1 /20

MÉTRICAS E QUALIDADE DE SOFTWAREFirmino dos Santos Filho,

Brasilfirminosantos@gmail.com

AbstractPelo fato da qualidade não possuir uma única dimensão, atributo, ou característica, anoção de qualidade normalmente é capturada em um modelo que descreve ascaracterísticas compostas e as relações entre elas. Para definir um modelo de qualidade,deve haver uma clara distinção entre atributos internos e externos. Qualidade pode sermedida de diversas formas — métricas e critérios devem ser estabelecidos parasatisfazer as necessidades do projeto de software. Este artigo discute como aplicarmétricas de software para melhorar a qualidade e a confiabilidade de produtos desoftware, baseado nas melhores práticas de desenvolvimento de software, práticascomercialmente aprovadas.

Índice

Abstract.....................................................................................................................................1

1. Definições...........................................................................................................................2

2. Melhores Práticas de Software ........................................................................................3

3. Erros, Falhas e Avarias ....................................................................................................6

3.1. Análise da Terminologia sob a ótica da língua Portuguesa.......................................6

3.2. Erros, Falhas(Faults) e Avarias(Failures)...................................................................7

4. Confiabilidade como um Atributo da Qualidade...........................................................8

5. Melhoria do Processo de software com CMM ...............................................................9

6. Métricas de Software para Qualidade. .........................................................................10

6.1. Métricas de Qualidade para Requisitos de Software...............................................11

6.1.1. Use Case (Casos de Uso) .........................................................................................11

6.1.2. Métricas para os Requisitos....................................................................................12

6.2. Qualidade do Código e do Projeto, Métricas de Confiabilidade.............................12

6.2.1. Métricas de Código..................................................................................................13

6.2.1.1. Tamanho...............................................................................................................13

6.2.1.1.1. Número de classes ................................................................................................13

6.2.1.1.2. Número de linhas executáveis.............................................................................14

6.2.1.2. Volatilidade ..........................................................................................................14

6.2.1.2.1. Breakage ...............................................................................................................14

6.2.1.3. Complexidade.......................................................................................................14

6.2.1.3.1. Tamanho dos métodos .........................................................................................14

6.2.1.3.2. Número de declarações executáveis por método...............................................14

6.2.1.3.3. Número de métodos por classe ...........................................................................14

2 /20

6.2.1.3.4. Número de if-then-else, while, for, try and switch aninhados..........................14

6.2.1.3.5. Número de Caminhos Estáticos..........................................................................15

6.2.1.3.6. Resposta de uma Classe (RFC)...........................................................................15

6.2.1.3.7. Complexidade Ciclomática de métodos .............................................................15

6.2.1.3.8. Profundidade da estrutura de herança..............................................................16

6.2.1.4. Acoplamento.........................................................................................................16

6.2.1.4.1. Número de filhos ..................................................................................................16

6.2.1.4.2. Acoplamento entre objetos (fan-out da classe)..................................................16

6.2.1.5. Coesão ...................................................................................................................17

6.2.1.5.1. Número de filhos ..................................................................................................17

6.2.1.5.2. Falta de coesão em Métodos (LCOM)................................................................17

6.2.1.6. Legibilidade ..........................................................................................................17

6.2.1.6.1. Número de linhas de comentário por número de declarações ou instruções doprograma 17

6.2.1.6.2. Razão Comentários / Código ..............................................................................17

6.3. Qualidade do teste e Métricas de Confiabilidade....................................................17

6.3.1. Casos de Teste..........................................................................................................18

6.3.2. Propósito dos Casos de Teste..................................................................................18

6.3.3. Métricas de Teste.....................................................................................................19

7. Referencias ......................................................................................................................19

1. DefiniçõesNa norma ISO 9126, qualidade de software é definido como: "A totalidade de recursose características de um produto de software que afeta sua habilidade para satisfazer asnecessidades definidas ou implícitas". Decorre que a qualidade é decomposta em seisfatores:

• Funcionalidade• Confiabilidade• Eficiência• Facilidade de Uso• Facilidade de Manutenção• Portabilidade

IEEE 610.12-1990 define confiabilidade como “A habilidade de um sistema oucomponente executar as funções exigidas nas condições declaradas por um período detempo especificado.”

IEEE 982.1-1988 define Gerenciamento de Confiabilidade de Software como “Oprocesso de otimização da confiabilidade de software por um programa que enfatizaprevenção de erro de software, detecção e remoção de falhas, e o uso de medidas paramaximizar a confiabilidade levando em conta fatores restritivos do projeto tais comorecursos, cronograma e desempenho.”

3 /20

Isto posto, a confiabilidade do produto de software entregue é relacionado a qualidadede todos os processos e produtos do desenvolvimento de software; a documentação dosrequisitos, o processo de desenvolvimento, o código, planos de teste, e o teste dosoftware.

A presença de um bem definido e bem administrado processo é um discriminadorfundamental entre hiper-produtivos projetos e projetos malsucedidos. Para melhorar aqualidade do software, o processo de desenvolvimento de software deve sercompreendido, definido, medido, e continuamente melhorado.A definição de processo de desenvolvimento de software definida pela SEI: "Umprocesso de software é uma série de atividades, métodos, práticas e transformações queas pessoas usam para desenvolver e manter produtos de software.”

Em sistemas de software de grande porte, a obtenção de qualidades tais comodesempenho, segurança, suscetibilidade à modificações, funcionalidade, confiabilidade,eficiência, facilidade de uso, facilidade de manutenção e portabilidade não só édependente de práticas de a nível de código mas também de todo o processo dedesenvolvimento de software.

2. Melhores Práticas de SoftwareUm processo de desenvolvimento de software é uma série de atividades necessárias paratransformar os requisitos do usuário em um sistema de software. Um processo efetivoprovê diretrizes para o desenvolvimento eficiente de software com qualidade. Umprocesso bem definido permitirá resolver o paradoxo de software, maior qualidade comrápida disponibilização para o mercado. O processo adequado captura e apresenta asmelhores práticas que o estado atual da arte permite:• Desenvolvimento Iterativo

! Desenvolvimento Iterativo é a técnica que é usada para entregar a funcionalidade deum sistema em uma série sucessiva de liberações de modo a realizar crescentemente osistema desejado. Os riscos mais críticos devem ser focados nas fases iniciais do projetode modo a aumentar previsibilidade a evitar descarte e retrabalho [1].

