FACULDADE METROPOLITANA DE CAMAARI

CURSO DE BACHARELADO EM ENGENHARIA DE CONTROLE E

AUTOMAO.














ESTIMATIVA DE CUSTO DE SOFTWARE.

















Camaari-Ba
2011





FACULDADE METROPOLITANA DE CAMAARI
CURSO DE BACHARELADO EM ENGENHARIA DE CONTROLE E
AUTOMAO.





ESTIMATIVA DE CUSTO DE SOFTWARE.
















Cludia Cristina Guimares.
Hagner Vieira.
Hcsa Pamela.
Marinaldo de Jesus.





Camaari-Ba
2011
Pesquisa Bibliogrfica da disciplina Engenharia de
Software a ser encaminhada professora
Fernanda Silva para avaliao e anlise. Referente
1 Unidade do curso de Bacharelado em
Engenharia de Controle e Automao
(Mecatrnica).



"Lembrar que estarei morto em breve a ferramenta mais importante que j
encontrei para me ajudar a tomar grandes decises. Porque quase tudo -
expectativas externas, orgulho, medo de passar vergonha ou falhar - caem
diante da morte, deixando apenas o que apenas importante. No h razo
para no seguir o seu corao. Lembrar que voc vai morrer a melhor maneira
que eu conheo para evitar a armadilha de pensar que voc tem algo a perder.
Voc j est nu. No h razo para no seguir seu corao."
(Steve Jobs)



































ESTIMATIVA DE CUSTO DE SOFTWARE.


Sumrio


1. INTRODUO....................................................................................................05





2. ESTADO DA ARTE........................................................................................06



3. MTODO PARA ESTIMATIVA DE CUSTO. ......................................10




4. MTODO COCOMO...............................................................................11





5. CONCLUSO.....................................................................................................13





6. REFERNCIAS BIBLIOGRFICAS...................................................................14
5
ESTIMATIVA DE CUSTO DE SOFTWARE.


