universidade federal do parÁ instituto de tecnologia programa de … · mps.br melhoria do...
TRANSCRIPT
UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
UMA ABORDAGEM AUTOMATIZADA DE MEDIÇÃO EM
PROCESSOS DE SOFTWARE
Luciana Maria Azevedo Nascimento
DM 36/2007
UFPA / ITEC / PPGEE Campus Universitário do Guamá
Belém-Pará-Brasil Dezembro/2007
II
UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Luciana Maria Azevedo Nascimento
UMA ABORDAGEM AUTOMATIZADA DE MEDIÇÃO EM
PROCESSOS DE SOFTWARE
DM 36/2007
UFPA / ITEC / PPGEE Campus Universitário do Guamá
Belém-Pará-Brasil Dezembro/2007
III
UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Luciana Maria Azevedo Nascimento
UMA ABORDAGEM AUTOMATIZADA DE MEDIÇÃO EM
PROCESSOS DE SOFTWARE
Dissertação submetida à Banca Examinadora do Programa de Pós-Graduação em Engenharia Elétrica da UFPA para a obtenção do Grau de Mestre em Engenharia Elétrica
UFPA / ITEC / PPGEE Campus Universitário do Guamá
Belém-Pará-Brasil Dezembro/2007
IV
UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
UMA ABORDAGEM AUTOMATIZADA DE MEDIÇÂO EM PROCESSOS DE SOFTWARE
AUTOR: LUCIANA MARIA AZEVEDO NASCIMENTO DISSERTAÇÃO DE MESTRADO SUBMETIDA À AVALIAÇÃO DA BANCA EXAMINADORA APROVADA PELO COLEGIADO DO PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA DA UNIVERSIDADE FEDERAL DO PARÁ E JULGADDA ADEQUADA PARA OBTENÇÃO DO GRAU DE MESTRE EM ENGENHARIA ELÉTRICA NA ÁREA DE COMPUTAÇÃO APLICADA. APROVADA EM 21 / 12 / 2007 BANCA EXAMINADORA:
Prof. Dr. Elói Luiz Favero (ORIENTADOR – UFPA)
Prof. Dr. Roberto Célio Limão de Oliveira (MEMBRO – UFPA)
Prof. Dr. Rodrigo Quites Reis (MEMBRO – PPGCC/ICEN/UFPA)
Prof. Dr. Cleidson Ronald Botelho de Sousa (MEMBRO – PPGCC/ICEN/UFPA)
VISTO:
Prof. Dr. Evaldo Gonçalves Pelaes
(COORDENADOR DO PPGEE/ITEC/UFPA)
V
Agradecimentos
A Deus, por guiar meus caminhos.
Aos meus pais, Nádia e Reginaldo. Este trabalho também é fruto dos esforços e
muitos sacrifícios de vocês.
Ao professor Rodrigo Quites Reis, por ter incentivado em mim o gosto pela
pesquisa acadêmica, por ter acreditado e apoiado este trabalho, pelos conhecimentos
compartilhados e lições ensinadas.
Ao meu namorado Christopherson pela compreensão e companheirismo.
Ao amigo Anderson Costa, pelo apoio essencial na realização desse trabalho,
pelas discussões, idéias, sugestões e críticas construtivas.
Ao Breno França, que ajudou a elaborar soluções para requisitos fundamentais
deste trabalho.
À Carla Paxiúba, grande amiga sempre solícita e interessada em conversar
sobre essa dissertação, em me apoiar e compartilhar comigo seu conhecimento e experiência
profissional.
À Valéria, outra amiga querida, pelo apoio inestimável na finalização dessa
dissertação.
A todos os colegas que acompanharam e torceram por mim.
Aos colegas do LABES.
Aos professores do PPGEE.
À PROPESP.
À CAPES.
À Universidade Federal do Pará.
VI
SUMÁRIO
CAPÍTULO 1 INTRODUÇÃO ............................................................................................. 14
1.1. SUMÁRIO DOS OBJETIVOS DESTE TRABALHO. ..................................................................15
1.2. ORGANIZAÇÃO DO TEXTO. .................................................................................................16
CAPÍTULO 2 MEDIÇÃO E PROCESSO DE SOFTWARE ............................................. 17
2.1. CONCEITOS RELACIONADOS À MEDIÇÃO. .........................................................................19
2.2. ABORDAGENS DE MEDIÇÃO EM PROCESSOS DE SOFTWARE. ............................................22
2.2.1. O Paradigma GQM. ..........................................................................................................23
2.2.2. O Paradigma Goal-Driven Software Measurement. .........................................................25
2.3. MEDIÇÃO E MODELOS DE MELHORIA DE QUALIDADE. .....................................................27
2.3.1. CMMI ...............................................................................................................................27
2.3.2. MPS.BR. ...........................................................................................................................31
2.4. AUTOMAÇÃO DO PROCESSO DE SOFTWARE E O AMBIENTE WEBAPSEE ..........................36
2.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO. ............................................................................39
CAPÍTULO 3 ABORDAGEM DE MEDIÇÃO PARA PROCESSOS DE SOFTWARE 40
3.1. MODELO DE PROCESSO DE MEDIÇÃO. ...............................................................................41
3.1.1. Planejar Medição. .............................................................................................................42
3.1.2. Executar Medição. ............................................................................................................47
3.1.3. Avaliar Resultados............................................................................................................47
3.2. INTEGRAÇÃO DO MODELO DE PROCESSO DE MEDIÇÃO NO AMBIENTE WEBAPSEE. ...48
3.2.1. Medição no Domínio de Processos. .................................................................................49
3.2.2. Medição no Domínio Organizacional. ..............................................................................51
3.2.3. Proposta de ferramenta de apoio ao Processo de Medição no WebAPSEE. ....................53
3.3. CONSIDERAÇÕES FINAIS DO CAPÍTULO. .............................................................................55
CAPÍTULO 4 FERRAMENTA DE APOIO AO PROCESSO DE MEDIÇÃO ............... 57
4.1. MODELO DE DADOS PARA O DOMÍNIO DE PROCESSOS. ....................................................58
4.2. MODELO DE DADOS PARA O DOMÍNIO ORGANIZACIONAL. ..............................................65
4.3. PROTÓTIPO DA FERRAMENTA .............................................................................................67
4.3.1. Módulo MIPModel. ..........................................................................................................67
4.3.2. Módulo MIP .....................................................................................................................70
4.3.3. Módulo Organizacional ....................................................................................................73
4.4. MODIFICAÇÕES NO AMBIENTE WEBAPSEE. ....................................................................74
4.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO. .............................................................................76
CAPÍTULO 5 AVALIAÇÃO DA PROPOSTA ................................................................... 77
5.1. EXPERIMENTO. ....................................................................................................................77
5.2. ADERÊNCIA DA PROPOSTA AOS MODELOS CMMI E MPS.BR. ........................................85
VII
5.3. TRABALHOS RELACIONADOS. .............................................................................................87
5.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO. ............................................................................88
CAPÍTULO 6 CONCLUSÕES ............................................................................................. 89
6.1. ANÁLISE CRÍTICA DA PROPOSTA. .......................................................................................89
6.2. TRABALHOS FUTUROS. .......................................................................................................90
6.3. CONSIDERAÇÕES FINAIS DO TRABALHO. ...........................................................................91
REFERÊNCIAS ..................................................................................................................... 93
VIII
LISTA DE ILUSTRAÇÕES
FIGURA 1 - O PROCESSO DE SOFTWARE [37]. ............................................................... 17
FIGURA 2 - MODELO DE CLASSES PARA MEDIÇÃO (ADAPTADO DE [26]). ........... 19
FIGURA 3 – O PARADIGMA GQM [46]. ............................................................................. 24
FIGURA 4 - O PARADIGMA GOAL-DRIVEN SOFTWARE MEASUREMENT. .................. 26
FIGURA 5 - COMPONENTES DO MPS.BR [44]. ................................................................. 32
FIGURA 6 - REPRESENTAÇÃO GRÁFICA PARA AS PRINCIPAIS CONSTRUÇÕES DA WEBAPSEE-PML. .................................................................................................................. 37
FIGURA 7 - VISÃO DO GERENTE E DO DESENVOLVEDOR NO WEBAPSEE. ........... 38
FIGURA 8 - CICLO DE MELHORIA CONTÍNUA DE QUALIDADE. ............................... 41
FIGURA 9 - MODELO DE PROCESSO DE MEDIÇÃO PROPOSTO. ................................ 42
FIGURA 10 - MODELAGEM DAS ATIVIDADES DA ETAPA PLANEJAR MEDIÇÃO. 46
FIGURA 11 - EXEMPLO DE RELACIONAMENTO ENTRE METAS DE NEGÓCIO, DE MEDIÇÃO, QUESTÕES, INDICADORES E MÉTRICAS. .................................................. 47
FIGURA 12 - MODELAGEM DAS ATIVIDADES DA ETAPA AVALIAR RESULTADOS. .................................................................................................................................................. 48
FIGURA 13 - DOMÍNIOS DE MEDIÇÃO NO WEBAPSEE. ............................................... 49
FIGURA 14 - MEDIÇÃO NO DOMÍNIO DE PROCESSOS DE SOFTWARE. ................... 50
FIGURA 15 - MEDIÇÃO NO DOMÍNIO ORGANIZACIONAL. ......................................... 52
FIGURA 16 - INDICADOR ÍNDICE DE DESVIO DE PRAZOS DE PROJETOS ............... 53
FIGURA 17 - DIAGRAMA DE CONTEXTO DA FERRAMENTA PROPOSTA. ............... 54
FIGURA 18 - CASOS DE USO DA ETAPA EXECUTAR MEDIÇÃO NO WEBAPSEE. .. 55
FIGURA 19 - DIAGRAMA DE CLASSES PARA IMPLEMENTAÇÃO DO PROCESSO DE MEDIÇÃO NO DOMÍNIO DE PROCESSOS. ................................................................. 58
FIGURA 20 - DIAGRAMA DE ESTADOS DO MIPMODEL............................................... 63
IX
FIGURA 21 - DIAGRAMA DE ATIVIDADES DO MIPMODEL ........................................ 64
FIGURA 22 - DIAGRAMA DE CLASSES DE IMPLEMENTAÇÃO DO PROCESSO DE MEDIÇÃO NO DOMÍNIO ORGANIZACIONAL. ................................................................ 66
FIGURA 23 - TELA PRINCIPAL DO MÓDULO MIPMODEL. .......................................... 67
FIGURA 24 – TELA A) - ABA INDICATORS. TELA B) - DEFINIÇÃO DE UM INDICADOR NO MIPMODEL. .............................................................................................. 69
FIGURA 25 - CONFIGURAÇÃO DO INDICADOR PARA INTEGRAÇÃO DO MIP COM O PROCESSO DE SOFTWARE. ............................................................................................ 71
FIGURA 26 - VISUALIZAÇÃO E ANÁLISE DOS RESULTADOS NO DOMÍNIO DE PROCESSOS. ........................................................................................................................... 72
FIGURA 27 - VISUALIZAÇÃO E ANÁLISE DOS RESULTADOS NO DOMÍNIO ORGANIZACIONAL. ............................................................................................................. 74
FIGURA 28 - CAMADAS QUE COMPÕEM A ARQUITETURA DO WEBAPSEE [29] . 75
FIGURA 29 - EXECUÇÃO DO PROCESSO DE EXEMPLO. .............................................. 78
FIGURA 30 - ATIVIDADE ELICITAR REQUISITOS. ........................................................ 79
FIGURA 31 - ATIVIDADE DESENVOLVER ALTERAÇÕES. ........................................... 80
FIGURA 32 - ATIVIDADE IMPLANTAR PROJETO. ......................................................... 80
FIGURA 33 – ELABORAÇÃO DO INDICADOR “DESVIO DE CUSTO POR TIPO DE ATIVIDADE”. ......................................................................................................................... 83
FIGURA 34 - INDICADOR DESVIO DE CUSTO POR TIPO DE ATIVIDADE. ............... 83
X
LISTA DE TABELAS
TABELA 1 - TIPOS DE ESCALA E OPERAÇÕES ADMISSÍVEIS. ................................... 21
TABELA 2 - GABARITO PARA DEFINIÇÃO DE META (ADAPTADO DE [1] ). ........... 24
TABELA 3 - NÍVEIS DE MATURIDADE NO CMMI. ......................................................... 28
TABELA 4 - METAS E PRÁTICAS ESPECÍFICAS PARA MEDIÇÃO E ANÁLISE NO NÍVEL 2 CMMI. ...................................................................................................................... 30
TABELA 5 - METAS E PRÁTICAS DAS ÁREAS DE PROCESSO DO NÍVEL 4 CMMI. 31
TABELA 6 - NÍVEIS DE MATURIDADE DO MR-MPS. .................................................... 33
TABELA 7 – EXEMPLO DE METAS DE NEGÓCIO. ......................................................... 43
TABELA 8 – EXEMPLO DE METAS DE MEDIÇÃO. ......................................................... 43
TABELA 9 – EXEMPLO DE QUESTÕES. ............................................................................ 44
TABELA 10 – EXEMPLO DE DEFINIÇÃO DE UM INDICADOR. ................................... 45
TABELA 11 - CASOS DE USO PRINCIPAIS E REQUISITOS RELACIONADOS. .......... 55
TABELA 12 - CATEGORIA DA SELEÇÃO BYTYPE POR TIPO DE ALVO. .................... 61
TABELA 13 - METAS DE NEGÓCIO ELABORADAS NO ESTUDO DE CASO. ............. 81
TABELA 14 - METAS DE MEDIÇÃO ELABORADAS NO ESTUDO DE CASO E METAS DE NEGÓCIO RELACIONADAS. ......................................................................................... 81
TABELA 15 - QUESTÕES NO ESTUDO DE CASO E METAS DE MEDIÇÃO RELACIONADAS.. ................................................................................................................. 82
TABELA 16 - INDICADORES NO ESTUDO DE CASO E QUESTÕES RELACIONADAS. .................................................................................................................................................. 82
TABELA 17 – APOIO FORNECIDO AO NÍVEL 2 DO CMMI E AO NÍVEL F DO MPS.BR. ................................................................................................................................... 86
XI
LISTA DE SIGLAS E ABREVIAÇÕES
CMMI Capability Maturity Model Integration
GQM Goal-Question-Metric
GQ(I)M Goal-Question-Indicator-Metric
MIP Measurement Implementation Plan
MIPModel Measurement Implementation Plan Model
MPS.BR Melhoria do Processo de Software Brasileiro
OrgMIP Organizational Measurement Implementation Plan
PSEE Process-Centered Software Engineering Environment
XII
RESUMO
Os atuais avanços tecnológicos em diversos setores da sociedade resultam em demanda por
software cada vez mais complexo, robusto e confiável. Como conseqüência, a complexidade
de gerenciar o desenvolvimento de software também é maior: surgem novas tecnologias,
padrões e técnicas, o mercado é mais competitivo e exige maior produtividade e qualidade
com menor custo e prazo. Nesse cenário, dados quantitativos que retratem a realidade do
processo de desenvolvimento são úteis para fundamentar e justificar decisões e tomada de
ações. Além disso, medidas coletadas formam uma base histórica valiosa que pode ser usada
para caracterizar o processo e seus elementos, obter conhecimento sobre pontos fortes e
oportunidades de melhorias, avaliar o alcance de metas e impactos de mudanças, realizar
planejamento e previsões, entre outros. Esta dissertação apresenta uma abordagem para
medição de projetos de software cujo objetivo é prover apoio para seleção, coleta e análise de
dados quantitativos e qualitativos que possam auxiliar a melhoria de processos e seus
produtos. A abordagem está integrada em um ambiente de desenvolvimento centrado em
processos usufruindo, portanto da estrutura e potenciais benefícios oferecidos para gerência
de processos.
Palavras-chave: Engenharia de Software, Processo de Software, Medição,
Tecnologia de Processo.
XIII
ABSTRACT
Current technological advances demand software systems with increasing complexity and
reliability attributes. As a consequence it also influences software management activities: new
technologies arise; market is more competitive and requires higher productivity and quality;
the pressure for time-to-market is increasing as well. Thus, information reflecting software
development status is needed in order to justify decisions and actions to be taken by
managers. Besides, the collected data constitute a valuable historical database that can be used
to: characterize the process and its elements; obtain knowledge on strong points and
opportunities of improvements; evaluate the reach of goals and the impacts of changes; plan
and foresight outcomes; and so on. This work presents a measurement methodology for
software projects which aims to provide quantitative and qualitative data that can improve
both processes and their products. Finally, this proposal was built on the top of a process-
centered software engineering environment, which explores the synergy of such integration in
order to provide management staff with continuously updated information.
Keywords: Software Engineering, Software Process, Measurement, Software
Process Technology.
14
CAPÍTULO 1
INTRODUÇÃO
O contexto atual de desenvolvimento de software caracteriza-se pela grande
demanda por sistemas de software cada vez mais complexos e robustos, freqüentes mudanças
de tecnologia e surgimento de padrões, metodologias e técnicas. O mercado é mais
competitivo, com clientes exigindo maior produtividade em menos tempo, com menor custo,
e maior qualidade do produto de software. O melhor atendimento a esses requisitos implica
em um grande diferencial entre organizações de software [33].
Qualidade deixou de ser um diferencial competitivo e tornou-se um requisito básico
para a sobrevivência no mercado [18]. Com isso, nos últimos anos as organizações de
desenvolvimento de software voltaram sua atenção à maneira como constroem software, ou
seja, ao Processo de Software. O Processo de Software pode ser definido como um conjunto
de atividades e seus elementos relacionados que devem ser realizadas para transformar as
necessidades do cliente em software. Em outras palavras, processos de software indicam o
que deve ser feito, quando, como, onde e por quem deve ser feito, e quais recursos serão
utilizados.
Para gerar produtos de software com níveis de qualidade desejáveis é necessário
verificar a qualidade do processo utilizado para desenvolvê-los. Para tanto, segundo [14] duas
abordagens são adotadas: a melhoria do processo de software e o uso de tecnologia para
apoiá-lo e até mesmo automatizá-lo. O uso de tecnologia para automação de processo de
software tem sido apoiado por ambientes integrados de desenvolvimento denominados PSEEs
(Process-Centered Software Engineering Environments) [11], que são ambientes que podem
apoiar a análise, modelagem, simulação, execução e reutilização de processos de
desenvolvimento de software para automação do seu gerenciamento.
Em relação à melhoria do processo, alguns modelos de qualidade tem sido propostos,
como os padrões CMMI (Capability Maturity Model Integration) [8] e o brasileiro MPS.BR
(Melhoria do Processo do Software Brasileiro) [44]. Esses modelos definem um conjunto de
práticas/atividades que as organizações devem seguir para se enquadrar em um dos crescentes
níveis de qualidade. Níveis mais altos de qualidade exigem melhoria constante do processo de
15
software apoiada por dados quantitativos e qualitativos, ou seja, atividades de medição e
análise do processo são requisitos essenciais para alcançar maturidade no desenvolvimento de
software.
Medição é o processo pelo qual números ou símbolos são associados a atributos e
entidades no mundo real, descrevendo-as de acordo com regras claramente definidas e
produzindo como resultado um conjunto de métricas [15]. Através da medição obtêm-se
dados que retratam a realidade do processo de desenvolvimento de software, propiciando a
melhoria do processo através da análise de ineficiências, oportunidades de melhoria e
avaliação de impactos.
Apesar do consenso sobre a importância da medição em processos de software, a
implementação de um processo de medição nas organizações de desenvolvimento de software
ainda é problemática [42]. Isso ocorre porque definir um processo de medição não é uma
tarefa trivial, pois demanda conhecimento para que não venha aumentar as dificuldades
enfrentadas durante o desenvolvimento de software, como por exemplo, demanda de esforço
na coleta de métricas desnecessárias e análise equivocada dos resultados. Portanto, para
reduzir os custos e riscos de um processo de medição ineficiente e/ou incorreto, torna-se
necessário a adoção de uma metodologia que auxilie a identificação de métricas úteis e
facilite a análise dos resultados.
1.1. SUMÁRIO DOS OBJETIVOS DESTE TRABALHO.
No contexto do cenário descrito, a proposta dessa dissertação é a definição de uma
abordagem automatizada para implantação de Processos de Medição, abrangendo:
• Seleção e definição de métricas que forneçam informações úteis à organização;
• Definição de procedimentos de coleta e análise;
• Recuperação e Análise dos resultados obtidos.
Como parte integrante da proposta, será definida uma abordagem de integração com
um ambiente automatizado de gerenciamento de processos, visando usufruir da riqueza de
dados e informações armazenadas em um ambiente que permite a modelagem e
acompanhamento de processos, mantendo o registro da execução dos processos.
16
1.2. ORGANIZAÇÃO DO TEXTO.
Além da Introdução, esta dissertação possui mais cinco capítulos, organizados como
descrito a seguir.
O segundo capítulo resume o estudo realizado sobre medições e processos de
software, apresentando conceitos sobre medição, além de abordagens encontradas na
literatura para executar medições em processos de software. São apresentados também
modelos de melhoria de qualidade de processos e uma discussão sobre como a medição está
inserida nestes modelos. Em seguida descreve-se como ambientes de desenvolvimento de
software fornecem auxílio para automação do gerenciamento de processos, para então
apresentar o ambiente WebAPSEE, no qual a proposta deste trabalho foi integrada.
No terceiro capítulo o modelo proposto para Processo de Medição é apresentado,
contendo a descrição e justificativa de todos os passos. Em seguida é descrita a abordagem de
integração com o ambiente WebAPSEE.
No quarto capítulo é apresentado o projeto de classes para o protótipo de apoio à
abordagem. Em seguida são descridos os módulos desenvolvidos e as alterações realizadas no
ambiente WebAPSEE para possibilitar a integração do protótipo.
O quinto capítulo apresenta a análise da proposta através da simulação de um
processo real, avaliação da aderência aos modelos CMMI e MPS.BR e, por último,
comparação com trabalhos relacionados.
Por fim, no capítulo 6 são descritas as considerações finais, uma análise crítica da
proposta e os trabalhos futuros.
17
CAPÍTULO 2
MEDIÇÃO E PROCESSO DE SOFTWARE
Para gerar produtos de software com níveis de qualidade desejáveis é necessário
verificar a qualidade das atividades, ferramentas e métodos utilizados, pois a qualidade do
software é fortemente relacionada com a qualidade do processo executado para desenvolvê-lo
[19].
O Processo de Software pode ser definido como um conjunto de atividades e seus
elementos relacionados (recursos, pessoas, ferramentas, entre outros) que devem ser
realizadas para transformar as necessidades (requisitos) do cliente em software. Em outras
palavras, processos de software indicam o que deve ser feito, quando, como, onde e por quem
deve ser feito, e quais recursos serão utilizados. Como ilustra a Figura 1, a partir dos
requisitos iniciais de um problema a ser solucionado por software, um processo será adotado
para transformar os requisitos em um produto de software.
Figura 1 - O Processo de Software [37].
Para planejar o processo de desenvolvimento de um produto de software, alternativas
são avaliadas para definir e organizar as atividades, períodos devem ser estimados de acordo
com os prazos estabelecidos e os recursos e pessoas devem ser alocados dentro das restrições
18
de custo determinadas. Além disso, problemas devem ser previstos através da avaliação de
riscos, e possíveis soluções estratégicas devem ser elaboradas.
Por mais que seja bem planejado, dificilmente o processo executado será idêntico ao
seu planejamento inicial. Isso ocorre porque o processo de software não é estático [30], é um
processo criativo que envolve pessoas e cujos requisitos certamente mudam e/ou evoluem ao
longo de seu progresso. Portanto, para obter sucesso no projeto de desenvolvimento é
imprescindível monitorar a execução do processo em relação ao que foi planejado e, caso
necessário, modificar o processo para mantê-lo sob controle, novamente avaliando
alternativas e antecipando riscos na tentativa de finalizar o projeto de acordo com o prazo e
custo estimados. Nesse cenário, dados quantitativos que retratem a realidade do processo são
indispensáveis para o seu gerenciamento.
Em qualquer campo da Ciência, medições e análises geram descrições quantitativas
que nos ajudam a compreender comportamentos e resultados [36]. Dentre as razões para
realizar medições em processos, produtos e recursos relacionados, pode-se citar o fato de que,
através da análise de seus resultados, fornecem subsídios para ([6] e [34]):
• Caracterizar processos, produtos e recursos para melhor conhecê-los e
estabelecer baselines para futuras comparações;
• Monitorar a execução do processo e assim verificar sua aderência em relação ao
seu planejamento, possibilitando tomada de ações para controle de custos, prazos
e redução de riscos;
• Avaliar o alcance de metas de qualidade e o impacto de ações de melhorias
tecnológicas e de processo;
• Prever e planejar baseando-se em dados históricos, obtendo conhecimento
acerca dos relacionamentos entre processos e seus elementos correlatos, de modo
que os valores observados em determinados atributos possam ser usados para
prever outros. Além disso, o conhecimento obtido possibilita que as estimativas
sejam feitas com base em evidências; e
• Melhorar, identificando através de informações quantitativas ineficiências e
oportunidades de melhoria, propiciando melhor escolha de métodos, técnicas e
ferramentas.
Na próxima seção são apresentados conceitos necessários para compreender, analisar
e fazer uso de medições. Em seguida, a seção 2.2 descreve abordagens propostas na literatura
19
especializada para medição em processos de software. Por último, a seção 2.3 apresenta
modelos de melhoria de qualidade de processos, destacando como o processo medição está
inserido nesses modelos.
2.1. CONCEITOS RELACIONADOS À MEDIÇÃO.
Segundo [15], medição é o processo pelo qual números ou símbolos são associados a
atributos e entidades no mundo real, descrevendo-as de acordo com regras claramente
definidas e produzindo como resultado um conjunto de métricas. Portanto, medição é a forma
de capturar e mapear informações de atributos do mundo real para o mundo formal, de modo
que possam ser manipuladas para caracterizar e conhecer melhor os atributos em questão [17],
[26].
Para melhor manipular e analisar corretamente os resultados obtidos pela medição, é
necessário conhecer quais elementos estão envolvidos na execução da medição, e como se
relacionam entre si. Kitchenham et al descreve esses elementos em [26], representados na
Figura 2 por um diagrama de classes com separação entre elementos do mundo real e formal.
Figura 2 - Modelo de classes para Medição (adaptado de [26]).
Uma Entidade é um objeto observado no mundo real para o qual, através de
medição, deseja-se capturar características a fim de manipulá-las formalmente. São exemplos
de entidades na Engenharia de Software: processos (qualquer atividade relacionada com
desenvolvimento e/ou manutenção de software), produtos (artefatos produzidos ou
Mundo Formal (Matemático) Mundo Empírico (Real)
20
modificados durante o desenvolvimento, em diferentes níveis granularidade), e recursos
(pessoas, equipamentos e software utilizados).
As características de uma entidade são denominadas Atributos. Uma entidade pode
possuir vários atributos, como tamanho, esforço, complexidade, entre outros. Um mesmo
atributo pode qualificar várias entidades, como por exemplo, o atributo produtividade pode
ser aplicado a pessoas, equipes ou processos.
Uma Unidade de medição determina como medir um atributo. Várias unidades
poder ser usadas para medir um mesmo atributo (temperatura, por exemplo, pode ser medida
em graus Fahrenheit, Celsius, ou na escala Kelvin), e uma unidade pode estar relacionada a
diferentes atributos.
O Tipo de Escala de uma unidade determina as transformações admissíveis para uso
e análise de atributos quantificados em uma unidade específica. Portanto, compreender o tipos
de escala é importante para que, ao aplicar operações matemáticas, encontre-se resultados
válidos. De acordo com [7], [26] e [34], os tipos de escalas são:
• Nominal: é o tipo de escala mais simples, usada para classificar entidades. O
valor do atributo pode ser um nome ou um rótulo, sendo aceitável qualquer
representação simbólica ou numérica, porém não há noção de magnitude. Não
permite a realização de operações aritméticas nem ordenação de valores;
• Ordinal: acrescenta a noção de ordem à escala nominal, mas a distância entre os
valores não tem qualquer significado;
• Intervalar: define uma distância entre um valor e outro, de forma que existam
intervalos de mesmo tamanho entre valores consecutivos. Permite a execução de
operações de adição, subtração e média, mas não permite comparação entre
valores por não existir um zero absoluto nessa escala;
• Racional: nessa escala existe a definição de um zero absoluto, que representa a
ausência do valor medido e funciona como o ponto inicial da escala. Com isso, é
permitido calcular a razão entre grandezas;
• Absoluta: é um caso especial de escala racional onde o único multiplicador
permitido é o número um. A medição nessa escala é feita contando o número de
ocorrências, como por exemplo, a determinação da quantidade de defeitos
encontrados num produto após a entrega.
21
A Tabela 1 apresenta as operações válidas para cada tipo de escala, além de alguns
exemplos.
Tabela 1 - Tipos de escala e operações admissíveis.
Tipo de
Escala Operações Exemplos
Nominal Determinação de igualdade e cálculo
da moda.
Rótulos e classificações como:
- Nomes de linguagens de programação (ex.: Ada, C,
Java)
- Tipos de atividade (análise, projeto, codificação,
teste).
Ordinal
O mesmo que acima, mais a
determinação de maior e menor, e
cálculo da mediana.
Classificações como:
- Complexidade de risco (Alta, Média, Baixa).
- Experiência do desenvolvedor (Inexperiente, Pouco
Experiente, Experiente, Especialista).
Intervalar
O mesmo que acima, mais a
determinação de igualdade de
intervalos, soma, diferença e média
aritmética.
- Tempo (hora, minuto, segundo).
- Data.
- Temperatura em graus Fahrenheit ou Celsius.
Racional
Mesmo que acima, mais a
determinação de igualdade de
razões, média geométrica e média
harmônica.
- Intervalos de tempo.
- Custo, esforço, tamanho.
- Temperatura na escala Kelvin.
Absoluto
Mesmo que acima, mais a
determinação de igualdade com
valores obtidos de outras escalas do
mesmo tipo.
- Contagens em geral.
- Probabilidade.
Ao medir um atributo de uma entidade, aplica-se a ele uma unidade específica para
obter um determinado Valor. O valor medido só tem sentido no contexto da entidade, atributo
e unidade de medida aos quais está relacionado.
Um Instrumento de Medição pode ser usado para determinar o valor de um atributo
usando uma unidade específica de medição. Como exemplo pode-se usar um termômetro para
medir temperatura, um software para contar linha de código, entre outros.
A medição de um atributo pode ser classificada como direta ou indireta. Medições
diretas mapeiam valores de atributos através da observação apenas do atributo envolvido,
gerando métricas denominadas primitivas, diretas ou básicas. A medição indireta de um
22
atributo envolve valores de outros atributos necessários para calcular o valor desejado.
Métricas que dependem de outras métricas são chamadas de secundárias, indiretas ou
derivadas.
Por sua vez, as métricas podem ser classificadas como métricas objetivas ou
métricas subjetivas. Métricas objetivas independem do autor da medição – o mesmo
resultado será obtido quando duas ou mais pessoas executam a mesma medição. Métricas
subjetivas dependem do contexto e do julgamento da pessoa que realizou a medição, sendo
possível obter resultados diferentes se medidas novamente por outra pessoa, ou até se pela
mesma pessoa em outro momento.
2.2. ABORDAGENS DE MEDIÇÃO EM PROCESSOS DE SOFTWARE.
A etapa principal para a definição de um processo de medição é a seleção das
métricas que serão coletadas, o que não é uma tarefa trivial. Diversas métricas já foram
propostas na literatura para uma grande variedade de atributos de processos, produtos,
recursos, entre outros, como em [12], [17] e [25], o número de atributos de entidades passíveis
de medição é potencialmente grande [34], assim como as possíveis escalas de medição [6].
Segundo Park et al [34], o desafio da medição é identificar quais atributos devem ser
coletados para gerar visões úteis das entidades que necessitam ser analisadas, gerando o
mínimo de esforço extra possível. A escolha incorreta de atributos e métricas pode aumentar
as dificuldades enfrentadas durante o desenvolvimento de software, como demanda de esforço
na coleta de métricas desnecessárias e análise equivocada dos resultados.
Os modelos existentes para seleção de métricas podem ser categorizados por duas
abordagens principais [35]: bottom-up e top-down. Na abordagem bottom-up, é selecionado
um conjunto de métricas a serem coletadas em relação ao processo, recursos, produtos e seus
resultados. Inicia-se verificando o que pode ser medido e a partir daí pode-se chegar aos
objetivos da medição [22]. A abordagem defende que existe um conjunto de métricas
fundamentais necessárias para responder qualquer questão da organização. Na prática, a
abordagem mostrou-se falha no principal objetivo da medição: prover informações
quantitativas para apoiar decisões gerenciais [16].
A abordagem top-down preconiza que métricas devem ser derivadas de objetivos e
necessidades de informação da organização, e a interpretação dos dados deve ser feita no
contexto dos objetivos. Portanto, ao se iniciar um programa de medição a primeira pergunta a
23
ser feita não deve ser “Que métricas devem ser coletadas?”, mas sim “O que se deseja
aprender?” [39].
A literatura apresenta diferentes abordagens top-down, como o QFD (Quality
Function Deployment Aproach) [27], o SQM (Software Quality Metrics Approach) [5] e o
GQM (Goal-Question-Metric) [1][2]. Dentre esses, o GQM é o mais difundido por ter se
mostrado o mais flexível e aplicável [38].
As próximas subseções descrevem, respectivamente, o paradigma GQM e sua
vertente Goal-Driven Software Measurement, por terem sido a base da proposta desse
trabalho.
2.2.1. O Paradigma GQM.
O GQM é um paradigma orientado a objetivos, portanto afirma que o processo de
medição não deve ser guiado pelas métricas, mas sim pelo o que se deseja obter através de sua
coleta. Foi desenvolvido inicialmente na Universidade de Maryland em cooperação com a
NASA [4] e depois passou a fazer parte do projeto TAME [3].
O paradigma GQM afirma que medições só devem ser realizadas se estiverem
fundamentadas por uma ou mais metas claramente definidas. Logo, o ponto de partida para
seleção de métricas é a definição de um conjunto de metas que se pretende atingir quanto ao
processo e produtos através de atividades de medições. Em geral, as metas são relacionadas a
questões fundamentais para a organização, como por exemplo, produtividade.
Em seguida deve ser gerado um conjunto de questões que traduzam as metas em
aspectos quantitativos e que, ao serem respondidas, ajudem a organização a atingir as metas
identificadas. Finalmente, identificam-se métricas que ao serem coletadas ajudem a responder
as questões. A Figura 3 ilustra o relacionamento existente entre metas, questões e métricas.
Enquanto a definição das métricas segue a abordagem top-down, a interpretação dos dados é
feita de modo bottom-up: de posse dos dados, verifica-se as questões e metas relacionadas
para então analisar os resultados.
24
Figura 3 – O paradigma GQM [46].
Devido ao fato de que as metas são primordiais para a definição da estrutura de
medição, o GQM estabelece que a definição de uma meta deve ser composta por: 1) uma
proposta que especifica o objeto alvo de medição e a razão da coleta; 2) uma perspectiva que
define o aspecto de referência e o ponto de vista a ser adotado; e 3) uma descrição do
ambiente, o contexto em que a medição será executa, com objetivo de permitir futuras
comparações. A Tabela 2 mostra o gabarito sugerido em [1] para definição de metas do GQM.
Tabela 2 - Gabarito para definição de meta (adaptado de [1] ).
Proposta Analisar o(a)_______________________ (objeto: processo, produto) Com a intenção de___________________ (razão: conhecer, avaliar, prever, melhorar)
Perspectiva o(a)______________________________ (foco :custo, correção, confiabilidade,...) do ponto de vista do(a)_______________ (quem: usuário, cliente, desenvolvedor, gerente,....)
Ambiente no seguinte contexto: _______________________ (descrever o ambiente)
Segundo Soligen e Berghout em [46], a aplicação do GQM possui 4 etapas:
• Planejamento, onde ocorre a seleção do que será mensurado e planejamento do
projeto de medição;
• Definição, na qual as metas, questões e métricas são definidas e documentadas.
• Coleta de Dados; e
• Interpretação, onde os dados coletados são analisados para responder as
questões e as respostas encontradas são analisadas para verificar o alcance das
metas estabelecidas.
Aplicando-se o GQM, as medições realizadas são alinhadas com os objetivos
organizacionais, diminuindo o risco de coletar métricas que não possuam utilidade para a
Def
iniç
ão
G1 G2
Q1 Q2 Q3 Q4 Q5
M1 M2 M3 M4 M5 M6 M7
Questões
Métricas
Interpretação
Metas
25
organização. A rastreabilidade entre as metas e métricas coletadas tem como benefício servir
como base para futuras melhorias no próprio processo de medição, já que mudanças nas metas
refletirão mudanças nas suas métricas derivadas. Além disso, a mesma rastreabilidade é usada
no sentido de métrica em direção à meta para auxiliar na interpretação correta dos resultados.
2.2.2. O Paradigma Goal-Driven Software Measurement.
Considerado como uma extensão do GQM, o paradigma Goal-Driven Software
Measurement foi proposto em 1996 pelo Software Engineering Institute (SEI), da
Universidade de Carnegie Mellon [34]. O objetivo do paradigma é auxiliar a seleção de
métricas de apoio ao alcance às metas de negócio da organização, mantendo a rastreabilidade
entre métricas e metas de negócio para que os esforços de medição não sejam desviados de
seus propósitos de origem.
O paradigma Goal-Driven Software Measurement determina um processo completo
para definição de uma política de medição, composto por 10 passos ordenados:
1. Identificar Metas de Negócio.
2. Identificar o que se deseja aprender.
3. Identificar Submetas para refinar as Metas de Negócio.
4. Identificar entidades e atributos relacionados com as Submetas.
5. Formalizar Metas de Medição.
6. Identificar Questões quantitativas e Indicadores relacionados que auxiliem a o
alcance das Metas de Medição.
7. Identificar os elementos de dados que serão coletados para construir os
Indicadores.
8. Definir e padronizar as medições que serão usadas.
9. Identificar as ações que serão tomadas para implementar as medições.
10. Preparar um plano para a implementação das medições.
São duas as principais características que diferem o Goal-Driven Software
Measurement do GQM: 1) o processo inicia a partir de metas de negócio organizacionais, e 2)
após a geração de questões, define-se indicadores que auxiliarão na seleção de métricas mais
adequadas. Devido à inserção desse elemento em relação ao GQM, o paradigma Goal-Driven
26
Software Measurement é também conhecido como GQ(I)M (Goal-Question-Indicator-
Metric), acrônimo que será usado nesse trabalho deste ponto em diante.
As metas de negócio devem representar os esforços estratégicos da organização e
não estão necessariamente relacionadas a atributos mensuráveis do processo. Para cada meta
de negócio identificada, são enumerados os aspectos que necessitam ser compreendidos,
verificados, previstos ou melhorados para que a meta seja atingida. Agrupando esses aspectos,
é possível desenvolver metas específicas, chamadas de submetas, para as metas de negócios.
O próximo passo é a definição de entidades do processo que será medido, e para cada
entidade enumeram-se seus atributos mensuráveis.
Com a execução dos quatro primeiros passos, gera-se uma estrutura de informação
que será a base para a aplicação do GQM do quinto ao sétimo passo, com a diferença da
identificação dos indicadores.
Um indicador é uma representação de um ou mais resultados de medição, elaborado
para facilitar a comunicação e compreensão dos resultados e assim ajudar a responder as
questões derivadas das metas de medição.
A Figura 4 ilustra o relacionamento entre os elementos identificados nos sete
primeiros passos, destacando as etapas de aplicação do GQM. Os três últimos passos visam
operacionalizar as medições através da padronização do processo de coleta e planejamento da
implantação desse processo na organização.
Figura 4 - O paradigma Goal-Driven Software Measurement.
Indicadores
Metas de Medição G1 G2
Q1 Q2 Q3 Q4
M1 M2 M3 M4 M5 M6
Questões
Métricas
Metas de Negócio
Aspectos que se deseja compreender
Submetas Entidades e Atributos
I1 I2 I3 I4 I5
27
2.3. MEDIÇÃO E MODELOS DE MELHORIA DE QUALIDADE.
No intuito de promover a melhoria na qualidade de processos, têm sido propostos
modelos que avaliam e certificam o nível de maturidade de uma organização na execução de
seus processos, como o CMMI (Capability Maturity Model Integration) [8] e o brasileiro
MPS.Br (Melhoria do Processo do Software Brasileiro) [44]. Este último é baseado nos
padrões ISO/IEC 12207 [23], ISO/IEC 15504 [13] e na representação em estágios do CMMI.
Em geral, modelos de melhoria de qualidade de processos definem práticas que as
organizações devem seguir para se enquadrarem em algum dos seus crescentes níveis de
maturidade estabelecidos. As subseções a seguir apresentam os modelos CMMI e MPS.Br
respectivamente, evidenciando como a medição de processos é tratada em cada um dos
modelos.
2.3.1. CMMI
O CMMI é um modelo de melhoria de maturidade de processos de desenvolvimento
de produtos e serviços, desenvolvido pelo Software Engineering Institute da Universidade de
Carnegie Mellon em conjunto com órgãos militares americanos e organizações da indústria de
desenvolvimento de software. Seu objetivo é prover um framework único e integrado para
melhoria de processo em organizações, contendo melhores práticas para atividades de
desenvolvimento e manutenção a serem executadas em todo o ciclo de vida de um produto.
Inicialmente, o SEI desenvolveu o modelo SW-CMM (Software Capability Maturity
Model), por solicitação do Departamento de Defesa norte-americano. Posteriormente surgiram
outros modelos CMM para várias disciplinas, dentre os quais se destacaram os modelos para
Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência de Força
de Trabalho e Desenvolvimento Integrado de Processo e Produto. Apesar da utilidade
comprovada desses modelos em diferentes indústrias, o uso de múltiplos modelos se mostrou
problemático, limitando a expansão de melhorias dentro de uma organização. Para solucionar
esse problema, o CMMI foi desenvolvido como uma evolução dos modelos SW-CMM
(Capability Maturity Model for Software), SECM (System Engineering Capability Model) e
IPD-CMM (Integrated Product Development Capability Maturity Model), sendo portanto o
sucessor desses modelos.
O framework CMMI permite a utilização de um modelo próprio para uma única
disciplina ou a integração de modelos, como Engenharia de Software e Aquisição de
Software. Nesta seção será dado enfoque para o modelo CMMI-DEV [41], que provê
28
recomendações para o gerenciamento, medição e monitoração de processos de
desenvolvimento.
No CMMI, os tópicos mais importantes para melhoria de processos são agrupados
em áreas de processos, classificadas em uma das 4 categorias: Gerência do Processo, Gerência
do Projeto, Engenharia e Suporte. Para cada área de processo são definidas práticas
específicas necessárias para atingir suas metas.
Pela representação em estágios, o CMMI define cinco níveis crescentes de
maturidade para a capacidade da organização em desenvolver seus produtos com qualidade e
conforme os custos e prazos assumidos. A Tabela 3 apresenta os níveis de maturidade e suas
áreas de processo.
Tabela 3 - Níveis de Maturidade no CMMI.
Nível Áreas de Processo
Nível 5: Em Otimização Análise de Causas e Resolução
Inovação e Implantação na Organização
Nível 4: Quantitativamente Gerenciado
Gerenciamento Quantitativo do Processo
Desempenho do Processo Organizacional
Nível 3: Definido Desenvolvimento de Requisitos
Solução Técnica
Integração de Produtos
Verificação
Validação
Foco no Processo Organizacional
Definição do Processo Organizacional
Treinamento Organizacional
Gerência Integrada do Projeto
Gerência de Riscos
Análise de Decisão e Resolução
Nível 2: Gerenciado Gerência de Requisitos
Planejamento do Projeto
Monitoração e Controle do Projeto
Gerência de Acordos com Fornecedores
Medição e Análise
Garantia da Qualidade do Processo e do Produto
Gerência de Configuração
Nível 1: Inicial -
29
Além das práticas e metas específicas de cada área de processo, em cada nível de
maturidade são definidas práticas genéricas para todas as áreas de processo do nível em
questão e seus níveis inferiores.
O nível Inicial caracteriza organizações instáveis, com processos informais e caóticos
cujos projetos dependem dos esforços muitas vezes heróicos de algumas pessoas. Mesmo
nesse contexto podem ser desenvolvidos produtos que funcionem como requerido, mas
freqüentemente extrapolam os custos e prazos planejados.
No nível Gerenciado, o processo é gerenciado em nível de projeto. Com a adoção das
práticas relacionadas às áreas de processo do nível, a organização é capaz de assumir
compromissos em relação ao desenvolvimento dos requisitos, prazos e custos de projetos com
grandes chances de cumpri-los. Como essas práticas são aplicadas no nível de projetos,
mudanças na estrutura da organização podem causar problemas nos projetos, sejam elas
mudanças de políticas, tecnologia, entre outras.
No nível Definido, o foco está na padronização dos processos. Para tanto, os
processos são definidos e institucionalizados na organização através de padrões,
procedimentos, ferramentas e métodos. Também são estabelecidas instruções de adaptação
para que os processos-padrão da organização possam ser ajustados às características de cada
projeto. Para alcançar o nível 3, além de executar as práticas definidas para ele é necessário
cumprir as determinações do nível 2.
O enfoque do nível 4 é a Gerência Quantitativa dos processos executados na
organização. Para tanto são estabelecidos objetivos quantitativos para a qualidade e
desempenho do processo organizacional, e esses objetivos irão nortear o gerenciamento dos
processos. Nesse nível, a organização é proficiente em coletar métricas que possibilitem
gerenciar os processos através do controle estatístico dos seus objetivos e metas de qualidade.
Uma organização só pode alcançar o nível 4 se também cumprir as práticas requeridas nos
níveis 2 e 3.
O nível máximo do CMMI é o nível Em otimização, no qual os processos estão no
estágio de melhoria contínua e são otimizados de acordo com as necessidades do momento da
organização. As melhorias são baseadas em dados quantitativos e fornecem apoio para os
objetivos de qualidade e de desempenho do processo, pois derivam das metas de negócio da
organização.
30
No CMMI as atividades de medição são agrupadas em uma área de processo
específica denominada Medição e Análise, que têm por objetivo “desenvolver e sustentar a
capacidade de medições que é utilizada para apoiar as necessidades de gerenciamento de
informações” [8]. Medição e Análise são classificadas como uma área de processo de suporte,
por constituírem um processo essencial que provê informações para outras áreas de processo.
Seguindo a representação em estágios preconizada pelo CMMI, a implantação da
área de processo Medição e Análise é iniciada já no nível 2 e possui duas metas específicas:
Alinhar Atividades de Medição e Análise e Fornecer Resultados de Medição. As práticas
associadas a cada uma das metas específicas são listadas na Tabela 4.
Tabela 4 - Metas e práticas específicas para Medição e Análise no nível 2 CMMI.
Meta Específica 1: Alinhar atividades de Medição e Análise
Práticas Específicas:
PE 1.1 - Estabelecer objetivos de medição.
PE 1.2 - Especificar medidas. PE 1.3 - Especificar procedimentos de coleta e armazenamento de dados.
PE 1.4 - Especificar procedimentos de análise.
Meta Específica 2: Fornecer Resultados de Medição
Práticas Específicas: PE 2.1 - Coletar dados de medições.
PE 2.2 - Analisar dados de medições.
PE 2.3 - Armazenar dados e resultados. PE 2.4 - Comunicar resultados.
Para atender a meta genérica do nível Gerenciado (2), o processo de Medição e
Análise deve ser institucionalizado como um processo gerenciado, e no nível Definido (3),
deve ser institucionalizado como um processo definido.
Além da área de processo Medição e Análise, o nível 4 do CMMI é fortemente
relacionado com medição através de suas duas áreas de processo: Desempenho dos
Processos Organizacionais, relacionado ao entendimento quantitativo dos processos, e
Gestão Quantitativa de Projetos, que visa utilizar o conhecimento obtido para alcançar
objetivos de qualidade e desempenho. Nesse nível, medições são usadas para monitorar os
processos sob controle estatístico e também gerenciar os projetos com informações
quantitativas. A Tabela 5 apresenta as metas e práticas associadas às áreas de processo do
nível 4.
31
Tabela 5 - Metas e práticas das áreas de processo do nível 4 CMMI.
Área de Processo Metas Específicas Práticas
Desempenho dos Processos organizacionais
Estabelecer e manter modelos e linhas de base de desempenho de processos-padrão.
• Selecionar os processos e elementos a serem incluídos na análise de desempenho;
• Estabelecer medidas de desempenho de processos;
• Estabelecer objetivos de qualidade e desempenho dos processos;
• Estabelecer modelos de desempenho de processos.
Gestão Quantitativa de Projetos
Gerenciar quantitativamente os projetos.
• Estabelecer os objetivos do projeto quanto a qualidade e desempenho do processo;
• Compor o processo a ser utilizado no projeto;
• Selecionar os subprocessos a serem geridos estaticamente;
• Gerir o desempenho do projeto, identificando ações corretivas quando necessário.
Gerenciar estatisticamente o desempenho dos subprocessos.
• Selecionar medidas e técnicas de análise;
• Aplicar métodos estatísticos para compreender variações;
• Controlar o desempenho dos subprocessos selecionados;
• Registrar dados estatísticos no repositório de dados da organização.
Com a execução dessas práticas, serão obtidos conhecimentos que irão subsidiar a
implantação de melhoria contínua e otimização dos processos, assunto principal do nível 5 de
maturidade.
2.3.2. MPS.BR.
O modelo MPS.BR – Melhoria de Processo do Software Brasileiro – vem sendo
desenvolvido desde 2003 sob a coordenação da Associação para Promoção da Excelência do
Software Brasileiro- Softex, com apoio do MCT (Ministério da Ciência e tecnologia), FINEP
(Financiadora de estudos e Projetos) e BID (Banco Interamericano de Desenvolvimento).
O objetivo do MPS.BR é definir um modelo de melhoria e avaliação de processos de
software com custo de implantação acessível à industria de software brasileira, especialmente
as micro, pequenas e médias empresas, de modo que atenda sua necessidades de negócio e
viabilize a inserção das empresas no mercado internacional [44].
O MPS.BR é baseado nos conceitos de maturidade e capacidade de processo para
avaliação e melhoria de produtos de software e serviços. Como mostra a Figura 5, o MPS.BR
possui três componente - o Modelo de Referência (MR-MPS), o Método de Avaliação (MA-
32
MPS) e o Modelo de Negócio (MN-MPS) - que descrevem o MPS.BR através de documentos
em formato de guias, que são:
• Guia Geral: descreve de modo geral o modelo MPS.BR e detalha o MR-MPS
apresentando as definições dos níveis de maturidade, processos e atributos do
processo, e os requisitos que devem ser atendidos.
• Guia de Implementação: é composto por sete guias que descrevem como
implementar cada nível de maturidade do modelo.
• Guia de Aquisição: descreve um processo para a condução de compras de
software e serviços correlatos, de forma a apoiar organizações que queiram
adquirir software e serviços correlatos apoiando-se no MR-MPS.
• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos de avaliação, métodos e formulários de apoio à avaliação.
Figura 5 - Componentes do MPS.BR [44].
Visando obter reconhecimento internacional, o MPS.BR foi desenvolvido para ser
aderente a normas e modelos internacionais. A base técnica do MPS.BR é composta pelas
normas NBR ISO/IEC 12207 – Processo de Ciclo de Vida de Software, pelas emendas 1 e 2
da norma internacional ISO/IEC 12207 e pela ISO/IEC 15504 – Avaliação de Processo,
estando portanto em conformidade com esses modelos. O MPS.BR também é aderente ao
CMMI, cobrindo seu conteúdo através da inclusão de processos e resultados de processos em
relação aos processos da norma NBR ISO/IEC 12207.
O MPS.BR define níveis de maturidade que são uma combinação ente processos e
sua capacidade. A capacidade diz respeito à habilidade do processo para alcançar os objetivos
33
de negócio atuais e futuros, e está relacionada com o atendimento a atributos de processo
definidos em cada nível de maturidade para os processos. São definidos 7 níveis de
maturidade no MR.MPS: A (em otimização), B (Gerenciado Quantitativamente), C
(Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G
(Parcialmente Gerenciado). A escala de maturidade inicia no nível G e progride até o nível A.
Para cada um dos níveis de maturidade foi atribuído um perfil de processos e de
capacidade de processos que direcionam os esforços da organização na busca de melhorias. O
atendimento a um determinado nível de maturidade é obtido quando todos os resultados do
processo e atributos de processos relacionados ao nível em questão e aos níveis anteriores são
atendidos.
São definidos 22 processos categorizados como Fundamentais, Organizacionais e de
Apoio. A Tabela 6 lista os processos do MPS.Br distribuídos nos 7 níveis de maturidade.
Tabela 6 - Níveis de Maturidade do MR-MPS.
Nível Processo
A (mais alto) Análise de Causas de Problemas e Resolução
B Gerência de Projetos (evolução)
C
Gerência de Riscos Desenvolvimento para Reutilização
Análise de Decisão e Resolução
Gerência de Reutilização (evolução)
D
Verificação
Validação Projeto e Construção do Produto
Integração do Produto Desenvolvimento de Requisitos
E
Gerência de Projetos (evolução) Gerência de Reutilização
Gerência de Recursos Humanos
Definição do Processo Organizacional Avaliação e Melhoria do Processo Organizacional
F
Medição Garantia de Qualidade
Gerência de Configuração
Aquisição
G Gerência de Requisitos
Gerência de Projetos
34
No MR-MPS, Medição (MED) é um processo de apoio definido no nível F cujo
propósito é “coletar e analisar os dados relativos aos produtos desenvolvidos e aos processos
implementados na organização e em seus projetos, de forma a apoiar os objetivos
organizacionais” [45]. Portanto, o principal foco da medição é apoiar tomada de decisões
relacionadas a produtos, processos e atendimento de metas da organização. No nível F, são
esperados 7 resultados para o processo de Medição:
MED1 - Objetivos e atividades de medição são estabelecidos a partir das
necessidades de informação e objetivos da organização.
As necessidades de informação podem ser derivadas de objetivos de negócio da
organização e/ou da legislação e dos objetivos do produto e do processo. Geralmente,
necessidades de informação são definidas pelos dirigentes da organização e dos
processos técnicos e gerenciais. Principalmente no início da implantação do
processo, as necessidades devem ser priorizadas para que o processo inicie com
pequenas medições e então evolua de forma consistente e útil.
Os objetivos de medição devem especificar os propósitos das medições e análises e
os tipos de ações que podem ser tomadas a partir das análises dos dados. Tais
objetivos podem ser restringidos pelos processos existentes, recursos disponíveis ou
outras considerações de medições.
Recomenda-se o uso de um processo de medição, como por exemplo o GQM.
MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de
medição, é identificado e/ou definido, priorizado, documentado, revisado e
atualizado.
Medidas são selecionadas para satisfazer os objetivos de medição definidos, e devem
ser documentadas contendo nome, descrição, unidade de medida e sua relação com
os objetivos de medição. As medidas selecionadas devem ser constantemente
revisadas com a gerência de alto nível para verificar se satisfazem as necessidades de
informação e objetivos de medição.
35
MED3 - Os procedimentos para a coleta e o armazenamento de medidas são
especificados.
Para cada medida selecionada, devem ser documentados os procedimentos de coleta
e armazenamento dos dados, incluindo responsabilidades, ferramentas e freqüência
de coleta. No nível F não é obrigatório o uso de um repositório para as medições,
mas caso exista, deve ser definido em termos de localização, procedimentos de
inserção e de acesso aos dados, incluindo permissões e responsabilidades.
MED4 - Os procedimentos para a análise da medição realizada são
especificados.
As atividades de análise das medições devem ser documentadas para cada medida
selecionada, incluindo responsabilidades, freqüência, fase, dados de origem,
ferramenta, verificações e informações sobre como os resultados serão comunicados.
MED5 - Os dados requeridos são coletados e analisados.
Os dados devem ser coletados e analisados conforme definido em MED3 e MED4.
A interpretação dos resultados deve levar em conta o contexto em que os dados
foram coletados, permitindo que conclusões e futuras comparações ente dados da
mesma natureza sejam feitas devidamente.
MED6 - Os dados e os resultados de análises são armazenados.
Dados de medições, especificações, resultados de análises, indicadores,
interpretações e informações necessárias de contexto devem ser armazenados para
uso futuro. Geralmente as informações armazenadas incluem planos de medição,
especificação de medidas, conjunto de dados coletados e relatórios de análises e
apresentação.
MED7 - As informações produzidas são usadas para apoiar decisões e para
fornecer uma base objetiva para comunicação aos interessados.
As informações geradas - principalmente indicadores e suas interpretações - devem
ser comunicadas aos interessados de forma a apoiar tomada de decisão. A
comunicação deve ser feita de forma clara, concisa e adequada aos perfis dos
interessados e usuários da medição, além estar claramente relacionada com os
objetivos de medição para facilitar sua utilização.
36
Nos níveis mais altos de maturidade do modelo (B e A), os resultados de medição
devem apoiar a previsão de tendências de qualidade para planejamento e tomada de ações.
2.4. AUTOMAÇÃO DO PROCESSO DE SOFTWARE E O AMBIENTE
WEBAPSEE
Apesar dos processos de software fornecerem uma visão mais organizada das etapas
e elementos envolvidos no desenvolvimento, o gerenciamento manual de um processo tornou-
se uma atividade árdua, principalmente quando se considera a quantidade e variedade de
indicadores que precisam ser coletados como evidência do aumento da qualidade e
maturidade do processo, como exigido pelos modelos MPS.BR e CMMI. Nesse cenário, a
área de pesquisa Tecnologia de Processo de Software surgiu na Engenharia de Software,
objetivando o estudo e desenvolvimento de ferramentas para automação do gerenciamento do
processo de software [37].
Constituindo um dos resultados mais promissores dessa área de pesquisa, Ambientes
de Desenvolvimento de Software Centrados em Processos (PSEE - Process-Centered
Software Engineering Environment) [11] são ferramentas desenvolvidas para prover
automação no gerenciamento do ciclo de vida de processos, com potencial de fornecer apoio
para análise, modelagem, simulação, execução e reutilização de processos.
Para permitir a modelagem de processos, um PSEE deve possuir em seu mecanismo
uma linguagem de modelagem de processos (PML – Process Modelling Language). PMLs
são linguagens específicas de programação voltadas para a definição e automação de
processos de software, devendo portanto oferecer recursos para definir e manipular as
atividades do processo.
O WebAPSEE é um ambiente para automação do gerenciamento de processos de
software baseado em Software Livre cujo desenvolvimento é mantido pelo Laboratório de
Engenharia de Software da Universidade Federal do Pará. A versão atual do ambiente serve
como base de integração para um número de meta-modelos de apoio à simulação,
instanciação, execução, melhoria e reuso de processos [28][30].
O meta-modelo do WebAPSEE é fundamentado em um paradigma baseado em
atividades, descrevendo um processo como uma coleção parcialmente ordenada de atividades
e é composto por mais de 150 classes. Uma descrição detalhada deste meta-modelo pode ser
encontrada em [30]e [47].
37
O ambiente dispõe de uma linguagem de modelagem de processo denominada
WebAPSEE-PML que fornece representação gráfica para os construtores da linguagem
proposta. Possui ainda um conjunto dinâmico de mecanismos que fornece sincronização
flexível através de conexões de atividades.
A Figura 6 resume a representação gráfica da WebAPSEE-PML. As atividades do
processo podem ser modeladas como atividades Normais, Automáticas e Decompostas (que
se decompõem em outras atividades). Atividades são executadas por Agentes ou Grupo de
agentes, produzem e recebem como entrada Artefatos e podem consumir Recursos. As
Conexões denotam controle de fluxo entre as atividades.
Figura 6 - Representação gráfica para as principais construções da WebAPSEE-PML.
O WebAPSEE oferece também apoio para gerência flexível de processos através do
suporte à modificação dinâmica, permitindo adição, remoção e alteração de atividades,
recursos e pessoas após o início da execução do processo sem que este se torne inconsistente.
Como pode ser visto na Figura 7, o WebAPSEE provê separação explícita de
interesses do gerente e dos desenvolvedores em um processo. Através de sua tela específica
(WebAPSEE-Manager – que mostra um processo exemplo em execução), o gerente modela e
acompanha a execução de processos, tratando de informações sobre o Projeto, o Ambiente, o
Processo em si, as Pessoas, os Artefatos, os Recursos e as Políticas [30]. O desenvolvedor
controla suas tarefas através da agenda de tarefas (denominada Task Agenda), podendo
iniciar, pausar, finalizar ou delegar uma tarefa, além ter acesso a funcionalidades para obter e
submeter atualizações aos artefatos de software do processo em execução.
38
Figura 7 - Visão do Gerente e do Desenvolvedor no WebAPSEE.
Em relação ao apoio à medição e análise, convêm destacar a existência de um pacote
de classes denominado ProcessKnowledge, que exerce o papel de base para definição, registro
e estimativas de métricas dos projetos executados no ambiente [32].
Uma métrica pode ser definida no ambiente WebAPSEE como pertencente a um
artefato, um processo, uma atividade, um recurso, um agente, um grupo de agentes ou à
organização. É possível especificar mais de uma unidade de medida para uma métrica, como
por exemplo para a métrica “Tamanho”, que pode ser medida em “linhas de código”, “pontos
por função” ou outra unidade escolhida livremente pelo gerente. O ambiente permite também
que se defina um intervalo válido para valores de uma métrica, e que sejam registradas
informações úteis sobre o método que deve ser utilizado para coletar a métrica. O gerente
também é responsável por estimar e coletar as métricas, indicando o valor e a unidade, e no
caso específico de coleta, o período de medição.
Visão do Gerente Visão do Desenvolvedor
39
2.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO.
Para cumprir seus objetivos com sucesso, um processo de software deve ser
gerenciado com práticas baseadas em informações que possam subsidiar e justificar tomada
de decisões. Nesse contexto, medição é uma infra-estrutura necessária para se desenvolver
uma disciplina madura de Engenharia de Software [40].
Este capítulo apresentou conceitos relacionados à medição, e quais benefícios podem
ser obtidos ao se gerenciar processos de software usando medições. Também foram descritas
abordagens para medição de processos de software, com ênfase para as abordagens orientadas
a objetivos.
Foram apresentados os modelos CMMI e o MPS.BR para implantação de melhorias
e avaliação de qualidade de processos de software, destacando como esses modelos
recomendam o uso de processos de medição como apoio para alcançar níveis elevados de
qualidade.
Por fim, foi descrita a área Tecnologia de Processos de Software e, por serem um dos
seus resultados mais promissores, foram apresentados conceitos relacionados à Ambientes de
Desenvolvimento Centrados Processos, com atenção especial para o PSEE em que a proposta
desta dissertação foi aplicada: o ambiente WebAPSEE.
40
CAPÍTULO 3
ABORDAGEM DE MEDIÇÃO PARA PROCESSOS DE SOFTWARE
A Medição de processos de software é uma atividade fundamental para alcançar
níveis mais altos de qualidade no desenvolvimento de software. Apesar de ser possível coletar
métricas independentemente do uso de um processo de medição [10], não existe um conjunto
de métricas que seja adequado e útil a todas as organizações existentes e seus processos de
software.
De acordo com [34], o desafio da medição é identificar quais atributos devem ser
coletados para gerar visões úteis das entidades que necessitam ser analisadas. Portanto, a meta
principal não é simplesmente medir, mas sim encontrar oportunidades de melhoria usando a
medição como auxílio ao diagnóstico e tomada de decisão, pois segundo Zubrow apud [20],
os benefícios de um processo de medição são obtidos através das ações realizadas a partir da
análise dos dados, e não da coleção de dados em si.
A proposta deste trabalho é a definição e integração de um modelo de Processo de
Medição em um ambiente automatizado de gerenciamento de processos de software, com
objetivo principal de fornecer auxílio efetivo para implantação de melhorias de qualidade
através de dados que retratem a realidade de processos executados.
O propósito do modelo de medição definido não é sugerir métricas, mas sim propor
atividades que ao serem executadas propiciem a seleção e coleta de métricas que gerem
informações úteis para a organização gerenciar seus projetos. Com isso o modelo visa auxiliar
a implantação de um ciclo de melhoria contínua de qualidade, como ilustrado na Figura 8,
onde:
• Através de atividades de medição, a organização obtém dados quantitativos acerca
de seus processos, recursos, produtos, e outros elementos que interessarem, e
assim pode construir indicadores que convertam os dados em informações úteis;
• Analisando os resultados da medição, a organização adquire conhecimento para
compreender quais são seus pontos fortes e oportunidades de melhoria;
• Com o conhecimento obtido, ações e escolhas mais adequadas podem ser tomadas
em relação aos seus recursos, métodos, tecnologias, entre outros;
41
• As ações fundamentadas nos dados quantitativos têm potencial de produzir como
resultado melhorias no alcance de metas da organização, como maior
produtividade e redução de custo. Os resultados tornam-se alvo de medições para
que o ciclo de melhoria seja contínuo.
Figura 8 - Ciclo de Melhoria Contínua de Qualidade.
O modelo de processo de medição proposto é detalhado na próxima seção, e a seção
3.2 descreve a abordagem de integração com um ambiente específico, o WebAPSEE.
3.1. MODELO DE PROCESSO DE MEDIÇÃO.
Após o levantamento e estudo de práticas recomendadas para a seleção,
planejamento e coleta de métricas em projetos de software apresentados no capítulo 2,
definiu-se como requisitos que o Processo de Medição deve:
R1 - Ser orientado pelas metas de negócio da organização;
R2 - Favorecer a comunicação e entendimento do seu propósito;
R3 - Reduzir o risco de interpretações equivocadas de seus resultados; e
R4 - Favorecer a comunicação e divulgação de seus resultados.
A partir dos requisitos, o modelo de Processo de Medição foi elaborado contendo
três atividades principais:
• Planejar Medição através da seleção de métricas a serem coletadas para atender
as necessidades de informações organizacionais sobre o alcance de suas metas.
• Executar Medição, coletando métricas conforme especificado na etapa anterior.
• Avaliar Resultados dos dados coletados.
Dados Quantitativos �Métricas de Processos, Pessoas, Recursos, e outros �Indicadores.
Compreensão �Pontos fortes. �Oportunidades de melhoria.
Programas �Pessoal �Métodos/Técnicas �Tecnologia �Ambiente
Melhorias �Produtividade �Qualidade �Satisfação do Cliente �Custo, etc.
Medição
Análise
Ações
Resultados
42
A Figura 9 ilustra as etapas do processo e seus artefatos segundo a notação do
WebAPSEE. O resultado da etapa de planejamento é um Plano de Medição e Análise a ser
aplicado na etapa de execução, que através da coleta de métricas possibilita a criação de
indicadores dos resultados. Os indicadores são analisados na etapa Avaliar Resultados, e são
divulgados através de Relatórios Gerenciais.
Figura 9 - Modelo de Processo de Medição proposto.
As próximas seções apresentam detalhadamente cada uma das etapas do processo.
3.1.1. Planejar Medição.
O planejamento da implementação de medição tem como atividade principal a
seleção das métricas que serão coletadas, o que deve ser feito de acordo com as necessidades
de informações da organização e de cada projeto. Para elaborar a etapa de planejamento,
tomou-se como base os paradigmas GQM [1], GQ(I)M [34], e modelos de medição seguidos
por organizações de desenvolvimento de software com certificação de qualidade CMMI,
como por exemplo a empresa Motorola [10]. As seguintes atividades foram então definidas:
1. Identificar Metas de Negócio;
2. Identificar Metas de Medição;
3. Identificar Questões Quantitativas;
4. Identificar Indicadores que ajudem a responder as questões;
43
5. Identificar Métricas necessárias para a construção dos indicadores; e
6. Elaborar Relatórios Gerenciais dos resultados.
Conforme o requisito R1, a identificação de Metas de Negócio consiste em enumerar
metas que direcionem as estratégias e esforços da organização como um todo, incluindo seus
possíveis departamentos e unidades de trabalho. A Tabela 7 apresenta alguns exemplos de
metas de negócio.
Tabela 7 – Exemplo de Metas de Negócio.
Metas de Negócio
Produzir software de qualidade.
Melhorar a produtividade.
Satisfazer o cliente.
Cumprir os compromissos de prazo e custo assumidos.
Metas de Medição traduzem as Metas de Negócio em objetivos específicos para
medição [34]. Em atendimento aos requisitos R2 e R3, a definição de uma Meta de Medição
deve auxiliar a compreensão uniforme dos propósitos da medição, e por conseqüência,
facilitar a análise correta dos resultados. Para tanto, sua definição deve conter o objeto de
interesse para a medição (como por exemplo, um artefato), indicar o propósito da medição
(como caracterizar, avaliar, analisar algum atributo do objeto de interesse devido a objetivos
como controlar, compreender, planejar, entre outros), sobre qual ponto-de-vista é adotado
(ex.: gerência, desenvolvedores, clientes), além de fornecer eventuais fatores e dados
contextuais necessários para análise e compreensão dos resultados. Alguns exemplos de metas
de medição são listados na Tabela 8.
Tabela 8 – Exemplo de Metas de Medição.
Metas de Medição
Analisar a taxa de defeitos detectados no produto como forma de aferir sua qualidade, sob o ponto-de-vista do cliente.
Conhecer o tamanho de cada artefato desenvolvido e o esforço necessário para produzi-lo, com o objetivo de manter uma base de dados históricos sobre produtividade e permitir a normalização dos demais dados coletados, sob a visão da gerência.
Analisar o erro das estimativas com o objetivo de conhecer sua acurácia e identificar oportunidades para melhorá-la, de acordo com o ponto-de-vista dos gerentes.
44
As Metas de Medição geram Questões quantitativas, que especificam diretamente as
necessidades de informação, facilitam o entendimento da razão pela qual as medidas são
coletadas e direcionam a interpretação dos resultados. A Tabela 9 mostra alguns exemplos de
Questões.
Tabela 9 – Exemplo de Questões.
Questões
Qual a produtividade observada em cada projeto de desenvolvimento?
Qual o esforço gasto para o desenvolvimento de cada artefato?
Qual o desvio das estimativas (esforço, prazo, tamanho) realizadas no planejamento dos projetos, comparando-se os valores estimados e obtidos?
Qual a evolução da taxa de erros em estimativas em cada projeto?
As Questões são respondidas com auxílio de Indicadores gráficos que fornecem
informações consolidadas através dos valores de uma ou mais Métricas. Os Indicadores
devem ser planejados para favorecer a compreensão dos resultados por quem os visualiza
(requisitos R2 e R3), por isso a definição de um indicador deve incluir sua descrição e
informações sobre procedimentos de análise, como mostra a definição de um indicador de
exemplo na Tabela 10.
45
Tabela 10 – Exemplo de definição de um Indicador.
Indicador
Identificação: Desvio de Tamanho do Projeto.
Métrica: Tamanho do Projeto Formato: Tabela
Descrição: Mostra lado a lado a primeira estimativa de tamanho, a última estimava e o tamanho final, apresentando os desvios entre os valores.
Procedimento de Análise:
Idealmente o desvio deve ser zero, indicando que provavelmente o escopo do projeto foi bem definido e a técnica de estimativa aplicada foi precisa, mas pequenos desvios são aceitáveis e não devem ser considerados problemas.
O desvio negativo significa que o tamanho estimado foi maior que o tamanho real final, fazendo com que esforço e custo fossem estimados além do que deveriam, ou seja, recursos foram alocados e/ou adquiridos desnecessariamente.
O desvio positivo significa que o tamanho estimado foi menor que o tamanho real final, o que pode causar prejuízos já que todas as demais estimativas provavelmente serão calculadas com valor menor.
Se não houve alterações no escopo do projeto, grandes desvios podem indicar ineficiência da técnica de estimativa escolhida, pouca experiência do estimador ou alto índice de reuso no projeto.
Identificar o motivo do desvio é importante para que a causa seja evitada nos próximos projetos.
Ao se identificar as métricas necessárias para construir os indicadores,
conseqüentemente identifica-se o que vai ser medido, visto que uma métrica é relacionada a
um atributo de um determinado elemento. A especificação da métrica deve conter sua
descrição, unidade de medida e também informações sobre procedimentos de coleta.
A última etapa do planejamento é a elaboração de Relatórios Gerenciais para prover
informações úteis à gerência em tempo hábil, como forma de auxílio ao acompanhamento e
avaliação dos projetos além de possíveis tomadas de decisão (requisito R4). Os relatórios
devem ser elaborados a partir das necessidades de informações identificadas nas etapas
anteriores e podem ou não conter os resultados da etapa de avaliação da medição.
A Figura 10 apresenta as atividades definidas para o planejamento de medição
modeladas no ambiente WebAPSEE. As conexões do tipo end-end entre as atividades
permitem que elas ocorram em paralelo, porém só podem finalizar após o término da
atividade origem da conexão. Esse tipo de conexão foi escolhido porque, a partir da atividade
Identificar Metas de Medição, cada atividade deriva seus resultados a partir do que foi
identificado na atividade anterior.
46
Figura 10 - Modelagem das atividades da etapa Planejar Medição.
Segundo o modelo da Figura 10 as atividades são realizadas por um Grupo de
Medição da organização juntamente com o Gerente do Projeto, exceto na atividade Identificar
Métricas. Para iniciar a primeira atividade (Identificar Metas de Negócio) o artefato Plano de
Medição e Análise foi modelado como artefato de entrada devido à possibilidade de
disponibilizar templates dos artefatos a serem produzidos. Assim, todas as atividades
atualizam o artefato Plano de Medição e Análise que, após o término da etapa de
planejamento, irá guiar a etapa Executar Medição.
O relacionamento entre metas de negócio, metas de medição, questões, indicadores e
métricas é exemplificado na Figura 11. Uma meta de medição pode estar relacionada a mais
de uma meta de negócio e o mesmo ocorre entre questões e metas de medição, indicadores e
questões, e métricas e indicadores. A meta de medição G1 do exemplo está relacionada com
as metas de negócio B1 e B2, que também compartilha a meta G2 com B3. Dessa forma,
alterações em qualquer um dos elementos do modelo afetarão a meta de negócio B2. A
implementação do modelo deve garantir a rastreabilidade e propagação de alterações entre os
elementos.
47
Indicadores
Metas de Medição G1 G2
Q1 Q2 Q3 Q4
M1 M2 M3 M4 M5 M6
Questões
Métricas
Metas de Negócio
I1 I2 I3 I4 I5
B1 B2 B3
Figura 11 - Exemplo de relacionamento entre Metas de Negócio, de Medição, Questões, Indicadores e Métricas.
3.1.2. Executar Medição.
Nesta etapa as métricas são estimadas e coletadas ao longo da execução do projeto e
de acordo com o que foi definido no Plano de Medição. Novas metas e questões ainda podem
surgir, causando alterações no Plano de Medição. À medida que os dados forem coletados,
Indicadores e Relatórios podem ser gerados para informar seus resultados à Gerência.
3.1.3. Avaliar Resultados.
A avaliação da medição consiste em analisar os Indicadores gerados conforme o
procedimento de análise especificado e, a partir da análise, identificar lições aprendidas que
devam ser consideradas nas etapas posteriores do projeto e até mesmo em outros projetos.
Caso seja necessário, o relato de lições aprendidas deve ser acompanhado de observações de
contexto para melhor compreensão de quando e como devem ser aplicadas. A comunicação e
divulgação da avaliação dos resultados devem ser feitas com o auxílio dos Relatórios
Gerenciais elaborados no plano de medição.
A Figura 12 um exemplo detalhado de processo para a etapa Avaliar Resultados. A
etapa inicia com atividade “Analisar Indicadores de Resultados”, executada por um agente
gerente do projeto auxiliado pelo Grupo de Medição da organização. Essa atividade recebe
como entrada tanto os Indicadores dos resultados coletados no processo de software quanto o
Plano de Medição e Análise que é necessário para contextualizar e guiar a análise dos
indicadores.
Assim que inicia a análise dos Indicadores pode-se gerar relatórios para divulgação dos
resultados, por isso a conexão de transição entre as atividades da Figura 12 é do tipo start-
start. A atividade “Preparar e divulgar Relatórios Gerenciais” tem como artefato de entrada
além dos indicadores o Plano de Medição e Análise do projeto, e gera como saída os
Relatórios Gerenciais.
48
Figura 12 - Modelagem das atividades da etapa Avaliar Resultados.
3.2. INTEGRAÇÃO DO MODELO DE PROCESSO DE MEDIÇÃO NO
AMBIENTE WEBAPSEE.
Definir e executar medições em processos sem auxílio de ferramenta pode ser uma
atividade difícil, tediosa e passível de erros e dificuldades, como por exemplo, dificuldade em
analisar as métricas, pois nem sempre quem analisa participou do planejamento da medição e
a recuperação da definição das métricas pode ser complicada sem ferramentas disponíveis.
Pode haver também dificuldade em reutilizar os dados coletados, pois normalmente são
especificados no seu plano de medição correspondente, que não descreve o processo de
software que foi medido ou o descreve informalmente, dificultando descobrir se um
determinado dado pode ser usado em outro projeto. O mesmo problema se aplica aos planos
de medição, pois sem a definição do processo fica difícil saber que plano de medição, ou
partes dele, pode ser reutilizado em processos futuros.
Além de minimizar as dificuldades citadas acima, a integração de uma ferramenta de
apoio ao processo de medição proposto no ambiente WebAPSEE tem como objetivo principal
explorar a possibilidade de interação e sinergia proporcionadas por um ambiente que mantém
o registro da execução dos processos.
Apesar do primeiro nível para implantação de medições ser o de processos de
software, existem necessidades de informações em níveis mais altos do gerenciamento
organizacional, geralmente referentes a atributos da Organização e seus processos. Para
49
atender a essa necessidade, foram definidos dois domínios para a abordagem de medição no
WebAPSEE : o Domínio de Processo e o Domínio Organizacional, como mostra a Figura 13.
Figura 13 - Domínios de Medição no WebAPSEE.
Medição no Domínio de Processo de software é realizada em relação a seus
atributos, como prazo e custo, e atributos de seus componentes, que no ambiente WebAPSEE
podem ser atividades, agentes, grupos de agentes, artefatos e recursos. No Domínio
Organizacional, medição refere-se a atributos da organização e também dos seus processos
executados, com objetivo de possibilitar análise comparativa entre os processos.
Como requisito para a integração do planejamento de medição e análise no
WebAPSEE, foi determinado que não deveria acrescentar mais complexidade na modelagem
dos processos de software. Definiu-se então que o planejamento da medição deve ser feito
separadamente da definição de processos, especificando o quê e como componentes
modelados no WebAPSEE serão medidos. A abordagem de integração do modelo de processo
de medição com o WebAPSEE é apresentada em detalhes nas seções a seguir para cada um
dos domínios definidos, respectivamente. Para manter uniformidade com a documentação do
ambiente, os termos usados na descrição do meta-modelo são escritos em inglês.
3.2.1. Medição no Domínio de Processos.
No domínio de processos de software, o processo de medição ocorre conforme ilustrado
na Figura 14, que mostra as etapas definidas (Planejar Medição, Executar Medição e Avaliar
Resultados) e os elementos de ligação entre elas.
Atividades Agentes Grupos de Agentes Artefatos Recursos
Processo de Software
Organização
Medição
Processos
Domínio de Processo Domínio Organizacional
50
Figura 14 - Medição no domínio de Processos de Software.
Conforme descrito anteriormente, na etapa Planejar Medição define-se um Plano de
Medição que irá guiar a execução. Para reduzir o esforço gasto na etapa de planejamento de
medição em cada projeto de desenvolvimento de software, foi elaborado o conceito de
Modelo de Plano de Implementação de Medição (MIPModel – Measurement
Implementation Plan Model, representado pelo elemento 1 na Figura 14), que especifica um
plano-padrão de medição passível de ser executado em processos de software.
A partir dos objetivos da organização, o gerente pode definir um MIPModel a ser
aplicado em qualquer processo, ou caso a organização possua processos-padrão definidos,
especificar modelos de medição de acordo com características de cada processo-padrão, como
por exemplo, processo para projetos simples, projetos de manutenção, projetos complexos,
entre outros.
Seguindo o que foi especificado para a etapa Planejar Medição, a definição de
MIPModel é feita através da identificação de Metas de Negócio, de Medição, Questões,
Indicadores e Relatórios Gerenciais. Como um MIPModel não está relacionado a um processo
real em execução, seus indicadores não podem especificar quais elementos serão medidos
para que possa ser gerado, mas devem definir que tipo de elemento tem como alvo
(atividades, agentes, grupos de agentes, recursos, artefatos ou o próprio processo), e a(s)
métrica(s) necessária(s).
As atividades de medição a serem executadas em um processo de software específico
são definidas em seu Plano de Implementação de Medição (MIP – Measurement
Implementation Plan, ilustrado na Figura 14 pelo elemento 2), que é gerado a partir de um
MIPModel selecionado pelo gerente. Dessa forma, assegura-se que o processo de medição
seja aderente às definições organizacionais, mas para atender necessidades e características
Processos-Padrão de Software
Modelos de Plano de Implementação de
Medição
Processo Plano de Implementação de
Medição
6 0 , 8
6 , 41 7 , 8
8 5 2 001 02 03 04 05 06 07 08 09 0
1 0 0
W a i t i n gR e a d yA c t i v eP a u s e dF i n i s h e dC a n c e l l e dF a i l e d
Objetivos Organizacionais
Relatórios dos Resultados
Indicadores
Planejar Medição Executar Medição Avaliar Resultados
1
2
3
51
especificas do projeto, o MIP de um processo pode ser adaptado com a inserção de novos
elementos (Metas de Negócio, de Medição, Questões, Indicadores e Relatórios). Porém, de
forma similar ao conceito de herança no paradigma de Orientação a Objetos, os elementos que
constam no MIPModel que gerou o MIP não podem ser alterados ou removidos.
Após criar o Plano de Implementação de Medição de um determinado processo, o
gerente deve finalizar a configuração dos indicadores selecionando quais elementos do
processo serão medidos, conforme o tipo de elemento definido no indicador. Como exemplo,
se o elemento alvo do indicador foi definido como artefatos, o gerente deve selecionar quais
artefatos do processo serão medidos. Portanto, a integração de um MIP com um processo de
software é feita através da seleção explícita dos elementos do processo que precisam ser
medidos para gerar os indicadores.
Com os indicadores configurados, o Plano de Implementação de Medição está pronto
para ser usado na etapa Executar Medição. Nesta etapa, as estimativas e coleta de métricas são
realizadas usufruindo da estrutura já existente no pacote ProcessKnowledge, apresentado no
capítulo anterior, mas com a integração da abordagem proposta as métricas específicas a
serem estimadas e coletadas em um processo são as definidas em seu Plano de Implementação
de Medição. A maioria das métricas é coletada pelo gerente de projeto, com exceção de
métricas relativas aos artefatos, que podem ser coletadas pelos próprios desenvolvedores.
À medida que o processo de software é executado, as métricas requeridas pelo seu
MIP são coletadas e indicadores podem ser gerados, como representa o elemento 3 na Figura
14. Com indicadores disponíveis, a etapa Avaliar Resultados pode ser iniciada mesmo antes
do processo de desenvolvimento finalizar.
De acordo com o que foi especificado para a etapa de avaliação na seção 3.1.3, os
indicadores devem ser analisados e lições aprendidas devem ser registradas, além de eventuais
informações de contexto necessárias para compreender os resultados. A análise dos
indicadores é divulgada para a gerência através dos Relatórios Gerenciais configurados.
3.2.2. Medição no Domínio Organizacional.
Medição no nível organizacional tem como objetivo de suprir necessidades de
informação em níveis de gerência acima do nível de projeto. Como exemplo, gerentes de
recursos humanos podem se preocupar com a porcentagem de pessoas da organização
treinadas nos processos e técnicas institucionalizadas, gerentes de negócio precisam monitorar
prazos de diversos projetos e avaliar impactos gerados por possíveis atrasos, gerentes de
52
processos avaliam a eficácia dos processos organizacionais e a aderência dos projetos a eles,
entre outros.
Considerando esses requisitos, a implementação no domínio organizacional da
abordagem de medição proposta deve apoiar não só a coleta de métricas de atributos da
organização, mas também deve auxiliar a análise comparativa de métricas de processos
executados. A Figura 15 ilustra as etapas da abordagem proposta no domínio organizacional.
Figura 15 - Medição no domínio Organizacional.
De acordo com o modelo adotado, a partir dos objetivos organizacionais o Plano de
Implementação de Medição Organizacional (OrgMIP – Organizational Measurement
Implementation Plan, elemento 1 da Figura 15) deve ser definido identificando-se Metas de
Negócio, Metas de Medição, Questões, Indicadores e Relatórios específicos para o nível
organizacional. O OrgMIP direciona a coleta de métricas na etapa Executar Medição através
das métricas requeridas pelos seus indicadores, que diferente dos indicadores gerados no
domínio de processos, podem ser relacionados apenas com métricas da organização ou de
processos.
Indicadores no domínio organizacional subsistem enquanto seus resultados
representarem informação útil para a organização, portanto acumulam resultados que podem
ser analisados na etapa Avaliar Resultados em várias ocasiões ao longo de seus ciclos de vida.
Um exemplo é um indicador que mostre o desvio do prazo de dois ou mais processos em
relação às suas estimativas, por ordem de execução, permitindo analisar ao longo do tempo a
evolução da capacidade e maturidade da organização em estimar e cumprir prazos. A Figura
16 ilustra o exemplo dado com processos fictícios (identificados como P1, P2, ..., a P8).
6 0 , 8
6 , 41 7 , 8
8 5 2 001 02 03 04 05 06 07 08 09 0
1 0 0
W a i t i n gR e a d yA c t i v eP a u s e dF i n i s h e dC a n c e l l e dF a i l e d
Indicadores Organizacionais e Comparativos de Processos
Relatório dos Resultados
Plano de Implementação de Medição Organizacional
Processos Objetivos
Organizacionais
Organização
Planejar Medição Executar Medição Avaliar Resultados
1
2
53
Figura 16 - Indicador Índice de Desvio de Prazos de Projetos
3.2.3. Proposta de ferramenta de apoio ao Processo de Medição no WebAPSEE.
Para possibilitar a integração do modelo processo de medição proposto no ambiente
WebAPSEE, foi necessário projetar uma ferramenta que fosse acoplada como um módulo no
ambiente, além de implementar algumas alterações no próprio ambiente. O propósito da
ferramenta é apoiar as etapas Planejar Medição e Avaliar Resultados, tanto no Domínio de
Processos como no Domínio Organizacional. Portanto, são requisitos da ferramenta:
F1 - Viabilizar a execução do Processo de Medição nos domínios de processos e
organizacional, permitindo a definição de MIPModels, MIPs e OrgMIPs, a
integração de cada um deles com as entidades definidas no ambiente e a análise
de seus resultados;
F2 - Permitir a evolução de MIPModels sem que seus MIPs derivados percam
informações;
F3 - Permitir adaptação do MIP de um processo sem alteração das metas de negócio,
de medição, questões, indicadores e relatório gerenciais definidos no
MIPModel de origem, assim como os relacionamentos entre esses elementos;
F4 - Manter a rastreabilidade entre os elementos definidos para cada MIPModel,
MIP e OrgMIP, e propagar eventuais alterações;
F5 - Gerar os Indicadores gráficos e Relatórios Gerenciais definidos.
A Figura 17 apresenta o diagrama de casos de uso com as funcionalidades principais
da ferramenta proposta, seguida da descrição sucinta de cada caso de uso.
0
10
20
30
P1 P2 P3 P4 P5 P6 P7 P8
Índ
ice
(%)
Projetos
Índice de Desvio de Prazos de Projetos
54
Figura 17 - Diagrama de contexto da ferramenta proposta.
O caso de uso Gerenciar MIPModels provê funcionalidades para criar e atualizar
modelos de Plano de Implementação de Medição.
A funcionalidade de definição do plano de medição a ser seguido por um projeto é
descrita pelo caso de uso Selecionar MIP de Projeto, que deve apresentar MIPModels
disponíveis para gerar o MIP do projeto. A adaptação do MIP ao projeto é permitida pelo caso
de uso Configurar MIP de Projeto, que também viabiliza a integração do MIP com o
processo provendo a funcionalidade de seleção dos alvos do indicador.
Em relação ao plano de medição no Domínio Organizacional, a definição e
atualização do OrgMIP são realizadas através do caso de uso Gerenciar OrgMIP.
Para permitir o acesso e visualização dos Relatórios Gerenciais com os resultados da
medição e análise, o caso de uso Visualizar Relatórios Gerenciais deve ser implementado na
ferramenta. Por fim, relatórios de propósito geral devem ser disponíveis conforme o caso de
uso Visualizar Relatórios Gerais.
A relação existente entre os casos de uso e os requisitos identificados neste trabalho,
tanto para o processo quanto para a ferramenta, é mostrada na Tabela 11.
55
Tabela 11 - Casos de uso principais e requisitos relacionados.
Id Caso de Uso Requisitos Relacionados
UC1 Gerenciar MIPModels F1, F2, F4
UC2 Selecionar MIP de projeto F1
UC3 Configurar MIP F1, F3, F4
UC4 Gerenciar OrgMIP F1, F4
UC5 Analisar Medição F1, F5
UC6 Visualizar Relatórios Gerenciais R4, F5
UC7 Visualizar Relatórios Gerais R2, F5
Em relação à etapa Executar Medição, definiu-se que ela seria integrada na estrutura
já existente do WebAPSEE. Como mostra a Figura 18, o gerente pode estimar e coletar
métricas através do componente Manager Console, cujos formulários de estimativa e coleta
foram modificados para interagir com o MIP do projeto. Para descentralizar o esforço de
coleta, sugeriu-se também a inclusão de um formulário de coleta na agenda do desenvolvedor
para que colete métricas dos artefatos que desenvolver, também conforme definido no MIP do
projeto.
Figura 18 - Casos de uso da etapa Executar Medição no WebAPSEE.
3.3. CONSIDERAÇÕES FINAIS DO CAPÍTULO.
Medição em processos de software sido reconhecida pela comunidade científica
como um método eficaz e necessário para o gerenciamento e melhoria de qualidade, mas a
implantação de programas de mensuração não é uma tarefa trivial.
56
Com o objetivo de apoiar as atividades de medição em processos de software, este
capítulo apresentou uma modelo de Processo de Medição Orientado a Objetivos baseado nos
modelos GQM, GQ(I)M e em modelos usados por empresas da indústria de software.
Para prover automação no Processo de Medição proposto, definiu-se uma abordagem
de integração do processo com ambientes de gerenciamento de processos de software, sendo
escolhido o ambiente WebAPSEE para executar a integração. A abordagem foi delineada sob
dois aspectos para medição: o Domínio de Processos e o Domínio Organizacional.
Em complemento à abordagem de integração do Processo de Medição com o
WebAPSEE, apresentou-se também os requisitos e casos de uso principais para uma
ferramenta de apoio à essa integração.
57
CAPÍTULO 4
FERRAMENTA DE APOIO AO PROCESSO DE MEDIÇÃO
Durante a execução de um processo de medição como o proposto neste trabalho, as
diversas métricas identificadas no plano de medição devem ser coletadas ao longo do ciclo de
vida de um processo de desenvolvimento de software, e sem uma abordagem adequada de
armazenamento e recuperação dessas métricas é difícil utilizá-las para gerar informações úteis
em tempo hábil. O uso de uma ferramenta para automação do processo de medição tem o
potencial de beneficiar o planejamento das metas de qualidade, coleta e armazenamento dos
dados (métricas), além de facilitar a recuperação, visualização, e divulgação de resultados.
Apesar da capacidade de fornecer grande auxílio às atividades de medição, as
ferramentas tradicionalmente desenvolvidas para esse propósito não possuem registro dos
processos de software, ou necessitam que todos os componentes a serem medidos no processo
sejam cadastrados na ferramenta e atualizados sempre que o processo mudar – o que acontece
freqüentemente devido à natureza dinâmica dos processos de software.
A integração de uma ferramenta de apoio ao processo de medição com um ambiente
automatizado de desenvolvimento de software tem a vantagem de interagir com os processos
definidos e executados no ambiente, e assim formar uma base de dados única com dados de
processos de software e seus processos de medição.
Este capítulo apresenta o protótipo de ferramenta de apoio ao modelo de Processo de
Medição proposto neste trabalho. A ferramenta visa apoiar as etapas de seleção, planejamento
da coleta de métricas, análise de resultados e recuperação de informações sobre medições,
além de possibilitar a integração do processo de medição com o ciclo de vida de processos de
software executados no ambiente WebAPSEE.
Seguindo a abordagem descrita no capítulo anterior, o projeto da ferramenta foi
dividido em dois pacotes principais, relacionados com o Domínio de Processos e o Domínio
Organizacional. As seções 4.1 e 4.2 descrevem em detalhes o modelo de dados para cada um
dos pacotes, respectivamente, enquanto que a seção 4.3 apresenta o protótipo desenvolvido da
ferramenta.
estimativa e coleta já existente no WebAPSEE para
medição
seção
4.1.
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
seção
3.2.3
Além da ferramenta proposta, foram sugeridas modificações
estimativa e coleta já existente no WebAPSEE para
medição na etapa de Execução do processo de medição. Essas modificações são descritas na
seção 4.4.
4.1. MODELO DE DADOS PARA
A Figura 19
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
seção 3.2.2 do capítulo anterior e com os requisitos da ferramenta identificados na seção
3.2.3.
Figura 19 - Domínio de Processos.
Além da ferramenta proposta, foram sugeridas modificações
estimativa e coleta já existente no WebAPSEE para
na etapa de Execução do processo de medição. Essas modificações são descritas na
MODELO DE DADOS PARA
Figura 19 apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
Diagrama de classes Domínio de Processos.
Além da ferramenta proposta, foram sugeridas modificações
estimativa e coleta já existente no WebAPSEE para
na etapa de Execução do processo de medição. Essas modificações são descritas na
MODELO DE DADOS PARA
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
Diagrama de classes Domínio de Processos.
Além da ferramenta proposta, foram sugeridas modificações
estimativa e coleta já existente no WebAPSEE para
na etapa de Execução do processo de medição. Essas modificações são descritas na
MODELO DE DADOS PARA O DOMÍNIO DE PROCESS
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
Diagrama de classes para implementação do Processo de Medição no
Além da ferramenta proposta, foram sugeridas modificações
estimativa e coleta já existente no WebAPSEE para possibilitar sua
na etapa de Execução do processo de medição. Essas modificações são descritas na
O DOMÍNIO DE PROCESS
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
implementação do Processo de Medição no
Além da ferramenta proposta, foram sugeridas modificações
possibilitar sua integra
na etapa de Execução do processo de medição. Essas modificações são descritas na
O DOMÍNIO DE PROCESS
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
implementação do Processo de Medição no
Além da ferramenta proposta, foram sugeridas modificações na abordagem
integração com o pla
na etapa de Execução do processo de medição. Essas modificações são descritas na
O DOMÍNIO DE PROCESSOS.
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
implementação do Processo de Medição no
58
na abordagem de
com o plano de
na etapa de Execução do processo de medição. Essas modificações são descritas na
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
implementação do Processo de Medição no
58
de
no de
na etapa de Execução do processo de medição. Essas modificações são descritas na
apresenta o diagrama de classes desenvolvido para permitir a
implementação do Processo de Medição no Domínio de Processos, conforme especificado na
do capítulo anterior e com os requisitos da ferramenta identificados na seção
59
Um MIPModel é identificado por um nome, e além de sua descrição deve especificar
em que tipo de processo de software pode ser executado. De acordo com a definição descrita
no capítulo anterior, um MIPModel deve estar relacionado às Metas de Negócio da
organização (classe BusinesssGoal), que por si geram as Metas de Medição (instâncias da
classe MeasurementGoal).
A definição de Metas de Medição deve conter o objeto de interesse para a medição, o
propósito, sobre qual ponto-de-vista, e também dados contextuais, como por exemplo, a
indicação do domínio do problema associado. As Metas de Medição geram Questões
quantitativas (objetos da classe Question), que são respondidas com o auxilio de Indicadores
(classe Indicator).
Um Indicador do MIPModel possui um nome, informações de procedimento de
análise e tem como alvo informar dados do processo, atividades, artefatos, recursos,
desenvolvedores, ou grupo de desenvolvedores, o que é definido pelo atributo targetType. As
Métricas que o Indicador precisa para gerar informações são relacionadas a ele pela
associação com a classe MetricDefinition, que já pertencia ao meta-modelo do WebAPSEE no
pacote ProcessKnowledge.
A consolidação dos dados que serão apresentados em um indicador é feita através de
operações definidas na classe Operation. São exemplos de operações pré-definidas: o cálculo
do desvio de uma métrica em relação a suas estimativas, o cálculo da distribuição dos valores
de uma métrica em um conjunto de alvos, a razão ou qualquer outra operação entre métricas
para formação de métricas secundárias, entre outras. Definiu-se quatro formatos básicos para
um indicador ilustrar os resultados: Tabela, diagrama de Pizza, Barra e Linha. (classes Table,
Pie, Bar e Line, especializações da classe Format).
Os relacionamentos entre metas de negócio, metas de medição, questões, indicadores
e métricas de um MIPModel devem ser implementados conforme os requisitos F3 - e F4 -,
que dizem respeito à rastreabilidade entres os elementos e possibilidade de acrescentar novos
relacionamentos no plano de medição adaptado ao processo (MIP), sem modificar elementos
e relacionamentos definidos no MIPModel.
Esses requisitos constituíram um desafio para o trabalho, e demandaram esforço
significativo para elaborar uma solução que os atendesse corretamente. A solução foi definida
através do uso de conectores para relacionar os elementos entre si e identificar se pertencem
ao MIPModel ou ao MIP. Metas de negócio, metas de medição, questões e indicadores são
adicionados e relacionados no modelo através de conectores próprios (classes BG_CON,
60
MG_CON, Q_CON e I_CON, respectivamente), que são especializações da classe Connector.
Um objeto da classe Connector é relacionado exclusivamente com um MIPModel ou com um
MIP, portanto no contexto de um determinado MIPModel um elemento possui apenas um
conector responsável por todos os seus relacionamentos. Em relação às métricas, não foi
necessário o uso de conectores já que estas são selecionadas na definição dos indicadores, e
estes não podem ser alterados ou removidos no MIP.
O Plano de Implementação de Medição (classe MIP) de um Processo (classe
Process, do pacote ProcessModel no meta-modelo do WebAPSEE) é derivado a partir de um
único MIPModel, e também permite adição de novos elementos. Conforme a solução adotada,
para adicionar metas de negócio, de medição, questões ou indicadores são criados conectores
ligados aos MIP. Os elementos já pertencentes ao MIPModel podem ser adaptados ao projeto
apenas através da inclusão de novos relacionamentos, e para isso são criados para eles
conectores ligados ao MIP.
A solução com uso de conectores garante que os relacionamentos definidos no
MIPModel de origem não sejam removidos, pois basta verificar se possuem conectores
ligados ao MIPModel e se os conectores estão relacionados. Portanto, no contexto de um
MIP, uma instância de meta de negócio, meta de medição, questão ou indicador pode ter no
máximo dois conectores, um ligado ao MIP e outro ao MIPModel de origem, mas essa
solução é transparente para o usuário pois ele verá na ferramenta como um único elemento.
Para integrar o MIP com o processo, é necessário indicar quais elementos do
processo serão as entidades-alvo dos indicadores, de acordo com o que foi definido no
atributo targetType de cada indicador. Com o objetivo de diminuir o esforço gasto nessa
tarefa, foram definidos três tipos de seleção de alvos:
1. By Type: Serão disponibilizadas categorias pré-definidas para seleção, conforme o
targetType do indicador: se for do tipo “agentes”, será mostrada uma lista de cargos,
para os outros tipos de alvo serão listados seus tipos pré-definidos no ambiente1. A
Tabela 12 apresenta a listagem de categorias por tipo de alvo;
2. All: Todos os elementos do processo correspondentes com o targetType do indicador
serão medidos para gerar os resultados. Por exemplo, se o targetType for ”artefatos”,
para todo os artefatos do processo deverão ser coletadas as métricas definidas no
indicador;
1 Hierarquia de tipos default fornecida com a instalação do ambiente WebAPSEE e sujeita a especialização para uma organização de desenvolvimento de software usuária.
61
3. Selected: Elementos específicos do processo serão selecionados, conforme o
targetType do indicador.
Tabela 12 - Categoria da seleção ByType por tipo de alvo.
Tipo de Alvo Categorias para seleção ByType Significado
Agentes
Administrative Staff Equipe Administrativa
Analysts Analistas
Developers Desenvolvedores
Managers Gerentes
Production and Support Produção e Suporte
Stakeholder Parte interessada no processo.
Testers Testadores
Atividades
Coding Codificação
Design Projeto
Documentation Documentação
Engagement Request Solicitação de Compromisso
Requirements Requisitos
Testing Teste
Verification and Validation Verificação e Validação
Artefatos
Agreement Report Artifact Relatório de Acordo e Compromisso do projeto.
Architecture Design Artifact Projeto da Arquitetura
Binary Code Artifact Código binário.
Check-list Artifact Lista de Verificação e Controle
Communication Artifact Artefato de Comunicação
Glossary Artifact Glossário do projeto.
Management Artifact Artefato de Gerenciamento.
Manual Artifact Manual
Meeting Record Artifact Artefato de Registro de Reunião
Planning Artifact Artefato de Planejamento
Report Artifact Relatório
Request Artifact Artefato de Solicitação
Requirements Analysis Artifact Artefato de Análise de Requisitos.
Requirements Specification Artifact Especificação de Requisitos
Schedule Artifact Artefato de programação e agendamento
Scope Definition Artifact Artefato de Definição do escopo
Source Code Artifact Código-fonte
Test Artifact Artefato de planejamento ou execução de teste.
Vision/Proposal Artifact Artefato de Visão e/ou Proposta.
Recursos Consumable Recurso consumível
Exclusive Recurso de uso exclusivo.
Shareable Recurso compartilhável.
62
O tipo de seleção é armazenado na classe MIP_Indicator através do atributo kind.
No caso do tipo selecionado for By Type, uma ou mais categorias podem ser selecionadas e
armazenadas no atributo apseeType. Se o tipo escolhido for Selected, os elementos do
processo que forem escolhidos serão relacionados ao indicador através da classe
WebApseeObject, que armazena a identificação do objeto.
Objetos da classe MIP_Indicator armazenam também a análise do indicador (atributo
analysis), alem de registrar lições aprendidas e informações gerais que possam ter
influenciado nos resultados (atributos learnedLessons e observation, respectivamente).
Tanto no MIPModel quanto no MIP, os Relatórios Gerenciais são configurados em
relação às questões e seus indicadores através da classe Report, podendo incluir ou não os
procedimentos de análise dos indicadores, a análise em si, lições aprendidas e observações
(atributos booleanos da classe Report).
Com a execução do Processo de Medição em seus projetos, a Organização adquire
amadurecimento em medir, identifica novas metas e/ou descarta outras, e surge então a
necessidade de modificar os planos de medição institucionalizados pelos MIPModels.
Segundo o requisito F2, o modelo deve permitir a evolução de MIPModels sem que seus
MIPs previamente derivados percam informações e fiquem inconsistentes.
Para atender esse requisito foi desenvolvida uma solução baseada em versões,
adaptada do mecanismo de versionamento de templates de processos no ambiente
WebAPSEE definido em [9].
Cada vez que for necessário modificar um MIPModel, é criada uma nova versão dele
contendo a mesma estrutura, ou seja, é criada uma cópia para edição. Os MIPs gerados
anteriormente não são afetados pela edição do MIPModel porque continuam relacionados
com a versão pela qual foram gerados. Para manter a consistência do modelo, em um
determinado instante de tempo um MIPModel pode ter no máximo uma versão apta para
instanciar MIPs.
O versionamento de um MIPModel, assim como sua disponibilidade para ser
instanciado, é controlado através de seu estado (atributo state), que pode ter um dos valores
listados a seguir:
• Draft (Rascunho): É o estado inicial de um MIPModel, ou de uma nova versão.
Indica que o MIPModel está em edição, por isso as únicas operações disponíveis
são editar e salvar.
criação até chegar no e
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
MIPModels
• Defined
instanciação, ou sej
seja necessário modificar um MIPModel
versão será criada e irá substituí
• Pending
estado
• Outdated
uma versão que passou para o estado
não pode g
relacionamentos
A Figura 20
criação até chegar no e
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
MIPModels.
Defined (Definido)
instanciação, ou sej
seja necessário modificar um MIPModel
versão será criada e irá substituí
Pending (Pendente):
estado Draft, e não é permitida a criação de novas versões para ele.
Outdated (Desatualizado)
uma versão que passou para o estado
não pode gerar novas versões nem derivar MIPs de processos, mas seus
relacionamentos
Figura 20 ilustra a máq
criação até chegar no estado
Figura 20
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
(Definido): Indica que o MIPModel está estável e disponível para
instanciação, ou seja, pode gerar MIPs de processos,
seja necessário modificar um MIPModel
versão será criada e irá substituí
(Pendente): Um MIPModel no estado
e não é permitida a criação de novas versões para ele.
(Desatualizado): O MIPModel está em desuso, pois foi substituído por
uma versão que passou para o estado
erar novas versões nem derivar MIPs de processos, mas seus
relacionamentos e dos seus MIPs gerados
ilustra a máquina de estados definida para um MIPModel desde sua
do OutDated
Figura 20 - Diagrama de Estados do MIPModel
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
: Indica que o MIPModel está estável e disponível para
pode gerar MIPs de processos,
seja necessário modificar um MIPModel
versão será criada e irá substituí-lo quando estiver estável.
Um MIPModel no estado
e não é permitida a criação de novas versões para ele.
: O MIPModel está em desuso, pois foi substituído por
uma versão que passou para o estado D
erar novas versões nem derivar MIPs de processos, mas seus
e dos seus MIPs gerados
uina de estados definida para um MIPModel desde sua
OutDated.
Diagrama de Estados do MIPModel
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
: Indica que o MIPModel está estável e disponível para
pode gerar MIPs de processos,
seja necessário modificar um MIPModel que está
lo quando estiver estável.
Um MIPModel no estado
e não é permitida a criação de novas versões para ele.
: O MIPModel está em desuso, pois foi substituído por
Defined. Um MIPModel no estado
erar novas versões nem derivar MIPs de processos, mas seus
e dos seus MIPs gerados são mantidos intactos.
uina de estados definida para um MIPModel desde sua
Diagrama de Estados do MIPModel
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
: Indica que o MIPModel está estável e disponível para
pode gerar MIPs de processos, não pode ser editado
está no estado
lo quando estiver estável.
Um MIPModel no estado Pending possui uma versão no
e não é permitida a criação de novas versões para ele.
: O MIPModel está em desuso, pois foi substituído por
. Um MIPModel no estado
erar novas versões nem derivar MIPs de processos, mas seus
são mantidos intactos.
uina de estados definida para um MIPModel desde sua
Diagrama de Estados do MIPModel.
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
: Indica que o MIPModel está estável e disponível para
não pode ser editado
no estado Defined,
possui uma versão no
e não é permitida a criação de novas versões para ele.
: O MIPModel está em desuso, pois foi substituído por
. Um MIPModel no estado
erar novas versões nem derivar MIPs de processos, mas seus
são mantidos intactos.
uina de estados definida para um MIPModel desde sua
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
63
: Indica que o MIPModel está estável e disponível para
não pode ser editado. Caso
efined, uma nova
possui uma versão no
: O MIPModel está em desuso, pois foi substituído por
. Um MIPModel no estado Outdated
erar novas versões nem derivar MIPs de processos, mas seus
uina de estados definida para um MIPModel desde sua
Para exemplificar em detalhes o ciclo de vida de um MIPModel, a Figura 21
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
63
: Indica que o MIPModel está estável e disponível para
. Caso
uma nova
possui uma versão no
: O MIPModel está em desuso, pois foi substituído por
utdated
erar novas versões nem derivar MIPs de processos, mas seus
uina de estados definida para um MIPModel desde sua
Figura 21
apresenta um diagrama de atividades com todas as possibilidades de ações disponíveis para
Figura 21 - Diagrama de atividades do MIPModelDiagrama de atividades do MIPModelDiagrama de atividades do MIPModelDiagrama de atividades do MIPModel
64
64
65
O exemplo inicia com a atividade CreateMIPModel, que cria um objeto de
MIPModel denominado M1.1 no estado Draft. O objeto M1.1 pode então ser editado e as
alterações na sua estrutura são salvas pela atividade SaveMIPModel.
Quando M1.1 estiver pronto para ser salvo como definido, o evento SaveAsDefined
pode ser disparado, causando uma bifurcação no fluxo de atividades: a atividade
ToBecomeDefined altera o estado do objeto M1.1 para Defined, e também é feito um teste
para verificar se o MIPModel possui alguma versão antecessora. Caso exista um predecessor
para M1.1, representado no diagrama pelo objeto M1.0, a atividade ToBecomeOutdated é
executada para alterar o estado do predecessor de Pending para Outdated. Em seguida, há
possibilidade de realizar duas atividades: MIPInstantiation e CreateNewVersion.
A atividade MIPInstantiation permite a criação de uma nova instância de M1.1, ou
seja, gera um MIP derivado de M1.1, e pode ser executada diversas vezes. A partir dessa
atividade, pode-se também ativar a atividade CreateNewVersion.
Uma nova versão do MIPModel pode ser solicitada através da atividade
CreateNewVersion, que muda o estado do MIPModel atual (M1.1) para Pending e cria uma
cópia do objeto com estado Draft, representada no exemplo pelo objeto M1.2.
Em seguida, é possível derivar novos MIPs até que seja executada a atividade
ToBecomeOutdated, que muda o estado do objeto M1.1 para Outdated e então finaliza o seu
ciclo de vida, já que ele é substituído pela versão M1.2 no estado Defined.
4.2. MODELO DE DADOS PARA O DOMÍNIO ORGANIZACIONAL.
No Domínio Organizacional, é necessário que a ferramenta disponibilize
funcionalidades para criar e manter apenas um plano de medição, o OrgMIP, e também
permitir análise dos indicadores organizacionais. A Figura 22 apresenta a estrutura de classes
elaborada para permitir a implementação do processo de medição proposto no Domínio
Organizacional.
Conforme especificado na seção 3.2.2, o Plano de Implementação Organizacional -
OrgMip – é composto por Metas de Negócio (objetos da classe OrBusinessGoal), que estão
relacionadas com Metas de Medição da classe OrgMeasurementGoal, que por si geram
Questões quantitativas (objetos da classe OrgQuestion).
66
Figura 22 - Diagrama de classes de implementação do Processo de Medição no Domínio Organizacional.
Semelhante às Metas de Medição no Domínio de Processos, a definição de Metas de
Medição Organizacionais deve conter o objeto de interesse, o propósito, sobre qual ponto-de-
vista e dados contextuais.
Os resultados da medição são visualizados através de Indicadores Organizacionais
(classe OrgIndicator), que estão relacionados com as Questões. Assim como os indicadores
no Domínio de Processos, a definição de um indicador deve conter sua identificação,
descrição, procedimentos de análise e qual seu tipo de alvo para medição (atributos name,
description, analysisProcedure e targetType, respectivamente). As métricas necessárias para
gerar o indicador são definidas através do relacionamento com a classe MetricDefinition, e o
formato de apresentação do indicador pode ser Tabela, diagrama de Pizza, Barra ou linha
(classes Table, Pie, Bar e Line, especializações de Format).
Indicadores Organizacionais auxiliam a compreensão e análise de resultados
relacionados à medição em atributos da organização ou relacionados a métricas de processos
executados, com o objetivo de permitir comparação de resultados. Portanto, diferente dos
indicadores de um MIP apresentados anteriormente, o atributo targetType de um indicador
organizacional tem apenas dois valores possíveis: organização ou processo.
67
A análise de um Indicador Organizacional, juntamente com suas lições aprendidas e
observações gerais de contexto, são registradas na classe OrgIndicatorAnalysis. Um Indicador
Organizacional pode ser analisado diversas vezes, por isso cada análise deve ter sua data
registrada no atributo date.
Se o atributo targetType do indicador for processos, cada análise do indicador é
relacionada com processos da classe Process, permitindo assim flexibilidade para seleção de
processos nas análises comparativas.
4.3. PROTÓTIPO DA FERRAMENTA
Para avaliar a proposta desse trabalho, desenvolveu-se um protótipo da ferramenta de
apoio ao Processo de Medição. O protótipo foi integrado ao ambiente WebAPSEE com três
módulos principais: MIPModel, MIP e Organizacional, detalhados nas subseções a seguir.
4.3.1. Módulo MIPModel.
O módulo MIPModel é relativo ao caso de uso UC1 – Gerenciar MIPModels. Como
mostra a Figura 23, o módulo MIPModel permite a definição de modelos de plano de medição
conforme a especificação da proposta, ou seja, através da seleção de Metas de Negócio, Metas
de Medição, Questões, Indicadores e Relatórios Gerenciais nas abas Business Goals,
Measuremet Goals, Questions, Indicators e Reports, respectivamente.
Figura 23 - Tela principal do módulo MIPModel.
68
O MIPModel de exemplo da Figura 23 está no estado Draft, portanto é possível
realizar alterações no modelo, e conforme a máquina de estados para MIPModels especificada
anteriormente, as atividades Save e Save as Defined estão disponíveis. A partir do momento
que o MIPModel é salvo como Defined o módulo permite acesso apenas para leitura do
MIPModel, bloqueando quaisquer tentativas de alteração.
Em cada aba do formulário é possível incluir na base de dados o elemento
correspondente, adicioná-lo ao MIPModel, visualizar os elementos adicionados e também
remover elementos. A remoção de um determinado elemento é feita apenas em relação ao
MIPModel, pois os elementos incluídos permanecem na base de dados para compor o
catálogo disponível para criação de MIPModels e também de MIPs.
Para manter a rastreabilidade entre os elementos, conforme solicita o requisito F4,
antes de adicionar um elemento ao MIPModel é necessário informar os elementos do níveis
anteriores, exceto para o nível de Metas de Medição por ser o primeiro nível. Como exemplo,
a tela a) da Figura 24 mostra que na aba Indicators é necessário informar a Meta de Negócio
antes de adicionar um Indicador, para em seguida selecionar uma Meta de Medição que esteja
relacionada com a Meta de Negócio, e finalmente acessar as Questões já relacionadas
anteriormente com a Meta de Medição selecionada.
Em relação à definição de indicadores, foram disponibilizadas na ferramenta 3 tipos
de operações para geração do indicador:
• Desvio: Calcula o índice de desvio entre estimativas e métricas e apresenta os
resultados conforme o formato escolhido para o indicador. No formato Tabela, o
índice de desvio é calculado pela subtração entre as métricas coletadas e suas
estimativas, enquanto que os formatos Barra e Linha mostram a porcentagem de
desvio. Essa operação não é disponível para o formato de gráfico em Pizza.
• Distribuição: Calcula a porcentagem do somatório ou média de uma métrica em
relação aos elementos-alvo do indicador. Os formatos possíveis de apresentação
dos resultados são Tabela, gráfico de Barra e Pizza.
• Listagem: Disponível apenas no formato Tabela, a listagem recupera todas as
estimativas e métricas coletadas dos alvos do indicador.
como tipo de alvo atividades
valores de esforço estimados e realizad
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
elementos.
Figura 24 –
A tela
como tipo de alvo atividades
valores de esforço estimados e realizad
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
elementos.
– Tela a) - Aba
A tela b) da Figura 24
como tipo de alvo atividades
valores de esforço estimados e realizad
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
Aba Indicators
Figura 24 mostra um exemplo de definição de um Indicador que tem
como tipo de alvo atividades realizadas no processo de software,
valores de esforço estimados e realizad
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
Indicators. Tela b) - Definição de um indicador no MIPModel
mostra um exemplo de definição de um Indicador que tem
realizadas no processo de software,
valores de esforço estimados e realizados através de um gráfico de barras
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
Definição de um indicador no MIPModel
mostra um exemplo de definição de um Indicador que tem
realizadas no processo de software,
através de um gráfico de barras
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado n
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
Definição de um indicador no MIPModel
mostra um exemplo de definição de um Indicador que tem
realizadas no processo de software, e mostrará o desvio ente os
através de um gráfico de barras
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
permitindo assim que um MIPModel seja reutilizado na construção de outro com
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
a)
Definição de um indicador no MIPModel
mostra um exemplo de definição de um Indicador que tem
mostrará o desvio ente os
através de um gráfico de barras.
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
a construção de outro com
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
a) b)
69
Definição de um indicador no MIPModel.
mostra um exemplo de definição de um Indicador que tem
mostrará o desvio ente os
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
a construção de outro com
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
69
mostra um exemplo de definição de um Indicador que tem
mostrará o desvio ente os
Além de permitir a definição e edição de modelos de plano de medição, o módulo
MIPModel também disponibiliza a funcionalidade de copiar um plano de medição já definido,
a construção de outro com
características inicialmente semelhantes mas que será adaptado pela inclusão ou remoção de
70
4.3.2. Módulo MIP
O módulo MIP foi desenvolvido para prover funcionalidades dos casos de uso
relacionados com um MIP, além de parte dos casos de uso que dizem respeito à análise e
visualização dos resultados, como detalhado a seguir.
Caso de uso UC2 – Selecionar MIP de Projeto
Implementado pela funcionalidade Choose Process MIP, que disponibiliza uma lista
de MIPModels no estado Defined ou Pending e uma lista de processos modelados no
ambiente WebAPSEE para criar o plano de medição de um determinado processo. Ao
selecionar um MIPModel o usuário tem acesso à sua descrição e recomendações da
aplicabilidade (atributo apliedTo) do MIPModel.
Após selecionar o processo de software e o MIPModel mais adequado dentre os
disponíveis, a ação de seleção pode ser acionada para instanciar um MIP derivado do
MIPModel determinado e relacionar o MIP criado com o processo de software.
Caso de uso UC3 – Configurar MIP
O módulo MIP disponibiliza o acesso aos MIPs instanciados para adaptação e
integração dos Indicadores com os elementos do processo.
Através de interface gráfica semelhante à de definição de MIPModels (vide tela a) da
Figura 25), pode-se visualizar os elementos definidos no MIPModel de origem, além de
incluir novos elementos e relacionamentos de acordo com as necessidades específicas do
projetos. Em conformidade com o requisito F3, é possível remover elementos e
relacionamentos do MIP somente se não constarem no MIPModel que o originou.
A configuração necessária para integrar o MIP com seu processo de software
relacionado (requisito F1) é executada através da ação Select Target disponível na aba
Indicators, ilustrada na Figura 25. Por meio dessa ação seleciona-se quais são os elementos-
alvo de um determinado indicador, ou seja, que elementos do processo precisam ser medidos
para gerar o indicador como desejado. Como exemplifica a tela b) da Figura 25, a seleção dos
alvos do indicador é feita com o auxílio dos filtros All, By Type e Selected, conforme descrito
na seção 4.1.
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
Figura 26
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
seja gerado (requisito F5).
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
utilizou
formato do Microsoft Excel (
Figura 25 - Software.
Caso de uso UC
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
Figura 26, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
seja gerado (requisito F5).
Foi escolhido o formato de planilhas elet
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
utilizou-se a API jXLS
formato do Microsoft Excel (
Configuração do indicador para integração do MIP com o Processo de
Caso de uso UC5
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
seja gerado (requisito F5).
Foi escolhido o formato de planilhas elet
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
se a API jXLS [24]
formato do Microsoft Excel (
Configuração do indicador para integração do MIP com o Processo de
– Analisar Medição
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
Foi escolhido o formato de planilhas elet
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
[24] para exportar os dados dos indicadores e criar arquivos
formato do Microsoft Excel (XLS).
Configuração do indicador para integração do MIP com o Processo de
Analisar Medição
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
Foi escolhido o formato de planilhas elet
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
para exportar os dados dos indicadores e criar arquivos
Configuração do indicador para integração do MIP com o Processo de
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
Foi escolhido o formato de planilhas eletrônicas para gerar os indicadores
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
para exportar os dados dos indicadores e criar arquivos
Configuração do indicador para integração do MIP com o Processo de
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
rônicas para gerar os indicadores
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
para exportar os dados dos indicadores e criar arquivos
a)
Configuração do indicador para integração do MIP com o Processo de
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
rônicas para gerar os indicadores
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
para exportar os dados dos indicadores e criar arquivos
a)
71
Configuração do indicador para integração do MIP com o Processo de
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
rônicas para gerar os indicadores devido à
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
para exportar os dados dos indicadores e criar arquivos no
b)
71
Para viabilizar a análise dos resultados da medição, o módulo MIP disponibiliza uma
interface gráfica para acesso e geração dos indicadores gráficos. Como pode ser visto na
, o acesso aos indicadores é possível através da navegação entre as Metas de
Negócio, de Medição e Questões aos quais está relacionado, permitindo então que o indicador
à
facilidade e funcionalidades disponíveis para geração e manipulação de gráficos. Para tanto,
no
72
Ao selecionar um indicador, têm-se acesso também à sua descrição e detalhes de
procedimento de análise definidos, como mostrado na Figura 26. De posse dessas
informações, pode-se então prosseguir com a análise dos resultados, registrando-a através da
aba Analysis, assim como prováveis lições aprendidas e observações de contexto (abas
Learned Lessons e Observations).
Caso de uso UC6 – Visualizar Relatórios Gerenciais
A visualização dos Relatórios Gerenciais configurados no MIP do processo é
disponibilizada no módulo MIP na mesma tela de análise dos indicadores, como mostra a
Figura 26.
Assim como para os indicadores, o acesso aos relatórios configurados é feito após a
seleção de uma questão do plano de medição. Os relatórios configurados para a questão são
então listados, e ao selecionar um relatório o usuário visualiza também o detalhamento da
configuração dele, ou seja, quais indicadores constam no relatório, se inclui procedimentos de
análise, a análise, lições aprendidas e observações, e para quem ou para qual grupo de pessoas
o relatório é destinado. Os Relatórios Gerenciais também são gerados no formato do
Microsoft Excel (XLS).
Figura 26 - Visualização e Análise dos resultados no Domínio de Processos.
1 81 0
3 0
5 0
2 01 5
01 02 03 04 05 06 07 08 09 0
1 0 0
A n á l i s eR e q u i s i t o sP r o j e t oC o d i f i c a c a oR e v i s ã oT e s t e
73
4.3.3. Módulo Organizacional
O módulo organizacional tem como objetivo viabilizar a definição do Plano de
Implementação de Medição Organizacional – OrgMIP – e também a visualização e análise
dos resultados de medição. A seguir são apresentados em detalhes os casos de uso
implementados no módulo.
Caso de Uso UC4 - Gerenciar OrgMIP
Em conformidade com a especificação descrita na seção 4.2, o módulo
organizacional implementa o caso de uso UC4 permitindo a definição do OrgMIP pela
inclusão de Metas de Negócio, de Medição, Questões, Indicadores Organizacionais e
Relatórios Gerenciais relativos ao Domínio Organização.
Para definição e atualização do OrgMIP, o módulo organizacional disponibiliza
interface gráfica semelhante às utilizadas para definição de MIPModels e MIPs, onde pode-se
incluir elementos na base de dados e também adicionar os elementos ao OrgMIP, mantendo a
rastreabilidade dos relacionamentos entre eles (requisito F4).
Caso de uso UC5 – Analisar Medição
Assim como no módulo MIP, a análise da medição no Domínio Organizacional é
feita através da análise dos indicadores definidos. Através da interface gráfica ilustrada pela
tela a) da Figura 27, o acesso aos indicadores é feito navegando-se entre as Metas de Negócio,
de Medição e Questões.
De acordo com o que foi especificado para Indicadores Organizacionais na seção 4.2,
um indicador pode ser analisado diversas vezes enquanto for útil pra organização. Por isso, ao
selecionar um indicador o usuário visualiza a lista de análises já realizadas para ele, além de
sua descrição e seus procedimentos de análise.
A tela b) da Figura 27 mostra o formulário de análise para um indicador cujo
targetType é processos. Para esse tipo de Indicador Organizacional, em cada análise devem
ser selecionados os processos que serão os alvos do indicador, para em seguida gerar o
indicador no formato xls. Na mesma tela registra-se a análise em si, lições aprendidas e
observações gerais de apoio à compreensão da análise, além da data em que ocorreu. É
possível também visualizar e editar uma análise passada através da mesma tela.
mesma tela de análise do indicador, como mostra a
de que os
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
organizacional.
organizacionais apresentam resultados de apenas um ind
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
indicador.
4.4.
modificações arquiteturais no ambiente.
sistema WebAPSEE se divide em 3 camadas princip
Figura 27
Caso de uso UC
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
mesma tela de análise do indicador, como mostra a
que os Indicadores Organizacionais
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
organizacional.
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
organizacionais apresentam resultados de apenas um ind
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
indicador.
4.4. MODIFICAÇÕES NO
Para integrar o protótipo da ferramenta
modificações arquiteturais no ambiente.
sistema WebAPSEE se divide em 3 camadas princip
Figura 27 - Visualização e Análise dos
Caso de uso UC6
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
mesma tela de análise do indicador, como mostra a
Indicadores Organizacionais
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
organizacionais apresentam resultados de apenas um ind
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
MODIFICAÇÕES NO
Para integrar o protótipo da ferramenta
modificações arquiteturais no ambiente.
sistema WebAPSEE se divide em 3 camadas princip
Visualização e Análise dos
– Visualizar Relatórios Gerenciais
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
mesma tela de análise do indicador, como mostra a
Indicadores Organizacionais
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
organizacionais apresentam resultados de apenas um ind
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
MODIFICAÇÕES NO AMBIENTE
Para integrar o protótipo da ferramenta
modificações arquiteturais no ambiente.
sistema WebAPSEE se divide em 3 camadas princip
Visualização e Análise dos resultados no Domínio Organizacional.
Visualizar Relatórios Gerenciais
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
mesma tela de análise do indicador, como mostra a
Indicadores Organizacionais podem ser analisados diversas vezes, e também porque
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
organizacionais apresentam resultados de apenas um ind
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
AMBIENTE WEBAPSEE.
Para integrar o protótipo da ferramenta
modificações arquiteturais no ambiente. Conforme demonstrado na
sistema WebAPSEE se divide em 3 camadas princip
a) Acesso aos Indicadores Organizacionais
resultados no Domínio Organizacional.
Visualizar Relatórios Gerenciais
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
mesma tela de análise do indicador, como mostra a tela b) da
podem ser analisados diversas vezes, e também porque
indicadores para comparação de processos são relacionados aos seu
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
organizacionais apresentam resultados de apenas um indicador: o mesmo selecionado para
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
WEBAPSEE.
Para integrar o protótipo da ferramenta ao WebAPSEE
Conforme demonstrado na
sistema WebAPSEE se divide em 3 camadas principais [29]:
a) Acesso aos Indicadores Organizacionais
b) Análise de Indicador Comparativo de Processo
resultados no Domínio Organizacional.
Visualizar Relatórios Gerenciais
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
da Figura 27
podem ser analisados diversas vezes, e também porque
indicadores para comparação de processos são relacionados aos seus alvos em cada an
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
icador: o mesmo selecionado para
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
WEBAPSEE.
WebAPSEE foi necessário realizar
Conforme demonstrado na Figura 28
:
a) Acesso aos Indicadores Organizacionais
b) Análise de Indicador Comparativo de Processo
resultados no Domínio Organizacional.
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
Figura 27. Isso é devido ao fato
podem ser analisados diversas vezes, e também porque
s alvos em cada an
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
icador: o mesmo selecionado para
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
foi necessário realizar
Figura 28, a arquitetura do
a) Acesso aos Indicadores Organizacionais
b) Análise de Indicador Comparativo de Processo
74
resultados no Domínio Organizacional.
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
evido ao fato
podem ser analisados diversas vezes, e também porque
s alvos em cada análise.
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
icador: o mesmo selecionado para
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
foi necessário realizar
, a arquitetura do
b) Análise de Indicador Comparativo de Processo
74
O acesso aos Relatórios Gerenciais no módulo organizacional é disponibilizado na
evido ao fato
podem ser analisados diversas vezes, e também porque
álise.
Portanto, em um determinado instante podem existir diversas versões de um mesmo indicador
Diferentes do que ocorre no Domínio de Projetos, Relatórios Gerenciais
icador: o mesmo selecionado para
análise. Os relatórios disponíveis na tela de análise são os relacionados à mesma questão do
foi necessário realizar
, a arquitetura do
75
A) Camada Servidora, que provê serviços de persistência, checagem de consistência
para modelagem, controle e armazenamento de artefatos e execução de modelos de
processos de software;
B) Camada Cliente, que oferece infra-estrutura para acesso aos serviços da camada
servidora;
C) Camada de Ferramentas Clientes, que possui as ferramentas que interagem
diretamente com a GUI1 para entrada de dados, modelagem de processos e visualizações
de informações obtidas do servidor.
Figura 28 - Camadas que compõem a Arquitetura do WebAPSEE [29]
A fim de atender as demandas de serviços específicos da ferramenta de suporte ao
modelo de Processo de Medição proposto, os seguintes componentes foram alterados na
arquitetura do ambiente WebAPSEE:
• Na camada C, os formulários da ferramenta foram adicionados ao componente
WebAPSEE Forms. No componente WebAPSEE Reports foram adicionados
métodos para visualização dos indicadores e relatórios gerenciais da ferramenta.
• Na camada B foram adicionados novos métodos no Reports Client para realizar
as chamadas dos indicadores e relatórios da ferramenta.
1GUI - Graphical User Interface
76
• Na camada A foram adicionadas ao componente Model classes de negócio
relativas aos dados persistentes requeridos pela ferramenta em cada um de seus
módulos.
Para estimar e coletar métricas, serão utilizados os formulários atuais do ambiente,
mas deverão ser integrados com o MIP do processo para que disponibilizem as métricas
conforme definido no plano de medição. No protótipo atual esta integração não está
implementada, mas esse fato não impede o uso da ferramenta proposta porque os formulários
de estimativa e coleta provêem acesso a todas as métricas definidas no ambiente.
Outra alteração sugerida é a possibilidade dos agentes coletarem métricas relativas
aos artefatos que desenvolvem, descentralizando desse modo a tarefa de coleta. Para tanto,
será necessário incluir na agenda do desenvolvedor acesso ao formulário de coleta, integrando
a agenda com o MIP do processo da atividade em execução. Atualmente esta funcionalidade
não está implementada, portanto só o gerente coleta métricas.
4.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO.
Este capítulo apresentou o protótipo de apoio ao Processo de Medição proposto,
sendo que o protótipo foi integrado ao ambiente WebAPSEE.
Foram apresentados os modelos de classes para definição da abordagem de medição
nos domínios definidos no capítulo anterior – Domínio de Processos e Domínio
Organizacional, evidenciando como os modelos satisfazem os requisitos definidos para a
ferramenta. Os módulos desenvolvidos – MIPModel, MIP e OrgMIP - foram descritos com
base nos casos de uso definidos anteriormente.
Por fim, apresentou-se as modificações realizadas no ambiente WebAPSEE para
permitir o desenvolvimento e integração do protótipo da abordagem. Além disso, foram
descritas as modificações ainda não implementadas no protótipo atual mas que constam como
trabalho futuro.
77
CAPÍTULO 5 AVALIAÇÃO DA PROPOSTA
Este capítulo apresenta a avaliação da proposta dessa dissertação através de um
experimento onde foram utilizados dados de execução de um processo real, da análise da
aderência aos modelos CMMI e MPS.BR e também através da comparação com trabalhos
relacionados. As seções a seguir descrevem essas avaliações respectivamente.
5.1. EXPERIMENTO.
Na avaliação do trabalho, um processo real de manutenção adaptativa de uma
organização de desenvolvimento de software foi executado no ambiente. No período de
execução do presente trabalho de dissertação tal organização possuía avaliação nível 2 do
CMM.
O estudo de caso iniciou a partir de entrevistas com dois funcionários da organização
com cargo de líder de projetos em desenvolvimento de software, sendo que os dois líderes
pertencem a grupos de desenvolvimento distintos. O objetivo principal da entrevista foi
conhecer o processo de desenvolvimento institucionalizado da organização, como o processo
trata da medição e como ela é executada.
Com as entrevistas verificou-se que a organização possui Planos de Medição e
Análise padronizados em documentos eletrônicos tanto para projetos quanto para o nível
organizacional, como sugere a abordagem proposta neste trabalho. Os Planos de Medição e
Análise incluem a definição de metas de negócio, metas de medição, questões, indicadores de
resultados e a geração de relatórios gerenciais.
As atividades de medição da organização estão previstas no processo de
desenvolvimento, sendo que uma pessoa é alocada como responsável por coletar as métricas
planejadas no Plano de Medição e também por consolidar os resultados na forma de
indicadores e relatórios gerencias. Algumas das métricas são inseridas em um sistema de
coleta pelos próprios desenvolvedores enquanto que outras devem ser solicitadas as
responsáveis. Um dos líderes de projeto entrevistados era o responsável no seu grupo pelas
atividades de medição, fato que possibilitou a obtenção de conhecimento detalhado sobre as
atividades de medição da organização.
Para a execução do estudo de caso, foram obtidos junto à organização os dados
referentes aos custos e prazos estimados e realizados para cada atividade de um processo de
78
manutenção já finalizado, com o compromisso de manter os valores sob sigilo. Além disso,
obteve-se acesso ao Plano de Medição a nível de projetos de software, porém não a
organização não permitiu o acesso à especificação do seu processo padrão de
desenvolvimento.
Como mostra a Figura 29, as atividades do processo de exemplo foram modeladas e
executadas na ferramenta Manager do ambiente WebAPSEE. O processo inicia com a
atividade Reunião Inicial do Projeto envolvendo todos os participantes. Após a execução da
atividade, um analista de requisitos tem a responsabilidade de registrar as decisões tomadas na
reunião na atividade Elaborar Ata da Reunião, enquanto outro analista planeja o
gerenciamento de configuração para o projeto na atividade Planejar Configuração. Em
paralelo, a atividade Elicitar Requisitos é iniciada.
Figura 29 - Execução do processo de exemplo.
Elicitar Requisitos é uma atividade descomposta em outras atividades modeladas
como ilustrado na Figura 30. Ela compreende a elaboração e revisão do Documento de Visão
do projeto e da especificação dos Casos de Uso envolvidos. Por último, os requisitos são
importados para uma ferramenta de Gestão de Requisitos.
79
Figura 30 - Atividade Elicitar Requisitos.
Com a finalização da atividade Importar Requisitos para Ferramenta de Gestão
de Requisitos, de acordo com o processo ilustrado na Figura 29 o Gerente deve realizar a
atividade Elaborar Planejamento do Projeto para que atividade Desenvolver Alterações
seja iniciada.
Como mostra a Figura 31, a execução da atividade Desenvolver Alterações inicia
com a codificação de formulários no sistema por dois desenvolvedores. Na seqüência, ao
mesmo tempo em que é feita a revisão e formatação dos formulários são desenvolvidos novos
relatórios de gestão na ferramenta. Ao final da atividade Desenvolver Relatório de Gestão
um agente codifica versões desses relatórios no formato PDF1.
1 Portable Document Format
80
Figura 31 - Atividade Desenvolver Alterações.
Seguindo o processo modelado, ao finalizar a atividade Desenvolver Alterações a
aplicação deve ser testada para que então o projeto seja homologado (atividades Testar
Aplicação e Homologar Projeto, respectivamente) Após a homologação, o sistema é
implantado no ambiente de operação, conforme as atividades mostradas na Figura 32. Depois
da atividade Implantar, são realizados novos testes na aplicação ao mesmo tempo que
ocorrências de falhas são corrigidas (conexão start-start entre as atividades Teste e Corrigir
Ocorrências de Falhas). Após a correção de falhas, um agente com papel de Gerente realiza
ajustes na homologação.
Figura 32 - Atividade Implantar Projeto.
81
Ao final do processo, o gerente deve fazer uma avaliação final do projeto e
desenvolver o artefato Relatório de Avaliação Final, contendo indicadores dos resultados e
lições aprendidas.
Elaborou-se um modelo de Plano de Implementação de Medição – MIPModel –
simplificado, visto que o processo não é para desenvolver um sistema de software novo, mas
sim um processo de manutenção num sistema que a equipe já possuía conhecimento prévio do
domínio de problema. Nas tabelas a seguir é apresentado um resumo contendo as Metas de
Negócio (Tabela 13), de Medição (Tabela 14), Questões (Tabela 15) e Indicadores elaborados
Tabela 16).
Tabela 13 - Metas de Negócio elaboradas no estudo de caso.
Metas de Negócio
1 Produzir software de qualidade.
2 Melhorar a produtividade.
3 Cumprir os compromissos de prazo e custo assumidos.
Tabela 14 - Metas de Medição elaboradas no estudo de caso e Metas de Negócio relacionadas.
Metas de Medição Meta(s) de Negócio
1
Analisar taxa de defeitos em produtos em manutenção.
Descrição:
Analisar a taxa de defeitos detectados no produto como forma de aferir sua qualidade, sob o ponto-de-vista do cliente, em projetos de manutenção.
1
2
Analisar o tamanho de artefatos e esforço despendido.
Descrição:
Conhecer o tamanho de cada artefato desenvolvido e o esforço necessário para produzi-lo, com o objetivo de manter uma base de dados históricos sobre produtividade.
1, 2, 3
3
Avaliar esforço e rendimento em atividades de teste.
Descrição:
Avaliar as atividades de teste quanto ao esforço e ao rendimento obtido na detecção de defeitos, com o objetivo de identificar formas de aumentar sua eficácia.
1
4
Melhorar acurácia de estimativas que afetem prazo e custo. Descrição:
Analisar o erro das estimativas com o objetivo de conhecer sua acurácia e identificar oportunidades para melhorá-la.
3
82
Tabela 15 - Questões no estudo de caso e Metas de Medição relacionadas.
Questão Meta de Medição
1 Qual a tava de defeitos observada em cada artefato desenvolvido? 1
2 Qual a produtividade observada por tipo de atividade? 2
3 Qual a produtividade observada em atividades de desenvolvimento? 2
4 Qual o tamanho de cada artefato desenvolvido? 2
5 Qual o esforço gasto para o desenvolvimento de cada artefato? 2
6 Qual o esforço dedicado às atividades de teste? 3
7 Qual a taxa de defeitos encontrados em atividades de teste antes e depois da implantação do produto? 3
8 Qual a fração de defeitos detectados em atividades de teste? 3
9 Qual a fração do esforço de um projeto que é empregada nas atividades de teste? 3
10 Qual o índice de desvio das estimativas de esforço, custo, prazo e tamanho realizadas, comparando-se os valores estimados e obtidos? 4
Tabela 16 - Indicadores no estudo de caso e Questões relacionadas.
Indicador Questão
1 Listagem de defeitos observados por artefato 1
2 Distribuição de esforço por tipo de atividade. 2
3 Distribuição de esforço em atividades de desenvolvimento. 3
4 Listagem do tamanho de artefatos. 4
5 Listagem do esforço gasto por artefato. 5
6 Listagem do esforço em atividades de teste. 6
7 Distribuição do esforço por tipo de atividade. 6,9
8 Distribuição de defeitos detectados por tipo de atividade. 8
9 Listagem da taxa de defeitos encontrados em testes antes da implantação. 7
10 Listagem da taxa de defeitos encontrados em testes depois da implantação. 7
11 Índice de desvio de custo por atividade. 10
12 Índice de desvio de custo por tipo de atividade. 10
13 Índice de desvio de esforço por atividade. 10
14 Índice de desvio de esforço por tipo de atividade. 10
15 Índice de desvio de prazo por atividade. 10
16 Índice de desvio de prazo por tipo de atividade. 10
17 Índice de desvio de tamanho por atividade. 10
18 Índice de desvio de tamanho por tipo de atividade. 10
A partir dos dados disponibilizados, elaborou-se um indicador que apresenta o desvio
de custo do projeto por tipo de atividade em formato de gráfico de barras (Figura 33). O
indicador gerado, cujo gráfico está ilustrado na Figura 34, evidenciou que as atividades do
tipo Requirements e Verification e Validation foram superestimadas em mais de 20% em
83
relação ao custo realmente despendido. Dentre as causas relatadas por um integrante do
projeto com perfil de gerente estão a necessidade de treinamentos sobre o método de
estimativa utilizado na organização e a falta de uma base histórica para auxiliar as estimativas.
Figura 33 – Elaboração do Indicador “Desvio de Custo por Tipo de Atividade”.
Figura 34 - Indicador Desvio de Custo por Tipo de Atividade.
Com a execução simulada do processo de exemplo no WebAPSEE integrado com a
ferramenta definida para apoiar a medição, os seguintes benefícios do uso da abordagem
proposta foram identificados:
Desvio de Custo por Tipo de Atividade
-40%
-30%
-20%
-10%
0%
10%
Coding Management Requirements Testing Verificationand Validation
Tipo de Atividade
Des
vio
84
• Fornece apoio à Gerência para avaliação do processo.
A ferramenta disponibiliza para análise os dados resultantes contextualizados pelas
metas de negócio, a definição detalhada das metas medição, e questões que
levantaram a necessidade da coleta dos dados (vide a Figura 26 e a Figura 27 no
capítulo anterior). Além disso, os indicadores possuem descrição e procedimentos de
análise definidos, que também são disponibilizados. De posse dessas informações o
gerente registra a análise dos indicadores na própria ferramenta, e se desejar pode
informar lições aprendidas e observações de contexto dos resultados.
• Diminui tempo de resposta para geração de Relatórios de Avaliação.
Os relatórios configurados podem ser gerados a qualquer momento. Como são
gerados no formato do Microsoft Excel, os relatórios podem ser manipulados
livremente para quaisquer ajustes.
• Permite a padronização e recuperação de Planos de Medição.
São definidos os modelos de Plano de Medição (MIPModels) para serem
instanciados em processos, e os planos de medição (MIPs) são registrados na
ferramenta para consulta posterior. Com a execução dos planos de medição, o
MIPModel de origem pode ser aperfeiçoado, e a organização pode também elaborar
novos MIPModels adequados aos processos que executa. No exemplo dado, o
MIPModel elaborado pode ser usado para instanciar planos de medição para projetos
simples, enquanto outro MIPModel pode ser elaborado para projetos complexos.
• Favorece a reutilização de lições aprendidas.
As lições aprendidas registradas na análise dos resultados podem ser reutilizadas no
planejamento das próximas atividades e novos projetos. As lições aprendidas são
contextualizadas pelos indicadores que estão relacionados, ao plano de medição, e
por fim, ao processo no qual o plano de medição foi instanciado. Essa
contextualização favorece a reutilização das lições diminuindo o risco de
interpretações equivocadas.
No exemplo simulado, a análise e lições aprendidas do indicador da Figura 34
poderiam ser usadas juntamente com o histórico dos valores obtidos para melhorar a acurácia
das estimativas de custos em outros projetos.
85
Em relação ao modelo proposto para integração do Processo de Medição a um PSEE,
alguns potenciais benefícios foram identificados como hipóteses que precisam ser avaliadas
empiricamente em um trabalho futuro. São eles:
• Permite a escolha de métricas úteis à organização, visto que as métricas são
definidas a partir dos objetivos de negócio e de medição, tanto em nível
organizacional quanto de projetos. Desse modo, métricas são coletadas para
satisfazer necessidades reais de informação.
• Permite a coleta e análise correta dos resultados devido à definição detalhada dos
objetivos de medição e procedimentos de análise dos indicadores. Nem sempre quem
coleta participou da elaboração do plano de medição do projeto, portanto essas
informações favorecem a compreensão dos resultados no contexto correto.
• Fornece apoio efetivo à Gerência através dos Relatórios Gerenciais configurados
para comunicar resultados de forma a apoiar tomada de decisões.
5.2. ADERÊNCIA DA PROPOSTA AOS MODELOS CMMI E MPS.BR.
Para analisar o apoio que a proposta fornece para implantação de processos de
medição, verificou-se as recomendações preconizadas pelos modelos de qualidade CMMI e
MPS.BR, apresentados nas seções 2.3.1 e 2.3.2, respectivamente.
Como mostra a Tabela 17, para os níveis em que o processo de medição é
implantado (nível 2 do CMMI e nível F do MPS.BR), avaliou-se como a proposta atende às
praticas especificas e resultados esperados.
Em relação à especificação de métricas, o modelo atende parcialmente por não
permitir a definição de métricas calculadas automaticamente a partir de outras métricas, nem
o uso de escalas do tipo Nominal e Ordinal. Logo, essas deficiências constituem pontos de
melhoria futura. A proposta atende também parcialmente a comunicação dos resultados
porque emite os Relatórios Gerenciais configuração, mas a divulgação deles para os
interessados pode ser feita pelo gerente através de meios externos à ferramenta.
Acerca dos níveis Definido (2) do CMMI e E do MPS.BR deve-se ressaltar que
através da definição de MIPModels a proposta fornece auxílio para a institucionalização do
processo de medição. Os níveis mais altos desses modelos são referentes ao controle
estatístico e ao uso dos resultados para previsão de tendências, estando fora do escopo desse
trabalho.
Práticas Específicas para Medição n
Nível 2
PE 1.1 - Estabelecer objetivos de medição.
PE 1.2 - Especificar medidas.
PE 1.3 - Especificar procedimentos de coleta e armazenamento de dados.
PE 1.4 - Especificar procedimentos de análise.
PE 2.1 - Coletar dados de medições.
PE 2.2 - Analisar dados de medições.
PE 2.3 - Armazenar dados e resultados.
PE 2.4 - Comunicar resultados.
Específicas para Medição no CMMI –
Nível 2
Estabelecer objetivos de medição.
MED1estabelecidos a partir das neinformação e objetivos da organização.
Especificar MED2orientado pelos objetivos deidentificado e/ou definido, priorizado, documentado, revisado
Especificar procedimentos de coleta e armazenamento de
MED3 armazenamento de medidas
Especificar procedimentos de análise.
MED4 medição realizada são
Coletar dados de
MED5 analisadosAnalisar dados
Armazenar dados MED6 são armazenados
Comunicar MED7 para apoiar decisões eobjetiva para comunicação aos interessados
Resultado Esperados da Medição nMPS.BR
MED1 - Objetivos e atividades de medição são estabelecidos a partir das neinformação e objetivos da organização.
MED2 - Um conjunto adequado de medidas, orientado pelos objetivos deidentificado e/ou definido, priorizado, documentado, revisado
MED3 - Os procedimentos para a coleta e o armazenamento de medidas
MED4 - Os procedimentos para a análise da medição realizada são
MED5 - Os dados requeridos são coletados e analisados.
MED6 - Os dados e os resultados de análises são armazenados.
MED7 - As informaçõpara apoiar decisões eobjetiva para comunicação aos interessados
Tabela 17 –
Esperados da Medição nMPS.BR – Nível F
Objetivos e atividades de medição são estabelecidos a partir das necessidades de informação e objetivos da organização.
Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado.
Os procedimentos para a coleta e o armazenamento de medidas são especificados
ocedimentos para a análise da medição realizada são especificados.
Os dados requeridos são coletados e
Os dados e os resultados de análises
As informações produzidas são usadas para apoiar decisões e para fornecer uma base objetiva para comunicação aos interessados
Apoio fornecido
Esperados da Medição no Atendimento
Objetivos e atividades de medição são cessidades de
informação e objetivos da organização.
Um conjunto adequado de medidas, medição, é
identificado e/ou definido, priorizado, Parcial
Os procedimentos para a coleta e o são especificados.
ocedimentos para a análise da
Os dados requeridos são coletados e
Os dados e os resultados de análises
es produzidas são usadas para fornecer uma base
objetiva para comunicação aos interessados. Parcial
Apoio fornecido ao nível 2 do CMMI e ao nível F
Atendimento
Através da definição de Metas de Negócio e Metas de Medição.
Parcial
Permite aprocedimentos de coleta. Não permite a definição para cálculo automático de medidas secundáriasmétricas com escala Nominal ou alfanuméricos.
Os procedimentos de coleta são especificados na definição de cada medida. Para todos os processos, o armazenamento dos dados é na base de métricas do WebAPSEE.
Procedimentos de Análise são definidos para cada indicador de resultados.
As métricas são estimadas e coletadformulários
A análise dos resultados é registrada para cada indicador.
Os processos, planos de mediçanálise dos resultados são armazenados na base do ambiente.
Parcial
A ferramenta gera os Relatórios Gerenciais configurados no plano de medição, mas o gerente é quem repassa as informações ao públicorelatório.
ao nível 2 do CMMI e ao nível F
Como atende
Através da definição de Metas de Negócio e Metas de Medição.
Permite a definição de medidas primárias procedimentos de coleta. Não permite a definição para cálculo automático de medidas secundáriasmétricas com escala Nominal ou alfanuméricos.
Os procedimentos de coleta são especificados na definição de cada medida. Para todos os processos, o armazenamento dos dados é na base de métricas do WebAPSEE.
Procedimentos de Análise são definidos para cada indicador de resultados.
As métricas são estimadas e coletadformulários próprios no ambiente
A análise dos resultados é registrada para cada indicador.
Os processos, planos de mediçanálise dos resultados são armazenados na base do ambiente.
A ferramenta gera os Relatórios Gerenciais configurados no plano de medição, mas o gerente é quem repassa as informações ao públicorelatório.
ao nível 2 do CMMI e ao nível F do MPS.BR.
Como atende
Através da definição de Metas de Negócio e Metas de
definição de medidas primárias procedimentos de coleta. Não permite a definição para cálculo automático de medidas secundáriasmétricas com escala Nominal ou Ordinal
Os procedimentos de coleta são especificados na definição de cada medida. Para todos os processos, o armazenamento dos dados é na base de métricas do
Procedimentos de Análise são definidos para cada indicador de resultados.
As métricas são estimadas e coletadpróprios no ambiente.
A análise dos resultados é registrada para cada
Os processos, planos de medição, dados coletados e análise dos resultados são armazenados na base do
A ferramenta gera os Relatórios Gerenciais configurados no plano de medição, mas o gerente é quem repassa as informações ao público
86
Através da definição de Metas de Negócio e Metas de
definição de medidas primárias e seus procedimentos de coleta. Não permite a definição para cálculo automático de medidas secundárias, nem
Ordinal com caracteres
Os procedimentos de coleta são especificados na definição de cada medida. Para todos os processos, o armazenamento dos dados é na base de métricas do
Procedimentos de Análise são definidos para cada
As métricas são estimadas e coletadas através de
A análise dos resultados é registrada para cada
ão, dados coletados e análise dos resultados são armazenados na base do
A ferramenta gera os Relatórios Gerenciais configurados no plano de medição, mas o gerente é quem repassa as informações ao público-alvo de cada
86
Através da definição de Metas de Negócio e Metas de
seus procedimentos de coleta. Não permite a definição para
, nem com caracteres
Os procedimentos de coleta são especificados na definição de cada medida. Para todos os processos, o armazenamento dos dados é na base de métricas do
Procedimentos de Análise são definidos para cada
A análise dos resultados é registrada para cada
ão, dados coletados e análise dos resultados são armazenados na base do
A ferramenta gera os Relatórios Gerenciais configurados no plano de medição, mas o gerente é
alvo de cada
87
5.3. TRABALHOS RELACIONADOS.
Esta seção apresenta uma comparação da abordagem apresentada com três
ferramentas de auxilio a processos de medição. São elas: REMEX, Amadeus, MedPlan e
Metrics.
A ferramenta REMEX [21] é um ambiente cuja funcionalidade específica é a
definição de atividades de planos de medição, conforme o paradigma GQM. REMEX utiliza
Raciocínio Baseado em Casos para construção de automática de um plano de medição através
da reutilização de planos e/ou atividades de planos anteriores, diminuindo o esforço durante o
planejamento de medição. Ao contrário da proposta deste trabalho, REMEX não está
integrada a um ambiente automatizado de desenvolvimento, o que permitiria a interação direta
das atividades de um plano de medição com o processo de software e seus elementos.
O sistema Amadeus [43], inserido no PSEE Arcadia, permite a análise de processos
baseada em métricas, mas não possui mecanismo para definição do processo de medição.
Permite também adição de novas técnicas de análise, que são baseadas em métodos
estatísticos.
As ferramentas MedPlan e Metrics [42] estão integradas ao ambiente de
desenvolvimento TABA. A ferramenta MedPlan apóia a elaboração de planos de medição da
organização e de projetos. Diferente da abordagem elaborada neste trabalho, a ferramenta
MedPlan permite a definição de somente um plano padrão de medição, baseado no método
GQM, que deve ser executado em todos os projetos de software. Assim como na proposta
desta dissertação, o plano padrão de medição pode ser adaptado para um determinado projeto
através da adição de novos elementos GQM, mas não é permitida a remoção das definições
organizacionais contidas no plano padrão.
Através da ferramenta Metrics o gerente pode coletar métricas de um projeto de
acordo com o plano de medição definido na ferramenta MedPlan, e gerar um relatório do
plano de medição e seus resultados. Não é permitido que a tarefa de informar métricas seja
realizada também pelos desenvolvedores, e que o gerente configure relatórios gerenciais
elaborados de acordo com a necessidade de informação, como é proposto neste trabalho. Uma
métrica pode ser visualizada através de uma representação gráfica, que difere dos indicadores
que fazem parte da abordagem apresentada já que estes podem consolidar resultados de uma
ou mais métricas. Adicionalmente, Metrics fornece apoio à avaliação post-morten através do
envio de questionários de avaliação aos participantes do projeto, além da avaliação da
88
aderência às áreas de processo do CMMI através de checklists. O apoio às atividades de
análise pela proposta aqui apresentada é fornecido apenas ao gerente, que pode analisar os
indicadores dos resultados e identificar lições aprendidas.
5.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO.
Neste capítulo a proposta foi analisada através de três abordagens: experimento,
aderência a modelos de qualidade e comparação com trabalhos relacionados.
No experimento foi executado um processo com dados reais de custo e prazo, e um
Plano de Implementação de Medição (MIP) foi instanciado a partir do MIPModel elaborado.
Foram destacados benefícios fornecidos pela ferramenta proposta, além da necessidade de
avaliação empírica para validar as hipóteses com potenciais benefícios da metodologia para
medição apresentada nesse trabalho.
Em seguida, foi apresentado como a metodologia e a ferramenta propostas provêem
apoio para executar as práticas do CMMI e alcançar os resultados esperados pelo MPS.BR.
Com essa análise foram descobertos necessidades de melhoria referentes ao cadastro de
métricas no ambiente e divulgação dos resultados.
Por fim, foram apresentadas três ferramentas de apoio ao processo de medição,
destacando-se suas características, pontos fortes e fracos em relação à proposta dessa
dissertação.
89
CAPÍTULO 6 CONCLUSÕES
Medição tornou-se um processo tão importante quanto necessário nas organizações
que desenvolvem software [31], pois fornece dados quantitativos para apoiar a gerência de
processos no cenário atual caracterizado por rápidas mudanças, grande exigência de
produtividade e qualidade do produto de software.
Implantar um processo de medição não é uma tarefa fácil, ainda mais quando se
considera a quantidade de métricas para os diversos atributos de processo e seus elementos
propostas na literatura especializada. Para obter conhecimento útil, é necessário que as
atividades de medição e métricas selecionadas estejam de acordo com as necessidades de
informação da organização e do projeto.
Este trabalho apresentou uma abordagem automatizada de medição e análise para
processos de software orientada a objetivos organizacionais. A abordagem tem potencial de
promover melhoria continua de qualidade ao permitir o planejamento de coleta de métricas de
acordo com as necessidades organizacionais e dos projetos, a configuração e geração de
indicadores gráficos (juntamente com procedimentos de análise) para facilitar a compreensão
dos resultados, e configuração de relatórios gerenciais com resultados consolidados para
fornecer em tempo hábil auxílio à tomada de decisão.
A subseção a seguir apresenta algumas limitações do trabalho relacionadas tanto com
o modelo proposto quanto à sua implementação atual. Na seqüência, a seção 6.3 descreve
atividades futuras para continuação do trabalho, enquanto que a seção 6.4 apresenta as
considerações finais.
6.1. ANÁLISE CRÍTICA DA PROPOSTA.
Devido às inúmeras possibilidades para elaboração de indicadores, foram
desenvolvidas na ferramenta três operações pré-definidas para consolidação dos valores a
serem apresentados por indicadores: Desvio, Listagem e Distribuição. Embora o meta-modelo
tenha sido projetado para permitir adição de novas operações, sua implementação atual não
fornece auxílio nesta atividade, pois cada operação deve ser codificada como um método em
Java e registrada na classe Operation.
A implementação atual adota uma solução simplificada para o aspecto de segurança:
Apenas os usuários configurados como gerentes no WebAPSEE têm acesso à definição dos
90
MIPModels, MIPs, OrgMIP e os relatórios produzidos pela ferramenta. Investigações
adicionais devem ser conduzidas em função da necessidade de fornecer acesso adequado aos
perfis dos interessados nos resultados da medição, como por exemplo: gerentes de negócio,
gerentes de processos e os próprios desenvolvedores.
No protótipo desenvolvido até a presente data, o módulo de geração dos Relatórios
Configurados ainda não está em operação. Este módulo está em desenvolvimento, e uma das
dificuldades encontradas reside no fato de que o conteúdo dos relatórios é dinâmico,
possuindo um ou mais indicadores e informações de indicadores de acordo com a
configuração. A solução de gerar relatórios no formato Microsoft Excel tem como benefício
permitir que o gerente manipule os gráficos e dados gerados, mas apresenta dificuldades em
gerar relatórios cujos conteúdos não possuam um formato padrão.
Em relação à escala e ao tempo de resposta o elemento crítico corresponde à geração
dos Relatórios Gerenciais configurados. Neste aspecto, a quantidade de indicadores contidos
em um relatório influencia significantemente no seu tempo de geração, em virtude da
necessidade de navegação em uma extensa rede de objetos. Uma avaliação criteriosa com
mais estudos de caso, após o desenvolvimento desse módulo, pode resultar em melhoria na
implementação.
6.2. TRABALHOS FUTUROS.
Entre as atividades futuras previstas para o trabalho consta o desenvolvimento de
melhorias e evolução do protótipo atual que não foram desenvolvidas devido a restrição de
tempo para conclusão deste trabalho. As melhorias são:
• Integração do formulário de coleta com o plano de medição do processo (MIP);
• Inserção de formulário de coleta na agenda do desenvolvedor, para que colete
métricas de artefatos conforme definido no MIP do processo;
• Desenvolvimento de relatórios de propósito geral relativos aos planos de
medição (caso de uso UC7);
• Extensão do mecanismo de definição de métricas para que permita o cálculo
automático de métricas secundárias e também o uso de escalas do tipo Nominal e
Ordinal;
• Desenvolvimento de uma abordagem automatizada para comunicação e
divulgação dos Relatórios Gerenciais.
91
Pretende-se avaliar o impacto que mudanças no processo – já permitidas pelo
WebAPSEE - podem causar nas metas definidas no seu plano de medição, e como prover ao
gerente apoio para monitorar e gerenciar esses impactos.
Ainda como atividade futura, será avaliado como obter melhor proveito do registro
de lições aprendidas e observações de contexto através da gerência desse conhecimento. O
propósito é auxiliar a disseminação e utilização mais abrangente da experiência obtida, ou
seja, desenvolver uma solução automatizada para propiciar que o valor do conhecimento
adquirido seja agregado não só ao projeto a que pertence, mas também nos próximos projetos
e nas decisões e estratégicas de negócio da organização.
A experimentação da ferramenta em uma organização deve ser realizada para que a
abordagem seja avaliada numa escala maior de complexidade. O objetivo é obter feedback
quanto a qualidade e efetividade no auxílio à gerência de processos, avaliar empiricamente os
potenciais benefícios da abordagem, e assim identificar novas oportunidades e pontos de
melhoria.
Por fim, está previsto o estudo, análise e aplicação de mecanismos e técnicas para
avaliar correlação entre os elementos e valores medidos, com o objetivo de auxiliar o gerente
na avaliação dos resultados para tomada de decisões.
6.3. CONSIDERAÇÕES FINAIS DO TRABALHO.
A abordagem apresentada nesta dissertação fornece auxílio à prática de
recomendações feitas para processos de medição e análise nos níveis iniciais de modelos de
maturidade, como os modelos CMMI e MPS.BR descritos no texto.
Espera-se que o modelo proposto possa servir como base para implantação de
processos de medição em organizações, de modo que passem a usufruir dos benefícios que as
práticas de medição podem oferecer. Através da solução elaborada com a definição de
modelos de Plano de Implementação de Medição (MIPModels), a abordagem oferece auxílio
para que as organizações evoluam seus processos de medição ao longo do tempo sem perda
de informações passadas.
Deve-se destacar que a integração do processo de medição com um PSEE tem o
grande benefício de desfrutar de todo o mecanismo e estrutura que o ambiente possui para
gerenciamento de processos, permitindo que as atividades de medição sejam inseridas no
processo de software sem aumentar a complexidade do planejamento e modelagem de suas
atividades. Por exemplo, a base de métricas obtida pela execução do modelo proposto pode
92
ser usada em conjunto com técnicas avançadas de análise para executar práticas de níveis
mais altos de qualidade, como por exemplo, as áreas Desempenho dos Processos
Organizacionais e Controle Quantitativo de Projetos do CMMI.
Por fim, ressalta-se a necessidade da implantação da proposta deste trabalho em mais
estudos de casos para validar os benefícios identificados e analisar oportunidades de
aperfeiçoamento.
93
REFERÊNCIAS
[1] Basili, V. R. Software Modeling and Measurement: The Goal/Question/Metric Paradigm. Technical Report CS-TR-2956, Department of Computer Science, University of Maryland, College Park, MD 20742, September 1992.
[2] Basili, V. R., Caldieira, G., Rombach, H. D. Goal Question Metric Paradigm. Encyclopedia of Software Engineering. John Wiley & Sons, Inc., 1994,.p. 528-532.
[3] Basili, V. R., Rombach, H. D. The TAME Project: Towards Improvement-Oriented Software Environments. IEEE Transactions on Software Engineering, 1988,SE-14(6).
[4] Basili, V. R., Weiss, D. A Methodology for Collecting Valid Software Engineering Data. IEEE Transactions on Software Engineering, Vol. 10, No. 3, Nov, 1984, pp. 728-738.
[5] Boehm, B. W., Brown, J. R., Lipow, M. Quantitative Evaluation of Software Quality. In: International Conference on Software Engineering, 2, 1976, Proceedings of…, p. 592.
[6] Briand, L. C., Differding C., Rombach, D. Practical Guidelines for Measurement-based Process Improvement. Software Process – Improvement and Practice, v.2, 1996, p. 253-280.
[7] Briand, L. C., El Emam, K., Morasca S. On the Application of Measurement Theory to Software Engineering. Empirical Software Engineering - An International Journal, v.1, 1996.
[8] Chrissis, M. B., Konrad, M., Shrum, S. CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley, 2003.
[9] Costa, A. J. S., Sales, E. O. Uma Proposta para Reutilização de Processos para o Ambiente WebAPSEE. Trabalho de Conclusão de Curso (Graduação em Bacharelado em Ciência da Computação). Departamento de Informática, Universidade Federal do Pará, 2006.
[10] Daskalantonakis, M.K. A Practical View of Software Measurement and Implementation Experiences within Motorola. In: Applying Software Metrics, IEEE Computer Society Press, 1992, pp. 168-180.
[11] Derniame, J., Kaba, B., Wastell, D. Software Process: Principles, Mehodology and Technology. Lecture Notes in Computer Science, 1500. Springer, 1998.
[12] DoD - Department of Defense and US Army. A Foundation for Objective Project Management (P1045/D5.0). Washington, D.C., 2000. Disponível em http://www.psmsc.com.
[13] Eman, K. E., Drouin, J., Melo W., SPICE – The Theory and Practice of Software Process Improvement and Capability Determination, IEEE Computer Society Press, 1998.
94
[14] Falbo, R. A. Integração de Conhecimento em um ambiente de desenvolvimento de software. Tese de Doutorado. Rio de Janeiro: COPPE-UFRJ, 1998.
[15] Fenton, N. E. Software Measurement: A Necessary Scientific Basis. IEEE Transactions on Software Engineering, vol 20 n. 3, 1994, p. 199-206.
[16] Fenton, N. E., Neil, M. Software metrics: Roadmap. ICSE - Future of Software Engineering Track. 2000, p. 357-370.
[17] Fenton, N. E., Pfleeger, S. L. Software Metrics – A Rigorous & Practical Approach. PWS Publishing Company, 2ª Edição, 1997.
[18] Florac, W. A., Carleton, A. D. Measuring the Software Process: Statistical Process Control for Software Process Improvement. Addison Wesley, 1999.
[19] Fulggetta, A. Software Process: A Roadmap. In Proceedings of the Conference on The Future of Software Engineering, Limerick-Ireland, 2000, p. 25-34.
[20] Goethert, W., Hayes,W. Experiences in Implementing Measurement Programs. Technical Report CMU/SEI-2001-TN-026, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. 2001. Disponível em http://www.sei.cmu.edu.
[21] Greese von Wangenheim, C., Rodrigues, M. R. Planejamento de programas de mensuração baseados em reutilização. XI Conferência Internacional de Qualidade de Software. Curitiba, Brasil, 2000.
[22] Hetzel, W. Making Software Measurement Work: Building an Effective Software Measurement Program. QED Publishing, 1993.
[23] ISO/IEC 12207:1995, Information Technology – Software Life-Cycle Processes. 1995.
[24] JXLS. JXLS Project Documentation, 2007. Disponível em http://jxls.sourceforge.net.
[25] Kan, S. H. Metrics and Models in Software Quality Engineering, Addison-Wesley, 2ª Edição, 2003.
[26] Kitchenham., B., Pfleeger, S. L., Fenton, N. Towards a Framework for Software Measurement Validation. IEEE Transactions on Software Engineering, vol. 21, nº 12. December, 1995. p. 929-944.
[27] Kogure, M., Akao, Y. Quality Funcion Deployment and CWQC in Japan. Quality Progress, Outubro, 1983, p. 25-29.
[28] Lima, A. M., Costa, A. J. S., França, B. B. N., Lima Reis, C. A. , Reis, R. Q. Gerência Flexível de Processos de Software com o Ambiente WebAPSEE. 19º. Simpósio Brasileiro de Engenharia de Software – Sessão de Ferramentas, Outubro, 2006.
[29] Lima, A. M., Lima Reis, C. A. , Reis, R. Q. Análise do Ambiente WebAPSEE no atendimento aos requisitos de Gerência de Processos de Software. XX Semana Paraense de Informática, SEPAI/CTIC. Belém, PA. Outubro de 2006.
95
[30] Lima Reis, C.A. Uma Abordagem Flexível para Execução de Processos de Software Evolutivos. Tese de Doutorado. Porto Alegre: PPGCC-UFRGS, 2003.
[31] Mcgarry, J., Card, D., Jones, C., et al. Practical Software Measurement: Objective Information for Decision Makers, Addison-Wesley, 2001.
[32] Nascimento, L. M. A., Costa, A. J. S., França, B. B. N., Lima Reis, C. A. , Reis, R. Q. Uma abordagem para Medição em um Ambiente de Desenvolvimento de Software Centrado em Processos. Conferência Latino-Americana de Informática, San José, Costa Rica, 2007.
[33] Natali, A. C., Falbo, R. A. Gerência de Conhecimento de Qualidade de Software. 2nd Ibero-American Symposium on Software Engineering and Knowledge Engineering, Salvador, Brasil, 2002.
[34] Park, R.E., Goethert, W.B., Florac, W.A. Goal-Driven Software Measurement – A Guidebook. Handbook CMU/SEI-96-HB-002, Pittsburgh, Software Engineering Institute, Carnegie Mellon University, 1996. Disponível em http://www.sei.cmu.edu.
[35] Pfleeger, S., Rombach,D. Measurement based Process Improvement. In: IEEE Software. Julho, 1994, p. 8-11.
[36] Pfleeger, S. Engenharia de Software-Teoria e Prática. Prentice Hall, 2ª Edição, 2004.
[37] Reis,R.Q., Lima Reis,C.A., Nunes, D.J. Automação no Gerenciamento do Processo de Engenharia de Software. Escola Norte de Informática, 2002.
[38] Roche, J., Jackson, M. “Software measurement methods: recipes for sucess?”. Journal on Information and Software Technology, v.36, 1994, p. 173-189.
[39] Rombach, H. D., Ulery, B. T. Improving software maintenance through measurement. Proceedings of the IEEE, v. 77, No.4, 1989, p. 581-595.
[40] Rombach, H. D. Practical Benefits of Goal-Oriented Measurement. Software Reliability and Metrics. Elsevier Applied Science, 1991.
[41] SEI - Software Engineering Institute. CMMI for Development, v1.2. CMU/SEI-2008-TR-008, Pittsburgh, Carnegie Mellon University. 2006. Disponível em http://www.sei.cmu.edu.
[42] Schnaider, L., Santos, G., Montoni, M., Rocha, A. R. Uma abordagem para Medição e Análise em Projetos de Desenvolvimento de Software. III Simpósio Brasileiro de Qualidade de Software. Brasília, Brasil, 2004.
[43] Selby, R. W., Porter, A. A., Schmidt, D. C., Berney, J. Metric-Driven Analysis and Feedback Systems for Enabling Empirically Guided Software Development. 13th International Conference on Software Engineering, 1991. p.288-298.
[44] Softex - Associação para Promoção da Excelência do Software Brasileiro. MPS.BR – Guia Geral, v1.2, 2007. Disponível em www.softex.br.
96
[45] Softex - Associação para Promoção da Excelência do Software Brasileiro. MPS.BR – Guia de Implementação Parte 2, v1.1, 2007. Disponível em www.softex.br.
[46] Solingen, R., Berghout, E. The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development. McGraw-Hill, 1999.
[47] WebAPSEE. Documento de Referência do ambiente WebAPSEE. v.1.0, 2006. Disponível em www.webapsee.com.