UNIVERSIDADE ZAMBEZE

FACULDADE DE CIÊNCIAS E TECNOLOGIA

ENGENHARIA INFORMÁTICA

3° Ano – Laboral

Engenharia de Software

Tema:
Medição de Software

Nomes:
Evander Hassamo Ahmed Alegy
Keven José Manuel Gonçalves
Lingui Joaquim Moiana
Paulo Samuel Ernesto Tinga

Docente: Taheer Mithá

Beira, abril de 2022

Índice

Introdução.............................................................................................................................................2

Objetivos...............................................................................................................................................3

Objetivos gerais.................................................................................................................................4

Objetivos específicos.........................................................................................................................4

Medição.................................................................................................................................................4

Métricas de software.............................................................................................................................5

Métricas de produtividade................................................................................................................6

Metrica de qualidade.........................................................................................................................6

Utilização de Modelo de Qualidade.......................................................................................................7

Qualidade de uso.................................................................................................................................10

Métricas Orientadas ao tamanho (Linhas de Código)..........................................................................11

Métricas Orientadas à função (Analise de Pontos de Função)............................................................13

Razões para se medir um software......................................................................................................14

Exemplo de Métricas...........................................................................................................................15

Utilidade das métricas.........................................................................................................................18

Conclusão............................................................................................................................................19

Bibliografia..........................................................................................................................................19

2
Introdução
No mundo da engenharia medir é algo importante, e é algo fundamental para coleta de dados
e isso não é indiferente nos softwares e por isso devemos estudar as diversas formas de medir
e indicadores de qualidades que nos mostraram como o projeto está caminhando e se irá
agradar ao usuário final.

Neste contexto podemos contextualizar as medições como a definição de qualidade, escopo,

formar expectativas e avaliar a produtividade para o nosso produto final.

3
Objetivos

Objetivos gerais
 Definir medição e métricas de softwares, e avaliar os diversos pontos sobre o tema
 Explicar o porquê e como de fazer medições

Objetivos específicos
 Explicar o conceito de medições
 Falar acerca de como funciona as métricas nos softwares e dizer os diferentes tipos
 Explicar a utilização de um modelo de qualidade
 Definir Métricas Orientadas a função e orientadas a tamanho
 Dar as razões de medir um software
 Exemplificar as Métricas

4
Medição 
A medição é uma componente chave de qualquer engenharia, portanto, com o
amadurecimento da engenharia de software ela tem se tornado fundamental na coleta de
dados significativos, na identificação de pontos positivos e falhos da organização, assim
como no ciclo da melhoria de processo. 

O processo de medição ajuda a organização a gerenciar e tomar decisões baseadas em

fatos, a prever melhor a entrega de seus produtos, a melhorar seu processo de
desenvolvimento e a utilizar recursos com maior eficiência. Sua importância pode ser
evidenciada nas palavras de Tom de Marco:” Você não pode gerenciar o que não pode
medir”.

Dessa forma, a medição pode ser considerada como o ato de determinar uma indicação
quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de
um produto ou processo. Várias são as razões que podem influenciar o uso da medição no
âmbito organizacional, entre elas: 

 Obter melhor entendimento dos processos aplicados, dos produtos, recursos e

ambientes, e poder comparar em futuras avaliações; 
 Avaliar o andamento do projeto em relação aos planos; 
 Direcionar ações, baseado nas informações coletadas e analisadas; 

Identificar gargalos no processo que possam vir a causar impedimentos ou queda na

qualidade do produto final.  são parâmetros para a medição do desempenho de um software.
Uma métrica é um padrão de medida do grau em que um sistema ou processo de software é
dotado de uma dada propriedade.

5
Métricas de software
Ainda que uma métrica não seja uma medida (as métricas são funções, enquanto as
medidas são os números obtidos pela aplicação da métrica), muitas vezes os dois termos são
usados como sinônimos.

Dado que as medições quantitativas são essenciais em todas as ciências, há um

