Якість ПЗ: вісім міфів

Джеффрі Воас

Складається враження, що комп'ютерне співтовариство цілком задоволена нинішнім станом справ c якістю ПО: мало не те, що нових ідей, та й просто ентузіазму. Нам залишається лише згадувати про ті далекі часи, коли спеціалізуватися в галузі управління якістю ПЗ було дуже престижно, і на візитці часто зустрічалися написи типу: "software safety evangelist".

Невже вже можна спочивати на лаврах? Зрештою, ні одна з основних проблем створення якісного ПЗ так і не вирішено! Сьогодні перед нами стоять все ті ж проблеми, що й десять років тому. Я хочу звернути увагу колег на деякі загальноприйняті рішення, щоб не сказати панацеї (silver bullets, як після знаменитої книги Брукса стало прийнято це позначати у професійній літературі), які, власне, і створюють ілюзію руху вперед. Мені здається, що насправді ці рішення носять міфологічний характер. Чи не претендуючи на повноту, я виділив вісім таких міфів.

Удосконалення процесу та моделі зрілості розробки ПЗ

Міф, пов'язаний з цією тенденцією сучасної програмної інженерії, полягає в наступному: вимір зрілості процесу розробки в деякій організації еквівалентно вимірювання якості ПЗ, що ця організація виробляє. Звідси неявно випливає, що побудова більш зрілого процесу розробки забезпечує створення більш зрілого (більш якісного) ПЗ.

Само по собі вдосконалення процесу розробки, так само як і ранжування колективів за рівнем професіоналізму (особливо по стандартизованої методикою типу CMM) безумовно похвально. Однак практика доводить, що припущення про однозначну зв'язку між офіційно засвідченими рейтингами зрілості процесів і якістю виробленого ПО помилково. На жаль, у комп'ютерній індустрії цей міф отримав надзвичайно широке поширення.

Формальні методи

Цей міф можна вважати в деякій мірі окремим випадком попереднього. Він говорить, що саме формальні методи здатні стати рушійною силою "удосконалення процесів", зокрема, полегшити рішення проблем безпеки та надійності ПЗ. На ділі формальні методи - це не більше ніж математично сувора демонстрація наявності у розробляється ПО деяких бажаних властивостей абстрактної природи. Формальні методи дозволяють робити висновку про відсутність логічно некоректного, погано визначеного та рассогласованного поведінки, яка в принципі може бути присутнім в специфікації.

Звичайно, впровадження формальних методів має сенс, однак необхідно чітко розуміти, що можливості їх застосування досить обмежені. Не кажучи вже про те, що використовувати формальні методи складніше, і це обходиться недешево.

Мови і об'єктно-орієнтоване проектування

Цей міф встановлює, що, змінивши мовну або проектну парадигму, можна вирішити ті проблеми розробки, з якими ми не могли впоратися, використовуючи існуючі мови або стратегії проектування. Однак заміна однієї мови програмування іншим, більш сучасним, навряд чи допоможе вирішити проблеми, не безпосередньо пов'язані з особливостями застосовуваного мови. А саме з таким завданням звичайно і доводиться стикатися.

Сучасні програмні системи стають усе складніше. Для їх реалізації пропонується використовувати знову ж таки все ускладнюються мови проектування і програмування (які містять стільки можливостей, що мало хто з фахівців здатний коректно застосовувати їх). Особливо показові в цьому відношенні стали зараз дуже популярними об'єктно-орієнтовані мови. Поняття та концепції, що лежать в основі об'єктно-орієнтованої парадигми, досить складні і потребують дуже акуратному зверненні. Недостатньо коректне використання цієї парадигми часто-густо призводить до виникнення серйозних проблем, що дає підстави для зовні парадоксального висновку: створювати якісне ПЗ для багатьох легше з використанням "старих" мов, наділених більш скромними можливостями.

До того ж сучасні парадигми проектування, в основі яких лежать принципи абстракції (такі, як інкапсуляція), роблять процес тестування на системному рівні більш складним і менш ефективним. Відомо, однак, що чим важче тестувати, тим менше шансів отримати у результаті високоякісне ПЗ.

Метрики і виміру

Даний міф стверджує можливість умовиводів, "добре" чи ПЗ розроблено, на основі цифрових оцінок, які відносяться як безпосередньо до коду, так і до процесу його розробки. Але чи можна точно визначити, що означає "гарний" код?

Для більшості фахівців код хороший тоді, коли він реалізує обчислення необхідної функції бажаним способом (наприклад, коректно і з обмеженнями, накладаються виконанням у реальному часі). При цьому поняття "хороший" не пов'язано прямо із тем, як код структурований і тим більше з тим, як він виглядає - вона перш за все відноситься до семантиці функції, реалізованої даними фрагментом коду.

Так як структурні методи семантику не вимірюють, вони не можуть показати, наскільки код гарний. У ще більшою мірою це стосується метрика процесів. Одне час вважалося, що метрики можуть вимірювати семантику, але це виявилося не так. До того ж, як з'ясувалося, вже зібрані метрики не так просто інтерпретувати в практичних термінах, що необхідно для реального поліпшення процесу розробки. Цікаво, що метрики коду більше підходять для оцінки якості процесу розробки, ніж самого коду.

