planejamento/gerenciamento alexandre mota (acm@cin.ufpe.br)
Post on 21-Apr-2015
102 Views
Preview:
TRANSCRIPT
Planejamento/Gerenciamento
Alexandre Mota (acm@cin.ufpe.br)
Tempo de Desenvolvimento A partir da rede de atividades
Grafo interligando tarefas com tempo Determinar o caminho crítico
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 RiscosRisco Probabilida
deEfeitos
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 Págs.docum. Erros Pessoas
projA-01 24 168 12.1 365 29 3
projB-04 62 440 27.2 1224 86 5
projC-03 43 314 20.2 1050 64 6
MÉTRICAS DERIVADAS
PRODUTIVIDADE =
QUALIDADE =
CUSTO =
DOCUMENTAÇÃO =
KLOC / Pessoas-mês
Erros / KLOC
$ / LOC
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. Grupo de especialistas recebe especificações e formulário de estimativa
2. Há uma reunião para discutir objetivos, limitações e características do projeto
3. Daí, anonimamente, cada um lista as tarefas e suas estimativas
4. Estimativas são agrupadas por um moderador e apresentadas ao grupo
5. Só a estimativa do especialista é marcada no formulário. As outras ficam iguais.
Wideband-Delphi O procedimento é:
6. Há outra reunião para discutir resultados. Cada especialista revê sua lista de tarefas mas não as estimativas
7. Este processo volta ao passo 3 Até que as estimativas estejam próximas o suficiente
Wideband-DelphiProjeto: Extensão do RoseEstimador: AlexandreData: 01/03/2003Aqui está o limite das estimativas da 1a rodada
0 20 40 60 80 100
X X* X! X X
X – estimativasX* - sua estimativaX! – estimativa mediana
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
ConstruaVersão 1
Modifique atécliente estarsatisfeito
Fase demanutenção
Desvantagens Sem especificação Sem projeto Não gerencia riscos
Vantagens Baixa sobrecarga de
desenvolvimento Não precisa de
especialização Para sistemas muito
pequenos
Modelo Cascata
Definição deRequisitos
Projeto doSistema
ImplementaçãoE testes
Integração eTestes
Operação emanutençã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árioAtividades
concorrentes
Especificação
Desenvolvimento
Validação
Versãoinicial
Versãofinal
Versõesintermediárias
Descriçãosuperficial
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 derequisitos
Especificaçãoformal
Transformaçãoformal
Integração etestes
Perpectivas Desvantagens
Necessita de profissionais altamente qualificados para aplicar a técnica
Alguns aspectos ainda são difíceis de especificar (GUI)
Vantagens 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çãoDe requisitos
Análise decomponentes
ModificaçãoDe requisitos
Projeto comreuso
Desenvolv. Eintegração
Validação doSistema
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
Desenvolv.incremento
Validaçãoincremento
Integraçãoincremento
Validação dosistema
Requisitossuperficiais
Requisitos emincrementos
Projeto daarquitetura
Sistema incompleto
Sistemacompleto
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
Modelo cascata mais análise de riscos Precede cada fase por
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
top related