esforço contínuo dos profissionais e teóricos da ciência da computação para adotar
abordagens similares no desenvolvimento de software. A meta é obter medições objetivas,
reprodutíveis e quantificáveis, que podem ter inúmeras aplicações valiosas no planejamento
de cronograma e orçamento, na estimativa de custos, em quality assurance, testes, depuração
de software, otimização do desempenho do software e do pessoal envolvido nas tarefas.

Tais métricas, no processo de engenharia de software, podem ser diretas ou indiretas.

As diretas são o custo e o esforço aplicado ao desenvolvimento e manutenção do software e
do produto, a quantidade de linhas de código produzidas e o total de defeitos registrados
durante um determinado período de tempo. Porém, a qualidade e a funcionalidade
do software, ou a sua capacidade de manutenção, são mais difíceis de serem avaliadas e só
podem ser medidas de forma indireta. E a engenharia de software está longe de desenvolver
uma métrica-padrão amplamente aceita e cuja aplicação e resultados não sejam afetados por
fatores subjetivos. Frequentemente há divergências sobre o que medir e como avaliar o
resultado das medições.

Também podemos dividir as métricas de software, sob o ponto de vista de aplicação,

em duas categorias:

 Métricas de produtividade 
 Metrica de qualidade.

Métricas de produtividade
As métricas de produtividade concentram-se na saída do processo de engenharia
de software.

6
Metrica de qualidade

As métricas de qualidade indicam o quanto o software atende aos requisitos definidos

pelo usuário.
Métricas de software possibilitam realizar uma das atividades mais fundamentais do
processo de gerenciamento de projetos: o planejamento, a partir do qual se podem identificar
a quantidade de esforço, o custo e as a Modelo de Qualidade para Qualidades Diretas e
Indiretas tividades necessárias para a realização do projeto.

Utilização de Modelo de Qualidade

Qualidade de produto de software deveria ser avaliada utilizando um modelo de

qualidade definido. O modelo de qualidade deve ser usado quando se estabelecem metas de
qualidade para produtos de software e produtos intermediários. A qualidade do produto de
software deve ser hierarquicamente decomposta para um modelo de qualidade composto de
características e SUB características que podem ser usadas como um checklist de assuntos
relacionados à qualidade.

É praticamente impossível medir todas as SUB características de todas as partes de

um grande produto de software. Similarmente, não é prático medir qualidade em uso de todos
os possíveis cenários de tarefas do usuário. Recursos para avaliação precisam ser alocados
entre os diferentes tipos de medições dependendo dos objetivos do negócio e da natureza do
produto e do processo.

Este modelo de qualidade para qualidade dietas e indiretas, que categoriza a qualidade
de software em 6 características (funcionalidade, confiabilidade, usabilidade, eficiência,
manutenibilidade e portabilidade), que são subdivididas em SUB características. Para cada
característica e sub-característica, a capacidade do software é determinada por um conjunto
de atributos internos que podem ser medidos.

7
Medidas Direta: são o custo e o esforço aplicado ao desenvolvimento e manutenção do
software e do produto, quantidade de linhas de código produzido e o total de defeitos
registrados durante um determinado período de tempo, ou seja, são medidas realizadas em
termos de atributos observados (usualmente determinada pela contagem).

Exemplo:

 Custo do software;
 Esforço;
 Linha de código produzida;
 Velocidade de execução em segundos (de software);
 Memoria ocupado pelo software;
 Número de erros encontrados em um espaço de tempo.

Medidas Indiretas: são medidas obtidas a partir de outras métricas (derivadas), ou seja, são
medidas que possuem qualidades e funcionalidades do software.
Exemplo:

 Funcionalidade
 Confiabilidade.
 Usabilidade do software;
 Eficiência;
 Manutenibilidade;
 Qualidade de software;
 Portabilidade;

8
Funcionalidade: capacidade de fornecer funções que correspondam às necessidades
explícitas e implícitas do usuário quando o software é utilizado sob condições especificadas.

 Adequação: capacidade de fornecer um conjunto apropriado de funções para tarefas

