Planejamento de Software
Leonardo Sameshima Taba
Paulo Eduardo Papotti
Engenharia de Software
PPG-CC
Profa. Dra. Rosângela Aparecida Delloso Penteado
Métricas de Software
O que é métrica?
Muitos termos são usados, indistintamente, mas
representam conceitos distintos.
•
•
•
•
Medida
Medição
Métrica
Indicador
Métricas Orientadas a Tamanho
Erros por KLOC (milhares de linhas de código), defeitos por KLOC,
$ por KLOC e páginas de documentação por KLOC.
Adicionalmente, outras métricas interessantes podem ser calculadas:
erros por pessoa-mês, KLOC por pessoa-mês, $ por página de
documentação.
Métricas Orientadas a Tamanho
• Vantagens
• Desvantagens
Métricas Orientadas a Tamanho
Vantagens
• Fáceis de serem obtidas
• Vários modelos de medidas
• Baseados em LOC ou KLOC
Desvantagens
•
•
•
•
•
LOC depende da linguagem de programação
Penalizam programas bem projetados,
Mas pequenos
Não se adaptam às linguagens não procedimentais
Difícil de obter em fase de planejamento
Métricas Orientadas a Função
• Métricas de software orientadas a função usam uma
medida de funcionalidade entregue pela aplicação como
valor de normalização.
• A métrica orientada a função mais amplamente usada é a
pontos por função (function point – FP).
Pontos por Função
Fatores de Ajuste - Fi
1. O sistema requer salvamento (backup) e recuperação (recovery)?
2. Comunicações de dados são necessárias?
3. Há funções de processamento distribuídas?
4. O desempenho é crítico?
5. O sistema vai ser executado em um ambiente operacional existente,
intensamente utilizado?
6. O sistema requer entrada de dados on-line?
7. A entrada de dados on-line exige que a transação de entrada seja
construída através de várias telas ou operações?
8. Os arquivos mestre são atualizados on-line?
9. As entradas, saídas, arquivos ou consultas são complexas?
10. O processamento interno é complexo?
11. O código é projetado para ser reusado?
12. A conversão e a instalação estão incluídas no projeto?
13. O sistema está projetado para instalações múltiplas em diferentes
organizações?
14. A aplicação está projetada para facilitar modificações e para facilidade
de uso pelo usuário?
Classificação das Fi
Cada resposta deve obedecer a uma escala de 0 a 5.,
em que 0 significa não-importante ou não-aplicável e 5
absolutamente essencial.
PF = total de contagem x [0,65 + 0,01 x Σ(Fi)]
Artigo para consulta
Albrecht, A. J. "Measuring Application Development Productivity". Proc.
IBM Application Development Sysmposium, Monterey, CA, out. de
1979, p 83-92.
Métricas Orientadas a Função
• Vantagens
• Desvantagens
Métricas Orientadas a Função
Vantagens
• Independentes da linguagem;
• Ideal para aplicações que usam linguagem não procedimental;
• Se baseiam em dados mais fáceis de serem conhecidos
durante a evolução do projeto.
Desvantagens
• Cálculo baseado em dados subjetivos;
• Resultado é apenas um número.
Exemplo de utilização de PF
Pontos por caso de uso
A análise de sistemas Orientados a Objetos utiliza
normalmente, os diagramas de Casos de Uso para
descrever as funcionalidades do sistema.
Permite que seja possível estimar o tamanho do
sistema ainda na fase de levantamento de Casos de
Uso.
Grau de detalhe dos Casos de Uso
analisados influencia diretamente
na qualidade final da medição.
1. Calcular total de pesos não
ajustados dos atores
Relacionar os atores, classificá-los de acordo com
seu nível de complexidade (simples, médio ou
complexo)
TPNAA = 1*numAtoresSimples + 2*numAtoresMedio +
3*NumAtoresComplexo
2. Calcular pesos não ajustados dos
casos de uso
Contar os casos de uso e atribuir o grau de
complexidade sendo a complexidade com base no
número de classes e transações.
TPNAUC= 5*numCasoUsoSimples +
10*numCasoUsoMedio + 15*NumCasoUsoComplexo
3. Calcular pontos de casos de uso não
ajustados
PCUNA = TPNAA + TPNAUC
4. Calcular fator de complexidade
técnica
FCT = 0.6 + (0.01 * Somatório dos Ti*Peso)
5. Calcular fatores de complexidade
ambiental
FCA = 1.4 + (-0.03 * Somatório dos Fi*Peso)
6. Calcular pontos de casos de uso
ajustados
PCUA = PCUNA * FCT * FCA
7. Calculos finais
•
•
•
•
•
Pessoa-hora por unidade de PCU (Karner sugere 20)
Estimativa em pessoa-hora (PCUA * PH-PCU)
Tamanho da equipe (dado de entrada
Estimativa em horas(EPH/TE)
Estimativa em meses (EH/160 - considerando 4
semanas e 40 horas por semana)
Artigo para consulta
Karner, G. "Resource Estimation for Objectory Projects". Objective
Systems SF AB (copyright owned by Rational Software), 1993
Exemplo de utilização de PCU
Estimativas de software
Objetivos do planejamento de projeto
• Obter estimativas de recursos, custo e tempo
• Tentar definir cenários de melhor caso, caso
mais provável e pior caso
Escopo
• Primeira atividade do planejamento
• Deve ser detalhado, fechado e não ambíguo
• Definido em acordo com o cliente
• O projeto é factível?
Recursos
Estimando
• Atualmente, o software é o componente mais
caro de sistemas computacionais
• É importante estimar o mais precisamente
possível
• Não é uma atividade exata
• Técnicas de decomposição
• Modelos empíricos
Técnicas de decomposição
• Dimensionamento de software
o Dim. de "lógica nebulosa"
o Dim. de pontos de função
o Dim. de componentes padrão
o Dim. de modificação
• Estimativa de três pontos ou valor esperado
S = (Sot + 4Spr + Spe) / 6
Estimativa baseada no problema
• A partir do escopo, decompõe o software em
funções do problema
• LOC ou FP, variáveis de estimativa, são estimadas
a partir das funções
• Métricas de produtividade como LOC/pm ou FP/pm
são aplicadas à variavel
• As estimativas de cada função são combinadas
para produzir uma estimativa global do projeto
• São feitas estimativas otimistas, mais prováveis e
pessimistas
S = (Sot + 4Spr + Spe) / 6
Estimativa baseada no problema - LOC
Produtividade média: 620 LOC/pm
Custo médio: $8000/mês
Custo por LOC: $13
Custo total: $431.000
Esforço: 54 pm
Estimativa baseada no problema - FP
Estimativa baseada no problema - FP
Estimativa baseada no problema - FP
FPestimados = total x [0.65 + 0.01 x E(Fi)]
FPestimados = 375
Produtividade média: 6,5 FP/pm
Custo médio: $8000/mês
Custo por FP: $1230
Custo total: $461.000
Esforço estimado: 58 pm
Estimativa baseada em processo
• Como na estimação baseada no problema, o
software é decomposto em suas funções
• O processo de desenvolvimento também é dividido
• É estimado o esforço necessário para cada parte
do processo de cada função
• Métricas de produtividade como custo por
undidade de esforço são aplicadas
Estimativa baseada em processo
Custo médio: $8000/mês
Custo total: $368.000
Esforço estimado: 46 pm
Modelos empíricos
• Desenvolvidos através de experimentação com
amostras de diversos projetos
• Estrutura
E = A + B x (ve)c
• Seus resultados devem ser analisados com
cuidado
Modelos empíricos
• Baseados em LOC
• Baseados em FP
COCOMO II
• Pontos por objeto
• Quantidade de
o Telas (interface)
o Relatórios
o Componentes
• Classificação em três níveis de complexidade
COCOMO II
• NOP = (pontos por objeto) x [(100 - %reúso)/100]
• PROD = NOP/pessoas-mês (esforço)
•
Esforço estimado = NOP/PROD
Equação do software
•
•
•
•
E = [LOC x B0.333/P]3 x (1/t4)
E = esforço em pessoas-mês ou pessoas-ano
t = duração do projeto em meses ou anos
B = “fator de aptidões especiais”
• Aumenta lentamente à medida que o projeto se torna mais
complexo. Para programas pequenos (de 5 a 15 KLOC), B = 0,16.
Para programas maiores que 70 KLOC, B =0,39
• P = “parâmetro de produtividade”
• Reflete a maturidade global do processo e práticas de gestão.
Valores típicos podem ser P = 2.000 para um sistema embarcado
de tempo real, P = 10.000 para software de telecomunicações e P
= 28.000 para sistemas comerciais
Comprar ou fazer?
• Normalmente, comprar um componente
pronto é mais barato que desenvolvê-lo
• Árvore de decisões
• Terceirização
Árvore
de decisão
custo estimado =
E (probabilidade do caminho)i
x (custo estimado do caminho)i
Resumindo
• Estimar
o
o
o
Quanto tempo,
Quanto esforço e
Quantas pessoas serão necessárias
• Utilizando o escopo
o
o
Técnicas de decomposição
Modelos empíricos
• Deve-se utilizar mais de uma estimativa
para aumentar a precisão
Gestão de configuração de
software
Gestão de configuração
de software (SCM)
• Controlar mudanças
• Atidade “umbrella”, ocorrendo por todo o
ciclo de vida do software
• Objetivo: Aumentar ao máximo a facilidade
com que mudanças são gerenciadas no
decorrer do projeto
Elementos de um sistema de gestão de
configuração
• Elementos de componente
• Elementos de processo
• Elementos de construção
• Elementos humanos
Item de configuração de software (SCI)
• Informações que são criadas como
parte do processo de desenvolvimento
de software
• São organizados para formar objetos
de configuração
Objetos de configuração
Baseline (referenciais)
• Itens de configuração de software
armazenados que passaram por análise e
revisões técnicas e foram aprovados.
• Exemplos de itens de baseline:
o
o
o
o
o
o
Especificação do sistema
Requisitos do software
Especificação do projeto
Código fonte
Planos e casos de teste
Sistema operacional
Baseline
Repositório
• Além de ser um SGBD, deve auxiliar nas tarefas de
SCM
o Determinação de versão
o
Acompanhamento de dependências e gestão de
modificações
o
Acompanhamento de requisitos
o
Gestão de configuração
o
Pistas de auditoria
Processo de SCM
• Identificar
• Controle de versão
• Controle de modificação
• Auditoria de configuração
• Status reporting
Identificação de objetos
• Abordagem orientada a objetos
• Dois tipos
o Objetos simples
 Unidades de informação
o Objetos agregados
 Coleção de objetos simples e agregados
• Objeto
o Nome
o Descrição
o Lista de recursos
o "Realização"
Controle de versão
• Repositório (banco de dados de projeto)
• Capacidade de gestão de versão
• Facilidade de construir
• Acompanhamento de tópicos (bugs)
• Exemplos: CVS, SVN (não são sistemas "de
construção")
Controle de modificação
• Pedido de modificação
• Relatório de modificação
• Autoridade de controle de modificação (change
control authority, CCA)
• Ordem de modificação de engenharia (engineering
change order, ECO)
• Modificação é feita
• Atividades de qualidade (software quality
assurance, SQA)
• Atualização no repositório
Controle de modificação
• Deve-se tomar cuidado com burocracia demais
• Camadas de controle
o
Nível informal
 SCI não está no baseline
o
Nível de projeto
 SCI está no baseline
o
Nível formal
 Produto já foi entregue
Auditoria de configuração
• Como garantir que as modificações foram
adequadamente implementadas?
• Revisões técnicas formais
• Auditoria de configuração
Auditoria de configuração
• 6 questões:
• A modificação especificada na ECO foi feita?
• Uma revisão técnica formal foi conduzida para
avaliar a correção técnica?
• O processo de software foi seguido e as normas de
ES foram aplicadas?
• A modificação foi refletida no SCI? O autor e a data
da modificação foram registrados?
• Os procedimentos da SCM para anotar a
modificação, registrá-la e relatá-la foram seguidos?
• Todos os SCIs relacionados foram adequadamente
atualizados?
Status reporting
• Questões:
o O que aconteceu?
o Quem fez?
o Quando aconteceu?
o O que mais será afetado?
• Relatório de estado de configuração (configuration
status reporting, CSR)
o Todas as modificações no gerenciamento da
configuração são relatados
o Pode ser colocado em um BD on-line ou site
Bibliografia
[1] Pressman, R. S. - Engenharia de Software - 6ª edição
[2] Pressman, R. S. - Software Engineering, A Practitioner's Approach - 5th
edition
[3] Karner, G. "Resource Estimation for Objectory Projects". Objective
Systems SF AB (copyright owned by Rational Software), 1993
[4] Albrecht, A. J. "Measuring Application Development Productivity". Proc.
IBM Application Development Sysmposium, Monterey, CA, out. de 1979, p
83-92.
[5] Heimberg, V. Grahl, E. A. Estudo de Caso de Aplicação da Métrica de
Pontos deCasos de Uso numa Empresa de Software. Disponível em:
http://www.inf.furb.br/seminco/2005/artigos/130-vf.pdf. Acesso: 03/04/2010