Capítulo 23. Planejamento de Projeto Pearson PrenticeHall. Todos os direitos reservados. slide 1

Transcrição

1 Capítulo 23 Planejamento de Projeto slide 1

2 Tópicos abordados Definiçãode preço de software Desenvolvimento dirigido a planos Programação de projeto Planejamento ágil Técnicas de estimativa slide 2

3 Planejamento de projeto O planejamento de projeto envolve dividir o projeto em partes e atribuí-las aos membros da equipe, antecipar os problemas que possam surgir e preparar soluções para esses problemas. O planejamento de projeto, criado no início,é usado para comunicar a equipe e aos clientes como o trabalho será realizado e para ajudar a avaliar o progresso do projeto. slide 3

4 Fases do planejamento Na fase de proposta, durante a licitação para um contrato para desenvolver ou fornecer um sistema de software. Durante a fase de iniciação do projeto, é necessário planejar quem irá trabalhar no projeto, como o projeto será dividido em incrementos, como os recursos serão alocados através de sua empresa, etc. Periodicamente, ao longo do projeto, quando você modifica o seu planejamento à luz das experiências adquiridas a partir da monitoração das informações e acompanhamento do progresso do trabalho. slide 4

5 Planejamento da proposta Pode ser necessário fazer o planejamento com apenas esboços dos requisitos de software. Nessa fase, o objetivo do planejamento é fornecer informações que serão usadas na definição do preço do sistema para os clientes. slide 5

6 Definição de preço de software São feitas estimativas para descobrir o custo do desenvolvedor para produzir um sistema de software. ü Você deve levar em conta os custos de hardware, software, formação, deslocamentos e esforço. Não existe uma relação simples entre o custo de desenvolvimento e o preço cobrado. Considerações econômicas, políticas, organizacionais e empresariais mais amplas influenciam o preço cobrado. slide 6

7 Fatores que afetam a definição de preço de software slide 7

8 Desenvolvimento dirigido a planos O desenvolvimento dirigido a planos é uma abordagem da engenharia de software, na qual o processo de desenvolvimento é planejado em detalhes. ü O desenvolvimento dirigido a planos é baseado em técnicas de gerenciamento de projetos e é a forma "tradicional" de gerenciar grandes projetos de desenvolvimento de software. É criado um plano de projeto que registra o trabalho a ser feito, quem irá fazêlo, o cronograma de desenvolvimento e os produtos do trabalho. Os gerentes usam esse plano para apoiar tomadas de decisões e como uma forma de mediro progresso. slide 8

9 Desenvolvimento dirigido a planos prós e contras Os argumentos a favor de uma abordagem dirigida a planos são que o planejamento antecipado permite que questões organizacionais (disponibilidade de pessoal, outros projetos, etc.) sejam cuidadosamente consideradas, e que os problemas potenciais e as dependências sejam descobertas antes do início do projeto, e não quando o projeto já esteja em andamento. O principal argumento contra o desenvolvimento dirigido a planos é que muitas decisões iniciais precisam ser revistas por causa de alterações no ambiente no qual esse software será usado. slide 9

10 Planos de projeto Em um projeto de desenvolvimento dirigido a planos, um plano desse projeto define os recursos disponíveis para o projeto, a divisão de trabalho e um cronograma para a realização dos trabalhos. Seções do plano ü Introdução ü Organização de projeto ü Análise de riscos ü Requisitos de recursos de hardware e software ü Divisão de trabalho ü Cronograma de projeto ü Mecanismos de monitoração e geração de relatórios slide 10

11 Suplementos de plano de projeto slide 11

12 O processo de planejamento O planejamento do projeto é um processo iterativo que se inicia quando é criado um plano de projeto inicial durante a fase de iniciação. Mudanças no plano são inevitáveis ü Durante o projeto, na medida em que ficam disponíveis mais informações sobre o sistema e a equipe desse, você deve rever regularmente o plano para refletir as mudanças de requisitos, cronograma e riscos. ü Mudanças nos objetivos de negócio também levam a mudanças nos planos de projeto. Na medida em que os objetivos de negócio mudam, essas mudanças podem afetar todos os projetos, que podem então ser replanejados. slide 12

13 O processo de planejamento de projeto slide 13

14 Programação de projeto A programação de projeto é o processo de decidir como, em um projeto, o trabalho será organizado em tarefas separadas, e quando e como essas tarefas serão executadas. Estimar o tempo necessário para concluir cada tarefa, o esforço necessário e quem vai trabalhar nas tarefas identificadas. Você também precisa estimar os recursos necessários para concluir cada tarefa, tais como o espaço em disco necessário em um servidor, o tempo necessário em hardwares especializados, tal como um simulador, e qual será o orçamento de viagens. slide 14