1. INTRODUO.
Os problemas relativos previsibilidade de projetos constituem uma das
preocupaes da indstria de software. As estatsticas da Scientific American
[Filho, 2000] mostram que o tempo realizado dos projetos de software excede em
50% o tempo planejado no cronograma do projeto. O Standish Groups relatou em
1994 [Standish, 1994] que apenas 16% dos projetos de software atingem o seu
objetivo dentro do cronograma e do oramento previstos. Por outro lado, Glass em
[Glass, 2003] afirma que algumas das principais causas para isso so estimativas
feitas baseadas em informao insuficiente (usualmente sem que a especificao
de requisitos esteja disponvel), estimativas feitas para satisfazer a direo, e
projetos com requisitos demasiadamente flutuantes. Os dados de 2001 do
Standish Groups [Standish, 2001] mostram as seguintes estatsticas: 27% dos
projetos de software so finalizados no tempo e custo previstos; 40% dos projetos
so cancelados antes de finalizarem; 42% dos projetos no apresentam as
funcionalidades propostas originalmente; 50% dos projetos custam em mdia
180% a mais da estimativa original. Cabe salientar que ocorreu uma melhoria nas
estatsticas de projetos que terminam dentro prazo (cronograma) e oramento
previstos do Standish Group de 1994 (16%) para 2001 (27%). Esta melhoria
ocorreu devido a percepo da indstria sobre a importncia estratgica do
software [Pressman, 2000], devido ao surgimento de clientes mais exigentes e,
especialmente, devido aos investimentos na implantao das melhores prticas da
Qualidade de Software como o CMM (Capability Maturity Model) [PAU93] no Brasil
[MCT, 2004a] [MCT,2004b]. Os dados da Boeing Information Systems
apresentados em [Masters, 2000] demonstramque a previsibilidade de
cronograma do projeto aumenta conforme a evoluo nos nveis de maturidade do
modelo CMM. A variao de cronograma da Boeing foi reduzida em 125% durante
a transio do nvel CMM 1 para o nvel 2 e ento em 24% durante a transio do
nvel 2 para o nvel 3 e em 15% durante a transio do nvel 3 para o nvel 4.
Embora tenham ocorrido melhorias, a indstria continua lidando com projetos
mal sucedidos. O CHAOS Report de 2003 [Standish, 2003] apresentou os
seguintes dados: apenas 34% dos projetos so bem sucedidos; 15% dos projetos
foram cancelados; 43% o erro mdio em relao ao oramento do projeto
daqueles que foram completados; e apenas 52% das caractersticas (requisitos
no funcionais) e funcionalidades so entregues no produto. A maioria das
tecnologias e metodologias de engenharia de software preocupam-se
primordialmente com a qualidade da soluo de software gerada. No entanto,
existem tambm vrios problemas associados gesto do projeto, tais como:
tempo estimado de durao do projeto, custo, alocao de recursos, esforo
gasto e outros. Muitos desses aspectos podem ser estimados quantitativamente. A
grande dificuldade reside na gerao de estimativas fidedignas. Note que se um
projeto subestimado, mesmo utilizando-se os melhores mtodos para a
elicitao de requisitos, desenho, implementao e testes, o projeto corre o risco
de ser cancelado. O principal risco que afeta os projetos de software
subestimados o de presso excessiva do cronograma, o qual pode forar o
6
trmino prematuro do projeto, colocando em risco a qualidade e a funcionalidade
do projeto [Jones, 1994]. Entre as possveis conseqncias desse risco temos:
cancelamento do projeto, baixa moral da equipe, baixa qualidade, atrasos de
cronograma, custos excessivos devido a um grande nmero de horas extras e
atritos entre o gerente e a equipe [Hazan, 1999]. Assim, considera-se um dos
principais problemas que afetam os projetos de software so os gerenciais
[Forsberg, 1997].
Estes problemas, que possuem maior impacto em projetos complexos,
freqentemente esto associados gesto de requisitos e previsibilidade de
prazo e custo. As principais decises que devem ser tomadas por um gerente de
projetos incluem, dentre outras, a negociao entre custo, cronograma,
funcionalidade e fatores da qualidade. A definio do oramento e do cronograma
constitui uma base para o planejamento e controle do projeto. Por exemplo,
quantas pessoas devem ser alocadas nas fases inicial, intermedirias e final do
projeto. Quanto esforo, custo e cronograma deve ser esperado para atingir os
principais marcos do projeto [Boehm, 2000]. Um dos principais riscos que atinge o
processo de estimativas a falta de credibilidade nas estimativas pelas equipes
de desenvolvimento [Boehm, 2000]. Isto ocorre quando as estimativas so
irreais, ou seja quando os projetos so subestimados ou superestimados. A
acurcia das estimativas de tamanho torna-se fundamental para a elaborao de
um cronograma e oramento realistas, pois as estimativas de tamanho constituem
a base para a derivao das estimativas de custo e de esforo [SEI, 2002].
Na rea de gerao de estimativas de esforo, prazo e custo, destacam-se os
modelos paramtricos COCOMO II (Constructive Cost Model) [Boehm, 2000] e o
SLiM (Software Lyfe Cycle Model) [Putnan, 1992]. Estes modelos foram
publicados [Boehm, 2000] [Putnan, 1992] e so respeitados tanto no meio
acadmico quanto na indstria [Aguiar, 2004]. No entanto, os mtodos para a
gerao das estimativas de tamanho de projetos de software, que constituem o
principal insumo para a utilizao dos modelos de estimativa de esforo, tm sido
muito pouco discutido pela literatura [Meli, 1997]. Este processo trata as
estimativas de tamanho, esforo, prazo, custo e recursos computacionais crticos,
seguindo as prticas de estimativas definidas na rea de processo - Planejamento
do Projeto de Software do modelo CMMI [SEI, 2002].
2. ESTADO DA ARTE.

Estimativas constituem o primeiro tipo de anlise quantitativa executado no
projeto de software. Estimativas de m qualidade (sem acurcia) constituem uma
das principais causas dos projetos cancelados [Jones, 1994]. As estimativas
inadequadas podem levar a prazos no cumpridos, custos excessivos com horas
extras e m qualidade do software. Esta seo tem como propsito apresentar
uma viso geral das prticas de planejamento de projetos de software descritas
no CMMI [SEI, 2002], destacando as atividades relativas s estimativas de
projetos. A rea de processo de planejamento de projetos considera as seguintes
estimativas: tamanho, esforo, custo, cronograma e necessidade de recursos
computacionais crticos. Tambm so apresentadas as mtricas mais utilizadas
pela indstria de software para as estimativas de tamanho de projetos, a saber:
7
Pontos de Funo (PF) e Pontos por Casos de Uso (PCU). Humphrey
[Humphrey, 1990] define um projeto como sendo um esforo de trabalho real izado
por um grupo de pessoas com um objetivo bem definido, dentro de prazo
estabelecido e com recursos limitados. Dessa forma, pode-se caracterizar um
projeto como uma ou mais demandas do cliente. Por exemplo: a elaborao de
um sistema novo; a evoluo de uma ou mais funcionalidades de um sistema
existente (manuteno evolutiva); e a migrao de um sistema existente para
outra plataforma ou mudana de verso da linguagem de desenvolvimento do
sistema (manuteno adaptativa).
O Gerenciamento de Projetos a aplicao de conhecimentos, habilidades, e
tcnicas para projetar atividades que visem atingir ou exceder as necessidades e
expectativas das partes envolvidas, com relao ao projeto. O ato de atingir ou
exceder as necessidades e expectativas das partes envolvidas, envolve o
equilbrio entre demandas concorrentes de escopo, prazo, custo e qualidade [PMI,
2000].

