ПРОГРАМНА ІНЖЕНЕРІЯ -2022

Викладач: Слабоспицька Ольга Олександрівна

olsips2017@gmail.com, olgaslab@knu.ua, 526 4286

Лише альянс технологій з мистецтвом і гуманітарними

знаннями надає результат і примушує наші серця співати
Стів Джобс

Лекція 1_16_09_2021. Сутність, структура та основні поняття інженерії програмного

забезпечення
Посібники
Жихаревич_ПППІ.pdf, підрозділи 1.2, 1.4, 2.1, 2.3, 5.3, 5.4
Orlov_PI.pdf, с.20-23
Додатково: Sydorov.pdf, ІПЗ_50_розвитку.pdf
romanov_PI.pdf, с.28-32
1.1 Визначення та місія інженерії програмного забезпечення
Упродовж розвитку інженерії програмного забезпечення (ІПЗ) різнорідні визначення фіксували
окремі вибіркові аспекти її поточної сутності. Окремі показові формулювання:
«Встановлення й використання обґрунтованих інженерних принципів для економного отримання
программного забезпечення, яке є надійним і реально працює» (F.L.Bauer, 1968);
«Дисципліна, метою якої є створення якісного програмного забезпечення, яке завершується вчасно,
не перевищує виділених коштіві задовольняє висунуті вимоги» (S.R.Schach, 1988);
«Форма інженерії, яка застосовує принципи комп’ютерних наук і математики для рентабельного
розв’язання проблем програмного забезпечення» (CMU/SEI-90-TR-003, 1990)
«Cкладова комп’ютерних наук, яка створює практичні, економічно вигідні рішення для
обчислювальних задач та задач опрацювання інформації, переважно шляхом застосування наукових
знань та розробки програмних систем, що служать людству»» (N.R.Mead, D.Garlan, M.Show, 2018);
«Інженерна дисципліна, в якій зібрані всі аспекти виробництва програмного забезпечення від ранніх
етапів специфікації систем до її обслуговування після уведення в експлуатацію», проте «немає
універсальних методів та методів розробки програмного забезпечення, які є придатними для всіх
систем та всіх компаній – навпаки, за останні 50 років склався різноманітний набір методів та
інструментів розробки програмного забезпечення» (B.Rendell, 2018);
«Концепції, методи, інструменти, системи тощо, які призначені для забезпечення якісного та
високопродуктивного характеру інженерної діяльності зі створення та використання програмно-
інформаційних засобів обчислювальної техніки» (Ф. Я. Дзержинський і Л. Д. Райков, 1990)
«Дисципліна, що відмежовує кодування комп’ютерної програми від розроблення програмного
продукту» (B.Boehm, 2017)
Наразі їх підсумовують стандартизовані де-юре визначення:
Систематичне застосування наукових і технічних знань, методів і досвіду для розробки,
реалізації, тестування й документування програмного забезпечення.
ДСТУ ISO/IEC 2382:2017 (ISO/IEC 2382:2015, IDT) Інформаційні технології. Словник термінів

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

використання за призначенням та обслуговування програмного забезпечення,тобто
«застосування інженерії до програмного забезпечення».
ДСТУ ISO/IEC/IEEE 24765:2018 (ISO/IEC/IEEE 24765:2017, IDT) Інженерія систем і програмних засобів.
Словник термінів
ДСТУ ISO/IEC TR 19759:2016 (ISO/IEC TR 19759:2015, IDT) Програмна інженерія. Настанова щодо ядра
знань програмної інженерії (SWEBoK, V.3)
Шляхом виконання загального призначення будь-якої інженерії – розв’язання поставлених завдань
за допомогою (налаштування) наявних теорій і методів – ІПЗ реалізує свою місію, а саме результативне
й ресурсно ефективне стале опрацювання складності створюваних програмних систем (ПС) і продуктів
(ПП – ПС з документально гарантованою якістю), а також процесів і середовищ їх розроблення, під час
промислового виробництва ПС/ПП з гарантованою якістю.
 2

1.2 Становлення ІПЗ: чинники, результати, особистості

Основна передумова виокремлення ІПЗ як окремої галузі знань: необхідність перетворення
програмування з «мистецтва одинаків» у промислове програмування – невід’ємний складник масового
виробництва ПП з гарантованою якістю. Ця передумова виникла внаслідок::
1) швидкого зростання змістовної складності та розміру створюваних продуктів, неопрацьовної в
межах первинного «ковбойсько-хакерського» стилю суто індивідуального програмування без хоча б де-
факто стандартів: замість «малих» стали потрібні «великі» програми. З 60-х років процес
програмування стає масовим, але через «ручний» характер кодування (software crafting) залишається
неприйнятно вартісним, тривалим і неякісним;
 код, заплутаний через модель «code and fix»;
 код, наповнений залишковими дефектами через «heroic debagging»;
 порушення термінів і бюджетів поставок ПП через незадовільне керування (великими) проектами;
 потреба врахування різноманітності та обслуговування, зокрема в критичній інфраструктурі;
 недостатність кваліфікованих кадрів.
Програму вважають «малою», якщо їй властиві хоча б декілька поданих далі ознак:
 вона вирішує одне чітко поставлене завдання (напр., видає десяткові цифри числа π) у чітко
заданих обмеженнях (не більше 30000 цифр), до того ж «іграшкове», не дуже суттєве для практичної чи
дослідницької діяльності;
 швидкість її роботи неважлива;
 шкода від неправильної роботи програми практично відсутня;
 розвиток та обслуговування непотрібні;
 документація непотрібна – використання зрозуміле для потенційно зацікавлених осіб.
Натомість, програму вважають «великою/складною» (і зазвичай звуть ПС/ПП), якщо вона має не
лише і не стільки значний розмір коду, але протилежні ознаки і/або додаткові атрибути, пов'язані з її
запитаністю й готовністю користувачів платити як за неї, так і за її супровід і/або навчання роботі з нею:
 вирішує одне чи декілька пов'язаних завдань, часто без чіткої постановки, настільки важливих для
певних осіб/організацій, що ті набувають значних вигод від її використання;
 має бути зручною; зокрема, має бути повна й зрозуміла користувачам документація, можливо,
спеціальна документація для адміністраторів, а також документи для навчання роботі з програмою;
 низька продуктивність на реальних даних призводить до значних втрат для користувачів;
 неправильна робота завдає відчутних збитків користувачам та іншим організаціям/особам, навіть
якщо збої відбуваються не надто часто;
 для виконання своїх завдань програма має взаємодіяти з іншими програмами та програмно-
апаратними системами, працювати на різних платформах;
 користувачі отримують додаткові вигоди від нових функцій та усунення помилок. Необхідна
проектна документація, що дозволяє розвивати її третім сторонам з прийнятно низькою трудомісткістю;
 до розробки залучено понад 5 осіб з ролями від бізнес-аналітика до тестувальника;
 значна кількість можливих користувачів, і ще більше осіб, на діяльність яких впливає робота
програми та її результати.
2) розвитку функціональних та продуктивних спроможностей перших електронно-обчислювальних
машин (рис.1.1), яке зазначив, зокрема, Е.Дійкстра:
«Основна причина кризи програмного забезпечення – різке зростання потужностей обчислювальних машин!
Простіше кажучи: немає обчислювальної техніки – немає проблем із розробкою програмного забезпечення
для неї; коли ж з'явилося кілька слабких комп'ютерів, з'явилися перші проблеми, пов'язані з розробкою
програмного забезпечення, зараз ми маємо гігантські комп'ютери, і програмування стало так само гігантською
проблемою».

Рисунок 1.1 – Динаміка співвідношення витрат на апаратне та програмне забезпечення

 3

3) зростання запитаності, насамперед критичними державними й міжнародними бізнесовими

структурами, «великого» програмного забезпечення (ПЗ) з характеристиками високоякісного продукту –
своєчасністю та гарантованою якістю;
4) виокремлення масової професії програміста, а надалі – інженера ПЗ з ролями від бізнес-
аналітика до обслуговника ПЗ;
5) зростання вартості ПЗ – як абсолютної, так і відносної, порівняно з апаратним, особливо його
обслуговування та розвитку (рис.1.1);
6) накопичення в різних центрах розроблення, використання й обслуговування програм позитивного
й негативного досвіду та формування кращих практик як стандартів де-факто.
Ф.Л.Бауер (Friedrich Ludwig "Fritz" Bauer) зафіксував першу кризу складності – неможливість
застосування «кустарних» (напів-інтуїтивних) методів розробки програмного коду для виробництва
«великих» масштабовних ПС:
«Існуюче програмне забезпечення розробляється аматорами (незалежно від того, де – в університетах,
компаніях чи на виробництві) за допомогою майстерності одинаків (в університетах) або великої кількості
працівників («мільйон мавп») на виробництві, є ненадійним і потребує постійного «технічного обслуговування»
(причому слово «обслуговування» неправильно використовують для позначення збоїв і відмов, очікуваних від
виробника з самого початку), є неохайним, непрозорим і невдосконалюваним (або принаймні занадто
вартісним, щоб це зробити). І нарешті, існуюче програмне забезпечення надходить занадто пізно і коштує
дорожче, ніж очікувалося, та не виправдовує покладених на нього сподівань».
Результатом усвідомлення провідними представниками наукових, освітніх і промислових спільнот
нагальної необхідності подолання першої кризи складності стало проведення спеціалізованої
конференції під егідою наукового комітету НАТО (.м.Гарміш-Потсдам, ФРН, 7-11 жовтня 1968р.), де
було обґрунтовано й запроваджено термін «software engineering»:
Report on a conference sponsored by the NATO science committee, Garmisch, Germany, 7th to 11th
October 1968, Editors: Peter Naur and Brian Randell.
Термін «інженерія програмного забезпечення» (software engineering) був свідомо обраний як
провокативний: «це поняття означало, що виробництво ПЗ має ґрунтуватися на тому ж типі
теоретичних засад і практичних застосувань, що й у традиційних галузях інженерії» (Ф.Л.Бауер).
В СРСР академік РАН А.П.Єршов запровадив термін-аналог – технологія програмування
Пізніше був запропонований альтернативний термін – «програмна інженерія» (ПІ), де-факто
стандартизований в Україні в 2006-2016рр.
Засади програмної інженерії – технології програмування в СРСР були широко розвинуті Академіком
В.М.Глушковим з колегами в Інституті кібернетики НАН УРСР.
Наразі в навчальній практиці застосовують точніший відповідник первинного англомовного терміну –
Інженерія програмного забезпечення, широко використовуваний взаємозаміно з ПІ.

Академік В.М.Глушков Академік А.П.Єршов

1.3 Зміст, аспекти та структура ІПЗ

1.3.1 Позиція в комп’ютерних науках
Наведені стандартизовані визначення задають основні аспекти ІПЗ, які уможливлюють виконання її
місії та зумовлюють подібності до інших «інженерій» (зокрема, систем і знань) та відмінності від
програмування – «аматорського», наукового, спортивного й промислового:
1) позиція ІПЗ в комп’ютерних науках (Computer Science, Інформатика);
2) внутрішня структура ІПЗ;
3) нормативно-методичне забезпечення ІПЗ як особливої «інженерії» програм, ПС, ПП.
 4

ІПЗ підсумовує підходи до розроблення корисних для кінцевого користувача ПП і прийоми їх

ефективного практичного застосування на всіх стадіях життєвого циклу (ЖЦ).
Функції ІПЗ:
1) дослідження методів і засобів побудови комп'ютерних програм, ПС і ПП;
2) узагальнення й документування накопиченого досвіду прикладного програмування, виявлення й
систематизація закономірностей його розвитку та формування рекомендацій з практичного
використання;
3) визначення автоматизованих операцій з (промислового) виробництва програмних сутностей
(об'єктів, модулів, компонентів, програмних аспектів тощо);
4) визначення правил і порядку інженерної діяльності для побудови з простих об'єктів нових
складніших (ПС, сімейств систем, лінійок ПП);
5) формалізація методів вимірювання та оцінювання ПП і процесів їх кнструювання.
Комп’ютерні науки (Computer Science, Інформатика): теорія та формальне підґрунтя створення
алгоритмів і комп’ютерних програм.
Програмна інженерія займає центральне місце серед комп'ютерних наук; вона надає парадигми,
теорії та концепції для кожної з них, визначає процеси розроблення, конфігурування, розгортання та
обслуговування створених ПП (рис.1.2).

Комп’ютерна
інженерія

Теорія, концепції, Методи та прийоми Застосування,розгортання,

засади розроблення
конфігурування
Інформаційні системи ++
Інформаційні технології ++ +++ +
Програмна інженерія ++++ ++++ ++++
Системна інженерія ++ +++ +++
Комп’ютерна інженерія +
Рисунок 1.2 – Позиція ІПЗ в комп’ютерних науках
1.3.2 Структура та нормативне забезпечення ІПЗ
Для опису внутрішньої структури ІПЗ наразі застосовують два ракурси:
1) згідно з актуальним Зводом знань з ПІ – Software Engineering Body of Knowledge версії 3, 2014
(SWEBoK V.3), локалізованим як ДСТУ ISO/IEC TR 19759:2016 (ISO/IEC TR 19759:2015, IDT) Програмна
інженерія. Настанова щодо ядра знань програмної інженерії) та підтримуючими Зводами знань з
проектного менеджменту та бізнес-аналізу – так званими «трьома китами» ІПЗ (рис.1.3);
2) згідно з прагматичним виокремленням, на підставі статусу й спрямованості відповідних знань,
п’яти «дисциплін» ІПЗ, запропонованих д.ф.-м.н., проф. Лавріщевою К.М.:
 наукової;
 інженерної;
 виробничої;
 дисципліни керування;
 економічної.
SWEBoK V.3 систематизує загальновизнані знання з ІПЗ у форматі 15 областей знань (knowledge
areas) і 7 пов’язаних дисциплін (related disciplines).
 5

ІПЗ

Рисунок 1.3 – Засадничі Зводи знань («три кити») та складники методичного забезпечення ІПЗ
Надано такі області знань (SWEBOKv3.pdf – лише для довідки).
1. Програмні вимоги (Software Requirements).
2. Проектування (створення архітектури) – Software Design.
3. Конструювання програмного забезпечення (Software Construction).
4. Тестування (Software Testing).
5. Обслуговування програмного забезпечення (Software Maintenance).
6. Керування конфігурацією програмного забезпечення (Software Configuration Management).
7. Управління конструюванням програмного забезпечення (Software Engineering Management).
8. Процес конструювання програмного забезпечення (Software Engineering Process).
9. Моделі та методи програмної інженерії (Software Engineering Models and Methods).
10. Якість програмного забезпечення (Software Quality).
11. Професійна практика програмної інженерії (Software Engineering Professional Practice).
12.Економіка програмної інженерії (Software Engineering Economics).
13.Засади обчислень (Computing Foundations).
14.Математичні засади (Mathematical Foundations).
15.Засади конструювання (Engineering Foundations).
Перелік пов’язаних дисциплін містить:
1. Комп’ютерну інженерію (Computer Engineering);
2. Комп’ютерні науки (Computer Science);
3. Загальний менеджмент (General Management);
4. Математику (Mathematics);
5. Проектний менеджмент (Project Management);
6. Управління якістю (Quality Management);
7. Системну інженерію (Systems Engineering).
Виділені області знань і дисципліни безпосередньо містять засади ефективного конструювання
унікальних ПС/ПП за умов невизначеності у форматі програмного проекту, тоді як решта стосуються
також і операціональної діяльності у відносно регламентованих процесах.
Зокрема, область знань 11 «Професійна практика програмної інженерії», вперше виокремлена в
SWEBoK V.3, визначає дві групи рис виконавців програмного проекту, критичних для його успіху:
– професіоналізм у кваліфікаційному й етичному аспектах;
– розвинуті м’які, насамперед комунікативні та презентаційні, навички (рис.1.4, 1.5).
 6

Рисунок 1.4 – Високорівнева структура компетенцій фахівця з програмної інженерії «поза

програмуванням» за SWEBOK V.3

Рисунок 1.5 – Істотні м’які навички Software Engineer – фахівця з ІПЗ

У свою чергу, загальновизнаний доробок проектного менеджменту фіксують:
1) «другий кит» – відповідний Звід знань Інституту управління проектами (PMI) США (Project
Management Body of Knowledge, PMBOK), що є міжнародним стандартом де-факто та національним
стандартом США. Наразі чинна 7 редакція (серпень 2021р). (PMBоK7_2021.pdf – лише для довідки);
стандартом де-факто залишається 6 редакція (6 вересня 2017р.);
2) альтернатива PMBOK – Засади компетенцій Міжнародної асоціації з управління проектами (IPMA)
–IPMA Competence Baseline, 4 версія, 2015;
3) ISO 10006:2017. Quality Management Systems. Guidelines for Quality management in projects,
4) ISO 21500:2021 Project, programme and portfolio management — Context and concepts,
 7

5) ISO 21502:2020 Project, programme and portfolio management. Guidance on project management.
PMBOK 6 ред. фіксує 10 областей знань, в яких реалізуються процеси керування з п’яти рамкових
груп (рис.1.6).

Рисунок 1.6 – Рамкові області знань і процеси керування (програмним) проектом за PMBOK 6 ред.
У PMBOK 7 ред. десять областей знань замінені вісьмома «областями продуктивності»
(performance domain):
1) співпраця з причетними сторонами (stakeholders);
2) керування проектною командою;
3) керування життєвим циклом проекту та продукту (методологія, етапи, поставка результатів)
4) планування проекту;
5) керування роботами проекту (project work)
6) опрацювання невизначеності та нечіткості (Navigating uncertainty and ambiguity)
7) поставка результатів зі створенням цінності (project delivery)
 8

8) оцінка й відстеження ефективності проекту (project performance)

Менеджер (програмного) проекту позиціонується як лідер, який не стільки формально забезпечує
його результати (deliverables), скільки насамперед створює й розвиває середовище максимізації
цінності для так званих причетних сторін (stakeholders, стейкхолдерів ) – осіб та організацій, які можуть
позитивно/негативно впливати на перебіг проекту та інтереси яких зазнають його впливу.
Надано також 12 принципів запровадження й використання системи надання цінності за допомогою
проектів.
1. Відповідальне керівництво: бути турботливим, поважати та підтримувати свою проектну команду.
2. Командна робота: створювати культуру поважної вимогливості до результатів.
3. Залучення зацікавлених сторін: прагнути зрозуміти інтереси та очікування зацікавлених сторін і
залучати їх до процесу створення цінності.
4. Створення цінності: сфокусуватися на максимізації цінності для замовника і організації.
5. Цілісне сприйняття: cприймати проєкт, як елемент більшої системи. Враховувати взаємозв’язки в
середині системи при реалізації проєкту.
6. Керівництво: вчити, наставляти і надихати учасників проєктної команди.
7. Налаштування: вибирати ту методологію управління проектом, яка максимізує цінність для
замовника і організації.
8. Якість: вбудовувати якість в процес створення результатів.
9. Управління складністю (navigate complexity): знижувати складність проекту, використовуючи
навички, знання і досвід.
10. Загрози і можливості: мінімізувати загрози і максимізувати можливості.
11. Адаптивність і стійкість: вміти діяти за ситуацією, зберігаючи фокус на створенні цінності.
12. Управління змінами: бути готовим і управляти змінами, які допоможуть реалізувати задум
проекту.
Уточнення універсальних дій з управління проектом для програмного проекту надає відповідне
Розширення (Extension) до Project Management BoK (PMBoK) 5 редакції.
Третій «кит» – Звід знань з аналізу ділових процесів (Business Analysis BoK, BABoK) Міжнародного
інституту бізнес-аналізу – фіксує універсальні компетенції з підтримки ділових процесів в організації-
розробнику програмних продуктів:
1. Аналітичне мислення та вирішення проблем.
2. Особливості поведінки
3. Знання ділових процесів
4.Комунікативні навички
5. Навички взаємодії.
6. Знання інструментів і технологій.
(жирним шрифтом виділено «з’єднувальні» області знань).
Призначеність ІПЗ як наукової дисципліни: застосування знань, здобутих з фундаментальних наук,
для побудови великих і складних ПП – принаймні, моделювання їх поведінки та виробництво коду для
виконання на ПК або гаджеті. Теоретичний базис ІПЗ поєднує:
а) основні поняття ІПЗ:
 дані та структури даних;
 функції та композиції над даними;
 базові об'єкти (модулі, компоненти, каркаси, контейнери тощо);
 цільові об'єкти (програмне забезпечення, програмна система, сімейство систем,
 програмний проект, процес конструювання).
 б) доробок фундаментальних наук, підсумований в областях знань 13-15 SWEBoK V.3 – засади
обчислень, конструювання та математичні засади, зокрема:
 теорії алгоритмів;
 математичної логіки;
 теорії автоматичного керування;
 теорії доведення;
 теорії множин.
Призначеність ІПЗ як інженерної дисципліни: виробництво ПЗ.
Складниками підґрунтя інженерної дисципліни є:
 9

 Звід знань SWEBOK V3 – теоретичні засади та формальні визначення методів і засобів розробки;
 Звід знань PMBOK 6, 7 ред. – принципи та методи планування й контролювання робіт у
програмному проекті
 рамковий процес конструювання ПП, поданий системою процесів їх життєвого циклу (ЖЦ);
 інфраструктура – середовище розробки;
 стандарти ІПЗ де-юре й де-факто – регламентовані правила й кращі практики побудови проміжних
артефактів у процесах ЖЦ і кінцевого ПП;
 прикладні засоби та інструменти розробки ПП.
Інфраструктура ІПЗ – система апаратного забезпечення, нормативно-методичних, програмних і
людських ресурсів організації-розробника, необхідних для ефективного виконання рамкового процесу
конструювання ПП.
Програмні ресурси – загальносистемне ПЗ, середовище розробки, (не)програмні ресурси
повторного використання організації-розробника, інформаційне забезпечення.
Нормативно-методичні ресурси – методики, процедури, правила, рекомендації, документи, що
регламентують процес розробки.
Людські ресурси: групи розробників з функціональними ролями, відповідними основним діяльностям
під час розробки, та менеджерів проекту.
Стандарти ІПЗ систематизують:
а) за змістом:
 засадничі (напр., ISO/IEC/IEEE 12207);
 щодо окремих видів діяльності в ЖЦ (ISO/IEC/IEEE 29148 );
 щодо основних характеристик ПП, процесів, проектів, які необхідно забезпечувати й відстежувати
(напр., ISO/IEC/IEEE 25010);
б) за рівнем загальності: де-юре (міжнародні й національні, зокрема ДСТУ); корпоративні;
авторитетних фахових спільнот; авторські – пропозиції авторитетних фахівців з ІПЗ.
Призначеність ІПЗ як виробничої дисципліни: автоматизоване виготовлення ПП з використанням
готових (не)програмних ресурсів організації-розробника та з мережі Інтернет.
ПП конструюються з програмних компонентів (КПВ) і непрограмних ресурсів (РПВ) повторного
використання, збережуваних у спеціальних сховищах (репозиторіях ПЗ) організації-розробника або у
відповідних реєстрах Інтернет згідно з рис.1.7.
Модель
предметної
КПВ1 КПВ2 КПВn області Виробництво
... ПП
Конфігурування
Репозиторій
Рисунок 1.7 – Рамкова схема виготовлення ПС/ПП з КПВ
Інженерні підходи до використання КПВ і РПВ, розвинуті для побудови так званих Сімейств ПС і
лінійок ПП:
 конструювання КПВ (reuse engineering): проектування ПС знизу догори з виокремленням КПВ під
час пректування;
 конструювання застосунків (application engineering): проектування ПС згори донизу з зіставленням
КПВ, вже наявних у репозиторії,передбаченим функціям ПС;
 доменна інженерія (domain engineering): одночасне проектування й конструювання КПВ і ПС як
результату їх конфігурування, що нагадує процес конвеєрного збирання.
Призначеність ІПЗ як дисципліни керування: автоматизація та оптимізація процесів керування
конструюванням ПП.
Теоретичне підґрунтя дисципліни керування – теорія керування складними системами, до якої в
1970-х роках вагомий внесок зробили фахівці ІК АН УРСР під керівництвом Академіка В.М.Глушкова.
Практичні інструменти його використання підсумовані в Зводах знань PMBoK 6,7 ред. і стандартах з
проектного менеджменту.
Нарешті, призначеність економіки ІПЗ:
 прогнозування/оцінка вартості, трудомісткості та часу розроблення ПС/ПП для складання
контрактів на їх створення, прийняття проектних рішень, вибору варіанту архітектури;
 прогнозування/відстеження та опрацювання ризиків конструювання ПС/ПП за певних ресурсів.
 10

Для оцінки трудомісткості й витрат на виробництво ПС/ПП застосовують спеціальні моделі, напр.,:
COCOMO, SLIM.
1.4 Основні поняття ІПЗ
Приймемо базові робочі визначення.
1. Програмна система (Software system, ПС) – група інтегрованих програмних засобів, що
підтримують певний діловий процес Споживача і можуть використовувати спільні сховища даних.
2. Програмне забезпечення – сукупність ПЗ, що придбаваються або розробляються для
експлуатації в складі ПС. Будемо говорити «програмне забезпечення системи», якщо потрібно
підкреслити його приналежність до ПС (яка охоплює також технічне, організаційне та інші види
забезпечення). Отже, програмне забезпечення - це не тільки програми, але й уся документація щодо
них.
Організаційною формою створення ПС є
3. Програмний проект – обмежена в часі діяльність, метою якої є створення унікальної ПС.
Сукупність завершених, виконуваних та потенційно можливих програмних проектів в організації-
розробнику ПС утворює процес програмної інженерії. Іншими словами,
4. Процес програмної інженерії, або конструювання, ПС (Software Engineering) – система логічно
взаємопов'язаних видів діяльності з визначення, проектування та побудови ПС і, можливо, побічних
програмних продуктів.
5. Життєвий цикл розроблення (ЖЦ) ПС – період її існування від початку розроблення до
впровадження/продажу. ЖЦ являє собою набір впорядкованих стадій (аналіз вимог, проектування,
реалізація, тестування, дослідна експлуатація).
6. Робочий продукт ПС – подання знань розробників щодо неї на певній стадії її розроблення
(вимоги та документи їх специфікації, опис архітектури, різні подання коду й тестів, звіти про
тестування).
1.5 Принципи ІПЗ
Практичне застосування розглянутого вмісту ІПЗ підтримано наразі трьома групами її принципів.
1.5.1 Принципи опрацювання складності під час конструювання програмних сутностей
1. Абстрагування (abstraction) та уточнення (refinement).
2. Модульність – організація великих систем у формі наборів підсистем, модулів або компонентів.
3. Виокремлення інтерфейсів і приховування внутрішньої інформації. Модулі мають
взаємодіяти один з одним через чітко певні інтерфейси і приховувати один від одного внутрішню
інформацію — внутрішні дані, деталі реалізації інтерфейсних операцій.
4. Спеціальні властивості інтерфейсів модуля:
–адекватність (інтерфейс підтримує розв’язання саме задач, необхідних користувачам модуля);
–повнота (підтримуються всі значущі задачі, зумовлені функціями модуля);
–ненадлишковість (жодну операцію не можна вилучити);
–простота (операції не можна подати композиціями простіших операцій на тому ж рівні абстракції,
за того ж розуміння функціональності модуля)
5. Розподіл відповідальності:
–подання відносно незмінних часткових алгоритмів (політик) параметрами загального алгоритму;
–відокремлення спостережного ззовні опису розв’язуваних задач (інтерфейсу) від способу
розв’язання (реалізації).
6. Слабка зв'язність (coupling) модулів і сильне зчеплення (cohesion) функцій в одному модулі.
7. Повторне використання КПВ, РПВ, ПС.
1.5.2 Принципи ефективного надання цінності причетним сторонам
Це 12 принципів створення цінності з PMBoK 7 ред., п.1.3.2.
1.5.3 Принципи етичної професійної поведінки фахівція з ІПЗ
Необхідність найефективнішої координації діяльності фахівців у групах і між групами процесу
конструювання за допомогою додаткових компетенцій, не пов’язаних безпосередньо із створенням ПП,
– «м’яких» навичок, знань та умінь – зафіксована також в чинному Кодексі етики та професійної
практики ІПЗ (IEEE-CS/ACM Software Engineering Code of Ethics and Professional Practices (див.
Жихаревич_ПППІ.pdf, підрозд.5.3, с.219-228).
Кодекс визначає вісім Принципів професійної поведінки фахівця з ІПЗ.
 11

1. СУСПІЛЬСТВО.
Програмні інженери мають діяти неухильно на користь суспільства.
2. КЛІЄНТ І ПРАЦЕДАВЕЦЬ
Програмні інженери повинні діяти згідно з інтересами клієнта і працедавця, якщо вони не суперечать
інтересам суспільства.
3: ПРОДУКТ
Програмні інженери повинні забезпечувати відповідність якості своїх продуктів та їх модифікацій
найвищим можливим професійним стандартам.
4. ОЦІНКИ
Програмні інженери мають підтримувати цілісність і незалежність своїх професійних оцінок.
5: МЕНЕДЖМЕНТ
Програмні інженери-менеджери та провідні співробітники повинні дотримуватися етичних підходів до
керування розробкою і підтримкою програмного забезпечення і просувати ці підходи.
6: ПРОФЕСІЯ
Програмні інженери повинні піднімати престиж і репутацію своєї професії на користь суспільства.
7: КОЛЕГИ
Програмні інженери повинні бути справедливі по відношенню до своїх колег, допомагати їм і
підтримувати.
8: ОСОБИСТА ВІДПОВІДАЛЬНІСТЬ
Програмні інженери повинні постійно вчитися навичкам обраної професії і сприяти просуванню
етичного підходу до своєї діяльності.
Лекція 2_08_09_2022. Призначення та сутність моделей життєвого циклу програмних
засобів
Корисні ресурси
Блог Б.Вейка (Bill Wake): https://xp123.com/articles/
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, підрозділи 3.1-3.6, 3.8
proIS.pdf, розділ 2,3
ЯПЗ_Т.pdf, розд. 2,підрозділи 5.1-5.3
додатково
Orlov_PI.pdf, розд.1, с.23-48; розд.2, с.83-100; розд.13
romanov_PI.pdf, с.32-38, розд.5
2.1. Поняття життєвого циклу та його моделі
Створення та масове виробництво різнорідних, зокрема (над)великих і складних програмних
продуктів (ПП) у сучасних організаціях-розробниках вимагає застосування універсальних принципів
опрацювання складності насамперед до організації діяльності зі створення ПП, тобто до процесів їх
конструювання та керування ним і до проміжних продуктів цих процесів.
Універсальні принципи опрацювання складності в інженерії програмного забезпечення (ІПЗ):
1. Абстрагування (abstraction) та уточнення (refinement).
2. Модульність – організація великих систем у формі наборів підсистем, модулів або компонентів.
3. Виокремлення інтерфейсів і приховування внутрішньої інформації.
Модулі мають взаємодіяти один з одним через чітко певні інтерфейси і приховувати один від одного
внутрішню інформацію — внутрішні дані, деталі реалізації інтерфейсних операцій.
4. Спеціальні властивості інтерфейсів модуля:
–адекватність (інтерфейс підтримує розв’язання саме задач, необхідних користувачам модуля);
–повнота (підтримуються всі значущі задачі, зумовлені функціями модуля);
–ненадлишковість (жодну операцію не можна вилучити);
–простота (операції не можна подати композиціями простіших операцій на тому ж рівні абстракції,
за того ж розуміння функціональності модуля)
5. Розподіл відповідальності:
–подання відносно незмінних часткових алгоритмів (політик) параметрами загального алгоритму;
–відокремлення спостережного ззовні опису розв’язуваних задач (інтерфейсу) від способу
розв’язання (реалізації).
6. Слабка зв'язність (coupling) модулів і сильне зчеплення (cohesion) функцій в одному модулі.
7. Багаторазове застосування.
Результатом застосування принципів 1-7 до процесів конструювання ПП й керування ним є поняття:
– життєвого циклу (ЖЦ) програмного забезпечення (ПЗ), зокрема ПП і програмних систем (ПС);
– моделі ЖЦ ПЗ.
Визначення 2.1. Життєвий цикл ПЗ (ПС, ПП, сервісу, іншої програмної сутності) у широкому
сенсі – період його розвитку від задуму до вилучення.
(ДСТУ ISO/IEC/IEEE 24765:2017. Словник ISO/IEC/IEEE з інженерії систем і програмного
забезпечення, ДСТУ ISO/IEC/IEEE 12207:2018, 15288:2015).
Життєвий цикл ПЗ у вузькому сенсі – період від задуму ПЗ до початку його функціонування за
призначенням: введення в експлуатацію на об’єкті автоматизації і/або випуску на ринок масового
споживання.
Життєвий цикл (ЖЦ) програмних засобів або програмно-апаратної системи охоплює принаймні такі
високо-рівневі діяльності:
– аналіз предметної області,
– збирання та документування вимог,
– реалізація/виробництво (включно з проектуванням, кодуванням, тестуванням),
– впровадження/продаж,
– експлуатація,
– обслуговування,
– вилучення з експлуатації.
Кожна діяльність являє собою достатньо однорідний набір дій, виконуваних для вирішення одного
завдання або групи тісно пов'язаних завдань з розроблення та підтримки експлуатації програмних
засобів (ПЗ).
У результаті діяльностей створюються і перероблюються робочі продукти.
 2
Визначення 2.2. Артефакт, або робочий продукт, – створювана людиною інформаційна,
зокрема програмна, сутність, яка перетворює певні вхідні дані у вихідні в результаті виконання різних
діяльностей і є поданням знань розробників ПП щодо нього у відповідний момент його ЖЦ.
Приклади артефактів: модель предметної області, опис вимог, технічне завдання, архітектура
системи, проектна документація на систему в цілому і на її компоненти, прототипи системи і
компонентів, власне, початковий код, документація користувача , документація адміністратора системи,
настанова з розгортання, база запитів користувача, план проекту.
Впродовж ЖЦ до створення й експлуатації ПЗ залучаються фахівці, що виконують різні ролі.
Визначення 2.3. Роль у ЖЦ ПЗ – опис сукупності можливостей і відповідальностей групи
зацікавлених сторін, що беруть участь в діяльності зі створення й експлуатації ПЗ і розв’язують одні й ті
самі задачі або мають одні й ті самі інтереси щодо неї.
Приклади ролей: бізнес-аналітик, інженер з вимог, архітектор, проектувальник призначеного для
інтерфейсу користувача, програміст-кодувальник, технічний письменник, тестувальник, менеджер
програмного проекту, співробітник відділу обслуговування, кінцевий користувач.
Стале забезпечення рівня результативності й економічної ефективності процесу конструювання
програмних продуктів у сучасних організаціях-розробниках потребує розроблення й апробації
відповідних структур ЖЦ і стандартизації тих, які засвідчили свою перспективність. Форматом опису
такої структури є модель ЖЦ.
Визначення 2.4. Модель ЖЦ ПЗ або ПС – схема, що охоплює процеси, діяльності та завдання під
час розроблення, експлуатації та обслуговування ПЗ і ПС.
(ДСТУ ISO/IEC/IEEE 24765:2017).
Модель ЖЦ ПЗ і ПС:
1) фіксує конкретні набори діяльностей (зазвичай деталізованих до завдань та операцій),
артефактів, ролей та, необов’язково, їх взаємозв’язки;
2) надає рекомендації з організації ЖЦ загалом. Рекомендації містять відповіді на питання, які
артефакти є вхідними для яких діяльностей і які є їх наслідками, які ролі залучено до різних
діяльностей, як ці діяльності пов’язані між собою, які критерії застосовують для оцінки якості отриманих
наслідків, як оцінити відповідність робочих продуктів цілям програмного проекту та стратегічним цілям
організації, коли доцільно й можливо переходити від однієї діяльності до іншої.
Уточнюючі цілі застосування моделей ЖЦ:
1) забезпечення ефективної взаємодії між учасниками процесу конструювання програмних
продуктів, зокрема розробників, замовників¿споживачів;
2) контролювання перебігу робіт, оцінювання робочих продуктів і кінцевого продукту на відповідність
вимогам;
3) балансування витрат і ризиків створення робочих продуктів і кінцевого продукту;
4) підтримка прийняття рішень щодо вимог, цінність реалізації яких у програмному продукті
виправдовує витрати на розроблення і/або на весь ЖЦ (affordability analysis – аналіз обґрунтованості
вимог);
5) стале вдосконалення процесів ЖЦ.
Наразі в моделях ЖЦ ПЗ застосовують дві категорії основних елементів:
1) технологічні процеси;
2) окремі діяльності.
Визначення 2.5. Процес ЖЦ ПЗ або ПС – система взаємопов’язаних дій, результатом яких є
розроблення або оцінювання ПЗ чи ПС. Кожну діяльність складено з завдань, і процеси можуть
охоплювати спільні діяльності.
Відповідно, розроблено дві групи моделей ЖЦ: процесні та стадійні.
2.2. Процесні моделі ЖЦ ПЗ
Кожна модель подана системою взаємопов’язаних процесів – сукупностей дій з досягнення певних
цілей, зафіксованих у відповідних стандартах де-юре й де-факто, розглядуваних у період від задуму
ПЗ/ПС до його вилучення з експлуатації.
1. Загальноприйнята рамкова процесна модель ЖЦ ПЗ зафіксована в міжнародному стандарті
ISO/IEC/IEEE 12207:2017 та його вітчизняному відповіднику ДСТУ ISO/IEC/IEEE 12207:2018
(ISO/IEC/IEEE 12207:2017, IDT) Інженерія систем і програмних засобів. Процеси життєвого циклу
програмних засобів.
Модель визначає чотири групи процесів ЖЦ ПЗ, поданих у табл.2.1:
1) процеси угоди (agreement processes);
2)організаційні процеси уможливлення проектів (Organizational Project-Enabling processes);
3) технічні процеси керування включно з процесами проекту (Technical Management processes);
 3
4) технічні процеси (Technical processes).
Для кожного з процесів ЖЦ ПЗ в межах цих груп описано його мету, бажані результати, завдання та
заходи, які необхідно виконати для досягнення цих результатів.
Таблиця 2.1 – Рамковий склад процесів ЖЦ ПЗ за ISO/IEC/IEEE 12207:2017
1. Процеси 2. Організаційні процеси 3. Процеси технічного 4. Технічні процеси
угоди уможливлення проекту керування (Technical (Technical processes)
(Agreement (Organizational Project- Management processes)
processes) Enabling processes)
1.1 Процес 2.1 Life cycle model 3.1 Project Planning process 4.1 Business or Mission
придбавання management process 3.2 Project assessment and Analysis process
(Acquisition 2.2 Infrastructure control process 4.2 Stakeholder Needs and
process) Management process 3.3 Decision Management Requirements Definition
1.2 Процес 2.3 Portfolio Management process process
постачання process 3.4 Risk Management 4.3 System/Software
(Supply 2.4 Human Resource process requirements definition
process) Management process 3.5 Configuration process
2.5 Quality Management Management process 4.4 Architecture Definition
process 3.6 Information Management process
2.6 Knowledge process 4.5 Design Definition process
Management process 3.7 Measurement process 4.6 System Analysis process
3.8 Quality Assurance 4.7 Implementation process
process 4.8 Integration process
4.9 Verification process
4.10 Transition process
4.11 Validation process
4.12 Operation process
4.13 Maintenance process
4.14 Disposal process
Для процесів ЖЦ ПЗ описано: мету, передбачені результати, завдання та заходи для їх досягнення.
2. Уточнення ДСТУ ISO/IEC/IEEE 12207:2018 надають частини ДСТУ ISO/IEC 24748
Інженерія систем і програмних засобів. Керування життєвим
ДСТУ ISO/IEC TS 24748-1:2018 циклом. Частина 1. Настанови щодо керування життєвим циклом
(ISO/IEC TS 24748-1:2016, IDT) – встановлює керівні принципи щодо управління життєвим циклом
інженерії систем і ПЗ
Розроблення систем і програмного забезпечення. Управління
життєвим циклом. Частина 2. Настанова щодо застосування
ДСТУ ISO/IEC TR 24748-2:2015
ІSO/ІEC 15288 (Процеси життєвого циклу системи) (ІSO/ІEC
TR 24748-2:2011,
Інженерія систем і програмного забезпечення. Керування життєвим
ДСТУ ISO/IEC TR 24748-3:2016
циклом. Частина 3. Настанова щодо застосування ІSO/ІEC 12207
(ISO/IEC TR 24748-3:2011, IDT)
(Процеси життєвого циклу програмного забезпечення)
ДСТУ ISO/IEC/IEEE 24748-4:2018 Інженерія систем і програмних засобів. Керування життєвим
(ISO/IEC/IEEE 24748-4:2016, IDT) циклом. Частина 4. Інженерне проектування систем
ДСТУ ISO/IEC/IEEE 24748-5:2018 Інженерія систем і програмних засобів. Керування життєвим
(ISO/IEC/IEEE 24748-5:2017, IDT) циклом. Частина 5. Планування розроблення програмних засобів
ДСТУ ISO/IEC TS 24748-6:2018 Інженерія систем і програмних засобів. Керування життєвим
(ISO/IEC TS 24748-6:2016, IDT) циклом. Частина 6. Розроблення системної інтеграції
3. IEEE Std 1074™-2006 IEEE Standard for Developing a Software Project Life Cycle Process не адаптує
ISO/IEC/IEEE 12207:2018, а містить власні активності – термінальні «заготовки» процесів і правила
конструювання з них процесів для окремого програмного проекту та проекту. Активності охоплюють:
1) керування програмними проектами;
2) дії, що передують розробленю;
3) дії з розроблення;
4) дії після розроблення з обслуговування;
5) загальні активності.
 4
2.3. Стадійні моделі ЖЦ ПЗ (див. Orlov_PI.pdf, c.29-40; ЯПЗ_Т.pdf, с.33-54, Модели_ЖЦ.pdf)
2.3.1. Класифікація стадійних моделей
Актуальні стадійні моделі ЖЦ ПС поділяються на два класи:
а) рамкові, незалежні від методології конструювання ПЗ/ПС:
б) уточнення рамкових з позицій певної методології конструювання ПЗ, які водночас являють собою
моделі відповідного програмного проекту:
 жорсткі(планові), зорієнтовані на одноразове повне визначення вимог до створюваного продукту
й одноразове послідовне виконання базових сукупностей дій з їх реалізації;
 ітеративні, згідно з якими ЖЦ являє собою послідовність ітерацій зі створення дедалі
детальніших подань ПС;
 гнучкі, де ЖЦ подається послідовністю ітерацій фіксованої тривалості, організованих згідно з
засадами Agile-маніфесту.
2.3.2. Каскадна модель
Перша модель ЖЦ – каскадна модель, де кожна робота виконується один раз згідно з рис.2.1.
Тобто вважають, що кожна робота має бути виконана настільки ретельно, що після її закінчення і
переходу до наступного етапу, повертатися до попереднього не буде потреби. Розробник перевіряє
проміжний результат відомими методами верифікації і фіксує його як готовий еталон для наступного
процесу.
Визначення завдання

Проектування системи

Реалізація системи

Тестування системи
на перевірку правиль-
ності (верифікація)

Тестування системи
на відповідність
завданню

Супровід

Рисунок 2.1 – Каскадна модель ЖЦ ПЗ

Тобто вважають, що кожна робота має бути виконана настільки ретельно, що після її закінчення і
переходу до наступного етапу повертатися до попереднього не буде потреби. Розробник перевіряє
проміжний результат відомими методами верифікації і фіксує його як готовий еталон для наступного
процесу.
Роботи і завдання процесу розроблення зазвичай виконуються послідовно (рис.2.1).
Проте допоміжні і організаційні процеси (контроль вимог, керування якістю і ін.), як правило,
виконуються разом з процесами розробки ПЗ. У даній моделі повернення до початкового процесу
передбачається після супроводження і виправлення помилок.
Особливість такої моделі полягає у фіксації послідовних процесів розроблення програмного
продукту. В її основу покладена модель фабрики, де продукт проходить стадії від задуму до
виробництва, потім його передають замовнику у вигляді готового виробу, де заміна не передбачена,
хоча можна подати інший подібний виріб.
Недоліки цієї моделі такі:
1. процес створення ПС не завжди вкладається в таку жорстку форму і послідовність дій;
2. не враховуються змінювані потреби користувачів, нестабільні умови зовнішнього середовища,
які впливають на зміни вимог до ПС під час ї розроблення;
3. значний розрив між часом внесення помилки (наприклад, на процесі проектування) і часом її
виявлення (при супроводі), що призводить до суттєвої переробки ПС.
При застосуванні каскадної моделі можуть спостерігатися такі чинники ризику:
– вимоги до ПС недостатньо чітко сформульовані, не враховують перспективи розвитку ОС,
середовищ;
– громіздка система, що не допускає компонентної декомпозиції, може викликати проблеми щодо
розміщення її в пам'яті або на платформах, не передбачених у вимогах;
– внесення швидких змін до технології і у вимоги може погіршити процес розроблення окремих
частин системи або системи в цілому;
– обмеження на ресурси (людські, програмні, технічні і ін.) в ході розробки можуть звузити окремі
можливості реалізації системи;
 5
– отриманий продукт може виявитися не придатним для застосування внаслідок нерозуміння
розробниками вимог або функцій системи або недостатньо проведеного тестування.
Переваги:
1. всі завдання підсистем і системи реалізуються одночасно, завдяки чому не можна забути
жодного завдання, а це сприяє встановленню стабільних зв'язків між ними;
2. повністю розроблену систему з документацією на неї легше супроводжувати, тестувати,
фіксувати помилки і вносити зміни не хаотично, а цілеспрямовано, починаючи з вимог, наприклад,
додавати або замінювати деякі функції і повторювати процес.
Каскадна модель придатна для створення першої версії ПЗ з метою перевірки реалізованих в ній
функцій. При супроводі і експлуатації можуть бути виявлені різного роду помилки, виправлення яких
спричинить повторне виконання всіх процесів, починаючи з уточнення вимог.
Типові приклади застосування: військові стандарти США, ГОСТ 34 і ГОСТ 19 – наразі не ДСТУ, а
стандарти де-факто.
ГОСТ 34.601-90
Стадии Этапы работ
1.1. Обследование объекта и обоснование необходимости создания АС.
1. Формирование 1.2. Формирование требований пользователя к АС.
требований к АС 1.3. Оформление отчёта о выполненной работе и заявки на разработку АС
(тактико-технического задания)
2.1. Изучение объекта.
2.2. Проведение необходимых научно-исследовательских работ.
2. Разработка концепции
2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям
АС.
пользователя.
2.4. Оформление отчёта о выполненной работе.
3. Техническое задание. 3.1. Разработка и утверждение технического задания на создание АС.
4.1. Разработка предварительных проектных решений по системе и её частям.
4. Эскизный проект.
4.2. Разработка документации на АС и её части.
5.1. Разработка проектных решений по системе и её частям.
5.2. Разработка документации на АС и её части.
5.3. Разработка и оформление документации на поставку изделий для
5. Технический проект. комплектования АС и (или) технических требований (технических заданий) на
их разработку.
5.4. Разработка заданий на проектирование в смежных частях проекта
объекта автоматизации.
6. Рабочая 6.1. Разработка рабочей документации на систему и её части.
документация. 6.2. Разработка или адаптация программ.
7.1. Подготовка объекта автоматизации к вводу АС в действие.
7.2. Подготовка персонала.
7.3. Комплектация АС поставляемыми изделиями (программными и
техническими средствами, программно-техническими комплексами,
информационными изделиями).
7. Ввод в действие.
7.4. Строительно-монтажные работы.
7.5. Пусконаладочные работы.
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний.
8.1. Выполнение работ в соответствии с гарантийными обязательствами.
8. Сопровождение АС
8.2. Послегарантийное обслуживание.
Склад документів на стадіях визначається ГОСТ 34.201-89.
Зміст документів на стадіях визначається РД -50- 34.698-90
Застосування для розроблення ПП на замовлення державних структур регламентовано
ДСТУ 3973-2000 (Науково-дослідна робота, НДР)
ДСТУ 3974-2000 (Дослідно-конструкторська, ДКР).
 6
ГОСТ 19.102-77
Единая система программной документации
СТАДИИ РАЗРАБОТКИ
1. Настоящий стандарт устанавливает стадии разработки программ и программной документации для
вычислительных машин, комплексов и систем независимо от их назначения и области применения.
2. Стадии разработки, этапы и содержание работ должны соответствовать указанным в таблице.
Стадии Этапы
Содержание работ
разработки работ
Постановка задачи.
Обоснование
Сбор исходных материалов. Выбор и обоснование критериев
необходимости
эффективности и качества разрабатываемой программы.
разработки
Обоснование необходимости проведения научно-
программы
исследовательских работ.
Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Научно- Обоснование целесообразности применения ранее
исследовательские разработанных программ.
работы Определение требований к техническим средствам.
Техническое
Обоснование принципиальной возможности решения
задание
поставленной задачи.
Определение требований к программе.
Разработка технико-экономического обоснования разработки
программы.
Разработка и Определение стадий, этапов и сроков разработки программы и
утверждение документации на нее.
технического задания Выбор языков программирования.
Определение необходимости проведения научно-
исследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.
Предварительная разработка структуры входных и выходных
данных.
Разработка эскизного
Уточнение методов решения задачи.
Эскизный проекта
Разработка общего описания алгоритма решения задачи.
проект Разработка технико-экономического обоснования.
Утверждение Разработка пояснительной записки.
эскизного проекта Согласование и утверждение эскизного проекта
Уточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных
Разработка
данных.
технического проекта
Определение семантики и синтаксиса языка.
Технический Разработка структуры программы.
проект Окончательное определение конфигурации технических средств.
Разработка плана мероприятий по разработке и внедрению
Утверждение программ.
технического проекта Разработка пояснительной записки.
Согласование и утверждение технического проекта.
Разработка
Программирование и отладка программы
программы
Рабочий
проект Разработка
Разработка программных документов в соответствии с
программной
требованиями ГОСТ 19.101-77.
документации
 7
Стадии Этапы
Содержание работ
разработки работ
Разработка, согласование и утверждение программы и методики
испытаний.
Проведение предварительных государственных,
Испытания программы межведомственных, приемо-сдаточных и других видов
испытаний.
Корректировка программы и программной документации по
результатам испытаний.
Подготовка и передача программы и программной документации
для сопровождения и (или) изготовления.
Подготовка и
Внедрение Оформление и утверждение акта о передаче программы на
передача программы
сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программ.
2.3.3. Інкрементна модель
Цю модель (incremental) ще називають моделлю з нарощуванням або з приростом. Її суть полягає в
розробці продукту ітераціями, і кожна ітерація закінчується випуском працездатної версії. У кожній новій
версії додаються деякі функціональні можливості. Розробка системи починається з визначення набору
всіх вимог до ПС і ділення процесу розроблення на ітерації. Кожна ітерація реалізується послідовно з
використанням процесів ЖЦ і фіксації робочої версії системи, системи, що поступово наближається до
остаточної версії (рис. 2.2).

Проект Реалізація Тестування Випуск 1

Аналіз вимог
і попереднє Проект Реалізація Тестування Випуск 2
тестування

Проект Реалізація Тестування Випуск 3

Рисунок 2.2. Інкрементна модель ЖЦ

Перша проміжна версія системи, що створюється (випуск 1), реалізує частину вимог, у подальшу
версію (випуск 2) додають додаткові вимоги до тих пір, поки не будуть остаточно виконані всі вимоги і
розв’язані задачі розробки системи.
Для кожної проміжної версії на процесах ЖЦ виконуються необхідні процеси, роботи і завдання,
зокрема, аналіз вимог і створення нової архітектури, які можуть бути виконані одночасно.
Процеси розроблення технічного проекту програмної системи, її програмування і тестування,
збирання і кваліфікаційні випробування ПС виконуються при створенні кожної подальшої версії.
Відповідно до даної моделі ЖЦ, процеси якої практично такі самі, як і в каскадній моделі, наголос
робиться на побудову деякої закінченої проміжної версії, а завдання процесу розроблення виконуються
послідовно або частково паралельно для ряду окремих проміжних структур версії.
Роботи і завдання процесу розроблення наступної версії системи з додатковими вимогами або
функціями можуть виконуватися неодноразово в одній тій же послідовності для всіх проміжних версій
системи. Процеси супроводження і експлуатації можуть бути реалізовані разом з процесом
розроблення версії шляхом перевірки частково реалізованих вимог в кожній проміжній версії і так до
отримання кінцевого варіанта системи. Допоміжні і організаційні процеси ЖЦ зазвичай виконуються
разом з процесом розроблення версії системи і до кінця розробки збираються дані, на підставі яких
можна встановити рівень завершеності і якості виготовленої системи.
При застосуванні даної моделі необхідно враховувати такі чинники ризику:
– вимоги складені з урахуванням можливості їх зміни при реалізації продукту;
– всі можливості системи потрібно реалізувати одразу;
– швидка зміна технології і вимог до системи може призвести до порушення отриманої структури
системи;
– обмеження в ресурсному забезпеченні (виконавці, фінанси) можуть призвести до несвоєчасного
введення системи в експлуатацію.
Ця модель ЖЦ доцільна, коли:
 8
– бажано реалізувати деякі можливості системи швидко за рахунок створення проміжної версії
продукту;
– ПЗ декомпозують на окремі складники, які можна реалізовувати як деякі самостійні проміжні або
готові продукти;
– можливе збільшення фінансування на розробку окремих частин системи.
2.3.4. Спіральна модель (Б.Боем)
Виходячи з можливості внесення змін, як в процес, так і в проміжний продукт було створено
спіральну модель ЖЦ (рис.2.3).
Внесення змін орієнтоване на задоволення потреби користувачів одразу, як тільки буде
встановлено, що створені артефакти або елементи документації не відповідають дійсному стану
розробки.
Дана модель ЖЦ допускає аналіз продукту на витку розробки, його перевірку, оцінку правильності та
прийняття рішення про перехід на наступний виток або повернення на попередній виток для
доопрацювання на ньому проміжного продукту.
Відмінність цієї моделі від каскадної полягає в можливості багато разів повертатися до процесу
формулювання вимог і до повторної розробки версії системи з будь-якого процесу моделі.

Рисунок.2.3 – Спіральна модель ЖЦ розробки програмних систем

Для програмного продукту така модель у первинному вигляді має обмеження:
По-перше, висловлення вимог замовником носить суб'єктивний характер, вимоги можуть
багаторазово уточнюватися протягом розробки ПС i навіть після завершення та випробовування, і
часом може з'ясуватися, що замовник «хотів зовсім інше».
По-друге, змінюються обставини та умови використання системи, тому загальновизнаним законом
програмної інженерії є закон еволюції, який сформулюємо так: кожна діюча ПС з часом потребує
внесення змін або виводиться з експлуатації.
При необхідності внесення змін до системи на кожному витку з метою отримання нової версії
системи обов'язково переглядаються попередньо зафіксовані вимоги, після чого повертаються на
попередній виток спіралі для продовження реалізації нової версії системи з урахуванням усіх змін.
2.3.5. Еволюційна модель
У разі еволюційної моделі система послідовно розробляється з блоків конструкцій. На відміну від
інкрементної моделі в еволюційній моделі вимоги встановлюються частково і уточнюються в кожному
наступному проміжному блоці структури системи.
 9
Використання еволюційної моделі припускає проведення дослідження предметної області для
вивчення потреб її замовника і аналізу можливості застосування цієї моделі для реалізації. Модель
використовується для розробки нескладних і некритичних систем, де головною вимогою є реалізація
функцій системи. При цьому вимоги не можуть бути визначені відразу і повністю. Тому розробка
системи здійснюється ітераційним шляхом її еволюційного розвитку з отриманням деякого варіанта
системи–прототипу, на якому перевіряється реалізація вимог. Іншими словами, такий процес за своєю
суттю є ітераційним, з етапами розробки, що повторюються, починаючи від змінених вимог і закінчуючи
отриманням готового продукту. В деякому розумінні до цього типу моделі можна віднести спіральну
модель.
Розвитком цієї моделі є модель еволюційного прототипування в рамках усього ЖЦ розробки ПС
Аналіз
доцільності
моделі

Дослідження
замовника

Ітерація
розробки Реалізація
функціонального
прототипу

Ітерація
проектування
і побудови

Рисунок 2.4 – Модель еволюційного прототипування

Методологія розробки за цією моделлю часто зветься RAD (Rapid Application Development).
У даній моделі наведені дії, які пов'язані з аналізом її застосовності для конкретного виду системи, а
також обстеженням замовника для визначення потреб користувача при розробці плану створення
прототипу.
У моделі є дві головні ітерації розробки функціонального прототипу, проектування і реалізації
системи з метою перевірки, чи задовольняє вона всі функціональні і нефункціональні вимоги. Основною
ідеєю цієї моделі є моделювання окремих функцій системи в прототипі і поступове еволюційне його
доопрацювання до виконання всіх заданих функціональних вимог.
Ітерацій з отримання проміжних варіантів прототипу може бути декілька, в кожній з яких додається
функція і повторно моделюється робота прототипу. І так до тих пір, поки не будуть промодельовані всі
функції, задані у вимогах до системи. Після цього виконується ще одна ітерація – остаточне
програмування для отримання готової системи.
Ця модель застосовується для систем, в яких найбільш важливими є функціональні можливості, і які
необхідно швидко продемонструвати на CASE-засобах.
Оскільки проміжні прототипи системи відповідають реалізації деяких функціональних вимог, їх
можна перевіряти і під час супроводу і експлуатації, тобто разом з процесом розробки чергових
прототипів системи. При цьому допоміжні і організаційні процеси можуть виконуватися разом з
процесом розроблення і накопичувати відомості за даними кількісних і якісних оцінок на процесах
розроблення.
При цьому враховуються такі чинники ризику:
– реалізація всіх функцій системи одночасно може призвести до громіздкості;
– обмежені людські ресурси зайняті розробкою протягом тривалого часу.
Переваги:
– швидка реалізація деяких функціональних можливостей системи і їх апробація;
– використання проміжного продукту в наступному прототипі;
– виділення окремих функціональних частин для реалізації їх у вигляді прототипу;
– можливість збільшення фінансування системи;
– зворотний зв'язок із замовником для уточнення функціональних вимог;
– спрощення внесення змін у зв'язку із заміною окремих функції.
Модель розвивається у напряму додавання нефункціональних вимог до системи, пов'язаних із
захистом і безпекою даних, несанкціонованим доступом до них і ін.
 10
2.3.6. Спіральна модель покрокових зобов’язань Б.Боема (Incremental Commitment Spiral Model,
див. What_is_ICSM.pdf)
Для опрацювання трендів сучасної програмної інженерії, які ускладнюють виробництво
конкурентоздатних програмних продуктів, під керівництвом Б.Боема надано розвиток спіральної моделі.
Назва отриманої моделі – спіральна модель покрокових зобов’язань (рис.2.5) – фіксує її визначальні
особливості:
– подання ЖЦ послідовністю уніфікованих ітерацій для вдосконалюваних версій ППЗ, які становлять
цінність для причетних сторін (розробника, спонсора, споживачів, обслуговників тощо);
– спільні перегляди цими сторонами наприкінці фаз ЖЦ своїх зобов’язань щодо наступної фази на
підставі оцінок її вартості й ризику невиконання.
Уточнення вимог до версій Взаємоузгоджене
ППЗ і параметрів фаз їх конструювання
розроблення/модифікації Виконання2 версій ППЗ КС
на підставі оцінок ризику Розроблення3 та ітерацій їх
невиконання і витрат Обґрунту- Виконання1 розроблення/модифікації
для фази вання4 Розроблення2
Обґрунту-
вання3 Розроблення1
Перегляди зацікавленими Обґрунтування 2
Обґрунтування
сторонами їх зобов’язань
щодо наступної фази ЖЦ
на підставі оцінок ризику
її невиконання й вартості Вартісне аналізування
Розвідування

Припустимі дії в ЖЦ
залежно від ризику
невиконання й витрат
Прийнятний для наступної фази

Нехтовний Рівень
ризику: Надвисокий
неопрацьовний
Оцінки
витрат
на ППЗ Високий, але
опрацьовний
Рисунок. 2.5 – . Внутрішня структура ЖЦ ППЗ і КС за моделлю покрокових зобов’язань
Передбачено такі типи зобов’язань:
а) вилучення наступної фази, якщо ризик нехтовно низький, а витрати істотні;
б) її виконання за прийнятних ризику й витрат;
в) опрацювання ризику на поточній фазі, якщо він високий, але опрацьований;
г) закриття/перевизначення проекту за неприйнятних витрат і/або ризику.
Прийняття зобов’язань а)-г) вимагає принаймні рішень щодо реалізовності й доцільності чергової
версії ПЗ та складу й вмісту ітерацій з розроблення/модифікації цієї версії. Внаслідок цього невід’єм-
ним складником ЖЦ ПЗ стає процес експертно-аналітичного оцінювання витрат на ПЗ з
використаням сімейства моделей COCOMO (див. Л13_24_11_2022_Економіка_ПІ.pdf), який вчасно
надає адекватні оцінки витрат на підтримку заначених рішень. По-фазні перегляди визначають для
нього організаційну інфраструктуру й технологічні регламенти перебігу.
Наведені тут «кільця спіралі» й занумеровані кружечки на них відображають ітерації з їх фазами та,
відповідно, по-фазні перегляди з припустимими зобов’язаннями.
Модель покрокових зобов’язань передбачає для розроблення/модифікації версії ППЗ дві стадії:
Покрокове визначення та Покрокове розроблення й виконання. Для кожної i-ї версії ППЗ, починаючи з
другої, перша стадія містить єдину фазу Обґрунтування. Згідно зі своєю назвою, друга стадія охоплює
фази Розроблення й Виконання. Як показано на рисунку, протягом кожної ітерації різні (але ефективно
взаємодіючі) команди одночасно реалізують фази Виконання для (i-1)-ї ітерації, Розроблення – для i-ї
та Обґрунтування – для (i+1)-ї, i>1.
Ураховуючи особливу роль першої версії, яка істотно обумовлює рішення щодо доцільності й вмісту
подальших ітерацій, перша стадія для неї містить додаткові фази Розвідування й Вартісного
аналізування. Аналізування може бути пропущено, якщо перегляд зобов’язань після Розвідування
засвідчує нехтовно низький ризик його невиконання. Отже, першій версії в загальному випадку
відповідають п’ять ітерацій. Перші три з них, що складають стадію її Визначення і тому відокремлені на
рис.2.5 прапорцем і штриховою лінією, далі не повторюються й містять по одній фазі, на відміну від
решти ітерацій.
 11
2.4 Моделі ЖЦ з урахуванням методології програмного проекту
2.4.1 Ітеративні моделі
2.4.1.1 Раціональний уніфікований процес ( див. Orlov_PI.pdf, розд.13, с. 386-413;
romanov_PI.pdf, 5.1, c.183-196)
Agile UP - http://www.ambysoft.com/unifiedprocess/agileUP.html
2.4.1.2 ICONIX (ICONIX.pdf, c.13-24)
2.4.1.3 MSF, MSF for Agile Software Development, MSF for CMMI Process Improvement
Чаще всего все требования на задание действительно практически невозможно определить
заранее, к тому же даже сформулированные требования подвергаются коррекции. Но тогда требуется
повысить уровень управляемости проектом, без чего создание сложного ПО просто невозможно.
Компромисс между этими противоречивыми требованиями и предоставляет модель процессов MSF, в
которой сочетаются водопадная и спиральная модели разработки: проект реализуется поэтапно, с
наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться
по спирали.
В этом случае планирование на основе промежуточных контрольных точек и предсказуемость
водопадной модели дополняются наличием обратной связи с заказчиком и творческим подходом к
решению задач, характерными для спиральной модели. Таким образом, модель процессов MSF
позволяет создавать и развертывать решения уровня предприятия, обеспечивая прогнозируемость
хода проектов и учитывая реальные условия их выполнения.
Создание общей картины приложения
На этом этапе решаются следующие основные задачи:
– определение состава команды;
– определение структуры проекта;
– определение бизнес–целей;
– оценка существующей ситуации;
– создание документа общей картины и области действия проекта;
– определение требований и профилей пользователей;
– разработка концепции решения;
– оценка риска;
– закрытие этапа.
На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и
"Создана общая картина решения".
Организован костяк команды. Здесь не обязательно нужен полный поименный список команды,
но в документе структуры проекта должны быть определены роли и обязанности каждого члена
команды, а также описана иерархия отчетности и ответственности в группе, каналы взаимодействия с
заказчиком и общая структура команды.
Создана общая картина решения. Речь идет о разработке концепции решения, которым должна
руководствоваться команда для достижения долгосрочных бизнес–целей проекта. Область действия
проекта определяет, что включается в контекст проекта, а что выходит за его рамки. На этой
временной точке речь идет о создании первой версии документа, который находится в стадии
рецензирования участниками команды и согласования заказчиком.
Этап завершается контрольной точкой "Утверждение документа общей картины и области действия
проекта".
Планирование
На этапе планирования команда решает, что нужно разработать, и формирует планы реализации
продукта. Готовится функциональная спецификация, создается проект решения, детализируются
планы работы, выполняется оценка стоимости и сроков получения результатов.
На этом этапе проводится анализ требований, которые делятся на бизнес–требования,
пользовательские, функциональные и системные требования. После сбора и анализа требований
команды разрабатывается проект решения, определяются профили пользователей, после чего
формируются сценарии применения решения, выполняемые пользователями одного типа, а затем
определяются варианты использования системы.
Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование. На стадии
концептуального проектирования задача рассматривается с точки зрения пользовательских и бизнес–
требований и заканчивается определением набора сценариев использования системы. При
логическом проектировании задача рассматривается с точки зрения проектной команды, решение
представляется в виде набора сервисов. И уже на стадии физического проектирования задача
 12
рассматривается с точки зрения программистов, уточняются используемые технологии и программные
интерфейсы.
В ходе данного этапа решаются такие задачи:
– разработка проекта и архитектуры решения;
– создание функциональной спецификации;
– разработка планов проекта;
– разработка календарного графика;
– создание среды разработки, тестирования и пилотной эксплуатации;
– закрытие этапа.
– Контрольные точки этапа планирования связаны с достижением следующих результатов:
– функциональная спецификация;
– план управления рисками;
– определение среды разработки и тестирования;
– генеральный план и календарный график проекта.
Результаты данного этапа служат для принятия компромиссных решений в дальнейшем.
Разработка
На этапе разработки создается решение, в том числе пишется и документируется код. В начале
этого этапа команда проверяет выполнение всех задач, характерных для предыдущих этапов, а затем
приступает к решению следующих задач:
– создание прототипа приложения;
– разработка программных компонентов приложения;
– создание решения (последовательность ежедневных или более частых сборок приложения);
– закрытие разработки (реализация всех функций, поставка кода и документации).
– Результаты этапа предполагают следующие элементы:
– исходный текст кода и исполняемые файлы;
– сценарии установки и конфигурации для развертывания;
– окончательная функциональная спецификация;
– элементы поддержки решения;
– спецификации и сценарии тестирования.
Основная контрольная точка этапа – "Окончательное утверждение области действия проекта". В
этот момент все функции продукта готовы и прошли тестирование в рамках своего модуля. После этого
продукт готов к внешнему тестированию и стабилизации. Кроме того, заказчики, пользователи,
сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут
предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.
Стабилизация
Данный этап – подготовка к выпуску окончательной версии продукта, доводка его до заданного
уровня качества. Здесь выполняется комплекс работ по тестированию (обнаружение и устранение
дефектов), а также проверяется сценарий развертывания продукта и проводится пилотная
эксплуатация.
Тестирование подразумевает следующие основные виды работ:
– тестирование компонентов;
– тестирование баз данных;
– тестирование инфраструктуры;
– тестирование защиты;
– тестирование интеграции;
– анализ удобства работы с продуктом;
– нагрузочное тестирование (включая анализ ресурсоемкости и производительности);
– регрессивное тестирование;
– ведение отчетности по тестированию.
Когда решение становится достаточно устойчивым, проводится его пилотная эксплуатация в
тестовой среде с привлечением пользователей и применением реальных сценариев работы.
Один из главных показателей этапа стабилизации – число обнаруженных ошибок. Сходимость этой
величины в сторону устойчивого уменьшения – признак того, что близится завершение работ над
 13
продуктом. Важнейшая промежуточная контрольная точка – появление версии, в которой усилиями
самой проектной команды не обнаружено ни одной ошибки. Далее следуют выпуски кандидат–релизов
продукта для их исследования в условиях пилотной эксплуатации. Завершающая контрольная точка –
подтверждение готовности продукта к выпуску и полноценному развертыванию в промышленной среде.
Развертывание
На этом этапе выполняется установка решения и необходимых компонентов окружения, проводится
его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме
того, анализируется проект в целом на предмет уровня удовлетворенности заказчика. Основные
контрольные точки данного этапа таковы:
– развернуты основные компоненты;
– развернуто решение в целом;
– развернутое решение стабилизировано;
– решение развернуто и передано в эксплуатацию заказчику.
Следует подчеркнуть, что момент завершения данного этапа бывает достаточно сложно формально
определить, так как выявление неполадок может продолжаться и в ходе промышленной эксплуатации.
Именно поэтому необходимо четко сформулировать критерии для завершающей контрольной точки
этапа развертывания и не пытаться отладить абсолютно все.
Комментарии по поводу этапов работ
Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в
основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft
и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии
от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению
различных этапов разработки и зачастую используется собственная терминология, что усложняет
проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской
терминологии.
Общепринятый на сегодня список ALM–этапов, которого, в частности, придерживаются Borland и
Rational, выглядит следующим образом:
– Defining (определение требований);
– Designing (анализ и проектирование);
– Developing (разработка);
– Testing (тестирование);
– Deploying (развертывание).
Как легко заметить, модель MSF предлагает несколько иную разбивку на этапы и их наименование.
Хотелось бы обратить внимание читателей, что речь здесь не идет просто о разных названиях одних и
тех же видов деятельности. Объективная проблема категоризации заключается в том, что выделение
самостоятельных этапов в жизненном цикле приложений весьма условно, особенно если речь идет об
итерационной циклической модели разработки. Например, широкое использование визуальных
методов проектирования с автоматической генерацией кода фактически стирает грань между
проектированием и кодированием. А тестирование вообще пронизывает всю жизнь программы.
Имеются и субъективные факторы, которые определяются различиями стратегических бизнес–
целей разных поставщиков методологий. Именно этим объясняется то, что Microsoft – основу бизнеса
которой составляют не средства разработки, а платформенное ПО, – больше внимания (по сравнению
с теми же Rational и Borland) уделяет общим вопросам организации процесса создания приложений, а
также их внедрению.
Поэтому, например, этап Envisioning включает определение не только требований к ПО, но и
состава команды (здесь содержатся, в частности, очень интересные рекомендации касательно ролевой
модели команды разработчиков, а также возможных вариантов совмещения ролей). А этап Stabilizing
подразумевает не только собственно тестирование, но и фактически опытную эксплуатацию ПО, на
которой могут уточняться исходные требования заказчика. Что уж говорить об особом акценте Microsoft
на задачах развертывания решений...

2.4.2. Гнучкі стадійні моделі (Метод_ПЗ.pdf)

2.4.2.1 SCRUM (422.pdf, 2020-Scrum-Guide-Ukrainian.pdf)
1. Планирование спринта (Sprint Planning Meeting)
Происходит в начале новой итерации Спринта.
– Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт
принимает на себя команда;
 14
– На основе выбранных задач создается резерв спринт. Каждая задача оценивается в идеальных
человеко–часах;
– Решение задачи не должно занимать более 12 часов или одного дня. При необходимости
задача разбивается на подзадачи;
– Обсуждается и определяется, каким образом будет реализован этот объём работ;
– Продолжительность совещания ограничено сверху 4–8 часами в зависимости от
продолжительности итерации, опыта команды и т. п.
 (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи
из резерва продукта;
 (вторая часть совещания) Участвует только команда: обсуждают технические детали
реализации, наполняют резерв спринта.

2.1–2.n Ежедневное совещание (Daily Scrum meeting)

 начинается точно вовремя;
 все могут наблюдать, но только «свиньи» говорят;
 длится не более 15 минут;
 проводится в одном и том же месте в течение спринта.
В течение совещания каждый член команды отвечает на 3 вопроса:
– Что сделано с момента предыдущего ежедневного совещания?
– Что будет сделано с момента текущего совещания до следующего?
– Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает
скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц,
непосредственно затронутых данным препятствием.)

3.1–3.m Скрам над скрамом (Scrum of Scrums)

Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать
работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном
скрам совещании плюс следующие вопросы:
– Что каждая команда сделала с момента предыдущего ежедневного совещания?
– Что каждая команда сделает к следующему ежедневному совещанию
– Есть ли проблемы, мешающие или замедляющие работу каждой команды?
– Нужно ли другой команде сделать что–то из задач вашей команды?

4. Обзор итогов спринта (Sprint review meeting)

Проводится после завершения спринта.
– Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
– Привлекается максимальное количество зрителей.
– Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый
показывает, что сделал за спринт).
– Нельзя демонстрировать незавершенную функциональность.
– Ограничена 4–мя часами в зависимости от продолжительности итерации и инкремента
продукта.
5. Ретроспективное совещание (Retrospective мeeting)
Проводится после завершения спринта.
– Члены команды высказывают своё мнение о прошедшем спринте.
– Отвечают на два основных вопроса:
3) Что было сделано хорошо в прошедшем спринте?
4) Что надо улучшить в следующем?
– Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
– Ограничена 1–3–мя часами.
2.4.2.2 XP-процес (Orlov_PI.pdf, с.40-45)
2.4.2.3 DSDM (422.pdf)
 15
1. Пред–проект
Фаза пред–проекта (Pre–Project) включает в себя обсуждение возможных проектов. На этой стадии
предпринимается решение о реализации проекта вообще.
2. Изучение выполнимости проекта
На фазе изучения выполнимости проекта (The Feasibility Study) анализируется возможность
выполнения проекта. Исследуются возможности реализации программной системы, которая способна
удовлетворить потребности бизнеса. На стадии изучения выполнимости проекта принимается
решение, что проект можно реализовать (с учетом текущих ограничений времени и ресурсов).
3. Изучение бизнес–процессов
На фазе изучения бизнес–процессов (The Business Study) исследуются коммерческие аспекты
проекта:
– имеет ли проект коммерческую ценность?
– каков будет состав участников проекта?
– какие технологии будут использоваться?
4. Итерация разработки функциональной модели
Во время итерации разработки функциональной модели (Functional Model Iteration)
разрабатывается и анализируется функциональный прототип системы. Функциональный прототип
показывает, какими функциями должна обладать система и как она должна их выполнять.
Функциональный прототип позволяет ответить на следующие вопросы:
– насколько удобно будет пользоваться готовой системой?
– будет ли готовая система обладать необходимым уровнем производительности?
– каков наилучший путь реализации готовой системы?
Проект может включать в себя несколько итераций разработки функциональной модели.
5. Итерация разработки
Во время итерации разработки (Design and Build Iteration) продукт проектируется и
разрабатывается, причем сразу с требуемым качеством. Обычный проект содержит несколько
итераций разработки.
6. Внедрение
На фазе внедрения (Implementation) продукт подготавливается к выпуску, разрабатывается
пользовательская документация, проводится обучение пользователей и т.д. Проект может включать
несколько итераций внедрений.
7. Пост–проект
На фазе пост–проекта (Post–Project) осуществляется анализ реализованной системы и
принимается решение о возможном расширении функциональности продукта. Данный анализ
выполняется по прошествии некоторого времени с момента технического завершения проекта.
2.4.2.4. FDD (422.pdf)
Проект по методологии FDD состоит из двух основных фаз:
1) получение списка всех функциональных возможностей, которыми должен обладать продукт;
2) последовательная реализация функциональных возможностей.
Структура проекта в методологии FDD состоит из пяти основных процессов:
1) разработка общей модели;
2) построение списка функциональных возможностей;
3) планирование реализации функциональных возможностей;
4) проектирование функциональности;
5) реализация функциональности.
В результате последовательного выполнения трех первых процессов разрабатывается общая
модель продукта. Последние два выполняются итеративно для каждой небольшой группы
взаимосвязанных функциональных возможностей.
1. Проект в методологии FDD начинается с процесса разработки общей модели (Develop Overall
Model). Результатом процесса разработки общей модели является общая модель предметной области
и разрабатываемой системы.
Процесс разработки общей модели включает в себя следующие задачи:
– формирование команды моделирования;
– анализ предметной области;
– изучение проектной документации;
– разработка модели;
 16
– детализация модели;
– описание модели.
Критерии начала процесса
Найдены эксперты предметной области. Назначены главный архитектор и ведущие
программисты.
Формирование команды моделирования
Команда моделирование включает в себя постоянных членов, таких как эксперты предметной
области и ведущие программисты. Другие члены команды разработчиков периодически включаются в
команду моделирования, чтобы у них был шанс поучаствовать в процессе моделирования.
Анализ предметной области
Эксперты проводит обзор предметной области, в которой предстоит осуществлять моделирование.
Во время анализа могут обсуждаться любые аспекты предметной области, в том числе и не имеющие
прямого отношения к разрабатываемому продукту.
Изучение проектной документации
Команда моделирования изучает имеющиеся проектные документы – список требований, модели
данных, руководства пользователей и т.п.
Разработка модели
Формируются небольшие группы (не более трёх человек). Каждая из этих групп разрабатывает
собственный вариант модели некоторой предметной области. Затем представитель каждой группы
презентует разработанную в данной группе модель всей команде моделирования. Окончательная
модель либо выбирается из предложенных группами моделей, либо конструируется на основе
нескольких предложенных группами моделей.
Детализация модели
Общая модель расширяется по результатам итеративного выполнения предыдущей задачи.
Описание модели
Описываются основные аспекты разработанной общей модели. Также описываются основные
варианты альтернативных моделей, которые могут пригодиться в течение проекта.
Верификация
Внутренняя верификация результатов процесса разработки общей модели осуществляется
благодаря активному участию экспертов предметной области. Внешняя верификация результатов
процесса осуществляется благодаря согласованию результатов моделирования с заказчиком.
Критерии завершения процесса
Для завершения процесса команда моделирования должна предоставить детальное описание
разработанной общей модели. Результаты процесса должны быть согласованны с менеджером
проекта и главным архитектором.
2. Построение списка функциональных возможностей
Результатом данного процесса является построение списка функциональных возможностей (Build
Feature List), которые должна предоставлять разрабатываемая система. Процесс построения списка
функциональности включает в себя следующие задачи:
• формирование команды для разработки списка
функциональности;
• разработка списка функциональности.
Критерии начала процесса
Успешно завершен предыдущий процесс разработки общей модели.
Формирование команды для разработки списка функциональных возможностей
В команду включаются главные программисты, состоявшие в команде моделирования.
Разработка списка функциональности
Вся функциональность системы разбивается на предметные области, которые получаются путем
декомпозиции общей предметной области. Для каждой предметной области системы описываются все
вероятные варианты использования. Затем для каждого варианта использования составляется список
функциональных возможностей, которыми должна обладать система.
Каждая функциональная возможность записывается в виде предложения, имеющего смысл с точки
зрения конечного пользователя системы – например, «Проверить пароль пользователя». Реализация
каждой функциональной возможности должна занимать не более двух недель. В противном случае
данная функциональная возможность должна быть разделена на части.
Верификация
Внутренняя верификация осуществляется благодаря тому, что все члены команды по разработке
списка функциональных возможностей принимали активное участие в процессе разработки общей
модели. Внешняя верификация результатов процесса осуществляется через согласование списка
функциональных возможностей с экспертами предметной области и заказчиком.
 17
Критерии завершения процесса
Результатом процесса является список функциональных возможностей, который содержит:
– список предметных областей продукта;
– список вариантов использования для каждой предметной области;
– список функциональных возможностей, необходимых для поддержки каждого из вариантов
использования.
3. Планирование реализации функциональности
Результатом процесса планирования реализации функциональности (Plan By Feature) является
создание общего плана разработки продукта.
Общий план разработки продукта определяет порядок, в котором будут реализовываться
функциональные возможности. Данный план учитывает зависимости между функциональными
возможностями, сложность их реализации и загрузку команды.
Процесс планирования реализации функциональности включает в себя следующие задачи:
– формирование команды планирования;
– определения порядка разработки;
– назначение ответственности ведущих программистов за реализацию конкретных вариантов
использования;
– назначение владельцев классов.
Критерии начала процесса
Успешно завершен предыдущий процесс построения списка функциональных возможностей.
Формирование команды планирования
В команду включаются менеджер по разработке и главные программисты.
Определения порядка разработки
Команда планирования назначает, с точностью до месяца, дату завершения реализации каждого
варианта использования. Идентификация вариантов использования и дат завершения их реализации
основаны на следующих основных факторах:
– учитываются зависимости между функциональными возможностями на уровне участвующих
классов;
– осуществляется балансировка нагрузки между владельцами участвующих классов;
– учитывается сложность реализации тех или иных функциональных возможностей;
– функциональные возможности, реализация которых связана со значительным риском, имеют
приоритет перед другими возможностями;
– учитываются разнообразные внешние факторы, такие как выпуск промежуточных версий,
проведение публичных презентаций и т.п.
Назначение ответственности главных программистов за реализацию конкретных вариантов
использования
Команда планирования должна назначить ответственность главных программистов за реализацию
конкретных вариантов использования. Распределение ответственности основывается на следующих
основных факторах:
– учитывается порядок разработки;
– зависимостями между функциональными возможностями на уровне участвующих классов;
– осуществляется балансировка нагрузки между владельцами участвующих классов (главные
программисты тоже являются владельцами классов);
– учитывается сложность реализации тех или иных функциональных возможностей.
Назначение владельцев классов
Команда планирования должна назначить ответственность разработчиков за реализацию
конкретных классов. Каждый разработчик может отвечать за разработку нескольких классов.
Распределение ответственности основывается на следующих основных факторах:
– учитывается балансировка нагрузки между разработчиками;
– учитывается сложность реализации тех или иных классов;
– учитывается порядок разработки.
Верификация
Верификация результатов планирования осуществляется непосредственно в процессе
планирования при активном участии ведущих программистов, менеджера разработки и менеджера
проекта.
 18
Критерии завершения процесса
Результатом процесса является общий план разработки, который содержит:
– варианты использования и даты завершения их реализации;
– ответственность главных программистов за реализацию конкретных вариантов использования;
– ответственность разработчиков за реализацию конкретных классов.
4. Проектирование функциональности
Целью процесса проектирования функциональности (Design By Feature) является разработка
архитектуры, необходимой для реализации небольшой группы взаимосвязанных функциональных
возможностей. Ответственность за реализацию функциональных возможностей распределена между
главными программистами. Главные программист выбирает одну или несколько взаимосвязанных
функциональных возможностей для реализации в течение данной итерации.
Критерии начала процесса
Успешно завершен предыдущий процесс планирования.
Формирование функциональной команды
Ведущий программист идентифицирует классы, которые связаны с реализацией выбранного набора
функциональных возможностей. Владельцы данных классов включаются в команду по разработке
данной функциональной возможности.
Анализ предметной области
Эксперт проводит обзор предметной области, с которой связан выбранный набор функциональных
возможностей. Выполнение анализа предметной области является необязательной задачей и зависит
от сложности реализации выбранных функциональных возможностей, сложности общей предметной
области и т.п.
Изучение проектной документации
Члены функциональной команды изучают всю доступную проектную документацию относительно
выбранных функциональных возможностей.
Моделирование взаимодействия
Члены функциональной команды моделируют, в том или ином виде, взаимодействие объектов,
вовлеченных в реализацию разрабатываемых функциональных возможностей. В модели учитываются
все взаимодействующие объекты и последовательность сообщений, которыми они обмениваются.
Детализация общей модели
Ведущий программист уточняет общую модель, добавляя или изменяя классы и методы, опираясь
на результаты моделирования функциональных возможностей.
Написание заготовки для реализации
Опираясь на уточненную общую модель, каждый разработчик делает изменения в интерфейсах
принадлежащих ему классов (не затрагивая реализацию классов). Затем ведущий программист
формирует API для разрабатываемых функциональных возможностей.
Верификация
Верификация дизайна разрабатываемых функциональных возможностей осуществляется членами
функциональной команды с возможным привлечением других участников проекта.
Критерии завершения процесса
Результатом процесса проектирования функциональности является полностью разработанный и
верифицированный проект реализации набора взаимосвязанных функциональных возможностей,
который содержит:
– пояснительную записку, которая обобщает и описывает дизайн, необходимый для реализации
новых функциональных возможностей;
– все необходимые вспомогательные документы (включая результаты моделирования);
– описание основных альтернативных вариантов дизайна;
– обновленную общую модель;
– календарный план реализации набора новых функциональных возможностей.
5. Реализация функциональности
Целью процесса реализации функциональности (Build By Feature) является полная реализация
набора взаимосвязанных функциональных возможностей, ценных с точки зрения пользователя.
Разработчики вносят изменения в классы, владельцами которых они являются. Для вновь написанного
кода разрабатываются модульные тесты. Также проводится инспекция всех изменений внесенных в
код системы.
Критерии начала процесса
Для разрабатываемой функциональной возможности успешно завершен процесс проектирования.
Разработка
 19
Разработчики вносят все необходимые изменения в классы, владельцами которых они являются.
Инспекция кода
Проводится полная инспекция всего внесенного кода с участием членов функциональной команды и,
возможно, других участников проекта.
Разработка модульных тестов
Разработчики проектируют и реализуют модульные тесты для классов, владельцами которых они
являются. По решению главного программиста, могут быть также разработаны функциональные тесты,
которые специфицируют основные варианты использования новых функциональных возможностей.
Интеграция
После исчерпывающего модульного и функционального тестирования и успешной инспекции кода
новые функциональные возможности интегрируется в разрабатываемый продукт.
Верификация
Верификация осуществляется благодаря исчерпывающему модульному и функциональному
тестированию и инспекциям кода.
Критерии завершения процесса
Результат процесса реализации набора взаимосвязанных функциональных возможностей:
– реализован набор взаимосвязанных функциональных возможностей, ценных с точки зрения
пользователя;
– весь новый код протестирован и проинспектирован;
– новые функциональные возможности интегрированы в систему.
2.4.2.5. Адаптивная разработка ПО (ASD, Adaptive Software Development, Дж.Хайсмит)
(президентом
Разработана для экстремальных проектов на основе теории сложных адаптивных систем.
В ASD статический цикл разработки ПС – Планирование–Проектирование–Программирование –
заменяется динамическим циклом Размышление–Взаимодействие–Обучение (Speculate–
Collaborate–Learn) (рис.2.6).
Цикл обучения

Планиров ание Параллельная Анализ Финальная

От крытие
адапт ив ного компонентная качеств а оценка
проекта
цикла инженерия качеств а и
в ыпуск

Размышление Взаимодействие Обучение

Рисунок 2.6 – ЖЦ в методології адаптивного розробленя ПЗ

Этот цикл предполагает непрерывное обучение, связан с постоянными изменениями, повторными
оценками, попытками предусмотреть неизвестное будущее проекта, и требует тесного взаимодействия
между менеджером, разработчиками, группой качества и заказчиками.
Размышление не противопоставляется планированию, а учитывает реально существующую
неопределенность при решении сложных проблем, допускает изначальную ограниченность знаний и
возможность ошибок, и предполагает большую долю исследований и экспериментов, как основу
Обучения.
Взаимодействие – заменяет традиционный стиль командного управления при принятии решений.
Современные сложные приложения зачастую не «строятся заново» группой индивидуумов, а постоянно
эволюционируют, требуя сбора, анализа и использования больших объемов накопленной информации,
что не под силу одиночкам. В условиях быстрых изменений ситуации в проекте принятие основных
решений делегируется непосредственно командам проекта. Правильность принятых решений, в свою
очередь, также зависит от Обучения.
Качество Знаний, накопленных в результате применения таких практических приемов, как
ретроспективный обзор проекта, является основным показателем правильности политики Обучения в
организации и залогом ее адаптируемости.
I. Фаза Размышления (Обдумывания) включает следующие семь шагов:
1. Инициирование и открытие проекта. Включает определение назначения, целей, ограничений,
участников, требований; оценки масштаба, сферы действия и ключевых рисков.
2. Определение временных рамок проекта с учетом оценок (см. п.1).
3. Определение оптимального числа циклов и продолжительности каждого из них. Выбор зависит
от общей продолжительности проекта и степени неопределенности в оценке ситуации. Для малых и
средних проектов (размер<5000 УЕФ) цикл составляет 1–4 недели.
 20
4. Написание целевых утверждений для каждого цикла. Промежуточные цели, установленные для
каждого цикла, и их контроль по вехам проекта, повышают прозрачность разработки, способствуют
своевременному устранению дефектов и предупреждению ошибок, и, в целом, накоплению знаний о
предметной области и проекте. Верификация и тестирование – неотъемлемая часть каждого цикла
разработки.
5. Выделение основных компонентов и их распределение по циклам. Для визуализации
соотношений «компоненты–циклы» при планировании используется матрица «компоненты–циклы».
6. Выделение технологических и вспомогательных компонентов и их распределение по циклам.
Критерии распределения таковы: продукты каждого цикла должны быть полезны пользователю, а
наиболее высокие риски – устранены как можно раньше; должны учитываться естественные
зависимости между компонентами, а ресурсы – распределяться рационально.
7. Разработка списка задач. Задачи определяются путем разбиения каждого компонента на
отдельные части. В список добавляются задачи, не касающиеся компонентов непосредственно.
II. Фаза Взаимодействия. Предполагает параллельную разработку работоспособных
компонентов. Основная задача менеджеров в этой фазе – организация взаимодействия при
параллельной работе распределенных команд.
III. Фаза Обучения. Предполагает анализ качества в конце каждого цикла разработки. Цели
качества устанавливаются и эволюционируют так, что всегда служат критериями завершения циклов,
а также критериями пригодности применяемых практических приемов анализа, составляющих основу
обучения. Цели анализа – не столько поиск дефектов, сколько изучение потребительских свойств
будущего продукта (этот анализ выполняют заказчики), функциональных и технических характеристик
продукта (технические обзоры выполняют разработчики), эффективности функционирования команд и
используемых процессов, состояния проекта и необходимости перепланирования ресурсов перед
началом следующего цикла. Состояние проекта определяется по состоянию каждого компонента,
который был запланирован на текущий цикл разработки.
Лекція 3 15_09_2022. Парадигми програмування
Корисні ресурси
Сайт Р.Іськова: http://ruslan.rv.ua/python-essential/paradigmas/paradigmas.html
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, підрозділ 5.6, розд.8
додатково
Orlov_PI.pdf, с.182-183, 322-325; розд.18
romanov_PI.pdf, підрозділ 3.2
3.1. Класифікація мов програмування
Сучасній програмній індустрії властиві три тенденції:
1) зростання обсягів, специфічності та складності функціональних задач і ділових процесів, які
вимагають автоматизованої підтримки;
2) загострення вимог до якості програмних продуктів і скорочення термінів і ресурсів їх розроблення;
3) пошук шляхів і засобів подолання обмеженості ресурсів створення програмних продуктів –
пам’яті, швидкості обчислень і продуктивності праці програмістів.
Вони зумовлюють постійне розроблення мов програмування (МП) з різним співвідношенням
універсальності й спеціалізованості: наразі відомо кілька десятків тисяч МП та їх діалектів (новий
компілятор МП вводить новий її діалект), і ця кількість невпинно зростає. Для вибору адекватних МП і
визначення напрямів їх розвитку запроваджено такі основні критерії класифікації.
1. Призначеність: практичні, для прикладних застостунків, і теоретичні, для застосування в
теоретичних моделях інформаційних систем.
2. Функціональна сила: універсальні та спеціалізовані.
Будь-яка програма є функцією, що пов’язує вхідні дані з результатами, тобто кожній МП L відповідає
певна сукупність таких функцій. Серед них можна виділити підмножину F базових елементарних
функцій, з яких за допомогою певних композицій будуються програми цією МП. У теорії алгоритмів існує
поняття класу U(F) усіх алгоритмічно обчислюваних функцій над базисом F.
Кажуть, що мова L є універсальною, якщо для кожної функції класу U(F) існує L –програма, що
обчислює її відносно певних функцій кодування й декодування, та спеціалізованою – в іншому виадку.
Приклади універсальних МП – АЛГОЛ-60, ПЛ/1, ФОРТРАН, Lisp, ПАСКАЛЬ, С, С + + , Java, PHP,
Perl, Python.
Приклади спеціалізованих МП – мови для підготовки програмної документації.
3. Предметна орієнтація (клас ефективно розв’язуваних задач, поданий насамперед основними
типами даних і структурою програми).
Основні предметні орієнтації:
– числова обробка даних – задачі числового аналізу, лінійної алгебри, математичної фізики й
аналітичних перетворень (МП зі структурами даних, обмеженими багатовимірними масивами, зокрема
АЛГОЛ-60, ФОРТРАН-IV, АНАЛІТИК);
– обробка складно структурованої інформації (МП з розвиненою системою типів даних зі
структурами, покажчиками, зокрема. ПЛ-1, КОБОЛ, АЛГОЛ-68, ПАСКАЛЬ, С, С++, Delphi, Oberon, Java);
– обробка даних у реальному часі (Modula, Аda);
– символьна обробка – задачі штучного інтелекту (СНОБОЛ, Lisp, РЕФАЛ, ФОЛI);
– розробка баз даних (Oracle, SQL);
– Веб-технології (HTML, PHP, Perl).
.4. Типізація: статична (сильна) та динамічна (слабка)
За статичної типізації змінні й параметри функцій (методів) зв’язуються з типами в момент опису або
декларування й не можуть бути змінені пізніше. Це, окрім спрощення трансляції й керування пам’яттю,
уможливлює часткову перевірку семантичної коректності використання змінних уже на етапі компіляції,
зокрема перевірку узгодженості їхніх типів із типом операцій.
За динамічної типізації змінні й параметри функцій (методів) зв’язуються з типами в момент
присвоювання значення або передавання параметра у функцію. Тоді одна й та сама змінна в різні
моменти виконання програми може буде зв’язана зі значеннями різних типів.
Приклади МП:
– зі статичною типізацією – ФОРТРАН, АЛГОЛ-60, ПАСКАЛЬ, С, С++, Modula.
– з динамічною типізацією – Lisp, ML, Pyhton, Perl, Smalltalk.
5. Парадигма програмування – підхід до побудови програм, підґрунтям якого є узгоджена
сукупність ідей і понять, що визначають певний стиль написання програм, тобто сукупність правил,
яких слід дотримувати.. Це спосіб концептуалізації, що визначає організацію обчислень і
структурування операцій, виконуваних комп’ютером.
 2
Поняття парадигми програмування запроваджено Робертом Флойдом в однойменній лекції з
приводу отримання Тьюрінгової медалі АСМ (1978р.) як основної концептуальної ідеї або комплексу
ідей, що визначають характерні риси певної технологій програмування
(R.W. Floyd. The Paradigms of Programming Communications of the ACM, 22(8):455—460, 1979).

Р.В Флойд, 1978

Це поняття уточнює для програмування засадниче поняття парадигми, запроваджене філософом
науки Т.Куном (1962) як «загальновизнані наукові досягнення, що протягом певного часу дають
науковій спільноті модель постановки проблем та їх вирішення».
Довільна парадигма програмування має концептуальні засади, використовує свій набір моделей і
методів обчислень включно зі структурами даних і механізмами керування та визначає клас
прикладних задач, ефективно вирішуваних засобами даної парадигми.
Призначеність парадигм програмування:
1) розбиття програми на термінальні складники;
2) визначення моделі перетворення даних;
3) запровадження обмежень на використовувані конструкції
3.2. Парадигми програмування
3.2.1 Класифікація парадигм
Наразі розрізняють:
1) парадигми прикладного (систематичного) та теоретичного програмування;
2) парадигми основні (Імперативного, Функціонального, Алгебраїчного та Логічного програмування)
та вищі (за рівнем) (Паралельного, Об’єктно-орієнтованого, Агентного програмування)
[Парадигми програмування – http://schum.kiev.ua/let/];
3) парадигми, відмінні способом декомпозиції задачі (Імперативного, Декларативного,
Об’єктно-орієнтованого, Сценарного програмування, Програмування в обмеженнях);
4) парадигми (стилі), відмінні глибиною і спільністю опрацьовування технічних деталей організації
процесів комп’ютерної обробки інформації (Машинно-орієнтоване, Системне, Логічне,
Трансформаційне, Високопродуктивне /паралельне програмування).
Практично корисну систематизацію парадигм подано на рис. 3.1.
ПРИКЛАДНЕ ПРОГРАМУВАННЯ

1. Імперативне 2. Об’єктно- 3.Декларативне

орієнтоване
Неструктурне Функціональне
На класах
Процедурне (Smalltalk, C++, Delphi) Логічне

Структурне На прототипах В обмеженнях

(Java Script)
Модульне Доказове

Збіркове Нове покоління Доменно-орієнтоване

парадигм (HTML, SQL)
Кероване подіями Сценарне
Розподілене
Паралельне Компонентне (distributed)

Узагальнене Сервісно-орієнтоване
програмування
ТЕОРЕТИЧНЕ
(generic) в різних Аспектно (контекстно-) ПРОГРАМУВАННЯ
парадигмах орієнтоване
Алгебраїчне
Метапрограмування Агентне
за шаблонами Експлікативне
(meta-programming) Генеруюче
Інсерційне
Автоматне
Візуальне (visual) Композиційне
Концептно-орієнтоване

Рисунок 3.1 – Класифікація парадигм програмування

(Капитонова Ю.В., Летичевский А.А. Об основных парадигмах программирования ( Кибернетика и системный
анализ.-1994.-№6.-с.3-20 )
 3
3.2.2 Парадигма Імперативного програмування
Імперативне програмування – це підхід до побудови програм, що використовує алгоритмічну
декомпозицію задачі, при якій програму подано послідовністю дій (команд), які має повинен
покроково виконати комп’ютер.
Оскільки імперативна програма подібна до наказів комп’ютеру, імперативне програмування іноді
звуть наказовим.
Концептуальна ідея імперативного програмування – алгоритмічна структура програмного коду,
яка передбачає роз’єднання у програмах даних і дій, що виконуються над ними. Активним суб’єктом
у імперативних програмах є алгоритм, який має виконати всі необхідні для досягнення потрібного
результату дії над пасивними даними. Таким чином, в імперативному програмуванні алгоритм має
пріоритет перед даними.
Імперативна парадигма програмування відповідає архітектурі традиційних ЕОМ, запропонованій
фон Нейманом.
Теоретичною основою імперативного програмування є алгоритмічна система під назвою
«машина Т’юринга» – абстрактний обчислювальний пристрій, що виконує послідовність команд
програми, яка, таким чином, переходить з одного стану в інший.
Відповідно, програму в імперативному програмуванні розглядають як послідовність дій, які змінюють
стан комп’ютера, тобто перетворюють початковий стан пам’яті –, значення вхідних даних – у
заключний, тобто у результати. Концепції пам’яті як сховища значень, поточного кроку виконання і
поточного стану, що змінюється у часі, є Фундаментальними поняттями імперативного програмування.
Моделлю обробки даних за імперативного підходу є послідовне виконання команд, які задають
алгоритм вирішення задачі:
програма = послідовність дій.
Базові поняття імперативної парадигми: оператор (команда), що задає дію з обробки даних, і
змінна, якій можна присвоїти значення, що зберігається в памяті комп’ютера; базова операція –
присвоєння, що служить для зміни вмісту областей пам’яті.
Основна задача програміста з написання імперативної програми – звести рішення задачі до
послідовності операторів, які вміє виконувати процесор комп'ютера.
Кожна парадигма програмування має відповідну інструментальну підтримку. Найбільш відомі і
поширені імперативні мови програмування представлені на рис. 3.2.

Рисунок 3.2 – Імперативні МП

Оскільки практично всі сучасні комп’ютери орієнтовані на послідовні обчислення, імперативне
програмування явно виграє в ефективності реалізації прикладних задач, для яких важлива швидкість
виконання. Окрім цього, роботу із зовнішніми пристроями, як правило, описують у термінах
послідовного виконання операцій, що робить такі задачі ідеальними для імперативної реалізації.
3.2.3 Парадигма Об’єктно-орієнтованого програмування
Об’єктно-орієнтоване програмування – це підхід до побудови програм, що використовує об’єктну
декомпозицію задачі, за якої структура системи описується в термінах об’єктів і зв’язків між ними, а
поведінка – в термінах обміну повідомленнями між об’єктами.
Об'єкт являє собою цілісну модель і природну імітацію діяльності деякого елемента реального світу.
Об'єкти, як і реальні сутності навколишнього світу характеризуються тим, що вони мають певний набір
властивостей, здатні різними способами змінювати ці властивості і можуть реагувати на події, які
виникають як у навколишньому світі, так і усередині самого об’єкта. Об’єкт, як правило, включає деякі
дані, які характеризують стан об’єкта, та функції обробки цих даних, які описують поведінку об’єкта.
Функції об’єкта, які у об'єктно-орієнтованому програмуванні (ООП) називають методами, зазвичай
призначені для доступу до даних об’єкта та виконання певних дій над ними.
 4
Концептуальною ідеєю ООП є поєднання даних і дій, що виконуються над ними, в єдине
ціле, зване об’єктом.
Кожен об'єкт є екземпляром певного класу. Клас в ООП – це абстрактний тип даних, створюваний
програмістом. Клас являє собою множину об’єктів з подібною структурою та поведінкою. Всі об’єкти, які
є екземплярами одного класу, можуть виконувати одні й ті ж самі дії. Поняття об'єкта та класу є
фундаментальними в ООП.
Всі дії та розрахунки в об’єктно-орієнтованих програмах виконуються шляхом взаємодії (обміну
даними) між об’єктами за допомогою механізму передавання повідомлень – запитів на виконання дії,
доповнених списком аргументів, які можуть знадобитися для її виконання (рис. 3.3).

Рисунок 3.3 – Схематичне подання об'єктів і зв’язків між ними

Об’єкт – приймач повідомлення реагує на нього в особливий, тільки йому відомий спосіб. При цьому
він може надіслати повідомлення іншим об’єктам, отримати від них відповіді, змінити свій стан і,
нарешті, повернути відповідь об’єкту – надавачу повідомлення.
Основою ефективної організації виконання програми в руслі ООП є дотримання принципів
інкапсуляції, успадкування та поліморфізму.
Інкапсуляція визначає спосіб опису, який передбачає об’єднання в межах класу даних і методів їх
обробки, а також приховування деталей реалізації класу: користувач має бачити і використовувати для
доступу до об’єкту й маніпулювання ним виключно інтерфейсний складник класу (список декларованих
властивостей і методів). Це дозволяє забезпечити захист даних від зовнішнього втручання.
Успадкування – це механізм породження нових класів з уже існуючих. Породжений клас успадковує
властивості та поведінку класу-бвтька і може доповнити їх своїми власними. Механізм успадкування
дозволяє організовувати класи в єдину деревоподібну структуру із загальним коренем – ієрархію
спадкування.
Вона характеризується тим, що властивості й поведінка екземпляра деякого класу автоматично
доступні будь-якому класу, розміщеному нижче в ієрархії спадкування. Це дозволяє формувати похідні
поняття на основі базових і таким чином створювати модель як завгодно складної предметної області із
заданими властивостями. Наприклад, ієрархія класів – геометричних фігур має вигляд:

Точка (Point)
X, Y, Color

Лінія (Line) Коло (Circle)

Point, X1, Y1 Point, R

Трикутник (Triangle) Сектор( Sector)

Line, X2, Y2 Circle, ug1, ug2

Полоса (Trace) Круг (FullCircle)

Line, H Circle, Color1
 5
Поліморфізм – це механізм, що дозволяє мати різні реалізації одного й того ж методу, які будуть
вибиратися залежно від типу об’єкту, переданого до методу під час його виклику. Поліморфізм означає,
що певні одноіменні дії можуть розрізнятися залежно від того, якого з класів вони стосуються. Напр.,
для трьох різних об’єктів або класів – двигун автомобіля, електричне світло в кімнаті та комп’ютер –
можна визначити операцію «вимкнути». Проте зміст цієї операції буде відрізнятися для кожного з
розглянутих об’єктів. Так, для двигуна автомобіля виклик дії «вимкнути двигун» означає припинення
подачі палива і його зупинку, а некоректна дія «вимкнути комп’ютер» може спричинити втрату даних.
Використання поліморфізму підвищує гнучкість та універсальність програмного забезпеченя (ПЗ).
Отже, на відміну від імперативного програмування, що грунтується на алгоритмічній декомпозиції
програми та розмежуванні в програмах даних і процедур їх обробки, в об’єктно́-орієнтованих програмах
має місце об’єктна декомпозиція програми й об’єднання даних та функцій їх обробки в межах
певного класу. Первинними в ООП є дані (об’єкти), а не код. Об’є́ктно-орієнтована програма фактично
є описом структури і поведінки окремих об’єктів, які взаємодіють між собою так, щоб забезпечити певну
поведінку ПЗ.
Стійкість та керованість об’єктно-орієнтованої програми забезпечуються за рахунок чіткого
розподілу відповідальності об’єктів (за кожну дію відповідає певний об’єкт), однозначного означення
інтерфейсів об’єктної взаємодії та повної ізольованості внутрішньої структури об’єкта від
зовнішнього середовища (інкапсуляції).
Обчислювальна модель чистої парадигми ООП підтримує явно лише одну операцію – надсилання
об’єкту повідомленння.
Повідомлення можуть мати параметри, які є об’єктами. Саме повідомлення також є об’єктом.
Роль програміста з написання об’єктно-орієнтованої програми полягає у формуванні й реалізації
такої ієрархії об’єктів, взаємодія яких після запуску програми призведе до досягнення необхідного
кінцевого результату.
Використання розроблених (можливо, іншими колективами програмістів) бібліотек об'єктів дозволяє
значно заощадити трудовитрати при розробці ПЗ, особливо типового.
Однак переваги ООП повною мірою виявляються лише для розробки досить великих ПС.
Особливо зручно і легко в об'єктах подати взаємодію різних елементів графічного інтерфейсу
користувача.
Спроби застосувати ООП для програмування нескладних алгоритмів, ззокрема розрахунків за
готовими формулами, часто виглядають штучними нагромадженнями непотрібних мовних конструкцій.
Їх простіше і зручніше розробляти, застосовуючи імперативне програмування.
Об'єктно-орієнтовані мови можна поділити на три групи (рис. 3.4):
1) чисті МП, які в найбільш класичному вигляді підтримують лише одну парадигму ООП. Вони
передбачають невелику мовну частину та істотну бібліотеку, а також набір засобів підтримки часу
виконання.
2) гібридні мови, які є результатом запровадження об’єктно-орієнтованих конструкцій до популярної
імперативної МП;
3) урізані МП, які є результатом вилученя з гібридних мов найбільш непотрібних з об’єктно-
орієнтованої точки зору конструкцій.

Рисунок 3.4 – Об’єктно-орієнтовані МП

3.2.4 Парадигма Декларативного програмування
Декларативне програмування — це парадигма програмування, відповідно до якої програма
в певений спосіб описує, що потрібно отримати як результат, але не як це треба зробити
 6
Тому декларативне програмування часто звуть описовим. У цій парадигмі головним є чітке
формулювання мети й результатів розв’язання задачі, а не послідовність отримання цього
результату. Вибір та застосування необхідного для розв’язання задачі алгоритму – проблема
виконуючої системи (алгоритм роботи з даними «зашитий» до неї).
Так, декларативним є опис web-сторінок на HTML — вони описують, що містить сторінка та що має
відображатися (заголовок, шрифт, текст, зображення), але не містять інструкцій, як слід відображати
сторінку; опис SQL-запитів, що конкретизують властивості даних, які слід отримати з бази даних, але не
процес їх отримання; опис XML-документів, але не процес тощо.
Такий підхід має високий ступінь абстракції й легко формалізується математичними засобами.
Фактично програміст оперує не набором інструкцій, а абстрактними поняттями, часто досить
узагальненими.
Декларативні мови найкраще застосувати, коли «дані керують програмою»: для написання
експертних систем, конструювання трансляторів з МП, для більшості задач штучного інтелекту. Саме
там їх використання є найбільш ефективним.
Різновидами декларативного програмування є функціональне та логічне програмування.
3.2.4.1. Функціональне програмування – це підхід до побудови програм, який ґрунтується на
абстракції математичної функції та передбачає, що програма є сукупністю визначень
математичних функцій, а її виконання полягає в обчисленні відповідних виразів.
Функції можуть визначатися через інші функції (як композиція функцій) або рекурсивно (через самих
себе). У процесі виконання програми функції отримують параметри, обчислюють і повертають
результат, у разі необхідності обчислюючи значення інших функцій.
Слід зазначити, що існують відмінності в трактуванні математичної функції у функціональному та в
процедурному програмуванні. Зокрема, традиційна функція в математиці не може змінити своє
оточення та запам’ятати результати відпрацювання, а лише надає результат обчислення. Тобто, у
функціональному програмуванні програму можна представити як обчислення послідовності функцій
без станів.
На відміну від імперативного програмування, де існує поняття поточного кроку виконання і
поточного стану, змінного в часі, у функціональному програмуванні поняття часу відсутнє.
Отже, функціональне програмування є способом створення програм, в яких єдиною дією є
виклик функції, єдиним способом розбиття програми – створення нового імені функції та надання
для цього імені виразу, що обчислює значення функції, а єдиною операцією під час визначення
функцій, - їх композиція.
Такий підхід уможливлює прозоре моделювання тексту програм математичними засобами.
Основна специфіка функціональних МП – в тому, що функції обмінюються між собою даними
безпосередньо, тобто без використання проміжних змінних і присвоювань.
До відомих функціональних МП належить LISP (List Processing), що розглядається фахівцями як
основна мова програмування систем штучного інтелекту, Mathematica (символьні обчислення),
XSLT (XML), Haskell, Scheme (рис. 3.5). На платформі DOT.NET мовою функціонального програмування
є мова F#.

Рисунок 3.5 – Функціональні МП

Наприклад, обчислення факторіала числа на LISP:
;; обчислення факторіала
(define (fact n)
(cond ((= n 1) 1)
((> n 1) (* n (fact (- n 1))))))
;; виведення значення 5!
(print (fact 5))
 7
Цей приклад використовує рекурсивне визначення факторіала. Вирази в LISP визначаються за
дужками і можуть записуватися в кілька рядків. Визначення функції здійснюється з використанням
defun. Математичні вирази записуються у спеціальній формі – вираз а+bx має вигляд: +(а,*(b,х)).
Стандартна функція cond служить для організації умовного виконання, print – для виведення.
Функціональне програмування застосовують для вирішення задач, які складно формалізувати й
розв’язувати в термінах послідовних операцій – переважно задач, пов’язаних з розпізнаванням
образів, спілкуванням природною мовою, реалізацією експертних систем, автоматизованим
доведенням теорем, символьними обчисленнями, тобто задач з предметної області штучного
інтелекту.
3.2.4.2. Логічне програмування – це підхід до побудови програм, який грунтується на логіці
предикатів і передбачає, що програма являє собою опис відомостей про задачу (фактів),
припущень, достатніх для її вирішення (правил виведення), та твердження, яке треба довести.
Виконання програми полягає у доведенні цього твердження.
Факти (аксіоми) і правила виведення, які утворюють базу знань певної предметної області, подають
предикатами. Твердження, яке треба довести, вводиться в програму як цільова функція. Виконання
програми полягає у тому, щоб визначити за допомогою механізмів логічного виведення, чи випливає
задане цільове твердження (запит) з наявних фактів і правил. Для виконання програми (логічного
виведення результату) використовується вбудована система автоматичного пошуку.
Таким чином, у логічній програмі має місце поділ на дані (факти) та код (правила, запити), але
досить умовний: факти, правила й запити мають одну й ту ж форму запису – у вигляді предикатної
функції.
Програма в парадигмі логічного програмування описує не алгоритм вирішення задачі, а логічну
модель предметної області – деякі факти щодо властивостей предметної області та відношення між
цими властивостями, а також правила виведення нових властивостей і відношень з уже заданих.
Рішення задачі (отримання відповіді на запит) отримують не шляхом виконання команд, а за
допомогою механізмів керованого логічного виведення нових фактів на основі заданих фактів і правил
виводу, які реалізуються програмною системою автоматично.
Це свідчить про декларативність мови логічного програмування, яка влучно виражена у формулі Р.
Ковальского: «алгоритм = логіка + керування».
Основне завдання програміста – вдало описати у вигляді системи логічних формул предметну
область і таку множину відношень на ній, які з достатнім ступенем повноти описують задачу.
Найбільш поширеною мовою логічного програмування є PROLOG (PROgramming in LOGic –
програмування в термінах логіки). До мов логічного програмування також відносять Planner, Mercury,
Fril.
Наприклад, опис на PROLOG задачі з деякої предметної області, наприклад географії:
DOMAINS
gorod, strana = symbol
PREDICATES
situ(gorod,strana)
CLAUSES
Situ (pekin, asia).
Situ (warszawa, poland).
Situ (berlin, europe).
Situ (X, europe):- situ (X, russia).
Situ (X, europe):- situ (X, poland).
Розділ CLAUSES – головна частина програми на PROLOG. Тут записуються факти та правила. Так,
вираз situ (kiev, ukraine) описує той факт, що місто Київ знаходиться на Україні; правило situ (X, europe):
- situ (X, poland) означає, що будь-яке польське місто є одночасно європейським містом.
Розділ PREDICATES використовується для опису предикатів – назв відношень, існуючих між
об’єктами. Наприклад, предикат situ описує відношення між містами і країнами (приналежність міста
певній країні).
Розділ DOMAINS використовується для опису імен і структур об’єктів. Наприклад, місто і країна є
об’єктами символьного типу.
Відповіддю на запит
goal: situ (petersburg, europe).
Буде: Yes, тобто істина (хоча в явному вигляді цього факту описано не було).
Програми в парадигмі логічного програмування відрізняються принципово низькою швидкодією,
оскільки обчислення виконуються методом проб і помилок (за допомогою пошуку з поверненнями).
 8
Однак, важливою перевагою такого підходу є достатньо високий рівень машинної незалежності та
можливість «відкатів» – повернення до попередньої підцілі за негативного результаті аналізу одного з
варіантів під час пошуку рішення (скажімо, чергового ходу гри в шахи), що позбавляє від необхідності
пошуку розв’язку шляхом повного перебору варіантів і збільшує ефективність реалізації.
Основні властивості розглянутих парадигм програмування узагальнені в табл.3.1
Таблиця 3.1 – Зіставлення основних парадигм програмуваня:
Парадигма Ключовий Програма Виконання програми Результат
концепт
Імперативна оператор послідовність послідовне виконання результуючий стан пам’яті
операторів операторів
Об’єктно- об’єкт набір класів обмін повідомленнями результуючий стан об’єктів
орієнтована об’єктів між об’єктами
Функціональна функція набір функцій обчислення функцій значення головної функції
Логічна предикат логічні формули логічний доказ результат доказу
Слід зазначити, що парадигма програмування не визначається однозначно певною МП – чимало
сучасних МП є мультипарадигменними, тобто передбачають конструкції, властиві кільком різним
парадигмам програмування. Зокрема, мова C++ є універсальною мовою програмування високого рівня
з підтримкою трьох сучасних парадигм: процедурної, об’єктно-орієнтованої та узагальненої.
Розвиток парадигм пов’язаний з двома взаємозв’язаними причинами:
1) розширенням класу функціональних задач і пошуком найефективніших методів їх розв’язання;
2) зростанням складності програм і програмних систем, зростанням вимог до їх якості й надійності.
Мистецтво програмування якраз і полягає в тому, щоб вибрати МП, яка найкраще підходить для
розв’язання поставленої задачі.
3.3 Методології програмування
Кожна парадигма програмування фіксує рамковий підхід до розв’язання задач, в руслі якого фахівці
розвивають певну методологію програмування для сталого ресурсно ефективного забезпечення
якості й своєчасності програмних продуктів (ПП), прийнятної для їх споживачів, і задовільної
продуктвності розробників, насамперед програмістів.
Методологія програмування – це об’єднана єдиним філософським підходом сукупність
методів, що застосовуються в процесі створення програм і ПП.
Кожна методологія має властиві їй атрибути:
 парадигму програмування, що визначає основне джерело ефективності методології;
 узгоджену й упорядковану множину методів, за допомогою яких застосовують методологію;
 концепції (поняття, ідеї), що обьгрунтовують методи й дозволяють точніше їх описати.
Визначимо метод як це сукупність теоретичних принципів і практичних прийомів, які потрібно
застосувати для розв’язання певної задачі.
Основними методами, через які реалізується імперативна парадигма програмування, є:
 метод зміни станів, що полягає в послідовному зміні станів пам’яті (змінних) і підтримується
концепцією алгоритму;
 метод управління потоком виконання, який полягає в покроковому контролі управління і
підтримується концепцією потоку виконання.
Ранній стиль розробки імперативних програм характеризувався неструктурованістю – код
програми являв собою єдиний цілісний блок; переходи до потрібних секцій програми виконувалися за
допомогою операторів переходу (завичай, goto). Подібні проекти називали BS-програмами – «bowl of
spaghetti» – блюдо спагеті, бо так виглядала програма при спробі зобразити всі переходи між її
операторами.
Хорошими програмістами на той час вважалися ті, чиї програми мали мінімальний об’єм пам’яті та
швидко виконувалися, враховуючи тодішні можливості обчислювальної техніки. Однак, такі програми
було важко (якщо взагалі можливо) зрозуміти іншим фахівцям, а з часом – і автору. Тому при їх
розробці поставали проблеми забезпечення якості: утворення «спагетті-коду», складність його
перевірки і тестування.
Із збільшенням складності задач розмір програм постійно збільшувався. Типовою стала ситуація,
коли в різних місцях програми виникала необхідність в одній і тій же послідовності дій. Такі дії могли
бути досить складними і подаватися значними фрагментами програми. Для забезпечення компактності
й підвищення наочності програм було запропоновано оформляти повторювані фрагменти програми у
вигляді спеціальних синтаксичних конструкцій – підпрограм (процедур або функцій), які за
необхідності могли бути викликані для виконання з будь-якого місця основної програми.
 9
Методологія програмування, заснована на концепції виклику підпрограми, яка є логічно завершеним
фрагментом програми, отримала назву процедурного програмування.
Основні засади процедурного програмування:
 використання механізмів передачі параметрів і повертання результатів;
 розподіл областей дії змінних програми (локальні, глобальні),
 використання різних моделей пам'яті для зберігання змінних;
 блокова організація програм.
Основними методами, через які реалізується процедурне програмування, є:
 метод процедурної декомпозиції, який полягає у оформленні кожного логічно завершеного
фрагменти програми у вигляді підпрограми, і апр. олів на концепції виклику підпрограми;
 метод блочності, що розглядає програму як деяку ієрархічну структуру, яка складається з
головної програми і множини вкладених блоків (підпрограм), і апр. олів на концепції блокової
організації програм;
 метод локалізації даних, який полягає у видимості (доступності) даних, що обробляються у
підпрограмі, лише в межах підпрограми, і апр. олів на концепції розподілу областей дії змінних
програми;
 метод специфікації інтерфейсів, який полягає у формалізованому описі входів, виходів і
підпрограм;
 механізм раннього зв’язування, який полягає у статичному зв’язуванні підпрограм (на етапі
компіляції).
Моделлю обробки даних, характерною для процедурного програмування, є послідовне виконання
підпрограм, подане нотацією:
програма = послідовність процедур, кожна з яких – послідовність елементарних дій і викликів
процедур.
Використання процедурного підходу при розробці програм дозволяє зменшити розмір програмного
коду, усунувши дублювання, зробити програми прозорішими, прискорити процес їх написання і
тестування. Використання підпрограм дозволило розбивати великі задачі на підзадачі і таким чином
спростило написання великих програм.
Наступним кроком розвитку програмування стало підвищення структурованості програм –
структурне програмування (Е.В.Дійкстра, 1967р.). Дана методологія – це сукупність методів
проектування та написання програм за жорсткими правилами, дотримання яких підвищує
продуктивність праці програмістів, поліпшує читабельність і полегшує процес тестування програм.
Витоки цієї методології сягають 70-х років XX століття, коли швидкими темпами почала зростати
складність програм, а отже, постала потреба у методах подолання такої складності. Вона ґрунтується
на теоремі К.Бома-Дж.Якопіні (1966р.), які довели, що будь-який виконуваний алгоритм може бути
перетворений до структурованого вигляду, тобто такого виду, коли хід його виконання визначається
лише за допомогою трьох структур управління: послідовностей, розгалужень і циклів.
Методологія структурного програмування реалізується через методи:
1) структурного кодування (структурування програм);
2) низхідного проектування (спадного проектування, проектування «згори-донизу»);
3) блочного програмування;
4) процедурного структурного програмування;
5) паралельного документування.
Метод структурного кодування (1) передбачає, що будь-яка програма побудована з трьох
базових конструкцій:
 послідовне виконання – одноразове виконання операцій в тому порядку, в якому вони записані в
тексті програми;
 розгалуження – одноразове виконання однієї із двох або більшої кількості операцій, в залежності
від виконання деякої заданої умови;
 цикл – багаторазове виконання однієї і тієї ж операції до тих пір, доки виконується деяка задана
умова (умова продовження циклу).
В програмі базові конструкції можуть бути довільно вкладені одна в одну, але ніяких інших засобів
керування послідовністю виконання операцій не передбачено. Зокрема, неприпустимим є використання
оператора безумовного переходу (GOTO).
Мета структурування – перетворення неструктурованої програми на еквівалентну їй
структуровану, тобто складену з обмеженого набору керуючих алгоритмічних структур. Методи
 10
структурування ґрунтуються на поняттях функціонального вузла, а також на поняттях простої,
елементарної й складеної програми.
Елементарна програма – не містить блоків, складених більше ніж з одного вузла. Слід зазначити,
що існує обмежена кількість елементарних програм, з яких основними є три програми на рис. 3.6.

Рисунок 3.6 – Основні елементарні програми: послідовність (а), вибір (б), цикл з передумовою (в)
Якщо функціональний вузол елементарної програми замінити елементарною програмою,
утвориться складена програма. Якщо вузол складеної програми замінити елементарною програмою,
знов утвориться складена програма. В такий спосіб з будь-якої множини елементарних програм
утворюється певний набір складених програм.
Складену програму, побудовану з множини елементарних програм, звуть структурованою.
Позначимо літерою S клас складених програм, базисна множина якого містить такі елементарні
програми, як послідовність (рис. 3.6, а), вибір (рис. 3.6, б) і цикл з передумовою ( рис. 3.6, в).
Теорема Бома-Якопіні про структурування стверджує, що будь-яку просту програму шляхом
покрокового перетворення можна замінити функціонально еквівалентною структурованою програмою з
класу S.
Згадане покрокове перетворення здійснюється за правилами (рис. 3.7):
1) правило простоти – створення програми слід починати із простої програми;
2) правило пакетування – кожну дію можна замінити двома послідовними діями (вихід одного
функціонального вузла з'єднується із входом наступного);
3) правило вкладання – кожну дію можна замінити будь-якою структурою керування (будь-який
блок може бути замінений на структуру керування вибору або повторення);
4) правила 2 і 3 можна застосовувати у будь-якій послідовності необмежену кількість разів.

Рисунок 3.7 – Застосування правил пакетування та вкладання до простої програми

Для перетворення неструктурованих програм у структуровані застосовують методи:
 дублювання кодів,
 введення змінної стану,
 булевих ознак.
Метод дублювання кодів застосовують для перетворення неструктурованих програм, що не містять
циклів. Для отримання структурованої програми дублюють ті блоки (модулі), до яких можна «увійти» з
кількох точок.
Приклади. 1. Стуктуруємо неструктуровану програму з блок-схемою на рис. 3.8 (блоки позначені
ідентифікаторами модулів), яка свідчить, що модуль М5 не може виконуватися, доки не стануть
 11
відомими результати роботи модулів М2 і МЗ.
Подамо цю програму як просту, складену з елементарних програм типу вибору. Користуючись
правилом вкладання, розширимо блоки MX і MY, замінивши їх елементарними програмами типу
вибору. В результаті заміни модуль М5 продублюється (рис. 3.9).

Рисунок 3.8 – Блок-схема неструктурованої програми

Рисунок 3.9 –Результат перетворення неструктурованої програми в структуровану

2. Розглянемо блок-схему неструктурованої програми з циклами й нумерованими блоками (рис.
3.10).

Рисунок 3.10 – Блок-схема неструктурованої програми з циклами

У програму вводиться нова змінна i. Цій змінній присвоюється номер блока, на який потрібно
 12
передати керування. Зокрема, якщо істинна умова А, то цій змінній присвоюється номер блока В, тобто
2, якщо істинна умова С, змінній і присвоюється 1 — номер блока А.
Логічні блоки неструктурованої блок-схеми замінюються елементарними програмами типу вибору,
що послідовно перевіряють значення змінної стану. Гілки «так» програм типу вибору мають містити
оператори присвоєння нових значень змінній стану й оператори перевірки певних умов початкової
програми. Отриману блок-схему відповідної структурованої програми подано на рис. 3.11.

Рисунок 3.11 – Блок-схема структурованої циклічної програми з рис.3.10

Метод булевої ознаки використовується для перетворення неструктурованих програм, що містять
цикли. В програму вводиться додаткова змінна, яка набуває значення true чи false. Доки змінна ознаки
зберігає це значення, виконання циклу триває. Значення змінної ознаки всередині циклу модифікується
лише за певних умов.
В основу методу низхідного проектування (2) покладено структурну декомпозицію задачі із
застосуванням принципу покрокової (поетапної) деталізації. Низхідне програмуваня ектування
передбачає, що розробка програм ведеться методом «згори донизу», від загального до деталей.
Спочатку задача розглядається як єдиний блок, що відображає загальне призначення програми. Далі
ця задача поділяється на декілька дрібніших підхадач у тому порядку, в якому вони мають
виконуватися. Потім кожна з підзадач розбивається на свої під задачі другого рівня деталізації і т.д.
Процес покрокової деталізації підзадач здійснюється, поки підхзадачі чергового рівня не стануть досить
простими для незалежного розв’язання (наприклад, кожній із них буде відповідати окрема команда МП).
Блочне програмування (3) — це організація програми у вигляді сукупності відносно незалежних
складових частин – блоків, якими фактично є підпрограми. Як показує практика, великі задачі простіше
вирішуються, якщо розглядати їх як сукупність менших задач.
Як правило, програмний блок розв’язує порівняно нескладну задачу, логічно незалежну від інших
 13
задач. Його властивості:
 відповідає лише одній задачі;
 має один вхід і один вихід;
 має порівняно невеликий розмір;
 доступний за своїм ідентифікатором;
 може викликати інший блок (не в усіх мовах програмування);
 підтримує незалежність функціонування (заміна підпрограми на аналогічну не впливає на всю
програму).
Тобто, кожна програма представляється лінійною послідовністю блоків. Кожен блок складається з
одного або декількох інших блоків, кожен із яких має також рівно один вхід і рівно один вихід і сам може
розглядатися як блок. Сенс блоків, що мають один вхід і один вихід, полягає в тому, що можна вийняти
їх, змінити їх начинку і вставити назад без зміни інших сполучень в програмі.
Блоки повинні бути незалежними в межах інтерфейсу програми і структури даних. Практика
показала, що чим вищий ступінь незалежності підпрограм, тим простіше розібратись в окремих
програмних блоках і в програмі в цілому; тим менша ймовірність так званого хвильового ефекту –
появи нових помилок при виправленні старих або при внесенні змін у апр. олі. Тому не варто без
крайньої необхідності використовувати в підпрограмах глобальні змінні. Всі зв'язки між підпрограмами
мають підтримуватися через списки параметрів.
Процедурне структурне програмування (4) передбачає використання принципу процедурної
декомпозиції на всіх рівнях проектування ПС. За цим принципом кожен логічно цілісний програмний
блок, отриманий на певному рівні деталізації, оформлюється як підпрограма. Наприклад, підпрограма
обчислення визначника матриці, підпрограма знаходження суми елементів ряду.
Розробка процедурної структурованої програми ведеться покроково, методом «згори донизу» з
використанням механізму так званих «заглушок» - підпрограм, які нічого не роблять. При цьому
спочатку пишеться основна програма, у якій замість кожного логічного зв’язного фрагмента тексту
вставляється виклик підпрограми, яка буде виконувати цей фрагмент. Замість справжніх, працюючих
підпрограм, в програму вставляються «заглушки». Отримана програма перевіряється та
налагоджується. Після того, як програміст переконається, що підпрограми викликаються в правильній
послідовності, тобто загальна структура програми вірна, підпрограми-«заглушки» послідовно
замінюються на реально працюючі, причому розробка кожної підпрограми ведеться тим же методом,
що і основної програми. Розробка закінчується тоді, коли не залишиться жодної «заглушки», яка не
була б видалена.
Таким чином, «заглушки» дозволяють перевірити логіку програми верхнього рівня до реалізації
наступного. Тобто на кожному кроці розробки програми існує працездатний «каркас», який поступово
обростає деталями. Така послідовність гарантує, що на кожному етапі розробки програміст одночасно
має справу з доступною для огляду і зрозумілою йому множиною апр. олтів і може бути впевнений,
що загальна структура всіх більш високих рівнів програми вірна. При супроводженні та внесенні змін у
програму з’ясовується, в які саме процедури потрібно внести зміни, і вони вносяться, не зачіпаючи
безпосередньо не пов’язані з ними частини програми. Це дозволяє гарантувати, що при внесенні змін і
виправленні помилок не вийде з ладу якась частина програми, що знаходиться в даний момент поза
зоною уваги програміста.
Одним із прийомів формалізованого підходу до низхідного процедурного проектування є метод
ієрархічних діаграм абревіатурою (Hierarchical Input Processing Output, НІРО — діаграма входу,
обробки, виходу). Згідно з цим методом структура всієї програми подається у вигляді дерева, в якому
підпрограми зображуються вузлами, а їхні виклики — ребрами.
Сутність методу паралельного документування (5) полягає у тому, що при розробці програм
документація повинна створюватися одночасно із програмуванням, зокрема, у вигляді коментарів до
програми. Документування апр. олів тексту дозволяє будь-якому програмісту легко читати і
розуміти його у процесі розробки та подальшого супроводу.
Отже, в руслі методології структурного програмування програма ієрархічно структурується та
розробляється шляхом послідовного уточнення на кожному рівні ієрархії за принципами ієрархічності
та абстрагування.
Вдалою є та абстракція, що висвітлює суттєві деталі й відкидає несуттєві: під час низхідного
проектування програми на верхніх рівнях абстракції деталі реалізації приховуються, а на нижніх рівнях
вони описуються адекватною МП.
Фактично такий підхід збільшив структурованість програм – велика програма стала сукупністю
процедур-підпрограм. Одна підпрограма, головна, розпочинала роботу всієї програми.
Методи низхідного проектування та блочного програмування регламентують процес побудови
 14
архітектури програми на макрорівні. Методи структурування, навпаки, працюють на мікрорівні,
регламентуючи процес створення власне програмного коду.
Впровадження принципів структурного програмування зробило тексти програм, навіть досить
великих, більш читабельними. Значно полегшилося розуміння програм, створилися передумови
промислової розробки програм, коли їх може зрозуміти не лише автор, а й інші програмісти, полегшився
й прискорився процес розробки ПЗ.
Розвитком ідей процедурного програмування внаслідок подальшого зростання об'єму й складності
ПЗ, стала методологія модульного програмування.
Основна ідея модульного програмування – організація програм як сукупності незалежних
блоків, званих модулями.
Визначальним принципом модульного програмування є незалежність модулів: програма має бути
поділена на модулі так, щоб зв'язки між ними були слабкими (слабка зв’язність, low coupling), а
всередині модулів — сильними (сильна зчепленість, high cohesity).
Модулі вважають незалежними, якщо:
 кожен модуль можна замінити іншим функціонально еквівалентним модулем з тим самим
інтерфейсом;
 взаємозв’язки між модулями встановлені за ієрархічним принципом;
 всі структури даних інкапсульовані в модулі, тобто доступ до даних можливий лише через
процедури й функції модуля;
 модуль має одну точку входу та одну точку виходу;
 модуль повертає керування тому програмному блоку, що його викликав.
При розбитті програмного забезпечення на модулі для кожного модуля визначається
функціональність, яку він має реалізувати, та зв’язки з іншими модулями.
При цьому функціональність модуля (що він має виконувати) відокремлюється від його реалізації
(як він це виконує). Зв’язки між модулями здійснюються через спеціальний інтерфейс, тоді як доступ до
реалізації модуля (коду підпрограм і «внутрішніх» змінних) заборонений. Тобто знаючи, що робить
модуль та як його викликати, можна без обмежень використовувати його, не маючи жодного уявлення
щодо його реалізації. Такий підхід розмежовує доступ до даних програми, зменшуючи кількість
помилок, що виникають при роботі з ними.
Третя ідея модульного програмування – групування підпрограм і даних, якими вони управляють, в
окремо компільовані файли, також звані модулями. Основна програма може підключати такі модулі йі
використовувати підпрограми, що містяться в них. Так забезпечується можливість автономної реалізації
й зберігання коду (в бібліотеках модулів) та збирання програм з модулів.
Таким чином, основними ідеями модульного програмування є:
 автономна реалізація модулів (в бібліотеках модулів),
 автономна компіляція,
 збирання програм з модулів.
Основними методами модульного програмування є:
 метод забезпечення незалежності модулів, який полягає у розробці модулів, відносно
ізольованих один від одного;
 механізм пізнього зв’язування, який полягає у динамічному виклику модулів (на етапі виконання).
Розбиття на модулі зменшує час перекомпіляції і полегшує процес налагодження програм,
приховуючи несуттєві деталі за інтерфейсом модуля і дозволяючи налагоджувати програму по
частинах. Інтерфейсом модуля є заголовки всіх підпрограм і описи доступних ззовні типів, змінних і
констант. Використання модульного програмування істотно спрощує розробку програмного
забезпечення, зокрема, шляхом розподілу процесу його розробки між групами розробників. Крім того,
модулі надалі без змін можна використовувати в інших розробках, що підвищує продуктивність роботи
програмістів. У разі колективної розробки модульної програми робота розподіляється так: більш
досвідчені програмісти відповідають за інтерфейс модулів, а менш досвідчені — за їх реалізацію.
Модульний принцип покладено в основу практично всіх стилів програмування.
3.4 Технології програмування
Методологія програмування надає «фундамент» для формування та опису конкретних технологій
програмування – систем виробничих процесів створення запитаного ПЗ.
У технології програмування акцент робиться саме на процесах розробки програм (технологічних
процесах) у порядку їх виконання. В руслі певної методології може бути розроблено декілька технологій
програмування.
Як і довільна технологія, технологія програмування являє собою набір технологічних інструкцій, що
 15
охоплюють:
 послідовність виконання технологічних операцій;
 опис умов виконання операцій;
 описи самих операцій включно з визначенням вхідних і вихідних даних, результатів, інструкцій,
нормативів, стандартів, критеріїв і методів оцінки.
Так, процес розробки програм в імперативній парадигмі (вибраній для простоти) поєднує такі етапи:
1) постановка задачі;
2) її формалізація;
3) вибір методу вирішення задачі;
4) розробка алгоритму програми;
5) розробка тексту програми;
6) тестування і налагодження програми.
Постановка задачі. Полягає у формулюванні опису умови задачі, визначенні її вхідних і вихідних
даних, а також форми видачі результатів. Для цього треба однозначно й узгоджено, між розробниками
й причетними сторонами, відповісти на питання:
 Що дано?
 Які дані припустимі ?
 Які результати і в якому вигляді мають бути отримані ?
 За яких умов можливе отримання передбачених результатів, а за яких – ні ?
 Які результати вважаються коректними?
Постановка задачі завершується створенням зовнішньої специфікації програми, що містить:
 опис вихідних даних і результатів (типи, формати, точність, спосіб передачі, обмеження);
 опис задачі, що реалізується програмою;
 спосіб звернення до програми;
 опис можливих аварійних ситуацій і помилок користувача.
Таким чином, програму розглядають як «чорну скриньку», для якої визначено функції та вхідні й
вихідні дані.
Формалізація задачі. На цьому етапі розгорнутий опис задачі формалізується – заміняється її
математичною моделлю – математичними залежностями, які пов’язують вхідні дані з вихідними
результатами, або інформаційною моделлю, в якій встановлено залежність між даними та способами їх
отримання (наприклад, бази даних – БД).
Пвд час побудови моделі визначаються істотні характеристики задачі, тобто виконується її
абстрагування.
Вибір методу вирішення задачі. Виконується аналіз відомих розробникам методів розв’язання
формалізованої задачі, зокрема, для математичної моделі – аналіз та аргументований вибір
відповідного математичного / числового методу. Найкращий метод вибирають за спроможністю для
функціоналу та критеріїями складності, ефективності, точності залежно від очікувань причетних сторін і
можливостей команди.
На цьому етапі також визначають середовище виконання програми: вимоги до апаратури,
операційної системи, програмного оточення.
Під час вибору МП слід враховати:
 функціональне призначення системи;
 клас розв’язуваних задач;
 склад технічних засобів системи;
 необхідну швидкість роботи програми;
 обмеження на об’єм використовуваної пам’яті;
 можливість розбиття програми на модулі;
 необхідність перенесення на інших типів ЕОМ;
 наявність ефективних трансляторів;
 необхідність використання вже розроблених пакетів програм;
 використовувані операційні системи;
 необхідність роботи із зовнішніми пристроями;
 типи даних, з якими працює програма;
 наявність достатніх бібліотек стандартних програм для обробки інформації відповідного типу та
організації;
 професійні можливості розробників та наявного ПЗ.
Розробка алгоритму програми. Неформально алгоритмом називається опис у зрозумілій для
 16
виконавця формі послідовності операцій над вхідними даними, виконання яких забезпечує досягнення
поставленої мети. Він має бути якомога повнішим і точнішим, враховувати максимум можливих ситуації
функціонування програми.
Алгоритм розв'язання задачі розбивають на більш прості складники (модулі), щоб їх програмування
було незалежним. Складається блок-схема програми, де виділяють головну програму й підпрограми та
їх взаємозв’язки. Встановлюють початкові дані та результати підпрограм.
Розробка тексту програми. Для опису алгоритмів на зрозумілій ПК мові, використовують МП.
Етап розробки тексту програми саме і полягає у кодуванні алгоритму на обраній мові
програмування. На цьому етапі основну увагу приділяють питанням синтаксичної правильності та
забезпеченню документованості програмного тексту, що дозволяє будь-якому програмісту легко читати
і розуміти програмний текст у процесі розробки та супроводу.
Тестування та відлагодження програми. Частину синтаксичних помилок, допущених при написанні
програми, виявляє транслятор. Правильність же виконання обчислень і передачі керування (логічна
перевірка) виявляються програмістом в процесі налагодження програми шляхом порівняння очікуваних
і отриманих результатів. Відлагодження програми – це процес виявлення і усунення змістовних
помилок і залишкових дефектів, виявленних під час тестування. Тестування – перевірка коректності
поведінки програми за різних (не)коректних вхідних даних – займає в середньому не менше половини
часу розроблення.
Отже, в методології програмування (в руслі певної парадигми) методи розглядаються «знизу» – в
аспекті їх побудови, а в технології програмування за цією методологією – «зверху», тобто в аспекті
організації технологічних процесів розроблення програмних продуктів.
3.5 Показові новітні парадигми програмування
Автоматне програмувавання (А.Шалито, automata.pdf).
Агентне програмувавання (agent.pdf).
Аспектне програмування (aspect.pdf; Orlov_PI.pdf, c.322-328).
Генеруюче програмування (gener.pdf).
Компонентно-орієнтоване програмування (комп-ор.pdf).
Сервіс-орієнтоване програмування
Парадигма передбачає використання сервіс-орієнтованої архітектури (SOA), в якій для забезпечення
модульності застосовують розподілені слабко зв’язані компоненти (Веб-сервіси), що взаємодіють за
допомогою стандартизованих апр. олів.
Характеристики Веб-сервісів:
 модульність: сервіс надає логічно пов’язані функції в певній предметній галузі із заданими
входами й виходами;
 автономність : відсутність залежностей, які можуть спостерігати споживачі;
 прихованість реалізації: Веб-сервіс розглядається як чорна скринька.
Переваги SOA:
 відкритість, стандартизація протоколів доступу;
 підтримка паралельного виконання, масштабованість;
 відмовостійкість.
Обмеження SOA:
 залежність від стану мережних з’єднань;
 додаткові обчислювальні ресурси, ПЗ і витрати для підтримки масштабування;
 проблеми забезпечення безпеки даних, якості обслуговування (Quality of Services)
Найпоширеніші два типи веб-сервисів: SOAP-сервіси та REST-сервіси.
SOAP-сервіси використовують стандарти доступу й опису інтерфейса, запропоновані W3C – SOAP
(Simple Object Access Protocol) і WSDL (Web Service Definition Language). Отже, зате мають додаткові
можливості, відсутні для REST-сервісів, апр.., адресацію. Доступні для композиції за допомогою мови
BPEL (Business Process Execution Language).
REST-сервіси викорпистовують для передавання даних засоби протоколу HTTP. На відміну від
SOAP-сервісів їх інтерфейс визначається неформально в документації.
Історія розвитку парадигм наразі дозволяє виділити підстави, базові принципи та тенденції їх
подальшої еволюції, підсумовані Д.Сімондсом (Еволюція парадигм.pdf)
Лекція 4_22_09_2022 – Інженерія вимог до програмних засобів
Корисні ресурси:
https://www.modernanalyst.com/Community/CommunityBlog/tabid/182/ID/5833/Top-10-Mistakes-in-Requirements-
Elicitation.aspx
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, підрозділи 2.1-2.8
proIS.pdf, підрозділ 10.1,10.2, додатково 10.3-10.5
ЯПЗ_Т.pdf, підрозділ 1.4 (модель вимог Р.Грейді FURPS), 4.1-4.4
додатково
vigers.pdf
Маглинець_IT.pdf
Orlov_PI.pdf, розд.4,9
4.1 Основні процеси інженерії вимог
4.1.1 Нормативне забезпечення та засади інженерії вимог
Комплексну діяльність з вилучення, узгодження, встановлення пріоритетів, документування та повторного
використання вимог у процесі конструювання програмного забезпечення (ПЗ) звуть наразі Інженерією
вимог до ПЗ і розглядають як цілісний під-процес процесу конструювання ПЗ.
Кращі практики Інженерії вимог регламентовано в наведених далі стандартах:
а) де-юре міжнародного й національного рівня
1) ISO/IEC/IEEE 29148:2018 Software and systems engineering – Life cycle processes — Requirements
engineering (Програмна та системна інженерія – Процеси життєвого циклу – Розроблення вимог) –
ДСТУ відсутній
2) ДСТУ ISO/IEC/IEEE 12207-2018 (ISO/IEC/IEEE 12207:2017, IDT): три Технічні процеси:
 Визначення бізнесу або місії;
 Визначення потреб і вимог причетних сторін (званих також стейкхолдерами);
 Визначення вимог до системи/ПЗ;
3) ДСТУ ISO/IEC TR 19759:2016 (ISO/IEC TR 19759:2015, IDT) Програмна інженерія. Настанова щодо ядра
знань програмної інженерії (SWEBoK V.3): область знань «Програмні Вимоги» – знання щодо дій і технік
вилучення, аналізу, специфікування й валідації, впорядкування за важливістю, документування вимог до
програмного забезпечення (ПЗ), а також керування вимогами впродовж усього життєвого циклу (ЖЦ) ПЗ.

Структура області знань «Програмні вимоги» за SWEBoK V.3

 2
б) де-факто
4) PMBoK PMI 6 ред. (процес 5.2 у групі процесів планування та області знань «управління змістом»),
PMBoK 7 ed (2021р.). – у форматі 10 взаємопов’язаних принципів надання цінності:
1. створювати середовище співпраці проектної команди;
2. ефективно залучати стейкхолдерів;
3. фокусуватися на цінності;
4. виявляти, оцінювати та реагувати на системні взаємодії;
5. демонструвати лідерську поведінку;
6. вбудовувати якість у процеси та результати;
7. опрацьовувати складність (navigate complexity);
8. оптимізувати реагування на ризики;
9. застосовувати адаптивність та стійкість;
10. підтримувати зміни для досягнення очікуваного майбутнього стану,
PMI Requirements management: А practice guide, 2016;
5) BABoK V.3 Міжнародного інституту бізнес-аналізу (IIBA) (розд. 5 «Життєвий цикл вимог», розд. 7
«Аналіз вимог і визначення проекту»), система шаблонів специфікації вимог IIBA;
6) Requirements Engineering Body Of Knowledge (REBOK), що розробляється групою під керівнцтвом
проф. Аояма (Mikio Aoyama)в Nanzan University, Японія;
7) курс для отримання статусу «Certified Professional for Requirements Engineering» IREB (International
Requirements Engineering Board, ФРГ, https://www.ireb.org/en)
Klaus Pohl, Chris Rupp. Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for
Requirements Engineering Exam;
8) система шаблонів процесу вилучення, аналізу, специфікування, валідації й документування в руслі
перспективних методологій конструювання ПЗ, зокрема:
 жорстких планових (ГОСТ19 – Єдина система програмної документації (ЕСПД), ГОСТ34 – Єдина
система конструкторської документації (ЕСПД);
 ітеративних (RUP, MSF, ICONIX) – за допомогою варіантів використання;
 гнучких – за допомогою історій користувача;
9) система шаблонів успішних організацій-розробників, напр. Doors Telelogic, EARS (Easy Approach to
Requirements Syntax, Alistair Mavin, компанія Rolls-Royce, Велика Британія);
10) технологічні моделі ефективних процесів інженерії вимог, запроваджені в успішних організаціях-
озробниках і/або запропоновані авторитетними фахівцями, напр. процес Volere (J.Robertson,
https://www.volere.org/course/mastering-the-requirements-process/?).
Кращі практики інженерії ПЗ декларують: не є успішним програмний проект:
– з незадоволеними очікуваннями споживачів і замовника;
– результати якого не використані кінцевими користувачами.
Причетні сторони мають не вимоги, а
Очікування – «умоглядну картинку майбутнього»
Зазвичай – досить широку.
Приклад очікування: «зростання продуктивності відділу після впровадження ІТ-системи»; «щоб
виконання проекту та впровадження ПС не надто вплинуло на роботу сусіднього департаменту».
Очікування не можна долучити до програмного проекту й задовольнити, не перетворивши на вимогу.
Вимога – конкретний, вимірний, перевіюваний запит зацікавленої особи
Приклад вимоги: «Програмна система має дозволяти проходити всі сценарії користувача без маніпулятора
«миша».
Програмні вимоги – Software Requirements – властивості програмного забезпечення, які мають бути
йому притаманні для розв’язання конкретних практичних задач, підтримка яких складає його
призначення.
Програмні вимоги – сукупність тверджень щодо конкретних властивостей і характеристик, які
повинне мати програмне забезпечення, щоб ним можна було користуватися для вирішення тих
задач, для яких воно призначене.
Вимоги визначають, яка поведінка програмної системи (ПС) є правильною і бажаною («якісною»), а
яку слід вважати некоректною. Тому вимоги відіграють провідну роль у конструюванні, тестуванні та
обслуговуванні – саме їх треба реалізувати, перевіряти та, за доцільності, змінювати.
 3
Щоб вимоги до ПС можна було впевнено застосовувати під час її розроблення й тестування, вони повинні
мати низку характеристик, зафіксованих у стандартах з розроблення ПС. ISO/IEC/IEEE 29148:2018 і його
джерелах – де-факто стандарти IEEE Std. 1362-98, 1233, 830 визначають необхідні характеристики
правильно складених вимог:
1) адекватність – відповідність реальним потребам користувачів ПС;
2) однозначність, тобто відсутність можливості різного тлумачення;
3) повнота, тобто відображення у вимогах всіх істотних потреб і всіх ситуацій, за яких ПС має
функціонувати;
4) несуперечність, або узгодженість, між різними елементами вимог;
5) систематичність подання – вимоги мають бути описані в межах деякої системи з чітким зазначенням
місця кожної вимоги серед інших, з визначенням зв'язків і залежностей між ними та пріоритетності для
причетних сторін;
6) відстежуваність – вимоги повинні мати чітко визначені зв'язки з модулями створюваної ПС,
частинами проектної документації та тестами, щоб завжди можна було визначити, для виконання або
перевірки яких вимог створений кожний з цих елементів і наскільки він їм відповідає;
7) придатність до перевірки, тобто можливість для кожної вимоги однозначно встановити за
допомогою певної процедури аналізу поведінки ПС, виконана вимога чи ні;
8) придатність до модифікації, тобто можливість змінення вимог із швидким усуненням їх
суперечностей.
або за ISO/IEC/IEEE 29148:2018
1. Необхідність 1. Necessary
2. Абстрактність 2. Abstract
3. Недвозначність 3. Unambiguous
4. Взаємоузгодженість 4. Consistent
5. Повнота 5. Complete
6. Чіткість, сприйнятність 6. Concise
7. Виконуваність 7. Feasible
8. Трасовність 8. Traceable
9. Верифіковність 9. Verifiable
Збирання вимог – відповідальність менеджера проекту (який може залучати до неї членів команди з
довільними ролями). Нехтуючи нею – він ризикує в кращому разі «закрити контракт формально, зіпсувавши
відносини із замовником» (для замовного проекту), а в гіршому – внеможливити здавання продукту через
претензії ключових причетних сторін, очікування яких не задоволені.
4.1.2 Класифікація вимог
4.1.2.1. Рамкові альтернативні класифікації вимог до ПЗ описані класиками інженерії вимог –
К.Вігерсом (vigers.pdf) (рис. 4.1а)) і Д.Леффінгвеллом, Д.Відрігом (рис. 4.1б)). Рівні класифікацій визначені
призначеністю вимог.
4.1.2.2 Функціональні та нефункціональні вимоги (Functional and Non-functional Requirements) –
функціональні вимоги задають, «що» ПС має виконувати; нефункціональні – з дотриманням «яких умов»
(напр., час реагування під час виконання певної операції).
Роботи К.Вігерса, А.Коберна, Д.Лефінгвелла і Д.Відрига визначають різні категорії (види) вимог і
пов'язаних з ними понять:
•1. Потреби (needs) – відображають проблеми бізнесу, зацікавленої сторони або процесу, які мають бути
співвіднесені з використанням чи придбанням ПС;
•2. Група функціональних вимог – пов'язані безпосередньо з функціональністю ПС, спрямованою на
задоволення бізнес-потреб:
2.1 Бізнес-вимоги (Business Requirements) – визначають високорівневі цілі організації або клієнта
(споживача) – замовника програмного забезпечення, що розробляється, відповідаючи на запитання Чому
створюється продукт
2.2 Користувацькі вимоги (User Requirements) – описують цілі/завдання користувачів системи, які
мають досягатися/виконуватися користувачами за допомогою створюваної програмної системи. Ці вимоги
часто подають у вигляді варіантів використання (Use Cases).
2.3 Функціональні вимоги (Functional Requirements) – визначають функціональність (поведінку)
програмної системи, яка має бути створена розробниками для надання можливості виконання користувачами
своїх обов'язків у рамках бізнес-вимог і в контексті вимог користувача.
 4

а) б)
Рисунок 4.1 – Рівні вимог за К.Вигерсом і Д.Леффінгвеллом
•3. Група нефункціональних вимог (Non-Functional Requirements)
3.1 Бізнес-правила (Business Rules) – включають чи пов'язані з корпоративними регламентами,
політиками, стандартами, законодавчими актами, внутрішньо-корпоративними ініціативами (напр.,, прагнення
досягти зрілості процесів за CMMI 4-го рівня), обліковими практиками, алгоритмами обчислень тощо.
Business Rules Group визначає бізнес-правила як «положення, що визначають чи обмежують деякі аспекти
бізнесу. Вони стосуються організації структури бізнесу, контролюють або впливають на поведінку бізнесу».
Бізнес-правила часто визначають розподіл відповідальності в ПС, відповідаючи на питання «хто
виконуватиме конкретний варіант використання» або зумовлюють певні функціональні вимоги.
Розроблено методи формального подання бізнес-правил, аж до формальних мов опису (OCL – Object
Constraint Language, BRML – Business Rules Markup Language).
3.2 Атрибути якості (Quality Attributes) – описують додаткові характеристики продукту у різних
«вимірах», значущих для користувачів і/або розробників, і стосуються переносності, інтероперабельності
(прозорості взаємодії з іншими ПС, цілісності, стійкості тощо.
3.3 Зовнішні інтерфейси (External Interfaces) – часто підмінюються «інтерфейсом користувача», але
крім нього насамперед охоплюють конкретизацію аспектів взаємодії з іншими ПС, апаратним і програмно-
апаратним оточенням, операційним середовищем (напр., запис до журналу подій операційної системи) та
можливості моніторингу поведінки ПС під час експлуатації;
3.4 Обмеження (Constraints) – формулювання умов, що модифікують вимоги або набори вимог,
звужуючи вибір можливих рішень з їх реалізації. Зокрема, до них можуть належати параметри
продуктивності, що впливають на вибір платформ реалізації і/або розгортання (протоколи, сервери додатків,
баз даних), що можуть належати до зовнішніх інтерфейсів.
•4.Системні вимоги (System Requirements) – високорівневі вимоги до програмного забезпечення (ПЗ) у
складі численних взаємозалежних підсистем і застосунків (серед яких можуть бути апаратні складники та
групи фахівців).
Поряд з описаною класифікацією вимог 1-4 використовують відносно незалежні поняття:
a) Високорівневі Властивості, або Характеристики (Features):
 за К.Вігерсом, це множина логічно пов'язаних функціональних вимог, які надають певні можливості для
користувача та задовольняють бізнес-цілі організації-розробника. З точки зору маркетингу ПЗ, це група
вимог, впізнавана зацікавленими особами, які приймають рішення щодо придбання ПЗ, тобто це список
вирізнюючих рис або можливостей в описі продукту;
 за Д.Леффінгвеллом, Д.Відрігом, це сервіси, які надає ПС для задоволення потреб зацікавлених сторін.
Features можуть мати різний рівень деталізації – від охоплення високорівневих можливостей системи
(наприклад, «Розрахунок заробітної плати…»), до конкретних вимог (наприклад, «Автоматичне повідомлення
 5
Клієнта за e-mail про резервування товару на складі»);
б) Незалежні, або загальні, властивості (Emergent Properties) – вимоги щодо (програмно-апаратної)
системи загалом, які не можна співвіднести з окремими її елементами. Такі вимоги стосуються
синергетичного ефекту, який може мати така система («ціле більше, ніж сума його частин»). Приклад –
вимога до «пропускної спроможності коллцентру», залежна від взаємодії комунікаційного обладнання,
оператора та програмного забезпечення в конкретних умовах;
в) Вимоги з кількісною оцінкою (Quantifiable Requirements) – вимоги, що піддаються кількісному
визначенню/вимірюванню, напр., «система має забезпечити пропускну здатність не менше 10 запитів на
секунду», часто приналежні до атрибутів якості й тому контекстно пов’язані з відповідними функціональними
вимогами.
У методології Раціонального уніфікованого процесу послідовно застосовують альтернативну
класифікацію вимог за моделлю FURPS+ (Р.Грейді, Hewlett-Packard; Маглинець_IT.pdf, с.25-27; ЯПЗ_Т.pdf,
підрозділ 1.4).
4.2. Рамковий процес інженерії вимог (vigers.pdf, розд. 3)
4.2.1 Модель процесу (рис. 4.2, 4.3):

Рисунок 4.2 – Рамковий ітеративний процес опрацювання вимог за К. Вігерсом

Рисунок 4.3 – Деталізований процес опрацювання вимог за К. Вігерсом

Процес не є дискретним; це постійний циклічний процес, задіяний на всіх етапах ЖЦ ПЗ. Його цикли
ініціюються на початку програмних проектів і продовжуються протягом усього ЖЦ ПЗ до завершення проекту.
Напр., функціональні тести створюють зідно з функціональними вимогами до ПС і зазвичай виконують під
час приймальних випробувань.
Ідентифікує програмні вимоги як елементи конфігурації (в термінах конфігураційного забезпечення) та
контролює їх за допомогою тих же практик конфігураційного управління, що й для інших активів програмних
проектів (наприклад, файлів або запитів на зміни).
Потрібна адаптація до проектного та/або організаційного контексту відповідного програмного проекту.
4.2.2 Учасники процесу
1. Менеджер проекту – відповідальний за якість і своєчасність документу специфікації вимог та її
актуалізацію.
2. Член(и) команди, які безпосередньо й активно працюють зі специфікацією вимог – зазвичай, бізнес-
аналітик, технічний письменник, тестувальник.
3. Причетні сторони (стейкхолдери) програмного проекту – це особи або організації, інтереси яких можуть
 6
зазнавати як позитивного, так і негативного впливу під час виконання або в результаті завершення проекту і
які спроможні справляти на успіх або невдачу проекту позитивний або негативний вплив.
До рамкового переліку стейкхолдерів належать (рис.4.4):
1) Внутрішні (в організації-розробнику):
1. члени команди проекту;
2. їх керівники у функціональних підрозділах (у лінійно-матричний організації-розробнику);
3. співробітники й керівники цільових і постійних допоміжних функціональних підрозділів (тестування,
системного ПЗ, формальних методів тощо) в лінійно-матричний організації-розробнику;
4. співробітники й керівники постійних робочих груп в процесі розроблення (гарантування якості,
системного адміністрування, вдосконалення процесу розроблення тощо);
5. співробітники апарату управління в організації, насамперед перші й другі особи;
6. співробітники офісів управління проектами різних рівнів;
7. (потенційні) обслуговники продукту.

Рисунок 4.4 – Основні групи стейкхолдерів у програмному проекті

2) Зовнішні (поза організацією):
1. Замовники (Customers)/Спонсори/Куратори/Придбавачі: суб’єкти цільової аудиторії на ринку ПЗ,
зокрема відповідальні за придбання/замовлення програмних продуктів;
2. Користувачі/Споживачі – особи, які мають безпосередньо користуватися ПС; користувачі можуть
описати задачі, які вони мають розв’язувати з використанням ПС, очікування щодо атрибутів якості та
обмеження;
3. Операційний персонал організації-замовника – об’єкта автоматизації.
4. Регулятори: багато галузей застосування ПЗ є нормативно регульованими, напр.,телекомунікації або
банківський сектор. ПЗ для цих галузей (насамперед, державного й корпоративного сектора) має відповідати
керівним документам і штатним процедурам, визначеним уповноваженими органами.
Приклад вимог від регуляторів – Постанова КМУ «Про внесення змін до деяких постанов Кабінету
Міністрів України щодо функціонування офіційних веб-сайтів органів виконавчої влади» від 12 червня
2012р.№ 493, що встановлює уніфіковані вимоги до дизайну та доступності розміщеної інформації для
офіційних веб-сайтів органів виконавчої влади;
5. Маркетингові аналітики (як у штаті організацій – потенційних покупців та/або замовників, так і
незалежні);
6. Промоутери;
7. Авторитетні члени фахових спільнот у предметній галузі, для якої створюється ПС;
8. Співробітники зовнішніх організацій, що можуть бути залучені до обслуговування ПС.
4.3. Вилучення вимог (Requirements Elicitation) (vigers.pdf, розд. 3,7)
4.3.1 Джерела вимог
Це перша стадія побудови моделі предметної галузі, для якої розробляється ПС.Без ідентифікації
причетних сторін, їх взаємодії, виконуваних ними бізнес-процесів неможливий успіх програмного проекту.
Ключовий принцип інженерії вимог за ISO/IEC/IEEE 29148:2018 – забезпечення конструктивної
взаємодії між користувачами та розробниками, що складають документ специфікації вимог з урахуванням
процесів групової динаміки і використанням технік та інструментів усної й письмової ділової комунікації.
Отже, вилучення, узгодження між собою й зі стейкхолдерами та документування у специфікації вимог –
перший вид цільової діяльності у програмному проекті, що вимагає використання інструментарію групової
 7
динаміки (з відповідної області знань SWEBoK V.3).
Необхідно ідентифікувати та узгодити всі можливі джерела вимог, значущі на вирішення завдань проекту,
щоб визначити ступінь їхнього впливу проект і значимість їх вимог для розробки ПС.
Джерела:
1. Цілі розробки ПС, що уточнюються під час аналізу здійсненності проекту – feasibility study;
2. Знання про предметну галузь використання ПС;
3. Причетні сторони;
4. Знання про об'єкт автоматизації:
– середовище виконання та операційне оточення – обмеження ефективності, супроводженості,
інтероперабельності;
– наявні інструментальні засоби;
– організаційне середовище,
– документообіг…;
5. Продукти інших розробників, зокрема конкурентів, партнерів, авторитетних фахових спільнот, що
задовольняють очікування, подібні до тих, які має підтримувати створювана ПС;
6. Власні продукти – функціональні аналоги створюваної системи;
7. Маркетингові огляди тенденцій ринку програмного забезпечення.
Для ретельного виявлення причетних сторін корисні установчі питання (собі та вже виявленим
представникам сторін):
 хто може сприяти або перешкоджати досягненню цілей проекту?
 хто найбільше зацікавлений у результатах проекту?
 хто приймає рішення на проекті?
 хто виступає експертом у проекті?
 хто працюватиме з результатами проекту після його реалізації?
Результати слід задокументувати у Реєстрі причетних сторін програмного проекту.
4.3.2. Техніки вилучення вимог
1. Интервьюрирование – традиционный подход извлечения требований; не стоит забывать, что
получение информации от пользователя “не равно” получению требований; информация должна быть
проанализирована и трансформирована в требования, таким образом, информация от пользователя
является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов:
– вільне інтерв’ю;
– структуроване інтерв’ю, коли респонденти надають відповіді на поставлені запитання або заповнюють
слоти фреймів;
– наративне інтерв’ю у формі наративу – слабко структурованої розповіді.
2. Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы
“что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями, зокрема:
– коментування й аргументування користувачем своїх дій;
– зворотнє навчання: стейкхолдера запитують про заперечення та змінення и щодо версії вимог.
3. Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют
разные подходы к прототипированию – от «бумажных» моделей до пилотных подсистем, реализуемых как
самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы
постепенно трансформируются в результаты проекта и используются для проверки и утверждения
требований;
4. «Разъясняющие встречи» («facilitated meetings») – запланированные коллективные обсуждения
для проактивного решения возникающей в проекте проблемы всеми ее заинтересованными лицами с
использованием универсальных техник фасилитации – совместной выработки взаимоприемлемого
решения (мирового кафе, открытого пространства);
5. Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров
рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования
бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия
представителя заказчика в проектной группе исполнителя ( типовая практика в eXtreme Programming «on-site
customer» – «присутствующий заказчик»); данная техника является достаточно затратной, но, в то же время,
очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и
взаимосвязанных бизнес-процессах.
6. Обстеження об’єкта автоматизації, насамперед засадничої документації, посадових інструкцій,
регламентного документообігу.
 8
Під час спілкування з «джерелами вимог» слід дотримуватися:
1) 10 правил ефективного слухання К.Девіса:
1. Перестаньте говорить. Невозможно слушать, разговаривая.
2. Помогите говорящему раскрепоститься. Создайте у человека ощущение свободы. Это часто
называют созданием разрешающей атмосферы (регуляція ємоционального напряжения).
3. Покажите говорящему, что вы готовы слушать. Необходимо выглядеть и действовать
заинтересованно. Не читайте почту, когда кто-либо говорит. Слушая, старайтесь понять, а не искать поводов
для возражений.
4. Устраните раздражающие моменты. Не рисуйте, не постукивайте по столу, не перекладывайте
бумаги. Будет ли спокойнее в кабинете, если закрыть дверь?
5. Сопереживайте говорящему. Постарайтесь встать в положение говорящего (применяя
эмоциональный и социальный интеллект).
6. Будите терпеливым. Не экономьте время. Не прерывайте говорящего. Не порывайтесь выйти, не
делайте шагов в направлении двери.
7. Сдерживайте свой характер Рассерженный человек придает словам неверный смысл.
8. Не допускайте споров или критики. Это заставляет говорящего занять оборонительную позицию, он
может замолчать или рассердиться. Не спорьте. Именно победив в споре, вы проиграете.
9. Задавайте вопросы. Это подбадривает говорящего и показывает ему, что вы слушаете. Это
помогает продвигаться вперед.
10. Перестаньте говорить! Это наставление идет и первым, и последним, ибо все остальные зависят
от него. Вы не сможете эффективно слушать, если будете разговаривать.
2) технік ефективної усної міжособистісної комунікації:
– активного слухання – формулювання (уточнюючих) питань, малої розмови, повторения,
перефразування, інтерпретації;
– регуляції емоційної напруги;.
– оберненого зв’язку та вербалізації почуттів.
4.4. Аналіз вимог (Requirements Analysis)
4.4.1 Сутність анлізу вимог
Анализ требований включает:
– обнаружение и разрешение конфликтов между требованиями;
– определение границ задачи, решаемой создаваемым программным обеспечением; в общем случае –
определение «scope», границ и содержания программного проекта;
– детализация системных требований для установления программных требований;
– установление приоритетов требований.
Практически всегда, хотя это явно и не отмечено в описании анализа требований как секции SWEBOK, на
практике выделяется и детализация бизнес-требований для установления программных требований.
Например, пресловутый режим работы 24x7, сформулированный в виде бизнес-требования, накладывает
достаточно жесткие рамки на выбор технологической платформы и архитектурных решений как технических
требований к разрабатываемой программной системе.
SWEBOK отмечает, что традиционный взгляд на анализ требований часто сфокусирован или уменьшен
до вопросов концептуального моделирования с использованием соответствующих аналитических методов,
одним из которых является SADT – Structured Analysis and Design Technique (методология структурного
анализа и техники проектирования), знакомый многим по нотациям IDEF0 (функциональное моделирование
– стандарт IEEE 1320.1), IDEF1X (информационное моделирование – стандарт IEEE 1320.2, известный также
как IDEFObject), часто применяемым как для моделирования бизнес-процессов, так и структур данных, в
частности – реляционных баз данных.
Вне зависимости от выразительных средств результатом анализа требований должны быть однозначно
интерпретируемые требований, реализация которых проверяема, а стоимость и ресурсы –
предсказуемы.
Для успішного вирішення конфліктів між можливостями розробника та очікуваннями замовника та між
вимогами різних зацікавлених сторін корисні спеціальні техніки:
1) генерування ідей (див. tv_resh.pdf)
– Прямой и обратный мозговой штурм, метод ключевых вопросов, анализ корневой причины
– Метод свободных ассоциаций;
– Метод инверсии;
– Метод 635;
– Метод Кроуфорда;
 9
– 6 шляп де Боно;
2) комунікативний метод Дельфи.
4.4.2 Класифікування вимог
Требования можно классифицировать по целому ряду параметров, например:
 функциональные и нефункциональные требования;
 внутренние (с другими требованиями) или внешние зависимости;
 требования к процессу или продукту;
 приоритет требований;
 содержание требований в отношении конкретных подсистем создаваемого программного
обеспечения;
 изменяемость/стабильность требований.
Другие варианты классификации могут, и часто базируются, на принятых в организации подходах,
применяемых методологиях, методах и практиках, а, зачастую, и специфике проектов и даже требованиях
заказчиков к процессу разработки и, в частности, определения требований и форме представления
результатов их анализа.
4.4.3 Концептуальне моделювання
Моделювання предметнї галузі та проблеми, для вирішення якої створюється – ключовий елемент
аналізу вимог. Ціль моделювання – узгоджене розуміння проблеми та методів її вирішення до їх застосуванн.
Среди факторов, которые влияют на выбор модели, метода и детализации ее представления, степени
связанности с программным кодом и другими вопросами:
 Природа проблемы (проблемной области)
 Экспертиза и опыт инженеров
 Требования заказчика к процессу
 Доступность методов и инструментов
 Внутрикорпоративные стандарты и регламенты
 Культура разработки
Могут быть разработаны различные виды моделей в русле структурного и объектно-ориентированного
подхода, включающие потоки работ и данных, модели состояний, трассировки событий, взаимодействия
пользователей, объектные модели, модели структур данных.
Фокус индустрии программного обеспечения смещается в сторону UML 2.0 и отходу (как минимум,
частичному) от IDEF, в применении к аналитической деятельности. Альтернатива – стандарт BPMN –
Business Process Model and Notation (см. www.bpmn.org/).
На практике наблюдается тенденция разделения вопросов определения требований и моделирования.
Это, например, заметно в современных методологиях, таких как RUP (Rational Unified Process), где работа с
требованиями и моделирование/проектирование – суть две разные дисциплины.
4.4.4. Встановлення пріоритетів вимог
1) традиційні методи та процедури К.Вігерса (див. vigers.pdf, розд. 16);
2) новітня процедура Н.Кано впорядкування вимог до функцій за їх привабливістю для користувача (див.
Вольфсон_ГУПП.pdf, с.21-23).
4.5. Специфікування вимог (Requirements Specification)
На инженерном жаргоне, да и в терминологии ряда методологий, устоялся термин «software requirements
specification» (SRS) – спецификация программных требований. Для сложных систем, на самом деле,
существует целый комплекс спецификаций, документов, которые являются результатом сбора и анализа
требований, их моделирования и архитектурного проектирования. Эти документы систематически
анализируются, в них вносятся изменения, они пересматриваются и утверждаются. Чаще всего, для
описания комплексных проектов (в части требований) используется три основных документа
(спецификации):
 Определение системы (system definition)
 Системные требования (system requirements)
 Программные требования (software requirements)

4.5.1 Визначення системи (System Definition Document)

Данный документ, часто называемый «спецификацией пользовательских требований» (user requirements
specification), описывает требования к ПС. Содержание документа определяет высокоуровневые требования,
часто – стратегические цели, для достижения которых создается программная система. Принципиальным
моментом является то, что такой документ описывает требования к системе с точки зрения области
 10
применения - “домена”. Соответственно, изложение требований в нем ведется в терминах прикладной
области. Документ описывает системные требования вместе с необходимой информацией о бизнес-
процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других
регламентов. Примером де-факто стандарта для создания и структурирования такого документа является
IEEE 1362 “Concept of Operations Document”.
4.5.2 Специфікація системних вимог (System Requirements Specification)
В сложных проектах принято разделять спецификацию системных требований (system requirements) и
спецификацию программных требований (software requirements). При таком подходе программные
требования порождаются системными требованиями и детализируют требования к компонентам и
подсистемам программного обеспечения. Документ описывает программную систему в контексте системной
инженерии (system engineering). Де-факто стандарт IEEE 1233-1998. Guide for Developing System
Requirements Specifications является одним из признанных руководств по разработке системных
требований.
4.5.3 Специфікація програмних вимог (Software Requirements Specification - SRS)
Часто эту спецификацию называют также «требованиями к программному обеспечению». В ней
устанавливают основные соглашения между пользователями (заказчиками) и разработчиками
(исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать.
Документ может включать процедуры проверки получаемого программного обеспечения на соответствие
предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики,
определяющие качество и методы его оценки, вопросы безопасности и многое другое. Часто программные
требования описываются на обычном языке. В то же время, существуют полуформальные и формальные
методы и подходы, используемые для спецификации программных требований. В любом случае, задача
состоит в том, чтобы программные требования были ясны, связи между ними прозрачны, а содержание
данной спецификации не допускало разночтений и интерпретаций, способных привести к созданию
программного продукта, не отвечающего потребностям заинтересованных лиц. Де-факто стандарт IEEE 830-
1998 Recommended Practice for Software Requirements Specifications является классическим примером
стандарта на содержание, структурирование и методы описания программных требований.
Необходим отметить, что в документацию на требования не следует вносить элементы дизайна системы
(скажем, логическую модель базы данных). А вот сценарии использования Use Case часто включают в
спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм,
например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании спецификаций требований, то
есть одно серьезное заблуждение, которое делают обычно неопытные аналитики – это фактическая
подмена требований как таковых, моделями графического пользовательского интерфейса, т.е. когда в
документы-спецификации требований просто включаются «картинки» пользовательского интерфейса с
небольшими пояснениям. Это отнюдь не означает, что с заинтересованными лицами и в частности с
пользователями, не следует вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого
существует, например, прототипирование.
Наразі IEEE Std.1362, 1233, 830 підсумовані й замінені ISO/IEC/IEEE 29148:2018, де System Definition
відповідає специфікація вимог зацікавлених сторін (StRS).
Послідовність створення специфікацій трьох рівнів подано на рис. 4.5., який надає конструктивне
уточнення рамкового процесу К.Вігерса на рис. 4.1, 4.2.
Для фіксації подання вимог до ПС (StRS, SyRS, SRS) зазвичай застосовують:
 природну мову зі спеціальними патернами, структуровану за певним підходом для запобігання
помилкам і дефектам (див. Шаблони_SRS_2022.pdf);
 мови опису програм (напр., VDM, RAISE);
 графічні нотації (напр., UML, IDEF);
 математичні специфікації (напр., скінчені автомати).
Вибір нотації зумовлений відповідями на питання:
 хто споживач і користувач подання в певній нотації?
 з якою метою та як споживач і користувач використовують подання?
 11

Рисунок 4.5 – Послідовність створення специфікацій вимог в програмному проекті

Проблеми в документах вимог
а) проблеми неадекватного вилучення вимог
1. Передчасний перехід від простору проблеми в простір рішень
Простір проблеми – система очікувань причетних сторін, яка містить:
– можливості, які бажають отримати причетні сторони;
– обмеження, пов’язані з отриманням цих можливостей.
Простір рішень – система властивостей створюваної програмної системи на підтримку можливостей і
обмежень з простору проблеми.
Недостатнє розуміння проблем призводить до того, що:
– не відшукується найкраще вирішення проблем, шляхом порівняння альтернативних вирішень, оскільки
не існує опису проблем;
– складно управляти межами проекту, бо не існує об'єктивних (документально підтверджених) критеріїв
долучення певних функцій до ПС;
– замовник, споживачі та розробники по-різному розуміють призначення ПС; це, зокрема, призводить до
того, що розробники і замовник долучають до ПС непотрібні можливості та неіснуючі на практиці обмеження;
– всі дискусії ведуться стосовно ПС, а не стосовно задач, які необхідно вирішити, а представники
замовника/споживачі/користувачі, можуть бути неготовими або просто не в змозі мислити рамками ПС;
Рекомендації: починати проект з розуміння проблем замовника та споживачів, за можливості, розробляти
формальний документ «вимоги зацікавлених сторін», аналізувати й моделювати ділові процеси замовника та
споживачів.
2. Неохоплені зацікавлені сторони
Рекомендації: розглядати вимоги до ПС у контексті всього життєвого циклу, а не тільки до моменту
впровадження готової ПС у замовника або її випуску на ринок. Тобто необхідно відразу думати про
приймання і сприйняття ПС, її розгортання, підтримку та експлуатацію. Треба враховувати, що ПС, можливо,
буде взаємодіяти з іншими системами, а, отже, ці взаємодії необхідно охопити під час збирання вимог.
3. Постачальник залишає замовника на тривалий час без належної уваги
Рекомендації: Намагатися синхронізувати проект зі швидкістю зміни ділових процесів замовника, щоб в
обмежений час користувачі на боці замовника отримували нові функції ПС, актуальні для їх роботи. Тобто
необхідно за можливості виділяти в проекті фази. Розмір фаз і терміни поставки їх передбачених продуктів
мають відповідати динаміці розвитку бізнесу замовника.
Продовжувати спілкуватися із замовником на всіх рівнях – як від рівня вищого керівництва, на рівні
керівництва проектом, на рівні експертів і аналітиків з обох боків, так і на технічному рівні.
 12
4. Постійна змінність вимог
Рекомендації: запровадити погоджену й документовану процедуру внесення змін до меж і змісту проекту,
яка передбачає перегляд оцінок вартості й термінів робіт, відносно короткі фази, постійне залучення
досвідчених аналітиків.
5. Зацікавлені сторони приховують інформацію, затримують прийняття рішень з питань, за які вони
відповідають.
Рекомендації: залучити представників зацікавлених сторін до команди проекту, оцінити ризики затримки
ними рішень і/або інформації на початку проекту та врахувати їх в оцінках його вартості й термінів
6. Спроби заміни вимог моделями.
Рекомендації: чітко визначити позитивні й негативні наслідки такої заміни, й вдаватися до неї лише
тоді, коли перші безсумнівно переважають другі.
7. Визначення ступеню деталізації вимог: коли зупинитися?
Рекомендації: критерії повноти – рівень вимог та очікування цільової аудиторії.
б) проблеми подання вилучених вимог
1. Терминологическая неопределенность. Часто используются термины, которые обладают
многозначностью, и такие термины не определены в глоссариях, чтобы можно было четко понять, что
конкретно автор имеет в виду в данном случае (это не всегда бывает понятно из контекста). Как пример
можно привести собственно использование (и, что немаловажно, понимания!) термина «требования». Под
этим ёмким термином можно понимать как требования к бизнес процессам, так и функциональные или
нефункциональные требования к ПО вообще.
Во многих англоязычных стандартах прописано использование тех или иных глаголов, форм и
структурирование предложений, описывающих требования – например использование глаголов (will, shall,
should, may, can – перечислены в порядке “убывания директивности”). Действительно, “программный модуль
X отсылает уведомление на e-mail адрес пользователя...” несет, мягко говоря, иную смысловую нагрузку,
чем “отсылается сообщение”.
2. Отсутствие представления о классификации требований. Подмена одних категорий требований
– другими и смешение требований (например, такое часто случается с функциональными требованиями,
бизнес-требованиями и бизнес-правилами). Как результат – создаваемые документы тяжело читать и
извлекать полезную для разработки ПО информацию. Зачастую в одном абзаце, можно встретить
перемешанные как описания необходимой функциональности и тут же элементы предполагаемого
пользовательского интерфейса, который должен воплотить разработчик. Или проектные решения, например,
использование таблиц баз данных или полей. И помимо этого, содержится несистематизированная и
фрагментарная информация о бизнес-процессах организации. Все это скрывает истинные требования к
разрабатываемому ПО, что в свою очередь затрудняет как разработку, так и согласование требований.
Корректная и однозначная интерпретация требований и анализ влияний становятся практически
неосуществимыми, что напрямую сказывается на адекватности удовлетворения потребностей
заказчика/пользователей.
3. Фокусировка на деталях пользовательского интерфейса. В документах встречается
акцентирование не на необходимой функциональности, а на деталях пользовательского интерфейса.
4. Излишнее акцентирование внимания на деталях реализации. Попытка отразить в документе с
требованиями к создаваемому ПО не ЧТО должна делать система, а то КАК она это будет делать. Это одна
из ключевых проблем. Во многом, поэтому, часто выделяют внутренние технические требования к системе,
которые не проходят аттестации со стороны пользователей и разрабатываются не аналитиками, а
архитектором и ведущими разработчиками уже на этапе проектирования – software design (см. следующую
область знаний SWEBOK).
5. Слабая формализация бизнес-процессов. В документах перемешивается описание бизнеса и
требования к ПО, что приводит сложностям в понимании сути и общему пониманию как должна быть
спроектирована система.
4.5.4 Технічні правила оформлення документа специфікації вимог
Ці правила сприяють наданню специфікації вимог 8 властивостей реалізовності й тестопридатності
1. Глоссарий и перечень сокращений и аббревиатур – это важно и хорошо. Но первое упоминание в
тексте должно быть полным. Не нужно при первом удобном случае писать «ТЗ», напишите сначала
«Техническое задание (далее – ТЗ)».
2. Любые используемые сокращения и короткие названия (Система, Заказчик, Исполнитель и т.п.) пишите
 13
единообразно по всем документам проекта: либо все со строчной, либо все с прописной буквы.
3. Формулировки и версии стороннего программного обеспечения (далее – ПО) в разных частях
документа (требования к квалификации персонала, требования к ПО, требования к АРМ-ам) должны быть
идентичными: «MS Internet Explorer версии 8.0 и выше» везде, и никакого «Microsoft IE 8.5″ и тому
подобного.
4. Для англоязычных стандартных элементов интерфейса есть переводы на русский язык, на украинский
язык (напр., Лінгвістичний портал Майкрософт https://www.microsoft.com/ru-ru/language).
5. Тире ≠ дефис! Тире ставится между словами! Дефис ≠ тире. Вокруг дефиса нет пробелов.
6. Формулируйте требования единообразно, без синонимов: «Система должна обеспечивать [нечто]«.
Если используете слово «должно», то забудьте слова «нужно» и «необходимо».
7. Стройте предложения в активном залоге. «Система должна отображать окно ввода данных» вместо
«Должно отображатьСЯ окно ввода данных».
8. Единый перечень стилей по всему комплекту документов. Если Вы маркируете список уровня 1
чёрточками, то не маркируйте его точками.
9. Стандартизированные обозначения единиц измерения.
10. Не следует употреблять кванторы общности: «все», «каждый», «никто», «всегда», «никогда»,
«везде», «нигде» и подобные им слова. Очень вероятно, что такое требование либо невыполнимо, либо
может трактоваться разными способами.
11. Не завершайте перечисления и списки такими слова, как «и т.д.», «и прочие», «и другие». Какие
такие «другие»? Зафиксируйте конкретный перечень. Если считаете, что список может и должен быть
дополнен, то добавьте примечание «Перечень [того-то] может/должен быть дополнен/уточнён на этапе
технического проектирования».
12. Избегайте причастий, не уточняющих требование. Например: «Данные должны передаваться
в согласованном формате». Что это за «согласованный формат»? Когда и кем он согласован? Лучше
написать: «Данные должны передаваться в формате, описанном в пункте N настоящего технического
задания» или другом месте. Если этот формат ещё до конца не известен, то добавьте фразу «Формат
передачи данных должен быть уточнён и согласован сторонами на этапе [ваш этап]«.
13. Без особой необходимости не используйте разные шрифты в документе. Понятно, что куски
программного кода нагляднее оформляются шрифтом Courier New, однако проверяйте, что однотипные
блоки текста оформлены в едином стиле, и схожие абзацы или ячейки таблицы не оформлены и Times New
Roman, и Arial.
Дополнительные рекомендации.
1. Определяться с глоссарием на начальном этапе и доводить этот глоссарий до всех участников
команды разработки, которые будут писать те или иные документы.
2. Давать ссылки на все таблицы, иллюстрации и приложения, которые есть в документе. Они должны
быть привязаны к конкретным местам документа. Помимо наличия ссылок на таблицы и иллюстрации, эти
таблицы и иллюстрации должны быть, как минимум, названы, и, желательно, однотипно.
3. И то, что, возможно, и не так критично, но может выглядеть неопрятно:
– общее форматирование текста: абзацы, отступы, выравнивание (единые для всего документа);
– лишние пробелы между словами;
– лишние переходы на новую строку между абзацами (форматирование текста лучше реализовать с
помощью стандартных средств редактора);
– одинаковые кавычки во всем документе (кавычки под кнопками 2 и Ж – разные);
– после сокращения «тыс.» ставится точка, после сокращений «млн» и «млрд» – нет точки.;
– знак номера № от самого номера (цифры) нужно отделять пробелом, а в вёрстке используется
короткий пробел, т. н. «полукегельная»;
– между цифрами ставится тире без пробелов: 2–3, 20–30. Между датами ставится тире без пробелов:
временной интервал должен выглядеть 1999–2001 гг. (НЕ тире с пробелами).
4.6. Перевірка вимог (Requirements Validation)
Определение требований напрямую связано с процедурами проверки (verification) и утверждения.
Вообще говоря, принято считать, что требования описаны неполно, если для них не заданы правила V&V
(verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения.
Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству,
непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему
требованиям.
Иногда полноценную проверку сути и содержания документов подменяет «нормоконтроль» – проверка
документов требований на соблюдение принятых стандартов внешнего оформления (отступы и размеры
 14
поля, подписи таблиц/рисунков и т.п.), но никак ни оценка качества требований, который совершенно
недостаточен.
Если стандарты жизненного цикла описывают как правильно создавать продукт, то стандарты (в том
числе, внутрикорпоративные) отвечают за создание правильного продукта, то есть того продукта, который
соответствует ожиданиям пользователей и других заинтересованных лиц.
Для достижения этой цели применяется ряд практик, в том числе, представленных ниже.
4.6.1 Огляд вимог (Requirements Review)
Один из распространенных методов проверки требований - инспекция или обзор требований. Суть его
заключается в том, что ряд лиц, вовлеченных в проект (для крупных проектов – специально выделенные
специалисты), “вычитывают” требования в поисках необоснованных предположений, описаний требований,
допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени
детализации, отклонений от принятых стандартов и т.п.
Перспективные практики статического тестирования требований (лише для довідки!):
 Виктория Соковикова. Можно ли протестировать техническое задание за полчаса (https://software-
testing.ru/library/around-testing/requirements/3356-requirements);
 Тріада (https://habr.com/ru/company/tinkoff/blog/449424/);
4.6.2 Прототипування (Prototyping)
В общем случае, прототипирование подразумевает проверку инженерной интерпретации программных
требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора
требований. Существует множество подходов к прототипированию, как с точки зрения детализации, так и
того, чему уделяется внимание при прототипировании. Наиболее часто прототипы создаются для оценки
способа реализации пользовательского интерфейса и проверки архитектурных подходов и решений.
Прототип – это не обязательно нечто, воплощенное в код. Прототипом пользовательского интерфейса
может быть, просто «прорисованный» на бумаге или в электронной форме набор переходов между
экранами/диалоговыми окнами системы (кстати, это подход, часто используемый в Agile-практиках, но
отнюдь не заменяющий требований к системе).
При всей безусловной полезности прототипирования для обеспечения проверки требований и решений,
оно может привести к ряду проблем (див. Проблеми вимог вище):
– смещение внимания с целевых функций прототипа и, как следствие, неудовлетворенность
пользователей огрехами прототипа, отсутствием стоящей за ним реальной функциональности (для
прототипов пользовательского интерфейса), ошибками в прототипе и т.п.
– превращение прототипа в реальную систему за счет постоянного добавления новых свойств и
функциональности «для проверки» – часто бывает нарушена архитектурная целостность, не обеспечена
необходимая масштабируемость и качество получаемого программного продукта;
– переключение внимания заинтересованных лиц на эргономику и детали дизайна графического
пользовательского интерфейса, при начальной цели построения прототипа для выявления функциональных
и иных требований и наоборот. Проблема не во внимании пользовательскому интерфейсу, проблема в
подмене, если так можно выразиться, функциональной составляющей пользовательским интерфейсом
(«задачи» – «кнопочками» и «окошками»).
Выбор метода прототипирования, да и самого факта такого способа проверки требований или
технологических идей, должен основываться на временных и других имеющихся ресурсах, опыте в
прототипировании и степени сложности создаваемой ПС.
4.6.3 Підтвердження моделі предметної галузі і/або ПС (Model Validation)
Утверждение или аттестация модели связана с вопросами обеспечения приемлемого качества продукта.
Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны
пользователей/заказчика. В то же время, проверка и аттестация модели, например, объектно-
ориентированного представления бизнес-сущностей и связей между ними может быть проверена с той или
иной степенью использования формальных методов, например, статического анализа (поиск связей и путей
взаимодействия между описанными объектами и выделение различного рода несоответствий). Это – другая
сторона утверждения модели.
4.6.4 Приймальні тести (Acceptance Tests)
Требования должны быть верифицируемы. Требования, которые не могут быть проверены и аттестованы
(утверждены) – это всего лишь “пожелания”. Именно так они буду восприниматься разработчиками, даже в
случае их высокой значимости для пользователей. Если описанное требование не сопровождается
процедурами проверки – в большинстве случаев говорят о недостаточной детализации или неполном
 15
описании требования и, соответственно, спецификация требований должна быть отправлена на доработку и
если необходимо, должны быть предприняты дополнительные усилия, направленные на сбор требований.
Можно говорить о том, что процедура анализа требований считается выполненной только тогда, когда
все требования, включенные в спецификацию, обладают методами оценки соответствия им создаваемого
программного продукта. Чаще всего столь строгое ограничение на степень законченности спецификации
накладывается на функциональные требования и атрибуты качества (например, время отклика системы).
Идентификация и разработка приемочных тестов для нефункциональных требований часто оказывается
наиболее трудоемкой задачей. Для ее решения обычно “ищут точку опоры”, то есть возможность взгляда на
описываемые требования с количественной точки зрения, в плоть до переформулирования и большей
степени детализации описания таких требований.
Засіб сприяння верифіковності вимог – узгоджене розроблення тестів і плану їх виконання на
заключному етапі складання специфікації вимог відповідного рівня за конструктивної взаємодії бізнес-
аналітика, тестувальника й менеджера.
4.6.5 Трасування вимог (Requirements Tracing)
Трассировка требований обеспечивает связь между требованиями и отслеживание источников
требований. Трассировка является фундаментальной основой проведения анализа влияния (impact analysis)
при изменении требований, помогая предсказывать эффект от внесения таких изменений. Трассировка
предполагает направленную связь (представляется в виде сложного направленного ациклического графа)
между требованиями, то есть зависимости.
Требования (B) обладают обратной зависимостью (то есть вторичны) по отношению к требованиям (A) и
заинтересованным лицам, которые являются источником либо образуют причину появления
рассматриваемых требований (B). И, наоборот, требования (A) трассируются напрямую к тем требованиям
(B) и элементам дизайна (например, модели или, в общем случае, кода, запросов на изменения и т.п.),
которые порождаются или удовлетворяют требованиям (A).
Для трасування вимог в передбачено матрицю вимог із зазначенням їх азпємозв’язків між собю, з
модулями коду та тестами.
4.6.6 Вимірювання вимог (Measuring Requirements)
С практической точки зрения, обычно полезно иметь нечто, позволяющее определить «объем»
требований для заданного (создаваемого) программного продукта. Это число полезно для исследования
“масштабов” изменений в требованиях, оценки стоимостных характеристик (cost estimation) разработки и
поддержки программной системы, опосредовано – оценки продуктивности разработки и эффективности
поддержки на этапах реализации требований и внесения изменений и т.п.
Измерение функционального размера (Functional Size Measurement. FSM) – это техники такого рода
численной оценки. Стандарты ISO/IEC и другие источники описывают частные техники FSM (например,
метод Альбрехта и модель COCOMO II для оценки стоимости реализации требований определенного
размера (див. Л13_24_11_2022_Економіка_ПІ.pdf).
В дополнение к практическим соображениям, представленным в SWEBOK, на фоне общей тенденции
разработки моделей <оценки> зрелости, стоит отметить, что существуют определенные работы и по
созданию различных моделей зрелости требований. Например, наиболее популярная модель зрелости в
индустрии программного обеспечения – CMMI включает разный объем и содержание работ по определению
и управлению требованиями для уровней зрелости начиная со второго.
4.7 Показові приклади налаштування рамкового процесу інженерії вимог
4.7.1 Для замовного програмного продукту та для продукту ринкового призначення
Див. матеріалі Ю.Хімоніна (Software_Requirements_Khimonin.pdf).
4.7.2 Для методології RUP (Маглинець_IT.pdf)
Лекція 5_29_09_2022 – Інженерія вимог до програмних засобів, створюваних за гнучкою
методологією
Корисні ресурси
Портал щодо SCRUM сайту AgileUkraine: http://scrum.com.ua/category/books/
Сайт М.Кона (Мike Кohn): http://www.mountaingoatsoftware.com/
Cайт і блог Д.Лефінгвелла «Scaling Software Agility»: http://deanleffingwell.com/,
http://scalingsoftwareagilityblog.com/
Сайт Дж.Паттона (Jeff Patton): http://www.agileproductdesign.com/index.html
Блог Скотта Амблера Agile Requirements Best Practices – http://www.agilemodeling.com/
Додатково
Сайт консультативної компанії «Industrial Logic» щодо ощадливих і гнучких методів індустрії
програмного забезпечення: https://www.industriallogic.com/
Посібники
Вольфсон_ГУПП.pdf
2020-Scrum-Guide-Ukrainian.pdf, 2020-Scrum-Guide-US.pdf
Кон М. Оцінювання і планування в Agile / М.Кон – Фабула,2019. – 356 с. (Agile Estimating and
Planning,
Кон_ ОПЛпроектов_2018.pdf)
Кон М. Пользовательские истории: гибкая разработка программного обеспечения» - Вильямс, 2012 -
256 с. (Кон_Польз_истории_2012.pdf)
Піхлер Р. Agile продукт-менеджмент за допомогою Scrum / Р.Піхлер – Фабула,2019. – 356 с.
(Пихлер_Упр_продуктом_Scrum2017.pdf )
5.1 Подання вимог до програмного продукту в гнучких методологіях
Вміст рамкових документів «Потреби причетних сторін» (StRS) і «Системні вимоги» (SyRS),
передбачених ISO/IEC/IEEEE 29148 (див. Л4_22_09_2022_Вимоги.pdf), а саме категорії
споживачів/замовників та їх найважливіших проблем й очікувань, для опрацювання яких
створюють програмний продукт (ПП), у гнучкому програмному проекті подають:
1) обов’язковий документ Product Vision;
2) необов’язкова бізнес-модель ПП.
Рамковий вміст, структуру, вимоги й техніки розроблення Product Vision окреслено в
Пихлер_Упр_продуктом_Scrum2017.pdf, розд.2. Для побудови бізнес-моделей наразі застосовують
графічні патерни, складені змістовними блоками різного розміру згідно з їх значущістю і тому звані
полотнами, або канвасами (canvaces, напр., https://www.industriallogic.com/canvases/).
Перспективними полотнами для бізнес-моделі ПП в гнучкому програмному проекті є:
 універсальний матричний шаблон полотна бізнес-моделі О.Остервальдера, І.Пін’є
(БМ_Остервальдер.pdf – лише для довідки);
 ощадливі полотна (Lean Canvas) Еша Маурья.
Шаблон Остервальдера-Пін’є передбачає чотири напрями опису ПП (рис. 5.1):
1) Споживачі (Клієнти) з блоками:
 цільові групи споживачів,
 канали просування;
 технології клієнтських відносин;
2) Ціннісна пропозиція;
3) Інфраструктура з блоками: ключові партнери, процеси, ресурси;
4) формула прибутку з блоками: структура витрат; потоки прибутку.
Саме наявність виділеного напряму «Споживачі (Клієнти)» є головною перевагою цього полотна
для виконання завдань організації-розробника з управління очікуваннями причетних сторін.
Роль Специфікації вимог до ПЗ (SRS) відіграють:
 Журнал продукту, або Беклог (Backlog) (Пихлер_Упр_продуктом_Scrum2017.pdf, розд.3);
 Журнал спринту (Sprint Backlog);
 Визначення виконаної роботи (Definition of Done, DoD).
Беклог продукту складений бізнес-вимогами, зазвичай оформленими у вигляді так званих історій
користувача (user story, Кон_Польз_истории_2012.pdf, розд.1; ), які можуть бути дуже складними й не
мати оцінок розміру та пріоритету реалізації, а також нефункціональними вимогами у форматі обмежень
(формулювання; критерій прийнятності).
 2
3.Інфраструктура 1.Споживачі

2.

4.Формула прибутку
Рисунок 5.1 – Структура базового й канвы бизнес-модели
Натомість, елементами Беклогу спринту є історії користувача (user story) з властивостями INVEST
(розглянутими в наступному підрозділі 5.2.), визначеними розмірами й пріоритетами реалізації, а також
уточнені командою DoD.
5.2 Сутність і властивості історій користувача
Історія користувача має чотири де-факто обов’язкові атрибути:
1) унікальний числовий ідентифікатор – зазвичай збігається з ідентифікатором історії в системі
контролю версій, якою користується команда;
2) назву історії – стислий (приблизно до 10 слів) опис функціоналу з погляду користувача,
сформульований у вигляді трійки «Роль», «Дія», «Мета» (Кон_Польз_истории_2012.pdf, розд.2):
AS < define user > I WANT < descibe experience > SO THAT < describe benefit >
«Як <користувачу(роль)>, мені треба <дія>, щоб <причина (бізнес-цінність, ціль) >» (1)
Напр.: «Користувач вводить логін і пароль, щоб авторизуватися на сайті».
Якщо причина не очевидна (напр., «Як вегетаріанцю, мені потрібно фільтрувати результати пошуку,
щоб переглядати лише вегетаріанські страви»), при створенні опису функціональності для користувача
команді слід переконатися, що вона надає цінність для клієнта, узгоджено відповівши принаймні на
питання:
 ким є користувач;
 що потрібно робити користувачу;
 навіщо користувачу це робити.
Прикладом застосування такого прийому є назва «Як представнику служби підтримки клієнтів, мені
треба звертатися до даних клієнтів, щоб я міг швидше відповідати на їх питання». Крім того, описи
функціональності користувачів слід визначати так, щоб їх реалізовувати можна було в довільному
порядку;
3) важливість, або пріоритет – унікальний числовий пріоритет історії, чим він вищий, тим раніше цю
історію необхідно реалізувати;
4) оцінку – кількісну відносну оцінку обсягу історії користувача за спеціальною шкалою (в
спеціальних безрозмірних одиницях – сторипоінтах, ідеальних днях чи, рідше, годинах).
Атрибути 1)-4) зручно розміщувати на стікері, прикріпленному на дошку.
Напр., історію користувача для авторизації на сайті з оцінкою в 10 сторипоінтів, важливістю 200 та
номером у трекері 1453, можна подати на стікері:

Крім де-факто обов'язкових атрибутів 1)-4) досить часто застосовують і чотири додаткові атрибути
історії, які можна відстежувати в трекері:
 3
5) детальний опис – текстовий і, можливо, графічний опис історії, який застосовують насамперед у
розподілених командах для збереження знань щодо функціоналу ПП;
6) демонстрацію – достатньо докладний сценарій, що дозволяє тестування та підтвердження
досягнутої коректності виконання коду для історії користувача. Напр., для вищенаведеної історії
користувача з авторизацією можна використати такі сценарії для демонстрації:
1) користувач вводить логін "root" і пароль "pass", переходить на сторінку особистого профілю на
сайті;
2) користувач вводить логін "root" і пароль "wrongpass", отримує повідомлення "Введено
неправильний логін або пароль";
7) критерії приймання (acceptance criteria) та приймальні тести, для вироблення яких застосовують
спеціальні кращі практики цілеспрямованої комунікації:
а) Story Kick Off Huddles («Купки для розкриття історії користувача»), або Тріада, за участі бізнес-
аналітика, програмістів, тестувальника (тріада.pdf – лише для довідки);
б) Example Mapping, або складання карт тестових випадків (https://habr.com/ru/company/oleg-
bunin/blog/450844/ – лише для довідки);
8) категорію – її застосовують для підвищення керованості за допомогою категоризації завдань.
Припустимі як продуктні категорії («теми» й «епіки», розглянуті в наступному підрозділі 5.3), так і
нефункціональні категорії типу «оптимізація продуктивності», «технічна історія».
Для виявлення ролей користувачів, які потребують функціоналу (Кон_Польз_истории_2012.pdf,
розд.3), корисні три підходи (https://dou.ua/lenta/articles/techniques-for-developing-requirements-1/):
1) посадовий – виділення ролей з урахуванням посадових обов'язків.
2) функціональний — виділення ролей з урахуванням функціональних завдань.
3) гібридний – поєднання посадового й функціонального підходів.
Білл Вейк (Bill Wake, автор https://www.industriallogic.com/) запропонував абревіатуру INVEST для
опису властивостей «хорошої», тобто придатної для ефективної реалізації та тестування, історії
користувача (INVEST_Wake.pdf):
Independent (Незалежна)
Negotiable (Обговорювана)
Valuable (Цінна, або Корисна)
Estimable (Придатна для оцінювання, або Естимована)
Small (Мала,або Компактна)
Testable (Тестована).
Сутність властивостей INVEST описано далі.
1. Незалежна
Незалежність означає, що історію можна раалізувати, від тестувати та, можливо, навіть доставити
споживачам саму по собі. Через це вона може надавати незалежну цінність
2. Обговорювана
На відміну від подання вимог у традиційній SRS, історія користувача не є остаточною угодою щодо
певної функціональності, а скоріше форматом для таких вимог, які ще мають бути обговорені,
реалізовані, відтестовані та прийняті. Цей процес обговорення між бізнесом та командою адекватно
відображає правомірність та першочерговість інформації від бізнесу, але також і залучає до
дослідження через співпрацю та фідбек .з комунікацією, зокрема практиками а), б) щодо критеріїв
приймання.
Обговорюваність історій користувача дозволяє командам досягти передбачуваності. Відсутність
надмірно обмежуючих і надто деталізованих вимог удосконалює здатність команди й бізнесу знаходити
компроміси між обсягом функціональності та датою доставки. Оскільки кожна історія припускає певну
гнучкість, у команди теж виникає більше гнучкості у виконанні цілей релізу, що збільшує надійність та
посилює довіру.
3. Цінна (Корисна)
Ціль команди гнучкого проекту – доставити максимальну користь у межах доступного часу та
ресурсів. Тому кожна історія користувача має надавати користувачу, замовнику або стейкхолдеру певну
користь (іноді звану цінністю), яка є найважливішим атрибутом в INVEST-моделі. Пріоритети в беклогах
виставляють на підставі користі історій, і весь бізнес переживає чи зазнає успіх краху залежно від
користі, яку команда здатна доставити.
Команда має створювати історії, які «прорізають» архітектуру наскрізь, щоб надати цінність
користувачеві і розраховувати на зворотний зв’язок із ним настільки рано і часто, наскільки це можливо.
 4
4. Придатна для оцінювання, або Естимована
Опис функціональності в історії деталізований рівно настільки, щоб можна було описати та оцінити
трудовитрати, необхідні для його реалізації.
Перед включенням до спринту описи функціональності користувачів оцінюють у балах. Бали є
навмисно приблизними оцінками, що використовуються головним чином для управління списком
невиконаних робіт і для підготовки до спринту. Після початку спринту команда розбиває опис
функціональності на завдання, необхідні його реалізації. На зборах з обліку невиконаної роботи з
продукту команда працює з власником продукту, щоб визначити, з яких описів необхідна додаткова
інформація, перш ніж їх можна буде розбити на завдання для оцінки трудовитрат. Власник продукту
може зібрати ці відомості та записати їх в опис функціональності.
5. Мала,або Компактна
Обсяг опису функціональності має дозволяти реалізувати його протягом спринту.
Опис функціональності користувачів має бути досить невеликим, щоб команда могла завершити їх
реалізацію протягом спринту. Власник продукту разом із командою працює над розбиттям надто
великих описів на дрібніші, використовуючи патерни їх розбиття (User Story Splitting Patterns).
Напр., опис «Як представнику служби підтримки клієнтів, мені потрібно звертатися до даних клієнтів,
щоб я міг швидше відповідати на запитання клієнтів» доцільно розбити на дрібніші описи, напр., «як
представнику служби підтримки клієнтів, мені потрібно знаходити ім'я клієнта та результати останнього
дзвінка за номером клієнта»; «як представнику служби підтримки клієнтів, мені потрібно звертатися до
повного журналу дзвінків клієнта, щоб я міг детально розібратися в поточній проблемі».
Корисний набір патернів розбиття надано Р.Лоренцем (Richard Lawrence, табл.5.1).
Однак необхідно не допускати долучення до історії непотрібних подробиць, оскільки надмірна
деталізація може негативно вплинути на обговорення, створюючи оманливе враження точності і Опис
функціональності користувача має бути підставою для розмов та обговорень з власником продукту та
клієнтом, які продовжуються, доки опис не буде повністю реалізовано та прийнято.
6. Тестована
Умови приймання мають бути визначені.
Наприкінці спринту клієнти або власник продукту або приймають опис функціональності користувача
як завершений (цілком реалізований), або відхиляють його. Перед початком спринту необхідно якомога
чіткіше визначити умови приймання клієнтом. Звичайно, опис функціональності може бути прийнятий з
причин, яких ніхто не передбачав. Проте розмови команди з клієнтами допомагають визначити умови
приймання, що сприяє розумінню командою очікувань клієнтів. Умови приймання можна
використовувати як основу для приймальних тестів; це дозволяє ефективніше оцінити повноту
реалізації опису функціональності.
Таблиця 5.1 – Десять патернів розбиття історії користувача за Річардом Лоренцем
1. По последовательностям действий. Определить конкретные шаги, выполняемые
пользователем в рамках последовательности, и тогда реализовать последовательность поэтапно.
...Я могу публиковать тарифные планы на
домашний дисплей
Как энергокомпания я хочу изменять и ...Я могу послать сообщение на Интернет-
публиковать тарифные планы потребителю портал потребителя
...Я могу опубликовать таблицу тарифов на
смарт-термостате потребителя
2. По вариации бизнес правил. На первый взгляд некоторые стори выглядят достаточно просто.
Однако, иногда бизнес-правила более сложны и обширны, чем это может показаться. В таком случае
оказывается полезным разбивать пользовательскую историю на несколько стори, контролируя таким
образом сложность бизнес-правил.
...упорядочивать по почтовому индексу
Как энергокомпания я могу упорядочивать ...упорядочивать по домашней демографии
потребителей по демографическому признаку ...упорядочивать по уровню потребления
энергии
3. По основным трудозатратам. Иногда пользовательская история может быть разбита на
несколько частей, где большая часть трудозатрат попадет в первую стори. В примере приведенном
ниже должна быть построена соответствующая инфраструктура, чтобы реализовать первую стори;
однако, последующее добавление функциональности должно быть довольно тривиальным.
 5
Как пользователь я хочу иметь возможность ...Я хочу использовать Временной тариф [12]
выбрать/изменить мой тарифный план с помощью ...Я хочу использовать Предоплатный тариф
энергокомпании через Интернет-портал ...Я хочу подписаться на Пиковый тариф [13]
4. По простоте / сложности. Когда команда обсуждает пользовательскую историю и она, кажется,
становится все объемней и объемней (“А как насчет x? А думали ли вы об y?”), следует остановиться и
спросить себя “какой наипростейший вариант мог бы сработать?” Зафиксируйте эту простейшую
версию в качестве первой стори, и тогда уже сможете разбить все вариации и сложные детали в
отдельные пользовательские истории.
Как пользователь, я в целом хочу ...реагировать на время и продолжительность
фиксированный тариф, но хотел бы быть в курсе пиковых цен
изменения пиковых цен. ...реагировать на непредвиденные изменения
5. По вариациям данных. Вариации данных и источников данных являются другой причиной
дополнительных трудозатрат и сложности. Попробуйте добавлять стори по ходу дела после того, как
построена простейшая версия. Вот пример локализации приложения:
...на английском
Как энергокомпания я могу отсылать сообщения
...испанском
потребителям
...арабском и т. д.
6. По методам ввода данных. Иногда сложность состоит не столько в самой функциональности,
сколько в пользовательском интерфейсе. В таком случае разбейте стори так, чтобы построить вначале
наипростейший интерфейс, а более сложный построится позже.
...используя гистограммы по однонедельным
промежуткам
Как пользователь я могу просматривать мой
...на сравнительном графике, так что я мог бы
уровень потребления на разных графиках
сравнить мое потребление с потреблением других
семей с такой же демографией
7. Отсрочка качеств системы. Иногда первоначальная реализация не так уж и трудна, а большая
часть трудозатрат уйдет на то, чтобы сделать ее быстрой, или более надежной, или более точной, или
более масштабируемой. Однако, команда может много почерпнуть из базовой реализации и она
должна все же представлять собой определенную ценность для пользователей, которые в противном
случае не могли бы использовать систему вовсе. В этом случае разбейте стори на все последующие
“...ости”.
...интерполировать данные из последней
Как пользователь я хочу видеть потребление на вычитки данных
моем счетчике в реальном времени ...показать настоящие данные счетчика в
реальном времени
8. По операциям (пример: CRUD). Слова наподобие “управлять” или “контролировать” - дань
дополнительной вместимости стори для множества составных операций. С другой стороны они
подсказывают естественное разбиение стори на части.
...Я могу создать учетную запись
...Я могу редактировать установки учетной
Как пользователь я могу управлять своей записи
учетной записью ...Я могу приостановить учетную запись
...Я могу добавить больше бытовых приборов к
моей учетной записи
9. По сценариям использования. Если сценарии разрабатывались для представления сложных
взаимодействий вида “пользователь-система” или “система-система”, то стори часто можно разделить
соответственно отдельным под-сценариям.
 6
Сценарий / Стори №1 (оптимистичный
сценарий): Сообщить энергокомпании, что у
пользователя есть оборудование
Я хочу подписаться на программу Сценарий / Стори №2: Энергокомпания
энергосбережения через розничного обеспечивает оборудование и данные и
дистрибьютора. уведомляет потребителя.
Сценарий / Стори №3 (альтернативный
сценарий): Обработать ошибки при валидации
данных.
10. Запустить спайк. В некоторых случаях пользовательская история может быть слишком большой
или сложной, или возможно реализация плохо понята. В таком случае нужно проделать технический
или функциональный спайк, чтобы внести ясность; потом разбить стори на основании результатов
(более подробно о спайках в следующей части).
Описи функціональності з властивостями INVEST, зокрема цінні (V) й незалежні (I), утворюють
список невиконаних робіт за ПП. Їх оцінюють і призначають пріоритети, після чого команда починає
реалізуватим описи функціональності з найвищим пріоритетом. Власник продукту працює над тим, щоб
описи функціональності з найвищим пріоритетом мали властивості INVEST, перш ніж вони будуть
винесені на зустріч з планування спринту.
5.3 Спеціальні категорії історій користувача
Епопеї (epics), теми (themes), піки (спайки, spikes)
Властивості INVEST мають бути притаманні історіям, готовим до реалізації.
В то же время истории с меньшим приоритетом могут быть более объемными – их называют
эпопеи (эпики, epics) и темы (themes) (Кон_Польз_истории_2012.pdf, розд.2,4).
Епопеї – це дуже великі описи функціональності у форматі історії користувача, які являють собою
значні обсяги робіт.
Під час розбиття епопеї можна створити множину тем та інших дрібніших описів функціональності.
Теми – це досить великі описи функціональності, зазвичай обсягу більшого, ніж можна реалізувати в
спринті, що являють собою набір взаємопов'язаних історій користувача.
Cразу разбивать их на более мелкие нецелесообразно во избежание чрезмерного разрастания
списка невыполненных работ. Разбивать описания функциональности на более мелкие следует
методом набегающей волны: по мере их приближения к верху упорядоченного по приоритетам
списка невыполненных работ.
При ранжировании списка невыполненных работ разбивают эпопеи и темы, находящиеся в верхней
части списка, и назначают приоритеты новым, более мелким описаниям. По завершении ранжирования
описания функциональности с наивысшим приоритетом должны быть достаточно небольшими, чтобы
их можно было реализовать. Ниже в ранжированном списке можно найти гораздо больше подробных
пользовательских описаний функциональности.
Для розбиття доцільно застосувати 10 патернів Р.Лоренца (табл.5.1), патерни Б.Вейка
(https://www.industriallogic.com/).
Пики – это работы, не направленные непосредственно на реализацию описания функциональности
пользователя, которые команде иногда приходится выполнять.
Три распространенных типа пиков – исследование, задолженность по ошибкам, улучшение
процесса или инженерное улучшение.
Исследование проводят при наличии открытых вопросов по описанию функциональности
пользователя, на которые необходимо получить ответ перед полным разбиением описания на задачи и
его оценкой. Например, на собрании по планированию спринта команда рассматривает описание
функциональности «Как часто летающий пассажир, я могу бронировать призовые билеты». После
обсуждения этого описания остается больше вопросов, чем ответов. Команда создает описание
функциональности, представляющее собой пик. «Как члену команды, мне нужно понять, что означает
выражение «бронировать призовые билеты», чтобы я мог писать описания для включения в будущие
спринты». Команда определяет, сколько часов можно посвятить этому исследованию, и записывает это
количество в качестве временных рамок пика. Ни одно из описаний, написанных в ходе пика, не может
реализоваться в течение той же итерации. Эту работу необходимо запланировать на одну из будущих
итераций с помощью списка невыполненных работ по продукту.
Задолженность по ошибкам – для работ по исправлению ошибки, лучше всего непосредственно
 7
тогда, когда она найдена. Если не удается устранить ошибку в тот же день, когда она была найдена,
один из участников команды должен создать рабочий элемент ошибки, чтобы не потерять ее из вида.
Следите за тем, чтобы ошибки не накапливались. Если у команды накапливаются ошибки, создайте
описание функциональности пользователя и свяжите ошибки с пиком, чтобы его можно было оценить и
назначить ему приоритет вместе с остальными описаниями функциональности и пиками.
Команда может предпринимать действия по улучшению процесса или внесению инженерных
улучшений, призванных помочь ей в достижении успеха. Необходимость в улучшениях часто
выявляется на ретроспективном собрании по спринту и на ежедневных Scrum-собраниях. Например,
команде может понадобиться улучшить покрытие кода модульными тестами или снизить время
построения на сервере непрерывной интеграции.
5.4 Техніки виявлення, документування та оцінювання пріоритетів історій користувача
Для виявлення та документування історій користувача (яке зазвичай починає Власник продукту й
узгоджує атрибути історії з командою) застосовують техніки (див. Вольфсон_ГУПП.pdf,
Кон_Польз_истории_2012.pdf, розд.2,4,12-15):
– побудови бізнес–моделі;
– аналізу персон (personas) (https://www.reveall.co/guides/));
– виявлення причетних сторін (Кон_Польз_истории_2012.pdf, розд.5);
– аналізу впливів (impact mapping) Г.Аджіча (Gojko Adzic, https://gojko.net/);
– візуалізації змісту історій (storymapping);
– «подорожі споживача» (customer jorney map).
Підхід Іmpact mapping (Impact-mapping.pdf) передбачає 4-етапний процес побудови спеціальної
ментальної карти (mind map), термінальні елементи якої надають достатньо підстав для складання й
узгодження повного набору INVEST-історій користувача навіть у гнучкому програмному проекті
створення ПП ринкового призначення, коли быльш ьрадицыйны техныки вилучення вимог в
комуныкації з причетними сторонами незастосовні.
Storymapping (https://dou.ua/lenta/articles/techniques-for-developing-requirements-1/) – это аналог
Іmpact mapping, только со стороны пользователей. Берутся уже существующие персоны, из которых
выбираются самые важные, согласно Impact mapping, описывается высокоуровневый функционал для
каждой из них. Затем описывается минимально необходимый набор атрибутов фичи, который позволит
сделать продукт ценным для персоны. Его дополняют вариантами развития, какие только придут в
голову за ограниченное время. Цель: определить функции для первого релиза, он же – минимально
ценный продукт.
В customer jorney map (Guide_ Cust_J_Mapping.pdf; https://www.reveall.co/guides/) для всех
важных персон, выявленных ранее, проектируется черновой вариант навигации пользователя в
продукте. Для каждого шага описывается контекст, в котором пользователь пришел сюда. Оценивают
его ощущения от продукта и мотивацию дальнейшей работы с продуктом. Цель: понять, какая
функциональность и интерфейс мотивирует пользователя продолжать общение с продуктом, а что
может заставить его уйти.
Базовими підходами до встановлення пріоритетів вилучених історій (виконуваного Власником
продукту) є (Вольфсон_ГУПП.pdf; vigers.pdf, розд. 20):
1) декомпозиція найважливіших епіків і тем на INVEST-історії (безпосередньо або через задачі з
властивостями SMART), які можна реалізувати впродовж спринту з використанням патернів розбиття,
зокрема з табл.5.1. Абревіатура SMART означає:
– конкретність (Specific);
– вимірність (Measurable), тобто наявність метрик ступеня досягнення в певних кількісних шкалах;
– досяжність (Attainable);
– доцільність (Relevant), тобто відповідність умовам виконання проекту й узгодженість між собою,
та забезпеченість ресурсами (Resource-bound);
– наявність терміну досягнення (Time-bound);
2) упорядкування INVEST-історій за значущістю для користувача за процедурою Норіакі Кано
(Вольфсон_ГУПП.pdf, с.22-24);
3) встановлення рейтингів за схемою Д.Лефінгвелла на підставі трьох чинників, яким зіставлено
бальну шкалу від 1 до 9:
– незалежної цінності для користувача, оцінюваної Власником продукту безпосередньо або за
процедурою Н.Кано;
– цінності для досягнення цілей поточної ітерації;
 8
– скорочення ризику недосягненя цілей спринту і/або проекту,
шляхом їх підсумовування з вагами, відповідними відносній значущості цих чинників (рис.5.2).
Ця процедура є спрощеним аналогом процедури К.Вігерса впорядкування функціональних вимог на
підставі вартості, цінності й ризику нереалізовності (Л4_22_09_2022_Вимоги.pdf).

Рисунок 5.2 – Результат підсумовування оцінок трьох чинників за процедурою Д.Лефінгвелла

Формулювання назв і/або детальних описів складних великих історій часто призводить до проблем:
– невдалих спроб подати в форматі історії користувача (1) всі знання про продукт, навіть якщо вони
явно йому невідповідні;
– відсутності розуміня, як заповнювати позиції формату (1) («незрозуміло, що включати»);
– визначення доцільного рівня деталізації: якщо узагальнити – втрачається контроль, якщо
деталізувати – неприйнятна трудомісткість підтримки;
– частих змін назв і/або детальних описів через комунікаційні прогалини;
– відсутність де-факто стандартизованого опису;
– втрати фокусу в дискусіях.
Для запобігання цим проблемам під час документування складної історії доцільно застосувати
спеціальне Полотно історії користувача (User Story Canvas, рис.5.3), інструмент, який мотивує
узгодити з Власником продукту підтвердити більше аспектів, ніж просто «критерії прийняття».
 9

Рисунок 5.3 – Структура Полотна історії користувача

Для заповнення полотна історії користувача необхідні послідовні кроки під час обговорення історії,
згруповані в п’ять блоків:
1) блок комунікацій: перші чотири кроки. Команда погоджує категорію кінцевого користувача – чим
вона конкретніша, тим більш сфокусованим буде подальше обговорення. Далі Власник продукту та
команда ідентифікують конкретних експертів бізнес-домену, які зможуть надавати розробникам
необхідну додаткову інформацію вже під час розробки. Також вписують конкретні імена замовників та
інших зацікавлених сторін. Команда має чітко й узгоджено усвідомити, з з яких питаннях і з ким доцільно
спілкуватися для уточнення їх вимог. Таким чином, Власник продукту не стане вузьким місцем під час
реалізації складних історій. Аналіз блоку комунікацій дозволить власнику продукту визначити можливих
учасників для зустрічі з огляду спринту, планувати наперед та підтверджувати участь причетних сторін
на цій зустрічі;
2) блоку контексту: п’ятий і шостий крок.. Команда спілкується з Власником продукту, щоб
зрозуміти й визначити потреби користувача та контекст потенційного використання нових
функціональних можливостей. Члени команди погоджують і записують,, що не влаштовує персону в її
користувацькому досвіді, щоб надалі свідомо працювати над покращеням.
3) блок користувацької історії: сьомий, восьмий і дев’ятий кроки. Здійснюється перехід від
проблеми до її вирішення. Зрозумілий контекст допоможе сформулювати саме ту історію, яка матиме
позитивний вплив на кінцевого користувача. Крім того, цей досвід слід описати у вигляді кількох
можливих рішень з їх плюсами й мінусами: «дешево й сердито» або «дорого й багато». У кінці цього
блоку важливо задокументувати «критерії прийняття».
4) блок реалізації: десятий, одинадцятий і дванадцятий кроки. Додаються технічні знання про ПП.
Потрібно обговорити і задокументувати технічні обмеження з точки зору архітектури, програмних
інтерфейсів для інтеграції, підтримувані технології та зберігання даних. Важливо відзначити, що всі ці
обмеження будуть впливати на виконання нових функціональних можливостей, швидкість реалізації,
тощо. Далі потрібно вказати залежності від третіх систем, які також мають бути змінені та, дуже
важливо, як треба змінити існуючі схеми даних, які джерела даних будуть необхідні, чи ці дані вже
доступні?
 10
5) блок очікуваних результатів: останні два кроки. Члени команди домовляються про обробку й
інтерпретацію зворотного зв’язку від користувачів. Вважають, що історія успішно реалізована, якщо
відповідає критеріям прийняття від Власника продукту. Але це не зовсім так: історія тому є
«користувацькою», що збирати зворотний зв’язок потрібно від користувачів. Команда має розуміти, як
збирати інформацію про використання продукту. Можливо, розробникам варто інтегрувати реалізовану
історію з Google Analytics або розробити власний механізм для відстеження реального використання
нових функціональних можливостей.
Великі, але не складні історії варто починати одразу з шаблонів розбиття (зокрема з табл..5.1).
Якщо реалізація історії не об’ємна, але складна і заплутана в обмеженнях і залежностях, у полотні
історії користувача доцільно частково заповнювати тільки ті блоки, про які важливо домовитись і
задокументувати.
Зрозумілі й не великі за розмірами історії не потребують комплексного інструменту для обговорення.
5.5 Вимірювання вимог: визначення та використання розміру історії користувача
У гнучких методологіях для оцінювання розміру функцій, які мають бути реалізовані в програмному
продукті, передбачено три одиниці виміру:
 сторипоінт, або бал історії (Story Point) (Кон_ОПЛпроектов_2018.pdf, розд.4, с.36-41;
Кон_Польз_истории_2012.pdf, c.93-100);
 ідеальний день (Ideal day) (Кон_ ОПЛпроектов_2018.pdf, розд.5, с.42-45);
 ідеальна година (Ideal hour), використовна рідше,
які застосовують до вимог, поданих переліком історій користувача з властивостями INVEST в
журналі продукту.
Сторипоінт – відносно безрозмірна інтегральна складність такої історії користувача, яка:
1) типова для проекту;
2) вважається всіма членами команди найпростішою в поточному беклогу.
За своєю призначеністю ці одиниці виміру є аналогами умовних одиниць функціональності, Веб-
об’єктів і Веб-пунктів, пунктів варіантів використання (див. Л13_24_11_2022_Економіка_ПІ.pdf), які
застосовують у планових та ітеративних методологіях до вимог, поданих описом природною мовою в
документі специфікації вимог і/або системою уніфікованих описів варіантів використання й
відповідними UML-діаграмами,
Для оцінки ефективності команди застосовують показник «(командна) швидкість» (vrlocity), яку
вимірюють у зазначених одиницях (Кон_ ОПЛпроектов_2018.pdf, розд.4, 5, с.36-45). Вона є аналогом
поняття трудомісткості у планових та ітеративних методологіях.
Рамкові процедури визначення розміру історії користувача (Кон_ ОПЛпроектов_2018.pdf, розд. 6,
с. 46-54; Кон_Польз_истории_2012.pdf, розд.8, c.93-100; Agile-Estimating-Planning.pdf):
1) експертне оцінювання;
2) оцінювання за аналогами;
3) декомпозиція історії;
4) традиційне Покер-планування (Planning Poker, https://www.planningpoker.com/) та його спрощення
С.Бокманом.
1. Традиційна процедура Покер-планування (Вольфсон_ГУПП.pdf, с.34-40).
Planning Poker – процедура визначення розміру історій користувача як їх складності в
сторипоінтах
Базові правила Planning Poker:
1) учасники – безпосередні виконавці історій користувача. Зокрема, власник продукту не грає, якщо
не створює/тестує код;
2) для оцінювання застосовується послідовність чисел Фібоначчі: 1, 2, 3,5, 8, 13, 21; або
логаріфмічна шкала1, 2, 3,5, 8, 13, 20; 40; 100 (останні два числа – для епіків і тем, занадто великих для
реалізації в спринті). Цифри фіксуються на спеціальних картах, які надають учасникам;
3) раунд – послідовність чотирьох дій:
 Замовник/Власник Продукту читає історію, а команда стисло уточнює її;
 кожний учасник вибирає свою оцінку й кладе карту цифрою догнизу;
 всі одночасно відкривають карти;
 якщо є розбіжності, визнані істотними, в обговорені виявляються й обґрунтовуються їх причини.
 11
Раунди повторюють, поки не буде досягнуто прийнятної близькості оцінок або виявлено істотні
причини розбіжностей для їх опрацювання скрам-майстром, Власником продукту і/або вищим
керівництвом.
2. Спрощена процедура С. Бокмана визначення розміру історій користувача
Підготовка: Роздрукуйте або напишіть від руки картки з Історіями Користувача (або Вимогами), які
ви збираєтеся оцінювати. Достатньо написати код у вашій системі зберігання вимог і короткий заголовок
або навіть скорочену назву, яка всі можуть пригадати.
Хід гри: кожний гравець може зробити такі дії:
1. Узяти картку зверху стопки і покласти її десь на столі щодо інших карток.
Прийняті домовленості: зліва – це простіше, справа – складніше, знизу – наявної картки – такого ж
розміру.
2. Посунути одну з лежачих на столі карток, пояснюючи чому він не згоден
3. Пропустити хід.
Гра закінчується, коли в стопці не залишилося більше карток і коли жоден з гравців не хоче посунути
наявні картки (тобто кожний вже пропускає хід).
Дуже важливо спілкуватися під час гри і пояснювати, чому гравець зробив той або інший вибір. Все-
таки наша ціль – дати сумісні командні оцінки, ця гра не ради виграшу одного учасника .
Після того, як ви отримали на столі лінію карток від простих до складних, вам залишається тільки
підставити шкалу. Можна використовувати:
 числа від 1 до 10;
 логарифмічну шкалу;
 шкалу Фібоначчі (1,2,3,5,8,13), яка, як відомо, швидко росте вгору і тим самим позбавляє від
непотрібних обговорень різниці між великими і складними Історіями.
Для оцінювання нових історій, коли планується цілком нова версія або новий продукт, і карток
багато, доцільно «зіграти» ще раз, а вже на етапі підстановки шкали порівняти результат з минулими
впорядкуваннями та, за потреби, оновити шкалу.
Якщо ж надходять нові вимоги під час роботи над поточною версією продукту, то достатньо узяти
нову картку та «вести» її вздовж шкали від більш найбільшого значення, до меншого. При цьому біля
кожної «ваги» слід питати команду: «нова вимога така ж складна, як ця чи ні?». Рухаючи нову картку в
бік меншої «ваги» і питаючи знову, можна знайти для цієї картки поділку шкали, з якою згодна вся
команда, а це і є ціль сумісної оцінки порівнянням.
Складність оцінки нефункціональних вимог у тому, що вони вимагають подвійних витрат: на
первинну та на безперервну відповідність (подібну до своєрідного «податку», оскільки регулярне
тестування продуктивності для дотримання відповідної нефункціональної вимоги створює для команди
додаткові витрати).
М.Кон радить оцінювати обидва складники витрат окремо: спочатку вартість початкової
відповідності, як і для довільного іншого елемента Беклога Продукту; далі для узгодження частки
«податку» команда та Власник Продукту визначають, коли буде проходити його «виплата» – кожен
спринт або кожні n спринтів. Тоді команда зможе оцінити кількість сторипоінтів, які необхідно виконати
протягом запланованої кількості спринтів і розподілити цей обсяг на кожен спринт.
Спеціальні прийоми:
 уточнення оцінок розміру історій – Кон_ ОПЛпроектов_2018.pdf, розд. 7, с.55-60;
 вибору найбільш прийнятної одиниці розміру – Кон_ ОПЛпроектов_2018.pdf, розд. 8, с.60-65.
Оцінки розміру далі застосовують для визначення швидкості команди (velocity) та планування релізів
і спринтів.
Лекція 7_12_10_2022_Проектування програмного забезпечення: засади та структурний
підхід
Корисні ресурси:
https://learn.ztu.edu.ua/mod/book/tool/print/index.php?id=278
https://devzone.org.ua/post/nayvazhlivishi-arkhitekturni-shabloni-yaki-neobkhidno-znati
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, с.27-30; розд.5,6
proIS.pdf, с.132, розд.8,9
Завгородній_Ялова.pdf, теми 8-15 (вибірково за питаннями)
Иванова_ТП_2021.pdf, розд.4, с.101-134, розд.5, 137-162
додатково
Orlov_PI.pdf, розд.6, с.149-168; розд.18
Progr_ingeneria_web.pdf, розд.5,7
romanov_PI.pdf, с.26, підрозд.41-4.3, с.143-165; 7.1,7.2, с.299-324
Басс Л. Архитектура программного обеспечения на практике [2ed.] / Л. Басс, П. Клементс, Р. Кацман –
Питер, 2006 – 574 с.(Басс_ Архитектура_на_практике2006.djvu)
Мартін Р. Чиста архітектура / Р.Мартін – Фабула, 2019. – 352 с. (Чистая архитектура_Мартин2018.pdf)
7.1 Поняття архітектури програмного забезпечення та його проектування як діяльності з
побудови архітектури

Рисунок 7.1 – Структура області знань «Проектування програмного забезпечення» за SWEBOK V.3
Поняття архітектури програмного забезпечення (ПЗ) запроваджено Е.Дійкстрою (1968р.),
Д.Парнасом (початок 1970рр.) і розвинуто, зокрема, М.Шоу, Д.Гарландом (1996р.).
Наразі основними нормативними документами з проектування ПЗ є:
1) ДСТУ ISO/IEC/IEEE 42010:2018 (ISO/IEC/IEEE 42010:2011, IDT) Інженерія систем і програмних
засобів. Опис архітектури, ISO/IEC/IEEE 42010:2011 є результатом адаптації й розвитку в 2007р. де-
факто стандарту ANSI/IEEE 1471-2000 IEEE Recommended Practice for Architectural Description for
Software-Intensive Systems : (Рекомендована практика та архітектурний опис програмних систем);
 2
2) ДСТУ ISO/IEC/IEEE 12207:2018 (ISO/IEC/IEEE 12207:2017, IDT) Інженерія систем і програмних
засобів. Процеси життєвого циклу програмних засобів.
3) IEEE Std 1016™-2009 IEEE Standard for Information Technology – Systems Design – Software Design
Descriptions (SDD-ieee-1016-2009.pdf – лише для довідки).
Нормативні документи надають доповнювані визначення архітектури ПЗ (software architecture) ПЗ:
опис підсистем та компонент програмної системи, а також зв'язків між ними; набір моделей та
артефактів, що містять результати рішень, прийнятих за способами реалізації вимог у програмному коді
(SWEBoK V3)

Набір засадничих принципів організації ПС, втілених у наборі її компонентів, їх зв’язках один з одним та
з оточенням ПС, а також принципів проектування та розвитку ПС
ДСТУ ISO/IEC/IEEE 42010:2018

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

середовищі, і принципах, що управляють їх дизайном і еволюцією".
IEEE 1471

Під архітектурою ПЗ розуміють набір внутрішніх структур ПЗ, виокремлених з різних точок зору і
складених з компонентів, їх зв’язків і можливих взаємодій між компонентами, а також доступних ззовні
властивостей цих компонентів.
Басс Л. Архитектура программного обеспечения на практике
Таким чином, архітектура ПС має визначити її внутрішню структуру: складники та спосіб їх
взаємодії між собою й їх програмно-апаратним оточенням. Тому вона підтримує насамперед
нефункціональні вимоги до ПС.
Натомість, узгоджений опис самих цих складників із зазначенням їх специфічної поведінки та
характеристик, який має забезпечити функціональні вимоги, звуть (архітектурним) проектом, або
дизайном ПС (software design).
Однак у практиці розроблення, залежно від застосованої парадигми, методології та технології ці
робочі продукти не завжди повністю відокремлені один від одного.
Наведені визначення зумовлюють три рамкові складники архітектури
(https://learn.ztu.edu.ua/mod/book/tool/print/index.php?id=278):
1) структуру – статичний складник, що показує розподіл відповідальності між виділеними
елементами архітектури;
2) поведінку – динамічний складник, що відображає взаємозв'язки і взаємодія між цими елементами;
3) стиль – засади й настанови щодо структури, які фіксують набір обмежень, що визначає сімейство
відповідних їм архітектур.
Відповідно, в області знань «Проектування ПЗ» SWEBoK V3 і в ДСТУ ISO/IEC/IEEE 12207:2018
(табл.7.1) діяльність з проектування подано як двох-кроковий процес:
а) визначення архітектури ПЗ (Architecture Definition, архітектурне проектування) – декомпозиція
структури (статичної) та організації (динамічної) компонент;
б) визначення проекту ПЗ (Design Definition, детальне проектування) – встановлення специфічної
поведінки та характеристик окремих компонентів.
Процес архітектурного проектування надає систему узгоджених моделей ПС з вищенаведеного
визначення архітектури за SWEBoK V3, яка фактично є повним і точним поданням специфікації вимог
до ПС, неспроможної забезпечити достатню повноту й точність через обмеження природної мови (хоча
б і структурованої). Тому його звуть також процесом архітектурного моделювання, або аналізу.
Модель ПС – це її формалізований опис на певному рівні абстракції, відповідному знанням і
повноваженням у процесі конструювання виконавців з певною функціональною роллю, точку зору
яких на ПС вона подає, описуючи конкретний аспект ПС з використанням відповідних діаграм і/або
формальних описів та документів заданого формату.
Як зазначає Г.Буч, «моделювання є центральною ланкою всієї діяльності щодо створення якісного
ПЗ. Моделі будують, щоб зрозуміти та осмислити структуру та поведінку майбутньої системи,
полегшити керування процесом її створення та зменшити можливий ризик, а також документувати
прийняті проектні рішення».
 3
ДСТУ ISO/IEC/IEEE 12207:2018 також фіксує для процесу проектування:
а) вхідний контекст – систему процесів інженерії вимог та їх продуктів (див.
Л4_22_09_2022_Вимоги.pdf), позначених у табл.7.1 жовтим;
б) вихідний контекст – систему процесів реалізації, верифікації й валідації включно з тестуванням
(Л12_17_11_2022_Тестування_ПЗ.pdf), функціонування та обслуговування, зрілість яких таким чином
безпосередньо залежить від зрілості процесу проектування, позначених у табл.7.1 блакитним.
Таблиця 7.1 – Позиція діяльності з проектування в системі рамкових процесів ЖЦ
1. Процеси 2. Організаційні процеси 3. Процеси технічного 4. Технічні процеси
угоди уможливлення проекту керування (Technical (Technical processes)
(Agreement (Organizational Project- Management processes)
processes) Enabling processes)
1.1 Процес 2.1 Life cycle model 3.1 Project Planning 4.1 Business or Mission Analysis
придбаванн management process process process
я 2.2 Infrastructure 3.2 Project assessment and 4.2 Stakeholder Needs and
(Acquisition Management process control process Requirements Definition process
process) 2.3 Portfolio Management 3.3 Decision Management 4.3 System/Software
1.2 Процес process process requirements definition process
постачання 2.4 Human Resource 3.4 Risk Management 4.4 Architecture Definition
(Supply Management process process process
process) 2.5 Quality Management 3.5 Configuration 4.5 Design Definition process
process Management process 4.6 System Analysis process
2.6 Knowledge 3.6 Information 4.7 Implementation process
Management process Management process 4.8 Integration process
3.7 Measurement process 4.9 Verification process
3.8 Quality Assurance 4.10 Transition process
process 4.11 Validation process
4.12 Operation process
4.13 Maintenance process
4.14 Disposal process
Далі в ЖЦ сформована архітектура – система моделей ПС – виконує критично важливі функції:
 фіксує єдине узгоджене бачення ПС всіх учасників розроблення та причетних сторін;
 уможливлює (часткову) імплементацію ПС за допомогою генераторів коду – під час
конструювання;
 пояснює структуру ПС для команди обслуговників і надає підґрунтя для внесення змін до ПС – під
час супроводження (званого наразі обслуговуванням – maintenance).
7.2 Де-факто стандартне подання архітектури ПЗ «4+1» Ф.Крачтена (Завгородній_Ялова.pdf
підрозділ 12.4)
Враховуючи зазначені функції архітектури ПС в її ЖЦ, ДСТУ ISO/IEC/IEEE 42010:2018 та IEEE Std
1016™-2009 надають уточнене визначення архітектури та/або її проекту як системи архітектурних
описів (architectural description) з точки зору певних причетних сторін за допомогою системи моделей.
Стандарти рекомендують для кожного подання фіксувати :
 ролі, погляди та інтереси зацікавлених у ньому сторін;
 причини та підстави відповідного погляду на ПС;
 неузгодженості в межах певного подання і/або між ними;
 допоміжну інформацію щодо джерел і підстав подання.
Шаблон опису архітектурного подання надано в IEEE Std 1016™-2009 (рис.7.2).
Чотири де-факто стандартні аспекти ПС та відповідні їм подання, необхідні для повної й однозначної
специфікації вимог до неї, та п’ятий, що забезпечує їх узгодження, підсумував Ф.Крачтен (Kruchten P.
Architectural Blueprints – The «4+1» View Model of Software Architecture / P. Kruchten // IEEE Software –
1995. – N12 (6) – P. 42-50 (Kruchten1995.pdf – лише для довідки) у так званій моделі архітектури «4+1»
(рис.7.3).
Зазначені аспекти та подання виконують різні, але взаємодоповнювальні, функції й відображають
точки зору виконавців основних функціональних ролей під час розроблення ПС:
1) подання сценаріїв, або варіантів використання відображає функціональні можливості ПС,
містить сценарії її взаємодії із зовнішнім середовищем та ролі користувачів і зовнішніх систем;
2) логічне подання відображає логічну структуру та поведінку ПС, відображає пакети, підсистеми,
класи, інтерфейси та їх взаємозв'язки;
 4

Рисунок 7.2 – Шаблон опису проекту ПЗ за IEEE Std 1016™-2009

2. Логічне подання 3. Подання реалізації

Аналітик, розробник
Поведінка 1. Подання Програміст
Структура варіантів використання Керування проектом

Користувач
Функціональність
4. Подання процесів 5.Подання розміщення
Системний інтегратор Системний інженер
Продуктивність Топологія ПС
Масштабовність Впрвадження, розгортання
Пропускна здатність Комунікація

Рисунок 7.3 – Архітектурне подання «4+1» Ф.Крачтена

3) подання реалізації відображає фізичну структуру, тобто набір програмних компонентів,
інтерфейсів та зв'язків між ними;
4) подання процесів відображає структуру потоків управління, моделює аспекти паралельної
роботи ПЗ, включає такі елементи, як потоки управління, нитки);
5) подання розміщення описує фізичне розміщення компонентів ПС на вузлах обчислювальної
системи, відображає її вузли, пристрої, лінії комунікації, процеси.
Подання варіантів використання займає центральну позицію серед 5-ти подань, оскільки воно
відіграє роль змістовного «скелету» ПС і проекту її розроблення.
В загальному випадку говорять про модель «N+1», маючи на увазі, що перелік архітектурних подань
може уточнюватися, але подання варіантів використання обов'язково є його ядром.
Згідно з рис.3.7, кожне архітектурне подання – це модель ПС з точки зору виконавців певної
відповідної ролі, яка фіксує лише істотні для цієї ролі аспекти й ігнорує все «зайве». Разом ці 4+1
подання надають багатовимірну, повну й точну специфікацію ПС.
7.3 Принципи проектування ПЗ
1) універсальні принципи опрацювання складності в ІПЗ (Л2_20_03_2019_Моделі_ЖЦ.pdf);
2) «nехнологічні» принципи опрацювання складності
Don’t Repeat Yourself – DRY
 5
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system
• What does it mean?
• Each system element should be defined once
• One table for each entity
• One class to model a specific entity
• One method to do certain activity
• This single definition should be used everywhere across the system
Keep It Simple Stupid /Straightforward/ – KISS
Design of each part should be as simple as possible
• What does it mean?
• Do not use complex tools for simple applications
• Do not create redundant classes, methods, modules and remove them from system
• Keep all parts of app small
You Aren’t Gonna Need It – YAGNI
Implement something only if you actually need it
• What does it mean?
• Do not implement anything until you need it
• You need develop, test, document, support anything you implemented – it takes your
time
• Often it will be refactored – it takes more of your time
• It may block or do more complex necessary features later – it takes all your time
3) принципи SOLID у трактувані Р.Мартіна (Чистая архитектура_Мартин2018.pdf, розд.7-11).
7.4 Стратегії проектування ПЗ (Завгородній_Ялова.pdf, тема 10)
7.4.1 Рамкові підходи до проектування ПЗ
Наразі застосовують чотири основні підходи до проектування архітектури ПЗ:
а) функціонально-модульний, або структурний, що передбачає функціональну декомпозицію, за
якої структура ПС описується в термінах двох ієрархій: її функцій і структур даних (переважний для
імперативної парадигми програмування);
б) об'єктно-орієнтований, що використовує об'єктну декомпозицію, за якої структура ПС
описується в термінах об'єктів та їх зв'язків, а поведінка – в термінах обміну повідомленнями між
об'єктами (Л8_20_10_2022_Пр_арх_об_орієнт_підхід.pdf);
в) проектування на основі структур даних;
г) компонентне проектування.
Перевагою підходу б) (й обмеженням підходу а)) є єдинність ієрархії – немає необхідності
відстежувати відповідність між двома ієрархіями функціонально-модульного підходу
7.4.2 Класичні техніки структурного аналізу на підставі (Иванова_ТП_2021.pdf, розділ 4;
Progr_ingeneria_web.pdf, розд.5):
 функціональних діаграм – SADT Д.Росса (Мінухін2008.pdf, підрозд.1.2; Инюшкина2014.pdf,
підрозділ 4.2)
 діаграм потоків даних (DFD) Йордана-Де Марко та Гейна-Сарсона
 діаграм структур даних Варн’є-Орра та Джексона
7.4.3 Метод SSADM (Инюшкина2014.pdf)
7.4.4 Класичні техніки структурного проектування (Иванова_ТП_2021.pdf, розділ 5;
Progr_ingeneria_web.pdf, розд.7)
7.5 Зразки проектування (Завгородній_Ялова.pdf, 8.4-8.11, теми 12, 13; Lecture07.pdf,
Lecture08.pdf)
7.5.1 Класифікація зразків
а) незалежні від стратегії проектування:
– архітектурні стилі – де-факто шаблони проектування макро-архітектури
(https://devzone.org.ua/post/nayvazhlivishi-arkhitekturni-shabloni-yaki-neobkhidno-znati)
Конвеєр оброблення даних (Канали й фільтри, Пакетне оброблення, Замкнений цикл керування)
Виклик-повернення (Процедурна декомпозиція, Абстрактні типи даних, Багаторівнева
архітектура, Клієнт – сервер);
Інтерактивні системи (Модель - представлення – контролер (MVC), Представлення-абстракція –
керування
Системи на підставі сховищ даних (репозиторій, класна дошка);
Керована подіями архітектура;
Архітектура на основі мікросервісів;
 6
 зразки організації, тобто успішні практики організації розробки ПЗ, що дозволяють вирішувати
певні завдання в рамках деякого контексту з обмеженнями на можливі рішення;
б) у руслі об’єктно-орієнтованого підходу (Л8_20_10_2022_Пр_арх_об_орієнт_підхід.pdf)
 зразки аналізу – типові рішення під час моделювання складних взаємовідносин між поняттями
певної предметної області;
 патерни проектування у вузькому сенсі – загальні рішення загальної проблеми в заданому
контексті (GoF, GRASP, об’єктно-орієнтоване уточнення SOLID);
 ідіоми – специфічні для деякої мови програмування способи організації елементів програмного
коду, що дозволяють вирішувати певну типову задачу;
7.5.2 Показові приклади зразків
7.6 Розробка, оцінювання та вибір архітектури на основі сценаріїв (Lecture06.pdf,
Завгородній_Ялова.pdf, підрозділ 9.3, тема 15)
Лекція 8_20_10_2022_Об’єктно-орієнтований аналіз і проектування програмного забезпечення
Корисні ресурси:
https://dou.ua/lenta/articles/solid-principles
https://bool.dev/blog/detail/grasp-printsipy
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, розд.10
proIS.pdf, с.132, підрозділ 6.1, розд.11,12, додатково розд.16
Завгородній_Ялова.pdf, 10.4, 12.2
додатково
Orlov_PI.pdf, розд.10, с.264-313; розд.18
Progr_ingeneria_web.pdf, розд.5,7
romanov_PI.pdf, підрозділ 3.3
Иванова_ТП_2021.pdf, розд.6,7
Довідкова література
Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с
англ. – СПб.: Питер, 2007. – Главы 12-13 (аналіз), 14-15 (Рамбо_Блаха_UML 2.0_ООМ_Р2007.djvu).
Крэг Ларман Применение UML 2.0 и шаблонов проектирования. 3-е издание Вильямс 2013, 274
(Ларман_UML 2.0_шабл_проект_2013.djvu)
Фаулер Мартин Шаблоны корпоративных приложений Вильямс 2016 548 (Фаулер_ Шаблоны
корпоративных приложений_2016.djvu)
Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования.
Паттерны проектирования. – СПб.: Питер, 2019. (Гамма_Паттерны проектирования_GoF.pdf)
8.1 Підґрунтя об’єктно-орієнтованого підходу до проектування ПС
8.1.1 Становлення об’єктно-орієнтованого підходу до проектування
Проблеми, що стимулювали розвиток об’єктно-орієнтованого підходу до аналізу й проектування ПЗ
(ООПр):
1) підвищення продуктивності розробки за рахунок повторного використання програмного забезпечення
(ПЗ);
2) спрощення супроводу й модифікації розроблених систем (локалізація внесених змін);
3) полегшення проектування ПЗ (за рахунок скорочення семантичного розриву між структурою
вирішуваних задач і структурою ПЗ).
Віхи розвитку ООПр::
1967: мова Simula – 1ый серед об'єктно-орієнтованих;
1970-е: Smalltalk – отримав досить широке розповсюдження;
1980-е: Теоретичні основи, C++, Objective-C;
1990-е: Методи OOA і OOD (Booch, OMT ....), з'явилася мова Java;
1997: Прийнято стандарт OMG UML 1.1..
Поняття об'єкту набуло практичного значення у проектуванні в 70-х - 80-х роках і стало основою методів
об'єктно-орієнтованих розробок. В період 1988-1992рр. Було розвинуто методи об' єктно-орієнтованого
аналізу і проектування:
 роботи Саллі Шлеєр (Sally Shlaer) та Стіва Меллора (Steve Mellor), що пізніше були втілені у
рекурсивному проектуванні (Recursive Design);
 Пітер Коуд (Peter Coad) та Ед Йордон (Ed Yourdon) розробили неформальний та орієнтований на
прототипи метод Коуда;
 Граді Буч (Grady Booch) з компанії Rational Software написав фундаментальну роботу з розробки ПС
мовою Ada;
 Джим Рамбо (James Rumbaugh) очолив групу в дослідній лабораторії General Electric і розробив
популярний метод Object Modeling Technique (OMT);
• Айвар Джекобсон (Ivar Jacobson) виклав свій досвід роботи з телефонними системами фірми
Ericsson і вперше ввів поняття варіанту використання (Use Case).
До 1995р. мала місце жорстка конкуренція численних методів об’єктно-орієнтованого аналізу й
проектування – «війна методів» (подібних за сутністю, але розбіжних за вторинними деталями), яку не
послабило навіть прийняття окремих методик і графічних нотацій (IDEF0, IDEF1X) як національних
стандартів.
 2
Проте у відповідь на пропозицію звести всі методи до єдиного стандарту, компанія OMG отримала
відкритий лист із протестом від всіх авторів основних методологій. Тоді Джим Рамбо залишив General
Electric і приєднався до Буча в Rational Software з наміром об'єднати їх методи та досягти стандартизації за
прикладом компанії Microsoft. Всі, хто не погодився з таким рішенням, сформували анти-Бучівську коаліцію.
На конференції OOPSLA'95 Буч та Рамбо представили перший опис об'єднаного методу у формі
документації під робочою назвою "Unified Method 0.8". В цей самий час фірма Rational Software здійснила
придбання компанії Objectory і до розробників уніфікованого методу приєднався Джекобсон. Розробка
нового методу - вже під назвою UML - тривала до 1997 року, причому з відкритим несхваленням зі сторони
голови OMG.
Тоді ж деякі компанії та організації побачили в мові UML стратегічний інтерес для свого бізнесу.
Компанія Rational Software разом з декількома організаціями, що виявили бажання виділити ресурси для
розробки строгого визначення версії 1.0 мови UML, заснувала консорціум партнерів UML, у який спочатку
ввійшли такі фірми, як Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational Software, TI і Unisys. Ці компанії забезпечили підтримку подальшої
роботи з більш точного визначення нотації.
В січні 1997р. авторитетні фахівці подали пропозиції щодо стандартизації методів обміну інформацією
між різними моделями. Серед них була й документація на мову UML 1.0. Після кількох істотних доповнень
версія 1.1. мови UML була прийнята як офіційний стандарт OMG.
Отже, наразі ООПр є результатом розвитку та інтеграції насамперед: OOAD Г.Буча, OMT Дж.Рамбо та
Object-Oriented Software Engineering (OOSE) А.Джекобсона.
8.1.2. Принципи ООПр (на додаток до загальних принципів проектування ПЗ з
Лекція7_13_10_2022_Проект_архіт_ПЗ_структ.pdf)
a) універсальні принципи ООПр за Гр. Бучем – принципи об’єктно-орієнтованої парадигми
програмування ():
основні (абстрагування, інкапсуляція, модульність, ієрархія об’єктів);
додаткові (типізація, паралелізм, збережність);
б) принципи SOLID, уточнені для коду в об’єктно-орієнтованій парадигмі
(https://dou.ua/lenta/articles/solid-principles/):
 єдиності відповідальності (The Single Responsibility Principle),
 відкритості/закритості (The Open Closed Principle),
 заміщення Б.Лісков (The Liskov Substitution Principle),
 розділення інтерфейсу (The Interface Segregation Principle),
 інверсії залежності (The Dependency Inversion Principle).
8.1.3 Переваги об’єктної моделі
 3

8.2 Особливості подання архітектури ПЗ Ф.Крачтена «4+1» в руслі ООПр

1. Сценарії, або варіанти використання ( use case view): взаємодія між складниками ПС.
Ціль: виділення компонентів, перевірка та уточнення архітектури.
2. Логічне подання (logical view): ключові сутності ПС як об'єкти та класи об'єктів.
Ціль: реалізація функціональних вимог в об'єктах.
3. Подання реалізації (англ. development view): розподіл компонентів ПС для імплементації різними
розробниками та командами.
Ціль: організація розробки.
4. Процесне подання (англ. process view): взаємодія процесів під час виконання ПС.
Мета: аналіз ПрПроцесненефункціональних вимог (продуктивності, доступності, …).
5. Подання розміщення, або фізичне (англ. physical view): організація компонентів у розподіленому
середовищі.
Ціль: планування розгортання ПС.
Функції «4+1» подання в ООПр ПС:
а) спрощення обговорення рішень з проектування ПС (споживачі – зацікавлені сторони, зокрема,
менеджер проекту, замовник; засоби – неформальні подання (напр., блочні діаграми);
б) документування вже розробленої архітектури для покращення її розуміння та розвитку ПС (споживачі
– розробники, відділ супроводу. засоби – формальні подання, напр. UML і спеціалізовані мови (architecture
description language – AADL, C2, Darwin, Wright).
Засоби UML для опису подань 1-5 пыдсумованы в табл..8.1.
Таблиця 8.1 – Основні діаграми UML для опису архітектури ПС в руслі ООПр
Подання Діаграма UML
1.Сценарії Варіантів використання
2.Логічне Класів, послідовності, взаємодії
3.Реалізації Компонентів, пакетів
4. Процесне Діяльності
5.Розміщення Розгортання
8.3 «Важкий» процес ООПр в руслі RUP (лише для довідки)
8.3.1 Підпроцес об’єктного аналізу (Аналіз_RUP.pdf)
8.3.2 Підпроцес детального проектування (Проект_RUP.pdf)
8.4 «Полегшений» процес об’єктно-орієнтованого аналізу та проектування ICONIX (ICONIX.pdf)
ICONIX (Д.Розенберг) – перспективный метод итеративной разработки ПЗ, объединивший лучшие
стороны сложного для понимания и применения процесса RUP и более неформального экстремального
программирования. ICONIX основан на прецедентах, является итеративным и инкрементным (рис.8.1). Его
основная задача найти ответ на вопрос: каким образом максимально быстро добраться от прецедентов к
работающей системе, используя минимум промежуточных шагов.
Отличительная характеристика ICONIX - использование ограниченного подмножества UML:
диаграмма классов, диаграмма последовательности, диаграмма пригодности (робастности) и
диаграмма вариантов использования (прецедентов).
 4

Рисунок 8.1 – Процес розроблення ICONIX

Крупные стрелки отражают основной порядок разработки, тонкие – возможность возврата на
предыдущие этапы для доработки (итеративность).
На первом из 4 этапов работы с методологией ICONIX (Анализ и рецензирование требований)
создаётся Диаграмма классов и далее дорабатывается в течение всех этапов, пока не станет готовой
основой для написания кода.
Кроме того, на начальной стадии работы по рассматриваемой методологии выявляются объекты
предметной области и взаимосвязь между ними. Выявляются прецеденты, путём создания диаграммы
вариантов использования, они организуются в группы, которые в свою очередь изображаются в виде
пакетов. Далее распределяются функциональные требования между прецедентами и объектами
предметной области. Также совместно с заказчиком корректируется и дополняется модель
пользовательского интерфейса.
На втором этапе – анализа и предварительного проектирования, создается диаграмма
пригодности, на которой отображаются граничные объекты, контроллеры и сущности также продолжается
модификация диаграммы классов так, чтобы она отражала конец фазы анализа в работе над проектом.
Для этого оставляются текстовые описания прецедентов – главные последовательности действий и
альтернативные последовательности, как показано в работе. Выполняется анализ пригодности,
отражающий для каждого прецедента приблизительный набор объектов и связей между ними, которые
выполняют описанный сценарий.
На третьем этапе Проектирования разрабатывается архитектура системы, создаются диаграммы
последовательности, которые описывают распределение поведения, то есть определения функций, из
которых будет состоять программа (какому классу должна принадлежать каждая функция). Стоит
подчеркнуть, что для каждого сценария разрабатывают отдельную диаграмму последовательности. На них
видно, что экземпляры объектов взаимодействуют путем обмена сообщениями, каждое из которых
вызывает ту или иную функцию объекта-получателя.
Далее уточняются классы уровня детального проектирования и уточняются диаграммы классов,
создается общая диаграмма классов и диаграммы классов по пакетам. По желанию строятся модель
данных с атрибутами и связями (ER-диаграмма) и диаграмма состояний [8].
На последнем этапе реализации пишется или генерируется код. Проходит его тестирование, а также
проводится испытание системы. Ккаждый этап завершается рецензированием, и обсуждением созданных
диаграмм с коллегами и что следует постоянно следить за качеством создаваемого ПО
 5
8.5 Зразки в руслі ООПр (Lecture07.pdf, Lecture08.pdf)
8.5.1 Патерни ООпр у вузькому сенсі
Складники патерна:
 назва;
 сфера застосування, опис проблеми, яку вирішує патерн проектування;
 узагальнена структура патерну: основні компоненти, їх взаємовідношення та виконувані функції
(природною мовою або діаграма класів UML);
 результат застосування шаблону, переваги й можливі негативні наслідки.
Чим не є шаблони:
Шаблон ̸= архітектура: архітектура системи більш абстрактна, шаблон
передбачає конкретну реалізацію;
Шаблон ̸= КПІ: шаблон вимагає імплементації, КПІ – це готовий код.
Шаблон проектування (англ. design pattern) типовий конструктивний елемент ПС, що задає взаємодію
кількох її компонентів, а також ролі та сфери відповідальності виконавців.
Проектування та програмування
Інженерія вимог Моделювання Архітектура

Проектування Конструювання
компонентів
Обслуговування Тестування
Патерни застосовують тут
8.5.2 23 патерни Банди чотирьох (GoF – Гамма_Паттерны проектирования_GoF.pdf;
DesignPatterns_Buday.pdf)
а) породжуючі (5 Creational Patterns)
• Builder
• Abstract Factory
• Factory Method
• Prototype
• Singleton
б) структурні (7 Structural Patterns)
• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy
в) поведінкові (11 Behavioral Patterns))
• Chain of responsibility
• Command
• Strategy
• Interpreter
• Observer (subscriber, publisher-subscriber, listener, dependents)
• Memento
• Visitor
• Template method
• Mediator
• State
• Iterator
8.5.3 GRASP (Ларман, Фаулер, Фаулер_ Шаблоны корпоративных приложений_2016.djvu)
На відміну від 23 класичних патернів GoF, 5 оснвних і 4 додаткових General responsibility assignment
software patterns K.Лармана, М.Фаулера – загальні шаблони розподілу відповідальності – не мають
специфічної структури, чіткої області застосування та конкретної вирішуваної проблеми, що вирішується, а
 6
лише являють собою узагальнені підходи/рекомендації/принципи щодо вирішення загальних завдань
стосовно призначення відповідальності класам та об'єктам (https://bool.dev/blog/detail/grasp-printsipy

Рисунок 8.2 – 5 основних і 4 додаткових патерна GRASP

Додаткові патерни:
• Pure Fabrication
• Indirection
• Polymorphism
• Protected Variations
8.5.4 Зразки аналізу М.Фаулера (напр., величина, перетворення, складена фізична одиниця,
Lecture07.pdf)
Лекція 9_27_10_2022_Конструювання програмного забезпечення
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, підрозділ 11.1
Иванова_ТП_2021.pdf, підрозд.2.1, 2.6-2.8
Мартин_Чистый код_2019.pdf, розд.3-5,7
додатково Мартин_ Ид_ программист.pdf, розд.4, 6-11
Программист_фанатик_Фаулер2019.pdf, поради 3,16,18,29,30
romanov_PI.pdf, підрозділ 3.4
9.1 Засоби ефективного конструювання програмного забезпечення (ПЗ) за SWEBOK V.3
Конструювання ПЗ – процес повнообсяжного створення працездатних ПЗ шляхом поєднання
кодування, верифікації, модульного й інтеграційного тестування та відлагодження
Конструювання
програмних
засобів (ПЗ)

1. Засади 2. Керування 3. Практичні 4. Технології

4. 5. Інструменти
констру- констру- констру- 5.
констру-
зауваження
ювання ПЗ юванням ювання ювання ПЗ
Проектування й
використання
Зменшення прикладного Середовища
Моделі Проектування в розроблення
складності конструювання конструюванні програмного
в ЖЦ ПЗ інтерфейсу
Об’єктно- Засоби
Передбачення Мови орієнтовані побудови
Планування конструювання засоби часу інтерфейсу
змін конструювання виконання користувача
Параметризація
Конструювання Вимірювання в Кодування та узагальнені Інструменти
для верифікації конструюванні типи (generics) модульного
Діагностичні тестування
твердження,
проектування за Інструменти
Повторне Тестування в контрактом і
конструюванні профілювання,
використання захисне аналізу
програмування продуктивності
Конструювання Оброблення та виокремлення
Стандарти для повторного помилок, шарів
конструювання використання виключень
і відмово-
стійкість
Конструювання Виконувані
з повторним моделі
використанням
Техніки
конструювання,
Якість керовані
конструювання таблицями та
на основі станів
Конфігурування
Інтеграція й інтернаціона-
лізація під час
виконання
Оброблення
вхідних даних
на основі
граматик

Елементарні
конструкції
паралелізму
Проміжні
програмні
засоби
(middleware)

Методи
конструювання
Стандарти розподілених ПЗ
платформ
Конструювання
різнорідних
Тестове систем
програмування
(test-first Аналіз
programming) і налаштування
продуктивності
.
Рисунок 9.1 – Структура області знань «Конструювання ПЗ» у SWEBoK V.3
 2
Таблиця 9.1 – Позиція діяльності з конструювання в ЖЦ ПС за ДСТУ ISO/IEC/IEEE 12207:2017
1. Процеси угоди 2 Організаційні 3. Процеси технічного 4 Технічні процеси
(Agreement процеси керування (Technical (Technical processes)
processes) уможливлення Management processes)
проекту
(Organizational
Project-Enabling
processes)
1.1 Процес 2.1 Life cycle model 3.1 Project Planning 4.1 Business or Mission Analysis process
придбавання management process process 4.2 Stakeholder Needs and Requirements
(Acquisition 2.2 Infrastructure 3.2 Project assessment Definition process
process) Management process and control process 4.3 System/Software requirements
1.2 Процес 2.3 Portfolio 3.3 Decision definition process
постачання Management process Management process 4.4 Architecture Definition process
(Supply process) 2.4 Human Resource 3.4 Risk Management 4.5 Design Definition process
Management process process 4.6 System Analysis process
2.5 Quality 3.5 Configuration 4.7 Implementation process
Management process Management process 4.8 Integration process
2.6 Knowledge 3.6 Information 4.9 Verification process
Management process Management process 4.10 Transition process
3.7 Measurement process 4.11 Validation process
3.8 Quality Assurance 4.12 Operation process
process 4.13 Maintenance process
4.14 Disposal process
9.2. Технологічні засоби ефективного конструювання ПЗ
9.2.1 Склад засобів
Основні засоби ефективного конструювання ПЗ:
а) дотримання рамкових принципів ІПЗ (Л1_Сутність_Осн_поняття_ПІ_16_09_2021.pdf);
б) адекватний формат розроблення - унікальні програмні продукти (ПП) в програмни х проектах,
розвиток ПП - в процесах операціональної діяльності шляхом безперервної інтеграції;
в) спеціальні прийоми конструювання, підсумовані на рис.9.1.
9.2.2 Прийоми ефективного конструювання (Java_DUT.pdf, розд.1, підрозділ 6.1)
1. Зменшення складності
Потреба у зменшенні складності впливає на всі аспекти конструювання і особливо критична для
процесів верифікації (перевірки) та тестування результатів конструювання, тобто самих програмних
систем.
Зменшення складності у конструюванні програмного забезпечення досягають створенням простого і
легко читаного коду, нехай і на шкоду прагненню зробити його ідеальним (напр., з точки зору гнучкості,
«чистоти», скорочення розміру). Це не означає, що треба обмежити застосування розвинених мовних
можливостей засобів програмування, а передбачає "лише" пріоритет читаності коду, простоти
тестування, прийнятного рівня продуктивності замість постійного вдосконалення коду без урахування
термінів та обмежень проекту.
Мінімізація складності досягається, зокрема, проходженням стандартам (обговорюються в темі 1.4
"Стандарти у конструюванні"), використанням низки специфічних технік (висвітлюються в 3.3
"Кодування") і підтримкою практик, спрямованих на забезпечення якості в конструюванні (3.5 "Якість
конструювання") .
2. Передбачення змін (Anticipating Changes)
Більшість програмних систем змінюються з часом. Причин цьому - безліч. Очікування змін є однією з
рушійних сил конструювання програмного забезпечення. Програмне забезпечення не є ізольованим від
зовнішнього оточення (як системного, так і з точки зору галузі діяльності, для автоматизації завдань і
проблем якого воно застосовується). Більше того, програмні системи є частиною змінюється
середовища і повинні змінюватися разом з нею, а, іноді, і бути джерелом змін самого середовища.
Очікування змін підтримується рядом технік, представлених в темі 3.3 "Кодування".
3. Конструювання з можливістю перевірки (Constructing for Verification)
"Конструювання для перевірки" (а саме такий сенс закладений в оригінальна назва даної теми)
припускає, що побудова програмних систем повинно вестися таким чином, щоб сама програмна
система допомагала вести пошук причин збоїв, будучи прозорою для застосування різних методів
 3
перевірки та внесення необхідних змін, як на стадії незалежного тестування , так і в процесі
операційної діяльності - експлуатації, коли особливо важлива можливість швидкого виявлення та
виправлення виникаючих помилок.
Серед технік, спрямованих на досягнення такого результату конструювання:
• огляд, оцінка коду (code review)
• модульне тестування (unit-testing)
• структурування коду для і спільно з застосуванням автоматизованих засобів тестування
• обмежене застосування складних або важких для розуміння мовних структур.
4. Повторне використання
Під час конструювання ПЗ типові ресурси систематичного повторного використання - бібліотеки,
модулі, компоненти, початковий код, «продукти з полиці» (COTS).
Систематичне багаторазове використання істотно підвищує продуктивність і якість ПЗ за зниження
його вартості.
Багаторазове використання має два тісно пов'язані аспекти: “
конструювання для багаторазового використання;
конструювання з багаторазовим використанням.
5. Стандарти в конструюванні (romanov_PI.pdf, підрозділ 3.4; Мартин_Чистый код_2019.pdf,
розд.3-5,7)
Стандарти, які безпосередньо застосовуються під час конструювання, охоплюють:
• комунікаційні методи (наприклад, стандарти форматів документів і <оформлення> утримання)
• мови програмування і відповідні стилі кодування (наприклад, Java Language Specification, що є
частиною стандартної документації JDK - Java Development Kit і Java Style Guide, що пропонує
загальний стиль кодування для мови програмування Java)
• платформи (наприклад, стандарти програмних інтерфейсів для викликів функцій операційного
середовища, такі як прикладні програмні інтерфейси платформи Windows - Win32 API, Application
Programming Interface або. NET Framework SDK, Software Development Kit)
• інструменти (не в термінах середовищ розробки, але можливих засобів конструювання - наприклад,
UML як один зі стандартів для визначення нотацій для діаграм, що представляють структура коду і його
елементів або деяких аспектів поведінки коду)
Використання зовнішніх стандартів. Конструювання залежить від зовнішніх стандартів, пов'язаних
з мовами програмування, використовуваним інструментальним забезпеченням, технічними
інтерфейсами і взаємним впливом Конструювання програмного забезпечення та інших областей знань
програмної інженерії (в тому числі, пов'язаних дисциплін, наприклад, управління проектами). Стандарти
створюються різними джерелами, наприклад, консорціумом OMG - Object Management Group (зокрема.
Стандарти CORBA, UML, MDA, ...), міжнародними організаціями з стандартизації такими, як ISO / IEC,
IEEE, TMF, ..., виробниками платформ, операційних середовищ і т.д. (Наприклад, Microsoft, Sun
Microsystems, CISCO, NOKIA, ...), виробниками інструментів, систем управління базами даних ит.п.
(Borland, IBM, Microsoft, Sun, Oracle, ...).
Розуміння цього факту дозволяє визначити достатній і повний набір стандартів, які застосовуються у
проектній команді або організації в цілому.
Використання внутрішніх стандартів. Певні стандарти, угоди та процедури можуть бути також
створені усередині організації або навіть проектної команди. Ці стандарти підтримують координацію між
певними видами діяльності, групами операцій, мінімізують складність (у тому числі при взаємодії членів
проектної групи та за її межами), можуть бути пов'язані з питаннями очікування та обробки змін, ризиків
і питаннями конструювання для перевірки та подальшого тестування. У поєднанні з зовнішніми
стандартами, внутрішні стандарти покликані визначити загальні правила гри для всіх членів проектної
команди, домовившись про терміни, процедури та інших значущих угодах, незалежно від ступеня
формалізації процесів конструювання, зокрема, і процесів життєвого циклу, в загальному випадку.
Приклад використання внутрішних стандартів – практичні рекомендації з організації конструювання
в MSF (Ехлаков_ОПИ.pdf, підрозділ 4.4).
2. Керування конструюванням (Managing Construction)
2.1 Моделі конструювання в життєвому циклі (Construction Models)
Моделі конструювання визначають комплекс операцій, які включають послідовність, результати
(наприклад, вихідний код і відповідні unit-тести) та інші аспекти, пов'язані із загальним життєвим циклом
розробки. У більшості випадків, моделі конструювання визначаються використовуваним стандартом
життєвого циклу, застосовуваними методологіями і практиками. Деякі стандарти життєвого циклу, за
своєю природою, є орієнтованими на конструювання - наприклад, екстремальне програмування (XP-
eXtreme Programming). Деякі розглядають конструювання в нерозривному зв'язку з проектуванням (в
частині моделювання), наприклад, RUP (Rational Unified Process).
 4

9.2.3 Адекватний технологічний формат конструювання

Наразі розрізняють два формати цілеспрямованої продуктивної діяльності груп людей:
1) операціональна діяльність, яка не має наперед визначеного моменту завершення, стало
виконується за усталеними регламентами, де опрацьовано якомога більше ризиків, і не зумовлює
унікальності результатів (напр., процес вироблення на підприємстві продукції за допомогою регулярно
повторюваних технологічних операцій згідно з технологічними інструкціями);
2) проектна діяльність, яка реалізує створення унікальних продуктів або результатів для їх
передбачених споживачів в економічно доцільні терміни за умов глибокої невизначеності.
Як показано на рис. 9.2, керованість операційної діяльності забезпечено за допомогою
управління процесами (Process Management) і ситуаціями (Case Management). Умови, за яких ці
формати управління неприпустимі або неефективні, якраз і визначають сферу управління
проектами, показану на рис. 9.2.

Рисунок 9.2 – Зіставлення проектної та процесної діяльності

Особливості проектної діяльності зафіксовано в її (де-факто) стандартизованих визначеннях
Узагальнення поширених визначень та ознак проекту дозволяє прийняти його робоче визначення
I. Проект – це обмежена в часі цілеспрямована зміна окремої системи із встановленими
вимогами до якості результатів, припустимими межами витрат засобів і ресурсів та
специфічною організацією
Фіксація у визначенні «окремої системи» вказує не тільки на цілісність проекту та його
розмежованість з іншими заходами, але й підкреслює унікальність проекту на відміну від
операціональної діяльності.
Наведене визначення сформульовано в руслі так званого нормативного підходу до управління
проектами, який наразі розвивають фахівці НТУУ КПІ МОНУ.
Сутність нормативного підходу – розвиток управління проектами як самодостатнього розділу теорії
управління відкритими соціально-економічними системами, присвяченого ефективним методам,
формам і засобам управління змінами. Для цього сукупність учасників проекту розглядають як активну
організаційну систему, тобто групу людей, що разом реалізують певну програму або ціль, керуючись
певними нормами й правилами та виявляючи свою активність. Предметом досліджень є:
1) змістовне визначення складу так званих механізмів управління проектами – взаємоузгоджених
правил і процедур, які регламентують взаємодію учасників проекту, зокрема процедур прийняття рішень
менеджером проекту та рештою учасників. ;
2) встановлення й формалізація бажаних позитивних властивостей цих механізмів;
3) власне розроблення механізмів з такими властивостями.
Базовим формальним апаратом є теорія календарно-мережного планування й управління. Вона
дозволяє формувати детерміновані й імовірнісні мережні моделі робіт проекту та груп його виконавців і
застосовувати до них потужний сучасний інструментарій (дискретної) оптимізації на графах, який
гарантує оптимальність отримуваних рішень. Таким чином, нормативний підхід відкриває можливості
систематизації кращих і гірших практик управління проектами шляхом зіставлення їх зі створюваними
механізмами.
 5
Однак у низці предметних галузей, зокрема в розробці програмних продуктів, не завжди
вдається адекватно врахувати в графо-подібних мережевих моделях всі необхідні змістовні обмеження.
До того ж, розв’язання оптимізаційних задач для складних і великих проектів може потребувати
забагато ресурсів, а отримане з великими труднощами оптимальне рішення може виявитися
неприйнятним, бо істотні змістовні обмеження не були адекватно відображені в моделі, на підставі якої
воно отримане. Тому численні фахові спільноти наразі розвивають альтернативний підхід до
систематизації управління проектами на технологічних засадах, який званий технологічно-описовим.
Його сутність фіксує відповідне визначення проекту в актуальних Зводах знань з управління проектами
PMBoK 6,7 ред. (Л1_Сутність_Осн_поняття_ПІ_01_09_2022.pdf).
II. Проект – обмежений в часі захід, спрямований на створення унікального продукту,
послуги або результату
Отже, ключова розбіжність між проектною та операціональною діяльністю – нециклічність проекту
(хоча окремі види діяльності в проекті можуть мати циклічний характер).
Визначення проекту як цілеспрямованої зміни певної системи в часі дозволяє взаємодоповнюване
застосування його «проектної» нотації як системи взаємопов’язаних робіт (що висвітлює унікальні зміни)
та «процесної» нотації, яка акцентує стійкі стани – стабільні роботи, подані обмеженими в часі
фрагментами процесів.
9.3 Інструменти підтримки ефективного конструювання ПЗ
9.3.1 Основні групи інструментів
Дев’ять наведених груп інструментальних засобів підтримки конструювання відповідають першим
п’яти областям знань SWEBOKV3 — інженерія вимог, проектування, конструювання, тестування,
обслуговування. Всі вони підтримують також інтеграцію модулів під час конструювання.
1. Інструменти роботи з вимогами (Software Requirements Tools):
— інструменти керування вимогами (моделювання вимог);
— засоби здобуття, аналізу, специфікації та перевірки вимог;
— інструменти трасування вимог.
Обидві ці категорії є складовими керування вимогами, але інструменти трасування можна
розглядати відокремлено внаслідок їх важливості, особливо за підвищення складності ПЗ. До того ж
трасування вимог виконують під час не тільки їх аналізу, але й інших процесів життєвого циклу.
Функціональні можливості інструментів роботи з вимогами можуть варіювати залежно від складності
проектів і рівня зрілості процесів. Якщо на другому рівні зрілості за моделлю CMMI Staged визначено
«управління вимогами» (Requirement Management), то для 3го встановлюється «розробка вимог»
(Requirement Development). Водночас вимоги можуть сприйматися і як елементи конфігурації поряд із
запитами на зміни та іншими активами проекту. Тому іноді у програмних засобах, доступних на ринку
ПЗ, для роботи з вимогами пропонуються системи конфігураційного керування.
Засоби моделювання на основі UML і BPMN також можна розглядати як елементи
інструментального забезпечення роботи з вимогами, що відображається в їхній функціональності й
тісній інтеграції з класичними засобами керування вимогами. Сама інтеграція реалізується не тільки
через візуальне подання роботи з репозиторіями вимог, а й в автоматизації трасування між моделями
та/або їх елементами — з одного боку та вимогами — з іншого.
2. Інструменти проектування (Software Design Tools) охоплюють засоби створення і перевірки
програмного дизайну. За відсутності загальноприйнятої класифікації існує розмаїття таких інструментів.
Їх можна поділити на окремі категорії за базовими нотаціями моделювання і проектування (SADT/IDEF,
UML, BPMN/BPEL, Microsoft DSL тощо) або за цільовими завданнями (бізнесмоделювання,
проектування БД, об’ єктноорієнтоване проектування, інтеграційне/SOAпроектування тощо).
3. Інструменти конструювання (Software Construction Tools) призначені для виробництва й
трансляції програмного подання (зокрема, початкового коду), придатного для машинного виконання:
– редактори програм — інструменти створення та модифікації початкового коду програм і, можливо,
асоційованої з ним документації. Це можуть бути як редактори загального призначення, так і
спеціалізовані редактори з підтримкою специфіки цільової мови програмування (найчастіше — в
інтегрованих середовищах розробки (Integratel development environment IDE);
– компілятори і генератори коду. Традиційно компілятори є неінтерактивними (командними)
трансляторами початкового коду. Однак існує тенденція інтеграції компіляторів і редакторів в
інтегровані середовища програмування. До цього класу також належать препроцесори,
лінковники/завантажувачи та генератори коду (за винятком, хіба що, об’єктноорієнтованих засобів
проектування, які підтримують зв’язок з початковим кодом і, як тенденція, тісно інтегровані з новим
поколінням IDE);
 6
– інтерпретатори забезпечують виконання програм через емуляцію. Вони можуть підтримувати дії
з конструювання ПЗ, надаючи для виконання програм оточення, більш контрольоване, ніж може надати
операційна система. Нині існує тенденція щодо злиття компіляторів та інтерпретаторів, зокрема в так
званій компіляції «на льоту», коли проміжний програмний код під час виконання або із випередженням
(наприклад, у процесі запуску/завантаження програми) перетворюється на набір інструкцій, виконуваних
безпосередньо засобами операційної системи, але під контролем середовища виконання. Такий підхід
покладено в основу низки сучасних програмних платформ, наприклад Java і.NET. У цьому контексті
можна говорити про об’єднання інтерпретаторів із компіляторами та генераторами коду в клас засобів
безпосередньої підготовки (трансляції) початкового коду до виконання;
– відладники підтримують процес конструювання ПЗ, функціонально відрізняючись від редакторів і
компіляторів.
В окрему категорію можна об’єднати інтегровані засоби розробки, а також програмні бібліотеки
(бібліотеки компонентів). Надкатегоріями можна вважати програмні платформи (наприклад, Java, J2EE,
Microsoft.NET) і платформи розподілених обчислень (CORBA і WebServices), що містять як інструменти,
так і певні моделі конструювання, перетворення та виконання коду.
4. Інструменти тестування (Software Testing Tools):
— генератори тестів, що надають допомогу з розроблення сценаріїв тестування;
— засоби виконання тестів, що забезпечують середовище виконання тестових сценаріїв у
контрольованому оточенні, яке дає змогу відстежувати поведінку тестованого об’єкта;
— інструменти оцінювання тестів підтримують оцінювання результатів виконання тестів,
допомагаючи визначити місце і міру відповідності поведінки об’єкта очікуванням;
— засоби керування тестами надають підтримку всім аспектам процесу тестування програмного
забезпечення;
— інструменти аналізу продуктивності використовують для кількісного оцінювання та аналізу
продуктивності ПЗ.
Цей клас інструментальних засобів можна доповнити категоріями, котрі відповідають іншим видам
тестування. Так, можна виокремити інструменти функціонального тестування, засоби тестування
безпеки, інструменти тестування користувацького інтерфейсу, інструменти навантажувального
тестування тощо.
5. Інструменти обслуговування (Software Maintenance Tools):
— інструменти полегшення розуміння програм, зокрема засоби візуалізації;
— інструменти реінжинірингу, які надають допомогу з відновлення для наявного ПЗ таких
артефактів, як специфікація та опис дизайну (архітектури), що їх в подальшому можна трансформувати
для генерування нового продукту на основі функціональності наявного.
Оскільки сучасні засоби проектування зазвичай підтримують аналіз початкового коду (у разі
об’єктноорієнтованих систем) та його візуалізацію (зокрема, у вигляді діаграм послідовності UML), це
дає підстави об’єднати названі інструменти в єдиний клас інструментів реінжинірингу. Водночас
діяльність із супроводу й підтримки, зокрема щодо збоїв і виправлення виявлених помилок у ПЗ,
вимагає віднесення до цього класу також засобів конфігураційного керування (наприклад у частині
оброблення запитів на зміни).
6. Інструменти конфігураційного керування (Software Configuration Management Tools):
— інструменти відстежування дефектів, розширень і проблем;
— інструменти керування версіями;
— інструменти складання і випуску.
7. Інструменти керування розробленням (Software Engineering Management Tools):
— інструменти планування і відстежування проектів, що використовуються для календарного
планування робіт, кількісного оцінювання зусиль і вартості проекту;
— інструменти керування ризиками включно з їх ідентифікацією, оцінюванням та моніторингом;
— інструменти кількісного оцінювання робочих продуктів процесу конструювання;
8. Інструменти підтримки процесів (Software Engineering Process Tools):
— інструменти моделювання, які дають змогу, зокрема, описати модель процесів (див. п. 2.2);
— інструменти керування процесами;
— інтегровані середовища — платформи розробки ПЗ, які охоплюють усі стадії життєвого циклу і
нині зумовлюють розвиток інтегрованих засобів розробки і CASEсистем у напрямку підтримки суміжної
функціональності — керування вимогами, конфігураційного керування з підтримкою керування змінами,
тестування та оцінювання якості. Такі середовища звуть ALMсистем (Application Lifecycle Management,
системи керування життєвим циклом, див. тему 8).
9.Інструменти забезпечення якості (Software Quality Tools):
— інструменти інспектування, що використовуються для підтримки огляду та аудиту;
— інструменти (статичного) аналізу.
 7
Ці засоби використовують для аналізу програмних артефактів, даних, потоків робіт і залежностей.
Вони призначені для перевірки певних властивостей чи артефактів на відповідність заданим
характеристикам.
Додаткові складники автоматизованої підтримки конструювання ПЗ (Miscellaneous Tool Issues):
— техніки інтеграції інструментів — платформи, подання, процеси, дані та настанови;
— метаінструменти, які генерують інші інструменти, наприклад компілятор компіляторів;
— оцінювання інструментів.
9.3.2 Інтегровані середовища розроблення (ICASE)
Хоча автоматизовану підтримку конструювання надіють і розмежовані CASE засоби, їх інтеграція
додатково забезпечує::
 полегшення передавання інформації (моделі, програми, документи, дані) між засобами,
програмними проектами, командами й групами в процесі конструювання;
 зменшення трудомісткості й підвищення зрілості допоміжних процесів – керування конфігурацією,
забезпечення якості, документування – та якості їх продуктів;
 підвищення контрольованості програмних проектів шляхом покращенняя планування, моніторингу
та комунікацій;
 удосконалення координації учасників великого програмного проекту.
Водночас застосування інтегрованого CASEсередовища (ІCASE) має обмеження:
 подання несуперечливої інформації щодо інжинірингу,
 стандартизація інтерфейсів між інструментальним засобами, однакового механізму комунікацій
інженера із кожним засобом та забезпечення можливості роботи в різних технічних і програмних
середовищах.
Термін «інтеграція» передбачає комбінацію та взаємодію. ICASE об’єднує набір різних засобів і
певний спектр інформації, що зближує між собою як інструментальні засоби, так і учасників проекту,
забезпечуючи:
— механізм спільного використання інформації всіма засобами, наявними у середовищі;
— можливості відстежування впливу змін в одній інформаційній сутності на інші;
— контроль версій та суцільне керування конфігурацією;
— прямий доступ до будьякого засобу середовища;
— стандартизований інженерний підхід із застосуванням сучасної практики та перевірених методів;
— автоматизовану підтримку обраної моделі життєвого циклу ІС;
— інтеграцію CASE засобів та одиниць конфігурації в єдину структуру розбиття робіт;
— однаковий вигляд та єдиний спосіб роботи для всіх засобів у межах стандартизованого людино-
машинного інтерфейсу;
— підтримку комунікацій між учасниками проекту;
— визначення й накопичення управлінських і технічних метрик, використовуваних надалі для
вдосконалення процесів і продуктів.
В архітектурі ICASE виокремлюють такі рамкові компоненти:
 базу даних для зберігання інформації,
 систему керування об’ єктами для керування змінами інформації,
 систему керування засобами для координації використання CASEзасобів,
 інтерфейс користувача.
Більшість моделей фіксують розподіл цих компонентів по чотирьох рівнях:
1) рівень інтерфейсу користувача – охоплює стандартизований набір засобів інтерфейсу, що
містить ПЗ для керування людино-машинним інтерфейсом і бібліотеку відображуваних об’єктів. Для
встановлення єдиних правил подання й взаємодії визначають єдиний презентаційний протокол, який
регламентує правила розміщення елементів, назви та організацію меню, іконки, назви об’єктів,
принципи використання клавіатури й миші, механізми доступу до засобів;
2) рівень засобів – містить сервіси з керування CASEзасобами, які контролюють їх поведінку в
середовищі. В разі багатозадачної роботи ці сервіси забезпечують синхронізацію й комунікації,
координацію потоків інформації з репозиторію та системи керування об’єктами до засобів, функції
захисту тй аудиту, а також збирання метрик щодо застосування засобів;
3) рівень керування об’єктами – виконує конфігураційне керування шляхом ідентифікації всіх
конфігураційних об’єктів, контролю версій та підтримки контролю змін, обліку та аудиту. Фактично саме
цей рівень забезпечує інтеграцію засобів і доступ до репозиторію ICASE;
4) рівень спільно використовуваного репозиторію – містить базу даних і виконує функції контролю
доступу, уможливлюючи взаємодію рівня керування об’єктами з базою даних.
 8
Замість традиційного неефективного виконання функцій репозиторію учасником проекту (що міг за
потреби відновити втрачену (неформальну) інформацію) наразі репозиторій — це база даних, яка є
центром накопичення й збереження інформації з конструювання ПЗ, а роль людини (інженера) полягає
у взаємодії з нею за допомогою інтегрованих CASEзасобів.
Репозиторій ICASE – сукупність механізмів і структур даних, що забезпечують інтеграцію в
аспектах:
— інтеграції даних включно з перевіркою правильності елементів репозиторію, забезпечення
несуперечності між поведінкою взаємопов’язаних об’єктів та автоматичним виконанням каскадної
модифікації, коли зміна одного об’єкта вимагає змін інших об’єктів;
— сумісного використання інформації численними розробниками й засобами, керування та
контролювання множинного доступу до даних, блокування й розблокування об’єктів для запобігання
втрати змін, внесених одночасно різними учасниками проекту;
— інтеграції «дані – засоби», тобто визначення моделі даних, доступних для всіх засобів ICASE
середовища, контролювання доступу до даних, керування конфігурацією;
— інтеграції «дані – дані», тобто встановлення зв’язків між об’єктами даних для виконання інших
функцій;
— контролювання дотримання методології — визначення ER-моделі для репозиторію, структура якої
зумовлює кроки для його заповнення й ведення;
— стандартизації документів включно з програмним кодом.
На підтримку наведених аспектів інтеграції репозиторій описують мета моделлю – ER-моделлю, що
визначає склад збережуваної інформації та способи її збереження й доступу до даних інструментальних
засобів та розробників – «інженерів», захисту та інтеграції даних і розвитку ЕК-моделі.
Зміст і характеристики репозиторію визначаються відповідями на два запитання — що слід зберігати
в ньому та які специфічні сервіси він має надавати.
Зазвичай, у репозиторії має зберігатися така інформація:
— опис вирішуваних проблем;
— опис предметної області;
— розв’язок проблем;
— правила та інструкції з обраного процесу розробки ІС (методології);
— план проекту, його ресурси та історія;
— опис організаційного контексту.
Сильний CASEрепозиторій має виконувати:
1) функції досконалої СКБД (зазвичай реляційної або об’єктноорієнтованої):
— зберігання ненадмірних даних — кожен об’єкт записується тільки один раз, але стає доступним
усім CASEзасобам;
— високорівневий доступ — немає потреби дублювати засоби керування даними в кожному
інструментальному засобі;
— забезпечення незалежності даних — CASEзасоби та цільові додатки ізольовані від фізичних
параметрів зберігання даних, тому на них не впливають зміни конфігурації технічного забезпечення;
— контроль транзакцій — репозиторій здійснює блокування записів, двоетапне здійснення
транзакцій, протоколювання та відновлення даних для підтримки їх цілісності за умови одночасної
роботи кількох користувачів;
— забезпечення безпеки — контроль доступу до даних згідно з установленими правами;
— реалізацію непередбачених запитів і звітів — надання прямого доступу до вмісту репозиторію
за допомогою зручного користувацького інтерфейсу з використанням SQL або форм із наданням
можливості проводити аналіз даних та формувати звіти, не передбачені в CASEзасобах середовища;
— забезпечення відкритості — простий механізм введення/виведення для завантаження або
передавання великих обсягів даних;
— багатокористувацька підтримка — керування одночасним доступом до бази даних багатьох
засобів і користувачів із розв’язанням конфліктів і блокуванням на рівні файлів і записів. Для
середовищ, що функціонують в умовах мережі, багатокористувацька підтримка передбачає також
інтерфейс із мережними протоколами і засобами;
2) функції, специфічні для CASEсередовища:
 зберігання складних структур даних – у репозиторії поряд з простими елементами даних можуть
зберігатися дані складних типів (діаграми, документи, файли). Також репозиторій містить інформаційну
модель (метамодель), яка описує структуру, зв’язки і семантику даних, що зберігаються. Для
метамоделі має бути передбачено можливість розширення з пристосуванням до нових подань та
специфічної організаційної інформації. Крім моделей та описів систем, що розробляються, репозиторій
має містити асоційовані метадані — додаткову інформацію, яка описує дані щодо процесу інжинірингу,
зокрема час створення певного компонента, його поточний статус, зв’язки з іншими компонентами;
 9
 забезпечення інтеграції — інформаційна модель репозиторію також має містити правила
(політики), що описують бізнесправила та інші обмеження та вимоги щодо інформації, яка вводиться в
репозиторій безпосередньо або з CASEзасобу. Може встановлюватися тригер, який активує правила,
асоційовані з об’єктом, у разі модифікації останнього для перевірки адекватності моделі в режимі
реального часу;
 семантично потужний інтерфейс з інструментальним засобами – метамодель містить семантичну
інформацію, яка дає змогу різним CASEзасобам інтерпретувати значення даних, що зберігаються в
репозиторії. Наприклад, діаграми потоків даних, підготовлені за допомогою певного CASEзасобу,
зберігаються в репозиторії у формі, визначеній інформаційною моделюю і незалежній від будьякого
внутрішнього їх подання, що використовується цим засобом. Інші CASEзасоби можуть інтерпретувати
вміст репозиторію і використовувати інформацію, потрібну їм для виконання поставлених завдань.
Таким чином семантична складова інформації, що зберігається в репозиторії, надає можливість
численним інструментальним засобам спільно використовувати дані на відміну від погоджень «засіб—
засіб» («мостів»);
 керування процесом/проектом. Репозиторій містить інформацію не лише про цільовий програмний
додаток, а й про характеристики кожного окремого проекту та загальний процес розробки ІС організації
(фази, завдання тощо). Це створює можливості для автоматизованої координації технічних та
управлінських дій. Наприклад, статус проекту може оновлюватися автоматично або як результат
використання певного CASEзасобу. Призначення завдань та запити можуть здійснюватися
електронною поштою. Звітування про проблеми та стан їх виправлень, супровід, авторизацію змін
можна координувати і відстежувати на основі доступу засобів до репозиторію.
 керування версіями. Репозиторій має бути здатен вмістити всі версії, що створюються під час
реалізації проекту, з метою ефективного керування випуском продукту і надання розробникам
можливості повернутися до попередніх версій під час тестування та відлагодження. При цьому
вимагається, щоб CASEрепозиторій міг контролювати широкий спектр типів об’єктів, включно з текстом,
графікою, картами, складними документами та унікальними об’єктами, якими є визначення екранів і
звітів, файли об’єктів, тестові дані, результати тестування. Відстежування версій об’єктів має
здійснюватися на довільно обраному рівні. Для підтримки паралельної розробки мають дозволятися
численні похідні (варіанти) від єдиного попередника — розробники можуть одночасно опрацьовувати
різні підходи до вирішення проблеми, починаючи з однієї точки;
 відстеження залежностей та керування змінами. У репозиторії підтримується широкий набір
зв’язків між елементами даних, що зберігаються, зокрема відношення між структурними підрозділами і
процесами, складовими програмного додатку, проектними рішеннями та інформаційною архітектурою
підприємства тощо. Деякі з цих відношень є лише асоціаціями, інші є залежностями чи обов’язковими
зв’язками. Підтримку цих зв’язків між об’єктами розробки звуть керуванням зв’язками.
Дві останні функції підтримують і системи конфігураційного керування
9.4 Засоби вдосконалення конструювання
9.4.1 Безпечне програмування (2021_Davydov.pdf)
9.4.2 Рефакторинг: свідчення потреби та прийоми виконання (Мартин_Чистый код_2019.pdf,
розд. 17 – «Запахи» коду, Code smells; розд.10,12; Мартин_ Ид_ программист.pdf, розд.4)
9.5.3 Реінжиніринг
Повторна реалізація успадкованої програмної системи (ПС) для підвищення зручності її
використання, супроводження, розширення функціоналу чи впровадження оновлених технологій.
Визначення рефакторингу охоплює повторне документування ПС, її реорганізацію та реструктуризацію,
переписування більш потужною мовою програмування, модифікація і/або модернізаціяю структури та
системнихданих.
9.5.4 Реверсна інженерія (зворотне розроблення) ПЗ
Результати дослідження програм часто використовують для їх подальшої модифікації, розширення
функціоналу або створення засобів, що дозволяють долати обмеження їх використання (напр., умовно-
безкоштовні програми). Такі методи можна також застосувати для отримання специфікації протоколів
обміну інформацією (напр., мережних протоколів) або способів її зберігання (формати файлів).
Основними методами зворотного розроблення ПЗ є:
1) моніторинг активності – найчастіше для дослідження протоколів обміну інформацією. Напр.,
для дослідження мережевих проколів можна використати перехоплення потоків даних у мережі за
допомогою спеціалізованих програмних і/або апаратних засобів. Однак цей метод може не надати
повного розуміння алгоритмів функціонування ПЗ;
 10
2) дизасемблювання. Машинний код програми читається й перекладається мовою асемблера для
його розуміння в первинному вигляді. Таким способом можна досліджувати будь-яке ПЗ, але за
допомогою спеціальних технологій під час розроблення дизасемблювання можна значно ускладнити.
Метод вимагає високої кваліфікації людини – виконавця зворотного розроблення й значних витрат часу;
3) декомпіляція. Полягає у перекладі машинного коду програми мовою високого рівня. Метод важко
реалізувати з огляду на складність створення інструментів.
Лекція 10_03_11_2022. Обслуговування програмного забезпечення
Посібники
Коцовський_ОбслугПС.pdf, розд.6
10.1. Структура загальноhjplприйнятих знань з обслуговування ПЗ (SWEBOK V3)

Засоби
обслуговування
ПЗ

Міграція

Вилучення з
експлуатації

Рисунок 10.1 - Структура області знань «Обслуговування ПЗ» за SWEBOK V.3

Основні регламенти діяльності з обслуговування ПЗ:
1. ДСТУ ISO/IEC 14764:2014 Інженерія програмного забезпечення. Процеси життєвого циклу
програмного забезпечення. Технічне обслуговування (ІSO/ІEC 14764:2006, ІDT) (пропередня редакція –
14764_2006.pdf – лише для довідки); наразі інтегрує IEEE Std. 1219:1998.
2. ДСТУ ISO/IEC/IEEE 12207:2018 (ISO/IEC/IEEE 12207:2017, IDT) Інженерія систем і програмних
засобів. Процеси життєвого циклу програмних засобів
Таблиця 10.1 – Позиція діяльності з обслуговування ЖЦ ПС за ISO/IEC/IEEE 12207:2017
1. Процеси 2 Організаційні процеси 3. Процеси технічного 4 Технічні процеси
угоди уможливлення проекту керування (Technical (Technical processes)
(Agreement (Organizational Project- Management processes)
processes) Enabling processes)
1.1 Процес 2.1 Life cycle model 3.1 Project Planning 4.1 Business or Mission Analysis
придбавання management process process process
(Acquisition 2.2 Infrastructure 3.2 Project assessment 4.2 Stakeholder Needs and
process) Management process and control process Requirements Definition process
1.2 Процес 2.3 Portfolio 3.3 Decision 4.3 System/Software requirements
постачання Management process Management process definition process
(Supply 2.4 Human Resource 3.4 Risk Management 4.4 Architecture Definition process
process) Management process process 4.5 Design Definition process
2.5 Quality Management 3.5 Configuration 4.6 System Analysis process
process Management process 4.7 Implementation process
2.6 Knowledge 3.6 Information 4.8 Integration process
 2
Management process Management process 4.9 Verification process
3.7 Measurement 4.10 Transition process
process 4.11 Validation process
3.8 Quality Assurance 4.12 Operation process
process 4.13 Maintenance process
4.14 Disposal process
10.2 Основи обслуговування ПЗ (Коцовський_ОбслугПС.pdf, розд.6)
Фаза обслуговування в життєвому циклі зазвичай починається відразу після приймання/передачі
продукту й триває протягом періоду гарантії або, частіше, передбаченої договором технічної підтримки.
Однак дії з обслуговування починаються набагато раніше.
Інтеграція обслуговування ПЗ в бізнес-процеси зумовлена:
– скороченням інвестицій організацій безпосередньо в розробку програмних систем, з метою
збільшення термінів використання вже існуючого ПЗ;
– змінністю бізнес-потреб, бажання підвищити віддачу від вже експлуатованих систем
– проблеми експлуатації Open Source, Legacy
– поширення аутсорисингу.
Неготовність розглядати життєвий цикл як такий, що триває і після передачі системи в експлуатацію,
неопрацьованість відповідних процедур коригування продукту після його випуску - проблема:
– в бізнесі-середовищі, для якого ПЗ лише інструмент,
– в компаніях-інтеграторах, де часто "забувають" про необхідність розвинення успіху після
впровадження системи у замовника,
– в незалежних постачальників програмних продуктів, які, випускаючи нову версію кращого у своєму
класі продукту, починають працювати над новою версією, приділяючи недостатню увагу підтримці та
оновленню вже існуючих версій.
За SWEBOK V3,
Обслуговування ПЗ - система взаємопов’язаних дій, необхідних для витратно ефективної
підтримки його функціонування
За IEEE 1219:1998
Обслуговування ПЗ - модифікація програмного продукту після передачі в експлуатацію для
усунення збоїв, поліпшення показників продуктивності та/або інших характеристик (атрибутів)
продукту або адаптація продукту для використання в модифікованому оточенні
За ДСТУ ISO/IEC 14764:2014, ISO/IEC/IEEE 12207:2018
Обслуговування ПЗ - процес модифікації програмного продукту в частині його коду і документації
для вирішення виникаючих проблем <при експлуатації> або реалізації потреб у покращенні тих чи
інших характеристик продукту.
Завдання обслуговування - модифікація продукту за збереження його цілісності.
Обслуговування підтримує функціонування програмного продукту протягом усього операційного
життєвого циклу, тобто періоду його експлуатації.
У процесі супроводу:
– фіксуються і відслідковуються запити на модифікацію (запити на зміни),
– оцінюється вплив запропонованих змін,
– модифікується код та інші активи (артефакти) продукту,
– проводиться необхідне тестування
– і, нарешті, випускається оновлена версія продукту;
– проводиться навчання користувачів
– і забезпечується їх щоденна підтримка при роботі з поточною версією продукту.
ДСТУ ISO/IEC/IEEE 12207:2018, ISO/IEC 14764:2014 систематизують основні дії з обслуговування
(рис.10.1):
1) втілення процесу обслуговування;
2) аналіз проблеми та модифікацій(змін) для її опрацювання;;
3) реалізацій модифікацій;
4) огляд (оцінка) і прийняття рішень з модифікації;
5) міграція (з однієї версії програмного продукту на іншу, з одного продукту до іншого);
6) виведення продукту з експлуатації.
 3
Багато робіт з обслуговування подібні до робіт з розроблення: необхідні аналіз, проектування,
кодування, тестування й документування Фахівці з супроводу (персонал супроводу) можуть отримувати
знання про програмний продукті безпосередньо від розробників.

Рисунок 10.1 – Внутрішня структура процесу обслуговування за ДСТУ ISO/IEC 14764:2014

Взаємодія з розробниками і раннє залучення цих фахівців допомагає зменшити трудомісткість
адекватного обслуговування програмної системи (ПС). Передача знань персоналу супроводу, його
навчання, має починатися не пізніше початку дослідної експлуатації продукту (пік навантаження на
службу супроводу припадає на перших 2-6 тижнів з моменту передачі системи в реальну експлуатацію).
Інакше зусилля на одночасну підтримку ПС і навчання відповідних фахівців не тільки перевищить
реально допустимі норми завантаження персоналу (як групи або служби супроводу і техпідтримки, так і
розробників системи), але й знизить ефективність підтримки користувачів на критично важливому етапі
початку використання нової/модифікованої системи
Стандарт ISO/IEC 14764 рекомендує, щоб персонал або організації, які відповідають за
обслуговування, адаптували до своїхз потреб елементи процесів розроблення.
Однак обслуговування охоплює й певні унікальні роботи, виконувані за допомогою спеціалізованих
процесів:
– передавання – контрольована й координована діяльність з передавання програмного засобу
повноважень і відповідальності щодо нього від розробників групі, службі чи організації, відповідальній за
подальшу підтримку;
– прийняття/відхилення запитів на модифікацію – запити на зміни можуть як прийматися і
передаватися на опрацювання, так і відхилятися з обґрунтованих причин: обсягу і/або складності
необхідних змін та їх трудомісткості. Відповідні рішення можуть також прийматися на підставі
пріоритетності, оцінки обґрунтованості, наявності ресурсів, планів релізів;
– сповіщення обслуговників і відстеження статусу запитів на модифікацію та звітів про
помилки - функція підтримки кінцевих користувачів, що ініціює оцінювання й аналіз пріоритетності та
вартості модифікацій, пов'язаних із запитом/повідомленою проблемою;
– аналізування впливів – можливих наслідків змін наявної ПС;
– підтримка ПЗ – роботи з консультування користувачів у відповідь на їх інформаційні запити й
повідомлення про проблеми (помилки, збої, непередбачену поведінку, нерозуміння роботи з ПС);
– контракти й зобов'язання – класична угода щодо рівня надаваних послуг та інших договірних
аспектів виконання обслуговниками відповідних робіт.
Роботи з планування обслуговування
Планування робіт з обслуговування має стосуватися всіх рівнів планування:
– бізнес – планування (організаційний рівень);
– безпосередніх робіт з обслуговування;
– версій (рівень програмного засобу);
– оброблення конкретних запитів на зміну.
Розробка програмних систем, як правило, займає від декількох місяців до декількох років, супровід і
активна експлуатація систем займає від декількох років до 5-10 років і більше. Проведення оцінки
ресурсів – невід'ємна частина планування. Ресурси, необхідні для супроводу, повинні бути оцінені та
закладені до бюджету ще при розробці системи. Планування робіт із супроводу має починатися
одночасно з прийняттям рішення про створення системи та узгоджуватися з цілями забезпечення
якості.
Спочатку необхідно визначити концепцію супроводу. За ДСТУ ISO/IEC 14764:2014 вона має
фіксувати::
– вміст діяльності з супроводу;
 4
– адаптацію процесу супроводу;
– ідентифікацію обслуговника;
– оцінки вартості супроводу.
Після розробки концепції діяльності з супроводу має бути сформований відповідний план
супроводу. Цей план має готуватися одночасно з розробкою програмного засобу. План має визначати,
як користувачі будуть розміщувати свої запити на модифікацію (зміни) або повідомляти про помилки,
збої та проблеми.
Планування версій вимагає від обслуговника:
– отримання й збирання інформації про дати розміщення індивідуальних запитів і звітів;
– досягнення угоди з користувачами щодо вмісту подальших версій ПЗ;
– ідентифікації потенційних конфліктів і можливих альтернатив реалізації необхідних запитів;
– оцінки ризиків для функціонування поточної версії ПС і планування «відкату» до
немодифікованого варіанту ПС у разі проблем, пов'язаних з модифікацією;
– інформування всіх зацікавлених сторін.
На рівні індивідуального запиту планування охоплює аналізування впливів
Важливим елементом процесу обслуговування є управління конфігураціями – спеціальна
діяльність з систематичного адміністрування файлових активів програмних проектів.
Конфігураційне управління охоплює два взаємопов’язані завдання – управління версіями та
управління збірками.
Виконання першого підтримує керування версіями файлів і виконується в проекті за допомогою
спеціальних програмних пакетів – засобів версійного контролю (Microsoft Visual SourceSafe, IBM
ClearCase.).
У свою чергу, управління збірками – це автоматизований процес трансформації вихідних текстів ПЗ
у пакет виконуваних модулів, що враховує численні налаштування проекту й компіляції та інтегрується з
процесом автоматичного тестування. Ця процедура є засобом інтеграції проекту, основою його
ітеративної розробки.
Конфігураційне управління має справу з мінливими у процесі продуктами, які з наборів файлів. Такі
продукти прийнято називати одиницями конфігураційного управління: документація користувача;
проектна документація; вихідні тексти; пакети тестів; інсталяційні пакети; Тестові звіти.
У кожної одиниці конфігураційного управління має: структурою – набір файлів; відповідальною
особою, хто її розробляє; практикою конфігураційного управління; автоматичною процедурою контролю
за цілісністю елемента. Елементи конфігураційного управління можуть утворювати ієрархію.
В результаті керування конфігураціями має бути забезпечена якість ПЗ
Якість програмного забезпечення
Недостатньо сподіватися, що у процесі супроводу якість програмного засобу підвищуватиметься.
Для підтримки процесу супроводу повинні плануватися та реалізовуватися відповідні процедури та
процеси, спрямовані на підвищення якості. Роботи та техніки з забезпечення якості, перевірки та
атестації, огляду, аналізу та оцінки, а також аудиту повинні відбиратися в контексті взаємодії та
узгодження з усіма іншими процесами, спрямованими на досягнення бажаного рівня якості. На основі
стандарту ISO/IEC 14764 рекомендується адаптувати відповідні процеси, техніки та активи, що
стосуються розробки програмного забезпечення. До них, наприклад, належать документація з
тестування та результати тестів.
Результатом супроводу є еволюція ПЗ.
М. М. Леман виділив такі типи програм:
S — програми написані в чіткій відповідності із специфікацією вимог до неї;
P — програми, які реалізують процедури, що повністю визначають їх поведінку незалежно від
оточення;
E — програми, що функціонують в умовах реального світу, тобто істотно залежать від середовища
свого функціонування, а тому потребують адаптації до зовнішніх вимог .
У 1970-х роках М.М.Леман почав формулювати закони еволюції програмного забезпечення,
насамперед для програм E-типу. Внаслідок робіт Б.Боема, Л. Беладі ці закони можна розподілити по
трьох категоріях:
I. Закони про еволюцію характеристик програмних систем;
II. Закони, що стосуються організаційно-економічних обмежень на розвиток ПЗ;
III. Мета-закони еволюції ПЗ.
 5

1. Еволюція ПО — саморегульований процес. Характеристики змін (число помилок, розмір системи,

періодичність випусків) приблизно однакові для всіх випусків.
2. Темп розробки програмної системи стабільний протягом всього ЖЦ і слабо залежить від тих, що
затрачують на розробку ресурсів.
3. Обсяг змін у кожному релізі залишається відносно стабільним впродовж усього періоду розробки.
(Причина: необхідність збереження високого рівня знань розробників про ПС).
Обслуговування можна розглядати як еволюційну розробку ПС. Оскільки здана в експлуатацію
система не завжди повністю завершена, її треба змінювати протягом терміну експлуатації. В результаті
ПС стає складнішим і погано керованим, виникає проблема зменшення його складності. До технологій
еволюції ПС відносяться реінженеринг, реверсна інженерія та рефакторинг [8, 10].
Реінженеринг - удосконалення застарілого ПС шляхом його реорганізації, а також
перепрограмування окремих елементів або налаштування параметрів на іншу платформу або
середовище виконання.
Рефакторинг – реорганізація коду для поліпшення характеристик та показників якості програм без
зміни їхньої поведінки. Цей процес реалізується шляхом поступової зміни окремих операцій над
текстами, інтерфейсами, середовищем програмування та виконання ПС, а також налаштування чи
внесення змін до інструментальних засобів підтримки ПС. Якщо зберігається форма існуючої системи
за зміни, то рефакторинг - одне із варіантів реверсної інженерії.
Реверсна інженерія
Складається вивчення ПС, відновленні специфікації (графів викликів, потоків даних, управління),
аналізі модульної структури. Така дія називається зворотним проектуванням - відновлення втрачених
знань про програму тільки на основі її тексту. Найчастіше реверсна інженерія застосовується після того,
як до коду ПС було внесено багато змін і воно стало некерованим. Корисно видалити недосяжні ділянки
коду (у старих програмах їх обсяг може досягати 30%), провести реструктуризацію програми (легше
розуміти струнку ієрархічну структуру).
Лекція 11_10_11_22 – Засади, моделі та техніки забезпечення якості програмних засобів
Посібники
Кучеров_Артамонов_ІПЗ_2017.pdf, розд. 14
ЯПЗ_Т.pdf, розд.1, 16
Orlov_PI.pdf, с.313-322
romanov_PI.pdf, c.253-266
Жихаревич_ПППІ.pdf, підрозд. 7.3,7.4, розд.8
ЛМ_Взаємодія.pdf, Лекція 15
11.1 Об’єкти, сутність та засоби забезпечення якості програмних засобів
Найбільш повний спектр дій з керування якістю програмних засобів зафіксований:
1) у SWEBOK V.3 (2013) в області знань «Якість програмного забезпечення» (Software Quality).
2) у PMBoK PMI 6 ed. і програмному розширенні PMBoK PMI 5 ed. у форматі трьох процесів (див. рис.
11.1) та в PMBoK 7 ed (2021р.). – у форматі одного з 12 принципів декларованої PMBoK 7 ed. Системи
надання цінності за допомогою проектів: «вбудовувати якість у процеси та результати»;
3) в ДСТУ ISO 10006:2018 (ISO 10006:2017, IDT) Управління якістю. Настанови щодо керування якістю
в проектах
4) в ДСТУ ISO/IEC/IEEE 12207:2018 та ISO/IEC/IEEE 12207:2017 – у форматі:
 процесу керування якістю в групі організаційних процесів уможливлення проекту;
 процесу гарантування якості в групі процесів технічного управління;
 процесів верифікації й валідації в групі технічних процесів,
а також допоміжних процесів оцінювання й контролювання та процесу вимірювання в групі процесів
технічного управління.

Засоби якості
програмного
забезпечення

Безпека програмного
забезпечення

Структура області знань «Якість програмного забезпечення» за SWEBoK V.3

 2

Процеси за PMBoK PMI 6 ed

Рисунок 11.1 – Структура знань щодо забезпечення якості програмних продуктів
Поняття якості взагалі і якості програмного забезпечення зазнало розвитку.
Філ Кросби (Phil Crosby) визначив якість як відповідність вимогам користувачів, 1979р.
Уотс Хемпфрі (W.Hamphrey, Software Engineering Institute, автор моделі оцінки зрілості CMM, People
Software Process та Team Software Process) розглядає якість як «досягнення відмінного рівня придатності
до використання».
Компанія IBM, у свою чергу, ввела в обіг фразу "якість, керована ринковими потребами" (market-driven
quality).
Критерій Болдріджа (M.Baldrige) в Національному Інституті стандартів і технологій США (НІСТ)
National Institute of Standards and Technology, "Baldrige National Quality Program", передбачає подібне
трактування: «якість, що задається споживачем» і розгляд задоволення споживача як головної мети
забезпечення якості.
Приймемо робочі визначення:
Якість - наявність в деякого об’єкта характеристик, здатних забезпечувати його використання за
призначенням.
Якість програмного забезпечення (Software Quality) – сукупність його властивостей, що
забезпечують здатність задовольняти встановлені, передбачувані або очікувані потреби відповідно
до призначення.
Для керування якістю в програмному проекті необхідне:
1) виокремлення об’єктів забезпечення якості;
2) моделі якості об’єктів і методи її прогнозування й вимірювання за цими моделями;
3) загальні підходи до створення інфраструктури й організаційної культури постійного
підвищення якості процесів та їх продуктів;
4) результативні та економічно ефективні процеси, методи та процедури керування якістю;
Далі окреслено дев’ять основних об’єктыв забезпечення якості програмного продукту в процесі
його розроблення, чинники й моделі, за наявності, їх якості та напрями й засоби її забезпечення.
1. Власне програмний продукт та робочі продукти – його подання в життєвому циклі (ЖЦ).
Базовый стандарт по качеству ISO/IEC 9126-1:2001 «Software Engineering -Product Quality, Part 1:
Quality Model» предлагает рассматривать качество на трех уровнях его обеспечения в артефактах
 3
проекта (внутреннее качество, внешнее качество и качество ПО в эксплуатации) и рекомендует
иерархическую модель качества для каждого из этих уровней.
Процесс оценивания качества по модели ISO/IEC 9126-1:2001 регламентируется стандартом
ISO/IEC 14598:1999 «Information Technology - Software Product Evaluation» в 6 частях.
Однак через обмеження пари стандартів ISO/IEC 9126 й ISO/IEC 14598 на їх заміну наразі
запроваджується новітнє сімейство стандартів Software Quality Requirements and Evaluation (SQuaRE) −
ISO/IEC 250XX «Технология программного обеспечения. Требования и оценка качества программного
продукта. Руководство».
Мета розвитку ISO/IEC 9126-1:2001 стандартами SQuaRE – відобразити зв’язок між вимогами до ПП
та його якістю й ресурсами її досягнення.
Національні відповідники ISO/IEC 9126 й ISO/IEC 14598 наразі перебувають у процесі скасування.
Їх замінюють:
ДСТУ ISO/IEC 25010:2015 (для розвитку моделі внутрішньої та зовнішньої якості),
ДСТУ ISO/IEC 25022:2019 (ISO/IEC 25022:2016, IDT) (для розвитку моделі якості під час
застосування),
ДСТУ ISO/IEC 25023:2019 (ISO/IEC 25023:2016, IDT) Інженерія систем і програмних засобів. Вимоги до
якості систем програмних засобів та їхнього оцінювання (SQuaRE). Вимірювання якості систем та
програмних продуктів;
ДСТУ ISO/IEC 25040:2016 (ISO/IEC 25040:2011, IDT) Інженерія систем і програмних засобів. Вимоги
до якості систем і програмних засобів та її оцінювання (SQuaRE). Процес оцінювання.
ДСТУ ISO/IEC 25041:2016 (ISO/IEC 25041:2012, IDT) Інженерія систем і програмних засобів. Вимоги
до якості систем і програмних засобів та її оцінювання (SQuaRE). Настанова з оцінювання для
розробників, придбавачів і незалежних оцінювачів.
Стандарты серии SQuaRE сгруппированны в 5 cекций:
− ISO/IEC 2500n – группа стандартов «Управление качеством». Стандарты, входящие в эту группу,
определяют все общие модели, термины и определения, а также практические советы высокого уровня
по применению наиболее подходящих стандартов к определенным прикладным случаям;
− ISO/IEC 2501n – группа стандартов «Модель качества» представляют детальную качественную
модель, включая характеристики для внутреннего и внешнего качества программного продукта, а также
качества в использовании. Кроме того, характеристики внутреннего и внешнего качества
разбиваются на подхарактеристики. Также предоставляется практическое руководство по
использованию модели качества;
− ISO/IEC 2502n – группа стандартов «Контроль качества» включает эталонную модель измерения
качества программного продукта, математическое определение качественных мер и практическое
руководство по их применению. Представленные меры относятся к внутреннему, внешнему качеству
программного продукта, а также качеству в использовании. Определены и представлены элементы
качественных мер, формирующие основу для последующих мер (измерений);
− ISO/IEC 2503n – группа стандартов «Требования к качеству» помогает в определении (уточнении)
требований к качеству. Данные требования к качеству могут использоваться в процессе выявления
требований к программному продукту, который необходимо разработать, или как входные данные для
процесса оценки. Процесс определения требований соответствует техническому процессу,
определенному в ISO/IEC 15288;
− ISO/IEC 2504n – группа стандартов «Оценка качества» устанавливает требования, рекомендации и
руководства для оценки программного продукта, которое производится как специалистами по оценке,
так и заказчиками или разработчиками. Также представлена поддержка документирования меры
(измерения) как модуля оценки.
Группы SQuaRE (ISO/IEC 25050 – ISO/IEC 25099) содержат стандарты и (или) технические отчеты по
качеству программного продукта, которые относятся к особым прикладным областям применения или
дополняют стандартов начальных групп.

2. Графічний інтерфейс користувача

2.1 Некількісні критерії якості (romanov_PI.pdf, c.253-266)
2.2 Засади проектування та метрики Л.Константайна-Л.Локвуд для оцінки практичності (Orlov_PI.pdf,
с.313-322)
2.3 Модель GOMS – Goals, Operators, Methods, and Selection Rules – Цілі, Оператори, Методи та
Правила выбору (https://habr.com/ru/post/512712/; ЛМ_Взаємодія.pdf, підрозд.15.2; GOMS_Л11.pdf) та
її вдосконалення (https://infolisting.ru/category/x7rs546zv0jbfi_notes.shtml).
 4
Запропонована С.Кардом, Т.Мораном, А.Ньюелом,1983.
Поширена Дж.Раскіном, Интерфейс: новые направления в проектировании компьютерных систем»:
Символ-Плюс; М.; 2005.

3. «Ресурси» для ПС – компоненти повторного використання (КПВ) і продукти з полиці (COTS).

Тестирование соответствия компонентов ПО и COTS-продуктов (от commercial of-the-shelf, готовый к
использованию продукт, продукт «с полки») потребностям их использования в создаваемом продукте
(согласно ISO/IEC 12119: 1994 «Information Technology–Software Packages--Quality Requirements and
Testing»).

4. Засоби розробки
Тестування за ДСТУ 3919-1999 (ISO/IEC 14102:1995) Інформаційні технології. Основні напрямки
оцінювання та відбору CASE-інструментів.

5. Процеси розроблення (див.папку Proc_SW)

Спеціальні моделі якості процесів розробки ПС зафіксовані:
– в 9-частинному стандарті ISO/IEC 15504 «Information Technology -Software Process Assessment» і
шести ДСТУ, відповідних його частинам (модель SPICE, від Software Process Improvement and Capability
dEtermination), де якість розглядається як спроможність (capability) окремих процесів та їх поточних
композицій;
– у стандартах де-факто технологічної зрілості організації-розробника – Capability Maturity Model
(СMM), CMM Integrated (CMMI), розроблених Інститутом програмної інженерії (SEI), де якість
розглядається як технологічна зрілість одного цілісного процесу розробки, придбання, надання послуг
(Жихаревич_ПППІ.pdf, підрозд. 7.3),
Моделі SPICE і CMM(I) взаємно доповнюють одна одну, причому сертифікація процесів за ISO 9001
допомагає досягти старших рівнів зрілості за CMMI. Описи моделей містять рекомендації щодо
визначення рівня зрілості оцінюваного процесу.

6. Процеси управління розробкою ПЗ (див. папку Proc; в IPMA-OCB.pdf розд. 6, с.32-39)

Якість подано універсальними моделями зрілості:
1) управління проектами, програмами і портфелями OPM3 PMI, IPMA Delta, Берклі, Л.Грейнера,
Г.Карцнера
2) ділових процесів організації: M.Болдріджа, Ділової досконалості (EQFC) (див. instr07.pdf)

7. Виконавці проекту
1) моделі зрілості колективу People CMM, особистого (PSP) й коллективного (TSP) процесу
розроблення (див. PSPTSP.doc);
2) програми професійного розвитку, зокрема в компанії Construx Software під керівництвом
С.Макконнелла (Жихаревич_ПППІ.pdf, підрозд. 7.4).

8. Процеси, що підтримують керування якістю(див. sqp.doc):

– процеси забезпечення гарантії якості (Software Quality Assurance – SQA);
– верифікації й валідації;
– огляду (спільного перегляду) та аудиту;
– власне процес керування якістю (SQM), що забезпечує функції контролю та оцінки за всіма
аспектами процесів, продуктів і ресурсів, включно з вимогами до процесів, вимірюванням процесів та їх
результатів і встановленням зворотного зв'язку.

Роль SQA – забезпечити планування й подальше виконання процесів на основі заданого плану та
проведення необхідних вимірювань процесів.
Верифікацію й валідацію (V&V) застосовують до артефактів програмного проекту в його
контрольних точках для перевірки й підтвердження їх правильності. Дії з V&V регламентуються базовими
стандартами:
IEEE 1012-2016 - IEEE Standard for System, Software, та Hardware Verification and Validation
IEEE 1059:1993 «IEEE Guide for Software Verification and Validation Plans».
 5
Діяльність з оглядів та аудитів продуктів включає п'ять типів дій: управлінські огляди, технічні
огляди, інспекції, наскрізний контроль та аудити, уніфіковано регламентованих IEEE 1028:2008
«IEEE Standard for Software Reviews and Audits».
Огляди ПЗ регламентовані також ДСТУ ISO/IEC 20246:2018 (ISO/IEC 20246:2017, IDT) Інженерія
систем і програмних засобів. Рецензування розроблюваних програмних засобів.
Засади процесу керування якістю надають
TickIT – схема сертифікації систем менеджменту якості для програмного забезпечення на ґрунті
ІSO/ІEC 90003:2004, запропонована провідними фірмами розробниками Великої Британії;
ДСТУ ISO/IEC 90003:2006 Програмна інженерія. Настанови щодо застосування ІSO 9001:2000 до
програмного забезпечення (ІSO/ІEC 90003:2004, ІDT), який регламентує розгортання Систем
менеджменту якості під час розробки ПЗ;
ДСТУ ISO 10006:2018 (ISO 10006:2017, IDT) Управління якістю. Настанови щодо керування якістю в
проектах.
9. Загальні підходи до створення інфраструктури й організаційної культури постійного
підвищення якості
1) універсальні
– Total Quality Management (ТQM) (Shper_Q.ppt), Quality Function Deployment (QFD) (див. qfd.DOC,
instr06.pdf, p41-haag.pdf), JIT, TOC, Бережливое производство (Lean Development)
– внутрішній і зовнішній бенчмаркінг – розповсюдження кращого досвіду (див. instr06.pdf);
– статистичний контроль процесів для гарантованого рівня їх прогнозованості;
– Система збалансованих показників (BSC);
– Підхід Хосін Канрі: якісно-орієнтована реалізація стратегія організації в проектах;
– підходи до якісно-орієнтованого управління організацією, зокрема, Architecture for Information
Systems (ARIS);
2) спеціальні (див. QIP_IDEAL.doc):
– SQFD , Software Lean Development, фабрики опыта (experience factory, В.Бейсли), подходы к
организации разработки программного продукта QIP (центр GSFC NASA) и IDEAL (SEI), построение и
использование информационной среды устойчивого выполнения проектов (project baseline, П.
Джалотта).
– реалізація статистичного контролю процесів – методологія Cleanroom ( див. Cleanroom.pdf)
Для аналізу результатів оцінювання якості застосовуються прості візуальні інструменти аналізу
якості та, за достатньої кваліфікації фахівців і ресурсів, методи багатовимірного статистичного аналізу
кількісних і якісних даних (див. інструменти.doc).
11.2 Моделі якості програмного забезпечення
11.2.1. Поняття якості програмного забезпечення
Залежно від стадії життєвого циклу програмного продукту і проекту та відповідних їй потреб учасників
проекту, в ISO/IEC 9126-1:2001 зафіксовано три категорії якості ПС:
– внутрішня, яку характеризує відносна кількість залишкових дефектів у коді й документації;
– зовнішня, яку характеризує відносна кількість відмов під час функціонування;
– експлуатаційна, яку характеризує спроможність програмного продукту виконувати покладені на
нього функції,
схарактеризовані на рис. 11.2.
Червоний, жовтий і зелений колір підкреслює, що безпосередньо забезпечити розробники можуть
лише внутрішню якість, а зовнішня й експлуатаційна послідовно визначаються нею.
 6
ПРОГРАМНА СИСТЕМА (ПС)
Група інтегрованих програмних засобів, які реалізують інформаційну технологію виконання певного
ділового процесу Споживача/Замовника і можуть використовувати спільні сховища даних.
(робоче означення, прийняте на підставі ГОСТ 34)
Позитивний приклад: група програмних застосунків, що складають автоматизоване робоче
місце фахівця, є ПС.
Негативний приклад: програмно-апаратні засоби захисту інформації не є ПС.

ЯКІСТЬ ПС ( ISO/IEC 9126, ДСТУ 2844-94)

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

Проектування і Специфікація вимог Визначення потреб у

реалізація ПС до ПС функціях ПС

Відображає погляд К і н ц е в и х
користувачів/
Відображає погляд Cпоживачів
Замовника/
Постачальника
та Ро з р о б н и к а
( аналітика, Експлуатаційна, або
тестувальника, якість у використанні:
менеджера проекту)
Відповідність ефекту від
Обумовлює с п о ж и в а н н я функцій ПС
Відображає погляд очікуванням Кінцевих
Ро з р о б н и к а користувачів/Cпоживачів.
(аналітика,
архітектора, Зовнішня:
програміста,
тестувальника) Відповідність ПС, що Надає
Визначає функціонує в модель- підгрунтя
ному чи реальному потребує
середовищі експлуатації, оцінювання
й перевірки
цільовим вимогам до неї.
Внутрішня:
Відповідність робочих Надає
продуктів похідним підгрунтя,
вимогам до них, необхідним потребує Звіт(и) про
оцінювання проблему
для зовнішньої якості ПС . й перевірки

Аналіз результатів тестування

Метрики
Метрики дефектів
процесу ПРОЦЕСИ ПЕРЕВІРКИ
тестування
ПРОЦЕСИ ТЕСТУВАННЯ

Проектування і Системна інтеграція і Функціонування в

реалізація ПС тестування середовищі експлуатації

Рисунок 11.2 – Взаємозв’язок категорій внутрішньої, зовнішньої та експлуатаційної якості

11.2.2. Поняття моделі якості програмного забезпечення
МОДЕЛЬ ЯКОСТІ ПС
Множина взаємозв'язаних (ієрархічно або ні) характеристик, які
утворюють базис для специфікації вимог до якості ПС та її оцінювання

ЗАГАЛЬНА СТРУКТУРА МОДЕЛІ ЯКОСТІ ПС

ХАРАКТЕРИСТИКА 1
ХАРАКТЕРИСТИКА k

Атрибут
(підхарактеристика) 1.1 . . . Атрибут
(підхарактеристика) k.1 . . .
Атрибут
(підхарактеристика) 1.n(1) Атрибут
(підхарактеристика) k.n(k)

Метрики атрибутів –
показники, обчислювані за даними процесів
перевірки й т е с т у в а н н я у певних шкалах
Рисунок 11.3 – Структура моделі якості програмного забезпечення
Модель якості призначена для:
 7
– визначення вимог до якості ПС (зовнішньої і внутрішньої);
– підтвердження повноти визначення вимог до якості;
– ідентифікації цілей проекту;
– ідентифікації цілей тестування;
– ідентифікації призначених для користувача критеріїв приймання завершеного програмного
продукту.
М е т р и к а – властивість робочого або кінцевого програмного продукту, значення якої визначає
міру його якості в аспекті певної підхарактеристики, належить певній шкалі і може бути однозначно
встановлене за допомогою певного методу під час огляду цього продукту, його тестування або
експлуатації.

За об’єктом вимірювання, метрики поділяють на:

– зовнішні – призначені для вимірювання зовнішньої якості, тобто ступеню відповідності продукту,
що може виконуватися в певному середовищі функціонування, встановленим(заявленим) та
передбачуваним потребам при використанні за певних умов;
– внутрішні – призначені для вимірювання внутрішньої якості, тобто ступеню відповідності робочих
продуктів похідним вимогам до них, які опосередковано забезпечують потреби у функціях кінцевого
продукту;
– метрики використання – призначені для вимірювання не властивостей самої ПС, а споживаних
результатів її експлуатації користувачами/споживачами.
Таблиця 11.1 – Застосування метрик на стадіях ЖЦ ПС
Внутрішні метрики Зовнішні метрики
Стадії підготовки пропозицій і визначення вимог до ПС
Використовуються для: Використовуються для:
 специфікації плану підвищення якості проекту і  специфікації вимог до якості з
проміжних продуктів точки зору користувача
 описи кількісних підцілей внутрішньої якості  описи кількісних цілей зовнішньої
проекту і проміжних продуктів ПС по характеристиках, якості по характеристиках, вказаних в
вказаних в моделі. моделі.
Джерела даних: потреби користувачів, опис Джерела даних: потреби користувачів,
пропозицій, специфікації вимог опис пропозицій, специфікації вимог
Стадії проектування, кодування і автономного тестування ПС
Використовуються для: Використовуються для:
 оцінювання досягнутого рівня реалізації плану  передбачення якості при
підвищення якості по характеристиках, вказаних в моделі використанні (експлуатаційної якості)
 виявлення відхилень від підцілей внутрішньої якості Джерела даних: результати аналізу
 передбачення значень зовнішніх метрик і сценаріїв використання ПС, виконуваних
зовнішньої якості прототипів застосунків та звіти про
Джерела даних: результати оглядів, статичного аналізу результати тестування
і вимірів специфікацій, проекту, коду і ін.
Стадії інтеграції, системного тестування, інсталяції, приймання ПС
Використовуються для: Використовуються для:
 оцінювання досягнутого рівня реалізації плану  представлення характеристик
підвищення якості проекту і проміжних продуктів якості ПС, визначених в моделі
 підтвердження того, що досягнута
якість задовольняє користувача
 передбачення експлуатаційної
Джерела даних: результати оглядів, статичного якості
аналізу і вимірів специфікацій, проекту, програмного коду Джерела даних: сценарії
тощо. використання ПС при тестуванні і
експлуатації, а також спільно з іншими
програмними системами
Стадія експлуатації ПС
Використовуються для: Використовуються для:
 дослідження взаємозв'язку внутрішніх і зовнішніх  представлення характеристик
метрик експлуатаційної якості ПС, визначених в
 8
Внутрішні метрики Зовнішні метрики
моделі
 підтвердження того, що наявний
рівень якості все ще задовольняє
Джерела даних: результати оглядів, статичного аналізу реальні потреби користувача
і вимірів специфікацій, проекту, програмної коди і ін. Джерела даних: сценарії використання
ПС і сценарії її поведінки в ході
експлуатації, звіти про претензії
користувачів
Рівень визначення вимог до експлуатаційної, зовнішньої і внутрішньої якості, множина і тип об'єктів
виміру і вимірюваних атрибутів, вибір експлуатаційних, зовнішніх і внутрішніх метрик для них , а також
порядок використання процедур вимірювання і оцінювання якості залежить від стадії ЖЦ ПС .
Взаємозв’язки метрик на стадіях ЖЦ ПС показано на рис. 11.4
Определение
потребностей в
ПС и подготов ка Функциониров ание
предложений
отражает
Эксплуа-
Потребности Метрики
Реальный мир тацион-
пользов ате- эксплуатаци-
(реальные услов ия ное
лей онного
применения ПС) качеств о
качества

Спецификация
определяют показыв ает Системная
требов аний к ПС
интеграция и
тестиров ание
отражает
Поведение
Требов ания
системы Внешнее Внешние
к в нешнему
(в нешние атрибуты качеств о метрики
качеств у
ПС)

Проектиров ание
определяют
и реализация ПС показыв ает
Проектиров ание
и реализация ПС
отражает
Внутренние Требов ания
атрибуты ПС Внутрен-
к в нутрен- Внутренние
нее
нему метрики
качеств о
качеств у

Рисунок 11.4 – Взаємозв’язок метрик на стадіях ЖЦ ПС

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

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

менеджерам оцінювати й прогнозувати якість якість проміжних і кінцевих продуктів ПС безпосередньо за
їх властивостями, без виконання на комп’ютері.
Розробляються з метою:
– демонстрації якості не виконуваних на комп’ютері продуктів за характеристиками и
підхарактеристиками з моделі якості на ранніх стадіях ЖЦ ПС;
– надання підстав при плануванні та вдосконаленні процесів, об’єктами яких є не виконувані на
комп’ютері продукти;
– верифікації того, что проміжні й кінцеві продукти задовольняють планованим вимогам до
внутрішньої якості ПС;
– прогнозування зовнішніх метрик якості.
11.2.3. Базові моделі якості програмного забезпечення
 9
Наразі найбільш широко застосовують дві стандартизовані ISO/IEC рамкові моделі, що являють
собою також і «стандарти де факто»:
1) еталонна, або рамкова (reference), модель якості ПО, зафіксована в наборі стандартів ISO/IEC
9126 і відповідних ДСТУ;
2) модель якості ПС/програмного продукту та модель якості під час застосування, зафіксовані в
стандарті ISO/IEC 25010 «Systems and software engineering – Systems and software Quality Requirements
and Evaluation (SQuaRE) – System and software quality models» і гармонізованому з ним ДСТУ ISO/IEC
25010.
ISO/IEC 25010 є складником новітнього Сімейства стандартів 250XX «Вимоги та оцінювання якості
систем і програмних засобів» (SQuaRE), яке наразі запроваджується ISO/IEC на заміну набору
стандартів ISO/IEC 9126.
Традиційна рамкова модель ISO/IEC 9126 визначає:
1) шість основних характеристик зовнішньої та внутрішньої якості ПС (див. рис. 11.5, 11.6, табл..11.2);
2) чотири характеристики експлуатаційної якості (див. рис. 11.6, 11.7). Кожна характеристика
уточнюється за допомогою спеціального набору під-характеристик і метрик, або вимірів за згідно з
ISO/IEC 25010, – властивостей ПС, вимірних за певною шкалою (насамперед, абсолютною, інтервалів іа
порядку).
Функціональність
Функціональна
придатність
Здатність до взаємодії
Захищеність
Точність
Відповідність
Переносність стандартам
Адаптовність Надійність
Зручність встановлення Завершеність
Задтність Відновлюваність
до співіснування
Замінна здатність Відмовостійкість
Відповідність Відповідність стандартам
стандартам
Якість
Супроводженність ПС Зручність
Аналізовність використання
Змінність Зрозумілість
Стабільність Вивченність
Тестопридатність Притягальність
Відповідність Зручність оперування
стандартам (керівність)
Відповідність
стандартам
Ефективність
Часова ефективність
(реактивність)
Використовність ресурсів

Рисунок 11.5 – Характеристики та під-характеристики внутрішньої й зовнішньої якості за ISO/IEC 9126

 10
МОДЕЛЬ ЯКОСТІ ПС ЗА ISO/IEC 9126-1:2001, ДСТУ 2844-94
Оцінювані Кінцевим користувачем/Споживачем характеристики якості у використанні

Результативність Продуктивність Безпечність Задоволеність

(effectiveness) (productivity) функціювання (satisfaction)
(safety)

Метрики завершеності

Щільність Імовірність Задоволеність

дефектів безвідмовної роботи надійною роботою

2. Відновлюваність 1. Завершеність 3. Відмовостійкість

(recoverability) (maturity) (fault tolerance) Переносність
(portability)
Зручність Ефективність Супроводженність
Функціональність Надійність застосування (efficiency) (maintainability)
(functionality) (reliability) (usability)

Забезпечувані Розробником характеристики внутрішньої й зовнішньої якості

ЗМІСТ ХАРАКТЕРИСТИК ВНУТРІШНЬОЇ ТА ЗОВНІШНЬОЇ ЯКОСТІ ПС

Фу н к ціон а л ьн іс ть — чи робить застосунок те, що від нього

вимагається
Н а дійн іс ть — чи працює застосунок без збоїв, «зависань» або виклику
виключень
Еф е к тивн іс ть — чи працює застосунок з прийнятною швидкістю при
доступі до нього багатьох користувачів
З ру чн іс ть з а с тос у ва н н я - чи є застосунок легко зрозумілим, освоюваним,
зручним і привабливим для користувачів/споживачів
С у п роводжу ва н іс ть – чи легко застосунок модифікується (коректується,
вдосконалюється, адаптується до змін вимог та середовища виконання)
Пе ре н ос н іс ть – чи придатний застосунок для перенесення з одного
середовища до іншого

ЗМІСТ ХАРАКТЕРИСТИК ЯКОСТІ ПС У ВИКОРИСТАННІ

Ре з у л ьта тивн іс ть – чи дозволяє ПС досягти задані цілі користувачів з
точності й повноти розв’язання їхніх задач у встановленому контексті її
використання
Проду к тивн іс ть – чи прийнятні витрати ресурсів на розв’язання цих задач
Бе з п е чн іс ть – чи можливий збиток (матеріальний й моральний), тобто
шкода здоров'ю людей, бізнесу, майну, навколишньому середовищу при
використанні ПС у встановленому контексті
З а довол е н іс ть – чи користувачі ПС задоволені нею в певному контексті
її використання

Рисунок 11.6 – Характеристики, під характеристики та метрики у рамковій моделі якості

Таблиця 11.2 – Під-характеристики характеристик якості ПС за ДСТУ ISO/IEC 9126
№ Під-характеристика Визначення
1 Під-характеристики функціональності
1.1 Функціональна Властивості ПС, що обумовлюють її здатність надавати належну множину
придатність функцій
 11
№ Під-характеристика Визначення
(suitability) для вирішення специфікованих завдань і досягнення цілей користувача
1.2 Точність Властивості ПС, що обумовлюють її здатність забезпечувати правильні або
(accuracy) погоджені
результати або дії з необхідною мірою точності
1.3 Здатність до Властивості ПС, що обумовлюють її здатність взаємодіяти з однією або
взаємодії більш
(interoperability) специфікованими системами
1.4 Захищеність Властивості ПС, що обумовлюють її здатність забезпечувати захист
(security) інформації
від несанкціонованого доступу осіб або систем на читання і модифікацію
та її доступність для осіб і систем, що мають права доступу
2 Під-характеристики надійності
2.1 Завершеність Властивості ПС, що обумовлюють її здатність уникнути відмови через
(maturity) дефектів, що містяться в ній
2.2 Відмовостійкість Властивості ПС, що обумовлюють її здатність підтримувати встановлений
(fault tolerance) рівень функціонування в умовах прояву дефектів в ПС, помилок в даних
або порушень специфікованого інтерфейсу
2.3 Відновність Властивості ПС, що обумовлюють її здатність відновлювати
(recoverability) функціонування на заданому рівні і відновлювати пошкоджені програми і
дані
3 Під-характеристики зручності використання
3.1 Зрозумілість Властивості ПС, що забезпечують користувачеві можливості зрозуміти, чи
(understandability) дійсно вона може задовольнити його потреби, як вона може
використовуватися для вирішення певних завдань і які умови її
використання
3.2 Освоюваність Властивості ПС, що забезпечують користувачеві можливість освоїти
(learnability) прийоми її використання

3.3 Керованість Властивості ПС, що забезпечують користувачу можливість управляти або

(operability) контролювати її дії

3.4 Привабливість Властивості ПС, що забезпечують її привабливість для користувача

(attractiveness)
4 Під-характеристики ефективності
4.1 Реактивність Властивості ПС, що обумовлюють її здатність забезпечувати належний час
(time behaviour) відгуку (відповіді) і обробки завдань, а також рівень пропускної
спроможності при виконанні функцій у встановлених умовах використання
4.2 Використання Властивості ПС, що обумовлюють її здатність використовувати належні
ресурсів ресурси в потрібні періоди часу при виконанні своїх функцій у встановлених
(resource utilization) умовах вживання
5 Під-характеристики супроводженності
5.1 Придатність до Властивості ПС, що обумовлюють можливість діагностування її недоліків
аналізування або причин відмов, а також ідентифікації частин, які повинні
(analyzability) модифікуватися
5.2 Змінюваність Властивості ПС, що обумовлюють можливість виконання встановлених
(changeability) видів модифікації
5.3 Стабільність Властивості ПС, що обумовлюють її здатність мінімізувати несподівані
(stability) ефекти модифікацій
5.4 Тестопридат-ність Властивості ПС, що забезпечують її здатність сприяти перевірці
(testability) модифікованого ПЗ
6 Під-характеристики переносності
6.1 Здатність до Властивості ПС, що обумовлюють її здатність адаптуватися для
адаптації використання в різних специфікованих середовищах без використання дій
(adaptability) або засобів, відмінних від тих, які спеціально призначені для цих цілей
6.2 Здатність до Властивості ПС, що обумовлюють її здатність до інсталяції в
встановлення специфікованому середовищі
(installability)
6.3 Сумісність Властивості ПС, що обумовлюють її здатність співіснувати з іншими
 12
№ Під-характеристика Визначення
(coexistence) незалежними ПС в загальному середовищі, розділяючи загальні ресурси
6.4 Замінна здатність Властивості ПС, що обумовлюють її здатність використовуватися замість
(replaceability) інших специфікованих ПС в середовищі їх вживання
Окрім наведених в таблиці підхарактеристик, з кожною з шести характеристик якості пов'язана
підхарактеристика «Відповідність нормам і правилам (compliance)». Це означає, що кожна з вказаних
характеристик повинна відповідати вимогам відповідних стандартів (по забезпеченню надійності,
супроводу і ін.) для певного класу ПС

Рекомендовані для застосування приклади метрик надано в частинах стандарту

ISO/IEC 9126-2:2003. Software Engineering - Product Quality - Part 2: External Metrics.
ISO/IEC 9126-3:2003. Software Engineering - Product Quality - Part 3:Internal Metrics.
ISO/IEC 9126-4:2004. Software Engineering – Software Product Quality - Part 4: Quality In Use Metrics.

Опис метрик в стандарті виконано за єдиною схемою з вказівкою наступної інформації:

– ім'я метрики. Відповідні метрики внутрішньої і зовнішньої якості мають однакові імена;
– призначення метрики. Сформульовано у вигляді питання, на яке дає відповідь використання
метрики;
– метод використання. Містить правила отримання даних і схему їх використання в метриці;
– формула і елементи даних. Вказується формула обчислення (або формули) і пояснюються
елементи даних, що беруть участь в ній;
– інтерпретація виміряних даних. Діапазон значень і переважне значення;
– тип шкали метрики. Типи шкал - номінальна, порядкова, інтервальна, відносна або абсолютна;
– тип міри. Один з типів міри – міра розміру, часу, рахункова міра;
– вихідні дані. Джерело даних, використовуване у вимірі;
– процес ЖЦ. Вказується найменування процесу ЖЦ ПС, в якому рекомендовано використання
метрики при проведенні вимірювання;
– одержувач. Вказуються споживачі результатів вимірювання.
У свою чергу, згідно з новим ДСТУ ISO/IEC 25010:2015, Модель якості ПС/програмного продукту
поєднує вісім характеристик якості ПС/продукту: функційну придатність, рівень продуктивності,
сумісність, зручність використання, надійність, захищеність, супроводженість і мобільність
(червоним кольором позначено нові характеристики, зеленим – залишені з рамкової моделі). Кожна
характеристика складається з множини відповідних підхарактеристик (рис. 11.7 і табл. 11.3).
Якість програмного продукту / продукту, що є системою

Функційна Рівень Зручність Супровод-

придатність продуктивності Сумісність застосування Надійність Захищеність женість Мобільність

Функційна Реактивність Співіснов- Визнаність Заверше- Конфіден- Модульність Адаптовність

повнота ність відповідності ність ційність
Застосовність Повторна Інстальов-
Функційна ресурсів Взаємо- Опановність Готовність Цілісність використов- ність
коректність дійність ність
Потенційність Керовність Відмово- Неспростов- Замінність
Функційна можливостей стійкість ність Аналізов-
доцільність Захищеність ність
від помилок Відновність Обліковність
користувача Модифіков-
Автентич- ність
Естетичність ність
інтерфейсу Тестовність
користувача

Доступність

Рисунок 11.7 – Модель якості ПС/програмного продукту за ДСТУ ISO/IEC 25010:2015

Таблиця 11.3 – Характеристики і підхарактеристики моделі якості продукту за ISO/IEC 25010:2015
5. Надійність (reliability)
Ступінь, в якому система, продукт або
компонент виконує специфіковані функції у
визначених умовах протягом заданого
 13
періоду часу
Характеристика/Підхарактеристикf Завершеність
1.Функціональна придатність (functional suitability) Готовність
Ступінь, в якому ПС.продукт надають функції, які
задовольняють встановленим і здогадним потребам
під час використання за заданих умов
Функціональна повнота Відмовостійкість
Функціональна коректність Відновність
Функціональна доцільність 6.Захищеність (security)
Ступінь, в якому продукт або ПС захищає
інформацію і дані таким чином, що особи або
інші продукти чи системи мають рівень
доступу до даних, відповідний їх типам і
рівням авторизації
2.Рівень продуктивності (performance efficiency) Конфіденційність
Рівень відповідності результатів роботи з обсягом
ресурсів, використаних за заданих умов
Реактивність Цілісність
Використовність ресурсів Неспростовність
Потенційність можливостей Обліковність
3.Сумісність сумісність (compatibility) Автентичність
Ступінь, в якому продукт, ПС або компонент можуть
обмінюватися інформацією з іншими продуктами, ПС
або компонентами чи виконувати запитані функції,
спільно використовуючи одне й те саме апаратне або
програмне середовище
Співісновність 7.Супроводженність (maintainability)
Наскільки результативно і ефективно
продукт або система можуть бути
модифіковані призначеними фахівцями з
обслуговування
Взаємодійність Модульність
4.Зручність використання (usability) Повторна використовність
Ступінь, в якому продукт або система можуть
використовуватися визначеними користувачами для
досягнення вказаних цілей з результативністю,
ефективністю і задовольненністю в заданих
контекстах застосування
Визнаність відповідності Аналізовність
Опановність Модифіковність
Керовність Тестовність
Захищеність від помилок користувача 8. Мобільність (portability)
Рівень результативності й ефективності
перенесення ПС, продукту або компоненту з
одного апаратного, програмного або іншого
середовища оперування або застосування
до іншого
Естетичність інтерфейсу користувача Адаптовність
Доступність Інстальовність
Замінність
Новітня Модель якості ПП під час застосування визначає п'ять характеристик, пов'язаних з
результатами взаємодії з ПС споживача її функцій: результативність, ефективність, задоволеність,
свобода від ризику і покриття контексту (див. рис. 11.8 і табл. 11.4). Кожну характеристику можна
застосувати для різних видів діяльності зацікавлених сторін, наприклад, для взаємодії оператора або
підтримки розробника.
 14
Якість під час
застосування

Результативність Ефективність Задоволеність Свобода від Покриття

ризику контексту

Результативність Ефективність Зменшення: Повнота

Корисність
Довірчість - економічного контексту
Приємність ризику;
Гнучкість
Комфортність - ризику для
здоров’я і
безпеки;
- екологічного
ризику
Рисунок 11.8 – Модель якості під час застосування за ДСТУ ISO/IEC 25010:2015
Якість під час застосування системи характеризує вплив продукту (системи або програмного
продукту) на зацікавлені сторони. Він визначається якістю програмних засобів, апаратних засобів та
операційного середовища, а також характеристиками користувачів, задач і соціального середовища. Всі
ці чинники роблять свій внесок в якість системи під час застосування.
Таблиця 11.4 – Характеристики та підхарактеристики якості під час застосування
Результативність (effectiveness)
Cтупінь досягнення цілей
Ефективність (efficiency)
Обсяг ресурсів, витрачених в зв'язку з точністю і повнотою досягнення користувачами цілей)
Задоволеність (satisfaction)
Ступінь, в якому потреби користувача задовольняються під час використанні продукту або системи в
заданому контексті застосування)
Корисність
Довірчість
Приємність
Комфортність
Свобода від ризику (freedom from risk)
Ступінь, в якому продукт або система послаблює потенційний ризик для економічного стану, життя
людини, здоров'я або навколишнього середовища)
Зменшення економічного ризику
Зменшення ризику для здоров’я та безпеки
Зменшення екологічного ризику
Покриття контексту (context coverage)
Ступінь, в якому продукт або система можуть бути використані з результативністю, ефективністю,
свободою від ризику і задовольненністю як у специфікованих контекстах застосування, так і в
контекстах за межами початково точно специфікованих
Повнота контексту
Гнучкість

11.2.4 Альтернативні (нестандартизовані) моделі якості ПС

11.2.4.1.Ієрархічні моделі якості
1 . 1 . Мак-Колла (1977).
McCall J.A., Richards P.K., Walters G.F. Concepts and definitions of software quality // Factors in
Software Quality, NTIS. – 1977, v. 1.
Найвищий рівень утворюють три основні цільові характеристики якості ПС:
– функціональність;
– здатність до модифікування;
– здатність до адаптації і взаємодії з апаратним забезпеченням.
Вони деталізуються 11 чинниками якості, а потім – 23 критеріями якості.
 15
Для оцінювання чинників ( за бальною шкалою від 0 до 10) використовуються 20 метрик якості, що
можуть пов’язуватися з кількома чинниками:
 зручність перевірки на відповідність стандартам;
 точність управління і обчислень ;
 міра стандартності інтерфейсів;
 функціональна повнота;
 однорідність використовуваних правил проектування і документації;
 міра стандартності форматів даних;
 стійкість до помилок;
 ефективність роботи;
 розширюваність;
 широта області потенційного використання;
 незалежність від апаратної платформи
 повнота протоколювання помилок і інших подій;
 модульність;
 зручність роботи;
 захищеність;
 самодокументованість;
 простота роботи;
 незалежність від програмної платформи;
 можливість співвідношення проекту з вимогами;
 зручність навчання.
1.2. Б. Боема (1978).
Boehm B.W., J. R. Brown, H. Kaspar, M. Lipow, G. MacLeod, and M. J. Merritt. Characteristics of
Software Quality // TRW series of Software Technology. North Holland. Amsterdam. – 19711.
На третьому рівні 19 критеріїв якості, що є взаємозалежними і часто конфліктними.
Зручність інтерфейсу та здатність до адаптації віднесені до другого рівня моделі.
1.3. Р. Ваттса (1987) – розвиток моделі Мак-Колла
1.4. Дьюча і Вілліса (1988)
Abel D.E., Rout T.P. Determining and Specifying the Quality Attributes of Software Products //
Austral. Comput. J. – 1993. – V. 25. – №. 3. – P.105-111.
15 користувацьких і 27 технічних атрибутів, які можуть пов'язуватися з чинниками якості і критеріями
якості.
2.Обмеження ієрархічних моделей якості
– неоднозначність шкали для характеристик якості верхнього рівня (здатності до
взаємодії, переносності тощо);
– подібність цих характеристик до функціональних вимог;
– відсутність об’єктивних підстав для прийняття їх лінійної залежності від
підпорядкованих атрибутів та метрик;
– статичність, тобто відсутність, в переважній більшості випадків, аналітичних
залежностей між цільовими значеннями зовнішніх та внутрішніх метрик на послідовних етапах
розроблення, а також врахування ситуації конкретного програмного проекту;
– відсутність зв’язків атрибутів якості з ресурсами, необхідними для їх забезпечення.

Для опрацювання цих обмежень запропоновано низку відносно нових ієрархічних моделей.
1 . 5 . Т.Джілба (1988)
Gilb T. Principles of Software Engineering Management, Addison-Wesley.- 19811. – 442 p.
– локально адаптовна (у масштабі організації) і відкрита для поповнення;
– сполучає характеристики ресурсів з характеристиками якості;
– пов'язана з еволюційною моделлю процесу розробки;
Верхній рівень утворюють:
чотири характеристики якості – працездатність, готовність, адаптовність, зручність
використання;
 16
чотири характеристики ресурсів – час, гроші, люди та інструменти.
1 . 6 . Constructive quality model ( COQUAMO) Б.Кітченхем (1988)
B.Kitchenham Towards a constructive quality model // Software Engineering Journal July – 1987 – P.
105-113
Низка чинників якості з класичних моделей Джілба, МакКолла і Боема адаптується до особливостей
конкретного програмного проекту.
1 . 7 . Р.Дж.Дромея ( 1996)
R.G.Dromey. A model for software product quality. // IEEE Trans. On Softw. Eng. – V. 21. – N.2. – febr.
– 1995. – P. 146-162.
Призначена для поступового поглиблення розуміння взаємозв’язків між атрибутами
(характеристиками) та підпорядкованими атрибутами для визначення ознак програмного продукту
та його складників, що впливають на атрибути якості.
Побудова моделі потребує:
1) вибору множини атрибутів якості верхнього рівня, які будуть використані для оцінювання;
2) складання списку всіх компонентів або модулів системи;
3) ідентифікації визначальних властивостей кожного компонента, які найбільше впливають на
якість властивості оцінюваного програмного продукту;
4) визначити взаємозв’язки між властивостями компонентів та атрибутами якості програмного
продукту;
5) протестувати модель; та ;
6) виявити її некоректності та виправити їх (повторивши дії 1)-5)).
1 . 1 1 . Software quality in Development (SQUID) Й.Боега (1999)
Boegh J. et al. A Method for Software Quality Planning, Control and Evaluation // IEEE Software. -
march/april. - 19911. - P. 69 – 77.
Якість специфікується в термінах внутрішніх і зовнішніх характеристик (як і в 986), що
уточнюються, поки не стануть безпосередньо вимірними атрибутами.
Користувачу надається можливість визначити, яким чином внутрішні характеристики впливають
на зовнішні, пов'язуючи їх в моделі даних.
Модель може пристосовуватися до потреб окремої організації і передбачає використання власної
бази даних.
Переваги моделі:
– врахування більшості чинників, що впливають на якість ПС,
– сприяння уникненню конфліктів між різними вимогами до якості,
– можливість зазначати виміри та метрики для компонентів ПС із різними функціями
(обчислювальних, інтерфейсних, інформаційних (баз даних)) і встановлювати відповідні їм правила
виконання вимірювань.
1 . 1 1 . COnstructive QUALity MOdel (COQUALMO) Б.Боема-А.Чулані (1997)
Devani-Chulani S. Incorporating Bayessian Analysis to Improve the Accuracy of COCOMO II and its
Quality Model Extension // Univ. of South. Calif., Los Angeles, CA.- 1997.
Характеристикою якості прийнято надійність, а її метриками – кількості внесених та усунутих
дефектів в різних робочих продуктах на різних стадіях життєвого циклу ПС, які пов’язуються з оцінками
ресурсів на їх усунення.
11.2.4.2.Неієрархічні моделі якості
2 . 1 . A Software Quality Model and Metrics for Identifying Project Risks Е. Х’ятт, Л.Розенберг (1996)
(Software Assurance Technology Center, NASA)
Hyatt L., Rosenberg L. A Software Quality Model and Metrics for Identifying Project Risks and
Assessing Software Quality // 8th Annual Soft. Technology Conf., Utah, april. – 1996.
Рівень якості визначається як величина, обернена до ризику програмного проекту. Підтримується
класифікація та всебічна оцінка ризиків. Описує співвідношення між метриками якості та ризику на
послідовних стадіях проекта, надаючи можливість визначати ризик та якість для відповідних їм
робочих продуктів: документу специфікації вимог, проекту архітектури, тексту коду, проектів тестів і
тестових скриптів.
Підстава розроблення – потреба врахування і подання каузальних (причинно-наслідкових)
взаємозв'язків в проблематиці якості ПС
 17
2 . 2 . QEST (Quality Factor + Economic, Social and Technical dimensions) А.Абран, Л.Бугліоне
(1999)
Buglione L., Abran A., Geometrical and statistical Foundations of a Three-dimensional Model of
Performance // International Journal of Advanced in Engineering Software. - 30. - 19911.
Модель – тривимірна структура-оболонка, яка дозволяє одночасно подавати залежність значень
параметрів програмного продукту, що відображають три аспекти його вимірювання (три точки зору на
продукт):
1. Економічний аспект (E). Точка зору менеджерів на вартість і графік розробки (постачання)
продукту.
2. Соціальний аспект (S). Точка зору користувачів на характеристики експлуатаційної якості (якості
у використанні) продукту.
3. Технічний аспект (T). Точка зору розробників на забезпечення, вимірювання і оцінювання
досягнення вимог до якості продукту.
Три виміри моделі утворюють геометричну фігуру - правильний чотиригранник (тетраедр), сторони
якого відображають нормалізовані значення виміряних величин за кожним з вимірів, а вершина -
нормалізоване оптимальне цільове значення для кожного виміру
Схематичне подання моделі QEST для оцінювання якості ПС під час проекту
Z P

Y
Qe
Qt
.

Qs T

E .

S
X
Модель адаптована авторами для одночасного подання кількісних і некількісних (якісних) мір
програмного продукту, що розробляється, інтегрованих в єдиний (інтегральний) показник його якості,
отриманий експертною групою на основі опитування всіх зацікавлених в ньому осіб.
Вершина (P) тетраедра описує максимальний рівень якості продукту (ефективності проекту).
Сторони правильного тетраедра (піраміди) дорівнюють одиниці. Всі три виміри нормалізовано на
інтервалі {0,1}. Значення по кожному виміру є зваженими сумами списку n значень нормалізованих
коефіцієнтів, що відображають кожну з трьох точок зору експертів на продукт (номінальні оцінки). Ціі
значення відкладаються на сторонах піраміди {Qe, Qs, Qt}. Отримані точки з'єднуються лініями.
Утворюється перетин піраміди, що «відділяє» кращі і гірші оцінки якості продукту. В ході виконання
проекту формуються «реальні зрізи» ефективності проекту.
Ефективність проекту (розглядувана як якість створюваного продукту) вимірюється за допомогою
однієї з трьох величин:
– відстані від перетину до основи піраміди (чим більша відстань від поточного перетину до
основи, тим вища ефективність проекту);
– площі перетину (чим менша площа, тим вище ефективність);
– об'єму нижньої частини піраміди (xим більший об'єм під перетином, тим вища ефективність
проекту).

2 . 3 . GDQA (Graphical Dynamic Quality Assessment) А.Абраном і Н.Кецесі (2001)

Kececi N. Abran A. Analysing. Measuring and assessing software quality in a logic based graphical
model // Qualita2001 (4th International Congress on Quality and Reliability), Annecy, France, March 22-
23, 2001.
1) визначається ієрархічна модель якості ПС, що включає декомпозицію артефактів в категорії
процесів, продуктів і ресурсів проекту (аж до виділення вимірних властивостей);
2) виконується їх пріоритезація, «зважування» і нормалізація для подальшого зіставлення;
3) встановлюються взаємозв'язок чинників якості, що знаходяться на різних рівнях, оскільки багато
атрибутів якості нижнього рівня можуть вносити внесок до декількох характеристик верхнього рівня
ієрархії;
 18
4) атрибути відображаються на відповідні міри і пов'язані з ними метрики якості (у цьому підході вони
називаються функціями), а потім
5) визначаються вхідні змінні, значення яких можна встановити, аналізуючи проектні документи, код,
звіти про тестування та ін.
Приклад використання схеми GDQA для підхарактеристики «завершеність» характеристики
якості «надійність».
Çàâåðøåííîñòü
Обозначения на схеме
Непосредств енное 
измерение
Вычисление
метрики
W
W
W Взв ешив ание MX2MY2
MX3 W
 Суммиров ание
W

MX1 MX2 MY2 MX4

A4 B3 A1
B1
A2
B2
A3
B4
A5
B5

Кола на схемі вказують, для яких метрик використовуються ті або інші дані.
Таблиця 11.5 – Внутрішні метрики (функції) «завершеності» ПС, подані на схемі
Назва Позна- Формула Дані, що збираються
метрики чення Им'я Описание
Інтенсивність МХ1 МХ1= А1/B1 А1 Число помилок, виявлених при перевірці
виявлення В1 Очікуване число помилок, які будуть виявлені при перевірці
помилок при
перевірці
Кількість MX2Y2 MX2Y2 = A2 Число усунених дефектів в проекті, коді…
усунених MX2/MY2 B2 Оцінюване число дефектів, які будуть виявлені в ПС (при інс
дефектів MX2 = A2/B2 B3 Число помилок, виявлених при перевірці
MY2 = A2/B3
Щільність MX3 MX3 = (A3 - A3 Очікуване число помилок, які будуть виявлені при перевірці
дефектів, що A4) / B4 A4 Число помилок, виявлених при перевірці
залишилися B4 Оцінюваний розмір ПС
Адекватність МХ4 МХ4 = A5/B4 A5 Число тестових ситуацій в плані тестування
тестування B4 Число тестових ситуацій, які мають бути передбачені для з
тестового покриття

2.4. Probabilistic Method for early evaluation of Non-Functional Requirements (Prometheus)

Trendowicz A, Punter T. Quality modeling for software product lines – Available at http://www.empress-
itea.org/publications/EMPRESS_27.pdf
Модель розроблена в руслі ціле-орієнтованого підходу до вимірювання та оцінювання якості лінійок
програмних продуктів, який інтегрує кількісні та якісні методи моделювання. Він дозволяє:
1) виконання оцінювання, починаючи з ранніх стадій ЖЦ,
2) ефективне навчання по ходу розроблення кількох варіантів/релізів продукту,
3) уточнення моделі якості по послідовних проектах,
4) інтеграцію кількісних (заснованих на вимірюванні) і якісних методів,
5) комбінування різних контекстів індивідуальних поглядів на якість ПС (розробників,
користувачів) і оцінюваних об’єктів (процесів, продуктів, ресурсів).
 19
Підхід включає три фази: специфікацію моделі, застосування моделі для оцінювання якості
і «пакування» здобутих знань з метою накопичення досвіду по проектах щодо застосування моделі та
її уточнення.
Схема виконання кроків підходу зі специфікації моделі подана на рис. 11.9.

Перша фаза
ПрО, вимоги Визначення цілей якості
користувача (вимог)

Еталонні моделі, Специфікація

запитальники характеристик якості

Досвід, емпіричні Специфікація

аналізи взаємозв’язків
Неприйнятна
Друга
Погляди на якість, Перегляд моделі фаза
системні артефакти
Прийнятна
Операціоналізація
Метрики
(квантифікація) моделі

Третя фаза

Користувач Зацікавлені особи, експерти у ПрО Експерти у ПрО

Рисунок 11.9 – Послідовність специфікування моделі якості за підходом Prometheus

Цільові вимоги до якості СПС визначаються і специфікуються із застосуванням методології
вимірювання «Ціль-питання-метрика» (Н.Фентон).
Вони уточнюються згідно з переліком вимірюваних характеристик і підхарактеристик оцінюваних
програмних об’єктів сімейства. Потім встановлюються взаємозв’язки між характеристиками
(підхарактеристиками) та вимірами.
Розрізнюють два типи зв’язків:
– декомпозицію характеристик (згори – донизу)
– та вплив рівня (значення) однієї характеристики на значення іншої.
Для розробленої моделі перевіряється її реалізовність. Спочатку досягається консенсус усіх
зацікавлених сторін – споживачів вимірювань – стосовно структури і складу моделі, потім визначаються
практичні можливості і ресурси збирання даних для обчислення значень за метриками в моделі. Задля
досягнення компромісу між трудовитратами на застосування моделі та практичною цінністю її
використання модель може бути спрощена. Оцінюється відносна важливість характеристик, після чого в
моделі залишаються тільки найбільш впливові й легкі у вимірюванні характеристики. Насамкінець,
виконується квантифікація моделі – «наповнення» даними (вихідними значеннями) характеристик і
зв’язків для застосування метрик.
Метрики можуть мати не тільки кількісне, але й якісне (інтуїтивне, експертне) подання (з
використанням порядкової шкали, наприклад, рівень значень «дуже високий», «високий», «середній»,
«низький», «дуже низький»). Для квантифікації зв’язків (впливів), а також комбінування кількісних і якісних
даних застосовуються байєсівські мережі.
11.3 Рамковий процес оцінювання якості ПП
Призначення процесу оцінювання програмного продукту:
– гарантувати шляхом систематичного вимірювання і оцінювання, що продукт задовольняє
встановленим і передбачуваним вимогам користувачів до цього продукту.
В результаті успішного виконання процесу мають бути:
 встановлені вимоги, що стосуються проведення оцінювання;
 визначені критерії оцінювання продукту;
 специфіковані методи виконання оцінювання, і всі дії в рамках цих методів належним чином
виконуватимуться;
 дані вимірів збиратимуться, а результати використання метрик - оцінюватися по відношенню до
критеріїв;
 результати діяльності по оцінюванню продукту будуть доступні для всіх зацікавлених сторін».
Об’єкти оцінювання: проміжні (робочі) продукти ПС в ході розробки та кінцевий програмний
продукт.
 20
Цілі оцінювання якості робочих продуктів:
 прийняття рішення про приймання проміжного продукту у співвиконавця;
 прийняття рішення про завершення якого-небудь процесу і передачі продукту наступному
процесу;
 прогнозування, попередня оцінка якості кінцевого продукту;
 збір інформації про проміжні продукти з метою контролю і управління процесом розробки ПС.
Основні цілі оцінювання якості кінцевого продукту:
 прийняття рішення про приймання продукту;
 прийняття рішення про терміни випуску продукту;
 порівняння продукту з іншими продуктами;
 вибір продукту серед альтернативних продуктів;
 оцінка результату використання продукту (як позитивного, так і негативного).
Як показано на рис. 11.10, Процес оцінювання якості програмного продукту охоплює входи та
підсумкові результати, обмеження й ресурси для оцінювання якості й передбачає п’ять етапів,
реалізація яких визначається цілями й умовами оцінювання (рис. 11.11).
11.4 Засоби забезпечення якості у процесі розроблення (Orlov_PI.pdf, розд 20, с. 603-618)
11.5 Модуль ПС як термінальний об’єкт забезпечення якості. Показники зв’язності та
зчеплення
Orlov_PI.pdf, розд.6, с.167-182;
11.6 Склад, типізація та призначення метрик об’єктно-орієнтованих ПС
Orlov_PI.pdf, розд.12, с. 350-383;
Кучеров_Артамонов_ІПЗ_2017.pdf, розд. 14
romanov_PI.pdf, підрозділ 2.4, с.123-137.
 21

Обмеження щодо Встановлення вимог до оцінювання

оцінювання 1. Встановлення призначення оцінювання
Вхідні дані
для оцінювання 2. Отримання вимог до якості програмного продукту

Потреби 3. Встановлення складників продукту для включення в оціню

в оцінюванні
Підсумкові 4. Визначення жорсткості оцінювання
результати
Процес оцінювання
Статичний оцінювання
продукт Специфікування оцінювання
Звіт про
оцінювання 1. Добір вимірів якості (модулів оцінювання)
2. Визначення критеріїв рішення для вимірів якості
Динамічний
продукт 3. Визначення критеріїв рішення для оцінювання

Ресурси
для оцінювання
Проектування оцінювання
1. Планування діяльності з оцінювання

Виконання оцінювання
1. Здійснення вимірювань
2. Застосування критеріїв рішення для вимірів якості
3. Застосування критеріїв рішення для оцінювання

Завершення оцінювання
1. Огляд результату оцінювання
2. Створення звіту про оцінювання
3. Огляд оцінювання якості та забезпечення зворотного зв'яз
з організацією
4. Виконання розподілу даних оцінювання

Рисунок 11.10 – Процес оцінювання якості програмного продукту


Попередньо відібрати продукти і постачальників на
підставі зворотного зв'язку з користувачами продукту,
огляду документації продукту і навчальних курсів,
оглядів літератури та пробного застосування продукту.
Підготувати вимоги до програмного продукту
і до набування та оприлюднити запит
стосовно пропозиції/тендера.
Оцінити постачальників на підставі
системи якості, процесу конструювання
програмного забезпечення, процесу
обслуговування програмного
забезпечення та спроможності
Оцінити програмні продукти на підставі
результатів зовнішнього оцінювання,
документаціїпродукту, досвіду
експлуатації продукту, прототипів
продукту, інших методів
оцінювання продукту.
Відібрати продукт і постачальника
та скласти договір
Виконати тестування прийнятності
та прийняти/відкинути продукт
Виконати довільне
додаткове оцінювання
Приєднати продукт до більшої
системи або використовувати
автономно
а) Придбання готового продукту
Рисунок 11.11 – Приклади реалізації процесу оцінювання
22
Оприлюднити запит стосовно інформації
Попередньо відібрати постачальника на підставі
зворотного зв'язку з іншим споживачем,
системи якості, процесу конструювання/обслуговування
програмного забезпечення та спроможності
Підготувати вимоги до програмного засобу
і до набування.
І оприлюднити запит стосовно
пропозиції/тендерної угоди
Оцінити постачальників на підставі
формального оцінювання системи якості,
процесу конструювання програмного забезпечення
та спроможності
Відібрати постачальника
Специфікувати вимоги до плану забезпечення якості
постачальника, процесу розроблення програмного
забезпечення, процесів верифікації й валідації,
процесів спільного перегляду й аудиту та до
продуктів поставки
Укласти договір з урахуванням яких-небудь програмних
продуктів, що мають змінюватися (за потреби)
Управляти виконанням договору з боку постачальника
та відстежувати його на підставі плану якості
постачальника
Виконати приймальні випробування
та прийняти/відкинути постачання
замовного/зміненого програмного продукту
Виконати довільне
додаткове оцінювання
Приєднати продукт до більшої
системи або використовувати
автономно
б) Придбання продукту шляхом його замовлення