métricas de software

MÉTRICAS DE SOFTWARE 1

Apresentação

.............................................................................................................................Erro!

Indicador não definido.

Aula 1: Fundamentos de métricas e medidas ............................................................................

Erro! Indicador não definido.

................................................................................Erro! Indicador não definido. Introdução

................................................................................................................................ 7 Conteúdo

Métricas para Software ..................................................................................................... 7

Por que devemos medir? ................................................................................................. 9

Quais são as etapas envolvidas? ..................................................................................... 9

Como garantir que o trabalho seja realizado corretamente? ................................... 9

Avaliação dos atributos internos do produto ............................................................. 10

Qualidade de Software ................................................................................................... 10

Custo do reparo ............................................................................................................... 11

Curva de falhas para hardware ou curva da banheira ............................................. 11

Garantia de qualidade ..................................................................................................... 12

Fatores determinantes para a garantia da qualidade ............................................... 12

Fatores de qualidade de McCall .................................................................................... 13

Características operacionais .......................................................................................... 13

Características de manutenção .................................................................................... 14

Características de adaptação a novos ambientes ..................................................... 14

Fatores de Qualidade ISO 9126 ..................................................................................... 15

Métricas de indicadores e de produto ......................................................................... 15

Controle do software ...................................................................................................... 16

O produto e o processo em relação à medição ........................................................ 17

As estimativas mais importantes .................................................................................. 17

Métricas do processo ...................................................................................................... 17

Métricas do produto ........................................................................................................ 18

Métricas diretas e métricas indiretas............................................................................ 19

Métricas orientadas ao tamanho .................................................................................. 19

Métricas orientadas à função ........................................................................................ 20

Princípios de medição .................................................................................................... 20

Atributos de métricas eficazes de software ................................................................ 20

Atividade Proposta........................................................................................................... 22


........................................................................................................................... 22 Referências

......................................................................................................... 22 Exercícios de fixação

Aula 2: Pontos por Função ......................................................................................................... 30

........................................................................................................................... 30 Introdução

.............................................................................................................................. 31 Conteúdo

Métricas baseadas em função ou Pontos por Função (PF)...................................... 31

Valores do domínio de informações ........................................................................... 31

Valores do domínio de informações – Tabela de PF ................................................ 32

Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA) ........................ 33

Exemplo de Diagrama de Fluxo de Dados (DFD) simples ........................................ 36

Cálculo dos Pontos por Função .................................................................................... 38

Método para estimativa de custo – exemplo SERPRO ............................................. 38

Contagem de Pontos por Função de Projetos de Manutenção ............................. 40

Pontos de Casos de Uso (PCU) ..................................................................................... 40

Calculando o peso dos Atores do Sistema ................................................................. 41


....................................................................................................................... 42 Aprenda Mais

........................................................................................................................... 42 Referências

Exercícios de fixação ......................................................................................................... 42

Aula 3: Determinação de Ponto por Função .............................................................................. 49

........................................................................................................................... 49 Introdução

.............................................................................................................................. 50 Conteúdo

Contextualização ............................................................................................................. 50

Fan-out e Fan-in .............................................................................................................. 51

Fan-out e Fan-in: características .................................................................................. 51

Métricas de projeto da arquitetura ............................................................................... 53

Indicadores de qualidade de software ........................................................................ 55

Métricas para projeto orientado a objeto ................................................................... 57

Métricas orientadas a classe — o conjunto de métricas CK .................................... 59


........................................................................................................................... 61 Referências


Aula 4: Estimativa de esforço e prazo ....................................................................................... 68

........................................................................................................................... 68 Introdução


.............................................................................................................................. 69 Conteúdo

COCOMO .......................................................................................................................... 69

COCOMO básico .............................................................................................................. 69

Exemplos de COCOMO básico ..................................................................................... 70

COCOMO intermediário ................................................................................................. 73

COCOMO avançado ........................................................................................................ 76

COCOMO avançado: Spider-CoCoMo ........................................................................ 76

COCOMO II ....................................................................................................................... 78

Método de Putnam .......................................................................................................... 79

Complexidade ciclomática ............................................................................................ 79

Complexidade ciclomática ............................................................................................ 80

Conclusões........................................................................................................................ 81


........................................................................................................................... 81 Referências


Conteudista ..........................................................................................................................88 .


Qualquer empresa nasce com o sonho de ser bem-sucedida, mas nem todas

são vencedoras, e algumas até morrem antes de completar seu primeiro ano.

Empresas de sucesso são aquelas que trabalham com foco na gestão da

qualidade e do conhecimento.

No caso de PROJETO, verificamos que o gerenciamento é necessário, mas não

podemos gerenciar aquilo que é impossível medir.

A gestão do desenvolvimento, da manutenção e da prestação de serviços

relacionados ao software – que envolve custo, prazo e qualidade – passou,

então, a ser relevante. Afinal, esses fatores se constituem, hoje, como o

diferencial entre as empresas.

Plataformas como ITIL, CMMI e MPS-BR colocam as métricas e as medições

como práticas fundamentais para a gestão de software com padrão de

qualidade – o que tornou sua medição uma obrigação.

Nesse sentido, esta disciplina pretende desenvolver no profissional da área a

visão gerencial baseada na preocupação com o custo, a produtividade, a

qualidade e novas métricas, bem como com suas formas de medição e suas

limitações.


É muito importante que você conheça as técnicas de gerenciamento de projeto

de software e saiba estabelecer parâmetros para futuras medições.

Sendo assim, esta disciplina tem como objetivos:

1. Definir medida e métrica de software;

2. Identificar as formas de medição, de estimativa e de acompanhamento de

um projeto de software, bem como os parâmetros para futuros projetos;

3. Descrever as métricas mais usuais para fins de medição do esforço no

desenvolvimento de um software.


Introdução

Você terá oportunidade de desenvolver os Conceitos de métricas e medições

para software, medidas diretas e indiretas, medidas no software pronto (kloc).

Toda empresa já nasce com o “sonho de ser bem-sucedida”, porém muitas

delas nem chegam a completar seu primeiro ano. Empresas de sucesso são

aquelas que estão trabalhando com foco na gestão da qualidade e do

conhecimento. No entanto, não se pode gerenciar o que não se pode medir.

Assim, plataformas como ITIL, CMMI, MPS-BR e outras, colocam as métricas e

medições como práticas fundamentais para a gestão de software com padrão

de qualidade.

A qualidade tornou a medição do software nos seus diversos aspectos uma

obrigação. Deve-se desenvolver no profissional de software a visão gerencial,

assim como a preocupação com custo, produtividade, qualidade e novas

métricas, suas formas de medição e suas limitações. Ele deve conhecer

conceitos para medir o software (produtividade, qualidade, prazo, tamanho

etc.) desde a fase de especificação de requisitos. Para tal, deve conhecer

técnicas e ferramentas em suas medidas nas diversas fases do projeto.

Preparado para iniciar a aula? Bons estudos!

Objetivo:

1. Compreender os conceitos das métricas e das medições de software;

2. Entender o que envolve a qualidade de software.


Conteúdo

Métricas para Software

Então, o próprio mercado exige, hoje, a gestão da qualidade, do conhecimento

e sabe-se que não se pode gerenciar o que não se pode medir. No entanto,

como medir valores como o conhecimento ou a qualidade?

Sabemos que todo processo de engenharia necessita de medições para

entender melhor os modelos e avaliar a quantidade dos produtos construídos.

No caso da engenharia de software – que não é fundamentada nas medidas

quantitativas diretas, como voltagem, temperatura, velocidade – as suas

medidas e métricas são na sua maioria indiretas.

Medição é o processo pelo qual são atribuídos valores numéricos ou simbólicos

às características de uma entidade qualquer, definidos de acordo com regras

bem definidas. Na ciência da computação, podemos medir os atributos, antes

considerados incomensuráveis – ainda que alguns especialistas em software

continuem a argumentar que o software é “incomensurável”.

O que é métrica?

Por sua natureza, a engenharia é uma disciplina quantitativa. A métrica de

produto ajuda os engenheiros de software a visualizar o projeto e a construção

do software, focalizando atributos específicos e mensuráveis dos artefatos da

engenharia de software.

Quem realiza?

Os engenheiros de software usam métricas de produto para ajudá-los a criar

software da mais alta qualidade.

Haverá sempre um elemento qualitativo na criação de software. O problema é

que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários

critérios objetivos para ajudar a direcionar o projeto de dados,

arquitetura, interfaces e componentes. Ao testar, necessitamos de


orientação quantitativa que nos auxiliará na seleção de casos de teste

e seus objetivos.

A métrica de produto proporciona uma base por meio da qual a análise,

projeto, codificação e teste podem ser conduzidos mais objetivamente e

avaliados de maneira mais quantitativa.

Haverá sempre um elemento qualitativo na criação de software. O problema é

que a avaliação qualitativa pode não ser suficiente. Fazem-se necessários

critérios objetivos para ajudar a direcionar o projeto de dados,

arquitetura, interfaces e componentes. Ao testar, necessitamos de

orientação quantitativa que nos auxiliará na seleção de casos de teste

e seus objetivos.

A métrica de produto proporciona uma base por meio da qual a análise,

projeto, codificação e teste podem ser conduzidos mais objetivamente e

avaliados de maneira mais quantitativa.

Atenção

Haverá sempre um elemento qualitativo na criação de software.

O problema é que a avaliação qualitativa pode não ser

suficiente. Fazem-se necessários critérios objetivos para

ajudar a direcionar o projeto de dados, arquitetura,

interfaces e componentes. Ao testar, necessitamos de

orientação quantitativa que nos auxiliará na seleção de

casos de teste e seus objetivos.

A métrica de produto proporciona uma base por meio da qual a

análise, projeto, codificação e teste podem ser conduzidos mais

objetivamente e avaliados de maneira mais quantitativa.


Por que devemos medir?

• Para sabermos quanto cobrar;

• Para conseguirmos dar prazos;

• Para definirmos a equipe;

• Para definirmos complexidade;

• Para definirmos tamanho;

• Para medirmos risco.

Quais são as etapas envolvidas?

O primeiro passo no processo de medição é definir as métricas apropriadas

para o software.

Em seguida, coletam-se os dados necessários para aplicar as métricas

formuladas.

Uma vez computadas, as métricas são analisadas com base em diretrizes

preestabelecidas e dados do passado.

Os resultados das análises são interpretados para obter informações

sobre a qualidade do software.

Os dados da interpretação levam à modificação dos requisitos e modelos

de projeto, código-fonte ou casos de teste.

Qual é o artefato (produto)?

O produto, no caso, são as métricas computadas por meio de dados

coletados dos requisitos e modelos de projeto, código-fonte e casos

de teste.

Como garantir que o trabalho seja realizado corretamente?

Estabeleça os objetivos da medição antes de iniciar a coleta de dados, definindo

cada métrica de produto de maneira não ambígua. Defina apenas algumas


métricas e, então, use-as para obter informações sobre a qualidade do artefato

de software.

Embora as métricas de produto para software sejam imperfeitas, podem

proporcionar uma maneira sistemática de avaliar a qualidade com base em um

conjunto de regras claramente definidas. Elas também proporcionam uma visão

objetiva, que “vai direto ao ponto” e não “após o fato”. Isso permite descobrir e

corrigir problemas potenciais antes que se tomem defeitos catastróficos.

Avaliação dos atributos internos do produto

A seguir, veremos algumas medidas que podem ser usadas para avaliar a

qualidade do produto enquanto ele está sendo projetado.

Essas medidas de atributos internos do produto fornecem uma indicação em

tempo real da eficácia dos modelos de requisitos, projeto e código, da

eficácia dos casos de teste e da qualidade geral do software que será

criado.

Qualidade de Software

O desenvolvimento de sistemas de software envolve uma série de atividades

em que as oportunidades de falhas são muito grandes.

Os erros podem aparecer no início do processo devido a alguns fatores:

• Objetivos mal definidos;

