1 > Livro: Software Engineering> Autor: Roger S. Pressman > Editora McGraw-Hill> Capítulos 5 e 7.

1

>> Livro: Software Engineering Livro: Software Engineering >> Autor: Roger S. Pressman Autor: Roger S. Pressman

>> Editora McGraw-Hill Editora McGraw-Hill >> Capítulos 5 e 7 Capítulos 5 e 7

2

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software

IntroduçãoIntrodução Escopo do SoftwareEscopo do Software RecursosRecursos Estimativa de Projeto de SoftwareEstimativa de Projeto de Software Relacionamento entre Pessoas e EsforçoRelacionamento entre Pessoas e Esforço Distribuição do EsforçoDistribuição do Esforço Determinação de Cronogramas Rastreamento e Controle de Projeto Plano de Projeto de Software

3

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareIntroduçãoIntrodução

Tempo: O mais valioso bem disponível a um Tempo: O mais valioso bem disponível a um

engenheiro de software. Se houver tempo engenheiro de software. Se houver tempo

disponível suficiente:disponível suficiente:– Um problema pode ser adequado/ analisado;Um problema pode ser adequado/ analisado;– Uma solução pode ser compreensiva/ projetada;Uma solução pode ser compreensiva/ projetada;– O código-fonte deve ser cuidadosamente O código-fonte deve ser cuidadosamente

implementado; e implementado; e

– O programa, deve ser minuciosamente testado.O programa, deve ser minuciosamente testado.

4

Planejamento de Projeto de SofwarePlanejamento de Projeto de Sofware IntroduçãoIntrodução

Um projeto é planejado e tem seu cronograma Um projeto é planejado e tem seu cronograma

determinado casualmente;determinado casualmente;

Os riscos são considerados somente depois que Os riscos são considerados somente depois que

eles se transformaram em problemas completos; eles se transformaram em problemas completos;

ee

As pessoas não são organizadas de uma forma As pessoas não são organizadas de uma forma

que agilize o progresso.que agilize o progresso.

O planejamento de projetos de software obriga O planejamento de projetos de software obriga

gerentes e profissionais a despender tempo para gerentes e profissionais a despender tempo para

organizar “suas ações”.organizar “suas ações”.

5

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software IntroduçãoIntrodução

Após compreender os requisitos funcionais do Após compreender os requisitos funcionais do

software, restrições relativas ao sistema e software, restrições relativas ao sistema e

preocupações de confiabilidade, o planejador preocupações de confiabilidade, o planejador

aplica técnicas e ferramentas para deduzir aplica técnicas e ferramentas para deduzir

estimativas de esforço e de tempo.estimativas de esforço e de tempo.

Estimativas oferecem informações úteis somente Estimativas oferecem informações úteis somente

se estiverem integradas em uma estrutura de se estiverem integradas em uma estrutura de

planejamento mais completa. planejamento mais completa.

6

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software IntroduçãoIntrodução

Objetivos do Planejamento de Projeto:Objetivos do Planejamento de Projeto:

– Fornecer uma estrutura que permita o gerente fazer Fornecer uma estrutura que permita o gerente fazer

estimativas de recursos, custo e cronograma.estimativas de recursos, custo e cronograma.

Antes de iniciarmos o planejamento de projeto, Antes de iniciarmos o planejamento de projeto,

devemos:devemos:

– responder a algumas questões sobre riscos;responder a algumas questões sobre riscos;

– desenvolver estratégia para atacar o problema;desenvolver estratégia para atacar o problema;

– estabelecer mecanismo para avaliar o progresso;estabelecer mecanismo para avaliar o progresso;

– organizar a equipe escolhida para construir o software. organizar a equipe escolhida para construir o software.

7

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareEscopo do SoftwareEscopo do Software

O escopo do software descreve função, O escopo do software descreve função, desempenho, restrições, interfaces e confiabilidadedesempenho, restrições, interfaces e confiabilidade

O escopo do software é definido através da O escopo do software é definido através da comunicação entre o cliente e o analista de comunicação entre o cliente e o analista de sistemas.sistemas.

