Exemplo 1.

3: Não há medidas universalmente reconhecidas para identificar os melhores

jogadores de futebol individuais (embora o número de golos marcados seja uma medida
bastante precisa da qualidade de um atacante). Embora muitos fãs e jogadores tenham
argumentado que a qualidade do jogador é um atributo incompreensível, essa questão foi
abordada antes dos jogos da Copa do Mundo de 1994 nos EUA. Para fornecer um meio
objetivo (mensurável) de determinar o "homem da partida", várias novas medidas foram
propostas:

"Para ajudar a FIFA a avaliar os melhores jogadores, será necessário adicionar as marcas de
afinação. A intervalos de dez metros, haverá linhas em ambos os lados do campo. Isso
permitirá uma passagem justa, uma passagem lateral, uma jarda de drible e encaminhando a
jarda para cada jogador ".

Traduzido de "Mudanças prováveis às regras para a Copa do Mundo de 1994",

Nouveaux FIFA d'Arbitres, março de 1990.

É fácil ver paralelos na engenharia de software. Em muitos casos, queremos uma pontuação
geral que combine várias medidas em uma "grande imagem" do que está acontecendo
durante o desenvolvimento ou a manutenção. Queremos saber se um produto de software é
bom ou ruim, com base em um conjunto de medidas, cada uma das quais capta uma faceta de
"bens". Da mesma forma, queremos poder medir a capacidade de uma organização para
produzir um bom software ou a capacidade de um modelo de fazer boas previsões sobre o
processo de desenvolvimento de software. As medidas compostas podem ser controversas,
não só por causa das medidas individuais que a compõem, mas também por causa dos pesos
atribuídos. Da mesma forma, a polêmica entra em erupção quando tentamos capturar
informações qualitativas sobre algum aspecto da engenharia de software. Diferentes
especialistas têm opiniões diferentes, e às vezes é impossível obter consenso.

Finalmente, às vezes é necessário modificar nosso ambiente ou nossas práticas para medir
algo novo ou de uma maneira nova. Pode significar o uso de uma nova ferramenta (para
contar linhas de código ou avaliar estrutura de código), adicionando uma nova etapa em um
processo (para informar sobre o esforço), ou usando um novo método (para tornar a medida
mais simples). Em muitos casos, a mudança é difícil para as pessoas aceitarem; Como veremos
em capítulos posteriores, há questões de gerenciamento a serem consideradas sempre que
um programa de medição é implementado ou alterado.

1.2 Medição em engenharia de software

Vimos que a medição é essencial para nossas vidas diárias, e a medição tornou-se comum e
bem aceita. Nesta seção, examinamos o domínio da engenharia de software para ver por que a
medição é necessária. A engenharia de software descreve a coleta de técnicas que aplicam
uma abordagem de engenharia para construção e suporte de produtos de software. As
atividades de engenharia de software incluem gerenciar, custear, planejar, modelar, analisar,
especificar, projetar, implementar, testar e manter. Por "abordagem de engenharia",
queremos dizer que cada atividade é compreendida e controlada, de modo que há poucas
surpresas à medida que o software é especificado, projetado, construído e mantido. Enquanto
a ciência da computação fornece os fundamentos teóricos para a construção de software, a
engenharia de software se concentra na implementação do software de forma controlada e
científica. A importância da engenharia de software não pode ser subestimada, já que o
software permeia nossas vidas. Desde controles de forno a airbags, de transações bancárias ao
controle de tráfego aéreo, e de plantas de energia sofisticadas a armas sofisticadas, nossas
vidas e a qualidade de vida dependem de software. Para uma profissão tão jovem, a
engenharia de software geralmente fez um trabalho admirável de proporcionar uma fidelidade
segura, útil e confiável. Mas há espaço para uma grande melhoria. A literatura está repleta de
exemplos de projetos que superaram seus orçamentos e horários. Pior, há muitas histórias
sobre software que colocou vidas e empresas em risco. Os engenheiros de software
abordaram esses problemas buscando continuamente novas técnicas e ferramentas para
melhorar o processo e o produto. O treinamento suporta essas mudanças, de modo que os
engenheiros de software estão melhor preparados para aplicar as novas abordagens para
desenvolvimento e manutenção. Mas as melhorias metodológicas por si só não fazem uma
disciplina de engenharia.