• Erros em fases de projeto e desenvolvimento.

Ninguém tolera erros, por isso o desenvolvimento de software tem que ter

garantia de qualidade.

A atividade de teste de software é um elemento crítico da garantia de qualidade

de software e representa a última revisão de especificação, projeto e

codificação.


Custo do reparo

Quanto mais cedo for verificado o software durante o seu ciclo de vida,

menores as chances de elevar os custos de reparo.

Curva de falhas para hardware ou curva da banheira


Garantia de qualidade

A garantia de qualidade de software (Software Quality Assurance) não é algo

com a qual começamos a nos preocupar depois que o código foi gerado, e sim

ao longo de todo o processo de engenharia de software. A SQA ou GQS

abrange:

Métodos e ferramentas de análise, projeto, codificação e teste;

Revisões técnicas em cada fase do desenvolvimento;

Estratégia de teste;

Documentação de software e das mudanças efetuadas;

Padrões de desenvolvimento de software;

Mecanismos de medição.

Fatores determinantes para a garantia da qualidade

Os requisitos de software são a base a partir da qual a qualidade é medida.

A falta de conformidade aos requisitos significa falta de qualidade.

Padrões especificados definem um conjunto de critérios de desenvolvimento

que orientam a maneira segundo a qual o software passa pelo trabalho de

engenharia. Se os critérios não forem seguidos, o resultado quase que

seguramente será a falta de qualidade.


Conjunto de requisitos que não são mencionados (ex.: boa

manutenibilidade). Caso o software se adéque aos requisitos explícitos, mas

não aos implícitos, sua qualidade será suspeita.

Fatores de qualidade de McCall

McCall propõe uma categoria de fatores que afetam a qualidade do software,

conforme mostra a figura.

Características operacionais

Corretude

Refere-se à capacidade de um programa satisfazer sua especificação e cumprir

os objetivos visados pelo cliente. Ele faz aquilo que eu quero?

Confiabilidade

Refere-se à capacidade de um programa executar a função pretendida com a

precisão exigida. Ele se comporta com precisão o tempo todo?

Usabilidade

Refere-se ao esforço necessário para aprender, operar, preparar a entrada e

interpretar a saída de um programa. Ele foi projetado para o usuário?


Integridade

Refere-se à capacidade de controlar o acesso ao software ou a dados por

pessoas não autorizadas. Ele é seguro?

Eficiência

Refere-se à quantidade de recursos computacionais e de código exigida para

que um programa execute sua função. Ele rodará em meu hardware tão bem

quanto possível?

Características de manutenção

Manutenibilidade

Refere-se ao esforço exigido para localizar e reparar erros em um programa.

Posso consertá-lo?

Flexibilidade

Refere-se ao esforço demandado para modificar um programa. Posso mudá-lo?

Testabilidade

Refere-se ao esforço exigido para testar um programa a fim de garantir que ele

execute a função pretendida. Posso testá-lo?

Características de adaptação a novos ambientes

Portabilidade

Refere-se ao esforço exigido para transferir o programa de um ambiente para

outro. Serei capaz de usá-lo em outra máquina?

Reusabilidade

Refere-se à capacidade de um programa, ou partes, ser reusado em outras

aplicações. Serei capaz de reutilizar parte do software?


Interoperabilidade

Refere-se ao esforço exigido para se acoplar um sistema a outro. Serei capaz

de compor uma interface com outro sistema?

Fatores de Qualidade ISO 9126

Funcionalidade: A funcionalidade diz respeito ao grau com que o software

satisfaz as necessidades indicadas pelos seguintes subatributos:

adequabilidade, precisão, interoperabilidade, atendibilidade e segurança.

Além da funcionalidade, outros fatores da ISO 9126: confiabilidade, usabilidade,

eficiência, manutenibilidade e portabilidade.

SEGUNDO PRESSMAN:

“O teste é o último reduto no qual a qualidade pode ser avaliada”;

“Você não pode testar qualidade. Se ela não estiver lá antes, ela não

estará lá quando terminar de testar”;

“Otimismo é o risco ocupacional da programação; teste é o tratamento";

“A qualidade de um software é função de quanto ele muda o mundo

para melhor”.

Métricas de indicadores e de produto

É importante que você entenda as diferenças sutis entre os termos medida,

medição e métrica, empregados com frequência.

MEDIDA

Sob o contexto de engenharia de software, medida proporciona uma indicação

quantitativa da extensão, quantidade, capacidade ou tamanho de algum

produto ou processo.

MEDIÇÃO

A medição é o ato de determinar uma medida.


MÉTRICA

Segundo o IEEE (Standard Glossary of Software Engineering Terminology),

métrica busca obter uma medida quantitativa do grau com o qual um

sistema, componente ou processo possui determinado atributo.

Quando é coletado um único ponto de dado (por exemplo, o número de erros

descobertos em um componente de software), foi estabelecida uma medida.

A medição ocorre como resultado da coleção de um ou mais pontos de dados

(por exemplo, um conjunto de revisões de componentes e testes de unidade é

investigado para coletar medidas do número de erros para cada um).

Uma métrica de software relaciona as medidas individuais de alguma maneira

(por exemplo, o número médio de erros encontrados por revisão ou o número

médio de erros encontrados por teste de unidade).

Antes que um projeto possa ser planejado, deve-se:

• Estabelecer os objetivos e o escopo do projeto;

• Considerar soluções alternativas;

• Identificar as restrições administrativas e técnicas.

Controle do software

É impossível controlar um software sem medições e feedback. Não se pode

controlar o que não se pode medir e a extensão do controle depende da

precisão da medição. Qualquer coisa que não se pode medir está fora de

controle.

As medições e métricas ajudam a entender o processo usado para se

desenvolver um produto de software e o próprio produto.


O produto e o processo em relação à medição

Produto é medido para avaliar a sua qualidade e processo é medido para

melhorá-lo. Para efetivar a medição é necessário ter em mãos documentação

de efeitos passados e dados estatísticos de quantificação de efeitos futuros.

A medição e a inferência estatística são usadas em várias áreas para projetar

o desempenho futuro.

A medição pode levar a controvérsias e discussões como:

• Que métricas usar?

• Como os dados compilados devem ser usados?

• É justo usar medições para se comparar pessoas, processos e produtos?

As estimativas mais importantes

A estimativa é uma das principais atividades do planejamento de software:

Esforço humano exigido

Duração do projeto

Custo

Métricas são frequentemente classificadas como métricas do processo ou

métricas do produto, e são aplicadas durante o processo de desenvolvimento

ou ao produto de software desenvolvido.

Métricas do processo

As métricas do processo quantificam atributos do processo de desenvolvimento

e do ambiente de desenvolvimento.

Métricas de recursos: experiência do programador, custo de

desenvolvimento e manutenção.


Métricas para o nível de experiência do pessoal: número de anos que

uma equipe está usando uma linguagem de programação; número de anos que

um programador está na organização.

Outros fatores relacionados ao desenvolvimento incluem:

• Técnicas de desenvolvimento;

• Auxílio para programação;

• Técnicas de supervisão etc.

Métricas do produto

São medidas do produto de software. Podem não revelar nada sobre como o

software foi desenvolvido.

Incluem:

O tamanho do produto (linhas de código);

A complexidade da estrutura lógica (recursão – for, while, repeat, fluxo

de controle – ordem das instruções do programa – e profundidade de

laços aninhados);

A complexidade da estrutura de dados;

Funções (tais como tipo de software: comercial, científico etc.).

Atenção

Nesse caso, é importante que você conheça um exemplo:

O número de defeitos descobertos durante o teste formal

depende do produto (número de segmentos de código que estão

errados) e do processo usado na fase de teste (a extensão do

teste).


Métricas diretas e métricas indiretas

Medidas Diretas do Processo de Software:

Custo e esforço aplicados.

Medidas Diretas do Produto:

Número de linhas de código produzidas (KLOC - Kilo Lines of Code ou

simplesmente “mil linhas de código”); Velocidade de execução; Tamanho de

memória; Número de defeitos registrados em um tempo qualquer.

Medidas Indiretas do Produto:

Qualidade;

Funcionalidade;

Complexidade;

Eficiência;

Confiabilidade;

Manutenibilidade.

Métricas orientadas ao tamanho

Linhas de Código (KLOC): uma linha de código é qualquer linha do texto de um

programa, exceto comentários e linhas em branco, sem levar em conta o

número de comandos ou fragmentos de comandos em uma linha. Estão

incluídas na definição de linhas de código todas as linhas que contém cabeçalho

do programa, declarações e comandos executáveis.


Vantagens:

• É fácil de calcular;

• É o fator mais importante para muitos modelos de estimativa.

Desvantagens:

• Dependente da linguagem de programação;

• Penalizam programas bem estruturados, porém mais curtos.

Métricas orientadas à função

• São medidas indiretas do software;

• Concentram-se na funcionalidade ou utilidade do programa;

• Função: coleção de comandos executáveis que realizam uma determinada

tarefa.

Princípios de medição

Formulação: criação de medidas e métricas apropriadas para a

representação do software.

Coleção: no caso, refere-se ao mecanismo usado para acumular dados

necessários para criar as métricas formuladas.

Análise: é a computação das métricas e a aplicação de ferramentas

matemáticas.

Interpretação: relacionada à avaliação de métricas que resultam em

informações sobre a qualidade da representação.

Feedback: são recomendações derivadas da interpretação de métricas

de produto transmitidas para a equipe de software.

Atributos de métricas eficazes de software

Centenas de métricas já foram propostas para software, algumas demandam

medições muito complexas, outras são tão esotéricas que poucos profissionais

do mundo real têm qualquer esperança de entendê-las, e outras ainda violam

as noções intuitivas básicas do que é realmente um software de alta qualidade.


Pressman (Engenharia de Software) elege atributos que deverão ser abrangidos

por métricas.

Planejamento

Análise

Design

Programação

A seguir estão elencados os atributos que devem ser considerados pelas

métricas – segundo Pressman (Engenharia de Software):

Simples e computáveis – Deverá ser relativamente fácil aprender a

derivar a métrica, e sua computação não deve demandar esforço ou

tempo fora do normal.

Empiricamente e intuitivamente persuasiva – A métrica deverá satisfazer

as ideias do engenheiro de software.

Consistente e objetiva – A métrica deverá sempre produzir resultados

que não sejam ambíguos. Um terceiro independente deverá ser capaz de

derivar o mesmo valor da métrica usando as mesmas Informações sobre

o software.

Consistente no seu uso das unidades e dimensões – A computação

matemática da métrica deverá usar medidas que não resultem em

combinações bizarras de unidades. Por exemplo, multiplicar número de

pessoas nas equipes de projeto pelas variáveis da linguagem de

programação no programa resulta em uma mistura duvidosa de

unidades que não é claramente convincente.

Independente da linguagem de programação – As métricas deverão ser

baseadas no modelo de requisitos, modelo de projeto ou na própria

estrutura do programa. Elas deverão ser independentes dos caprichos da

sintaxe ou semânticas das linguagens de programação.


Um mecanismo efetivo para feedback de alta qualidade – A métrica

deverá fornecer informações que podem levar a um produto final de

melhor qualidade.

Atividade Proposta

Discuta sobre a importância da adoção de métricas no processo de qualidade

de software.

Chave de resposta: O processo de desenvolvimento de software deve ter o

foco na qualidade.

Referências

PRESSMAN, Roger S. Engenharia de Software. 7. ed. Mc Graw Hill,2011.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Mc Graw Hill, 2007.

PADUA Filho, Wilson de. Engenharia de Software: Fundamentos, métodos e

padrões, 3. ed. Rio de Janeiro: Editora LTC, 2009.

Bibliografia Complementar:

PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.

VAZQUEZ,C.E. , SIMÕES,G.S. , ALBERT,R.M. Análise de ponto de função

medição, estimativa e gerenciamento de projetos de software. São

Paulo: Editora Érica, 2009.

Exercícios de fixação

