34. 10 Основних ризиків при розробці пз.

На відміну від мета-ризиків часу і витрат, де події ризиків можуть бути визначені досить поетапним(хоча і зовсім не простим) чином, шляхом послідовного розкладання завдань на менші підзадачі, визначення ризиків, в загальному випадку, куди менш механистично. У середовищі розробки і тестування програмного забезпечення існують три основні підходи до визначення ризиків : 1) на основі класифікації, 2) сценаріїв і 3) специфікацій.

Класифікація - це просто систематичний список. Подумайте над наступною аналогією. Хтось збирається відправитися в авіаподорож, так що він проходить по стандартному списоку-памятке, використовуваному перед кожною поїздкою. Список містить заяви або питання, такі як: чи "На місці мої документи"? чи: чи "Перевірив я, чи не затримується мій виліт"?

З часом багато людей і організації створили класифікації програмних ризиків. Один такий список був створений Барри Боэмом(Barry Boehm) першопроходцем і широко відомим дослідником в області

ризиків для програмних проектів. У 1989 році Боэм визначив класифікацію 10 основних ризиків при розробці програмного забезпечення, а в 1995 році оновив список. Версія 1995 року приведена тут:

1. Недоліки персоналу

2. Розклади, бюджети, процеси

3. Готові комерційні програми, зовнішні компоненти

4. Невідповідність вимог

5. Невідповідність інтерфейсу користувача

6. Архітектура, продуктивність якість

7. Зміни вимог

8. Застаріле програмне забезпечення

9. Зовні виконувані завдання

10. Насильство над теорією програмування

Повинно бути очевидно, що список 10 основних ризиків Боэма не визначає риски негайно. Замість цього, класифікація просто представляє початкову точку, з якою можна приступити до обдумування ризиків, що відносяться до проекту. Наприклад, перший ризик, "недоліки персоналу", охоплює безліч різних можливих ризиків, що відносяться до кадрів. У проекту може просто не бути досить програмістів для створення додатка або

системи. Чи ключовий фахівець може залишити проект на середині роботи. Чи у штату програмістів може не виявитися необхідних технічних умінь для проекту. Ну, і так далі. Більшість з 10 основних категорій мають бути знайомі читачам, за винятком, можливо, 10-ій категорії "насильство над теорією програмування". Це, якоюсь мірою, універсальна категорія, що охоплює завдання, що відносяться до таких речей як технічний аналіз, аналіз витрат/прибутків і прототипизация. Інша часто використовувана класифікація ризиків розробки програмного забезпечення була створена Інститутом розробки програмного забезпечення(SEI). SEI - це один з 36 федерально спонсорованих центрів досліджень і розробки в США. Ці дослідницькі центри є дивними, гібридними організації, які фінансуються на гроші платників податків, але продають продукти і служби. Класифікація ризиків при розробці програмного забезпечення SEI була створена в 1993 році і містить приблизно 200 питань. Наприклад, питання №1 такий: чи "Стабільні вимоги? Якщо ні, який ефект цього для системи(якості, функціональності, розкладу, інтеграції, архітектури, тестування) "? Питання № 16: "Як визначається прийнятність алгоритмів і конструкцій (прототипизация, моделювання, аналіз, симуляція) "? Класифікацію ризиків SEI можна знайти в додатку до цього документу. При визначенні ризиків на основі сценаріїв розробник представляє себе в різних ролях, створює сценарії для цих ролей і визначає, що може піти не так в кожному сценарії. Використовуючи раніше описану аналогію з авіаперельотом, мандрівник може в думці простежити дії, які він робитиме в поїздці. Наприклад: "Спершу я приїду в аеропорт. Потім я припаркую мій автомобіль. Потім я пройду реєстрацію біля стійки авіакомпанії. Такий процес представлення собі сценаріїв може розкрити багато ризиків, включаючи затримки в дорозі із-за дорожніх робіт або аварії, відсутність парковки, можливість забути документи і так далі. У середовищі програмного проекту поширеними ролями, використовуваними для визначення ризиків на основі сценаріїв, є користувачі, розробники, тестери, продавці, архітектори програмного забезпечення і керівники проектів. Сценарій користувача може представляти з себе щось на зразок: "По-перше, я встановлюю додаток. Потім я запускаю додаток". У багатьох випадках сценарій визначення ризиків безпосередньо відповідає тестовому випадку. Ролями визначення ризиків на основі сценаріїв не обов'язково мають бути люди. Ролі також можуть бути програмними модулями і підсистемами. Наприклад, припустимо, що у нас є деякий об'єкт C#, що виконує шифрування і дешифрування. Можна уявити собі такий об'єкт як роль і створити сценарій ніби: "Спершу я приймаю деякий введення і створюю екземпляр себе. Потім я приймаю деяке введення і передаю воно моєму методу шифрування". За визначенням ризиків на основі сценаріїв існує менше досліджень, ніж за визначенням на основі класифікацій. Технічний документ, який можна знайти на Шаблони визначення ризиків для програмних проектів надає хороший огляд цієї області і пропонує цікавий, теоретичний, грунтований на шаблонах підхід до визначення ризиків.