Livro Software Engineering Autor Roger S Pressman Editora

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

Planejamento de Projeto de Software n n n n n Introdução Escopo do Software Recursos Estimativa de Projeto de Software Relacionamento entre Pessoas e Esforço Distribuição do Esforço Determinação de Cronogramas Rastreamento e Controle de Projeto Plano de Projeto de Software 2

Planejamento de Projeto de Software Introdução n Tempo: O mais valioso bem disponível a um engenheiro de software. Se houver tempo disponível suficiente: – Um problema pode ser adequado/ analisado; – Uma solução pode ser compreensiva/ projetada; – O código-fonte deve ser cuidadosamente implementado; e – O programa, deve ser minuciosamente testado. 3

Planejamento de Projeto de Sofware Introdução n Um projeto é planejado e tem seu cronograma determinado casualmente; n Os riscos são considerados somente depois que eles se transformaram em problemas completos; e n As pessoas não são organizadas de uma forma que agilize o progresso. n O planejamento de projetos de software obriga gerentes e profissionais a despender tempo para organizar “suas ações”. 4

Planejamento de Projeto de Software Introdução n Após compreender os requisitos funcionais do software, restrições relativas ao sistema e preocupações de confiabilidade, o planejador aplica técnicas e ferramentas para deduzir estimativas de esforço e de tempo. n Estimativas oferecem informações úteis somente se estiverem integradas em uma estrutura de planejamento mais completa. 5

Planejamento de Projeto de Software Introdução n Objetivos do Planejamento de Projeto: – Fornecer uma estrutura que permita o gerente fazer estimativas de recursos, custo e cronograma. n Antes de iniciarmos o planejamento de projeto, devemos: – responder a algumas questões sobre riscos; – desenvolver estratégia para atacar o problema; – estabelecer mecanismo para avaliar o progresso; – organizar a equipe escolhida para construir o software. 6

Planejamento de Projeto de Software Escopo do Software n n n O escopo do software descreve função, desempenho, restrições, interfaces e confiabilidade O escopo do software é definido através da comunicação entre o cliente e o analista de sistemas. Exemplo de técnica de comunicação usada: – FAST (Facilitated Application Specification Techniques) 7

Planejamento de Projeto de Software Recursos Pessoas Componentes de Software Reusável Ferramentas de Hardware/Software 8

Planejamento de Projeto de Software Estimativa de Projeto de Software n n n Custo e esforço de software nunca serão uma ciência exata. Muitas variáveis - humana, técnica, ambiental, política - podem afetar o custo final de software e o esforço aplicado ao seu desenvolvimento. Entretanto, estimativa de projeto de software pode ser transformada de uma arte misteriosa a uma série de passos sistemáticos que fornecem estimativas com risco aceitável. 9

Planejamento de Projeto de Software Estimativa de Projeto de Software n Para ativar custo confiável e estimativa de esforço, existem várias opções: – Estimativa de atraso no projeto; – Estimativa baseada em projetos similares que já tenham sido completados; – Uso relativamente simples de “técnicas de decomposição” para gerar custo de projeto e estimativas de esforço; – Uso de um ou mais modelos empíricos para estimativa de custo e esforço do software. 10

Planejamento de Projeto de Software Relacionamento entre Pessoas e Esforço n n n Em um projeto de desenvolvimento de software pequeno, uma única pessoa pode analisar os requisitos, executar o projeto, gerar o código e realizar testes. À medida que o tamanho do projeto aumenta, mais pessoas devem ser envolvidas. Há um mito comum no qual muitos gerentes que são responsáveis pelo esforço de desenvolvimento ainda acreditam: 11

Planejamento de Projeto de Software Relacionamento entre Pessoas e Esforço n “. . . se nos atrasarmos, sempre poderemos acrescentar mais programadores e posteriormente sairmos do atraso do projeto. . . ”. n Acrescentar pessoas tardiamente num projeto muitas vezes tem um efeito desintegrador sobre o projeto, fazendo com que o cronograma fuja ainda mais do controle. 12

Planejamento de Projeto de Software Relacionamento entre Pessoas e Esforço As pessoas que são incluídas no sistema, e as pessoas que as ensinam são as mesmas que estão realizando o trabalho. Enquanto estão ensinando, nenhum trabalho é feito n Além do tempo despendido para se aprender o sistema, um número maior de pessoas aumenta o número de canais de comunicação e a complexidade desta ao longo de um projeto. * novo canal de comunicação => esforço e tempo adicional. n 13