• Gerenciamento de Requisitos (Requirements Management, RM)! RM é definido como uma abordagem sistemática para extrair, organizar e documentar

os requisitos do sistema e um processo que estabelece e mantém um acordo entre ocliente e os projetistas, de modo a controlar as mudanças de requisitos do sistema.

! O gerenciamento de requisitos envolve a tradução dos pedidos dos clientes em umasérie de necessidades fundamentais dos clientes e características de sistema. Estes porsua vez são detalhados em especificações funcionais e não funcionais. Estes requisitosmais específicos são os requisitos de software [2].

! Uma valiosa ferramenta pode ser usada para detalhar requisitos funcionais: Use Case(Casos de Uso). Um Caso de Uso descreve uma sucessão de ações, executada pelosistema, que resulta um valor para o usuário. Casos de Uso servem como umarepresentação UML para os requisitos do sistema.

! Quando é dito que um processo é dirigido a Casos de Uso (Use-case driven) significaque o processo de desenvolvimento segue um fluxo – segue uma série de fluxos detrabalho que derivam dos casos de uso. Casos de Uso são especificados, casos de usosão projetados, e no final casos de uso são a fonte a partir do qual o projetista de testeconstrói os casos de teste (test cases).

• Arquiteturas baseadas em componentes! Um componente pode ser definido como uma parte substituível de um sistema que

cumpre uma função clara no contexto de uma arquitetura bem definida. Um

4 /20

componente adapta-se e provê a realização física de uma série de interfaces ecomportamentos.

! Arquitetura baseada em componentes é a base para a reutilização, reutilização decomponentes e reutilização de arquiteturas; permite o uso de componentescomercialmente disponíveis e a expansão do software existente incrementalmente [3].

• Foco na Arquitetura! Extensas análises dos requisitos, do projeto, implementação e atividades de avaliação

são executadas antes da implementação completa esteja em foco. O foco inicial doprojeto de implementar e testar a arquitetura deve preceder o desenvolvimento em largaescala e teste de todos os componentes.

! Em sistemas de software de grande porte, a obtenção dos requisitos de qualidade não sódepende de práticas de a nível de código, mas também de toda a arquitetura dosoftware. Assim, está entre os principais interesses do desenvolvedor, determinar, naocasião em que a arquitetura de sistema de software for especificada, se o sistema teráas qualidades desejadas.

• Modelagem Visual (UML) e Métodos Orientados a Objetos! UML (Unified Modeling Language) é a terceira geração de linguagem de modelos

visuais que define as construções e relações de sistemas complexos.! A UML é a linguagem sucessora da análise orientada a objetos e métodos de projeto.! A UML é uma linguagem padronizada para modelagem de software – uma linguagem

que permite a visualização, especificação, construção e documentação dos artefatos desistemas intensivos de software.

! A linguagem UML permite a comunicação clara e precisa entre os diversos membros dotime de desenvolvimento. A linguagem UML permite ao desenvolvedor a visualizaçãodo produto de seu trabalho em diagramas padronizados. Provendo anotaçõesformalizadas para capturar e visualizar as abstrações de software, o principal impacto datecnologia orientada a objetos está na redução do tamanho total do que precisa serdesenvolvido.

• Trabalho de equipe! Um projeto de software bem sucedido sucesso precisa ter equilíbrio entre um sólido

talento e pessoas altamente qualificadas nas posições chaves. Trabalho de equipe émuito mais importante que a soma dos indivíduos.

! Todas as pessoas em organizações de desenvolvimento de software têm que ter umameta comum: entregar um produto de alta qualidade no prazo e dentro do orçamentoprevisto.

• Ferramentas de apoio! As ferramentas e ambiente usados no processo de desenvolvimento de software têm um

efeito linear na produtividade do processo. Durante cada ciclo de desenvolvimento desoftware as ferramentas provêem apoio de automatização crucial, de modo a permitir odesenvolvimento dos artefatos de engenharia de software através de mudanças graduaise controladas. Ferramentas e ambientes de desenvolvimento devem ser vistos comocomponentes primário para a automatização do processo e melhoria continua.

• Verificação continua da qualidade! Existe uma propriedade famosa no desenvolvimento de software: é muito mais barato

corrigir defeitos durante o desenvolvimento que os corrigir depois do desenvolvimento.! Nos ciclos de vida iniciais as métricas devem ter uma forte contribuição para a

avaliação da qualidade, quando esforços para melhorar a qualidade de software sãomuito mais efetivos. A coleta das métricas deve ser automatizada e não intrusiva, ouseja não deve interferir com as atividades dos desenvolvedores.

! A avaliação do software deve ser uma coleta de tópicos não usuais (geralmentechamado de métricas de software), que possui uma ampla gama de modelos parapredizer a qualidade do projeto de software.

5 /20

! Deve-se utilizar as métricas e indicadores de software para medir o progresso e aqualidade de cada artefato produzido durante o processo de desenvolvimento desoftware.

! Você não pode desenvolver um produto de software com qualidade ou melhorar oprocesso sem ter como medir (medir no sentido de avaliar sua qualidade e estágio dedesenvolvimento) este software. As medições obtidas do software devem ser analisadasde modo a identificar pontos fracos do processo definido e prover uma forma de seobter uma melhoria do processo utilizado.

! Métricas de software são usadas afim de monitorar e avaliar os seguintes aspectos doprojeto:" Progresso em termos de tamanho e complexidade." Estabilidade em termos de taxa de mudança na implementação, tamanho ou

complexidade." Modularidade em termos da extensão da mudança." Qualidade em termos do número e tipo de erros." Maturidade em termos da freqüência de erros." Recursos em termos de recursos despendidos contra os planejados.

! A visão matemática das métricas pode ser achada nas referências [5] e [7].• Gerenciamento da configuração de software (SCM, Software configuration

management)! SCM é uma disciplina da engenharia de software que inclui as ferramentas e técnicas

(processos ou metodologia) utilizadas pelas empresas para gerenciar as mudanças deseus ativos de software.

! IEEE 828-1998 diz sobre SCM:" SCM constitui uma boa prática de engenharia para todos os projetos de software,

