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

Para o objetivo de controle ou mudança, assumindo que o fator de variação já mostrou que tem algum impacto, a análise se concentra em determinar se ou não este impacto é devido a uma relação causal entre o fator de qualidade e o fator de variação. Os resultados da análise de dados coletados são uma entrada essencial para a interpretação de dados. 4.7 INTERPRETAÇÃO DOS DADOS O dados coletados e analisados são interpretados no contexto da meta de mensuração. A interpretação dos dados coletados é feita em feedback sessions, reuniões dos representantes do ponto de vista especificado na meta e coletores de dados. O objetivo dos feedback sessions é interpretar os dados coletados com pessoal que tem a expertise necessária. Assim os dados analisados são apresentados aos participantes da reunião, interpretações possíveis discutidas e modificações para melhoramento planejadas [BDR97, HOR96, GHW95]. Preparo do material de apresentação O material a ser apresentado e discutido durante o feedback session é preparado com base nos dados coletados no contexto do plano GQM. O plano GQM apoia a análise e a interpretação dos dados sendo seguido bottom-up. As perguntas colocadas no plano GQM serão discutidas no feedback session com base nos dados coletados com respeito às perguntas. Para isso, os dados coletados são combinados às medidas no plano GQM e processados como descrito no modelo. Esses resultados são colocados junto com as perguntas correspondentes e comparados às hipóteses iniciais. :O que é a distribuição das falhas por papel de detectador? Papel valores atuais Test Group hipótesis User Tester Engineer 10 20 30 40 50 60 70 80 percentage de falhas Figura 12. Exemplo de material de feedback session Diretrizes Project X Feedback session 11.03.94 Slide 4 of 19 O material de feedback session deveria indicar as perguntas do plano GQM que ele pretende responder, a hipótese correspondente e o número de pontos de dados subjacentes. Utilização do GQM no Desenvolvimento de Software - 28

Os dados deveriam ser apresentados numa forma fácil de entender, p. ex., evitar listas longas de números etc. Valores inesperados ou pontos de dados que foram interpolados deveriam ser marcados. Material indicando tendências identificadas na análise de dados pode ser adicionado. Aspectos de privacidade com respeito aos dados precisam ser considerados cuidadosamente. É importante que sejam discutidos os assuntos de privacidade de dados abertamente e levada a sério qualquer preocupação de algum dos participantes. Para assegurar privacidade só dados acumulados deveriam ser incluídos no material. O material de apresentação deveria ser entregue antes do feedback session para os participantes. Se o material de apresentação não esta pronto a tempo, é recomendado postergar a reunião em vez de executar o feedback session com pessoas desprevenidas. Execução de feedback sessions O objetivo principal dos feedback sessions é a interpretação de dados de mensuração, a verificação das hipóteses declaradas nos planos GQM, e a identificação das possibilidades para melhoramento do processo de software. Feeback sessions são reuniões de grupo. Participantes são as pessoas que representam o ponto de vista especificado nas metas, e os coletores de dados. O objetivo é aproveitar o conhecimento especifico dessas pessoas sobre o objeto avaliado na interpretação de dados para atingir conclusões válidas no contexto especifico. Além disso, essas pessoas vão ser afetadas pelas mudanças de processo atingindo o melhoramento da qualidade. A identificação e discussão dessas mudanças com todas as pessoas envolvidas nos feedback sessions também ajuda a receber o comprometimento pessoal necessário para a realização dessas mudanças [GHW95, SOL95,Sol95]. O material de apresentação deveria ser estruturado com respeito ao plano GQM e pelo menos contar com todos os pontos de discussão identificados na análise. Isso pode incluir: explicação de divergências existentes entre os dados atuais e as hipóteses especificadas no abstraction sheet discussão de tendências identificadas na análise verificação de relação entre fatores de qualidade e fatores de variação. As pessoas que representam os pontos de vista das metas sabem usar os dados para os propósitos delas, e os coletores de dados sabem quão bem os dados providos foram coletados na verdade e se eles estão de acordo com a finalidade das metas de mensuração. Por exemplo, falsas conclusões podem ser tiradas de um número pequeno de falhas que são informadas, se Utilização do GQM no Desenvolvimento de Software - 29

