Metricas de Software

Mtricas de Desenvolvimento de Software
Mtricas de
Desenvolvimento de
Software
Professor Marcelo Freitas Pintaud
1
Introduo 5
Captulo 1 Mtricas de Software 5
Medidas, Mtricas e Indicadores 5
Classificao das Mtricas de Software 7
Tipos de Mtricas de Software 8
Mtricas de Dimenso de Software 9
Mtricas de Halstead 11
Mtricas de Complexidade de Software 11
SUMRIO Mtricas de Qualidade de Software 12
Mtricas de Orientao a Objetos 14
Medidas Aplicadas Metodologia gil 16
Ferramentas para Extrao de Mtricas 17
Consideraes Sobre Mtricas 18
Estimativas de Software 18
Estimativas conceitos fundamentais 18
Planejamento do Projeto: definio do escopo 19
Planejamento do Projeto: Estimativa de Recursos 19
Tcnicas de Estimativas: Decomposio 20
Exemplos de Estimativas Baseadas em LOC 21
Exemplos de Estimativas Baseadas em Pontos Por Funo 22
Modelos de Estimativas 24
Modelos de Estimativa Empricos 24
Exemplo de Aplicao do Modelo Emprico 25
Modelo COCOMO - Conceitos Bsicos 26
COCOMO 81 26
Estimativa de esforo de desenvolvimento 27
Estimativa do prazo de desenvolvimento 27
Exemplo de aplicao do COCOMO 27
COCOMO II 28
Modelo Application Composition 28
Modelo Early Design 28
Modelo Post-Achitecture 30
Estimativa Baseada em Processo 30
Exemplo de Estimativa Baseada em Processo 31
Conciliao de Modelos de Estimativas 32
Exemplo de conciliao de estimativas 32
Gerenciamento de Riscos 33
Conceitos bsicos sobre riscos em projetos 33
Prticas para Gerenciamento de Riscos 34
2
Avaliao e Priorizao de Riscos 35

Categorizaes de Risco 36
Avaliao do Risco Global do Projeto 37
Matriz de Riscos 37
Exposio ao Risco (ER) 38
Exemplo de clculo de ER 38
Exposio ao Risco Total (ERT) 39
Exemplo de clculo de ER 39
RMMMRisk Mitigation, Monitoring and Management 40
Cronogramao 40
Conceitos Bsicos sobre Cronogramao 40
Cronogramao e Planejamento de Projetos 41
Cronogramao e Controle de Projetos 41
EVM - Earned Value Management 42
Exemplo de uma Anlise do Valor Agregado 42
Parmetros para Anlise do Valor Agregado 43
Exemplo de uma Anlise do Valor Agregado 44
Problema: 44
Diagrama de Gantt 46
Rede de Atividades: PERT/CPM/PDM 47
Consideraes Finais 49
Referncias 49
Glossrio de Siglas 50
3
4
Introduo software, que a gesto de riscos. Todo projeto est ex-

posto a riscos e de suma importncia que voc adote
uma estratgia pr-ativa em relao a eles. Isso implica
Caro aluno, nesta disciplina trataremos de um tema
em conseguir prever a quais riscos o projeto est vulne-
de grande relevncia para os profissionais envolvidos na
rvel, qual a probabilidade desses riscos se tornarem rea-
produo do software: as Mtricas de Software. Este tema
lidade e qual o impacto deles no projeto, caso realmente
parte fundamental da prtica da Engenharia de Software
venham a ocorrer. Por fim, finalizaremos a disciplina dis-
e cada vez mais comum nos requisitos contratuais para
cutindo cronogramao. Aqui tambm as medidas de-
dimensionar o software e sua qualidade.
sempenham um papel fundamental. Um exemplo disso
a denominada Anlise do Valor Agregado que pode
Organizaes que criam padres e modelos para a in-
auxili-lo no monitoramento e controle do andamento de
dstria, como os padres ISO e CMMI, se preocupam com
um projeto.
medidas e mtricas a fim de apurar e garantir a qualidade
de produtos e servios. Empresas e rgos governamen-
Ento isso, caro aluno. Uma vez que voc tenha con-
tais, no Brasil e no mundo, esto usando mtricas para
cludo o estudo desses vrios tpicos, voc estar prepa-
compreender, controlar, prever e melhorar projetos, pro-
rado para entender melhor a importncia da utilizao
cessos e produtos de software.
das mtricas no seu trabalho profissional como Engenhei-
Dessa forma, caro aluno, caso voc esteja envolvido com ro e Arquiteto de Software.
a rea de desenvolvimento de software, fundamental ter
Marcelo Pintaud
conhecimento sobre os conceitos relativos s mtricas.
Ao longo dessa disciplina, apresentaremos os conceitos
bsicos sobre mtricas, depois veremos como elas se
Captulo 1 Mtricas de Software
relacionam com o produto, processo e projeto de software
e como podem auxiliar no seu controle e melhoria. Em Medidas, Mtricas e Indicadores
seguida, apresentaremos as diferentes categorias de
mtricas que podem dar suporte a vrios aspectos ligados Mtricas de software esto se tornando cada vez mais
prtica da Engenharia de Software. uma parte importante na prtica da Engenharia de Softwa-
re. A cada dia, um nmero maior de empresas e governos,
Em um segundo momento, voc ter oportunidade esto adotando e reportando mtricas de qualidade como
de ver como as mtricas desempenham um papel funda- parte dos requisitos contratuais de desenvolvimento.
mental em uma das reas mais crticas do desenvolvimen-
to de software: a rea de estimativas de custos, prazos e
recursos. Vrios modelos de estimativas sero apresenta-
dos, dando-lhe condies de constatar a importncia de
se ter um programa bem estabelecido de coleta de medi-
das, clculo de mtricas e armazenamento dessas infor-
maes em uma base de dados robusta. A qualidade des-
sa base de dados ser fundamental para a preciso das
estimativas realizadas para cada projeto em andamento
na sua empresa.
Fonte: http://blog.andrefaria.com/wp-content/uploads/2012/03/metric.
Trataremos, tambm, de um assunto que comum a png
todo empreendimento, incluindo o desenvolvimento de
5
Padres, modelos e normas como ISO - International Organization for Standardization, CMMI - Capability Maturi-
ty Model Integration, dentre outros, consideram as mtricas dentre as suas prticas recomendadas. Empresas esto
usando mtricas para melhor compreender, mapear, controlar e predizer projetos, processos e produtos de software.
Conforme Pressman (2010), medio comum no campo da Engenharia. Consumo de energia, peso, dimenses
fsicas, temperatura, voltagem e vrias outras medidas so utilizadas rotineiramente pelas vrias reas da Engenharia.
Importante!
No campo da Engenharia de Software a medio til principalmente quando relacionada ao processo, projeto
e produto de software.
Pode ser aplicada ao processo de software com o objetivo de melhor-lo continuamente. No caso do projeto
de software, as medidas podem auxiliar nas estimativas de prazos e custos, no controle de qualidade, na avaliao
da produtividade, no controle do projeto e na tomada de decises, conforme o projeto evolui. As medidas relacio-
nadas ao produto de software focalizam atributos especficos de artefatos e so coletadas medida que tarefas
tcnicas (anlise, projeto, codificao e teste) so conduzidas.
Pressman (2010), no contexto da engenharia de software, define medida como um valor que fornece uma indi-
cao quantitativa da extenso, quantidade, dimenso, capacidade ou tamanho de algum atributo de um produto ou
processo.
Na definio mais geral, medio o ato de determinar uma medida.
O IEEE Standard Glossary define mtrica como uma medida quantitativa do grau em que um sistema, componente
ou processo possui um determinado atributo.
Quando um nico ponto de dados foi coletado (como, por exemplo, o nmero de erros descoberto em um nico
componente de software) uma medida foi estabelecida.
Medio ocorre como resultado da coleo de um ou mais pontos de dados (por exemplo, um certo nmero de
revises de componentes e testes de unidade so investigados para coletar medidas do nmero de erros em cada um).
Uma mtrica de software relaciona as medidas individuais de algum modo, como, por exemplo, o nmero mdio de
erros encontrados por reviso ou nmero mdio de erros encontrados por teste unitrio.
Um engenheiro de software coleta medidas e desenvolve mtricas de modo que indicadores sejam obtidos. Um
indicador uma mtrica ou combinao de mtricas que fornece profundidade na viso do processo, projeto ou pro-
duto de software.
Um indicador fornece um parmetro que permite ao gerente do projeto ou engenheiros de software ajustarem o
processo, projeto ou produto para torn-lo melhores e gerenciveis.

6
A figura 1 ilustra esses conceitos.
Figura 1: Viso Geral sobre Medida, Mtrica e Indicadores

Fonte: baseado em [PRESSMAN, 2010]
Uma grande variedade de mtricas j foram propostas, mas nem todas mostram resultados satisfatrios.
Isso ocorre por vrios fatores: algumas exigem, por exemplo, medies muito complexas, outras so muito restritas,
limitando sua aplicao, e outras violam as noes bsicas dos atributos de um software (qualidade, por exemplo).
As mtricas de software consideradas efetivas devem possuir alguns atributos. Dentre eles podemos citar:
Simples e computveis: deve ser relativamente fcil aprender como derivar a mtrica e seu clculo no deve
exigir esforo ou tempo exagerado.
Empricas e intuitivamente persuasivas: a mtrica deve satisfazer s noes intuitivas do engenheiro de
software sobre o atributo do produto que est sendo considerado.
Consistentes e objetivas: a mtrica deve produzir sempre resultados que no sejam ambguos.
Independentes da linguagem de programao: mtricas devem ser baseadas no modelo de anlise, modelo de
projeto ou na estrutura do programa.
Mecanismo efetivo para realimentao de alta qualidade: isto , a mtrica deve levar a um produto final da
mais alta qualidade.
Enfim, as mtricas devem permitir a comparao dos resultados para medir qualidade, eficincia, custo, produtivi-
dade, dentre outros aspectos mensurveis da anlise, desenho, codificao e testes de software.
Classificao das Mtricas de Software

Existem muitas classificaes para mtricas de software. Um software pode ser medido orientado ao tamanho, a
funes, aos objetos, aos recursos humanos envolvidos, a qualidade e pela produtividade, dentre outras medies.
7
Apresentamos algumas classificaes de mtricas no Existem outras classificaes, como mtricas pblicas
que se segue. e mtricas privadas.
As mtricas privadas se aplicam ao indivduo e as

Classificao quanto ao objeto:
informaes e resultados so de divulgao restrita. Os
dados coletados com base individual devem ser privados e
mtricas de produto: so relacionadas complexi-
servir como indicadores apenas para o indivduo. Servem
dade, tamanho, qualidade (confiabilidade, manu-
para ajudar o engenheiro de software a aperfeioar seu
tenibilidade, etc) do software produzido.
trabalho individual. Algumas mtricas so privadas de
mtricas de processo: referem-se ao processo de
uma determinada equipe (por exemplo, proporo de
concepo e desenvolvimento do software, me-
defeitos por indivduo).
dindo por exemplo, o processo de desenvolvimen-
to, tipo de metodologia usada e tempo de desen-
As mtricas pblicas tm origem privada, mas acabam
volvimento.
por serem divulgadas para toda a equipe. Elas permitem
Classificao quanto ao critrio utilizado na sua de- que as organizaes realizem mudanas estratgicas para
terminao: melhorar o processo de desenvolvimento do software.
mtricas objetivas: so obtidas atravs de regras Tipos de Mtricas de Software

bem definidas, sendo a melhor forma de possibilitar
comparaes posteriores consistentes. Nessa H um grande nmero de mtricas de software, que
categoria, os valores obtidos devem ser sempre normalmente so aplicadas de forma isolada e considera-
os mesmos, independente do instante, condies das insatisfatrias por grande parte dos desenvolvedores.
ou indivduos que os determinam. A determinao
dessas mtricas passvel de automatizao (por No passado, vrias mtricas e uma srie de processos
exemplo, nmero de linhas de cdigo). foram propostos, mas a maioria no possua uma base
terica suficiente e/ou uma significativa validao experi-
mtricas subjetivas: podem partir de valores,
mental. Vrias delas foram definidas e, em seguida, testa-
mas dependem de um julgamento, que tambm
das e utilizadas em apenas um ambiente limitado. Apesar
um dado de entrada, para serem levantadas (por
de, em alguns casos, existirem relatos de validao ou de
exemplo, o modelo de estimativa de custo, que de-
aplicao dessas mtricas, testes ou uso em ambientes
pende da classificao do tipo de software).
diferentes produziram resultados no esperados. Essas
diferenas acabam por no serem surpreendentes, uma
Classificao quanto ao mtodo de obteno:
vez que faltam definies claras e hipteses de testes bem
definidas.
mtricas primitivas: so aquelas que podem ser
observadas diretamente em uma nica medida Assim, existe um grande nmero de mtricas que voc
(por exemplo, o nmero de linhas de cdigo, erros pode utilizar, mas voc deve notar que apenas algumas
indicados em um teste de unidade ou ainda o total tm sido amplamente utilizadas ou aceitas.
de tempo de desenvolvimento de um projeto).
mtricas compostas: so as combinaes de uma Apesar de tudo, se voc construir uma aplicao apoia-
ou mais medidas (por exemplo, o nmero de erros da por algumas das mtricas e modelos disponveis, esco-
encontrados a cada mil linhas de cdigo ou ainda lhidas de forma cuidadosa, elas podero produzir resulta-
o nmero de linhas de teste por linha de cdigo). dos teis se forem utilizadas de acordo com o ambiente
especificado.
8
Nos prximos tpicos apresentaremos alguns tipos de Tanto os parmetros como os fatores de ponderao
mtricas. constantes na tabela T1 so propostos pelo modelo e, a
princpio, so fixos.
Mtricas de Dimenso de Software
Ento, nesse passo, voc ter que estimar a quantida-
Linhas de Cdigo (LOC- Lines of Code) de de cada parmetro previsto para o software a ser de-
Podemos dizer que, pelo menos at hoje, essa a me- senvolvido e atribuir um fator de ponderao para cada
dida mais utilizada para medir o tamanho de um progra- um deles.
ma. de fcil definio e preciso, apesar de que algumas
dvidas podem surgir na contagem do que se considera Uma grande questo que surge como minimizar a
linhas de cdigo. subjetividade na atribuio desses fatores de ponderao,
Por exemplo, podem surgir dvidas quanto a conside- porque isso pode variar de pessoa para pessoa.
rar ou no linhas em branco, comentrios, trechos no-
-executveis, mltiplas declaraes por linha e vrias li- O IFPUG- International Function Points Users Group
nhas por declarao, assim como a questo das linhas de disponibiliza uma srie de recomendaes visando mini-
cdigo repetidas ou reusadas. mizar essa subjetividade.
O mais usual contar qualquer linha que no seja linha Uma vez preenchida a Tabela T1, voc ter o valor de
em branco ou comentrio, independentemente do nme- Contagem Total, o qual ser utilizado no terceiro passo do
ro de declaraes por linha. clculo.
Mtricas calculadas por esse mtodo podero somente Tabela T1: Tabela para Pontos por Funo
ser comparadas se referirem mesma linguagem de progra-
mao e se o estilo de programao estiver normalizado.
Porm, caro aluno, vale lembr-lo que a qualidade do

cdigo fonte no pode ser medida pela quantidade de li-
nhas de cdigo e sim pela organizao de tais linhas visan-
do manuteno e reuso.
Pontos por Funo (PF ou FP- Function Points)

[2] No segundo passo de clculo dos pontos por fun-
uma medida baseada nos modelos e ciclos de vida o, voc ter que avaliar 14 questes (Quadro Q2) tam-
tradicionais de desenvolvimento de software, proposta bm relacionadas a funcionalidades do software a ser de-
para medir o tamanho estimado do software no incio senvolvidos.
do desenvolvimento. No modelo proposto para o clculo
de Pontos por Funo, voc tem que seguir trs passos, Para cada uma dessas perguntas, voc ter que atri-
conforme descritos a seguir. buir um valor de influncia, obedecendo uma escala pro-
posta pelo modelo (Quadro Q1).
[1] No primeiro passo, ter que preencher a Tabela T1,
apresentada a seguir. Note que nessa tabela h parmetros Quadro Q1: Escala de Influncia
ligados s funcionalidades do software a ser desenvolvido,
bem como fatores de ponderao relacionados a cada um
desses parmetros.
9
Quadro Q2: 14 perguntas relacionadas s funcionalidades
Para evitar o problema da subjetividade ao avaliar a influncia de cada funcionalidade, o IFPUG desenvolveu
recomendaes a serem seguidas.
No final desse segundo passo, voc ter a soma das influncias de cada uma das 14 perguntas.
O valor dessa soma variar de um mnimo de 0 (todas as 14 perguntas tendo valor 0) a um valor mximo de 70
(todas as perguntas tendo valor igual a 5).
[3] No terceiro passo, faz-se uso de uma expresso emprica proposta pelo modelo para obteno dos pontos por
funo:
No captulo 2 voltaremos a falar sobre esse tipo de mtrica e veremos sua aplicao em algumas tcnicas de
estimativas de custo e prazo de desenvolvimento.
Antes de prosseguir com o estudo, recomendamos que voc acesse o site do IFPUG ou BFPUG e se familiarize com
as recomendaes propostas para a utilizao do modelo.
Leia tambm o material disponibilizado no link.
Atravs dele voc tomar conhecimento em detalhes das vrias etapas que tem que seguir para obter essa medida
de funcionalidade do software.
10
Importante ! n1 o nmero de operadores nicos e