1.2.1 Negligência de medidas em engenharia de software

As disciplinas de engenharia usam métodos baseados em modelos e teorias. Por exemplo, ao

projetar circuitos elétricos, atraímos teorias como a lei de Ohm, que descreve a relação entre
resistência, corrente e tensão no circuito. Mas as leis do comportamento elétrico evoluíram
usando o método científico: afirmando uma hipótese, projetando e executando um
experimento para testar sua verdade e analisando os resultados. Subjugar o processo científico
é a medição: medir as variáveis para diferenciar os casos, medir as mudanças no
comportamento e medir as causas e os efeitos. Uma vez que o método científico sugere a
validade de um modelo ou a verdade de uma teoria, continuamos usando medidas para aplicar
a teoria a prática. Assim, para construir um circuito com uma corrente e resistência específicas,
nós sabemos o que é necessária a tensão e usamos instrumentos para medir se temos uma
tensão em uma determinada bateria. É difícil imaginar engenharia elétrica, mecânica e civil
sem um papel central para a medição. De fato, a ciência e a engenharia, não podem ser
efetivas nem práticas sem medição. Mas a medição foi considerada um luxo na engenharia de
software. Para a maioria dos projetos de desenvolvimento:

1. Nós não conseguimos estabelecer metas mensuráveis para nossos produtos de software.
Por exemplo, prometemos que o produto será fácil de usar, confiável e sustentável sem
especificar de forma clara e objetiva o significado desses termos. Como resultado, quando o
projeto estiver completo, não podemos dizer se cumprimos nossos objetivos. Esta situação
levou a Tom Gilb a declarar (Gilb, 1988) o Princípio dos Objetivos Difusos de Gilb: projetos sem
metas claras não alcançarão seus objetivos com clareza.

2. Não conseguimos entender e quantificar os custos de componentes de projetos de

software. Por exemplo, a maioria dos projetos não pode diferenciar o custo do design do custo
de codificação ou teste. Uma vez que o custo excessivo é uma queixa de muitos de nossos
clientes, não podemos esperar controlar os custos se não estivermos medindo os
componentes relativos do custo.

3. Não quantificamos nem prevemos a qualidade dos produtos que produzimos. Assim, não
podemos dizer a um usuário potencial qual a confiança de um produto em termos de
probabilidade de falha em um determinado período de uso, ou quanto trabalho será
necessário para a entrega do produto para um ambiente de máquina diferente.
4. Permitimos evidências anedóticas para convencer-nos a tentar mais uma nova tecnologia
revolucionária de desenvolvimento, sem fazer um estudo cuidadosamente controlado para
determinar se a tecnologia é eficiente e eficaz. Figura 1 . 1 mostra exemplos típicos de
materiais promocionais para ferramentas e técnicas de desenvolvimento automatizado de
software. Mas na maioria das vezes, esses materiais não são acompanhados por relatórios da
base científica das reivindicações.

Quando as medições são feitas, muitas vezes são feitas com pouca frequência, de forma
inconsistente e incompleta. A incompletude pode ser frustrante para aqueles que desejam
fazer uso dos resultados. Por exemplo, um desenvolvedor pode afirmar que 80% de todos os
custos de software envolvem manutenção, ou que há, em média, 55 falhas em cada 1000
linhas de código de software. Mas nem sempre nós contamos como esses resultados foram
obtidos, como os experimentos foram projetados e executados, quais entidades foram
medidas e como, e quais foram as margens de erro realistas. Sem essa informação adicional,
permanecemos cético e incapaz de decidir se aplicar os resultados e a nossa Situações. Além
disso, não podemos fazer um estudo objetivo para repetir as medidas em nossos próprios
ambientes. Assim, a falta de medição na engenharia de software é agravada pela falta de uma
abordagem rigorosa. É claro a partir de outras disciplinas de engenharia que a medição pode
ser eficaz, se não essencial, para tornar visíveis as características e os relacionamentos, avaliar
a magnitude dos problemas e criar uma solução para os problemas. À medida que o ritmo da
inovação de hardware aumentou, o mundo do software tentou relaxar ou abandonar seus
fundamentos de engenharia e esperar conquistas revolucionárias. Mas agora esse software,
que desempenha um papel fundamental, envolve enorme investimento de energia e dinheiro,
é hora de engenharia de software abraçar a disciplina de engenharia que tem tido tanto
sucesso em outras áreas.