os coletores de dados não informam que nem toda falha identificada durante o teste foi informada devido à pressão de tempo. Os pontos de vista (e só eles) pode tirar conclusões dos dados que altamente dependem do contexto do programa de mensuração. A razão subjacente que conduz às conclusões e todas as explicações relacionadas deve ser documentada. Isto é necessário para que essas conclusões sejam questionadas e refinadas mais tarde, se conclusões incompatíveis ou complementares são tiradas durante feedback sessions futuros. A interpretação dos dados deveria conduzir à identificação de fraquezas dos processos aplicados e à discussão de possíveis estratégias de melhoramento. Todas as sugestões e mudanças intencionadas para melhoramento precisam ser documentadas em detalhes para assegurar que estas mudanças sejam implementadas de fato. Caso contrário, a conseqüência seria uma motivação imensamente reduzida das pessoas envolvidas. A iniciação de mudanças para alcançar melhoramento do processo de software tem que ser preparada especificando pontos de ação para cada mudança: Qual modificação foi concluída? Quem é responsável pela implantação de modificações? Quando tem a modificação que ser implantada? Uma outra meta importante dos feedback sessions é a avaliação do programa de mensuração. Subseqüentemente aos feedback sessions, a análise pode ser refinada, e se necessário, também o plano GQM e os procedimentos de coleta de dados com base em novas perguntas sugeridas. Se interpretações alternativas ainda existem depois do feedback session, análises adicionais dos dados podem ajudar selecionar a mais provável. Durante os feedback sessions novos problemas podem ser identificados e podem exigir uma análise adicional para dirigi-los corretamente. Também, a necessidade de dados adicionais para responder as perguntas pode ser identificada, necessariamente resultando numa atualização adequada do plano GQM. O feedback session é um meio para avaliar o próprio programa de mensuração: Se alguns dados de mensuração mostram ter pequeno ou nenhum uso ou se referem a uma pergunta que já foi respondida, esses dados (e as perguntas correspondentes) são excluídos do plano GQM. Se os procedimentos de coleta são muito intrusivos, muito demorados, eles devem ser simplificados. Formas diferentes de apresentações de dados podem ser propostas. O foco de interesse pode mudar durante o programa de mensuração. Os feedback sessions são o lugar certo para discutir a modificação ou expansão do programa de mensuração. Utilização do GQM no Desenvolvimento de Software - 30

Em cada destes casos o plano GQM e o plano de mensuração precisam ser atualizados respectivamente. Os feedback sessions são uma parte imperativa do programa de mensuração onde aprendizagem acontece. Os participantes do programa de mensuração são altamente motivados provendo e recebendo feedback. Além disso, as pessoas da equipe do projeto percebem que o programa de mensuração atualmente apoia o trabalho delas, e não avalia-as. Diretrizes Feedback sessions deveriam ser feitos periodicamente (p. ex. cada 6-8 semanas) dependendo da disponibilidade de dados novos. Se os intervalos entre feedback sessions são muito longos, há o risco de se perder o embaloe a motivação no programa de mensuração. A duração de um feedback session é recomendada não levar muito mais tempo do que 3 horas, porque requer um nível alto de atenção por parte do participante. Se os participantes não podem usar os dados, isto pode ser explicado de modos diferentes: - Os resultados não são apresentados numa forma adequada ou compreensível aos participantes. - Os dados não enfocam a meta de medida declarada, p.ex., as medidas definidas não capturam o atributo que aquele pretende medir. - Alguma informação necessária falta, p.ex., alguns fatores de contexto relevantes não estão sendo medidos. Pode ser útil ter acesso on-line ao banco de dados de mensuração durante o feedback session. Assim, alguns pedidos para informação adicional podem ser satisfeitos imediatamente através de acessos on-line ao banco de dados. Toda a interpretação é feita pelas pessoas que representam o ponto de vista da meta. Só estas pessoas podem prover interpretações válidas. Até mesmo, se resultados da análise são incluídos no material de feedback session, as decisões concludentes se aceitar ou rejeitar uma hipótese permanecem atadas a estas pessoas. A implementação da modificação concluída é essencial: caso contrário o programa de mensuração só implica esforço adicional sem qualquer benefício. 4.8 CAPTURA DE EXPERIÊNCIAS O objetivo é capturar explicitamente as experiências ganhas durante o programa de mensuração para reutilizar esse conhecimento em projetos de software futuros [GB97, BCR94a]. Os dados coletados, analisados e interpretados no programa de mensuração são usados para construir modelos organizacionais, como p.ex. modelos de custos e perfis de erro. Utilização do GQM no Desenvolvimento de Software - 31