15 Programação de atividades de projeto Dividir o projeto em tarefas e estimar o tempo e os recursos necessários para concluir cada tarefa. Organizar tarefas simultaneamente para otimizar a utilização da força de trabalho. Minimizar as dependências entre as tarefas para evitar atrasos causados por uma tarefa que esteja esperando a conclusão de outras tarefas. Depende da intuição e da experiência dos gerentes de projeto. slide 15

16 Etapas e entregas As etapas são pontos do cronograma contra os quais você pode avaliar o progresso, por exemplo, a transferência do sistema para testes. Entregas são produtos de trabalho entregues ao cliente, por exemplo, um documento de requisitos do sistema. slide 16

17 O processo de programação de projeto slide 17

18 Problemas de programação Estimar a dificuldade dos problemas é difícil, assim como estimar o custo de desenvolvimento de uma solução. A produtividade não é proporcional ao número de pessoas trabalhando em uma tarefa. Adicionar pessoas a um projeto atrasado atrasa-o ainda mais por causa do overhead de comunicação. O inesperado sempre acontece. Sempre permitir contingênciasno plano. slide 18

19 Representação de cronograma Normalmente são utilizadas notações gráficas para ilustrar o cronograma do projeto. Essas mostram a divisão do projeto em tarefas. As tarefas não devem ser muito pequenas. Elas devem levar cerca de uma semana ou duas. Os gráficos de barras são a representação mais comumente utilizada para cronogramas de projetos. Elas mostram o cronograma como atividades ou recursos contra o tempo. slide 19

20 Tarefas, durações e dependências slide 20

21 Gráfico de barras de atividades slide 21

22 Gráfico de alocação de pessoal slide 22

23 Planejamento ágil Métodos ágeis de desenvolvimento de software são abordagens iterativas nas quais o software é desenvolvido e entregue aos clientes em incrementos. Ao contrário das abordagens dirigidas a planos, a funcionalidade desses incrementos não é planejada com antecedência, mas decidida durante o desenvolvimento. ü A decisão sobre o que incluir em um incremento depende do progresso das prioridades do cliente. e As prioridades e os requisitos do cliente mudam por isso faz sentido ter um plano flexível, que possa acomodar essas mudanças. slide 23

24 Fases do planejamento ágil Planejamento de release, que olha à frente durante vários meses e decide sobre os recursos que deveriam ser incluídos em um release de um sistema. Planejamento de iteração, o qual tem uma visão de mais curto prazo, e se concentra no planejamento do próximo incremento de um sistema. Geralmente em torno de 2-4 semanas de trabalho de uma equipe. slide 24

25 Planejamento em XP slide 25

26 Planejamento baseada em estórias A especificação do sistema em XP é baseada em estórias de usuários que refletem as características que devem ser incluídas no sistema. A equipe do projeto lê e discute as estórias e classifica em ordem do tempo que acredita ser necessário para implementar a estória. O planejamento de release envolve a seleção e refinamento das estórias que irão refletir as características a serem implementadas em um release de um sistema e na ordem em que as estórias devem ser implementadas. São escolhidas as estórias a serem implementadas em cada iteração, com o número de estórias refletindo o tempo de entrega de uma iteração (geralmente 2 ou 3 semanas). slide 26

27 Pontos importantes O preço cobrado por um sistema não depende apenas dos custos de desenvolvimento estimados, os quais podem ser ajustados dependendo do mercado e das prioridades organizacionais. O desenvolvimento dirigido a planos é organizado em torno de um plano de projeto completo que define as atividades do projeto, o esforço planejado, a programação de atividades e quem é responsável por cada atividade. A programação de projeto envolve a criação de representações gráficas do plano de projeto. Gráficos de barra mostram a duração da atividade e prazos da equipe, são as representações de cronograma mais usadas. O jogo do planejamento de XP envolve toda a equipe no planejamento do projeto. O plano é desenvolvido de forma incremental e, se surgem problemas, esses são ajustados. Ao invés de atrasar a entrega de um incremento, reduz-se a funcionalidade do software. slide 27

