Processo de Implantação de Gestão de Qualidade de Software em Empresas Nacionais: O Estudo de Caso do Tribunal de Contas da

Transcrição

1 Universidade Católica de Brasília UCB Mestrado em Informática Qualidade de Software Processo de Implantação de Gestão de Qualidade de Software em Empresas Nacionais: O Estudo de Caso do Tribunal de Contas da União Tomás Roberto Cotta Orlandi Processo de Implantação de Gestão de Qualidade de Software em Empresas Nacionais: O Estudo de Caso do Tribunal de Contas da União Tomás Roberto Cotta Orlandi Resumo A proposta deste trabalho é demonstrar a viabilidade da implantação de um processo contínuo de avaliação de qualidade de software em empresas brasileiras, apresentando a abordagem GQM Goal, Question, Metric, situando-a no contexto de outras abordagens de avaliação e qualidade de software, que atende não só as expectativas em relação à uma melhora de qualidade dos produtos, mas também a um incremento na produtividade das equipes de trabalho. Palavras-chave abordagem GQM, CMM, Fábrica de Experiência, ISO, QIP, Qualidade de software, SPICE. Orientador Prof. Dr. Walcélio L. Melo Abstract The objective of this article is to show the viability of introducing a continuos evaluation process of software quality in Brazilian s companies, presenting the GQM Goal, Question, Metric approach, comparing it with others software s quality approaches, attending the wishes of a better software product s quality and best productivity of the team working. Keywords CMM, Experience Factory, GQM Approach, ISO, QIP, Software Quality, SPICE Brasília (DF), dezembro de

2 I. Introdução Objetivos Gerais : O presente trabalho tem por objetivo apresentar um exemplo da abordagem GQM Goal, Question, Metric, situando-a no contexto de outras abordagens de avaliação e qualidade de software como ISO,CMM, SPICE e QIP. A implantação da abordagem GQM em empresa nacional, será mostrada através da utilização de um processo padronizado de desenvolvimento, conversão e manutenção de software. A proposta é demonstrar a viabilidade da implantação de um processo contínuo de avaliação de software nas empresas nacionais, que atenda não só as expectativas em relação à uma melhora de qualidade dos produtos, mas também a um incremento na produtividade das equipes de trabalho, incorporando naturalmente a cultura de produzir software com testes, inspeções e medições de resultados. Será também demonstrada a viabilidade da manutenção de um programa permanente de qualidade de software, através do treinamento, implantação e aplicação da abordagem GQM, visando uma melhora contínua na qualidade e na produtividade de sistemas. Como produto final são gerados modelos quantitativos, baseados em dados captados, que viabilizam uma análise da qualidade dos software produzidos, possibilitando uma comparação qualitativa do processo de desenvolvimento de sistemas com organizações externas. Em decorrência da implantação dessa abordagem, demonstra-se a implementação e a manutenção de uma estrutura, separada logicamente do desenvolvimento de software, a Fábrica de Experiências. A Fábrica de Experiências (Experience Factory)[1] tem por objetivo armazenar as experiências dos projetos desenvolvidos, em termos de soluções e implementações adotadas, para que as equipes possam fazer reuso posterior das soluções e dos códigos já desenvolvidos. As soluções empacotadas na Fábrica de Experiências poderão ser utilizadas também por organizações semelhantes à estudada, ou seja, empresa nacional pública ou privada. Objetivos Específicos: Apresentar claramente a abordagem GQM e sua forma de aplicação; Situar a abordagem GQM no contexto geral da qualidade de software; Mostrar a viabilidade da implantação da abordagem GQM em empresas nacionais (utilizando o estudo de caso do Tribunal de Contas do Distrito Federal TCDF); Apresentar uma forma das equipes de trabalho incorporarem naturalmente, no desenvolvimento e manutenção de software, as atividades de testes, inspeções e medições de resultados; Mostrar o conceito e a forma de implementação da Fábrica de Experiências. II. Caracterização dos Produtos e dos Processos Este capítulo visa apresentar os modelos de qualidade de software mais aplicados em empresas ou setores, produtores de software, que de algum modo se preocupam em implementar e manter procedimentos de avaliação e medição, visando uma melhora na qualidade e produtividade dos projetos e sistemas desenvolvidos pela empresa. O Modelo ISO de Qualidade A norma ISO/IEC objetiva auxiliar organizações na definição de seus processos de software oferecendo uma guia para definição das atividades e tarefas a serem desempenhadas durante as principais etapas que envolvem a construção de um produto de software. A norma agrupa processos de software em três grandes classes processos fundamentais, processos de apoio e processos organizacionais. A categoria de processos fundamentais compreende os processos que executam as principais funções relacionadas ao ciclo de vida de software. Processos de apoio servem como auxiliares ao processo fundamental de construção, contribuindo para o sucesso e a qualidade do produto gerado. Processos organizacionais são responsáveis pelo acompanhamento do desenvolvimento, compreendendo processos para gerência, melhoria da qualidade, infra-estrutura e treinamento. Cada processo inserido nestas classes está dividido em um conjunto de atividades que, por sua vez, se dividem em um conjunto de tarefas para sua realização. Contudo, a norma não especifica detalhes de como implementar ou executar estas tarefas e atividades. Este é um dos motivos pelo qual o presente trabalho não abordará o modelo ISO de qualidade pois, no contexto de empresas nacionais em questão, necessitamos especificar os detalhes de como implementar processos de qualidade de software nas organizações. O Modelo SPICE (ISO/IEC 15504) de Qualidade A iniciativa de se estabelecer um padrão internacional para melhoria de processos de software levou a ISO/IEC a aprovar em 1993 um novo grupo de trabalho, denominado WG10, a partir do qual se organizou o projeto SPICE (Software Process Improvement and Capability determination) (ISO/IEC , 1996) [5]. Analogamente ao CMM, o objetivo principal do SPICE é a elaboração de um padrão ou infra-estrutura (framework) para avaliação de processos de software e para a determinação de sua capacitação - ISO/IEC

3 A futura norma ISO/IEC define processos e práticas que podem ser implementados para estabelecer e aprimorar a capacidade de aquisição, desenvolvimento, manutenção, operação e suporte de software em organizações. Estas práticas são organizadas utilizando-se uma arquitetura que combina duas perspectivas: uma perspectiva funcional (análoga à perspectiva da norma ISO/IEC 12207), compreendendo quais os processos que devem existir numa organização e uma outra perspectiva que avalia o nível de capacitação de cada um destes processos (análoga ao CMM). O uso da norma permite que as organizações possam perceber a existência ou não de processos específicos, bem como a capacitação dos que existem, traçando caminhos para a melhoria. O Modelo CMM O Capability Maturity Model (CMM) para Software, compilado pelo Software Engineering Institute SEI da Carnegie Mellon University (EUA), pode ser entendido como um modelo para avaliação do grau de maturidade das organizações quanto à capacidade produtiva de software. [13] O CMM representa uma proposição de recomendações para empresas, cujo negócio seja a produção de software, que pretendam incrementar a capacidade (ou qualidade) do processo de desenvolvimento de sistemas. O modelo apresentado pelo CMM não se preocupa em como a organização implementa, mas, antes, busca descrever o quê se espera do processo produtivo de software. O modelo CMM foi utilizado neste trabalho como caminho a ser seguido para nortear as ações de implementação de um modelo de qualidade de software em organizações brasileiras, pois, trata-se de um modelo consagrado e utilizado mundialmente por organizações produtoras de software. O CMM classifica as organizações produtoras de software em cinco grupos (ou níveis) de maturidade, identificando, para cada grupo, as áreas chave do processo de desenvolvimento de sistemas que devem ser observadas na busca da melhoria da capacidade produtiva. Cada área chave possui objetivos que precisam ser alcançados para que a organização seja considerada como tendo atingido determinado nível. Os cinco níveis de maturidade propostos pelo CMM, em grau crescente, são: inicial; repetitivo; definido; gerenciado; e otimizado.[13] Nível 1 - Inicial Nesse nível, o processo de produção de software é efetuado de maneira empírica e ocasionalmente, até mesmo, de forma caótica. Poucos processos são definidos e o sucesso dos projetos depende de esforços individuais e atitudes heróicas dos desenvolvedores. Uma característica das organizações classificadas nesse nível é o comprometimento além da capacidade. A dificuldade da organização em cumprir os compromissos estabelecidos é acompanhada pela sobrecarga do corpo técnico, que fica impossibilitado de seguir as práticas recomendadas para a engenharia de software, gerando, então, sucessivas crises. Durante as crises, normalmente, são abandonadas as fases de planejamento, havendo um incremento exagerado e desordenado das etapas de codificação e teste. Para esse nível, o CMM não apresenta áreas chave. A caracterização do comportamento no nível 1 é colocado apenas como base de comparação para os demais níveis. Nível 2 - Repetitivo Nesse nível de maturidade, existe um gerenciamento básico de projetos com a finalidade maior de acompanhar custos e cronogramas. Porém, o processo aplicado ao desenvolvimento de novos projetos constitui-se basicamente na repetição de práticas já experimentadas com sucesso em projetos similares anteriormente desenvolvidos. Os processos de desenvolvimento podem, assim, ser diferentes de projeto para projeto em organizações considerados no nível 2. O que deve existir, porém, é uma política que sirva como guia no estabelecimento de uma gerência apropriada de processos. Os compromissos assumidos, então, passam a ser mais realistas, pois baseiam-se, agora, em resultados observados em projetos anteriores. A gerência de projetos pode acompanhar melhor os custos, o cronograma e o atendimento aos requerimentos. As áreas chave para o nível 2 estão focadas nas práticas que concernem ao gerenciamento de projetos: gerência de requisitos; planejamento do projeto; acompanhamento do projeto e de desvios; gerenciamento de subcontratados; controle de qualidade; e gerência de configurações. Nível 3 - Definido No nível definido, um processo padrão (ou vários) para desenvolvimento e manutenção de software é documentado e usado por toda a organização. Esse padrão inclui as atividades de engenharia e gerenciamento de software integrados em um todo coerente. O processo padrão é utilizado (e modificado, se necessário) para auxiliar os gerentes e desenvolvedores em uma produção mais eficiente. Um programa de treinamento é implementado em toda a organização para assegurar que o corpo técnico e os gerentes adquiram o conhecimento e habilidade necessários à execução de suas tarefas. A medida que acontecem, os projetos utilizam-se do processo padrão e fazem adaptação desse modelo para ajustá-lo às suas peculiaridades. Sendo, então, esse processo ajustado o que realmente é usado nas atividades do projeto. 5 6

