Medição e Estimativa de Software com o Método COSMIC · complexas, como sistemas especialistas, simulação, auto-aprendizado, previsão de clima, etc. ... Inicialmente, RNF RFU

FATTO Consultoria e Sistemas - www.fattoCS.com.br

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


Objetivo do Método de Medição COSMIC

2

...e o que vem a ser “tamanho funcional”?

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


Tipos de Medida

3

Medição de Tamanho Funcional (MTF) Medição Técnica

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

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)


Categoria de Requisitos do Usuário

4

Requisitos Funcionais (RFU)Requisitos específicos de uma tarefa ou serviço do usuário descrevendo o que o software deve fazer

Qualquer outro requisito ou restrição de ordem geral no sistema ou projeto, exceto aquelas que evoluem em RFU

Manipulação e Movimentação de dados:

❑ Transferência ❑ Transformação ❑ Armazenamento ❑ Recuperação

Tecnologias de desenvolvimento, manutenção, suporte e execução ❑ Ferramenta de

programação e teste, OS, DBMS, UI, etc.

à Im

plem

enta

ção

❑ Desempenho ❑ Compatibilidade ❑ Usabilidade ❑ Confiabilidade ❑ Segurança ❑ Manutenção ❑ Portabilidade

à Q

ualid

ade

à O

rgan

izaç

ãoEquipamento alvo Aderência a padrões

Locais para operação

Interoperabilidade Privacidade Proteção contra danos ❑ Intencionais ❑ Acidentais

ao

Am

bien

te

Métricas de Tamanho Funcional

Métricas Técnicas e Indicadores de Produtividade e Qualidade

Requisitos não Funcionais (RNF)


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.

❑ 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

A disponibilidade deve aumentar Y% em relação à média anual passada

❑ Habilitar troca rápida de processamento para um 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

Evolução dos RNF em RFU (ou não)

5


Extração dos Requisitos Funcionais do Usuário

6

Requisitos Funcionais do Usuário (‘RFU’) nos artefatos do software a ser

medido

artefatos com definição de requisitos

artefatos da modelagem /

análise de dados

artefatos com decomposição funcional

dos requisitos

pré-implementação

ambos os tipos de insumo demandam o mesmo trabalho?

artefatos de armazenamento físico de dados

procedimentos e manuais operacionais

do software

pós-implementação

programas físicos


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

O ISO/IEC padronizando a Medição do Tamanho Funcional

7


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

O método e a organização COSMIC

8

FATTO Consultoria e Sistemas - www.fattoCS.com.br 9

Evolução do COSMIC


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

Manuais de Referência – disponíveis em http://www.cosmicon.com (3.0.1)

10


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

Por que o Método COSMIC de Medição?

11


Estimativas e medição do desempenho com maior acuidade

12

Métricas de 1ª Geração

COSMIC

Variabilidade da produtividade Espaço entre a menor e maior produtividade

verificadas números meramente ilustrativos

% d

e de

man

das

por

faix

a de

pr

odut

ivid

ade

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

Por que tanta variabilidade?


Estimativas e medição do desempenho com maior acuidade – Causas

13

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

epoi

s

Ant

es


14

Medição apenas na perspectiva da camada de aplicação e desconsiderando a medição manutenção ou desenvolvimento em outras camadas

Gerar PDFGerar DOC

Gerar XLSListar

Listar

aplicação

Infra

aplicaçãomelhoria

Proposta de solução que não aborda tão bem a variabilidade



15

Variabilidade na extensão das funções tornam inadequado apenas três faixas de “complexidade”

Melhorias que afetam apenas poucas partes de uma funcionalidade provocam a medição da funcionalidade como um todo

(%)TD (%)AR ≤ 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

Proposta de solução usando

fatores de impacto

arbitrários

Função de Complex.

Alta com 06 PF

Função de Complex.

Alta com 06 PF


Habilidade de capturar tamanho a partir de múltiplas perspectivas

16

Adaptado do treinamento Mastering Requirements Management com Casos de Uso, IBM Sodtware Group

Aplicação de Negócio

Requisitos de Software

Especificações de Projeto (Design)

o quê

como

Infraestrutura de Suporte

o quê

como

funcional

Não funcional

funcional

Não funcional

relação entre um requisito não funcional em uma camada ser um (ou vários) requisitos funcionais em outra


Requisitos e o processo de Medição

Conjunto de:

• Modelos • Princípios • Regras • Processos

objetivos1

3

4

2

Projetado não depender de qualquer decisão de implementação embutida nos artefatos do software a ser medido

É um valor de uma quantidade de acordo com o método do COSMIC

Expresso em unidades: Pontos de Função COSMIC ou PFC

tamanho funcional do

pedaço de software

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

requisitos funcionais do usuário nos artefatos do software a ser

medido

2


O Processo de Medição na Estrutura do Método COSMIC

18

Ver

são

4.0,

CO

SM

IC M

easu

rem

ent

Man

ual

© C

OSM

IC

O Processo de Medição

Tamanho funcional do software em

unidades de PFC

Objetivos1

4

3

estratégia de medição

6

Definição de cada pedação de software

a ser medido da medição exigida

7

fase de mapeamento

9

Modelo de contexto de

software5

Modelo geral de software8

Requisitos Funcionais do

Usuário na forma do modelo geral de

software

10

fase de medição

11

Requisitos Funcionais do Usuário em artefatos do software a ser

medido2


O Modelo de Contexto de Software do COSMIC e suas aplicações

19

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

Os movimentos de dados

As fronteiras para apoiar medir os RFU, que podem estar em diferentes níveis de granularidade

Modelo de Contexto de

Software

5Estratégia de

Medição

Aplicam-se os princípios e conceitos ⑤ aos RFU do software a ser medido para responder questões como:

Qual medição é necessária?

Como interpretar esta medição?

6

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

7


Princípio (a) Software está contido em hardware

20

hardware de E/Susuários

software

hardware de E/S

equipamento de armazenamento

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

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


Software

5


(b) Software é tipicamente estruturado em camadas

21

COSM

IC M

easu

rem

ent

Man

ual,

4, it

em 2

.2.2

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

Driver de tela

Driver de impressora

Driver de disco

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

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

App 1 App 2 App nCamada Superior

Subordinada

depende de


Software

5


(c) Componentes Pares em uma mesma Camada

22

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

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

principais componentes pares

Interface com usuário /

apresentaçãoregras de negócio

serviços de dados

camadas de infraestrutura

camada de

aplicação


Software

5


(d) Uma demanda, várias camadas, diferentes escopos

23

Escopo A

Usuários

Escopo B

Escopo C

Hardware

Modificações na Camada de Aplicação

Modificações na Camada de InfraestruturaDesenvolvimento de novo Driver de Dispositivo

Adaptado do lívro COSMIC Function Pointd: Theory and Advanced Practices, 2011, Reiner Dumke and Alain Abran

Requisitos do Usuário

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


Software

5


(e) Diferentes propósitos, diferentes escopos

24

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

Escopo 1 Escopo 2 Escopo 3

Escopo Único

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


Software

5


(f) Usuários funcionais de um pedaço de software

25

usuário funcional humano

aplicação sendo medida

aplicação par

cam

ada

de a

plic

ação

usuário funcional da aplicação sendo

medida

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


Software

5


(g) Fronteira entre o pedaço de software e o usuário funcional

26

fronteira fronteiraaplicação sendo medida

aplicação par

cam

ada

de a

plic

açã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)


Software

5


(g) Armazenamento persistente e movimentos de Dados

27

aplicação sendo medida

aplicação parentradas

saídas

exits

entries exits

entries

armazenamento persistente ca

mad

a de

apl

icaç

ã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

leiturasgravaçõesmovimentos

de dados


Software

5


(h) e (i) Níveis de granularidade e o nível do processo funcional

28

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

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

definir nova turma

listar cursos ativos

listar alunos

inscritos

Inscrever aluno na

turma

listar turmas do

curso

Nível 2: processo funcional

Nível 3: passo ou regra de negócio

validar preenchimento da ficha de inscrição

calcular valor do desconto

atualizar arquivo de turmas

processo de venda de inscrições

processo abertura de turma

Nível 1: processo agregador

NÍVEIS D

E G

RA

NU

LAR

IDA

DE

O nível de granularidade no qual as medições devem ser normalmente feitas é o do processo funcional


Software

5


(j) Medidas por aproximação e escaladas para o padrão

29

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

visão delineando requisitos centrais para o sistema

O RFU de um pedaço de software de determinado escopo pode existir em diferentes níveis 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

funções previstas e ambiente do sistema

especificação completa de requisitos

fase 1 fase 2 fase 3fator de escala

fator de escala


Software

5


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

Modelo de Contexto de Software em ação – Enunciado

30


Software

5


Modelo de Contexto de Software em ação – Análise

31

usuárioGestor na Equipe de Suporte ao Produto

Gestor de Negócio no Internet Banking

Cliente do Banco

iBanking

Sistema de Internet Banking Sistemas Legados Aplicação

Infraestrutura de Suporte

fronteiras

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


Software

5

componentes pares


O Modelo de Geral de Software do COSMIC e suas aplicações

32

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

Fase de Mapeamento

9

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

Modelo Geral de Software8

ComponenteProcesso funcional Ped

ido

Componente A

Processo AProcesso BProcesso C

Itens

Produto

Cliente

Requisitos na forma do modelo geral de

software

10

E E

W W

R R


b) Os RFU de um pedaço de software a ser medido podem ser mapeados em processos funcionais únicos

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)

a) O software recebe dados de entrada de seus usuários funcionais e produz saídas e/ou outro resultado para os mesmos

Princípios de (a) a (e)

33

evento disparador

usuário funcional

entry

c) Cada processo funcional consiste de subprocessos

d) Subprocessos podem ser um movimento de dados ou manipulação de dados

processo funcional

RFUprocesso funcional

movimentos de dados

manipulação de dados

subprocessos

Modelo de Geral de Software

8


pedidoitem do pedido

clienteproduto

pedidoitem do pedido

Princípios (f) e (g)

34

usuário funcional processo

funcional


8

f) Um movimento de dados move um único grupo de dados

g) Um grupo de dados consiste de um conjunto único de atributos de dados que descreve apenas um objeto de interesse

objetos de interesse

cliente produto pedido

itens de pedido

confirmação de pedido


(h) Há 04 tipos de movimentos de dados

35

usuário funcional

processo funcional

entry

exit

read

write


8

fronteira

armazenamento persistente

manipulação

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

Os quatro tipos de movimentos de dados são distinguidos pela sua origem e destino

subprocessos de movimentação de dados


(i) Movimentos mínimos

36

usuário funcional

processo funcional

entry

exit

read

write


8

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


deve

deve* deve*

deve* - opcional se houver um outro deve* presente

manipulação

fronteira


(j) Medição indireta da manipulação

37

usuário funcional

processo funcional

entry

exit

read

write


8


manipulação

j) Os subprocessos de manipulação não são medidos em separado; são medidos indiretamente pelos subprocessos de movimentação associados

deve

deve* deve*

deve* - opcional se houver um outro deve* presente

fronteira


processos funcionais parâmetros resultados memória mensagem

somar (+)

subtrair (-)

multimplicar (x)

dividir (÷)

raiz quadrada (√)

inverter (1/x)

memória – Armazenar (MS)

memória – Limpar (MC)

memória – Recuperar (MR)

memória – Somar (M+)

memória – Limpar Resultado (C)

E

E

E

E

E

E

E

E

E

E

E

X, W, R

X, W, R

X, W, R

X, W, R

X, W, R

X, W, R

X

W

W

R

R, W

W

X

X

X

X

X

X

X

X

X

X

Modelo Geral de Software – Análise

38


8

calculadora (modo básico)

componente

grupos de dados

Matriz do Modelo Geral de Software

46 CFP


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

39

FATTO Consultoria e Sistemas - www.fattoCS.com 40

Carlos Eduardo Vazquez [email protected] cvazquezbr (skype) +55 (27) 98123-9100

Guilherme Siqueira Simõess [email protected]

guilherme.s.simoes (skype) +55 (27) 98111-7505


www.fattocs.com/blog/

@fattocs

facebook.com/fattocs

Documents

Medição e Estimativa de Software com o Método COSMIC · complexas, como sistemas especialistas, simulação, auto-aprendizado, previsão de clima, etc. ... Inicialmente, RNF RFU