Capítulo 23 Planejamento de Projeto. Aula 1 Cronograma do Projeto

Transcrição

1 Capítulo 23 Planejamento de Projeto Aula 1 Cronograma do Projeto

2 Tópicos ² Preço de software ² Desenvolvimento dirigido a planejamento ² Agendamento de projeto ² Planejamento ágil ² Técnicas de estimativa 2

3 Planejamento de Projeto ² O planejamento de projeto envolve quebrar o trabalho em partes e atribui-las aos membros da equipe do projeto, antecipar problemas que podem surgir e preparar tentativas de soluções para estes problemas. ² O plano do projeto, que é criado no início do projeto, é usado para comunicar como o trabalho será feito pela equipe do projeto e clientes, e ajudar a avaliar o progresso do projeto. 3

4 Estágios de Planejamento ² No estágio de proposta, quando você está iniciando um contrato para desenvolver ou fornecer um sistema de software. ² Durante a fase inicial do projeto, quando você tem que planejar quem trabalhará no projeto, como o projeto será quebrado em incrementos, como os recursos serão alocados através da companhia, etc. ² Periodicamente durante o projeto, quando você modificar seu plano por causa da experiência adquirida e informação do monitoramento do progresso do trabalho. 4

5 Planejamento de Proposta ² O planejamento pode ser necessário com somente requerimentos de software iniciais. ² O objetivo do planejamento neste estágio é fornecer informação que será usada na atribuição de preço do sistema para os clientes. 5

6 Preço de Software ² Estimativas são feitas para descobrir o custo, para o desenvolvedor, de produzir um sistema de software. Leva-se em conta hardware, software, viagens, treinamento e esforço. ² Não há um relacionamento simples entre o custo de desenvolvimento e o preço cobrado ao cliente. ² Considerações organizacionais, econômicas e políticas maiores influenciam o preço cobrado. 6

7 Fatores que Afetam o Preço do Software Fator Oportunidade de mercado Incerteza na estimativa de custo Termos contratuais Descrição Uma organização de desenvolvimento pode cotar um preço baixo porque ela deseja mover-se para um novo segmento do mercado de software. Aceitar um lucro baixo em um projeto pode dar à organização a oportunidade de aumentar os lucros depois. A experiência ganha pode também ajudar a desenvolver novos produtos. Se uma organização está insegura da estimativa de custos, ela pode aumentar o preço por uma contingência muito acima do seu lucro normal. Um cliente pode permitir que o desenvolvedor retenha a propriedade do código fonte e o reutilize em outros projetos. O preço cobrado pode então ser menor do que se o código fonte do software é entregue ao cliente. 7

8 Fatores que Afetam o Preço do Software Fator Volatilidade dos requerimentos Saúde financeira Descrição Se os requerimentos são frequentemente modificados, uma organização pode baixar o preço para ganhar um contrato. Após ganhar o contrato, preços mais altos podem ser cobrados para as mudanças nos requerimentos. Desenvolvedores em dificuldades financeiras podem baixar seus preços para ganhar um contrato. É melhor ter um lucro pequeno do que um lucro normal ou nenhum lucro do que sair dos negócios. O fluxo de caixa é mais importante do que o lucro em tempos de dificuldades econômicas. 8

9 Desenvolvimento Dirigido a Planejamento ² O desenvolvimento dirigido a planejamento ou a plano é uma abordagem de engenharia de software na qual o processo de desenvolvimento é planejado em detalhes. O desenvolvimento dirigido a planejamento é baseado em técnicas de gerência de projetos de engenharia e é a maneira tradicional de gerenciar projetos grandes de desenvolvimento de software. ² Um plano do projeto é criado e contém o trabalho a ser feito, quem o fará, o cronograma de desenvolvimento e os produtos do trabalho. ² Os gerentes usam o plano para dar suporte às tomadas de decisão no projeto e como uma maneira de medir o progresso. 9

10 Desenvolvimento Dirigido a Planejamento Prós e Contras ² Os argumentos a favor de uma abordagem dirigida a planejamento são que o planejamento prévio permite que aspectos organizacionais (disponibilidade de pessoal, outros projetos, etc.) serem levando em conta de perto, e que os problemas potenciais e dependências são descobertas antes que o projeto inicie, o que é melhor do que durante o andamento do projeto. ² O principal argumento contra o desenvolvimento dirigido a planejamento é que muitas decisões prévias tem que ser revisadas por causa de mudanças no ambiente no qual o software será desenvolvido e utilizado. 10

