Metryki oprogramowania
Motywacja/Cel
Metryki oprogramowania to funkcje matematyczne, dzięki którym możliwa jest ilościowa (numeryczna) analiza kodu i ocena jego właściwości. Używamy ich w audycie, żeby ilościowo zobrazować lub uzasadnić jakościową ocenę oprogramowania.
Metoda
Istnieje niemal nieskończona ilość metryk oprogramowania 
Ponieważ, mimo istnienia narzędzi automatycznie obliczających metryki, ich analiza i interpretacja jest uciążliwa i czasochłonna, należy wybrać te, których wartości dadzą najwięcej informacji potrzebnych do osiągnięcia celu audytu.
Poniżej prezentuję kilka metryk, stosowanych w ocenie łatwości konserwacji i dalszego rozwoju systemu informatycznego.
- NCSS (Non Commenting Source Statements): jest to ilość linijek kodu w danej jednostce (jednym pliku, klasie, metodzie, funkcji), które nie są komentarzami. Zbyt wysoka wartość sugeruje, że badana jednostka kodu zawiera zbyt dużo funkcjonalności.
- Ilość metod w klasie i klas w pakiecie: jest to odpowiednik NCSS na wyższym poziomie organizacji kodu. Zbyt wysokie wartości najczęściej oznaczają nieodpowiedni projekt danego modułu i zbyt dużą ilość funkcjonalności w jednostce kodu. Naturalnie w językach oprogramowania, które nie organizują kodu w klasy i pakiety, należy stosować metryki do odpowiednich struktur charakterystycznych dla tego języka.
- CCN (Cyclomatic Complexity Number) opisuje, jak bardzo skomplikowany jest przepływ sterowania w programie. Jest to bardzo istotne dla testowania, eliminacji błędów oraz dalszego rozwoju oprogramowania. Im wyższy stopień skomplikowania, tym trudniej jest ocenić wpływ zmian w kodzie na jego funkcjonowanie.
- Zduplikowany kod w zasadzie nie powienien istnieć. Zduplikowana implementacja logiki wymaga w przypadku wprowadzania zmian odnalezienie, modyfikacji i testowania kodu w wielu miejscach. Zasada DRY (Don’t Repeat Yourself) mówi, że powinno się unikać powtórzeń, aby zapewnić zachowanie konsystencji w aplikacji.
- Cykliczne zależności między komponentami systemu (na różnych poziomach abstrakcji) wskazują na bardzo silne powiązania pomiędzy nimi. Oznacza to, że zmiany w jednym komponencie mogą mieć nieprzewidywalne efekty w zupełnie innych miejscach systemu (ripple effect), co najczęściej łączy się z podwyższonymi kosztami eliminacji błędów i testowania. Cykle często wynikają z nieodpowiedniego podziału funkcjonalności na warstwy lub moduły.
Przykład
Jako przykład poniżej prezentuję macierz zależności pomiędzy warstwami w badanym systemie. Plusy poniżej diagonali pokazują dopuszczalne zależności pomiędzy warstwami. W idealnym przypadku, powinny one jednak istnieć tylko na polach tuż pod diagonalą. Z macierzy widać też, że warstwy abs i sss leżą na jednym poziomie. Liczby powyżej diagonali pokazują ile razy zostały złamane zasady separacji warstw.
