Unidade I - Qualidade de Produto

Prévia do material em texto

*
Unidade I: Qualidade de Produto
Qualidade de Software
 Conceitos básicos de qualidade de software
* 
Segundo a NBR ISO 9000:2005, "qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos". Ou seja, pode-se afirmar que se algum produto ou serviço atende aos requisitos especificados, este mesmo produto ou serviço possui a qualidade desejada. 
A qualidade pode ser medida através do grau de satisfação em que as pessoas avaliam determinado produto ou serviço. No entanto, esse produto ou serviço pode ter qualidade para algumas pessoas e para outras nem tanto, ou seja, a qualidade é algo subjetivo. 
Conceituar desta forma então o termo qualidade se torna uma tarefa muito difícil, pois elementos intrínsecos estão enraizados no intelecto de cada ser. 
O termo TQM (Total Quality Management) – Gestão da qualidade total, amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. De acordo com Kan (2002), "O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica." (KAN, 2002, p. 30). Independente dos seus vários tipos de implementação.
* 
Os elementos chave do TQM podem ser resumidos conforme Figura 1, abaixo: 
 
Figura 1 - Elementos chave do TQM. 
* 
	Foco do Cliente (Customer Focus) - O objetivo é atingir a satisfação total do cliente. O foco do cliente inclui o estudo das necessidades e vontades do cliente, coleta de requisitos do cliente e a medição e gerenciamento da satisfação do cliente. 
	Melhoria de Processo (Process Improvement) - O objetivo é reduzir as variações de processo e atingir a melhoria da qualidade contínua. Este elemento inclui ambos os processos de negócio e o processo de desenvolvimento do produto. Através da melhoria de processo, a qualidade do produto será reforçada. 
	Lado Humano da Qualidade (Human Side of Quality) - O objetivo é criar a cultura de qualidade por toda a empresa. As áreas de foco incluem liderança, apoio da alta gerência, participação total de todos os colaboradores da empresa, e outros fatores humanos como sociais e psicológicos.
	Métricas, Modelos, Medições e Análises (Metrics, Models, Measurement and Analysis) - O objetivo é direcionar a melhoria contínua em todos os parâmetros da qualidade por um sistema de medição orientado a metas. 
No contexto de sistemas de informação e softwares o conceito da ISO aplica-se na sua totalidade, sendo que os usuários finais sempre terão as expectativas de um alto padrão de qualidade para que suas tarefas sejam sempre executadas da maneira mais adequada possível. 
* 
Tian (2005) afirma que as expectativas de qualidade para sistemas de software estão relativamente ligadas em dois aspectos: 
	"O sistema de software deve fazer o que é suposto que se faça. Em outras palavras, eles devem fazer certo as coisas". (TIAN, 2005, p. 35) 
	"Eles devem realizar estas tarefas especificas corretamente e satisfatoriamente. Em outras palavras, eles devem fazer as coisas certas". (TIAN, 2005, p. 35) 
Indiretamente, as duas afirmações de Tian (2005) estão com base na ISO 9000:2005 sendo que o sistema deve fazer o que se espera que ele faça, de acordo com seus requisitos levantados e especificados. 
Contudo, a qualidade possui alguns princípios básicos, como: 
	Tentar prevenir defeitos ao invés de consertá-los; 
	Ter a certeza que os defeitos que foram encontrados, sejam corrigidos o mais rápido possível. 
	Estabelecer e eliminar as causas, bem como os sintomas dos defeitos; 
	Auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos. 
* 
Segundo ainda a NBR ISO 8402, o conceito de qualidade é "A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas". As necessidades explícitas são aquelas expressas na definição formal de requisitos propostos pelo cliente. Esses requisitos definem as condições em que o produto ou serviço devem ser utilizados bem como seus objetivos, funções e o desempenho esperado. Já as necessidades implícitas são aquelas que, embora não expressas pelo cliente nos documentos de requisitos, são necessárias para o usuário. Estão incluídos nessas classes tanto os requisitos que não precisam ser declarados por serem óbvios como aqueles requisitos que não são percebidos como necessários no momento que o produto foi desenvolvido, mas que pela gravidade de suas consequências devem ser atendidos. 
* 
A qualidade, seja ela usada no contexto de software ou de produtos e serviços, hoje não mais é uma obrigação e um diferencial das empresas. A mesma se tornou um padrão em qualquer ramo de atividade e indústria sendo assim necessária para garantir a satisfação do cliente. Qualidade hoje em dia, não é apenas um diferencial de mercado para as empresas conseguirem vender e lucrar mais, é um pré-requisito que se deve conquistar para conseguir colocar o produto ou serviço no Mercado Global. De acordo com Jack Welch, "A qualidade é a nossa melhor garantia da fidelidade do cliente, a nossa mais forte defesa contra a competição estrangeira e o único caminho para o crescimento e para os lucros." 
 Qualidade de Software 
* 
Diante dessa complexidade na definição da palavra qualidade, Pressman (2005) sugere que a qualidade de software seja implementada e não somente uma ideia ou desejo que uma organização venha a ter. Para tanto, Pressman (2005) faz as seguintes colocações sobre qualidade de software: 
1. "Definir explicitamente o termo qualidade de software, quando o mesmo é dito";(PRESSMAN, 2005, p. 193)
 
