ISSN 0103-9741 Monografias em Cincia da Computao n 04/05

Anlise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software

Claudia Hazan Arndt von Staa

Departamento de Informtica

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO RUA MARQUS DE SO VICENTE, 225 - CEP 22453-900 RIO DE JANEIRO - BRASIL

Monografias em Cincia da Computao, No. 04/05 Editor: Prof. Carlos Jos Pereira de Lucena

ISSN: 0103-9741 Fevereiro, 2005

Anlise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software *

Claudia Hazan
claudinha@inf.puc-rio.br

Arndt von Staa

arndt@inf.puc-rio.br Abstract. Documented estimation constitutes the basis for the construction of trustworthy software project plans. The size estimation of software projects is used to derive the cost, effort and schedule estimations. Several models have been used by industry to estimate effort and cost given system or artifact size estimates, for example COCOMO. However, the methods to estimate the size of a project have gotten little attention. This work analyzes, from the perspective of CMMI, methods used to generate software projects size estimations using Function Points. It then proposes a new method for estimating size based on experiments. Finally, we describe a simplified process for generating and documenting estimations regarding size, effort, budget, schedule and required critical computer resources. Keywords: Estimations, Function Point Analysis, Software Project Management, CMMI. Resumo. Estimativas documentadas constituem a base para a elaborao de planos fidedignos do projeto de software. A estimativa do tamanho de projetos de software utilizada para a derivao das estimativas de custo, esforo e cronograma. Muitos modelos tm sido utilizados pela indstria para estimar-se esforo e custo baseados em estimativas de dimenso dos artefatos, como por exemplo o COCOMO. Neste trabalho analisamos, a partir de uma perspectiva baseada em CMMI, mtodos utilizados para gerao de estimativas de tamanho de projetos de software baseadas em Pontos de Funo. A seguir propomos um novo mtodo para gerao de estimativas de tamanho, baseando-se em experimentao. Finalmente apresentamos um processo simplificado para a gerao e a documentao de estimativas de tamanho, esforo, custo, cronograma e necessidade de recursos computacionais crticos. Palavras-chave: Estimativas, Anlise de Pontos por Funo, Gerenciamento de Projetos de Software, CMMI. ___________________
*

Trabalho patrocinado pelo Ministrio de Cincia e Tecnologia da Presidncia da Repblica Federativa do Brasil

Responsvel por publicaes: Rosane Teles Lins Castilho Assessoria de Biblioteca, Documentao e Informao PUC-Rio Departamento de Informtica Rua Marqus de So Vicente, 225 - Gvea 22453-900 Rio de Janeiro RJ Brasil Tel. +55 21 3114-1516 Fax: +55 21 3114-1530 E-mail: bib-di@inf.puc-rio.br

ii

Sumrio
1. INTRODUO ................................................................................................................................................. 1 1.1. ORGANIZAO DO ARTIGO ............................................................................................................................ 2 2. ESTADO DA ARTE.......................................................................................................................................... 3 2.1. PROPOSTA ..................................................................................................................................................... 7 3. ELABORAO ................................................................................................................................................ 8 3.1. ANLISE DO PROCESSO DE ESTIMATIVAS DO SERPRO ................................................................................ 8 3.2. PROPOSTA E IMPLEMENTAO DE MELHORIAS NO PROCESSO DE ESTIMATIVAS ......................................... 9 3.2.1. MTODOS PARA GERAO DE ESTIMATIVAS DE TAMANHO ............................................................. .. 10 3.2.1.1. MTODO CONTAGEM INDICATIVA ................................................................................... ...... 10 3.2.1.2. MTODO CONTAGEM INDICATIVA INTELIGENTE ............................................................. .....11 3.2.1.3. MTODO DE CONTAGEM ESTIMATIVA ................................................................................. 12 3.2.1.4. MTODO DAS ESTIMATIVAS PERCENTUAIS ...........................................................................15 3.2.2. MTODO PARA GERAO DE ESTIMATIVAS DE ESFORO............................................................... 17 3.2.3. MTODO PARA GERAO DE ESTIMATIVAS DE PRAZO .................................................................. 20 3.2.4. MTODO PARA GERAO DE ESTIMATIVAS DE CUSTO .................................................................. 22 3.2.5. ESTIMATIVAS DE RECURSOS COMPUTACIONAIS CRTICOS ............................................................. 22 4. DISCUSSO E CONTRIBUIES ............................................................................................................. 23 4.1. INTEGRANDO O PROCESSO DE ESTIMATIVAS PROPOSTO COM O XP............................................................ 24 5. ESTUDO DE CASO..................................................................................................................................26 6. CONCLUSES E RECOMENDAES PARA FUTUROS TRABALHOS ........................................... 28

iv

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, preconizadas pelos modelos e normas da Qualidade. Neste contexto, importante destacar o crescimento significativo da certificao ISO 9001 [ABNT, 1994] na indstria de software e qualificao em modelos 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] demonstram que 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. Os dados foram coletados entre os exerccios 1991 e 1999. 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 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].
1

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 trabalho tem como objetivo descrever e analisar o processo de gerao de estimativas do Servio Federal de Processamento de Dados (SERPRO), uma organizao governamental de desenvolvimento de solues de Tecnologia da Informao e de Comunicaes, e implantar melhorias por meio do estabelecimento de um novo mtodo de estimativas de tamanho de projetos de desenvolvimento e de manuteno evolutiva de software, integrando os conceitos da Anlise de Pontos de Funo ao conhecimento inicial do domnio do projeto. Este mtodo foi definido por meio de pesquisa de mtodos de estimativa de tamanho em Pontos de Funo, e a adaptao destes mtodos a partir da experincia adquirida. O propsito melhorar a acurcia das estimativas de tamanho. Alm disso, tambm apresentado um processo simplificado para gerao e documentao de estimativas. 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].

1.1. Organizao do artigo

Este trabalho est organizado da seguinte forma: a seo 2 apresenta o estado da arte das atividades de planejamento de projetos de software, destacando as diretrizes para os processos de gerao de estimativas do modelo CMMI. A seo 3 apresenta uma anlise do processo de estimativas do Servio Federal de Processamento de Dados (SERPRO). Esta anlise utiliza a ferramenta da qualidade: Diagrama de Causa e Efeito. Tambm apresentada uma proposta de implementao de melhorias no processo analisado por meio da definio de dois mtodos de estimativa de tamanho de projetos de software em Pontos de Funo, denominados Mtodo de Contagem Indicativa Inteligente e Mtodo de Contagem Estimativa. Estes mtodos possibilitam a gerao e documentao das estimativas no comeo do ciclo de vida do desenvolvimento de software, ou seja durante a fase de planejamento. Alm disso, nesta seo descrito um procedimento simplificado para a derivao das estimativas de esforo, prazo e custo, utilizando a estimativa de tamanho.
2

A seo 4 apresenta uma proposta de integrao do procedimento de estimativas proposto no processo de planejamento do Extreme Programming (XP). A seo 5 descreve um Estudo de Casos, ilustrando a aplicao do procedimento descrito na seo 3. Finalmente, a seo 6 conclui o trabalho e identifica possveis trabalhos futuros.

2. Estado da arte
Como j foi visto, 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: Pontos de Funo (PF) e Pontos por Casos de Uso (PCU). Humphrey [Humphrey, 1990] define um projeto como sendo um esforo de trabalho realizado 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)
3

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: 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.

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 plano. 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. As mtricas de tamanho de projeto de software mais utilizadas pela indstria so as seguintes: Pontos de Funo (PF) , Linhas de Cdigo (LOC - Line of Code) e Pontos por Casos de Uso (PCU). O principal benefcio da mtricas PF sobre a LOC que os Pontos de Funo podem ser obtidos no incio do ciclo de vida, diretamente das especificaes de requisitos do projeto. Alm disso, os PFs so teis para a gerao das estimativas de tamanho do projeto, independentemente da metodologia e linguagem de programao utilizada no desenvolvimento. Um mtodo de estimativas de Pontos de Funo bastante utilizado o Contagem Indicativa proposto pela NESMA (Netherlands Software Metrics Association) [NESMA, 2005]. Este mtodo foi considerado no estabelecimento de um novo mtodo definido neste trabalho - o mtodo Contagem Indicativa Inteligente. A mtrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner [Karner, 1993] com o propsito de estimar recursos para projetos de software orientados a objeto, modelados por meio de especificao de Casos de Uso. Em linhas gerais, o mtodo de contagem de Pontos por Caso de Uso consiste nos seguintes passos: 1. Contar os atores e identificar sua complexidade; 2. Contar os casos de uso e identificar sua complexidade; 3. Calcular os PCUs no ajustados; 4. Determinar o fator de complexidade tcnica; 5. Determinar o fator de complexidade ambiental; 6. Calcular os PCUs ajustados. Com o resultado desta medio e sabendo-se a produtividade mdia da organizao para produzir um PCU, pode-se ento estimar o esforo total para o projeto. A seguir so mostradas as principais vantagens da mtrica Pontos de Funo (PF) sobre a mtrica PCU. A mtrica Pontos por Caso de Uso foi apresentada para o mercado como uma soluo simples para as estimativas de tamanho, especialmente para os que no conheciam as prticas de Contagem de Pontos por Funo ou as consideravam complexas para serem aplicadas, descritas em [IFPUG, 2004].

