Prof. Ms. Ronaldo Martins da Costa

Transcrição

1 Prof. Ms. Ronaldo Martins da Costa

2 O tempo é o mais valiosos bem disponível a um engenheiro de software. Se houver suficiente tempo disponível, um problema pode ser adequadamente analisado, uma solução pode ser compreensivamente projetada, o código-fonte, cuidadosamente implementado e o programa, minuciosamente testado. Mas parece que nunca há tempo o bastante.

3 Um projeto é planejado e tem seu cronograma determinado casualmente; os riscos são considerados somente depois que eles se transformaram em problemas completos; as pessoas não são organizadas de uma forma que agilize o processo. Às vezes parece que, em nossa ansiedade para começar, não despendemos tempo para organizar nossas ações. O planejamento de projetos de software obriga gerentes e profissionais a despender esse tempo.

4 O planejamento de Projetos Integração Após compreender os requisitos funcionais do software, características de desempenho, restrições relativas ao sistema e preocupações de confiabilidade, o planejador aplica técnicas e ferramentas para deduzir estimativas de esforço e tempo. Mas estas estimativas oferecem-nos informações úteis somente se estiverem integradas numa estrutura de planejamento mais completa.

5 Antes de começar, devemos responder a algumas questões importantes sobre riscos, desenvolvermos uma estratégia para atacarmos o problema, estabelecer um mecanismo para avaliarmos o progresso e organizar os membros do pessoal que foram escolhidos para construir o produto.

6 Análise dos Riscos Identificação dos riscos: riscos de projeto, riscos técnicos, riscos de negócio. A identificação dos riscos envolve a relação dos riscos específicos de projeto dentro das categorias acima. Um dos melhores métodos para se entender cada um dos riscos é usar um conjunto de perguntas que ajude o planejador do projeto a compreender os riscos.

7 Ex., o planejador poderia atingir uma compreensão dos riscos de composição do pessoal ao responder às seguintes perguntas: São as melhores pessoas disponíveis? As pessoas têm a combinação certa de habilidades? Há pessoas suficientes à disposição? Opessoalestácomprometidocomtodaaduraçãodoprojeto?...

8 Análise dos Riscos Projeção dos riscos:tenta classificar cada risco de duas maneiras:a probabilidadede que o risco seja real e as conseqüênciasdos problemas associados ao risco, caso ele ocorra.

9 O planejador do projeto executa 4 atividades de projeção de riscos: Estabelecimento de uma escala que reflita a probabilidade percebida de ocorrência de um risco; Delineamento das conseqüências do risco; Estimativa do impacto do risco sobre o projeto e o produto; Anotação da precisão global da projeção dos riscos de forma que não haja mal entendidos

10 Análise dos Riscos Avaliaçãodosriscos:Aessaalturadoprocesso deanálise dos riscos, estabelecemos um conjunto de termos: [ri, li, xi], onde ri é o risco, li é a probabilidade do risco e xi, o impacto do risco. Durante a avaliação dos riscos, examinamos mais detalhadamente a precisão das estimativas que foram feitas durante a projeção dos riscos, tentaremos determinar uma ordem de prioridade para os riscos que foram descobertos e começaremos a pensar em maneiras de controlar e/ou evitar riscos que tem a probabilidade de ocorrer

11 A fim de que a avaliação seja útil, um nível de risco referente deve ser definido. Para a maioria dos projetos, ocusto,osprazoseodesempenhorepresentam3níveis de risco referentes típicos.

12 Análise dos Riscos Gerenciamento e Monitoração dos riscos: O trio (descrição, probabilidade e impacto dos riscos) associado a cada risco é usado como uma base a partir da qual os passos de gerenciamento dos riscos são desenvolvidos.

13 Por ex., suponhamos que a alta rotatividade de pessoal seja obervada como um risco ao projeto, ri. Baseando-se na história passada e na intuição administrativa, a probabilidade li, de elevada rotatividade de pessoal é estimada como sendo de 70% e o impacto, xi, é projetado para aumentar a duração do projeto em 15% e o custo global em 12%. Colocados esses dados, os seguintes passos de administração dos riscos são propostos:

14 Análise dos Riscos Gerenciamento e Monitoração dos riscos: Reunir-se com o pessoal atual para determinar as causas de rotatividade de pessoal; Tomar providências para diminuir aquelas causas que estejam sob nosso controle antes que o projeto inicie; Assim que o projeto iniciar, pressupor que haverá rotatividade de pessoal e o desenvolver técnicas para garantir a continuidade quando as pessoas saírem;

15 Organizar equipes de projeto de forma que as informações a respeito de cada atividade sejam amplamente difundidas. Definir padrões de documentação e estabelecer mecanismos para se certificar de que os documentos sejam desenvolvidos de maneira oportuna; Realizar revisões de todo o trabalho com os colegas de forma que mais de uma pessoa esteja a par das atividades desenvolvidas; Definir um membro do pessoal que sirva de backup para cada profissional mais crítico;

