Gerência e Planejamento de Projeto

Transcrição

1 Objetivos Gerência e Planejamento de Projeto Sandra.Pinto Ferraz Fabbri e.mail - sfabbri@dc.ufscar.br Métricas Orientadas ao Tamanho Orientadas à Função de Qualidade de Projeto Técnicas de Decomposição: Estimativa de LO e PF Estimativa de Esforço Modelos Empíricos Modelo Estático de Variável Simples OOMO Ferramentas Plano de Projeto de Software Plano de Projeto- I. Introdução. Escopo e propósito do documento. Objetivos do Projeto II. de Projeto. Dados históricos usados nas estimativas. Técnicas de estimativa. III. Riscos do Projeto. nálise dos riscos. dministração dos riscos IV. ronograma. Divisão do trabalho (work breakdown). Rede de tarefas. Gráfico de Gantt. Tabela de recursos V. Recursos do Projeto. Pessoal. Hardware e Software. Recursos especiais VI. Organização do Pessoal. Estrutura de Equipe. Relatórios dministrativos VII. Mecanismos de ontrole VIII. pêndices II. ESTIMTIVS DE PROJETO MÉTRIS TÉNIS DE DE ESTIMTIVS

2 Métricas Métricas Razões para se medir o software: Indicar a qualidade do produto valiar a produtividade dos que desenvolvem o produto Determinar os benefícios derivados de novos métodos e ferramentas de engenharia de software Formar uma base para as estimativas judar na justificativa de aquisição de novas MEDIDS DIRETS usto Esforço Linhas de ódigo Velocidade de Execução Memória MEDIDS DO SOFTWRE MEDIDS INDIRETS Funcionalidade Qualidade omplexidade Eficiência onfiabilidade ferramentas ou de treinamentos adicionais Nro de Erros Manutenibilidade Métricas MÉTRIS ORIENTDS O TMNHO São derivadas de medidas diretas do software e do processo através do qual ele é desenvolvido Métricas MÉTRIS ORIENTDS O TMNHO LO/KLO projeto esforço $ KLO pags.docum. erros pessoas proj-. 9 projb-. proj-. Exemplos: LO - Lines of ode KLO - Thousand Lines of ode MÉTRIS DERIVDS PRODUTIVIDDE = KLO / pessoas-mês QULIDDE = erros / KLO USTO = $ / LO DOUMENTÇÃO = pags.docum. / KLO

3 Métricas MÉTRIS ORIENTDS O TMNHO Métricas DE QULIDDE VNTGENS: DESVNTGENS: Fáceis de serem obtidas Vários modelos de estimativa baseados em LO ou KLO LO depende da linguagem de programação Penalizam programas bem projetados, mas pequenos Não se adaptam às linguagens não procedimentais Difícil de obter em fase de planejamento 9 corretitude - grau em que o software executa a função que lhe é exigida manutenibilidade - grau de facilidade com que o software pode ser corrigido, adaptado ou ampliado integridade - capacidade que um software tem de suportar ataques (acidentais ou intencionais) à sua integridade usabilidade - tenta quantificar a característica de user friendliness do software Métricas OLET, OMPUTÇÃO E VLIÇÃO DS MÉTRIS Processo de Engenharia de Software oleta de Dados Software omputação das Métricas valiação dos Dados Gerentes Profissionais TÉNIS DE DEOMPOSIÇÃO Subdividem o problema em problemas menores e administráveis Estimativa de de LO e PF Estimativa de de Esforço BSELINE - DDOS HISTÓRIOS

4 TÉNIS DE DEOMPOSIÇÃO Estimativa de de LO e PF ) Decompor o software em funções menores que possam ser estudadas individualmente ) Usando Dados Históricos ou intuição, fornecer para cada subfunção valores de LO ou PF otimista, mais provável, pessimista LO Funções otimista(a) mais provável(b) pessimista(c) Esperado função função função 9 função 9 função 9 função função 9 TÉNIS DE DEOMPOSIÇÃO Estimativa de de LO e PF ) Determinar o número esperado (E) da variável de estimativa (LO ou PF) para cada subfunção: E = ( a + b + c )/ LO Funções otimista(a) mais provável(b) pessimista(c) Esperado função função função 9 função 9 função 9 função função 9 LO ESTIMDO ) Determinar o valor estimado LO ou PF ESTIMDO TÉNIS DE DEOMPOSIÇÃO Estimativa de de LO e PF Determinação do usto e do Esforço: TÉNIS DE DEOMPOSIÇÃO Estimativa de de LO e PF Determinação do usto e do Esforço: BORDGEM BORDGEM De Projetos Passados (Dados Históricos) obtém-se: Produtividade Média = 9 LO/pessoas-mês De Projetos Passados (Dados Históricos) obtém-se: usto Médio = 9, $/LO Diferentes valores de produtividade, de acordo com a Da última Tabela obteve-se LO ESTIMDO = complexidade de cada subfunção. ESFORÇO = LO ESTIMDO / Produtividade Média O USTO e o ESFORÇO são calculados separadamente ESFORÇO = / 9 = pessoas-mes para cada subfunção. USTO = LO ESTIMDO x usto Médio USTO = x 9, = $

