Gerncia de Projetos de Software

Antes de contratar o desenvolvimento de um software, geralmente, um cliente quer saber se seu fornecedor capaz de realizar esse trabalho, quanto o projeto custar e qual ser a sua durao. Para responder a essas perguntas, necessrio definir o escopo do projeto, atravs de um levantamento preliminar de requisitos, realizar estimativas, levantar riscos, alocar recursos e definir um cronograma de execuo. Todas essas informaes so registradas em um documento, chamado Plano de Projeto, que deve ser sistematicamente revisado ao longo do projeto, de modo a permitir acompanhar o progresso e tomar aes corretivas, no caso de se detectar desvios em relao ao inicialmente planejado. Esse conjunto de atividades faz parte da gerncia de projetos de software.

1 Projeto de Software e Gerncia de Projetos de Software

Projeto, como definido pelo PMBOK1, um empreendimento temporrio com o objetivo de criar um produto ou servio nico [4]. um trabalho que visa criao de um produto ou execuo de um servio especfico, temporrio, no repetitivo e que envolve um certo grau de incerteza na sua realizao [5]. Normalmente, caracterizado por uma seqncia de atividades (o processo do projeto), sendo executada por pessoas dentro de limitaes de tempo, recursos (no caso de projetos de software, sobretudo, pessoas) e custos. Assim sendo, a Gerncia de Projetos de Software envolve, dentre outros, o planejamento e o acompanhamento das pessoas envolvidas no projeto, do produto sendo desenvolvido e do processo seguido para evoluir o software de um conceito preliminar para uma implementao concreta e operacional [1]. Uma vez que o processo j foi objeto de estudo, acreditamos que o leitor j est convencido de sua importncia para o sucesso de um projeto de software. Passemos, ento, a consideraes sobre as pessoas e o produto. Pessoas: Em um projeto de software, h vrias pessoas envolvidas, exercendo diferentes papis, tais como: Gerente de Projeto, Desenvolvedor (Analistas, Projetistas, Programadores, Engenheiros de Testes), Gerente da Qualidade, Clientes, Usurios. O nmero de papis e suas denominaes podem ser bastante diferentes dependendo da organizao e at mesmo do projeto. As pessoas trabalhando em um projeto so organizadas em equipes. Assim, o conceito de equipe pode ser visto como um conjunto de pessoas trabalhando em diferentes tarefas, mas objetivando uma meta comum. Essa no uma caracterstica do
1

O PMBOK (Project Management Body of Knowledge Corpo de Conhecimento em Gerncia de Projetos) um guia de orientao do conhecimento envolvido na gerncia de projetos, cujo objetivo identificar e descrever conceitos e prticas da gerncia de projetos em geral, padronizando a terminologia e os processos adotados nesta rea de estudo. Esse documento foi produzido e periodicamente atualizado pelo PMI (Project Management Institute Instituto de Gerncia de Projetos), uma entidade internacional sem fins lucrativos que congrega profissionais atuando na rea de gerncia de projetos [5].

desenvolvimento de software, mas da organizao de pessoas em qualquer atividade humana. Assim, a definio de equipes importante para uma ampla variedade de situaes, tal como uma formao de uma equipe de futebol. Para a boa formao de equipes, devem ser definidos os papis necessrios e devem ser considerados aspectos fundamentais, a saber: liderana, organizao (estrutura da equipe) e coordenao. Alm disso, h diversos fatores que afetam a formao de equipes: relacionamentos inter-pessoais, tipo do projeto, criatividade etc. No que se refere organizao / estrutura das equipes, h diversos tipos de equipes, tais como os citados por Pressman [1]: Democrtica Descentralizada: No tem um lder permanente e as decises so tomadas por consenso do grupo. A comunicao entre os membros da equipe horizontal. Controlada Descentralizada: H um lder do projeto, mas a comunicao ainda horizontal. Controlada Centralizada: H um lder do projeto e a comunicao entre ele e os demais membros da equipe vertical.