específicas e objetivos do usuário.
 Acurácia: capacidade de fornecer o resultado com o grau de precisão desejado. ·
Interoperabilidade: capacidade de interagir com um ou mais sistemas.
 Segurança de Acesso: capacidade de proteger dados e informações de pessoas ou
sistemas não autorizados.
 Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições
similares relativas a funcionalidade.

Confiabilidade: capacidade do software manter seu nível de desempenho quando utilizado

em condições estabelecidas. ·

 Maturidade: capacidade de evitar defeitos no software. ·

 Tolerância a Falhas: capacidade de manter um nível de desempenho estabelecido em
caso de defeito no software.
 Recuperabilidade: capacidade de recuperar dados diretamente afetados no caso de
falhas. · Conformidade: capacidade de aderir a padrões, convenções, leis e prescrições
similares relativas a confiabilidade.

Usabilidade: capacidade que o produto tem de ser entendido, aprendido, utilizado e ser
atraente para o usuário.

9
  Inteligibilidade: capacidade do produto de fazer o usuário entender se o software é
adequado, e como ele pode ser usado para tarefas particulares.
 Aprendibilidade: capacidade que o produto deve ter de fazer o usuário entendê-lo. ·
Operacionalidade: capacidade que o produto deve ter para que o usuário possa
aprendê-lo e controlá-lo.
 Atratividade: capacidade do produto em ser atraente para o usuário. · Conformidade:
capacidade de aderir a padrões, convenções, leis e prescrições similares relativas a
usabilidade.

Eficiência: relacionamento entre o nível de desempenho do software e a quantidade de

recursos utilizados, sob condições estabelecidas.

 Comportamento em Relação ao Tempo: capacidade de fornecer tempos de resposta e

de processamento, além de taxas de transferência, apropriados, quando o software
executa suas funções, sob condições estabelecidas
 Comportamento em Relação aos Recursos: Capacidade de usar tipos e quantidades
apropriados de recursos, quando o software executa suas funções sob condições
estabelecidas.
 Conformidade: Capacidade de estar de acordo com normas e convenções relacionadas
à eficiência.

Manutenibilidade: esforço necessário para se fazer modificações específicas no software. ·

Analisabilidade: capacidade em diagnosticar deficiências e causas de defeitos.

 Analisabilidade: Capacidade de permitir o diagnóstico de deficiências ou causas de

falhas no software, ou a identificação de partes a serem modificadas.
 Modificabilidade: capacidade que o produto tem de receber modificações.
 Estabilidade: capacidade de evitar efeitos inesperados a partir de modificações.
 Testabilidade: capacidade de validar as modificações efetuadas no produto.
 Conformidade: capacidade de aderir a padrões e convenções relativas a
manutenibilidade.

Portabilidade: capacidade que o produto tem de ser transferido de um ambiente para outro. ·
Adaptabilidade: capacidade de ser adaptado em diferentes ambientes sem intervenção. ·

10
  Adaptabilidade: capacidade de ser adaptado para diferentes ambientes especificados,
sem necessidade da aplicação de outras ações ou meios além daqueles fornecidos para
essa finalidade pelo software considerado.
 Capacidade de Instalação: capacidade de ser instalado em um ambiente específico.
 Coexistência: capacidade que o produto tem de coexistir com outro software
independente em um ambiente comum, compartilhando recursos comuns.
 Capacidade de Substituição: capacidade de ser usado no lugar de outro produto de
software com o mesmo propósito no mesmo ambiente.
 Conformidade: capacidade de aderir a padrões e convenções relativas a portabilidade.

Qualidade de uso
É a visão do usuário da qualidade do produto de software quando é utilizado em
ambiente e contexto de uso estabelecidos. Ela mede o quanto os usuários podem alcançar
seus objetivos em um ambiente particular, em vez de medir as propriedades do software
propriamente dito. O nível de qualidade no ambiente dos usuários pode ser diferente daqueles
obtidos no ambiente dos desenvolvedores, devido as diferenças entre hardware e ambiente de
apoio. O usuário avalia somente aqueles atributos de software que são utilizados em suas
tarefas. Algumas vezes, atributos de software especificados por um usuário final durante a
fase de análise de requisitos, não mais correspondem às necessidades do usuário quando o
produto está em uso, devido a mudanças nos requisitos e a dificuldade de especificar
necessidades implícitas.