5 TÉNIS DE DEOMPOSIÇÃO BORDGEM Estimativa de de LO e PF Funções LO/pessoas-mes $/LO LO Estimado $ pessoas-mes função. função. função.9 função.9 função 9. função 99. função. USTO ESTIMDO DO PROJETO ESFORÇO ESTIMDO DO PROJETO. x : TÉNIS DE DEOMPOSIÇÃO Estimativa de de Esforço ) Decompor o software em funções menores que possam ser estudadas individualmente ) Usando Dados Históricos ou intuição, estimar para cada subfunção o ESFORÇO ( pessoas-mês) necessário em cada etapa da construção do software Etapas da onstrução nálise Funções Requisitos Projeto odificação Teste Totais função..... função função..... função..... função..... função..... função..... TÉNIS DE DEOMPOSIÇÃO Estimativa de de Esforço ) plicar a TX de Trabalho a cada uma das Etapas de onstrução do software ) alcular o USTO e o ESFORÇO para cada função e cada etapa Etapas da onstrução nálise Funções Requisitos Projeto odificação Teste Totais função..... função função..... função..... função..... função.. ESFORÇO. ESTIMDO.. função..... Total.. USTO. ESTIMDO.. Taxa ($).... USTO Modelo Estático de de Variável Simples MODELOS EMPÍRIOS Usam fórmulas derivadas empiricamente OOMO

6 MODELOS EMPÍRIOS Modelo Estático de de Variável Simples REURSO = X ( característica estimada ) ESFORÇO E =. x LO.9 (pessoas-mês) DURÇÃO DO PROJETO D =. x LO. (meses) TMNHO D EQUIPE S =. x E. (pessoas) LINHS DE DOUMENTÇÃO DO = 9 x LO. Modelo de Walston e Felix - constantes derivadas de projetos MODELOS EMPÍRIOS OOMO Modelo : Modelo OOMO Básico (Boehm) modelo estático de variável simples esforço de desenvolvimento calculado em função do tamanho do software (LO) Modelo : Modelo OOMO Intermediário esforço de desenvolvimento calculado em função do tamanho do software (LO) e de um conjunto de "direcionadores de custo Modelo : Modelo OOMO vançado mesmas características do modelo intermediário avaliação do impacto dos "direcionadores de custo" em cada passo do processo de construção MODELOS EMPÍRIOS OOMO MODELOS EMPÍRIOS OOMO São definidos para classes de projetos: Orgânico projetos pequenos equipes pequenas e com baixa experiência requisitos não muito rígidos Semi-Separado projetos com tamanho e complexidade médios equipes com experiências variadas requisitos rígidos e não rígidos Embutido restrições rígidas de hardware, software e operacionais Modelo OOMO Básico Esforço E = (KLO) e B Tempo de Desenvolvimento T = (E) e D Modelo OOMO Intermediário Esforço E = (LO) e B x FE Básico Intermediário classes B D B orgânico semi-separado embutido......

7 MODELOS EMPÍRIOS FE - Fator de juste do Esforço OOMO TRIBUTOS DIREIONDORES DE USTO tributos do Produto: complexidade, confiabilidade exigida tamanho do banco de dados tributos do Hardware: restrições de desempenho, restrições de memória, etc. tributos Pessoais: capacidade, experiência tributos de projeto: uso de ferramentas, métodos, etc. ada atributo é ponderado numa escala de pontos e, através de tabelas publicadas por Boehm, obtem-se o FE, que varia de.9 a. MODELOS EMPÍRIOS Exemplo de aplicação do OOMO Utilizando-se os dados obtidos através da Estimativa LO, o Modelo Básico e Semi-separado, tem-se: E = (KLO) e B T = (E) e D E =. (KLO) exp, =. (.), = pessoas-mes om esses valores é possível determinar um número recomendado de pessoas OOMO T =. (E) exp. =. (). =. meses N = E/T = /. = pessoas FERRMENTS UTOMTIZDS s Técnicas de Decomposição e os Modelos Empíricos de podem ser implementados em software. Esses softwares exigem os seguintes tipos de dados: estimativas quantitativas do tamanho ou funcionalidade do software (LO ou PF) características qualitativas do projeto (complexidade, confiabilidade exigida, etc.) descrição do pessoal de desenvolvimento e/ou ambiente de trabalho (experiência, motivação, etc.) Pontos-haves Quanto às Métricas: Sem medir, não há maneira de determinar se existe melhoria medição resulta em mudança cultural o criar uma baseline (banco de dados contendo medições do processo e do produto), engenheiros e gerentes podem ter uma melhor visão do processo e do produto Quanto às : Não constituiem uma ciência exata; sempre existem Riscos Para diminuir os Riscos, devem ser baseadas em Dados Históricos, que são construídos ao longo do tempo através da utilização de Métricas mais precisas devem fazer uso de várias técnicas