11 Planos de Projeto ² Em um desenvolvimento dirigido a planejamento, um plano de projeto atribui os recursos disponíveis ao projeto, a divisão do trabalho e um cronograma para executar o trabalho. ² Seções do plano Introdução Organização do projeto Análise de risco Requerimentos de hardware e software Divisão do trabalho Cronograma do projeto Mecanismos de monitoramento e informação 11

12 Suplementos ao Plano de Projeto Plano Plano de qualidade Plano de validação Plano de gerência de configuração Plano de manutenção Plano de desenvolvimento do pessoal Descrição Descreve os procedimentos de qualidade e padrões que serão usados em um projeto. Descreve a abordagem, recursos e cronograma usados para a validação do sistema. Descreve os procedimentos e estruturas de gerência de configuração a serem usadao. Prevê os requerimentos de manutenção, custos e esforço. Descreve como as habilidades e experiência dos membros da equipe de projeto serão desenvolvidas. 12

13 O Processo de Planejamento de Projeto ² O planejamento do projeto é um processo iterativo que inicia quando você cria um plano inicial de projeto durante a fase inicial do projeto. ² As mudanças no plano são inevitáveis. Enquanto mais informação sobre o sistema e a equipe do projeto tornam-se disponíveis durante o projeto, você deve regularmente revisar o plano para refletir requerimentos, cronograma e mudanças nos riscos. As mudanças de objetivos de negócio também levam a mudanças nos planos do projeto. Enquanto os objetivos de negócio mudam, isso pode afetar todos os projetos, que podem então ter que ser replanejados. 13

14 O Processo de Planejamento de Projeto 14

15 Agendamento do projeto ² O agendamento do projeto é o processo de decidir como o trabalho em um projeto será organizado como tarefas separadas, e quando e como essas tarefas serão executadas. ² Você estima o tempo de calendário necessário para completar cada tarefa, o esforço requerido e quem irá trabalhar nas tarefas que foram identificadas. ² Você também deve estimar os recursos necessários para completar cada tarefa, tais como o espaço em disco requerido em um servidor, o tempo requerido de hardware, como um simulador, e qual será o orçamento de viagem. 15

16 Atividades do Agendamento do Projeto ² Divida o projeto em tarefas e estime o tempo e os recursos necessários para completar cada tarefa. ² Organize as tarefas concorrentemente para fazer uso ótimo da força de trabalho. ² Minimize as dependências entre as tarefas para evitar atrasos causados por uma tarefa esperando por outra para completar. ² Depende da intuição e experiência dos gerentes de projeto. 16

17 Milestones e Itens a Entregar ² Milestones são pontos no cronograma contra os quais você pode avaliar o progresso, por exemplo, a entrega de um sistema para teste. ² Itens a entregar são produtos de trabalho que são entregues a um cliente, por exemplo, um documento de requerimentos para o sistema. 17

18 O Processo de Agendamento de Projeto 18

19 Problemas de Cronograma ² Estimar a dificuldade dos problemas e desta forma o custo de desenvolvimento de uma solução é difícil. ² A produtividade não é proporcional à quantidade de pessoas trabalhando em uma tarefa. ² Adicionar pessoas a um projeto atrasado o atrasa mais ainda por causa de sobrecargas de comunicação. ² O inesperado sempre acontece. Sempre permita contingência no planejamento. 19

20 Representação de Cronograma ² As notações gráficas são normalmente usadas para ilustrar o cronograma de projeto. ² Elas mostram a divisão do projeto em tarefas. As tarefas não deveriam ser muito pequenas. Elas deveriam levar cerca de uma ou duas semanas. ² Os gráficos de barras são a representação mais comumente utilizada para cronogramas de projetos. Eles mostram o cronograma com atividades ou recursos contra o tempo. 20

21 Tarefas, Durações e Dependências Tarefa Esforço (Pessoa/Dia) Duração (Dias) T Dependências T T T1 (M1) T T T2, T4 (M3) T T1, T2 (M4) T T1 (M1) T T4 (M2) T T3, T6 (M5) T T7, T8 (M6) T T9 (M7) T T10, T11 (M8) 21

22 Gráfico de Barras de Atividades 22

23 Gráfico de Alocação de Pessoal 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Jane T1 T3 T9 T10 T12 Ali T1 T8 Geetha T2 T6 T10 T3 Maya T3 T8 Fred T4 T8 T11 T12 Mary T5 Hong T7 T6 23

24 Planejamento Ágil ² Os métodos ágeis de desenvolvimento de software são abordagens iterativas nas quais o software é desenvolvido e entregue aos clientes em incrementos. ² Diferente das abordagens dirigidas a planejamento, a funcionalidade desses incrementos não é planejada a priori mas é decidida durante o desenvolvimento. A decisão do que incluir em um incremento depende do progresso e das prioridades do cliente. ² As prioridades do cliente e os requerimentos mudam de forma que faz sentido ter um plano flexível que pode acomodar tais mudanças. 24

