Medição e Estimativa de Software com o Método COSMIC

Transcrição

1 Medição e Estimativa de Software com o Método COSMIC Atualizado para a versão 4.0 do Manual de Medição O guia de implementação do COSMIC para a ISO/IEC 19761

2 Objetivo do Método de Medição COSMIC Definir uma medida padrão do tamanho funcional do software Aplicabilidade - Software em aplicações comerciais - Software de tempo real - Híbridos Possível definir extensões locais para - Funcionalidade relacionada a processamento matemático intensivo Funcionalidade em algoritmos complexos ou outras regras especializadas e complexas, como sistemas especialistas, simulação, auto-aprendizado, previsão de clima, etc. Processamento de variáveis contínuas como sons em áudio ou imagens em vídeo como em jogos, instrumentos musicais, etc. Não considera aspectos da funcionalidade como complexidade que possa ser considerada como contribuindo ao 'tamanho' do software...e o que vem a ser tamanho funcional? 2

3 Tipos de Medida Medição de Tamanho Funcional (MTF) Aproxima ou mede cedo o tamanho do software a partir dos requisitos Apoia a estimativa do esforço do projeto ou quantificação do desempenho de produtos e serviços a partir da perspectiva do usuário ou dono para análise de produtividade Deve ser independente de desenvolvimento técnico e decisões de implementação Permite comparar a produtividade entre as diferentes técnicas e tecnologias disponíveis Medição Técnica Quantifica o desempenho técnico de produtos e serviços a partir de como são implementados Análise da eficiência do design Melhor desempenho do design Apoio à engenharia de requisitos Apoio à verificação e validação Exemplo: as métricas na família ISO/IEC Software product Quality Requirements and Evaluation (SQuaRE) 3

4 Categoria de Requisitos do Usuário Requisitos Funcionais (RFU) Requisitos específicos de uma tarefa ou serviço do usuário descrevendo o que o software deve fazer Manipulação e Movimentação de dados: Transferência Transformação Armazenamento Recuperação Qualquer outro requisito ou restrição de ordem geral no sistema ou projeto, exceto aquelas que evoluem em RFU ao Ambiente à Implementação Requisitos não Funcionais (RNF) Interoperabilidade Privacidade Proteção contra danos Intencionais Acidentais Tecnologias de desenvolvimento, manutenção, suporte e execução Ferramenta de programação e teste, OS, DBMS, UI, etc. Equipamento alvo Aderência a padrões Locais para operação Desempenho Compatibilidade Usabilidade Confiabilidade Segurança Manutenção Portabilidade à Organização à Qualidade Métricas de Tamanho Funcional Métricas Técnicas e Indicadores de Produtividade e Qualidade 4

5 Evolução dos RNF em RFU (ou não) Inicialmente, RNF RFU a ser desenvolvido ou adquirido RNF após requisitos iniciais evoluírem em RFU O tempo de resposta médio em horários de pico não deve exceder X segs. A disponibilidade deve aumentar Y% em relação à média anual passada Parâmetros devem ser facilmente mantidos pela equipe do usuário Deve ser passível de uso pelo público em geral sem treinamento a uma taxa de sucesso de Z% Fornecer dados externos em tempo real Monitorar e reportar tempo de médio de resposta Habilitar troca rápida de processamento para um processador alternativo sem interrupção do serviço Habilitar o usuário a manter as tabelas de parâmetros Recursos de ajuda Menus bem estruturados e fáceis de usar Permitir o uso por usuários com deficiências visuais Equipamento apropriado Parte do software escrito em linguagem de baixo nível Processador alternativo operando em hot stand by Nenhum Teclados em braile Teste extensivo por membros do público em geral 5

6 Extração dos Requisitos Funcionais do Usuário artefatos com definição de requisitos artefatos com decomposição funcional dos requisitos artefatos da modelagem / análise de dados Requisitos Funcionais do Usuário ( RFU ) nos artefatos do software a ser medido préimplementação pósimplementação programas físicos procedimentos e manuais operacionais do software artefatos de armazenamento físico de dados ambos os tipos de insumo demandam o mesmo trabalho? 6

7 O ISO/IEC padronizando a Medição do Tamanho Funcional ISO/IEC define os princípios da medição do tamanho funcional Implementados em métodos de medição do tamanho funcional por COSMIC (ISO/IEC 19761:2011) IFPUG APF (ISO/IEC 20926:2009) UKSMA Mk II (ISO/IEC 20968:2002) NESMA APF (ISO/IEC 24570:2005) FiSMA (ISO/IEC 29881:2010) 7

8 O método e a organização COSMIC The COmmon Software Measurement International Consortium Iniciativa voluntária de um grupo internacional de especialistas Objetivo inicial de desenvolver, testar, trazer ao mercado e buscar aceitação de uma nova geração de FSM Define uma medida padrão do tamanho funcional do software - Ponto de Função COSMIC (PFC) Método COSMIC de Medição do Tamanho Funcional mantido pelo Comitê de Práticas de Medição do COSMIC (MPC) 8

9 Evolução do COSMIC 9

10 Manuais de Referência disponíveis em (3.0.1) Visão Geral da Documentação e Glossário de Termos Princípios e Regras para o Método Visão Geral do Método Manual de Medição - O Guia de implementação do COSMIC para a ISO/IEC Tópicos Avançados e Relacionados Documentos de Suporte Específicos de Domínios Orientações para Aplicações Comerciais Orientações para Software de Tempo Real Orientações para Projetos Ágeis Orientações para DW Orientações para SOA Estudos de Casos de Aplicações Comerciais Estudos de Casos de Software de Tempo Real Boletins de Atualização do Método (11) 10

11 Por que o Método COSMIC de Medição? Nível de confiabilidade compatíveis por todos os tipos de software Está no domínio público e sem custos Tem reconhecimento total do ISO/IEC Projeto é simples Base conceitual compatíveis com a moderna engenharia de software Métodos de 1ª geração nem sempre tem força suficiente para atender as necessidades do mercado, ou funcionam apenas em domínios muito restritos Estimativas e medição do desempenho com maior acuidade Habilidade de capturar tamanho a partir de múltiplas perspectivas 11

12 Estimativas e medição do desempenho com maior acuidade % de demandas por faixa de produtividade Há demandas com desempenho melhor que 1 HH/PF COSMIC A maior parte das demandas tem um desempenho entre 8 e 9 HH/ PF Métricas de 1ª Geração Há demandas com desempenho pior que 16 HH/ PF Variabilidade da produtividade Espaço entre a menor e maior produtividade verificadas números meramente ilustrativos Por que tanta variabilidade? 12

13 Estimativas e medição do desempenho com maior acuidade Causas Manutenção em software compartilhado que implementa regras de negócio usadas em várias funcionalidades Validar CPF Solução não Padrão ISO 13

14 Estimativas e medição do desempenho com maior acuidade Causas Medição apenas na perspectiva da camada de aplicação e desconsiderando a medição manutenção ou desenvolvimento em outras camadas Listar Antes melhoria aplicação aplicação Listar Depois Gerar PDF Gerar DOC Gerar XLS Infra Proposta de solução que não aborda tão bem a variabilidade 14

15 Estimativas e medição do desempenho com maior acuidade Causas Melhorias que afetam apenas poucas partes de uma funcionalidade provocam a medição da funcionalidade como um todo (%)TD 2/3 (x 100%) 100% >100% (%)AR 1/3 (x 100%) 0,25 0,50 0,75 2/3 (x 100%) 0,50 0,75 1,00 100% 0,75 1,00 1,25 >100% 1,00 1,25 1,50 Proposta de solução usando fatores de impacto arbitrários Variabilidade na extensão das funções tornam inadequado apenas três faixas de complexidade Função de Complex. Alta com 06 PF Função de Complex. Alta com 06 PF 15

16 Habilidade de capturar tamanho a partir de múltiplas perspectivas relação entre um requisito não funcional em uma camada ser um (ou vários) requisitos funcionais em outra Aplicação de Negócio funcional Não funcional funcional o quê como o quê Requisitos de Software Especificações de Projeto (Design) Infraestrutura de Suporte Não funcional como Adaptado do treinamento Mastering Requirements Management com Casos de Uso, IBM Sodtware Group 16

17 Requisitos e o processo de Medição objetivos É um valor de 2 uma quantidade de acordo com o método do COSMIC Projetado não depender de qualquer decisão de implementação embutida nos artefatos do software a ser medido Expresso em unidades: Pontos de Função COSMIC ou PFC 1 Conjunto de: Modelos Princípios Regras Processos tamanho funcional do pedaço de software requisitos funcionais do usuário 2 nos artefatos do software a ser medido 3 4 Descreve o que o software deve fazer para os usuários funcionais que são os destinatários e remetentes dos dados de e para ele Exclui requisitos técnico ou de qualidade que diga como o software deva executar A função é relativa ao processamento de informação que o software deve executar para seus usuários 17

18 O Processo de Medição na Estrutura do Método COSMIC Objetivos Modelo de contexto de software estratégia de medição Requisitos Funcionais do Usuário em artefatos do software a ser medido 6 Modelo geral de software Definição de cada pedação de software a ser medido da medição exigida fase de mapeamento 9 O Processo de Medição 7 Requisitos Funcionais do Usuário na forma do modelo geral de software fase de medição Versão 4.0, COSMIC Measurement Manual COSMIC Tamanho funcional do software em unidades de PFC 4 18

19 O Modelo de Contexto de Software do COSMIC e suas aplicações Aplicam-se os princípios e conceitos 5 aos RFU do software a ser medido para responder questões como: Qual medição é necessária? Como interpretar esta medição? 5 Modelo de Contexto de Software Estratégia de Medição 6 Introduz os princípios e conceitos necessários à definição do escopo da medição As camadas de software e componentes pares O escopo de um pedaço de software a ser medido Os usuários funcionais do pedaço de software 7 Escopo de cada pedaço de software a ser medido Um pedaço de software a ser medido deve ser cuidadosamente definido no escopo da medição A definição deve considerar o contexto com o qual o pedaço de software interage em termos de software e/ou equipamentos Os movimentos de dados As fronteiras para apoiar medir os RFU, que podem estar em diferentes níveis de granularidade 19

20 5 Modelo de Contexto de Software Princípio (a) Software está contido em hardware usuários hardware de E/S hardware de E/S Software tipicamente é restrito por equipamentos de entrada e saída: software mouse, um teclado, uma impressora ou um monitor quando usado por pessoas dispositivos como sensores ou relés em software de tempo real embarcado equipamento de armazenamento Software também é vinculado a equipamento de armazenamento persistente como discos rígidos ou outros tipos de memória que podem ser usados para reter dados Ainda que a medição do tamanho funcional seja feita com base em uma visão lógica que abstrai dessa visão física (hardware e software), é útil expor essa última porque o responsável pela medição deve distinguir uma da outra 20

21 5 Modelo de Contexto de Software (b) Software é tipicamente estruturado em camadas Camada Superior depende de Subordinada Se um pedaço de software a ser medido é parte de uma arquitetura em camadas resultante de um projeto, deveria ser fácil decidir que camada o compreende Camada de Aplicação Camada de Middleware Serviços Utilitários Etc. Camada de SGBD SGBD 1 SGBD 2 Camada do Sistema Operacional Driver de teclado App 1 App 2 App n Driver de tela Driver de impressora Driver de disco Se o ambiente de software cresceu e evoluiu ao longo do tempo, as camadas (se houver) podem não ser claramente distintas. Para esses circunstâncias, o método do COSMIC inclui algumas regras para distinguí-las COSMIC Measurement Manual, 4, item

22 5 Modelo de Contexto de Software (c) Componentes Pares em uma mesma Camada O método fornece regras para dimensionar os principais componentes pares isoladamente. Importante para os propósitos de medição de performance e estimativas quando executam em plataformas técnicas diferentes principais componentes pares Interface com usuário / apresentação camadas de infraestrutura regras de negócio serviços de dados camada de aplicação Qualquer pedaço de software em qualquer camada pode ser decomposto em seus componentes em vários níveis (ex., descer a módulos individuais ou objetos de classes) e o método pode ser utilizado para medir o respectivo tamanho em qualquer nível Abaixo do nível de componentes pares principais em qualquer camada, deve-se definir padrões locais de níveis de decomposição (com o arquiteto), para manter a compatibilidade entre medições provenientes de diferentes fontes 22

23 5 Modelo de Contexto de Software (d) Uma demanda, várias camadas, diferentes escopos Requisitos do Usuário Modificações na Camada de Aplicação Modificações na Camada de Infraestrutura Desenvolvimento de novo Driver de Dispositivo Adaptado do lívro COSMIC Function Pointd: Theory and Advanced Practices, 2011, Reiner Dumke and Alain Abran Escopo A Escopo C Escopo B Usuários Hardware O escopo de qualquer pedaço de software medido deve estar inteiramente contido em uma única camada Cada camada tem uma função especializada e pode ser desenvolvida com tecnologia diferente daquela utilizada nas outras camadas Pode ou não fazer sentido medir o tamanho de alguns pedaços de software residentes em duas ou mais camadas e, depois, somar tais tamanhos como se o resultado representasse o tamanho de uma simples entidade A medida de tamanho resultante poderia, assim como a soma dos tamanhos de maçãs e laranjas, ser muito difícil de interpretar e/ou comparar com outras medidas de tamanho funcional 23

24 5 Modelo de Contexto de Software (e) Diferentes propósitos, diferentes escopos Aplicação é um pedaço distinto de software, desenvolvido por uma equipe de projeto específica: para a maioria dos propósitos, faz sentido definir o escopo da medição como a aplicação como um todo Aplicação desenvolvida como três componentes pares principais cada um com tecnologias diferentes ou desenvolvidos por diferentes equipes: para o propósito de estimar o esforço fará sentido definir três escopos de medição separados Escopo Único Escopo 1 Escopo 2 Escopo 3 O tamanho medido de cada um dos três componentes servirá como entrada para uma fórmula de estimativa capaz de explicar diferentes tecnologias e/ou características das equipes de projeto de cada componente 24

25 5 Modelo de Contexto de Software (f) Usuários funcionais de um pedaço de software usuário funcional humano aplicação sendo medida aplicação par usuário funcional da aplicação sendo medida camada de aplicação Usuários funcionais de um pedaço de software a ser medido identificados a partir de seus RFU, como fontes e/ou destinos pretendidos para dados Na visão lógica para um pedaço de software de aplicações de negócio, os RFU costumam descrever só a funcionalidade requerida do ponto de vista de usuários humanos e, talvez, outras aplicações pares que enviem ou recebam dados Quaisquer camadas de software e dispositivos de hardware que suportem a interação dos usuários funcionais com a aplicação são facilitadores da trocas de dados e não remetentes ou destinatários 25

26 5 Modelo de Contexto de Software (g) Fronteira entre o pedaço de software e o usuário funcional fronteira aplicação sendo medida aplicação par fronteira camada de aplicação Fronteira definida como interface conceitual entre software e usuário funcional Fronteira não deve ser confundida com qualquer linha desenhada em um diagrama para delimitar o escopo de um pedaço de software ou camada Fronteira permite fazer distinção clara entre qualquer coisa parte do pedaço de software medido (dentro) e qualquer coisa parte do ambiente dos usuários funcionais (fora) 26

27 5 Modelo de Contexto de Software (g) Armazenamento persistente e movimentos de Dados entradas saídas gravações armazenamento persistente aplicação sendo medida leituras exits entries entries exits aplicação par movimentos de dados camada de aplicação Usuários funcionais interagem com o software através da fronteira via dois tipos de movimentos de dados (entries e exits) software também troca dados com o dispositivo de armazenamento persistente via dois tipos de movimentos de dados (reads e writes) O dispositivo de armazenamento não é considerado como um usuário do software e portanto está dentro da fronteira do software 27

28 5 Modelo de Contexto de Software (h) e (i) Níveis de granularidade e o nível do processo funcional processo de venda de inscrições listar cursos ativos definir nova turma validar preenchimento da ficha de inscrição processo abertura de turma listar turmas do curso calcular valor do desconto listar alunos inscritos Inscrever aluno na turma atualizar arquivo de turmas Nível 1: processo agregador Nível 2: processo funcional Nível 3: passo ou regra de negócio NÍVEIS DE GRANULARIDADE O RFU de software pode ser expresso em diferentes níveis de granularidade: nível de detalhe da descrição de um pedaço de software O nível de granularidade no qual as medições devem ser normalmente feitas é o do processo funcional Declarações de requisitos de alto nível compõem os RFU quando do início do desenvolvimento e são refinados e elaborados em mais detalhe a partir dai 28

29 5 Modelo de Contexto de Software (j) Medidas por aproximação e escaladas para o padrão fase 1 fase 2 fase 3 visão delineando requisitos centrais para o sistema funções previstas e ambiente do sistema especificação completa de requisitos fator de escala fator de escala O RFU de um pedaço de software de determinado escopo pode existir em diferentes níveis de granularidade Comparar a medição (ou aproximação) cuidadosamente a partir de diferentes fontes ou para usar os resultados em algum outro processo, todas as medições devem ser feitas ou escaladas para um nível padrão de granularidade Devem-se calcular fatores de escala locais para converter tamanhos em diferentes níveis de granularidade para a unidade padrão no nível de granularidade do processo funcional 29

30 5 Modelo de Contexto de Software Modelo de Contexto de Software em ação Enunciado Objetivos - Estimar o esforço do atendimento da demanda para: 1) A equipe de automação bancária deve desenvolver o novo Internet Banking responsável por capturar, criticar, manter e fornecer reporte sobre transações financeiras, atuando também como um front-end de sistemas core legados de retaguarda, realizando a preparação e a passagem de movimentos com transações para processamento pelos mesmos 2) Deve permitir dois modos de operação: um voltado ao cliente e outro voltado aos administradores (da equipe de gestão do Internet banking) que será responsável pela definição e manutenção dos parâmetros operacionais do negócio. A equipe de suporte ao produto poderá manter constantes usadas no processamento para diminuir a necessidade de manutenção 3) Usa a plataforma ibanking, sob a responsabilidade da equipe de suporte ao desenvolvimento, que fornece uma infraestrutura serviços compartilhados como acesso a arquivos, controle de acesso, autorização, entre outros 4) Deve ser dado manutenção no ibanking para que sejam incluídas transações de geração de chaves privadas e públicas, criptografar e/ou assinar mensagens, descriptografar e/ou verificar assinaturas em mensagens 30

31 5 Modelo de Contexto de Software Modelo de Contexto de Software em ação Análise Gestor de Negócio no Internet Banking Gestor na Equipe de Suporte ao Produto usuário Cliente do Banco componentes pares Sistema de Internet Banking fronteiras Sistemas Legados Aplicação ibanking Infraestrutura de Suporte camadas escopo (considerando os RFU de todos os usuários) Todas as funcionalidades no Sistema de Internet Banking Funcionalidades incluídas e alteradas nos Sistemas Legados Funcionalidades incluídas e alteradas no ibanking 31

32 O Modelo de Geral de Software do COSMIC e suas aplicações 10 Componente Componente A Processo funcional Processo A Processo B Processo C Pedido E E W W Itens Produto R R Cliente 8 Suporta a identificação dos componentes de funcionalidade que serão medidos Modelo Geral de Software Busca estabelecer um entendimento comum sobre o que é software para fins de medição 9 Fase de Mapeamento Requisitos na forma do modelo geral de software Identifica os eventos no mundo dos usuários funcionais aos quais o software deve responder e dai identifica os processos funcionais Identifica movimentos de dados (Entries, Exits, Reads e Writes) de cada processo funcional que, por sua vez, depende da identificação de grupos de dados que são movimentados 32

33 Modelo 8 de Geral de Software Princípios de (a) a (e) a) O software recebe dados de entrada de seus usuários funcionais e produz saídas e/ou outro resultado para os mesmos processo funcional RFU evento disparador usuário funcional entry processo funcional subprocessos movimentos de dados manipulação de dados e) Cada processo funcional é disparado por um movimento de dados Entry a partir do usuário funcional que informa ao processo funcional que o usuário funcional identificou um evento (disparador) b) Os RFU de um pedaço de software a ser medido podem ser mapeados em processos funcionais únicos c) Cada processo funcional consiste de subprocessos d) Subprocessos podem ser um movimento de dados ou manipulação de dados 33

34 Modelo 8 de Geral de Software Princípios (f) e (g) f) Um movimento de dados move um único grupo de dados usuário funcional processo funcional objetos de interesse cliente produto pedido itens de pedido pedido item do pedido confirmação de pedido pedido cliente item do pedido produto g) Um grupo de dados consiste de um conjunto único de atributos de dados que descreve apenas um objeto de interesse 34

35 Modelo 8 de Geral de Software (h) Há 04 tipos de movimentos de dados usuário funcional fronteira entry exit processo funcional manipulação read write armazenamento persistente Os quatro tipos de movimentos de dados são distinguidos pela sua origem e destino subprocessos de movimentação de dados Entry e Exit: Movimentos de dados que atravessam a fronteira entre o usuário funcional e o software sendo medido Read e Write: Movimento de dados entre software e armazenamento persistente 35

36 Modelo 8 de Geral de Software (i) Movimentos mínimos usuário funcional fronteira deve deve* entry exit processo funcional manipulação read write deve* armazenamento persistente deve* - opcional se houver um outro deve* presente i) Um processo funcional deve incluir no mínimo um movimento de dados entry e um movimento de dados exit ou write; ou seja, um mínimo de dois movimentos de dados 36

37 Modelo 8 de Geral de Software (j) Medição indireta da manipulação usuário funcional fronteira deve deve* entry exit processo funcional manipulação read write deve* armazenamento persistente deve* - opcional se houver um outro deve* presente j) Os subprocessos de manipulação não são medidos em separado; são medidos indiretamente pelos subprocessos de movimentação associados 37

38 Modelo 8 de Geral de Software Modelo Geral de Software Análise componente Matriz do Modelo Geral de Software calculadora (modo básico) grupos de dados processos funcionais parâmetros resultados memória mensagem somar (+) subtrair (-) E E X, W, R X, W, R X X multimplicar (x) E X, W, R X 46 CFP dividir ( ) E X, W, R X raiz quadrada ( ) inverter (1/x) E E X, W, R X, W, R X X memória Armazenar (MS) memória Limpar (MC) E E W W X X memória Recuperar (MR) E X R memória Somar (M+) memória Limpar Resultado (C) E E R, W W X X 38

39 39 Encerramento O método do COSMIC está para o método do IFPUG, assim como o método do IFPUG está para a contagem estimativa da NESMA Aborda - intrinsecamente - o requisito ser funcional ou não funcional conforme os usuários, permitindo de maneira unificada medir software de forma mais abrangente que a APF no IFPUG Ainda que seja mais trabalhoso medir comparado ao método do IFPUG, pode facilmente ser usado em estimativas mais robustas que usando a complexidade e contribuição

40 Guilherme Siqueira Simõess guilherme.s.simoes (skype) +55 (27) Carlos Eduardo Vazquez cvazquezbr (skype) +55 (27) FATTO Consultoria e Sistemas

41 41