Utilização do GQM no Desenvolvimento de Software

Utilização do GQM no Desenvolvimento de Software UNIVERSIDADE DO VALE DO RIO DOS SINOS Centro de Ciências Exatas e Tecnológicas Instituto de Informática Laboratório de Qualidade de Software Fone: (51) 590.8169 instituto@exatas.unisinos.br

Utilização do GQM no Desenvolvimento de Software Autoria: Christiane Gresse von Wangenheim Última atualização: Setembro 2000 Impressão: Gráfica UNISINOS O texto desta apostila foi publicado pela autora na IX Conferência Internacional de Tecnologia de Software: Qualidade de Software, Curitiba, Brasil, 1998 com o título "Melhoramento de Software Baseado em Mensuração - Como Aplicar GQM na Prática?", com autoria conjunta com H. D. Rombach e G. Ruhe. Nenhuma parte desta apostila pode ser utilizada ou reproduzida, em qualquer meio ou forma, seja mecânico ou eletrônico, fotocópia, gravação, ou outros, sem autorização, prévia, expressa e específica do Autor. UNIVERSIDADE DO VALE DO RIO DOS SINOS Centro de Ciências Exatas e Tecnológicas Instituto de Informática Laboratório de Qualidade de Software: www.inf.unisinos.br/instituto/lqs Fone: (51) 590.8169 - E-mail: instituto@exatas.unisinos.br Utilização do GQM no Desenvolvimento de Software - 2

SUMÁRIO For continuous improvement of software quality and productivity the capturing and reuse of explicit software development know-how is essential. What represents relevant software know-how differs among companies wrt. their context characteristics and their business goals. Therefore the software know-how has to be derived by organization-specific measurement programs taking into account the environment and focusing on the company-specific goals. Although a significant progress has been made during the last years, implementing a successful measurement program in industrial software projects is still a challenging undertaking. Most problems are due to lacking support and guidance for the application of measurement programs in practice. This paper focuses on the Goal/Question/Metric (GQM) paradigm, a goal-oriented measurement approach. We present a detailed description of how to plan and execute a GQM-based measurement program, including guidelines for its application in practice. The approach is evaluated by studying the cost/benefit ratio of the introduction of GQM-based measurement programs in various industrial environments. Keywords: Software quality, Goal-oriented measurement, Goal/Question/Metric approach, Cost/benefit, Industrial application Utilização do GQM no Desenvolvimento de Software - 3

1 INTRODUÇÃO Hoje, quase todas as organizações estão envolvidas no desenvolvimento ou uso de software. A qualidade do software tem uma importância essencial para a competitividade de uma organização no mercado. Mas, na realidade, o processo de desenvolvimento e manutenção de software é freqüentemente insuficiente com respeito à qualidade, produtividade e previsibilidade. Muitas organizações estabeleceram processos de desenvolvimento e manutenção de uma maneira ad-hoc, baseadas em experiências de outras empresas. Isso resultou muitas vezes em soluções incompatíveis, conseqüências negativas e equipes sem motivação. Para melhorar a qualidade e produtividade de software na indústria, é necessário entender o software e os processos de desenvolvimento e manutenção de software específicos de uma empresa. O problema com o software, é que seu desenvolvimento é influenciado por um espectro extremamente grande de fatores como: de processo (p.ex. técnicas, ferramentas usadas), produto (p.ex. linguagem de programação, plataforma) ou recursos (p.ex. experiência de desenvolvedores). Para adquirir uma visão mais profunda deste processo de desenvolvimento e dos fatores de influência, nós necessitamos de modelos formais e de uma forma de organização para a reutilização de todo o conhecimento [BCR94a]. É especialmente importante definir o nível corrente de compreensão de processos e produtos de software em uma empresa de uma forma quantitativa, de forma que as metas de negócios da empresa possam ser julgadas se estão satisfeitas ou não. Isso só pode ser obtido em uma empresa através da modelagem e da mensuração explícita dos fatores que influenciam o processo de software [Rom91]. Este artigo enfoca a aplicação da abordagem GQM para mensuração orientada em metas na prática. No capítulo 2, a mensuração em projetos de software é motivada. A abordagem GQM é apresentada em detalhe no capítulo 3, sendo descritos todos os passos para planejar e executar um programa de mensuração. A descrição de cada passo é complementada através de diretrizes para a sua aplicação na prática. Experiências com respeito aos custos e benefícios relacionados à aplicação na prática são mostradas no capítulo 5. Capítulo 6 resume os resultados e fornece conclusões. Utilização do GQM no Desenvolvimento de Software - 4

2 PORQUE APLICAR MENSURAÇÃO EM PROJETOS DE SOFTWARE? Geralmente é aceito que a mensuração não é um fim em si, mas um meio para o fim. Assim, objetivos finais para o estabelecimento de um programa de mensuração em uma organização de software são [NAS94]: Compreensão dos produtos e processos de software, Gerência de projetos de software, Melhoramento contínuo. O propósito subjacente de qualquer programa de mensuração deve ser o de alcançar os resultados específicos da coleta e interpretação dos dados de mensuração. Sem tais objetivos, nenhum benefício será alcançado através do esforço da mensuração. Mensuração para compreender produtos e processos de software Fundamental para o melhoramento sistemático de processos e produtos de software é a compreensão e o estabelecimento de linhas-base quantitativas com respeito aos processos atuais na organização. Esta compreensão dos processos e práticas na organização é crucial para planejar, controlar e melhorar o desenvolvimento e a manutenção do software. Exemplos de questões, expressando esta necessidade para compreensão são: Como está distribuído o esforço no desenvolvimento e na manutenção de software? Quanto esforço está sendo gasto em rework (devido à correção de defeitos)? Qual é a porcentagem de falhas encontradas por inspeção? Um primeiro passo para abordar estes assuntos é estabelecer um a linha-base com respeito aos produtos e processos de software na organização. Com base na informação quantitativa ganha através de um programa de mensuração, uma organização pode construir seus modelos de qualidade específicos e pode examinar fatores de contexto que têm um impacto nos modelos. Por exemplo, o esforço para o desenvolvimento de um sistema de software depende do tamanho de sistema e da experiência dos desenvolvedores. Para uma compreensão completa da combinação complexa dos vários fatores de influência, estes devem ser examinados dentro da organização específica por um programa de mensuração. Utilização do GQM no Desenvolvimento de Software - 5