25 Estágios do Planejamento Ágil ² O planejamento de entrega, que olha adiante vários meses e decide quais características devem ser incluídas na entrega de um sistema. ² O planejamento de iteração, que olha pouco tempo adiante, e concentra-se no planejamento do próximo incremento de um sistema. Isso são tipicamente 2-4 semanas de trabalho da equipe. 25

26 Planejamento em XP 26

27 Planejamento Baseado em História ² A especificação de sistema em XP é baseada em histórias do usuário que refletem as características que deveriam ser incluídas no sistema. ² A equipe do projeto lê e discute as histórias e as classifica conforme a quantidade de tempo que eles acham que levará para implementar a história. ² O planejamento de entrega envolve selecionar e refinar as histórias que refletirão as características que serão implementadas em uma entrega de um sistema e a ordem que as histórias deveriam ser implementadas. ² As histórias a serem implementadas em cada iteração são escolhidas, com a quantidade de histórias refletindo o tempo para entregar uma iteração (geralmente 2 ou 3 semanas). 27

28 Pontos Principais ² O preço cobrado por um sistema não depende somente dos custos estimados de desenvolvimento; ele pode ser ajustado dependendo do mercado e de prioridades organizacionais. ² O desenvolvimento orientado a planejamento é organizado ao redor de um plano de projeto completo que define as atividades do projeto, o esforço planejado, o cronograma de atividades e quem é responsável por cada atividade. 28

29 Pontos Principais ² O agendamento de projeto envolve a criação de uma representação gráfica do plano do projeto. Os gráficos de barra, que mostram a duração das atividades e as linhas de tempo da equipe, são as representações mais comumente utilizadas de cronograma. ² O jogo de planejamento XP envolve a equipe inteira no planejamento do projeto. O plano é desenvolvido de forma incremental e, se ocorrem problemas, é ajustado. A funcionalidade do software é reduzida ao invés de atrasar a entrega de um incremento. 29

30 Capítulo 23 Planejamento de Projeto Aula 2 Es>ma>va de Custo

31 Técnicas de Estimativa ² As organizações precisam fazer estimativas de custo e esforço de software. Há dois tipos de técnicas que podem ser usadas para fazer isso: técnicas baseadas em experiência A estimativa de requerimentos de esforço futuro é baseada na experiência do gerente em projetos passados e no domínio da aplicação. Essencialmente, o gerente faz um julgamento do que os requerimentos de esforço devem ser; modelagem de custo algorítmica nesta abordagem, uma fórmula é usada para computar o esforço do projeto baseado em estimativas de atributos do produto, tais como tamanho, e características de projeto, tais como a experiência do pessoal envolvido. 31

32 Abordagens Baseadas em Experiência ² As técnicas baseadas em experiência apoiam-se em julgamentos baseados na experiência dos projetos passados e no esforço gasto nesses projetos em atividades de desenvolvimento de software. ² Tipicamente, você identifica os itens a serem produzidos em um projeto e os componentes de software distintos ou sistemas que estão para serem desenvolvidos. ² Você documenta-os em uma planilha, estima-os individualmente e computa o esforço total necessário. ² Geralmente ajuda ter um grupo de pessoas envolvido na estimativa de esforço e pedir a cada membro do grupo para explicar as estimativas deles. 32

33 Modelagem de Custo Algorítmica ² O custo é estimado como uma função matemática de atributos do produto, projeto e processo cujos valores são estimados por gerentes de projeto: Esforço = A Tamanho B M A é uma constante dependente de organização, B reflete o esforço desproporcional para projetos grandes e M é um multiplicador que reflete os atributos de produto, processo e pessoas. ² O atributo de produto mais comumente usado é o tamanho do código. ² Muitos modelos são similares, mas usam valores diferentes para A, B e M. 33

34 Precisão da Estimativa ² O tamanho de um sistema de software pode somente ser conhecido precisamente quando é ele é terminado. ² Vários fatores influenciam o tamanho final: uso de COTS e componentes; linguagem de programação; distribuição de sistema. ² À medida que o processo de desenvolvimento progride, a estimativa de tamanho se torna mais precisa. ² As estimativas dos fatores que contribuem para B e M são subjetivas e variam de acordo com o julgamento da pessoa que faz a estimativa. 34

35 Incerteza de Estimativa 35

