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

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

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

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

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

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

Метрики за редове код

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

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

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

Качество на кода според редовете код в C++

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

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

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

Цикломатична сложност на МакКейб

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

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

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

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

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

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

Метрики на Халстед

Метриките на Халстед са едни от най-старите метрики и са въведени през 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}}$ – емпирични проучвания показват, че броят грешки зависи от усилието за имплементиране