Efetividade: definida como sendo a capacidade do produto de software possui de possibilitar

ao usuário atingir metas especificadas com acurácia e completeza, em um contexto de uso
especificado.

11
Produtividade: definida como sendo capacidade do produto de software possui de
possibilitar aos usuários utilizar uma quantidade adequada de recursos em relação à
efetividade alcançada em um contexto de uso especificado.

Segurança: definida como sendo a capacidade do produto de software possui de oferecer

níveis aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ao
ambiente, em um contexto de uso especificado.

Satisfação: refere-se à capacidade do produto de software satisfazer usuários em um contexto

de uso especificado.

Métricas Orientadas ao tamanho (Linhas de Código)

Durante os 10 primeiros anos ou mais da indústria de software, iniciados por volta de

1947 a 1957, a maioria das aplicações eram muito pequenas. A grande maioria era menor que
1.000 linhas de código fonte. Todos foram escritos em linguagens de baixo nível e alguns
foram corrigidos em linguagem de máquina, o que é ainda mais difícil de trabalhar. A
primeira tentativa de medir a produtividade e a qualidade usando a métrica de "linhas de
código"(LOC – Line of Codes) foi na época de 1950 sendo bastante eficaz. A codificação
levou cerca de 50 por cento do esforço para construir uma aplicação, a depuração e testes
levaram cerca de 40 por cento e o restante levou apenas cerca de 10 por cento.

Antigamente a produtividade era baseada em linhas de código e a contagem de bugs

baseada em erros ou defeitos por 1.000 linhas de código (KLOC) sendo o padrão de métricas
e bastante eficaz. Isto ocorria porque os erros eram mais comuns e problemáticos nos
primeiros dias de codificação do software.

Entre 1957 e 1967, a situação começou a mudar drasticamente. As linguagens de

baixo nível começaram a ser substituídas por linguagens mais poderosas, como COBOL,
FORTRAN, APL e o tamanho das aplicações cresceram de 1.000 linhas de código para 100
mil linhas de código.

Estas mudanças nas linguagens de programação e tamanhos das aplicações

começaram a causar problemas para a métrica de linhas de código. Em 1967, a codificação
em si estava começando a cair abaixo de 30 por cento do esforço de desenvolvimento,
enquanto a elaboração de requisitos, especificações, planos e documentação começaram a se

12
aproximar de 40 por cento. Testar e depurar levou cerca de 30 por cento. Deste modo, alguns
aplicativos foram escritos em duas ou mais linguagens de programação diferentes. Em
meados da década de 1970 foram notados problemas mais sérios com a métrica LOC. É
razoável supor que as linguagens de programação de alto nível melhoraram a produtividade
do desenvolvimento e da qualidade.

Suponha que você tenha duas aplicações idênticas, sendo uma codificada em
Assembly e outra em COBOL. A versão em Assembly possui 10.000 linhas de código, mas a
versão em COBOL possui apenas 3.000 linhas de código. Quando você mede as taxas de
codificação, ambas as línguas foram codificadas a uma taxa de 1.000 linhas de código por
mês, mas uma vez que a versão em COBOL era apenas um terço do tamanho da versão em
Assembly, os ganhos de produtividade não podem ser vistos por meio de métricas LOC.

Presumimos que as especificações e documentos para ambas as versões levaram 5

meses de esforço. Assim, a versão em Assembly necessitou de 15 meses de esforço enquanto
a versão em COBOL precisaria de apenas 8 meses de esforço.

Se medir todo o projeto com métricas LOC, a versão em Assembly tem uma taxa de
produtividade de 666 linhas de código por mês enquanto a versão em COBOL tem uma
produtividade de 375 linhas de código por mês. Obviamente, os benefícios econômicos de
linguagens de programação de alto nível desaparecem quando a métrica LOC era utilizada.

Estes problemas incentivaram a pesquisa e desenvolvimento de novas métricas que

mediriam os sistemas independente do volume de código, produtividade e qualidade sem
distorção.

13
Métricas Orientadas à função (Analise de Pontos de Função)
A Análise de Pontos de Função (APF) é uma medida de dimensionamento de
significância de negócio claro.

Tornou-se pública por Allan Albrecht da IBM em 1979, a técnica APF quantifica as
funções contidas no software em termos que sejam significativos para os usuários do
software. A medida se relaciona diretamente com os requisitos de negócio que o software se
destina a abordar. Pode ser facilmente aplicada através de uma ampla variedade de ambientes
de desenvolvimento e ao longo da vida de um projeto de desenvolvimento. Medidas de outras
empresas, tais como a produtividade do processo de desenvolvimento e os custos por unidade
de suporte de software, também pode ser medida em pontos prontamente derivados.

A função é derivada de uma série de etapas. Usando um conjunto padronizado de

critérios básicos, cada uma das funções do negócio é um índice numérico de acordo com o
seu tipo e complexidade. Estes índices são somados para obter uma primeira medida de
tamanho o qual é então normalizado pela incorporação de um número de fatores relacionados
com o software como um todo. O resultado final é um número único, denominado o índice de
Ponto de Função que mede o tamanho e complexidade do produto de software

O Manual de Práticas de Contagem de Pontos de Função contém todas as definições e

regras necessárias para o uso da APF, disponibiliza exemplos mais comuns e aborda de
maneira geral o uso da técnica para que o processo seja aplicado em uma grande variedade de
situações.

A APF é possível medir a funcionalidade que o usuário solicita e recebe e medir o

desenvolvimento e a manutenção de software, independentemente da tecnologia utilizada
para implementação. A desvantagem de utilizar APF é de não medir diretamente o esforço, a
produtividade ou o custo. É exclusivamente uma medida de tamanho funcional do software.
Este tamanho, junto com outras variáveis, é que pode ser usado para derivar produtividade,
esforço e custo do projeto de software.

14
Razões para se medir um software

A medição é algo comum no mundo da engenharia. Mas para engenharia de software

está longe se ter uma medição padrão amplamente aceita e com resultados sem nenhum fator
subjetivo.

O uso da medição permite quantificar e por sua vez administrar mais efetivamente a
partir da análise de dados, mas saber escolher as métricas ideais para utilizar no projeto é um
aspecto que deve ser levado em consideração, pois o uso de métricas pode gerar diversas
dúvidas, principalmente quando se tenta medir algo que nunca foi medido no passado, que é
o caso da dos projetos de desenvolvimento de software

Certamente, um aumento de produtividade significativo será obtido quando

conseguirmos estabelecer uma sistemática de métricas adequada à mensuração de resultados
do desenvolvimento de software (e efetivamente usá-la).

Algumas razões de medir os softwares são

 Indicar a qualidade do produto;

 Avaliar a produtividade dos que desenvolvem o produto;
 Determinar os benefícios derivados de novos métodos e ferramentas de engenharia de
software;
 Formar uma base para as estimativas;
 Buscar oportunidades por fatoração;
 Ajudar na justificativa de aquisição de novas ferramentas ou de treinamentos
adicionais;

Exemplo de Métricas
Métricas de código-fonte foram criadas propostas desde que os primeiros conceitos de
engenharia de software surgiram. As métricas pioneiras foram rapidamente absorvidas pela
indústria, que as usa como frequência. Métricas de complexidade e tamanho são as mais

15
usuais, por exemplo LOC (linhas de Código) e seus derivados por exemplo: erros/LOC,
LOC/tempo.

Essas métricas são reconhecidamente limitadas quando usadas isoladamente. Mas

mesmo com o avanço da pesquisa em métricas desde então, a indústria continua usando as
mesmas métricas simplistas e de forma isolada.

A descrição dos conceitos de cada métrica selecionada, bem como, quando

encontrados os valores teóricos de referência de acordo com a literatura. Começando pelas
métricas de tamanho:

 LOC (número de linhas de código)

É a medida mais comum para o tamanho de um software. São contadas apenas as

linhas executáveis, ou seja, são excluídas linhas em branco e comentários. Para efetuar
comparações entre o sistema usando LOC, é necessário que ambos tenham sido feito na
mesma linguagem de programação e que o estilo esteja normalizado.

Os intervalos surgidos pelo LOC de uma classe (java e c++) são: até 70 (bom); entre
70 e 130 (regular); de 130 em diante (ruim).

 AM LOC (media do número de linhas de código por método)

Essa medida indica se o código esta bem distribuído entre os métodos. Quanto maior,
mais “pesados” são os métodos. É preferível ter muitas operações pequenas e de fácil
entendimento que poucas operações grandes e complexas.

Os intervalos surgidos são: até 10 (bom); entre 10 e 13 (regular); de 13 em diante

(ruim). Uma outra métrica derivada de LOC, ao invés do número medio por método, é a
MMLOC, número de linhas de código do maior método da classe.

 Número total de módulos ou classes

É outro indicador de tamanho, que é menos influenciada por linguagens de

programação, nível dos desenvolvedores e estilos de codificação. Assim, essa métrica pode
ser usada para comparar projetos escritos em diferentes linguagens de programação.

Ao considerar características como esforço de manutenibilidade, flexibilidade, compressão e

qualidade do código fonte, em geral, deve-se levar em consideração não só as métricas de
tamanho acima descritas, mas também indicadores estruturais, como descritos a seguir:

16
  NOA (número de atributos)

Calcula o número de atributos de uma classe. Seu valor mínimo é zero e não existe
um limite máximo para seu resultado. Uma classe com muitos atributos pode indicar que ela
tem muitas responsabilidades e apresentar pouca coesão, ou seja, deve estar tratando de
assuntos diferentes.

 NOM (número de métodos)

É usado para medir o tamanho das classes em termos das suas operações
implementadas. Essa métrica é usada para ajudar a identificar o potencial de reuso de uma
classe. Em geral, as classes com um grande número de métodos são mais difíceis de serem
reutilizadas, pois elas são propensas a serem menos coesas. Assim, é recomendado que uma
classe não tenha um número excessivo de métodos.

 NPA (número de atributos públicos)

Mede o encapsulamento. Os atributos de uma classe devem servir apenas as

funcionalidades da própria classe. Portanto, boas praticas de programação recomendam que
os atributos de uma classe devem ser manipulados através de método de acesso, os atributos
de uma classe devem ser privados, indicando que o número ideal para essa métrica é zero.

Os intervalos sugeridos para java e c++ são: ate 1 (bom); entre 1 a 9 (regular); de 9
em diante (ruim).

 NPM (número de métodos públicos)

Representa o tamanho de “interface” da classe. Métodos estão diretamente

relacionados as operações previstas na respetiva classe. Altos valores para essa métrica
indicam que uma classe tem muitos métodos e, provavelmente, muitas responsabilidades, o
que conflita com boas praticas de programação.

Os intervalos sugeridos para java e c++ são: até 10 (bom); entre 10 e 40 (regular); de
40 em diante (ruim).

 ANPM (media do número de parâmetros por método)

Calcula a media de parâmetro dos métodos de classe. Seu valor mínimo é zero e não
existe um limite máximo para seu resultado, mas um número alto de parâmetros pode indicar
que um método pode ter, mais de uma responsabilidade, ou seja, mas de uma função.

17
  DIT (profundidade de arvore de herança)

É o número de superclasses a classe ancestral de classe sendo analisada. São

contabilizadas apenas as superclasses do sistema, ou seja, as classes de bibliotecas não são
contabilizadas. Nos casos onde herança múltipla é permitida, considera-se o maior caminho
de classe ate uma das raízes da hierarquia. Quanto maior for o valor DIT, maior é o número
de atributos e métodos herdados, e, portanto, maior é a complexidade.

Os intervalos sugeridos são: ate 2 (bom); entre 2 e 4 (regular); de 4 em diante (ruim).

Entretanto, valores baixos indicam pouco reuso de código via herança. 1

Utilidade das métricas

O objetivo das métricas de software é a identificação dos principais parâmetros que
afetam o desenvolvimento de software. A necessidade das métricas de software teve maior
atenção quando se contactou a chamada “crise de software”. Outro fator que colaborou essa
necessidade foi a constatação de uma gerência ineficaz durante o desenvolvimento de maior
parte das soluções de software, uma vez que o desenvolvimento do software é complexo e
não se tinha medidas bem definido e variável para a avaliação do software e seu
desenvolvimento.

Entretanto, estimativas precisas e eficazes, planejamento e controle são aspetos

difíceis de se concretizar em conjunto. Assim, com as métricas de software, propõe-se uma
melhoria do processo de gestão com a identificação, medição e controle dos parâmetros
essenciais do software.

São consideradas boas matrizes aquelas que facilitam a medição dos parâmetros, há
riscos de se perder na enorme qualidade de métricas propostas pela literatura. O tratamento
de um grande volume de dados pode ser humanamente impossível. Portanto, é preciso definir
e justificar critérios adotados na escolha das métricas. É desejável que as métricas possuam as
seguintes características:

 O que a Métrica se propõe a medir deve ser claro;

 A métrica deve ser formalmente definida, seu valor deve estar atrelado ao objeto
medido, independentemente de quem (ou qual ferramenta) o obtenha;
 Deve ser possível obter seu valor rapidamente e a baixo do custo;

18
 A métrica deve medir efetivamente o proposto por la;
 Pequenas mudanças no software, por exemplo, não podem causar grandes mudanças
no valor obtido;
 O resultado da métrica deve ser independente da linguagem de programação utilizada;

19
Conclusão

Findado o trabalho, verificamos que a medição é o processo pelo qual números ou

símbolos são designados a atributos e entidades do mundo real da forma a descreve-los de
acordo com regras claramente definidas. O processo de desenvolvimento de software é um
trabalho colaborativo composto por diversos profissionais que fazem parte de uma cadeia de
desenvolvimento, composto por vários processos divididos em diversas fases.

Não existe ma etapa especifica que a medição de software possa atuar, não existe
apenas um profissional que fara uso de métricas de software. Então, existe uma gama de
possibilidades para as empresas agregarem valor a cadeia de desenvolvimento.

20
Bibliografia

 DEVMEDIA, O Processo de Medição de Software, recuperado em

https://www.devmedia.com.br/amp/o-processo-de-medicao-de-software-engenharia-de-
software-31/18730 aos 25 de abril de 2022.
 WIKIPEDIA, O Processo de Medição software, recuperado em
https://pt.wikipedia.org/wiki/M%C3%A9trica_de_software aos 25 de abril de 2022
 FILES, a qualidade de software, recuperado em
https://mmpsw.files.wordpress.com/2010/04/aula-12-qualidade-sw.pdf aos 26 de abril
de 2022.
 UNIVASF, os padrões de qualidade de software, recuperado em
http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula03_04.pdf aos
28 de abril de 2022.
 CPS, Métricas de Software e o Gerenciamento de qualidade
http://ric.cps.sp.gov.br/bitstream/123456789/577/1/20142S_IULIANOHugoGiovanni
_CD1945.pdf aos 29 de abril de 2022.
 MACORATTI, estimativas de tamanho de software, recuperado em
https://www.macoratti.net/net_est1.htm aos 30 de abril de 2022.
 1LIBRARY, Qualidade Interna e Qualidade Externa, recuperado em
https://1library.org/article/qualidade-interna-e-qualidade-externa-norma-iso-
iec.zkw2pvez aos 30 de abril de 2022.

21