5

Gerenciamento de projetos

Objetivos
objetivo deste capitulo é proporcionar uma visão geral do gerenciamento projetos de software. Depois de ler este capitulo, você:
Iij

o

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 representações gráficas (diagramas de barras e diagramas de atividades) podem ser usadas pelos gerentes de projeto para representar os cronogramas de projeto;

iIi terá sido apresentado à noção de gerenciamento de riscos e alguns dos riscos que podem surgir em projetos de software.

Conteúdo
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 não 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 são responsáveis pejo desenvolvimento de planos e cronogramas do projeto. Eles supervisionam o trabalho para assegurar que ele esteja scndo realizado dentro dos
padrões exigidos e monitoram o progresso para verificar se o desenvolvimento está no prazo e

dentro do orçamento. O gerenciamento de projetos de software é necessário, pois a engenharia de software profissional está sempre sujeita às restrições de orçamento e de cronograma da organização. O trabalho do gerenlc de projeto de software é assegurar que o projeto de sotlware atenda a essas restrições e entregue um software que contribua para as metas da empresa que está desenvolvendo o software.

em algum estágio.:cssária para examinar o progresso. O processo é experimen· (aoo e testado. Os projetos inovadores de engenharia (como novos sistemas de transporte). como pontes e prédios. Se u cronograma atrasa. Em úreas da engenharia l:om um longo histórico. O trabalho varia muito. . por algumas ou todas as seguintes atividadcs: III lÍIl lÍIl Elaboração da proposta Planejamento e desenvolvimento Custo do projeto e rcvisões do projeto do cronograma do projeto Iii Monitoração Iii Seleção e avaliação de pessoal Iij Elaboração de relatórios e apresentações O primeiro estágio de um projeto de software pode envolvcr a elaboração de uma proposta para obter um contrato para realizar o trabalho. Os sistemas de software são freqUentemente novos e tecnologicamente inovadores. desenvolvimento de cronograma de projeto e gerenciamento de riscos. obviamente. estimativa de custos de software e gerenciamento de qualidade. mesmo os gerentes que têm uma grande experiência pockm considerar dil"ícil prever problemas. jrrqiiell1emf1llte. Não pode ser visto ou locado. Os gerentes de projetos de software não podem ver o progresso. não é dc surpreender que alguns projctos de software atrasem. Os capílu~ los posteriores (na Parte 6)' abordarão outros aspectos do gerenciamento de software. A elaboração da proposta é uma tarefa crítica. projetos ·único". 3. Geralmente inclui a estimativa de custos e de cronograma e justitica por que o contrato deve ser concedido a detcrminada organização ou equipe. a elaboração da proposta é uma habilidade adqoirida pela prática c pela experiência. Portanto. quando determinado processo de software provavelmente apresentará problemas de desenvolvimento. O planejamento de projeto está relacionado à identificação das atividades. No entanto. ainda não podemos prever.·. Essas distinções tornam o gerenciamento de software particularmente difícil.partes da estrutura estarão. O produto é inlllllgível. 2. A proposta descreve os objetivos do projeto e como ele será realizado. Eles COlHam com outras pessoas para produzir a documentação Ilc<. Abordo esses itens mais delaIhadamente neste capítulo e no Capítulo 26. Além disso. o efeitu sobre o produto é visível . Projetos de software de grande porte são geralmente diferentes. É elaborado um plano para guiar o desenvolvimento em direção aos objetivos do projeto.!ào de um navio ou de um projeto de engenharia civil pode VCf o produto que está sendo construído. O software é intangível. Algumas das diferenças são: I. pois a existêocia de muitas organizações de software depende da existência de um número suficiente de propostas aceitas e contratos concedidos. O gerente de um projeto de constru. Em face das dificuldades envolvidas.1 Atividades de gerenciamento É impossível fornecer uma descrição de trabalho-padrão para um gerente de software. de alguma forma. No entanto. Embora nossa compreensão desses processos tenha se desenvolvido de modo significativo nos últimos anos. confiavelmente. não concluídas. é bem compreendido. 5. é surpreendente que tantos projetos de software sejam entregues no prazo e dentro do orçamento! O gerenciamento de projetos de software é um assunto amplo e não pode ser abordado apenas em um único capítulo. frcqüentemente apresentam também problemas de cronograma. a maioria dos gerentes assume a responsabilidade. No entanto.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. A estimativa de custos é uma atividade relacionada à estimativa dos recursos necessários para realizar o plano do projeto. Devido a esses problcmas. As lições aprendidas em projetos anteriores podem não ser aproveitadas em novos projetos. dependendo da organização e do produto de software que está sendo desenvolvido. Nl1u existem processoJ-padrüo de software. Proj(~lUSde sojllmre de gmlldr porte slio. as rápidas mudanças de tecnologia em computadores e comunicações podem tomar a experiência do gerente obsoleta. incluiodo gerenciamento de pessoas. a engenharia de software é diferente de outros tipo!lo de engenharia em uma série de maneiras. O processo de engenharia de alguns tipos de "i~tema. Isso é esptxialmellle verdadeiro quando o projeto de software é parte de um projeto mais amplo de engenharia de sistemas. ultrapassem o orçamento e estejam fora do cronograma. Portanto. apresento simplesmente uma introdução do assunto neste capítulo e descrevo três atividades importantes de gerenciamento: planejamento de projeto. os processos de software variam drasticamente de uma organização para outm. marcos e produtos gerados por um projeto. de projetos anteriores. Pode oão haver diretrizes definidas para essa tarefa.

você deve avaliar as restrições (data de entrega definida. O resultado de uma revisão pode levar à decisão de cancelamento de-um projeto.) que afetam o projeto.2. O tcmpo de desenvolvimento de um projeto de software de grande porte pode ser dc vários anos. Embora a maioria das organizações possua mecanismos formais para monitoração. Os gerentes de projcto são geralmente responsáveis pela preparação de relatórios sobre o projeto para o cliente e para as organizações contratantes. são necessárias mudanças no plano do projeto. A estrutura de um plano de desenvolvimento de software é descri la na Seção 5. mudam. Em vez de aguardar que um atraso no cronograma seja relatado. muitos erros simples poderão ser cometidos. Pude ser necessário contratar uma equipe menos experiente e que aceite uma remuneração menor. como sua estrutura. Um plano elaborado no início de um projcto deve ser usado como guia. Assim como UIl1plano de projeto. revelando dificuldades à medida que elas ocorrem. Mas provavelmente ocorrerão problemas. Os gerentes geralmente precisam selecionar pessoas para irabalhar em seus projetos. o plano deve ser regularmente revisado. o gerente de software poderia designar algum especialista para o problema ou pode propor uma alternativa de programação. Conseqüentemente. é quase ccrto que ocorram mudanças nos objetivos da organização. 5. você deve estimar os parãmetros do projeto. é normal que ocorram uma série de revisões formais de gerem:iamemo do projeto. No início dc um processo de planejamento.1 estabelece um processo dc planejamento de projeto para desenvolvimento de software. apenas concluído quando o próprio projeto é concluído. a. Explico a montagem da equipe e a seleção do pessoal no Capítulo 25. À medida que as infomlações se tornam disponíveis durante o projeto. pessoal disponível. Devem estar aptos a apresentar essas informações durante as revisõcs do progresso. a menos que pelo mcnos um membro do projeto tenba alguma experiência com o tipo do sistema a ser desenvolvido. Sem essa experiência. Dentro da organização.1 e abordados mais detalhadamcnte em um capítulo relcvante em outra parte no livro. Ele deve evoluir à medida que o projeto progride e melhores informações se tomem disponíveis. O gerente deve maUler o acompanhamento do progresso do projeto e comparar o progresso com os custos reais e planejados. orçamento geral etc. os gerentes precisam aceitar uma equipe de projeto aquém do considerado ideal. Pode ser impossível recrutar uma nova equipe para o projeto. metas do projeto também mudam e. um gerente experienle pode fornecer um quadro mais nítido do que está acontecendo por meio de discussões informais com a equipe do projelo. As razões para isso são: I.1.Capitulo 5 ii Gerenciamento de projetos 63 A monitoração do projeto é uma atividade conlinua. À medida que essas meta. 3. Por exemplo. discussões diárias com a equipe do projelo podem revelar um problema específico ao localizar algum defeilo de software. deverá ser capaz de se comunicar eficientemente de forma verbal e escrita.2 Planejamento de projeto O gerenciamento eficiente de um projeto dc software depende dc um planejamento minucioso do progresso do projeto. na maioria dos casos. O ideal é que haja o pessoal habilitado com experiência adequada disponível para trabalhar no projeto. 2. Os gerentes devem prever os problemas que podem ocorrer e preparar soluções experimcnlais para esses problemas. se você for um gerente de projeto. portanto. O orçamento do projeto pode não ser suficiente para Contratar uma equipe muito bem remunerada. As metas da empresa constituem um importante fator que deve ser considerado na formulação do plano do projeto. . Eles devem redigir documentos concisos e coerentes que resumam as informações fundamentais com base em relatórios detalhados do projeto. Eles são descritos brevemente na Tabela 5. Uma equipe inexperiente pode ser designada a um projeto a fim de aprender e ganhar experiência. Duranle csse período. Ele mostra que o planejamento é um processo iterativo. Essas mudanças podem significar que o software não é mais necessário ou que os requisitos originais de projeto não são apropriados. Durante um projeto. os gerentes podem também precisar elaborar outros tipos de planos. A gerência deve decidir pela inlerrupção do desenvolvimento do software ou allerar o projeto para acomodar as mudanças nos objctivos da organização. as pessoasmais indicadas já podem estar alocadas em outros projetos. No entanto. O pseudocódigo apresentado na Figura 5. O gerente de software precisa Irabalhar dentro dessas restrições ao selecionar a equipe de projeto. Junto com isso. Elas estão relacionadas à revisão geral do progresso c desenvolvimento técnico do projeto e à verificação se o projeto c as metas da organização que está financiando o software ainda estão alinhados. Uma equipe com experiência adequada pode não estar disponível na organização ou cxtemamenle. A monitoração informal pode prever problemas pOleneiais do projeto. A organização pode querer desenvolver as habilidades de seus funcionários. Esse plano inicial deve ser o mel bar possível em facc das informações disponíveis.

À medida que as informações se tornam disponíveis. o plano de projeto é um único documento que inclui diferentes tipos de planos (Tabela 5. você deve examinar o progresso e anotar as discrepâncias em relação ao cronograma. você não deve contar com o fato de que tudo correrá bem. As referências a outros planos estão incluídas. os recursos e o cronogramá usados para a validaç. Naturalmente.os. Em seguida. a maioria dos planos deve incluir as seguintes seções: I. Em outms c". Em algumas organizações. Veja " Prevêos requisitos de manutenção do sjstema.Vejao Capitulo25.Aguarde (por um .64 • Engenharia de software Tabela 5.renciamenta de configuraçao a serem usados.1). Suas hipóteses e cronograma iniciais devem ser pessimistas em vez de otimistas.1 Planejamento do prOJeto. Veja o Capitulo22. a estrutura analítica dn pmjeto e um (m- nograma para realizar o trabalho. IllIrodução. voçê define os marcos de progresso e os produtos a serem entregues.2. prazo etc.no~~ quali9ade Plano de'validaçao Plano de gerenciamento de (onfiguraçAo Plano de manutenção Descrição . . o Capitulo 29: Descreye os procedimentos e as estruturas de g.) que afetam o gerenciamenro do projeto. Figura 5. o plano de pmjeto está relacionado apenas ao processo de desenvolvimento.1o do sistema. IIna estimado para o projeto e as atividades definidas no cronograma são iniciadas ou liberadas para prosseguimento. Descreve brevemente os objetivos do pmjeto e estabelece as restrições (por exemplo. Deve existir contingência suficiente no plano. O processo. 5. No entanto. os rostos de manuten~o e o esforço necessário.?27. entra em um loop. Devido às estimativas iniciais dos parâmetros do projeto serem experimentais. Se essa renegociação não for bem-sucedida e o cronograma não puder ser cumprido. você deve revisar as hipóteses originais e o cronograma do projeto.1 ------- O plano de projeto ---- o plano de pmjeto estabelece os recursos disponíveis para O pmjcto. A estrutura de plano que descrevo neste livm é adequada ao último tipo de plano. Depois de algum tempo (geralmente cerca de duas ou três semanas). sempre sed necessário modificar o plano original. uma revisão técnica pode ser considerada. Piano de desenvolvimento Descreve como as habilidades e a experiência dos membros da equipe de profeto serAo de pessoal desenvolvidas. de modo que 'IS restriçõcs e os marcos do projeto não precisem ser renegociados o tempo todo no loop de planejamento. Vejao Capltul. O objetivo dessa revi~ão é encontrar uma abordagem alternativa que se limite às re~trições do projeto e cumpra o cronograma. Se o projeto estiver atrasado. mas os planos são separados entre si. Pla. Os detalhes do plano de pmjeto vadam dependendo do tipo do pmjeto e da organização. então. Vejao Capitulo24. Defina as restrições do projeto Faça a avaliação inicial dos parâmetros do projeto Defina os marcos do projeto e os produtos a serem entregues while projeto não foi concluído ou cancelado (oop Elabore um cronograma do projeto Inicie as atividades d~' acordo (om o cronograma . Deve ser elaborado um cronogr: .1 Tipos de planos Plano .período) Examine o progresso do projeto Revis'eas estimati~as de parâmetros do projeto Atualize o cronograma do projeto Renegocie as restrições do projeto e os produtos a serem entregues if (surgirem problemas) then Inicie revisão técnica e possível nova revisão end if end loop tamanho e distribuição das funções. Problemas de alguma natureza quase sempre surgem durante o projeto. Descreveos procedimentose os padroes de qualidade usados no projeto. Oescreve·a abordagem. pode ser necess<Írio renegociar as restrições e os produtos a serem entregues com o cliente. a<çamenlo.

correspondem à finalização das saídas de cada atividade. as pessoas envolvidas e seus papéis na equipe. que não podem ser verificados.4. o processo de software deve ser decomposto em atividades básicas com saídas associadas. embora não sejam entregues ao cliente. ESlrllrurll llnalítica. Análise de riscos. pois a quantidade de código que ainda precisa ser desenvolvida é incerta. Os marcos devem representar o fim de um estágio lógico e distinto do projeto.2. COmO'Codificação 80% concluída'. Os produtos do projeto entregues ao cliente são a definição e a especificação de requisitos. quando a prulUtipação é usada para ajudar a validar os requisitos. como um relatório. é impossível avaliar quão bem o trabalho está progredindo e as estimativas de custos c o cronograma não podem ser atualizados. É geralmente disponibilizado no fim de alguma fase importante do projeto. a probabilidade da ocorrência desses riscos c as propostas de estratégias de redução de riscos. A .wws de I1W!'.2.2 Marcos no processo de requisitos. Se o hardware precisar ser comprado.2. Os gerentes estimam o tempo e recursos necessários para concluir atividades. Organização do projeto. podem ser incluídas as estimarivas de preços e u 5. são inúteis para o gerenciamento do projeto. Algumas partes. 4. Os marcos podem ser resultados internos do projeto usados pelo gerente do projeto para verificar o progresso. Descreve o modo como a equipe de de-senvolvimcnto está organizada. prazo de entrcga. Figura 5. Ao planejar um projeto. 5. mas marcos não precisam ser produtos.2 Marcos e produtos a serem entregues Os gerentes precisam de informaçõcs pam realizar seu trabalho. Explico os princípios de gerenciamento de riscos na Seção 5. 7. Como o software é intangível. Estabelece a estrutura analítica do projeto em atividades e identifica os marcos e os produtos a serem cntregues com cada atividade. Eles podem ser simples relatórios breves sobre o que foi concluído. 6. neste caso. a Figura 5. mudarão frcqüentemclllc c outras partes serão m<lisestáveis. Um produto é um resultado de projeto entregue ao cliente. Para simplificar as revisões. Os marcos. organizando-as em uma seqüência coerente. que possa ser apresentado à gerência. Os relatórios de marcos não precisam ser documentos extensos. o prazo estimado necessário para atingir cada marco e a alocação de pessoas nas atividades.WrUçüo e e/u/Joraçc1o de relatórios. Um marco é um ponto final reconhecível de uma atividade do processo de software. Definem os relatórios de gerenciamclllo que devem ser produzidos. Você não pode verificar se esse estado foi alcançado. essas informações podem ser fornecidas apenas como relatórios e documentos que descrevem o estado do software que é desenvolvido.3 Cronograma do projeto O desenvolvimento do cronograma do projeto é um dos trabalhos mais difíceis para um gerente de projeto. como especificação ou designo Os produtos são geralmente marcos.Capitulo 5 • Gerenciamento de projetos 65 2. 3. você deve organizar o documento em !oieções separadas que podem ser individualmente substituídas à medida que o plano evolui. MecQlIi. Requisitos de recursos de hardware e de software. Descreve os possíveis riscos do projeto. Os marcos e os produtos a serem entregues são explicadus na Seção 5. Por exemplo. deve existir uma saída formal. A cada marco. Estudo de viabilidade ATIVIDADES Estudo de projeto Relatório de viabilidade Defini<C1o de requisitos Relatório de avaliação Projeto de arquitetura MARCOS • 5. Sem essas informações. Marcos indefinidos. Especificam o hardware e o software de apoio necessários para realizar o desenvolvimento. Você deve revisar regularmente o plano durante o projeto. Para estabelecer os marcos.2 mostra as possíveis atividades envolvidas na especificação de requisitos. como O cronograma do projeto. quando eles devem ser produzidos e os mecanismos de monitoração de projeto usados. Cronograma do projeto. Apresenta as dependências entre as atividades. você deve estabelecer uma série de 11l1llH'j·.

. Além do calendário. Uma subdivisão mais detalhada significa que urna quantidade desproporcional de tempo deve ser despendida na estimativa e na revisão de diagramas. as estimativas anteriores constituem uma base incerta para o desenvolvimento do cronograma do novo projeto. dependências entre a. Nesse sentido. sua duração e as respecliva.2. ao estimar os cronogramas. diferentes atividades que con. mais 20% para cobrir aspectos sobre os quais não tinha pensado. conforme apresentado na Tabela 5. É importante evitar uma situação em que todo o projeto fique atrasi. padrãe.erem iniciadas e terminadas. usando uma ferramenta de gerenciamento de projetos. dos parâmetros de projelo (prazo final. o desenvolvimento do cronograma de software não é diferente de nenhum outro tipo de projeto avan<. Esse falor extra de contingência depende do tipo de projelo. Você deve coordenar as atividades paralelas e organizar o trabalho de modo que a força de trabalho seja usada de maneira otimizada. Outros recursos podcm ser o espaço em disco necessário no servidor. criei um conjunto hipotético de atividades. 5.3 Processo de desenvolvimento do cronograma do projeto. as estimativas iniciais certamente serão otimistas.3. então. Ao ob. o tempo necessário de um hardware especializado. Explico estimativas mais detalhada mente no Capítulo 26. O desenvolvimento do cronograma de projelo (Figura 5.1 Diagramas de barras e redes de atividades Os diagramas de barras e as redes de atividades são notações gráficas usadas para ilustrar o cronograma do projeto. Se o projeto for novo e tecnicamente avançado. as dependências de atividades c as alocaçõcs de pessoal. portanto.ável por cada atividade e quando a> atividades estão programada> para . mostram. É também útil estabelecer uma quamidi. Conforme já sugeri. Em geral. Descrevo esses diagramas na seção seguinte. Para ilustrar como os diagramas são usados.ar método. devem ser continuamente atualizados à medida que mais informações sobre o progresso se (Ornem disponíveis. algumas das atividades são realizadas simultaneamente.írio para completar essas atividades. O recursu principal é o esforço humano necessário. Os diagramas de barras e os diagramas de atividades podem ser gerados automaticamente baseados em um banco de dados de informações do projeto. O. deverá ser subdividida para planejamento c desenvolvimento do cronograma de projeto.3) envolve a divisão do trabalho total de um projelo em alividades separadas e a avaliação do tempo necess:.ado de grande porte. você também deve prestar atenção aos recursos necessários para completar cada tarefa. Adiciono sempre 30% a minha estimativa original para problemas não previstos e. Uma nova aeronave. Se ela levar mais tempo que isso.ervar a Tabela 5. A estimativa de cronograma é mais complicada pelo falO de que projeto. aumentar a estimativa para cobrir problemas não previstos. Um fator de contingência adicional para cobrir problemas não previ. certas panes do projeto podem se tornar mais difíceis e tomar mais tempo do que inicialmente previsto. você não deve considerar que todo o est<ígio do projeto estará livre de problema~.66 11 Engenharia de software menos que o projeto cujo cronograma está sendo desenvolvido seja similar a um projeto anterior. o hardware pode apresentar defeilO e o software ou o hardware de apoio essencial pode ser entregue com atraso. e o orçamento para viagens necessárias da equipe de projeto. como um simulador. Se o projeto for tecnicamente avançado. Essa tabela mostra as atividades. As atividi. em seguida. interdependências. Os cronogramas. diferentes podem u.2. Os cronogramas de projeto são geralmente representados como um conjunto de diagramas que apresentam a estrutura analítica do projeto. são geralmente u»das para automatizar a produção de diagramas. As pessoas que trabalham em um projeto podem ficar doentes ou podem sair. etc. como o Microsoft Projecl. Uma boa regra prática é fazer a estimativa como se nada fosse dar errado e. As redes de alividade. A.ldo devido ao fato de a tarefa crítica não estar concluída.tituem um projeto. você pode Figura 5.) e da qualidade c experiência dos engenheiros de software que trabalham no projeto.tos pode também ser acrescentado à estimaliva. Identificar atividades Identificar dependências entre atividades Estimar recursos para atIVIdades Alocar pessoas para atividades Criar diagramas de projeto Requisitos de software Diagramas de atividades e diagramas de barras . pontes e mesmo novos modelos de 3ulOmó· veis freqüentemente sofrem atrasos devido a problemas não previstos. e linguagens de implementação diferentes.ldcs de projeto devem durar pelo menos uma semana. mesmo quando todas as eventualidades são levadas em conta.lde máxima de tempo para qualquer atividade de aproximadamente 8 a 10 semanas. diagramas de barra> moslram quem é respon. ferramenta> de gerenciamento de projeto.

Ponanto. mostrada na Figura 5. Antes do início da implementação.4. Antes de passar de um marco para outro. os atrasos nas atividades que não estão no caminho principal não causam necessariamente atraso geral no cronograma. T7 (M7) T9 (M6) Tll (M8) Tl (M1) Dependências constatar que a atividade n é dependente da atividade TI. a implementação desse projeto. Contudo. O cronograma geral do projeto depende do caminho principal. Quando os valores reais são conhecidos. isso corresponde a II semanas de tempo decorrido ou 55 dias trabalhados. As atividades são representadas por retãngulos. Por exemplo. depois. Neste caso. O caminho principal é a seqüência de atividades dependentes que define o tempo necessário para concluir o projeto. A maioria das ferramentas de gerenciamento de projetos calcula os atrasos permitidos. então a atividade T9. os marcos e os produtos a serem entregues são apresentados por retãngulos de cantos arredondados. quando as atividades T3 e T6 forem terminadas. a terceira coluna da Tabela 5.2 Tarefa Tl T2 B T4 T5 T6 T7 T8 T9 TlO Tl1 Tl2 5 11 Gerenciamento de projetos 67 Durações e dependências de tarefas Duração (dias) 8 15 15 10 10 5 20 25 15 15 7 la • T2.4).o. pode começar. pois não está no caminho principal. Na ferramenta de gerenciamento de projeto usada para produzir esse diagrama. os cronogramas iniciais de projeto serão incorretos. As atividades posteriores de projeto poderão.Capítulo Tabela 5. o projeto do componente deve estar concluído. o cronograma do projeto não será afetado. Uma atividade pode ser iniciada quando seu marco precedente (que pode depender de várias atividades) for atingido. Você deve ler o diagrama da esquerda para a direita e de cima para baix. O cronograma de projeto pode se tomar mais cuno por causa da redução do tempo gasto que aguarda o término das atividades. À medida que o projeto avança.4. Ele mostra quais atividades podem ser realizadas simultaneamente e quais devem ser executadas em seqüência devido a uma dependência da atividade anterior. ela não irá afetar a data final de término do projeto. Por exemplo. Na Figura 5. um diagrama de atividades pode ser gerado (Figura 5. o diagrama de atividades deve ser revisado. M5) alcançado quando as tarefas terminam (veja a Figura 5. As datas desse diagrama mostram a data de início da atividade. O tempo mínimo necessário para terminar O projeto pode ser estimado considerando-se O caminho mais longo no gráfico de atividades (o caminho principal). Em face das dependências e das durações estimadas das atividades. as estimativas devem ser comparadas com o tempo real decorrido. Desde que esses atrasos não estendam as atividades de modo que o tempo total para a atividade mais as atividades futuras dependentes não excedam o caminho principal. ser reorganizadas para reduzir a extensão do caminho principal. Pode ser possível modificar o projeto de sistema de modo que o caminho principal se tome mais cuno. T4 (M2) Tl. Por exemplo. conforme mostrado no diagrama de barras do projeto. todas as atividades devem terminar nos marcos. Isso significa que T1 deve ser terminada antes do início de T3. todos os caminhos que levam para ele precisam estar completos. T2 (M3) Tl(M1) T4 (MS) B. T I pode ser a preparação de um projeto de componente e n. porque as atividades seguintes não podem ser iniciadas até que a atividade em atraso tenha sido terminada. T6 (M4) T5.4). se T8 estiver atrasada por duas semanas. Qualquer atraso no ténnino de qualquer atividade principal causa atrasos no projeto. Essa comparação pode ser usada como base para revisão de cronograma para as panes posteriores do projeto.2 mostra O marco correspondente (por exemplo. . o caminho principal é mostrado como uma seqüência de caixas com contorno em negrito. Inevitavelmente. Os gcrentes também usam os diagramas de atividades ao alocar o trabalho de projeto. Eles podem fornecer esclarecimentos sobre as dependências de atividades quc não sejam óbvias.

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 J I • M3 M2 ~ T6 T5 . Se uma atividade não for concluída em tempo. É um diagrama de barras que mostra um calendário de projeto e as datas de início e fim das atividades. A Figura 5. figura 5.5 é lima maneira complementar de representação de infonnaçôes de cronograma do projeto. Ao ser lido da esquerda para a direita.m .4 1417103 15 dias Processo de desenvolvimento do cronograma do projeto. o diagrama de barras mostra daramente quando uma atividade começa e (emuna. em homenagem a seu inventor. Algumas das atividades mostradas no diagrama de bmrus da Figura 5. o caminho principal não será afetado até o fim do período indicado pela barra sombreada. As atividades no caminho principal não têm margem de erro e são identificadas por não possuírem barras sombreadas associadas.68 11 Engenharia de software figura 5.5 são seguidas por uma barra sombreada cujo comprimento é calculado pela ferramenta de cronograma. Às vezes é chal1l3do de diagramas de Gantl. ~ I I I J Til I .5 4f7 1117 Início T4 T1 12 Ml.M6 I M8 T12 r.M4 T9 t M7 f TIO I . Ela demonstra a flexibilidade da data de término das atividades.

1998) (Ould. pois a experiência do programador não está disponível para ser oferecida em negócios futuros. pode cometer erros de programação. Riscos de projeto são aqueles que afetam o cronograma ou os recursos de projeto. isso poderá ter efeito prejudicial sobre os outros projetos. Naturalmente. no produto e nos . 2. Você precisa prever os riscos. Em alguns períodos. Por exemplo. Essa alocação pode também 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. Se um programador experiente deixa um projeto. pois um substituto pode não ser tão experiente e. então. Riscos de produto são aqueles que afetam a qualidade ou o desempenho do software que está sendo desenvolvido.6). o software que está sendo desenvolvido ou a organização. Finalmente. Um exemplo pode ser a perda de um projetista experiente.6 AlocaçM de pessoal versus diagrama de tempo.Capitulo 5 11 Gerenciamentode projetos Figura 5. você pode pensar em risco como algo que seria preferível não ocorrer. Um exemplo pode ser um componente comprado não funcionar conforme e~perado. Os riscos podem ameaçar o projeto.6. Os riscos que podem afetar um projeto dependem do projeto e do ambiente organizacional onde o software está sendo desenvolvido. Pode também haver atrasos porque o especialista não está disponível. como uma da') principais atividades dos gerentes de projeto. pois a entrega do sistema pode atrasar.3. Ela. Alguns dos riscos mais comuns são mostrados na Tabela 5. • 5. esses tipcs de risco se sobrepõem. a alocação de pessoal às atividades do projeto. os gerentes de projeto também precisam considerar a alocação de recursos e. pcrtanto. um concorrente que lança um produto é um risco de negócio. pode ser um risco de negócio. três categorias de risco relacionadas: I.5/8 2218 2918 5/9 12/9 19/9 T8 1T11 T12 Jane T1 Tl T9 I • IT10 Anne T2 Jim T6 I In I I T5 I Mary Além de considerar os cronogramas. trabalhando em outros projetos. dificuldades na estimativa de prazo e recursos necessários para o desenvolvimento de software. Se um projeto atrasa enquanto um especialista está trabalhando nele.4 Gerenciamento de riscos o gerenciamento de riscos está sendo considerado. Isso pode causar problemas no cronograma. elas podem estar em férias. De fonna simplificada. em particular. cada vez mais. Riscos de negócio são aqueles que afetam a organização que desenvolve ou adquire o software. Os resultados da análise de riscos devem ser documentados no plano de projeto junto com uma análise das conseqüências de uma ocorrência de risco. 3. dependência de habilidades individuais e mudanças de requisitos devido às mudanças nas necessidades do cliente. No entanto. compreender o impacto desses riscos no projeto. Fred 69 4f7 T4 lln I 1817 25n 118 818 . se originam de requisitos mal definidos. As pessoas não precisam estar designadas a um projeto durante todo o tempo. Pode também ser um risco de produto. Um gerenciamento eficiente de riscos toma mais fácil lidar com os problemas e assegurar que eles não conduzirão a um orçamento inaceitável ou atraso no cronograma. O gerenciamento de riscos é particularmente importante para projetos de software. Grandes organizações geralmente empregam uma série de especialistas que trabalham em um projeto. 1999). Existem. observe que Mary e Jim são especialistas que trabalham somente em uma única tarefa no projeto. se necessário. isso pode ser um risco de projeto. passando por cursos de treinamento ou realizando alguma outra atividade. muitos riscos são universais. Ele consiste em prever os riscos que podem afetar o cronograma do projeto ou a qualidade do software que está sendo desenvolvido e tomar providências para evitar esses riscos (Hall. devido às incertezas inerentes à maioria dos projetos. Na Figura 5.

Planejamellto de riscos. caso os riscos ocorram.s riscos de software Tipo de risco Projeto Projeto Projeto Projeto e produto Descrição Pessoalexperiente deixar~o projeto antes do seu término. de produto e de negócios são identificados. São elaborados planos para cuidar dos riscos seja evitando-os ou minimizando seus efeitos no projeto. O processo de gerenciamento de riscos. o hardware prazo. os riscos deverão ser analisados novamente e novas prioridades deverão ser estabelecidas. é um processo iterativo que prossegue ao longo do projeto. previsto. a situação é monitorada. A tecnologia sobre a qual o sistema foi construido foi superada por uma nova tecnologia.•desses riscos são avaliadas. Tamanho subestimado Projetoe produto Produto Baixo desempenho da ferramenta CASE Mudança de tecnologia Concorrência de produto Negócios Negócios negócios. como todos os outros planejamentos de projeto. você também deve incluir no plano os resultados do processo de gerencia- mento de riscos. O tamanho do sistema foi subestimado. Uma vez elaborado um conjunto inicial de planos. Ele envolve vários estágios: I. 3. Os riscos possíveis de projeto. como planos de contingência específicos a serem ativados caso o risco venha a ocorrer..70 11I Engenharia de software Tabela 5. 4.7. Idelltificaçõo de riscos. e tomar providências para evitar esses riscos. Os planos de prevenção de riscos e de contingência podem ser modificados à medida quc novas infonnações de risco surgirem. Um produto concorrente foi lançado no mercado antes da condusao do sistema. Análise de riscos. Haverá uma mudança na gerência da organizaç~o com ROlatividade pessoal de Mudança de gerência Indisponibilidade de hardware diferentes prioridades. 2. Você deve documentar os resultados do processo de gerenciamento de riscos em um plano de gerenciamento de riscos. Figura 5. essencial ao projeto não será entregue dentro do Mudança de requisitos Haverá um número maior de mudanças de requisitos do que o • Atrasos de especificaç3a Projeto e produto As espedficaçôes das interfaces essenciais nAo estafA0 disponfveis dentro do prazo. Os riscos são constantemente avaliados e os planos para mitigação de riscos são revisados à medida que mais informações se tomam disponíveis. Quando apropriado.3 Risco Possíve. O processo de gerenciamento de riscos está ilustrado na Figura 5. Identificação de riscos Análise de riscos Planejamento de riscos Monitoração de riscos Lista de riscos potenciais lista de riscos priorizados Planos de prevenção de riscos e de contingência Avaliaç~o de riscos .7 Processo de gerenciamento de riscos. uma análise desses riscos e os planos necessários para gerenciar esses riscos. de modo a poder tomar providências imediatas para recuperação. À medida que mais informações sobre os riscos se tomarem disponíveis. Monitoração de riscos. As ferramentas CASE que apóiam o projeto não funcionam conforme previsto. Pode ser necessário elaborar planos de contingência. A probabilidade e as conseqüência . Esse plano deve incluir uma explicação dos riscos enfrentados pelo projeto.

riscos com conseqüências muito pequenas ou com muito pouca probabilidade de ocorrência não sejam normalmente considerados. Tabela 5.'. São aqueles que derivam do ambiente organizacional no qual o software está sendo desenvolvido. São aqueles que derivam de tecnologias de software ou hardware usadas para desenvolver o sistema. O treinamento necessario para o pessoal não esta disponlvel. f imposslvelrecrutar pessoal com as habilidadesnecessárias. de modo que uma gerência diferente tornou-se responsavelpelo projeto.1 Identificação de riscos A identificação de riscos é o primeiro estágio do gerenciamento de riscos. Em princípio. você deverá ter uma longa lista de riscos que podem ocorrer e quais podem afetar o produto.4 Riscose tipos de risco.Capitulo 5 lIi Gerenciamento de projetos 71 5. 3. Riscos de pelloa/. A identificação de riscos pode ser realizada como um processo em equipe. um checklist de diferentes tipos de risco pode ser usado.4.4 apresenta alguns exemplos dos possíveis riscos em cada uma dessas categorias. Essas estimativas de risco geralmente não precisam ser avaliações numéricas precisas. média (25-50%). baixa (l()"'25%). 4. Riscos de requisitos. Riscos de estimatil'as. O prazo necessario para desenvolvero software foi subestimado. Organizacional Ferramentas A organização é reestruturada. Mudanças de requisitosque requerem retrabalho maior de projeto são propostas. Problemasfinanceirosda organização forçam reduções no orçamento do projeto. sérios. A Tabela 5. toleráveis ou insignificantes. seis tipos de risco que podem surgir: I. São aqueles que derivam de mudanças de requisitos de cliente e do processo de gerenciamento de mudança de requisitos. você precisa considerar cada risco identificado e fazer uma avaliação de sua probabilidade e seriedade. o processo e os negócios. Para auxiliar o processo. embora. na prática. desenvolver o sistema. pelo menos. usando uma abordagem de brainstorrning.2 Análise de riscos Durante o processo de análise de riscos. RiICOS de ferramelltas.4. Os componentes de software que devem ser reusados contêm defeitos que limitam sua funcionalidade. Os clientes não compreendem o impacto das mudanças de requisitos. os riscos não devem ser avaliados ou priorizados neste estágio. Tipo de risco Tecnologia Pessoàl Riscos possíveis o banco de dados usado no sistema não pode processartantas transaçoes por se<Jundocomo esperado. Após concluir o processo de identificação de riscos. São aqueles associados às pessoas da equipe de desenvolvimento. As ferramentas CASE não podem ser inte<Jradas. 6. O código gerado pelas ferramentas CASE é ineficiente. São aqueles que derivam de estimativas de gerenciamento das características de sistema e estimativas de recursos necessários para construir o sistema. 5. mas devem basear-se em um número de faixas: III A probabilidade do risco deve ser avaliada como muito baixa «10%).você deve contar com sua própria avaliação e experiência. 5. Ela está relacionada com a descoberta dos possíveis riscos do projeto. São aqueles que derivam de ferramentas CASE e outros softwares de apoio. O tamanho do software foi subestimado. usados para 2. o que faz com que gerentes de projetos experientes sejam as melhores pessoas para auxiliar no gerenciamento de riscos. RiSCaI de recllologia. ou simplesmente ser baseada na experiência. Requisitos Estimativas . . Não existe uma maneira fácil de fazer isso . O pessoal mais qualificado está doente e nao disporifvel nos momentos criticas. lIi Os efeitos do risco podem ser avaliados como catastróficos. Existem. A taxa de reparo de defeitos foi subestimada. alta (5()"'75%) ou muito alta (>75%). Riscos organizacionais.

assim como lOdos os riscos sérios que tenham probabilidade de ocorrência acima da média. A Tabela 5. o processo. a avaliação de probabilidade e de seriedade é arbitrária neste caso. Toleráveis Toleráveis Toleráveis Toleráveis Toleráveis Insignificantes o treinamento necessário para o pessoal nao está disponlvel. você deve avaliar quais são os mais significativos. A organiza~o é reestruturada.5. para fazer essa avaliação. Em geral. essa tabela deve ser atualizada após cada iteração do processo de gerenciamento de riscos.6 mostra as possíveis estratégias identificadas para os riscos principais da Tabela 5. riscos catastróficos devem sempre ser considerados. Probabilidade Baixa Efeitos Catastróficos Catastróficos Sérios Sérios ~ imposslvelrecrutar pessoal com as habilidadesnecessáriaspara o projeto. O tamanho do software foi subestimado. Portanto. Os clientes não compreendem o impacto das mudanças de requisitos. Na prática. o número de riscos selecionados para monitoração deve ser gerenciável. Boehm (Boehm.r 72 li Engenharia de software Você deve.5 ilustra isso em relação aos riscos identificados na Figura 5. Podem ser 5 ou 15. tanto a probabilidade quanto a avaliação dos efeitos de um risco podem mudar à medida que mais informações sobre o risco tomam-se disponíveis e quando os planos de gerenciamento de riscos são implantados.6. Sérios Sérios Sérios Sérios O tempo necessário para desenvolver o software foi subestimado. O banco de dados usado no sistema nao pode processar tantas transaçO€s por segundo como esperado. 2. computar os resultados desse processo de análise usando uma labela ordenada de acordo com a gravidade do risco. mas penso que esse número é um tanto arbitrário. 1988) recomenda identificar e monitorar os 'lO maiores' riscos. Com base oos riscos identificados na Tabela 5. Após os riscos terem sido analisado5 e classificados. como mostrado na Tabela 5.5 Análise de riscos Risco Problemas financeiros da organização forçam reduçoes no orçamento do projeto. e uma gerl!ncia diferente tornou-se responsável pelo projeto. Tabela 5. você precisa de informações detalhadas sobre o projelo. Alta Média Média Média Alta Média Alta Alta Média Média Média Alta Média o mais qualificado sua funcionalidade est~doente nos momentos crfticos do projeto.5. Novamente. Estratégias de minimização. Um exemplo de estratégia de minimização de riscos é de doença entre o pessoal da equipe como mostrado na Tabela 5. a equipe de desenvolvimento e a organização.6. . Seguir essas estratégias significa que o impacto do risco será reduzido. ESlraIéxias de prevenção. No entanto. Naturalmente. portanto. eiS componentes de software que devem ser reusados-<:ontêmdefeitos que limitam ~o propostas mudaoças de requisitosque requerem maior retrabalho de projeto. Um exemplo de uma estratégia de prevenção de riscos é lidar com componentes defeituosos. o código gerado pelas ferramentas CASEé ineficiente. As ferramentas CASEnão podem ser integradas. 1.4. A avaliação deve depender da combinação da probabilidade da ocorrência do risco e de seus efeitos. A Tabela 5.4. Essas estratégias dividem-se em três categorias: Seguir essas estratégias significa que a probabilidade de que o risco ocorrerá será reduzida. 5. Um número muito grande de riscos exigirá que muitas informações sejam coletadas. A taxa de reparo de defeitos foi subestimada. Obviamente. O número correIo de riscos a serem monitorados depende do projeto. Ele conta com a avaliação e a experiência do gerente do projeto. é apropriado considerar todos os 8 riscos com conseqüências catastróficas ou sérias.3 Planejamento de riscos o processo de planejamento de riscos considera cada um dos riscos importantes identificados e define estratégias para gerenciá-los. não existe um processo simples a ser seguido para definir os planos de gerenciamento de riscos.

Tabela 5. Verificar a possibilidade de comprar um banco de dados com desempenho melhor.6 Estratégias de gerenciamento de Risco Ifr~j. portanto. Baixo moral do pessoal.4 Monitoração de riscos A monitoração de riscos envolve a avaliação regular de cada um dos riscos identificados para decidir se esse risco está ou não se tomando mais ou menos provável e se os efeitos do risco mudaram. A monitoração de riscos deve ser um processo contínuo e. 5. use uma estratégia que reduza as chances de que o risco tenha sérios efeitos. Reestruturaçaoda organizaçao Desempenho do banco de dados Prazo de desenvolvimento subestimado 3. Falha no cumprimento do cronograma. Um exemplo de estratégia de contingência é a estratégia para problemas financeiros da organização na Tabela 5. tenha estratégias que reduzam o impacto geral de ocorrência de um risco no projeto ou no produto. falha em eliminar defeitos relatados. Planos de co1ltingêm:ia. reclamações sobre ferramentas CASE.~-mas financeirosda organizaçao piobfemas de recrutamento 'Doença do pessoal da equipe cC.7 Fatares de risco Indicadores potenciais Tipo de risco Tecnologia Pessoal Organizacional Ferramentas Entrega de hardware ou software de apoio com atraso. Seguir essas estratégias significa que você está preparado para o pior e tem uma estratégia para lidar com o problema. Relutância dos membros da equipe em usar ferramentas. Preparar um documento de instruç6es para a gerência sênior que mostre (orno o projeto est1 contribuindo de maneira muito importante para as metas da empresa. a cada revisão de progresso feita pela gerência.reclamações do cliente. as pessoas compreendam as tarefas uns dos outros. Naturalmente. Se isso não for possível. Alertar o cliente sobre as dificuldadespotenciais e a possibilidadede atrasos~investigara compra de componentes. isso não pode ser observado diretamente.Capítulo Tabela 5. que mostre como o projeto está contribuindo de maneira muito importante para as metas da empresa.4. demandas por estações de trabalho mais poderosas. Reorganizara equipe de maneira que haja mais superposiçao de trabalho e. relacionamentos pr~rios entre os membros da equipe. potencialmente defeituosos por componentes comprados Substituir os componentes e de confiabilidadereconhecida. Finalmente. muitos problemas de tecnologia relatados. A Tabela 5. disponibilidade de emprego. Esses fatores são obviamente dependentes dos tipos de risco.mponentescom defeito . Note a analogia com as estratégias usadas em sistemas críticos para assegurar contiabilidade. Requisitos Estimativas Munas solicitaçõesde mudança de requisitos. Boatos na organização. proteção e segurança. ~'Mudança5 de requisitos 5 ti Gerenciamento de projetos 73 fiSCOS Estratégia Preparar um documento de instruções para a gerência sênior. Essencialmente. Verificar a compra de componentes e verificar o uso de um gerador de programa. é necessário observar outros fatores que forneçam indícios a respeito da probabilidade do risco e seus efeitos. . é necessário considerar e discutir cada um dos principais riscos separadamente. é melhor usar uma estratégia que evite o risco.6. falta de aç30 da gerência sênior. portanto. • Derivar informações de rastreabilidade para avaliar o impacto das mudanças de requisitos e maximizar o ocultamente de informações no projeto.7 apresema alguns exemplos de fatores que podem ser úteis na avaliação desses tipos de risco.

que mostram as durações de atividades. (S. ~ fácil de ler e de compreender. durações e dependências. Brooks. Os marcos devem ocorrer regularmente ao longo de um projeto de software. Suponha que ocorra um problema sério e imprevisto e. 11 Os gerentes de software possuem diversos papéis. elaboração de estimativas e desenvolvimento de cronograma do projeto.2 5. li O desenvolvimento' do cronograma do projeto envolve a criação de várias representações gráficas de partes do plano de projeto. Ould. John Wiley & Sons. Elabore um novo diagrama de barras. . Você deve elaborar planos para evitar. -- •• •• • •• •• •• EXERcíCIOS 5. Este é um relato muito pragmático do gerenciamento de software. Qual é a principal diferença entre um marco e um produto? A Tabela 5. A medida que mais informações se tornam disponlveis. Os processos de software não são bem compreendidos. Uma apresentação muito prática e de fácil leitura a respeito dos riscos e gerenciamento de riscos. t um relato interessante e de fácil leitura de um dos primeiros grandes projetos de software. • 11 Um marco de projeto é um resultado previsivel de uma atividade. LEITURAS SUGERIDAS • Waltzing wirh bears: managing risk on sofrware projects. no qual algum relatório formal de progresso deve ser apresentado ã gerência. O livro trata da questão dos riscos e penso que seja. Elabore um dia9rama de atividades e um diagrama de barras que mostre o cronograma do projeto. DeMarco e T. Os problemas de gerenciamento de software não mudaram desde a década de 1960 e este é um dos melhores livros sobre o assunto.6 5.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 orçamento. e diagramas de barras. 2003. a tarefa T5 leve 40 dias. P. O software é intanglvel.) The mythical man month (anniversary edirion). liste as dificuldades de gerenciamento nesses projetos de programação que falharam. (F.8 . 11 Os principais riscos do projeto devem ser identificados e avaliados para definir sua probabilidade e as conseqüências para o projeto. (T. Lister. Elescontinuam ao longo de um projeto. Usando os exemplos de problemas de projeto apresentados na literatura. o melhor livro disponivel sobre esse assunto. Elas incluem'diagramas de atividades. os planos e os cronogramas devem ser revísado~. (M. 11 O gerenciamento de software é diferente do gerenciamento em outras áreas da engenharia. em vez de levar 10 dias. Dorset House. O planejamento e a elaboração de estimativas são processos iterativos.3 5. Reviseo diagrama de atividades de acordo com a nova situação. Explique brevemente o propósito de cada uma das seções em um plano de projeto de software. Explique por que o processo de planejamento de software é iterativo e por que um plano deve ser continuamente revisado durante um projeto de software. 1995.) Consulte a Parte 6 para obter outras indicações de leituras sobre gerenciamento. Um produto é um marco disponibili~ado para o cliente do projeto. que mostram os inter-relacionamentos entre as atividades de projeto.) Software project survival guide.4 5. Explique por que os melhores programadores nem sempre se tornam os melhores gerentes de software.-- 5.) Managing software quality and business risk. A Tabela 5.2 apresenta as durações das atividades de projeto de software. que mostre como o projeto pode ser reorganizado. 199B. Os projetos podem ser ·novos ou inovadores. portanto.8 estabelece uma série de atividades. o sistema operacional IBM 051360. gerenciar ou lidar com os prováveis riscos se ou quando eles ocorrerem. McConneli. provavelmente. Os riscos devem ser explicitamente discutidos em cada reunião de progresso do projeto.5 5.1 5. O Capitulo 3 deste livro é simplesmente a melhor explicação sobre riscos que já vi. conforme sugerido em Leituras Sugeridas). As atividades mais significativas são planejamento. MICrosoft Press. Addison-Wesley. Pode ser útil basear sua resposta na lista de atividades de gerenciamento apresentada na Seção 5. mas contém recomendações de boas práticas. A edição de aniversáriO (publicada 20 anos após a edição original em 1975) inclui outros artigos clássicos de Brooks.1.7 Explique por que a intangibilidade dos sistemas de software apresenta problemas especiais ao gerenciamento de projetos de software. não existe um conjunto de experiências para guiar seu gerenciamento. (Sugiro que você comece com o livro de Brooks. ressaltando o novo caminho principal. 1999.

nos quais o fornecedor oferece um preço fixo para concluir o desenvolvimento de um sistema. Todos os membros da equipe têm filhos pequenos. Se algo der errado. Sugira como o uso de tais contratos pode aumentar a probabilidade de ocorrência de riscos de produto. o fornecedor deve pagar. podem ser usados para passar o risco do projeto do cliente para o fornecedor.4.Capítulo 5 Tabela 5. 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 remuneração.9 Alêm dos riscos apresentados na Tabela 5. . mas sente que pode prestar uma contribuição mais eficiente na função técnica do que na administrativa. você recebe uma promoção para gerente de projeto. Explique se você deve aceitar esse pedido de seu gerente ou se você deve persuadir sua equipe a dar seu tempo para a organização em vez de a suas famílias. Os contratos de preço fixo. Que fatores podem ser significativos para sua decisão? Como programador. identifique seis outros riscos possíveis que podem surgir em projetos de software.8 Durações e dependências de tarefas Tarefa Duração (dias) li Gerenciamento de projetos 75 Dependências 5. Explique se vocÊ deve aceitar a promoção.

Sign up to vote on this title
UsefulNot useful