Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Посибник ІСТОА.doc
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
2.45 Mб
Скачать

4.7. Моделі жц аіс і відповідного пз

Під моделлю ЖЦ АІС розуміють структуру, що визначає послідовність виконання і взаємозв'язки процесів, дій і задач протягом ЖЦ. Модель ЖЦ залежить від специфіки, масштабу, складності проекту і специфіки умов, у яких система створюйся й функціонує.

Стандарт ISO/EEC 12207 не пропонує конкретну модель ЖЦ і методи розроблення АІС та її ПЗ. Його положення є загальними для будь-яких моделей ЖЦ, методів і технологій проектування АІС і розроблення ПЗ. Стандарт описує структуру процесів ЖЦ, але не конкретизує в деталях, як реалізувати або виконати дії і задачі, включені в ці процеси.

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

  • каскадна модель (1970 -1985 pp.)

  • і спіральна модель (1986 -1990 рр.).

В

4.7.1. Каскадна модель жц

однорідних АІС 1970—80-х pp. прикладне ПЗ являло собою одне ціле. Для розроблення такого типу ПЗ застосовувався каскадний підхід (інша назва - водоспад (waterfall)). Принциповою особливістю каскадного підходу є перехід на наступну стадію здійснюється тільки після того, як буде цілком виконано роботу на поточній стадії, і повернень на пройдені стадії не передбачається. Кожна стадія закінчується одержанням деяких результатів, що стають вихідними даними для наступної стадії.

Вимоги до розроблюваної АІС, визначені на стадії формування вимог, строго документуються у вигляді технічного завдання й фіксуються на весь час розроблення проекту.

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

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

Переваги застосування каскадного способу полягають ось у чому:

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

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

Каскадний підхід добре зарекомендував себе під час побудови АІС, для яких на самому початку розроблення можна досить точно й повно сформулювати усі вимоги для того, щоб надати можливість розробникам якнайкраще реалізувати їх. У цю категорію підпадають складні системи з великою кількістю задач обчислювального характеру, системи реального часу тощо.

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

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

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

  • користувачі не можуть відразу викласти всі свої вимоги і передбачати, як вони зміняться в процесі розроблення;

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

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

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