2. "Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade"; (PRESSMAN, 2005, p. 193) 
3. "Realizar atividades de segurança da qualidade em cada projeto de software";(PRESSMAN, 2005, p. 193) 
4. "Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como consequência, a qualidade no produto final"; (PRESSMAN, 2005, p. 193) 
* 
Sendo assim, a busca constante pela qualidade não se faz apenas no começo do projeto ou no seu final realizando testes, mas sim e um processo que visa abranger toda a engenharia de software bem como a colaboração de todos os membros do time do projeto. 
Uma possível definição mais abrangente e completa para qualidade de software seria a proposta por Bartié (2002): "Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002, p. 16) 
Alguns modelos de qualidade de software também são citados por Pressman (2005). Há o que McCall e Cavano (1978) sugerem como métricas para qualidade de software. Conhecido como Fatores da Qualidade, estes fatores avaliam o software em três pontos distintos: Transição do Produto, Revisão do Produto e Operação do Produto.
* 
Na Figura 2 são mostrados os Fatores da Qualidade de McCall: 
Figura 2 - Os Fatores da Qualidade de McCall. 
Assim como o modelo proposto por McCall e Cavano (1978), "a Hewlett-Packard desenvolveu também um modelo que referencia fatores da qualidade de software e que primeiramente publicado por Grady and Caswell (1987), denominado FURPS: Functionality, Usability, Reliability, Performance e Supportability. Estes fatores estabelecem as métricas de qualidade de software para cada fase do processo de engenharia de software". (PRESSMAN, 2005, p. 539) 
* 
Além desses modelos de métricas para qualidade de software, nota-se que a constante busca pela mesma se tornou uma atividade essencial dentro das empresas. Colocando-se todos esses conceitos dentro do contexto apresentado, podemos dizer que "qualidade não é uma fase do ciclo de desenvolvimento de software ... é parte de todas as fases".(BARTIÉ, 2002, p. 16) 
Portanto, é necessário um planejamento adequado para que a qualidade de software seja atingida, conforme a definição de qualidade quedeverá ser alcançada. Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir essas metas de qualidade propostas. Para tanto, todas as etapas do ciclo de vida de engenharia de software devem ser contempladas com atividades que visam garantir a qualidade tanto do processo quanto do produto. 
Software Quality Assurance (Garantia da Qualidade de Software)
* 
Segundo Lewis (2004), uma definição formal de Software Quality Assurance (SQA) é "atividades sistemáticas fornecendo evidências para o uso pretendido para o produto total de software".(LEWIS, 2004, p. 18) 
Sendo assim, podemos ainda definir como Quality Assurance "o conjunto de atividades de apoio para fornecer confiança de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido". (LEWIS, 2004, p. 18) 
Com isso, o SQA envolve todo o processo de desenvolvimento de software fazendo as devidas monitorações e melhorias de processos pertinentes, fazendo com que os padrões, procedimentos acordados estão sendo seguidos e garantindo que problemas são encontrados e ações corretivas são tomadas. Esse tipo de ação é orientada a prevenção. O IEEE 610.12-1990 cita qualidade de software como "(1) Um padrão planejado e sistemático de todas as ações necessárias para fornecer confiança adequada que um item ou produto está em conformidade com os requisitos técnicos estabelecidos. (2) Um conjunto de atividades projetadas para avaliar o processo pelo qual produtos são desenvolvidos ou manufaturados". 
* 
O SQA é também entendida e formada por um grupo de pessoas relacionadas e empregadas através de todo o ciclo de vida de engenharia de software que positivamente influenciam e quantificam a qualidade do software que está sendo entregue. Como já foi dito, o SQA não é somente uma atividade associada exclusivamente com atividades de desenvolvimento de software, mas sim atividades que se expandem durante todo o ciclo de vida de desenvolvimento de software. Portanto, isso consiste em realizar a qualidade tanto do processo quanto do produto. No processo, podemos quantificar a sua qualidade através de métricas para qualidade de software e no produto com as técnicas de verificação e validação. Essas atividades podem ser, por exemplo, avaliações como as citadas pela ISO 9000, auditorias, inspeções formais, teste de software, revisões. Ainda no processo podemos usar os métodos de garantia da qualidade no formato de auditorias e reportes para a alta gerência, além de avaliações constantes do processo e análise estatística de controle do processo. No produto os métodos de garantia da qualidade são revisões, inspeção formal e teste de software, além de revisão dos resultados do teste de software realizada por experts, auditorias do produto e testes realizados pelo cliente. 
* 
No entanto, empresas que não possuem o grupo ou processos de SQA tendem a mostrar os seguintes indicadores de falta de qualidade, conforme Lewis (2004): 
1. O software que foi entregue frequentemente apresenta falhas; 
2. Inaceitáveis consequências de falhas de sistemas, desde financeiras até cenários reais de aplicação; 
3. Sistemas não estão frequentemente disponíveis para uso pretendido; 
4. Sistemas são freqüentemente muito caros; 
5. Custo de detectar e remover defeitos são excessivos. 
Por outro lado, empresas que possuem o grupo ou processo de SQA implementados e a sua aplicação de maneira adequada e correta mostra que: 
1. A remoção de erros acontece no momento em que se é barato corrigir; 
2. Melhoria da qualidade do produto; 
3. O SQA é um recurso para a melhoria de processo; 
4. Estabelecimento de um banco de dados de métricas como: planejamento, taxas de falhas e outros indicadores da qualidade; 
* 
Lewis (2004) cita as atividades mais comuns do SQA, sendo estas categorizadas como: Teste de Software (Verificação e Validação), Gerenciamento de Configuração de Software e Controle da Qualidade. Na Figura 3, podemos ver a relação entre essas três principais atividades juntamente com Padrões, Procedimentos, Convenções e Especificações: 
 
