Sumrio

Captulo 1 - Compreendendo a Dimenso do Software e de Sua Gesto

1.1 - A Dimenso do Software

1.2 - A Dimenso da Gesto do Software
1.3 - A Importncia da Medio do Software

Captulo 2 - Conceitos Fundamentais da Qualidade

2.1 - Origens e Evoluo Histrica da Qualidade

2.2 - Conceitos da Qualidade
2.3 - As Escolas da Qualidade
2.4 - Custos da Qualidade
2.5 - Sistemas da Qualidade Baseados na ISO 9000
2.6 - Os Prmios Nacionais da Qualidade

Captulo 3 - Implicaes dos Conceitos da Qualidade Para o Software

3.1 - O Paradigma da Qualidade do Software

3.2 - Interpretao dos Demais Conceitos da Qualidade

Captulo 4 - Classificao e Mecanismo das Medies em Software

4.1 - Classificao das Medies

4.2 - Mecanismo da Medio em Software

Captulo 5 - O Processo de Desenvolvimento de Software - Base Para Aplicao das

Medies

5.1 - Conceitos Bsicos do Processo de Software

5.2 - Nveis de Medio Conforme os Modelos de Processo

Captulo 6 - Aplicao das Medies no Planejamento de Projetos

6.1 - O Processo de Planejamento de Projetos

6.2 - Tipos e Tcnicas de Estimativas
6.3 - Estimativas Utilizando a Anlise Por Pontos de Funo-FPA
6.4 - Estimativas Utilizando o COCOMO ( Constructive Cost Model)
6.5 - Estimativas Utilizando Regresso Linear

Captulo 7 - Aplicao das Medies no Processo de Desenvolvimento do Software

7.1 - O Processo de Gesto de Projetos

7.2 - O Processo de Inspeo Formal de Software
7.3 - Medies no Processo de Desenvolvimento de Software

Captulo 8 - Aplicao das Medies na Gesto do Produto

8.1 - O Processo de Gesto do Produto

 8.2 - Medies Para a Gesto do Produto
8.3 - Medies Para o Aperfeioamento dos Processos de Planejamento de
Projetos,de Desenvolvimento do Software e Gesto do Produto

Captulo 9 - Gesto do Ambiente de Software

9.1 - Medies Para o Monitoramento do Ambiente

9.2 - Medies Para a Gesto dos Recursos
9.3 - Anlise de Tendncias
9.4 - Anlise de Impacto
9.5 - Anlise de Atributos
9.6 - Modelagem do Ambiente de Desenvolvimento

Captulo 10 - Aplicao das Medies em Decises Econmicas Relativas a

Software

10.1- Deciso de Comprar/Desenvolver Internamente

10.2- Planejamento de Custos de Manuteno Anual de Software
10.3- Anlise de Viabilidade da Utilizao de Inspees do Projeto
10.4- Anlise de Viabilidade da Utilizao de Anlise Essencial
10.5- Anlise de Viabilidade da Utilizao de Projeto Estruturado
10.6- Anlise de Viabilidade da Utilizao da Anlise de Complexidade
10.7- Anlise de Viabilidade da Utilizao da Inspeo de Cdigo

Captulo 11 - Aplicao Estratgica das Medies

11.1- O Processo de Benchmarking

11.2- O Modelo SEI de Certificao da Qualidade em Software
11.3- O Modelo ISO de Certificao da Qualidade em Software
11.4- Melhoria Contnua da Qualidade do Software
11.5 - Avaliao do Acervo de Software

Captulo 12 - Vendendo e Implantando Um Programa de Qualidade de Software

12.1- Planejando a Venda do Programa de Qualidade de Software

12.2- Vendendo o Programa
12.3- Planejamento da Implantao
12.4- Gerenciando a Implantao do Programa
12.5- Manuteno e Melhoria do Programa da Qualidade de Software

Captulo 13 - tica na Utilizao dos Resultados das Medies

13.1- Nveis de Privacidade dos Resultados das Medies

13.2- Regras de Conduta Para a Utilizao das Medies

Captulo 14 - As Novas Responsabilidades dos Gestores de Software

14.1- As Responsabilidades dos Gerentes de Projetos de Software

14.2- As Responsabilidades dos Gerentes de Desenvolvimento
14.3- As Responsabilidades dos Gerentes de Informtica
Captulo 15 - Auto-Avaliao do Estgio de Maturidade de Software

15.1- Auto-Avaliao Conforme o Modelo SEI

15.2- Auto-Avaliao Conforme o Modelo ISO 9000-3
15.3- Verificao das Condies Para a Mudana

Captulo 16 - Coletnea de Estatsticas Relativas ao Software

 1995 by EDITORA ATLAS S.A.
Rua Conselheiro Nbias, 1384 ( Campos Elsios)
01203-904 So Paulo (SP)
Tel.: (011) 221-9144 (PABX)

ISBN 99-999-9999-9

Impresso no Brasil/Printed in Brazil

Depsito legal na Biblioteca Nacional conforme Decreto no. 1.825, de 20 de dezembro de 1907.

TODOS OS DIRETOS RESERVADOS - proibida a reproduo total ou parcial,de qualquer forma

ou por qualquer meio. O Cdigo Penal brasileiro determina, no artigo 184:
DOS CRIMES CONTRA A PROPRIEDADE INTELECTUAL
Violao de direito autoral
--------------
-------------
------------
------------

Dados internacionais de Catalogao na Publicao (CI)

( Cmara Brasileira do Livreo,SP,Brasil)

Fernandes, Aguinaldo Aragon, 1954 -

Gerncia Efetiva de Software Atravs de Mtricas/ Aguinaldo Aragon
Fernandes. So Paulo : Atlas, 1995.

Bibliografia.
ISBN 99-999-9999-9

1.Gerncia 2. Software 3. Mtricas I.Ttulo

99-9999 CDD-999.9999

ndices para catlogo sistemtico:

Este livro dedico a um grupo especial de - amigos para sempre, so eles:

Edison Hernandez
Francisco Carlos da Rosa Ramos
Jos Luiz Carlos Kugler
Luiz Carlos Slavutzki
Marco Antnio de Moraes
Marco Aurlio Subtil
Paulo Jos Mattos
 PREFCIO
Nos ltimos dez anos, desde que me envolvi com as questes de gerenciamento de
projetos de software e aps a realizao de mais de 60 seminrios sobre o tema,
constatei que a to falada crise do software eminentemente gerencial, com razes
culturais, caractersticamente brasileira, onde o pragmatismo e o comportamento
imediatista no tem atingido os objetivos pretendidos . Continuamos sempre a reinventar
a roda e a um custo que os clientes/usurios no esto mais dispostos a pagar.

Atualmente, com a dependncia cada vez maior das organizaes em relao

tecnologia da informao, a gerao de produtos de software com qualidade e a um custo
compensador, torna-se fator crtico de sucesso.

Produtos de software de qualidade so aqueles que efetivamente agregam valor para a

empresa e para os clientes servidos por esta. Isto significa para a empresa, flexibilidade,
reduo de custos de seus processos empresariais, manuteno dos clientes atuais,
criao de novos nichos de mercado, aumento na participao do mercado e
lucratividade.

Este livro pretende estimular os gerentes e engenheiros de software a praticar a gerncia

de projetos e produtos com base em fatos e dados, visando atingir nveis de qualidade
adequados s exigncias dos atuais clientes/usurios a um custo tambm adequado,
apoiando de forma efetiva os esforos da empresa para o aperfeioamento contnuo de
suas operaes.

Apesar de se constituir em uma modesta contribuio, j que o tema tratado vastssimo

e intrigante, procuramos, a partir de um modelo genrico de gesto do software, mostrar
como as mtricas (ou medies) podem ser empregadas, explicitando os principais
momentos das medies e seus objetivos.

Avanamos agora, desde nosso tlimo trabalho sobre Gerncia de Projetos , para
retratar todas as nuances relativas ao gerenciamento do software conforme suas
dimenses, ou seja, planejamento de projetos, processo de desenvolvimento,
planejamento anual de atendimento ao produto, planejamento do atendimento especfico
ao produto (manutenes corretivas, adaptativas e projetos de melhoria), o
monitoramento do prprio atendimento ao produto e a gesto da qualidade,produtividade
e custo do produto enquanto em operao/utilizao.

Adicionalmente introduzimos o conceito de que o ambiente de desenvolvimento de

software (considerando o conjunto de projetos, servios de atendimento e produtos da
instalao), deve ser gerenciado por exceo, atravs de mtricas que do a indicao do
que , a princpio, est fora dos limites de controle.

Fernandes ,Aguinaldo Aragon & Kugler, Jos Luiz Carlos . Gerncia de Projetos de
Sistemas: uma abordagem prtica. Livros Tcnicos e Cientficos S.A. , Rio de Janeiro, 2a.
edio,1990.
A estrutura lgica do livro foi construda com base na nossa experincia e observaes
das prticas de outras organizaes (mdias e grandes) no tocante ao desenvolvimento e
gesto de produtos de software.

A partir disso, estruturamos o livro partindo dos fundamentos bsicos do que significa
Qualidade e o que signfica medir processos para aps, mostrarmos as possibilidades de
aplicao para o gerenciamento operacional, ttico e estratgico do software.

Apesar de tambm possuirmos acentuada bagagem acadmica, utilizamos uma

linguagem simples e objetiva, com amplo apoio bibliogrfico, para que o leitor possa
aprofundar-se posteriormente quanto aos temas tratados.

Estruturamos o livro em 16 captulos os quais podem ser vistos conforme uma diviso de
4 partes fundamentais.

A primeira parte, que vai do captulo 1 ao 5 eminentemente conceitual. Apresenta as

dimenses do software e a importncia da sua medio, os conceitos bsicos universais
sobre a qualidade, o que significam estes conceitos para a realidade da gesto e
desenvolvimento/manuteno do software, quais os nveis de medio necessrios, quais
as medies mais apropriadas, finalizando com o conceito de modelos de processo de
software.

A segunda parte, que vai do captulo 6 ao 11, apresenta a aplicao das medies ao
software, considerando o planejamento de projetos, o desenvolvimento propriamente, o
planejamento do atendimento ao produto, o monitoramento do atendimento ao produto, a
gesto do produto, a gesto do ambiente de software no sentido mais amplo, a aplicao
estratgica das medies e o apoio a processos de tomada de deciso econmicos
relativos ao software.

A terceira parte, que compreende os captulos 12 a 14, apresenta alguns pr-requisitos

importantes para que as medies sejam aplicadas numa organizao, ou seja,
discutimos a forma como um programa de mtricas e qualidade de software pode ser
vendido e estruturado, discutimos sobre as questes ticas e comportamentais acerca do
uso dos resultados das medies e, dentro de um contexto de qualidade, quais as
responsabilidades esperadas dos gerentes de projetos e de desenvolvimento e do
gerente de informtica.

A quarta e ltima parte apresenta alguns auxlios para que o leitor avalie o estgio de
maturidade que a sua organizao de software se encontra, a fim de permitir o
planejamento consistente de melhorias, bem como apresenta um elenco de fatos e
dados ( estatsticas) extrados da experincia de empresas de classe mundial, bem como
de extensivas pesquisas realizadas em pases que se encontram mais maduros
tecnolgicamente.

Produtos de software um termo genrico que usamos ao longo deste livro. Para ns a
finalidade do processo de desenvolvimento a gerao de um produto, independente se
para consumo interno, se para terceiros sob contrato ou se para comercializao em
grande escala.
Esperamos que esta nossa pequena contribuio auxilie efetivamente o leitor a encontrar
caminhos prprios para atingir nveis de excelncia na produo e manuteno de
produtos de software.

Por fim, estamos totalmente abertos para o recebimento de crticas e sugestes e para a
troca de idias e experincias. Para aqueles leitores que desejarem fazer contato eis a
forma: Alameda Franca 386 apto 111, CEP: 01422-010 -So Paulo - SP, Telefax (011)
889-0387.

So Paulo,14/12/94

Aguinaldo Aragon Fernandes

Agradecimentos

Este livro no seria possvel sem a colaborao das seguintes pessoas e

organizao:

Professor Antnio Loureiro Gil, cuja comunho de idias e abordagens validaram

muitos dos conceitos introduzidos no texto;

David Card, Diretor de Mtricas e Processos da CSC, cujos ensinamentos

constituiram-se no grande incentivo para o meu auto-aperfeioamento;

Jaime Roberto Perez Herrera, Gerente Tcnico de Projetos da UNPROJETOS -

SP da CTIS -Informtica e Sistemas Ltda, cuja apurada capacidade de anlise
crtica e lgica foi decisiva para a organizao final do texto;

Murilo Maia Alves, Gerente de Garantia da Qualidade da CTIS - Informtica e

Sistemas Ltda, cujo conhecimento lingustico, que no o meu forte, foi tambm
decisivo para a arrumao semntica e gramatical do texto;

Tereza Cristina Maia Fernandes, minha esposa, amiga , companheira e

colaboradora, cujo profundo conhecimento matemtico, avalizou muitos dos
algoritmos colocados neste texto;

CTIS-Informtica e Sistemas Ltda pelo apoio material dado para a elaborao

desta obra.
Captulo
1
COMPREENDENDO A DIMENSO DO
SOFTWARE E DE SUA GESTO

Apesar da disciplina de software j contar com pelo menos cinquenta anos de progresso ,
a abordagem para o seu desenvolvimento ainda tem se fundamentado em mtodos e
prticas artesanais . Ao contrrio dos que pregam que o desenvolvimento de software
deve ser encarado como um esforo de engenharia, infelizmente no h correspondncia
com a realidade, talvez com rarssimas excees e principalmente em organizaes cuja
finalidade ou negcio o software.

No Brasil em especial, mesmo com o acesso ao que h de mais atual em termos

de ferramentas de desenvolvimento , vivemos eternamente a crise do software, isto :
baixa qualidade, prazos e oramentos ultrapassados e mtodos gerenciais
igualmente empricos.

A nosso ver a crise do software uma crise eminentemente gerencial, que

muitas vezes transcende as responsabilidades dos gerentes de software, pois sem o
patrocnio mudanas, vindo da alta administrao da empresa, dificilmente uma
inovao ou implantao de mtodos de gesto eficazes, bem sucedida.

Entretanto com a importncia econmica cada vez maior atribuda ao software

pelas organizaes, visto ser um dos principais insumos para a competitividade
empresarial e at mesmo de naes, as condies para tratar seu desenvolvimento com
um enfoque de engenharia, comeam a ser estabelecidas. Outro aspecto a contribuir
para isto a rpida disseminao dos conceitos de qualidade, qualidade total e sistemas
da qualidade que se observa pelo mundo , cuja filosofia preconiza o controle dos custos
de no conformidade do processo e do produto.

De acordo com Arthur 1, na rea de software, os custos da m qualidade

podem atingir 50% dos custos totais do desenvolvimento.

Mesmo sem empregar abordagens mais cientficas para o desenvolvimento de

software temos tido sucesso?

bvio que sim , mesmo com as imperfeies introduzidas e entregues aos

usurios temos tido sucesso, porm com um processo cuja tnica apagar incndios ,
a um altssimo custo ( infelizmente no mensurado), considerando todo o ciclo de vida do
software , e a um timing inaceitvel dada a dinmica dos negcios e do mercado.

Toda e qualquer disciplina de engenharia fundamentada em medies.

impossvel imaginar como a Engenharia Civil, Eltrica, a Fsica, a Qumica teriam
progredido sem medies. Elas so a base de qualquer cincia.
 H uma famosa frase de Tom de Marco 2 que diz: You cannot control what
you cannot measure , ou seja, no gerenciamos nada sem as medies necessrias,
at mesmo projetos de software.

Para comearmos a tratar o software sob uma abordagem de engenharia,

necessrio entendermos as caractersticas de sua dimenso e a importncia da medio
para a sua gesto.

1.1 - A Dimenso do Software

Todo e qualquer software desenvolvido, independente de plataforma e

tecnologia, segundo uma sequncia bsica de grandes atividades, denominada de Ciclo
de Vida.

PROJETO PRODUTO

Anlise do Definio Projeto Projeto Construo Teste e Manuteno

Negcio dos Lgico do Fsico do do Sistema Implantao /Melhoria/
Requisi- Sistema Sistema do Sistema Descarte

PROCESSO
Figura 1-1

O desenvolvimento do software ocorre no contexto de um projeto , o qual

executado de acordo com um processo, gerando produtos intermedirios e um
produto final ( release do software ) , o qual deve ser mantido a fim de corrigir defeitos
introduzidos durante o projeto, deve ser melhorado com a incorporao de novas
features e por fim , deve ser desativado, substitudo ou descartado, ao final de sua vida
til.

Projetos de Software

Um projeto de software um esforo no sentido de construir um produto , dentro

de determinadas especificaes, que atenda necessidades dos usurios (clientes) para
que executem processos operacionais e gerenciais de negcios.

Na verdade, um projeto de software a juno de Objetivos + Atividades +

Prazos + Recursos Envolvidos + Riscos e Incertezas.

uma forma de organizao do trabalho que apresenta as seguintes

caractersticas:

um esforo finito, com incio e fim e a cujo trmino pretende-se a entrega,

gerao ou finalizao de um determinado produto, definido a priori;
 um esforo que pode ser subdividido em unidades de trabalho (
fases,etapas, atividades ) que ocorrem em uma sequncia pr-
determinada;

O objetivo, a alocao de recursos e o progresso realizado podem ser

monitorados e avaliados.

Podemos considerar como projetos de software:

Desenvolvimento de Software sob medida ou encomenda

Desenvolvimento de Software - Produto
Desenvolvimento de novas releases do software

No consideramos servios de manuteno espordicos como remover defeitos ,

realizar pequenas adaptaes e adicionar pequenas funcionalidades, projetos de
software, apesar de que os mesmos tambm devem ser gerenciados.

Processo de Software

O processo de software um conjunto de atividades , (numa sequncia pr-

determinada ), mtodos e prticas que so utilizados na produo e evoluo do software.

O processo compreende:

Polticas de desenvolvimento
Procedimentos para o desenvolvimento
Diversas tcnicas e padres para a construo de produtos
Padres de apresentao de produtos intermedirios

O processo define a forma como o projeto executado e, consequentemente,

gerenciado.

O conjunto de atividades , numa sequncia pr-determinada, compem o que se

denomina a arquitetura do processo de software.

A arquitetura do processo , no jargo mais comumente utilizado na rea de

informtica, o que chamamos de metodologia de desenvolvimento.

O processo de software existe em qualquer organizao, independente de seu

nvel de organizao e padronizao. Pode ser um processo sem formalizao ou
altamente padronizado.

Produto de Software

O processo de software tem como resultado um produto (release) que contm

uma srie de atributos derivados dos requisitos e especificaes a fim de atender
necessidades implcitas e explcitas dos usurios (clientes). Estes atributos definem as
caractersticas do produto em termos de desempenho, confiabilidade, eficincia,
usabilidade, nvel de manutenibilidade, nvel de portabilidade e nvel de reutilizao.

O software enquanto produto sofre alteraes, caracterizadas como:

Manuteno corretiva, que compreende:

remoo de defeitos introduzidos pelo projeto

remoo de defeitos introduzidos por manutenes adaptativas
remoo de defeitos introduzidos por melhorias

Manuteno adaptativa, que compreende:

a alterao de determinadas funes do software visando adequ-lo

a requisitos regulatrios ou de legislao

Melhorias no software, que compreendem:

introduo de novas features no software em funo de novos

requisitos dos negcios
introduo de novas features no software em funo de mudana
de tecnologia

Uma nova release do software o somatrio de manutenes adaptativas e de

melhorias.

O desenvolvimento de uma nova release pode ser realizado sob a filosofia de

projeto, ao passo que manutenes corretivas geralmente no.

1.2 - A Dimenso da Gesto do Software

A gesto do software consiste nas aes necessrias para a gesto do projeto, do

ambiente de desenvolvimento, e do produto (release) visando atingir objetivos
previamente estabelecidos no que concerne a produtividade e qualidade e quanto ao
atendimento das necessidades dos usurios ( clientes ).

Gesto do Projeto

As aes necessrias para a gesto do projeto podem ser categorizadas em:

Planejamento do Projeto, que compreende:

Elaborar o escopo preliminar do produto a ser desenvolvido

Elaborar estimativas de prazos, recursos, esforo, custos e
tamanho do produto
Definir o processo de desenvolvimento a ser adotado pelo projeto
Definir a estrutura de organizao do projeto
 Definir os pontos de controle do projeto

Controle do Projeto, que compreende:

Controle da alocao dos recursos

Verificao e validao dos produtos intermedirios
Controle de mudanas no escopo do projeto
Refinamento do planejamento inicial do projeto
Replanejamento do projeto
Acompanhamento da realizao das tarefas conforme planejado
Acompanhamento da realizao oramentria do projeto

Monitoramento do Projeto, que compreende:

Verificar o progresso do projeto

Verificar e avaliar a qualidade dos produtos intermedirios
Verificar e avaliar a produtividade da equipe
Avaliar o projeto em termos financeiros

Gesto do Ambiente de Desenvolvimento de Software

A gesto do ambiente de software consiste em aes relativas a:

Introduzir novos recursos para a gesto e desenvolvimento de software

Avaliar comparativamente a produtividade dos projetos
Avaliar a produtividade do desenvolvimento conforme distintas plataformas
de hardware e software
Avaliar comparativamente, a qualidade dos projetos e produtos
Avaliar as tendncias da produtividade e qualidade
Aperfeioar o processo de desenvolvimento de software
Avaliar o impacto de novos mtodos e tcnicas sobre a produtividade e
qualidade do software
Avaliar os aspectos financeiros do software

Gesto do Produto

A gesto do produto , por sua vez, refere-se a aes relativas a:

Elaborar o planejamento anual das manutenes/melhorias

Avaliar a produtividade das manutenes e melhorias
Avaliar a qualidade do produto ao longo de sua vida til
Avaliar o nvel de atendimento s solicitaes de manuteno
Avaliar os aspectos financeiros do produto

1.3 - A Importncia da Medio do Software

 O objetivo da aplicao da medio de software fornecer aos gerentes e
engenheiros de software um conjunto de informaes tangveis para planejar o projeto,
realizar estimativas, gerenciar e controlar os projetos com maior preciso.

A realidade aponta para a necessidade de medies, visto que:

As estimativas de prazos, recursos, esforo e custo so realizadas com

base no julgamento pessoal do gerente de projeto
A estimativa do tamanho do software no realizada
A produtividade da equipe de desenvolvimento no mensurada
A qualidade dos produtos intermedirios do processo no medida
A qualidade do produto final (release) no medida
O aperfeioamento da qualidade do produto ao longo de sua vida til no
medido
Os fatores que impactam a produtividade e qualidade no so
determinados
A qualidade do planejamento dos projetos no medida
Os custos de no conformidade ou da m qualidade no so medidos
A capacidade de deteco de defeitos introduzidos durante o processo no
medida
No h aes sistematizadas no sentido de aperfeioar continuamente o
processo de desenvolvimento e de gesto do software
No h avaliao sistemtica da satisfao dos usurios (clientes)

Na verdade, a maioria dos projetos e produtos de software so desenvolvidos e

evoludos em bases artesanais , cuja nica preocupao atingir o objetivo de prazo,
negligenciando os atributos de qualidade e financeiro , ou de controle de custos.

Dessa forma, o que temos entregado aos nossos usurios e clientes um

conjunto de cdigo, que executa determinadas funes e defeitos, e o que pior, no
aproveitamos as experincias passadas para aperfeioar o processo de desenvolvimento.

A adoo dos conceitos de engenharia para o desenvolvimento do software

requer:

Um processo de software definido em termos de polticas de

desenvolvimento, procedimentos, padres, mtodos, tcnicas e
ferramentas

Medies relativas atributos do projeto, tais como prazos, recursos,

custos e esforo

Medies relativas atributos do processo, tais como cobertura de testes,

nvel de deteco e remoo de defeitos, nvel de complexidade do projeto,
produtividade

Medies relativas atributos do produto, tais como confiabilidade, nvel de

deteco de defeitos , ndice de manuteno, tamanho do software
 Medies relativas satisfao dos clientes

Sistema de garantia da qualidade, incluindo gerncia de configurao,

planos da qualidade, inspeo formal de software, tcnicas de testes de
sistemas e assim sucessivamente

Com a adoo destes conceitos possvel medir a qualidade e produtividade dos

projetos/processo e do produto, compar-los com metas pr-estabelecidas, verificar
tendncias e fundamentar o aperfeioamento contnuo do processo.

REFERNCIAS

1. ARTHUR,Jay Lowell. Improving Software Quality: an insiders guide to TQM. Wiley &
Sons, New York,1993.

2. DeMARCO, Tom. Controlling Software Projects: management, measurement &

estimation.Yourdon Press, New York,1982.
Captulo
2
CONCEITOS FUNDAMENTAIS DA
QUALIDADE

O objetivo primrio de realizarmos medies no tocante ao desenvolvimento de software

o de obter nveis cada vez maiores de qualidade, considerando o projeto, o processo e
o produto, visando a satisfao plena dos clientes ou usurios, a um custo
economicamente compatvel.

Nossa misso com este livro no estaria completa caso nos eximssimos de
apresentar os conceitos fundamentais da qualidade. Conceitos sobre os quais repousa
todas as iniciativas para a qualidade do software e que permite um melhor entendimento
dos assuntos tratados nos captulos posteriores.

Apesar da qualidade ser um tema vastssimo e excitante, procuramos apresent-

lo de forma sucinta , porm abrangente, discutindo as suas principais nuances e
implicaes para a rea de software.

Antes de apresentarmos os conceitos da qualidade se faz necessrio uma breve

exposio sobre as origens e evoluo histrica da qualidade

2.1 - Origens e Evoluo Histrica da Qualidade

A aplicao da qualidade data de alguns sculos atrs, quando a pessoa que

produzia , inspecionava e vendia um bem, significava uma s. Geralmente era um arteso
que , tendo contato direto com o cliente, especificava facilmente seus requisitos e media
informalmente a satisfao dos mesmos.

Com o desenvolvimento do comrcio, comearam a surgir os intermedirios.

Nesta poca o produtor j no podia determinar com clareza as expectativas e
percepes dos consumidores. Ainda assim era o prprio arteso que realizava a
inspeo da qualidade de seu trabalho.

Esta situao perdurou at o final do sculo 19, quando em funo da revoluo

industrial, a produo em srie e de massa comeou a ser implementada. Neste momento
surgiu o supervisor de equipes de produo, o qual coordenava pessoas que
desenvolviam tarefas similares. O supervisor passou a ser ento o principal elemento do
controle da qualidade, inspecionando o trabalho dos operrios.

Com o esforo de produo exigido pela primeira Guerra Mundial foram criadas
as primeiras funes segregadas com a tarefa especfica de realizar inspeo. A
qualidade passava a ser responsabilidade dessas funes.

A segunda Guerra Mundial , com a produo em larga escala de material blico,

colocou na mo dos inspetores as primeiras ferramentas estatsticas de controle da
qualidade. Comeou-se a realizar inspees com base em tcnicas de amostragem (era
impraticvel a inspeo 100% dos produtos) assim como o controle da conformidade dos
produtos atravs de grficos de controle.

Nesta ocasio as tcnicas estatsticas da qualidade tiveram um grande

desenvolvimento sendo responsvel em parte, pelo esforo de guerra bem sucedido dos
norte-americanos.

Porm a aplicao das tcnicas de controle estatstico da qualidade encontrou no

Japo do ps-guerra, um campo bastante frtil. As foras de ocupao americanas,
visando auxiliar na reconstruo do pas , designaram o Dr. Deming para transmitir o
conhecimento dessas tcnicas aos engenheiros japoneses. Deming considerado como
o pai do milagre japons.

Foi no Japo, durante a dcada de 50, que o controle estatstico da qualidade

experimentou seu maior desenvolvimento.

Na dcada de 60, com o incio da globalizao da economia, e o consequente

aumento do nvel de exigncia por produtos com maior qualidade, introduziu-se a idia de
que a obteno da qualidade nos produtos passava tambm pela qualidade do projeto.
Nascia ento o Controle da Qualidade Total (CQT). Esta idia tambm foi desenvolvida
pelos japoneses.

A implementao do CQT e seu desenvolvimento pelos japoneses transformou, a

partir da dcada de 70 , as bases da competio mundial.

Na dcada de 80, as idias, mtodos e prticas do CQT evoluiram para o que se

denomina de Controle da Qualidade Por Toda a Empresa (Companywide Quality Control),
abrangendo todas as funes da empresa, fornecedores e distribuidores a fim de garantir
a qualidade de produtos e servios conforme requisitos explcitos e implcitos dos
consumidores bem como a Gesto da Qualidade Total (Total Quality Management -TQM).

Somente no incio da dcada de 80 que as principais economias ocidentais

descobriram o motivo do sucesso japons.

Culminando , ao final da dcada de 80, mais precisamente em 1987, foram criadas

as primeiras normas internacionais sobre Sistema da Qualidade, as normas ISO 9000.

A Figura 2-1 mostra graficamente, a evoluo da qualidade.

Deming foi descoberto pelos americanos em 24 de junho de 1980 atravs do programa de

televiso exibido pela NBC entitulado If Japan Can, Why Cant We? produzido por Clare
Crawford-Mason.
 Evoluo da Qualidade
TQCCW
TQC TQM

Controle Estatstico

1980
Inspeo

1960
Supervisor
1937
Operador

1918

1900

Figura 2-1
Evoluo Histrica da Qualidade

2.2 - Conceitos da Qualidade

Apesar da qualidade como disciplina j ser relativamente madura, no existe um

consenso sobre sua definio.

Para tanto apresentaremos o conceito sob a tica de vrias fontes, para que o
leitor possa comparar e criar o seu prprio ou adotar um conceito.

Adicionalmente iremos avanar para tratar dos conceitos relativos Controle da

Qualidade,Garantia da Qualidade,Controle da Qualidade Total e Sistema da Qualidade.

Qualidade

Qualidade a composio total das caractersticas de marketing,

engenharia,fabricao e manuteno de um produto ou servio, atravs das quais o
mesmo produto ou servio, em uso, atender as expectativas do cliente. Armand V.
Feigenbaum 5.

Qualidade a adequao ao uso do ponto de vista do cliente. J.M. Juran 14.

Qualidade a totalidade de requisitos e caractersticas de um produto ou servio

que estabelecem a sua capacidade de satisfazer necessidades implcitas e explcitas .
American Society for Quality Control 1.

Interpretado de forma mais restrita, qualidade significa qualidade do produto.

Interpretado de forma mais ampla, qualidade significa qualidade de trabalho, qualidade de
servio, qualidade de informao, qualidade de processo, qualidade de pessoal, incluindo
operrios, engenheiros, gerentes e executivos, qualidade de sistema, qualidade de
empresa, qualidade de objetivos Kaoru Ishikawa 10.

Um produto ou servio de qualidade aquele que atende perfeitamente, de forma

confivel, de forma acessvel, de forma segura e no tempo certo as necessidades do
cliente Vicente Falconi 4.

Qualidade conformidade com os requisitos Philip B. Crosby 3.

Apesar de no haver uma nica definio, podemos claramente perceber que

quem define a qualidade em termos de necessidades e expectativas implcitas e explcitas
o CLIENTE. Essas necessidades e expectativas formam os requisitos a partir dos quais
os produtos e servios so projetados , os processos de fabricao, marketing ,entrega,
instalao e assistncia tcnica tambm so projetados e realizados.

Entretanto esses requisitos podem evoluir com o tempo. Por isso que nenhuma
empresa pode afirmar que chegou no topo em termos da qualidade. um processo
dinmico e evolutivo.

De acordo com James Teboul 19 na medida em que as expectativas do cliente

so plenamente satisfeitas ou mesmo suplantadas, essas expectativas vo para um
patamar superior e assim indefinidamente. A Figura 2-2 representa este mecanismo.

Figura 2-2
Portanto, para qualquer empresa,a qualidade uma busca contnua.

Controle da Qualidade

Para entendimento da figura, considere as formas circulares como as expectativas do

cliente e as formas quadrilteras como o atendimento dessas expectativas pela empresa.
 O controle da qualidade o conjunto de tcnicas operacionais e atividades que
sustentam a qualidade do produto e servio que satisfar certas necessidades; tambm o
uso de tais tcnicas e atividades American Society for Quality Control 1.

Um sistema de mtodos de produo que produzem economicamente bens ou

servios de boa qualidade atendendo aos requisitos do consumidor. O controle da
qualidade moderno utiliza mtodos estatsticos e chamado frequentemente de controle
estatstico da qualidade Padres Industriais Japoneses .

Praticar um bom controle de qualidade desenvolver, projetar, produzir e

comercializar um produto de qualidade que mais econmico, mais til e sempre
satisfatrio para o consumidor Kaoru Ishikawa 10.

De modo mais prtico, o controle da qualidade envolve tcnicas e atividades

operacionais objetivando o monitoramento de um processo e a eliminao das causas de
desempenho insatisfatrio, de modo a se obter uma eficincia econmica.

Geralmente, o monitoramento do processo realizado atravs de tcnicas

estatsticas a fim de verificar a variabilidade do mesmo. Para a determinao das causas
e sua eliminao so utilizadas as chamadas ferramentas da qualidade

Garantia da Qualidade

Todas as aes planejadas ou sistemticas necessrias para prover confiana

adequada de que o produto ou servio satisfaro necessidades requeridas American
Society for Quality Control 1.

Garantia da qualidade significa garantir a qualidade de um produto para que o

consumidor possa compr-lo com confiana e us-lo por um longo perodo de tempo com
satisfao e confiana Kaoru Ishikawa 10.

A garantia da qualidade tem como finalidade assegurar que todas as atividades

da qualidade (qualidade do projeto,processo,fabricao etc.) esto sendo conduzidas da
forma requerida. Vicente Falconi 4.

Garantia da qualidade a atividade de prover a evidncia necessria para

estabelecer confiana de que a funo da qualidade est sendo efetivamente
desempenhada. Frank M. Gryna 7.

Na indstria em geral, a garantia da qualidade realizada com base em requisitos

pr-determinados para cada fase do processo de produo de um produto, considerando
desde o seu projeto at a assistncia tcnica. Este requisitos so verificveis quanto a
sua adequabilidade e tm possibilidade de produzirem evidncias objetivas. Por exemplo,
tcnicas de especificao de projetos, padro de apresentao de projeto, procedimento

Estas ferramentas so abordadas no captulo 11, onde mostrado sua aplicao na rea
de software.
da passagem do projeto para a engenharia de processo de fabricao, so requisitos
veririficveis quanto ao seu emprego efetivo.

A qualidade garantida atravs de auditorias da qualidade, auditorias de produtos,

auditorias do desenvolvimento de novos projetos, auditorias de processos e assim
sucessivamente.

Este conceito j traz a noo de que as atividades da qualidade no se restringem

a uma rea da empresa, mas so responsabilidade de todos na organizao.

Controle da Qualidade Total

Controle da Qualidade Total envolve a implementao de atividades tcnicas e

gerenciais orientadas para prover qualidade ao cliente como responsabilidade principal da
alta administrao e das principais funes de linha tais como marketing, engenharia,
produo, relaes industriais, finanas e servios, bem como a prpria funo de
qualidade Armand V. Feigenbaum 5.

O Controle da Qualidade Total uma abordagem que tem como princpios

bsicos: (i) qualidade em primeiro lugar - no os lucros a curto-prazo em primeiro lugar;(ii)
orientao para o consumidor - no orientao sobre o enfoque da empresa;(iii) o primeiro
processo o cliente; (iv) usar fatos e dados - utilizao de mtodos estatsticos; (v)
respeito pela humanidade como filosofia da administrao - administrao plenamente
participativa; (vi) gerenciamento por funes cruzadas. Kaoru Ishikawa 10.

O Controle da Qualidade Total regido pelos seguintes princpios bsicos: (I)

produzir e fornecer produtos e/ou servios que atendam concretamente as necessidades
do cliente;(ii) garantir a sobrevivncia da empresa atravs do lucro contnuo adquirido
pelo domnio da qualidade; (iii) identificar o problema mais crtico e solucion-lo pela mais
alta prioridade; (iv) falar, raciocinar e decidir sobre dados e com base em fatos, no com
base na experincia,bom senso ou intuio;(v) gerenciar a empresa ao longo do
processo, focalizando a preveno;(vi) reduzir as disperses nos processos atravs do
isolamento de suas causas fundamentais; (vii) o cliente o rei,no permitir a venda de
produtos defeituosos;(viii) procurar prevenir a origem dos problemas; (ix) nunca permitir
que o mesmo problema se repita pela mesma causa;(x) respeitar os empregados como
seres humanos independentes. Vicente Falconi 4 .

O conceito de Ishikawa , como no poderia deixar de ser, e o do Prof. Falconi,

refletem a abordagem japonesa para Controle da Qualidade Total (CQT), diferentemente
da proposta por Feigenbaum.

O CQT japons, tambm denominado de Controle da Qualidade Total Por Toda a

Empresa (TQCCW) tem como pressuposto a participao de todos na organizao,
independente da posio hierrquica. Ou seja, todos devem ser educados
(permanentemente ) para a melhoria contnua de todos os processos da empresa visando
a reduo ou at mesmo a eliminao das causas de problemas que possam ocasionar
defeitos nos produtos e servios. A viso japonesa de CQT tambm abrange
fornecedores , empresas filiadas e redes de distribuio.
 J a abordagem de CQT proposta por Feigenbaum ( que os japoneses
denominam abordagem ocidental ) enfatiza a existncia de uma rea na organizao
especializada em controle da qualidade.

De acordo com Ishikawa a abordagem ocidental domnio dos especialistas em

controle da qualidade.

Sistema da Qualidade

Um sistema da qualidade uma estrutura de trabalho operacional por toda a

empresa, documentada, integrando procedimentos tcnicos e gerenciais, para orientar a
coordenao das pessoas, das mquinas e da informao da empresa na melhor e mais
prtica forma, a fim de assegurar a satisfao do consumidor e custos econmicos da
qualidade Armand V. Feigenbaum 5.

Estrutura organizacional, as responsabilidades, os procedimentos, processos e

recursos para a implementao da gesto da qualidade ISO 11.

O objetivo de um Sistema da Qualidade, de acordo com a ISO 12, a

especificao dos requisitos para que a empresa demonstre capacidade para controlar os
processos que determinam a aceitabilidade do produto pelo cliente, bem como
preveno e deteco de qualquer no conformidade durante a produo e instalao e
na implementao de meios para prevenir a sua reincidncia.

Mais adiante, nos itens 2.4 e 2.5, so apresentados os Sistemas da Qualidade

representados pelas normas ISO srie 9000 e pelos Prmios Nacionais da Qualidade.

2.2 - As Escolas da Qualidade

Muitos autores e pensadores contribuiram decisivamente para o desenvolvimento

dos conceitos, abordagens, mtodos e prticas relativas qualidade.

A base da disciplina, entretanto, concentra-se nas contribuies dos seguintes

autores:

Deming
Juran
Feigenbaum
Ishikawa
Crosby
Imai
Osada

Visando complementar os conceitos expostos no item anterior, passaremos agora,

a descrever, sucintamente, as contribuies desses autores, que caracterizam as Escolas
da Qualidade.

Deming

A abordagem de Deming 17 baseia-se em 4 aspectos principais, quais sejam:

 Os 14 Pontos de Deming
A Teoria do Saber Profundo
A Reao em Cadeia
O Ciclo de Deming

Este conjunto forma, na verdade, uma linha filosfica para a gesto da qualidade,
que em essncia uma nova maneira de encarar a gesto da empresa.

De acordo com Deming, a boa qualidade significa um grau previsvel de

uniformidade e confiabilidade a baixo custo, estando a qualidade adequada ao mercado.

Os 14 Pontos de Deming

Estabelecer a constncia de propsito para melhorar o produto e o servio

Adotar a nova filosofia
Acabar com a dependncia da inspeo em massa
Cessar a prtica de avaliar as transaes apenas com base nos preos
Melhorar permanentemente os processos de planejamento, produo e servio
Instituir o treinamento no trabalho
Instituir a liderana
Afastar o medo
Eliminar as barreiras entre as reas da organizao
Eliminar slogans, exortaes e metas para os empregados
Eliminar as cotas numricas
Remover as barreiras que minam o orgulho do trabalhador
Instituir um slido programa de educao e retreinamento
Agir no sentido de concretizar a transformao

Teoria do Saber Profundo

Conhecimento acerca da variao ( variabilidade dos processos)

Conhecimento da funo perda ( identificar custos da m qualidade)
Conhecimento da filosofia de vencer ou vencer ( cooperao interna e parceria
com fornecedores)
Conhecimento de psicologia (motivaes dos empregados)
Conhecimento acerca da confiabilidade ( do produto)
Teoria do conhecimento ( usar teoria e experincia conjuntamente)

A Reao Em Cadeia

MELHORIA DA MELHORIA DA
QUALIDADE PRODUTIVIDADE

REDUO DE PREOS MAIS

CUSTOS BAIXOS

CONQUISTA DE PERMANNCIA
MERCADOS NO NEGCIO

EMPREGOS RETORNO DO
INVESTIMENTO
 Figura 2-3

O Ciclo de Deming

O Ciclo de Deming, mais conhecido como PDCA uma abordagem para a

gesto de processos. Pode ser utilizado tanto para a manuteno de um
processo como para a sua melhoria.

PDCA significa: Plan ou planejamento que consiste no estabelecimento de

metas da qualidade e a definio das estratgias para alcan-las; Do ou
execuo que consiste na realizao da tarefa como prevista no plano,bem
como a coleta de dados para a anlise do processo; Check ou verificao
que consiste na anlise propriamente dita do resultados da execuo da
tarefa; e Action ou ao corretiva que consiste na determinao de
contramedidas para diminuir a variabilidade do processo ou eliminar causas
dos problemas.

O ciclo PDCA representado por um crculo como se estivesse em rotao

no sentido horrio , demonstrando a necessidade de rod-lo
indefinidamente, melhorando o processo continuamente.

Deming considerado o pai da qualidade. Ao lado de Frederick Taylor, foi

a pessoa que mais contribuiu para o desenvolvimento dos mtodos de
trabalho no ambiente industrial neste sculo.

O sucesso japons na conquista de mercados com produtos inovadores,

baratos e de boa qualidade se deve, fundamentalmente, aos ensinamentos
de Deming.

A P

C D
 Figura 2-4
O Ciclo de Deming

Juran

A grande contribuio dada por Juran 13 foi a famosa trilogia, na qual os

componentes bsicos da gesto da qualidade constituem-se em:

Planejamento da Qualidade
Controle da Qualidade
Melhoria da Qualidade

Resumidamente esta abordagem contempla:

Planejamento da Qualidade

a atividade de desenvolvimento de produtos e processos necessrios

para atender s necessidades dos clientes, envolvendo:

Determinao sobre quem so os clientes

Determinao das necessidades dos clientes
Desenvolvimento das caractersticas de produtos que respondam s
necessidades dos clientes
Desenvolvimento dos processos que sejam capazes de produzir
essas caractersticas de produtos
Transferncia dos planos resultantes s foras operacionais

Controle da Qualidade

Avaliar o desempenho da qualidade real

Comparar o desempenho real com as metas da qualidade
Atuar nas diferenas

Melhoramento da Qualidade

Consiste na elevao do desempenho da qualidade a nveis inditos e

contempla os seguintes passos:

Estabelecer a infra-estrutura necessria para assegurar um

melhoramento da qualidade anual
Identificar as necessidades especficas para melhoramento - os
projetos de melhoramento
Para cada projeto estabelecer uma equipe que tenha claramente a
responsabilidade de fazer com que o projeto seja bem-sucedido
Fornecer os recursos, motivao e treinamento necessrios s
equipes para diagnosticar as causas, estimular o estabelecimento
de uma soluo e estabelecer controles para manter ganhos
 Juran tambm considerado, juntamente com Deming, como responsvel por
introduzir, no Japo, onde esteve pela primeira vez em 1954, os conceitos de Gesto da
Qualidade.

Feigenbaum

Feigenbaum 5 contribuiu para o detalhamento do conceito de controle da

qualidade e na determinao das principais funes de CQ para obteno da qualidade
desejada pelo cliente.

Seu enfoque compreende o controle da qualidade em cada etapa do ciclo do

produto na empresa, agrupando estas etapas em 4 principais funes, ou seja:

Controle de Novos Projetos

Esta funo envolve o estabelecimento e especificao do custo da

qualidade, da qualidade do desempenho, da qualidade da segurana e da
qualidade da confiabilidade do produto requerido, visando a satisfao do
cliente, incluindo a eliminao ou localizao das possveis fontes de
problemas de qualidade antes do incio efetivo da produo.

Controle de Recebimento de Material

Esta funo envolve o recebimento e armazenamento, no nvel mais

econmico da qualidade, daquelas partes cuja qualidade tem conformidade
com os requisitos de especificao, com nfase na responsabilidade total
do fornecedor.

Controle do Produto

Esta funo envolve o controle de produtos na fonte da produo e atravs

de servios de campo, de forma que as especificaes de qualidade
possam ser corrigidas antes que produtos defeituosos ou no conforme
sejam fabricados, e que os servios possam ser mantidos no campo para
assegurar proviso integral qualidade para o cliente.

Estudos de Processos Especiais

Esta funo envolve investigaes e teste para localizar as causas de

produtos no conformes, para determinar a possibilidade de aperfeioar as
caractersticas da qualidade e para assegurar que o aperfeioamento e as
aes corretivas sejam permanentes e completas.
 Venda de Produtos
Controle de
Engenharia do Produto Novos Pro-
jetos
Planejamento do Processo

Aquisio de Material

Controle de
Recebimento e Inspeo de Material
Recebimento
de Material
Fabricao de Partes e Produtos
Estudos de
Processos
Inspeo e Testes de Produtos Especiais

Expedio dos Produtos

Controle
do
Instalao e Assistncia Tcnica Produto

Figura 2-5
Modelo de TQC de Feigenbaum

Ishikawa

Ishikawa 10 foi o grande divulgador dos ensinamentos de Deming e Juran no

Japo.

Expandiu os conceitos de controle e gesto da qualidade, criando o que le

denominou de Controle da Qualidade Total ( CQT) ao estilo japons.

A essncia do CQT preconizado por Ishikawa a participao de todos na

organizao para a melhoria da qualidade. Por isso tambm denominado de Controle
da Qualidade por Toda a Empresa.

Um dos instrumentos bsicos criados com o incentivo de Ishikawa para o Controle

da Qualidade Total por Toda a Empresa foi o Crculo de Controle da Qualidade(CCQ) . O
CCQ um grupo informal formado por operrios, supervisores e engenheiros, com a
finalidade de melhorar a qualidade de um processo especfico, melhorar as condies de
segurana, melhorar o ambiente de trabalho e assim sucessivamente.

Outra contribuio foi o diagrama de causa e efeito ( tambm chamado de

diagrama espinha de peixe ou diagrama de Ishikawa) para a anlise de causas de
problemas.

Para Ishikawa so 5 os fatores que contribuem para a variabilidade nos processos,

os chamados 5 Ms: Material, Man, Machine, Measure, Methods. Atualmente foi
incorporado mais um fator, o Environment ou Meio-Ambiente. A seguir dado um
exemplo do diagrama de causa e efeito.
 material mquina medida

EFEITO

pessoas mtodo
Figura 2-6
Diagrama de Ishikawa

Crosby

Philip B. Crosby 3, discpulo de Juran, estruturou sua viso sobre Gesto da

Qualidade conforme os Quatro Absolutos da Qualidade e um plano de implementao
composto por 14 passos.

Os Quatro Absolutos So:

A qualidade se define pela conformidade s exigncias
O sistema da qualidade a preveno
O padro de desempenho zero defeito
A medida da qualidade o preo pago pela no-conformidade

Os quatorze passos para a implementao da Gesto da Qualidade so:

Engajamento da Direo
Equipe de melhoria da qualidade
Medio
Custo da qualidade
Conscincia da qualidade
Ao corretiva
Planejamento para zero defeito
Educao
Dia de zero defeito
Estabelecimento de metas
Remoo da causa do erro
Reconhecimento
Conselhos da qualidade
Faa tudo de novo

Imai
 Masaki Imai 9 contribuiu com a criao da filosofia do KAIZEN que em japons
significa melhoramento.

Assim como as demais Escolas, o KAIZEN proporciona uma linha filosfica para a
melhoria contnua.

Esta linha filosfica constituda pelos seguintes elementos:

Conceito Bsico do KAIZEN

KAIZEN significa melhoramento contnuo, envolvendo todos, inclusive gerentes e

operrios, ou seja, o nosso modo de vida - seja no trabalho, na sociedade ou em
casa - merece ser constantemente melhorado.

Abrangncia do KAIZEN

KAIZEN um conceito de guarda-chuva que abrange a maioria das prticas

japonesas como: (i) orientao para o consumidor; (ii) TQC; (iii) CCQ; (iv) sistema
de sugestes; (v) disciplina no local do trabalho; (vi) manuteno produtiva total;
(vii) kanban; (viii) melhoramento da qualidade; (ix) just-in-time: (x) zero defeitos (xi)
atividades em pequenos grupos; (xii) melhoramento da produtividade; (xiii)
desenvolvimento de novos produtos.

Componentes Bsicos da Administrao

A administrao tem dois componentes principais, a manuteno e o

melhoramento. A manuteno consiste em manter os padres atuais de
tecnologia, administrativos e operacionais. O melhoramento dirigido para
melhorar os padres atuais.

Administrao Orientada Para o Processo

O KAIZEN orientado para o processo e baseia-se fundamentalmente nas

pessoas para os esforos de melhoramento. Por basear-se em pessoas exige
mudana comportamental. A atuao sobre preveno.

Caractersticas do KAIZEN

Os resultados so atingidos a longo-prazo, porm so duradouros; a mudana

gradual e constante; o envolvimento de todos; exige pouco investimento
entretanto com grande esforo para manter; a orientao do esforo so as
pessoas;a avaliao baseada nos resultados das melhorias.

Estabilizao dos Padres Atuais

Antes de iniciar o ciclo PDCA de melhoria contnua necessrio padronizar os

processos atuais.

Osada
 Takashi Osada 16 foi o criador da filosofia de housekeeping ou 5Ss.

Os 5Ss so assim chamados em virtude das palavras japonesas

Seiri,Seiton,Seiso, Seiketsu, Shitsuke que significam respectivamente
organizao, arrumao, limpeza, padronizao e disciplina.

De acordo com Osada a qualidade e produtividade so atingidos pelos 5Ss.

Organizao

Significa distinguir o necessrio do desnecessrio no ambiente de trabalho.

Arrumao

Consiste em colocar as coisas nos lugares certos ou dispostas de forma correta,

para que possam ser usadas prontamente, acabando com a procura de objetos.

Limpeza

Significa manter limpo o local de trabalho.

Padronizao

Significa manter a organizao, a arrumao e a limpeza contnua e

constantemente.

Disciplina

Significa criar ou ter a capacidade de fazer as coisas como deveriam ser feitas;
um processo de repetio e prtica.

2.3 - Custos da Qualidade

Todas as organizaes contabilizam os custos para o desenvolvimento de suas

vrias funes, quais sejam: marketing, pessoal, projeto, finanas, produo, assistncia
tcnica e assim sucessivamente. Geralmente esta contabilizao adota o conceito de
centros de custos, sendo que cada centro de custo representado por um setor, diviso
ou departamento da empresa.

Esta abordagem de contabilizao ainda presente em praticamente todas as

empresas, no permite a contabilizao de custos de atividades multifuncionais
(atividades que permeiam vrias reas da empresa) como o caso dos custos da
qualidade.

At a dcada de 50, os nicos custos relativos atividades da qualidade nas

empresas industriais e que compunham o custo de fabricao eram os relativos a
inspeo e teste.

Atualmente uma nova abordagem para a contabilizao de custos de atividades

multifuncionais o que se denomina custo ABC (Activity Based Costing). Vide a referncia
15 para maiores detalhes sobre o tema.
 Com a introduo das filosofias de controle da qualidade e qualidade total, os
especialistas comearam a perceber que os custos das atividades da qualidade estavam
escondidos em contas de overhead.

Para evidenciar a importncia da qualidade para as empresas e vend-la aos

demais gerentes da companhia e alta administrao, cuja linguagem est sempre
relacionada a dinheiro, os reponsveis pelos primeiros Departamentos de Controle da
Qualidade sentiram a necessidade de estudar os custos relacionados com a qualidade.

Como resultado destes estudos algumas surpresas apareceram 8:

Os custos relacionados com a qualidade eram muito maiores do que

haviam sido mostrados, at ento nos relatrios contbeis comuns. Para a
maioria das empresas estes custos representavam de 20 a 40% do
faturamento anual.

Os custos da qualidade no eram simplesmente o resultado de operaes

de fabricao: as operaes de apoio eram as principais fontes.

A fonte dos custos era resultado de pouca qualidade. Tais custos eram de
fato, evitveis.

Enquanto os custos da m qualidade eram evitveis, no haviam

responsabilidades claras sobre as aes para reduz-los e nem haviam
estruturas para desempenhar essas aes.

Como no passado, ainda h muita confuso a respeito do significado para custos

da qualidade.

Custos da qualidade no so os custos para obter qualidade mas sim os custos

por no ter qualidade, ou seja, encontrar e corrigir o trabalho defeituoso.

Alguns experts , tais como Gryna 8 , definem como custos da qualidade os

custos da m qualidade.

Os custos da qualidade so categorizados como:

Custos de Falhas Internas

So custos associados com defeitos encontrados antes de entregar o

produto ou servio ao cliente.

Custos de Falhas Externas

So custos associados com defeitos encontrados depois da entrega do

produto ou servio ao cliente.

Custos de Avaliao
 So os custos incorridos para determinar o grau de conformidade do
produto ou servio aos requisitos da qualidade, previamente establecidos.

Custos de Preveno

So os custos incorridos para manter os custos de falha interna, externa e

de avaliao a um patamar mnimo.

Esta categorizao representa uma das essncias fundamentais da qualidade, que

o investimento contnuo em preveno para a produo econmica de bens e servios.
Ou seja, a qualidade no est dissociada de baixo custo e, consequentemente,da
lucratividade.

Para finalizar este tpico apresentamos os tipos de custos para cada categoria, de
acordo com Gryna.

Custos de Falhas Internas

Refugo: o trabalho, material , componentes e custos fixos sobre

produto defeituoso que no pode ser economicamente recuperado.

Retrabalho: os custos de corrigir produtos defeituosos para

adequ-lo ao uso.

Anlise de Falhas: os custos de analisar produtos no conformes a

fim determinar as causas da no conformidade.

Refugo e Retrabalho do Fornecedor: os custos de refugo e

retrabalho devido ao recebimento de produtos no conformes dos
fornecedores.

Inspeo 100% : o custo de encontrar unidades defeituosas em um

lote de produtos que contm um nvel inaceitvel de itens
defeituosos.

Reinspeo e teste : os custos da reinspeo e teste de produtos

que foram retrabalhados.

Downgrading : a diferena entre o preo normal de venda e a

reduo do preo devido a razes de qualidade.

Custos de Falhas Externas

Responsabilidades de Garantia : os custos envolvidos em

substituir ou realizar reparos em produtos que ainda encontram-se
em perodo de garantia.

Ajustamento de Reclamaes : os custos de investigar e ajustar

reclamaes justificadas atribudas a produto defeituoso ou
instalao do produto.
 Material Devolvido : os custos associados com o recebimento e
devoluo de produto defeituoso.

Concesses : os custos de concesses feitas ao cliente em virtude

do produto aceito no ter os padres especificados ou no estar
dentro da conformidade adequada para as necessidades de uso.

Custos de Avaliao

Inspeo e Teste de Recebimento : os custos de determinar a

qualidade do produto comprado, atravs da inspeo no
recebimento.

Inspeo e Teste no Processo : os custos de avaliar a

conformao dos requisitos para a aceitao do produto.

Inspeo e Teste Final : os custos de avaliar a conformidade dos

requisitos para a aceitao do produto.

Auditorias da Qualidade do Produto : os custos de realizar

auditorias da qualidade durante o processo ou em produtos.

Manuteno da Exatido dos Equipamentos de Teste : os custos

de manter os equipamentos de medio calibrados.

Servios e Materiais de Inspeo e Teste : os custos de materiais

e suprimentos para o trabalho de inspeo e teste, bem como os
servios.

Avaliao de Estoques : os custos de testar produtos no campo,

armazenados ou em estoque para evitar degradao.

Custos de Preveno

Planejamento da Qualidade : incluem os custos relacionados com

a elaborao de planos da qualidade e procedimentos para
comunicar estes planos a todos envolvidos.

Reviso de Novos Produtos : os custos de engenharia de

confiabilidade e outras atividades relacionadas com qualidade,
associadas com o lanamento de novos projetos.

Planejamento do Processo : os custos de estudos de capacidade

do processo, planejamento das inspees e outras atividades
associadas com o processo de fabricao.

Controle do Processo : os custos de inspeo e teste durante o

processo para determinar o seu status.

Auditorias da Qualidade : os custos de avaliar a execuo de

atividades do plano e sistema da qualidade.
 Avaliao da Qualidade dos Fornecedores : os custos de avaliar
as atividades de qualidade dos fornecedores antes de sua seleo (
auditoria de segunda parte ) ; auditoria das atividades durante o
contrato e esforo de desenvolvimento dos fornecedores.

Treinamento : o custo de preparar e conduzir programas

relacionados qualidade.

2.4 - Sistemas da Qualidade Baseados Nas Normas ISO

Em 1987, a ISO ( International Organisation for Standardization ) com sede em

Genebra, da qual o Brasil participa atravs da ABNT ( Associao Brasileira de Normas
Tcnicas), publicou a srie de Normas 9000 sobre Gesto da Qualidade.

Os principais motivadores para a publicao dessas normas foram:

Os altos custos de auditorias de segunda parte (empresa audita o

fornecedor), devido aos diversos critrios de avaliao e especificao que
as empresas fornecedoras de bens e servios tinham que se submeter
quando eram auditadas por mais de um cliente, refletindo sobre o preo
final do produto para ambas as partes.

A globalizao da economia , exigindo certa uniformidade nos elementos

de garantia da qualidade na produo de bens e servios.

A adoo pelos pases mais desenvolvidos ( Estados Unidos, Inglaterra,

Canad principalmente), de normas especficas relativas a sistemas da
qualidade, anteriores publicao das normas srie 9000.

A srie ISO 9000 ( NB-9000 no Brasil) constitue-se em um conjunto de normas

internacionais para os sistemas da qualidade.

Ela fornece orientaes sobre como estruturar o Sistema da Qualidade da

empresa, de forma que a mesma possa evidenciar a qualidade do seu processo de
produo de bens e servios, demonstrando assim que capaz de suprir as
necessidades dos clientes conforme requisitos previamente estabelecidos.

Atualmente a srie 9000 considerada como barreira tcnica imposta por muitos
pases desenvolvidos , principalmente os da Comunidade Econmica Europia, aos
pases de economia emergente como o caso do Brasil.

Independente deste fato, a adoo por uma empresa de um Sistema da Qualidade

baseado na srie ISO 9000 motivada por:

Imposio Contratual de Um ou Mais Clientes

Neste caso a empresa deve evidenciar ao cliente que mantm poltica e

objetivos da qualidade consistentes e entendidos por todos os seus
colaboradores ( fornecedores, funcionrios, acionistas); possui
 procedimentos relativos aos elementos da norma , documentados e em uso
efetivo, congruentes com a poltica da qualidade.

Alm destes requisitos, a empresa deve submeter-se a auditorias de

terceira parte ( empresa contrata empresa de auditoria de sistemas da
qualidade para obter certificao).

Iniciativa Prpria

Neste caso a empresa visa: reduo de custos de no conformidade, para

aumento da lucratividade; manuteno do nvel de satisfao dos clientes;
melhor competitividade; aumento de participao de mercado.

A srie 9000 composta por um conjunto de normas ( ou famlia ) que pode ser
dividido em normas para fins contratuais e de guias de orientao, conforme mostra a
Figura 2-7.

Para fins de certificao do Sistema da Qualidade, em funo de imposio

contratual , a empresa pode escolher entre a ISO 9001, 9002 e 9003.

A ISO 9001 a mais abrangente e pode ser utilizada por empresas que projetam,
desenvolvem, fabricam, instalam produtos e prestam assistncia tcnica.

A ISO 9002 , menos rigorosa que a 9001, pode ser utilizada por empresas que
devem garantir a produo, instalao e assistncia tcnica ao produto. possvel a
aplicao desta norma a empresas que tambm projetam produtos. Entretanto o seu
Sistema da Qualidade somente abranger o ciclo produo, instalao e assistncia
tcnica. Empresas que somente montam produtos , ou seja, j recebem o projeto pronto
do seu parceiro tecnolgico so exemplos de empresas que podem certificar-se conforme
a 9002.

A 9003, por sua vez, se aplica a situaes onde o fornecedor deve garantir a
capacidade no que se refere a inspeo e ensaios finais. Aplica-se a laboratrios de
inspeo, distribuidores de produtos etc. As certificaes segundo esta norma
representam apenas 4% do total das certificaes que hoje, a nvel mundial, j chegam a
30.000 18.

Em 1994 a srie 9000 foi revisada esclarecendo alguns pontos obscuros em

relao verso de 1987.

Cada norma composta por elementos numerados, os quais especificam o

Sistema da Qualidade.

importante ressaltar que as normas srie ISO 9000 no especificam o como

fazer, mas sim o que fazer. O como fica a cargo da empresa definir.

Para melhor compreenso daremos uma breve viso sobre os 20 elementos do

Sistema da Qualidade conforme a ISO 9001 .

Vide 17 para informaes mais detalhadas acerca das normas srie ISO 9000.
Elemento 4.1 - Responsabilidade da Administrao
Tpicos abordados:

Poltica e objetivo da qualidade

Responsabilidade e autoridade pelas atividades relativas qualidade no
mbito da empresa
Recursos e pessoal para atividades de verificao
Designao do representante da administrao no que concerne
qualidade
Anlise crtica do sistema da qualidade pela administrao

Elemento 4.2 - Sistema da Qualidade

Tpicos abordados:

Manual da qualidade com a estrutura do sistema da qualidade e

procedimentos
Procedimentos consistentes com a poltica da qualidade
Planejamento da qualidade definido e documentado
Planejamento da qualidade consistente com os requisitos do sistema da
qualidade e adequado ao mtodo do fornecedor

Elemento 4.3 - Anlise Crtica do Contrato

Tpicos abordados:

Manuteno de procedimentos para anlise crtica do contrato

Elemento 4.4 - Controle de Projeto

Tpicos abordados:

Planejamento do projeto
Atribuies das atividades de planejamento identificadas
Interfaces tcnicas e organizacionais definidas
Identificao e documentao dos requisitos de entrada do projeto
Considerao de outras legislaes existentes para o projeto
Vinculao dos requisitos de entrada com a anlise crtica do contrato
Documentao dos dados resultantes do projeto
Dados de sada do projeto verificados e validados com os de entrada
Liberao do projeto somente aps a anlise crtica dos dados de sada
Execuo e anlise crtica do projeto
Registro das aes para verificao
Controle das alteraes no projeto

Elemento 4.5 - Controle de Documentos

Tpicos abordados:

Aprovao e emisso de documentos

Controle de documentos externos referenciados no sistema da qualidade
Identificao de documentos obsoletos em uso
Alteraes e modificaes em documentos
Elemento 4.6 - Aquisio
Tpicos abordados:

Avaliao de subfornecedores
Seleo de subfornecedores
Avaliao do sistema da qualidade do subfornecedor
Definio do tipo e extenso do controle
Anlise crtica dos documentos de aquisio
Verificao do produto adquirido pelo comprador

Elemento 4.7 - Produto Fornecido Pelo Comprador

Tpicos abordados:

Manuteno de procedimentos para verificao, armazenagem e

manuteno de produto fornecido pelo comprador

Elemento 4.8 - Identificao e Rastreabilidade de Produto

Tpicos abordados:

Estabelecimento e manuteno de procedimentos para identificao de

produtos durante todo os estgios de produo, expedio e instalao

Elemento 4.9 - Controle de Processo

Tpicos abordados:

Planejamento da produo
Controle das condies de produo
Monitorizao do processo e controle
Aprovao de processos e equipamentos
Critrios de qualidade do trabalho
Controle de processos especiais
Manuteno de equipamentos para assegurar a contnua capabilidade do
processo

Elemento 4.10 - Inspeo e Ensaios

Tpicos abordados:

Inspeo e ensaios de recebimento

Inspeo e ensaios no processo produtivo
Inspeo e ensaios finais
Registros de inspeo e ensaios
Documentao dos testes e resultados
Autoridade para liberao

Elemento 4.11 - Equipamentos de Inspeo, Medio e Ensaios

Tpicos abordados:

Identificao das medies a serem feitas

Identificao, aferio e calibrao de todos os equipamentos de inspeo
e ensaios que possam afetar a qualidade
 Estabelecimento, documentao e manuteno de procedimentos para
aferio e calibrao
Mostrar a situao de aferio de cada equipamento
Demonstrao ao comprador da adequao dos equipamentos de inspeo
e ensaio
Avaliao e documentao dos resultados de inspeo e ensaios
Assegurar condies ambientais para as aferies/calibrao
Assegurar condies adequadas para o manuseio, preservao e
armazenamento dos equipamentos de inspeo e ensaios
Verificao de programas de computador usados para inspeo e ensaios
Manuteno de registros sobre as inspees e ensaios

Elemento 4.12 - Situao da Inspeo e Ensaios

Tpicos abordados:

Identificao da inspeo e ensaio do produto ao longo da produo e

instalao
Definio da autoridade para liberao de produtos conformes
Manuteno de procedimentos referentes ao elemento

Elemento 4.13 - Controle de Produtos No Conformes

Tpicos abordados:

Anlise crtica e disposio de produtos no conformes

Manuteno de procedimentos para impedir que produtos no conformes
sejam usados na produo
Controle de produtos no conformes

Elemento 4.14 - Ao Corretiva

Tpicos abordados:

Investigao de causas de no conformidades e definio de aes

corretivas para prevenir repetio
Controle sobre o andamento das aes corretivas
Implementao e registro de alteraes nos procedimentos em funo das
aes corretivas
Anlise dos dados de no conformidade e de aes corretivas pela
administrao

Elemento 4.15 - Manuseio, Armazenamento, Embalagem e Expedio

Tpicos abordados:

Estabelecimento de mtodos para manuseio que evitem danos

Designao de reas de armazenamento
Controle dos processos de embalagem
Expedio

Elemento 4.16 - Registros da Qualidade

 Tpicos abordados:

Estabelecimento de procedimento para controle dos registros da qualidade

inclusive os eletrnicos
Definio dos tempos de reteno dos registros da qualidade
Disponibilizao para o comprador dos registros da qualidade

Elemento 4.17 - Auditorias Internas da Qualidade

Tpicos abordados:

Implementao de auditoria interna do sistema da qualidade

Documentao das auditorias internas
Acompanhamento e avaliao da eficcia das aes corretivas

Elemento 4.18 - Treinamento

Tpicos abordados:

Estabelecimento e manuteno de procedimentos para identificar as

necessidades de treinamento
Manuteno de registros de treinamento

Elemento 4.19 - Assistncia Tcnica

Tpicos abordados:

Estabelecimento e manuteno de procedimentos acerca de servio ps-

venda

Elemento 4.20 - Tcnicas Estatsticas

Tpicos abordados:

Estabelecimento de procedimentos para identificao de tcnicas

estatsticas
Controle da aplicao das tcnicas estatsticas especificadas

Um dos aspectos principais da evidncia do funcionamento de um Sistema da

Qualidade, conforme a srie 9000, a sua documentao. Cerca de 90% das no
conformidades encontradas por empresas de certificao reside na documentao 18 .

A documentao do sistema da qualidade geralmente especificada em 4 nveis

conforme mostra a Figura 2-8.

MANUAL DA QUALIDADE

MANUAL DE PROCEDIMENTOS

INSTRUES DE TRABALHO

REGISTROS, FORMULRIOS
 Figura 2-8
Documentao do Sistema da Qualidade

Os contedos dos respectivos nveis so:

Manual da Qualidade:

Declarao da Poltica da Qualidade da Empresa

Objetivos da Qualidade
Estrutura da Empresa
Responsabilidades Relativas Qualidade
Representante da Administrao
Anlise Crtica do Sistema da Qualidade
Descrio do Sistema da Qualidade

O Manual da Qualidade ou MQ geralmente contm informaes que

compreendem os elementos 4.1 e 4.2 da norma.

Manual de Procedimentos:

O Manual de Procedimentos deve descrever, para cada um dos elementos,4.3 a

4.20, o processo respectivo em grandes linhas. O detalhe especfico, usualmente
descrito pelas Instrues de Trabalho.

Procedimento de Anlise Crtica de Contrato

Procedimento de Controle de Projeto
Procedimento de Controle de Documentos
Procedimentos de Aquisio
Procedimento de Produto Fornecido Pelo Comprador
Procedimento de Identificao e Rastreabilidade de Produto
Procedimento de Controle de Processo
Procedimento de Inspeo e Ensaios
Procedimento de Equipamentos de Inspeo,Medio e Ensaios
Procedimento de Situao de Inspeo e Ensaios
Procedimento de Controle de Produtos No Conformes
Procedimento de Ao Corretiva
Procedimento de Manuseio,Armazenamento, Embalagem e
Expedio
Procedimento de Registros da Qualidade
Procedimentos de Auditorias Internas da Qualidade
Procedimentos de Treinamento
Procedimentos de Assistncia Tcnica
Procedimentos de Tcnicas Estatsticas

Instrues de Trabalho
 As instrues de trabalho contemplam o detalhamento de um procedimento. Ou
seja, um procedimento pode conter mais de uma Instruo de Trabalho. Por
exemplo, o procedimento sobre Anlise Crtica de Contrato, poderia,
hipoteticamente, referenciar Instrues de Trabalho, tais como:

Elaborao de Propostas Tcnicas

Elaborao de Propostas Comerciais
Controle de Verses de Propostas
Registros de Reunies de Especificao de Requisitos

Registros,Formulrios

Nesta parte da documentao so descritos os registros e formulrios

pertinentes e necessrios ao Sistema da Qualidade. Estes registros e
formulrios podem estar em forma de sistemas informatizados.

A documentao do Sistema da Qualidade condio necessria para que a

empresa se candidate certificao na norma selecionada (9001,9002 ou 9003). A outra
condio que o Sistema esteja efetivamente implementado.

A certificao obtida atravs de uma Auditoria Externa contratada pela prpria

empresa. O objetivo da auditoria o de obter evidncias objetivas da conformidade do
Sistema da Qualidade com a norma. A auditoria realizada por uma empresa
Certificadora, independente, credenciada por um rgo Credenciador.

No Brasil o rgo credenciador o INMETRO. Os rgos credenciadores mais

respeitados no mundo industrializado so o RAB - Registrar Accreditation Board,
americano, o NACCB - National Accreditation Council for Certification Bodies, ingls,
o Standards Council of Canada e RVC , holands.

Conforme o rgo certificador, o certificado de conformidade do Sistema da

Qualidade vlido por at 3 anos, sendo que no decorrer do perodo de validade h
acompanhamento por parte da Auditoria Externa em intervalos de 6 em 6 meses.

As auditorias so conduzidas por um Auditor Lder (Leader Assessor) registrado

nos rgos credenciadores. Periodicamente este registro deve ser revalidado.Esta
revalidao feita em funo da evidncia documentada da participao do Auditor Lder
em auditorias de sistemas da qualidade.

2.5 - Outros Sistemas da Qualidade

Alguns pases, no sentido de promover o desenvolvimento da excelncia

empresarial em termos da Qualidade Total, instituiram Prmios Nacionais da Qualidade.

Descreveremos sucintamente, a seguir, os principais prmios nacionais da

qualidade.
 Estados Unidos - Malcolm Baldrige Award

Instituido pelo governo norte-americano em homenagem a Malcolm Braldrige , ex-

Secretrio do Comrcio no governo Reagan.

Este prmio oferecido s empresas americanas que se destacam em Gesto da

Qualidade. A premiao possui trs categorias: empresas industriais, de servios e
pequenas empresas.

Para receber o prmio, a empresa candidata tem que apresentar um sistema de

Gesto da Qualidade Total o qual avaliado segundo critrios especficos.

Critrios de Avaliao (1992)

1.0 - Liderana
1.1 - Liderana da alta administrao
1.2 - Gesto para a qualidade
1.3 - Responsabilidade comunitria
2.0 - Informao e Anlise
2.1 - Abrangncia e gesto de dados e das informaes sobre qualidade e
desempenho
2.2 - Comparaes com a concorrncia e referenciais de excelncia
2.3 - Dados da empresa: anlise e uso
3.0 - Planejamento Estratgico da Qualidade
3.1 - Processo de planejamento estratgico da qualidade
3.2 - Planejamento da qualidade e desempenho
4.0 - Desenvolvimento e Gesto de Recursos Humanos
4.1 - Gerenciamento de recursos humanos
4.2 - Envolvimento dos funcionrios
4.3 - Educao e treinamento dos funcionrios
4.4 - Desempenho e reconhecimento dos funcionrios
4.5 - Bem-estar e moral dos funcionrios
5.0 - Gesto da Qualidade de Processos
5.1 - Projeto e introduo de produtos e servios
5.2 - Gesto de processos - processos de produo e fornecimento de produtos
5.3 - Gesto de processos - processos de negcio e dos servios de apoio
5.4 - Qualidade dos fornecedores
5.5 - Avaliao da qualidade
6.0 - Resultados Obtidos Quanto Qualidade e s Operaes
6.1 - Resultados obtidos quanto qualidade de produtos e servios
6.2 - Resultados obtidos quanto s operaes da empresa
6.3 - Resultados obtidos quanto qualidade no processo de negcio e em servios
de apoio
6.4 - Resultados obtidos quanto qualidade dos fornecedores
7.0 - Focalizao no Cliente e Sua Satisfao
7.1 - Gesto do relacionamento com os clientes
7.2 - Compromisso com os clientes
7.3 - Determinao da satisfao dos clientes

Vide referncia 17 para maiores detalhes sobre o Prmio Baldrige.

 7.4 - Resultados relativos satisfao dos clientes
7.5 - Comparao da satisfao dos clientes
7.6 - Requisitos e expectativas futuras dos clientes

Japo - Prmio Deming 17

Prmio institudo pela JUSE - Union of Japanese Scientists and Engineers em

1951, em reconhecimento aos trabalhos do Dr. Deming para os esforos de
melhoria da qualidade no Japo.

O Prmio dividido em trs categorias : (1) Prmio Deming para Pessoas

Individual, (2) Prmio Deming de Aplicao do Controle da Qualidade, e (3) Prmio
Deming de Controle da Qualidade para Fbricas.

Os elementos de verificao so descritos a seguir.

Critrios de Avaliao ( 1991)

1.0 - Poltica
1.1 - Polticas para gesto, qualidade e controle da qualidade
1.2 - Mtodo para estabelecer as polticas
1.3 - Justificao e consistncia das polticas
1.4 - Utilizao de mtodos estatsticos
1.5 - Transmisso e difuso de politicas
1.6 - Anlise das polticas e dos resultados alcanados
1.7 - Relao entre as polticas e o planejamento a longo e a curto prazos
2.0 - Organizao e Sua Gesto
2.1 - Explicitao dos limites da autoridade e responsabilidade
2.2 - Adequao das delegaes de autoridade
2.3 - Cooperao entre as divises
2.4 - Comisses e suas atividades
2.5 - Utilizao do pessoal
2.6 - Utilizao de atividades de crculos de controle da qualidade
2.7 - Diagnstico do controle da qualidade
3.0 - Educao e Disseminao
3.1 - Programa de educao e resultados
3.2- Conscincia da qualidade e do controle da qualidade, graus de compreenso
do controle da qualidade
3.3 - Ensino dos mtodos e conceitos estatsticos, e a extenso de sua
disseminao
3.4 - Noo da eficcia do controle da qualidade
3.5 - Educao de empresa relacionada
3.6 - Atividades de crculo de controle da qualidade
3.7 - Sistema de sugesto para melhoria
4.0 - Coleta,Disseminao e Utilizao de Informaes Sobre Qualidade
4.1 - Coleta de informaes externas
4.2 - Transmisso de informaes entre divises
4.3 - Velocidade na transmisso de informaes ( utilizao de computadores)
 4.4 - Processamento de dados, anlise estatstica de informao e utilizao dos
resultados
5.0 - Anlise
5.1 - Seleo de problemas
5.2 - Adequao da abordagem analtica
5.3 - Utilizao de mtodos estatsticos
5.4 - Ligao com tecnologia adequada
5.5 - Anlise de qualidade, anlise de processos
5.6 - Utilizao de resultados analticos
5.7 - Adequabilidade das sugestes de melhoria
6.0 - Normalizao
6.1 - Sistematizao de normas
6.2 - Mtodos de disseminao, reviso e descarte de normas
6.3 - Resultado do estabelecimento, reviso ou revogao de normas
6.4 - Contedos das normas
6.5 - Utilizao de mtodos estatsticos
6.6 - Acmulo de tecnologia
6.7 - Utilizao de normas
7.0 - Controle
7.1 - Sistema de controle da qualidade
7.2 - Itens de controle e pontos de controle
7.3 - Utilizao de mtodos estatsticos de controle
7.4 - Contribuio para os crculos de controle da qualidade
7.5 - Condies reais de atividades de controle
7.6 - Situao do controle
8.0 - Garantia da Qualidade
8.1 - Procedimentos para o desenvolvimento de novos produtos e servios
8.2 - Segurana contra responsabilidade civil do produto
8.3 - Projeto de processo, anlise de processo, controle do processo e melhoria
8.4 - Capacidade do processo
8.5 - Instrumentao, aferio, ensaio e inspeo
8.6 - Manuteno de equipamentos, controle de subcontratao,compras e
servios
8.7 - Sistema de garantia da qualidade e auditoria do sistema
8.8 - Utilizao de mtodos estatsticos
8.9 - Avaliao e auditoria da qualidade
8.10 - Situao real da garantia da qualidade
9.0 - Resultados
9.1 - Medio de resultados
9.2 - Resultados reais em qualidade
9.3 - Resultados intangveis
9.4 - Aes para remoo de resultados
10 - Planejamento Para o Futuro
10.1 - Compreenso do estgio atual e da adequabilidade do plano
10.2 - Medidas para remover defeitos
10.3 - Planos para novos avanos
10.4 - Ligao com planos de longo prazo

Brasil - Prmio Nacional da Qualidade 6

 Institudo pela Fundao Prmio Nacional da Qualidade a partir de 1992. A FPNQ
tem a participao do governo e de empresas e entidades privadas. O PNQ foi projetado
nos moldes do Baldrige Award. Qualquer empresa brasileira pode candidatar-se ao
Prmio.

Os elementos de verificao so descritos a seguir.

Critrios de Avaliao ( 1994 )

1.0 - Liderana
1.1 - Liderana pela alta direo
1.2 - Gesto para a qualidade
1.3 - Responsabilidade comunitria e esprito cvico da empresa
2.0 - Informao e Anlise
2.1 - Abrangncia e gesto dos dados e informaes sobre qualidade e
desempenho
2.2 - Comparaes com a concorrncia e com referenciais de excelncia
2.3 - Dados da empresa: anlise e uso
3.0 - Planejamento Estratgico da Qualidade

3.1 - Processo de planejamento estratgico da qualidade e do desempenho da

empresa
3.2 - Planejamento da qualidade e o do desempenho
4.0 - Desenvolvimento e Gesto de Recursos Humanos
4.1 - Planejamento e gesto de recursos humanos
4.2 - Envolvimento dos funcionrios
4.3 - Educao e treinamento em qualidade
4.4 - Desempenho e reconhecimento dos funcionrios
4.5 - Bem-estar e satisfao dos funcionrios
5.0 - Gesto da Qualidade de Processos
5.1 - Projeto e introduo no mercado de produtos e servios
5.2 - Gesto de processos: processos de produo e fornecimento de produtos e
servios
5.3 - Gesto de processos: processos do negcio e dos servios de apoio
5.4 - Qualidade dos fornecedores
5.5 - Avaliao da qualidade
6.0 - Resultados Obtidos Quanto Qualidade e s Operaes
6.1 - Resultados obtidos quanto qualidade de produtos e servios
6.2 - Resultados obtidos quanto operaes da empresa
6.3 - Resultados obtidos quanto qualidade no processo do negcio e em servios
de apoio
6.4 - Resultados obtidos quanto qualidade de fornecedores
7.0 - Focalizao no Cliente e Sua Satisfao
7.1 - Expectativa dos clientes: presentes e futuros
7.2 - Gesto do relacionamento com os clientes
7.3 - Compromisso com os clientes
7.4 - Determinao da satisfao dos clientes
7.5 - Resultados relativos satisfao dos clientes

Para este autor, empresa brasileira qualquer empresa instalada em territrio nacional,
independente da origem do capital e do seu controle acionrio.
 7.6 - Comparao da satisfao dos clientes

Ao contrrio da ISO, os Prmios Nacionais da Qualidade aqui descritos focalizam

a Gesto da Qualidade Total, bem mais abrangente que o Sistema da Qualidade
preconizado pela srie 9000 de normas.

Atualmente, os Prmios Nacionais tm sido utilizados por muitas empresas para

realizar Benchmarking , que o processo de comparar-se s melhores prticas
gerenciais e operacionais.
O atendimento aos requisitos ou critrios de avaliao desses Prmios indica para
o mercado que a empresa uma operao de classe mundial.

De acordo com a base de dados PIMS - Profit Impact of Market Strategy 2 a

Qualidade a estratgia que mais traz retorno para a empresa. Ela possibilita:

Lealdade mais forte por parte dos clientes

Maior repetio de compras pelos clientes
Menor vulnerabilidade a guerras de preos
Capacidade de obter preos relativos mais elevados sem afetar a
participao no mercado
Custos mais baixos de marketing
Aumentos de participao no mercado
Maior retorno sobre os investimentos e sobre as vendas

REFERNCIAS

1. ASQC, Statistics Division. Glossary and Tables for Statistical Quality Control.
Milwaukee, 2nd edition,1983.

2. BUZZEL,Robert D & GALE, Bradley T. PIMS - O Impacto das Estratgias de Mercado

no resultado das Empresas. Pioneira,So Paulo, 1991.

3. CROSBY, Philip B. Qualidade Investimento. Jos Olympio Editora, Rio de

Janeiro,1984.

4. FALCONI, Vicente Campos. TQC - Controle da Qualidade Total (no estilo japons).
Fundao Christiano Otoni, Belo Horizonte,1992.

5. FEIGENBAUM, Armand V. Total Quality Control. McGraw-Hill, 3rd edition,New

York,1986.

6. FGV. Curso de Gesto da Qualidade Total. So Paulo,1994.

7. GRYNA, Frank M. Quality Assurance. In: Jurans Quality Control Handbook. McGraw-
Hill, 4th edition, New York, 1988.

A base de dados PIMS contm o maior conjunto de informaes estratgicas do mundo

sobre cerca de 3000 unidades de negcio. Avalia o impacto de estratgias empresariais
sobre os resultados da empresas.
8. ______, Frank M. Quality Costs. In: Jurans Quality Control Handbook. McGraw-
Hill, 4th edition, New York, 1988.

9. IMAI, Masaki. KAIZEN: a estratgia para o sucesso competitivo. Instituto IMAM,So

Paulo, 4a. edio, 1988.

10.ISHIKAWA, Kaoru. Controle da Qualidade Total Maneira Japonesa. Editora

Campus,Rio de Janeiro, 1993.

11.ISO -9000: 1987 (E) - Quality Management and Quality Assurance Standards -
Guidelines Selection and Use - International Organization for Standardization.

12.ISO-9001: 1987 (E) - Quality Systems - Model for Quality Assurance in

Design/Development,Production,Installation ans Servicing - International
Organization for Standardization.

13.JURAN, J.M. Juran na Liderana Pela Qualidade: um guia para executivos.

Pioneira/IMAM, So Paulo,1990.

14. JURAN,J.M. Jurans Quality Control Handbook. McGraw-Hill, 4th edition,New

York,1988.

15. NAKAGAWA, Masayuki. ABC - Custo Baseado em Atividade. Atlas,So

Paulo,1994.

16. OSADA, Takashi. Housekeeping - 5Ss : cinco pontos-chaves para o ambiente da

qualidade total. Instituto IMAM,So Paulo,1992.

17.PURI, Subhash C. ISO 9000- Certificao - Gesto da Qualidade Total.Qualitymark

Editora,Rio de Janeiro, 1994.

18.SGS-ICS. Leader Assessor Training. Anotaes do Seminrio, So Paulo, 1994.

Captulo
3
IMPLICAES DOS CONCEITOS
DA QUALIDADE PARA O
SOFTWARE

Talvez uma das reas mais refratrias implementao da qualidade seja a de

informtica e, em especial, as atividades relativas gesto e ao desenvolvimento de
software.

Como observado no primeirto captulo , as prticas nas organizaes evidenciam

a afirmativa acima.

Isto entretanto deve ser visto como motivao e oportunidade para a melhoria
dessas prticas, objetivando a produo de software de qualidade.

Este captulo tem como finalidade discutir a interpretao dos conceitos da

qualidade para a rea de software.

3.1 - O Paradigma da Qualidade do Software

Para a definio do que seja qualidade do software necessrio entendermos os

fatores crticos que podem ser subdivididos em fatores explcitos e implcitos da
qualidade.

Os fatores explcitos normalmente so externados pelo cliente. Lembre-se de

quem define a qualidade o cliente. Esses fatores consistem nas expectativas do cliente.
Abrangem fatores relativos qualidade do projeto/processo , qualidade do produto final e
do atendimento quanto manutenes corretivas, adaptativas e introduo de melhorias
no produto.

Os fatores implcitos dizem respeito aos fatores de qualidade do software, que so

percebidos pelos desenvolvedores ( no pelos clientes) e que constituem em elementos
para atender aos fatores explcitos e principalmente para atender a produo econmica
do software.

Os fatores explcitos e implcitos so:

Geralmente a literatura enfatiza fatores da qualidade relativos exclusivamente ao produto

de software; aqui expandiremos esta noo para englobar a qualidade do projeto e do
atendimento durante a vida til do produto.
 Fatores Explcitos
Tabela 3-1
Fatores Descrio
Prazo do Projeto Prazo desejado pelo cliente ou estabelecido em termos contratuais
Informaes s/progresso Informaes sobre o progresso do projeto disponibilizadas para o
cliente, sua periodicidade; pode ser estabelecido tambm em ter-
mos contratuais
Atendimento funcional Extenso na qual o sistema satisfaz suas especificaes e atinge
os objetivos do usurio
Confiabilidade Extenso na qual o sistema desempenha suas funes requeridas
com preciso
Integridade Extenso na qual o acesso ao sistema ou dados do mesmo por pes-
soas no autorizadas pode ser controlado
Usabilidade Esforo requerido para aprender, operar, preparar entradas e inter-
pretar as sadas do sistema
Retorno s/ o investimento Benefcios econmicos obtidos pelo cliente atravs do sistema
Tempos de atendimento Tempos de atendimento para manutenes/evoluo no produto
requeridos pelo cliente

Fatores Implcitos
Tabela 3-2
Fatores Descrio
Exatido das estimativas Extenso na qual as estimativas do projeto em termos de prazo,
esforo, custo e tamanho do software so atingidas
Eficincia Quantidade de recursos computacionais e de cdigo requeridos
pelo sistema para desempenhar uma funo
Manutenibilidade Esforo requerido para localizar e remover um defeito em um mdu-
lo ou programa do sistema
Testabilidade Esforo requerido para testar um programa ou mdulo para asse-
gurar que o mesmo desempenha a funo designada
Flexibilidade Esforo necessrio para modificar um programa ou mdulo
Portabilidade Esforo requerido para transferir um programa ou mdulo ou o sis-
tema como um todo de uma plataforma de hardware e/ou software
para outra
Reusabilidade Extenso na qual um programa pode ser usado em outras aplica-
es; relacionada ao empacotamento e escopo das funes que o
programa desempenha
Interoperabilidade Esforo requerido para interagir/integrar sistemas entre si
Estabilidade do software Extenso na qual os fatores acima so mantidos ao longo da vida
til do produto de software

Adicionalmente aos fatores da qualidade, h os atributos do software os quais

determinam esses fatores.

Os atributos do software so:

Tabela 3-3
Atributos Descrio
Exatido de Estimativas Atributode gesto do projeto, pelo qual o prazo estimado
de Prazo cumprido ou no, e em que extenso os prazos so atingidos
Exatido de Estimativas Atributo de gesto do projeto, pelo qual o esforo estimado
de Esforo atingido ou no, e em que extenso atingido
Exatido de Estimativas Atributo de gesto do projeto, pelo qual o custo estimado
de Custo atingido ou no, e em que extenso atingido
Exatido de Estimativa Atributo de gesto do projeto, pelo qual a estimativa de tamanho
de Tamanho do Software do software atingida ou no, e em que extenso atingida
Exatido da Estimativa Atributo de gesto do projeto, pelo qual a estimativa de esforo
de Esforo de Retrabalho de retrabalho atingida ou no, e em que extenso atingida
Rastreabilidade Aqueles atributos do software que proporcionam a rastreabilidade
dos componentes desde os requisitos at a implementao, consi-
derando especificaes (documentos de projeto) , cdigo fonte e
executvel
Completeza Aqueles atributos do software que proporcionam a completa imple-
mentao das funes requeridas
Consistncia Aqueles atributos do software que proporcionam uniformidade nas
tcnicas de projeto e implementao empregadas
Exatido Aqueles atributos do software que proporcionam a preciso reque-
rida em clculos e gerao de sadas
Tolerncia a Erros Aqueles atributos do software que proporcionam continuidade da
operao sob condies anormais
Simplicidade Aqueles atributos do software que proporcionam a implementao
de funes da forma mais fcil e compreensvel
Modularidade Aqueles atributos do software que proporcionam uma estrutura de
mdulos altamente independentes
Generalidade Aqueles atributos do software que proporcionam certo grau de
abrangncia das funes desempenhadas
Expansibilidade Aqueles atributos do software que proporcionam a expanso dos
requisitos do armazenamento de dados ou de funes computa-
cionais
Instrumentao Aqueles atributos do software que proporcionam a mensurao de
utilizao ou da identificao de erros
Auto-Descritividade Aqueles atributos do software que proporcionam explanao da
implementao de uma funo
Eficincia da Execuo Aqueles atributos do software que proporcionam a reduo do
tempo de processamento
Eficincia de Armazena- Aqueles atributos do software que proporcionam a minimizao
mento dos requisitos de memria durante a operao
Controle de Acesso Aqueles atributos do software que proporcionam o controle de
acesso ao software e aos dados
Auditoria de Acesso Aqueles atributos do software que proporcionam a auditoria do
acesso ao software e aos dados
Operabilidade Aqueles atributos do software que possibilitam a sua operao
Treinamento Aqueles atributos do software que possibilitam a assimilao das
funes pelos usurios a partir da operao e familiarizao ini-
cial
Tabela 3-3 (Continuao)
Atributos Descrio
Comunicabilidade Aqueles atributos do software que possibilitam interfaces de en-
tradas e sadas
Independncia de Aqueles atributos do software que determinam sua dependncia
Software ao ambiente de software ( sistema operacional,utilitrios etc.)
Independncia de Aqueles atributos do software que determinam sua dependncia
Mquina em relao ao hardware
Comunicao Aqueles atributos do software que proporcionam a utilizao de
protocolos padres e rotinas de interfaces
Padres de Dados Aqueles atributos do software que proporcionam a utilizao de
representaes padres de dados
Conciso Aqueles atributos do software que proporcionam a implementao
de uma funo com uma quantidade mnima de cdigo
Reduo do Custo do Atributos do software que possibilitam a reduo do custo de um
Processo processo de negcio do cliente
Aumento da lucratividade Atributos do software que possibilitam o aumento da lucratividade
do negcio do cliente
Aumento da Participao Atributos do software que possibilitam ao negcio do cliente o au-
do Mercado mento de participao no mercado
Manuteno de Clientes Atributos do software que possibilitam a manuteno dos clientes
Atuais atuais

As Tabelas 3-4 e 3-5 a seguir, caracterizam respectivamente, os fatores explcitos

e implcitos, conforme as dimenses projeto,produto e atendimento, e o seu
relacionamento com os atributos do software.

Tabela 3-4
Fatores Dimenses da Qualidade
Projeto Produto Atendimento
Explcitos Implcitos Explcitos Implcitos Explcitos Implcitos
Prazo do projeto
Informaes s/progresso
Exatido das estimativas
Atendimento funcional
Confiabilidade
Eficincia
Integridade
Usabilidade
Manutenibilidade
Testabilidade
Flexibilidade
Portabilidade
Reusabilidade
Interoperabilidade
Retorno s/investimento
Tempos de atendimento
Estabilidade do sw
Tabela 3-5
Fatores da Qualidade Atributos do Projeto e Produto
Exatido das estimativas Exatido da estimativa de prazo
Exatido da estimativa de esforo
Exatido da estimaiva de custo
Exatido da estimativa de tamanho do software
Exatido da estimativa de esforo de retrabalho
Atendimento funcional Rastrabilidade
Consistncia
Completeza
Confiabilidade Tolerncia a erros
Consistncia
Exatido
Simplicidade
Eficincia Eficincia de uso de memria
Eficincia de execuo
Integridade Controle de acesso
Auditoria de acesso
Usabilidade Operabilidade
Treinamento
Comunicabilidade
Manutenibilidade Consistncia
Flexibilidade Modularidade
Generalidade
Expansibilidade
Testabilidade Simplicidade
Modularidade
Instrumentao
Auto-Descritividade
Portabilidade Modularidade
Auto-Descritividade
Independncia de mquina
Independncia de software
Resusabilidade Generalidade
Modularidade
Independncia de software
Interoperabilidade Modularidade
Comunicao
Comunicabilidade
Retorno s/ investimento Reduo de custo do processo de negcio
Aumento da lucratividade do negcio
Aumento da participao do mercado
Manuteno de clientes atuais
Estabilidade do software Manuteno dos fatores da qualidade especificados, ao longo
da vida til do produto
Adaptado de William Perry 2.
 Como podemos concluir, a determinao do que seja qualidade do software no
algo trivial.

Modernamente existem tcnicas para auxiliar no planejamento da qualidade do

software, tais como o QFD - Quality Function Deployment (tcnica desenvolvida pelos
japoneses) destinada a traduzir em termos tcnicos os fatores da qualidade ou requisitos
explicitados pelos clientes, a fim de incorpor-los no produto e assegurar que isto
acontea.

Estes fatores e requisitos so obtidos de vrias formas, atravs de pesquisas junto

a clientes, grupos de foco e assim sucessivamente.

Em desenvolvimento de software, tcnicas como JAD (Joint Application Design),

servem como meios para determinar o requisitos da qualidade do ponto de vista do
cliente/usurio.

Entretanto, o atingimento de nveis aceitveis de qualidade est subordinado

medio e a comparao dos resultados com padres j determinados pela organizao.

Verificando alguns fatores da qualidade tais como manutenibilidade, testabilidade

e portabilidade cuja medida bsica esforo, ou seja, alocao de homens/hora,
necessrio padres de esforo para determinar se em um projeto a meta de qualidade foi
atingida.

Outra condio bsica a avaliao sistemtica da satisfao do cliente/usurio

com o produto logo aps a sua implantao e a avaliao da satisfao durante o uso
mais prolongado a fim de cotejar se os requisitos foram plenamente satisfeitos (so
rarssimas organizaes de informtica que adotam tal procedimento).

De qualquer forma, o paradigma a resolver que muitas vezes os requisitos dos

clientes e ou usurios so conflitantes com o atingimento de metas da qualidade
referentes ao projeto/processo e ao produto.

O prazo um exemplo tpico. Muito frequentemente so impostos prazos

inexequveis cuja busca de atingimento pela equipe de projeto impacta severamente os
demais fatores implcitos e atributos correspondentes, principalmente aqueles
relacionados com os custos da m qualidade.

No existe, infelizmente, solues de curto-prazo para resolver este paradigma.

Somente atravs de medies relativas ao projeto, processo e produto, aliado
permanente educao do cliente/usurio e dos desenvolvedores de software que
podemos resolver a questo e isto, naturalmente, requer tempo, pacincia, persistncia e
comprometimento.

3.2 - Interpretao dos Demais Conceitos da Qualidade

Vide referncia 1 para maiores detalhes sobre o QFD.

 Neste tpico tentaremos apresentar os conceitos de controle da qualidade,
garantia da qualidade, sistema da qualidade e custos da qualidade, sob a tica do
software, conforme suas dimenses correspondentes.

Controle da Qualidade do Software

Interpretando os conceitos de controle da qualidade como expostos no item 2.2,

podemos considerar a seguinte definio para o software:

Controle da qualidade do software envolve a utilizao de tcnicas e

atividades para o monitoramento dos processos de gesto, desenvolvimento
e manuteno/evoluo do software a fim de verificar causas de
variabilidade, determinar e eliminar causas de no conformidade, de modo a
obter-se eficincia econmica no processo

A base para implementar este conceito constitui-se na:

Existncia de um processo definido de gesto ( metodologia de gesto)

Existncia de um processo definido de desenvolvimento do software
(metodologia de desenvolvimento)
Existncia de um processo definido para a manuteno/evoluo do
software
Fatores da qualidade e atributos do produto e respectivos processos j
selecionados e que devem ser monitorados/controlados

Tecnicamente a aplicao do conceito se d atravs de:

Coleta de dados sobre os eventos que caracterizam ou representam os

fatores da qualidade e atributos do produto e processo
Emprego de ferramentas para determinar causas de no conformidade, tais
como grfico de Pareto, diagrama de causa e efeito
Emprego de mtodos estatsticos, tais como grficos de controle (controle
estatstico do processo)

Estes itens de aplicao sero vistos com maior profundidade nos captulos
posteriores.

Garantia da Qualidade do Software

A garantia da qualidade do software significa garantia da qualidade do processo e

do produto.

Nossa definio :

No captulo 5, o conceito sobre processo de software exaustivamente discutido.

 Garantia da qualidade do software o conjunto de atividades que tem como
finalidade assegurar que a qualidade dos processos de gesto,
desenvolvimento e de manuteno/evoluo esto sendo desempenhadas
conforme requerido, a fim de satisfazer as necessidades explcitas e
implcitas do cliente/usurio com o uso do produto.

Da mesma forma que a definio anterior, a garantia da qualidade para ser

exercida, tambm necessita de processos de gesto, desenvolvimento e
manuteno/evoluo do software definidos, bem como os fatores da qualidade e
atributos correspondentes tambm definidos.

A evidncia da existncia destes elementos so a documentao e os objetos

(componentes de software) que so gerados, numa forma sequencial e logicamente
ordenada ao longo dos respectivos processos.

A obteno desta evidncia desempenhada por atividades de:

Auditoria de processo, que tem como finalidade a verificao da

conformidade de especificaes com os requisitos, conformidade de
utilizao das tcnicas usadas para a contruo dos produtos,
conformidade das especificaes com padres estabelecidos,
conformidade dos mtodos de gesto com o procedimento documentado,
verificao de resultados de testes, verificao dos padres de
documentao, verificao dos procedimentos de inspeo, identificao e
remoo de defeitos e assim sucessivamente

Auditoria do produto, verificando conformidade do software com os

requisitos do cliente/usurio, bem como o atingimento das metas e
objetivos da qualidade

Sistema da Qualidade Relativo ao Software

O sistema da qualidade para o software pode ser definido como:

Uma estrutura de trabalho, documentada, usada por toda a rea de

desenvolvimento e gesto do software, que tem como finalidade a
especificao dos requisitos para que seja demonstrada a capacidade de
controlar os processos de gesto, desenvolvimento e manuteno/evoluo,
bem como prevenir, detectar, remover no-conformidades e eliminar suas
reincidncias nos processos.

Como vimos no captulo 2, a srie 9000 e os Prmios Nacionais da Qualidade so

modelos de Sistemas da Qualidade.

Para a rea de software, h os modelos ISO 9000-3, que a 9001 para software,
e SEI (Software Engineering Institute - Carnegie Mellon University) .

Ambos modelos so discutidos no captulo 11.

 Com base na ISO, um modelo de sistema da qualidade (SQ) para software deve
conter, de forma documentada:

Polticas e objetivos da qualidade

Definio das responsabilidades sobre as atividades da qualidade
Procedimentos de reviso gerencial do SQ
Procedimentos de auditorias do sistema da qualidade
Procedimentos de aes corretivas
Procedimentos para anlise crtica de contrato
Procedimentos para o planejamento do desenvolvimento do software
Procedimentos para o planejamento da qualidade do software
Procedimentos para projeto e implementao do software
Procedimentos para teste e validao do software
Procedimentos para aceitao do software
Procedimentos para replicao, entrega e instalao do software
Procedimentos de manuteno do software
Procedimentos para a gerncia de verses do software
Procedimentos para o controle da documentao
Procedimentos quanto aos registros da qualidade
Procedimentos quanto medio do produto e processo
Procedimentos quanto aquisio
Procedimentos quanto a treinamento

Custos da Qualidade em Software

Considerando a classificao dos custos da qualidade explanados anteriormente,

podemos identificar os custos relativos a software como:

Custos de Preveno

Treinamento
Ferramentas
Mtodos
Padres, polticas e procedimentos
Consultoria externa
Planejamento do desenvolvimento
Planejamento da qualidade
Reunies de equipe para preveno
Prototipao rpida de sistemas
Coleta de dados e anlise de resultados de medies
Anlise de causas de problemas
Garantia da qualidade

Custos de Avaliao

Reviso das especificaes dos requisitos

Reviso das especificaes de projeto
Reviso das especificaes de componentes e mdulos
Reviso e inspeo de cdigo
 Processo de teste, incluindo teste de unidade, teste do sistema, teste do produto,
verificao e validao independente
Beta teste, teste em paralelo
Auditorias dos produtos

Custos de Falhas Internas

Identificao de defeitos pr-release

Remoo de defeitos pr-release
Reinspeo de especificaes
Reinspeo de produto
Reinspeo de cdigo
Realizao de testes adicionais
Utilizao de recursos computacionais para testes adicionais

Custo de Falhas Externas

Identificao de defeitos ps-release

Remoo de defeitos ps-release
Reinspeo de manutenes
Atendimento de campo para remover defeitos

Esperamos que o leitor tenha compreendido, em linhas gerais, o significado da

qualidade para a rea de software.

Com esta compreenso estamos preparados para o detalhamento da medio dos

processos de gesto do projeto, desenvolvimento e manuteno/evoluo do software,
visando o atingimento de objetivos da qualidade.

REFERNCIAS

1. GUINTA,L.R. & PRAIZLER,N.C. The QFD Book, the team approach to solving
problems and satisfying customers through quality function deployment.
AMACON Books, New York,1992.

2.PERRY, William E. Effective Methos of EDP Quality Assurance. In: Handbook of

Software Quality Assurance. Editors: G. Gordon Shulmeyer ans James I.
McManus, 2nd edition, Van Nostrand Reinhold,New York ,1992.
Captulo
4
CLASSIFICAO E MECANISMO
DAS MEDIES EM SOFTWARE

Como vimos anteriormente, a Gesto de Projetos e de Produtos de software somente

atingem um determinado nvel de eficcia e exatido se houverem Medidas que
possibilitem gerenciar atravs de fatos, e o que mais importante, gerenciar os aspectos
econmicos do software, que geralmente so negligenciados em organizaes de
desenvolvimento.

Medidas, na disciplina de Engenharia de Software, so denominadas de Mtricas,

as quais podem ser definidas como mtodos de determinar,quantitativamente, a
extenso na qual o projeto, processo e produto de software tm certos
atributos.Isto inclue a frmula para determinar o valor da mtrica como tambm a
sua forma de apresentao, as diretrizes de utilizao e interpretao dos
resultados obtidos no contexto do ambiente de desenvolvimento de software.1

Um dos aspectos que deve ser observado quando da implementao de iniciativas

de utilizao de mtricas quanto a sua utilidade no contexto de um projeto ou do
ambiente como um todo alm, naturalmente, dos tipos e categorias de mtricas,usurios
das mtricas, audincias (destinatrios dos resultados) e os seus nveis de aplicao.

H vrias caractersticas importantes que esto associadas com o emprego das

mtricas de software. A sua escolha, para fins de gerenciar atravs de fatos e dados,
requer alguns pr-requesitos importantes, quais sejam:

Os objetivos que se pretende atingir com a utilizao das mtricas

Em uma organizao que se dedica ao desenvolvimento de

software,considerando tanto como atividade fim como de suporte a uma
empresa, h vrios objetivos que se buscam atingir, dependendo
obviamente do estgio de maturidade que se encontra essas atividades.

Alguns dos objetivos perseguidos geralmente se enquadram na

seguinte relao:

a) Melhorar a qualidade do planejamento do projeto;

b) Melhorar a qualidade do processo de desenvolvimento;
c) Melhorar a qualidade do produto resultante do processo;
d) Aumentar a satisfao dos usurios e clientes do software;
e) Reduzir os custos de retrabalho no processo;
f) Reduzir os custos de falhas externas;
g) Aumentar a produtividade do desenvolvimento;
h) Aperfeioar continuamente os mtodos de gesto do projeto;
I) Aperfeioar continuamente o processo e produto;
j) Avaliar o impacto de atributos no processo de desenvolvimento tais como
novas ferramentas;
 k) Determinar tendncias relativas a certos atributos do processo.

As mtricas devem ser simples de entender

Devido as diversas audincias (destinatrios dos produtos das medies),

as mtricas devem ser simples de entender e de serem utilizadas para
verificar atingimento de objetivos e para subsidiar processos de tomada de
deciso.

As mtricas devem ser objetivas

As mtricas devem ser objetivas visando reduzir ou minimizar a influncia

do julgamento pessoal na coleta,clculo e anlise dos resultados.

Efetivas no custo

O valor da informao obtido como resultado das medies deve exceder o

custo de coletar,armazenar e calcular as mtricas. A efetividade no custo
deve ser analisada em funo do estgio de maturidade do ambiente de
desenvolvimento que se encontra a empresa no contexto de uma estratgia
de melhoria contnua.

Informativas

As mtricas selecionadas devem propiciar informao que possibilite

avaliar acertos ( ou no) de decises e aes realizadas no passado,
evidenciar a ocorrncia de eventos presentes que subsidiem decises
tempestivas, bem como prever a possibilidade de ocorrncia de eventos
futuros.

4.1 - Classificao das Medies

As mtricas de software podem ser classificadas sob diferentes

formas,considerando o tipo de dado a ser coletado e os objetivos e nvel de utilizao das
mesmas.

Classificao Conforme o Tipo de Medidas

Sob este prisma, podemos considerar as seguintes classificaes 2 :

Objetiva/Subjetiva
Distingue as medies que contam coisas e aquelas que envolvem o
julgamento humano.

Absoluta/Relativa
Medidas absolutas no variam com a adio de novos itens. O tamanho do
software, por exemplo, uma medida absoluta pois independente do
tamanho dos demais. Medidas relativas mudam como mdias de valores
de eventos. Medidas objetivas geralmente so absolutas, enquanto as
subjetivas tendem a ser relativas.
 Explcitas/Derivadas

Medidas explcitas so obtidas diretamente, enquanto as derivadas atravs

de outras medidas explcitas ou derivadas. Por exemplo, homens/ms de
esforo despendidos em uma atividade uma medida explcita, enquanto
produtividade do desenvolvimento em Pontos de Funo por homem/ms
derivada.

Dinmica/Esttica

Medidas dinmicas tm um componente temporal, tal como defeitos

encontrados por ms, ou tendncia da produtividade do desenvolvimento.
Neste caso os valores mudam ao longo do tempo, dependendo de quando
feita a coleta de dados. Medidas estticas, entretanto, permanecem
inalteradas, tal como o esforo total despendido durante o
desenvolvimento.

Preditivas/Explanatrias

Medidas preditivas consistem em estimativas geradas a partir de

transformaes de medidas explcitas/derivadas ou dinmicas/estticas. As
estimativas geralmente so obtidas atravs de transformaes com o uso
de mtodos quantitativos. As medidas explanatrias so produzidas aps a
ocorrncia do evento. Estas medidas geralmente vo alimentar um banco
de dados de mtricas para a gerncia do ambiente de desenvolvimento.

Conforme o Objetivo da Medio

As mtricas podem servir Gesto Estratgica, Ttica e Operacional no que

concerne ao ativo software da empresa.

As medies estratgicas devem possibilitar a realizao de: benchmarking ,

isto , comparar-se com outras empresas, competidoras ou no; melhorias contnuas,
na filosofia de Kaizen, no tocante qualidade de seus mtodos de planejamento de
projetos, gesto do processo de desenvolvimento e gesto do produto e a avaliao
econmica do ativo software.

As medies tticas dizem respeito gesto do ambiente de software em termos

do impacto da introduo de novas ferramentas, mudanas no processo de
desenvolvimento, treinamento de pessoal, anlise de tendncias da produtividade e assim
sucessivamente. Elas so derivadas a partir da agregao das medies de cada projeto
ou produto tomados individualmente.

As medies operacionais, por sua vez, ocorrem a nvel de cada projeto ou

produto de software, visando subsidiar o planejamento de projetos, a gesto do processo
de desenvolvimento, o planejamento do atendimento ao produto de software e prpria
gesto do produto.
 MEDIES ESTRATGICAS

BENCHMARKING MELHORIA CONTNUA AVALIAO

ECONMICA

MEDIES TTICAS
ANLISE DE ANLISE DE ANLISE DE
TENDNCIAS IMPACTOS ATRIBUTOS

MEDIES OPERACIONAIS
GESTO DO PROJETO GESTO DO PRODUTO
PROCESSO
MTRICAS DE PROJETO MTRICAS DO PRODUTO

Figura 4-1
Classificao das Medies Em Software

Tanto as medies operacionais, tticas e estratgicas, fornecem os indicadores

para que os atributos Qualidade e Produtividade sejam determinados, comparados e
assim sucessivamente.

4.2 - O Mecanismo da Medio em Software

Medies Operacionais

Alguns aspectos importantes na aplicao das medies, geralmente tratados de

forma obscura pela literatura tcnica, quanto a determinao de:

Quais as medies que devem ser realizadas no processo de

planejamento de um projeto especfico

Quais as medies realizadas no processo de planejamento de um projeto

especfico que vo subsidiar a gesto do processo de desenvolvimento e do
produto correspondente

Quais as medies que devem ser realizadas no processo de

desenvolvimento de um software especfico que iro realimentar a gesto do
prprio processo

Quais as medies no processo de desenvolvimento de um software

especfico que iro subsidiar a gesto do produto correspondente

Quais as medies que devem ser realizadas no planejamento da gesto

do produto
 Quais as medies que devem ser realizadas durante a
manuteno/evoluo do produto para subsidiar a prpria gesto do produto

Quais as medies que devem ser realizadas no processo de

desenvolvimento de um software especfico para subsidiar o aperfeioamento do
modelo de processo de software e a metodologia de planejamento de
projetos da empresa

Quais as medies que devem ser realizadas no processo de gesto do

produto de um software especfico para subsidiar o aperfeioamento do modelo
de processo de software e na metodologia de planejamento de projetos da
empresa

PROJETO ESPECFICO

PLANEJAMENTO PROCESSO DE GESTO DO

DO PROJETO DESENVOLVIMENTO PRODUTO
DO SOFTWARE

MODELO DE PROCES- MODELO DE PRO- MODELO DE PROCES-

SO DE PLANEJAMEN- CESSO DE DESEN SO DE GESTO DE
TO DE PROJETOS VOLVIMENTO DE PRODUTO
SOFTWARE

MODELOS GENRICOS NVEL EMPRESA

Figura 4-2
Mecanismo da Medio

Este modelo que denominamos de mecanismo da medio focaliza sobre os

momentos em que as medies devem ser realizadas e em que momento devem ser
utilizadas.

A seguir relacionamos as principais medies que ocorrem em cada etapa do ciclo

de vida do software.

Medies Realizadas no Planejamento de Projetos

 No processo de planejamento, a maioria das medidas de natureza preditiva, j
que concentra-se em estimativas. Entretanto o planejamento tambm faz uso de medidas
explanatrias visto que as mesmas compem os padres da instalao quanto a
determinados atributos do processo de desenvolvimento e de gesto do produto.

Ambos tipos de medidas serviro para que o processo de desenvolvimento e de

gesto do produto possam ser controlados, ou seja, comparando-se os atributos dos
respectivos processos com os padres a fim de verificar desvios e tomar aes corretivas.

Medies Realizadas Para o Processo de Desenvolvimento

Estas medies so as estimativas realizadas no processo de planejamento que

vo subsidiar a gesto do processo de desenvolvimento do software. As principais
so:

Estimativa do Tamanho do Software

Estimativa do Prazo do Projeto
Estimativa do Esforo do Projeto
Custo Estimado Para o Projeto
Estimativa do Nmero de Instrues Fontes
Estimativa da Distribuio de Esforo Por Fase do Projeto
Estimativa da Distribuio do Prazo Por Fase do Projeto
Estimativa do Nmero de Defeitos Pr-Release
Estimativa do Nmero de Defeitos Ps-Release
Estimativa do Esforo de Retrabalho
Estimativa do Custo de Retrabalho
Estimativa do Nmero de Profissionais a Serem Alocados ao Projeto
Estimativa do Nmero de Profissionais Por Fase do Projeto

Medio Realizada Para o Processo de Gesto do Produto

Esta medio utilizada quando do planejamento do atendimento do produto do

software. Porm este dado pode mudar visto o comportamento do processo de
desenvolvimento.

Nmero de defeitos ps-release previstos

Medies Utilizadas Pelo Planejamento - Padres da Instalao

Estas medies so de natureza essencialmente explanatrias pois explicam o

comportamento do processo de desenvolvimento e de gesto do produto da
instalao e se constituem nos padres, sobre os quais o controle exercido.

Os padres compem a base de dados de mtricas, os quais devem estar

associados com o tipo do processo de desenvolvimento e com o produto
especfico e muitas vezes com a rea de aplicao do software em virtude da
volatilidade do negcio atendido pelo mesmo.

Por exemplo, no podemos misturar padres do processo de software

caracterizado por maniframe, DB2, CICS e CSP e metodologia estruturada,
com o processo caracterizado como rede local , Windows NT, Visual Basic ,
SQL-Server e metodologia orientada a objeto. Para cada tipo de processo deve
haver um data set especfico de mtricas.
 Somente alguns padres de medies podem ser utilizados independente do tipo
do processo, como por exemplo, padres relativos ao processo de inspeo formal
de software, que abrange taxas de inspeo, tempos mdios de preparao para
inspeo etc.

Em relao ao produto de software em si, os padres so especficos ao software,

ou seja, devemos manter um data set para cada produto. com base nestes
padres que o processo de gesto do produto pode ser realizado.

Os principais padres que devem ser mantidos so:

Exatido da estimativa de prazo

Exatido da estimativa de tamanho
Exatido da estimativa de custo
Exatido da estimativa de esforo
Exatido da estimativa de defeitos pr-release
Exatido da estimativa de defeitos ps-release
Exatido da estimativa de esforo de retrabalho
Exatido da estimativa de custo de retrabalho
Exatido da estimativa de instrues fontes
Exatido da estimativa de nmero de profissionais
Distribuio do esforo por fase
Distribuio do custo por fase
Distribuio dos defeitos por fase
Distribuio dos defeitos por tipo
Origem dos defeitos
Produtividade mdia do desenvolvimento
Custo mdio do ponto de funo de desenvolvimento
Crescimento funcional mdio do software
Taxa de inspeo
Tempo mdio de preparao da inspeo
Densidade mdia de defeitos
Eficincia na remoo de defeitos
Mdia de reutilizao de cdigo
Complexidade do projeto do software
ndice de tecnologia de desenvolvimento do ambiente
ndice de tecnologia de gesto do ambiente
Intensidade de falhas
Custo mdio do ponto de funo de manuteno corretiva
Custo mdio do ponto de funo de manuteno adaptativa
Custo mdio do ponto de funo de projetos de melhoria
ndice de manuteno no software
Densidade mdia de defeitos
Crescimento funcional do software aps a release
Produtividade mdia de manutenes corretivas
Produtividade mdia de manutenes adaptativas
Produtividade mdia de projetos de melhoria
Exatido da estimativa de esforo de atendimento
Exatido da estimativa de custo de atendimento

Medies Realizadas No Processo de Desenvolvimento

As medies realizadas durante o processo de desenvolvimento do software tm

vrios propsitos , ou seja, para a prpria gesto do processo, para o planejamento do
processo de gesto do produto, para o aperfeioamento dos modelos de processo de
planejamento, de desenvolvimento e de gesto do produto utilizados pela instalao.

Quanto ao aperfeioamento dos modelos, as medies realizadas durante o

desenvolvimento vo suprir o nvel ttico de medio.

Aqui se misturam vrios tipos de medio. Temos medies explcitas, derivadas,

dinmicas, estticas, algumas poucas preditivas e a gerao de medidas explanatrias
que iro alimentar o banco de dados de mtricas. Na realidade todas as medidas, aps o
trmino do desenvolvimento do software, tornam-se explanatrias.

Medies Para a Gesto do Prprio Processo de Desenvolvimento

As medies realizadas para a gesto do prprio processo de desenvolvimento

tm como propsito possibilitar a gesto de vrias facetas do projeto, ou seja, a
gesto da qualidade do produto que est sendo desenvolvido, a gesto do
progresso do projeto, a gesto financeira do projeto e a gesto de mudanas.

A seguir esto relacionadas as principais medies que devem ser realizadas.

Progresso na remoo de defeitos

Defeitos restantes
Desvio da estimativa de defeitos
Composio dos tipos de defeitos na fase
Composio de defeitos at a fase
Composio das classes de defeitos
Distribuio de defeitos por mdulo do software
Densidade de defeitos da inspeo
Densidade de defeitos na fase
Densidade de defeitos por mdulo do software
Eficincia da remoo de defeitos do processo de inspeo
Taxa de exame por inspees
Taxa de preparao por inspeo
Tamanho do material inspecionado por inspees
Complexidade do mdulo
Falhas adicionais esperadas para atingir o objetivo de intensidade
Tempo de execuo adicional esperado para atingir o objetivo de
intensidade
Progresso na elaborao de produtos
Acompanhamento fsico do projeto
Estimativa atualizada do tamanho do software
Estimativa atualizada de prazo
Exatido da estimativa de prazo da fase
Estimativa atualizada de esforo
Estimativa atualizada de alocao de recursos
Exatido da estimativa de esforo da fase
Acompanhamento financeiro do projeto
Estimativa atualizada do custo do projeto

Comportamento do custo do retrabalho

Monitoramento de mudanas nos requisitos
Origens de incremento/mudanas nos requisitos

Medies Realizadas Para a Gesto do Produto

So medies de natureza eminentemente preditivas, a fim de auxiliar o
planejamento da gesto do produto.

Falhas esperadas para o software

Intensidade atual de falhas
Estimativa atualizada do nmero de defeitos pr-release

Medies Realizadas Para o Aperfeioamento dos Modelos de

Planejamento de Projetos e do Processo de Desenvolvimento

So medies de natureza explanatrias que iro alimentar o banco de dados de

mtricas da instalao a fim de subsidiar o planejamento e gesto de novos
projetos, conforme a lista apresentada anteriormente.

Estas medies tambm do subsdio ao gerenciamento ttico do ambiente de

software como um todo, indicando, principalmente, tendncias e possibilitando a
anlise de atributos do processo.

Verificao da exatido das estimativas

Tamanho do software entregue
Produtividade do desenvolvimento
Custo do ponto de funo do desenvolvimento
Crescimento funcional do software durante o desenvolvimento
Reutilizao do cdigo
Complexidade do software
Custo da qualidade
Distribuio do esforo por fase
Distribuio dos defeitos por fase
Densidade de defeitos do software
ndice de tecnologia do desenvolvimento empregado
ndice de tecnologia de gesto empregado
Outras medies qualitativas

Medies Realizadas No Processo de Gesto do Produto

O processo de gesto do produto ou da release do software pode ser subdividido

em dois subprocessos, quais sejam: planejamento do atendimento e atendimento.
Este representado pelas manutenes corretivas, adaptativas e projetos de
melhoria do software.

O planejamento do atendimento ainda pode ser subdividido em planejamento

anual e planejamento de atendimento especfico, ou seja, a uma determinada
solicitao de manuteno ou melhoria.

Similarmente aos outros momentos de medio, as medies realizadas na gesto

do produto alimentam o prprio processo , assim como subsidiam o
aperfeioamento dos modelos de planejamento de projetos e desenvolvimento do
software.

Aqui tambm so encontradas medies de natureza explcita, derivada,

dinmica,esttica, preditiva e explanatria.

A diferena em relao ao processo de desenvolvimento que o aspecto temporal

fundamental neste caso, visto que o objetivo principal melhorar continuamente
o software durante a sua vida til.
 Medies Para o Prprio Processo de Gesto

As medies aqui so realizadas durante o planejamento do atendimento e

durante o atendimento especfico.

Estimativa do esforo de atendimento anual

Estimativa do nmero de profissionais para o atendimento anual
Estimativa do custo de atendimento anual
Estimativa dos defeitos do atendimento anual
Esforo esperado de retrabalho
Custo esperado do retrabalho do atendimento
Modelos probabilsticos para atendimento a manutenes corretivas
Estimativa do esforo de manutenes adaptativas
Estimativa do prazo de manutenes adaptativas
Estimativa do nmero de profissionais para a manuteno adaptativa
Estimativa do custo da manuteno adaptativa
Estimativa do nmero de defeitos da manuteno adaptativa
Estimativa do esforo de retrabalho da manuteno adaptativa
Estimativa do custo de retrabalho da manuteno adaptativa
Estimativa do tamanho do projeto de melhoria
Estimativa de esforo do projeto de melhoria
Estimativa de prazo do projeto de melhoria
Estimativa do nmero de profissionais para projetos de melhoria
Estimativa de defeitos do projeto de melhoria
Estimativa de esforo de retrabalho no projeto de melhoria
Estimativa de custo de retrabalho no projeto de melhoria
Monitoramento do backlog
Tempo mdio de atendimento s solicitaes
Tempo mdio do backlogem aberto
Origem das solicitaes
Frequncia do tipo de solicitao
Frequncia de solicitaes por mdulo do software
Produtividade da manuteno corretiva
Monitoramento da densidade de defeitos do produto
Monitoramento da intensidade de falhas do produto
ndice de manuteno do produto
Produtividade de manutenes adaptativas e projetos de melhoria
Custo do ponto de funo de manuteno adaptativa e projetos de
melhoria

Medies Realizadas Para o Aperfeioamento dos Modelos de

Planejamento , do Processo de Desenvolvimento e Gesto do Produto

Eficincia da remoo de defeitos do processo de desenvolvimento

Verificao da exatido das estimativas

Tamanho atual do software

Crescimento funcional relativo do software
Crescimento funcional mdio anual do software
Complexidade atual do software
Custo da qualidade
ndice de tecnologia de manuteno/melhoria empregado
ndice de tecnologia de gesto empregado
 Demais medies qualitativas

Medies Tticas

O objetivo das medies tticas o de auxiliar a gesto do ambiente de software

como um todo.

Para tanto, as informaes armazenadas no banco de dados de mtricas so

transformadas para verificar tendncias, analisar impactos e analisar atributos.

Anlise de Tendncias

A anlise de tendncias tenta prever o comportamento futuro dos valores de

determinados indicadores.

Geralmente utiliza-se de tcnicas estatsticas de previso para realizar a anlise

de tendncias, tais como regresso linear e anlise de sries temporais.

As principais possibilidades de medio so:

Tendncia da produtividade do desenvolvimento por tipo de processo

Tendncia da produtividade da manuteno corretiva
Tendncia da produtividade da manuteno adaptativa
Tendncia da produtividade de projetos de melhorias
Tendncia da densidade de defeitos de software
Tendncia da exatido das estimativas relativas a projeto
Tendncia do custo do ponto de funo de projetos de desenvolvimento
Tendncia do custo do ponto de funo de manuteno corretiva
Tendncia do custo do ponto de funo de manuteno adaptativa
Tendncia do custo do ponto de funo de projetos de melhoria
Tendncia da exatido de estimativas relativas gesto do produto
Tendncia do crescimento funcional de um software especfico
Tendncia dos defeitos pr-release por tipo de processo
Tendncia dos defeitos ps-release por tipo de processo
Tendncia da distribuio do esforo por fase do projeto
Tendncia da distribuio de defeitos por fase

Anlise de Impactos

Neste caso procuramos avaliar o impacto sobre a qualidade e produtividade em

funo de determinados eventos, tais como a introduo de uma nova tecnologia
de desenvolvimento e gesto e assim por diante.

Na realidade, a anlise de impacto feita comparando-se os resultados das

medies antes e depois da introduo da novidade.

Impacto da introduo de CASE

Impacto da introduo de nova metodologia de desenvolvimento
Impacto da introduo de nova metodologia de gesto
Impacto da introduo de inspeo formal de software
Impacto da introduo de nova ferramenta de desenvolvimento
Impacto do aumento do skill do pessoal de desenvolvimento
 Anlise de Atributos

O objetivo da anlise de atributos a comparao das medidas entre plataformas

de desenvolvimento.

Esta anlise de atributos d insights valiosos para determinao de causas e

fatores que levam a melhor qualidade e produtividade de uma plataforma sobre
outra, bem como avaliar a eficcia dos mtodos.

Anlise de produtividade entre plataformas de desenvolvimento

Anlise de produtividade conforme mtodos de desenvolvimento
Anlise de densidade de defeitos por processo de desenvolvimento
Anlise de custos por plataforma e processo de desenvolvimento

Medies Estratgicas

As medies estratgicas, por sua vez, so obtidas a partir de agregaes das

medies operacionais e tticas e visam subsidiar processos de benchmarking , a
melhoria contnua do processo de gesto do ambiente de software e a realizao de
avaliaes financeiras sobre o acervo de software da organizao, inclusive a nvel de
anlise de retorno do investimento.

Benchmarking da produtividade do desenvolvimento

Benchmarking da densidade de defeitos
Benchmarking dos custos de desenvolvimento
Nvel de satistao dos clientes/usurios
Melhoria da qualidade do software
Melhoria da produtividade do desenvolvimento
Acervo de software da empresa em pontos de funo
Acervo de software em pontos de funo por rea da empresa
Custos mdios de desenvolvimento
Valor do acervo de software
Retorno sobre o investimento
Crescimento do market share da empresa
Reduo de custos de processos empresariais

Antes de detalharmos cada tipo de medio necessrio discutirmos a

importncia do processo de software . Este processo condio si ne qua non para
efetivar um Programa de Mtricas dentro da organizao.

REFERNCIAS

1.DASKALANTONAKIS, Michael K. A Practical View of Software Measurement ans

Implementation Experiences Within Motorola. IEEE Transactions on Software
Engineering, Vol 18, no. 11, November 1992.

2.HUMPHREY, Watts . Managing the Software Process. Addison-Wesley,

Reading,MA,1990.
Captulo
5
O PROCESSO DE DESENVOLVIMENTO
DE SOFTWARE - BASE PARA A
APLICAO DAS MEDIES

So trs as condies tcnicas bsicas para se realizar medies operacionais, tticas e

estratgicas, quais sejam:

Um Processo de Software Definido;

O Conceito de Work-Product;
Banco de Dados de Mtricas.

Estas trs condies esto intimamente relacionadas visto que as medies so

feitas no contexto de um Processo de Software, o qual gera produtos intermedirios e
final (Work-Products), sendo que os dados sobre essas medies vo alimentar um
Banco de Dados cuja finalidade permitir o monitoramento/aperfeioamento do processo,
bem como realimentar e subsidiar novos projetos de software. Podemos considerar este
relacionamento como um ciclo evolutivo, como nos mostra a Figura 5-1 a seguir.

PROCESSO DE SOTWARE
WP WP WP WP WP

medio medio medio medio medio medio

BANCO DE DADOS DE
MTRICAS
Realimentao
GERENCIAMENTO/
MONITORAMENTO
Figura 5-1
Ciclo de Medio

Neste captulo nos deteremos em apresentar os conceitos associados a Processo

e Work-Products, visando evidenciar a importncia de ambos para um esforo de
medio, dando base inclusive para a melhor compreenso dos temas que sero
apresentados nos captulos seguintes.

5.1 - Conceitos Bsicos do Processo de Software

 Como j apresentado anteriormente, o ciclo de vida do software, que podemos
considerar como um modelo macro do processo , imutvel e independente de
tecnologia, plataforma, finalidade e criticidade do software.

Planejamento

Concepo

Projeto

Desenvolvimento Projeto

Implantao

Operao Manuteno/Melhoria

Produto
Substituio/Desativao

Figura 5-2
Ciclo de Vida do Software

Qualquer software que formos desenvolver passa, necessariamente, por estas

grandes fases.

H uma analogia bastante significativa com o ciclo de vida de produtos (fsicos)

industriais.

A diferena que a produo de software fruto de interaes intelectuais entre

pessoas, dificultando a definio de atividades rotineiras repetitivas, ao contrrio da
produo de bens industriais, que muitas vezes no requerem a interveno humana e
quando requerem, exigem baixo skill do pessoal , comparado com as exigncias de
conhecimento requeridas dos engenheiros de software.

Este fato um dos principais fatores que concorrem para a dificuldade em

padronizar o processo de software, ou no jargo mais conhecido, da metodologia de
desenvolvimento, bem como sua aplicao efetiva nas organizaes.
 De acordo com Humphrey 2 , ao desenvolvermos software, estamos
tratando com um processo intelectual que deve ajustar-se dinamicamente s
necessidades criativas dos profissionais e suas tarefas.

H portanto, um claro paradigma : como flexibilizar o processo em funo das

necessidades individuais e atender os requisitos da empresa por padronizao?

Outro fator que adiciona maior complexidade que , apesar do macro processo
ser semelhante, as novas tecnologias de hardware , mtodos e abordagens de
desenvolvimento, ambiente orientado a eventos e a finalidade do software, requerem um
conjunto de atividades diferenciadas, ou seja, o detalhamento do macro processo torna-se
especfico conforme a combinao destes fatores.

Entretanto, a padronizao traz benefcios do ponto de vista da gesto do

ambiente de desenvolvimento, quais sejam:

Possibilita a reduo de problemas de treinamento;

Possibilita a melhoria contnua do processo em funo da
experimentao das equipes de projeto;
Possibilita base para as medies selecionadas;
Possibilita base para o planejamento de projetos;
Possibilita base para a gesto do projeto e processo.

Ainda de acordo com Humphrey, as necessidades conflitantes de customizao e

padronizao podem, frequentemente, serem resolvidas pelo estabelecimento de uma
arquitetura do processo, a qual consiste de um conjunto de unidades ( etapas do
processo) , sendo que a customizao obtida incluindo-se etapas especficas conforme
as caractersticas do projeto.

Por exemplo, para qualquer projeto de software h etapas comuns, tais como
Teste e Inspeo ( esta ltima pode ocorrer em vrias fases do desenvolvimento) porm,
ao desenvolvermos um projeto para plataforma mainframe e outro para plataforma
client-server em GUI ( Graphical User Interface), o processo ( ou metodologia) de ambos
ter componentes comuns e especficos.

Toda e qualquer organizao tem, de forma intuitiva ou no, uma arquitetura de

processo, ou seja, ela pode estar normatizada/manualizada ou no. O importante que
haja uma sequncia pr-determinada de atividades, relacionadas entre si, que guie os
desenvolvedores na produo e evoluo do software.

Para fins de medio do processo isto uma condio sine qua non.

Um simples roteiro metodolgico, que evidencie a arquitetura e os produtos do

processo j basta, dependendo bvio, dos objetivos que se pretende atingir com as
medies.

Quanto maior o nvel de detalhamento da arquitetura do processo e do processo

em si, maiores so as possibilidades de aperfeioar a maneira de como o trabalho feito,
antecipar problemas e visualizar alternativas de preven-los ou de resolv-los. Isto a
essncia da gesto do software.
 Neste ponto importante a definio formal de Arquitetura e Processo 2:

Arquitetura do Processo de Software: o arcabouo dentro do qual o

processo de software de um projeto especfico definido

Processo de Software: o conjunto de atividades, mtodos e prticas que

so utilizadas na produo e evoluo do software

Para compreendermos melhor estes conceitos e podermos tambm determinar o

significado de Work-Product necessrio maior detalhamento.

De acordo com o modelo SEI ( Software Engineering Institute) 2 , o processo

de software pode ser definido em trs nveis, quais sejam:

Modelo U : ou universal, que consiste nas polticas de desenvolvimento e

explicita as grandes fases do processo ( do nosso ponto de vista, trata-se
do segundo nvel de abstrao do modelo do processo, sendo o primeiro o
ciclo de vida do software)

Modelo W : ou modelo de trabalho que compreende os

procedimentos,etapas, responsabilidades do processo

Modelo A : ou modelo atmico, o qual define padres e ferramentas de

desenvolvimento, relacionadas aos procedimentos e etapas definidas no
modelo W

A Figura 5-3 mostra a hierarquia dos modelos.

A representao do modelo U caracterizada pela abordagem denominada

Waterfall conforme mostra a Figura 5-4

Observe que tal abordagem um detalhamento do modelo ciclo de vida.

CICLO DE VIDA

MODELO U

MODELO W

MODELO A

Figura 5-3
Nveis dos Modelos do Processo de Software

No captulo11 este modelo apresentado com maior profundidade.

 Viabilidade

Validao

Planos e re-
quisitos
Validao

Desenho do
Produto
Validao

Desenho
Detalhado
Validao

Codificao

Validao

Integrao

Validao

Implementao

Validao

Figura 5-4
Modelo Waterfallde Desenvolvimento de Software

Para fins de gesto, o modelo waterfall no representa o que realmente acontece

durante o desenvolvimento do software.

J os modelos W e A , vistos de forma integrada, possibilitam especificar:

O que deve ser feito ( o objetivo da tarefa)

Como deve ser feito (procedimento, padres e ferramentas)
Quem deve fazer
 Quando deve ser feito ( qual o posicionamento da tarefa na sequncia do
processo)
Que resultados so esperados (produtos a serem gerados)
Quais as medies so apropriadas
Quais os pontos chaves de controle
Quais os critrios de entrada para se iniciar uma tarefa ( critrios que
devem estar plenamente satisfeitos)
Quais os critrios de sada de uma tarefa ( idem observao anterior)
Quais os relacionamentos entre as tarefas, para trs e para frente no
processo ( backward e forward )

A implementao da arquitetura do processo depende desses dois modelos e

pode ser efetivada atravs do que se denomina de Clula , a qual representa uma tarefa
especfica e unicamente identificada.

A Figura 5-5 mostra a representao da clula.

Entrada Tarefa Sada

OUT IN

feedback

Especificaes:

Entrada: as condies a serem atendidas antes do incio da tarefa

Sada : os resultados a serem produzidos e como sero embutidos no
produto da tarefa

Feedback
In : qualquer feedback vindo de outros estgios do processo
Out : qualquer feedback da tarefa para outros estgios do processo

Tarefa : o que deve ser feito, por quem, como e quando, incluindo
padres e procedimentos apropriados, bem como as responsa-
bilidades

Medies:
as medies requeridas da tarefa (atividades,recursos e tempo)
produtos ( nmero, tamanho e qualidade ) e feedback (nmero,
tamanho e qualidade)

Figura 5-5
Clula da Arquitetura de Processo de Software
 Um conjunto logicamente ordenado de clulas constitue a Arquitetura do
Processo.

A Figura 5-6, mostra parte de uma arquitetura hipottica para a construo de um

modelo essencial de sistemas.

001 002 003 004

Modelo Modelo Com- Dicionarizao Especificao
Ambiental portamental dos Modelos dos Processos

005
Inspeo

006 005
Derivao do Inspeo
Modelo Lgi-
co de Dados

Figura 5-6
Arquitetura do Processo

A clula tambm permite a definio de produtos. Se tomarmos o exemplo da

Figura acima, teramos os seguintes produtos:

Modelo Ambiental do Software

Modelo Comportamental do Software
Dicionrio dos Modelos
Processos Especificados
Modelo Lgico Derivado

Apesar de termos colocado dois pontos de inspeo, a clula 005 poderia ocorrer
entre as tarefas 001 e 002, 002 e 003, 003 e 004.

Um dos grandes problemas no gerenciamento de projetos a prtica, nada

recomendvel, de medir o progresso com base apenas na informao de que a tarefa foi
concluda sem a evidncia de um produto.

A nica forma que temos de medir o progresso atravs da evidncia de um

produto, 100% concludo, passvel de inspeo, e que foi construdo considerando
determinadas tcnicas e mtodos e dentro de um padro de apresentao.
 Isto nos d a condio bsica para realizarmos as medies de prazo, esforo,
custo, tamanho, defeitos e assim sucessivamente.

Sem uma arquitetura de processo definida, o desenvolvimento de software

continua sendo um trabalho artesanal ao invs de um trabalho de engenharia.

A importncia de considerarmos produtos que:

A concluso 100% de um produto evidencia o prazo efetivo realizado para

desenvolver a tarefa
Consequentemente, evidencia o esforo e o custo da tarefa
Sem produto inspecionvel, impossvel realizar medies acerca de
defeitos, complexidade do produto, tamanho do software

5.2 - Nveis de Medio Conforme Os Modelos de Processo

De acordo com os modelos de processo, podemos determinar trs nveis de

medio, ou seja:

A nvel do Modelo Ciclo de Vida

A nvel do Modelo Universal
A nvel do Modelo W

A escolha do modelo que servir de base para as medies depender, alm dos
fatores organizacionais normais:

Dos objetivos que se quer atingir com as medies

Do estgio em que se encontra o esforo de medio

Como j comentamos anteriormente, quanto maior o nvel de detalhe do modelo

maior ser a complexidade do esforo de medio porm, maiores tambm sero os
benefcios que podero ser obtidos.

Para organizaes que ainda no determinaram os seus modelos Ws, um bom

ponto de partida pode ser o modelo Ciclo de Vida ou o modelo Universal. Isto tambm
vlido para organizaes que experimentam ambientes distintos conforme a classe/tipo
de software, por exemplo, software bsico, firmware, de controle de processo, de
processamento de imagem, aplicativos comerciais etc.

Esta abordagem foi muito bem sucedida na HP atravs do relato de Grady &
Caswell 1 , cuja estratgia para iniciar o esforo de medio fundamentou-se no
modelo Ciclo de Vida, j que no havia modelos Ws para as diversas classes de
software que a empresa desenvolvia.

O interessante a observar que as medies de projeto e produto,

consequentemente as tticas e estratgicas, j apresentadas no captulo 3, podem ser
empregadas, em sua maioria, desde o mais alto nvel de abstrao.
 A empresa pode, com o passar do tempo, na medida em que ganha experincia,
atinja estgios mais elevados de maturidade e, conforme os resultados obtidos nos nveis
maiores, implementar as medies no nvel mais detalhado que o W.

Neste nvel que os maiores benefcios so conseguidos, principalmente no

tocante melhoria contnua do processo.

A seguir apresentado para os trs Modelos de Processo os possveis pontos de

medio, de acordo com as mtricas bsicas de projeto.

O modelo W a ser apresentado trata-se de um modelo real, adaptado a partir da

metodologia comercial Multimtodo desenvolvida pela Multinformtica 3 .
Tabela 5-1
MODELO DE FASE ETAPA ATIVIDADES MEDIES
PROCESSO 1 2 3 4 5
Ciclo de Vida
Planejamento
Concepo
Projeto
Desenvolvi-
mento
Implantao
Manuteno/
Melhoria
UNIVERSAL
Viabilidade
Planos e Re-
quisitos
Desenho do
Produto
Desenho De-
talhado
Codificao
Integrao
Implementa-
o
W
Estudo 1-Elaborao do 1- Elaborao do Plano de Trabalho
Preliminar Plano de Traba- do
Estudo Preliminar
do Estudo Pre-
liminar
2-Levantamento 2- Levantamento Preliminar
Preliminar
3-Delimitao do 1-Definio de Objetivos
Problema 2-Delimitao do Contexto de Anlise
3-Elaborao da Viso Macro
4-Modelo de Dados Preliminar
5-Elaborao do Diagnstico
Legenda: 1- Prazo 2- Esforo 3- Custo 4- Tamanho 5- Defeitos
MODELO DE FASE ETAPA ATIVIDADES MEDIES
PROCESSO 1 2 3 4 5
W Estudo 4- Elaborao 1- Definio dos Requisitos do Sis-
Preliminar de Proposta tema
de Soluo 2- Elaborao de Alternativas
5- Elaborao 1- Definio da Estratgia de De-
do Plano de senvolvimento
Trabalho 2- Detalhamento de Atividades
Especificao 1-Elaborao 1- Elaborao do Modelo Funcional
do Modelo
Funcional
2-Elaborao 1- Elaborao do Modelo de Dados
do Modelo de
Dados
3-Compatibili- 1- Compatibilizao dos Modelos de
zao dos Mo- Dados e Funcional
delos
4-Integrao 1- Integrao com Modelos Existen-
com Modelos tes
Existentes
5-Elaborao 1- Elaborao do Modelo Operacio-
do Modelo de nal
Implementa- 2- Definio de Interfaces Entre
o Ambientes
3- Definio dos Procedimentos de
Segurana e Controle
4- Especificao da Sequncia de
Processamento On-Line
5- Especificao da Sequncia de
Processamento Batch e Manual
6- Elaborao de Modelos de Entra-
da e Sada
6-Reviso do 1- Reviso do Plano de Desenvolvi-
Plano de Tra- mento
balho 2- Distribuio de
Responsabilidades
Projeto de Im- 1-Projeto de 1- Identificao do Modelo de Dados
plementao Armazena- do Modelo Operacional
mento de Da- 2- Modelo Lgico de Armazena-
dos mento
3- Identificao das Necessidades
de Acesso
4- Projeto Fsico de Banco de Dados
2-Reviso do 1- Reviso do Modelo Operacional
Modelo
Opera-
cional
Legenda: 1- Prazo 2- Esforo 3- Custo 4- Tamanho 5- Defeitos
MODELO DE FASE ETAPA ATIVIDADES MEDIES
PROCESSO 1 2 3 4 5
W Projeto da Im- 3-Projeto de 1- Elaborao do Fluxo Operacio-
plementao Rotinas Ope- nal das Rotinas Automatizadas
racionais 2- Projeto de Programas
4-Projeto de 1-Elaborao do Fluxo Operacio-
Rotinas Ma- nal das Rotinas Manuais
nuais 2- Descrio das Rotinas Manuais
5-Reviso do 1- Reviso do Plano de Desenvol-
Plano de Tra- vimento
balho 2- Distribuio de
Responsabilidades
Implementao 1-Implementa- 1- Codificao de Programas
o de Progra- 2- Preparao do Teste do Progra-
mas ma
3- Teste do Programa
2-Liberao 1- Preparao do Teste da Unidade
da Unidade de de Implementao
Implementa- 2- Teste da Unidade de Implemen-
o tao
3-Elaborao 1- Elaborao da Documentao
da Documen- Operacional
tao Opera-
cional
Implantao 1-Planejamen- 1- Elaborao do Plano da Implan-
to da tao
Implanta-
o 2- Reviso dos Critrios de Homolo-
gao
2- Treinamen- 1- Treinamento
to
3- Execuo 1- Execuo do Sistema
do Sistema
4- Homologa- 1- Homologao da Implantao
o da Implan-
tao
5- Avaliao 1- Avaliao do Desenvolvimento
do Desenvol-
vimento
Legenda: 1- Prazo 2- Esforo 3- Custo 4- Tamanho 5- Defeitos

Para finalizar este captulo, gostaramos de lembrar que, independente do nvel do

Modelo de Processo selecionado, as medies devem ser realizadas com base em
produtos 100% inspecionveis.
REFERNCIAS

1. GRADY,Robert B. & CASWELL,D.L. Software Metrics: Establishing a Company-

Wide Program. Prentice-Hall, Englewood Cliffs, New Jersey, 1987.

2.HUMPHREY,Watts. Managing the Software Process. Addison-Wesley,

Reading,MA,1990.

3.MULTINFORMTICA. Multimtodo, So Paulo.

Captulo
6
APLICAO DAS MEDIES
NO PLANEJAMENTO DO PROJETO

O objetivo principal para aplicar medies no planejamento do projeto est associado aos
seguintes aspectos:

Estimar consistentemente o tamanho previsto do software

Estimar consistentemente o esforo previsto para o projeto
Estimar consistentemente o custo do projeto
Estimar consistentemente outros atributos do processo, tais como nmero de
defeitos esperados

Para tanto necessrio produzir um planejamento do projeto de qualidade, que

significa realizar estimativas confiveis e que possibilite controlar/monitorar o processo de
desenvolvimento visando manter a produtividade nos nveis previstos, remover defeitos
introduzidos no projeto o quanto antes no processo, reduzindo ou mesmo eliminando o
esforo de retrabalho, consequentemente mantendo o oramento sob controle.

A Figura 6-1 exemplifica o ciclo bsico de gesto de projetos.

PADRES

CONTROLE ATUAR SOBRE

OS DESVIOS

PLANEJAMENTO DESENVOLVIMENTO AVALIAO

REALIMENTAO

Figura 6-1
Ciclo Bsico de Gesto de Projetos de Software

Esta representao mostra que o controle deve atuar tanto sobre o planejamento
como o desenvolvimento. Os desvios so determinados por padres a partir do controle
que gera aes para atuar sobre os desvios observados. A avaliao, ao final do projeto,
realimenta o planejamento de novos projetos e assim num crculo indefinido.
 A idia que as medies propiciem a gerao e manuteno de padres de
forma que o controle , a ao sobre os desvios e a avaliao, possam ser exercidos.

6.1 - O Processo de Planejamento de Projetos

Antes de detalharmos a aplicao das medies no processo de planejamento de

projetos preciso compreendermos melhor no que consiste este processo. A Figura 6-2
apresenta o fluxo do processo.

Caracterizar a Definir o Processo Selecionar Perfis Elaborar Estima-

Soluo de de Pessoal tivas
Desenvolvimento

Definir Premissas Definir a Estrutura Elaborar o Orar o Projeto

de Gesto de Organizao do Cronograma
Projeto

Elaborar o Docu-
mento de Plane-
jamento do Proje-
to

Figura 6-2
O Processo de Planejamento de Projetos

Caracterizar a Soluo significa definir o escopo do projeto em termos de

requisitos do cliente/usurio, ou seja, requisitos funcionais e fatores da qualidade,
determinar plataforma tecnolgica de desenvolvimento, bem como os atributos do produto
que devero merecer ateno.

Definir o Processo de Desenvolvimento consiste em determinar o processo que

apoiar o desenvolvimento da soluo em termos de fases/etapas/atividades, padres,
produtos intermedirios esperados, tcnicas a serem utilizadas ,precedncia entre as
atividades etc.

Selecionar os Perfis de Pessoal consiste na determinao das habilidades

tcnicas e gerenciais necessrias para o projeto em funo da natureza e caractersticas
da soluo e do processo definido.

Elaborar Estimativas consiste na elaborao de estimativas de prazo, esforo e

custo do projeto, bem como a estimativa de tamanho do software. Pode-se considerar
tambm nesta etapa a elaborao de estimativas de esforo de retrabalho, custo de
retrabalho, produtividade esperada da equipe a ser alocada e assim sucessivamente.

Definir Premissas de Gesto consiste na determinao do modelo de gesto a

ser adotado em termos de monitoramento do projeto, informaes a serem fornecidas
para o cliente/usurio acerca do progresso do projeto, estabelecimento dos pontos de
controle, local de desenvolvimento, aspectos relativos transferncia de tecnologia,
tratamento de no conformidades, tratamento de mudanas de escopo do projeto a
pedido do cliente/usuario durante o desenvolvimento, gerncia de mudanas, avaliao
de impactos de contingncias sobre o projeto, metas de qualidade a serem atingidas e
assim por diante. Na realidade o estabelecimento das regras do jogo para a conduo
do projeto juntamente com o cliente/usurio.

Definir a Estrutura de Organizao do Projeto consiste na definio de como o

projeto ser organizado em termos de coordenao, quem dever participar da
coordenao, a definio das atribuies, a indicao das funes de apoio ao projeto,
tais como suporte tcnico, garantia da qualidade, apoio administrativo/logstico, suporte
de metodologia, suporte tecnolgico, bem como a participao de tcnicos do
cliente/usurio.

Elaborar o Cronograma consiste no estabelecimento dos prazos para cada

fase/etapa/atividade do projeto, conforme o processo de desenvolvimento definido.
Geralmente a cronogramao, estabelecimento de datas efetivas de incio e trmino de
cada fase/etapa/atividade, se d aps a instalao formal do projeto.

Orar o Projeto consiste na elaborao do oramento do projeto, a partir dos

resultados das estimativas e da determinao quantitativa dos recursos necessrios,
requeridos pelo empreendimento. Em alguns casos , de acordo com regras da
organizao, pode-se elaborar o cronograma de desembolso do projeto , ms as ms,
conforme a sua durao estimada.

Elaborar o Documento de Planejamento do Projeto consiste na confeco do

Plano de Trabalho do Projeto o qual dever conter os objetivos do projeto, o escopo da
soluo que dever ser desenvolvida, os recursos necessrios, metas de qualidade se
houverem, a estrutura organizacional de gesto e operao do projeto, o cronograma
estimativo e o oramento. Este documento o ponto de partida para as discusses
iniciais com o cliente/usurio e uma vez aprovado, servir de guia para a gesto durante o
desenvolvimento da soluo.

O ponto crtico deste processo a elaborao de estimativas de prazo, esforo,

custo do projeto e do tamanho do software. a principal preocupao do gerente de
projetos , pois estimativas no realistas afetam seriamente a credibilidade do projeto junto
ao cliente/usurio.

Veremos agora como podemos realizar estimativas baseadas em mtodos

formais, na infra-estrutura de infomaes necessrias para apoiar o uso destes mtodos e
nas medies necessrias.

6.2 - Tipos e Tcnicas de Estimativas

Este um tema extremamente controvertido na literatura tcnica de engenharia de

software.

De acordo com Fenton 3 os principais modelos de predio para software foram

desenvolvidos a partir de anlises no contexto de um data set especfico. Portanto eles

Fernandes & Kugler 4 fornecem um texto bsico sobre gerncia de projetos, no qual
encontra-se em detalhes o processo de planejamento de projetos.
incorporam as caractersticas particulares de cada data set e frequentemente incluem
parmetros difceis de serem determinados no incio de um projeto, o que a princpio
invalida sua utilizao para a realizao de estimativas quando do planejamento do
projeto .

Para utilizao dos modelos de estimativas, ainda de acordo com Fenton,

necessrio calibr-los ou mesmo customiz-los conforme a realidade da organizao.

A realidade da organizao constitue-se em uma srie histrica com as

observaes acerca de prazos, esforo, custo, tamanho do software e de outros atributos
referentes a cada projeto.

Dessa forma o parmetro preconizado pelo modelo de estimativa pode ser

utilizado para realizar inferncias.

A Figura 6-3 mostra este raciocnio.

Estimativas Para a
Plataforma A
Modelos de
Estimativas
Estimativas Para a
Plataforma B

Estimativas Para a
PlataformaN

Srie Histrica Srie Histrica Srie Histrica

Plataforma A/Pro- Plataforma B/Pro- Plataforma N/Pro-
cesso A cesso B cesso N

Por projeto: Por Projeto: Por Projeto:

Tamanho Tamanho Tamanho
Prazos/Esforo/ Prazos/Esforo/ Prazos/Esforo/
Custo/Tamanho/ Custo/Tamanho/ Custo/Tamanho/
Outros Atributos Outros Atributos Outros Atributos

PROJETOS
Figura 6-3
Modelo de Data Set de Mtricas

A Figura 6-3 mostra que, a partir da coleta de dados sobre prazos, esforo, custo
efetivamente realizados pelos projetos da instalao, considerando tipo de plataforma de
hardware/software e o tipo de processo de desenvolvimento, bem como a coleta de dados
sobre outros atributos, tais como esforo de retrabalho, custo de retrabalho, nmero de
defeitos pr-release etc., alimenta-se uma base de dados para manter uma srie histrica.

Os parmetros gerados pelos modelos de estimativas fazem, a partir da srie

histrica, inferncias para determinar os valores dos itens que queremos estimar,
geralmente: prazo, esforo, custo , nmero de profissionais em tempo integral a serem
alocados e tamanho do software.

Observao deste autor.

 Os tipos de estimativas e respectivas tcnicas e modelos que podemos realizar
(no limitadas ao conjunto apresentado abaixo) durante o planejamento do projeto so:

Tabela 6-1 - Tcnicas e Modelos Para Estimativas

Tipo de Estimativa Tcnicas e Modelos
FPA COCOMO Regresso
Linear
Tamanho do Sistema Metodologia 2
Prazo do Projeto Inferncia Modelo Prrpio
Prazo das Fases Modelo Prprio
Esforo do Projeto Inferncia
Esforo por Fase Modelo Prprio
Custo do Projeto Inferncia Modelo Prprio
Custo por Fase Modelo Prprio
Nmero de Defeitos Inferncia
Pr-Release
Nmero de Defeitos Inferncia
Ps-Release
Esforo de Retrabalho Inferncia
Custo do Retrabalho Inferncia
Nmero de Linhas de Converso FPA
Cdigo Linhas de Cdigo
Nmero de Profissionais Inferncia Modelo Prprio

6.3 - Estimativas Utilizando a Anlise Por Pontos de Funo - FPA

O Ponto de Funo mede o tamanho do software pela quantificao de sua

funcionalidade externa, baseada no projeto lgico ou a partir do modelo de dados. A
contagem dos Pontos de Funo tem como objetivos:

Medir o que o cliente/usurio requisitou e recebeu

Medir independentemente da tecnologia utilizada para implementao
Propiciar uma mtrica de tamanho para apoiar anlises de qualidade e
produtividade
Propiciar um veculo para estimativa de software
Propiciar um fator de normalizao para comparao entre software

A tcnica de FPA foi desenvolvida por Albrecht em 1974 quando trabalhava na

IBM e evoluda por Capers Jones e o International Function Point Users Group -
IFPUG.

O IFPUG considera a abordagem de Albrecht como a Metodologia #1. A

Metodologia #2 em desenvolvimento pelo prprio IFPUG 5 pressupe a medio do
software a partir do Modelo de Dados preliminar, o que permite realizar a primeira
medio antes mesmo de iniciar o Projeto Lgico .

6.3.1 - Estimativa do Tamanho do Software - Metodologia #1

 Os procedimentos para a contagem dos Pontos de Funo ( ou tamanho de um
software ) de acordo com o Counting Practice Manual (Release 4.0) do IFPUG 5 so:

Determinar o Tipo de Contagem

O Ponto de Funo pode estar associado com trs tipos de contagem:(i) contagem
de pontos de funo de projetos de desenvolvimento;(ii) contagem de pontos de
funo de projetos de melhoria; e(iii) contagem de pontos de funo de aplicaes
( sistemas j entregues e em produo).

Identificar as Fronteiras da Contagem

Uma fronteira indica os limites entre a aplicao ou projeto que est sendo medido
e as aplicaes externas do domnio do usurio. A fronteira determina as funes
que devero ser medidas.

Determinar os Pontos de Funo No Ajustados

Os Pontos de Funo No Ajustados abrangem a funcionalidade especfica
requerida pelo usurio para o projeto. A funcionalidade requerida diz o que ser(
ou ) entregue para o usurio.

Os Pontos de Funo No Ajustados compem-se de dois tipos de funo,isto ,

funes de dados e transacionais como mostra a Figura 6-4 a seguir.

Funes de Dados representam a funcionalidade proporcionado ao usurio para

atender seus requisitos de dados internos e externos.

Um Arquivo Lgico Interno um grupo de dados logicamente relacionados ou

informao de controle mantidos dentro das fronteiras da aplicao.

Arquivos Lgi-
cos Internos
Funes de Dados
Arquivos de In-
terfaces Exter-
nas
Pontos de Funo
No Ajustados Entradas
Externas

Funes Transacio- Sadas Externas

nais

Consultas
Externas

Figura 6-4
Tipos de Funes

Arquivos Lgicos Internos podem ser exemplificados por:

Arquivos mestres da aplicao

Tabelas criadas para atender a aplicao
 Dados de segurana da aplicao
Dados de auditagem
Mensagens de auxlio (help)
Mensagens de erro

Um Arquivo de Interface Externa um grupo de dados logicamente relacionado

ou informao de controle mantida externamente s fronteiras da aplicao.

Pode ser exemplificado por:

Arquivos mestres de outras aplicaes

Tabelas criadas para atender outras aplicaes
Mensagens de auxlio ou de erro criadas para atender outras aplicaes

Funes Transacionais representam a funcionalidade proporcionada aos

usurios para processar os dados da aplicao.

Uma Entrada Externa processa dados ou informao de controle oriundos de fora

das fronteiras da aplicao.

Pode ser exemplificada por:

Entrada de dados on-line

Entrada de dados batch

Uma Sada Externa processa dados ou informao de controle que so enviadas

para fora das fronteiras da aplicao.

Pode ser exemplificada por:

Dados transferidos para outra aplicao

Relatrios
Relatrios on-line
Grficos gerados em forma de texto

Uma Consulta Externa representa uma combinao de entrada e sada quando

uma entrada gerar imediatamente uma sada.

Pode ser exemplificada por:

Recuperao de dados
Consulta
Consultas de mensagens de help

Portanto, para o clculo dos Pontos de Funo No Ajustados deve-se identificar e

enumerar as funes da aplicao, ou seja, determinar o nmero de Arquivos
Lgicos Internos, Arquivos de Interface Externa, Entradas Externas, Sadas
Externas e Consultas Externas.
 Aps essa identificao, classificar cada uma das funes conforme seu nvel de
complexidade, se baixa, mdia ou alta.

O nvel de complexidade das funes de dados determinado pelos nmeros de

tipos de elementos de dados e tipos de elementos de registro associados com
os Arquivos Lgicos Internos e Arquivos de Interfaces Externas.

Tipo de Elemento de Dados (TED) um campo nico reconhecido pelo usurio,

no recursivo, no Arquivo Lgico Interno ou no Arquivo de Interface Externa.

Tipo de Elemento de Registro (TER) um subgrupo de dados, reconhecido pelo

usurio, dentro de um Arquivo Lgico Interno ou Arquivo de Interface Externa.

O nvel de complexidade das funes transacionais determinado pelos nmeros

de tipos de arquivos referenciados e tipos de elementos de dados associados
com as Entradas Externas, Sadas Externas e Consultas Externas.

Tipo de Arquivo Referenciado (TAR) um arquivo lgico interno lido ou mantido

por um tipo de funo e/ou um arquivo de interface externa lida por uma funo.

Tipo de Elemento de Dados (TED) neste caso, um campo nico reconhecido

pelo usurio e tratado pelas funes transacionais.

As Tabelas 6-2,6-3,6-4 e 6-5 a seguir, apresentam a determinao da

complexidade das respectivas funes.
Tabela 6-2 - Complexidade de Arquivos Lgicos Internos e Interfaces Externas
Registros Dados
1 a 19 TED 20 a 50 TED 51 ou mais TED
1 TER Baixa Baixa Mdia
2 a 5 TER Baixa Mdia Alta
6 ou mais TER Mdia Alta Alta

Tabela 6-3 - Complexidade de Entradas Externas

Arquivos Dados
1 a 4 TED 5 a 15 TED 16 ou mais TED
0 a 1 TAR Baixa Baixa Mdia
2 TAR Baixa Mdia Alta
3 ou mais TAR Mdia Alta Alta

Tabela 6-4 - Complexidade de Sadas Externas

Arquivos Dados
1 a 5 TED 6 a 19 TED 20 ou mais TED
0 a 1 TAR Baixa Baixa Mdia
2 a 3 TAR Baixa Mdia Alta
4 ou mais TAR Mdia Alta Alta

Tabela 6-5 - Complexidade de Consultas Externas

 Arquivos Dados
Entradas 1 a 4 TED 5 a 15 TED 16 ou mais TED
0 a 1 TAR Baixa Baixa Mdia
2 TAR Baixa Mdia Alta
3 ou mais TAR Mdia Alta Alta
Sadas 1 a 5 TED 6 a 19 TED 20 ou mais TED
0 a 1 TAR Baixa Baixa Mdia
2 a 3 TAR Baixa Mdia Alta
4 ou mais TAR Mdia Alta Alta

Uma vez classificadas as funes conforme sua complexidade , deve-se utilizar a

tabela de transformao.

Para melhor compreenso iremos exemplificar. Suponha uma aplicao na qual

identificamos:

3 Entradas Externas, sendo todas as 3 de complexidade baixa

2 Sadas Externas, sendo uma com complexidade baixa e outra mdia
4 Arquivos Lgicos Internos, sendo 3 de complexidade baixa e um
mdio
3 Arquivos de Interfaces Externas, sendo 2 de complexidade baixa e um
mdio
5 Consultas Externas, sendo 1 de complexidade baixa, 3 mdias e 1
alta

A tcnica pressupe que cada nvel de complexidade de uma funo tem um peso.
A tabela de transformao tem o formato a seguir.

Determinar o Valor do Fator de Ajustamento

O valor do fator de ajustamento (FA) indica a funcionalidade geral proporcionada

ao usurio pela aplicao.

O FA consiste de 14 caractersticas do sistema que avaliam a funcionalidade geral

da aplicao. O nvel de influncia dessas caractersticas dado por uma escala
que varia de 0 a 5 representando:

0, no est presente ou no tem influncia

1, pouca influncia
2, moderada influncia
3, mdia influncia
4, significante influncia
5, forte influncia

Essas caractersticas so:

Comunicao de Dados
Processamento de Dados Distribudo
 Desempenho
Configurao Pesadamente Utilizada
Taxa de Transao

Tabela 6-6 - Determinao dos Pontos de Funo No Ajustados

Funo Ocorrncias Complexidade Peso Resultado
Entradas Externas 3 Baixa x3= 9
0 Mdia x4= 0
0 Alta x6= 0
Total 1 = 9
Sadas Externas 1 Baixa x4= 4
1 Mdia x5= 5
0 Alta x7= 0
Total 2 = 9
Arquivos Lgicos 3 Baixa x7= 21
Internos 1 Mdia x 10 = 10
0 Alta x 15 = 0
Total 3 = 31
Arquivos de Inter- 2 Baixa x5= 10
faces Externos 1 Mdia x7= 7
0 Alta x 10 = 0
Total 4 = 17
Consultas 1 Baixa x3= 3
Externas 3 Mdia x4= 12
1 Alta x6= 6
Total 5 = 21
Total de Pontos de Funo No Ajustados 87

Entrada de Dados On-Line

Eficincia do Usurio Final
Atualizao On-Line
Processamento Complexo
Reutilizao
Facilidade de Instalao
Facilidade Operacional
Mltiplas Instalaes
Facilidade de Mudana

Voltando ao nosso exemplo, suponha os seguintes nveis de influncia:

Tabela 6-7 - Caractersticas Gerais da Aplicao

Caractersticas Nvel de Influncia
Comunicao de Dados 2
Processamento de Dados Distribudo 1
Desempenho 5
Configurao Pesadamente Utilizada 5
Taxa de Transao 4
Entrada de Dados On-Line 3
Eficincia do Usurio Final 2
 Atualizao On-Line 3
Processamento Complexo 1
Reutilizao 0
Facilidade de Instalao 2
Facilidade Operacional 4
Mltiplas Instalaes 3
Facilidade de Mudana 3
Nvel de Influncia Total 38

Utilizando o nvel de influncia total, podemos determinar o FA de acordo com a

frmula a seguir:
0.65 + (0.01 x NI ) = FA

No nosso exemplo, o FA seria de:

0.65 + (0.01 x 38 ) = 1.03

Calcular o Ponto de Funo Ajustado

Esta a etapa final do processo de contagem dos Pontos de Funo, ou seja, a

determinao do tamanho do software.

Para determinar os Pontos de Funo preciso multiplicar o FA pelos Pontos de

Funo No Ajustados.

Assim nosso exemplo finaliza com o seguinte resultado:

1.03 x 87 = 90 ( por arredondamento)

6.3.2 - Estimativa do Tamanho do Software - Metodologia #2

Os procedimentos para a utilizao da metodologia 2 so descritos a seguir.

Determinar o Tipo de Contagem

Procedimento anlogo ao utilizado pela metotologia# 1.

Identificar as Fronteiras da Contagem

Procedimento anlogo ao utilizado pela metodologia# 1.

Determinar os Pontos de Funo

Como observado anteriormente, a metodologia# 2 baseia-se no Modelo de Dados
Preliminar. Neste caso exige-se da pessoa que far a medio, familiaridade com
as tcnicas de modelagem e de processos.

As definies principais adotadas pela metodologia# 2 so:

Atributo: uma caracterstica da entidade, geralmente anlogos aos tipos de

Elementos de Dados.
 Entidade Associativa: uma entidade que contm atributos que descrevem uma
relao M para N entre duas outras entidades.
Entidade Atributiva: uma entidade que descreve uma ou mais caractersticas
de outra entidade.
Processo Elementar: a menor unidade de uma atividade que representativa
para o usurio final em termos do seu negcio.
Entidade: uma coisa fundamental, de relevncia para o usurio, sobre a qual
uma coleo de fatos mantida.
Sub-tipo de Entidade: a subdiviso de uma entidade. Um sub-tipo herda todos
os atributos e relacionamentos da entidade pai e pode ter, adicionalmente,
atributos e relacionamentos nicos.
Relacionamento: uma associao entre duas entidades. Um relacionamento
no tem atributos.
Tipos de Elementos de Dados: so os nmeros de atributos incluindo atributos
de chave estrangeira.
Tipos de Elementos de Registros: so o nmero de entidades, incluindo sub-
tipos e atributos.
Tipos de Arquivos Referenciados: so as entidades mantidas pela aplicao
ou no que so utilizados por funes transacionais.

Considerando o modelo de dados resumido de uma aplicao de

acompanhamento de projeto conforme a Figura 6-5 , podemos definir os tipos de
funes de dados e de transao.

Figura 6-5 - Modelo de Dados Exemplo

Grupo de
Fases/ Desenvolvimento
Etapas Unidades

Projeto
Metodologia
Solicitao

Plano de
Trabalho Ambiente
Computacional Ocorrncias

Estimado Atual Realizado

ARQUIVOS LGICOS INTERNOS

Projeto
Solicitao
Ambiente Computacional
Plano de Trabalho
Fases/Etapas
Metodologia
 Observe que a entidade Ocorrncias no considerada como um Arquivo Lgico
Interno pois somente pode ser mantida atravs da entidade Projeto.

ARQUIVOS DE INTERFACE EXTERNA

Grupo de Desenvolvimento
Unidades
(Supondo que so mantidas por outra aplicao)

ENTRADAS EXTERNAS
Considere para cada Arquivo Lgico Interno os seguintes
processos:
Create
Update
Delete

SADAS EXTERNAS
Considere para cada Arquivo Lgico Interno o seguinte
processo:
Emisso de Relatrio

CONSULTAS EXTERNAS
Considere para cada Arquivo Lgico Interno o seguinte
processo:
Read

Neste exemplo teramos, portanto, 8 funes de dados e 30 funes transacionais.

A determinao da complexidade de cada funo, o uso da tabela de traduo, a

aplicao das 14 caractersticas da aplicao e a determinao do ponto de
funo ajustado seguem os mesmos procedimentos da metodologia #1.

6.3.3 - Estimativa do Prazo do Projeto

O emprego do Function Points para a estimativa do prazo de um projeto tem sua

limitaes, a no ser que a empresa se disponha a utilizar ferramentas comerciais
disponveis no mercado que objetivam a gerao de estimativas dessa natureza.

Uma dessas ferramentas o Checkpoint, desenvolvida pela SPR - Software

Productivity Research 6 , a qual consiste de um sistema especialista que, a partir da
informao sobre o tamanho do software em Pontos de Funo e sobre atributos do
ambiente de desenvolvimento, gera uma srie de estimativas, inclusive o prazo esperado
para o projeto.

Na falta de um instrumento dessa natureza, o procedimento realizar inferncias

sobre uma base de dados que contenha uma srie histrica (observaes) com
informaes acerca de projetos j completados em termos de: plataforma de
hardware/software, processo de desenvolvimento (metodologia empregada), prazo,
esforo, custo e tamanho.

A Figura 6-8 mostra um exemplo de um data set com uma srie histrica
hipottica.

Tabela 6-8 - Data Set de Mtricas

Plataforma de Hardware : mainframe
Plataforma de Software :
Gerenciador de Banco de Dados : DB2
Monitor de TP : CICS
Linguagem de Programao : CSP
Processo : Metodologia Estruturada

Itens Projetos
A B C D
Tamanho 300 500 800 1200
Esforo 10 H/M 16,67 H/M 32 H/M 60 H/M
Prazo 5 meses 6 meses 8 meses 10 meses
Custo $ 48.000 $ 80.016 $ 153.000 $ 288.000
Equipe 2 3 4 6
Produtividade 30 FP/h/m 30 FP/h/m 25 FP/h/m 20 FP/h/m

O procedimento para realizar inferncia, a partir do tamanho do software em Ponto

de Funo o que segue.

Determinar o Ambiente de Hardware/Software de Desenvolvimento

A inferncia deve ser realizada para o mesmo ambiente em que ser desenvolvido
o software.

Determinar o Processo Que Ser Utilizado Para o Desenvolvimento

A inferncia deve ser realizada para o mesmo processo que servir de base para o
desenvolvimento.

Determinar o Prazo do Projeto

Para valores de tamanho de software diferentes aos existentes no data set e que
estejam compreendidos entre a amplitude 300 a 1200 pode-se empregar
interpolao aritmtica.

uma forma de determinar valores eqidistantes entre dois pontos na tabela. Em

geral, se tivermos dois pontos numa tabela ( Xo,Yo) e (X1,Y1) e desejarmos
 encontrar o valor de Y correspondente a um ponto X entre Xo e X1 , por
interpolao , podemos usar a seguinte frmula:

X - Xo
Y = Yo + ( Y1- Yo)
X1- Xo

Supondo uma estimativa de tamanho de 600 PFs ( que fica entre 500 e 800 PFs
do nosso data set) as variveis da frmula acima assumem os seguintes valores:

Yo =6
Y1 =8
X = 600
Xo = 500
X1 = 800

Aplicando a frmula teramos a seguinte estimativa:

Y = 6 + 600-500 x (8-6)

800 -500

Y = 6 + 2/3 x 2 = 6,6 meses

6.3.4 - Estimativa do Esforo do Projeto

O esforo estimado para um projeto medido pela alocao dos recursos

humanos em termos de homem/ms ou homem/hora.

A inferncia a ser realizada similar a anterior.

Entretanto a transformao pode ser direta caso o data set contiver o dado sobre
a produtividade mdia do desenvolvimento conforme a plataforma de hardware/software e
respectiva metodologia ou se houver valor de Ponto de Funo similar ao estimado.

A interpolao tambm pode ser empregada nos casos de valores de PFs

estimados, intermedirios aos existentes no data set.

Transformao Direta
Para determinar o esforo, o data set deve conter a Produtividade Mdia do
Desenvolvimento em PFs por Homem/Ms de acordo com a plataforma de
hardware/software e o processo de desenvolvimento.

Exemplo de aplicao:

Supondo:
Produtividade Mdia na Plataforma mainframe ,DB2,CICS e
CSP seja igual a 26.25 FPs /H/m
PFs estimados sejam 500
 O clculo do esforo esperado :

Esforo = ( Tamanho Estimado do Software em PFs )

( Produtividade Mdia em FPs/H/m )

No nosso exemplo teramos:

Esforo = 500 PFs ou 19 H/m (por arredondamento)

26,26 FP/H/m

Transformando em horas, considerando jornada de 168 horas/ms,

teramos em torno de 3192 homens/hora de esforo.

Transformao Por Interpolao

O tratamento o mesmo dado para determinar o prazo. Neste caso para cada
projeto no data set dever conter a produtividade correspondente realizada para
o mesmo.

6.3.5 - Custo Estimado Para o Projeto

O custo estimado para o projeto o produto do custo do homem/ms ou

homem/hora, multiplicado pelo esforo previsto sendo que, de forma simplificada o Custo
= f ( Esforo).

Aqui devemos observar duas abordagens para tratar o custo do homem/ms:

Custeio Direto
Custeio Por Absoro Total

O custeio direto considera apenas o salrio + encargos ou em termos de valores

mdios ou aquele que representa o recurso especfico a ser empregado no projeto, de
acordo com a respectiva faixa salarial.

O custeio por absoro total j mais complexo, pois deve considerar um rateio
entre diversos tipos de despesas incidentes sobre o desenvolvimento do software, tais
como: recursos computacionais, equipamentos auxiliares, servios contratados, custos
administrativos, custos com materiais de consumo, custos de pessoal referente s reas
de assessoria, chefia do desenvolvimento e assim sucessivamente.

O conceito que est por trs desta abordagem que a rea de desenvolvimento
vende servios de anlise e programao ou funes, que so medidos pelo consumo
de Homens/Ms ao projeto.

Portanto o custo do Homem/Ms no modo de absoro total :

(salrios + encargos) + parcela correspondente de rateio

 Para simplificar podemos considerar a relao desenvolvida por Bandeira1,
cujo custo de pessoal no desenvolvimento de software representa cerca de 60 a 70% do
custo total, excluindo itens de investimento que sejam necessrios.

Outra forma de determinar o custo estimado do projeto atravs do custo unitrio

para produzir um Ponto de Funo.

Determinao do Custo Estimado Com Base no Esforo

As trs alternativas neste caso so:

Por custeio direto:

(salrio + encargo) mdio do Homem/Ms x esforo estimado

Por absoro total:

(salrio + encargos + parcela de rateio) x esforo estimado

Relao 60 a 70%

considerando X o custo de pessoal e Y o custo total, ento:

custo total = ( X x 30) 70 + X

Determinao do Custo Pelo Custo Unitrio do PF

Neste caso o data set dever conter o custo unitrio em PF para cada projeto,
conforme a plataforma e o processo de desenvolvimento.

No exemplo daTabela 6-8 , os respectivos custos unitrios para os projetos A,B,C

e D seriam: $160,03 - $ 160,00 - $ 191,25 - $ 240,00.

O custo mdio seria de: $ 187.82.

Para determinar o custo estimado do projeto na plataforma mainframe

,DB2,CICS,CSP, necessitamos apenas multiplicar o tamanho do software
em PFs por $ 187.82. Considerando uma estimativa de 500 PFs obteramos um
resultado de $ 93.910,00.

Outra alternativa o emprego da interpolao aritmtica para determinarmos o

custo do projeto para tamanhos intermedirios na tabela.

6.3.6 - Estimativa do Nmero de Instrues Fontes

De acordo com Caper Jones 6, a predio do nmero de instrues fontes para

um software baseada na observao emprica do nvel da linguagem e sobre o nmero
de instrues requerido para implementar um ponto de funo.

O nvel da linguagem, a partir das pesquisas realizadas na IBM por Capers Jones
e Albrecht, foi normalizado a partir de instrues equivalentes em Assembler na
linguagem alvo, a fim de produzir um ponto de funo.
 Por exemplo, uma instruo fonte em Cobol equivale a trs em Assembler, j o
PL/1 equivale a quatro.

A Tabela a seguir apresenta uma amostra dos nveis de linguagem com o nmero
correspondente de instrues fontes equivalentes para produzir um ponto de funo.

Tabela 6-9 - Instrues Equivalentes Conforme Pontos de Funo

Linguagem Nvel Instrues
Equivalentes
1. Default - baixo nvel 1.0 320
2. Linguagem de Mquina 1.0 320
3. Assembler 1.0 320
4. Macro Assembler 1.5 213

5. Default C 2.5 128

6. Basic Interpretado 2.5 128
7. Fortran II 2.5 128
8. Fortran 66 2.5 128
9. Default - segunda gerao 3.0 105

10.Default - linguagens procedurais 3.0 105

11.Fortran 77 3.0 105
12.Algol 68 3.0 105
13.Algol W 3.0 105
14.Chill 3.0 105

15.ANSI Cobol 74 3.0 105

16. Coral 66 3.0 105
17. Jovial 3.0 105
18. ANSI Cobol 85 3.5 91

19.Default - Pascal 3.5 91

20.Basic Compilado 3.5 91
21.PL/S 3.5 91
22.Default - linguagens de terceira gerao 3.5 91

23.Default - Geradores de Relatrios 4.0 80

24.PL/1 4.0 80
25.Modula 2 4.0 80
26.Ada 4.5 71

27.Prolog 5.0 64
28.Lisp 5.0 64
29.Forth 5.0 64
30. ANSI/Quick/Turbo Basic 5.0 64

31.Default- Linguagens de IA 6.5 49

32.Linguagens de Simulao 7.0 46
33.Default-Tabelas de Deciso 7.0 46
34.Default - Banco de Dados 8.0 40
35.Default - Suporte Deciso 9.0 35
36.Default - Linguagem Estatistica 10.0 32
37.APL 10.0 32

Enquadram-se como default todas as outras linguagens do mesmo nvel.

38.Default - Orientao Objeto 11.0 29

39.Default - Quarta Gerao 16.0 20

40.Default - Gerador de Programas 20.0 16
41.Default- Linguagens de Query 25.0 13
42.Default- Planilhas Eletrnicas 50.0 6
43.Default - Quinta Gerao ( GUI) 75.0 4

Para a estimativa do nmero de instrues fontes do software devemos proceder

como segue.

Determinar a Linguagem ( ou linguagens) de Desenvolvimento

Realizar a Transformao - Caso de Uma Linguagem

Exemplo:

Linguagem Cobol
1000 PFs estimados

O resultado :

Pontos de Funo Estimados x No. de Instrues Equivalentes ou

1000 x 91 = 91.000 Instrues Fontes

Realizar a Transformao - Caso de Duas Linguagens

Exemplo:

Linguagem Cobol
Linguagem Assembler
1000 PFs em Cobol
200 PFs em Assembler

O resultado :

(1000 x 91 ) + (200 x 320 ) = 155.000 Instrues Equivalentes

6.4 - Estimativas Utilizando o COCOMO ( Constructive Cost Model)

O mtodo COCOMO foi desenvolvido por Barry Boehm 2 , para estimar

esforo, prazo , custo e tamanho da equipe para um projeto de software.

O mtodo foi derivado a partir de um data set compreendendo 63 projetos,

cobrindo reas como: negcios, controle, cientfica, suporte e sistema operacional.

Existem trs modelos neste mtodo:

 COCOMO Bsico
COCOMO Intermedirio
COCOMO Detalhado

O COCOMO Bsico uma verso aplicvel grande maioria dos projetos de

software : pequenos a mdios software, em termos de tamanho, desenvolvidos in-
house.

Entretanto as estimativas fornecidas pelo COCOMO Bsico so limitadas, pois

desconsideram alguns fatores tais como restries de hardware, qualificao e
experincia do pessoal, uso de modernas tcnicas e ferramentas e outros atributos do
projeto.

O COCOMO Intermedirio j adiciona estes fatores, proporcionando estimativas

mais acuradas.

O COCOMO Detalhado , por sua vez, apresenta tcnicas para se estimar tanto a
nvel de mdulo, subsistema e sistema, individualizando, a cada fase do projeto, os
atributos de custo.

Para os objetivos deste captulo, descreveremos os modelos Bsico e

Intermedirio, pois julgamos suficiente para as necessidades da maioria dos ambientes
de desenvolvimento das organizaes brasileiras.

Um mtodo de estimativa, para projetos de software, tem certa exatido se o

mesmo pode estimar os custos de desenvolvimento com 20% de variao em relao ao
previsto e 30% em relao ao prazo.

De acordo com Boehm, o COCOMO Intermedirio enquadra-se dentre desta

definio.

O COCOMO categoriza os projetos de software em trs tipos fundamentais:

Modo Orgnico (Convencional)

No modo orgnico, equipes relativamente pequenas desenvolvem sistemas

num ambiente altamente familiar, in-house. A maior parte das pessoas
engajadas no projeto tem experincia prvia com sistemas similares na
organizao, bem como tem um completo entendimento de como o sistema
em desenvolvimento contribuir para os objetivos da empresa.

Isto significa que a maioria das pessoas engajadas no projeto pode

contribuir para o mesmo em seus estgios iniciais, sem gerar uma grande
sobrecarga de comunicao sobre o que o sistema far e qual ser a
diviso de trabalho para a equipe.
Um projeto orgnico relativamente flexvel sobre a forma como o software
atende s especificaes de requisitos e interfaces.

Outras caractersticas do modo orgnico so: (I) ambiente estvel de

desenvolvimento; (ii) algoritmos simples; (iii) prmio relativamente baixo
 para trmino antes do prazo;(iv) tamanho relativamente pequeno, projetos
na faixa de 50.000 instrues fontes.

Modo Difuso

O modo difuso representa um estgio intermedirio entre os modos

orgnico e restrito. Significa uma mistura das caractersticas dos modos
orgnico e detalhado.

Suas caractersticas bsicas so:

a equipe mescla grande e pouca experincia com a aplicao

a equipe mescal grande e pouca experincia com a tecnologia
o tamanho do software varia at 300.000 instrues fontes

Modo Restrito

O principal fator que distingue um projeto de software de modo Restrito a

necessidade para operar conforme grandes restries. O produto deve
operar dentro de um contexto complexo de hardware, software, regras e
procedimentos operacionais, tal como um sistema de transferncia
eletrnica de fundos ou um sistema de controle de trfego areo.

Como resultado, projetos de modo restrito no tm a opo de modificar

facilmente suas especificaes.

So projetos que requerem altos custos de verificao e validao. Estes

fatores contribuem para baixar a produtividade e criar deseconomias de
escala.

Geralmente, o prmio para trmino antes do prazo extremamente alto.

A seguir so apresentados os procedimentos para a realizao de estimativas

pertinentes com o COCOMO.

6.4.1 - Estimativa de Esforo - COCOMO Bsico

Determinar o Modo do Projeto (Orgnico,Difuso ou Restrito)

Determinar o Nmero de Instrues Fontes Previstas

Este um das limitaes do mtodo, pois como, no incio do projeto, saberemos
quantas instrues fontes sero produzidas?

Uma alternativa, que nos parece vivel, a utilizao combinada do mtodo FPA
com o COCOMO.

Uma vez que o FPA pode transformar Pontos de Funo em Instrues Fontes,
poderamos usar o resultado da transformao para a aplicao das equaes de
esforo do COCOMO.
 Aplicar a Estimativa de Instrues Fontes na Equao de Esforo
O COCOMO propicia trs equaes para determinar o esforo previsto para o
projeto, conforme o modo do mesmo.

Tabela 6-10 - Equaes de Esforo - COCOMO Bsico

Modo Esforo
1.05
Orgnico H/M = 2.4 (KDSI)
1.12
Difuso H/M = 3.0 (KDSI)
1.20
Restrito H/M = 3.6 (KDSI)

Supondo:

50 KDSI para um software classificado como orgnico

100 KDSI para um software classificado como difuso
200 KDSI para um software classificado como restrito

Aplicando a frmula:

Esforo estimado para 50 KDSI orgnico

1.05
H/M = 2.4 ( 50 ) = 146 (por arredondamento)

Esforo estimado para 100 KDSI difuso

1.12
H/M = 3.0 ( 100 ) = 521 ( por arredondamento)

Esforo estimado para 200 KDSI restrito

1.20
H/M = 3.6 ( 200 ) = 2077 ( por arredondamento)

6.4.2 - Estimativa do Prazo - COCOMO Bsico

O COCOMO tambm prov equaes para a determinao do prazo do projeto.

Tabela 6-11 - Equaes de Prazo

Modo Prazo
0.38
Orgnico Prazo = 2.5 ( H/M)
0.35
Difuso Prazo = 2.5 (H/M)
0.32
Restrito Prazo = 2.5 (H/M)

H/M significa Homem/Ms e KDSI, milhares de instrues fontes entregues.

 Aplicando as estimativas de esforo do exemplo anterior, os prazos estimados
seriam:

50 KDSI orgnico
0.38
Prazo = 2.5 ( 146 ) = 16.61 meses

100 KDSI difuso

0.35
Prazo = 2.5 ( 521 ) = 22.33 meses

200 KDSI restrito

0.32
Prazo = 2.5 ( 2077) = 28.81 meses

6.4.3 - Estimativa de Quantitativo de Pessoal - COCOMO Bsico

Para a determinao do nmero mdio de profissionais necessrios para o projeto

preciso dividir o esforo estimado pelo prazo estimado. No nosso exemplo os
resultados seriam:

50 KDSI orgnico
Equipe = 146 16.61 = 9 ( por arredondamento)

100 KDSI difuso

Equipe = 521 22.33 = 23 ( por arredondamento)

200 KDSI restrito

Equipe = 2077 28.81 = 72 ( por arredondamento)

6.4.4 - Estimativa de Esforo - COCOMO Intermedirio

O mesmo procedimento adotado para o COCOMO Bsico deve ser adotado aqui.

As diferenas fundamentais entre o modelo Bsico e o Intermedirio residem nas

equaes de estimativa de esforo e na considerao dos fatores de custo aplicveis ao
projeto.

No modelo Intermedirio, as equaes para determinao do esforo so:

Tabela 6-12 - Equaes de Esforo - COCOMO Intermedirio

Modo Esforo
1.05
Orgnico H/M = 3.2 ( KDSI )
1.12
Intermedirio H/M = 3.0 ( KDSI )
1.20
Restrito H/M = 2.8 ( KDSI )
 Os fatores de custo so classificados por atributo do projeto, ou:

Atributos do Produto
RELY Confiabilidade requerida pelo software
DATA Tamanho da base de dados
CPLX Complexidade do software

Atributos Computacionais
TIME Restries de execuo (tempo de mquina)
STOR Restries quanto ao uso de memria principal
VIRT Mudanas do ambiente de software
TURN Tempo de resposta

Atributos da Equipe
ACAP Capacidade dos analistas
AEXP Experincia na aplicao
PCAP Capacidade dos programadores
VEXP Experincia no ambiente de hardware
LEXP Experincia na linguagem de programao

Atributos do Projeto
MODP Tcnicas modernas de programao
TOOL Uso de ferramentas
SCED Prazo requerido para o desenvolvimento

Cada um destes fatores tem um peso, que so os multiplicadores, que ajustam

para mais ou para menos as estimativas iniciais.

Na Tabela 6-13 so mostrados os pesos para cada atributo.

Tabela 6-13 - Multiplicadores de Esforo

Multiplicadores Pesos
Atributos Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto
RELY .75 .88 1.00 1.15 1.40
DATA .94 1.00 1.08 1.16
CPLX .70 .85 1.00 1.15 1.30 1.65
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT .87 1.00 1.15 1.30
TURN .87 1.00 1.07 1.15
ACAP 1.46 1.19 1.00 .86 .71
AEXP 1.29 1.13 1.00 .91 .82
PCAP 1.42 1.17 1.00 .86 .70
VEXP 1.21 1.10 1.00 .90
LEXP 1.14 1.07 1.00 .95
MODP 1.24 1.10 1.00 .91 .82
TOOL 1.24 1.10 1.00 .91 .83
SCED 1.23 1.08 1.00 1.04 1.10
A determinao dos pesos aplicveis ao projeto dado pela Tabela 6-14.
Tabela 6-14 - Determinao dos Pesos
Atributos Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto
RELY Inconvenin- Perdas Perdas Altas perdas Risco vida
cia facilmente moderadas financeiras humana
recuperadas
DATA DB bytes 10 DB <100 100DB<1000 DB 1000
no. IF IF IF
instrues
fontes < 10
CPLX Vide Tabela 6-15
TIME 50% dispo- 70% 85% 95%
nibilidade de
tempo de
execuo

STOR 50% uso de 70% 85% 95%

memria
disponvel
VIRT Principais 6 meses 2 meses 2 semanas
mudanas a
cada 12
meses
TURN Interativo < 4 horas 4-12 horas mais que 12
horas
ACAP 15o. percentil 35o. percentil 55o. percentil 75o. percentil 90o. percentil
AEXP 4 meses de 1 ano 3 anos 6 anos 12 anos
experincia
PCAP 15o. percentil 35o. percentil 55o. percentil 75o. percentil 90o. percentil
VEXP 1 ms de 4 meses 1 ano 3 anos
experincia
LEXP 1 ms de 4 meses 1 ano 3 anos
experincia
MODP No utiliza Iniciando Algum uso Uso Uso rotineiro
generalizado
TOOL Ferramentas Ferramentas Ferramentas Ferramentas Ferramentas
bsicas em em mini bsicas de de para anlise,
micro mainframe programao projeto, ge-
e teste rncia
SCED 75% do 85% 100% 130% 160%
nominal

Tabela 6-15 - Complexidade

Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto
Controle de Cdigo Operadores Uso de Considervel Cdigo Controle de
Operaes simples com com uso de tabelas de controle reentrante e microcdigo;
poucos programao deciso; entre recursivo; programao
operadores estruturada algum mdulos; manuseio de dinmica de
sem uso de controle controle de interrupes recursos
Programao entre filas e pilha;
Estruturada mdulos grande
nmero de
operadores
Operaes Avaliao de Avaliao de Uso de Anlise Equaes Anlise de
Computacio- expresses expresses rotinas numrica, diferenciais dados
nais simples moderadas matemticas interpolao parciais stocsticos
e estatsticas multivariada.
padres; equaes
operaes diferenciais
com matrizes
Operaes Instrues Tratamento Processamen Operaes a Rotinas de Operaes
Dependenes simples de de I/O o de I/O nvel fsico diagnstico; em micro-
de Mquina leitura e incluido de I/O comunicao programao
gravao escolha do ; controle de
perifrico, tempos
 deteco de
erro de
processamen
to
Operaes Arrays Arquivos Entradas Reestrutura- Rotina Estrutura
De Gerncia simples na simples, sem para o parametriza- realacional
de Dados memria arquivos mltiplos complexa de da de
principal intermedi- arquivos dados a nvel estruturao
rios de registro de dados;
otimizao
de pesquisa
Projeto de Pouco QA,CM Verificao e Verificao Verificao
Requisitos e detalhe; bsicos; validao detalhada;pa detalhada;
do Produto pouca planos de dres de QA, QA,CM ,PDR
verificao; testes CM, PDR, e I V&V,
sem QA,CM planos de planos de
teste teste muito
detalhados detalhados
Projeto Informao Detalhe V&V Verificao Verificao
Detalhado de projeto moderado; detalhada; detalhada;
mnima; QA e CM padres de padres de
mnimo QA e bsicos,plan QA e CM; QA e CM;
CM; o plano de inspees
inspees de teste teste detalhadas;
informais detalhado planos de
testes muito
detalhados;
I V&V
Teste de Sem Procedimen- V&V Procedimen- Procedimen-
Cdigo e procediment to de teste to de teste to de teste
Unidade o mnimo; QA detalhado; detalhado;
de teste; e CM bsico; QA e CM; QA e CM;
mnimo QA e inspees
CM detalhadas
de cdigo; I
V&V
Integrao e Sem Procedimen- V&V Procedimen- Procedimen-
Teste procediment to de teste to de teste to de teste
o de teste; mnimo; detalhado; muito
muitos requisitos QA e CM; detalhados;
requisitos frequenteme documenta- QA e CM;
sem teste; nte sem o IV & V
mnimo QA e testes;
CM; QA e CM
bsico

Exemplo de aplicao do modelo Intermedirio:

Supondo:

50 KDSI estimado para o software modo orgnico

Determinao do esforo no ajustado:

1.05
Esforo = 3.2 ( 50 ) = 195 Homens/Ms

QA=Quality Assurance,CM=Configuration Management,PDR=Product Design Review,IV & V

= Independent Verification & Validation.
 Ajustamento do esforo pelos multiplicadores escolhidos:

Supondo as seguintes caractersticas do software conforme a tabela.

Multiplicadores Pesos
Atributos Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto
RELY .75 .88 1.00 1.15 1.40
DATA .94 1.00 1.08 1.16
CPLX .70 .85 1.00 1.15 1.30 1.65
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT .87 1.00 1.15 1.30
TURN .87 1.00 1.07 1.15
ACAP 1.46 1.19 1.00 .86 .71
AEXP 1.29 1.13 1.00 .91 .82
PCAP 1.42 1.17 1.00 .86 .70
VEXP 1.21 1.10 1.00 .90
LEXP 1.14 1.07 1.00 .95
MODP 1.24 1.10 1.00 .91 .82
TOOL 1.24 1.10 1.00 .91 .83
SCED 1.23 1.08 1.00 1.04 1.10

195 x 1.15 x 1.08 x 1.00 x 1.00 x 1.06 x .87 x 1.07 x .86 x .91 x .86 x
.90 x .95 x .82 x .83 x .1.10 = 102. 96 ou 103 H/M

Neste exemplo o esforo estimado passaria de 195 para 103 H/M.

6.4.5 - Estimativa de Prazo - COCOMO Intermedirio

O COCOMO intermedirio utiliza as mesmas equaes para determinar o prazo

que o modelo Bsico.

6.4.6 - Estimativa de Quantitativo de Pessoal - COCOMO Intermedirio

Utiliza-se do mesmo procedimento que o COCOMO Bsico.

6.4.7 - Estimativa de Distribuio de Esforo e Prazo - Ambos Modelos

O COCOMO emprega uma tabela padro de tamanho de software, ou seja:

Projeto pequenos 2KDSI

Projetos intermedirios 8KDSI
Projetos mdios 32KDSI
Projetos grandes 128KDSI
Projetos muito grandes 512KDSI

Associado a estes tamanhos de projetos, Boehm desenvolveu uma tabela (6-17)

que estabelece a distribuio percentual de esforo e prazo pelas fases de um projeto.
 Esta tabela baseada na distribuio de Rayleigh. A distribuio de Rayleigh
permite realizar estimativas aproximads da distribuio de esforo, pessoal necessrio,
previso de defeitos etc.

Essa distribuio determinada pela seguinte frmula:

2 2 2
X = Y ( 1 td ) x e ( t 2 x td )
onde:
X o valor a ser estimado
Y o valor do atributo que ser decomposto pela
distribuio
td o ms que o projeto atinge seu pico
t o ms para o qual desejamos estimar

As fases contempladas pelo modelo COCOMO so:

Planos e Requisitos
Projeto do Produto
Programao
Integrao e Teste

O procedimento para determinar o esforo e prazo para cada fase do projeto

dado pelo exemplo a seguir.

Considere o tamanho de um projeto , modo orgnico, conforme o modelo

Intermedirio, em 32 KDSI.

Aplicando a equao de esforo teremos 122 H/M.

Supondo um fator de ajustamento de 1.19 (derivado dos multiplicadores), teremos

o H/M ajustado em 145 H/M e o prazo de 16,5 meses.

Para acharmos a distribuio do esforo e prazo por fases necessrio

multiplicarmos o H/M e o prazo respectivamente pelos percentuais da tabela.

A distribuio ficaria conforme as tabelas a seguir:

Tabela 6-17 - Distribuio de Esforo e Prazo Para Tamnhos Padres

Distribuio de Esforo (%) Tamanho
Modo Fase 2KDSI 8KDSI 32KDSI 128KDSI 512KDSI
Orgnico Planos e Requisitos 6 6 6 6
Projeto do Produto 16 16 16 16
Programao 68 65 62 59
Projeto Detalhado 26 25 24 23
Codificao 42 40 38 36
Integrao e Teste 16 19 22 25
Difuso Planos e Requisitos 7 7 7 7 7
Projeto do Produto 17 17 17 17 17
Programao 64 61 58 55 52
Projeto Detalhado 27 26 25 24 23
Codificao 37 35 33 31 29
Integrao e Teste 19 22 25 28 31
Restrito Planos e Requisitos 8 8 8 8 8
 Projeto do Produto 18 18 18 18 18
Programao 60 57 54 51 48
Projeto Detalhado 28 27 26 25 24
Codificao 32 30 28 26 24
Integrao e Teste 22 25 28 31 34
Prazo (%)
Orgnico Planos e Requisitos 10 11 12 13
Projeto do Produto 19 19 19 19
Programao 63 59 55 51
Integrao e Teste 18 22 26 30
Difuso Planos e Requisitos 16 18 20 22 24
Projeto do Produto 24 25 26 27 28
Programao 56 52 48 44 40
Integrao e Teste 20 23 26 29 32
Restrito Planos e Requisitos 24 28 32 36 40
Projeto do Produto 30 32 34 36 38
Programao 48 44 40 36 38
Integrao e Teste 22 24 26 28 30

Tabela 6-18 - Distribuio do Esforo do Exemplo

Orgnico Planos e Requisitos .06 x 145 = 8.7
Projeto do Produto .16 x 145 = 23.20
Programao .62 x 145 = 89.90
Integrao e Teste .22 x 145 = 31.90

Tabela 6-19 - Distribuio do Prazo Para o Exemplo

Orgnico Planos e Requisitos .12 x 16.5 = 1.98
Projeto do Produto .19 x 16.5 = 3.14
Programao .55 x 16.5 = 9.08
Integrao e Teste .26 x 16.5 = 4.29

Para tamanhos de software diferentes dos tamanhos da tabela padro, mas que
estejam dentro dos limites 2 - 512, podemos empregar a interpolao aritmtica a fim
determinarmos a distribuio do esforo e prazos por fases.

A estimativa do quantitativo de pessoal necessrio para cada fase obtida

dividindo-se a distribuio do esforo pela de prazo.

Tabela 6-20 - Distribuio do Quantitativo de Pessoal Por Fase Para o Exemplo

Orgnico Planos e Requisitos 8.7 1.98 = 4.39 ou 4
Projeto do Produto 23.20 3.14 = 7.39 ou 7
Programao 89.90 9.08 = 9.90 ou 10
Integrao e Teste 31.90 4.29 = 7.44 ou 7

6.4.8 - Estimativa de Custo do Projeto

A mesma conceituao e procedimentos que foram explicados no item 6.3.5 so

empregados com os resultados do mtodo COCOMO.

6.5 - Estimativas Utilizando Regresso Linear

A regresso linear uma tcnica estatstica que permite realizar previses atravs
da determinao do tipo de associao entre variveis.
 A regresso linear simples, associa duas variveis entre si. Por exemplo, uma
varivel funo de outra varivel.

Defeitos de um software = f ( Tamanho em Function Points)

Atravs da equao de regresso linear podemos determinar ou prever o valor da

outra varivel. No exemplo anterior, tendo-se um certo nmero de observaes de
defeitos de software e de tamanho do software em function points, e um dado valor
atribudo ao software em pontos de funo, podemos prever o nmero de defeitos
esperados para o software.

A regresso no s apresenta a relao linear positiva como tambm a negativa.

Isto significa dizer que, no caso de associao positiva, quando o valor de uma varivel
cresce, o valor da outra tambm cresce. No caso de associao negativa acontece o
inverso.

A forma geral da equao de regresso linear para dados de uma amostra :

__
Y x = a + bX
onde: __
Yx o valor estimado da varivel dependente, dado um valor especfico
da varivel independente X
a o ponto de interseco da linha de regresso linear com o eixo Y
b a declividade da linha de regresso
X o valor especfico da varivel independente

H diversos critrios matemticos para o desenvolvimento de uma equao de

regresso.

Pelo mtodo dos mnimos quadrados , a equao de regresso melhor ajustante

aquela para a qual mnima a soma dos quadrados dos desvios entre os valores
observados e estimados da varivel dependente em funo dos dados amostrais.

As frmulas pelas quais os valores de a e b da equao so determinados, a fim

de satisfazer o critrios dos mnimos quadrados, so:
_ _
XY - nX Y
b= 2 _2
X - nX
_ _
a = Y - bX

Formulada a equao de regresso, podemos estimar o valor da varivel

dependente dado o valor da varivel independente. Entretanto, tal estimativa deve ser
feita apenas dentro do intervalo de variao dos valores da varivel independente.

Vide Kazmier 7 para obter maiores detalhes sobre regresso linear e outros tratamentos
estatsticos.
 Para auxiliar na demonstrao da aplicao da regresso linear, usaremos a
Tabela 6-21 .

Tabela 6-21 - Data Set de Variveis de Tamanho e Defeitos

Observaes Tamanho do Defeitos do 2 2
Software em Software XY X Y
PFs - X Y
1 10 6 60 100 36
2 20 24 480 400 576
3 40 32 1280 1600 1024
4 80 192 15360 6400 36864
5 160 384 61600 25600 147456
6 320 768 245760 102400 589824
7 640 1536 983040 409600 2359296
8 1280 3072 3932160 1638400 9437184
9 2560 6144 15728640 6553600 37748736
10 5120 12288 62914560 26214400 150994940
Totais 10230 24446 83882940 34952500 201315940
Mdia 1023 2444,60

6.5.1 - Estimativa do Nmero de Defeitos Pr-Release

A equao da regresso neste caso :

Defeitos Pr-Release = f ( Tamanho do Software em Pontos de Funo)

Supondo que a estimativa do tamanho do software seja 1200, queremos

determinar qual o nmero de defeitos pr-release esperado.

Determinao dos Valores de a e b

XY - nX Y
b=
2 _2
X - nX

_ _
a = Y - bX

b = 62914560 - 10 (1023) (2444,60) = 1,55

2
34952500 - (10) (1023)

a = 2444,60 - (1,55) (1023) = 860.99 ou 861

Aplicar a e b Na Equao de Regresso

_
Y x = a + bX = 861 + 1,55 x 1200 = 2721 defeitos esperados
6.5.2 - Estimativa do Nmero de Defeitos Ps-Release

A equao de regresso neste caso :

Defeitos Ps-Release = f( Tamanho do Software em Pontos de

Funo)

Analogamente aplicao anterior, deveria ser estruturado um data set que

contivesse todas as observaes acerca de defeitos ps-release para os tamanhos
correspondentes dos software em pontos de funo a fim de aplicar a equao de
regresso e realizar a estimativa.

6.5.3 - Estimativa do Esforo de Retrabalho

O retrabalho no desenvolvimento de software est associado ao nmero de

defeitos encontrados no software ao longo do projeto.

Ou seja, a equao de regresso :

Esforo de Retrabalho = f( Nmero de Defeitos Pr-Release)

Para tanto o data set deveria conter dados acerca do esforo de retrabalho
conforme o tamanho do software em pontos de funo.

Este raciocnio tambm vlido para a estimativa de esforo de retrabalho durante

a manuteno do software.

6.5.4 - Estimativa do Custo de Retrabalho

Como o esforo o principal componente de custo, a equao de regresso para

determinar o custo estimado do retrabalho, tanto para defeitos pr-release como ps-
release :

Custo do Retrabalho = f( Esforo de Retrabalho)

Outra alternativa seria multiplicarmos o custo mdio do homem/ms ou

homem/hora pelo esforo estimado.

REFERNCIAS

1. BANDEIRA, Alfredo. Acompanhamento do Custo de Sistemas. SUCESU-DF, Anais do

Congresso Regional de Informtica,Braslia, 1984.

2. BOEHM,Barry . Software Engineering Economics. Prentice-Hall,Englewood

Cliffs,New Jersey, 1981.

3. FENTON, N.E. Software Metrics: a rigorous approach. Chapman & Hall, London,
1991.
4.FERNANDES, A.A. & KUGLER,J.L.C. Gerncia de Projetos de Sistemas:uma
abordagem prtica. Livros Tcnicos e Cientficos Editora S.A., Rio de Janeiro,
2a. edio,1990.

5. IFPUG. Function Points Counting Practice Manual - Release 4.0.

Westerville,Ohio,1994.

6. JONES,Capers. Applied Software Measurement. McGraw- Hill, New York ,1991.

7.KAZMIER,L.J. Estatstica Aplicada a Economia e Administrao. McGraw-Hill,So

Paulo,1982.
Captulo
7
APLICAO DAS MEDIES NO
PROCESSO DE DESENVOLVIMENTO
DO SOFTWARE

O objetivo principal para aplicar medies na gesto do projeto est associado aos
seguintes aspectos:

Atingimento do prazo inicialmente previsto

Atingimento do oramento inicialmente previsto
Gerao de um produto de software de boa qualidade, adequado ao uso
Satisfao do cliente/usurio
Prover a gerncia do ambiente de desenvolvimento com as informaes
requeridas para a melhoria dos processos de planejamento,
desenvolvimento de software e projeto e gesto do produto

Para tanto preciso controlar/monitorar o processo de desenvolvimento visando

manter a produtividade nos nveis previstos ou padres, remover defeitos introduzidos no
produto o quanto antes no processo, reduzindo ou eliminando o esforo de retrabalho,
consequentemente mantendo o oramento sob controle.

O processo de gesto, que conta com uma srie de atributos, tais como gesto
dos recursos, reviso e refinamento do planejamento, gesto financeira,gesto da
documentao e objetos, gesto das mudanas, a realizao de medies e inspees e
a avaliao final do projeto, atua sobre um processo de desenvolvimento de software que
representado pela metodologia de desenvolvimento.

Neste captulo, similarmente ao anterior, procuramos descrever os princpios

fundamentais do processo de gesto, dando destaque especial para o processo de
inspeo formal de software e de avaliao do projeto para aps, detalharmos as
medies que devem ser aplicadas.

7.1 - O Processo de Gesto de Projetos

O Processo de Gesto do Projeto composto por um conjunto de elementos ou

atributos como mostra a Figura 7-1.

O Processo de Gesto atua sobre um processo de desenvolvimento, geralmente

representado por uma metodologia composta por fases,etapas e atividades, assim como
padres de construo (tcnicas,mtodos e ferramentas) e padres de apresentao de
produtos.

Na Figura, o processo de desenvolvimento est representado por 7 fases,quais

sejam:
 Gesto da Controle do Gesto Gesto das
Qualidade Progresso Financeira
Mudanas

MEDIES E ANLISES

Instala- Anlise Especifi- Prototipa- Projeto De- Implementa- Implanta-

o Preliminar cao o talhado o o

Avalia-
PROCESSO DE INSPEO o

MONITORAMENTO

Figura 7-1
O Processo de Gesto do Processo de Desenvolvimento

Instalao do Projeto

A instalao do projeto tem como objetivo formalizar o seu incio junto aos
clientes/usurios participantes. Com este procedimento, procura-se criar
visibilidade para o projeto perante o cliente, assim como obter comprometimento
quanto s metas perseguidas.

A instalao do projeto deve ocorrer por meio de uma Reunio de Instalao do

Projeto a qual o primeiro servio a ser desenvolvido independente do roteiro
metodolgico a ser seguido.

A reunio de instalao deve ser considerada como o ponto de partida real do

projeto.

Nesta reunio so apresentados os objetivos e escopo do projeto, premissas e

diretrizes que nortearo o projeto, o modelo de gesto do projeto, as
responsabilidades tanto do cliente/usurio como da rea de desenvolvimento, os
critrios de resoluo de pendncias, o cronograma mestre resumido do projeto
calendarizado e o cronograma de atividades cuja responsabilidade principal do
cliente/usurio.

Devem participar todas as pessoas que sero envolvidas de forma direta ou

indireta no esforo do projeto.

Anlise Preliminar
 Consiste no esforo necessrio para entender o negcio do cliente/usurio a fim
de propor solues informatizadas, na elaborao do modelo de dados preliminar,
na elaborao de estimativa de tamanho do software, no estabelecimento de
alternativas de soluo e na identificao preliminar das principais funes da
soluo. O produto desta fase o Projeto Preliminar ou Ante-Projeto.

Especificao

Refere-se elaborao do projeto lgico do software, incluindo a elaborao do

modelo funcional e de dados ou o modelo essencial do sistema, do modelo
operacional preliminar do sistema (Diagrama Hierrquico do Sistema-DHS), dos
procedimentos de segurana e controle, do projeto de dilogo,do projeto de
normalizao e assim sucessivamente. O produto desta fase o Projeto de
Especificao.

Prototipao

Refere-se elaborao de verses de um prottipo do sistema conforme

especificado na fase anterior. Geralmente pode ser construdo um prottipo com
funcionalidade mnima apresentando telas de entradas e sadas, o que na
linguagem tcnica significa mock-up. Na prototipao que as especificaes
so validadas pelos clientes/usurios. Esta fase pode ser realizada
concomitantemente com a fase anterior e gera como produto o prottipo do
sistema.

Projeto Detalhado

Consiste na elaborao do modelo de armazenamento de dados, na identificao

das necessidades de acesso ao banco de dados, no projeto fsico do banco de
dados, no projeto de rotinas automatizadas, na definio das regras de integridade
do banco de dados e na reviso do modelo operacional preliminar do sistema.
Gera como produto o Projeto Fsico o qual tambm deve ser homologado
formalmente pelo cliente/usurio.

Implementao

Abrange a codificao das rotinas automatizadas, a criao do banco de dados, o

teste individual de programas, o teste de mdulos, o teste integrado do sistema, o
teste de aceitao do cliente/usurio, a realizao de acertos que porventura
houverem, o ajuste no banco de dados e a disponibilizao do produto para ser
implantado em ambiente operacional. Gera como produto o software para ser
testado em campo.
Implantao

Apesar desta fase geralmente encontrar-se dentro do contexto do projeto, onde os

compromissos com prazos e resultados j foram feitos junto ao cliente/usurio, esta fase, a
rigor no deveria fazer parte do projeto; deveria ser considerada no esforo de
planejamento.
Refere-se ao planejamento da implantao, treinamento dos clientes/usurios na
operao do novo sistema, execuo do sistema no campo e, se for o caso,
passagem para a produo, bem como o atendimeno inicial.

As Medies referem-se coleta de dados sobre prazo, esforo, custo de cada

fase, defeitos encontrados e removidos e outros atributos do processo, assim
como a medio do tamanho do software ao final do projeto. As medies so
necessrias para a gesto do processo de software como um todo
(compreendendo aes para a melhoria contnua), bem como para o projeto de
desenvolvimento.

O Processo de Inspeo,que ser detalhado mais adiante, efetivado em pontos

especficos do processo de desenvolvimento. A inspeo tem como objetivo
detectar defeitos introduzidos no projeto e acompanhar sua resoluo,
assegurando a conformidade dos produtos com os requisitos e especificaes.

Para realizarmos as inspees necessrio que o processo gere produtos

intermedirios 100% inspecionveis. O progresso de qualquer projeto somente
perceptvel com produtos intermedirios 100% acabados.

A Avaliao do projeto tem como objetivo registrar informaes sobre:

Aspectos tcnicos do projeto e do processo de desenvolvimento, visando

alimentar uma base de dados que possa subsidiar o planejamento de
novos projetos
Eventos que contribuiram para a variabilidade do processo, visando
subsidiar a ao corretiva correspondente a fim de eliminar as fontes de
no conformidade
Percepo do cliente/usurio a respeito da qualidade do desenvolvimento
do projeto
Percepo do cliente/usurio a respeito da adequao ao uso do software

A Gesto da Qualidade enfatiza a remoo de defeitos nos produtos que so

introduzidos durante o processo de desenvolvimento . Dessa forma preciso
monitorar o progresso na remoo de defeitos, verificar defeitos restantes, analisar
os defeitos em termos de sua composio, origem, verificar a distribuio de
defeitos por mdulo do software, analisar a eficincia do processo de inspeo,
identificar mdulos propensos a erros, determinar a densidade de defeitos do
software entregue e comparar com padres e determinar a intensidade de falhas
esperada para o produto a fim de prover a gesto do produto com informaes
necessrias para alocao de recursos para manuteno.

O Controle do Progresso contempla o refinamento do planejamento, o

replanejamento do projeto, base para o acompanhamento fsico, bem como a
verificao do progresso do desenvolvimento dos produtos intermedirios do
projeto conforme o roteiro metodolgico de trabalho adotado.

O refinamento do planejamento requerido na medida em que o projeto avana.

Isto ocorre quando temos uma maior compreenso da soluo, quando so
registradas atividades realizadas e que no haviam sido previstas inicialmente,
quando, em funo de um maior conhecimento da soluo, prevem-se novas
 atividades a serem realizadas e quando, ao trmino de uma fase do projeto,
necessitamos desdobrar as atividades da prxima fase.

O refinamento no deve ser confundido com replanejamento. Este geralmente

ocorre em funo de atrasos, antecipaes ou por mudana de escopo do projeto.

Uma das preocupaes em refinar o planejamento inicial do projeto manter o

registro de como o mesmo foi conduzido e determinar, para uso futuro, o melhor
roteiro metodolgico para projetos de mesma natureza, alm de, naturalmente,
propiciar a gerncia efetiva do projeto em curso.

O replanejamento do projeto necessrio quando h solicitaes feitas pelo

cliente/usurio que impactam o projeto e h ocorrncias de eventos
(contingncias) que tambm impactam o projeto.

O replanejamento pode caracterizar-se por alteraes nos prazos previstos e/ou

na alterao do roteiro metodolgico inicial. Ateno deve ser dada ao controle
das verses do planejamento.

A Gesto Financeira e de Recursos abrange o controle do oramento, cotejando

continuamente o realizado contra o previsto, a verificao do custo restante ou
previso de custo adicional, bem como na alocao, realocao, qualificao e
substituio dos recursos orados para o projeto em termos de recursos humanos,
recursos computacionais e demais tipos de recursos/servios. Esta funo, no
mbito de um projeto crucial, visto ser a base para os registros de
esforo(homem/ms) alocado s fases/etapas/atividades, bem como para os
registros da alocao de outros recursos. Estes regisros tambm vo determinar
os custos reais do projeto.

A Gesto de Mudanas contempla o controle de mudanas no escopo do

projeto, a anlise das mudanas, a manuteno da documentao tcnica e
gerencial pertinente e a elaborao de simulaes de impacto sobre o projeto.

Um dos principais problemas na gesto de projetos de software a alterao

constante do escopo do projeto, ou em funo de mudanas nos requisitos dos
usurios ou em funo de eventos inesperados, tal como mudana de legislao.

A gerncia do projeto, neste caso, deve evidenciar, atravs de simulaes, o

impacto sobre prazos e, principalmente custos. Esta funo d o start para o
replanejamento.

A gesto de mudanas tambm contempla a gesto da documentao tcnica e

objetos (componentes de software), da documentao gerencial e as respectivas
verses.

De acordo com Frederick P. Brooks 3 um dos principais fatores de insucesso em

projetos de software a inexistncia de um calendrio detalhado de eventos.
 A documentao tcnica do projeto refere-se aos documentos (produtos) de
especificao, projeto detalhado,implementao, implantao e componentes de
software e verses.

A documentao gerencial abrange o conjunto de documentos pertinentes s

informaes sobre a gesto do projeto em termos de:

Cpia do estudo preliminar, ante-projeto ou proposta tcnica

Cpias de Atas de Reunio
Cpias de homologaes de produtos intermedirios
Cpias de registros de ocorrncias
Cpias das anlises das solicitaes de alteraes de escopo
Cpia do cronograma original (1a. verso) e verses consecutivas
Quadro de alocao de recursos e verses consecutivas
Cpias de comunicaes expedidas e recebidas
Cpia da avaliao do projeto

O Monitoramento do projeto, por sua vez, abrange a anlise das informaes

quantitativas sobre o processo de desenvolvimento , das informaes sobre
inspeo , sobre recursos, planejamento, financeiras, produtos intermedirios
(documentos) e sobre mudanas a fim de apoiar processos de tomada de deciso
que sejam necessrios.

Geralmente o monitoramento ocorre em pontos intermedirios do processo ou

pontos de controle a fim de verificar o grau de atingimento das metas, nvel da
qualidade, decidir sobre pendncias e assim sucessivamente.

O monitoramento deve ser feito junto com o cliente/usurio e pode ser agendado
desde o incio do projeto. Dependendo do porte e importncia do projeto,
recomendvel a criao de Comit Gerencial.

7.2 - O Processo de Inspeo Formal de Software

O Processo de Inspeo de Software o principal meio pelo qual a qualidade do

processo pode ser medida; a base para a gerncia do processo de desenvolvimento.

De acordo com Ebenau & Strauss 6 , inspees no processo so meios de

verificar produtos intelectuais pelo exame manual dos mesmos, atravs de pequenas
equipes, para assegurar a conformidade dos produtos com especificaes e
requerimentos.

O objetivo principal do processo de inspeo a deteco de defeitos e a

remoo subsequente dos mesmos.
 No objetivo da inspeo a avaliao das decises conceituais sobre a soluo
que est sendo desenvolvida. Tal tipo de avaliao pode ser feita em processos de
Walkthroughs os quais so menos formais que os de inspeo.
Um processo de inspeo para se tornar vivel depende dos seguintes fatores:

Capacitao do pessoal tcnico para realizar inspees

Conhecimento do pessoal tcnico acerca do ambiente de desenvolvimento,
mtodos e tcnicas de projeto de software
Um processo de desenvolvimento claramente definido
Checkpoints em estgios intermedirios no processo
Produtos intermedirios claramente definidos (work-products) no contexto
do processo de desenvolvimento
Uso efetivo das informaes coletadas pela inspeo para melhorar a
qualidade do produto, do processo e dos mtodos de gesto
Avaliar o processo e produto e no pessoas ( importantssimo)
Atributos a serem medidos devem estar claramente definidos

Do ponto de vista econmico a inspeo permite reduzir os custos de

desenvolvimento, pela reduo do esforo de retrabalho.

A Figura 7-2 mostra a relao do custo para identificar e remover defeitos entre as
fases de desenvolvimento do software.

Custo Relativo Figura 7-2

1000

500

200

100

50

20

10

Requisitos Projeto Codificao Teste Aceitao Operao

A aplicao da Inspeo , desde o incio do processo de desenvolvimento, permite

obter uma primeira indicao quantitativa da qualidade do produto que est sendo
construdo, ao contrrio do que ocorre quando utilizamos somente metotologia de teste.

A Figura 7-3 demonstra este aspecto.

Vide a referncia 12 , para uma apreciao detalhada sobre Walkthrough.

Vide o captulo 13, o qual trata sobre questes ticas quanto ao uso de medies em
software.
 SEM INSPEES

Projeto

Codificao

Teste

Primeira indicao quantita-

tiva da qualidade - a partir
dos resultados do teste

Cronograma

COM INSPEES

Projeto

Io
Codificao

I1 I2

Teste
Primeira indicao
quantitativa da qua-
lidade
Custo de Remoo de Defeitos

Figura 7-3
Inspeo e Indicao Quantitativa da Qualidade

Segundo David Card 5 , 81% dos defeitos introduzidos em um software so

oriundos da fase de projeto. Este mais um dos motivos pelos quais importante aplicar
a inspeo desde o incio do projeto do software.

Mesmo com este dado estatstico, o rigor dos procedimentos de inspeo devem
ser homogneos ao longo do desenvolvimento, particularmente no Brasil, onde os
requisitos e consequentemente as especificaes sofrem constantes alteraes.
 A inspeo pode ser aplicada em vrias etapas do processo de desenvolvimento
como mostra a Figura 7-4.

ANLISE PRELIMINAR Inspeo de Planos de Projeto

ESPECIFICAO Inspeo de Conceitos e de

Requisitos

PROTOTIPAO Inspeo do Prottipo

PROJETO Inspeo do Projeto

DETALHADO

IMPLEMENTAO
Inspeo de Requisitos e Projeto

Figura 7-4
Inspees No Processo do Software

O Processo de Inspeo composto por 5 etapas, ou seja:

Planejamento
Viso Geral
Preparao
Reunio
Retrabalho
Acompanhamento

A Tabela 7-1 mostra a descrio e os objetivos de cada etapa

Tabela 7-1 - Etapas do Processo de Inspeo 6
Etapa Descrio
Planejamento Estabelecimento de
cronograma; selecionar
inspetores; obter e distribuir
material
Viso Geral Apresentao pelo autor, do
trabalho a ser inspecionado
Preparao Estudo individual do material
Objetivos
Assegurar que os
prazos,participantes e materias
estejam disponveis
Prover entendimento sobre o
material a ser inspecionado
Preparar os participantes a
 a ser inspecionado identificar defeitos
Reunio Exame formal do material Identificar e registrar os
distribudo defeitos
Retrabalho Revisar o produto Resolver problemas
Acompanhamento Verificar a resoluo Certificar a reviso pelo autor e
satisfatria dos defeitos completar a inspeo
identificados

Estas etapas compem uma sequncia natural de conduo do processo de

inspeo, a qual prev a gerao de produtos.

Produto Etapa de Etapa de

Planejamento Viso Geral

Notificao de Etapa de
Inspeo Preparao

Etapa de Etapa de
Reunio de Ins- Retrabalho
peo

Lista de
Defeitos Sumrio de
Defeitos
Etapa de
Produto
Acompanhamento
Inspecionado

Fonte 6
Relatrio
Gerencial
Figura 7-5
Fluxo Do Processo de Inspeo

Note que o produto a ser inspecionado pode ser um deliverable intermedirio a

uma fase, por exemplo, o modelo de dados juntamente com o dicionrio de dados,
pertencente fase de especificao, ou o produto final de uma fase. Os itens a serem
selecionados para sofrerem inspeo dependem do prazo e porte do projeto. Entretanto
devem consistir naqueles produtos que so crticos para o sucesso do projeto.

A Tabela 7-2 descreve cada uma das etapas do processo de inspeo,

considerando as entradas, o processo e as sadas.
Tabela 7-2 - Descrio das Etapas do Processo de Inspeo 6
Entradas
Planejamento
1. Work-Product completado
2. Critrio de entrada da inspe-
o tores
3. Taxa de inspeo
Viso Geral
1. Produto a ser inspecionado
2. Materiais relacionados
3. Auxlios Visuais
4. Sala de reunio
Preparao
1. Produto a ser inspecionado
2. Notificao de reunio de
inspeo
3. Checklists de inspeo
4. Tempo de preparao
recomendado
Reunio de Inspeo
1. Produto a ser inspecionado
2. Referncias necessrias
3. Tempos de preparao dos
inspetores
4. Anotaes de preparao
dos inspetores
5. Checklist de inspeo
6.Notificao de reunio de ins-
peo
Processo Sadas
1. Moderador verifica atendi- 1. Critrios de entrada verifica-
mento dos critrios de entrada dos
do produto a ser inspecionado
2. Moderador seleciona inspe- 2. Notificao de reunio de
inspeo
3. Moderador determina a ne- 3. Reserva de sala para a re-
cessidade pela viso geral unio
4. Moderador cronograma a Materiais de inspeo
inspeo
1. Moderador conduz reunio 1. Conhecimento do produto a
preliminar para entendimento ser inspecionado
do produto
2. Autor apresenta o produto 2. Respostas questes
para moderador e inspetores
3. Moderador determina a pre- 3. Atribuio de responsabili-
parao e responsabilidades dades
de leitura do material
1. Estudo, pelos inspetores, do 1. Conhecimento do material
material a ser inspecionado
2. Determinao sobre como o 2. Anotao dos defeitos
produto ser apresentado
3. Inspetores registram seu 3. Registro do tempo de
tempo de preparao preparao
1. Moderador inicia a reunio e 1. Lista de defeitos iden-
verifica tempos de preparao tificados
2. Leitura do produto 2. Relatrio da reunio de
inspeo e sumrio de defeitos
3. Defeitos so identificados e 3. Disposio do produto
registrados
4. Lista de defeitos revisada
e a disposio do produto
determinada
5. Relatrio da reunio e sum-
rio de defeitos so completa-
dos
Tabela 7-2 - Descrio das Etapas do Processo de Inspeo (Continuao)
Retrabalho
1. Lista de defeitos identifica-
dos
2. Disposio do produto
3. Cronograma para o modera-
dor revisar ou reinspecionar o
retrabalho
Acompanhamento
1. Produto revisado
2. Se for uma reinspeo con-
siderar as entradas das etapas
de planejamento,viso geral,
preparao e reunio de inspe-
o
1. Autor resolve a lista de de-
feitos
1. Moderador verifica o atendi-
mento, pelo produto, dos cri-
trios de sada
2. Considerar os processos
das 4 primeiras etapas
3. Moderador completa o rela-
trio de inspeo
1. Produto revisado
2. Moderador notifica o
trmino do retrabalho
1. Produto inspecionado
2. Se a disposio do produto
for condicional ou rejeitado,
considerar as sadas da etapa
de reunio de inspeo
3. Relatrios de inspeo
completados

No Processo de Inspeo os membros da equipe desempenham os seguintes

papis:

Autor o indivduo responsvel pela elaborao do produto epela

realizao de mudanas exigidas em funo da inspeo

Moderador o indivduo que assegura que os procedimentos so

seguidos; gerencia o processo de inspeo

Leitor o responsvel por conduzir a equipe de inspeo na leitura do

material durante a reunio de inspeo

Registrador o indivduo responsvel por registrar e classificar todos os

defeitos identificados na reunio de inspeo

Inspetor representado por todos os membros da equipe de inspeo,

incluindo o autor; sua responsabilidade a de identificar defeitos

Durante a reunio de inspeo, o produto inspecionado pode receber a seguinte

disposio:

Produto Aceito, ou seja, atende as especificaes e os critrios de sada

da inspeo (no est porm, totalmente livre de defeitos)

Produto Aceito Condicionalmente; neste caso h alguns defeitos

significativos os quais podem ser removidos, (necessitando de retrabalho)
com a reviso pelo moderador junto ao autor, sendo que os defeitos no
criam mudana relevante para o produto em termos de conformidade
 Produto a Ser Reinspecionado, ou seja, o produto deve passar
novamente pelas etapas de reunio de inspeo, retrabalho e
acompanhamento

Em equipes pequenas de projeto sugere-se que o prprio lder se responsabilize

pelo papel de moderador, enquanto os demais membros pelo papel de inspetores.

Algumas empresas de classe mundial 4, 11, 13, tm obtido grande sucesso

com a aplicao do processo de inspeo. Este sucesso tem sido traduzido em projetos
nos prazos e economias no custo (oramento) , tanto para a fase de desenvolvimento do
software como para a de manuteno/evoluo.

Pelo investimento em inspeo, reduz-se significativamente os custos de m

qualidade de falha interna e externa.

Visto os conceitos bsicos relevantes para a gesto do processo de

desenvolvimento, iremos detalhar as medies necessrias nesta fase do ciclo de vida do
software.

7.3 - Medies no Processo de Desenvolvimento de Software

Como vimos pelo modelo que denominamos de mecanismo de medio, as

medies no processo de desenvolvimento do software tm vrios propsitos, quais
sejam:

Medies para a gesto do prprio processo

Medies para atender gesto do produto
Medies para subsidiar o aperfeiomento do processo de planejamento de
projetos, a ser utilizado por todos os projetos da instalao
Medies para subsidiar o aperfeioamento do processo de software, a ser
utilizado por todos os projetos da instalao

PROCESSO PRODUTO

PROCESSO DE PROCESSO DE
PLANEJAMENTO SOFTWARE
DE PROJETOS

Figura 7-6
Medies Realizadas Durante do Desenvolvimento

Antes mesmo de comear o projeto propriamente, j devemos registrar algumas

informaes no Banco de Dados de Mtricas e Projetos.
 Essas informaes , maioria de carter subjetivo, vo subsidiar a avaliao final do
projeto, bem como delinear as caractersticas do ambiente de desenvolvimento visando
possibilitar a verificao, a posteriori, de fatores crticos que possam afetar a qualidade e
produtividade do processo de desenvolvimento.

Dessa forma comearemos por listar estas informaes.

7.3.1- Informaes Que Devem Ser Coletadas No Incio do Desenvolvimento

No incio do projeto o software deve ser caracterizado. A caracterizao consiste

numa srie de atributos que qualificam o projeto em termos de:

Ambiente de hardware/software de desenvolvimento

Perfil preliminar da equipe do projeto
Abrangncia do software em termos organizacionais ou de mercado
Classe e tipo do software, se software produto, se comercial,controle
de processos, software de misso crtica etc.
Caracterizao do ambiente de apoio ao desenvolvimento
Utilizao de mtodos e tcnicas de gesto do projeto
Metodologia de desenvolvimento a ser empregada
Mtodos e tcnicas de remoo de erros a serem utilizadas

Estas informaes na realidade so variveis as quais podem ser tratadas

estatsticamente para determinar qual a combinao de fatores que levam a uma melhor
qualidade e produtividade do processo de desenvolvimento.

Ao final do projeto esta qualificao inicial comparada com o que de fato ocorreu
para fins de anlise de causas.

Se estivermos usando um banco de dados de projetos e de mtricas, estas

informaes constituiro os dados de identificao do projeto.

7.3.2 - Medies Para a Gerncia do Processo de Desenvolvimento

Aqui as medies podem ser visualizadas conforme as principais funes

desempenhadas pela gerncia e as metas estipuladas no planejamento do projeto em
termos de prazos, esforo, custo e qualidade.

De acordo com a Figura 7-1, que mostra o esquema de gesto do processo de

desenvolvimento, as funes principais so:

Gesto da Qualidade
Gesto do Progresso
Gesto Financeira
Gesto de Mudanas

Ainda neste captulo, quando da discusso da avaliao final do projeto, mostrada a

forma sobre como estas variveis so mensuradas.
 Decidimos, para a melhor compreenso da aplicao das medies, apresent-las
conforme este modelo.

Medies Para a Gesto da Qualidade

A gesto da qualidade do processo de desenvolvimento visa fundamentalmente a

remoo de defeitos nos produtos que vo sendo gerados ao longo do processo. Na
realidade uma abordagem preventiva.

Para fins de medio qual o significado de defeitos, falhas e bugs?

Uma definio simples para Defeitos : um problema com o produto que

detectado em algum ponto do desenvolvimento. Falhas ocorrem quando o produto no
desempenha a tarefa requerida pelo cliente/usurio (conforme especificaes) durante a
sua operao. J bug um defeito no programa que encontrado durante a sua
operao , tanto no teste como durante o seu uso.

importante notar que defeitos e falhas no so sinnimos. Falhas podem ser

causadas por defeitos. Destacamos a palavra podem, em virtude de que nem sempre um
defeito causa uma falha. Por exemplo, um defeito de no atendimento do padro de
programao pode no criar uma falha caso a lgica estiver correta.

Adicionalmente, a instalao deve possuir uma classificao dos defeitos para fins
de monitorar o processo e identificar as principais causas de introduo dos mesmos nos
produtos.

H vrias forma de classificao de defeitos, algumas mais detalhadas do que

outras, porm todas com o mesmo propsito.

A mais abrangente fornecida por Beizer 1 , cuja classificao apresentada

resumidamente a seguir.

Tabela 7-3 - Classificao de Defeitos

Tipos de Defeitos Sub-Tipos
Funcionais
Requisitos Incorretos
Completeza dos Requisitos
Verificabilidade dos Requisitos
Documentao dos Requisitos
Mudanas de Requisitos
Implementao de Funes
Acertos na Implementao
Completeza das Features
Completeza de Condies
Domnio de Variveis
Mensagens
Condies de Exceo
Tabela 7-3 - Classificao de Defeitos (Continuao)
Estruturais
Controle do Fluxo do Programa
Processamento
Dados
Definio, Estrutura e Declarao
de Dados
Tratamento e Acesso aos Dados
Implementao
Edio de Programas
Violao de Padres de Programao
Documentao de Programas
Integrao
Interfaces Internas
Interfaces Externas
Arquitetura do Software
Uso do Sistema Operacional
Arquitetura do Software
Recuperao de Falhas
Desempenho
Diagnstico Incorreto
Partio Incorreta
Execuo do Teste
Projeto do Teste
Execuo do Teste
Documentao do Teste
Completeza do Teste

As medies relativas gesto da qualidade enquadram-se dentro de cinco

categorias: para o monitoramento de defeitos, para a anlise de defeitos, para a anlise
do processo, para a anlise de complexidade dos mdulos e para a confiabilidade
esperada do produto.

A gesto da qualidade dentro deste prisma est intimamente relacionada com o

monitoramento do progresso do projeto e de seus aspectos financeiros.

Monitoramento de Defeitos

Os objetivos das medies so:

Verificar o progresso na remoo de defeitos ao longo do calendrio de

execuo do projeto
Verificar os desvios entre o realizado e as estimativas

Progresso na Remoo de Defeitos

Objetivo: Verificar o progresso na remoo de defeitos ao longo do

desenvolvimento.
Mtodo de Determinao: Plotar o nmero cumulativo de defeitos identificados
ao longo do calendrio de execuo do projeto.
Fonte de Informaes: processo de inspeo e cronograma atualizado do
projeto.
Forma de Apresentao: grfica.
Ao Gerencial: No caso de haver desvio entre defeitos identificados e
removidos, o gerente de projeto poder verificar a produtividade da inspeo ( taxa
de inspeo ) , bem como avaliar a produtividade da remoo de defeitos( que a
fase de acompanhamento do processo de inspeo)
Exemplo:

Defeitos Identificados Defeitos Removidos

50

40
Defeitos
Cumulativos 30

20

10

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Semanas
Figura 7-7

Neste exemplo, entre as semanas 8 e 17 houve atraso na remoo dos defeitos.

Defeitos Restantes

Objetivo: Estimar o nmero de defeitos restantes no projeto a partir do trmino de

uma determinada fase do projeto
Mtodos de Determinao: aqui podemos vislumbrar dois mtodos.
Mtodo #1:
Estimativa Atualizada de Defeitos Pr-Release - Defeitos Cumulativos At
a Fase

A estimativa atualizada pode ser determinada a partir do clculo atualizado

dos pontos de funo do software. Os clculos dos pontos de funo
podem ser elaborados ao final do projeto lgico e ao final do projeto fsico.
O raciocnio a ser utilizado o mesmo que foi demonstrado no captulo 6
em relao metodologia #1 da Anlise Por Pontos de Funo.
Mtodo #2:
Projeo de defeitos pelo uso da distribuio de Rayleigh.

Como j apresentado na captulo 6, a distribuio de Rayleigh tambm

pode ser utilizada para estimar o nmero de defeitos restantes para o
projeto, a partir de um determinado ponto no cronograma e considerando a
estimativa atualizada de defeitos pr-release. Esta estimativa no caso,
 prev o nmero de defeitos possveis para cada um dos meses restantes
para o projeto.

Fonte de Informaes: processo de inspeo, o qual registra o nmero

cumulativo de defeitos; o clculo atualizado dos pontos de funo do software.
Forma de Apresentao: grfica e tabular.
Ao Gerencial: De posse de informaes sobre o desempenho das inspees
em termos de taxa de preparao e de exame, juntamente com os dados sobre o
nmero de defeitos restantes no global ou ms a ms, at o trmino do projeto,o
gerente do projeto pode avaliar sobre a necessidade de alocar mais recursos para
a inspeo ou criar novos pontos de inspeo para aumentar a taxa de deteco
de defeitos e assim diminuir a ocorrncia de defeitos.
Exemplo:
Mtodo #1
Supondo a estimativa atualizada do nmero de defeitos esperados do
software, em funo de seu tamanho, em 1000 defeitos e o registro de 500
defeitos at a fase, teramos 500 defeitos restantes.
Mtodo #2
Supondo a estimativa atualizada do nmero de defeitos esperados do
software em 1000 ; o prazo total do projeto 10 meses; se estivermos no 4o.
ms; o 5o. ms o ms de pico do projeto, pelo uso da distribuio de
Rayleigh, os defeitos restantes seriam:

5o. ms 122 defeitos

6o. ms 117 defeitos
7o. ms 105 defeitos
8o. ms 89 defeitos
9o. ms 71 defeitos
10o. ms 54 defeitos Total de 558 defeitos

Desvio da Estimativa de Defeitos

Objetivo: Realizar anlise de sensibilidade em relao s estimativas de defeitos

pr-release esperados.
Mtodo de Determinao: Nmero de Defeitos Identificados No Perodo dividido
pelo Nmero de Defeitos Esperados No Perodo; plotar grficamente.
Fonte de Informaes: processo de inspeo e estimativa atualizada de defeitos
esperados.
Forma de Apresentao: grfica ou tabular.
Ao Gerencial: Caso haja grandes desvios ou desvios sucessivos, o gerente do
projeto pode calibrar a expectativa de defeitos restantes a partir do percentual
mdio do desvio verificado e re-estimar o esforo e custo de retrabalho e alocao
de pessoal para inspeo.
Exemplo:
Supondo o seguinte data set.
Tabela 7-4
Perodo Estimativa de Estimativa de Defeitos Relao
Defeitos (ED) Defeitos (EDA) Identificados DI / DE
Atualizada (DI)
1o. ms 39 50 +28%
2o. ms 74 84 +14%
3o. ms 100 120 +20%
4o. ms 116 117 +1%
5o. ms 122 142
6o. ms 117 136
7o. ms 105 122
8o. ms 89 103
9o. ms 71 82
10o. ms 54 63
Mdia 16%

Neste exemplo, a estimativa de defeitos foi recalibrada com base na variao

mdia da relao DI/DE, ou seja, na mesma proporo.

A mesma tabela poderia ser apresentada de forma grfica conforme mostra a

Figura 7-8 a seguir.

150

Defeitos 130
Cumulativos
110

90

70

50

30

1 2 3 4 5 6 7 8 9 10
Meses
ED DI EDA

Anlise de Defeitos

Os objetivos das medies so:

Identificar a composio dos defeitos

Identificar as classes de defeitos
Verificar a distribuio dos defeitos por fase do projeto
Verificar o nmero de defeitos por mdulo do software, bem como sua
distribuio
 Composio dos Tipos de Defeitos Na Fase

Objetivo: Identificar a frequncia do tipo de defeito por fase do projeto.

Mtodo de Determinao: Tipo de Defeito na Fase dividido pelo Nmero de
Defeitos na Fase. Realizar esta operao para cada um dos tipos de defeitos
identificados na fase.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica
Ao Gerencial: Conforme for a frequncia, em termos percentuais, dos tipos de
defeitos na fase, o gerente deve selecionar aqueles tipos de defeitos que
apresentaram maior ocorrncia para fins de anlise de suas causas, visando criar
contra-medidas para a eliminao ou reduo de sua ocorrncia.
Exemplo:

Supondo a fase de especificao.

80%

70%

60%

Frequncia 50%

40%

30%

20%

10%

RI DO VP DE
Tipos de Defeitos
Figura 7-9

Legenda:
RI - Requisitos Incorretos
DO- Documentao dos Requisitos
VP- Violao de Padres
DE- Definio de Estrutura de Dados

Composio de Defeitos At a Fase

Objetivo: Identificar a frequncia do tipo de defeito at a fase do projeto.

Mtodo de Determinao: Tipo de Defeito at a Fase dividido pelo Nmero
de Defeitos at a Fase. Realizar esta operao para cada um dos tipos de defeitos
identificados na fase.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica
Ao Gerencial: Analisar as causas dos defeitos de maior frequncia, bem como
comparar a intensidade dos tipos de defeitos ao longo do projeto. Caso um tipo de
defeito persistir em termos de frequncia, o gerente pode decidir quanto nfase
das inspees.
 Exemplo:
Especificao Projeto Detalhado
70%

60%
Figura 7-10
50%

40%

30%

20%

10%

RI DO VR DE RI DO VR DE
Legenda:
RI - Requisitos Incorretos VR- Verificabilidade dos Requisitos
DO - Documentao dos Requisitos DE - Definio de Estrutura de Dados

A Figura mostra que houve uma melhoria na intensidade e foco das inspees na
fase de Projeto Detalhado.

Composio das Classes de Defeitos

Objetivo: Identificar as classes de defeitos por fase e at a fase, a partir da

decomposio dos tipos de defeitos.
Mtodo de Determinao: Classe de Defeito de um Tipo de Defeito dividido
pelo Tipo de Defeito. Realizar esta operao para cada um dos tipos de defeitos
identificados , decompondo-os em classes de defeitos.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica
Ao Gerencial: Verificar as causas dos defeitos relativas ao tipo de defeito que
apresentou maior frequncia durante a fase ou at a fase.
Exemplo:

Supondo a defeito RI - Requisitos Incorretos, conforme a Figura 7-11.

50%

40%

Frequncia 30%

20%

10%

Esquecido Incorreto Extra

Classes de Defeitos
Figura 7-11

Distribuio de Defeitos Por Mdulo do Software

Objetivo: Identificar os mdulos candidatos a serem propensos a erros ( mdulos

com erros crnicos).
Mtodo de Determinao: Plotar o nmero de defeitos por mdulo do software.
Fonte de Informaes: Processo de inspeo e diagrama hierrquico do sistema
( de forma simplificada, os mdulos do software so as Unidades de
Implementao conforme o Diagrama de Estrutura de Sistema ou DHS.)
Forma de Apresentao: tabular ou grfica.
Ao Gerencial: A distribuio indica o(s) mdulo(s) com possibilidade de serem
propensos a erros; neste caso o gerente pode decidir monitorar mais de perto os
referidos mdulos ou reprojet-los ou refaz-los.
Exemplo:

Supondo a distribuio dos defeitos conforme a Tabela a seguir e considerando

que os defeitos identificados o foram pela inspeo dos projetos de programas.

Tabela 7-5
Mdulo Defeitos Identificados Frequncia
1 30 10%
2 20 7%
3 10 3%
4 50 16%
5 30 10%
6 20 7%
7 60 20%
8 70 23%
9 10 3%
10 5 2%
Total 305

Neste exemplo o gerente do projeto deveria concentrar-se nos mdulos 4,7 e 8

pois representam mais de 50% dos defeitos identificados.

Anlise do Processo

Os objetivos das medies so:

Avaliar a eficincia das inspees

Identificar mdulos propensos a erros
Avaliar possveis desvios da densidade de defeitos padro

Densidade de Defeitos da Inspeo

Objetivo: Verificar o desempenho das inspees, comparativamente ao padro de

densidade de defeitos da instalao, bem como avaliar a melhoria do processo de
inspeo.
Mtodo de Determinao: Nmero de Defeitos Identificados dividido pelo
Nmero de Linhas do Material Inspecionado.

Geralmente procura-se normalizar esta relao por 1000 linhas, ou referentes a

documentos de especificao ou a instrues fontes. Para se elaborar a
normalizao utiliza-se a regra de trs. Exemplo: 40 defeitos encontrados em 400
linhas inspecionadas de um produto intermedirio, significa uma densidade de 100
defeitos por 1000. A frmula : ( No. de Defeitos Identificados x 1000) dividido
pelo Nmero de Linhas Inspecionadas.

Para analisar o processo , no caso o desempenho das inspees, uma alternativa

a utilizao das tcnicas de controle estatstico, mais especificamente atravs do
grfico de controle.

O grfico de controle, utilizando a definio dada por Feigenbaum 7, um

mtodo grfico para avaliar se um processo est ou no sob controle estatstico.

Esta ferramenta permite comparar a variao da densidade de defeitos dentro de

limites aceitveis.

Existem uma srie de tipos de grficos de controle, cada tipo para atender uma
situao especfica.

No caso do controle estatstico da densidade de defeitos em produtos de software,

utiliza-se o grfico de Nmero de No- Conformidades por Unidade (u), ou
seja, vrias no conformidades independentes (defeitos) podem ocorrer em uma
unidade do Produto (documento de especificao do projeto ou mdulo do
software em instruo fonte). O tamanho de cada subgrupo (n) e o conjunto de
unidades pode variar.

A determinao do grfico de controle dada ento por:

Determinao da mdia de no-conformidades

_
u = de no-conformidades (defeitos)
do no. de unidades (linhas)
inspecionadas

Determinao do Limite Superior de Controle - LSC e do Limite Inferior de

Controle - LIC

_ _
LSC = u + 3 u
n

_ _
LIC = u - 3 u
n
A forma de representao do grfico :

LSC

mdia

LIC

Figura 7-12

Caso os valores de densidade de defeitos estiverem dentro dos limites, considera-

se que o processo est sob controle estatstico.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica.
Ao Gerencial: Valores de densidade de defeitos acima do LSC indicam
produtos propensos a erros; valores abaixo do LIC indicam produtos mal
inspecionados. Para anlise dos indcios, o gerente do projeto deve analisar o
desempenho das respectivas inspees ( cujas densidades esto fora dos
limites) em termos de taxas de preparao e de exame, verificando se esto
dentro dos padres, assim como o tamanho do produto inspecionado.
Exemplo:

Densidade de defeitos de uma inspeo

100 defeitos encontrados

tamanho do produto inspecionado = 1500 linhas
densidade = ( 100 x 1000) 1500 = 66.67 ou 67 defeitos por 1000 linhas.

Confrontar a densidade de defeitos do produto com os limites padres da

instalao para uma dada combinao de plataforma de
hardware/software e metodologia ( processo de desenvolvimento).

80

70
densidade = 67
60

50 LSC

40

30 mdia

20 LIC
10

Figura 7-13
 Neste exemplo o produto inspecionado est com indcios de ser propenso a erros.

Todo o processo de inspeo, ocorrido at um determinado ponto do

calendrio do projeto, pode ser comparado com os limites padres da instalao.

80 Trmino do Projeto Detalhado

70

60

50 LSC

40

30 mdia

20 LIC

10

1 2 3 4 5 6
Figura 7-14

Neste exemplo as inspees 4 e 5 deveriam ser analisadas para verificar as

causas da variao observada.

Densidade de Defeitos Na Fase

Objetivo: Verificar o nvel de defeitos introduzidos na fase do projetoe compar-lo

aos padres de controle da instalao.
Mtodo de Determinao: Similar ao aplicado para a densidade de defeitos da
inspeo, porm deve-se considerar a mdia da densidade de defeitos das
inspees realizadas na fase.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica.
Ao Gerencial: Caso a densidade de defeitos estiver fora dos limites de controle,
o gerente do projeto dever avaliar os produtos gerados na fase, visando
determinar os que mais contriburam para a variao verificada. Esta ao
fundamental nas fases iniciais do projeto visto que 81% dos defeitos no software
tm sua origem na especificao.
Exemplo:

Similar ao anterior aos exemplos anteriores.

Densidade de Defeitos Por Mdulo do Software

Objetivo: Identificar os mdulos considerados como propensos a erros.

Mtodo de Determinao: Quando da inspeo dos mdulos componentes do
software ( rotinas e programas) ou das Unidades de Implementao ( conjunto de

O grfico foi feito para fins de ilustrao do exemplo, no baseando-se em dados reais.
mdulos) , determinar as densidades de defeitos respectivas.As inspees neste
caso podem ser feitas com base nos projetos de programas ( em portugus
estruturado por exemplo) ou com base nos resultados dos testes individuais de
cada programa ou da Unidade de Implementao.

A instalao pode construir grficos de controle exclusivamente para as inspees

de projetos de programas e de cdigo, cujos resultados de densidade de defeitos
constituiriam um data set especfico , dentro dos padres do processo como um
todo.
Fonte de Informaes: Processo de inspeo e documentos de estrutura do
sistema que permita identificao de mdulos ou Unidades de Implementao.
Forma de Apresentao: grfica ou tabular.
Ao Gerencial: Mdulos ou Unidades de Implementao que apresentarem
variao fora dos limites de controle devem ser revisados.
Exemplo:

Supondo a seguinte distribuio de densidade de defeitos conforme os mdulos de

um sistema hipottico.

Tabela 7-6
Mdulos Densidade
1 33.70
2 67.00
3 23.30
4 35.00
5 27.00

Caso os mdulos 1,3,4 e 5 estivessem dentro dos limites de controle, a gerncia

deveria analisar detidamente o mdulo 2 a fim de reduzir sua densidade de
defeitos, colocando-a dentr dos limites de controle.

Eficincia da Remoo de Defeitos do Processo de Inspeo

Objetivo: Medir a eficincia do processo de inspeo at a fase de teste

integrado.
Mtodo de Determinao: A medio da eficincia dada pela seguinte
expresso: dos Defeitos Identificados At a Fase de Teste Integrado sobre o
dos Defeitos Identificados At a Fase de Teste Integrado + dos Defeitos
Identificados Durante a Fase de Teste Integrado.
Fonte de Informao: Processo de inspeo e relatrio de defeitos do teste.
Forma de Apresentao: sem forma especfica.
Ao Gerencial: Caso a eficincia do conjunto de inspees for baixa, o gerente
deve procurar indcios de mudanas de requisitos no registradas e aceitas pela
equipe sem a devida comunicao ou reforar os recursos para a inspeo do
teste integrado ou analisar os mdulos com maior propenso a erros pois devem
ser os causadores da baixa eficincia. Outra alternativa seria analisar a
complexidade dos mdulos. Conforme estatsticas , cerca de 12% dos mdulos de
um sistema representam 50% do esforo de manuteno.
Exemplo:
Considera-se como baixa eficincia , ndice menor que 70%.

Supondo 1000 defeitos encontrados at a fase de teste integrado e 300 defeitos

encontrados durante o teste integrado:

A eficincia da remoo de defeitos da inspeo neste caso seria de 77%,

portanto aceitvel.

Aqui o grfico de controle tambm se aplica caso a instalao registrar as

eficincias obtidas por projetos passados.

Taxa de Exame Por Inspees

Objetivo: Verificar se a taxa de exame dos produtos inspecionados est dentro

dos limites de controle da instalao.
Mtodo de Determinao: Aqui tambm se aplica o grfico de controle. A taxa de
exame medida em linhas por hora. Para cada inspeo deve-se determinar a
taxa de exame. Aps determinar a mdia e aplic-la nas frmulas de LSC e LIC j
apresentadas anteriormente.
Fonte de Informaes: Processo de inspeo.
Forma de Apresentao: grfica.
Ao Gerencial: Esta anlise serve de base para a avaliao do desempenho das
inspees. Geralmente produtos grandes despendem um maior tempo de exame
assim como de preparao. A relao entre taxa de preparao e de exame
proporcional e linear. muito provvel que produtos de tamanho aproximado e
que apresentaramm grande variao de densidade de defeitos, experimentaram
taxas de exame diferentes. Isto pode ser um indicativo de que a inspeo no foi
realizada dentro dos padres preconizados.
Exemplo:

550

500

450

400

350 LSC

300

250
mdia
200

100

50

1 2 3 4 5 6 7 8 9
Figura 7-15

Neste exemplo as taxas de exame das inspees 1 e 5 esto fora dos limites de
controle padres da instalao.
Taxa de Preparao Por Inspeo

Objetivo: Verificar o padro de desempenho da preparao das inspees.

Mtodo de Determinao: A taxa de preparao tambm medida em linhas por
hora. O grfico de controle pode ser aplicado. O clculo da mdia e limites segue
a frmula j tratada.
Fonte de Informaes: O processo de inspeo e registros de tempos de
preparao para cada produto inspecionado.
Forma de Apresentao: grfica.
Ao Gerencial: Analisar a inspeo cuja taxa de preparao est fora dos limites
de controle. Verificar o tamanho dos produtos e respectivas densidades de
defeitos visando tomar a deciso de reinspecionar ou no o produto.
Exemplo:
Similar ao anterior.

Tamanho do Material Inspecionado Por Inspees

Objetivo: Apoiar a anlise do desempenho da inspeo, juntamente coma as

anlises das taxas de preparao e exame.
Mtodo de Determinao: O tamanho do produto expresso em nmero de
linhas. Plotar um grfico com o tamanho do material para cada inspeo
correspondente. Uma forma de anlise a de estabelecer a mdia do tamanho do
material inspecionado e um limite de + 2 desvios padres a partir da mdia.
Tamanho que se distancia muito da mdia ou que ultrapassem os 2 desvios
padres podem ser objeto de anlise mais apurada.
Fonte de Informaes: Processo de inspeo e registro do tamanho do material
inspecionado.
Forma de Apresentao: grfica ou tabular.
Ao Gerencial: Esta anlise auxilia na avaliao do desempenho das inspees,
juntamente com as informaes sobre taxas de preparao e exame. Materiais de
grande volume exigem maior tempo de preparao e exame. Caso esta relao
no for verificada, h indcios de material mal inspecionado. Material mal
inspecionado provavelmente significa baixa densidade de defeitso, com
probabilidade de estas abaixo do LIC.
Exemplo:
700

600
+ 2
Tamanho 500

do Material 400

300

200

100

1 2 3 5 6 7
Inspees
Figura 7-16
Medio Para a Anlise de Complexidade

O objetivo dessa medio o de subsidiar a gerncia quanto a definio de

estratgias para a reduo de complexidade dos mdulos do software. A reduo
da complexidade dos mdulos reduz a probabilidade da introduo de defeitos no
produto.

Objetivo: Analisar a complexidade do projeto do mdulo ( ou programa) visando

otimizao.
Mtodo de Determinao:
Mtodo #1 - Complexidade Ciclomtica

Esta mtrica, introduzida por McCabe 10, foi desenvolvida para

quantificar a complexidade do fluxo de controle do programa.
A mtrica deriva da representao grfica do fluxo de controle do
programa.
A frmula para a complexidade ciclomtica de McCabe dada pela
expresso:

M = L - N + 2P

onde:

M = complexidade ciclomtica
L = nmero de ligaes no grfico
P = nmero de chamadas (calls) para outros programas ou
subrotinas

McCabe recomenda que a complexidade ciclomtica para um programa

no deve ultrapassar 10.
Existem fortes evidncias de que quanto maior a complexidade ciclomtica,
maior a taxa de erros introduzidos nos mdulos 5.

Mtodo #2 - Modelo de Card & Glass

Card & Glass 5, desenvolveram outro modelo para medir a

complexidade de um mdulo. A quantificao da complexidade dada pela
expresso:
2
c= f + v (f + 1)
onde:

c = complexidade do mdulo
f = fanout do mdulo
v = variveis de I/O usadas pelo mdulo
 sendo que:

fanout a contagem do nmero de callsde um dado

mdulo 2
v = 2f (f + 1 )

De acordo com estes autores, o nmero de fanouts necessrios para

otimizar a complexidade varia de 0 a 3.
Com 3 fanouts a complexidade aceitvel 33.

Fonte de Informaes: Documentos de projeto, de programas, listagens de

programas, analisadores de complexidade.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: De acordo com o mtodo #1, um mdulo com complexidade
ciclomtica superior a 10 deve ser re-analisado ou reprojetado. O mesmo ocorre
com complexidade superior a 33 no caso do modelo de Card & Glass.

As aes visando a reduo da complexidade so:

fanout deve ser mantido em tr6es ou menos

minimizar as variveis de I/O tratadas pelo mdulo
aumentar a eficincia do projeto pelo uso de inspees, programao
estruturada e gerncia de configurao ( controle de verses).
Exemplo:
Mtodo#1
Supondo o seguinte fluxo de programa:

L=4 N= 5 P = 1
M = ( 4-5) + 2 = 1
Mdulo est em nvel aceitvel de complexidade.

Mtodo #2
Supondo um mdulo com fanout = 5
2
v = 2 x 5 (5 + 1 )
v = 360
c = 25 + ( 360/6) = 85
Mdulo que dever ser revisto.

Estabelecimento de Objetivos de Intensidade de Falhas

Objetivos de intensidade de falhas podem ser estabelecidos para o software

quando da realizao do teste integrado do mesmo.

Ao estabelecer estes objetivos pode-se determinar o nmero de falhas e tempo

adicionais para atingimento do objetivo.
 A determinao destes requisitos dada pela disciplina de Confiabilidade (
Reliability), cuja aplicao na rea de software foi desenvolvida e divulgada por Musa,
Iannino & Okumoto 12 . Devido a complexidade do assunto, nos deteremos em
algumas medies bsicas derivadas dos modelos preconizados por estes autores.

Falhas Adicionais Esperadas Para Atingir o Objetivo de Intensidade

Objetivo: Estimar o nmero de falhas adicionais a serem experimentadas pelo

software at o atingimento do objetivo de intensidade de falhas.
Mtodo de Determinao: O clculo para determinao das falhas adicionais
dado pela expresso:

= Vo p - f
o
onde:

nmero de falhas esperadas para atingimento do objetivo

de intensidade de falhas
Vo nmero de falhas observadas at um tempo T do teste
o intensidade de falhas inicial por CPU hora
p intensidade atual de falhas em CPU hora
f objetivo de intensidade de falhas em CPU hora
Fontes de Informaes: Registros de falhas experimentadas pelo software
durante o teste integrado.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: O atingimento do objetivo de intensidade de falhas permite a
release do software para o teste de aceitao pelo cliente/usurio ou, dependendo
das circunstncias, a entrega do produto para a operao normal.
Exemplo:
Supondo a intensidade de falhas inicial em 10 CPU hora, um objetivo de
intensidade de falhas de .10 CPU hora, 200 falhas observadas at o momento e a
intensidade de falhas atual em 5 CPU hora:

= 200 / 10 5 - .10 = 98 falhas adicionais

Tempo de Execuo Adicional Esperado Para Atingimento do Objetivo de

Intensidade

Objetivo: Estimar o tempo de execuo adicional necessrio para atingir o

objetivo de intensidade de falhas.
Mtodo de Determinao: O clculo do tempo de execuo adicional dado pela
expresso:

= Vo Ln p
o f
onde:
 tempo de execuo adicional
Vo nmero de falhas observadas
o intensidade inicial de falhas
Ln logaritmo neperiano
p intensidade de falha atual
f objetivo de intensidade
Fontes de Informaes: Registros de falhas durante a execuo do software.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Idem ao item anterior.
Exemplo:
Supondo os mesmos dados do exemplo anterior:

= 200/10 Ln ( 5/.1) = 20 Ln ( 50 ) = 20 x 3.91 = 78,20 CPU hora

Medies Para o Monitoramento do Progresso

O monitoramento do progresso de um software somente pode ser verificado

atravs da concluso dos produtos intermedirios que, ao longo do processo , vo sendo
disponibilizados. O trmino de um produto intermedirio significa produto aprovado pelo
processo de inspeo.

O monitoramento do progresso tambm est associado gesto financeira e de

recursos, pois variaes no prazo tm impacto imediato quanto ao esforo e custos do
projeto.

Outro aspecto a ser considerado quanto ao replanejamento do projeto, o qual

deriva da estimativa atualizada do tamanho do software e da estimativa atualizada do
prazo.

Portanto , as medies quanto ao monitoramento do progresso do projeto

abrangem os aspectos de: controle do progresso e replanejamento.

Controle do Progresso

Os objetivos das medies so:

Verificar o progresso na elaborao dos produtos previstos

Acompanhamento fsico do projeto

Progresso na Elaborao de Produtos

Objetivo: Verificar o progresso na elaborao de produtos intermedirios do

projeto, bem como as variaes que possam levar a um replanejamento do
mesmo.
Mtodo de Determinao: Em funo do cronograma do projeto, deve-se
identificar os prazos de liberaes (entregas) dos produtos previstos conforme o
que preconiza o processo de desenvolvimento selecionado para o software.
Plotar em um grfico a previso de entrega do produto, ao longo do tempo,
juntamente com o esforo tambm previsto para o produto. Registrar no grfico, o
prazo efetivo de liberao do produto com o esforo correspondente realizado.
Fontes de Informaes: Sistema automatizado de gerncia de projetos ( project
tracking ), estimativas de prazos e esforo oriundas do planejamento e registros
de prazo e esforo realizado.
Forma de Apresentao: grfica.
Ao Gerencial: Caso houver variao positiva no que tange aos prazos
planejados ( atuais) , o gerente do projeto deve verificar o esforo adicional
necessrio para manter o prazo sob controle ou decidir pelo replanejamento do
projeto.
Exemplo:
Supondo a estimativa inicial de prazo e esforo e respectivos produtos:

Tabela 7-17
Produto Prazo Esforo
Projeto Preliminar 2 meses 9 homens/ms
Projeto do Produto 3 meses 23 homens/ms
Programas Testados 9 meses 90 homens/ms
Sistema Integrado 4 meses 32 homens/ms

Esforo Acumulado
200
190 Figura 7-17
180
170
160
150
140
130
120
110
100
90
80
70
60
50
40
30
20
10

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 meses
Legenda:
Produto Esperado Esforo Previsto x Prazo
Esforo Realizado x Prazo Esforo Acumulado x Prazo
Produto Concludo

Pelo exemplo podemos verificar que houve variao para a elaborao do produto
previsto para o quinto ms e para o dcimo quarto ms, com as consequncias no
esforo, que aumentou substancialmente. De forma simplificada , deveramos
duplicar o esforo na fase final, de 32 homens/ms para 64, ou seja, mais 8
pessoas deveriam ser agregadas ao projeto. Entretanto, em fases finais isto
muito difcil. Supondo que o prazo factvel de ser atingido em relao fase de
Integrao e Teste , o projeto atrasaria pelo menos por 2 meses.
 Acompanhamento Fsico do Projeto

Objetivo: Verificar o andamento do cronograma do projeto.

Mtodo de Determinao: A maioria dos software-produto de gerenciamento de
projetos, tal como o MS-Project , possuem as ferramentas necessrias, uma vez
devidamente alimentado, para a gerao de cronogramas e comparao do
previsto contra o realizado. Este pacotes possuem vrios tipos de sadas para a
visualizao do andamento fsico, sendo um dos principais o grfico de Gantt.
Fonte de Informaes: Sistema gerenciador de projetos (project tracking).
Forma de Apresentao: grfica.
Ao Gerencial: O grfico de Gantt geralmente permite a visualizao genrica
do progresso do projeto. Mostra os prazos previstos e realizados e, se houver, a
nova estimativa de prazo, ou seja, o prazo restante.
Exemplo:
Figura 7-18
Fases Meses
jan fev mar abr mai jun jul ago
Planejamento

Especificao

Projeto

Codificao

Teste

Implantao

Legenda:
Prazo Inicialmente Estimado

Prazo Realizado Efetivamente

Prazo Estimado Atualizado

Medies Para o Replanejamento

Os objetivos dessas medies so:

Possibilitar elaborar as estimativas atualizadas do prazo do projeto

Avaliar as estimativas de prazo do projeto
Atualizar a estimativa de tamanho do software

Estimativa Atualizada do Tamanho do Software

Objetivo: Elaborar estimativa atualizada do tamanho do software visando o
replanejamento do projeto.
Mtodo de Determinao: Ao final da Especificao ( Projeto Lgico) e do
Projeto Detalhado ( Projeto Fsico) deve-se elaborar nova contagem dos Pontos
de Funo, considerando, no entanto, a metodologia # 1 de contagem.
Fonte de Informaes: Documentos de especificao e do projeto detalhado.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Com a nova estimativa de tamanho, o gerente deve realizar nova
estimativa de prazo, esforo e custo para o projeto.
Exemplo: Vide captulo 6.

Estimativa Atualizada de Prazo

Objetivo: Elaborar nova estimativa de prazo para o projeto e para as fases do

projeto.
Mtodo de Determinao: Deve ser utilizado o mesmo mtodo j apresentado no
captulo 6. Com a nova estimativa do tamanho , ou se realiza a interpolao no
data set de dados histricos de projetos ou emprega-se o modelo COCOMO, o
qual inclusive permite realizar estimativas de prazo por fase. Com os novos
valores de prazo, deve-se deduzir o prazo j realizado, determinando assim o
prazo restante. Com esta abordagem, o prazo restante poder ser estimado a
partir do trmino da fase de especificao ou das fase de projeto detalhado.
importante notar que todas as estimativas apresentadas no captulo 6 podero
ser re-elaboradas.
Fontes de Informao: Documentos do projeto e nova estimativa do tamanho.
Forma de Apresentao: grfica
Ao Gerencial: Conforme o nvel da variao entre o estimado inicialmente e a
nova estimativa, o gerente poder alocar mais recursos ao projeto, por exemplo,
programao, nos processos de inspeo, aumentar a frequncia das inspees
ou realzar nova negociao com o cliente/usurio quanto ao replanejamento.
Neste caso dever ser emitida verso atualzada do Planejamento do Projeto.
Exemplo:

O prazo restante poder ser apresentado em forma de grfico de Gantt, conforme

o exemplo da medio - Acompanhamento Fsico do Projeto.

Exatido da Estimativa de Prazo da Fase

Objetivo: Analisar a variao do realizado com as estimativas e prover meios de

controlar o processo de desenvolvimento.
Mtodo de Determinao: A exatido da estimativa de prazo da fase dada pela
expresso: Prazo Realizado Na Fase (meses/semanas etc.) Prazo Estimado
Para a Fase. Caso a instalao tiver o grafico de controle relativo exatido de
estimativas, o resultado poder ser cotejado com os limites de controle.
Fonte de Informao: Registros de estimativas e cronograma atualizado.
Forma de Apresentao: grfica caso comparar com os limites de controle.
Ao Gerencial: Caso o ndice de exatido estiver forma dos limites de controle
ou muito distante da mdia geral ou especfica para a fase em anlise, o gerente
deve determinar as causas da variao, as quais geralmente so qualitativas, ou
 baseadas no perfil da equipe ( tcnica e de usurios), ou no ambiente de trabalho,
ou nos mtodos utilizados, ou nos equipamentos e assim por diante.
Exemplo:

Supondo a estimativa inicial para uma determinada fase em 5 meses e o prazo

realizado em 7 meses. A exatido da estimativa de 1.4, o que significa que
houve uma variao de + 40% no prazo estimado. Caso os limites de controle
forem 30% e 20% , dever-se-ia analisar as causas da variao.

Medies Para a Gesto de Recursos e Financeira

Decidimos agrupar ambos conjuntos de medies pois os custos do projeto so

determinados em grande parte pelo esforo alocado ao projeto.

O objetivo bsico da gesto de recursos e financeira do projeto perseguir a

reduo do seu custo global. bvio que a esse tipo de gesto dependente da gesto
da qualidade e do controle do progresso.

Da gesto da qualidade porque minimiza o esforo de retrabalho,

consequentemente otimizando o atingimento dos prazos e reduzindo o custo do projeto,
pela reduo do custo do retrabalho.

Do controle do progresso pois fornece informaes acerca das possibiidades de

atraso, consequentemente das possibioidades de aumento de esforo e custo
correspondente.

Medies Para o Monitoramento da Alocao de Recursos

Os objetivos dessas medies so:

Elaborar estimativas atualizadas de esforo

Elaborar estimativas atualizadas de alocao de recursos

Estimativa Atualizada de Esforo

Objetivo: Elaborar estimativa atualizada do esforo a fim de determinar nova

alocao de recursos e subsidiar a nova estimativa de custo do projeto.
Mtodo de Determinao: A partir da estimativa atualizada do tamanho do
software e com o emprego do mtodo COCOMO pode-se determinar a
necessidade de esforo adicional. Para tanto deve-se deduzir da estimativa
atualizada o esforo j realizado. O modelo COCOMO j emprega a distribuio
de Rayleigh, portanto ela no necessita ser empregada.
Fonte de Informaes: Estimativa atualizada do tamanho do software, registros
do esforo realizado.
Forma de Apresentao: tabular.
Ao Gerencial: De posse da nova estimativa, o gerente deve determinar a
necessidade por rever a alocao de recursos humanos ao projeto, nas fases
subsequentes, bem como elaborar nova estimativa de custos.
Exemplo:
Supondo que a estimativa inicial fosse de 400 Pontos de Funo em Cobol e que a
nova contagem , realizada ao final do projeto lgico, seja de 500 Pontos de
Funo.

Utilizando a transformao de FPs para instrues fontes e a frmula de esforo

do mtodo COCOMO para projetos do tipo orgnico, teramos respectivamente as
seguintes previses de esforo: 110,23 H/M para 400 PFs e 140,10 H/M para 500
PFs e a distribuio do esforo por fase conforme a tabela abaixo.

Tabela 7-18
Fase Estimativa Estimativa Variao
Inicial Atual
Planejamento 6,24
Projeto do Produto 16.64
Programao 64,32 86,27 + 34%
Integrao e Teste 23,03 31,41 + 36 %

Haveria um acrscimo de 30,33 H/M de esforo em relao a estimativa inicial.

Estimativa Atualizada de Alocao de Recursos

Objetivo: Elaborar estimativa atualizada do nmero de profissionais com alocao

integral ao projeto, em funo da estimativa atualizada de esforo.
Mtodo de Determinao: A determinao do nmero de profissionais a serem
alocados dada pela expresso: Esforo Atualizado Por Fase do Projeto dividido
pelo Prazo Atualizado da Fase.
Fonte de Informaes: Estimativa atualizada de esforo e prazo.
Forma de Apresentao: tabular.
Ao Gerencial: Esta previso atualizada do nmero de profissionais a serem
alocados til quando estamos no incio do projeto ou na fase de especificao e
projeto detalhado. til tambm para determinarmos o nmero de programadores
necessrios. Porm para que a programao inicie sem problemas importante
administrarmos o gargalo representado pelo esforo necessrio para a elaborao
dos projetos dos programas. Entretanto na fase de integrao e teste e mesmo de
implantao no recomendvel adicionar mais recursos humanos ao projeto.
Neste caso a tendncia de atrasar mais ainda o projeto. Se seu projeto estiver
na fase de programao e for feito uma nova estimativa de pessoal para as fases
seguintes e essa estimativa indicar que o projeto deve alocar mais pessoal,
negocie com a equipe atual o aumento da carga de trabalho ou assuma o atraso
do projeto.
Exemplo:
Vide captulo 6 quanto a estimativa de determinao de pessoal por fase do
projeto.

Exatido da Estimativa de Esforo da Fase

Objetivo: Analisar a variao do realizado com as estimativas e prover meios de

controlar o processo de desenvolvimento.
Mtodo de Determinao: A exatido da estimativa de esforo da fase dada
pela expresso: Esforo Realizado Na Fase ( homems/ms) Esforo Estimado
Para a Fase. Caso a instalao tiver o grafico de controle relativo exatido de
estimativas, o resultado poder ser cotejado com os limites de controle.
Fonte de Informao: Registros de estimativas , cronograma atualizado e
registros de esforo realizado.
Forma de Apresentao: grfica caso comparar com os limites de controle.
Ao Gerencial: Caso o ndice de exatido estiver forma dos limites de controle
ou muito distante da mdia geral ou especfica para a fase em anlise, o gerente
deve determinar as causas da variao, as quais geralmente so qualitativas, ou
baseadas no perfil da equipe ( tcnica e de usurios), ou no ambiente de trabalho,
ou nos mtodos utilizados, ou nos equipamentos e assim por diante.
Exemplo:

Supondo a estimativa inicial para uma determinada fase em 30 homens/ms e o

esforo realizado em 40 homem/ms. A exatido da estimativa de 1.3, o que
significa que houve uma variao de + 30% no esforo estimado. Neste exemplo a
variao est dentro dos limites de controle . Entretanto pode haver necessidade
de replanejar o projeto caso o nvel de variao para outras fases persistir.

Medies Para o Monitoramento Financeiro do Projeto

Os objetivos dessas medies so:

Acompanhar financeiramente o projeto

Realizar estimativas atualizadas do custo do projeto
Analisar o comportamento dos custos de retrabalho

Acompanhamento Financeiro do Projeto

Objetivo: Acompanhar a evoluo dos custos do projeto em relao ao orado e

verificar o valor ganho at estgio que se encontra o projeto no cronograma.
Mtodo de Determinao: Comparar, ao longo do cronograma do projeto, os
custos realizados com os custos orados. Determinar o valor ganho subtraindo o
custo orado (atualizado) com o custo realizado.
Fonte de Informaes: Sistema de gerenciamento de projetos ou registros das
estimativas de custo e do custo realizado.
Forma de Apresentao: grfica.
Ao Gerencial: Este acompanhamento importante para o gerente definir
estratgias que possam conduzir o projeto dentro dos limites oramentrios, bem
como simular impactos financeiros no projeto decorrente de atrasos ou de
aumento de esforo.
Exemplo:

Com uma representao deste tipo a gerncia rapidadmente visualiza:

que houveram duas atualizaes da estimativa inicial , uma na semana

25 e outra na 35.
o progresso do custo real do projeto ao longo do tempo.
as tendncias do custo restante a ser realizado
 o progresso do valor ganho ou das economias obtidas

custo
1500

1000 Custo Estimado Total

500
Custo Orado

300
Custo Realizado

100 Valor Ganho

0 5 15 20 25 30 35 40 45 50 55
Semanas desde o incio do projeto Hoje
Figura 7-19

Estimativa Atualizada do Custo do Projeto

Objetivo: Determinar o custo atualizado do projeto em funo de um

replanejamento ocorrido.
Mtodo de Determinao: (Esforo Estimado Para as Fases Restantes x Custo
Mdio do Homem/Ms) + Parcela de Rateio de Outros Custos Diretos e Indiretos
Alocados s Fases Correspondentes. A maioria dos pacotes de gerenciamento de
projetos, uma vez que sejam devidamente alimentados, reprogramam o oramento
do projeto.
Fontes de Informao: Sistema de Controle de Custos ou composio percentual
da parcela de rateio sobre o custo total do projeto mais o registro do custo mdio
do homem/ms ou o registro do custo de cada recurso humano alocado fase
correspondente do projeto. ( Vide captulo 6 quanto a determinao do custo do
projeto).
Forma de Apresentao: grfica
Ao Gerencial: Se sua empresa trabalhar na filosofia de transferncia de preos
entre unidades necessrio negociao com o cliente/usurio. Essa negociao
pode ser conduzida com tranquilidade se o gerente do projeto seguir
rigorosamente os preceitos da boa gerncia de projetos, ou seja, registrar as
ocorrncias, as solicitaes de mudanas no escopo do projeto, houverem as
reunies de avaliao de progresso, isto , se puder comprovar as causas de
aumento de esforo.
Exemplo:

Pode ser utilizada uma representao similar a do exemplo anterior.

custo
1500

1000

500

300 Custo Orado

Custo
Realizado
100

Integrao & Teste

Planejamento
Programao Implantao
Especificao

Projeto Detalhado
Figura 7-20

Neste exemplo , em funo da estimativa atualizada de prazo e esforo, os custos

so reprojetados a partir da fase de Programao.

Comportamento do Custo de Retrabalho

Objetivo: Analisar o comportamento do custo de retrabalho ao longo do projeto.

Mtodo de Determinao: O custo de retrabalho determinado pela seguinte
expresso: Esforo de Retrabalho x Custo Mdio do Homem/Hora. O custo de
retrabalho da fase : do Esforo de Retrabalho na Fase x Custo do
Homem/Hora.
Fonte de Informaes: O processo de inspeo deve fornecer a informao
sobre o esforo de retrabalho. Para tanto os registros correspondentes devero
ser realizados.
Forma de Apresentao: grfica.
Ao Gerencial: O custo de retrabalho est associado ao nvel de defeitos que
so introduzidos nos produtos do software e que so detectados pelo processo de
inspeo. A gesto da qualidade que atua sobre os custos de retrabalho. Estes
custos tambm podem ser controlados utilizando-se o grfico de controle.Caso os
custos se comportarem fora dos limites de controle ou se houver uma grande
disperso em relao mdia, o gerente do projeto deve analisar as causas da
variao. O grfico de controle pode ser construdo considerando cada fase do
processo de desenvolvimento.
Exemplo:
Podemos considerar dois tipos de representao grfica do custo de retrabalho.
 Figura 7-21

100 Planejamento

90 Especificao

80 Projeto Detalhado

70 Programao
Teste
60
Implantao
50

40

30

20

10

Legenda:
Custo Mdio de Retrabalho

Custo de Retrabalho Realizado

Grfico de Controle da Fase de Especificao

Figura 7-22

50 LSC

35 mdia
LIC

Medies Para a Gesto de Mudanas

O objetivo bsico dessas medies o monitoramento das mudanas de

requisitos solicitadas pelos clientes/usurios ao longo do desenvolvimento do software,
bem como identificar as origens dessas mudanas.

A principal medio a ser realizada relativa a estabilidade dos requisitos. Baixa

estabilidade significa que o projeto entra em uma rea de perigo , podendo comprometer
as metas de prazo e custo inicialmente estipuladas.

Monitoramento de Mudanas nos Requisitos

Objetivo: Monitorar a ocorrncia de mudanas nos requisitos ao longo do

desenvolvimento do projeto.
Mtodo de Determinao: Aqui devemos utilizar dois indicadores, quais sejam:
(i) Estabilidade dos Requisitos na Fase e (ii) Crescimento/Mudanas dos
Requisitos na Fase. Os requisitos, do ponto de vista do cliente/usurio, geralmente
compreendem os aspectos funcionais do software em termos de entradas,sadas,
consultas, interfaces ,desempenho e caractersticas gerais ( anlogas as
estabelecidas pelo mtodo de Anlise Por Pontos de Funo). Considerando o
progresso da especificao do software, podemos esperar uma estabilidade muito
baixa na fase de Planejamento ou Ante-Projeto. Entretanto a estabilidade a partir
da fase de especificao deve ser relativamente alta. Caso for baixa, significa que
deveremos refazer grande parte da concepo lgica para atender as
necessidades do projeto fsico do software. Na fase de implementao a
estabilidade tem que ser bastante alta.

Portanto deve-se estabelecer expresses diferenciadas para a fase de Projeto

preliminar ou Ante-Projeto e para as demais.

No caso de medio da estabilidade dos requisitos:

Para a fase de Projeto Preliminar/Ante-Projeto/Planejamento a expresso :

Mudanas dos Requisitos + Correo de Requisitos dividido pelo

Nmero de Requisitos da Fase de Projeto Preliminar
Esta medio somente pode ser feita na fase posterior ou de Especificao
(Projeto Lgico).

Para as demais fases a expresso :

Nmero de Requisitos Adicionados na Fase Atual + Nmero de

Requistos da Fase Anterior Alterados + Nmero de Requisitos da Fase
Anterior Corrigidos dividido pelo Nmero de Requisitos da Fase
Anterior
Esta medio feita na fase de projeto detalhado (Projeto Fsico) para
medir a estabilidade dos requisitos da fase de Especificao, na fase de
Implementao para medir a estabilidade dos requisitos da fase de Projeto
Detalhado e assim sucessivamente.

Quanto menor o ndice ao longo do desenvolvimento, mais estveis so os

requisitos.

No caso de crescimento/mudanas dos requisitos na fase:

As expresses so:

Nmero de Requisitos Adicionados dividido pelo Nmero Total de

Requisitos

Nmero de Requisitos Alterados dividido pelo Nmero Total de

Requisitos
Estas medies fornecem uma idia de crescimento funcional do software
ou de adio de caractersticas de processamento ou de mudanas nos
requisitos.
Fontes de Informao: Documentos de projeto , registros de requisitos e de
incluso/alterao/correo de requisitos.
Forma de Apresentao: tabular e grfica.
Ao Gerencial: No existem padres na literatura sobre este ndice. A instalao
pode criar seus prprios padres conforme for o tipo de plataforma de hardware e
software e o processo de desenvolvimento. Espera-se baixa estabilidade de
requisitos na fase de Projeto Preliminar, grande adio de requisitos na fase de
Especificao, alta estabilidade dos requisitos para esta fase e demais. O
monitoramento do crescimento ou de alteraes de requisitos ao longo da fase
permite agir tempestivamente antes do seu trmino a fim de identificar as causas/
origens do incremento ou da mudana. O monitoramento pode ser realizado
considerando o calendrio de cada fase do projeto.
Exemplo:

Medindo a estabilidade da fase de Especificao:

Supondo a adio de 20 requisitos, a alterao de 10 requisitos , a correo de 5

requisitos para um total de 80 requisitos:

1 - (20 + 10 + 5 / 80 ) = 56%

Neste exemplo, cerca de 56% dos requisitos foram mantidos. Pode ser
considerada como uma baixa estabilidade. No caso de valores negativos
considera como estabilidade inexistente. Isto significa que a Especificao foi
totalmente alterada.

Medindo o crescimento funcional/processamento e o ndice de mudana:

Supondo que at um tempo To, dentro da fase de especificao, 100 requisitos

funcionais tenham sido definidos e aprovados pelo cliente/usurio e que entre o
tempo To e T1 houve um incremento de 30 requisitos. Isto pode ser demonstrado
graficamente para fins de monitoramento.

To T1
130

Neste exemplo o incremento foi de 30%.

100

30

Figura 7-23

A mesma representao pode ser dada para a variao de mudanas nos

requisitos.
 Origens de Incremento/Mudanas nos Requisitos

Objetivo: Identificar as origens de incremento e/ou mudanas nos requisitos.

Mtodo de Determinao: Atravs dos registros de incrementos e de solicitaes
de mudanas nos requisitos pode-se identificar as fontes de alterao. Uma das
alternativas identificar os clientes/usurios que concentram a maior parte das
solicitaes. Dessa forma pode-se construir grficos de frequncia que evidenciem
as principais fontes, com possibilidade de desdobr-los a fim de identificar as
verdadeiras causas.
Fontes de Informaes: Registros de requisitos, solicitaes de mudanas e de
incremento.
Forma de Apresentao: grfica.
Ao Gerencial: Uma vez identificadas as principais fontes de mudanas e/ou
incrementos, o gerente do projeto deve tomar aes corretivas a fim de eliminar ou
reduzir as fontes de variabilidade.
Exemplo:

Mudanas
50

30

20

10

Marketing Produo Engenharia Vendas

Figura 7-24
Neste exemplo , para um sistema que envolva 4 reas da empresa, a principal
fonte de alteraes a rea de marketing, seguida da produo. Este grfico
poderia ser desdobrado, classificando os motivos de alteraes ou incremento cuja
origem o marketing e a produo. Analisando as causas, o gerente de projetos
pode verificar se o usurio indicado a fornecer informaes o mais adequado, se
as tcnicas de envolvimento dos usurios para a especificao de requisitos esto
sendo corretamento empregadas e assim por diante.

7.3.3 - Medies Para Atender a Gesto do Produto

Durante o processo de desenvolvimento do software so realizadas medies as

quais vo subsidiar o processo de gesto do prprio software. Estas medies so
realizadas quando da release do software.

As principais medies so:

Falhas esperadas para o software

Intensidade atual de falha
Estimativa atualizada do nmero de defeitos ps-release
As duas primeiras medies tambm so derivadas dos modelos de confiabilidade
de Musa, Iannino & Okumoto.

Falhas Esperadas Para o Software

Objetivo: Determinar o nmero de falhas esperadas para o software dentro de um

perodo de tempo especificado.
Mtodo de Determinao: O clculo de falhas esperadas dado pela seguinte
expresso:

() = 1 Ln ( o + 1)

onde:

() nmero de falhas esperadas

parmetro de reduo do nmero de falhas na medida em
que o software vai sendo depurado
o intensidade inicial de falhas do software
tempo de execuo para o qual se pretende determinar o
nmero de falhas
Ln logaritmo neperiano
sendo que:
derivado da relao entre a intensidade inicial de falhas sobre o
nmero de falhas detectado dentro de um perodo especfico de
medio
Fontes de Informao: Registros de falhas quando da execuo do teste
integrado do software.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Dependendo da meta estabelecida quanto ao nmero de falhas
aceitveis para o software em relao a um perodo de tempo especfico, a
gerncia poder, estabelecer objetivos de reduo do nmero de falhas quando o
software estiver em operao, o que guiar os esforos de manuteno corretiva.
Exemplo:

Supondo que a intensidade de falha inicial , medida no incio do teste integrado,

tenha sido de 10 falhas por CPU hora; que foram registradas 200 falhas durante o
teste integrado; e que se pretende estabelecer o nmero de falhas esperadas para
um tempo de execuo de 1000 CPU hora:

( ) = 1 / .05 Ln ( 10 x .05 x 500 + 1 ) = 111 (aproximado)

Esperaramos, portanto, a ocorrncia de 111 falhas para um perodo de 500 CPU

hora.

Intensidade Atual de Falhas

Objetivo: Determinar a intensidade atual de falhas do software quando de sua

release.
Mtodo de Determinao: O clculo para a determinao da intensidade atual de
falhas dado pela expresso:

( ) = o exp ( - )
onde:

( ) intensidade atual de falha

o intensidade inicial de falha
parmetro de reduo da intensidade de falha
nmero de falhas observadas durante o teste
exp funo exponencial
Fontes de Informaes: Registros de falhas na execuo do teste integrado.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: A gerncia pode confrontar a intensidade atual com objetivos de
intensidade para o produto, estipulados no incio do projeto. Caso houver vairao
para mais, a gerncia pode estabelecer metas quando da operao do produto a
fim de guiar a manuteno corretiva.
Exemplo:

Supondo a intensidade inicial em 10 falhas por CPU hora e 100 falhas observadas
e um parmetro de reduo de falhas em torno de 0.05:

( ) = 10 exp ( - .05 x 100 ) = 0.07 falhas por CPU hora

Estimativa Atualizada do Nmero de Defeitos Ps-Release

Objetivo: Determinar o nmero de defeitos ps-release quando do trmino do

projeto.
Mtodo de Determinao:
Mtodo #1

Esta mtodo parte da equao de regresso linear onde:

Nmero de Defeitos Ps-Release = F ( Tamanho do Software)

Neste caso o tamanho do software, ao final do projeto, calculado pela

metodologia #2 do Pontos de Funo.

Mtodo #2

Este mtodo contempla a seguinte expresso:

Nmero de Defeitos Ps-Release = Nmero de Defeitos Pr-Release x

( 100 - Eficincia Mdia da Remoo de Defeitos) / Eficincia Mdia da
Remoo de Defeitos

Fontes de Informao: Registros das inspees e o ndice de eficincia mdia da

remoo de defeitos do processo de desenvolvimento, constante no banco de
dados de mtricas da instalao.
 Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Esta estimativa permite gerncia estabelecer os recursos
necessrios para a correo dos defeitos. Lembramos que falhas so reflexos de
defeitos porm, nem todos os defeitos geram falhas.
Exemplo:

Mtodo # 1
Usar a equao de regresso linear, similarmente ao exemplo apresentado
no captulo 6 quanto estimativa de defeitos pr-release.
Mtodo # 2
Supondo que foram registrados 800 defeitos pr-release e que a eficincia
mdia de remoo de defeitos do processo de 60%:

Nmero de Defeitos Pr-Release = 800 ( 100 - 60 ) / 60 = 533

7.3.4 - Medies Para Atender o Aperfeioamento do Planejamento de Projetos e do

Processo de Desenvolvimento da Instalao

Ao final do processo de desenvolvimento devem ser feitas algumas medies para

que dem subsdios ao aperfeioamento contnuo dos processos de planejamento de
projetos e de desenvolvimento da instalao.Essas medies vo atualizar o banco de
dados de mtricas, bem como estabelecer os novos padres da instalao, os quais
sero utilizados para o planejamento e desenvolvimento de novos projetos.

Essas medies compreendem:

Verificao da Exatido das Estimativas

Tamanho do Software Entregue
Produtividade do Desenvolvimento
Custo do Ponto de Funo de Desenvolvimento
Crescimento Funcional do Software Durante o Desenvolvimento
Reutilizao do Cdigo
Complexidade Relativa do Software
Custo da Qualidade
Distribuio do Esforo Por Fase
Distribuio do Custo Por Fase
Distribuio dos Defeitos Por Fase
Densidade de Defeitos do Software
ndice de Tecnologia de Desenvolvimento Empregado
ndice de Tecnologia de Gesto Empregado
Demais Medies Qualitativas

A seguir detalharemos cada uma dessas medies.

Ao contrrio das medies elencadas para a gesto do prprio processo de

desenvolvimento, nesta seo no discutiremos as aes gerenciais relativas a cada
medio, tendo em vista que as mesmas so tratadas a nvel ttico.
 Verificao da Exatido das Estimativas

Essas medies objetivam a determinao da exatido das estimativas visando

realimentar o processo de planejamento para fins de adequao dos modelos de
estimativas.

Exatido da Estimativa de Prazo

Objetivo: Determinar o grau de acerto da estimativa inicial de prazo elaborada

quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de prazo dada pelas
seguintes expresses:

Caso do Prazo estimado for menor que o prazo realizado

ExP = (PE/PR) x 100
onde:
PE Prazo Estimado
PR Prazo Realizado

Caso do prazo estimado for maior que o prazo realizado

ExP = 1- ( PE/PR ) -1 x 100

De acordo com essas frmulas a exatido da estimativa = a 100%, significa que o

prazo estimado foi igual ao prazo realizado
Fontes de Informaes: Sistema de gerenciamento de projetos.
Forma de Apresentao: nenhuma especfica.
Exemplos:
Supondo o prazo estimado em 10 meses e o realizado em 12 meses, a exatido
da estimativa :
Exp = 83%
Ou seja a estimativa representa 83% do prazo efetivamente relizado, com uma
variao de 17% a mais.

Supondo o prazo estimado em 12 meses e o realizado em 10 meses, a exatido

da estimativa :
Exp = 80%
O prazo realizado representa 80% do prazo estimado, com uma variao de 20%
para menos. ( Geralmente um fato muito difcil de ocorrer)

Exatido da Estimativa de Tamanho do Software

Objetivo: Determinar o grau de acerto da estimativa inicial de tamanho elaborada

quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de tamanho dada pela
pelas mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Clculo do tamanho do software realizado no
planejamento e ao trmino do projeto.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao anterior.

Exatido da Estimativa de Custo

Objetivo: Determinar o grau de acerto da estimativa inicial de custo elaborada

quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de custo dada pela pelas
mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Sistema de gerenciamento de projetos.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao da exatido da estimativa de prazo.

Exatido da Estimativa de Esforo

Objetivo: Determinar o grau de acerto da estimativa inicial de esforo elaborada

quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de esforo dada pela pelas
mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Sistema de gerenciamento de projetos.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao da exatido da estimativa de prazo.

Exatido da Estimativa de Defeitos Pr-Release

Objetivo: Determinar o grau de acerto da estimativa inicial de defeitos pr-release

elaborada quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de defeitos pr-release
dada pela pelas mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Sistema de gerenciamento de projetos, processo de
inspeo.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao da exatido da estimativa de prazo.

Exatido da Estimativa de Custo de Retrabalho

Objetivo: Determinar o grau de acerto da estimativa inicial de custo de retrabalho

elaborada quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de custo de retrabalho
dada pela pelas mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Sistema de gerenciamento de projetos , processo de
inspeo.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao da exatido da estimativa de prazo.

Exatido da Estimativa de Instrues Fontes

 Objetivo: Determinar o grau de acerto da estimativa inicial do nmero de
instrues fontes elaborada quando do planejamento do projeto.
Mtodo de Determinao: A exatido da estimativa de instrues fontes dada
pela pelas mesmas frmulas, substituindo-se as variveis.
Fontes de Informaes: Estimativa inicial e contagem das instrues fontes ao
final do projeto.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Similar ao da exatido da estimativa de prazo.

Tamanho do Software Entregue

Ao final do projeto os Pontos de Funo devem ser calculados a fim de determinar

o tamanho efetivo do software.

No caso de ser sistema de processamento em tempo-real, uma das alternativas

o emprego da variao da metodologia #1 da Anlise Por Pontos de Funo denominada
de Feature Points, a qual foi desenvolvida por Capers Jones 9.

Clculo do Ponto de Funo Pela Metodologia #1

Objetivo: Determinar o tamanho do software a ser entregue para os

clientes/usurios.
Mtodo de Determinao: metodologia #1.
Fontes de Informaes: Funes implementadas no software.
Forma de Apresentao: Formulrio de clculo do mtodo.
Exemplo:
Vide captulo 6 .

Clculo de Feature Points Para Sistemas de Processamento em Tempo Real

Objetivo: Determinar o tamanho do software em feature points.

Mtodo de Determinao:
A diferena fundamental entre o Function Points Analisys e o Feature Points est
na considerao que este faz em relao aos algoritmos empregados pelo
software, bem como na utilizao dos pesos que definem a complexidade das
funes ( entradas, sadas, consultas, arquivos lgicos internos e arquivos de
interfaces externas).

Os procedimentos para clculo do Feature Points so:

Contagem das Funes

Utiliza-se a mesma abordagem tratada pela metodologia #1.
Definio da Complexidade
A complexidade definida pelos aspectos da lgica e de dados do software.Para
tanto deve ser determinado o nvel de complexidade da lgica e dos dados,
conforme a seguinte escala:

Complexidade da Lgica
1. Algoritmos e clculos simples
2. Maior parte dos algoritmos e de clculos so simples
3. Algoritmos e clculos de complexidade mdia
4. Alguma dificuldade e clculos complexos
5. Muitos clculos e algoritmos complexos e difceis
Complexidade dos Dados
1. Estrutura de dados simples, com poucas variveis e baixa complexidade
2. Numerosos variveis mas com relacionamentos de dados simples
3. Arquivos/Tabelas mltiplas, campos e interaes de dados
4. Estruturas e interaes de dados complexas
5. Estrutura e interaes de dados muito complexas

Soma das Complexidades Lgica e de Dados

Exemplo da soma das complexidades:
Complexidade Lgica Algoritmos e clculos simples 1
Complexidade dos Dados Estruturas e interaes de dados complexas 1
Soma = 2

Definio do Multiplicador de Complexidade

Tabela 7-19
Soma das Complexidades Multiplicador de Complexidade
2 0.6
3 0.7
4 0.8
5 0.9
6 1.0
7 1.1
8 1.2
9 1.3
10 1.4

Determinar o Nmero de Algoritmos

Determinar o Nvel de Complexidade dos Algoritmos

A complexidade dos algoritmos determinada pelo nmero de regras e pelo
nmero de fatores ou elementos de dados requeridos. O algoritmo a seguir
exemplifica estes conceitos: Se funcionrio igual a gerente e salrio for maior
que 3000 ento deve ser avaliado o desempenho. Este exemplo contm uma
regra e dois fatores: funcionrio e salrio. A Figura 7-25 mostra a relao entre
nmero de fatores por regra e o nmero de regras em um algoritmo, as quais
determinam o nvel de complexidade do algoritmo.
 Empregar a Tabela de Transformao
Tabela 7-20
Parmetro Ocorrncias Peso Total
Algoritmos x 1 =
Entradas x 4 =
Sadas x 5 =
Consultas x 4 =
Arquivos Lgicos Internos x 7 =
Arquivos de Interfaces x 7 =
Total No Ajustado
Multip. de Complexidade
Feature Point Ajustado

Fontes de Informao: Software a ser entregue.

Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo 3 algoritmos com, respectivamente, pesos 1,2 e 3; 10 entradas, 10
sadas, 10 consultas, 5 arquivos , 2 interfaces e soma de complexidade 6.

Nmero de
Fatores
10
9 10
9
8
8
7
7
6
6

5 5
4
4
3
3
2
2
1
1

1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 Regras

Figura 7-25

Aplicando a tabela de transformao teramos a seguinte contagem de Feature Points:

Tabela 7-21
Parmetro Ocorrncias Pesos Total
Algoritmos 1x 1= 1
1x 2= 2
1x 3= 3
Entradas 10 x 4= 40
Sadas 10 x 5= 50
Consultas 10 x 4= 40
Arquivos 5x 7= 35
Interfaces 2x 7= 14
Total No Ajustado 185
Multip. Complexidade 1.0
Feature Points Ajust. 185

Produtividade do Desenvolvimento

Objetivo: Determinar a produtividade do desenvolvimento do software.

Mtodo de Determinao: O clculo da produtividade dado pela expresso:
Tamanho do Software em Pontos de Funo Esforo do Projeto.
Fontes de Informao: Clculo final dos FPs e registros de esforo do projeto.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo um software de tamanho 1000 Pontos de Funo, cujo projetodespendeu
cerca de 50 homens/ms, a produtividade ser de 20 PFs/H/M.

Custo do Ponto de Funo de Desenvolvimento

Objetivo: Determinar o custo unitrio do ponto de funo do projeto.

Mtodo de Determinao: O clculo dado pela expresso: Custo Total do
Projeto Tamanho Final do Software em Pontos de Funo.
Fontes de Informaes: Sistema de gerenciamento de projetos ou de controle de
custos de projetos e clculo final dos pontos de funo do projeto.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo um custo total em torno de $ 120.000,00 e o tamanho final em 1000
pontos de funo, o custo unitrio do ponto de funo de desenvolvimento seria de
$ 120,00.

Crescimento Funcional do Software Durante o Desenvolvimento

Objetivo: Determinar a variao do crescimento funcional do software ao longo do

projeto.
Mtodo de Determinao: O clculo dado pela expresso:

( FPF - FPI ) FPI x 100

onde:

FPF Pontos de Funo Final Calculado

FPI Pontos de Funo Estimados Inicialmente
Fontes de Informao: Documento de planejamento do projeto e clculo final do
tamanho do software.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo o FPI em 1000 e o FPF em 1300, o crescimento funcional seria de +30%.

Reutilizao do Cdigo

Objetivo: determinar a taxa de reutilizao de cdigo do projeto.

Mtodo de Determinao: A taxa de reutilizao pode ser calculada tomando
como base pontos de funo ou nmero de instrues fontes. O clculo para
ambos igual conforme a expresso a seguir:

(TCR TSU) x 100

onde:
TCR Tamanho do Cdigo Reutilizado
TSU Tamanho do Sistema na Unidade de Medida Escolhida
Fontes de Informaes: Registros de reutilizao de componentes de software,
clculo do tamanho do software ao final do projeto ou sistema de controle de
verses de software e de biblioteca de componentes reutilizveis.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo o TCR de 300 e p TSU de 1000, a taxa de reutilizao seria de 30%.

Complexidade do Software

Objetivo: Determinar a complexidade do software como um todo.

Mtodo de Determinao: O modelo de complexidade foi desenvolvido por Card
& Glass 5 sendo a complexidade determinada pelas expresses a seguir:

Ct = St + Dt
onde:
Ct complexidade do software
St complexidade estrutural
Dt complexidade de dados
sendo que:
2
St fi /n

Dt vi / fi + 1 / n
e:
fi fanout do mdulo i
vi variveis de I/O do mdulo i

Fontes de Informaes: Projetos de rotinas automatizadas.

Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo um sistema com 5 mdulos, cada mdulo com 2 fanouts e 44 variveis
de I/O.

St = 100 / 5 = 20
Dt = 73,33/5= 14.66
Ct = 34,66

Custo da Qualidade

Objetivo: Determinar o custo da qualidade do projeto.

Mtodo de Determinao: Como discutido no captulo 3, os custos da qualidade
so classificados em custos de preveno, custos de avaliao, custos de falhas
internas e custos de falhas externas. Na realidade, o custo da qualidade do projeto
o somatrio dos custos destas categorias. Mais detalhadamente, o custo da
qualidade determinado pela expresso:

( CTR+ CFE ) + ( CIN + CTT) + ( CRE) + ( CMI)

onde:
CT R Custo de treinamento para a equipe
CFE Custo de aquisio/alocao de ferramentas de apoio
ao desenvolvimento e gesto do projeto
CIN Custo das inspees, excluindo os de retrabalho
CTT Custo de testes do sistema, excluindo o custo de remoo
de falhas de execuo do software
CRE Custo de retrabalho
CMI Custo de manuteno inicial,quando da entrega do produto
Fontes de Informaes: Acompanhamento financeiro do projeto e processo de
inspeo.
Forma de Apresentao: interessante mostrar a relao entre os custos de
preveno com os custos de retrabalho e os custos da qualidade do projeto com o
custo total do projeto a fim de permitir anlises de sensibilidade. Dessa forma til
a apresentao grfica ou tabular desses resultados.
Exemplo:

Tabela 7-22
Tipo CP/CR CA/CR CTQ/
CTP
Custo Total do Projeto CTP 4000 25%
CustoTotal da Qualidade CTQ 1000
Custo de Preveno CP 100 14%
Custo de Avaliao CA 200 29%
Custo de Retrabalho CR 700

Distribuio do Esforo Por Fase

Objetivo: Determinar o comportamento da distribuio do esforo por fase do

projeto.
Mtodo de Determinao: Para cada fase do projeto determinar o percentual do
esforo conforme a expresso:

Efasei Efasei
ou seja, dividir o esforo da fase especfica pelo esforo total do projeto.
Fontes de Informao: Sistema de gerenciamento de projetos ou registros de
esforo do projeto.
Forma de Apresentao: grfica.
Exemplo:
 co
20% Leste Planejamento - 10%
Lest
Nort e Oeste Projeto do Produto - 30%

40% Nort
Oest Programao - 40%
co
e Integrao e Teste 20%

Distribuio do Custo Por Fase

Objetivo: Determinar o comportamento da distribuio do custo por fase do

projeto.
Mtodo de Determinao: Para cada fase do projeto determinar o percentual do
custo conforme a expresso:

Cfasei Cfasei
ou seja: Dividir o custo da fase especfica pelo custo total do projeto.
Fontes de Informao: Sistema de gerenciamento de projetos ou registros de
custo do projeto.
Forma de Apresentao: grfica.
Exemplo:
Similar ao exemplo anterior.

Distribuio dos Defeitos Por Fase

Objetivo: Determinar o comportamento da distribuio dos defeitos por fase do

projeto.
Mtodo de Determinao: Para cada fase do projeto determinar o percentual dos
defeitos conforme a expresso:

Dfasei Dfasei
ou seja: Dividir os defeitos da fase especfica pelo total de defeitos observados no
projeto.
Fontes de Informao: Processo de inspeo.
Forma de Apresentao: grfica.
Exemplo:
Similar ao exemplo anterior.

Densidade de Defeitos do Software

Objetivo: Determinar a densidade de defeitos do software sendo entregue.

Mtodo de Determinao: Como estamos tratando do produto em si, que
constitudo por instrues fontes ou por funes, a densidade de defeitos deve ser
determinada dividindo-se o nmero de defeitos restantes esperados pelo tamanho
do software em pontos de funo ou pelo nmero de instrues fontes. Para que
se defina os defeitos restantes pode-se empregar a frmula do ndice de eficincia
da remoo de defeitos ( vide exemplo da Estimativa Atualizada do Nmero de
Defeitos Ps-Release, no item 7.3.3) ou obter os dados atravs da ltima inspeo
do processo antes da entrega efetiva do software. A rigor esta medio
preliminar, pois somente com a coleta de dados sobre os defeitos comunicados
pelos usurios com a operao do software que poderemos de fato, estabelecer
esta medida. Lembre-se que no caso de utilizar instrues fontes importante
normalizar por1000 a densidade de defeitos.As expresses a seguir definem esta
medio.
Considerando densidade por 1000 instrues fontes:

( NDRS x 1000 ) NKDSI = defeitos por 1000 linhas

onde:

NDRS Nmero de Defeitos Restantes do Software

NKDSI Nmero Total de Instrues Fontes do Software

Considerando a densidade por pontos de funo:

NDRS Nmero de Pontos de Funo = defeitos por

PF.
Fontes de Informao: Registros de defeitos identificados pelo processo de
inspeo e ndice padro da eficincia de remoo de erros.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo 100 defeitos restantes esperados, tamanho em pontos de funo em
torno de 274 e 25 KDSI e software desenvolvido em Cobol:

( 50 x 1000 ) 25.000 = 2 defeitos por 1000 linhas

50 274 = .18 defeitos por ponto de funo

ndice de Tecnologia de Desenvolvimento Empregado

O ndice de tecnologia de desenvolvimento diz respeito ao nvel de utilizao de

ferramentas de apoio ao desenvolvimento, bem como s abordagens
metodolgicas utilizadas pelo projeto. Mede o nvel de sofisticao da tecnologia
de desenvolvimento aplicada ao projeto. Este ndice pode ser correlacionado com
as medidas de qualidade e produtividade a fim de auxiliar na modelagem do
melhor ambiente de desenvolvimento.

O ndice tecnolgico tem vrios componentes, quais sejam:

Ambiente de desenvolvimento
Emprego de metodologia de desenvolvimento
Ferramentas de apoio ao desenvolvimento
Tipo de CASE utilizado
Tcnicas de especificao e desenvolvimento
Utilizao de mtodos de identificao e remoo de erros

Objetivo: Determinar o nvel de sofisticao da tecnologia de desenvolvimento

empregada.
Mtodo de Determinao: Cada componente pode ser traduzido por uma varivel
ordinal, composta por tens que definem nveis de sofisticao. Cada componente
tem um peso e cada item tem uma nota. O ndice dado pela mdia ponderada
ou:

( Pesos x Notas ) / Pesos =

Ambiente de Desenvolvimento ( peso 5 )

a) No h apoio eletrnico para elaborao dos documentos do projeto; no h

biblioteca tcnica disponvel para as equipes de projeto; sem automao do
controle de verses dos componentes do software; um terminal ou micro para
cada quatro analistas/programadores; ferramentas mnimas de depurao; as
equipes de projetos no possuem rea reservada; no existe reas para
armazenagem de materiais, listagens; no existem salas de reunio disponveis
para revises tcnicas e no h monitoramento de defeitos. ( Nota 1 )
b) Algum suporte de edio de textos para a documentao de projetos; pequena
e escassa biblioteca tcnica; controle das verses para o cdigo-fonte; a
documentao controlada manualmente; um terminal/micro para cada
analista/programador; algumas ferramentas de depurao; escritrios
compartilhados por trs ou quatro analistas/programadores; uma ou duas salas de
reunio; sistema manual de registro de erros. ( Nota 3 )
c) Apoio informatizado para a documentao do projeto; boa biblioteca tcnica a
disposio para as equipes de projetos; controle de verses de componentes de
software automatizado; um terminal/micro para cada analista/programdor, com
terminais extras como back-up; ferramentas de depurao; bibliotecas de testes;
espao adequado aos analistas/programadores com reas de armazenagem
adequadas; salas de reunio adequadas. ( Nota 5 )

Emprego de Metodologia de Desenvolvimento ( peso 5 )

a) O projeto no utilizou nenhuma metodologia de desenvolvimento (Nota 1)

b) O projeto usou apenas um roteiro bsico, com fases e etapas (Nota 2 )
c) Alm das fases e etapas, haviam produtos a serem gerados em cada fase (
Nota 3)
d) A metodologia empregada, alm de C, indicava tcnicas a serem utilizadas,
bem como recomendaes e esquema de gerenciamento (Nota 4)
e) A metodologia empregada automatizava todo o ciclo de desenvolvimento (Nota
5)

Ferramentas de Apoio ao Desenvolvimento ( peso 5 )

Verificador de sintaxe
Depurador interativo
Prototipador
Gerador de telas
Gerador de relatrios
Gerador de grfico
Gerador de cdigo-fonte
Otimizadores
 Linguagens com facilidades de depurao
Gerador de dados para teste
Dicionrio de dados
Documentador automtico
Analisador de cdigo
Utilitrios de otimizao de banco de dados
Controle automatizado de verses

0 a 2 itens assinalados nota 1

3 a 5 itens assinalados nota 2
6 a 8 itens assinalados nota 3
9 a 12 itens assinalados nota 4
13 a 15 itens assinalados nota 5

Tipo de CASE ( Computer Aided Software Engineering) Empregado

( peso 4 )

a) O projeto no empregou CASE ( Nota 1 )

b) lower CASE ( Nota 2)
c) upper CASE (Nota 3)
d) integrated CASE (Nota 5)

Tcnicas de Especificao e Desenvolvimento ( peso 5 )

a) O projeto utilizou apenas anlise estruturada ( Nota 1)

b) O projeto utilizou , alm de a, modelagem de dados ( Nota 2 )
c) O projeto utilizou alm de b, prototipao e JAD ( Nota 3 )
d) O projeto utilizou anlise essencial , JAD e prototipao ( Nota 4 )
e) O projeto utilizou anlise orientada a objetos ( Nota 5 )

Utilizao de Mtodos de Identificao e Remoo de Erros

( peso 5 )

Reviso dos requisitos

Reviso do projeto lgico
Reviso do projeto do projeto fsico de banco de dados
Reviso dos projetos de rotinas automatizadas
Inspeo e reviso do cdigo
Verificao e validao independente
Teste de exatido de algoritmos
Teste de programas individuais
Teste de unidade de implantao
Teste integrado
Teste de desempenho
Teste de aceitao
Teste de campo
Organizao de teste independente
Anlise de mdulos com erros crnicos
 Investigao da satisfao do usurio

0 a 3 itens assinalados nota 1

4 a 6 itens assinalados nota 2
7 a 9 itens assinalados nota 3
10 a 12 itens assinalados nota 4
13 a 16 itens assinalados nota 5

O conjunto de valores possveis est entre: 1 e 5

Fontes de Informaes: Avaliao final do projeto.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Convidamos o leitor a aplicar o instrumento em um de seus projetos.

ndice de Tecnologia de Gesto Aplicado ao Projeto

Este ndice tem uma funo similar ao anterior, a diferena que ele mede o nvel
de sofisticao da gesto do projeto.

Os componentes deste ndice so:

Estimativas de prazos, custos e recursos
Elaborao de cronogramas e oramentos
Pert/CPM
Acompanhamento fsico/financeiro
Controle de custos
Ferramenta de monitoramento de defeitos
Comunicao eletrnica entre membros da equipe
Controle de mudanas e de configurao

Estimativas de Prazos, Custos e Recursos ( peso 5 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5 )

Elaborao de Cronogramas e Oramentos ( peso 5 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5 )

Pert/CPM ( peso 3 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5 )

Acompanhamento Fsico/Financeiro ( peso 5 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5)

Controle de Custos ( peso 5 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5)

Ferramenta de Monitoramento de Defeitos ( peso 5 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5)

Comunicao Eletrnica Entre Membros da Equipe ( peso 3 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5)

Controle de Mudanas e de Configurao ( peso 4 )

a) No tem ( nota 1)
b) Manual ( nota 2 )
c) Parcialmente automatizada ( nota 3 )
d) Grande parte automatizada ( nota 4 )
e) Totalmente automatizada ( nota 5)

O conjunto de valores possveis est entre: 1 e 5.

Outras Medies Qualitativas

As medies qualitativas so realizadas para fornecer indicativos de causas para

a melhor ( pior) qualidade e produtividade do projeto, visando subsidiar a gerncia
de desenvolvimento com informaes teis para que possa aperfeioar
continuamente o processo de desenvolvimento de software da instalao. Essas
medies qualitativas podem ser empregadas juntamente com os ndices de
tecnologia de desenvolvimento e de gesto a fim de fornecer um quadro amplo
dos aspectos subjetivos do processo.

As medies qualitativas compreendem:

Perfil da equipe tcnica do projeto

Novidades das especificaes do software
Experincia da equipe na rea de aplicao do software
Experincia da equipe na rea de aplicao do software
Envolvimento dos usurios
Novidade da tecnologia para a equipe
Experincia dos usurios com projetos de sistemas
Experincia da equipe com mtodos de remoo de erros
Geografia do desenvolvimento
Coeso tcnica apresentada durante o projeto
Principais ocorrncias

Perfil da Equipe Tcnica do Projeto

Em relao ao ambiente de desenvolvimento:

Experincia nas ferramentas de apoio ao desenvolvimento

Experincia nos mtodos e tcnicas de anlise e projeto
Experincia nas linguagens de programao
Experincia em mtodos e tcnicas de revises e inspees
Experincia em tcnicas de teste de sistemas
Experincia no hardware de desenvolvimento

Estabelecer o percentual, conforme o total dos membros da equipe em termos de:

Pouca experincia - at 2 itens assinalados :_____%

Mdia experincia - 3 e 4 itens assinalados:_____%
Grande experincia - 5 e 6 itens assinalados:_____%

Novidades das Especificaes do Software

a) Nenhuma novidade
b) Pouca novidade
c) Mdia novidade
d) Grande novidade
e) Especificaes totalmente desconhecidas pela equipe

Experincia da Equipe na rea de Aplicao do Software

a) Nenhuma experincia
b) Pouca experincia
c) Mdia experincia
d) Grande experincia
e) Domnio da rea de aplicao

Experincia dos Usurios na rea de Aplicao do Software

a) Nenhuma experincia
b) Pouca experincia
c) Mdia experincia
d) Grande experincia
e) Domnio da rea de aplicao

Envolvimento dos Usurios

a) Nenhum envolvimento
b) Pouco envolvimento
c) Mdio envolvimento
d) Grande envolvimento
e) Total participao, inclusive com usurios alocados full-time ao projeto

Novidade da Tecnologia Para a Equipe

a) Tecnologia de hardware e software desconhecida pela equipe

b) Poucos elementos da tecnologia dominados pela equipe
c) Domnio mediano da tecnologia
d) Maioria dos componentes da tecnologia dominados pela equipe
e) Domnio completo da tecnologia

Experincia dos Usurios Com Projetos de Software

a) Nenhuma experincia com projetos de software

b) Pouca experincia
c) Alguns membros com experincia
d) A maioria com experincia em projetos de software
e) Todos os usurios com experincia em projetos de software

Experincia da Equipe Com Mtodos de Remoo de Erros

a) Nenhuma experincia
b) Pouca experincia
c) Mdia experincia
d) Grande experincia
e) Domnio completo

Geografia do Desenvolvimento

a) Projeto foi desenvolvido em um nico local

b) Projeto foi desenvolvido em mais de um local na mesma cidade
 c) Projeto foi desenvolvido com participao de vrias fornecedores numa
mesma cidade
d) Projeto foi desenvolvido por equipes distribudas em diversas cidades
e) Projeto foi desenvolvido com participao de equipes distribudas em
diversos pases

Coeso Tcnica Apresentada Durante o Projeto

a) Nenhuma coeso tcnica entre os membros

b) Pouca coeso tcnica
c) Mdia coeso tcnica
d) Grande coeso tcnica
e) Coeso tcnica total

Principais Ocorrncias

Ocorrncias referem-se s contingncias voluntrias ou involuntrias que podem

acontecer no decorrer do projeto e que se caracterizam como eventos impactantes
no projeto, em termos de prazos, custos e qualidade.

As principais ocorrncias devem ser registradas para que a anlise posterior do

projeto, assim como a anlise do processo de software possa ser realizada,
confrontando resultados com possveis causas.

Contingncias so eventos que podem ocorrer no incio, no meio ou no final do

projeto e que, geralmente demandam ao gerencial imediata para manter o
projeto sob controle.

Exemplos de contingncias que impactam negativamente o projeto:

Mudana no ambiente de hardware/software durante o desenvolvimento

Alta rotatividade na equipe tcnica do projeto
No alocao dos recursos ao projeto conforme o planejado
Mudana constante nos membros da equipe de usurios
Mudanas de escopo do projeto quando este est na fase de projeto
fsico
Motivos de fora maior, tais como greves

Ao final deste captulo gostaramos de alertar o leitor que apenas apresentamos as

medies que consideramos as mais importantes.

Nosso objetivo foi o de mostrar as possibilidades de medir o processo de software,

apesar do desconhecimento e da desconfiana que existe na rea de informtica quanto
a este tpico.

importante considerar tambm que, em termos prticos, os gerentes e

engenheiros de software devem selecionar somente aquelas medies que so crticas e
que estejam de acordo com os objetivos que se pretende atingir. impraticvel, a no ser
em grandes corporaes de classe mundial em excelncia, empregar todas as
medies,talvez com o tempo consiguamos.
REFERNCIAS

1. BEIZER, Boris. Software Testing Techniques. Van Nostrand Reinhold, New

York,1990.

2. BOEHM, Barry. Software Engineering Economics. Prentice-Hall, Englewood

Cliffs,New Jersey,1981.

3. BROOKS,Frederick P. The Mythical Man-Month. Addison-Wesley,Reading,MA,1975.

4. BUSH,Marilyn. Formal Inspections - Do They Really Help? NSIA Sixth Annual National
Joint Conference on Software Quality and Productivity, Williamsburg,VA, april
1990.

5. CARD,David & GLASS, P.L. Measuring Software Design Quality. Prentice-

Hall,Englewood Cliffs,New Jersey, 1990.

6. EBENAU,R.G. & STRAUSS, S.H. Software Inspection Process. McGraw-Hill,New

York,1994.

7. FEIGENBAUM,Armand V. Total Quality Control. McGraw-Hill, 3rd edition,New

York,1986.

8. FREEDMAN, D.P. & WEINBERG,G.M. Manual de Walkthroughs: inspees e revises

tcnicas de especificaes de sistemas e programas. McGraw-Hill,So Paulo,1993.

9. JONES,Capers. Applied Software Measurement.McGraw-Hill, New York, 1991.

10.McCABE, T. A Complexity Measure. IEEE Transactions on Software Engineering,Dec

1976.

11.McCORMIK,K. Results of Using Inspections for the AT&T ICIS Project. Second
Annual Symposium on EDP Quality Assurance, March 1993.

12.MUSA, J.D. et al. Software Reliability. McGraw-Hill, New York,1990.

13.RUSSEL,Glen W. Experience With Inspections in Ultralarge Scale

Development.IEEE Software, vol 17, No1, January 1991.
Captulo
8
APLICAO DAS MEDIES
NA GESTO DO PRODUTO

Os principais fatores motivadores para que sejam aplicadas medies na gesto do

produto so:

Melhorar continuamente a qualidade do produto

Melhorar continuamente a qualidade do atendimento s solicitaes dos
clientes/usurios
Fornecer a base necessria para o gerenciamento das manutenes e
projetos de melhorias do software
Monitorar a qualidade do produto ao longo de sua vida til

O processo de gesto do produto possui caractersticas, tanto do planejamento

de projetos como do desenvolvimento de software.

Durante a gesto do produto, as manutenes corretivas, adaptativas e projetos

de melhorias tambm devem ser planejadas. Se levarmos em considerao que na
mdia, cerca de 70% dos recursos de desenvolvimento esto alocados manuteno
e implementao de pequenas melhorias nos produtos de software, o planejamento
torna-se ento, crtico.

A execuo do planejado ou de solicitaes inesperadas, as quais normalmente

so maioria, requerem um monitormento constante, visando no s a qualidade como
tambm a liberao de recursos humanos, obtendo assim maior capacidade de
atendimento, tanto para novos projetos como para a manuteno/melhoria dos
produtos em operao.

Este captulo culmina com o conjunto de medies necessrias, a nvel

operacional, para o gerenciamento efetivo do software em seu ciclo de vida.

Analogamente aos captulos anteriores, que trataram mais objetivamente sobre

a aplicao das medies, neste captulo procuramos descrever, sob nosso ponto de
vista, no que consiste o processo de gesto do produto, suas fases e particularidades
e por fim, as medies julgadas importantes para o gerenciamento.

8.1 - O Processo de Gesto do Produto

O processo de gesto do produto pode ser vislumbrado como possuindo os

mesmos elementos da gesto do processo de desenvolvimento. A diferena
fundamental que aqui estamos preocupados em realizar as manutenes corretivas e
adaptativas, assim como as melhorias no produto , sejam elas representadas por
pequenos incrementos ou por melhorias significativas.
 Apesar dessa diferena, devemos igualmente gerir a qualidade do produto, a
qualidade do atendimento, visando a contnua satisfao dos clientes/usurios, a
gesto do progresso do atendimento das solicitaes , a gesto financeira e de
recursos do atendimento e de mudanas.

A Figura 8-1 nos d esta viso.

Gesto da Controle do Gesto Gesto das

Qualidade Progresso Financeira Mudanas

MEDIES E ANLISES

Planeja-
Manuteno Manuteno Projetos de
mento
Corretiva Adaptativa Melhoria

ATENDIMENTO

INSPEO E AVALIAO

MONITORAMENTO

Figura 8-1
Modelo de Gesto do Produto

Planejamento do Atendimento

O planejamento do atendimento compreende dois momentos. Um momento no

qual o atendimento ao produto planejado considerando o perodo de um ano e
o outro diz respeito ao planejamento do atendimento de uma solicitao
especfica, a qual pode abranger vrios servios,isto , uma srie de
manutenes corretivas ou adaptativas ou de melhorias ou at mesmo
combinaes entre elas.

Igualmente ao que feito para o planejamento de projetos, o planejamento de

atendimento deve estimar prazos, custos e recursos e outros atributos
requeridos para a posterior confrontao com o realizado.

Manuteno Corretiva

Devido aos atributos da release entregue logo aps o trmino do projeto, pode-
se prever a necessidade de manutenes corretivas no produto no que tange a
frequncia provvel de atendimento. Geralmente essas manutences so
derivadas de solicitaes no programadas.
As manutenes corretivas normalmente tm sua nfase logo no incio da
operao do software ou quando da entrega de nova release. Tambm podem
ser ocasionadas pelas manutenes adaptativas.

O processo de manuteno corretiva usualmente abrange as seguintes etapas:

IDENTIFICAO
DO DEFEITO OU
FALHA

ENTENDIMENTO
DO PROBLEMA

ACERTOS EM
PROGRAMAS E/
OU ESTRUTURA
DE DADOS

TESTE DOS
ACERTOS

LIBERAO DOS
ACERTOS

Figura 8-2
Etapas da Manuteno Corretiva

Manuteno Adaptativa

Estas manutenes so em decorrncia de mudanas em legislao,

procedimentos de rgos reguladores, otimizao do software e mudana da
tecnologia.

As manutenes adaptativas podem ser programadas. Em alguns setores

econmicos que tm forte ingerncia regulatria, como o setor financeiro, h
manutenes adaptativas que so impossveis de serem programadas, pois so
decorrncia de mudanas na legislao ou em procedimentos expedidos por
autoridade monetria.
 Projetos de Melhoria

Projetos de melhoria referem-se a incrementos de novas funes no software ,a

fim de atender a evoluo do negcio da empresa. A maioria dos projetos de
melhoria podem ser programados. Projetos de melhoria no programados
evidencia falta de alinhamento entre a rea de informtica e seus
clientes/usurios. Em projetos de melhoria tambm possvel o emprego
do processo de inspeo.

Dependendo do rigor metodolgico utilizado pela empresa , o projeto de

melhoria pode implicar na reformulao do modelo de dados, na reformulao
do modelo operacional do projeto, na reformulao do projeto fsico do banco
de dados e assim sucessivamente. Neste caso imperioso o emprego de
inspeo e tratar o projeto como se fosse de desenvolvimento.

O processo simplificado de projetos de melhoria mostrado pela Figura 8-3 a

seguir.
ANLISE DOS
INCRE-
MENTOS

ANLISE DE
IMPACTO NA
ESTRUTURA DE
DADOS E
FUNCIONAL

REFORMULAO DO
MODELO DE DADOS
E FUNCIONAL

REFORMULAO DO
PROJETO FSICO DO
BANCO DE DADOS

PROJETO DAS
ROTINAS
AUTOMATIZADAS

CODIFICAO E
TESTE INDIVIDUAL
DE PROGRAMAS

TESTE DAS
UNIDADES DE
IMPLEMENTAO

TESTE INTEGRADO
DA NOVA RELEASE

TESTE DE
ACEITAO PELO
CLIENTE/USURIO

LIBERAO DA
NOVA RELEASE

Figura 8-3
Etapas de Projetos de Melhoria
 Os demais componentes so similares aos do processo de desenvolvimento.

Entretanto, na gesto do produto, a qualidade e os aspectos financeiros devem

ser monitorados ao longo da vida til do software,no somente no que diz respeito a
um atendimento especfico.

Outro conceito fundamental o de release. Dependendo da extenso, uma ou

mais manutenes adaptativas geram uma nova release do software. Um projeto de
melhoria, por sua vez, gera necessriamente uma nova release.

Portanto, ao longo de sua vida til, um produto de software pode ter uma srie
de releases.

importante, no contexto desta abordagem, o controle das releases em termos

de documentos e componentes de software, a fim de evitar retrabalho. SE houverem
mudanas, temos que ter a possibilidade de recuperar algumas features de releases
anteriores.

Estes pontos definem a essncia da gesto do produto.

As medies para o processo de gesto do produto tambm se dividem

conforme o mecanismo de medio, mostrado pela Figura 8-4.

PROCESSO DE GESTO DO
SOFTWARE PROCESSO

PROCESSO DE PROCESSO DE
PLANEJAMENTO SOFTWARE
DE PROJETOS

Figura 8-4
Medies na Gesto do Produto

As medies que devem ser realizadas para a gesto do produto concentram-

se ento em:

Medies para o prprio processo de gesto do produto

Medies para subsidiar o aperfeioamento do processo de
planejamento de projetos
Medies para subsidiar o aperfeioamento do processo de
desenvolvimento de software

A estrutura lgica de apresentao das medies neste captulo segue a

utilizada pelo captulo anterior.
8.2 - Medies Para a Gesto do Produto

As medies relativas a gesto do produto podem ser classificadas em:

Medies para o planejamento anual de atendimento

Medies para o planejamento de atendimento especfico
Medies para o monitoramento do atendimento
Medies para o monitoramento do produto

8.2.1 - Medies Para o Planejamento Anual de Atendimento do Produto

O planejamento anual de atendimento do produto de software, tenta prever as

quantidades de esforo e recursos necessrias, bem como estabelecer o custo anual
previsto deste atendimento. O somatrio dos custos de todos os atendimentos mais os
custos previstos para os projetos, configuram o oramento da rea de
desenvolvimento.

Adicionalmente tenta estimar alguns atributos relativos a qualidade do produto,

para fins de comparao e controle.

importante estabelecer dois momentos para o planejamento anual de

atendimento.

Um momento quando se deve planejar o atendimento logo aps a entrada da

release em operao, ou seja, no se tem informaes ( data set) sobre o
desempenho do atendimento ao produto especfico. Para fins de apresentao do
mtodo de determinao, chamaremos de momento #1.

Um segundo momento quando j existe uma histria de atendimento e,

portanto, h informaes histricas quantitativas sobre o produto. Chamaremos este
de momento #i , pois ocorre repetidas vezes.

No primeiro momento as informaes que vo subsidiar o planejamento so as

relativas a produtos similares em termos de tamanho e plataforma de
hardware/software, em virtude de que no existem dados histricos.

No segundo momento deve-se utilizar as informaes que demonstram a

prpria evoluo do produto.

Ao apresentarmos as medies, enfocaremos ambos momentos.

Estimativa de Esforo de Atendimento

Objetivo: Determinar o esforo necessrio para o atendimento satisfatrio s

solicitaes de manuteno e evoluo do produto por parte dos
clientes/usurios considerando um perodo de 12 meses.
Mtodo de Determinao: Aqui devemos considerar os dois momentos.

Momento #1
A estimativa de esforo anual de atendimento dada pela expresso:
 EAM =CFM PAM
onde:
CFM Crescimento funcional mdio anual do produto, obtido
para produtos similares em termos de tamanho,plataforma
e rea de aplicao na empresa
PAM Produtividade mdia anual do atendimento, que dada
pelas produtividades mdias das manutenes
corretivas,adaptativas e projetos de melhoria
Momento #I
Para o momento #I, h duas alternativas, sendo uma dada pelo mtodo
COCOMO.

Mtodo #1
A estimativa de esforo anual de atendimento dada pela expresso:

CMP PMP = EAM

onde:
CMP Crescimento funcional mdio anual do prprio produto
PMP Produtividade mdia anual do atendimento ao prprio
produto

Mtodo #2
Pelo mtodo COCOMO ( modelo bsico), a estimativa do esforo anual de
atendimento dada pelas expresses:

(1) ACT = ( IFA + IFM ) KDSI

onde:
ACT Trfego anual de mudana ( Annual Traffic Change)
IFA Instrues fontes adicionadas
IFM Instrues fontes modificadas
KDSI Tamanho do software a ser mantido

(2) EAM = 1.0 ( ACT) (EPR)

onde:
EPR Esforo do projeto original

Fontes de Informaes: Data set com informaes sobre os padres de

produtos similares ou com informaes sobre o prprio produto.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Com a informao da estimativa de esforo, estimar o nmero
de profissionais a serem alocados em tempo integral ao atendimento e o custo
anual previsto.
Exemplo:

Momento #1
Supondo que o crescimento anual mdio para produtos similares seja de 200
Pontos de Funo e que a produtividade mdia de atendimento seja de 20 FPs
por homem/ms, o esforo anual previsto seria de 10 H/M.
Momento#i
Mtodo #1
Supondo que o crescimento anual mdio do produto seja de 100 Pontos de
Funo e que a produtividade mdia de atendimento seja de 15 FPs por
homem/ms, o esforo anual previsto seria de 6,67 H/M.
Mtodo #2
Supondo que a mdia anual de IFA seja de 3000 e a mdia de IFM seja de
2000; considerando que o software tenha 50 KDSI , cujo esforo original para
seu desenvolvimento tenha sido de 146 H/M ,o EAM seria de 14,60 H/M.

Estimativa do Nmero de Profissionais Para o Atendimento

Objetivo: Determinar o nmero de profissionais que devero ser alocados em

tempo integral para o atendimento ao produto.
Mtodo de Determinao: A determinao dada pela expresso:

NPA = EEA 12
onde:
EEA Esforo estimado anual de atendimento
12 Nmero de meses do ano
Fontes de Informao: Estimativa de esforo anual de atendimento.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Definir a alocao do recurso tendo em vista o perfil
necessrio.
Exemplo:
Supondo o esforo anual em 24 H/M , o nmero de profissionais seria 2
alocados em tempo integral.

Estimativa do Custo de Atendimento

Objetivo: Determinar o oramento anual de atendimento para um produto

especfico.
Mtodo de Determinao: Aqui h duas alternativas.

Mtodo #1:
O custo anual de manuteno dado pela expresso:

CMFP x CFM =
onde:
CMFP Custo mdio do Ponto de Funo de atendimento
CFM Crescimento funcional mdio do produto em FPs
O CMFP obtido pela mdia das mdias do custo de FPs de manuteno
corretiva, manutenes adaptativas e projetos de melhoria.

Mtodo #2:
O custo anual de manuteno dado pela expresso:

CMHM x EEA
onde:
EEA Esforo estimado anual de atendimento
 CMHM Custo Mdio do Homem/Ms

Fontes de Informaes: Dados de custo da mo de obra e estimativa anual de

esforo.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Registrar o oramento para fins de controle.
Exemplo:

Mtodo #1
Supondo o custo mdio do ponto de funo do atendimento em torno de $ 204
e o CFM em torno de 300, o custo anual seria de $ 61.200.

Mtodo #2
Supondo o custo mdio homem/ms em torno de $ 16 e o esforo estimado em
24 H/M ou $ 3840, o custo anual seria de $ 61.440.

Estimativa Esperada de Defeitos do Atendimento

Objetivo: Determinar o nmero de defeitos esperados durante o atendimento

anual.
Mtodo de Determinao: O clculo do nmero de defeitos dado pela
expresso:

EED = DDR x CFM

onde:
DDR Densidade de defeitos da release

O DDR a densidade da release atual, calculada aps o trmino do projeto ou

por medies que devem ser realizadas nos momentos #I.
Fontes de Informaes: Banco de dados de mtricas o qual contm dados
sobre as densidades atuais de defeitos dos produtos.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Com esta estimativa, o gerente do produto pode calcular o
esforo e respectivo custo de retrabalho esperado e, portanto, os custos da m
qualidade de falhas externas.
Exemplo:
Densidade em Pontos de Funo:
Supondo a densidade em 0,5 defeitos por ponto de funo e o CFM em 200,
ento o nmero de defeitos esperados seria em torno de 100.
Densidade em 1000 Linhas de Instrues Fontes:
Supondo a densidade de 12 por 1000 e um CFM de 18.000 linhas de instrues
fontes( transformados a partir dos pontos de funo), a densidade seria de 216.

Esforo Esperado de Retrabalho

Objetivo: Determinar o esforo de retrabalho durante o atendimento anual.

Mtodo de Determinao: O esforo de retrabalho pode ser calculado atravs
da equao de regresso dada pela expresso:

Esforo de Retrabalho = f ( CFM)

 Para tanto preciso que a instalao tenha no seu banco de dados de
mtricas, informaes sobre o esforo de retrabalho correspondente a um ponto
de funo de atendimento.
Fontes de Informao: Banco de dados de mtricas.
Forma de Apresentao: nenhuma especifica.
Ao Gerencial: Com base nesta informao o gerente poder estimar o custo
de retrabalho esperado.
Exemplo: Vide exemplo referente a estimativa do nmero de defeitos
pr-release apresentado no captulo 6.

Custo Esperado do Retrabalho do Atendimento

Objetivo: Determinar o custo esperado do retrabalho do atendimento.

Mtodo de Determinao: Pode ser determinado tambm por regeresso
linear ou multipicando-se o esforo estimado de retrabalho pelo custo do
homem/ms ou homem/hora.
Fontes de Informao: Registros de custos de mo de obra e estimativa de
esforo de retrabalho.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Informao a ser utilizada para o controle dos custos relativos
qualidade do produto.
Exemplo:
Supondo o esforo esperado de retrabalho em 5 H/M ou 800 homens/hora e o
custo do homem/hora em $20, teramos cerca de o custo de $ 16.000 como
custo de retrabalho.

8.2.2 - Medies Para o Planejamento de Atendimento Especfico

Essas medies referem-se ao planejamento do atendimento das

manutenescorretivas, adaptativas e projetos de melhoria.

Como vimos anteriormente, as manutenes corretivas, visto serem de

natureza no programada , torna quase impraticvel o planejamento de seu
atendimento. A nica possibilidade prevermos a probabilidade da ocorrncia de
solicitaes dessa natureza, com base no histrico de atendimento, bem como
definirmos as falhas esperadas em funo da intensidade atual de falhas.
 Planejamento do Atendimento a Manutenes Corretivas

A probabilidade da ocorrncia de eventos ( solicitaes de manutenes

corretivas) pode ser caracterizada pela distribuio de probabilidade de Poisson e pela
distribuio exponencial.

A distribuio de Poisson pode ser usada para determinar a probabilidade de

uma dado nmero de sucessos quando os eventos ocorrem em um continuum de
tempo ou espao. Por exemplo, a chegada de solicitaes de manutenes corretivas
enquadra-se neste processo.

Se os eventos ou sucessos ocorrem num processo de Poisson, ento o

comprimento de tempo ou espao entre dois eventos sucessivos segue uma
distribuio exponencial.

A distribuio exponencial se aplica se desejarmos saber o tempo at a

ocorrncia do primeiro evento, o tempo decorrido at acontecer o primeiro evento,
considerando um ponto aleatoriamente selecionado e, o tempo entre dois eventos
sucessivos.

A determinao da probabilidade de um dado nmero X de sucessos em uma

distribuio de Poisson possvel pela seguinte expresso:

x -
P(X ) = e X!
onde :
nmero mdio de sucessos no tempo ou espao
e algarismo neperiano constante = 2,7183

No caso da distribuio exponencial, a determinao das probabilidades dada

pelas expresses:
-
(1) P(Tt)=1-e
-
(2) P(T>t)=e
onde:

(1) utilizada para determinar a probabilidade da ocorrncia

do primeiro evento dentro de um intervalo de tempo especificado.
(2) utilizada para determinar a probabilidade de que o
primeiro evento no ocorrer dentro do intervalo de tempo especificado.

No caso em que o tempo de atendimento s solicitaes de manutenes

corretivas se comportarem como uma distribuio normal de probabilidade possvel
estimar a probabilidade de que um atendimento especfico seja concludo dentro do
tempo solicitado pelo cliente/usurio.

Vide Kazmier 5 para maiores detalhes sobre essas distribuies de probabilidade.

 Para se determinar a probabilidade, na distribuio normal, emprega-se a
seguinte frmula:

z=(X-)
onde:
a mdia da distribuio de probabilidade
o desvio padro da distribuio

A seguir daremos alguns exemplos de aplicao.

Utilizao dos Modelos de Probabilidade

Probabilidade da Ocorncia do Primeiro Evento

Supondo que, em mdia, 5 solicitaes de manuteno corretiva para um

software sejam recebidas a cada 5 dias. Qual a probabilidade de que, a partir
do trmino da manuteno corretiva, se passem 10 dias antes do recebimento
da prxima solicitao? ( Distribuio Exponencial)

para 5 dias 1
para 10 dias 2
-2
( T > 10 ) = e = 0,13534

Neste exemplo a probabilidade seria de aproximadamente 13%.

Probabilidade De Que Sejam Recebidos Mais do Que X Solicitaes

Supondo que as solicitaes de manutenes corretivas chegam

aleatoriamente numa mdia de 10 para cada 20 dias. Qual a probabilidade de
que sejam recebidas mais do que 30 solicitaes em um ms?( Aproximao
pela normal da distribuio de Poisson)

Em virtude de que a mdia para um perodo de 30 dias maior do que

= 10, podemos empregar a distribuio normal para aproximar o valor da
probabilidade de Poisson.

Neste caso = = 15 ( 10 20 = .5; .5 x 30 = 15)

= = 3.87

z = (30,5 - 15) 3,87 4.0

P(X 30,5 ) = P ( z + 4) = 0,5000 - 0,4999 = 0,0001

Neste caso a probabilidade de ocorrer mais de 30 solicitaes em um ms

quase inexistente.

Existem tabelas padres para as distribuies de Poisson e Normal dado e X.

Probabilidade do Recebimento de Um Nmero X de Solicitaes

Em mdia, so recebidas 5 solicitaes de manuteno corretiva num perodo

de uma semana. Qual a probabilidade de que, em uma semana selecionada
aleatoriamente, sejam recebidas exatamente 6 solicitaes? ( Distribuio de
Poisson)
6 -5
P (X = 6 = 5.0) (5) e 6! 0.15 ou 15%

Probabilidade de Tempo de Atendimento - Exemplo 1

O tempo necessrio para o atendimento a uma solicitao de manuteno

corretiva normalmente distribuda com mdia = 16 horas e desvio padro
= 4 horas. O cliente/usurio deseja um prazo de no mximo 10 horas. Qual a
probabilidade de que a solicitao seja atendida no prazo exato de 10 horas?
(Distribuio Normal)

z = ( 10 - 16 ) 4 = - 1,50
P ( X = 10) = 0,4332 ou 43%

Probabilidade de Tempo de Atendimento - Exemplo 2

Considerando os mesmos parmetros de mdia e desvio padro do exemplo

anterior, foi comunicado ao cliente/usurio que a solicitao de manuteno
corretiva ser atendida no prazo de 18 horas. Qual a probabilidade de que este
compromisso no possa ser cumprido?

P ( X > 18 ) = z = (18 - 16) 4 = 0,50 = 0,5000 - 0,1915 = 0,3085 ou

31%

Probabilidade do Tempo de Atendimento - Exemplo 3

Considerando os mesmos parmetros de mdia e desvio padro do exemplo

exemplo 1, qual a probabilidade da solicitao ser atendida em menos de 10
horas?

P ( X < 10 ) = z = ( 10 - 16 ) 4 = -1,50 = 0,5000 - 0,4332 = 0,0668

ou 7%.

Ao Gerencial: O emprego de modelos de distribuio de probabilidade

possibilita ao gerente balancear a carga de trabalho alocada aos software que
se encontram em operao, assim como, atravs do bom senso que as
probabilidades proporcionam, determinar compromissos que tenham a maior
probabilidade de sucesso.

Falhas Esperadas do Software

As falhas esperadas do software so determinadas a partir da intensidade de

falha atual do produto.
 Essas falhas podem ser determinadas utilizando-se as mesmas frmulas
empregadas no captulo 7 quando da exposio das medies para estabelecer
a intensidade de falha da primeira release do software.

Planejamento do Atendimento s Manutenes Adaptativas

As manutenes adaptativas podem ser vistas sob diversas formas, quais

sejam:

Reprojetar o software para adapt-lo a um novo produto

Alterar partes do cdigo para acomodar novas caractersticas
Integrar o cdigo adaptado ao software e testar a nova release

Um dos nicos modelos que proporcionam a medio do esforo, prazo e custo

de uma manuteno adaptativa o COCOMO 1.

Estimativa do Esforo da Manuteno Adaptativa

Objetivo: Determinar o esforo necessrio para o atendimento a uma

manuteno adaptativa.
Mtodo de Determinao: A estimativa dada pelas seguintes expresses:

(1) AAF = 0.40 (DM) + 0.30 (CM) + 0.30 (IM)

onde:
AAF fator de ajustamento de adaptao
DM percentagem do projeto original ou atual que modificado
( medido subjetivamente)
CM percentagem do cdigo que modificado
IM percentagem do esforo requerido para integrar e testar a
adaptao, comparada com o esforo realizado para
integrar e testar o software quando do seu
desenvolvimento

(2) EDSI = (ADSI) x ( AAF 100)

onde:
EDSI nmero equivalente de instrues fontes
ADSI nmero de instrues fontes entregues adaptadas do
software
Fontes de Informao: Anlise da adaptao.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Com a informao do esforo, o gerente do projeto pode
estimar o prazo requerido para o atendimento e os custos correspondentes.
Exemplo:
Supondo uma modificao de 20% em relao ao projeto original do software;
sendo que 30% do cdigo dever ser alterado e; 30% o esforo requerido
para integrar as adaptaes ao software e testar a nova release. O software a
ser adaptado tem 20 KDSI e de modo orgnico.
 (1) Clculo do AAF
0.40 (20) + 0.30 (30) + 0.30 ( 30) = 26

(2) Clculo do EDSI

20000 x ( 26 100) = 5200 ou 5,2 KDSI

(3) Clculo do esforo

1,05
Esforo = 2,4 (5,2) = 13,55 H/M

Estimativa do Prazo da Manuteno Adaptativa

Objetivo: Determinar o prazo necessrio para o atendimento manuteno

adaptativa.
Mtodo de Determinao: Utiliza-se a equao do COCOMO para estimar o
prazo.
Fontes de Informaes: Estimativa de esforo.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Utilizar a informao para calcular o oramento do
atendimento.
Exemplo:
Supondo o esforo estimado do exemplo anterior, teramos o prazo:
0,38
Prazo = 2.5 ( 13,55) = 6,73 meses

Estimativa do Nmero de Profissionais Necessrios

Objetivo: Determinar o nmero de profissionais a serem alocados para o

atendimento manuteno adaptativa.
Mtodo de Determinao: O nmero de profissionais definido dividindo-se o
esforo pelo prazo estimado.
Fontes de Informao: Estimativas de esforo e prazo.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Definir os recursos humanos e perfis necessrios e aloc-los
ao atendimento.
Exemplo:
Conforme as estimativas de esforo e prazo, o nmero de profissionais
necessrios para o atendimento seria de 2.01 ou 2.

Equao de esforo do COCOMO, modo Bsico.

Estimativa do Custo Manuteno Adaptativa

Objetivo: Determinar o oramento do atendimento solicitao de manuteno

adaptativa.
Mtodo de Determinao: O custo calculado multiplicando-se o custo mdio
do homem/ms pelo esforo estimado.
Fontes de Informaes: Estimativa de esforo.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Negociar oramento com cliente/usurio e alocar a verba
necessria.
Exemplo:
Supondo um custo mdio de homem/ms a $ 3000, teramos para um esforo
de 6,73 H/M, um custo de $ 20.190 relativo ao atendimento.

Estimativa do Nmero de Defeitos

A determinao do nmero de defeitos segue o mesmo raciocnio que o

utilizado para o planejamento anual do atendimento. A diferena que
devemos multiplicar a densidade atual de defeitos do software, em 1000 linhas
de instrues fontes, pelo EDSI ( nmero equivalente de instrues fontes).

Por exemplo, se a densidade atual de 12 por 1000 e tivermos 5200 EDSI, o

nmero de defeitos esperados seria de aproximadamente 62.

Estimativa de Esforo de Retrabalho da Manuteno Adaptativa

Aqui o raciocnio o mesmo dos exemplos anteriores relativos s estimativas

de esforo de retrabalho, ou seja, esforo de retrabalho funo do tamanho
da adaptao medida em EDSI e com possibilidade de ser transformada em
pontos de funo.

Por exemplo, 5200 EDSI em COBOL significam aproximadamente cerca de 57

pontos de funo ( 91 linhas de instruo fonte representa 1 ponto de funo).

Podemos portanto, utilizar a equao de regresso linear. Seria importante

manter dados acerca do esforo mdio de retrabalho correspondente
adaptao de 1 ponto de funo.

Estimativa do Custo do Retrabalho da Manuteno Adaptativa

O custo do retrabalho o esforo multiplicado pelo custo mdio do homem/ms

ou do homem/hora. A forma de determinao anloga aos exemplos
anteriores para clculo do custo de retrabalho.

bom recordar que este custo crtico para o controle dos custos da m
qualidade durante a manuteno/evoluo do produto.
 Planejamento de Projetos de Melhoria

O planejamento de projetos de melhoria contempla os mesmos elementos de

estimativas realizados quando da ocasio do planejamento do projeto, ou seja, o
tamanho do projeto de melhoria, o prazo , esforo, nmero de profissionais
necessrios,custo , defeitos esperados, esforo e custo de retrabalho.

Estimativa do Tamanho do Projeto de Melhoria

Objetivo: Determinar o tamanho do projeto de melhoria em termos de pontos

de funo.
Mtodo de Determinao: A caracterstica do projeto de melhoria a adio,
remoo e/ou alterao de funes. Para tanto, utiliza-se da contagem dos
pontos de funo para projetos de melhoria ( enhancement project), tal como
definido no Couting Practice Manual do IFPUG 3.

A determinao dos pontos de funo para projetos de melhoria dada pela

frmula:

EFP = ( ADD + CHGA + CFP ) x VAFA + ( DEL x VAFB)

onde:
EFP a contagem de pontos de funo do projeto
ADD funes no ajustadas includas no software
CHGA funes no ajustadas modificadas no software
CFP funes adicionadas como converso (se houver)
VAFA o fator de ajustamento do projeto de melhoria aps o
trmino do projeto
DEL funes no ajustadas deletadas do software
VAFB o fator de ajustamento do projeto de melhoria antes do
seu incio
Para estimativa considera-se VAFA = VAFB.
A determinao da complexidade das funes e dos pontos de funo seguem
os mesmos procedimentos aplicados pela metodologia#1
Nota: o modelo de ajustamento do COCOMO tambm pode ser utilizado
para projetos de melhoria.

Fontes de Informaes: Anlise de impacto do projeto de melhoria.

Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Com a estimativa do tamanho, as demais estimativas podem
ser realizadas.
Exemplo:
Supondo a adio de 20 PFs, 10 PFs modificados, nenhuma funo
convertida, uma fator de ajustamento de 1.05 e 5 PFs deletados:

EFP = ( 20 + 10 + 0 ) x 1.05 + ( 5 x 1.05) = 36,75

 Estimativa de Esforo do Projeto de Melhoria

Emprega-se o mesmo raciocnio utilizado para a estimativa do esforo do

projeto de software .

Uma alternativa a converso dos pontos de funo em nmero de linhas de

instrues fontes e aplicar os algoritmos do mtodo COCOMO.

Demais Estimativas

As estimativas restantes de prazo, custo, nmero de profissionais necessrios,

defeitos esperados, esforo e custo de retrabalho seguem os procedimentos j
discutidos para o planejamento de projetos ( captulo 6) e para o planejamento
anual de atendimento.

8.2.3 - Medies Para o Monitoramento do Atendimento

O objetivo dessas medies prover informaes para a gesto do

atendimento, considerando o conjunto de manutenes corretivas, adaptativas e
projetos de melhoria. O atendimento normalmente considerado no jargo da rea de
informtica como backlog .

Essas medies concentram-se em:

Monitoramento do atendimento s solicitaes de manutenes

corretivas e pequenas manutenes adaptativas
Monitoramento das manutenes adaptativas de porte significativo e dos
projetos de melhoria

Medies Para o Monitoramento do Atendimento s Manutenes

Corretivas

Monitoramento do Backlog

Objetivo: Avaliar o volume de solicitaes recebidas e fechadas durante o ms.

Mtodo de Determinao: Demonstrar graficamente o atendimento ao
backlog do software ao longo do tempo.
Fontes de Informaes: Registros de solicitaes recebidas e registros de
solicitaes fechadas.
Forma de Apresentao: grfica.
Ao Gerencial: Esta medio permite ao gerente visualizar o nvel de
atendimento ao produto, comparando-a com a demanda de servios requerida
pelos clientes/usurios. Permite obter indcios de problemas em determinados
mdulos do software, verifificar fatores cclicos, e pistas sobre a origem das
solicitaes.
Exemplo:
Nmero de Solicitaes

100

80

40

20

1 2 3 4 5 6 7 8 9 meses
Figura 8-5
Legenda:
Solicitaes Recebidas

Solicitaes Fechadas

Backlog Acumulado

Tempo Mdio de Atendimento das Solicitaes

Objetivo: Determinar o tempo mdio do atendimento s solicitaes de

manutenes ao longo do tempo.
Mtodo de Determinao: A determinao do tempo mdio mensal de
atendimento dada pela expresso:

TMA = TASL NSLM

onde:
TASL Tempo de atendimento de cada solicitao abertas no
ms
NSLM Nmero de solicitaes fechadas no ms

Fontes de Informaes: Registros de atendimento de solicitaes

Forma de Apresentao: grfica.
Ao Gerencial: Estabelecer o padro de tempo do atendimento para as
solicitaes.
Exemplo:

Tempo em Dias
20

15

10

0
1 2 3 4 5 6 meses
 Figura 8-6

Tempo Mdio do Backlog Em Aberto

Objetivo: Determinar o tempo mdio de permanncia das solicitaes no

backlog.
Mtodo de Determinao: A determinao do tempo mdio de permanncia
dada pela expresso:

TMB = TPSLA NSLA

onde:
TPSLA Tempo de permanncia da solicitao no backlog
NSLA Nmero de solicitaes em aberto no perodo
Esta mdia cumulativa.

Fontes de Informaes: Registros do atendimento s solicitaes.

Forma de Apresentao: grfica.
Ao Gerencial: O objetivo diminuir ao mximo o tempo de pemanncia pelo
aumento da produtividade do atendimento ou pela eliminao das causas das
solicitaes.
Exemplo:

Nmero de dias
50

40

30

20

10

0
1 2 3 4 5 6 meses
Figura 8-7

Origem das Solicitaes

Objetivo: Identificao da origem das solicitaes de atendimento em relao

aos clientes/usurios do software.
Mtodo de Determinao: Registrar as frequncias das solicitaes por
origem ao longo do tempo. As frequncias podem ser plotadas de forma
cumulativa at o ponto no tempo que se deseja medir ou serem plotadas
mensalmente, a fim de permitir a visualizao de tendncias.
Fontes de Informaes: Registros de atendimento.
Forma de Apresentao: grfica.
Ao Gerencial: A identificao dos clientes/usurios que mais solicitam
servios de manuteno pode indicar potenciais problemas do no atendimento
do software s necessidades dos mesmos; neste caso o gerente dever
determinar as causas e desenvolver e implementar contra-medidas para
elimin-las.
Exemplo:
% Nmero de Solicitaes

50

40

30

20

10

Market. Prod. Financ.

Figura 8-8

Neste exemplo , para um tempo T qualquer , a maior frequncia tem sido da

rea de marketing da empresa. Portanto deveriam ser analisadas as causas.

Frequncia do Tipo de Solicitao

Objetivo: Analisar a frequncia das solicitaes conforme o tipo, se corretiva ou

adaptativa.
Mtodo de Determinao: Registrar a frequncia das solicitaes por tipo ao
longo do tempo. As frequncias podem ser plotadas de forma cumulativa at o
ponto no tempo que se deseja medir, ou serem plotadas mensalmente, a fim de
permitir a visualizao de tendncias.
Fontes de Infomaes: Registros de atendimento.
Forma de Apresentao: grfica.
Ao Gerencial: A identificao dos tipos de solicitaes pode indicar
problemas potenciais no software no que tange a mdulos com erros crnicos
ou aqueles que so mais suscetveis adaptaes.
Exemplo:
Similar ao exemplo anterior em termos de representao grfica.

Frequncia de Solicitaes Por Mdulo do Software

Objetivo: Determinar os mdulos com indcios de serem mdulos com erros

crnicos ou aqueles mais suscetveis adaptaes frequentes.
Mtodo de Determinao: Registrar a frequncia das solicitaes por mdulo
do software, separando em corretivas e adaptativas. Considerar a frequncia
cumulativa at oponto no tempo que se deseja avaliar.
Fontes de Informaes: Registros de atendimento.
Forma de Apresentao: grfica.
Ao Gerencial: Caso for identificada uma incidncia significante de
solicitaes que afetam um ou mais mdulos do software, o gerente dever
tomar deciso quanto a refazer o mdulo para eliminar defeitos ou falhas ou
adequ-lo s necessidades dos clientes/usurios.
Exemplo:
% Solicitaes Por Mdulo/Manutenes Corretivas

100

80

60

40

20

A B C D Mdulos
Figura 8-9

Neste exemplo os mdulos A e B representam 60% de todas as solicitaes de

manutenes corretivas e so, portanto, candidatos a uma anlise mais
profunda.

A mesma representao pode ser feita para as manutenes adaptativas.

Produtividade da Manuteno Corretiva/Adaptativa

Objetivo: Determinar a produtividade das manutenes corretivas e

adaptativas de pequeno porte.
Mtodo de Determinao: A produtividade para manutenes corretivas, j
que as mesmas so de difcil dimensionamento atravs da tcnica de Pontos de
Funo, pode ser expressa em Linhas de Instrues Fontes por
homem/hora.Deve-se considerar as linhas que compem a parte do software a
ser corrigida. apropriado verificar a produtividade mdia ao longo do tempo.
Uma possibilidade transformar as linhas de instrues fontes em pontos de
funo conforme a tabela de transformao apresentada no captulo 6.
Fontes de Informao: Registros de atendimento.
Forma de Apresentao: grfica.
Ao Gerencial: Avaliar a produtividade ao longo do tempo e contrapor com os
padres da produtividade para este tipo de atendimento e verificar causas das
variaes.
Exemplo:
Produtividade Mdia em Instrues Fontes por Homem/Hora

50

40

30

20

10

1 2 3 4 5 6 meses
Figura 8-10
 Monitoramento das Manutenes Adaptativas de Porte e de
Projetos de Melhoria

As medies relativas a estes tipos de atendimento so anlogas s

empregadas para o processo de desenvolvimento de software, ou seja:

Gesto da Qualidade

Progresso na remoo de defeitos

Defeitos restantes

Desvio da estimativa de defeitos

Composio dos tipos de defeitos

Composio das classes de defeito

Densidade de defeitos da inspeo

Eficincia da Remoo de Defeitos do Processo de Inspeo

Taxa de exame por inspees

Taxa de preparao por inspeo

Tamanho do material inspecionado por inspees

Complexidade dos Mdulos

Objetivos de intensidade de falhas

Monitoramento do Progresso

Progresso na elaborao de produtos

Acompanhamento fsico

Gesto de Recursos e Financeira

Estimativa atualizada do tamanho do software

Estimativa atualizada de prazo

Estimativa atualizada de esforo

Estimativa atualizada de alocao de recursos

Acompanhamento financeiro do projeto

Estimativa atualizada do custo do projeto

 Comportamento do custo do retrabalho

Gesto de Mudanas

Monitoramento de mudanas nos requisitos

Origens dos incrementos/mudanas

8.2.4 - Medies Para o Monitoramento da Evoluo do Produto

As medies para o monitoramento do projeto concentram-se na avaliao

contnua da melhoria da qualidade, da produtividade e dos aspectos de custo
do produto ao longo de sua vida til. As informaes so coletadas durante o
atendimento s solicitaes.

A gesto da qualidade do produto tem como referencial as medies acerca da

densidade de defeitos , intensidade de falhas e ndice de manuteno, todas
vistas ao longo da vida til do software. O objetivo neste caso o de
aperfeioar constantemente a qualidade do produto.

A gesto da qualidade est relacionada produtividade e ao comportamento

dos custos. A inteno que a relao qualidade produtividade custos
seja validada.

Dessa forma, a produtividade tambm deve ser monitorada e o reflexo sobre os

custos analisado.

As anlises desses fatores devem realimentar a execuo do atendimento,

objetivando aumentar a satisfao dos clientes/usurios conforme custos
econmicos da qualidade.

Gesto da Qualidade do Produto

Monitoramento da Densidade de Defeitos do Produto

Objetivo: Verificar o estgio atual da qualidade do produto, bem como inferir

tendncias acerca da densidade de defeitos.
Mtodo de Determinao: O tratamento da densidade de defeitos do produto
ao longo do tempo deve considerar cada release do software, seja ela motivada
por manutenes adaptativas ou projetos de melhoria. Dessa forma, ao final de
cada manuteno adaptativa ou projeto de melhoria, deve-se determinar a
densidade de defeitos da release. A densidade de defeitos deve ser plotada
contra as releases, evidenciando progresso ou no da qualidade, bem como
indicando o padro da densidade. Para fins de controle podemos utilizar
tambm a ferramenta - grfico de controle estatstico, confrontando as
densidades de defeitos de cada release com os limites de controle da
densidade mdia relativa a todos os produtos da instalao. A densidade de
defeitos deve ser estabelecida por 1000 linhas de insrues fontes ou por
pontos de funo.
Fontes de Informao: Registros de densidade de defeitos coletados ao
trmino das manutenes adaptativas e projetos de melhoria.
Forma de Apresentao: grfica.
Ao Gerencial: A ao gerencial requerida para produtos com densidade de
defeitos fora dos limites de controle a avaliao dos fatores possveis de
causa para a variao, que podem ser equipamentos/ambiente operacional,
mtodos empregados, perfil da equipe tcnica e de usurios e assim por
diante.Caso a gerncia j tenha implementado novas tcnicas para a melhoria
da qualidade e as mesmas no surtiram efeito, o que evidenciado por
releases com alta densidade de defeitos, deve-se realizar nova anlise das
causas, ou seja, girar o ciclo PDCA de Deming.
Exemplo:

Densidade de Defeitos
Por 1000 Linhas

50

40

30

20

10

1 2 3 4 5 6
Releases
Figura 8-11

Neste exemplo a densidade de defeitos sofre queda da release 1 para a 3, tem

uma subida substancial da release 3 para a 4 e cai novamente, estabilizando-se
na release 6, o que significa que os mtodos de controle da qualidade surtiram
efeito positivo.

O grfico de controle pode ser empregado para produtos que j estejam

relativamente maduros, ou seja, a partir de uma determinada release, as
demais podem ser plotadas no grfico.

Monitoramento da Intensidade de Falhas do Produto

Objetivo: Verificar o nvel de intensidade de falhas do produto ao longo do

tempo.
Mtodo de Determinao: A intensidade de falhas do produto tambm pode
ser monitorada da mesma forma como a densidade de defeitos. Ao trmino de
cada manuteno adaptativa e projetos de melhoria a intensidade deve ser
calculada e plotada graficamente para demonstrar o comportamento do produto
quanto a este fator. Aqui tambm o grfico de controle pode ser til.
Fontes de Informaes: Clculo da intensidade de falhas ao final de cada
release.
Forma de Apresentao: grfica.
Ao Gerencial: A ao gerencial requerida para produtos com intensidade de
falhas fora dos limites de controle a avaliao dos fatores possveis de causa
para a variao, que podem ser equipamentos/ambiente operacional, mtodos
empregados, perfil da equipe tcnica, estado do cdigo e assim por
diante.Caso a gerncia j tenha implementado novas tcnicas para a melhoria
da qualidade e as mesmas no surtiram efeito, o que evidenciado por
releases com alta intensidade de falhas, deve-se realizar nova anlise das
causas, ou seja, girar o ciclo PDCA de Deming.
Exemplo:
Similar ao exemplo apresentado para densidade de defeitos.

ndice de Manuteno do Produto

Objetivo: Identificar o impacto das manutenes adaptativas e projetos de

melhoria sobre os mdulos do software em termos da propagao e
abrangncia, bem como as frequncias de manuteno por mdulo.
Mtodo de Determinao: A partir dos registros de solicitaes e atendimento,
identificar o manuseio de mdulos por manuteno ou projeto de melhoria,
assim como a frequncia das manutenes por mdulo do software. Considerar
esta anlise ao longo do tempo. A anlise pode considerar as manutenes
isoladamente ou no conceito de release.
Fontes de Informaes: Registros de atendimento s solicitaes.
Forma de Apresentao: grfica.
Ao Gerencial : A anlise do ndice de manuteno do produto e seu impacto
subsidia decises quanto a refazer um ou vrios mdulos do produto ou at
mesmo decidir sobre o seu descarte ou substituio.
Exemplo:

Mdulos Manuseados Por Release

50

40

30

20

10

1 2 3 4 5 6
Releases
Figura 8-12

Neste exemplo, h um crescimento significativo no nmero de mdulos

manuseados, na medida em que novas releases do produto vo sendo
liberadas. Isto pode significar um produto altamente instvel e que necessita
sofrer uma reviso profunda. Produtos instveis possuem alta densidade de
defeitos.

Para representar a incidncia de manutenes por mdulos do produto, pode-

se empregar a mesma representao grfica mostrada no exemplo da medio
- Frequncia de Solicitaes Por Mdulos do Software.
 Medies Relativas Produtividade e aos Custos

Produtividade de Manutenes Adaptativas e Projetos de Melhoria

Objetivo: Determinar a produtividade das manutenes adaptativas e projetos

de melhoria e analisar tendncias.
Mtodo de Determinao: A produtividade determinada pela relao do
nmero de pontos de funo mantidos ( na adaptao ) ou incrementados pelo
projeto de melhoria sobre o esforo correspondente, registrado quando do
trmino do atendimento. A produtividade pode ser comparada com os padres
da instalao ou entre releases.
Fontes de Informao: Registros de esforo e do tamanho do software aps o
atendimento.
Forma de Apresentao: grfica.
Ao Gerencial: Identificar as causas de baixa produtividade. Realizar
experimentos com utilizao de novas tcnicas de manuteno.
Exemplo:

Produtividade da Manuteno
Projetos de Melhoria

50

40

30

20

10

1 2 3 4 5
Releases
Figura 8-13

Custos do Ponto de Funo de Manuteno Adaptativa e Projetos de

Melhoria

Objetivo: Determinar o custo do ponto de funo de manutenes adaptativas

e projetos de melhoria.
Mtodo de Determinao: O custo do ponto de funo determinado atravs
da diviso do custo da manuteno ou do projeto de melhoria pelo nmero de
pontos de funo ajustados. O custo pode ser representado por perodo de
tempo para cada tipo de atendimento e por release.
Fontes de Informaes: Registros de custos da manuteno ou projeto de
melhoria e o clculo dos pontos de funo relativos manuteno ou projeto de
melhoria.
Forma de Apresentao: grfica.
Ao Gerencial: Verificar causas de aumento do custo do ponto de funo.
Exemplo:
 Custo do Ponto de Funo

300

200

100

50

1 2 3 4 5 6 meses
Figura 8-14
Legenda:
Custo do PF Manutenes
Adaptativas

Custo do PF de Projeto de
Melhoria
A representao desta medio pode ser feita considerando-se releases. Neste
caso deve-se diferenciar o tipo de release ( oriunda de adaptaes ou de
projetos de melhoria).

8.3 - Medies Para o Aperfeioamento dos Processos de Planejamento de

Projetos,de Desenvolvimento de Software e de Gesto de Produtos

As medies realizadas para o monitoramento do produto, bem como as que

devem ser feitas ao final de cada atendimento, formam o conjunto de
informaes que vo apoiar o aperfeioamento do processo de planejamento de
projetos, do processo de desenvolvimento de software e do prprio processo de
gesto do produto. Essas medies tambm devem compor o banco de dados
de mtricas de forma que os padres da instalao sejam estabelecidos.

Essas medies compreendem:

Eficincia da Remoo de Defeitos

Verificao da Exatido das Estimativas
Tamanho Atual do Software
Crescimento Funcional Relativo do Software
Crescimento Funcional Mdio do Software
Complexidade Atual do Software
Custo da Qualidade
ndice de Tecnologia de Manuteno/Melhoria Empregado
ndice de Tecnologia de Gesto Empregado
Demais Medies Qualitativas

A seguir detalharemos cada uma dessas medies.

Eficincia da Remoo de Defeitos do Processo

Objetivo: Determinar a eficincia da remoo de defeitos do processo de

desenvolvimento.
Mtodo de Determinao: A eficincia da remoo de defeitos dada pela
expresso:

DPR ( DPR + DPO )

onde:
DPR Defeitos Pr-Release identificados durante o
desenvolvimento
DPO Defeitos Ps-Release identificados durante a operao do
software at um perodo de tempo determinado
O tempo de operao do software, para fins de registro dos defeitos ps-release,
vai depender do tempo necessrio para que todas as suas funes sejam
utilizadas pelos clientes/usurios.
Fontes de Informao: Processo de inspeo durante o desenvolvimento e
registros de solicitaes de manutenes corretivas.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo que foram identificados 700 defeitos pr-release e 400 ps-release; a
eficincia seria de 64%, ou seja, o processo de desenvolvimento do software
especfico conseguiu identificar e remover cerca de 64% dos defeitos
introduzidos no software.

Este valor hipottico poderia ser comparado com o padro da eficincia da

remoo de defeitos da instalao, que a mdia das eficincias de todos os
projetos que foram desenvolvidos para a mesma plataforma de
hardware/software e utilizando a mesma metodologia de desenvolvimento.

Verificao da Exatido das Estimativas

Essas medies tm a finalidade de verificar a variao das estimativas

realizadas pelo planejamento de atendimento anual e pelo planejamento de
atendimento especfico.

Os algoritmos genricos para determinao da exatido da estimativa so dados

pelas expresses:
No caso da estimativa for menor que o realizado:

ExE = ( E/R) x 100

No caso da estimativa for maior que o realizado

ExE = 1 - ( E/R ) -1 x 100

onde:
ExE Exatido da estimativa
E Valor do item estimado
R Valor obtido do item ao final do processo

Este algoritmo o mesmo explicitado para as medies de exatido das

estimativas apresentadas no item 7.3.4.
A seguir so listadas as medies possveis de serem realizadas quanto a este
tpico.

Exatido da Estimativa de Esforo Anual de Atendimento Exatido da

Estimativa do Nmero de Profissionais Para o Atendimento Anual
Exatido da Estimativa do Custo Anual de Atendimento
Exatido da Estimativa de Defeitos Esperados do Atendimento Anual
Exatido da Estimativa do Esforo de Retrabalho do Atendimento Anual
Exatido da Estimativa do Custo de Retrabalho do Atendimento Anual
Exatido da Estimativa do Esforo da Manuteno Adaptativa
Exatido da Estimativa do Prazo da Manuteno Adaptativa
Exatido da Estimativa do Nmero de Profissionais Necessrios Para a
Manuteno Adaptativa
Exatido da Estimativa do Custo da Manuteno Adaptativa
Exatido da Estimativa do Nmero de Defeitos da Manuteno
Adaptativa
Exatido da Estimativa do Esforo do Retrabalho da Manuteno
Adaptativa
Exatido da Estimativa do Custo de Retrabalho da Manuteno
Adaptativa
Exatido da Estimativa do Tamanho da Manuteno Adaptativa
Exatido da Estimativa do Tamanho do Projeto de Melhoria
Exatido da Estimativa do Esforo do Projeto de Melhoria
Exatido da Estimativa do Prazo do Projeto de Melhoria
Exatido da Estimativa do Nmero de Profissionais Necessrios Para o
Projeto de Melhoria
Exatido da Estimativa do Custo do Projeto de Melhoria
Exatido da Estimativa do Nmero de Defeitos do Projeto de Melhoria
Exatido da Estimativa do Esforo do Retrabalho do Projeto de Melhoria

Exatido da Estimativa do Custo de Retrabalho do Projeto de Melhoria

Tamanho Atual do Software

Durante os projetos de manuteno adaptativa e de projetos de melhoria o

tamanho do software pode ter alterado, em termos de incluso de funes,
substituio de funes, remoo de funes e alterao de funes.

Quando houver estes eventos pode-se utilizar a a metodologia #1 preconizada

pelo IFPUG para fins de contagem do tamanho atual do software.

No caso de somente haver incluso de funes, pode-se calcular o tamanho do

ponto de funo pelo uso da expresso:

( FPRA + FPAD ) x NFA = TAS

onde:

FPRA Tamanho em pontos de funo da release anterior

FPAD Tamanho do projeto de melhoria em pontos de funo
NFA Fator de ajustamento da nova release
Crescimento Funcional Relativo do Software

Objetivo: Determinar o crescimento funcional relativo do software em funo de

manutenes adaptativas e projetos de melhoria.
Mtodo de Determinao: A determinao do crescimento funcional relativo do
software dada por:

CRTS = ( IPFMP FPRA ) x 100

onde:
IPFMP Incremento do software em pontos de funo a partir
da manuteno adaptativa ou do projeto de melhoria
FPRA Tamanho em pontos de funo da release anterior
Fontes de Informao: Contagem do tamanho atual do software e tamanho da
release anterior.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo que foram adicionados 100 pontos de funo a partir de uma
manuteno adaptativa ou projeto de melhoria em uma release de tamanho
1200, o crescimento funcional relativo seria de 8,33%.

Crescimento Funcional Mdio do Software

Objetivo: Determinar o crescimento funcional mdio do software ao longo do

tempo.
Mtodo de Determinao: O CFM determinado pela expresso:

CFM = CRFA n
onde:
CRFA Crescimento funcional anual
n nmero de anos do atendimento
sendo que:
CFRA determinado pelo crescimento funcional do software ao longo
de um ano.
Fontes de Informao: Contagem dos pontos de funo das releases.
Forma de Apresentao: nenhuma especfica.
Exemplo:
Supondo que num perodo de 4 anos foram observados CRFAs respectivos de
20%, 30% 40% e 20%. O CFM seria portanto de 27,5 %.

Complexidade Atual do Software

Para a determinao da complexidade atual do software, pode-se utilizar o

modelo preconizado por Card & Glass 2.

A complexidade dever ser recalculada em razo das alteraes de

complexidades dos mdulos manutenidos e/ou em razo de novos mdulos
adicionados.

Para fonte de referncia quando do clculo da complexidade atual, importante

a manuteno do Diagrama Hierrquico do Sistema (DHS) atualizado.
Custo da Qualidade

A frmula do clculo do custo da qualidade anloga apresentada para a

determinao do custo da qualidade de projetos de software, conforme o captulo
7.

O custo da qualidade pode ser calculado para cada atendimento , principalmente

no tocante manuteno adaptativa e projetos de melhoria.

O somatrio do custo da qualidade de cada atendimento, considerando o perodo

de um ano, nos fornece o custo da qualidade do atendimento anual ao produto.

Este custo pode ser comparado com o custo do atendimento, para verificar a
relao entre ambos.

O objetivo que os custos de falhas internas ( retrabalho) sejam minimizados.

ndice de Tecnologia de Manuteno/Melhoria Empregado

Igualmente ao ndice de tecnologia de desenvolvimento, este ndice tambm tem

por objetivo determinar o nvel de sofisticao da tecnologia aplicada durante o
atendimento (manuteno adaptativa ou projeto de melhoria).

Entretanto h algumas diferenas entre a medio para manuteno adaptativa e

projetos de melhoria.

Para projetos de melhoria devemos utilizar os mesmos componentes que o

ndice de tecnologia de desenvolvimento. Portanto o instrumento de medio o
mesmo.

O mtodo de determinao tambm baseia-se no somatrio de pesos

multiplicados por notas e dividido pelo somatrio dos pesos, isto , uma mdia
ponderada.

A seguir apresentaremos o instrumento de medio para manutenes

adaptativas.

Ambiente da Manuteno ( peso 5)

a) No h apoio eletrnico para elaborao dos documentos do projeto; no h

biblioteca tcnica disponvel para as equipes de projeto; sem automao do
controle de verses dos componentes do software; um terminal ou micro para
cada quatro analistas/programadores; ferramentas mnimas de depurao; as
equipes de projetos no possuem rea reservada; no existe reas para
armazenagem de materiais, listagens; no existem salas de reunio disponveis
para revises tcnicas e no h monitoramento de defeitos. ( Nota 1 )
b) Algum suporte de edio de textos para a documentao de projetos;
pequena e escassa biblioteca tcnica; controle das verses para o cdigo-fonte;
a documentao controlada manualmente; um terminal/micro para cada
analista/programador; algumas ferramentas de depurao; escritrios
compartilhados por trs ou quatro analistas/programadores; uma ou duas salas
de reunio; sistema manual de registro de erros. ( Nota 3 )
c) Apoio informatizado para a documentao do projeto; boa biblioteca tcnica
a disposio para as equipes de projetos; controle de verses de componentes
de software automatizado; um terminal/micro para cada analista/programdor,
com terminais extras como backup; ferramentas de depurao; bibliotecas de
testes; espao adequado aos analistas/programadores com reas de
armazenagem adequadas; salas de reunio adequadas. ( Nota 5 )

Utilizao de Ferramentas de Apoio Manuteno ( peso 5)

Verificador de sintaxe
Depurador interativo
Prototipador
Gerador de telas
Gerador de relatrios
Gerador de grfico
Gerador de cdigo-fonte
Otimizadores
Linguagens com facilidades de depurao
Gerador de dados para teste
Dicionrio de dados
Documentador automtico
Analisador de cdigo
Utilitrios de otimizao de banco de dados
Controle automatizado de verses
Ferramenta de apoio reestruturao do cdigo

0 a 3 itens assinalados nota 1

4 a 6 itens assinalados nota 2
7 a 9 itens assinalados nota 3
10 a 13 itens assinalados nota 4
14 a 16 itens assinalados nota 5

Utilizao de Tcnicas e Mtodos de Remoo de Erros (peso 5)

Reviso dos requisitos

Reviso da alterao na estrutura lgica do sistema
Reviso da alterao no projeto fsico de banco de dados
Reviso dos projetos de rotinas automatizadas
Inspeo e reviso do cdigo
Verificao e validao independente
Teste de exatido de algoritmos
Teste de programas individuais
Teste de unidade de implantao
Teste integrado
Teste de desempenho
 Teste de aceitao
Teste de campo
Organizao de teste independente
Anlise de mdulos com erros crnicos
Investigao da satisfao do usurio

0 a 3 itens assinalados nota 1

4 a 6 itens assinalados nota 2
7 a 9 itens assinalados nota 3
10 a 12 itens assinalados nota 4
13 a 16 itens assinalados nota 5

Reutilizao de Cdigo e Mdulos ( peso 5 )

a) Nenhuma reutilizao ( nota 1 )

b) At 15% de reutilizao ( nota 2 )
c) Entre 16 a 25% de reutilizao (nota 3)
d) Entre 26% a 50% de reutilizao ( nota 4)
e) Acima de 50% ( nota 5)

ndice de Tecnologia de Gesto Empregado

Tanto para as manutenes adaptativas como projetos de melhoria a forma de

medio a mesma que a empregada para projetos de software ( vide captulo
7).

Demais Medies Qualitativas

Essas medies fornecem as pistas necessrias para a identificao das

causas de baixa qualidade e produtividade.

As medies qualitativas, tanto para manutenes adaptativas como para

projetos de melhoria compreendem:

Perfil da equipe tcnica alocada manuteno/projeto de melhoria

Novidades das especificaes da adaptao/projeto de melhoria
Experincia da equipe com o software
Envolvimento dos usurios
Experincia da equipe com mtodos de remoo de erros
Geografia do desenvolvimento
Coeso tcnica apresentada durante o projeto
Estrutura e estado do cdigo base do software
Principais ocorrncias

Perfil da Equipe Tcnica Alocada

Em relao ao ambiente de desenvolvimento/manuteno:

Experincia nas ferramentas de apoio ao desenvolvimento

 Experincia nos mtodos e tcnicas de anlise e projeto
Experincia nas linguagens de programao
Experincia em mtodos e tcnicas de revises e inspees
Experincia em tcnicas de teste de sistemas
Experincia no hardware de desenvolvimento

Estabelecer o percentual, conforme o total dos membros da equipe em termos

de:
Pouca experincia - at 2 itens assinalados :_____%
Mdia exoerincia - 3 e 4 itens assinalados:_____%
Grande experincia - 5 e 6 itens assinalados:_____%

Novidades das Especificaes da Adaptao/Melhoria

a) Nenhuma novidade
b) Pouca novidade
c) Mdia novidade
d) Grande novidade
e) Especificaes totalmente desconhecidas pela equipe

Experincia da Equipe Com o Software

a) Nenhuma experincia
b) Pouca experincia
c) Mdia experincia
d) Grande experincia
e) Domnio da rea de aplicao

Envolvimento dos Usurios

a) Nenhum envolvimento
b) Pouco envolvimento
c) Mdio envolvimento
d) Grande envolvimento
e) Total participao, inclusive com usurios alocados full-time ao projeto

Experincia da Equipe Com Mtodos de Remoo de Erros

a) Nenhuma experincia
b) Pouca experincia
c) Mdia experincia
d) Grande experincia
e) Domnio completo

Geografia do Desenvolvimento

a) Projeto foi desenvolvido em um nico local

b) Projeto foi desenvolvido em mais de um local na mesma cidade
c) Projeto foi desenvolvido com participao de vrias fornecedores numa
mesma cidade
 d) Projeto foi desenvolvido por equipes distribudas em diversas cidades
e) Projeto foi desenvolvido com participao de equipes distribudas em
diversos pases

Coeso Tcnica Apresentada Durante o Projeto

a) Nenhuma coeso tcnica entre os membros

b) Pouca coeso tcnica
c) Mdia coeso tcnica
d) Grande coeso tcnica
e) Coeso tcnica total

Origem do Cdigo Base

Desenvolvido internamente na empresa

Desenvolvido em outro local da empresa
Desenvolvido sob encomenda por contrato
Adquirido de terceiros
Cdigo base veio de vrias fontes

Idade do Cdigo Base

Menos de um ano
Entre um e dois anos
Entre dois e quatro anos
Entre quatro e seis anos
Acima de seis anos

Estado do Cdigo Base

Estabilizado
Estabilizando-se
Instvel
Propenso a erros
Extremamente instvel

Ocorrncias

Aqui tambm sugerimos o registro das ocorrncias principais relativas

manuteno adaptativa e projetos de melhoria, as quais fornecem informaes
qualitativas para avaliar os resultados do atendimento.

Este captulo culmina a apresentao das medies operacionais do

software , conforme classificao discutida no captulo 4.

Os itens de 8 a 10 foram adaptados de Capers Jones 4

 O prximo captulo apresenta o tratamento dado s medies operacionais,
cuja transformao vo determinar as medies para o gerenciamento do
ambiente de software como um todo.

REFERNCIAS

1. BOEHM, Barry. Software Engineering Economics.Prentice-Hall, Englewood

Cliffs,New Jersey,1981.

2. CARD,D.N. & GLASS, P.L. Measuring Software Design Quality.Prentice-

Hall,Englewood Cliffs,New Jersey, 1990.

3. IFPUG. Function Point Counting Practice Manual - Release 4.0.

Westerville,Ohio,1994.

4. JONES, Capers. Applied Software Measurement. McGraw-Hill,New York,1991.

5. KAZMIER, L.J. Estatstica Aplicada a Economia e Administrao. McGraw-Hill,So

Paulo, 1982.
Captulo
9
GESTO DO AMBIENTE
DE SOFTWARE

A gesto do ambiente do software consiste na gesto do ponto de vista de um gerente de

desenvolvimento ou um gerente de informtica. No somente est vinculado a um projeto
ou a um produto especfico, mas tambm no conjunto dos projetos e produtos da
instalao como um todo. o nvel ttico de gesto.

Neste nvel a preocupao avaliar a qualidade dos processos de planejamento

de projetos, de desenvolvimento de software e de gesto dos produtos em utilizao,
visando atingir patamares cada vez mais elevados de qualidade sob o conceito de
melhoria contnua.

Para tanto, as medies operacionais devem ser agregadas a fim de permitir: a

anlise de tendncias de determinados indicadores, que pode subsidiar aes para
reverso ou sustentao dessas tendncias; a anlise de impactos da introduo de
novas tecnologias sobre a qualidade e produtividade, que pode auxiliar na deciso sobre
quais combinaes de elementos de tecnologia garantem melhores resultados; a anlise
de atributos, que permite a comparao da qualidade e produtividade entre plataformas,
metodologias, reas de aplicao, habilidades tcnicas de pessoal e assim
sucessivamente.

O tratamento dado para a agregao das medies operacionais tambm tem a

finalidade de criar os padres de medidas de acordo com os trs fatores, ou seja,
plataforma de hardware/software , metodologia de desenvolvimento ( tipo de processo) e
rea de aplicao do software na empresa ( h reas cuja dinmica tornam as solues
informatizadas muito volteis), sujeitas mudanas constantes.

Criando os padres de medidas para a instalao, a gerncia fica em posio de

monitorar o comportamento dos projetos e produtos individualmente, de compar-los e
verificar a adequabilidade dos respectivos processos e necessidades de implementar
melhorias e analisar resultados.

Devemos atentar para o fato de que um dos maiores problemas para a gerncia
do desenvolvimento o controle da alocao de pessoal entre os diversos projetos e
servios. Se faz imprescindvel, para organizaes de porte mdio e grande, uma
sistemtica de controle de alocao. Este controle dever permitir saber quem est
alocado em que, por quanto tempo, quem j est comprometido com projetos ou servios
planejados para comear e quais as folgas ( intervalos de datas) disponveis relativas a
cada recurso humano.

Nossa experincia tem demonstrado que cerca de 50% ( ou mais) do tempo

produtivo de um gerente de desenvolvimento despendido cuidando de assuntos
relativos a pessoal e sua alocao, incluindo questes burocrticas.
 A essncia da gesto do ambiente de software mostrada pela Figura abaixo.

GESTO OPERACIONAL

Planejamento Desenvolvimento Gesto do

de Projetos do Software Produto

Estmulos Externos
Monitora

Gere Demanda de
Recursos Servios

Analisa
Tendncias Analisa Ca-
pacidade
Consolida
Medies
Analisa
Operacionais
Impactos

Deciso/ Analisa
Ao Atributos
Cria os
Padres
Modelagem
Ambiente
GESTO DO AMBIENTE

Figura 9-1

Atravs de estmulos externos, oriundos de vrias reas da organizao, as

demandas por servios so geradas no que diz respeito a novos projetos de software,
manutenes corretivas, manutenes adaptativas e projetos de melhoria.

A primeira providncia analisar a capacidade de atendimento do ambiente de

desenvolvimento a fim de planejar a alocao de recursos, sejam eles internos ou
externos ( empresas terceirizadas).

O controle do progresso dos projetos e servios de manuteno/melhoria e do

planejamento dos projetos e servios que ainda no tiveram o seu incio, juntamente com
o quadro de alocao de recursos atual e previsto, fornecem a base para a anlise de
capacidade.

A anlise de capacidade de atendimento no se limita somente aos aspectos

quantitativos mas tambm aos aspectos qualitativos dos recursos. Na nossa rea,
quantidade no representa condio para aumento da produo. Pode ser at fator de
aumento dos custos, visto a intensa necessidade por treinamento formal e on the job.
 A experincia observada em vrios ambientes de desenvolvimento tem
demonstrado que um tcnico com potencial somente domina uma metodologia de
desenvolvimento aps o terceiro projeto. Conforme for o porte dos projetos isto pode
representar mais de trs anos. Com a cultura gerencial de resultados imediatos instalada
no Brasil, a qualidade dos recursos torna-se mais importante.

O Monitoramento diz respeito verificao do andamento fsico e financeiro dos

projetos , servios e produtos, considerando tambm os aspectos de qualidade dos
mesmos, comparao com os padres da instalao , subsidiando decises e respectivas
aes para correo de rumos. Esta abordagem permite a gesto por exceo.

A Gesto dos Recursos refere-se a alocao e realocao de recursos entre os

projetos e servios, considerando recursos humanos, recursos computacionais,
investimentos em novas tecnologias, metodologias, ambiente fsico de trabalho,
treinamento, organizao dos recursos e etc.

A Anlise de Tendncias realizada a partir da consolidao das medies

operacionais e tenta prever o comportamento futuro de determinados atributos do
ambiente como um todo e de produtos de software especficos.

A Anlise de Impacto realizada para verificar o acerto ( ou no) de decises

quanto introduo de novas tecnologias de desenvolvimento sobre a qualidade, a
produtividade e aspectos financeiros (custos) relativos aos principais processos.

A Anlise de Atributos refere-se a elaborao de comparaes entre

plataformas e tecnologias de desenvolvimento , considerando tambm a qualidade,
produtividade e aspectos financeiros.

Estes componentes do modelo do gesto do ambiente, tomados no conjunto,

fornecem os elementos necessrios para os processos de tomada de deciso que, por
sua vez, produziro aes para o apoio e a correo de rumos da gesto operacional.

Medies Para o Monitoramento do Ambiente

Essas medies concentram-se na verificao dos projetos de software e no

atendimento aos produtos que, em determinado momento, esto fora dos padres em
termos da qualidade , atendimento ao prazo , produtividade e custos.

Verificao de Projetos/Produtos Com Desvio do Padro de Qualidade

Objetivo: Verificar projetos e produtos que apresentam densidade de defeitos fora

dos limites de controle.
Mtodo de Determinao: Comparar a densidade de defeitos dos projetos,
conforme a fase que se encontram, e dos produtos de acordo com as releases,
com os padres respectivos de densidade de defeitos, considerando os atributos
principais de plataforma de hardware/software, metodologia de desenvolvimento e
rea de aplicao do software.
Fontes de Informaes: Processos de inspeo realizados nos projetos e
produtos.
 Forma de Apresentao: grfica ou tabular.
Ao Gerencial: Realizar anlise dos resultados das inspees para verificar
incidncia de tipos de defeitos e identificar causas provveis. Auditar mtodos de
gesto dos projetos e produtos, utilizao da metodologia de desenvolvimento e
qualificao do pessoal alocado.
Exemplo:

Anlise de Projetos - considerando os atributos plataforma,metodologia e rea de

aplicao. Para esta anlise a instalao deveria delimitar os limites de controle
por fase do projeto.
Tabela 9-1 Densidade em 1000 linhas
Projeto Fase Densidade Limites de Variao
At a Fase Controle da Mdia
Projeto A Especificao 70 50 a 20 +133%
Projeto B Especificao 60 50 a 20 +100%
Projeto C Projeto Detalhado 50 40 a 15 +150%
Projeto D Projeto Detalhado 10 40 a 15 -50%

Anlise de Produtos - aqui pode-se delimitar limites de controle de acordo com o

nmero da release.

Tabela 9-2 Densidade em 1000 linhas

Produto Release Densidade Limites de Variao
da Release Controle da Mdia
Produto A 5 20 5 a 12 +150%
Produto B 3 30 8 a 20 +114%
Produto C 2 30 12 a 25 +67%
Produto D 4 25 7 a 14 +108%

Verificao dos Projetos Com Desvio da Estimativa de Prazos

Objetivo: Verificar os projetos que apresentam desvio acentuado da estimativa de

prazo conforme o planejado.
Mtodo de Determinao: Atravs da exatido das estimativas dos prazos das
fases dos projetos e da estimativa atualizada, podemos selecionar aqueles que
apresentaram o desvio mais acentuado e que merecem ateno gerencial.
Fontes de Informaes: Registros de controle do progresso dos projetos ,
medies quanto exatido das estimativas e estimativas atualizadas de prazos.
Forma de Apresentao: grfica ou tabular.
Ao Gerencial: Identificar as causas de atraso e definir, junto com o gerente do
projeto, estratgias alternativas para eliminar o atraso ou diminuir a variao
prevista entre o realizado e o planejado.
Exemplo:
Esta medio tambm pode ser aplicada para manutenes adaptativas e projetos
de melhoria de porte significativo.
Tabela 9-3
Projeto Fase Estimativa do Trmino Variao
do Projeto em Relao

Estimativa
Inicial
Descrio Planej. Realiz. ExE Incial Atual
B Especif. 2 4 50% 10 12 +20%
C Especif. 1 3 33% 7 9 +29%
D Proj.Detal. 3 5 60% 11 13 +18%

Neste exemplo consideramos uma propagao linear do atraso o que nem sempre
ocorre.

Verificao dos Tempos do Atendimento s Manutenes Corretivas

Objetivo: Identificar e analisar o desempenho do atendimento de manutenes

corretivas e adaptativas de pequeno porte em termos da variao em relao aos
limites de controle e mdia dos tempos padres de atendimento.
Mtodo de Determinao: Para cada produto/release ou de forma agregada,
devemos estabelecer os limites de controle em relao aos tempos de
atendimento padres da instalao para manutenes corretivas. A partir dos
registros de atendimento podemos selecionar os casos que sofreram desvios em
relao aos padres.
Fontes de Informaes: Tempos padres e registros do atendimento.
Forma de Apresentao: grfica ou tabular.
Exemplo:
Considerando o tempo de atendimento mdio agregado da instalao para
manutenes corretivas e a medio realizada em um ms especfico.

Tempos Padres
em Dias
30

20 LSC

10

LIF
0

Solicitaes S1 S8 S12 S20 S23 S26

Produtos PA PD PA PC PD PF

Figura 9-2

Neste exemplo, as solicitaes S1,S8,S12,S20,S23 e S26 esto fora dos limites de

controle. Cada uma relativa a um produto especfico.

Verificao dos Desvios de Custos Estimados

 Objetivo: Verificar os projetos e produtos que se encontram com valor ganho
negativo, bem como aqueles cuja estimativa atualizada de custo ultrapassa os
padres de tolerncia.
Mtodo de Determinao: Valor ganho a diferena entre o oramento estimado
e o realizado at um determinado ponto no tempo. Geralmente esta medida deve
ser tratada de forma acumulada at o ponto de medio. Projetos ou produtos com
valor ganho negativo so os que o custo realizado ultrapassou o custo orado e
estimado. Para produtos, entretanto, a avaliao deve ser feita numa base anual.
Fontes de Informaes: Estimativas de custos de projetos e de atendimento
anual ao produto e registros de realizao oramentria respectivos.
Forma de Apresentao: grfica e tabular.
Ao Gerencial: Identificar e analisar as causas do valor ganho negativo,
negociar com clientes/usurios ou a administrao a atualizao dos valores dos
projetos e do oramento de atendimento ao produto.
Exemplo:
Anlise de Valor Ganho de Projeto

1200 Estimativa
1000 Estimativa Atualizada - Custo
Inicial -Custo Total Total

Custo Realizado

Custo Orado

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Semanas

Hoje
Figura 9-3

Anlise de Valor Ganho de Produtos - Considerando um ano especfico

Produto Produto Produto Produto Produto
A B C D E
Legenda:
Orado
Realizado

Figura 9-4

Pode-se utilizar a representao anterior para avaliar o percentual do oramento j

realizado durante o atendimento ao produto.

Medies Para a Gesto dos Recursos

Neste nvel a principal medio a ser realizada sobre a capacidade de

atendimento dado um determinado nvel de demanda por servios.
 Anlise da Capacidade de Atendimento

Objetivo: Verificar a capacidade de atendimento da instalao dado um nvel de

demanda por servios, considerando novos projetos, manutenes
corretivas,adaptativas e projetos de melhoria.
Mtodo de Determinao: A determinao da capacidade, dado um intervalo de
tempo estipulado , dada pela expresso:

CAT = CATI -( CAA + CAC )

onde:
CAT Capacidade de atendimento no perodo de tempo
CATI Capacidade total instalada
CAA Capacidade alocada no perodo
CAC Capacidade comprometida no perodo

A capacidade em homens/hora, de preferncia. Tambm deve-se estratificar a

capacidade em termos de recursos de anlise, programao e assim por diante e
conforme o tipo de alocao, se projetos, manutenes, projetos de melhoria.

Para a determinao da capacidade de atendimento a uma demanda

imprescindvel o controle da alocao dos recursos no mbito da rea de
desenvolvimento.

Para cada servio demandado, deve-se confrontar o esforo estimado para o

mesmo com a CAT prevista para o perodo de tempo correspondente.
Fontes de Informaes: Estimativas de esforo e prazo para cada servio
demandado e registros sobre a alocao de pessoal.
Forma de Apresentao: nenhuma especfica.
Ao Gerencial: Caso a capacidade de atendimento for inferior demanda
existente para um perodo de tempo especfico, o gerente dever negociar com os
clientes/usurios novas datas para incio ou redefinir, junto administrao, as
prioridades ou solicitar autorizao para contratao de terceiros.
Exemplo:
Supondo uma demanda de 300 horas de anlise para um perodo de tempo
especfico, sendo que para este perodo tem-se 2000 horas alocadas a projetos,
1000 horas comprometidas e a capacidade total instalada de 3200.

3200 - ( 2000 + 1000) = 200

Neste caso haveria necessidade por mais 100 homens/hora para atender a
demanda.

Anlise de Tendncias

A anlise de tendncias procura prever o comportamento futuro dos principais

atributos do processo de planejamento de projetos, desenvolvimento de software e gesto
do produto. Os principais so os que se relacionam com o planejamento, a qualidade,
produtividade e custos.
 Os principais atributos so:

Produtividade do desenvolvimento
Produtividade de manutenes adaptativas
Produtividade de projetos de melhoria
Exatido das estimativas
Distribuio do esforo por fase
Distribuio do prazo por fase
Densidade de defeitos
Eficincia da remoo de defeitos
Custo do ponto de funo de desenvolvimento
Custo do ponto de funo de manuteno
Custo do ponto de funo de projetos de melhoria

Na realidade todas as medies podem sofrer uma anlise dessa natureza.

A anlise de tendncia desenvolvida atravs da tcnica estatstica de Anlise

de Sries Temporais.

Esta tcnica permite identificar e segregar fatores relacionados com o tempo e que
influenciam valores observados em uma srie histrica. Estes fatores podem subsidiar a
projeo dos valores da srie temporal.

O mtodo considera quatro fatores que inflenciam o comportamento dos valores

em uma srie temporal, quais sejam:

Tendncia Secular

Refere-se ao movimento de longo prazo nos valores da srie temporal,

considerando um grande perodo de tempo.

Flutuaes Cclicas

So movimentos oscilatrios, para cima ou para baixo, em relao tendncia dos

valores da srie histrica.

Variaes Sazonais

So movimentos oscilatrios que ocorrem dentro de um perodo de tempo e que

se repetem a cada novo ciclo.

Movimentos Irregulares

Vide Kazmier 1 para exemplos de aplicao deste tcnica estatstica de previso.

Variaes nos valores da srie temporal que no podem ser atribudas a eventos
cclicos ou sazonais.

Para aplicao da anlise da tendncia nos atributos acima listados, sugerimos

tratar os fatores de tendncia secular e flutuaes cclicas. Estas podem ser
derivadas de um conjunto de variveis do ambiente de desenvolvimento (
habilidades do pessoal tcnico, metodologia de desenvolvimento, ferramentas de
apoio ao desenvolvimento, caractersticas do projeto, habilidades dos
clientes/usurios) no relacionadas com aspectos sazonais.

Movimentos irregulares podem ser consequncia de rupturas significantes no

mtodo de trabalho e na tecnologia empregada.

No ambiente de desenvolvimento de software, esse tipo de ruptura, ou quebra de

paradigmas, invalida uma srie histrica como base para anlise de tendncias.
Nova srie histrica deve ser construda a partir desta ruptura.

Considerando que no h rupturas e que registramos os valores daqueles

atributos ao longo do tempo, classificando-os por plataforma de desenvolvimento,
metodologia de desenvolvimento e rea de aplicao, podemos aplicar a anlise
de srie temporais.

Anlise da Tendncia da Produtividade do Desenvolvimento

Objetivo: Projetar, para perodos futuros, a tendncia da produtividade do

desenvolvimento de software para uma determinada combinao de
plataforma,metodologia e rea de aplicao.
Mtodo de Determinao: No caso da produtividade devemos considerar valores
mdios observados dentro de um perodo de tempo, preferencialmente
trimestral.Esses valores mdios so determinados a partir da produtividade, em
Pontos de Funo por H/M, calculada para os projetos que tiveram seu trmino
num trimestre qualquer e que compem a srie histrica. A produtividade mdia
obtida pelo somatrio das produtividades individuais de cada projeto dividido pelo
nmero de projetos.

A tendncia determinada pelas expresses:

(1) Y = a + bX
onde:
Y o valor da produtividade esperada no perodo X
a representa a interseco da linha de tendncia com os
valores da srie histrica
b representa a declividade da linha de tendncia
__ 2 _2
(2) b= ( XY - nXY ) ( X - n X )
onde:

X o perodo para o qual se deseja projetar um valor da

srie
Y o valor da srie histrica
 _ _
(3) a = Y - bX

As variaes cclicas da srie histrica so determinadas pela expresso:

( 4 ) 100 x ( VSH VTE )

onde:
VSH valor observado da srie histrica
VTE valor da tendncia para o mesmo perodo de VSH, pela
aplicao da expresso (1)
Esta expresso conhecida como relativos de ciclo, o qual evidencia os picos e
sulvos da componente cclica da srie temporal.
Fontes de Informaes: Srie histrica das produtividades mdias trimestrais dos
projetos de software. Esta srie histrica pode estar armazenada no banco de
dados de mtricas e ser tratada por pacote estatstico.
Forma de Apresentao: grfica.
Ao Gerencial: Caso a tendncia for de diminuio da produtividade, o gerente
deve identificar, analisar e remover as causas da baixa produtividade, visando
reverter a tendncia. A anlise das variaes cclicas pode fornecer subsdios,
embora tardiamente, para determinar fatores que influenciaram positivamente ou
negativamente a produtividade.
Exemplo:
Supondo a seguinte srie histrica sobre produtividade:
Perodo Numerao do Produtividade Y XY 2
Perodo - X X
1/91 0 30 0 0
2/91 1 28 28 1
3/91 2 33 66 4
4/91 3 27 81 9
1/92 4 30 120 16
2/92 5 25 125 25
3/92 6 26 156 36
4/92 7 23 161 49
1/93 8 20 160 64
2/93 9 18 162 81
3/93 10 20 200 100
4/93 11 23 253 121
1/94 12 17 204 144
Tabela 9-5

Aplicando as expresses (2) e (3) , temos para a linha de tendncia, expresso

(1), os seguintes valores:

Y = 31,34 - 1,12 X

Para projetarmos a tendncia para o perodo 2/94 , cujo X 13, obtemos o

seguinte valor:

Y = 31,34 - 1,12 ( 13) = 16,78

A representao grfica para os perodos 13,14 seria:
 Y
33
32
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12

1/91 2/91 3/91 4/91 1/92 2/92 3/92 4/92 1/93 2/93 3/93 4/93 1/94 2/94 3/94
Figura 9-5

Para elaborarmos o diagrama de ciclo , devemos determinar os relativos de ciclo,

conforme a expresso (4). A Tabela 9-6 , a seguir, mostra os clculos.
Tabela 9-6
X Y Y 100 x (Y/ Y) Relativo de Ciclo
0 30 31,34 100 x 30/31,34 95,72
1 28 30,22 100 x 28/30,22 92,65
2 33 29,10 100 x 33/29,10 113,40
3 27 27,98 100 x 27/27,98 96,50
4 30 26,86 100 x 30/26,86 111,69
5 25 25,74 100 x 25/25,74 97,13
6 26 24,62 100 x 26/24,62 105,61
7 23 23,50 100 x 23/23,50 97,87
8 20 22,38 100 x 20/22,38 90,17

X Y Y 100 x (Y/ Y) Relativo de Ciclo

11 23 19,02 100 x 23/19,02 120,93
12 17 17,90 100 x 17/17,90 94,97
9 18 21,26 100 x 18/21,26 84,67
10 20 20,14 100 x 20/20,14 99,30

A representao grfica do ciclo :

 Relativo do Ciclo
Em %
121
120
119
118
117
116
115
114
113
112
110
109
108
107
106
105
104
103
102
100
99
98
97
96
95
94
93
92
91
90
89
88
87
86
85
84

1/91 2/91 3/91 4/91 1/92 2/92 3/92 4/92 1/93 2/93 3/93 4/93
Figura 9-6

Como podemos observar pelo grfico, os perodos 1/93 e 3/93 foram os que
sofreram as maiores variaes em relao tendncia da srie histrica.

Demais Anlises de Tendncias

A tcnica de anlise de srie temporais se aplica igualmente aos demais atributos

mencionados anteriormente, levando em conta os perodos trimestrais como
sugerido, apesar de que a tcnica pode ser empregada para qualquer perodo
desejado.

Anlise de Impacto

A anlise de impacto procura avaliar as variaes da qualidade, produtividade e

aspectos de custos dos processos de desenvolvimento e gesto do software, em funo
de mudanas operadas no ambiente, tais como introduo de nova tecnologia de
desenvolvimento, tecnologia de gesto, ferramentas de apoio ao desenvolvimento,
investimentos em treinamento e assim sucessivamente.

Esta anlise tem por objetivo verificar se as mudanas implantadas alcanaram os

resultados esperados, principalmente no que diz respeito a melhoria da qualidade,
aumento da produtividade e reduo de custos.

A anlise pode ser representada graficamente , evidenciando o impacto ao longo

do tempo.

O exemplo a seguir apresenta este tipo de representao.

Supondo que em um determinado ponto no tempo, os projetos de software

passem a empregar ferramenta CASE. Nossa inteno seria verificar o impacto na
produtividade de desenvolvimento. Devemos ento, considerar a produtividade antes e
depois da introduo desta nova tecnologia.

Produtividade
30 Antes do CASE Depois do CASE

25

20

15

10

1 2 3 4 5 6 7 8 9 10 11 12 13 Perodo de Tempo
Figura 9-7

Poderamos tambm estabelecer grficos de controle, evidenciando as mudanas

dos limites de controle superiores e inferiores. Este exemplo hipottico mostra que logo
aps a introduo do CASE houve uma diminuio da produtividade, isto devido ao
perodo necessrio para a aprendizagem da equipe tcnica com a nova ferramenta.
Depois deste perodo de aprendizagem, h um aumento constante e vertiginoso da
produtividade.

O mesmo tipo de anlise pode ser feita para qualquer uma das medidas dos
processos de desenvolvimento e de gesto do produto, bviamente no nvel ttico de
agregao, o qual trata basicamente com valores mdios das medidas operacionais.

Anlise de Atributos

A anlise de atributos procura comparar os indicadores de qualidade,

produtividade, custos e outros ( a critrio ) entre plataformas de hardware/software,
metodologias de desenvolvimento, tecnologias de gesto, habilidades e perfis de pessoal
e outras medidas subjetivas ou qualitativas.

O objetivo obter, com base nas anlises comparativas, informaes que

subsidiem decises acerca da alocao de projetos de desenvolvimento conforme a
combinao de plataforma,metodotologia, tecnologia e perfil de pessoal mais adequada
para atingir metas estipuladas de qualidade, produtividade e custos.

Esta anlise tambm pode ser representada graficamente, superpondo valores

dos indicadores de acordo com diferentes combinaes de atributos.

O exemplo a seguir demonstra esta representao grfica para a anlise de

atributos, considerando tambm a medio de produtividade.

Esta abordagem de anlise pode ser utilizada para comparar densidade de

defeitos, custos do ponto de funo , exatido de estimativas de prazo, eficincia da
remoo de defeitos etc.

Produtividade

30

25

20

15

10

1 2 3 4 5 6 7 8 9 Perodo de Tempo
Figura 9-8
Plataforma Mainframe,Metodologia Estruturada,baixo ndice de
tecnologia de gesto

Plataforma Cliente-Servidor,Anlise Essencial,JAD e Prototipao,

alto ndice de gesto

Modelagem do Ambiente de Desenvolvimento

A modelagem do ambiente de desenvolvimento j mais complexa que a anlise

atributos, pois aplica modelos de regresso mltipla, a fim de determinar quais os fatores
que contribuem para o ambiente de alta qualidade e produtividade.

A regresso mltipla serve para definir modelos de relaes causais.

Num modelo deste tipo, a qualidade e produtividade so determinadas como

variveis dependentes, enquanto os demais fatores so variveis independentes.

O primeiro passo definir quais as variveis que, com base na experincia da

instalao, tem demonstrado que afetam positivamente a varivel dependente. Segundo,
devemos ter informaes sobre a ocorrncia dos valores dessas variveis.
Terceiro,elaborar as equaes de regresso e testar, com o apoio de pacotes estatsticos,
os modelos construdos.

Por exemplo, considerando que a produtividade funo de ferramentas de

desenvolvimento, reutilizao de cdigo,ferramentas para teste,experincia e perfl da
equipe e uso de mtodos de gesto de projetos, poderamos elaborar a seguinte
equao:

Produtividade = f ( Ferramentas de desenvolvimento,reutilizao,ferramentas

para teste,experincia da equipe,experincia do usurio,uso de mtodos de
gesto)

Supondo que ao processarmos o modelo encontrssemos o resultado:

Produtividade = f( ferramentas de desenvolvimento,reutilizao e experincia da

equipe)

Isto significaria que quanto maior o nvel de sofisticao e adequabilidade das

ferramentas de desenvolvimento, quanto maior o nvel da reutilizao e quanto
maior a experincia da equipe de projeto, maior ser a produtividade.

O emprego da regresso mltipla permite que testemos o modelo passo a passo (

step by step), com possibilidade de isolar as influncias das variveis
independentes em relao dependente.

Na medida em que as variveis independentes vo sendo colocadas na equao

de regresso possvel verificar se o modelo est se degradando.

A medida de degradao do modelo dado por um indicador denominado de

coeficiente de determinao ajustado, cuja diminuio indica degradao do
modelo pela incluso de uma varivel. Neste caso descarta-se a varivel do
modelo e assim sucessivamente at que tenhamos o modelo definitivo.

Uma vez que o modelo esteja determinado, com as variveis que efetivamente
contribuem para alta qualidade e produtividade, o gerente de desenvlvimento pode
modelar o seu ambiente para que as variveis estejam presentes em todos os
projetos.

As medies sobre ndice de tecnologia de desenvolvimento, ndice de tecnologia

de gesto e demais medies qualitativas fornecem a maioria das variveis a
serem tratadas no modelo. Geralmente variveis deste tipo, qualitativas, so
variveis ordinais e devem ser tratadas por mtodos estatsticos no-paramtricos.

REFERNCIAS

1. KAZMIER. L. J. Estatstica Aplicada A Economia e Administrao. McGraw-Hill, So

Paulo , 1982.

Vide Kugler & Fernandes 2 para exemplo de como aplicar a regresso linear para
modelagem utilizando a tcnica de path analisys.
2. KUGLER, J.L.C. & FERNANDES,A.A. Planejamento e Controle de Sistemas de
Informao. Livros Tcnicos e Cientficos S.A. , Rio de Janeiro, 1984.
Captulo
10
APLICAO DAS MEDIES EM
DECISES ECONMICAS RELATIVAS
A SOFTWARE

Uma das dimenses da gesto do software a econmica. Como exposto no captulo 2, o

conceito da qualidade fornece esta conotao pois o esforo de atingir patamares mais
evoludos de qualidade recai tambm sobre a gesto dos custos de no conformidade ou
m qualidade. Ou seja, qualidade aumenta lucratividade pela diminuio dos custos de
falhas internas e externas e pelo aumento da satisfao dos clientes.

Na rea de software a gesto econmica tem sido muito negligenciada.

Infelizmente a nica preocupao, principalmente nas organizaes brasileiras, tem sido o
atingimento do prazo, independente dos outros fatores. Geralmente experimenta-se altos
custos de falhas internas e externas ( manuteno ou atendimento de campo) fazendo
com que grande parte dos recursos fique alocado s atividades de manuteno, limitando
a capacidade da empresa em desenvolver novas solues, tornando-a assim menos
competitiva.

Entretanto, na medida em que a organizao comea a aplicar medies e reter

as informaes sobre os seus resultados, so estabelecidas as condies necessrias
para que decises econmicas relativas ao software sejam tomadas.

Neste captulo procuraremos mostrar algumas aplicaes de deciso econmica

que podem ser feitas com base nos resultados das medies.

Concentraremos nossa discusso nos seguintes tpicos:

Deciso de Comprar/Desenvolver Internamente

Planejamento de Custos de Manuteno Anual de Software
Viabilidade de Utilizao de Inspees de Projeto
Viabilidade de Utilizao de Anlise Essencial
Viabilidade de Utilizao de Projeto Estruturado
Viabilidade de Utilizao de Anlise de Complexidade
Viabilidade de Utilizao de Inspeo de Cdigo

10.1 - Deciso de Comprar/Desenvolver Internamente

Algumas vezes nos deparamos com este tipo de deciso, entre comprar um
pacote pronto ou desenvolver internamente o software.

Vide GRADY 1 para aplicaes e justificativas dessas anlises econmicas.

 Obviamente que neste caso devemos levar em considerao o custo
oportunidade que o custo que a empresa ter caso perder uma oportunidade para
realizar um negcio lucrativo.

A base para a anlise compreende:

Tamanho em Pontos de Funo do Software (Pacote)

Custo do Ponto de Funo de Desenvolvimento conforme a plataforma
de hardware/software
Custo oportunidade

Suposies:

Tamanho em Pontos de Funo do Pacote = 1000

Custo do Pacote = $ 100.000
Custo do Ponto de Funo de desenvolvimento = $ 200
Custo Oportunidade = $ 100.000

Aplicao das Suposies:

Custo de desenvolver internamente o software

Custo do ponto de funo de desenvolvimento x tamanho em pontos de

funo do pacote + custo oportunidade

$ 200 x 1000 + $ 100.000 = $ 300.000

Ganhos com a compra do pacote

Custo de desenvolver internamente - custo do pacote

$ 300.000 - $ 100.000 = $ 200.000

Neste exemplo optaramos por comprar o pacote ao invs de desenvolv-lo

internamente.

10.2 - Planejamento de Custos de Manuteno Anual de Software

A base para a anlise compreende:

Custo do Ponto de Funo de Manuteno/Melhoria conforme cada

plataforma de hardware/software
Mdia Anual de Pontos de Funo mantidos/acrescidos para cada software

Suposies:

Tabela de custos do ponto de funo de manuteno/melhoria conforme

plataforma:
 Plataforma 1 Plataforma 2 Plataforma 3
$ 80.00 $ 90.00 $ 85.00

Supondo a distribuio quantitativa de software por plataforma:

Tabela 10-1
Plataforma 1 Plataforma 2 Plataforma 3
Software Mdia Anual Software Mdia Anual Software Mdia Anual
A 200 D 150 G 100
B 100 E 200 H 150
C 100 F 250 I 300

Aplicao das Suposies:

Tabela 10-2
Plataforma 1 Plataforma 2 Plataforma 3
Software Resultado Software Resultado Software Resultado
A 200x$80 = $16.000 D 150x$90 = $13.500 G 100x$85 = $8500
B 100x$80 = $ 8.000 E 200x$90 = $18.000 H 150x$85 = $12.750
C 100x$80 = $ 8.000 F 250x$90 = $22.500 I 300x$85 = $25.500
Total $ 32.000 $ 54.000 $ 46.750

Neste exemplo, o nosso oramento anual para a manuteno/melhoria do

conjunto de software da instalao seria de $ 132.750.

10.3 - Anlise de Viabilidade da Utilizao de Inspees de Projeto

A base para a anlise compreende:

Tamanho do projeto em milhares de instrues fontes

( KNCSI- Thousands of Non-Commentary Source Instructions)
Mdia de defeitos por KNCSI
Mdia de defeitos gerados no projeto
Nmero timo de inspetores durante uma inspeo
Razo do tempo de preparao em relao ao tempo de inspeo
Nmero de defeitos encontrados por hora de inspeo
Percentagem mdia de defeitos encontrados nas inspees de projeto
Razo do custo para encontrar e remover defeitos durante o teste em
relao ao custo para encontrar e remover defeitos na fase de projeto
Nmero de profissionais em tempo integral dedicados ao projeto
Custo mdio do homem/hora

Suposies:

Tamanho do projeto em KNCSI

80 KNCSI
Mdia de defeitos por KNCSI
7 defeitos por KNCSI
 Mdia de defeitos gerados no projeto
35% do total dos defeitos introduzidos no software
Nmero timo de inspetores durante uma inspeo
De 4 a 5 inspetores
Razo do tempo de preparao em relao ao tempo de inspeo
Em torno de 1.75
Nmero de defeitos encontrados por hora de inspeo
2.5 defeitos por hora de inspeo
Percentagem mdia de defeitos encontrados nas inspees de projeto
55% do total dos defeitos de projeto
Razo do custo para encontrar e remover defeitos durante o teste em
relao ao custo para encontrar e remover defeitos na fase de projeto
6.25 vezes mais
Nmero de profissionais em tempo integral dedicados ao projeto
8 profissionais
Custo mdio do homem/hora
$ 16.00

Aplicao das Suposies

Defeitos esperados para o projeto como um todo

(80.000 1000) x 7 = 560

Defeitos esperados para a fase de projeto

560 x .35 = 196 defeitos

Esforo para encontrar os defeitos na inspeo do projeto

a. ( 196 defeitos x .55) 2.5 defeitos/hora = 43.12 ou 43

b. 43 horas x 5 inspetores = 215 homens/hora para inspeo
c. 215 x 1.75 = 376.25 ou 376 homens/hora de preparao
d. 215 + 376 = 591 homens/hora de esforo de inspeo

Esforo para encontrar o mesmo nmero de defeitos durante o teste

591 homens/hora x 6.25 = 3693.75 ou 3694 homens/hora

Resultados

Ganho em esforo

3694 - 591 = 3103

Ganho no prazo do projeto

3103 ( 8 profissionais x 160 horas ) = 2.4 meses

 Ganho financeiro

3103 x $ 16.00 = $ 49.648.00

10.4 - Anlise de Viabilidade da Utilizao de Anlise Essencial

A base para a anlise compreende:

Os diagramas e dicionrio de dados produzidos proporcionam informaes

teis aos analistas no sentido de verificar problemas que so encontrados
na fase de teste
Tamanho do projeto em milhares de instrues fontes
Esforo total do projeto
Mdia de defeitos pr-release por KNCSI
Tempo necessrio para encontrar e remover defeitos introduzidos na
anlise essencial durante o teste
Percentual mdio de tempo despendido na fase de anlise de requisitos
Percentual mdio de tempo despendido na fase de teste
Percentual mdio de defeitos, em relao ao total de defeitos, com
possibilidade de serem introduzidos pela anlise
Percentual de defeitos introduzidos pela especificao, sem a utilizao de
ferramentas de apoio anlise
Percentual de defeitos introduzidos pelo projeto, sem a utilizao de
ferramentas de apoio anlise
Percentual de eliminao de defeitos com a utilizao de ferramentas
Reduo do tempo para teste em funo dos diagramas de anlise
Aumento do tempo de anlise de requisitos em funo da utilizao de
diagramas de anlise
Nmero de profissionais alocados em tempo integral ao projeto
Custo mdio do homem/hora

Suposies:

Tamanho do projeto em KNCSI

100
Esforo total do projeto
45714 homens/hora
Mdia de defeitos pr-release por KNCSI
7 defeitos
Tempo necessrio para encontrar e remover defeitos introduzidos na
anlise essencial durante o teste
15 horas por defeito
Percentual mdio de tempo despendido na fase de anlise de requisitos
18%

Percentual mdio de tempo despendido na fase de teste

29%
 Percentual mdio de defeitos, em relao ao total de defeitos, com
possibilidade de serem introduzidos pela anlise
20%
Percentual de defeitos introduzidos pela especificao, sem a utilizao de
ferramentas de apoio anlise
10%
Percentual de defeitos introduzidos pela projeto, sem a utilizao de
ferramentas de apoio anlise
10%
Percentual de eliminao de defeitos com a utilizao de ferramentas
75%
Reduo do tempo para teste em funo dos diagramas de anlise
5%
Aumento do tempo de anlise de requisitos em funo da utilizao de
diagramas de anlise
10%
Nmero de profissionais alocados em tempo integral ao projeto
10
Custo mdio do homem/hora
$ 16.00

Aplicao das Suposies:

Determinao do nmero total de defeitos esperados

(100.000 1000) x 7 = 700

Defeitos esperados com possibilidade de serem introduzidos pela anlise

700 x .20 = 140

defeitos introduzidos pela anlise de requisitos: 700 x .10 = 70
defeitos introduzidos pelo projeto : 700 x .10 = 70

Acrscimo de esforo na fase de anlise de requisitos

45714 homens/hora x .18% = 8228. 52 ou 8229

8229 x .10% = 822.9 ou 823 homens/hora

Esforo para encontrar e remover 75% dos defeitos durante o teste

.75 x 140 = 105 defeitos

105 defeitos x 15 horas = 1575 homens/hora

Resultados:

Ganho no esforo de teste

1575 homens/hora - 823 homens/hora = 752 homens/hora

 Decrscimo do esforo de teste

45714 homens/hora x .29 = 13257.06 ou 13257

13257 x .05 = 662.85 ou 663

Ganho total de esforo

752 + 663 = 1415

Ganho financeiro

1415 x $ 16.00 = $ 22.640,00

Ganho no prazo do projeto

1415 ( 10 x 160 ) = .88 meses

10.5- Anlise de Viabilidade da Utilizao de Projeto Estruturado

A base para a anlise compreende:

Tamanho do projeto em KNCSI

Esforo total do projeto
Mdia de defeitos pr-release por KNCSI
Tempo para encontrar e remover defeitos introduzidos pelo projeto durante
a fase de teste
Tempo mdio despendido na fase de projeto estruturado, em relao ao
total
Tempo mdio despendido na fase de teste, em relao ao total
Percentual dos defeitos introduzidos pelo projeto estruturado em relao ao
total
Percentual de eliminao de defeitos com utilizao de ferramentas de
apoio elaborao do projeto
Acrscimo de tempo no projeto em funo do emprego de ferramentas
Decrscimo de tempo na fase de teste em funo do emprego de
diagramas
Nmero de profissionais em tempo integral alocado ao projeto
Custo mdio do homem/hora
Suposies:

Tamanho do projeto em KNCSI

80
Esforo total do projeto
36572
Mdia de defeitos pr-release por KNCSI
7
Tempo para encontrar e remover defeitos introduzidos pelo projeto durante
a fase de teste
12 horas por defeito
Tempo mdio despendido na fase de projeto estruturado, em relao ao
total
19% do total
Tempo mdio despendido na fase de teste, em relao ao total
29% do tempo total
Percentual dos defeitos introduzidos pelo projeto estruturado em relao ao
total
25% do total
Percentual de eliminao de defeitos com utilizao de ferramentas de
apoio elaborao do projeto
75% dos defeitos
Acrscimo de tempo no projeto em funo do emprego de ferramentas
5% de acrscimo
Decrscimo de tempo na fase de teste em funo do emprego de
diagramas
5% de decrscimo
Nmero de profissionais em tempo integral alocado ao projeto
9
Custo mdio do homem/hora
$ 16.00

Aplicao das Suposies:

Total de defeitos esperados pelo projeto

( 80.000 1000 ) x 7 = 560

Defeitos esperados a serem introduzidos pelo projeto estruturado

560 defeitos x .25 x .75 = 105

Acrscimo de esforo no projeto estruturado

36572 x .19 x .05 = 347.43 ou 348

Tempo para encontrar e remover os mesmos 105 defeitos no teste

105 x 12 horas = 1260 homens/horas

 Decrscimo do esforo na fase de teste

36572 x .29 x .05 = 530.29 ou 530 homens/horas

Resultados:

Ganho em esforo para remover defeitos

1260 homens/horas - 348 homens/hora = 912 homens/horas

Ganho no esforo total

912 homens/horas + 530 homens/horas = 1442 homens/hora

Ganho financeiro

1442 x $ 16 = $ 23.072,00

Ganho no prazo do projeto

1442 ( 9 x 160 ) = 1 ms

10.6 - Anlise da Viabilidade da Utilizao da Anlise de Complexidade

A base da anlise compreende:

Tamanho do projeto em KNCSI

Esforo total do projeto
Mdia de defeitos pr-release por KNCSI
Percentual mdio de defeitos da fase de projeto
Percentual mdio de defeitos da fase de codificao
Razo de custo para encontrar e remover defeitos introduzidos na fase de
codificao, durante o teste
Tempo mdio para encontrar e remover defeitos
Percentual de defeitos com possibilidade de serem encontrados e
removidos com utilizao de ferramentas na fase de projeto
Percentual de defeitos com possibilidade de serem encontrados e
removidos com utilizao de ferramentas na fase de codificao
Nmero de profissionais alocados em tempo integral ao projeto
Custo mdio do homem/hora

Suposies:

Tamanho do projeto em KNCSI

50
Esforo total do projeto
22857
 Mdia de defeitos pr-release por KNCSI
7
Percentual mdio de defeitos da fase de projeto
35% do total
Percentual mdio de defeitos da fase de codificao
45% do total
Razo de custo para encontrar e remover defeitos introduzidos na fase de
codificao, durante o teste
2.5
Tempo mdio para encontrar e remover defeitos no teste
10 horas por defeito
Percentual de defeitos com possibilidade de serem encontrados e
removidos com utilizao de ferramentas na fase de projeto
25% dos defeitos
Percentual de defeitos com possibilidade de serem encontrados e
removidos com utilizao de ferramentas na fase de codificao
25% dos defeitos
Nmero de profissionais em tempo integral
6
Custo mdio do homem/hora
$ 16.00

Aplicao das Suposies:

Defeitos de projeto e de cdigo que se supe encontrar com as

ferramentas

350 defeitos x .35 x .25 = 31 defeitos de projeto

350 defeitos x .45 x .25 = 39 defeitos de codificao

Para encontrar e remover 70 defeitos adicionais durante a codificao

(70 x 10 horas ) 2.5 = 280 homens/hora

Esforo para encontrar e remover defeitos durante o teste

280 x 2.5 = 700

Resultados:

Ganho de esforo

700 - 280 = 420 homens/horas

Ganho financeiro

420 x $ 16.00 = $ 6720

 Ganho no prazo do projeto

420 ( 6 x 160 ) = .4 meses

10.7 - Anlise de Viabilidade da Utilizao da Inspeo de Cdigo

A base para a anlise compreende:

Tamanho do projeto em KNCSI

Esforo total do projeto
Mdia de defeitos pr-release por KNCSI
Razo para encontrar defeitos no teste em relao codificao
Nmero timo de inspetores numa inspeo
Razo de tempo de preparao pelo tempo de inspeo
Percentual mdio de defeitos encontrados pela inspeo de cdigo
Nmero timo de linhas inspecionadas por hora
Nmero de linhas de comentrios em relao s de instrues fontes
Nmero de profissionais alocados em tempo integral
Custo mdio do homem/hora

Suposies:

Tamanho do projeto em KNCSI

50
Esforo total do projeto
22857
Mdia de defeitos pr-release por KNCSI
7
Razo para encontrar defeitos no teste em relao codificao
2.5
Nmero timo de inspetores numa inspeo
4a5
Razo de tempo de preparao pelo tempo de inspeo
1.75
Percentual mdio de defeitos encontrados pela inspeo de cdigo
60%
Nmero timo de linhas inspecionadas por hora
250
Nmero de linhas de comentrios em relao s de instrues fontes
2 linhas de comentrios para cada 10 de instrues fontes
Nmero de profissionais alocados em tempo integral
6
Custo mdio do homem/hora
$ 16.00
 Aplicao das Suposies:

Defeitos esperados para o projeto como um todo

350

Tempo estimado para inspecionar todo o cdigo

50.000 x 1.2 (linhas de comentrios) = 60.000

60.000 250 linhas/hora = 240 horas
240 horas x 5 inspetores = 1200 homens/hora para inspeo
1200 x 1.75 = 2100 homens/hora para preparao
1200 + 2100 = 3300 homens/hora para toda a inspeo

Esforo para encontrar os mesmos defeitos no teste

60% dos defeitos de 350 = 210 defeitos

( 3300 x .6 ) x 2.5 (razo de custo) = 4950

Resultados:

Ganho de esforo

4950 - 3300 = 1650 homens/horas

Ganho financeiro

1650 x $ 16.00 = $ 26.400,00

Ganho de prazo no projeto

1650 ( 6 x 160 ) = 1.7 meses

REFERNCIAS

1. GRADY,R.B. Practical Software Metrics for Project Management and Process

Improvement. Prentice-Hall, Englewood Cliffs, New Jersey,1992.
Captulo
11
APLICAO ESTRATGICA DAS
MEDIES - MELHORIA
CONTNUA DO PROCESSO

A aplicao estratgica das medies reside em trs pontos fundamentais, quais sejam:

Benchmarking
Melhoria Contnua
Avaliao Econmica e de Resultados

Benchmarking , de acordo com Kearns 5 , o processo contnuo de medir os

produtos, servios e prticas da empresa em relao aos principais competidores ou em
relao quelas companhias reconhecidas como lderes na indstria.

O Benchmarking tem uma ligao bastante estreita com o processo de melhoria

contnua, visto que a realizao de um esfoo para atingir o nvel de excelncia de um
competidor ou de outras empresas no-competidoras, no que diz respeito a determinadas
reas de negcio ou a prticas, enquadra-se na filosofia do Kaizen.

Felizmente, para a rea de informtica, existem dois modelos de certificao de

qualidade em software que servem de base para realizar Benchmarking. So eles o
modelo SEI - Capability Maturity Model do Software Engineering Institute da Carnegie-
Mellon University e o modelo ISO 9000-3. Ambos so considerados como modelos de
Sistemas da Qualidade.

A melhoria contnua baseia-se na filosofia do Kaizen e tem como elementos

fundamentais para a gesto de processos, a aplicao das ferramentas da qualidade, isto
, folha de verificao, grfico de pareto, diagrama de causa e efeito ( Ishikawa
diagram), carta de tendncia, histograma,grfico de disperso e o grfico de controle
estatstico. Outro instrumento importante a utilizao do Ciclo de Deming ou PDCA -
Plan-Do-Check-Action, o qual o cerne da melhoria contnua.

A avaliao econmica tenta valorar o acervo do software na empresa como um

todo e por suas reas, conforme o uso dos recursos pelas diversas divises e
departamentos. A avaliao dos resultados tenta medir o retorno para a empresa do
acervo de software em termos de lucratividade, market share etc.

Este captulo divide-se portanto, nestes trs temas, procurando demonstrar o que
denominamos de medies estratgicas.
11.1 - O Processo de Benchmarking

O processo de Benchmarking procura comparar aspectos quantitativos e

qualitativos do ambiente de software da empresa.

A comparao quantitativa reside nos atributos de qualidade,produtividade e

custos de projetos de software e de gesto do produto.

Esta anlise importante na medida em que a empresa depende

estratgicamente da tecnologia da informao.

Em alguns tipos de negcios, onde a competio extremamente acirrada, a

empresa necessita ter uma competncia estabelecida para sobreviver e crescer no seu
negcio.

Um exemplo so as instituies financeiras, cujo nvel de automao, que na

realidade basicamente software, um requisito mandatrio para operar no mercado.

Nesse tipo de negcio, inclusive, o produto o prprio software. Um produto de

aplicao financeira ou de aplicao comercial bancria ( os emprstimos), so
puramente software. Cria diferencial quem tiver produtos de melhor qualidade, com maior
gama de opes, que reduza o tempo de acesso e uso do produto pelo cliente e quem
tem maior controle sobre as operaes ( automao do back office) e quem conhecer
melhor o seu cliente ( database marketing) e quem for extremamente responsivo s
necessidades dos clientes e do mercado.

Isto, bviamente, requer produo de software de alta qualidade e com grande

produtividade e a um custo econmico da qualidade, considerando todo o ciclo de vida do
produto.

A comparao qualitativa j procura confrontar as prticas relativas produo do

software, levando em conta no somente tecnologia e mtodos de desenvolvimento como
tambm a infra-estrutura de gerenciamento.

O processo de Benchmarking, de acordo com Camp 2 consiste em 5

etapas,conforme mostra a Figura 11-1.

Benchmarking Quantitativo

Consiste em comparar a qualidade do processo de desenvolvimento em termos de

densidade de defeitos, a qualidade dos produtos tambm em termos de densidade de
defeitos, a produtividade do desenvolvimento em termos de Pontos de Funo por H/M e
os custos do ponto de funo de desenvolvimento e de manuteno adaptativa e projetos
de melhoria.

Esta anlise tambm pode ser demonstrada de forma grfica.

 A seguir fornecido um exemplo grfico do benchmarking. No devemos
esquecer que a comparao mais til quando estivermos tratando com o mesmo tipo de
plataforma, metodologia etc.

1. Identificar o objetivo do benchmarking

PLANEJAMENTO
2. Identificar empresas/modelos para comparar

3. Determinar mtodo de coleta de dados

4. Determinar o gapde desempenho

ANLISE
5. Projetar futuros nveis de desempenho

6. Comunicar resultados e ganhar aceitao

INTEGRAO
7. Estabelecer metas funcionais

8. Desenvolver planos de ao

AO 9. Implementar aes e monitorar o progresso

10. Recalibrar o benchmarking

MATURIDADE .Comprometimento da administrao

.Prticas incorporadas nos processos

Figura 11-1

Produtividade
Mdia 50

45 Empresa A

40
Nossa empresa
35

30 Empresa B

25 Empresa C

20

Figura 11-2

Neste exemplo h duas empresas que tm maior produtividade que a nossa.

O benchamarking competitivo importante para fornecer os primeiros insihgts. O

importante descobrir quais as prticas que levam as empresas B e C a terem maior
produtividade do que a nossa. O objetivo seria ento atingirmos o mesmo desempenho da
empresa C, considerada a de mais alto desempenho.

O mesmo tipo de comparao pode ser realizada para os outros indicadores de

qualidade e custos.

Benchmarking Qualitativo
 O Benchmarking qualitativo pode ser desenvolvido atravs de uma pesquisa cujas
questes evidenciem o estado-da-arte da tecnologia de desenvolvimento e de gesto
empregadas pelas empresas competidoras ou no.

Os instrumentos para a determinao do ndice de Tecnologia de

Desenvolvimento, o ndice de Tecnologia de Gesto e as demais medies qualitativas
apresentados no captulo 7 fornecem muitos subsdios para este tipo de pesquisa.

A outra alternativa compararmos as prticas da empresa com os modelos de

certificao da qualidade em software

Devido a importncia de ambos modelos, decidimos por abrir tpicos especficos

para ambos.

11.2 - O Modelo SEI de Certificao da Qualidade em Software

O modelo SEI foi desenvolvido pela Carnegie-Mellon University ,a pedido do DoD -

Departamento de Defesa, em especial a Fora Area Norte-Americana, visando criar uma
forma de certificar empresas de desenvolvimento de software.

O modelo procura determinar, com base nos fatores de organizao, gerncia de

projetos, gerncia de processos e tecnologia, nveis de maturidade de uma empresa em
relao ao software. O modelo SEI tambm conhecido como Software Process
Maturity ou Capability Maturity Model - CMM.

O modelo composto de cinco nveis de maturidade do processo, ou:

Inicial

Neste estgio , tambm chamado de ad hoc ou catico, a organizao no opera

com procedimentos formalizados em termos de desenvolvimento, estimativas de
custo e planos dos projetos.O controle de mudana no homogneo, no h
comprometimento da gerncia em relao a planos e procedimentos, sendo que a
instalao e manuteno de software frequentemente apresenta problemas srios.
Os profissionais so dirigidos de crise em crise , por prioridades no planejadas e
mudanas no gerenciadas.

comum aos gerentes realizarem solicitaes difceis de serem atingidas pela

equipe tcnica, enquanto cortam recursos. O prazo a nica prioridade e os
talentos no conseguem ser retidos.

As aes necessrias para migrar deste nvel ou estgio para o seguinte

concentram-se em: planejamento (estimativas), monitoramento do projeto, controle
de mudana, comprometimento gerencial e garantia da qualidade.

Repetido

Vide Humphrey 4 cuja obra disseca o modelo SEI.

A principal diferena entre este nvel e o inicial que j h controle sobre a forma
como a organizao estabelece seus planos e comprometimentos.

As aes iniciadas no estgio anterior j comeam a surtir efeito em termos de

planejamento de projetos documentado, incluindo estimativas, controle de
projetos, controle de subcontratados, roteiro de desenvolvimento, documentao
do projeto, estrutura de garantia da qualidade, procedimentos documentados e
mecanismos de controle de mudanas e gerncia de configurao ( controle de
verses do software).

As aes chaves para a evoluo deste estgio para o seguinte so:

estabelecimento do grupo de engenharia de processo, da arquitetura de
desenvolvimento de software e a introduo de mtodos e tecnologias de
engenharia de software.

Definido

Neste nvel a organizao j estabeleceu um processo padro o qual pode ser

adaptado para necessidades especficas de cada projeto.

O Grupo de Engenharia de Processo estabelecido para implementar e evoluir o

processo de desenvolvimento, inclusive com o treinamento das equipes tcnicas,
revises gerenciais perdicas so realizadas para avaliar a efetividade dos novos
procedimentos, estabelecem-se mtodos de teste, medies so realizadas
quanto a erros no processo, as ferramentas de desenvolvimento esto definidas e
o processo de inspeo formal institudo.

As aes necessrias para a evoluo deste estgio para o seguinte so:

estabelecimento de medies relativas a parmetros de qualidade e custo do
processo, estabelecimento de um banco de dados sobre o processo para anlises
de qualidade e produtividade e avaliaes sobre a qualidade de cada produto.

Gerenciado

Aqui as aes desencadeadas no nvel anterior so implementadas em sua

totalidade, incluindo benchmarking de produtos; para cada projeto realizado um
planejamento da qualidade; h planos de introduo de novas tecnologias;
treinamentos sobre planejamento da qualidade, gerncia quantitativa do
processo, mtodos avanados de desenvolvimento e prototipao so
estabelecidos; planos de melhoria do processo so estabelecidos; o desempenho
monitorado conforme os planos da qualidade e melhorias, as mudanas nos
projetos esto sob controle da gerncia de configurao, o nvel das medies
mais detalhado e etc.

As aes requeridas para a evoluo deste estgio para o seguinte so: apoio
informatizado coleta de dados sobre o processo e a utilizao dos dados para a
anlise e modificao do processo visando a preveno de problemas e melhoria
contnua.

Otimizado
 Este o estgio da melhoria contnua do processo, da reutilizao de
componentes , da utilizao intensiva de mtodos de preveno de erros, do
controle estatstico do processo e da modelagem do ambiente de
desenvolvimento.

A Figura 11-3 resume os estgios e suas principais caractersticas.

Preveno de Defeitos OTIMIZADO

Automao do Processo de Software

Medio de Software
Gerncia da Qualidade do Software GERENCIADO

Processo Padronizado
Inspeo de Software DEFINIDO
Metodologia de Teste
Grupo de Engenharia de Software

Planejamento de Projetos
Controle de Projetos REPETIDO
Gerncia de Configurao
Quality Assurance

INICIAL

Figura 11-3

Este modelo alm de permitir a organizao realizar uma auto-avaliao , tambm

possibilita o planejamento da melhoria do desenvolvimento de software.

De acordo com Humphrey 4 a passagem de um estgio para outro, sendo feito

de forma planejada , leva em torno de 2 anos.

Recentes estatsticas norte-americanas 6 , obtidas atravs de pesquisa

realizada pelo Software Engineering Institute , revelou que 74% das empresas de
software se encontram no nvel 1, 19% no nvel 2 e 7% no nvel 3.

Os passos propostos para o planejamento da melhoria do processo de software,

de acordo com o modelo consistem em:

1. Entender a situao atual do processo de desenvolvimento

2. Desenvolver uma viso do processo desejado

Veja o captulo 15, o qual traz um instrumento de auto-avaliao quanto ao estgio de

maturidade de software.
 3. Estabelecer uma lista das aes necessrias para o aperfeioamento do
processo
4. Produzir um plano para realizar as aes planejadas e requeridas
5. Comprometer recursos para executar o plano

11.3 - O Modelo ISO de Certificao da Qualidade em Software

O modelo ISO para software uma derivao da 9001 e conhecida como ISO
9000-3 3 apesar que, para fins de certificao, considera-se como 9001.

O objetivo da norma proporcionar um guia de orientao onde um contrato entre

duas partes requer a demonstrao da capacidade do fornecedor para desenvolver, suprir
e manter produtos de software.

A norma estruturada em trs partes, quais sejam:

Sistema da Qualidade - Ferramental

Sistema da Qualidade - Atividades do Ciclo de Vida
Sistema da Qualidade - Atividades de Suporte

Cada parte dividida em elementos. A norma possui 22 elementos, ou:

Responsabilidade da Gerncia
Sistema da Qualidade
Auditorias Internas da Qualidade
Ao Corretiva
Reviso do Contrato
Especificao dos Requisitos do Comprador
Planejamento do Desenvolvimento
Planejamento da Qualidade
Projeto e Implementao
Teste e Validao
Aceitao
Replicao, Entrega e Instalao
Manuteno
Gerncia de Configurao
Controle de Documentos
Registros da Qualidade
Medies
Regras,Prticas e Convenes
Ferramentas e Tcnicas
Compras
Software Produto Incluso
Treinamento

A seguir apresentado um resumo dos principais elementos da norma.

4.1 - Responsabilidade da Gerncia

Inclue:

O fornecedor deve definir e documentar uma poltica da qualidade

A poltica deve ser entendida por todos na organizao
As responsabilidades e autoridades quanto s atividades relativas
qualidade, na organizao, devem estar claramente definidas
Os recursos e pessoal para verificao do sistema da qualidade devem
estar definidos
O fornecedor deve indicar um representante da administrao, com
responsabilidade e autoridade para assegurar que o sistema da qualidade
esteja em operao conforme os requisitos da norma
O sistema da qualidade deve ser revisto a intervalos regulares, com os
registros pertinentes documentados
O comprador ( cliente) deve definir exatamente suas necessidades e
especificaes
O fornecedor e o comprador devem realizar revises conjuntas para
verificar aderncia do software s especificaes e resultados de teste

4.2 - Sistema da Qualidade

Inclue:

Todos os elementos do sistema da qualidade devem estar documentados

O fornecedor deve preparar e documentar um plano da qualidade a fim de
implementar atividades da qualidade para cada projeto de software

4.3 - Auditorias Internas do Sistema da Qualidade

Inclue:

O fornecedor deve realizar auditorias internas peridicas para verificar a

conformidade do sistema da qualidade
As auditorias devem ser planejadas, documentadas e as recomendaes
acompanhadas

4.4 - Ao Corretiva
Inclue:

O fornecedor deve estabelecer, documentar e manter procedimentos para

investigar causas de no-conformidade do produto, analisar processos,
iniciar aes preventivas, aplicar controles para que as aes corretivas
sejam realizadas e implementar e registrar mudanas nos procedimentos
em funo dos resultados da ao corretiva

5.2 - Reviso do Contrato

Inclue:

O fornecedor deve estabelecer e manter procedimentos para a reviso do

contrato e para a coordenao dessas atividades
O fornecedor deve revisar cada contrato para assegurar que o escopo e
requisitos sejam definidos e documentados, que as contingncias sejam
identificadas, que informao proprietria seja adequadamente protegida,
 que quaisquer requisitos diferentes daqueles na proposta sejam
solucionados, que a responsabilidade do fornecedor com sub-contratados
esteja definida
O fornecedor deve manter registros dessas revises
O contrato deve prever critrios de aceitao do software, tratamento de
mudanas dos requisitos do comprador durante o desenvolvimento, o
tratamento de problemas detectados aps a aceitao, as atividades a
serem desempenhadas pelo comprador no que concerne a especificao
dos requisitos, a definio das facilidades, ferramentas e itens de software
a serem fornecidos pelo comprador, procedimentos e padres a serem
usados e requisitos de replicao do software
Devem ser designadas pessoas, de ambas as partes, para o
estabelecimento das especificaes dos requisitos do comprador

5.4 - Planejamento do Desenvolvimento

Incle:

O plano de desenvolvimento deve conter a definio do projeto em termos

de objetivos e relacionamento com outros projetos do comprador ou do
fornecedor, a organizao dos recursos para o projeto, incluindo estrutura
da equipe, responsabilidades, uso de sub-contratados e recursos materiais,
as fases de desenvolvimento, o cronograma do projeto e a identificao de
planos correlatos tais como plano da qualidade, plano de gerncia de
configurao, plano de integrao e plano de teste
O plano de desenvolvimento deve ser atualizado na medida do progresso
do projeto
Para cada fase do desenvolvimento devem ser estabelecidas as entradas e
sadas
O plano deve prever tambm como o projeto ser gerenciado
O plano deve identificar as regras, prticas, convenes,
ferramentas,tcnicas e a gerncia de configurao
O fornecedor deve verificar as sadas de todas as fases do
desenvolvimento

5.5 - Planejamento da Qualidade

Inclue:

O plano da qualidade deve prever os objetivos da qualidade, expresso em

termos mensurveis sempre quando possvel, os critrios de entrada e
sada para cada fase de desenvolvimento, identifidao dos tipos de teste,
planejamento detalhado do teste e responsabilidades quanto a revises e
testes, gerncia de configurao e controle de mudana e controle de
defeitos e ao corretiva

5.6 - Projeto e Implementao

Inclue:

Os seguintes aspectos inerentes s atividades de projeto devem ser

consideradas: regras de projeto, definies de interfaces internas,
metodologia de projeto, utilizao de experincias de projeto passadas
 No que tange implementao devem ser levadas em considerao regras
para programao, convenes consistentes de nomes, mtodos de
implementao
O fornecedor deve desempenhar revises e assegurar que os requisitos
sejam atendidos e que os mtodos de projeto e implementao sejam
adequadamente utilizados
O fornecedor deve manter registros documentados de tais revises

5.7 - Teste e Validao

Inclue:

O fornecedor deve estabelecer e revisar os planos de testes

O plano de teste deve considerar, planos para itens de software,
integrao, teste do sistema e teste de aceitao, casos de teste, dados de
teste e resultados esperados, ambiente de teste, ferramentas e software de
teste, o critrio pelo qual o trmino do teste ser julgado, a documentao
do usurio e os requisitos de pessoal e o treinamento correspondente
Durante o teste os seguintes aspectos devem ser levados em
considerao: os resultados do teste devem ser registrados , quaisquer
problemas e seus impactos possveis em outras partes do software devem
ser anotados e os responsveis notificados, de forma que sejam
solucionados, reas do software impactadas por qualquer modificao
devem ser identificadas e testadas novamente, a adequabilidade do teste
deve ser avaliada e o ambiente de hardware e software do teste deve ser
documentado
Antes de entregar o produto para a aceitao pelo comprador, o fornecedor
deve valid-lo e sempre quando possvel, dentro de condies similares ao
ambiente especificado no contrato
Quando o teste sob condies de campo requerido, os seguintes
aspectos devem ser levados em considerao: as caractersticas a serem
testadas no campo, as responsabilidades especficas do fornecedor e do
comprador no desenvolvimento e avaliao do teste e a restaurao do
ambiente do usurio

5.8 - Aceitao
Inclue:

Antes de desempenhar as atividades de aceitao, o fornecedor deve

assistir o comprador na identificao da programao da aceitao,
procedimentos para avaliao, o ambiente de hardware/software e recursos
necessrios e os critrios de aceitao a serem utilizados

5.9 - Replicao,Entrega e Instalao

Inclue:

A determinao do nmero de cpias do software a serem entregues

O tipo de meio magntico a ser utilizado, incluindo formatos
A estipulao da documentao requerida
Questes relativas a direitos autorais
 Custdia da cpia master e cpias de back-up, incluindo planos de
contingncia
O perodo de obrigao do fornecedor suprir cpias
As cpias a serem entregues devero ser verificadas quanto a sua
completeza
Os papis do fornecedor e comprador devero estar plenamente
estabelecidos quanto instalao
Deve-se levar em considerao responsabilidades relativas a: cronograma,
acesso s instalaes do comprador, disponibilidade de pessoal habilitado,
disponibilidade e acesso a sistemas e equipamentos do comprador, a
necessidade para validar cada instalao e um procedimento formal para a
aprovao de cada instalao aps o seu trmino

5.10 - Manuteno
Inclue:

Os itens de software a serem mantidos devem estar estipulados em

contrato
Deve ser elaborado um plano de manuteno acordado entre o fornecedor
e o comprador
O plano de manuteno deve considerar: escopo da manuteno,
identificao do status inicial do produto, a organizao de suporte, as
atividades de manuteno, os registros e relatrios de manuteno
O fornecedor e o comprador devem estar de acordo quanto incorporao
de mudanas em um software em funo da necessidade de manter o
desempenho

6.1 - Gerncia de Configurao

Inclue:

O fornecedor deve desenvolver um plano de gerncia de configurao que

compreende: organizaes e responsabilidades correspondentes relativas
gerncia de configurao, atividades a serem desempenhadas,
ferramentas,tcnicas e metodologias a serem usadas e o estgio no qual
os itens de software devem entrar sob o controle da gerncia de
configurao
Procedimentos devem ser aplicados a fim de assegurar para cada verso
do software: as especificaes funcionais e tcnicas, todas as ferramentas
de desenvolvimento que afetam estas especificaes, todas as interfaces
com outros itens de software e hardware e todos os documentos e arquivos
de computador relacionados ao item de software
A identificao do item de software deve propiciar o relacionamento com os
requisitos estabelecidos em contrato
Para produtos entregues, deve ser demonstrada a capacidade de
rastreabilidade
O fornecedor deve estabelecer e manter procedimentos para identificar,
documentar, revisar e autorizar quaisquer mudanas no software sob
controle da gerncia de configurao
As mudanas devem ser notificadas aos envolvidos
 O fornecedor deve estabelecer e manter procedimentos para registrar,
gerenciar e comunicar o status dos itens do software, as solicitaes de
mudanas e a implantao das mudanas aprovadas

6.2 - Controle da Documentao

Inclue:

O fornecedor deve estabelecer e manter procedimentos para controlar

todos os documentos relativos a esta parte da ISO 9000, compreendendo:
a determinao dos documentos sujeitos a procedimentos de controle de
documentos, a aprovao da emisso de procedimentos e procedimentos
de mudana de documentos

6.3 - Registros da Qualidade

Inclue:

O fornecedor deve estabelecer e manter procedimentos para identificar,

coletar, indexar, arquivar , armazenar, manter e disponibilizar os registros
da qualidade

Os registros da qualidade devem ser mantidos para demonstrar o

atingimento da qualidade requerida e a operao efetiva do sistema da
qualidade
Registros da qualidade relativos a sub-contratados tambm devem ser
mantidos
Os registros da qualidade devem ser protegidos contra deteriorizao ou
danos
Tempos de reteno dos registros da qualidade devem ser estabelecidos

6.4 - Medies
Inclue:

Mtricas devem ser usadas para gerenciar o processo de desenvolvimento

e de entrega e devem ser relevantes para o produto especfico de software
O fornecedor deve coletar dados e reportar os valores das mtricas em
base regular, identificar o nvel atual de desempenho a partir das mtricas,
tomar aes corretivas se o nvel da mtrica variar em relao aos nveis
alvos especificados e estabelecer metas de melhoria em funo das
mtricas
O fornecedor deve possuir medies quantitativas da qualidade dos
processos de desenvolvimento e de entrega
Essas mtricas devem refletir quo bem o processo de desenvolvimento
est sendo conduzido em termos de pontos de controle (milestones) ,
objetivos de qualidade e qual a efetividade do processo na reduo de
defeitos

6.5 - Regras,Prticas e Convenes

Inclue:
 O fornecedor deve prover regras, prticas e convenes para a operao
desta parte do sistema da qualidade

6.6 - Tcnicas e Ferramentas

Inclue:

O fornecedor deve usar ferramentas, facilidades e tcnicas para que a

operao desta parte do sistema da qualidade seja efetiva

6.7 - Compras
Inclue:

O fornecedor deve garantir que produtos ou servios comprados estejam

em conformidade com os requisitos especificados
Documentos de compra devem conter dados que descrevam claramente os
produtos ou servios comprados
O fornecedor deve avaliar sub-contratados com base em suas habilidades
para atender os requisitos da sub-contratao
Registros de sub-contratados aceitveis devem ser mantidos
O fornecedor responsvel pela validao do trabalho sub-contratado
Deve ser facultado ao comprador, avaliar produtos e servios comprados,
bem como sub-contratados

6.8 - Produto de Software Incluso

Inclue:

O fornecedor pode ser solicitado pelo comprador a incluir ou usar produto

de software fornecido por este ou por terceira parte
O fornecedor deve estabelecer e manter procedimentos para a
validao,armazenamento, proteo e manuteno de tais produtos
Produtos comprados pelo comprador e no adequados para uso, devem
ser registrados e notificados ao comprador
A validao pelo fornecedor no exime o comprador da responsabilidade
de prover produto aceitvel

6.9 - Treinamento
Inclue:

O fornecedor deve estabelecer e manter procedimentos para identificar as

necessidades de treinamento e prover o treinamento para todo o pessoal
que desempenha atividades que afetam a qualidade
O fornecedor deve manter registros apropriados sobre a realizao de
treinamento

Da mesma forma como o modelo SEI, o modelo ISO tambm serve de elemento
para a realizao de benchmarking.

No captulo 15 tambm colocamos um checklist pelo qual o leitor pode fazer a auto-
avaliao de sua organizao de desenvolvimento de software.
11.4 - Melhoria Contnua da Qualidade do Software

O processo de melhoria contnua baseia-se no ciclo PDCA - Plan - Do - Check -

Action.

O objetivo o aperfeioamento constante dos processos de planejamento de

projetos, desenvolvimento de software e gesto do produto.

A Figura 11-4 mostra o ciclo PDCA para a melhoria contnua.

Padronizar Indicadores
da qualidade

Identificao do
problema

A P

Analisar causas
Indicadores da
qualidade
C D
Contra-medidas

Efeito das contra-medidas Plano de ao

Adaptado de Arthur 1
Figura 11-4
 PLAN

O primeiro passo do ciclo de Deming o planejamento da melhoria , a partir da

determinao de objetivos de melhoria em relao aos processos de planejamento de
projetos, de desenvolvimento de software, gesto do produto ou em relao a
determinadas caractersticas do produto.

O planejamento realizado com as informaes coletadas em funo do

desempenho dos processos atuais. Este desempenho dado pelas medies respectivas
ou, como mostra a figura, pelos indicadores da qualidade.

Os indicadores fornecem informaes acerca de reas problemas ou com

potencial de aperfeioamento.

Durante o planejamento pode-se utilizar algumas das ferramentas da qualidade

como as Listas de Verificao, o Grfico de Pareto e o Diagrama de Causa-e-Efeito
(Ishikawa diagram).

A Figura 11-5 a seguir apresenta um exemplo de aplicao dessas ferramentas.

Folha de Verificao de Defeitos do Software
Mdulo 1 Mdulo 2 Mdulo 3 Total

Registros
de Defeitos

2 24 1 27
Defeitos do Software Por Tipo - Mdulo 2

Defeitos Frequncia Acumulada

100
95% 100%
85%
71%
50 56% 50%
25% 41%

0 25 16 15 15 14 10 10%

Diagrama de Causa e Efeito

Ambiente Pessoas Processo
inexperiente difcil de modificar
mudanas
novas
frequentes contrataes defeitos no
software
comunicao inadequada interrupo
de teste material de consulta
no disponvel

Figura 11-5
 Uma vez determinadas as principais causas dos problemas ou das variaes do
processo, devemos desenvolver contra-medidas eficazes para eliminar a recorrncia dos
problemas. Isto ocorre na fase do DO do ciclo de Deming.

DO

Nesta fase do ciclo de Deming, as contra-medidas (solues) para os problemas

identificados so desenvolvidas e implementadas.

A implementao dessas contra-medidas planejada em termos de recursos

necessrios, atribuies e responsabilidades pela implantao, custos previstos, aspectos
de gerncia,controle e monitoramento do projeto de melhoria.

CHECK

A verificao dos resultados da implementao das contra-medidas feita atravs

das medies operacionais e tticas.

Aqui tambm podemos utilizar o auxlio de outras ferramentas da qualidade, como

a carta de tendncia, o grfico de disperso e o grfico de controle, conforme o
exemplo dado pela Figura 11-6.

ACTION

Uma vez que os resultados so os esperados parte-se para padronizar o processo

conforme as melhorias implementadas e, principalmente sustentar a melhoria.

Na medida em que novos objetivos e metas de melhoria so estabelecidas, parte-

se novamente para rodar o ciclo de Deming e assim indefinidamente, aproveitando todas
as oportunidades de aperfeioamento.

Do ponto de vista do software a melhoria contnua deve concentrar-se

principalmente na qualidade, na produtividade, no custo e na satisfao dos
clientes/usurios.

Tambm podemos visualizar a aplicao do ciclo PDCA para aperfeoar a

exatido das estimativas, o planejamento anual de atendimento, o planejamento de
atendimento especfico, a qualidade do processo de atendimento e a qualidade do
produto ao longo de sua vida til.

Ou seja, as reas de aplicao candidatas a melhoria contnua podem

compreender desde o nvel mais elevado do modelo de gesto de software apresentado
neste livro at os seus elementos de maior nvel de detalhe.
 Carta de Tendncia

Defeitos
Defeitos do Software Por Semana
50

25

0
1 2 3 4 5 6 7 8 9 10 Semanas

LSC
Grfico de Controle

mdia

LIC

Taxa de Defeito
Grfico de Disperso

11.5 - Avaliao do Acervo de Software

A avaliao do acervo de software objetiva valorar este ativo da organizao,

visando fornecer para a administrao da companhia uma viso dos investimentos
realizados em desenvolvimento e manuteno, dando as condies necessrias para
avaliar o retorno do investimento.

O valor do acervo de software de uma empresa determinado multiplicando-se o

somatrio do tamanho de todos os software em pontos de funo pelo custo do ponto de
funo de desenvolvimento. Ou seja, quanto custaria para a empresa refazer todo este
acervo.

Da mesma forma, podemos determinar o valor do acervo para cada diviso ou

departamento da empresa, os quais so os gestores dos respectivos software ou maiores
usurios.

Esta demonstrao pode ser realizada de forma grfica para fins de compreenso
gerencial.
 Talvez o aspecto mais importante da avaliao estratgica seja a medio do
retorno dos investimentos em desenvolvimento de software.

Geralmente isto possvel caso tivermos registros quantitativos em relao aos

processos empresariais que passam por um processo de automao. Registros estes em
termos de custos , ciclos de tempos de processamento etc.

Conforme for o processo empresarial pode-se realizar medies.

Por exemplo, um software que permite alterar profundamente o processo de venda

de uma empresa, o resultado pode ser determinado pelo aumento percentual de vendas
relativamente ao perodo antes da introduo da nova sistemtica.

Outro exemplo a melhoria de servios, pela eliminao de etapas em um

processo empresarial. Em bancos, a reduo do tempo de anlise e concesso de crdito
melhora o atendimento, com reduo de custo do processo.

A automao industrial melhora a flexibilidade da fabricao, aumentando a

qualidade dos produtos e produtividade do processo, com reduo de custos e dos custos
da qualidade.

Portanto, os elementos bsicos para medir o retorno dos investimentos em

software existem. A necessidade que sejam medidos a fim de que as melhorias no
negcio sejam percebidas atravs de fatos e dados.

A partir do prximo captulo, nossa discusso muda para mostrar aspectos que
julgamos fundamentais para a efetiva implantao de medies no ambiente de
desenvolvimento de software.

REFERNCIAS

1. ARTHUR, Jay Lowel. Improving Software Quality: an insiders guide to TQM. Wilwy &
Sons, New York, 1993.

2. CAMP,Robert. Benchmarking; the search for industry best practices that lead to
superior performance. ASQC Quality Press, Milwaukee,Wisconsin,1989.

3. ISO 9000-3 : 1991. Quality Management and Quality Assurance Standards -

guidelines for the application of ISO 9001 to the development,supply and
maintenance o software. International Organization for Standardization.

4. HUMPHREY,Watts. Managing the Software Process. Addison-Wesley

Reading,MA,1990.

5. KEARNS,David. T. Quality Improvement Begins at the Top. Jerry Bowles,Ed. World

20,No. 5 (May,1986) 21
6. LAMPRECHT,James. ISO 9000 e o Setor de Servios. Qualitymark Editora,Rio de
Janeiro,1994.
Captulo
12
VENDENDO E IMPLANTANDO UM
PROGRAMA DE QUALIDADE DE
SOFTWARE

Como qualquer inovao que se pretenda introduzir em uma organizao, um Programa

de Qualidade de Software requer cuidados especiais, principalmente em uma cultura
como a brasileira, cujo planejamento e viso de longo prazo no se constituem em
virtudes.

Na verdade este tipo de inovao requer aes no sentido de Planejar a Venda

do Programa, Vender o Programa, Planejar a Implantao do Programa,
Implement-lo, Gerenci-lo e Mant-lo/Aperfeio-lo.

Por Planejar a Venda estamos considerando as seguintes aes:

Selecionar o nvel de medio em funo dos Modelos de Processo em

utilizao ou que seja praticvel medir
Determinar os objetivos que se pretende atingir com a medio e portanto
selecionar as mtricas
Aplicar as medies em um projeto-piloto para evidenciar benefcios
Pesquisar os casos bem sucedidos de implantao de programas dessa
natureza oriundos de outras empresas
Determinar o mercado alvo ou segmentos que se pretende vender a
inovao
Arranjar o patrocnio para a inovao
Conseguir o apoio dos formadores de opinio, tanto internos como externos
rea de informtica
Elaborar o material de venda

Vender o Programa envolve:

Aplicar palestras de sensibilizao conforme o segmento do mercado

Mostrar ao vivo se possvel ,os casos bem sucedidos
Mostrar os resultados do projeto piloto
Evidenciar a relao custo/benefcio do esforo de medio

Planejar a Implantao compreende:

Definir as estratgias de implantao

Definir as atividades e sua sequncia lgica para a implantao do
Programa
Definir os recursos necessrios
Definir as responsabilidades pelo Programa
 Definir a estrutura de coordenao do projeto de implantao do programa
Definir o oramento financeiro necessrio
Definir os pontos de controle do projeto
Definir o cronograma de desembolso

Implementar o Programa compreende o desenvolvimento do projeto.

Gerenciar a implantao do Programa abrange:

Refinar o planejamento inicial

Gerenciar as mudanas
Replanejar o projeto
Aplicar e manter os conceitos ticos
Acompanhar o progresso do projeto
Avaliar os resultados intermedirios e final do projeto
Realizar o acompanhamento fsico-financeiro do projeto

Por fim, manter e aperfeioar o Programa contempla:

Utilizar os resultados das medies para tomar aes efetivas visando a

melhoria da qualidade e produtividade
Disseminar constantemente os resultados, tornando pblico os benefcios e
melhorias obtidas
Educar continuamente os integrantes dos vrios segmentos do mercado
Aperfeioar o Processo de Software pela introduo do Modelo W, mais
detalhado, e aplicar as medies neste nvel
Introduzir ferramentas de apoio mais avanadas
Realizar benchmarking contnuo

Como o leitor observou, todo o esforco de implantao de um Programa de

Qualidade encarado aqui como um projeto, cujas fases so justamente o Planejamento
da Venda, a Venda, o Planejamento da Implementao, a Implementao e a
Manuteno/Aperfeioamento.

Estas fases so uma consequncia natural da introduo de uma inovao em

uma organizao. No caso especfico de um Programa de Qualidade de Software, o
objetivo evitar os erros que so comuns na implementao, quais sejam:

A gerncia no estabelece claramente os propsitos do Programa e mais

tarde v as medies como irrelevantes
Profissionais de sistemas resistem ao Programa, pois o percebem como
forma de control-los e de gerar comentrios negativos sobre seu
desempenho
Geralmente equipes de projeto que j se encontram sobrecarregadas so
prejudicadas com tarefas extensivas e adicionais de coleta de dados
referente s medies
Os resultados das medies no geram ao gerencial
 Um aviso importante neste momento que um modelo de Venda e Implantao
de um Programa de Qualidade de Software como o apresentado aqui, e que ser
detalhado mais adiante, no est considerando peculiaridades de ambiente, clima
organizacional e cultura que existem em cada empresa.

Deve-se portanto, analisar criticamente este modelo de forma que seja adaptado
realidade de cada empresa.

12.1- Planejando a Venda do Programa de Qualidade de Software

Seleo do Nvel de Medio

Aps a deciso de implementar o Programa de Qualidade , o primeiro passo

selecionar o nvel de medio apropriado e, naturalmente, possvel.

Como estratgia sugerimos adoo de cautela mesmo que a empresa j possua

um Modelo do nvel W j em pleno funcionamento.

A medio neste nvel mais complexa e exige recursos de coleta e

monitoramento de projeto e processo mais sofisticados. Dificilmente se consegue realizar
coleta e anlise na mo quando se trabalha com modelos mais detalhados.

Caso a empresa j esteja madura e com as ferramentas necessrias disponveis,

pode selecionar o nvel mais detalhado. Um fator importante neste caso e que pode
contribuir para esta deciso a existncia de cultura corporativa que incentive a medio
de processos. Isto geralmente encontrada em organizaes que experimentam ou j
experimentaram Programas de Qualidade Total.

Se no for esta a situao da sua empresa, o modelo Universal pode ser o mais
apropriado.

Outra considerao a ser feita que o custo de coleta e anlise das medies no
deve exceder os benefcios ou economias/melhorias a serem obtidas com o Programa.

Determinao de Objetivos

Quais so os objetivos que a sua empresa deseja atingir com um Programa de

Qualidade de Software?

Alguns objetivos mais comuns so:

Aperfeioar o planejamento de projetos

Aumentar a capacidade de detectar defeitos
Aumentar a confiabilidade do software
Diminuir a densidade de defeitos do software
Melhorar os servios prestados aos usurios/clientes

Reduzir os custos de no-conformidade

Aumentar a produtividade do desenvolvimento, manuteno e
aperfeioamento do software
 Minimizar o esforo e prazos de desenvolvimento
Reduzir os custos de retrabalho no processo
Reduzir os custos de falhas externas
Aperfeioar os mtodos de estimativas de projetos
Aperfeioar os mtodos de gesto dos projetos
Determinar tendncias relativas a atributos do processo
Aperfeioar o processo de software

Os objetivos a serem definidos dependem, geralmente:

Das classes de software que so desenvolvidos na empresa, ou seja,

sistema operacional, sistemas de misso crtica ( controle de trfego areo
um exemplo), sistemas de tempo-real, sistemas interativos ( sistemas de
apoio a combate em caas supersnicos) e sistemas de aplicao
comercial.

Por exemplo, em sistemas operacionais, de misso crtica e de tempo-real

,a confiabilidade e desempenho so fatores crticos. Neste caso alguns
objetivos da medio podem ser: aperfeioar o processo de inspeo
formal de software, melhorar o nvel de cobertura dos testes e assim
sucessivamente.

Empresas que so caracterizadas como de informao intensiva, caso de

seguradoras e bancos, cujos produtos so na realidade software,
necessitam melhorar a produtividade do desenvolvimento e melhoria de
seus sistemas haja visto a intensa competio e possuir sistemas flexveis
em termos de manuteno.

Empresas que se dedicam ao desenvolvimento de software sob medida

para terceiros, necessitam reduzir os custos de retrabalho e de falhas
externas, bem como realizar estimativas de prazos e custos mais apuradas

Empresas que desenvolvem software-produto, tipo commodity necessitam

reduzir os custos de falhas externas e controlar as diversas verses dos
produtos.

Selecionar as Mtricas

Uma forma interessante de determinar quais mtricas utilizar em funo dos

objetivos nos dada por Basili 1 com o Goal/Question/Metric Paradigm ou
paradigma da meta/questo/mtrica.
O princpio deste paradigma :

Cada organizao ou projeto tem objetivos

Para cada objetivo h um conjunto de questes que se pode formular a fim
de verificar o atingimento do objetivo
Muitas destas questes tm respostas que podem ser mensuradas
Os resultados destas mensuraes, ao fornecer respostas s questes,
podem determinar at que ponto o objetivo est ou foi atingido

A Figura 12-1 mostra o relacionamento entre os componentes do paradigma.

Objetivo 1 Objetivo 2

Questo 1 Questo 2 Questo 3

Mtrica 1 Mtrica 2 Mtrica 3 Mtrica 4

Figura 12-1
Exemplo de aplicao do paradigma:

Objetivo 1: Aperfeioar o Planejamento do Projeto

Questo 1.1: Qual foi a exatido da estimativa do prazo do projeto?

Mtrica 1.1: Exatido da Estimaiva de Prazo
Frmula da Mtrica:

EEP = Durao Real do Projeto

Durao Estimada do Projeto

Questo 1.2: Qual foi a exatido da estimativa do esforo do projeto?

Mtrica 1.2: Exatido da Estimativa de Esforo
Frmula da Mtrica:

EEE = Esforo Real do Projeto

Esforo Estimado do Projeto

Vide aplicao deste paradigma pela Motorola .

 Defina portanto seus paradigmas.

Aplicao de Medies em Projetos-Piloto

A venda de um Programa de Qualidade de Software ser mais efetiva caso

possamos apresentar exemplos concretos oriundos da prpria empresa.

Para tanto recomendvel que o paradigma estabelecido seja aplicado em um

projeto-piloto, de preferncia de pequeno porte, cujo gerente tenha esprito inovador e
aceite a experimentao sem resistncias.

Em qualquer empresa encontramos pessoas com estas caractersticas.

Em empresas de grande porte, com vrios centros de desenvolvimento, este

processo pode levar alguns anos 5.

Os resultados da medio serviro de argumento para a venda do Programa.

Pesquisar os Casos Bem Sucedidos

No Brasil, infelizmente, no temos conhecimento da aplicao de um Programa de

Qualidade de Software de forma extensiva.

Entretanto organizaes como a CSC 2, Motorola 3, HP 6, GE 4, j

implementaram e mantm Programas desta natureza.

Estes casos tambm devem compor o material de venda.

importante tambm que os profissionais envolvidos no Programa participem de

congressos e seminrios no Brasil e exterior sobre o tema.

Um importante forum de discusso sobre Programas de Mtricas o IFPUG.

Determinar o Mercado Alvo

Em qualquer trabalho de marketing, visando o lanamento de um produto, um

passo primordial a definio dos segmentos de mercado que se pretende atuar.

No caso de um Programa de Qualidade de Software, podemos visualizar os

seguintes segmentos alvos:

Alta Administrao da Empresa

Este segmento est interessado no desempenho das atividades de

desenvolvimento/manuteno de software em termos de qualidade ( que
significa menores custos), produtividade, custo e apoio aos negcios da
corporao, bem como avaliar decises de investimentos em termos de
desenvolvimento de novos produtos, desativao de produtos, substituio
e melhoria.
 Gerentes Funcionais

Este segmento est interessado na qualidade ( desempenho,

confiabilidade e funcionalidade ) dos software que apoiam seus processos
ou negcios.

Gerncia da Tecnologia da Informao

Este segmento, composto pelo gerente da rea, gerente de

desenvolvimento e demais gerentes , est interessado no aperfeioamento
contnuo do processo de desenvolvimento.

Gerentes de Software/Projetos

Este segmento est interessado no controle e aperfeioamento dos

projetos especficos sob sua responsabilidade.

Engenheiros de Software/Analistas

Este segmento est interessado no controle e melhoria de atividades

especficas do projeto no qual participa.

Arranjar o Patrocnio

No h possibilidade de sucesso da implantao do Programa de Qualidade de

Software se o principal executivo da rea de tecnologia da informao no se
comprometer com o projeto e os esforos de medio ficarem restritos a alguns projetos e
no forem sistemticos.

Comprometimento significa engajamento efetivo, persistncia, dedicao, dar o

exemplo, exigir que o planejamento seja cumprido , alimentar seu processo de deciso
com os resultados das medies preliminares, apoiar publicamente os esforos da equipe
do projeto.

Em alguns casos preciso ser missionrio.

Outro aspecto importante quanto ao funding do projeto, ou seja, como a

implantao do Programa ser financiada.

Dependendo da extenso do Programa e de seu porte, a alada do gerente de

tecnologia da informao pode ser ultrapassada.

Nesta situao somente o comprometimento do gerente no basta. preciso o

patrocnio de um alto executivo da companhia ou seja o executivo campeo.

Trabalhar os Formadores de Opinio

 Os formadores de opinio so pessoas respeitadas por sua expertise na rea
tcnica e que exercem influncia pronunciada sobre o principal ncleo de gerentes da
empresa ou da rea de informtica.

Muitas vezes apresentam postura extremamente crtica para com idias ou grupos
alheios a sua rea de influncia, mas, uma vez convencido da relevncia de um dado
projeto, torna-se um dedicado e leal campeo daquela causa. Serve como fonte de
informaes e referncia dentro da organizao ( sabe o que foi feito no passado, por
quem, e sabe indicar facilmente com quem voc deve falar), alm de intermediar
comunicao informal entre diversas unidades da empresa.

O recado aqui : conquiste o mximo de aliados.

Elaborar o Material de Venda

O material de venda deve ser elaborado visando as audincias (segmentos) que

se pretende atingir.

Lembrando que os interesses desses segmentos so distintos, o material deve ser

elaborado de acordo.

O material de venda pode ser baseado em transparncias ou pela utilizao de

algum software de apresentao (presentation) . Neste caso recomendvel o uso de
canho ou datashow , de preferncia colorido.

Para que a platia tenha o registro da apresentao, pode-se fornecer fotocpias

do material.

Durante a manuteno do Programa pode-se utilizar outros tipos de materiais de

venda .

O material de venda deve ter bons argumentos . Estes argumentos devem ir ao

encontro dos respecitvos interesses do mercado.

Podemos elaborar dois tipos de materiais, um para ser apresentado Alta

Administrao e Gerentes Funcionais e outro para os Gerentes e Engenheiros de
Software .

O contedo sugerido do material para a Alta Administrao ( considere cada tpico

como uma transparncia ou slide) apresentado a seguir.(Vide tambm o material
utilizado pela HP 6 para realizar a venda de seu Programa de Mtricas)

Agenda da Apresentao
Apresentar a estrutura da apresentao e informar o tempo de durao.

Programa de Qualidade de Software:

O que ? Quais os benefcios para a empresa? Qual a estratgia de
implantao?
Introduzir as questes que devero ser respondidas no decorrer da
apresentao

Os Objetivos Pretendidos Com o Programa de Qualidade

Apresentar os objetivos selecionados para serem atingidos com o
Programa, enfatizando os aspectos qualidade, produtividade e custos
(viso econmica da gesto do software)

Quais as Mtricas Escolhidas Para Evidenciar o Atingimento dos

Objetivos
Apresentar as mtricas que devero ser empregadas e em que nvel.

Resultados Preliminares em Projeto-Piloto

Apresentar os resultados conseguidos com as mtricas selecionadas no
projeto-piloto ,evidenciando os benefcios atingidos para a melhoria da
qualidade, produtividade e reduo de custos de desenvolvimento.Mostrar
os resultados atravs de grficos para melhor compreenso da platia.

As Melhores Prticas na Indstria

Apresentar as melhores prticas na indstria tais como GE ,HP e como,
atravs das mtricas, estas empresas conseguiram gerenciar projetos,
processo e produto e benefcios conseguidos.

Emprego Estratgico das Mtricas

Mostrar como as mtricas podem auxiliar alta gerncia e os negcios em
termos de benchmarking , melhoria contnua do processo de software e
avaliao econmica do acervo de software da empresa. Deve ser
mostrado o impacto na qualidade dos produtos e servios da empresa e se
possvel, os ganhos financeiros possveis de serem obtidos.

Informaes Gerenciais
Apresentar os relatrios e grficos gerenciais a serem periodicamente
produzidos para a alta administrao.

Planejamento Preliminar da Implantao

Mostrar o planejamento da implantao, prazos e recursos necessrios.
Evidenciar tambm a estratgia de implantao.
 Estimativas de Investimentos Necessrios
Apresentar os investimentos a serem realizados e detalh-los a nvel de
um cronograma de desembolso conforme o prazo de execuo do projeto.

O contedo para os gerentes e engenheiros de software necessita ter uma

abordagem mais tcnica e conceitual. Nossa sugesto a adoo do roteiro a seguir
apresentado.

Agenda da Apresentao
Apresentar a estrutura da apresentao e informar o tempo de durao.

Programa de Qualidade de Software:

O que ? Quais os benefcios para a empresa? Qual a estratgia de
implantao?
Introduzir as questes que devero ser respondidas no decorrer da
apresentao

Os Objetivos Pretendidos Com o Programa de Qualidade

Apresentar os objetivos selecionados para serem atingidos com o
Programa, enfatizando os aspectos qualidade, produtividade e custos
(viso econmica da gesto do software)

Conceitos de Qualidade de Software

Apresentar os conceitos bsicos de qualidade de software e evidenciar a
necessidade por medies.

Resultados Preliminares do Projeto-Piloto

Apresentar os resultados conseguidos com as mtricas selecionadas no
projeto-piloto ,evidenciando os benefcios atingidos para a melhoria da
qualidade, produtividade e reduo de custos de desenvolvimento.Mostrar
os resultados atravs de grficos para melhor compreenso da platia.

As Melhores Prticas na Indstria

Apresentar as melhores prticas na indstria tais como GE ,HP e como,
atravs das mtricas estas empresas conseguiram gerenciar projetos,
processo e produto e benefcios conseguidos.

Quais as Mtricas Escolhidas Para Evidenciar o Atingimento dos

Objetivos
Apresentar as mtricas que devero ser empregadas e em que nvel.

Medies Estratgicas ,Tticas e Operacionais

Mostrar como as mtricas devero ser utilizadas para fins de
gerenciamento do ambiente de software como um todo, os tipos de aes
possveis de serem tomadas e o apoio ao negcio da empresa.

Como as Mtricas Escolhidas Auxiliaro os Gerentes a Gerenciar os

Projetos e Processo de Desenvolvimento
Mostrar como cada mtrica definida auxiliar os gerentes em suas
atribuies. Mostrar quais os grficos possveis de serem empregados para
 a apresentao dos resultados das mtricas e para fins de tomada de
deciso gerencial. Detalhar o nvel operacional de medio.

Os Princpios ticos do Programa

Apresentar a regra do jogo no que tange utilizao das medies pelos
gerentes.

Planejamento Preliminar da Implantao

Apresentar como se dar a implantao do Programa e expor algumas das
responsabilidades a serem assumidas por membros da equipe.

Prximos Passos
Apresentar os prximos passos.

12.2 - Vendendo o Programa

A venda do Programa ou o momento da verdade , deve obedecer uma sequncia

lgica caracterizada por , em um primeiro momento , a apresentao da palestra de
sensibilizao Alta Administrao , caso o Programa for aprovado nesta instncia,
partir ento para o trabalho de venda aos gerentes e engenheiros de software.

O apoio concreto da Alta Administrao condio necessria para o sucesso do

projeto. Sem este apoio, qualquer esforo est fadado ao fracasso.

Quando do agendamento da palestra de sensibilizao devemos observar alguns

procedimentos:

Selecionar as pessoas que devero ser convidadas apresentao

Agendar com antecedncia a apresentao e enviar comunicao para os
participantes
Procurar realizar a apresentao em local cuja interrupo seja a mnima
possvel ( infelizmente hoje temos o celular )
No dia anterior apresentao certificar-se de que o material esteja em
ordem; se for utilizar projeo com datashow ou canho, testar os
equipamentos na vspera
Designar uma pessoa para realizar anotaes durante a apresentao,
visando registrar as questes colocadas pela platia, sugestes, crticas,
diretrizes e assim sucessivamente

Outras abordagens possveis de serem empregadas consistem em:

Usar o testemunho do gerente do projeto piloto

Mostrar ao vivo, se possvel , os resultados bem sucedidos de
implantao de Programas de Qualidade (Mtricas) de Software
Fazer com que o pessoal tcnico participe de congressos, encontros e
seminrios relativos ao tema

12.3 - Planejamento da Implantao

Definio das Estratgias de Implantao

 Conforme for o nvel de resistncia da equipe de gerentes e engenheiros de
software preciso estabelecer algumas estratgias para a implantao bem sucedida do
Programa.

Em uma situao deste tipo a abordagem gerar e aproveitar o efeito

demonstrao.

Iniciar a implantao pelos projetos cujos gerentes e engenheiros de software so

inovadores e apreciam as mudanas e vem num trabalho deste tipo , oportunidade de
crescimento profissional.

Com a disseminao dos primeiros resultados , a apreciao pela Alta

Administrao e com a consequente anlise comparativa entre os projetos controlados
(que utilizaram o modelo de qualidade) e os no controlados , comea-se a evidenciar o
caminho a ser seguido. muito provvel que as resistncias sero removidas com
sucesso.

Se a empresa utiliza servios terceirizados para o desenvolvimento de projetos de

software recomendvel que estes fornecedores sejam inseridos no mbito do Programa
de Qualidade.

Sempre quando possvel procurar adquirir software-produto disponvel no

mercado para apoio ao Programa, tais como: gerenciador de projetos, software de
estimativas, software para controle de custos da qualidade, banco de dados de mtricas e
assim sucessivamente.

A estratgia tambm deve definir os estgios de implantao do Programa, por

quais mtricas as primeiras medies sero realizadas, em que ponto a qualidade vai
comear a ser medida e assim por diante.

Definio do Roteiro de Implantao

impossvel elaborar o Planejamento da Implantao do Programa sem uma

sequncia lgica de atividades que configura um roteiro de trabalho a ser seguido durante
a implantao do projeto.

Este roteiro necessrio para estabelecer tempos , recursos a serem

empregados, responsabilidades, estrutura de coordenao do projeto, cronograma de
execuo , pontos de controle (reviso gerencial) do projeto e cronograma de desembolso
de recursos financeiros. Um exemplo de roteiro de implantao fornecido a seguir.
Tabela 12-1
ATIVIDADE
1.Estruturar a Equipe do Projeto
2. Capacitao em Mtricas e Qualidade
de Software
3. Seminrio Gerencial Sobre o Programa
de Qualidade
4. Capacitao em Function Points
5. Capacitao em Planejamento de Proje-
tos de Software
6. Capacitao na Aplicao das 7 Ferra-
mentas da Qualidade
7. Capacitao na Utilizao de Ferra-
mentas e Modelos Estatsticos
8. Capacitao em Inspeo em Software
9. Capacitao em Anlise e Complexidade
de Design
10. Avaliao do Processo de Software
11.Implementao de Melhorias no Proces-
so Atual
12.Estruturao do Ambiente Voltado Para
a Qualidade
13.Seleo de Produtos Disponveis no
Mercado
14.Implantao de Ferramentas
15.Desenvolvimento de Ferramentas
16.Implementar as Melhorias no Processo
17.Implementar as Medies
18.Disseminar o Programa da Qualidade
19. Acompanhamento do Programa
20. Publicar os Resultados do Programa
21.Disseminar o Modelo de Qualidade
Para as Empresas Contratadas
FINALIDADE DA ATIVIDADE
Designar pessoas para o projeto e atribuir
responsabilidades
Capacitar gerentes e engenheiros de software
na coleta e anlise das mtricas, bem como as
aes decorrentes
Conscientizar os gerentes funcionais quanto a
importncia do Programa
Capacitar gerentes e engenheiros de software na
aplicao da Anlise Por Pontos de Funo
Capacitar gerentes e engenheiros de software na
aplicao de mtodo e ferramentas de
estimativas de prazos,custos e recursos
Capacitar gerentes e engenheiros de software no
emprego das 7 ferramentas da qualidade a fim
de apoiar na soluo de problemas
Capacitar gerentes e engenheiros de software na
aplicao de ferramentas estatsticas para
anlises dos resultados de mtricas
Capacitar gerentes e engenheiros de software na
tcnica de inspeo formal de software
Capacitar gerentes e engenheiros de software na
anlise de complexidade do produto de software
em desenvolvimento
Determinar pontos fortes e fracos do processo de
software atual
Padronizar o processo atual e inserir tcnicas de
inspeo, testes etc.
Estruturao da funo de garantia da qualidade
Selecionar produtos disponveis no mercado para
a elaborao de estimativas e controle da quali-
dade de software
Implantao das ferramentas disponveis no
mercado
Desenvolver ferramentas complementares para
apoio ao Programa
Implementar nos novos projetos as melhorias no
processo
Implementar as medies nos novos projetos
Implementar o modelo da qualidade a nvel das
manutenes e melhorias de software
Acompanhar a implantao do Programa e ava-
liar os resultados
Publicar os primeiros resultados positivos do
Programa
Disseminar ou desenvolver os fornecedores da
empresa caso houver
 Definir os Recursos Necessrios

Os recursos para a implantao de um Programa de Qualidade de Software

podem incluir:

Recursos Humanos
Neste item devem ser considerados:

Gerente/Coordenador do projeto
Equipe de apoio tcnico do projeto
Alocao do tempo dos demais profissionais nas atividades de
treinamento e capacitao e implantao das mtricas nos projetos

Recursos de Software
Compreendem:

Gerenciador de projetos
Ferramenta de estimativa
Ferramenta de monitoramento de defeitos (defect tracking)
Ferramenta estatstica
Banco de dados de projetos e mtricas
Ferramenta para controle de custos da qualidade
Ferramenta para controle de aes corretivas

Recursos Ambientais e Materiais

Compreendem espao fsico para a equipe do projeto, materiais de
consumo, servios de documentao e assim sucessivamente.

Treinamento
Cursos de capacitao , seminrios (internos ou externos), participao em
congressos, encontros etc.

Recursos de Hardware
Para utilizao das ferramentas de software e para apoio s
apresentaes, treinamentos e documentao do projeto.

Servios Externos
Consistem em servios de consultores externos e desenvolvimento de
software sob medida para apoiar o Programa.

Outros Servios
Consistem em servios de transportes ( terrestre e areos), alimentao
etc.
 Definir as Responsabilidades e Estrutura de Coordenao

Um projeto como a implantao do Programa de Qualidade de Software requer

que as responsabilidades sejam claramente definidas em relao estrutura de
coordenao e s pessoas que realizaro as medies operacionais.

A estrutura de coordenao do projeto o forum de resoluo de conflitos e

pendncias, bem como a instncia que define diretrizes, avalia e homologa produtos
intermedirios , autoriza o replanejamento do projeto e define a alocao e a realocao
de recursos ao projeto.

A composio desta estrutura depende do porte e extenso do Programa e,

naturalmente, da importncia para a empresa.

Quanto maior o porte, a importncia e os recursos destinados ao Programa,

aconselhvel que a coordenao geral fique no mais alto nvel da empresa ou que tenha
acesso Alta Administrao.

Este conceito bsico para o gerenciamento de qualquer tipo de projeto, mesmo

no sendo orientado implantao de Programa da Qualidade.

No nvel de execuo propriamente, as seguintes responsabilidades devem ser

definidas:

Quem tem a responsabilidade pela coleta das informaes sobre as

medies
Quem tem a responsabilidade pela manuteno dos registros de coleta
Quem tem a responsabilidade pela anlise das medies
Quem tem a responsabilidade pela manuteno dos registros das
medies
Quem tem a responsabilidade pelo relato das anlises
Quem encaminha as aes necessrias em funo dos resultados das
medies

Definio dos Pontos de Controle

Os pontos de controle de um projeto geralmente esto associados a produtos

intermedirios, 100% inspecionveis, e que evidenciam o seu progresso .

Dessa forma, ao elaborar o roteiro de implantao do projeto, identificar como

ponto de controle, quelas atividades que compem o caminho crtico.

As revises gerenciais, objeto de reunies de progresso, devem ser agendadas

conforme os pontos de controle previstos.
 Elaborao do Oramento do Projeto

Uma vez que os recursos necessrios e o cronograma de execuo, com datas de

incio e trmino para cada atividade, foram definidos, pode-se elaborar o oramento
financeiro do projeto e o consequente cronograma de desembolso, ou seja, quanto vai ser
despendido mensalmente em termos monetrios pelo projeto, para fins de gerenciamento.

12.4 - Gerenciando a Implantao do Programa

A gerncia de projetos baseia-se em alguns princpios universais os quais so

relatados neste tpico.

Monitoramento do Progresso do Projeto

Que compreende a realizao de reunies peridicas de avaliao dos

trabalhos e de reviso gerencial conforme os pontos de controle, nas quais
participem os membros da equipe de coordenao do projeto e no preparo
de relatrios de posicionamento para serem distribudos aos integrantes da
administrao da companhia.

Este monitoramento deve abranger no s a consecuo fsica do projeto

como tambm financeira.

Gerenciamento de Mudanas

Em qualquer tipo de projeto ocorrem contigncias, as quais so

ocorrncias de eventos que podem impactar negativamente o projeto em
termos de prazo e custo.

Alteraes de escopo so comuns, assim como o no atendimento da

programao de alocao de recursos.

As ocorrncias de contingncias, voluntrias ou no, devem ser analisadas

quanto ao seu impacto no projeto.

Caso houver impacto em prazos e consequentemente em custos, o projeto

deve, necessriamente , sofrer um replanejamento. No d para fingir que
nada aconteceu e pensar que o tempo ser recuperado nas etapas
seguintes do projeto. Isto um dos maiores erros que os gerentes de
projetos podem cometer, pois em processos de implantao de inovao,
cuja aprendizagem ocorre durante o desenvolvimento do projeto, o tempo
jamais recuperado.

Nesta situao o mais correto negociar com a administrao da

companhia ou a gerncia de tecnologia da informao este replanejamento.
 Para tanto imprescindvel a constituio de um dossi gerencial do
projeto com o registro de todos os fatos e a evidncia de anlises de
impacto.

Comprometimento Com Princpios ticos

Os princpios ticos de conduta devem ser mantidos a qualquer custo, sob

pena do projeto tornar-se um retumbante fracasso. Na medida em que os
princpios no so seguidos, o pessoal que tem a responsabilidade por
coletar dados e analisar os resultados das medies comear sabotar
todo o esforo.

Gerenciar projetos tambm uma de instruo contnua das pessoas

envolvidas com o mesmo.

Avaliao dos Resultados

Avaliar resultados intermedirios possibilita ao imediata para

reestabelecer a qualidade dos produtos que esto sendo gerados pelo
projeto evitando comprometer a credibilidade do mesmo.

Sempre h possibilidade para aperfeioar o prprio processo de

desenvolvimento do projeto e corrigir seus rumos.

Em um Programa de Qualidade de Software no existem resultados finais

absolutos pois a qualidade tambm no algo absoluto. Podemos
considerar estgios de qualidade dentro de um espao de tempo.

Portanto, objetivos quantitativos de qualidade devem ser estabelecidos

como metas para um perodo de tempo pr-determinado.

Os resultados de um Programa de Qualidade de Software devem ser

considerados sob esta tica.

Ao final do projeto Programa da Qualidade de Software , deve-se avaliar

o atingimento dos objetivos propostos para o perodo de durao do
mesmo e realimentar o processo para evoluir a fase seguinte do Programa
que a partir da passa a ser um esforo permanente de melhoria contnua
da qualidade.

12.5 - Manuteno e Melhoria do Programa de Qualidade de Software

Ao terminarmos a fase de implantao do Programa , iniciamos a parte mais difcil

que mant-lo , nutr-lo e aperfeio-lo.

Algumas estratgias bsicas sugeridas so:

 Aperfeioar o Processo de Software pela introduo do Modelo W , mais
detalhado, e aplicar as medies neste nvel, visando obter as condies
para o gerenciamento efetivo de projetos, processo e produto.

Educar e retreinar continuamente os integrantes dos vrios segmentos do

mercado. Na medida em que o processo de software se sofistica, com le
se sofistica o nvel de medio, as mtricas e as metas de qualidade.

Disseminar constantemente os resultados das medies, apresentando os

benefcios concretos e melhorias obtidas. Uma alternativa realizar
encontros internos sobre Qualidade de Software , editar jornalzinho ou
relatrios tcnicos.

Introduzir ferramentas de apoio mais avanadas. Por exemplo, ferramentas

como o Checkpoint desenvolvida pela Software Productivity Research,
empresa pertencente Capers Jones 8, permite realizar estimativas
completas a partir do tamanho de pontos de funo do software.

O leitor deve ter percebido que colocamos uma nfase exagerada neste captulo.
Foram dezoito pginas. Entretanto, de que adiantaria falarmos o tempo todo sobre
mtricas se no houvessem as explicaes necessrias de como implant-las numa
organizao?

REFERNCIAS

1. BASILI,V & WEISS,D. A Methodology for Collecting Valid Software Engineering

Data.IEEE Transactions on Software Engineering, Vol SE-10,No. 6 ,nov 1984.

2. BELDEN, Andy. Managing With Metrics. IV Encontro Nacional de Usurios de Pontos

de Funo. IBPI, Rio de Janeiro, 1993.

3. CARD,David . Engenharia da Qualidade de Software. IBPI, Seminrio,Rio de

Janeiro,1993.

4. DASKALANTONAKIS,Michael. A Practical View of Software Measurement and

Implementation Experiences Within Motorola.IEEE Transactions on Software
Engineering,Vol 18, No. 11, November 1992.

5. GRADY, R. & CASWELL,D.L. Software Metrics: Establishing a Company-Wide

Program. Prentice-Hall, Englewood Cliffs, New Jersey,1987.

6. GRADY,R . Practical Software Metrics for Project Management and Process

Improvement. Prentice-Hall, Englewood Cliffs, New Jersey, 1992.

7.JONES,Capers. Applied Software Measurement.McGraw-Hill,New York,1991.

Captulo
13
TICA NA UTILIZAO
DOS RESULTADOS DAS
MEDIES

Apesar dos amplos benefcios que podem ser obtidos com a utilizao das mtricas para
o gerenciamento dos projetos e produtos de software, h um item extremamente sensvel
que deve ser levado em considerao e que, se negligenciado, pode conduzir ao fracasso
tentativas bem intencionadas de medies.

O item sensvel ao qual estamos nos referindo o fator humano. Isto significa que
algumas polticas corporativas devem nortear a forma como os dados das medies
devem ser coletados e analisados a fim de no ferir suscetibilidades pessoais que
possam comprometer todo o esforo de implementar e manter um programa de mtricas.

Neste contexto fundamental que a gerncia estabelea quais as informaes

que devem ser mantidas a nvel de cada projeto e aquelas que podem ser divulgadas de
forma mais ampla, tendo em vista as vrias audincias contempladas com os resultados
das medies.

Entretanto , esta somente uma das atitudes requeridas da gerncia. A outra e

talvez a mais importante o comprometimento na manuteno de algumas regras
visando a implantao e evoluo de um esforo de medio mais amplo.

O princpio bsico que norteia as regras, cujo conjunto deve orientar o

comportamento tico da gerncia e das equipes de desenvolvimento, fundamenta-se no
que podemos considerar um axioma enunciado por Deming :

85% dos problemas que ocorrem nos processos da empresa de

responsabilidade da gerncia.

Consequentemente a medio jamais deve avaliar desempenhos individuais e

sim enfocar processos e produtos os quais so desempenhados por equipes.

O primeiro passo para adotarmos certas regras determinar quais informaes

devem ser mantidas no nvel restrito do indivduo , no nvel da equipe do projeto, no nvel
do departamento de informtica e no nvel da alta gerncia da empresa.

O segundo passo a implantao das regras de conduta em si.

Estes dois aspectos que definem o que denominamos de tica na utilizao das
medies.
11.1 - Nveis de Privacidade dos Resultados das Medies

Os nveis de privacidade so basicamente quatro, quais sejam:

O indivduo
A equipe de desenvolvimento
O departamento de informtica
A alta gerncia da empresa

Nvel de Privacidade- o Indivduo

Como o objetivo no medir o desempenho individual , toda e qualquer

informao que, de alguma maneira, tenha a probabilidade de ser utilizada de
forma prejudicial a uma pessoa deve ser privada a ela. Neste caso podemos
incluir:

Taxas de defeitos do indivduo

Nmero de compilaes efetuadas pelo indivduo
Produtividade pessoal medida
Tempo mdio de atendimento do indivduo para solicitaes de
manuteno

A privacidade neste nvel significa no medir qualquer um deste elementos.

Nvel de Privacidade - Equipe do Projeto

Grande parte das mtricas de projeto e produto ( operacionais), conforme

relacionadas no Captulo 3 , devem ser privativas da equipe do projeto, pelo
menos durante o desenvolvimento do software ou da implementao de
releases e serem compartilhadas somente pelo gestor da rea de
desenvolvimento e/ou pelo responsvel pela rea de informtica.

Dessa forma evita-se o constrangimento da prpria equipe em relao ao

desempenho das outras ou, ao contrrio.

Tais informaes podero ser registradas em um Banco de Dados para futura

pesquisa por outras equipes porm, deve-se determinar o tempo em que podero
ser liberadas. A idia aqui que tanto as experincias bem sucedidas ou no ,
realimentem o planejamento da melhoria da gesto dos projetos, dos produtos e
do processo de desenvolvimento.

Neste caso podemos dar a liberdade para as equipes efetuarem medies

especficas , de seu prprio interesse, que as auxiliem no monitoramento dos
objetivos do projeto.

De acordo com a prtica da HP, muito bem relatada por Grady no

planejamento do projeto ou da release, quando so estabelecidas quais
informaes devero ser coletadas, a equipe fica mais confortvel em tornar os
resultados pblicos e aceita mais facilmente ser avaliada conforme as mtricas
inicialmente estabelecidas.
 Nvel de Privacidade - Departamento de Informtica

As informaes sobre o desempenho dos projetos conforme os padres

estabelecidos ou anlises comparativas entre projetos, somente do interesse
do responsvel pela rea de informtica e do desenvolvimento.

Entretanto, informaes acerca das medies tticas : anlise de tendncias,

anlise de impactos e anlise de atributos , podem ser pblicas a nvel do
departamento a fim de que todos os gerentes de projeto e produtos possam
beneficiar-se das informaes no sentido do aprimoramento contnuo.

Nvel de Privacidade - A Alta Gerncia da Empresa

As medies estratgicas , cuja principal audincia a alta administrao da

empresa, podem ser pblicas a este nvel com o conhecimento bvio da gerncia
do Departamento de Informtica.

Entretanto, como so informaes de carter estratgico, no devem ser

disponveis para outras gerncias funcionais e divulgadas de forma detalhada
para fora da empresa.

Esta atitude recomendvel para aquelas empresas cujo software o principal

insumo do processo de gerao de bens e servios e que lhes propiciam
diferenciao mercadolgica.

11.2 - Regras de Conduta Para a Utilizao das Medies

Apresentamos a seguir algumas regras de conduta que devem ser observadas

quando da implementao, manuteno e evoluo de um esforo de medio.

Defina claramente quais mtricas devero ser coletadas e analisadas

Defina como os resultados das mtricas sero utilizados
Defina as mtricas que sero empregadas no projeto desde o seu
planejamento ,de preferncia em conjunto com a equipe
No permita que utilizem os resultados das mtricas para avaliar o
desempenho individual
No utilize as mtricas que as equipes de projeto coletaram para
qualquer tipo de penalizao ; no use as mtricas contra a equipe
No enfatize uma mtrica sobre as outras
D feed-back peridico equipe do projeto quanto s anlises das
mtricas

Utilize as mtricas para a melhoria contnua da gesto de projetos e

produtos e do processo de desenvolvimento
Mantenha comprometimento com o esforo de medio, de forma
que as equipes de projeto o alimentem com informaes acuradas
No deixe que as equipes com desempenho superior faam propa-
ganda de seus feitos junto s outras equipes
 Por fim importante ter em mente que a obteno da qualidade desejada de
responsabilidade de todos, mas principalmente dos nveis gerenciais, pois so eles que
definem oramentos, aprovam aquisio de recursos, do a ltima palavra no que
concerne a utilizao de plataformas de desenvolvimento, implementam efetivamente o
processo de gesto, o processo de software, definem programas de treinamento e assim
sucessivamente.
Captulo
14
NOVAS RESPONSABILIDADES
PARA OS GESTORES DE
SOFTWARE

Neste Captulo procuraremos apresentar as novas dimenses de responsabilidades

dos gestores de software de acordo com os conceitos que at aqui temos discutido.

No nos restringeremos somente ao Gerente de Projetos de Software. Por se

tratar de um livro tambm de cunho gerencial ,e que fornece uma abordagem mais
ampla sobre a gesto do software em uma organizao, discutiremos as
responsabilidades e papis que o Gerente de Desenvolvimento ou de Sistemas e o
Gerente do Departamento de Informtica devem assumir em um novo cenrio.
Geralmente so tpicos esquecidos nos livros sobre Gerncia de Projetos.

Estas dimenses de responsabilidades esto fortemente ligadas aos seguintes

aspectos:

Natureza dos projetos de software e release

Implantao, manuteno e aprimoramento de um programa de mtricas
Obteno da Certificao da Qualidade conforme a norma ISO
Melhoria contnua do processo de software conforme o modelo SEI
A gesto da complexidade tecnolgica (integrao de tecnologias)
A gesto da mudana ( que em ltima anlise engloba os demais)

14.1 - As Responsabilidades dos Gerentes de Projetos de Software

Podemos dividir as responsabilidades dos Gerentes de Projetos de Software em

duas categorias, ou seja, Gerenciais-Tcnicas e Gerenciais-Organizacionais. Estas
duas categorias podem ainda ser sub-divididas em Bsicas e Avanadas.

Na verdade podemos visualizar a seguinte matriz:

Bsicas Avanadas

Gerenciais
Tcnicas

Gerenciais
Organizacionais

As responsabilidades bsicas representam os elementos mnimos necessrios

para a gesto bem sucedida de um projeto de software.
 As responsabilidades avanadas representam formas mais evoludas de ver a
gesto do projeto, o que inclue a gesto da mudana de uma forma mais abrangente, a
gesto ttica e estratgica do software.

Gerenciais-Tcnicas Bsicas

Dentro desta categoria h quatro responsabilidades principais, quais sejam:

Definio do Projeto

Esta responsabilidade diz respeito elaborao do Planejamento do

Projeto, cujo produto o Plano do Projeto.

Mais especificamente, o Gerente de Projeto deve:

Caracterizar a soluo que dever ser desenvolvida;

Definir as premissas e diretrizes que nortearo o projeto;
Definir os recursos a serem empregados no projeto;
Definir a estrutura de organizao e de gesto do projeto;
Definir o roteiro de desenvolvimento do projeto;
Definir o cronograma bsico do projeto;
Definir os pontos de controle do projeto para fins de reviso
gerencial;
Identificar os padres a serem utilizados.

Estimativas e Cronogramao

Este conjunto de responsabilidades geralmente est associado

elaborao do Plano do Projeto, entretanto, devido a sua importncia a
colocamos como um tem a parte.

Dizem respeito a:

Estimar prazos ,custos, recursos e tamanho do software, com uso

de ferramentas de estimativas ou no;
Estimar o esforo de desenvolvimento para o projeto como um
todo e para cada uma das fases estabelecidas;
Estimar os prazos para cada fase de desenvolvimento.

Esta categoria talvez seja uma das mais difceis do gerente realizar visto
que, na maioria das instalaes ,no h histria registrada a fim de
subsidiar as estimativas.

Sua importncia reside no fato de que as estimativas geram um

comprometimento do gerente com sua gerncia e com os usurios alm
de, naturalmente, criar expectativas junto a estes ltimos.

Outro complicador que, atualmente, muitos projetos de software esto

inseridos em um contexto de integrao de tecnologia, por exemplo,
utilizando o mainframe como servidor de dados e as funes sendo
executadas em um ambiente client-server com aplicaes escritas em
GUI (Graphical User Interface). Ou seja, a histria passada no ajuda
muito.

Controle do Projeto

O controle do projeto abrange:

Refinamento do projeto ao longo do seu desenvolvimento;

Replanejamento do projeto em funo de mudanas, inclusive
com novas estimativas;
Controle de mudanas de escopo do projeto;
Controle de alocao de recursos;
Verificao e validao de produtos intermedirios em termos de
padres de desenvolvimento, aderncia s especificaes e aos
requisitos dos usurios, funcionalidade e assim sucessivamente;

Monitoramento do Projeto

O monitoramento do projeto a tarefa de tornar disponvel para os

usurios e gerncia de informtica, informaes sobre o progresso do
projeto.

O progresso do projeto baseado na verificao do trmino efetivo

(100%) dos produtos intermedirios do projeto ,devidamente validados e
de acordo com os padres e aderente s especificaes e requisitos dos
usurios.

Neste caso o gerente do projeto deve atentar para as diferentes

necessidades de informaes requeridas pela gerncia de
desenvolvimento e de informtica e os usurios.

Geralmente as gerncias de desenvolvimento e informtica requerem

informaes acerca do esforo, prazos, custos realizados, situao dos
produtos em termos de sua completeza, bem como relato de ocorrncias,
as quais podem impactar negativamente em prazos e custos.

Os usurios por sua vez, requerem informaes acerca de prazos,

pendncias e completeza dos produtos.
 Gerenciais- Organizacionais Bsicas

As responsabilidades organizacionais bsicas abrangem os aspectos

comportamentais, de negociao, motivacionais, bem como as tarefas
administrativas a seu cargo.

O gerente de projeto deve manter a motivao da equipe ao longo

do desenvolvimento;
O gerente de projeto deve dar grande nfase integrao das
tarefas e atividades do projeto, uma vez que cada rea funcional
apresenta seus propsitos e objetivos particulares, ocasionando
desentendimentos e conflitos;
O gerente de projeto deve negociar entre as partes interessadas,
usurios e gerncia de informtica quanto a prazos, recursos,
reviso de escopo etc.;
O gerente de projeto deve executar as funes administrativas
requeridas, tais como elaborao de relatrios de progresso,
comunicaes com reas de apoio etc.;
O gerente de projeto deve conseguir a colaborao de vrias
pessoas na organizao para atingir os objetivos especficos do
projeto, o que exige constante trabalho de convencimento e
negociao.

Gerenciais-Tcnicas Avanadas

As responsabilidades tcnicas avanadas esto associadas com as medies

ao longo do projeto, visando a obteno do nvel aceitvel de qualidade dos
produtos intermedirios e final do mesmo.

Portanto diz respeito qualidade da gesto do projeto e dos produtos gerados e

a satisfao dos usurios (cliente).

Neste contexto o gerente de projeto deve:

Realizar as medies relativas a prazo, custo,tamanho , recursos do

projeto e esforo;
Determinar, a partir de Inspees Formais de Software, os nveis e tipos
de defeitos introduzidos nos produtos intermedirios;
Gerir os custos da m qualidade do projeto, em termos de falhas internas
e custos de preveno e avaliao;
Implementar tcnicas de testes de sistemas e de verificao, visando
reduzir os defeitos introduzidos no produto;
Gerir e controlar as verses dos produtos do projeto;
Implementar o Plano de Qualidade do projeto;
Medir a satisfao dos usurios quanto aos resultados do projeto e seus
produtos;
Realizar as medies de produtividade do projeto;
Realizar os registros da qualidade pertinentes;
 Gerenciais-Organizacionais Avanadas

As responsabilidades organizacionais avanadas dizem respeito ao

engajamento do gerente em um esforo de inovao e seu papel requerido.

Todos ns sabemos que um processo de inovao em uma empresa , requer

alguns papis-chaves. Um desses papis o que Kugler definiu como Campeo
do Produto.

O campeo do produto o gerente do projeto. o indivduo que cria, define, ou

adota uma idia para lanar uma dada inovao e que est disposto a arriscar seu
cargo e prestgio ( geralmente baseado no seu poder de percia ) para apoiar a bem-
sucedida implantao do projeto.

Seus papis principais so os de gerar novas idias e testar sua viabilidade

eficaz na resoluo de problemas que exigem criatividade e determinao; agressivo e
teimoso em promover suas idias.

Muitas vezes consegue recursos informalmente, com consentimento tcito das

gerncias; sabe muito bem como usar a estrutura para conseguir fazer andar o projeto;
sabe agir politicamente e sabe equilibrar necessidades de mercado e restries
tcnicas.

14.2 - As Responsabilidades dos Gerentes de Desenvolvimento

A responsabilidade principal do gerente de desenvolvimento a de gerir o

ambiente de software visando a melhoria contnua do processo. Isto inclue, mas no
est limitado a :

Introduzir e administrar a utilizao de novas tcnicas e mtodos para a

melhoria da qualidade do planejamento dos projetos;
Administrar a introduo de Inspees Formais de Software;
Fornecer as ferramentas necessrias para a gerncia da configurao do
software;
Administrar a introduo de mtodos de planejamento e execuo de
testes de software;
Administrar a introduo de planos da qualidade para cada projeto de
software;
Fazer com que os gerentes de projeto realizem as medies relativas
aos projetos e produtos;
Promover a atualizao tcnica perdica do pessoal de projetos;
Realizar as medies de carter ttico, relativas ao ambiente de
desenvolvimento como um todo;
Determinar as condies que contribuem para projetos produtivos e de
qualidade e implement-las;
Monitorar a melhoria das prticas de desenvolvimento de software em
termos de qualidade, produtividade etc.;
 Verificar o impacto da introduo de novas tecnologias;
Avaliar comparativamente os projetos em termos de qualidade e
produtividade e identificar causas de problemas;
Implementar aes corretivas eficazes , visando eliminar recorrncia de
problemas

14.3 - As Responsabilidades dos Gerentes de Informtica

Em uma filosofia de qualidade, aplicada ao desenvolvimento de software , a

responsabilidade principal do gerente de informtica a de ser o grande patrocinador
da implementao das mudanas.

Isto significa influenciar diretamente no processo de alocao de recursos, usar

seu poder para canalizar recursos para uma dada inovao, assumindo em grande
parte, quando no no todo, o risco da implantao da inovao.

Geralmente no tem tempo para desenvolver e promover suas prprias idias,

entretanto deve ser capaz de defender a inovao com o apoio decisivo dos
campees de produto.

Deve promover o acesso de sua equipe base do poder da oraganizao,

legitimando a inovao.

Deve fornecer direcionamentos e conselhos equipe , auxiliando os gerentes

campees, muitas vezes de forma velada, incentivando e encorajando o
desenvolvimento pessoal.

Sabe isolar a sua equipe de restries organizacionais, dando o tom de

equilbrio entre exigncias administrativas e autonomia tcnica.

Sabe selecionar pessoas e projetos; sabe quem se d bem com quem.

Sabe cobrar resultados de maneira gradual; pouca presso no incio, de

maneira a estimular divergncias e pensamento criativo, e aumentando gradativamente
o grau de exigncia , de forma a estimular convergncia e refinamento de solues na
fase final do implementao da mudana.

Adicionalmente o gerente de informtica deve ser capaz de:

Fornecer os meios para a estruturao do ambiente de desenvolvimento

de software orientado qualidade;
Estruturar as funes de Quality Assurance do ambiente;
Estruturar as funes de Gerncia da Configurao;
Planejar a evoluo do estgio de maturidade do desenvolvimento do
software e orientar a implementao de aes sistemticas para este fim;
Implantar o Sistema da Qualidade;
Realizar benchmarking do ambiente com outras empresas;
Avaliar economicamente o acervo de software da organizao;
Gerir os custos da m qualidade do ambiente, redirecionando os
investimentos para a preveno;
 Revisar criticamente o Sistema da Qualidade, conforme periodicidade
pr-determinada;
Monitorar as aes corretivas para eliminar recorrncia de causas de
problemas;
Captulo
15
AUTO-AVALIAO DO ESTGIO
DE MATURIDADE DE SOFTWARE

Este captulo tem por objetivo auxili-lo na realizao de uma auto-avaliao referente ao
estgio de evoluo que sua empresa se encontra em termos da gesto do
software,considerando o termo mais amplo que at aqui temos empregado.

Para tanto, trazemos trs instrumentos de auto-avaliao que tambm podem ser
utilizados como elementos para anlise de benchmarking, bem como ponto de partida
para um esforo planejado de evoluo e/ou melhoria contnua da maturidade de
software.

Os trs instrumentos referem-se, respectivamente a:

Auto-avaliao conforme o Modelo SEI

Auto-avaliao conforme o Modelo ISO 9000-3
Auto-avaliao conforme as Condies da Empresa Para a Mudana

15.1 - Auto-Avaliao Conforme o Modelo SEI

Caracterize sua organizao de software, selecionando o nvel que mais se

aproxima de sua realidade.

Nvel A

1. A empresa opera sem procedimentos formalizados

2. No so empregados mtodos de estimativas de custo,prazo e recursos
3. As ferramentas de desenvolvimento no so integradas com o processo e
nem aplicadas uniformemente
4. No h controles de mudana
5. A metodologia de desenvolvimento no est claramente estabelecida
6. No so empregadas tcnicas de inspeo e teste de sistemas
7. No h controle quantitativo (estatstico) da qualidade do software
8. comum os projetos ultrapassarem os custos e prazos planejados

Nvel B

9. Todos os projetos produzem e documentam seus planos,incluindo

projeesdo tamanho do produto, estimativa de recursos,pessoal, prazos e
pontos de controle

10. O processo de planejamento monitorado com base em padres e

procedimentos aprovados plea rea de Garantia da Qualidade
11. Revises gerenciais peridicas (mensais ou trimestrais) so conduzidas
para acompanhar o desempenho do projeto em termos de tamanho,
pessoal, cronogramas e pontos de controle
12. Mecanismos so estabelecidos para monitorar e controlar as mudanas
nos requerimentos
13. Um sistema de gerncia de configurao e de controle de mudana
estabelecido para requerimentos, codificao e resultados de testes
14. Padres documentados so produzidos para estimativas de tamanho de
software, projeo de recursos, prazos e planos de produto
15. Guias de estilo de produto so desenvolvidos para orientar as atividades de
projeto e codificao
16. Procedimentos documentados so produzidos para o desenvolvimento e
aprovao dos planos do produto, aprovao para mudanas nos
requerimentos, projetos ou cdigo, conduo de auditorias e revises
gerenciais
17. Os mtodos bsicos de projeto, codificao e teste de software esto
definidos e documentados
18. Mtodos padres so desenvolvidos para estimativa e planejamento de
projetos
19. Medies e anlises so feitas entre o planejado e o executado
20. Dados histricos so retidos sobre o cdigo, erros de teste etc.
21. Mecanismos e responsabilidades so estabelecidas para assegurar que os
planos sejam produzidos e acompanhados para todos os projetos; os
planos so aprovados pelas equipes de implementao; todos os planos
so revistos antes de haver comprometimento efetivo; auditorias so
conduzidas quando especificadas, controle de mudana rigorosamente
implementado e a Garantia da Qualidade e gerncia de configurao de
software so efetivamente desempenhadas
22. Procedimentos, mtodos e responsabilidades so estabelecidas para
assegurar que os desenvolvedores entendam tanto os requerimentos como
o ambiente dos usurios da aplicao
23. Meios so estabelecidos para prover o ambiente de desenvolvimento com
o conhecimento sobre ferramentas e mtodos disponveis

Nvel C

24. Existe poltica escrita, divulgada e documentada, requerendo que o padro

do processo de desenvolvimento de software seja usado
25. estabelecido um grupo de engenharia do processo de software
26. Revises gerenciais peridicas so realizadas para verificar o status dos
projetos internos de aperfeioamento do processo de software
27. O grupo de engenharia do processo de software lidera as atividades de
aperfeioamento do processo, bem como assegura a conscientizao
sobre os mtodos empregados
28. Revises gerenciais peridicas so realizadas para tratar sobre
treinamento, insero de tecnologia, status do processo de software e
planos de aperfeioamento do processo
29. Mecanismos so estabelecidos para identificar problemas sobre projeto de
sistema e software e resolv-los imediatamente
30. Cursos padres so oferecidos sobre gerncia da qualidade, gerncia de
profissionais de software, mtodos de software e inspees
31. Um plano de treinamento produzido, definindo os cursos requeridos para
cada funo no ambiente de desenvolvimento
32. Os recursos so estimados para cada atividade chave no processo de
software
33. Contingncias so estabelecidas para todas estimativas conforme a
experincia histrica
34. Planos de gerncia de risco dos projetos identificam termos tcnicos e de
negcio, os quais possam afetar o sucesso do projeto
35. O desempenho do projeto acompanhado e revisado por atividade chave
no processo de software
36. Inspees de projeto e cdigo so monitorados at a resoluo dos
problemas que surjam
37. O desenvolvimento e documentao dos padres e mtodos do processo
so monitorados e revistos
38. As ferramentas e mtodos de desenvolvimento de cada projeto so
mantidos sob o controle da gerncia de configurao de software
39. As definies e padres do processo para cada projeto so mantidas sob o
controle da gerncia de configurao de software
40. Procedimentos formais so estabelecidos para a sub-contratao de
recursos
41. Mecanismos e recursos so estabelecidos para o acompanhamento do
desempenho dos sub-contratados
42. A rea de Garantia da Qualidade da empresa monitora a Garantia da
Qualidade do sub-contratado
43. Padres documentados so produzidos para o processo de software como
um todo, abrangendo tambm registros de custos, mtodos de teste e
relatrios sobre qualidade dos produtos
44. Guias de estilo para desenvolvimento so utilizadas por toda a empresa e
para qualquer projeto
45. Procedimentos documentados so estabelecidos para produzir e aprovar
padres de processo e produto
46. As definies do processo so adaptadas, para dinamicamente, atender as
contingncias de cada projeto
47. Mtodos documentados so desenvolvidos para o projeto, codificao,
inspeo e teste
48. Mtodos so estabelecidos para identificar e relacionar todos os itens
referentes ao projeto e codificao, desde os requisitos at o teste
49. Medies so feitas sobre os erros encontrados e os custos incorridos pela
atividade do processo
50. Mecanismos e responsabilidades so estabelecidos para assegurar que
cada requisito do produto seja testvel
51. Mecanismos e responsabilidades so estabelecidos para assegurar a
produo de padres do processo, bem como relatrios de custos
52. Mecanismos so estabelecidos para assegurar que os padres do
processo de software sejam inteiramente revistos e que sua adoo seja
aceita pela comunidade tcnica da empresa
53. Mecanismos e responsabilidades so estabelecidos para a reviso da
eficcia do grupo de engenharia do processo de software
54. Mecanismos do processo so estabelecidos para assegurar a validao da
abordagem do projeto contra as necessidades dos usurios
55. Um plano de insero de tecnologia estabelecido
56. O ambiente de desenvolvimento de software estabelecido e instalado
57. Um conjunto de padres de ferramentas compatveis definida e est
disponvel

Nvel D

58. Uma poltica da empresa estabelecida, requerendo que cada novo

produto ou release seja medida
59. Uma poltica da empresa estabelecida, requerendo que todos os projetos
estabeleam planos para aperfeioar os mtodos padres
60. A nfase organizacional sobre o planejamento e acompanhamento da
qualidade
61. Recursos so disponveis para apoiar a introduo de tecnologia
62. Cada grupo de desenvolvimento principal conduz, periodicamente, um
trabalho de avaliao
63. Revises gerenciais peridicas so realizadas para avaliar o desempenho
em termos dos planos de qualidade e aes de melhoria da qualidade
64. Cursos padres so oferecidos sobre planejamento da qualidade, gerncia
quantitativa de processo, mtodos avanados de desenvolvimento,
prototipao
65. Planos de qualidade so produzidos para cada projeto
66. Planos de ao visando a melhoria da qualidade so produzidos sempre
quando o projeto no atinge as metas da qualidade
67. O desempenho medido em funo dos planos de qualidade e melhorias
68. As customizaes de cada projeto em relao aos padres do processo
so retidas sob o controle da gerncia de configurao de software
69. As mtricas utilizadas no processo so mantidas sob o controle da gerncia
de configurao de software
70. Mtricas de qualidade dos sub-contratados so estabelecidas e
acompanhadas
71. O desempenho da rea de Garantia da Qualidade acompanhado e
revisado
72. Padres documentados so produzidos para inspees, ferramentas e
mtodos, planos de qualidade e monitoramento de qualidade por atividade
do processo
73. Procedimentos documentados so produzidos para a customizao do
processo e do ambiente
74. Procedimentos documentados so desenvolvidos para os planos de
qualidade, acompanhamento, inspees e customizao do processo e do
ambiente
75. Mtodos documentados so estabelecidos para prototipao e avaliao
quantitativa do projeto
76. Prottipos so desenvolvidos para demonstrar a viabilidade de requisitos
crticos antes que entrem no escopo do projeto
77. Medies e anlises so feitas sobre os nveis de defeitos nos produtos,
eficincia e cobertura das inspees e testes, distribuio dos erros,
produtividade de tarefas e eficcia das ferramentas
78. Um banco de dados sobre o processo estabelecido
79. Um banco de dados sobre o processo e o sistema de qualidade so
centralmente mantidos e protegidos
80. Mecanismos e responsabilidades so estabelecidas para assegurar a
definio e o uso de mtricas padres, a produo e acompanhamento dos
planos de qualidade, e a insero apropriada de novas tecnologias
81. Mecanismos e responsabilidades so definidos para assegurar que os
profissionais tcnicos dos projetos aprovem e aceitem os planos de
qualidade dos produtos e tornem-se pessoalmente comprometidos em
mant-los
82. Apoio insero de tecnologias estabelecida, incluindo apoio para a
instalao e uso de ferramentas, assistncia utilizao de novos
mtodos, bem como customizao do ambiente

Nvel E

83. Uma poltica emitida, requerendo que cada grupo de desenvolvimento

demonstre um padro crescente de produtividade
84. Uma poltica da empresa requer que cada grupo de desenvolvimento utilize
os mtodos e ferramentas oficiais estabelecidas
85. O ponto focal da organizao o desenvolvimento, a introduo e o apoio
reutilizao de componentes
86. Revises gerenciais peridicas so realizadas para avaliar o desempenho
da produtividade
87. Meios so estabelecidos para assegurar que o processo de software e as
aes de melhorias sejam objetivamente avaliadas, reconhecidas e
recompensadas
88. Cursos padres so oferecidos para justificao econmica, projetos
avanados, mtodos de reutilizao e mtodos de preveno de erros
89. Planos de melhoria do processo so produzidos para cada projeto
90. Planos de melhoria de produtividade so produzidos para cada projeto
91. O desempenho avaliado em funo das melhorias no processo e
produtividade
92. A reutilizao de componentes e suas definies so mantidas sob o
controle da gerncia da configurao de software
93. Melhorias de processo e produtividade dos sub-contratados so revistas,
aprovadas e monitoradas
94. A rea de Garantia da Qualidade da empresa monitora as aes de
melhoria de processo e de produtividade dos sub-contratados
95. Padres documentados so produzidos para a medio da produtividade
de cada tarefa em termos de limites estatsticos
96. Guias documentados e padres so produzidos para a reutilizao de
componentes, incluindo padres de interfaces
97. Procedimentos documentados so desenvolvidos para o planejamento da
produtividade, gerao de cdigos reutilizveis, customizao de
componentes reutilizveis
98. Mtodos documentados so desenvolvidos para o projeto de componentes
reutilizveis, anlise de preveno de defeitos e extino de defeitos
99. Estudos econmicos e tcnicos so conduzidos durante o projeto para
decidir quando componentes reutilizveis devem ser empregados
 100. Medies e anlises so realizadas sobre eficcia de ferramentas, mtodos
de prototipao, de reutilizao
101. Anlise de causas de defeitos so conduzidas
102. Mecanismos e responsabilidades so definidas para acompanhamento de
produtividade, integrao de tecnologia e acompanhamento da eficcia da
reutilizao
103. Mecanismos e responsabilidades so estabelecidas para assegurar que os
profissionais sejam treinados e capazes de desempenhar preveno de
defeitos e que sejam pessoalmente comprometidos com as melhorias do
processo
104. O apoio da tecnologia inclue a anlise de cada tarefa para determinar o
apoio requerido, os aspectos econmicos deste apoio e a prototipao de
ferramentas e mtodos potenciais
105. O conjunto de ferramentas progressivamente aperfeioado para incluir o
uso de novas tecnologias e mtodos

NVEL SELECIONADO - ESTGIO MAIS ADEQUADO DE SUA REALIDADE

A
B
C
D
E

15.2 - Auto-Avaliao Conforme o Modelo ISO 9000-3

ELEMENTOS DA NORMA CHECKLIST Sim N

o
4 Sistema da Qualidade
4.1 Responsabilidade da Adminis-
trao
Existe uma poltica documentada, definindo os objetivos e o com-
promisso para com a qualidade?
Esta poltica compreendida, implementada e mantida em todos
os nveis da organizao?
Esto definidas as responsabilidades e autoridades de todo o
pes-
soal que administra, desempenha e verifica atividades que
influem
na qualidade?
Os requisitos, recursos e pessoal treinado para atividades de veri-
ficao esto identificados?
ELEMENTO DA NORMA CHECKLIST Sim No
4 Sistema da Qualidade -
Ferramentas
4.1 Responsabilidade da Admi-

nistrao

O Sistema da Qualidade analisado criticamente pela Adminis-

trao em intervalos apropriados?

So mantidos registros destas anlises?

O comprador quando da contratao dos servios designa um re-

presentante com autoridade para lidar com os aspectos contratu-

ais?

Revises conjuntas com o cliente so realizadas a intervalos pro-

gramados para verificar conformidade do software com os requi-

sitos, verificar resultados e resultados de teste de aceitao?

Os resultados de tais revises so documentados?

4.2 Sistema da Qualidade

H um Sistema da Qualidade documentado , considerando todo o

ciclo de vida, assegurando que a qualidade seja verificada durante

o processo ?

O Sistema da Qualidade documentado est efetivamente imple-

mentado?

Os elementos e requisitos do Sistema da Qualidade esto clara-

mente documentados numa estrutura lgica coerente?

Para cada projeto de software existe um Plano da Qualidade

base-
ado no Sistema da Qualidade?

Este Plano da Qualidade entendido e observado pelas pessoas

e reas da organizao envolvidas com o projeto?

4.3 Auditorias Internas do Sis-

tema da Qualidade

H auditorias internas da qualidade para verificar a eficcia do

Sistema da Qualidade?

As Auditorias so programadas com base na importncia das ati-

vidades relativas qualidade?

As Auditorias e aes de acompanhamento so desempenhadas

de acordo com procedimentos documentados?

Os resultados das Auditorias so documentados e levados aten-

o do pessoal que tem responsabilidade pela rea auditada?

ELEMENTO DA NORMA CHECKLIST Sim No
4.4 Ao Corretiva

mantida documentao e procedimentos para:

a) investigar as causas de no-conformidade do produto e a ao

corretiva necessria para prevenir a repetio?

b) analisar todos os processos, operaes de

trabalho,concesses,
registros da qualidade, relatrios de assistncia tcnica e reclama-

es do Cliente para detectar e eliminar causas potenciais de ser-

vios no conforme?

c) iniciar aes preventivas para tratar dos problemas em um nvel

correspondente aos riscos encontrados?

d) aplicar controles para assegurar que as aes corretivas so

realizadas e que as mesmas so efetivas?

e) implementar e registrar alteraes nos procedimentos resultan-

tes de aes corretivas?

5. Sistema da Qualidade -
Atividades do Ciclo de Vida
5.1 Geral

Os projetos de desenvolvimento de software so organizados de

acordo com um roteiro metodolgico que represente um modelo

de ciclo de vida?

As atividades relacionadas com a qualidade so planejadas e im-

plementadas com relao ao modelo de ciclo de vida usado?

5.2 Reviso de Contrato

So estabelecidos e mantidos procedimentos para reviso de con-

trato e para a coordenao destas atividades?

Quanto aos contratos:

a) o escopo do contrato e os requerimentos so definidos e docu-

mentados?

b) as contingncias e riscos possveis so identificados?

c) as informaes propietrias so adequadamente protegidas?

d) os requerimentos que diferem daqueles na proposta so resol-

vidos?

e) as responsabilidades com sub-contratados esto definidas?

f) a terminologia a ser empregada entendida por ambas as par-

tes?
ELEMENTO DA NORMA CHECKLIST Sim No
5.2 Reviso de Contrato

Em relao aos itens da qualidade no Contrato:

a) esto definidos os critrios de aceitao?

b) est definido o tratamento de mudanas nos requisitos do cli-

ente durante o desenvolvimento?

c) est definido o tratamento de problemas detectados aps a a-

ceitao do produto/servio, incluindo reclamaes e queixas do

cliente acerca de itens relacionados com a qualidade?

d) as atividades a serem desempenhadas pelo cliente, especial-

mente s relativas a especificao de requisitos, instalao e

aceitao esto definidas?

e) as facilidades, ferramentas e itens de software a serem entre-

gues ao cliente esto definidas?

f) os padres e procedimentos a serem utilizados esto defini-

dos?

g) os requisitos para replicao do software eso definidos?

5.3 Especificao dos Requisi-

tos do Cliente

Os requisitos do cliente abrangem itens como desempenho, se-

gurana, confiabilidade e privacidade?

Estes requisitos so claramente definidos de forma a serem vali-

dados durante a aceitao do produto?

H aprovao destes requisitos por parte do cliente antes do de-

senvolvimento do produto?

H controle da documentao relativa aos requisitos do cliente?

Todas as interfaces entre o produto de software e outros software

ou produtos de hardware so claramente especificados na espe-

cificao de requisitos?

Durante o desenvolvimento da especificao dos requisitos:

a) h designao de pessoas de ambas as partes para

estabelecer
a especificao de requisitos do cliente?

b) h formas e mtodos para aprovao das especificaes e para

mudanas nas especificaes?

ELEMENTO DA NORMA CHECKLIST Sim No
5.3 Especificao dos Requi-

sitos do Cliente

c) o esforo de definio de requisitos documentado por ambas

as partes?

5.4 Planejamento do Desenvol-

vimento

O plano de desenvolvimento contempla:

a) a definio do projeto, incluindo a declarao de seus objeti-

vos , bem como referencia o relacionamento com outros projetos

da empresa e do Cliente?

b) a organizao dos recursos do projeto, incluindo a estrutura da

equipe, responsabilidades, utilizao de sub-contratados, recursos

materiais e outros?

c) as fases de desenvolvimento?

d) o cronograma e calendarizao do projeto, as tarefas, recursos

e esforo requerido para cada tarefa e qualquer inter-

relacionamen-
to entre elas?

e) a identificao dos planos relacionados tais como: plano da

qua-
lidade, plano de gerncia de configurao, plano de integrao,

plano de teste?

O plano de desenvolvimento atualizado na medida em que o

pro-
jeto avana?

Antes do incio de cada fase h uma reviso e aprovao dos pro-

dutos da fase anterior?

H uma metodologia claramente definida para o desenvolvimento

do produto?

Nesta metotologia h a identificao das fases de

desenvolvimento
a serem executadas?

H identificao das entradas para cada fase?

H identificao das sadas requeridas de cada fase?

H procedimentos de verificao a serem realizados em cada fa-

se?

H anlise de problemas potenciais associada com as fases de

de-
senvolvimento e com a construo dos requisitos?
ELEMENTO DA NORMA CHECKLIST Sim No
5.4 Planejamento de Desen-

volvimento

O plano de desenvolvimento estabelece como como os projetos

devem ser gerenciados, incluindo a identificao de cronograma

de
desenvolvimento e implementao, os produtos a serem
entregues,
o controle do progresso, as responsabilidades organizacionais, os

recursos e atribuio de tarefas equipe do projeto, bem como os

interfaces tcnicos e organizacionais entre diferentes grupos?

O plano de desenvolvimento identifica as regras, prticas e

conven-
es para o desenvolvimento, as ferramentas e tcnicas e a
gern-
cia de configurao?

H revises de progresso planejadas?

As revises de progresso so documentadas?

As entradas para cada fase de desenvolvimento so definidas e

documentadas?

Cada requisito pode ser verificado quanto a sua consecuo?

As sadas requeridas de cada fase de desenvolvimento so defini-

das e documentadas?

H um plano para a execuo de verificaes dos produtos de

cada
fase de desenvolvimento?

Os resultados das verificaes so registrados?

5.5 Planejamento da Qualidade

Para o desenvolvimento do projeto preparado um plano da qua-

lidade especfico?

O plano da qualidade contempla:

a) objetivos da qualidade expressos em termos mensurveis?

b) critrios de entrada e sada para cada fade de

desenvolvimento?
c) identificao dos tipos de teste, bem como atividades de verifi-

cao e validao a serem desempenhadas?

d) planejamento detalhado de teste, atividades de verificao e

va-
lidao a serem realizadas, definindo cronograma, recursos e
auto-
ridade de aprovao

e) responsabilidades para revises e testes, gerncia de

configura-
o, controle de mudana,controle de defeitos e ao corretiva?
ELEMENTO DA NORMA CHECKLIST Sim No
5.6 Projeto e Implementao

No projeto de desenvolvimento levado em considerao:

a) regras de projeto, definies de interfaces internas?

b) metodologia especfica tendo em vista o tipo de software que est

sendo construdo?

c) utilizao de experincia passada para evitar a ocorrncia de pro-

blemas similares?

d) a construo das especificaes de forma que possam ser facil-

mente testadas e mantidas?

Na implementao levado em considerao:

a) regras de programao, linguagens de programao, convenes

de identificao de atributos, tabelas, ndices, arquivos ?

b) metodologias de implementao?

H revises para assegurar que os requisitos esto sendo atingidos

e que os mtodos de projeto e implementao esto sendo empre-

gados?

Estas revises impedem o prosseguimento do projeto antes que as

deficincias sejam efetivamente sanadas?

H registros documentados de tais revises?

5.7 Teste e Validao

H plano de testes para o software?

O plano de teste contempla:

a) teste de item de software, teste de integrao, teste de sistema e

teste de aceitao?

b) casos de testes, dados de testes e resultados esperados?

c) tipos de testes a serem desempenhados, ou seja, funcional,

testes
de interfaces, testes de desempenho, teste de usabilidade?

d) ambiente de teste e ferramentas de teste?

e) os critrios pelos quais o trmino do teste ser julgado?

f) documentao do usurio?

g) o pessoal requerido e requisitos de treinamento?

Durante o teste levado em considerao:

a) o registro dos resultados dos testes?

ELEMENTO DA NORMA CHECKLIST Sim No
b) os responsveis so notificados para a resoluo de problemas?

c) partes do software impactadas por qualquer modificao so

iden-
tificadas e re-testadas?

d) a adequabilidade e relevncia do teste?

e) a documentao e registro das condies do ambiente de

hardware e software e da configurao do software que est sendo

testado?

feita uma efetiva validao do software antes da entrega para o

cliente em termos de sua operao e, quando possvel, em condi-

es reais?

Quando o teste sob condies de campo exigido:

a) so especificados as funes a serem testadas?

b) so definidas as responsabilidades de ambas as partes na avalia-

o do teste?

c) h a restaurao do ambiente do usurio aps o teste?

5.8 Aceitao

Antes das atividades de aceitao:

a) o cliente auxiliado na determinao de prazo?

b) o cliente auxiliado na determinao dos procedimentos de ava-

liao?

c) o cliente auxiliado na determinao do ambiente de hardware e

software necessrios para a avaliao de aceitao?

d) o cliente auxiliado na definio dos critrios de aceitao?

5.9 Replicao, Entrega e Ins-

talao

No caso de replicao do software:

a) especificado o nmero de cpias do software?

b) especificado o tipo de meio para cada item de software, incluin-

do formato e verso?

c) especificado a documentao requerida tais como manuais e

guias do usurio?

d) especificado copyright e termos de licenciamento?

e) especificado os aspectos relativos a custdia e back-up de c-

pias, incluindo planos de recovery?

ELEMENTO DA NORMA CHECKLIST Sim No
5.9 Replicao, Entrega e Insta-

lao

f) especificado a obrigao de reposio de cpias ao cliente?

H procedimentos para verificar a exatido das cpias aps a sua

replicao?

Durante a instalao do software, as responsabilidades de ambas

as partes so definidas em termos de:

a) cronograma, incluindo fins de semana?

b) acesso s instalaes do cliente ( fsicas, password etc.) ?

c) disponibilidade de pessoal especializado?

d) acesso aos equipamentos e sistemas do cliente?

e) a necessidade de validao de cada instalao do produto?

5.10 Manuteno

H procedimentos para as atividades de manuteno requeridas?

H um plano de manuteno do software?

O plano de manuteno contempla:

a) escopo da manuteno?

b) identificao do status inicial do produto?

c) organizao de suporte?

d) registros de manuteno e relatrios?

e) atividades de manuteno?

A identificao do status inicial do produto, para fins de manuten-

o , definido junto com o cliente e documentado?

As mudanas efetuadas no software em funo da manuteno

so documentadas e controladas?

Para cada item de software que sofre manuteno:

a) H uma lista de solicitao ou relato de problemas recebido do

cliente e o status atual de cada solicitao?

b) H responsveis para responder s solicitaes ou para imple-

mentar a ao corretiva apropriada?

c) H prioridades atribudas s aes corretivas?

d) H o registro das aes corretivas?

e) So mantidos dados estatsticos sobre a ocorrncia de falhas e

atividades de manuteno?
ELEMENTO DA NORMA CHECKLIST Sim No
5.10 Manuteno

Os registros das atividades de manuteno so utilizados para a

melhoria do produto de software e do prprio sistema da qua-

lidade?

H procedimentos documentados para incorporar mudanas no

produto de software numa abordagem de release?

Estes procedimentos incluem:

a) regras para determinar onde novas implementaes sero rea-

lizadas ou incorporadas no produto?

b) descries dos tipos de releases dependendo de sua frequn-

cia e/ou impacto nas operaes do cliente e habilidade para imple-

mentar mudanas a qualquer ponto no tempo?

c) mtodos pelos quais o cliente ser comunicado sobre mudanas

planejadas no produto?

d) mtodos para confirmar que as mudanas a serem implemen-

tadas no introduziro outros problemas?

e) registros indicando quais mudanas foram implementadas por

instalao, para mltiplos produtos?

6 Sistema da Qualidade - Ativi-

dades de Suporte

6.1 Gerncia da Configurao

H um sistema de gerncia de configurao?

Este sistema:

a) identifica unicamente as verses de cada item de software?

b) identifica as verses de cada item de software que, juntos, cons-

tituem uma verso especfica de um produto completo?

c) identifica o status de construo do produto de software em de-

senvolvimento ou entregue e instalado?

d) controla a atualizao simultnea de um item de software espe-

cfico por mais de uma pessoa?

e) prov a coordenao para a atualizao de mltiplos produtos

em uma ou mais instalaes quando requerido?

f) identifica e monitora todas aes e mudanas resultantes de uma

solicitao de mudana, desde o incio at a release?

ELEMENTO DA NORMA CHECKLIST Sim No
6.1 Gerncia da Configurao

H um plano de gerncia da configurao?

Este plano contempla:

a) organizaes ou reas envolvidas na gerncia da configurao

e responsabilidades atribudas para cada um?

b) atividades de gerncia da configurao a serem desempenha-

das?

c) ferramentas de gerncia da configurao, tcnicas e metodolo-

gias a serem utilizadas?

d) o estgio que os itens devem ser colocados sob o controle da

gerncia da configurao?

H procedimentos para identificar os itens de software durante to-

das as fases de desenvolvimento, desde a especificao at a re-

plicao e entrega?

Quando requerido por contrato , h procedimentos para o

tratamen-
to aps a entrega do produto?

Cada item de software tem uma identificao nica?

A identificao de cada item de software para cada verso con-

templa:

a) as especificaes funcionais e tcnicas?

b) todas as ferramentas de desenvolvimento que afetam as espe-

cificaes funcionais e tcnicas?

c) todos os interfaces com outros itens de software e hardware?

d) todos os documentos e arquivos de computador relacionados

ao
item de software?

H procedimentos para identificar, documentar, revisar e autorizar

qualquer mudana aos itens de software sob a gerncia da confi-

gurao?

Todas as mudanas nos itens de software seguem estes procedi-

mentos?

H mtodos para notificar as mudanas s partes interessadas

e para mostrar a rastreabilidade entre mudanas e partes modi-

ficadas dos itens de software?

H procedimentos para registrar gerenciar e relatar sobre o status

dos itens de software, sobre solicitao de mudanas?

ELEMENTO DA NORMA CHECKLIST Sim No
6.2 Controle da Documenta-

mantido procedimentos para controlar todos os documentos relati-

vos ao sistema da qualidade?

Os procedimentos para controle da documentao contemplam:

a) a determinao dos documentos sujeito ao controle?

b) a aprovao e emisso de procedimentos?

c) o controle de mudanas nos documentos?

O controle de documentao aplicado a:

a) documentos que descrevem o sistema da qualidade aplicado ao

ciclo de vida do software?

b) documentos de planejamento descrevendo a evoluo do rela-

cionamento com o cliente?

c) documentos de produto incluindo entradas para cada fase de de-

senvolvimento, sadas de cada fase de desenvolvimento, planos de

verificao e validao e respectivos resultados, manuais e

documen-
tao de manuteno?

H procedimentos para assegurar que os documentos e respecti-

vas cpias estejam disponveis em locais apropriados onde opera-

es essenciais para o efetivo funcionamento do sistema da quali-

dade so desempenhadas?

H procedimentos para que documentos obsoletos sejam removidos

dos locais de uso?

H procedimentos para a reviso e aprovao de mudanas nos

documentos?

H controle das verses dos documentos?

Os documentos so re-emitidos aps um determinado nmero de

alteraes ?

6.3 Registros da Qualidade

H procedimentos para identificao, coleta, indexao,

arquivamen-
to, armazenamento, manuteno e disposio de registros da quali-

dade?

H procedimento para determinar perodo de tempo em que os

regis-
tros devem ser retidos?
ELEMENTO DA NORMA CHECKLIST Sim No
6.4 Medio

H utilizao de mtricas para a medio da qualidade do produ-

to?

As mtricas relativas ao produto so coletadas em intervalos regu-

lares?

So identificados os nveis de desempenho com as mtricas ?

Com os resultados das medies, e quando h indicao, h to-

mada de ao corretiva?

So estabelecidas metas de melhoria em funo das medies?

H mtricas para a medio da qualidade do processo de desen-

volvimento de software?

6.7 Compra

H procedimentos para assegurar que produtos e/ou servios

adquiridos para agregar ao produto estejam em conformidade com

os requisitos?

H registros sobre a qualificao e desempenho de sub-contrata-

dos?

H validao do trabalho de sub-contratados?

6.8 Software Produto Incluso

H procedimentos para a validao , armazenamento, proteo e

manuteno de produto de software do cliente ou de terceiros?

6.9 Treinamento

H procedimentos para identificar as necessidades de treinamento

do pessoal envolvido com atividades que afetam a qualidade?

So mantidos registros sobre as atividades de treinamento?

15.3 - Verificao das Condies Para a Mudana

Apesar destes instrumentos de auto-avaliao, fornecerem subsdios para o

caminho a percorrer, rduo por sinal, necessrio verificar as condies ambientais da
empresa para a mudana. Isto significa verificar se o esforo a ser despendido para
evoluir a novas patamares de excelncia em software ter chances de ser bem sucedido.
 Para tanto, apresentamos um breve checklist para voc avaliar se sua empresa
ou organizao de informtica reune as condies organizacionais para a mudana.

O checklist composto por 17 itens. Para cada item, d uma nota, de acordo
com a seguinte escala:

Alto =3
Mdio = 2
Baixo = 1

A nota 3 significa que a organizao possue a condio na totalidade; a nota 2

significa que a organizao possue parcialmente a condio; a nota 1 significa que a
organizao no possue a condio.

Se o seu escore ficar entre 41 e 51 a implementao da mudana poder ser bem

sucedida. Se o escore ficar entre 28 e 40, a mudana possvel mas ser difcil. Neste
caso maior ateno dever ser destinada as sete primeiras condies. Por fim, se o seu
escore ficar entre 17 e 27, a implementao da mudana ser praticamente impossvel.

CONDIO PARA A MUDANA ESCORE

PATROCINADOR
H um patrocinador para a mudana, ou seja, a pessoa com poder para auxiliar a equipe de mudana
quando encontra resistncia; 3 pontos caso o patrocinador se encontra no nvel senior da empresa ( o
Dire-
tor de Informtica/Tecnologia); caso o patrocinador seja de reas de assessoria d somente 1 ponto
LIDERANA
Isto significa a liderana do dia-a-dia; a pessoa que estabelece metas, trabalha arduamente para o
sucesso
do empreendimento e tem os resultados para o negcio bem claro na mente;d 3 pontos caso a liderana
seja desempenhada por algum de alto nvel da organizao e que tenha trnsito junto s outras reas
da
empresa
MOTIVAO
D trs pontos para um forte senso de urgncia transmitido pela alta gerncia, o qual compartilhado
pelo
resto da empresa e para uma cultura corporativa que enfatiza a melhoria contnua
DIREO
A alta gerncia acredita que o futuro pode ser diferente do presente? Quo clara a viso da alta
gerncia
acerca do futuro? A alta gerncia pode mobilizar empregados, clientes e fornecedores para a ao? D
trs pontos para respostas positivas a estas questes
MEDIES
Trs pontos se a empresa j utiliza medidas de desempenho advindas da qualidade total ( tais como
taxas de defeitos, marketing timing etc.); dois pontos se algumas medidas existem; se a empresa ou
unidade de
negcio no tiver medies ou voc no sabe do que se trata, atribua somente um ponto
CONTEXTO ORGANIZACIONAL
Como a mudana pretendida se relaciona com outras que esto ocorrendo na organizao? Trs pontos
se
existe uma forte relao, se h uma ligao estratgica ; caso o esforo de mudana isolado ou se h

mltiplos esforos de mudana no ligados estrategicamente pode estar havendo problemas

Este checklist foi adaptado do artigo Rate Your Readiness To Change de Thomas A.
Stewart publicado na revista Fortune de fevereiro de 1994.
 CONDIO PARA A MUDANA ESCORE
PROCESSOS/FUNES
As principais mudanas geralmente exigem o re-projeto dos processos do negcio, os quais atravessam
funes organizacionais; se os executivos no esto conscientes a mudana ser dificultada. D mais
pon-
tos quanto maior for a conscincia dos executivos e da organizao como um todo no sentido de mudar
os
processos crticos mesmo sacrificando poder para o bem do grupo
BENCHMARKING DOS COMPETIDORES
D maiores pontos se sua empresa observa continuamente os competidores e compara mtodos e
proces-
sos com os seus; d um ponto se o conhecimento que sua empresa tem do competidor primrio
FOCO NO CLIENTE
Quanto mais as pessoas na empresa esto imbudas de vontade para conhecer cada vez mais o cliente,
maior a probabilidade de que a organizao concorde com mudanas para servir melhor o cliente. Trs
pontos se cada um na empresa sabe quem o seu cliente, conhece suas necessidades; d menos
pontos
se este conhecimento fica restrito a pessoal de vendas, executivos da alta administrao
RECOMPENSAS
Mudanas tornam-se mais fceis se os gerentes e empregados so recompensados para aceitarem
riscos,
serem inovadores e perseguirem novas solues; recompensas para equipes so mais aconselhveis do
que recompensa pelo desempenho individual; reduza os pontos se sua empresa recompensa a
continuida-
de ao invs da mudana; reduza mais ainda se os empregados acreditam que erros so sempre punidos
ESTRUTURA ORGANIZACIONAL
A melhor situao uma organizao flexvel; d nota baixa se a sua empresa tem uma estrutura rgida
cu-
ja maior mudana ocorreu mais do que cinco anos ou tem feito frequentes reorganizaes com pouco su-
cesso
COMUNICAO
Uma empresa adaptar-se- mais rapidamente a uma mudana caso tiver comunicao que chegue a to-
dos os seus nveis e que seja usada e entendida pelos empregados; caso contrrio a mudana ser muito
difcil
HIERARQUIA ORGANIZACIONAL
Quanto menores os nveis da hierarquia e quanto menores os ttulos dos empregados, maior a probabili-
dade de um esforo de mudana ser bem sucedido; grande nmero de gerentes de nvel mdio e de pes-
soal de assessoria faz com que o processo de tomada de deciso seja mais demorado e tem poder para
bloquear a mudana mesmo que de forma passiva
EXPERINCIA PASSADA COM MUDANAS
D trs pontos se a sua empresa implementou, em um passado recente, mudanas bem sucedidas; d
um
ponto se nunca vivenciou uma mudana; dois pontos para mudanas que agregaram um pouco de valor
MORAL
A mudana fcil se os empregados gostam do seu trabalho e o nvel de responsabilidade individual
alto; sinais de pouca disposio para mudana se o esprito de equipe baixo, pouco trabalho voluntrio
extra e desconfiana; observe dois tipos de desconfiana: entre gerncia e empregados e entre departa-
mentos
INOVAO
Melhor situao: a empresa est sempre experimentando; novas idias so implementadas com pouco
es-
foro; empregados trabalham atravs das fronteiras departamentais sem muito problema; maus sinais:
muitas aprovaes antes que novas idias sejam tentadas, empregados so desencorajados de trabalhar
com colegas de outros departamentos ou divises
 CONDIO PARA MUDANA ESCORE
TOMADA DE DECISO

D trs pontos se as decises so tomadas rapidamente, levando em considerao uma grande

variedade
de sugestes; claro onde as decises so tomadas; d uma nota baixa se as decises so demoradas

e so tomadas pelos misteriosos les ; h muitos conflitos durante o processo e confuso antes que as

decises sejam anunciadas

Captulo
16
COLETNEA DE ESTATSTICAS
REFERENTES SOFTWARE

Informaes estatsticas que representam a experincia de outras organizaes no

desenvolvimento de software, fornecem avisos importantes para o gerente e
desenvolvedores.

As informaes que a seguir so expostas podem subsidiar qualquer processo de

planejamento do desenvolvimento de software, independente de plataforma e tcnicas a
serem empregadas.

Probabilidades de Introduo de Defeitos Em Funo do Nmero de

Condicionais Em Um Programa

60%

40%

30%

20%

10%

5%

1-10 11-20 21-30 31-50 51-90 >90

Fonte: Furlan 3

Fontes de Erros do Software

Fonte dos Erros %

Requisitos e Especificaes 11
Projeto 81
Linguagem e Ambiente 6
Outros 2

Fonte: Weiss 6
Inspeo Formal de Software versus Teste

Utilizando a tcnica de inspeo formal de software, o prazo de

desenvolvimento tem um acrscimo de 10%
Testes de sistemas conseguem detectar somente 50% dos de-
feitos do software
A tcnia de inspeo formal de software detecta at 70% dos
defeitos do software
A utilizao conjunta da tcnica de inspeo formal de software
e de testes podem detectar at 90% dos defeitos do software

Fonte: AT&T 2

Emprego da Reutilizao de Software

Projetos criados primariamente de software reutilizado despen-

dem cerca de 1/4 do tempo e recursos do que novos projetos
Projetos criados de software reutilizado experimentam somente
1/3 da densidade de defeitos daqueles que so novos

Fonte: Grady 4

Cobertura de Teste

Testes tpicos, sem medio de cobertura, somente conseguem

testar cerca de 55% do cdigo; com o controle de cobertura pode
testar cerca de 80%

Fonte: Grady 4

Distribuio do Esforo do Desenvolvimento

Projetos de software investem, em mdia, cerca de 18% do es-

foro total durante a especificao, 19% no design , 34% na co-
dificao e 29% durante o teste

Fonte: Grady 4

Produtividade Mdia Na Produo de Cdigo

Um projeto entrega em mdia, cerca de 350 linhas de cdigo

(excluindo comentrios) por engenheiro/ms

Fonte: Grady 4
Esforo de Desenvolvimento versus Esforo de Manuteno

Gasta-se cerca de 2 a 3 vezes de esforo em manuteno e

melhoramento de software do que criando novos

Fonte: Grady 4

Densidade de Defeitos

Para cada 10 defeitos encontrados no teste do software, ser

encontrado cerca de 1 defeito ps-release

Fonte: Grady 4

Variaes no Processo de Software

85% das causas de variaes no processo de software so co-

muns, enquanto 15% so causas especiais

Fonte: Arthur 1

Crescimento do Software Aps a Especificao

Entre o trmino da especificao de um sistema e a sua imple-

mentao, cerca de 44% de codigo e 35% de funcionalidade sero
adicionados

Fonte: Capers Jones 5

Aspectos Relativos Qualidade

Uma organizao reativa despende cerca de 90% do seu tem-

po na correo dos sintomas de problemas ao invs de atacar as
suas causas
No incomum encontrar um departamento de informtica que
no possui programa de qualidade formal, cujos custos de m qua-
lidade representam cerca de 30 a 50% do oramento anual
Custos de avaliao em empresas que tm programa de quali-
dade chegam a 25% do custo total do software, enquanto em ou-
tras companhias este custo chega a 50% do custo total

Fonte: Arthur 1

Mdulos Com Erros Crnicos

Cerca de 5% dos mdulos de um sistema de porte, recebe em

torno de 50% das comunicaes de defeitos.

Fonte:Capers Jones 5
Mdias Norte-Americanas

Emprego de Pessoal Conforme o Tamanho do Sistema em Pontos de Funo

Tamanho do Sistema em Pontos Intervalos de Quantitativo de

de Funo Pessoal
20 At 1
40 At 1
80 2
160 Entre 2 e 4
320 Entre 4 e 8
640 Entre 8 e 16
1280 Entre 16 e 32
2560 Entre 32 e 64
5120 Entre 64 e 128
10240 Entre 128 e 254

Variao Percentual Entre Prazos Planejados e Realizados Conforme o

Tamanho do Sistema em Pontos de Funo

Tamanho do Sistema em Pontos Variao Entre Prazo Reali-

de Funo zado versus Planejado
20 Nenhum
40 + 10%
80 + 35%
160 + 40%
320 + 60%
640 + 65%
1280 + 90%
2560 + 65%
5120 + 100%
10240 + 114%

Crescimento em Contedo Funcional Conforme o Tamanho do Sistema em Pontos

de Funo

Intervalo de Tamanho de Sistema Intervalos Percentuais de

em Pontos de Funo Crescimento
10 a 80 At 10%
80 a 640 Entre 10 a 20%
640 a 5120 Entre 20 a 30%
5120 a 10240 Entre 20 a 40%
Homem-Ms de Esforo Para Novos Projetos de Software

Tamanho do Sistema Intervalos de Esforo em

em Pontos de Funo Homem/Ms
10 1
20 2
40 Entre 2 e 4
80 Entre 4 e 8
160 Entre 8 e 16
320 Entre 32 e 64
640 Entre 128 e 256
1280 Entre 512 e 1024
2560 Entre 1024 e 2048
5120 Entre 4096 e 8192
10240 Entre 8192 e 16384

Taxas de Produtividade Para Projetos de Software

Tamanho do Sistema Taxa de Produtividade em

em Pontos de Funo Pontos de Funo
10 Entre 15 e 16
20 Entre 14 e 15
40 Entre 13 e 14
80 Entre 10 e 11
160 Entre 7 e 8
320 Entre 6 e 7
640 Entre 4 e 5
1280 Entre 3 e 4
2560 Entre 2 e 3
5120 Entre 1 e 2
10240 1

Volume Mdio de Documentao Gerada em Pginas

Tamanho do Sistema Volume Mdio da Documenta-

em Pontos de Funo o Gerada
10 Entre 10 e 20
20 Entre 20 e 40
40 Entre 40 e 80
80 Entre 160 e 320
160 Entre 320 e 640
320 Entre 1280 e 2560
640 Entre 2560 e 5120
1280 Entre 5120 e 10240
2560 Entre 20480 e 40960
5120 Entre 40960 e 81920
Risco de Cancelamento de Projetos de Software

Tamanho do Sistema Intervalos das Probabilidades

em Pontos de Funo de Cancelamento
10 At 5%
20 At 5%
40 Entre 5 e 10%
80 10%
160 Entre 10 e 15%
320 Entre 15 e 20%
640 Entre 20 e 25%
1280 Entre 25 e 30%
2560 Entre 30 e 35%
5120 Entre 35 e 40%
10240 Entre 45 e 50%

Expectativa de Vida de Software Aps a Entrega

Tamanho do Sistema Intervalo de Anos em Produ-

em Pontos de Funo o Antes da Substituio
10 At 1
20 Entre 1 e 2
40 Entre 2 e 3
80 Entre 3 e 4
160 Entre 4 e 5
320 Entre 6 e 7
640 Entre 8 e9
1280 Entre 10 e 11
2560 Entre 13 e 14
5120 Entre 14 e 15

Volume de Novas Funes Adicionadas Como Melhorias Anualmente

Tamanho do Sistema Intervalos de Pontos de Fun-

em Pontos de Funo o Adicionados
10 At 10
20 At 10
40 Entre 10 e 20
80 Entre 10 e 20
160 Entre 20 e 40
320 Entre 40 e 80
640 Entre 80 e 160
1280 Entre 160 e 320
2560 Entre 320 e 640
5120 Entre 640 e 1280
Taxas de Produtividade Para Projetos de Melhoria

Tamanho do Sistema Intervalos de Taxas de Produ-

em Pontos de Funo tividade em Pontos de Funo
10 Entre 3 e 4
20 Entre 5 e 6
40 Entre 7 e 8
80 Entre 9 e 10
160 Entre 8 e 9
320 Entre 6 e 7
640 Entre 5 e 6
1280 Entre 3 e 4
2560 Entre 2 e 3
5120 Entre 1 e 2

Taxas de Produtividade Para Projetos de Manuteno

Tamanho do Sistema Intervalos de Taxas de Produ-

em Pontos de Funo tividade em Pontos de Funo
10 Entre 18 e 20
20 Entre 14 e 16
40 Entre 6 e 8
80 Entre 4 e 6
160 Entre 2 e 4
320 Entre 0 e 2

Mdia de Defeitos Potenciais

Tamanho do Sistema Intervalos de Defeitos em

em Pontos de Funo Potencial
10 Entre 4 e 8
20 Entre 16 e 32
40 Entre 64 e 128
80 Entre 128 e 256
160 Entre 256 e 512
320 Entre 512 e 1024
640 Entre 1024 e 2048
1280 Entre 2048 e 4096
2560 Entre 4096 e 8192
5120 Entre 8192 e 16384
10240 Entre 16384 e 32768
Eficincia Mdia na Remoo de Defeitos

Tamanho do Sistema Intervalos de Remoo Cumu-

em Pontos de Funo lativa de Defeitos
10 Entre 90 e 95%
20 Entre 90 e 95%
40 Entre 85 e 90%
80 Entre 85 e 90%
160 Entre 80 e 85%
320 Entre 75 e 80%
640 Entre 70 e 75%
1280 Entre 65 e 70%
2560 Entre 65 e 70%
5120 Entre 60 e 65%
10240 Entre 60 e 65%

Volumes de Defeitos Entregues aos Usurios

Tamanho do Sistema Intervalos de Defeitos Vlidos

em Pontos de Funo Entregues aos Usurios
10 At 1
20 At 2
40 Entre 2 e 4
80 Entre 4 e 8
160 Entre 8 e 16
320 Entre 64 e 128
640 Entre 256 e 512
1280 Entre 1024 e 2048
2560 Entre 4096 e 8192
5120 Acima de 16384

Defeitos Comunicados Pelos Usurios No Primeiro Ano de Uso do Sistema

Tamanho do Sistema Intervalos de Defeitos Comu-

em Pontos de Funo nicados Pelos Usurios
10 At 1
20 At 2
40 At 2
80 Entre 2 e 4
160 Entre 8 e 16
320 Entre 64 e 128
640 Entre 256 e 512
1280 Entre 1024 e 2048
2560 Entre 2048 e 4096
5120 Entre 4096 e 8192
10240 Entre 8192 e 16384
Eficincia da Remoo de Erros Conforme Fatores de Projeto

Fatores de Projeto Eficincia da Remoo de Erros, %

o mais baixo mdio o mais alto
1.Sem inspeo do projeto
2.Sem inspeo de cdigo 30 40 50
3.Sem garantia da qualidade
4.Sem teste formal
1.Com inspeo do projeto
2.Com inspeo de cdigo 95 99 99
3.Com garantia da qualidade
4.Com teste formal

Intervalos de Produtividade Em Pontos de Funo Conforme Fatores de Projeto

Fatores de Projeto Intervalos de Produtividade PFs

o mais baixo mdio o mais alto
1.Staff inexperiente
2.Mtodos no estruturados 0.25 2.5 5.0
3.Ferramentas comuns
4.Linguagens de baixo nvel

1.Staff experiente
2.Mtodos estruturados 20.0 40.0 100.0
3.Ferramentas CASE
4.Linguagens de alto nvel

Fonte: Capers Jones 5

Voc pode usar estas informaes para avaliar o seu processo e avaliar os riscos
inerentes ao desenvolvimento. Porm no procure fazer muitas generalizaes, pois
referem-se a uma realidade diferente da nossa, cujas organizaes de software
encontram-se em estgios mais evoludos.

REFERNCIAS

1. ARTHUR,Jay Lowel . Improving Software Quality: an insiders guide to TQM. Wiley &
Sons, New York, 1993.

2. EBENAU, R.G. & STRAUSS, S. H. Software Inspection Process. McGraw-Hill, 1994.

3. FURLAN, Jos Davi. Reengenharia da Informao: do moto realidade. MAKRON

Books, So Paulo, 1994.

4. GRADY, R.B. Practical Software Metrics for Project Management and Process
Improvement., Prentice Hall, Englewood Cliffs, New Jersey, 1992.

5. JONES, Capers.Applied Software Measurement. McGraw-Hill,New York,1991.

6. WEISS,D.M. & BASILI,V.R. Evaluating Software Development By Analisys of
Changes. IEEE Transactions on Software Engineering, Vol 2, No 2 , feb 1985.
 LISTA DE MTRICAS QUE APARECEM NESTE LIVRO

Captulo 6

1. Estimativa do Tamanho do Software

2. Estimativa do Prazo do Projeto Com Pontos de Funo
3. Estimativa do Esforo do Projeto Com Pontos de Funo
4. Custo Estimado do Projeto Com Ponto de Funo
5. Estimativa do Nmero de Instrues Fontes
6. Estimativa de Esforo COCOMO - Bsico
7. Estimativa de Prazo COCOMO- Bsico
8. Estimativa de Quantitativo de Pessoal COCOMO - Bsico
9. Estimativa de Esforo COCOMO Intermedirio
10. Estimativa de Quantitativo de Pessoal - COCOMO Intermedirio
11. Estimativa de Distribuio de Esforo e Prazo COCOMO
12. Estimativa do Nmero de Defeitos Pr-Release
13. Estimativa do Nmero de Defeitos Ps-Release
14. Estimativa do Esforo de Retrabalho
15. Estimativa do Custo de Retrabalho

Captulo 7

16. Progresso na Remoo de Defeitos

17. Defeitos Restantes
18. Desvio da Estimativa de Defeitos
19. Composio dos Tipos de Defeitos na Fase
20. Composio de Defeitos At a Fase
21. Composio das Classes de Defeitos
22. Distribuio de Defeitos Por Mdulo do Software
23. Densidade de Defeitos da Inspeo
24. Densidade de Defeitos na Fase
25. Densidade de Defeitos Por Mdulo do Software
26. Eficincia da Remoo de Defeitos do Processo de Inspeo
27. Taxa de Exame Por Inspees
28. Taxa de Preparaoa Por Inspeo
29. Tamanho do Material Inspecionado Por Inspees
30. Anlise de Complexidade
31. Falhas Adicionais Esperadas Para Atingir Objetivo de Intensidade
32. Tempo de Execuo Adicional Esperado Para Atingimento do Objetivo de
Intensidade
33. Progresso na Elaborao de Produtos
34. Acompanhamento Fsico do Projeto
35. Estimativa Atualizada do Tamanho do Software
36. Estimativa Atualizada de Prazo
37. Exatido da Estimativa de Prazo da Fase
38. Estimativa Atualizada de Esforo
39. Estimativa Atualizada de Alocao de Recursos
40. Exatido da Estimativa de Esforo da Fase
41. Acompanhamento Financeiro do Projeto
42. Estimativa Atualizada do Custo do Projeto
43. Comportamento do Custo de Retrabalho
44. Monitoramento de Mudanas nos Requisitos
45. Origens de Incremento/Mudanas nos Requisitos
46. Falhas Esperadas Para o Software
47. Intensidade Atual de Falhas
48. Estimativa Atualizada do Nmero de Defeitos Ps-Release
49. Exatido da Estimativa de Prazo
50. Exatido da Estimativa de Tamanho do Software
51. Exatido da Estimativa de Custo
52. Exatido da Estimativa de Esforo
53. Exatido da Estimativa de Defeitos Pr-Release
54. Exatido da Estimativa de Custo de Retrabalho
55. Exatido da Estimativa de Instrues Fontes
56. Tamanho do Software Entregue
57. Clculo do Ponto de Funo
58. Clculo do Feature Points
59. Produtividade do Desenvolvimento
60. Custo do Ponto de Funo de Desenvolvimento
61. Crescimento Funcional do Software Durante o Desenvolvimento
62. Reutilizao do Cdigo
63. Complexidade do Software
64. Custo da Qualidade
65. Distribuio do Esforo Por Fase
66. Distribuio do Custo Por Fase
67. Distribuio de Defeitos Por Fase
68. Densidade de Defeitos do Software
69. ndice de Tecnologia de Desenvolvimento Empregado
70. ndice de Tecnologia de Gesto Aplicado ao Projeto

Captulo 8

71. Estimativa do Esforco Anual de Atendimento

72. Estimativa do Nmero de Profissionais Para o Atendimento Anual
73. Estimativa do Custo do Atendimento Anual
74. Estimativa Esperada de Defeitos do Atendimento Anual
75. Esforo de Retrabalho do Atendimento Anual
76. Custo Esperado do Retrabalho do Atendimento Anual
77. Probabilidade da Ocorrncia do Primeiro Evento de Solicitao de Manuteno
Corretiva
78. Probabilidade de Que Sejam Recebidos Mais do Que X Solicitaes de
Manutenes Corretivas
79. Probabilidade do Recebimento de Um Nmero X de Solicitaes
80. Probabilidade de Tempo de Atendimento - Exemplo 1
81. Probabilidade de Tempo de Atendimento - Exemplo 2
82. Probabilidade de Tempo de Atendimento - Exemplo 3
83. Falhas Esperadas do Software
84. Estimativa do Esforo da Manuteno Adaptativa
85. Estimativa do Prazo da Manuteno Adaptativa
86. Estimativa do Nmero de Profissionais Necessrio Para a Manuteno Adaptativa
87. Estimativa do Custo de Manuteno Adaptativa
88. Estimativa do Nmero de Defeitos da Manuteno Adaptativa
89. Estimativa de Esforo de Retrabalho da Manuteno Adaptativa
90. Estimativa do Custo do Retrabalho da Manuteno Adaptativa
91. Estimativa do Tamanho do Projeto de Melhoria
92. Estimativa de Esforo do Projeto de Melhoria
93. Monitoramento do Backlog
94. Tempo Mdio de Atendimento das Solicitaes
95. Tempo Mdio do Backlog Em Aberto
96. Origem das Solicitaes
97. Frequncia do Tipo de Solicitao
98. Frequncia de Solicitaes Por Mdulo do Software
99. Produtividade da Manuteno Corretiva/Adaptativa
100. Monitoramento da Densidade de Defeitos do Produto
101. Monitoramento da Intensidade de Falhas do Produto
102. ndice de Manuteno do Produto
103. Produtividade de Manutenes Adapatativas e Projetos de Melhoria
104. Custos do Ponto de Funo de Manuteno Adaptativa e Projetos de Melhoria
105. Eficincia da Remoo de Defeitos do Processo
106. Verificao da Exatido das Estimativas de Manuteno
107. Tamanho Atual do Software
108. Crescimento Funcional Relativo do Software
109. Crescimento Funcional Mdio do Software
110. Complexidade Atual do Software
111. Custo da Qualidade do Atendimento ao Produto
112. ndice de Tecnologia de Manuteno/Melhoria Empregado
113. ndice de Tecnologia de Gesto Empregado

Captulo 9

114. Verificao de Projetos/Produtos Com Desvio do Padro da Qualidade

115. Verificao dos Projetos Com Desvio da Estimativa de Prazos
116. Verificao dos Tempos de Atendimento s Manutenes Corretivas
117. Verificao dos Desvios de Custos Estimados
118. Anlise da Capacidade de Atendimento
119. Anlise da Tendncia da Produtividade do Desenvolvimento
120. Anlise de Impacto
121. Anlise de Atributos
122. Modelagem do Ambiente de Desenvolvimento