independentemente da fase do desenvolvimento, ou se for protótipo rápido, oumanutenção em andamento. Aumenta a confiança e qualidade do software pelasseguintes razões:# Prove estrutura para identificação e controle da documentação, código,

interfaces, e bancos de dados para apoiar todas as fases do ciclo de vida.# Apoiando uma metodologia escolhida para desenvolvimento / manutenção que

se ajuste aos requisitos, normas, políticas, organização e filosofia degerenciamento.

# Produz gerenciamento e informação de produto relativo ao estado da versãodo produto de software utilizado como referencia, controle de mudanças,testes, liberações, auditorias, etc.

• Padrões para Codificação (Coding Standards)! A eliminação de todos os erros está, pelo menos em ambientes industriais atuais, bem

além da capacidade tecnológica de software disponível. Não obstante a experiênciasugere que a densidade de erros de códigos liberados possam ser reduzidos pela metadeatravés da utilização de processos internos de verificação apoiados por ferramentasanalíticas adequadas. Isto não requer mudanças de paradigmas ou idiomas. É necessárioa determinação na adoção de técnicas comprovadas.

! De todas as formas de controle de qualidade de software, a inspeção de código é semdúvida a mais efetiva. Quando apoiado por boas ferramentas, o custo unitário típico deidentificação de um erro estático é até duas vezes menor que o custo da identificaçãoatravés de métodos dinâmicos. Para realizar o trabalho de inspeção você precisa de umpadrão de codificação (coding standard) definindo requisitos que o código a serinspecionado deve satisfazer. [12]

! Um padrão de codificação são regras que governam o uso de uma linguagem deprogramação. Complementa o padrão da linguagem definindo características de usoaceitável e o inaceitável. Características de uso inaceitável conduzem ao erro ou a máinterpretação. Características de uso aceitável evitam situações dúbias ou problemáticas.Isto não garante que seu código esteja livre de erros, porque sempre se pode alcançar

6 /20

uma implementação imaculada da coisa errada. Um padrão de codificação ajuda a quevocê:" evite uso de características indefinidas," evite uso de características não especificadas," evite uso de características definidas pela implementação," se proteja contra erros de compilação," se proteja contra erros comuns de programação," limite a complexidade de seu programa (Veja item 6)," estabeleça uma base objetiva para revisão de seu código.

! Evitando usos indefinidos, não especificados e definidos pela implementação,efetivamente você limita o uso da linguagem de programação a um subconjunto que éinequivocamente definido. Isto evita os pontos fracos linguagem. Este processo não é aprova de falhas mas o ajudará a prevenir erros. Se você examinar relatórios de errosgerados pelo compilador, não só o seu próprio, mas também de outros desenvolvedores,para a mesma linguagem, você obterá uma idéia razoável dos tipos de coisas que podemser mal implementadas. Você pode evitar essas características da linguagem ou pelomenos sujeitar seu o uso a uma clara e razoável justificação.

• Teste Automatizado! ”Teste Automatizado” está automatizando o processo manual de teste ainda hoje em

uso.! O propósito real das ferramentas de teste automatizadas são automatizar os testes de

regressão. Isto significa que você tem que ter ou tem que desenvolver casos de testedetalhados que sejam reproduzíveis, e este conjunto de testes sejam executados todavez que haja uma mudança no programa de modo a assegurar que esta mudança nãoproduza conseqüências não intencionais.

As melhores práticas são um conjunto de técnicas aprovadas comercialmente para odesenvolvimento de software que, quando usadas de modo combinado, golpeiem ascausas básicas dos problemas de desenvolvimento de software.

3. Erros, Falhas e Avarias

3.1. Análise da Terminologia sob a ótica da língua PortuguesaA escolha de uma terminologia que exprima na nossa língua conceitos originariamentedefinidos em Inglês é uma tarefa delicada e difícil.Vamos analisar a opção pela trilogia falha => erro => avaria para designarrespectivamente "fault", “error" e "failure". Sendo a tradução de "error" por erroperfeitamente pacifica, toda a polemica se resume a atribuição de termos Portuguesespara "fault" e "failure". A palavra “falha” é talvez a mais adequada para ambos oscasos, dado não haver na língua portuguesa termos que traduzam com clareza adiferenciação semântica que existe entre os termos "fault" e "failure" assumidos nosentido técnico. De fato, existem em Português diversos termos com significadosemelhante tais como "falta", "avaria", "defeito", sendo possível encontrar argumentospara eleger qualquer destes termos como a melhor tradução quer de "fault" quer de"failure".O termo "falha" é normalmente utilizado no sentido de “causa de um evento”. Logo"falha" é o termo português mais adequado para "fault".Um outro argumento a favor da tradução de "fault" por "falha", prende-se com o fato dena área científica o conceito vinculado pelo termo "fault" ser usado com maisfreqüência e num conjunto de expressões mais diversificado do que o termo "failure".Assim, havendo uma interdependência na tradução das duas palavras anglo-saxonicas,

7 /20

deve-se reservar a melhor tradução para o termo utilizado com mais freqüência ou seja,para "fault" .Por outro lado, parece-nos que "avaria" traduz em bom português o termo anglo-saxonico "failure", ainda que este termo esteja associado a perturbações físicas de umsistema e, normalmente, de caracter permanente.

3.2. Erros, Falhas(Faults) e Avarias(Failures)Nenhum desenvolvedor de software produz um software perfeito na primeiraimplementação. Assim, é importante o desenvolvedor medir aspectos de qualidade dosoftware. A terminologia utilizada na investigação e análise deve ser precisa, enquantonos permitindo entender as causas como também os efeitos da avaliação da qualidade eesforços de aperfeiçoamento.De acordo com a norma IEEE std 729 define-se a seguinte terminologia:• Uma falha (fault) acontece quando um erro humano resultar em um resultado

indesejado em algum produto de software. Quer dizer, a falha é a codificação doerro humano. Por exemplo, um desenvolvedor poderia entender mal um requisito dainterface de usuário, e como conseqüência criar um projeto que inclua o engano. Afalha de projeto também pode resultar num código incorreto, como tambéminstruções incorretas no manual de usuário. Assim, um único erro pode resultar emuma ou mais falhas, e uma falha pode residir em quaisquer dos produtos dodesenvolvimento.