Figura 3 - Componentes do SQA. 
Figura 3 - Componentes do SQA. 
* 
Teste de Software (Software Testing): Conforme Lewis (2004), "É uma estratégia popular para o gerenciamento de risco". (LEWIS, 2004, p. 19) 
O teste de software é usado para verificar que requisitos funcionais e não-funcionais foram devidamente implementados. A limitação dessa abordagem (Teste de Software), entretanto, é que na fase em que ele acontece, muitas vezes é difícil de se conseguir alguma qualidade no produto. Isso porque muitas empresas ainda usam o modelo Waterfall, ou modelo cascata, que foca justamente a atividade de teste de software somente no final do modelo, ou seja, caso algum defeito seja encontrado (erros em requisitos, por exemplo) todo ciclo deverá ser inicializado novamente. O teste de software na verdade, foca quase que exclusivamente as atividades de verificação e validação.
Controle da Qualidade (Quality Control): O controle da qualidade é definido como um processo e métodos usados para monitorar o trabalho e observar se os requisitos estão sendo satisfeitos. O foco é justamente em revisões e remoção de defeitos antes mesmo do envio dos produtos. O controle da qualidade deve ser de responsabilidade da unidade organizacional que produz o produto. No entanto, é possível ter o mesmo grupo que constrói o produto, que realize também o controle da qualidade, ou estabelecer um grupo de controle da qualidade separado ou departamento dentro da mesma unidade organizacional que desenvolve o produto.
* 
O controle da qualidade consistem de checklists bem definidos em um produto que é especificado no plano de garantia da qualidade. Um exemplos clássico de controle da qualidade são as inspeções de software. A inspeção é o grau mais maduro e formal dentro das revisões, sendo necessária uma preparação prévia, participantes definidos adequadamente e critérios de entrado e saída bem definidos. 
O controle da qualidade é projetado para detectar defeitos e corrigir esses defeitos encontrados, enquanto que a garantida da qualidade é orientada através da prevenção de defeitos. 
3. Gerenciamento de Configuração de Software (SCM - Software Configuration Management): SCM é responsável por identificar, rastrear e controlar mudanças nos elementos do software de um sistema. O SCM controla a evolução do sistema de software , gerenciando versões dos componentes de software e seus relacionamentos. O propósito é identificar todos os componentes inter-relacionados do software e para controlar sua evolução através das várias fases no ciclo de vida de desenvolvimento de software. 
SCM é uma disciplina que pode ser aplicada para atividades incluindo: desenvolvimento de software, controle de documentação, problemas de rastreamento, controle de mudanças e manutenção. O SCM ainda consiste de atividades que asseguram que arquitetura e codificação são definidas e não podem ser mudados sem uma revisão dos efeitos da mudança e sua documentação. Isso porque conforme definição do SCM é controlar o código-fonte e a sua documentação associada fazendo com que o código-fonte final e suas descrições estão consistentes e representam os itens que estavam revisados e testados.
* 
Para que ainda estes três principais componentes funcionem corretamente, o sucesso do programa de garantida da qualidade de software também depende de uma coerente coleção de padrões, procedimentos, convenções e especificações, conforme Figura 3. 
A combinação de todos esses componentes e suas melhores práticas é o que chamamos de Software Quality Assurance, e que por sua vez todo esse trabalho é realizado por pessoas, garantindo então a qualidade de software do produto final entregue ao cliente ou usuário final. 
Conforme Figura 3 Componentes do SQA, o foco será exclusivamente o componente Teste de Software. 
Para que também toda essa estrutura esta devidamente documentadae aceita por todos os membros do time do projeto, é necessário um planejamento adequado. Esse planejamento é feito no Software Quality Assurance Plan ou Plano de Garantia da Qualidade de software. Segundo Lewis (2004), "O plano de garantia da qualidade de software é um resumo ou esboço das medidas de qualidade para garantir níveis de qualidade dentro do esforço do desenvolvimento de software".(LEWIS, 2004, p. 22).
O plano é usado como um baseline para comparar os níveis atuais de qualidade durante o desenvolvimento com os níveis planejados de qualidade. "O plano de SQA provê o framework e guias para o desenvolvimento de um código entendível e que seja de fácil manutenção"(LEWIS, 2004, p. 22). 
Controle da Qualidade de Software versus Garantia da Qualidade de Software 
* 
Um dos grandes erros geralmente cometidos por pessoas e empresas é confundir os conceitos e aplicação dos termos Controle da Qualidade (Quality Control) e Garantia da Qualidade (Quality Assurance). Embora usados de maneira errônea em muitos lugares, ambos os termos têm propósitos totalmente diferentes. 
A Tabela 1 - Diferenças entre Garantia da Qualidade e Controle da Qualidade mostra a diferença entre estas duas atividades: 
* 
Fonte: Quality Assurance is not Quality Control. 
	Quality Assurance	Quality Control
	1. Garantia da qualidade garante que o processo é definido e apropriado.	1. As atividades de controle da qualidade focam na descoberta de defeitos em i específicos.
	2. Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade.	2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?".
	3. Garantia da qualidade é orientada a processo.	3. Controle da qualidade é orientado a produto.
	4. Garantia da qualidade é orientada a prevenção.	4. Controle da qualidade é orientado a detecção.
	5. Foco em monitoração e melhoria de processo.	5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados.
	6. As atividades são focadas no inicio das fases no ciclo de vida de desenvolvimento de software.	6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software.
	7. Garantia da qualidade garante que você está fazendo certo as coisas e da maneira correta.	7. Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.
* 
Com isso, pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, o teste de software é orientado a produto e está dentro do domínio do controle da qualidade. 
Qualidade de Software segundo o SWEBOK 
O SWEBOK (Software Engineering Body of Knowledge - Guia de Conhecimento em Engenharia de Software) é um documento criado sob o patrocínio da IEEE (Institute of Electrical and Electronics Engineers) – Instituto de Engenheiros eletricistas e eletrônicos, com a finalidade de servir de referência em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software. Apresenta em uma das suas KA´s (Knowledge Areas) a KA de Software Quality. Abaixo na Figura 4, pode-se ver a estrutura da KA´s de Software Quality: 
* 
* 
O SWEBOK descreve ainda inúmeras maneiras para se atingir a qualidade sendo que esta KA em especifico cobre as técnicas estáticas para detecção de defeitos, não sendo requerido que o software esteja sendo executado, enquanto que as técnicas dinâmicas são cobertas pela KA de Software Testing. 
Custo da Qualidade de Software 
A qualidade não é totalmente algo que podemos obter de forma gratuita. Para tanto, investimentos financeiros, treinamentos, softwares e outras iniciativas precisam ser realizadas em adição para a busca da qualidade de software como um todo. 
Segundo Bartié (2002), "Um dos maiores desafios a ser considerados é estabelecer um modelo de custos relacionados a implantação de um processo de garantia da qualidade de software." (BARTIÉ, 2002, p. 29) 
A Figura 5 mostra um modelo de custo de qualidade de software proposto por Bartié (2002): 
* 
Figura 5 - Modelo de Custo de Qualidade de Software.
* 
No modelo apresentado, Bartié (2002) propõe a criação de duas categorias separadas para os custos relacionados a conformidade e o custo da não-conformidade: 
1. Custo da Detecção de Defeitos: Pode-se aqui fazer claramente referências para o termo controle da qualidade, ou seja, o foco está exatamente no produto. As atividades aqui realizadas são orientadas ao produto desenvolvido, e estas incluem: 
Revisões de requisitos; 
Revisões de Modelagem; 
Revisões de Planos de Teste; 
Inspeções de código; 
Testes de Software. 
2 . Custo da Prevenção de Defeitos: Assim como detecção de defeitos está associada ao controle da qualidade, a prevenção de defeitos está associada a garantia da qualidade, ou seja, o foco está exatamente no processo. As atividades aqui realizadas são orientadas ao processo, e estas incluem:
* 
	Definição de Metodologias; 
	Treinamentos; 
	Ferramentas de apoio ao processo de desenvolvimento; 
	Definição de Políticas; 
	Procedimentos; 
	Padrões; 
	Especificações e convenções; 
	Planejamento do SQA; 
	Relatórios de Qualidade para melhoria de processo. 