n2 o nmero de operandos nicos do programa.
Uma das melhores referncias sobre Pontos por
Funo o site do IFPUG- International Function Comprimento do Programa
Point Users Group (http://www.ifpug.org), ou sua re-
presentao brasileira oficial, BFPUG - Brazilian Func- Enquanto o vocabulrio a soma dos smbolos (tokens)
tion Point Users Group (http://www.bfpug.com.br/). diferentes, o comprimento do programa (N) a soma do
total de operadores e operandos, sendo dado como:

System Bag
uma medida de dimenso total de um software, de-

terminada a partir das funcionalidades descritas em espe- onde
cificaes formais. N1 o nmero total de operadores e
O algoritmo de clculo se difere por se aplicar a siste- N2 o nmero total de operandos do programa.
mas orientados por dados ou orientados por processos. Acredita-se que a mtrica de comprimento mais
Um dos objetivos dessa mtrica maximizar o quociente objetiva e eficiente que o LOC.
Bag/Custo total no desenvolvimento do projeto.
Volume do Programa
Mtricas de Halstead O volume de um programa, medido em bits, dado em
funo do seu comprimento (N) e do seu vocabulrio (n):
um conjunto de mtricas baseadas na teoria da
informao. Essas mtricas se aplicam a vrios aspectos do
software, diferentemente da maior parte das mtricas, que
tratam um aspecto particular, e tambm so usadas para
avaliar o esforo global de desenvolvimento do software.
Mtricas de Complexidade de Software
Assim como as mtricas de dimenso de software, as
O Vocabulrio (n), Comprimento (N) e Volume (V) so
mtricas de complexidade foram criadas de acordo com
mtricas que so aplicadas especificamente ao software
os modelos tradicionais de desenvolvimento e podem
final. Tambm so especificadas frmulas para calcular
ser computadas no incio do ciclo de desenvolvimento de
o esforo total (E) e tempo de desenvolvimento (T) de
software, para o maior sucesso na gerncia do processo
software.
de software. So medidas deste tipo de mtrica:
Vocabulrio do Programa
Complexidade Ciclomtica - v(G)
O software visualizado como uma sequncia de sm- A Complexidade Ciclomtica parte do princpio que a
bolos (tokens), sendo cada smbolo classificado em opera- complexidade depende do nmero de condies (caminhos
dores ou operandos. Dessa forma, o vocabulrio do pro- lgicos), correspondendo ao nmero mximo de percur-
grama (n) definido como: sos linearmente independentes em um software. A ideia
que, medindo a complexidade do programa, voc sai-
ba quantos caminhos lgicos deve testar. Isso auxilia no
desenvolvimento e nos testes do software. Essa mtrica
pode ser representada atravs de um grafo de fluxo de
onde controle, onde os ns representam uma ou mais instru-
11
es sequenciais e os arcos orientados indicam o sentido Fluxos de informaes na estrutura de um programa

do fluxo de controle entre vrias instrues. so considerados medidas de complexidade de software,
sendo comparados com a complexidade ciclomtica e
A complexidade ciclomtica de um determinado grafo mtricas de Halstead. Esse mtodo conta o nmero de
pode ser calculada atravs de uma frmula da teoria dos parmetros de entradas (fan-in) e sadas (fan-out), sendo
grafos:
definido como:
onde
e o nmero de arestas Uma experincia de validao dessa mtrica foi reali-
n o nmero de ns do grafo. zada na concepo e desenvolvimento de um ncleo para
o sistema operacional UNIX. Alm disso, fluxo de informa-
A complexidade ciclomtica pode ter vrias interpre-
taes. Por exemplo, foi verificado que a produtividade o tambm permite estimar, com uma certa preciso, o
diminui de forma no linear proporcionalmente ao au- esforo de manuteno.
mento da densidade dos pontos condicionais. Tambm foi
relacionada com os esforos de depurao e manuteno, Mtricas de Qualidade de Software
podendo ser utilizada para estimar custos a partir do pro-
jeto detalhado dos mdulos. Qualidade uma caracterstica que, nos modelos
O interesse na mtrica de complexidade ciclomtica tradicionais de desenvolvimento de software, pode ser
levou sua normalizao. Posteriormente, foram defi- medida em cada fase do ciclo de desenvolvimento de
nidas outras cinco mtricas: complexidade da unidade software. Mtricas para a qualidade na fase de projeto,
real, complexidade essencial, complexidade do projeto por exemplo, foram propostas h dcadas.
de mdulos, complexidade total do projeto e complexi-
dade de integrao. Essas mtricas foram utilizadas para
Os primeiros estudos sobre mtricas mostram mais re-
identificar e minimizar a complexidade em cdigos no
latos e experincias com mtricas de dimenso e comple-
estruturados, decidindo sobre o nmero de testes neces-
xidade; posteriormente algumas reas que tratam as ca-
srios para uma cobertura total das possveis execues,
ractersticas de qualidade de software foram investigadas.
eliminando a redundncia e restringindo a complexidade
de mdulos produzidos a um nvel aceitvel.
Corretude, eficincia, portabilidade, confiabilidade,
Nmero de Ns usabilidade, modularidade, grau de reutilizao e facilida-
de de manuteno (manutenibilidade) so caractersticas
Corresponde ao nmero de ns em um grafo de fluxo
ligadas qualidade de software.
de controle que representa a sequncia de controle de
execuo de instrues num programa. Um n definido
Mtricas de Funcionalidade
como uma passagem necessria das linhas direcionais
(arestas) no grafo, sendo assim uma proposta de mtrica Funcionalidade pode ser definida como a capacidade
de complexidade de software. de um software ser usado com eficincia e satisfao para
atingir objetivos especficos em um determinado ambien-
Fluxo de Informao
te. Podem-se destacar as seguintes caractersticas sobre a
funcionalidade do software:
12
Facilidade de aprendizagem: capacidade de um usu- aplicar, partindo das mtricas de manuteno corretiva.
rio atingir rapidamente um grau de proficincia ele- Mtricas tpicas dessa categoria so:
vada;
MTTF - Mean Time To Fail (Tempo Mdio at a
Usabilidade: capacidade do software interagir ami-
Falha): a probabilidade de uma falha ocorrer num
gavelmente com os usurios;
intervalo de tempo especificado;
Controle: capacidade de um produto em responder MTBF - Medium Time Between Failures (Tempo
de uma forma natural e consistente aos comandos e Mdio entre Falhas): o tempo mdio entre falhas.
entradas de dados fornecidos;
Utilidade: capacidade de resolver ou ajudar a resol- Existem modelos para descrever a ocorrncia de erros
ver problemas para os quais o software foi proposto; em funo do tempo, permitindo definir a confiabilidade
e o MTTF. Partindo dos seguintes pressupostos:
Eficincia: capacidade de resolver problemas de for-
ma rpida e econmica.
Entradas de testes so exemplos aleatrios de
Uma questo que bastante discutida em relao a entradas no sistema;
esse tipo de mtrica a subjetividade que pode haver em Todos os erros de software so observados;
seus clculos. Esforos tem sido realizados no sentido de Intervalos de erros so independentes uns dos ou-
minimizar essa questo. tros;
MTBF exponencialmente distribudo.
Mtricas de Manuteno Corretiva
Algumas mtricas foram propostas para medir ou pre- As seguintes equaes so definidas:
ver a manutenibilidade do software, j que erros encon-
trados no sistema e a sua eliminao rpida so caracters-
ticas importantes na avaliao da qualidade do software.
As mtricas de Halstead e de complexidade ciclomti-

ca podem ser utilizadas para prever a complexidade das
tarefas de manuteno de software. Elas podem ser utili-
zadas de forma eficaz para explicar ou prever a manuten-
o de software em sistemas distribudos. Podemos citar, onde:
por exemplo, as seguintes mtricas de complexidade para D o total de nmero de erros;
medir as atividades de manuteno em um sistema: b e c so constantes determinadas pelo tipo de softwa-
re ou de um software similar;
Nmero de erros detectados por aplicao de uma d(t) o nmero total de erros detectados no tempo
bateria de testes; Determinar b, c e D, que no uma tarefa bvia, pode
Nmero de erros detectados pelos usurios; estabelecer o sucesso da aplicao desse modelo de m-
Tempo mdio de resposta na resoluo de proble- trica de confiabilidade.
mas detectados;
Nmero de mudanas de projeto; Existem estudos relacionando a confiabilidade com
Nmero de alteraes no cdigo fonte. mtricas de dimenso e complexidade, como as de Halstead
Mtricas de Confiabilidade e de complexidade ciclomtica. Os trabalhos clssicos
nessa rea relacionam as mtricas de complexidade com
Mtricas de Confiabilidade a manuteno, medindo a complexidade em cada mdulo
So mtricas para estimar e dimensionar o esforo de e suas inter-relaes. A correlao entre a complexidade
depurao, como, por exemplo, a quantidade de testes a
13
e a manuteno pode ser assim explorada no sentido de relao ao nmero total de mtodos acessveis na
conseguir a reduo dos custos de manuteno. classe.
Medida de Abstrao dos Atributos (MAA - Mea-
Mtricas de Orientao a Objetos sure of Attribute Abstraction): razo do nmero de
atributos herdados por uma classe em relao ao
Existem mtricas voltadas especificamente aos aspec-
nmero total de atributos nas classes.
tos relevantes no contexto da programao orientada a
Mtodos ponderados por Classe (WMC - Wei-
objetos: mtricas de classe, mtricas de mtodos, mtri-
ghted Methods per Class): soma ponderada de to-
cas de herana, mtricas de acoplamento e mtricas do
dos os mtodos da classe.
sistema (caractersticas gerais do software orientado a
Mtodos Reusados (PMR - Percent of Potential
objetos), conforme apresentado a seguir.
Method uses actually Reused): percentual de reu-
so dos mtodos da classe.
Mtricas de Classes
Mtrica de Acesso aos Dados (DAM - Data Access
Cdigo Orientado a Funo (FOC - Function Orien- Metric): razo do nmero de atributos privados
ted Code): mede o percentual de cdigo no orien- em relao ao nmero total de atributos declara-
tado a objeto usado no programa. dos na classes.
Coeso de Classe (CCO - Class Cohesion): mede a Nmero de Ancestrais (NOA - Number Of Ances-
relao entre as classes. tors): nmero total de ancestrais de uma classe.
Dados Pblicos (PDA - Public Data): contabiliza o Nmero de Atributos Pblicos (NPA - Number of
nmero de acessos aos dados protegidos e pbli- Public Attributes): contabiliza o nmero de atribu-
cos de uma classe. tos declarados como pblicos em uma classe.
Encapsulamento dos Atributos (AHF - Attribute Nmero de Mtodos de Classe em uma Classe
Hiding Factor): razo entre a soma de todos os (NCM - Number of Class Methods): mede os mto-
atributos herdados de todas as classes do sistema dos disponveis em uma classe, mas no em suas
em considerao ao nmero total de atributos das instncias.
classes disponveis. Nmero de Parmetros por Mtodos (NPM -
Encapsulamento dos Mtodos (MHF - Method Hi- Number of Parameters per Method): nmero m-
ding Factor): razo entre a soma de todos os m- dio de parmetros por mtodo.
todos invisveis em todas as classes em relao ao Nmero de Referncias como Atributo (NRA -
nmero total de mtodos definidos em um deter- Number of Reference Attributes): contabiliza o n-
minado sistema. mero de ponteiros e referncias passadas como
Entropia de Complexidade da Classe (CEC - Class atributos de uma classe.
Entropy Complexity): mede a complexidade da Nmero de Tipos de Dados Abstratos (NAD - Num-
classe, baseada no contedo de suas informaes. ber of Abstract Data types): nmero de objetos de-
Falta de Coeso entre Mtodos (LCM - Lack of Co- finidos pelo usurio como atributos de uma classe
hesion between Methods): indica o nvel de coeso que so necessrios para instanciar um objeto da
entre os mtodos. referida classe.
Linhas de comentrio por Mtodo (CLM - Com- Nmero de Variveis de Instncia em uma Classe
ment Lines per Method): mede o percentual de (NIV - Number of Instance Variables): mede a rela-
comentrios no mtodo. o de uma classe com outro objeto do programa.
Medida de Abstrao das Funes (MFA - Mea- Percentual de Dados Pblicos (PPD - Percentage
sure of Functional Abstraction): razo entre o n- of Public Data): o percentual de dados pblicos
mero de mtodos herdados por uma classe em de uma classe.
14
Ponderao do Tamanho da Classe (WCS - Wei- tambm conhecida como fan-out da classe, ou
ghted Class Size): nmero de ancestrais mais o ta- como Acoplamento entre Objetos (CBO - Coupling
manho total de mtodos da classe. Between Objects) na famlia de mtricas de CK
Porcentagem de Mtodos Comentados (PCM - (Chidamber-Kemerer).
Percentage of Commented Methods): percentual Acoplamento de Classe (CP - Class Coupling):
de mtodos com comentrios em uma classe. mede as relaes entre as classes com base em
Privacidade Interna (INP - Internal Privacy): refere- suas trocas de mensagens.
se ao uso de funes de acesso classe, incluindo Fator de Acoplamento (CFA - Coupling Factor):
as chamadas da prpria classe. razo entre o nmero mximo possvel de
Respostas para uma Classe (RFC - Response For acoplamentos no sistema e o nmero atual de
a Class): nmero de mtodos dentre todos os acoplamentos possveis por herana.
mtodos que podem ser invocados em resposta
a uma mensagem enviada por um objeto de uma Mtricas de Herana
classe.
Construo Efetiva (FEF - Factoring Effectiveness):
Mtricas de Mtodos nmero de mtodos nicos dividido pelo nmero
total de mtodos.
Complexidade do Mtodo (MCX - Method Com- Potencial de Mtodos Sobrescritos (PMO - Percent
plexity): relaciona a complexidade com o nmero of Potential Method uses Overridden): percentual
de mensagens. de mtodos sobrescritos utilizados.
MAG (MAX V(G)): complexidade ciclomtica Nvel de Aninhamento Hierrquico da Classe
mxima dos mtodos de uma classe. (HNL - Class Hierarchy Nesting Level): mede a
Mdia de Complexidade dos Mtodos (AMC - profundidade de hierarquia em que cada classe
Average Method Complexity): soma da comple-
est localizada.
xidade ciclomtica de todos os mtodos dividido
Mtricas de Reuso de Mtodo (MRE - Method Reu-
pelo nmero total de mtodos.
se Metrics): indica o nvel de reuso dos mtodos.
Mdia do Tamanho dos Mtodos (AMS - Average
Nmero de Mtodos Herdados (NMI - Number of
Method Size): mede o tamanho mdio dos mto-
Methods Inherited): mede o nmero de mtodos
dos do programa.
que uma classe herda.
Medida de Polimorfismo (PFA - Polymorphism
Mtricas de Acoplamento
Factor ): razo entre o nmero atual de possibili-
dades de polimorfismo diferentes de uma classe
Acoplamento Aferente (AC - Afferent Coupling):
e o nmero mximo de possveis polimorfismos
nmero total de classes externas de um pacote
distintos da referida classe.
que dependem de classes de dentro desse pacote.
Nmero de Mtodos Sobrescritos (NMO - Num-
Quando calculada no nvel da classe, essa medida
ber of Methods Overridden): nmero de mtodos
tambm conhecida como Fan-in da classe,
redeclarados pela classe herdeira.
medindo o nmero de classes das quais a classe
Tipo de Especializao (SIX - Specialisation Index):
derivada e, assim, valores elevados indicam uso
indica o tipo de especializao.
excessivo de herana mltipla.
Acoplamento Eferente (EC- Efferent Coupling): Medida de Herana de Atributos (AIF - Attribute
nmero total de classes dentro de um pacote Inheritance Factor): razo entre a soma dos atri-
que dependem de classes externas ao pacote. butos herdados em todas as classes do sistema e
Quando calculada no nvel da classe, essa medida o nmero total de atributos disponveis na classe.
15
Profundidade da rvore de Herana (DIT - Depth Problemas Relatados por Classe (PRC - Problem
of Inheritance Tree): mede o nmero de ancestrais Reports per Class): mede os relatos de erros da
de uma classe. classe.
Nmero de Filhos (NOC - Number Of Children): Reuso do Sistema (SRE - System Reuse): percentu-
nmero total de filhos de uma classe. al de reuso de classes.
Categorizao (CAN - Category Naming): divide as
Proporo de Reuso (RER - Reuse Ratio): razo
classes em um conjunto semanticamente significa-
entre o nmero de superclasses dividido pelo
tivo.
nmero total de classes.
Profundidade Mdia de Herana (ADI - Average
Proporo de Especializao (SPR - Specialisation
Depth of Inheritance): diviso entre a soma de n-
Ratio): razo entre o nmero de subclasses dividi- veis de aninhamento de todas as classes pelo n-
do pelo nmero de superclasses. mero de classes.
Medida de Herana de Mtodo (MIF - Method Mdia de Ancestrais (ANA - Average Number of
Inheritance Factor): razo entre a soma dos Ancestors): determina o nmero mdio de ances-
mtodos herdados em todas as classes e o nmero trais de todas as classes.
total de mtodos disponveis em todas as classes. Densidade Funcional (FDE - Functional Density):
Proporo entre Profundidade e Largura (RDB - razo entre o nmero de linhas de cdigo e pontos
Ratio between Depth and Breadth): razo entre a de funo.
profundidade e a largura da hierarquia de classes. Modificao de Objetos Reusados (PRO - Percent

of Reused Objects Modfied): percentual de objetos
Mtricas do Sistema reusados que foram modificados.
Granularidade da Aplicao (APG - Application Medidas Aplicadas Metodologia gil

Granularity): nmero total de objetos dividido
pelo nmero total de pontos de funo. Caro aluno, a seguir esto listadas e definidas algumas
medidas para auxiliar uma equipe na escolha das melhores
Eficincia da Biblioteca de Objeto (OLE - Object
mtricas que possam ser utilizadas nas metodologias geis.
Library Effectiveness): razo entre o nmero total
de objetos reusados e o nmero total de objetos
Entre as mtricas apresentadas esto exemplos daque-
da biblioteca.
las que podem ser coletadas de forma automatizada, por
Complexidade Associada (ASC - Association Com- serem compostas de medidas quantitativas e objetivas.
plexity): mede a complexidade da estrutura asso-
ciada ao sistema. Dessas, algumas j foram apresentadas anteriormente,
Nmero de Hierarquias (NOH - Number Of Hierar- como: Linhas de Cdigo, Complexidade Ciclomtica,
chies): nmero de hierarquias distintas do sistema. Mtodos Ponderados por Classe, Falta de Coeso dos
Reuso de Classe (CRE - Number of time a Class Mtodos, Profundidade da rvore de Herana, Nmero
is Reused): mede as referncias a uma classe e o de Filhos, Acoplamento Aferente, Acoplamento Eferente.
nmero de aplicaes que reusam tal classe. Alm das mtricas j apresentadas, podemos citar:
Nmero de Rejeio de Classe (NCT - Number of Total de Linhas de Cdigo de Teste (TLCT): repre-
Classes Thrown away): mede o nmero de vezes senta o nmero total de pontos de teste do siste-
que uma classe rejeitada at que seja aceita. ma. Um ponto de teste considerado como um
16
passo do cenrio de um teste de aceitao, auto- A aplicao manual das mtricas bastante trabalhosa,
matizado ou como uma linha de cdigo de teste envolvendo uma srie de clculos e anotaes, o que
de unidade automatizado, descartando linhas em dificulta e torna essa atividade de medio propensa a
branco e comentrios. erros.
Sob esse prisma, torna-se bastante interessante a
Nmero de Linhas Alteradas: representa o nmero utilizao de ferramentas que automatizem e/ou orientem
de linhas (no apenas cdigo-fonte) adicionadas, tal processo de medio.
removidas e atualizadas no Repositrio de Cdigo
Unificado.
Nmero de Commits: representa o nmero de

commits efetuados no Repositrio de Cdigo Uni-
ficado.
Estimativas Originais: representa o total de pon-

tos (ou horas) originalmente estimados pela equi-
pe para todas as estrias da iterao.
Estimativas Finais: representa o total de pontos

http://paquimetro.reguaonline.com/
(ou horas) efetivamente reportadas como gastas
para implementar as estrias da iterao.
Nmero de Estrias Entregues: representa o n- As ferramentas que trabalham com aplicao de m-

mero total de estrias implementadas pela equipe tricas se dividem basicamente nos seguintes grupos:
e aceitas pelo cliente.
Ferramentas de especificao e organizao de
Nmero de Pontos Entregues: representa o n- requisitos
mero total de pontos implementados pela equipe
e aceitos pelo cliente. Ferramentas de modelagem
Ferramentas de estimativa de custo e esforo

Tempo: utilizado no clculo de diversas mtricas,
pode ser utilizado como durao (em meses, se- Ferramentas para coleta de mtricas especficas
manas, dias, etc.) ou como nmero de iteraes.
Alguns exemplos de ferramentas para esses propsitos
Tamanho da Equipe: geralmente utilizado no cl- so: Rational Requisite Pro, Borland CaliberRM, Borland
culo de mtricas, representa a quantidade de pes- Together, IBM Rational Rose, Costar, Cost Xpert, Estimate
soas na equipe. Easy Use Case, Enterprise Architect.
Esforo: uma medida que leva em conta o tamanho Assista a um vdeo sobre um caso prtico de uso de
da equipe durante um certo intervalo de tempo, mtricas ligadas s Mdias Sociais.
geralmente medido em pessoas-ms ou pessoas- http://youtu.be/9O8D3zY59w4 329
ano. Consideraes Sobre Mtricas
Ferramentas para Extrao de Mtricas
17
Independentemente das mtricas adotadas muito especifique as dependncias intertarefas que pre-
importante para as organizaes a coleta efetiva dessas cisam ter um forte acompanhamento do progresso
mtricas e o registro histrico dos projetos, formando
uma base de conhecimento que auxilie nos processos de
anlise, melhoria e tomada de deciso.
Vimos diferentes mtricas at o momento, porm mui-
tos fatores devem ser levados em considerao para a es-
colha das mtricas. Recomendamos que voc identifique
qual a necessidade de medio do projeto (qualidade,
produtividade, erros, falhas, etc) para, em seguida, adotar
mecanismos que permitam uma medio mais significati-
va e mais efetiva.
Estimativas de Software Fonte: http://hostintermex.com/img/slider/female-pushing.jpg
Estimativas conceitos fundamentais A estimativa de software vista tanto como arte quan-
to como cincia e o desenvolvedor conta com vrias tcni-
Caro aluno, quando estamos envolvidos em projeto cas teis para auxili-lo. As mtricas de processo e projeto
de software, antes mesmo de comearmos a realiz-lo, coletadas ao longo de projetos anteriores fornecem uma
precisamos lidar com alguns aspectos decisivos para o seu base importante para a gerao de estimativas quantita-
sucesso ou fracasso. Alguns destes pontos, estudados em tivas. Mas importante ressaltar, caro aluno, que a expe-
gerenciamento de projetos, so: escopo, custo, recursos rincia do pessoal envolvido pode ajudar imensamente
e cronograma. Observe que para lidar com estes pontos medida que as estimativas so desenvolvidas e revistas.
precisamos conhecer as estimativas de software.

O planejamento de projeto fornece um guia para a en-
genharia de software bem sucedida. A estimativa impor-
A estimativa imprescindvel para apurar custos,
tante porque estabelece uma base para todas as outras
alocar recursos e estabelecer cronogramas de trabalho.
atividades de planejamento de projeto.
Portanto, torna-se necessrio grande dedicao a este
assunto.
Normalmente, as estimativas so feitas dentro de um
Antes de um projeto iniciar necessrio estimar:
perodo de tempo limitado no incio do projeto e devem
ser atualizadas regularmente medida que o projeto
o trabalho a ser feito
avana. As abordagens modernas de engenharia de sof-
o custo do projeto
tware, como os modelos evolucionrios e modelos geis,
os recursos necessrios
assumem uma viso iterativa do desenvolvimento de
o tempo de incio e fim do projeto
software. Em tais abordagens, possvel revisitar a esti-
mativa medida que mais informaes so conhecidas
A seguir, necessrio estabelecer um cronograma de
permitindo, assim, revis-la quando o cliente solicita mo-
projeto que:
dificaes nos requisitos.
defina as tarefas e marcos da engenharia de sof- A estimativa de recursos, de custo e de cronograma,

tware exige experincia, acesso s informaes histricas con-
identifique os responsveis por cada tarefa sistentes e empenho nas previses quantitativas, quando
18
informao qualitativa, em alguns casos, tudo o que Facilitated Application Specification Technique que uma
pode se ter disponvel. abordagem que visa encorajar a criao de uma equipe
conjunta de clientes e desenvolvedores que trabalham
Toda estimativa tem incerteza e isso acaba acarretando juntos para identificar o problema, propor elementos de
riscos ao projeto. Se o escopo do projeto mal entendido soluo, negociar diferentes abordagens e especificar um
ou se os requisitos esto sujeitos a mudanas frequentes, conjunto preliminar de requisitos.
a incerteza e o risco podem se tornar perigosamente al-
tos. Discutiremos riscos no prximo captulo. Uma vez entendido o escopo, importante determinar
a viabilidade do projeto dentro das dimenses delimitadas
(tecnolgica, financeira, de tempo e de recursos). Isso
Planejamento do Projeto: definio do
importante para evitar dedicar esforo e dinheiro em um
escopo projeto que pode estar condenado ao fracasso desde o

incio.
Pressman (2010), faz uma interessante pergunta sobre
estimativas: Voc construiria uma casa sem saber quanto
iria gastar?. E fao a mesma pergunta a voc, caro alu-
Planejamento do Projeto: Estimativa de
no. Certamente sua resposta seria: no. Como a maioria Recursos
dos sistemas e produtos de software pode custar consi-
deravelmente mais do que construir uma casa, muito Uma tarefa importante no planejamento a estimativa
razovel fazer uma estimativa antes de se comear a criar de recursos necessrios para o desenvolvimento do
software. software. A figura 2, proposta por Pressman (2006), ilustra
os recursos com que devemos nos preocupar.
Pois bem, caro aluno, podemos dizer que o objetivo
do planejamento de projeto fornecer uma estrutura que
permita ao gerente fazer estimativas razoveis de recur-
sos, custo e cronograma (prazos).
A primeira atividade de planejamento do projeto de

software a determinao do escopo. O escopo do sof-
tware descreve os dados e o controle a serem processa-
dos, as funes e desempenho esperados, as restries, a
interface e a confiabilidade desejadas.
Normalmente no incio de um projeto h uma incer-

Figura 2: Recursos para o planejamento de estimativas
teza em relao a estes itens. Uma necessidade foi defi- Fonte: baseado em PRESSMAN [2006]
nida e metas e objetivos bsicos foram enunciados, mas
a informao necessria para definir o escopo, que pr- Notamos que o ambiente de desenvolvimento, que in-
-requisito para a estimativa, ainda no foi delineada. clui ferramentas de hardware e de software, fica na base
da pirmide. Esse ambiente fornece a infraestrutura para
Para isso, necessria uma intensa comunicao entre apoiar o esforo de desenvolvimento. Na camada inter-
desenvolvedores e clientes. A tcnica mais utilizada para mediria da pirmide encontramos os componentes de
isso conduzir uma reunio preliminar ou uma entrevis- software reusveis, que podem reduzir consideravelmen-
ta. Existem tcnicas mais avanadas que visam facilitar te os custos e o prazo de desenvolvimento. No topo da
essa comunicao. Como exemplo, podemos citar o FAST- pirmide est o recurso humano.
19
Para cada um dos recursos indicados na pirmide Tcnicas de Estimativas: Decomposio

necessrio especificar a sua descrio, uma declarao de
disponibilidade, a poca em que o recurso ser necessrio Na maioria das vezes, o problema de desenvolver uma
e o prazo durante o qual ele ser utilizado. estimativa de custo e esforo para um determinado proje-
to muito complexo para ser considerado como um todo.
Caro aluno, como vimos na disciplina Engenharia de
Software e de Requisitos, no incio os maiores custos es- Devido a isso, as tcnicas de decomposio do proble-
tavam relacionados ao hardware e no ao software. Na- ma em um conjunto de problemas menores se mostram
queles primeiros tempos, erros na estimativa do custo atrativas, pois se espera que, com essa diviso, se torne
de software tinham um impacto relativamente pequeno. mais fcil chegar soluo.
Hoje, geralmente, o software o componente mais caro de
todos os sistemas baseados em computador. Para sistemas A preciso da estimativa de um projeto depende dos
complexos, feitos sob encomenda, um erro de estimativa seguintes fatores:
grande pode fazer a diferena entre lucro e prejuzo.
1. o grau com que o planejador estimou adequada-
Infelizmente, a estimativa de custo e esforo para de- mente o tamanho do produto a ser construdo
senvolver software no uma cincia exata. Isso normal- 2. a aptido para traduzir a estimativa de tamanho em
mente decorre do fato de um grande nmero de variveis esforo humano, tempo transcorrido e dinheiro
humanas, tcnicas, ambientais e polticas afetar o custo 3. o grau com que o plano de projeto reflete a capa-
final do software e o esforo necessrio para desenvolv-lo. cidade da equipe de software
4. a estabilidade dos requisitos do produto e do ambien-
De qualquer modo, existem opes para auxiliar a con- te que apoiam o esforo de engenharia de software
seguir estimativas de custo e esforo que sejam confi-
veis, que segundo Pressman (2010), so: Como uma estimativa de projeto to boa quanto a
estimativa do tamanho do trabalho a ser realizado, o di-
Adie a estimativa at que o projeto esteja mais mensionamento representa o primeiro grande desafio do
adiantado: quanto mais tarde voc fizer a estimati- planejador de projeto.
va, maior a probabilidade de acertar. Infelizmente,
apesar de atraente, essa opo no prtica. Nor- Para a determinao do tamanho do produto a ser
malmente, o cliente deseja estimativas de custo e construdo, as abordagens mais utilizadas so:
prazo o quanto antes.
abordagem direta (medido em LOC, por exemplo)
Baseie as estimativas em projetos semelhantes,
abordagem indireta (medido em PF, por exemplo)
que j foram completados.
Use tcnicas de decomposio: essas tcnicas utili- Em relao s tcnicas de estimativa baseadas em LOC
zam uma abordagem do tipo dividir para conquis- e PF, elas diferem quanto ao nvel de detalhe necessrio
tar, que seria decompor o projeto em suas fun- para a decomposio:
es principais e atividades relacionadas.
Estimativa LOC: a decomposio considera que
Use um ou mais modelos empricos.
todas as funes podem ser decompostas em
importante ressaltar que essas opes dependem subfunes semelhantes a entradas de uma base
fundamentalmente dos dados histricos usados para ali- de dados histrica (quanto maior for o grau de
mentar a estimativa. Se no existem dados histricos, as particionamento, mais provvel ser que estimati-
estimativas sero precrias. vas precisas de LOC possam ser desenvolvidas)
20
Estimativa PF: ao invs de focalizar a funo, es- a varivel de estimativa tamanho (T), para cada funo
timada cada uma das caractersticas do domnio (LOC) ou valor do domnio de informao (PF).
de informao (entradas, sadas, arquivos de da-
dos, consultas, interfaces externas), bem como os Um exemplo de clculo de um valor esperado para T
14 valores de ajuste de complexidade. pode ser a mdia ponderada:
Como alternativa, o planejador pode escolher outros

componentes para dimensionar, como classes, objetos, ca-
sos de uso, modificaes ou processos do negcio afetados.
Uma vez determinado o valor esperado para a varivel

Mtricas referenciais de produtividade (por exemplo,
de estimativa de tamanho T, os dados histricos de LOC
LOC/PM ou PF/PM) so ento aplicadas varivel de es-
ou PF so aplicados.
timativa adequada e o custo ou esforo correspondente
funo derivado. A seguir, as estimativas de funo
A seguir, por meio de alguns exemplos, vamos ver a
so combinadas para produzir uma estimativa global para
aplicao do que descrevemos, adotando algumas tcni-
todo o projeto.
cas de estimativas.
A experincia mostra que frequentemente h uma
variao nos valores das mtricas de produtividade de uma Exemplos de Estimativas Baseadas em LOC
organizao. Portanto, o uso como referencial de um nico
valor obtido de uma dada mtrica no recomendvel. Exemplo 1
O ideal que a mdia de cada mtrica deva ser calcu- Suponha um determinado software que ser desen-
lada por domnio de projeto. Os projetos devem ser agru- volvido. Este software do tipo CAD Computer-Aided
pados por tamanho de equipe, rea de aplicao, comple- Design, ou seja, tem uma aplicao cientfica. Aps a an-
xidade e outros parmetros relevantes. A seguir, mdias lise do escopo do software, suas funes principais foram
locais dos domnios devem ser calculadas. identificadas e so relacionadas na tabela 1.

No caso de estimativas de um novo projeto, ele deve Em seguida, um intervalo de estimativa de LOC de-
ser primeiro classificado num domnio e depois a mdia senvolvido para cada funo.
da mtrica do domnio adequado deve ser usada para ge-
rar a estimativa. Esse intervalo considera as estimativas como otimista,
mais provvel e pessimista.
Independente da varivel de estimativa que usada
(LOC, PF, nmero de classes, nmero de casos de uso, Os valores das estimativas apresentados na tabela 1,
etc), o planejador comea estimando um intervalo de va- para cada funo, foram obtidos utilizando a expresso
lores para cada funo (LOC, por exemplo) ou o valor do para T j apresentada (T = ( Tot + 4Tmp + Tpess ) / 6).
domnio de informao (PF, por exemplo).
Por exemplo, para a funo Recursos de Anlise 3D,
Usando dados histricos e/ou intuio, so estimados foram obtidas estimativa otimista = 3800 LOC; mais prov-
um valor de tamanho otimista (Tot), um mais provvel vel= 6500 LOC; pessimista= 8600 LOC.
(Tmp) e um pessimista (Tpess) para cada funo (LOC) ou
contagem (PF - para cada valor do domnio de informa- Estes valores, aplicados na equao para T, produzem
o). Isso possibilita o clculo de um valor esperado para um valor esperado de 6400 LOC.
21
Tabela 1: Principais funes identificadas Tabela 2: Estimativas de Tamanho Otimista, Mais Pro-
vvel e Pessimista (em LOC)
Aps o clculo das estimativas de LOC para cada

A tabela 3 apresenta o clculo do tamanho de cada
funo, foi identificada uma estimativa de 32400 LOC para
uma das funes (em LOC) utilizando a expresso apre-
o sistema a ser desenvolvido.
sentada anteriormente T = (Tot + 4.Tmp + Tpess) / 6.
Considerando que uma anlise de dados histricos

Tabela 3: Clculo do tamanho de cada funo
revelou que a produtividade organizacional mdia para
sistemas desse tipo de 500 LOC/pessoas-ms e que o
valor bruto da mo de obra de R$ 4.000,00 por pessoa-
ms, o custo por linha de cdigo de aproximadamente:

Portanto, o custo total estimado para o projeto de:

Utilizando a estimativa de tamanho obtida na tabela 3
e os dados do valor bruto da mo de obra e produtividade
fornecidos anteriormente, podemos calcular as estimati-
vas de esforo e custo total conforme indicado a seguir.
O esforo necessrio estimado para desenvolver o pro-
jeto de:
Exemplo 2
A tabela 2 apresenta as estimativas de tamanho

otimista, mais provvel e pessimista para cada uma
das funes a serem implementadas no software CAD
mencionando no exemplo 1. Considerando que a que
a empresa de software responsvel em desenvolver o
projeto produz 400 LOC/por ms, com um valor bruto de
Exemplos de Estimativas Baseadas em
mo de obra de R$ 3000,00 por pessoa-ms, podemos,
Pontos Por Funo
baseado nesses dados, obter a estimativa de custo e
No caso de pontos por funo (PF), conforme falamos
esforo necessrios para construir o software usando a
anteriormente, a decomposio tem foco nos valores do
tcnica de estimativa baseada em LOC.
22
domnio de informao ao invs das funes do software. Para cada fator de ajuste, um nmero atribudo con-
Neste mtodo, a estimativa registrada numa tabela, forme sua influncia no fator em anlise, de acordo com a
como a tabela 4, com os valores estimados do domnio de escala mostrada no quadro 2.
informao e com atribuio de valores aos 14 fatores de
ajuste de complexidade (veja quadro 1). Quadro 2: Escala de Influncia
Tabela 4: Tabela sugerida na anlise por ponto de funo

Fonte: baseado em PRESSMAN [2010]
Utilizando a expresso emprica proposta pelo mode-

lo, conforme citado no captulo 1, pode-se determinar a
quantidade estimada de pontos por funo:
Uma vez que se tenha obtido a produtividade mdia

da equipe de desenvolvimento para esse tipo de projeto
Na tabela 5, temos relacionados os Fatores de Ponde- e o valor bruto salarial, pode-se, analogamente ao que foi
rao para cada parmetro utilizado no modelo de clculo feito para LOC, calcular as estimativas para o custo total
de pontos por funo. do projeto e para o esforo necessrio para conclu-lo.
Tabela 5: Fatores de Ponderao Exemplo 3
Suponha que a sua empresa foi contratada para desen-

volver determinado software. Considere que a empresa
tem um alto grau de maturidade no desenvolvimento de
software.
Devido a isso, tem procedimentos de coleta de da-

dos, clculo de mtricas e armazenamento desses valores
numa base de dados, organizada considerando softwares
do mesmo domnio de aplicao.
As questes apontadas no quadro 1 so os 14 fatores
de ajustes propostos quando se utiliza Ponto por Funo. Aps uma anlise preliminar na base de dados da em-
presa, e considerando software do mesmo domnio de
Quadro 1: Fatores de ajustes aplicao do software a ser desenvolvido, obtiveram-se
os valores relacionados na tabela 6.
Utilizando os dados do exemplo 2 proposto e consi-

derando que o fator de ponderao (peso) seja simples
para todos os parmetros da tabela 6 e que os valores de
ajuste de complexidade para os 14 fatores de ajustes se-
jam considerados de influncia moderada, estime o custo
e o esforo necessrios para construir o software usando
a tcnica de estimativa baseada em PF.
23
Considere que a produtividade mdia para sistemas Estimativa de PF = 321 PF. Dessa forma, podemos
desse domnio seja de 5 PF/pm. calcular as estimativas de Custo Total Estimado do projeto
e Esforo necessrio para desenvolv-lo, conforme
Tabela 6: Valores obtidos na base de dados da empresa apresentado a seguir.
Na tabela 7, os valores de Contagem apresentados na

5 coluna, foram obtidos atravs da expresso T = (Toti-
mista + 4*Tmais provvel + Tpessimista) / 6. Modelos de Estimativas
Uma vez obtidos esses valores de Contagem, foram Modelos de Estimativa Empricos
considerados os valores de ponderao simples (Peso),
conforme tabela 5. Esses valores esto relacionados na 6 Alguns modelos de estimativa para software usam fr-
coluna da tabela 7. mulas empricas. Essas frmulas so derivadas usando an-
lise de regresso de dados coletados de projetos anteriores.
De posse dos valores de Contagem e Peso, obtemos a
7 coluna da Tabela 7, que nada mais do que a multipli- Normalmente, usa-se uma amostra limitada de proje-
cao da Contagem pelo Peso. tos. Cada modelo de estimativa normalmente adequado
A soma dos valores dessa 7 coluna resultar no valor para um determinado conjunto de classes de software e
da Contagem Total, que, no caso, foi de 346. ambientes de desenvolvimento, ou seja, so dependentes
dos dados dos projetos que foram usados para obt-los.
Tabela 7: Obteno da Contagem Total
Devido a isso, geralmente, esses modelos de estimativa
devem ser adaptados para as condies locais da empresa.
claro que, antes de serem usados na sua empresa,

caro aluno, esses modelos devem ser testados usando re-
sultados de projetos finalizados. Os dados estimados pelo
modelo devem ser comparados aos resultados reais e a efi-
Como no enunciado do exemplo foi dito para considerar ccia do modelo deve ser analisada para as condies lo-
os valores de ajuste de complexidade para os 14 fatores cais. A estrutura geral dos modelos empricos tem a forma:
de ajustes como de influncia moderada (=2, conforme
Quadro 2), isso resultar numa valor de 14 * 2 = 28.
Substituindo os valores de Contagem Total ( = 346)

e soma dos 14 fatores de ajustes ( = 28) na expresso , onde
obtemos: A, B, c = so constantes derivadas empiricamente
24
E = esforo em pessoas-ms
ev = varivel de estimativa (LOC ou PF)
A maioria dos modelos de estimativa tem alguma for-

ma de fator de ajuste ao projeto. Isso permite que a va- Problema:
rivel E seja ajustada por caractersticas especficas do
projeto, tais como: Suponha que a sua empresa foi contrata para desen-
volver um software de CAD. Considere que a empresa
tem um alto grau de maturidade no desenvolvimento
complexidade do problema
de software e que, devido a isso, tem procedimentos de
experincia da equipe coleta de dados, clculo de mtricas e armazenamento
ambiente de desenvolvimento desses valores numa base de dados, organizada conside-
rando softwares do mesmo domnio de aplicao. Aps
A seguir, apresentamos alguns exemplos de modelos uma anlise preliminar na base de dados da empresa, e
empricos orientados a PF para esforo (E): considerando softwares do mesmo domnio de aplicao
do software a ser desenvolvido, obtiveram-se, para cada
funo a ser implementada no software, os valores de ta-
manho otimista, mais provvel e pessimista, em LOC, re-
lacionados na tabela 8.
E agora, alguns exemplos de modelos empricos orien- Considerando isso e utilizando os dados fornecidos na
tados a LOC para esforo (E): tabela 8, calcule:
a estimativa de tamanho do software em LOC

importante ressaltar, caro aluno, que para os mes-
o esforo
mos valores de PF ou LOC, os modelos vo gerar resul-
a durao do projeto
tados diferentes (porque foram gerados, cada qual, em
o tamanho da equipe
alguns domnios de aplicao especficos).
o nmero de pginas de documentao.
Portanto, para utilizar esses modelos, eles devem ser

Tabela 8: Tamanhos em LOC para cada funo a ser
adaptados para as necessidades locais.
implementada
Exemplo de Aplicao do Modelo Emprico

Soluo
Como exemplo de aplicao de modelo emprico, vamos
utilizar o modelo de Walston-Felix para fazer estimativa.
a. Para calcular a estimativa do tamanho do software em LOC,
Esse modelo apresenta, alm da expresso para esti- calculamos a estimativa de tamanho para cada funo. Para
mativa de esforo vista anteriormente, as seguintes ex- isso, utilizamos a expresso da mdia ponderada apresen-
presses empricas de estimativa: tada anteriormente: T = ( Tot + 4Tmp + Tpess ) / 6
25
Dessa forma, chegamos aos resultados mostrados na O COCOMO 81 apresentado na forma de um conjunto
Tabela 9. de modelos divididos hierarquicamente em trs nveis:
Bsico, Intermedirio e Avanado.
Tabela 9: Clculo do tamanho de cada funo a ser im-
plementada no software O modelo 1 COCOMO Bsico, calcula o esforo
do desenvolvimento de software em funo do ta-
manho estimado do programa expresso em linhas
de cdigo estimadas.
O modelo 2 COCOMO Intermedirio, calcula o
esforo de desenvolvimento de software em fun-
o do tamanho do programa e de um conjunto de
b. Esforo = E = 5,2 x (KLOC)0,91 = 5,2 x (34,317) 0,91 @ direcionadores de custo, alternativamente chama-
129,81 PM dos atributos ou fatores de software, que incluem
avaliaes subjetivas do produto, do hardware, do
c. Durao do Projeto = D = 4.1 x (KLOC) 0.36
= 4,1 x
pessoal e dos atributos do projeto.
(34,317)0,36 @ 14,64 meses
O modelo 3 COCOMO Avanado, incorpora to-
d. Tamanho da Equipe = S = 0.54 x (E) 0.6
= 0,54 x
das as caractersticas da verso intermediria, in-
(129,81)0,6 @ 10 pessoas
cluindo a avaliao do impacto dos atributos do
e. Pginas de Documentao: DOC = 49 x (KLOC) 1.01 software e da equipe desenvolvedora em cada
= 49 x (34,317)1,01 @ 1742 pginas passo do processo de engenharia de software.
Note que nas expresses acima deve-se utilizar KLOC Depois da anlise dos requisitos funcionais do sof-
(e no LOC) e que PM significa pessoa-ms. tware, o tamanho da aplicao deve ser estimado em
milhares de linhas de cdigo (KLOC) e o projeto deve ser
Modelo COCOMO - Conceitos Bsicos classificado em um dos trs modos de desenvolvimento,
identificados por Boehm (1981): orgnico, embutido ou
COCOMO- COnstructive COst MOdel (Modelo de semi destacado.
Custo Construtivo) um modelo emprico de estimativa
de software que foi derivado atravs da coleta de dados No modo orgnico, equipes relativamente peque-
de um grande nmero de projetos de software. bem nas desenvolvem sistemas num ambiente alta-
documentado, compatvel com ferramentas comerciais e mente familiar, in-house. Nesse modo de desen-
de domnio pblico e amplamente utilizado. volvimento, a maior parte das pessoas engajadas
Sua primeira verso data de 1981 e por isso referen- no projeto tem experincia prvia com sistemas
ciado como COCOMO 81 (tambm conhecido como CO- similares na organizao e entendimento comple-
COMO bsico). A verso atual denominada COCOMO 2. to do sistema. Outras caractersticas do modo or-
gnico so: ambiente estvel de desenvolvimento
Apresentaremos a seguir detalhes desse modelo. com pouca necessidade de inovao e inexistncia
de requisitos de entrega rgidos; uso de algoritmos
COCOMO 81 simples; tamanho relativamente pequeno, com
Apresentado por Boehm (1981), o COCOMO um projetos na faixa de at 50.000 linhas de cdigo.
modelo desenvolvido para estimar esforo, prazo, custo O principal fator que distingue um projeto de sof-
e tamanho da equipe para um projeto de software. Todas tware de modo embutido ou restrito a neces-
as referncias ao COCOMO encontradas na literatura sidade de seguir restries rigorosas. O produto
publicadas at 1995 so citaes desse modelo. a ser desenvolvido dever operar dentro de um
26
contexto complexo de hardware, software e regras Direcionador de custo uma caracterstica de desen-
e procedimentos operacionais. So projetos de volvimento de software que tem efeito aumentativo ou
software caracterizados por serem relativamente diminutivo na quantidade de esforo de desenvolvimento
grandes, com muita necessidade de inovao, que final do projeto. Boehm (1981) definiu 15 direcionadores
demandam altos custos de verificao e validao. de custo para o COCOMO que, segundo ele, provocam im-
Caro aluno, podemos citar como exemplos de pro- pacto significativo na produtividade e nos custos do pro-
jetos do modo embutido: projeto de sistema de jeto. O fator m(X) da equao de estimativa de esforo de
transferncia eletrnica de fundos e projeto de desenvolvimento o produto dos 15 direcionadores de
sistema de controle de trfego areo. custo. Definies completas dos direcionadores de custo
O modo semidestacado aplicado em projetos de esto descritas no trabalho de Boehm (1981).
software com caractersticas situadas entre os mo-
dos orgnico e embutido. Suas caractersticas bsi-
Estimativa do prazo de desenvolvimento
cas so: a equipe mescla grande e pouca experincia Alm de estimar o esforo, o COCOMO tambm apre-
com a aplicao e com a tecnologia e o tamanho do senta equaes para estimar o prazo de desenvolvimento
software pode chegar a 300.000 linhas de cdigo. nominal do projeto em meses e a diviso do esforo por
fases e atividades do projeto.
Estimativa de esforo de desenvolvimento Os modos de desenvolvimento Bsico e Intermedirio
As equaes de estimativa de esforo de desenvolvi- utilizam as mesmas equaes para determinar o prazo. As
mento so da forma apresentada na equao: equaes de estimativa de prazo de desenvolvimento so
da forma apresentada na equao:
onde
S o tamanho do software expresso em milhares de onde
linhas de cdigo, excludos os comentrios T o tempo de desenvolvimento, e
m(X) um multiplicador composto que depende de 15 E o esforo j calculado.
direcionadores de custo
Os modos de desenvolvimento e os valores de ai e bi
No COCOMO Bsico, m(X) = 1 para cada direcionador para os nveis Bsico e Intermedirio so apresentados na
de custo; no COCOMO Intermedirio devem ser atribudos Tabela 11.
valores especficos para cada atributo.
Tabela 11: valores de ai e bi para os nveis Bsico e In-
Os modos de desenvolvimento e os valores de ai e bi termedirio do COCOMO
para os nveis Bsico e Intermedirio so apresentados na
tabela 10.
Tabela 10: valores de ai e bi para os nveis Bsico e

Intermedirio do COCOMO
Fonte: baseado em BOEHM [1981]
Exemplo de aplicao do COCOMO

Como exemplo de aplicao do modelo COCOMO B-
Fonte: baseado em BOEHM [1981] sico, vamos utilizar os dados fornecidos no exemplo da
27
seo 3.1.1 para calcular o esforo necessrio para desen- composio rpida de aplicaes de software auxiliadas
volver o software proposto naquele exemplo. Suponha por computador ou ICASE Integrated Computer-Aided
que o projeto de nvel bsico e o modo de desenvolvi- Software Environment.
mento semidestacado.
Para fazer esse clculo, fazemos uso da expresso E = O modelo prev a contagem de Pontos de Objeto,
ai Sbim(X), conforme seo 3.3.1. Como o exemplo uma uma nova abordagem de medio de tamanho de softwa-
aplicao do COCOMO Bsico, m(X) igual a 1. re para estimar custo e prazo de projetos. um tipo de
contagem funcional de telas, relatrios e de mdulos de
Os valores de ai e bi so obtidos da tabela 10 (ai = 3,0 linguagem de terceira gerao, em que cada um dos ele-
e bi = 1,12) e o valor de S, estimativa do tamanho do sof- mentos contados recebe uma classificao em nveis de
tware, igual a 34.317 LOC, ou seja, aproximadamente 34 complexidade (simples, mdia e alta).
KLOC (esse valor foi calculado no exemplo da seo 3.1.1).
Segundo os projetistas do COCOMO II, estimativas
Substituindo esses valores na equao de esforo aci- de Pontos de Objeto foram comparadas a estimativas de
ma, teremos: Pontos de Funo e mostraram resultados mais adequa-
dos aos tipos de aplicao a que se destina o modelo Ap-
plication Composition [CSSE, 2012].
Caro aluno, no modelo Application Composition, o es-

foro computado atravs da expresso e mais detalhes
podem ser obtidos em CSSE (2012):
COCOMO II
Para atender s necessidades de um modelo de esti-
mativa de custo de projeto de software mais adequado
s prticas de ciclo de vida de software dos anos 1990 e
2000, teve incio, em 1994, o projeto COCOMO II, com o onde:
objetivo de desenvolver um modelo de custo mais atuali- PM = Esforo em pessoas-ms
zado que o modelo antecessor. NOP = Novos Pontos de Objeto Contados
PROD = Produtividade dos Desenvolvedores
Trs modelos de estimativa de custo foram apresenta-
dos como resultado do projeto COCOMO II: Composio Uma pessoa/ms a quantidade de tempo correspon-
de Aplicao - Application Composition, Projeto Prelimi- dente ao gasto por uma pessoa trabalhando em um pro-
nar - Early Design e o modelo Ps-Arquitetura- Post-Archi- jeto de desenvolvimento de software em um ms. Esse
tecture, que sero explicados no que se segue. nmero no inclui feriados ou frias e considera tempo
livre nos finais de semana. O nmero de pessoas-ms
Modelo Application Composition diferente do tempo necessrio para completar um proje-
to; um projeto pode ser estimado em 50 PM de esforo e
O modelo Application Composition - Composio de 11 meses de cronograma.
Aplicaes foi projetado especificamente para aplicaes
que so desenvolvidas por equipes pequenas em poucas Modelo Early Design
semanas ou meses.
O modelo foi projetado para prever o esforo de pro- As etapas posteriores s fases iniciais de projetos ou ci-
totipao envolvido no uso de ambientes integrados de clos de vida espirais podem requerer a pesquisa de arqui-
28
teturas alternativas ou estratgias de desenvolvimento

incremental. O modelo Early Design foi desenvolvido para
elaborar estimativas iniciais e apoiar essas atividades.
As principais variveis de entrada para o modelo so: o onde:

tamanho estimado do sistema e os direcionadores de custo. PM = Esforo estimado em pessoas-ms
O tamanho da aplicao que vai ser desenvolvida a principal a = Constante provisoriamente ajustada em 2,5
varivel de entrada para clculo de esforo e tempo. Tamanho = Tamanho estimado, expresso em milhares
de linhas de cdigo (KLOC)
Derivado da estimativa do tamanho dos mdulos de b = fator escalar
software que iro constituir a aplicao ou programa, o EM Multiplicadores de esforo: RCPX, RUSE, PDIF,
tamanho deve ser expresso em unidade de milhares de PERS, PREX, FCIL, SCED
linhas de cdigo (KLOC). PMM = Estimativa de esforo de manuteno
O modelo Early Design permite que o tamanho da apli- O coeficiente b calculado atravs da equao:
cao possa ser estimado em pontos de funo no ajus-
tados, posteriormente convertidos em linhas de cdigo
pelo modelo.
Pontos de funo podem ser utilizados como boas es-

timativas porque so baseados em informaes que esto onde:
disponveis logo no incio do ciclo de vida do projeto. SF = fatores de escala: PREC, FLEX, RESL, TEAM, PMAT
O modelo Early Design utiliza um conjunto reduzido Para ajustar o tamanho efetivo do produto de softwa-
de direcionadores de custo. As escalas correspondentes e re, o COCOMO utiliza vrias expresses que levam em
os multiplicadores de esforo desses direcionadores man- considerao a volatilidade dos requisitos, o reuso de
tm relacionamento consistente com os direcionadores componentes, alm de calcular o esforo de manuteno.
combinados do modelo Post-Architecture, para assegurar
Maiores detalhes sobre essas expresses podem ser en-
a consistncia das estimativas dos dois modelos, confor-
contradas no manual do COCOMO II.
me mostra a tabela 12.

Para estimar o cronograma de desenvolvimento de
Tabela 12: Direcionadores de Custo aplicados no mo-
projetos, os modelos de estimativa do COCOMO II utili-
delo Early Design e Post-Architecture
zam a expresso:
onde:
a = constante, provisoriamente ajustada em 3,0
Fonte: [CSSE, 2012] SCED% = porcentagem de compreenso/expanso do
multiplicador de esforo SCED
A equao seguinte utilizada para calcular o esforo PM = estimativa de pessoas-ms
de desenvolvimento em projetos estimados pelo modelo b = fator escalar
Early Design: TDEV = tempo de desenvolvimento
29
O modelo Post-Architecture utiliza 17 direcionadores

Modelo Post-Achitecture
de custo para ajuste do esforo nominal, agrupados em
4 categorias: Produto, Plataforma, Pessoal e Projeto. A
Quando um projeto se apresenta pronto para ser
relao completa desses direcionadores de custo pode
desenvolvido, j deve possuir uma arquitetura de ciclo de
ser encontrada no manual do COCOMO II.
vida que possa fornecer informaes mais precisas para
as entradas dos direcionadores de custo, proporcionando O esforo de desenvolvimento, segundo o modelo Post-
estimativas mais precisas. Architecture estimado atravs da seguinte equao, que se
diferencia da equao do modelo Early Design no nmero de
Para apoiar esse estgio, o COCOMO II projetou o direcionadores de custo, que agora passa a ser 17.
modelo Post-Architecture, um modelo comprometido
com a forma de desenvolvimento de software utilizada e
tambm de manuteno de produtos de software. Esse
modelo prev a utilizao de linhas de cdigo e/ou pontos
de funo para estimar o tamanho inicial do projeto,
reuso de software, 17 direcionadores de custo e 5 fatores onde:
de escala de projeto. PM = Esforo estimado em pessoas-ms
a = Constante provisoriamente ajustada em 2,5
Para estimar pontos de funo para o modelo Post- Tamanho = Tamanho estimado, expresso em milhares
Architecture, utiliza-se o processo de converso de pontos de linhas de cdigo (KLOC)
de funo no ajustados em linhas de cdigo sugerido b = fator escalar
pelo modelo Early Design. O COCOMO II permite que EMi Multiplicadores de esforo
componentes possam ter seus tamanhos estimados em PMM = Estimativa de esforo de manuteno
pontos de funo e outros, onde pontos de funo no
podem ser bem descritos, tais como aplicaes em tempo As demais equaes utilizadas para calcular o fator es-
real e computao cientfica, em linhas de cdigo. calar b, o ajuste de tamanho, porcentagem de reuso de c-
digo, etc. so iguais s equaes do modelo Early Design.
O objetivo da contagem de linhas de cdigo medir
a quantidade de trabalho intelectual necessrio para de-
Estimativa Baseada em Processo
senvolver um programa. Uma das dificuldades de conta- Essa tcnica baseia a estimativa no processo que ser
gem aparece quando se tenta definir medies consisten- usado. Os passos a serem seguidos so:
tes em diferentes linguagens.
1. Inicialmente, realizada, atravs do escopo, uma
Definir o que uma linha de cdigo difcil devido s decomposio das funes do software. A seguir, o
diferenas conceituais envolvidas no processo de conta- processo tambm decomposto em um conjunto
gem de declaraes executveis e declaraes de dados de atividades (tarefas).
em diferentes linguagens. 2. Podem-se representar as funes e atividades de
processo decompostas em uma tabela.
O modelo COCOMO II sugere o uso de um checklist 3. O prximo passo estimar o esforo necessrio
desenvolvido pela SEI para apoiar as medies. O checklist para realizar cada funo do software, para cada
completo est disponibilizado no manual do COCOMO II. atividade decomposta do processo. Preferencial-
Para assegurar a uniformidade de dados coletados no mente, isso feito com base em dados histricos
projeto COCOMO II, uma ferramenta de coleta de mtricas de projetos anteriores similares ao que vai ser de-
automatizada chamada Amadeus foi utilizada. senvolvido no momento.
30
4. Taxa(s) de mo-de-obra (so) atribuda(s) (para o em processo. Considere um valor bruto mdio de
projeto como um todo ou para cada atividade do mo de obra de 4.000 reais por pessoa-ms.
processo).
Estime o custo de cada funo do software (sem
5. Custo e esforo so calculados.
considerar as atividades iniciais de desenvolvi-
mento: Comunicao com o Cliente, Planejamen-
Normalmente, profissionais mais experientes (mais
to, Anlise de Risco).
bem remunerados) esto envolvidos nas primeiras ativi-
dades do processo e pessoal menos experiente est en- Estime o custo de cada atividade de arcabouo
volvido com gerao de cdigo e primeiros testes. do processo.
A tabela 13 exemplifica uma possvel decomposio do

Tabela 14: Estimativas de Esforo (PM) para cada fun-
produto e do processo. Note que, como o processo de-
o a ser desenvolvida considerando cada atividade de
composto em suas vrias atividades e o produto em suas
arcabouo
vrias funes, a tabela 13 possibilita o clculo do custo e
esforo para cada funo e para cada atividade de arca-
bouo do processo de software.
Tabela 13: Decomposio do produto e do processo
onde:
RVCG = Recursos de Visualizao de Computao
Grfica
AG2D = Anlise Geomtrica 2D
AG3D = Anlise Geomtrica 3D
Exemplo de Estimativa Baseada em Processo
RCIU = Recursos de Controle e Interface Grfica
com o Usurio
Suponha um determinado software de CAD que ser
GBD = Gesto de Base de Dados
desenvolvido. Atravs da anlise do escopo do software,
FCP = Funo de Controle de Perifricos
suas funes principais foram identificadas e so relacio-
MAP = Mdulos de Anlise de Projeto
nadas na tabela 14. O processo a ser utilizado tambm
PM = Pessoa-ms
foi decomposto e suas atividades principais esto relacio-
nadas na tabela 14. Consultando dados histricos para
o domnio de aplicao do software a ser desenvolvido,
Soluo:
estimativas de esforo foram obtidas, conforme apresen-
tado na tabela 14.
A tabela 15 apresenta as somas dos esforos de cada
coluna e tambm a soma dos esforos de cada linha for-
Fazendo uso dos dados fornecidos, estime o es-
necidos na tabela 14. Na ltima linha da tabela apresen-
foro e o custo totais necessrios para construir o
tado o clculo para obter o esforo total para desenvolver
software usando a tcnica de estimativa baseada
31
o software. Note, ento, que a soma dos esforos de cada Conciliao de Modelos de Estimativas
linha resultar no esforo necessrio para desenvolver cada
uma das funes do software a ser desenvolvido. E a soma Normalmente estimativas de projeto precisas usam
dos esforos de cada coluna resultar no esforo necessrio pelo menos duas das tcnicas de estimativas apresenta-
para executar cada atividade de arcabouo do processo.
das anteriormente. Valores mdios (conciliao) de esti-
mativas so ento calculados atravs dos valores de esti-
Tabela 15: Soma dos esforos necessrios para desen-
mativa obtidos das tcnicas consideradas.
volver cada funo e cada atividade de arcabouo
A conciliao realizada quando a variao mxima a
partir da mdia obtida no ultrapasse 20%. Nesses casos,
h forte razo para acreditar que as estimativas so con-
fiveis. Caso contrrio, mais pesquisa e anlise devem ser
realizadas. Pela comparao e conciliao das estimativas
derivadas usando diferentes tcnicas mais provvel que
o planejador consiga derivar uma estimativa precisa. Caro
aluno, vale lembr-lo que a estimativa de projetos de sof-
tware no uma cincia exata. Mas, conforme vimos, da-
dos histricos e tcnicas sistemticas podem melhorar a
Fonte: baseado em PRESSMAN [2010] preciso da estimativa
Exemplo de conciliao de estimativas

De posse dos esforos para desenvolver cada funo e
cada atividade de arcabouo, relacionados na tabela 16, e Considerando o software de CAD utilizado em
do valor bruto de mo de obra fornecido no enunciado do exerccios anteriores, verifique se os valores esti-
problema, podemos calcular o Custo Total para desenvol- mados de esforo utilizando as tcnicas de estima-
ver o software, o custo para desenvolver cada uma das fun- tivas baseadas em LOC, PF e Processo, podem ser
es separadamente bem como o custo de para executar conciliados.
cada atividade de arcabouo, conforme mostrado a seguir. Caso os valores estimados possam ser conciliados,
calcule o custo total do projeto baseado no valor
de esforo conciliado. Considere que a taxa bruta
mdia de mo de obra de 4.000 reais/pm.
Dados Fornecidos :
Estimativa de Esforo baseada em LOC @ 65 pm

Estimativa de Esforo baseada em PF @ 64 pm
Estimativa de Esforo baseada em Processo @ 61 pm
Soluo:
a)
Concluso: Como a variao mxima est dentro da fai-

xa de 20%, as estimativas de esforo obtidas atravs de trs
diferentes tcnicas podem ser conciliadas para o seu valor
mdio, ou seja, o esforo considerado ser de 63,5 pm.
32
trio de 2013 aponta que apenas 39% dos projetos

b) de TI no mundo alcanam sucesso.
O dado preocupante, uma vez que a