Alm disso, existe uma falsa noo de que a mtrica Pontos de Funo no pode ser aplicada para dimensionar sistemas orientados a objetos. Como a contagem de Pontos de Funo, considera os requisitos funcionais do sistema, de maneira independente da metodologia utilizada1, os PFs tambm podem ser aplicados para sistemas cujos requisitos tenham sido modelados utilizando casos de uso. Enquanto que, o PCU somente pode ser aplicado em projetos de software cuja especificao tenha sido expressa em casos de uso. Note que a contagem de PF independe da forma como os requisitos do software foram expressos. Esta vantagem do PF foi citada pelo prprio Gustav Karner [Karner, 1993]. No possvel na prtica aplicar PCU na medio de aplicaes existentes cuja documentao esteja desatualizada ou sequer exista. A alternativa seria escrever os casos de uso destas aplicaes para s ento medi-las. Porm isto tornaria a medio invivel devido ao alto custo. Com o PF possvel realizar a medio analisando-se a prpria aplicao em uso (aplicao implantada ou pacote). A medio de aplicaes instaladas pode ser til na elaborao de contratos de outsourcing de sistemas e na aquisio de pacotes. No existe um padro nico para a escrita do caso de uso. Diferentes estilos na escrita dos caso de uso ou na sua granularidade podem levar a resultados diferentes na medio por PCU. A mtrica Pontos de Funo no sofre deste problema pois independe da forma como os requisitos so expressos ou documentados. Devido ao processo de medio do PCU ser baseado em casos de uso, o mtodo no pode ser empregado antes de concluda a anlise de requisitos do projeto. Na maioria das vezes h necessidade de se obter uma estimativa antes da finalizao desta etapa. O processo de contagem de PF tambm s pode ser empregado aps o levantamento dos requisitos do projeto, na fase de projeto lgico. Porm existem tcnicas estimativas de tamanho em pontos de funo que podem ser aplicadas com sucesso antes da anlise de requisitos ser concluda. Alguns destes mtodos sero apresentados neste trabalho, a saber: Contagem indicativa, Contagem indicativa inteligente, Contagem estimativa e Estimativas percentuais. A mtrica PCU no contempla a medio de projetos de melhoria funcional do software (manuteno evolutiva), somente projetos de desenvolvimento. A mtrica PF contempla a medio de projetos de desenvolvimento, projetos de manuteno evolutiva e aplicaes implantadas. Note que a mtrica Pontos de Funo pode ser usada para dimensionar os projetos concludos de uma organizao, possibilitando a gerao de uma baseline para as estimativas. No existe um grupo de usurios ou organizao responsvel pela padronizao ou evoluo do mtodo PCU; e a bibliografia sobre o assunto escassa. Para a mtrica PF existe o IFPUG (International Function Point Users Group) que o responsvel por manter o Manual de Prticas de Contagem. Alm disso, o mtodo PCU no aderente norma ISO/IEC 14143 que define um modelo para a medio funcional de software. A APF, conforme o manual do IFPUG verso 4.1.1, est padronizada sob a norma ISO/IEC 20926. No existe um programa de certificao de profissionais que conheam a tcnica do PCU e saibam aplic-la de forma adequada. A contagem de Pontos de Funo possui o programa de certificao CFPS (Certified Function Point Specialist) promovido pelo IFPUG, garantindo assim a utilizao correta do mtodo Anlise de Pontos de Funo (APF) por um especialista certificado. importante destacar que a certificao deve ser renovada a cada trs anos, para garantir a atualizao do especialista nas novas verses do manual ou at mesmo na verso em que ele foi certificado.
1

Cabe salientar que Pontos de Funo um indicador de dimenso. O esforo calculado a partir dos PF e da produtividade observada. Esta ltima evidentemente depende da tecnologia utilizada alm da proficincia da equipe.
6

O fator ambiental inserido no PCU subjetivo, dificultando a consistncia da aplicao do mtodo em programas de mtricas de software e benchmarking entre organizaes, pois torna o tamanho de um projeto varivel; sem que sua funcionalidade sequer mude. Se um mesmo projeto for entregue a duas equipes distintas a contagem dos PCUs deste projeto ser tambm diferente em cada situao. Ou seja, o mesmo projeto possui dois tamanhos distintos. importante enfatizar que o fator de ajuste da contagem de PF, que possui finalidade semelhante ao fator ambiental da mtrica Pontos por Caso de Uso, no subjetivo. O fator de ajuste calculado baseando-se na ponderao do Nvel de Influncia (NI) das 14 Caractersticas Gerais do Sistema (CGS) definidas. A ponderao do NI, que varia em uma escala de zero a cinco, baseada em descries contidas no manual de prticas de contagem CPM 4.2 [IFPUG 2004]. Na verso do manual (CPM 4.2), publicada em 2004, foram includas guidelines para apoiar o entendimento das descries associadas aos nveis de influncia de zero a cinco das caractersticas gerais do sistema. Embora muitas organizaes e referncias bibliogrficas considerem os Pontos por Caso de Uso como o estado da arte em mtricas de tamanho de software [Andrade, 2004] [Cunha, 2003] [Damodaram, 2004], analisando-se as desvantagens expostas acima pode-se concluir que o PCU no traz nenhum benefcio adicional sobre o PF. Tambm importante destacar a maturidade da mtrica PF na indstria de software (25 anos de criao e evoluo) em relao mtrica PCU (menos de 10 anos). E ainda, na aplicao de mtricas para estimar-se tamanho, a mtrica de Pontos de Funo possui uma vantagem adicional que a sua utilizao como insumo para o COCOMO, modelo utilizado para a derivao das estimativas de esforo, prazo e custo a partir das estimativas de tamanho. Assim, os mtodos de estimativas de tamanho propostos neste trabalho so baseados na mtrica PF.

2.1. Proposta
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. Na seo anterior, foram abordadas as prticas definidas pelo CMMI para o estabelecimento de um processo de estimativas, bem como as principais mtricas de tamanho utilizadas pela indstria de software. Este trabalho tem como propsito definir e implantar um processo simplificado de estimativas de projetos de software, baseando-se na aplicao prtica das diretrizes do CMMI, descritas nas prticas especficas de Planejamento de Projetos de Software. O foco deste trabalho encontra-se na anlise e no estabelecimento de mtodos para estimativas de tamanho de projetos de software. A mtrica utilizada para as estimativas de tamanho a de Pontos de Funo (PF), devido aos seus benefcios, descritos na seo anterior. Assim, ser apresentado como obter o tamanho aproximado de um projeto de software em Pontos de Funo no incio do ciclo de vida. E ainda, como derivar as estimativas de esforo, prazo e custo, de maneira emprica, da estimativa de tamanho gerada.

3. Elaborao
Esta seo tem como propsito apresentar um processo de estimativas simplificado, com nfase nos mtodos de estimativa de tamanho. Este processo foi definido para apoiar a organizao Servio Federal de Processamento de Dados (SERPRO) na certificao CMM Nvel 2 e encontra-se integrado sob a forma de um procedimento no processo de desenvolvimento de software da empresa - o PSDS (Processo Serpro de Desenvolvimento de Solues). O primeiro passo executado para definio do procedimento foi a anlise do processo estimativas do SERPRO, por meio da ferramenta diagrama de causa e efeito. Alm do procedimento tambm foi definido um artefato, denominado Estimativas Documentadas (ED) que tem a finalidade de apoiar a documentao das estimativas e das premissas utilizadas para as estimativas. Este artefato utilizado nas macroatividades de planejamento e acompanhamento dos projetos de software, definidas no processo da empresa.

3.1. Anlise do Processo de Estimativas do SERPRO

Esta seo mostra uma aplicao da ferramenta da qualidade diagrama de causa e efeito na identificao do relacionamento entre as principais causas do efeito falhas do processo de estimativas do SERPRO.
Falta de confiana nas estimativas Procedimento no gera estimativas com acurcia suficiente

Procedimento no considera projetos de manuteno

Utilizao de mtodos subjetivos e/ou inadequados Ausncia de para medio de tamanho Cultura de Medio Ausncia de dados histricos de produtividade Falta de clareza do procedimento

Processo de Estimativas Mal-sucedido

Ausncia da cultura de estimativas pelas equipes de desenvolvimento

No h treinamento na utilizao do procedimento Automatizao inadequada do procedimento

No utilizao do procedimento

Figura 1: Anlise de Falhas de um Processo de Estimativas de Software

O diagrama de causa e efeito, tambm conhecido como grfico espinha-de-peixe, mostra o relacionamento entre a caracterstica da qualidade e os fatores que afetam esta caracterstica. Sua apresentao assemelha-se com uma espinha-de-peixe, com a caracterstica da qualidade rotulada na posio da cabea do peixe, e os fatores que afetam esta caracterstica colocados onde os ossos esto localizados [Kan, 1995] [Oliveira, 1996]. A Figura 1 ilustra a identificao das principais causas dos problemas do processo de estimativas do SERPRO. A causa raiz dos principais problemas do processo de estimativas foi a utilizao da mtrica Pontos por Caso de Uso (PCU), discutida na seo 2. Estado da Arte. A mtrica PCU [Probasco, 2002] [Smith, 2000] foi apresentada para as equipes de desenvolvimento como uma Silver Bullet para as estimativas de tamanho, ou seja, seria simples e eficaz.

Alm disso, foi tambm erradamente colocado que a mtrica Pontos de Funo no seria adequada para estimar sistemas orientados a objetos ou sistemas modelados por meio de Casos de Uso. No entanto, a mtrica Pontos de Funo mede tamanho funcional, independentemente da tecnologia utilizada [IFPUG, 2004]. Dekkers [Dekkers, 2001], Aguiar [Aguiar, 1992] e Longstreet [Longstreet, 2002] afirmam que a Especificao de Casos de Uso um excelente mtodo para modelar requisitos e Pontos de Funo uma excelente mtrica para aferio de tamanho funcional dos requisitos elicitados, considerando o ponto de vista do usurio. O principal problema que os desenvolvedores encontraram na utilizao da mtrica PCU foram os seguintes: Falta de acurcia das estimativas de esforo, devido a ausncia de base histrica; Dificuldade de estimar pequenos projetos de manuteno ou apuraes especiais, onde no h modelagem de requisitos, por exemplo: desenvolvimento de uma rotina para atualizao de um arquivo e gerao de um relatrio; Dificuldade de gerao de dados histricos de produtividade, devido subjetividade do mtodo. Cada pessoa tem a sua maneira de modelar os requisitos em Casos de Uso, alguns mais detalhistas outros menos prolixos. Por exemplo, alguns analistas modelam a funcionalidade cadastro de alunos com apenas um Caso de Uso Cadastrar Alunos. Outros modelam com dois casos de uso: Cadastrar Alunos e Consultar Alunos. J os mais detalhistas modelam com quatro Casos de Uso: Incluir Aluno, Alterar Aluno, Excluir Aluno e Consultar Aluno. Assim, o mesmo sistema pode ter uma medida de tamanho em Pontos por Caso de Uso distinta; Impossibilidade de gerao de estimativas iniciais para o plano do projeto, a partir do artefato Documento de Viso [Kruchten, 2000] ou Proposta Comercial, onde no existem Casos de Uso modelados e sim necessidades e funcionalidades. O modelo CMM requer que o plano, contendo as estimativas, deve ser produzido no incio do projeto, quando os requisitos esto sendo elicitados e ainda no foram modelados [Fiorini, 1998].

A ausncia de cultura em mtricas pelas equipes de desenvolvimento, associada no adequao da mtrica Pontos por Casos de Uso, ausncia de dados histricos de produtividade e de treinamentos geraram uma falta de credibilidade nas estimativas pelas equipes de desenvolvimento. Como conseqncia, as atividades associadas s estimativas caram em desuso, especialmente pelos responsveis por projetos de pequenas manutenes, onde os requisitos no so modelados por Casos de Uso.