O impacto do uso de tecnologias em projetos de software é analisado, como p.ex. projeto orientado a objetos ou inspeções. Esses experiências são continuamente sintetizadas a partir de vários projetos para se ganhar uma compreensão geral de produtos e processos na organização. Identificando tipos específicos de projetos, linhas-base são estabelecidas para modelos de qualidade na organização. Modelos de processos e produtos básicos são desenvolvidos para a organização. Essas experiências são capturadas explicitamente em forma de [NAS94]: Políticas e guias de gerência de software, incluindo vários modelos, p.ex. modelos preditivos de esforço. Padrões de desenvolvimento e manutenção de software, definindo produtos, métodos, técnicas e ferramentas que se mostraram benéficas para a organização. Material de treinamento com respeito às tecnologias novas, padrões, ferramentas ou processos introduzidos na organização. Ferramentas e suporte automatizado, ajudando a gerência de software, desenvolvimento e manutenção ou processos de coleta de dados, p.ex. uma ferramenta para estimação de custos com base em modelos locais. Relatórios de estudos de processo enfocando as questões específicas, os métodos aplicados, os resultados medidos e os conclusões a que se chegou. Diretrizes A aprendizagem sistemática e a captura das experiências tem que ser separada do desenvolvimento e manutenção de software [BCR94a]. Os pacotes de experiência têm que ser adaptáveis às necessidades, extensíveis, compreensíveis e acessíveis aos projetos de software futuros. Utilização do GQM no Desenvolvimento de Software - 32

5 EXPERIÊNCAS COM PROGRAMAS DE MENSURAÇÃO BASEADOS EM GQM NA INDÚSTRIA Programas de mensuração baseados em GQM foram aplicados com muito sucesso na indústria. Esse capítulo resume resultados de varias empresas aplicando o GQM na prática. Principalmente, nós enfocamos em resultados e lessons learned obtidos em aplicações em três empresas européias: Robert Bosch GmbH, Digital SPA, and Schlumberger RPS no projeto ESSI-CEMP ("Customized Establishment of Measurement Programs") [CEM96]. Os objetivos principais desse projeto foram: (i) estabelecer programas de mensuração baseados em GQM com respeito à confiabilidade e reutibilidade de produtos e processos de software nessas três empresas. (ii) comparar e analisar os resultados e experiências dos parceiros industriais, e (iii) derivar dados de custo/benefício e linhas mestras e heurísticas para o estabelecimento e disseminação do método na indústria européia. 5.1 BENEFICIOS DOS PROGRAMAS GQM A aplicação dos programas de melhoramento baseados em mensuração obteve grande sucesso na indústria. O QIP, incluindo GQM provou ser um paradigma poderoso para melhoramento sistemático no domínio de software. Enfocando especialmente a abordagem GQM, os benefícios qualitativos mais importantes são apresentados a seguir [GHR97,CEM96]: Melhor compreensão dos produtos e processos, p.ex. o esforço para corrigir falhas e defeitos foi visualizado, características dos módulos com alto risco foram identificadas. Linhas-base para os assuntos de interesse foram derivadas. A consciência dos pontos fortes e fracos dos produtos e processos de software (com respeito ao enfoque de qualidade) aumentou. Por exemplo, algumas técnicas de teste foram significantemente mais ou menos efetivas do que esperado. Hipóteses, refletindo a compreensão implícita do produto/processo puderam ser confirmadas ou rejeitadas com base nos dados quantitativos. Razões puderam ser identificadas e explicações foram provadas. Oportunidades de melhoramento com médio/alto impacto na qualidade de produto de software foram identificadas e sugestões para melhoramento foram implantadas através das modificações do processo ou da introdução das novas tecnologias. Utilização do GQM no Desenvolvimento de Software - 33

