Plano de projeto Cronograma e Controle
Razões para atrasar um projeto Um deadline não realístico estabelecido por alguém fora do grupo de engenharia de software Câmbios nos requerimentos do software não previstos no cronograma Uma estimação baixa da quantidade de esforço e/ou os recursos para o trabalho Dificuldades técnicas não previstas com antecendêcia. Falta ou erro na comunicação entre a equipe Falha do gerente do projeto ao reconhecer que o projeto esta detrás no cronograma e não tomar medidas.
A precisão nos cronogramas é mais importante que a precisão nos custos Custos 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
Exemplo O grupo é perguntado sobre construir um controlador de tempo real de um instrumento de diagnóstico médico que vai ser introduzido no mercado em 9 meses. Depois de uma estimação cuidadosa e a análise de risco, o gerente tem a conclusão que o software requere 14 meses com o pessoal disponível. Que fazer?
1. Execute uma detalhada análise das estimativas usando projetos passados. Determine esforço e duração do projeto 2. Usando modelo incremental desenvolva estratégia que entregará as funções críticas do software no deadline. Documente o planejamento. 3. Entreviste se com o cliente e usando a estimativa explique que o deadline não é realístico. 4. Ofereça a estratégia incremental como alternativa. Negue a possibilidade de atrasar o cronograma depois.
Princípios básicos a ser definidos no cronograma de um projeto de software para cada tarefa Compartimetação: O projeto deve ser dividido em atividades e tarefas. O produto e o processo devem ser descompostos Interdependência: Definição de dependências entre as tarefas e atividades. Algumas acontecem em seqüência e outras em paralelo. Algumas não começam até o produto de outras atividades estar pronto e outras acontecem independentemente. Alocação de tempo: Para cada tarefa a ser programada deve ser alocada alguma quantidade de trabalho (pessoadia ou esforço). Cada tarefa deve ter data de inicio e fim. Validação de esforço: Para cada projeto se define o grupo de trabalho. Acontece a alocação de tempo. Definição de responsabilidades: Cada tarefa no cronograma deve ter um responsável Definição de resultados: Cada tarefa deve ter um resultado. Para projetos de softwares o resultado é normalmente um produto do trabalho. Produtos do trabalho são freqüentemente combinados em entregas Definição de marcos: Cada tarefa ou grupo de tarefas deve estar associada a um marco do projeto. O marco é alcançado quando um ou mais produtos entregues são revisados para determinar qualidade e foi aprovado.
Relação Pessoa - Esforço Em pequenos softwares uma pessoa pode fazer a análise de requisitos, fazer o design, gerar o código e conduzir os testes. Quando o tamanho aumenta mais pessoas são envolvidas Não podemos nos dar o luxo de ter uma aproximação de esforço de 10 pessoa-ano Lembrar MITO
Exemplo: MITO Considere 4 engenheiros que produzem 5000 LOC/year em projetos individuais Juntos 6 caminhos de comunicação potenciais -> tempo. Reduze produtividade em 250 LOC/year. Então ao invés de produzir 20000 LOC/year (- 250X6) produzem 18500 LOC/year. 7.5% menos O tempo de 1 ano para fazer cai no cronograma a 2 meses de finalizar o tempo. 2 pessoas são adicionadas. Caminhos de comunicação aumentam para 14. a produtividade dos novos é 84X2 = 1680 LOC por 2 meses. A produtividade agora é de 20000 + 1680 (250X14) = 18180 LOC/year.
Exemplo Equação do software L = PX(E/B) 1/3 t 4/3 E-esforço, P produtividade (2000-28000), B fator habilidade (0.16-0.39) e uma função do tamanho do projeto, t duração em meses E = L 3 /B 3 t 4 E (pessoa-ano) Considere um software de tempo real complexo estimado em 33000 LOC, 12 pessoa-ano de esforço Se 8 pessoas estão no projeto ele deve ser completado em 1.3 anos. Se estendemos nosso tempo a 1.75 anos o modelo da E<3.8 pessoa-ano BENEFÍCIOS!!!
Distribuição de esforço Regra 40-20-40
Distribuição de esforço As Técnicas de Estimativas levam a estimativas de pessoas-mês A distribuição do esforço apresentada deve ser considerada uma diretriz As características de cada projeto devem ditar a distribuição do esforço O esforço despendido no planejamento do projeto é, em geral, de 2 a 3% do esforço total
Definindo tarefas Tipos de projetos Projeto de novos conceitos Projeto de aplicações novas Projetos de melhorias Projetos de manutenção Projetos de reengenharia
Definindo tarefas Grau de rigor Casual: Todas as atividade framework são aplicadas, só um mínimo de tarefas é requerido. Atividades guarda chuva são minimizadas e os requerimentos de documentação também. Estruturado: O processo é totalmente aplicado. As atividades guarda chuvas necessárias para assegurar qualidade são complementadas. Agilidade na medida de qualidade, documentação e tarefas Estrito: O processo é totalmente feito com um alto grau de disciplina. Todas as atividades guarda-chuva são aplicadas e documentação robusta deve ser gerada Reação rápida Situações de emergência. (documentação e revisões profundas depois da liberação). RARAS OCAÇÕES
Definindo tarefas Critérios de adaptação sugerem o grau de rigor Tamanho do projeto Número potencial de usuários Criticalidade Longevidade Estabilidade dos requisitos Facilidade da comunicação desenvolvedor/cliente Maturidade da aplicação da tecnologia Restrições de performance Características embutidas/não embutidas Características das pessoas Fatores de reengenharia
Definindo tarefas Seletor de tarefas Grau Peso T. Projeto Produto Critério de adaptação n conceitos ap novas melh manut reeng Tamanho do projeto 1.2 0 1 1 1 1 Número usuários 1.1 0 1 1 1 1 Criticalidade 1.1 0 1 1 1 1 Longevidade 0.9 0 1 1 0 0 Estabilidade requisitos 1.2 0 1 1 1 1 Facilidade com desenvolvedor/cliente 0.9 1 1 1 1 1 Maturidade da aplicação tecnologia 0.9 1 1 0 0 1 Restrições de performance 0.8 0 1 1 0 1 Características embutidas/não embutidas 1.2 1 1 1 0 1 Características das pessoas 1 1 1 1 1 1 Interoparabilidade 1.1 0 1 1 1 1 Fatores de reengenharia 1.2 0 0 0 0 1 Seletor TSS<1.2 1.0<TSS<3.0 TSS>2.4 Grau de Rigor Casual Estruturado Estrito
Seleção de tarefas de Engenharia de software Tarefas principais Escopo do conceito Planejamento conceitual preliminar Avaliação de riscos da tecnologia Prova do conceito Implementação do conceito Reação do cliente ao conceito
Desenvolvimento do conceito modelo seqüencial Definição do projeto Planejamento Construção Liberação Avaliação do cliente Definição do conceito Prova do conceito Planejamento preliminar do conceito Avaliação de risco tecnológico Construção do conceito Reação do cliente
Desenvolvimento do conceito modelo evolucionário Definição do conceito Planejamento preliminar do conceito Avaliação de risco tecnológico Reação do cliente Prova do conceito Construção do conceito
Refinamento de tarefas Tarefa 1 Escopo do conceito 1.1 Identificar necessidade, benefícios e potenciais clientes 1.2 Definir entrada/saída desejada, eventos de entrada que conduzem a aplicação Iniciar tarefa 1.2 1.2.1 Revisão técnica formal da descrição das necessidades 1.2.2 Derivar uma lista de entradas/saídas visíveis ao cliente case of mech mech = desenvolvimento de função de qualidade: Encontre ao cliente para isolar os requerimentos do conceito; entreviste ao usuário final; observe aproximação atual ao problema, processo atual; revise requerimentos anteriores e queixas mech = Analise estrutural: Faça a lista de os objetos de dados mais importantes; defina relações entre os objetos; defina atributos do objeto. mech = Visualização do objeto: Faça a lista de classes de problemas; desenvolva hierarquia de classes e conexão de classes; defina atributos da classe. 1.2.3 FTR: Revise entradas/saídas com o cliente e revise os requerimentos Finalizar Tarefa 1.2
1.3 Definir o comportamento da funcionalidade para cada função principal Iniciar Tarefa 1.3 FTR saídas e entradas de dados derivados da tarefa 1.2 1.3.2 Derive um modelo de função/comportamento case of mech mech = desenvolvimento de função de qualidade: Encontre ao cliente para revisar os requerimentos do conceito; entreviste ao usuário final; observe aproximação atual ao problema, processo atual; revise requerimentos anteriores e queixas; desenvolva um esboço de função comportamento mech = Analise estrutural: Derive a diagrama de fluxo a nivel do contexto. Refine o diagrama de fluxo de dados para prover mais detalhes; escreva narrativas do processo mech = Visualização do objeto: Defina operações/métodos que são relevantes para cada clase. 1.3.3 Revise função/comportamento com o cliente e revise requerimentos Final Tarefa 1.3 1.4 Isole os elementos tecnológicos para serem implementados no software 1.5 Procure software existentes 1.6 Defina viabilidade 1.7 Faça a estimação de tamanho rápida 1.8 Crie a definição de escopo Final da tarefa
Rede de tarefas 3a. Avaliação Risco Tec. 5a. Implem. Conceito 1. Escopo do Conceito 2. Planejamento do Conceito 3b. Avaliação Risco Tec. 4. Prova do Conceito 5b. Implem. Conceito 6. Integra. 7. Reação Cliente 3b. Avaliação Risco Tec. 5b. Implem. Conceito
Exemplo de rede de tarefas
Produto Software processador de texto Conjunto de tarefas Conceito de escopo 1.1 Identificar necessidades e benefícios Reunirse com os clientes Identificar necesidades e restrições do projeto Estabelecer declaração do produto Marco Declaração do produto definido 1.2 Definir entrada/controle/saída desejado Alcance das funções de teclado Alcance das funções de entrada Alcance dos modos de interação Alcance dos documentos de diagnóstico Alcance de outras funções Documento OCI FTR Revisar OCI com clientes Revisar OCI se requerido Marco: OCI definido 1.3 Definir funcionalidade/comportamento Definir funções de teclado Definir entradas de voz Descrever modos de interação Descrever chequeo de gramática e ortografía Descrever outras funções WP FTR Revisar definiçoes OCI com o cliente Revisar quando requerido Marco: Definição de OCI completada 1.4 Isolar elementos de software Marco: Definidos os elementos de software 1.5 Procurar disponibilidade de software existentes Procurar componentes de edição de texto Procurar componentes de entrada de voz Procurar componentes de chequeo de gramática e ortografía Marco: Componentes reusaveis identificadas 1.6 Definir viabilidade tecnica Avaliar entrada de voz Avaliar chequeo de gramática Marco: Viabilidade tecnica avaliada 1.7 Fazer estimativa de tamanho 1.8 Crear deficição de escopo Revisar documento de escopo com o cliente Revisar documento quando requerido Marco: Documento de Escopo completado semana 1 semana 2 semana 3 semana 4 semana 5
Gráfico de Gantt Tem por objetivo mostrar a duração de cada tarefa. Seu mérito está na simplicidade.
Mecanismos de controle O que é Controle? É 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 Controle tenha eficiência é preciso que o seu método seja simples e que o planejamento tenha sido bem elaborado.
Controle
Controle 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
A 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 Controle do Projeto tem por objetivo verificar se o cronograma está sendo cumprido e rearranjar as atividades caso isso seja necessário