Questão 1

Segundo Pressman, “Qualidade de software é a satisfação de requisitos

funcionais e de desempenho explicitamente declarados, normas de

desenvolvimento explicitamente documentadas e características implícitas que

são esperadas em todo software desenvolvido profissionalmente”. Analise as

afirmativas a seguir, relacionadas a software:

I. Falta de conformidade com os requisitos é falta de qualidade;

II. Os fatores de qualidade de Mc Call estão relacionados com operação, revisão

e transição de software;


III. Portabilidade – Facilidade com que o software pode ser transposto de um

ambiente para outro.

Agora assinale a alternativa correta:

a) Todas as afirmativas estão corretas

b) Apenas a afirmativa III está correta

c) Apenas a afirmativa II está correta

d) Apenas as afirmativas I e III estão corretas

e) Apenas as afirmativas II e III estão corretas

Questão 2

A avaliação qualitativa não é suficiente para medir o esforço do software. É

preciso critérios objetivos para direcionar o projeto de dados, arquitetura,

interfaces e componentes. Ao testarmos, necessitamos de orientação

quantitativa que nos auxiliará na seleção de casos de teste. A métrica de

produto proporciona uma base por meio da qual a análise, projeto, codificação

e teste podem ser conduzidos mais objetivamente e avaliados de maneira

quantitativa. Sendo assim, devemos medir:

I. Para sabermos quanto cobrar.

II. Para conseguirmos dar prazos;

III. Para definirmos a equipe;

IV. Para definirmos a complexidade;

V. Para definirmos o tamanho.


b) Estão corretas apenas as afirmativas I, III e IV

c) Estão corretas apenas as afirmativas I, II, III e V

d) Estão corretas apenas as afirmativas I, II, III e IV

e) Estão corretas apenas as afirmativas II, III, IV e V

Questão 3

Ninguém tolera erros, por isso o desenvolvimento de software tem que ter

garantia de qualidade. Ele envolve uma série de atividades em que as

oportunidades de falhas são muito grandes e, consequentemente, os erros


podem aparecer no início do processo. Isso se deve a alguns fatores, exceto

(assinale a alternativa INCORRETA):

a) Bom planejamento de teste

b) Objetivos mal definidos

c) Erros na fase de projeto

d) Planejamento malfeito

e) Requisitos mal definidos

Questão 4

A garantia de qualidade de software (Software Quality Assurance) não é algo

com a qual começamos a nos preocupar depois que o código foi gerado, e sim

ao longo de todo o processo de engenharia de software. A SQA abrange,

exceto (assinale a alternativa INCORRETA):

a) Dispensa de documentação de software e das mudanças efetuadas

b) Métodos e ferramentas de análise, projeto, codificação e teste

c) Estratégia de teste

d) Padrões de desenvolvimento de software

e) Mecanismos de medição

Questão 5

Segundo Roger Pressman, o gerenciamento de testes é um processo

fundamental para obter qualidade no software. Analise as afirmativas:

I. “O teste é o último reduto no qual a qualidade pode ser avaliada”;

II. “Você não pode testar qualidade. Se ela não estiver lá antes, ela não estará

lá quando terminar de testar”;

III. “Otimismo é o risco ocupacional da programação; teste é o tratamento”;

IV. “A qualidade de um software é função de quanto ele muda o mundo para

melhor”.


b) Estão corretas apenas as afirmativas I, III e IV

c) Estão corretas apenas as afirmativas I, II e III

d) Estão corretas apenas as afirmativas I, II e IV


e) Estão corretas apenas as afirmativas II, III e IV

Questão 6

Assinale a alternativa correta:

a) Na engenharia de software não existe diferença entre medição e medida.

b) Considerando o tempo de existência, a engenharia de software e a

engenharia civil se equivalem em maturidade.

c) Uma métrica mal especificada não gera qualquer influência para tomada

de decisão de baixa qualidade.

d) pesar de existirem métricas de processo e de projeto, não existem

métricas de produto.

e) Medida é diferente de métrica e pode ser realizada de forma direta ou

indireta.

Questão 7

No contexto de engenhada de software, medida pode ser definida como:

a) O ato de determinar uma medida.

b) Proporciona uma indicação quantitativa da extensão, quantidade,

capacidade ou tamanho de algum produto ou processo.

c) É um conceito matemático relacionado à distância de um módulo ao

seguinte.

d) É a divisão de um software em fragmentos marcados por tempo e custo.

e) É um conceito relacionado à gerência de projetos.

Questão 8

O processo de desenvolvimento de software deve ser continuamente medido

durante seu desenvolvimento. Para isso é necessário:

I. Criar uma “cultura” de medição e métrica (desenvolvimento com bases

técnicas);

II. Catalogar em base de dados históricos;

III. Padronizando em metros ou centímetros, cada medida obtida.

a) Completam o enunciado as afirmativas I e II


b) Completam o enunciado as afirmativas I e III

c) Completam o enunciado as afirmativas II e III

d) Completa o enunciado apenas a afirmativa I

e) Completa o enunciado apenas a afirmativa II

Questão 9

Uma linha de código é qualquer linha do texto de um programa, exceto

comentários e linhas em branco, sem levar em conta o número de comandos

ou fragmentos de comandos em uma linha. São medidas em Quilo de Linhas de

Código ou mil linhas (KLOC). Estão incluídas na definição de linhas de código

todas as linhas que contêm cabeçalho do programa, declarações e comandos

executáveis. Analise as afirmativas sobre KLOC e responda:

I. É fácil de calcular;

II. É um fator importante para muitos modelos de estimativa;

III. Depende da linguagem de programação;

IV. Penalizam programas bem estruturados, porém mais curtos.

a) Estão corretas as afirmativas I, III e IV

b) Estão corretas as afirmativas I, II e III

c) Estão corretas as afirmativas I, II e IV

d) Estão corretas as afirmativas II, III e IV

e) Todas as afirmativas estão corretas.

Questão 10

A estimativa é uma das principais atividades do planejamento de software.

Métricas são frequentemente classificadas como métricas do processo ou

métricas do produto e são aplicadas durante o processo de desenvolvimento ou

ao produto de software desenvolvido. Com relação às estimativas de software

marque a afirmativa correta (forma completa):

a) Para uma aplicação existente ou nova desejamos saber quanto tempo

será necessário para o desenvolvimento e também quanto é o custo.

b) Para uma nova aplicação desejamos saber quanto tempo será necessário

para fazer.


c) Para uma aplicação existente desejamos saber quanto tempo será

necessário para fazer uma alteração.

d) Para uma aplicação existente desejamos saber qual o custo de uma

alteração.

e) Para uma nova aplicação desejamos saber qual o custo da aplicação.

Aula 1


Questão 1 - A

Justificativa: Software que não segue os requisitos não oferece qualidade; O

fatores de Mc Call são exatamente operação, revisão e transição de software; A

portabilidade é uma exigência hoje, o que permite que o software possa ser

executado em mais de um sistema operacional.

Questão 2 - A

Justificativa: Para determinarmos o esforço empregado no software devemos

medir custo, prazo, recursos físicos e pessoas, a complexidade e o tamanho.

Portanto, todas as afirmativas estão corretas.

Questão 3 - A

Justificativa: No início do desenvolvimento devemos aplicar a característica da

abstração, isto é, nos preocuparmos com o que é mais importante para o

momento como, por exemplo, a definição clara dos objetivos e dos requisitos e

a elaboração de um bom planejamento do projeto, e deixar alguns detalhes

para mais adiante. O planejamento de implantação e disponibilização do

software deve ser feito em outra etapa.

Questão 4 - A

Justificativa: Um dos requisitos da qualidade do software é a documentação.

Software sem documentação se distancia das normas de qualidade. Qualidade


de software inclui padrões de medição e uso adequado de ferramentas de

desenvolvimento, implementação e teste.

Questão 5 - A

Justificativa: Todas as afirmativas estão registradas em “Engenharia de

Software” de Roger Pressman (6ª Ed. p. 340-350).

Questão 6 - E

Justificativa: Podemos ter medidas diretas como número de linhas de código

produzidas ou velocidade de execução e medidas indiretas como qualidade,

funcionalidade, complexidade.

A opção “a” está errada, pois medição é um processo, já medida é usada para

avaliar a qualidade do produto.

A opção “b”: engenharia civil existe há milênios.

A opção “c”: métrica mal especificada afeta a qualidade do produto.

A opção “d”: Os engenheiros de software usam métricas de produto para

ajudá-los a criar software da mais alta qualidade.

Questão 7 - B

Justificativa: Medida é a quantificação de algo que se quer medir. Por exemplo:

o tamanho do software em KLOC ou pontos por função. É um conceito

matemático, porém, não para medir distância entre módulos e nem a divisão de

um software.

Questão 8 - A

Justificativa: Criar uma cultura de medição de software e registrar os dados

históricos para que possam ser utilizados em projetos futuros são contribuições

para a qualidade do software. O software jamais será medido em metros ou

centímetros.


Questão 9 - E

Justificativa: KLOC é uma métrica orientada ao tamanho e de fácil obtenção e

independente da linguagem usada. pois bastar contar o número de linhas,

exceto os comentários. Por outro lado, programas orientados a objetos e bem

estruturados são penalizados por esta métrica.

Questão 10 - A

Justificativa: Todas as afirmativas são verdadeiras, porém, a mais completa é a

que fala em tempo e custo, isto é, a opção “a”.


Introdução

Nesta aula, você compreenderá como devem ser usadas as seguintes métricas:

Pontos por Função (PF); Ponto por Função Não Ajustado (PFNA); Pontos por

Função para Diagrama de Fluxo de Dados (DFD) simples; Método para

Estimativa de Custo; Contagem de Pontos por Função de Projetos de

Manutenção; Pontos de Casos de Uso (PCU); e Peso dos Atores do Sistema.

Essa abordagem é muito importante devido à necessidade de justificar prazos e

custos do software.

Bons estudos!

Objetivo:

1. Identificar os Pontos por Função;

2. Compreender a aplicação dos Pontos por Função.


Conteúdo

Métricas baseadas em função ou Pontos por Função (PF)

Para que servem os Pontos por Função?

Pontos por Função medem o tamanho funcional do software.

Da mesma forma que somente os metros quadrados são insuficientes para

administrar uma construção, PF são insuficientes para administrar um projeto

de SW.

Para que servem as métricas Pontos por Função?

A métrica Ponto por Função pode ser usada efetivamente como um meio para

medir a funcionalidade fornecida por um sistema. Por meio de dados históricos,

a métrica FP pode ser empregada para:

Estimar o custo necessário para projetar, codificar e testar o software;

Prever o número de erros que serão encontrados durante o teste;

Prever o número de componentes e/ou o número de linhas projetadas

de código-fonte no sistema implementado.

Valores do domínio de informações

A métrica Pontos por Função está baseada em medidas calculáveis (diretas) do

domínio do software e avaliações qualitativas da complexidade do software.

Valores do domínio de informações são definidos da seguinte maneira:

Entradas externas (number of external inputs - EEs): cada entrada

externa é originada de um usuário ou transmitida de outra aplicação e fornece

dados distintos orientados à aplicação ou informações de controle.

Arquivos lógicos internos (internal logic files - ILFs): as entradas devem

ser diferenciadas das consultas, que são contadas separadamente. Cada


arquivo lógico interno é um agrupamento lógico de dados que reside dentro das

fronteiras do aplicativo e é mantido através de entradas externas.

Saídas externas (number of external outputs - EOs): cada saída externa

é formada por dados derivados da aplicação e fornece informações para o

usuário. São relatórios, telas, mensagens de erro etc.

Consultas externas (number of external inquiries - EQs): uma consulta

externa é definida como uma entrada online que resulta na geração de alguma

resposta imediata do software na forma de uma saída online.

Arquivos lógicos internos (number of internal logical files ILFs): cada

arquivo lógico interno é um agrupamento lógico de dados que reside dentro das

