Planejamento de Tempo e Custos em Ambientes deDesenvolvimento de Software Orientados à Organização

Monalessa Perini Barcellos1,2 , Sávio Mendes de Figueiredo1, Ana Regina Rocha1,Guilherme Travassos1

1Universidade Federal do Rio de Janeiro – COPPE/SistemasCaixa Postal 68511 – CEP 21941-972 – Rio de Janeiro, RJ - Brasil

2 Faculdade Vitoriana de Ensino SuperiorVitória, ES – Brasil

{mona, savio, darocha, ght}@cos.ufrj.br

Abstract: Delivering a quality software product with expected cost and on time istoday a great challenge for the organizations. In the last decades a lot ofresearches have been accomplished aiming the development of cost estimationmodels to produce estimations near by projects’ real cost. KnowledgeManagement concepts using have been efficient to support cost planning. Thispaper describes an approach for projects Cost Planning used by an Enterprise-Oriented Software Development Environment. The approach is based oninternational standards, in concepts of Knowledge Management and parametricmodels COCOMO II and Function Point Analysis. A tool (CustPlan) developed tosupport such approach is also presented.

Resumo: Entregar um produto com qualidade, dentro do prazo e custos esperadosé hoje um grande desafio para as organizações. Nas últimas décadas, muitaspesquisas têm sido realizadas no sentido de desenvolver modelos para estimarprazos e custos que resultem em estimativas acuradas. A utilização dos conceitose práticas de gerência do conhecimento tem se mostrado eficiente no apoio aoplanejamento de tempo e custos de projetos. Este artigo apresenta umaabordagem para o planejamento de tempo e custos de projetos de software,baseada em normas e padrões internacionais, nos princípios da gerência doconhecimento e nos modelos paramétricos COCOMO II e Análise de Pontos deFunção. A ferramenta CustPlan, desenvolvida para apoiar a abordagem descrita,também é apresentada.

1. Introdução

As ferramentas e técnicas utilizadas no desenvolvimento de novas aplicações desoftware não têm sido suficientes para garantir o sucesso dos projetos. Problemassignificativos ainda têm sido relatados. Observa-se, por exemplo, não aderência abaselines1, não cumprimento de orçamentos, realização de estimativas incorretas ouincoerentes e um número praticamente inaceitável de projetos cancelados, estagnados ouque não tenham atendido às expectativas dos clientes.

Tendo a modernidade tecnológica garantido a evolução dos recursos de apoio aodesenvolvimento de sistemas, como explicar tal fato? Talvez não seja tão difícil revelar eperceber que tal fato se dá pois muitos praticantes utilizam a tecnologia disponível, maspouco conhecem os processos que ela apóia. Com isso, dificilmente seriam capazes deexecutar os processos sem a tecnologia de apoio, pois apenas utilizam o processo datecnologia em si e não o processo genérico no qual a tecnologia se baseou para ser capaz deprover apoio automatizado (MURCH, 2000). Esse fato pode contribuir com os problemasanteriormente citados.

Para os executivos de negócio, o número de projetos sem sucesso é um dos pontosmais frustrantes do desenvolvimento de software, pois resulta em oportunidades perdidas einsatisfação de clientes. Assim sendo, além de outros fatores de qualidade, é importante queum produto de software seja desenvolvido com os recursos e cronograma previstos. Osucesso de um projeto depende muito da habilidade do gerente em estimar seus custos eprazos no início de seu desenvolvimento e controlá-los ao longo do processo dedesenvolvimento.

Quando o tema em pauta são os prazos e custos do projeto, a definição e utilizaçãode bons processos para sua gerência é de grande importância. O objetivo de processos paragerência de prazos e custos é fornecer diretrizes que devem ser seguidas para a realizaçãodas estimativas de um projeto e, com seu desenvolvimento, direcionar as atividades deacompanhamento e controle, de forma a auxiliar na proximidade entre os valores estimadose os reais.

Sendo assim, a utilização de processos para gerência de prazos e custos bemdefinidos pode auxiliar na realização de estimativas com menor margem de erro, indicarcaminhos de acompanhamento e controle e, dessa forma, tornar menos frequentes emenores os desvios dos projetos, favorecendo o sucesso de um maior número de projetosde software.

Porém, apenas concluir um projeto no cronograma e orçamento previstos não maisindica ser este um projeto de sucesso. É necessário “agregar valor” à organização. Essevalor pode ser representado pelo conhecimento adquirido pela organização nodesenvolvimento do projeto. Para trabalhar com a captura e utilização de conhecimentodevem ser utilizados os conceitos e práticas da gerência do conhecimento.

A gerência do conhecimento tem sido reconhecida pelas organizações em geralcomo um importante fator de sucesso, uma vez que as constantes mudanças de mercado,tecnológicas e sociais exigem rápidas tomadas de decisão e atualizações em procedimentos,métodos e até estruturas organizacionais (O’LEARY e STUDER, 2001; ABECKER et al.,2001). A gerência do conhecimento trata a descoberta, aquisição, criação, disseminação eutilização de conhecimento, contribuindo para o constante aprendizado organizacional. 1 Dados quantitativos que caracterizam o ponto de partida de um projeto (JONES, 2000).

O crescente interesse pela gerência do conhecimento chegou recentemente àindústria de software e alguns pesquisadores têm trabalhado com a aplicação de seusconceitos em organizações que desenvolvem e mantêm software (MARKKULA, 1999;VILLELA et al., 2001; MENDONÇA et al., 2001; WANGENHEIM et al., 2001; RUS eLINDVALL, 2002). O conhecimento para gerência de prazos e custos de projetos desoftware é um exemplo de conhecimento presente nessas organizações. Durante oplanejamento de um projeto de software é realizado o planejamento do tempo e dos custosdo projeto, onde esforço, prazo e custos propriamente ditos são planejados. Quanto maior aexperiência e conhecimento do gerente do projeto, maior será sua capacidade de realizarum bom planejamento de custos.

A Estação Taba, um projeto desenvolvido pela COPPE/UFRJ, é um meta-ambientecapaz de gerar, através de instanciação, ambientes de desenvolvimento de software (ADS)adequados às particularidades de processos de desenvolvimento e de projetos específicos.Para introduzir os conceitos e práticas da gerência do conhecimento na Estação Taba foramcriados os Ambientes de Desenvolvimento de Software Orientados à Organização(ADSOrg). Esses ambientes se propõem a apoiar as atividades de Engenharia de Software,possibilitando a gerência do conhecimento que pode ser útil aos engenheiros de software aolongo dos projetos de uma organização (VILLELA et al., 2000). Assim, o conhecimento degerência de prazos e custos adquirido em projetos da organização é uma das áreas deconhecimento que deve ser gerenciada por esses ambientes. O trabalho descrito neste artigoestá inserido nesse contexto.

A seção 2 deste artigo apresenta as definições dos principais modelos utilizadospara realizar as estimativas de prazo e custos em projetos de software. A seção 3 apresentaos principais conceitos da gerência do conhecimento. A seção 4 apresenta a Estação Taba eo ADSOrg. Na seção 5 são descritos os processos definidos para a gerência de tempo egerência de custos de projetos de software, baseados nos modelos apresentados na seção 2 enos conceitos de gerência do conhecimento apresentados na seção 3. Na seção 6 éapresentada a ferramenta CustPlan, implementada no ADSOrg da Estação Taba(apresentado na seção 4), para apoiar os processos descritos na seção 5. Na seção 7 sãorealizadas as considerações finais.

2. Modelos para Realização de Estimativas de Prazos e Custos de Projetos

Nas últimas duas décadas, muitos estudos têm sido realizados na área de estimativasde prazos e custos para projetos de software, disponibilizando uma diversidade de técnicaspara a realização dessas estimativas. Essas técnicas, de acordo com suas características,podem ser agrupadas em três tipos de modelos: (i) modelos paramétricos; (ii) estimativasbaseadas em analogias; e, (iii) julgamento de especialistas.

(i) Modelos Paramétricos

Os modelos paramétricos utilizam características do projeto em modelosmatemáticos e/ou algoritmos para calcular as estimativas do projeto. Alguns dessesmodelos, já considerados clássicos como o COCOMO II (evolução do COCOMO 81)(BOEHM et al., 2000) e a Análise de Pontos de Função (GARMUS e HERRON, 2001) têm

sua aplicabilidade constatada em experiências e práticas de muitas organizações,registradas em artigos e outras publicações.

Outros exemplos de modelos paramétricos são: MARK II PF, Full Function Point,Bispoke (RUNESON et al., 2000), Regressão OLS, Stepwise, ANOVA, CART, RegressãoRobusta (JEFFERY et al., 2000) e TCE (YAMAURA e KIKUNO,1999).