* 
3. Custo da Não-Conformidade: Por outro lado, o custo da não-conformidade está relacionado às perdas que o projeto terá, não optando pela detecção e prevenção de defeitos: 
	Re-revisões; 
	Re-testes; 
	Correções de código-fonte e documentação muito constantes; 
	Reestruturação; 
	Redistribuição das versões do software; 
	Atrasos no cronograma; 
	Falhas na produção. 
Com isso, "O modelo apresentado deverá ser associado a todas as atividades de um processo de engenharia de software. Em todos os projetos a serem construídos ou modificados, todas as atividades deveriam ter uma política de alocação de custos semelhante ao modelo apresentado." (BARTIÉ, 2002, p. 29) 
* 
Qualidade de Software segundo a ISO 9126-1 
A ISO também apresenta as características da qualidade de software através da norma NBR ISO/IEC 9126-1. A antiga norma brasileira para as características da qualidade de software era a NBR 13.596. No entanto, a mesma se integrou a ISO, formando a NBR ISO/IEC 9126-1. Na Figura 6, são mostradas essas características juntamente com suas subcaracterísticas: 
Figura 6 - NBR ISO/IEC 9126-1 - Características da Qualidade de Software
* 
Funcionalidade (Satisfação das Necessidades): É a capacidade do produto de software de prover funcionalidades que satisfação as necessidades quando o software está em uso dentro das condições especificadas.
Confiabilidade (Imunidade a Falhas): É a capacidade do produto de software de manter um nível especificado de performance quando o software está em uso dentro das condições especificadas.
Usabilidade (Facilidade de Uso): É a capacidade do produto de software de ser entendido, aprendido, usado e atrativo quando o software está em uso dentro das condições especificadas. 
Eficiência (Rápido e "Enxuto"): É a capacidade do produto de software de prover performance apropriada, relativa ao conjunto de recursos usados quando o software está em uso dentro das condições especificadas.
Manutenibilidade (Facilidade de Manutenção): É a capacidade do produto de software de ser mudado. Modificações incluem correções, melhorias ou adaptações do software de mudar em um ambiente, e em requisitos e especificações funcionais. 
Portabilidade (Uso em outros Ambientes): É a capacidade do produto de software de ser transferido de um ambiente para outro. 
* 
Além da NBR ISO/IEC 9126-1, existem ainda outras normas da série 9126, as quais são:
 1. ISO/IEC 9126-2 - Métricas Externas: Podem ser aplicadas para um produto não executável durante os estágios de desenvolvimento. Medem a qualidade de produtos intermediários e predizem a qualidade do produto final. 
2. ISO/IEC 9126-3 - Métricas Internas: Utilizadas para medir a qualidade do software através do comportamento do sistema ou de parte dele. Só podem ser usadasdurante a fase de testes do ciclo de vida e durante a operação do sistema. 
3. ISO/IEC 9126-4 - Métricas da Qualidade do Uso: medem se o produto atende ou não as necessidades dos usuários, fazendo-os atingir seus objetivos com efetividade, produtividade, segurança e satisfação. Só podem ser usadas no ambiente real ou em uma aproximação do ambiente real. 
Observação:
NBR – Norma Brasileira 
ISO - Organização Internacional para Padronização
IEC - Comissão Eletrotécnica Internacional
* 
A Qualidade segundo o PMBOK do PMI 
O PMBOK (Project Management Body Of knowledge) do PMI (Project Management Institute), apresenta o gerenciamento da qualidade do projeto, conforme Figura 7 abaixo: 
Figura 7 - Gerenciamento da Qualidade do Projeto segundo o PMBOK do PMI. 
* 
De acordo com o PMBOK, "Os processos de gerenciamento da qualidade do projeto incluem todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles implementam o sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao fim, conforme adequado". (PMI, p.179) 
* 
Com isso os três principais processos são:
1. Planejamento da Qualidade: "Identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los." (PMI, 2004, p. 179) 
2. Garantia da Qualidade: "Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.".(PMI, 2004, p. 179) 
3. Controle da Qualidade: "Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório." (PMI, 2004, p. 179) 
Como se pode notar é evidente a semelhança entre os conceitos usados no PMBOK e os conceitos da própria ISO. Com isso, é possível ainda relacionar estes três processos do PMBOK com as definições de controle da qualidade e garantia da qualidade de software apresentados anteriormente.
 Métricas para Software
* 
O mercado exige, hoje, a gestão da qualidade, do conhecimento e sabe-se que não se pode gerenciar o que não se pode medir. No entanto, como medir valores como o conhecimento ou a qualidade?
Sabemos que todo processo de engenharia necessita de medições para entender melhor os modelos e avaliar a quantidade dos produtos construídos. No caso da engenharia de software – que não é fundamentada nas medidas quantitativas diretas, como voltagem, temperatura, velocidade – as suas medidas e métricas são na sua maioria indiretas.
Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos às características de uma entidade qualquer, definidos de acordo com regras bem definidas. Na ciência da computação, podemos medir os atributos, antes considerados incomensuráveis – ainda que alguns especialistas em software continuem a argumentar que o software é “incomensurável”.
* 
O que é métrica?
Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software, focalizando atributos específicos e mensuráveis dos artefatos da engenharia de software.
Métrica é uma medida quantitativa do grau que um sistema, componente ou processo possui de um dado atributo. Por exemplo, nos primeiros dezoito meses de atividade foram encontrados somente dois erros identificados por utilizadores.
As métricas são um bom meio para entender, monitorar, controlar, prever e testar o desenvolvimento de software e os projetos de manutenção.
Quem realiza?
Os engenheiros de software usam métricas de produto para ajudá-los a criar software da mais alta qualidade.
Haverá sempre um elemento qualitativo na criação de software. O problema é que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários critérios objetivos para ajudar a direcionar o projeto de dados, arquitetura, interfaces e componentes. Ao testar, necessitamos de orientação quantitativa que nos auxiliará na seleção de casos de teste e seus objetivos.
A métrica de produto proporciona uma base por meio da qual a análise, projeto, codificação e teste podem ser conduzidos mais objetivamente e avaliados de maneira mais quantitativa.
* 
Por que devemos medir?
	Para sabermos quanto cobrar;
	Para conseguirmos dar prazos;
	Para definirmos a equipe;
	Para definirmos complexidade;
	Para definirmos tamanho;
	Para medirmos risco.