Mensuração para gerenciar projetos de software Os modelos organizacionais baseados na compreensão dos produtos e processos de software e os fatores de influência destes podem ser usados para prover melhor informação (quantitativa) para decisões de gerência. O conhecimento ganho pela análise e interpretação dos dados de mensuração pode ser usado para [NAS94]: Planejamento de novos projetos de software com base na estimativa de esforço requerido, cronograma, alocação da equipe, etc. Através dos modelos formais baseados em dados de mensuração, conhecimento sobre esses aspectos pode ser reutilizado para um planejamento mais informado e apropriado. Um exemplo é o modelo de distribuição de esforço por fases do ciclo de vida de software na NASA com base em dados analisados de mais de 25 projetos nessa organização. Outras 26% Projeto 23% Fases da ciclo da vida: Projeto, Implementação, Teste Outras atividades incluindo treinamento, reuniões, viajens. Teste 30% Implementação 21% Figura 1. Modelo de distribuição de esforço [NAS94] Controle do projeto corrente através da comparação dos valores estimativos com os valores atuais coletados pela mensuração acompanhando o projeto corrente. Resultando da monitoria do estado do projeto, ajustes e ações corretivas podem ser iniciadas, quando desvios do plano de projeto ou problemas aparecem. Para possibilitar esta comparação, os dados devem ter sido coletados em programas de mensuração em projetos semelhantes já completados, e os dados atuais têm que ser coletados em programas de mensuração do projeto corrente. Utilização do GQM no Desenvolvimento de Software - 6

100 Projeto Implementação/Teste Teste de sistema Teste de aceita 90 80 % de Total SLOC 70 60 50 40 30 20 planejado atual 10 % de cronograma 10 20 30 40 50 60 70 80 90 100 Figura 2. Acompanhamento da taxa de crescimento [NAS94] Validação dos modelos organizacionais desenvolvidos em programas de mensuração passados. Por causa das mudanças permanentes na área de software, p.ex. com respeito às novas tecnologias, os modelos precisam ser ajustados às novas tendências ou, em caso de os projetos atuais mostrarem desvios dos dados constantes dos modelos. Mensuração para guiar melhoramento O objetivo principal de uma organização é desenvolver um produto de alta qualidade dentro de um cronograma e orçamento. Por causa dos requisitos permanentemente crescentes no desenvolvimento de software com respeito ao cliente ou novas tecnologias, o melhoramento sistemático e contínuo precisa ser parte integrada ao processo de software. O melhoramento do produto é tipicamente atingido através do melhoramento dos processos usados para produzir o produto. O melhoramento dos processos pode ser atingido pela modificação dos processos gerenciais ou técnicos, ou pela introdução das novas tecnologias. Em todo caso, mensuração de software é uma tecnologia chave de qualquer programa de melhoria: Enfocando no melhoramento da qualidade, os pontos fortes e fracos podem ser identificados pelo programa de mensuração inicial. Com base nessa compreensão inicial, áreas de melhoramento potenciais com alto impacto na qualidade do produto podem ser identificadas e ações de melhoramento podem ser selecionadas, executadas e avaliadas. O impacto dessas mudanças precisa ser assessorado quantitativamente pela mensuração acompanhando as modificações. Ele só pode ser determinado, se uma linha-base quantitativa está disponível, contra a qual as comparações podem ser feitas. De outra maneira é impossível determinar se uma mudança obteve um efeito positivo ou não [DHL95]. Um paradigma para o melhoramento contínuo e execução sistemática dos projetos de software é o Quality Improvement Paradigm (QIP) [BCR94a, BR88]. O QIP foi desenvolvido na Universidade de Maryland (EUA) em cooperação com o Software Engineering Laboratory (SEL) da NASA. O QIP é um processo iterativo, que inclui o planejamento, execução e avaliação de melhoramento em organizações de software. Um conceito principal dessa Utilização do GQM no Desenvolvimento de Software - 7

abordagem é a aquisição do know-how de software através de programas de mensuração específicos dentro de uma empresa e a captura dessas experiências ganhas e a reutilização destas em projetos futuros. Isso é suportado pela Experience Factory [BCR94a,Bas92], uma unidade organizacional que facilita o desenvolvimento do projeto através da análise e síntese de todos os tipos de experiência, agindo como um repositório para essas experiências, que possa prover dados experienciais para vários projetos futuros ainda em vista. Para a aplicação do QIP, o estabelecimento de um programa de mensuração que provê os dados exigidos e interpretações, é imperativo. Utilização do GQM no Desenvolvimento de Software - 8

3 ABORDAGEM GOAL/QUESTION/METRIC Mensuração é uma tecnologia chave de todo programa de melhoramento. O paradigma Goal /Question /Metric (GQM) [BDR97,BCR94b,BW84] é uma abordagem orientada a metas para a mensuração de produtos e processos de software, suportando a definição top-down de um programa de mensuração e a análise e interpretação bottom-up dos dados de mensuração. Ela foi utilizada com sucesso em diversas empresas, como NASA-SEL (EUA), Robert Bosch GmbH (Alemanha) [BDT96], Allianz Lebensversicherungs-AG (Alemanha) [GRR94], Digital SPA (Itália) [FLM96], Motorola [Das92], Schlumberger (Holanda) [HOLR96]. O paradigma GQM é baseado no requisito de que a mensuração deveria ser orientada a metas, p.ex., toda coleta dos dados deve ser baseada num fundamento lógico, que é documentado explicitamente. Essa abordagem tem várias vantagens: ela suporta a identificação das métricas úteis e relevantes tanto quanto suporta a análise e interpretação dos dados coletados. Ela permite um assessoramento da validade das conclusões a que se chegou e evita a resistência contra programas de mensuração. Meta: Analise o sistema de software com respeito à confiabilidade de ponto de vista da equipe na empresa xyz. Definição Q1 Q2 Q3: Como é a distribuição dos defeitos com respeito à fase de detecção? M6: Numero total de defeitos detectados Interpretação M1 M2 M3 M5: Numero dos defeitos detectados por fase Figura 3. Abordagem GQM Para apresentar essas vantagens, programas de mensuração baseados em GQM devem ser planejados e executados de acordo com os seguintes princípios: A tarefa de análise a ser executada precisa ser especificada precisamente e explicitamente através de uma meta de mensuração. Medidas precisam ser derivadas de uma forma top-down baseada em metas e perguntas. Uma estrutura de metas e perguntas não pode ser adaptada de forma retroativa a um conjunto de medidas existente. Utilização do GQM no Desenvolvimento de Software - 9