Planejamento de Projeto de Software Distribuição do Esforço n Cada uma das técnicas de estimativa de projetos de software leva a estimativas de pessoas-mês (ou pessoas-ano) exigidas para se concluir o desenvolvimento do software. n Essa distribuição, outrora chamada regra 40 -20 -40, enfatiza as tarefas de análise e projeto realizadas no início do projeto e os testes realizados no final. 14

Planejamento de Projeto de Software Distribuição do Esforço Análise e projeto (40 - 40%) Atividade de testes e depuração (30 - 40%) Codificação (15 - 20%) 15

Planejamento de Projeto de Software Distribuição do Esforço n Atualmente, mais de 40% de todo o esforço de projeto freqüentemente é recomendado para as tarefas de análise e projeto de grande projetos de desenvolvimento de software. Portanto, a regra 4020 -40 não mais se aplica num sentido estrito. n A distribuição de esforço ilustrada na figura deve ser usada somente como uma diretriz. As características de cada projeto devem ditar a distribuição do esforço. n 16

Planejamento de Projeto de Software Distribuição do Esforço n O esforço despendido em planejamento de projeto raramente é responsável por mais do que 2 a 3% do esforço total, a menos que o plano envolva grandes dispêndios com riscos. n A análise de requisitos pode envolver de 10 a 25% do esforço de projeto. O esforço despendido em análise ou construção de protótipos deve elevar-se em proporção direta com o tamanho e a complexidade do projeto. n 17

Planejamento de Projeto de Software Distribuição do Esforço n n Uma margem de 20 a 25% do esforço normalmente é aplicada no projeto de software. O tempo gasto na revisão do projeto e na subseqüente iteração também deve ser considerado. Por causa do esforço aplicado no projeto de software, o código se desenvolverá com pouca dificuldade. Uma margem de 15 a 20% do esforço global pode ser conseguida. 18

Planejamento de Projeto de Software Distribuição do Esforço n n n O teste e a subseqüente depuração podem ser responsáveis por uma margem de 30 a 40% do esforço de desenvolvimento do software. A condição crítica do software muitas vezes dita a quantidade de teste que é exigida. Se o software for human-rated (isto é, falha de software que pode resultar em perdas de vidas humanas), percentagens mais elevadas podem ser consideradas. 19

Planejamento de Projeto de Software Determinação de Cronogramas n A determinação de um cronograma para projetos de desenvolvimento de software pode ser vista a partir de duas perspectivas bem diferentes. – Na primeira, uma data final para a entrega de um sistema baseado em computador já foi (e de maneira irrevogável) estabelecida. A organização é obrigada a distribuir o esforço dentro do espaço de tempo previsto. – A segunda presume que limites cronológicos aproximados tenham sido discutidos, mas que a data final seja estabelecida pela organização de engenharia de software. O esforço é distribuído para que se possa tirar melhor proveito dos recursos e uma data final é definida após cuidadosa análise. 20

Planejamento de Projeto de Software Determinação de Cronogramas n n n A precisão na determinação de um cronograma às vezes pode ser bem mais importante do que a precisão na determinação dos custos. Num ambiente orientado ao produto, os custos adicionados podem ser absorvidos por nova determinação de preços ou por amortização ao longo de um grande número de vendas. Um cronograma descumprido, porém, pode reduzir o impacto de mercado, criar clientes insatisfeitos e elevar os custos internos. 21

Planejamento de Projeto de Software Determinação de Cronogramas n Quando abordamos a fixação de prazos para projetos de software, uma série de perguntas pode ser feita. – Como relacionamos o tempo cronológico com o esforço humano? – Quais tarefas e paralelismos podem ser esperados? – Quais marcos de referência podem ser usados para mostrar o progresso? 22

Planejamento de Projeto de Software Determinação de Cronogramas – Como o esforço é distribuído ao longo do processo de engenharia de software? – Existem métodos disponíveis de determinação de prazos? – Como representaremos fisicamente o cronograma e como rastrearemos o progresso quando o projeto se iniciar? 23

Planejamento de Projeto de Software Determinação de Cronogramas n A determinação de um cronograma para um projeto de software não difere significativamente da fixação de prazos para qualquer esforço de desenvolvimento de multitarefas. n Ferramentas e técnicas para determinação de um cronograma de projeto podem ser aplicadas no software com poucas modificações. 24

Planejamento de Projeto de Software Determinação de Cronogramas Fases, passos e atividades num projeto 25

Planejamento de Projeto de Software Determinação de Cronogramas Gráfico de atividades para a construção de uma casa 26

Planejamento de Projeto de Software Determinação de Cronogramas Gráfico de atividades com durações 27