Por fim, na formao de equipes deve-se levar em conta o tamanho da equipe. Quanto maior o nmero de membros da equipe, maior a quantidade de caminhos possveis de comunicao, o que pode ser um problema, uma vez que o nmero de pessoas que podem se comunicar com outras pode afetar a qualidade do produto resultante. Produto Na gerncia de projetos, um gerente se depara, logo no incio, com um srio problema: so necessrias estimativas quantitativas (de tempo e custo) e um plano organizado do trabalho a ser feito, entretanto, no h informao suficiente para tal. Assim, a primeira coisa a fazer definir o escopo do software, realizando um levantamento de requisitos inicial. Neste contexto, ganha fora a idia de decompor o problema, em uma abordagem dividir para conquistar. Inicialmente, o sistema deve ser decomposto em subsistemas que so, por sua vez, decompostos em mdulos. Os mdulos podem, ainda, ser recursivamente decompostos em sub-mdulos ou funes, at que se tenha uma viso geral das funcionalidades a serem tratadas no projeto. Caractersticas especiais relacionadas a essas funes devem ser apontadas, tais como requisitos de desempenho. Estrutura de Diviso do Trabalho Uma boa gerncia de projetos comea com a fuso das vises de produto e processo. Cada funo ou mdulo a ser desenvolvido pela equipe do projeto deve passar pelas vrias atividades definidas no processo de software. Essa pode ser uma base bastante efetiva para a elaborao de estimativas, incluindo a alocao de recursos, j que sempre mais fcil estimar pores menores de trabalho. Assim, til elaborar uma estrutura de diviso do trabalho (Work Breakdown Structure WBS), considerando essa duas dimenses - produto e processo - como mostra a Tabela 1.

Tabela 1 Estrutura de Diviso do Trabalho considerando a fuso das vises de produto e processo. Atividades do processo Mdulos / Funes Mdulo 1 Mdulo 2 .... Anlise e Especificao de Requisitos Projeto Implementao Testes

2 O Processo da Gerncia de Projetos de Software

O processo de software composto de diversos processos, dentre eles o processo de gerncia de projetos. Tipicamente, um processo de gerncia de projetos envolve trs atividades principais: Planejamento: no incio do projeto, um plano organizado de como o projeto ser conduzido deve ser elaborado. O planejamento do projeto deve tratar da definio do escopo do software, da definio do processo de software do projeto, da realizao de estimativas, da elaborao de um cronograma e da identificao e tratamento dos riscos associados ao projeto. Acompanhamento: conforme anteriormente apontado, no incio do projeto h pouca informao disponvel, o que pode comprometer a preciso do escopo identificado, das estimativas realizadas e, por conseguinte, do cronograma elaborado. medida que o trabalho avana, maior conhecimento se tem e, portanto, possvel refinar e ajustar esses elementos. Alm disso, projetos so dinmicos e, portanto, esto sujeitos s mudanas que ocorrem no contexto em que o produto ser inserido. Sendo assim, fundamental acompanhar o progresso do trabalho, refinar escopo e estimativas, alterar o processo do projeto e o cronograma, alm de monitorar riscos e tomar aes corretivas. Assim sendo, as atividades realizadas (sumarizadas na Figura 1) no planejamento, so novamente consideradas no acompanhamento do projeto, que tipicamente se d nos marcos definidos no projeto. Encerramento: terminado o projeto, a gerncia ainda tem um importante trabalho a fazer: fazer uma anlise crtica do que deu certo e o que no funcionou, procurando registrar lies aprendidas de sucesso e oportunidades de melhoria. Comparaes entre valores estimados e realizados, identificao de problemas que ocorreram e causas dos desvios devem ser discutidas com os membros da equipe, procurando fazer com que haja um aprendizado, no s da equipe, mas da organizao como um todo. Uma tcnica bastante empregada neste contexto a anlise post-mortem.

Levantamento preliminar de requisitos

Marco

Processo de Desenvolvimento

Planejamento

Acompanhamento

Encerramento

Determinao do Escopo do Software Definio do Processo de Software do Projeto Realizao de Estimativas Estimativa de Tamanho Estimativa de Esforo Estimativa (Alocao) de Recursos Estimativa de Durao (Elaborao do Cronograma do Projeto) Estimativa de Custos Gerncia de Riscos Elaborao do Plano de Projeto