Nos anos 80, modelos paramétricos foram utilizados e comparados em conjuntos dedados de projetos de diversos tamanhos e ambientes. Algumas das principais conclusõesforam que esses modelos geravam resultados fracos quando aplicados sem calibração emoutros ambientes. Kemerer (BRIAND et al., 1999), por exemplo, usou 15 projetos deaplicações para negócios e comparou quatro modelos: SLIM (BOEHM, 1981), COCOMO(BOEHM, 1981), Estimacs (PUTNAM, 1978) e Análise de Pontos de Função (GARMUSe HERRON, 2001). A margem de erro encontrada foi consideravelmente alta (85%), o quelevou à reavaliação das técnicas testadas, surgimento de novas técnicas e desenvolvimentode procedimentos de calibração para os modelos paramétricos, permitindo que cadaorganização possa utilizar valores diferentes para as constantes e outros parâmetros dosmodelos, adquirindo-os através da análise de dados e projetos da própria organização, oque diminuiu consideravelmente a margem de erro das estimativas realizadas pelosmodelos paramétricos. O COCOMO II (BOEHM et al., 2000) é um bom exemplo demodelo que permite calibração para cada organização em particular.

Nos anos 90, os estudos também envolveram modelos não paramétricos, baseadosem algoritmos inteligentes e analogias, que são descritos a seguir.

(ii) Estimativas Baseadas em Analogias

As estimativas baseadas em analogias são métodos não paramétricos que utilizamdados históricos de outros projetos para realizar as estimativas para o projeto corrente. Asanalogias são realizadas levando-se em consideração características comuns aos projetos.São, frequentemente, utilizadas nas estimativas de custos totais do projeto quando existeuma quantidade limitada de informações detalhadas sobre ele, como por exemplo nas fasesiniciais. Também são utilizadas para apoiar a distribuição do tempo e custos totais doprojeto em suas fases, módulos e/ou atividades (PMBOK, 2000).

Para realizar as estimativas utilizando analogias, é preciso que exista uma base dedados históricos que possa ser acessada para fornecer os dados dos projetos anteriores queserão utilizados como pontos de apoio para as estimativas dos novos projetos.

Muitas pesquisas mostraram que a realização de estimativas baseadas em analogiasproduz valores satisfatórios, desde que a base de dados históricos possua projetos similaresao projeto que está sendo estimado, que os critérios de determinação da similaridade entreprojetos sejam bem definidos e que o algoritmo de busca por projetos similares sejaeficiente.

Os bons resultados obtidos nos estudos de analogia de estimativas não vêmdesacreditar os modelos paramétricos. Alguns dos estudos desenvolvidos associarammétodos paramétricos e analogias, obtendo resultados que levaram à conclusão de que umaassociação desses dois tipos de modelos seria capaz de fornecer estimativas com umamargem de erro aceitável, ou seja, em torno de 20%.

(iii) Julgamento de Especialistas

Existem organizações que não possuem uma base de dados históricos, o que asimpede de realizar as estimativas dos projetos baseadas em analogias. Da mesma forma,existem aquelas onde não há experiência ou conhecimento para utilizar, de forma eficaz,algum modelo paramétrico de estimativas. Para realizar estimativas em organizações que seapresentem nessa situação, existe um outro tipo de modelo chamado de opinião deespecialistas, julgamento de especialistas ou utilização de experiência pessoal, e consiste noato dos gerentes de projetos estimarem os valores para os projetos baseando-se em suaspróprias experiências passadas. Alguns autores afirmam que essa ainda é a forma maiscomumente utilizada pelas organizações e destacam que ela não é capaz de produzir dadoshistóricos formais e, tipicamente, não apresenta regras para sua abordagem, além de nãopermitir calibrações para melhorar as estimativas mal realizadas, uma vez que não hápadrão para sua realização.

Apesar das desvantagens dessa abordagem, muitas vezes, a utilização daexperiência pessoal pode ser o caminho disponível para uma organização realizar asestimativas de seu primeiro projeto e iniciar, assim, a alimentação de uma base de dadoshistóricos que possa ser utilizada nos projetos subsequentes. Além disso, alguns estudosmostraram que os valores de estimativas gerados por essa abordagem crescem emeficiência de maneira diretamente proporcional à experiência do gerente em estimarprojetos de software.

Há, ainda, uma outra situação onde a opinião de um especialista é necessária e temcaráter de julgamento e decisão. Nela, o gerente do projeto utiliza sua experiência paradecidir os valores das estimativas quando técnicas diferentes apresentam valores diferentespara as mesmas variáveis do projeto (prazo, custos e esforço) ou para ajustar os valores dasestimativas propostos pelas técnicas.

GRAY et al. (1999) realizaram estudos para analisar a realização de estimativasatravés da opinião de especialistas. Em um estudo de caso comparativo entre Análise dePontos de Função, COCOMO e julgamento de especialistas os autores puderam observarque as estimativas realizadas pelos especialistas superavam as demais em acurácia econsistência. Nesse estudo de caso, os autores também puderam perceber que a maioria dasempresas envolvidas no estudo utilizavam o julgamento de especialistas, mesmo quandoutilizavam outros modelos. Ao fim do estudo, concluíram que uma associação formal dosmétodos paramétricos e estimativas por analogias com o julgamento de especialistas écapaz de produzir estimativas satisfatórias, pois o julgamento de especialistas teria a funçãode calibrar os valores apresentados pelos projetos similares. Os autores ressaltam que,mesmo com os resultados positivos, os riscos desse método não podem deixar de serconsiderados.

Analisando os resultados das pesquisas das duas últimas décadas, é possívelobservar que utilizar os três tipos de modelos de estimativas é um bom caminho para obterestimativas acuradas, uma vez que os pontos fracos de um modelo podem ser minimizadospelos outros modelos. BIELAK (2000), por exemplo, retrata um caso de sucesso dautilização combinada dos três modelos em um projeto para os geocientistas doDepartamento de Serviços técnicos e Exploração da Pesquisa, da empresa Arco, atuante nosetor petrolífero.

3. Gerência do Conhecimento

O trabalho descrito neste artigo, conforme mencionado inicialmente, adota agerência do conhecimento como um de seus fundamentos básicos. Esta seção apresenta,assim, os principais conceitos da gerência do conhecimento, relevantes para o trabalho aquiapresentado.

As organizações defrontam-se com ambientes cada vez mais competitivos.Constantemente, surge necessidade de redução de custos, de aumento de valor de mercadoe de reestruturações organizacionais que, normalmente, resultam em demissões econsequentes perdas de informações críticas para as organizações. Segundo O’LEARY(1998) e O’LEARY e STUDER (2001), esses são os principais fatores que levaram asorganizações a reconhecerem o valor estratégico do conhecimento. No caso específico deorganizações cujo negócio é o desenvolvimento de software, segundo WEI et al. (2002),pode ser acrescentado a esse conjunto de fatores a falta de qualidade com que, muitasvezes, é conduzida a atividade de levantamento de requisitos e a alta volatilidade dasplataformas de hardware e software. Esses são os principais fatores que levaram asorganizações a se interessarem pela gerência do conhecimento.

A gerência do conhecimento é uma prática formal de organizar, armazenar efacilitar o acesso e reutilização do conhecimento organizacional, através do uso dosavanços da tecnologia da informação (O’LEARY 1998). É a administração, de formasistemática e ativa, dos recursos de conhecimento de uma organização, utilizandotecnologia apropriada e visando fornecer benefícios estratégicos à organização, o queenvolve a obtenção de conhecimento relevante a partir de fontes internas e/ou externasdisponíveis para a organização, disponibilização e distribuição do conhecimento obtido deforma adequada às necessidades dos usuários, geração de novos conhecimentos eeliminação de conhecimento defasado (VILLELA et al., 2000).

A gerência do conhecimento contribui para o aprendizado individual,organizacional e de equipe, dando suporte à disseminação da informação e à inovaçãodentro da organização. Isso é muito importante, uma vez que, para que a vantagemcompetitiva agregada pelo conhecimento seja de fato sustentável, esse conhecimento nãopode estar no nível do indivíduo, e sim no nível organizacional (DIENG, 2000).

RAMASUBRAMANIAN e JAGADEESAN (2002) ressaltam que é importanteobservar que a utilização da gerência do conhecimento em organizações de software trazbenefícios mais imediatos aos projetos de desenvolvimento de software em particular doque à organização como um todo. Os benefícios alcançados através de uma gerência doconhecimento eficaz em um projeto específico incluem a possibilidade de fornecerrespostas rápidas às necessidades dos clientes e o aumento da produtividade da equipecomo um todo.