1.2.2 Objetivos para a medição de software

Mesmo quando um projeto não está em apuros, a medição não é apenas útil, mas necessária.
Afinal, como você pode dizer se o seu projeto é saudável se você não tem medidas de saúde?
Portanto, é necessário medir, pelo menos, para avaliar o status de seus projetos, produtos,
processos e recursos. Porque nem sempre sabemos o que descarta um projeto, é essencial
que medimos e gravamos características de bons projetos, bem como de maus. Precisamos
documentar as tendências, a magnitude da ação corretiva e as mudanças resultantes. Em
outras palavras, devemos controlar nossos projetos, não apenas executá-los. Tom DeMarco,
um forte defensor da necessidade de medição no desenvolvimento de software, afirma isso.

Há razões convincentes para considerar o processo de medição cientificamente, de modo que

a medição seja uma verdadeira atividade de engenharia. Toda ação de medição deve ser
motivada por um objetivo ou necessidade particular, claramente definido e facilmente
compreensível. Ou seja, não basta afirmar que devemos medir para ganhar controle. Os
objetivos de medição devem ser específicos, vinculados ao que os gerentes, desenvolvedores e
usuários precisam saber. Assim, esses objetivos podem diferir de acordo com o tipo de pessoal
envolvido e em qual nível de desenvolvimento e uso de software eles são gerados. Mas são os
objetivos que nos dizem como as informações de medição serão usadas quando forem
coletadas. Abaixo estão exemplos dos tipos de informações necessárias para entender e
controlar um projeto de desenvolvimento de software, separado por perspectivas de gerente e
desenvolvedor:

Gerentes

• O que cada processo custa? Podemos medir o tempo eo esforço envolvidos nos vários
processos que compõem a produção de software. Por exemplo, podemos identificar o custo da
obtenção de requisitos, o custo de especificar o sistema, o custo de projetar o sistema eo
custo de codificação e teste do sistema. Desta forma, entendemos não só o custo total do
projeto, mas também a contribuição de cada atividade para o todo.

• Quão produtivo é o pessoal? Podemos medir o tempo necessário para a equipe especificar o
sistema, projetá-lo, codificá-lo e testá-lo. Em seguida, usando medidas do tamanho das
especificações, design, código e planos de teste, por exemplo, podemos determinar a
produtividade da equipe em cada atividade. Esta informação é útil quando as alterações são
propostas; O gerente pode usar as figuras de produtividade para estimar o custo ea duração
da mudança.

• Quão bom o código está sendo desenvolvido? Ao registrar cuidadosamente falhas, falhas e
mudanças à medida que ocorrem, podemos medir a qualidade do software, permitindo-nos
comparar diferentes produtos, prever os efeitos da troca, avaliar os efeitos de novas práticas e
definir metas para o processo e a melhoria do produto.

• O usuário estará satisfeito com o produto? Podemos medir a funcionalidade determinando

se todos os requisitos solicitados foram realmente implementados corretamente. E podemos
medir a usabilidade, a confiabilidade, o tempo de resposta e outras características para sugerir
se nossos clientes ficarão felizes com a funcionalidade e o desempenho.

• Como podemos melhorar? Podemos medir o tempo necessário para realizar cada grande
atividade de desenvolvimento e calcular o efeito sobre qualidade e produtividade. Então
podemos pesar os custos e os benefícios de cada prática para determinar se o benefício vale o
custo. Alternativamente, podemos tentar várias variações de uma prática e medir os
resultados para decidir qual é o melhor; Por exemplo, podemos comparar dois métodos de
design para ver qual deles produz o código de maior qualidade.

Engenheiros

• Os requisitos são testáveis? Podemos analisar cada requisito para determinar se a sua
satisfação é expressa de forma mensurável e objetiva. Por exemplo, suponha que um requisito
afirma que um sistema deve ser confiável; O requisito pode ser substituído por um que declare
que o tempo médio para falha deve ser superior a 15 horas decorridas de tempo de CPU.

