Тема: Основи управління

проєктами
1. Проєкт і сутність проєктної
діяльності.
2. Міжнародні та національні
стандарти з управління проєктами.
3. Класифікація проєктів.
4. Життєвий цикл і фази проєкту.
5. Моделі життєвого циклу
інформаційних систем.
6. Учасники й оточення проєкту.
7. Методичні засади структуризації
проєкту.
 Питання 5.
Моделі життєвого циклу інформаційних
систем
 Моделі життєвого циклу ІС: що вибрати?
У програмній інженерії під
життєвим циклом ІС розуміють
послідовність фаз, через які
система проходить на протязі
свого існування: від задуму до
розробки, експлуатації та
ліквідації.
Узагальнена модель життєвого циклу

Розробка стратегії
автоматизації

Створення
Супровід Доробка системи та
її впровадження
 Узагальнена модель життєвого циклу:
1. Розробка стратегії
звичайно виконує замовник спільно з майбутнім її
користувачем.
У залежності від кваліфікації замовника і складності
системи, стратегія може бути зафіксована в
документах. У вітчизняній практиці це ТЗ.
Якщо замовником є державна організація, то при
розробці стратегії звичайно визначають мету
автоматизації, користувачів, очікувані переваги,
необхідні ресурси для створення ІС, джерела і
чинники ризику, передбачуваного розробника і
порядок взаємодії з ним, організацію проєкту і
розподіл відповідальності за його реалізацію.
Всі ці відомості відображаються в документах, що
ініціюють розробку ІС.
 Узагальнена модель життєвого циклу:
2. Створення і впровадження системи

Вона може бути побудована в залежності від

прийнятої моделі ЖЦ проєкту.
Головну роль протягом цієї фази відіграє
організація-розробник.
 Узагальнена модель життєвого циклу:
3. Супровід
Здійснюється розробником після впровадження
системи, коли вона надходить у
розпорядження замовника або організації
користувача.
У процесі супроводу розробник усуває всі
помилки, виявлені після впровадження,
здійснює адаптацію ІС з урахуванням умов
експлуатації, на вимогу замовника
доопрацьовує її з метою підвищення якості
функціонування
 Життєвий цикл розробки програмного забезпечення
(Software Development Life Сycle, SDLC)
- це структура, яка визначає кроки, що беруть
участь у розробці програмного забезпечення на
кожному етапі. Він охоплює детальний план
побудови, розгортання та обслуговування
програмного забезпечення.
SDLC визначає повний цикл розробки, тобто всі
завдання, пов'язані з плануванням, створенням,
тестуванням та розгортанням програмного
продукту.
Метою SDLC є постачання високоякісного
продукту, який відповідає вимогам замовника.
Цикл SDLC представляє процес розробки ПЗ
Етапи SDLC:
• Збір та аналіз вимог
• Дизайн
• Впровадження або кодування
• Тестування
• Розгортання
• Технічне обслуговування
 1) Збір та аналіз вимог
На цьому етапі від клієнта збирається вся
відповідна інформація для розробки продукту
відповідно до його очікувань. Будь-які неясності
повинні бути вирішені лише на цьому етапі.
Бізнес-аналітик та менеджер проекту
організували зустріч із замовником, щоб зібрати
всю інформацію, наприклад, що замовник хоче
створити, хто буде кінцевим споживачем, яка
мета продукту. Перш ніж створювати продукт,
дуже важливо розуміння або знання продукту.
 1) Збір та аналіз вимог (закінчення)
Після завершення збору вимог проводиться
аналіз для перевірки доцільності розробки
продукту. У разі виникнення будь-якої
неясності проводиться дзвінок для подальшого
обговорення.
Після чіткого розуміння вимог створюється
документ SRS (Software Requirement
Specification). Цей документ повинен бути
добре зрозумілий розробникам, а також
повинен бути переглянутий замовником для
подальшого використання.
 2) Дизайн
• На цьому етапі вимога, зібрана в
документі SRS (Software Requirement
Specification), використовується як вхідна
інформація та виводиться архітектура
програмного забезпечення, що
використовується для реалізації розробки
системи.
 3) Впровадження або
кодування
Впровадження / кодування починається
після того, як розробник отримає
проектний документ. Дизайн програмного
забезпечення переведений у вихідний код.
На цьому етапі реалізовано всі компоненти
програмного забезпечення.
 4) Тестування
Тестування починається після завершення кодування
та випуску модулів для тестування. На цьому етапі
розроблене програмне забезпечення ретельно
перевіряється, і всі виявлені дефекти приписуються
розробникам для їх усунення.
Повторне тестування, регресійне тестування
проводиться до моменту, коли програмне забезпечення
стане відповідати очікуванням замовника.
Тестувальники направляють документ SRS, щоб
переконатися, що програмне забезпечення відповідає
стандартам замовника.
 5) Розгортання
Після того, як продукт тестується, його
застосовують у виробничому середовищі або
спочатку UAT (Тест прийняття користувача)
робиться залежно від очікувань замовника.
У випадку UAT створюється копія
виробничого середовища, і замовник разом із
розробниками проводить тестування. Якщо
замовник знаходить заявку, як очікувалося, тоді
клієнт надає підписку для запуску.
 6) Технічне обслуговування
Після розгортання продукту на виробничому
середовищі розробники піклуються про технічне
обслуговування продукту, тобто якщо виникає
якась проблема, яка потребує виправлення або
потрібно зробити будь-яке вдосконалення.
 Моделі життєвого циклу розробки
