• Nenhum resultado encontrado

1 Medição e Métricas de Software

N/A
N/A
Protected

Academic year: 2019

Share "1 Medição e Métricas de Software"

Copied!
14
0
0

Texto

(1)

Medição e Métricas de

Software

2

Motivação

Um dos obj et ivos básicos da Engenharia de Soft ware é: a t r ansfor m ação da cr iação de sist em as soft w ar e de um a m aneir a ar t íst ica, indisciplinada e pouco

ent endível par a um a for m a devidam ent e con t r ola da , qu a n t ifica da e pr e visíve l

“ Mét ricas de Soft ware” é um assunt o discut ido há m ais de 20 anos na engenharia de soft ware ... e no ent ant o não é verificada sua ut ilização, na prát ica, pela grande m aioria

dos proj et os de const rução de soft ware

Pesquisas realizadas em em presas de soft ware indicam que m ais da m et ade de grandes proj et os de soft ware se deparam com algum t ipo de at raso,

excesso de cust o ou prazo ou algum fracasso na execução quando im plant ado

Motivação

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

m edir” .

Tom De Marco

 “ Se você não sabe para onde você quer ir,

qualquer cam inho você pode seguir. Se você não sabe onde você est á, um m apa não vai aj udar! ” .

(2)

44

Por que medir?

 Se não é possível m edir, expressando em

núm eros, apenas um a análise qualit at iva ( e, port ant o, subj et iva) pode ser feit a ( o que, na m aioria das vezes, é insuficient e) .

 Com m edições, as t endências ( boas ou m ás)

podem ser det ect adas, m elhores est im at ivas podem ser feit as e m elhorias reais podem ser conseguidas.

 Núm eros perm it em análises, com parações e

com binações que são im possíveis de fazer com out ros t ipos de inform ação.

55

Conceitos Básicos - Qualidade

 Caract eríst ica de Qualidade: um conj unt o de

at ribut osde um a ent idadepor m eio do qual a qualidade da m esm a pode ser avaliada.

 At ribut o: um a propriedade m ensurável, física ou

abst rat a, de um a ent idade.

 Ent idade: o que se desej a avaliar. No cont ext o

da Qualidade de Soft ware, um produt o, processo, recurso, proj et o et c.

 Caract eríst icas de Qualidade

 Sub- caract eríst icas

Exemplo 1

 Ent idade a ser avaliada: ferram ent a CASE de

m odelagem UML ( p.ex., Jude)

 Caract eríst icas de Qualidade:

 Funcionalidade ( adequabilidade)  Usabilidade

 Facilidade para o aprendizado  Facilidade para a operação  Facilidade de com preender

 Eficiência

 Em term os de tem po

 Em relação à utilização de recursos

 Port abilidade

(3)

77

Conceitos Básicos - Medição

 Medida

 Medição

 Mét rica

 I ndicador

88

Medida e Medição

 Medida: núm ero ou cat egoria at ribuído fornece um a indicação quant it at iva da ext ensão, quant idade, dim ensão, capacidade ou t am anho de um at ribut o de um a ent idade.

 Medição: é o at o de m edir, ist o é, de det erm inar um a m edida.

Métrica e I ndicador

 Mét rica: procura correlacionar m edidas

individuais com o obj et ivo de se t er um a idéia da eficácia da ent idade sendo m edida.

(4)

10

Em resumo - Métricas

 Um a m ét rica é a m edição de um at ribut o ( propriedades ou caract eríst icas ) de um a det erm inada ent idade ( produt o, processo ou recursos) . Exem plos:

 Tam anho do produt o de soft ware ( ex: Núm ero de Linhas de

código)

 Núm ero de pessoas necessárias para im plem entar um caso

de uso

 Núm ero de defeitos encontrados por fase de desenvolvim ento  Esforço para a realização de um a t arefa

 Tem po para a realização de um a t arefa  Cust o para a realização de um a t arefa

 Grau de sat isfação do client e ( ex: adequação do produto ao

propósito, conform idade do produto com a especificação)