Gerenciamento de Riscos Tecnologia da Informao uma das reas que apre-
senta maior nvel de maturidade em gerenciamento
Conceitos bsicos sobre riscos em de projetos. A boa notcia que o percentual de su-
projetos cesso vem aumentando significativamente nos lti-
mos anos.
Estudos e a prtica comprovam que uma srie de fato-
res pode ameaar o sucesso dos processos de desenvolvi- De acordo com o PMBOK o sucesso deve
mento de software. ser medido pela qualidade do produto e do projeto,
pela pontualidade, pelo cumprimento do oramen-
Taxas relativamente altas de projetos atrasados, cus- to e pelo grau de satisfao do cliente. O papel do
tos que ultrapassam as estimativas, implementaes que gerente de projetos equilibrar essas variveis, uma
no correspondem ao que foi exigido, projetos que so vez que esto todas interligadas, e a mudana em
abortados antes da sua concluso, so problemas fre- qualquer delas causa impacto nas demais.
quentemente encontrados na rea de desenvolvimento
de software.
De acordo com levantamento realizado pelo Standish O PMSURVEY.ORG uma pesquisa

Group (2013), em 2012, dos projetos acompanhados, anual, organizada voluntariamente pelo Project
39% foram completados dentro do cronograma e do pra- Management Institute de diversos pases, e con-
zo estipulado, sendo que 18% fracassaram. ta com a participao de centenas de organiza-
es no mundo. Os resultados da pesquisa de 2012
mostram que cerca de 60% das organizaes tm
cumprido as metas nos fatores crticos de sucesso.
Fonte: http://pmkb.
com.br/artigo/gestao-de-projetos-sucesso-nos-projetos/
A gesto de riscos uma atividade que visa fornecer

