1.1. Складність програмного забезпечення

Складність програмного забезпечення - зовсім не випадкова її властивість. Складність виникає через чотири основні причини:

• складністю реальної ПО, з якої виходить замовлення на розроблення програмного забезпечення (ПЗ);

• складністю керування процесом розроблення;

• необхідністю забезпечити достатню гнучкість програми;

• незадовільними способами опису поведінки великих дискретних систем.

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

Ця зовнішня складність зазвичай виникає через "нестикування" між користувачами системи і її розробниками: користувачі насилу можуть пояснити у формі, зрозумілій розробникам, що насправді потрібно зробити. Бувають випадки, коли користувач лише поверхнево уявляє, що йому потрібно від майбутньої ІС. Це в основному відбувається не через помилки з тієї чи іншої сторони; просто кожна з груп спеціалізується в своїй області, і їй бракує знання партнера. У користувачів і розробників різні погляди на суть проблеми, і вони роблять різні виведення про можливі шляхи їх рішення. Насправді, навіть якщо користувач точно знає, що йому потрібно, важко однозначно зафіксувати всі його вимоги. Зазвичай вони фіксуються на багатьох сторінках тексту, "розбавлених" небагатьма рисунками. Такі документи важко піддаються розумінню, вони відкриті для різних інтерпретацій і часто містять елементи, що відносяться швидше до дизайну, ніж до необхідних вимог розроблення.

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

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

• під супроводом розуміється усунення помилок;

• під еволюцією - внесення змін до системи у відповідь на вимоги, що змінилися, до неї;

• під збереженням - використання всіх можливих і неможливих способів для підтримки життя в „дряхлій” системі, що розпадається на частини.

На жаль, досвід показує, що істотний відсоток витрат на розроблення ІС витрачається саме на збереження.

Труднощі керування процесом розроблення. Основне завдання розробників полягає в створенні ілюзії простоти, в захисті користувачів від складності описуваного предмету або процесу. Розмір вихідних текстів ІС зовсім не входить до числа її головних переваг, тому ми прагнемо робити вихідні тексти компактнішими, видумуючи хитромудрі і потужні методи, а також використовуючи середовища розроблення вже існуючих проектів і програм. Проте нові вимоги для кожної нової системи неминучі, вони змушують створювати багато програм "з нуля", або намагатися по-новому використовувати вже існуючі. Всього 30 років тому програми об'ємом в декілька тисяч рядків на асемблері виходили за межі наших можливостей. Сьогодні звичайними стали ІС, розмір яких обчислюється десятками тисяч або навіть мільйонами рядків на мовах високого рівня. Жодна людина ніколи не зможе повністю зрозуміти таку систему. Навіть якщо ми правильно розкладемо її на складові частини, ми все одно отримаємо сотні, а інколи і тисячі окремих модулів. Тому такий об'єм робіт вимагає залучення команди розробників, в ідеалі як можна з меншою чисельністю. Але якою б вона не була, завжди виникатимуть значні труднощі, пов'язані з організацією колективної розробки. Чим більше розробників, тим складніше зв'язки між ними і тим складніша координація, особливо якщо учасники робіт географічно віддалені один від одного, що типово в разі дуже великих проектів. Таким чином, при колективному виконанні проекту головним завданням керівництва є підтримка єдності і цілісності розробки.

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

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

Всередині великої прикладної програми можуть існувати сотні і навіть тисячі змінних і декілька потоків керування. Повний набір цих змінних, їх поточних значень, поточної адреси і стеку виклику для кожного процесу описує стан прикладної програми в кожний момент часу. Оскільки виконання нашої програми здійснюється на цифровому комп'ютері, ми маємо систему з дискретними станами. Аналогові системи, такі, як рух кинутого м'яча, навпаки, є безперервними. Коли ми говоримо, що система описується безперервною функцією, ми маємо на увазі, що в ній немає прихованих сюрпризів. Невеликі зміни вхідних параметрів завжди викличуть невеликі зміни вихідних. З іншої сторони, дискретні системи за своєю природою мають кінцеве число можливих станів, хоча у великих системах це число відповідно до правил комбінаторики дуже велике. Ми прагнемо проектувати системи, розділяючи їх на частини так, щоб одна частина мінімально впливало на іншу. Проте переходи між дискретними станами не можуть моделюватися безперервними функціями. Кожна подія, зовнішня по відношенню до програмної системи, може перевести її в новий стан, і, більш того, перехід з одного стану в інший не завжди детермінований. За несприятливих умов зовнішня подія може порушити поточний стан системи через те, що її творці не змогли передбачити всі можливі варіанти. Уявимо собі пасажирський літак, в якому система керування польотом і система електропостачання об'єднані. Було б дуже неприємно, якби від включення пасажиром, що сидить на місці 17В, індивідуального освітлення літак негайно увійшов би у глибокого піке. У безперервних системах така поведінка була б неможливою, але в дискретних системах будь-яка зовнішня подія може вплинути на будь-яку частину внутрішнього стану системи. Це, вочевидь, і є головною причиною обов'язкового тестування наших систем; але річ у тому, що за винятком найтривіальніших випадків, всеосяжне тестування таких програм провести неможливо. І доки у нас немає ні математичних інструментів, ні інтелектуальних можливостей для повного моделювання поведінки великих дискретних систем, ми повинні задовольнитися розумним рівнем упевненості в їх правильності.

Наслідки необмеженої складності. Чим складніша система, тим легше її повністю розвалити. Будівельник навряд чи погодиться розширити фундамент вже побудованої 100-поверхової будівлі. Це не просто дорого: робити такі речі означає напрошуватися на неприємності. Але що дивно, користувачі програмних систем, не замислюючись, ставлять подібні завдання перед розробниками. Це, стверджують вони, всього лише технічне питання для програмістів.

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

Як ми можемо змінити ці справи? Оскільки проблема виникає в результаті складності структури програмних продуктів, ми пропонуємо спочатку розглянути способи роботи із складними структурами в інших областях. Насправді, можна навести безліч прикладів успішно функціонуючих складних систем. Деякі з них створені людиною, наприклад: космічний човник Space Shuttle, тунель під Ла-Маншем, великі фірми типу Microsoft або General Electric. У природі існують ще складніші системи, наприклад система кровообігу людини або рослина.