Quais são as etapas envolvidas?
	O primeiro passo no processo de medição é definir as métricas apropriadas para o software.
	Em seguida, coletam-se os dados necessários para aplicar as métricas formuladas.
	Uma vez computadas, as métricas são analisadas com base em diretrizes preestabelecidas e dados do passado.
	Os resultados das análises são interpretados para obter informações sobre a qualidade do software.
	Os dados da interpretação levam à modificação dos requisitos e modelos de projeto, código-fonte ou casos de teste.
* 
Mas, como calcular uma métrica?
Em um determinado projeto o Gerente de Projetos gostaria de medir a satisfação do cliente. Durante as quatro entregas realizadas, um técnico averiguou com o cliente os problemas encontrados e identificou os casos de uso afetados, conforme tabela abaixo. Mas, como calcular uma métrica?
Tabela de Defeitos Por Entrega
Para garantir a qualidade do software foi definida uma métrica para identificar o percentual de casos de uso com defeito identificado pelo cliente.
% de CDU com defeitos = CDUcDefeito / CDUImplementado * 100
Onde:
	% de CDU com defeitos: métrica que representa o percentual de erros encontrados pelo cliente.
	CDUcDefeito: medida que representa o número de caso de uso com defeitos.
	CDUImplementado: medida que representa a quantidade de casos de uso implementados pelos desenvolvedores.
* 
* 
 Benefícios da Medição para o Gerenciamento de Projetos
	Redução das atividades que não agregam valor ao produto e que está sendo desenvolvido.
	Melhoria na gestão de recursos.
	Aumento na eficiência dos serviços prestados.
	Conhecimento da produtividade do projeto.
	Verificar se os recursos são adequados ao projeto.
	Avaliar o rendimento da codificação e avaliar se um produto está conforme aos critérios acordados com o cliente.
Benefícios da Medição para uma organização e negócio
	Identificar oportunidades de melhoria.
	Fomentar a visão da empresa.
	Aumentar o retorno de investimento.
	Melhorar a satisfação do cliente.
	Melhorar a posição da empresa no mercado.
	Melhorar a visibilidade sobre a situação dos projetos, baseada em dados objetivos
	Os processos que poderiam ajudar
* 
Qual é o artefato (produto)?
O produto, no caso, são as métricas computadas por meio de dados coletados dos requisitos e modelos de projeto, código-fonte e casos de teste.
Como garantir que o trabalho seja realizado corretamente?
Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo cada métrica de produto de maneira não ambígua. Defina apenas algumas métricas e, então, use-as para obter informações sobre a qualidade do artefato de software.
Embora as métricas de produto para software sejam imperfeitas, podem proporcionar uma maneira sistemática de avaliar a qualidade com base em um conjunto de regras claramente definidas.
Elas também proporcionam uma visão objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e corrigir problemas potenciais antes que se tomem defeitos catastróficos.
Avaliação dos atributos internos do produto
Veremos algumas medidas que podem ser usadas para avaliar a qualidade do produto enquanto ele está sendo projetado.
Essas medidas de atributos internos do produto fornecem uma indicaçãoem tempo real da eficácia dos modelos de requisitos, projeto e código, da eficácia dos casos de teste e da qualidade geral do software que será criado.
* 
Métricas de indicadores e de produto
É importante que você entenda as diferenças sutis entre os termos medida, medição e métrica, empregados com frequência.
MEDIDA
Sob o contexto de engenharia de software, medida proporciona uma indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum produto ou processo.
MEDIÇÃO
A medição é o ato de determinar uma medida.
MÉTRICA
Segundo o IEEE - Instituto de Engenheiros Eletricistas e Eletrônicos (Standard Glossary of Software Engineering Terminology), métrica busca obter uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo.
* 
Quando é coletado um único ponto de dado (por exemplo, o número de erros descobertos em um componente de software), foi estabelecida uma medida.
A medição ocorre como resultado da coleção de um ou mais pontos de dados (por exemplo, um conjunto de revisões de componentes e testes de unidade é investigado para coletar medidas do número de erros para cada um).
Uma métrica de software relaciona as medidas individuais de alguma maneira (por exemplo, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade).
Antes que um projeto possa ser planejado, deve-se:
	Estabelecer os objetivos e o escopo do projeto;
	Considerar soluções alternativas;
	Identificar as restrições administrativas e técnicas.
* 
Controle do software
É impossível controlar um software sem medições e feedback. Não se pode controlar o que não se pode medir e a extensão do controle depende da precisão da medição. Qualquer coisa que não se pode medir está fora de controle.
As medições e métricas ajudam a entender o processo usado para se desenvolver um produto de software e o próprio produto.
O produto e o processo em relação à medição
Produto é medido para avaliar a sua qualidade e processo é medido para melhorá-lo. Para efetivar a medição é necessário ter em mãos documentação de efeitos passados e dados estatísticos de quantificação de efeitos futuros.
A medição e a inferência estatística são usadas em várias áreas para projetar o desempenho futuro.
A medição pode levar a controvérsias e discussões como:
	Que métricas usar?
	Como os dados compilados devem ser usados?
	É justo usar medições para se comparar pessoas, processos e produtos?
* 
As estimativas mais importantes
A estimativa é uma das principais atividades do planejamento de software:
	 Esforço humano exigido
	 Duração do projeto
	 Custo
Métricas são frequentemente classificadas como métricas do processo ou métricas do produto, e são aplicadas durante o processo de desenvolvimento ou ao produto de software desenvolvido.
* 
Métricas do processo
As métricas do processo quantificam atributos do processo de desenvolvimento e do ambiente de desenvolvimento.
	Indicadores de processo permitem à organização de engenharia de software ter idéia da eficácia de um processo existente.
	Elas permitem aos gerentes e profissionais avaliarem o que funciona e o que não funciona.
	Métricas de processo são coletadas ao longo de todos os projetos e durante longos períodos.
Seu objetivo é fornecer indicadores que levem ao aperfeiçoamento do processo de software a longo prazo.
Métricas de recursos:
	 experiência do programador
	 custo de desenvolvimento
	 manutenção.