uma cobertura em relao s variveis que podem levar
aos problemas relacionados ao desenvolvimento de sof-
tware. Fatores que podem aumentar a probabilidade de
falha ou de fracasso total em projetos so previamente
estabelecidos, avaliados e acompanhados constantemen-
te, com a reduo ou eliminao da sua ocorrncia e dos
seus efeitos adversos.
Fonte: STANDISH GROUP (2013)
Pressman (2010) afirma que a gerncia de riscos cru-

O The Standish Group publica a cada dois anos
cial para um bom gerenciamento de projeto de software.
uma pesquisa chamada Chaos Report, que aponta o
Tanto as empresas quanto os profissionais de software
percentual de projetos, na rea de TI, que alcanam
tm se mobilizado no sentido de tornar mais claras as
sucesso, dficit (atraso/prejuzo) ou fracasso. O rela-
questes relativas a essa rea. Cada vez se torna mais co-
33
mum medidas como treinamentos especficos, incentivos Boehm (1991) prope a subdiviso mostrada na figura
certificao de profissionais, implantao de programas 3, no gerenciamento de riscos:
de qualidade, padronizaes, etc. Figura 3 Gerenciamento de Riscos
Mas o que se entende por risco, caro aluno?
Segundo Longstaff et al (2000) risco a medida da

