Життєвий цикл інформаційної системи є базовими елементом концепції проектного аналізу. Життєвий цикл інформаційної системи - це час від першої затрати до останньої вигоди проекту. Він відображає розвиток проекту, роботи, які проводяться на різних стадіях підготовки, реалізації та експлуатації проекту. До поняття життєвого циклу інформаційної системи входить визначення різних стадій розробки й реалізації проекту.
Життєвий цикл інформаційної системи являє собою певну схему або алгоритм, за допомогою якого відбувається встановлення певної послідовності дій при розробці та впровадженні проекту.
Ступінь деталізації і термінологія опису відповідних процедур залежать від характеру проекту, предметної культури, поставлених завдань, наявних ресурсів і, можливо, уподобань та смаків проектного аналітика. Спіральна модель життєвого циклу розробки програмної системи є подальшим розвитком водоспадної або каскадної моделі , в якій кожний завій спіралі відповідає одній з версій розробленої системи. Точніше було б сказати: кожний завій спіралі відповідає одному з етапів життєвого циклу, під час якого розробляється версія програмної системи. Ця модель позбавляє замовника і розробника від необхідності повного і точного формулювання вимог до системи на початковій стадії, оскільки вони уточнюються на кожному завії спіралі (ітерації або етапі розробки версії системи). Таким чином, постійно поглиблюються та конкретизуються деталі проекту і, в результаті вибирається обґрунтований варіант, який доводиться до реалізації [3]. Спіральна модель (у всякому разі її графічне зображення), тобто кожний з її завіїв - етапів розробки, складається з чотирьох стадій: 1. Аналіз вимог; 2. Проектування; 3. Реалізація; 4. Тестування Під стадією розробки розуміється частина етапу процесу розробки програмної системи, обмежена у часі і завершується створенням конкретного продукту, визначеного у вимогах. Проходження всіх стадій повторюється на кожному етапі розробки, кожному завії спіралі, окрім останнього, який завершується виводом системи з експлуатації. Відміною такої моделі від попередньої (каскадної) є можливість багаторазового повернення до стадії формулювання вимог до розробки з будь-якої стадії робіт, якщо виявиться необхідність внесення змін. Це позитивна властивість моделі, бо на кожній стадії життєвого циклу може виникнути потреба змін, а внесення змін на будь-якій стадії обов'язково починається з внесення змін до попередньо зафіксованих вимог. Це може бути пов'язане з виявленням у процесі розробки недостатньої обґрунтованості сформульованих вимог або неузгодженості окремих позицій такого формулювання, відсутності потрібних інформаційних або технічних ресурсів, зниження обсягів фінансового забезпечення тощо. Такі зміни носять локальний поточний характер і не приводять до принципових змін вимог, зафіксованих у документах. Але і в цьому випадку рішення про внесення змін повинно бути виваженим, ретельно обґрунтованим і не виходити за рамки розроблюваної версії, тому що велика кількість змін і, таким чином, часте повернення до попередніх стадій можуть внести додаткові труднощі в організацію робіт, пов'язаних з розробкою. Більш суттєві пропозиції щодо змін, які пов'язані з розширенням функціональних можливостей програмної системи, накопичуються у замовника, узгоджуються з розробником і вносяться у список для подальшого включення у нові вимоги до розробки системи з метою створення її нової, більш досконалої, версії. Існуючі моделі життєвого циклу різняться структурою і конкретним змістом фаз створення і впровадження автоматизованої системи (АС) або окремих її складових. Найпоширенішими моделями ЖЦП є: каскадна модель; спіральна модель; метод швидкого прототипу; метод послідовного нарощування функцій; модель, заснована на повторному використанні компонентів; модель, заснована на автоматизованому синтезі програм. Каскадна модель характеризується чіткою впорядкованістю таких стадій створення і впровадження АС: визначення вимог; розроблення технічного завдання; планування розробки; проектування; реалізація; збирання системи; супроводження; уточнення вимог. Така впорядкованість вимагає, щоб роботи, передбачені на кожній стадії, виконувалися без необхідності їх перегляду, тобто без повернення до попередньої стадії. Модель містить тільки зовнішній цикл, що включає стадію супроводу, оскільки на цій стадії можуть уточнюватись і змінюватись вимоги замовника і відбувається повернення до стадії розроблення технічного завдання з подальшим повторенням усіх інших стадій. Перевага каскадної моделі — в її детермінованості й чіткій регламентованості. Це важливо при розробленні складних проектів, в яких необхідна узгоджена участь декількох організацій, що представляють замовника, розробників і користувачів. Її слабкою стороною є те, що від затвердження технічного завдання до впровадження готового продукту минає дуже багато часу. Існує ризик, що за цей час реальні потреби користувача можуть змінитися і тому не будуть повністю задоволені. Крім того, можливі ситуації, коли реальні потреби, що залишаються незмінними, але були неправильно або недостатньо повно усвідомлені користувачами при розробленні технічного завдання, їх дійсне розуміння настає лише після введення системи в експлуатацію, коли вже пізно вносити серйозні зміни. Спіральна модель життєвого циклу передбачає багаторазове проходження одних і тих самих стадій розробки, поки створений продукт не буде задовольняти замовника. Ця модель має ітераційний характер, притаманний процесу створення таких складних штучних об’єктів, якими є програмні засоби. На кожній ітерації створюють діючий прототип, який піддають критичному оцінюванню. На заключній ітерації прототип приймають за остаточний варіант системи. Спіральна модель вільна від недоліків каскадної моделі, оскільки на кожному витку спіралі є можливість пересвідчитися в тому, що вимоги, які змінилися, враховано при розробленні чергового прототипу. До недоліків спіральної моделі слід віднести складність планування та організації робіт, а також значні витрати ресурсів при розробленні великих проектів. Тому її використовують у тих випадках, коли система невелика, але існує певна невизначеність щодо вимог користувачів. Якщо проект досить великий, то звичайно в ньому вдається виділити обмежену за обсягом підсистему, яку дійсно доцільно розробляти, використовуючи спіральну модель. Через труднощі планування робіт ця модель частіше застосовується тоді, коли замовник, розробник і користувач — одна й та сама організація або коли продукт розробляється для масового споживача. Метод швидкого прототипу передбачає розроблення в стислі строки діючого макета частини автоматизованої системи, найбільш критичної до змін вимог користувачів, а також проведення тестувальної експлуатації макета до розроблення повномасштабного зразка. Звичайно насамперед прототипуванню підлягає інтерфейс користувача з майбутньою системою. Це дає змогу залучити кінцевих користувачів до активної співпраці на ранній стадії розроблення АС і таким чином уникнути доопрацювань закінченої системи (що коштують дорого), як це часто трапляється при використанні каскадної моделі. Основне призначення прототипування — полегшити виявлення всіх вимог користувачів. Тому, як правило, прототип після розроблення технічного завдання більше не використовують і далі модель життєвого циклу збігається з каскадною. Такий підхід, зокрема, реалізовано в британській технології SSADM. Передбачена британським стандартом розробка діючого прототипу ще більше пом’якшує недоліки каскадної моделі. Метод послідовного нарощування функцій полягає у проектуванні та реалізації АС поетапно. На кожному етапі користувачі отримують варіант системи з усе більшим функціональним наповненням. Це дає змогу різко скоротити час, необхідний для введення в дію першої черги АС і початку експлуатації її. У результаті організація-користувач досить скоро починає відчувати реальніший ефект від автоматизації. Тому до сильної сторони такого підходу порівняно з каскадною моделлю можна віднести скорочення терміну окупності. Слабкими сторонами є труднощі планування управління проектом у поєднанні з необхідністю дотримуватися відкритої архітектури, що часто сильно ускладнює задачу розробника. Метод послідовного нарощування функцій досить успішно може бути застосований при створенні АС організаційного управління. При цьому в першу чергу може бути розроблена частина АС, що реалізує порівняно прості інформаційні задачі, впровадження яких може дати відразу помітний ефект. До складу наступних черг можуть бути включені інші інформаційні задачі і лише потім — задачі, що потребують виконання досить складних розрахунків. Еволюційна модель передбачає доопрацювання повномасштабного зразка автоматизованої системи до рівня якості, що задовольняє кінцевих користувачів, безпосередньо в процесі експлуатації її. При цьому реалізацію АС починають з тих функцій, про які розробники мають досить чітке уявлення. Знання відносно інших функцій системи уточнюють уже після її часткової здачі в експлуатацію. У цьому розглядуваний підхід протилежний методу швидкого прототипу, згідно з яким розробку починають з реалізації функцій, відносно яких у розробників є найбільші сумніви. При створенні складних АС еволюційний підхід дає змогу від початку зосередитися на досягненні високих експлуатаційних характеристик, таких як надійність, мобільність, модифікованість тощо, чому іноді перешкоджає розробка швидких прототипів. Еволюційний підхід може бути особливо корисним при розробленні систем, в яких роботи зі створення програмного забезпечення не лежать на критичному шляху загального графіка робіт. Повторне використання компонентів є основою так званого складального програмування, що дає змогу суттєво скоротити вартість і тривалість розроблення АС, а також підвищити його надійність при одночасному скороченні витрат на супровід. Найбільший ефект отримується тоді, коли значну частину задач вдається сформулювати в термінах відносно невеликого числа підзадач, яким ставлять у відповідність стандартні підпрограми. Тоді розроблення чергової задачі зводиться до написання порівняно нескладної програми, що викликає ці підпрограми в потрібній послідовності та організує між ними обмін даними. Однак унікальні алгоритми обробки інформації або суб’єктивні знання евристики, якими користуються експерти при вирішенні складних задач, за допомогою стандартних програм описати неможливо. Тому модель, заснована на повторному використанні компонентів, є ідеалізацією і в чистому вигляді не використовується. Водночас у зв’язку з поширенням об’єктно-орієнтованого підходу до розроблення АС вона набуває все більшого значення.
Автоматизований синтез програм заснований на трансформації специфікацій, складених на мові надвисокого рівня, в машинні програми. Відповідно до розвитку таких мов змінювалось і значення, що вкладається в поняття «синтез програм». Найбільш високий рівень притаманний так званим мовам четвертого покоління. Тоді очевидно, що мови «надвисокого» рівня — це існуючі мови представлення знань систем штучного інтелекту, які відносять до п’ятого покоління. Таким чином, концепція автоматизованого синтезу програм у її сучасному розумінні заснована на представленні знань як про предметну область, так і про процес створення програмних засобів. На відміну від підходів, розглянутих вище, реалізація цього підходу потребує досить високих первинних витрат на побудову моделей знань і особливо на створення інструментальних засобів для підтримки їх, що пов’язано з ризиком значного подорожчання розробки. Автоматизований синтез програм за їх специфікаціями дає змогу різко скоротити всі види витрат і реалізувати високу якість програмного продукту. Тому існують умови, за яких розглянутий підхід може виявитися економічно досить ефективним, і задача програмної інженерії полягає в тому, щоб знайти ці умови.