Cada medida precisa ter um fundamento lógico subjacente que é documentado explicitamente. O fundamento lógico é usado para justificar a coleta dos dados e para guiar a análise e interpretação. Os dados que são coletados com respeito às medidas precisam ser interpretados de uma forma bottom-up no contexto das metas GQM e das perguntas. Isso dá suporte à interpretação dos dados para as limitações e suposições do objeto através de um fundamento lógico de cada medida. As pessoas que vão utilizar os resultados do programa de mensuração e a partir de cujo ponto de vista a meta de mensuração é formulada, precisam ser envolvidas profundamente na definição e interpretação do programa de mensuração. Elas são os reais peritos com respeito ao objeto e ao enfoque de qualidade investigado no programa de mensuração e portanto provêem interpretações válidas no ambiente especifico. Utilização do GQM no Desenvolvimento de Software - 10

4 GQM- PASSO A PASSO O método GQM descreve o planejamento e execução de um programa de mensuração baseado no paradigma GQM. Com base nas experiências de aplicações do paradigma GQM em várias empresas, o processo GQM foi modelado em detalhe [GHW95]. Padrões suportando o método GQM foram desenvolvidos [Rom91, Bas92, GRR94], p.ex., para definição das metas. Diretrizes e heurísticas para a aplicação prática do método GQM são dadas em [BDR97, GRR96, NAS94]. Um exemplo completo de um programa de mensuração incluindo todos os artefatos relacionados é ilustrado em [GHW95]. A seguir, uma visão geral do método GQM é dada, a qual é então descrita passo-a-passo com base no modelo de processo GQM [GHW95]. Outras experiências específicas de empresas com a aplicação do método GQM são reportadas em [Das92, FLM96, SOL95, Sol95]. O escopo do método GQM inclui o planejamento, a execução do programa de mensuração, e a captura das experiências ganhas durante esse programa sob forma de modelos. As fases do processo GQM são orientadas ao Paradigma de Melhoria de Qualidade (QIP). Uma visão geral dos passos do processo de um programa de mensuração é dada na figura 4. No começo do programa de mensuração, um estudo prévio é realizado para encontrar modelos de experiência relevantes baseados nas metas e características da organização e dos projetos. Um projeto piloto para a introdução do programa de mensuração é selecionado e caracterizado. Com base nessa informação, uma meta a ser atingida pelo programa de mensuração é especificada, definindo precisamente objeto, objetivo, enfoque de qualidade, ponto de vista e contexto da análise. Com respeito à meta, um conjunto das medidas relevantes é derivado via perguntas e modelos, resultando em um plano GQM consistindo de uma meta, perguntas, modelos e medidas. Capturar experiências Estudo prévio Análise e Interpretação Identificação de metas GQM Desenvolvimento de plano GQM Coleta de dados Desenvolvimento de plano de mensuração Figura 4. Visão geral do processo GQM Utilização do GQM no Desenvolvimento de Software - 11

Um plano de mensuração é definido pela integração das medidas definidas no plano GQM e do plano de projeto de software através da determinação de quando, como, e por quem os dados requeridos podem ser coletados. Durante a fase da execução do programa de mensuração, os dados são coletados de acordo com o plano de mensuração. Os dados coletados são analisados e interpretados com respeito às metas GQM de acordo com o plano GQM em feedback sessions. Os resultados de análise e interpretação são acondicionados em modelos reutilizáveis. Ao se introduzir mensuração baseada em GQM em uma organização, o método ainda precisa ser adaptado ao ambiente específico. Assim, o suporte oferecido pelo método GQM, incluindo descrições de processos, padrões e diretrizes não é obrigatório. Essencial para a aplicação da abordagem GQM são os princípios fundamentais (como descrito acima) que necessitam ser considerados para realizar um programa de mensuração baseado em GQM com sucesso. No planejamento e execução de um programa de mensuração dois papéis principais são diferenciados: a equipe de garantia de qualidade e a equipe do projeto (incluindo o gerente do projeto). A equipe de garantia de qualidade tem conhecimento detalhado do processo GQM e é responsável pelo planejamento e execução do programa de mensuração. A equipe do projeto é responsável pelo desenvolvimento de software no projeto atual e só participa em alguns passos do programa de mensuração. Nas próximas seções segue-se uma descrição detalhada de cada passo de um programa de mensuração baseado em GQM. Diretrizes são dadas com base em experiências de empresas aplicando essa abordagem na prática. 4.1 ESTUDO PRÉVIO O objetivo do estudo prévio é a coleta de informação que é pertinente à introdução de um programa de mensuração na organização. Esta informação é usada para apoiar a seleção de um projeto piloto para a introdução de um programa de mensuração e a definição das metas de mensuração. Primeiro, precondições e restrições relacionadas à introdução do programa de mensuração são identificados. Isto pode ser feito baseado em documentos já existentes (por exemplo o manual do processo de software), ou - se disponível - também em experiências de programas de mensuração anteriores. Além disso, a organização é caracterizada (p.ex. domínio de aplicação, setor de negócios), e as metas de melhoria organizacionais são identificadas (p.ex. reduzir o número das falhas nos sistemas de software entregues). Projetos potenciais para a aplicação de mensuração são caracterizados (p.ex. duração, representatividade com respeito aos projetos da organização). Com base nessas informações, um projeto piloto é selecionado para a introdução de um programa de mensuração baseado em GQM. Utilização do GQM no Desenvolvimento de Software - 12