Figura 1 O Processo de Gerncia de Projetos. As atividades relacionadas no quadro na parte inferior na Figura 1 so realizadas diversas vezes ao longo do projeto. Tipicamente, no incio do projeto, elas tm de ser realizadas para produzir uma primeira viso gerencial sobre o projeto, quando so conjuntamente denominadas de planejamento do projeto. medida que o projeto avana, contudo, o plano do projeto deve ser revisto, uma vez que problemas podem surgir ou porque se ganha um maior entendimento sobre o problema. Essas revises do plano de projeto so ditas atividades de acompanhamento do projeto e tipicamente so realizadas nos marcos do projeto. Os marcos de um projeto so estabelecidos durante a definio do processo e tipicamente correspondem ao trmino de atividades importantes do processo de desenvolvimento, tais como Anlise e Especificao de Requisitos, Projeto e Implementao. O propsito de um marco garantir que os interessados tenham uma viso do andamento do projeto e concordem com os rumos a serem tomados. Em uma atividade de acompanhamento do projeto, o escopo pode ser revisto, alteraes no processo podem ser necessrias, bem como devem ser monitorados os riscos e revisadas as estimativas (de tamanho, esforo, durao e custo).

Na seqncia, cada uma das atividades inerentes ao planejamento e acompanhamento de projetos discutida, com exceo da definio do processo de software do projeto.

3 Determinao do Escopo do Software

A primeira atividade de gerncia em um projeto de software consiste na determinao do escopo do software a ser desenvolvido [1]. Basicamente, o escopo do produto composto pela especificao de um conjunto de funcionalidades (requisitos funcionais) associada a outras caractersticas desejadas (requisitos no funcionais), tais como desempenho, confiabilidade etc. Para que o escopo do software seja determinado, um levantamento preliminar de requisitos deve ser realizado2. O escopo pode ser documentado de vrias formas, sempre contendo uma breve descrio das funes do sistema, requisitos no funcionais importantes e o contexto e objetivos do sistema.

4 - Estimativas
Antes mesmo de serem iniciadas as atividades tcnicas de um projeto, o gerente e a equipe de desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessrios, a durao e, por fim, o custo do projeto. Apesar das estimativas serem um pouco de arte e um pouco de cincia, essa importante atividade no deve ser conduzida desordenadamente. As estimativas podem ser consideradas a fundao para todas as outras atividades de planejamento de projeto. Para alcanar boas estimativas de prazo, esforo e custo, existem algumas opes [1]: 1. Postergar as estimativas at o mais tarde possvel no projeto. 2. Usar tcnicas de decomposio. 3. Usar um ou mais modelos empricos para estimativas de custo e esforo. 4. Basear as estimativas em projetos similares que j tenham sido concludos. A primeira opo, apesar de ser atraente, no prtica, pois estimativas devem ser providas logo no incio do projeto (fase de planejamento do projeto). No entanto, deve-se reconhecer que quanto mais tarde for feita a estimativa, maior o conhecimento do projeto e menores as chances de se cometer erros. Assim, fundamental revisar as estimativas na medida em que o projeto avana (atividades de acompanhamento do projeto). Tcnicas de decomposio, a segunda opo, usam, conforme discutido anteriormente, a abordagem dividir para conquistar na realizao de estimativas, atravs da decomposio do projeto em mdulos / funes (decomposio do produto) e atividades mais importantes (decomposio do processo). Assim, a estrutura de diviso de trabalho,

A atividade de levantamento de requisitos ser estudada com mais detalhes no captulo 5.