fronteiras do aplicativo e é mantido através de entradas externas.

Arquivos de interface externos (number of external interface files -

EIFs): cada arquivo de interface externo é um agrupamento lógico de dados

que reside fora da aplicação, mas fornece informações que podem ser usadas

pela aplicação.

Valores do domínio de informações – Tabela de PF

Uma vez coletados os dados, a tabela de PF é preenchida associando um valor

de complexidade com cada contagem. Organizações que usam métodos Ponto

por Função desenvolvem critérios para definir se determinada entrada é

simples, média ou complexa. No entanto, a determinação da complexidade é de

certo modo subjetivo. Veja o quadro:


Exemplo de aplicação de Ponto de Função Não Ajustado (PFNA)

Um software a ser desenvolvido necessita da aplicação da métrica Pontos por

Função. Segundo a equipe de desenvolvimento, a seguinte relação foi

determinada ainda na fase de requisitos em consonância com o cliente em

função dos arquivos que farão parte do software e seus respectivos pesos com

relação ao PF total.

Para calcular o PF devemos seguir os seguintes passos:

- Eleger um dos tipos de função, preferencialmente aqueles que representam

altos percentuais, que são: Arquivos Internos - Entradas Externas - Saídas

Externas.

- Obter o número de ocorrências do tipo de função eleito.

- Calcular Pontos de Função Não Ajustados (PFNA).


- Utilizar o Fator de Ajuste da Complexidade = 1.

Durante as conversas preliminares com o cliente, verificou-se que os Arquivos

Internos seriam facilmente identificáveis, o que os credenciou como melhor

parâmetro para as estimativas de pontos de função.

Verificou-se que o total de Arquivos Internos é 13, portanto, complexidade

média, segundo a tabela definida pela equipe de desenvolvimento:

Concluímos que o software é de complexidade Média, pois 13 está na faixa 6

a 19. Considere este número e veja a seguir a continuidade dos cálculos.

Cálculo do PFNA

a) Como Arquivos Internos representam 25% do total dos PF:

25% ===> 13

100% ===> PF

PF = (13 * 100) / 25 = 52

b) Interfaces Externas: 3% de 52 = 1,56 (~= 2)

Entradas Externas: 30% de 52 = 15,6 (~= 16)

Saídas Externas: 28% de 52 = 14,56 (~= 15)

Consultas: 14% de 52 = 7,28 (~= 7)

Obs.: os arredondamentos devem obedecer ao padrão.

Tabela do PF

Podemos preencher a tabela de PF usando a coluna Complexidade Média.


Cálculo do PFA

Ponto de Função Ajustado (PFA)

Para calcular Pontos por Função Ajustado, usa-se a seguinte relação:

PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)]

Onde a contagem total é a soma de todas as entradas FP obtidas da Tabela.

Os Fi (i = 1 a 14) são fatores de ajuste de valor (value adjustment factors -

VAF) baseados em respostas a 14 questões. Cada uma dessas perguntas é

respondida por meio de uma escala que varia de 0 (não importante ou não

aplicável) a 5 (absolutamente essencial). Observe:

1. O sistema requer salvamento (backup)?

2. São necessárias comunicações de dados especializadas para transferir

informações para a aplicação ou da aplicação?

3. Há funções de processamento distribuído?

4. O desempenho é crítico?

5. O sistema rodará em um ambiente operacional existente e intensamente

utilizado?

6. O sistema requer entrada de dados on-line?

7. A entrada on-line de dados requer que a transação de entrada seja

composta em múltiplas telas ou operações?

8. Os ILFs (arquivos lógicos) são atualizados on-line?

9. As entradas, saídas, arquivos ou consultas são complexas?

10. O processamento Interno é complexo?


11. O código é projetado para ser reutilizável?

12. A conversão e Instalação estão incluídas no projeto?

13. O sistema é projetado para múltiplas Instalações em diferentes

organizações?

14. A aplicação é projetada para facilitar a troca e o uso pelo usuário?

Cálculo do PFA após respostas

Os valores constantes na Equação e os fatores de peso aplicados aos valores do

domínio de informações são determinados empiricamente.

Dando prosseguimento ao exercício, vamos imaginar que após as respostas às

14 perguntas, Fi totalizou 42.

Então:

PFA = Total de contagem x [0,65 + 0,01 x ∑ (Fi)]

PFA = 311 x [0,65 + 0,01 x 42]

PFA = 311 x 1,11

PFA = 332,77 ~= 333

Avance a tela para acompanhar um exemplo de Diagrama de Fluxo de

Dados (DFD) simples.

Exemplo de Diagrama de Fluxo de Dados (DFD) simples

Um software a ser desenvolvido necessita da aplicação da métrica Pontos por

Função. Segundo a equipe de desenvolvimento, a seguinte relação foi

determinada ainda na fase de requisitos em consonância com o cliente em

função dos arquivos que farão parte do software e seus respectivos pesos com

relação ao PF total.


O Diagrama de Fluxo de Dados é avaliado para determinar um conjunto-chave

de medidas de domínio de informação necessárias para a computação da

métrica ponto de função:

3 entradas externas — senha, botão de emergência e

ativar/desativar.

2 consultas externas — consulta de zona e consulta de sensor.

1 arquivo lógico interno (ILF) — arquivo de configuração do

sistema.

2 saídas externas — mensagens e estado do sensor.

4 arquivos de interface externa (EIF) — sensor de teste,

configuração de zona, ativar/desativar e alerta de alarme.


Cálculo dos Pontos por Função

O total da contagem apresentado no quadro Pontos por Função deve ser

ajustado usando a Equação, supondo que:

∑ (Fi) = 46

Portanto,

FP = 50 X [0,65 X (0,01 X 46)] = 56

Avance e acompanhe o Método para Estimativa de Custo.

Método para estimativa de custo – exemplo SERPRO

A estimativa de custo do projeto deve levar em consideração o custo da mão de

obra, considerando o esforço e o custo da hora de todos os profissionais

envolvidos no desenvolvimento da solução de software.

Além do custo da mão de obra e recursos computacionais, devem ser

considerados outros custos, tais como:


Treinamento

Consultoria

Viagens

Licenças de software

Custos indiretos etc.

Cálculo Custo do Projeto (CP)

Sugere-se a seguinte fórmula para calcular o custo relativo à mão de obra para

o desenvolvimento da solução (CP – Custo do Projeto).

CP = (QHC x VPC) + (QHA x VPA) + (QPF x EPF x VPA) + Outros

Custos

Onde:

QHC = Quantidade de Horas do Consultor

VPC = Valor da Hora do Consultor

QHA = Quantidade de Horas do Analista

VPA = Valor da Hora do Analista

QPF = Tamanho do Projeto em PF

EPF = Esforço para implementar um Ponto por Função na plataforma

em questão

Cálculo Preço Fixo por Ponto por Função

Caso o contrato seja de preço fixo por Ponto de Função, então pode-se

considerar o seguinte:

CP = (QHC x VPC) + (QHA x VPA) + (QPF x VPF)

Onde:

VPF = Valor Unitário do PF para o projeto em questão - Identificado de

acordo com a Tabela de Serviço Padrão do Sistema de Orçamento

Técnico.


Contagem de Pontos por Função de Projetos de Manutenção

Para que serve a contagem de Pontos por Função de Projetos de

Manutenção?

Esta contagem tem como propósito descrever os diversos tipos de projetos de

manutenção e mostrar uma solução para o seu dimensionamento em Pontos

por Função, visto que o manual de práticas de contagem não contempla

projetos de manutenção (maintenance), apenas o de melhoria (enhancement).

Quanto à documentação de projetos de manutenção pequenos (menores que

100 PF), deve-se registrar a solicitação do cliente e documentar os requisitos da

aplicação impactada pela demanda, de forma detalhada, visando apoiar a

contagem de Pontos de Função da demanda.

É importante também documentar as estimativas e a contagem de Pontos por

Função.

Pontos de Casos de Uso (PCU)

Quais são as características?

É possível estimar o tamanho do sistema ainda na fase de levantamento de

casos de uso.

Estima a dimensão do sistema de acordo com:

O modo como os usuários o utilizarão;

A complexidade de ações requeridas por tipo de usuário;

A análise em alto nível dos passos necessários para a realização de cada

tarefa.

O que é preciso para gerar estimativas com PCU?

Calcular o peso dos Atores do Sistema;

Calcular o peso dos casos de uso;


Calcular fatores de ajuste;

Calcular o Porte do Sistema.

Calculando o peso dos Atores do Sistema

Ações

Encontrar a métrica UAW (Unadjusted Actor Weight).

Classificar atores envolvidos em cada caso de uso.

Somar os produtos do número de atores de cada tipo pelo respectivo

peso.

Quadro Tipo de autor/peso

Exemplo

Um sistema projetado para dois tipos de usuários (gerente e usuário comum) e

que fosse acessado por um outro sistema utilizando-se de um protocolo de

comunicação, por exemplo, teria um valor de UAW de 8 (2 atores de nível

complexo e 1 ator de nível médio).

UAW = (2 * 3) + (1 * 2)

UAW = 8

Atividade Proposta

Discuta sobre a importância da adoção de métricas no processo de qualidade

de software.


Chave de resposta: O processo de desenvolvimento de software deve ter o

foco na qualidade.

Aprenda Mais

Material complementar

Para saber mais sobre Pontos por Função, acesse o vídeo

disponível em nossa biblioteca virtual.

Referências

PRESSMAN, Roger S. Engenharia de software. 7. ed. Mc Graw Hill, 2011.

SOMMERVILLE, Ian. Engenharia de software. 8. ed. Mc Graw Hill, 2007.

PADUA Filho, Wilson de. Engenharia de software: fundamentos, métodos e

padrões. 3. ed. Rio de Janeiro: Editora LTC, 2009.

PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.

VAZQUEZ, C.E. , SIMÕES, G.S., ALBERT, R.M. Análise de ponto de função




Questão 1

A Métrica de software baseadas em Pontos por Função mede:

a) O tamanho funcional do software.

b) A complexidade dos testes de software.

c) A extensão das sub-rotinas.

d) A quantidade de classes.

e) A qualidade do software.

Questão 2

A métrica Ponto por Função usa dados históricos para:

I — Estimar o custo necessário para projetar, codificar e testar o software.


II — Prever o número de erros que serão encontrados durante o teste.

III — Prever o número de componentes e/ou o número de linhas projetadas de

código-fonte no sistema implementado.

a) Todas corretas

b) Apenas I

c) Apenas II

d) Apenas II e III

e) Apenas I e III

Questão 3

A métrica Pontos por Função está baseada em medidas calculáveis do domínio

do software e avaliações qualitativas da complexidade do software. Um dos

domínios, “Entradas externas”, é definido como:

a) Originado de um usuário ou transmitido de outra aplicação e fornece

dados distintos à aplicação ou informações de controle.

b) Um agrupamento lógico de dados que reside dentro das fronteiras do

aplicativo.

c) Um agrupamento lógico de dados que reside fora da aplicação, mas

fornece informações que podem ser usadas pela aplicação.

d) Uma entrada online que resulta na geração de alguma resposta imediata

do software na forma de uma saída online.

e) Domínio formado por dados derivados da aplicação e que fornece

informações para o usuário.

Questão 4

A métrica Pontos por Função está baseada em medidas calculáveis do domínio

do software e avaliações qualitativas da complexidade do software. Um dos

domínios, “Arquivos lógicos internos”, é definido como:

a) Um agrupamento lógico de dados que reside dentro das fronteiras do

aplicativo.

b) Entrada originada de um usuário ou transmitida de outra aplicação e que

fornece dados distintos à aplicação ou informações de controle.


c) Um agrupamento lógico de dados que reside fora da aplicação, mas

fornece informações que podem ser usadas pela aplicação.

d) Uma entrada online que resulta na geração de alguma resposta imediata

do software na forma de uma saída online.

e) Domínio formado por dados derivados da aplicação e que fornece