4 O que difere o nível 3 do nível anterior, além das áreas chave relacionadas a seguir, basicamente, é o fato de existir neste nível o processo padrão definido, documentado, integrado, ajustado e, principalmente, seguido por toda a organização. O nível 3 do CMM pode ser resumido pelas palavras padrão e consistência, uma vez que, nesse nível, as atividades de engenharia e gerenciamento no processo produtivo de software são estáveis e repetitivas. Com uma linha de produção estabelecida, os custos, o cronograma e as funcionalidades estão sob controle e qualidade do software é melhor acompanhada. As áreas chave definidas para o nível 3 estão voltadas aos aspectos da organização e do projeto, no sentido de prover uma infra-estrutura que possibilite a institucionalização de um efetivo processo de engenharia e gerência de software para todos os projetos. São áreas chave para o nível 3: foco no processo da organização (ou estabelecimento de responsabilidades na organização para atividades relativas à produção de software); definição do processo para a organização; programa de treinamento; gerenciamento integrado; engenharia de produtos; coordenação intergrupos (ou interação entre grupos de engenharia de software); revisão de pares. Nível 4 - Gerenciado Nesse nível, passam a ser coletadas e analisadas métricas detalhadas relativas ao processo e à qualidade do produto para acompanhamento e controle do processo. Nesse nível, processo e produto são quantitativamente entendidos e controlados. No nível gerenciado, a organização define objetivos de qualidade que devem ser alcançados para produtos e processos. As atividades de produção de software mais importantes são acompanhadas por meio de um programa de medidas da organização afim de que possam ser observadas a produtividade, a qualidade, etc. Um banco de dados para a organização como um todo é usado para coletar e analisar os dados disponíveis extraídos dos projetos. O processo de software é equipado com um processo de coleta de medidas consistente e bem definido. O nível 4 do CMM pode ser resumido como sendo quantificado e previsível porque os processos são medidos e as operações são realizadas dentro de limites quantitativos. Esse nível permite que a organização trabalhe com segurança na previsão do desempenho dos processos e da qualidade dos produtos. As áreas chave para o nível 4 estão direcionadas ao entendimento quantitativo do processo e do produto: gerenciamento quantitativo do processo; e gerenciamento da qualidade do produto. Nível 5 - Otimizado No nível otimizado, toda a organização está voltada para um contínuo processo de melhoria. A organização busca identificar, de forma pró-ativa, os pontos fortes e fracos do processo, com o objetivo de evitar erros e melhorar a eficiência. Dados reais de processos são usados para análise da relação custo/benefício, para implementação de novas tecnologias ou para propor mudanças ao processo produtivo. As equipes de software em organizações no nível 5 trabalham na análise de defeitos do processo afim de determinar suas causas, avaliar o processo e prevenir manifestações de erros conhecidos e recorrentes, e, ainda, disseminar os conhecimentos adquiridos pela organização. Em qualquer sistema, existe um desperdício contínuo, em forma de retrabalho, simplesmente por causa de imprevistos. Esforços no sentido de eliminar esses desperdícios resultam em mudanças no sistema pela recondução dessas causas comuns de ineficiência. Embora esses esforços para reduzir desperdícios ocorram em todos os níveis de maturidade, essa preocupação constitui o foco do nível 5. O nível 5 do CMM pode ser caracterizado como de melhoria contínua porque as organizações identificadas no nível 5 estão continuamente empenhadas em melhorar a capacidade de seus processos. A melhoria pode surgir tanto em função do progresso do próprio processo quanto da aplicação de novas tecnologias e métodos. A aplicação de novas tecnologias ou mudanças no processo são planejadas e gerenciadas como tarefas rotineiras. As áreas chave que constituem o nível 5 buscam enfocar os assuntos que os projetos precisam observar para promover um incremento contínuo e mensurável da qualidade do processo de software. São as seguintes as áreas chave para o nível otimizado: prevenção de erros; gerenciamento de mudança tecnológica; e gerenciamento de mudanças no processo. 7 8

5 Como mostra a figura 1, o CMM, pode ser representado como uma estrutura de cinco níveis de maturidade: Inicial 1 Repetitível 2 Definido 3 Gerenciado 4 foco no processo da organização; definição do processo para a organização; programa de treinamento; gerenciamento integrado; engenharia de produtos; coordenação intergrupos; revisão de pares. Figura 1 Otimizado 5 gerência de requisitos; planejamento do projeto; acompanhamento do projeto e de desvios; gerenciamento de subcontratados; controle de qualidade; e gerência de configurações. O Paradigma de Aperfeiçoamento da Qualidade - QIP prevenção de erros; gerenciamento de mudança tecnológica; e gerenciamento de mudanças no processo gerenciamento quantitativo do processo; e gerenciamento da qualidade do produto. O Quality Improvement Paradigm QIP (ou Paradigma do Aperfeiçoamento da Qualidade), desenvolvido por Victor Basili e outros [1], é o resultado da aplicação do método científico para resolução do problema de melhoria da qualidade de software. O QIP está diretamente relacionado ao Ciclo Plan/Do/Check/Act (PDCA) de Shewart-Deming[15] largamente utilizado na indústria para implementação de planos de gerenciamento da qualidade. A abordagem PDCA é articulada em quatro fases: [15] Planejar (Plan): Definir os objetivos e metas do aperfeiçoamento da qualidade, determinar métodos para alcançar esses objetivos e preparar um plano de implementação. 9 Executar (Do): executar a implementação do plano e a coleta de dados. Verificar (Check): verificar a melhoria do desempenho usando os dados coletados dos processos e tomando ações corretivas necessárias. Agir (Act): atuar no sentido de padronizar as melhorias e incorporá-las ao processo. Por sua vez, o QIP desenvolve-se por meio dos seguintes passos:[1] Caracterizar: conhecer o ambiente com base nos dados e modelos disponíveis e na instituição. Estabelecer os fundamentos com os processos existentes na organização e caracterizá-los criticamente. Definir os objetivos: com base na caracterização inicial e nas capacidades estratégicas da organização, definir com objetivos quantificáveis o que seriam projetos bem sucedidos e avaliar o desempenho e melhoria da organização. As exceções aceitáveis são definidas com base nos fundamentos estabelecidos no passo de caracterização. Escolher os processos: com base na caracterização do ambiente e dos objetivos definidos, escolher os processos apropriados para melhoria bem como as ferramentas e métodos de apoio, certificando-se que esses sejam consistentes com os objetivos. Executar: executar os processos elaborando os produtos e provendo retorno, a partir do projeto, dos dados que estão sendo coletados para avaliação do alcance dos objetivos. Analisar: ao final de cada projeto específico, analisar os dados e informações acumuladas para avaliar as práticas correntes, identificar problemas, registrar achados, e fazer recomendações para melhoria de futuros projetos. Empacotar: Consolidar a experiência adquirida em forma de refinamento do modelo praticado ou mesmo pela adoção de novos modelos e, ainda, por meio de outras formas de estrutura de conhecimento alcançadas no último ou em processos anteriores e armazená-las em uma base de experiências, disponível para uso futuro. Uma caracterização apropriada e sem ambigüidades do ambiente é um pré-requisito para a aplicação correta do paradigma. Essa caracterização requer a classificação minuciosa do projeto, permitindo a identificação de classes de projetos com características e objetivos similares. Assim, pode-se estabelecer o ambiente adequado ao projeto corrente. Com a correta caracterização obtém-se um contexto para a definição de objetivos, para a reutilização de experiências e produtos, para a seleção de processos, para a avaliação e comparação de resultados, e para uma maior exatidão nas previsões. O Processo do Paradigma de Aperfeiçoamento da Qualidade Há um grande número de características de projetos e de ambiente que afetam o processo de desenvolvimento e o produto de software, tais como: fatores de pessoal - números de empregados, nível de especialização, organização de grupo, experiências; fatores relacionados ao problema - domínio da aplicação, suscetibilidade a mudança, limites do problema; fatores do processo - modelos de processo, métodos, técnicas, ferramentas, linguagem de programação, outros documentos; fatores do produto - implantação/entrega, tamanho do sistema, qualidades requeridas; 10