16 Análise dos Riscos Gerenciamento e Monitoração dos riscos: Os passos de administração dos riscos são organizados num Plano de Administração e Monitoração dos Riscos (PAMR). O PAMR documenta todo o trabalho executado como parte da análise de riscos e é usado pelo gerente de projetos como parte do Plano de Projeto global.

17 Assim que o PAMR tiver sido desenvolvido, começa a monitoração dos riscos. A monitoração é uma atividade de rastreamento do projeto com três objetivos: Avaliarseumriscoprevistodefatoocorre; Garantir que os passos de reversão definidos para o risco estejam sendo adequadamente aplicados; Coletar informações que possam ser usadas em análises de risco futuras Outra tarefa da monitoração é tentar atribuir culpa (qual risco causou problemas) ao longo do projeto.

18 Determinação de um Cronograma 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 da um sistema já foi estabelecida; desse modo a organização vê-se compelida a distribuir o esforço dentro do espaço de tempo previsto.

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

20 Determinação de um Cronograma Aprecisãonadeterminaçãodeumcronogramaàs vezes pode ser bem mais importante do que a precisão na determinação dos custos. Num ambiente orientado para o 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 Determinação de um Cronograma Relações pessoas-trabalho: à medida que o projeto aumenta, mais pessoas podem ser incluídas??? As pessoas incluídas devem aprender o sistema e as antigas devem ensiná-las... Definição de tarefa e paralelismo: quando mais de uma pessoa está envolvida no projeto, é provável que as atividades de desenvolvimento ocorram em paralelo

22 Determinação de um Cronograma Distribuição do Esforço: Análise e projeto (40-50%) Atividades de testes e depuração (30-40%) Codificaçã o (15-20%)

23 Determinação de um Cronograma Métodos de Determinação de Cronogramas: ferramentas e técnicas para determinação de um cronograma podem ser aplicadas no software com poucas modificações: PERT Program Evaluation and Review Technique CPM CriticalPathMethod

24 Ambas as técnicas desenvolvem uma descrição da rede de tarefas e um projeto, ou seja, uma representação tabular das tarefas que devem ser levadas a efeito desde o começoatéofinaldeumprojeto. 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; Calcular limites de tempo que definam uma janela de tempo para uma tarefa particular.

25 Rastreamento e Controle de Projeto Um dos papéis da administração é rastrear e controlar o projeto de software assim que ele se põe a caminho. O rastreamento pode ser levado a efeito de muitas maneiras diferentes: Realizando-se reuniões periódicas sobre a situação do projeto, em que cada membro da equipe relate o progresso e os problemas;

26 Avaliando-se os resultados de todas as revisões levadas a efeito 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; Comparando-se a data de início real com a data de início planejada para cada tarefa do projeto; Reunindo-se informalmente com profissionais para se obter suas avaliações subjetivas do progresso até o momento e os problemas que aparecem.

27 Uma estratégia para se efetuar a reengenharia de um software existente pode ser desenvolvida se a administração da empresa estiver disposta apagarjá,emvezdeesperarparapagar(muito) mais tarde. Na realidade a reengenharia pode ser uma alternativa de baixo custo à manutenção de software.

28 Os seguintes passos são recomendados: 1. Selecione aqueles programas que são muito usados no momento e que provavelmente estarão sendo usadosnospróximos5a10anos. 2.Estime o custo anual para manter os programas escolhidos no passo 1. O custo de manutenção deve incluir a correção, a adaptação ambiental e os aumentos funcionais. 3. Disponha por ordem de prioridade os programas escolhidos no passo 1 conforme importância e custo de manutenção

29 Os seguintes passos são recomendados:(cont.) 4. Estime o custo para efetuar a reengenharia dos programas selecionados no passo 1. Estime o custo anual para manter esses programas depois de efetuada a reengenharia. 5. Para cada programa escolhido, compare seu custo de manutenção com o custo para efetuar a sua reengenharia. 6. Compute o tempo exigido para o retorno do investimento de reengenharia.

30 7. Leve m consideração questões intangíveis, como melhor receptividade a mudanças, melhor confiabilidade do sistema, superior desempenho do sistema e melhores interfaces com o usuário. 8. Obtenha a aprovação da administração para iniciar a reengenharia de um simples programa.

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

32 OPlanodeProjetodeSoftwaredeve: Comunicar escopo e os recursos à administração, ao pessoal técnico e ao cliente do software; Definir os riscos e sugerir técnicas para evitá-los; Definir custos e prazos para as revisões administrativas; Oferecer uma abordagem global ao desenvolvimento do software para todas as pessoas envolvidas no projeto.