програмного забезпечення
Модель життєвого циклу програмного
забезпечення - це описове зображення
циклу розробки програмного забезпечення.
Моделі SDLC можуть мати різний підхід,
але основні фази та діяльність
залишаються однаковими для всіх моделей.
 Найпопулярніші моделі SDLC
1.Каскадна модель/Модель Водоспад
2.Модель V
3.Ітераційна модель
4.Спіральна модель.
5.Гнучка модель.
6.Скрам модель
7.Методологія екстремального програмування
8.Модель Rad
9.Модель програмного прототипу
10.Модель Великоговибуху
 1)Каскадна модель/ Модель водоспаду
«Waterfall Model»

Модель водоспаду - це перша модель, що

використовується в SDLC. Вона також
відома як лінійна послідовна модель.
 Каскадна модель ЖЦ ІС
характеризується структурою впорядкованих стадій з
яких складаються стадії створення і впровадження.
Така впорядкованість передбачає, що всі передбачені
роботи повинні виконуватись настільки ретельно,
щоб не переглядати прийняті рішення. Модель містить
тільки цикл на стадії супроводу.
Склад і назва технологічних стадій у різних авторів
різна. Відмінності зводяться до ступеню деталізації.
Американський стандарт стадій створення
автоматизованої системи військового призначення
DOD-STD-2167A передбачає стадії, наведені на
наступному слайді.
Каскадна модель життєвого циклу ІС
Визначення Уточнення вимог
вимог

Разработка тех.
завдання

Планування
розробки

Реалізація

Зборка
системи

Супровід
 Каскадна модель ЖЦ ІС
Переваги каскадної моделі: Недоліки каскадної моделі:
1) Детермінованість 1) Від затвердження ТЗ до
моделі; впровадження готового
2) Чітка регламентованість продукту минає багато
(що спрощує управління часу. Існує ризик, що
проєктом, особливо вимоги користувачів
контроль за зміняться і вони не
виконанням). будуть задоволені.
2) Можливі випадки, коли
реальні потреби
залишилися
незмінними, але були
неправильно або
недостатньо використані
користувачем під час
розробки ТЗ.
 2). Модель V («V-Model»)
Ця модель була створена як ітераційний
різновид каскадної моделі або Waterfall
(водоспаду) . Назва походить від паралельної
структури V, за якою слідує ця модель.
Головною відмінністю V-моделі є те, що вона
спрямована на ретельну перевірку та тестування
продукту, що вже на початкових стадіях
проектування.
V-Model також відома як модель перевірки та
перевірки. У цій моделі розробка та тестування
йдуть паралельно.
 Модель V складається з 9 різних фаз SDLC
1. аналіз вимог,
2. проектування системи,
3. проектування архітектури,
4. проектування модулів,
5. кодування,
6. модульне тестування,
7. інтеграційне тестування,
8. системне тестування та
9. приймальне тестування.
 V-Model має дві частини – Перевірка
(планування та складання, Verification Pfase) та
Перевірка (тестування та покращення,
Validation Pfase ).
Етапи від аналізу вимог до розробки модуля
перебувають у фазі перевірки (планування та
складання).
А етапи від модульного тестування до
приймального тестування перетворюються на
фазу перевірки (тестування та покращення).
Тільки фаза кодування є нейтральною – вона
бере участь в обох.
 Фаза верифікації включає:
Аналіз вимог: На цьому етапі збирається та
аналізується вся необхідна інформація. Діяльність з
перевірки включає перегляд вимог.
Дизайн системи: Після того, як вимога чітка, система
розробляється, тобто архітектура, компоненти продукту
створюються та документуються в проектному
документі.
Дизайн високого рівня: Високорівневий дизайн
визначає архітектуру / дизайн модулів. Він визначає
функціональність між двома модулями.
Дизайн низького рівня: Дизайн низького рівня
визначає архітектуру / дизайн окремих компонентів.
Кодування: На цьому етапі розробляється код.
 Фаза перевірки включає:
Одиничне тестування: Unit Testing - це метод перевірки
найменшого фрагмента коду, на відповідність його цілям.
Одиничне тестування виконується з використанням модульних
тестових кейсів на етапі проектування низького рівня. Модульне
тестування виконується розробником самостійно.
Інтеграційне тестування: Інтеграційне тестування проводиться
для тестування модулів / компонентів, коли вони інтегровані, для
перевірки, чи працюють вони належним чином. Його виконують
тестувальники.
Тестування системи: означає тестування системи в цілому, яке
виконується на етапі проектування після інтеграційного
тестування. На цьому етапі перевіряється вся функціональність
системи.
Випробування на приймання: Приймальні випробування
пов'язані з етапом аналізу вимог проводяться в середовищі
замовника.
 Модель V

Переваги V - моделі: Недоліки V-моделі:

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

• якщо потрібне ретельне тестування

продукту, то V-модель виправдає закладену у
собі ідею: validation and verification.
• для малих та середніх проектів, де вимоги
чітко визначені та фіксовані.
• за умов доступності фахівців необхідної
кваліфікації, особливо тестувальників.
# 3. Ітераційна модель
 Спіральна модель ЖЦ
Передбачає багаторазове проходження тих
самих стадій проєкту доти, доки він не
буде задовольняти замовника.
Ця модель відображає ітеративний характер, властивий
процесу створення таких складних проєктів, якими є
програмне забезпечення ІС.
На кожній ітерації створюють діючий прототип,
піддають критичній оцінці. На заключній ітерації
прототип приймають за остаточний варіант системи.
Якщо проєкт великий, то зазвичай виділяють в ньому
обмежену підсистему, яку доцільно розробляти
використовуючи спіральну модель. Ця модель
використовується у випадках, коли замовник,
розробник і користувач - одна особа, продукт для
масового споживача
Спіральна модель життєвого циклу
Остаточний
варіант
Випробування Аналіз вимог
та оцінка