28 Técnicas de estimativa As organizações precisam fazer estimativas de esforço e custo de um software. Existem dois tipos de técnicas que pode ser usadas para fazer isso: ü Técnicas baseadas em experiências As estimativas de requisitos de futuros esforços são baseadas na experiência do gerente com projetos anteriores e no domínio da aplicação. Essencialmente, o gerente faz um juízo fundamentado a respeito de como devem ser os requisitos de esforço. ü Modelagem algorítmica de custos Nessa abordagem, é usada uma abordagem para calcularo esforço do projeto com base em estimativas dos atributos de produto, como tamanho e características do processo, assim comoa experiência da equipe envolvida. slide 28

29 Abordagens baseadas em experiências Técnicas baseadas em experiências se baseiam em julgamentos baseados na experiência de projetos anteriores e ao esforço dispendido nesses projetos em atividades de desenvolvimento de software. Normalmente, você identifica os entregáveis em um projeto e os diferentes componentes de software ou sistemas a serem desenvolvidos. Você documenta esses em uma planilha, estima cada um individualmente e calculao esforço total necessário. Normalmente é útil ter um grupo de pessoas envolvido na estimativa de esforço e pedir a cada membro do grupo que explique a sua estimativa. slide 29

30 Modelagem algorítmica de custos O custo é estimado como uma função matemática de produto, de projeto e atributos de processo, cujos valores são estimados por gerentes de projeto: ü Esforço = A x TamanhoB x M ü A é uma constante dependente da organização, Tamanho é o tamanho do código, B reflete o esforço proporcional para grandes projetos e M é um multiplicador refletindo atributos de produtos, processo e de pessoas. O atributo de produto mais comumente usado para a estimativa de custo é o tamanho do código. A maioria dos modelos são semelhantes, mas eles usam valores diferentes para A, B e M. slide 30

31 Incerteza de estimativa O tamanho de um sistema de software só pode ser conhecido com precisão quando esse é concluído. Vários fatores influenciam o tamanho final ü Uso de COTS e componentes; ü Linguagem de programação; ü Distribuição de sistemas. Namedidaem queo processo dedesenvolvimento progride então a estimativa de tamanho torna-se mais precisa. As estimativas dos fatores que contribuem para B e M são subjetivas e variam de acordo com o julgamento de quem faz as estimativas. slide 31

32 Incerteza de estimativa slide 32

33 O modelo COCOMO II Um modelo empírico baseado na experiência em projetos. Bem documentado, modelo "independente" que não está vinculado a um fornecedor específico de software. É uma longa história desde a versão inicial publicada em 1981 (COCOMO-81) através de várias instanciações para o COCOMO II. O COCOMO II leva em consideração as diferentes abordagens de desenvolvimento de software, reúso, etc. slide 33

34 Modelos COCOMO II O COCOMO II incorpora uma série de submodelos que produzem estimativas de software cada vez mais detalhadas. Os submodelos COCOMO II são: ü Modelo de composição de aplicação. Usado quando o software é composto de partes existentes. ü Modelo de projeto preliminar. Usado quando os requisitos estão disponíveis, mas o projeto ainda não começou. ü Modelo de reuso. Usado para calcular o esforço de integração dos componentes reusáveis. ü Modelo de pós-arquitetura. Usado uma vez que a arquitetura do sistema foi projetada e mais informações sobre o sistema estão disponíveis. slide 34

35 Modelos de estimativa COCOMO slide 35

36 Modelo de composição de aplicação Apoia prototipação de projetos e em projetos onde há reuso extensivo. Baseado em estimativas padrão de produtividade de desenvolvedores de aplicações (objetos): pontos / mês. Leva em consideração ferramentas CASE. A fórmula é ü PM = ( NAP x (1 - %reuse/100 ) ) / PROD ü PM é a estimativa de esforço em pessoas-mês, o NAP é o número de pontos de aplicação e PROD é a produtividade. slide 36

37 Produtividade de pontos de aplicação slide 37

38 Modelo de projeto preliminar Após os requisitos serem acordados podem ser feitas estimativas. Baseado em uma fórmula padrão para modelos algorítmicos ü PM = A x TamanhoB x M onde: ü M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED; ü A = 2,94 na calibração inicial, Tamanho em KLOC, B varia 1,1-1,24 dependendo da novidade do projeto, a flexibilidade de desenvolvimento, as abordagens de gerenciamento de riscos e a maturidade do processo. slide 38

39 Multiplicadores Os multiplicadores refletem a capacidade dos desenvolvedores, os requisitos não-funcionais, a familiaridade com a plataforma de desenvolvimento, etc. ü RCPX confiabilidade e complexidade de produto; ü RUSE o reúso requerido; ü PDIF dificuldade de plataforma; ü PREX experiência de pessoal; ü PERS capacidade de pessoal; ü SCED cronograma; ü FCIL recursos de apoio da equipe. slide 39