• Por outro lado, uma avaria (failure) é o desvio de um sistema de seucomportamento exigido. Avarias podem ser descobertas antes ou depois da entregado sistema, como também elas podem acontecer durante os testes ou durante aoperação do sistema. É importante notar que estamos comparando o comportamentoreal do sistema com o comportamento exigido, em lugar de comparar com ocomportamento especificado, porque falhas na especificação dos requisitos podemresultar em avarias também.

De certo modo, pode-se pensar em falhas e avarias como visões interna e externa dosistema. Falhas representam problemas que o desenvolvedor vê, enquanto avarias sãoproblemas que o usuário vê. Nem toda falha corresponde a uma avaria, porque ascondições em que uma falha resulta numa avaria de sistema pode nunca ocorrer. Estecaso é facilmente visualizado se você considerar um código contendo uma falha quenunca é executado, ou este código não é executado o suficiente para incrementar umcontador que ultrapasse limites inaceitáveis.

Durante o teste e a operação, observamos o comportamento do sistema. Quando umcomportamento indesejável ou inesperado acontece, nós reportamos este fato como umaavaria. A confiabilidade de um sistema de software está definida em termos de avariasobservadas durante a operação, ao invés de número de falhas; normalmente, podemosdeduzir pouco sobre confiabilidade a partir somente das informações de falhas. Assim, adistinção entre avarias e falhas é muito importante. Sistemas com muitos falhas podemser muito confiáveis, porque as condições que ativam as falhas podem ser muito raras.

Para muitas organizações, erros freqüentemente significam falhas. Também háuma noção distinta de "processar erro", que pode ser pensado como um estado dosistema que resultou da ativação de uma falha mas antes da ocorrência de uma avaria[4]. Esta noção particular de erro é altamente pertinente a software tolerante a falhas

8 /20

(que está preocupado em como prevenir avarias na presença de erros deprocessamento) [5],• Anomalias normalmente representam uma classe de defeitos que são improváveis de

causar avarias (desde que considerados isoladamente), mas eventualmente podemcausar avarias indiretamente. Neste caso, uma anomalia é um desvio do correto,mas não é necessariamente errado. Por exemplo, desvio do padrão aceitável da boaprática de programação (como uso de nomes de variáveis sem significado) éconsiderado freqüentemente como anomalia.

• Defeito normalmente é utilizado para se referenciar coletivamente a falhas eavarias. Porém, às vezes um defeito é uma classe particular de falha.

• Bugs refere-se a falhas que acontecem no código.• Crashes são um tipo especial de falha onde o sistema deixa de funcionar.

Até que a terminologia seja a mesma para todos, é importante sejam definidas regrasclaras, de forma que todos as compreendam, quem deve suprir, coletar, analisar, e usaros dados. Freqüentemente, diferenças de significado são aceitáveis, contanto que estesdados possam ser transladados de uma estrutura para a outra.

4. Confiabilidade como um Atributo da QualidadeHá muitos modelos diferentes para qualidade de software, mas em quase todos modelos,confiabilidade é um dos critérios, atributo ou característica que estão incorporadas. ISO9126 std define seis características de qualidade, uma dos quais é confiabilidade.

Considerando que confiabilidade é um atributo da qualidade, pode se concluir que aconfiabilidade de software depende de um software com muita qualidade. A construçãode um software confiável depende da aplicação de atributos de qualidade a cada fase dociclo de vida de desenvolvimento com a ênfase na prevenção de erros, especialmentenas fases preliminares do ciclo de vida. Métricas são necessárias a cada fase dodesenvolvimento para medir atributos da qualidade. IEEE Std 982.2-1988 inclui odiagrama da Figura 1, indicando a relação da confiabilidade com as diferentes fases dociclo de vida. [8]

Codificação do Erro Humano

falha

Sistema

avariaErro Humano

9 /20

Focando na prevenção de erros para melhoria da confiabilidade, precisamos identificar emedir os atributos da qualidade aplicável as diferentes fases do ciclo de vida.Precisamos especificamente focar o fluxo de trabalho (workflow) – requisitos, análise,projeto, implementação, e teste – que ocorrem nas diversas iterações.

5. Melhoria do Processo de software com CMMUm processo de desenvolvimento de software bem administrado pode ser visto comoprocesso iterativo de troca de informações e permite que organizações dedesenvolvimento de software tenham uma clara visão e um bom entendimento dainformação disponível, provendo fundamentos para a análise e administração doprocesso de software baseado em fatos concretos e não em vagas suposições.

Para resistir a pressão da competição, economia de recursos, e para melhorar aqualidade do software produzido, uma organização de desenvolvimento de softwareprecisa perceber a necessidade de implementar e administrar um processo dedesenvolvimento de software eficiente e efetivo. [13]

O Modelo de Maturidade de Capacidade (Capability Maturity Model (CMM)),desenvolvido pela Software Engineering Institute (SEI), é a estrutura básica conceitualque representa o processo de gerenciamento do desenvolvimento de software. O CMMcontêm cinco níveis de maturidade ou fases. Estes cinco níveis de maturidade definemuma escala original para medir a maturidade do processo de software de umaorganização e para avaliar a capacidade do processo de software. Cada nível dematuridade indica o nível de capacidade de processo:

CONFIABILI-DADE DESOFTWARE

FIM DE VIDA• Facilidade de

transferência,conversão,migração.

• Verificaçãoem paralelo.

CONCEITOS• Necessidades/Objetivos dousuário–funcionalidade–desempenho–completo–consistência• Padrões deDocumentação REQUISITOS

• Aderência as necessidades• Arquitetura• Ambiente Operacional• Completo• Facilidade de uso

PROJETO• Complexidade• Modularidade• Interfaces• Expansibilidade• Cronologia,Dimensão• Completo

IMPLEMENTA-ÇÃO• Complexidade• Interfaces• Completo• Padrões deDesenvolvimento• Facilidade demanutenção

TESTE• Cobertura dasFuncionalidades• Cobertura dosTópicos• Interface doscomponentes• Medidas deDesempenho

INSTAÇÃO &VERIFICAÇÃO• Realidade operacional• Cobertura daconfiguração• Interfaces– SW / SW– SW / HW

OPERAÇÃO & MANUTENÇÃO• Integridade das mudanças• Cobertura dos Testes deregressão• Facilidade de aprendizado,facilidade de uso.