Реалізація Проєктування
 Спіральна модель ЖЦ
Переваги - відсутність Недоліки - складність
недоліків каскадної планування та
моделі, оскільки можна організації робіт, значні
врахувати вимоги, що витрати ресурсів при
змінилися. розробці великих
проєктів.
Використовується для
невеликих проєктів,
існує велика
невизначеність відносно
вимог користувача.
 Інші моделі
Проміжними між каскадною і спіральною
моделями є :
1) Метод швидкого прототипу;
2) Метод послідовного нарощування функцій;
3) Еволюційна модель;
4) Модель заснована на повторному
використанні компонент;
5) Модель заснована на автоматизованому
синтезі програм.
 1. Метод швидкого прототипу
Передбачає розробку в стислі терміни
діючого макета частини ІС
найкритичнішої до змін вимог
користувача, проведення дослідної
експлуатації макету до початку розробки
повномасштабного зразка.
Зазвичай насамперед підлягає
прототипуванню інтерфейс користувача з
майбутньою системою. Це дозволяє
залучити користувача до участі у
розробці на ранніх стадіях і уникнути
дорогих доробок кінцевих змін.
 Модель швидкого прототипу
Це цінний механізм розуміння потреб
споживачів.
Основне призначення - полегшити
виявлення вимог користувача.
Прототип після розробки ТЗ не
використовується, а в іншому ця
модель ЖЦ співпадає з каскадною.
 Модель прототипу
- це модель, в якій прототип розробляється до власне
розробки програмного забезпечення для отримання
цінних відгуків від замовника.
Прототипи мають обмежені функціональні
можливості та неефективну продуктивність у
порівнянні з фактичним програмним забезпеченням.
Фіктивні функції використовуються для створення
прототипів.
Модель прототипу
 Модель прототипу
Після завершення збору вимог створюється
швидкий дизайн і будується прототип, який
представляється замовнику для оцінювання.
Зворотній зв'язок впроваджено, і прототип знову
переглядається замовником на будь-які зміни.
Цей процес триває до тих пір, поки модель не
буде прийнята замовником.
 Модель прототипу
Відгуки клієнтів та уточнені вимоги
використовуються для модифікації прототипу і
знову представляються замовнику для оцінки.
Як тільки замовник схвалює прототип, він
використовується як вимога для побудови
власне програмного забезпечення. Фактичне
програмне забезпечення будується з
використанням підходу Waterfall model.
 3. Еволюційна модель
передбачає доробку ІС до рівня якості, який
задовольнить кінцевого користувача, безпосередньо
в процесі дослідної експлуатації.
Розробку ІС починають з тих функцій, про які
розробники мають чітке уявлення.
Знання відносно інших функцій системи уточнюють
вже після її часткового впровадження в
експлуатацію.
У цьому даний підхід є протилежним до метода
швидкого прототипу, при застосуванні якого
розробники починають реалізацію функцій відносно
яких у них існує найбільше сумнівів.
2. Метод послідовного нарощування функцій
полягає в поетапній розробці та реалізації
системи, на кожному етапі збільшується кількість
функцій.
Ця модель дозволяє зменшити час впровадження першої
черги ІС. Користувач раніше починає відчувати
перевагу від автоматизації.
Перевага - скорочення термінів окупності.
Недолік - складність планування й управління в
поєднанні з необхідністю дотримання відкритої
архітектури.
Цей метод доцільно використовувати в ІС
організаційного управління. Як перша черга може
бути розроблена частина ІС, в який реалізуються
порівняно прості інформаційні задачі, впровадження
яких може дати відразу помітний ефект.
 3. Еволюційна модель
При створенні складної ІС еволюційний підхід
дозволяє з самого початку зосередиться на
досягненні високих експлуатаційних
характеристик, до яких відносять надійність,
мобільність, модифікованість та ін.
Еволюційний підхід доцільно використовувати
при розробці ІС, у якій роботи по створенню
ПЗ не лежать на критичному шляху
загального графіка робіт.
 4. Модель заснована на повторному
використанні компонентів
Повторне використання компонентів є основою
складального програмування, яке дозволяє
суттєво скоротити вартість і тривалість розробки
ІС, а також підвищити його надійність при
одночасному скороченні витрат на супровід.
Найбільший ефект отримують тоді, коли значну
частину задач удається сформулювати в термінах
порівняно невеликої кількості підзадач, яким
відповідають стандартні підпрограми.
 4. Модель заснована на повторному
використанні компонентів (продовження)
Розробка чергової задачі зводиться до написання
порівняно нескладної програми, що викликає
підпрограми у певній послідовності й
організовує обмін даними між ними.
Такий підхід передбачає дослідження понять і
відносин відповідної предметної області та
розробку пакету, що їх реалізує, а також
технології застосування цього пакету при
формалізації задач.
 4. Модель заснована на повторному
використанні компонентів (закінчення)
Модель, заснована на повторному використанні
компонентів, є певною мірою ідеалізацією і в
чистому вигляді не використовується.
Нині, у зв'язку з поширенням об'єктно-
орієнтованого підходу до розробки ІС, вона
набуває все зростаючого значення.
 5. Модель заснована на автоматизованому
