Софтуерни метрики

от Уикипедия, свободната енциклопедия
Направо към: навигация, търсене

Метриките на даден софтуер са големина, която отразява качеството на отделните части от програмата посредством числена стойност. [1]

Метриките се делят на:

  • Метрики за измерване на процеса на развитие на софтуер
  • Метрики за измерване на наличните ресурси
  • Метрики за оценка на софтуерния продукт. Те се делят на

Обектноориентираните метрики вземат под внимание взаимовръзките между програмните елементи (класове, методи).

Традиционните метрики се делят на метрики за измерване големината и сложността на програмата и метрики за измерване на програмната структура. Най-важните метрики за измерване големината и комплексността на програмата са метриките за редове код и метриките на Халстед. Цикломатичната сложност на МакКейб е най-известната метрика за измерване на програмната структура.

Метрики за редове код[редактиране | edit source]

Измерването на редовете код (LOC, Lines of Code) е най-разпространеният начин за количественото измерване на сложността на софтуер.

  • LOCphy – общ брой редове (physical lines)
  • LOCpro – брой програмни редове (декларации, дефиниции, директиви и код) (program lines)
  • LOCcom – брой редове с коментари (commented lines)
  • LOCbl – брой празни редове (blank lines)

Стойностите на метриките определят качеството на кода квантитативно различно в зависимост от езика за програмиране.

Качество на кода според редовете код в C++[редактиране | edit source]

Според Кулман и Ламберц[2] дължината на една функция трябва да е между 4 и 40 реда код. Минималната дължина е един ред за дефиницията на функцията, два реда за отварящата и затварящата скоба за начало и край на функцията, и един ред код. Според тях дадена функция с дължина над 40 реда код най-вероятно съдържа действия за повече от една функция в себе си.

Увеличаването на дължината на функциите намалява четимостта им. Според Кулман и Ламберц дължината на един файл трябва да е между 4 и 400 реда. Минималното съдържание на един файл може да е една функция, затова минималната им дължина е 4 реда. Файлове с дължина над 400 реда (10 до 100 функции) в повечето случаи са твърде дълги, за да бъдат разбрани добре.

Коментарите трябва да представляват между 30 и 75 процента от редовете в един файл. В случай, че са по-малко файлът е или недостатъчно документиран, или прекалено тривиален. В случай, че са повече, файлът губи смисъла си на програмен, а представлява по-скоро документация.

Цикломатична сложност на МакКейб[редактиране | edit source]

Цикломатичната сложност на МакКейб е въведена от Томас МакКейб през 1976 г. Тя е най-разпространената метрика и е независима от езика за програмиране.

Цикломатичното число на МакКейб, v (G), показва сложността на кода спрямо действията в него. За код, съдържащ единствено последователни команди стойността на v (G) е 1.

За дадена функция v (G) е равно на броя разклонения във функцията минус едно. Разклонения се предизвикват както от оператори за разглеждане на случаи като if и switch-case, така и от цикли и команди за хващане на грешки (try-catch). Колкото по-голямо е числото, толкова повече разклонения има в кода и толкова по-сложна е функцията за разбиране и тестване.

Качество на кода според цикломатичната сложност на МакКейб[редактиране | edit source]

Кулман и Ламберц препоръчват цикломатичната сложност на дадена функция да е под 15. Това отговаря на поне 15 възможни развития на една функция. Такъв брой възможности са трудни за идентифициране и тестване. Според тях абсолютно максималната цикломатична сложност на МакКейб трябва да е 100.

Цикломатичната сложност на един файл е сумата от цикломатичните сложности на функциите в него.

Метрики на Халстед[редактиране | edit source]

Метриките на Халстед са едни от най-старите метрики и са въведени през 1977 г. от Морис Халстед като квантитативна мярка за сложността на дадена програма. Те се основават на броя оператори и операнди в един модул.

Метриките на Халстед интерпретират програмния код като последователност от оператори и операнди. Използват се за определяне на качеството на кода откъм възможност за поддръжка. Съществуват следните метрики на Халстед:

  • N – дължина на програмата (program length)
  • n – големина на речника (vocabulary size)
  • V – обем на програмата (program volume)
  • D – сложност на програмата (difficulty level)
  • L – ниво на програмата (program level)
  • E – усилие за имплементиране (effort to implement)
  • T – време за имплементиране (implementation time)
  • B – брой бъгове (number of delivered bugs)


  • N = N1 + N2 - дължината на програмата е равна на сумата от броя на операторите и операндите


  • n = n1 + n2 - големината на речника е равна на сумата от броя на различните оператори и операнди


  • V = N \cdot log_{2}(n)
обемът на програмата е равен на дължината на програмата, умножена по логаритъм от големината на речника при основа 2
обемът на програмата трябва да е между 20 и 1000. При стойност над 1000 най-вероятно функцията върши прекалено много неща и може да се раздели на няколко функции
обемът на един файл трябва да е между 100 и 8000.


  • D = \frac{n1}{2} \cdot \frac{N2}{n2} - сложността на програмата е пропорционална на съотношението от дължина на програмата и големина на речника. Ако един операнд се ползва повече пъти в програмата, той е по-вероятно да причини грешка.


  • L = \frac{1}{D} - нивото на програмата е реципрочната стойност на сложността. Програма с ниско ниво е по-вероятно да съдържа грешки.


  • E = V \cdot D - усилието за имплементиране е пропорционално на обема на програмата и сложността ѝ.


  • T = \frac{E}{18} - емпирични проучвания показват, че времето за имплементиране на програма е равно на времето за разбирането ѝ и е равно на 1/18-част от усилието за имплементирането ѝ в секунди.


  • B = \frac{E^\frac{2}{3}}{3000} - емпирични проучвания показват, че броят грешки зависи от усилието за имплементиране


Източници[редактиране | edit source]

  1. ((en)) IEEE Std 1061-1992 IEEE Standard for a Software Quality Metrics Methodology -Description
  2. ((de)) Komplexität und Qualität von Software