Planejamento de Software

Apresentação em tema: "Planejamento de Software"— Transcrição da apresentação:

1 Planejamento de Software
Leonardo Sameshima Taba Paulo Eduardo Papotti Engenharia de Software        PPG-CC Profa. Dra. Rosângela Aparecida Delloso Penteado

2 Métricas de Software

3 O que é métrica? Muitos termos são usados, indistintamente, mas representam conceitos distintos. Medida Medição Métrica Indicador O termo medida, no contexto de engenharia de software, fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de produto ou processo.  Por outro lado, medição pode ser definida como o ato de determinar uma medida.  Por fim, a definição de métrica, de acordo com o IEE Standard Glossary, é “uma medida quantitativa de grau em que um sistema, componente ou processo possui um determinado atributo”. Indicador é uma métrica ou conjunto de métricas que fornece profundidade de visao do processo de software, projeto de sotware ou o produto em si.

4 Métricas Orientadas a Tamanho
Métricas orientadas a tamanho são originadas pela normalização das medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi produzido. Depende de gravação de dados histórico dos projetos. 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.

5 Métricas Orientadas a Tamanho
Vantagens Desvantagens

6 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

7 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).

8 Pontos por Função Nr. de entradas de usuário que forneçam dados distintos para a aplicação. Nr. de saídas de usuário que forneçam informações orientadas a aplicações (relatórios, telas, mensagens de erro) Nr. de consultas do usuário entrada on-line que resulte em saída on-line Nr. de arquivos cada arquivo lógico Nr. de interfaces externas todas as interfaces legíveis por máquina, usadas para transmitir informação para outro sistema.

9 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?

10 PF = total de contagem x [0,65 + 0,01 x Σ(Fi)]
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

11 Métricas Orientadas a Função
Vantagens Desvantagens

12 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.

13

14 Exemplo de utilização de PF

15 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.

16 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

17 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

18 3. Calcular pontos de casos de uso não ajustados
PCUNA = TPNAA + TPNAUC 

19 4. Calcular fator de complexidade técnica
FCT = (0.01 * Somatório dos Ti*Peso)

20 5. Calcular fatores de complexidade ambiental
FCA = (-0.03 * Somatório dos Fi*Peso)

21 6. Calcular pontos de casos de uso ajustados
PCUA = PCUNA * FCT * FCA 

22 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

23 Exemplo de utilização de PCU

24 Estimativas de software

25 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

26 Escopo Primeira atividade do planejamento
Deve ser detalhado, fechado e não ambíguo Definido em acordo com o cliente O projeto é factível?

27 Recursos

28 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

29 Técnicas de decomposição
Dimensionamento de software Dim. de "lógica nebulosa" Dim. de pontos de função Dim. de componentes padrão Dim. de modificação Estimativa de três pontos ou valor esperado S = (Sot + 4Spr + Spe) / 6

30 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

31 Estimativa baseada no problema - LOC
Produtividade média: 620 LOC/pm Custo médio: $8000/mês Custo por LOC: $13     Custo total: $       Esforço: 54 pm

32 Estimativa baseada no problema - FP

33 Estimativa baseada no problema - FP

34 Estimativa baseada no problema - FP
FPestimados = total x [ x E(Fi)] FPestimados = 375 Produtividade média: 6,5 FP/pm Custo médio: $8000/mês Custo por FP: $1230 Custo total: $ Esforço estimado: 58 pm

35 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

36 Estimativa baseada em processo
Custo médio: $8000/mês Custo total: $            Esforço estimado: 46 pm

37 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

38 Modelos empíricos Baseados em LOC Baseados em FP

39 COCOMO II Pontos por objeto Quantidade de Telas (interface) Relatórios
Componentes  Classificação em três níveis de complexidade

40 COCOMO II NOP = (pontos por objeto) x [(100 - %reúso)/100]
PROD = NOP/pessoas-mês (esforço)      Esforço estimado = NOP/PROD

41 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 = para um sistema embarcado de tempo real, P = para software de telecomunicações e P = para sistemas comerciais

42 Comprar ou fazer? Normalmente, comprar um componente pronto é mais barato que desenvolvê-lo Árvore de decisões Terceirização

43 Árvore de decisão custo estimado =
E (probabilidade do caminho)i x (custo estimado do caminho)i

44 Resumindo Estimar Utilizando o escopo
Quanto tempo, Quanto esforço e Quantas pessoas serão necessárias Utilizando o escopo Técnicas de decomposição Modelos empíricos Deve-se utilizar mais de uma estimativa para aumentar a precisão

45 Gestão de configuração de software

46 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

47 Elementos de um sistema de gestão de configuração
Elementos de componente Elementos de processo Elementos de construção Elementos humanos

48 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

49 Objetos de configuração

50 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: Especificação do sistema Requisitos do software Especificação do projeto Código fonte Planos e casos de teste Sistema operacional

51 Baseline

52 Repositório Além de ser um SGBD, deve auxiliar nas tarefas de SCM
Determinação de versão Acompanhamento de dependências e gestão de modificações  Acompanhamento de requisitos Gestão de configuração Pistas de auditoria

53 Processo de SCM Identificar Controle de versão Controle de modificação
Controle de versão Controle de modificação Auditoria de configuração Status reporting

54 Identificação de objetos
Abordagem orientada a objetos Dois tipos Objetos simples Unidades de informação Objetos agregados Coleção de objetos simples e agregados Objeto Nome Descrição Lista de recursos "Realização"

55 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")

56 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

57 Controle de modificação
Deve-se tomar cuidado com burocracia demais Camadas de controle Nível informal SCI não está no baseline Nível de projeto SCI está no baseline Nível formal Produto já foi entregue

58 Auditoria de configuração
Como garantir que as modificações foram adequadamente implementadas? Revisões técnicas formais Auditoria de configuração

59 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?

60 Status reporting Questões: O que aconteceu? Quem fez?
Quando aconteceu? O que mais será afetado? Relatório de estado de configuração (configuration status reporting, CSR) Todas as modificações no gerenciamento da configuração são relatados Pode ser colocado em um BD on-line ou site

61 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), [4] Albrecht, A. J. "Measuring Application Development Productivity". Proc. IBM Application Development Sysmposium, Monterey, CA, out. de 1979, p [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: Acesso: 03/04/2010