métricas de software: modelos de contratação e planejamento de projetos

Métricas de Software: modelos de contratação e planejamento de projetos

José Claudemir Pacheco Júnior MSc, AGTIC

[email protected]

Palestra ministrada na Semana de Tecnologia da Faculdade Joaquim Nabuco – Campus Olinda em 22/10/2015

http://www.google.com.br/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRxqFQoTCITmmbWs1sgCFYySkAodQLoN6g&url=http://www2.ati.pe.gov.br/web/site-ati/exibir_noticia?groupId%3D20653%26articleId%3D6409736%26templateId%3D23746&bvm=bv.105814755,d.Y2I&psig=AFQjCNH8TAjT7jOQZsHwoLjcTJr62HesnA&ust=1445612445370029

AgendaIntrodução

Métricas de Software

Modelos de Contratação de Serviços de Software

Visão Geral da Análise de Pontos de Função

APF no Planejamento de Projetos

Conclusão

IntroduçãoEngenharia de Software:

produzir sistemas de software de maneira controlada,

quantificada e previsível;Mais da metade de grandes projetos de software se deparam com algum tipo de atraso, excesso de custo

ou prazo ou mesmo fracasso total (cf. Chaos Report, Standish Group)

“Não se pode gerenciar o que não se pode

medir” (Tom De Marco)

IntroduçãoPor quê medir software?

• Entender e aperfeiçoar o processo de desenvolvimento

• Melhorar a gerência de projetos e o relacionamento com clientes

• Reduzir frustrações e pressões de cronograma

• Gerenciar contratos de software• Indicar a qualidade de um produto de

software• Avaliar a produtividade do processo

IntroduçãoPor quê medir software?

• Avaliar os benefícios (em termos de produtividade e qualidade) de novos métodos e ferramentas de engenharia de software

• Avaliar retorno de investimento• Melhorar a exatidão das estimativas• Oferecer dados qualitativos e quantitativos ao gerenciamento de desenvolvimento de software, de forma a realizar melhorias em todo o processo de desenvolvimento de software

IntroduçãoPrincipais papéis de Medições de Software, de acordo com Humphrey:

Processos, Produtos e Serviços de

Software

Entender

Avaliar Prever

Controlar

Métricas de Software

Métricas de SoftwareMedição de um atributo (propriedades ou características) de uma determinada entidade (produto, processo ou recursos) de software.

Exemplos: • Tamanho do produto de software (ex: nº de

linhas de código, nº de casos de uso)• Número de pessoas necessárias para

implementar um caso de uso• Número de defeitos encontrados por fase de

desenvolvimento• Esforço para a realização de uma tarefa• Tempo para a realização de uma tarefa• Custo para a realização de uma tarefa• Grau de satisfação do cliente (ex: adequação

do produto ao propósito, conformidade do produto com a especificação)

Métricas de SoftwareUma métrica deve ser:• Expressa em alguma unidade• Válida: quantifica o que

queremos medir• Confiável: produz os mesmos

resultados dadas as mesmas condições

• Prática: barata, fácil de calcular, entender e testar

Métricas diretas

• Medida realizada em termos de atributos observados

• Ex.: custo, esforço, nº de linhas de código, nº de casos de uso, nº de diagramas, nº de requisitos funcionais, nº de erros por fase etc.

Métricas indiretas

• Medidas obtidas a partir de outras métricas

• Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção etc.

Métricas de Software – Categorização

Métricas orientadas a

tamanho • Medidas diretas do

tamanho dos artefatos de software associados ao processo por meio do qual o software é desenvolvido.

• Ex.: esforço, custo, nº de páginas de documentação, nº de erros, nº de linhas de código

Métricas orientadas por

função• Medição de

software do ponto de vista do usuário, determinando de forma consistente o tamanho e a complexidade de um software


Métricas de produtividad

e

• Concentram-se na saída do processo de engenharia de software.

• Ex.: nº de casos de uso por iteração

Métricas de

qualidade•Oferecem uma indicação de quanto o software se adequa às exigências implícitas e explícitas do cliente.•Ex.: nº de erros por fase

Métricas técnicas

•Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido.•Ex.: complexidade lógica, reusabilidade, facilidade de manutenção