6 fatores dos recursos - máquinas de produção e desenvolvimento, tempo calendário, orçamento, software existente. A definição realista dos objetivos é importante para a caracterização do ambiente. É preciso estabelecer modelos e objetivos para os processos e para os produtos. Esses objetivos precisam ser mensuráveis, dirigidos pelos modelos, e definidos para uma variedade de perspectivas, tais como, a do usuário, do cliente, do projeto, da organização, etc. A abordagem GQM - Goal/Question/Metric (demonstrada adiante) [2] é o mecanismo usado pelo Quality Improvement Paradigm para definir e avaliar um conjunto de objetivos operacionais usando métricas. Essa abordagem representa uma sistemática para ajuste e integração de objetivos com modelos de processos, produtos e perspectivas de qualidade de software, baseadas em necessidades específicas do projeto e da organização. Existe uma variedade de dados que podem ser coletados: Dados sobre recursos - incluem esforço por atividade, fase, tipo ou pessoal, tempo de computador, tempo calendário, etc; Dados de mudanças e falhas dizem respeito a mudanças e falhas por vários esquemas de classificação; Métricas do processo relativas à definição e à conformidade dos processos, e aos dados concernentes ao entendimento do domínio da aplicação; Dados do produto quanto às características lógicas e físicas do produto e quanto à utilização e contexto da informação. Como mostra a figura 2, o ciclo QIP, pode ser representado da seguinte forma: Empacotar Analisar Executar Figura 2 Caracterizar Definir objetivos Escolher processo 11 A Fábrica de Experiência O QIP baseia-se na idéia de que o aperfeiçoamento do processo e do produto de software requer uma acumulação contínua de experiências (aprendizado) em formato que pode ser efetivamente entendido e modificado (modelos de experiências) em um repositório integrado (base de experiências) que pode ser acessado e modificado em conformidade com as necessidades do projeto corrente (reutilização). Para apoiar o paradigma de aperfeiçoamento foi desenvolvida um estrutura distinta do desenvolvimento de software denominada Fábrica de Experiências (Experience Factory EF).[1] A Fábrica de Experiências é uma estrutura física e/ou lógica que apoia o desenvolvimento de sistemas por meio da análise e sintetização de todos os tipos de experiências, agindo como um repositório para essas experiências e fornecendo-as a outros projetos na medida da demanda, representa um paradigma de mudança do pensamento corrente de desenvolvimento de software. Ela separa os tipos de atividades que precisam ser executadas em diferentes estruturas, reconhecendo que elas verdadeiramente representam processos e enfoques diferentes. Assim, identificam-se duas unidades organizacionais distintas: a Organização Projeto, para o desenvolvimento de sistemas; e a Fábrica de Experiências, para o empacotamento de conhecimentos adquiridos. Na Organização Projeto, são resolvidos os problemas, na Fábrica de Experiência, são entendidas as soluções e empacotadas as experiências para futura reutilização.[1] O Processo da Fábrica de Experiências A Fábrica de Experiências representa o grupo que trabalha na base do conhecimento da engenharia de desenvolvimento de software como um bem da corporação, enquanto a Organização Projeto representa o grupo cujo trabalho é usar aquele conhecimento para produzir os mais avançados produtos da corporação. A Organização Projeto caracteriza o projeto e seu ambiente, define os objetivos para o projeto e escolhe o processo apropriado dadas as características e objetivos. O suporte ao projeto é provido pela Fábrica de Experiências pela articulação das características, formulação de objetivos e seleção do conjunto apropriado de experiências passadas para uso no projeto. [1] Pela abordagem da Fábrica de Experiências, a reutilização não representa apenas o reaproveitamento de código mas de todos os tipos de experiências e do contexto que envolve essas experiências, reconhecendo que as experiências nem sempre são reutilizáveis como foram concebidas, antes elas precisam ser ajustadas e empacotadas para tornar mais fácil o seu acesso e reutilização. Na prática, a abordagem QIP/EF é implementada colocando-se primeiramente a organização em seu lugar, a partir de sua caracterização. Isso significa a coleta de dados para estabelecimento dos fundamentos (baselines) e avaliação dos pontos fortes e fracos da organização a fim de se obter o enfoque nos negócios e objetivos da empresa para o processo de melhoria. A coleta inicial de dados é crítica também para a definição da qualidade do produto que deveria ser aprimorada pelo programa. Dessa forma, a organização define em si mesma um contínuo aperfeiçoamento, mesmo se o nível de maturidade não for muito alto, porque ela aprende a partir do seu próprio negócio, não de um modelo de processo ideal, externamente 12

7 concebido. Melhorias no processo serão baseadas na compreensão do relacionamento entre processo e produto na própria organização. A introdução de novas tecnologias será motivada por problemas locais e o corpo técnico estará mais disposto a utilizá-las. O Modelo Goal Question Metric (GQM) Esta apresentação da abordagem Goal/Question/Metric (GQM), utilizada como abordagem na definição do processo de desenvolvimento de software, toma por base o texto de Victor R. Basili, Gianluigi Caldiera e H. Dieter Rombach [2]. Os dois primeiros do Institute for Advanced Computer Science, da University of Maryland (EUA), e o último da FB Informatik, da Universitat Kaiserslautern (Alemanha). Como em qualquer disciplina de engenharia, o desenvolvimento de software requer um mecanismo de mensuração para avaliação e retorno. O procedimento de medir é uma forma de criar uma memória corporativa e um auxílio na resposta de várias questões associadas ao estabelecimento de um processo de software. Um processo de medidas estabelecido auxilia no planejamento de novos projetos, na determinação de pontos fortes e fracos de produtos e processos, na racionalidade para adoção ou refinamento de técnicas em uso, e ainda, na avaliação da qualidade de processos ou produtos específicos. Medir também ajuda, durante o curso de um projeto, a avaliar o seu progresso, tomar as medidas corretivas baseadas nesse julgamento, e avaliar o impacto de tal ação. Algumas questões que poderiam, por exemplo, ser respondidas a partir de um sistema de medida, seriam : Qual o custo de um novo projeto? Qual a freqüência de certos tipos de erros? Qual o impacto da aplicação de determinada técnica na produtividade dos projetos? De acordo com vários estudos realizados sobre a aplicação de métricas e modelos em ambiente industrial, o processo de medida para trazer resultados precisa ser: voltado para objetivos específicos; aplicado a todo o ciclo de vida dos produtos, processos e recursos; adaptado às características e ao contexto da organização, do ambiente e dos objetivos. Como na figura 3, o modelo hierárquico GQM, pode ser representado da seguinte forma: OBJETIVO 1 OBJETIVO 2 QUESTÃO QUESTÃO QUESTÃO MÉTRICA MÉTRICA MÉTRICA MÉTRICA Figura 3 13 A abordagem GQM A abordagem GQM parte da premissa de que para uma organização adotar um processo de medida definitivo é necessário primeiramente estabelecer os objetivos da própria organização e de seus projetos, definir esses objetivos operacionalmente e, finalmente, criar um ambiente de apoio capaz de interpretar os dados comparando-os com os objetivos estabelecidos. Assim, é importante deixar claro, pelo menos em termos gerais, qual a necessidade de informações da organização, se essas informações podem ser quantificadas e em que momento podem ser colhidas, e se podem ser analisadas em função dos objetivos.[2] A abordagem foi definida originalmente para avaliação de defeitos em um conjunto de projetos no ambiente da NASA Goddard Space Flight Center. A aplicação envolveu um conjunto de estudos de casos e foi expandida para incluir várias abordagens experimentais. Embora a abordagem tenha sido usada originalmente para definir e avaliar os objetivos de um projeto específico, seu uso foi expandido para contextos maiores. A abordagem foi usada como um passo dentro de outra técnica, o Quality Improvement Paradigm (discutido anteriormente neste trabalho), processo de melhoria da qualidade que se utiliza de um ambiente operacional restrito, a Fábrica de Experiência (Experience Factory), que pode, por sua vez, ser entendida como um ambiente experimental com o objetivo de produção e/ou avaliação de software e processos para uso nos demais projetos. Neste trabalho, a utilização de todas estas técnicas, será norteada pelo modelo CMM de qualidade de software. A correta utilização destas técnicas permitirá à organização galgar os níveis de maturidade, através da realização das suas áreas chave para cada nível alcançado. O resultado da aplicação da abordagem GQM é a especificação de um sistema de medidas objetivando um conjunto particular de casos e de regras na interpretação dos dados medidos. O modelo de mensuração resultante possui três níveis:[2 - p 3] 1. Nível Conceitual: no qual é definido um objetivo (Goal) para o objeto a ser medido levando-se em conta o modelo de qualidade que se pretende atingir e o ponto de vista da observação. Podem ser objetos de medida: Produtos - quaisquer documentos e produtos que são gerados durante o ciclo de vida do sistema: especificações, projetos, programas, lotes de testes etc. Processos - atividades relacionadas ao desenvolvimento de software normalmente associadas ao dispêndio de tempo: fase de especificação, de projeto, de teste, de interação etc. Recursos - itens consumidos no processo para gerar os produtos: pessoal, equipamentos, software, espaço físico etc. 2. Nível Operacional: diz respeito a um conjunto de questões (Question) usado para caracterizar a forma de julgamento e garantir que o objetivo, definido no modelo, será atingido. As questões tentam caracterizar o objeto a ser medido (produto, processo ou recurso) com respeito a um padrão de qualidade e buscam identificar a qualidade desse objeto a partir de determinado ponto de vista. 14

