Pesquisa da Maturidade das Boas Práticas de Estimativas

e Métricas em Organizações Paraenses

Fábio L. Figueiredo1, Luiz O. Barata1
1Especialização em Gerência de Projetos de Software – Instituto de Ciências Exatas
Universidade Federal Pará (UFPa)
Caixa Postal 66075 – 110 – Belém – PA – Brasil
fabiolima.net@gmail.com, luiz.ufpa@gmail.com

Resumo. Este trabalho consiste em elaborar uma pesquisa da maturidade de

boas práticas de estimativas e métricas em organizações paraenses, visando
também citar algumas ferramentas e metodologias que visam auxiliar na
melhoria do uso de medições e favorecer à possíveis estimativas. É
importante ressaltar que para a realização da pesquisa foi elaborado um
questionário baseado nos resultados esperados do modelo MPS.BR, no que
tange estimativas e métricas.

Abstract. The meaning of this work is to make a research about the maturity
of good estimates and metrics in Paraenses organizations but also to offer
some tools and methodologies to help the improvement the use of
measurements and encourage possible estimates. It is important to emphasize
that to conduct the study a questionnaire was developed based on expected
results of the model MPS.BR in regard estimates and metrics.

1. Introdução
1.1. Contexto do Trabalho
Segundo Kaplan (KAPLAN, 2004 apud OLIVEIRA, 2005), o que não se pode medir,
não se pode gerenciar. A frase traduz a necessidade, cada vez maior, que os atuais
gestores têm de se servir de metodologias e indicadores que lhes permitam estabelecer
objetivos, monitorar os resultados e verificar, de forma objetiva, como essas metas
propostas foram atingidas.
Deste modo, o presente trabalho tem como objetivo apresentar a importância do
uso de estimativas e métricas dentro da gestão de gerência de projetos de software,
enfatizando a diferença entre medição e estimativa assim como os resultados esperados
dentro do modelo MPS.Br (Melhoria de Processo de Software Brasileiro), apresentando
recomendações para aplicação de estimativas e métricas através da descrição de
ferramentas de software específicas relacionadas ao tema e por fim apresentar uma
análise estatística da maturidade das organizações ou empresas de software paraenses
no uso de estimativas e métricas, através da elaboração e aplicação de um questionário
baseado nos resultados esperados no que diz respeito às recomendações do modelo
MPS.Br.
1.2. Justificativa
A falta de maturidade e até mesmo a falta de conhecimento sobre a importância do uso
de métricas e estimativas para se obter qualidade no desenvolvimento de software vem
ser o grande motivo para a elaboração deste trabalho, procurou-se verificar como as
empresas ou organizações paraenses vem desenvolvendo seus projetos no que cerne o
bom uso de estimativas e métricas.
1.3. Motivação
Devido a grande quantidade de questionamentos sobre como utilizar métricas e
estimativas para possíveis obtenções de sucesso em projetos de software, surgiu a
necessidade de se verificar como se encontra a maturidade das organizações paraenses
nesse meio. E quais os recursos para se chegar a um nível de qualidade.
1.4. Objetivo
Obter um levantamento da maturidade das boas práticas de métricas e estimativas em
organizações paraenses, tendo como base as orientações dos resultados esperados do
MPS.BR (Modelo de Processo do Software Brasileiro). Citar algumas ferramentas e
métodos para o uso de métricas e estimativas, bem como servir de apoio para que seja
dada a importância e mostrar a boa utilidade de medições para estimar projetos com
qualidade.
1.5. Organização do Trabalho
Este trabalho foi estruturado em sete capítulos, incluindo este, que foram
distribuídos como descrito a seguir:
Capítulo 1: introdução.
Capítulo 2: tem por objetivo fazer uma síntese sobre gerência de projetos,
passando pelas definições formais, suas formas e práticas, algumas das principais
atividades, bem como sua importância e sua relação com medição de software.
Capítulo 3: descreve conceitos de métricas e estimativas, como se relacionam,
as melhores práticas, a importância do uso em favor da qualidade e os cenários em que
podem ser utilizadas.
Capítulo 4: faz uma introdução ao MPS.BR descrevendo seu conceito, sua base
em modelos internacionais, das vantagens, motivação para criação do modelo e
descrição os níveis.
Capítulo 5: discursa sobre a análise da maturidade das empresas pesquisadas,
apresenta um resumo dos resultados esperados do MPS.BR que serviram de base para o
questionário, descreve sobre a estrutura do questionário avaliativo, organizações
avaliadas e a apresentação dos resultados.
Capítulo 6: trata das recomendações para aplicação de estimativas e métricas,
ferramentas que podem ser usadas, procedimentos e técnicas mais utilizadas.
 Capítulo 7: faz as considerações finais do trabalho, abordando as principais
contribuições e limitações, enunciando as perspectivas para futuras pesquisas que
possam ajudar as empresas paraenses nas boas práticas de métricas e estimativas.

2. Gerência de Projetos
Hoje o uso de melhores práticas em gerenciamento de projetos já é encarada como um
fator de aumento de chances dos empreendimentos darem certo, pois é uma ação
estratégica de cada empresa. O entendimento do objetivo da gerência de projetos e sua
importância são esclarecidos por muitos autores.
Segundo (PMI, 2004), o gerenciamento de projetos é a aplicação de
conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos.

O gerenciamento de projetos de software é uma parte essencial da

engenharia de software. Um bom gerenciamento não pode garantir o sucesso
de um projeto. No entanto, um mau gerenciamento geralmente resulta em
falha do projeto: o software é entregue com atraso, custa mais do que foi
originalmente estimado e falha ao atender seus requisitos (Sommerville,
2007).

Para Pressman (2006), a gestão do projeto envolve o planejamento, a

monitoração e o controle do pessoal, processo e eventos que ocorrem à medida que o
software evolui de um conceito preliminar para uma implementação operacional.
SOMMERVILLE (2003) apresenta algumas atividades que são consideradas comuns
entre diversos projetos de software: Elaboração de Propostas, Planejamento e
programação de projetos, custo do projeto, Monitoramento e revisões de projeto,
Seleção e avaliação de pessoal e Elaboração de relatórios e apresentações. A atividade e
o número de atividades podem variar de projeto para projeto de software devido às
especificidades de cada projeto. Entretanto, é fundamental para o desenvolvimento
profissional de projetos de software que ocorra um planejamento mínimo dos passos
que deverão ser realizados para concluir com sucesso um projeto de software.

Atividade: Elaborar Proposta

A proposta é um documento (artefato) que descreve como o projeto de software

será executado. Entre os seus principais tópicos estão: Objetivo do Projeto, Estimativas
de Custo e Programação. A proposta, portanto, é um documento apresentado a um
provável cliente que especifica como o desenvolvedor pretende conduzir o
desenvolvimento do produto de software. Caso a proposta seja aprovada, pode ser
transformado em um contrato entre desenvolvedor e cliente. Então, trata-se de um
documento que deve ser elaborado por pessoas experientes, pois erros nas estimativas
de custo ou prazos, por exemplo, podem resultar em prejuízos para o cliente e/ou
desenvolvedor.
 Atividade: Planejar e Programar o Projeto

Essa atividade tem como foco principal identificar e descrever as atividades que
serão executadas para atingir o objetivo especificado na Proposta (Ciclo de Vida
detalhado) e estimar o tempo e custos relacionados a esse projeto. Portanto, pressupõe-
se que o cliente aprovou a proposta e foi firmado um contrato entre ambos.

Atividade: Monitorar o Projeto

O monitoramento do projeto de software é uma atividade que procura

acompanhar o andamento do projeto e comparar o progresso e custos reais aos previstos
inicialmente no Plano de Projeto. Dependendo da complexidade, tamanho e processo de
software padrão de uma empresa de desenvolvimento (entre outros fatores), o
Monitoramento também pode envolver a observação, por parte do Gerente de Projetos,
de possíveis riscos que poderiam comprometer o projeto de software. Desta forma, a
atividade de Monitoramento deve definir quais mecanismos serão utilizados para
realizar essas tarefas, por exemplo: reuniões periódicas com a equipe, consulta a
relatórios técnicos e gerenciais, controle do tempo (cronograma) etc.

Atividade: Selecionar e Avaliar Pessoal

Dependendo do tipo de projeto, a seleção de pessoal é uma atividade empregada

no gerenciamento de projeto e tem por objetivo formar uma equipe capaz em número
(quantidade de pessoas) e habilidade para executar o projeto. Na seleção e avaliação do
pessoal, são considerados aspectos como tempo de experiência, habilidade com as
tecnologias que serão utilizadas no projeto, custo da hora do profissional etc.

Atividade: Elaborar Relatórios e Apresentações

Nessa atividade o Gerente de Projeto deve produzir relatórios que apresentem o

andamento do projeto de forma concisa e objetiva. Os relatórios podem ser destinados
tanto para o cliente como à empresa. Portanto, o Gerente deve ser hábil em redigir e
apresentar as informações em reuniões contidas nos relatórios.

As atividades descritas anteriormente sofrerão variações para cada projeto,

dependendo também da maturidade do gerente de projetos. Vale ressaltar que uma
organização pode adotar processos baseados em padrões da engenharia de software para
auxiliar na área de gerência.

Na área de TI, os sucessivos fracassos observados nos projetos de software ao

longo das últimas décadas (CHAOS, 1994 apud OVIGLE et al., 2007), levaram grande
parte das organizações a adotarem uma abordagem mais disciplinada para o
desenvolvimento do software. O Rational Unified Process (RUP) é um processo de
engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir
tarefas e responsabilidades dentro de uma organização de desenvolvimento, buscando
garantir a produção de software de alta qualidade que atenda às necessidades de negócio
dentro dos prazos e custos estimados. Por ser um processo de engenharia de software, o
RUP é uma tecnologia em camadas, onde a camada do “Processo” é sustentada pelas
camadas de “Métodos” e “Ferramentas”, podendo ser adaptado para atender as
necessidades de cada organização focando na qualidade dos produtos produzidos,
tornando-se um instrumento útil para a aplicação de controles e técnicas de
gerenciamento. (RUP, 2003; PRESSMAN, 2002 apud OVIGLE et al., 2007).

Para CASTOR (2003), O RUP não cobre todos os aspectos de gerência de

projetos de software, como: recursos humanos, custo e orçamento, contratação e etc.
Porém para os aspectos relacionados ao produto de software, o RUP descreve algumas
das atividades e técnicas desempenhadas pelo gerente de projeto.