informações para o usuário.

Questão 5

Na gestão de escopo de software, três elementos são essenciais em um projeto

de software. Analise as afirmativas e identifique-as como verdadeiras (V) ou

falsas (F).

( ) Após a definição do escopo, não é comum existirem mudanças no

desenvolvimento de projetos.

( ) A técnica de reuso de software nunca vai beneficiar a qualidade do

projeto.

( ) A técnica de reuso de software colabora para a redução do prazo do

projeto.

( ) Mesmo as pequenas mudanças de escopo devem ser registradas e

analisadas.

( ) Profissionais que dominam a Análise de Ponto por Função fazem com

que o cálculo da estimativa de esforço e custo seja uma ciência exata.

Questão 6

(CESGRANRIO – 2012 – Chesf) Um engenheiro de software fez uma contagem

de pontos por função de um software a ser desenvolvido e levantou as

seguintes informações:

COMPLEXIDADE EE – 3 4 6 SE – 4 5 7 CE – 3 4 6 ALI – 7 10 15 AIE – 5 7 10

Onde: PF = Contagem total x (0,65 + 0,01 x Soma Fi)


Considerando as possíveis complexidades de cada função de negócio, os

valores mínimos e máximos da contagem não ajustada de Pontos por Função

serão respectivamente:

a) 143 e 363

b) 177 e 361

c) 177 e 363

d) 179 e 361

e) 179 e 363

Questão 7

Em que consiste a modalidade preço por PF (Ponto por Função)?

a) É o valor global que uma empresa fornecedora está cobrando para um

determinado serviço.

b) É o valor unitário negociado com o qual se fará a transação comercial

para um desenvolvimento de software.

c) É um valor de referência de custo e que deve participar de um contrato.

d) É um valor que serve para medir a produtividade de um programador.

e) É um valor que serve para definir o quanto se pode pagar ao profissional

contratado (em regime CLT) em uma empresa.

Questão 8

(FCC – 2012 – TRE-CE) Considere 3 AIEs simples, 5 EEs médias, 8 CEs

complexas, 3 ALIs complexos e 7 SEs médias. O cálculo de PFs bruto é:

a) 136

b) 148

c) 159

COMPLEXIDADE EE – 3 4 6

SE – 4 5 7

CE – 3 4 6

ALI – 7 10 15

AIE – 5 7 10


d) 163

e) 212

Questão 9

A Análise de Pontos por Função (APF) é uma técnica para a medição de

projetos de desenvolvimento de software que visa estabelecer uma medida de

tamanho, em PFs, considerando a funcionalidade implementada, sob o ponto

de vista do usuário.

Analise as afirmativas a seguir, relacionadas à APF:

I — É uma ferramenta que permite determinar o tamanho de pacotes de

software adquiridos, através da contagem de todos os Pontos por Função

incluídos no pacote.

II — É uma ferramenta que permite estimar custos e recursos envolvidos em

projetos de desenvolvimento e manutenção de software.

III — O Ponto por Função não ajustado é definido pelo produto da contagem

por um fator de ajuste.

a) Apenas a afirmativa III

b) Apenas a afirmativa II

c) Apenas as afirmativas I e III

d) Apenas as afirmativas I e II

e) Todas as afirmativas estão corretas

Questão 10

Uma das boas práticas utilizadas pelas empresas para contratar fornecedores

desenvolvedores de software é homologá-los previamente. Assim, sempre que

houver alguma demanda de software para ser desenvolvido poderemos afirmar

que:

a) Todos os fornecedores cobrarão o mesmo valor pelo projeto.

b) Todos os fornecedores participarão de todas as propostas.

c) A contratante pode exigir que cada proposta apresente a quantidade de

Pontos por Função do projeto de forma detalhada, o que tornará mais

fácil comparar as propostas.


d) A contratada pode exigir que cada proposta apresente a quantidade de


fácil comparar as propostas.

e) A contratada pode exigir que cada proposta apresente a quantidade de


difícil comparar as propostas.

Aula 2


Questão 1 - A

Justificativa: Por definição, Pontos por Função medem o tamanho funcional do

software.

Questão 2 - A

Justificativa: Por melo de dados históricos, a métrica FP pode ser empregada

para estimar o custo, prever o número de erros que serão encontrados durante

o teste e prever o número de componentes e/ou o número de linhas projetadas

de código-fonte.

Questão 3 - A

Justificativa: Entrada externa não reside dentro do aplicativo. Ë fornecida pelo

usuário e/ou por outra aplicação.

Questão 4 - A

Justificativa: Arquivo lógico interno, conforme o seu nome diz, reside dentro da

fronteira do software.


Questão 5 - F, F, V, V, F

Justificativa: A maioria dos projetos passa por mudanças ao longo do ciclo de

vida. Métrica de software não pretende obter medidas exatas, mas uma

estimativa de esforço.

A técnica de reuso é recomendada no desenvolvimento de software e na sua

qualidade. Toda alterações no software deve ser documentada.

Portanto, a resposta correta é F-F-V-V-F

Questão 6 - E

Justificativa: Mínimo: (8 x 3) + (10 x 4) + (0 x 3) + (15 x 7) + (2 x 5) = 179

Máximo: (8 x 6) + (10 x 7) + (0 x 6) + (15 x 15) + (2 x 10) = 363

Questão 7 - B

Justificativa: A técnica Pontos por função é usado pelos desenvolvedores par

determinar o esforço no desenvolvimento do software. Assim, o custo do

software pode ser estimado.

Questão 8 - D

Justificativa: Solução: (3 x 5) + (5 x 4) + (8 x 6) + 3 x 15) + (7 x 5) = 163

Questão 9 - D

Justificativa: Pontos por função ajustado é definido pelo produto da contagem

por um fator de ajuste, o que contradiz o item III.

A técnica Pontos por Função determina o tamanho do software e os custos

correspondentes.

Questão 10 - C

Justificativa: Nos editais das licitações públicas para desenvolvimento de

software, pontos por função tem sido uma exigência do contratante.


Introdução

Nesta aula, você compreenderá :

• Métricas para modelo de projeto;

• Fan-out e Fan-in;

• Conectividade;

• Métricas de projeto da arquitetura;

• Métricas para projeto orientado a objeto;

• Acoplamento e Métricas orientadas à classe.

Esta abordagem é muito importante para determinar o tamanho do software.

Bons estudos!

Objetivo:

1. Compreender as métricas para o modelo de projeto de acordo com os

parâmetros de dimensão do software Fan-out e Fan-in;

2. Entender as métricas para o modelo de projeto de acordo métricas de

projeto da arquitetura.


Conteúdo

Contextualização

É inconcebível que o projeto de um novo avião, um novo chip de computador

ou um novo edifício comercial...

... seja conduzido sem a definição de medidas, sem determinar métricas

para os vários aspectos de qualidade e sem usá-las como indicadores para

orientar a maneira pela qual o projeto evoluirá.

E, além disso, o projeto de sistemas complexos baseados em software muitas

vezes é realizado praticamente sem nenhuma medição.

A ironia disso tudo é que as métricas de projeto para software estão

disponíveis, mas a grande maioria dos engenheiros de software continua

ignorando sua existência.

As métricas de projeto para software de computador, como todas as outras

métricas de software, não são perfeitas.

Continua o debate sobre sua eficácia e a maneira pela qual deveriam ser

aplicadas.

Muitos especialistas argumentam que é necessária mais experimentação para

que as medições de projeto possam ser usadas. E, além disso, projeto sem

medição é uma alternativa inaceitável.

Examinaremos a seguir algumas das métricas de projeto mais comuns para

software de computador. Cada uma delas pode proporcionar uma melhor

visualização, e todas podem ajudar o projeto a evoluir para um nível maior de

qualidade.


Fan-out e Fan-in

A hierarquia de controle, também chamada estrutura de programa, representa

a organização dos módulos de programa.

Ela não representa aspectos procedimentais de software, tais como sequência

dos processos, ocorrência/ordem das decisões ou repetição de operações.

A notação mais comum para representar a hierarquia é mostrada na figura.

Notamos que profundidade e largura constituem uma indicação do número de

níveis de controle e do espaço de controle global, respectivamente.

Fan-out

É uma medida do número de módulos que são diretamente controlados por

outro módulo, isto é, o número de subordinados imediatos para aquele módulo.

Fan-in

Indica quantos módulos controlam diretamente determinado módulo, isto é, o

Fan-in de um módulo indica o número de superiores imediatos que ele possui.

O relacionamento de controle entre os módulos é expresso da seguinte

maneira: um módulo que controla outro é superordenado a ele e,

inversamente, que um módulo controlado por outro é subordinado ao

controlador.

Na figura, o módulo X é superordenado aos módulos A, B, C. O módulo H é

subordinado ao módulo E, que é subordinado ao módulo A.

Fan-out e Fan-in: características

A hierarquia de controle também representa duas características distintas:

visibilidade e conectividade.


Visibilidade

Indica o conjunto de componentes de programas que pode ser invocado ou

usado como dados por um determinado componente. Por exemplo, um módulo

de um sistema orientado a objeto pode ter acesso a uma ampla sucessão de

objetos de dados que ele herdou, mas só faz uso de um pequeno número

desses objetos de dados.

Conectividade

Indica o conjunto de componentes que é diretamente invocado ou usado como

dados por determinado componente. Por exemplo, um módulo que faça

diretamente outro módulo iniciar a execução é conectado a ele.

Fan-out

Deve-se ter no máximo 7 subordinados.

Fan-in

Deve-se manter alto o número de superiores. Alto Fan-in é a recompensa pelo

factoring inteligente e a remoção de módulos restritivos.

Ter uma função chamada por muitos superiores evita a necessidade de

codificar a mesma função em vários lugares. Portanto, em tempo de

manutenção, a duplicidade de alteração é eliminada.

Módulos com Fan-in devem ter boa coesão: funcional ou, no mínimo,

comunicacional ou sequencial.

Existem duas regras para restringir o uso de Fan-in:

Cada interface para um único módulo deve ter os mesmos números e tipos de

parâmetros. O exemplo a seguir contraria esta regra.


Métricas de projeto da arquitetura

As métricas de projeto da arquitetura focalizam as características da arquitetura

do programa com ênfase na estrutura arquitetônica e na eficácia dos módulos

ou componentes dentro da arquitetura.

Essas métricas são uma “caixa-preta” no sentido de que elas não requerem

qualquer conhecimento do funcionamento interno de um determinado

componente de software.

Card e Glass [Car90] definem três medidas de complexidade de projeto de

software:

Complexidade estrutural: Para arquiteturas hierárquicas (por exemplo,

arquiteturas de chamada e retorno), a complexidade estrutural de um

módulo i é definida da seguinte maneira:

Complexidade de dados: A complexidade dos dados (data complexity)

proporciona uma indicação da complexidade na interface Interna para um

módulo i e é definida como:

Em que v(i) é o número de variáveis de entrada e saída passadas para o do

módulo i.

Complexidade de sistema: Por fim, a complexidade de sistema (system

complexity) é definida como a soma da complexidade estrutural e de dados,

especificada como:


Atenção

À medida que esses valores de complexidade aumentam, a

complexidade global da arquitetura do sistema também

aumenta.

Isso leva a uma maior probabilidade de que o trabalho de

integração e teste também aumente.

Fenton [Fen91] sugere um conjunto de métricas de morfologia simples (isto é,

forma) que permite que diferentes arquiteturas de programa sejam comparadas

usando uma série de dimensões diretas. Referindo-se à arquitetura de chamada

e retorno na Figura apresentada, podem ser definidas as seguintes métricas:

Tamanho = n + a

em que n é o número de nós e a é o número de arcos.

Para a arquitetura mostrada:

Tamanho = 19 + 24 = 43

Profundidade = caminho mais longo desde o nó raiz (topo) até o nó da

folha. Logo, a profundidade = 5

Largura = número máximo de nós em qualquer nível da arquitetura.

Logo, largura = 7