Segundo DIENG (2000), a gerência do conhecimento busca atingir os seguintesobjetivos: (i) transformar o conhecimento individual em coletivo; (ii) dar suporte aoaprendizado e integração de um novo membro em uma organização; (iii) disseminarmelhores práticas; (iv) melhorar os processos corporativos de trabalho, a qualidade e aprodutividade dos produtos desenvolvidos; e, (v) reduzir tempo de entrega de produtos. Nocontexto específico da Engenharia de Software, a gerência do conhecimento visa apoiar oaperfeiçoamento constante das atividades realizadas ao longo do processo de

desenvolvimento de software, apoiando a criação e transferência de conhecimentosespecificamente relacionados a esse contexto na organização (SEPPÃNEN et al., 2002).

É importante observar que a gerência do conhecimento não é simplesmente umproblema de montar grupos e equipes de aprendizado ou instalar um sistema de gerência dedocumentos eletrônicos para disseminar as informações. Ao invés disso, é umdeslocamento do paradigma de gerência, que envolve pessoas e outros recursos tais comoestrutura organizacional, cultura, tecnologia da informação e outros (LEE et al., 2001).

3.1 Gerência do Conhecimento em Engenharia de Software

O desenvolvimento de software é uma área que envolve muitas pessoas em fases eatividades diferentes e que sofre modificações em um espaço de tempo consideravelmentepequeno. A disponibilidade dos recursos, normalmente, não cresce proporcionalmente aocrescimento das necessidades e não diminuir a produtividade é uma necessidade. Oconhecimento em Engenharia de Software é muito extenso e aumenta cada vez mais. Asorganizações têm problemas para identificar o conteúdo, a localização e o uso doconhecimento. Uma melhoria no uso desse conhecimento é a motivação básica que guia agerência do conhecimento em Engenharia de Software.

Além da motivação básica, RUS e LINDVALL (2002) citam algumas necessidadesque também motivam a utilização da gerência do conhecimento em Engenharia deSoftware: (i) diminuição do tempo e custo de desenvolvimento e aumento da qualidade; (ii)melhoria no processo de tomada de decisões; (iii) aquisição de conhecimento sobre novastecnologias; (iv) aquisição de conhecimento sobre novos domínios; (v) compartilhamentodo conhecimento sobre a política, práticas e cultura organizacionais; (vi) conhecimentosobre ‘quem sabe o quê’ na organização; e, (vii) compartilhamento do conhecimentoadquirido no desenvolvimento de software.

A gerência do conhecimento tem diversas abordagens na Engenharia de Software,entre elas o apoio às atividades do planejamento de projetos (RUS e LINDVALL, 2002).Para o planejamento dos custos e cronograma de projetos, tema do trabalho aquiapresentado, a utilização do conhecimento organizacional é muito importante na realizaçãodas estimativas, podendo ser utilizados modelos analíticos que analisam dados quantitativosde projetos anteriores e propõem estimativas para o projeto corrente. As atividades deacompanhamento do projeto, tais como a comparação entre as estimativas de custo, esforçoe cronograma propostos e os valores atuais do projeto, criam o conhecimento do projetoparticular. Seus resultados são úteis para o próprio projeto e podem, também, ser base paraa criação do conhecimento organizacional de projetos e para o aprendizado, podendo serarmazenados em repositórios e bases de experiências. Utilizando o conhecimentoorganizacional, os gerentes de projeto podem também estimar os defeitos, confiabilidade eoutros parâmetros do projeto e do produto.

4. A Estação Taba e os Ambientes de Desenvolvimento de Software Orientadosà Organização

A Estação Taba, conforme originalmente proposto, é um meta-ambiente capaz degerar, através de instanciação, ambientes de desenvolvimento de software (ADS)adequados às particularidades de processos de desenvolvimento e de projetos específicos.

Um meta-ambiente pode ser definido como um ambiente que abriga um conjunto deprogramas que interage com usuários para definir interfaces, selecionar ferramentas eestabelecer os tipos de objetos que irão compor o ambiente de desenvolvimento específico(ROCHA et al., 1990).

O projeto Taba teve início em 1990, a partir da constatação de que domínios deaplicação diferentes possuem características distintas, e que estas devem incidir nosambientes de desenvolvimento através dos quais os engenheiros de software desenvolvemaplicações. Sendo assim, a Estação Taba tem por objetivo auxiliar na definição,implementação e execução de ADS adequados a contextos específicos.

Considerando que os objetivos iniciais do projeto, os quais apontavam que asparticularidades de domínios de aplicação também devem ser consideradas na instanciaçãode um ADS para que este ofereça ferramentas mais específicas e possibilite a reutilizaçãodo conhecimento do domínio, OLIVEIRA (1999) estendeu a definição da Estação Taba deforma que esta possa instanciar ADS orientados a domínios específicos, criando osAmbientes de Desenvolvimento de Software Orientados a Domínio (ADSOD), através dainclusão do conhecimento de domínio e sua disponibilização para a realização das diversasatividades do desenvolvimento de software.

Em uma nova evolução, para implementar a gerência do conhecimento na EstaçãoTaba, foram criados os Ambientes de Desenvolvimento de Software Orientados àOrganização (ADSOrg).

ADSOrg representam uma evolução dos Ambientes de Desenvolvimento deSoftware Orientados a Domínio (ADSOD) e visam apoiar o gerenciamento completo doconhecimento requerido em uma atividade de Engenharia de Software, evitando que esseconhecimento fique disperso ao longo da estrutura organizacional e, consequentemente,sujeito a dificuldades de acesso e, até mesmo, a perdas (VILLELA et al., 2000).

A evolução do conceito de ADSOD para ADSOrg foi realizada a partir de duasconstatações: (i) duas ou mais organizações podem desenvolver software para um mesmodomínio com processos, interesses e características muito distintas; e, (ii) o conhecimentodo domínio não é o único conhecimento importante para apoiar desenvolvedores e demaisenvolvidos no processo de software em suas atividades. Outros conhecimentos, tais como oconhecimento relativo às diretrizes e melhores práticas organizacionais e às liçõesaprendidas em experiências anteriores com o uso de processos, métodos e técnicas desoftware, também são extremamente importantes e úteis para os desenvolvedores e demaisenvolvidos.

Um ADSOrg tem os seguintes objetivos: (i) permitir que desenvolvedores edemais envolvidos no desenvolvimento de software tenham acesso a todo conhecimentoacumulado pela organização e relevante ao contexto de desenvolvimento e manutenção desoftware; (ii) promover o aprendizado organizacional nesse contexto (VILLELA et al.,2000; VILLELA et al., 2001).

Um ADSOrg torna possível a identificação de erros cometidos em projetosanteriores e a reutilização de soluções pré-qualificadas durante a realização de tarefassimilares ou idênticas, visando a melhoria da produtividade e qualidade, bem como aredução dos custos do software (VILLELA et al., 2000).

Os requisitos de um ADSOrg são: (i) possuir a representação da estrutura e dosprocessos organizacionais e possibilitar a fácil localização de especialistas cujoconhecimento e experiência podem ser úteis em projetos de software; (ii) armazenarconhecimento especializado sobre desenvolvimento e manutenção de software e fornecer

esse conhecimento para as equipes de projeto quando necessário; e, (iii) apoiar a contínuaevolução do conhecimento armazenado no ambiente.

4.1 Planejamento de Projetos em ADSOrg

Para apoiar a atividade de planejamento de projetos no ADSOrg, algumasferramentas foram desenvolvidas e outras encontram-se em desenvolvimento, no contextodo ADSOrg.

Uma delas, RiscPlan, apóia o planejamento de riscos baseado na reutilização doconhecimento organizacional de riscos, considerando as características do projeto e aexperiência da organização em projetos anteriores (FARIAS, 2002). O objetivo dessaferramenta é dar suporte automatizado ao planejamento de riscos em projetos de software,oferecendo aos gerentes de projeto o conhecimento e experiências acumulados pordiferentes gerentes em projetos similares ocorridos dentro da própria organização.

Outra ferramenta, RHPlan, apóia as atividades de definição de perfis decompetência, seleção de profissionais, monitoração da alocação e avaliação de recursoshumanos necessárias ao processo de alocação de recursos humanos de um projeto(SCHNAIDER, 2003). O objetivo dessa ferramenta é dar suporte automatizado aoplanejamento de recursos humanos em projetos de software, permitindo a utilização doconhecimento organizacional de competências.

A ferramenta CustPlan, que será apresentada na seção 6 deste artigo, auxilia oplanejamento de custos e prazos em ADSOrg, considerando as características do projeto, aexperiência da organização em projetos anteriores e métodos paramétricos de realização deestimativas. O objetivo dessa ferramenta é dar suporte automatizado ao planejamento decustos e prazos em projetos de software, oferecendo aos gerentes de projeto oconhecimento e experiências acumulados por diferentes gerentes em projetos similaresocorridos dentro da própria organização.

