ЖИТТЄВИЙ ЦИКЛ ПВ.

МОДЕЛІ
ЖЦ
1 Визначення ЖЦ згідно з ДСТУ. Стадії
створення ЖЦ ПЗ.
2 Основні моделі ЖЦ. Загальні
характеристики
3 Стандарти життєвого циклу ПЗ
4 Класичний життєвий цикл
5 Інкрементна модель
 Визначення ЖЦ з
• Створення — це тривалий, трудомісткий та динамічний процес
підготовки рішень з усіх питань, пов'язаних з реєстрацією,
передаванням, обробкою та використанням даних, розробкою
відповідної документації, в якій на різних стадіях і етапах беруть
участь спеціалісти різних спеціальностей та кваліфікації.
Життєвий цикл інформаційної системи — це сукупність стадій
та етапів, які проходить інформаційна система в своєму роз-
витку з часу прийняття рішення про початок удосконалення
системи управління до моменту, коли вона припиняє своє
існування (перестає функціонувати).
• Згідно з ДСТУ 2941—94 (Системи обробки інформації.
Розроблення систем. Терміни і визначення)
• Життєвий цикл інформаційної системи — це весь період
існування системи від початку розроблення до закінчення її
використання та утилізації комплексу засобів її
автоматизації.
• Економічний об'єкт проходить три стани: початковий, цільовий і
кінцевий.
Початковий стан є моментом виникнення задуму
(ідеї), або початком фінансування створення ПЗ.
Цільовий стан пов'язується з початком
фінансування, тобто виконання об'єктом свого при-
значення, а кінцевий — припиненням його
діяльності у зв'язку з фізичним або моральним
старінням, зміни чи перетворення його на якісно
новий об'єкт.
Стадії створення ПЗ — одна з частин процесу
створення ПЗ, який встановлено нормативними
документами та закінчується випуском
документації на ПЗ (ця документація містить опис
повної, в межах заданих вимог, моделі ПЗ на
заданому для даної стадії рівні)
Аналіз вітчизняного та зарубіжного досвіду
показує, що життєвий цикл поділяється так:
• передпроектна, проектна стадії та
введення в дію;
• передпроектне обстеження;
• створення технічного і завдання;
• розробка концептуального проекту;
• створення логічного проекту;
• створення програмного продукту;
• впровадження, функціонування,
супроводження та модернізація.
Результати, одержані на попередніх стадіях, є
підставою для виконання робіт на наступних.

Рис.1. Життєвий цикл проектування ПЗ

 Визначення основних понять ЖЦ ПВ
Життєвий цикл програмного виробу —
проміжок часу від моменту виникнення
об'єктивної необхідності у програмному вирoбі
до моменту вилучення його з експлуатації.

Модель життевого циклу ПВ — схема сукупності

взаємопов'язаних прoцесів створення та
послідовного перетворення стану ПВ від
формування вимог до нього до завершення його
експлуатації.
 Моделі ЖЦ ПВ
Кустарна (традиційна) модель ЖЦ ПВ — процеси
кодування та нала-годження програми є початковими у
послідовності робіт, після чого вико- нується доведення ії
до вимог користувача.
Каскадна модель ЖЦ ПВ — передбачає перехід на
наступний етап nicля повного завершення робіт
попереднього.
Поетапна модель ЖЦ ПВ з проміжним контролем —
ітераційний процес розробки програми iз циклами
зворотного зв'язку між етапами.
Спіральна модель ЖЦ ПВ — кожний виток (крок
розробки) відповідає поетапній моделі створення
фрагмента або вepciї ПВ.
СASE-модель ЖЦ ПВ — передбачає використання засобів
автоматизації на кожному етапі, у тому числі i на етапах
аналізу та проектування, що докорінно змінюе їх зміст.
 Класичний життєвий цикл
Найстаршою моделью процесу розробки ПО є
класичний життєвий цикл (автор Уинстон Ройс,
1970)
Дуже часто класичний життєвий цикл називають
каскадною чи водоспадною моделлю,
підкреслюючи, що розробка розглядається як
послідовність етапів, причому перехід на
наступний, ієрархічно нижній етап відбувається
тільки після повного завершення робіт на
поточному етапі
Класичний ЖЦ ПВ
 Зміст основних етапів