como a mostrada na Tabela 1, pode ser utilizada para estimar, por exemplo, tamanho ou esforo. Modelos empricos, tipicamente, usam frmulas matemticas, derivadas em experimentos, para prever esforo como uma funo de tamanho (linhas de cdigo ou pontos de funo). Entretanto, deve-se observar que os dados empricos que suportam a maioria desses modelos so derivados de um conjunto limitado de projetos. Alm disso, fatores culturais da organizao no so considerados no uso de modelos empricos, pois os projetos que constituem a base de dados do modelo so externos organizao. Apesar de suas limitaes, modelos empricos podem ser teis como um ponto de partida para organizaes que ainda no tm dados histricos, at que a organizao possa estabelecer suas prprias correlaes. Finalmente, na ltima opo, dados de projetos anteriores armazenados em um repositrio de experincias da organizao podem prover uma perspectiva histrica importante e ser uma boa fonte para estimativas. Atravs de mecanismos de busca, possvel recuperar projetos similares, suas estimativas e lies aprendidas, que podem ajudar a elaborar estimativas mais precisas. Nesta abordagem, os fatores culturais so considerados, pois os projetos foram desenvolvidos na prpria organizao. Vale frisar que essas abordagens no so excludentes; muito pelo contrrio. O objetivo ter vrias formas para realizar estimativas e usar seus resultados para se chegar a estimativas mais precisas. Quando se fala em estimativas, est-se tratando na realidade de diversos tipos de estimativas: tamanho, esforo, recursos, tempo e custos. Geralmente, a realizao de estimativas comea pelas estimativas de tamanho. A partir delas, estima-se o esforo necessrio e, na seqncia, alocam-se os recursos necessrios, elabora-se o cronograma do projeto (estimativa de durao) e, por fim, estima-se o custo do projeto. 4.1 Gerncia de Projetos e Medio muito importante observar a estreita relao entre gerncia de projetos e medio. Para acompanhar o andamento do projeto, preciso medir o progresso e comparar com o estimado. Mesmo no planejamento, sobretudo quando se pretende utilizar dados de projetos anteriores, dados de mtricas so muito importantes. No possvel controlar o que no se pode medir e, principalmente, s possvel chegar a boas estimativas com base em dados histricos se dados forem coletados criteriosamente. Assim, as medidas do visibilidade ao estado do projeto, permitindo tanto saber para onde ir no incio do projeto quanto verificar se o rumo est correto, tomando aes corretivas quando necessrio [6]. Mas no basta coletar dados aleatoriamente. Para que possam ser usados eficientemente, esses dados tm de ser arranjados de modo a prover indicadores. Por exemplo, o que se pode dizer a respeito da qualidade de um produto de software que tenha apresentado cinco defeitos depois de implantado? boa? No? Isoladamente, esse dado pouco diz. Neste caso, combinar dados em mtricas uma boa opo. No exemplo anterior, se combinssemos a medida de nmero de defeitos com uma medida de tamanho (tal como linhas de cdigo LOC), teramos uma mtrica (nmero de defeitos por linha de cdigo) capaz de nos dizer bem mais do que os dados isolados. Se agora os cinco defeitos medidos

fossem em um software de 10.000 linha de cdigo, chegar-se-ia ao valor de 0,5 defeito/KLOC. A partir dessa mtrica, comparando-a com indicadores da organizao, a sim poder-se-ia chegar a alguma concluso sobre a qualidade do produto. Em uma abordagem desta natureza, os resultados da medio permitem uma comunicao efetiva com os vrios interessados no desenvolvimento. A falta de mtricas de projeto, por outro lado, prejudica de forma geral o seu acompanhamento, uma vez que pode haver um problema, mas ele no est sendo percebido por aqueles que podem direcionar esforos para a sua soluo. Assim, mtricas tm um importante papel na rpida identificao e correo de problemas ao longo do desenvolvimento do projeto. Com a sua utilizao, fica muito mais fcil justificar e defender as decises tomadas, afinal o gerente de projeto no decidiu apenas com base em seu sentimento e experincia, mas tambm fundamentado na avaliao de indicadores que refletem uma tendncia de comportamento futuro. Essa tendncia no derivada apenas das experincias no projeto corrente, mas tambm de experincias semelhantes de outros projetos da organizao (conhecimento organizacional) e at mesmo de fora dela [6]. No que tange gerncia de projetos, estabelecer classes de projetos e coletar algumas mtricas pode ser bastante importante para apoiar a realizao de estimativas. Por exemplo, se uma organizao tem indicadores para produtividade (tamanho/esforo) e custo (R$/tamanho) para diversas classes de projetos diferentes, possvel, a partir de uma estimativa de tamanho, chegar a estimativas de esforo e custo. Dada a importncia da estimativa de tamanho nessa abordagem, ela , geralmente, a primeira a ser realizada. 4.2 - Estimativa de Tamanho: Ainda que anteriormente o tamanho tenha sido basicamente utilizado para normalizar indicadores de produtividade, custo e qualidade, mesmo isoladamente pode ser uma medida importante, como, por exemplo, na contratao de servios de desenvolvimento e manuteno de software. Dois modelos de contratao so bastante difundidos atualmente [6]: preo global fixo e por preo unitrio por homem-hora. No primeiro, um preo total fixo estabelecido por um produto ou servio bem definido. O grande problema desse modelo que, normalmente, alta a probabilidade de haver um aumento do escopo inicialmente previsto. A questo passa a ser: incorporar ou no novos requisitos ao produto? Se a deciso for por incorporar esses requisitos, quem vai pagar a conta? Afinal, aumento do escopo implica em aumento no trabalho a ser realizado. Renegociar contratos nem sempre fcil. Alm disso, as alteraes nos requisitos podem ser muitas (e s vezes pequenas), sendo invivel a realizao de tantas renegociaes. Se a deciso for por no incorporar novos requisitos, o resultado final pode ser ainda mais desastroso: a insatisfao do cliente. No modelo baseado em homem-hora, o risco passa a ser outro. Se a organizao responsvel pelo fornecimento do produto ou servio pouco produtiva, ela no penalizada. Muito pelo contrrio. Ela recebe ainda mais para fazer o mesmo servio [6]. Uma forma alternativa para contratao consiste em uma variao do segundo modelo na qual o preo unitrio pago no mais por homem-hora (uma unidade de esforo), mas por uma unidade de tamanho. Assim, possvel acomodar mudanas no