Comparar a produtividade de engenheiros de software em termos

de linha de código• Está sendo utilizado a mesma unidade

de medida?• O que é uma linha de código válida?

• O contexto considerado é o mesmo?• Mesma linguagem de programação?• Mesmo framework e bibliotecas?

• O que se quer realmente é o tamanho do código?• E a qualidade do código?

Métricas de Software – Dificuldades


Terceirização de Serviços de TI

•A década de 90 foi caracterizada no Brasil pela terceirização, inclusive em TI•Até então o desenvolvimento e manutenção de sistemas era executado por equipes internas (analistas de sistemas e programadores)•Atualmente as organizações buscam manter a sua equipe de TI com foco no seu negócio principal (analistas de negócio) e contratam fornecedores especializados para execução dos serviços

Homem-HoraPreço Fixo

Preço Unitário


Contratação por Homem-Hora

•Serviços (nem sempre projetos) executados pela alocação de profissionais terceirizados•Remuneração pela qualificação da equipe e esforço gasto•Contrato de gestão mais simples•Agilidade na resposta à mudanças de requisitos•Não demanda negociação contratual•Remuneração desvinculada dos resultados entregues•Antítese da produtividade•Custo do projeto é orientado pelos aspectos internos do trabalho (quanto de esforço e nível de especialização). Estes aspectos estão sob controle do fornecedor


Contratação por Preço Fixo

•Custo do projeto definido em função do escopo apresentado pelo cliente•Escopo precisa ser bem definido•Preço embute risco do escopo•Previsibilidade de custo (?)•E se o preço foi mal estabelecido?•E se o escopo mudar?•O “fixo” torna-se variável e leva a nova negociação, mas em que condições?•Como trabalhar num preço fixo e escopo fechado se a única certeza sobre um projeto de software é que mudanças de requisitos irão ocorrer?


Contratação por Preço Unitário

•Quando a unidade de remuneração representa uma entrega de valor para o cliente, há mais equilíbrio entre riscos e responsabilidades entre cliente e fornecedor•Produtividade e qualidade Fornecedor•Escopo Cliente•O desafio é ter uma unidade que seja:•Medida de forma consistente e uniforme•Orientada ao negócio do cliente•Auditável•Vinculada dos resultados entregues•Uma solução: adotar Pontos de Função para medir projetos de software



Surgiu na IBM no

início da década de 1970

com Allan Albrecht,

como alternativ

a às métricas baseadas em linhas de código

Fundação do

International

Function Point

User Group

(IFPUG) em

1986

Publicação em

1988 da versão 2.0 do Manual

de Práticas

de Contage

m (CPM)

Publicação em

1990 da versão 3.0 do Manual

de Práticas

de Contage

m (CPM)

A versão mais

atual do CPM

(4.3.1) foi

publicada em janeiro de 2010

Histórico

Perspectivas

•O uso da técnica de APF começou significativamente no Brasil no início da década de 90•Difusão consistente e crescente•A partir de 2008, a adoção ao uso de PFs acelerou-se no Governo Federal por causa da IN 04/2008•TCU aponta Ponto de Função (PF) como sendo a unidade mais adequada para determinar o tamanho de qualquer sistema de informação•Governos estaduais e municipais tem seguido a mesma diretriz•O mercado privado também vem usando o processo: Bradesco, OI, TAM, BM&FBOVESPA, Porto Seguro, Redecard, Cielo, ONS, Totvs•Brasil é o país com maior quantidade de usuários da APF


APF: Técnica de medição das funções (requisitos funcionais) de um software sob o ponto de vista do usuário• Usuário é qualquer pessoa ou coisa que se comunica ou

interage com o software a qualquer momento• Ponto de Função (PF) é a sua unidade de medida• Medição independente da tecnologia utilizada na

construção do software• Mede o que o software faz, e não como ele foi construídoA medição é baseada em uma avaliação

padronizada dos requisitos funcionais do usuário, definida pelo IFPUG• Pode ser feita por qualquer profissional, não restrito à área de TI• Processo de medição pode ser aprendido em dois dias de