Planejamento de Projeto de Software Determinação de Cronogramas n O PERT - Program Evaluation and Review Technique (método de avaliação e revisão de programa) e o CPM - Critical Path Method (método do caminho crítico) são dois métodos de determinação de cronogramas que podem ser aplicados no desenvolvimento de software. 28

Planejamento de Projeto de Software Determinação de Cronogramas n Ambas as técnicas são dirigidas por informações já desenvolvidas em atividades de planejamento de projeto anterior: – estimativas de esforço; – uma decomposição de função de produto; – a seleção do modelo de processo apropriado; – a seleção de tipo de projeto e conjunto de tarefas. 29

Planejamento de Projeto de Software Determinação de Cronogramas n Independências entre tarefas pode ser definida usando uma rede de tarefa. n Tarefas, algumas vezes chamadas WBS - Work Breakdow Structure (estrutura de divisão de trabalho), são definidas para o produto como um todo ou para funções individuais. n Uma rede de tarefa é uma representação gráfica do fluxo de tarefa para um projeto. 30

Planejamento de Projeto de Software Determinação de Cronogramas CPM bar chart 31

Planejamento de Projeto de Software Determinação de Cronogramas Exemplo de Work Breakdown Structure (WBS) 32

Planejamento de Projeto de Software Determinação de Cronogramas Gantt chart para o exemplo de WBS 33

Planejamento de Projeto de Software Determinação de Cronogramas n Tanto o PERT como o CPM proporcionam ferramentas quantitativas que permitem ao planejador de software: – determinar o caminho crítico - a cadeia de tarefas que determina a duração do projeto; – estabelecer as estimativas de tempo mais prováveis para tarefas individuais ao aplicar modelos estatísticos; e – calcular limites de tempo que definam uma “janela” de tempo para uma tarefa em particular. 34

Planejamento de Projeto de Software Determinação de Cronogramas n Cálculos de limite de tempo podem ser muito úteis na determinação de um cronograma para projetos de software. n Deslize no projeto de uma função, por exemplo, pode retardar ainda mais o desenvolvimento de outras funções. 35

Planejamento de Projeto de Software Determinação de Cronogramas n Importantes limites de tempo que podem ser reconhecidos numa rede PERT ou CPM: 1) o tempo mais cedo em que uma tarefa pode iniciar-se quando todas as tarefas precedentes foram completadas no tempo mais curto possível; 2) o tempo mais tarde para o início da tarefa antes que o tempo de conclusão mínimo do projeto seja atrasado; 3) o término mais breve - a soma do início mais cedo com a duração da tarefa; 36

Planejamento de Projeto de Software Determinação de Cronogramas 4) o término mais tardio - o momento de início mais tarde somado à duração da tarefa; 5) a flutuação total - a quantidade de superávit de tempo ou margem de segurança permitida nas tarefas, determinação de prazos de forma que o caminho crítico da rede seja mantido dentro do prazo. 37

Planejamento de Projeto de Software Determinação de Cronogramas n Os cálculos de tempo-limite levam à determinação do caminho crítico e proporcionam ao gerente um método quantitativo para avaliar o progresso à medida que as tarefas são concluídas. n O planejador deve reconhecer que o esforço de manutenção, ainda que não seja fácil de programar neste estágio, tornar-se-á, por fim, o maior fator de custo. 38

Planejamento de Projeto de Software Determinação de Cronogramas n PERT e CPM foram implementadas em uma grande variedade de ferramentas automatizadas que estão disponíveis para todos os computadores pessoais. n Tais ferramentas são relativamente fáceis de serem usadas e tornam os métodos de análise disponíveis para todos os gerentes de projetos de software. 39

Planejamento de Projeto de Software Rastreamento e Controle de Projeto n n Há um ditado que diz: “Os projetos de software atrasam-se em seu cronograma um dia de cada vez”. O atraso de um dia na programação raramente será fatal para um projeto. Mas os dias se somam e, ao longo da extensão de um projeto, pequenos atrasos podem resultar em grandes problemas. Um dos papéis da administração é rastrear e controlar o projeto de software assim que ele é iniciado. 40

Planejamento de Projeto de Software Rastreamento e Controle de Projeto n O rastreamento (tracking) pode ser feito de muitas maneiras diferentes: – Realizando-se reuniões sobre a situação do projeto, em que cada membro da equipe relate o progresso e os problemas. – Avaliando-se os resultados de todas as revisões realizadas ao longo do processo de engenharia de software. – Determinando-se se os marcos de referência de projeto formais foram atingidos até a data programada. 41

