Поняття життєвого циклу програмного забезпечення (ЖЦ ПЗ) є одним з базових у програмній інженерії. Життя-ний цикл програмного забезпечення визначає-ся як період часу, який починається з моменту прийняття ре-шення про необхідність створення ПЗ і закінчується в момент його повного вилучення з експлуатації.
Під моделлю Ж Ц ПО розуміється структура, визначаються-ющая послідовність виконання і взаємозв'язку процесів, дей-тей і завдань протягом ЖЦ. Модель ЖЦ залежить від специфіки, масштабу і складності проекту і специфіки умов, в яких система створюється і функціонує.
Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Його положення є загальними для лю-Бих моделей ЖЦ, методів і технологій розробки ПЗ. Стандарт описує структуру процесів ЖЦ ПО, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, вклю-нені в ці процеси.
Модель ЖЦ будь-якого конкретного ПО ЕІС визначає характер процесу його створення, який являє собою сукупність упорядкованих у часі, взаємопов'язаних і об'єднаних в стадії робіт, виконання яких необхідне і досить для створення ПЗ, відповідного заданим вимогам.
В однорідних ЕІС 70-х і 80-х рр. прикладне ПО являло собою єдине ціле. Для розробки такого типу ПО застосовувався каскадний підхід (інша назва - водоспад (waterfall)) (рис. 1.3). Принциповою особливістю каскадного підходу є сліду-ющее: перехід на наступну стадію здійснюється тільки після того, як буде повністю завершена робота на поточному стадії, і повернень на пройдені стадії не передбачено. Кожна ста-дія закінчується отриманням деяких результатів, які слу-жать в якості вихідних даних для наступної стадії. Вимоги до розробляється ПО, певні на стадії формування вимог, строго документуються у вигляді технічного завдання і фіксуються на весь час розробки проекту. Кожна стадія за-вершается випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників. Критерієм якості розробки при такому підході є точність виконання специфікацій технічного завдання.
1.3 Каскадна схема розробки ПЗ 1.4 Реальний процес
При цьому основна увага розробників зосереджується на досягненні оптимальних значень технічних характеристик раз-ється ПО: продуктивності, обсягу займаної пам'я-ти та ін.
Переваги застосування каскадного способу укладаючи-ються в наступному:
на кожній стадії формується закінчений набір проектної документації, який відповідає критеріям повноти і узгоджено-сті;
виконувані в логічній послідовності стадії робіт по-зволяют планувати терміни завершення всіх робіт і відповідними-ющие витрати.
У той же час цей підхід має ряд недоліків, викликаних перш за все тим, що реальний процес створення ПЗ ніколи повністю не вкладався в таку жорстку схему. Процес створення ПО носить, як правило, ітераційний характер: результа-ти черговий стадії часто викликають зміни в проектних рі-пах, вироблених на більш ранніх стадіях. Таким чином, по-стійно виникає потреба в поверненні до попередніх стадій і уточнення або перегляд раніше прийнятих рішень. В результаті реальний процес створення ПЗ приймає інший вигляд (рис. 1.4).
Зображену на рис. 1.4 схему часто відносять до окремої моделі, так званої моделі з проміжним контролем. в якій межстадійние коригування забезпечують більшу надійність за порівняй-нію з каскадної моделлю, хоча і збільшують весь період розробки.
Основним недоліком каскадного підходу є суще-ного запізнення з отриманням результатів і, як наслідок, досить високий ризик створення системи, що не задовольняє умов, що змінилися потребам користувачів. Практика показуючи-ет, що на початковій стадії проекту повністю і точно сформу-лювати всі вимоги до майбутньої системи не вдається. Це пояс-вується двома причинами: 1) користувачі не в змозі відразу викласти всі свої вимоги і не можуть передбачити, як вони зміняться в ході розробки; 2) за час розробки можуть про-ізойті зміни у зовнішньому середовищі, які вплинуть на требо-вання до системи. В рамках каскадного підходу вимоги до ЕІС фіксуються у вигляді технічного завдання на весь час її ство-ня, а узгодження отриманих результатів з користувачами проводиться тільки в точках, планованих після завершення кожної стадії (при цьому можливе корегування результатів по зауваженнях користувачів, якщо вони не зачіпають вимоги, викладені в технічному завданні). Таким чином, пользовате-ли можуть внести суттєві зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточності-ного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ користувачі отримують систему, не задовольняє їх потребам. В результаті доводиться починати новий проект, який може спіткати така ж доля.
Для подолання перелічених проблем в середині 80-х рр. була запропонована спіральна модель ЖЦ (рис. 1.5).
Її принциповою особливістю є наступне: прикладне ПО створює-ся не відразу, як в разі каскадного підходу, а по частинах з вико-ристанням методу прототипування. Під прототипом розуміється чинний програмний компонент, який реалізує окремі функції і зовнішні інтерфейси розробляється ПО. Створення прототипів здійснюється в кілька ітерацій, або витків спи-рали. Кожна ітерація відповідає створенню фрагмента або вер-сії ПО, на ній уточнюються цілі і характеристики проекту, оце-ється якість отриманих результатів та плануються роботи наступної ітерації. На кожній ітерації виробляється тщатель-ва оцінка ризику перевищення термінів і вартості проекту, щоб визначити необхідність виконання ще однієї ітерації, сте-пень повноти і точності розуміння вимог до системи, а так-же доцільність припинення проекту. Спіральна модель через додавали користувачів і розробників ПЗ від необхідності пів-ного і точного формулювання вимог до системи на початковій-ної стадії, оскільки вони уточнюються на кожній ітерації. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту, і в результаті вибирається обгрунтований варіант, кото-рий доводиться до реалізації.
Спіральна модель не виключає використання каскадного підходу на завершальних стадіях проекту в тих випадках, коли тре-бования до системи виявляються цілком визначеними.
Основна проблема спірального циклу - визначення моменту переходу на наступну стадію. Для її вирішення необхідно ввести тимчасові обмеження на кожну зі стадій життєвого циклу. Пере-хід здійснюється відповідно до плану, навіть якщо не вся заплані-рова робота закінчена. План складається на основі статистич-ських даних, отриманих в попередніх проектах, і особистого досвіду розробників.
Всі матеріали в розділі "Інформатика"