Métricas para o nível de experiência do pessoal:
	número de anos que uma equipe está usando uma linguagem de programação;
	número de anos que um programador está na organização.
Outros fatores relacionados ao desenvolvimento incluem:
	Técnicas de desenvolvimento;
	Auxílio para programação;
	Técnicas de supervisão etc.
* 
Métricas de Processo e aperfeiçoamento do processo de software
Medimos a eficácia de um processo de software indiretamente – originamos um conjunto de métricas, baseadas nas saídas que podem ser derivadas do processo.
As saídas incluem – medidas de erros descobertos antes da entrega do software, defeitos entregues aos usuários finais e por ele relatados, produtividade dos produtos de trabalho entregues, esforço humano despendido, tempo gasto, cumprimento de cronograma e outras medidas.
Algumas dessas medidas, tais como defeitos entregues aos usuários finais, só podem ser utilizadas para avaliar o processo, enquanto que outras, tais como erros descobertos antes da entrega do software, podem ser utilizados para avaliar tanto o processo quanto um projeto em específico.
As métricas de processo de software podem fornecer benefícios significativos, à medida que a organização trabalha para aperfeiçoar seu nível gerencial de maturidade de processo.
Todavia, essas métricas podem ser mal utilizadas, criando mais problemas do que conseguem resolver.
Use bom senso e sensibilidade empresarial quando interpretar dados de métricas.
Forneça regularmente realimentação aos indivíduos e equipes que coletam medidas e métricas.
* 
 Não use métricas para avaliar indivíduos.
 Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las.
 Nunca use métricas para ameaçar indivíduos ou equipes.
 Dados de métricas que indicam uma área problemática não devem ser considerados “negativos”. Esses dados são meramente um indicador para melhoria do processo.
 Não fique obcecado com uma única métrica em detrimento de outras métricas importantes.
À medida que uma organização sente-se mais confortável, coletando e usando métricas de processo, a derivação de indicadores simples dá lugar a uma abordagem mais rigorosa, chamada melhoria estatística de processo de software – statistical software process improvement (SSPI).
A SSPI usa a análise de falhas de software para coletar informação sobre todos os erros e defeitos encontrados à medida em que uma aplicação, sistema ou produto é desenvolvido e usado. 
* 
Erro – falha num produto de trabalho de engenharia de software, ou resultado a ser produzido, que é encontrado por engenheiros de software antes do software ser entregue ao usuário final.
Defeito – falha encontrada depois da entrega ao usuário final. A análise de falhas funciona da seguinte maneira:
Todos os erros e defeitos são categorizados por origem (por exemplo: falha na especificação, falha de lógica, não atendimento à padrões)
O custo para corrigir cada erro e defeito é registrado.
A quantidade de erros e defeitos de cada categoria é contada e ordenada de forma decrescente.
O custo total de erros e defeitos de cada categoria é calculado.
Os dados resultantes são analisados, para descobrir as categorias que produzem um maior custo para a organização.
São desenvolvidos planos para modificar o processo, com o objetivo de eliminar (ou reduzir a frequência das) classes de erros e defeitos que são mais dispendiosas.
* 
Métricas de Projeto
	 Indicadores de Projeto permitem ao gerente de projeto de software:
	Avaliar o status de um projeto em andamento;
	Acompanhar riscos potenciais;
	Descobrir áreas-problemas antes que elas se tornem críticas;
	Ajustar o fluxo de trabalho ou tarefas;
	Avaliar a capacidade da equipe de projeto e controlar a qualidade dos produtos do trabalho de software.
	Em alguns casos, as mesmas métricas de software podem ser usadas para determinar indicadores de projeto e de processo de software.
	Métricas de processo de software são usadas com finalidade estratégica.
	Medidas de projeto de software são táticas – métricas de projeto e indicadores derivados delas são usados por um gerente de projeto e por uma equipe de software, para adaptar o fluxo de trabalho e as atividades técnicas do projeto.
A primeira aplicação das métricas de projeto, na maioria dos projetos de software, ocorre durante as estimativas. Métricas coletadas de projetos anteriores são usadas como base, a partir da qual as estimativas de esforço e de tempo são feitas para o trabalho atual de software.
À medida que o projetoprossegue, medidas de esforço e de tempo despendidos são comparadas com as estimativas originais – o gerente de projeto usa esses dados para monitorar e controlar o progresso.
* 
À medida que o trabalho técnico se inicia, outras métricas de projeto começam a ter importância, como:
Taxa de produção – representada em termos de páginas de documentação, horas de revisão, pontos-por-função e linhas de código fonte entregue.
	Primeiro essas métricas são usadas para minimizar o cronograma de desenvolvimento, fazendo os ajustes necessários para evitar atrasos e problemas, e riscos em potencial.
	Métricas de projeto são usadas para avaliar a qualidade do produto durante sua evolução e, quando necessário modificar a abordagem técnica para aperfeiçoar a qualidade.
À medida que a qualidade é aperfeiçoada, os defeitos são minimizados, e, à medida que a contagem de defeitos decresce, a quantidade de retrabalho durante o projeto é também reduzida.
Isto leva à diminuição do custo total do projeto.
* 
Métricas do produto
São medidas do produto de software. Podem não revelar nada sobre como o software foi desenvolvido.
Incluem:
O tamanho do produto (linhas de código);
A complexidade da estrutura lógica (recursão – for, while, repeat, fluxo de controle – ordem das instruções do programa – e profundidade de laços aninhados);
A complexidade da estrutura de dados;
Funções (tais como tipo de software: comercial, científico etc.).
Nesse caso, é importante que você conheça um exemplo: O número de defeitos descobertos durante o teste formal depende do produto (número de segmentos de código que estão errados) e do processo usado na fase de teste (a extensão do teste).
* 
Métricas diretas e métricas indiretas
Medidas Diretas do Processo de Software:
	 Custo e esforço aplicados.
Medidas Diretas do Produto:
	Número de linhas de código produzidas (KLOC – Kilo Lines of Code ou simplesmente “mil linhas de código”);
	Velocidade de execução;
	Tamanho de memória;
	Número de defeitos registrados em um tempo qualquer.
Medidas Indiretas do Produto:
	Qualidade;
	Funcionalidade;
	Complexidade;
	Eficiência;
	Confiabilidade;
	Manutenibilidade. 
