Planejamento de Software

Leonardo Sameshima TabaPaulo Eduardo Papotti

Engenharia de Software        PPG-CCProfa. 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

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.

Métricas Orientadas a Função

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 consultaKarner, G. "Resource Estimation for Objectory Projects". ObjectiveSystems 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 softwareo Dim. de "lógica nebulosa"o Dim. de pontos de funçãoo Dim. de componentes padrãoo 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/pmCusto médio: $8000/mêsCusto 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/pmCusto médio: $8000/mêsCusto por FP: $1230Custo total: $461.000Esforç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êsCusto total: $368.000           Esforço estimado: 46 pm

Modelos empíricos

• Desenvolvidos através de experimentação com amostras de diversos projetos

 • Estrutura

 

 • Seus resultados devem ser analisados com

cuidado

E = A + B x (ve)c

Modelos empíricos

• Baseados em LOC

• Baseados em FP

COCOMO II

• Pontos por objeto • Quantidade de

o Telas (interface)o Relatórioso 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)ix (custo estimado do caminho)i

Resumindo

• Estimaro Quanto tempo,o Quanto esforço eo Quantas pessoas serão necessárias

• Utilizando o escopoo Técnicas de decomposiçãoo 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 Especificação do sistemao Requisitos do softwareo Especificação do projetoo Código fonteo Planos e casos de testeo Sistema operacional

Baseline

Repositório

• Além de ser um SGBD, deve auxiliar nas tarefas de SCMo 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 Nomeo Descriçãoo Lista de recursoso "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

• 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

Controle de modificação

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 relatadoso 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". ObjectiveSystems 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