3.2. Proposta e Implementao de Melhorias no Processo de Estimativas

A anlise do diagrama de causa e efeito (Figura 1), apresentado na seo 3.1, permitiu a visualizao de um grande problema de forma organizada. As limitaes do diagrama que este no serve para priorizar as causas a serem tratadas. A deciso realizada foi a criao de um novo procedimento de estimativas, considerando as causas de problemas apontadas e a criao do curso Processo de Estimativas com mentoring, visando a capacitao das equipes de desenvolvimento no procedimento. O novo procedimento para gerao de estimativas de tamanho utilizou os princpios do modelo CMM [Fiorini, 1998], devido busca pela empresa da qualificao CMM - nvel 2 e do modelo XP [Beck, 2000], com o intuito de tornar o processo de estimativas simples, devido a dificuldade de aquisio uma ferramenta para gerao de estimativas pela empresa. A abordagem de utilizar as diretrizes de simplicidade do XP para alcanar as metas do modelo CMM defendida por Orr [Orr, 2002] e por Paulk [Paulk, 2001].
9

O propsito da criao do procedimento o de permitir que os lderes de projetos gerem as estimativas de tamanho, esforo, prazo, custo e recursos computacionais do projeto de software de forma consistente e padronizada para apoiar a elaborao do plano do projeto. O procedimento tem como objetivo integrar mtodos para apoiar as seguintes atividades: Gerar estimativas de tamanho do projeto de software; Derivar estimativas de esforo, custo e prazo do projeto de software.

3.2.1. Mtodos para Gerao de Estimativas de Tamanho Nesta seo prope-se mtodos para gerao de estimativas de tamanho de projetos de software em Pontos de Funo. A mtrica Pontos de Funo visa estabelecer uma estimativa confivel do tamanho do software, considerando a funcionalidade a ser entregue pela aplicao, independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicao [Garmus, 2001]. Alm disso, na prtica a APF tem demonstrado grande utilidade na garantia da completeza da especificao de requisitos. Uma contagem de PF realizada usando uma descrio formal das necessidades do negcio na linguagem do usurio. Assim, a contagem apoia uma reviso dos requisitos do sistema com o usurio [Hazan, 2003]. Na fase de Planejamento do Projeto de Software, os desenvolvedores possuem pouco conhecimento sobre o sistema a ser desenvolvido, tornando-se impraticvel a aplicao do mtodo de Contagem de Pontos de Funo publicado no manual CPM 4.2 que preconiza a existncia do projeto lgico da aplicao [IFPUG, 2004]. Note que nesta fase ainda no temos todos os requisitos elicitados, e portanto no existe um projeto lgico da aplicao completo e validado. Assim, foram identificados na literatura mtodos para estimar o tamanho do projeto em Pontos de Funo no incio do projeto, utilizando o Documento de Viso. Alm dos mtodos pesquisados, foi criado um novo mtodo, denominado NESMA Inteligente, que consiste na calibragem dos ndices utilizados no mtodo Contagem Indicativa [NESMA, 2005], utilizando o conhecimento inicial dos requisitos do projeto, com a finalidade obter-se uma melhor acurcia nas estimativas de tamanho. O mtodo criado tem sido aplicado com sucesso, gerando estimativas com menos de 10% de erro, especialmente em contagens rpidas de sistemas implementados. A grande vantagem da contagem de PF que o mtodo fornece facilidades para reestimativas. Ento, a contagem estimada de PF refinada, conforme o conhecimento dos requisitos do projeto evolui, em marcos definidos no plano do projeto. Note que no h retrabalho, as contagens anteriores no so descartadas e sim refinadas, conforme os requisitos do projeto evoluem. Nas subsees seguintes so apresentados os mtodos para estimativas de tamanho de software pesquisados na literatura e os mtodos criados para integrar o procedimento de estimativas estabelecido para o SERPRO. 3.2.1.1. Mtodo Contagem Indicativa O Mtodo denominado Contagem Indicativa baseado nos estudos desenvolvidos pela NESMA (Netherlands Software Metrics Users Association) [NESMA, 2005]. A Estimativa de tamanho obtida, por meio da seguinte frmula: PF = 35 * N ALI + 15 * N AIE Na qual:

10

PF: Tamanho estimado do projeto de software em Pontos de Funo N ALI: Nmero estimado de Arquivos Lgicos Internos N AIE: Nmero Estimado de Arquivos de Interface Externa Um Arquivo Lgico Interno (ALI) definido como um grupo de dados logicamente relacionados ou de informao de controle2, identificado pelo usurio, mantidos dentro da fronteira da aplicao. Um Arquivo de Interface Externa (AIE) definido como um grupo de dados logicamente relacionados ou informaes de controle, identificado pelo usurio, referenciados pela aplicao, mantidos dentro da fronteira de outra aplicao [Hazan, 2000]. Para obteno das constantes 35 e 15 utilizados na frmula acima, o mtodo leva em considerao as seguintes premissas [NESMA, 2005]: A contagem baseada no nmero de Arquivos Lgicos Internos e de Arquivos de Interface Externas. A contagem considera a complexidade mdia para os tipos funcionais da APF [IFPUG, 2004]; Cada Arquivo Lgico Interno 10 PF possui 3 Entradas Externas (incluso, alterao, excluso) 12 PF, 2 Consultas Externas (consultas aos dados da tabela) 8 PF e 1 Sada Externa (1 relatrio contendo totalizaes) 5 PF; totalizando 35 PFs; Cada Arquivo de Interface Externa 7 PF possui 2 Consultas Externas (consulta e relatrio com os dados da tabela) 8 PF; totalizando 15 PFs.

importante ressaltar que o mtodo Contagem Indicativa foi reconhecido pelo IFPUG em Junho de 2003, como um mtodo potencialmente valioso para a estimativa do tamanho funcional. No entanto, isto no significa que o IFPUG endosse o mtodo como vlido, acurado ou prefervel em relao a quaisquer outros mtodos. A prtica tem mostrado que o mtodo tem superestimado o tamanho da maioria dos projetos, em relao a contagem de PF final do projeto implementado. 3.2.1.2. Mtodo Contagem Indicativa Inteligente A diretriz utilizada na criao do mtodo a seguinte: Quanto maior o conhecimento dos requisitos do projeto, maior deve ser a acurcia das estimativas. A idia integrar ao mtodo Contagem Indicativa o conhecimento dos requisitos do projeto, gerando premissas que influenciaro nas constantes 35 e 15 do mtodo, apresentado na seo anterior, visando a obteno de uma estimativa de tamanho com maior acurcia. As contribuies funcionais (nmero de PFs associados) utilizadas neste mtodo esto baseadas no Manual de Prticas de Contagem (CPM 4.2) [IFPUG, 2004]. Note que muitos sistemas, especialmente aqueles em verses iniciais no apresentaro as funcionalidades de relatrio e excluso para todos ALIs. E ainda, a prtica tem demonstrado que a maioria dos ALIs e AIEs so de complexidade Simples, e no Mdia, conforme preconizado pelo mtodo anterior. Os experimentos realizados pela autora mostraram que na maioria das vezes, o tamanho fica superestimado com a aplicao do mtodo Contagem Indicativa.

Informao de controle definida como um dado que influencia um processo elementar (funcionalidade) da aplicao sendo contada. Ou seja, a informao de controle especifica qual, quando, ou como o dado ser processado. Por exemplo, um sistema de pagamentos de pessoal deve armazenar informao de tempo que determina quando o processo elementar (funcionalidade) de pagamento de empregados ocorre.
11

Assim, fundamental que as frmulas de estimativas considerem as caractersticas de complexidade funcional especficas de cada projeto em questo. As premissas ou suposies utilizadas na gerao das estimativas devem ser documentadas, para atender a prtica relativa estimativa de tamanho, includa na rea de processo planejamento do projeto do nvel 2 segundo o CMMI. Por exemplo, suponha que um sistema hipottico XPTO a ser desenvolvido, tenha quatro tabelas pequenas (menos de 20 campos) mantidas por meio das funes de incluso, alterao e consulta (usada para a edio dos dados na alterao). Assim, considera-se que o sistema possui 4 ALIs Simples. O sistema tambm utiliza uma tabela de usurio do Sistema de Controle de Acesso, apenas para validao dos dados de acesso. Assim, considera-se que o sistema possui um AIE Simples. Note que o usurio no especificou relatrios nem funes de excluso para esta release. Se utilizarmos o mtodo contagem indicativa, a contagem seria de 155 Pontos de Funo, obtidos segundo a frmula abaixo: PF = 4 ALIs x 35 + 1 AIE x 15 O tamanho est superestimado, o sistema XPTO muito simples e no atende as premissas utilizadas na concepo do mtodo Contagem Indicativa, descritas na seo anterior. Ento para maior acurcia da estimativa, utiliza-se o conhecimento inicial do projeto para aplicar o mtodo Contagem Indicativa Inteligente. Tem-se o seguinte: Cada ALI Simples (Tabelas pequenas) - 7 PFs possui duas Entradas Externas (incluso e alterao) de complexidade desconhecida, considera-se mdias - 8 PFs (4 x 2) e uma Consulta Externa (recuperao de dados para alterao) de complexidade desconhecida, considera-se mdia 4 PFs. Note que o ndice multiplicador dos ALIs no mais 35 PF e sim 19 PF (8 +7 + 4). O AIE Simples (dados de acesso - logon e senha) - 5 PFs com uma Consulta Externa Simples (controle de acesso) com 3 PFs. Note que o ndice multiplicador dos AIEs no mais 15 PF e sim 8 PF (5 + 3). Ento, aplicando o mtodo com novos ndices, tem-se a estimativa de 84 Pontos de Funo: PF = 4 ALIs x 19 + 1 AIE x 8 3.2.1.3. Mtodo de Contagem Estimativa Este mtodo foi definido inicialmente para atender uma rea do SERPRO com muitas demandas de pequenas manutenes evolutivas. Estas demandas, muitas vezes, no possuem Arquivos Lgicos Internos (ALIs) e Arquivos de Interface Externa (AIEs) includos, alterados ou excludos. Suponha um projeto de manuteno para gerar relatrios e grficos. O tamanho estimado pelo mtodo contagem indicativa de um projeto com zero ALIs e zero AIEs seria zero Pontos Funo. O impacto seria zerar todas as estimativas (custo, esforo e prazo) e inviabilizar o plano do projeto. O mtodo de contagem estimativa visa aferir o tamanho em Pontos de Funo de maneira simplificada, quando o responsvel pelo projeto possui algum conhecimento dos requisitos do projeto. A idia mapear os requisitos descritos nas propostas comerciais ou Documentos de Viso nos tipos funcionais da Anlise de Pontos por Funo e estimar a complexidade, baseando-se nas tabelas de complexidade e contribuio funcional [IFPUG, 2004]. Os tipos funcionais so apresentados na Figura 2. As necessidades e funcionalidades especificadas para o projeto devem ser enquadradas em uma das seguintes tabelas abaixo:

12

Consultas Externas
(Sem Dados Derivados)

Fronteira da Aplicao

Sadas Externas
( Com Dados Derivados)

APLICAO
Arquivos Lgicos Internos

Entradas Externas
Funes de dados Funes transacionais

Arquivos de Interface Externa

Outra Aplicao
Arquivo Lgico Interno

Figura 2: Viso Geral dos Tipos Funcionais da Anlise de Pontos por Funo [Hazan, 2000]

Tabela A - Contagem dos Arquivos Lgicos Internos (ALIs): Banco de Dados da Aplicao (tabelas e arquivos mantidos pela aplicao) Arquivos Lgicos Internos (ALI): So grupos lgicos de dados, mantidos por meio de um processo elementar da aplicao. Note que deve-se observar a viso do usurio, no considere arquivos fsicos, arquivos de ndices, arquivos de trabalho e tabelas de relacionamento sem atributos prprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas tambm no so consideradas um ALI [IFPUG, 2004]. Questo 1: Voc est alterando a estrutura de tabelas ou arquivos (incluindo, alterando ou excluindo campos)? Voc est criando uma nova tabela ou um novo arquivo? Quantos campos possui esta tabela ou arquivo?
N ALIs Simples: N ALIs Mdio: N ALIs Complexo: Total PF da Tabela A: X 7 PF X 10 PF X 15 PF

A experincia tem mostrado que a maioria dos ALIs dos sistemas do SERPRO so Simples. Tabela B - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicaes APENAS referenciados pela aplicao que est sendo mantida (tabelas e arquivos mantidos por outra aplicao) Arquivos de Interface Externa (AIEs): so grupos lgicos de dados, mantidos por outra aplicao, apenas referenciados pelo projeto sendo desenvolvido. Note que deve-se observar a viso do usurio, no so considerados arquivos fsicos, arquivos de ndice, arquivos de trabalho, tabelas de relacionamento sem atributos prprios e entidades fracas [IFPUG, 2004]. Questo 2: Voc est alterando a estrutura de tabelas ou arquivos mantidos por outras aplicaes (incluindo, alterando ou excluindo campos)? Voc est utilizando uma nova tabela ou um novo arquivo, mantido por outra aplicao? Quantos campos possui esta tabela ou arquivo?
13

N AIEs Simples: N AIEs Mdio: N AIEs Complexo: Total PF da Tabela B:

X 5 PF X 7PF X 10 PF

A experincia tem mostrado que praticamente 100% dos AIEs dos sistemas so Simples. Tabela C - Contagem de Entradas Externas (EEs): Funcionalidades que mantm arquivos ou tabelas ou alteram o comportamento da aplicao. So considerados os processos elementares de incluses, alteraes, excluses de dados. Entradas Externas (EEs) - um processo elementar que processa dados ou informao de controle que entram pela fronteira da aplicao. O objetivo principal de uma Entrada Externa manter um ou mais Arquivos Lgicos Internos e/ou alterar o comportamento do sistema. Um processo elementar definido como a menor unidade de atividade que significativa para o usurio. O processo elementar deve ser auto-contido e deixar o negcio da aplicao em um estado consistente [IFPUG, 2004]. Questo 3: Voc est incluindo, alterando ou excluindo registros de tabelas ou arquivos (files)? Quantas funes deste tipo possui o seu projeto (conte separadamente as incluses, alteraes e excluses de dados) ? Voc est entrando com dados que alteram o comportamento da aplicao (exemplo: processamentos batch, ou processamento de informaes de controle)?
N EEs Simples: N EEs Mdia: N EEs Complexa: Total PF da Tabela C: X 3 PF X 4 PF X 6 PF

Caso no haja conhecimento da aplicao de APF ou sobre o processo elementar (funcionalidade analisada), considere as Entradas Externas como Mdias. Tabela D - Contagem de Consultas Externas (CEs): Funcionalidades que apresentam informaes para o usurio SEM utilizao de clculos ou algoritmos. So os processos elementares do tipo l - imprime, l apresenta dados, incluindo consultas, relatrios, gerao de disquetes ou CDs, downloads ... Consultas Externas (CEs): um processo elementar que envia dados ou informao de controle para fora da fronteira da aplicao. O objetivo principal de uma CE apresentar informao para o usurio atravs da recuperao de dados ou informao de controle de ALIs ou AIEs. O processamento lgico no contm frmulas matemticas ou clculos, e no cria dados derivados. Nenhum Arquivo Lgico Interno mantido durante o processamento, nem o comportamento do sistema alterado [IFPUG, 2004]. Questo 4: Voc est desenvolvendo ou alterando uma funo para apresentar informaes para o usurio: uma consulta, relatrio, browse, listbox, download, gerao de um arquivo, gerao de CD ou de disquete? Esta funo NO possui clculos ou algoritmos para trabalhar os dados referenciados nem altera um Arquivo Lgico Interno?
N CEs Simples: N CEs Mdia: N CEs Complexa: Total PF da Tabela IV:
14

X 3 PF X 4PF X 6 PF

Caso no haja conhecimento da aplicao de APF ou sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas como Mdias. Tabela E - Contagem de Sadas Externas (SEs): Funcionalidades que apresentam informaes para o usurio COM utilizao de clculos ou algoritmos. So as consultas ou relatrios com totalizao de dados, relatrios estatsticos, grficos, gerao de disquetes com atualizao log ou ndice, downloads com clculo de percentual ... Sadas Externas (SEs): um processo elementar que envia dados ou informao de controle para fora da fronteira da aplicao. O objetivo principal de uma Sada Externa apresentar informao para um usurio atravs de um processamento lgico adicional a recuperao de dados ou informao de controle. O processamento lgico deve conter no mnimo uma frmula matemtica ou clculo, ou criar dados derivados. Uma Sada Externa pode tambm manter um mais Arquivos Lgicos Internos e/ou alterar o comportamento do sistema[IFPUG, 2004]. Questo 5: Voc est desenvolvendo uma funo para apresentar informaes para o usurio: uma consulta, relatrio com totalizao de dados, etiquetas de cdigo de barras, grficos, relatrios estatsticos, download com percentual calculado, gerao de arquivo, gerao de CD, gerao de disquete com atualizao de log? Esta funo DEVE ter clculos ou algoritmos para trabalhar os dados referenciados nos arquivos lgicos OU atualizar campos (normalmente indicadores) nos arquivos?
N SEs Simples: N SEs Mdia: N SEs Complexa: Total PF da Tabela E: X 4 PF X 5 PF X 7 PF

Caso no haja conhecimento da aplicao de APF ou sobre o processo elementar (funcionalidade analisada), considere as Sadas Externas como Mdias. A Estimativa de tamanho do projeto de desenvolvimento ou manuteno em PFs pelo mtodo emprico deve ser gerada totalizando-se os PFs obtidos nas tabelas A, B, C e D, E. Embora, o mtodo contagem estimativa, que consiste em uma simplificao do mtodo de Contagem de Pontos de Funo, tenha sido apresentado inicialmente para as estimativas de manuteno evolutiva, recomenda-se fortemente sua utilizao em novos projetos de desenvolvimento visando obter maior acurcia das estimativas. 3.2.1.4. Mtodo de Estimativas Percentuais O Mtodo foi criado por Capers Jones, baseando-se em uma pesquisa feita em um Banco de Dados Histrico com cerca de 120 projetos da empresa Software Productivity Research em 1990 [SPR, 2005]. Foi observada uma correlao entre os tipos de funo da aplicao que pode ser expressa da seguinte forma: A quantidade de ALIs representa 25% do total de funes de uma aplicao A quantidade de AIEs representa 3% do total de funes de uma aplicao A quantidade de EEs representa 30% do total de funes de uma aplicao A quantidade de SEs representa 28% do total de funes de uma aplicao A quantidade de CEs representa 14% do total de funes de uma aplicao
15

Baseando-se nesta anlise estatstica, precisa-se identificar apenas a quantidade de um dos tipos de funo da aplicao para derivar a quantidade dos outros. A quantidade de um tipo de funo deve ser representada sempre em valores inteiros. Para calcular os Pontos de Funo No-Ajustados, utiliza-se complexidade funcional mdia para os tipos de funo (Arquivo Lgico Interno, Arquivo de Interface Externa, Entrada Externa, Sada Externa e Consulta Externa). Este mtodo presume um relacionamento lgico e previsvel entre variveis independentes, quando na realidade para uma determinado projeto esse relacionamento pode no acontecer. Nesses casos, medida que aumenta o grau de conhecimento da aplicao, pode-se identificar qual e em que quantidade um determinado tipo de funo ficou fora da mdia [Hazan, 1996]. Na prtica, o grau de conhecimento de um projeto na fase de planejamento no suficiente para este tipo de anlise. Segue um exemplo da aplicao do mtodo. Ao analisar uma determinada aplicao foram identificados 3 Arquivos Lgicos Internos. Utilizando o Mtodo de Estimativa por Percentual pode-se afirmar que: Se 3 ALIs = 25 % do TOTAL DE FUNES, ento TOTAL DE FUNES = 12 Se AIEs = 3% do TOTAL DE FUNES (12) , ento AIEs = 0,36 (arredonda-se para 0) Se EEs = 30 % do TOTAL DE FUNES (12) , ento EEs = 3,6 (arredonda-se para 4) Se SEs = 28 % do TOTAL DE FUNES (12) , ento SEs = 3,36 (arredonda-se para 3) Se CEs = 14% do TOTAL DE FUNES (12), ento CEs = 1,68 (arredonda-se para 2)

A partir desses valores calcula-se os PFs No-Ajustados da aplicao, conforme o seguinte:

TIPO DE FUNO ALIs AIEs EEs SEs CEs COMPLEXIDADE FUNCIONAL 3 MDIA X 10 = 30 0 MDIA X 7 = 0 4 MDIA X 4 = 16 3 MDIA X 5 = 15 2 MDIA X 4 = 8