Exemplo de técnica de comunicação usada:Exemplo de técnica de comunicação usada:– FAST FAST (Facilitated Application Specification (Facilitated Application Specification

Techniques)Techniques)

8

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareRecursosRecursos

Pessoas

Componentes de Software Reusável

Ferramentas de Hardware/Software

9

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareEstimativa de Projeto de SoftwareEstimativa de Projeto de Software

Custo e esforço de software nunca serão uma Custo e esforço de software nunca serão uma ciência exata. ciência exata.

Muitas variáveis - humana, técnica, ambiental, Muitas variáveis - humana, técnica, ambiental, política - podem afetar o custo final de software e política - podem afetar o custo final de software e o esforço aplicado ao seu desenvolvimento.o esforço aplicado ao seu desenvolvimento.

Entretanto, estimativa de projeto de software pode Entretanto, estimativa de projeto de software pode ser transformada de uma arte misteriosa a uma ser transformada de uma arte misteriosa a uma série de passos sistemáticos que fornecem série de passos sistemáticos que fornecem estimativas com risco aceitável.estimativas com risco aceitável.

10

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareEstimativa de Projeto de SoftwareEstimativa de Projeto de Software

Para ativar custo confiável e estimativa de esforço, Para ativar custo confiável e estimativa de esforço, existem várias opções:existem várias opções:– Estimativa de atraso no projeto;Estimativa de atraso no projeto;– Estimativa baseada em projetos similares que já Estimativa baseada em projetos similares que já

tenham sido completados;tenham sido completados;– Uso relativamente simples de “técnicas de Uso relativamente simples de “técnicas de

decomposição” para gerar custo de projeto e decomposição” para gerar custo de projeto e estimativas de esforço;estimativas de esforço;

– Uso de um ou mais modelos empíricos para Uso de um ou mais modelos empíricos para estimativa de custo e esforço do software.estimativa de custo e esforço do software.

11


Relacionamento entre Pessoas e EsforçoRelacionamento entre Pessoas e Esforço

Em um projeto de desenvolvimento de software Em um projeto de desenvolvimento de software pequeno, uma única pessoa pode analisar os pequeno, uma única pessoa pode analisar os requisitos, executar o projeto, gerar o código e requisitos, executar o projeto, gerar o código e realizar testes. realizar testes.

À medida que o tamanho do projeto aumenta, À medida que o tamanho do projeto aumenta, mais pessoas devem ser envolvidas.mais pessoas devem ser envolvidas.

Há um mito comum no qual muitos gerentes que Há um mito comum no qual muitos gerentes que são responsáveis pelo esforço de desenvolvimento são responsáveis pelo esforço de desenvolvimento ainda acreditam:ainda acreditam:

12

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareRelacionamento entre Pessoas e EsforçoRelacionamento entre Pessoas e Esforço

““...se nos atrasarmos, sempre poderemos ...se nos atrasarmos, sempre poderemos acrescentar mais programadores e posteriormente acrescentar mais programadores e posteriormente sairmos do atraso do projeto...”. sairmos do atraso do projeto...”.

Acrescentar pessoas tardiamente num projeto Acrescentar pessoas tardiamente num projeto

muitas vezes tem um efeito desintegrador sobre o muitas vezes tem um efeito desintegrador sobre o

projeto, fazendo com que o cronograma fuja ainda projeto, fazendo com que o cronograma fuja ainda

mais do controle. mais do controle.

13

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareRelacionamento entre Pessoas e EsforçoRelacionamento entre Pessoas e Esforço

As pessoas que são incluídas no sistema, e as As pessoas que são incluídas no sistema, e as pessoas que as ensinam são as mesmas que estão pessoas que as ensinam são as mesmas que estão realizando o trabalho. Enquanto estão ensinando, realizando o trabalho. Enquanto estão ensinando, nenhum trabalho é feitonenhum trabalho é feito

Além do tempo despendido para se aprender o Além do tempo despendido para se aprender o sistema, um número maior de pessoas aumenta o sistema, um número maior de pessoas aumenta o número de canais de comunicação e a número de canais de comunicação e a complexidade desta ao longo de um projeto. complexidade desta ao longo de um projeto.