8 3. Nível Quantitativo: representa os dados que serão apurados/medidos (Metric). Um conjunto de dados é associado às questões formuladas a fim de que sejam traduzidas quantitativamente. Esses dados podem ser objetivos ou subjetivos. - Objetivos - se dependem apenas do objeto que está sendo medido e não do ponto de vista em que são tomados. Por exemplo: número de versões de um documento, horas de pessoal gastas em determinada tarefa, tamanho de um programa etc. - Subjetivos - se dependem, além do próprio objeto que está sendo medido, do ponto de vista em que será analisada a medida. Exemplo: facilidade de leitura de um texto, nível de satisfação do usuário etc. Assim, um modelo GQM é uma estrutura hierárquica que inicia com a definição de um objetivo (goal), especificando o propósito da medição, os objetos e aspectos desses objetos que serão avaliados, e o ponto de vista em que as medidas serão analisadas. O objetivo é, então, refinado em diversas questões (question). Cada questão é, por sua vez, delineada nas métricas (metric). Há que se observar que uma mesma métrica pode ser usada para responder diferentes questões de um mesmo objetivo; diversos modelos GQM podem, também, ter questões e métricas em comum, desde que seja assegurado que quando da coleta das métricas sejam observados os diversos pontos de vista a que se destinam, pois a mesma medida pode assumir valores diversos dependendo do ponto de vista em que será analisada. O processo GQM Um modelo GQM é desenvolvido a partir de um conjunto de objetivos acerca de qualidade e/ou produtividade definidos para a organização, para a divisão ou para o projeto, tais como satisfação do usuário, entrega de serviço no prazo, melhoria de desempenho.[2 p 5] A partir da identificação dos objetivos e com base em modelos do objeto em avaliação, derivam-se questões que possam definir esses objetivos de forma mais completa. Por exemplo, se o objetivo é caracterizar um software quanto a determinadas qualidades (e.g., portabilidade), então faz-se necessária a escolha de um modelo para o produto que qualifique esses interesses (e.g., relação de características funcionais que precisam ser implementadas para diferentes arquiteturas). O próximo passo consiste em especificar as medidas que devem ser coletadas a fim de responder às questões e acompanhar a conformidade dos produtos e processos aos objetivos. Por fim, há que se desenvolver os meios de coleta dos dados, incluindo-se mecanismos de avaliação e análise. O processo de identificação de objetivos é crítico para o sucesso da aplicação da abordagem GQM, e será apoiado por passos metodológicos específicos. Para a consecução de um objetivo concorrerão três fontes básicas de informação[2 p 6]. A primeira fonte diz respeito à política e à estratégia da organização que aplica a abordagem GQM. A partir dessa fonte, com a análise da política da corporação, dos planos estratégicos e, ainda, levando-se em conta os interesses relevantes na organização, derivam-se o aspecto e o propósito para o objetivo a ser perseguido. A segunda fonte de informações é a descrição dos processos e produtos da organização, ou, pelo menos, daqueles que estão dentro do escopo do programa de medidas que se pretende efetuar. A partir desse fonte, com a especificação dos modelos de processos e produtos, dentro da maior formalidade possível, deriva-se a coordenada do objeto para o objetivo em questão. A terceira fonte de informações é o modelo do negócio da organização, que fornece a coordenada ponto de vista. É evidente que nem todos os assuntos e processos são relevantes para todos os pontos de vista na organização. Assim, há que se fazer uma análise da relevância dos objetivos para a organização, antes de se considerar concluída a lista de objetivos. Dessa forma, conclui-se a definição dos objetivos para o modelo GQM, tomando-se em conta a estrutura e os objetivos da organização. A partir da especificação de cada objetivo podem-se derivar questões significantes que quantificam o objetivo. Geralmente, são feitos pelo menos três grupos de questões: G 1. Como se pode caracterizar o objeto (produto, processo ou recurso) com o respeito ao objetivo global de determinado modelo GQM? Exemplo: Q 1: Qual o prazo corrente no atendimento às solicitações de mudanças num sistema em manutenção? Q 2: Existe um processo (documentado) no atendimento às solicitações de mudanças? G 2. Como se podem caracterizar os atributos relevantes do objeto em observação num modelo GQM específico? Exemplo: Q 1: Qual o desvio do prazo no atendimento de solicitações em função do estimado? Q 2: O desempenho da equipe no atendimento de solicitações vem melhorando? G 3. Como podem ser avaliadas as características do objeto que são relevantes com respeito ao aspecto tratado no modelo GQM? Exemplo: Q1: O desempenho tem sido satisfatório sob o ponto de vista do gerente de projeto? Q2: Há melhoria visível no desempenho? Uma vez que as questões tenham sido formuladas, deve-se proceder a associação destas com as métricas apropriadas. Diversos fatores devem ser considerados, dentre eles: Volume e quantidade dos dados existentes - deve-se buscar maximizar o uso das fontes de dados existentes, desde que estejam disponíveis e sejam confiáveis. Maturidade dos objetos em medição - devem-se aplicar medidas objetivas para objetos com maior nível de maturidade, e avaliações subjetivas quando se trabalha com objetos instáveis ou informais. Aprendizado do processo - o uso de modelos QGM requer sempre refinamento e adaptação. Assim, as medidas definidas devem auxiliar não somente na análise do objeto medido, mas também na avaliação do próprio modelo

9 Como exemplo de aplicação da abordagem Goal/Question/Metric, apresenta-se a suposição de modelo em que se pretenda melhorar o prazo no atendimento às solicitações de mudança para um determinado sistema em fase de manutenção. O objetivo definido deverá explicitar o propósito (melhorar), o processo (atendimento de solicitações de mudança), o ponto de vista (gerente de projeto), e o aspecto a ser observado (prazo de execução). Esse objetivo deve ser refinado em uma série de questões, que serão respondidas a partir da comparação do tempo coletado com média. O modelo GQM completo seria: [2 p 8] Objetivo Propósito Melhoria Aspecto Objeto (processo) Ponto de vista Prazo Atendimento das solicitações Gerente de projetos Questão Q1 Qual o tempo corrente no atendimento de solicitações de mudança? Métricas M1 Média de tempo de cada fase M2 M3 Desvio padrão % de casos acima do limite superior Questão Q2 O processo (documentado) no atendimento de solicitações é fielmente seguido? Métricas M4 Avaliação subjetiva do gerente de projetos M5 % de exceções identificado durante as revisões Questão Q3 Qual o desvio do prazo no atendimento de solicitações em função do estimado? Métricas M6 Média da execução média prevista * 100 Média da execução M7 Avaliação subjetiva do gerente de projeto Métricas M8 Média de tempo de execução * 100 Padrão de tempo para a fase Uma vez que o modelo GQM esteja definido, faz-se necessária a seleção das técnicas, ferramentas e procedimentos apropriados à coleta de dados. Os dados coletados devem ser mapeados para o modelo e interpretados de acordo com esquemas previamente definidos pela organização. Conclui-se, então, que a abordagem Goal/Question/Metric é uma abordagem para definição de um mecanismo de mensuração que possibilite o acompanhamento e avaliação do processo operacional de produção de software. Questão Q4 O desempenho está melhorando? Métricas M8 Média de tempo de execução * 100 Padrão de tempo para a fase Questão Q5 O desempenho tem sido satisfatório sob o ponto de vista do gerente de projeto? Métricas M7 Avaliação subjetiva do gerente de projeto Questão Q4 Há melhoria visível no desempenho? 17 18

10 III. O Ambiente em que foi Implementado o Modelo GQM Neste capítulo são apresentadas as principais características e a missão institucional da instituição aonde foi implantado o processo de melhoria contínua usando o QIP/GQM - o Tribunal de Contas do Distrito Federal e, inserida nessa missão, o papel desenvolvido pelo setor de informática. A missão do TCDF As competências constitucionais do Tribunal de Contas do Distrito Federal são:[3] apreciar, mediante emissão de parecer prévio, as contas anuais do Governador e julgar aquelas relativas aos administradores e demais responsáveis por dinheiro, bens e valores públicos; apreciar, para fins de registro, a legalidade dos atos de admissão de pessoal e de concessão de aposentadorias, reformas e pensões; avaliar a execução das metas estabelecidas no plano plurianual, nas diretrizes orçamentárias e no orçamento anual; realizar inspeções e auditorias de natureza contábil, financeira, orçamentária, operacional e patrimonial nas unidades administrativas dos Poderes Executivo e Legislativo; fiscalizar as aplicações do Poder Público em empresas de cujo capital social o Distrito Federal participe de forma direta ou indireta; fiscalizar a aplicação de recursos repassados ou recebidos pelo Distrito Federal, a qualquer título; atender às solicitações da Câmara Legislativa relativas às atividades de Controle Externo; aplicar, em caso de ilegalidade ou irregularidade de contas, as sanções previstas em lei e sustar, se o Tribunal não for atendido, a execução de ato impugnado. No planejamento estratégico para o período de 1999 a 2003 [7] é dado especial relevo ao estabelecimento da missão institucional do TCDF com base nas competências constitucionais acima e nos arts. 77 e 78 da Lei Orgânica do Distrito Federal (LODF) [3]. Esses artigos elucidam que a fiscalização contábil, financeira, orçamentária, operacional e patrimonial dos órgãos e entidades da administração do Distrito Federal, quanto à legalidade, legitimidade, economicidade, aplicação das subvenções e renúncia de receitas é exercida pela Câmara Legislativa - mediante controle externo e pelo sistema de controle interno de cada Poder - com o auxílio do Tribunal de Contas do Distrito Federal. Assim, inferida da essência dos citados dispositivos legais, a missão do Tribunal pode ser enunciada como: Exercer o controle externo da administração dos recursos públicos do Distrito Federal, em auxílio à Câmara Legislativa, zelando pela legalidade, legitimidade, efetividade, eficácia, eficiência e economicidade na gestão desses recursos. Releva notar que o atributo principal do papel da Corte de Contas Distrital é garantir à sociedade segurança quanto à transparência e boa gestão dos recursos arrecadados e gastos pelo Governo do Distrito Federal. O papel do setor de informática A política de informatização do Tribunal tem se pautado pela adoção de soluções que associem qualidade, funcionalidade e economicidade. Nesse contexto, ao setor de informática do Tribunal, denominado Núcleo de Informática e Processamento de Dados NIPD, compete apoiar a atividade de fiscalização por meio da criação de sistemas de informação para acompanhamento dos gastos públicos, avaliação de riscos e identificação de pontos críticos para auditoria, produção, organização e divulgação de súmulas, decisões, votos, pareceres e instruções. Para auxiliar essas atividades foram desenvolvidos, em especial a partir de 1996, vários sistemas integrados em repositório de informações único.[8] Ao NIPD compete também administrar a rede de microcomputadores, executar e acompanhar a manutenção dos equipamentos de informática, bem como propor a compra de bens e serviços relativos a tecnologia. Adicionalmente, o setor mantém atualizado, com o apoio de diversas Unidades do TCDF, o site que permite a qualquer cidadão consultar os documentos públicos produzidos no exercício do controle externo. Por ser um ente público com especial apreço pela boa gestão dos recursos, antes de efetuar investimentos são feitas análises de alternativas com vistas a encontrar a melhor relação custo x benefício. Essa prática, aplicada ao setor de informática será, como apresentado a seguir, motivadora do desenvolvimento de um processo de produção de software. Motivação para o estabelecimento do processo de desenvolvimento Devido ao esforço necessário ao estabelecimento de um processo de desenvolvimento, em especial quando se conta com poucos recursos humanos e materiais, foi fundamental para o empenho na produção do mesmo a existência das motivações a seguir relacionadas. Melhoria da qualidade de produtos Sendo o TCDF um órgão de informatização relativamente recente, a partir de 1995, a equipe responsável pelo desenvolvimento de sistemas teve a oportunidade de construir todo um conjunto de aplicações corporativas, com base nas necessidades identificadas junto aos usuários, integrado e homogêneo. No entanto, o processo de construção dessas soluções foi fortemente influenciado pela experiência profissional dos técnicos e, apesar de ter sido um processo repetitivo, não era explicitado formalmente. Hoje, contando com mais de dez aplicações em produção ( linhas de código fonte em Visual Basic, VB Script, Java, Java Script e HTML), que, portanto, requerem manutenção, e sem modificação no quadro de desenvolvedores (2 analistas e 4 programadores), faz-se necessário aprimorar o processo de trabalho visando a elaboração 19 20