O programa GQM provê também informação quantitativa e concreta para dar sustentação a requisições e propostas baseadas nos dados de mensuração. Melhor suporte (quantitativo) para planejamento, monitoria e controle dos projetos de software é disponível. Os resultados do programa podem ser usados para formular modelos e regras gerais. Eles constituíram um base bem-fundamentada para decisões. O aumento da motivação da equipe para entender o processo de software e um maior interesse na qualidade do produto e no melhoramento destes foram observados. A aprendizagem contínua nas empresas foi iniciada. Pessoas tentam evitar erros feitos em projetos passados através da reutilização do conhecimento ganho em programas de mensuração anteriores. Uma visão geral sobre benefícios de várias empresas resultando da aplicação de GQM é mostrada na seguinte tabela. Benefícios dos programas de mensuração baseados em GQM Robert Bosch GmbH [CEM96] Digital SPA [CEM96, FLM96] - Melhor compreensão dos processos e produtos de desenvolvimento do software. - Áreas criticas foram identificadas. - Linhas-base para o processo de desenvolvimento de software foram criadas. - Fatores de contextos no esforço do desenvolvimento foram identificados. - Ações de melhoramento foram iniciadas. - Maior facilidade de gerência de projetos de software - Disponibilidade de modelos, p.ex. distribuição de falhas por prioridade e nível, distribuição de esforço e produtividade de testes - Primeiras ações de melhoramento implantadas com respeito à reorganização de testes - que resultou uma redução dos custos de testes de 30%. - Melhoramento de mensuração, incluindo melhor praticas de coleta de dados, facilidades de gerência dos dados e interpretação dos dados. - Motivação e consciência crescida para mensuração e coleta dos dados. - Possibilidade de analisar e interpretar dados históricos. Motorola [Das92] - Pessoas começaram de pensar em processos de software e qualidade. - Identificação de problemas existentes. - Motivação para melhoramento. - Estabelecimento de linhas-base locais. - Enfoque em ações com resultados quantitativos. - Melhoramento significante de produtividade e qualidade (50x redução de densidade de defeitos de software lançado em 3.5 anos), critério de aceitação para entrega e exatidão das estimativas do cronograma. - Redução significante de custos através do melhor qualidade (rework reduzido). NASA [BCM92] - Melhoramento de confiabilidade de software de 35%. - Melhoramento significante de capacidade de gerência de projetos de software através da construção de modelos de excelência de processo para predizer, controlar e gerenciar custos e qualidade de software. - Redução de esforço de rework, de custos de desenvolvimento de código novo de 10% e crescimento de reutilização de software. - Melhor compreensão de software na organização de desenvolvimento inteira. Schlumberger RPS - Melhor compreensão dos produtos e processos na organização. Utilização do GQM no Desenvolvimento de Software - 34

