Capítulo 23 Planejamento de Projeto · Planejamento baseada em estórias ... ü Modelo de projeto...

©2011PearsonPrenticeHall.Todososdireitosreservados.

Capítulo23

PlanejamentodeProjeto

©2011PearsonPrenticeHall.Todososdireitosreservados.slide1


Tópicos abordados

• Definição de preço de software

• Desenvolvimento dirigido a planos

• Programação de projeto

• Planejamento ágil

• Técnicas de estimativa


Planejamentodeprojeto

• O planejamento de projeto envolve dividir o projeto em partes e atribuí-las aosmembros da equipe, antecipar os problemas que possam surgir e prepararsoluções para esses problemas.

• O planejamento de projeto, criado no início, é usado para comunicar a equipe eaos clientes como o trabalho será realizado e para ajudar a avaliar o progressodo projeto.


Fasesdoplanejamento

• Na fase de proposta, durante a licitação para um contrato para desenvolver oufornecer um sistema de software.

• Durante a fase de iniciação do projeto, é necessário planejar quem irá trabalharno projeto, como o projeto será dividido em incrementos, como os recursosserão alocados através de sua empresa, etc.

• Periodicamente, ao longo do projeto, quando você modifica o seuplanejamento à luz das experiências adquiridas a partir da monitoração dasinformações e acompanhamento do progresso do trabalho.


Planejamentodaproposta

• Pode ser necessário fazer o planejamento com apenas esboços dos requisitosde software.

• Nessa fase, o objetivo do planejamento é fornecer informações que serãousadas na definição do preço do sistema para os clientes.


Definiçãodepreçodesoftware

• São feitas estimativas para descobrir o custo do desenvolvedor para produzirum 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çocobrado.

• Considerações econômicas, políticas, organizacionais e empresariais maisamplas influenciam o preço cobrado.


Fatoresqueafetamadefiniçãodepreçodesoftware


Desenvolvimentodirigidoaplanos

• O desenvolvimento dirigido a planos é uma abordagem da engenharia desoftware, na qual o processo de desenvolvimento é planejado em detalhes.

ü O desenvolvimento dirigido a planos é baseado em técnicas degerenciamento de projetos e é a forma "tradicional" de gerenciar grandesprojetos 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 umaforma de medir o progresso.


Desenvolvimentodirigidoaplanos–prósecontras

• Os argumentos a favor de uma abordagem dirigida a planos são que oplanejamento antecipado permite que questões organizacionais(disponibilidade de pessoal, outros projetos, etc.) sejam cuidadosamenteconsideradas, e que os problemas potenciais e as dependências sejamdescobertas antes do início do projeto, e não quando o projeto já esteja emandamento.

• O principal argumento contra o desenvolvimento dirigido a planos é que muitasdecisões iniciais precisam ser revistas por causa de alterações no ambiente noqual esse software será usado.


Planosdeprojeto

• Em um projeto de desenvolvimento dirigido a planos, um plano desse projetodefine os recursos disponíveis para o projeto, a divisão de trabalho e umcronograma 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


Suplementosdeplanodeprojeto


Oprocessodeplanejamento

• 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çõessobre o sistema e a equipe desse, você deve rever regularmente o planopara refletir as mudanças de requisitos, cronograma e riscos.

ü Mudanças nos objetivos de negócio também levam a mudanças nosplanos de projeto. Na medida em que os objetivos de negócio mudam,essas mudanças podem afetar todos os projetos, que podem então serreplanejados.


Oprocessodeplanejamentodeprojeto


Programação deprojeto

• A programação de projeto é o processo de decidir como, em um projeto, otrabalho será organizado em tarefas separadas, e quando e como essas tarefasserão executadas.

• Estimar o tempo necessário para concluir cada tarefa, o esforço necessário equem 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árioem hardwares especializados, tal como um simulador, e qual será o orçamentode viagens.


Programação deatividadesdeprojeto

• Dividir o projeto em tarefas e estimar o tempo e os recursos necessários paraconcluir cada tarefa.

• Organizar tarefas simultaneamente para otimizar a utilização da força detrabalho.

• Minimizar as dependências entre as tarefas para evitar atrasos causados poruma tarefa que esteja esperando a conclusão de outras tarefas.

• Depende da intuição e da experiência dos gerentes de projeto.


Etapaseentregas

• As etapas são pontos do cronograma contra os quais você pode avaliar oprogresso, por exemplo, a transferência do sistema para testes.

• Entregas são produtos de trabalho entregues ao cliente, por exemplo, umdocumento de requisitos do sistema.


Oprocessodeprogramação deprojeto


Problemasdeprogramação