esforo, mas sem os desvios observados na modalidade por homem-hora. A questo passa a ser, ento, que unidade usar para medir tamanho. Entre as vrias formas de se medir tamanho de um software, uma das mais simples, direta e intuitiva a contagem do nmero de linhas de cdigo (Lines Of Code - LOC) dos programas fonte. Existem alguns estudos que demonstram a alta correlao entre essa mtrica e o tempo necessrio para se desenvolver um sistema. Entretanto, o uso dessa mtrica apresenta vrias desvantagens. Primeiro, verifica-se que ela fortemente ligada tecnologia empregada, sobretudo a linguagem de programao e ao estilo do cdigo escrito. Segundo, pode ser difcil estimar essa grandeza no incio do desenvolvimento, sobretudo se no houver dados histricos relacionados com a linguagem de programao utilizada no projeto. Por fim, essa uma mtrica que pouco significativa para o cliente. Visando possibilitar a realizao de estimativas de tamanho mais cedo no processo de software e sem os problemas de dependncia em relao tecnologia, foram propostas outras mtricas em um nvel de abstrao mais alto. O exemplo mais conhecido a contagem de Pontos de Funo (PFs), que busca medir as funcionalidades do sistema requisitadas e recebidas pelo usurio, de forma independente da tecnologia usada na implementao. 4.3 - Estimativas de Esforo: Para a realizao de estimativas de tempo cronolgico (durao) e custo, fundamental estimar, antes, o esforo necessrio para completar o projeto ou cada uma de suas atividades. Estimativas de esforo podem ser obtidas diretamente pelo julgamento de especialistas, tipicamente usando tcnicas de decomposio, ou podem ser computadas a partir de dados de tamanho ou de dados histricos. Quando as estimativas de esforo so feitas com base apenas no julgamento dos especialistas, uma tabela como a Tabela 1 pode ser utilizada, em que cada clula corresponde ao esforo necessrio para efetuar uma atividade no escopo de um mdulo especfico. Uma tabela como essa pode ser produzida tambm com base em dados histricos de projetos similares j realizados na organizao. Quando estimativas de tamanho so usadas como base, pode-se considerar um fator de produtividade, indicando quanto em unidades de esforo necessrio para completar um projeto (ou mdulo), descrito em unidades de tamanho. Assim, uma organizao pode coletar dados de vrios projetos e estabelecer, por exemplo, quantos em homens-hora (uma unidade de esforo) so necessrios para desenvolver 1000 LOCs (KLOC) ou 1 PF (unidades de tamanho). Esses fatores de produtividade devem levar em conta caractersticas dos projetos e da organizao. Assim, pode ser til ter vrios fatores de produtividade, considerando classes de projetos especficas. Assim como em outras situaes, quando uma organizao no tem ainda dados suficientes para definir seus prprios fatores de produtividade, modelos empricos podem ser usados. Existem diversos modelos que derivam estimativas de esforo a partir de dados de LOC ou PFs.

