PlanejamentoGerenciamento Alexandre Mota acmcin ufpe br Tempo de
Planejamento/Gerenciamento Alexandre Mota (acm@cin. ufpe. br)
Tempo de Desenvolvimento n A partir da rede de atividades n n Determinar o caminho crítico n n n Grafo interligando tarefas com tempo 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
Identificação de Riscos Risco Probabilidade Efeitos Pessoal doente Moderada Sério Tamanho do software desconhecido. . . Alta Tolerável Pessoal qualificado não disponível Alta … … Catastrófico
Estratégias de Gerenciamento Risco Estratégia Pessoal doente Reorganizar equipe para ter sobreposição de pessoas/trabalho Recrutamento Alertar cliente sobre possível atraso … Mudança nos requisitos … Analisar rastreamento entre requisitos para determinar impacto
Sumário de Gerenciamento n Manter informação sempre atualizada n n 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
Por que Mensurar? n n n 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
Utilização de Métricas Projeto Esforço $ KLOC proj. A-01 24 168 12. 1 proj. B-04 62 440 proj. C-03 43 314 Págs. docum. Erros Pessoas 365 29 3 27. 2 1224 86 5 20. 2 1050 64 6 PRODUTIVIDADE = KLOC / Pessoas-mês MÉTRICAS DERIVADAS QUALIDADE = Erros / KLOC CUSTO = $ / LOC DOCUMENTAÇÃO = Págs. docum. / KLOC
Métricas de Software n Método de Wideband-Delphi n Método de Lógica-Fuzzy n Pontos por Função n COCOMO
Wideband-Delphi n n 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)
Wideband-Delphi O procedimento é: n 1. 2. 3. 4. 5. 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.
Wideband-Delphi n O procedimento é: 6. 7. 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
Wideband-Delphi Projeto: Extensão do Rose Estimador: Alexandre Data: 01/03/2003 Aqui está o limite das estimativas da 1 a rodada X 0 20 X* X! 40 X – estimativas X* - sua estimativa X! – estimativa mediana 60 X X 80 100
Método de Lógica-Fuzzy n n 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
Exemplo de Lógica-Fuzzy n n 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)
Exemplo de Lógica-Fuzzy Categoria LOC Muito pequeno 173 Pequeno 481 Médio 1338 Grande 3719 Muito grande 10341
Método de Lógica-Fuzzy n Considerações Importantes: n n n 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
Modelos de ciclo de vida n n Construa e Conserte (Code-and-Fix, Build-and-Fix) Cascata (“Waterfall”) n n n Cascata Modificado Prototipação Espiral Formal Baseado em reuso
Construa e Conserte n Desvantagens n n Vantagens n n n Sem especificação Sem projeto Não gerencia riscos 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
Modelo Cascata Definição de Requisitos Projeto do Sistema Implementação E testes Integração e Testes Operação e manutenção
Características do Modelo Cascata n Desvantagens n n 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 n n Orientado a documentação Manutenção é mais simples
Características do Modelo Cascata* n Desvantagens n n n Milestones podem tornar-se ambíguos Atividades em paralelo podem levar a problema de comunicação, suposições errôneas e ineficiência Vantagens n n n Atividades podem ser sobrepostas Mais fácil de lidar com mudanças nos requisitos Capacidade para gerenciar riscos
Processo Evolucionário n Desenvolvimento exploratório (Protótipo evolucionário) n Construa, avalie e evolua para produto n n 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 n Construa, use e descarte n Obter requisitos do cliente. Inicia-se com uma especificação incompleta e simples do sistema
Processo Evolucionário Atividades concorrentes Descrição superficial Especificação Versão inicial Desenvolvimento Versões intermediárias Validação Versão final
Perspectivas n Desvantagens n n 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 n n n Sistemas interativos de pequeno e médio porte Partes de sistemas grandes (interface com usuário) Sistemas com vida útil curta
Processo Formal n n Transformação de uma especificação formal em um programa executável Pode ser empregado de duas formas: n Através de um cálculo de refinamentos n n Implementação é derivada por construção, garantindo corretude Através de passos de refinamento n Versão mais concreta do sistema é proposta e depois deve-se verificá-la em relação a anterior
Processo Formal Definição de requisitos Especificação formal Transformação formal Integração e testes
Perpectivas n Desvantagens n n n Vantagens n n Necessita de profissionais altamente qualificados para aplicar a técnica Alguns aspectos ainda são difíceis de especificar (GUI) Garantia de segurança e confiabilidade Aplicações n Sistemas críticos e complexos
Processo baseado em Reuso n n Baseado no reuso sistemático de componentes existentes na própria empresa ou no mercado Estágios do processo n n n 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
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
Processo Iterativo n n n 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: n n Desenvolvimento incremental Desenvolvimento em espiral
Desenvolvimento Incremental n n n 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
Desenvolvimento Incremental Requisitos superficiais Requisitos em incrementos Projeto da arquitetura Desenvolv. incremento Validação incremento Integração incremento Sistema incompleto Validação do sistema Sistema completo
Vantagens n n 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
Modelo Espiral n Forma Simplificada n n Precede cada fase por n n n Modelo cascata mais análise de riscos Alternativas Análise de riscos Procede cada fase por n n Avaliação Planejamento da fase seguinte
Modelo Espiral Simplificado n Se os riscos não podem ser resolvidos, projeto é terminado imediatamente
Modelo Espiral Completo n Dimensão Radial n n Custo acumulado atualizado Dimensão Angular n Progresso através da espiral
Modelo Espiral Completo
Características do Modelo Espiral n Desvantagens n n n Bem aplicado somente a sistemas de larga escala Sistemas devem ser produtos internos da empresa Vantagens n n Fácil de decidir o quanto testar Não faz distinção entre desenvolvimento e manutenção
Bibliografia n Leitura adicional n n Software Engineering. I. Sommerville A Discipline for Software Engineering. W. S. Humphrey
- Slides: 39