probabilidade e severidade de efeitos adversos.
Ropponen & Lyytinen (2000) definem varivel de

risco como um estado ou propriedade de uma tarefa de
desenvolvimento ou do ambiente que, uma vez ignorada,
aumentar a probabilidade de falha do projeto.
Prticas para Gerenciamento de Riscos

Fonte: Baseado em [BOEHM, 1991]
Eventos imprevistos podem causar efeitos adversos

Padronizaes como o SWEBoK (engenharia de sof-
e, em muitos casos, catastrficos no andamento de um
tware) e o PMBoK (gerncia de projetos) colocam a ge-
projeto. As tcnicas e procedimentos de Gerenciamento
rncia de riscos em destaque.
de Risco surgiram como uma tentativa de resposta
necessidade de prever, compreender e prevenir a
Pressman (2010) identifica uma srie de atividades
ocorrncia de riscos, bem como reduzir quaisquer efeitos
relacionadas ao gerenciamento de risco muito similares
negativos caso eles venham a ocorrer. proposta por Boehm (1991): identificao de riscos, ava-
liao, priorizao, definio de estratgias de administra-
Algumas das prticas mais difundidas na gesto de o de riscos e monitoramento.
risco so:
O CMMI apresenta uma rea de processo especfica
Identificao sistemtica de riscos atravs de re- para gerenciamento de risco, que deve atender 4 obje-
vises de documentao, tcnicas de coleta de tivos: preparao da gerncia de riscos, identificao e
informaes, anlise SWOT Strenghts, Weaknes- anlise de riscos,reduo de riscos e institucionalizao
ses, Oportunities and Threats (Foras, Fraquezas, de um processo definido, cada um deles com um detalha-
Oportunidades e Ameaas). mento de subprocessos.
Anlise probabilstica de riscos, incluindo o grau A norma ISO 12207 contm uma especificao de um
de possibilidade de ocorrncia e da gravidade dos processo para este fim. Nas normas ISO 9000, o termo
mesmos; risco citado como parte da preveno de no confor-
Planejamento detalhado para a reduo do grau midades.
de incerteza da ocorrncia e da gravidade dos
Para a avaliao de riscos torna-se necessrio iden-
eventos de risco a um valor aceitvel;
tificar as ameaas presentes tanto no ambiente interno
Metdica anlise de trade-offs resultando em um
como externo ao objeto de estudo, fazer uma anlise des-
plano de resposta a riscos;
sas ameaas e definir uma ordem de prioridade de acordo
Designao de um Gerente de Riscos
com os fatores de maior relevncia.
34
Segundo o guia SWEBoK 2004 (IEEE Computer Socie- Avaliar riscos envolve, caro aluno, a definio de quais
ty, 2012), avaliar os riscos simplesmente identificar os deles so prioritrios. Engloba tambm a tomada de de-
mais crticos. Para fazer isso, deve-se avaliar a criticidade ciso envolvendo mltiplas variveis e incertezas. Neste
de cada varivel de risco. Esse processo de avaliao c- campo minado, tanto as tcnicas quantitativas quanto as
clico, j que, conforme o projeto se desenvolve, fatores de qualitativas tm limitaes e crticas.
risco tanto podem surgir como desaparecer, assim como
os graus de gravidade e ocorrncia dos mesmos podem As principais tcnicas quantitativas para gerncia de
sofrer alteraes relevantes. riscos so o clculo da exposio ao risco, aliado ou no
a rvores de deciso e simuladores. A aplicao correta
A identificao dos fatores ou variveis de risco pode ser dessas tcnicas promete resultados precisos, possibilida-
feita por meio de uma srie de tcnicas tais como checklists des de fazer anlises de sensibilidade e o teste de cen-
padronizados disponveis, o exame de tomadores de deci- rios alternativos com uma ou mais de uma deciso en-
so, comparao com a experincia e decomposio. cadeadas. O que se nota que as tcnicas de avaliao
de risco tm se diversificado, aprimorado e incorporado
Uma vez identificados os fatores de risco, a anlise maior robustez.
desses fatores tenta definir as probabilidades de ocorrn-
A maior dificuldade no uso dessas tcnicas a neces-
cia e gravidade dos mesmos. Para isso pode-se utilizar de
sidade de garantia de boas estimativas. Para isso, ne-
modelos de performance e custo, anlise de redes, anli-
cessrio que haja todo um suporte baseado em dados
se estatstica e qualitativa, dentre outras. O PMBoK (2008)
estatsticos de projetos similares (envolve critrios como
recomenda a adoo de procedimentos tanto quantitati-
escopo e tecnologia utilizada), cotaes de preos e le-
vos quanto qualitativos, enquanto o CMMI e a ISO deixam
vantamentos de custos atualizados, alm de medies de
a escolha da abordagem organizao.
variveis de desenvolvimento (esforo de programao,
tempo de execuo de tarefas semelhantes, etc).
Avaliao e Priorizao de Riscos
A satisfao de todas essas premissas exige um am-
A ltima etapa do processo de avaliao de risco- a biente maduro de produo de software e certa abundn-
priorizao dos riscos - produz uma listagem por ordem cia e qualidade de dados, algo nem sempre possvel. A
de urgncia de tratamento (veja a figura 3 para identificar aplicao de tcnicas sem este tipo de suporte pode no
estas etapas). Isso pode ser feito atravs do emprego atingir os objetivos propostos.
de tcnicas como anlise de grau de exposio ao risco,
processos de obteno de consenso e anlise de custo- Em relao s tcnicas qualitativas, a maior crtica
benefcio. baseada na falta de preciso nos resultados decorrente da
Os mtodos de priorizao de riscos podem ser tanto subjetividade inerente sua aplicao. Segundo o PMBoK
quantitativos, como a aplicao da mtrica de exposio (2008), o uso de tcnicas qualitativas deve sempre pres-
ao risco, como podem ser qualitativos, como no Carne- supor uma anlise posterior da preciso dos dados. Com
ggie Mellon Risk-Ranking Method [FLORIG et al, 2001] isso, consegue-se contornar parcialmente os problemas
[BOEHM, 1991]. de preciso e a tendenciosidade das decises.
A etapa da avaliao de riscos importante principal- Dentre as principais tcnicas qualitativas temos
mente quando se est diante de um grande nmero de o levantamento das probabilidades de ocorrncia e
possibilidades de risco, exigindo esforo adicional de fil- gravidade dos riscos e o uso de matrizes de probabilidade
tragem e priorizao. e impacto.
35
importante entender os riscos e tomar medidas