A ferramenta CustPlan está inserida no contexto do ADSOrg e, assim, deve atender aseus requisitos. Dessa forma, o requisito (ii) que designa “fornecer conhecimento para asequipes de projeto” e o requisito (iii) que designa “apoiar a contínua evolução doconhecimento armazenado no ambiente” são parcialmente atendidos no que diz respeito aoconhecimento necessário para a realização das atividades dos processos de gerência detempo e custos, uma vez que, durante o planejamento de tempo e custos de um projeto serápossível a reutilização do conhecimento adquirido ao longo de projetos anteriores earmazenado na memória organizacional.

A utilização das ferramentas descritas acima fornece o Plano de Riscos, o Plano deAlocação de Recursos Humanos, o Plano de Custos e o Cronograma do projeto. Essesplanos são componentes do Plano do Projeto que é utilizado na gerência do projeto.

5. Processos de Gerência de Tempo e Gerência de Custos: Uma AbordagemProposta

Os processos de gerência de tempo e gerência de custos possuem um conjunto deatividades maior que o necessário ao planejamento de tempo e custos de um projeto de

software, uma vez que abrangem também as atividades relacionadas ao acompanhamento econtrole do tempo e custos ao longo do processo de desenvolvimento.

Os processos apresentados a seguir foram definidos tendo como base a literatura degerência de tempo e custos, as recomendações da norma NBR ISO 10006 (2000), quedefine diretrizes para a qualidade no gerenciamento de projetos, o relatório técnico 16326da ISO/IEC (1999), que provê um guia para a aplicação da norma ISO/IEC 12207 (1995) àgerência de projetos de software, e o PMBOK (Project Management Body of Knowledge -2000), o padrão para gerência de projetos publicado pelo PMI (Project ManagementInstitute).

A norma NBR ISO 10006 (2000) recomenda que sejam utilizados, em todas asatividades do processo, a experiência e dados históricos provenientes de projetos anteriores.Dessa forma, os processos aqui descritos buscam a reutilização do conhecimento eexperiência organizacionais, um dos benefícios visados pela gerência do conhecimento.

Algumas observações importantes devem ser destacadas a respeito dos processosaqui definidos:

1. Os processos podem ser adaptados à realidade de uma organização específica,considerando os documentos a serem gerados, realização de sub-atividades epossíveis limitações ou restrições impostas;

2. Os processos compõem uma proposta de abordagem, o que não significa ser aúnica aplicável a uma organização; e

3. Há uma interação dos processos de gerência de tempo, gerência de custos eprocesso de alocação de recursos. Na abordagem aqui apresentada, a gerênciade tempo propõe o cronograma do projeto. Posteriormente, os recursos sãoalocados às atividades do cronograma e, em seguida, os custos do projeto sãocalculados. O processo de alocação de recursos não é tratado nessa abordagem.

5.1 Processo de Gerência de Tempo

A gerência de tempo tem como objetivo elaborar e controlar o cronograma doprojeto.

Esse processo deve ser utilizado em dois momentos distintos do projeto:inicialmente, quando pouco é conhecido do projeto, onde são geradas as estimativas iniciaisainda com uma abrangência macroscópica, para realizar o planejamento do projeto e,posteriormente, quando mais informações do projeto forem obtidas, o que permite orefinamento das estimativas geradas.

No momento de realizar as primeiras estimativas, apenas as atividades do processode desenvolvimento são analisadas. No refinamento das estimativas, as sub-atividades doprocesso também são consideradas.

O processo de gerência de tempo é composto por cinco atividades: (i) Identificar asdependências entre as atividades do projeto; (ii) Estimar a duração das atividades do projetocom abordagem top-down; (iii) Estimar a duração das atividades do projeto comabordagem bottom-up; (iv) Elaborar o cronograma do projeto; e , (v) Controlar ocronograma do projeto.

(i) Identificar as dependências entre as atividades do projeto: Nessa atividade asinter-relações, interações lógicas e interdependências entre as atividades do projeto sãoidentificadas e analisadas quanto à sua consistência, pois existem atividades que podem ser

realizadas independentemente de outras, mas há aquelas que precisam de uma relação dedependência temporal com outra(s).

(ii) e (iii) Estimar a duração das atividades do projeto: Para realizar as estimativasdo projeto, uma abordagem deve ser escolhida pelo gerente do projeto: top-down oubottom-up. As atividades (ii) e (iii) do processo de gerência de tempo são, então, realizadasde forma alternativa. Na abordagem top-down, as estimativas de prazo e esforço do projetosão realizadas, inicialmente, utilizando-se modelos paramétricos. Os valores dasestimativas fornecidos pelos modelos paramétricos são, então, ajustados pelo gerente doprojeto analisando-se dados de projetos similares e utilizando sua experiência pessoal paradecidir as estimativas do projeto. Definidos os valores das estimativas, estes devem serdistribuídos pelas atividades do projeto. Na abordagem bottom-up são utilizados dados deprojetos similares para realizar as estimativas das atividades do projeto. As estimativastotais do projeto são obtidas através do somatório das estimativas de suas atividades.

(iv) Elaborar o cronograma do projeto: Realizadas as estimativas para as atividadesdo projeto, o cronograma deve ser elaborado. Neste momento, são identificados oscaminhos críticos do projeto, determinadas as datas de início e fim das atividades eregistrados os marcos e pontos de controle no cronograma do projeto.

(v) Controlar o cronograma do projeto: Durante o desenvolvimento do projeto, ocronograma deve ser comparado, analisado e revisto sempre que necessário. Para isso, ogerente registra os desvios ocorridos e revê o cronograma, considerando a possibilidade derecuperação do desvio ou negociando com as partes envolvidas. As decisões e açõescorretivas a serem tomadas só devem ser feitas após consideradas suas implicações para oprojeto. As alterações do cronograma devem ser comunicadas às partes envolvidas noprojeto.

5.2 Processo de Gerência de Custos

A gerência de custos tem como objetivo elaborar e controlar o orçamento doprojeto.

Este processo deve ser utilizado em momentos distintos: inicialmente, após seremrealizadas as estimativas iniciais de tempo e esforço, são geradas as estimativas iniciais decustos, ainda com uma abrangência macroscópica. Posteriormente, as estimativas realizadassão detalhadas e, quando as estimativas de tempo, esforço ou alocação de recursos foremrevistas, as estimativas de custos também deverão ser.

O processo de gerência de custos é composto por três atividades: (i) Estimar custosdo projeto; (ii) Elaborar o orçamento do projeto; e, (iii) Controlar o orçamento do projeto.

(i) Estimar custos do projeto: O primeiro passo do processo de gerência de custos éestimar os custos do projeto. Nesta atividade, os elementos de custos do projeto (recursosde hardware, recursos de software, recursos humanos e outras despesas) são identificados esuas respectivas quantidades e custos atribuídos.

(ii) Elaborar orçamento do projeto: Os valores realizados na atividade anterior sãoutilizados para elaborar o orçamento do projeto, que será o baseline dos custos2 para mediro desempenho do projeto. Todos os elementos de custos e seus respectivos valores,identificados/registrados anteriormente, são inseridos no orçamento do projeto com suasrespectivas datas e frequência. As receitas previstas para o projeto também são registradas.

(iii) Controlar orçamento do projeto: Durante o desenvolvimento do projeto, ogerente deve comparar, analisar e rever o orçamento sempre que necessário. O controle decustos envolve identificar e documentar o motivo das variações, tanto positivas quantonegativas e adequar o orçamento a elas. Assim, os desvios ocorridos são registrados e oorçamento é alterado para adequar-se a eles. Caso os desvios registrados e/ou as açõescorretivas tomadas indiquem situações de risco ao projeto, estas devem ser comunicadas àspartes interessadas.

6. A Ferramenta CustPlan

A ferramenta CustPlan foi desenvolvida para apoiar o planejamento de tempo ecustos nos Ambientes de Desenvolvimento de Software Orientados à Organização. Paradesenvolver a ferramenta CustPlan, inicialmente, foi realizado um estudo sobre asprincipais técnicas e métodos utilizados para realizar as estimativas de tempo e custos deprojetos de software. Esses métodos foram apresentados na seção 2 deste artigo. Emseguida, foram analisados os processos de gerência de tempo e gerência de custosregistrados na literatura de gerência de projetos e qualidade de software. Com base nessaliteratura, nos conceitos e práticas da gerência do conhecimento, nos modelos deestimativas analisados e em padrões de gerência de projetos foram propostos o processo degerência de tempo e o processo de gerência de custos, apresentados na seção 5 deste artigo,que são apoiados pela ferramenta aqui apresentada.