Diretrizes É muito importante que as pessoas envolvidas no projeto piloto que participaram no programa de mensuração sejam motivadas e concordem com a introdução de um programa de mensuração. Então, estas pessoas têm de ser convencidas dos benefícios do estabelecimento de um programa de mensuração baseado em GQM. Isto pode ser feito (p.ex. no contexto de um seminário de mensuração) apresentando os benefícios de um programa de mensuração atingidos em outros projetos ou contextos, mostrando como o trabalho deles pode ser apoiado, quais problemas poderiam ser resolvidos e - se disponível - histórias de sucesso de outros projetos. A caracterização organizacional e a caracterização de projeto podem ser apoiadas pelo uso de questionários adaptados ao ambiente específico. Um exemplo de tal questionário pode ser encontrado em [GHW95]. As metas de melhoramento organizacionais são derivadas das metas de negócio e estratégias da empresa. Isto pode ser apoiado mais adiante pela determinação dos fatores críticos de sucesso e áreas de problema existentes na organização. A existência de um modelo de processo de software é essencial para planejar e executar um programa de mensuração [BDT96]. Se nenhum existe refletindo o processo de software usado no projeto atual, um modelo de processo descritivo tem que ser desenvolvido durante esta fase do programa de mensuração. Quando introduzindo mensuração baseada em GQM, o projeto piloto deveria ser selecionado de acordo com os seguintes critérios [BDR97, GHW95]: - deveria ser um projeto típico para a organização - é possível de motivar a equipe de projeto para a aplicação de novas tecnologias - escolher um projeto com necessidade de melhoramento - considere os recursos dedicados ao programa de mensuração. Em geral, a duração do projeto e o tamanho da equipe deveria ser razoavelmente pequena. - o projeto não deveria possuir muito riscos. Durante esse passo os participantes do programa de mensuração têm de ser treinados de acordo com os papéis deles na mensuração. O treinamento deveria cobrir o paradigma GQM (para a compreensão básica) e uma apresentação dos passos nos quais eles participarão ativamente. 4.2 IDENTIFICAÇÃO DE METAS GQM Com base nas metas organizacionais e do projeto piloto, as metas a serem alcançadas pelo programa de mensuração são determinadas, como uma base para o desenvolvimento de um programa de mensuração efetivo. Utilização do GQM no Desenvolvimento de Software - 13

Com base na informação de contexto coletada no estudo prévio, metas GQM são derivadas das metas de negócio, das metas estratégicas da organização, ou mais diretamente das metas organizacionais de melhoramento com respeito aos problemas conhecidos. As metas atingidas pela mensuração são formuladas como metas GQM em termos de [BDR97,BCR94]: Dimensão Definição Exemplo Objeto de Estudo O que será analisado? Processo de desenvolvimento, teste, documento de projeto, sistema de software Objetivo Enfoque de Qualidade Ponto de Vista Contexto Porque o objeto será analisado? Qual atributo do objeto será analisado? Quem será usar os dados coletados? Em qual ambiente está localizado? Caracterização, avaliação, predição, monitora, controle, modificação Confiabilidade, custos, correção, remoção dos defeitos, modificações, manutenibilidade Gerente do projeto, desenvolvedor, equipe de garantia de qualidade, usuário, gerente Projeto A, departamento x, O modelo da meta GQM foi desenvolvido para indicar a informação necessária para a meta da mensuração e assim apóia a atividade de definir a meta. A mensuração pode ser direcionada aos vários objetivos [BDR97]: Caracterização visa formar um instantâneo do estado/performance atual dos produtos de processos de software. Avaliação visa comparar e avaliar produtos e processos de software. Monitorando visa seguir as tendências/evolução do estado/performance de processos e produtos. Predição visa identificar relações entre vários fatores de processo e produto, usando estas relações para predizer atributos externos pertinentes a produtos e processos. Controle visa identificar relações causais que influenciam o estado/performance de processos e produtos. Modificação visa identificar relações causais para mudar o processo de software para obter qualidade de produto e produtividade de processo mais alta. Utilização do GQM no Desenvolvimento de Software - 14

Para se concentrar nas metas mais importantes, as metas GQM identificadas são priorizadas com respeito às necessidades da organização e do projeto piloto e as mais importantes são selecionadas e aplicadas no projeto piloto. Diretrizes Para considerar o conhecimento e as experiências de todas as pessoas envolvidas no projeto piloto, as metas GQM deveriam ser identificadas durante uma sessão de brainstorm. Isto é também importante devido ao fato de que o programa de mensuração só será aceito, se as pessoas sentem as necessidades delas refletidas e expressas pelo programa de mensuração. As seguintes questões, que implicitamente consistem numa caracterização de projeto e organização e identificação de meta de melhoramento, podem estimular a discussão para a definição de meta [Sol95]: 1. O que são as metas estratégicas da organização? 2. Que forças têm impacto nas metas estratégicas? 3. O que são as estratégias para alcançar as metas estratégicas da organização? 4. Como você pode melhorar a performance? O que são as preocupações principais (problemas)? 5. O que são as metas de melhoria? 6. Como você pode alcançar as metas de melhoria? 7. O que são possíveis metas de mensuração? Quais metas de mensuração serão selecionadas? Na definição de dimensões de metas os seguintes aspectos deveriam ser considerados [BDR97, GHW95]: - Objeto de Estudo deveria enfocar produtos ou processos com necessidade de serem compreendidos melhor. O modelo de processo pode ajudar a identificar e definir objetos relevantes. Objetivo deveria ser adaptado ao nível de compreensão dos problemas na empresa (p.ex. antes de começar modificar é necessário caracterizar a situação atual). O objetivo também precisa ser adaptado à estabilidade do processo e ao controle da performance. Enfoque de Qualidade deveria ser consistente com a prioridade de metas de melhoramento organizacionais e deveria enfocar os pontos fracos mais urgentes em relação ao processo de software. Ponto de Vista. Se GQM está sendo usado pela primeira vez é recomendável definir metas GQM sob três pontos de vista diferentes: - ponto de vista das pessoas técnicas que executam o projeto, p. ex. desenvolvedor - ponto de vista do gerente do projeto Utilização do GQM no Desenvolvimento de Software - 15