[CEM96, HOR96] - Maior visibilidade de grau de defeitos e estimação de riscos de módulos. - Estabelecimento de linhas-base para resultados de mensuração, p.ex. com respeito a detecção de erros, reutilização de software. - Suporte para gerência de projetos e garantia de qualidade. - Consciência crescente de pontos fortes e fracos dos processos. - Melhor compreensão de produtos e processos no projeto piloto através de uma cooperação intensa dentro da equipe. - Enfoque em qualidade crescente na equipe. 5.2 CUSTO DO ESTABELECIMENTO DOS PROGRAMAS GQM O estabelecimento de programas de mensuração baseado em GQM nas três empresas durante o projeto CEMP foi acompanhada com a mensuração dos custos relacionados à introdução na prática. Os resultados das três empresas foram capturados, comparados e cuidadosamente generalizados [GHR97,CEM96]. Os resultados mais importantes são apresentados a seguir. Todos os valores fornecidos são médias dos resultados das empresas individuais e de projetos, incluindo só atividades relacionadas diretamente ao método GQM: O esforço total requerido para introduzir mensuração baseada em GQM é aproximadamente 1 homem-ano. O esforço total requerido para introduzir GQM (de aprox. 1 homem-ano) advém 1/3 da equipe participando no programa ativamente e 2/3 dos da equipe de GQM que são responsáveis por planejamento e execução do programa. A relação do esforço entre o planejamento e a execução do programa GQM é aproximadamente 2/3 (planejamento) para 1/3 (execução). O esforço total diminui em programas GQM posteriores. No projeto CEMP as empresas gastaram aproximadamente 6 homens-mês nos programas posteriores em comparação com um homem-ano nos primeiros. As razões principais para a diminuição são a disponibilidade de ferramentas para a tecnologia GQM, experiência crescente com a abordagem e a reutilização (em partes) dos artefatos relacionados do programa GQM. As despesas gerais do projeto relacionadas com a participação da equipe no programa GQM são aproximadamente 2% do esforço total do projeto de software. Figura 13, mostra a distribuição de esforço por fase de processo GQM. Os dados foram coletados em 6 projetos-piloto em três empresas diferentes [GHR97, CEM96]. As fases representadas na figura 13 incluem as seguintes atividades: Treinamento: Execução e participação no treinamento com respeito ao GQM Utilização do GQM no Desenvolvimento de Software - 35

Estudo prévio: Caracterização da organização e do projeto piloto, identificação de metas de melhoramento Identificação metas GQM: Discussão de metas de melhoramento e derivação das metas de mensuração Planejamento GQM: Execução de entrevistas, desenvolvimento de planos GQM Planejamento do plano de mensuração: Desenvolvimento dos procedimentos e instrumentos da coleta de dados Análise e interpretação dos dados coletados no contexto de plano GQM. 100% 90% 80% 70% 60% 50% Análise e interpretação Definição plano de mensuração Planejamento GQM Identificação metas GQM Estudo prévio 40% Treinamento 30% 20% 10% 0% Projetos Figura 13. Distribuição de esforço por fase [GHR97] Os fatores abaixo foram identificados como, em geral, fatores de influência no custo relacionado ao estabelecimento de um programa de mensuração na indústria [NAS94,CEM96]: Escopo do programa de melhoramento: Tamanho da organização Número dos projetos incluídos no programa de mensuração Utilização do GQM no Desenvolvimento de Software - 36

Escopo do programa de mensuração (p.ex. partes do ciclo da vida de processo de software enfocadas, número das metas consideradas, número de medidas) Duração do programa de mensuração (p.ex., duração da fase de coleta dos dados, freqüência dos feedback sessions) Características da organização/projeto de software: Disponibilidade de uma infra-estrutura específica para mensuração (p.ex., grupo de garantia de qualidade enfocando assuntos de melhoramento de processo ao nível de toda a organização) Disponibilidade de pré-requisitos para um programa de mensuração (p.ex. modelo explícito do processo de software) Experiência com mensuração e com a abordagem GQM Disponibilidade de suporte de ferramentas para o programa de mensuração (p.ex. ferramentas para coleta de dados) Reutilização de artefatos de programas de mensuração anteriores Quantidade de atividades adicionais para suportar o programa GQM (p.ex. implementação de ferramentas para coleta de dados) Tamanho da equipe e localização da equipe Estabilidade do processo e dos projetos de software Existência de uma cultura orientada em melhoramento na organização Uma visão geral com respeito aos custos relacionados ao programas de mensuração baseados em GQM é mostrada na seguinte tabela, resumindo experiências de várias empresas. Custos relacionados aos programas de mensuração baseados em GQM Robert Bosch GmbH [CEM96] Desenvolvimento de software para controle de motor em carros. Uso de GQM desde 1994. Dados de um projeto piloto (com 6 desenvolvedores). - Esforço para coleta, análise e interpretação dos dados da equipe de projeto é ~3% do esforço total do projeto. - Distribuição do esforço entre a equipe de projeto e a equipe GQM é 25% vs. 75% do esforço total dedicado ao programa de mensuração. - Uma grande parte dos esforços relacionados ao programa de mensuração (39%) foi usado para atividades de suporte, como modelagem do processo de software e desenvolvimento de ferramentas para mensuração. Utilização do GQM no Desenvolvimento de Software - 37