Planejamento de Projeto de Software Rastreamento e Controle de Projeto – Comparando-se a data de início real com a data de início planejada para cada tarefa de projeto relacionada na tabela de recursos. – Reunindo-se informalmente com profissionais para se obter suas avaliações subjetivas do progresso até o momento e os problemas que aparecem no horizonte. – Todas essas técnicas de rastreamento são usadas por gerentes de projeto experientes. 42

Planejamento de Projeto de Software Rastreamento e Controle de Projeto n n O controle é empregado por um gerente de projetos de software para administrar os recursos do projeto, enfrentar problemas e dirigir o pessoal do projeto. Se o projeto estiver no prazo e dentro do orçamento, as revisões indicarem progresso real e os marcos estiverem sendo atingidos, o controle é leve. Quando ocorrerem problemas, o gerente de projetos deverá exercer o controle para saná-los o mais rapidamente possível. Depois que o problema tiver sido diagnosticado, recursos adicionais podem ser concentrados na área de problema; o pessoal pode novamente ser disposto ou a programação do projeto, redefinida. 43

Planejamento de Projeto de Software Processo de Planejamento de Projeto 1) Estabelecer a data de início do projeto 2) Estabelecer a data final do projeto 3) Estabelecer a metodologia de projeto ou ciclo de vida do projeto a ser usado 4) Determinar o escopo do projeto em termos das fases da metodologia ou do ciclo de vida do projeto 5) Identificar ou selecionar os métodos de revisão a serem usados 44

Planejamento de Projeto de Software Processo de Planejamento de Projeto 6) Identificar qualquer milestone (conclusão de uma atividade) predeterminado ou outras datas críticas que devem ser encontradas 7) Listar tarefas, por fase do projeto, a fim de que elas possam ser acompanhadas 8) Estimar o pessoal necessário para acompanhar cada tarefa 9) Estimar o pessoal disponível para acompanhar cada tarefa 45

Planejamento de Projeto de Software Processo de Planejamento de Projeto 10) Determinar nível de perfil necessário para desempenhar cada tarefa 11) Determinar dependências de tarefa – Quais tarefas podem ser feitas em paralelo – Quais tarefas requerem estar completas para que outras tarefas possam iniciar 12) Projetar pontos de controle ou de revisão 13) Realizar estimativa de custo de projeto e análise de custo x benefício 46

Planejamento de Projeto de Software Plano de Projeto de Software n Cada etapa do processo de engenharia de software deve produzir um resultado que possa ser revisado e possa funcionar como uma base para os passos que se seguirão. n O Plano de Projeto de Software é produzido ao término das tarefas de planejamento e fornece informações básicas sobre o custo e programação de recursos que serão usadas ao longo do processo de engenharia de software 47

Planejamento de Projeto de Software Plano de Projeto de Software n O Plano de Projeto de Software deve: 1. Comunicar o escopo e os recursos à administração, ao pessoal técnico e ao cliente do software; 2. Definir os riscos e sugerir técnicas para evitá-los; 3. Definir custos e prazos para as revisões administrativas; 4. Oferecer uma abordagem global ao desenvolvimento do software para todas as pessoas envolvidas no projeto; 5. Delinear como qualidade será garantida e mudanças serão gerenciadas. 48

Planejamento de Projeto de Software Plano de Projeto de Software n n n O Plano de Projeto de Software não precisa ser um documento extenso e complexo. Seu propósito é ajudar a estabelecer a viabilidade do esforço de desenvolvimento. O plano concentra-se na declaração geral do “o que” e na declaração específica de “quanto” e “por quanto tempo”. As etapas subseqüentes do processo de engenharia de software concentrar-se-ão na definição, desenvolvimento e manutenção. 49

Planejamento de Projeto de Software Plano de Projeto de Software I. Introdução A. Propósito do plano B. Escopo do projeto e objetivos 1. Declaração do escopo 2. Funções principais 3. Questões de desempenho 4. Restrições técnicas e de gerenciamento II. Estimativas de projeto A. Dados históricos usados B. Técnicas de estimativas 3. Estimativas de esforço, custo e duração III. Estratégia de Gerenc. de Riscos A. Tabela de riscos. B. Discussão de riscos a gerenciar C. Plano RMMM para cada risco 1. Mitigação de risco 2. Monitoração de risco 3. Gerenciamento de risco IV. Cronograma A. Divisão de trabalho no projeto B. Rede de tarefas C. Gráfico de timeline (gráfico de Gantt) D. Tabela de recursos V. Recursos do projeto A. Pessoal B. Hardware e software C. Recursos especiais VI. Organização do pessoal A. Estrutura de equipe (se for o caso) B. Relatórios administrativos VII. Mecanismos de rastreamemto e controle A. Garantia e controle de qualidade B. Gerenciamento e controle de mudanças VIII. Apêndices. 50