Planejamento/Gerenciamento
Alexandre Mota
([email protected])
Tempo de Desenvolvimento

A partir da rede de atividades


Determinar o caminho crítico



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

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
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
Utilização de Métricas
Projeto
Esforço
$
KLOC
projA-01
24
168
12.1
projB-04
62
440
projC-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

Método de Wideband-Delphi

Método de Lógica-Fuzzy

Pontos por Função

COCOMO
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)
Wideband-Delphi
O procedimento é:

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

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 1a 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




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




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

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
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
Construa e Conserte

Desvantagens




Vantagens



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

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
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
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
Processo Evolucionário
Atividades
concorrentes
Descrição
superficial
Especificação
Versão
inicial
Desenvolvimento
Versões
intermediárias
Validação
Versão
final
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
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
Processo Formal
Definição de
requisitos
Especificação
formal
Transformação
formal
Integração e
testes
Perpectivas

Desvantagens



Vantagens


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

Sistemas críticos e complexos
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
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



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
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
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




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

Forma Simplificada


Precede cada fase por



Modelo cascata mais análise de riscos
Alternativas
Análise de riscos
Procede cada fase por


Avaliação
Planejamento da fase seguinte
Modelo Espiral Simplificado

Se os riscos não
podem ser
resolvidos, projeto é
terminado
imediatamente
Modelo Espiral Completo

Dimensão Radial


Custo acumulado atualizado
Dimensão Angular

Progresso através da espiral
Modelo Espiral Completo
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
Bibliografia

Leitura adicional


Software Engineering. I.Sommerville
A Discipline for Software Engineering.
W.S.Humphrey