Figura 1: Fatores de Qualidade que afetam a Confiabilidade

10 /20

• Nível 1, inicial: O processo de software é caracterizado como ad hoc, caótico, eheróico. Poucos processos estão definidos ou seguidos, e o sucesso do projetodepende do esforço individual. Não há nenhum gerenciamento formal sobre odesenvolvimento de software.

• Nível 2, reproduzível: Este nível provê uma introdução formal, ao processodocumentado. São estabelecidos processos básicos de gerenciamento para controlarcusto, cronograma e funcionalidade. A necessária disciplina do processo está acaminho de repetir sucessos de projetos anteriores com aplicações semelhantes. Aelevação do Nível 1 para o Nível 2 significa que a organização estabeleceu controlesobre o gerenciamento de projeto, estabeleceu um grupo de processo de engenhariade software (SEPG), e formalmente introduziu métodos e técnicas de engenharia desoftware.

• Nível 3, definido: Este nível provê os fundamentos para o processo de melhoriacontínua estabelecendo as funções do gerenciamento do processo necessárias paracontrolar os parâmetros do processo. O processo de software para as atividades degerenciamento e engenharia estão documentados, padronizados, e integrados em umprocesso de software padronizado para toda a organização. Todos os projetos usamuma versão sob medida (subset adequado ao projeto) do processo de softwarepadrão da organização para desenvolver e manter software.

• Nível 4, gerenciado: Medidas detalhadas do processo de software e da qualidade doproduto são coletadas. O processo de software e de produtos são quantitativamentecompreendidos e controlados.

• Nível 5, otimizado: O processo de melhoria contínua é possível através da avaliaçãoquantitativa do processo e a partir da introdução de idéias e tecnologias inovadoras.

6. Métricas de Software para Qualidade.

Devem ser usadas métricas de software para melhorar a qualidade e a confiabilidadeatravés da identificação de áreas da especificação de requisitos do software e do códigoque potencialmente podem causar erros.

Medidas oferecem visibilidade de como os processos, produtos, recursos, métodos, etecnologias de desenvolvimento de software se relacionam entre si. Medidas podem nosajudar a responder perguntas sobre a efetividade de técnicas ou ferramentas, sobre aprodutividade de atividades de desenvolvimento e a qualidade dos produtos.Modelos de qualidade normalmente envolvem formas de avaliação do produto, e suameta fundamental é prever a qualidade do produto.

Os produtos de um Processo de Desenvolvimento de Software são os artefatos,incluindo o software, documentos e modelos. As métricas recomendadas são listadasaqui com os modelos para os quais se aplicam.

11 /20

Três fases do ciclo de vida serão abordadas onde técnicas de prevenção de erro emétricas de software podem ser aplicadas com grande impacto sobre a qualidade e aconfiabilidade: requisitos, codificação e teste.

6.1. Métricas de Qualidade para Requisitos de SoftwareOs requisitos especificam a funcionalidade que deve ser incluída no software final. Écrítico que os requisitos sejam escritos em linguagem clara e precisa de modo a facilitaro entendimento entre o desenvolvedor e o cliente. Usando os atributos de qualidade paraa confiabilidade mostrado na Figura 1, para software de alta confiabilidade, osrequisitos devem ser estruturados, completos, e de fácil aplicação.Há três formatos primários para estrutura de especificação de requisitos, definidos porIEEE, DOD e NASA. [7,8,9]. Estes definem o que deve conter a especificação dosrequisitos além dos próprios requisitos. O uso consistente de um formato como estes,assegura que informações críticas, como o ambiente operacional, não sejam omitidas.Requisitos completos são estáveis e incluem todas as informações possíveis,especificado com detalhes adequados de modo a permitir que o projeto e aimplementação evoluam. Especificações de requisitos não deveriam conter frases talqual ASD (a ser definido) ou ASA (a ser adicionado) pois a generalidade destas frasesprovocam um impacto negativo no projeto, e causam uma arquitetura incoerente.Para aumentar de a facilidade de uso dos requisitos, eles são escritos normalmente nalíngua corrente (português no Brasil) [ao invés de um estilo de escrita especializado (porexemplo, anotação Z)] que pode facilmente produzir terminologia ambígua. Paradesenvolver software confiável nas fases subsequentes a fase de requisitos, os requisitosnão devem conter termos ambíguos, ou conter qualquer terminologia que possa serinterpretado como um requisito opcional. Requisitos ambíguos são estes que podem tersignificados múltiplos ou que parecem deixar ao desenvolvedor a decisão se deve ounão implementar um requisito.A importância de documentar requisitos corretamente foi uma das razões para que aindústria de software produzisse um número significante de ferramentas de auxilio àcriação e gerenciamento de documentos da especificação de requisitos e dos itensespecificados individualmente. Entretanto poucas destas ferramentas ajudam naavaliação da qualidade do documento de requisitos ou dos itens especificadosindividualmente.

6.1.1. Use Case (Casos de Uso)Uma boa ferramenta para capturar requisitos e coloca-los no contexto é o modelamentode Casos de Uso (Use Cases).

Casos de Uso são um modo para organizar requisitos da perspectiva do usuário. Todasos requisitos para um usuário realizar uma tarefa particular são reunidos em um únicocaso de uso. O modelo de use-case é a coleção de todos os casos de uso individuais.

Vantagens do modelamento de casos de uso incluem:• Casos de uso mostram porque o sistema é necessário. Casos de uso mostram que

metas os usuários podem realizar usando o sistema.• Requisitos de sistema são definidos no contexto. Cada requisito é parte de uma

sucessão lógica de ações de modo a realizar uma meta do usuário.

12 /20

• Casos de uso são facilmente compreensíveis. O modelo expressa requisitos daperspectiva do usuário e na linguagem própria do usuário. O modelo nos mostracomo os usuários imaginam o sistema e o que o sistema deve fazer.

• O modelo é um meio para comunicar os requisitos entre os clientes e odesenvolvedor, de modo a garantir que o sistema que construímos é o que deseja ocliente.

6.1.2. Métricas para os RequisitosCaracterística MétricasTamanho • Número totais de requisitos