Um dos objetivos da Gerncia de Projetos identificar, estabelecer, coordenar,
e monitorar as atividades, tarefas e recursos necessrios de um projeto para
produzir um produto e/ou servio, dentro do contexto dos requisitos e restries
do projeto [ABNT, 1998].
Um segundo objetivo acompanhar, dirigir e registrar os resultados produzidos e
os recursos consumidos no desenrolar da execuo do projeto, confrontando-os
com o que era esperado pelos planos. Como conseqncia desse confronto o
gerente estar capacitado a tomar medidas corretivas racionais, sempre que a
execuo se desviar mais do que o tolerado do que era esperado. Os dois
principais processos do Gerenciamento de Projetos de Software so:
Planejamento do Projeto e Acompanhamento do Projeto. As principais atividades
contidas nestes processos consistem no estabelecimento e acompanhamento das
estimativas de tamanho, cronograma, recursos, custos e eficincia de remoo de
defeitos e na obteno e manuteno de compromissos [Jones, 1997] [SEI,
2002]. O planejamento do projeto de software inicia com uma viso geral dos
requisitos que definem o produto, e tem como propsito estabelecer e manter
planos que definam as atividades a serem realizadas durante o projeto. A rea de
processo Planejamento de Projeto do nvel 2 do modelo CMMI envolve as
seguintes atividades [SEI, 2002]:

Desenvolver o plano do projeto.
Interagir apropriadamente com os interessados (stakeholders).
Planejar o envolvimento dos interessados identificados;
Obter compromisso com o plano;
Manter o plano;
O estabelecimento de estimativas constitui uma das principais atividades do
processo de planejamento do projeto de software. As estimativas devem ter uma
base segura e fornecer confiana que os planos nelas baseados so capazes de
conduzir aos objetivos do projeto, e que englobam funcionalidades, custo, prazo e
caractersticas da qualidade. Os fatores tipicamente considerados nas estimativas
incluem, dentre outros,o seguinte:
8
Requisitos do projeto;
Escopo do projeto;
Modelo do ciclo de vida do projeto selecionado (ex.: cascata, incremental,
etc.);
Abordagem tcnica;
Tarefas e artefatos identificados e seus atributos; (ex.: tamanho e
complexidade)
Modelos e dados histricos para converso dos atributos dos artefatos e
tarefas em horas de trabalho e custo.
As estimativas e as premissas utilizadas para sua gerao 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]:
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, esforo e cronograma. As
estimativas de tamanho devem ser consistentes com os requisitos do
projeto para determinar-se esforo, custo e cronograma adequados.
Assim, sempre que ocorrerem mudanas alm do tolerado (relevantes)
nos requisitos, as estimativas precisam ser revistas e o projeto
replanejado. Sugere-se a utilizao da mtrica Pontos de Funo (PF)
[IFPUG, 2004] para as estimativas de tamanho. Os PF fornecem uma
mtrica de tamanho do projeto de software, quantificando as suas
funcionalidades, sob o ponto de vista lgico, observando os requisitos do
usurio [Garmus, 2001]. Alm de apoiar a implantao dos modelos CMM
[Hazan, 2003] e CMMI [Dekkers, 2002], a mtrica foi reconhecida pela
norma ISO/IEC 20926 [Dekkers, 2003].
Determinar as estimativas de esforo e de custo para os artefatos e
tarefas: as estimativas de esforo e custo devem ser geradas baseando-
se em dados objetivos, ou seja, utilizando mtodos e dados histricos. Os
projetos com ausncia de dados histricos de esforo de projetos
similares disponveis 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
esforo e custo: considerar a necessidade de recursos computacionais
crticos no ambiente de desenvolvimento, no ambiente de teste, no
ambiente de produo, ou em qualquer combinao destes. Estimativas
de recursos computacionais incluem o seguinte: identificar os recursos
computacionais crticos; e basear estimativas de recursos computacionais
crticos em requisitos alocados. Exemplos de recursos computacionais
incluem: memria, processador, espao em disco, perifricos, capacidade
da rede e do banco de dados.
9
Uma vez que as estimativas foram estabelecidas, desenvolve-se o plano do
projeto, que fornece uma base para execuo e controle das atividades do projeto.
O plano do projeto precisa ser revisado quando ocorrem mudanas de requisitos
ou de compromissos durante o projeto.Este tambm precisa ser revisado quando
forem observados erros estruturais nas estimativas utilizadas. O propsito do
processo do Acompanhamento do Projeto fornecer um entendimento visvel e
confivel do progresso do projeto de modo que aes corretivas apropriadas
possam ser tomadas quando o desempenho desviar significativamente do pl ano.
Um desvio significativo se, caso no seja resolvido, o projeto no alcanar
seus objetivos funcionalidades, atributos, custo e prazo). O progresso
determinado pela comparao dos artefatos, tamanho, esforo, custo e
cronograma atuais e os planejados nos marcos estabelecidos no plano do projeto.
Note que o CMMI define as diretrizes para um processo de planejamento de
projetos, estabelecendo as principais estimativas a serem consideradas: tamanho,
esforo, prazo, custo e recursos computacionais crticos. No entanto, o modelo
no descreve como estimar o tamanho de projetos de desenvolvimento e de
manuteno de software, como derivar as estimativas de esforo, prazo e custo
a partir das estimativas de tamanho.
A literatura tem discutido bastante os modelos de estimativas de esforo, prazo
e custo. O modelo COCOMO II [Boehm, 2000], desenvolvido na University of
Southern California (USC) tem sido utilizado pela indstria [Aguiar, 2004]. As
ferramentas SLiM, comercializada pela empresa QSM (Quantitative Software
Management) e Knowledge Plan criada pela empresa SPR (Software Productivity
Research), que utilizam modelos de estimativas proprietrios, tambm tem sido
utilizadas pela indstria. No entanto, a maioria das empresas de software
continuam estimando projetos, baseando-se na opinio e sentimento do gerente
ou lder do projeto.A dificuldade no est na utilizao dos modelos de estimativas
de esforo, prazo e custo. E sim no estabelecimento das estimativas de tamanho
que constitui o principal insumo para a gerao das estimativas de esforo, prazo
e custo.
Custos do Software:
Os custos do software dominam os custos do restante do sistema.
No caso de software para computadores pessoais, o custo do software a
maior parte.
Software custam muito mais para se manter do que para desenvolvimento,
especialmente software de vida longa.
A engenharia de software deve preocupar-se fortemente com os custos de
software.
Os maiores custos de desenvolvimento so o de pessoal capital
intelectual.


10
3. MTODO PARA ESTIMATIVA DE CUSTO.
Segundo o modelo CMM, as estimativas de custo devem ser derivadas da
estimativa de tamanho. Assim, de posse do tamanho da aplicao em Pontos de
Funo, do esforo e do tamanho da equipe, o prximo passo a gerao da
estimativa de custo. Neste procedimento, considera-se os seguintes atributos
para a aferio da estimativa de custo: estimativa de mo de obra (considerando
o custo por perfil do profissional), recursos computacionais, treinamento,
consultoria, viagens e custos indiretos.
importante destacar que as estimativas de custos de mo de obra dos
sistemas terceirizados so aferidas com base no nmero de Pontos de Funo
estimados e o preo por Ponto de Funo contido no contrato firmado entre a
empresa contratante e a empresa contratada. Nos sistemas desenvolvidos por
profissionais da empresa, o custo estimado considerando-se o esforo e o custo
dos profissionais alocados para o desenvolvimento do projeto. importante
destacar que o custo por Ponto de Funo pode ser bastante varivel, o esforo
(HH/PF) e outros custos indiretos influenciam fortemente no custo/PF.
A estimativa de custo deve considerar o valor da hora dos profissionais alocados
ao projeto, bem como outros custos de ambiente, ferramentas, deslocamentos,
consultoria, etc. A estimativa de recursos computacionais crticos em projeto
WEB deve considerar a disponibilidade dos servidores utilizados para
desenvolvimento, homologao e produo do sistema e outros recursos de
Hardware relevantes.
4. MTODO COCOMO.
O mtodo COCOMO (ou COnstructive COst MOdel) um modelo de estimativa
do tempo de desenvolvimento de um produto. Criado porBarry Boehm. baseado
no estudo de sessenta e trs projetos. Os programas examinaram de 2.000 a
100.000 linhas de cdigo emlinguagens de programao de Assembly a PL/I.