Por exemplo, o modelo proposto por Bailey-Basili [3] estabelece a seguinte frmula para se obter o esforo necessrio em pessoas-ms para desenvolver um projeto, tomando por base o tamanho do mesmo em KLOC: E = 5,5 + 0,73 * (KLOC)1,16 Outros modelos so apresentados em [3] e [2]. Contudo, deve-se observar que modelos empricos diferentes conduzem a resultados muito diferentes, o que indica que esses modelos devem ser adaptados para as condies da organizao. Uma forma de se fazer essa adaptao consiste em experimentar o modelo usando resultados de projetos j finalizados, comparar os valores obtidos com os dados reais e analisar a eficcia do modelo. Se a concordncia dos resultados no for boa, as constantes do modelo devem ser recalculadas usando dados organizacionais [1]. 3.4.4 - Alocao de Recursos: Estimar os recursos necessrios para realizar o esforo de desenvolvimento outra importante tarefa. Quando falamos em recursos, estamos englobando pessoas, hardware e software. No caso de software, devemos pensar em ferramentas de software, tais como ferramentas CASE ou software de infra-estrutura (p.ex., um sistema operacional), bem como componentes de software a serem reutilizados no desenvolvimento, tais como bibliotecas de interface ou uma camada de persistncia de dados. Em todos os casos (recursos humanos, de hardware e de software), necessrio observar a disponibilidade do recurso. Assim, importante definir a partir de que data o recurso ser necessrio, por quanto tempo ele ser necessrio e qual a quantidade de horas necessrias por dia nesse perodo, o que, para recursos humanos, convencionamos denominar dedicao. Observe que j entramos na estimativa de durao. Assim, alocao de recursos e estimativa de durao so atividades realizadas normalmente em paralelo. No que se refere a recursos humanos, outros fatores tm de ser levados em conta. A competncia para realizar a atividade para a qual est sendo alocado fundamental. Assim, preciso analisar com cuidado as competncias dos membros da equipe para poder realizar a alocao de recursos. Outros fatores, como liderana, relacionamento inter-pessoal etc, importantes para a formao de equipes, so igualmente relevantes para a alocao de recursos humanos a atividades. 4.5 - Estimativa de Durao e Elaborao de Cronograma De posse das estimativas de esforo e realizando em paralelo a alocao de recursos, possvel estimar o tempo cronolgico (durao) de cada atividade e, por conseguinte, do projeto como um todo. Se a estimativa de esforo tiver sido realizada para o projeto como um todo, ento ela dever ser distribuda pelas atividades do projeto. Novamente, dados histricos de projetos j concludos na organizao so uma boa base para se fazer essa distribuio. No entanto, muitas vezes, uma organizao no tem ainda esses dados disponveis. Embora as caractersticas do projeto sejam determinantes para a distribuio do esforo, uma diretriz inicial til consiste em considerar a distribuio mostrada na Tabela 2 [1].

Tabela 2 Distribuio de Esforo pelas Principais Atividades do Processo de Software. Planejamento Especificao e Anlise de Requisitos De 10 a 25% Projeto Implementao Teste e Entrega

At 3%

De 20 a 25%

De 15 a 20%

De 30 a 40%

De posse da distribuio de esforo por atividade e realizando paralelamente a alocao de recursos, pode-se criar uma rede de tarefas com o esforo associado a cada uma das atividades [3]. A partir dessa rede, pode-se estabelecer qual o caminho crtico do projeto, isto , qual o conjunto de atividades que determina a durao do projeto. Um atraso em uma dessas atividades provocar atraso no projeto como um todo. Finalmente, a partir da rede de tarefas, deve-se elaborar um Grfico de Tempo (ou Grfico de Gantt), estabelecendo o cronograma do projeto. Grficos de Tempo podem ser elaborados para o projeto como um todo (cronograma do projeto), para um conjunto de atividades, para um mdulo especfico ou mesmo para um membro da equipe do projeto. 4.6 - Estimativa de Custo De posse das demais estimativas, possvel estimar os custos do projeto. De maneira geral, os seguintes itens devem ser considerados nas estimativas de custos: Custos relativos ao esforo empregado pelos membros da equipe no projeto; Custos de hardware e software (incluindo manuteno); Outros custos relacionados ao projeto, tais como custos de viagens e treinamentos realizados no mbito do projeto; Despesas gerais, incluindo gastos com gua, luz, telefone, pessoal de apoio administrativo, pessoal de suporte etc.

