2.1 Особливості створення програмного продукту

2.1.1. Принципи роботи з вимогами до програмного забезпечення. Проблематика проектування.

Згідно статистичних досліджень групи Стендіша (Standish Group), в США щорічно витрачається більше 250 млрд. доларів на розробку додатків інформаційних технологій в рамках приблизно 175000 проектів. Причому 31 % проектів буде зупинено до завершення. Затрати на 52,7 % проектів складуть 189 % від початкової оцінки вартості. Американські компанії та управлінські організації потратять 81 млрд. доларів на програмні проекти, які так і не будуть завершені. Ці ж організації заплатять додатково 59 млрд. доларів за програмні проекти, які завершаться, але значно перевищать заплановано відведений на них час.

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

• нестача початкової інформації від клієнта – 13 % всіх проектів;

• неповні вимоги і специфікації – 12 % проектів;

• зміна вимог і специфікацій – 12 % всіх проектів.

Звичайно проект може потерпіти невдачу через нереалістично складеного графіку чи неправильно розподіленого часу (4 % проектів), нераціональний підбір персоналу і виділення ресурсів (6 %), невідповідність технологічних навиків (7 %), а також по іншим причинам. Якщо вважати, що наведені цифри представляють реальний стан в галузі, то по крайній мірі, невдачі третьої частини проектів пояснюються причинами, безпосередньо пов’язаними зі збором і документуванням вимог, а також з управлінням ними.

Не дивлячись на те що більшість проектів дійсно перевищують відведений час і бюджет, виявилось, що біля 9 % проектів крупних компаній були завершені вчасно і в межах бюджету; аналогічного успіху вдалось досягнути у 16 % проектів малих компаній. Виникає очевидне запитання: «Які основні фактори успіху в цих проектах?» Згідно проведеного дослідження трьома найбільш важливими факторами були:

• підключення до розробки користувача – 16 % всіх успішних проектів;

• підтримка зі сторони виконавчого керівництва – 14 % всіх успішних проектів;

• чітка постановка вимог – 12 % всіх успішних проектів.

Дві інші основні проблеми, які згадуються майже в половині звітів, виявились:

• специфікації вимог;

• управління вимогами клієнта.

2.1.2. Оцінка вартості помилок

Недавно ряд компаній провели дослідження оцінки вартості помилок, що виникають на різних етапах створення програм. Кожна фірма діяла незалежно, але результати були приблизно однакові: якщо вартість зусиль, необхідних для знаходження і виправлення помилок на стадії написання коду, прийняти за одиницю, то вартість знаходження і виправлення помилок на стадії розробки вимог буде в 5–10 разів менша, а вартість знаходження і виправлення помилок на стадії супроводження – в 20 разів більша.

0,1–0,2 Час розробки вимог

0,5 Проектування

1 Кодування

2 Тестування компонент

5 Впровадження

20 Підтримка і обслуговування

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

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

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

1. Повторна специфікація.

2. Повторне проектування.

3. Повторне кодування.

4. Повторне тестування.

5. Заміна замовлення – сповістити клієнтам та операторам про необхідність замінити дефектну версію виправленою.

6. Внесення виправлень – виявити і ліквідувати всі неточності, викликані неправильним функціонуванням помилково специфікованої системи, що може вимагати виплати певних сум обуреним клієнтам, повторного виконання певних обчислювальних задач на ЕОМ і т.п.

7. Списання тієї частини роботи (коду, частин проекту і т.п.), яка виконувалась, але виявилась непотрібною, коли виявилось, що все це створювалось на основі невірних вимог.

8. Відкликання дефектних версій вбудованого програмного забезпечення і відповідної документації. Якщо прийняти до уваги, що програмне забезпечення вбудовується в різні вироби – від годинників і мікрохвильових пічок до автомобілів, – така заміна може зачепити як самі вироби, так і вбудоване в них програмне забезпечення.

9. Виплати по гарантійним зобов’язанням.

10. Відповідальність за виріб, якщо клієнт через суд вимагає відшкодування збитків, завданого неякісним програмним продуктом.

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

12. Створення документації.