- ponto de vista das pessoas que pelo para o programa de mensuração, p.ex., gerente sênior Isto assegura que todas as pessoas pertinentes serão envolvidas e recebem benefícios do programa de mensuração que em troca aumentará aceitação e cooperação de todas. As metas GQM deveriam ser selecionadas rigorosamente se concentrando só nos assuntos mais centrais e algumas metas importantes para assegurar o sucesso do programa de mensuração. É importante começar com poucas metas, para manter os custos baixos e mostrar a usabilidade da mensuração antes de amplificar o programa. 4.3 DESENVOLVIMENTO DO PLANO GQM Planos GQM contém a informação necessária para planejar mensuração e analisar e interpretar os dados coletados [BDR97]. De acordo com as metas GQM, um plano GQM é desenvolvido para cada meta GQM selecionada. Um plano GQM consiste de uma meta GQM e um conjunto das perguntas, modelos e medidas [BDR97,BCR94]. O plano define precisamente porque as medidas são definidas e como elas serão usadas. As perguntas identificam a informação necessária para atingir a meta e as medidas definem operacionalmente os dados a serem coletados para responder as perguntas. O modelo usa os dados coletados como entrada para gerar respostas às perguntas. Para determinar as perguntas relevantes com respeito à meta, entrevistas são feitas. O objetivo das entrevistas é adquirir o conhecimento implícito das pessoas envolvidas. Essas entrevistas são feitas com as pessoas declaradas no ponto de vista da meta GQM, p.ex. desenvolvedores ou o gerente de projeto. O conhecimento adquirido durante a(s) entrevista(s) é usado como uma base para a derivação das perguntas, modelos e medidas relevantes à meta. 4.3.1 Entrevistas GQM As entrevistas deveriam ser feitas com as pessoas que são especificadas na dimensão «ponto de vista» da meta GQM. Isto assegura que a informação pertinente é ganha das pessoas que são os peritos em relação à perspetiva da meta de mensuração. Durante a entrevista, deveriam ser enfocados os seguintes tópicos [GHW95,GRR94]: Fatores de Qualidade: O que significa o enfoque de qualidade especificado na meta GQM ao entrevistado? Hipótese de Linha-Base: Para cada fator de qualidade que pertence ao enfoque de qualidade é declarado: qual é a estimativa do entrevistado no estado atual ao fator de qualidade? Fatores de Variação: Quais fatores ambientais variáveis têm possivelmente um impacto nos fatores de qualidade? Utilização do GQM no Desenvolvimento de Software - 16

Impacto na Hipótese de Linha-Base: Para cada fator de variação é declarado: Qual é a estimativa do entrevistado do impacto do fator de variação no fator de qualidade? Uma ferramenta para a aquisição e estruturação de conhecimento durante as entrevistas é o Abstraction Sheet [GRR94]. O abstraction sheet é um documento de uma página com quatro quadrantes, um para cada dos tópicos mencionados acima. No cabeçalho é declarada a meta GQM (veja figura 5). O abstraction sheet facilita a comunicação entre a equipe de GQM e a equipe de projeto durante a entrevista e a revisão do plano GQM representando uma visão simplificada do plano GQM. O conhecimento adquirido durante uma entrevista é documentado em um abstraction sheet. Para completar a compreensão com respeito a uma meta GQM, o conhecimento resultando de varias entrevistas com respeito à meta é resumido em um abstraction sheet. Conflitos e inconsistências que surgem juntando a informação tem que ser resolvidos em follow-up interviews. Objeto Objetivo Enfoque de Qualidade confiabilidade Processo de caracterizar software Fatores de Qualidade - número total de defeitos - número dos defeitos por criticalidade (não-crítico, crítico) - número de defeitos por fase de ciclo da vida introduzido (REQ, HLD, LLD/IMP) - esforço total de rework (em horas) Ponto de Vista desenvolvedor Contexto Empresa x, Projeto A Fatores De variação - tipo de inspeção de código - experiência de pessoas da equipe de desenvolvimento Hipótese de Linha-Base - número total de falhas: 120-75% não-crítico, 25% crítico - REQ 10, HLD 20, LLD/IMP 40, TESTE 30 - esforço total de rework: 1000 h Impacto na Hipótese de Linha-Base - com ad-hoc inspeções de código menos defeitos serão detectados do que com outros tipos de inspeções. - pessoas da equipe de desenvolvimento mais experientes introduzem menos defeitos. Figura 5. Exemplo de um Abstraction Sheet Utilização do GQM no Desenvolvimento de Software - 17

Diretrizes Para capturar todas as informações relevantes, entrevistas com varias pessoas representando o ponto de vista declarado na meta deveriam ser feitas. E, para esclarecer pontos abertos várias entrevistas em seguida poderiam ser necessárias. Durante as entrevistas possivelmente pode ficar óbvio que as metas GQM selecionadas não cobrem adequadamente os objetos/objetivos a serem medidos. Neste caso, primeiro as metas GQM têm que ser redefinidas. A realização de entrevistas individuais ampliam o conhecimento adquirido. Se isto é impossível, entrevistas podem acontecer em grupos pequenos dependo da dinâmica do grupo pertinente com respeito à possibilidade de discussões abertas e eventuais controvérsias. Os entrevistados precisam ser motivados, treinados e informados sobre o programa de mensuração e qual informação é esperada deles nas entrevistas. No começo confiança precisa ser assegurada e deve ser explicado como a informação será usada. O entrevistador precisa ser bem preparado ao respeito à meta específica, o processo de software a terminologia usados no projeto piloto. Experiências de programas de mensuração semelhantes podem ajudar na preparação das entrevistas. A tarefa do entrevistador é a aquisição de conhecimento, ele não deveria influenciar o entrevistado em qualquer direção. Modelos organizacionais, p.ex. o modelo de processo de software pode ser usado como ponto de referência na entrevista, se isto é considerado útil pelo entrevistado. 4.3.2 Refinamento de Plano GQM O objetivo é a definição quantitativa da meta GQM em um conjunto de medidas via perguntas e modelos, com base nos fatores de qualidade e fatores de variação adquiridos durante as entrevistas. Neste passo o plano GQM é desenvolvido. Primeiro, as perguntas são derivadas, expressando a necessidade de informação em linguagem natural. Um exemplo de uma pergunta é: Quantos defeitos são detectados dependente do tipo da inspeção usada? A resposta para uma pergunta pode ser atingida através dos dados coletados e interpretados para as medidas derivadas através de modelos de qualidade. As perguntas são derivadas com base na informação documentada no abstraction sheet. Para cada fator de qualidade no abstraction sheet, uma ou mais perguntas são formuladas Utilização do GQM no Desenvolvimento de Software - 18