• Encontramos todas as falhas? Podemos medir o número de falhas na especificação, design,

código e planos de teste, e rastreá-los de volta às suas causas raiz. Usando modelos de taxas
de detecção esperadas, essas informações podem nos ajudar a decidir se as inspeções e testes
foram efetivos e se um produto pode ser lançado para a próxima fase de desenvolvimento.

• Conhecemos nossos objetivos de produto ou processo? Podemos medir características dos

produtos e processos que nos dizem se cumprimos os padrões, atendemos a um requisito ou
cumprimos um objetivo de processo. Por exemplo, a certificação pode exigir que menos de 20
falhas tenham sido relatadas por site de teste beta durante um determinado período de
tempo. Ou um padrão pode exigir que nenhum módulo contenha mais de 100 linhas de
código. O processo de teste pode exigir que o teste unitário deve atingir uma cobertura de
declaração de 90%.

• O que vai acontecer no futuro? Podemos medir os atributos dos produtos existentes e dos
processos atuais para fazer previsões sobre os ajustes. Por exemplo, as medidas de tamanho
das especificações podem ser usadas para prever o tamanho do sistema alvo, as previsões
sobre futuros problemas de manutenção podem ser feitas a partir de medidas das
propriedades estruturais dos documentos de projeto e as previsões sobre a confiabilidade do
software em uso operacional podem ser feitas medindo a confiabilidade durante o teste.

1.2.3 Medição para compreensão, controle e melhoria

As listas acima nos mostram que a medição é importante para três atividades básicas.
Primeiro, existem medidas que nos ajudam a entender o que está acontecendo durante o
desenvolvimento e a manutenção. Nós avaliamos a situação atual, estabelecendo linhas de
base que nos ajudam a estabelecer metas para o comportamento futuro. Nesse sentido, as
medidas tornam visíveis os aspectos do processo e do produto, dando-nos uma melhor
compreensão das relações entre as atividades e as entidades que elas afetam.

Em segundo lugar, a medida nos permite controlar o que está acontecendo em nossos
projetos. Usando nossas linhas de base, metas e compreensão de relacionamentos, nós
prevemos o que é provável que aconteça e faça mudanças em processos e produtos que nos
ajudem a atingir nossos objetivos. Por exemplo, podemos monitorar a complexidade dos
módulos de código, dando uma revisão completa apenas para aqueles que excedem os limites
aceitáveis. Em terceiro lugar, a medida nos encoraja a melhorar nossos processos e produtos.
Por exemplo, podemos aumentar o número ou tipo de revisões de design que fazemos, com
base em medidas de qualidade de especificação e previsões de qualidade de projeto provável.

Não importa como as medidas são usadas, é importante gerenciar as expectativas daqueles
que tomarão decisões baseadas em medição. Os usuários dos dados devem sempre estar
cientes da precisão limitada da predição e da margem de erro nas medições. Tal como
acontece com qualquer outra disciplina de engenharia, há espaço na engenharia de software
para abuso e mau uso da medida. A Figura 1 .2 mostra irreversivelmente como a gerência
pode pressionar os desenvolvedores a produzir medidas precisas com modelos, ferramentas e
técnicas inadequadas. Se você está esperando que a medição forneça soluções instantâneas e
fáceis aos seus problemas de engenharia de software, esteja ciente de nosso corolário da regra
de DeMarco:

Você não pode prever nem controlar o que você não pode medir.

1.3 O escopo das métricas de software

As métricas de software são um termo que engloba muitas atividades, que envolvem algum
grau de medição de software:

• estimativa de custo e esforço

• medidas e modelos de produtividade

• coleção de dados

• modelos e medidas de qualidade

• modelos de confiabilidade

• avaliação de desempenho e modelos

• métricas estruturais e de complexidade

• avaliação capacidade-maturidade

• gerenciamento por métricas

• avaliação de métodos e ferramentas

Cada uma dessas atividades será abordada em detalhes em capítulos posteriores. Nossas
bases teóricas, que serão descritas nos capítulos 2 e 3, nos permitirão considerar as atividades
de forma unificada, e não como temas diversos e não relacionados.

