Основних ризиків при розробці ПЗ.

На відміну від мета-ризиків часу і витрат, де події ризиків можуть бути визначені досить поетапним(хоча і зовсім не простим) чином, шляхом послідовного розкладання завдань на менші підзадачі, визначення ризиків, в загальному випадку, куди менш механистично. У середовищі розробки і тестування програмного забезпечення існують три основні підходи до визначення ризиків: 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#, що виконує шифрування і дешифрування. Можна уявити собі такий об'єкт як роль і створити сценарій ніби: "Спершу я приймаю деякий введення і створюю екземпляр себе. Потім я приймаю деяке введення і передаю воно моєму методу шифрування". За визначенням ризиків на основі сценаріїв існує менше досліджень, ніж за визначенням на основі класифікацій. Технічний документ, який можна знайти на Шаблони визначення ризиків для програмних проектів надає хороший огляд цієї області і пропонує цікавий, теоретичний, грунтований на шаблонах підхід до визначення ризиків.

 

 

Аналіз ризиків.

Аналіз ризиків - це процес поєднання вірогідності(чи правдоподібності) події ризику з грошовими втратами(чи негативним ефектом) у разі цієї події, щоб зробити значення, яке можна використати для порівняння ризику з іншими рисками і визначення його пріоритетності. У цьому розділі я представляю два старі підходи до аналізу ризиків(методика очікуваного значення і категоріальна методика) і один новий підхід, іменований PERIL. Давайте спершу поглянемо на методику очікуваного значення. Процес реалізації аналізу ризиків ІБ по суті складається з трьох основних блоків: 1. Блок методики розрахунку ризиків ІБ;2. Блок по розробці і впровадженню процедури аналізу ризиків ІБ в підрозділах компанії;3. Блок підготовки звітності по процесу аналізу ризиків ІБ. Кожен з даних блоків містить свої питання і складнощі при реалізації. Проведення аналізу ризиків уявляє собою складний і рутинний процес. Багато консалтингових компаній використовують у своїй постійній практиці спеціально розроблені табличні файли, часто також застосовується спеціалізоване програмне забезпечення, покликане допомогти автоматизувати складні процеси управління ризиками.. В даний час у світі існує кілька десятків автоматизованих засобів, що дозволяють зробити працю фахівця з аналізу ризиків менш складним і трудомістким, за різними з зазначених вище блоків або комбінації блоків. Практика впровадження процесу аналізу ризиків показала, що найчастіше методика розрахунку ризиків ІБ та організація процедури аналізу ризиків ІБ рідко може бути добре автоматизована у одному рішенні. Запуск процесу управління ризиками в компанії – завдання складне і нетривіальна, а якщо в процесі бере участь декілька підрозділів, то процес проведення аналізу ризиків бажано автоматизувати. Дані засоби автоматизації відносяться до другого блоку процесу аналізу ризиків ІБ.

 

Цикли тотальної інтеграції.

Для ефективного вирішення проблеми забезпечення безпеки потрібний відповідний сучасний рівень технологій, технічних засобів і послуг з безпеки, базовою тенденцією розвитку яких є бурхливий цикл тотальної інтеграції. Нині інтеграцією охоплені микро-и радіоелектроніка, засоби обробки і канали зв'язку; з'явилися інтегральні технології, багатофункціональні інтегральні пристрої, мережі і системи; стали надаватися інтегральні послуги забезпечення безпеки. Особливо наочно відбувається цикл інтеграції в мікроелектроніці. Відомо, що оперативно-технічні характеристики спеціальної апаратури в першу чергу залежать від характеристик і особливостей використовуваної елементної бази. Це особливо яскраво проявилося на прикладі розвитку технічних засобів зберігання інформації, використовуваних в практиці роботи правоохоронних служб. Для вирішення таких завдань, як приховане аудіо- і відеоспостереження, захист інформації, зберігання і передача спеціальної інформації по каналах зв'язку в умовах інформаційно-технічної протидії і тому подібне. Аналіз розвитку сучасної мікроелектроніки демонструє, що нині цикл створення нової техніки і технологій складають всього 2-3 роки, чому сприяють досягнення в області створення мікроелементної бази, в першу чергу в області мікросхем пам'яті і микроциклоров. Якщо інтегрально оцінювати досягнення сучасної мікроелектроніки в області створення елементної бази, то їх можна описати усього лише двома основними технологічними параметрами, які визначаються товщиною ізолюючих ліній затворів микроциклоров та розміром напівкроку елементів облаштувань оперативної пам'яті. Експериментально встановлений закон Мура: кожні 1,5 року величини характеристик подвоюються(покращуються). Природно, що від цих технологічних параметрів залежать основні технічні характеристики мікросхем, такі, як об'єм пам'яті і складність циклора