• Estimar a dificuldade dos problemas é difícil, assim como estimar o custo dedesenvolvimento de uma solução.

• A produtividade não é proporcional ao número de pessoas trabalhando emuma tarefa.

• Adicionar pessoas a um projeto atrasado atrasa-o ainda mais por causa dooverhead de comunicação.

• O inesperado sempre acontece. Sempre permitir contingências no plano.


Representaçãodecronograma

• Normalmente são utilizadas notações gráficas para ilustrar o cronograma doprojeto.

• Essas mostram a divisão do projeto em tarefas. As tarefas não devem ser muitopequenas. Elas devem levar cerca de uma semana ou duas.

• Os gráficos de barras são a representação mais comumente utilizada paracronogramas de projetos.

• Elas mostram o cronograma como atividades ou recursos contra o tempo.


Tarefas,durações edependências


Gráficodebarrasdeatividades


Gráficodealocaçãodepessoal


Planejamento ágil

• Métodos ágeis de desenvolvimento de software são abordagens iterativas nasquais o software é desenvolvido e entregue aos clientes em incrementos.

• Ao contrário das abordagens dirigidas a planos, a funcionalidade dessesincrementos não é planejada com antecedência, mas decidida durante odesenvolvimento.

ü A decisão sobre o que incluir em um incremento depende do progresso edas prioridades do cliente.

• As prioridades e os requisitos do cliente mudam por isso faz sentido ter umplano flexível, que possa acomodar essas mudanças.


Fasesdoplanejamento ágil

• Planejamento de release, que olha à frente durante vários meses e decidesobre 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 seconcentra no planejamento do próximo incremento de um sistema.

• Geralmente em torno de 2-4 semanas de trabalho de uma equipe.


Planejamento emXP


Planejamentobaseada emestórias

• A especificação do sistema em XP é baseada em estórias de usuários querefletem 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 tempoque acredita ser necessário para implementar a estória.

• O planejamento de release envolve a seleção e refinamento das estórias queirão refletir as características a serem implementadas em um release de umsistema 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 onúmero de estórias refletindo o tempo de entrega de uma iteração (geralmente2 ou 3 semanas).


Pontosimportantes

• O preço cobrado por um sistema não depende apenas dos custos dedesenvolvimento estimados, os quais podem ser ajustados dependendo domercado e das prioridades organizacionais.

• O desenvolvimento dirigido a planos é organizado em torno de um plano deprojeto completo que define as atividades do projeto, o esforço planejado, aprogramação de atividades e quem é responsável por cada atividade.

• A programação de projeto envolve a criação de representações gráficas doplano de projeto. Gráficos de barra mostram a duração da atividade e prazos daequipe, são as representações de cronograma mais usadas.

• O jogo do planejamento de XP envolve toda a equipe no planejamento doprojeto. 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-sea funcionalidade do software.


Técnicasdeestimativa

• 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 defuturos esforços são baseadas na experiência do gerente com projetosanteriores e no domínio da aplicação. Essencialmente, o gerente faz umjuízo fundamentado a respeito de como devem ser os requisitos deesforço.

ü Modelagem algorítmica de custos – Nessa abordagem, é usada umaabordagem para calcular o esforço do projeto com base em estimativas dosatributos de produto, como tamanho e características do processo, assimcomo a experiência da equipe envolvida.


Abordagensbaseadas emexperiências

• Técnicas baseadas em experiências se baseiam em julgamentos baseados naexperiência de projetos anteriores e ao esforço dispendido nesses projetos ematividades de desenvolvimento de software.

• Normalmente, você identifica os entregáveis em um projeto e os diferentescomponentes de software ou sistemas a serem desenvolvidos.

• Você documenta esses em uma planilha, estima cada um individualmente ecalcula o esforço total necessário.

• Normalmente é útil ter um grupo de pessoas envolvido na estimativa deesforço e pedir a cada membro do grupo que explique a sua estimativa.


Modelagemalgorítmicadecustos

• O custo é estimado como uma função matemática de produto, de projeto eatributos de processo, cujos valores são estimados por gerentes de projeto:

ü Esforço = A x TamanhoB xMü A é uma constante dependente da organização, Tamanho é o tamanho do

código, B reflete o esforço proporcional para grandes projetos e M é ummultiplicador refletindo atributos de produtos, processo e de pessoas.

• O atributo de produto mais comumente usado para a estimativa de custo é otamanho do código.

• A maioria dos modelos são semelhantes, mas eles usam valores diferentes paraA, B e M.


Incertezadeestimativa

• O tamanho de um sistema de software só pode ser conhecido com precisãoquando esse é concluído.

• Vários fatores influenciam o tamanho finalü Uso de COTS e componentes;ü Linguagem de programação;ü Distribuição de sistemas.