A breve introdução a seguir lhe dará uma sensação das técnicas atualmente em uso para cada
faceta de medida. Fornece indicadores para onde o material é abordado em detalhes em
capítulos posteriores.

1.3. 1 Estimativa de custo e esforço

Os gerentes forneceram a motivação original para derivar e usar medidas de software. Eles
queriam poder prever os custos do projeto durante fases iniciais no ciclo de vida do software.
Como resultado, foram propostos e utilizados vários modelos de estimativa de custo e esforço
de software. Exemplos incluem o modelo COCOMO da Boehm (Boehm, 1981), o modelo SLIM
da Putnam (Putnam, 1978) e o modelo de pontos de função da Albrecht (Albrecht, 1979). Estes
e outros modelos geralmente compartilham uma abordagem comum: o esforço é expresso
como uma função (pré-definida) de uma ou mais variáveis (como tamanho do produto,
capacidade dos desenvolvedores e nível de reutilização). O tamanho geralmente é definido
como linhas (preditas) de código ou número de pontos de função (que podem ser derivadas da
especificação do produto). Os modelos de custo e a previsão do esforço são discutidos no
Capítulo 12.

1.3.2 Modelos e medidas de produtividade

As necessidades urgentes de gerenciamento também resultaram em inúmeras tentativas de

definir medidas e modelos para avaliar a produtividade da equipe em diferentes processos de
software e em diferentes ambientes. A Figura 1 .3 ilustra um exemplo dos possíveis
componentes que contribuem para a produtividade geral. Mostra a produtividade como uma
função de valor e custo; Cada um é então decomposto em outros aspectos, expresso em forma
mensurável. Este modelo é uma visão de produtividade significativamente mais abrangente do
que a tradicional, que simplesmente divide o tamanho pelo esforço. Ou seja, muitos gerentes
tomam decisões com base na taxa em que as linhas de código estão sendo escritas por pessoa
mês de esforço. Esta medida mais simples pode ser enganosa, se não perigosa (Jones, 1986).
Os modelos e medidas de produtividade são cobertos principalmente no Capítulo 11.

1.3.3 Coleta de dados

A qualidade de qualquer programa de medição é claramente dependente da coleta de dados

cuidadosa. Mas coletar dados é mais fácil dizer do que fazer, especialmente quando os dados
devem ser coletados em um conjunto diversificado de projetos. Assim, a coleta de dados está
se tornando uma disciplina em si, onde os especialistas trabalham para garantir que as
medidas sejam definidas inequivocamente, que a coleta seja consistente e completa e que a
integridade dos dados não esteja em risco. Mas é reconhecido que a coleta de dados de
métricas deve ser planejada e executada de forma cuidadosa e sensível. Veremos no Capítulo
14 como a Hewlett-Packard e outras pessoas tornaram público o quadro gerencial que ajudou
a tornar seu programa de métricas corporativas um sucesso.

A Figura 1 .4 contém vários exemplos de como os dados coletados podem ser destilados em
gráficos e gráficos simples que mostram os gerentes o progresso e os problemas de
desenvolvimento. Basili e Weiss descreveram uma metodologia geral para a coleta de dados
válida (Basili e Weiss, 1984), enquanto Mellor descreve a coleta de dados necessária para
avaliação de confiabilidade (Mellor, 1992). Este material é abordado nos Capítulos 5, 6, 10 e
11. A coleta de dados também é essencial para a investigação científica de relacionamentos e
tendências. Veremos no Capítulo 4 quão boas experiências, pesquisas e estudos de caso
exigem uma coleta de dados cuidadosamente planejada, bem como uma análise minuciosa e
relatórios dos resultados.

1.3.4 Modelos e medidas de qualidade

