1 / 39

Planejamento/Gerenciamento

Planejamento/Gerenciamento. Alexandre Mota (acm@cin.ufpe.br). Tempo de Desenvolvimento. A partir da rede de atividades Grafo interligando tarefas com tempo Determinar o caminho crítico O caminho que leva mais tempo para concluir

dyani
Download Presentation

Planejamento/Gerenciamento

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)

  2. Tempo de Desenvolvimento • A partir da rede de atividades • Grafo interligando tarefas com tempo • Determinar o caminho crítico • O caminho que leva mais tempo para concluir • Gerente deve dar especial atenção às tarefas contidas no caminho crítico • É crucial ter folgas no caminho crítico

  3. Identificação de Riscos

  4. Estratégias de Gerenciamento

  5. Sumário de Gerenciamento • Manter informação sempre atualizada • Principalmente tempo e riscos • Colocar pessoas ociosas para revisar trabalho de pessoas ativas (extreme programming) – Qualidade • Avaliar trabalho futuro HOJE • Estar sempre com o plano em mãos

  6. Por que Mensurar? • Indicar a qualidade do produto • Avaliar produtividade • Formar base para estimativas • Determinar benefícios derivados de novos métodos e ferramentas da ES • Justificar aquisição de ferramentas e treinamento

  7. KLOC / Pessoas-mês Erros / KLOC $ / LOC Págs.docum. / KLOC PRODUTIVIDADE = QUALIDADE = CUSTO = DOCUMENTAÇÃO = Utilização de Métricas Projeto Esforço $ KLOC Págs.docum. Erros Pessoas projA-01 24 168 12.1 365 29 3 projB-04 62 440 27.2 1224 86 5 projC-03 43 314 20.2 1050 64 6 MÉTRICAS DERIVADAS

  8. Métricas de Software • Método de Wideband-Delphi • Método de Lógica-Fuzzy • Pontos por Função • COCOMO

  9. Wideband-Delphi • Originado pela Rand Corporation e refinado por Boehm • Consiste em obter consenso a partir de estimativas individuais • As estimativas são geradas após reuniões entre os desenvolvedores • O consenso se dá através de discussões em grupo sobre as estimativas individuais (anônimas)

  10. Wideband-Delphi • O procedimento é: • Grupo de especialistas recebe especificações e formulário de estimativa • Há uma reunião para discutir objetivos, limitações e características do projeto • Daí, anonimamente, cada um lista as tarefas e suas estimativas • Estimativas são agrupadas por um moderador e apresentadas ao grupo • Só a estimativa do especialista é marcada no formulário. As outras ficam iguais.

  11. Wideband-Delphi • O procedimento é: • Há outra reunião para discutir resultados. Cada especialista revê sua lista de tarefas mas não as estimativas • Este processo volta ao passo 3 Até que as estimativas estejam próximas o suficiente

  12. Wideband-Delphi Projeto: Extensão do Rose Estimador: Alexandre Data: 01/03/2003 Aqui está o limite das estimativas da 1a rodada X X* X! X X 0 20 40 60 80 100 X – estimativas X* - sua estimativa X! – estimativa mediana

  13. Método de Lógica-Fuzzy • Estimativa é baseada em dados históricos • Sistemas são divididos em categorias de tamanhos • A escala de tamanhos é dada por logaritmos e ajustadas • Divisão vai até ponto onde sistema atual pode ser encaixado em alguma categoria

  14. Exemplo de Lógica-Fuzzy • Suponha que seu menor programa tenha 173 LOC e o maior 10341 • E deseja-se dividir essa região em 5 categorias • Calculam-se, log 173=2.238 e log 10341=4.014 • E dividem-se (4014 – 2238) por 4 para obter o incremento (0.444)

  15. Exemplo de Lógica-Fuzzy

  16. Método de Lógica-Fuzzy • Considerações Importantes: • Ter dados históricos sobre um grande número de projetos para ter como comparar com as várias categorias • Deve-se atualizar as categorias tão logo haja dados suficientes • As categorias também devem ser ajustadas de acordo com os projetos futuros esperados

  17. Modelos de ciclo de vida • Construa e Conserte (Code-and-Fix, Build-and-Fix) • Cascata (“Waterfall”) • Cascata Modificado • Prototipação • Espiral • Formal • Baseado em reuso

  18. Construa e Conserte • Desvantagens • Sem especificação • Sem projeto • Não gerencia riscos • Vantagens • Baixa sobrecarga de desenvolvimento • Não precisa de especialização • Para sistemas muito pequenos Construa Versão 1 Modifique até cliente estar satisfeito Fase de manutenção

  19. Modelo Cascata Definição de Requisitos Projeto do Sistema Implementação E testes Integração e Testes Operação e manutenção

  20. Características do Modelo Cascata • Desvantagens • Partição inflexível do projeto em estágios distintos • Dificuldade para lidar com as mudanças nos requisitos do sistema • Não gerencia riscos • Vantagens • Orientado a documentação • Manutenção é mais simples

  21. Características do Modelo Cascata* • Desvantagens • Milestones podem tornar-se ambíguos • Atividades em paralelo podem levar a problema de comunicação, suposições errôneas e ineficiência • Vantagens • Atividades podem ser sobrepostas • Mais fácil de lidar com mudanças nos requisitos • Capacidade para gerenciar riscos

  22. Processo Evolucionário • Desenvolvimento exploratório (Protótipo evolucionário) • Construa, avalie e evolua para produto • Trabalhar com os clientes até se obter o produto final a partir de uma especificação bem-definida e completa do sistema. • Protótipo descartável • Construa, use e descarte • Obter requisitos do cliente. Inicia-se com uma especificação incompleta e simples do sistema

  23. Processo Evolucionário Atividades concorrentes Versão inicial Especificação Versões intermediárias Descrição superficial Desenvolvimento Versão final Validação

  24. Perspectivas • Desvantagens • Falta de visibilidade do processo • Sistemas são geralmente mal estruturados • Conhecimentos específicos (ling. de prot. rápida) podem ser necessários • Aplicações • Sistemas interativos de pequeno e médio porte • Partes de sistemas grandes (interface com usuário) • Sistemas com vida útil curta

  25. Processo Formal • Transformação de uma especificação formal em um programa executável • Pode ser empregado de duas formas: • Através de um cálculo de refinamentos • Implementação é derivada por construção, garantindo corretude • Através de passos de refinamento • Versão mais concreta do sistema é proposta e depois deve-se verificá-la em relação a anterior

  26. Processo Formal Definição de requisitos Especificação formal Transformação formal Integração e testes

  27. Perpectivas • Desvantagens • Necessita de profissionais altamente qualificados para aplicar a técnica • Alguns aspectos ainda são difíceis de especificar (GUI) • Vantagens • Garantia de segurança e confiabilidade • Aplicações • Sistemas críticos e complexos

  28. Processo baseado em Reuso • Baseado no reuso sistemático de componentes existentes na própria empresa ou no mercado • Estágios do processo • Análise dos componentes • Modificação dos requisitos • Projeto do sistema com reuso • Desenvolvimento e integração • Validação • Essa abordagem está se tornando cada vez mais importante, mas ainda faltam casos experimentais bem-sucedidos

  29. Processo baseado em Reuso Especificação De requisitos Análise de componentes Modificação De requisitos Projeto com reuso Desenvolv. E integração Validação do Sistema

  30. Processo Iterativo • Os requisitos do sistema SEMPRE mudam durante o desenvolvimento • Iteração pode ser aplicado a qualquer um dos processos de desenvolvimento • Duas abordagens são destacadas: • Desenvolvimento incremental • Desenvolvimento em espiral

  31. Desenvolvimento Incremental • Ao invés de entregar o sistema completo, divide-se o sistema em partes de tal forma a cada entrega corresponder a alguma funcionalidade do sistema • Requisitos do usuário são priorizados e os quanto maior a prioridade mais cedo tal funcionalidade deve ser entregue • Uma vez que o desenvolvimento de um incremento seja iniciado, esses requisitos são fixados enquanto que os posteriores são deixados serem modificados

  32. Desenvolvimento Incremental Requisitos superficiais Requisitos em incrementos Projeto da arquitetura Desenvolv. incremento Validação incremento Integração incremento Validação do sistema Sistema completo Sistema incompleto

  33. Vantagens • Solicitações dos clientes são entregues a cada incremento. Assim, as funcionalidades são entregues o mais cedo possível • Incrementos iniciais servem de protótipo para obter requisitos para incrementos posteriores • Diminuição do risco de falha de todo o projeto • Serviços de maior prioridade tendem a receber maior ênfase em testes

  34. Modelo Espiral • Forma Simplificada • Modelo cascata mais análise de riscos • Precede cada fase por • Alternativas • Análise de riscos • Procede cada fase por • Avaliação • Planejamento da fase seguinte

  35. Modelo Espiral Simplificado • Se os riscos não podem ser resolvidos, projeto é terminado imediatamente

  36. Modelo Espiral Completo • Dimensão Radial • Custo acumulado atualizado • Dimensão Angular • Progresso através da espiral

  37. Modelo Espiral Completo

  38. Características do Modelo Espiral • Desvantagens • Bem aplicado somente a sistemas de larga escala • Sistemas devem ser produtos internos da empresa • Vantagens • Fácil de decidir o quanto testar • Não faz distinção entre desenvolvimento e manutenção

  39. Bibliografia • Leitura adicional • Software Engineering. I.Sommerville • A Discipline for Software Engineering. W.S.Humphrey

More Related