36 O Modelo COCOMO 2 ² Um modelo empírico baseado em experiência de projeto. ² Modelo bem documentado e independente que não está ligado a um vendedor específico de software. ² Longa história desde a versão inicial publicada em in 1981 (COCOMO-81) através de várias instâncias até COCOMO 2. ² COCOMO 2 leva em conta abordagens diferentes para desenvolvimento de software, reuso, etc. 36

37 Modelos COCOMO 2 ² COCOMO 2 incorpora uma faixa de sub-modelos que produzem estimativas de software crescentemente detalhadas. ² Os sub-modelos em COCOMO 2 são: modelo de composição de aplicação. Usado quando o software é composto de partes existentes. modelo de projeto preliminar. Usado quando os requerimentos estão disponíveis, mas o projeto ainda não iniciou. modelo de reuso. Usado para computar o esforço de integrar componentes reutilizáveis. modelo pós-arquitetura. Usado uma vez que a arquitetura do sistema tenha sido projetada e mais informação sobre o sistema esteja disponível. 37

38 Modelos de Estimativa COCOMO 38

39 Modelo de Composição de Aplicação ² Suporta projetos de prototipagem e projetos em que há reuso extensivo. ² Baseado em estimativas padrão da produtividade do desenvolvedor em pontos/mês da aplicação (objeto). ² Leva em conta as ferramentas CASE. ² A fórmula é PM = ( NAP (1 - %reuso/100 ) ) / PROD PM é o esforço em pessoas-mês, NAP é a quantidade de pontos de aplicação e PROD é a produtividade. 39

40 Produtividade de Ponto de Aplicação Experiência e capacidade do desenvolvedor maturidade e capacidade ICASE PROD (NAP/ mês) Muito baixa Baixa Nominal Alta Muito alta Very low Baixa Nominal Alta Muito alta

41 Modelo de Projeto Preliminar ² As estimativas podem ser feitas após os requerimentos terem sido aceitos. ² Baseado em uma fórmula padrão para modelos algorítmicos: PM = A Tamanho B M M = PERS RCPX RUSE PDIF PREX FCIL SCED; A = 2.94 em calibração inicial, Tamanho em KLOC, B varia de 1.1 a 1.24 dependendo da novidade do projeto, flexibilidade de desenvolvimento, abordagens de gerência de risco e a maturidade do processo. 41

42 Multiplicadores ² Os multiplicadores refletem a capacidade dos desenvolvedores, os requerimentos não funcionais, a familiaridade com a plataforma de desenvolvimento, etc.. RCPX complexidade e confiabilidade do produto; RUSE o reuso necessário; PDIF dificuldade de plataforma; PREX experiência de pessoal; PERS capacidade de pessoal; SCED cronograma necessário; FCIL as facilidade de suporte à equipe. 42

43 O Modelo de Reuso ² Leva em conta código de caixa-preta que é reutilizado sem mudança e código que tem que ser adptado para ser integrado com código novo. ² Há duas versões: reuso de caixa-preta o código não é modificado. Uma estimativa de esforço (PM) é computada; reuso de caixa-branca o código é modificado. Uma estimativa de tamanho equivalente à quantidade de linhas do novo código fonte é computada. Isso então ajusta a estimativa de tamanho para o novo código. 43

44 Estimativas do Modelo de Reuso 1 ² Para código gerado: PM = (ASLOC * AT/100)/ATPROD ASLOC é a quantidade de linhas de códigos geradas. AT é a porcentagem de código automaticamente gerado. ATPROD é a produtividade dos engenheiros ao integrar este código. 44

45 Estimativas do Modelo de Reuso 2 ² Quando o código tem que ser entendido e integrado:: ESLOC = ASLOC * (1-AT/100) * AAM. ASLOC e AT como antes. AAM é o multiplicador de ajuste de adaptação computado dos custos de modificar o código reutilizado, os custos de entender como integrar o código e os custos de tomar a decisão de reutilizá-lo. 45

46 Nível Pós-Arquitetura ² Usa a mesma fórmula que o modelo de projeto preliminar, mas com 17 ao invés de 7 multiplicadores associados. ² O tamanho do código é estimado como: quantidade de linhas de código novo a ser desenvolvido; estimativa de quantidade de linhas equivalentes de código novo computadas usando o modelo de reuso; uma estimativa da quantidade de linhas de código que tem que ser modificadas de acordo com as mudanças nos requerimentos. 46