11 de produtos com menor número de erros possível, que observem a integração e a homogeneidade dos sistemas já desenvolvidos. Planejamento de novas demandas Da forma atual, as estimativas de prazo para desenvolvimento ou manutenção de sistemas são baseadas somente na experiência pessoal dos técnicos, sem um acompanhamento efetivo dos prazos. Essa situação, apesar de bastante comum nas organizações, é fator de risco para a credibilidade do setor no caso de falha. Felizmente, desde 1995, os técnicos tem acertado em suas previsões à administração da Casa. No entanto, o acompanhamento sistemático do processo de desenvolvimento de software será fundamental para aperfeiçoar as estimativas de prazos e recursos de novas demandas de sistemas. Mudança de plataforma computacional Com a relativa estabilização da demanda por desenvolvimento de novos serviços e programas ao setor de informática do TCDF, a partir do final de 1998, a equipe técnica iniciou trabalho de busca de alternativas com vistas a reduzir a necessidade de investimentos em informática e identificou grupos de programas que, se substituídos, levariam a essa redução. Esse trabalho subsidiou a Presidência do Tribunal a decidir substituir, até o final do ano de 2002, o sistema operacional Windows 95 pelo Linux nas estações de trabalho do TCDF, proporcionando elevada redução de investimentos com hardware e software [8]. Assim, com vistas a possibilitar essa substituição, será necessário converter todos os sistemas desenvolvidos e configurar aplicativos de escritório que possibilitem ao usuário final usufruir das mesmas funcionalidades hoje disponíveis. Esse fato gerará intenso esforço de codificação que, sem acompanhamento formalizado por meio de um processo de desenvolvimento definido e utilizado por todos os técnicos, poderá inviabilizar a substituição da plataforma computacional proposta pelo fracasso na conversão dos sistemas. Para que seja possível substituir gradualmente as aplicações, optou-se por utilizar a linguagem Java como padrão para a execução dessa tarefa. A linguagem de programação Java permite disponibilizar os sistemas tanto para estações Windows 95 como Linux e irá facilitar a reutilização de código. IV. Implementando Um Processo De Melhoria Contínua Metodologia Empregada Conforme podemos observar em, um processo contínuo de melhoria pode ser implementado institucionalmente, independente se a atividade fim da empresa é produzir software ou outra qualquer, seguindo-se alguns passos descritos detalhadamente a seguir:[5] - Montar uma Equipe de Melhoria do Processo: A primeira e mais crítica atividade ao montar uma equipe é a aprovação da gerência para todo o processo de melhoria do software na organização. É importante destacar que nesse processo uma série de recursos devem ser alocados. A equipe designada para essa tarefa, preferencialmente em tempo integral, deve ser composta de técnicos experientes, com credibilidade dentro da organização, podendo contar também com a participação de pesquisadores e consultores externos. Hoje já é amplamente reconhecido que uma equipe de melhoria dos processos da organização deve ser mantida em uma estrutura separada do desenvolvimento de software. Essa equipe deve ter um mandato, ou tempo de duração bem definido, por exemplo: o tempo de ser implantado um processo de qualidade com certificação ISO Nesse ambiente em que foi implementado o Modelo GQM, a montagem da equipe de melhoria dos processos foi o primeiro passo dos trabalhos. Os profissionais mais experientes foram alocados e levantaram todos os processos do TCDF, propondo melhorias nos que não se enquadravam plenamente no novo processo de informatização da organização. O levantamento desses processos foi feito por 6 (seis) analistas de sistemas durante um mês, dedicados exclusivamente à esta tarefa. - Modelar os Processos Existentes: Modelar os processos existentes em uma organização pode servir para vários propósitos e agregar diversos benefícios. No contexto de melhoria de processos, modelos de processos descritivos são úteis para se entender a maneira como as coisas funcionam e para comunicar esse entendimento. Algumas questões básicas que necessitam serem respondidas em uma modelagem de processos são: - Quais são as atividades do processo? - Quais são as dependências entre essas atividades? - Quando as atividades iniciam e terminam? - Quem são os atores que executam essas atividades? - Quais são as interdependências entre estes atores? 21 22

12 Fontes de informação para responder essas questões indicam que devem ser utilizadas entrevistas com os membros da organização, inspeções nas documentações dos processos (quando existirem), inspeções nas documentações de gerência do projeto e também observações diretas na equipe de desenvolvimento. Os modelos de processos que foram desenvolvidos serão usados em passos subsequentes do processo de melhoria. Um bom sinal é quando os desenvolvedores penduram partes dos modelos em seus ambientes de trabalho, significa que estão sendo úteis para o dia a dia dos seus trabalhos. No TCDF, os prováveis processos a serem informatizados, foram modelados e descritos de forma a explanar claramente as atividades intrínsecas de cada um, as dependências entre essas atividades, o tempo de duração de cada uma delas, os atores que as executam e as interdependências entre estes atores. - Conduzir uma Análise Qualitativa: A meta desse estágio é identificar as causas e os mecanismos internos que indiquem os problemas de custos e riscos elevados, relacionados à qualidade dos produtos entregues e à eficiência do processo de desenvolvimento de software. A equipe de melhoria de processos da organização, citada anteriormente, poderá ser responsável pela análise contínua desse problemas. Uma modelagem dos processos bem definida, ajudará a diferenciar os verdadeiros problemas dos aspectos irrelevantes. Nesse contexto, existem três técnicas principais para se fazer a análise qualitativa: entrevistas estruturadas, análise eventual dos problemas e questionários bem definidos e bem desenhados. No contexto da análise qualitativa, essas técnicas se complementam, pois, permitem uma checagem cruzada das informações levantadas. A análise eventual é usualmente iniciada quando é reportado um problema vindo da fase de testes, ou já da operação, de um determinado sistema. Para executar a análise eventual alguns procedimentos são recomendados: - Selecione um sistema, ou versão, relevante para a organização; - Obtenha todos os relatórios de problemas; - Classifique as falhas de programas de acordo com tipos e níveis de gravidade; - Determine as causas de maior gravidade de falhas em termos de erros humanos e falhas nos processos; - Desenvolva recomendações para mudanças de processos e valide-as com os participantes da análise eventual; - Refine as linhas gerais da análise eventual e a nomenclatura utilizada para auxiliar futuras análises. A execução destes procedimentos assume que a organização tem processos bem definidos e modelos organizacionais. No TCDF, como os processos já haviam sido modelados e bem definidos, nesta fase foram elaborados também os procedimentos de coleta de dados e desenhados os 23 formulários. Foi selecionado o Sistema de Acompanhamento de Processos para uma análise preliminar da metodologia a ser empregada. Foram levantados os problemas apresentados na versão do sistema e classificadas a s falhas segundo critérios de gravidade estabelecidos pelo gerente de informática. - Definir e Documentar um Plano de Ação: Uma vez que os processos estão modelados e seus pontos fortes e fracos estão bem entendidos, um plano de ação deve ser definido. Para o Software Engineering Process Group Guide o plano de ação é definido como: Uma resposta formal, escrita da avaliação (do processo) e o mapa para sua melhoria. O plano de ação é extremamente importante por várias razões, dentre elas podemos citar: é solicitado para conseguir uma mudança do orçamento para as próximas fases (avaliação das soluções, mudanças nos processos), é crucial para transferir as informações corretas para a gerência e para os desenvolvedores sobre a importância e as dificuldades do que será realizado. Um possível esboço de alto nível de plano de ação pode ter o seguinte formato: - Melhora corporativa dos objetivos e motivações; - O plano de ação dos diversos grupos e participantes do processo de melhoria, suas responsabilidades e prerrogativas; - Os passos da melhoria, suas conexões com os objetivos corporativos e seus critérios de entrada e saída; - As fases que conduzem para os critérios de saída de cada passo de melhoria, os riscos e incertezas associados a cada fase e os planos de contingência correspondentes, os gerentes encarregados de monitorar e organizar as fases de execução; - O conjunto de atividades envolvidas em cada fase de cada passo, os participantes em cada atividade e suas responsabilidades; - O esforço e o custo para cada passo e fase, com intervalos indeterminados; - Os benefícios esperados baseados em experiências externas e em informações existentes sobre qualidade e produtividade da organização. Como Plano de Ação para o TCDF foi estabelecida uma metodologia que contempla: procedimentos de desenvolvimento e manutenção de sistemas, estabelecimento de um fluxo de solicitações de sistemas, o Sistema de Acompanhamento do Desenvolvimento de Sistemas SADS, que permite o registro do processo e a extração das métricas estabelecidas (todos estes itens podem ser vistos no Anexo I deste documento). - Montar um Programa de Medição: A princípio um programa de medição é geralmente projetado para: prover uma base quantitativa de comparações para futuras mudanças de processos, melhor entendimento dos requisitos que tenha ou não sido identificados na análise qualitativa precedendo a medição, e finalmente, fazer com que o processo de tomada decisões seja menos arriscado provendo informações gerenciais corretas e no tempo certo sobre produtos de software e os processos utilizados para desenvolvê-los. Em várias ocasiões já foi percebido que o êxito de um 24

