Узгодженість та оцінка вимог. (Лекція 11)

Август 6, 2022

Главная
Менеджмент
Узгодженість та оцінка вимог. (Лекція 11)

Содержание

2. Вимоги отримані від користувачів можуть дублюватися або заперечувати один одного. Одні вимоги можуть бути незрозумілими або
3. По цій причині, перед тим, як вимоги попадуть у документ опису вимог, їх необхідно узгодити.
4. В дійсності узгодження і перевірка обґрунтованості вимог здійснюється паралельно з виявленням вимог. Після того як вимоги
5. Узгодження та перевірка вимог не можуть бути відокремлені від процесу підготовки технічного завдання. Зазвичай узгодження вимог
6. Для перевірки обґрунтованості вимог необхідно більш повний варіант технічного завдання, в якому всі вимоги чітко ідентифіковані
7. ВИМОГИ, ЯКІ ВИХОДЯТЬ ЗА РАМКИ ПРОЕКТУ Вибір проекту в сфері інформаційних технологій та відповідно створюваній системі
8. Для того щоб визначити, чи не виходить конкретна вимога за межі потрібного, необхідна еталонна модель, по
9. Однак існують і інші причини, по яким вимога може бути розглянута як та, що виходить за
10. Наприклад, вимоги можуть представляти велику складність для реалізації в комп’ютеризованій системі і повинно залишатися побажанням людини,
11. МАТРИЦЯ ЗАЛЕЖНОСТІ ВИМОГ Коли всі вимоги чітко ідентифіковані та пронумеровані можна сконструювати матрицю залежностей вимог (або
12. Таблиця 1 Матриця залежностей вимог
13. Верхня права частина матриці (над діагоналлю включно) не використовується. Інші комірки вказують на те, чи перекриваються
14. Матриця залежності вимог представляє собою простий, але ефективний метод знаходження протиріч та перекриттів, коли кількість вимог
15. МАТРИЦЯ ЗАЛЕЖНОСТІ ТА УЗГОДЖЕННЯ ВИМОГ ЗАСОБАМИ IBM RATIONAL REQUISITE PRO
16. ВИМОГИ - РИЗИКИ І ПРІОРИТЕТИ Усунувши суперечності і повтори вимог, необхідно провести аналіз ризиків і призначити
17. Здійсненність проекту залежить від його ризикованості. Ризик - це загроза, що заважає здійснити проект (брак фінансування,
18. ВИМОГИ МОЖУТЬ БУТИ «РИЗИКОВАНИМИ» З РІЗНИХ ПРИЧИН. ЦІ ПРИЧИНИ ПОДІЛЯЮТЬСЯ НА ТАКІ КАТЕГОРІЇ: • Типовий ризик
19. ПРІОРИТЕТИ ВИМОГ В ідеалі пріоритети вимог призначаються індивідуальними замовниками в процесі їх виявлення. Потім їх погоджують
20. Для того щоб виключити невизначеність і полегшити призначення пріоритетів, кількість пріоритетів має бути не великою. Зазвичай
21. Їх можна позначати як «високий», «середній», «низький» і «невизначений». Альтернативний перелік пріоритетів може виглядати, наприклад, так:
22. Наведемо приклад класифікації з описом: високий – критичні для рішення та проект не може бути реалізований
23. РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ МОЖНА РОЗДІЛИТИ НА ЧОТИРИ ОСНОВНІ КАТЕГОРІЇ: 1. Ризики пов'язані з вимогами 2. Технологічні
24. РИЗИКИ ПОВ'ЯЗАНІ З ВИМОГАМИ Процес розробки програмного забезпечення починається з визначення вимог і варіантів використання системи.
25. Основний спосіб справиться з цією групою ризиків - контролювати процес управління вимогами, створювати UML моделі варіантів
26. ТЕХНОЛОГІЧНІ РИЗИКИ Ця група ризиків об'єднує ризики пов'язані з використовуваними технологіями. Які технології ви плануєте застосувати?
27. РИЗИКИ ПОВ'ЯЗАНІ З КВАЛІФІКАЦІЄЮ ПЕРСОНАЛУ Хоча цій групі ризиків зазвичай приділяють мало уваги, але вона не
28. Для вирішення цієї групи ризиків необхідна в першу чергу підтримка керівництва. Потім, якщо учасники проекту частково
29. Менеджер проекту повинен вирішити, що і до якого терміну потрібно зробити, а керівник підрозділу має вирішити,
30. ПОЛІТИЧНІ РИЗИКИ Це дуже небезпечна група ризиків, яка з високою ймовірністю може привести до краху проекту
31. ПЛАНУВАННЯ РЕАГУВАННЯ НА РИЗИКИ Планування реагування на ризики - це процес розробки шляхів і визначення дій
32. МОЖЛИВІ ЧОТИРИ МЕТОДИ РЕАГУВАННЯ НА РИЗИКИ: Ухилення від ризику (risk avoidance). Передача ризику (risk transference). Зниження
33. УХИЛЕННЯ ВІД РИЗИКУ Ухилення від ризику передбачає зміну плану управління проектом таким чином, щоб виключити загрозу,
34. ПЕРЕДАЧА РИЗИКУ Передача ризику передбачає перекладення негативних наслідків загрози з відповідальністю за реагування на ризик на
35. ЗНИЖЕННЯ РИЗИКІВ Зниження ризиків передбачає зниження ймовірності та / або наслідків негативного ризикованого події до прийнятних
36. ПРИЙНЯТТЯ РИЗИКУ Прийняття ризику означає, що команда проекту усвідомлено прийняла рішення не змінювати план управління проектом
37. ГОЛОВНІ РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ ТА СПОСОБИ РЕАГУВАННЯ Список з п'яти головних причин провалу програмних проектів -
38. ДО ЧАСТО УПУСКАЄМОГО У ВИМОГАХ МОЖНА ВІДНЕСТИ: Функціональні. Програми установки, настройки, конфігурації. Міграція даних. Інтерфейси з
39. НЕВИЗНАЧЕНІСТЬ НЕ ЗМЕНШУЄТЬСЯ, ЯКЩО УПРАВЛІННЯ НЕ СПРЯМОВАНЕ НА РАННІЙ ДОЗВІЛ РИЗИКІВ
40. ВИЗНАЧЕННЯ ПРІОРИТЕТІВ ВИМОГ НА ПЕРШІ ІТЕРАЦІЇ ПРОЕКТУ
42. Скачать презентацию

Слайд 2

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

вимоги можуть бути незрозумілими або нереальними, інші можуть залишатися не виясненими.

Слайд 3

По цій причині, перед тим, як вимоги попадуть у документ опису

вимог, їх необхідно узгодити.

Слайд 4

В дійсності узгодження і перевірка обґрунтованості вимог здійснюється паралельно з виявленням

вимог. Після того як вимоги виявлені, вони підлягають перевірці. Для всіх сучасних методів виявлення вимог, які пов’язані з так званою груповою динамікою, це цілком природньо. Тим більш після виявлення вимог, вони, в будь-якому випадку повинні підлягати до детального обговорення та перевірці.

Слайд 5

Узгодження та перевірка вимог не можуть бути відокремлені від процесу підготовки

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

Слайд 6

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

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

Слайд 7

ВИМОГИ, ЯКІ ВИХОДЯТЬ ЗА РАМКИ ПРОЕКТУ
Вибір проекту в сфері інформаційних технологій

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

Слайд 8

Для того щоб визначити, чи не виходить конкретна вимога за межі

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

Слайд 9

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

як та, що виходить за рамки проекту.

Слайд 10

Наприклад, вимоги можуть представляти велику складність для реалізації в комп’ютеризованій системі

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

Слайд 11

МАТРИЦЯ ЗАЛЕЖНОСТІ ВИМОГ
Коли всі вимоги чітко ідентифіковані та пронумеровані можна сконструювати

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

Слайд 12

Таблиця 1 Матриця залежностей вимог

Слайд 13

Верхня права частина матриці (над діагоналлю включно) не використовується. Інші комірки

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

Слайд 14

Матриця залежності вимог представляє собою простий, але ефективний метод знаходження протиріч

та перекриттів, коли кількість вимог відносно невелика. В протилежному випадку описаний метод можна застосовувати лише після групування вимог по категоріям та порівняння в межах кожної категорії по окремості.

Слайд 15

МАТРИЦЯ ЗАЛЕЖНОСТІ ТА УЗГОДЖЕННЯ ВИМОГ ЗАСОБАМИ IBM RATIONAL REQUISITE PRO

Слайд 16

ВИМОГИ - РИЗИКИ І ПРІОРИТЕТИ
Усунувши суперечності і повтори вимог, необхідно провести

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

Слайд 17

Здійсненність проекту залежить від його ризикованості.
Ризик - це загроза, що заважає

здійснити проект (брак фінансування, часу, ресурсів і т.д.). Ідентифікуючи ризики, менеджер отримує можливість управляти ними.

Слайд 18

ВИМОГИ МОЖУТЬ БУТИ «РИЗИКОВАНИМИ» З РІЗНИХ ПРИЧИН. ЦІ ПРИЧИНИ ПОДІЛЯЮТЬСЯ НА

ТАКІ КАТЕГОРІЇ:

• Типовий ризик означає, що вимога технічно важко реалізувати.
• Ризик зниження продуктивності означає, що реалізація вимог може сповільнити реакцію системи.
• Ризик, пов'язаний з порушенням цілісності баз даних, означає, що вимога важко перевірити і може виникнути суперечливість даних.
• Ризик, пов'язаний з процесом розробки, означає, що для реалізації вимог необхідно використовувати незвичайні методи, незнайомі розробникам (наприклад, методи формальної специфікації).
• Політичний ризик означає, що вимога може виявитися нездійсненним через внутрішньополітичні причини.
• Юридичний ризик означає, що вимога може призвести до порушення діючих законів або суперечити очікуваних змін закону.
• Ризик, пов'язаний з мінливістю, означає, що вимога може потенційно зміняться або еволюціонувати протягом процесу розробки.

Слайд 19

ПРІОРИТЕТИ ВИМОГ
В ідеалі пріоритети вимог призначаються індивідуальними замовниками в процесі їх

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

Слайд 20

Для того щоб виключити невизначеність і полегшити призначення пріоритетів, кількість пріоритетів

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

Слайд 21

Їх можна позначати як «високий», «середній», «низький» і «невизначений».
Альтернативний перелік

пріоритетів може виглядати, наприклад, так: «істотне», «корисне», «важко визначити» і «відкладене».

Слайд 22

Наведемо приклад класифікації з описом:
високий – критичні для рішення та

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

Слайд 23

РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ МОЖНА РОЗДІЛИТИ НА ЧОТИРИ ОСНОВНІ КАТЕГОРІЇ:
1. Ризики пов'язані

з вимогами
2. Технологічні ризики
3. Ризики пов'язані з кваліфікацією персоналу
4. Політичні ризики
Це тільки основні категорії, однак, у кожному конкретному випадку можуть бути додані інші види, не розглянуті тут.

Слайд 24

РИЗИКИ ПОВ'ЯЗАНІ З ВИМОГАМИ
Процес розробки програмного забезпечення починається з визначення вимог

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

Слайд 25

Основний спосіб справиться з цією групою ризиків - контролювати процес управління

вимогами, створювати UML моделі варіантів використання і залучати замовників для обговорення отриманих моделей. Замовник повинен зрозуміти, навіть якщо він цього не розумів на початку, що він отримає на кожному етапі розробки і як цим можна буде користуватися. Використання інструментальних засобів для керування вимогами, таких як RequisitePro і ClearQuest і такого інструменту для створення моделей, як, наприклад, Rational Rose.

Слайд 26

ТЕХНОЛОГІЧНІ РИЗИКИ
Ця група ризиків об'єднує ризики пов'язані з використовуваними технологіями.
Які

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

Слайд 27

РИЗИКИ ПОВ'ЯЗАНІ З КВАЛІФІКАЦІЄЮ ПЕРСОНАЛУ
Хоча цій групі ризиків зазвичай приділяють

мало уваги, але вона не менш важлива, ніж дві попередні. Наскільки співробітники, які беруть участь у проекті досвідчені у роботі з вибраними технологіями? Чи є досвід ведення аналогічних проектів, чи достатній досвід менеджера проекту?
Проект не можуть врятувати генії-одинаки, якщо основна маса учасників проекту - дилетанти. Якщо програмісти не розбираються в UML діаграмах, а аналітики тільки їх і створюють, то проект можна навіть не починати.
Керівник проекту повинен оцінити ризики та організувати навчання ще до початку проекту, щоб не втрачати час на помилки в майбутньому. Досвідчені наставники вже знають, як обійти більшість помилок, які зустрічаються на шляху розробники, тому їх досвід дозволить заощадити значні кошти, навіть якщо це не очевидно.

Слайд 28

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

Потім, якщо учасники проекту частково зайняті своїми основними обов'язками і у них є власний керівник, то щодо проведення робіт по проекту необхідно вирішувати питання саме з керівником.

Слайд 29

Менеджер проекту повинен вирішити, що і до якого терміну потрібно зробити,

а керівник підрозділу має вирішити, хто це буде робити і коли.

Слайд 30

ПОЛІТИЧНІ РИЗИКИ
Це дуже небезпечна група ризиків, яка з високою ймовірністю може

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

Слайд 31

ПЛАНУВАННЯ РЕАГУВАННЯ НА РИЗИКИ
Планування реагування на ризики - це процес розробки

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

Слайд 32

МОЖЛИВІ ЧОТИРИ МЕТОДИ РЕАГУВАННЯ НА РИЗИКИ:
Ухилення від ризику (risk avoidance).
Передача

ризику (risk transference).
Зниження ризиків (risk mitigation).
Прийняття ризику (risk acceptance).

Слайд 33

УХИЛЕННЯ ВІД РИЗИКУ
Ухилення від ризику передбачає зміну плану управління проектом

таким чином, щоб виключити загрозу, викликану негативним ризиком, захистити цілі проекту від наслідків ризику або послабити мети, що перебувають під загрозою (наприклад, зменшити зміст проекту). Деякі ризики, що виникають на ранніх стадіях проекту, можна уникнути за допомогою уточнення вимог, отримання додаткової інформації або проведення експертизи.

Слайд 34

ПЕРЕДАЧА РИЗИКУ
Передача ризику передбачає перекладення негативних наслідків загрози з відповідальністю

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

Слайд 35

ЗНИЖЕННЯ РИЗИКІВ
Зниження ризиків передбачає зниження ймовірності та / або наслідків

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

Слайд 36

ПРИЙНЯТТЯ РИЗИКУ
Прийняття ризику означає, що команда проекту усвідомлено прийняла рішення

не змінювати план управління проектом у зв'язку з ризиком або не знайшла відповідної стратегії реагування. Ми змушені приймати всі «невідомі ризики».

Слайд 37

ГОЛОВНІ РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ ТА СПОСОБИ РЕАГУВАННЯ
Список з п'яти головних причин

провалу програмних проектів - наступний:
- Вимоги замовника відсутні / не повні / схильні до частих змін.
- Відсутність необхідних ресурсів та досвіду.
- Відсутність робочого взаємодії з замовником.
- Неповнота планування. «Забуті роботи».
- Помилки в оцінках трудоємкостей і термінів робіт

Слайд 38

ДО ЧАСТО УПУСКАЄМОГО У ВИМОГАХ МОЖНА ВІДНЕСТИ:
Функціональні.
Програми установки, настройки, конфігурації.
Міграція даних.
Інтерфейси

з зовнішніми системами.
Довідкова система.
Загальносистемні.
Продуктивність.
Надійність.
Відкритість.
Масштабованість.
Безпека.
Міжплатформеність.
Ергономічність.

Слайд 39

НЕВИЗНАЧЕНІСТЬ НЕ ЗМЕНШУЄТЬСЯ, ЯКЩО УПРАВЛІННЯ НЕ СПРЯМОВАНЕ НА РАННІЙ ДОЗВІЛ РИЗИКІВ

Слайд 40

Узгодженість та оцінка вимог. (Лекція 11)

Содержание

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

По цій причині, перед тим, як вимоги попадуть у документ опису

В дійсності узгодження і перевірка обґрунтованості вимог здійснюється паралельно з виявленням

Узгодження та перевірка вимог не можуть бути відокремлені від процесу підготовки

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

ВИМОГИ, ЯКІ ВИХОДЯТЬ ЗА РАМКИ ПРОЕКТУВибір проекту в сфері інформаційних технологій

Для того щоб визначити, чи не виходить конкретна вимога за межі

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

Наприклад, вимоги можуть представляти велику складність для реалізації в комп’ютеризованій системі

МАТРИЦЯ ЗАЛЕЖНОСТІ ВИМОГ Коли всі вимоги чітко ідентифіковані та пронумеровані можна сконструювати

Таблиця 1 Матриця залежностей вимог

Верхня права частина матриці (над діагоналлю включно) не використовується. Інші комірки

Матриця залежності вимог представляє собою простий, але ефективний метод знаходження протиріч

МАТРИЦЯ ЗАЛЕЖНОСТІ ТА УЗГОДЖЕННЯ ВИМОГ ЗАСОБАМИ IBM RATIONAL REQUISITE PRO

ВИМОГИ - РИЗИКИ І ПРІОРИТЕТИУсунувши суперечності і повтори вимог, необхідно провести

Здійсненність проекту залежить від його ризикованості.Ризик - це загроза, що заважає

ВИМОГИ МОЖУТЬ БУТИ «РИЗИКОВАНИМИ» З РІЗНИХ ПРИЧИН. ЦІ ПРИЧИНИ ПОДІЛЯЮТЬСЯ НА

ПРІОРИТЕТИ ВИМОГВ ідеалі пріоритети вимог призначаються індивідуальними замовниками в процесі їх

Для того щоб виключити невизначеність і полегшити призначення пріоритетів, кількість пріоритетів

Їх можна позначати як «високий», «середній», «низький» і «невизначений». Альтернативний перелік

Наведемо приклад класифікації з описом: високий – критичні для рішення та

РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ МОЖНА РОЗДІЛИТИ НА ЧОТИРИ ОСНОВНІ КАТЕГОРІЇ:1. Ризики пов'язані

РИЗИКИ ПОВ'ЯЗАНІ З ВИМОГАМИ Процес розробки програмного забезпечення починається з визначення вимог

Основний спосіб справиться з цією групою ризиків - контролювати процес управління

ТЕХНОЛОГІЧНІ РИЗИКИ Ця група ризиків об'єднує ризики пов'язані з використовуваними технологіями. Які

РИЗИКИ ПОВ'ЯЗАНІ З КВАЛІФІКАЦІЄЮ ПЕРСОНАЛУ Хоча цій групі ризиків зазвичай приділяють

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

Менеджер проекту повинен вирішити, що і до якого терміну потрібно зробити,

ПОЛІТИЧНІ РИЗИКИ Це дуже небезпечна група ризиків, яка з високою ймовірністю може

ПЛАНУВАННЯ РЕАГУВАННЯ НА РИЗИКИПланування реагування на ризики - це процес розробки

МОЖЛИВІ ЧОТИРИ МЕТОДИ РЕАГУВАННЯ НА РИЗИКИ: Ухилення від ризику (risk avoidance).Передача

УХИЛЕННЯ ВІД РИЗИКУ Ухилення від ризику передбачає зміну плану управління проектом

ПЕРЕДАЧА РИЗИКУ Передача ризику передбачає перекладення негативних наслідків загрози з відповідальністю

ЗНИЖЕННЯ РИЗИКІВ Зниження ризиків передбачає зниження ймовірності та / або наслідків

ПРИЙНЯТТЯ РИЗИКУ Прийняття ризику означає, що команда проекту усвідомлено прийняла рішення

ГОЛОВНІ РИЗИКИ ПРОГРАМНИХ ПРОЕКТІВ ТА СПОСОБИ РЕАГУВАННЯСписок з п'яти головних причин

ДО ЧАСТО УПУСКАЄМОГО У ВИМОГАХ МОЖНА ВІДНЕСТИ:Функціональні.Програми установки, настройки, конфігурації.Міграція даних.Інтерфейси