Na seção 6.1 serão apresentados os critérios de caracterização de projetos utilizadosna ferramenta. Na seção 6.2 é apresentada uma pesquisa realizada para alimentar a base deconhecimento da ferramenta e, finalmente, na seção 6.3 a ferramenta CustPlan éapresentada.

6.1 Caracterização de Projetos

Um dos modelos utilizados para realizar as estimativas de projetos são as analogias.Para realizar as estimativas utilizando analogias é necessário que haja uma base de dadoshistóricos de projetos que forneçam os valores que serão utilizados como apoio para arealização das estimativas de novos projetos. E, além disso, é necessário que haja umaforma de determinar quais dos projetos que estão presentes na base de dados históricos sãoadequados para fornecer os dados. Para isso, é necessário caracterizar os projetos, traçando-lhes um perfil e, posteriormente, determinar um mecanismo de busca que indique asimilaridade entre eles.

2 Baseline dos Custos é o orçamento referencial que será utilizado para medir e monitorar o

desempenho dos custos do projeto. É desenvolvido através da totalização das estimativas de custos por

período.

Para a implementação da abordagem aqui apresentada na Estação Taba, acaracterização de projetos foi realizada considerando-se dois tipos especiais de critérios:genéricos e específicos. Os critérios genéricos são os que podem caracterizar um projetoindependente da finalidade para o qual a caracterização será utilizada. Os critériosespecíficos são aqueles que são definidos de acordo com a finalidade da caracterização. Porexemplo, para traçar perfis de projetos para realizar analogias para determinação de prazose custos, um critério específico importante pode ser “Restrição de Cronograma”, queindica que o tempo para desenvolvimento do projeto é pré-estabelecido (como em umdesenvolvimento de um site que precisa estar ativo em 3 meses).

A determinação dos critérios genéricos de um projeto é obrigatória, ou seja, essescritérios precisam ser informados para que o agrupamento de projetos similares sejarealizado. Os critérios específicos devem ser informados de acordo com a finalidade dacaracterização de projetos na Estação Taba.

Dada a complexidade da implementação de um mecanismo automático de busca porprojetos similares, neste trabalho, o referido mecanismo não foi determinado. O usuáriotem a flexibilidade de determinar os critérios desejados e o nível de filtragem que seráutilizado na busca.

As tabelas a seguir apresentam os critérios de caracterização genéricos e específicospropostos para a Estação Taba. Os critérios foram escolhidos com base na literatura,principalmente nas propostas de JONES (2000), e levando-se em consideração os critériosque já estavam presentes na Estação.

Tabela 1 – Critérios Genéricos de Caracterização de Projetos de Software

Critério DescriçãoIndústria Define a indústria na qual o software está inserido. Pode-se usar

a classificação padrão de indústrias para determinar o conjuntode indústrias existentes. Exemplos são Extração de óleo e gás;Indústrias de refinaria de petróleo e relacionadas; Comunicação,Serviços de Transporte (JONES, 2000).

Tipo de Software Define a área de aplicação à qual o software se destina.Exemplos de tipos de software são: Sistemas Especialistas,Sistemas de Informação, Softwares Embutidos, SistemasMilitares, etc.

Paradigma Indica o paradigma utilizado no desenvolvimento do projeto.Ex.: Estrutural, Orientação a Objetos, etc.

Natureza do Projeto Indica se o projeto é um projeto de desenvolvimento ou seenvolve alguma forma de manutenção. As possíveis naturezasde projeto são: novo desenvolvimento, melhoria (adição defunções), atualização para atender a novas regulamentações,reparo de defeitos, melhoria de performance, migração paranova plataforma, nacionalização, reengenharia, atualização emmassa (por exemplo: Euro e ano 2000), híbrida (JONES, 2000).

Tabela 2 – Critérios Específicos de Caracterização de Projetos de Software

Critério DescriçãoNível de experiência dos gerentesdo projeto

Indica o nível de experiência da gerência do projeto comEngenharia de Software, com a plataforma de desenvolvimento,a tecnologia utilizada e por último com o domínio da aplicação(JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN,2001). Para diminuir a subjetividade deste critério são utilizados5 valores possíveis para cada tópico de experiência: 0 – nenhumaexperiência; 1 – treinamento acadêmico; 2 – prática em até trêsprojetos; 3 – experiente; 4 – capaz de orientar outros (GOMES,2001).

Nível de experiência da equipe dedesenvolvimento

Indica o nível de experiência da equipe de desenvolvimento comEngenharia de Software, com a plataforma de desenvolvimento,a tecnologia utilizada e por último com o domínio da aplicação(JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN,2001). Para diminuir a subjetividade deste critério são utilizados5 valores possíveis para cada tópico de experiência: 0 – nenhumaexperiência; 1 – treinamento acadêmico; 2 – prática em até trêsprojetos; 3 – experiente; 4 – capaz de orientar outros (GOMES,2001).

Nível de experiência dos clientes Indica o nível de experiência do cliente com ciclo de vida dedesenvolvimento de software e com o domínio da aplicação(JONES, 2000).

Distribuição geográfica da equipe Indica se a equipe está centralizada ou dispersa geograficamente(JONES,2000).

Restrição de Cronograma Indica se o projeto possui alguma restrição de cronogramaRestrição de Desempenho ouTempo de Execução

Indica se o projeto possui alguma restrição de desempenho outempo de execução (JONES, 2000; MENZIES e SINSEL, 2000;IDRI e ABRAN, 2001).

Restrição de Segurança Indica se o projeto possui alguma restrição de segurança(JONES, 2000; MENZIES e SINSEL, 2000; IDRI e ABRAN,2001).

Restrição de Recursos Humanos Indica se o projeto possui alguma restrição de recursos humanos.Uso de Tecnologia inovadora Indica se o projeto possui algum grau de inovação relacionada a

plataforma utilizada, linguagem de programação utilizada,arquitetura do projeto, etc.

6.2 Pesquisa de Dependências Usuais entre as Atividades do Processo deDesenvolvimento

O primeiro passo para realizar o planejamento do cronograma do projeto é indicaras dependências entre as atividades do projeto, conforme apresentado no processo degerência de tempo, descrito na seção 5. Para realizar esse passo utilizando CustPlan, ogerente de projetos poderá consultar no repositório da organização as dependências usuaisentre as atividades do processo de desenvolvimento.

Para coletar as dependências usuais, foi realizada uma pesquisa cujos participantesforam gerentes de projetos de software da Fundação COPPETEC (Coordenação de

Projetos, Pesquisas e Estudos Tecnológicos) e outros gerentes de projetos que atuam emprocessos de desenvolvimento do software. Foram considerados 8 gerentes de projeto,sendo estes mestres ou doutores na área de informática e com experiência relevante emgerência de projetos de software.

A pesquisa foi realizada utilizando-se um questionário que considerou as atividadesdo processo de desenvolvimento da ISO/IEC 12207 - Tecnologia de Informação –Processos de ciclo de vida de software. O questionário apresentou uma tabela onde oparticipante indicou, para cada atividade do processo, suas pré-atividades, ou seja, asatividades que precisam estar concluídas para que ela possa ser realizada. Foi permitido aoparticipante registrar considerações sobre as dependências e comentários em geral.

Com base nos dados coletados, um conjunto de dependências usuais entre asatividades do processo de desenvolvimento da ISO/IEC 12207 foi proposto e armazenadono repositório da organização para ser utilizado durante a atividade Identificar asDependências entre as Atividades do Projeto realizada no planejamento do cronograma doprojeto.

Para a realização dessa pesquisa foram seguidas cinco atividades: (i) definição; (ii)planejamento; (iii) operação; (iv) análise e interpretação; e (v) apresentação. O ponto departida foi a concepção da idéia da pesquisa, onde foi avaliado se uma pesquisa erarealmente necessária e apropriada para atender as questões a serem investigadas. Dandoinício ao processo de realização da pesquisa propriamente dito, na atividade definição apesquisa foi definida em termos do problema pesquisado, seus objetivos e metas. Naatividade de planejamento, o projeto da pesquisa foi realizado, a instrumentação foielaborada e as ameaças à perfeita execução da pesquisa foram avaliadas. Durante estaatividade foi gerado o planejamento da pesquisa. Na atividade operação, os questionáriosforam entregues aos participantes e os dados obtidos foram organizados em uma planilhavisando facilitar a análise e avaliação dos dados realizada na atividade posterior de análisee interpretação. Finalmente os resultados foram apresentados na atividade apresentação.

6.2.1 Resultados da Pesquisa

Os resultados da pesquisa caracterizaram um conjunto inicial de dependênciasusuais entre as atividades do processo de desenvolvimento da NBR ISO/IEC 12207 que foiarmazenado no repositório da organização para apoiar os gerentes de projeto naidentificação das dependências entre as atividades do projeto.

