5

Gerenciamento de projetos

Objetivos
objetivo deste capitulo proporcionar uma viso geral do gerenciamento projetos de software. Depois de ler este capitulo, voc:
Iij

de

conhecer

as principais tarefas

dos gerentes

de projeto

de software;

il compreender por que a natureza do software torna o gerenciamento de projetos de software mais dificil do que o gerenciamento de projetos de outros tipos de engenharia; li descobrir a necessidade do planejamento de projetos em todos os projetos

de software; iI saber como as representaes grficas (diagramas de barras e diagramas de atividades) podem ser usadas pelos gerentes de projeto para representar os cronogramas de projeto;

iIi ter sido apresentado noo de gerenciamento de riscos e alguns dos riscos que podem surgir em projetos de software.

Contedo
5.1 5.2 5.3 5.4 Atividades de gerenciamento Planejamento Cronograma Gerenciamento de projeto do projeto de riscos

o gerenciamento

de projetos de software uma parte essencial da engenharia de software. Um

bom gerenciamento no pode garantir o sucesso de um projeto. No entanto, um mau gerenciamento

geralmente resulta em falha do projeto: o software entregue com atraso, custa mais do que foi

originalmente estimado e falha ao atender seus requisitos.

Os gerentes de software so responsveis pejo desenvolvimento de planos e cronogramas do projeto. Eles supervisionam o trabalho para assegurar que ele esteja scndo realizado dentro dos
padres exigidos e monitoram o progresso para verificar se o desenvolvimento est no prazo e

dentro do oramento. O gerenciamento de projetos de software necessrio, pois a engenharia de software profissional est sempre sujeita s restries de oramento e de cronograma da organizao. O trabalho do gerenlc de projeto de software assegurar que o projeto de sotlware atenda a essas restries e entregue um software que contribua para as metas da empresa que est desenvolvendo o software.

62

11 Engenharia de software

Os gerentes de software fazem o mesmo tipo de trabalho quc os gerentcs de projeto dc outras reas da engenharia. No entanto. a engenharia de software diferente de outros tipo!lo de engenharia em uma srie de maneiras. Essas distines

tornam o gerenciamento de software particularmente difcil. Algumas das diferenas so: I. O produto
inlllllgvel.

O gerente de um projeto de constru,!o de um navio ou de um projeto de engenharia civil

pode VCf o produto que est sendo construdo. Se u cronograma atrasa, o efeitu sobre o produto visvel - partes da estrutura estaro. obviamente. no concludas. O software intangvel. No pode ser visto ou locado. Os gerentes de projetos de software no podem ver o progresso. Eles COlHam com outras pessoas para produzir a documentao

Ilc<.:cssria para examinar o progresso.

2. Nl1u existem processoJ-padro de software. Em reas da engenharia l:om um longo histrico.
O

processo experimen

