Складність проблемної області

Проблеми, що ми намагаємося розв’язати у програмному забезпеченні, часто включають елементи неминучої складності, в котрій ми знаходимо міріади конкуруючих, можливо несумісних вимог. Розглянемо вимоги для електронної системи багатомоторного літака, системи перемикання стільникового телефону або автономного робота. Пряма функціональність подібних систем достатньо складна до розуміння, але додамо тепер всі (часто неявні) не функціональні вимоги, такі як практичність, продуктивність, вартість, живучість, надійність. Ця нестримна зовнішня складність є тим, що спричиняє свавільну складність, про яку писав Брукс.
Ця зовнішня складність звичайно виникає з розірвання зв’язку між користувачами системи та її розробниками: користувачі загально вважають дуже важким надати точний вираз власних потреб у формі, яку розробники можуть зрозуміти. У деяких випадках користувачі можуть мати лише приблизні уявлення про те, чого вони хочуть від програмної системи. Це не стільки провина або користувачів, або розробників системи; скоріше це відбувається через те, що кожна група в основному потребує досвіду у області іншої. Користувачі та розробники мають різні точки зору на природу проблеми та роблять різні припущення відносно природи рішення. Дійсно, навіть якщо користувачі мають чудове знання власних потреб, ми на цей час маємо небагато інструментів для точного оволодіння цими вимогами. Загальний шлях щоб виразити вимоги є великі томи тексту, що іноді супроводжуються деякими кресленнями. Подібні документи є складними для розуміння, відкриті для різноманітних інтерпретацій та занадто часто містять елементи, що є скоріше дизайном, ніж істотними вимогами.
Подальшим ускладненням є те, що вимоги до програмної системи часто змінюються під час її розробки, головним чином через те, що саме існування проекту програмної розробки змінює правила проблеми. Розгляд ранніх виробів, таких як проектні документи та прототипи, та потім використання системи як тільки її встановлено та задіяно є посилюючою функцією, що заохочує користувачів краще розуміти та ясно виражати їхні дійсні потреби. У той самий час, цей процес допомагає розробникам оволодіти проблемною областю, дозволяючи їм задати кращі питання, що освітлюють темні кутки бажаної поведінки системи.
(Підпис до рисунку) Задачею команди розробки програмного забезпечення є створення ілюзії простоти.
Через те, що великі програмні системи є капітальними вкладеннями, ми не можемо дозволити перероблювати існуючу систему кожного разу, коли вимоги до неї змінюються. Заплановано це чи ні, системи прагнуть еволюціонувати через деякий час, обумовлюючи те, що часто невірно називають утриманням програмного забезпечення. Щоб бути точнішим, це є утримання, коли ми виправляємо помилки; це є еволюцією, коли ми відповідаємо на зміну вимог; це є збереженням, коли ми продовжуємо використовувати надзвичайні зусилля щоб залишити частину програмного забезпечення, що застаріле та приходить в занепад, у дієвості. Нажаль, реалії вирішують, що непомірний відсоток ресурсів розробки зайнятий у збереженні програмного забезпечення.
[1]