A produtividade não pode ser vista isoladamente. Sem uma avaliação acompanhada da
qualidade do produto, a velocidade de produção não tem sentido. Esta observação levou os
engenheiros de software a desenvolver modelos de qualidade cujas medidas podem ser
combinadas com as dos modelos de produtividade. Por exemplo, o modelo avançado de
estimativa COCOMO da Boehm está vinculado a um modelo de qualidade (Boehm et ai, 1978).
Da mesma forma, o modelo de qualidade McCall (McCall et al., 1 977), comumente chamado
de modelo FCM (Factor Criteria Metric), está relacionado à produtividade. Esses modelos
geralmente são construídos de forma semelhante a uma árvore, semelhante à Figura 1.5. Os
ramos superiores possuem importantes fatores de qualidade de alto nível de produtos de
software, como confiabilidade e usabilidade, que gostaríamos de quantificar. Cada fator de
qualidade é composto por critérios de nível mais baixo, como a estruturação e a
rastreabilidade. Os critérios são mais fáceis de entender e medir do que os fatores; Assim, as
medidas reais (métricas) são propostas para os critérios. A árvore descreve as relações
pertinentes entre os fatores e seus critérios dependentes, para que possamos medir os fatores
em termos de medidas de critérios dependentes. Essa noção de divisão e conquista foi
implementada como uma abordagem padrão para medir a qualidade do software (ISO 9126).
Os modelos de qualidade são descritos detalhadamente no Capítulo 9.

1.3.5 Modelos de confiabilidade

A maioria dos modelos de qualidade inclui a confiabilidade como fator de componente, mas a
necessidade de prever e medir a própria confiabilidade levou a uma especialização separada
na modelagem e previsão de confiabilidade. Littlewood (1988) e outros fornecem um exemplo
rigoroso e bem-sucedido de como um foco em um atributo de qualidade de produto
importante levou a uma maior compreensão e controle de nossos produtos. Este material está
descrito no Capítulo 10.

1.3.6 Avaliação e modelos de desempenho

O desempenho é outro aspecto da qualidade. O trabalho sob a égide da avaliação de

desempenho inclui características de desempenho do sistema observáveis externamente, tais
como tempos de resposta e taxas de conclusão (Ferrari et al., 1978, 1983; Kleinrock, 1975).
Especialistas em desempenho também investigam o funcionamento interno de um sistema,
incluindo a eficiência de algoritmos incorporados na complexidade computacional e
algorítmica (Garey e Johnson 1979; Hard, 1992). O último também se preocupa com a
complexidade inerente dos problemas medidos em termos de eficiência de uma solução ideal.
Este material é descrito no Capítulo 7.

1.3.7 Métricas estruturais e de complexidade

Atributos de qualidade desejáveis como confiabilidade e manutenção não podem ser medidos
até que alguma versão operacional do código esteja disponível. No entanto, desejamos poder
prever quais partes do sistema de software provavelmente serão menos confiáveis, mais
difíceis de testar ou requerer mais manutenção do que outras, mesmo antes do sistema estar
completo. Como resultado, medimos os atributos estruturais das representações do software
que estão disponíveis com antecedência (ou sem necessidade) de execução; Então, tentamos
estabelecer teorias empíricamente preditivas para apoiar a garantia de qualidade, controle de
qualidade e previsão de qualidade. Halstead (1977) e McCabe (1976) são dois exemplos
clássicos desta abordagem; Cada um define medidas derivadas de representações adequadas
do código-fonte. Este material e desenvolvimentos mais recentes estão descritos no Capítulo
8.

1.3.8 Gerenciamento por métricas

A medida está se tornando uma parte importante do gerenciamento de projetos de software.

Os clientes e desenvolvedores também dependem de gráficos e gráficos baseados em
medições para ajudá-los a decidir se o projeto está no bom caminho. Muitas empresas e
organizações definem um conjunto padrão de medidas e métodos de relatórios, para que os
projetos possam ser comparados e contrastados. Esta coleção uniforme e relatórios são
especialmente importantes quando o software desempenha um papel de apoio no projeto
geral. Ou seja, quando o software é incorporado em um produto cujo foco principal é uma
área de negócios diferente do software, o cliente ou o usuário final geralmente não é bem-
versado na terminologia do software, então a medida pode pintar uma imagem de progresso
em termos gerais e compreensíveis. Por exemplo, quando uma usina de energia pede a um
desenvolvedor de software que escreva software de controle, o cliente geralmente sabe muito
sobre geração e controle de energia, mas muito pouco sobre linguagens de programação,
compiladores ou hardware de computador. As medidas devem ser apresentadas de forma a
informar ao cliente e ao desenvolvedor como o projeto está fazendo. No Capítulo 6,
examinaremos várias técnicas de análise e apresentação de medições que são úteis e
compreensíveis para todos os que estão envolvidos no sucesso do projeto.