Uma visão mais detalhada do fluxo de atividades na gerência de projetos pode

ser observada na Figura 1, de acordo com o RUP.

Figura 1. Gerenciamento de Projeto: Fluxo de Trabalho (RUP.2001)

2.1. A Importância da Gerência de Projetos de Software

Segundo (AMARAL, 2008), gerenciar projetos corretamente é uma questão de
sobrevivência empresarial, as empresas necessitam de uma posição competitiva no
mercado, oferecendo produtos e serviços com qualidade, preços justos e dentro dos
prazos. As disciplinas de gerenciamento de projetos têm se mostrado
comprovadamente, eficientes em aumentar as probabilidades de sucesso de projetos, em
todas as indústrias. É importante salientar que não se utiliza gerência de projetos apenas
para reduzir os riscos de fracasso total do projeto, mas sem dúvida este é seu objetivo
maior. O fracasso de um projeto é o maior pesadelo de gerentes de projetos, equipes,
patrocinadores e envolvidos em geral. Os motivos que podem levar ao fracasso de um
projeto são inúmeros e obras inteiras têm sido escritas sobre este assunto. Porém
existem razões mais comuns que levam ao fracasso o maior número de projetos na
indústria em geral. Fergus O’Connell, em sua obra How to Run Successful High-Tech
Project-Based Organizations (Artech House, 1999 apud AMARAL, 2008) apresenta
uma relação dos dez principais motivos que levam projetos ao fracasso:
• Os objetivos do projeto não são bem definidos e/ou os envolvidos não são
identificados;
• Os objetivos do projeto são definidos de forma apropriada, mas as mudanças
não são controladas de forma apropriada;
• O projeto não é planejado de forma apropriada;
• O projeto não é gerenciado de forma apropriada;
• O projeto é planejado de forma apropriada, porém seus recursos não são
gerenciados;
• Não são criados planos de contingência;
• As expectativas dos envolvidos com relação ao projeto não são gerenciadas;
• O projeto é planejado de forma apropriada, mas seu progresso não é
monitorado e controlado;
• Relatórios de progresso são inadequados ou inexistentes;
• Quando ocorre problemas no projeto, as pessoas acreditam que os mesmos
podem ser resolvidos de forma simples.
Problemas como esses estão presente na indústria de software à anos. Após
algumas décadas de evolução a Standish Group, publicou o Chaos Report em 1994
(Standish, 1994) mostrando o resultado de uma pesquisa realizada em mais de 175.000
projetos de software pelo mundo. Segundo a pesquisa somente 16% dos projetos são
finalizados com sucesso. O critério para ser considerado de sucesso é o cumprimento do
prazo, custo e escopo. Projetos que não cumprem pelo menos uma dessas variáveis são
considerados “Desafiados”. Como pode ser visto na Figura 2, 53% dos projetos não
cumprem alguma das variáveis supracitadas. Por fim, 31% dos projetos, denominados
“Cancelados”, são cancelados por completo.
 Chaos Report 1994
16%

Sucesso
Cancelados

Desafiados
53%

31%

Figura 2. Resultado do Chaos Report de 1994

Mais espantoso ainda é fato de que os relatórios subsequentes (Standish,

2004) não mostram uma melhora significativa no número de projetos que são entregues
fora do prazo, acima do orçamento ou com menos funcionalidades do que proposto, ou
seja, os “Desafiados”. A Figura 3 mostra que apesar de ter havido uma diminuição no
número de projetos cancelados e aumento nos que obtiveram sucesso, muitos projetos
ainda são “Desafiados”. Inclusive o número de projetos de sucesso ficou, em geral,
abaixo de 1/3 do total de projetos pesquisados. Isto demonstra que mesmo depois de
mais de 35 anos de evolução, os projetos continuam com os mesmos problemas do
passado.

Chaos Report

2004 29% 18% 53%

2002 34% 15% 51%

2000 28% 23% 49% Sucesso

Cancelados
1998 26% 28% 46% Desafiados
1996 27% 40% 33%

1994 16% 31% 53%

0% 20% 40% 60% 80% 100%

Figura 3. Resultado do Chaos Report entre 1994 e 2004

Em 2004, o Relatório Chaos Report, ao analisar os projetos de T.I (Tecnologia

da Informação) que falharam, afirma que, para a maioria deles, a principal causa não foi
a falta de recursos financeiros ou acesso à tecnologia, mas sim, falta de conhecimento
em gestão de projetos. E este conhecimento não se aplica somente à figura do Gerente
de Projetos, mas a toda equipe.
2.2. Gestão e Medição
Já foram discutidos diversos problemas relacionados ao desenvolvimento de software,
os quais são resultantes da omissão ou do mau uso de metodologias e técnicas
adequadas a esta importante tarefa de engenharia.
No entanto, boa parte dos fracassos no que diz respeito aos projetos de software
deve-se, principalmente, a problemas de administração ou gerenciamento do
desenvolvimento de software.
Mas especificamente na medição dentro da gerência de projetos, percebemos
que muitas empresas não adotam, desconhecem ou não possuem maturidade para
realizar técnicas de medições, sendo elas de tão fundamental importância.
Segundo De Marco (1993, apud Fernandes, 1995), “You cannot control what
you cannot measure”, ou seja, não gerenciamos nada sem as medições necessárias, até
mesmo projetos de software.
Para Contador (2008), um dos motivos da baixa adesão ao uso de medidas na
área de software é o alto custo da coleta de dados dentro da organização. Além disso, a
definição do que deve ser medido pela empresa representa uma das grandes dificuldades
do processo. Embora exista uma gama variada de atividades a serem controladas, é
necessário focar a coleta em um grupo restrito de dados, contemplado apenas as
medidas necessárias, tornando o processo de coleta menos trabalhoso.
3. Medição versus Estimativa
Quando se fala em métricas, então, deve-se ter em mente que se trata de dados
(números) quantitativos que irão mostrar em forma de indicadores o estado atual de um
determinado projeto. A busca pela qualidade utilizando métricas de software deve ser
aplicada tanto às pessoas que produzem o produto, quanto para o processo em que se
desenvolve o mesmo produto. Com métricas podemos estimar prazos de entregas finais
e ter uma visão global do projeto. É muito importante que os gerentes de projetos de
software tenham o hábito de sempre estar medindo seus projetos para saberem como o
mesmo está evoluindo e apresentar de forma clara os resultados obtidos para as pessoas
envolvidas.

A utilização de métricas tem como objetivo medir a produtividade e qualidade

de software, assim como para planejar e estimar projetos de software. Segundo
Fernandes (1995, apud Oliveira, 2006), a medição está associada a vários aspectos do
desenvolvimento de software:
• Durante a fase de planejamento, as informações coletadas nas medições de
projeto anteriores poderão ser utilizadas na estimativa do novo projeto;

• Durante o desenvolvimento de software, as medições são coletadas e

analisadas em relação às estimativas propostas inicialmente;

• Ao término do desenvolvimento, medições são coletadas e analisadas,

gerando as métricas do produto, como por exemplo, a taxa de defeito (que
refletirá a qualidade do software produzido).
 Assim as métricas podem ser definidas como o resultado extraído de
determinadas medições coletadas ao longo do desenvolvimento.

Já uma desvantagem é que a métrica de software não oferece

100% (cem por cento) de confiança em seus resultados. A métrica serve de base para o
conhecimento no campo da medição na gestão de projetos, com ajuda de projetos que já
foram concluídos no passado, e não uma base de dados a qual se pode confiar e fazer
estimativas que futuramente não serão aceitas e tomarão boa parte do tempo tentando
adivinhar quanto tempo irá se gastar para produzir tal produto ou refazendo todo o
trabalho.

Segundo Kozak (1997, apud Oliveira, 2006), as métricas de software podem ser
classificadas de várias maneiras:

• Objetivas/Subjetivas. As métricas objetivas são facilmente quantificadas e

medidas através de expressões numéricas ou representações gráficas dessas
expressões, e calculadas de documentos de software. Já as subjetivas são
medidas relativas baseadas em estimativas pessoais ou de grupo, sendo
obtidas por termos linguísticos como alto, médio e baixo;

• Absolutas/Relativas. Métricas absolutas não sofrem variação com a adição

de novos itens. O tamanho de um programa, por exemplo, é uma medida
absoluta (independente do tamanho de outras). Métricas relativas modificam-
se com a influência de outras. Métricas objetivas são geralmente absolutas,
enquanto que métricas subjetivas tendem a ser relativas;

• Explícitas/Derivadas. Métricas explícitas são coletadas diretamente,

enquanto que métricas derivadas são computadas a partir de outras métricas
explícitas ou derivadas. Um exemplo de uma medida explícita pode ser
"programador-mês", enquanto que "produtividade" (ou "linhas de código")
por "programador-mês" seriam métricas derivadas;

• Dinâmicas/Estáticas. Métricas dinâmicas possuem a dimensão tempo,

como por exemplo, erros encontrados por mês. Assim, os valores tendem a se
modificar dependendo quando as métricas são realizadas dentro do ciclo de
vida do produto. Métricas estáticas, entretanto, permanecem sem variação,
como por exemplo, o esforço total despendido ou total de defeitos
encontrados durante o desenvolvimento de um produto;

• Preditivas/Explanatórias. Métricas preditivas podem ser obtidas ou geradas

antes do evento ocorrer, enquanto que as métricas explanatórias são
produzidas após a ocorrência do fato.

De uma forma geral, as métricas são especialmente úteis quando um histórico

detalhado dos desenvolvimentos anteriores está disponível na organização.
Adicionalmente, ferramentas estão disponíveis para auxiliar na automação da coleta de
métricas. (Oliveira, 2000 apud Oliveira, 2006).
 Dependendo do ambiente existe uma possibilidade de métrica a ser adotada e
analisada, a Figura 4 apresenta onde pode ser empregado métricas dentro de uma
organização de desenvolvimento de software.

Figura 4. Ambientes para Aplicação de Métricas (NETO, 2006)

A princípio, é necessário determinar o que se quer medir, a fim de se definir

