42. Класична ітераційна модель.

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

завдання проходять усі етапи без яких або ітерацій - повернень на попередні кроки

технологічного процесу. При програмуванні, наприклад, може виявитися, що реалізація

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

продуктивністю. В цьому випадку вимагається те, що перепроектувало, а може бути і

переробка специфікацій. При розробці великих нетрадиційних систем необхідність в

ітераціях виникає регулярно на будь-якому етапі життєвого циклу як із-за допущених на

попередніх кроках помилок і неточностей, так і із-за змін зовнішніх вимог до умов

експлуатації системи. Такі мотиви класичної ітераційної моделі життєвого циклу (див. рис.

2.3). Класична ітераційна модель абсолютизує можливість повернень на попередні етапи.

Проте ця обставина відбиває істотний непереборний аспект програмних розробок, що не

спираються на объектно-ориенти-ро-ван-ное проектування. Всі традиційні технології

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

міняється: при поверненні завжди доводиться повторювати побудову того, що вже вважалося

готовим. Інше положення з об'єктно-орієнтованими технологіями. Як вже відзначалося,

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

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

переробки старого при поверненнях. По суті, класична схема залишається вірною, але тільки

у рамках однієї ітерації і з однією важливою поправкою: усе корисне, що було зроблено

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

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

КОСЯК

43. Каскадна модель.

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

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

На етапі попереднього (ескізного) проектування виробляються вимоги до апаратних засобів і програмного забезпечення, розробляється архітектура програми.

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

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

Далі окремі програми інтегруються і тестуються у вигляді цілісної системи.

Потім ПС супроводжується документами і передається в експлуатацію.

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

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

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