11 11

Exemplo 2

 Desej a- se saber se um a pessoa est á com seu

peso ideal ou não. Para t al, duas m edidassão

im port ant es: alt ura ( H) e peso ( P) .

 Ao m edir essas dim ensões, est á- se efet uando

um a m edição.

 A m ét rica“ índice de m assa corporal ( I MC) ” é

calculada segundo a seguint e fórm ula: I MC = P / H2.

 A part ir dessa m ét rica, foram est abelecidos

indicadoresque apont am se um adult o est á acim a do peso, se est á obeso ou abaixo do peso ideal considerado saudável.

Exemplo 2

 I ndicadores da Organização Mundial de Saúde

Con diçã o I M C e m a du lt os

abaixo do peso abaixo de 18,5

no peso norm al entre 18,5 e 25

acim a do peso ent re 25 e 30

(5)

13 13

Exemplo 2

 I ndicadores da Nat ional Healt h and Nut rit ion Exam inat ion Survey

Con diçã o I M C e m M u lh e r e s I M C e m H om e n s

abaixo do peso < 19,1 < 20,7

no peso norm al 19,1 - 25,8 20,7 - 26,4

m arginalm ente acim a do peso 25,8 - 27,3 26,4 - 27,8

acim a do peso ideal 27,3 - 32,3 27,8 - 31,1

obeso > 32,3 > 31,1

14 14

Exemplo 1

 Funcionalidade

 Adequabilidade

Cobe r t u r a da fu n cion a lida de im ple m e n t a da - CFI

 Quão correta está a im plem entação funcional?

 CFI = 1 – NFNI / NFE

 NFNI : núm ero de funções ausent es ( não

im plem entadas) ou incorretam ente im plem ent adas det ect ado na avaliação

 NFE: núm ero de funções descritas na

especificação de requisitos

 Quanto CFI m ais perto de 1.0, m elhor.

 CFI < 0.8, descartar a possibilidade de adoção do

produto.

Por que medir software?

 Ent ender e aperfeiçoar o processo de

desenvolvim ent o

 Melhorar a gerência de proj et os e o relacionam ent o

com client es

 Reduzir frust rações e pressões de cronogram a  Gerenciar cont rat os de soft ware

 I ndicar a qualidade de um produt o de soft ware  Avaliar a produt ividade do processo

 Avaliar os benefícios ( em t erm os de produt ividade e

qualidade) de novos m ét odos e ferram ent as de engenharia de soft ware

(6)

16

Por que medir software?

 I dent ificar as m elhores prát icas de desenvolvim ent o de soft ware

 Em basar solicit ações de novas ferram ent as e t reinam ent o

 Avaliar o im pact o da variação de um ou m ais at ribut os do produt o ou do processo na qualidade e/ ou produt ividade

 Form ar um a baselinepara est im at ivas  Melhorar a exat idão das est im at ivas

 Oferecer dados qualit at ivos e quant it at ivos ao gerenciam ent o de desenvolvim ent o de soft ware, de form a a realizar m elhorias em t odo o processo de desenvolvim ent o de soft ware

17 17

Medição e Estimativas

 Base im port ant e para est im at ivas: dados

hist óricos.

 Mas só é possível chegar a boas est im at ivas com

base em dados hist óricos se os dados forem colet ados crit eriosam ent e.

 Port ant o, quando se pret ende ut ilizar dados de

proj et os ant eriores para est im ar, dados de m ét ricas são m uit o im port ant es.

Medição e Acompanhamento de Projetos

 Para acom panhar o andam ent o do proj et o, é

preciso m edir o progresso e com parar com o est im ado.

 Medidas colet adas dão visibilidade ao est ado do

proj et o, perm it indo verificar se o rum o est á corret o e fornecendo a base para a t om ada de ações corret ivas, quando necessário.

 Mét ricas t êm um im port ant e papel na rápida