TOTAL DE PS DE FUNO NO AJUSTADOS = 69

Em 2000, o ISBSG [ISBSG, 2003] publicou uma nova tabela de percentuais por tipo de projeto desenvolvimento, redesenvolvimento e manutenes evolutivas, baseado em seu Banco de Dados Histrico com milhares de projetos. Em Junho de 2003, o ISBSG publicou uma nova tabela substituindo a anterior apenas para projetos de novos desenvolvimento. Recomenda-se a utilizao das tabelas do ISBSG por serem dados de projetos mais atuais (Figura 3). Note que no sistema exemplo, tem-se 80 PFs estimados pelos dados do ISBSG de 2000 e 76 PFs estimados pelos dados do ISBSG de 2003 e 105 PFs estimados pelo NESMA. Este sistema hipottico utilizado como exemplo nos cursos de Anlise de Pontos de Funo possui 84 Pontos de Funo.

16

Estudo do ISBSG (Data 6 /2000)

Objeto Novo Desenvolvimento Re-desenvolvimento ALI AIE EE SE CE 22,00% 5,00% 33,50% 23,50% 16,00% 23,00% 2,50% 52,90% 17,50% 4,10%

Melhorias 15,60% 6,50% 32,70% 32,00% 13,20%

NOVO DESENVOLVIMENTO (ISBSG Junho/2003)

FUNES DE DADOS FUNES TRANSACIONAIS

ALI = 23.5% AIE = 8.1%

EE = 29.3% SE = 24.3% CE = 14.8%

Figura 3: Tabelas de Estimativas Percentuais do ISBSG [ISBSG, 2003]

O Mtodo Estimativas Percentuais deve ser aplicado somente quando se tem pouco conhecimento sobre o projeto, inviabilizando a aplicao dos mtodos de Contagem Estimativa e de Contagem Indicativa. O mtodo de Estimativas Percentuais no possui acurcia adequada, devido premissa utilizada de que todas as aplicaes possuem a mesma distribuio de funcionalidades associadas aos tipos funcionais (ALI, AIE, EE, CE, SE). Na prtica, este mtodo foi utilizado pela autora em apenas um projeto quando o conhecimento era a quantidade de Casos de Uso, por exemplo 10 Casos de Uso. Segundo os desenvolvedores, cada Caso de Uso teria 4 Entradas Externas (Incluso, Alterao, Excluso Lgica, Reincluso). Assim, tem-se o total de 40 Entradas Externas e ento o mtodo pode ser aplicado. A complexidade de cada tipo funcional foi determinada baseando-se no conhecimento do projeto, por exemplo ALIs e AIEs Simples, EEs Complexas, CEs e SEs Mdias. A acurcia da estimativa comparando-se com o realizado no foi adequada. 3.2.2. Mtodo para Gerao de Estimativas de Esforo A estimativa de esforo deve ser derivada da estimativa de tamanho, segundo o CMMI. Nesta seo descrito um mtodo para derivar as estimativas de esforo a partir das estimativas de tamanho. As Estimativas de esforo so geradas em homem_horas (HH) por um modelo de estimativas simplificado, baseando-se apenas em dois parmetros: estimativa de tamanho em PF e fator de converso HH/PF. importante ressaltar que a produtividade considerada no fator de converso (HH/PF), depende de diversos atributos do projeto, dentre outros: tamanho, plataforma de desenvolvimento, complexidade da aplicao e experincia da equipe. O fator de converso precisa ser estabelecido de acordo com as caractersticas de cada projeto. Assim, para obteno de estimativa de esforo e de prazo mais precisa sugere-se a construo de um banco de dados histrico de projetos com dados estratificados, de acordo com os atributos do projeto que a organizao considere relevante no seu contexto.

17

Para facilitar a gerao de estimativas de esforo, nesta verso do procedimento de estimativas, o mtodo utiliza como insumo seguintes parmetros: Estimativa de tamanho do projeto: Tamanho estimado do projeto em Pontos de Funo. Fator de Converso HH/PF: Este parmetro a quantidade de horas para se implantar um Ponto de Funo. Este fator deve ser recuperado de dados histricos de projetos similares ao projeto em questo.

Para os projetos nos quais no h dados histricos de projetos similares disponveis sugere-se utilizar dados de produtividade pesquisados por meio de benchmarking. A Tabela I apresenta alguns dados pesquisados na tabela de nvel de linguagem da empresa Software Productivity Research [SPR, 2005] e benchmarking com outras empresas do governo: Caixa Econmica Federal, DATAPREV e CELEPAR. A Tabela I contm fatores de converso HH classificados por linguagem de programao e trs nveis de produtividade: Baixa, Mdia, Alta. O nvel de produtividade deve ser definido baseando-se na complexidade da especificao, experincia da equipe de desenvolvimento e outros fatores que influenciem a produtividade. TABELA I: Produtividade em Pontos de Funo/hora por linguagem
Ambiente/Linguagem Mainframe COBOL NATURAL Micro e Cliente/Servidor Visual Basic Delphi ORACLE WEB/Documentos ASP Java Lotus Notes 12h 17 h 5,5 10 h 15 h 3,9 8h 12 h 3,1 8,8 h 8,8 h 13,2 h 6,8 h 6,8 h 8,8 h 5,7 h 5,7 h 6,6 h 26,4 h 13,2 h 17,6 h 8,8 h 13,2 h 6,6 h ndice Produtividade (horas/PF) Baixa Mdia Alta

Note que o nvel de produtividade Baixa est associado, dentre outros fatores, a: aplicaes complexas ou a equipes inexperientes na plataforma de desenvolvimento. J o nvel de produtividade Alta est associado a aplicaes simples, ou a equipes experientes na plataforma. O nvel de produtividade da equipe influencia diretamente nas estimativas de prazo, a produtividade Alta implica em prazos de desenvolvimento menores. Como esta tabela no est baseada em projetos reais do SERPRO, os setores que j possuem um pequeno histrico de projetos concludos tm utilizado os seus prprios ndices de produtividade. Caso, a linguagem de desenvolvimento utilizada no seja encontrada na tabela de linguagens, seleciona-se uma linguagem com produtividade similar. Caso o projeto seja desenvolvido em mais de uma linguagem de programao, define-se um ndice de produtividade - horas/PF, contemplando o percentual de cada linguagem.

18

Por exemplo, suponha um projeto de baixa complexidade, desenvolvido por uma equipe experiente na plataforma e na aplicao, utilizando as linguagens NATURAL e COBOL, sendo 20% COBOL e 80% NATURAL. Consultando a tabela I tem-se as seguintes produtividades altas: COBOL 13,2 HH/PF e NATURAL 6,6 HH/PF. Ento, para o projeto em questo, temos o seguinte fator de converso (HH/PF) para a gerao da estimativa de esforo: 0,2 x 13,2 + 0,8 x 6,6 = 7,92. As linguagens utilizadas e os percentuais devem documentadas em Premissas. importante ressaltar que a Tabela I est sendo apresentada para ilustrar o mtodo. A produtividade por linguagem pode ser bastante varivel, por exemplo segundo o banco de dados do ISBSG [ISBSG, 2003], a produtividade do JAVA varia de 10 h/PF a 60 h/PF, devido s caractersticas especficas de cada projeto de software. O processo de desenvolvimento de software utilizado na organizao tambm influncia a produtividade. Portanto, a acurcia das estimativas de esforo fortemente dependente da existncia de um banco de dados histrico, contendo dados de esforo, tamanho e atributos de produtividade de projetos concludos da organizao. O prximo passo o estudo de fatores que influenciam na produtividade para a estratificao dos dados histricos de projetos a serem coletados. A construo do banco de dados histrico deve levar em considerao poucos atributos relevantes sobre o ponto de vista de influncia na produtividade. Tem-se realizado pesquisas com as equipes de desenvolvimento nos cursos de estimativas, buscando identificar tais atributos. A Tabela II apresenta os atributos mais relevantes identificados pelos participantes de cinco turmas do treinamento Tcnicas de Estimativas ministradas nas Regionais do SERPRO. Cada turma teve uma mdia de 30 colaboradores. A pergunta colocada foi a seguinte: Quais os principais atributos exercem impacto nas estimativas de esforo e prazo? importante destacar que os cargos e nveis de experincia dos participantes foi bastante diversificado, alguns participantes possuem mais de 30 anos de empresa, outros esto no SERPRO h somente 3 anos. Os participantes realizaram o exerccio em grupos de 2 a 4 pessoas e debateram os resultados com os colegas de outros grupos e a instrutora. Os parmetros utilizados para derivao das estimativas de esforo descritos no Modelo CMMI [SEI, 2002] incluem o seguinte: Riscos Competncias e papis crticos utilizados para executar o trabalho Nveis de habilidade de gerentes e equipes necessrias para realizar o trabalho Necessidades de habilidades, conhecimento e treinamento Necessidades de facilidades (ex.: espao do escritrio e reunies, estaes de trabalho) Trabalho direto e overhead Requisitos para o produto e componentes do produto Estimativas de tamanho de artefatos e mudanas antecipadas Modelo do ciclo de vida do projeto e processos selecionados Abordagem tcnica Capacidades e ferramentas fornecidas no ambiente de engenharia Necessidades de facilidades de Engenharia

19

Nvel de segurana requerida para tarefas, artefatos, hardware, software, pessoal e ambiente de trabalho

TABELA II: Atributos que Influenciam as Estimativas de Custo, Esforo e Cronograma

Atributos Turma 1 Turma 2 Turma 3 Turma 4 Turma 5 Tamanho (PF) X X X X X Experincia da Equipe: plataforma, negcio, processo de desenvolvimento, ferramentas e X X X X X projetos similares Motivao da equipe X X X X X Rotatividade de Pessoas X Integrao (relacionamento) da Equipe Habilidade dos gestores Disponibilidade da equipe Participao de profissionais em mais de 2 projetos simultaneamente Tamanho da equipe de desenvolvimento Disponibilidade de infra-estrutura (suporte, rede, ferramentas, hardware, software) Utilizao de ferramentas automticas Reutilizao de Cdigo e Componentes Plataforma de Desenvolvimento Desenvolvimento de componentes reusveis Ambiente de Trabalho Processo de Desenvolvimento utilizado Complexidade da demanda (projeto) Clareza e Qualidade da especificao Estabilidade de Requisitos Utilizao de novas tecnologias (ex: JAVA) Imposio de prazo pelo cliente Relacionamento e Parceria com o Cliente Conhecimento do negcio pelo cliente X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Na rea de Engenharia de Software tm sido desenvolvidos muitos modelos parametrizados para apoiar as estimativas de custo, esforo e cronograma. O uso destes modelos como fonte nica de estimativa no recomendado, porque estes modelos so baseados em dados de projetos histricos que podem no ser similares aos projetos da sua organizao. Diversos modelos e/ou mtodos combinados podem ser usados para assegurar uma melhor acurcia e conseqentemente uma maior confiana na estimativa [Boehm, 2000]. 3.2.3. Mtodo para Estimativas de Prazo Aps estimar-se o esforo necessrio para o desenvolvimento do projeto, o prximo passo a derivao da estimativa de prazo. A estimativa de prazo gerada inicialmente de forma emprica considerando os insumos: tamanho e esforo estimados do projeto e tamanho da equipe para o desenvolvimento do projeto. Algumas consideraes foram feitas para as estimativas de prazo em horas e em meses:

20

1 ms possui 22 dias teis; Em uma jornada de trabalho de 8 horas/dia, a produtividade mdia do profissional no Brasil de 6 horas/dia [Jones, 1997]. Ento, utiliza-se a seguinte frmula: Prazo (em dias) = Esforo (horas) / (Tam. equipe * 6)

Figura 4: Relao entre o esforo e o prazo [PUT92]

As estimativas de prazo no so lineares com o tamanho, assim pretende-se pesquisar mais sobre o melhor tempo desenvolvimento (onde h uma melhor relao custo x benefcio de alocao de recursos e menor prazo de desenvolvimento), dado o tamanho de um projeto especfico. Jones prope uma frmula para o clculo do melhor tempo de desenvolvimento, denominado Td e de Regio Impossvel (RI) de desenvolvimento (Figura 4), descrito em [Jones, 1998]. Na Regio Impossvel (RI), a adio de mais recursos ao projeto no implicar em reduo no prazo. O clculo da regio impossvel j est sendo utilizado para apoiar a confeco de cronogramas. Note que a curva (Figura 4) mostra que quanto menor o prazo almejado para a concluso do projeto, maior ser o esforo requerido [PUT92]. O aumento do esforo para reduzir o prazo acontece atravs da realizao de horas-extras e da incluso de pessoal adicional. A reduo de prazo tem um limite, como demonstra a regio impossvel da Figura 4 . O mtodo ainda no considera o clculo da Regio Impossvel. O mtodo utilizado apenas para se ter uma idia inicial da viabilidade do projeto. O cronograma do projeto deve ser construdo baseando-se nas atividades do projeto e na disponibilidade dos papeis para execuo delas. As ferramentas de gesto de projetos, tais como MS Project, tm sido utilizadas para apoiar na confeco do cronograma.

21

3.2.4. Mtodo para Estimativas 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.

3.2.5. Estimativas de Recursos Computacionais Crticos Alm das estimativas de tamanho, esforo, prazo e custo, o modelo CMMI tambm pede que as estimativas de Recursos Computacionais Crticos sejam documentadas. Visando a padronizao da documentao destas estimativas, sugere-se a utilizao da planilha, ilustrada na Figura 5. Deve-se considerar recursos computacionais crticos dos ambientes de: desenvolvimento, teste e produo. Exemplos de recursos computacionais crticos incluem o seguinte: memria, espao em disco capacidade da rede, potncia de processadores, potncia das estaes de trabalho e capacidade dos perifricos [SEI, 2002].

Nome do Recurso Computacional Crtico

Responsvel pela Data (*) Custo Descrio Disponibilizao Limite Parmetros D/P/H (OPCIONAL)

Total Nome do Recurso, hardware: micro, perifrico, expanso de memria, rea em disco, banda de rede, etc Parmetros: Caractersticas do recurso, como: quantidade, perfil, configurao, etc (*) D:Recurso para ambiente de desenvolvimento; P: recurso para ambiente de produo; H: recurso para amb. Homologao Custo: Preencher este campo quando for possvel a definio dos custos envolvidos com o recurso computacional

Figura 5: Modelo para Estimativas de Recursos Computacionais Crticos

22

4. Discusso e contribuies
Alguns experimentos iniciais tm sido realizados com os mtodos de estimativas de tamanho propostos. Os mtodos tm demonstrado uma boa preciso com menos de 10% de erro, sem levar em considerao as mudanas de requisitos no decorrer do desenvolvimento. Inicialmente, recomendou-se a utilizao do mtodo Contagem Indicativa (NESMA) devido a sua simplicidade, no entanto na prtica as estimativas de tamanho, na maioria das vezes ficaram muito acima do tamanho real. Isto ocorreu por causa das premissas utilizadas na concepo do mtodo, considerando a complexidade mdia para as funes de dados, que costumam ser simples; e ainda duas consultas externas para os Arquivos de Interface Externa, que costumam ser usados apenas para validao de dados, sem nenhuma funcionalidade de consulta especfica. Alguns sistemas de consultas gerenciais possuem funes de consulta aos AIEs, no entanto estas consultas gerenciais, normalmente so Sadas Externas e tambm a frmula original da Contagem Indicativa no pode ser aplicada. Assim, o mtodo Contagem Indicativa Inteligente criado tem se mostrado adequado para as contagens rpidas, exceto para os casos de manutenes evolutivas, onde no h arquivos lgicos includos ou com a estrutura alterada. Nestes casos, recomenda-se a utilizao do Mtodo de Contagem Estimativa. O mtodo de estimativas percentuais pode distorcer bastante a contagem se o projeto a ser dimensionado no se encaixar no modelo (premissas) proposto pelo mtodo. Embora, a literatura proponha a calibrao dos percentuais para o projeto a ser estimado [UNISYS, 1995]. Na prtica, isto torna-se extremamente complicado para ser realizado no incio do projeto, quando h pouco conhecimento sobre o mesmo. Assim, devido a subjetividade do mtodo, este no foi incorporado no procedimento de estimativas do SERPRO. O mtodo de Contagem Estimativa tem sido bastante utilizado nas estimativas. Alm deste, proporcionar uma melhor acurcia nas estimativas, este facilita as reestimativas de tamanho que devem ocorrer no acompanhamento do projeto. Outro ponto a ser considerado nas Estimativas de Tamanho o Fator de Ajuste da Contagem de Pontos de Funo que influencia os Pontos por Funo no Ajustados em +/35%. O valor do fator de ajuste, que varia de 0,65 a 1,35, indica a funcionalidade geral fornecida para o usurio da aplicao, considerando as 14 Caractersticas Gerais do Sistema (CGS) que estimam a magnitude das funcionalidades gerais da aplicao. Cada caracterstica possui descries associadas que ajudam a determinar o nvel de influncia da caracterstica. Os nveis de influncia esto definidos em uma escala de 0 (nenhuma influncia) a 5 (forte influncia) [Hazan, 2000]. Embora o fator de ajuste no tenha atualizaes relevantes desde a dcada de 80, no seja reconhecido pela ISO [Dekkers, 2003] e algumas empresas tenham desconsiderado o fator de ajuste nas contagens. A opo do SERPRO foi seguir o manual CPM 4.2 [IFPUG, 2004], considerando o clculo fator de ajuste tambm nas estimativas de tamanho. Assim, a empresa est utilizando os Pontos de Funo Ajustados nas estimativas de tamanho desde a etapa de planejamento. A experincia tem demonstrado que sistemas batch ficam com um Fator de Ajuste Baixo (entre 0,8 e 0,9), em Sistemas mainframe on-line ou micro stand alone o fator de ajuste fica em torno 1 no exercendo impacto na contagem dos Pontos de Funo no ajustados, os Sistemas Cliente Servidor e Web possuem fator de ajuste mais altos (entre 1,1 a 1,2). Alguns sistemas Cliente Servidor mais complexos tiveram fator de ajuste maior que 1,25. O AulaNet [EDUWEB, 2003], ambiente de software baseado na Web, desenvolvido Laboratrio de Engenharia de Software - LES - do Departamento de Informtica da PUC-Rio tem um fator de ajuste de 1,27. O Fator de Ajuste do AulaNet foi aferido pela autora, especialista em contagem de Pontos de Funo, por meio de entrevistas com a equipe de desenvolvimento da aplicao. Tambm importante destacar que a aferio do fator de ajuste tem apoiado a elicitao e a anlise (reviso) de requisitos nofuncionais e at mesmo de requisitos funcionais.

23

As estimativas de esforo tm sua preciso dependente da existncia de dados histricos de projetos similares. Neste momento, o SERPRO est em fase de construo de um Banco de Dados Histrico de produtividade. O Banco de Dados histrico ser construdo partir da contagem de PF de projetos concludos e obteno de dados de esforo dos projetos em questo. A estratgia da empresa estratificar os projetos, inicialmente por linguagem de desenvolvimento, tipo do projeto e experincia da equipe. Tambm pretende-se realizar Benchmarking no ISBSG (International Software Benchmarking Standards Group) [ISBSG, 2003] para comparar a produtividade do SERPRO com o mundo. O modelo de estimativa de esforo apresentado, que multiplica o tamanho de projeto em Pontos de Funo pela produtividade (nmero de horas para produzir 1 Ponto de Funo) denominado Modelo simplificado de estimativas [Vazquez, 2004]. Este modelo tem se apresentado adequado. No entanto, com a construo do Banco de Dados Histrico, pretende-se utiliz-lo na calibragem dos parmetros do COCOMO II [Boehm, 2000]. A idia comparar as estimativas geradas pelo modelo simplificado e pelo COCOMO, visando apoiar os lderes de projetos na confeco de cronogramas mais realistas especialmente para os projetos dos novos clientes, onde a experincia no pode ajudar. As estimativas de prazo no so lineares com o tamanho, assim pretende-se pesquisar mais sobre o melhor tempo desenvolvimento, dado o tamanho de um projeto especfico. Jones prope um mtodo para clculo de Tempo de timo de Desenvolvimento e de Regio Impossvel de desenvolvimento, descrito em [Jones, 1998]. Este mtodo foi implantado na planilha de documentao de estimativas do SERPRO apenas para efeito de anlise. Este modelo pode no ser apropriado para a organizao, devido a este mtodo ser bastante emprico e no ter sido calibrado utilizando dados histricos de projetos da organizao. importante destacar que o COCOMO II [Boehm, 2000] tambm prope frmulas para o clculo da Regio Impossvel (RI) e do Tempo timo de Desenvolvimento (Td), baseando-se no tamanho do projeto e de outros parmetros. Estes parmetros referem-se calibragem, que deve ser realizada com dados histricos de projetos da organizao, referentes ao contexto para o qual as estimativas sero elaboradas e ao mapeamento do modelo, que leva em considerao a seqncia de atividades pertinentes ao ciclo de vida do projeto, as caractersticas do produto, o processo de desenvolvimento, caractersticas da equipe de desenvolvimento e outros fatores relativos ao projeto a ser estimado [Aguiar, 2004]. Na subseo seguinte apresentada uma proposta de integrao dos mtodos de estimativas propostos de acordo com o CMMI no processo de planejamento de projetos (Planning Game) do Extreme Programming (XP).

