Webinar COSMIC - Functional Size Measurement

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