Digital SPA [CEM96] Desenvolvimento de ferramentas de ambientes CASE e bancos de dados. Uso de GQM desde 1994. Dados de dois projetos (com 32 desenvolvedores em dois locais/ 4 desenvolvedores em um local). Motorola [Das92] Iniciativa de métricas de software na empresa inteira começando em 1989. NASA [NAS94] Dados baseados em 17 anos de experiência em organizações de 100 até 5000 pessoas. O tamanho dos projetos varia de 5KSLOC até um milhão de SLOC. Schlumberger RPS [SLO95, CEM96] Desenvolvimento de sistemas para postos de gasolina self service Uso de GQM desde 1994. Dados derivados de dois projetos. - Esforço total de estabelecimento e execução de programa GQM foi uma parte razoavelmente pequena dos custos totais do projeto. - Reutilizando experiências, produtos GQM e ferramentas em projetos seguidos reduziu os custos totais de programa de mensuração em 40%. - Esforço relacionado às reuniões de grupos de trabalho e envolvimento em tempo parcial na implantação do programa de mensuração (Metrics Working Group ~8 pessoas/8 reuniões por ano e Metrics Users Group ~15 pessoas/4 reuniões por ano) - Esforço total ~1% de recursos total da organização. - Dados em % total do tamanho da organização: - Empresas médias (100-500 pessoas): - Overhead de projeto (coleta de dados) < 2% - Processamento dos dados ~3-7% - Estudo prévio, planejamento de programa, análise de resultados ~6-15% - Empresas grandes (500-5000 pessoas): - Overhead de projeto (coleta de dados) < 1% - Processamento dos dados <2% - Estudo prévio, planejamento de programa, análise de resultados <3% - Custos iniciais no total: 850 horas no primeiro projeto piloto e 370 horas no seguinte projeto. - Custos da equipe permanente do projeto (incluindo coleta e interpretação dos dados): 2% de tempo total do projeto - Custos da equipe de garantia de qualidade: 5-7% do tempo total - A curva de aprendizagem do planejamento e execução de mensuração baseado em GQM reduzia o esforço entre o primeiro e o segundo projeto piloto de 35%. Utilização do GQM no Desenvolvimento de Software - 38

6 RESUMO E CONCLUSÃO A aplicação de mensuração baseada em GQM provou ter muito sucesso em várias empresas. A abordagem de GQM mostrou ser satisfatória para estabelecer um programa de mensuração efetivo que enfoca a atenção nas reais causas de problemas do processo e produto de software. Como resultado dos programas de mensuração a compreensão da qualidade do produto e do processo de software aumentou significativamente. Os resultados da mensuração baseada em GQM permitiram identificar forças e fraquezas do produto e processo e, assim, oportunidades para melhoramento baseadas na análise qualitativa e quantitativa. Como está mostrado no capítulo 5.2 benefícios consideráveis de aplicar esta tecnologia foram identificados. O esforço adicional exigido é considerado aceitável pelas empresas, comparando com os benefícios alcançados. Para aplicar mensuração e a abordagem GQM na prática com sucesso, algumas linhas-base devem ser consideradas [CEM96, Das92, NAS94]: Infra-estrutura para mensuração é necessária, isso inclui o estabelecimento de um grupo de trabalho enfocando a garantia de qualidade do processo de software. A gerência tem que se comprometer com o programa de mensuração e apoiar modificações motivadas através da mensuração. Todas as pessoas envolvidas no programa de mensuração deveriam participar ativamente no programa de mensuração. Envolvimento de gerentes de projeto na administração do programa de GQM. Todas as pessoas envolvidas precisam ser informadas e treinadas apropriadamente. Alocação de recursos suficientes para o programa de mensuração. Um pré-requisito para o estabelecimento de um programa de mensuração com sucesso é a disponibilidade de um modelo de processo de software. O processo de software e os produtos relacionados precisam ser modelados e os papeis envolvidos definidos. Começa com um conjunto de medidas enfocando áreas de melhoramento importantes e evolui esse conjunto com tempo, ao invés de debater interminavelmente tentando de achar as medidas perfeitas. As pessoas da equipe do projeto são os melhores para interpretar os dados coletados, porque elas têm o expertise no domínio do projeto e podem derivar interpretações válidas. Um consultor externo com expertise na analise de dados na área de engenharia de software pode ajudar a iniciar e guiar essas atividades. Utilização do GQM no Desenvolvimento de Software - 39