como os dados serão coletados. Essas decisões devem ser compatíveis com o processo
de desenvolvimento. Uma metodologia de métrica e estimativa não vai solucionar de
imediato os problemas de um processo de desenvolvimento, no entanto esta deve ser
utilizada para tornar possível o entendimento do processo, para facilitar a previsão de
suas fases e mostrar como controlá-las.
Uma das grandes dificuldades nas organizações de desenvolvimento e software
principalmente para o gerente de projetos é entender da necessidade de se utilizar
métricas em favor da qualidade dos serviços desenvolvidos.
A medição favorece um autoconhecimento interno da organização em termos
quantitativos, podendo ser um ponto culminante para tomada de decisões em uma
pressão imediata tanto interna quanto externa à organização. Vale ressaltar que toda a
base de medidas organizadas adequadamente servirá para preparar-se para o futuro,
podendo prever tendências e realizar uma boa estimativa.
Para Martinho (2007), a busca pela melhoria na qualidade do processo de
desenvolvimento de software através de padrões, normas e ferramentas, está fazendo
com que a empresa que tenha estabelecido e cumprido prazos de entrega, e os mesmos
sejam reduzidos, mantendo a qualidade do software, obtenham vantagens consideráveis
sobre suas concorrentes. Porém estimar o tempo de projeto e desenvolvimento de um
software e a data de entrega do mesmo para o cliente é um processo delicado o qual
envolve muita sensibilidade do Gerente de Projetos de Software e, principalmente, uma
excelente capacidade de estimativa. É um cenário comum dentro das empresas
desenvolvedoras de software.
Estimar prazos, custos e recursos para o projeto talvez seja uma das tarefas mais
nobres e importantes quando do planejamento do projeto, pois é com base nela que
negociamos as condições necessárias para gerenciar um projeto, assim como
encontrarmos os argumentos para revisão de prazos, custos e recursos (FERNANDES;
KUGLER, 1989).
As estimativas e as premissas utilizadas para sua geração devem ser
documentadas para possibilitar o acompanhamento do plano, conforme o progresso do
projeto. O processo de Estabelecer Estimativa abrange, dentre outras, as seguintes
atividades (SEI, 2002 apud HAZAN et al., 2005):
• Estabelecer e manter as estimativas dos atributos dos artefatos e das
tarefas: as estimativas de tamanho constituem o insumo principal para a
maioria dos modelos usados para estimar custo, esforço e cronograma. As
estimativas de tamanho devem ser consistentes com os requisitos do projeto
para determinar-se esforço, custo e cronograma adequados. Assim, sempre
que ocorrerem mudanças além do tolerado (relevantes) nos requisitos, as
estimativas precisam ser revistas e o projeto replanejado. Sugere-se a
utilização da métrica Pontos de Função (PF) (IFPUG, 2004 apud HAZAN et
al., 2005) para as estimativas de tamanho. Os PF fornecem uma métrica de
tamanho do projeto de software, quantificando as suas funcionalidades, sob o
ponto de vista lógico, observando os requisitos do usuário (Garmus, 2001
apud HAZAN et al., 2005);
• Determinar as estimativas de esforço e de custo para os artefatos e
tarefas: as estimativas de esforço e custo devem ser geradas baseando-se em
dados objetivos, ou seja, utilizando métodos e dados históricos. Os projetos
com ausência de dados históricos de esforço de projetos similares disponíveis
possuem um risco maior, necessitando de mais pesquisas para desenvolver
bases racionais de estimativas;
• Incluir a necessidade de uma infra-estrutura de suporte nas estimativas
de esforço e custo: considerar a necessidade de recursos computacionais
críticos no ambiente de desenvolvimento, no ambiente de teste, no ambiente
de produção, ou em qualquer combinação destes. Estimativas de recursos
computacionais incluem o seguinte: identificar os recursos computacionais
críticos; e basear estimativas de recursos computacionais críticos em
requisitos alocados. Exemplos de recursos computacionais incluem: memória,
processador, espaço em disco, periféricos, capacidade da rede e do banco de
dados.
Segundo (CESAR et al., 2008) o desconhecimento por parte do gerente de
projeto, da natureza do produto, também contribui para falhas na estimativa. Defeitos
são corriqueiramente encontrados no sistema demandando mais tempo em uma
determinada funcionalidade. A produtividade por parte dos desenvolvedores varia ao
longo da implementação. Tudo isso pode levar ao cancelamento do contrato ou em
atrasos na entrega do produto. Portanto, o processo de estimativa de software deve ser
contínuo e está sujeito a mudanças.
Um dos principais riscos que atinge o processo de estimativas é a falta de
credibilidade nas estimativas pelas equipes de desenvolvimento (BOEHM, 2000 apud
HAZAN et al., 2005). Isto ocorre quando as estimativas são irreais, ou seja, quando os
projetos são subestimados ou superestimados. A acurácia das estimativas de tamanho
torna-se fundamental para a elaboração de um cronograma e orçamento realistas, pois as
estimativas de tamanho constituem a base para a derivação das estimativas de custo e de
esforço (SEI, 2002 apud HAZAN et al., 2005).
Estimativas podem ser vistas em macro e micro estimativas. Cabendo a primeira
uma previsão do todo. Para esta estimativa conhece-se avaliação de especialistas
(subjetivas, sujeitas a modificações), matemáticas (usando dados históricos),
comparação e analogia (projetos com atributos simulares e os principais atributos
análogos). Já na visão micro da estimativa acrescenta-se um esforço associado com cada
componente ou atividade do processo separadamente. Neste caso, faz-se uma
decomposição em menores partes do projeto (ARAUJO et al., 2005).
As estimativas de software realizadas dentro do PD (Processo de
Desenvolvimento) são necessárias para a construção dos cronogramas, definições de
escopo de versão, previsão de alocação de recursos, de pessoas, e realização de
orçamentos (CISS, 2006 apud PEREIRA et al., 2007). Uma correta e bem realizada
estimativa é fundamental para a qualidade do processo, do produto e para a viabilidade
da execução das atividades (PEREIRA et al., 2007).

4. MPS.BR
O MPS.BR (Melhoria de Processos do Software Brasileiro) é um modelo de qualidade
de processo de software direcionado à realidade do mercado de pequenas e médias
empresas de desenvolvimento de software no Brasil coordenado pela Associação para
Promoção da Excelência do software Brasileiro (SOFTEX).
Este modelo é baseado no CMMI (Capability Maturity Model Integration –
Integração de Modelos de Maturidade da Capacidade para Desenvolvimento), nas
normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro.
Uma das principais vantagens do MPS.BR é seu custo reduzido de certificação
em relação às normas estrangeiras, sendo ideal para micro, pequenas e médias
empresas.
O projeto tem apoio do Ministério da Ciência e Tecnologia, da Financiadora de
Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).
4.1. Motivação para criação do MPS.BR

A partir da crescente demanda de produtos de software onde, a cada dia, aumenta o

nível de exigência por parte dos clientes no que diz respeito à qualidade e
complexidade dos produtos. A partir deste ponto, pode-se observar que as empresas
estão buscando cada vez mais a maturidade nos seus processos de software para
atingir padronizações de qualidade e produtividade internacionais, que são
essenciais para a sobrevivência no mercado de TI.

Porém, o custo de uma certificação para uma empresa pode ser de até US$ 400 mil,
o que se torna inviável para empresas de micro, pequeno e médio porte. Então,
através da uma parceria entre a SOFTEX, Governo Brasileiro e Universidades,
surgiu o projeto MPS.BR (Melhoria de Processo do Software Brasileiro), que é a
solução brasileira compatível com o modelo CMMI, está em conformidade com as
normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira.
4.2. Descrição geral do Modelo
O MPS.BR está dividido em três (3) componentes (Figura 5): Modelo de Referência
(MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada
componente é descrito por meio de guias e/ou de documentos do MPS.BR.

Figura 5. Componentes do MPS.BR (SOFTEX.2006)

O Modelo de Referência MR-MPS contém os requisitos que os processos das

unidades organizacionais devem atender para estar em conformidade com o MR-MPS.
Ele contém as definições dos níveis de maturidade, processos e atributos do processo. O
MR-MPS está em conformidade com os requisitos de modelos de referência de
processo da norma ISO/IEC 15504-2.
O MPS.BR apresenta 7 níveis de maturidade que são:
• A - Em Otimização;
• B - Gerenciado quantitativamente;
 • C - Definido;
• D - Largamente Definido;
• E - Parcialmente Definido;
• F - Gerenciado;
• G - Parcialmente Gerenciado.
Cada nível de maturidade possui suas áreas de processo, onde são analisados os
processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de
requisitos, solução técnica, integração do produto, instalação do produto, liberação do
produto), processos organizacionais (gerência de projeto, adaptação do processo para
gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e
melhoria do processo organizacional, definição do processo organizacional,
desempenho do processo organizacional, gerência quantitativa do projeto, análise e
resolução de causas, inovação e implantação na organização) e os processos de apoio
(garantia de qualidade, gerência de configuração, validação, medição, verificação,
treinamento).
Em seguida vem a Capacidade, onde são obtidos os resultados dos processos
analisados, onde cada nível de maturação possui um número definido de capacidades a
serem vistos.
• AP 1.1 - O processo é executado;
• AP 2.1 - O processo é gerenciado;
• AP 2.2 - Os produtos de trabalho do processo são gerenciados;
• AP 3.1 - O processo é definido;
• AP 3.2 - O processo está implementado;
• AP 4.1 - O processo é medido;
• AP 4.2 - O processo é controlado;
• AP 5.1 - O processo é objeto de inovações;
• AP 5.2 - O processo é otimizado continuamente.
O Guia de Aquisição é um documento complementar destinado a organizações
que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém
requisitos do MR-MPS, mas boas práticas para a aquisição de software e serviços
correlatos.
O Guia de Implementação, composto de 7 partes descreve como implementar
cada um dos níveis do MR-MPS. O Guia de Avaliação contém o processo e o método
de avaliação MA-MPS, os requisitos para os avaliadores líderes, avaliadores adjuntos e
Instituições Avaliadoras (IA). O processo e o método de avaliação MA-MPS estão em
conformidade com a norma ISO/IEC 15504-2.
O Modelo de Negócio MN-MPS descreve regras de negócio para
implementação do MR-MPS pelas Instituições Implementadoras (II), avaliação
seguindo o MA-MPS pelas Instituições Avaliadoras (IA), organização de grupos de
empresas para implementação do MR-MPS e avaliação MA-MPS pelas Instituições
Organizadoras de Grupos de Empresas (IOGE), certificação de consultores de aquisição
e programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR.

5. Análise da Maturidade
5.1. Resultados Esperados do MPS.BR
De acordo com a análise feita nos guias de referência e de implementação do MPS.BR,
procurou-se verificar quais são os processos e resultados esperados que tratam de
estimativas e métricas. A Tabela 1 apresenta toda a base de análise.
Tabela 1. Estrutura dos resultados esperados

Processos Resultados Esperados

Gerência de Projetos – GPR