A relação arco para nó,

r = a/n

mede a densidade de conectividade da arquitetura:

r= 24/19 = 1,26.


Indicadores de qualidade de software

A força aérea americana (U.S. Air Force Systems Command) desenvolveu um

conjunto de indicadores de qualidade de software baseados nas características

de projeto mensuráveis de um programa de computador. Usando conceitos

similares àqueles propostos na norma IEEE Std. 982.1-1988, a Força Aérea usa

informação obtida do projeto de dados e arquitetural para criar um índice de

qualidade da estrutura do projeto (design structure quality index - DSQI) que

varia de 0 a 1.

Os seguintes valores devem ser apurados para calcular o DSQI:

S1: Número total de módulos definidos na arquitetura do programa.

S2: Número de módulos cuja função correta depende da origem dos

dados de entrada ou que produzem dados para serem usados em outro

lugar (em geral, módulos de controle, entre outros, não seriam contados

como parte de S2).

S3: Número de módulos cuja função correta depende de processamento

anterior.

S4: Número de itens de base de dados (inclui objetos dados e iodos os

atributos que definem objetos).

S5: Número total de itens únicos de base de dados.

S6: Número de segmentos de base de dados (diferentes registros ou

objetos individuais).

S7: Número de módulos com uma única entrada e saída (processamento

de exceção não é considerado múltipla saída).

Uma vez determinados os valores S1 até S7, para um programa de computador

podem ser calculados os seguintes valores intermediários:

Estrutura de programa

D1, que é definido da seguinte maneira:


Se o projeto da arquitetura foi desenvolvido por meio de um método distinto

(por exemplo, projeto orientado a fluxo de dados (DFD) ou projeto orientado a

objeto (OO), então D1 = 1, caso contrário D1 = 0.

Independência modular

D2 = 1 – (S2/S1)

Módulos não dependentes de processamento anterior

D3 = 1 – (S3/S1)

Tamanho da base de dados

D4 = 1 – (S5/S4)

Compartilhamento da base de dados

D5 = 1 – (S6/S4)

Característica de entrada/saída do módulo

D6 = 1 – (S7/S1)

Cálculo do DSQI

Com os valores intermediários determinados, o DSQI é calculado da seguinte

maneira:

DSQI = ∑ wi/D

Em que i = 1 a 6, w1 é o peso relativo da importância de cada um dos valores

intermediários e ∑W1 = 1 (se todos os Di tiverem o mesmo peso, então w1 =

0,167).


Métricas para projeto orientado a objeto

Há muita coisa sobre projeto orientado a objeto que é subjetivo - um

projetista experiente “sabe” como caracterizar um sistema orientado a objeto

de maneira que implemente efetivamente os requisitos do cliente.

Mas, à medida que um modelo de projeto orientado a objeto cresce em

tamanho e complexidade, uma visão mais objetiva das características do

projeto pode favorecer tanto o projetista experiente (que obtém uma visão

adicional) quanto o novato (que obtém uma indicação da qualidade que de

outra forma não estaria disponível).

Em um tratamento detalhado de métricas de software para sistemas orientados

a objeto, Whitmire descreve nove características distintas e mensuráveis

de um projeto orientado a objeto:

1. Tamanho. É definido em termos de quatro visualizações: população,

volume, comprimento e funcionalidade. População é medida tomando-se

uma contagem estática das entidades orientadas a objeto, como classes

ou operações. Medidas de volume são idênticas às medidas de

população, mas são coletadas dinamicamente - em determinado instante

do tempo. Comprimento é a medida de uma cadeia de elementos de

projeto interconectados (por exemplo, a extensão de uma árvore de

herança é uma medida do comprimento). As métricas de funcionalidade

proporcionam uma indicação indireta do valor fornecido ao cliente por

uma aplicação orientada a objeto.

2. Complexidade. Assim como o tamanho, há muitas visões diferentes da

complexidade do software. Whitmire vê a complexidade em termos de

características estruturais examinando como as classes de um projeto

orientado a objeto se inter-relacionam.


3. Acoplamento. As conexões físicas entre elementos do projeto orientado

a objeto (por exemplo, o número de colaborações entre classes ou o

número de mensagens passadas entre objetos) representam o

acoplamento em um sistema orientado a objeto.

4. Suficiência. Whitmire define suficiência como “o grau com o qual uma

abstração possui as características requeridas para ela, ou o grau com o

qual um componente de projeto possui características em sua abstração,

do ponto de vista da aplicação corrente”. Em outras palavras,

perguntamos: “Que propriedades essa abstração (classe) precisa ter

para ser útil para mim?”. Essencialmente, um componente de projeto

(por exemplo, uma classe) é suficiente se refletir totalmente todas as

propriedades do objeto de domínio da aplicação que está modelando -

isto é, que a abstração (classe) possui as características necessárias para

ele.

5. Totalidade. A única diferença entre totalidade e suficiência é “o

conjunto de características em relação às quais comparamos a abstração

ou o componente de projeto”. A suficiência compara a abstração do

ponto de vista da aplicação corrente. A totalidade considera múltiplos

pontos de vista, formulando a pergunta: “Que propriedades são

necessárias para representar completamente o objeto de domínio do

problema?”. Em virtude do critério da totalidade considerar diferentes

pontos de vista, ele tem uma implicação indireta no grau com o qual a

abstração ou o componente de projeto pode ser reutilizado.

6. Coesão. Assim como seu correspondente no software convencional, um

componente orientado a objeto deverá ser projetado de maneira que

tenha todas as operações funcionando em conjunto para atingir um

objetivo único e bem definido. A coerência de uma classe é determinada

examinando-se o grau segundo o qual “o conjunto de propriedades que

ela possui faz parte do domínio do problema ou projeto”.


7. Originalidade. Uma característica similar à simplicidade, originalidade

(aplicada tanto a operações quanto a classes) é o grau segundo o qual

uma operação é atômica - isto é, a operação não pode ser construída

por meio de uma sequência de outras operações contidas dentro de uma

classe que apresenta um alto grau de originalidade e encapsula apenas

operações primitivas.

8. Similaridade. O grau segundo o qual duas ou mais classes são

similares em termos de sua estrutura, função, comportamento ou

finalidade é indicado por essa medição.

9. Volatilidade. Conforme já afirmamos multas vezes neste livro, podem

ocorrer alterações de projeto quando os requisitos são modificados ou

quando acontecem modificações em outras partes de um aplicativo,

resultando em adaptação obrigatória do componente de projeto em

questão. A volatilidade de um componente orientado a objeto mede a

possibilidade de que uma alteração venha a ocorrer.

Métricas orientadas a classe — o conjunto de métricas CK

O que é classe?

A classe é a unidade fundamental de um sistema orientado a objeto. Portanto,

medidas e métricas para uma classe individual para a hierarquia da classe e

colaborações entre classes serão valiosas quando tivermos de avaliar qualidade

de projeto orientado a objeto.

Uma classe encapsula dados e a função manipula os dados. Com frequência é o

“pai” das subclasses (às vezes chamadas de filhas) que herda seus atributos e

operações. Muitas vezes elas colaboram com outras classes. Cada uma dessas

características pode ser usada como base para a medida.

Chidamber e Kemerer propuseram um dos conjuntos mais amplamente

conhecidos de métricas de software orientado a objeto. Também chamado de


conjunto de métricas CK (CK metrics suite), os autores propuseram seis

métricas de projeto baseado em classe para sistemas orientados a objeto.

Vejamos uma delas:

Métodos ponderados por classe (weighted methods per class - WMC).

Suponha que n métodos de complexidade c1,c2 ,..., cn são definidos para uma

classe C. A métrica especifica de complexidade escolhida (por exemplo,

complexidade ciclomática) deverá ser normalizada de maneira que a

complexidade nominal para um método assuma o valor 1,0.

WMC = ∑c1

Para i = 1 a n. O número de métodos e sua complexidade são indicadores

razoáveis do trabalho necessário para implementar e testar uma classe.

Atenção

Quanto maior for o número de métodos, mais complexa será a

árvore de herança (todas as subclasses herdam os métodos de

seus pais). Por fim, conforme o número de métodos cresce para

uma dada classe, ela tende a se tornar cada vez mais específica

de aplicação, limitando assim sua potencial reutilização. Por

todas essas razões, o WMC deverá ser mantido o mais baixo

possível.

Embora pudesse parecer relativamente fácil desenvolver uma

contagem para o número de métodos em uma classe, o

problema é na realidade mais complexo do que parece. Deverá

ser desenvolvida uma abordagem consistente de contagem.


Atividade Proposta

Discuta com seus colegas a importância da adoção de métricas no processo de

projeto de software a importância do fan-in e fan-out em uma estrutura de

módulos de projeto de software.

Chave de resposta: FAN-OUT, FAN-IN, Complexidade de dados,

complexidade estrutural.

Referências

PRESSMAN, Roger S. Engenharia de software. 7. ed. Mc Graw Hill, 2011.

SOMMERVILLE, Ian. Engenharia de software. 8. ed. Mc Graw Hill, 2007.

PADUA Filho, Wilson de. Engenharia de software: fundamentos, métodos e


PETERS, James F. Engenharia de software. 3. ed. Campus, 2001.

VAZQUEZ, C.E. , SIMÕES,G.S., ALBERT, R.M. Análise de ponto de função




Questão 1

A estrutura de programa representa a organização de seus módulos. A

profundidade e largura da estrutura constituem uma indicação do número de

níveis de controle e do espaço de controle global, respectivamente. A medida

que determina o número de módulos que são diretamente controlados por

outro módulo é denominada:

a) Fan-in

b) Fan-out

c) Stubb

d) EAP

e) Hierarquia


Questão 2

A estrutura de programa representa a organização de seus módulos. A

profundidade e largura da estrutura constituem uma indicação do número de

níveis de controle e do espaço de controle global, respectivamente. A medida

que indica quantos módulos controlam diretamente determinado módulo, isto é,

indica o número de superiores imediatos que ele possui é denominado:

a) Fan-in

b) Fan-out

c) Stubb

d) EAP

e) Hierarquia

Questão 3

A característica da hierarquia de controle da estrutura do software que indica o

conjunto de componentes que é diretamente invocado ou usado como dados

por determinado componente é denominada:

a) Factoring

b) Visibilidade

c) Extensão

d) Conectividade

e) Navegabilidade

Questão 4

No Fan-out, quantos módulos subordinados devemos ter, no máximo?

a) 3

b) 5

c) 6

d) 7

e) 8

Questão 5

No Fan-in, quantos módulos superiores, no máximo, devemos ter?


a) O mínimo possível

b) Alto número de superiores

c) 4

d) 5

e) 6

Questão 6

Em um tratamento detalhado de métricas de software para sistemas orientados

a objeto, Whitmire descreve algumas características distintas e mensuráveis de

um projeto orientado a objeto. Assinale a opção INCORRETA:

a) Volatilidade

b) Hierarquia

c) Similaridade

d) Originalidade

e) Coesão

Questão 7

As métricas de projeto focalizam as características da arquitetura do programa

e são verdadeiras “caixa-preta” no sentido de que elas não requerem qualquer

conhecimento do funcionamento interno de um determinado componente de

software. São definidas três medidas de complexidade de projeto de software:

a) Temporal, procedimental e casual.

b) Informacional, de dados e funcional.

c) Procedimental, funcional, hierárquico.

d) Estrutural, de dados e de sistema.

e) Lógica, funcional e de dados.

Questão 8

A complexidade dos dados proporciona uma indicação da complexidade na

interface interna do software para um módulo “i” e é definida como

D(i) = v(i)/[fout (i) + 1]


Onde fout (i) é o Fan-out do módulo i e v(i) é o número de variáveis de

entrada e saída passadas para o do módulo “i”. Calcule a complexidade na

interface para o módulo com um número total de variáveis 19 e Fan-out 7.

a) 3,45

b) 6,70

c) 2,37

d) 3,98

e) 0,37

Questão 9