treinamentoAPF permite não só medir o tamanho do sistema em termos da funcionalidade fornecida ao usuário, mas também estimar seu tamanho em qualquer fase do seu ciclo de vida, mesmo que os requisitos ainda não tenham sido detalhados


Medir Funções:• Solicitadas e recebidas pelo usuário do software• De projetos de desenvolvimento e melhoria de

software de forma independente de sua implementação, e de aplicações já implementadas (inventário de software)Ser um método de medição:• Consistente: pessoas diferentes medindo devem chegar ao mesmo resultado

• Simples: o esforço de medição deve onerar o mínimo o esforço total do projeto

• Clara: entendida pelo cliente e pelo fornecedor

Objetivos da APF


A análise “quebra” o sistema em funções que:

• Permitem ao usuário interagir com o sistema – Funções de Transação• E armazenar dados – Funções de Dados

Atribui um peso (pontos de função) para cada uma delas

fronteira da aplicação

entradas externas

arquivos de

interface externa

consultas externas

Fatto Sistemas__________________

Sumário Executivo de Projeto

Projeto : BR01020 Cliente : Banco Istabel Base : 31/05/1998

Custos x Faturado

......................

......................

............................................

......................

......................

......................

saídas externas

arquivos lógicos internos


consultar4 PFCE

excluir4 PF EE

arquivo10 PF ALI

incluir4 PF EE

listar5 PFSE

Cada função identificada é classificada quanto ao tipo e à complexidade


Pontos de função não medem diretamente esforço, produtividade ou custo. É exclusivamente uma medida de tamanho funcional do software. Este tamanho em conjunto com outras variáveis é que pode ser usado para derivar produtividade, estimar esforço e custo• Tecnologia: sistema operacional, linguagem de programação,

etc• Qualidade: performance, usabilidade, portabilidade, etc• Padrões: interface, segurança, auditoria, etcRequisitos não funcionais são

desconsiderados na medição de PFs• Em contratos por PF, o que a APF não mede pode afetar o

R$/PF ou ser alvo de uma métrica diferente

Manutenções que não alteram funções não são medidas em PF

Visão Geral da Análise de Pontos de FunçãoRestrições da APF

Uma ferramenta para determinar o tamanho de um pacote adquirido pela contagem de todas as funções incluídasPermite avaliar o impacto da introdução de mudanças no processo de desenvolvimento de software (novas ferramentas, métodos, etc.) Contribui para uma comunicação mais efetiva entre usuário x desenvolvedorSuporta a análise de produtividade e qualidade, seja diretamente ou em conjunto com outras métricas como esforço, defeitos e custoApoia o gerenciamento de escopo de projetos

Complementa o gerenciamento dos requisitos ao auxiliar na verificação da solidez e completeza dos requisitos especificados


Benefícios da adoção da APF

Permite remunerar o fornecedor do desenvolvimento e manutenção de software pelos resultados entregues (funções do sistema), não pelo esforço gasto (Homem-Hora)Provê auxílio aos usuários na determinação dos benefícios de um pacote para sua organização através da contagem das funções que especificamente correspondem aos seus requisitos (make or buy)Um meio para estimar custo e recursos para o desenvolvimento e manutenção de softwareUm fator de normalização para comparação de software ou para comparação da produtividade na utilização de diferentes técnicasUma ferramenta para fundamentar a negociação de contratos



Usado por milhares de organizações no Brasil e no mundo, o que aumenta a possibilidade de benchmarkingSuportado por uma organização de alcance mundial (IFPUG)Aplicável a todos os tipos de softwareAplicável a todas as fases de um projeto de software, inclusive nas fases iniciais




Quanto custa (R$) 1 PF?

Não existe uma tabela padrão de preços do PF• Concorrência• Contexto no qual o serviço será executado (requisitos técnicos, de

qualidade, padrões, grau de complexidade, quantidade de artefatos entregáveis etc)Os preços normalmente são estabelecidos

em função de:• Por exemplo: um apto de 100 m2 ficará mais caro com um

acabamento de alto luxo, mas continuará tendo 100 m2Tudo o que não é diretamente medido pelos PFs afetará o R$/PFOu seja, quanto mais alta são as exigências técnicas e de qualidade, maior tende a ser o R$/PF