Para realizar a pesquisa, um conjunto inicial de dependências foi proposto, porém,os participantes da pesquisa não tiveram acesso às dependências presentes nesse conjunto.

Para obter os resultados, inicialmente, as características dos participantes dapesquisa foram analisadas e, em seguida, foram estabelecidos pesos para cada um deles,considerando o tempo de atuação em gerência de projetos, o número de projetosgerenciados, a experiência em processos de software e o conhecimento sobre a normaNBR ISO/IEC 12207 de cada participante. A análise das características e cálculo dos pesosdos participantes os classificou em dois grupos: experientes e pouco experientes.

Foi, então, estabelecido o valor do ponto de inclusão, para indicar o valor a partir doqual uma dependência identificada pelos participantes faria parte do conjunto final dedependências.

Analisadas as dependências identificadas por cada participante, foi possívelperceber que os participantes pertencentes ao grupo experiente identificaram as

dependências presentes no conjunto inicial proposto, mesmo sem terem tido acesso a ele.Por outro lado, alguns participantes do grupo pouco experiente identificaram muitasdependências incoerentes.

Utilizando os pesos dos participantes e o critério de inclusão de uma dependência noconjunto de dependências (valor do ponto de inclusão), o conjunto de dependências obtidofoi igual ao conjunto inicialmente proposto.

A tabela 3 apresenta o conjunto de dependências usuais obtido como resultado dapesquisa. Esse conjunto de dependências usuais foi armazenado no repositório daorganização e pode ser acessado como apoio à determinação das dependências entre asatividades do projeto.

Tabela 3 – Conjunto final de dependências usuais entre as atividades do processo de desenvolvimento

Atividades que precisam estar concluídas

Atividades do Processo de Desenvolvimento daNBR ISO/IEC 12207 -- Tecnologia de Informação – Processos de ciclo de vida de software que

devem ser executadas

An

ális

e d

os

Re

qu

isito

s d

oS

iste

ma

An

ális

e d

os

Re

qu

isito

s d

oS

oft

wa

re

Ap

oio

à a

ceita

ção

do

So

ftw

are

Co

difi

caçã

o e

Te

ste

s d

o S

oft

wa

re

Imp

lem

en

taçã

o d

op

roce

sso

Inst

ala

ção

do

So

ftw

are

Inte

gra

ção

do

Sis

tem

a

Inte

gra

ção

do

So

ftw

are

Pro

jeto

da

Arq

uite

tura

do

Sis

tem

a

Pro

jeto

da

Arq

uite

tura

do

So

ftw

are

Pro

jeto

De

talh

ado

do

So

ftw

are

Te

ste

de

Qu

alif

ica

ção

do

Sis

tem

a

Te

ste

de

Qu

alif

ica

ção

do

So

ftw

are

Análise dos Requisitos do Sistema: descrição das funções, capacidades, requisitos e restrições dosistema.

X

Análise dos Requisitos do Software: descrição das funções, capacidades, requisitos e restrições de cadaitem de software do sistema.

X X

Apoio à aceitação do Software: acompanhamento à utilização do software. X X X X X X X X X X X X

Codificação e Testes do Software: implementação e testes do software e bases de dados. X X X X X X

Implementação do processo : Definição do modelo de ciclo de vida, atividades e tarefas do projeto.

Instalação do Software: implantação do software no ambiente do cliente. X X X X X X X X X X X

Integração do Sistema: integração dos itens de software ao sistema. X X X X X X X X X

Integração do Software: integração dos componentes que compõem cada item de software. X X X X X X X

Projeto da Arquitetura do Sistema: definição dos itens de hardware, software e operações do sistema. X X

Projeto da Arquitetura do Software: definição dos itens de hardware, software e operações do sistema decada item de software do sistema.

X X x X

Projeto Detalhado do Software: refinamento do projeto da arquitetura de cada componente de software,interface e bases de dados.

X X X X x

Teste de Qualificação do Sistema: realização de testes segundo os requisitos de qualidade estabelecidospara o sistema.

X X X X X X X X X X

Teste de Qualificação do Software: realização de testes segundo os requisitos de qualidade estabelecidospara cada item de software.

X X X X X X X X

6.3 A Ferramenta CustPlan

Buscando-se apoiar a abordagem de planejamento de tempo e custos emADSOrg na Estação Taba, foi implementada a ferramenta CustPlan, que apoia asatividades presentes nos processos de gerência de tempo e gerência de custosapresentados na seção 5.

CustPlan é disponibilizada em um ADSOrg instanciado e, dessa forma,possibilita a utilização do conhecimento organizacional armazenado no repositório daorganização. Ela faz parte das ferramentas disponibilizadas ao usuário do ADSOrgdurante as atividades de gerência do projeto. CustPlan é acessada pelo gerente doprojeto em momentos distintos durante o processo de desenvolvimento do projeto. Pararealizar o planejamento inicial do projeto, o gerente acessará a CustPlan através daatividade Planejamento do Projeto, mais especificamente durante a realização das sub-atividades Planejamento de Tempo e Planejamento de Custos. Para refinar/detalhar asestimativas realizadas, o gerente do projeto acessará a CustPlan novamente após aespecificação de requisitos do sistema estar concluída.

Como a CustPlan trata dois processos distintos, ela será dividida em duas partes(Planejamento de Tempo e Planejamento de Custos) para ser melhor apresentada.

(i) Planejamento do Tempo

O primeiro acesso à CustPlan é realizado para apoiar a realização das primeirasestimativas de tempo do projeto. É feito quando o gerente seleciona a sub-atividade“Planejamento Inicial do Tempo”, presente na atividade “Planejamento do Projeto”.Nesse momento, um ícone da CustPlan fica disponível no lado direito da tela (figura 1).

Figura 1 – Acesso à CustPlan para Planejamento do Tempo

Para realizar o planejamento do tempo, a CustPlan apoia as seguintes atividades:(i) Identificar dependências entre as atividades do projeto; (ii) Estimar a duração dasatividades do projeto; (iii) Elaborar o cronograma do projeto; e, (iv) Controlar ocronograma do projeto.

A figura 2 apresenta a interface básica da ferramenta onde é possível identificar,no lado esquerdo da tela, o processo que está sendo executado e, no lado direito, aatividade que está sendo realizada pelo gerente. Os ícones em formato de interrogação elâmpada, localizados no canto superior direito da tela, permitem a realização de consultae registro de conhecimento pertinentes às atividades do processo. O registro doconhecimento, acessado através do ícone em forma de lâmpada, é realizado através daferramenta de aquisição de conhecimento chamada Acknowledge (MONTONI et al.,2001). Essa ferramenta tem como objetivo permitir que os gerentes de projeto registremo conhecimento por eles adquirido durante a execução das atividades dos processosrealizados para o desenvolvimento de um software. Esse conhecimento é, então,filtrado, empacotado, armazenado no repositório da organização e disponibilizado paraconsulta. O conhecimento armazenado para os processos de gerência de tempo e custosdisponibilizado ao gerente pode auxiliá-lo na execução da atividades dos processos, e,consequentemente, permitir que melhores estimativas sejam realizadas para o projeto. Aconsulta ao conhecimento é feita através do ícone em forma de interrogação que exibe atela apresentada na figura 3.

A figura 2 apresenta a tela da CustPlan que é utilizada para a identificação dasdependências entre as atividades do projeto (atividade (i)). Nessa tela, além doconhecimento disponibilizado, o gerente pode acessar também o conhecimento deespecialistas sobre as dependências usuais entre as atividades do processo dedesenvolvimento da NBR ISO/IEC 12207 para auxiliá-lo a identificar as relações dedependência entre as atividades do projeto. Esse conhecimento foi obtido através darealização da pesquisa com gerentes de projeto, citada anteriormente, considerando asatividades do processo de desenvolvimento da referida norma.

Figura 2 – Interface CustPlan – Processo de Gerência de Tempo – Tela Identificardependências entre as atividades do projeto

Figura 3 – Consulta ao conhecimento armazenado no repositório da organização

Para realizar as estimativas de duração das atividades do projeto (atividade (ii)),CustPlan disponibiliza ao gerente do projeto duas abordagens: top-down e bottom-up,que são realizadas de forma alternativa na ferramenta.

De acordo com os resultados observados na literatura de estimativas de projetos,a associação de modelos paramétricos, analogia de estimativas e julgamento deespecialistas para realizar as estimativas de projetos tem se mostrado o caminho maiseficiente. Baseando-se nesses resultados, CustPlan permite que o gerente realize asestimativas combinando esses três tipos de modelos, através da utilização da abordagemtop-down para a realização das estimativas.