(Nível G) GPR2, GPR4, GPR5, GPR6.

MED1, MED2, MED3, MED4,

Medição – MED (Nível F)
MED5, MED6, MED7.

Processos Resultados Esperados

Gerência de Projetos – GPR

GPR21, GPR22, GPR23, GPR24,
(Evolução) (Nível B)
GPR25.

Gerência de Projetos – GPR

(Evolução) (Nível E) GPR4, GPR19.

No Apêndice A é apresentado uma tabela com os processos e resultados

esperados, com um detalhamento maior, sendo especificado cada resultado e o
entendimento do mesmo.
5.2. Questionário Avaliativo
O questionário do Apêndice B tem como objetivo obter informações sobre o nível de
maturidade no uso de estimativas e métricas das empresas de TI do estado do Pará para
desenvolver um levantamento estatístico. Sua estrutura esta baseada nas orientações dos
resultados esperados que contemplam estimativas e métricas do MPS.BR, tornando o
questionário também uma forma de medir a qualidade nos processos de medição das
organizações.
Foram criadas 17 perguntas que auxiliam na validação do processo de
maturidade das empresas, tendo como possíveis respostas justificadas ou comentadas.
5.3. Organizações Avaliadas
No período de 3 à 15 de abril de 2009 foi enviado o questionário que consta no
Apêndice B deste trabalho para 20 organizações paraenses, sendo que foi recebido 10
questionários respondidos.
Das organizações participantes:
a) LABES – UFPA: Laboratório de Engenharia de Software da UFPA
(Universidade Federal do Pará) têm como objetivo incentivar e aprofundar a
pesquisa na área de Engenharia de Software na UFPA, mais especificamente em
gerência de processos de software.
b) CTIC – UFPA: O Centro de Tecnologia da Informação e Comunicação
da UFPA (CTIC), responsável por desenvolver e administrar atividades
didáticas, científicas e administrativas desempenhadas pela Universidade; fazer
o processamento dos dados estatísticos através da computação e realizar a
computação dos dados de que necessita a Universidade no campo de pesquisa,
ensino e administração.
c) CESUPA: Centro Universitário do Pará é uma unidade de ensino/serviço
responsável por associar técnicas e tecnologias na prestação de serviços e/ou
pesquisa na área de computação. Atua fortemente em projeto e desenvolvimento
de software.
d) Cobra Tecnologia: Fundada em 1974, a COBRA foi a primeira empresa
a desenvolver, produzir e comercializar tecnologia genuinamente nacional, no
segmento de informática. Nos anos 90, já fazendo parte do conglomerado Banco
do Brasil, torna-se integradora de soluções: especifica, comercializa, implanta,
treina e presta assistência técnica em todo o País para equipamentos das maiores
empresas desenvolvedoras mundiais.
e) FÓTON: É uma empresa de automação, consultoria, serviços e
treinamentos com foco no mercado financeiro de pequeno e médio porte.
f) DETRAN: Departamento Estadual de Trânsito do Pará, também
chamado DETRAN-PA, é um órgão público estadual, vinculado ao Governo do
Estado do Pará, responsável pelo gerenciamento do trânsito de veículos em todo
o estado do Pará.
g) SERPRO: Serviço Federal de Processamento de Dados - é uma empresa
pública, vinculada ao Ministério da Fazenda. A Empresa, cujo negócio é a
prestação de serviços em Tecnologia da Informação e Comunicações para o
setor público, é considerada uma das maiores Organizações do setor, na América
Latina.
h) PDCASE: Fornece soluções para o mercado financeiro, serviço de
fábrica de software, outsourcing, desenvolvimento de projetos sob medida e
capacitação de profissionais da área de TI (Tecnologia da Informação).
i) AmazonCop: Amazon Corporation é uma empresa genuinamente
paraense que está a mais de 10 anos no mercado do norte do país, possui mais de
 100 colaboradores, fornecendo soluções em TI voltadas para empresas de médio
porte.
j) Versatilit: Empresa de desenvolvimento e prestação de serviços de
Tecnologia da Informação.
k) Albras: A Alumínio Brasileiro SA é uma companhia brasileira, de
capital fechado, que foi instalado em 1985, no município de Barcarena, a 40
quilômetros de Belém, em linha reta, capital do Estado do Pará, na Amazônia
(ao Norte do Brasil). A empresa é resultado de uma associação da Companhia
Vale do Rio Doce (51%) e da Nippon Amazon Aluminium Co. Ltd. (49%),
consórcio de empresas japonesas, entre trading companies, consumidoras e
produtoras de alumínio e o Japan Bank for International Cooperation,
organismo do governo japonês, sendo este o maior participante do consórcio.
l) Alunorte: Alumina do Norte do Brasil S.A, é uma empresa formada a
partir de acordo realizado pelos governos do Brasil (representado pelo diplomata
Gilbert Ducry) e do Japão em 1978 (com a participação da Companhia Vale do
Rio Doce) para a criação da empresa. Atualmente é a maior refinaria de alumina
do mundo.
m) FAPESPA: Fundação de Amparo à Pesquisa do Estado do Pará fomenta
a pesquisa e fortalece o sistema regional de Ciência, Tecnologia e Inovação,
CT&I.
n) Ministério Público do Pará: É o órgão criado para defender os direitos da
sociedade, garantindo a ordem jurídica e o regime democrático.
o) Tribunal Regional Eleitoral do Pará: Garantir a efetividade, a celeridade
e a transparência dos processos eleitorais.
p) Tribunal de Justiça do Estado o Pará: Responsável por processos
judiciais do estado do Pará, possui um núcleo de desenvolvimento de sistemas
internos.
q) Museu Paraense Emílio Goeldi: é uma instituição de pesquisa vinculada
ao Ministério da Ciência e Tecnologia do Brasil.
r) CINBESA: Companhia de Informática de Belém desenvolve sistemas de
informação coorporativos e específicos para a Prefeitura Municipal de Belém.
s) SEDUC: Secretaria de Estado de Educação, órgão de administração
direta do Estado do Pará, têm por finalidade estudar, planejar e executar o
controle e a avaliação dos assuntos relativos à política educacional do Governo
do Estado.

5.4. Apresentação dos Resultados

De acordo com os resultados da pesquisa e levantamento dos dados, procurou-se
representar as informações estatísticas através do gráfico apresentado abaixo, onde
encontra-se organizado as questões e o número de empresas que adotam ou não algum
tipo de métrica e estimativa:

Figura 6. Análise Geral dos Resultados por Perguntas

Abaixo consta a análise detalhada dos resultados obtidos em cada pergunta

sequenciado de acordo com o questionário:
a) Quando se foi feita a pergunta do uso de WBS (Work Breakdown Structure),
também conhecida no Brasil como EAP (Estrutura Analítica de Trabalho), tivemos 70%
das empresas ou organizações afirmando que utilizam nas fazes iniciais de projeto para
se ter uma visão macro do escopo do projeto, possibilitando saber quais os objetivos a
serem alcançados.
b) Quando se foi feita a pergunta se a organização possui uma base de dados ou
histórico de projetos para servir de apoio a uma análise de esforço e custo de tarefas,
tivemos 80% das empresas ou organizações dizendo que possuem uma base histórica
que serve para analisar o fluxo de atividades passadas, bem como analisar processos e
pessoas envolvidas nos projetos e também reaproveitar códigos ou módulos para
projetos futuros.
c) Com respeito ao uso de um cronograma incluindo marcos ou pontos de
controle, 90% das organizações responderam que baseado no escopo do projeto
definido na WBS e posteriormente repassado ao cronograma, no final de cada iteração
ocorre uma análise de riscos e seus impactos, bem como aprovação de requisitos,
homologação, etc. Em geral os pontos de controle ou milestones são utilizados para
monitorar o andamento do projeto para possíveis tomadas de decisão.
d) Em relação à organização possuir uma lista de possíveis riscos para os projetos,
bem como seus devidos impactos e tratamentos, 70% responderam que para cada
projeto possuem uma lista de riscos com seus respectivos impactos, sendo que essa lista
consta no plano de mitigação e contingência.
e) Em relação se a organização possui um método de medida e as medições dos
projetos são baseadas nos objetivos da organização, 70% responderam que utilizam
alguma metodologia como: GQM (Goal Question Metric), COCOMO (Costructive
Cost Model), etc, para realizar as medições dos projetos sempre indo a favor dos
objetivos estratégicos da organização.
f) Em relação à organização possuir uma documentação detalhada do conjunto de
medidas e se constantemente são revisadas de acordo com os objetivos da organização,
60% responderam que possuem um conjunto de métricas sendo essas revisadas
procurando seguir os objetivos da organização no tange tomadas de decisões futuras.
g) Em relação à organização possuir uma documentação especifica para os
procedimentos de como serão coletados e armazenados os dados dos projetos, 70%
responderam que possuem um plano de medição que detalha como deve ser procedido a
coleta e o armazenamento dos dados dos projetos.
h) Na questão que trata se de acordo com cada medida do projeto a organização
possui uma documentação com as respectivas atividades e seus responsáveis, bem como
um meio de comunicação entre eles, 50% das organizações responderam que possuem
um plano de medição e que as atividades são delegadas pelo gerente de projetos bem
como o meio de comunicação que se deverá seguir.
i) Em relação à coleta e análise dos dados dos projetos serem realizados de acordo
com o cronograma, 70% das organizações responderam que o processo de análise e
coleta de dados são realizados como esta definido no cronograma do projeto, essas
atividades são repassadas para os coordenadores dos projetos que posteriormente
repassa para um responsável da equipe.
j) Em relação às informações produzidas serem usadas para apoiar decisões do
projeto indo de acordo com os objetivos da organização, 70% das organizações
responderam que no final de cada iteração os resultados das medições são apresentados
a toda equipe, servindo como tomada de decisões para o projeto, em se tratando de
atraso da entrega, custo, renegociação com o cliente, entre outros.
Pode-se concluir que a grande maioria das organizações utiliza algum
tipo de métrica e estimativa para o desenvolvimento de projetos de software, o que não
justifica possuir um bom nível de maturidade, pois muitas organizações conhecem
técnicas e metodologias, mas não utilizam de maneira correta ou contínua, muitas por
não terem uma devida orientação das melhorias que poderiam ser feitas se o uso fosse
feito corretamente, dando um maior nível qualidade a seus produtos.

6. Recomendações para Aplicação de Estimativas e Métricas

