Існують різні типи якості, які можна виміряти в програмних продуктах, наприклад, придатність за призначенням (наприклад, кінцеве використання), ремонтопридатність, ефективність. Деякі з них є дещо суб'єктивними або доменними (наприклад, хороші принципи дизайну графічного інтерфейсу можуть бути різними в різних культурах або залежати від контексту використання, думаю, військові та споживчі).
Мене цікавить більш глибока форма якості, пов’язана з мережею (або графіком) типів та їх взаємопов'язаністю, тобто про те, до яких типів відноситься кожен тип, чи є чітко ідентифіковані кластери взаємозв’язку, що належать належним чином багатоярусна архітектура, або, навпаки, є великий «куля» посилань на тип («монолітний» код). Також розмір кожного типу та / або методу (наприклад, вимірюється в кількості байтового коду Java або. Net IL) повинен дати деяку вказівку на те, де великі складні алгоритми були реалізовані як монолітні блоки коду, а не розкладатися на більш керовані / ремонтовані шматки.
Аналізи на основі таких ідей можуть бути в змозі обчислити показники, які є принаймні проксі-сервісом якості. Точний поріг / точки прийняття рішення між високою та низькою якістю, я б підозрював, є суб'єктивним, наприклад, оскільки під ремонтом ми маємо на увазі ремонтопридатність людських програмістів, і, отже, функціональне розкладання повинно бути сумісним з тим, як працює людський розум. Мені цікаво, чи може колись бути математично чисте визначення якості програмного забезпечення, яке перевершує все можливе програмне забезпечення у всіх можливих сценаріях.
Мені також цікаво, чи небезпечна ця ідея, що якщо об'єктивні проксі-сервери для якості стануть популярними, тиск у бізнесі змусить розробників дотримуватися цих показників за рахунок загальної якості (ті аспекти якості, які не вимірюються проксі-серверами).
Інший спосіб мислення про якість - з точки зору ентропії. Ентропія - це тенденція повернення систем із упорядкованих до невпорядкованих станів. Кожен, хто коли-небудь працював над реальним програмним проектом середнього та великого масштабу, оцінить ступінь, до якого якість кодової бази має тенденцію до погіршення з часом. Тиск у бізнесі, як правило, призводить до змін, що зосереджуються на новій функціональності (за винятком випадків, коли саме якість є принциповою точкою продажу, наприклад, у програмному забезпеченні авіоніки), а також погіршення якості через проблеми регресії та функціональність "взуття", де це не добре підходить від перспектива якості та обслуговування. Отже, чи можна виміряти ентропію програмного забезпечення? А якщо так, то як?