4.1. Integrando o Processo de Estimativas Proposto com o XP

O planejamento em Extreme Programming (XP) focaliza em como uma equipe de desenvolvedores pode ser otimamente conduzida. Assim, o planejamento realizado para assegurar que a equipe est sempre trabalhando na coisa mais importante que precisa ser feita; coordenar efetivamente com outras pessoas e responder rapidamente aos eventos inesperados. Os planos so baseados em estimativas feitas por indivduos. Quando eventos inesperados ocorrem, os planos devem ser revisados. Qualquer tcnica de planejamento deve fornecer visibilidade, tal que qualquer pessoa envolvida no projeto possa realmente ver quanto falta e quanto j foi feito do projeto. Isto significa que precisa-se criar marcos de acompanhamento que representem claramente o progresso do projeto [Beck, 2001]. O propsito do plano inicial verificar se o projeto faz sentido como um todo. Normalmente, estes planos (estudo de viabilidade) so feitos antes de envolver o pessoal tcnico. Para elaborao do plano so necessrias estimativas de tempo (cronograma) e de custos (oramento). O XP sugere que no sejam gastas muitas horas no primeiro plano.
24

O processo de planejamento XP confia claramente na separao de papis de pessoas do negcio e pessoas de software. Isto assegura que as pessoas do negcio (analistas de negcios) sejam responsveis pelas decises de negcio e as pessoas tcnicas (programadores) tomem as decises tcnicas. A estimativa uma deciso tcnica que deve ser realizada pelos programadores. A escolha de prioridade entre as funcionalidades e caractersticas no funcionais uma deciso de negcio realizada pelas pessoas de negcio que conhecem o mercado e podem utilizar a experincia em aplicaes similares. Note que o planejamento constitui uma maneira de descobrir quais requisitos (ou stories) devem ser construdos em cada iterao. Uma story a unidade (pedao) de funcionalidade em um projeto XP. A definio de uma story requer uma comunicao eficaz entre clientes e desenvolvedores. Os clientes definem a story e os desenvolvedores estimam a story. As estimativas devem ser realizadas no incio do projeto, isto assim que se inicia a redao da a story. Existem trs abordagens chaves para uma estimativa efetiva: Mantenha simples Utilize o que aconteceu no passado Aprenda com a experincia

O desenvolvedor deve ser capaz de estimar quanto tempo levar para construir a story em questo. Beck [Beck, 2001] sugere uma maneira simples para estimar-se o tamanho de uma story, a saber : Procurar uma story similar que tenha sido entregue; Assumir que a nova story consumir a mesma quantidade de esforo; Se no achar um story similar, ento procurar uma story duas vezes maior ou menor, e ento dividir ou multiplicar o esforo.

Assim, o seguinte preconizado: Voc apenas pode estimar da experincia. Voc tem experincia? Convide um amigo que tenha, chame um programador para conversar. Note que o processo apresentado fortemente baseado na experincia em projetos anteriores. A equipe de desenvolvimento discute cada story, considera quanto tempo leva para implementar, e decide sobre a estimativa. Assim, caso a equipe no possua experincia em projetos similares, esta no possuir suporte cientfico para negociar o tamanho mximo de uma da story possvel de ser construda em uma iterao. Segundo Beck [Beck, 2001], as duas principais reas de incerteza consideradas no desenvolvimento do plano do projeto so as seguintes: velocidade da equipe e tamanho das stories. Assim, sugere-se a utilizao da mtrica de Pontos de Funo (PF) e do Mtodo de Contagem Estimativa, descrito em 3.2.1.3 para identificao do tamanho da story na fase de planejamento do projeto. A velocidade da equipe de desenvolvimento apenas poder ser identificada com acurcia, caso exista um banco de dados histrico com projetos similares. No entanto, as frmulas para o clculo de regio de impossvel, descritas na literatura [Jones, 1998] e [Putnam, 1992], podem ajudar na definio do tamanho ideal da story (em Pontos de Funo) possvel de ser construda em cada iterao. O XP, assim como o CMM, pressupe a utilizao do plano do projeto para acompanhar e avaliar o progresso, que demonstrado por meio da entrega de cdigo integrado e testado que implementa uma story. O processo de planejamento do XP tambm considera as reestimativas peridicas das stories para incorporar informaes adicionais como dependncias entre as stories ou tecnologia [Beck, 2001]. Portanto, torna-se importante um processo simplificado de estimativas gil para apoiar o processo de planejamento do XP.

25

5. Estudo de Caso
Esta seo tem como propsito apresentar um estudo de caso utilizando os mtodos de estimativas propostos na seo 3. Com a finalidade de apresentar o procedimento de estimativas de forma simplificada, esta seo descreve um sistema hipottico (parte de um sistema real). Suponha que o setor de treinamento de uma empresa solicitou um sistema, denominado STREINA com as necessidades e funcionalidades, descritas na Tabela III. Note que necessria uma anlise dos requisitos do projeto documentados no Documento de Viso antes da aplicao do Mtodo de Contagem Estimativa, visando uma melhor acurcia das estimativas. Na prtica, o analista de negcios entrevistado pelo profissional responsvel pelas estimativas. TABELA III: Funcionalidades do Sistema de Treinamentos (STRENA)
Necessidade 1 Controlar capacitaes Id Func. F 1.1 F1.2 F 1.3 F 1.4 F 1.5 F 1.6 F 1.7 F 1.8 F 1.9 F 1.10 Descrio das Funcionalidades/atores envolvidos Cadastrar evento de capacitao Tcnico Planejar evento de capacitao Tcnico Planejar cronograma de capacitao Tcnico Consultar cronograma de capacitao Tcnico Consultar eventos de capacitao por data e local Tcnico Consultar detalhes de um evento de capacitao Tcnico Informar resultado da avaliao de um evento de capacitao Tcnico Informar acompanhamento de comunidade capacitada (avaliao ps-treinamento) Participantes do treinamento Consultar acompanhamento de comunidade capacitada Tcnico Gerar Consultas Gerenciais (Grficos e Relatrios) de Capacitao Gerente Benefcio Crtico

Note que algumas funcionalidades que no aparecem explicitamente no Documento de Viso , cujas funcionalidades esto representadas na Tabela III, por exemplo como Controle de Acesso sero consideradas na estimativa. Conforme descrito no Procedimento de Estimativas, o primeiro passo estimar-se o tamanho do projeto. Vamos utilizar o mtodo de contagem estimativa. ALI: Usurios Simples 7 PF

26

3 EEs: Cadastro Usurios (Incluso, Alterao e Excluso) Simples 9 PF 2 CEs: Lista de Usurios, Consultar Usurios Simples 6 PF EE: Alterar Senha Simples 3 PF ALI: Capacitao Mdio 10 PF 2 EEs: Cadastrar evento de Capacitao (Incluso e Alterao) Media 8 PF CE: Lista de Eventos Capacitao Simples 3 PF SE: Consultar evento de capacitao Mdia 5 PF 2 EEs Planejar Evento de Capacitao (Planejar e Alterar Plano) Mdia 8 PF CE: Consultar Plano Evento Capacitao Mdia 4 PF 2 EEs Planejar Cronograma de Capacitao (Criar e Alterar Cronograma) Mdia 8 PF SE: Consultar Cronograma Evento Capacitao Mdia 5 PF SE: Consultar eventos de capacitao por data e local Mdia 5 PF CE: Consultar Detalhes de Evento de Capacitao Complexa 6 PF 3 EEs: Cadastrar participantes no evento: (Incluso, Alterao/Excluso) 2Mdias/1 Simples 11 PF CE: Consultar Participantes cadastrados no evento Mdia 4 PF SE: Enviar para e-mail para participao do evento Mdia 5 PF 2 EEs: Informar resultados da avaliao de um evento de capacitao Simples 6 PF 5 SEs: Consulta Avaliao de um evento de capacitao (1 relatrio e 4 grficos) Simples 20 PF SE: Enviar e-mail de notificao para avaliao do evento Mdia 5 PF 2 EE: Informar acompanhamento de comunidade capacitada (Informar e alterar dados de acompanhamento) Mdia - 8 PF CE: Consultar dados de acompanhamento inseridos - Mdia 4 PF SE: Consultar Consolidada acompanhamento comunidade capacitada Simples 4 PF SE: Consultas Gerenciais ( 2 grficos e 2 relatrios) Simples 16 PF

Totalizando o nmero de PFs, tem-se 170 PFs no ajustados. Suponha que o fator de ajuste deste projeto seja de 1,10. Assim, temos 187 Pontos de Funo Ajustados estimados. De posse da estimativa de tamanho, procede-se com estimativa de esforo. Este projeto ser desenvolvido em JAVA por equipe experiente na plataforma. Como o projeto de complexidade simples e pequeno (< 200 PFs), ser utilizada a produtividade 12 horas/PF. Assim, a estimativa de esforo de 2244 HH (homens_hora). O prximo passo a estimativa de prazo, considerando-se a produtividade de 6 h/dia, o ms com 22 dias teis e uma equipe com 3 recursos (incluindo desenvolvimento e gesto) tem-se: 5,7 meses estimados para realizao do projeto. Como 10% do projeto j foi realizado (modelagem do negcio), ento o prazo restante de 5,2 meses.
27

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.

6. Concluses e Recomendaes para Trabalhos Futuros

