8.1.8. Супроводження програми

Розробку програми завершено. Далі йде процес використання чи експлуатації програми, який передбачає:

• передачу і копіювання програми, внаслідок чого можуть з’явитися помилки, а значить, їх потрібно виявити і виправити;

• коригування програми в цілях збільшення швидкодії;

• коригування програми при зміні вимог до програми, сформульованих у постановці задачі;

• коригування програм при виявленні помилок, які не виявлені на тестових даних;

• удосконалення програми;

• коригування програми (якщо вона працює у комплексі з іншими програмами) при спільній експлуатації чи при зміні інших програм комплексу;

• тестування програми безпосередньо перед використанням;

• адаптацію програми при зміні компонентів обчислювальної системи;

• коригування програми з метою полегшення супроводження програми (корислива мета програміста, і, якщо всі коригування виконуються за рахунок замовника, то в останньому випадку умовити його заплатити дуже важко).

Всі перелічені дії забезпечують підтримку програми в робочому стані та складають поняття супроводження програми. Як свідчить практика, витрати на розробку і супроводження програмного забезпечення розподіляються по етапах нерівномірно і значною мірою залежать від того, на якій стадії виявлено помилки, оскільки чим пізніше помилку виявлено, тим більші витрати на її виправлення. При проектуванні програми з’являється до 64% помилок, при програмуванні — 36%. Однак при налагодженні програм виявляють тільки 40% помилок, решта виявляється вже на стадії приймання і супроводження програми.

Розвиток мов і технологій програмування з самого початку мали полегшити працю програмістів. Коли з’ясувалося, що користувачами програм можуть бути професіонали з прикладних галузей, а не тільки програмісти, змінилася ідеологія програмування, постали інші вимоги до програм: це й дружній інтерфейс, но­вий зміст понять мобільності та надійності і взагалі програмування без програмістів. Тобто програмно-машинні комплекси левову частину роботи з розробки програм переймають на себе, отже, на долю людини залишається «зв’язати» готові модулі в єдину програму, як скласти споруду з блоків-кубиків, але споруда більше схожа на піраміду перевернуту догори основою. Ясно, що надійність таким чином покращитися не могла.

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

Крім того, неабиякого значення набуває відповідь на запитання: для кого призначена програма — для власного використання чи на продаж? Бо в першому випадку вона повинна бути зручною, надійною, економічною, раціональною, довговічною, призначеною для вирішення проблеми; у другому — програма перш за все товар, вона має окупити витрати та приносити прибуток. Її користувач — перш за все покупець, і треба зробити так, щоб він не просто купив програму, а був зацікавлений купувати її нові версії або замінити її новою, більш привабливою програмою.

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

У корпорації Cutter була розроблена нова технологія економного створення програмного забезпечення (ЕСПЗ), аналіз якої показав, що вона дозволяє втричі швидше реалізувати проект, зробити його втричі дешевше та припуститися втричі меншої кількості помилок.

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

Було розроблено 12 принципів ЕСПЗ:

0.  Найвищий пріоритет — задоволення вимог замовника, виявлення його конкретних потреб, підтримка зворотного зв’язку з ним. Можливості продукту, про які клієнт не згадував, є непотрібними, отже недоцільно витрачати на них зусилля (як з’ясувалося, близько 45% можливостей більшості програмних продуктів користувачі ніколи не використовують).

1.  Треба так скоординувати властивості продукту, щоб вони задовольняли клієнта в замовлений термін і в межах встановленого бюджету.

2.  Необхідною є активна участь замовника в роботі для організації максимально швидкої адаптації до зміни вимог.

3.  Концентрація командних зусиль, поєднання різноманітних вмінь розробників.

4.  Всі методології розпочинаються з визначення вимог до проекту. Їх зміна постійно контролюється. В ЕСПЗ прийнято вважати цей процес неперервним, тому бажано передбачати, які зміни можуть виникнути та як пристосувати до них проект.

5.  Бажано створювати глобальні рішення, щоб програмний продукт можна було використовувати в різних компаніях, ринках, продуктах.

6.  Програмний продукт краще зібрати, використовуючи готові компоненти та шаблонні рішення, ніж конструювати, або купити його, ніж побудувати.

7.  Краще сьогодні мати на 80% готовий продукт, ніж завтра готовий на 100%, бо замовник здебільшого згоден пожертвувати функціональними можливостями продукту заради скорішого його отримання.

8.  Можливості продукту та обсяги паперової роботи з ним повинні бути мінімальними в розумних межах.

9.  Необхідно перш за все створити технологію роботи, спочатку визначивши цілі, а вже потім — способи їх вирішення.

10.  Розвиток продукту — це збільшення його можливостей, а не розміру, при цьому важливо визначити критичні властивості продукту, а саме ті, які впливають на бізнес-процеси користувача.

11.  ЕСПЗ найкраще підходить для розробки прикладних програм.