8 Objetivos Plano de Projeto de Software ronograma Redes PERT-PM Duração do Projeto Prazos do Projeto Gráfico de Gantt Gráfico de Recursos ontrole O que é ontrole Tipos de ontrole Formas de conduzir o ontrole 9 I. Introdução. Escopo e propósito do documento. Objetivos do Projeto II. de Projeto. Dados históricos usados nas estimativas. Técnicas de estimativa. III. Riscos do Projeto. nálise dos riscos. dministração dos riscos IV. ronograma. Divisão do trabalho (work breakdown). Rede de tarefas. Gráfico de Gantt. Tabela de recursos V. Recursos do Projeto. Pessoal. Hardware e Software. Recursos especiais VI. Organização do Pessoal. Estrutura de Equipe. Relatórios dministrativos VII. Mecanismos de ontrole VIII. pêndices IV. ronograma. Divisão do trabalho (work breakdown). Rede de tarefas. Gráfico de Gantt. Tabela de recursos precisão nos cronogramas é mais importante que a precisão nos custos ustos adicionais: podem ser absorvidos por várias vendas pode ser estipulado um novo preço O não cumprimento do cronograma: reduz o impacto no mercado cria insatisfação dos clientes cria problemas com a integração dos sistemas

9 DIVISÃO DO TRBLHO E DISTRIBUIÇÃO DO ESFORÇO nálise e Projeto -% tividade de Teste e Depuração -% odificação -% s Técnicas de levam a estimativas de pessoas-mês distribuição do esforço apresentada deve ser considerada uma diretriz s características de cada projeto devem ditar a distribuição do esforço O esforço despendido no planejamento do projeto é, em geral, de a % do esforço total REDES PERT- PM ou REDES de PLNEJMENTO É a representação gráfica de um Programa, na qual se apresenta a seqüência lógica do Planejamento com as interdependências das tarefas, tendo por finalidade atingir um objetivo. PERT - Program Evaluation and Review Technique PM - ritical Path Method Tarefa REDE Duração Interdependêndia tividade Eventos é a execução efetiva de uma operação; consome tempo e/ou rercursos corespondem a macos que caracterizam determinados instantes

10 Planejamento da Rede identificar as tividades identificar a ordem em que ocorrem as tividades determinar a duração das tividades Representação da Rede evento inicial identificação da atividade duração da atividade evento final Tipos de tividades tividades Dependentes TIVIDDE DEPENDENTE atividade B é dependente da atividade se para iniciar B é necessário que tenha sido concluída TIVIDDE PRLEL s atividades e B são paralelas se elas podem ser executadas simultaneamente B atividade só pode ser executada depois que as atividades e B forem concluídas 9

11 tividades Dependentes tividades Paralelas B D s atividades e D só podem ser executadas depois que as atividades e B forem concluídas B s atividades B e podem ser executadas simultaneamente D tividades Paralelas B D atividade fantasma Tempo de Execução da Rede B s atividades B e devem ser identificadas por origem e destino diferentes Tempo de Execução = + + =

12 Tempo de Execução da Rede Para redes complexas, definem-se: cedo do evento tarde do evento folga do evento caminho crítico Tempo de Execução da Rede cedo do evento : tempo necessário para que o evento seja atingido, sem atrasos 9 9 cedo = max ( cedo anterior + duração ) Tempo de Execução da Rede tarde do evento : tempo limite para a realização do evento para não atrasar o projeto Tempo de Execução da Rede folga do evento : diferença entre o tarde e o cedo do evento tarde = min ( tarde posterior - duração ) folga = tarde - cedo

13 Tempo de Execução da Rede caminho crítico : vai do evento inicial ao evento final, passa pelas atividades de maior duração e a soma das durações corresponde ao cedo do evento final (os eventos por onde ele passa têm a menor folga) TRDE = EDO TRDE < EDO TRDE > EDO não existe um prazo para elaboração do projeto existe um prazo que é menor do que o prazo normal para elaboração do projeto existe um prazo que é maior do que o prazo normal para elaboração do projeto álculo do cedo dos eventos: álculo do caminho crítico: B D E 9 F G B D E 9 F G