* 
Métricas orientadas ao tamanho
Linhas de Código (KLOC): uma linha de código é qualquer linha do texto de um programa, exceto comentários e linhas em branco, sem levar em conta o número de comandos ou fragmentos de comandos em uma linha. Estão incluídas na definição de linhas de código todas as linhas que contém cabeçalho do programa, declarações e comandos executáveis.
Vantagens:
	É fácil de calcular;
	É o fator mais importante para muitos modelos de estimativa.
Desvantagens:
	Dependente da linguagem de programação;
Penalizam programas bem estruturados, porém mais curtos.
* 
Se uma organização de software mantém registros simples, uma tabela de medidas orientadas ao tamanho, pode ser criada.
A tabela lista cada projeto de software desenvolvido e as correspondentes medidas daqueles projetos.
Deve-se notar que o esforço e o custo registrados na tabela referem-se a todas as atividades de engenharia de software (análise, projeto, codificação e teste), não apenas à codificação.
Para o desenvolvimento de métricas foi escolhida uma medida base da tabela anterior – LOC (Linhas de Código-Fonte)
A partir dos dados “rudimentares”, contidos na tabela anterior, um conjunto de métricas simples orientadas a tamanho pode ser desenvolvido para cada projeto.
* 
 Defeitos por KLOC;
 R$ por LOC (estimado…);
 Páginas de documentação por KLOC;
Adicionalmente, outras métricas interessantes podem ser calculadas:
 Erros por pessoa-mês;
 LOC por pessoa-mês;
 $ por página de documentação (estimado…);
Métricas orientadas a tamanho não são universalmente aceitas como o melhor modo de medir o processo de desenvolvimento de software.
A maior parte da controvérsia gira em torno do uso de linhas de código fonte como medidas-chave.
Adeptos da medida de linhas de código fonte alegam que LOC é um artefato de todos os projetos de desenvolvimento de software, que pode ser facilmente contado e que muitos modelos de estimativa usam tal artefato.
* 
Por outro lado, os oponentes argumentam que as medidas de LOC:
 São dependentes da linguagem de programação.
 Penalizam programas curtos, mas bem projetados.
 Não podem acomodar facilmente linguagens não procedimentais e que seu uso na estimativa requer um nível de detalhes que pode ser difícil de alcançar, ou seja, significa que o planejador deve estimar o LOC a ser produzido, muito antes que a análise e o projeto tenham sido completados.
* 
Métricas orientadas à função
	São medidas indiretas do software;
	Concentram-se na funcionalidade ou utilidade do programa;
	Função: coleção de comandos executáveis que realizam uma determinada tarefa;
Métricas de software orientadas a função usam uma medida da funcionalidade entregue pela aplicação como valor da normalização.
Como funcionalidade não pode ser medida diretamente, deve ser originada indiretamente usando outras medidas diretas.
Métricas orientadas a função foram inicialmente propostas por Albrecht em 1979 que sugeriu uma medida chamada pontos-por-função.
APF (Análise por pontos de função) - Pontos-por-função – derivadas a partir da contagem (direta) do domínio da informação do software e avaliação da complexidade do software.
São calculados completando a tabela apresentada a seguir.
Cinco características do domínio da informação são determinadas e as contagens são registradas nos lugares próprios da tabela.
* 
* 
Quantidades de entradas do usuário – cada entrada do usuário, que fornece dados distintos orientados à aplicação do software, é contada. Entradas devem ser distinguidas de consultas, que são contadas separadamente.
Quantidade de saídas do usuário – cada saída do usuário, que fornece informação orientada à aplicação para o usuário, é contada. Nesse contexto, saída refere-se a relatórios, telas, mensagens de erro, etc. Itens de dados individuais dentro de um relatório não são contados separadamente.
Novas consultas do usuário – uma consulta é definida como uma entrada on- line, que resulta na geração de alguma resposta imediata do software sob forma de saída on-line. Cada consulta distinta é contada.
Quantidade de arquivos – cada arquivo lógico (isto é, grupo de dados lógicos que pode ser parte de uma base de dados maior ou um arquivo separado) é contado.
Quantidade de interfaces externas – todas as interfaces que são usadas para transmitir informação a outro sistema, são contadas.
Uma vez coletados esses dados, um valor de complexidade é associado com cada contagem.
Organizações que usam os métodos de pontos por função desenvolvem critérios para determinar se uma instância particular é simples, média ou complexa. No entanto, esta determinação é um tanto subjetiva.
* 
Para determinar os pontos por função é usada a seguinte relação:
FP = contagem total X [0,65 + 0,01 X ? (Fi)]
Os Fi (i=1 a 14) são valores de ajuste de complexidade, baseados nas respostas às seguintes perguntas:
* 
O sistema requer salvamento (backup) e recuperação (recovery)
Comunicações de dados são necessárias?
Há funções de processamento distribuídas?
O desempenho é crítico?
O sistema vai ser executado em um ambiente operacional existente, intensivamente utilizado?
O sistema requer entrada de dados on-line?
A entrada de dados on-line, exige que a transação de entrada seja construída através de várias telas ou operações?
Os arquivos mestre são atualizados on-line?
As entradas, saídas, arquivos ou consultas são complexas?
O processamento interno é complexo?
O código é projetado para se reusado?
A conversão e a instalação estão incluídas?
O sistema está projetado para instalações múltiplas em diferentes organizações?
A aplicação está projetada para facilitar modificações e para facilidade de uso pelo usuário?
* 
Cada uma destas questões é respondida usando uma escala que varia entre:
0 – não importante e não aplicável
5 – absolutamente essencial
Os valores na equação e os fatores de pesoda tabela, foram determinados empiricamente.
Uma vez calculados, os pontos por função são usados de modo análogo à LOC, como forma de normalizar medidas de produtividade, qualidade e outros atributos de software. Tais como:
	Erros por FP
	Defeitos por FP
	$ por FP
	Páginas de documentação por FP
	FP por mês.
* 
Atributos de métricas eficazes de software
Centenas de métricas já foram propostas para software, algumas demandam medições muito complexas, outras são tão esotéricas que poucos profissionais do mundo real têm qualquer esperança de entendê-las, e outras ainda violam as noções intuitivas básicas do que é realmente um software de alta qualidade.
	Planejamento
	Análise
	Design
	Programação
