41
FATTO CONSULTORIA E SISTEMAS Carlos Eduardo Vazquez 19/01/2015 1 Estimativas de Software com o COSMIC © 2016 FATTO Consultoria e Sistemas | www.fattocs.com 1

Estimativas de Software com o COSMICfattocs.com/files/pt/apresentacoes/estimativas-de-software-com... · e Não são Requisitos Funcionais 2. Unidade de produto na prod, de software

Embed Size (px)

Citation preview

FATTO CONSULTORIA E SISTEMAS

Carlos Eduardo Vazquez

19/01/2015

1

Estimativas de Software com

o COSMIC

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 1

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 2

Dê preferência ao uso de uma conexão de banda larga

O evento não fará uso do vídeo (webcam), somente slides e áudio

Se necessário, ajuste o idioma da sala na barra de ferramentas superior

O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas

Você pode mandar suas perguntas pelo chat ao longo da apresentação

Para aqueles que possuem certificação PMP, o evento vale 1 PDU

A apresentação será gravada e o vídeo publicado posteriormente no site e redes

sociais:

ORIENTAÇÕES INICIAIS

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 3

MISSÃO

Estimativas e Medição de Projetos de Software

Implantação da Análise de Pontos de Função (IFPUG, NESMA , COSMIC)

Auditoria de Medições de Projetos de Software Medidos com APF

Benchmarking e Análises de produtividade

Avaliação para Melhoria dos Processos de Software

Engenharia de Requisitos

Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade)

Construção e Monitoramento de Contratos de Software baseados em Resultados

Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas

Funcionais

DIRECIONAMENTO ESTRATÉGICO COM:

Apoiar nossos clientes a estabelecer modelos de negócios em que eles tenham o controle

e trazer visibilidade do desempenho para a gestão de seus processos de software.

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 4

Engenharia de Requisitos de

Software

24 horas

Estimativa de Projetos de

Software com o COCOMOII

16 horas

Oficina de Contagem

de Pontos de Função

Sessões de 8 ~ 40 horas

Gestão de Riscos em Projetos

16 horas

Oficina de Requisitos

Sessões de 8 ~ 40 horas

Introdução ao Gerenciamento de

Projetos

16 horas

Medição e Estimativa de

Software com o Método

COSMIC

16 horas (Presencial)

Preparação para

o Exame CFPS

96 horas (EAD e presencial)

APF: Fundamentos,

Benefícios e Implantação

8 horas (EAD e presencial)

Capacitação em APF:

Medição e

Estimativa de Software

16 horas (EAD e presencial)

Workshop APF:

Metodologia

e Práticas de Medição

16 horas (Presencial)

FORMAÇÃO PROFISSIONAL

O livro mais vendido de APF no país foi escrito por nós

Formou ~25% de especialistas certificados pelo IFPUG no Brasil

Representante do Scope Project Sizing Software

Preparação para

o Exame de Certificação

COSMIC Foundation Level

16 horas (EAD e presencial)

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 5

Estimativas de Software com o

COSMIC

1... 2... 3!

Objetivos

1. Despertar no público a consciência sobre a problemática na elaboração de estimativas no desenvolvimento de software

2. Apresentar o conceito de unidade de produto e de como aplicá-lo na medição de software para o planejamento e monitoramento da produtividade em seu desenvolvimento

3. Apresentar o método do COSMIC para medição do tamanho funcional e o seu papel na geração de unidades de produto a partir dos requisitos funcionais

1. A problemática da estimativa

Quando se pede uma estimativa para entrega de um programa testado e que implementa uma transação comercial para um desenvolvedor, ele fornece uma estimativa de 12 horas

O mais provável é que ele esteja correto, porque se trata de uma peça cujo nível de incerteza é muito pequeno

Ainda que erre em 100%, isso representará um erro de 12 horas; montante de impacto marginal comparado ao projeto como um todo

Estimar pequenos elementos é fácil

Programar

uma

Transação

Testar uma

transação

Estimar a realização de uma atividade de

12 horas

Pequeno!

Dificuldade Impacto

Portanto, a solução para todos os problemas de estimativa é decompor um projeto em suas partes constituintes e estimar o esforço a ser investido em cada uma delas

Com isso, os casos em que a estimativa é mais difícil e cujo erro em sua realização tem impactos negativos significativos para o negócio não serão mais um problema

Um grande elemento como a soma de suas partes memores

Estimar a entrega de um

produto final ao longo de dois

anos

Fase 01 Fase 02 Fase 03 Fase 04 Grande!

Dificuldade Impacto

1. A problemática da estimativa

Não se sabe de início quais são todos os programas

Há trabalho que não é uma função dessa quantidade de programas

O nível de informação disponível não permite usar a lógica da estimativa da baixo para cima como solução para os desafíos da estimativa

A falha nessa lógica

evolução no desenvolvimento

decisões e acordos sobre a solução

processo da engenharia de requisitos escopo

preliminar

necessidades de negócio

? Não se consegue saber quais são essas

atividades de 12 horas quando em estágios

iniciais do desenvolvimento

?

? ? ?

1. A problemática da estimativa

#NoEstimates

Poderia se esperar por esse momento para “saber” em vez de “acreditar”?

O mesmo não se pode dizer em

decisões sobre quais mudanças

devem ser priorizadas dentre os 20%

das demandas que consomem os

80% dos recursos.

1. A problemática da estimativa

Por que estimar se ao final do trabalho já se tem certeza da informação de interesse

Afinal, são apenas entre 15 ou 30 días em um ambiente onde se usam abordagens ágeis de desenvolvimento

> 2.000

HH 18% <

2.000 HH

82%

QUANTIDADE (#)

> 2.000 HH

61%

< 2.000 HH

39%

ESFORÇO(HH)

Decisões executivas de investimentos que devem ser justificadas para

quem mantém o governo daquela organização

Como fazer isso com #NoEstimates?

1. A problemática da estimativa

Conclusão de uma estimativa da área compatível com o orçamento disponível permite tomar várias decisões

Não se pode usar essa informação em um nível de detalhe de cada cômodo, é muito mais caro (proporcionalmente) construir um banheiro que um quarto

Quando chega-se ao ponto de necessitar estimar o custo especificamente com os banheiros, já se tem elementos para realizar estimativas de baixo para acima

O importante é que no total os custos não variem em muito da estimativa inicial

Casa em estilo Santa Fé de

Cadu Orçamento

disponível

1 m

1 m

Custo unitário médio de construção por m2

Uma unidade de produto na construção cívil

2. Unidade de produto na prod, de software

Casa Construída

300 m2

Produto

1 m

1 m

US$ 500,00 /

m2

Produtividade

Custo

Desembolsos com

os investimentos

US$ 150.000,00

Arquiteto Engenheiros Mestre de obras Pedreiros Ajudantes Impostos e taxas Aprovações e registros Materiais diversos…

Apropriação Indireta de custos

Apropriação direta de custos

2. Unidade de produto na prod, de software

?

?

Unidade de Producto

Qual seria a métrica que cumpre o papel de unidade de produto para o planejamento e

monitoramento do desempenho na indústria de software tal qual no exemplo

da construção civil?

Permitir aproximar ou medir o tamanho do software a partir de seus requisitos

Permitir comparar a produtividade entre as diferentes técnicas e tecnologias disponíveis

Apoiar na estimativa de esforço do projeto ou na quantificação do desempenho a partir da perspectiva do usuário ou dono para fins de análise de produtividade

Ser independente de desenvolvimento técnico e decisões de implementação

2. Unidade de produto na prod, de software

Dimensão do

projeto e qualidade

Outras métricas que permitam quantificar o

desempenho técnico de produtos e serviços a partir

de como são implementados

Análise da eficiência do projeto

Apoio à verificação e validação

Melhora no desempenho do projeto

Apoio à engenharia de requisitos

2. Unidade de produto na prod, de software

Tipos de requerimientos

Requisitos Funcionais

Requisitos que estão específicamente associados a uma tarefa ou serviço do usuario e descreve o que o software deve fazer independentemente de como o faz

Manipulação e Movimentação de dados Transferência Transformação Armazenamento Recuperação

Qualquer outro tipo de requisito ou de restrição de ordem geral para o produto

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

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

Imp

lem

enta

ção

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

Qu

alid

ade

O

rgan

izaç

ão

Equipamento alvo

Aderência a padrões

Locais para operação

Interoperabilidade

Privacidade

Proteção contra danos Intencionais Acidentais

Am

bie

nte

Não são Requisitos Funcionais

2. Unidade de produto na prod, de software

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

artefatos de armazenamento físico de dados

procedimentos e manuais operacionais do software

pós-implementação

programas físicos

Onde vivem os requisitos funcionais?

2. Unidade de produto na prod, de software

© 2016 FATTO Consultoria e

Sistemas | www.fattocs.com

Artefatos de

Software

1ª Versão dos

Requisitos

Versão Posterior dos

Requisitos

Pode ser

medido pelo

COSMIC

Deveria ser

registrado,

pode ser

quantificável

Requisitos

Funcionais do

Usuário

Requisitos não

Funcionais

‘Verdadeiros’R

FN

Requisitos

Funcionais do

Usuário

Evolução da Linha de Tempo do Projeto

A relação entre os requisitos funcionáis e não funcionáis ao longo do desenvolvimento

2. Unidade de produto na prod, de software

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’

2. Unidade de produto na prod, de software

A relação entre os requisitos funcionais e não funcionais ao longo do desenvolvimento

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)

Derivação de unidades de produto dos requisitos funcionais

2. Unidade de produto na prod, de software

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

3. Medição do tamanho funcional COSMIC

Conjunto de: Modelos Principios Regras Procesos

Visão geral do método de medição

objetivos 1

4

Idependente da implementação relacionada com os artefatos do software a ser medido

É um valor de uma magnitude de acordo com o método 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 usuarios, que são os destinatários e emissores dos dados

Exclui requisitos técnicos ou de qualidade que expressam como o software funciona

A função é relativa ao proceso de informação que o software deve executar para seus usuários

Requisitos funcionais do usuario nos artefatos de software a ser

medido 2

3

3. Medição do tamanho funcional COSMIC

As fases da medição COSMIC

Tamanho funcional do software em unidades de

PFC

Objetivos 1

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 software

5

Modelo geral de software

8

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 medido

2

3. Medição do tamanho funcional COSMIC

Usuario funcional

usuário

funciona

l humano

aplicação

sendo

medida aplicação par

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

3. Medição do tamanho funcional COSMIC

Fronteira

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)

fronteira fronteira aplicação

sendo

medida aplicação par

3. Medição do tamanho funcional COSMIC

Movimientos de dados

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

aplicação

sendo

medida aplicação par

entradas

saídas

exits

entries exits

entries

armazenamento

persistente ca

ma

da

de

ap

lica

çã

o

leituras gravações

movimentos

de dados

3. Medição do tamanho funcional COSMIC

pedido

item do pedido

cliente

produto

pedido

item do pedido

usuário

funcional processo

funcional

objetos de interesse

cliente produto pedido

itens

de

pedido

confirmação de pedido

Exemplo de Movimentos de dados

3. Medição do tamanho funcional COSMIC

editar e gerenciar

pedidos de férias

100 PFCG1

incluir, alterar,

excluir, apreciar...

150 PFCG2

1 PFCG1 = 1,5 PFCG2 ± 25%

especificação

completa 200 PFCG3

1 PFCG2 = 1,33 PFCG3 ± 15%

Estimar/Aproximar Medir

proposta requisitos

projeto construção implementação

1. Avaliar o desempenho pela relação entre a quantidade de horas investidas e a

quantdade de pontos de função COSMIC medidos

2. Reavaliar os indicadores de produtividade para que pasem a incluir o desempenho

do projeto que acaba de terminar

3. Reavaliar a quantidade de pontos de função COSMIC que correspondem à média

dos procesos ou conceitos de negócio

Medição versus Aproximação do Tamanho

3. Medição do tamanho funcional COSMIC

© 2016 FATTO Consultoria e

Sistemas | www.fattocs.com

Benchmarking

Aproximação do Tamanho 150 CFP

Esforço estimado 1000 HH

07 HH/CFP ou menos de 8% de chance

3. Medição do tamanho funcional COSMIC

© 2016 FATTO Consultoria e

Sistemas | www.fattocs.com

Conhece a si mesmo

3. Medição do tamanho funcional COSMIC

© 2016 FATTO Consultoria e

Sistemas | www.fattocs.com

Conclusão

Existe uma grande diferença entre as respostas para a

seguinte pergunta "Por que se solicitam 5.000 HH para o

projeto e não 2.000 HH?"

Há duas respostas:

- Porque eu sei

- Porque há apenas 2% de probabilidade de entregar um

projeto deste tamanho com 2.000 HH de acordo com os

dados históricos. além disso, não há um único projeto da

base de dados internacional de avaliação comparativa

que dê suporte a essa estimativa

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 32

PESQUISA!

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 33

PRÓXIMOS EVENTOS

• PRÓXIMAS TURMAS:

• PRÓXIMOS WEBNARS:

Gestão de Riscos: como lidar com as incertezas do Projeto?

terça-feira, 16 de fevereiro 2016 20:00

https://fatto.clickwebinar.com/gestao-de-riscos-como-lidar-com-as-incertezas-do-projeto/register

© 2016 FATTO Consultoria e Sistemas | www.fattocs.com 34

PERGUNTAS?

Brasília: (61) 4063-7484

São Paulo: (11) 4063-4658

Vitória: (27) 3026-6304

Rio de Janeiro: (21) 4063-5311

Belo Horizonte: (31) 4063-8475

Obrigado pela sua atenção!

Carlos Eduardo Vazquez [email protected]

Skype: cvazquezbr

FATTO Consultoria e SistemasMedicao, Estimativas e Requisitos de Software

Estimativas de Software com o COSMICCarlos Eduardo Vazquez1

ResumoRealizar uma estimativa de baixo para acima e inviavel quando nao esta disponıvel a estrutura de projeto e estimarapenas com base em uma analogia e subjetivo demais para os objetivos de negocio atuais. Alem disso, nao se podeaprender com os erros passados. O objetivo deste artigo e apresentar o metodo de medicao do tamanho funcional doCOSMIC e apresentar uma proposta para derivar unidades de produto a partir dos requisitos funcionais do usuario emdiferentes representacoes.

KeywordsCOSMIC; Software Measurement; Function Points; ISO/IEC 14.143; ISO/IEC 25.000; Software Benchmarking; ISBSG;Performance Evaluation; NoEstimates

1FATTO Consultoria e Sistemas, [email protected]

Conteudo

1 A problematica da estimativa 11.1 Estimar pequenos elementos e facil . . . . . . . . . . 1

Um grande elemento como a soma de suas partes memores• A falha nessa logica • O dilema das estimativas

1.2 #NoEstimates . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Unidade de produto para o software 22.1 A unidade de produto na construcao civil . . . . . . . 2

Productividade • Unidade de Produto

2.2 Tipos de requisitos . . . . . . . . . . . . . . . . . . . . . 3Onde vivem os requisitos funcionais? • A relacao entre osrequisitos funcionais e nao funcionais ao longo do desenvolvi-mento

2.3 A unidade de produto dos requisitos funcionais . . 4

3 O metodo de medicao do tamanho funcional doCOSMIC 4

3.1 Visao geral do metodo de medicao . . . . . . . . . . . 5Objetivo de la medicion • Requisitos funcionais • A medicao• O resultado da medicao

3.2 O processo de medicao . . . . . . . . . . . . . . . . . . 53.3 Medicao Vs Aproximacao do tamanho . . . . . . . . 53.4 Estimativas como uma probabilidade . . . . . . . . . 63.5 As estimativas e os dados de benckmarking . . . . 63.6 Conhece-te a ti mesmo . . . . . . . . . . . . . . . . . . 6

4 Conclusao 7

5 Referencias Bibliograficas 7

1. A problematica da estimativa

1.1 Estimar pequenos elementos e facil

Quando se pede uma estimativa para a entrega de um pro-grama testado e que implementa uma transacao comercialpara um desenvolvedor, ele fornece uma estimativa de 12horas. O mais provavel e que ele esteja correto, porque se

trata de uma peca cujo nıvel de incerteza e muito pequeno.Ainda que erre nessa estimativa em 100%, isso represen-tara um erro de 12 horas; montante de impacto marginalcomparado ao projeto como um todo (Figura 1).

Figura 1. Estimar a realizacao de uma atividade de 12horas.

1.1.1 Um grande elemento como a soma de suas par-tes memores

Portanto, a solucao para todos os problemas de estimativa edecompor um projeto em suas partes constituintes e estimaro esforco a ser investido em cada uma delas. Com isso,os casos em que a estimativa e mais difıcil e cujo erro emsua realizacao tem impactos negativos significativos para onegocio nao serao mais um problema (Figura 2).

1.1.2 A falha nessa logica

A falha nesta logica e que na concepcao de um produtonao se conhecem todos os programas e algumas atividadesnao tem o esforco em sua realizacao como uma funcao daquantidade de programas como, por exemplo, a Engenhariade Requisitos e o projeto de arquitetura. Os produtos dessasatividades sao os insumos para a programacao e os testesde unidade usados no exemplo apresentado. Em outras

Estimativas de Software com o COSMIC — 2/7

Figura 2. Estimar a entrega de um produto final ao longo dedois anos.

palavras, o nıvel de informacao disponıvel nao permite usara logica de estimativa de baixo para cima como solucaopara os desafios da estimativa (Figura 3).

Figura 3. Nao se podem identificar quais sao essasatividades de 12 horas durante as fases iniciais dodesenvolvimento.

1.1.3 O dilema das estimativas

Nesses casos, o dilema associado com a geracao de es-timativas se faz mais evidente. Enquanto em atividadesmenores a complexidade de estimar e baixa e a falha emsua realizacao tem impactos negativos pouco relevantes,nos projetos maiores existe uma dificuldade inerente pararealizar estimativas com a precisao necessaria.

1.2 #NoEstimates

Por que estimar se ao final do trabalho ja se tem certeza dainformacao de interesse? Afinal, sao apenas entre 15 ou 30dias em um ambiente onde se usam abordagens ageis dedesenvolvimento. Pode-se esperar por esse momento para”saber”ao inves de ”acreditar”(Figura 4).

Pode-se dizer o mesmo das decisoes sobre as iniciativasque devem ser priorizadas nos 20% das demandas queconsomem os 80% dos recursos? Estimar fornece insumoque viabiliza a gestao de mudancas organizacionais queenvolvem orquestrar o desenvolvimento de novos sistemas

Figura 4. Cauda longa: Maior concentracao em projetospequenos.

e a melhoria de varios sistemas existentes. Pode-se dizero mesmo de iniciativas que implicam em uma avaliacaopreliminar de custo-benefıcio para apoiar decisoes execu-tivas sobre investimentos que devem ser justificados paraos responsaveis pela governanca corporativa? Estimativasnesses momentos iniciais tambem facilita que as equipessejam autoadministradas e que o seu desempenho sejaplanejado e monitorado de acordo com as exigencias detransparencia e eficiencia da governanca corporativa domundo atual (Figura 5).

Figura 5. Poucos sao os projetos; mas, muito e nelesinvestido.

2. Unidade de produto para o software

2.1 A unidade de produto na construcao civil

Alguns argumentarao que o processo de software e unicoe que esta alem de qualquer medicao. Contudo, existemsimilaridades deste ultimo com a construcao civil em escalaindustrial. Cada edifıcio e unico apesar de compartilhar ele-mentos arquitetonicos comuns em maior ou menor grau. Oprocesso de entrega de um imovel inclui desde a concepcaode um projeto arquitetonico, passa por varios projetos de en-genharia, a construcao e testes observando esses projetos,ate a aceitacao final por parte do proprietario e a garantiapor um perıodo de transicao.

Quando se constroi um edifıcio, e necessario ter umorcamento disponıvel para a sua construcao e definirparametros para estabelecer os requisitos quanto ao seuprojeto arquitetonico. Uma informacao chave neste mo-mento e o valor do custo unitario medio da construcao pormetro quadrado (Figura 6).

Com essa informacao pode-se chegar a conclusao de umaestimativa da area compatıvel com o orcamento disponıvel e,

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.

Estimativas de Software com o COSMIC — 3/7

Figura 6. Custo unitario medio da construcao por m2.

a partir disso, ha a oportunidade de tomar varias decisoes.Obviamente, nao se pode usar essa informacao em umnıvel de detalhe de cada comodo individualmente. Afinal, emuito mais caro (proporcionalmente) construir um banheiroque um quarto. O banheiro possui custo maior com maode obra e materiais como a instalacao hidrosanitaria, porexemplo. Mas, como comentado antes, quando chega-seao ponto de necessitar estimar o custo especificamente comos banheiros, ja se tem elementos para realizar estimativasde baixo para acima... O importante e que no total a somadessas estimativas, ou mesmo neste ponto da evolucao daobra desembolsos ja realizados, nao ultrapassassem emmuito a estimativa inicial baseada na quantidade de metrosquadrados e na produtividade media.

2.1.1 Productividade

Neste ponto surge um importante conceito: O de produtivi-dade. Produtividade pode ser definida como a razao entre aquantidade de bens ou servicos produzidos e as unidadesde tempo ou custo investidos para a sua entrega.

No caso de minha casa e em funcao dos meus objetivoscitados, escolhi como representacao de produto a quanti-dade de metros quadrados construıdos e o investimento emdinheiro como representacao dos custos. O planejamentoda produtividade na construcao - que nem planta ainda tinha- foi realizado em termos de reais por metro quadrado.

Nessa quantidade de R$/M2 estavam incluıdas as despesassobre como pagar ao arquiteto, aos engenheiros, ao mestrede obras, aos pedreiros, aos ajudantes; quanto pagar emimpostos e taxas, aprovacoes e registros; quanto pagar pormateriais diversos. Todos esses custos passaram a seravaliados por meio de uma apropriacao indireta de custos(Figura 7).

2.1.2 Unidade de Produto

A unidade de produto que cumpre o papel de fator de custoprimario e a area construıda expressa na unidade metrosquadrados. Qual seria a metrica que cumpre o papel deunidade de produto para o planejamento e monitoramento

Figura 7. Apropriacao directa e indireta de custos.

do desempenho na industria de software tal qual no exemploda construcao civil?

Alguns requisitos podem ser identificados para tal unidadede produto:

• Permitir aproximar ou medir o tamanho do software apartir de seus requisitos;

• Apoiar na estimativa de esforco do projeto ou naquantificacao do desempenho a partir da perspectivado usuario ou dono para fins de analise de produtivi-dade;

• Ser independente de desenvolvimento tecnico e de-cisoes de implementacao;

• Permitir comparar a produtividade entre as diferentestecnicas e tecnologias disponıveis.

Observe que esse tipo de unidade nao elimina a necessi-dade de outras metricas que permitam quantificar o desem-penho tecnico de produtos e servicos a partir de como saoimplementados como, por exemplo:

• Analise da eficiencia do design;

• Aperfeicoamento do desempenho do design;

• Apoio a engenharia de requisitos;

• Apoio a verificacao e validacao.

Um exemplo de metricas como essas e parte da famıliaISO/IEC 25.000 ou Software product Quality Requirementsand Evaluation (SQuaRE).

2.2 Tipos de requisitos

Considerando as caracterısticas desejadas para essa uni-dade de produto para a producao de software, deve-se con-siderar como objeto de medicao os requisitos funcionais dousuario, porque esses sao requisitos especificamente asso-ciados a uma tarefa ou servico do usuario e que descrevemo que o software deve fazer independentemente de comoele o fara; coisa que ainda nao se sabe quando deseja-seestimar no nıvel tatico e estrategico como discutido aqui.

Sao requisitos que descrevem a manipulacao e amovimentacao de dados por meio da transferencia,transformacao, armazenamento e recuperacao de dados.

Como comentado, esses nao sao os unicos requisitos parao software. Ha os requisitos nao funcionais que abordamquaisquer outros tipos de requisito ou de restricao de ordemgeral para o produto. Sao restricoes quanto:

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.

Estimativas de Software com o COSMIC — 4/7

• Ao ambiente como a interoperabilidade, privacidadee a protecao contra danos a incidentais ou acidentais;

• Restricoes quanto a organizacao como os equipa-mentos alvo, a aderencia a padroes e locais paraoperacao;

• Restricoes quanto a implementacao como as tec-nologias de desenvolvimento, manutencao, suportee execucao como, por exemplo, a ferramenta deprogramacao e testes, sistemas operacionais, sis-temas gerenciadores de banco de dados, sistemade gerenciamento da interface grafica com o usuario,etc.

• Requisitos de qualidade ou nıvel de servico comoquestoes relacionadas ao desempenho, compatibili-dade, usabilidade, confiabilidade, seguranca, facili-dade de manutencao e portabilidade.

2.2.1 Onde vivem os requisitos funcionais?

Os requisitos funcionais do usuario encontram-se tanto emartefatos gerados antes da implementacao do softwarecomo apos a sua implementacao. No primeiro caso saoelementos como especificacoes de requisitos, modelos dedados, ou estruturas que organizam os requisitos em umaestrutura de decomposicao funcinal. No segundo, sao pro-gramas fısicos, procedimentos e manuais operacionais dosoftware e artefatos de armazenamento fısico dos dados(Figura 8).

Figura 8. Fontes de informacao sobre os requisitos.

2.2.2 A relacao entre os requisitos funcionais e naofuncionais ao longo do desenvolvimento

Os requisitos nao funcionais na perspectiva de um usuariopodem ser tratados como requisitos funcionais na perspec-tiva de outro. Muitos produtos de software que fornecemservicos compartilhados existem com o objetivo de atenderrequisitos nao funcionais de outros produtos de software;seus usuarios. Por exemplo, servicos de controle de acessofornecidos por um sistema de single sign on que fornece fun-cionalidades de autenticacao e autorizacao compartilhadospor todas as aplicacoes de negocio em uma organizacao.

Ou seja, conforme se avanca no desenvolvimento deveser possıvel medir usando uma metrica unificada aquelesrequisitos originalmente abordando requisitos nao funcio-nais que evoluıram para requisitos funcionais em uma outraperspectiva (Figura 9).

Deve-se destacar que havera sempre requisitos verdadei-ramente nao funcionais e que devem ser registrados porinfluenciar uma maior ou menor produtividade. Por exem-plo, na avaliacao de minha casa tive de considerar tratar-se

Figura 9. A evolucao dos requisitos.

de uma residencia unifamiliar e um padrao normal (nao setratava de uma casa popular, nem de uma casa de luxo).

Alguns exemplos dessa evolucao:

• O tempo de resposta medio em horarios de pico naodeve exceder 10 segundos. Este requisito nao funcio-nal evoluiu para o desenvolvimento de software como objetivo de fornecer dados externos em tempo reale para o monitoramento e reporte do tempo medio deresposta; enquanto, mantiveram-se como requisitosnao funcionais a utilizacao de um equipamento apro-priado e a sua programacao em uma linguagem debaixo nıvel.

• A disponibilidade do software deve aumentar em 5%em relacao a media anual passada. Este requisitonao funcional evoluiu para o desenvolvimento desoftware para uma troca rapida de processamentopara um processador alternativo sem interrupcao noservico; enquanto, manteve-se como um requisito naofuncional haver um processador alternativo operandoem ’hot stand by’.

Entao para fins de medicao - e estimativa - deve ser possıveladotar uma unidade de produto que permita essa flexibili-dade conforme os propositos da medicao.

2.3 A unidade de produto dos requisitos funcionais

Contar os requisitos funcionais parece ser uma boa alterna-tiva para representar as unidades de produto do software;contudo, nem todos os requisitos sao iguais e corre-se comisso o risco de misturar em uma mesma conta bananas elaranjas. Para isso a ISO/IEC definiram um padrao paraesse tipo de medicao, denominado Medicao do TamanhoFuncional, e cujo metodo mais moderno que o observa eo do Consorcio Internacional de Medicao de Software emGeral ou COSMIC.

3. O metodo de medicao do tamanhofuncional do COSMIC

O metodo de medicao do COSMIC e uma segunda geracaode metodos de medicao do tamanho funcional. Ele ofe-rece nıvel de confiabilidade compatıveis por todos os tiposde software. Esta no domınio publico e o acesso a suadocumentacao nao tem custos. O metodo tem reconheci-mento total do ISO/IEC. O seu projeto e simples e possuiuma base conceitual compatıvel com a moderna engenhariade software.

Metodos anteriores nem sempre tem a aplicabilidade amplao suficiente para atender as necessidades do mercado, ou

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.

Estimativas de Software com o COSMIC — 5/7

funcionam apenas em domınios restritos. O planejamentoe medicao do desempenho tem maior acuidade e, por fim,o metodo tem a habilidade de capturar tamanho a partir demultiplas perspectivas.

3.1 Visao geral do metodo de medicao

Figura 10. Visao geral do metodo do COSMIC.

3.1.1 Objetivo de la medicion

Toda medicao depende dos objetivos que a motivaram. Me-dir a area em de uma construcao em metros quadrados porexemplo, a medicao e feita de uma forma se o objetivo forassentar o piso e de outra forma se o objetivo e calcularquanta ferragem sera necessaria para confeccao da laje deconcreto. Por isso o primeiro insumo na medicao do tama-nho funcional usando o metodo do COSMIC e o objetivodaquela medicao.

3.1.2 Requisitos funcionais

O objeto da medicao sao os requisitos funcionais. Quandose discute funcao, entao deve-se considerar funcao paraquem. Portanto, os requisitos funcionais descrevem o queo software deve fazer para seus usuarios. Eles sao osdestinatarios e remetentes de dados para o software sendomedido.

3.1.3 A medicao

O metodo de medicao consiste em um conjunto de modelos,princıpios, regras e procedimentos que se aplicam aos doisinsumos mencionados anteriormente. Isso, com o propositode gerar o valor de uma magnitude para a funcionalidadeentregue pelo software expresso em pontos de funcao COS-MIC.

3.1.4 O resultado da medicao

O resultado da medicao e um valor de uma quantidade defuncionalidade entregue pelo software em pontos de funcaoCOSMIC.

3.2 O processo de medicao

A medicao e muito simples (Figura 11). Na fase de es-trategia de medicao, se descreve o contexto no qual o soft-ware e considerado de acordo com o objetivo da medicao.Alem disso, delimita o software a ser medido e o usuarioexterno, que nao necessariamente e uma pessoa. A faseseguinte, o mapeamento da medicao, identifica os proces-sos naquele contexto. Em cada processo, sao identificadosmovimentos de dados. Finalmente, a fase de medicao tem

por objetivo consolidar os movimentos identificados consi-derando o equivalente a um ponto de funcao COSMIC paracada movimento de dados identificado.

Figura 11. O processo de medicao COSMIC.

A medicao exige que se estabeleca uma fronteira conceitualentre o software e o usuario (Figura 12). A fronteira naodeve ser confundida com qualquer linha desenhada em umdiagrama para delimitar o escopo de uma parte do softwareou camada. A fronteira permite realizar a distincao claraentre qualquer parte do software medido (dentro) e qualquerparte do ambiente dos usuarios (fora).

Figura 12. Fronteiras.

Os usuarios interagem com o software por atraves da fron-teira por meio de movimentos de dados de entrada (E) esaıda(X). O software tambem troca dados com dispositi-vos de armazenamento por meio de movimentos de dadosde leitura (R) e gravacao (W). O dispositivo de armazena-mento nao e considerado como um usuario do software e,portanto, esta dentro da fronteira do software (Figura 13).

Figura 13. Movimentos de dados.

Cada movimento de dados contribui com o equivalente aum ponto de funcao COSMIC (Figura 14).

3.3 Medicao Vs Aproximacao do tamanho

Neste ponto, surge uma pergunta: Se o interesse e estimarquando ainda nao se conhecem os detalhes da solucao,como se podem identificar essas transferencias de dadosnos momentos iniciais? A resposta e que nao se podeestimar. Antes de estimar o esforco ou o prazo, deve-seaproximar o tamanho. Para isso, se deve reconhecer qual eo fator de escala mais apropriado (Figura 15).

Por exemplo, ha conceitos de negocio pre-existentes e so-bre os quais existe uma necessidade de manter e recuperardados apesar de que apenas se tenha informacao sobre odomınio do problema. O escopo estara definido em termos

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.

Estimativas de Software com o COSMIC — 6/7

Figura 14. Um movimento de dados, 01 PFC.

Figura 15. A diferenca entre aproximar o tamanho e fazeruma medicao.

de macro processos de negocio, areas funcionais e siste-mas impactados. Estes elementos podem ser contados e asua correlacao com o software final entregue e medido empontos de funcao COSMIC determinada.

Em momentos posteriores no ciclo de vida, quando ja existeum escopo definido em termos de quais tarefas do usuariodevem ser parcialmente ou totalmente transferidas para osoftware, e possıvel identificar processos e aplicar a mesmalogica na extrapolacao da quantidade de pontos de funcaoCOSMIC a partir da quantidade de processos identificados.

No final do projeto, a medicao se realiza com o objetivo de:

• Avaliar o desempenho mediante a relacao entre aquantidade de horas investidas e a quantidade depontos de funcao COSMIC medidos;

• Reavaliar os indicadores de produtividade para quepassem a incluir o desempenho do projeto que acabade terminar.

• Reavaliar a quantidade de pontos de funcao COS-MIC que correspondem em media a cada processoe a cada conceito de negocio conforme o nıvel deinformacao disponıvel nos diferente pontos que sedeseja estimar.

3.4 Estimativas como uma probabilidade

Existe uma confusao sobre o conceito de estimativa. Algunsconfundem este assunto com uma profecia. Quando apartir da informacao incompleta, alguem manifesta umaquantidade de horas-homem ou um prazo que nao estejaassociado a um intervalo ou a uma probabilidade, ele naoesta gerando uma estimativa, esta profetizando. Enquantoas profecias exigem um toque divino, as estimativas apenasnecessitam dados e tecnica.

3.5 As estimativas e os dados de benckmarking

Ha bases de dados de benchmarking que permitem cal-cular onde se posiciona uma estimativa em relacao ao de-sempenho dos projetos presentes naquelas bases. Porexemplo, se estimou um projeto para o desenvolvimento em

Java considerando 150 Pontos de Funcao COSMIC (CFP)e um esforco de 1.000 homens-hora (HH) para entrega.Isso equivale a uma taxa de entrega correspondente a 07HH/CFP. Isso indica que ha uma probabilidade de 8% deque o esforco nao esteja subestimado; parece-me otimistapor demais.

A figura 16 indica a distribuicao de probabilidade derivadada serie de projetos presentes na base de dados ISBSG- Grupo Internacional de Padroes de Benchmarking desoftware. Na linha horizontal, se mostram as faixas comintervalos de produtividade expressos em HH/CFP. Na linhavertical, apresentam-se as percentagens de probabilidadeassociados. A area assinalada indica a probabilidade acu-mulada de nao subestimar.

Algumas probabilidades sao destacadas por seu valor dereferencia: O ponto onde ha 50% de probabilidade de su-bestimar o superestimar (a mediana) e a faixa de 25% acimae abaixo deste nivel (o primeiro e o terceiro quartil).

Figura 16. Avaliar estimativas com dados debenchmarking

3.6 Conhece-te a ti mesmo

Alem das referencias externas promovidas por organizacoesque fornecem dados de benchmarking, existem os dadosinternos que tem ate mais valor nas estimativas da producao,ja que refletem com maior precisao as condicoes locais. Porexemplo, a linha horizontal no grafico indica a medicaoem pontos de funcao COSMIC. Cada ponto, entao, indicaa quantidade de CFP e o esforco corresponde. A partirdesses dados, e possıvel derivar uma tendencia geral quedescreva essa relacao e possa ser utilizada na producao deestimativas. No grafico sao apresentadas algumas faixas.Cada uma delas descreve a projecao de produtividade e osintervalos de 95% confianca e predicao.

Figura 17. Avaliar estimativas com dados de benchmarking

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.

Estimativas de Software com o COSMIC — 7/7

4. Conclusao

Existe uma grande diferenca entre as respostas para aseguinte pergunta ”Por que se solicitam 5.000 HH para oprojeto e nao 2.000 HH?”:

Ha duas respostas:

- Porque eu sei.

- Porque ha apenas 2% de probabilidade de entregar umprojeto deste tamanho con 2.000 HH de acordo com osdados historicos. alem disso, nao ha um unico projeto dabase de dados internacional de avaliacao comparativa quede suporte a essa estimativa.

5. Referencias Bibliograficas

ABRAN,2010

Alain Abran, Software Metrics and Software Metrology, IEEEComputer Society Publications (Wiley), 2010.

BOEHM,2000

Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chu-lani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, DonaldJ. Reifer, Bert Steece, Software Cost Estimation with CO-COMOII, Prentice Hall, 2000.

COSMIC,2015

The Common Software Measurement International Consor-tium (COSMIC), The COSMIC Functional Size MeasurementMethod, Version 4.0.1.

JONES,2007

Capers Jones, Estimating Software Costs: Bringing Realismto Estimating, Osborne (McGraw HIll), 2nd. Edition, 2007.

VAZQUEZ,2013

Carlos Vazquez, Guilherme Simoes, Renato Albert, Analisede Pontos de Funcao, Medicao, Estimativas e Gerencia-mento de Projetos de Software, Sao Paulo, Editora Erica,2013.

c© FATTO Consultoria e Sistemas - www.fattocs.comProibida a reproducao total ou parcial sem a permissao dos autores por escrito.