expressando a necessidade de informação relacionada ao fator de qualidade. A informação contida na seção fatores de variação do abstraction sheet é usada para derivar perguntas com respeito ao contexto pertinente. Um exemplo é dado na figura 6 com base no abstraction sheet mostrado em figura 5. Definição de Processo Q1. Tem a experiência da equipe de desenvolvimento um impacto no número de defeitos? Hipótese: as pessoas da equipe mais experientes introduzem menos defeitos. Q1.1. Qual é a distribuição de experiência entre as pessoas da equipe de desenvolvimento? Hipótese: 30% 3 ou mais anos, 20% 1-3 anos, 50% menos de um ano de experiência Q1.2. Qual é o número total de defeitos informados antes de entrega? Hipótese: haverá aproximadamente 120 defeitos detectados antes de entrega. Definição de qualidade Q2. Qual é o número total de defeitos informados antes de entrega? Hipótese: haverá aproximadamente 120 defeitos detectados antes de entrega. Q3. Qual é a distribuição de defeitos informados antes de entrega por criticalidade? Hipótese: 75% defeitos não-crítico, 25% defeitos críticos. Q4. Qual é a distribuição de defeitos por fase de ciclo de vida da introdução detectados antes de entrega? Hipótese: REQ: 10%, HLD 20%, LLD/IMP: 40%, TESTE 30% Q5. Qual é o total do rework antes da entrega? Hipótese: 1000h Figura 6. Exemplo de perguntas do plano GQM Para a operacionalização dos planos GQM, modelos de qualidade precisam ser construídos. Os atributos abstratos dos artefatos avaliados, p.ex., reutilizabilidade de componentes, precisam ser definidos numa forma operacional adequada às metas e considerando suposições plausíveis sobre o meio ambiente em modelos descritivos [BDR97]. Comparações e avaliações precisam ser definidas precisamente pelo modelos de avaliação, p.ex. avaliando a complexidade de um componente em relação aos outros componentes do domínio. Para fazer predições modelos preditivos precisam ser construídos. Isso inclui a consideração da forma funcional do modelo, a técnica usada para a construção e fatores de influência. Utilização do GQM no Desenvolvimento de Software - 19

Modelo preditivo: Efetividade de inspeções Contexto: empresa xyz, tipo de projeto abc Suposições: Quanto maior o documento inspecionado, maior é o efeito de fadiga, e mais complexa é a inspeção, i.e., sua carga cognitiva. Descrição do modelo: O modelo prediz a efetividade de inspeções. Atributos: Medidas: efetividade e = a * (tamanho de documento)^b [parâmetros de a,b; b < 0] tamanho de documento número de operações especificadas Figura 7. Exemplo de um modelo preditivo Em seguida, um conjunto de medidas é derivado que é satisfatório para alimentar o modelo e responder a perguntas em seu contexto determinado. Medidas são definições operacionais de atributos, como p.ex. fatores de qualidade. Os atributos a serem medidos para responder as perguntas respectivas são operacionalizados através de modelos de qualidade. A definição das medidas inclui a definição do nível da mensuração e a faixa de valores aceitáveis. O nível da mensuração (p.ex. nominal, ordinal, intervalo, racional) pode suportar a seleção de procedimentos adequados de análise de dados. A faixa de valores das informações determina quais valores são esperados e ajuda identificar valores anormais. Para dados no nível intervalo ou racional, a unidade precisa ser definida. Para níveis nominais e ordinais de escala limitada, as semânticas de todas as categorias precisam ser descritas explicitamente. Utilização do GQM no Desenvolvimento de Software - 20