• Na medida em que o processo de desenvolvimento progride então a estimativade tamanho torna-se mais precisa.

• As estimativas dos fatores que contribuem para B e M são subjetivas e variamde acordo com o julgamento de quem faz as estimativas.


Incertezadeestimativa


OmodeloCOCOMOII

• Um modelo empírico baseado na experiência em projetos.

• Bem documentado, modelo "independente" que não está vinculado a umfornecedor 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 dedesenvolvimento de software, reúso, etc.


ModelosCOCOMOII

• O COCOMO II incorpora uma série de submodelos que produzem estimativasde 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ãodisponíveis, mas o projeto ainda não começou.

ü Modelo de reuso. Usado para calcular o esforço de integração doscomponentes reusáveis.

ü Modelo de pós-arquitetura. Usado uma vez que a arquitetura do sistemafoi projetada e mais informações sobre o sistema estão disponíveis.


ModelosdeestimativaCOCOMO


Modelodecomposição deaplicação

• Apoia prototipação de projetos e em projetos onde há reuso extensivo.

• Baseado em estimativas padrão de produtividade de desenvolvedores deaplicaçõ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.


Produtividadedepontosdeaplicação


Modelodeprojetopreliminar

• 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,24dependendo da novidade do projeto, a flexibilidade de desenvolvimento,as abordagens de gerenciamento de riscos e a maturidade do processo.


Multiplicadores

• Os multiplicadores refletem a capacidade dos desenvolvedores, os requisitosnã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.


Omodelodereúso

• Leva em conta o código caixa-preta que é reusado sem alterações e o códigoque 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. É calculadauma estimativa de esforço (PM).

ü O reúso da caixa-branca na qual o código é modificado. É computada umaestimativa 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.


Estimativa1domodelodereú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.


Estimativas2domodelodereú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 custosde alteração do código reusado, os custos de compreensão de como integrar ocódigo e os custos de reúso da decisão tomada.


Modelodepós-arquitetura

• Usa a mesma fórmula como o modelo de projeto preliminar, mas com 17, emvez de 7 multiplicadores associados.

• O tamanho do código é estimado como:

ü Número de linhas de código novo para serem desenvolvidas;

ü Estimativa do número equivalente de linhas do novo código calculadousando omodelo de reúso;

ü Uma estimativa do número de linhas de código que devem ser modificadasde acordo com mudanças de requisitos.


Otermoexpoente(B)

• Esse depende de cinco fatores de escala (ver próximo slide). Soma asclassificações, divide por 100 e adiciona 1,01.

• Uma empresa assume um projeto em um novo domínio. O cliente não definiu oprocesso que deve ser usado e não deu tempo para análise de riscos. Aempresa tem um nível de CMM 2.

ü Precedência - novo projeto (4)

ü Flexibilidade de desenvolvimento - sem a participação dos clientes - Muitoalta (1)


Otermoexpoente(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.


Fatoresdeescalausadosnocálculoexpoentenomodelodepós-arquitetura


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.


Oefeitodedriversdecustonasestimativasdeesforço


Duraçãodeprojetoeseleçãodepessoal

• Bem como a estimativa de esforço, os gerentes devem estimar o temponecessá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)(0.33+0.2*(B-1.01))

ü PM é o cálculo do esforço e B é o expoente calculado, como discutidoanteriormente (B é 1 para o modelo de prototipação anterior). Esse cálculoprevê o cronograma nominal para o projeto.

• O tempo necessário é independente do número de pessoas trabalhando noprojeto.


Requisitosdeequipe

• A equipe necessária não pode ser computada pela estimativa de tempo dedesenvolvimento a partir do cronograma.

• O número de pessoas trabalhando em um projeto varia de acordo com a fasedo projeto.

• Normalmente, quanto mais pessoas trabalham no projeto, mais esforço total éexigido.

• Muitas vezes, o acúmulo muito rápido de pessoas se correlaciona com o nãocumprimento do cronograma.


Pontosimportantes

• Técnicas de estimativa de software podem ser baseadas na experiência, em queos gerentes julgam o esforço necessário, ou algorítmicos, em que o esforçonecessário é calculado a partir de outros parâmetros de projeto estimados.

• O modelo de custos do COCOMO II é um modelo de custos que usa atributosde projetos, de produto, de hardware e pessoais, bem como atributos detamanho e complexidade de produto para obter uma estimativa de custos.

Capítulo 23 Planejamento de Projeto · Planejamento baseada em estórias ... ü Modelo de projeto...

Documents

Transcript of Capítulo 23 Planejamento de Projeto · Planejamento baseada em estórias ... ü Modelo de projeto...