Planejamento de Custos Desenvolvimento Softwares

PLANEJAMENTO DE CUSTOS EM AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE ORIENTADOS ORGANIZAO
Monalessa Perini Barcellos
TESE
SUBMETIDA
AO
CORPO
DOCENTE
DA
COORDENAO
DOS
PROGRAMAS DE PS-GRADUAO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAO.
Aprovada por:
________________________________________________ Profa. Ana Regina Cavalcanti da Rocha, D. Sc.
________________________________________________ Prof. Guilherme Horta Travassos, D. Sc.
________________________________________________ Profa. Kthia Maral de Oliveira, D. Sc.
________________________________________________ Prof. Ricardo de Almeida Falbo, D. Sc.
RIO DE JANEIRO, RJ-BRASIL JUNHO DE 2003
BARCELLOS, MONALESSA PERINI Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados Organizao [Rio de Janeiro] 2003 VIII, 208 p., 29,7 cm (COPPE/UFRJ, M. Sc., Engenharia de Sistemas e Computao, 2003) Tese Universidade Federal do Rio de Janeiro, COPPE 1. Planejamento de Custos 2. Ambientes de Desenvolvimento de Software Orientados Organizao I. COPPE/UFRJ II. Ttulo (srie)
ii
Resumo da Tese apresentada COPPE/UFRJ como parte dos requisitos necessrios para a obteno do grau de Mestre em Cincias (M. Sc) PLANEJAMENTO DE CUSTOS EM AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE ORIENTADOS ORGANIZAO Monalessa Perini Barcellos
Junho/2003
Orientadores: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos
Programa: Engenharia de Sistemas e Computao A indstria de software vem produzindo softwares cada vez mais complexos e maiores, com exigncia de tempo e custos cada vez menores e com necessidade de qualidade cada vez mais acurada. Entregar um produto com qualidade, dentro do prazo e custos esperados hoje um grande desafio para as organizaes. Fatores como esses impulsionam o interesse, por parte das organizaes, pela estimativa e controle dos custos dos projetos de software. Nas ltimas dcadas muitas pesquisas tm sido realizadas no sentido de desenvolver modelos para estimar custos que resultem em estimativas o mais prximo possvel dos custos reais dos projetos. A utilizao dos conceitos e prticas de gerncia do conhecimento tem se mostrado eficiente no apoio ao planejamento de custos de projetos. Para apoiar o processo de gerncia do conhecimento em organizaes que desenvolvem software, surgiu o conceito dos Ambientes de Desenvolvimento de Software Orientados Organizao, que apoiam a atividade de Engenharia de Software em uma organizao, fornecendo o conhecimento acumulado e relevante para esta atividade, assim como dando suporte ao aprendizado organizacional em Engenharia de Software. Este trabalho apresenta uma abordagem para Planejamento de Custos de projetos nesses ambientes, baseada nas normas NBR ISO 10006, ISO/IEC DTR 16326, no guia PMBOK (Project Management Body of Knowledge), nos princpios da gerncia do conhecimento e nos modelos paramtricos COCOMO II e Anlise de Pontos de Funo.
iii
Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requeriments for the degree of Master of Science (M. Sc)
COSTS PLANNING IN ENTERPRISE-ORIENTED SOFTWARE DEVELOPMENT ENVIROMENT
Monalessa Perini Barcellos
June/2003
Advisors: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos
Departament: Systems and Computing Engineering Software industry must produce software more complex and larger in less time and costs reduced no loss quality. Delivering a quality software product with expected cost and on time is today a great challenge for the organizations. These issues increase organizations interest in software projects costs estimation and control techniques. During the last decades a lot of researches have been accomplished aiming the development of cost estimation models to produce estimations close a possible to projects real cost. Beside these techniques, Knowledge Management concepts have demonstrated to be efficient to support cost planning. Enterprise-Oriented Software Development Environment support the Software Engineering activities in an organization, providing the accumulated and considerable knowledge for these activities and supporting the learning organization in Software Engineering. This work presents an approach for projects Costs Planning in Enterprise-Oriented Software Development Environment, based on standards such as NBR ISO 10006, ISO/IEC DTR 16326, in the guide PMBOK (Project Management Body of Knowledge), in concepts of Knowledge Management and parametric models COCOMO II and Function Point Analysis.
iv
Ao meu pai, meu heri. minha filha, Luiza, o grande amor da minha vida. Ao meu esposo e companheiro Alex Sandro.
Agradecimentos
Ao meu pai, pelo incio de tudo... Por ter me ensinado o verdadeiro valor do estudo e do conhecimento. minha filha, Luiza, por ter vindo ao mundo durante o desenvolvimento deste trabalho mostrando-me como limites podem ser superados. minha filha, Luiza, mais uma vez, por me presentear com seus lindos sorrisos, carinhos e brincadeiras nos momentos de cansao na caminhada deste trabalho. Ao meu esposo, Alex Sandro, por mais do que qualquer pessoa, acreditar em meu potencial, oferecer o ombro sempre que precisei e por vibrar comigo a cada etapa concluda. minha irm, Dbora, pela companhia, cumplicidade e ajuda nos momentos mais difceis. amiga Luciana, pela amizade, carinho, pacincia, incentivo, troca de conhecimentos e pela fora e companheirismo de todos os momentos. Ao Svio, por seu empenho e esforo, sem os quais este trabalho no teria se concretizado. Ao Gleison, Karina, Lilian e Smulo pelo auxlio com seus conhecimentos e por sua boa vontade em colaborar sempre (mesmo que nas madrugadas). Catarina por me acolher durante as viagens. Ao amigo Francisco Rapchan pelo incentivo, apoio espiritual e colaborao com sua experincia e conhecimento. Ao Blaschek pela oportunidade de trabalhar sob sua gerncia e pelo carinho e apoio no primeiro ano deste trabalho. Aos participantes da pesquisa que colaboraram prontamente minha solicitao. Aos meus orientadores pelos ensinamentos, direcionamentos e pela pacincia nessa jornada. Aos professores membros da banca por prestigiarem meu trabalho com sua presena. Ana Paula e funcionrios administrativos pela prestatividade. CAPES pelo apoio financeiro. A Deus... pela vida... e por este momento!
vi
Contedo
1. Introduo............................................................................................................................. 1
1.1 Motivao.........................................................................................................................................................1 1.2 Objetivo da Tese ..............................................................................................................................................3 1.3 Organizao da Tese........................................................................................................................................4
2. Planejamento de Projetos e Estimativas de Custos ........................................................ 5

2.1 Introduo........................................................................................................................................................5 2.2 Estimativas de Custos ......................................................................................................................................6 2.2.1 Modelos Paramtricos ..............................................................................................................................7 2.2.2 Estimativas baseadas em Analogias .......................................................................................................9 2.2.2.1 A Base de Dados Histricos ..........................................................................................................11 2.2.3 Julgamento de Especialistas...................................................................................................................17 2.2.4 Outras Questes sobre a Realizao de Estimativas ............................................................................20 2.3 Descrio de Algumas Tcnicas de Estimativas de Custos ........................................................................22 2.3.1 A Tcnica Anlise de Pontos de Funo...............................................................................................22 2.3.2 O Modelo COCOMO II .........................................................................................................................27 2.4 Consideraes Finais .....................................................................................................................................30
3. Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA ........................................................................................................................................ 31

3.1 Introduo.......................................................................................................................................................31 3.2 Gerncia do Conhecimento ...........................................................................................................................32 3.2.1 Gerncia do Conhecimento em Engenharia de Software....................................................................33 3.2.2 Conhecimento ........................................................................................................................................36 3.2.3 Memria Organizacional.......................................................................................................................38 3.2.4 Processo de Gerncia de Conhecimento ..............................................................................................39 3.3 A Estao TABA ..........................................................................................................................................40 3.4 Ambientes de Desenvolvimento de Software Orientados Organizao (ADSOrg) ...............................41 3.4.1 Planejamento de Projetos em Ambientes de Desenvolvimento de Software Orientados Organizao......................................................................................................................................................43 3.5 Consideraes Finais .....................................................................................................................................44
4. Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados Organizao ..................................................................................................... 46

4.1 Introduo.......................................................................................................................................................46 4.2 Planejamento de Custos em AD SOrg...........................................................................................................47 4.3 Processo de Gerncia de Tempo e Processo de Gerncia de Custos .........................................................50 4.3.1 Processo de Gerncia de Tempo............................................................................................................51 i. Identificar as Dependncias entre as Atividades do Projeto.................................................................52 ii. Estimar a durao das Atividades do Projeto com Abordagem Top-down ........................................53 iii. Estimar a durao das Atividades do Projeto com Abordagem Bottom-up.......................................54 iv. Elaborar o Cronograma do Projeto......................................................................................................54 v. Controlar o Cronograma do Projeto......................................................................................................55 4.3.2 Processo de Gerncia de Custos ............................................................................................................56 i. Estimar os Custos do Projeto .................................................................................................................56 ii. Elaborar Oramento do Projeto ...........................................................................................................57 iii. Controlar Oramento do Projeto..........................................................................................................57 4.4 A Abordagem de Planejamento de Custos para a Estao TABA .............................................................58 4.4.1 Processo de Gerncia de Tempo............................................................................................................60 4.4.2 Processo de Gerncia de Custos ............................................................................................................66 4.5 Consideraes Finais .....................................................................................................................................70
vii
5. A Ferramenta CustPlan .................................................................................................... 71

5.1 Introduo.......................................................................................................................................................71 5.2 Caracterizao de Projetos na Estao TABA.............................................................................................71 5.3 Pesquisa de Dependncias Usuais entre as Atividades do Processo de Desenvolvimento .......................77 5.4 A Ferramenta CustPlan .................................................................................................................................81 5.5 Consideraes Finais ...................................................................................................................................110
6. Consideraes Finais e Perspectivas Futuras ..............................................................111

6.1 Consideraes Finais ..................................................................................................................................111 6.2 Perspectivas Futuras ...................................................................................................................................113
Referncias Bibliogrficas ...................................................................................................115 Anexo 1 - Realizao de Estimativas utilizando Anlise de Pontos de Funo e Pontos de Caso de Uso .......................................................................................................................130
A1.1 O Processo de Contagem de Pontos de Funo .....................................................................................130 A1.2 O processo de contagem de Pontos de Caso de Uso .............................................................................137 A1.3 Exemplo de Contagem utilizando Anlise de Pontos de Funo .........................................................141
Anexo 2 - Realizao de Estimativas utilizando COCOMOII.......................................145

A2.1 A2.2 A2.3 A2.4 A2.5 A2.6 Os Modelos do COCOMO II ..................................................................................................................145 Os Fatores de Equilbrio do COCOMO II ............................................................................................146 Os Direcionadores de Custos do COCOMO II .....................................................................................147 O Processo de Realizao de Estimativas utilizando COCOMO II ...................................................150 Exemplo de estimativas utilizando COCOMO II ..................................................................................167 Consideraes ..........................................................................................................................................170
Anexo 3 - Notao dos Diagramas de Workflow..............................................................171 Anexo 4 - Pesquisa de Dependncias Usuais entre as Atividades do Projeto .............174
A4.1 A4.2 A4.3 A4.4 A4.5 A4.6 Introduo.................................................................................................................................................174 Planejamento da Pesquisa .......................................................................................................................174 Avaliao dos Dados Obtidos .................................................................................................................183 Resultados Obtidos ..................................................................................................................................195 Lies Aprendidas ...................................................................................................................................199 Consideraes Finais ...............................................................................................................................200
Anexo 5 - Modelo de Classes ...............................................................................................201

A5.1 Caraterizao de Projetos ........................................................................................................................201 A5.2 Planejamento de Tempo e Custos ...........................................................................................................203 A5.3 Diagramas de Classes ..............................................................................................................................204
viii
Captulo 1 Introduo
Este captulo apresenta as principais questes que motivaram a realizao deste trabalho, o objetivo da pesquisa e a organizao da Tese.
1.1
Motivao
As ferramentas e tcnicas utilizadas no desenvolvimento de novas aplicaes de software no tm sido suficientes para garantir o sucesso dos projetos. Problemas significativos ainda tm sido relatados. Observa-se, por exemplo, no aderncia de baselines1, no cumprimento de oramentos, elaborao de estimativas incorretas ou incoerentes e um nmero praticamente inaceitvel de projetos cancelados, estagnados ou que no tenham atendido s expectativas dos clientes. Tendo a modernidade tecnolgica garantido a evoluo dos recursos de apoio ao desenvolvimento de sistemas, como explicar tal fato? Talvez no seja to difcil revelar e perceber que tal fato se d pois muitos praticantes utilizam a tecnologia disponvel, mas pouco conhecem os processos que ela apia. Com isso, dificilmente seriam capazes de executar os processos sem a tecnologia de apoio, pois apenas utilizam o processo da tecnologia em si e no o processo genrico no qual a tecnologia se baseou para ser capaz de prover apoio automatizado (MURCH, 2000). Esse fato pode contribuir com os problemas anteriormente citados. Para os executivos de negcio, o nmero de projetos sem sucesso um dos pontos mais frustrantes do desenvolvimento de software, pois resulta em oportunidades perdidas e insatisfao de clientes. Assim sendo, alm de outros fatores de qualidade, importante que um produto de software seja desenvolvido com os recursos e cronograma previstos. O sucesso de um projeto depende muito da habilidade do gerente em estimar seus custos e prazos no incio de seu desenvolvimento e control-los ao longo do processo de desenvolvimento (CRUZ, 1998).
1
Dados quantitativos que caracterizam o ponto de partida de um projeto (JONES, 2000).
Introduo ________________________________________________________________________________________
Quando o tema em pauta so os custos e prazos do projeto, a definio e utilizao de bons processos para sua gerncia de grande importncia. O objetivo de processos para gerncia de custos e prazos fornecer diretrizes que devem ser seguidas para a realizao das estimativas de um projeto e, com seu desenvolvimento, direcionar as atividades de acompanhamento e controle, de forma a auxiliar na proximidade entre os valores estimados e os reais. Sendo assim, a utilizao de processos para gerncia de custos e prazos bem definidos pode auxiliar na realizao de estimativas com menor margem de erro, indicar caminhos de acompanhamento e controle e, dessa forma, tornar menos frequentes e menores os desvios dos projetos, favorecendo o sucesso de um maior nmero de projetos de software. Porm, apenas concluir um projeto no prazo e oramento previstos no mais indica ser este um projeto de sucesso. necessrio agregar valor organizao. Esse valor pode ser representado pelo conhecimento adquirido pela organizao no desenvolvimento do projeto. Para trabalhar com a captura e utilizao de conhecimento devem ser utilizados os conceitos e prticas da gerncia do conhecimento. A gerncia do conhecimento tem sido reconhecida pelas organizaes em geral como um importante fator de sucesso, uma vez que as constantes mudanas de mercado, tecnolgicas e sociais exigem rpidas tomadas de deciso e atualizaes em procedimentos, mtodos e at estruturas organizacionais (OLEARY e STUDER, 2001; ABECKER et al., 2001). A gerncia do conhecimento trata a descoberta, aquisio, criao, disseminao e utilizao de conhecimento, contribuindo para o constante aprendizado organizacional. O crescente interesse pela gerncia do conhecimento chegou recentemente
indstria de software e alguns pesquisadores tm trabalhado com a aplicao de seus conceitos em organizaes que desenvolvem e mantm software (MARKKULA, 1999; VILLELA et al., 2001a; MENDONA et al., 2001; WANGENHEIM et al., 2001; RUS e LINDVALL, 2002). O conceito de Ambientes de Desenvolvimento de Software Orientados Organizao (ADSOrg), em cujo contexto este trabalho se insere, surgiu da necessidade de gerenciar o conhecimento organizacional adquirido ao longo de projetos de software. Esses ambientes apoiam a atividade de Engenharia de Software em uma organizao, fornecendo
Introduo ________________________________________________________________________________________
o conhecimento acumulado e relevante para essa atividade e dando apoio ao aprendizado organizacional em Engenharia de Software (VILLELA et al., 2001a). O conhecimento para gerncia de custos e prazos de projetos de software um exemplo de conhecimento presente em uma organizao que desenvolve e/ou mantm software. Durante o planejamento de um projeto de software realizado o planejamento de custos, no qual esforo, prazo e custos propriamente ditos so planejados para o projeto em questo. Quanto maior a experincia e conhecimento do gerente do projeto, maior ser sua capacidade de realizar um bom planejamento de custos. Ambientes de Desenvolvimento de Software Orientados Organizao se propem a apoiar as atividades de Engenharia de Software, possibilitando a gerncia do conhecimento que pode ser til aos engenheiros de software ao longo dos projetos de uma organizao (VILLELA et al., 2000). Assim, o conhecimento de gerncia de custos e tempo adquirido em projetos da organizao uma das reas de conhecimento que deve ser gerenciada por esses ambientes. O trabalho aqui descrito est inserido nesse contexto.
1.2
Objetivo da Tese
O principal objetivo deste trabalho estabelecer um meio de auxiliar a elaborao do Plano de Custos e cronograma do Projeto, baseando-se no uso de tcnicas e prticas utilizadas na Engenharia de Software e no aprendizado da organizao por meio de suas experincias passadas, atravs da gerncia do conhecimento. Para que esse objetivo seja alcanado, foram definidos processos de gerncia de custos e gerncia de tempo, tendo como base a gerncia do conhecimento organizacional, que deve auxiliar a realizao das estimativas de custos e prazos e facilitar o acompanhamento destes ao longo do processo de desenvolvimento, atravs da
disponibilizao do conhecimento acumulado em projetos anteriores, armazenado no Repositrio de Conhecimento Organizacional de um Ambiente de Desenvolvimento de Software Orientado Organizao.
Introduo ________________________________________________________________________________________
1.3
Organizao da Tese
Esta dissertao composta por cinco captulos, alm desta Introduo. No Captulo 2, Planejamento de Projetos e Estimativas de Custos, so apresentados estudos na rea de planejamento de custos e resultados de comparaes entre vrias tcnicas obtidos em pesquisas realizadas em projetos de empresas de vrias partes do mundo. So tambm descritos dois modelos paramtricos para estimativas de custos: Anlise de Pontos de Funo e COCOMO II. No Captulo 3, Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA, so apresentadas as principais caractersticas de Ambientes de Desenvolvimento de Software Orientados Organizao, os conceitos de gerncia do conhecimento e a estrutura da Estao TABA. No Captulo 4, Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados Organizao so apresentados os processos de gerncia de custos e gerncia de tempo propostos neste trabalho e a abordagem proposta para gerncia de custos e gerncia de tempo em Ambientes de Desenvolvimento de Software Orientados Organizao. No Captulo 5 descrita a ferramenta CustPlan, desenvolvida na Estao TABA, para apoiar os processos de gerncia de custos e gerncia de tempo definidos no captulo 4. No Captulo 6 so apresentadas as concluses, contribuies da Tese e perspectivas de trabalhos futuros.
Captulo 2 Planejamento de Projetos e Estimativas de Custos

Neste captulo so apresentados alguns conceitos relacionados a Estimativas de Custos e relatos de pesquisas realizadas nesse contexto. Tambm so apresentadas duas tcnicas de estimativas: Anlise de Pontos de Funo e COCOMO II.
2.1 Introduo Atualmente, profissionais que ocupam cargos de gerncia de projetos tm assumido um importante papel quando o assunto em foco so projetos de software. Assim como os lderes na indstria de Tecnologia de Informao, os gerentes de projeto criam estratgias e orquestram cuidadosamente a elaborao de planos de ao que sejam capazes de gerenciar o desenvolvimento de projetos de maneira eficiente (MURCH, 2000). A funo de gerncia pode ser conceituada como o conjunto de atividades e tarefas realizadas por uma ou mais pessoas, com o objetivo de planejar e controlar as atividades de outras para atingir um objetivo ou completar uma atividade que no pde ser atingido ou completada de forma independente. PRESSMAN (2001) afirma que a gerncia de projetos de software envolve planejamento, acompanhamento e controle de pessoas, processos e eventos que ocorrem medida em que o software evolui de um conceito inicial a uma implementao operacional. Dentre as atividades da gerncia determinadas por PRESSMAN (2001), destaque especial merece a de planejamento, que deve ser realizada antes da execuo propriamente dita do projeto. Para realizar um projeto necessrio que haja o planejamento de quais aes devero ser tomadas, como elas devero ser realizadas e qual o contexto em que elas esto inseridas. O planejamento do projeto engloba o planejamento do processo de desenvolvimento, recursos humanos, hardware e software necessrios, custos
relacionados, cronograma, qualidade do produto e do processo, documentao e riscos envolvidos.
Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________
Todo planejamento realizado deve ser registrado em um documento chamado Plano do Projeto. Cada item a ser analisado e planejado origina um plano especfico, como por exemplo: Plano de Custos, Plano de Riscos, Plano de Recursos Humanos e Plano da Qualidade. O conjunto de todos os planos especficos que envolvem o projeto constitui o Plano do Projeto. O Plano do Projeto o elemento base para o processo de gerncia do projeto, pois se comporta como o ponto inicial do controle, onde as informaes bsicas iniciais so registradas e, com o desenvolvimento do projeto, sero modificadas e executadas. Seu objetivo prover um conjunto de diretrizes que habilite o gerente a realizar estimativas razoveis e anlises satisfatrias das variveis pertinentes ao projeto, como por exemplo qualidade, riscos, prazos e custos, facilitando o desenvolvimento do projeto dentro das expectativas estabelecidas pelas partes envolvidas. Embora existam vrias abordagens para o processo de software, todas elas enfatizam a importncia da realizao do planejamento. DONALDSON e SIEGEL (2000), por exemplo, localizam o Plano do Projeto em uma viso figurativa da gerncia de projetos de software atravs das fases do desenvolvimento de software, definindo-as de forma macroscpica como o que, como, construo e uso. Baseado nessas macrofases, os autores propem um modelo genrico para a Engenharia da Informao e um ciclo de vida genrico para desenvolvimento de software, onde se insere o Plano do Projeto. Para os autores, o planejamento deve ser realizado nas fases o que e como e o acompanhamento e controle seriam executados nas fases construo e uso.
2.2 Estimativas de Custos Quando os computadores comearam a ser utilizados em escala comercial os custos com software representavam menos de 20% dos custos totais com os sistemas de computao. Com o tempo, essa relao foi se alterando e os custos com software passaram a representar uma fatia muito mais expressiva dos custos totais. Esse crescimento impulsionou o interesse, por parte das organizaes, pela medio e controle dos custos dos projetos de desenvolvimento de software. Entregar um produto no prazo, dentro do oramento e com um nvel de qualidade, no mnimo, aceitvel, tornou-se um fator crtico para muitas organizaes. Subestimar os
6
custos de um projeto de software pode comprometer a qualidade do produto a ser entregue. Por outro lado, superestim-los pode levar perda de competitividade no mercado. BROOKS (1975), na dcada de 70, j lanava a reflexo: - Como um projeto atrasa um ano? - Um dia de cada vez... . Segundo ele, constatadamente, a maioria dos fracassos de projetos se d devido a atrasos de cronogramas mal elaborados e estimativas mal realizadas. Em resposta a essa questo, nas ltimas duas dcadas, muitos estudos tm sido realizados na rea de estimativas de custos para projetos de software. As abordagens existentes para a realizao das estimativas de projetos de software so: (i) modelos paramtricos; (ii) analogia de estimativas; e, abordagens so descritas a seguir. (iii) julgamento de especialistas. Essas
2.2.1 Modelos Paramtricos

Os modelos paramtricos utilizam caractersticas do projeto em modelos matemticos e/ou algoritmos para calcular as estimativas do projeto. Alguns desses modelos, j considerados clssicos como o COCOMO II (evoluo do COCOMO 81) (BOEHM et al., 2000; TRINDADE et al., 1999) e a Anlise de Pontos de Funo (GARMUS e HERRON, 2001) tm sua aplicabilidade constatada em experincias e prticas de muitas organizaes, registradas em artigos e outras publicaes2. Outras tcnicas tambm tm sido estudadas e analisadas. RUNESON et al. (2000) avaliaram as tcnicas MARK II PF, Full Function Point e Bispoke. JEFFERY et al. (2000) realizaram experincias com Estimativas por Analogias, Regresso OLS, Stepwise, ANOVA, CART e Regresso Robusta. Analisando algumas tcnicas existentes e considerando-as relativamente de difcil utilizao, YAMAURA e KIKUNO (1999) propuseram o TCE Top-down Cost Estimation , apresentando-o como rpido, fcil e capaz de gerar estimativas acuradas. O TCE composto por trs passos bsicos que so realizados consultando-se tabelas fornecidas pela tcnica e ajustadas para cada organizao. Os passos bsicos so: (1)
2
Essas tcnicas sero descritas na seo 2.3.
identificar a classificao funcional do software e verificar o custo padro para este tipo de software; (2) ajustar o custo padro considerando as estratgias de negcio do projeto, como por exemplo: a prioridade manter a qualidade do projeto ou a prioridade manter a data final; e, (3) reajustar o custo considerando caractersticas do ambiente de desenvolvimento. HASTINGS e SAJEEV (2001) realizaram uma anlise dos principais mtodos de estimativas e medio e propuseram um novo mtodo, baseado em vetores. Na verdade, so dois novos mtodos: VSM Vector Size Measurement e VPM Vector Prediction Model. O primeiro tem como objetivo medir o tamanho do software e classificar os sistemas de software. O segundo, por sua vez, estima o esforo necessrio ao desenvolvimento do projeto. Os autores utilizaram as consideraes de Fenton (FENTON, 1991) quando este afirma que o tamanho do software funo, entre outros atributos, de sua funcionalidade e complexidade. Fazendo uso dessa considerao, o VSM traa um vetor que representar a magnitude do sistema em funo de um plano cartesiano funcionalidade x
complexidade. Diversas frmulas e relaes foram propostas para obter o traado do vetor e realizar sua interpretao para o projeto em anlise. O VPM tem como objetivo estimar o esforo provvel para o desenvolvimento do projeto. Para tal, os requisitos do sistema devem estar representados em uma linguagem especial, chamada ASL (Algebraic Specification Language). Aps essa especificao, podem ser utilizados mtodos baseados em produtividade, regresso linear ou modelos de custos para que, baseando-se em suas frmulas e relaes, seja possvel calcular o valor da estimativa do esforo. MIRANDA (2001), por sua vez, realizou uma proposta para que seja possvel obter uma noo mais exata do tamanho do projeto. Uma entidade do sistema escolhida como referncia e todas as demais sero mensuradas em funo da original, atravs da utilizao de uma matriz de julgamento. Esse autor ressalta, ainda, que o problema da realizao ad hoc de estimativas no acadmico, pois as tcnicas existem. O problema prtico, pois elas no so utilizadas, gerando oramentos e cronogramas questionveis. Nos ltimos vinte anos, muitos estudos foram realizados comparando-se as tcnicas de estimativas de custos para software. Nos anos 80, modelos paramtricos foram
utilizados (BOEHM, 1981; PUTNAM, 1978) e comparados em conjuntos de dados de projetos de diversos tamanhos e ambientes. Algumas das principais concluses foram que esses modelos geravam resultados fracos quando aplicados sem calibrao em outros ambientes. Kemerer (BRIAND et al., 1999), por exemplo, usou 15 projetos de aplicaes para negcios e comparou quatro modelos: SLIM (BOEHM, 1981), COCOMO (BOEHM, 1981), Estimacs (PUTNAM, 1978) e Anlise de Pontos de Funo (GARMUS e HERRON, 2001). A margem de erro encontrada foi consideravelmente alta (85%), o que levou reavaliao das tcnicas testadas, surgimento de novas tcnicas e desenvolvimento de procedimentos de calibrao para os modelos paramtricos, permitindo que cada organizao possa utilizar valores diferentes para as constantes e outros parmetros dos modelos, adquirindo-os atravs da anlise de dados e projetos da prpria organizao, o que diminuiu consideravelmente a margem de erro das estimativas realizadas pelos modelos paramtricos. O COCOMO II (BOEHM et al., 2000) um bom exemplo de modelo que permite calibrao para cada organizao em particular. Nos anos 90, os estudos tambm envolveram modelos no paramtricos, baseados em algoritmos inteligentes e analogias, que so descritos a seguir.
2.2.2 Estimativas baseadas em Analogias

As estimativas baseadas em analogias so mtodos no paramtricos que utilizam dados histricos de outros projetos para realizar as estimativas para o projeto corrente. As analogias so realizadas levando-se em considerao caractersticas comuns aos projetos. So frequentemente utilizadas nas estimativas de custos totais do projeto quando existe uma quantidade limitada de informaes detalhadas sobre ele, como por exemplo nas fases iniciais. Tambm so utilizadas para apoiar a distribuio do tempo e custos totais do projeto em suas fases, mdulos e/ou atividades (PMBOK, 2000). Muitos estudos de caso tm sido desenvolvidos para analisar a utilizao da analogia de estimativas e os resultados tm sido consideravelmente positivos. SHEPPERD e SCHOFIELD (1997), por exemplo, realizaram comparaes avaliando estimativas por analogias e stepwise regression. Seus resultados mostraram que estimativas por analogia superavam stepwise regression . Em 299 projetos de 17
organizaes foi possvel constatar que os modelos baseados em algoritmos inteligentes e analogias superavam os paramtricos, sendo o COCOMO e a Anlise de Pontos de Funo os que apresentaram melhores resultados, dentre os modelos paramtricos. OHLSSON e WOHLIN (1999) analisaram a realizao das estimativas de esforo utilizando analogias observando 26 projetos realizados entre 1996 e 1998 . O objetivo era produzir valores que pudessem ser utilizados pelos estudantes do Departamento de Sistemas de Comunicao da Lund University como referncia para estimarem seus projetos. Os autores dividiram os projetos em oito partes, que foram utilizadas para realizar as estimativas. So elas: requisitos, testes, subtestes, processos, fluxos, sadas, entradas e sinais. Observando as partes, o esforo e o nmero de membros envolvidos nos projetos realizados em 1996 e 1997 os autores realizaram analogias, anlises e regresses matemticas e propuseram valores mdios para o esforo para cada parte do projeto. Em seguida, utilizando outros modelos de estimativas, foram realizadas as estimativas para os projetos de 1998. Tambm foram realizadas estimativas para os projetos de 1998 utilizando-se os valores propostos pelos autores em 1997 considerando as partes do projeto. Essas estimativas foram, ento, comparadas e, na maior parte dos casos, as estimativas realizadas considerando-se as partes do projetos e os valores propostos pelos autores atravs das analogias foram mais acuradas. Os autores constataram que nos casos em que essas estimativas no eram melhores, a margem de erro encontrada era consideravelmente alta, o que os fez concluir que um estudo mais profundo sobre as partes que foram utilizadas para dividir os projetos deveria ser realizado, bem como repetir a pesquisa considerando mais projetos. MENDES e COUNSELL (2000) desenvolveram um estudo sobre a realizao de estimativas de esforo utilizando analogias em projetos Web. Nesse estudo, os autores utilizaram a ferramenta ANGEL (ANaloGy softwarE tooL), desenvolvida pela Bournemouth University, que capaz de realizar analogias para um projeto comparando suas caractersticas com as caractersticas de projetos armazenados em uma base de dados. Para realizar as analogias, foram utilizados dois conjuntos de dados contendo dados empricos de projetos de desenvolvimento de software para Web. As analogias foram realizadas considerando o nmero de arquivos HTML da aplicao, o nmero de arquivos HTML que seriam reutilizados de outras aplicaes, o nmero de links da aplicao e o grau de
10
interao dos arquivos da aplicao. Os resultados obtidos nesse estudo mostraram que a analogia de estimativas fornecia estimativas prximas dos valores praticados para os projetos.
2.2.2.1 A Base de Dados Histricos
Observando os resultados dos estudos que realizaram analogias com dados de projetos anteriores, a necessidade de armazenar em uma base de dados histricos as informaes a respeito de projetos que j foram concludos tornou-se evidente. Os valores realmente praticados em cada projeto podem, ento, ser utilizados como pontos de apoio para as estimativas dos novos projetos atravs das tcnicas de analogias. Diversos autores registraram os resultados de seus estudos para verificar a necessidade da base de dados histricos. MIRANDA (2001), por exemplo, apresenta os resultados dos estudos de Albert L. Lederer e Jayesh Prasad, que mostram que utilizar dados histricos e documentar o projeto so atividades capazes de produzir estimativas muito melhores do que a intuio permite. ENGELKAMP et al. (2000) argumentam que algumas tcnicas de estimativas so muito complexas, o que acaba exigindo um conhecimento muito apurado de seus usurios. Sua proposta prover mecanismos e tcnicas de estimativas de custo, esforo e prazo que possam ser mais acessveis aos gerentes de projeto. Dessa forma, a necessidade de um banco de dados contendo dados das experincias anteriores em projetos por ele vislumbrada. Um projeto piloto na sd&m AG (Software Design & Management), uma empresa de desenvolvimento de aplicaes tcnicas e sistemas de informao da Alemanha, originou uma proposta completa da base de experincias contendo: como iniciar uma base de experincias, quais seus parmetros (o que armazenar de cada projeto identificadores, variveis quantitativas, variveis qualitativas e classificadores) e como avaliar os dados armazenados. BASILI et al. (2001a) reforam a efetividade da utilizao de dados histricos, considerando primitivas as metodologias de desenvolvimento aplicadas e propondo como soluo a utilizao de produtos, processos e experincias da prpria organizao, por
11
meio da gerncia do conhecimento, atravs da base de dados histricos de projetos. Como experincia, realizou um trabalho na multinacional Q-Labs, onde um sistema de gesto de experincias foi implementado com base no conceito da Fbrica de Experincias. BASILI et al. (2001b) tratam no trabalho realizado na Q-Labs a idia de uma generalizao do conceito da Fbrica de Experincias para organizaes que no so desenvolvedoras de software, refletindo sobre o momento em que a base de dados
histricos ainda est vazia, ou seja, quando nenhuma experincia foi registrada. Enfatiza a necessidade de no apenas armazenar os dados na base, relatando a dificuldade de analislos e de reutiliz-los. Outra experincia trata de um estudo realizado na ESA (European Space Agency) (BRIAND et al.,1999; BRIAND et al., 2000), mostrando que uma organizao possuindo uma base de dados histricos prpria, com informaes dos projetos por ela desenvolvidos, tem menos chance de cometer erros ao realizar as estimativas de custos, analisando essas informaes, do que uma organizao que utiliza uma base de dados histricos multiorganizacional, isto , com dados de projetos desenvolvidos por diversas organizaes. Ainda assim, as organizaes que acessam uma base de dados multiorganizacional tm possibilidade de cometer uma margem menor de erros do que aquelas que no realizam qualquer tipo de registro dos valores praticados em seus projetos. A funcionalidade de uma base de dados prpria para cada organizao tambm destacada por MOSES et al. (2000) quando os autores realizam estudos sobre como refinar as estimativas de esforo em pequenas empresas de desenvolvimento de software. Eles utilizam uma abordagem Bayesiana e observam as diferenas entre pequenas e grandes empresas, destacando como os dados da grande empresa seriam inteis para estimar projetos na pequena empresa, devido s particularidades do domnio dos problemas e solues. ANGELIS et al. (2001), por outro lado, defendem que, em alguns casos, a utilizao de uma base de dados multiorganizacional pode ser mais expressiva que uma base prpria. Por exemplo, quando uma organizao de software inicia suas atividades, ela ainda no tem experincias prprias para reutilizar, ento, utilizar dados de outras empresas pode ser til. Quando uma empresa muda o domnio de suas aplicaes ou insere uma nova tecnologia, recorrer a uma base multiorganizacional pode auxili-la nas
12
estimativas do novo projeto. Os autores realizaram um estudo considerando uma base com dados coletados pelo International Software Benchmarking Standards Group. Essa base continha dados de 789 projetos categorizados de acordo com sua natureza (rea de
negcios, domnio organizacional, uso de certas ferramentas e mtodos, dentre outras). Os autores propuseram um modelo estatstico para realizao de estimativas de projetos, que foi proposto baseando-se em analogias realizadas na base de dados da pesquisa. Os resultados obtidos mostraram que o modelo proposto eficiente, porm os autores
ressaltam que o estudo deve ser repetido e que trabalhar com dados categorizados exige que muitos estudos sejam realizados antes de considerar o modelo realmente eficiente. Tomando como referncia o universo considerado pelo estudo, a utilizao da base de dados multiorganizacional mostrou-se eficiente. Dada a importncia da base de dados histricos preciso considerar que em um determinado momento ela estar vazia. Como proceder para inserir os primeiros dados nela? E, de posse dos dados dos projetos da base de dados histricos, como agrup-los? Como identific-los como similares para que possam ser base de apoio para as estimativas de futuros projetos? necessrio traar uma caracterizao para os projetos. Essa caracterizao deve ser capaz de responder s questes bsicas para a definio dos perfis de projetos e, dessa forma, agrup-los como similares. Alguns autores tm registrado pesquisas e resultados que auxiliam a responder esses questionamentos. Em resposta ao questionamento de armazenamento inicial de dados histricos, BOEHM (2000) apresenta diversas razes para a utilizao do COCOMO II. A principal delas a considerao de que a maioria dos mtodos de estimativas s so realmente eficientes quando utilizados com base em dados de projetos anteriores (mtodos no paramtricos). Esse fato faz com que Boehm considere esses mtodos ineficientes, pois no so capazes de prover meios para estimar o primeiro projeto a ser armazenado na base de dados histricos, o que o COCOMO II faz, sem restries. Essa capacidade atribuda ao COCOMO II foi obtida devido a seus fatores de calibrao j serem fornecidos com base no estudo de dezenas de projetos com os mais diferentes perfis. Uma outra forma de iniciar o armazenamento dos dados na base de dados histricos utilizar o julgamento de especialistas, que ser descrito na prxima seo (2.2.3).
13
Aps os dados estarem armazenados na base, deve-se estabelecer critrios de caracterizao para que os dados possam ser acessados e utilizados na analogia de estimativas. Segundo IDRI e ABRAN (2001), o quesito similaridade entre projetos de software no tem sido assunto de estudos profundos mesmo sendo frequentemente utilizado em estimativas de esforo para o desenvolvimento de software baseadas na analogia entre projetos. Entretanto, a complexidade dos mdulos e experincia dos programadores so citados como fatores que descrevem projetos de software. Alm disso, relatada a metodologia do COCOMO e COCOMO II que utilizam 17 atributos para descrever um projeto. Tais atributos referenciam questes de tamanho do software, forma de desenvolvimento, caractersticas do produto, da equipe, de tecnologia e restries em geral. Os mesmos poderiam, ento, ser considerados como pontos importantes para caracterizar os projetos e, posteriormente, agrup-los como similares. JONES (2000) considera que h sete tipos bsicos de informao para traar caracterizao de projetos que so comuns entre avaliaes, benchmarks e estudos de baseline, sendo elas: o pas para o qual o projeto se destina, a cidade, a indstria, a natureza do projeto (novo desenvolvimento, melhoria (adio de funes), adaptao para atender a novas regulamentaes, reparo de defeitos, melhoria de desempenho, migrao para nova plataforma, nacionalizao, reengenharia, atualizao em massa (por exemplo: Euro e Ano 2000) ou hbrido), o escopo do projeto (subrotina, mdulo, prottipo descartvel ou prottipo evolutivo), a classe do projeto (aplicao para uso corporativo desenvolvida com recursos internos, aplicao para uso corporativo desenvolvida com a contratao de terceiros, aplicao para uso corporativo que atende a padres militares, aplicao shareware ou freeware, aplicao para uso externo via Internet, aplicao para ser distribuda junto com dispositivos fsicos, aplicao comercial para venda ou leasing, aplicao desenvolvida sob contrato de encomenda para terceiros, aplicao desenvolvida sob contrato de encomenda para o governo ou aplicao desenvolvida sob contrato de encomenda para instituio militar) e o tipo do projeto (no procedural, web applet, aplicao batch, ou aplicao interativa) MENZIES e SINSEL (2000), por sua vez, retratam a necessidade de considerar a precedncia, flexibilidade de desenvolvimento, anlise arquitetural ou resoluo dos riscos,
14
coeso da equipe de desenvolvimento, maturidade do processo, atributos do produto (confiabilidade requerida, tamanho da base de dados, complexidade do produto, nvel de reuso, requisitos de documentao), atributos da plataforma (restrio de tempo de execuo, armazenamento da memria principal, volatilidade da plataforma), atributos da equipe (capacidade do analista e do programador, continuidade do programador, experincia do analista, experincia com a plataforma), atributos do projeto (experincia com a linguagem e ferramentas, uso de ferramentas de software, desenvolvimento distribudo), confiabilidade do sistema e presses de cronograma. KURTZ (2001) alega que alm das caractersticas sugeridas pelos demais autores, de grande importncia considerar caractersticas de investimento e da organizao que atua no desenvolvimento do projeto. Estabelecidos os critrios de caracterizao dos projetos preciso definir o mecanismo que indicar quais projetos so similares. SCHOFIELD e SHEPPERD (1995) usam a similaridade para estimar o esforo de desenvolvimento de software baseado em analogia e propem uma abordagem na qual os projetos similares so encontrados medindo-se a distncia Euclidiana em um espao n-dimensional onde cada dimenso corresponde a uma varivel (um critrio de caracterizao). A limitao desta abordagem que ela no trabalha com variveis medidas em escalas nominais (exemplo: domnio de aplicao). MENDES e COUSELL (2000) utilizaram em seus estudos a ferramenta ANGEL (ANaloGy softwarE tooL), desenvolvida pela Bournemouth University e j citada anteriormente, que tambm utiliza distncia Euclidiana para verificar a analogia entre os projetos. IDRI e ABRAN (2001), por sua vez, propem utilizar um modelo baseado em lgica Fuzzy para definir as mtricas de similaridade dos projetos de software e ento superar a limitao de no poder trabalhar com atributos de projeto medidos em escalas nominais . PRIETO-DIAZ (1991) props a classificao facetada , buscando tornar possvel a recuperao de componentes de software baseada em similaridade. Segundo o autor, selecionar componentes similares um problema de classificao e o esquema de classificao crucial no processo de reutilizao de componentes. Seu esquema pode ser
15
adaptado de forma a tornar possvel a recuperao de projetos de software baseada em similaridade. Outra questo relativa base de dados histricos que deve ser considerada que, algumas vezes, os dados presentes podem estar incompletos. Isso pode ocorrer devido ao no registro dos dados no momento de alimentar a base de dados ou por problemas relacionados integridade, procedimentos e segurana da base de dados. A ausncia de alguns dados pode comprometer as estimativas realizadas por analogias. Para tratar casos de dados incompletos foram desenvolvidas Missing Data Techiniques (MDT) (FORD, 1976; RAYMOND e ROBERTS, 1987; KROMREY e HINES, 1994). STRIKE et al. (2001) observaram os problemas gerados pela perda de dados para o processo de estimativas de custos e realizaram um estudo comparando algumas MDT aplicadas a modelos de estimativas de custos baseados em dados histricos. Para realizar o estudo, os autores utilizaram uma base de dados composta por 206 projetos de 26 empresas finlandesas de diversas reas (negcios, aplicaes bancrias, manufatura e outras). Os projetos tinham seu tamanho medido em pontos de funo, o esforo total fornecido em pessoas/ms e valores para quinze fatores de produtividade. Utilizando trs mecanismos para eliminar alguns dados da base de dados (MCAR, MAR e NM (LITTLE e RUBIN, 1987)) os autores testaram dez diferentes tcnicas de tratamento de dados perdidos. Foram realizadas 825 simulaes, variando o nmero de variveis perdidas de um a trs e o percentual de dados perdidos de 5 a 40%. Os resultados obtidos mostraram que possvel trabalhar em modelos de estimativas com dados perdidos com uma margem de erro aceitvel e at insignificante quando h poucos dados perdidos. medida que a quantidade de dados e sua utilidade para as estimativas aumenta, tambm aumentar a margem de erro da estimativa realizada. Uma ltima questo que ainda diz respeito base de dados histricos utilizada na analogia de estimativas quanto tempo os dados devem permanecer na base, ou seja, quando os dados dos projetos concludos podem estar obsoletos para serem utilizados nas analogias e, por este motivo, devem ser excludos ou desconsiderados. MENDES e COUSELL (2000) realizam este questionamento e afirmam que muitos estudos e observaes ainda devem ser realizados, mas que a introduo de novas tecnologias e expressivas mudanas organizacionais ou at mesmo econmicas so pontos que devem ser
16
observados para a eliminao de dados de projetos da base utilizada na analogia de estimativas. Os bons resultados obtidos nos estudos de analogia de estimativas no vm desacreditar os modelos paramtricos. Alguns dos estudos desenvolvidos associaram mtodos paramtricos e analogias, obtendo resultados que levaram concluso de que uma associao desses dois tipos de modelos seria capaz de fornecer estimativas com uma margem de erro aceitvel, ou seja, em torno de 20%.
2.2.3 Julgamento de Especialistas

Quando a analogia de estimativas foi apresentada na seo anterior, argumentou-se sobre a necessidade de possuir uma base de dados histricos, definir os critrios de caracterizao dos projetos e recuperar os dados de projetos concludos que possam ser utilizados como base para as estimativas de novos projetos. Porm, tambm preciso considerar que nem sempre a organizao tem acesso a uma base de dados histricos de projetos. Algumas vezes ela no possui dados formais nos quais possa se basear para realizar as estimativas de um projeto nem experincia ou conhecimento para utilizar de forma eficaz algum modelo paramtrico de estimativas. BOEHM e FAIRLEY (2000), ao analisarem essa situao, consideram uma outra forma de realizar as estimativas de um projeto. Eles afirmam que esta ainda a forma mais comumente utilizada, chamada de opinio de especialistas, julgamento de especialistas ou utilizao de experincia pessoal, e consiste no ato dos gerentes de projetos estimarem os valores para os projetos, baseando-se em suas prprias experincias passadas. A utilizao da experincia pessoal, segundo argumentos dos autores, no capaz de produzir dados histricos formais e, tipicamente, no apresenta regras para sua abordagem, alm de no permitir calibraes para melhorar as estimativas mal realizadas, uma vez que no h padro para sua realizao. Os autores ressaltam, ainda, que as tcnicas de estimativas baseadas em modelos matemticos ou em analogias podem ser utilizadas para uma diversidade considervel de tipos de projetos, pois so capazes de considerar as diferenas e especialidades de cada projeto em particular. Para um especialista consideravelmente difcil ter experincia em
17
todos os tipos de projetos de desenvolvimento de software, o que pode lev-lo a estimar de forma ineficiente um projeto com caractersticas diferentes das que trabalhou at o presente momento. Para BOEHM e FAIRLEY (2000) um especialista capaz de realizar estimativas que representem desvios aceitveis quando comparadas aos valores realmente praticados se ele tiver repetido a atividade de estimar muitas vezes e, com isso, tiver alcanado para si um certo grau de maturidade para realizar as estimativas de um projeto. Apesar de possuir algumas desvantagens, muitas vezes a utilizao da experincia pessoal pode ser o caminho disponvel para uma organizao realizar as estimativas de seu primeiro projeto e iniciar, assim, a alimentao de uma base de dados histricos que possa ser utilizada nos projetos subsequentes. BOEHM e FAIRLEY (2000) consideram, ainda, uma outra situao onde a opinio de um especialista necessria e tem o carter de julgamento e deciso. Nela, o gerente do projeto utiliza sua experincia para decidir os valores das estimativas quando tcnicas diferentes apresentam valores diferentes para as mesmas variveis do projeto (prazo, custos e esforo) ou para ajustar os valores propostos pelas tcnicas. Segundo os autores, nesse caso, a experincia do especialista representa um fator crtico para a deciso dos valores das estimativas que se aproximem o mximo possvel dos valores realmente praticados. MENDES e COUNSELL (2000) tambm consideram esse caso como o melhor caminho para a utilizao da opinio de especialistas. Apesar das desvantagens apresentadas pelos autores acima citados, alguns estudos tm sido realizados para mostrar que a opinio e julgamento de especialistas um bom caminho para realizao de estimativas. GRAY et al. (1999) realizaram estudos para analisar a realizao de estimativas atravs da opinio de especialistas. Em um estudo de caso comparativo entre Anlise de Pontos de Funo, COCOMO e julgamento de especialistas os autores puderam observar que as estimativas realizadas pelos especialistas superavam as demais em acurcia e consistncia. Neste estudo de caso os autores tambm puderam perceber que a maioria das empresas envolvidas no estudo utilizavam o
julgamento de especialistas, mesmo quando utilizavam outros modelos. Ao fim do estudo, concluram que uma associao formal das estimativas por analogias com o julgamento de especialistas capaz de produzir estimativas satisfatrias, pois o julgamento de
18
especialistas teria a funo de calibrar os valores apresentados pelos projetos similares. Os autores ressaltam que, mesmo com os resultados positivos, os riscos desse mtodo no podem deixar de ser considerados. Um outro estudo realizado por JOHNSON et al. (2000) tambm foi til para analisar a acurcia das estimativas geradas por especialistas. Eles desenvolveram um pacote de ferramentas de estimativas denominado LEAP (Lightweight, Empirical,
Antimeasurement dysfunction and Portable) e o utilizaram em um estudo de caso na University of Hawaii que envolveu 16 estudantes. A LEAP permite a realizao das estimativas por modelos algortmicos e/ou considerando a opinio do gerente do projeto. Considerando 128 projetos (cada estudante participou de oito projetos), os autores puderam perceber que as estimativas realizadas pela opinio dos estudantes tornavam-se melhores a cada projeto e que, na maioria dos casos, eram melhores que as calculadas pelos modelos algortmicos. Inicialmente, foram considerados os trs primeiros projetos de cada estudante, para alimentar uma base de dados histricos de projetos. Em seguida, outros projetos foram realizados e os estudantes passaram a observar as estimativas dos projetos anteriores e compar-las com os valores praticados, percebendo, assim, o erro cometido. A melhoria nos valores estimados nos cinco projetos subsequentes de cada aluno foi expressiva. A mdia de erro das estimativas de tamanho realizadas pelos estudantes no terceiro projeto era de 50% e diminuiu para 15% no oitavo. Para esforo, o erro diminuiu de 25% para 10%. Os autores HOST e WHOHLIN (1997) realizaram estudos sobre a utilizao do julgamento de especialistas como mtodo de estimativas, analisando-o em um pequeno experimento baseado no PSP Personal Software Process (HUMPREY, 1995) e
constataram que as estimativas realizadas eram eficientes quando comparadas com os valores reais dos projetos. Estudos recentes mostram que utilizar os trs tipos de modelos de estimativas um bom caminho para obter estimativas acuradas, uma vez que os pontos fracos de um modelo podem ser minimizados pelos outros modelos. Como exemplo de utilizao de tcnicas diferentes para realizar as estimativas de um projeto, temos BIELAK (2000), que realizou um projeto para os geocientistas do Departamento de Servios Tcnicos e Explorao da Pesquisa da empresa Arco, atuante no
19
segmento petrolfero, onde pde analisar a utilizao da experincia pessoal de gerentes para realizar as estimativas de tamanho de um projeto e a utilizao de dados histricos para melhorar essas estimativas. Para estimar os custos, prazos e esforo necessrios para desenvolver o projeto foi utilizado o COCOMO II, que necessita, entre outros fatores, do tamanho do sistema para que seja possvel calcular as demais estimativas. Ningum na equipe do projeto era treinado em Anlise de Pontos de Funo, ento o tamanho inicial do sistema precisou ser estimado considerando-se a experincia do gerente em projetos anteriores. Estimados os valores iniciais para uma parte do projeto, esta era desenvolvida. Concludo seu desenvolvimento, o tamanho real era, ento, comparado com o tamanho estimado inicialmente. O processo se repetiu at que todo o projeto estivesse concludo e, a cada estimativa de tamanho realizada, os dados das partes j concludas do projeto eram consultados. O resultado do estudo realizado pelo autor nesse projeto mostrou que, medida que o projeto era desenvolvido e que mais dados histricos eram obtidos, menor era o desvio entre os tamanhos estimado e real do projeto.
2.2.4 Outras Questes sobre a Realizao de Estimativas

Mesmo existindo diversas tcnicas para a realizao das estimativas de um projeto e estas apresentarem diversas abordagens diferentes (analogias, modelos matemticos e experincia pessoal) uma dificuldade comum apresentada pelos gerentes de projeto est em realizar as estimativas no incio do projeto, quando pouco conhecido do mesmo. As estimativas iniciais so realizadas quando o levantamento dos requisitos ainda no foi completamente executado. CHRISTENSEN e THAYER (2001) afirmam que realizar as estimativas na fase inicial do projeto uma tarefa rdua e que traz consigo riscos, como por exemplo a baixa preciso dos requisitos que ainda no esto formalizados. Dados de projetos similares podem ajudar (PMBOK, 2000), mas pode ocorrer a no existncia de projetos similares ou uma base de dados histricos que ainda esteja vazia. Uma forma de amenizar o problema das estimativas iniciais realizar essas estimativas considerando apenas as grandes fases do projeto. Quando as informaes do projeto tornarem-se mais precisas, o gerente pode realizar novas estimativas, agora com informaes mais completas e peculiares ao projeto,
20
considerando todas as atividades que devem ser executadas ao longo de seu desenvolvimento. RAINER e SHEPPERD (1999) realizaram um estudo durante vinte meses em um projeto na IBM para analisar o comportamento do cronograma do projeto ao longo de seu desenvolvimento. Inicialmente, o gerente do projeto props um cronograma considerando apenas as grandes fases do projeto. medida em que o projeto era desenvolvido reunies entre membros do projeto e usurios chave eram realizadas. Durante essas reunies o cronograma era analisado e, sempre que necessrio, era revisto e tinha suas estimativas de prazo e esforo refinadas. No total foram realizadas sete revises do cronograma. O gerente do projeto considerou o projeto sendo de sucesso, pois alm de ter satisfeito as exigncias do cliente, foi entregue no limite de prazo e custos previstos e apresentou um ganho de mercado para a empresa. Como resultado do estudo, os autores enfatizaram a necessidade do replanejamento durante o desenvolvimento do projeto, afirmando que, apesar do esforo para realizar o planejamento nas fases iniciais do projeto ser intenso, o planejamento deve continuar fase aps fase do projeto. Ento, medida que mais detalhes sobre o projeto so disponibilizados, as mudanas e refinamento nas estimativas devem ser realizados. Considerando todas as pesquisas e prticas desenvolvidas na rea de estimativas de projetos de software, ARMOUR (2002) realiza consideraes sobre algumas questes que so consideradas mitos no processo de realizao de estimativas em projetos de software. Ao retratar cada mito, o autor expe o contexto em que o mesmo est inserido e o justifica. Algumas concluses apresentadas por ARMOUR (2002) so: (i) muito difcil produzir estimativas acuradas, pois os dados necessrios para a realizao destas s estaro disponveis nas fases conclusivas do projeto; (ii) o tamanho do projeto no capaz de, sozinho, determinar as estimativas. Outras variveis como reuso e conhecimento necessrio tambm devem ser consideradas; (iii) a utilizao de dados histricos til, mas tambm no capaz de garantir a acurcia das estimativas, pois os critrios de similaridade devem ser bem estabelecidos e os dados disponibilizados devem ser analisados e bem interpretados para serem aplicados ao projeto corrente; (iv) um coeficiente mdio de produtividade no indica a produtividade real de cada indivduo, sendo assim, estimativas geradas a partir desse coeficiente podem no ser precisas; (v) linhas de cdigo e outros sistemas de medida,
21
como Anlise de Pontos de Funo, podem no refletir o tamanho real do projeto, pois podem no considerar reutilizao, linguagens e aplicativos de desenvolvimento com facilitadores, como geradores de cdigo, por exemplo; (vi) aumentar o nmero de pessoas em um projeto no significa que o mesmo poder ser concludo em menos tempo, pois as tarefas podem ser dependentes. Finalizando, o autor ressalta que o processo de realizar estimativas um processo de previso e no de preciso, sendo assim, uma margem de erro deve ser determinada e as estimativas que estiverem um desvio menor ou igual a essa margem de erro devem ser consideradas acuradas. 2.3 Descrio de Algumas Tcnicas de Estimativas de Custos Como mencionado anteriormente, muitas pesquisas tm sido realizadas com experincias para observar o comportamento das diversas tcnicas de estimativas e para tentar traar um caminho para a realizao das estimativas utilizando as melhores tcnicas para cada projeto em particular. Neste trabalho, dar-se- um maior foco analogia de estimativas, atravs do uso do conhecimento (a ser descrito posteriormente) e experincias passadas, e a duas tcnicas paramtricas: Anlise de Pontos de Funo e COCOMO II. Uma viso geral dessas tcnicas paramtricas e estudos envolvidos so apresentados a seguir. A descrio dos passos para sua utilizao, bem como exemplos de aplicao das tcnicas, so realizadas nos Anexo 1 e Anexo 2.
2.3.1 A Tcnica Anlise de Pontos de Funo

A Anlise de Pontos de Funo (APF) um sistema de medidas proposto por Allan Albrecht, da IBM, em 1979, que quantifica as funes contidas em um software em termos que so significativos para seus usurios e fornece o tamanho do software em nmero de pontos de funo. Segundo JONES (1999), durante muitos anos, a indstria de software considerou estimar o tamanho de um sistema como sendo um problema difcil e, at mesmo, sem soluo. Porm, nos ltimos 20 anos, muitas tcnicas tm sido propostas e a Anlise de
22
Pontos de Funo tem se destacado por ser utilizada em uma quantidade considervel de empresas e institutos no mundo todo. Essa tcnica recebe o apoio do IFPUG (Institute Function Point Users Group), que responsvel por determinar e documentar as regras de aplicao e valores utilizados na Anlise de Pontos de Funo, bem como fornecer apoio e treinamentos aos usurios da tcnica. Esse rgo possui comits de representao em diversos pases, onde possvel certificar indivduos na utilizao e conhecimento da tcnica. Em 1994, o IFPUG reconheceu a importncia do apoio da ISO (International Organization for Standardization) para que a APF tivesse uma utilizao mais expressiva no mercado. Sendo assim, a ISO reconheceu a APF como um padro internacional. Estudos foram realizados para a elaborao de uma norma que contemplasse a abordagem da APF e chegou-se concluso de que a utilizao de uma tcnica especfica poderia restringir a aplicao da norma. A comunidade ISO, ento, baseada nos princpios da APF, publicou a ISO/IEC 14143 Information Technology Software Measurement Functional Size Measurement, onde faz-se referncia aos mtodos FSM (Functional Size Measurement), sem exigir a aplicao de um mtodo especfico, mas sendo a APF um dos mtodos disponveis. FSM refere-se a uma classe geral de tcnicas de medio de software que considera os requisitos funcionais identificados pelo usurio como a base para calcular o tamanho do software (DEKKERS, 1999). A ISO/IEC 14143-1 define os conceitos fundamentais da FSM e descreve princpios gerais para aplicar um mtodo FSM. A Anlise de Pontos de Funo reflete a funcionalidade fornecida pelo software ao negcio em que est inserido. Dessa forma, pode ser aplicada em vrios contextos de desenvolvimento, da fase inicial de especificao dos requisitos do sistema, at em momentos posteriores sua implantao. Assim, indicadores como a produtividade do processo de desenvolvimento e o custo por ponto de funo podem ser obtidos. Cada uma das funcionalidades necessrias ao sistema recebe um peso numrico em funo de seu tipo e sua complexidade. Esses pesos so totalizados em uma medida inicial de tamanho, que ser normalizada atravs da ponderao de caractersticas gerais do sistema e fornecer um resultado final que mede o tamanho e a complexidade do mesmo (GARMUS e HERRON, 2001).
23
Como mencionado anteriormente, Anlise de Pontos de Funo pode ser utilizada em diversos momentos do desenvolvimento de software, podendo medir um projeto que ser desenvolvido, as manutenes em um sistema existente ou uma aplicao instalada. A contagem em pontos de funo realizada atravs da medida de dois tipos de funes que esto presentes em um sistema: Funes Tipo Dados e Funes Tipo Transao. As Funes Tipo Dados representam as funcionalidades fornecidas pelo sistema ao usurio, para atender s necessidades referentes aos dados que o sistema ir manipular. Trata-se dos arquivos internos e externos que so utilizados pelo sistema. As Funes Tipo Transao representam as funcionalidades de processamento dos dados fornecidas pelo sistema ao usurio. Trata-se das entradas, sadas e consultas do sistema. Considerando que sistemas com complexidade e caractersticas diferentes podem apresentar um mesmo nmero de pontos de funo (ou nmeros muito prximos), a tcnica prope a avaliao de quatorze caractersticas que indicam o perfil do projeto. A cada caracterstica, o usurio indica um nvel de influncia que pode variar de zero a cinco. Os valores atribudos s caractersticas sero utilizados para ajustar o nmero de pontos de funo encontrado inicialmente, refletindo, assim, as particularidades do projeto. O nmero de pontos de funo uma medida de tamanho para o sistema e, a partir dela, podem ser obtidas relaes que auxiliam na realizao das estimativas dos projetos. Para estimar os custos de um projeto, relaes como o esforo necessrio para realizar um ponto de funo e/ou o custo de um ponto de funo so imprescindveis. Esses valores podem ser obtidos atravs de consultas a tabelas fornecidas pelo IFPUG ou atravs da anlise dos dados de projetos anteriormente realizados pela organizao ou por outras. JONES (1999) realizou um estudo observando dados de diversos projetos. Os resultados obtidos foram relaes de um ponto de funo com o nmero de documentos gerados, com a quantidade de cdigo, com nmero de erros e com a quantidade de casos de testes. O objetivo de JONES (1999) ter analisado a quantidade de documentos gerados para um ponto de funo foi o tempo e esforo consumidos para gerar os diversos tipos de documentos que so necessrios durante o desenvolvimento de um software. O autor chegou concluso que, dependendo do domnio da aplicao, cerca de 50% do custo total do software atribudo elaborao dos documentos do projeto. O autor dividiu os
24
documentos dos projetos em seis tipos: requisitos do usurio, especificaes funcionais, especificaes lgicas, planos de testes, manuais do usurio e documentos de referncia para o usurio. Foram analisados projetos de quatro domnios diferentes. Para cada domnio foi calculado o intervalo mdio da quantidade de cada tipo de documento produzido em um ponto de funo. A utilizao da relao entre o nmero de documentos gerados e um ponto de funo j est presente em algumas ferramentas comerciais de estimativas de projetos. Um outro ponto analisado por JONES (1999) foi a quantidade de cdigo gerada por um ponto de funo. O autor considerou diversas linguagens. Essa relao bastante conhecida desde o incio da utilizao da APF. JONES (1999) tambm analisou o nmero de erros e defeitos observados em um ponto de funo e o nmero de casos de testes necessrios para realizar um ponto de funo. Para analisar os erros considerou as fases: requisitos, projeto, implementao, documentao, manuteno. Para cada fase o autor calculou o intervalo mdio do nmero de erros encontrados em um ponto de funo. Para analisar os casos de testes considerou: testes de unidade, testes de novas funes, testes de regresso, testes de integrao e testes do sistema. Para cada tipo de teste o autor calculou o intervalo mdio do nmero de casos de testes necessrios para um ponto de funo. Com a utilizao do paradigma de desenvolvimento orientado a objetos alguns autores desenvolveram estudos propondo adaptaes da tcnica APF para considerar os diagramas gerados na fase de anlise de requisitos de projetos orientados a objeto. Alguns autores chegaram a propor ferramentas que realizam a contagem sem que seja necessria a interferncia humana. Como exemplo desses autores temos KUSUMOTO et al. (2000) e UEMURA et al. (1999) que realizaram estudos envolvendo a aplicao da APF e adaptaes em especificaes de requisitos orientadas a objeto. Um estudo de caso foi realizado no sistema REQUARIO da empresa Hitachi Ltd. no qual foi utilizado o
paradigma de orientao a objeto e especificao em UML (Unified Modeling Language). Os autores desenvolveram uma adequao da APF que capaz de analisar os diagramas em UML e fornecer o nmero de funes tipo dados, funes tipo transao e pontos de funo do sistema. Essa adequao foi implementada em uma ferramenta que realizou as estimativas do sistema em estudo analisando os diagramas da especificao de requisitos.
25
Os resultados gerados pela ferramenta foram considerados adequados quando comparados com os resultados obtidos por um especialista em APF que realizou a medio manualmente. Os autores ressaltam que muitas aplicaes da ferramenta em projetos ainda devem ser realizadas, pois o universo de testes foi relativamente pequeno, mas consideraram que a experincia representa um grande passo na automatizao completa da APF. Um dos inconvenientes da utilizao de uma ferramenta como essa para realizar as estimativas, que, para isso, uma primeira especificao de requisitos do sistema deve estar pronta e representada em UML. Se a medio no for completamente automtica, a especificao no precisa estar representada em tantos detalhes quanto em alguns dos diagramas. Uma das vantagens da automatizao completa da tcnica evitar que pessoas diferentes obtenham estimativas diferentes para um mesmo projeto utilizando a tcnica APF. Segundo os autores, isso ocorre pois pessoas diferentes tm vises diferentes de um mesmo sistema. Essa discrepncia, no entretanto, no desejada e pode ser resolvida com a utilizao de uma ferramenta que realize as estimativas sem a interferncia humana. Assim, como apresentado no exemplo acima, a utilizao do paradigma orientado a objetos gerou a necessidade de criar outros mtodos ou adaptaes da tcnica APF para realizar as estimativas utilizando como base as especificaes geradas nessa abordagem. Um dos mtodos criados com esse objetivo a contagem em Pontos de Casos de Uso (NAGESWARAN, 2001) . Os diagramas de caso de uso so comumente utilizados para descrever a funcionalidades do sistema de acordo com sua forma de utilizao pelos usurios. A tcnica de anlise de dimenso por casos de uso foi criada para permitir realizar estimativas para projetos orientados a objeto ainda na fase de levantamento de requisitos, utilizando-se os prprios documentos gerados nessa fase como subsdio para o clculo das estimativas. A tcnica de estimativas por casos de uso foi proposta em 1993 por Gustav Karner, da Objectory (hoje, Rational Software). Ela baseia-se em dois mtodos paramtricos: a Anlise de Pontos de Funo e MARK II, uma adaptao de APF, bastante utilizada na Inglaterra. A forma de dimensionar o sistema a principal diferena dessa tcnica com a Anlise de Pontos de Funo. Nela, considera-se o modo como os usurios utilizaro o
26
sistema, a complexidade das aes requeridas para cada tipo de usurio e uma anlise em alto nvel das operaes do sistema. O nvel de abstrao maior do que o da APF. Uma vez que os casos de uso principais do sistema so levantados, possvel estimar o tamanho do sistema. O grau de detalhe dos casos de uso influencia diretamente no resultado final da medio. O ideal medir apenas os casos de uso em nvel de sistema, onde seja possvel diferenciar transaes e interaes com o usurio. Assim, uma
descrio de casos de uso em um nvel muito alto (nvel de negcio) ou muito baixo (casos de uso atmicos) no demonstra-se adequada para a medio. Para realizar as estimativas utilizando a tcnica Pontos de Caso de Uso so realizadas contagens dos atores e casos de uso do sistema obtendo uma contagem inicial. Em seguida, assim como na APF, caractersticas do sistema so analisadas para ajustar a contagem inicial e determinar o tamanho do sistema considerando suas principais
caractersticas. A descrio detalhada dos passos para a realizao de estimativas utilizando-se Pontos de Caso de Uso realizada no Anexo 1.
2.3.2 O Modelo COCOMO II

COCOMO (Constructive Cost Model) foi proposto por Barry Boehm durante os anos 70 (BOEHM, 1981) e foi chamado de COCOMO 81. Aps duas dcadas, uma evoluo, COCOMO II, foi desenvolvida no Centro de Pesquisa em Engenharia de Software da University of Southen California (USC). COCOMO II um modelo para a mensurao de esforo, prazos e custos. um reflexo do estado de amadurecimento das tecnologias e da Engenharia de Software e traz adequaes s mudanas ocorridas no decorrer das duas dcadas, desde que o COCOMO original foi proposto (TRINDADE et al., 1999). Assim como seu predecessor, o COCOMO II realiza as estimativas de esforo, prazos e custos para o desenvolvimento de um software a partir da dimenso do mesmo. As estimativas de prazo e esforo so calculadas diretamente atravs da utilizao das frmulas propostas pelo modelo e do tamanho do sistema. A estimativa dos custos do projeto, por sua vez, pode ser obtida analisando-se os valores de prazo e esforo encontrados.
27
Para determinar as relaes e os valores das variveis do COCOMO II foi realizada uma pesquisa que utilizou dados de 161 projetos. Esses dados foram analisados e, atravs de regresses matemticas, as relaes e constantes foram definidas pelos pesquisadores. O COCOMO II funciona como uma hierarquia de modelos que podem ser aplicados de acordo com a evoluo do desenvolvimento do software. O primeiro deles, chamado de Composio da Aplicao, usado nos primeiros estgios da Engenharia de Software, quando a prototipagem das interfaces com o usurio, a considerao da interao do software com o sistema, a avaliao do desempenho e o julgamento da maturidade tecnolgica so de extrema importncia. Esse modelo pode tambm ser utilizado em sistemas desenvolvidos com apoio dos ambientes ICASE3 ((Integrated Computer-Aided Software Engineering ). Aps serem conhecidos os requisitos e arquitetura bsicos do sistema, utiliza-se o modelo Pr-Projeto . Quando a especificao est completa e detalhes sobre o software a ser desenvolvido so profundamente conhecidos, o modelo utilizado o Ps-Arquitetura . Como mencionado anteriormente, para realizar as estimativas para o software, o COCOMO II requer a informao de tamanho do mesmo. Trs opes diferentes de dimensionamento esto disponveis: pontos por objeto, pontos de funo e linhas de cdigo fonte. O modelo Composio da Aplicao utiliza o dimensionamento em pontos por objeto, que mede o tamanho do software considerando o nmero de telas, relatrios e componentes que provavelmente sero necessrios para construir a aplicao. Os demais modelos utilizam o dimensionamento em pontos de funo ou linhas de cdigo fonte, pois contam com informaes mais precisas e detalhadas do software, possibilitando, assim, a utilizao dessas tcnicas. O primeiro passo para realizar as estimativas utilizando o COCOMO II determinar o modelo que ser utilizado. Em seguida, o tamanho do software deve ser dimensionado e as frmulas de clculo do esforo particulares a cada modelo devem ser utilizadas.
Ambientes que geralmente incluem as seguintes capacidades: um framework para aplicaes com middleware para integrar e gerenciar a execuo dos componentes da aplicao; um conjunto de utilitrios comuns, tais como construtores de interfaces grficas para o usurio, sistemas gerenciadores de bancos de dados e pacotes de suporte rede; um conjunto de componentes reutilizveis por domnio; um repositrio capaz de gerenciar e permitir acesso a esses componentes; e ferramentas de desenvolvimento para projeto, implementao, integrao e testes.
3
28
Para calcular o esforo, os modelos Pr-Projeto e Ps-Arquitetura utilizam uma variedade de fatores de equilbrio e direcionadores de custos para ajustar o clculo das estimativas. Os fatores de equilbrio so cinco fatores que so analisados para considerar as principais peculiaridades do projeto que influenciam na relao tamanho x esforo, como por exemplo o grau de similaridade do projeto em desenvolvimento com relao a outros desenvolvidos anteriormente. Os direcionadores de custos so caractersticas que devem ser avaliadas em um sistema, pois influenciam diretamente no esforo e prazo necessrios para desenvolv-lo. Um exemplo dessas caractersticas a capacidade dos analistas e programadores envolvidos no projeto. Cada caracterstica analisada, ou seja, cada direcionador e cada fator de equilbrio, recebe um nvel de influncia para o projeto (extremamente baixo, muito baixo, baixo, mdio, alto, muito alto, extremamente alto). Cada nvel tem um valor numrico correspondente (chamado multiplicador de esforo para os direcionadores de custos) que utilizado nas relaes matemticas do modelo. So esses valores numricos, juntamente com outras constantes utilizadas nas frmulas, que tornam o modelo adequado ao projeto em que est sendo aplicado. O modelo Pr-Projeto considera sete direcionadores de custos e o modelo PsArquitetura considera dezessete. A diferena no nmero de direcionadores considerados para cada modelo se d devido s poucas informaes conhecidas sobre o projeto nos momentos iniciais e ao detalhamento destas medida em que o sistema desenvolvido. Calculado o esforo para a construo da aplicao, o prximo passo consiste em estimar o prazo necessrio. Para realizar esse clculo, o COCOMO II considera em suas frmulas o esforo obtido anteriormente e restries de tempo presentes no desenvolvimento do produto. Calculados o esforo e o prazo, a equipe mdia e o custo para o desenvolvimento do projeto podem ser derivados. Uma importante diferena entre o COCOMO II e o COCOMO 81 que o modelo atual pode ter os valores de seus direcionadores de custos, fatores de equilbrio e constantes alterados. Esses valores podem ser alterados por uma nova calibragem
realizada pela equipe que props o COCOMO II, por uma calibragem desenvolvida por outros grupos de pesquisa ou ainda por calibragem desenvolvida por empresas especficas que utilizem o modelo com base em suas prprias experincias no desenvolvimento de
29
software. Sendo assim, cada organizao pode ser capaz de determinar seus prprios valores, baseando-se em projetos que j tenham sido realizados (TRINDADE et al., 1999). A calibrao do modelo a uma organizao especfica possibilita a realizao de estimativas mais acuradas, uma vez que estaro sendo considerados dados histricos da prpria organizao para realizar a calibrao.
2.4 Consideraes Finais Devido grande importncia das estimativas nos projetos de desenvolvimento de software e ao registro de uma considervel responsabilidade pelo fracasso dos mesmos s estimativas mal realizadas, vrias tcnicas tm sido propostas e muitas delas, com o passar do tempo, tm evoludo com o objetivo de acompanhar as mudanas tecnolgicas e de negcio impostas pelo mercado. A escolha da tcnica a ser utilizada em um projeto no tarefa trivial e nenhuma pode garantir valores precisos. Uma combinao de tcnicas paramtricas, como a Anlise de Pontos de Funo e COCOMO II, e no paramtricas, como a Analogia de Estimativas e Julgamento de Especialistas, tem sido considerada uma boa soluo, pois as tcnicas paramtricas podem auxiliar nas estimativas iniciais e as no paramtricas podem utilizar dados de projetos j concludos ou o conhecimento obtido em experincias passadas, buscando uma diminuio na margem de erro das estimativas. As tcnicas no paramtricas tambm so importantes quando a organizao no possui experincia para aplicar os modelos paramtricos. Mesmo considerando-se a falta de preciso das estimativas obtidas, importante a utilizao dessas tcnicas, pois medida que projetos forem concludos, ser possvel observar a margem de erros e calibrar o modelo para diminu-la. A realizao ad hoc das estimativas ainda uma escolha das organizaes, mas uma escolha que pode custar muito caro.
30
Captulo 3 Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA

Este captulo apresenta os principais conceitos de gerncia do conhecimento, de Ambientes de Desenvolvimento de Software Orientados Organizao e apresenta a Estao TABA e suas caractersticas relevantes a este trabalho.
3.1 Introduo O conhecimento tem sido apontado pelas organizaes em geral como um importante recurso estratgico, influenciando na competitividade da organizao (WINCH, 2000, OLEARY, 1998, LEE et al., 2001, LIEBOWITZ, 2002). Os engenheiros de software lidam constantemente com diferentes tipos de conhecimento ao longo do processo de desenvolvimento de software. O conhecimento acumulado pelos diversos membros da equipe de um projeto pode ser til em projetos futuros da organizao e representa uma potencial fonte de aprendizado organizacional em Engenharia de Software. Entretanto, a identificao, organizao, armazenamento, utilizao, evoluo e difuso do conhecimento no so atividades triviais. A gerncia do conhecimento surgiu com o objetivo de apoiar essas atividades. Para prover a Estao TABA da capacidade de realizar esse apoio foram definidos os Ambientes de Desenvolvimento de Software Orientados Organizao (ADSOrg) (VILLELA et al., 2001a). Este captulo apresenta, na seo 3.2, de forma sucinta, os conceitos de gerncia do conhecimento, enfatizando-se os pontos relevantes para os Ambientes de Desenvolvimento de Software Orientados Organizao e para este trabalho. Em seguida, na seo 3.3, a Estao TABA apresentada para que seja possvel o entendimento da infra-estrutura que permite a configurao de um ADSOrg. Na seo 3.4 so apresentadas as caractersticas e a estrutura dos Ambientes de Desenvolvimento de Software Orientados Organizao configurados na Estao TABA.
31
Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________
3.2 Gerncia do Conhecimento As organizaes defrontam-se com ambientes cada vez mais competitivos. Constantemente surge necessidade de reduo de custos, de aumento de valor de mercado e de reestruturaes organizacionais que, normalmente, resultam em demisses e consequentes perdas de informaes crticas para as organizaes. Segundo OLEARY (1998a) e OLEARY e STUDER (2001), esses so os principais fatores que levaram as organizaes a reconhecerem o valor estratgico do conhecimento. No caso especfico de organizaes cujo negcio o desenvolvimento de software, segundo WEI et al. (2002), pode ser acrescentado a este conjunto de fatores a falta de qualidade com que, muitas vezes, conduzida a atividade de levantamento de requisitos e a alta volatilidade das plataformas de hardware e software. Esses so os principais fatores que levaram as organizaes a se interessarem pela gerncia do conhecimento. A gerncia do conhecimento uma prtica formal de organizar, armazenar e facilitar o acesso e reutilizao do conhecimento organizacional, atravs do uso dos avanos da tecnologia da informao (OLEARY 1998a). a administrao, de forma sistemtica e ativa, dos recursos de conhecimento de uma organizao, utilizando tecnologia apropriada e visando fornecer benefcios estratgicos organizao, o que envolve a obteno de conhecimento relevante a partir de fontes internas e/ou externas disponveis para a organizao, disponibilizao e distribuio do conhecimento obtido de forma adequada s necessidades dos usurios, gerao de novos conhecimentos e eliminao de conhecimento defasado (VILLELA et al., 2000). A gerncia do conhecimento contribui para o aprendizado individual,
organizacional e de equipe, dando suporte disseminao da informao e inovao dentro da organizao (WINCH, 1999; DIENG, 2000). WINCH (2000) afirma, ainda, que para a vantagem competitiva agregada pelo conhecimento ser de fato sustentvel, este conhecimento no pode estar no nvel do indivduo, e sim no nvel organizacional. RAMASUBRAMANIAN e JAGADEESAN (2002) ressaltam que importante observar que a utilizao da gerncia do conhecimento em organizaes de software traz benefcios mais imediatos aos projetos de desenvolvimento de software em particular do que organizao como um todo. Os benefcios alcanados atravs de uma gerncia do
32
conhecimento eficaz em um projeto especfico incluem a possibilidade de fornecer respostas rpidas s necessidades dos clientes e o aumento da produtividade da equipe como um todo. Segundo DIENG (2000), a gerncia do conhecimento busca atingir os seguintes objetivos: (i) transformar o conhecimento individual em coletivo; (ii) dar suporte ao aprendizado e integrao de um novo membro em uma organizao; (iii) disseminar melhores prticas; (iv) melhorar os processos corporativos de trabalho, a qualidade e a produtividade dos produtos desenvolvidos; e, (v) reduzir tempo de entrega de produtos. No contexto especfico da Engenharia de Software, a gerncia do conhecimento visa apoiar o aperfeioamento constante das atividades realizadas ao longo do processo de desenvolvimento de software, apoiando a criao e transferncia de conhecimentos especificamente relacionados a esse contexto na organizao (SEPPNEN et al., 2002). As organizaes tm adquirido conhecimento atravs da anlise das atividades individuais e dos processos de negcios para aprender com seus sucessos e falhas (PREECE et al., 2001). Pesquisas indicam o crescimento da integrao das prticas da gerncia do conhecimento com os processos de negcios. O desafio, agora, prover mtodos e ferramentas que criem e capturem o conhecimento para essa integrao (OLEARY e STUDER, 2001). LEE et al. (2001) ressaltam que o verdadeiro sentido da gerncia do conhecimento deve ser considerado. A gerncia do conhecimento no simplesmente um problema de montar grupos e equipes de aprendizado ou instalar um sistema de gerncia de documentos eletrnicos para disseminar as informaes. Ao invs disso, um deslocamento do paradigma de gerncia, que envolve pessoas e outros recursos tais como estrutura organizacional, cultura, tecnologia da informao e outros.
3.2.1 Gerncia do Conhecimento em Engenharia de Software

O desenvolvimento de software uma rea que envolve muitas pessoas em fases e atividades diferentes e que sofre modificaes em um espao de tempo consideravelmente pequeno. A disponibilidade dos recursos normalmente no cresce proporcionalmente ao
33
crescimento das necessidades e no diminuir a produtividade uma necessidade. O conhecimento em Engenharia de Software muito extenso e aumenta cada vez mais. As organizaes tm problemas para identificar o contedo, a localizao e o uso do conhecimento. Uma melhoria no uso desse conhecimento a motivao bsica que guia a gerncia do conhecimento em Engenharia de Software. Alm da motivao bsica, RUS e LINDVALL (2002) citam algumas necessidades que tambm motivam a utilizao da gerncia do conhecimento em Engenharia de Software: (i) diminuio do tempo e custo de desenvolvimento e aumento da qualidade; (ii) melhoria no processo de tomada de decises; (iii) aquisio de conhecimento sobre novas tecnologias; (iv) aquisio de conhecimento sobre novos domnios; (v) compartilhamento do conhecimento sobre a poltica, prticas e cultura organizacionais; (vi) conhecimento sobre quem sabe o qu na organizao; e, (vii) compartilhamento do conhecimento adquirido no desenvolvimento de software. A gerncia do conhecimento tem diversas abordagens na Engenharia de Software, entre elas a melhoria do processo (SCHNEIDER et al., 2002; RUS e LINDVALL, 2002), a introduo de novas tecnologias e o aumento da qualidade e produtividade. Para realizar a melhoria do processo, o conhecimento organizacional e o conhecimento produzido na execuo das atividades dirias do processo devem ser considerados. Segundo SEPPNEN et al. (2002), utilizar a gerncia do conhecimento na melhoria do processo muito importante, pois as tcnicas de Engenharia de Software e de Gerncia da Qualidade falham se no forem baseadas no conhecimento necessrio e existente em uma organizao de software. Para aumentar a produtividade, preciso melhorar a capacidade da equipe de Engenharia de Software para que esta realize suas tarefas garantindo que o conhecimento adquirido durante o projeto no seja perdido e que o conhecimento armazenado na organizao seja utilizado (RUS e LINDVALL, 2002). RUS e LINDVALL (2002) e SCHNEIDER et al. (2002) ressaltam, ainda, a importncia da gerncia do conhecimento no planejamento de projetos. As organizaes podem utilizar a gerncia do conhecimento como uma estratgia de preveno e mitigao de riscos, uma vez que ela apresenta os riscos que poderiam ser ignorados, como por exemplo: repetio de erros e retrabalho devido ao esquecimento de lies aprendidas em projetos anteriores, indisponibilidade de indivduos que possuem conhecimento importante
34
e perda do conhecimento com posterior perda de tempo para readquiri-lo. Para o planejamento dos custos e cronograma de projetos, os autores consideram que a utilizao do conhecimento organizacional muito importante na realizao das estimativas, podendo ser utilizados modelos analticos que analisam dados quantitativos de projetos anteriores e propem estimativas para o projeto corrente. As atividades de acompanhamento do projeto, tais como a comparao entre as estimativas de custo, esforo e cronograma propostos e os valores atuais do projeto, criam o conhecimento do projeto particular. Seus resultados so teis para o prprio projeto e podem, tambm, ser base para a criao do conhecimento organizacional de projetos e para o aprendizado, podendo ser armazenados em repositrios e bases de experincias. Utilizando o conhecimento organizacional, os gerentes de projeto podem tambm estimar os defeitos, confiabilidade e outros parmetros do projeto e do produto. REIFER (2002) tambm faz uma anlise dos principais benefcios da gerncia do conhecimento para o planejamento do projeto. O autor tambm considera que a principal vantagem a captura do conhecimento organizacional e de lies aprendidas e a disponibilizao destes de forma sistemtica, porm ressalta que capturar as lies aprendidas pode ser uma tarefa difcil e que podem haver poucos incentivos para a utilizao da gerncia do conhecimento quando h presses para concluir a fase de planejamento. Outras atividades da Engenharia de Software que so apoiadas pela gerncia do conhecimento so a gerncia de documentao, a gerncia de competncias e identificao de especialistas e a reutilizao de software (RUS e LINDVALL, 2002). SEPPNEN et al. (2002) realizaram um estudo sobre como utilizar a gerncia do conhecimento atravs dos processos de projetos de software. Para isso, realizaram uma pesquisa em uma unidade de negcios independente de uma empresa de desenvolvimento de software para produtos eletrnicos. Os autores propuseram uma abordagem que captura o conhecimento de fontes relevantes ao projeto e, em seguida, empacota o conhecimento e o disponibiliza aos membros do projeto para utilizao, de acordo com a demanda. A captura, neste caso, similar anlise organizacional na Fbrica de Experincias, onde feita a anlise do conhecimento e o empacotamento deste em blocos reutilizveis. A
35
abordagem dos autores trata do conhecimento adquirido ao longo do processo de desenvolvimento de software. RAMESH (2002) ressalta que para utilizar a gerncia do conhecimento em processos de desenvolvimento de software necessrio que haja rastreabilidade no processo de gerncia do conhecimento para auxiliar a conexo dos fragmentos de conhecimento capturados ao longo do processo de desenvolvimento. BIRK et al. (2002) consideram a Anlise PostMortem como um excelente mtodo para gerncia do conhecimento, pois captura a experincia e melhores prticas de projetos concludos, com o objetivo de que os membros dos projetos sejam capazes de reconhecer, recordar e utilizar esse aprendizado durante os novos projetos.
3.2.2 Conhecimento
Como mencionado, a gerncia do conhecimento um campo que vem ganhando popularidade tanto na comunidade acadmica quanto no mundo dos negcios. Entretanto, embora exista uma certa abundncia em propostas de dispositivos e mtodos para desenvolver sistemas baseados em conhecimento, ainda existe uma confuso sobre o que constitui conhecimento (BIGGAN, 2001). Conceitualmente, conhecimento a informao combinada com experincia, contexto, interpretao e reflexo. a forma de informao que est pronta para ser aplicada em decises e aes (DAVENPORT et al., 1998). FISCHER e OSTWALD (2001) enfatizam ainda que conhecimento muito mais do que informao. Conhecimento a informao inserida em um contexto particular. Uma informao pode facilmente tramitar de um lugar para outro, de uma pessoa para outra, mas o conhecimento no o pode fazer com tal facilidade. ALAVI e LEIDNER (1999), por outro lado, preferem explicitar a conexo entre informao e conhecimento, diminuindo a distncia entre seus conceitos. Afirmam que o conceito de conhecimento no radicalmente diferente de informao, uma vez que conhecimento informao processada na mente do indivduo, que volta a se tornar informao quando articulado ou comunicado a outros atravs de textos, sadas computacionais, palavras faladas ou escritas e outros meios.
36
Segundo BIGGAN (2001), um cuidado especial deve ser tomado para diferenciar conhecimento de crena e opinio. Para isso, necessrio que trs critrios sejam satisfeitos: (i) o conhecimento deve ser verdadeiro; (ii) aquele que detm o conhecimento deve acreditar que ele verdadeiro; e (iii) aquele que detm o conhecimento deve estar em posio de saber que o mesmo verdadeiro. Quando se trata de conhecimento, existe uma unanimidade no que diz respeito aos seus dois tipos, sendo eles explcito e tcito. Conhecimento explcito pode ser expresso em palavras e nmeros e pode ser facilmente transmitido e compartilhado na forma de princpios universais, frmulas cientficas, procedimentos codificados, entre outros. Conhecimento tcito altamente pessoal e difcil de formalizar, tornando-se difcil de compartilhar com outras pessoas. Conhecimento tcito depende da experincia pessoal e envolve fatores intangveis como crenas, perspectivas e valores. Intuio e previses pertencem a esta categoria de conhecimento (VILLELA et al., 2000). Segundo RUS e LINDVALL (2002) o principal benefcio do conhecimento explcito que ele pode ser armazenado, organizado e disseminado sem o envolvimento de quem originou esse conhecimento. Alguns autores citam outras classificaes ou subclassificaes para o conhecimento (BIGGAN, 2001; MARKKULA, 1999). Segundo MARKKULA (1999), as metas organizacionais determinam o tipo de conhecimento a ser coletado por uma organizao, sendo crtica a identificao e coleta de conhecimento independente de sua forma. O autor classifica os conhecimentos que podem ser teis para organizaes que desenvolvem e mantm software, separando-os em trs classes: conhecimento externo, conhecimento interno estruturado e conhecimento interno informal. Na classe de conhecimento externo, tem-se: (i) ponteiros para sites da Internet, principalmente os sites tcnicos, mas tambm podem ser sites de clientes, competidores, parceiros tcnicos, fornecedores de software, jornais tcnicos e centros de pesquisa, e (ii) manuais, livros e materiais de treinamento disponveis eletronicamente ou a informao de como obt-los. A classe de conhecimento interno estruturado inclui: mtodos de planejamento de projetos e de Engenharia de Software, modelos de documentos com exemplos reais de
37
utilizao, melhores prticas, componentes de software, relatrios de pesquisa, diretrizes e outras informaes de comunicaes especficas da organizao, competncia dos funcionrios, informaes de marketing e de resultados da organizao. Estes tipos de conhecimento so revisados pela organizao antes de serem publicados. Por fim, a classe de conhecimento interno informal dividida em trs partes: discusses, que podem ser organizadas de acordo com os diferentes assuntos; notcias relacionadas a assuntos tcnicos e pastas de projeto, onde so mantidos todas as informaes e todo o conhecimento gerados durante cada projeto e que servem como repositrios de lies aprendidas quando os projetos so concludos.
3.2.3 Memria Organizacional

A Memria Organizacional pode ser considerada como um repositrio do conhecimento disponvel na organizao, cuja finalidade assegurar que o conhecimento desejado possa ser recuperado no tempo e no lugar corretos (KOUWENHOVEN, 1998). Para DIENG (2000), a Memria Organizacional uma representao explcita e persistente da informao e conhecimento cruciais em uma organizao, de forma a facilitar seu acesso, compartilhamento e reuso pelos membros da organizao para executar tarefas individuais e coletivas. A Memria Organizacional tem dois papis principais, segundo FISCHER e OSTWALD (2001): (i) ser fonte de informao para auxiliar a organizao a entender seus problemas e (ii) ser receptculo de novas informaes e produtos criados durante o desenvolvimento das tarefas. Quando se diz receptculo ou repositrio importante ressaltar que no pode ser entendido como um repositrio fsico nico, monoltico e de algum tipo especfico, como observado por ACKERMAN e HALVERSON (2000), pois nem mesmo as organizaes so entidades monolticas. Segundo OLEARY (1998a), a Memria Organizacional pode conter vrias bases de conhecimento, que podem ser para utilizao pela mquina ou pelo usurio, sendo bases de conhecimento tpicas em empresas de software: propostas, projetos, melhores prticas, notcias, especialistas, entre outras.
38
OLEARY (1998b, 1998c) acredita que, para usar vrias bases de conhecimento de forma efetiva, as organizaes devem estar hbeis a gerar ontologias que permitam aos usurios estabelecer os recursos que precisam e desejam. As ontologias4 e as bases de conhecimento esto proximamente relacionadas na gerncia do conhecimento, pois as ontologias definem as caractersticas das bases de conhecimento e suas vises, alm de facilitarem a comunicao entre mltiplos usurios e a associao entre as mltiplas bases de conhecimento, pois especificam um vocabulrio compartilhado.
3.2.4 Processo de Gerncia de Conhecimento

Para implantar gerncia do conhecimento necessrio que um processo seja seguido. PREECE et al. (2001) afirmam que poucas organizaes possuem um processo sistemtico de gerncia do conhecimento. No entanto, pesquisadores tm proposto diversos processos de conhecimento, sendo que, apesar de possurem fases ou estgios diferentes, todos apontam para as mesmas fases genricas: a criao, captura e disponibilizao do conhecimento. A diferena entre os processos propostos est no nvel de detalhamento das atividades. JOSHI (2001) prope um processo de conhecimento composto pelas seguintes atividades genricas de conhecimento: seleo de conhecimento, aquisio de conhecimento, utilizao de conhecimento, transferncia de conhecimento e internalizao de conhecimento. A seleo de conhecimento refere-se atividade de identificar e recuperar o conhecimento necessrio dentre os recursos de conhecimento existentes na organizao. A seleo de conhecimento e aquisio de conhecimento so atividades anlogas, diferindo em um importante aspecto: a aquisio de conhecimento manipula o conhecimento que existe tambm fora dos limites da organizao. A utilizao de conhecimento a atividade de aplicao do conhecimento existente para gerar novo
4 Ontologia uma representao de vocabulrio, geralmente especializada para algum domnio ou assunto. O termo ontologia algumas vezes utilizado para se referir a um corpo de conhecimento, tipicamente um senso comum sobre um determinado domnio, utilizando um vocabulrio como representao. Em outras palavras, a representao textual prov um conjunto de termos com os quais so descritos os fatos em algum domnio, enquanto o corpo do conhecimento utilizando aquele vocabulrio uma coleo de fatos sobre um domnio (CHANDRASEKARAN et al., 1999).
39
conhecimento e/ou produzir uma externalizao do conhecimento. A transferncia de conhecimento refere-se disseminao e distribuio do conhecimento. A internalizao de conhecimento refere-se a uma atividade que altera os recursos de conhecimento da organizao atravs da aquisio, seleo, transferncia e/ou utilizao do conhecimento. Outras propostas de processos de conhecimento so encontradas na literatura, entre elas: (i) RUS e LINDVALL (2002) consideram as seguintes atividades no processo: criao, captura, transformao, acesso e aplicao; (ii) PREECE et al. (2001) propem um processo com as fases de anlise de requisitos, modelagem conceitual, construo de base de conhecimento, validao e implantao, refinamento e manuteno; (iii) STAAB et al. (2001) propem um processo de conhecimento formado por quatro passos: criao ou importao do conhecimento, captura do conhecimento, recuperao e acesso do conhecimento, utilizao do conhecimento; (iv) FISCHER e OSTWALD (2001) consideram a gerncia do conhecimento como um processo cclico que envolve criao, integrao e disseminao; e (v) LEE et al. (2001) propem um processo de gerncia do conhecimento com quatro estgios: incio, propagao, integrao e distribuio. 3.3 A Estao TABA A Estao TABA, conforme originalmente proposto, um meta-ambiente capaz de gerar, atravs de instanciao, ambientes de desenvolvimento de software (ADS) adequados s particularidades de processos de desenvolvimento e de projetos especficos. Um meta-ambiente pode ser definido como um ambiente que abriga um conjunto de programas que interage com usurios para definir interfaces, selecionar ferramentas e estabelecer os tipos de objetos que iro compor o ambiente de desenvolvimento especfico (ROCHA et al., 1990). O projeto TABA teve incio em 1990, a partir da constatao de que domnios de aplicao diferentes possuem caractersticas distintas, e que estas devem incidir nos ambientes de desenvolvimento atravs dos quais os engenheiros de software desenvolvem aplicaes. Sendo assim, a Estao TABA tem por objetivo auxiliar na definio, implementao e execuo de ADS adequados a contextos especficos. Com o intuito de atender a esse objetivo, quatro funes foram originalmente definidas para a Estao TABA (TRAVASSOS, 1994): (i) auxiliar o engenheiro de
40
software na especificao e instanciao do ambiente mais adequado ao desenvolvimento de um produto especfico a partir do processo de software e/ou de uma definio do domnio de aplicao; (ii) auxiliar o engenheiro de software na implementao das ferramentas necessrias ao ambiente definido; (iii) permitir aos desenvolvedores do produto de software a utilizao da Estao atravs do ambiente instanciado; e (iv) permitir a execuo do software na Estao configurada para o seu desenvolvimento. Considerando que os objetivos iniciais do projeto, os quais apontavam que as particularidades de domnios de aplicao tambm devem ser consideradas na instanciao de um ADS para que este oferea ferramentas mais especficas e possibilite a reutilizao do conhecimento do domnio, OLIVEIRA (1999) estendeu a definio da Estao TABA de forma que esta possa instanciar ADS orientados a domnios especficos, criando os Ambientes de Desenvolvimento de Software Orientados a Domnio (ADSOD), atravs da incluso do conhecimento de domnio e sua disponibilizao para a realizao das diversas atividades do desenvolvimento de software. 3.4 Ambientes de Organizao (ADSOrg) Desenvolvimento de Software Orientados
Para melhorar a maneira como as organizaes desenvolvem e mantm software fundamental melhorar a maneira como elas administram o conhecimento requerido para a realizao dessa atividade. Dessa forma, a partir dos estudos realizados em gerncia do conhecimento e ADS, foi definido o conceito de Ambiente de Desenvolvimento de Software Orientado Organizao (ADSOrg), uma classe de ADS que apia a atividade de Engenharia de Software em uma organizao, fornecendo o conhecimento acumulado pela organizao e relevante para essa atividade, ao mesmo tempo em que apia, a partir dos projetos especficos, o aprendizado organizacional em Engenharia de Software (VILLELA, et al. ,2000). ADSOrg representam uma evoluo dos Ambientes de Desenvolvimento de Software Orientados a Domnio (ADSOD) e visam apoiar o gerenciamento completo do conhecimento requerido em uma atividade de Engenharia de Software, evitando que esse conhecimento fique disperso ao longo da estrutura organizacional e, consequentemente, sujeito a dificuldades de acesso e, at mesmo, a perdas (VILLELA et al., 2000).
41
Um ADSOrg
tem os
seguintes objetivos: (i) permitir que desenvolvedores e
demais envolvidos no desenvolvimento de software tenham acesso a todo conhecimento acumulado pela organizao e relevante ao contexto de desenvolvimento e manuteno de software; (ii) promover o aprendizado organizacional neste contexto (VILLELA et al., 2000; VILLELA et al., 2001b; VILLELA et al., 2002). Um ADSOrg torna possvel a identificao de erros cometidos em projetos anteriores e a reutilizao de solues pr-qualificadas durante a realizao de tarefas similares ou idnticas, visando a melhoria da produtividade e qualidade, bem como a reduo dos custos do software (VILLELA et al., 2000). ADSOrg so, como mencionado anteriormente, uma evoluo do conceito de ADSOD e foram construdos a partir de duas constataes: (i) duas ou mais organizaes podem desenvolver software para um mesmo domnio com processos, interesses e caractersticas muito distintas; e, (ii) o conhecimento do domnio no o nico conhecimento importante para apoiar desenvolvedores e demais envolvidos no processo de software em suas atividades. Outros conhecimentos, tais como o conhecimento relativo s diretrizes e melhores prticas organizacionais e s lies aprendidas em experincias anteriores com o uso de processos, mtodos e tcnicas de software, tambm so extremamente importantes e teis para os desenvolvedores e demais envolvidos. Os requisitos de um ADSOrg so: (i) possuir a representao da estrutura e dos processos organizacionais e possibilitar a fcil localizao de especialistas cujo conhecimento e experincia podem ser teis em projetos de software; (ii) armazenar conhecimento especializado sobre desenvolvimento e manuteno de software e fornecer esse conhecimento para as equipes de projeto quando necessrio; e, (iii) apoiar a contnua evoluo do conhecimento armazenado no ambiente. Dessa forma, a Estao TABA passou a ter as seguintes funes VILLELA et al., 2000): (i) Auxiliar o engenheiro de software na especificao e configurao do ambiente mais adequado para apoiar o desenvolvimento de software em uma organizao especfica (ADSOrg), considerando seu processo de software e a gerncia do conhecimento organizacional relevante para o desenvolvimento de software;
42
(ii)
Auxiliar o engenheiro de software na especificao e instanciao de ambientes de desenvolvimento de software para projetos especficos a partir da prpria Estao TABA (caso no seja possvel ou adequado a definio de um ADSOrg);
(iii) Auxiliar os gerentes de projeto de organizaes cujo negcio o desenvolvimento de software para diversos clientes na realizao de novas especializaes a partir dos processos especializados do ADSOrg, de forma a atender s particularidades de desenvolvimento de software desses clientes; (iv) Auxiliar os gerentes de projeto na especificao e instanciao de ambientes de desenvolvimento de software para projetos especficos a partir do ADSOrg configurado; (v) Auxiliar o engenheiro de software a implementar ferramentas necessrias aos ambientes de desenvolvimento de software; (vi) Permitir o uso da Estao TABA para desenvolvimento de software atravs dos ambientes instanciados; e (vii) Permitir a execuo do software na prpria Estao.
3.4.1 Planejamento de Projetos em Ambientes de Desenvolvimento de Software Orientados Organizao

Para apoiar a atividade de Planejamento de Projetos na Estao TABA, algumas ferramentas foram desenvolvidas e outras encontram-se em desenvolvimento, no contexto do ADSOrg. Uma delas, RiscPlan, apia o planejamento de riscos baseado na reutilizao do conhecimento organizacional de riscos, considerando as caractersticas do projeto e a experincia da organizao em projetos anteriores (FARIAS, 2002). O objetivo dessa ferramenta dar suporte automatizado ao planejamento de riscos em projetos de software, oferecendo aos gerentes de projeto o conhecimento e experincias acumulados por diferentes gerentes em projetos similares ocorridos dentro da prpria organizao. Outra ferramenta, RHPlan, apia as atividades de definio de perfis de competncia,
43
seleo de profissionais, monitorao da alocao e avaliao de recursos humanos necessrias ao processo de alocao de recursos humanos de um projeto (SCHNAIDER, 2003). O objetivo dessa ferramenta dar suporte automatizado ao planejamento de recursos humanos em projetos de software, permitindo a utilizao do conhecimento organizacional de competncias. A ferramenta CustPlan, proposta neste trabalho, auxilia o planejamento de custos e prazos em ADSOrg, considerando as caractersticas do projeto, a experincia da organizao em projetos anteriores e mtodos paramtricos de realizao de estimativas. O objetivo dessa ferramenta dar suporte automatizado ao planejamento de custos e prazos em projetos de software, oferecendo aos gerentes de projeto o conhecimento e experincias acumulados por diferentes gerentes em projetos similares ocorridos dentro da prpria organizao. A ferramenta CustPlan est inserida no contexto do ADSOrg e, assim, deve atender a seus requisitos. Dessa forma, o requisito (ii) que designa fornecer conhecimento para as equipes de projeto e o requisito (iii) que designa apoiar a contnua evoluo do conhecimento armazenado no ambiente sero parcialmente atendidos no que diz respeito ao conhecimento necessrio para a realizao das atividades dos processos de gerncia de prazos e custos, uma vez que, durante o planejamento de prazos e custos de um projeto ser possvel a reutilizao do conhecimento adquirido ao longo de projetos anteriores e armazenado na memria organizacional. A utilizao das ferramentas descritas acima fornece o Plano de Riscos, o Plano de Alocao de Recursos Humanos, o Plano de Custos e o Cronograma do projeto. Esses planos so componentes do Plano do Projeto que utilizado na gerncia do projeto.
3.5 Consideraes Finais Este captulo apresentou os principais conceitos da gerncia do conhecimento, importantes para a definio dos Ambientes de Desenvolvimento de Software Orientados Organizao. Tambm foi realizada a apresentao das principais caractersticas da Estao TABA, relevantes para o ADSOrg e para este trabalho.
44
O ADSOrg foi definido e foram descritas suas principais caractersticas. As ferramentas de apoio ao planejamento de projeto, presentes no ADSOrg, foram apresentadas. A utilizao do conhecimento organizacional uma das principais atividades em um ADSOrg. A ferramenta proposta neste trabalho contribui para a formao desse conhecimento no que diz respeito s atividades dos processos de gerncia de custos e prazos dos projetos de desenvolvimento de software da organizao e utiliza o conhecimento armazenado para auxiliar a realizao de melhores estimativas de custos e prazos no Cronograma e Plano de Custos dos projetos a serem desenvolvidos. No prximo captulo, ser apresentada a abordagem proposta para o planejamento de prazos e custos para projetos de software em ADSOrg. Com esse objetivo sero apresentadas a abordagem terica para processos de gerncia de custos e gerncia de tempo e suas abordagens no ADSOrg.
45
Captulo 4 Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados Organizao

Este captulo apresenta uma abordagem para o planejamento de custos em projetos de software baseada na reutilizao do conhecimento e experincia organizacionais. A ferramenta proposta introduz o planejamento de custos Estao TABA e fundamentada nos conceitos de gerncia do conhecimento e ADSOrg.
4.1
Introduo
O planejamento de custos uma das atividades iniciais de um projeto de software e requer uma viso global da organizao, sendo fortemente centrado na experincia e conhecimento adquiridos em projetos anteriores. Quanto maior a experincia do gerente do projeto, melhor ele ser capaz de realizar as estimativas para o projeto corrente. Porm, o conhecimento de prazo e custos de um gerente de projeto no pode permanecer no nvel do indivduo. Para que a organizao evolua aprendendo com seus prprios erros e acertos, necessrio que o conhecimento seja gerenciado de forma a tornar possvel sua captura, recuperao e futura utilizao. Este captulo apresenta uma abordagem para o planejamento de custos e fundamenta-se nos conceitos de gerncia do conhecimento e Ambientes de
Desenvolvimento de Software Orientados Organizao. A proposta disponibilizar ao gerente do projeto todo o conhecimento de prazos e custos acumulado pelos vrios gerentes de uma organizao, considerando projetos similares anteriores. A seo seguinte apresenta como o planejamento de projetos ser realizado em um ADSOrg e aborda o planejamento de custos como uma das atividades realizadas durante o planejamento do projeto. A seo 4.3 apresenta os processos de gerncia de tempo e
46
Planejamento de Custos em ADSOrg ________________________________________________________________________________________
gerncia de custos definidos buscando-se a utilizao do conhecimento organizacional de tempo e custos nas vrias atividades do processo. A seo 4.4 apresenta a abordagem proposta para o planejamento de custos, apresentando a modelagem das vrias atividades includas nos processos de gerncia de tempo e gerncia de custos e a forma como o conhecimento utilizado e, finalmente, a seo 4.5 apresenta as consideraes finais.
4.2
Planejamento de Custos em ADSOrg
A Estao TABA permite que uma organizao estabelea seu Processo Padro e, a partir dele, defina os processos especializados e instanciados. Um processo instanciado se adequa s necessidades de um projeto especfico e precisa ser acompanhado, medido e gerenciado de forma a buscar uma maior qualidade do produto de software que est sendo desenvolvido. Uma das atividades que deve estar presente em um processo instanciado a atividade de Planejamento do Projeto. Essa atividade deve ser realizada no incio do projeto, de forma macroscpica, e deve ser detalhada ao longo do desenvolvimento, medida em que aumenta o nvel de entendimento do projeto. A atividade de planejamento tem como produto o documento Plano do Projeto, que contm as diretrizes e mtodos a serem seguidos para a execuo do projeto. O Plano do Projeto composto por vrias sees que abordam tpicos especficos a serem considerados. O Plano do Projeto elaborado com o auxlio de um ADSOrg conter os seguintes planos: Plano de Organizao: descreve as equipes de desenvolvimento, gerncia e controle da qualidade que atuaro no projeto e respectivas responsabilidades. Plano de Documentao: apresenta os roteiros de todos os documentos a serem gerados ao longo do desenvolvimento do projeto, bem como as responsabilidades por sua produo e avaliao. Plano de Recursos e Produtos: identifica os produtos a serem gerados, respectivas dimenses e os recursos necessrios para o desenvolvimento do projeto. neste plano que encontra-se a anlise dos prazos e recursos humanos para a realizao das atividades do projeto.
47
Plano de Acompanhamento: descreve os marcos e pontos de controle gerenciais e os procedimentos adotados para acompanhamento e controle do projeto. Este plano contm, ainda, a anlise de riscos do projeto e os procedimentos de gerncia relativos mesma. Plano de Controle da Qualidade: descreve os marcos e pontos de controle da qualidade e todos os procedimentos (revises) e atributos de qualidade a serem adotados para controle da qualidade ao longo do desenvolvimento e avaliao da qualidade do produto final. Plano de Treinamento: descreve o cronograma das atividades para treinamento dos desenvolvedores e usurios do produto. Plano de Implantao e Operao: descreve os procedimentos necessrios para a implantao e operao do produto. Plano de Gerncia de Configurao: descreve os procedimentos para gerncia de configurao. A figura 4.1 ilustra um modelo do Plano do Projeto a ser gerado em um ADSOrg.
48
Plano do Projeto
1. 2. 3. Plano de Organizao Plano de Documentao Plano de Recursos 4.1 Recursos Humanos (indica os recursos humanos necessrios ao desenvolvimento do projeto) 4.2 Cronograma (indica o cronograma para a realizao do projeto) 4.3 Recursos de Hardware (indica os recursos de hardware necessrios ao desenvolvimento do projeto) 4.4 Recursos de Software (indica os recursos de software necessrios ao desenvolvimento do projeto) 4.5 Recursos Financeiros (indica os recursos financeiros necessrios ao desenvolvimento do projeto, representados atravs do oramento do projeto) 4.6 Outros Recursos (indica outros recursos necessrios ao desenvolvimento do projeto, como por exemplo aluguel, energia, dentre outros) 4. 5. 6. 7. 8. Plano de Acompanhamento Plano de Controle da Qualidade Plano de Treinamento Plano de Implantao e Operao Plano de Gerncia da Configurao
Figura 4.1. Modelo do Plano de Projeto com detalhamento do Plano de Recursos (ROCHA, 2000)
49
Para fornecer apoio elaborao do Plano do Projeto em um ADSOrg instanciado, algumas ferramentas foram desenvolvidas e esto disponveis para a execuo da atividade de Planejamento do Projeto (ou equivalente). O objetivo apoiar o desenvolvimento de cada um dos planos (sees) inseridos no Plano do Projeto, fornecendo para isso, o conhecimento organizacional adquirido pelos vrios gerentes de projetos anteriores e que possa ser til elaborao de um plano especfico. Algumas dessas ferramentas foram citadas no captulo 3, sendo a RiscPlan (FARIAS 2002) utilizada para apoiar a Anlise de Riscos e a RHPlan (SCHNAIDER, 2003) utilizada para apoiar a alocao de recursos humanos ao projeto. Neste trabalho apresentamos uma abordagem para o planejamento de custos (cronograma, recursos de hardware, software, outros recursos e oramento) , presente no Plano de Recursos, em ADSOrg, e propomos a CustPlan como ferramenta de apoio abordagem proposta. Com a utilizao da CustPlan o gerente de projeto poder elaborar o Plano de Custos utilizando tcnicas paramtricas de estimativas e consultando o conhecimento acumulado para a realizao dessa atividade. 4.3 Processo de Gerncia de Tempo e Processo de Gerncia de Custos Os processos de gerncia de tempo e gerncia de custos possuem um conjunto de atividades maior que o necessrio ao planejamento de tempo e custos de um projeto de software, uma vez que abrangem tambm as atividades relacionadas ao acompanhamento e controle do Plano de Custos ao longo do processo de desenvolvimento. O objetivo da definio do processo foi destacar os requisitos a serem alcanados pela abordagem de planejamento de custos proposta neste trabalho e facilitar o entendimento da insero da abordagem na gerncia de tempo e custos como um todo. Os processos foram definidos tendo como base a literatura de gerncia de custos, as recomendaes da norma NBR ISO 10006 (2000), que define diretrizes para a qualidade no gerenciamento de projetos, o relatrio tcnico 16326 da ISO/IEC (1999), que prov um guia para a aplicao da norma NBR ISO/IEC 12207 (1998) gerncia de projetos de software, e o PMBOK (Project Management Body of Knowledge - 2000), o padro para gerncia de projetos publicado pelo PMI (Project Management Institute).
50
A norma NBR ISO 10006 (2000) recomenda que sejam utilizados, em todas as atividades do processo, a experincia e dados histricos provenientes de projetos anteriores. Dessa forma, o processo aqui descrito busca a reutilizao do conhecimento e experincia organizacionais, um dos benefcios visados pela gerncia do conhecimento. Em todas as referncias citadas, a gerncia de custos realizada atravs de dois pilares de gerncia: o tempo do projeto e os custos propriamente ditos. Sendo assim, foram definidos dois processos distintos, que relacionam-se diretamente: Processo de Gerncia de Tempo e Processo de Gerncia de Custos. A descrio dos processos apresenta os aspectos que devem ser considerados, os produtos gerados e os responsveis envolvidos em cada atividade. Esse processo ainda pode ser adaptado realidade de uma organizao especfica, considerando os documentos a serem gerados, realizao de sub-atividades e possveis limitaes ou restries impostas.
4.3.1 Processo de Gerncia de Tempo

A Gerncia de Tempo tem como objetivo determinar as dependncias e a durao das atividades do projeto. Este processo deve ser utilizado em dois momentos distintos: inicialmente, quando pouco conhecido do projeto, onde so geradas as estimativas iniciais ainda com uma abrangncia macroscpica, para realizar o planejamento do projeto e, posteriormente, quando mais informaes do projeto forem obtidas, o que permite o refinamento das estimativas geradas. No momento de realizar as primeiras estimativas, apenas as atividades do processo de desenvolvimento so analisadas. No refinamento das estimativas, as sub-atividades do processo tambm so consideradas. O processo de gerncia de tempo composto por cinco atividades: i. Identificar as dependncias entre as atividades do projeto ii. Estimar a durao das atividades do projeto com abordagem top-down iii. Estimar a durao das atividades do projeto com abordagem bottom-up iv. Elaborar o cronograma do projeto v. Controlar o cronograma do projeto
51
i. Identificar as Dependncias entre as Atividades do Projeto Esta atividade consiste em identificar as relaes de dependncia entre as atividades do projeto. As inter-relaes, interaes lgicas e interdependncias entre as atividades devem ser identificadas e analisadas quanto sua consistncia, pois existem atividades que podem ser realizadas independentemente de outras, mas h aquelas que precisam de uma relao de dependncia temporal com outra(s). Durante esta sub-atividade, o gerente do projeto deve identificar as dependncias entre as atividades/sub-atividades do processo de desenvolvimento do projeto. A anlise das dependncias usuais entre as atividades/sub-atividades de projetos anteriormente realizados buscando encontrar informaes que orientem na determinao das dependncias entre as atividades/sub-atividades do projeto corrente de grande importncia, bem como considerar a opinio de especialistas. Produto: Atividades/sub-atividades do projeto sequenciadas. Responsvel: Gerente do projeto.
Aps esta atividade, so realizadas as estimativas de durao das atividades do projeto e seu esforo. Neste momento, so estimados quantos perodos de trabalho e o esforo que sero necessrios para a realizao de cada atividade/sub-atividade do projeto. Os perodos de trabalho podem ser indicados em horas, dias, semanas ou outras unidades de tempo. Ao estimar os perodos de trabalho preciso considerar tambm o tempo de espera necessrio devido s relaes de dependncia entre algumas atividades/sub-atividades. Essas relaes foram identificadas durante a execuo da atividade i. As estimativas de durao das atividades podem ser realizadas com abordagem topdown (atividade (ii) Estimar a durao das Atividades do Projeto com Abordagem Topdown ) ou com abordagem bottom-up (atividade (iii) Estimar a Durao das Atividades do Projeto com Abordagem Bottom-up). Dessa forma, as atividades ii e iii so realizadas de forma alternativa.
52
ii. Estimar a durao das Atividades do Projeto com Abordagem Top-down Gerentes de projetos costumam estimar utilizando mtodos paramtricos e/ou comparao com projetos similares, de acordo com a prpria experincia em projetos anteriores. Neste processo, consideramos que ser utilizada uma combinao destes. Modelos paramtricos sero utilizados para a realizao das estimativas do projeto como um todo ou por partes (mdulos, fases). Dados de projetos similares anteriores sero utilizados para refinar essas estimativas. Aps obtidos esses valores, os mesmos devem ser distribudos entre as atividades/sub-atividades, sendo muito importante, novamente, consultar dados de projetos anteriormente realizados e considerar a opinio de especialistas.
Sub-atividades: Realizar as estimativas do projeto atravs de Mtodos Paramtricos: Durante esta sub-atividade o gerente do projeto utiliza mtodos paramtricos (Anlise de Pontos de Funo e/ou COCOMO II) para realizar as estimativas do projeto. O gerente pode realizar as estimativas de todo o projeto ou dividi-lo em mdulos e realizar as estimativas para cada mdulo. Nesse caso as estimativas totais do projeto so obtidas atravs do somatrio das estimativas dos mdulos. Ajustar as estimativas a partir de dados de projetos similares: Durante esta sub-atividade o gerente do projeto consulta dados de projetos similares para refinar as estimativas do projeto obtidas na sub-atividade anterior. Essas estimativas sero utilizadas como base para realizao das estimativas de tempo das atividades/sub-atividades do projeto. Distribuir o tempo do projeto pelas atividades/sub-atividades do processo de desenvolvimento: Durante esta sub-atividade o gerente do projeto realiza as estimativas de durao de cada atividade/sub-atividade do processo de desenvolvimento. Para realizar essa sub-atividade o gerente distribui os valores totais do projeto ou de seus mdulos, encontrados com a utilizao dos modelos paramtricos e ajustados com dados de projetos similares (duas sub-atividades descritas acima), entre as atividades/sub-atividades do projeto. Para isso, o gerente deve analisar o tempo das atividades/sub-
53
atividades de projetos anteriormente realizados buscando encontrar informaes que orientem na realizao das estimativas de tempo das atividades/sub-atividades do projeto corrente, bem como considerar sua experincia pessoal. Produto: Atividades/ sub-atividades do projeto com estimativas de tempo. Responsvel: Gerente do projeto.
iii. Estimar a durao das Atividades do Projeto com Abordagem Bottom-up Caso o gerente faa a opo pela abordagem bottom-up, ele realiza as estimativas de cada atividade/sub-atividade do projeto. Os valores totais do projeto e/ou seus mdulos so, ento, obtidos atravs do somatrio das estimativas das atividades/sub-atividades. possvel perceber que abordagem bottom-up ocorre de forma inversa top-down, onde as estimativas so realizadas, inicialmente, para todo o projeto e, depois, distribudas entre suas atividades/sub-atividades. Aqui, na abordagem bottom-up, inicialmente, so realizadas as estimativas das atividades/sub-atividades e, em seguida, so totalizadas as estimativas do projeto. Nesse caso, para estimar o tempo e esforo de cada atividade/sub-atividade, o gerente do projeto deve analisar a durao e esforo das atividades/sub-atividades presentes em projetos similares anteriores, buscando encontrar valores que orientem a realizao das estimativas das atividades/sub-atividades do projeto corrente. Produto: Atividades/ sub-atividades do projeto com estimativas de tempo. Responsvel: Gerente do projeto.
iv. Elaborar o Cronograma do Projeto Esta atividade consiste em identificar os caminhos crticos do projeto, estabelecer as datas de incio e fim das atividades do projeto e registrar os marcos e pontos de controle identificados para o projeto no Plano de Acompanhamento. Sub-atividades: Identificar caminhos crticos do projeto: Durante esta sub-atividade o gerente do projeto deve identificar os caminhos crticos do projeto. Um caminho crtico uma seqncia de atividades tais que, se houver atraso em alguma delas, esse atraso ser transmitido ao trmino do projeto. Para cada
54
caminho crtico devem ser registradas informaes importantes, como a necessidade de tomada de deciso no caminho crtico em questo ou alguma observao a ele pertinente. Determinar as datas de incio e fim de cada atividade/sub-atividade: Durante esta sub-atividade o gerente do projeto define as datas de incio e fim para realizar cada atividade/sub-atividade, observando o prazo estimado para cada uma delas, suas dependncias e os caminhos crticos identificados. Registrar marcos e pontos de controle do projeto: Durante esta subatividade os marcos e pontos de controle identificados no Plano de Acompanhamento do projeto so registrados no cronograma. Produto: Cronograma do projeto. Responsvel: Gerente do projeto.
v. Controlar o Cronograma do Projeto Durante o desenvolvimento do projeto, o cronograma deve ser comparado, analisado e revisto sempre que necessrio. Convm que o cliente e as principais partes interessadas estejam cientes das alteraes do cronograma e, quando necessrio, sejam envolvidos na determinao das mudanas. Sub-atividades: Identificar Desvios de Cronograma: Durante o desenvolvimento do projeto podem ocorrer desvios no cronograma. Nesta sub-atividade o gerente do projeto registra os desvios das estimativas de tempo em relao ao realizado, justificando-os. Rever o Cronograma: Durante esta sub-atividade o gerente do projeto rev o cronograma considerando a possibilidade de recuperao do desvio ou negociando com as partes envolvidas. As decises e aes corretivas a serem tomadas s devem ser feitas aps consideradas suas implicaes para o projeto. Comunicar Alterao no Cronograma: Nesta sub-atividade realizada a divulgao da alterao no cronograma s partes envolvidas no projeto.
55
Produto: Cronograma revisado. Responsvel: Gerente do projeto.
4.3.2 Processo de Gerncia de Custos

A gerncia de custos projeto. Este processo deve ser utilizado em momentos distintos: inicialmente, aps serem realizadas as estimativas iniciais de tempo, so geradas as estimativas iniciais de custos ainda com uma abrangncia macroscpica. Posteriormente, as estimativas realizadas so detalhadas e, se as estimativas de tempo e esforo forem revistas, as estimativas de custos tambm sero. O processo de gerncia de custos composto por trs atividades: i. ii. iii. Estimar os custos do projeto Elaborar oramento do projeto Controlar oramento do projeto tem como objetivo fornecer a estimativa dos custos do
i. Estimar os Custos do Projeto Esta atividade consiste em realizar estimativas dos custos relativos a todos os recursos necessrios realizao das atividades do projeto. Sub-atividades: Registrar Elementos de Custos: Durante o planejamento do projeto, alguns recursos necessrios para desenvolv-lo so identificados. Por exemplo, no Plano do Processo de Desenvolvimento so indicados o hardware e software necessrios para desenvolver o projeto e no Plano de Recursos Humanos so indicadas as pessoas necessrias ao projeto. Nesta sub-atividade os elementos de custos j identificados so registrados no Plano de Custos e o gerente do projeto identifica aqueles que ainda no foram identificados, como por exemplo energia e aluguel. Atribuir valor para os Elementos de Custos: Durante esta sub-atividade, o gerente do projeto determina valores quantitativos e financeiros (custo
56
unitrio, quantidade e custo total) para os elementos de custos do projeto. O custo total de cada elemento identificado ser o produto de seu custo unitrio por sua quantidade utilizada. Para os recursos humanos e outros recursos vinculados execuo de atividades especficas do projeto, a quantidade utilizada poder ser obtida atravs da anlise dos dados do cronograma do projeto. Produto: Estimativas de custos do projeto. Responsvel: Gerente do projeto. ii. Elaborar Oramento do Projeto Consiste em utilizar os valores realizados na atividade anterior para elaborar o oramento do projeto, que ser o baseline dos custos5 para medir o desempenho do projeto. Durante esta atividade todos os elementos de custos e seus respectivos valores, identificados/registrados na atividade i, devem ser inseridos no oramento do projeto. Produto: Oramento do projeto. Responsvel: Gerente do projeto. iii. Controlar Oramento do Projeto Durante o desenvolvimento do projeto, o oramento deve ser comparado, analisado e revisto sempre que necessrio. O controle de custos envolve identificar e documentar o motivo das variaes, tanto positivas quanto negativas e adequar o oramento a elas. Sub-atividades: Registrar Desvios de Oramento: Durante o desenvolvimento de um projeto podem ocorrer desvios no oramento. Nesta sub-atividade o gerente do projeto registra esses desvios, justificando-os. Rever Desvios de Oramento: Durante esta sub-atividade o gerente do
projeto toma as aes corretivas ou contingenciais para os desvios
Baseline dos Custos o oramento referencial que ser utilizado para medir e monitorar o
desempenho dos custos do projeto. desenvolvido atravs da totalizao das estimativas de custos por perodo.
57
identificados. O gerente do projeto calcula o valor excedente, realiza a anlise e executa a soluo para tratar cada desvio identificado, procurando evitar que os custos ultrapassem a disponibilidade de recursos financeiros alocada ao projeto. As decises e aes corretivas a serem tomadas s devem ser feitas aps consideradas suas implicaes para o projeto. Comunicar Situaes de Risco: Nesta sub-atividade o gerente comunica s partes interessadas a ocorrncia de situaes de risco consequentes dos desvios do oramento. Produto: Oramento revisado. Responsvel: Gerente do projeto.
4.4 A Abordagem de Planejamento de Custos para a Estao TABA A Estao TABA tem como objetivo instanciar Ambientes de Desenvolvimento de Software destinados a apoiar as atividades realizadas ao longo de um projeto. Para isso, deve-se, inicialmente, definir o processo de desenvolvimento a ser utilizado no projeto e, em seguida, instanciar o ambiente para apoiar a execuo do processo. A abordagem proposta neste trabalho introduz o planejamento de custos Estao TABA, mais especificamente ao ADSOrg, uma vez que, at ento, no existiam ferramentas de apoio ao planejamento de custos nesses ambientes. A abordagem de apoio ao planejamento de custos proposta por este trabalho para a Estao TABA foi dividida em duas gerncias: gerncia de tempo e gerncia de custos do projeto. Como requisitos bsicos a serem atendidos pela abordagem para a gerncia de tempo tem-se: (1) apoiar a identificao das dependncias entre as atividades do processo de desenvolvimento; (2) apoiar a realizao das estimativas de durao das atividades do processo de desenvolvimento; (3) apoiar a elaborao do cronograma do projeto; e (4) apoiar o controle do cronograma do projeto. Como requisitos bsicos a serem atendidos pela abordagem para a gerncia de custos, tem-se: (1) apoiar a identificao dos elementos de custos do projeto; (2) apoiar a elaborao do oramento do projeto; e (3) apoiar o controle do oramento do projeto. Estes requisitos foram definidos tendo como base as
58
atividades que so realizadas ao longo do planejamento de custos de um projeto de software. A abordagem aqui descrita est inserida no contexto de Ambientes de Desenvolvimento de Software Orientados Organizao e pretende, alm de atender os requisitos acima, disponibilizar ao gerente de projeto todo o conhecimento de prazos e custos acumulado pelos vrios gerentes da organizao. Informaes sobre os prazos e custos praticados em projetos similares anteriormente realizados podem ajudar o gerente do projeto a refinar suas estimativas e torn-las mais prximas dos valores reais. Alm disso, as idias, diretrizes, problemas, dvidas e lies aprendidas relacionados gerncia de custos e registradas pelos gerentes de projetos anteriores podem apoiar no planejamento de custos de novos projetos. O conhecimento adquirido pelos usurios de um ADSOrg instanciado, ao longo das vrias atividades do processo de desenvolvimento, ser armazenado no repositrio do projeto. Alm disso, esse repositrio conter os dados do projeto de software como, por exemplo, sua equipe de desenvolvimento, processo utilizado, riscos identificados, custos estimados, dentre outros. O repositrio do projeto refletir sempre a atual situao do projeto de software associado ao ADSOrg instanciado. Quando o projeto concludo, os dados que representarem potenciais fontes de aprendizado organizacional sero copiados para o repositrio da organizao, que tem como objetivo armazenar o conhecimento obtido ao longo dos vrios projetos de software da organizao. O repositrio da organizao poder ser consultado durante o desenvolvimento de um projeto de software, visando a utilizao do conhecimento organizacional nas vrias atividades do processo de desenvolvimento de software. No que diz respeito ao conhecimento e dados relacionados ao planejamento de custos, o repositrio do projeto armazenar os valores referentes a prazo, esforo e custos envolvidos no projeto, as idias, sugestes e comentrios que surgirem ao longo do planejamento de custos do projeto, alm das lies aprendidas em gerncia de tempo e custos. No final do projeto, todo o conhecimento de prazos e custos adquirido durante o planejamento de custos ser copiado do repositrio do projeto para o repositrio da organizao, tornando-o, dessa forma, disponvel para futura utilizao. Alm disso, os
59
dados de prazos e custos do projeto tambm sero copiados para o repositrio da organizao, por representarem fontes importantes de aprendizado organizacional em gerncia de custos. A seguir ser descrito como as atividades relacionadas ao planejamento de custos sero realizadas em um ADSOrg. Os processos descritos na seo 4.3 foram modelados, buscando-se representar o conhecimento tcito e explcito necessrios e as ferramentas utilizadas em cada atividade dos processos. As atividades dos processos de gerncia de tempo e gerncia de custos sero abordadas, apresentando-se sua modelagem e como a abordagem proposta pretende apoiar sua realizao. Os processos foram modelados utilizando-se a abordagem de modelagem de processos organizacionais apresentada em VILLELA et al. (2001b), que permite a representao grfica do conhecimento e habilidades necessrios execuo das atividades do processo. A notao utilizada por esta abordagem descrita no Anexo 3.
4.4.1 Processo de Gerncia de Tempo

A abordagem proposta para o processo de gerncia de tempo em um ADSOrg envolve a execuo de cinco atividades: (1) Identificar dependncias entre as atividades; (2) Estimar a durao das atividades com abordagem top-down; (3) Estimar a durao das atividades com abordagem bottom-up; (4) Elaborar o cronograma do projeto; e (5)
Controlar o cronograma do projeto. Essas atividades foram descritas anteriormente, na definio do processo de gerncia de tempo. O processo de gerncia de tempo utilizado em dois momentos distintos: primeiro, para gerar as estimativas iniciais do projeto, com abrangncia macroscpica e, depois, para refinar essas estimativas. Ao estar realizando as estimativas iniciais, o gerente s tem acesso lista de atividades do processo de desenvolvimento, pois as sub-atividades s so exibidas no momento de refinamento das estimativas. A aquisio do conhecimento durante a execuo do processo feita atravs da interao da ferramenta CustPlan , objeto deste trabalho, com uma ferramenta de Aquisio de Conhecimento (MONTONI et al., 2002), que est sendo desenvolvida em outra tese de mestrado, com o objetivo de permitir o registro do conhecimento adquirido pelo usurio do ADSOrg durante as vrias atividades do processo. Atravs dessa ferramenta ser permitido
60
o registro de idias, dvidas, problemas encontrados, diretrizes e lies aprendidas pelo gerente do projeto durante a execuo das atividades do processo de gerncia de tempo. Aps serem registradas, essas informaes so, ento, filtradas e empacotadas para armazenamento no repositrio da organizao e vinculao ao processo e atividade adequados. A partir desse momento, o novo conhecimento (agora explcito) estar acessvel aos usurios da ferramenta CustPlan. A figura 4.2 apresenta a modelagem do processo de gerncia de tempo, detalhando suas atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios. O conhecimento tcito representado na figura a experincia em gerncia de tempo do gerente do projeto. Ao longo de todas as atividades do processo, o conhecimento tcito tem o mesmo significado. O conhecimento explcito est armazenado no repositrio da organizao e pode ser dados de projetos anteriores ou conhecimento adquirido de gerentes de projeto da organizao ao realizar as atividades deste processo.
Repositrio do Projeto
Repositrio da Organizao
CustPlan
Estimar durao das atividades com abordagem top-down

CustPlan CustPlan
CustPlan
Identificar dependncias entre as atividades
CustPlan
Elaborar Cronograma Estimar durao das atividades com abordagem bottom-up
Controlar Cronograma
Cronograma
Cronograma Revisto
Gerente do Projeto
Figura 4.2 Detalhamento do Processo de Gerncia do Tempo
61
4.4.1.1 Identificar Dependncias entre as Atividades do Projeto A abordagem proposta apia a identificao das dependncias entre as atividades do processo de desenvolvimento disponibilizando dados sobre as dependncias usuais6 entre as atividades, bem como outros conhecimentos relacionados atividade, disponveis no repositrio da organizao. Para a realizao dessa atividade, o gerente deve analisar as atividades/subatividades do processo instanciado e, para cada uma delas, indicar quais so as atividades/sub-atividades que necessitam estar concludas para que esta possa ser iniciada.
4.4.1.2 Estimar a durao das Atividades do Projeto com Abordagem Top-down Nessa atividade, o gerente, inicialmente, realiza as estimativas de todo o projeto ou de seus mdulos e, em seguida, distribui as estimativas entre as atividades/sub-atividades do projeto e/ou mdulo. Caso o gerente escolha estimar a durao das atividades de forma top-down, esta abordagem apoiar a realizao das estimativas de durao das atividades do processo de desenvolvimento atravs de dois modelos paramtricos (Anlise de Pontos de Funo e COCOMO II), da disponibilizao de dados sobre prazo e esforo em projetos similares anteriores e da possibilidade de consulta ao conhecimento disponvel no repositrio da organizao relativo a essa atividade. Para realizar as estimativas das atividades do projeto com a abordagem top-down, o gerente, inicialmente, deve utilizar os modelos paramtricos Anlise de Pontos de Funo e COCOMO II para realizar as estimativas de todo o projeto ou de seus mdulos. Em seguida, o gerente do projeto deve refinar essas estimativas analisando dados de projetos similares anteriores e utilizando sua experincia pessoal para decidir as estimativas finais. Quando um modelo paramtrico utilizado, os parmetros e constantes a ele pertinentes so obtidos no repositrio da organizao, bem como os dados de projetos similares. As estimativas obtidas so, ento, armazenadas no repositrio do projeto. As estimativas realizadas atravs dos modelos paramtricos tambm sero armazenadas no repositrio do
6
O conhecimento disponibilizado sobre as dependncia usuais resultado de pesquisa com
especialistas sobre as dependncias entre as atividades do processo de desenvolvimento da ISO 12207, apresentada no captulo 5 e descrita no Anexo 4.
62
projeto e com a concluso do projeto sero copiadas para o repositrio da organizao. Isso possibilitar a anlise e comparao com os valores realmente praticados, fornecendo assim o grau de acerto das tcnicas utilizadas pela organizao. Aps realizar as estimativas para todo o projeto ou para seus mdulos, o gerente deve distribu-las entre as atividades/sub-atividades envolvidas no desenvolvimento do projeto/mdulos. Para isso, o gerente pode consultar dados de projetos anteriores para orient-lo na distribuio das estimativas. A disponibilizao desses dados fornecer o prazo e esforo de uma determinada atividade em cada projeto similar encontrado e a relao desses valores com os valores totais do projeto. Por exemplo, o gerente pode observar que em um determinado projeto a atividade Anlise de Requisitos do Sistema foi realizada em vinte dias e o projeto foi realizado em cem dias. Ou seja, a atividade em questo consumiu 20% do tempo do projeto. Com base nesses dados, o gerente realiza a distribuio das estimativas totais entre as atividades do projeto /ou seus mdulos. A figura 4.3 apresenta a modelagem da atividade Estimar a durao das Atividades do Projeto com abordagem Top-down , detalhando suas sub-atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios.
CustPlan
CustPlan
CustPlan
Realizar Estimativas utilizando Mtodos Paramtricos
Ajustar estimativas atravs de dados de projetos similares
Distribuir o tempo entre as atividades/ sub-atividades
Gerente do Projeto
Figura 4.3 Detalhamento da atividade Estimar a Durao das atvidades do Projeto com Abordagem Top-down
63
4.4.1.3 Estimar a durao das Atividades do Projeto com Abordagem Bottom-up Caso seja escolhida a abordagem bottom-up, esta atividade apoiar a realizao das estimativas de durao das atividades/sub-atividades do processo de desenvolvimento atravs da disponibilizao de dados sobre prazo e esforo em projetos similares anteriores e atravs da possibilidade de consulta a outros tipos de conhecimento disponveis no repositrio da organizao relativos a essa atividade. O gerente realiza as estimativas para as atividades/sub-atividades. As estimativas totais do projeto e/ou de seus mdulos so obtidas pelo somatrio das estimativas para as suas atividades/sub-atividades.
4.4.1.4 Elaborar Cronograma Para elaborar o cronograma, inicialmente, devem ser identificados os caminhos crticos do projeto. Como mencionado anteriormente, um caminho crtico uma seqncia de atividades tais que, se houver atraso em alguma delas, esse atraso ser transmitido ao trmino do projeto. A identificao dos caminhos crticos ser realizada, utilizando o algoritmo do Critical Path Method - CPM (PRADO, 1998), que verifica as dependncias entre as atividades e suas duraes e indica quais so os caminhos crticos do projeto. Aps serem identificados os caminhos crticos, o gerente determina as datas de incio e fim das atividades, observando sua durao, dependncias e caminhos crticos identificados. Um dos planos que fazem parte do Plano do Projeto o Plano de Acompanhamento, onde so identificados os marcos e pontos de controle do projeto. O gerente deve, neste momento, registrar esses marcos e pontos de controle no cronograma do projeto. A figura 4.4 apresenta a modelagem da atividade Elaborar Cronograma do Projeto, detalhando suas sub-atividades e ferramentas utilizadas.
64
CustPlan CustPlan CustPlan
Identificar caminhos crticos do projeto
Determinar datas de incio e fim das atividades do projeto
Registrar marcos e pontos de controle
Gerente do Projeto
Figura 4.4 Detalhamento da atividade Elaborar Cronograma do Projeto
4.4.1.5 Controlar Cronograma Durante o desenvolvimento de um projeto podem ocorrer desvios no cronograma do projeto. O gerente de projeto deve registrar esses desvios, identificando em qual(is) atividades ocorreram e o motivo de sua ocorrncia. Aps serem registrados os desvios, o gerente deve rever o cronograma considerando: a) A possibilidade de recuperao do desvio do cronograma, revendo-o de forma a buscar alcanar o prximo marco do projeto na data prevista e garantindo o trmino do projeto na data esperada; b) Caso no haja possibilidade de recuperao do atraso, o gerente deve rever o cronograma como um todo e negociar com as partes envolvidas. Para identificar as aes corretivas a serem tomadas, o gerente do projeto deve analisar as razes dos desvios, podendo consultar o conhecimento disponvel no repositrio da organizao. O gerente pode tambm analisar as outras atividades do projeto onde tambm ocorreram atrasos e as razes que motivaram os desvios. Identificadas as aes corretivas e tendo sido alterado o cronograma, as mudanas devem ser comunicadas a todas as partes envolvidas.
65
A figura 4.5 apresenta a modelagem da atividade Controlar Cronograma do Projeto , detalhando suas sub-atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios.
Registrar desvios de cronograma
Rever cronograma
Comunicar alterao no cronograma
Cronograma revisto
Gerente do Projeto
Figura 4.5 Detalhamento da atividade Controlar Cronograma do Projeto
4.4.2 Processo de Gerncia de Custos

A abordagem proposta para o processo de gerncia de custos em um ADSOrg envolve a execuo de trs atividades: (1) Estimar custos; (2) Elaborar o oramento do projeto; e (3) Controlar o oramento do projeto. Essas atividades foram descritas anteriormente, na definio do processo de gerncia de custos. Assim como no processo de gerncia de tempo, a aquisio do conhecimento durante a execuo do processo feita atravs da interao da ferramenta CustPlan com uma ferramenta de Aquisio de Conhecimento que permite o registro do conhecimento adquirido pelo usurio do ADSOrg durante as vrias atividades do processo e armazena o conhecimento no repositrio da organizao. A partir desse momento, o novo conhecimento estar acessvel aos usurios da ferramenta CustPlan .
66
A figura 4.6 apresenta a modelagem do processo de gerncia de custos, detalhando suas atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios. O conhecimento tcito representado na figura a experincia em gerncia de custos do gerente do projeto. Ao longo de todas as atividades do processo, o conhecimento tcito tem o mesmo significado. O conhecimento explcito est armazenado no repositrio da organizao e pode ser dados de projetos anteriores ou conhecimento adquirido de gerentes de projeto da organizao ao realizar as atividades deste processo.
Repositrio do Repositrio da Projeto Organizao
Estimar Custos
Elaborar Oramento
Controlar Oramento
Oramento
Oramento Revisto
Gerente do Projeto
Figura 4.6 Detalhamento do Processo de Gerncia de Custos
4.4.2.1 Estimar Custos do Projeto Para realizar a estimativa dos custos do projeto, o gerente, inicialmente, deve identificar os elementos de custos. Alguns desses elementos j foram identificados em outros planos do Plano do Projeto, como por exemplo no Plano de Recursos Humanos que define a equipe do projeto. Uma lista com todos os elementos de custos j identificados fornecida ao gerente. Os elementos que no foram identificados, como por exemplo gastos com energia e aluguel , devem ser includos na lista pelo gerente do projeto. Para cada elemento de custo identificado, o gerente deve determinar a quantidade que ser utilizada e o custo financeiro correspondente. Para isso, o gerente deve consultar o
67
custo unitrio de cada elemento no repositrio da organizao, que dever t-los sempre atualizado. A figura 4.7 apresenta a modelagem da atividade Estimar Custos do Projeto, detalhando suas sub-atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios.
Repositrio do Projeto Repositrio da Organizao
CustPlan CustPlan
Identificar elementos de custos
Atribuir valores aos elementos de custos
Gerente do Projeto
Figura 4.7 Detalhamento da atividade Estimar Custos do Projeto
4.4.2.2 Elaborar Oramento do Projeto A elaborao do oramento do projeto consiste na distribuio dos custos identificados na atividade anterior (4.4.2.1) ao longo do desenvolvimento do projeto, ou seja, elaborado um cronograma financeiro que contm as receitas previstas para o projeto, as despesas e suas respectivas datas. Conforme apresentado no processo de gerncia de custos, a alocao das estimativas dos custos globais aos itens individuais de trabalho com a finalidade de estabelecer um baseline dos custos para medir o desempenho do projeto. Para elaborar o oramento, o gerente pode consultar o conhecimento disponvel no repositrio da organizao e til na realizao dessa atividade.
68
4.4.2.3 Controlar Oramento do Projeto Durante o desenvolvimento de um projeto podem ocorrer desvios no oramento do projeto que devem ser registrados pelo gerente. Aps o registro, o gerente deve, ento, corrigir o oramento para que o mesmo se adeque aos desvios registrados. O gerente do projeto deve analisar os desvios e tomar medidas para evitar que os custos ultrapassem a disponibilidade de recursos financeiros alocada ao projeto, podendo consultar o conhecimento disponvel no repositrio da organizao. Se necessrio, situaes graves com relao ao oramento, que coloquem em risco o projeto, devem ser comunicadas s partes interessadas. A figura 4.8 apresenta a modelagem da atividade Controlar Oramento do Projeto , detalhando suas sub-atividades, ferramentas utilizadas e conhecimento tcito e explcito necessrios.
Identificar desvios de oramento
Rever oramento
Comunicar situao de risco
Oramento Revisto
Gerente do Projeto
Figura 4.8 Detalhamento da atividade Controlar Oramento do Projeto
69
4.5 Consideraes Finais Este captulo apresentou uma abordagem para o planejamento de custos em projetos de software fundamentada nos conceitos de gerncia do conhecimento e Ambientes de Desenvolvimento de Software Orientados Organizao. A abordagem prope a utilizao, durante o planejamento de custos, do conhecimento disponvel no repositrio da organizao referente s atividades dos processos de gerncia de tempo e custos e de dados de projetos anteriores similares. Tambm foram apresentados os processos de gerncia de tempo e gerncia de custos definidos e suas abordagens na Estao TABA. Uma ferramenta de Aquisio de Conhecimento (MONTONI et al., 2002) permitir o registro do conhecimento obtido durante a execuo dos processos de gerncia de tempo e gerncia de custos. Uma interface da CustPlan com essa ferramenta permitir o acesso ao conhecimento disponvel no repositrio da organizao. Os resultados esperados pela utilizao da abordagem apontam para o refinamento das estimativas, possibilitando a realizao de estimativas que se aproximem o mximo possvel dos valores realmente praticados, principalmente atravs do acesso ao conhecimento acumulado na organizao e relevante para essa atividade.
70
Captulo 5 A Ferramenta CustPlan

Neste captulo apresentada a ferramenta CustPlan, desenvolvida na Estao TABA para apoiar o Planejamento de Custos em ADSOrg.
5.1 Introduo
Buscando-se apoiar a abordagem de planejamento de prazos e custos em ADSOrg na Estao TABA, foi implementada a ferramenta CustPlan, que apia as atividades presentes captulo 4. CustPlan disponibilizada em um ADSOrg instanciado e, dessa forma, possibilita a utilizao do conhecimento organizacional armazenado no repositrio da organizao. CustPlan faz parte das ferramentas disponibilizadas ao usurio do ADS durante a atividade de Planejamento do Projeto, mais especificamente durante a realizao das atividades Planejamento de Tempo e Planejamento de Custos. Este captulo apresenta, na seo 5.2, a caracterizao de projetos realizada na Estao TABA para a recuperao de projetos similares. Em seguida, na seo 5.3, apresentada a descrio da pesquisa realizada com gerentes para determinar as dependncias usuais entre as atividades do processo de desenvolvimento. Na seo 5.4 a ferramenta CustPlan apresentada e na seo 5.5 so apresentadas as consideraes finais. nos processos de gerncia de tempo e gerncia de custos apresentados no
5.2 Caracterizao de Projetos na Estao TABA
A caracterizao de projetos de software na Estao TABA tem como objetivo permitir o agrupamento de projetos que possuem caractersticas semelhantes sob um determinado aspecto. O agrupamento de projetos similares permite que sejam realizadas as analogias com os dados de projetos anteriormente realizados quando se trata de planejamento de prazos e custos. Porm, outras reas tambm tm interesse em agrupar os
71
A Ferramenta CustPlan ________________________________________________________________________________________
projetos, como por exemplo a anlise de riscos, que procura por conhecimento acumulado de riscos que esto presentes em projetos similares. Sendo assim, os critrios de caracterizao propostos foram separados em dois grandes grupos: critrios genricos e critrios especficos. Os critrios genricos so os que podem caracterizar um projeto independente da finalidade para o qual a caracterizao ser utilizada. Os critrios especficos so aqueles que so definidos de acordo com a finalidade da caracterizao. Por exemplo, para traar perfis de projetos para realizar analogias para determinao de prazos e custos, um critrio especfico importante pode ser Restrio de Cronograma, que indica que o tempo para desenvolvimento do projeto pr-estabelecido (como em um desenvolvimento de um site que precisa estar ativo em 3 meses). A determinao dos critrios genricos de um projeto obrigatria, ou seja, esses critrios precisam ser informados para que o agrupamento de projetos similares seja realizado. Os critrios especficos devem ser informados de acordo com a finalidade da caracterizao de projetos na Estao TABA. Para utilizar os critrios de caracterizao deve ser determinado um mecanismo de busca por projetos considerados similares segundo os critrios estabelecidos. Porm, essa no uma tarefa simples. SHEPPERD e SCHOFIELD (1997) relatam problemas encontrados na busca por projetos similares. Usando a similaridade para estimar o esforo de desenvolvimento de software baseado em analogia, SHEPPERD e SCHOFIELD (1997) propem uma abordagem na qual os projetos similares so encontrados medindo-se a distncia Euclidiana em um espao n-dimensional onde cada dimenso corresponde a uma varivel (um critrio de caracterizao). A limitao desta abordagem que ela no trabalha com variveis medidas em escalas nominais (exemplo: domnio de aplicao). Como j mencionado no captulo 2, IDRI e ABRAN (2001) consideram que a similaridade de projetos de software no tem sido assunto de estudos detalhados, apesar de ser frequentemente utilizada em estimativas de esforo de desenvolvimento de software baseadas em analogia. Eles propem a utilizao de um modelo baseado em lgica Fuzzy para definir as mtricas de similaridade dos projetos de software e, ento, superar a limitao de no poder trabalhar com atributos de projeto medidos em escalas nominais .
72
PRIETO-DIAZ (1991), em estudos para recuperao de componentes similares, props a classificao facetada . A proposta do autor pode ser adaptada para tornar possvel a recuperao de projetos similares. Neste trabalho no foi determinado o mecanismo de busca por projetos similares, dada a complexidade de tal tarefa. Inicialmente, a busca ser realizada atravs da igualdade de todos os critrios avaliados. Futuramente, uma tcnica de busca por projetos similares dever ser desenvolvida. As tabelas a seguir apresentam os critrios de caracterizao genricos e especficos propostos para a Estao TABA. Os critrios foram escolhidos com base na literatura, principalmente nas propostas de JONES (2000), e levando-se em considerao os critrios que j estavam presentes na Estao TABA.
Critrio Indstria
Tipo de Software
Paradigma Natureza do Projeto
Descrio Define a indstria na qual o software est inserido. Podese usar a classificao padro de indstrias para determinar o conjunto de indstrias existentes. Exemplos so Extrao de leo e gs; Indstrias de refinaria de petrleo e relacionadas; Comunicao, Servios de Transporte (JONES, 2000). Define a rea de aplicao qual o software se destina. Exemplos de tipos de software so: Sistemas Especialistas, Sistemas de Informao, Softwares Embutidos, Sistemas Militares, etc. Indica o paradigma utilizado no desenvolvimento do projeto. Ex.: Estrutural, Orientao a Objetos, etc. Indica se o projeto um projeto de desenvolvimento ou se envolve alguma forma de manuteno. As possveis naturezas de projeto so: novo desenvolvimento, melhoria (adio de funes), atualizao para atender a novas regulamentaes, reparo de defeitos, melhoria de performance, migrao para nova plataforma, nacionalizao, reengenharia, atualizao em massa (por exemplo: Euro e ano 2000), hbrida (JONES, 2000).
Tabela 5.1 Critrios Genricos de Caracterizao de Projetos de Software
73
Critrio Nvel de experincia gerentes do projeto
Descrio dos Indica o nvel de experincia da gerncia do projeto com Engenharia de Software, com a plataforma de desenvolvimento, a tecnologia utilizada e por ltimo com o domnio da aplicao (JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN, 2001). Para diminuir a subjetividade deste critrio so utilizados 5 valores possveis para cada tpico de experincia: 0 nenhuma experincia; 1 treinamento acadmico; 2 prtica em at trs projetos; 3 experiente; 4 capaz de orientar outros (GOMES, 2001). Nvel de experincia da equipe Indica o nvel de experincia da equipe de de desenvolvimento desenvolvimento com Engenharia de Software, com a plataforma de desenvolvimento, a tecnologia utilizada e por ltimo com o domnio da aplicao (JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN, 2001). Para diminuir a subjetividade deste critrio so utilizados 5 valores possveis para cada tpico de experincia: 0 nenhuma experincia; 1 treinamento acadmico; 2 prtica em at trs projetos; 3 experiente; 4 capaz de orientar outros (GOMES, 2001). Nvel de experincia dos Indica o nvel de experincia do cliente com ciclo de vida clientes de desenvolvimento de software e com o domnio da aplicao (JONES, 2000). Distribuio geogrfica da Indica se a equipe est centralizada ou dispersa equipe geograficamente (JONES,2000). Restrio de Cronograma Indica se o projeto possui alguma restrio de cronograma Restrio de Desempenho ou Indica se o projeto possui alguma restrio de desempenho Tempo de Execuo ou tempo de execuo (JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN, 2001). Restrio de Segurana Indica se o projeto possui alguma restrio de segurana (JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN, 2001). Restrio de Recursos Indica se o projeto possui alguma restrio de recursos Humanos humanos. Uso de Tecnologia inovadora Indica se o projeto possui algum grau de inovao relacionada a plataforma utilizada, linguagem de programao utilizada, arquitetura do projeto, etc. Tabela 5.2 Critrios Especficos de Caracterizao de Projetos de Software
O projeto de software caracterizado, inicialmente, no meta ambiente, no momento da definio do projeto. Antes que um ADS seja instanciado, ele caracterizado e tem seu processo de desenvolvimento definido. A figura 5.1 ilustra a tela de Registro do Projeto, onde as informaes bsicas do projeto so fornecidas. A figura 5.2 exibe a tela onde as caractersticas gerais so preenchidas.
74
Figura 5.1 Registro de um projeto de software na Estao TABA.
Figura 5.2 Caracterizao de um projeto de software na Estao TABA.
Aps o projeto ter sido registrado e caracterizado de forma geral, seu processo de desenvolvimento definido e instanciado. A figura 5.3 ilustra a tela de um ambiente instanciado, destacando a atividade de Planejamento do Projeto.
75
Figura 5.3 Ambiente Instanciado pela Estao TABA.
Como pode ser visto na figura, a tela do ambiente instanciado na Estao TABA contm as atividades do processo de desenvolvimento e as ferramentas que podem ser utilizadas para a realizao de cada uma dessas atividades. Essa interface proporciona ao engenheiro de software uma viso geral de todas as atividades associadas ao processo, bem como a relao de hierarquia e ordem de execuo entre elas. Na figura 5.3 encontra-se selecionada a atividade Atividades Iniciais do Planejamento do Projeto. A atividade permite a caracterizao especfica do projeto de software. A ferramenta Caracterizar uma ferramenta que guia o engenheiro de software durante o preenchimento dos critrios especficos de caracterizao do projeto. A figura 5.4 mostra uma das telas da ferramenta Caracterizar onde os critrios relacionados equipe do projeto so preenchidos.
76
Figura 5.4 Caracterizao especfica de um projeto de software na Estao TABA.
5.3 Pesquisa de Dependncias Usuais entre as Atividades do Processo de Desenvolvimento O primeiro passo para realizar o planejamento do cronograma do projeto indicar as dependncias entre as atividades do projeto, conforme apresentado no processo de gerncia de tempo, descrito no captulo 4. Para realizar esse passo utilizando CustPlan, o gerente de projetos poder consultar no repositrio da organizao as dependncias usuais entre as atividades do processo de desenvolvimento. Para coletar as dependncias usuais, foi realizada uma pesquisa cujos participantes foram gerentes de projetos de software da Fundao COPPETEC (Coordenao de Projetos, Pesquisas e Estudos Tecnolgicos) e outros gerentes de projetos que atuam em processos de desenvolvimento do software. Foram considerados 8 gerentes de projeto, sendo estes mestres ou doutores na rea de informtica e com experincia relevante em gerncia de projetos de software. A pesquisa foi realizada utilizando-se um questionrio que considerou as atividades do processo de desenvolvimento da ISO/IEC 12207 - Tecnologia de Informao Processos de ciclo de vida de software. O questionrio apresentou uma tabela onde o participante indicou, para cada atividade do processo, suas pr-atividades, ou seja, as atividades que precisam estar concludas para que ela possa ser realizada. Foi permitido ao participante registrar consideraes sobre as dependncias e comentrios em geral.
77
Com base nos dados coletados, um conjunto de dependncias usuais entre as atividades do processo de desenvolvimento da ISO/IEC 12207 foi proposto e armazenado no repositrio da organizao para ser utilizado durante a atividade Identificar as Dependncias entre as Atividades do Projeto realizada no planejamento do cronograma do projeto. Para a realizao dessa pesquisa foram seguidas cinco atividades: (i) definio; (ii) planejamento; (iii) operao; (iv) anlise e interperetao; e (v) apresentao. O ponto de partida foi a concepo da idia da pesquisa, onde foi avaliado se uma pesquisa era realmente necessria e apropriada para atender as questes a serem investigadas. Dando incio ao processo de realizao da pesquisa propriamente dito, na atividade definio a pesquisa foi definida em termos do problema pesquisado, seus objetivos e metas. Na atividade de planejamento , o projeto da pesquisa foi realizado, a instrumentao foi elaborada e as ameaas perfeita execuo da pesquisa foram avaliadas. Durante esta atividade foi gerado o documento de planejamento da pesquisa, descrito no Anexo 4. Na atividade operao, os questionrios foram entregues aos participantes e os dados obtidos foram organizados em uma planilha visando facilitar a anlise e avaliao dos dados realizada na atividade posterior de anlise e interpretao. Finalmente os resultados foram apresentados na atividade apresentao.
5.3.1 Resultados da Pesquisa

Os resultados da pesquisa caracterizaram um conjunto inicial de dependncias usuais entre as atividades do processo de desenvolvimento da NBR ISO/IEC 12207 que foi armazenado no repositrio da organizao para apoiar os gerentes de projeto na identificao das dependncias entre as atividades do projeto. Para realizar a pesquisa, um conjunto inicial de dependncias foi proposto, porm, os participantes da pesquisa no tiveram acesso s dependncias presentes nesse conjunto. Para obter os resultados, inicialmente, as caractersticas dos participantes da pesquisa foram analisadas e, em seguida, foram estabelecidos pesos para cada um deles, considerando o tempo de atuao em gerncia de projetos, o nmero de projetos gerenciados, a experincia em processos de software e o conhecimento sobre a norma
78
NBR ISO/IEC 12207 de cada participante. A anlise das caractersticas e clculo dos pesos dos participantes os classificou em dois grupos: experientes e pouco experientes. Foi, ento, estabelecido o valor do ponto de incluso, para indicar o valor a partir do qual uma dependncia identificada pelos participantes faria parte do conjunto final de dependncias. Analisadas as dependncias identificadas por cada participante, foi possvel perceber que os participantes pertencentes ao grupo experiente identificaram as dependncias presentes no conjunto inicial proposto, mesmo sem terem tido acesso a ele. Por outro lado, alguns participantes do grupo pouco experiente identificaram muitas dependncias incoerentes. Utilizando os pesos dos participantes e o critrio de incluso de uma dependncia no conjunto de dependncias (valor do ponto de incluso), o conjunto de dependncias obtido foi igual ao conjunto inicialmente proposto. A tabela 5.3 apresenta o conjunto de dependncias usuais obtido como resultado da pesquisa. A descrio detalhada da pesquisa contendo seu objetivo, apresentao do questionrio e resultados obtidos realizada no Anexo 4.
79
A Ferramenta CustPlan __________________________________________________________________________________________________________________________________
Atividades que precisam estar concludas
Anlise dos Requisitos do Sistema
Anlise dos Requisitos do Software
Instalao do Software
Integrao do Sistema
Integrao do Software
Projeto da Arquitetura do Sistema Projeto da Arquitetura do Software
Teste de Qualificao do Sistema
Apoio aceitao do Software
Codificao e Testes do Software
Anlise dos Requisitos do Sistema: descrio das funes, capacidades, requisitos e restries do sistema. Anlise dos Requisitos do Software: descrio das funes, capacidades, requisitos e restries de cada item de software do sistema. Apoio aceitao do Software: acompanhamento utilizao do software.
X X X X X X X X X X
Implementao do processo
X X X X X X X X X X X
Codificao e Testes do Software: implementao e testes do software e bases de dados.
Implementao do processo : Definio do modelo de ciclo de vida, atividades e tarefas do projeto.
Instalao do Software: implantao do software no ambiente do 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
Projeto Detalhado do Software
X X X
Integrao do Sistema: integrao dos itens de software ao sistema.
Integrao do Software: integrao dos componentes que compem cada item de software.
Projeto da Arquitetura do Sistema: definio dos itens de hardware, software e operaes do sistema.
X X X X X X X x X X X X X
Projeto da Arquitetura do Software: definio dos itens de hardware, software e operaes do sistema de cada item de software do sistema. Projeto Detalhado do Software: refinamento do projeto da arquitetura de cada componente de software, interface e bases de dados. Teste de Qualificao do Sistema: realizao de testes segundo os requisitos de qualidade estabelecidos para o sistema. Teste de Qualificao do Software: realizao de testes segundo os requisitos de qualidade estabelecidos para cada item de software.
Tabela 5.3 Conjunto final de dependncias usuais entre as atividades do processo de desenvolvimento.
80
Teste de Qualificao do Software
Atividades do Processo de Desenvolvimento da NBR ISO/IEC 12207 -- Tecnologia de Informao Processos de ciclo de vida de software que devem ser executadas
X X
5.4 A Ferramenta CustPlan Como mencionado anteriormente, a ferramenta CustPlan foi desenvolvida para apoiar o planejamento de custos nos Ambientes de Desenvolvimento de Software Orientados Organizao. Para prover esse apoio, a ferramenta utilizada para planejar o tempo e os custos propriamente ditos, sendo acessada em diversos momentos durante a execuo do processo de desenvolvimento. O acesso CustPlan feito atravs da tela principal de um ADSOrg instanciado. Essa tela contm as atividades do processo de desenvolvimento e as ferramentas que podem ser utilizadas para a realizao de cada uma dessas atividades. Essa interface proporciona ao engenheiro de software uma viso geral de todas as atividades associadas ao processo, assim como a relao de hierarquia e ordem de execuo entre elas. Para apoiar os processo de gerncia de tempo e gerncia de custos, CustPlan foi dividida em duas partes: tempo e custos. Inicialmente, o gerente utiliza CustPlan para realizar o planejamento do cronograma do projeto, ainda com uma viso macroscpica, considerando apenas as atividades do processo de desenvolvimento. Aps o cronograma ser elaborado, o gerente realiza a alocao dos recursos humanos s atividades do projeto, utilizando a ferramenta RHPlan (SCHNAIDER, 2003). Em seguida, o gerente volta a utilizar a CustPlan, agora para elaborar o oramento do projeto, baseando-se no cronograma e alocao de recursos realizada. Aps a especificao de requisitos do sistema estar concluda, o gerente utiliza CustPlan para refinar o cronograma e o oramento do projeto, considerando tambm as sub-atividades do processo de desenvolvimento e as informaes obtidas durante a elaborao da especificao de requisitos.
5.4.1 Planejamento do Tempo

O primeiro acesso CustPlan realizado para apoiar a realizao das primeiras estimativas de tempo do projeto. feito quando o gerente seleciona, no ADSOrg instanciado, a sub-atividade Planejamento Inicial do Tempo, presente na atividade Planejamento do Projeto. Nesse momento, um cone da CustPlan fica disponvel no lado direito da tela.
81
Figura 5.5 Tela principal de um ADSOrg instanciado com acesso CustPlan para Planejamento do Tempo
Para realizar o planejamento do tempo, a CustPlan apia as seguintes atividades: (i) Identificar dependncias entre as atividades do projeto; (ii) Estimar a durao das atividades do projeto; (iii) Elaborar o cronograma do projeto; e, (iv) Controlar o cronograma do projeto. Durante o planejamento inicial do tempo, como j mencionado, apenas as atividades do processo de desenvolvimento so consideradas. As sub-atividades sero consideradas no momento de refinar as estimativas geradas durante o planejamento inicial.
5.4.1.1 Identificar Dependncias entre as Atividades do Projeto Para identificar as dependncias entre as atividades do projeto, o gerente realiza a atividade Identificar Dependncias situada do lado esquerdo na tela da CustPlan. O gerente identifica as dependncias de cada atividade do processo de desenvolvimento (exibidas no quadro Atividades ) marcando no checklist Pr-Atividades as atividades do processo de desenvolvimento que devem estar concludas para que a atividade selecionada no quadro Atividades possa ser executada. O gerente pode consultar uma lista de dependncias usuais entre as atividades do processo de desenvolvimento da ISO 12207, disponibilizada
82
no quadro Conhecimento de Especialistas, para apoi-lo na identificao das dependncias.
Figura 5.6 Tela de Identificao das dependncias entre as atividades do projeto
Note que a interface da CustPlan prov a visualizao do processo que est sendo realizado (tempo ou custos) e suas atividades. No lado esquerdo possvel identificar o processo e no lado direito da interface identifica-se a atividade que est sendo realizada pelo gerente. Os cones localizados no canto superior direito da tela permitem a realizao de consulta e registro de conhecimento pertinentes s atividades do processo. O gerente do projeto pode consultar o conhecimento registrado por outros gerentes de projetos e registrar o conhecimento adquirido por ele durante a execuo da atividade. Ao longo dos processos de gerncia de tempo e custos, CustPlan disponibiliza o conhecimento explcito armazenado para a atividade que est sendo realizada pelo gerente. A figura 5.7 apresenta a tela de consulta ao conhecimento armazenado no repositrio da organizao, ilustrando a consulta ao conhecimento armazenado para a atividade Identificar dependncias entre as atividades do projeto , do processo de gerncia de tempo . Esta tela acessada atravs do cone situado na parte superior da tela, mais direita (lmpada).
83
Figura 5.7 Tela de consulta ao conhecimento armazenado no repositrio da organizao
O cone em forma de interrogao situado no canto superior direito da tela da CustPlan realiza a interface com a ferramenta de Aquisio de Conhecimento, onde o gerente pode registrar o conhecimento adquirido durante a execuo das atividades dos processos. 5.4.1.2 Estimar Durao das Atividades do Projeto Para estimar a durao das atividades do projeto, o gerente deve, inicialmente, selecionar a atividade Escolher Abordagem na ferramenta. Nessa tela, o gerente indica qual ser a abordagem utilizada para estimar a durao das atividades do projeto: abordagem top-down ou abordagem bottom-up. importante ressaltar que o gerente poder utilizar apenas uma das abordagens.
84
Figura 5.8 Tela de Escolha da abordagem para estimar a durao das atividades do projeto
Aps escolhida a abordagem, o gerente realiza as estimativas de acordo com a abordagem por ele determinada.
(a) Suponhamos que o gerente tenha escolhido a abordagem Top-down.
Conforme mencionado no captulo 2, a associao de tipos de modelos diferentes para realizar as estimativas de projetos tem-se mostrado o caminho mais eficiente.
Baseando-se nesses resultados, CustPlan permite, atravs da abordagem top-down de realizao de estimativas, que o gerente realize as estimativas utilizando modelos paramtricos, analogia de estimativas e que utilize o conhecimento organizacional e sua experincia pessoal para decidir os valores das estimativas do projeto.
85
Para realizar as estimativas segundo essa abordagem, o gerente, inicialmente, seleciona a sub-atividade Realizar as estimativas do projeto utilizando Anlise de Pontos de Funo. Na tela em questo, o gerente escolhe o critrio de realizao das estimativas: para todo o projeto ou para um mdulo especfico. Se for para um mdulo do projeto o gerente indica qual mdulo ser analisado. Em seguida, o gerente determina o nmero de arquivos lgicos internos e de arquivos de interface externa do sistema e, para cada um deles, o nmero de tipos de elementos de dados e de tipos de elementos de registros. O gerente indica, tambm, o nmero de entradas, sadas e consultas externas do sistema e, para cada uma delas, o nmero de arquivos referenciados e de elementos de dados envolvidos.
Figura 5.9 Tela de Realizao das estimativas do projeto utilizando Anlise de Pontos de Funo Contagem das Funes
Aps a contagem das funes, o gerente fornece o nvel de influncia de 14 caractersticas para o projeto, para que seja realizado o clculo do fator de ajuste.
86
Figura 5.10 Tela de Realizao das estimativas do projeto utilizando Anlise de Pontos de Funo Clculo do Fator de Ajuste
O gerente, ento, fornece valores de referncia (tempo e esforo de um ponto de funo na organizao) para a realizao do clculo das estimativas. Fornecidos todos os valores de entrada, o gerente clica no boto Calcular Estimativas e estas so calculadas.
Figura 5.11 Tela de Realizao das Estimativas do projeto utilizando Anlise de Pontos de Funo Clculo das Estimativas
87
Caso o gerente no informe o esforo de referncia para um ponto de funo, a tcnica considera o esforo de uma pessoa para o projeto. O gerente poder ajustar essa estimativa posteriormente. Aps utilizar a tcnica Anlise de Pontos de Funo para realizar as estimativas, o gerente seleciona a atividade Realizar Estimativas utilizando COCOMO II. Para realizar as estimativas utilizando o COCOMO II, o gerente escolhe o modelo que ser utilizado (Pr-Projeto ou Ps-Arquiterura). O critrio de realizao das estimativas para todo o projeto ou por mdulos permanece o mesmo que foi determinado na Anlise de Pontos de Funo. O gerente indica, tambm, a linguagem de programao que ser utilizada no projeto. Em seguida, determina os nveis de influncia dos fatores de equilbrio e direcionadores de custos para o projeto em questo.
Figura 5.12 Tela de Realizao das estimativas do projeto utilizando COCOMO II Fatores de Equilbrio
88
Figura 5.13 Tela de Realizao das estimativas do projeto utilizando COCOMO II Direcionadores de Custos e Clculo das Estimativas
Aps utilizar o COCOMO II, o gerente analisa os valores das estimativas obtidas por essa tcnica e pela Anlise de Pontos de Funo, realiza a analogia de estimativas e utiliza sua experincia pessoal para decidir as estimativas do projeto. Para isso, ele deve selecionar a sub-atividade Ajustar Estimativas a partir de Projetos Similares. Nesta sub-atividade, o gerente compara as estimativas geradas pelas tcnicas utilizadas e visualiza dados de projetos anteriores que iro auxili-lo na deciso dos valores das estimativas do projeto. Para selecionar os projetos similares, o gerente indica no checklist Critrios de Caracterizao do Projeto os critrios que devem ser utilizados na seleo dos projetos similares. Em seguida, o gerente escolhe a opo de filtro da pesquisa e clica no boto Pesquisar. Os projetos similares so exibidos juntamente com os valores de prazo e esforo para eles realizados. Analisando os dados dos projetos similares e os valores das estimativas do projeto geradas pelas tcnicas paramtricas APF e COCOMO II, o gerente utiliza sua experincia e
89
determina os valores que sero efetivamente estimados para o projeto registrando-os no quadro Valores das Estimativas.
Figura 5.14 Tela de Ajuste das estimativas a partir de dados de projetos similares
Decididos os valores das estimativas de prazo e esforo, estes devem ser distribudos entre as atividades do processo de desenvolvimento do projeto. Para realizar as estimativas das atividades, o gerente seleciona a sub-atividade Distribuir o tempo do projeto entre as atividades. Nessa tela so exibidas as estimativas totais do projeto e as atividades do processo de desenvolvimento. O gerente, ento, indica o prazo e esforo para cada uma das atividades, de modo que o somatrio de suas estimativas seja equivalente s estimativas totais propostas. Para auxiliar o gerente na distribuio das estimativas do projeto entre as atividades, so disponibilizados dados de projetos similares. Para cada atividade que o gerente analisar, so exibidos seu prazo e esforo nos projetos similares, bem como o percentual desses valores em relao aos valores totais do projeto.
90
Figura 5.15 Tela de Distribuio das estimativas entre as atividades do projeto
(b) Suponhamos, agora, que o gerente tenha escolhido a abordagem Bottom-up.
Para realizar as estimativas do projeto utilizando a abordagem bottom-up, o gerente realiza a busca por projetos similares, selecionando os critrios de caracterizao e o filtro da consulta e, em seguida, analisa os dados dos projetos similares para realizar as estimativas das atividades do projeto. Para cada atividade que o gerente analisar, so exibidos seu prazo e esforo nos projetos similares, bem como o percentual desses valores em relao aos valores totais do projeto. Realizadas as estimativas de todas as atividades do processo de desenvolvimento, as estimativas totais do projeto so calculadas.
91
Figura 5.16 Tela de realizao das estimativas do projeto com abordagem bottom-up
5.4.1.3 Elaborar Cronograma Aps terem sido determinadas as estimativas de prazo e esforo das atividades do projeto (utilizando-se a abordagem top-down ou bottom-up), o cronograma deve ser elaborado. Para isso, o gerente seleciona a atividade Elaborar o Cronograma na CustPlan. O primeiro passo para elaborar o cronograma determinar os caminhos crticos do projeto. Assim, o gerente seleciona a sub-atividade Identificar Caminhos Crticos. Quando o gerente acessa essa opo pela primeira vez, os caminhos crticos vm calculados e identificados em negrito na lista de atividades do projeto. Nas prximas vezes que o gerente acessar a tela, caso tenham ocorrido alteraes nas dependncias e/ou duraes das atividades do processo de desenvolvimento, o boto Atualizar Caminhos Crticos estar habilitado para que a lista de caminhos crticos possa ser alterada. Para cada caminho crtico, o gerente pode registrar algumas observaes que julgue necessrias.
92
Figura 5.17 Tela de Identificao dos caminhos crticos
Aps identificar os caminhos crticos, as datas de incio e fim das atividades devem ser informadas. O gerente seleciona a sub-atividade Determinar datas de incio e fim das atividades e, analisando os prazos de cada atividade, informa suas datas de incio e fim.
Figura 5.18 Tela de Determinao das datas das atividades
93
Para finalizar o cronograma, o gerente seleciona a sub-atividade Registrar Marcos e Pontos de Controle. Os marcos e pontos de controle registrados no Plano de Acompanhamento do projeto so, ento, registrados no cronograma e indicados por cones com as letras M e P que indicam se a atividade em questo constitui um marco ou ponto de controle. Quando o gerente acessa essa opo pela primeira vez, os marcos e pontos de controle vm registrados. Nas prximas vezes que o gerente acessar a tela, caso tenham ocorrido alteraes no Plano de Acompanhamento, o boto Atualizar Marcos e Pontos de Controle estar habilitado para que as alteraes possam ser registradas pelo gerente. importante ressaltar que essa funcionalidade ainda est inativa na CustPlan , pois o Plano de Acompanhamento est sendo desenvolvido em um projeto de final de curso e ainda no est implementado.
Figura 5.19 Tela de Registro dos marcos e pontos de controle
Aps ser elaborado o cronograma, o gerente pode acessar a atividade Visualizar Cronograma e escolher a verso do cronograma que deseja visualizar. gerado um arquivo html com os dados do cronograma do projeto. A figura 5.20 apresenta a tela utilizada para gerar o cronograma e a figura 5.21 apresenta o arquivo html gerado.
94
Figura 5.20 Tela de Visualizao do Cronograma
Figura 5.21 Cronograma (arquivo html)
95
5.4.1.4 Controlar Cronograma Ao longo do desenvolvimento do projeto deve ser realizado o controle do cronograma. Para isso, na CustPlan, o gerente seleciona a atividade Controlar Cronograma onde sero registrados os desvios que ocorreram no cronograma do projeto e as alteraes necessrias. Para registrar a ocorrncia de desvios no cronograma, o gerente seleciona a subatividade Identificar Desvios de Cronograma. Na tela exibida, o gerente seleciona a atividade do projeto em que o desvio ocorreu e registra a data e o valor em horas do desvio, justificando-o. No exemplo apresentado na figura 5.22 possvel observar que o gerente registrou um desvio de 8 horas na atividade anlise do problema causado por um adiamento na reunio de validao.
Figura 5.22 Tela de Identificao dos desvios do cronograma
Identificados os desvios do cronograma, periodicamente, o gerente realiza revises do cronograma, alterando-o sempre que necessrio devido aos desvios registrados. Para realizar a alterao do cronograma, o gerente deve selecionar a sub-atividade Adequar Cronograma. Na tela que exibida ao gerente, so apresentadas as atividades do processo
96
de desenvolvimento do projeto e as atividades que possuem desvios registrados vm em destaque. Ao selecionar uma atividade do projeto, seus desvios so exibidos e o gerente altera o cronograma analisando os desvios registrados. No exemplo apresentado no figura 5.23, para alterar o cronograma devido ao desvio de 8 horas registrado para a atividade Anlise do Problema, o gerente decidiu aumentar o prazo dessa atividade em 8 horas e, para no atrasar o projeto, diminuiu o prazo da atividade Planejamento do Projeto em 8 horas. importante observar que as aes corretivas do cronograma so tomadas pelo gerente com base nos dados dos desvios, em sua experincia, no conhecimento organizacional e nas caractersticas do projeto.
Figura 5.23 Tela de Alterao do cronograma
Aps alterado o cronograma, o gerente pode gerar um novo arquivo atravs da seleo da atividade Visualizar Cronograma , onde ele indica a nova verso a ser visualizada.
O planejamento inicial do tempo realizado no incio do projeto, quando poucas informaes so conhecidas, por isso as sub-atividades no so consideradas. Aps a especificao de requisitos do sistema estar concluda, deve ser feito o refinamento das
97
estimativas de tempo, onde as atividades do processo de gerncia de tempo aqui apresentadas so executadas novamente, porm, considerando as sub-atividades e as informaes obtidas durante a elaborao da especificao de requisitos do sistema. A figura 5.24 ilustra a estimativa da durao das atividades do projeto no momento do refinamento, ou seja, considerando as sub-atividades do processo de desenvolvimento. Os valores estimados no planejamento inicial podem ser alterados (recalculados) ou apenas expandidos (distribudos entre as sub-atividades).
Figura 5.24 Tela de realizao das estimativas das atividades do projeto Refinamento do Planejamento de Tempo
5.4.2 Planejamento de Custos

Aps ser realizado o planejamento do tempo do projeto, utilizando a primeira parte da CustPlan , feita a alocao de recursos humanos ao projeto, que realizada com o apoio da ferramenta RHPlan (SCHNAIDER, 2003).
98
Aps os recursos humanos estarem alocados ao projeto, deve ser elaborado o oramento do mesmo. Para realizar o planejamento dos custos, CustPlan apia as
seguintes atividades: (i) Estimar custos; (ii) Elaborar o oramento do projeto; e, (iii) Controlar o oramento do projeto. Durante o planejamento inicial dos custos, apenas as atividades do processo de desenvolvimento so consideradas. As sub-atividades sero consideradas no momento de refinar as estimativas geradas durante o planejamento inicial. O primeiro acesso ferramenta para tratar os custos do projeto feito quando o gerente seleciona, no ADSOrg instanciado, a sub-atividade Planejamento Inicial dos Custos, presente na atividade Planejamento do Projeto. Nesse momento, um cone da CustPlan fica disponvel no lado direito da tela.
Figura 5.25 - Tela principal de um ADSOrg instanciado com acesso CustPlan para Planejamento dos Custos
5.4.2.1 Estimar Custos Para realizar as estimativas dos custos do projeto, o gerente escolhe a atividade Estimar Custos na CustPlan. O primeiro passo identificar os elementos de custos. O gerente indica nos checklists quais so os recursos que sero utilizados no projeto e sua quantidade. Quando o gerente acessa essa opo o quadro de recursos humanos preenchido automaticamente, uma vez que foram definidos durante o planejamento de
99
alocao de recursos humanos. Caso tenham ocorrido alteraes no Plano de Alocao de Recursos Humanos, o boto Atualizar Recursos Registrados em outros Planos estar habilitado para que o quadro recursos humanos possa ser atualizado considerando as alteraes realizadas no Plano de Alocao de Recursos Humanos.
Figura 5.26 - Tela de Identificao dos elementos de custos do projeto
Aps terem sido identificados os elementos de custos, o custo destes para o projeto deve ser calculado. Para isso, o gerente seleciona a sub-atividade Atribuir Valor aos Elementos de Custos e, para cada elemento de custo, indica o custo unitrio. Um custo padro para a organizao sugerido ao gerente, que pode aceit-lo ou alter-lo. No caso de hardware e software, o custo unitrio pode ser o valor de compra ou o valor de uso do recurso (custo agregado ao projeto devido utilizao de recurso j existente, ou seja, que no precisar ser comprado). O gerente pode, ainda, considerar custo zero (0) para alguns elementos, como por exemplo para um software que a empresa j possui e que o gerente
100
no julga necessrio incluir o valor de uso como custo para o projeto. Para as despesas (outros recursos), o gerente tambm deve indicar a frequncia (mensal, por exemplo). O clculo dos custos com recursos humanos realizado automaticamente considerando-se seu custo unitrio (valor/hora), sua alocao s atividades e o prazo das atividades.
Figura 5.27 - Tela de Atribuio de valor aos elementos de custos do projeto
5.4.2.2 Elaborar Oramento Para elaborar o oramento do projeto, o gerente seleciona a opo Elaborar Oramento na ferramenta CustPlan. Em seguida, seleciona a sub-atividade Registrar Previso de Receitas, onde indica a data prevista para cada receita do projeto, seu valor e sua origem.
101
Figura 5.28 - Tela de Registro das Receitas Previstas
Registrada a previso de receitas, o gerente seleciona a sub-atividade Elaborar Oramento . Os custos com recursos humanos so calculados por atividade do projeto, considerando os dados do cronograma e da alocao de recursos s atividades do projeto. Para os demais recursos, o gerente indica a data em que a despesa ocorrer. Exemplificando: o gerente identificou o elemento de custo aluguel, indicando a quantidade 4. Ao atribuir valor a esse elemento, o gerente registrou um custo de R$ 300,00 com frequncia mensal. Para elaborar o oramento, o gerente deve informar a data em que ocorrer essa despesa (por exemplo, dia 05/05/2003). Assim, no oramento ser considerado que nos prximos 4 meses, no dia 05, ocorrer uma despesa de R$ 300,00 referente ao elemento de custo aluguel.
102
Figura 5.29 - Tela de Elaborao do oramento
Aps ser gerado o
oramento, o gerente pode acessar a atividade Visualizar
Oramento para visualizar em arquivo html com os dados do oramento do projeto.
Figura 5.30 - Tela de Visualizao do oramento
103
Figura 5.31 Cronograma (arquivo html)
5.4.2.3 Controlar Oramento Ao longo do desenvolvimento do projeto, deve ser realizado o controle do oramento. Para isso, na CustPlan , o gerente deve selecionar a atividade Controlar Oramento. O primeiro passo para controlar o oramento registrar a realizao das receitas previstas. O gerente deve selecionar a sub-atividade Registrar Receitas Realizadas. Nesse momento, para cada receita prevista no quadro Receitas Previstas, o gerente registra no quadro Receitas Realizadas a(s) receita(s) realizada(s) correspondentes prevista, podendo esta ser recebida integralmente ou parcialmente, em diversas sub-receitas. Quando
104
o valor de uma receita prevista integralmente recebido, seu status indicado como totalmente realizada.
Figura 5.32 - Tela de Registro de receitas realizadas
Caso ocorram desvios no oramento do projeto, o gerente deve registr-los. Para registrar a ocorrncia de desvios no oramento, o gerente seleciona a sub-atividade Identificar Desvios de Oramento. Na tela que exibida, so disponibilizadas quatro abas, sendo uma para cada tipo de recurso: recursos humanos, recursos de hardware, recursos de software e outros
recursos (despesas em geral). O gerente clica na aba correspondente ao tipo de recurso que gerou a diferena no oramento para registr-la. Para os recursos de hardware, recursos de software e outros recursos, o gerente seleciona o recurso em que o desvio ocorreu e registra a data e o valor do desvio, justificando-o. Na tela da figura 5.31 exemplificado um desvio referente compra de uma nova impressora para o projeto.
105
Figura 5.33 Tela de Identificao de desvios de oramento provenientes de recursos de hardware
importante observar que sempre que o cronograma do projeto for alterado, o oramento tambm dever ser. Sendo assim, as alteraes realizadas no cronograma devem ser refletidas no oramento. Na tela apresentada na figura 5.34 so exibidas as atividades do projeto e seus respectivos custos. Os desvios de cronograma registrados na parte de tempo da CustPlan para as atividades do projeto tambm estaro registrados para o oramento. Por exemplo, na figura 5.34 a atividade Anlise do problema possui um desvio de 8 horas que foi registrado no cronograma (o registro desse desvio foi ilustrado na figura 5.22). Caso tenha ocorrido algum desvio referente ao custo unitrio do recurso humano, este tambm registrado neste momento na CustPlan .
106
Figura 5.34 Tela de Identificao de desvios de oramento provenientes de recursos de humanos
Identificados os desvios do oramento, o gerente realiza revises do oramento, alterando-o sempre que necessrio, devido aos desvios registrados. Para realizar a alterao do oramento, o gerente seleciona a sub-atividade Adequar Oramento. Na tela que exibida ao gerente, so apresentados, em cada aba, os desvios dos recursos e, baseando-se nessas informaes, as aes corretivas necessrias so realizadas. No exemplo da tela da figura 5.35, observamos que a ao corretiva para a compra da impressora foi uma alterao na quantidade desse recurso e, consequentemente, em seu custo para o projeto.
107
Figura 5.35 Tela de alterao do oramento devido a desvios de oramento provenientes de recursos de hardware
As aes corretivas realizadas no cronograma para adequ-lo aos desvios registrados so tambm registradas no oramento. Na tela de recursos humanos, no quadro em que so exibidas as atividades, seus custos considerando as aes corretivas so calculados. No exemplo apresentado na tela da figura 5.36, as aes corretivas realizadas pelo gerente para adequar o cronograma ao desvio registrado alteraram os custos das atividades Anlise do Problema e Planejamento do Projeto. Note que o valor acrescido atividade Anlise do Problema no equivale ao valor diminudo da atividade Planejamento do Projeto, pois os valores dos recursos alocados a essas atividades so diferentes. As alteraes de oramento provenientes das alteraes do cronograma so realizadas automaticamente pela CustPlan.
108
Figura 5.36 - Tela de Alterao do oramento
Aps alterar o oramento, o gerente pode gerar um novo arquivo atravs da seleo da atividade Visualizar Oramento.
O planejamento inicial dos custos, assim como o planejamento inicial do tempo, realizado no incio do projeto, quando poucas informaes so conhecidas, por isso as subatividades no so consideradas. Aps a especificao de requisitos do sistema estar concluda, deve ser feito o refinamento das estimativas de tempo e, consequentemente, das estimativas de custos tambm, onde as atividades aqui apresentadas so executadas novamente, porm, considerando as sub-atividades do processo de desenvolvimento e as informaes coletadas durante a elaborao da especificao de requisitos. importante lembrar que, quando o planejamento de tempo for revisto, o planejamento de custos tambm dever ser.
109
A figura 5.37 ilustra a
elaborao do oramento do projeto no momento do
refinamento, ou seja, considerando as sub-atividades do processo de desenvolvimento.
Figura 5.37 - Tela de Elaborao do oramento Refinamento das Estimativas de Custos
5.5 Consideraes Finais Neste captulo foram apresentados os critrios de caracterizao da Estao TABA que so utilizados para permitir a recuperao de projetos similares, cujos dados so utilizados na realizao de estimativas baseadas em analogia. A pesquisa realizada para definir um conjunto de dependncias usuais entre as atividades do processo de desenvolvimento foi apresentada e a ferramenta CustPlan, implementada no contexto do ADSOrg, na Estao TABA, com o objetivo de apoiar o planejamento de tempo e custos, foi descrita e teve sua interface apresentada. O Anexo 5 apresenta as classes que foram includas no modelo da Estao TABA para representar os conceitos envolvidos no planejamento de tempo e custos de projetos.
110
Captulo 6 Consideraes Finais e Perspectivas Futuras

Neste captulo so apresentadas as consideraes finais desta pesquisa, suas contribuies e suas perspectivas futuras.
6.1 Consideraes Finais A tecnologia hoje disponvel para o desenvolvimento de software permite, e at induz, a utilizao de arquiteturas de sistemas cada vez maiores e mais complexas. Em contrapartida, o prazo para o desenvolvimento de tais produtos tem sido compactado, refletindo a evoluo tecnolgica e necessidades econmicas do mercado. As dimenses dos produtos de software esto atingindo nveis quantitativos cada vez maiores, no ocorrendo o mesmo com a tolerncia a falhas de previso de custos e cronogramas. Esse cenrio exige que processos formalizados de gerncia de software sejam definidos e utilizados (TRINDADE, et al. 1999). A gerncia dos prazos e custos de projetos de software muito importante, uma vez que pesquisas mostraram que a maioria dos projetos que fracassam tm como seu principal motivo o mal planejamento dos custos e cronograma. Para auxiliar os gerentes de projeto a gerenciarem os prazos e custos dos projetos, o PMBOK (2000) dedica um captulo gerncia de tempo e um captulo gerncia de custos, fornecendo diretrizes e sugestes de ferramentas que auxiliam a gerncia dos prazos e custos do projeto e comprovando a importncia mundial dessas atividades na realizao de projetos. A norma NBR ISO 10006 (2000) tambm trata os processos de gerncia de tempo e gerncia de custos, comprovando mais uma vez a importncia dessas atividades no contexto da gerncia de projetos. Dada a importncia da utilizao de mtodos eficientes para realizar o planejamento de prazos e custos, muitos pesquisadores dedicaram, e ainda dedicam, pesquisas a essa rea, propondo-se a realizar estudos de caso com as tcnicas mais conhecidas e, analisando os resultados obtidos nesses estudos, refin-las e/ou definir novas tcnicas e caminhos para realizar as estimativas com sucesso.
111
Consideraes Finais e Perspectivas Futuras ________________________________________________________________________________________
MIRANDA (2001) afirmou que tcnicas e abordagens eficientes existem. O que no muito comum, ainda, a utilizao correta dessas tcnicas. Esse fato acarreta na elaborao de oramentos e cronogramas falhos e irreais, que podem contribuir para o fracasso de um projeto. Prover uma organizao de capacidade para utilizar uma abordagem de planejamento de prazos e custos prtica e eficaz um ponto diferencial para a mesma diante das exigncias mercadolgicas atuais. O trabalho aqui descrito veio, exatamente, propor uma abordagem para o planejamento de prazos e custos nas organizaes. Essa abordagem est inserida em um tipo especial de ambientes de desenvolvimento de software, chamados de Ambientes de Desenvolvimento de Software Orientados Organizao (ADSOrg). Este trabalho encontra-se, assim, no contexto do ADSOrg, um projeto de longo prazo da COPPE, englobando outras ferramentas de gerncia de projetos com enfoque em gerncia do conhecimento e memria organizacional Dentre as principais contribuies deste trabalho destacam-se: (1) A definio de processos de gerncia de tempo e gerncia de custos baseados na gerncia do conhecimento organizacional e nas recomendaes da norma NBR ISO 10006 (2000), do relatrio tcnico 16326 da ISO/IEC 12207(1998) e no PMBOK (2000); (2) A proposta de uma caracterizao para os projetos da Estao TABA. Assim, os projetos podem ser agrupados como similares de acordo com critrios genricos e/ou especficos. (3) A utilizao da notao para diagramas de workflow para fornecer uma representao para os processos definidos, destacando-se as atividades, suas entradas, sadas e elementos interagentes. A utilizao da notao contribuiu para observar seus pontos fortes e fracos. (4) A disponibilizao de uma ferramenta para auxiliar a elaborao do Plano de Custos e Cronograma em Ambientes de Desenvolvimento de Software Orientados Organizao, utilizando mtodos paramtricos de estimativas e os princpios da gerncia do conhecimento e Memria Organizacional. (5) A definio de um conjunto de dependncias usuais entre as atividades do processo de desenvolvimento de software.
112
Os benefcios da abordagem proposta podero ser avaliados em um procedimento de validao da ferramenta. Porm, a validao de uma ferramenta como a CustPlan implica em sua utilizao em vrios projetos o que excede em muito o tempo esperado para uma tese de mestrado. Portanto, a validao ser realizada no contexto do projeto ADSOrg englobando outras ferramentas de gerncia de projetos. A abordagem proposta introduz o planejamento de custos na Estao TABA e representa um passo importante na construo de ferramentas de apoio gerncia de projetos centradas na utilizao do conhecimento organizacional. Tal perspectiva traz grandes benefcios para as organizaes de software e uma das principais tendncias na rea de Engenharia de Software.
6.2 Perspectivas Futuras
Buscando-se melhorar e expandir a abordagem de planejamento de custos proposta, algumas perspectivas de trabalhos futuros so destacadas. Inicialmente, a definio e implementao da tcnica de busca por projetos similares. Atualmente, os projetos esto sendo recuperados baseando-se em uma busca exata, ou seja, dois projetos so considerados similares somente quando todos os seus critrios de caracterizao so idnticos. A definio de uma tcnica de busca por projetos similares fundamental para permitir a utilizao eficiente do conhecimento acumulado por uma organizao. Algumas tcnicas estudadas foram citadas nos captulos dois e cinco, porm, seria interessante um estudo detalhado das abordagens encontradas na literatura. Uma outra melhoria seria a disponibilizao dos dados armazenados no repositrio da organizao referentes a projetos similares de forma mais expressiva para o gerente do projeto, para auxili-lo nas estimativas de novos projetos. Um exemplo desses dados seria os valores mdios de prazo, esforo e custos utilizados em projetos classificados como pequenos, mdios e grandes. Outra melhoria seria a implementao do processo de calibrao do modelo COCOMO II, para que o mesmo possa se adequar, cada vez mais, organizao em que est sendo utilizado. Para realizar a calibrao do COCOMO II necessrio que o repositrio da organizao contenha dados de diversos projetos. Sendo assim, a realizao
113
da calibrao depende da validao e efetiva utilizao do ADSOrg para que esses dados possam existir. Uma outra perspectiva bastante interessante seria a definio de uma ontologia de prazos e custos, inserida na ontologia de Engenharia de Software, que um dos componentes da estrutura de conhecimento de ADSOrg. A ontologia de prazos e custos tornaria possvel a definio de um vocabulrio comum no que diz respeito ao conhecimento de custos da organizao. Outra melhoria muito importante a implementao da integrao da CustPlan com duas ferramentas existentes no TABA: com RiscPlan (FARIAS, 2002) onde a ocorrncia de um risco exige a execuo de um plano de contingncia que provocar desvios no cronograma planejado; e com a planilha de acompanhamento de projeto, onde os recursos humanos do projeto registram o andamento das atividades que esto desenvolvendo. Assim, desvios de atraso no desenvolvimento dessas atividades poderiam ser registrados automaticamente. importante observar que essa melhoria seria realizada para apoiar a atividade de controle do cronograma do projeto no processo de gerncia de tempo. Para apoiar a disseminao e utilizao do conhecimento, poderia ser desenvolvida uma consulta pr-ativa ao conhecimento, onde a prpria CustPlan seria capaz de sugerir ao gerente dados de projetos anteriores sem, necessariamente, ter sido executada uma busca por projetos similares para isso. A abordagem proposta neste trabalho define processos para a gerncia de tempo e custos e uma ferramenta que apia a realizao desses processos na Estao TABA. A proposta de processos e ferramentas que apiem o desenvolvimento de software refora a percepo de que este no mais pode ser visto como uma prtica artesanal ou individual, pois suas especificidades o caracterizam como uma rea complexa e abrangente e, como tal, deve ser planejado e controlado para que se obtenha um feedback, no mnimo, satisfatrio.
114
Referncias Bibliogrficas
ABECKER, A., BERNADI, A., HINKELMANN, K. et al., 2001, Toward a Technology for Organizational Memories, IEEE Intelligent Systems, v. 13, May/June, pp. 40-48.
ABRAN, A., JACQUET, J.-P., 1999, A Structured Analysis of the New ISO Standard on Functional Size Measurement-definition of Concepts
Software Engineering Standards. Fourth IEEE International Symposium and Forum, pp. 230 241.
ACKERMAN, M., HALVERSON, C., 2000, Reexamining Organizational Memory, Communications of the ACM, v. 43, n. 1, Jan, pp. 59-64.
ALAVI, M., LEIDNER, D., 1999, Knowledge Management Systems: Emerging Views and Practices from the Field, In: 32 th Hawaii International Conference on System Sciences, IEEE Intelligent Systems, pp. 1-11.
ANGELIS, L., STAMELOS, I., MORISIO, M., 2001, Building a Software Cost Estimation Model Based on Categorical Data, Software Metrics Symposium METRICS, pp. 4 15. ARAJO, M. A. P., 1998, Automatizao do Processo de Desenvolvimento de Software nos Ambientes Instanciados pela Estao TABA, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
ARMOUR, P., 2002, Then Unmyths of Project Estimation, Communications of the ACM, vol 45, n 11, Nov, pp. 15-18.
115
Referncias Bibliogrficas ________________________________________________________________________________________
BASILI, V., CALDIERA, G., ROMBACH, D., 1994, The Experience Factory. In: John Marcianiak, Volume 1 of Encyclopedia of Software Engineering, Chapter X, John Wiley & Sons.
BASILI, V., NETO, M. G. M., SEAMAN, C. B., KIM, Y. M., 2001a A Prototype Experience Management System for a Software Consulting Organization, 13th International Conference on Software Engineering and Knowledge Engineering SEKE, pp. 29-36.
BASILI, V, LINDVALL,M., COSTA, P. , 2001b, Implementing the Experience Factory concepts as a set of Experience Bases, 13th International Conference on Software Engineering and Knowledge Engineering SEKE , pp. 102-109.
BECERRA-FERNANDEZ,
I.,
1998,
Center
for
Innovation
and
Knowledge
Management, SIGGROUP Bulletin, v. 19, Apr, pp. 46-51.
BIELAK, J., 2000, Improving Size Estimates Using Historical Data, IEEE Software , Volume: 17 Issue: 6 , Nov/Dec, pp. 27 35.
BIGGAN, J., 2001, Defining Knowledge: An Epistemological Foundation for Knowledge Management, In: 34 th Hawaii International Conference on System Sciences, IEEE Intelligent Systems, pp. 1-7.
BIRK, A., DINGSOYR, T., STALHANE, T., 2002, Postmortem: Never Leave a Project Without It, IEEE Software , Volume: 19 Issue: 3 , May/Jun, pp. 43 45.
BOEHM, B. W., 1981, Software Engineering Economics, Prentice Hall, Upper Saddle River.
116
BOEHM, B. W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 2000, Software Cost Estimation with COCOMO II, Prentice Hall.
BOEHM, B. W., 2000, Safe and Simple Software Cost Analisys, IEEE Software, Sep/Oct, pp. 14-17.
BOEHM, B.W., FAIRLEY, R. E., 2000, Software Estimation Perspectives, IEEE Software , Volume: 17 Issue: 6 , Nov/Dec, pp. 22 26.
BRAGA, A. , 1996, Anlise de Pontos de Funo, IBPI Press, Rio de Janeiro, RJ.
BRIAND, L.C., EMAM, K., SURMANN, D., WIECZOREK, I., MAXWELL, K.D., 1999, An Assessment and Comparison of Common Software Cost Estimation Modeling Techniques, Communications of the ACM, May, pp. 313-322.
BRIAND, L.C., LANGLEY, T., WIECZORECK, I., 2000, A replicated Assessment and Comparison of Common Software Cost Modeling Techniques, Communications of the ACM, Jun, pp. 377-386.
BROOKS, P. F., 1975, The Mythical Man-Month, Addison Wesley, pp. 14-26, 88-94.
CHANDRASEKARAN, B., et al., 1993, Task-Structure Analysis for Knowledge Modeling. In: B. V. Cuena (ed.), Knowledge Oriented Software Design, Elsevier Science Publishers. Ref: VILLELA (et al. 2000).
117
CHANDRASEKARAN, B., JOSEPHSON, J. R., BENJAMINS V. R., 1999, What Are Ontologies, and Why Do We Need Them?, IEEE Intelligent Systems & their applications, v. 14, n. 1, Jan/Feb, pp. 20-26.
CHRISTENSEN, M. J., THAYER H. R., 2001, The Project Managers: Guide to Software Engineerings Best Pratices, Ed. IEEE Computer Society.
CRUZ, C. D., 1998, Em Direo a um Modelo de Custos de Desenvolvimento de Software Orientado a Objetos, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
DAVENPORT, T., DE LONG, D., BEERS, M., 1998 . Successful Knowledge Management Projects, Sloan Management Review, v. 39, n. 2, pp. 43-57.
DEKKERS, C.A., 1999, Determination of Functional Domains for Use with Functional Size Measurement - Opportunities to Classify Software From a Business Perspective, Software Engineering Standards. Fourth IEEE International Symposium and Forum, pp. 227 229.
DONALDSON, S. E., SIEGEL, S. G., 2000, Successful Software Development, Prentice Hall, chapter 2, pp. 63-118.
EMAM, K., DROUIN, J., MELO W., 1998, SPICE The Theory and Practice of Software Process Improvement and Capability Determination, IEEE Computer Society Press.
ENGELKAMP,S.,
HARTKOPT, S., BROSSLER, P., 2000,
Project Experience
Database: A Report Based on First Practical Experience, PROFES - Product Focused Software Process Improvement, pp. 204-215.
118
FARIAS, L. L., ROCHA, A., TRAVASSOS, G., 2001, Planejamento de Riscos em Ambientes de Desenvolvimento de Software Orientados Organizao, WorkShop de Teses - XV Simpsio Brasileiro de Engenharia de Software, Rio de Janeiro-RJ.
FARIAS, L. L., 2002, Planejamento de Riscos em Ambientes de Desenvolvimento de Software Orientados Organizao, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
FENTON, N. E.,1991, Software Metrics: A Rigorous Approach, Chapman and Hall.
FISCHER, G, OSTWALD, J., 2001, Knowledge Management: Problems, Promises, Realities and Challenges, IEEE Intelligent Systems, Jan/Feb, pp. 60-72.
FORD, B., 1976, Missing Data Procedures: A Comparative Study, Proc. Social Statistics Section, pp. 324-329.
GARMUS, D., HERRON, D., 2001, Function Point Analysis: Measurement Practices for Successful Software Projects, Addison Wesley. GOMES, A.G.J., 2001, Avaliao de Processos de Software Baseada em Medies, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
GRAY, A.R., MACDONELL, S.G., SHEPPERD, M.J., 1999, Factors Systematically Associated With Errors in Subjective Estimates of Software Development Effort: The Stability of Expert Judgment, Software Metrics Symposium - METRICS, pp. 216 227.
119
HASTINGS, T. E., SAJEEV, A. S. M., 2001, A Vector-Based Approach to Software Size Measurement and Effort Estimation, IEEE Transactions on Software Engineering v. 27, n. 4, Apr, pp. 337-350.
HENDRIKS, P., VRIENS, D., 1999, Knowledge-based systems and knowledge management: Friends or foes?, Information & Management, v. 35, n. 2, Feb, pp. 113-125.
HOST, M., WOHLIN, C., 1997, A Subjective Effort Estimation Experiment, Information and Software Technology, v. 39, pp. 755-762.
HUMPREY, W., 1995, A Discipline for Software Engineering, Addison Wesley.
IDRI, A., ABRAN, A., 2001, A Fuzzy Logic Based Set of Measures for Software Projects Similarity: Validation and Possible Improvements, Software Metrics Symposium - METRICS, pp. 85-96.
ISO/IEC DTR 16326 Software Engineering Guide for the Application of ISO /IEC 12207 to Project Management, 1999.
ISO/IEC 14143 Information Technology Software Measurement Functional Size Measurement, 1998.
IVES, B., GIFFORD, T., HANKINS, D., 1998, Integrating Learning Through Knowledge (&Skills) Management, SIGGROUP Bulletin, v. 19, n. 1, Apr, pp. 51-55.
120
JEFFERY, R..,RUHE, M., WIEEZOREK, I., 2001, Using Public Domain Metrics to Estimate Software Development Effort , 7 th International Software Metrics Simposium 2001 Metrics 2001, pp. 16-27.
JOHNSON, P. M., MOORE, C. A., DANE, J. A., BREWER, R. S., 2000, Empirically Guided Software Effort Guesstimation, IEEE Software, Nov/Dec, pp. 51-56.
JONES, M., 1998, Knowledge Management at Work: Current Approaches and Case Studies, SIGGROUP Bulletin, v. 19, n. 1, Apr, pp. 33-34.
JONES, C., 1999, Software Sizing, IEEE Review, v.45, Issue: 4 , Jul, pp. 165-167
JONES, C., 2000, Software Assessments, Benchmarks, and Best Practices, AddisonWesley Information Technology Series, pp. 657 .
JORGENSEN, M., INDAHL, U., SJOBERG, D., 2001, Software Effort Estimation by Analogy and Regression Toward the Mean, 13th International Conference on Software Engeeering and Knowledge Engineering SEKE , pp. 268-274.
JOSHI, K. D., 2001, A Framework to Study Knowledge Behaviors During Decision Making, In: 34 th Hawaii International Conference on System Science, IEEE, pp. 1-12.
KROMREY, J., HINES, C., 1994, Nonrandomly Missing Data in Multiple Regression: An Empirical Comparation of Commom Missing Data Trearments, Education and Psycological Measurement, vol. 54, n 3, pp. 573-593.
121
KURTZ, T., 2001, Ask Pete, Software Planning and Estimation Through Project Characterization, Requirements Engineering. Fifth IEEE International
Symposium, pp. 286 287.
KUSUMOTO, S., INOUE, K., KASIMOTO, T., SUZUKI, A., YUURA, K., TSUDA, M., 2000, Function Point Measurement for Object-oriented Requirements
Specification, Computer Software and Applications Conference - COMPSAC, pp. 543 548.
LEE, J., KIM, Y., YU, S., 2001, Stage Model for Knowledge Management, In: 34th Hawaii International Conference on System Sciences, IEEE Software, pp. 1-10.
LIEBOWITZ, J., 2002, A Look at NASA Goddard Space Flight Centers Knowledge Management Iniciatives, IEEE Software , v. 19, Issue: 3 , May/Jun, pp. 40 42.
LITTLE, R., RUBIN, D., 1987, Statistical Analisys with Missing Data, John Wilwy and Sons.
MARKKULA, M., 1999, Knowledge Management in Software Engineering Projects, In: Proceedings of the 11th International Conference on Software Engineering & Knowledge Engineering, Kaiserslautern, Germany, Jun, pp. 20-27.
MACHADO, L., ROCHA, A., 1999, Modelo para Definio, Especializao e Instanciao de Processos de Software. In: Anais do Workshop de Teses em Engenharia de Software - XIII Simpsio Brasileiro de Engenharia de Software, Florianpolis, Brasil, Out, pp. 43-47.
122
MACHADO, L., 2000, Modelo para Definio, Especializao e Instanciao de Processos de Software na Estao TABA, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
MAIDANTCHIK, C., 1999, Modelo de Processo de Gerncia de Software para Equipes Geograficamente Dispersas, Tese de D. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
MENDES, E., COUNSELL, S., 2000, Web Development Effort Estimation Using Analogy", Software Engineering Conference, pp. 203 212.
MENDONA, M. G., SEAMAN, C.B., BASILI, V., KIM, Y., 2001, A Prototype Experience Management System for a Software Consulting Organization, Software Engineering and Knowledge Engineering SEKE, Buenos Aires, Argentina, June.
MENZIES, T., SINSEL, E., 2000, Practical Large Scale what-if Queries: Case Studies with Software Risk Assessment, Automated Software Engineering. Fifteenth IEEE International Conference, pp. 165 173.
MIRANDA, E., 2001, Improving Subjective Estimates Using Paired Comparisons, IEEE Software , Volume: 18 Issue: 1 , Jan/Feb, pp. 87 91.
MONTONI, M., ROCHA, A. R., TRAVASSOS, G. H., 2002, "Aquisio de Conhecimento nos Processos de Negcio", In: 7o Workshop de Teses em Engenharia de Software, Gramado, Brasil, Outubro.
123
MOSES, J., CLIFFORD, J., 2000, Learning How to Improve Effort Estimation in Small Software Development Companies, Computer Software and Applications Conference - COMPSAC, pp. 522 527.
MURCH, R., 2000, Project Management: Best Pratices for IT Professionals, Prentice Hall.
NAGESWARAN, S., 2001, Test Effort Estimation Using Use Case Points, Quality Week, San Francisco, California, EUA, Jun, pp.1-6.
NBR ISO 10006 Gesto da Qualidade: Diretrizes para Qualidade no Gerenciamento de Projetos, 2000.
NBR ISO/IEC 12207 Tecnologia de Informao Ciclos de Vida de Software, 1998.
OHLSSON, M.C., WOHLIN, C., 1999, An Empirical Study of Effort Estimation During Project Execution, Software Metrics Symposium - METRICS, pp. 91 98.
OLEARY, D. E.,
1998a,
Enterprise Knowledge Management, IEEE Intelligent
Systems, Mar, pp. 54-61.
OLEARY, D. E., 1998b, Using AI in Knowledge Management: Knowledge Bases and Ontologies, IEEE Intelligent Systems, v. 13, n. 3, May/Jun, pp. 34-39.
OLEARY, D. E., 1998c, Using AI in Knowledge Management: Knowledge Bases and Ontologies, IEEE Intelligent Systems, v. 13, n. 3, May/Jun, pp. 34-39.
124
OLEARY, D.E., STUDER, R., 2001, Knowledge Management: An Interdisciplinary Approach, IEEE Intelligent Systems, Jan/Feb, pp. 24-25.
OLEARY, D.E., 2001, How Knowledge Reuse Informs Effective System Design and Implementation, IEEE Intelligent Systems, Jan/Feb, pp. 44-49.
OLIVEIRA, K., 1999, Modelo para Constrio de Ambientes de Desenvolvimento de Software Orientados a Domnio, Tese de D. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
PAULK, M. C., WEBER, C. V., CURTIS, B., CHRISSIS, M. B. (eds.), 1995, The Capability Maturity Model: Guidelines for Improving the Software Process, Carnegie Mellon University, Software Engineering Institute, Addison-Wesley Longman Inc.
PRADO, D., 1998, PERT/CPM, Srie Gerncia de Projetos, volume 4, 2 edio, Ed. de Desenvolvimento Gerencial,.
PRIETO-DIAZ, R., 1991, Implementing faceted classification for software reuse, Communications of the ACM, vol.34, no.5, May, pp. 89 97.
PMBOK Project Management Body of Knowledge, 2000, PMI Project Management Institute.
PREECE, A., FLET, A., SLEEMAN, A., CURRY, D., MEANY, N., PERRY, P., 2001, Better Knowledge Management through Knowledge Engineering, Intelligent Systems, Jan/Feb, pp. 36-43. IEEE
PRESSMAN, R. S., 2001, Software Engineering: A Practitioners Approach, McGrawHill International Editions, 5 th ed.
125
PUTNAM, L.H.,1978, A General Empirical Solution to the Macro Software Sizing and Estimation Problem, IEEE Systems, Jul.
RAINER, A., SHEPPERD, M., 1999, Re-planning for a Successful Project Schedule, Software Metrics Symposium - METRICS, pp. 72 81.
RAMASUBRAMANIAN, S., JAGADEESAN, G., 2002, Knowledge Management at Infosys, IEEE Software, May/Jun, pp. 53-55.
RAMESH, B., 2002, Process Knowledge Management with Traceability, IEEE Software, v. 19, Issue: 3 , May/Jun, pp. 50 52.
RAYMOND, M., 1987, A Comparisonof Methods for Treating Incomplete Data in Selection Research, Education and Psycological Measurement, vol. 47, pp. 1326.
REIFER, J. D., 2002, A Little Bit of Knowledge is a Dangerous Thing, IEEE Software, May/Jun, pp. 14-15.
ROCHA, A.R.C, AGUIAR T. C., SOUZA, J. M., 1990, TABA: A Heuristic Workstation for Software Development, In: Proceedings of COMPEURO90, Tel Aviv, Israel, Maio.
ROCHA, A. R. C., 2000, Gerncia de Projetos, Notas de Aula.
RUNESON, P., BORGQUIST, N., LANDIN, M., BOLANOWSKI, W., 2000, An Evaluation of Functional Size Methods and a Bespoke Estimation Method for Real-Time Systems, PROFES Product Focused Software Process Improvement, pp 339-352.
126
RUS, I., LINDVALL, M., 2002, Knowledge Management in Software Engineering , IEEE Software , v. 19, Issue: 3 , May/Jun, pp. 26 38.
SCHNAIDER, L., 2003, Planejamento de Alocao de Recursos Humanos em Ambientes de Desenvolvimento de Software Orientados Organizao, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
SEPPNEN, V., KOMI-SIRVI, S., MNTYNIEMI, A., 2002, Toward a Practical Solution for Capturing Knowledge for Software Projects, IEEE Software, May/Jun, pp. 60-62.
SHEPPERD, M., SCHOFIELD, C., 1997, Estimating Software Project Effort Using Analogies, Software Engineering, IEEE Transactions on , v. 23, Issue: 11 , Nov 1997, pp. 736 743.
SHNEIDER, K., HUNNIUS, J., BASILI, V. R., 2002, Experience in Implementing a Learning Software Organization, IEEE Software, May/Jun, pp. 46-49.
SKYRME, D., 1998, Knowledge Management Solutions - The IT Contribution, SIGGROUP Bulletin, v. 19, n. 1, Apr, pp. 34-39.
STAAB, S., STUDER, R., SCHNURR, H.P., SURE, Y., 2001, Knowledge Management and Ontologies, IEEE Intelligent Systems, Jan/Feb, pp. 26-34.
STRIKE, K., EMAM, K. E., MADHAVJI, N., 2001, Software Cost Estimation with Incomplete Data, IEEE Transactions on Software Engineering, vol. 27, n 10, Oct, pp. 890-908.
127
TRAVASSOS, G. H., 1994, O Modelo de Integrao de Ferramentas da Estao TABA, Tese de D. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.
TRINDADE, A. L. P., PESSOA,M. S. P., SPINOLA, M. M. , 1999, COCOMO II Uma Compilao de Informaes sobre a Nova Mtrica, V Congresso Internacional de Engenharia Informtica da Universidade de Buenos Aires Argentina, pp. 117.
UEMURA, T., KUSUMOTO, S., INOUE, K., 1999, Function Point Measurement Tool for UML Design Specification, Software Metrics Symposium - METRICS, pp. 62 69.
VILLELA, K., TRAVASSOS, G.H., ROCHA, A.R., 2000,
Ambientes de
Desenvolvimento de Software Orientados Organizao, Publicao Tcnica COPPE/UFRJ - ES530/00 Rio de Janeiro, RJ, Abril.
VILLELA,
K.,
TRAVASSOS,
G.H.,
ROCHA,
A.R.,
2001a
Ambientes
de
Desenvolvimento de Software Orientados a Organizao, IDEAS'2001 Workshop Ibero-americano de Ingeniera de Requisitos y Ambientes de Software, Jan Jose, Costa Rica, Abril.
VILLELA,
K.,
SANTOS,
G.,
BONFIM,
C.,
et
al.,
2001b,
Knowledge Management in Software Development Environments, 14th International Conference Software & Systems Engineering and their
Applications, Paris, Dezembro.
VILLELA,
K.,
SANTOS,
G.,
TRAVASSOS,
G.
H.,
ROCHA,
A.
R., 2002, Gesto de Conhecimento em Ambientes de Desenvolvimento de Software, 2 Jornada Ibero-Americana de Engenharia de Software e Engenharia de Conhecimento, Salvador, Brasil, Outubro.
128
WANGENHEIM, C. G. V., LICHTNOW, D., WANGENHEIM , A.. V., 2001, A Hybrid Approach for Corporate Memory Management Systems in Software R&D Organizations, 13th International Conference on Software Engineering and Knowledge Engineering SEKE 2001 , pp. 326-330.
WEBER, C. K., ROCHA, A. R. C., NASCIMENTO, C. J., 2001, Qualidade e Produtividade em Software, 4 Edio, Ed. Makron Books.
WEI, C., HU, P. J., CHEN, H., 2002, Design and Evaluation of a Knowledge Management System, IEEE Software, May/Jun, pp. 56-59.
WIIG, K., 1994, Knowledge Management - The Central Focus for Intelligent acting Organizations, Schema Press. Ref: SKYRME (1998).
YAMAURA, T., KIKUNO, T., 1999, A Framework for Top-down Cost Estimation of Software Development, Computer Software and Applications Conference COMPSAC, pp. 322 323.
129
Anexo 1 Realizao de Estimativas utilizando Anlise de Pontos de Funo e Pontos de Caso de Uso
Este anexo apresenta os passos necessrios para realizar estimativas utilizando as tcnicas Anlise de Pontos de Funo, Pontos de Caso de Uso e um exemplo de utilizao da tcnica Anlise de Pontos de Funo.
A1.1 O Processo de Contagem de Pontos de Funo O processo de contagem dos pontos de funo pode ser dividido em sete etapas: (i) determinar tipo de contagem; (ii) identificar a fronteira da aplicao; (iii) contar as funes tipo dados; (iv) contar as funes tipo transao; (v) calcular pontos de funo no ajustados (com base nos resultados obtidos em (iii) e (iv)); (vi) calcular o valor do fator de ajuste; e (vii) calcular os pontos de funo ajustados (com base nos resultados obtidos em (v) e (vi)) , como mostra a figura A1.1. A execuo dessas etapas descrita a seguir.
Contar Funes Tipo Dados
Determinar tipo de contagem
Identificar a fronteira da aplicao
Contar Funes Tipo Transao
Calcular pontos de funo no ajustados Calcular nmero de pontos de funo ajustados
Calcular valor do fator de ajuste
Figura A1.1 Viso Geral do Processo de Anlise de Pontos de Funo (GARMUS e HERRON, 2001)
(i) Determinar o Tipo de Contagem Para realizar a contagem dos pontos de funo de um projeto, inicialmente, preciso determinar o tipo de contagem a ser realizada, podendo esta ser: Projeto de Desenvolvimento: mede a funcionalidade fornecida aos usurios finais do software para a primeira instalao da aplicao. Inclui as
130
Realizao de Estimativas utilizando Anlise de Pontos de Funo e Pontos de Caso de Uso ________________________________________________________________________________________
funcionalidades da contagem inicial da aplicao e as funcionalidades requeridas para converso de dados. Projeto de Manuteno: mede as modificaes realizadas para aplicaes existentes. Inclui as funcionalidades fornecidas aos usurios atravs de adio, modificao ou excluso de funes na aplicao. As funcionalidades de converso de dados tambm devem ser consideradas, caso existam. Aps a manuteno, a contagem da aplicao deve ser refeita para refletir as alteraes realizadas. Aplicao: mede uma aplicao instalada. tambm referenciada como contagem de linha de base ou contagem instalada e avalia as funcionalidades correntes providas aos usurios finais da aplicao.
(ii) Identificar a Fronteira da Aplicao Aps determinado o tipo de contagem, a fronteira da aplicao deve ser identificada. Ela indica a separao entre o projeto que est sendo medido e as aplicaes externas ao domnio do usurio. atravs dela que torna-se possvel definir quais funcionalidades sero includas no processo de contagem dos pontos de funo.
(iii) Contar Funes Tipo Dados Nesta etapa as funcionalidades da aplicao comeam a ser identificadas e contadas. A funcionalidade da aplicao avaliada em termos do qu fornecido pela mesma, no do como fornecido. Apenas componentes definidos e solicitados pelo usurio devem ser contados (GARMUS e HERRON, 2001). As Funes Tipo Dados representam as funcionalidades fornecidas pelo sistema ao usurio, para atender s necessidades referentes aos dados que o sistema ir manipular. Essas funes podem ser: 1) Arquivo Lgico Interno (ALI) : grupo logicamente relacionado de dados ou informaes de controle, identificvel pelo usurio, mantido dentro da fronteira da aplicao que est sendo controlada. Por exemplo: as tabelas ou classes do sistema.
131
2) Arquivo de Interface Externa (AIE): grupo logicamente relacionado de dados ou informaes de controle, referenciado pela aplicao, identificvel pelo usurio, mantido fora da fronteira da aplicao que est sendo controlada. Por exemplo: as tabelas acessadas em um outro sistema. A diferena bsica entre um ALI e um AIE que o ltimo no mantido pela aplicao que est sendo contada. Um AIE contado para uma aplicao sempre ser contado como um ALI em sua aplicao de origem. Nas definies de ALI e AIE foram utilizados alguns termos e expresses que merecem esclarecimento. So elas: Informaes de Controle: so dados utilizados pela aplicao para garantir aderncia com os requisitos funcionais especificados pelo usurio. Por exemplo: datas e horas so utilizadas pelos usurios para estabelecer a sequncia ou o momento de eventos. Assim, datas e horas so informaes de controle. Identificvel pelo Usurio: refere-se aos requisitos especficos que um usurio ou grupo de usurios seria capaz de definir para a aplicao. Mantido: refere-se ao fato de que o dado pode ser modificado atravs de um processo elementar da aplicao. Um processo elementar a menor atividade capaz de produzir resultados significativos para o usurio. Por exemplo: incluir, alterar e excluir. Cada Arquivo Lgico Interno e cada Arquivo de Interface Externa possui dois tipos de elementos que devem ser contados para cada funo identificada: Tipos de Elementos de Dados (TED): campo nico, reconhecido pelo usurio, no recursivo. Por exemplo: campos das tabelas. Tipos de Elementos de Registros (TER): subgrupo de dados, reconhecido pelo usurio. Por exemplo: generalizao/especializao de classes. Ao final dessa etapa devem estar identificados quantos Arquivos Lgicos Internos e Arquivos de Interface Externa o sistema possui e para eles, quantos so os Tipos de Elementos de Dados e os Tipos de Registros encontrados.
132
(iv) Contar Funes Tipo Transao As Funes Tipo Transao representam as funcionalidades de processamento dos dados fornecidas pelo sistema ao usurio. Essas funes podem ser: 1) Entrada Externa (EE): processo elementar da aplicao que processa dados ou informaes de controle que vm de fora da fronteira da aplicao que est sendo controlada. Exemplos: validaes, frmulas e clculos matemticos cujos parmetros vm de fora da fronteira da aplicao. 2) Sada Externa (SE): processo elementar da aplicao que gera dados ou informaes de controle que so enviados para fora da fronteira da aplicao que est sendo controlada. Exemplos: relatrios e grficos. 3) Consulta Externa (CE): processo elementar da aplicao que representa uma combinao de entrada (solicitao de informao) e sada (recuperao de informao). Exemplos: consultas implcitas, verificao de senhas e recuperao de dados com base em parmetros. Cada Entrada Externa, Sada Externa e Consulta Externa possui dois tipos de elementos que devem ser contados para cada funo identificada: Tipos de Elementos de Dados (TED): campo nico, reconhecido pelo usurio, no recursivo. Por exemplo: campos das tabelas. Tipos de Arquivos Referenciados ou Arquivos Referenciados (TAR): arquivos lgicos utilizados para processar a entrada e/ou sada. o total de ALI e AIE utilizados pela transao. Ao final dessa etapa devem estar identificadas quantas Entradas Externas, Sadas Externas e Consultas Externas o sistema possui e, para elas, quantos so os Tipos de Elementos de Dados e os Arquivos Referenciados encontrados.
(v) Calcular os Pontos de Funo No Ajustados Aps serem contadas todas as Funes Tipo Dados e as Funes Tipo Transao e seus elementos, preciso calcular os pontos de funo no ajustados, que refletem especificamente as funcionalidades fornecidas ao usurio pelo produto. Para isso, preciso identificar a complexidade e a contribuio, em pontos por funo, de cada uma das funes e elementos contados.
133
Para determinar a complexidade e contribuio das funes e seus elementos, necessrio utilizar as relaes dos valores de complexidade e contribuio fornecidas pela tcnica. A seguir so apresentadas tabelas que indicam a complexidade e contribuio das funes e seus elementos em um sistema, de acordo com a contagem estabelecida nas etapas (iii) e (iv). A tabela A1.1 indica a complexidade de um Arquivo Lgico Interno ou Arquivo de Interface Externa de acordo com o nmero de Tipos de Elementos de Dados e de Tipos de Elementos de Registros identificados para ele.
Tipos de Elementos de Dados 1 a 19
de Registros Elementos
20 a 50 BAIXA MDIA ALTA
51
MDIA ALTA ALTA
1 2a5
BAIXA BAIXA MDIA
Tipos de
Tabela A1.1 Complexidade de Arquivos Lgicos Internos e Arquivos de Interface Externa (GARMUS e HERRON, 2001)
A tabela A1.2 indica a complexidade de uma Entrada Externa de acordo com o nmero de Tipos de Elementos de Dados e de Arquivos Referenciados identificados para ela. Tambm utilizada para determinar a complexidade das entradas de uma Consulta Externa.
Tipos de Elementos de Dados

Tipos de Arquivos Referenciados
1a4 0 a1 2 BAIXA BAIXA MDIA
16
MDIA ALTA ALTA
Tabela A1.2 Complexidade de Entradas Externas e Entradas das Consultas Externas (GARMUS e HERRON, 2001)
A tabela A1.3 indica a complexidade de uma Sada Externa de acordo com o nmero de Tipos de Elementos de Dados e de Arquivos Referenciados identificados para ela. Tambm utilizada para determinar a complexidade das sadas de uma Consulta Externa.
134
Tipos de Elementos de Dados

Tipos de Arquivos Referenciados
1a5 0 a1 2a3 BAIXA BAIXA MDIA
20
MDIA ALTA ALTA
Tabela A1.3 - Complexidade de Sadas Externas e Sadas das Consultas Externas (GARMUS e HERRON, 2001)
A tabela A1.4 indica as contribuies (pesos) obtidas atravs das complexidades calculadas para as funes identificadas.
Contribuies (pesos) Complexidades ALI BAIXA MDIA ALTA 7 10 15 AIE 5 7 10 EE 3 4 6 SE 4 5 7 CE 3 4 6
Tabela A1.4 - Contribuies (pesos) das complexidades (GARMUS e HERRON, 2001)
Para calcular os pontos de funo no ajustados, multiplica-se o nmero de funes identificadas para uma determinada complexidade por sua contribuio. Ao final, soma-se todos os pontos de funo encontrados. A seguir apresentado um exemplo para o clculo dos pontos de funo no ajustados (PFNA) gerados pelos ALI de um sistema hipottico. O mesmo deve ser feito para a outras funes do sistema (AIE, EE, SE e CE).
Itens Contados Funo por Complexidade 1 Baixa ALI 2 Mdia 1 Alta x 7 x 10 x 15 Contribuio
Total por Complexidade Total de PFNA da Funo 7 20 15 42
Tabela A1.5 Exemplo de clculo dos pontos de funo no ajustados
135
(vi) Calcular Valor do Fator de Ajuste O nmero de pontos de funo no ajustados de um sistema reflete a funcionalidade que o sistema fornecer ao usurio, sem considerar as especificidades do sistema. Por exemplo, um mesmo sistema pode ser implementado para operar stand alone para um cliente e em arquitetura cliente servidor para outro. As funcionalidades seriam as mesmas, o que resultaria na mesma contagem de pontos de funo no ajustados, mas quando considera-se as caractersticas do sistema para cada cliente, observa-se que os pontos de funo devem ser ajustados para refletir a maior complexidade do sistema na arquitetura cliente servidor. Para ajustar os pontos de funo encontrados na etapa (v) devem ser levadas em considerao 14 (quatorze) caractersticas do sistema que sero analisadas e fornecero o valor do fator de ajuste. So elas: Comunicao de Dados, Processamento Distribudo, Performance, Configurao Altamente Utilizada, Taxa de Transaes, Entrada de Dados On-Line, Eficincia do Usurio Final, Atualizao On-Line, Processamento Complexo, Reutilizao, Facilidade de Operao, Facilidade de Instalao, Mltiplos Locais e Modificaes Facilitadas. Para cada caracterstica deve ser atribudo um nvel de influncia de 0 (zero) a 5 (cinco), onde 0 (zero) indica nenhuma influncia, 1 (um) influncia mnima, 2 (dois) influncia moderada, 3 (trs) influncia mdia, 4 (quatro) influncia significativa e 5 (cinco) grande influncia. Para calcular o valor do fator de ajuste deve-se seguir a relao VFA = (GIT * 0,01) + 0,65 Onde

VFA o valor do fator de ajuste GIT o grau de influncia total (soma de todos os valores dos nveis de influncia).
136
(vii) Calcular Pontos de Funo Ajustados Aps calculado o valor do fator de ajuste, os pontos de funo no ajustados sero ajustados, multiplicando-se o valor dos pontos de funo no ajustados (PFNA), obtidos em (v), pelo valor do fator de ajuste (VFA),obtido em (vi). Assim, PFA = PFNA x VFA
O nmero de pontos de funo encontrado representa o tamanho da aplicao de acordo com sua funcionalidade. Para calcular as estimativas de esforo, prazo e custos para a aplicao necessrio conhecer valores como o custo de um ponto de funo (por exemplo R$90,00)7 e o tempo necessrio para realizar um ponto de funo (por exemplo 2,5 h), ou o esforo para realizar um ponto de funo (por exemplo 14 pessoas/ms) e o custo do esforo. Com esses valores possvel calcular as estimativas para o projeto atravs das relaes entre o nmero total de pontos de funo do sistema e os valores de um ponto de funo. Para determinar os valores de um ponto de funo, a organizao pode realizar medies em projetos anteriores e obter um valor mdio para o ponto de funo. Caso no existam projetos anteriores podem ser consultadas tabelas disponibilizadas pelo IFPUG (Institute Function Point Users Group) e por seus rgos representantes em cada pas.
A1. 2 O processo de contagem de Pontos de Caso de Uso O processo de contagem dos pontos de caso de uso pode ser dividido em cinco etapas: (i) calcular o peso dos atores da aplicao; (ii) calcular o peso dos casos de uso da aplicao; (iii) calcular pontos de caso de uso no ajustados (com base nos resultados obtidos em (i) e (ii)); (iv) calcular o valor dos fatores de ajuste; e, (v) calcular os pontos de caso de uso ajustados (com base nos resultados obtidos em (iii) e (vii)). A execuo dessas etapas descrita a seguir. (i) Calcular o Peso dos Atores da Aplicao
Valor fornecido pela empresa FATTO Consultoria e Sistemas Vitria - ES
137
A primeira etapa da contagem de pontos de caso de uso classificar os atores envolvidos em cada caso de uso do sistema e calcular seu peso. Um ator pode ser classificado como simples, mdio ou complexo, de acordo com a tabela A1.6.
Tipo de ator Simples Mdio Complexo
Peso 1 2 3
Descrio Outro sistema acessado atravs de uma API de programao. Outro sistema interagindo atravs de um protocolo de comunicao. Usurio interagindo atravs de uma interface grfica.
Tabela A1.6 Pesos dos Atores (NAGESWARAN, 2001)
O peso dos atores (PA) equivale soma dos pesos de todos os atores do sistema. Desta forma, uma aplicao projetada para dois tipos de usurios (gerente e usurio comum) e que seja acessada por um outro sistema, utilizando um protocolo de comunicao, por exemplo, ter o valor de PA igual a oito (dois atores de nvel complexo e um ator de nvel mdio.
(ii) Calcular o Peso dos Casos de Uso da Aplicao Aps ser calculado o peso dos atores, preciso calcular o peso dos casos de uso do sistema. Os casos de uso, assim como os atores, so classificados em trs tipos: simples, mdio ou complexo. A classificao de um caso de uso se d de acordo com o nmero de transaes envolvidas em seu processamento. Por transao , entende-se como uma srie de processos que devem, garantidamente, ser realizados em conjunto, ou cancelados em sua totalidade, caso no seja possvel completar o processamento. O peso dos casos de uso (PCU) equivale soma dos pesos de todos os casos de uso do sistema. A tabela A1.7 apresenta a classificao dos casos de uso segundo o nmero de transaes.
Tipo de Caso de Uso Simples Mdio Complexo Nmero de Transaes At 3 4a 7 Mais de 7 Peso 1 2 3
Tabela A1.7 Pesos dos Casos de Uso de acordo com o nmero de transaes (NAGESWARAN, 2001)
Os casos de uso podem tambm ser classificados de acordo com o nmero de classes envolvidas, como mostra a tabela A1.8.
138
Tipo de Caso de Uso Simples Mdio Complexo
Nmero de Transaes At 5 5 a 10 Mais de 10
Peso 1 2 3
Tabela A1.8 - Pesos dos Casos de Uso de acordo com o nmero de classes (NAGESWARAN, 2001)
(iii) Calcular o Pontos de Caso de Uso No Ajustados O clculo dos pontos de caso de uso no ajustados (PCUN) realizado atravs da soma dos pesos dos atores (obtido em (i)) e pesos dos casos de uso (obtido em (ii)) do sistema. Assim: PCUN = PA + PCU
(iv) Calcular os Valores dos Fatores de Ajuste O mtodo de ajuste dos pontos de caso de uso bem similar ao adotado na tcnica Anlise de Pontos de Funo, diferindo no fato de que, neste caso, so utilizados dois fatores de ajuste: fator de complexidade tcnica, que considera as caractersticas tcnicas do sistema, e fator ambiental, que considera as caractersticas ambientais que envolvem o sistema. Cada fator de ajuste considera um srie de caratersticas que, ao serem analisadas, recebero um nvel de influncia que pode variar de 0 (zero) a 5 (cinco), onde 0 (zero) indica nenhuma influncia, 1 (um) influncia mnima, 2 (dois) influncia moderada, 3 (trs) influncia mdia, 4 (quatro) influncia significativa e 5 (cinco) grande influncia. Cada nvel de influncia tem um valor numrico correspondente (peso) que ser utilizado no clculo dos fatores de ajuste. O fator de complexidade tcnica considera as seguintes caractersticas: Sistema Distribudo, Tempo de Resposta, Eficincia, Processamento Complexo, Cdigo Reutilizvel, Facilidade de Instalao, Facilidade de Uso, Portabilidade, Facilidade de Mudana, Concorrncia, Recursos de Segurana, Acessibilidade por Terceiros e Necessidade de Treinamento Especial. O fator ambiental considera as seguintes caractersticas: Familiaridade com RUP ou outro processo formal, Experincia com a aplicao em desenvolvimento,
139
Experincia em Orientao a Objeto, Presena de Analista Experiente, Motivao, Requisitos Estveis, Desenvolvedores em Meio Expediente e Linguagem de Programao Complexa. Para as caractersticas do fator ambiental o nvel de influncia a elas atribudo corresponde ao nvel de disponibilidade da caracterstica em questo. Dessa forma, determinar que uma dada caracterstica tem nvel de influncia alta (4 ou 5) significa que esta caracterstica est presente no projeto e influencia no processo de desenvolvimento. Da mesma forma, atribuir um nvel de influncia baixo (0 ou 1) indica que a caracterstica no est presente no processo de desenvolvimento.
Para calcular o fator de complexidade tcnica utiliza-se a frmula: FCT = 0,6 + (0,01 x TT) Onde:

FCT o valor do fator de complexidade tcnica TT a soma dos pesos dos nveis de influncia das caractersticas consideradas
pelo fator de complexidade tcnica atribudos para o sistema.
Para calcular o fator ambiental utiliza-se a frmula: FA = 1,4 + (-0,03 x TA) Onde:

FA o valor do fator ambiental TA a soma dos pesos dos nveis de influncia das caractersticas consideradas
pelo fator ambiental atribudos para o sistema.
(v) Calcular o Pontos de Caso de Uso Ajustados O clculo dos pontos de caso de uso ajustados (PCUA) realizado atravs da multiplicao dos pontos de casos de uso no ajustados (PCUNA), obtido em (iii), pelos fatores de ajuste (FCT e FA), obtidos em (iv). Assim:
PCUA = PCUN x FCT x FA
140
O nmero de pontos de caso de uso encontrado representa o tamanho do sistema. O clculo das estimativas de prazo, esforo e custo realizado da mesma forma que na Anlise de Pontos de Funo, ou seja, necessrio conhecer valores como o custo de um ponto de caso de uso e o tempo necessrio para realiz-lo, ou o esforo para realizar um ponto de caso de uso e o custo do esforo. Com esses valores possvel calcular as estimativas para o projeto atravs das relaes entre o nmero total de pontos de caso de uso do sistema e os valores de um ponto de caso de uso. A1. 3 Exemplo de Contagem utilizando Anlise de Pontos de Funo8 Para exemplificar a utilizao da tcnica Anlise de Pontos de Funo, consideremos um pequeno sistema hipottico desenvolvido para uma academia de ginstica, com o objetivo de cadastrar os alunos matriculadose emitir um relatrio gerencial que apresente o nmero de alunos matriculados totalizados por ms. Considere o diagrama abaixo como representao do sistema hipottico. O arquivo (tabela) Alunos possui 10 atributos.
SECRETRIA
Dados dos alunos
ALUNOS SISTEMA COORDENADOR

Relatrio Gerencial Dados dos alunos
Figura A1.2 Diagrama de Contexto do sistema hipottico.
Passos: (i) Determinar o Tipo de Contagem O tipo de contagem para um Projeto de Desenvolvimento , uma vez que se trata de um sistema a ser desenvolvido e no de manuteno ou de medio em aplicao instalada.
O exemplo aqui apresentado foi extrado de WEBER et. al (2001 )
141
(ii) Identificar a Fronteira da Aplicao No h interao com outros sistemas.
(iii)
Contar Funes Tipo Dados
O nmero de Arquivos Lgicos Internos 1 pois s h manipulao do arquivo Alunos. O nmero de Elementos de Dados 10, que so os atributos do arquivo Alunos. S h um Tipo de Registro em Alunos, pois no h especializao deste arquivo. No h Arquivos de Interface Externa, uma vez que no h interao com outros sistemas.
Arquivos Lgicos Internos 1 (Alunos) Arquivos de Interface Externa 0 (no h interao com outros sistemas) Tabela A1.9 Exemplo de Contagem de Funes Tipo Dados Tipos de Elementos de Dados 10 (atributos de Alunos) Tipos de Elementos de Dados 0 Tipos de Elementos de Registros 1 Tipos de Elementos de Registros 0
(iv)
Contar Funes Tipo Transao
Existem trs Entradas Externas: incluso, alterao e excluso de alunos. Para as duas primeiras existem 10 Elementos de Dados, que so os atributos que so fornecidos como entrada para incluso ou os atributos que podem ser modificados em uma alterao. Para a excluso, apenas um Elemento de Dados considerado, que o cdigo do aluno que ser excludo. Em todas as entradas h apenas um arquivo referenciado: Alunos. Supondo que o sistema possui uma consulta aos dados cadastrais, a funo Consultas Externas apresenta contagem 1. Todos os atributos do arquivo Alunos so exibidos, totalizando 10 Elementos de Dados. Apenas o arquivo Alunos utilizado, ento Arquivos Referenciados igual a 1. A nica Sada Externa o Relatrio Gerencial. Supondo que ele apresente: o cdigo do aluno, nome do aluno, ms da matrcula, totalizador de alunos matriculados por ms e totalizador de alunos matriculados no ano, temos 5 Elementos de Dados. Apenas o arquivo Alunos utilizado, ento Arquivos Referenciados igual a 1.
142
Realizao de Estimativas utilizando Anlise de Pontos de Funo e Pontos de Caso de Uso ________________________________________________________________________________________ Entradas Externas 1 (Incluso) 1 (Alterao) 1 (Excluso) Consultas Externas 1 (Consulta aos dados cadastrais) Sadas Externas 1 (Relatrio Gerencial) Tipos de Elementos de Dados 10 (atributos de Alunos) 10 (atributos de Alunos) 1 (cdigo do alunos) Tipos de Elementos de Dados 10 (atributos de Alunos) Tipos de Elementos de Dados 5 (informaes apresentadas no relatrio) Tabela A1.10 Exemplo de Contagem de Funes Tipo Transao Arquivos Referenciados 1 (Alunos) 1 (Alunos) 1 (Alunos) Arquivos Referenciados 1 (Alunos) Arquivos Reerenciados 1 (Alunos)
(v) Calcular os Pontos de Funo No Ajustados Analisando os valores obtidos no passos acima e as tabelas A1.1 a A1.4 chegamos aos seguintes valores:
Itens Contados Funo por Complexidade 1 Baixa ALI 0 Mdia 0 Alta 0 Baixa AIE 0 Mdia 0 Alta 3 Baixa EE 0 Mdia 0 Alta 1 Baixa CE 0 Mdia 0 Alta 1 Baixa SE 0 Mdia 0 Alta x 7 x 10 x 15 x 5 x7 x 10 x 3 x4 x6 x 3 x4 x6 x 4 x5 x7 Contribuio
Total por Complexidade Total de PFNA da Funo 7 0 0 0 0 0 9 0 0 3 0 0 4 0 0 4 3 9 0 7
Total de Pontos de Funo No Ajustados: 23 Tabela A1.11 Exemplo de clculo dos pontos de funo no ajustados
143
(v)
Calcular Valor do Fator de Ajuste
Para calcular o fator de ajuste, as 14 caractersticas foram consideradas, obtendo-se os seguintes valores:
Caractersticas Gerais do Sistema Nvel de Influncia Comunicao de Dados 0 O sistema opera em micro stand-alone, portanto, no possui comunicao de dados. Processamento Distribudo Performance 0 1 O sistema opera em micro stand-alone. Requisitos de performance foram estabelecidos, mas nenhuma ao especial foi necessria. Configurao altamente utilizada Volume de Transaes Entrada de dados on-line Eficincia do usurio final Atualizao on-line Processamento complexo 0 0 5 3 3 0 No h restries operacionais. Nenhum perodo de pico de transaes esperado. Sistema on-line. Sistema desenvolvido com interface grfica. Sistema on-line, sem proteo para perda de dados. O sistema no executa processamento matemtico ou de segurana. Reusabilidade 1 O sistema foi desenvolvido levando-se em conta reuso de rotinas. Facilidade de instalao 4 Utilizao de ferramenta automtica para implantao do sistema. Facilidade de Operao Mltiplos locais 2 0 Sistema on-line. Nenhuma solicitao do usurio para implantar a aplicao em mais de um local.. Modificao facilitada 0 Nenhuma solicitao do usurio para projetar a aplicao visando minimizar ou facilitar mudanas. Grau de Influncia Total = 19 VFA = (GIT * 0,01) + 0,65 = 0,84 Tabela A1.12 Exemplo de clculo dos fator de ajuste Justificativa
(vi)
Calcular Pontos de Funo Ajustados
Para ajustar os pontos de funo do sistema, basta multiplicar os pontos de funo no ajustados pelo valor do fator de ajuste, como apresentado abaixo: PFA = 23 * 0,84 = 19,32 Sendo assim, o sistema hipottico possui 19 pontos de funo.
144
Anexo 2 Realizao de Estimativas utilizando COCOMOII

Este anexo apresenta os passos necessrios para realizar estimativas utilizando COCOMO II e um exemplo de utilizao do modelo.
A2.1 Os Modelos do COCOMO II Conforme apresentado no captulo 2, COCOMO II funciona como uma hierarquia de modelos que podem ser aplicados de acordo com a evoluo do desenvolvimento do software. A definio dos modelos que o COCOMO II trata apresentada a seguir (BOEHM et al., 2000): Composio da Aplicao: este modelo utilizado para realizar estimativas em projetos que utilizam ambientes ICASE (Integrated Computer-Aided Software Engineering ) para apoiar as fases do desenvolvimento. Esses ambientes
geralmente incluem as seguintes capacidades: um framework para aplicaes com middleware para integrar e gerenciar a execuo dos componentes da aplicao; um conjunto de utilitrios comuns, tais como construtores de interfaces grficas para o usurio, sistemas gerenciadores de bancos de dados e pacotes de suporte rede; um conjunto de componentes reutilizveis por domnio; um repositrio capaz de gerenciar e permitir acesso a esses componentes; e ferramentas de desenvolvimento para projeto, implementao, integrao e testes. importante ressaltar que nem todas as aplicaes so desenvolvidas dessa forma. Mas, para aplicaes que utilizam ambientes ICASE a reduo de prazos e esforos para desenvolver o produto significativa. Devido a essas caractersticas a abordagem para realizao das estimativas no modelo Composio da Aplicao diferente da abordagem dos demais modelos. Esse modelo tambm pode ser utilizado na fase inicial do projeto, onde prottipos da interface com o usurio so construdos, por isso tambm chamado Pr-Prototipao.
145
Realizao de Estimativas utilizando COCOMO II ________________________________________________________________________________________
Pr-Projeto: este modelo utilizado para a realizao de estimativas nas fases iniciais do projeto, onde as informaes do sistema esto parcialmente definidas. Exemplo dessas informaes pode ser a anlise de requisitos do sistema, mesmo que ainda esteja incompleta.
Ps-Arquitetura: este modelo utilizado para a realizao de estimativas do projeto quando este est pronto para ser desenvolvido, ou seja, quando toda a sua especificao, modelagem e projeto tenham sido realizados e informaes detalhadas sobre o que se pretende construir j estejam definidas.
A2.2 Os Fatores de Equilbrio do COCOMO II (BOEHM et al., 2000) Os fatores de equilbrio so cinco caractersticas do projeto que contribuem para a determinao da relao entre o tamanho do sistema e o esforo necessrio para desenvolv-lo. Sua anlise indicar o que ocorre com o esforo do projeto caso seu tamanho seja alterado. Cada fator de equilbrio definido por um conjunto de nveis de influncia (muito baixo, baixo, mdio, alto, muito alto e extremamente alto) e a cada nvel de influncia corresponde um valor numrico. Esses fatores s so considerados para os modelos Pr-Projeto e Ps-Arquitetura. So eles: PREC - Precedncia: Indica o grau de similaridade do projeto em
desenvolvimento com relao a outros desenvolvidos anteriormente. FLEX - Flexibilidade no Desenvolvimento: Indica o grau de flexibilidade do projeto no atendimento aos requisitos pr-estabelecidos. RESL - Resolues de Arquitetura e Risco: Indica o grau de especificao realizada para o projeto no que diz respeito s definies de sua arquitetura e anlise de riscos. TEAM Coeso da Equipe: Indica o grau de interao das pessoas que compem a equipe do projeto: usurios, clientes, desenvolvedores, analistas e outros. PMAT Maturidade do Processo: Indica o grau de maturidade do processo em relao aos nveis de maturidade do CMM (Capability Maturity Model).
146
A2.3 Os Direcionadores de Custos do COCOMO II (BOEHM et al., 2000) Os direcionadores de custos so caractersticas do projeto que interferem diretamente no esforo necessrio para seu desenvolvimento. Cada direcionador de custos definido por um conjunto de nveis de influncias (extremamente baixo, muito baixo, baixo, mdio, alto, muito alto e extremamente alto) e a cada nvel de influncia corresponde um valor numrico, chamado multiplicador de esforo. Apenas os modelos Pr-Projeto e Ps-Arquitetura consideram os direcionadores de custos. O modelo Ps-Arquitetura possui dezessete direcionadores de custos que so agrupados em quatro categorias: Atributos do Produto, Atributos da Plataforma, Atributos da Equipe de Desenvolvimento e Atributos do Projeto. Atributos do Produto so as caractersticas do produto que influenciam na determinao do esforo necessrio para desenvolv-lo. Os direcionadores de custos que representam essas caractersticas so: RELY - Confiabilidade Necessria ao Software: Indica o efeito produzido pela execuo incorreta das funes do software. DATA - Tamanho da Base de Dados: Indica o efeito provocado pelos
requisitos de testes de dados no desenvolvimento do software. medido atravs da relao entre o tamanho da base de dados de testes (em bytes) e o nmero de linhas de cdigo do software. Essa relao importante pois a base para determinar o esforo necessrio para inserir e manter os dados requeridos para realizar os testes do software. CPLX Complexidade do Software: Indica a complexidade do software
considerando cinco grupos de operaes: operaes de controle, operaes computacionais, operaes dependentes de dispositivos, operaes de administrao de dados e operaes de gerncia de interface com o usurio. RUSE - Reutilizabilidade Necessria: Indica o grau de reutilizao dos
componentes que sero desenvolvidos durante a construo do produto. DOCU - Documentao Compatvel com as Necessidades do Ciclo de Vida: Indica o grau de documentao disponvel para atender s necessidades do ciclo de vida do software.
147
Atributos da Plataforma referem-se s caractersticas que devem ser observadas baseando-se nas estruturas de hardware e software a serem utilizadas. Os direcionadores de custos que representam essas caractersticas so: TIME - Restries de Tempo de Execuo: Indica as restries de tempo impostas para o software. Seu valor expresso pelo percentual do tempo de execuo disponvel que ser consumido para a execuo das operaes. STOR - Restries da Memria Principal: Indica as restries impostas para o armazenamento dos dados na memria principal do sistema. Seu valor expresso pelo percentual da capacidade de armazenamento disponvel que ser consumida para a operao do software. PVOL - Mudanas de Plataforma: Indica o tempo previsto para que mudanas na plataforma sejam necessrias.
Atributos da Equipe de Desenvolvimento referem-se s caractersticas que devem ser observadas na equipe que ir desenvolver o software. Depois do tamanho do produto, considera-se que essas so as caractersticas que mais fortemente influenciam na determinao do esforo necessrio para o desenvolvimento . Os direcionadores de custos que representam essas caractersticas so: ACAP Capacidade dos Analistas: Indica a capacidade dos analistas como equipe e no individualmente. Considera habilidades de anlise, projeto, comunicao, cooperao e eficincia. PCAP Capacidade dos Programadores: Indica a capacidade dos programadores como uma equipe e no individualmente. Considera habilidades lgicas, de comunicao, cooperao e eficincia. PCON Rotatividade de Pessoal: Indica a taxa de rotatividade anual de pessoal. APEX Experincia na Aplicao: Indica o tempo de experincia da equipe no desenvolvimento de aplicaes similares ao software a ser desenvolvido. PLEX Experincia com a Plataforma: Indica o tempo de experincia da equipe na utilizao da plataforma de desenvolvimento utilizada no software.
148
LTEX Experincia com a Linguagem e Ferramentas: Indica o tempo de experincia da equipe na utilizao das ferramentas e linguagens utilizadas no software a ser desenvolvido.
Atributos do Projeto referem-se s caractersticas que devem ser observadas no projeto a ser desenvolvido, tais como: utilizao de tecnologias, localizao da equipe de desenvolvimento e restries de cronograma. Os direcionadores de custos que representam essas caractersticas so: TOOL - Uso de Ferramentas de Software: Indica o grau de utilizao de ferramentas de software para apoiar o desenvolvimento do produto. SITE - Desenvolvimento Multilocal: Indica a localizao da equipe e a forma de comunicao entre seus membros. SCED - Prazo Necessrio para o Desenvolvimento: Indica as restries impostas no cronograma de desenvolvimento do projeto. Sua definio se d atravs da porcentagem do prazo previsto que representa a restrio de tempo, ou seja, o tempo em que o sistema dever ser desenvolvido.
O modelo Pr-Projeto possui sete direcionadores de custos. A reduo do nmero de direcionadores se d pois nesse modelo muitas informaes ainda no foram definidas, o que dificulta o detalhamento de todos os direcionadores definidos anteriormente. Alguns direcionadores desse modelo correspondem a uma combinao das caractersticas tratadas nos direcionadores apresentados anteriormente. Os direcionadores do modelo Pr-Projeto so: RCPX - Confiabilidade e Complexidade do Produto: RELY, DATA, CPLX e DOCU. RUSE Reutilizabilidade Necessria: o mesmo direcionador utilizado no modelo Ps-Arquitetura. Indica o grau de reutilizao dos componentes que sero desenvolvidos durante a construo do produto. PDIF Dificuldades com a Plataforma: Indica o grau de dificuldade com a plataforma de desenvolvimento levando-se em considerao restries de tempo, Indica o grau de
confiabilidade e complexidade do produto. a combinao dos direcionadores
149
memria e caractersticas da plataforma. a combinao dos direcionadores TIME, STOR e PVOL. PERS - Capacidade do Pessoal: Indica a capacidade do pessoal envolvido no desenvolvimento do produto, considerando analistas e programadores. a combinao dos direcionadores ACAP, PCAP e PCON. PREX Experincia Profissional do Pessoal: Indica o grau de experincia do pessoal envolvido no desenvolvimento do produto no que diz respeito plataforma, linguagem e aplicao. a combinao dos direcionadores APEX, PLEX e LTEX. FCIL Facilidades: Indica o grau de utilizao de facilidades para o desenvolvimento do software, como por exemplo a utilizao de ferramentas de apoio ao desenvolvimento do software e ao desenvolvimento multilocal. a combinao dos direcionadores TOOL e SITE. SCED - Prazo Necessrio para o Desenvolvimento: o mesmo direcionador do modelo Ps-Arquitetura. Indica as restries impostas no cronograma de desenvolvimento do projeto. Sua definio se d atravs da porcentagem do prazo previsto que representa a restrio de tempo, ou seja, o tempo em que o sistema dever ser desenvolvido.
A2.4 O Processo de Realizao de Estimativas utilizando COCOMO II (BOEHM et al., 2000) O processo de realizao de estimativas de software utilizando o COCOMO II pode ser resumido em quatro etapas: (i) determinar o modelo da aplicao; (ii) realizar estimativas de esforo; (iii) realizar estimativas de prazo; e (iv) realizar estimativas de custos. Essas etapas so descritas a seguir:
(i) Determinar o Modelo da Aplicao Para realizar estimativas utilizando COCOMO II, inicialmente necessrio analisar qual ser o modelo utilizado, de acordo com as caractersticas da fase de desenvolvimento em que o software se encontra. Os modelos do COCOMO II foram apresentados na seo A2.1.
150
(ii) Realizar Estimativas de Esforo Aps ter sido identificado o modelo pertinente ao projeto, deve-se realizar a
estimativa de esforo. Os modelos Pr-Projeto e Ps-Arquitetura seguem os mesmos passos para a realizao da estimativa de esforo, porm, o modelo Composio da Aplicao segue um caminho diferente, devido a suas particularidades anteriormente mencionadas. O item (ii.a) apresenta a descrio dos passos utilizados para o clculo do esforo nos modelos Pr-Projeto e Ps-Arquitetura. O item (ii.b) descreve os passos para calcular a estimativa de esforo no modelo Composio da Aplicao. Em ambos, o resultado apresentado na unidade pessoas/ms, que indica quantas pessoas so necessrias para completar o desenvolvimento do software em um ms.
(ii.a) Clculo do Esforo para os modelos Pr-Projeto e Ps-Arquitetura
Para realizar a estimativa de esforo utilizada a frmula a seguir:

i=n
E(P/M) = A x tamanho x Onde:
MEi
i=1
A uma constante nica para todos os modelos, com valor 2,94. Essa constante, entretanto, pode ser alterada se novas calibraes forem realizadas9.
O tamanho do software pode ser definido atravs do nmero de linhas de cdigo fonte ou atravs do nmero de pontos de funo. Quando o tamanho do software definido em nmero de pontos de funo, o mesmo deve ser convertido para nmero de linhas de cdigo fonte atravs da utilizao de
Conforme apresentado no captulo 2, novas calibraes podem ser realizadas pela equipe que props o
COCOMO II, por outros grupos de pesquisa ou, ainda, desenvolvida por empresas que utilizem o modelo com base em suas prprias experincias no desenvolvimento de software. Essas calibraes so realizadas para melhorar a adequao do COCOMO II aos projetos/empresa onde aplicado, tornando as estimativa mais acuradas. As calibraes tambm podem ser aplicadas a outras constantes e aos valores dos fatores de equilbrio e direcionadores de custos.
151
tabelas padro que indicam quantas linhas de cdigo fonte correspondem a um ponto de funo em uma determinada linguagem.
i=5
Para determinar o valor de G10, utiliza-se a frmula G = B + 0,01 x

i=1
FEi ,
onde B uma constante, com valor 0,91. Essa constante, entretanto, pode ser alterada se novas calibraes forem realizadas.
i=5
O valor de
i=1
FEi obtido atravs da anlise dos cinco fatores de equilbrio
(FE), apresentados em A2.2 Para cada fator de equilbrio deve ser indicado um valor relacionado ao nvel de influncia deste para o projeto (muito baixo, baixo, mdio, alto, muito alto e extremamente alto). Ao nvel indicado corresponder um valor numrico a ser considerado, de acordo com as tabelas A2.1 e A2.2, apresentadas a seguir.
10
Analisando o valor do expoente G possvel conhecer o comportamento do projeto em situaes
de aumento do tamanho do mesmo. Se G < 1 o projeto em questo exibe o que BOEHM et. al (2000) chama de escala econmica, ou seja, se o tamanho do projeto dobrar , por exemplo, o esforo necessrio para desenvolv-lo ser menor que o dobro do calculado. Se G = 1, as alteraes de tamanho e esforo so equivalentes. Se G > 1 o projeto exibe uma escala decrescente de economia, ou seja, se o tamanho do sistema aumentar, o esforo necessrio para desenvolv-lo aumentar em propores maiores.
152
Nveis de Inluncia Fatores

PREC FLEX RESL TEAM
Muito baixo Baixo Mdio Alto Muito alto Extremamente alto Nenhuma precedncia Muito Rigoroso Pequeno (20% ) Interaes muito difceis Pouca precedncia Flexibilidade ocasional Algum (40%) Alguma dificuldade de interao Precedncia moderada Alguma familiaridade Muita familiaridade Alguma conformidade Bom (90%) Altamente cooperativo Completo (100% ) Interao total Completamente familiar Metas usuais
Flexibilidade Conformidade moderada Regular (60%) Interaes basicamente cooperativas CMM nvel 2 CMM nvel 3 usual Geral (75%) Amplamente cooperativo
PMAT
Inferior ao CMM nvel 1
Superior ao CMM nvel 1
CMM nvel 4
CMM nvel 5
Tabela A2.1 - Determinao do Nvel de Influncia dos Fatores de Equilbrio
Fatores de Equilbrio
Muito baixo Baixo
Nvel de Influncia
Mdio Alto Muito alto Extremamente alto
PREC FLEX RESL TEAM PMAT
6,20 5,07 7,07 5,48 7,80
4,96 4,05 5,65 4,38 6,24
3,72 3,04 4,24 3,29 4,68
2,48 2,03 2,83 2,19 3,12
1,24 1,01 1,41 1,10 1,56
0,00 0,00 0,00 0,00 0,00
Tabela A2.2 Valores atribudos aos Fatores de Equilbrio de acordo com os Nveis de Influncia
153

i=n
O valor de
i=1
ME i na frmula de esforo obtido atravs do somatrio dos
valores resultantes da anlise dos nveis de influncia dos direcionadores de custos de cada modelo, que foram apresentados na seo A2.3. Neste momento o direcionador de custos SCED no deve ser considerado. Para cada direcionador de custos deve ser indicado um valor relacionado ao nvel de influncia deste para o projeto (extremamente baixo, muito baixo, baixo, mdio, alto, muito alto e extremamente alto). Ao nvel indicado corresponder um valor numrico (multiplicador de esforo ME ) a ser considerado, de acordo com as tabelas A2.3 a A2.5, apresentadas a seguir:
154
Realizao de Estimativas utilizando COCOMO II ____________________________________________________________________________________________________________________________________________
Nvel de Influncia
Baixo Perdas moderadas 10 Tamanho do BD de testes/SLOC do programa < 100 Tamanho do BD de testes/SLOC do programa 1K 100 Tamanho do BD de testes/SLOC do programa < 1K Altas perdas financeiras Risco vida humana Mdio Alto Muito alto Extremamente alto
Direcionador
Muito baixo
RELY
Leve inconvenincia
DATA
Perdas facilmente recuperadas Tamanho do BD de testes/SLOC do programa < 10
CPLX11
Controle de microcdigo. Programao dinmica de recursos. Controle distribudo em tempo real .
Operaes de Controle
Cdigo reentrante e Operadores em uso Uso de tabelas de Cdigo simples, com Considervel controle recursivo. Manipulao de interrupes. poucos operadores apenas em programao deciso. Algum suporte entre mdulos. Controle estruturada. Predicados a processamento Sincronizao de sendo usados em de filas e pilhas. tarefas. Chamadas programao no simples. distribudo Operadores aninhados. estruturada. Aninhamentos simples. Processamentos complexas. Composio simples distribudos Processamentos homogneos. Distribudos do mdulo, via Heterogneos. chamadas a Controle simples de Controle de procedimentos ou processador de tempo real. processador de tempo scripts simples. real. Avaliao de expresses moderadas.
Operaes computacionais
Avaliao de expresses simples.
Uso de rotinas matemticas e estatsticas padro. Operaes bsicas de matrizes e vetores.
Anlise numrica bsica, interpolao multivariada, equaes diferenciais ordinrias.
Anlise numrica complexa. Equaes matriciais. Equaes diferenciais parciais. Paralelismo simples.
Anlise numrica difcil e no estruturada, dados estocsticos. Paralelismo complexo.
Tabela A2.3 - Determinao dos Nveis de Influncia dos Direcionadores de Custos do Modelo Ps-Arquitetura
11
O gerente deve analisar todas as reas do direcionador que se aplicam ao produto a ser desenvolvido e determinar seu nvel de influncia atravs de uma mdia subjetiva dos nveis de influncia de suas reas. O mesmo ocorre para o direcionador SITE.
155
Nvel de Influncia
Baixo Mdio Alto Muito alto Extremamente alto
Direcionador
Muito baixo
CPLX
Operaes dependentes de dispositivos
Instrues de leitura e gravao simples, com formatos simples.
Operaes em nvel fsico de entrada e sada. Otimizao de entradas e sadas duplicadas.
Rotinas para diagnstico de interrupo. Manipulao da linha de comunicao. Sistemas embutidos de processamento intenso.
Operaes microprogramadas. Sistemas embutidos de processamento crtico.
Operaes de administrao de dados
Arrays simples na memria principal, consultas e atualizaes simples.
Nenhum conhecimento Processamento de entrada e sada inclui necessrio sobre as seleo de dispositivo, caractersticas do processador ou checagem de status e dispositivos de entrada processamento de erros. e sada. As entradas e sadas so executadas no nvel GET/PUT. Arquivos simples, sem Entrada multiarquivo e edies, alteraes de sada em monoarquivo. estruturas de dados ou Mudanas estruturais arquivos intermedisimples. Consultas e rios. Consultas e atualizaes complexas. atualizaes moderadamente complexas. Triggers simples ativadas pelo fluxo de dados. Reestruturao de dados complexa. Coordenao de bases de dados distribudas. Triggers complexas. Otimizao de pesquisas. Uso de construtores simples de interface grfica. Uso simples de conjunto widget Recursos moderadamente complexos de 2D/3D, grficos dinmicos e multimdia.
Unio de estruturas relacionais e por objetos. Gerncia de dados em linguagem natural.
Operaes de gerncia de interface com usurio

Nenhum Aproveitamento em projetos.
Formulrios simples e geradores de relatrios.
RUSE
Desenvolvimento e extenso de conjuntos widget. Recursos simples de entrada e sada de voz e multimdia. Aproveitamento em programas.
Recursos multimdia complexos. Realidade virtual. Interface em linguagem natural. Aproveitamento em linhas de produtos. Aproveitamento em mltiplas linhas de produtos.
Tabela A2.3 - Determinao dos Nveis de Influncia dos Direcionadores de Custos do Modelo Ps-Arquitetura (continuao)
156
Nvel de Influncia
Baixo Mdio Alto Muito alto Extremamente alto
Direcionador
Muito baixo
DOCU
Muito escassa para as necessidades Do ciclo de vida.
Pouca para as necessidades do ciclo de vida.
TIME
STOR
PVOL
ACAP PCAP PCON
15 percentil 15 percentil Rotatividade de
pessoal de 48% ao
Adequada para as Excessiva para as Muito excessiva para necessidades necessidades as necessidades do ciclo de vida. do ciclo de vida. do ciclo de vida. Utilizao Utilizao Utilizao de Utilizao de de 70% do tempo de 85% do tempo de 95% do tempo de 50% do tempo de execuo disponvel execuo disponvel execuo disponvel execuo disponvel Utilizao Utilizao Utilizao de Utilizao de de 70% do armazena85% do armazena95% do armazenamento 50% do armazenamento disponvel mento disponvel disponvel mento disponvel Perodo para grande Perodo para grande Perodo para grande Perodo para grande mudanas: 12 meses mudanas: 6 meses mudanas: 2 meses mudanas: 2 semanas Pequenas: 1 ms Pequenas: 2 semanas Pequenas: 1 semana Pequenas: 2 dias 35 percentil 55 percentil 75 percentil 90 percentil 35 percentil 55 percentil 75 percentil 90 percentil Rotatividade de pessoal Rotatividade de pessoal Rotatividade de pessoal Rotatividade de pessoal de 24% ao ano de 12% ao ano de 6% ao ano de 3% ao ano
ano 6 meses de experincia 6 meses de experincia 1 ano de experincia 1 ano de experincia 3 anos de experincia 3 anos de experincia 6 anos de experincia 6 anos de experincia
APEX
PLEX
2 meses de experincia 2 meses de experincia
157
Nvel de Influncia
Baixo 6 meses de experincia Uso de ferramentas CASE simples. Pequena integrao. Uso de ferramentas bsicas, moderadamente integradas. Uso de ferramentas pesadas, moderadamente integradas. 1 ano de experincia 3 anos de experincia 6 anos de experincia Mdio Alto Muito alto Extremamente alto
Direcionador
Muito baixo
LTEX
TOOL
2 meses de experincia Uso de ferramentas para edio, codificao e depurao. Uso de ferramentas pesadas, pr-ativas, bem integradas, com processos e mtodos. Reutilizao.
SITE Localizao
Mltiplas cidades e empresas. Telefone individual e fax. Mltiplas cidades ou empresas. Correio eletrnico em banda estreita.
Internacional
Desenvolvimento em um nico local.. Multimdia interativa.
Comunicaes
Telefone e correio.
SCED
Execuo do projeto em 75% do cronograma original
Mesma cidade ou rea Mesmo prdio ou metropolitana. conjunto de prdios. Comunicao eletrnica Comunicao eletrnica em banda larga. em banda larga e ocasionalmente vdeo conferncia. Execuo do projeto em Execuo do projeto em Execuo do projeto em Execuo do projeto em 85% do cronograma 100% do cronograma 130% do cronograma 160% do cronograma original original original original
158
Direcionador
Muito baixo Baixo Mdio Alto Muito alto
Nveis de Influncia
Extremamente Alto
Extremamente baixo
5, 6
7, 8
9-11
12
13-15
16-18
19-21
RCPX12 Soma dos nveis de influncia de RELY, DATA, CPLX e DOCU Combinao de confiana (RELY) e documentao (DOCU)
Pequena Alguma Bsica Forte Muito forte Simples Alguma Moderada Complexo
Muito pequena
Extremamente forte Muito complexo Extremamente complexo
Complexidade do produto (CPLX)
Muito simples
Pequena
Pequena
Pequena
Moderada Idem tabela A2.3
Grande
Muito grande
Muito grande
Tamanho da Base de Dados (DATA) RUSE PDIF Soma dos nveis de influncia de TIME, STOR e PVOL
8 9
10-12
13-15
16, 17
Tabela A2.4 - Determinao dos Nveis de Influncia dos Direcionadores de Custos do Modelo Pr-Projeto
12
O gerente deve analisar todos os itens do direcionador e determinar seu nvel de influncia atravs de uma mdia subjetiva dos nveis de influncia dos itens. Para realizar a soma dos nveis dos direcionadores do modelo Ps-Arquitetura que compoem o direcionador do modelo Pr-Projeto (primeiro item) basta considerar que o nvel de influncia muito baixo para o direcionador no modelo Ps-Arquitetura corresponde ao valor 1, baixo corresponde ao valor 2, mdio ao valor 3, alto ao valor 4, muito alto ao valor 5 e extremamente alto ao valor 6. Essas observaes valem tambm para os direcionadores PDIF, PERS, PREX e FCIL.
159
Direcionador Nveis de Influncia

Extremamente baixo
Extremamente Alto
PDIF Mudanas de plataforma

Muito estvel 50% 65% 50% 80% Estvel Alguma volatilidade Voltil
Muito voltil 90%
3, 4
5, 6
7, 8
10, 11
12,13
14, 15
20% 30% 20% 12%
35%
45%
55%
65% 9%
75% 6%
85% 4%
45%
Combinao das restries de tempo (TIME) e memria (STOR) PERS Soma dos nveis de influncia de ACAP, PCAP e PCON Combinao da capacidade dos analistas (ACAP) e programadores (PCAP) Rotatividade de pessoal (PCON) PREX Soma dos nveis de influncia de APEX, PLEX e LTEX
5, 6 7, 8 9 10, 11
3, 4
12, 13
14, 15
Tabela A2.4 - Determinao dos Nveis de Influncia dos Direcionadores de Custos do Modelo Pr-Projeto (continuao)
160
Direcionador Nveis de Influncia

Extremamente baixo
Extremamente Alto
3 meses 5 meses 9 meses 1 ano 2 anos
4 anos
6 anos
11 2 Algum Uso de ferramentas CASE simples. Uso de ferramentas CASE bsicas. 3 4, 5 6 7, 8 Uso de boas ferramentas, moderadamente integradas. 9, 10 Uso de ferramentas muito boas, moderadamente integradas. Uso de ferramentas muito boas e bem integradas.
PREX Combinao de experincias com a aplicao (APEX), plataforma (PLEX) e linguagem (LTEX) FCIL Soma dos nveis de influncia de TOOL e SITE
Facilidades oferecidas por ferramentas (TOOL)
Mnimo
Apoio muito forte Apoio para Apoio bsico para Apoio forte para Apoio forte para para desenvolviPouco apoio para Algum apoio para Algum apoio para desenvolvimento multilocal desenvolvimentos multilocal desenvolvidesenvolvidesenvolvidesenvolvidesenvolvi(SITE) mentos multilocal mentos multilocal mentos multilocal mentos multilocal mentos multilocal mentos multilocal simples ou complexos. moderadamente complexos. moderadamente complexos. Idem tabela A2.3 moderadamente complexos. simples. desenvolvimentos em um nico. Local.
complexos.
SCED
Tabela A2.4 - Determinao dos Nveis de Influncia dos Direcionadores de Custos do Modelo Pr-Projeto (continuao)
161
Realizao de Estimativas utilizando COCOMO II _____________________________________________________________________________________
Nvel de Influncia Direcionadores

ExtremaMente baixo Muito baixo Baixo Mdio Alto Muito alto Extremamente alto
RELY DATA CPLX RUSE DOCU TIME STOR PVOL ACAP PCAP PCON APEX PLEX LTEX TOOL SITE SCED RCPX PDIF PERS PREX FCIL
Tabela A2.5 -
0,82
0,92 0,90
1,00 1,00 1,00 1,00 1,00 1,00 1,00
1,10 1,14 1,17 1,07 1,11 1,11 1,05 1,15 0,85 0,88 0,90 0,88 0,91 0,91 0,90 0,93 1,00 1,33 1,29 0,83 0,87 0,87
1,26 1,28 1,34 1,15 1,23 1,29 1,17 1,30 0,71 0,76 0,81 0,81 0,85 0,84 0,78 0,86 1,00 1,91 1,81 0,63 0,74 0,73 2,72 2,61 0,50 0,62 0,62 0,80 1,63 1,46 1,74 1,24
0,73
0,87 0,95
0,81
0,91
0,87 1,42 1,34 1,29 1,22 1,19 1,20 1,17 1,22 1,43 0,49 0,60 1,19 1,15 1,12 1,10 1,09 1,09 1,09 1,09 1,14 0,83 0,87 2,12 1,59 1,43 1,62 1,33 1,30 1,26 1,12 1,10
1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00 1,00
Determinao dos Multiplicadores de Esforo dos Nveis de Influncia dos
Direcionadores de Custos
Para processos de manuteno devem ser utilizados os direcionadores de custos do modelo Ps-Arquitetura, excluindo-se RUSE e SCED.
162
(ii.b) Clculo do Esforo para os modelos Composio da Aplicao O modelo Composio da Aplicao, como mencionado anteriormente, tem caractersticas diferentes dos demais modelos, por isso o clculo do esforo estimado necessrio para execut-lo ocorre de outra forma. Utilizar nmero de linhas de cdigo fonte para estimar o tamanho do software nesse modelo pode ser inexpressivo, uma vez que quando h utilizao de geradores de interface, linguagens visuais e outras facilidades dos ambientes ICASE, o nmero de linhas de cdigo no capaz de refletir o tamanho real do produto. O mesmo ocorre para os pontos de funo. Sendo assim, os pesquisadores do COCOMO II (BOEHM et al., 2000) acrescentaram escalas de produtividade tcnica de medio em pontos de objeto e a chamaram de medio em pontos de aplicao. Essa medio estima o tamanho do sistema atravs de estimativas do nmero de telas, relatrios e componentes de linguagem de 3 gerao (3GL). A maioria dos autores consideram essa medio ainda com o nome original (pontos de objeto). Para estimar o esforo nesse modelo, sete passos devem ser seguidos:
Passo 1: Estimar o nmero de telas, relatrios e componentes de linguagem de 3 gerao do software. Neste passo so contados os elementos presentes no software. As definies padro do ambiente ICASE tambm devem ser consideradas.
Passo 2: Classificar cada elemento identificado segundo seu nvel de complexidade. Para classificar os elementos preciso consultar as tabelas A2.6, para classificar as telas, e A2.7, para classificar os relatrios. Nas tabelas apresentadas a seguir, srv o nmero de tabelas de dados do servidor utilizadas na tela ou relatrio e cln o nmero de tabelas de dados de clientes utilizadas na tela ou relatrio.
Fontes das tabelas de dados Nmero de Views Total < 4 (< 2 srv, < 3 cln) >3 37 Simples Simples Mdia Total < 8 ( 2-3 srv, 3-5 cln) Simples Mdia Difcil Total 8 (> 3 srv, > 5 cln) Mdia Difcil Difcil
Tabela A2.6 Nveis de Complexidade de Telas
163
Fontes das tabelas de dados Nmero de Sees Total < 4 (< 2 srv, < 3 cln) 01 23 >3 Simples Simples Mdia Total < 8 ( 2-3 srv, 3-5 cln) Simples Mdia Alta Total 8 (> 3 srv, > 5 cln) Mdia Alta Alta
Tabela A2.7 Nveis de Complexidade de Relatrios
Passo 3: Avaliar o peso correspondente complexidade determinada para os elementos identificados. Esse passo executado consultando-se a tabela a seguir:
Pesos Tipo de Elemento Complexidade Simples Telas Relatrios Componentes 3GL 1 2 Complexidade Mdia 2 5 Complexidade Alta 3 8 10
Tabela A2.8 Pesos das Complexidade dos Elementos
Passo 4: Determinar o nmero de pontos de aplicao do software. Esse passo executado atravs da frmula a seguir: PA = Onde: PA = nmero de pontos de aplicao T = (n de telas com complexidade simples) + (n de telas com complexidade mdia x 2) + (n de telas com complexidade alta x 3) R = (n de relatrios com complexidade simples x 2) + (n de relatrios com complexidade mdia x 5) + (n de relatrios com complexidade alta x 8) C = (n de componentes 3GL x 10) T+ R+ C
164
Passo 5: Estimar a porcentagem de reutilizao esperada para o projeto. Corresponde porcentagem de telas, relatrios e componentes de linguagens de 3 gerao que sero utilizadas de aplicaes desenvolvidas anteriormente. Aps esse valor ser estimado, o nmero de novos pontos de aplicao deve ser calculado, atravs da frmula:
NPA = PA x (100 %R) /100 Onde: NPA = nmero de pontos de aplicao do software considerando a reutilizao de componentes de outras aplicaes PA = nmero de pontos de aplicao sem considerar a reutilizao de componentes (valor estimado no passo 4) %R = porcentagem de reutilizao estimada
Passo 6: Determinar a taxa de produtividade. Esse passo executado consultando-se a tabela a seguir:
Caracterstica Experincia e capacidade dos desenvolvedores Muito baixo Maturidade e Capacidade do ambiente ICASE Muito baixo PROD (taxa de produtividade) 4 7 13 25 Baixo Mdio Alto Baixo Nveis Mdio Alto Muito alto Muito alto 50
Tabela A2.9 Taxa de Produtividade
Passo 7: Realizar a estimativa de esforo. Esse passo executado atravs da frmula a seguir: E(PM) = NAP/PROD Onde: E = esforo estimado (pessoas/ms) NAP = nmero dos novos pontos de aplicao (estimado no passo 5) PROD = taxa de produtividade (estimada no passo 6)
165
(iii) Realizar Estimativas de Prazo Aps ter sido estimado o esforo (itens (ii.a) ou (ii.b)) o mesmo deve ser feito para o prazo. Para calcular o prazo estimado para o projeto, inicialmente deve ser feito o clculo do prazo original, ou seja, sem considerar qualquer restrio do tempo de desenvolvimento para o projeto. Essa estimativa realizada atravs da frmula P(M) = C x EF que fornece o prazo em meses, onde:
C uma constante nica para todos os modelos, com valor 3,67. Essa constante, entretanto, pode ser alterada se novas calibraes forem realizadas.
F = D + 0,2 x (G B), onde D = 0,28 (podendo ser alterado por calibraes) e G o valor encontrado no clculo do esforo.
E o valor do esforo resultante da etapa (ii) do processo.
Obtido o prazo original previsto para a realizao do projeto preciso observar se h restrio de tempo de desenvolvimento para o mesmo e qual a relao entre o prazo original previsto e essa restrio, caso exista. Essa relao considerada pelo direcionar SCED que indica o grau de compresso do prazo original para atender s restries de tempo especificadas para o projeto. Para incluir o direcionador SCED no clculo do esforo, basta multiplicar o prazo original (P(M) = C x EF) por SCED% / 100, onde:
SCED% indica a porcentagem de compresso correspondente ao multiplicador de esforo atribudo ao direcionador de custos SCED. Por exemplo: durante a anlise do prazo originalmente previsto, o gerente do projeto observou que o projeto deveria ser concludo em 70% do prazo originalmente previsto, sendo assim, atribuiu ao direcionador SCED o nvel de influncia muito baixo, resultando no multiplicador de esforo 1,43 (obtido analisando-se as tabelas A2.3 e A2.5). Para realizar a estimativa do prazo considerando a restrio e tempo, preciso analisar qual a porcentagem de compresso do direcionar de custos SCED no nvel de influncia correspondente ao multiplicador 1,43, isto , nvel muito baixo. Observando a tabela A2.3 possvel notar que o nvel muito baixo
166
corresponde a uma compresso de 75% tempo original. Sendo assim, SCED% receberia o valor 75.
(iv) Realizar Estimativas de Custos A estimativa dos custos depende dos resultados obtidos nas etapas (ii) e (iii). Para obter o nmero mdio de pessoas que devero ser alocadas ao projeto, basta dividir o valor do esforo pelo prazo. O COCOMO II considera que um ms equivale a 152 horas de trabalho, mas este valor pode ser modificado para se adequar a empresas especficas. Para proceder no clculo dos custos, necessrio conhecer o custo dos recursos humanos que sero utilizados no projeto, como por exemplo, o valor/hora ou valor/ms de um profissional ou o valor/hora padro utilizado pela organizao, definido a partir da anlise de dados de projetos realizados anteriormente. Para realizar a estimativa dos custos, basta calcular o produto do custo de uma unidade de esforo (valor/hora por exemplo) pelo tempo de utilizao do mesmo. Por exemplo, se as estimativas de esforo e prazo de um projeto foram respectivamente 5 pessoas e 10 meses, para estimar os custos desse projeto basta multiplicar o valor/ ms de cada pessoa pelo prazo em que elas estaro no projeto, que, nesse caso, so 10 meses.
A2. 5 Exemplo de estimativas utilizando COCOMO II Para exemplificar a utilizao do COCOMO II, consideremos o sistema hipottico desenvolvido para uma academia de ginstica do exemplo de contagem utilizando Anlise de Pontos de Funo apresentado no Anexo 1.
(i) Determinar o Modelo da Aplicao Suponhamos que uma primeira verso da especificao de requisitos do sistema j tenha sido realizada, porm os detalhes ainda no foram descritos. Sendo assim, o modelo utilizado ser Pr-Projeto.
167
(ii) Realizar Estimativas de Esforo Para realizar o clculo da estimativa de esforo para o sistema, os fatores de equilbrio e direcionadores de custos devem ser analisados. O gerente do projeto realizou essa anlise e forneceu os seguintes valores:
Valor Fatores de Equilbrio PREC Precedncia FLEX Flexibilidade no Desenvolvimento RESL Resolues de Arquitetura e Risco TEAM Coeso da equipe PMAT Maturidade do processo Nvel de Influncia Muito alto Extremamente alto Muito alto Muito alto Mdio Justificativa Muita Familiaridade Metas usuais Bom (90%) Altamente cooperativo CMM nvel 2 numrico 1,24 0,00 1,41 1,10 4,68
Tabela A2.10 Valores dos fatores de equilbrio para o exemplo apresentado
Direcionadores de Custos
Nvel de Influncia
Justificativa
Multiplicador de Esforo
RCPX Confiabilidade e Complexidade do Produto
Baixo
RUSE Reutilizabilidade Necessria
Mdio
PDIF Dificuldades com a Plataforma
Baixo
PERS Capacidade do Pessoal
Muito Alto
PREX Experincia Profissional do Pessoal
Alto
Confiana e documentao bsica, pouca complexidade e base dados pequena Aproveitamento em projetos No h restries de tempo de execuo, utilizao de memria e a plataforma considerada estvel. Baixa rotatividade de pessoal e analistas e programadores com boa capacidade Experincia mdia de 2 anos com plataforma, aplicao e linguagem Uso de ferramentas CASE bsicas e pouco apoio para desenvolvimento multilocal complexo.
0,83
1,00 0,87
0,63
0,87
FCIL Facilidades
Mdio
1,00
SCED Prazo necessrio para o Desenvolvimento
No h restrio de tempo de desenvolvimento Tabela A2.11 Valores dos direcionadores de custos para o exemplo apresentado
Mdio
1,00
168
Para proceder no clculo do esforo, utilizamos a frmula a seguir:

i=n
E(P/M) = A x tamanhoG x Onde:

MEi
i=1
A = 2,94 (constante). O tamanho do software foi calculado em pontos de funo no exemplo apresentado no Anexo 1. importante observar que aqui deve ser considerado o nmero de pontos de funo no ajustados, que para o exemplo em questo vale 23. O tamanho em pontos de funo deve ser transformado em nmero de linhas de cdigo fonte, utilizando-se tabelas de relao entre um ponto de funo e o nmero de linhas de cdigo fonte correspondente em uma determinada linguagem. Supondo que o sistema aqui exemplificado seja implementado em Power Builder, utilizando a tabela de converso encontrada em BOEHM et al. (2000), tem-se que um ponto de funo no ajustado equivale a 16 linhas de cdigo fonte em Power Builder. Sendo assim, tamanho = 368 SLOC = 0,368 KLOC .
i=5
G = B + 0,01 x
i=1
FEi = 0,91 + 0,01 x 8,43 = 0,9943
Assim, obtemos:
i=n
E(P/M) = A x tamanho x
MEi
i=1
E(P/M) = 2,94 x 0,3680,9943 x 5,2 E(P/M) = 5,66 (iii) Realizar Estimativas de Prazo Para calcular o prazo, utilizamos a seguinte frmula: P(M) = C x EF Onde:

C = 3,67 (constante). F = D + 0,2 x (G B) = 0,28 + 0,2 x (0,9943 0,91) = 0,3. E = 5,66
169
Assim: P(M) = C x EF P(M) = 3,67 x 5,66 0,3 P(M) = 6,17
Como no h restries de tempo e SCED % = 100 no h necessidade de consider-lo no clculo do prazo, pois 100/100 = 1.
(iv) Realizar Estimativas de Custos Inicialmente, preciso obter o nmero mdio de pessoas que sero alocadas equipe do projeto. Para isso, basta dividir o valor do esforo pelo prazo. Assim, equipe = 5,66 / 6,17 = 0,92 1 pessoa. Suponhamos que o salrio mdio dessa pessoa R$1200,00 Para calcular os custos (C) basta multiplicar o salrio do recurso pelo seu tempo de utilizao, assim: C(R$) = 1200 x 5,66 = 6792 A2. 6 Consideraes Os valores encontrados com a utilizao do COCOMO II foram relativamente altos para um sistema hipottico simples como o apresentado, o que demonstra que calibrar o modelo com dados prprios necessrio para torn-lo mais eficiente a uma organizao especfica. Se observarmos com ateno, possvel perceber que os valores das constantes representam alta influncia nos resultados e, se estas constantes (bem como os valores dos direcionadores e fatores de equilbrio) forem recalibradas, observando projetos da organizao, as estimativas realizadas sero mais acuradas. A descrio detalhada do processo de calibrao do modelo para uma organizao especfica pode ser encontrado em BOEHM et al. (2000).
170
Anexo 3 Notao dos Diagramas de Workflow

Este anexo apresenta a notao utilizada nos diagramas de workflows.
Processo
Evento
Evento dispara ou encerra um processo.
Grupo de Processos Relacionados

Este elemento serve para agrupar processos em categorias de processos.
Ator
Nome
Nome
Nome
Atividade
Atividade Atmica
Atividade Composta
Atividade Externa
Conhecimento Explcito
Conhecimento Tcito
Habilidade
171
Notao utilizada nos Diagramas de Workflow _____________________________________________________________________________________
Software
Repositrio
Documento
Nome
Operaes Lgicas
AND
OR
XOR
AND-Join
AND-Split
OR-Join
XOR-Join
XOR-Split [c1]
[c2]
172
Notao utilizada nos Diagramas de Workflow _____________________________________________________________________________________
Nota Explicativa
Texto
Associao
[c1] P/ Nota Explicativa Fluxo Sada Entrada p/ Evento
173
Anexo 4 Pesquisa de Dependncias Usuais entre as Atividades do Projeto

Este anexo apresenta a pesquisa realizada para definir um conjunto de dependncias usuais entre as atividades do processo de desenvolvimento.
A4. 1 Introduo Como apresentado na definio do processo de gerncia de tempo, no captulo 4, uma das atividade do planejamento do cronograma de um projeto determinar as relaes de dependncia entre as atividades do projeto. Na abordagem proposta por este trabalho, essa atividade ser executada com o apoio de um conjunto de dependncias usuais entre as atividades do projeto que podero ser consultadas pelo gerente do projeto. Para definir esse conjunto de dependncias, uma pesquisa foi realizada. Na seo A4.2 apresentado o planejamento da pesquisa e o formulrio
utilizado na coleta de dados; na seo A4.3 apresentada a anlise dos dados obtidos e na seo 4.4 os resultados da pesquisa.
A4. 2 Planejamento da Pesquisa
Descrio do Problema O processo de gerncia de tempo tem como principal objetivo elaborar e controlar o cronograma do projeto. O primeiro passo para a elaborao do cronograma a determinao das dependncias entre as atividades que compem o processo de desenvolvimento do projeto. Dependncias mal identificadas podem comprometer o desenvolvimento do projeto. Para apoiar o gerente de projetos na determinao das relaes de dependncia entre as atividades do projeto, dados de dependncias usuais so consideravelmente teis (PMBOK, 2000). Este estudo visa caracterizar as relaes de dependncia usuais entre as atividades de um projeto, utilizando como base as atividades do processo de desenvolvimento da NBR ISO/IEC 12207.
174
Pesquisa de Dependncias Usuais entre Atividades do Processo de Desenvolvimento _____________________________________________________________________________________
Objetivo Global Caracterizar as relaes de dependncia entre as atividades do processo de desenvolvimento da NBR ISO/IEC 12207.
Objetivo da Medio Tendo como base uma proposta inicial das dependncias entre as atividades do processo de desenvolvimento da NBR ISO/IEC 12207, caracterizar: 1. As relaes de dependncia entre as atividades. 1.1. Quais so as dependncias que devem ser excludas do conjunto de dependncias inicial. 1.2. Quais so as dependncias que devem ser includas no conjunto de dependncias inicial. importante destacar que o conjunto inicial de dependncias no estar disponvel aos gerentes, procurando evitar, assim, que os mesmos sejam influenciados pelas dependncias presentes no conjunto inicial.
Objetivo do estudo Analisar as atividades do processo de desenvolvimento da NBR ISO/IEC 12207. Com o propsito de caracterizar Com respeito s relaes de dependncia entre as atividades Do ponto de vista de gerentes de projeto No contexto de gerncia de tempo de projetos de software.
Objeto de estudo: Atividades do processo de desenvolvimento da NBR ISO/IEC 12207 Propsito: Caracterizar as relaes de dependncia entre as atividades pertencentes ao conjunto inicial de dependncias. Foco da qualidade: O foco da qualidade est na experincia do gerente de projetos em determinar as relaes de dependncia entre as atividades do processo de desenvolvimento da NBR ISO/IEC 12207. Perspectiva: A perspectiva do gerente de projetos de software
175
Contexto: O estudo ser realizado utilizando gerentes de projeto de software com experincia em gerncia de projetos de software. As atividades da NBR ISO/IEC 12207 sero apresentadas em um questionrio a ser entregue aos participantes do estudo que indicaro as relaes de dependncias entre elas, segundo sua perspectiva.
Questes: Q1: Existem dependncias que devem ser includas no conjunto de dependncias? Mtrica: A lista de dependncias sugeridas pelos gerentes de projeto. Q2: Existem dependncias que devem ser excludas do conjunto de dependncias? Mtrica: A lista de dependncias sugeridas pelos gerentes de projeto.
Definio das Hipteses Hiptese nula (H0 ): O conjunto de dependncias inicial completo, ou seja, no h dependncias a serem retiradas nem includas. Dp conjunto de dependncias inicial Dr dependncias a serem retiradas do conjunto de dependncias inicial Di dependncias a serem includas no conjunto de dependncias inicial H0 : Dr = Di =
Hiptese Alternativa (H1): Existem dependncias a serem retiradas do conjunto de dependncias inicial. H1: Dr
Hiptese Alternativa (H2): Existem dependncias a serem includas no conjunto de dependncias inicial. H2: Di
Seleo do Contexto O estudo ser conduzido de forma off-line, ou seja, o questionrio ser entregue aos participantes e no ser acompanhado. Cada gerente de projeto ter o seu tempo e ambiente para preencher o questionrio, colaborando com o estudo. Os participantes sero profissionais com experincia na rea de gerncia de projetos de software.
176
Seleo dos Indivduos Os indivduos so selecionados baseados em convenincia e disponibilidade, isto , sero selecionados os gerentes de projeto de software que participam de projetos da COPPETEC e/ou de outras empresas e que so conhecidos por sua experincia e atuao na rea de gerncia de projetos de software. Os indivduos selecionados representam uma amostra dos gerentes de projeto de software, mas no so escolhidos de forma aleatria.
Validade
Validade Interna Os participantes do estudo sero selecionados tendo como base sua experincia em gerncia de projetos de software. Assume-se que eles so representativos para a
populao dos gerentes de projeto. Dessa forma, as relaes de dependncia indicadas pelos participantes sero baseadas na experincia pessoal de cada gerente de projeto.
Validade de concluso Hiptese Nula: A verificao da hiptese nula ser feita por meio de simples demonstrao de presena ou no de dependncias na lista de dependncias fornecida pelos gerentes. A incluso ou excluso de dependncias levar em considerao: 1 O nmero de participantes que indicaram que uma dada dependncia deveria ser includa ou excluda; 2 O nvel de experincia do gerente de projeto que indicou que a dependncia deveria ser includa ou excluda.
Validade externa Os participantes so representativos para a populao dos gerentes de projeto de software. A fim de avaliar o nvel de experincia nas reas de gerncia de projetos e o conhecimento da norma NBR ISO/IEC 12207, os dados da caracterizao de indivduos podem ser analisados.
Instrumentao O instrumento de pesquisa utilizado apresentado a seguir.

177
Pesquisa de Dependncias Usuais entre Atividades do Processo de Desenvolvimento ____________________________________________________________________________________________________________________________________________
Descrio da Instrumentao: Relaes de Dependncia entre as atividades do Processo de Desenvolvimento da NBR ISO/IEC 12207
O principal objetivo da gerncia de tempo planejar e controlar o cronograma de um projeto. O primeiro passo desse processo a determinao das dependncias entre as atividades do projeto. Este questionrio visa identificar as dependncias usuais entre as atividades do processo de desenvolvimento de software, baseando-se no conhecimento de gerentes de projetos no que diz respeito s atividades do processo de desenvolvimento da NBR ISO/IEC 12207 - Tecnologia de Informao Processos de ciclo de vida de software. O questionrio faz parte de uma tese de mestrado da COPPE/UFRJ.
Caracterizao do Participante:
e-mail:
Nome:
REA DE ATUAO Empresa Empresrio Gerente de Informtica Gerente da Qualidade Gerente de Projeto Analista de Sistemas Outro: Universidade Professor Pesquisador Consultor Aluno de Doutorado Aluno de Mestrado Aluno de Graduao Desenvolve para: ( ) Uso Prprio ( ) Clientes
SOFTWARE QUE DESENVOLVE Administrao Agropecuria Automao Educacional Entretenimento Ferramenta de Desenvolvimento de Sw Financeiro
Gerenciador de Informaes Gerenciador de Redes Saude Software Grfico Teleinformtica/Telecomunicaes Transportes Outros: ( ) Pacote
Tempo de Atuao na rea: ____ Anos
Nmero de Projetos que j gerenciou: ____
FORMAO
EXPERINCIA EM PROCESSOS DE SOFTWARE Como voc classificaria seu entendimento / experincia em Processos de Software? ) Computao/Informtica ) Computao/Informtica ) Computao/Informtica ) Computao/Informtica ( ) Outro ( ) Outro ( ) Outro ( ) Outro Excelente Alto Mdio Baixo Nenhum
Nvel
Doutorado ( Mestrado ( Especializao ( Graduao (
) Eng de Software ( ) Eng de Software ( ) Eng de Software ( ) Eng de Software (
CONHECIMENTO SOBRE A NBR ISO/IEC 12207
Como voc classificaria seu conhecimento sobre a NBR/ISO IEC 12207- Tecnologia de Informao - Processos de ciclo de vida de software?
Contato: Ana Regina Rocha/Guilherme Horta Travassos / Monalessa Perini Barcellos COPPE/UFRJ Sistemas Caixa Postal 68511 CEP 21945-970 e-mail: darocha@cos.ufrj.br / ght@cos.ufrj.br / mona@cos.ufrj.br
Especialista Conhece Conhece, mas no usa Desconhece
Muito obrigada por sua colaborao ao nosso questionrio
178
INSTRUES
1 - Considere as atividades do processo de desenvolvimento da NBR ISO/IEC 12207 exibidas a seguir. Para cada atividade do processo, identifique com um X suas pr-atividades, ou seja, as atividades que precisam estar concludas para que a atividade em anlise seja executada. Utilize a tabela Comentrios Adicionais caso deseje registrar alguma observao.
Apoio aceitao do Software Instalao do Software Anlise dos Requisitos do Sistema Anlise dos Requisitos do Software Codificao e Testes do Software Integrao do Sistema Integrao do Software Projeto da Arquitetura do Sistema Implementao do processo Projeto da Arquitetura do Software Projeto Detalhado do Software Teste de Qualificao do Sistema Teste de Qualificao do Software
Atividades do Processo de Desenvolvimento da NBR ISO/IEC 12207 -- Tecnologia de Informao - Processos de ciclo de vida de software que devem ser executadas
Anlise dos Requisitos do Sistema: descrio das funes, capacidades, requisitos e restries do sistema.
Anlise dos Requisitos do Software: descrio das funes, capacidades, requisitos e restries de cada item de software do sistema. Apoio aceitao do Software: acompanhamento utilizao do software.
179
Comentrios Adicionais:
180
Conjunto inicial de Dependncias
A seguir apresentado o conjunto inicial de dependncias proposto por este estudo.

Integrao do Sistema Integrao do Software
Projeto da Arquitetura do Sistema
Projeto da Arquitetura do Software
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
Tabela A4.1 Conjunto inicial das dependncias usuais entre as atividades do processo de desenvolvi mento
181
X X
A4.3 Avaliao dos Dados Obtidos Para coletar os dados necessrios definio das dependncias usuais entre as atividades do processo de desenvolvimento de software, objetivo desta pesquisa, o formulrio elaborado como forma de instrumentao foi entregue aos participantes e os dados obtidos foram organizados em uma planilha para serem analisados. A anlise dos dados das caractersticas dos indivduos mostra uma heterogeneidade no que diz respeito experincia em gerncia de projetos de software e em processos de software. A tabela A4.2 apresenta a caracterizao parcial dos
participantes do estudo, exibindo o tempo de atuao na rea, o nmero de projetos gerenciados, a experincia em processos de software e o conhecimento sobre a NBR ISO/IEC 12207 de cada indivduo. A coluna Id descreve o identificador numrico atribudo a cada participante.
Tempo Id de Atuao 1 2 3 4 5 6 7 8 20 20 17 22 5 8 8 3
Nmero de Projetos que j gerenciou 15 30 50 12 2 6 20 4
Experincia em Processos de Software Excelente Excelente Excelente Excelente Mdio Mdio Alto Alto
Conhecimento sobre a NBR ISO/IEC 12207 Especialista Especialista Conhece Conhece Conhece Conhece Conhece, mas no usa Conhece, mas no usa
Tabela A4.2 Caracterizao Parcial dos Participantes do Estudo
Para diferenciar as respostas dos indivduos, ser atribudo um peso a cada um deles, considerando o tempo de atuao na rea, o nmero de projetos gerenciados, a experincia em processos de software e o conhecimento sobre a NBR ISO/IEC 12207. A forma utilizada para distinguir a opinio dos gerentes foi baseada na proposta de FARIAS (2002), acrescentando-se o conhecimento sobre a norma NBR ISO/IEC 12207 do participante. A frmula utilizada para definir o peso atribudo a um participante
P(i ) =
TA(i) NP(i) + + f (i ) + g(i) MedianaTA MedianaNP

183
Onde: P(i) o peso atribudo ao participante i; TA(i) o tempo de atuao na rea do participante i; MedianaTA a mediana do tempo de atuao, considerando o tempo de atuao de cada participante do estudo; NP(i) o nmero de projetos que o participante i j gerenciou; MedianaNP a mediana do nmero de projetos gerenciados, considerando o nmero de projetos gerenciados por cada participante do estudo; f(i) = 0, se a experincia em processos de software do participante i for nenhuma ou baixa; f(i) = 1, se a experincia em processos de software do participante i for mdia; f(i) = 2, se a experincia em processos de software do participante i for alta; f(i)= 3, se a experincia em processos de software do participante i for excelente. g(i) = 0, se a classificao do conhecimento do participante i no que diz respeito norma NBR ISO/IEC 12207 for desconhece; g(i) = 1, se a classificao do conhecimento do participante i no que diz respeito norma NBR ISO/IEC 12207 for conhece, mas no usa; g(i) = 2, se a classificao do conhecimento do participante i no que diz respeito norma NBR ISO/IEC 12207 for conhece; g(i)= 3, se a classificao do conhecimento do participante i no que diz respeito norma NBR ISO/IEC 12207 for especialista;
Analisando os dados da caracterizao dos indivduos (tabela A4.1), pode-se constatar que a mediana do tempo de atuao igual a 12,5 e a mediana do nmero de projetos gerenciados igual a 13,5. Tomando por base esses valores e os dados da tabela A4.2, o peso de cada participante calculado considerando a frmula descrita anteriormente. A tabela A4.3 apresenta o peso atribudo a cada indivduo participante da pesquisa.
184
Id 1 2 3 4 5 6 7 8
Peso 8,71 9,82 10,06 7,65 3,55 4,08 5,12 3,54
Tabela A4.3 Pesos dos participantes do estudo
A figura A4.1 exibe o grfico que descreve, no eixo horizontal, os participantes do estudo, e, no eixo vertical, o peso de cada participante.
12,00 10,00 8,00 Pesos 6,00 4,00 2,00 0,00 1 2 3 4 5 6 7 8 Participantes
Figura A4.1 Grfico Participantes x Pesos
Analisando o grfico possvel perceber dois grandes grupos de participantes: os participantes identificados por 1, 2, 3 e 4 so considerados experientes e tm seus pesos na faixa de 7 a 11. Os participantes 5, 6, 7 e 8 so pouco experientes e tm seus pesos na faixa de 3 a 6. No foram identificados indivduos inexperientes, que
possuiriam seu peso inferior a 3. Para definir o conjunto de dependncias usuais entre as atividades do processo de desenvolvimento de software, as dependncias pertencentes ao conjunto inicial proposto sero verificadas considerando-se o nmero de votos obtidos e o peso atribudo a cada voto. Para concluir se uma dependncia deve ou no pertencer ao
185
conjunto resultante desta pesquisa necessrio estabelecer um ponto de incluso, ou seja, o valor a partir do qual pode-se considerar um elemento como pertencente ao resultado final. Se todos os participantes do estudo identificarem uma determinada dependncia, teremos o valor de votos igual a 52,5413 para essa dependncia. Esse valor representa o valor mximo de votos para uma determinada dependncia da pesquisa. Assim, o ponto de incluso estabelecido em 26,27, que representa 50% do valor mximo de voto para uma determinada dependncia. Aps a definio do ponto de incluso, a anlise e interpretao dos dados obtidos concluda e o conjunto de dependncias usuais final estabelecido levando-se em considerao o peso atribudo a cada participante da pesquisa. A seguir so apresentados os votos para as dependncias de cada atividade do processo de desenvolvimento de software da NBR ISO/IEC 12207, utilizado como base para esta pesquisa. Para melhor visualizar os resultados, representaremos as atividades pela seguinte identificao:
Identificao 1 2 3 4 5 6 7 8 9 10 11 12 13
Atividade Anlise de Requisitos de Sistema Anlise de Requisitos do Software Apoio Aceitao do Software Codificao e Testes do Software Implementao do Processo Instalao do Software Integrao do Sistema Integrao do Software Projeto da Arquitetura do Sistema Projeto da Arquitetura do Software Projeto Detalhado do Software Teste de Qualificao do Sistema Teste de Qualificao do Software
Tabela A4.4 Identificao das Atividades do Processo de Desenvolvimento
186
Para cada atividade, as colunas das dependncias que esto presentes no conjunto inicial proposto sero representadas em cinza. Assim, ficar mais claro observar as diferenas entre as dependncias propostas pelo conjunto inicial e as identificadas pelos participantes. importante lembrar que os participantes no tiveram acesso ao conjunto inicial proposto. A tabela A4.5 apresenta os dados obtidos para as dependncias da atividade Anlise de Requisitos do Sistema.
Id Participante 1 2 3 4 5 6 7 8
3,55
Dependncias 1 2 3 4 5
8,71 9,82 10,06 7,65
10
11
12
13
Tabela A4.5 Dados obtidos para as dependncias da atividade Anlise de Requisitos do Sistema
Analisando os dados apresentados na tabela, podemos observar que a dependncia 5 est presente no conjunto de dependncias usuais, pois recebeu nmero de votos igual a 32,14, que superior ao ponto de incluso. A dependncia 9, apesar de ter sido identificada por um dos participantes, no ser includa no conjunto de dependncias usuais, uma vez que no alcanou o nmero de votos suficiente.
A tabela A4.6 apresenta os dados obtidos para as dependncias da atividade Anlise de Requisitos do Software.
13
Somatrio dos pesos dos participantes: 8,71 + 9,82 + 10,06 + 7,65 + 3,55 + 4,08 + 5,12 + 3,54 = 52,54 187
Id Participante
Dependncias
1
8,71 9,82 10,06 7,65 3,55 4,08
5
8,71 9,82 10,06 7,65 3,55
10
11
12
13
1 2 3 4 5 6 7 8
Software
9,82
7,65
3,54
Tabela A4.6 Dados obtidos para as dependncias da atividade Anlise de Requisitos do
Analisando os dados apresentados na tabela A4.6, observamos que as dependncias 1 e 5 sero includas no conjunto final de dependncias usuais pois alcanaram valor de votos superior ao valor do ponto de incluso. J a dependncia 9, que foi identificada por dois participantes, no ser includa no conjunto final de dependncias usuais, pois alcanou 17,47 votos, o que no suficiente para ser considerada elemento do conjunto final.
A tabela A4.7 apresenta os dados obtidos para as dependncias da atividade Apoio Aceitao do Software
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
6
8,71 9,82
7
8,71 9,82
8
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
8,71 9,82
13
8,71 9,82 10,06 7,65 3,55 4,08
1 2 3 4 5 6 7 8
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 10,06 10,06 10,06 10,06 10,06 10,06 10,06 7,65 3,55 4,08 7,65 3,55 4,08 5,12 3,54 3,54 3,54 3,54 3,54 3,54 3,54 7,65 3,55 4,08 7,65 3,55 4,08 7,65 3,55 4,08 7,65 3,55 4,08 7,65 3,55 4,08 7,65 3,55 4,08 7,65 3,55 4,08
3,54
Tabela A4.7 Dados obtidos para as dependncias da atividade Apoio Aceitao do Software
188
Analisando a tabela A4.7, podemos perceber que as dependncias 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12 e 13 sero includas no conjunto final de dependncias, pois obtiveram valor de votos superior ao valor do ponto de incluso.
A tabela A4.8 apresenta os dados obtidos para as dependncias da atividade Codificao e Testes do Software
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
5
8,71 9,82 10,06 7,65 3,55 4,08
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
13
1 2 3 4 5 6 7 8
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 10,06 7,65 7,65 7,65 3,55 4,08 5,12 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
3,54
Tabela A4.8 Dados obtidos para as dependncias da atividade Codificao e Testes do Software
Observando os dados apresentados na tabela A4.8, notamos que as dependncias 1, 2, 5, 9, 10 e 11 sero includas no conjunto final de dependncias, uma vez que obtiveram valor de votos superior ao valor do ponto de incluso. As dependncias 6 e 8, apesar de terem sido identificadas, no pertencero ao conjunto final pois no alcanaram votos suficientes para tal.
A tabela A4.9 apresenta os dados obtidos para as dependncias da atividade Implementao do Processo
189
Id Participante
Dependncias
10
11
12
13
1 2 3 4 5 6 7 8
4,08 4,08 5,12 5,12 3,54 7,65
Tabela A4.9 Dados obtidos para as dependncias da atividade Implementao do Processo
Para a atividade Implementao do Processo nenhuma dependncia ser includa no conjunto final de dependncias, pois as dependncias identificadas pelos participantes para essa atividade no alcanaram votos suficientes para pertencer ao conjunto final.
A tabela A4.10 apresenta os dados obtidos para as dependncias da atividade Instalao do Software
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
7
8,71 9,82
8
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
8,71 9,82
13
8,71 9,82
1 2 3 4 5 6 7 8
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 5,12 3,54 7,65
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 5,12
10,06 10,06 10,06 10,06 10,06 10,06 10,06 7,65 3,55 4,08 5,12 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 5,12 7,65 3,55 7,65 3,55 4,08 5,12 3,54
Tabela A4.10 Dados obtidos para as dependncias da atividade Instalao do Software
Analisando a tabela A4.10, podemos observar que as dependncias 1, 2, 4, 5, 7, 8, 9, 10, 11, 12, e 13 sero includas no conjunto final de dependncias, uma vez que obtiveram o valor mximo de votos dos participantes.
190
As dependncias 3 e 6, apesar de terem sido identificadas, no pertencero ao conjunto final pois no alcanaram votos suficientes para tal.
A tabela A4.11 apresenta os dados obtidos para as dependncias da atividade Integrao do Sistema
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
8
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
13
1 2 3 4 5 6 7 8
9,82 10,06 7,65 3,55
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 7,65 7,65
10,06 10,06 10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
3,55 3,55 4,08 5,12 3,54 4,08 5,12 3,54
Tabela A4.11 Dados obtidos para as dependncias da atividade Integrao do Sistema
Observando os dados apresentados na tabela A4.11, percebemos que as dependncias 1, 2, 4, 5, 8, 9, 10 e 11 sero includas no conjunto final de dependncias, pois obtiveram o valor mximo de votos dos participantes. A dependncia 13 alcanou 31,08 votos, logo, tambm ser includa conjunto final. A tabela A4.12 apresenta os dados obtidos para as dependncias da atividade Integrao do Software
Id Participante
no
Dependncias
1 1 2 3 4 5 6 7 8
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
13
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
Tabela A4.12 Dados obtidos para as dependncias da atividade Integrao do Software

191
Observando a tabela A4.12, notamos que as dependncias 1, 2, 4, 5, 8, 9, 10 e 11 sero includas no conjunto final de dependncias, uma vez que obtiveram o valor mximo de votos dos participantes.
A tabela A4.13 apresenta os dados obtidos para as dependncias da atividade Projeto da Arquitetura do Sistema
Id Participante
Dependncias
1
8,71 9,82 10,06 7,65 3,55 4,08 5,12 3,54
5
8,71 9,82 10,06
10
11
12
13
1 2 3 4 5 6 7 8
Sistema
7,65
7,65 3,55
4,08
4,08 5,12
3,54
Tabela A4.13 Dados obtidos para as dependncias da atividade Projeto da Arquitetura do
Observando os dados apresentados na tabela A4.13, podemos perceber que as dependncias 1 e 5 sero includas no conjunto final de dependncias, uma vez que obtiveram valor de votos superior ao valor do ponto de incluso. A dependncia 2, apesar de ter sido identificada, no pertencer ao conjunto final pois no alcanou votos suficientes para tal.
A tabela A4.14 apresenta os dados obtidos para as dependncias da atividade Projeto da Arquitetura do Software
192

Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
5
8,71 9,82 10,06 7,65 3,55 4,08
9
8,71 9,82 10,06 7,65 3,55 4,08
10
11
12
13
1 2 3 4 5 6 7 8
Software
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
Tabela A4.14 Dados obtidos para as dependncias da atividade Projeto da Arquitetura do
Analisando a tabela A4.14, percebemos que as dependncias 1, 2, 5 e 9 sero includas no conjunto final de dependncias, uma vez que obtiveram valor de votos superior ao valor do ponto de incluso.
A tabela A4.15 apresenta os dados obtidos para as dependncias da atividade Projeto da Detalhado do Software
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
5
8,71 9,82 10,06 7,65 3,55 4,08
9
8,71 9,82
10
8,71 9,82
11
12
13
1 2 3 4 5 6 7 8
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
10,06 10,06 7,65 3,55 4,08 7,65 3,55 4,08
3,54
Tabela A4.15 Dados obtidos para as dependncias da atividade Projeto da Detalhado do Software
Observando os dados apresentados na tabela A4.15, nota-se que as dependncias 1, 2, 5, 9 e 10 sero includas no conjunto final de dependncias, pois obtiveram valor de votos superior ao valor do ponto de incluso.
193
A tabela A4.16 apresenta os dados obtidos para as dependncias da atividade Teste de Qualificao do Sistema
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
7
8,71 9,82
8
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
13
8,71 9,82 10,06 7,65 3,55 4,08
1 2 3 4 5 6 7 8
Sistema
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65
10,06 10,06 10,06 10,06 10,06 7,65 3,55 4,08 5,12 3,54 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54
3,54
Tabela A4.16 Dados obtidos para as dependncias da atividade Teste de Qualificao do
Observando os dados da tabela A4.16, notamos que as dependncias 1, 2, 4, 5, 7, 8, 9, 10, 11 e 13 sero includas no conjunto final de dependncias, uma vez que obtiveram valor de votos superior ao valor do ponto de incluso. As dependncias 3 e 6, apesar de terem sido identificadas, no pertencero ao conjunto final pois no alcanaram votos suficientes. A tabela A4.17 apresenta os dados obtidos para as dependncias da atividade Teste de Qualificao do Software
Id Participante
Dependncias
1
8,71 9,82
2
8,71 9,82
4
8,71 9,82
5
8,71 9,82
7
8,71
8
8,71 9,82
9
8,71 9,82
10
8,71 9,82
11
8,71 9,82
12
13
1 2 3 4 5 6 7 8
Software
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65
10,06 10,06 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65
10,06 10,06 10,06 10,06 10,06 7,65 3,55 4,08 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 7,65 3,55 4,08 5,12 3,54 5,12
Tabela A4.17 Dados obtidos para as dependncias da atividade Teste de Qualificao do
194
Analisando a tabela A4.17, percebemos que as dependncias 1, 2, 4, 5, 8, 9, 10 e 11 sero includas no conjunto final de dependncias, uma vez que obtiveram o valor mximo de votos dos participantes. As dependncias 3, 6, 7 e 13 apesar de terem sido identificadas, no pertencero ao conjunto final pois no alcanaram votos suficientes para tal.
importante notar que a utilizao dos pesos dos participantes, calculado considerando o tempo de atuao na rea, o nmero de projetos gerenciados, a experincia em processos de software e o conhecimento sobre a NBR ISO/IEC 12207, determinou a incluso ou no de algumas dependncias. Na atividade Anlise de Requisitos do Sistema (tabela A4.5), quatro participantes identificaram a dependncia 5. O mesmo ocorreu para a dependncia 13 da atividade Integrao do Sistema (tabela A4.11). Se tivesse sido utilizado o critrio da maioria (metade dos participantes mais um) para a incluso de uma dependncia, as dependncias 5 e 13, nos casos acima citados, no seriam includas no conjunto final de dependncias. Porm, a considerao dos pesos dos participantes fez com que elas fossem includas no conjunto final, pois a soma dos pesos dos quatro participantes que identificaram as dependncias superou o valor do ponto de incluso.
A4.4 Resultados Obtidos A pesquisa realizada atingiu os objetivos iniciais, uma vez que o conjunto de dependncia usuais das atividades do processo de desenvolvimento foi caracterizado. O conjunto de dependncias final foi verificado avaliando-se as dependncias identificadas pelos participantes que deveriam ser includas ou excludas do conjunto inicial de dependncias. A tabela A4.18 apresenta o conjunto de dependncias resultante da anlise dos dados obtidos. Analisando a tabela A4.18 possvel perceber que o conjunto final de dependncias igual ao conjunto inicialmente proposto, ou seja, nenhuma dependncia foi includa ou excluda segundo o critrio utilizado. Porm, a hiptese nula (H0) foi verificada como falsa, uma vez que existiram dependncias sugeridas para incluso que no estavam presentes no conjunto inicial, bem como existiram dependncias sugeridas para excluso do conjunto inicial de dependncias.
195
Integrao do Sistema Integrao do Software
Projeto da Arquitetura do Sistema Projeto da Arquitetura do Software
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
Tabela 4.18 Conjunto final de dependncias usuais entre as atividades do processo de desenvolvimento.
196
X X
Ao realizar uma anlise das dependncias que foram sugeridas pelos participantes e que no foram includas no conjunto final pois no alcanaram o valor de votos suficiente, possvel perceber que, tanto os participantes do grupo experiente quanto os participantes do grupo pouco experiente identificaram dependncias que no estavam presentes no conjunto inicial. Porm, ao analisar essas dependncias, nota-se que as mesmas no so verdadeiras para um processo de desenvolvimento de software. Outra observao interessante que dos 14 votos do grupo experiente registrados para dependncias que no foram includas, 11 foram realizados pelo participante de menor peso do grupo. A tabela 4.19 apresenta o nmero de dependncias que foram sugeridas, mas no includas, e o nmero de votos de cada grupo.
N de dependncias sugeridas para incluso que no alcanaram valor de votos suficiente
N de votos do grupo experiente
N de votos do grupo pouco experiente
13
grupo
14
13
Tabela A4.19 Relao das dependncias para incluso com o n de votos recebidos de cada
Por outro lado, analisando-se as dependncias que foram sugeridas para excluso do conjunto inicial, ou seja, que no foram identificadas pelos participantes, possvel perceber que a maioria delas recebeu votos para excluso dos participantes do grupo pouco experiente, com raras excees. A tabela 4.20 apresenta o nmero de dependncias que foram sugeridas, mas no includas, e o nmero de votos de cada grupo.
N de dependncias sugeridas para excluso que no alcanaram valor de votos suficiente
N de votos do grupo experiente
N de votos do grupo pouco experiente
24
grupo
37
Tabela A4.20 Relao das dependncias para excluso como n de votos recebidos de cada
Sendo assim, podemos concluir que os participantes mais experientes registraram poucas alteraes para o conjunto inicial de dependncias e que, a maior parte das alteraes foi sugerida pelos participantes menos experientes, sendo estas irreais quando analisadas no contexto do processo de desenvolvimento de software.
197
As caractersticas de alguns dos participantes podem ser consideradas para que seja feita uma anlise do comportamento similar de seus resultados. Por exemplo, os trs participantes do grupo experiente que apresentam maior peso possuem caractersticas que direcionam seus resultados a serem coincidentes, pois so profissionais que tm trabalhado seguindo uma mesma abordagem para processos de software. O participante de menor peso desse grupo, cujos resultados diferenciam-se dos demais, no tem participao ativa nos trabalhos realizados pelos demais elementos do grupo nesse contexto, o que pode justificar a diferena de seus votos em relao aos demais elementos do grupo. No grupo pouco experiente, observa-se que os participantes de identificao 7 e 8 so os que sugerem o maior nmero de alteraes. Analisando a tabela de caracterizao parcial dos participantes (tabela A4.2) notamos que estes so os indivduos com menor conhecimento sobre a norma NBR ISO/IEC 12207, o que pode justificar o nmero de alteraes por eles sugeridas. importante ressaltar que esta pesquisa deve ser repetida, com um nmero maior de participantes e com perfis mais variados. No formulrio que foi entregue aos participantes, um espao foi destinado a comentrios livres. Algumas consideraes foram registradas e devem ser consideradas para a repetio da pesquisa, podendo at mesmo, ser necessrio realizar algumas alteraes para obter melhores resultados, como por exemplo, considerar iteraes do processo e atividades que podem ser executadas em paralelo. A tabela A4.21 apresenta os comentrios apresentados pelos participantes.
Id Participante 1 2 3
Comentrios As atividades relacionadas a sistema so opcionais e podem no existir caso no exista especificao de requisitos do sistema. Na prtica, e a prpria norma prev, essas atividades se sobrepem e so executadas de forma iterativa. Dependendo da complexidade e outras caractersticas do projeto de software, a implementao do processo pode ser refinada aps as fases Anlise dos Requisitos do Sistema e Anlise dos Requisitos do Software. Alm disso, dependendo da metodologia e estratgia de desenvolvimento de software, os testes, a instalao do software e a sua aceitao pode ser realizada diversas vezes ao longo da implementao/integrao de itens de software at culminar com a integrao do sistema.
Tabela A4.21 Comentrios registrados pelos participantes
198
A4.5 Lies Aprendidas Visando melhorar a realizao do estudo das dependncias entre as atividades do processo de desenvolvimento de software, alguns pontos precisam ser revistos, j que foram considerados como limitaes de sua primeira execuo. Os pontos abaixo foram observados a partir de comentrios, sugestes e/ou dvidas dos participantes da pesquisa e podem ser tratados em uma repetio futura da pesquisa.
1. Considerar atividades de outros modelos de processo: Seria interessante realizar a pesquisa considerando as dependncias entre as atividades do processo de desenvolvimento sugerido por outros modelos e normas (CMM e SPICE ISO 15504 por exemplo). Assim, tambm seria possvel realizar um estudo comparativo entre os resultados e propor um conjunto genrico de dependncias usuais, uma vez que esta pesquisa prope um conjunto de dependncias baseado apenas nas atividades da NBR ISO/IEC 12207.
2. Alterar a instrumentao: Alguns participantes sentiram dificuldades em preencher o formulrio, uma vez que este no considera as iteraes de processo e realizao de atividades em paralelo. Sendo assim, seria interessante alterar o formulrio incluindo uma forma de registrar as situaes acima mencionadas.
3. Acompanhar o preenchimento do formulrio:
Segundo o planejamento
realizado, o estudo seria conduzido de forma off-line, ou seja, o questionrio seria entregue aos participantes e o preenchimento do mesmo no seria acompanhado. Porm, dada a proximidade de um dos participantes, este foi acompanhado durante o preenchimento do questionrio. A realizao do acompanhamento mostrou que as contribuies para a pesquisa so maiores, uma vez que eventuais comentrios ou sugestes podem ser registrados durante o preenchimento do formulrio, enriquecendo os resultados. Alm disso, durante o acompanhamento, possvel sanar dvidas do participante que poderiam comprometer a qualidade de suas respostas.
199
A4.6 Consideraes Finais Este anexo apresentou o planejamento, anlise dos resultados obtidos e o resultado da pesquisa de dependncias usuais entre as atividades do processo de desenvolvimento de projetos de software. O objetivo da pesquisa foi caracterizar um conjunto de dependncias usuais entre as atividades do processo de desenvolvimento de projetos de software, baseando-se nas atividades do processo de desenvolvimento da NBR ISO/IEC 12207. Apesar do nmero reduzido de participantes, a pesquisa atingiu seu objetivo inicial considerando-se que os participantes possuem experincia em gerncia de projetos e processos de software. O conjunto de dependncias usuais resultante desta pesquisa estar armazenado no repositrio da organizao para que seja utilizado pelos gerentes de projeto durante o planejamento do cronograma do projeto.
200
Anexo 5 Modelo de Classes
Este anexo apresenta o modelo de classes da Estao TABA com as extenses incorporadas pelo modelo proposto nesta tese. So apresentadas as classes acrescidas para atender ferramenta CustPlan e suas descries.
A5.1 Caraterizao de Projetos A tabela A5.1 apresenta as classes que foram includas no modelo TABA para realizar a caracterizao de projetos.
Classe CriterioCaracterizacao
Descrio Critrios que caracterizam projetos de software na Estao TABA. Conjunto de valores que os critrios podem assumir. Grupos de aplicao aos quais os critrios de caracterizao podem se aplicar. Exemplos so equipe, cliente, gerente. Valor de um critrio especfico considerando um grupo de aplicao especfico em um projeto especfico. Indstrias pertencente classificao padro de indstrias. Um projeto de software destinado a uma indstria especfica. Todas as naturezas possveis de um projeto de software. Todas os possveis escopos de um projeto de software.
ValorDominio GrupoAplicacao
PerfilProjeto
ConhecimentoIndustria
ConhecimentoNatureza ConhecimentoEscopo
Tabela A5.1 Classes para a Caracterizao de Projetos
201
Modelo de Classes _____________________________________________________________________________________
NaturezaProjeto descricao : String
1 Industria ValorDomnio
v alor : String v alorMax : String v alorMin : String descric ao : String
Escopo
descricao : String
1
0..*
0..1
0..*
0..*
Projeto
0..* 0..*
0..* CriterioC aracterizacao
0..*
0..*
Perf ilProjeto v alor : Float
0..*
nome : String descricao : String tipo : Integer

0..*
1 Processo
0..* 0..* 0..*
0..*
1
0..*
1
Conhec imentoParadigma
GrupoAplicacao
nome : String descricao : String
1
ConhecimentoModeloC icloVida
Figura A5.1 Modelo para Caracterizao de Projetos
202
Modelo de Classes _____________________________________________________________________________________
A5.2 Planejamento de Tempo e Custos A tabela A5.2 apresenta as classes que foram includas no modelo TABA para realizar o planejamento de tempo e custos.
Classe CaracteristicaSistema Descrio Armazena as 14 caractersticas de sistema a serem avaliadas na tcnica Anlise de Pontos de Funo. NvelInfluencia Armazena os nveis de influncia de cada caracterstica do sistema. TipoFuncao Elemento ElementoTipoFuncao Armazena as funes da Anlise de Pontos de Funo. Armazena os elementos da Anlise de Pontos de Funo. Armazena a associao entre os elementos e as funes da Anlise de Pontos de Funo. ComplexidadeFuncional Armazena a relao das contagens dos elementos das funes com a complexidade e comtribuio para a Anlise de Pontos de Funo. InflunciaCaracteristicaSistema Armazena a influncia das caractersticas de sistema para o projeto. ValorPontoFuncao Armazena os valores dos parametros da Anlise de Pontos de Funo para o projeto. ModeloCOCOMOII ConstanteCOCOMOII FatorEquilibrio DirecionadorCusto Escala ItemEscala ValorCOCOMO II Modulo Estimativa Armazena os tipo de modelos do COCOMO II. Armazena as constantes utilizadas pelo COCOMO II. Armazena os fatores de equilbrio do COCOMO II. Armazena os direcionadores de custos do COCOMO II. Armazena a escala utilizada pelo COCOMO II. Armazena os itens da escala utilizados pelo COCOMO II. Armazena os valores do COCOMO II para o projeto. Armazena os mdulos do projeto. Armazena as estimativas realizadas para o projeto/mdulo/atividade. Tabela A5.2 Classes para o Planejamento de Custos
203
Modelo de Classes _____________________________________________________________________________________ Classe ParametroEstimativa Descrio Armazena os parmetros de estimativa disponveis no TABA. Exemplos so: custos, esforo e prazo. FormaEstimativa Armazena as formas possveis de estimativas, podendo ser ad hoc, baseada em analogias ou por mtodos. GrupoEstimativa Armazena os grupos de estimativas do cronograma e oramento gerados, identificando-os com um nmero de verso. Receita PrevisaoReceita Despesa DespesaProjeto ValorRecurso Desvio Armazena as receitas (entradas) realizadas para o projeto. Armazena as receitas previstas para o projeto. Armazena as despesas que podem ocorrer em um projeto. Armazena o valor das despesas de um determinado projeto. Armazena o valor dos recursos de um determinado projeto. Armazena os desvios de cronograma e oramento registrados durante o desenvolvimento do projeto. CaminhoCritico MarcoPontoControle ConhecimentoEspecialista Armazena os caminhos crticos do projeto. Armazena os marcos e pontos de controle do projeto. Armazena as dependncias usuais entre as atividades.
Tabela A5.2 Classes para o Planejamento de Custos (continuao)
A5.3 Diagramas de Classes As figuras A5.2 a A5.5 representam o modelo de classes contendo as classes acima descritas. O modelo foi dividido em quatro partes para facilitar o entendimento: A figura A5.2 apresenta as classes que foram criadas para realizar a Anlise de Pontos de Funo. A figura A5.3 apresenta as classes que foram criadas para realizar o COCOMO II. A figura A5.4 apresenta as classes que foram criadas para realizar o planejamento de custos. A figura A5.5 apresenta as classes que foram criadas para realizar o planejamento de tempo.
204
Modelo de Classes ____________________________________________________________________________________________________________________________________________
Modelo CustPlan - FPA

1..* Projeto 0..1
nome : String data : Date GrupoEstimativa
InfluenciaCaracteristicaSistema valorInfluencia : Integer nome : String decricao : String
Modulo 1 0..1
0..*
0..*
nome : string descricao : string uso : string complexidade : string tamanho : string modularidade : string jahInstanciado : bool esforcoEfetivo custoEfetivo tempoEfetivo
0..*
0..1
1 0..*
nome : String descricao : String NivelInfluencia CaracteristicaSistema
ConhecimentoMetodo
1..*
nivel : Integer descricao : String
TipoFuncao 0..*
nome : String descricao : String tipo : Integer
0..*
0..*
0..* ValorPontoFuncao valor : Float data : Date
1..* TipoFuncaoElemento
0..* 1 1 1
1..*
Elemento
nome : String descricao : String 1..* 1..* ComplexidadeFuncional valorMinimo1 : Integer valorMaximo1 : Integer valorMinimo2 : Integer valorMaximo2 : Integer complexidade : Integer contribuicao : Integer descricao : String
Figura A5.2 Modelo de Classes Anlise de Pontos de Funo 205
Linguagem Projeto 0..* Modulo

nome : String data : Date GrupoEstimativ a
nome : String descricao : String SLOCPontoFuncao : Integer
ConhecimentoMetodo
1 0..1 1
0..*
nome : string descricao : string uso : string complexidade : string tamanho : string modularidade : string jahInstanciado : bool esf orcoEf etiv o custoEf etiv o tempoEf etiv o nome : String descricao : String
0..1
0..* ModeloCOCMOII possui DirecionadorCusto nome : String descricao : String
0..* 1
ConstanteCOCOMOII
possui
nome : String valor : Float 0..* 1..* 1..*

1..*
0..* 0..* Escala 0..1

nome : String tipo : TipoEscala
sigla : String nome : String descricao : String
0..1 ItemEscala 0..*

0..* ValorCOCOMOII
1..*
0..*
nome : String descricao : String v alor : f loat
0..*
0..*
0..*
FatorEquilbrio 0..* 0..1
0..1
valor : Float data : Date 0..*
sigla : String nome : String descricao : String
Figura A5.3 Modelo de Classes COCOMO II
206
Receita Modulo 0..*

0..1 + pr-atividade nome : String descricao : float
origem : String valor : float data : Date
0..*
0..1
0..*
0..* 1..* 0..*
1 0..* Atividade
+ sub_atividades
0..*
0..*
Projeto 0..1 0..*

data : Date valor : float registradaPlano : Boolean
PrevisaoReceita
origem : String valor : float data : Date
0..* 0..1
Estimativa 0..* 0..1
nome : String descricao : String numeroIteracao : int dataInicio : Ctime dataFim : Ctime status : String esforcoEfetivo : float custoEfetivo : float tempoEfetivo : float
0..*
0..*
0..*
0..* 0..* 0..* 0..*
1..*
0..*
0..1
0..* GrupoEstimativa ParametroEstimativa nome : String data : Date
1..*
0..*
PlanejamentoRecurso
dataInicio : Date dataFim : Date quantidadeEstimadaRecurso : Integer valorCusto : Float valorUso : float
PlanejamentoRecurso 0..1
nome : String descricao : String unidade : String tipo : Integer
dataInicio : Date dataFim : Date quantidadeEstimadaRecurso : Integer valorCusto : Float valorUso : float
0..1 0..1
0..*
DespesaProjeto
valor : float 0..*
Despesa
0..*
nome : String descricao : String
0..1 0..* 0..*
Desvio
valor : Integer motivo : String data : Date
Figura A5.4 Modelo de Classes Custos 207
ParametroEstimativa nome : String data : Date
GrupoEstimativa
FormaEstimativa
descricao : String historico : Boolean
1 0..* 1..* Desvio

+pr-atividade valor : Integer motivo : String data : Date tipo : Integer
nome : String descricao : String unidade : String tipo : Integer
0..*
1 0..*
0..*
Estimativa 1..* Atividade 0..* 0..* 1..*

+sub_atividades
0..* 0..* 0..* 0..1 1

CaminhoCritico
Projeto
data : Date valor : float registradaPlano : Boolean
0..*
0..1 ConhecimentoMetodo
0..1
0..1
nome : String descricao : String numeroIteracao : int dataInicio : Ctime dataFim : Ctime status : String esforcoEfetivo : float custoEfetivo : float tempoEfetivo : float
0..*
nome : String descricao : String cor : Int
Modulo
nome : String descricao : float
0..* 0..1 0..1 1

MarcoPontoControle 0..*
1 1
0..*
1..*
0..1
1
ConhecimentoAtividade
0..*
descrio : String Tipo : Integer data : Date
0..*
0..* DependenciaEspecialistas
Figura A5.5 Modelo de Classes Tempo
208

Planejamento de Custos Desenvolvimento Softwares

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Planejamento de Custos Desenvolvimento Softwares

Încărcat de

Drepturi de autor:

Formate disponibile

PLANEJAMENTO DE CUSTOS EM AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE ORIENTADOS ORGANIZAO

Monalessa Perini Barcellos

________________________________________________ Profa. Ana Regina Cavalcanti da Rocha, D. Sc.

________________________________________________ Prof. Guilherme Horta Travassos, D. Sc.

________________________________________________ Profa. Kthia Maral de Oliveira, D. Sc.

________________________________________________ Prof. Ricardo de Almeida Falbo, D. Sc.

RIO DE JANEIRO, RJ-BRASIL JUNHO DE 2003

Orientadores: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos

COSTS PLANNING IN ENTERPRISE-ORIENTED SOFTWARE DEVELOPMENT ENVIROMENT

Monalessa Perini Barcellos

Advisors: Ana Regina Cavalcanti da Rocha Guilherme Horta Travassos

2. Planejamento de Projetos e Estimativas de Custos ........................................................ 5

3. Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA ........................................................................................................................................ 31

4. Planejamento de Custos em Ambientes de Desenvolvimento de Software Orientados Organizao ..................................................................................................... 46

5. A Ferramenta CustPlan .................................................................................................... 71

6. Consideraes Finais e Perspectivas Futuras ..............................................................111

Anexo 2 - Realizao de Estimativas utilizando COCOMOII.......................................145

Anexo 5 - Modelo de Classes ...............................................................................................201

Dados quantitativos que caracterizam o ponto de partida de um projeto (JONES, 2000).

Captulo 2 Planejamento de Projetos e Estimativas de Custos

relacionados, cronograma, qualidade do produto e do processo, documentao e riscos envolvidos.

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.2.1 Modelos Paramtricos

Essas tcnicas sero descritas na seo 2.3.

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.2.2 Estimativas baseadas em Analogias

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.2.2.1 A Base de Dados Histricos

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.2.3 Julgamento de Especialistas

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.2.4 Outras Questes sobre a Realizao de Estimativas

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.3.1 A Tcnica Anlise de Pontos de Funo

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

2.3.2 O Modelo COCOMO II

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Planejamento de Projetos e Estimativas de Custos _______________________________________________________________________________________

Captulo 3 Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

3.2.1 Gerncia do Conhecimento em Engenharia de Software

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

Ambientes de Desenvolvimento de Software Orientados Organizao e a Estao TABA _______________________________________________________________________________________

3.2.3 Memria Organizacional