A utilização dos modelos paramétricos é realizada na execução das atividadesRealizar estimativas do projeto utilizando Análise de Pontos de Função e Realizarestimativas do projeto utilizando COCOMO II, onde o gerente fornece os dadosnecessários ao cálculo das estimativas. A analogia de estimativas e julgamento deespecialistas são realizadas na atividade Ajustar estimativas do projeto a partir deprojetos similares, onde o gerente realiza a busca por projetos similares, indicando oscritérios de caracterização a serem considerados e o filtro da busca e, analisando osdados de projetos similares disponibilizados e comparando-os com os valores dasestimativas geradas pela Análise de Pontos de Função e COCOMO II, utiliza suaexperiência pessoal e decide as estimativas do projeto. A figura 4 apresenta a tela ondeo gerente visualiza as estimativas calculadas pelos modelos paramétricos, realiza abusca por projetos similares e decide as estimativas do projeto.

Figura 4 – Ajuste das estimativas obtidas pelos modelos paramétricos utilizandoanalogias e julgamento de especialista – Abordagem top-down

Para distribuir as estimativas realizadas para o projeto entre suas atividades, ogerente poderá consultar dados de projetos similares, armazenados no repositório daorganização, que servirão como base para a realização das estimativas das atividades doprojeto.

Na abordagem bottom-up de realização de estimativas do projeto, o gerenteutilizará dados de projetos anteriores, sua experiência pessoal e o conhecimentoregistrado por outros gerentes para realizar as estimativas das atividades. As estimativastotais do projeto serão calculadas pelo somatório das estimativas das atividades. Afigura 5 mostra a realização da estimativas com abordagem bottom-up. Na partesuperior da tela é realizada a busca por projetos similares e, para cada atividade doprojeto que está sendo estimado, são apresentadas suas estimativas nos projetosanteriores para que o gerente realize uma análise comparativa e utilize sua experiênciapara decidir pelos valores das estimativas das atividades do projeto.

Figura 5 – Realização das estimativas para as atividades analisando dados de projetossimilares – Abordagem bottom-up

A elaboração do cronograma (atividade (iii)) é feita com o apoio da CustPlan,que identifica automaticamente os caminhos críticos do projeto analisando as durações edependências entre as atividades do projeto e registra no cronograma os marcos epontos de controle identificados no Plano de Acompanhamento do projeto. O gerentedeve, então, indicar as datas de início e fim das atividades do projeto.

Para controlar o cronograma (atividade (iv)), o gerente do projeto utiliza aCustPlan para registrar os desvios que ocorreram e, posteriormente, analisa essesdesvios para alterar o cronograma. Novamente, o conhecimento registrado por outrosgerentes e a experiência pessoal do gerente do projeto são úteis para guiar as açõescorretivas a serem realizadas. A figura 6 apresenta a tela de registro dos desvios e afigura 7 apresenta a tela de alteração do cronograma.

Figura 6 – Registro de desvios de cronograma

Figura 7 – Alteração de cronograma

O planejamento inicial do tempo é realizado no início do projeto, quando poucasinformações são conhecidas, por isso as sub-atividades não são consideradas. Após aespecificação de requisitos do sistema estar concluída, deve ser feito o refinamento dasestimativas de tempo, onde as atividades do processo de gerência de tempo apresentadasna ferramenta são executadas novamente, porém, considerando as sub-atividades e asinformações obtidas durante a elaboração da especificação de requisitos do sistema. Afigura 8 ilustra realização de estimativas com abordagem bottom-up para indicar aduração das atividades do projeto no momento do refinamento, ou seja, considerando assub-atividades do processo de desenvolvimento. Os valores estimados no planejamentoinicial podem ser alterados (recalculados) ou apenas expandidos (distribuídos entre assub-atividades).

Figura 8 – Tela de realização das estimativas das atividades do projeto – Refinamento do

Planejamento de Tempo

(ii) Planejamento dos Custos

Após ser realizado o planejamento do tempo do projeto, utilizando a primeiraparte da CustPlan,, é feita a alocação de recursos humanos ao projeto, que é realizadacom o apoio da ferramenta RHPlan (SCHNAIDER, 2003). Após os recursos humanosestarem alocados ao projeto deve ser elaborado o orçamento do mesmo. Para realizar oplanejamento dos custos, a segunda parte da CustPlan deve ser utilizada. Esta apóia asseguintes atividades: (i) Estimar custos; (ii) Elaborar o orçamento do projeto; e, (iii)Controlar o orçamento do projeto.

Durante o planejamento inicial dos custos, apenas as atividades do processo dedesenvolvimento são consideradas. As sub-atividades serão consideradas no momentode refinar as estimativas geradas durante o planejamento inicial.

O primeiro acesso à ferramenta para tratar os custos do projeto é feito quando ogerente seleciona, no ADSOrg instanciado, a sub-atividade “Planejamento Inicial dosCustos”, presente na atividade “Planejamento do Projeto”. Nesse momento, assim comono planejamento de tempo, um ícone da CustPlan fica disponível no lado direito da tela.

Para realizar a estimativa dos custos do projeto (atividade (i)), os elementos decustos devem ser identificados. A figura 9 ilustra a tela que é utilizada para aidentificação desses elementos. O gerente indica nos checklists quais serão os recursosutilizados no projeto e sua quantidade. Todos os dados referentes aos recursos humanossão calculados automaticamente pela ferramenta, considerando as informações daalocação de recursos humanos ao projeto (realizada com apoio da RHPlan(SCHNAIDER, 2003)) e o cronograma.

Figura 9 – Interface CustPlan – Processo de Gerência de Custos – Tela Identificarelementos de custos

Identificados os elementos, seus valores são atribuídos na atividade Atribuirvalor aos elementos de custos. Para cada elemento de custo do projeto, seu custo padrãona organização é sugerido ao gerente que pode aceitá-lo ou alterá-lo.

Em seguida, o orçamento é elaborado (atividade (ii)). Os custos com recursoshumanos são calculados automaticamente por atividade do projeto, considerando os

dados do cronograma e da alocação de recursos às atividades do projeto. Para os demaisrecursos, o gerente deve indicar a data em que a despesa ocorrerá e sua frequência.

O controle de custos (atividade (iii)) envolve identificar e documentar o motivodas variações, tanto positivas quanto negativas e adequar o orçamento a elas. Assim, osdesvios ocorridos são registrados e o orçamento é alterado para adequar-se a eles. Casoos desvios registrados e/ou as ações corretivas tomadas indiquem situações de risco aoprojeto, estas devem ser comunicadas às partes interessadas. Na CustPlan, o controle doorçamento é realizado de forma similar ao controle do cronograma. O gerente registraos desvios e altera o orçamento analisando os desvios registrados. CustPlan realiza asalterações do cronograma no orçamento automaticamente. A figura 10 mostra umexemplo de desvio de cronograma que é registrado também no orçamento. O registro dodesvio no cronograma foi ilustrado na figura 6. A figura 11 mostra o orçamento alteradopara adequar-se às alterações do cronograma, provocadas pelas ações corretivas aodesvio registrado.

Figura 10 – Registro de desvios de cronograma no orçamento

Figura 11 – Alteração do orçamento devido a desvios de cronograma

O planejamento inicial dos custos, assim como o planejamento inicial do tempo,é realizado no início do projeto, quando poucas informações são conhecidas, por isso assub-atividades não são consideradas. Após a especificação de requisitos do sistema estarconcluída deve ser feito o refinamento das estimativas do tempo e, consequentemente,das estimativas de custos também, onde as atividades aqui apresentadas são executadasnovamente, porém, considerando as sub-atividades do processo de desenvolvimento e asinformações coletadas durante a elaboração da especificação de requisitos. É importantelembrar que, quando o planejamento de tempo, esforço ou alocação de recursos foremalterados, o planejamento de custos deverá ser revisto e, caso as alterações realizadasafetem o orçamento, este deverá ser alterado.

7. Considerações Finais

A tecnologia hoje disponível para o desenvolvimento de software permite, e atéinduz, a utilização de arquiteturas de sistemas cada vez maiores e mais complexas. Emcontrapartida, o prazo para o desenvolvimento de tais produtos tem sido compactado,refletindo a evolução tecnológica e necessidades econômicas do mercado. As dimensõesdos produtos de software estão atingindo níveis quantitativos cada vez maiores, nãoocorrendo o mesmo com a tolerância a falhas de previsão de orçamentos e cronogramas.Esse cenário exige que processos formalizados de gerência de projetos de softwaresejam definidos e utilizados.