* novo canal de comunicação => esforço e tempo * novo canal de comunicação => esforço e tempo adicional.adicional.

14

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareDistribuição do EsforçoDistribuição do Esforço

Cada uma das técnicas de estimativa de projetos Cada uma das técnicas de estimativa de projetos de software leva a estimativas de pessoas-mês (ou de software leva a estimativas de pessoas-mês (ou pessoas-ano) exigidas para se concluir o pessoas-ano) exigidas para se concluir o desenvolvimento do software. desenvolvimento do software.

Essa distribuição, outrora chamada regra 40-20-Essa distribuição, outrora chamada regra 40-20-40, enfatiza as tarefas de análise e projeto 40, enfatiza as tarefas de análise e projeto realizadas no início do projeto e os testes realizadas no início do projeto e os testes realizados no final.realizados no final.

15


Análise e Análise e projetoprojeto

(40 - 40%)(40 - 40%)

Atividade Atividade de testes e de testes e depuração depuração (30 - 40%)(30 - 40%)

Codificação Codificação (15 - 20%)(15 - 20%)

16


Atualmente, mais de 40% de todo o esforço de Atualmente, mais de 40% de todo o esforço de projeto freqüentemente é recomendado para as projeto freqüentemente é recomendado para as tarefas de análise e projeto de grande projetos de tarefas de análise e projeto de grande projetos de desenvolvimento de software. Portanto, a regra desenvolvimento de software. Portanto, a regra 40-20-40 não mais se aplica num sentido estrito.40-20-40 não mais se aplica num sentido estrito.

A distribuição de esforço ilustrada na figura deve A distribuição de esforço ilustrada na figura deve ser usada somente como uma diretriz.ser usada somente como uma diretriz.

As características de cada projeto devem ditar a As características de cada projeto devem ditar a distribuição do esforço.distribuição do esforço.

17


O esforço despendido em planejamento de projeto O esforço despendido em planejamento de projeto raramente é responsável por mais do que 2 a 3% raramente é responsável por mais do que 2 a 3% do esforço total, a menos que o plano envolva do esforço total, a menos que o plano envolva grandes dispêndios com riscos.grandes dispêndios com riscos.

A análise de requisitos pode envolver de 10 a 25% A análise de requisitos pode envolver de 10 a 25% do esforço de projeto.do esforço de projeto.

O esforço despendido em análise ou construção de O esforço despendido em análise ou construção de protótipos deve elevar-se em proporção direta com protótipos deve elevar-se em proporção direta com o tamanho e a complexidade do projeto.o tamanho e a complexidade do projeto.

18


Uma margem de 20 a 25% do esforço normalmente Uma margem de 20 a 25% do esforço normalmente é aplicada no projeto de software.é aplicada no projeto de software.

O tempo gasto na revisão do projeto e na O tempo gasto na revisão do projeto e na subseqüente iteração também deve ser considerado.subseqüente iteração também deve ser considerado.

Por causa do esforço aplicado no projeto de Por causa do esforço aplicado no projeto de software, o código se desenvolverá com pouca software, o código se desenvolverá com pouca dificuldade.dificuldade.

Uma margem de 15 a 20% do esforço global pode Uma margem de 15 a 20% do esforço global pode ser conseguida.ser conseguida.

19


O teste e a subseqüente depuração podem ser O teste e a subseqüente depuração podem ser responsáveis por uma margem de 30 a 40% do responsáveis por uma margem de 30 a 40% do esforço de desenvolvimento do software.esforço de desenvolvimento do software.

A condição crítica do software muitas vezes dita a A condição crítica do software muitas vezes dita a quantidade de teste que é exigida.quantidade de teste que é exigida.

Se o software for Se o software for human-ratedhuman-rated (isto é, falha de (isto é, falha de software que pode resultar em perdas de vidas software que pode resultar em perdas de vidas humanas), percentagens mais elevadas podem ser humanas), percentagens mais elevadas podem ser consideradas.consideradas.

20

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software Determinação de CronogramasDeterminação de Cronogramas