• Número de Casos de UsoEsforço • Unidades de homens-hora (na elaboração, mudança e

reparo, separadamente).Volatilidade • Número de defeitos e pedidos de mudança (aberto, fechado)Qualidade • Defeitos–número de defeitos, por severidade, abre, fechadoRastreabilidade • Requisito para UC

• Modelo de UC para o projeto• Projeto – Cenários realizados no modelo de projeto /

número totais de cenários• Implementação – Cenários realizados no modelo de

implementação / número totais de cenários.• Teste – Cenários realizados no modelo de teste (casos de

cases) / número totais de cenários.Completo • Número de Caso de Uso completados (revisados e sob o

gerenciamento da configuração e sem defeitos a seremresolvidos) / casos de uso identificados (ou númeroestimado de casos de uso)

6.2. Qualidade do Código e do Projeto, Métricas de ConfiabilidadeMétricas tem que contribuir para a avaliação da qualidade nas fases iniciais do ciclo devida, quando esforços para melhorar a qualidade de software são efetivos. A coleta dasmétricas deve ser automatizada e não intrusivo, isto é, não deve interferir com asatividades dos desenvolvedor.

A definição de um procedimento de métricas para códigos orienta os projetos desoftware e tem como finalidade monitorar e avaliar os seguintes aspectos do projeto:

• Progresso em termos de tamanho e complexidade.• Estabilidade em termos de taxa de mudança na implementação, tamanho, ou

complexidade.• Modularidade em termos da extensão de mudança• Qualidade em termos do número e tipo de erros.• Maturidade em termos da freqüência dos erros.• Recursos em termos do valor gasto com o projeto contra o gasto planejado.

Um modelo de qualidade tem que definir os atributos a serem medidos, atributosinternos e externos:

13 /20

• Atributos internos - Medimos e analisamos atributos internos porque eles podemprognosticar atributos externos. Os atributos internos estão freqüentementedisponíveis para medida no inicio do ciclo de vida, considerando que atributosexternos só são mensuráveis quando o produto estiver completo (ou quase assim), esegundo, atributos internos são freqüentemente mais fáceis de medir que atributosexternos:

Características a serem medidasCaracterística Métricas

Tamanho • Número de classes• Número de linhas executáveis

Esforço • Horas homem.Volatilidade • Número de defeitos e pedidos de mudança (aberto, fechado)

• “Breakage” (veja 6.2.1.2.1) para cada correção ou mudança devido a melhoramento.Complexidade • Tamanho de métodos

• Número de declarações executáveis por método• Número de métodos por classe• Número de declarações if-then-else, while, for, try e switch

aninhados.• Contagem estática de caminhos• Resposta para uma Classe (RFC)• Complexidade Ciclomática dos métodos• Profundidade da estrutura de herança de classes

Acoplamento • Número de objetos filhos.• Acoplamento entre objetos (classe fan-out).

Coesão • Número de objetos filhos.• Falta de coesão nos métodos (LCOM).

Defeitos • Número de defeitos, por severidade, aberto, fechado.

Qualidade

Legibilidade • Número de linhas de comentário por número de declarações doprograma.

• Razão comentário / linha de código.Completo • Número de unidades de classes testadas / número de classes no modelo de projeto

• Número de classes integradas / número de classes no modelo de projeto• Rastreabilidade da implementação (no modelo de Casos de Uso).• Rastreabilidade do modelo de Teste.• Tempo da integração ativa e de teste do sistema.

• Atributos externos - esses que só podem ser medidos considerando-se como oproduto se relaciona a seu ambiente:

o Facilidade de usoo Facilidade de manutençãoo Medidas de qualidade baseadas nos defeitos.

6.2.1. Métricas de Código

6.2.1.1. Tamanho

6.2.1.1.1. Número de classesNúmero de classes é um dos modos para se medir Tamanho. Esta medida pode serusada para verificação do plano da iteração e da quantidade de retrabalho por iteração.

14 /20

6.2.1.1.2. Número de linhas executáveisTamanho é usado para se avaliar a facilidade de compreensão do código pordesenvolvedores e mantenedores. Expressões executáveis é a contagem do número delinhas executáveis indiferentemente do embora número de linhas físicas de código, porexemplo,