Com a adoo de modelos de Qualidade de Software, tais como CMM ou CMMI, tornafundamental a existncia de um procedimento para a gerao e documentao das estimativas a serem utilizadas no acompanhamento do projeto de software. Os mtodos descritos neste trabalho foram definidos em 2002, no entanto sua utilizao efetiva iniciou-se em junho de 2003 aps a realizao dos treinamentos e mentoring. Os experimentos realizados com os mtodos de estimativas de tamanho tm demonstrado uma acurcia razovel, menos de 10 % de erro, sem levar em considerao as mudanas significativas de requisitos no decorrer do desenvolvimento, as quais acarretam em uma reestimativa do projeto, conforme preconizado no CMMI. A definio do procedimento de estimativas, contendo os mtodos descritos neste trabalho foi um passo importante na implantao da rea chave de planejamento de projeto no SERPRO. Os treinamentos e mentorings de Mtodos para Estimativas de ProJetos de Software possibilitou a utilizao do procedimento definido pelas equipes de desenvolvimento. Note que o modelo CMM no descritivo, apresenta O que fazer. Os mtodos pesquisados e implementados mostram Como fazer as prticas associadas s estimativas do CMM visando uma certificao ou aderncia ao modelo. A utilizao dos mtodos no trivial. Alm do curso bsico de estimativas, as equipes solicitam o treinamento de APF. E ainda, aps os cursos tericos para a apresentao dos conceitos, necessrio mentoring com as equipes. Os principais benefcios da utilizao de um procedimento de estimativas so: maior acurcia das estimativas geradas e melhor relacionamento com o cliente. A utilizao da mtrica Pontos de Funo para determinar o tamanho e das frmulas de clculo de Regio Impossvel e do tempo timo de desenvolvimento, propiciam a utilizao efetiva de um processo de desenvolvimento incremental (baseado na RUP), onde o cliente estabelece as prioridades e a equipe de desenvolvimento negocia a melhor forma de atender as necessidades dos clientes. Tambm importante destacar que vrios clientes do SERPRO tambm tem participado dos cursos de Estimativas e Anlise de Pontos de Funo. Isto facilita bastante a negociao de funcionalidades/cronograma. Como recomendaes para trabalhos futuros, sugere-se a anlise de mtodos estatsticos para o tratamento dos dados histricos de produtividade para as estimativas de custo e de esforo. A validao das frmulas para o clculo do tempo timo de desenvolvimento (Td) regio impossvel (RI) tambm deve ser realizada, para que estas venham incorporar o mtodo de estimativas de prazo. Outro ponto que deve ser considerado nas estimativas como o percentual de evoluo de requisitos impacta no tamanho do projeto. Tambm devem ser realizados experimentos, tratando os ndices de produtividade (homem-hora/PF) em cada ambiente, e ainda como cada fator de impacto na produtividade levantado nos treinamentos do SERPRO, Modelo CMMI e COCOMO II influenciam nos ndices de produtividade.

28

Referncias bibliogrficas
[ABNT, 1994] ABNT - Associao Brasileira de Normas Tcnicas. NBR ISO 9001/1994: Sistemas da qualidade - Modelo para garantia da qualidade em projeto, desenvolvimento, produo, instalao e servios associados. Rio de Janeiro, ABNT, 1994. ABNT - Associao Brasileira de Normas Tcnicas. NBR ISO/IEC 12207 - Tecnologia de informao - Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998. AGUIAR. M. Pontos de Funo ou Pontos por Caso de Uso? Como Estimar Projetos Orientados a Objetos. http://www.bfpug.com.br/islig-rio/ Downloads/pf_ucp.pdf 2002 AGUIAR. M. Estimando os projetos com COCOMO II. 2004.
http://www.metricas.com.br/Downloads/Estimando_Projetos_COCOMO_II.pdf

[ABNT, 1998]

[Aguiar, 1992]

[Aguiar, 2004] [Andrade, 2004]

ANDRADE, E. Pontos de Caso de Uso e Pontos de Funo na Gesto de Estimativa de Projetos de Software Orientados a Objeto. Tese de Mestrado, Universidade Catlica de Braslia (UCB) , Fevereiro/2004. BECK, K. Extreme Professional, 2000. Programming Explained. Addison-Wesley

[Beck, 2000] [Beck, 2001] [Boehm, 2000] [Cunha, 2003]

BECK, K & FOWLER, M. Planning Extreme Programming. AddisonWesley, 2001. BOEHM, B. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, 2000. CUNHA, G.; ALMEIDA, E. Estimativa de projetos com base em Casos de Uso. Simpsio Internacional de Melhoria de Processos de Software (SIMPROS), Recife, 2003 pp.53-60.

[Damodaram, 2004] DAMODARAN, M & WASHINGTON, A. Estimation using use case points. Computer Science Program. Texas Victoria: University of Houston. http://www.bfpug.com.br/Artigos/UCP/DamodaranEstimation_Using_Use_Case_Points.pdf [Dekkers, 2001] [Dekkers, 2002] [Dekkers, 2003] DEKKERS, C. Function Points and Use Cases - Wheres the Fit?. www.qualityplustech.com/FPUseCases-files/frame.htm DEKKERS, C. How Function Points Support the Capability Maturity Model Integration. Crosstalks, February 2002 pp 21-24. DEKKERS, C. Measuring the logical or functional Size of Software Projects and Software Application. Spotlight Software, ISO Bulletin May 2003 pp10-13. EDUWEB: http://www.eduweb.com.br/portugues/elearning_tecnologia.asp FILHO, J. Conceitos Preliminares em Homologao de Software. http://www.informal.com.br/artigos/a16022000001.htm FIORINI, S.; STAA, A.v.; BAPTISTA, R.; Engenharia de Software com CMM. Brasport ;1998.
29

[EDUWEB, 2003]

[Filho, 2000]
[Fiorini, 1998]

[Forsberg, 1997]

FORSBERG,K. & MOOZ, H. System Engineering Overview. Software Requirements Engineering, Second Edition, IEEE Computer Society Press, Washington, 1997 pp.44-72. GARMUS, D. & HERRON, D. Function Point Analysis: Measurement Practices for Successful Software Projects. Addison-Wesley, 2001. GLASS, R.L.; Facts and Fallacies of Software Engineering; New York, NY: Addison-Wesley; 2003. HAZAN, C. Anlise de Pontos de Funo. Projeto Final - Universidade do Estado do Rio de Janeiro (UERJ), 1996. HAZAN, C. Metodologia para o Uso de Indicadores na Gerncia de Projetos de Desenvolvimento de Software. Tese de Mestrado, IME, Maio 1999. HAZAN, C. Anlise de Pontos por Funo: Uma Abordagem Gerencial. Congresso Nacional da SBC, XIX Jornada de Atualizao em Informtica (JAI); Julho 2000 - Volume 2, pp 287-326. HAZAN, C. Anlise de Pontos por Funo: Uma ferramenta na implantao do Modelo CMM. Tema - a Revista do SERPRO, seo tematec, Jan/Fev 2003. HUMPHREY, W. Managing the Software Process. Addison-Wesley, 1990. IFPUG. Counting Practices Manual. Version 4.2, 2004. www.ifpug.org. ISBSG. International Software Benchmarking Standards Group. www.isbsg.org.au JONES C. Assessment and Control of Software Risks. Prentice Hall, 1994. JONES, C. Applied Software Measurement, Assuring Productivity and Quality. Prentice Hall, Second Edition, 1997. JONES, C. Estimating Software Costs. McGraw-Hill, 1998. LONGSTREET, D. Use Cases and Function www.softwaremetrics.com/Articles/usecases.htm Points.

[Garmus, 2001] [Glass, 2003] [Hazan, 1996] [Hazan, 1999]

[Hazan, 2000]

[Hazan, 2003]

[Humphrey, 1990] [IFPUG, 2004] [ISBSG, 2003] [Jones, 1994] [Jones, 1997] [Jones, 1998] [Longstreet, 2002] [Kan, 1995] [Karner, 1993]

KAN, S. Metrics and Models in Software Quality Engineering. Addison Wesley ;1995 pp. 148,149. KARNER, G. Use Case Points - Resource Estimation for Objectory Projects, Objective Systems SF AB, University of Linkping, Sucia, 1993. KRUCHTEN, P. The Rational Unified Process - An Introdution. AddisonWesley, 2000. pp167,168. MASTERS, S. Keys to Conducting Collaborative Assessments. SIMPROS, September 2000. pp 17. MCT. Ministrio da Cincia e Tecnologia. Evoluo de Certificados ISO 9000 no Brasil, 2004. http://www.mct.gov.br/Temas/info/Dsi/qualidad/certiso.htm

[Kruchten, 2000] [Masters, 2000]

[MCT, 2004a]

30

[MCT, 2004b]

MCT. Ministrio da Cincia e Tecnologia. Qualificao CMM no Brasil, 2004.

http://www.mct.gov.br/Temas/info/Dsi/qualidad/CMM.htm MELI, R. Early and Extended Function Point: A new method for Function Points Estimation. IFPUG - Fall Conference - September 1997 - Arizona, USA. NESMA - Netherlands Software Metrics Association. Indicative Function Point Count: www.nesma.org.nl OLIVEIRA S. T. Ferramentas para o Aprimoramento da Qualidade. GRIFO, 2 Edio; 1996 pp 29 a 34. ORR, K. CMM Versus Agile Development: Religious Wars and Software Development. Cutter Consortium, www.cutter.com/freestuff/apmreport.htm, 2002. PAULK, M. Extreme Programming from a CMM perspective. IEEE Software, Novembro 2001. PMI- Project Management Institute. A guide to the project management body of knowledge. Syba: PMI Publishing Division, www.pmi.org, 2000. PRESSMAN, R. S. Software engineering: a practitioners approach. 5th Edition, New York: McGraw-Hill, 2000. PROBASCO, L. Dear Dr. Use Case: What About Function Points and Use Cases?. Rational Software, Rational Edge, 2002. PUTNAN, L. & MYERS, W. Measures for Excellence Reliable Software On Time, Within Budget, Prentice-Hall, 1992. SMITH, J. The Estimation of Effort Based on Use Cases. Rational Software White Paper, 2000. SEI. Capability Maturity Model Integration (CMMISM). Version 1.1 CMU/SEI-2002-TR-012; Maro 2002. SPR. Software Productivity Research. www.spr.com Standish Group. The Chaos Report (1994). www.standishgroup.com Standish Group. The Chaos Report (2001). www.standishgroup.com Standish Group. The Chaos Report (2003). www.standishgroup.com UNISYS. Anlise de Pontos de Funo. Apostila Curso de Anlise de Pontos de Funo da UNISYS, 1995. VAZQUEZ et al. Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software. Editora rica Ltda, So Paulo, pp17-35, segunda edio, 2004.

[Meli, 1997]

[NESMA, 2005] [Oliveira, 1996] [Orr, 2002]

[Paulk, 2001] [PMI, 2000]

[Pressman, 2000] [Probasco, 2002] [Putnan, 1992] [Smith, 2000] [SEI, 2002] [SPR, 2005] [Standish, 1994] [Standish, 2001] [Standish, 2003] [UNISYS,1995] [Vazquez, 2004]

31