1.3.9 Avaliação de métodos e ferramentas

Muitos artigos e livros descrevem novos métodos e ferramentas que podem tornar sua
organização ou projeto mais produtivo e seus produtos melhores e mais baratos. Mas é difícil
separar as reivindicações da realidade. Muitas organizações realizam experimentos, executam
estudos de caso ou administram pesquisas para ajudá-los a decidir se um método ou
ferramenta é susceptível de fazer uma diferença positiva em suas situações particulares. Essas
investigações não podem ser feitas sem medições e análises cuidadas e controladas. Como
veremos no Capítulo 4, o sucesso de uma avaliação depende de um bom projeto experimental,
identificação adequada dos fatores susceptíveis de afetar o resultado e medição apropriada
dos atributos do fator.

1.3.10 Avaliação da maturidade da capacidade

Na década de 1980, o US Software Engineering Institute (SEI) propôs um modelo de

maturidade de capacidade (Humphrey, 1989) para medir a capacidade de um contratado para
desenvolver software de qualidade para o governo dos EUA. Este modelo avaliou muitos
atributos diferentes de desenvolvimento, incluindo o uso de ferramentas, práticas padrão e
muito mais. Para usar a primeira versão do modelo, denominada avaliação de maturidade do
processo, um contratado respondeu mais de 100 perguntas destinadas a determinar as
práticas reais do empreiteiro. O "grau" resultante foi relatado como uma escala de cinco
níveis, de "1" desenvolvimento ad hoc dependente de indivíduos para "5" (um processo de
desenvolvimento que poderia ser otimizado com base em feedback contínuo). Houve muitos
problemas com o primeiro modelo, conforme descrito por Bollinger e McGowan (Bollinger e
McGowan, 1991), e o SEI desde então revisou sua abordagem. O novo modelo, denominado
avaliação da maturidade da capacidade, baseia-se em práticas-chave que todos os contratados
devem usar. Outras organizações, inspiradas pelo objetivo do SEI, desenvolveram outros
modelos de avaliação, com a esperança de que tal avaliação encoraje a melhoria e permita às
organizações comparar e contrastar os desenvolvedores candidatos.

A noção de avaliação da maturidade do processo é muito atraente e descrevemos no Capítulo

3 como a maturidade do processo pode ser útil para entender o que e quando medir. No
Capítulo 13, analisaremos várias técnicas de avaliação de maturidade, incluindo ISO 9000,
examinando os prós e contras deste tipo de avaliação.

1.4 Resumo

Este capítulo introdutório descreveu como a medição permeia nossa vida cotidiana.
Argumentamos que a medição é essencial para a boa engenharia em outras disciplinas;
Deveria também tornar-se parte integrante da prática de engenharia de software. Em
particular:

• As lições de outras disciplinas de engenharia sugerem que a medição deve desempenhar um

papel mais importante na engenharia de software.

• A medição de software não é um tópico mainstream na engenharia de software. Em vez

disso, é uma coleção diversificada de tópicos marginais (geralmente referidos como métricas
de software) que variam a partir de modelos para prever os custos do projeto de software na
fase de especificação para as medidas da estrutura do programa.

• Muito trabalho de métricas de software carece do rigor associado à medição em outras

disciplinas de engenharia.

• As razões gerais para a necessidade de medição de engenharia de software não são

suficientes. Os engenheiros devem ter objetivos específicos e claramente definidos para a
medição.

• Devemos ser ousados em nossas tentativas de medição. Só porque ninguém mediu algum
atributo de interesse não significa que não pode ser medido satisfatoriamente. Criamos a cena
para uma nova perspectiva sobre métricas de software. Para ancorar um programa de
métricas em uma base sólida da teoria das medições, passamos para o próximo capítulo. Esta
base rigorosa nos permitirá implementar uma abordagem científica e efetiva para a
construção, cálculo e adequação das métricas que derivamos.