Важливо також розуміти, що метрики забезпечують опосередковану міру, взагалі кажучи, неізмеряемих властивостей. Наприклад, неможливо виміряти "тестового" і "сопровождаемость" програми. Зате легко встановити кількість рядків коду. Ясно, що програма довжиною в один рядок буде мати кращі характеристики тестують і сопровождаемості в порівнянні з програмою в мільйон рядків, і метрика "число рядків коду" це покаже. Краще слідувати емпіричному правилу (для багатьох неочевидним): метрики не можуть дати універсальних рецептів побудови якісного ПЗ; вони забезпечують лише напрям подальшого пошуку рішень.

Стандарти ПЗ

Багато вважають, що якщо є стандарт, то для отримання якісного ПО достатньо просто чітко йому слідувати. Корені цього міфу - у необгрунтованому перенесення в програмну інженерію практики, що склалася в традиційних індустріях. У останні 20 років ми спостерігаємо прямо-таки експонентний зростання числа різноманітних стандартів.

Організації, займаються створенням та розповсюдженням стандартів (ISO, IEEE, IEC), поки не дуже досягли успіху в об'єктивній оцінці їх переваг з точки зору практики розробки. Наприклад, було б непогано хоча б приблизно знати, що якщо слідувати стандарту "A" будуть потрібні додаткові витрати на величину "B", але при цьому ви придбаєте вигоди величиною "C". Якби кожен стандарт супроводжувався методикою оцінки вигод його використання для деякого типового проекту, то стандарти було б набагато легше порівнювати і адаптувати.

Мої основні сумніви, що стосуються стандартизації, такі:

стандарти рідко з'являються вчасно: як правило, процес їх створення розтягується на так довго, що до моменту публікації вони втрачають актуальність;

побутує думка (і вона не позбавлена підстав), що іноді під приводом боротьби за якість стандарти вводяться сильними світу цього як засобу конкурентної боротьби;

стандарти не містять методик кількісної оцінки вигод від їх застосування;

НЕ завжди зрозуміла взаємозв'язок вводиться стандарту з кращими зразками практики та з іншими стандартами.

Безумовно, слідувати стандартам в тій чи іншій мірі необхідно, але розробка програмно - Не та область, де це гарантує поліпшення якості продукту в кожному конкретному випадку.

Тестування

Тільки неофіти від програмування вірять міфу, що на етапі тестування можна виявити і вирішити всі накопичені в процесі розробки проблеми. За даними керівника фірми Software Productivity Research К. Джоунса імовірність благополучного завершення проблемного проекту не перевищує 15%. Висновок очевидний: якщо розробники очікують фази тестування в надії виправити виявлені його недоліки, шансів на порятунок такого проекту дуже мало.

CASE

Суть наступного міфу (до якого я особливо небайдужий) полягає в тому, що програмування специфікації з використанням діаграмного або візуального мови гарантує більш високу якість і надійність коду. CASE-засоби переживали бум на початку 90-х, коли на короткий час набув поширення міф про вигоди автоматичної генерації коду з візуальної специфікації. Прихильники цього підходу виходили з того, що людина робить менше помилок, малюючи картинки. Практика, проте, підтвердила тільки те, що з некоректних картинок можна отримати некоректний код.

Тотальне Управління Якістю

Останній міф пов'язаний з тенденцією регламентувати всі можливі аспекти розробки ПЗ. Тотальне Управління Якістю (Total Quality Management - TQM) - це дуже показовий приклад втілення даного міфу. У традиційних галузях індустрії дотримання чітко визначеної методики управління якістю дійсно приносить успіх. Однак промислове програмування залишається суто творчим процесом зі значним елементом невизначеності, і пряме додаток відпрацьованих в інших умовах методик представляється помилковим.

Висновок - Більше прагматизму!

Саме усвідомлення малої практичної цінності популярних колись напрямків зробило багатьох практиків скептиками, не вірять в нові ідеї. Це небезпечно, тому що так можна дійти до неприйняття дійсно корисних ідей, не кажучи вже про більш приземлені речі, таких як скорочення фінансування дослідницьких робіт.

Перераховані ідеї втратять міфологічний статус і дійсно забезпечать реальну допомогу в створення якісного та надійного ПЗ тільки в тому випадку, якщо будуть піддані критичному аналізу. Крім того, вони повинні використовуватися не за окремо, а в поєднанні один з одним

Однак я повинен ще раз повторити вже не одного разу висловлене попередження: дослідникам не слід пропонувати свої розробки практикам до того, як будуть отримані переконливі докази їх дійсної корисності. Важливо, щоб при цьому розглядалися і питання, пов'язані з обмеженнями нових технологій і вартістю їх адаптації.

У кожного з нас - своя роль. Практики повинні більш чітко пояснювати дослідникам свої реальні проблеми, використовуючи для цього комп'ютерну і пресу, і трибуни наукових конференцій. Дослідники повинні демонструвати ефективність своїх ідей на реальних, а не іграшкових завдання, і тільки потім виходити з ними на ринок.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/