6.1. Ferramentas
Para o auxílio na gestão de projetos de software existe uma grande necessidade do uso
de ferramentas. Este trabalho buscou elaborar uma lista com algumas dessas
ferramentas e suas características:
a) Ferramenta: MSProject
Tipo: Proprietária Desenvolvedor: Microsoft
• Baseia-se no modelo Diagrama de Precedências. Portanto, as atividades do
projeto são criadas na forma de blocos, não na forma de setas;
• Utiliza o Gráfico de Gantt ou de barras como ferramenta básica a ser utilizada
durante a entrada de dados;
• Aceita relações de precedências tipo Fim-Início, Início-Início, Fim-Fim e
Início-Fim;
• Permite tarefas recorrentes: Inclusão de tarefas que ocorrem de forma
repetitiva. Por exemplo, em um projeto pode haver reuniões todas as segundas-
feiras;
• Permite estabelecer níveis hierárquicos para as tarefas, isto é, admite a
existência de tarefas de resumo;
• Permite uso de subprojetos;
• Permite uso de "datas programadas" para as atividades;
• Permite uso do modelo probabilístico.
• Os custos são ligados diretamente às atividades na forma de custos fixos ou de
custos dos recursos;
• Visualmente, se apresenta como um conjunto de planilhas e de gráficos.
Disponível em: http://office.microsoft.com/pt-br/project/HA101656381046.aspx
b) Ferramenta: MrProject
Tipo: Livre Desenvolvedor: CodeFactory
Área de trabalho com suporte a: Gráfico de Gantt;
Visualização de Tarefas;
Visualização de Recursos;
Integrante da suíte de aplicativos Gnome Office.
Disponível em: http://ftp.gnome.org/pub/GNOME/sources/mrproject/0.10/

c) Ferramenta: Open Workbench

Tipo: Opensource Desenvolvedor: Niku Corporation
Para o plano de projeto: definir projetos e criar trabalhos relacionados com as
atividades, fases, tarefas;
Criar dependências como: quando iniciar e quando terminar;
Criar subprojetos e vinculá-los ao projeto principal;
Criar e gerir dependências entre projetos;
Associar orientações referente às tarefas;
Criar, editar e apagar agendas.
Para a programação de projeto: agendar tarefas, manual ou automaticamente
usando o Auto Schedule;
Esquema geral ou individualizado dos calendários;
Para gestão de recursos: definir recursos como: humanos, equipamentos,
materiais ou financeiro;
Atribuir recursos a tarefas;
Análise do projeto;
Controlar o status do projeto, a porcentagem realizada e o que ainda falta
realizar;
Definir, comparar e redefinir as configurações básicas do projeto;
Personalizar o projeto incluindo: coluna, layouts, filtros, classificar e basear em
regras de formatação.
Disponível em: http://www.myclarity.com/

d) Ferramenta: GanttProject
Tipo: Livre Desenvolvedor:Projeto GanttProject
Com GanttProject você pode quebrar o seu projeto em uma árvore de tarefas e
atribuir os recursos humanos e financeiros que têm de ser alocados em cada
tarefa.
Você também pode criar dependências entre tarefas, como "essa tarefa não pode
começar até que esta tenha acabado".
GanttProject trabalha seu projeto usando duas cartas: Gantt chart de tarefas e de
recursos gráficos.
Você pode imprimir os seus gráficos, gerar relatórios em PDF e HTML, trocar
dados com o Microsoft(R) Project(TM) e aplicações de planilha eletrônica.
Disponível em: http://ganttproject.biz/

e) Ferramenta: Jmetric
Tipo: GPL Desenvolvedor: Swinburne
University of Technology
JMetric é um analisador de métricas. Este analisa arquivos de origem Java e
fornece métricas de qualidade e tamanho.
Disponível em:
 http://www.it.swin.edu.au/projects/jmetric/products/jmetric/default.htm

f) Ferramenta: Scope
Tipo: Proprietária Desenvolvedor: Total Metrics
Permite um escalonamento de projeto usando IFPUG 4.2 análise por ponto de
função.
Disponível em: http://www.totalmetrics.com/function-point-software/scope-
project-sizing-software

g) Cost Xpert
Tipo: Proprietária Desenvolvedor: Cost Xpert
Implementa vários métodos de estimativa. A ferramenta utiliza dados coletados
de 7.000 projetos, comerciais e militares, para assegurar maior precisão nas
estimativas. Para estimar o tamanho do projeto, a ferramenta implementa uma
variedade de métodos. Pode-se utilizar linhas de código, pontos de função,
pontos de característica, métricas GUI, métricas de objeto e as abordagens
heurísticas top down e bottom up.
Além do ajuste dos direcionadores de custo do COCOMO II, a
ferramenta possibilita um ajuste ainda mais refinado da estimativa, baseado em
um conjunto de 8 fatores. Além dos relatórios de divisão de esforço por fases e
atividades, a ferramenta gera gráficos da estrutura de divisão funcional do
trabalho e gráficos de distribuição do esforço.
Disponível em: http://www.costxpert.com/en/index.html

h) Ferramenta: Softstar
Tipo: Proprietária Desenvolvedor: Soft Star
Para cálculo de estimativa de esforço, custo, prazo e distribuição de equipe. A
ferramenta implementa os modelos COCOMO original, Ada COCOMO e
COCOMO II. O tamanho do sistema pode ser expresso em pontos de função ou
em linhas de código. Após a inserção dos dados de pontos de função, deve-se
informar a linguagem escolhida para implementação do sistema. A ferramenta
Costar gera uma série de relatórios para estudo das estimativas calculadas.
Apresenta o relatório em detalhes da distribuição do esforço em fases e sua
duração. As ferramentas que implementam o modelo COCOMO levam em
consideração as atividades de Gerenciamento de Configuração e Garantia de
Qualidade de Software (CM/QA) na distribuição de esforço e cálculo de custo
do projeto.
Disponível em: http://www.softstarsystems.com/
i) Ferramenta: USC COCOMO II
Tipo: Gratuita Desenvolvedor: University of
Southern Califórnia
É uma implementação do modelo Post Architecture do COCOMO II. Ela
calcula esforço, prazo e distribuição do esforço e encontra-se disponível para
plataformas Sun Sparc Unix, Microsoft Windows e plataformas que habilitam a
linguagem Java. Os parâmetros dos direcionadores de custo podem ser
calibrados na ferramenta. Vários tipos de relatórios podem ser gerados pela
ferramenta.
Disponível em:
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
j) Ferramenta: WinFPA
Tipo: Proprietária Desenvolvedor: CSP
CONSULTORIA & SISTEMAS
Software multi-usuário especializado em Dimensionamento e Planejamento de
Projetos de Desenvolvimento e Manutenção de Sistemas
Ideal para quem precisa criar:
-Histograma de Mão-de-obra;
-WBS;
-Cronogramas (alto-nível e detalhado);
-Análise de Riscos;
-Modelagem dos processos/dados;
-Simulações: Equipe, Duração, Prazo, Defeitos, Manutenção;
-Composição do Preço de Venda;
Principais funcionalidades:
- Contagem dos Pontos de Função;
- Geração do Histograma de Mão-de-obra;
- Simulações: Equipe e Duração;
- Geração da EAP(WBS): Estrutura Analítica do Projeto;
- Geração do Cronograma do Projeto: Macro e Detalhado;
- Comparativos entre projetos;
- Visão 3D do projeto;
- Exportações: XML, MS-Excel, ASCII, MDL, MPP 2002/03 (desktop);
- Importações: XML, ASCII, MDL, MPP 2002/03 (desktop);
- Análise de Riscos (disponível na versão CORPORATE);
- Composição do Preço de Venda;
- Determinação dos feriados nacionais;
- Distribuição do Esforço do Projeto;
- Estatística de Taxas de Entrega e Custos;
- Classificação do Tamanho do Projeto;
- Estimativa de Casos de Testes;
- Estimativa de Defeitos;
- Fluxo de Caixa mensal e acumulado;
- Assistente de Inclusão de funções;
 - Revisor automático de parâmetros;
- WMM – Macro Modeler (modelagem em alto-nível);
- Cálculo da Taxa de Produtividade.
Disponível em: http://www.winfpa.com.br/index.htm

O primeiro obstáculo a ser superado para que tais ferramentas sejam utilizadas é
a efetiva implementação das métricas nas empresas desenvolvedoras de software para
poderem gerar os dados necessários e essenciais. O segundo é a obtenção de uma
ferramenta que auxilie o Gerente de Projetos de Software na compilação e analise dos
dados gerados, que não seriam poucos (MARTINHO, 2007).
6.2. Procedimentos e Técnicas
As diversas técnicas de estimativa de esforço de desenvolvimento do produto de
software descritas na literatura especializada obtêm em geral uma estimativa do valor da
métrica de software relacionada à quantidade de trabalho ou esforço a ser realizado.
Nesse sentido, algumas destas técnicas utilizam como entrada o valor de uma métrica de
software relacionada ao tamanho. É recomendável a utilização de mais de uma técnica
de estimativa a fim de comparar-se o resultado das diferentes técnicas e possibilitando
chegar a uma estimativa melhor (MACEDO, 2003).
De acordo com Martinho (2007), Existem diversas metodologias de métricas
como: Métricas orientadas a seres humanos, Métricas orientadas a função, Métricas
orientadas ao tamanho, Métricas de produtividade, Métricas de qualidade, Métricas
técnicas, etc.
A seguir é apresentada uma descrição de algumas metodologias:
a) GQM (Goal Question Metric).
Segundo (SOUSA; OLIVEIRA e ANQUETIL, 2003), o GQM baseia-se na
suposição de que para se medir de maneira eficaz, alguns objetivos devem ser
estabelecidos para que estes sirvam de rota para o estabelecimento de questões
que orientarão a definição de métricas em um contexto particular.
O objetivo do método GQM é caracterizar e fornecer um melhor entendimento
dos processos, produtos, recursos e ambientes e, assim, estabelecer bases para
comparação com trabalhos futuros (BRASILI, 1994 apud SOUSA; OLIVEIRA;
ANQUETIL, 2003).
b) PSM (Practical Software Measurement).
O modelo PSM surgir para auxiliar a gerência na mensuração de projetos de
software em relação a custos, prazos e requisitos, dentre eles: horas trabalhadas
no projeto, funcionalidades oferecida pelo projeto e ainda permitindo obter o
esforço do projeto e seu tamanho funcional através da contagem de pontos de
função. O PSM é uma abordagem para melhorar a maturidade dos processos de
desenvolvimento de software na sua qualidade e consequentemente dos seus
atributos (COPPOLA, 2008).
O PSM é um modelo para a estruturação da
mensuração em um projeto de software. De um ponto de vista prático, o PSM
procura resolver dois problemas: 1- como especificar formalmente as medidas a
serem usadas e 2- como conduzir o processo de medição. O PSM alcança esses
objetivos através de dois modelos: de informação e processo (AGUIAR, 2002).