40 O modelo de reúso Leva em conta o código caixa-preta que é reusado sem alterações e o código que deve ser adaptado para integrá-lo com o novo código. Existem duas versões: ü O reúso da caixa-preta, na qual o código, não é modificado. É calculada uma estimativa de esforço (PM). ü O reúso da caixa-branca na qual o código é modificado. É computada uma estimativa do tamanho equivalente ao número de linhas do novo código. Em seguida, ela ajusta a estimativa de tamanho para um novo código. slide 40

41 Estimativa 1 do modelo de reúso Para o código gerado: ü PM = (ASLOC * AT/100)/ATPROD ü ASLOC é o número de linhas de código gerado. ü AT é o percentual de código gerado automaticamente. ü ATPROD é a produtividade dos engenheiros em integrar esse código. slide 41

42 Estimativas 2 do modelo de reúso Quando o código precisa ser entendido e integrado: ü ESLOC = ASLOC x (1-AT/100) x AAM. ü ASLOC e AT como antes. AAM é o multiplicador de ajuste de adaptação, computado a partir dos custos de alteração do código reusado, os custos de compreensão de como integrar o código e os custos de reúso da decisão tomada. slide 42

43 Modelo de pós-arquitetura Usa a mesma fórmula como o modelo de projeto preliminar, mas com 17, em vez de 7 multiplicadores associados. O tamanho do códigoé estimado como: ü Número de linhas de códigonovo para serem desenvolvidas; ü Estimativa do número equivalente de linhas do novo código calculado usando o modelo de reúso; ü Uma estimativa do número de linhas de código que devem ser modificadas de acordo com mudanças de requisitos. slide 43

44 O termo expoente (B) Esse depende de cinco fatores de escala (ver próximo slide). Soma as classificações, divide por 100e adiciona 1,01. Uma empresa assume um projeto em um novo domínio. O clientenão definiu o processo que deve ser usado e não deu tempo para análise de riscos. A empresa tem um nível de CMM 2. ü Precedência - novo projeto (4) ü Flexibilidade de desenvolvimento - sem a participação dos clientes - Muito alta (1) slide 44

45 O termo expoente (B) ü Arquitetura / resolução de riscos - Nenhuma análise de risco M. Baixo (5). ü Coesão da equipe - nova equipe - nominal (3) ü Maturidade do processo - algum controle - nominal (3) Portanto, o fator de escala é, 1,17. slide 45

46 Fatores de escala usados no cálculo expoente no modelo de pós-arquitetura slide 46

47 Multiplicadores Atributos de produto ü Preocupados com as características requisitadas ao produto de software em desenvolvimento. Atributos de computador ü Restrições impostas ao software pela plataforma de hardware. Atributos de pessoal ü Multiplicadores que levam em consideração a experiência e as habilidades das pessoas que trabalham no projeto. Atributos de projeto ü Preocupados com as características particulares do projeto de desenvolvimento de software. slide 47

48 O efeito de drivers de custo nas estimativas de esforço slide 48

49 O efeito de drivers de custo nas estimativas de esforço slide 49

50 Duração de projeto e seleção de pessoal Bem como a estimativa de esforço, os gerentes devem estimar o tempo necessário para completar um projeto e quando a equipe será necessária. ü O tempo pode ser estimado usando uma fórmula COCOMO II ü TDEV = 3 x (PM)( *(B-1.01)) ü PM é o cálculo do esforço e B é o expoente calculado, como discutido anteriormente (B é 1 para o modelo de prototipação anterior). Esse cálculo prevê o cronogramanominal para o projeto. O tempo necessário é independente do número de pessoas trabalhando no projeto. slide 50

51 Requisitos de equipe A equipe necessária não pode ser computada pela estimativa de tempo de desenvolvimento a partir do cronograma. O número de pessoas trabalhando em um projeto varia de acordo com a fase do projeto. Normalmente, quanto mais pessoas trabalham no projeto, maisesforço total é exigido. Muitas vezes, o acúmulo muito rápido de pessoas se correlaciona com o não cumprimento do cronograma. slide 51

52 Pontos importantes Técnicas deestimativa desoftware podem ser baseadas na experiência, em que os gerentes julgam o esforço necessário, ou algorítmicos, em que o esforço necessário é calculado a partir de outros parâmetros de projeto estimados. O modelo de custos do COCOMO II é um modelo de custos que usa atributos de projetos, de produto, de hardware e pessoais, bem como atributos de tamanho e complexidade de produto para obter uma estimativa de custos. slide 52