A determinação de um cronograma para projetos A determinação de um cronograma para projetos de desenvolvimento de software pode ser vista a de desenvolvimento de software pode ser vista a partir de duas perspectivas bem diferentes. partir de duas perspectivas bem diferentes. – Na primeira, uma data final para a entrega de um Na primeira, uma data final para a entrega de um

sistema baseado em computador já foi (e de maneira sistema baseado em computador já foi (e de maneira irrevogável) estabelecida. A organização é obrigada a irrevogável) estabelecida. A organização é obrigada a distribuir o esforço dentro do espaço de tempo previsto.distribuir o esforço dentro do espaço de tempo previsto.

– A segunda presume que limites cronológicos A segunda presume que limites cronológicos aproximados tenham sido discutidos, mas que a data aproximados tenham sido discutidos, mas que a data final seja estabelecida pela organização de engenharia final seja estabelecida pela organização de engenharia de software. O esforço é distribuído para que se possa de software. O esforço é distribuído para que se possa tirar melhor proveito dos recursos e uma data final é tirar melhor proveito dos recursos e uma data final é definida após cuidadosa análise. definida após cuidadosa análise.

21


A precisão na determinação de um cronograma às A precisão na determinação de um cronograma às vezes pode ser bem mais importante do que a vezes pode ser bem mais importante do que a precisão na determinação dos custos. precisão na determinação dos custos.

Num ambiente orientado ao produto, os custos Num ambiente orientado ao produto, os custos adicionados podem ser absorvidos por nova adicionados podem ser absorvidos por nova determinação de preços ou por amortização ao determinação de preços ou por amortização ao longo de um grande número de vendas.longo de um grande número de vendas.

Um cronograma descumprido, porém, pode Um cronograma descumprido, porém, pode reduzir o impacto de mercado, criar clientes reduzir o impacto de mercado, criar clientes insatisfeitos e elevar os custos internos.insatisfeitos e elevar os custos internos.

22


Quando abordamos a fixação de prazos para Quando abordamos a fixação de prazos para projetos de software, uma série de perguntas pode projetos de software, uma série de perguntas pode ser feita.ser feita.– Como relacionamos o tempo cronológico com o Como relacionamos o tempo cronológico com o

esforço humano?esforço humano?

– Quais tarefas e paralelismos podem ser esperados?Quais tarefas e paralelismos podem ser esperados?

– Quais marcos de referência podem ser usados para Quais marcos de referência podem ser usados para mostrar o progresso?mostrar o progresso?

23


– Como o esforço é distribuído ao longo do processo de Como o esforço é distribuído ao longo do processo de engenharia de software?engenharia de software?

– Existem métodos disponíveis de determinação de Existem métodos disponíveis de determinação de prazos?prazos?

– Como representaremos fisicamente o cronograma e Como representaremos fisicamente o cronograma e como rastrearemos o progresso quando o projeto se como rastrearemos o progresso quando o projeto se iniciar?iniciar?

24


A determinação de um cronograma para um A determinação de um cronograma para um

projeto de software não difere significativamente projeto de software não difere significativamente

da fixação de prazos para qualquer esforço de da fixação de prazos para qualquer esforço de

desenvolvimento de multitarefas.desenvolvimento de multitarefas.

Ferramentas e técnicas para determinação de um Ferramentas e técnicas para determinação de um

cronograma de projeto podem ser aplicadas no cronograma de projeto podem ser aplicadas no

software com poucas modificações.software com poucas modificações.

25


Fases, passos e atividades num projetoFases, passos e atividades num projeto

26


Gráfico de atividades para a construção de uma casaGráfico de atividades para a construção de uma casa

27


Gráfico de atividades com duraçõesGráfico de atividades com durações

28


Determinação de CronogramasDeterminação de Cronogramas

O PERT - O PERT - Program Evaluation and ReviewProgram Evaluation and Review TechniqueTechnique ( (método de avaliação e revisãométodo de avaliação e revisão dede programaprograma) e o CPM - ) e o CPM - Critical Path Critical Path MethodMethod ( (método do caminho críticométodo do caminho crítico) são ) são dois métodos de determinação de dois métodos de determinação de cronogramas que podem ser aplicados no cronogramas que podem ser aplicados no desenvolvimento de software. desenvolvimento de software.