(7)

19 19

Medição e Qualidade

 A única m aneira de avaliar e m elhorar a

qualidade de um a ent idade é m edir at ribut os específicos dessa ent idade, obt er um conj unt o de m ét ricas significat ivas baseadas nesses at ribut os e usar os valores das m ét ricas para fornecer indicadores que nort earão um processo de m elhoria.

20 20

Medição e Melhoria de Processos

 Colet ar dados que m eçam o desem penho de

cada processo.

 Analisar o desem penho de cada processo.

 Ret er e ut ilizar os dados para:

 Avaliar a est abilidade e a capacidade do processo;  I nt erpret ar os result ados das observações e análises;  Traçar t endências;

 I dent ificar oport unidades de m elhorias

 Ex.: Processo de Engenharia de Requisit os.

Possíveis problemas com métricas

 Ex: Com parar a produt ividade de engenheiros em t erm os de linha de código

 Está sendo utilizado a m esm a unidade de m edida?

O que é um a linha de código válida?

 O contexto considerado é o m esm o?

Todos os engenheiros são fam iliarizados com a linguagem de program ação?

 O que se quer realm ent e é o t am anho do código?

E a qualidade do código?

 Com o o resultado será interpretado?

Produt ividade m édia de um engenheiro?

 O que se quer com o resultado?

(8)

22 22

Problemas Relacionados à Medição

 Procedim ent os de Colet a de Dados: t odo

t rabalho de avaliação é colocado em risco se não puder garant ir- se a obt enção de dados

confiáveis.

 I nfluência de Usuários, hardware et c.

 Que m ét ricas colet ar?

23 23

Tipos de Métricas de Software

 Mét ricas de proj et o

 Mét ricas de produt o

 Mét ricas est át icas: Fan- in/ Fan- out , Com plexidade

ciclom át ica, Profundidade da árvore de herança et c

 Mét ricas dinâm icas: t em po para realizar det erm inada

função

 Mét ricas de processo: colet adas ao longo de

t odos os proj et os.

 Mét ricas de qualidade: ex.: m ét ricas

relacionadas a defeit os

Categorização de Métricas

 Mét ricas diret as ( fundam ent ais ou básicas)

 Medida realizada em t erm os de at ribut os observados

( usualm ent e det erm inada pela cont agem )

 Ex.: cust o, esforço, no. linhas de código, capacidade de

m em ória, no. páginas, no. diagram as, et c.

 Mét ricas indiret as ( derivadas)

 Medidas obt idas a part ir de out ras m ét ricas

 Ex.: com plexidade, eficiência, confiabilidade, facilidade

(9)

25

Categorização de Métricas

 Mét ricas orient adas a t am anho

 São m edidas diret as do t am anho dos art efat os de

soft ware associados ao processo por m eio do qual o soft ware é desenvolvido.

 Ex.: esforço, cust o, no. KLOC, no. páginas de

docum ent ação, no. erros

 Mét ricas orient adas por função

 Consist e em um m ét odo para m edição de soft ware do

pont o de vist a do usuário, det erm inando de form a consist ent e o t am anho e a com plexidade de um soft ware.

26

Categorização de Métricas

 Mét ricas de produt ividade

 Concent ram - se na saída do processo de engenharia de

software.

 Ex.: no. de casos de uso/ iteração.

 Mét ricas de qualidade

 Oferecem um a indicação de quanto o software se adeqüa às

exigências im plícitas e explícitas do cliente.

 Ex.: erros/ fase

 Mét ricas t écnicas

 Concentram - se nas características do software e não no

processo por m eio do qual o software foi desenvolvido.

 Ex.: com plexidade lógica e grau de m anutenibilidade

O Paradigma Goal Question Metrics (GQM)

 Usado para definir o conj unt o de m ét ricas a ser

colet ado

 Propost o por:

 Basili and Rom bach’s, Goal- Quest ion- Met rics Paradigm ,