Figura 7. Modelo de Processo do PSM

Uma forma de melhor utilizar o PSM é utilizando a o PSM INSIGHT que é uma
ferramenta desenvolvida pelo departamento de defesa norte americano, junto
com o ASMO (Army Software Metrics Office), para a implantação do modelo
PSM. Atualmente na sua versão 4.2.2, a ferramenta auxilia profissionais para a
aplicação das técnicas PSM e para o acompanhamento de métricas (US ARMY,
2003 apud COPPOLA, 2008).
c)Estimativa por analogia
Segundo (TAVARES, 2005), pesquisas comprovaram que o julgamento
especialista é o método de estimativas mais comumente utilizado. Mas
comprovaram também que, em geral, o especialista utiliza a própria memória
para relembrar as estimativas de projetos anteriores necessárias para uma nova
estimativa. Isso ocorre porque, ou ele tem dificuldade de acesso aos documentos
dos projetos anteriores, ou não entende como tais projetos podem ajudá-lo.
Sendo assim, os riscos de erros desse método são menores quando uma equipe
de especialistas é adotada. Ou seja, um método mais estruturado de julgamento
especialista é a abordagem Delphi Banda-larga, que se utiliza de, no mínimo,
quatro especialistas por projeto.
 d)Delphi
Requisitos detalhados são passados para especialistas para que cada um faça
uma avaliação privada e produza uma estimativa. Os resultados são coletados e
um resumo anônimo é produzido. Este resumo é então repassado para os
especialistas que refazem suas estimativas. Um coordenador decide quando um
nível suficiente de consenso foi atingido e a interação deve parar. Uma
explicação mais detalhada pode ser encontrada em (PMI, 1996 apud MACEDO,
2003).
A seguir é apresentada uma descrição de algumas técnicas para métricas:
a) LOC – Lines of Code
Segundo (PARO, 2005), a técnica de mensuração por linhas de código (LOC –
Lines of Code) é uma das medidas mais antigas para determinação do tamanho,
esforço e, conseqüentemente, produtividade no desenvolvimento de software.
Ela consiste basicamente na contagem da quantidade do número de linhas de
código de um programa de software. É uma técnica de fácil automação,
eliminando esforços manuais. Porém, é uma técnica que conta com muitas
desvantagens. Podemos citar, entre elas, o fato de que é inexato ter que medir a
produtividade de um projeto de desenvolvimento com a saída de somente uma
das fases (fase de codificação); a experiência do desenvolvedor, pois o número
de linhas de código pode variar de pessoa a pessoa; a diferença entre linguagens
(o número de linhas de código de uma aplicação desenvolvida em Cobol
certamente é diferente da quantidade de linhas de código da mesma aplicação
desenvolvida em linguagem C).
A seguir é apresentado alguns tipos de métricas:
a)Métricas de Halstead
Estima o esforço empenhado na programação. Ela baseia-se em medidas
objetivas de código, e está relacionada com a teoria da informação, possuindo as
seguintes qualidades mensuráveis, definidas para um dado programa codificado
em qualquer linguagem de programação.
b)Métricas de McCabe
Segundo (SILVA; GARCIA; RINALDI e PONTES, 2007) ainda nos meados de
1970, foi desenvolvida a métrica da “complexidade ciclomática” de McCabe,
baseada no número de condições de fluxo em um programa (em um conceito
estrito de complexidade).
A métrica de McCabe (MCCABE, 1976 apud TIMÓTEO, 2008) foi selecionada
por ter uma solida validação teórica baseada na teoria dos grafos, esta métrica
foi definida de modo independente de tecnologias, ou seja, ela pode ser aplicada
para qualquer linguagem de desenvolvimento de software.
c) Métrica de Pontos de Casos de Uso (PCU)
 O Ponto de Casos de Uso (PCU) foi definido por Gustav Karner (KARN, 93
apud ANDRADE e OLIVEIRA) para estimar projetos OO (Orientado a
Objetos). O processo de contagem dessa métrica consiste de seis passos
conforme mostra o a Figura 8.

Figura 8. Passos do processo de contagem de PCU

d) Análise por Pontos de Função (APF)

A idéia fundamental da análise por ponto de função consiste em medir o
tamanho de qualquer produto de software baseado em termos lógicos, orientados
ao usuário. A análise por ponto de função não se preocupa diretamente com a
plataforma tecnológica, ferramentas de desenvolvimento e linhas de código. Ela
simplesmente mede a funcionalidade entregue ao usuário final. Nesse sentido, a
métrica de pontos de função de acordo com o IFPUG (International Function
Point Users Group) avalia o produto de software e mede o seu tamanho
baseando-se em características funcionais bem definidas deste sistema
(MACEDO, 2003).
Para obtenção de qualidade de software (TABORDA e BIERHALS, 2003)
descrevem que, as medidas utilizadas para quantificar as características que atestam a
qualidade de um software podem ser obtidas através da avaliação de aspectos como:
polimorfismo, encapsulamento, coesão, acoplamento e complexidade.
Métrica de Polimorfismo: polimorfismo refere-se a métodos com a mesma
assinatura em classes herdadas. São avaliados aspectos como fatores de polimorfismo,
que em um índice que vai de 0 a 1, verifica a existência de polimorfismo de métodos na
especificação. O polimorfismo puro ou sobrecarga em classes isoladas mede o número
de métodos com assinaturas diferentes, mas com o mesmo nome, já o polimorfismo
estático nos ancestrais identifica se foi implementado algum método com mesmo nome,
porém com argumentos ou tipos diferentes na classe de suas ancestrais. São levados em
conta também fatores como polimorfismo estático nos descendentes e em relação de
herança, polimorfismo dinâmico nos ancestrais e nos descendentes e polimorfismo em
relação à herança.
Métrica de Encapsulamento: aqui encontramos o fator de atributos ocultos, que
indica, em um índice que vai de 0 (não uso) a 1(máximo uso), o quanto os atributos são
restritos somente a classe, não sendo possível o acesso a outras classes, pois o acesso é
permitido pelos métodos públicos e o fator de métodos ocultos que avalia a quantidade
de métodos acessíveis por outras classes.
 Métrica de Coesão: avalia se as características realmente são pertinentes a
classe. E auxilia na abstração do seu tipo. Trata basicamente da falta de coesão nos
métodos que é descrito por Pressman como o número de métodos que tem acesso a um
ou mais dos mesmos atributos.
Métrica de Acoplamento: característica que se refere à interdependência entre as
classes. A busca de uma baixa dependência entre módulos facilita a reutilização dos
módulos em outras aplicações e ameniza a implementação de mudanças tanto no
desenvolvimento quanto na manutenção. O acoplamento entre as classes ocorre pela
interação entre elas.
Métrica de Complexidade: avalia aspectos que se referem ao grau de
entendimento do software como um todo. Isso é um fator muito importante na hora de
fazer uma manutenção no caso da ausência ou má documentação. São avaliados fatores
como tamanho e número de argumentos nos métodos, número de métodos nas classes,
profundidade da arvore de herança, fator de herança de métodos e atributos e referência
a subclasses.