14 aso : tarde = cedo O cliente não impôs um prazo para o término do projeto aso : tarde < cedo O cliente impôs um prazo menor do que o estimado para o término do projeto B D E 9 9 F G - - B - D 9 - G E F - omo fazer? aso : tarde < cedo reestudar as atividades, considerando o custo de implementação iniciar pelas atividades críticas cuidar para que a redução de uma atividade crítica não consuma a folga de uma não crítica aso : tarde < cedo produzir uma tabela com os seguintes dados: atividades duração custo duração custo diferença diferença custo/ do c.crítico normal normal acelerada acelerado custos durações unid.ac custo da aceleração: x (-) + x (-) = + =

15 aso : tarde < cedo refazer a rede de acordo com as novas datas atividades aceleradas: x (-) + x (-) B D G E F aso : tarde > cedo 9 B D 9 O cliente impôs um prazo maior do que o estimado para o término do projeto G E F 9 omo fazer? aso : tarde > cedo reestudar as atividades, considerando o custo de implementação, para tentar economizar realizando as atividades em ritmo mais lento aso : tarde > cedo produzir uma tabela com os seguintes dados: atividades duração custo duração custo diferença diferença custo/ do c.crítico normal normal lenta lento custos durações unid.desac economia da desaceleração: x (-) + x (-) = + = 9

16 aso : tarde > cedo refazer a rede de acordo com as novas datas atividades desaceleradas: x (-) + x (-) B D G E F 9 9 Exemplo de uma Rede de Tarefas análise e especificação revisão requisitos projeto dados revisão projeto preliminar planejamento testes walkthrough projeto projeto procedimental procedimentos testes codificação walkthrough codificação revisão procedimentos testes teste de unidade teste integração teste validação GRÁFIO DE GNTT Tem por objetivo mostrar a duração de cada tarefa. Seu mérito está na simplicidade. tividade B Duração Gráfico de Gantt planejado realizado

17 Plano de Projeto de Software Pontos de ontrole João na Maria Jorge Pedro Marta TREF TREF TREF TREF TREF TREF TREF TREF TREF TREF 9 I. Introdução. Escopo e propósito do documento. Objetivos do Projeto II. de Projeto. Dados históricos usados nas estimativas. Técnicas de estimativa. III. Riscos do Projeto. nálise dos riscos. dministração dos riscos V. Recursos do Projeto. Pessoal. Hardware e Software. Recursos especiais VI. Organização do Pessoal. Estrutura de Equipe. Relatórios dministrativos VII. Mecanismos de ontrole VIII. pêndices j f m a m j j a s o n d j f m a m Gráfico de Gantt planejado realizado IV. ronograma. Divisão do trabalho (work breakdown). Rede de tarefas. Gráfico de Gant. Tabela de recursos Plano de Projeto-ontrole Plano de Projeto-ontrole VII. Mecanismos de ontrole O que é ontrole? É a comparação entre o efetivo e o planejado com as providências necessárias para o enquadramento dos resultados na conjuntura apreciada, a fim de não produzir desvio em relação ao previsto. Para que um ontrole tenha eficiência é preciso que o seu método seja simples e que o planejamento tenha sido bem elaborado.

18 Plano de Projeto-ontrole Tipos de ontrole por Pontos-haves por tividades por Períodos controla eventos que constituem pontos de amarração de trechos de redes nos quais o cumprimento do tarde do evento é de máxima importância mantém atenção especial sobre cada atividade ou sobre determinadas atividades, consideradas mais importantes faz um apanhado da situação de tempos em tempos; o intervalo escolhido depende do projeto Plano de Projeto-ontrole Formas de conduzir o rastreamento e controle (tracking) do projeto realizar reuniões periódicas sobre a situação do projeto, com relato do progresso e dos problemas avaliar os resultados de todas as revisões conduzidas ao longo do processo de engenharia do software determinar se os marcos de referência formais foram atingidos até a data programada comparar a data de início real com a data de início planejada para cada tarefa do projeto fazer reuniões informais para obter avaliações subjetivas do progresso do projeto 9 Pontos-haves...Em Resumo... Rede de Tarefas e o Gráfico de Gantt constituem um meio simples e eficiente de alocação de tempo e recurso para o projeto O ontrole do Projeto tem por objetivo verificar se o cronograma está sendo cumprido e rearranjar as atividades caso isso seja necessário Planejar: estabelecer objetivos claros e detalhados que serão alcançados entre a situação atual e o objetivo final, juntamente com uma definição do trabalho necessário para alcançá-los Organizar: fazer o levantamento dos recursos necessários para por em prática o trabalho especificado no planejamento, numa estrutura eficaz Gerenciamento de Projeto é a execução repetida das atividades Revisar: modificar o plano, a organização e, possivelmente, os objetivos para acomodar as discrepâncias reveladas pela medição Medir: obter uma contínua realimentação sobre o andamento do que foi planejado Integrar: manter a unidade e a livre operação de recursos, principalmente os elementos humanos, durante a execução do planejado