Istnieją różne rodzaje jakości, które można mierzyć w oprogramowaniu, np. Przydatność do określonego celu (np. Zastosowanie końcowe), łatwość konserwacji, wydajność. Niektóre z nich są nieco subiektywne lub specyficzne dla danej dziedziny (np. Dobre zasady projektowania GUI mogą być różne w różnych kulturach lub zależą od kontekstu użytkowania, w zależności od użycia w celach militarnych i konsumenckich).
Interesuje mnie głębsza forma jakości związana z siecią (lub wykresem) typów i ich wzajemnymi powiązaniami, to znaczy do jakich typów odnosi się każdy typ, czy istnieją wyraźnie identyfikowalne klastry wzajemnych połączeń odnoszące się do właściwie architektura wielopoziomowa, lub odwrotnie, istnieje duża „kula” odniesień typu (kod „monolityczny”). Również rozmiar każdego typu i / lub metody (np. Mierzony ilością kodu bajtowego Java lub .Net IL) powinien dać pewne wskazanie, gdzie duże złożone algorytmy zostały zaimplementowane jako monolityczne bloki kodu zamiast być rozkładane na łatwiejsze w zarządzaniu / utrzymywaniu kawałki.
Analiza oparta na takich pomysłach może być w stanie obliczyć wskaźniki, które są co najmniej wskaźnikiem jakości. Podejrzewam, że dokładne progi / punkty decyzyjne pomiędzy wysoką a niską jakością są subiektywne, np. Ponieważ przez łatwość utrzymania rozumiemy przez to możliwość utrzymania przez ludzkich programistów, a zatem rozkład funkcjonalny musi być zgodny z tym, jak działają ludzkie umysły. Jako taki zastanawiam się, czy kiedykolwiek może istnieć matematycznie czysta definicja jakości oprogramowania, która wykracza poza wszelkie możliwe oprogramowanie we wszystkich możliwych scenariuszach.
Zastanawiam się również, czy to niebezpieczny pomysł, że jeśli obiektywne wskaźniki jakości staną się popularne, presja biznesowa spowoduje, że programiści zastosują te wskaźniki kosztem ogólnej jakości (tych aspektów jakości, które nie są mierzone przez proxy).
Innym sposobem myślenia o jakości jest z punktu widzenia entropii. Entropia to tendencja systemów do zmiany stanu z uporządkowanego na nieuporządkowany. Każdy, kto kiedykolwiek pracował nad prawdziwym światowym projektem oprogramowania o średniej i dużej skali, z pewnością doceni stopień, w jakim jakość bazy kodu z czasem spada. Presja biznesowa generalnie powoduje zmiany, które koncentrują się na nowej funkcjonalności (z wyjątkiem sytuacji, gdy sama jakość jest głównym punktem sprzedaży, np. W oprogramowaniu awionicznym), a także obniżaniu jakości poprzez problemy z regresją i funkcjonalność „klaksonu”, gdzie nie pasuje dobrze perspektywa jakości i utrzymania. Czy możemy zmierzyć entropię oprogramowania? A jeśli tak, to w jaki sposób?