7. Conclusão
O Processo de Desenvolvimento de Software deve ser continuamente medido durante
seu desenvolvimento. Para isso é necessário criar uma “cultura” de medição e métrica
(desenvolvimento com bases técnicas), pois essa tarefa se estende a todos os
profissionais envolvidos no projeto.
Segundo Martinho (2007), o mais importante a ser ressaltado é que as métricas
devem ser muito bem feitas pelos gerentes de projetos e que devem ser mostradas de
uma forma clara e que todos possam entender os resultados gerados. Feito isso, o
resultado que se tem é um conjunto de dados que darão a idéia do processo e um
entendimento do projeto. Permitirá aos Gerentes de Projetos de Software aperfeiçoar e
melhorar o processo de desenvolvimento do produto e avaliar a qualidade do produto
que está sendo produzido. Mas o mais importante é que sem existir uma ferramenta que
auxilie os Gerentes de Projetos de Software na analise dos dados coletados através das
métricas podemos cair novamente em um dilema: existem métricas adequadas, mas os
dados coletados são tantos e a análise dos mesmos, complicada e demorada que os
Gerentes de Projetos de Software não as utilizam.
A pesquisa apresentada neste trabalho procurou mostrar o nível de maturidade
das organizações paraenses no uso de estimativas e métricas, o resultado foi satisfatório,
pois a grande maioria utiliza técnicas e ferramentas ao longo do desenvolvimento de
projetos, mas há uma grande necessidade de como utilizar de maneira mais correta
garantindo boas práticas e sempre procurando crescer no nível de qualidade.
Este trabalho fica como referência para esclarecer dúvidas no que envolve
processos, técnicas e ferramentas para medir e estimar o desenvolvimento de projetos de
software.
Para pesquisas futuras fica a necessidade de envolver um maior número de
organizações paraenses, obtendo com isso um verdadeiro quadro analítico da
maturidade dessas organizações, possibilitando fornecer uma maior visibilidade do
quanto é importante e onde precisa ser melhorado. Cabe também ressaltar que o
resultado dessa pesquisa poderá servir para elaboração de um estudo de caso para cada
organização paraense visando apresentar onde a empresa ou organização pode melhorar
no uso das melhores práticas de técnicas e metodologias. Quebrando esse paradigma no
que envolve o uso de métricas e estimativas de software.
Referências
AMARAL, F. (2008) “Por que projetos de software falham?” Disponível em:
<http://www.fernandoamaral.com.br/Default.aspx?Artigo=52>. Acesso em: 15 abr.
2009.
AGUIAR, M. (2002) “Pratical Software Measurement: O CMM da Mensuração?”
Disponível em:
<http://www.metricas.com.br/Downloads/PSM_CMM_Mensuracao_Software.pdf>.
Acesso em: 16 abr. 2009.
ANDRADE, E. L. P; OLIVEIRA, K. M. (2004) “Aplicação de Pontos de Função e
pontos de Casos de uso de Forma Combinada no Processo de Gestão de Estimativas
de Tamanho de Projetos de Software Orientado a Objetos”. Disponível em:
<http://www.ip.pbh.gov.br/ANO7_N1_PDF/IP7N1_andrade.pdf>. Acesso em:17
abr. 2009.
ARAUJO, D. G; ANNA, N. S; KIENBAUM, G. S. (2005) “Proposta de um Ambiente
de Apoio a Estimativas em Projetos de Software Através Simulação de Simulação”.
Anais do V WORKCAP. São José dos Campos-SP.
CONTADOR, D. C. T. (2008) “A importância das medições no controle de um projeto
de software”. IETEC. Disponível em:
<http://www.ietec.com.br/site/techoje/artigos_autor/artigos/63>. Acesso em: 16 mar.
2009.
CASTOR, E. M. (2003) Gerenciando Projetos de Software com RUP e PMBOK.
Trabalho de Conclusão de Curso (Especialização em Tecnologia da Informação) -
UFPE, orientado pelo Prof. Hermano Perreli, Recife-PE.
COPPOLA, E. J. (2008) Uma contribuição à melhoria da maturidade dos processos de
desenvolvimento de software: um estudo de caso da utilização do Practical Software
And Systems Measurement - PSM INSIGHT. Dissertação de Conclusão de Mestrado
em Inovação Tecnológica e Desenvolvimento Sustentável do Centro Estadual de
Educação Tecnológica Paula Souza, orientada pelo Prof. Dr. Napoleão Verardi
Galegale, São Paulo-SP.
CESAR, A; RIBEIRO, F; LUIZ, L; ARRUDA, T; BRAYNER, T. 2008 Métricas de
Software. Monografia de Qualidade de Software. Centro de Informática –
Universidade Federal de Pernambuco - UFPE. Disponível em:
<www.cin.ufpe.br/~tmb/%5BQualidade%5D_Monografia_de_Qualidade.doc>.
Acesso em: 20 mai. 2009.
FERNANDES, A. A. Gerência de software através de métricas: Garantindo a qualidade
do projeto, processo e produto. Compreendendo a dimensão do software e de sua
gestão. São Paulo: Atlas, 1995. Cap. 1, p. 18.
FERNANDES, A. A; KUGLER, J. L. C. Gerência de projetos de sistemas: uma
abordagem prática. Rio de Janeiro: LTC - Livros Técnicos e Científicos Editora
Ltda, 1989. p. 12.
HAZAN, C; STAA, A. VON. (2005) Análise e Melhoria de um Processo de Estimativas
de Tamanho de Projetos de Software. Monografia do curso de Ciência da
Computação da Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro-
RJ.
MARTINHO, F. (2007) Métricas de Software como Ferramenta de Apoio ao
Gerenciamento de Projetos de Software. Disponível em:
<http://www.testexpert.com.br/?q=node/403>. Acesso em: 03 abr. 2009.
MACEDO, M. V. L. R. (2003) Uma Proposta de Aplicação da Métrica de Pontos de
Função em Aplicações de Dispositivos Portáteis. Trabalho Final de Mestrado
Instituto de Computação Universidade Estadual de Campinas, orientado pelo Prof.
Dr. Paulo Lício de Geus, Campinas-SP.
MELO, M. A. V. (2002) Requisitos de Ferramentas de Apoio aos Processos de Medição
de Software. Departamento de Ciência da Computação - Universidade Federal de
Minas Gerais, Belo Horizonte-MG.
NETO, P. A. S. Planejamento e Gerência de Projetos. (2006) Trabalho de Apresentação
Métricas de Software do Curso (Gerência Educacional de Tecnologia da Informação)
– Centro Federal de Educação e Tecnologia do Rio Grande do Norte, Natal-RG.
OLIVEIRA, S. R. B. (2006) Processos de Software: Princípios, Ambientes e
Mecanismos de Execução. Exame de Qualificação do Programa de Doutorado do
CIn/UFPE, orientado pelo Prof. Dr. Alexandre Marcos Lins de Vasconcelos, Recife-
PE.
OLIVEIRA, J. P. F. (2005) Gerenciamento de Projetos de Software. Monografia de
Conclusão do Curso de Ciência da Computação - Centro de Ciências Exatas e da
Natureza da Universidade Federal da Paraíba, orientado pelo Prof. Dr. Glêdson Elias,
João Pessoa-PB.
OVIGLE, O; COSTA, A. G; KIMIE, P; ITO, M. (2007) Utilizando o Rational Unifield
Process para atender a Lei Sarbanes-Oxley. In: Primeiro Workshop de
Desenvolvimento Rápido de Aplicações, Porto de Galinhas, 2007. Disponível em:
<http://reuse.cos.ufrj.br/wdra2007/index.php?
option=com_content&task=view&id=5&Itemid=6>. Acesso em: 13 abr. 2009.
PMI - PROJECT MANAGEMENT INSTITUTE, Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos. Guia PMBOK® . 3.ed, 2004.
PRESSMAN, Roger S. Engenharia de software. Conceitos de gestão de projetos. 6.ed.
São Paulo: McGraw-Hill, 2006. Cap. 21, p. 482.
PRADO, Darcy, Gerenciando Projetos nas Organizações, Belo Horizonte MG, EDG,
2000.
PEREIRA, R; TAIT, T. F. C; CASTRO, C. Y. H; TRINDADE, D. F. G; SILVA, J. V.
(2007) Estimavas de Software: O Estudo de uma Aplicação Prática Utilizando a
Técnica de Use Case Points. Departamento de Informática - Universidade Estadual
de Maringá. Maringá-PR. FFALM - Faculdades Luiz Meneghel. Bandeirantes-PR.
PARO, C. J. (2005) Medidas de tamanho de desenvolvimento e de melhorias de
software. Disponível em: <http://www.bfpug.com.br/>. Acesso em: 16 abr. 2009.
RUP. Rational Unified Process. Gerenciamento de Projeto: Fluxo de Trabalho. 2001.
Disponível em:
<http://www.wthreex.com/rup/process/workflow/manageme/wfd_pm.htm>. Acesso
em: 18 mar. 2009.
SILVA, D; GARCIA, M. N; RINALDI, H. M. R; PONTES, C. C. C. Análise das
Possíveis Diferenças entre Contratantes e Contratados em Terceirização de Serviços
de Software Segundo a Métrica de Análise de Ponto de Função. BASE - Revista de
Administração e Contabilidade da Unisinos, São Leopoldo-RS, p. 49, abr. 2007.
SOUSA, K. D; OLIVEIRA, K. M; ANQUETIL, N. Aplicação de GQM para avaliação
de processo de manutenção de software. In: Jornadas Iberoamericanas de Ingeniería
del Software e Ingeniería del Conocimiento, 2003, Valdivia. 3a Jornadas
Iberoamericanas de Ingeniería del Software e Ingeniería del Conocimiento, JIISIC,
2003.
STANDISH (1994) Chaos Report. Software Development Report, The Standish Group,
West Yarmouth, MA, Disponível em: <http://www.standishgroup.com>.
STANDISH (2004) Chaos Report. Software Development Report, The Standish Group,
West Yarmouth, MA, Disponível em: <http://www.standishgroup.com>.
SOMMERVILLER, Ian. Engenharia de software. Gerenciamento de projetos. 8.ed. São
Paulo: Person Addison-Wesley, 2007. Cap. 5, p. 61.
SOMMERVILLE, Ian. Engenharia de software. Tradução Maurício de Andrade. 6.ed.
São Paulo: Addison-Wesley, 2003.
TAVARES, C. F. O. K. (2005) Projetos de Estimativa de Software. Departamento de
Informática e Matemática Aplicada - Universidade Federal do Rio Grande do Norte,
Natal-RN.
TIMÓTEO, A. L. (2008) Plano de Dissertação de Mestrado em Ciência da Computação.
Universidade Federal de Pernambuco - Centro de Informática, Recife-PE.
TABORDA, L. B; BIERHALS, L. (2003) Métricas de Qualidade de Produto. Trabalho
apresentado na Universidade Federal de Santa Catarina - Departamento de
Informática e Estatística, orientado pelo Prof. Ricardo Pereira e Silva, Florianópolis-
SC.
Apêndice A – Processos e Resultados Esperados

Guia de Referência MPS-BR e Guia de Implementação

PROCESSO RESULTADO RESUMO (ENTENDIMENTO)
GPR2 - As tarefas e os Após ser definido o escopo do
produtos de trabalho do projeto, deve haver uma
projeto são dimensionados decomposição em partes menores
utilizando métodos utilizando-se de uma EAP ou
apropriados. WBS. Essa decomposição favorece
Gerência de
a visualização do tamanho do
Projetos –
projeto, não só para a equipe do
GPR (Nível
projeto, mas para o cliente, dando
G)
uma maior facilidade para medir
cada parte, desenvolver o
cronograma, estimar o custo de
cada parte, bem como a divisão e
distribuição das tarefas.
GPR4 - (Até o nível F) O Para se estimar o esforço e o custo
esforço e o custo para a é necessário ter uma base de dados
execução das tarefas e dos de projetos anteriores, é preciso
produtos de trabalho são que esses dados sejam consistentes
estimados com base em para que os resultados da
dados históricos ou estimativa sejam satisfatórios.
referências técnicas.

GPR5 - O orçamento e o Primeiramente é necessário criar

cronograma do projeto, uma matriz de criticidade, para
incluindo marcos e/ou pontos identificar o grau de
de controle, são relacionamento entre as tarefas,
estabelecidos e mantidos. para então posteriormente
estabelecer um cronograma de
duração do projeto sempre levando
em consideração a WBS. E após
esses processos poderá se fazer
uma estimativa de custo e
elaboração do orçamento do
projeto. Fazer uma manutenção
desses processos é fundamental
para se ter controle e qualidade no
projeto.

GPR6 - Os riscos do projeto É necessária a identificação de

são identificados e o seu possíveis riscos para o projeto. A
impacto, probabilidade de criação de uma lista dos possíveis
ocorrência e prioridade de riscos é criada, sendo
 tratamento são determinados posteriormente analisado quais
e documentados. destes riscos têm uma maior
chance de ocorrer, bem como
verificar o seu impacto e seu
devido tratamento. Cabe ao gerente
fazer um monitoramento desses
riscos.

MED1 - Objetivos de Após o levantamento dos objetivos

medição são estabelecidos e da organização, os objetivos de
mantidos a partir dos medição são estabelecidos
objetivos da organização e baseados nesse levantamento e
das necessidades de então alguns aspectos podem ser
informação de processos medidos, como: processos,
técnicos e gerenciais. produtos e recursos. A
Medição – documentação gerada a partir
MED desses objetivos de medição
(Nível F) servirá para tomada de decisões e é
de extrema necessidade a criação
de um método para as medições,
para que os resultados possam
realmente atender os objetivos da
organização.