Para a maioria dos projetos, o custo dominante o que se refere ao esforo empregado, juntamente com as despesas gerais. Sommerville [2] sugere que, de modo geral, os custos relacionados com as despesas gerais correspondem a um valor equivalente aos custos relativos ao esforo empregado pelos membros da equipe no projeto. Assim, para efeitos de estimativas de custos, pode-se considerar esses dois itens como sendo um nico, computado em dobro. Custos de hardware e software, ainda que menos influentes, no devem ser desconsiderados, sob pena de provocarem prejuzos para o projeto. Uma forma de tratar esses custos considerar a depreciao com base na vida til do equipamento ou da verso do software utilizada. Quando o custo do projeto estiver sendo calculado como parte de uma proposta para o cliente, ento ser preciso definir o preo cotado. Uma abordagem para definio do

preo pode ser consider-lo como o custo total do projeto mais o lucro. Entretanto, a relao entre o custo do projeto e o preo cotado para o cliente, normalmente, no to simples assim [2].

5 - Gerncia de Riscos
Uma importante tarefa da gerncia de projetos prever os riscos que podem prejudicar o bom andamento do projeto e definir aes a serem tomadas para evitar sua ocorrncia ou, quando no for possvel evitar a ocorrncia, para diminuir seus impactos. Um risco qualquer condio, evento ou problema cuja ocorrncia no certa, mas que pode afetar negativamente o projeto, caso ocorra. Assim, os riscos envolvem duas caractersticas principais: incerteza um risco pode ou no acontecer, isto , no existe nenhum risco 100% provvel; perda se o risco se tornar realidade, conseqncias no desejadas ou perdas acontecero.

Desta forma, de suma importncia que riscos sejam identificados durante um projeto de software, para que aes possam ser planejadas e utilizadas para evitar que um risco se torne real, ou para minimizar seus impactos, caso ele ocorra. Esse o objetivo da Gerncia de Riscos, cujo processo envolve as seguintes atividades:

Identificao de riscos: visa identificar possveis ameaas (riscos) para o projeto, antecipando o que pode dar errado; Anlise de riscos: trata de analisar os riscos identificados, estimando sua probabilidade e impacto (grau de exposio ao risco); Avaliao de riscos: busca priorizar os riscos e estabelecer um ponto de corte, indicando quais riscos sero gerenciados e quais no sero; Planejamento de aes: trata do planejamento das aes a serem tomadas para evitar (aes de mitigao) que um risco ocorra ou para definir o que fazer quando um risco se tornar realidade (aes de contingncia); Elaborao do Plano de Riscos: todos os aspectos envolvidos na gerncia de riscos devem ser documentados em um plano de riscos, indicando os riscos que compem o perfil de riscos do projeto, as avaliaes dos riscos, a definio dos riscos a serem gerenciados e, para esses, as aes para evit-los ou para minimizar seus impactos, caso venham a ocorrer. Monitoramento de riscos: medida que o projeto progride, os riscos tm de ser monitorados para se verificar se os mesmos esto se tornando realidade ou no. Novos riscos podem ser identificados, o grau de exposio de um risco pode mudar e aes podem ter de ser tomadas. Essa atividade realizada durante o acompanhamento do progresso do projeto.

Na identificao de riscos, trabalhar com uma srie de riscos aleatrios pode ser um fator complicador, principalmente em grandes projetos, em que o nmero de riscos