(aoo e testado. O processo de engenharia de alguns tipos de "i~tema. como pontes e prdios. bem compreendido. No entanto. os processos de software variam drasticamente de uma organizao para outm. Embora nossa compreenso desses processos tenha se desenvolvido de modo significativo nos ltimos anos. ainda no podemos prever, confiavelmente. quando determinado processo de software provavelmente apresentar problemas de desenvolvimento. Isso esptxialmellle verdadeiro quando o projeto de software parte de um projeto mais amplo de engenharia de sistemas.
3. Proj(~lUSde sojllmre de gmlldr porte slio, jrrqiiell1emf1llte, projetos nico",. Projetos de software de grande porte so geralmente diferentes. de alguma forma. de projetos anteriores. Portanto, mesmo os gerentes que tm uma grande experincia pockm considerar dil"cil prever problemas. Alm disso, as rpidas mudanas de tecnologia em computadores e comunicaes podem tomar a experincia do gerente obsoleta. As lies aprendidas em projetos anteriores podem no ser aproveitadas em novos projetos.

Devido a esses problcmas. no dc surpreender que alguns projctos de software atrasem. ultrapassem o oramento e estejam fora do cronograma. Os sistemas de software so freqUentemente novos e tecnologicamente inovadores. Os projetos inovadores de engenharia (como novos sistemas de transporte), frcqentemente apresentam tambm problemas de cronograma. Em face das dificuldades envolvidas. surpreendente que tantos projetos de software sejam entregues no prazo e dentro do oramento! O gerenciamento de projetos de software um assunto amplo e no pode ser abordado apenas em um nico captulo. Portanto, apresento simplesmente uma introduo do assunto neste captulo e descrevo trs atividades importantes de gerenciamento: planejamento de projeto, desenvolvimento de cronograma de projeto e gerenciamento de riscos. Os caplu~ los posteriores (na Parte 6)' abordaro outros aspectos do gerenciamento de software. incluiodo gerenciamento de pessoas. estimativa de custos de software e gerenciamento de qualidade.

5.1

Atividades

de gerenciamento

impossvel fornecer uma descrio de trabalho-padro para um gerente de software. O trabalho varia muito. dependendo da organizao e do produto de software que est sendo desenvolvido. No entanto, a maioria dos gerentes assume a responsabilidade, em algum estgio. por algumas ou todas as seguintes atividadcs:
III lIl lIl

Elaborao da proposta Planejamento e desenvolvimento Custo do projeto e rcvises do projeto do cronograma do projeto

Iii Monitorao

Iii Seleo e avaliao de pessoal Iij Elaborao de relatrios e apresentaes O primeiro estgio de um projeto de software pode envolvcr a elaborao de uma proposta para obter um contrato para realizar o trabalho. A proposta descreve os objetivos do projeto e como ele ser realizado. Geralmente inclui a estimativa de custos e de cronograma e justitica por que o contrato deve ser concedido a detcrminada organizao ou equipe. A elaborao da proposta uma tarefa crtica, pois a existocia de muitas organizaes de software depende da existncia de um nmero suficiente de propostas aceitas e contratos concedidos. Pode oo haver diretrizes definidas para essa tarefa; a elaborao da proposta uma habilidade adqoirida pela prtica c pela experincia. O planejamento de projeto est relacionado identificao das atividades. marcos e produtos gerados por um projeto. elaborado um plano para guiar o desenvolvimento em direo aos objetivos do projeto. A estimativa de custos uma atividade relacionada estimativa dos recursos necessrios para realizar o plano do projeto. Abordo esses itens mais delaIhadamente neste captulo e no Captulo 26.

Capitulo

ii

Gerenciamento

de projetos

63

A monitorao do projeto uma atividade conlinua. O gerente deve maUler o acompanhamento

do progresso do projeto

e comparar o progresso com os custos reais e planejados. Embora a maioria das organizaes possua mecanismos formais
para monitorao, um gerente experienle pode fornecer um quadro mais ntido do que est acontecendo por meio de discusses informais com a equipe do projelo. A monitorao informal pode prever problemas pOleneiais do projeto, revelando dificuldades medida que elas ocorrem. Por exemplo, discusses dirias com a equipe do projelo podem revelar um problema especfico ao localizar algum defeilo de software. Em vez de aguardar que um atraso no cronograma seja relatado. o gerente de software poderia designar algum especialista para o problema ou pode propor uma alternativa de programao. Durante um projeto, normal que ocorram uma srie de revises formais de gerem:iamemo do projeto. Elas esto

relacionadas reviso geral do progresso c desenvolvimento tcnico do projeto e verificao se o projeto c as metas da organizao que est financiando o software ainda esto alinhados.
O resultado de uma reviso pode levar deciso de cancelamento de-um projeto. O tcmpo de desenvolvimento de um projeto de software de grande porte pode ser dc vrios anos. Duranle csse perodo, quase ccrto que ocorram mudanas nos objetivos da organizao. Essas mudanas podem significar que o software no mais necessrio ou que os requisitos originais de projeto no so apropriados. A gerncia deve decidir pela inlerrupo do desenvolvimento do software ou allerar o projeto para acomodar as mudanas nos objctivos da organizao. Os gerentes geralmente precisam selecionar pessoas para irabalhar em seus projetos. O ideal que haja o pessoal habilitado com experincia adequada disponvel para trabalhar no projeto. No entanto, na maioria dos casos, os gerentes precisam aceitar uma equipe de projeto aqum do considerado ideal. As razes para isso so: I. O oramento do projeto pode no ser suficiente para Contratar uma equipe muito bem remunerada. Pude ser necessrio contratar uma equipe menos experiente e que aceite uma remunerao menor. 2. Uma equipe com experincia adequada pode no estar disponvel na organizao ou cxtemamenle, Pode ser impossvel recrutar uma nova equipe para o projeto. Dentro da organizao, as pessoasmais indicadas j podem estar alocadas em outros projetos. 3. A organizao pode querer desenvolver as habilidades de seus funcionrios. Uma equipe inexperiente pode ser designada a um projeto a fim de aprender e ganhar experincia. O gerente de software precisa Irabalhar dentro dessas restries ao selecionar a equipe de projeto. Mas provavelmente ocorrero problemas, a menos que pelo mcnos um membro do projeto tenba alguma experincia com o tipo do sistema a ser desenvolvido. Sem essa experincia, muitos erros simples podero ser cometidos. Explico a montagem da equipe e a seleo do pessoal no Captulo 25. Os gerentes de projcto so geralmente responsveis pela preparao de relatrios sobre o projeto para o cliente e para as organizaes contratantes. Eles devem redigir documentos concisos e coerentes que resumam as informaes fundamentais com base em relatrios detalhados do projeto. Devem estar aptos a apresentar essas informaes durante as reviscs do progresso. Conseqentemente, se voc for um gerente de projeto, dever ser capaz de se comunicar eficientemente de forma verbal e escrita.

5.2

Planejamento

de projeto

O gerenciamento eficiente de um projeto dc software depende dc um planejamento minucioso do progresso do projeto. Os gerentes devem prever os problemas que podem ocorrer e preparar solues experimcnlais para esses problemas. Um plano elaborado no incio de um projcto deve ser usado como guia. Esse plano inicial deve ser o mel bar possvel em facc das informaes disponveis. Ele deve evoluir medida que o projeto progride e melhores informaes se tomem disponveis. A estrutura de um plano de desenvolvimento de software descri la na Seo 5.2.1. Assim como UIl1plano de projeto, os gerentes podem tambm precisar elaborar outros tipos de planos. Eles so descritos brevemente na Tabela 5.1 e abordados mais detalhadamcnte em um captulo relcvante em outra parte no livro. O pseudocdigo apresentado na Figura 5.1 estabelece um processo dc planejamento de projeto para desenvolvimento de software. Ele mostra que o planejamento um processo iterativo, apenas concludo quando o prprio projeto concludo. medida que as infomlaes se tornam disponveis durante o projeto, o plano deve ser regularmente revisado. As metas da empresa constituem um importante fator que deve ser considerado na formulao do plano do projeto. medida que essas meta, mudam, a, metas do projeto tambm mudam e, portanto, so necessrias mudanas no plano do projeto. No incio dc um processo de planejamento, voc deve avaliar as restries (data de entrega definida, pessoal disponvel, oramento geral etc.) que afetam o projeto. Junto com isso, voc deve estimar os parmetros do projeto, como sua estrutura,

64

Engenharia

de software

Tabela 5.1 Tipos de planos Plano , Pla,no~~ quali9ade Plano de'validaao Plano de gerenciamento de (onfiguraAo
Plano de manuteno

Descrio , Descreveos procedimentose os padroes de qualidade usados no projeto. Vejao Capltul,?27.

Oescrevea abordagem, os recursos e o cronogram usados para a valida.1o do sistema. Veja o

Capitulo22. o Capitulo 29:

Descreye os procedimentos e as estruturas de g;renciamenta de configuraao a serem usados. Veja "

Prevos requisitos de manuteno do sjstema, os rostos de manuten~o e o esforo necessrio.

Vejao Capitulo24.
Piano de desenvolvimento
Descreve como as habilidades e a experincia dos membros da equipe de profeto serAo

de pessoal

desenvolvidas.Vejao Capitulo25.

Figura 5.1
Planejamento do prOJeto.

Defina as restries do projeto Faa a avaliao inicial dos parmetros do projeto Defina os marcos do projeto e os produtos a serem entregues while projeto no foi concludo ou cancelado (oop Elabore um cronograma do projeto Inicie as atividades d~' acordo (om o cronograma

,Aguarde (por um ,perodo)

Examine o progresso do projeto Revis'eas estimati~as de parmetros do projeto Atualize o cronograma do projeto Renegocie as restries do projeto e os produtos a serem entregues

if (surgirem problemas) then

Inicie reviso tcnica e possvel nova reviso

end if end loop

tamanho e distribuio das funes. Em seguida. vo define os marcos de progresso e os produtos a serem entregues. O processo. ento. entra em um loop. Deve ser elaborado um cronogr: . IIna estimado para o projeto e as atividades definidas no cronograma so iniciadas ou liberadas para prosseguimento. Depois de algum tempo (geralmente cerca de duas ou trs semanas), voc deve examinar o progresso e anotar as discrepncias em relao ao cronograma. Devido s estimativas iniciais dos parmetros do projeto serem experimentais. sempre sed necessrio modificar o plano original. medida que as informaes se tornam disponveis, voc deve revisar as hipteses originais e o cronograma do projeto. Se o projeto estiver atrasado. pode ser necess<rio renegociar as restries e os produtos a serem entregues com o cliente. Se essa renegociao no for bem-sucedida e o cronograma no puder ser cumprido, uma reviso tcnica pode ser considerada. O objetivo dessa revi~o encontrar uma abordagem alternativa que se limite s re~tries do projeto e cumpra o cronograma. Naturalmente, voc no deve contar com o fato de que tudo correr bem. Problemas de alguma natureza quase sempre surgem durante o projeto. Suas hipteses e cronograma iniciais devem ser pessimistas em vez de otimistas. Deve existir contingncia suficiente no plano, de modo que 'IS restrics e os marcos do projeto no precisem ser renegociados o tempo

todo no loop de planejamento.

5.2.1

-------

O plano de projeto
----

o plano

de pmjeto estabelece os recursos disponveis para

pmjcto, a estrutura analtica dn pmjeto e um (m-

nograma para realizar o trabalho. Em algumas organizaes, o plano de projeto um nico documento que inclui diferentes tipos de planos (Tabela 5.1). Em outms c",os, o plano de pmjeto est relacionado apenas ao processo de desenvolvimento. As referncias a outros planos esto includas, mas os planos so separados entre si. A estrutura de plano que descrevo neste livm adequada ao ltimo tipo de plano. Os detalhes do plano de pmjeto vadam

dependendo do tipo do pmjeto e da organizao. No entanto, a maioria dos planos deve incluir as seguintes sees:
I. IllIroduo. Descreve brevemente os objetivos do pmjeto e estabelece as restries (por exemplo, a<amenlo, prazo etc.) que afetam o gerenciamenro do projeto.

Capitulo

Gerenciamento

de projetos

65

2. Organizao do projeto. Descreve o modo como a equipe de de-senvolvimcnto est organizada. as pessoas envolvidas e seus papis na equipe.

3. Anlise de riscos. Descreve os possveis riscos do projeto. a probabilidade da ocorrncia desses riscos c as propostas
de estratgias de reduo de riscos. Explico os princpios de gerenciamento de riscos na Seo 5.4.

4. Requisitos de recursos de hardware e de software. Especificam o hardware e o software de apoio necessrios para
realizar o desenvolvimento. prazo de entrcga. Se o hardware precisar ser comprado, podem ser includas as estimarivas de preos e u

5.

ESlrllrurll llnaltica. Estabelece a estrutura analtica do projeto em atividades e identifica os marcos e os produtos a serem cntregues com cada atividade. Os marcos e os produtos a serem entregues so explicadus na Seo 5.2.2.

6. Cronograma do projeto. Apresenta as dependncias entre as atividades, o prazo estimado necessrio para atingir cada marco e a alocao de pessoas nas atividades. 7. MecQlIi.wws de I1W!';WrUo e e/u/Jorac1o de relatrios. Definem os relatrios de gerenciamclllo que devem ser produzidos. quando eles devem ser produzidos e os mecanismos de monitorao de projeto usados. Voc deve revisar regularmente o plano durante o projeto. Algumas partes, como O cronograma do projeto. mudaro frcqentemclllc c outras partes sero m<lisestveis. Para simplificar as revises. voc deve organizar o documento em !oiees separadas que podem ser individualmente substitudas medida que o plano evolui.

5.2.2

Marcos e produtos

a serem entregues

Os gerentes precisam de informacs pam realizar seu trabalho. Como o software intangvel. essas informaes podem ser fornecidas apenas como relatrios e documentos que descrevem o estado do software que desenvolvido. Sem essas informaes, impossvel avaliar quo bem o trabalho est progredindo e as estimativas de custos c o cronograma no podem ser atualizados. Ao planejar um projeto, voc deve estabelecer uma srie de 11l1llH'j. Um marco um ponto final reconhecvel de uma atividade do processo de software. A cada marco, deve existir uma sada formal, como um relatrio, que possa ser apresentado gerncia. Os relatrios de marcos no precisam ser documentos extensos. Eles podem ser simples relatrios breves sobre o que foi concludo. Os marcos devem representar o fim de um estgio lgico e distinto do projeto. Marcos indefinidos, COmO'Codificao 80% concluda'. que no podem ser verificados, so inteis para o gerenciamento do projeto. Voc no pode verificar se esse estado foi alcanado. pois a quantidade de cdigo que ainda precisa ser desenvolvida incerta. Um produto um resultado de projeto entregue ao cliente. geralmente disponibilizado no fim de alguma fase importante do projeto, como especificao ou designo Os produtos so geralmente marcos, mas marcos no precisam ser produtos. Os marcos podem ser resultados internos do projeto usados pelo gerente do projeto para verificar o progresso, embora no sejam entregues ao cliente. Para estabelecer os marcos, o processo de software deve ser decomposto em atividades bsicas com sadas associadas. Por exemplo, a Figura 5.2 mostra as possveis atividades envolvidas na especificao de requisitos. quando a prulUtipao usada para ajudar a validar os requisitos. Os marcos, neste caso. correspondem finalizao das sadas de cada atividade. Os produtos do projeto entregues ao cliente so a definio e a especificao de requisitos.

Figura 5.2

Marcos no processo de requisitos.

Estudo de
viabilidade

ATIVIDADES Estudo de
projeto

Relatrio de viabilidade

Defini<C1o de requisitos

Relatrio de avaliao

Projeto de arquitetura

MARCOS

5.3 Cronograma do projeto

O desenvolvimento do cronograma do projeto um dos trabalhos mais difceis para um gerente de projeto. Os gerentes estimam o tempo e recursos necessrios para concluir atividades, organizando-as em uma seqncia coerente. A

66

11 Engenharia de software

menos que o projeto cujo cronograma est sendo desenvolvido seja similar a um projeto anterior. as estimativas anteriores constituem uma base incerta para o desenvolvimento do cronograma do novo projeto. A estimativa de cronograma mais complicada pelo falO de que projeto, diferentes podem u,ar mtodo, e linguagens de implementao diferentes. Se o projeto for tecnicamente avanado, as estimativas iniciais certamente sero otimistas, mesmo quando todas as eventualidades so levadas em conta. Nesse sentido. o desenvolvimento do cronograma de software no diferente de nenhum outro tipo de projeto avan<;ado de grande porte. Uma nova aeronave, pontes e mesmo novos modelos de 3ulOm veis freqentemente sofrem atrasos devido a problemas no previstos. Os cronogramas. portanto, devem ser continuamente atualizados medida que mais informaes sobre o progresso se (Ornem disponveis. O desenvolvimento do cronograma de projelo (Figura 5.3) envolve a diviso do trabalho total de um projelo em alividades separadas e a avaliao do tempo necess:.rio para completar essas atividades. Em geral. algumas das atividades so realizadas simultaneamente. Voc deve coordenar as atividades paralelas e organizar o trabalho de modo que a fora de trabalho seja usada de maneira otimizada. importante evitar uma situao em que todo o projeto fique atrasi.ldo devido ao fato de a tarefa crtica no estar concluda. As atividi.ldcs de projeto devem durar pelo menos uma semana. Uma subdiviso mais detalhada significa que urna quantidade desproporcional de tempo deve ser despendida na estimativa e na reviso de diagramas. tambm til estabelecer uma quamidi.lde mxima de tempo para qualquer atividade de aproximadamente 8 a 10 semanas. Se ela levar mais tempo que isso, dever ser subdividida para planejamento c desenvolvimento do cronograma de projeto. Conforme j sugeri, ao estimar os cronogramas, voc no deve considerar que todo o est<gio do projeto estar livre de problema~. As pessoas que trabalham em um projeto podem ficar doentes ou podem sair, o hardware pode apresentar defeilO e o software ou o hardware de apoio essencial pode ser entregue com atraso. Se o projeto for novo e tecnicamente avanado. certas panes do projeto podem se tornar mais difceis e tomar mais tempo do que inicialmente previsto. Alm do calendrio. voc tambm deve prestar ateno aos recursos necessrios para completar cada tarefa. O recursu principal o esforo humano necessrio. Outros recursos podcm ser o espao em disco necessrio no servidor. o tempo necessrio de um hardware especializado. como um simulador. e o oramento para viagens necessrias da equipe de projeto. Explico estimativas mais detalhada mente no Captulo 26. Uma boa regra prtica fazer a estimativa como se nada fosse dar errado e, ento, aumentar a estimativa para cobrir problemas no previstos. Um fator de contingncia adicional para cobrir problemas no previ,tos pode tambm ser acrescentado estimaliva. Esse falor extra de contingncia depende do tipo de projelo, dos parmetros de projelo (prazo final. padre, etc.) e da qualidade c experincia dos engenheiros de software que trabalham no projeto. Adiciono sempre 30% a minha estimativa original para problemas no previstos e, em seguida, mais 20% para cobrir aspectos sobre os quais no tinha pensado. Os cronogramas de projeto so geralmente representados como um conjunto de diagramas que apresentam a estrutura analtica do projeto. as dependncias de atividades c as alocacs de pessoal. Descrevo esses diagramas na seo seguinte. A, ferramenta> de gerenciamento de projeto. como o Microsoft Projecl. so geralmente udas para automatizar a produo de diagramas.

5.3.1

Diagramas

de barras

e redes de atividades

Os diagramas de barras e as redes de atividades so notaes grficas usadas para ilustrar o cronograma do projeto. O, diagramas de barra> moslram quem respon,vel por cada atividade e quando a> atividades esto programada> para ,erem iniciadas e terminadas. As redes de alividade, mostram., dependncias entre a, diferentes atividades que con,tituem um projeto. Os diagramas de barras e os diagramas de atividades podem ser gerados automaticamente baseados em um banco de dados de informaes do projeto, usando uma ferramenta de gerenciamento de projetos. Para ilustrar como os diagramas so usados, criei um conjunto hipottico de atividades, conforme apresentado na Tabela 5.2. Essa tabela mostra as atividades. sua durao e as respecliva, interdependncias. Ao ob,ervar a Tabela 5.2. voc pode

Figura 5.3
Processo de desenvolvimento

do cronograma do projeto.
Identificar atividades Identificar dependncias entre atividades Estimar recursos para atIVIdades Alocar pessoas para atividades Criar diagramas de projeto

Requisitos de software

Diagramas de atividades e diagramas de barras

Captulo Tabela 5.2 Tarefa

Tl T2 B T4 T5 T6 T7 T8 T9 TlO Tl1 Tl2

11

Gerenciamento

de projetos

67

Duraes e dependncias de tarefas Durao (dias) 8

15 15 10 10 5 20 25 15 15 7 la T2. T4 (M2) Tl. T2 (M3) Tl(M1) T4 (MS) B. T6 (M4) T5. T7 (M7) T9 (M6) Tll (M8) Tl (M1)

Dependncias

constatar que a atividade n dependente da atividade TI. Isso significa que T1 deve ser terminada antes do incio de T3. Por exemplo, T I pode ser a preparao de um projeto de componente e n, a implementao desse projeto. Antes do incio da implementao, o projeto do componente deve estar concludo. Em face das dependncias e das duraes estimadas das atividades, um diagrama de atividades pode ser gerado (Figura 5.4). Ele mostra quais atividades podem ser realizadas simultaneamente e quais devem ser executadas em seqncia devido a uma dependncia da atividade anterior. As atividades so representadas por retngulos; os marcos e os produtos a serem entregues so apresentados por retngulos de cantos arredondados. As datas desse diagrama mostram a data de incio da atividade. Voc deve ler o diagrama da esquerda para a direita e de cima para baix.o. Na ferramenta de gerenciamento de projeto usada para produzir esse diagrama, todas as atividades devem terminar nos marcos. Uma atividade pode ser iniciada quando seu marco precedente (que pode depender de vrias atividades) for atingido. Ponanto, a terceira coluna da Tabela 5.2 mostra O marco correspondente (por exemplo, M5) alcanado quando as tarefas terminam (veja a Figura 5.4). Antes de passar de um marco para outro, todos os caminhos que levam para ele precisam estar completos. Por exemplo. quando as atividades T3 e T6 forem terminadas, ento a atividade T9, mostrada na Figura 5.4, pode comear. O tempo mnimo necessrio para terminar O projeto pode ser estimado considerando-se O caminho mais longo no grfico de atividades (o caminho principal). Neste caso, isso corresponde a II semanas de tempo decorrido ou 55 dias trabalhados. Na Figura 5.4, o caminho principal mostrado como uma seqncia de caixas com contorno em negrito. O caminho principal a seqncia de atividades dependentes que define o tempo necessrio para concluir o projeto. O cronograma geral do projeto depende do caminho principal. Qualquer atraso no tnnino de qualquer atividade principal causa atrasos no projeto,

porque as atividades seguintes no podem ser iniciadas at que a atividade em atraso tenha sido terminada. Contudo, os atrasos nas atividades que no esto no caminho principal no causam necessariamente atraso geral no cronograma. Desde que esses atrasos no estendam as atividades de modo que o tempo total para a atividade mais as atividades futuras dependentes no excedam o caminho principal, o cronograma do projeto no ser afetado. Por exemplo, se T8 estiver atrasada por duas semanas, ela no ir afetar a data final de trmino do projeto, pois no est no caminho principal. A maioria das ferramentas de gerenciamento de projetos calcula os atrasos permitidos, conforme mostrado no diagrama de barras do projeto. Os gcrentes tambm usam os diagramas de atividades ao alocar o trabalho de projeto. Eles podem fornecer esclarecimentos sobre as dependncias de atividades quc no sejam bvias. Pode ser possvel modificar o projeto de sistema de modo que o caminho principal se tome mais cuno. O cronograma de projeto pode se tomar mais cuno por causa da reduo do tempo gasto que aguarda o trmino das atividades. Inevitavelmente, os cronogramas iniciais de projeto sero incorretos. medida que o projeto avana, as estimativas devem ser comparadas com o tempo real decorrido. Essa comparao pode ser usada como base para reviso de cronograma para as panes posteriores do projeto. Quando os valores reais so conhecidos, o diagrama de atividades deve ser revisado. As atividades posteriores de projeto podero, depois, ser reorganizadas para reduzir a extenso do caminho principal.

68

11

Engenharia

de software

figura

5.4

1417103

15 dias

Processo de desenvolvimento do cronograma do projeto.

A Figura 5.5 lima maneira complementar de representao de infonnaes de cronograma do projeto. um diagrama de barras que mostra um calendrio de projeto e as datas de incio e fim das atividades. s vezes chal1l3do de diagramas de Gantl, em homenagem a seu inventor. Ao ser lido da esquerda para a direita, o diagrama de barras mostra daramente quando uma atividade comea e (emuna. Algumas das atividades mostradas no diagrama de bmrus da Figura 5.5 so seguidas por uma barra sombreada cujo comprimento calculado pela ferramenta de cronograma. Ela demonstra a flexibilidade da data de trmino das atividades. Se uma atividade no for concluda em tempo. o caminho principal no ser afetado at o fim do perodo indicado pela barra sombreada. As atividades no caminho principal no tm margem de erro e so identificadas por no possurem barras sombreadas associadas.

figura

5.5
4f7 1117 Incio T4 T1 12 Ml. 171 13 M5 T8 18/7 2517 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Diagrama de barras de atividades.

I
I
t

M3 M2 ~ T6 T5 .M4 T9 t M7 f TIO I

,
~
I I

J
Til

I
.M6

I
M8 T12

r.m

Capitulo 5 11 Gerenciamentode projetos

Figura 5.6 AlocaM de pessoal versus diagrama de tempo.
Fred

69

4f7 T4

lln
I

1817

25n

118

818

,5/8

2218

2918

5/9

12/9

19/9

T8

1T11 T12

Jane

T1 Tl T9

I
IT10

Anne

T2

Jim

T6

In
I

I
T5
I

Mary

Alm de considerar os cronogramas. os gerentes de projeto tambm precisam considerar a alocao de recursos e. em particular, a alocao de pessoal s atividades do projeto. Essa alocao pode tambm ser a entrada para as ferramentas de gerenciamento de projetos e para um diagrama de barras que mostre quando o pessoal designado ao projeto (Figura 5.6). As pessoas no precisam estar designadas a um projeto durante todo o tempo. Em alguns perodos, elas podem estar em frias, trabalhando em outros projetos, passando por cursos de treinamento ou realizando alguma outra atividade. Grandes organizaes geralmente empregam uma srie de especialistas que trabalham em um projeto. se necessrio. Na Figura 5.6, observe que Mary e Jim so especialistas que trabalham somente em uma nica tarefa no projeto. Isso pode causar problemas no cronograma. Se um projeto atrasa enquanto um especialista est trabalhando nele, isso poder ter efeito prejudicial sobre os outros projetos. Pode tambm haver atrasos porque o especialista no est disponvel.

5.4

Gerenciamento

de riscos

o gerenciamento de riscos est sendo considerado, cada vez mais, como uma da') principais atividades dos gerentes de projeto. Ele consiste em prever os riscos que podem afetar o cronograma do projeto ou a qualidade do software que est sendo desenvolvido e tomar providncias para evitar esses riscos (Hall, 1998) (Ould, 1999). Os resultados da anlise de riscos devem ser documentados no plano de projeto junto com uma anlise das conseqncias de uma ocorrncia de risco. Um gerenciamento eficiente de riscos toma mais fcil lidar com os problemas e assegurar que eles no conduziro a um oramento inaceitvel ou atraso no cronograma. De fonna simplificada, voc pode pensar em risco como algo que seria prefervel no ocorrer. Os riscos podem ameaar o projeto, o software que est sendo desenvolvido ou a organizao. Existem, pcrtanto, trs categorias de risco relacionadas:
I. Riscos de projeto so aqueles que afetam o cronograma ou os recursos de projeto. Um exemplo pode ser a perda de um projetista experiente.

2. Riscos de produto so aqueles que afetam a qualidade ou o desempenho do software que est sendo desenvolvido.
Um exemplo pode ser um componente comprado no funcionar conforme e~perado.

3. Riscos de negcio so aqueles que afetam a organizao que desenvolve ou adquire o software. Por exemplo, um
concorrente que lana um produto um risco de negcio. Naturalmente, esses tipcs de risco se sobrepem. Se um programador experiente deixa um projeto, isso pode ser um risco de projeto, pois a entrega do sistema pode atrasar. Pode tambm ser um risco de produto, pois um substituto pode no ser to experiente e, ento, pode cometer erros de programao. Finalmente, pode ser um risco de negcio, pois a experincia do programador no est disponvel para ser oferecida em negcios futuros. Os riscos que podem afetar um projeto dependem do projeto e do ambiente organizacional onde o software est sendo desenvolvido. No entanto, muitos riscos so universais. Alguns dos riscos mais comuns so mostrados na Tabela 5.3. O gerenciamento de riscos particularmente importante para projetos de software, devido s incertezas inerentes maioria dos projetos. Ela, se originam de requisitos mal definidos, dificuldades na estimativa de prazo e recursos necessrios para o desenvolvimento de software, dependncia de habilidades individuais e mudanas de requisitos devido s mudanas nas necessidades do cliente. Voc precisa prever os riscos, compreender o impacto desses riscos no projeto, no produto e nos

70

11I Engenharia

de software

Tabela 5.3 Risco

Possve,s riscos de software Tipo de risco Projeto Projeto Projeto

Projeto e produto

Descrio Pessoalexperiente deixar~o projeto antes do seu trmino.

Haver uma mudana na gerncia da organiza~o com

ROlatividade pessoal de Mudana de gerncia

Indisponibilidade de hardware

diferentes prioridades.

o hardware
prazo.
previsto.

essencial ao projeto no ser entregue dentro do

Mudana de requisitos

Haver um nmero maior de mudanas de requisitos do que o

Atrasos de especifica3a

Projeto e produto

As espedficaes das interfaces essenciais nAo estafA0 disponfveis dentro do prazo. O tamanho do sistema foi subestimado. As ferramentas CASE que apiam o projeto no funcionam conforme previsto. A tecnologia sobre a qual o sistema foi construido foi superada por uma nova tecnologia. Um produto concorrente foi lanado no mercado antes da condusao do sistema.

Tamanho subestimado

Projetoe produto
Produto

Baixo desempenho da ferramenta CASE Mudana de tecnologia

Concorrncia de produto

Negcios Negcios

negcios, e tomar providncias para evitar esses riscos. Pode ser necessrio elaborar planos de contingncia, de modo a poder tomar providncias imediatas para recuperao, caso os riscos ocorram.
O processo de gerenciamento de riscos est ilustrado na Figura 5.7. Ele envolve vrios estgios: I. Idelltificao de riscos. Os riscos possveis de projeto, de produto e de negcios so identificados. 2. Anlise de riscos. A probabilidade e as conseqncia ..desses riscos so avaliadas. 3. Planejamellto de riscos. So elaborados planos para cuidar dos riscos seja evitando-os ou minimizando seus efeitos no projeto. 4. Monitorao de riscos. Os riscos so constantemente avaliados e os planos para mitigao de riscos so revisados medida que mais informaes se tomam disponveis. O processo de gerenciamento de riscos, como todos os outros planejamentos de projeto. um processo iterativo que prossegue ao longo do projeto. Uma vez elaborado um conjunto inicial de planos, a situao monitorada. medida que

mais informaes sobre os riscos se tomarem disponveis, os riscos devero ser analisados novamente e novas prioridades
devero ser estabelecidas. Os planos de preveno de riscos e de contingncia podem ser modificados medida quc novas infonnaes de risco surgirem.

Voc deve documentar os resultados do processo de gerenciamento de riscos em um plano de gerenciamento de riscos.
Esse plano deve incluir uma explicao dos riscos enfrentados pelo projeto, uma anlise desses riscos e os planos necessrios para gerenciar esses riscos. Quando apropriado, voc tambm deve incluir no plano os resultados do processo de gerencia-

mento de riscos, como planos de contingncia especficos a serem ativados caso o risco venha a ocorrer.
Figura 5.7 Processo de gerenciamento
de riscos. Identificao de riscos Anlise de riscos Planejamento de riscos Monitorao de riscos

Lista de riscos potenciais

lista de riscos priorizados

Planos de preveno de riscos e de contingncia

Avalia~o
de riscos

Capitulo 5

lIi Gerenciamento

de projetos

71

5.4.1

Identificao

de riscos

A identificao de riscos o primeiro estgio do gerenciamento de riscos. Ela est relacionada com a descoberta dos possveis riscos do projeto. Em princpio, os riscos no devem ser avaliados ou priorizados neste estgio, embora, na prtica, riscos com conseqncias muito pequenas ou com muito pouca probabilidade de ocorrncia no sejam normalmente considerados. A identificao de riscos pode ser realizada como um processo em equipe, usando uma abordagem de brainstorrning, ou simplesmente ser baseada na experincia. Para auxiliar o processo, um checklist de diferentes tipos de risco pode ser
usado. Existem, pelo menos, seis tipos de risco que podem surgir:

I. RiSCaI de recllologia. So aqueles que derivam de tecnologias de software ou hardware usadas para desenvolver o
sistema.

So aqueles associados s pessoas da equipe de desenvolvimento. 3. Riscos organizacionais. So aqueles que derivam do ambiente organizacional no qual o software est sendo desenvolvido. 4. RiICOS de ferramelltas. So aqueles que derivam de ferramentas CASE e outros softwares de apoio. usados para
2. Riscos de pelloa/. desenvolver o sistema.

5. Riscos de requisitos. So aqueles que derivam de mudanas de requisitos de cliente e do processo de gerenciamento de mudana de requisitos. 6. Riscos de estimatil'as. So aqueles que derivam de estimativas de gerenciamento das caractersticas de sistema e
estimativas de recursos necessrios para construir o sistema.

A Tabela 5.4 apresenta alguns exemplos dos possveis riscos em cada uma dessas categorias. Aps concluir o processo de identificao de riscos, voc dever ter uma longa lista de riscos que podem ocorrer e quais podem afetar o produto, o processo e os negcios.

5.4.2

Anlise de riscos

Durante o processo de anlise de riscos, voc precisa considerar cada risco identificado e fazer uma avaliao de sua probabilidade e seriedade. No existe uma maneira fcil de fazer isso - voc deve contar com sua prpria avaliao
e experincia, o que faz com que gerentes de projetos experientes sejam as melhores pessoas para auxiliar no gerenciamento de riscos. Essas estimativas de risco geralmente no precisam ser avaliaes numricas precisas. mas devem basear-se em um nmero de faixas:

III A probabilidade do risco deve ser avaliada como muito baixa 10%), baixa (l()"'25%), mdia (25-50%), alta (5()"'75%) ou muito alta (>75%). lIi Os efeitos do risco podem ser avaliados como catastrficos, srios, tolerveis ou insignificantes. Tabela 5.4 Riscose tipos de risco. Tipo de risco Tecnologia
Pessol

Riscos possveis o banco de dados usado no sistema no pode processartantas transaoes por se<Jundocomo esperado.
Os componentes de software que devem ser reusados contm defeitos que limitam sua funcionalidade.

f imposslvelrecrutar pessoal com as habilidadesnecessrias.

O pessoal mais qualificado est doente e nao disporifvel nos momentos criticas.

O treinamento necessario para o pessoal no esta disponlvel.

Organizacional
Ferramentas

A organizao reestruturada, de modo que uma gerncia diferente tornou-se responsavelpelo projeto. Problemasfinanceirosda organizao foram redues no oramento do projeto. O cdigo gerado pelas ferramentas CASE ineficiente. As ferramentas CASE no podem ser inte<Jradas. Mudanas de requisitosque requerem retrabalho maior de projeto so propostas. Os clientes no compreendem o impacto das mudanas de requisitos. O prazo necessario para desenvolvero software foi subestimado. A taxa de reparo de defeitos foi subestimada. O tamanho do software foi subestimado.
.',

Requisitos Estimativas

r
72 li Engenharia de software

Voc deve, portanto, computar os resultados desse processo de anlise usando uma labela ordenada de acordo com a gravidade do risco. A Tabela 5.5 ilustra isso em relao aos riscos identificados na Figura 5.4. Obviamente, a avaliao de probabilidade e de seriedade arbitrria neste caso. Na prtica, para fazer essa avaliao. voc precisa de informaes detalhadas sobre o projelo, o processo, a equipe de desenvolvimento e a organizao. Naturalmente, tanto a probabilidade quanto a avaliao dos efeitos de um risco podem mudar medida que mais informaes sobre o risco tomam-se disponveis e quando os planos de gerenciamento de riscos so implantados. Portanto, essa tabela deve ser atualizada aps cada iterao do processo de gerenciamento de riscos. Aps os riscos terem sido analisado5 e classificados, voc deve avaliar quais so os mais significativos. A avaliao deve depender da combinao da probabilidade da ocorrncia do risco e de seus efeitos. Em geral, riscos catastrficos devem sempre ser considerados, assim como lOdos os riscos srios que tenham probabilidade de ocorrncia acima da mdia.
Boehm (Boehm, 1988) recomenda identificar e monitorar os 'lO maiores' riscos, mas penso que esse nmero um tanto

arbitrrio. O nmero correIo de riscos a serem monitorados depende do projeto. Podem ser 5 ou 15. No entanto. o nmero de riscos selecionados para monitorao deve ser gerencivel. Um nmero muito grande de riscos exigir que muitas informaes sejam coletadas. Com base oos riscos identificados na Tabela 5.5. apropriado considerar todos os 8 riscos com conseqncias catastrficas ou srias.

5.4.3

Planejamento

de riscos

o processo de planejamento de riscos considera cada um dos riscos importantes identificados e define estratgias para gerenci-los. Novamente, no existe um processo simples a ser seguido para definir os planos de gerenciamento de riscos. Ele conta com a avaliao e a experincia do gerente do projeto. A Tabela 5.6 mostra as possveis estratgias identificadas para os riscos principais da Tabela 5.5. Essas estratgias dividem-se em trs categorias:
Seguir essas estratgias significa que a probabilidade de que o risco ocorrer ser reduzida. Um exemplo de uma estratgia de preveno de riscos lidar com componentes defeituosos, como mostrado na Tabela 5.6. 2. Estratgias de minimizao. Seguir essas estratgias significa que o impacto do risco ser reduzido. Um exemplo de estratgia de minimizao de riscos de doena entre o pessoal da equipe como mostrado na Tabela 5.6.
1. ESlraIxias de preveno.

Tabela 5.5 Anlise de riscos Risco

Problemas financeiros da organizao foram reduoes no oramento do projeto.

Probabilidade
Baixa

Efeitos Catastrficos Catastrficos

Srios Srios

~ imposslvelrecrutar pessoal com as habilidadesnecessriaspara o projeto.

Alta Mdia Mdia Mdia Alta Mdia Alta Alta Mdia Mdia Mdia Alta Mdia

o mais qualificado
sua funcionalidade

est~doente

nos momentos crfticos do projeto.

eiS componentes de software que devem ser reusados-<:ontmdefeitos que limitam

~o propostas mudaoas de requisitosque requerem maior retrabalho de projeto.
A organiza~o reestruturada, e uma gerl!ncia diferente tornou-se responsvel pelo projeto. O banco de dados usado no sistema nao pode processar tantas transaOs por segundo como esperado.

Srios

Srios Srios
Srios

O tempo necessrio para desenvolver o software foi subestimado.

As ferramentas CASEno podem ser integradas.

Os clientes no compreendem o impacto das mudanas de requisitos.

Tolerveis Tolerveis Tolerveis Tolerveis Tolerveis

Insignificantes

o treinamento necessrio para o pessoal nao est disponlvel. A taxa de reparo de defeitos foi subestimada.
O tamanho do software foi subestimado.

o cdigo gerado pelas ferramentas CASE ineficiente.

Captulo Tabela 5.6 Estratgias de gerenciamento de Risco Ifr~j,~-mas financeirosda organizaao piobfemas de recrutamento 'Doena do pessoal da equipe cC;mponentescom defeito
. ~'Mudana5 de requisitos

5 ti

Gerenciamento

de projetos

73

fiSCOS

Estratgia Preparar um documento de instrues para a gerncia snior, que mostre como o projeto est contribuindo de maneira muito importante para as metas da empresa, Alertar o cliente sobre as dificuldadespotenciais e a possibilidadede atrasos~investigara
compra de componentes.

Reorganizara equipe de maneira que haja mais superposiao de trabalho e, portanto. as

pessoas compreendam as tarefas uns dos outros. potencialmente defeituosos por componentes comprados Substituir os componentes

de

confiabilidadereconhecida.

Derivar informaes de rastreabilidade para avaliar o impacto das mudanas de requisitos e maximizar o ocultamente de informaes no projeto. Preparar um documento de instru6es para a gerncia snior que mostre (orno o projeto est1 contribuindo de maneira muito importante para as metas da empresa. Verificar a possibilidade de comprar um banco de dados com desempenho melhor. Verificar a compra de componentes e verificar o uso de um gerador de programa.

Reestruturaaoda organizaao Desempenho do banco de dados

Prazo de desenvolvimento subestimado

3. Planos de co1ltingm:ia. Seguir essas estratgias significa que voc est preparado para o pior e tem uma estratgia para lidar com o problema. Um exemplo de estratgia de contingncia a estratgia para problemas financeiros da organizao na Tabela 5.6. Note a analogia com as estratgias usadas em sistemas crticos para assegurar contiabilidade, proteo e segurana. Essencialmente, melhor usar uma estratgia que evite o risco. Se isso no for possvel. use uma estratgia que reduza as chances de que o risco tenha srios efeitos. Finalmente. tenha estratgias que reduzam o impacto geral de ocorrncia de um risco no projeto ou no produto.

5.4.4

Monitorao

de riscos

A monitorao de riscos envolve a avaliao regular de cada um dos riscos identificados para decidir se esse risco est ou no se tomando mais ou menos provvel e se os efeitos do risco mudaram. Naturalmente, isso no pode ser observado diretamente, portanto, necessrio observar outros fatores que forneam indcios a respeito da probabilidade do risco e seus efeitos. Esses fatores so obviamente dependentes dos tipos de risco. A Tabela 5.7 apresema alguns exemplos de fatores que podem ser teis na avaliao desses tipos de risco. A monitorao de riscos deve ser um processo contnuo e, a cada reviso de progresso feita pela gerncia, necessrio considerar e discutir cada um dos principais riscos separadamente. Tabela 5.7 Fatares de risco Indicadores potenciais

Tipo de risco Tecnologia Pessoal

Organizacional Ferramentas

Entrega de hardware ou software de apoio com atraso, muitos problemas de tecnologia relatados. Baixo moral do pessoal, relacionamentos pr~rios entre os membros da equipe, disponibilidade

de emprego.
Boatos na organizao, falta de a30 da gerncia snior. Relutncia dos membros da equipe em usar ferramentas, reclamaes sobre ferramentas CASE,

demandas por estaes de trabalho mais poderosas.

Requisitos Estimativas

Munas solicitaesde mudana de requisitos,reclamaes do cliente.

Falha no cumprimento do cronograma, falha em eliminar defeitos relatados.

74

11 Engenharia

de software

I
PONTOS-CHAVE

___ --_1 -

11 > Um bom gerencial1)ento de projeto de software essencial para que os projetos de engenharia de software sejam desenvolvidos dentro do cronograma e do oramento. 11 O gerenciamento de software diferente do gerenciamento em outras reas da engenharia. O software intanglvel. Os projetos podem ser novos ou inovadores; portanto, no existe um conjunto de experincias para guiar seu gerenciamento. Os processos de software no so bem compreendidos. 11 Os gerentes de software possuem diversos papis. As atividades mais significativas so planejamento, elaborao de estimativas e desenvolvimento de cronograma do projeto. O planejamento e a elaborao de estimativas so processos iterativos. Elescontinuam ao longo de um projeto. A medida que mais informaes se tornam disponlveis, os planos e os cronogramas devem ser revsado~. 11 Um marco de projeto um resultado previsivel de uma atividade, no qual algum relatrio formal de progresso deve ser apresentado gerncia. Os marcos devem ocorrer regularmente ao longo de um projeto de software. Um produto um marco disponibili~ado para o cliente do projeto. li O desenvolvimento' do cronograma do projeto envolve a criao de vrias representaes grficas de partes do plano de projeto. Elas incluem'diagramas de atividades, que mostram os inter-relacionamentos entre as atividades de projeto, e diagramas de barras, que mostram as duraes de atividades. 11 Os principais riscos do projeto devem ser identificados e avaliados para definir sua probabilidade e as conseqncias para o projeto. Voc deve elaborar planos para evitar, gerenciar ou lidar com os provveis riscos se ou quando eles ocorrerem. Os riscos devem ser explicitamente discutidos em cada reunio de progresso do projeto.

LEITURAS

SUGERIDAS

Waltzing wirh bears: managing risk on sofrware projects. Uma apresentao muito prtica e de fcil leitura a respeito dos riscos e gerenciamento de riscos. (T. DeMarco e T. Lister, 2003, Dorset House.) Managing software quality and business risk. O Capitulo 3 deste livro simplesmente a melhor explicao sobre riscos que j vi. O livro trata da questo dos riscos e penso que seja. provavelmente. o melhor livro disponivel sobre esse assunto. (M. Ould, 1999. John Wiley & Sons.) The mythical man month (anniversary edirion). Os problemas de gerenciamento de software no mudaram desde a dcada de 1960 e este um dos melhores livros sobre o assunto. t um relato interessante e de fcil leitura de um dos primeiros grandes projetos de software, o sistema operacional IBM 051360. A edio de aniversriO (publicada 20 anos aps a edio original em 1975) inclui outros artigos clssicos de Brooks. (F. P. Brooks, 1995, Addison-Wesley.) Software project survival guide. Este um relato muito pragmtico do gerenciamento de software. mas contm recomendaes de boas prticas. ~ fcil de ler e de compreender. (S. McConneli, 199B. MICrosoft Press,) Consulte a Parte 6 para obter outras indicaes de leituras sobre gerenciamento.

--

EXERcCIOS
5.1 5.2 5.3 5.4 5.5 5.6 5.7

Explique por que a intangibilidade dos sistemas de software apresenta problemas especiais ao gerenciamento de projetos de software. Explique por que os melhores programadores nem sempre se tornam os melhores gerentes de software. Pode ser til basear sua resposta na lista de atividades de gerenciamento apresentada na Seo 5.1. Explique por que o processo de planejamento de software iterativo e por que um plano deve ser continuamente revisado durante um projeto de software. Explique brevemente o propsito de cada uma das sees em um plano de projeto de software. Qual a principal diferena entre um marco e um produto? A Tabela 5.8 estabelece uma srie de atividades, duraes e dependncias. Elabore um dia9rama de atividades e um diagrama de barras que mostre o cronograma do projeto. A Tabela 5.2 apresenta as duraes das atividades de projeto de software. Suponha que ocorra um problema srio e imprevisto e, em vez de levar 10 dias, a tarefa T5 leve 40 dias. Reviseo diagrama de atividades de acordo com a nova situao, ressaltando o novo caminho principal. Elabore um novo diagrama de barras, que mostre como o projeto pode ser reorganizado. Usando os exemplos de problemas de projeto apresentados na literatura. liste as dificuldades de gerenciamento nesses projetos de programao que falharam. (Sugiro que voc comece com o livro de Brooks, conforme sugerido em Leituras Sugeridas).

- --

5.8

Captulo 5 Tabela 5.8 Duraes e dependncias de tarefas Tarefa Durao (dias)

li

Gerenciamento

de projetos

75

Dependncias

5.9

Alm dos riscos apresentados na Tabela 5.4, identifique seis outros riscos possveis que podem surgir em projetos de
software. Os contratos de preo fixo, nos quais o fornecedor oferece um preo fixo para concluir o desenvolvimento de um sistema, podem ser usados para passar o risco do projeto do cliente para o fornecedor. Se algo der errado, o fornecedor deve pagar. Sugira como o uso de tais contratos pode aumentar a probabilidade de ocorrncia de riscos de produto. Seu gerente solicitou a entrega do software em um cronograma que voc sabe que s poder ser cumprido se sua equipe

de projeto trabalhar horas extras sem remunerao. Todos os membros da equipe tm filhos pequenos. Explique se voc
deve aceitar esse pedido de seu gerente ou se voc deve persuadir sua equipe a dar seu tempo para a organizao em vez de a suas famlias. Que fatores podem ser significativos para sua deciso? Como programador, voc recebe uma promoo para gerente de projeto, mas sente que pode prestar uma contribuio mais eficiente na funo tcnica do que na administrativa. Explique se voc deve aceitar a promoo.