Para melhor entender o que representa o volume em PFs:• Uma tela de cadastro (inclui, altera, exclui e consulta) possui em torno de 30 PFs

• Um relatório pode ter de 3 a 7 PFsOrganização Ano Volume (PF)/ano

R$/PF

ATI-PE 2011 25.300 352Caixa Econômica Federal 2010 2.000 900Conselho Nacional de Justiça 2010 40.000 383Eletrobrás 2009 12.000 542Emprel 2011 15.000 846Ministério da Educação 2010 31.200 352Ministério da Fazenda 2010 14.500 217Ministério da Justiça 2009 21.400 476Polícia Federal 2010 10.000 415Supremo Tribunal Federal 2009 11.000 398TJ-PE 2011 2.000 322Fonte: http://fattocs.com/pt/recursos/editais




Estimar tamanho do software (Fase de Concepção)

Medir tamanho do software (Fase de Elaboração)

Medir produtividade da equipe (Horas / PF)

Estimar esforço em horas (PF * Produtividade)

Estimar capacidade de produção da equipe (PF/Homem-Mês)

Quando aplicado adequadamente, o processo de medição por pontos de função

possibilita:

Estimar prazo do projeto (Tamanho + Produtividade + Nº de Colaboradores)• Estabilidade dos requisitos = PFatual / PFinicial• Baseline da organização• Tamanho do backlog = ∑ PF ProjetosEstimar custo para o projeto (PF Estimado *

Custo PF)Medir indicador de qualidade por projeto (Defeitos / PF)

Apoiar o gerenciamento de escopo do projeto

APF no Planejamento de ProjetosQuando aplicado adequadamente, o

processo de medição por pontos de função possibilita:

APF no Planejamento de ProjetosOs indicadores de projetos passados

auxiliam no planejamento de novos projetos

similares

A utilização de benchmarking também pode

servir de referência para estimar o

esforço de um novo projeto

Programming Language N Min P10 P25

Median P75 P90 Max

Mean

StDev

ABAP 5 8.0 - 13.3 13.818.

0 - 24.3 15.5 6.1ACCESS 28 0.3 0.5 1.1 2.0 - 5.5 27.0 3.3 5.1

C 27 2.8 6.4 8.5 14.919.

8 27.4 41.4 15.6 8.9

C++ 20 1.2 5.9 9.3 17.424.

4 42.3 69.3 21.2 16.9

COBOL 64 1.2 5.2 9.4 16.026.

0 42.4 69.7 20.1 15.2

JAVA 10 5.3 6.6 14.7 19.626.

7 67.8 68.2 26.8 22.8

NATURAL 21 2.3 4.8 5.7 9.613.

7 33.0 42.0 12.7 11.1

ORACLE 49 1.2 3.0 6.0 10.315.

9 28.1 78.1 13.4 12.9

VISUAL BASIC 54 0.4 2.7 3.8 7.514.

0 37.2 68.0 13.3 14.9

Fonte ISBSG: The Software Metrics Compendium – 2002

Estatísticas quanto à produtividade (H/PF) por linguagem de programação:

Conclusão

A utilização de métricas e indicadores permite padronizar a precificação e contratação de software, além de fornecer informações relevantes para o planejamento de projetos de software• Aumento na vazão das demandas (interesse do fornecedor é

maximizar as entregas e com isso seu faturamento)• Redução de custos (correção de defeitos e improdutividade é

ônus do fornecedor)• Melhoria na qualidade de requisitos dos projetos, gerando

menos retrabalho (a APF ajuda indiretamente a verificar e validar requisitos)

• Visibilidade dos resultados entregues no serviçoAPF surge como uma técnica robusta para medir software com fundamento na visão de negócio, provendo maior aproximação entre a área de TI e a área de negócio

APF apoia de maneira significativa a gestão do processo de contratação ou desenvolvimento de software

O modelo de contratação de software por PF possibilita:

Conclusão

http://quebec.huffingtonpost.ca/joanne-marcotte/laxisme-politicailleries-canada-quebec_b_6715492.html

Métricas de Software: modelos de contratação e planejamento de projetos

José Claudemir Pacheco Júnior

MSc, [email protected]