47 O Termo Expoente ² Ele depende de 5 fatores de escala (próximo slide). A soma deles dividida por 100 é adicionada a 1,01. ² Uma companhia pega um projeto em um novo domínio. O cliente não definiu o processo a ser usado e não permitiu tempo para a análise de risco. A companhia tem um nível de CMM 2. Precedência novo projeto (4) Flexibilidade de desenvolvimento nenhum envolvimento do cliente muito alto (1) Arquitetura/Resolução de riscos nenhuma análise de riscos muito baixo (5) Coesão da equipe equipe nova - nominal (3) Maturidade do processo algum controle - nominal (3) ² Desta forma, o fator de escala é 1,17. 47

48 Fatores de Escala Usados na Computação de Expoente do Modelo Pós-Arquitetura Fator de Escala Precedência Flexibilidade de Desenvolvimento Arquitetura Resolução de Riscos Coesão de Equipe Maturidade de Processo Explicação Reflete a experiência anterior da organização com esse >po de projeto. Muito baixa significa nenhuma experiência anterior; muito alta significa que a organização está completamente familiarizada com esse domínio de aplicação. Reflete o grau de flexibilidade no processo de desenvolvimento. Muito baixa significa que um processo predeterminado é usado; muito alta significa que o cliente define apenas metas gerais. Reflete a medida da análise de risco realizada. Muito baixa significa pouca análise; muito alta significa uma análise de riscos completa e exaus>va. Reflete quão bem os membros da equipe conhecem uns aos outros e trabalham juntos. Muito baixa significa muita dificuldade de interação; muito alta significa uma equipe integrada e eficaz, sem problemas de comunicação. Reflete a maturidade do processo da organização. O cálculo desse valor depende do ques>onário de maturidade CMM, mas uma es>ma>va pode ser alcançada subtraindo- se o nível de maturidade do processo CMM de 5. 48

49 Multiplicadores ² Atributos de produto Relacionados com as características requeridas do produto de software sendo desenvolvido. ² Atributos de computador Restrições impostas no software pela plataforma de hardware. ² Atributos pessoais Multiplicadores que levam em conta a experiência e capacidades das pessoas trabalhando no projeto. ² Atributos de projeto Relacionados com as características particulares do projeto de desenvolvimento de software. 49

50 O Efeito dos Drivers de Custo na Estimativa de Custo Valor de Expoente 1,17 Tamanho do sistema (incluindo fatores para reuso e volatilidade de requerimentos) Estimativa COCOMO inicial sem os drivers de custodrivers DSI 730 pessoas/mês Confiabilidade Muito alta, multiplicador = 1,39 Complexidade Muito alta, multiplicador = 1,3 Restrição de memória Alta, multiplicador = 1,21 Uso de ferramenta Baixa, multiplicador = 1,12 Cronograma Acelerada, multiplicador = 1,29 Estimativa COCOMO ajustada pessoas/mês 50

51 O Efeito dos Drivers de Custo na Estimativa de Custo Valor de Expoente 1,17 Confiabilidade Muito baixa, multiplicador = 0,75 Complexidade Muito baixa, multiplicador = 0,75 Restrição de memória Nenhuma, multiplicador = 1 Uso de ferramenta Muito alta, multiplicador = 0,72 Cronograma Normal, multiplicador = 1 Estimativa COCOMO ajustada 295 pessoas/mês 51

52 Duração de Projeto e Pessoal ² Bem como estimativa de esforço, os gerentes devem estimar o tempo de calendário necessário para completar um projeto e quando o pessoal será necessário. ² O tempo de calendário pode ser estimado usando uma fórmula COCOMO 2 TDEV = 3 (PM) ( *(B-1.01)) PM é a computação de esforço e B é o expoente computado como discutido acima (B é 1 para o modelo de prototipagem preliminar). Esta computação prevê o cronograma nominal para o projeto. ² O tempo necessário é independente da quantidade de pessoas trabalhando no projeto. 52

53 Requerimentos de Pessoal ² O pessoal requerido não pode ser computado pela divisão do tempo de desenvolvimento pelo cronograma necessário. ² A quantidade de pessoas trabalhando em um projeto varia dependendo da fase do projeto. ² Quanto mais pessoas trabalham no projeto, mais esforço total é geralmente necessário. ² Uma montagem muito rápida de pessoas geralmente tem relação com os deslizes de projeto. 53

54 Pontos Principais ² As técnicas de estimativa para software podem ser baseadas em experiência ou algorítmicas. Neste caso, os gerentes julgam o esforço necessário. No caso das técnicas algorítmicas, o esforço necessário é computado de outros parâmetros de projeto estimados. ² O modelo de custos The COCOMO II é algorítmico e usa atributos de projeto, produto, hardware e pessoas como também o tamanho do projeto e atributos de complexidade para derivar uma estimativa de custo. 54