Alm da subjetividade, outras limitaes podem ser proativas para evit-los ou administr-los.
apontadas nessas tcnicas, como por exemplo:
Em relao s estratgias de risco, podemos citar:
impreciso, devido ao uso de escalas lingusticas ba-
seadas em valores (muito, baixo, moderado, alto, etc); Estratgias de Risco Reativas: nada feito em
ambiguidade, por no diferenciar adequadamente relao aos riscos at que algo d errado. Se algo
riscos de valores prximos (aumentando ou dimi- der errado, tomam-se atitudes na tentativa de
nuindo a importncia dos mesmos por falta de es- corrigir o problema rapidamente.
pao na escala ou por m interpretao do gerente); Estratgias de Risco Proativas: comea antes do
correlaes entre mtricas no consideradas; etc. trabalho tcnico ser iniciado. Riscos potenciais so
identificados, suas probabilidades e impactos so
Toda tcnica qualitativa deve ser utilizada com critrio avaliados e eles so classificados por importncia.
e senso crtico, levando-se em conta as limitaes citadas. A seguir, estabelece-se um plano para administrar
Apesar de tudo, essas tcnicas so instrumentos impor- os riscos.
tantes para a reduo do nmero de riscos a serem tra-
tados em uma anlise quantitativa mais profunda, e sua O objetivo principal evitar riscos. Como nem todos
utilizao em projetos de software se justifica principal- os riscos podem ser evitados, um plano de contingncia
mente pela facilidade de aplicao. deve ser elaborado visando aes controladas e efetivas.
Riscos so objetos complexos. Possuem como atributo Sabemos que risco envolve duas caractersticas:
uma descrio, probabilidades de ocorrncia, estimativa
Incerteza o risco pode ou no acontecer.
de gravidade, gatilhos, planos de controle relacionados e
Perda se o risco tornar-se real, consequncias
os resultados prticos obtidos na sua aplicao, histricos
indesejadas ou perdas ocorrero.
de variaes dentro de projetos, etc.
Existem vrias categorizaes de risco. Por exemplo,
O IEEE (2009) recomenda a manuteno de dados re- segundo Pressman (2010), podemos categoriz-los em:
trospectivos dos riscos (o chamado risk profile), enquanto
o PMBOK (2008) cita como sada do controle de riscos um Riscos de Projeto: problemas potenciais oramen-
repositrio de dados para a gerao de um programa de trios, de cronograma, de pessoal (quantidade e
lies aprendidas de risco. Outros autores sugerem uma organizao), de recursos, de interessados e de re-
maior nfase no armazenamento adequado de informa- quisitos e seu impacto em um projeto de software.
o como guia para o subsequente refinamento de esti- Ameaam o plano do projeto.
mativas e anlises. Riscos Tcnicos: problemas potenciais de imple-
Categorizaes de Risco mentao, de interface, de verificao e de manu-
teno. Ameaam a qualidade e a pontualidade do
Caro aluno, pelo que vimos at aqui, podemos dizer que: software a ser produzido.
Riscos do Negcio: ameaam a viabilidade do sof-
risco um problema potencial que pode ou no tware a ser construdo.
ocorrer.
o desenvolvimento de software normalmente Principais riscos do negcio so:
envolve vrios riscos.
riscos podem comprometer o projeto (atraso, Risco de Mercado: construir um produto ou siste-
custo, concretizao,). ma excelente que no interesse a ningum.
36
Risco Estratgico: construir um produto que no Os requisitos esto bem entendidos pela equipe
se encaixa mais na estratgia geral de negcios da de desenvolvimento e pelo cliente?
empresa. Os clientes envolveram-se na definio dos requisitos?
Risco de Marketing: construir um produto que a
Os usurios finais tm expectativas realsticas?
equipe de vendas no sabe como vender.
O escopo do projeto estvel?
Risco Gerencial: perda de apoio da gerncia supe-
rior por causa de modificao de enfoque ou de A equipe de desenvolvimento tem as aptides ne-
pessoal. cessrias?
Risco de Oramento: perda de comprometimento Os requisitos do projeto so estveis?
oramentrio ou de pessoal. A equipe de projeto tem experincia com a tecno-
logia a ser implementada?
Outra categorizao possvel de risco inclui os seguintes: A quantidade de pessoal adequada para fazer o
servio?
Riscos Conhecidos: podem ser descobertos aps a
Todos os membros envolvidos (cliente/usurio)
avaliao do plano de projeto, do ambiente tcnico
concordam com a importncia do projeto e com
e comercial (prazo de entrega irreal, falta de docu-
os requisitos do sistema a ser construdo?
mentao dos requisitos e/ou do escopo, ambiente
de desenvolvimento ruim ou desfavorvel, etc).
Se qualquer uma das questes for respondida negati-
Riscos Previsveis: obtidos de experincia de pro-
vamente, os passos de atenuao, monitorao e gesto
jetos anteriores (rotatividade de pessoal, diluio
devem ser formalizados. O grau em que o projeto est em
do esforo de pessoal medida que os pedidos de
risco diretamente proporcional ao nmero de respostas
manuteno surgem).
negativas dadas s questes.
Riscos Imprevisveis: extremamente difceis de se-
rem identificados antecipadamente.
Caro aluno, faa uma pequena pausa e se divirta
Avaliao do Risco Global do Projeto com o filme sobre Gesto de Riscos em projetos...
talvez ele tenha sido feito por estagirios...
Caro aluno, dissemos que os riscos podem ser ava-
liados atravs de uma abordagem quantitativa ou quali- http://youtu.be/e_QgCSDuhu4 532
tativa. Um exemplo de avaliao qualitativa de risco a
avaliao do risco global do projeto, que foi derivada de Matriz de Riscos
dados de risco obtidos por levantamento feito com geren-
tes de projeto de software experientes, em vrias partes A previso (estimativa) de risco avalia cada risco de
do mundo. De acordo com Pressman (2010) , essa ava- dois modos:
liao consiste nas respostas dadas s questes abaixo, 1. A probabilidade de que o risco seja real.
as quais esto ordenadas por sua importncia relativa ao 2. As consequncias dos problemas associados ao
sucesso de um projeto: risco, se ele ocorrer.
Normalmente, nenhuma equipe de software dispe

A alta administrao do software e do cliente em-
de recursos para tratar todos os riscos possveis com o
penhou-se formalmente em apoiar o projeto?
mesmo grau de rigor. Priorizando riscos, a equipe pode
Os usurios finais esto empenhados com relao
alocar recursos onde eles vo ter maior impacto.
ao projeto?
37
Uma matriz de risco pode ser utilizada como uma uma priorizao de segunda ordem. Um fator de risco
tcnica para previso de risco. A matriz mostrada na figura que tem alto impacto, mas probabilidade de ocorrncia
4 um exemplo de matriz para previso de risco. muito baixa, no demandar muita ateno. Riscos de alto
impacto, com probabilidade moderada a alta e riscos de
A elaborao da matriz segue os passos: baixo impacto, com alta probabilidade, demandaro maior
ateno. Conforme dissemos, a probabilidade de risco pode
a listagem de todos os fatores de risco (no ser determinada fazendo-se estimativas individuais e depois
importando quo remotos sejam) colocada na desenvolvendo um nico valor de consenso. Existem tcnicas
1 coluna da matriz. mais sofisticadas para determinao de probabilidades que
cada fator de risco categorizado na 2 coluna. fazem uso da Estatstica para seus clculos.
na 3 coluna, coloca-se a probabilidade de
ocorrncia de cada fator de risco. Para isso, Exposio ao Risco (ER)
vrias tcnicas podem ser utilizadas. Dentre elas,
a tcnica Delphi, que utiliza valores estimados A Exposico ao Risco (ER) ou Risk Exposure (RE) de-
individualmente por cada membro da equipe para terminada atravs da seguinte expresso:
se chegar num valor de consenso.
na 4a coluna estimado o impacto de cada risco,
seguindo, por exemplo, as seguintes categorias:
1. Catastrfico (Valor de Impacto = 1) onde:

2. Crtico (Valor de Impacto = 2) P = probabilidade de ocorrncia do risco
3. Marginal (Valor de Impacto = 3) C = custo para o projeto no caso do risco ocorrer
4. Negligvel (Valor de Impacto = 4) A exposio ao risco pode ser calculada para cada risco
da tabela de risco. A exposio total ao risco, para todos
Figura 4: Matriz para previso de risco os riscos (acima da linha de corte na tabela de riscos),
pode fornecer um modo de ajustar a estimativa final de
custo de um projeto.
Exemplo de clculo de ER
Problema:
Considere que em um desenvolvimento de um software

apenas 60% dos componentes de software programados
para reuso (em um total de 50 componentes planejados)
sero, de fato, integrados aplicao.
Na sequncia, a matriz ordenada por probabilidade Com isso, as funcionalidades restantes tero que ser
e por impacto. Os riscos com alta probabilidade e alto desenvolvidas pela equipe. Atravs de tcnicas de estima-
impacto vo para o alto da tabela e os riscos com baixa tiva de probabilidade determinou-se que a probabilidade
probabilidade vo para a parte de baixo. Denominamos desse risco acontecer de 70%.
esse procedimento de priorizao de riscos de primeira Estimativas de LOC determinaram que o tamanho
ordem. A seguir, uma linha de corte estabelecida: riscos mdio de cada componente de 150 LOC e que o custo/
situados acima da linha recebero ateno subsequente. LOC de 8 reais/LOC. Calcule a ER para esse risco.
Riscos que ficam abaixo so reavaliados para se chegar
38
Soluo: srio remover alguns riscos e mudar as posies relativas

de outros).
Como 40% dos componentes previstos para reuso te-
ro que ser efetivamente desenvolvidos pela equipe, isso
implica em um total de: Exemplo de clculo de ER
Problema:
Utilizando a matriz de riscos apresentada na figura 4,

O custo para o projeto (C) desses componentes adicio- que se refere a um determinado software a ser desenvol-
nais a serem desenvolvidos pela equipe, alm dos plane-
vido, estabelea uma linha de corte adotando o seguin-
jados inicialmente ser de:
te critrio: riscos de primeira ordem tero probabilidade
de ocorrncia acima de 30% (a tabela deve ser ordenada
para determinar a linha de corte).
Dessa forma, a ER ser de: A seguir, verifique se o projeto vivel ou se novas an-
lises devem ser realizadas, considerando que o Custo Total
Estimado do projeto de R$ 120.000,00 (120 mil reais).
Soluo:
Exposio ao Risco Total (ERT)
Uma vez que a tabela tenha sido ordenada e estabele-
A Exposio ao Risco Total (ERT), para todos os riscos
acima da linha de corte na matriz de riscos, pode forne- cida a linha de corte, os riscos de primeira ordem so os
cer um modo de ajustar a estimativa final de custo de um listados na tabela 16.
projeto.
Tabela 16: Riscos de primeira ordem
Pode tambm ser usada para prever o aumento prov-
vel nos recursos de pessoal necessrios em vrios pontos
do cronograma do projeto.
Uma estratgia de anlise da exposio ao risco total

pode ser: se ERT for maior do que 50% do custo estimado
do projeto, a viabilidade do projeto deve ser avaliada.
As tcnicas de previso e anlise de riscos so aplica-

das iterativamente medida que o projeto de software
prossegue.
Cada risco deve ser reavaliado em intervalos regulares A seguir, calculamos a Exposio ao Risco (ER) de cada
para determinar se novas circunstncias causam modifi- fator de risco, de acordo com a tabela 17.
caes na sua probabilidade e impacto (pode ser neces- Tabela 17: Clculo da Exposio ao Risco
39
Monitorao: Monitorar os documentos para assegu-

rar que so auto-suficientes (para ser usado por um nova-
to, por exemplo, caso seja necessrio)
Gerenciamento: Se a estratgia de atenuao foi seguida,

a informao estar documentada podendo ser difundida
por toda a equipe (e por novatos, caso sejam necessrios).
Uma vez que o Custo Total Estimado do projeto de R$ Os passos de atenuao, monitorao e gerenciamento
120.000,00 notamos que a Exposio ao Risco Total est de risco (RMMM) implicam em custos adicionais ao projeto.
abaixo dos 50% estabelecidos como critrio de viabilidade Por exemplo, gastar tempo para se buscar um substi-
do projeto, ou seja, R$ 37.600,00) < (50% de R$ 120.000,00 tuto para cada tcnico essencial custa dinheiro. Devido
= R$ 60.000,00). Assim, a princpio, em relao aos riscos, a isso, o planejador do projeto deve efetuar uma anlise
o projeto se mostra vivel. custo/benefcio. Se a exposio ao risco especfico for me-
nor que o custo da atenuao deste, melhor no tentar
RMMMRisk Mitigation, Monitoring atenu-lo, mas sim monitor-lo.
and Management
Todas as atividades de anlise de risco tm uma nica Cronogramao
meta: ajudar a equipe de projeto a desenvolver uma es-
tratgia para lidar com o risco. Conceitos Bsicos sobre Cronogramao