13 programa de medições está no seu direcionamento para as metas e objetivos da organização. Os passos usuais de um processo de medição podem ser resumidos da seguinte forma: - Definir metas corporativas e de medidas; - Derivar modelos e medidas que pareçam adequados no contexto específico de medições; - Definir procedimentos de coleta de dados para coletar dados válidos e corretos; - Treinar os participantes em procedimentos de coleta de dados; - Testar a coleta de dados e validar os procedimentos em projetos piloto, simplificando e refinando-os quando necessário; - Expandindo o uso das medições em toda a organização; - Analisar os dados coletados para verificar a utilidade destes dados e a exatidão dos modelos; - Refinar modelos, medidas e procedimentos de coleta de dados, voltar ao passo 4. Algumas fontes usuais de problemas quando são implementados programas de medição: - A coleta de dados não voltada para as metas; - As metas de medição não estão claramente especificadas e/ou claramente comunicadas aos colaboradores; - Muitas metas a serem coletadas de uma só vez. Conflito entre as metas da alta gerência com as metas operacionais e vice-versa; - Desenvolvedores têm que coletar muitos dados; - A equipe encarregada do programa de medição não teve o treinamento adequado e/ou não tem experiência suficiente. Para transferir a tecnologia para a memória da organização, alguns pré-requisitos devem ser observados. Primeiro, a estrutura de recompensa deve ser mudada para refletir as metas da tecnologia transferida. Por exemplo, se a cultura atual da organização recompensa a produtividade, então a introdução de métodos estruturados de análise e projeto, que diminuem a rapidez da execução das primeiras fases do projeto, são improváveis de serem adotados pela organização ou, caso sejam adotadas pela organização, o seu uso efetivo será improvável. Segundo, deve haver um número de consultores especialistas na tecnologia disponível para resolver os problemas e, se necessário, prover treinamento para os membros da organização. Por ser o TCDF uma organização pública, que contém processos e procedimentos estabelecidos em leis, as mudanças dos processos muitas vezes tornam-se problemáticas e até impossíveis de serem realizadas. Neste cenário, mudar a organização é praticamente inviável. O que é factível, e que já está em curso, é a proposição de mudanças sistemáticas e paulatinas na execução de processos e procedimentos. Esta proposição é feita demonstrando-se os aspectos favoráveis e desfavoráveis destas mudanças, encaminhandoas para posterior decisão das autoridades competentes, gestoras destes processos. Neste capítulo os autores apresentaram uma abordagem ascendente para a melhoria prática do processo de produção de software e seus produtos. Estes passos devem ser vistos como uma implantação do Paradigma de Aperfeiçoamento da Qualidade QIP. A fim de facilitar sua aplicação em diferentes organizações de desenvolvimento e manutenção de software, os autores montaram um conjunto de passos e diretrizes deste paradigma, baseados em suas experiências adquiridas, conduzindo estudos quantitativos e qualitativos, em diversas organizações públicas e privadas. Neste passo da metodologia foram feitas as entrevistas recomendadas na abordagem GQM, onde foram definidas as metas corporativas e de medidas. Foram aplicados os procedimentos de coleta de dados e implantadas as rotinas de utilização formulários desenhados anteriormente, sendo treinados os funcionários responsáveis pela captação e alimentação dos dados. Este passo não apresentou problemas, pois, a coleta dos dados foi voltada para as metas estabelecidas nas entrevistas, as metas de medição foram claramente especificadas. Não houve uma sobrecarga no trabalho dos desenvolvedores para coletar os dados toda a equipe foi treinada no processo de coleta de dados. - Mudar os Processos e a Organização: Após o Projeto Piloto e a revisão dos seus resultados, a tecnologia deve ser transferida para a memória da organização. Tudo que pôde ser observado no Projeto Piloto deve ser usado para ensinar a tecnologia, as formas e materiais de seu treinamento para a organização. Também os procedimentos de coleta de dados talvez tenham de ser modificados para levar em conta as lições aprendidas no Projeto Piloto

14 V. Conclusão, Perspectivas e Futuros Trabalhos O presente trabalho tem por objetivo apresentar a fundamentação teórica e um caso prático da abordagem QIP/GQM aplicada em uma empresa brasileira, o Tribunal de Contas do Distrito Federal TCDF. Nos principais modelos de qualidade de software apresentados neste trabalho, o modelo CMM foi o escolhido por nortear de forma objetiva e direta, as ações de implementação de modelos de qualidade de software em empresas nacionais. O Paradigma de Aperfeiçoamento da qualidade QIP estabelece premissas fundamentais para que uma organização possa melhorar cada processo de software: caracterizar o ambiente, definir os objetivos, escolher os processos, analisar os dados e informações e finalmente empacotar as experiências adquiridas nesse projeto realizado. Essas experiências devem ser armazenadas na Fábrica de Experiências, para que possa ser estabelecida uma continuidade do processo de melhoria de software nas organizações. A abordagem GQM, objeto de estudo deste trabalho, é utilizada como mecanismo ou técnica, para que seja implementado um programa permanente de avaliação e melhoria da qualidade de software das organizações. Esta técnica foi escolhida principalmente pela sua abordagem objetiva e abrangente na condução dos trabalhos de melhoria da qualidade de software dentro das organizações. Conforme foi citado anteriormente, o presente trabalho será a parte inicial da dissertação de mestrado que versará sobre a viabilidade de se implantar e manter modelos de qualidade de software em empresas brasileiras, visando a melhoria contínua dos produtos de software dessas empresas. Para tanto, pretende-se implementar a abordagem GQM. com todas as suas implicações, em outra empresa nacional. Contaremos com a colaboração da equipe do Núcleo de Informática do TCDF para orientar a implantação de todo o processo, que deverá se dar primeiramente em uma equipe de desenvolvimento de software provavelmente da ECT -Correios do Brasil. Bibliografia [1] BASILI, Victor R.; CALDIERA, Gianluigi; ROMBACH, H. Dieter. The Experience Factory. Institute for Advanced Computer Studies / Department of Computer Science / University of Maryland (EUA); & FB Informatik / Universität Kaiserlautern (Alemanha). In: tame.html. [2]. The Goal Question Metric Approach. Institute for Advanced Computer Studies / Department of Computer Science / University of Maryland (EUA); & FB Informatik / Universität Kaiserlautern (Alemanha). In: tame.html. [3] BRASIL. CÂMARA LEGISLATIVA - DF. Lei Orgânica do Distrito Federal, Brasília: Câmara Legislativa, [4] BRASIL. CONGRESSO NACIONAL. Constituição Federal, Brasília: Congresso Nacional, [5] BRIAND, Lionel; EL EMAM, Khaled; MELO, Walcélio L. An Inductive Method for Software Process Improvement: Concrete Steps and Guidelines. In: Elements of Software Process Assessment and Improvement. Los Alamitos, California (EUA): IEEE Computer Society, p. p [6] DION, Ray. Starting the Climb Towards the CMM Level 2 Plateau. In: Elements of Software Process Assessment and Improvement. Los Alamitos, California (EUA): IEEE Computer Society, p. p [7] DISTRITO FEDERAL (Brasil). Tribunal de Contas do Distrito Federal - DF. Plano Estratégico do Tribunal: PLANEST; Período , Brasília: TCDF/DIPLAN, [8]. Tecnologia da Informação Triênio , Brasília: TCDF/NIPD, [9] JOHNSON, Donna L.; BRODMAN, Judith G. Tailoring the CMM for Small Businesses, Small Organizations, and Small Projects. In: Elements 27 28