29



Ambas as técnicas são dirigidas por informações Ambas as técnicas são dirigidas por informações

já desenvolvidas em atividades de planejamento já desenvolvidas em atividades de planejamento

de projeto anterior:de projeto anterior:– estimativas de esforço;estimativas de esforço;

– uma decomposição de função de produto;uma decomposição de função de produto;

– a seleção do modelo de processo apropriado;a seleção do modelo de processo apropriado;

– a seleção de tipo de projeto e conjunto de tarefas.a seleção de tipo de projeto e conjunto de tarefas.

30



Independências entre tarefas pode ser definida Independências entre tarefas pode ser definida

usando uma rede de tarefa.usando uma rede de tarefa.

Tarefas, algumas vezes chamadas WBS - Tarefas, algumas vezes chamadas WBS - Work Work

Breakdow StructureBreakdow Structure ( (estrutura de divisão deestrutura de divisão de

trabalhotrabalho), são definidas para o produto como um ), são definidas para o produto como um

todo ou para funções individuais.todo ou para funções individuais.

Uma rede de tarefa é uma representação gráfica do Uma rede de tarefa é uma representação gráfica do

fluxo de tarefa para um projeto.fluxo de tarefa para um projeto.

31


CPM bar chartCPM bar chart

32


Exemplo de Work Breakdown Structure (WBS)Exemplo de Work Breakdown Structure (WBS)

33


Gantt chart para o exemplo de WBSGantt chart para o exemplo de WBS

34


Tanto o PERT como o CPM proporcionam Tanto o PERT como o CPM proporcionam ferramentas quantitativas que permitem ao ferramentas quantitativas que permitem ao planejador de software:planejador de software:– determinar o caminho crítico - a cadeia de tarefas determinar o caminho crítico - a cadeia de tarefas

que determina a duração do projeto;que determina a duração do projeto;

– estabelecer as estimativas de tempo estabelecer as estimativas de tempo mais prováveismais prováveis para tarefas individuais ao aplicar modelos para tarefas individuais ao aplicar modelos estatísticos; e estatísticos; e

– calcular limites de tempo que definam uma “janela” calcular limites de tempo que definam uma “janela” de tempo para uma tarefa em particular.de tempo para uma tarefa em particular.

35


Cálculos de limite de tempo podem ser muito úteis Cálculos de limite de tempo podem ser muito úteis

na determinação de um cronograma para projetos na determinação de um cronograma para projetos

de software.de software.

Deslize no projeto de uma função, por exemplo, Deslize no projeto de uma função, por exemplo,

pode retardar ainda mais o desenvolvimento de pode retardar ainda mais o desenvolvimento de

outras funções.outras funções.

36


Importantes limites de tempo que podem ser Importantes limites de tempo que podem ser reconhecidos numa rede PERT ou CPM:reconhecidos numa rede PERT ou CPM:1)1) o tempo mais cedo em que uma tarefa pode iniciar-se o tempo mais cedo em que uma tarefa pode iniciar-se

quando todas as tarefas precedentes foram completadas quando todas as tarefas precedentes foram completadas no tempo mais curto possível; no tempo mais curto possível;

2)2) o tempo mais tarde para o início da tarefa antes que o o tempo mais tarde para o início da tarefa antes que o tempo de conclusão mínimo do projeto seja atrasado;tempo de conclusão mínimo do projeto seja atrasado;

3)3) o término mais breve - a soma do início mais cedo com o término mais breve - a soma do início mais cedo com a duração da tarefa;a duração da tarefa;

37



4)4) o término mais tardio - o momento de início mais tarde o término mais tardio - o momento de início mais tarde somado à duração da tarefa;somado à duração da tarefa;

5)5) a flutuação total - a quantidade de superávit de tempo a flutuação total - a quantidade de superávit de tempo

ou margem de segurança permitida nas tarefas, ou margem de segurança permitida nas tarefas,

