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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Недавно ряд компаній провели дослідження оцінки вартості помилок, що виникають на різних етапах створення програм. Кожна фірма діяла незалежно, але результати були приблизно однакові: якщо вартість зусиль, необхідних для знаходження і виправлення помилок на стадії написання коду, прийняти за одиницю, то вартість знаходження і виправлення помилок на стадії розробки вимог буде в 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. Створення документації.

 

Управління вимогами

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

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

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

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

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

 

Послідовність роботи з вимогами. Аналіз проблеми

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

Програмісти повинні зрозуміти потреби користувачів та інших зацікавлених осіб.

Наступним кроком здійснюється перехід в область розв’язання – безпосередньо до програмування. Однак для початку буде корисно сформулювати знання про предметну область. На даному етапі створюється список функцій, які повинна реалізовувати система.

Для того щоб провести аналіз, корисно визначити, що ж власне представляє собою проблема. По визначенню Гауса та Вайнберга, проблема – це різниця між бажаним і сприйманим.

Іноді самим простим розв’язком є зміна бізнес-процесу, а не створення нової системи. Як завжди, починати потрібно з визначення цілі. Ціль аналізу в тому, щоб добитися кращого розуміння проблеми до початку розробки. Для цього необхідно здійснити наступні п’ять етапів.

1. Досягнути згоди про визначення проблеми.

2. Визначити основні причини – питання, які стоять за проблемою.

3. Виявити зацікавлених осіб та користувачів.

4. Визначити межу системи розв’язання.

5. Визначити обмеження, які необхідно накласти на розв’язання.