MED2 - Um conjunto Deve-se estabelecer um conjunto

adequado de medidas, de medidas baseadas em critérios
orientado pelos objetivos de de medição. Essas medidas devem
medição, é identificado e/ou ser detalhadas, documentadas e
definido, priorizado, principalmente revisadas para que
documentado, revisado e então os objetivos de medição da
atualizado. organização sejam atingidos.

A partir da documentação
especificada de cada medida, todos
os procedimentos para coleta de
dados devem ser definidos para
MED3 - Os procedimentos
que os objetivos de cada medição
para a coleta e o
sejam atendidos. É importante que
armazenamento de medidas
a entrada dos dados, bem como a
são especificados.
integração com os processos sejam
automatizados para facilitar a
verificação, a validação e acesso a
essa base de dados.
 De acordo com cada medida
especificada, será necessário criar
uma documentação com as
respectivas atividades e seus
MED4 - Os procedimentos
responsáveis, bem como
para a análise da medição
estabelecer um meio de
realizada são especificados.
comunicação com os participantes.
Esse processo facilitará uma
análise mais adequada e com
qualidade.

De acordo com os procedimentos

de coleta de dados já definidos, os
dados efetivamente passam a ser
coletados e analisados por seus
respectivos responsáveis. É
importante que essa coleta seja
realizada em suas datas já
MED5 - Os dados requeridos definidas no cronograma, para não
são coletados e analisados. afetar o andamento do projeto. A
partir da análise os resultados
deverão ser apresentados aos seus
interessados para possíveis
conclusões.

Todos os resultados e dados

coletados e analisados devem ser
armazenados para possíveis
analises futuras. Tudo deve estar
MED6 - Os dados e os bem especificado para facilitar as
resultados de análises são verificações futuras principalmente
armazenados. em relação às interpretações de
medidas de como elas poderão ser
utilizadas. Todo esse processo
facilitará a criação de uma base
histórica.
MED7 - As informações Os responsáveis pelas medições
produzidas são usadas para devem utilizar as informações
 produzidas para ter apoio nas
tomadas de decisão. É importante a
confidencialidade com essas
informações, não permitindo uso
indevido. As medições servirão
apoiar decisões e para para que as tomadas corretivas e
fornecer uma base objetiva riscos avaliados sejam realizados
para comunicação aos com sucesso para os objetivos da
interessados. organização e do projeto. A clareza
da comunicação deve estar bem
relacionada a cada objetivo,
facilitando a utilização dos
resultados com os objetivos.

É realizada uma seleção dos

GPR 21 - (A partir do nível subprocessos que serão
B) Subprocessos do processo gerenciados estatisticamente,
definido para o projeto e que sendo necessário ter uma
Gerência de serão gerenciados relevância para o alcance dos
Projetos – estatisticamente são objetivos de qualidade e
GPR escolhidos e são desempenho do projeto.
(evolução) Posteriormente à seleção dos
identificados os atributos por subprocessos, será necessário
(Nível B)
meio dos quais cada identificar os atributos do produto
subprocesso será e do processo para o
gerenciado estatisticamente. gerenciamento estatístico.

É necessário um monitoramento
GPR22 - (A partir do nível constante dos objetivos de cada
B) O projeto é monitorado subprocesso como qualidade e
para determinar se desempenho, se realmente estão
seus objetivos para qualidade sendo alcançados. É interessante
e para o desempenho do utilizar métodos que possam
processo serão atingidos. antecipar as chances de se obter
Quando necessário, ações resultados futuros, baseados nos
dados atuais ou históricos.
corretivas são identificadas.

GPR 23 - (A partir do nível É necessária a utilização de

B) O entendimento da métodos estatísticos para avaliar
variação dos subprocessos cada subprocesso selecionado.
escolhidos para gerência Uma gerência estatística deve estar
quantitativa, utilizando em funcionamento para analisar
medidas cada medida e técnica utilizada
análise estatisticamente. Devem ser
e técnicas de
selecionadas e analisadas medidas
estatística previamente
selecionadas, é estabelecido e que estejam associadas aos

mantido.
GPR 24 - (A partir do nível
B) O desempenho dos
subprocessos escolhidos para
gerência quantitativa é alcançados e em paralelo buscando
monitorado para determinar
a sua capacidade de
satisfazer os seus objetivos
para qualidade e para o
desempenho. Ações são
identificadas quando for
necessário tratar deficiências
dos subprocessos.
GPR 25 - (A partir do nível
B) Dados estatísticos e de
gerência da qualidade são
incorporados ao repositório
de medidas da organização.
GPR4 - (A partir do nível E)
Gerência de O planejamento e as
Projetos – estimativas das atividades do
GPR projeto são feitos baseados
(evolução) no repositório de estimativas
(Nível E) e no conjunto de ativos de
processo organizacional.
objetivos de qualidade e
desempenho do projeto e do
processo respectivamente.
É preciso haver um monitoramento
de cada subprocesso para verificar
se os objetivos de qualidade e
desempenho estão sendo
tomar ações corretivas nas
possíveis deficiências encontradas.
É interessante a utilização de
gráficos para representar os
resultados de forma clara,
facilitando com isso a
comunicação entre os interessados.
Todos os dados estatísticos e de
qualidade do projeto conforme sua
evolução devem ser introduzidos
ao repositório de medidas da
organização, construindo com isso
uma base histórica para análises
futuras.
De acordo com o repositório de
estimativas o planejamento do
projeto será baseado. Toda a base
histórica de dados bem organizada,
facilitará nos próximos
planejamentos ou tomada de
decisões de projetos. Com essa
base histórica, uma análise de
tempo ou esforço para
determinadas atividades poderão
ser bem mais sucedidas e
principalmente justificadas. Os
métodos de estimativas como
Pontos por Casos de uso ou Pontos
por Função, poderão ser calibrados
de acordo com os valores da base
histórica, facilitando um
replanejamento ou verificar
possíveis riscos para com os
objetivos do projeto e da
organização.
 A partir do resultado das medidas
de projetos já executados, será
possível realizar um levantamento
de propostas de melhorias para
GPR19 - (A partir do nível projetos futuros. Sendo de
E) Produtos de trabalho, fundamental importância a
medidas e experiências manutenção do repositório de
documentadas contribuem medidas, pois nesse momento a
para os ativos de processo organização poderá estabelecer
organizacional. padrões para os projetos, bem
como as experiências adquiridas
nos projetos terão também um
valor para a melhoria dos ativos de
processo.

Apêndice B – Questionário avaliativo das empresas

Pesquisa da Maturidade das Estimativas e Métricas em Organizações Paraenses

Com intuito de realizar uma análise da maturidade das organizações ou empresas de

software paraenses no uso de estimativas e métricas, foi elaborado esse questionário
baseado nos resultados esperados no que diz respeito às recomendações do modelo
MPS.Br (Melhoria de Processo de Software Brasileiro).

O questionário conta com 17 perguntas, sendo de fundamental importância uma

justificativa ou um comentário de como é realizado o processo na empresa, para que a
pesquisa obtenha sucesso.

Obs: Ressaltamos que as informações contidas no questionário não serão divulgadas,

sendo de uso exclusivo para elaboração estatística.

O resultado do respectivo questionário faz parte do trabalho final para obtenção de título
do curso de Pós-Graduação em Gerência de Projetos de Software da Universidade
Federal do Pará ano 2008.

Alunos: Fábio Lima de Figueiredo e Luiz Otávio Barata.

Orientador: Prof. Dr. Sandro Ronaldo Bezerra Oliveira.

Questionário
 Para estruturar os projetos a organização utiliza uma EAP (Estrutura Analítica de
1 Projetos) ou WBS (Work breakdown structure)? Caso Sim, Justifique ou
comente.
R:

A organização possui uma base de dados ou histórico de projetos para servir de

2 apoio a uma análise de esforço e custo de tarefas? Caso Sim, Justifique ou
comente.
R:

3 A organização utiliza um cronograma incluindo marcos ou pontos de controle?

Caso Sim, Justifique ou comente.
R:

4 A organização possui uma lista de possíveis riscos para os projetos, bem como
seus devidos impactos e tratamentos? Justifique ou comente.
R:

5 A organização possui um método de medida e as medições dos projetos são

baseadas nos objetivos da organização? Caso Sim, Justifique ou comente.
R:

A organização possui uma documentação detalhada do conjunto de medidas e

6 constantemente são revisadas de acordo com os objetivos da organização? Caso
Sim, Justifique ou comente.
R:

A organização possui uma documentação especifica para os procedimentos de

7 como serão coletados e armazenados os dados dos projetos? Caso Sim, Justifique
ou comente.
R:

De acordo com cada medida do projeto a organização possui uma documentação

8 com as respectivas atividades e seus responsáveis, bem como um meio de
comunicação entre eles? Caso Sim, Justifique ou comente.
R:

9 A coleta e análise dos dados dos projetos são realizados de acordo com o
cronograma? Caso Sim, Justifique ou comente.
R:
10 As informações produzidas são usadas para apoiar decisões do projeto indo de
acordo com os objetivos da organização? Caso Sim, Justifique ou comente.
R:

11 É realizada uma seleção de subprocessos e identificação dos atributos do produto

para um gerênciamento estatístico? Caso Sim, Justifique ou comente.
R:

O projeto é monitorado para determinar se seus objetivos para a qualidade e

12 desempenho do processo estão sendo atingidos? Caso Sim, Justifique ou
comente.
R:

Os projetos possuem uma Gerência Estatística para analisar cada medida e técnica
13 utilizada, indo de acordo com os objetivos de qualidade e desempenho do projeto
e do processo respectivamente? Caso Sim, Justifique ou comente.
R:

É realizada uma monitoração de cada subprocesso para verificar se os objetivos de

14 qualidade e desempenho estão sendo alcançados, tomando ações corretivas nas
possíveis deficiências encontradas? Caso Sim, Justifique ou comente.
R:

Os dados estatísticos e de qualidade do projeto conforme suas evoluções são

15 incorporados ao repositório de medidas da organização? Caso Sim, Justifique ou
comente.
R:

O planejamento de novos projetos é baseado através do repositório de estimativas

16 e do conjunto de ativos do processo organizacional? Caso Sim, Justifique ou
comente.
R:

A partir dos resultados das medidas de projetos já executados a organização

17 realiza um levantamento de propostas de melhorias para projetos futuros? Caso
Sim, Justifique ou comente.
R: