Post on 18-Dec-2018
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 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 carlos.vazquez@fattocs.com
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, carlos.vazquez@fattocs.com
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.