relativamente grande. Assim, a classificao de riscos em categorias de risco, definindo tipos bsicos de riscos, importante para guiar a realizao dessa atividade. Cada organizao deve ter seu prprio conjunto de categorias de riscos. Para efeito de exemplo, podem ser consideradas categorias tais como: tecnologia, pessoal, legal, organizacional, de negcio etc. Uma vez identificados os riscos, deve ser feita uma anlise dos mesmos luz de suas duas principais variveis: a probabilidade do risco se tornar real e o impacto do mesmo, caso ocorra. Na anlise de riscos, o gerente de projeto deve executar quatro atividades bsicas [1]: (i) estabelecer uma escala que reflita a probabilidade de um risco, (ii) avaliar as conseqncias dos riscos, (iii) estimar o impacto do risco no projeto e no produto e (iv) calcular o grau de exposio do risco, que uma medida casando probabilidade e impacto. De maneira geral, escalas para probabilidades e impactos so definidas de forma qualitativa, tais como: probabilidade - alta, mdia ou baixa, e impacto - baixo, mdio, alto ou muito alto. Isso facilita a anlise dos riscos, mas, por outro lado, pode dificultar a avaliao. Assim, a definio de medidas quantitativas para o risco pode ser importante, pois tende a diminuir a subjetividade na avaliao. Jalote [8] prope os valores quantitativos mostrados nas tabelas 3 e 4 para as escalas acima. Tabela 3 - Categorias de Probabilidade [8] Probabilidade Baixa Mdia Alta Faixa de Valores at 30% 30 a 70% acima de 70%

Tabela 4 - Categorias de Impacto [8] Impacto Baixo Mdio Alto Muito Alto Faixa de Valores de 0 a 3 de 3 a 7 de 7 a 9 de 9 a 10

Usando valores quantitativos para expressar probabilidade e impacto, possvel obter um valor numrico para o grau de exposio ao risco, dado por: E(r) = P(r) * I(r), onde E(r) o grau de exposio associado ao risco r e P(r) e I(r) correspondem, respectivamente, aos valores numricos de probabilidade e impacto do risco r. De posse do grau de exposio de cada um dos riscos que compem o perfil de riscos do projeto, pode-se passar avaliao dos mesmos. Uma tabela ordenada pelo grau

de exposio pode ser montada e uma linha de corte nessa tabela estabelecida, indicando quais riscos sero tratados e quais sero desprezados. Para os riscos a serem gerenciados, devem ser definidos planos de ao, estabelecendo aes a serem adotadas para, em primeiro lugar, evitar que os riscos ocorram (aes de mitigao) ou, caso isso no seja possvel, aes para tratar e minimizar seus impactos (aes de contingncia). Esse o propsito da atividade de planejamento das aes. Ao longo de todo o processo da gerncia de riscos, as decises envolvidas devem ser documentadas no plano de riscos. Esse plano servir de base para a atividade de monitoramento dos riscos, quando os riscos tm de ser monitorados para se verificar se os mesmos esto se tornando realidade ou no. Caso estejam se tornando (ou j sejam) uma realidade, deve-se informar que aes foram tomadas. No caso do risco se concretizar, deve-se informar, tambm, quais as conseqncias da sua ocorrncia.

6 - Elaborao do Plano de Projeto

Todas as atividades realizadas no contexto da gerncia de projeto devem ser documentadas em um Plano de Projeto. Cada organizao deve estabelecer um modelo ou padro para a elaborao desse documento, de modo que todos os projetos da organizao contenham as informaes consideradas relevantes.

7 Gerncia de Projetos no PMBOK

Ver no Guia PMBOK [9] as seguintes sees: Seo 1.1 (pgs. 3 e 4) Seo 1.2 (pgs. 5 a 7) Seo 1.3 (pg. 8) Seo 1.4 (pgs. 9 a 11)

Referncias 1. R.S. Pressman, Engenharia de Software, Rio de Janeiro: McGraw Hill, 6 edio, 2006. 2. I. Sommerville, Engenharia de Software, So Paulo: Addison-Wesley, 8 edio, 2008. 3. S.L. Pfleeger, Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2 edio, 2004. 4. M.F. Vieira, Gerenciamento de Projetos de Tecnologia da Informao, Rio de Janeiro : Editora Elsevier Campus, 2003. 5. J.C.C. Martins, Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML, 2 edio revisada, Rio de Janeiro : Brasport, 2005.

6. C.E. Vazquez, G.S. Simes, R.M. Albert, Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software, 3 edio, So Paulo : Editora rica, 2005. 7. C. Hazan. Medio da Qualidade e Produtividade em Software, In: Qualidade e Produtividade em Software, 4 edio, K.C. Weber, A.R.C. Rocha, C.J. Nascimento (organizadores), Makron Books, 2001, p. 25 41. 8. P. Jalote, CMM in Practice: Processes For Executing Software Projects At Infosys, Addison-Wesley Publishing Company, 1999. 9. PMI, Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos Guia PMBOK, 3 edio, 2004.