UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
U
MA
A
BORDAGEM
A
UTOMATIZADA DE
M
EDIÇÃO EM
P
ROCESSOS DE
S
OFTWARE
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
U
MA
A
BORDAGEM
A
UTOMATIZADA DE
M
EDIÇÃ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.
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
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
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
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
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
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,
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
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
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.
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.
CAPÍTULO 2
M
EDIÇÃO E
P
ROCESSO DE
S
OFTWARE
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
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
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)
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.
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
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
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.
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
D ef in iç ão G1 G2 Q1 Q2 Q3 Q4 Q5 M1 M2 M3 M4 M5 M6 M7 Questões Métricas In te rp re ta çã o Metas
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
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
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ê
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
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.
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.
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-MPS) e o Modelo de Negócio (MN-(MA-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
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
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.
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.
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 tornou-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].
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.
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.
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.
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;