Calcule a complexidade do módulo de um software com complexidade

estrutural é 15 e complexidade dos dados é 30.

a) 2

b) 450

c) 0,5

d) 45

e) 15

Questão 10

Uma estrutura de software possui 15 nós e 12 arcos. Qual é o seu tamanho?

a) 180

b) 1,25

c) 3

d) 27

e) -3

Aula 3


Questão 1 - B


Justificativa: stub, em português esboço de método, em desenvolvimento de

software, é um pedaço de código usado para substituir algumas outras. Já

STUBB é nada, a não ser sobrenome como Alexander Stubb é um político

finlandês.

EAP = Sestrutura Analítica de Projeto, técnica usada no gerenciamento de

projeto.

Hierarquia é a ordenada distribuição dos poderes com subordinação sucessiva.

FAN-IN indica o número de superiores imediatos que ele possui é denominado.

Fun-OUT é a medida que determina o número de módulos que são diretamente

controlados por outro módulo é denominada.

Questão 2 - A

Justificativa: stub, em português esboço de método, em desenvolvimento de

software, é um pedaço de código usado para substituir algumas outras. Já

STUBB é nada, a não ser sobrenome como Alexander Stubb é um político

finlandês.

EAP = Sestrutura Analítica de Projeto, técnica usada no gerenciamento de

projeto.

Hierarquia é a ordenada distribuição dos poderes com subordinação sucessiva.

FAN-IN indica o número de superiores imediatos que ele possui é denominado.

Fun-OUT é a medida que determina o número de módulos que são diretamente

controlados por outro módulo é denominada.

Questão 3 - D

Justificativa: Conectividade – é como se módulos estivessem conectados a

outros para serem chamados durante a execução. Indica o conjunto de

componentes que é diretamente invocado ou usado como dados por

determinado componente. Por exemplo, um módulo que faça diretamente outro

módulo iniciar a execução é conectado a ele.

Extensão – significa comprimento, ou seja, a medida de uma cadeia de

elementos de projeto interconectados (por exemplo, a extensão de uma árvore

de herança é uma medida do comprimento).


Factoring – significa fatorar, dividir um módulo em módulos mmenores, o uqe

facilita a sua manutenção futura.

Visibilidade – característica que torna um aplicativo ou mesmo uma empresa

em algo que passa a ser percebido pelo mercado.

Navegabilidade - ...

Questão 4 - D

Justificativa: Em uma estrutura de módulos de um programa, o Ideal é que

tenhamos módulos com alto fan-in (muitos módulos chamando um determinado

módulo) e baixo fan-out (um detreminado módulo chamando o menor número

possível de módulos para evitar maior complexidade na lógica de programação

e futura manutenção do software). Segundo os autores devemos gter nom

máximo 7 fan-out.

Questão 5 - B

Justificativa: No fan-in, devemos ter o maior número possível de módulos

chamando um determinado módulo. Isso facilita a lógca da programação e a

manutenção futura. Fan-in conta o número de funções que chamam uma

determinada função.

O fan-in de um módulo indica o número de módulos que o utilizam, ou seja,

que tem relações de uso com o modulo. * Um fan-in alto indica que o módulo

representa uma abstração bem definida e muito utilizada por outros módulos.

Questão 6 - B

Justificativa: Hierarquia é a ordenada distribuição dos poderes com

subordinação sucessiva.

As características de Whitmire são: Tamanho, Comprimento, Complexidade,

Acoplamento, Suficiência, Totalidade, Volatilidade, Similaridade, Originalidade e

Coesão.


Questão 7 - D

Justificativa: Card e Glass definem três medidas de complexidade de projeto de

software: complexidade estrutural, complexidade de dados, complexidade de

sistema.

Essas medidas são determinadas mediante fórmulas e cáculos simples.

Questão 8 - C

Justificativa: Aplicando a fórmula, temos:

D = v / (fout + 1)

D = 19 / (7 + 1)

D = 19 / 8 = 2,37

Questão 9 - D

Justificativa: Complexidade de sistema (ou de um módulo) é definida como a

soma da complexidade estrutural e complexidade de dados. Portanto:

C = 15 + 30 = 45

Questão 10 - D

Justificativa: Tamanho = n + a

em que “n” é o número de nós e “a” é o número de arcos.

Tamanho = 15 + 12 = 27


Introdução

Nesta aula, você compreenderá as seguintes técnicas de estimativa: COCOMO

(básico, intermediário e detalhado); COCOMO II (estimativas de prazo, de custo

e de defeitos); método de Putnam e a complexidade ciclomática.

Objetivo:

1. Compreender as técnicas de estimativa COCOMO e COCOMO II;

2. Entender o método de Putnam e a complexidade ciclomática.


Conteúdo

COCOMO

O que é COCOMO?

COnstructive COst MOdel (COCOMO) é um algorítmico modelo de estimativa

do custo do software criado por Barry Boehm.

O modelo usa uma fórmula básica de regressão, com parâmetros que são

derivados dos dados históricos e das características atuais dos projetos.

O método COCOMO é um modelo de estimativa do tempo de desenvolvimento

de um software e está baseado no estudo de 63 projetos, dos quais foram

examinados de 2.000 a 100.000 linhas de código em linguagens de

programação Assembly.

O COCOMO consiste em três implementações: básico, intermediário e

avançado. Avance a tela e compreenda cada uma delas.

COCOMO básico

COCOMO básico é um modelo estático que calcula o esforço de

desenvolvimento de software e seu custo em função do tamanho de linhas de

códigos desenvolvidas. Aplica-se às seguintes classes de projetos do software:

Orgânicos: são projetos relativamente pequenos, simples e com pouca

inovação, com equipes de dimensão relativamente pequena. Exemplo: mala

direta.

Semidestacado ou difuso (em tamanho e complexidade): são projetos

intermediários com características entre o modo orgânico e o embutido, em que

as equipes de trabalho são heterogêneas em termo de experiência, como, por

exemplo, um sistema de processamento de transações (folha de pagamento).


Embutido ou restrito: aplicável no desenvolvimento de sistemas complexos

embutidos em hardware, com muitas inovações, restrições severas e/ou

requisitos muito voláteis e de confinamentos operacionais; exemplo: sistema de

controle de telefonia.

O COCOMO básico é um modelo estático de valor simples, que calcula o

esforço do desenvolvimento de software em função do tamanho deste

software, expresso em linhas de código estimadas. Avance e veja alguns

exemplos.

Exemplos de COCOMO básico

Uma vantagem do COCOMO básico é a sua rapidez em estimativas de custo

de software; porém, sua exatidão é limitada devido à falta de fatores para

explicar as diferenças entre:

Ferramentas;

Qualidade de pessoal e experiência;

Uso de ferramentas modernas e técnicas;

Outros atributos de projeto que influenciam nos custos de software.


Exemplo 1: Considere um software com 33,3 Kloc; usando o modelo

semidestacado, temos:

Logo, o número ideal de pessoas no projeto é:

N = E/D = 152/14,5 = 11 pessoas

Suponha que outro software tenha o Kloc igual a 45,3?

Exemplo 2: Considere que, após uma análise de ponto de função, detectamos

236 PFs não ajustados e que, além disso, as fórmulas do COCOMO tenham sido

construídas com Kloc. Se a linguagem utilizada for ACCESS, temos:


TAMANHO = 38 x 236 (PF) = 8968 LOC = 8,968 KLOC

Usando o COCOMO básico, o gerente considerou o projeto como orgânico.

Sendo assim, vamos usar as fórmulas.

Logo, o número ideal de pessoas no projeto é:

N = E/D = 36/4,3 = 8 pessoas


COCOMO intermediário

O método intermediário é uma extensão do método básico, porém, com mais

categorias de controle, como: atributos do produto; atributos de hardware;

atributos pessoais; atributos do projeto.

Atributos do produto

I – Confiabilidade exigida do software;

II – Tamanho do banco de dados;

III – Complexidade do software.

Atributos do hardware

I – Restrições de desempenho de run-time;

II - Restrições de memória;

III – Mudanças do ambiente de software;

IV – Tempo de resposta.

Atributos de pessoal

I – Capacidade dos analistas;

II – Capacidade dos programadores;

III – Experiência na aplicação;

IV – Experiência no ambiente de hardware;

V – Experiência com a linguagem de programação.

Atributos do projeto

I – Uso de ferramenta de software;

II – Técnicas modernas de programação;

III – Prazo requerido para o desenvolvimento.


O COCOMO intermediário calcula o esforço de desenvolvimento de software em

função do tamanho do programa, que inclui custo, avaliação subjetiva do

produto, hardware, pessoal e atributos de projeto. Observe a fórmula:

Considere que, no exemplo 2 (COCOMO intermediário), o gerente considerou

o projeto como orgânico; portanto, usaremos as fórmulas:

Cálculo do EAF: primeiramente, o gerente analisou os 15 direcionadores da

tabela de multiplicadores de esforço:


Posteriormente, ele concluiu que:

Complexidade do software: Alta

Restrições quanto ao uso da memória: Alto

Experiência com a linguagem de programação: Baixa

Capacidade dos programadores: Baixa

Os outros atributos foram considerados normais.

Assim, podemos calcular o EAF:


COCOMO avançado

No COCOMO avançado, são incorporadas características da versão

intermediária com uma avaliação de impacto de custo em cada passo do

projeto.

Nele, pode ser empregado software interativo auxiliar para a estimativa de

custos e prazos. A partir de um conjunto de atributos, premissas e modos de

desenvolvimento, o COCOMO estima os prazos, custos e recursos necessários

para cada etapa do ciclo de vida do produto.

COCOMO avançado: Spider-CoCoMo

O que é Spider-CoCoMo?

É uma ferramenta oriunda das pesquisas do projeto SPIDER da Universidade

Federal do Pará (OLIVEIRA, 2010).

Esse projeto tem como objetivo a construção de uma suíte de ferramentas

livres para dar suporte à implementação do modelo de qualidade MPS.BR –

Melhoria de Processo de Software Brasileiro (SOFTEX, 2009).

Por que foi concebida?

Sua concepção ocorreu pela necessidade de uma forma sistematizada e simples

para realizar estimativas de projetos de software, pois a maioria das empresas

utilizam planilhas eletrônicas e, com elas, não é possível atender

completamente às necessidades dos gerentes, tendo em vista que não é

possível obter uma base histórica dos valores estimados nos projetos da

organização.

O que é o MPS.BR?

O MPS.BR (SOFTEX, 2009) é um programa que busca avaliar processos de

desenvolvimento de software por meio de um conjunto de boas práticas. Esse

modelo se divide em sete níveis de maturidade, partindo do nível G, o mais

baixo, até o nível A, o mais alto. À medida que se passa de um nível para o


outro, o processo é entendido como mais maduro; cada nível possui um

conjunto de atividades, denominados processos. Por fim, cada processo contido

em um nível possui resultados esperados, que indicam que um determinado

item do processo em questão foi alcançado. A avaliação se dá pela análise de

cada resultado esperado dos processos.

A Spider-CoCoMo está inserida no contexto do processo Gerência de Projetos,

auxiliando nas estimativas de custo, prazos e número de pessoas. A ferramenta

está indiretamente ligada com o resultado esperado do GPR 2 e diretamente

ligada com o GPR 4, dois dos resultados esperados desse processo.

GPR 2

Visa garantir que tarefas e produtos de trabalho sejam dimensionados por meio

de métodos apropriados. A ferramenta necessita que o resultado esperado seja

cumprido, pois ele serve de parâmetro para o cálculo do CoCoMo. Em particular

para esse resultado esperado, o projeto SPIDER possui duas ferramentas para

medir o tamanho de projeto baseado no método de análise de pontos por

função e pontos por casos de uso, que são a Spider-APF e a Spider-UCP

(BALDEZ, 2010).

Caso seja adotado qualquer outro tipo de método que não os citados

anteriormente, o valor pode ser inserido manualmente na Spider-CoCoMo sem