A gerência dos prazos e custos de projetos de software é muito importante, umavez que pesquisas mostraram que a maioria dos projetos que fracassam têm como seuprincipal motivo o mal planejamento dos custos e cronograma. Esse planejamento éfortemente centrado na experiência e conhecimento adquiridos em projetos anteriores.Quanto maior a experiência do gerente do projeto, melhor ele será capaz de realizar asestimativas para o projeto corrente. Porém, o conhecimento do planejamento de prazos ecustos de um gerente de projeto não pode permanecer no nível do indivíduo. Para que aorganização evolua aprendendo com seus próprios erros e acertos, é necessário que oconhecimento seja gerenciado de forma a tornar possível sua captura, recuperação efutura utilização. Prover uma organização de capacidade para utilizar uma abordagemde planejamento de prazos e custos prática e eficaz é um ponto diferencial para a mesmadiante das exigências mercadológicas atuais. O trabalho descrito neste artigo veio,exatamente, propor uma abordagem para o planejamento de tempo e custos nasorganizações de software. Essa abordagem está inserida em um tipo especial deambientes de desenvolvimento de software, chamados de Ambientes deDesenvolvimento de Software Orientados à Organização (ADSOrg). O trabalho aquidescrito encontra-se, assim, no contexto do ADSOrg, um projeto de longo prazo daCOPPE, englobando outras ferramentas de gerência de projetos com enfoque emgerência do conhecimento e memória organizacional.

Os benefícios da abordagem proposta poderão ser avaliados em umprocedimento de validação da ferramenta. Porém, a validação de uma ferramenta comoCustPlan implica em sua utilização em vários projetos o que excede em muito o tempoesperado para uma tese de mestrado. Portanto, a validação será realizada no contexto doprojeto ADSOrg englobando outras ferramentas de gerência de projetos.

Uma observação importante que deve ser registrada no que diz respeito àeficiência das estimativas geradas por uma determinada técnica ou abordagem, é que oprocesso de realização estimativas é um processo de previsão e não de precisão, sendoassim, uma margem de erro deve ser determinada e as estimativas que estiverem umdesvio menor ou igual a essa margem de erro devem ser consideradas acuradas.

8. Referências Bibliográficas

ABECKER, A., BERNADI, A., HINKELMANN, K. et al., (1998), “Toward aTechnology for Organizational Memories”, IEEE Intelligent Systems, v. 13,May/June, p. 40-48.

ABRAN, A., JACQUET, J.-P., (1999), “A Structured Analysis of the New ISO Standardon Functional Size Measurement-definition of Concepts”Software Engineering Standards. Fourth IEEE International Symposium andForum, p. 230 –241.

BIELAK, J., (2000), “Improving Size Estimates Using Historical Data”, IEEESoftware, Volume: 17, Issue: 6 , Nov/Dec, p. 27 –35.

BOEHM, B. W., “Software Engineering Economics”, Prentice Hall, Upper SaddleRiver, 1981.

BOEHM, B. W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K.,HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., “Software CostEstimation with COCOMO II”, Prentice Hall, 2000.

BRIAND, L.C., EMAM, K., SURMANN, D., WIECZOREK, I., MAXWELL, K.D.,(1999), “An Assessment and Comparison of Common Software CostEstimation Modeling Techniques”, Communications of the ACM, May, p.313-322.

DIENG, R., (2000), “Knowledge Management and the Internet”, IEEE IntelligentSystems, vol. 15, n.3 (Maio/Junho), p. 14-17

ISO/IEC DTR 16326 – Software Engineering – Guide for the Application of ISO /IEC12207 to Project Management, 1999.

FARIAS, L. L., (2002), “Planejamento de Riscos em Ambientes de Desenvolvimento deSoftware Orientados à Organização”, Tese de M. Sc., COPPE/UFRJ, Rio deJaneiro, RJ, Brasil.

GARMUS, D., HERRON, D., “Function Point Analysis: Measurement Practices forSuccessful Software Projects”, Addison Wesley, 2001.

GOMES, A.G.J., (2001), “Avaliação de Processos de Software Baseada emMedições”, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.

GRAY, A.R., MACDONELL, S.G., SHEPPERD, M.J., (1999), “Factors SystematicallyAssociated With Errors in Subjective Estimates of Software DevelopmentEffort: The Stability of Expert Judgment”, Software Metrics Symposium -METRICS, p. 216 –227.

JEFFERY, R..,RUHE, M., WIEEZOREK, I., (2001), “Using Public Domain Metrics toEstimate Software Development Effort” , 7th International Software MetricsSimposium 2001 – Metrics 2001, pp. 16-27.

JONES, C., “Software Assessments, Benchmarks, and Best Practices”, Addison-Wesley Information Technology Series, 2000 .

LEE, J., KIM, Y., YU, S., (2001), “Stage Model for Knowledge Management”, In: 34th

Hawaii International Conference on System Sciences, IEEE Software, p. 1-10.

MARKKULA, M., (1999), “Knowledge Management in Software EngineeringProjects”, In: Proceedings of the 11th International Conference on SoftwareEngineering & Knowledge Engineering, Kaiserslautern, Germany, Jun, p. 20-27.

MENDONÇA, M. G., SEAMAN, C.B., BASILI, V., KIM, Y., (2001), “A PrototypeExperience 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: CaseStudies with Software Risk Assessment”, Automated Software Engineering.Fifteenth IEEE International Conference, p. 165 –173.

MONTONI, M., ROCHA, A. R., TRAVASSOS, G. H., (2002), "Aquisição deConhecimento nos Processos de Negócio", In: 7o Workshop de Teses emEngenharia de Software, Gramado, Brasil, Outubro.

MURCH, R., “Project Management: Best Pratices for IT Professionals”, PrenticeHall, 2000.

NBR ISO 10006 – Gestão da Qualidade: Diretrizes para Qualidade no Gerenciamentode Projetos, 2000.

O’LEARY, D. E., (1998), “Enterprise Knowledge Management”, IEEE IntelligentSystems, Mar, p. 54-61.

O’LEARY, D.E., STUDER, R., (2001), “Knowledge Management: AnInterdisciplinary Approach”, IEEE Intelligent Systems, Jan/Feb, p. 24-25.

OLIVEIRA, K., (1999), “Modelo para Constrição de Ambientes de Desenvolvimentode Software Orientados a Domínio”, Tese de D. Sc., COPPE/UFRJ, Rio deJaneiro, RJ, Brasil.

PMBOK – Project Management Body of Knowledge, PMI – Project ManagementInstitute, 2000.

PUTNAM, L.H., (1978), “A General Empirical Solution to the Macro Software Sizingand Estimation Problem”, IEEE Systems, Jul.

RAMASUBRAMANIAN, S., JAGADEESAN, G., (2002), “Knowledge Managementat Infosys”, IEEE Software, May/Jun, p. 53-55.

ROCHA, A.R.C, AGUIAR T. C., SOUZA, J. M., (1990), “TABA: A HeuristicWorkstation for Software Development”, In: Proceedings of COMPEURO’90,Tel Aviv, Israel, Maio.

RUNESON, P., BORGQUIST, N., LANDIN, M., BOLANOWSKI, W., (2000), “AnEvaluation of Functional Size Methods and a Bespoke Estimation Method forReal-Time Systems”, PROFES – Product Focused Software ProcessImprovement, p. 339-352.

RUS, I., LINDVALL, M., (2002), “Knowledge Management in Software Engineering”,IEEE Software , v. 19, Issue: 3 , May/Jun, p. 26 –38.

SCHNAIDER, L., (2003), “Planejamento de Alocação de Recursos Humanos emAmbientes de Desenvolvimento de Software Orientados à Organização”, Tesede M. Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil.

SEPPÃNEN, V., KOMI-SIRVIÕ, S., MÃNTYNIEMI, A., (2002), “Toward aPractical Solution for Capturing Knowledge for Software Projects”, IEEESoftware, May/Jun, p. 60-62.

VILLELA, K., TRAVASSOS, G.H., ROCHA, A.R., (2000), “Ambientes deDesenvolvimento de Softwrae Orientados à Organização”, PublicaçãoTécnica COPPE/UFRJ - ES530/00 Rio de Janeiro, RJ, Abril.

VILLELA, K., TRAVASSOS, G.H., ROCHA, A.R., (2001), “Ambientes deDesenvolvimento de Softwrae Orientados à Organização”, IDEAS'2001 -Workshop Ibero-americano de Ingeniería de Requisitos y Ambientes deSoftware, Jan Jose, Costa Rica, Abril.

WANGENHEIM, C. G. V., LICHTNOW, D., WANGENHEIM , A.. V., (2001), “AHybrid Approach for Corporate Memory Management Systems in SoftwareR&D Organizations”, 13th International Conference on Software Engineeringand Knowledge Engineering – SEKE 2001 , p. 326-330.

WEI, C., HU, P. J., CHEN, H., (2002), “Design and Evaluation of a KnowledgeManagement System”, IEEE Software, May/Jun, p. 56-59.

YAMAURA, T., KIKUNO, T., (1999), “A Framework for Top-down Cost Estimationof Software Development”, Computer Software and Applications Conference –COMPSAC, p. 322–323.