15 of Software Process Assessment and Improvement. Los Alamitos, California (EUA): IEEE Computer Society, p. p [10] MCGARRY, Frank; PAGE, Gerald; BASILI, Victor; et al. Software Process Improvement in The NASA Software Engineering Laboratory. Technical Report CMU/SEI-94-TR-22. ESC-TR Dezembro,1994. NASA/Goddard Space Flight Center; Computer Sciences Corporation (EUA); & University of Maryland (EUA). In: tame/tame.html. [11] NASA. Sample SEL Data Collection Forms: Development Estimates Form and Report Form. In: forms.htm. [12] NASA. Software Process Improvement Guidebook. NASA Janeiro, NASA-GB In: [13] PAULK, Mark C.; WEBER, Charles V.; CHRISSIS, Mary Beth. The Capability Maturity Model for Software. In: Elements of Software Process Assessment and Improvement. Los Alamitos, California (EUA): IEEE Computer Society, [14] PRESSMAN, Roger S. Engenharia de Software. Tradução de José Carlos Barbosa dos Santos. São Paulo: Makron Books, p. p [15] EDWARD DEMING, Out of the Crisis, MIT Center of Advanced Engineering Study, MIT Press, Cambridge, MA,

16 ANEXO I Modelo GQM aplicado ao desenvolvimento de sistemas no TCDF Considerando o contexto e as razões acima descritos estabeleceu-se o seguinte modelo Goal, Question, Metric, adiante detalhado, para a área de desenvolvimento de sistemas do Tribunal de Contas do DF. Objetivo Propósito Melhoria G1 Aspecto Qualidade Objeto Ponto de vista Sistemas Desenvolvidos (produto) Gerente Questão Q1 Quantidade de erros encontrados pelo usuário? Métricas M1 # mensal de ocorrências de manutenções corretivas M2 M3 M4 M5 # mensal de ocorrências de erros que afetam o desempenho dos sistemas # mensal de ocorrências de erros que afetam o funcionamento de pelo menos uma função # mensal de ocorrências de erros que afetam o funcionamento de pelo menos um sistema # mensal de ocorrências de erros que geram informações inconsistentes Questão Q2 A qualidade dos produtos está melhorando? Métricas M6 % de variação do último mês com relação a média acumulada para M1 M7 M8 M9 M10 % de variação do último mês com relação a média acumulada para M2 % de variação do último mês com relação a média acumulada para M3 % de variação do último mês com relação a média acumulada para M4 % de variação do último mês com relação a média acumulada para M5 Objetivo Propósito Avaliar G2 Aspecto Tempo Objeto Ponto de vista Conversão dos sistemas em Visual Basic (VB) para Java Gerente Questão Q3 Qual o tamanho do sistemas originais (VB)? Métricas M11 Quantidade de arquivos dos sistemas originais M12 Quantidade de linhas de código (LOC) dos sistemas Questão Q4 Qual o tamanho dos sistemas convertidos? Métricas M13 Quantidade de arquivos dos sistemas convertidos para Java M14 Quantidade de linhas de código (LOC) dos sistemas convertidos para Java Questão Q5 Qual o tempo necessário para conversão? Métricas M15 Tempo total de conversão por sistema em VB M16 Métricas M17 M16 por arquivo VB Objetivo Propósito Avaliar G3 Aspecto Planejamento Objeto Ponto de vista Tempo médio de conversão de uma LOC em VB para Java Processo de Desenvolvimento de Sistemas Gerente

17 Questão Q6 Qual a diferença entre o esforço (tempo) estimado e o realizado? Métricas M18 (Esforço real - Esforço estimado) por ocorrência e fase M19 M20 (M18 / Esforço estimado) * 100 por ocorrência e fase Média de M19 por objetivo e fase Questão Q7 Qual a diferença entre os prazos previstos e realizados? Métricas M21 (Data de início real - Data de início estimada) em dias por ocorrência e fase M22 M23 M24 Objetivo Propósito Avaliar G4 Aspecto Qualidade Objeto Ponto de vista Média de M21 por objetivo e fase (Data de fim real - Data de fim estimada) em dias por ocorrência e fase Média de M23 por objetivo e fase Processo de Desenvolvimento de Sistemas Gerente Questão Q8 Qual o número de erros identificados pela equipe de desenvolvimento durante a elaboração do sistema? Métricas M25 # mensal de erros encontrados na leitura de código M26 # mensal de erros encontrados na leitura de código que afetam o desempenho dos sistemas M27 M28 M29 M30 M31 M32 M33 M34 # mensal de erros encontrados na leitura de código que afetam o funcionamento de pelo menos uma função # mensal de erros encontrados na leitura de código que afetam o funcionamento de pelo menos um sistema # mensal de erros encontrados na leitura de código que que geram informações inconsistentes # mensal de erros encontrados nos testes de integração e implantação #mensal de erros encontrados nos testes de integração e implantação que afetam o desempenho dos sistemas # mensal de erros encontrados nos testes de integração e implantação que afetam o funcionamento de pelo menos uma função # mensal de erros encontrados nos testes de integração e implantação que afetam o funcionamento de pelo menos um sistema # mensal de erros encontrados nos testes de integração e implantação que que geram informações inconsistentes Questão Q9 Qual a relação entre os erros encontrados pelo usuário e os erros identificados durante a elaboração do sistema? M35 M1 / (M25 + M30) M36 M2 / (M26 + M31) M37 M3 / (M27 + M32) M38 M4 / (M28 + M33) M39 M5 / (M29 + M34) Questão Q10 Qual a origem (fonte) dos erros encontrados? M40 M41 M42 # mensal de erros encontrados pelos usuários por fonte de erro # mensal de erros encontrados na leitura de código por fonte de erro # mensal de erros encontrados nos testes de integração e implantação por fonte de erro M43 M40 / (M41 + M42)

18 Objetivo G1 - Melhoria da Qualidade dos Sistemas Desenvolvidos Procura-se aqui ter condições de dimensionar a melhoria dos produtos entregues aos usuários finais, utilizando-se como indicador principal a quantidade de erros percebida pelos usuários. Para esse objetivo foram definidas duas questões: 1. Q1 - Qual a quantidade de erros encontrados pelos usuário? - procura dimensionar os vazamentos de erros não encontrados na produção do sistema, permitindo quantificar os transtornos causados aos usuários. Em resposta a essa questão foram extraídas as seguintes medidas: 1.1. M1 = Número mensal de ocorrências de manutenções corretivas - contabiliza todas as ocorrências de erros encontradas pelos usuários independentemente de sua gravidade; 1.2. M2 = Número mensal de ocorrências de erros que afetam o desempenho dos sistemas - constituem um subgrupo de M1 e foram destacadas pois prejudicam o desempenho do sistema; 1.3. M3 = Número mensal de ocorrências de erros que afetam o funcionamento de pelo menos uma função - constituem outro subgrupo de M1 e foram destacadas pois prejudicam o desempenho de pelo menos uma função (tipicamente uma tela de transação) do sistema; 1.4. M4 = Número mensal de ocorrências de erros que afetam o funcionamento de pelo menos um sistema - constituem outro subgrupo de M1 e foram destacadas pois prejudicam o desempenho de pelo menos um sistema (toda uma aplicação); e 1.5. M5 = Número mensal de ocorrências de erros que geram informações inconsistentes - constituem outro subconjunto de M1 e foram destacadas pois provocam o armazenamento ou exibição de informações inconsistentes. 2. Q2 - A qualidade dos produtos está melhorando? - visa avaliar a evolução da qualidade dos produtos entregues por meio da comparação das métricas da Q1 acima descritas ao longo do tempo. Em resposta a essa questão foram extraídas as métricas abaixo: 2.1. M6 = Percentual de variação do último mês com relação a média acumulada para M1 - obtida pela divisão da medida de M1 para o último mês pela média de M1 nos meses anteriores ao último mês multiplicado por 100; 2.2. M7 = Percentual de variação do último mês com relação a média acumulada para M2 - cálculo idêntico ao de M6 utilizando como parâmetro M2; 2.3. M8 = Percentual de variação do último mês com relação a média acumulada para M3 - cálculo idêntico ao de M6 utilizando como parâmetro M3; 2.4. M9 = Percentual de variação do último mês com relação a média acumulada para M4 - cálculo idêntico ao de M6 utilizando como parâmetro M4; e 2.5. M10 = Percentual de variação do último mês com relação a média acumulada para M5 - cálculo idêntico ao de M6 utilizando como parâmetro M5. Objetivo G2 - Avaliar o tempo de conversão de sistemas em Visual Basic para Java Tendo em vista a mencionada estratégia de substituição do sistema operacional utilizado no TCDF, faz-se necessário reescrever todos os sistemas em produção na linguagem Java para que os mesmos possam continuar sendo utilizados. Esse objetivo visa aperfeiçoar as estimativas de conversão dos sistemas por meio da análise das seguintes questões: 1. Q3 - Qual o tamanho dos sistemas originais em Visual Basic? - essa questão é relevante para dimensionar a tarefa a ser executada. Para respondê-la são medidos: 1.1. M11 = Número de arquivos fonte por sistema - agrupam-se os arquivos dos sistemas desenvolvidos e em desenvolvimento em diretórios de trabalho específicos e procede-se a contagem. Essa métrica é extraída por apuração automática em lote, pelo próprio sistema de apoio ao processo, não necessitando de preenchimento de formulários; e 1.2. M12 = Número de linhas de código por sistema - somam-se as linhas de código, observada a sintaxe do Visual Basic, dos arquivos que compõem os sistemas de informação. Essa métrica é extraída por apuração em lote não necessitando de preenchimento de formulários. 2. Q4 - Qual o tamanho dos sistemas convertidos em Java? - assim, pode-se avaliar o impacto de substituição da linguagem em termos de tamanho (LOC) dos sistemas convertidos e acompanhar o progresso do processo de conversão. Para responder a essa questão são medidos: 2.1. M13 = Número de arquivos dos sistemas - contagem efetuada de forma idêntica a M11 para os diretórios dos sistemas em Java; e 2.2. M14 = Número de linhas de código por sistema - soma efetuada de forma idêntica a M12 para os diretórios dos sistemas em Java. 3. Q5 - Qual o tempo para conversão dos sistemas? - questão principal para o objetivo pretendido pois informa o esforço realizado até o momento e permite estimar a tarefa restante. Para responder a essa questão são extraídas as seguintes medidas: 3.1. M15 = Tempo total de conversão por sistema - soma das horas de trabalhadas para conversão de cada sistema até o momento; 3.2. M16 = Tempo médio de conversão de uma linha de código em VB para Java -