que haja perda nos resultados estimados.

GPR 4

Requer que o esforço e os custos sejam estimados. Esse resultado esperado é

totalmente atendido com a utilização da Spider-CoCoMo tanto nos níveis G e F,

tendo em vista que o método CoCoMo é utilizado para estimativas, como dito

anteriormente, como nos níveis superiores ao F, pois os valores estimados são

armazenados em banco de dados, sendo feito um histórico deles. Esse é o

grande diferencial da Spider-CoCoMo sobre as planilhas eletrônicas.


COCOMO II

O que é o COCOMO II?

O COCOMO II (segunda versão do COCOMO – COnstructive COst MOdel) é um

modelo objetivo de custos para o planejamento e execução de projetos de

software. Um modelo de custos fornece estrutura (framework) para a

comunicação de decisões de negócio entre os envolvidos em um

empreendimento baseado em software.

Além disso, oferece suporte a negociações contratuais, análises de melhoria de

processo, aquisição de ferramentas, alterações na arquitetura, decisões entre

desenvolvimento e aquisição de componentes, assim como diversas outras

decisões sobre retorno do investimento, servindo de base a estimativas plenas

de credibilidade.

Como se processa?

Embora a maioria das organizações inicie o processo de estimativa utilizando

modelos lineares simples, o amadurecimento do processo de software leva à

utilização de modelos mais sofisticados, capazes de melhor descrever os fatores

que influenciam os projetos de software.

O COCOMO II é uma excelente escolha nesse sentido. Desenvolvido em uma

universidade e fortemente apoiado pela indústria, oferece uma solução aberta,

escalável e respeitada.

Quais são suas vantagens?

O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um

componente individual;

O COCOMO pode calcular a programação da manutenção anual;

O COCOMO pode examinar a vantagem de dados históricos e, com essas

informações, criar uma constante da calibração que pode ser calculada

para estimativas futuras.


Qual é a sua desvantagem?

Imprecisão: sua precisão pode ser prejudicada no início do projeto, pois o

modelo depende fortemente de uma estimativa precisa da quantidade de

linhas.

Método de Putnam

O método de Putnam considera múltiplas variáveis e o ciclo de desenvolvimento

do projeto.

Com base em análise estatística, Putnam relacionou os comportamentos prazo

e esforço.

Equação de Putnam

Complexidade ciclomática

O que é?

Em 1976, McCabe criou uma maneira de testar cada caminho independente de

um programa, de forma que a quantidade de casos de teste será a

complexidade ciclomática do programa.

Complexidade ciclomática ou complexidade condicional é uma métrica usada

para indicar a complexidade do software; mede a quantidade de caminhos de

execução independentes a partir do código fonte.

Como é calculada?

É calculada a partir de um grafo de fluxo: os nós do grafo correspondem a

grupos indivisíveis de comandos, e uma aresta conecta dois nós.


Em que pode ser aplicada?

A complexidade ciclomática também pode ser aplicada a funções, módulos,

métodos ou classes individuais de um programa.

Complexidade ciclomática

Vamos a um exemplo?

Veja como calcular a complexidade ciclomática para um artefato de software

(VG).

Cálculo

V(G) = E – N + 2P

Para:

E = 8 P = 1

N = 7

V(G) = 8 – 7 + 2 = 3

V(G) = 3

V(G): Complexidade ciclomática;

G: Grafo (fluxograma);


E: Número de bordas (ligações);

N: Número de nós (instruções);

P: Número de componentes conectados ao gráfico (assumimos P = 1).

Conclusões

Não existe um modelo único;

Deve-se desenvolver o modelo mais adequado à empresa;

O modelo deve ser periodicamente revisto;

Deve-se validar por mais de um método;

É um aspecto estratégico para a empresa.

Atividade Proposta

Discuta com seus colegas a importância da adoção do modelo de estimativa de

ciusto COCOMO no processo de projeto de software a importância de se

determinar a complexidade ciclomática.

Chave de resposta: COCOMO, COCOMO II, Complexidade.

Referências

PADUA Filho, Wilson de. Engenharia de Software: fundamentos, métodos e


PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.

PRESSMAN, Roger S. Engenharia de Software. 7. ed. McGraw Hill, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. McGraw Hill, 2007.

VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de ponto de função




Questão 1

O método COCOMO é um modelo de estimativa do tempo de desenvolvimento

de um software, baseado no estudo de vários projetos, dos quais foram


examinados de 2.000 a 100.000 linhas de código em linguagens de

programação Assembly. Esse método consiste em três implementações: básico,

intermediário e avançado.

O modelo básico:

a) É um modelo com atributos de controle, como: atributos do produto;

atributos de hardware; atributos pessoais; atributos do projeto. É um

modelo com características da versão intermediária com uma avaliação

de impacto de custo em cada passo do projeto.

b) É um modelo estático que calcula o esforço de desenvolvimento de

software e seu custo em função do tamanho de linhas de códigos.

c) É um modelo dinâmico com características próprias que calcula o esforço

de cada programador.

d) É um modelo sistêmico que calcula as horas trabalhadas por cada equipe

do projeto.

Questão 2

O COCOMO básico se aplica a três classes de projetos do software; são elas:

a) Básico, intermediário e avançado

b) Orgânico, semidestacado e embutido

c) Básico, semidestacado e restrito

d) Difuso, semidestacado e embutido

e) Orgânico, difuso e semidestacado

Questão 3

O COCOMO ____________________ é aplicado no desenvolvimento de

sistemas complexos embutidos em hardware, com muita inovação, com

restrições severas e/ou com requisitos muito voláteis e de confinamentos

operacionais.

a) Difuso

b) Semidestacado

c) Orgânico

d) Funcional


e) Embutido

Questão 4

O COCOMO ____________________ mede projetos de software relativamente

pequenos, simples e com pouca inovação, com equipes de dimensão

relativamente pequena.

a) Avançado

b) Semidestacado

c) Orgânico

d) Funcional

e) Embutido

Questão 5

O COCOMO ____________________ é aplicado quando as equipes de trabalho

são heterogêneas em termo de experiência; por exemplo, um sistema de

processamento de transações, como o controle de estoque.

a) Avançado

b) Semidestacado

c) Orgânico

d) Funcional

e) Embutido

Questão 6

O COCOMO II (segunda versão do COCOMO – COnstructive COst MOdel) é um

modelo objetivo de custos para o planejamento e execução de projetos de

software. Um modelo de custos fornece uma estrutura (framework) para a

comunicação de decisões de negócio entre os envolvidos em um

empreendimento baseado em softwares. Marque as vantagens do COCOMO

II:

a)O mesmo processo pode ser aplicado ao projeto inteiro.

b)O mesmo processo pode ser aplicado a apenas um componente

individual.


c)Sua precisão pode ser prejudicada no inicio do projeto, pois o modelo

depende fortemente de uma estimativa precisa da quantidade de linhas.

d)Pode calcular a programação da manutenção anual.

e)Pode fazer exame da vantagem de dados históricos e criar uma constante

de calibração que pode ser calculada para estimativas futuras.

Questão 7

O __________________ considera múltiplas variáveis e o ciclo de

desenvolvimento do projeto com base em análise estatística, relacionando os

comportamentos prazo e esforço.

a) Método de esforço

b) Método COCOMO

c) Método COCOMO II

d) Método de pontos por função

e) Método de Putnam

Questão 8

A complexidade ciclomática ou complexidade condicional é uma métrica usada

para indicar a complexidade do software. Mede a quantidade de caminhos de

execução independentes a partir do código fonte. É calculada a partir de um(a):

a) Tabela da arquivos lógicos

b) Diagrama de fluxo de dados

c) Diagrama de casos de uso

d) Grafo de fluxo

e) Diagrama de Gantt

Questão 9

Analise esta tabela do COCOMO semidestacado.

Projeto de software ab bb cb db


Agora, determine o número de pessoas e o prazo que deve levar o projeto de

um software com 45 Kloc, usando:

E = ab * KLOC bb

D = cb * E db

P = E / D, onde:

E = Esforço aplicado por pessoa no mês

D = Tempo de desenvolvimento em meses

a) 328 pessoas/mês – 12 meses

b) 215 pessoas/mês – 16,4 meses

c) 142 pessoas/mês – 25,7 meses

d) 115 pessoas/mês – 26,4 meses

e) 102 pessoas/mês – 18 meses

Questão 10

Determine a complexidade ciclomática de um software cujo grafo apresenta 12

bordas e 7 nós. Considere o número de componentes conectado igual a 1.

a) 5

b) 7

c) 19

d) 14

e) 84

Aula 4


Questão 1 - B

Justificativa: O modelo COCOMO básico calcula o esforço do software em

função das linhas de código estimadas.

Semidestacado 3,0 1,12 2,5 0,35


Questão 2 - B

Justificativa: Segundo Pressman (Engenharia de Software) as classes de

projetos referentes ao COCOMO básico são Orgânico, Semi-destacado e

Embutido.

Questão 3 - E

Justificativa: Segundo Pressman (Engenharia de Software) as classes de

projetos referentes ao COCOMO básico são Orgânico, Semi-destacado e

Embutido.

Questão 4 - C

Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO

Orgânicos representam projetos relativamente pequenos, simples e com pouca

inovação, com equipes de dimensão relativamente pequena. Exemplo: Mala

Direta.

Questão 5 - B

Justificativa: Segundo Pressman (Engenharia de Software) o COCOMO Semi

destacado ou difuso - (em tamanho e complexidade) se refrem a projetos

intermediários com características entre o modo orgânico e o embutido, em que

as equipes de trabalho são heterogêneas em termo de experiência. Por

exemplo, um sistema de processamento de transações. Exemplo: Folha de

Pagamento.

Questão 6 - A, B, D, E

Justificativa: Segundo Pressman (Engenharia de Software) as vantagens do

COCOMO II são:

O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um

componente individual.

O COCOMO pode calcular a programação da manutenção anual.


O COCOMO pode fazer exame da vantagem de dados históricos e com esses

dados criar uma constante da calibração que pode ser calculada para

estimativas futuras.

Questão 7 - E

Justificativa: Segundo Pressman (Engenharia de Software) O método de

Putnam considera múltiplas variáveis e o ciclo de desenvolvimento do projeto.

Com base em análise estatística Putnam relacionou o comportamento prazo e

esforço.

Questão 8 - D

Justificativa: Segundo Pressman (Engenharia de Software), a complexidade

ciclomática é uma métrica usada para indicar a complexidade do software.

Mede a quantidade de caminhos de execução independentes a partir do código

fonte. É calculada a partir de um grafo de fluxo.

Questão 9 - B

Justificativa: Basta aplicar a fórmula.

E = 3 x 451,12 = 3 x 71,0555 = 215 pessoas/mês

D = 2,5 x 2150,35 = 2,5 x 6,55169 = 16,4

Questão 10 - B

Justificativa: Basta aplicar a fórmula.

V (G) = E – N + 2P

Onde E = 12

N = 7

P = 1

Logo: V(G) = 12 – 7 + 2 = 7


Luiz Roberto Martins Bastos é Mestre em Ciências e Computação, com

ênfase em Otimização de Processos, pelo Instituto Militar de Engenharia (IME),

Especialista em Informática Educativa pelo Centro Universitário Carioca

(UNICARIOCA), Graduado em Administração pela Universidade Estácio de Sá

(UNESA) e em Engenharia Elétrica pela Universidade Federal do Rio de Janeiro

(UFRJ). Possui experiência de 20 anos nas áreas de produção,

desenvolvimento, marketing e gestão de processos. Atualmente, é professor e

conteudista dos cursos de Graduação e Pós-Graduação da UNESA – nas

modalidades presencial e a distância. Também atua como professor convidado

da Fundação Getulio Vargas (FGV) e do Serviço Brasileiro de Apoio às Micro e

Pequenas Empresas (SEBRAE).

Currículo Lattes: http://lattes.cnpq.br/1109935861412082.

Documents

métricas de software