• Системний аналіз задає роль кожного елемента в
комп'ютерній системі, взаємодія елементів один з
одним. Оскільки ПЗ є лише частиною великої системи,
то аналіз починається з визначення вимог до всіх
системних елементів і призначення підмножини цих
вимог програмному «елементу». Необхідність
системного підходу явно виявляється, коли формується
інтерфейс ПЗ з іншими елементами (апаратурою,
людьми, базами даних). На цьому ж етапі починається
рішення задачі планування проекту ПЗ. У ході
планування проекту визначаються обсяг проектних
робіт і їхній ризик, необхідні трудозатраты,
формуються робочі задачі і план-графік робіт.
• Аналіз вимог відноситься до програмного
елемента — програмному забезпеченню.
Уточнюються і деталізуються його функції,
характеристики й інтерфейс.
• Усі визначення документуються в
специфікації аналізу. Тут же завершується
рішення задачі планування проекта.
Проектування складається в створенні представлень:
• архітектури ПЗ;
• модульної структури ПЗ;
• алгоритмічної структури ПЗ;
• структури даних;
• вхідного і вихідного інтерфейсу (вхідних і вихідних
форм даних).
Вихідні дані для проектування містяться в специфікації
аналізу, тобто в ході проектування виконується
трансляція вимог до ПЗ в безліч проектних
представлень. При рішенні задач проектування
основна увага приділяється якості майбутнього
програмного продукту.
• Кодування складається в перекладі результатів
проектування в текст мовою програмування.
• Тестування — виконання програми для виявлення
дефектів у функціях, логіку і формі реалізації
програмного продукту.
• Супровід — це внесення змін в експлуатоване ПО.
Мети змін :
• виправлення помилок;
• адаптація до змін зовнішньої для ПО середовища;
• удосконалення ПО по вимогах замовника.
•
Супровід ПО складається в повторному застосуванні
кожного з попередніх кроків (етапів) життєвого циклу до
існуючого ПЗ, але не в розробці нового ПЗ.
 Переваги і недоліки класичного ЖЦ
Як і будь-яка інженерна схема, класичний життєвий
цикл має переваги і недоліки.
Переваги класичного життєвого циклу: дає план і
часовий графік по всіх етапах проекту, упорядковує хід
конструювання.
Недоліки класичного життєвого циклу:
• реальні проекти часто вимагають відхилення від
стандартної послідовноти кроків;
• цикл заснований на точному формулюванні
вихідних вимог до ПО (реально на початку проекту
вимоги замовника визначені лише частково);
• результати проекту доступні замовнику тільки
наприкінці роботи.
 Інкрементна модель розробки ПЗ
• Інкрементна ( поступальна) модель розробки
• Один з ключових питань розробки програмного
забезпечення - як впоратися зі змінами, оскільки в разі
великомасштабних програмних проектів наявність
змін неминуча. Підприємництво змінюється, що веде
до зміни вимог, створюються нові технології, які
доцільно застосовувати для удосконалення
програмних систем, і змінюються самі платформи, для
яких створювалися системи. Зазначені зміни
вимагають переробки та вимагають, як повторного
аналізу вимог разом з впровадженням, так і
реалізацію нових функціональних
можливостей. Вартість змін повинна бути настільки
низькою, наскільки це можливо.
. Зміни найкраще робити тоді, коли їх
внесення в ПЗ по можливості дешевше. На
підставі цього, мають резон поступові
(інкрементальні) розробки і передача
продукту. Таким чином, зміни можна вносити
в тих частинах, які ще не почали розробляти.
Інкрементна розробка - це поетапна з
наступними часовими графіками стратегія, в
якій різні частини системи розробляються в
різний час і різними темпами, і якщо одна
частина готова, тоді її інтегрують в систему.
Згідно Яну Соммервілла (Ian Sommerville) «ітеративна
модель розробки» швидше загальна назва для ряду
так званих гібридних моделей (в тому числі, і
Інкрементальний і спіральна моделі). Слово
«ітеративний» наголошує на тому, що дії в цій моделі
повторюються.
Інкрементнийпідхід до розробки може бути як
плановий, так і гнучкій. Модель забезпечує побудову
спочатку невеликої частини системи з подальшим її
розширенням в кілька етапів. Поетапний підхід
дозволяє розробникам і майбутнім користувачам
системи вчитися, починаючи з ранніх ітерацій,
отримувати зворотний зв'язок ще тоді, коли можливо
зробити зміни, наприклад, в архітектурі системи, без
перепису всього коду.
Рис. Інкрементна стратегія
На початку роботи над проектом визначаються всі
основні вимоги до системи, після чого виконується її
розробка у вигляді послідовності версій. При цьому
кожна версія є закінченим і працездатним
продуктом. Перша версія реалізує частину
запланованих можливостей, наступна версія реалізує
додаткові можливості і т. д., Поки не буде отримана
повна система.
Дана модель життєвого циклу характерна при
розробці складних і комплексних систем, для яких є
чітке бачення (як з боку замовника, так і з боку
розробника) того, що собою має представляти
кінцевий результат (інформаційна система).
 Переваги інкрементної (поетапної) розробки
1. Витрати, які виходять в зв'язку зі зміною вимог
користувачів, зменшуються, повторний аналіз і сукупність
документації значно скорочуються в порівнянні з
Водоспадної (каскадної) моделлю.

2. Легше отримати відгуки від клієнта про виконану

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

3. У клієнта є можливість швидко отримати і освоїти

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

2. Структура системи має тенденцію до погіршення

при додаванні нових компонентів (частин) -
постійні зміни порушують структуру системи. Щоб
уникнути цього і підвищити якість програмного
забезпечення потрібен додатковий час і гроші на
рефакторинг. Погана структура робить програмне
забезпечення складним і дорогим для подальших
змін.
ЛІТЕРАТУРА:
1. С. А. Орлов Технология разработки
программного обеспечения. Разработка
сложных программных систем. Питер 2003 г.
2. С. А. Орлов Програмная инженерия Питер
2016 г.

Вивчити:
1. Методики системного тестування програмних
систем.

Опрацювати *1+ Глава 1, *2+ Глава 1