I EEE Transact ions on Soft ware Engineering, 1988.

 Baseia- se no fat o de que deve exist ir um a

(10)

28

O Paradigma Goal Question Metrics (GQM)

 I nicia- se com a ident ificação dos int eressados na m edição.

 Com base nos int eressados, est abelecem - se os principais obj et ivos da m edição para a organização, o proj et o ou um a t arefa específica. Ex: reduzir defeit os, aum ent ar produt ividade, et c.

 A part ir dos obj et ivos, geram - se pergunt as cuj as respost as dirão se os obj et ivos foram ou não alcançados ( ex: Qual a t axa de defeit o at ual? Qual a t axa de defeit o após a im plant ação do novo processo?)

 A part ir das pergunt as, definem - se m ét ricas: que dados serão necessários? Quais os form at os? Com o colet ar ( fórm ula e processo) ? Onde arm azenar e com o ut ilizar?

29

GQM – Exemplo 1

 Obj et ivo: Assegurar que t odos os defeit os são

corrigidos ant es do soft ware ser liberado para uso.

 Pergunt as:

 Quant os defeit os t em os at ualm ent e?  Qual o st at us de cada defeit o?  Qual a cobert ura dos t est es?

 Mét ricas:

 Núm ero de defeit os

 Núm ero de casos de t est es planej ados x execut ados  Núm ero de requisit os t est ados

GQM – Exemplo 2

 Obj et ivo: Melhorar a qualidade dos processos de

verificação e validação.

 Quest ões:

 Qual a quant idade de erros encont rados na revisão dos

art efat os?

 Qual a quant idade de erros encont rados nos t est es?  Qual a quant idade de erros det ect ados quando o

sist em a j á est á em operação?

 Mét ricas:

(11)

31

Selecionando Objetivos

 Devem est ar associados a um período de t em po

 Aum ent ar a produt ividade em 20% no prazo de 12

m eses

 Facilit a o acom panham ent o e a t om ada de ações para

viabilizar obj et ivo pois exist e um prazo! ! !

 Est udos indicam que obj et ivos m uit o com plexos

e de longo prazo podem causar im pact o na m ot ivação

 Obj et ivos m enores, a curt o prazo, perm it em que as

pessoas visualizem o progresso e alcancem sucessos

 Com o t em po e com a m at uridade da organização, os

obj et ivos devem se t ornar m ais com plexos e m ais desafiadores

32

Selecionando Métricas

 Sej a realist a e prát ico

 Considere o processo e o am bient e de desenvolvim ent o at ual

 Não selecione m étricas em que os dados sej am difíceis de

serem coletados na sua realidade

 Com ece com o que for possível

 A equipe não deve ser m uit o im pact ada

 Ut ilize a abordagem increm ent al

 Com o tem po, com os benefícios, m ais dados estarão

disponíveis...

Selecionando Métricas

 Obj et ivo: Aum ent ar sat isfação do client e

 Que atributos dos nossos produtos e serviços são m ais

im portantes para os nossos clientes?

Aspectos Relev ante s de Produto e Serviço para Clientes

0 5 10 15 20

Qualidade Custo Prazo Visibilidade do Progresso

Flexbilidade p/ mudanças

Aspectos Relevantes Para os Clientes

(12)

34

Métricas - Manutenibilidade

 Tipos de m anut enção

 Corretiva: m odificações para corrigir defeitos ou

não- conform idades

 Adaptativa: utilizada em resposta a m odificações nos

requisitos ( algum as partes do produto j á foram testadas e im plem entadas)

 I ncrem ental: acréscim os às especificações do produto ( ex.:

funções que não foram previstas anteriorm ente)

 Prevent iva ( Pressm an) : produt o é m odificado de form a a

facilitar a realização dos outros tipos de m anutenção

 Mét ricas de m anut enibilidade são aplicadas em dois casos

 Prever o esforço necessário para m odificar o software  Criar um a base de dados hist órica que acom panha o

desenvolvim ent o

35

Métricas – Medidas de tamanho

 Tam anho pode ser indicador de várias

caract eríst icas:

 Program as m aiores dem oram m ais t em po para serem

desenvolvidos

 Program as m aiores envolvem t rabalho m ais com plexo

 Vant agens:

 Aplicação sim ples

 Fácil int erpret ação quando não se precisa de m uit a

precisão

 Baixo cust o de aplicação

 Desvant agens:

 I nt erpret ação: para program ar o dobro de linhas de

código, em geral, é preciso m ais do que duplicar o t em po

Medidas de tamanho - Linhas de código

 Medidas básicas

 LOC (Lines of Code) – NÃO se dist ingue linhas de

código de linhas em branco ou de com ent ários

 SLOC ( Source Lines of Code) físico – linhas em branco

e com ent ários não são considerados

 SLOC lógico – cada com ando cont a com o um a linha

 Exem plo

 3 LOCS, 2 SLOCS, 3 LOCS lógicos ( pois há t rês

com andos)

// uma comparação

(13)

37

Medidas de tamanho – Complexidade

estrutural

 Avalia a const rução int erna do soft ware:

núm ero de com ponent es, a quant idade e a nat ureza da relação ent re eles

 Mot ivo: um soft ware cuj a est rut ura é m ais

com plexa oferece dificuldades para ser analisado e com preendido

 São baseadas, em geral, no código font e

38

Complexidade ciclomática

 Propost o por McCabe ( 1976)

 Avalia o núm ero de cam inhos de execução

diferent es de um dado program a

 Prem issa básica: nível de aninham ent o de laços

e com andos de decisão t em relação com a com plexidade de execução e com plexidade psicológica

Complexidade ciclomática

 Baseada na Teoria dos grafos

 A com plexidade ciclom át ica, V( G) , para um fluxo de grafo G é definida por:

V( G) = E – N + 2, onde E corresponde ao núm ero de ram os e N o núm ero de nós do grafo de fluxo.  A com plexidade ciclom át ica, V( G) , para um fluxo de grafo

G é:

(14)

40

Complexidade ciclomática – Exemplo

int fib (int n) { int a = 1;

1 int b = 1; int c = 2;

2 if (0 == n) return 0; 8 3 if (3 > n) return 1; 9

4 while (n-- > 2) { c = a+b;

5 a = b;

b = c; }

6 return c;

} 7

Número de ramos ( E = 11 ) Número de nós ( N = 9) Número de nós predicativos ( P = 3 )

Referências

Documentos relacionados

A par disso, analisa-se o papel da tecnologia dentro da escola, o potencial dos recursos tecnológicos como instrumento de trabalho articulado ao desenvolvimento do currículo, e

Estaca de concreto moldada in loco, executada mediante a introdução no terreno, por rotação, de um trado helicoidal contínuo. A injeção de concreto é feita pela haste

(grifos nossos). b) Em observância ao princípio da impessoalidade, a Administração não pode atuar com vistas a prejudicar ou beneficiar pessoas determinadas, vez que é

nesta nossa modesta obra O sonho e os sonhos analisa- mos o sono e sua importância para o corpo e sobretudo para a alma que, nas horas de repouso da matéria, liberta-se parcialmente

No entanto, maiores lucros com publicidade e um crescimento no uso da plataforma em smartphones e tablets não serão suficientes para o mercado se a maior rede social do mundo

Segundo Éric Laurent, a psicose ordinária se caracteriza pela não resposta aos significantes-mestres tradicionais, manifestando o fim do poder do Nome-do-Pai como

3.3 o Município tem caminhão da coleta seletiva, sendo orientado a providenciar a contratação direta da associação para o recolhimento dos resíduos recicláveis,

O valor da reputação dos pseudônimos é igual a 0,8 devido aos fal- sos positivos do mecanismo auxiliar, que acabam por fazer com que a reputação mesmo dos usuários que enviam