planejamento/gerenciamento alexandre mota ([email protected])
TRANSCRIPT
![Page 2: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/2.jpg)
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
![Page 3: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/3.jpg)
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
![Page 4: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/4.jpg)
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
![Page 5: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/5.jpg)
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
![Page 6: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/6.jpg)
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
![Page 7: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/7.jpg)
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
![Page 8: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/8.jpg)
Métricas de Software
Método de Wideband-Delphi
Método de Lógica-Fuzzy
Pontos por Função
COCOMO
![Page 9: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/9.jpg)
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)
![Page 10: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/10.jpg)
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.
![Page 11: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/11.jpg)
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
![Page 12: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/12.jpg)
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
![Page 13: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/13.jpg)
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
![Page 14: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/14.jpg)
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)
![Page 15: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/15.jpg)
Exemplo de Lógica-Fuzzy
Categoria LOC
Muito pequeno 173
Pequeno 481
Médio 1338
Grande 3719
Muito grande 10341
![Page 16: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/16.jpg)
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
![Page 17: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/17.jpg)
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
![Page 18: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/18.jpg)
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
![Page 19: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/19.jpg)
Modelo Cascata
Definição deRequisitos
Projeto doSistema
ImplementaçãoE testes
Integração eTestes
Operação emanutenção
![Page 20: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/20.jpg)
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
![Page 21: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/21.jpg)
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
![Page 22: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/22.jpg)
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
![Page 23: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/23.jpg)
Processo EvolucionárioAtividades
concorrentes
Especificação
Desenvolvimento
Validação
Versãoinicial
Versãofinal
Versõesintermediárias
Descriçãosuperficial
![Page 24: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/24.jpg)
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
![Page 25: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/25.jpg)
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
![Page 26: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/26.jpg)
Processo Formal
Definição derequisitos
Especificaçãoformal
Transformaçãoformal
Integração etestes
![Page 27: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/27.jpg)
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
![Page 28: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/28.jpg)
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
![Page 29: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/29.jpg)
Processo baseado em Reuso
EspecificaçãoDe requisitos
Análise decomponentes
ModificaçãoDe requisitos
Projeto comreuso
Desenvolv. Eintegração
Validação doSistema
![Page 30: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/30.jpg)
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
![Page 31: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/31.jpg)
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
![Page 32: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/32.jpg)
Desenvolvimento Incremental
Desenvolv.incremento
Validaçãoincremento
Integraçãoincremento
Validação dosistema
Requisitossuperficiais
Requisitos emincrementos
Projeto daarquitetura
Sistema incompleto
Sistemacompleto
![Page 33: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/33.jpg)
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
![Page 34: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/34.jpg)
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
![Page 35: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/35.jpg)
Modelo Espiral Simplificado
Se os riscos não podem ser resolvidos, projeto é terminado imediatamente
![Page 36: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/36.jpg)
Modelo Espiral Completo Dimensão Radial
Custo acumulado atualizado Dimensão Angular
Progresso através da espiral
![Page 37: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/37.jpg)
Modelo Espiral Completo
![Page 38: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/38.jpg)
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
![Page 39: Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)](https://reader033.vdocuments.site/reader033/viewer/2022051820/552fc15e497959413d8e5835/html5/thumbnails/39.jpg)
Bibliografia Leitura adicional
Software Engineering. I.Sommerville A Discipline for Software Engineering.
W.S.Humphrey