determinação de prazos de forma que o caminho crítico da determinação de prazos de forma que o caminho crítico da

rede seja mantido dentro do prazo.rede seja mantido dentro do prazo.

38



Os cálculos de tempo-limite levam à determinação Os cálculos de tempo-limite levam à determinação do caminho crítico e proporcionam ao gerente um do caminho crítico e proporcionam ao gerente um método quantitativo para avaliar o progresso à método quantitativo para avaliar o progresso à medida que as tarefas são concluídas. medida que as tarefas são concluídas.

O planejador deve reconhecer que o esforço de O planejador deve reconhecer que o esforço de manutenção, ainda que não seja fácil de programar manutenção, ainda que não seja fácil de programar neste estágio, tornar-se-á, por fim, o maior fator de neste estágio, tornar-se-á, por fim, o maior fator de custo.custo.

39


PERT e CPM foram implementadas em uma PERT e CPM foram implementadas em uma grande variedade de ferramentas automatizadas grande variedade de ferramentas automatizadas que estão disponíveis para todos os computadores que estão disponíveis para todos os computadores pessoais. pessoais.

Tais ferramentas são relativamente fáceis de serem Tais ferramentas são relativamente fáceis de serem usadas e tornam os métodos de análise disponíveis usadas e tornam os métodos de análise disponíveis para todos os gerentes de projetos de software.para todos os gerentes de projetos de software.

40

Planejamento de Projeto de SoftwarePlanejamento de Projeto de SoftwareRastreamento e Controle de ProjetoRastreamento e Controle de Projeto

Há um ditado que diz: “Os projetos de software Há um ditado que diz: “Os projetos de software atrasam-se em seu cronograma um dia de cada atrasam-se em seu cronograma um dia de cada vez”. O atraso de um dia na programação vez”. O atraso de um dia na programação raramente será fatal para um projeto. Mas os dias raramente será fatal para um projeto. Mas os dias se somam e, ao longo da extensão de um projeto, se somam e, ao longo da extensão de um projeto, pequenos atrasos podem resultar em grandes pequenos atrasos podem resultar em grandes problemas. problemas.

Um dos papéis da administração é rastrear e Um dos papéis da administração é rastrear e controlar o projeto de software assim que ele é controlar o projeto de software assim que ele é iniciado. iniciado.

41


O O rastreamento rastreamento ((trackingtracking) pode ser feito de muitas ) pode ser feito de muitas maneiras diferentes:maneiras diferentes:– Realizando-se reuniões sobre a situação do projeto, em Realizando-se reuniões sobre a situação do projeto, em

que cada membro da equipe relate o progresso e os que cada membro da equipe relate o progresso e os problemas. problemas.

– Avaliando-se os resultados de todas as revisões realizadas Avaliando-se os resultados de todas as revisões realizadas ao longo do processo de engenharia de software.ao longo do processo de engenharia de software.

– Determinando-se se os marcos de referência de projeto Determinando-se se os marcos de referência de projeto formais foram atingidos até a data programada.formais foram atingidos até a data programada.

42


Rastreamento e Controle de ProjetoRastreamento e Controle de Projeto

– Comparando-se a data de início real com a data de Comparando-se a data de início real com a data de

início planejada para cada tarefa de projeto relacionada início planejada para cada tarefa de projeto relacionada

na tabela de recursos.na tabela de recursos.

– Reunindo-se informalmente com profissionais para se Reunindo-se informalmente com profissionais para se obter suas avaliações subjetivas do progresso até o obter suas avaliações subjetivas do progresso até o momento e os problemas que aparecem no horizonte.momento e os problemas que aparecem no horizonte.

– Todas essas técnicas de rastreamento são usadas por Todas essas técnicas de rastreamento são usadas por

gerentes de projeto experientes.gerentes de projeto experientes.

43


O O controlecontrole é empregado por um gerente de projetos de é empregado por um gerente de projetos de software para administrar os recursos do projeto, enfrentar software para administrar os recursos do projeto, enfrentar problemas e dirigir o pessoal do projeto.problemas e dirigir o pessoal do projeto.