Uma estratgia efetiva para lidar com risco deve consi- Em sua forma mais simples, um cronograma uma lista
derar 3 pontos: Atenuao, Monitorao e Gerenciamen- de atividades e eventos organizados em funo do tempo.
to do risco. Isso conhecido como RMMMRisk Mitiga- Em sua forma mais complexa, um cronograma examina
tion, Monitoring and Management, ou seja: todas as atividades de um projeto e suas relaes entre si
em termos de restries de tempo, oramento e pessoas,
Mitigation: evitar risco. Elabora plano para atenu-
isto , recursos.
ao de risco.
Monitoring: monitorar risco. Monitora fatores
Na execuo de projetos, o cronograma uma impor-
que podem tornar o risco mais ou menos prov-
tante ferramenta de planejamento, controle e comunica-
vel. Monitora tambm passos elaborados no plano
o que, quando adequamente utilizada, suporta estima-
para atenuao de risco.
tivas de tempo e custo, facilita a comunicao entre as
Management: gerenciar risco e planejar para a
pessoas envolvidas nas atividades do projeto e estabelece
contingncia. Considera que o risco tornou-se re-
um compromisso com essas atividades.
alidade.
Alm disso, um cronograma um importante elemen-

Exemplo
to para atividades de gerenciamento: organizao, atri-
Considere o seguinte fator de risco: Rotatividade de buio de tarefas s pessoas envolvidas, controle e con-
pessoal. Em relao a esse risco, podemos seguir os trs duo do projeto.
pontos RMMM da seguinte maneira:
As pessoas envolvidas com cronogramas devem ter um
Atenuao: Definir padres de documentao e esta-
conhecimento slido de prticas e aplicaes de crono-
belecer mecanismos para assegurar que os documentos
gramao, tais como diagrama de Gantt, marcos e redes
sero desenvolvidos a tempo.
de atividades. Essas pessoas devem saber no s como
elaborar cronogramas detalhados, mas tambm devem
40
ser capazes de compreender e analisar cronogramas cria- Vrios produtos so gerados no processo de planeja-
dos por outros, como por exemplo, aqueles produzidos mento, dentre eles:
por contratados num processo de terceirizao. Portanto,
voc deve estar percebendo, caro aluno, que a cronogra- Planos Funcionais: so planos detalhados que
mao uma das mais teis ferramentas disponibilizadas estabelecem a abordagem a ser considerada nas
para a execuo de um projeto e sua aplicao efetiva diferentes reas funcionais (como por exemplo,
essencial para atingir as metas estabelecidas. testes e avaliaes, controle, comunicao, su-
porte, logstica, etc)
Cronogramao e Planejamento de Estrutura Analtica de Projeto ou Work Breakdo-
Projetos wn Structure (WBS): fornece uma estrutura bsica
para identificar cada elemento de um projeto em
Planejamento de projeto uma atividade relacionada nvel crescente de detalhes. Em essncia, descreve
a determinar qual trabalho necessita ser realizado, por a maneira na qual o trabalho deve ser realizado. A
quem, quando e sob quais restries de recursos. WBS tambm fornece um mtodo coerente para
relatar o progresso em direo s metas do plano.
, sem dvida, a mais importante atividade de um pro-
Cronogramas: uma srie de cronogramas de-
jeto. Sem um planejamento slido e abrangente prati-
senvolvida durante o processo de planejamento.
camente impossvel desenvolver um oramento realista,
organizar, compor e conduzir efetivamente uma equipe, e Esses cronogramas so elaborados para mostrar
monitorar e controlar o projeto. os detalhes requeridos para executar as ativida-
des e marcos principais.
Sem um planejamento slido e abrangente pratica- Oramento: o oramento reflete o custo da
mente impossvel desenvolver um oramento realista, or- integrao do escopo, cronograma e recursos
ganizar, compor e conduzir efetivamente uma equipe, e para realizar o trabalho.
monitorar e controlar o projeto.
Cronogramao um elemento crtico no processo de
planejamento. Alm de ser uma sada (output) do proces-
so, tambm contribui para o desenvolvimento de outras
sadas. O envolvimento em um projeto de pessoas que tm
conhecimento e experincia em tcnicas de cronograma-
o pode contribuir para a traduo efetiva dos conceitos
e ideias estratgicas do projeto em diagramas lgicos deta-
lhados, representando as atividades desse projeto e seus
relacionamentos mtuos.
Cronogramao e Controle de Projetos

A funo de controle compreende todas as atividades
Fonte: http://www.humordaterra.com/wp-content/uploads/2011/06/ que um gerente de projeto pode utilizar na tentativa de
Mais-1-desenvolvedor.jpg garantir que o andamento atual esteja em conformidade
com o planejamento desenvolvido.
Alm de determinar o que, onde, quem, com o que e
Para controlar um projeto, um gerente necessita de
quando em um projeto, o planejamento tambm ajuda a
meios para monitorar o progresso em relao ao plano
identificar e lidar com reas de risco.
estabelecido.
41
O cronograma pode servir como uma linha base (ba- Exemplo de uma Anlise do Valor
seline) atravs da qual o progresso medido. Se houver
indcios que uma atividade est atrasada, essa informa-
Agregado
o poder ser usada pela gerncia como uma base para
Considere que voc est participando de um deter-
aes corretivas.
minado projeto e que entendeu suas caractersticas b-
Contudo, considerar isoladamente uma informao do sicas. A seguir voc desenvolve o planejamento, que re-
cronograma pode levar a interpretaes errneas. O ge- sulta em uma durao de 10 dias a um custo de 100.000.
renciamento adequado requer a integrao de aspectos importante que nesse momento voc calcule o custo
tcnicos, de cronograma e de custos de um projeto. dirio do projeto. Para isto voc dever ter uma WBS bem
detalhada e que reflita a situao real de seu projeto.
Assim, uma forma de medida de desempenho integra-
Voc monta a WBS e obtm o planejamento mostrado no
do necessria para monitorar e controlar um projeto. A
grfico 1.
tcnica do Valor Agregado (EVM) fornece essa capacidade.
Grfico 1- Planejamento do Projeto
EVM - Earned Value Management

A tcnica EVM Earned Value Management ou Ge-
renciamento do Valor Agregado o uso de um sistema
de gerenciamento integrado que coordena o escopo, o
cronograma e as metas de custo e mede objetivamente o
progresso em face dessas metas.
Fonte: SOUZA [2009]

O propsito dessa tcnica fornecer aos gerentes
dados acurados para monitorar a execuo do projeto.
Suponha que o projeto est em andamento e voc
coleta o custo do projeto diariamente. O projeto est no
Basicamente, essa tcnica relaciona os recursos plane-
sexto dia e quando voc olha para o grfico 1 voc acredita
jados para o cronograma e para os requisitos de desem-
que o projeto est ruim, pois o planejado para o dia R$
penho tcnico. Todo trabalho identificado, incluindo os
40.000,00 e voc j gastou R$ 50.000,00.
listados na WBS, planejado, orado, e cronogramado.

Quando o trabalho realizado, ele orado sobre a mes-
Voc apresenta o grfico 2 na reunio de acompanha-
ma base em que foi planejado, isto , em unidades mone-
mento semanal de projetos.
trias (real, dlar, etc) ou esforo (pessoa-ms, homem-
-hora, etc). Segundo Souza (2009), com a Anlise do Valor
Agregado podemos ver aspectos como: Grfico 2- Curvas do Planejado e da Execuo Real do
Projeto (Realizado)
Como o projeto est?

Como ele deveria estar?
Os gastos do projeto esto adequados ao trabalho
realizado?
O projeto ser entregue dentro do prazo e custo
contratados?
Fonte: SOUZA [2009]
Qual a previso de desvio de prazo e custo?
42
Ao ver o grfico 2 seu gerente pede explicaes do bom lembrar que para utilizar EVM corretamente
porque o projeto j ter ultrapassado R$ 10.000, 00 de seu voc precisar:
custo.
Criar uma WBS detalhada
E...voc provavelmente no vai conseguir dar uma
Definir milestones (marcos)
explicao que o convena.
Realizar estimativa de custos, esforo e prazo de
cada atividade
Vamos fazer uma pausa aqui. Este cenrio
Monitorar constantemente seu projeto
bem comum em muitas empresas de TI e voc
Gerenciar o projeto tomando aes sempre que
provavelmente j se deparou com uma situao
necessrio
similar. O que acontece que s se olha o
E o mais difcil, saber quanto do seu projeto foi
custo, e no se est vendo aqui um ponto muito
produzido (agregado) a cada dia.
importante: a produo.
Porm, voc est preparado e vem monitorando seu Parmetros para Anlise do Valor
projeto com EVM, e voc apresenta o grfico 3 ao seu Agregado
gerente.
Caro aluno, alm do que foi dito na seo anterior, para
Grfico 3- Curvas relativas ao Planejado, Realizado e voc realizar a Anlise do Valor Agregado adequadamente,
Agregado voc ter que conhecer alguns parmetros e seguir alguns
passos, que so descritos de uma maneira simplificada no
que se segue.
Determinar o Custo Orado do Trabalho Crono-

gramado ou Budgeted Cost of Work Scheduled
BCWS: durante a atividade de estimativa, o custo
Fonte: SOUZA [2009]
ou o esforo (em pessoas-hora, pessoas-ms, etc)
de cada tarefa planejado. BCWSi o custo ou
Voc explica ao seu gerente que, apesar do cronograma
esforo planejado para a tarefa de trabalho i. Para
mostrar que o projeto ultrapassou o custo em R$10.000,00,
determinar o progresso num determinado ponto
o que j foi produzido (agregado) representa R$61.000,00,
do cronograma do projeto, o valor de BCWS a
ou seja, produziu-se o equivalente a R$61.000,00 e gastou-
soma dos BCWSi de todas as tarefas de trabalho
-se apenas R$50.000,00.
que deveriam ter sido completadas at aquele
momento no cronograma do projeto.
Em outras palavras, seu projeto est muito bem e pro-
vavelmente voc terminar antes e com um custo menor Calcular o valor do Custo Orado do Trabalho
que o previsto Realizado ou Budget Cost of Work Perfomed
BCWP: o valor de BCWP a soma dos valores
O ponto chave para se conseguir isto gerenciar o que BCWS de todas as tarefas que foram efetivamen-
est sendo produzido. O gerente do projeto deve saber te completadas num determinado momento do
quanto do projeto est pronto a cada dia. cronograma.
Determinar o Oramento na Concluso ou Bud-

Com isso consegue-se saber quanto do projeto em
get at Completion BAC: os valores de todas as
percentual est pronto e consequentemente, o valor que
tarefas de trabalho programadas so somados
j foi agregado ao projeto.
para obter o BAC, ou seja, BAC = S (BCWSk)
43
A distino entre BCWS e BCWP que o primeiro re- ndice de Desempenho do Custo (Cost Perfor-
presenta o oramento das atividades que foram planeja- mance Index CPI):
das para estarem completadas at um determinado mo-
CPI = BCWP / ACWP
mento e o ltimo representa o oramento das atividades
que realmente foram completadas at aquele momento.
(CPI prximo de 1 indica de que o projeto est dentro
Completados os passos anteriores, podem-se calcular os
do oramento definido)
seguintes indicadores:
Varincia do Custo (Cost Variance CV):
ndice de Desempenho do Cronograma ou Sche-

CV = |BCWP ACWP|
dule Performance Index SPI:
(indicao absoluta das economias num custo (em

relao aos custos planejados) ou dos excessos do custo
(para um tempo qualquer))
Varincia do Cronograma ou Schedule Variance
SV: Exemplo de uma Anlise do Valor
Agregado
Problema:
O ndice de Desempenho do Cronograma (SPI) uma
indicao da eficincia com a qual o projeto est utilizando Considere que voc um gerente de projeto de sof-
os recursos cronogramados. tware e que lhe foi solicitado calcular estatsticas de valor
agregado para um pequeno projeto de software. O pro-
Um valor do SPI prximo de 1 indica execuo eficiente jeto tem 60 tarefas de trabalho planejadas, para as quais
do cronograma do projeto. SV uma indicao absoluta foram estimadas 648 pessoas-dia para sua finalizao.
da varincia do cronograma planejado.
Na ocasio em que a anlise do valor agregado lhe
Podem-se calcular tambm: solicitada, 10 tarefas j foram completadas. Todavia, o
cronograma do projeto indica que 14 tarefas deveriam ter
sido completadas. Os seguintes dados de cronogramao
Porcentagem programada para concluso =
(em pessoas-dia - PD) esto disponveis, como mostra a
BCWS / BAC (fornece uma indicao da porcenta-
tabela 18:
gem do trabalho que deveria ter sido completada
no tempo t.)
Tabela 18: Cronograma do projeto a ser desenvolvido
Porcentagem completada = BCWP / BAC (for-
nece uma indicao da porcentagem de conclu-
so do projeto num determinado momento t)
Custo Real do Trabalho Realizado (Actual Cost of

Work Performed ACWP) ( a soma do esforo
despendido realmente nas tarefas de trabalho
que foram completadas num certo momento do
cronograma do projeto
44
solicitado que voc calcule: BAC = 648 PD
ndice de Desempenho do Cronograma (SPI) De posse desses valores, podemos ento calcular os
Varincia do Cronograma (SV) parmetros solicitados.
Porcentagem Programada para Concluso ndice de Desempenho do Cronograma (SPI)
Porcentagem Completada
ndice de Desempenho do Custo (CPI) SPI = BCWP / BCWS = 105,5 / 146,5 = 0,72
Varincia do Custo (CV)
Lembrando que quanto mais SPI estiver prximo de
um maior ser a eficincia com a qual o projeto est utili-
Soluo:
zando os recursos cronogramados
Antes de comearmos, temos que obter os valores de
Varincia do Cronograma (SV)
BCWS, BCWP, ACWP e BAC que so os parmetros bsicos
atravs dos quais os outros parmetros so calculados. SV = |BCWP BCWS|= |105,5 146,5| = 41 PD
Lembrando que o valor de BCWS a soma dos BCWSi Quanto mais prximo de zero estiver SV mais prximo
de todas as tarefas de trabalho que deveriam ter sido do planejado estar o andamento (ou custo) do projeto.
completadas at aquele momento no cronograma do
projeto, teremos que somar os esforos planejados das Porcentagem Programada para Concluso
tarefas 1 at a tarefa 14, que deveriam ser as tarefas
finalizadas no momento da anlise do projeto. BCWS / BAC = 146,5 / 648 = 0,2261 = 22,61 %
BCWS = 14 + 13 + 14 + 6 + 10,5 + 15 + 9 + 6 + 13 + 5 + 4 Fornece uma indicao da porcentagem do trabalho

+ 15 + 17 + 5 = 146,5 PD que deveria ter sido completada no tempo t.
Agora vamos calcular o valor de BCWP, que a soma

Porcentagem Completada
dos valores BCWS de todas as tarefas que foram efetiva-
mente completadas num determinado momento do cro-
BCWP / BAC = 105,5 / 648 = 0,1628 = 16,28 %
nograma, ou seja, temos que somar os valores de esforos
planejados das tarefas 1 a 10:
Fornece uma indicao da porcentagem de concluso
BCWP = 14 + 13 + 14 + 6 + 10,5 + 15 + 9 + 6 + 13 + 5 do projeto num determinado momento t.
= 105,5 PD Note que comparando a Porcentagem Programada
com a Porcentagem Completada, calculadas acima, vemos
A seguir, obtemos o valor de ACWP, ou seja, a soma do que o projeto est atrasado.
esforo realmente despendido nas tarefas de trabalho que
foram completadas num certo momento do cronograma ndice de Desempenho do Custo (CPI)
do projeto. Nesse caso, temos que somar o esforo real
gasto nas tarefas completadas (tarefas de 1 a 10): CPI = BCWP / ACWP = 105,5 / 107 = 0,9860
CPI prximo de 1 indica de que o projeto est dentro

ACWP = 14,5 + 9 + 18 + 7,5 + 10 + 16 + 9 + 6,5 + 11 + 5,5
do oramento definido
= 107 PD

O BAC, que a soma dos valores de todas as tarefas Varincia do Custo (CV)
de trabalho programadas, foi fornecido no enunciado do
exemplo: CV = |BCWP ACWP| = |105,5 107| = 1,5
45
Indicao absoluta das economias num custo (em A figura 5 ilustra o formato de um diagrama de Gantt
relao aos custos planejados) ou dos excessos do custo simplificado. H vrios softwares que facilitam a criao
(para um tempo qualquer)) de diagramas de Gantt. Um dos mais conhecidos o MS
Project. Nele, quando uma tarefa introduzida, ela
Diagrama de Gantt programada para comear na data de incio do projeto.
Ou seja, no momento que voc entra com as tarefas, a
Caro aluno, vamos recapitular: uma vez que voc tenha data de incio de cada uma delas , por padro, a data
determinado o conjunto de tarefas a serem executadas, estabelecida para o incio do projeto.
voc ter que atribuir valores especficos de esforo e
durao para cada uma delas. A seguir, uma rede de Estabelecendo a durao de cada tarefa e as vinculan-
tarefas dever ser criada de modo a permitir que a equipe do, voc estabelece uma dependncia que determina a
sequncia de execuo das tarefas. Assim, o Project agen-
de software satisfaa a data de entrega estabelecida.
da as tarefas definindo as datas de incio e de trmino
de cada tarefa. As barras de Gantt so, ento, movidas
Um cronograma adequado exige que:
para as datas apropriadas na escala de tempo, e linhas
de vnculo so desenhadas para mostrar a dependncia,
todas as tarefas figurem na rede conforme se pode ver na figura 5.
o esforo e durao sejam adequadamente atribu-
dos a cada tarefa
as interdependncias entre as tarefas sejam indica-
das
recursos (humanos e materiais) sejam alocados ao
trabalho a ser feito
marcos de referncia pouco espaados sejam es-
tabelecidos de modo que o progresso possa ser
acompanhado
Para auxiliar na cronogramao de projetos, voc pode

