Planejamento e Gerenciamento. Erros Clássicos. Pessoas. Pessoas. Processo. Processo. Gidevaldo Novais (gidevaldo.vic@ftc.br)

Transcrição

1 Planejamento e Gerenciamento Erros Clássicos Gidevaldo Novais (gidevaldo.vic@ftc.br) Desenvolvimento de Software é uma atividade complicada... Pessoas Motivação incoerente Esforço do pessoal e chefe de férias Pessoal fraco Seleção apressada ao invés de conveniente Pessoal problemático Umapessoapodedesconcentrarumaequipe Heroísmo Posso fazer tudo, não preciso da equipe Mais pessoas no final do projeto Em pequeno incêndio, jogue gasolina Escritórios barulhentos Meu nível de concentração é excelente Pessoas Atrito entre desenvolvedores e clientes Se você não adicionar isso, não quero mais Expectativas irreais Vamos terminar o projeto em 6 meses Falta de interação com o usuário Isso é ambíguo, mas vamos decidir sozinhos Crença cega Essa parte do sistema é muito simples, em 1 ou 2 dias removemos todos os erros Processo Processo Cronogramas altamente otimistas Ganhamos tempo na análise de requisitos e no projeto Gerenciamento de riscos insuficiente Se o risco A se concretizar, resolvemos Falha de contratos Com o módulo M, a ser criado pela empresa E, vamos melhorar nosso cronograma Planejamento insuficiente Esse sistema é simples, não há o que planejar Abandono de plano sob pressão Devido ao cronograma, vamos codificar já da especificação de requisitos e não vamos testar Garantia de qualidade prejudicada Só precisamos fazer os testes a partir da GUI Controle de gerenciamento insuficiente O que já fizemos? Não sei, mas sem problema Sem estimativas para tarefas necessárias Não precisamos registrar o tempo para tarefa T Planejamento para controlar depois Fizemos em 3 meses, o que planejamos fazer em 2, mas depois nós ganhamos tempo Programação sem padronização Vou codificar de qualquer jeito; ganho tempo 1

2 Produto Requisitos demais Sei que o usuário não pediu, mas vamos melhorar a performance do sistema Desenvolvedor exagerado Sei que o sistema não precisa e que não domino a tecnologia, mas vou usar o recurso R Desenvolvimento orientado a pesquisa Sei que vou desenvolver funcionalidade F, estado-da-arte, mas minha estimativa é razoável Tecnologia Síndrome da bala de prata Vou usar o gerador de GUIs e não terei problemas quanto ao desenvolvimento das GUIs Estimativa otimista com novas ferramentas ou métodos Vou usar ferramenta F, no lugar de G, daí vou ganhar tempo Troca de ferramentas no meio do projeto Vou usar a nova versão de F, pois tem mais recursos Falta de controle sobre o código-fonte Vamos trabalhar em paralelo no módulo M (único arquivo), para ganharmos tempo Fundamentos sobre o Desenvolvimento de Software Em software, um caminho para o sucesso é prestar atenção nos fundamentos... Fundamentos de Gerenciamento Estimativas e Cronogramas Estimar tamanho do projeto, esforço necessário e cronograma a cumprir Planejamento O que e como fazer, pessoal, tempo, etc. Acompanhamento status de reuniões, milestones etc. Mensuração Coletar métricas para analisar qualidade e produtividade Fundamentos Técnicos Elicitação e Análise de Requisitos Elicitar, documentar e conferir Projeto Arquitetura do sistema antes de implementar Construção (Implementação) Quanto mais rápido e fácil, melhor... Gerenciamento de Configuração Controlar as versões dos artefatos... Fundamentos de Garantia de Qualidade Testes Mais conhecida técnica de garantia de qualidade Revisões Técnicas Walkthroughs, leitura de código e inspeções 2

3 Por que Planejar? Planejamento Vamos organizar nossas tarefas e determinar nosso esforço Para criar soluções econômicas e a curto prazo de acordo com as necessidades do empregador Para fazer planos que representam precisamente o que se pode fazer Para ser bem-sucedido Ou seja, criar propostas que sejam completadas com recursos financeiros pré-estabelecidos O que é um plano? É um documento que define o trabalho e como ele será realizado O plano provê a definição de cada maior tarefa, com uma estimativa de tempo e recursos exigidos, e um contexto para gerenciamento de controle e revisão Quando documentado apropriadamente, serve também de benchmark para comparar com projetos anteriores A comparação pode levar a melhoria sobre erros em estimativas e a precisão das mesmas Conteúdo de um plano de software Qual é a proposta? Especificamente, o que deve ser entregue, quando e a que custo? Quão bom deve ser esse produto? É o que se deseja? O plano consegue assegurar a satisfação das necessidades? Há elementos disponíveis para verificar qualidade? Há como monitorar progresso? Há alertas antecipados sobre problemas em custo, cronograma e qualidade? Se sim, o quão cedo podem ser detectados e resolvidos? Conteúdo de um plano de software Quão grande é o trabalho? E quanto tempo se espera para realizá-lo? Como será realizado o trabalho? Qual a primeira, segunda, etc., tarefas? Quão bom foi seu plano? Você cometeu erros óbvios? Quais erros devo evitar no futuro? E como fazer um trabalho melhor no futuro? Estrutura de um Plano Introdução Organização do Projeto Análise de Riscos Requisitos com Recursos de SW/HW Detalhamento das Tarefas Milestones/Deliverables Cronograma do Projeto Mecanismos de Monitoração e Relatório 3

4 Marcos e Entregas Milestones (Marcos) Ponto final de uma atividade do processo de software (um marco no cronograma) Deliverables (Entregas) Resultado do projeto a ser entregue ao cliente. Usualmente entregue ao final de uma fase. Tarefas: Duração e Dependências Tarefa Duração (dias) Dependências T1 8 T2 15 T3 15 T1 (M1) T T2, T4 (M2) T6 5 T1, T2 (M3) 20 T1 (M1) 25 T4 (M5) 15 T3, T6 (M4) T10 15, (M7) 7 (M6) 10 (M8) Rede de Atividades Tempo das Atividades 14/7/99 M1 T3 8 days T1 5 days 4/8/99 25/8/99 25/7/99 T6 M4 M6 4/7/99 M3 start 20 days 7 days T2 10 days 25/7/99 10 days 11/8/99 5/9/99 T4 M2 M7 M8 18/7/99 T10 10 days M5 25 days Finish 19/9/99 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Start T4 T1 T2 M1 T3 M5 M3 M2 T6 M4 M7 T10 M6 M8 Finish Alocação de Pessoal 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred T4 Jane T1 T3 Anne T2 T6 T10 Planejando um projeto de software Inicie com uma declaração explícita do trabalho a ser feito e verifique se corresponde ao que o cliente espera Em projetos médios e grandes, criam-se subprojetos menores e estima-os separadamente Baseie suas estimativas com dados históricos de projetos semelhantes Jim Mary 4

5 Planejamento e Estimativa Planejamento e o Processo de Software Registre suas estimativas para comparar com os resultados reais no final do projeto Planejamento continua durante desenvolvimento e manutenção Planejamento inicial não é suficiente Planejamento detalhado mais cedo possível só ocorre após a especificação de requisitos Bibliografia Capítulo 4 Engenharia de Software Ian Sommerville 5