Ferramentas para suportar o programa de mensuração não são necessárias, mas podem ajudar a implantação e reduzir o esforço necessário facilitando a coleta dos dados. Essas incluem p.ex. sistemas para cálculo de custos, sistemas de gerência de configuração, e sistemas de detecção de problemas. Mas automatização tem limites e não todos os dados podem ser coletados automaticamente. Não enfoque na coleta de dados mas na análise e interpretação dos dados. Não avalie ou controle pessoas pela mensuração. Mensuração não deveria ser usada para qualificar ou caracterizar diferenças entre indivíduos. Isto garante a confiabilidade de dados individuais. Mensuração tem que ser integrada completamente nas atividades de projeto regulares para ganhar aceitação e reduzir esforço relacionado. Feedback sessions são o mecanismo chave para a interpretação dos dados. Refinamento/adaptação contínuo do programa de mensuração no contexto e nas metas. Mensuração não é a meta. A meta é melhoramento de processo de software através de mensuração e os dados coletados, analisados e interpretados. Através da mensuração só podem ser mostrados os problemas existentes e mudanças para melhoramento podem ser apontadas. Mas só a implantação/realização dessas mudanças pode trazer resultados e assim benefícios. Agradecimentos Os autores gostariam de agradecer ao H. Dieter Rombach e Guenther Ruhe pela participação em uma versão anterior do artigo e Aldo von Wangenheim pelas críticas, feedback e discussões proveitosas que ajudaram no amadurecimento deste artigo. Utilização do GQM no Desenvolvimento de Software - 40

REFERÊNCIA BIBLIOGRÁFICA [Bas92] V. R. Basili. Software Modelling and Measurement: The Goal/Question/Metric Paradigm. Technical Report CS-TR-2956, Department of Computer Science, University of Maryland, MD 20742, September 1992. [BCM92] V. R. Basili, G. Caldiera, F. McGarry, R. Pajerski, G. Page, S. Waligora. The Software Engineering Laboratory-An Operational Software Experience Factory. ACM,1992. [BCR94a] V. R. Basili, G. Caldiera and H. D. Rombach. Experience Factory. In John C. Marciniak, editor, Encyclopedia of Software Engineering, volume 1. John Wiley & Sons, 1994. [BCR94b] V.R. Basili, G. Caldiera and H. D. Rombach. Goal Question Metric Paradigm. In John C. Marciniak, editor, Encyclopedia of Software Engineering, volume 1. John Wiley & Sons, 1994. [BDR97] L. C. Briand, C. M. Differding and H. D. Rombach. Practical Guidelines for Measurement-Based Process Improvement. Software Process Improvement and Practice, vol. 2, 1997. [BDT96] A. Bröckers, C. Differding and G. Threin. The Role of Software Process Modeling in Planning Industrial Measurement Programs. In Proceedings of the METRICS 96. ICSE, 1996. [BR88] V. R. Basili, H. D. Rombach. The TAME Project: Towards Improvement-Oriented Software Environments. IEEE Transactions on Software Engineering, SE-14(6), 1988. [BW84] V. R. Basili and D. M. Weiss. A Methodology for Collecting Valid Ssoftware Engineering Data. IEEE Transactions on Software Engineering, SE-10(6):728-738, November 1984. [CEM96] The CEMP Consortium. Customized Establishment of Measurement Programs. Final Report, ESSI Nr. 10358, 1996. [CGF97] G. Cugola, C. Gresse, P. Fusaro, A. Fuggetta, L. Lavazza, S. Manca, M. R. Pagone, G. Ruhe, R. Soro. A Case Study of Evaluating Configuration Management Practices with Goal-Oriented Measurement. In Proceedings of the 4th International IEEE Symposium on Software Metrics, 1997. Utilização do GQM no Desenvolvimento de Software - 41