синтезі програм
Ця модель заснована на трансляції спеціально
розроблених програм на мові високого рівня в
машинні програми.
Ця концепція заснована на знаннях як про предметну
область, так і про процес створення програмних
засобів.
На відміну від інших підходів вона вимагає досить
високих первинних витрат на побудову моделі
знань та особливо на створення інструментальних
засобів їх підтримки, що збільшує вартість розробки.
Разом із тим автоматизований синтез програм дозволяє
різко скоротити всі види витрат на кожний подальший
зразок ІС і реалізувати високу якість програмного
продукту.
 Вибір ЖЦ ІС
Для вибору необхідно порівняти сильні і слабкі
сторони.
Вибір залежить від того, хто є замовником ІС.
Якщо це - ринок або замовник - недержавна
організація, то вибір диктується тільки логікою
здорового глузду та використовуваною
методологією розробки ІС (MSF, CDM Oracle
тощо).
Якщо проєкт розробляється за державним
замовленням, то необхідно дотримуватись
ДСТУ, тобто треба застосовувати каскадну
модель.
 Обов'язкові етапи робіт під час проєктування,
впровадження та експлуатації засобів інформатизації
(постанова Кабінету Міністрів України від 11 листопада 2009 р. N 1191)

1. Визначення потреби у засобах інформатизації та вивчення питання щодо

можливості їх модернізації для забезпечення виконання необхідних
функцій.
2. Розроблення техніко-економічного обґрунтування створення або
модернізації засобів інформатизації.
3. Обґрунтування необхідності використання особистих немайнових та (або)
майнових прав інтелектуальної власності на засоби інформатизації.
4. Розроблення технічного завдання на створення або модернізацію засобів
інформатизації.
5. Розроблення технічного та робочого або техноробочого проєкту
створення чи модернізації засобів інформатизації.
6. Проведення навчання фахівців для забезпечення функціонування засобів
інформатизації.
7. Виконання пусконалагоджувальних робіт.
8. Проведення випробувань створених або модернізованих засобів
інформатизації.
9. Введення засобів інформатизації в експлуатацію.
10. Виконання робіт з обслуговування засобів інформатизації відповідно до
гарантійних зобов'язань.
11. Післягарантійне обслуговування засобів інформатизації.
 Використання стандартів організації
життєвих циклів систем

Розглянемо найбільш поширені стандарти.

• Oracle Method:
– Методика Oracle CDM (Custom Development
Method)
– Методика Oracle PJM (Project Development
Method)
• Міжнародний стандарт ISO/IEC 12207
 Методика Oracle Custom Development Method
(CDM)
підтримує три моделі життєвого циклу:

1) “Класичну” – 2) “Прискорена розробка” (Fast Track) 3) “Полегшений підхід” –

передбачені – зорієнтована на використання рекомендується у
інструментів моделювання та випадку малих
всі програмування Oracle проєктів, можливості
роботи/задачі (Designer/2000, зокрема), швидкого
та етапи; призначена для порівняно прототипування
невеликих та середніх проєктів. додатків.

“визначення вимог” (етап

стратегії);
Передбачають поділ проєкту у часі на три
аналіз вимог (формулювання фази:
детальних вимог до системи);

проєктування (перетворення вимог 1. аналіз 2. проєктування

в детальні специфікації системи); та створення
вимог; системи;
реалізація (написання та тестування
додатків); 3. передача в експлуатацію/
впровадження.
впровадження (установка системи,
підготовка до початку експлуатації);
експлуатація (підтримка та
спостереження за додатком,
планування майбутніх
функціональних розширень).
 Основні процеси методики Oracle Custom Development
Method:
1] аналіз вимог – процес визначає бізнес- та системні вимоги до додатку;

2] аналіз існуючої системи – процес визначає і формулює існуюче технічне середовище для
визначення необхідних змін;
3] технічна архітектура системи – процес визначає елементи технічної бази системи, що
розробляється;
4] проєктування і створення БД – процес забезпечує проєктування і створення реляційної
бази даних, включаючи, наприклад, питання ефективної індексації і безпеки (секретність) на
рівні об'єктів БД;
5] проєктування і створення модулів ПЗ – основний процес, включає проєктування додатків і
створення програмного коду;

6] перетворення даних – цілі процесу – міграція, перетворення і тестування всіх існуючих

даних, які необхідні для роботи нової системи;

7] документування – процес забезпечує створення якісної текстової та on-line документації для

користувачів і адміністраторів, а так само технічних описів проєкту;

8] тестування – процес забезпечує спільне тестування якості всіх елементів системи, як

окремих модулів, так і результатів їх об'єднання;

9] навчання – процес забезпечує навчання і тестування користувачів і адміністраторів;

10] передача замовнику – процес включає такі задачі, як розробка плану інсталяції системи,
підготовка технічного середовища, організацію процесу "згортання" існуючої системи;

11] підтримка системи – цілі процесу – моніторинг і розв'язання проблем, заміна версій з
виправленими помилками, оцінка роботи системи і планування поліпшень.
Взаємозв'язок фаз та процесів методики Oracle Custom Development Method:
проєктування
Передача в
Аналіз вимог та створення
експлуатацію
системи
Аналіз вимог (RD)
Аналіз існуючої системи (ES)
Технічна архітектура системи (TA)

Проєктування і створення бази

даних (DB)
Проєктування і створення модулів
ПЗ (MD)
Перетворення даних (CY)

Документування (DO)

Тестування (TE)
Навчання (TR)
Передача замовнику (інсталяція)
(TS)
Підтримка (PS)
 Метод Oracle Project Development Method (PJM )
призначений для управління проєктами в області інформаційних технологій.
Мета – забезпечити структурну основу для планування, оцінки, управління і
контролю проєктів будь-яких типів.

Основні процеси, що розглядаються в PJM:

1) Контроль і Звіти – процес містить задачі, що допомагають визначити обсяг робіт і

методи проведення, управляти можливими змінами і контролювати ризик; крім
того він визначає управління планом проєкту і звіти про хід проведення проєкту);

2) Управління Роботами – задачі цього проєкту визначають і контролюють стан всіх

робіт, що виконуються по проєкту. Крім цього, забезпечують “фінансовий погляд”
на проєкт;

3) Управління Ресурсами – процес забезпечує оптимальний підбір персоналу, що

бере участь в проєкті, а також організує інфраструктуру для проведення проєкту);

4) Управління Якістю – процес повинен забезпечити “вимірювання якості” і

гарантувати задоволення не тільки вимог, але і очікувань замовника на протязі
всього проєкту;

5) Управління конфігурацією – задачі процесу допомагають організувати зберігання

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

5) завершення проєкту: врегулювання всіх спірних питань і забезпечення успішного

завершення проєкту.

Управління фазами
Планування Завершення
Планування Управління Завершення проєкту
проєкту
фази фазою фази

Контроль і звіти
Правління роботами
Управління ресурсами
Управління якістю
Управління
конфігурацією
 Міжнародний стандарт ISO/IEC 12207 –
це базовий стандарт процесів ЖЦ ПЗ, орієнтований на будь-які види ПЗ та типи
проєктів автоматизованих систем, куди входить ПЗ як частина стандарту і
визначає стратегію і загальний порядок створення та експлуатації ПЗ.

ISO/IEC 12207 охоплює ЖЦ від концептуалазації ідеї до завершення ЖЦ. Згідно з ним:
Система – це об'єднання одного або більше процесів, апаратних засобів, програмного
забезпечення, обладнання і моделей з метою забезпечення можливості задоволення певних
потреб або цілей.

В ISO/IEC 12207 описано 5 основних (базових) процесів:

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

✓ управління ✓підтримку його поточного ✓інсталяцію та вилучення

модифікаціям стану та функціональної програмного виробу з
 ISO/IEC 12207 описує 8 допоміжних процесів, які підтримують інші
процеси ЖЦ, є його частиною і забезпечують відповідну якість проєкту:

2)
1) Розв'язання 3) Управління 4) Забезпечення
проблем Документування конфігурацією; якості;
;

7) перевірка відповідності
5) Процес 6) Процес 8) процес аудиту
спільної оцінки
верифікації; атестації; (ревізії).
(об'єднаних оглядів);

Група забезпечення якості

Крім того, в ISO/IEC 12207 описано такі організаційні процеси:

1] процес 2] процес створення інфраструктури – 3] процес

визначає дії по створенню удосконалення
управління; інфраструктури, яка підтримує
процеси ЖЦ; процесів ЖЦ;

4] процес 5] Процес адаптації, який визначає дії,

необхідні для адаптації стандартів до
навчання; умов конкретного проєкту.
 Опис основних процесів життєвого
циклу програмного продукту
А1 Процес замовлення
Виконавець – Замовник
Дії:
1.1. Ініціювання;
1.2. Підготовка запиту щодо пропозицій
(тендеру);
13. Підготовка та коригування контракту;
1 4. Нагляд за постачанням;
1.5. Приймання та завершення
 Опис основних процесів життєвого циклу ПП:
ініціювання
Завдання Примітка
Описати концепції або потреби щодо
1.1.1.
замовлення, розроблення чи вдосконалення
системи, програмного продукту або програмної
послуги
Визначити та проаналізувати вимоги до
1.1.2. Замовник може здійснювати
визначення вимог до
системи. Вимоги до системи повинні містити
програмного забезпечення
вимоги з боку виробничого процесу, організації та самостійно або може передати
користувача, а також вимоги щодо безпеки, виконання "цього завдання"
захисту та інші критичні вимоги разом із постачальникові
відповідними стандартами та процедурами щодо
розроблення, випробування та погодження
1.1.3. Затвердити результати аналізу вимог Якщо замовник для виконання
аналізу системних вимог наймає
постачальника
Для виконання завдань,
наведених у підпунктах 1.1.2 та
1.1.3, повинен
використовуватися процес
розроблення (табл. А 3).
 Опис основних процесів життєвого циклу ПП:
ініціювання
Завдання Примітка

Розглянути
1.1.4.
Варіанти містять:
а) купівлю повністю готового для використання
варіанти замовлення, програмного продукту, що відповідає вимогам;
виходячи з аналізу б) розроблення програмного продукту або
відповідних отримання програмних послуг в рамках
організації;
критеріїв, включно з
в) розроблення програмного продукту або
ризиком, вартістю та отримання програмних послуг через контракт;
вигодою, для г) комбінація варіантів а), б) та в) цього
кожного варіанту. переліку;
д) удосконалення існуючого програмного
продукту або послуги.
 Опис основних процесів життєвого циклу ПП:
ініціювання
Завдання Примітка
1.1.5. Впевнитись, що: Якщо замовляється готовий до використання
а) вимоги щодо програмного продукту програмний продукт
задовольняються;
б) документація є у наявності;
в) права щодо використання та
володіння, а також патентні,
гарантійні та ліцензійні права
забезпечуються;
г) підтримка програмного продукту у
майбутньому планується.
1.1.6. Підготувати, задокументувати та План повинен містити: а) вимоги щодо
виконати план замовлення. системи;б) застосування планованої системи;в)
тип контракту, що буде застосовано;г)
відповідальність організацій-учасників;д)
концепцію підтримки, що буде використана;е)
враховані ризики разом з методами управління
ризиками.
Визначити та задокументувати
1.1.7.
стратегію та умови приймання
(критерії)
 Опис основних процесів життєвого циклу ПП:
підготовка запиту щодо пропозицій (тендеру)
Завдання
Задокументувати вимоги щодо
1.2.1.
замовлення (наприклад, запит щодо
пропозиції), зміст якого залежить від
варіанту замовлення, вибраного згідно
з Пунктом 1.1.2.
Визначити, які процеси, дії та
1.2.2.
завдання, що входять до цього
стандарту, відповідають проєкту, і
відповідним чином їх пристосувати.
Визначити сферу завдань, які
стосуються контракту.
Примітка
Документація щодо замовлення повинна,
містити:
а) системні вимоги;
б) опис сфери застосування;
в) інструкції для учасників тендеру;
г) перелік програмних продуктів;
д) терміни та умови;
е) умови нагляду за субпідрядами;
ж) технічні обмеження (наприклад, цільове
середовище).
Головним чином, треба визначити процеси
підтримки та організаційні процеси життєвого
циклу, а також, розподіл відповідальності (якщо
вона покладається на когось іншого, крім
постачальника), з тим, щоб постачальники мали
змогу у своїх пропозиціях вказати підхід до
кожного з визначених підтримувальних і
організаційних процесів.
 Опис основних процесів життєвого циклу ПП:
підготовка запиту щодо пропозицій (тендеру)
Завдання Примітка

Визначити проміжні етапи

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

слід передати організації, яку

обрано для виконання дій щодо
замовлення.
 Учасники Рівень Процес
декомпозиції

Замовник Контрактний процес замовлення

Про-
постачальник рівень процес поставки цеси,
що
Оператор Операційний процес функціонування під-
користувач рівень три-
му-
Розробники Інженерний процес процес розробки ють і
підтримки підтримки інші
Співробітники про-
підтримки Рівень підтримки процес функціонування цеси

організаційні процеси
Менеджер Корпоративний
рівень
менеджмент інфраструктура
удосконалення навчання

Кожний процес, дія чи задача ініціюється і виконується іншим процесом за

необхідністю, причому немає наперед визначеної послідовності
 Стандартом ISO/IEC 12207 передбачено 11 класів характеристик якості:

1) функціональні й інші можливі специфікації, включаючи виконання, фізичні

характеристики та умови середовища експлуатації;
2) зовнішні зв'язки (інтерфейси);
3) вимоги кваліфікації;
4) специфікації надійності, включаючи специфікації, пов'язані з методами
функціонування і супроводу, взаємодії з зовнішнім середовищем та вірогідністю
травм персоналу;
5) специфікації захищеності, включаючи специфікації, пов'язані з дотриманням
точності інформації;
6) людські фактори специфікації з інженерної психології (ергономіки), включаючи
пов'язані з ручним управлінням, взаємодією людини та обладнання,
обмеженнями на персонал та дії, що потребують концентрації людської уваги, які
є чутливими до помилок людини та навчання;

7) визначення даних та вимог бази даних;

8) вимоги до установки та прийомки ПП, що поставляється в місцях

функціонування та супроводу;
9) документація користувача;
10) робота користувача і вимоги виконання;
11) вимоги сервісу користувача.
 Порівняльна характеристика CDM та ISO 12207
ISO 12207 CDM Примітки
Основні процеси:
Процес придбання Немає
розробником
(замовником)

В CDM є процес СV – перетворення

Процес поставки Немає даних

Процес розробки. RD, ES, TA, DB, MD, (DO), В дужках показано процеси DO –
Визначає дії підприємства- (TR), TS документування та TR – навчання,
розробника, яке розробляє які відображені в інших процесах
принципи побудови ПВ і ISO 12207
ПП (в контексті створення
системи)
В організація-оператор розробляє
Процес експлуатації Немає план і гарантує відповідність
плану

Процес супроводу PS ISO передбачає розвиток, як

елемент супроводу, що викликає
новий процес, в CDM в такому
трактуванні повномасштабний
розвиток не передбачено
 Порівняльна характеристика CDM та ISO 12207
ISO 12207 CDM Примітки
Допоміжні процеси:
Процес документування DO – документування
Процес управління Немає
конфігурацією ПЗ
TE – тестування, Oracle PJM ISO використовує можливість
Процес забезпечення якості. застосувати інші міжнародні
А також процеси:
стандарти, наприклад ISO 9000
➢верифікація
➢атестація
➢спільна оцінка
➢аудит

Процес вирішення проблем Є в CDM

Організаційні процеси:
Процес управління Oracle PJM

Процес створення Oracle PJM

інфраструктури

Удосконалення процесів ЖЦ Немає В ISO 12207 передбачено зв'язок з

ISO 9000

Процес навчання TR – навчання

 Замовнику і розробнику доцільно врахувати:
Розробник отримує методику і
нормативну базу для повного
і зрозумілого замовнику опису
всіх своїх робіт з тестування ПЗ
і АС, організації
паралельної роботи нової і
старої систем, інших робіт,
пов'язаних з "впровадженням".
Розробник може з більшим успіхом
уникнути загрозливих для
бюджету проєкту ситуацій.
Коли він вимушений
безкоштовно виконувати ці
"об'ємні" роботи, оскільки
замовник не приймає роботи і не
платить гроші.
Розробник може створити
більш якісний продукт і
укріпити свій авторитет на
ринку.
Замовник отримує методику і
нормативну базу для
гарантування якості того
продукту, який він замовив за
свої чи кошти державного
бюджету.
Замовник зможе обґрунтувати
свої витрати перед
фінансовими чи
контролюючими органами,
уникнути ситуації, коли через
деякий час доводиться знову
замовляти гроші на заміну
невдалої системи чи
програмного комплексу, або
залишитись з непридатним
продуктом.
1) Жоден з розглянутих стандартів не
є повним, не описує усі види дій і
задач, що реально існують в
конкретних проєктах
автоматизованих систем і ПЗ.
2) ISO має набір процесів, дій і задач,
що охоплюють найбільш широкий
спектр можливих ситуацій за умови
максимальної можливості до
адаптації.
3) Використання ISO 12207:
а) фіксує необхідність організаційного відокремлення дій,
пов'язаних з “виготовленням” ПЗ і ІС від деяких видів
робіт, пов'язаних з гарантуванням якості;

б) фактично визначає конкретну відповідальність керівників

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

в) побудова профілів ЖЦ проєкту на основі ISO 12207

зазначеним чином може зробити проєктні роботи більш
дорогими. Вартість виросте також через проведення дій з
гарантування якості. На перший погляд – це непотрібні
ускладнення і ризики в проєктуванні ІС, яке і без того
відносять до діяльності з підвищеним ризиком.
 Питання 6.
Учасники й оточення проєкту.
Склад учасників проєкту, їх роль, розподіл їх функцій і
відповідальності залежать від типу, виду, масштабу і
складності проєкту, а також від фаз ЖЦ проєкту.
Жорстких регламентів по складу учасників проєкту не
існує.
Незмінними можна вважати наступні функції по здійсненню
проєкту, а отже і такий склад основних учасників:
- проєкт повинен бути осмислений, “придуманий" і ініційований,
значить у нього повинен бути ініціатор;
- проєкт повинен мати головну зацікавлену особу (організацію),
тобто сторону, яка є майбутнім власником і користувачем
результатами проєкту і несе за нього відповідальність. У нашій
термінології замовник = власник + користувач;
- здійснення проєкту вимагає залучення інвестицій, отже, у нього
повинні бути інвестори;
- проєкт треба готувати і здійснювати, значить у нього повинні
бути виконавці;
- внаслідок реалізації більшості проєктів щось має вироблятися
або надаватися послуги, отже проєкт повинен мати своїх
продавців, виробників і споживачів;
- проєктом треба управляти, отже у проєкт повинен мати
менеджерів.
Принципова схема учасників проєкту
Замовник
(власник)
Ініціатор проекту Інвестори

Інші зацікавлені сторони

Керівник проекту
Конкуренти
Команда проекту і
функціональні групи
Громадські групи
населення
ПРОЕКТ

Покупці кінцевої Генеральний

продукції контрактор

Продавці продукції Субконтрактор

Виробник готової Проектувальники

продукції
Власник земельної Генеральний підрядчик,
ділянки субпідрядчик
Ліцензори,
консалтингові,
Органи влади інжинірингові Постачальники
послуги
 Функції основних учасників проєкту
Ініціатор: сторона, що є автором головної
ідеї проєкту, його попереднього
обґрунтування і пропозицій по здійсненню
проєкту.
Ініціатором може бути практично будь-хто з
майбутніх учасників проєкту, але зрештою
ділова ініціатива по здійсненню проєкту
повинна виходити від замовника.
 Функції основних учасників проєкту
Замовник: головна сторона, зацікавлена у
здійсненні проєкту і досягненні його
результату.
Як правило, це майбутній власник і користувач
результатів проєкту. Він визначає основні вимоги і
масштаби проєкту, забезпечує фінансування проєкту
за рахунок своїх коштів або коштів інвесторів, що
залучаються до проєкту. Він укладає контракти з
основними виконавцями проєкту, несе
відповідальність за цими контрактами, управляє
персоналом взаємодії між учасниками проєкту, несе
відповідальність за проєкт перед суспільством і
законом.
 Функції основних учасників проєкту
Інвестор: сторона, що вкладає інвестиції в проєкт.
Мета інвестора - максимізація прибутку на свої
інвестиції.
Якщо інвестор і замовник не одна особа, то
звичайно як інвестори виступають банки,
інвестиційні фонди.
Інвестори вступають у контрактні відносини із
замовником, здійснюють розрахунки з іншими
сторонами по мірі виконання проєкту. Інвестори
є повноправними партнерами проєкту і
власниками проєкту, поки їм не будуть виплачені
всі кошти за контрактом із замовником або
кредитною угодою.
 Функції основних учасників проєкту
Керівник проєкту (менеджер): юридична особа, якій
замовник і інвестор делегує повноваження з
керівництва роботами по здійсненню проєкту, а саме:
плануванню, контролю і координації робіт всіх
учасників проєкту. Склад функцій і повноважень
керівника проєкту визначається контрактом із
замовником. Однак, перед керівником проєкту і його
командою звичайно ставиться задача всеосяжного
керівництва і координації робіт протягом ЖЦ проєкту
до досягнення певної мети проєкту і результатів при
дотриманні встановлених термінів, бюджету і якості.
 Функції основних учасників проєкту
Команда проєкту: специфічна організаційна структура
очолювана керівником проєкту і яка створюється на період
здійснення проєкту.
Задача команди проєкту: здійснення функцій управління
проєктом до ефективного досягнення цілей проєкту.
Склад і функції команди проєкту залежать від масштабів,
складності і інших характеристик проєкту.
Як правило, основними учасниками команди проєкту є:
менеджер проєкту, інженер, адміністративний керівник
контракту, контролер, бухгалтер, керівник служби
матеріально-технічного забезпечення, керівник робіт з
проєктування, керівник будівництва, координатор робіт з
експлуатації, адміністративний помічник, керівник
інформаційної служби.
 Функції основних учасників проєкту