Princípios de medição
	Formulação: criação de medidas e métricas apropriadas para a representação do software.
	Coleção: no caso, refere-se ao mecanismo usado para acumular dados necessários para criar as métricas formuladas.
	Análise: é a computação das métricas e a aplicação de ferramentas matemáticas.
	Interpretação: relacionada à avaliação de métricas que resultam em informações sobre a qualidade da representação.
	Feedback: são recomendações derivadas da interpretação de métricas de produto transmitidas para a equipe de software.
* 
A seguir estão elencados os atributos que devem ser considerados pelas métricas – segundo Pressman (Engenharia de Software):
	Simples e computáveis – Deverá ser relativamente fácil aprender a derivar a métrica, e sua computação não deve demandar esforço ou tempo fora do normal.
	Empiricamente e intuitivamente persuasiva – A métrica deverá satisfazer as ideias do engenheiro de software.
	Consistente e objetiva – A métrica deverá sempre produzir resultados que não sejam ambíguos. Um terceiro independente deverá ser capaz de derivar o mesmo valor da métrica usando as mesmas Informações sobre o software.
	Consistente no seu uso das unidades e dimensões – A computação matemática da métrica deverá usar medidas que não resultem em combinações bizarras de unidades. Por exemplo, multiplicar número de pessoas nas equipes de projeto pelas variáveis da linguagem de programação no programa resulta em uma mistura duvidosa de unidades que não é claramente convincente.
	Independente da linguagem de programação – As métricas deverão ser baseadas no modelo de requisitos, modelo de projeto ou na própria estrutura do programa. Elas deverão ser independentes dos caprichos da sintaxe ou semânticas das linguagens de programação.
	Um mecanismo efetivo para feedback de alta qualidade – A métrica deverá fornecer informações que podem levar a um produto final de melhor qualidade. 
* 
Cinco métricas para avaliar a qualidade de seus softwares
	Alcance: deve ser capaz de lidar com várias tecnologias. A maioria dos aplicativos modernos contém vários idiomas e sistemas que são ligados entre si de forma complexa.
2. Profundidade: deve ser capaz de gerar mapas completos e detalhados da arquitetura do aplicativo do Graphical User Interface (GUI), ferramenta de captura, processamento e análise de imagem, para o banco de dados. Sem essa detalhada arquitetura, seria impossível obter contextualização da aplicação.
3. Tornar o conhecimento explícito de engenharia de software: deve ser capaz de verificar a aplicação inteira contra centenas de padrões de implementação que codificam as melhores práticas de engenharia.
4. Métricas acionáveis: as métricas de qualidade não devem apenas informar, mas também orientar sobre como realizar a melhoria da qualidade do software, mostrando o que fazer primeiro, como fazê-lo, próximos passos etc.
5. Automatização: finalmente, deve ser capaz de realizar todos os pontos descritos acima de forma automatizada. Nenhum profissional ou equipe pode fazer essa tarefa, muito menos fazê-la em um curto espaço de tempo.
* 
Em um processo de desenvolvimento de software temos vários processos, como: gestão de requisitos, gestão de riscos, testes, gestão da qualidade.
No processo de Gestão de Requisitos, podemos coletar métricas como:
	Requisitos incluídos: indica a proporção de requisitos de um projeto que são adicionados aos requisitos estabelecidos inicialmente.
	Requisitos cancelados: indica a proporção de requisitos de um projeto que são anulados.
	Requisitos aprovados: indica a proporção de requisitos de um projeto que são aprovados pelo cliente antes de finalizar o desenho.
	Requisitos alterados: indica a proporção de requisitos de um projeto que se modificam
	Estabilidade de requisitos: mostra um valor de estabilidade dos requisitos no momento da medição, a partir do cálculo de fatores que influenciam na instabilidade.
No processo de Gestão de Riscos, podemos coletar métricas como o Nível de Riscos, que é uma métrica que indica o nível de risco que assume o projeto. Na gestão de riscos podemos determinar o nível de risco para cada fase do projeto e também para  obter uma classificação global do nível de risco do projeto.
* 
No processo de Testes, podemos coletar métricas como:
	Volume de erros por etapa: A estabilidade mostra um nível de confiança do software testado que serve como critério para a validação de um módulo, processo ou sistema. Conforme as correções dos erros, a taxa de defeitos por caso de teste vai diminuindo. Uma estabilidade elevada supõe um alto nível de qualidade do software.
	Gestão de Incidências: Mostra o grau de resolução das incidências detectadas por parte da equipe de projeto. Um valor baixo na Gestão de Incidências supõe um nível alto de incidências não resolvidas e, por tanto erros no software.
No processo de Gestão de Configuração, podemos coletar métricas como:
	Evolução do Software: indica a evolução do software para cada fase do projeto, baseado no volume de modificações que se produzem no software. Esta métrica indica como se evolui o software gerado comparado com as fases do projeto.
No processo de Gestão da Qualidade, podemos coletar métricas como:
	Estabilidade do Software: indica o número de erros detectados. Determina a qualidade dos sistemas em produção, baseado no número de erros detectados no período.
	Gestão de Não Conformidades: indica o número de não conformidades gerenciadas, não gerenciadas, moderadas, graves e leves.
* 
Exemplo: 
 Quatro equipes de software estão trabalhando em um grande projeto de software. Cada equipe precisa conduzir revisões de projeto, mas pode selecionar o tipo de revisão que irá usar. Pelo exame da métrica, erros encontrados por pessoa-hora empregada, o gerente de projeto nota que duas equipes que estão usando métodos de revisão mais formais, exibem um valor para os erros encontrados por pessoa-hora empregada, que é 40% maior do que o valor das outras equipes.
 Considerando todos os outros parâmetros iguais, isso, para o gerente de projeto, é um indicador de que os métodos de revisões formais podem fornecer um retorno maior do investimento em tempo que outra abordagem de revisão menos formal. Este pode, então, decidir sugerir que todas as equipes usem a abordagem menos formal.
 A métrica pode fornecer compreensão ao gerente de um projeto. E compreensão leva a uma tomada de decisão mais precisa.
 A medição é comum no mundo da engenharia. Medimos consumo de energia, peso, dimensões físicas, temperatura, voltagem, relação entre sinal e ruído…..
 Na engenharia de software a medição é muito menos comum – temos dificuldade em concordar quanto ao que medir e dificuldade em avaliar as medidas que são coletadas.
 Métricas devem ser coletadas de modo que os indicadores de processo e de produto possam ser determinados.