Figura 5 Exemplo de Diagrama de Gantt
fazer uso, dentre outras opes, de diagramas de Gantt
(ou diagrama de barras) e redes de atividades. De uma
Existem 4 tipos de dependncias (vnculos) entre ta-
maneira simplificada, podemos dizer que:
refas: trmino-a-incio, trmino-a-trmino, incio-a-incio
e incio-a-trmino. A dependncia trmino-a-incio a
O diagrama de Gantt pode mostrar para quando mais comum, enquanto a dependncia incio-a-trmino
est programado o incio e trmino de cada ativi- a menos comum. Uma descrio e um exemplo de cada
dade (tarefa), quem so os responsveis por elas, dependncia so fornecidos na figura 6.
os vnculos entre essas atividades, o andamento
de cada uma (em relao ao que j foi realizado O grfico de Gantt foi a primeira tcnica formal de cro-
at determinado momento), alm de ser poss- nogramao desenvolvida. Data do incio do sculo XX
vel relacionar os recursos materiais necessrios a quando Henry L. Gantt a formulou. Foi desenvolvida para
cada uma delas. Seu mrito est na simplicidade. fornecer uma maneira mais formal e sistemtica de orga-
nizar as tarefas de um projeto principalmente quando o
As redes de atividades mostram a durao de cada
tempo um fator importante.
atividade e a dependncia temporal entre elas.
46
O diagrama de Gantt sobreviveu em seu formato bsi- Paralelamente ao desenvolvimento das redes PERT, a
co e hoje em dia continua a ser largamente utilizado como indstria de construo desenvolveu um outro sistema de
ferramenta de cronogramao em todos os nveis organi- cronogramao utilizando redes baseado no conceito de
zacionais. caminho crtico.
O caminho crtico de um projeto o caminho ao lon-

go das atividades da rede que consome mais tempo at a
concluso do projeto. Esta abordagem foi denominada M-
todo do Caminho Crtico ou CPM- Critical Path Method.
Uma terceira tcnica de cronogramao utilizando re-

des tambm foi desenvolvida, o PDM - Precedence Dia-
gram Method.
Seu objetivo permitir uma descrio mais acurada dos

relacionamentos entre as vrias atividades do que as forne-
cidas pelas duas outras tcnicas.
De uma forma geral, as redes de atividades citadas so

representaes grficas das atividades de um projeto, nas
quais apresentada a sequncia lgica de planejamento,
Figura 6: Dependncias entre tarefas com as interdependncias entre as tarefas, que tm por fi-
nalidade atingir um objetivo, que a concluso do projeto.
Rede de Atividades: PERT/CPM/PDM
Para o planejamento de uma rede de atividades, voc
As redes de atividades foram desenvolvidas para su- ter que:
perar a limitao primria do diagrama de Gantt, que
a inabilidade de retratar claramente os relacionamentos, identificar as atividades
dependncias e restries dentre as atividades e eventos identificar a ordem em que essas atividades ocorrem
de um projeto.
determinar a durao das atividades
A primeira tcnica desenvolvida de cronogramao uti-
lizando redes foi o PERT- Program Evaluation and Review
Na figura 7, podemos ver uma representao de alguns
Technique. Ela foi utilizada pela primeira vez como ferra-
dos principais elementos de uma rede.
menta de gerenciamento para cronogramao e controle
no projeto do mssil americano Polaris, por volta de 1950.
PERT permite que gerentes visualizem o projeto intei-

ro, identifiquem inter-relacionamentos e dependncias
entre atividades e reconheam quando e onde atrasos
so aceitveis.
Um dos aspectos-chave dessa rede o uso de tcnicas Figura 7 Elementos de uma rede de atividades
probabilsticas para desenvolver um conjunto de estima-
tivas de tempo para cada atividade, tornando-a particu- Na rede de atividades temos dois tipos de atividades:
larmente adequada para projetos em que difcil fazer atividades dependentes e atividades paralelas, que esto
estimativas acuradas com alta preciso. explicitadas nos diagramas apresentados na figura 8.
47
Para redes complexas, podemos definir cedo do even-

to, tarde do evento, folga do evento e caminho critico. Os
diagramas mostrados na figura 10 exemplificam cada um
desses termos, ressaltando que a definio de caminho cr-
tico apresentada a que derivada da teoria dos grafos.
Figura 8: Tipos de atividades

O tempo de execuo da rede pode ser obtido confor-
me mostrado na figura 9.
Figura 9: Clculo do tempo de execuo da rede de ati-

vidades
48
Figura 10 Definio e exemplos de Cedo, Tarde, Folga dos processos utilizados na sua organizao, bem como
do evento e Caminho Crtico na conduo de cada projeto individual executado dentro
Alm dessa definio de caminho crtico, que origi- da empresa.
nada da teoria dos grafos, h uma outra definio que
o define como os eventos por onde ele passa tm folga Um programa de mtricas que seja baseado nas metas
zero. Notamos que por essa ltima definio, pode haver de uma organizao auxiliar na comunicao e na medi-
mais de um caminho crtico em uma rede de atividades. da de progresso em relao a essas metas. As equipes tra-
balharo focadas no que considerado importante para
Atravs do uso de uma ferramenta de software ade- a organizao.
quada, voc poder atualizar e retrabalhar, caso neces-
srio, essas redes, tendo informao do status e controle Mtricas bem projetadas, com objetivos bem docu-
sobre as atividades e cronograma do projeto. mentados, podem auxiliar a organizao a obter a infor-
mao que ela necessita para a melhoria contnua de seus
interessante comentar que h vrias outras possibili- produtos, processos e servios, mantendo o foco no que
dades de representaes grficas para redes de atividades importante.
alm daquelas apresentadas aqui. A despeito de sua gran-
de utilidade, h limitaes no uso das redes de atividades. Um mtodo prtico e sistemtico de selecionar, proje-
O valor de uma rede de atividades estar diretamente tar e implementar mtricas de software um auxlio va-
dependente da validade das estimativas de tempo feitas lioso na busca dos objetivos de melhoria organizacional. E
para cada atividade. Alm disso, s vezes difcil retratar para isso, pessoas com conhecimento e treinamento ade-
acuradamente todas as atividades e relacionamentos, es- quados so necessrias.
pecialmente em projetos grandes e complexos.
Podemos dizer que, com a concluso dessa discipli-
Por fim, uma vez desenvolvida uma rede de atividades na, voc deu um passo importante nesse sentido e, caso
detalhada, ela tende a ser o foco da ateno dos gerentes, tenha oportunidade, poder auxiliar a sua organizao a
quando, na verdade, haver vrios outros fatores no retra- atingir suas metas de melhoria nas vrias reas do desen-
tados na rede que requerero especial ateno no proces- volvimento de software.
so de gerenciamento. Portanto, caso voc venha a geren-
ciar um projeto, tenha o cuidado para no cair nesse erro. Prof. Marcelo Pintaud
Consideraes Finais Referncias

Caro aluno, essa disciplina introduziu vrios conceitos BOEHM, B. Software Engineering Economics. New Jer-
relativos a mtricas de software. Voc foi alertado sobre a sey: Prentice-Hall, 1981.
importncia de obter medidas das 3 principais caracters- BOEHM, B. W. Software Risk Management: Principles
ticas do desenvolvimento de software: produto, processo and Practices. IEEE Software. V. 8. N. 1. p. 32-41, Jan 1991.
e projeto. Uma vez que essas medidas so coletadas, m- BOOCH, G., RUMBAUGH, J., JACOBSON, I. UML guia
tricas podem ser derivadas. do usurio. Rio de Janeiro: Editora Campus, 2006.
BLOOGS, Wendy. Mastering UML com Rational Rose
Foi abordado, tambm, que a prtica de armazenar 2002: A Bblia. Rio de Janeiro: Alta Books, 2002.
mtricas em uma base de dados bem projetada, auxiliar CSSE Center for Systems and Software Engineering.
na sua utilizao como indicadores futuros. Desse modo, COCOMO II. 2012. Disponvel em: http://sunset.usc.edu/
voc poder utiliz-las, por exemplo, na melhoria dos csse/research/COCOMOII/cocomo_main.html.
produtos entregues para os clientes, no aprimoramento Acesso em 18 ago. 2012.
49
FLORIG, H. K.; et al. A Deliberative Method for Ranking Glossrio de Siglas

Risks: Overview and Test Bed Development. Risk Analysis.
V.21, N.2, p. 913-921, 2001. CASE - Computer-Aided Software Engineering (Engenha-
IEEE Computer Society. SWEBoK: Guide to the Softwa- ria de Software Auxiliada por Computador)
re Engineering Body of Knowledge. 2012. Disponvel em: CBD - Component-based Development (Desenvolvimen-
http://www.computer.org/portal/web/swebok/v3guide; to Baseado em Componentes)
jsessionid=bf5c6ea195ad20decbdfb94638c0. Acesso em CBSE - Component-based Software Engineering (Enge-
18 ago.2012 nharia de Software Baseada em Componentes)
LONGSTAFF, T. A.; CHITTISTER, C.; PETHIA, R.; HAIMES,
COCOMO - COnstructive COst MOdel (Modelo de Custo
Y. Y. Are we forgetting the risks of information technology?
Construtivo).
IEEE Computer. Vol. 33. N.12. p. 43-51. Dez. 2000.
PAULA FILHO, Wilson P. Engenharia de software: fun- COTS commercial-off-the-shelf (Software Comercial de
damentos, mtodos e padres. 3.ed. Rio de Janeiro: LTC, Prateleira)
2009. CPM - Critical Path Method (Mtodo do Caminho Crtico)
PETERS, J. F.; PEDRYC, W. Engenharia de software: te-
oria e prtica. Rio de Janeiro: Campus, 2001. DERS - Documento de Especificao de Requisitos de Software
PMI - Project Management Institute. Um guia do Con- DSDM - Dynamic Systems Development Method (Mto-
junto de Melhores Prticas em gerenciamento de Projetos do de Desenvolvimento de Sistemas Dinmico)
(Guia PMBOK) Quarta Edio. Atlanta: PMI Book Service
EVM - Earned Value Management (Anlise do Valor Agregado)
Center, 2008.
PRESSMAN, R. S. Engenharia de Software. 7.ed. So ICASE Integrated Computer-Aided Software Engineering
Paulo: McGraw-Hill, 2010. (Engenharia de Software Apoiada por Computador Integrada)
PRESSMAN, R. S. Engenharia de Software. 6.ed. So IEEE - Institute of Electrical and Electronics Engineers (Ins-
Paulo: McGraw-Hill, 2006. tituto de Engenheiros Eletricistas e Eletrnicos)
RUMBAUGH, James; et al. Modelagem e Projeto base-
IFPUG International Function Point Users Group (Grupo
ados em objetos. Rio de Janeiro: Campus, 2006.
Internacional de Usurios de Pontos por Funo)
ROPPONEN, J.; LYYTINEN, K. Components of software
development risk: How to address then? A project ma- ISO International Organization for Standardization (Or-
nager survey. IEEE Transactions on software engineering. ganizao Internacional para Padronizao)
Vol.26, N.2, p.98-112. Feb. 2000. PDM - Precedence Diagram Method (Mtodo do
SCHACH, Stephen. Engenharia de Software: os para- Diagrama de Precedncia)
digmas clssico e orientado a objetos. So Paulo: McGra-
wHill, 2008. PERT - Program Evaluation and Review Technique
SHORE, James; WARDEN, Shane. A Arte do Desenvolvi- (Tcnica de Avaliao e Reviso de Programa)
mento gil. Porto Alegre: Alta Books, 2008. PMI - Project Management Institute (Instituto de
SOMMERVILLE, Ian. Engenharia de Software. So Pau- Gerenciamento de Projetos)
lo: Addison-Wesley, 2007.
PMBoK Project Management Body of Knowledge.
THE STANDISH GROUP.Chaos Manifesto 2013. http://
(Conjunto de Melhores Prticas em Gerenciamento de
www.versionone.com/assets/img/files/ChaosManifes-
Projetos)
to2013.pdf. Disponvel em:. Acesso em 28 mai. 2015.
SOUZA, Washington. O que EVM Earned Value Ma- SWEBOK - Software Engineering Body of Knowledge
nagement. 2009. Disponvel em: http://www.blogcmmi. (Corpo de Conhecimento da Engenharia de Software)
com.br/gestao/o-que-e-evm-earned-value-management. UML Unified Modeling Language (Linguagem de
Acesso em 18 ago. 2012. Modelagem Unificada)
50

Metricas de Software

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Metricas de Software

Încărcat de

Drepturi de autor:

Formate disponibile

Mtricas de Desenvolvimento de Software

Avaliao e Priorizao de Riscos 35

Introduo software, que a gesto de riscos. Todo projeto est ex-

todo empreendimento, incluindo o desenvolvimento de

Na definio mais geral, medio o ato de determinar uma medida.

A figura 1 ilustra esses conceitos.

Figura 1: Viso Geral sobre Medida, Mtrica e Indicadores

Classificao das Mtricas de Software

As mtricas privadas se aplicam ao indivduo e as

mtricas objetivas: so obtidas atravs de regras Tipos de Mtricas de Software

Porm, caro aluno, vale lembr-lo que a qualidade do

Pontos por Funo (PF ou FP- Function Points)

Quadro Q2: 14 perguntas relacionadas s funcionalidades

Leia tambm o material disponibilizado no link.

Importante ! n1 o nmero de operadores nicos e

uma medida de dimenso total de um software, de-

es sequenciais e os arcos orientados indicam o sentido Fluxos de informaes na estrutura de um programa

As mtricas de Halstead e de complexidade ciclomti-

profundidade e a largura da hierarquia de classes. Modificao de Objetos Reusados (PRO - Percent

Granularidade da Aplicao (APG - Application Medidas Aplicadas Metodologia gil

Nmero de Commits: representa o nmero de

Estimativas Originais: representa o total de pon-

Estimativas Finais: representa o total de pontos

Nmero de Estrias Entregues: representa o n- As ferramentas que trabalham com aplicao de m-

Ferramentas de estimativa de custo e esforo

Estimativas de Software Fonte: http://hostintermex.com/img/slider/female-pushing.jpg

precisamos conhecer as estimativas de software.

defina as tarefas e marcos da engenharia de sof- A estimativa de recursos, de custo e de cronograma,

A primeira atividade de planejamento do projeto de

Normalmente no incio de um projeto h uma incer-

Para cada um dos recursos indicados na pirmide Tcnicas de Estimativas: Decomposio

Como alternativa, o planejador pode escolher outros

Uma vez determinado o valor esperado para a varivel

Aps o clculo das estimativas de LOC para cada

Considerando que uma anlise de dados histricos

Portanto, o custo total estimado para o projeto de:

A tabela 2 apresenta as estimativas de tamanho

Tabela 4: Tabela sugerida na anlise por ponto de funo

Utilizando a expresso emprica proposta pelo mode-

Uma vez que se tenha obtido a produtividade mdia

Tabela 5: Fatores de Ponderao Exemplo 3

Suponha que a sua empresa foi contratada para desen-

Devido a isso, tem procedimentos de coleta de da-

Utilizando os dados do exemplo 2 proposto e consi-

Na tabela 7, os valores de Contagem apresentados na

claro que, antes de serem usados na sua empresa,

Substituindo os valores de Contagem Total ( = 346)

A maioria dos modelos de estimativa tem alguma for-

a estimativa de tamanho do software em LOC

Portanto, para utilizar esses modelos, eles devem ser

Exemplo de Aplicao do Modelo Emprico

Tabela 10: valores de ai e bi para os nveis Bsico e

Exemplo de aplicao do COCOMO

Caro aluno, no modelo Application Composition, o es-

teturas alternativas ou estratgias de desenvolvimento

As principais variveis de entrada para o modelo so: o onde:

Pontos de funo podem ser utilizados como boas es-

O modelo Post-Architecture utiliza 17 direcionadores

A tabela 13 exemplifica uma possvel decomposio do

Tabela 13: Decomposio do produto e do processo

Fonte: baseado em PRESSMAN [2010]

Exemplo de conciliao de estimativas

Estimativa de Esforo baseada em LOC @ 65 pm

Concluso: Como a variao mxima est dentro da fai-