19 soma de todo o tempo de codificação em Java para conversão dividida pelo tamanho (em linhas de código VB) de todos os arquivos convertidos até o momento; e 3.3. M17 = Tempo médio de conversão de uma linha de código em VB para Java por arquivo VB - soma de todo o tempo de codificação em Java para conversão do arquivo dividida pelo tamanho (em linhas de código VB) do arquivo - possibilita avaliar a evolução da eficiência do trabalho e a complexidade da conversão de cada arquivo. Objetivo G3 - Avaliar o planejamento do processo de desenvolvimento de sistemas O processo de desenvolvimento de sistemas implantado contempla o planejamento de prazos e recursos. No entanto, para a efetividade do planejamento é necessário avaliar o seu grau de precisão e efetuar as correções necessárias. 1. Q6 - Qual a diferença entre o esforço (tempo) estimado e o realizado? - questão que possibilita verificar a precisão do planejamento de recursos; no caso do TCDF, o principal recurso para desenvolvimento de sistemas é a hora de trabalho dos técnicos. Assim, foram estabelecidas as seguintes medidas: 1.1. M18 = (esforço real - esforço estimado) agrupado por ocorrência e fase (entendase fase do processo de desenvolvimento como: especificação, codificação, leitura de código, e teste de integração e implementação) - diferença em minutos entre o esforço real e o esforço estimado - valores negativos expressam estimativas a maior e valores positivos estimativas a menor; 1.2. M19 = (M18 / esforço estimado) * 100 agrupado por ocorrência e fase - indica o percentual de erro das estimativas com relação ao esforço previsto; 1.3. M20 = Média de M19 agrupada por objetivo (entenda-se objetivo da ação da equipe de desenvolvimento em cada ocorrência: manutenção corretiva, manutenção evolutiva ou desenvolvimento de um novo sistema) e fase - permite avaliar se há discrepâncias significativas entre as previsões feitas para cada tipo de objetivo e dentro de cada objetivo por fase do processo de desenvolvimento de sistemas. 2. Q7 = Qual a diferença entre os prazos previstos e reais? - possibilita aferir a precisão das estimativas de datas de início e fim de cada fase do processo de desenvolvimento. Para essa aferição são computados: 2.1. M21 = (data de início real - data de início estimada) em dias agrupado por ocorrência e fase - mede a precisão no planejamento do início de cada fase do processo de desenvolvimento - valores negativos indicam fases iniciadas antes da data estimada; 2.2. M22 = Média de M21 agrupada por objetivo e fase - indica se há variação sensível entre as previsões de início por objetivo e/ou fase do processo de desenvolvimento de sistemas; 2.3. M23 = (data de fim real - data de fim estimada) em dias agrupado por ocorrência e fase - mede a precisão no planejamento do fim de cada fase do processo de desenvolvimento - valores negativos indicam fases concluídas antes da data estimada; e 2.4. M24 = Média de M23 agrupada por objetivo e fase - indica se há variação sensível entre as previsões de término por objetivo e/ou fase do processo de desenvolvimento de sistemas. Objetivo G4 - Avaliar a qualidade do processo de desenvolvimento de sistemas Com a implantação do processo de desenvolvimento de sistemas pretende-se reduzir o número de erros encontrados pelo usuário, ou seja, erros após a entrada do sistema em produção, estabelecendo-se pontos de teste no processo de desenvolvimento de sistemas com a execução das atividades de leitura de código e teste de integração e implantação. Assim, para avaliar a efetividade do processo em termos de identificação de erros e redução de vazamentos (erros encontrados pelos usuários) foram definidas as seguintes questões: 1. Q8 - Qual o número de erros identificados pela equipe de desenvolvimento durante a elaboração do sistema? - possibilita aferir a eficácia das atividades de teste implantadas com o processo de desenvolvimento de sistemas. Para essa questão são medidos: 1.1. M25 = Número mensal de erros encontrados na leitura de código - totaliza a quantidade de erros identificados na fase de leitura de código pela equipe de desenvolvedores a cada mês; 1.2. M26 = Número mensal de erros encontrados na leitura de código que afetam o desempenho dos sistemas - indica a quantidade de erros identificados na fase de leitura de código que prejudicam o desempenho do sistema pela equipe de desenvolvedores a cada mês; 1.3. M27 = Número mensal de erros encontrados na leitura de código que afetam o funcionamento de pelo menos uma função - indica a quantidade de erros identificados na fase de leitura de código que prejudicam o desempenho de pelo menos uma função (tipicamente uma tela de transação) do sistema pela equipe de desenvolvedores a cada mês; 1.4. M28 = Número mensal de erros encontrados na leitura de código que afetam o funcionamento de pelo menos um sistema - indica a quantidade de erros identificados na fase de leitura de código que prejudicam o desempenho de pelo menos um sistema (toda uma aplicação) pela equipe de desenvolvedores a cada mês; 1.5. M29 = Número mensal de erros encontrados na leitura de código que geram informações inconsistentes - indica a quantidade de erros identificados na fase de

20 leitura de código que provocam o armazenamento ou exibição de informações inconsistentes pela equipe de desenvolvedores a cada mês; 1.6. M30 = Número mensal de erros encontrados nos testes de integração e implantação - totaliza a quantidade de erros identificados na fase testes de integração e implantação pela equipe de desenvolvedores a cada mês; 1.7. M31 = Número mensal de erros encontrados nos testes de integração e implantação que afetam o desempenho dos sistemas - indica a quantidade de erros identificados na fase testes de integração e implantação que prejudicam o desempenho do sistema pela equipe de desenvolvedores a cada mês; 1.8. M32 = Número mensal de erros encontrados nos testes de integração e implantação que afetam o funcionamento de pelo menos uma função - indica a quantidade de erros identificados na fase testes de integração e implantação que prejudicam o desempenho de pelo menos uma função (tipicamente uma tela de transação) do sistema pela equipe de desenvolvedores a cada mês; 1.9. M33 = Número mensal de erros encontrados nos testes de integração e implantação que afetam o funcionamento de pelo menos um sistema - indica a quantidade de erros identificados na fase testes de integração e implantação que prejudicam o desempenho de pelo menos um sistema (toda uma aplicação) pela equipe de desenvolvedores a cada mês; M34 = Número mensal de erros encontrados nos testes de integração e implantação que geram informações inconsistentes - indica a quantidade de erros identificados na fase testes de integração e implantação que provocam o armazenamento ou exibição de informações inconsistentes pela equipe de desenvolvedores a cada mês; erros que afetam o funcionamento de pelo menos um sistema; e 2.5. M39 = M5 / (M29 + M34) - análoga a métrica M36 limitando a comparação aos erros que geram informações inconsistentes 3. Q10 - Qual a origem (fonte) dos erros encontrados? - visa caracterizar a origem dos erros para auxiliar na redução dos mesmos. As fontes de erro possíveis no processo de desenvolvimento implantado são: codificação, especificação, modificação anterior e requerimentos do usuário. Para caracterizar as origens dos erros são medidos: 3.1. M40 = Número mensal de erros encontrados pelos usuários por fonte de erro - agrupa mensalmente os erros encontrados pelos usuários de acordo com a fonte de erro indicada pelo analista responsável pela resolução da ocorrência; 3.2. M41 = Número mensal de erros encontrados na leitura de código por fonte de erro - agrupa mensalmente os erros encontrados pela equipe de desenvolvimento na fase de leitura de código classificados de acordo com o técnico responsável; 3.3. M42 = Número mensal de erros encontrados nos testes de integração e implantação por fonte de erro - agrupa mensalmente os erros encontrados na fase de testes de integração e implantação pela equipe de desenvolvimento de sistema classificados de acordo com o técnico responsável; e 3.4. M43 = M40 / (M41 + M42) - compara os erros encontrados pelos usuários e pela equipe técnica de acordo com a fonte de erro indicada. Todas essas métricas são obtidas automaticamente por meio dos sistemas de apoio ao processo de desenvolvimento implantado, descrito no próximo capítulo. 2. Q9 - Qual a relação entre o número de erros identificados pelo usuário e os erros identificados durante a elaboração do sistema? - possibilita a comparação entre as quantidades de erros encontrados pelos usuários dos sistemas (vazamentos) e de erros encontrados pela equipe de desenvolvimento de sistemas nas fases de leitura de código e testes de integração e implantação. Para efetuar essa comparação são extraídas: 2.1. M35 = M1 / (M25 + M30) - compara o total de erros encontrados pelo usuário com o total de erros encontrados pela equipe de desenvolvimento a cada mês. Valores acima de 1 indicam que os usuários estão encontrando mais erros do que a equipe de desenvolvimento; 2.2. M36 = M2 / (M26 + M31) - análoga a métrica anterior limitando a comparação aos erros que afetam o desempenho dos sistemas; 2.3. M37 = M3 / (M27 + M32) - análoga a métrica anterior limitando a comparação aos erros que afetam o funcionamento de pelo menos uma função; 2.4. M38 = M4 / (M28 + M33) - análoga a métrica M36 limitando a comparação aos