Se o projeto estiver no prazo e dentro do orçamento, as Se o projeto estiver no prazo e dentro do orçamento, as revisões indicarem progresso real e os marcos estiverem revisões indicarem progresso real e os marcos estiverem sendo atingidos, o controle é leve.sendo atingidos, o controle é leve.

Quando ocorrerem problemas, o gerente de projetos deverá Quando ocorrerem problemas, o gerente de projetos deverá exercer o controle para saná-los o mais rapidamente exercer o controle para saná-los o mais rapidamente possível.possível.

Depois que o problema tiver sido diagnosticado, recursos Depois que o problema tiver sido diagnosticado, recursos adicionais podem ser concentrados na área de problema; o adicionais podem ser concentrados na área de problema; o pessoal pode novamente ser disposto ou a programação do pessoal pode novamente ser disposto ou a programação do projeto, redefinida. projeto, redefinida.

44

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software Processo de Planejamento de ProjetoProcesso de Planejamento de Projeto

1) Estabelecer a data de início do projeto1) Estabelecer a data de início do projeto

2) Estabelecer a data final do projeto2) Estabelecer a data final do projeto

3) Estabelecer a metodologia de projeto ou ciclo de 3) Estabelecer a metodologia de projeto ou ciclo de vida do projeto a ser usadovida do projeto a ser usado

4) Determinar o escopo do projeto em termos das 4) Determinar o escopo do projeto em termos das fases da metodologia ou do ciclo de vida do projeto fases da metodologia ou do ciclo de vida do projeto

5) Identificar ou selecionar os métodos de revisão a 5) Identificar ou selecionar os métodos de revisão a serem usadosserem usados

45


6) Identificar qualquer 6) Identificar qualquer milestonemilestone (conclusão de uma (conclusão de uma atividade) predeterminado ou outras datas críticas atividade) predeterminado ou outras datas críticas que devem ser encontradasque devem ser encontradas

7) Listar tarefas, por fase do projeto, a fim de que 7) Listar tarefas, por fase do projeto, a fim de que elas possam ser acompanhadaselas possam ser acompanhadas

8) Estimar o pessoal necessário para acompanhar 8) Estimar o pessoal necessário para acompanhar cada tarefacada tarefa

9) Estimar o pessoal disponível para acompanhar 9) Estimar o pessoal disponível para acompanhar cada tarefacada tarefa

46


10) Determinar nível de perfil necessário para 10) Determinar nível de perfil necessário para desempenhar cada tarefadesempenhar cada tarefa

11) Determinar dependências de tarefa11) Determinar dependências de tarefa– Quais tarefas podem ser feitas em paraleloQuais tarefas podem ser feitas em paralelo– Quais tarefas requerem estar completas para Quais tarefas requerem estar completas para

que outras tarefas possam iniciarque outras tarefas possam iniciar

12) Projetar pontos de controle ou de revisão12) Projetar pontos de controle ou de revisão

13) Realizar estimativa de custo de projeto e análise 13) Realizar estimativa de custo de projeto e análise de custo x benefíciode custo x benefício

47

Planejamento de Projeto de SoftwarePlanejamento de Projeto de Software Plano de Projeto de SoftwarePlano de Projeto de Software

Cada etapa do processo de engenharia de software Cada etapa do processo de engenharia de software deve produzir um resultado que possa ser revisado deve produzir um resultado que possa ser revisado e possa funcionar como uma base para os passos e possa funcionar como uma base para os passos que se seguirão.que se seguirão.

O O Plano de Projeto de SoftwarePlano de Projeto de Software é produzido ao é produzido ao término das tarefas de planejamento e fornece término das tarefas de planejamento e fornece informações básicas sobre o custo e programação informações básicas sobre o custo e programação de recursos que serão usadas ao longo do processo de recursos que serão usadas ao longo do processo de engenharia de softwarede engenharia de software

48


Plano de Projeto de SoftwarePlano de Projeto de Software

O O Plano de Projeto de Software Plano de Projeto de Software deve: deve:

1.1. Comunicar o escopo e os recursos à administração, ao Comunicar o escopo e os recursos à administração, ao pessoal técnico e ao cliente do software;pessoal técnico e ao cliente do software;

22. Definir os riscos e sugerir técnicas para evitá-los; . Definir os riscos e sugerir técnicas para evitá-los;

3.3. Definir custos e prazos para as revisões administrativas; Definir custos e prazos para as revisões administrativas;

4.4. Oferecer uma abordagem global ao desenvolvimento do Oferecer uma abordagem global ao desenvolvimento do software para todas as pessoas envolvidas no projeto;software para todas as pessoas envolvidas no projeto;

5.5. Delinear como qualidade será garantida e mudanças serão Delinear como qualidade será garantida e mudanças serão gerenciadas.gerenciadas.

49


O O Plano de Projeto de SoftwarePlano de Projeto de Software não precisa ser não precisa ser um documento extenso e complexo. Seu propósito um documento extenso e complexo. Seu propósito é ajudar a estabelecer a viabilidade do esforço de é ajudar a estabelecer a viabilidade do esforço de desenvolvimento.desenvolvimento.

O plano concentra-se na declaração geral do “o O plano concentra-se na declaração geral do “o que” e na declaração específica de “quanto” e “por que” e na declaração específica de “quanto” e “por quanto tempo”.quanto tempo”.

As etapas subseqüentes do processo de engenharia As etapas subseqüentes do processo de engenharia de software concentrar-se-ão na definição, de software concentrar-se-ão na definição, desenvolvimento e manutenção.desenvolvimento e manutenção.

50

I. IntroduçãoI. Introdução

A. Propósito do planoA. Propósito do plano

B. Escopo do projeto e objetivosB. Escopo do projeto e objetivos1. Declaração do escopo1. Declaração do escopo2. Funções principais2. Funções principais3. Questões de 3. Questões de

desempenhodesempenho4. Restrições técnicas e de 4. Restrições técnicas e de

gerenciamento gerenciamento

II. Estimativas de projetoII. Estimativas de projeto

A. Dados históricos usadosA. Dados históricos usados

B. Técnicas de estimativasB. Técnicas de estimativas

3. Estimativas de esforço, custo e 3. Estimativas de esforço, custo e

duraçãoduração

III. Estratégia de Gerenc. de RiscosIII. Estratégia de Gerenc. de Riscos

A. Tabela de riscos.A. Tabela de riscos.

B. Discussão de riscos a gerenciarB. Discussão de riscos a gerenciar

C. Plano RMMM para cada riscoC. Plano RMMM para cada risco1. Mitigação de risco1. Mitigação de risco2. Monitoração de risco2. Monitoração de risco3. Gerenciamento de risco3. Gerenciamento de risco

IV. CronogramaIV. Cronograma

A. Divisão de trabalho no projetoA. Divisão de trabalho no projeto

B. Rede de tarefasB. Rede de tarefas

C. Gráfico de C. Gráfico de timeline timeline (gráfico de (gráfico de Gantt)Gantt)

D. Tabela de recursosD. Tabela de recursos

V. Recursos do projetoV. Recursos do projeto

A. PessoalA. Pessoal

B. Hardware e softwareB. Hardware e software

C. Recursos especiaisC. Recursos especiais

VI. Organização do pessoalVI. Organização do pessoal

A. Estrutura de equipe (se for o A. Estrutura de equipe (se for o caso)caso)

B. Relatórios administrativosB. Relatórios administrativos

VII. Mecanismos de rastreamemto e VII. Mecanismos de rastreamemto e controlecontrole

A. Garantia e controle de qualidadeA. Garantia e controle de qualidade

B. Gerenciamento e controle deB. Gerenciamento e controle de

mudançasmudanças

VIII. Apêndices.VIII. Apêndices.


1 > Livro: Software Engineering> Autor: Roger S. Pressman > Editora McGraw-Hill> Capítulos 5 e 7.

Documents

Transcript of 1 > Livro: Software Engineering> Autor: Roger S. Pressman > Editora McGraw-Hill> Capítulos 5 e 7.