[Das92] M.K. Daskalantonakis. A Practical View of Software Measurement and Implementation Experiences within Motorola. IEEE Transactions on Software Engineering, Vol. 18, No. 11, 1992. [DHL95] C. Differding, B. Hoisl, C. Lott. Technology Package for the Goal/Question Metric Paradigm. Technical Report 281-96, University of Kaiserslautern, Department of Computer Science, D-67653 Kaiserslautern, Germany, 1995. [GB97] C. Gresse, L. Briand. Requirements for the Know-ledge-Based Support of Software Engineering Measurement Plans. In Proceedings of the 9th Int. Conference on Software Engineering and Knowledge Engineering, Spain, 1997. [GHR97] C. Gresse, B. Hoisl, H. D. Rombach, G. Ruhe. Kosten-Nutzen-Analyse von GQMbasiertem Messen und Bewerten: Eine replizierte Fallstudie. In O. Grün and L. J. Heinrich, ed., Wirtschaftinformatik - Ergebnisse empirischer Forschung, Springer Verlag, 1997. [GHW95] C. Gresse, B. Hoisl, J. Wüst. A Process Model for GQM- Based Measurement. Technical Report STTI-95-04-E, Software Technology Transfer Initiative, University of Kaiserslautern, Department of Computer Science, Kaiserslautern, Germany, 1995. [GRR94] H. Günther, H. D. Rombach, and G. Ruhe. Kontinuierliche Qualitätsverbesserung in der Software Entwicklung - Erfahrungen bei der Allianz Lebensversicherungs-AG (in German). Wirtschaftsinformatik 38, 1994. [FLM96] A. Fuggetta, L. Lavazza, S. Morasca, S. Cinti, G. Oldano and E. Orazi. Applying GQM in an Industrial Software Factory. To appear in ACM Transactions on Software Engineering and Methodology. [HOR96] B. Hoisl, M. Oivo, G. Ruhe, and F. van Latum. No Improvement without Feedback: Experiences from goal-oriented measurement at Schlumberger. Fifth European Workshop on Software Process Technology, Nancy, France, October 1996. [NAS94] National Aeronautics and Space Administration. Software Measurement Guidebook. Technical Report SEL-84-101, NASA Goddard Space Flight Center, Greenbelt MD 20771, 1994. [Paw91] Z. Pawlak: Rough Sets: Theoretical Aspects of Reasoning about Data. Kluwer, 1991 [Rom91] H. D. Rombach. Practical Benefits of Goal-Oriented Measurement. Software Reliability and Metrics, Elsevier Applied Science, 1991. [Ruh96] G. Ruhe: Rough Set based Data Analysis in Goal Oriented Software Measurement. Third Symposium on Software Metrics, Berlin, March 1996, IEEE Computer Society Press, p.10-19 Utilização do GQM no Desenvolvimento de Software - 42

[SLO95] R. van Solingen, F. van Latum, M. Oivo, and E. Berghout. Application of Software Measurement at Schlumberger RPS: Towards Enhancing GQM. Proceedings of the Sixth European Software Cost Modelling Conference (ESCOM), May 1995. [Sol95] R. van Solingen. Goal-Oriented Software Measurement in Practice: Introducing Software Measurement in Schlumberger Retail Petroleum Systems. Master Thesis Report, Schlumberger RPS, Netherlands, 1995. Utilização do GQM no Desenvolvimento de Software - 43

APÊNDICE Utilização do GQM no Desenvolvimento de Software - 44