Lecture 5 :: Planejameto Temporal e Monitorização do Projeto

1. Prof. Doutor
Rogério Patrício Chagas do Nascimento
Professor Associado do
Departamento de Computação (DCOMP)/UFS
Assessor do Reitor para Cidades Inteligentes,
Diretor Científico da EATIS.org
rogerio@ufs.br
GpES
Grupo de Pesquisa em Engenharia de Software
Planejamento Temporal e
Monitorização do Projeto de SW
Lecture 5

2. 2
Sumário
▪ Introdução
– O quê é?
– Quem faz?
– Porquê é importante?
– Qual é o produto?
– Como saber se está bem feita?
▪ Conceitos e princípios básicos
▪ Relação pessoas-esforço
▪ Tarefas, interdependências e planejamento temporal

3. 3
Introdução (I)
▪ É a definição das datas de execução e dos responsáveis pelas tarefas
– composição do Diagrama de Gantt
– preencher detalhes das tarefas na ferramenta de apoio automatizado (MS Project,
etc.)
▪ Quem faz?
– Gestores de Software
▪ Porquê é importante?
– Permite ver a interdependência entre tarefas
– Permite ver o avanço do projeto
▪ Qual o produto?
– Planejamento temporal
– Informes de avanço

4. 4
Introdução (II)
▪ Como fazer bem?
– Todas as tarefas e as suas interligações devem aparecer
▪ opcionalmente, montar uma rede de tarefas
– O esforço, tempo e recursos devem ser atribuídos inteligentemente
▪ Após serem realizadas as Métricas e Estimações do Projeto..
– Os produtos a entregar devem ser devidamente espacejados por um marco (landmark)
▪ datas pré-definidas com intervalos “+/- constantes”
▪ Marcos: entrega da especificação, da análise, do desenho, dos testes, do produto final..

5. 5
Razões que Levam ao Atraso do Projeto
▪ Datas de entrega pouco realistas
▪ Mudança nos requisitos sem atualização das datas de entrega
– falta de atualização do Plano de Projeto
▪ Riscos não considerados
▪ Dificuldades técnicas ou humanas não previstas
▪ Falta de comunicação na equipe de desenvolvimento
▪ Falta de reconhecimento do atraso e ausência de medidas para o corrigir

6. 6
Como Agir Bem em Caso de Atraso?
- Exemplo
▪ O cliente pede a construção de uma classe X em no máximo
9 semanas
– Mas a Estimação e a Análise de Riscos sugerem 14 semanas
▪ O quê fazer?
– Realize uma estimação detalhada baseado em projetos anteriores
– Estabeleça uma estratégia de desenvolvimento incremental que
forneça a funcionalidade crítica em 9 semanas e deixe as outras para
depois
– Explique ao cliente a sua estratégia e porquê 9 semanas não é uma
data realista
▪ Convença-o a receber o produto por incrementos..

7. 7
Princípios Básicos
▪ Compartimentação: o projeto deve
subdividir-se em atividades e tarefas
▪ Interdependência
▪ Atribuição de tempo em unidades de
trabalho
▪ Validação do esforço: comprovar
não ter atribuído mais esforço que os
recursos humanos disponíveis
▪ Definição de responsabilidades
▪ Resultados definidos: tipicamente
um produto
▪ Definição de eventos importantes
(milestone): todas as tarefas se
associam a um evento
– revisão de qualidade, aprovação de
um ou mais produtos, etc

8. 8
Relação Pessoas-Esforço
▪ Mito
– os atrasos corrigem-se com mais pessoas
▪ Errado!
– Pois o overhead adicional pela entrada de um novo membro
na Equipe de Desenvolvimento atrasa ainda mais o projeto

9. 9
Distribuição do Esforço by Lacertae SW
▪ Após realizada a Estimação do Projeto de SW, divida o
tempo estimado da seguinte maneira:
– Planeamento: 2-3%
▪ debitado da distribuição das atividades descrita abaixo..
– Requisitos-Análise-Desenho: 40%
– Geração de Código: 20%
– Testes: 40%

10. 10
Effort Allocation by Roger Pressman
40-50%
30-40%
▪ “front end” activities
–
– customer communication
– analysis
– design
– review and modification
15-20%
▪ testing and installation
– unit, integration
– white-box, black box
– regression
▪ construction activities
– coding or code generation

11. 11
Refinação das tarefas
– Exemplo
▪ Tarefa: descrever o âmbito do software
– Identificação da necessidade, os benefícios e clientes potenciais
– Definir o resultado desejado e as entradas
– Definir funcionalidade/comportamento para cada função principal desenvolvida
– Isolar os elementos da tecnologia a implementar em software
– Investigar a disponibilidade de informação sobre o software existente
– Definir viabilidade técnica
– Estimar rapidamente o tamanho
– Criar definição do âmbito

12. 12
Planejamento Temporal
▪ Similar a qualquer esforço de engenharia
▪ Baseado em trabalho prévio
– Estimações de esforço (dias-pessoa)
▪ utilização de métricas
– Decomposição de funções (ou Classes)
– Seleção do processo de desenvolvimento de sw adequado e do seu conjunto de
tarefas
– Decomposição de tarefas

13. 13
Diagramas de Tempo (Gantt)
Tarefa Semana 1 Semana 2 Semana 3 ...
Identificar necessidades
 Reunir-se com o cliente
 Identificar limitações
 Definir declaração do
produto
 Entrega: declaração do
produto definir

....

14. 14
Monitorização do Projeto
▪ Realização de reuniões periódicas
▪ Avaliação dos resultados das revisões
▪ Determinação de marcos para a elaboração dos produtos gerados
durante a realização do projeto
– Comparando datas previstas com as reais

15. 15
Tabela de Controle do Projeto
Tarefa Início
Previsto
Início
Real
Fim
Previsto
Fim
Real
Responsável Esforço Obs.
Identificar necessidades
Reunir-se com o cliente
Identificar limitações
Definir declaração do
produto
Entrega: declaração do
produto definir
...
A Tabela de Controle pode ser gerada automaticamente, a depender
da ferramenta de apoio (MS Project, etc) utilizada..

16. Próximas Aulas Teóricas
Sobre o Plano de
Projeto de SW…

17. 17
...
▪ Análise e Gestão do Risco
▪ Medições, Métricas e Estimação para Projetos de SW
▪ Estimação de Projetos de SW OO
▪ Como assegurar Qualidade de Software

18. Bons caminhos!
Obrigado pela atenção!Thanks for listening! Merci pour votre attention!
rogerio@dcomp.ufs.br
@Patricium