Q1. Qual é o número total de defeitos antes de entrega? Modelo: Número total de defeitos pode ser calculado com base no número total dos relatórios de defeitos. Figura 8. Exemplos de medidas Problemas, assuntos abertos, e inconsistências que surgem durante o refinamento do plano GQM têm que ser novamente resolvidos durante entrevistas. Quando o plano GQM é completamente refinado, tem que ser revisado com respeito à correção e compleção. Diretrizes M1.1 contador de relatórios de defeitos informados antes de entrega [racional: inteiro] Q2. Qual é a distribuição de defeitos informados antes da entrega por criticalidade? Modelo: Distribuição = (# defeitos críticos/ total # defeitos, # defeitos não critico/ total # defeitos) critico: breakdown completo do sistema; não critico: impossível de executar uma ou mais de funções F1-F6. M2.1 classificação dos relatórios de defeitos encontrados antes da entrega por criticalidade [ordinal:não-crítico;crítico; outros] M2.2 número total dos defeitos detectados antes de entrega [racional: inteiro] Q3. Qual é a distribuição de defeitos por fase de ciclo de vida da introdução detectados antes de entrega? Modelo: Distribuição = (# defeitos em REQ/ total # defeitos,# defeitos em HLD/ total # defeitos, # defeitos em LLD/IMP/ total # defeitos) M3.1 contador de defeitos por fase de ciclo de vida onde o defeito foi introduzido [nominal: REQ, HLD, LLD/IMP] Q4. Qual é o esforço total de rework? Modelo: esforço de rework = (esforço de isolar defeito + esforço de corrigir defeito) M4.1 Para todos os defeitos informados antes de entrega: esforço para isolar as causas de defeitos [racional: inteiro (homens-hora)] M4.2 Para cada defeito informados antes de entrega: esforço para corrigir o defeito [racional: inteiro (homens-hora)] As hipóteses com respeito aos fatores de qualidade especificam a expectativa. O valor da hipótese pode ser baseado na intuição dos entrevistados. A captura de uma hipótese apóia mostrar a utilidade da mensuração, por apontar discrepâncias entre as expetativas e os dados coletados. A representação gráfica da hipótese facilita a discussão durante as entrevistas. Capturar explicitamente o impacto de um fator de variação sobre o fator de qualidade ajuda a concentrar-se em fatores relevantes e prevenir que fatores de variação demais sejam incluídos no plano GQM e, consequentemente, que o plano fique muito complexo. O uso de comentários para perguntas, modelos e medidas é encorajado, p.ex., explicando porque uma certa pergunta ou medida está incluída no plano GQM. Utilização do GQM no Desenvolvimento de Software - 21

Outro material disponível na organização, como p.ex., o modelo de processo de software pode prover informação requerida para a derivação das perguntas, modelos e medidas. O plano GQM tem que ser refinado iterativamente. Durante o primeiro passo normalmente o plano GQM não pode ser completado até o nível de medidas. O processo (e eventualmente as entrevistas) será iterado enquanto que o plano GQM não for completado e passe para a revisão subseqüente. 4.4 DESENVOLVIMENTO DO PLANO DE MENSURAÇÃO O objetivo principal do desenvolvimento do plano de mensuração é a integração apropriada de medidas no plano do projeto. Para cada medida identificada nos planos GQM do programa de mensuração, é determinado quando, como e por quem os dados são coletados de acordo com o processo de software. Critérios importantes que precisam ser considerados no desenvolvimento dos procedimentos de coleta de dados são: a confiabilidade dos dados coletados e a intrusividade da coleta dos dados [BDR97]. Os custos relacionados à coleta dos dados deveriam ser minimizados até onde for possível. Para cada medida, o instante de tempo precisa ser determinado, o qual é o melhor para coleta dos dados. Dependente de objetivo de mensuração e dos dados coletados, três tipos principais de estratégias podem ser adotados para a coleta dos dados [BDR97]: periodicamente (p.ex. coleta de dados de esforço por dia ou semana) começo/fim de atividades/fases (p.ex. grau de detecção de defeitos no fim da inspeção) transição de estado de artefato (p.ex. complexidade de componentes quando eles entram na gerência de configuração) Na definição do instante de tempo é necessário definir o nível de granularidade de updates em caso de uma coleta periódica. A definição de instantes de tempo orientada às atividades é feita com base no modelo de software que descreve as atividades e artefatos usados ou produzidos pelos processos. Diagramas de transição de estado de produtos podem ajudar definir os instantes de tempo relacionados às transições de estados de artefatos. Quando um cronograma para a coleta foi definido, é determinado quem pode ou deve coletar os dados. A primeira decisão é se existe uma ferramenta para automatizar a coleta de dados. Se não, subjetividade não poderá ser prevenida. Assim a determinação do/a papel/pessoa certo/a para a coleta de dados é muito importante. Aqui os seguintes critérios deveriam ser considerados [BDR97]: Expertise: Quem tem a expertise técnica/gerencial para prover os dados com precisão? Utilização do GQM no Desenvolvimento de Software - 22

Preconceito: Há qualquer razão para o provedor de dados mostrar qualquer preconceito nos dados ele provê? Acesso: Quem tem acesso ao objeto que está sendo medido? Custo: Pode o tempo gasto pela pessoa para coleta de dados ter efeitos críticos nos custos do projeto? Disponibilidade: A pessoa está disponível para a coleta de dados? Motivação: A pessoa está interessada no programa de mensuração? Além de se determinar quem coletará os dados, precisa ser determinado quem é responsável pela garantia de qualidade e o armazenamento dos dados. O projeto de instrumentos de mensuração é crucial para receber dados confiáveis. Três categorias de instrumentos de coleta de dados podem ser identificadas: ferramentas (p.ex. analisadores de código estáticos) questionários entrevistas estruturadas Categoria Nome Descrição Questionários projeto de Questionário de Projeto Registros que coletam informação de projeto geral no começo do projeto Questionário de Estimativas do Projeto Registra as estimativas de parâmetros de projeto; preenchido pelo gerente de projeto Questionários esforço de Questionário de Recursos de Pessoal Provê informação sobre horas gastadas em um projeto e como o esforço foi distribuído; é preenchido semanalmente pelo desenvolvedor de software Questionários manutenção de Questionário de Mudança Caracteriza a manutenção executada em resposta a um pedido de mudança Relatório de Mudança Registra informação sobre unidades mudadas; é preenchido cada vez que uma unidade configurada é modificada. Figura 9. Exemplos de tipos de questionários [NAS94] A decisão sobre qual instrumento é utilizado depende aos dados coletados. Ferramentas podem ser usadas para medidas objetivas de artefatos (p.ex. linhas de código), questionários e entrevistas estruturadas para medidas de processo (p.ex. esforço de rework) e medidas subjetivas de artefatos (p.ex. usabilidade de uma interface). Utilização do GQM no Desenvolvimento de Software - 23

Em relação ao desenvolvimento de questionários, as medidas coletadas pelos questionários são ordenadas de acordo com quando dados serão medidos e quem provê os dados. A intenção é agrupar medidas em um questionário só, que são selecionadas ao mesmo tempo e com a mesma pessoa. Com base nesses agrupamentos os questionários são desenvolvidos. Em geral, um questionário contém informação de identificação, p.ex., nome do projeto, data de coleta de dados (veja figura 10). Para cada medida a ser coletada no questionário, uma pergunta é formulada. A resposta é definida, determinando a faixa e, se necessário, a unidade. Nome Esforço do projeto Criticalid ade de defeitos Introduçã o de defeito Objeto/ atributo Projeto sw/esforço defeito/ criticalida de Defeito/fas e_intro Unidad e [homen s-mês] Nível Faixa Evento Instante de tempo Recurso/ coletor de dados racional -- periódica semana Humano/ desenvol vedor -- ordinal nãocrítico, crítico, outros -- nominal REQ, HLD, LLD/IM Figura 10. Exemplo de plano de mensuração Processo _fim Processo _fim processam ento falhas processam ento falhas Humano/ Testador Humano/ desenvol vedor QA responsá vel Gerente do projeto Equipe GQM Equipe GQM instrume nto Question ario_esfo rço Question ario_defe ito Question ario_defe ito Quando o desenvolvimento do plano de mensuração é completado, o plano de mensuração tem que ser revisado com respeito à consistência e perfeição de acordo com o plano GQM e com o processo de software descrito no plano do projeto. Utilização do GQM no Desenvolvimento de Software - 24

Questionário DEFEITOS Projeto: Nome: Data: Seção 1: Falhas Por favor enche um questionário cada vez você detecta uma falha.. 3. Como você classifica o criticalidade da falha? crítico (breakdown completo do sistema) não crítico (impossível de executar uma ou mais de funções F1-F6) outro 4. Qual é o seu papel? Desenvolvedor Testador Usuário Testador Seção 2: Defeitos 7. Qual é o nome do componente onde o defeito foi detectado? Nome do componente: 8. Em qual fase o defeito foi detectado? REQ HLD LLD/IMP TEST 9. Quanto tempo você precisou para corrigir o defeito? h min Figura 11. Exemplo de um questionário Diretrizes Geralmente, os dados deveriam ser coletados o mais cedo possível para assegurar a precisão dos dados. Os questionários deveriam ser projetados para suportar a integração da coleta dos dados nos processos. A coleta de dados deveria ser percebida como uma parte das atividades regulares de processo de software. Os questionários deveriam ser projetados de forma que os dados possam ser providos facilmente: - Defina claro quais os dados a serem providos - Use terminologia e conceitos organizacionais - Explique as categorias de classificações usadas Use estrutura lógica para a ordem das perguntas e agrupe perguntas em torno do tema Para diminuir o overhead da coleta de dados, use checklists ao invés de respostas abertas, quando possível. Utilização do GQM no Desenvolvimento de Software - 25

Faça um pré-teste dos questionários antes a coleta de dados começa. Esse teste prova se existe evidencia para a validade de dados coletados. 4.5 COLETA DE DADOS Durante a fase de execução do programa de mensuração, os dados são coletados de acordo com o plano de mensuração. Quando os dados foram coletados, têm de passar por um processo de garantia de qualidade antes de poderem ser armazenados ou analisados. O processo de garantia de qualidade de dados coletados aborda os seguintes assuntos: Completude. Precisa ser garantido que todos os questionários foram submetidos e estão completos (isso significa, se todos os dados necessários foram providos). Se faltam alguns dados, a causa precisa ser determinada, p.ex., as perguntas não são aplicáveis no contexto específico, não são compreensíveis, ou consideradas irrelevantes. Plausibilidade. Precisa ser controlado se os dados são do tipo especificado (p.ex. campos numéricos contendo valores não numéricos) e a plausibilidade desses valores (p.ex. um valor de 100 horas para o esforço de uma pessoa por semana não é plausível). Se o processo de garantia de qualidade descobre dados defeituosos ou faltantes, estes dados deveriam ser discutidos com os coletores de dados. Quando possível, eles têm de corrigir os dados. Se alguns dados específicos apresentam uma baixa confiabilidade regularmente, os procedimentos de coleta de dados e/ou treinamento dos coletores deveriam ser reconsiderados, avaliados e eventualmente melhorados. Os dados válidos são armazenados no banco de dados de mensuração disponíveis para a análise. Depois que os dados foram incluídos no banco de dados, é necessário controlar se as entradas correspondem os dados originais. Diretrizes O tempo entre a coleta e garantia de qualidade de dados não deveria ser muito longo, para permitir a correção, em caso da coleta de dados incompletos ou falsos. Se dados históricos são usados no programa de mensuração para uma análise postmortem, este passo de processo só contém a garantia de qualidade dos dados já disponíveis. A garantia de qualidade e o armazenamento dos dados coletados manualmente deveriam ser feitos com grande cuidado, uma vez que este processo é uma fonte de erros. Este Utilização do GQM no Desenvolvimento de Software - 26

processo pode ser supérfluo ou (pelo menos parcialmente) automatizado para dados que são coletados on-line. 4.6 ANÁLISE DOS DADOS Para análise de dados podem ser aplicados p.ex. testes ao respeito às hipóteses propostas no plano GQM. O objetivo da análise é identificar padrões e relações entre atributos para permitir o estabelecimento de linhas-base e a identificação de áreas problemáticas. A análise estatística pode ser aprimorada através de uma análise qualitativa, p.ex. usando a teoria de Rough Sets [Ruh96, Paw91]. O objetivo é gerar regras descrevendo e agregando resultados experimentais. A teoria de Rough Sets deriva regras se-então agregadas que podem ser usadas formalmente como a base para a integração de conhecimento de um perito humano com as regras derivadas da análise de dados experimentais [CGF97]. Um exemplo dessas regras pode ser, SE (Tipo de versão = A) E (Número de modules novos = baixo) E (Número de LOC mudado = médio) ENTÃO (esforço = muito alto). A análise de dados é guiada pelo plano GQM. Os dados atuais são comparados com as hipóteses de linhas-base. As hipóteses sobres as relações entre os fatores de qualidade e os fatores de variação são validadas e quantificadas [BDR97]. Comparação com linhas-base Os dados coletados podem ser usados para construir linhas-base quantitativas para os projetos de software da organização. Em geral, é interessante comparar as linhas-base medidas atualmente com as hipóteses esperadas que são definidas nos abstraction sheets. Isto permite investigar divergências e ativar discussões entre os desenvolvedores e gerentes para a interpretação dos dados. Além disso, essas divergências provavelmente induzem a investigações dos dados adicionais na procura por fatores que explicam as diferenças. Validação de hipóteses sobre o impacto de fatores de variação Dependendo do propósito da meta GQM, estratégias diferentes são aplicadas [BDR97]. Para o objetivo de predição, as hipóteses sobre o impacto de fatores de variação são testadas com respeito à seguinte pergunta: o fator de variação teve o impacto esperado no fator de qualidade? Se o impacto esperado não pode ser verificado, a exclusão do fator de variação da coleta de dados é considerada, assumindo o uso de uma técnica de modelagem adequada e um conjunto de dados apropriado. Se o impacto esperado é observado, a relação identificada pode ser usada para construir modelos novos ou mais confiáveis para a administração de projeto, garantia de qualidade etc. Utilização do GQM no Desenvolvimento de Software - 27