COCOMO consiste em trs implementaes:

Bsico
um modelo esttico que calcula o esforo de desenvolvimento
de software e seu custo, em funo do tamanho de linhas de cdigos
desenvolvidas.
11
Cocomo bsico bom por ser rpido em estimativas e custos de software,
mas sua exatido limitada por causa de sua falta de fatores para explicar
as diferenas entre ferramentas, qualidade de pessoal e experincia, uso
de ferramentas modernas e tcnicas, e outros atributos de projeto que
influenciam nos custos de software.Pode-se conseguir um software
interativo auxiliar na estimativa de custos e prazos de projetos de sistemas.
A partir de um conjunto de atributos, premissas e modos de
desenvolvimento o COCOMO estima os prazos, custos e recursos
necessrios para cada etapa do ciclo de vida do produto.

Intermedirio
Calcula o esforo de desenvolvimento de software em funo do tamanho
do programa, que inclui custo, avaliao subjetiva do produto, hardware,
pessoal e atributos de projeto.
O mtodo intermedirio uma extenso do mtodo bsico, mas com mais
categorias de controle como: Atributos do produto, Atributos de hardware,
Atributos pessoais, Atributos do projeto.

Avanado
So incorporadas caractersticas da verso intermediria com uma
avaliao de impacto de custo em cada passo de todo o projeto.
Nos anos 1980, Barry Boehm props uma hierarquia de modelos de estimativa
de software denominada COCOMO (Constructive Cost Model).O modelo
COCOMO tornou-se um dos modelos de estimativa de custo de software mais
amplamente usados, mais tarde, o modelo COCOMO evoluiu para um modelo
mais abrangente, chamado COCOMO II
4.1_ Modelo COCOMO II.
uma hierarquia de modelos que tratam das seguintes reas:
Modelo de composio da aplicao: Usado nos primeiros estgios da
engenharia de software.
Modelo do primeiro estgio de projeto: Usado depois que os requisitos
foram estabilizados e a arquitetura foi estabelecida.
Modelo para o estgio aps a arquitetura: Usado durante a construo do
software.
Como todos os modelos de estimativa de software, requer informao de
tamanho.Trs opes:
12
Pontos por objeto
Pontos por funo
Linhas de cdigo-fonte
Mtrica pontos por objeto
calculada usando-se a contagem da quantidade de:
Telas (na interface com o usurio)
Relatrios
Componentes que sero necessrios pra construir a aplicao.
Cada objeto classificado em trs nveis de complexidade.A porcentagem de re-
uso estimada e a contagem de pontos por objeto ajustada.
A produtividade estimada usando-se:
A experincia/capacidade do desenvolvedor.
A maturidade/capacidade do ambiente de desenvolvimento.
O esforo estimado usando-se os pontos por objeto e a produtividade.











13
5. CONCLUSO.

A estimativa precisa do custo e prazo de projetos de software no incio
de seu ciclo de vida (ainda na fase de planejamento) fundamental
para a indstria de software. Diversos projetos de software foram
interrompidos devido a atrasos no prazo e, conseqentemente, devido
ao custo real do projeto (ainda incompleto) ter superado
significativamente o custo estimado no incio do mesmo.
A gerncia do custo do projeto agrega os processos que envolvem
planejamento, estimativa, oramento e controle de custos que sero necessrios
para a concluso do projeto a partir de uma previso oramentria.
Os processos de gerncia do custo do projeto incluem:
Estimativa de custo: desenvolver uma aproximao dos gastos com os
recursos necessrios para execuo do projeto;
Oramento de Custo: agregar os custos estimados de atividades ou de
pacotes individuais de trabalho para estabelecer uma base de custo;
Controle de Custo: influenciar nos fatores que geram uma variao de custo e
controlar as mudanas de oramento do projeto;
A gesto de custos um processo em que se utiliza um conjunto de tcnicas
multidisciplinares, que nos permite compreender a origem dos custos. Este
processo pode conduzir ao aumento de proveitos, redues de custos e
obteno de melhores nveis de produtividade.















14

6. REFERNCIAS BIBLIOGRFICAS.


15