if (temp < 0){ // temp = 0; //Este exemplo tem uma sentença executável.}

6.2.1.2. Volatilidade

6.2.1.2.1. Breakage“Breakage” é a tendência do software em apresentar defeitos em muitos lugares todavez que é mudado. Freqüentemente a quebra (“Breakage”) acontece em áreas que nãotêm nenhuma relação conceitual com a área que foi mudada. Tais erros enchem oscorações dos gerentes de maus pressentimentos. Toda vez que eles autorizam umacorreção, eles temem que o software quebre de algum modo inesperado. A medida que afragilidade se intensifica, a probabilidade da ocorrência de “Breakage” aumenta com otempo, se aproximando assintoticamente. Tal software é impossível de se manter. Todacorreção piora a situação, introduzindo mais problemas do que os que são resolvidos.

6.2.1.3. Complexidade

6.2.1.3.1. Tamanho dos métodosÉ muito recomendado evitar funções longas (mais do que 100 linhas), porque funçõeslongas têm muitas desvantagens:• Se uma função for muito longa, pode ser difícil sua compreensão. Geralmente, pode

se dizer que uma função não deveria ser mais longa que duas páginas, visto que istoé quanto se pode compreender de uma única vez.

• Funções complexas são difíceis de se testar. Se uma função consiste em 15declarações “if” aninhados, então há 215 (ou 32768) diferentes ramos para se testarem uma única função.

6.2.1.3.2. Número de declarações executáveis por métodoO número de máximo de declarações por método deve ser menor que 10, porquemétodos com muitos declarações são difíceis de se entender.

6.2.1.3.3. Número de métodos por classeÉ altamente recomendado definir o número de máximo de métodos por classe em 20,porque é importante ter uma implementação clara e muitos métodos aumentam acomplexidade e obscurecem a compreensão.

6.2.1.3.4. Número de if-then-else, while, for, try and switchaninhados

O número de máximo de declarações if-then-else, while, for, try and switch aninhadospor classe devem ser menor que 4, porque se um número maior de declaraçõesaninhadas são usadas, mais difícil se torna manter um claro entendimento.

15 /20

6.2.1.3.5. Número de Caminhos EstáticosO número de caminhos estáticos de um método, isto é, o limite máximo de todos ospossíveis caminhos de um método, deve ser menor que 20, porque o número decaminhas estáticos está diretamente relacionado a facilidade de teste do software.

6.2.1.3.6. Resposta de uma Classe (RFC)O número de máximo de métodos que podem ser invocados em resposta a umamensagem deve ser 20. A RFC é a contagem de todos os métodos que podem serinvocados em resposta a uma mensagem de um objeto de uma classe ou por algummétodo da classe. Isto inclui todos os métodos acessíveis dentro da hierarquia da classe.Esta métrica foca na combinação da complexidade de uma classe através do número demétodos e a quantidade de comunicação com outras classes. Quanto maior for o númerode métodos de uma classe que podem ser invocados através de mensagens, maior acomplexidade da classe. Se um grande número de métodos podem ser invocados emresposta a uma mensagem, o teste e depuração da classe se torna complexo porque irárequerer um conhecimento mais detalhado da mesma por parte de quem efetua os testes.A elaboração de uma lista com os piores casos possíveis de respostas ajudará nadistribuição apropriada do tempo de teste.

6.2.1.3.7. Complexidade Ciclomática de métodosComplexidade Ciclomática é a métrica mais amplamente utilizada, membro da classe demétricas estáticas de software. Introduzida por Thomas McCabe em 1976, mede onúmero caminhos linearmente independentes de um módulo de programa. Esta medidaprovê um único número ordinal que pode ser comparado à complexidade de outrosprogramas. A Complexidade Ciclomática é freqüentemente referenciada simplesmentecomo complexidade do programa, ou como complexidade de McCabe. Pretende serindependente da linguagem e do formato da linguagem [15].A complexidade ciclomática de um módulo de software é calculada a partir de umgráfico conectado do módulo:Complexidade Ciclomática (CC) = E - N + pOnde E = o número de extremidades do gráfico

N = o número de nós do gráficop = o número de componentes conectados

Estudos mostram uma correlação entre a complexidade Ciclomática de um programa esua freqüência de erro. Uma baixa complexidade Ciclomática contribui para a facilidadede compreensão de um programa e indica que este é acessível a modificações comrisco menor que um programa mais complexo. A complexidade Ciclomática de ummódulo também é um forte indicador de sua facilidade de teste.

Complexidade CiclomáticaComplexidade

CiclomáticaAvaliação de Risco

1-10 Programa simples, sem muito risco.11-20 Complexo, risco moderado.21-50 Complexo, Programa de alto risco.

maior que 50 Programa quase impossível de ser testado.(altíssimo risco)

16 /20

Exemplo:

6.2.1.3.8. Profundidade da estrutura de herançaRepresenta o número de derivações da mais afastada classe de base (origem) até estaclasse. Um valor elevado desta métrica pode indicar que a classe depende defuncionalidade acumulada, que potencialmente dificulta a compreensão da classe.Quanto mais em baixo uma classe está dentro da hierarquia, maior o número demétodos que provável herdará, o que torna muito mais complexo predizer seu

comportamento. Estruturas com ramos mais longos (profundos) ocasionam uma maiorcomplexidade de projeto, visto que mais métodos e classes estão envolvidos, mas temostambém um maior potencial para reuso de métodos herdados. Maior profundidade deHerança indica um compromisso entre um incremento na complexidade e umincremento em reuso. Evite profundidade da estrutura de herança maior que 5.

6.2.1.4. Acoplamento

6.2.1.4.1. Número de filhosO maior o número de filhos (classes derivadas), maior o reuso, visto que herança é umaforma de reuso. Maior o número de filhos, maior a probabilidade de uma abstraçãoimprópria da classe de mãe. Se uma classe tiver um grande número de filhos, pode serum caso de abuso de subclasse. Se uma classe tiver um grande número de filhos, poderequerer mais tempo para teste dos métodos daquela classe. Evite número de filhosmaior que 5.

6.2.1.4.2. Acoplamento entre objetos (fan-out da classe)É definido como o número de classes com os quais uma classe está acoplada. Duasclasses estão acopladas quando métodos declarados em uma classe usa métodos ouinstancias de variáveis da outra classe [6]. Acoplamento excessivo entre classes deobjetos é prejudicial ao projeto modular e impede o reuso. Quanto mais independenteuma classe é, mais fácil é reutiliza-la em outra aplicação. Para melhorar a modularidadee promover o encapsulamento, acoplamento entre classes devem ser mínimos. Quantomaior o número de acoplamentos, maior a sensibilidade à mudanças em outras partes doprojeto, e como conseqüência a manutenção se torna mais difícil. Forte acoplamentotorna um sistema mais complexo visto que uma classe é de difícil compreensão,

seqüência:1-2+2=1

y=2

z=3

if / then:3-3+2=2

thendo this

ifx>4

no

yes

while loop:3-3+2=2

while

until loop:3-3+2=2

until

Do

17 /20

mudança e correção por si só, se estiver relacionado com outras classes. O projeto desistemas com o menor acoplamento possível entre classes pode reduzir a complexidade.Isto melhora a modularidade e promove o encapsulamento. Evite número de outrasclasses com as quais uma classe está acoplada maior que 10.

6.2.1.5. Coesão

6.2.1.5.1. Número de filhos

Veja item 6.2.1.4.1.

6.2.1.5.2. Falta de coesão em Métodos (LCOM)A falta de coesão mede a dessemelhança de métodos em uma classe por instancias devariáveis ou atributos.Um módulo altamente coeso deve estar isolado; alta coesão indica boa subdivisão declasses. Falta de coesão ou baixa coesão aumenta a complexidade e aumenta aprobabilidade de erros durante o processo de desenvolvimento. Coesão alta indicasimplicidade e alta grau de reuso. Classes com baixa coesão provavelmente poderiamser subdivididas em duas ou mais subclasses com maior coesão. Quando os objetos tempoucos métodos em comum, há muita falta de coesão. Isto implica que um nível deabstração adicional é necessária – objetos semelhantes precisam ser agrupados criandoclasses derivadas para estes.

6.2.1.6. Legibilidade

6.2.1.6.1. Número de linhas de comentário por número dedeclarações ou instruções do programa

O código de fonte deve ser suficientemente documentado. Por arquivo, pelo menos,uma linha de comentário é necessária para cada duas declarações de programa.Software que não é bem documentado pode ser de difícil compreensão. Especialmenteexceções que acontecem no software e que podem ser facilmente mal compreendidas.

6.2.1.6.2. Razão Comentários / CódigoA razão comentários por código é definido como o número de caracteres visíveis emcomentários dividido pelo número de caracteres visíveis fora dos comentários.Delimitadores de comentários são ignorados. Espaços em branco em “strings” sãotratados como caracteres visíveis. Um valor alto desta métrica pode indicar que hámuitos comentários–um atributo que pode tornar um módulo difícil de se ler. Um valorpequeno pode indicar que não há o bastante. É recomendado ter uma razão comentáriopor código entre 0,5 e 1,5.

6.3. Qualidade do teste e Métricas de Confiabilidade

Métricas de teste devem ter dois critérios para avaliar a confiabilidade de modoabrangente. O primeiro critério é a avaliação do plano de teste, de modo a assegurar queo sistema contenha a funcionalidade especificada nos requisitos (rastreabilidade doteste). Esta atividade deve reduzir o número de erros devido a falta de funcionalidadeesperada.O segundo critério, que freqüentemente está associado com a confiabilidade, é aavaliação do número de erros no código e taxa de erros achados/corrigidos.

18 /20

Para assegurar que o sistema contenha a funcionalidade especificada, planos de testecontendo múltiplos casos de teste são escritos; cada caso de teste é baseado em umestado do sistema e testa algumas funções baseadas num grupo de requisitos. O objetivode um programa efetivo de verificação é assegurar que todo requisito seja testado, o queimplica que se o sistema passa no teste, a funcionalidade requerida está no sistema a serentregue.

6.3.1. Casos de TesteConsiderando-se todos os casos de teste, cada requisito deve ser testado pelo menosuma vez, e alguns requisitos serão testados várias vezes porque eles estão envolvidosem múltiplos estados do sistema, em vários cenários e de modos diferentes. Mas comosempre, o tempo e os recursos financeiros disponíveis são questões importantes;enquanto cada requisito dever ser abrangentemente testado, tempo e orçamentolimitados sempre são restrições para se escrever e executar os casos de teste. Éimportante assegurar que cada requisito seja adequadamente, mas não excessivamente,testado. Em alguns casos, os requisitos podem se agrupados usando como critério queos mesmos sejam críticos para o sucesso do projeto; estes devem ser extensivamentetestados. Em outros casos, podem ser identificados requisitos não críticos; se umproblema acontece, a funcionalidade destes não afeta o sucesso do projeto enquanto seobtém um teste bem sucedido.

6.3.2. Propósito dos Casos de Teste• Identificar e descrever as condições de teste a serem utilizados.

• Estender os Casos de Uso adicionando respostas do sistema• Criar instancias de Casos de Uso (fluxo básico / fluxo alternativo)

• Identificar os dados específicos necessário ao teste.• Estender o Caso de Uso com vetores de teste (valores).• Estender as pré e pós condições com condições reais do sistema .

• Identificar os resultados esperados do teste.• Criar critérios de Aprovação/Falha.

• Se o objetivo do teste for o sistema completo, o caso de teste corresponderá auma execução completa de um caso de uso.

• Se o objetivo do teste for um subsistema, o caso de teste corresponderá àparte do caso de uso que corresponde ao subsistema.

19 /20

6.3.3. Métricas de Teste

Característica MétricasTamanho $%Número de Casos de Teste, Procedimentos de Teste,

“Scripts” de Teste.Esforço $%Número de horas-homem (despendido com a

produção, modificação e correção, separadamente) para aprodução dos casos de teste.

Volatilidade $%Número defeitos e requisições de mudanças (aberto,fechado) – comparado com o modelo de teste.

Qualidade $%Defeitos – número de defeitos por grau de severidade,abertos, fechados (estes defeitos são identificados a partirdo modelo de teste, não defeitos identificados pelo timede teste no software)

Completo $%Número de casos de teste implementados / número decasos de teste estimados.$%Rastreabilidade do teste (no modelo de Casos de Uso)$%Rastreabilidade do teste (nos Atributos dos Requisitos)$%Cobertura do código

Rastreabilidade $%Número de Casos de Teste reportados como bemsucedidos no Resumo de Avaliação do Teste / Númerode casos de teste.

7. Referencias

[1] Jacobson, Ivar, Grady Booch and James Rumbaugh, "The Unified SoftwareDevelopment Process," Addison-Wesley, 1999.

[2] Leffingwell, Dean, "Managing Software Requirements," Addison-Wesley, 2000.

[3] Royce, Walker, "Software Project Management," Addison-Wesley, 1998.

[4] Laprie, J.C., "Dependability: Basic Concepts and Terminology," Springer-Verlag,1992.

[5] Fenton, Norman E., "Software Metrics," PWS, 1997.

[6] Douglas, Bruce Powel, "Real Time UML," Addison Wesley, 1998.

[7] Whitmire, Scott A., "Object Oriented Design Measurement", John Wiley & Sons,1997.

[8] IEEE Standard 982.2-1987, "Guide for the Use of Standard Dictionary of Measuresto Produce Reliable Software".

[9] Rosenberg, Dr. Linda H., Ted Hammer and Jack Shaw, "Software Metrics andReliability," 9th International Symposium, November, 1998, Germany.

20 /20

[10] Basili, Victor R., Lionel C. Briand and Walcélio L. Melo, "A Validation of Object-Oriented Design Metrics as Quality Indicators", IEEE Transactions on SoftwareEngineering, Vol. 22, nº 10, October, 1996.

[11] Martin, Robert C., "Design Principles and Design Patterns", Object Mentor, 2000.

[12] "Why Coding Standards?", PR:QA White paper Series: WP5.1, ProgrammingResearch Ltd., http://www.prqa.co.uk, 1998.

[13] Raynus, Joseph, "Software Process Improvement with CMM", Artech House,1998.

[14] Rosenberg, Dr. Linda H., "Applying and Interpreting Object oriented Metrics",Software Technology Conference, Utah, April 1998.

[15] McCabe, Thomas J. & Watson, Arthur H. "Software Complexity.”, Crosstalk,Journal of Defense Software Engineering 7, 12 (December 1994): 5-9.