Post on 12-Nov-2018
Gerência de Projetos e Manutenção de Software
Aula 10 – Medição / Manutenção / Encerramento
Andréa Magalhães Magdalenoandrea@ic.uff.br
2017.01
4GPMS 2017.01
Medição
• Por que medir?
• O que significa uma medição?
Medição é o
caminho para
maturidade!
5GPMS 2017.01
Medição
• Medições permitem:– Aumentar a visibilidade do produto, projeto ou
processo– Tomadas de decisão objetivas (“eu acho” x “eu tenho
certeza”)
ProdutoProcesso
2
53
8
9
74
Projeto
6GPMS 2017.01
Baseline de medições
• Medições isoladas usualmente são inúteis
• A partir de diversas medições em contextos semelhantes é possível• Estabelecer uma baseline
• Comparar as novas medições com a baseline
7GPMS 2017.01
Medindo pessoas?
• Importante• Não utilizar medições de Engenharia de Software
para punir ou premiar indivíduos!!!• Medições devem ser utilizadas para aprimorar o
produto, projeto ou processo
8GPMS 2017.01
O que medir?
• Existe uma técnica que nos apoia nessa tarefa• Goal-Question-Metric (GQM)
• Algoritmo1. Definir os objetivos de negócio (Goal)2. Definir questões que permitem verificar se cada
objetivo está sendo atingido (Question)3. Definir medidas que apoiam na resposta de
cada questão (Metric)
9GPMS 2017.01
Exemplo: processo de Gerência de Configuração• O que medir em Gerência de Configuração?
• A efetividade do processo
• Os custos associados
• Os benefícios obtidos
• Sugestão: • Aplicar GQM
• Começar a medir antes demodificar o processo
10GPMS 2017.01
Exemplo: processo de Gerência de Configuração• Métricas
• Custo de operação• Número de sistemas/ICs sob gerência de configuração• Número de solicitações de modificação por mês• Tempo gasto para resolução de solicitações de
modificação• Carga de disco/memória/processamento do servidor de
GC• Densidade de defeitos por severidade• Número de achados na auditoria de GC• Tempo gasto para resolução dos achados de auditoria• Intervalo entre releases• Número de releases corretivas
11GPMS 2017.01
Como analisar as métricas obtidas?
• É possível definir um limite (threshold) para a métrica em questão• Se a métrica passar desse limite, é
necessário fazer uma análise de causa
• Qual seria um limite apropriado?• Que tal deixar a própria história determinar
esse limite?
12GPMS 2017.01
Processos estáveis x capazes
• Nem sempre o processo “mais rápido” é um processo estável ou capaz• Um processo estável permite que o
desempenho futuro seja previsível em função do desempenho passado
• Um processo capaz é um processo estável em que o desempenho atende aos requisitos do usuário
13GPMS 2017.01
Processos estáveis x capazes
• Problema: • Ir em até 20 minutos de Icaraí para São
Francisco• Processos
• Ir de carro• Ir de ônibus• Ir de bicicleta• Ir a pé
• Quais processos são estáveis?• Quais processos são capazes?
14GPMS 2017.01
Processos estáveis x capazes
tempo
pro
ba
bil
ida
de
20 min
tempo
pro
ba
bil
ida
de
20 min
tempo
pro
ba
bil
ida
de
20 min
tempo
pro
ba
bil
ida
de
20 min
carro ônibus
a pé bicicleta
estável
e capaz
15GPMS 2017.01
Gráfico de controle
• O gráfico de controle é um artefato que nos permite analisar a estabilidade de um processo
• Foi criado em 1920 por Walter Shewhart
0,0
2,0
4,0
6,0
8,0
10,0
12,0
1 3 5 7 9 11 13 15 17 19
+3σ
+2σ
+1σ
μ
-1σ
-2σ
-3σ
Solicitações corretivas
16GPMS 2017.01
Algoritmo para construção do gráfico de controle1. Coletar uma série temporal da métrica
desejada
2. A partir da série temporal da métrica desejada calcular
1. Média:
2. Desvio-padrão:
∑×==
n
iix
n 1
1µ
∑ −×−
==
n
iix
n 1
2)(1
1 µσ
17GPMS 2017.01
Algoritmo para construção do gráfico de controle3. Desenhar um gráfico com linhas
delimitando• Média• 1 desvio-padrão para cima e para baixo da
média• 2 desvios-padrão para cima e para baixo da
média• 3 desvios-padrão para cima e para baixo da
média4. Desenhar os pontos da série desejada e
conectar os pontos via uma linha
18GPMS 2017.01
Exemplo – número de solicitações corretivas por semana• Passo 1 – coleta de métricas
• Passo 2 – cálculo de média e desvio padrão
Semana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Solicitações
corretivas5 6 5 9 6 5 4 6 7 5 6 5 5 7 6 3 4 5 8 6
μ 5,65
σ 1,39
19GPMS 2017.01
Exemplo – número de solicitações corretivas por semana• Passos 3 e 4 – desenho do gráfico de
controleSemana 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Solicitações
corretivas5 6 5 9 6 5 4 6 7 5 6 5 5 7 6 3 4 5 8 6
+3σ 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8 9,8
+2σ 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4 8,4
+1σ 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0 7,0
μ 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7 5,7
-1σ 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3 4,3
-2σ 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9 2,9
-3σ 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5 1,5
20GPMS 2017.01
Exemplo – número de solicitações corretivas por semana• Passos 3 e 4 – desenho do gráfico de
controle
0,0
2,0
4,0
6,0
8,0
10,0
12,0
1 3 5 7 9 11 13 15 17 19
+3σ
+2σ
+1σ
μ
-1σ
-2σ
-3σ
Solicitações corretivas
21GPMS 2017.01
Análise do gráfico de controle
• Causa comum de variação• Dentro dos limites de probabilidade
• Existe em todo processo estável e previsível
• Causa especial de variação• Foge os limites de probabilidade
• Precisa ser analisada e evitada para que o processo possa ser estável e previsível
22GPMS 2017.01
Análise do gráfico de controle
• Quando o comportamento do gráfico foge do esperado...• É necessário achar uma causa atribuível• O processo pode estar instável
• Situações a serem analisadas• 1 evento além de μ ± 3σ• 2 de 3 eventos sucessivos do mesmo lado além
de μ ± 2σ• 4 de 5 eventos sucessivos do mesmo lado além
de μ ± 1σ• 8 eventos sucessivos do mesmo lado de μ
23GPMS 2017.01
-5,0
0,0
5,0
10,0
15,0
20,0
1 3 5 7 9 11 13 15 17 19
+3σ
+2σ
+1σ
μ
-1σ
-2σ
-3σ
Solicitações corretivas
Análise do gráfico de controle
25GPMS 2017.01
O que é a manutenção?
Leonardo Murta Manutenção de Software 25
“O processo de modificar um sistema de software ou componente, depois da
entrega, para corrigir falhas, melhorar desempenho ou outros atributos, ou adaptar a mudanças no ambiente.”
IEEE Std 620.12 1990
26GPMS 2017.01
Quando inicia a manutenção?
Leonardo Murta Manutenção de Software 26
Desenvolvimento ManutençãoRelease
27GPMS 2017.01
Quando inicia a manutenção?
Leonardo Murta Manutenção de Software 27
Desenvolvimento ManutençãoRelease
Desenv.
Manut.
Release
Desenv. Release
Manut.
Desenv.
Quais são os tipos de manutenção?
Manutenção de Software 28Leonardo Murta
Manutenção
Correção Evolução
Emergencial Corretiva Adaptativa PerfectivaPreventiva
29GPMS 2017.01
Quais são os tipos de manutenção?
• Manutenção corretiva• Reativa• Corrige problemas reportados• Faz o software voltar a atender aos requisitos
• Manutenção emergencial• Não programada• Mantém temporariamente o sistema funcionando• Necessita uma manutenção corretiva posterior
Leonardo Murta Manutenção de Software 29
30GPMS 2017.01
Quais são os tipos de manutenção?
• Manutenção preventiva• Pró-ativa• Corrige problemas latentes
• Manutenção adaptativa• Mantém o software usável após mudanças no
ambiente
• Manutenção perfectiva• Provê melhorias para o usuário• Melhora atributos de qualidade do software
Leonardo Murta 30
31GPMS 2017.01
Contratos de manutenção
• Tipo 1• Um único contrato para desenvolvimento e
manutenção• Valor fixo, disponível para todos os tipos de
manutenção
• Tipo 2• Contrato separado para manutenção• Período de manutenções corretivas predefinido• Cada manutenção preventiva, adaptativa ou
perfectiva contratada separadamente
Leonardo Murta Manutenção de Software 31
32GPMS 2017.01
Boas práticas para manutenção (de código)• Legibilidade• Estruturação• Redução da complexidade• Comentários precisos• Indentação e espaçamento• Evitar o uso de armadilhas clássicas das
linguagens• Ex.: Goto, herança múltipla, etc.
• Usar técnicas que ajudam a rastrear erros• Ex.: Controle de exceções
Leonardo Murta Manutenção de Software 32
33GPMS 2017.01
Boas práticas para manutenção (de código)
• Rastreabilidade• Código para requisitos, análise e projeto• Código para solicitações de modificação
• Padronização• Inspeções• Testes• Atualização da documentação
• Ex.: Modelos
Leonardo Murta Manutenção de Software 33
34GPMS 2017.01
Frases para pensar...
• “Fazer é só uma vez, manter é para sempre”
• “Se você não tem tempo para fazer direito, quando terá tempo para fazer de novo?”
36GPMS 2017.01
Encerramento• Verificação de todos os grupos de processos
para determinar se seus processos foram encerrados
• Homologação e encerramento de contratos realizados com fornecedores de recursos e serviços utilizados durante o projeto
• Disseminação das informações finais sobre o projeto, como lições aprendidas e resultados obtidos
• Também pode indicar o fim prematuro do projeto, por cancelamento.
Fechamento da subcontratação
Fechamento de projeto ou fase
37GPMS 2017.01
Encerramento
• Não é hora de relaxar• Se o gerente relaxa, a equipe perde o foco e relaxa
também
• Também não é hora de se desesperar• Calma• Organize e trate o trabalho final como um mini
projeto• Comunique-se com a equipe, mas deixe que os
membros terminem suas tarefas• Confira a qualidade• Trabalhe em turnos se a sobrecarga for inevitável
38GPMS 2017.01
Encerramento
• Postmortem• Revisão da qualidade dos produtos
• A meta foi obtida?• A visão do projeto foi alcançada?• Produtos com qualidade desejada?
• Revisão da qualidade dos processos• O projeto estava no caminho certo do início ao fim?• O planejamento foi correto?
• Examinando o valor do projeto• Quanto vale o projeto?
• Lições aprendidas• Alterações no processo organizacional
39GPMS 2017.01
Encerramento
• Obtendo a aprovação final• Aceitação informal
• Prazo concluído e produtos gerados
• Aceitação formal• Depende de um acordo de aceitação do projeto
estabelecido no início do projeto
41GPMS 2017.01
Exercício
• Preparar o relatório de encerramento com as lições aprendidas do seu trabalho
44GPMS 2017.01
Seminários
• Apresentação do andamento do trabalho
• Apresentação com duração de 20 minutos por grupo
• Entrega de slides e relatório do trabalho
• Opcional o uso do quadro
• 1º. Seminário• Escopo do produto• Escopo do projeto• Estimativas de esforço e
custo• EAP• Orçamento• Cronograma• Versão parcial do produto** Plano de projeto
• 2º. Seminário• Plano de comunicação• Análise de riscos• Monitoramento e controle
• Gráfico de burndown• Análise de valor agregado
• Plano de gerência de configuração
• Gestão de mudanças• Versão final do produto• Lições aprendidas** Relatório de encerramento do projeto