Контрактор (генеральний контрактор): сторона або
учасник проєкту, що вступає у відносини з замовником
і який бере на себе відповідальність за виконання робіт
за контрактом. Це може бути весь проєкт або його
частина.
Мета контрактора - отримання максимально можливого
прибутку. Функції контрактора: укладання контракту із
замовником (інвестором), відбір і укладання договорів
з субконтракторами, забезпечення координації їх робіт,
прийняття і оплата робіт співвиконавців.
Контрактором може бути керівник проєкту або інші
активні учасники проєкту.
Субконтрактор: вступає у договірні відносини з
контрактором або субконтрактором більш високого
рівня, несе відповідальність за виконання робіт і
послуг відповідно до контракту.
 Функції основних учасників проєкту
Проєктувальник: юридична особа, що виконує за
контрактом проєктно-дослідницькі роботи в рамках
проєкту. Вступає у договірні відносини з генеральним
контрактором або безпосередньо із замовником.
Генеральний підрядник: юридична особа, чия пропозиція
прийнята замовником (як правило, для будівельних
проєктів). Тому звичайно генеральним підрядником є
будівельна і проєктно-будівельна організації.
Генеральний підрядник несе відповідальність за
виконання робіт відповідно до контракту, підбирає і
укладає договори з субпідрядниками на виконання
окремих робіт і послуг.
Постачальники: субконтрактори, що здійснюють різні
види постачання на контрактній основі.
 Функції основних учасників проєкту
Ліцензори: організації, що видають ліцензії на право
володіння земельними ділянками, ведення торгів,
виконання певних робіт і послуг, використання “ноу-
хау".
Органи влади: сторона, що висуває і підтримує
екологічні, соціальні і інші висуваються суспільством
і державою сторони проєкту і що задовольняє свої
інтереси шляхом отримання податку від учасників
проєкту.
Власник земельної ділянки: юридична або фізична особа,
що є власником землі, що бере участь у проєкті.
Виробник кінцевої продукції: здійснює експлуатацію
створених основних фондів і виробляє кінцеву
продукцію. Бере участь у всіх фазах проєкту. У
багатьох випадках є замовником і інвестором. Головна
мета – прибуток.
 Функції основних учасників проєкту
Споживачі кінцевої продукції: юридичні і
фізичні особи, що є покупцями і користувачами
кінцевої продукції, які визначають вимоги до
кінцевої продукції і послуг, що формують попит на
них. За рахунок коштів споживачів відшкодовуються
витрати на проєкт і формується прибуток всіх
учасників проєкту.
Інші учасники проєкту: конкуренти основних учасників
проєкту; суспільні групи і населення, чиї
економічні і неекономічні інтереси зачіпає
здійснення проєкту; спонсори проєкту; різні
консалтингові, інжинірингові організації,
залучені до здійснення проєкту і інші.
 Функції основних учасників проєкту
Для визначення повного складу учасників проєкту,
побудови його функціональної і організаційної
структур на стадії розробки концепції проєкту
необхідно визначити:
- предметну область: цілі, задачі, роботи і основні
результати, масштаби, терміни, складність;
- відносини власності, залученої до здійснення проєкту
(що скільки коштує і кому належить);
- основні ідеї реалізації проєкту (як зробити);
- основні активні учасники проєкту;
- основні пасивні учасники проєкту (кого торкається
проєкт);
- які мотивації учасників проєкту (можливий прибуток,
збитки, ризик і т.д.)
 Оточення проєкту
Щоб методично правильно організувати роботу з
реалізації проєкту необхідно враховувати таке:
1. - Проєкт виникає, існує та розвивається у
певному оточенні, яке називається зовнішнім
середовищем
2. - Ряд елементів проєкту можуть бути
використані як в його складі, так і поза ним
(наприклад – спеціалісти працюють над кількома
проєктами).
3. - Проєкт не є жорстким утворенням. Його
елементи можуть перейти із зовнішнього
середовища до складу проєкту і навпаки.
 Проєкт та його оточення
Зовнішнє середовище

Перехідна зона

Границя
Границя
Проект перехідної
проекту
зони

Внутрішнє середовище
Оточення проєкту у складі підприємства
Політика Економіка Суспільство Закон і Наука і Природа
право техніка Екологія

Керівництво підприємства

Ринок Сфера Сфера Ринок

збуту збуту фінансів капіталу

Ринок Сфера Матеріально- Ринок сировини і

засобів технічне напівфабрикатів
виробництва забезпечення
виробництва
Проект
Служби и Сфера Сфера Ринок послуг
вимоги до очищення і інфраструктури і сервісу
охорони утилізації
оточуючого відходів
середовища

Інші відділи
 Експертна оцінка ступеню впливу факторів оточення на різні типи проєктів

№№ Сфери впливу
п/п оточення Нау
проєкту За-
По- Еко- ка Ку Інф-
Сус- кон При Екол
лі- но- і ль раст
піль і по- ро- о-
ти- мі- тех- ту- рукт
ство ря- да гія
ка ка ні- ра ура
док
Типи і ка
види проєктів
1
Соціальні 3 3 3 3 1 3 1 2 2

2
Економічні 3 3 2 3 1 2 0 1 1

3
Організаційні 2 3 2 3 2 3 2 1 1

4
Інноваційні 1 2 1 2 3 3 1 1 1

5
Інвестиційні 1 3 2 3 2 1 3 3 3

10 14 10 14 9 12 7 8 8