FATTO Virtual Live!
Webinar de Motivação "O método COSMIC de Medição do Tamanho Funcional" 29/10/2014 19:00 às 20:00
youtube.com/user/fattocs facebook.com/fattocs twitter.com/fattocs linkedin.com/company/fatto-consultoria-e-sistemas
www.fattocs.com
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
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”? FATTO Consultoria e Sistemas - www.fattoCS.com.br
2
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
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 25.000 – Software product Quality Requirements and Evaluation (SQuaRE)
3
Categoria de Requisitos do Usuário Requisitos Funcionais (RFU)
Métricas de Tamanho Funcional
Equipamento alvo
Privacidade
Aderência a padrões
Proteção contra danos ❑ Intencionais ❑ Acidentais
Locais para operação
Tecnologias de desenvolvimento, manutenção, suporte e execução ❑ Ferramenta de programação e teste, OS, DBMS, UI, etc.
❑ ❑ ❑ ❑ ❑ ❑ ❑
Desempenho Compatibilidade Usabilidade Confiabilidade Segurança Manutenção Portabilidade
à Qualidade
Transferência Transformação Armazenamento Recuperação
Interoperabilidade
à Organização
❑ ❑ ❑ ❑
ao Ambiente
Manipulação e Movimentação de dados:
Qualquer outro requisito ou restrição de ordem geral no sistema ou projeto, exceto aquelas que evoluem em RFU
à Implementação
Requisitos específicos de uma tarefa ou serviço do usuário descrevendo o que o software deve fazer
Requisitos não Funcionais (RNF)
Métricas Técnicas e Indicadores de Produtividade e Qualidade
FATTO Consultoria e Sistemas - www.fattoCS.com.br
4
Evolução dos RNF em RFU (ou não) Inicialmente, RNF
RFU a ser desenvolvido ou RNF após requisitos adquirido iniciais não evoluem em RFU
O tempo de resposta médio em horários de pico não deve exceder X segs.
❑ Fornecer dados externos em tempo real ❑ Monitorar e reportar tempo de médio de resposta
❑ Equipamento apropriado ❑ Parte do software escrito em linguagem de baixo nível
❑ Habilitar troca rápida de A disponibilidade deve aumentar Y% em relação à processamento para um média anual passada processador alternativo sem interrupção do serviço
❑ Processador alternativo operando em ‘hot stand by’
Parâmetros devem ser facilmente mantidos pela equipe do usuário
❑ Habilitar o usuário a manter as tabelas de parâmetros
❑ Nenhum
Deve ser passível de uso pelo público em geral sem treinamento a uma taxa de sucesso de Z%
❑ Recursos de ajuda ❑ Menus bem estruturados e fáceis de usar ❑ Permitir o uso por usuários com deficiências visuais
❑ Teclados em braile ❑ Teste extensivo por membros do público em geral
FATTO Consultoria e Sistemas - www.fattoCS.com.br
5
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 préimplementação
Requisitos Funcionais do Usuário (‘RFU’) nos artefatos do software a ser medido 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? FATTO Consultoria e Sistemas - www.fattoCS.com.br
6
O ISO/IEC padronizando a Medição do Tamanho Funcional ISO/IEC 14143 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)
FATTO Consultoria e Sistemas - www.fattoCS.com.br
7
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)
FATTO Consultoria e Sistemas - www.fattoCS.com.br
8
Evolução do COSMIC
FATTO Consultoria e Sistemas - www.fattoCS.com.br
9
Manuais de Referência – disponíveis em http://www.cosmicon.com (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 19761 – 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) FATTO Consultoria e Sistemas - www.fattoCS.com.br
10
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
11
% de demandas por faixa de produtividade
Estimativas e medição do desempenho com maior acuidade Há demandas com desempenho melhor que 1 HH/PF
A maior parte das demandas tem um desempenho entre 8 e 9 HH/ PF
Há demandas com desempenho pior que 16 HH/ PF
COSMIC Métricas de 1ª Geração
Variabilidade da produtividade Espaço entre a menor e maior produtividade verificadas números meramente ilustrativos
FATTO Consultoria e Sistemas - www.fattoCS.com.br
Por que tanta variabilidade?
12
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
13
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
aplicação
Depois
Listar
Antes
melhoria
aplicação
Gerar PDF Gerar DOC Gerar XLS
Infra
Proposta de solução que não aborda tão bem a variabilidade
FATTO Consultoria e Sistemas - www.fattoCS.com.br
14
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%
≤ 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
(%)AR
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
Função de Complex. Alta com 06 PF 15
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 func iona l funcional
Infraestrutura de Suporte
Não func iona l
Requisitos de Software o quê como Especificações de Projeto (Design) o quê como
Adaptado do treinamento Mastering Requirements Management com Casos de Uso, IBM Sodtware Group
FATTO Consultoria e Sistemas - www.fattoCS.com.br
16
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
2 requisitos funcionais do usuário nos artefatos do software a ser medido
1
Conjunto de: • • • •
3
Modelos Princípios Regras Processos
tamanho 4 funcional do pedaço de software
FATTO Consultoria e Sistemas - www.fattoCS.com.br
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
1
Objetivos
Modelo de 5 contexto de software
estratégia de medição 6
2
Requisitos Funcionais do Usuário em artefatos do software a ser medido
8
Modelo geral de software
Definição de cada pedação de software a ser medido da medição exigida
7
fase de mapeamento 9
Requisitos Funcionais do Usuário na forma 10 do modelo geral de software
fase de medição 3
O Processo de Medição
FATTO Consultoria e Sistemas - www.fattoCS.com.br
11
Versão 4.0, COSMIC Measurement Manual © COSMIC
O Processo de Medição na Estrutura do Método COSMIC
Tamanho funcional do 4 software em unidades de PFC
18
O Modelo de Contexto de Software do COSMIC e suas aplicações Aplicam-se os princípios e conceitos aos RFU do software a ser medido para responder questões como: 5
Modelo de Contexto de Software
Estratégia de Medição 6
7
Qual medição é necessária? Como interpretar esta medição?
Escopo de cada pedaço de software Um pedaço de software a ser a ser medido medido deve ser
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
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
19
5
Modelo de Princípio Contexto de Software
usuários
(a) Software está contido em hardware
hardware de E/S
hardware de E/S
software
Software tipicamente é restrito por equipamentos de entrada e saída: 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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
20
Modelo de (b) Contexto de Software Camada Superior depende de Subordinada
Software é tipicamente estruturado em camadas
App 1
Camada de Aplicação
Camada de Middleware Camada de SGBD
App 2
Serviços Utilitários
SGBD 1
App n Etc.
SGBD 2
Camada do Sistema Operacional
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
Driver de teclado
Driver de tela
Driver de impressora
Driver de disco
COSMIC Measurement Manual, 4, item 2.2.2
5
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
21
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
Interface com usuário / apresentação
regras de negócio
serviços de dados
camada de aplicação
principais componentes pares
camadas de infraestrutura
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
22
5
Modelo de Contexto de Software
(d) Uma demanda, várias camadas, diferentes escopos
Requisitos do Usuário
Adaptado do lívro COSMIC Function Pointd: Theory and Advanced Practices, 2011, Reiner Dumke and Alain Abran
Modificações na Camada de Aplicação Modificações na Camada de Infraestrutura Desenvolvimento de novo Driver de Dispositivo
Usuários
Escopo A Escopo B Escopo C 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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
23
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
24
Modelo de Contexto de Software
(f) Usuários funcionais de um pedaço de software aplicação sendo medida
usuário funcional humano
aplicação par usuário funcional da aplicação sendo medida
camada de aplicação
5
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
25
Modelo de Contexto de Software
(g) Fronteira entre o pedaço de software e o usuário funcional fronteira
fronteira aplicação sendo medida
aplicação par
camada de aplicação
5
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) FATTO Consultoria e Sistemas - www.fattoCS.com.br
26
Modelo de (g) Armazenamento Contexto de Dados Software
entradas saídas
aplicação sendo medida
gravações
persistente e movimentos de
exits entries
entries
aplicação par
exits
leituras
armazenamento persistente
movimentos de dados
camada de aplicação
5
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
27
5
Modelo de (h) e (i) Níveis de granularidade Contexto de processo funcional Software
listar cursos ativos
definir nova turma
validar preenchimento da ficha de inscrição
Nível 1: processo agregador
processo abertura de turma listar turmas do curso calcular valor do desconto
listar alunos inscritos
Inscrever aluno na turma
Nível 2: processo funcional
atualizar arquivo de turmas
Nível 3: passo ou regra de negócio
NÍVEIS DE GRANULARIDADE
processo de venda de inscrições
e o nível do
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
28
5
Modelo de Contexto de Software
(j) Medidas por aproximação e escaladas para o padrão
fase 1 visão delineando requisitos centrais para o sistema
fase 2 funções previstas e ambiente do sistema
fase 3 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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
29
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
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 camadas
iBanking
Infraestrutura de Suporte
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
31
10
8
Componente Componente A
Processo funcional Processo A Processo B Processo C
Modelo Geral de Software
Suporta a identificação dos componentes de funcionalidade que serão medidos Busca estabelecer um entendimento comum sobre o que é software para fins de medição
9
Pe di d It o en s Pr od ut Cl o ie nt e
O Modelo de Geral de Software do COSMIC e suas aplicações
E
E
W
W R
Fase de Mapeamento
R
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
32
Modelo de Geral 8 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 entry evento disparador
usuário funcional
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)
processo funcional
processo funcional
subprocessos movimentos de dados
b) Os RFU de um pedaço de software a ser medido podem ser mapeados em processos funcionais únicos
FATTO Consultoria e Sistemas - www.fattoCS.com.br
RFU
manipulação de dados
c) Cada processo funcional consiste de subprocessos d) Subprocessos podem ser um movimento de dados ou manipulação de dados 33
Modelo de Geral 8 de Software
Princípios (f) e (g)
f) Um movimento de dados move um único grupo de dados objetos de interesse usuário funcional
processo funcional
itens de pedido
cliente produto pedido
pedido item do pedido cliente produto pedido item do pedido confirmação de pedido
g) Um grupo de dados consiste de um conjunto único de atributos de dados que descreve apenas um objeto de interesse FATTO Consultoria e Sistemas - www.fattoCS.com.br
34
Modelo de Geral 8 de Software
(h) Há 04 tipos de movimentos de dados fronteira
usuário funcional
processo funcional
read
entry manipulação
write
armazenamento persistente
Os quatro tipos de movimentos de dados são distinguidos pela sua origem e destino
subprocessos de movimentação de dados
exit
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 FATTO Consultoria e Sistemas - www.fattoCS.com.br
35
Modelo de Geral 8 de Software
usuário funcional
(i) Movimentos mínimos
deve
fronteira
processo funcional
read
entry manipulação
deve*
exit
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
36
Modelo de Geral 8 de Software
usuário funcional
(j) Medição indireta da manipulação
deve
fronteira
processo funcional
read
entry manipulação
deve*
exit
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
37
Modelo de Geral 8 de Software
Modelo Geral de Software – Análise
componente
Matriz do Modelo Geral de Software
calculadora (modo básico) processos funcionais
grupos de dados parâmetros
resultados
memória
mensagem
somar (+)
E
X, W, R
X
subtrair (-)
E
X, W, R
X
multimplicar (x)
E
X, W, R
X
dividir (÷)
E
X, W, R
raiz quadrada (√)
E
X, W, R
X
inverter (1/x)
E
X, W, R
X
memória – Armazenar (MS)
E
W
X
memória – Limpar (MC)
E
W
X
memória – Recuperar (MR)
E
memória – Somar (M+)
E
R, W
X
memória – Limpar Resultado (C)
E
W
X
FATTO Consultoria e Sistemas - www.fattoCS.com.br
X
46 CFP
X
R
38
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
FATTO Consultoria e Sistemas - www.fattoCS.com.br
39
Guilherme Siqueira Sim천ess guilherme.simoes@fattocs.com guilherme.s.simoes (skype) +55 (27) 98111-7505 Carlos Eduardo Vazquez carlos.vazquez@fattocs.com cvazquezbr (skype) +55 (27) 98123-9100
FATTO Consultoria e Sistemas - www.fattoCS.com
40
www.fattocs.com/blog/
facebook.com/fattocs
@fattocs FATTO Consultoria e Sistemas - www.fattoCS.com.br
41