Життєвий цикл інформаційної системи

18

ЗМІСТ

Вступ

1. Поняття життєвого циклу інформаційної системи

2. Спіральна модель життєвого циклу програмної системи

3. Спіральна модель життєвого циклу ІС для налагоджувального режиму розробки

4. Узагальнена спіральна модель життєвого циклу інформаційної системи

Висновок

Список використаних джерел та літератури

Вступ

Життєвий цикл програмного забезпечення (програмного продукту, програмної системи) визначається як термін часу, який починається від моменту прийняття рішення про створення програмного забезпечення й закінчується у момент його повного вилучення з експлуатації, скоріше за все, з метою встановлення та інсталяції нового продукту. Саме - нового, а не нової версії того ж продукту, що вилучається. Життєвий цикл поділяється на етапи, упродовж кожного з яких створюється нова версія програмного продукту. Під моделлю життєвого циклу програмного забезпечення сприймається структура, що визначає послідовність виконання і взаємозв'язок процесів, дій і задач упродовж життєвого циклу. Головним нормативним документом, що регламентує склад процесів життєвого циклу, є міжнародний стандарт ISO/IEC 12207:1995 “Information Technology - Software Life Cycle Pro-cessing” та відповідний йому Державний стандарт України ДСТУ 3918-99 “Інформаційні технології. Процеси життєвого циклу програмного забезпечення“ [1]. В усіх роботах, в яких так чи інакше висвітлюється життєвий цикл програмних систем, наприклад [2, 3], є посилання на ці стандарти. Крім того, в них наводяться приклади каскадної моделі життєвого циклу та для порівняння на її тлі - спіральної моделі, що має більш придатні властивості для моделювання процесів життєвого циклу. Але, якщо для каскадної моделі життєвий цикл включає стадію експлуатації та супроводу, то для спіральної моделі (її графічного зображення) життєвий цикл закінчується стадією тестування. Інакше кажучи, така спіральна модель відображає не життєвий цикл програмної системи, а життєвий цикл її розробки. Цей погляд на спіральну модель дещо розбігається з міжнародним та державним стандартами.

1. Поняття життєвого циклу інформаційної системи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Універсальним підходом до визначення робіт, які відносяться до різних фаз і стадій ЦП, є підхід Всесвітнього банку.

На рис.1 показано шість стадій, які відіграють важливу роль у більшості проектів. Це ідентифікація, розробка, експертиза, переговори, реалізація та завершальна оцінка.

Ці стадії об'єднані в дві фази: фаза проектування - перші три стадії; фаза впровадження - останні три стадії. Розглянемо їх докладніше.

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

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

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

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

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

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

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

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

2. Спіральна модель життєвого циклу програмної системи

Спіральна модель життєвого циклу розробки програмної системи є подальшим розвитком водоспадної або каскадної моделі , в якій кожний завій спіралі відповідає одній з версій розробленої системи. Точніше було б сказати: кожний завій спіралі відповідає одному з етапів життєвого циклу, під час якого розробляється версія програмної системи. Ця модель позбавляє замовника і розробника від необхідності повного і точного формулювання вимог до системи на початковій стадії, оскільки вони уточнюються на кожному завії спіралі (ітерації або етапі розробки версії системи). Таким чином, постійно поглиблюються та конкретизуються деталі проекту і, в результаті вибирається обґрунтований варіант, який доводиться до реалізації [3]. Спіральна модель (у всякому разі її графічне зображення), тобто кожний з її завіїв - етапів розробки, складається з чотирьох стадій:

1. Аналіз вимог;

2. Проектування;

3. Реалізація;

4. Тестування

Під стадією розробки розуміється частина етапу процесу розробки програмної системи, обмежена у часі і завершується створенням конкретного продукту, визначеного у вимогах. Проходження всіх стадій повторюється на кожному етапі розробки, кожному завії спіралі, окрім останнього, який завершується виводом системи з експлуатації. Відміною такої моделі від попередньої (каскадної) є можливість багаторазового повернення до стадії формулювання вимог до розробки з будь-якої стадії робіт, якщо виявиться необхідність внесення змін. Це позитивна властивість моделі, бо на кожній стадії життєвого циклу може виникнути потреба змін, а внесення змін на будь-якій стадії обов'язково починається з внесення змін до попередньо зафіксованих вимог. Це може бути пов'язане з виявленням у процесі розробки недостатньої обґрунтованості сформульованих вимог або неузгодженості окремих позицій такого формулювання, відсутності потрібних інформаційних або технічних ресурсів, зниження обсягів фінансового забезпечення тощо. Такі зміни носять локальний поточний характер і не приводять до принципових змін вимог, зафіксованих у документах. Але і в цьому випадку рішення про внесення змін повинно бути виваженим, ретельно обґрунтованим і не виходити за рамки розроблюваної версії, тому що велика кількість змін і, таким чином, часте повернення до попередніх стадій можуть внести додаткові труднощі в організацію робіт, пов'язаних з розробкою. Більш суттєві пропозиції щодо змін, які пов'язані з розширенням функціональних можливостей програмної системи, накопичуються у замовника, узгоджуються з розробником і вносяться у список для подальшого включення у нові вимоги до розробки системи з метою створення її нової, більш досконалої, версії.

Найбільш суттєві зміни у вимогах (по суті - створення нових вимог) замовника можуть виникнути тільки після дослідної, а можливо, й під час промислової експлуатації програмної системи. Наведена модель (графічне її зображення) не враховує цієї стадії етапу життєвого циклу, хоча в згаданих роботах перед тим на цьому наголошувалось. Тому пропонуємо для режиму розробки нової версії програмної системи з метою її вдосконалення та розвитку у зв 'язку з появою нових вимог замовника для досягнення більш високих характеристик, аніж ті, що були закладені у початкових, використовувати не чотирьохстадійну, а п'ятистадійну спіральну модель життєвого циклу розробки, тепер вже і супроводу (дослідної або промислової експлуатації) програмної системи. Шосту стадію - вивід системи з експлуатації, про яку ведеться мова в роботах, застосовувати у моделі не будемо, тому що на ній закінчується спіраль, розвиток процесу (його динаміка ) завершується і предмет дослідження (життєвий цикл) зникає. Це, власне не стадія, а скоріше, кінцева фаза одного (останнього) з етапів розвитку подій. І без уваги він не залишиться, але про нього трохи пізніше. Графічно п'ятистадійна модель зображується не у вигляді чотирьох квадрантів на тлі Декартових (прямокутних) координат, а у вигляді п'ятисекторів полярної сітки координат

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

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

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

* усунення дефектів у програмних засобах , які не були виявлені під час тестування і можуть бути виявлені під час цієї стадії життєвого циклу (коригуюче супроводження );

* адаптація системи до умов експлуатації замовником, консультування, а можливо, і навчання фахівців замовника кваліфікованій експлуатації системи (адаптивне супроводження );

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

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

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

3. Спіральна модель життєвого циклу ІС для налагоджувального режиму розробки

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

Потреба в ньому виникає у тому разі, коли під час тестування системи виявляється, що її характеристики не відповідають замовленим. Є розбіжності між характеристиками, зафіксованими у вимогах на створення системи, характеристиками отриманими під час тестування реалізованої програмної системи. Це може статися за різних обставин, але ясно одне - систему (програмний продукт) треба доводити, тобто вилучати помилки, усувати дефекти, вносити зміни в окремі програми й перепроектувати якісь фрагменти системи. Після цього знову необхідно реалізувати систему і ще раз тестувати. Можливо, і на цей раз будуть виявлені розбіжності в характеристиках, але значно менші. Знов повторення вказаного циклу доведення. Вочевидь - новий завій спіралі, але не тої спіралі, що розходиться, як це здійснюється у моделі розробки, а тої, що зходиться, як це здійснюється у моделі доведення (наладки) версії програмного продукту (дещо нагадує спіраль Архімеда з однією гілкою. Ця спіральна модель зображена на тлі прямокутних (Декартових ) координат, координатні вісі яких поділяють простір площини на чотири квадранти, кожний з яких разом зі своєю напіввіссю відповідає певній стадії режиму доведення програмної системи. Суттєвою відміною цієї моделі є те, що вона притаманна іншому режиму розробки програм, навіть не розробки, а доведення їх до кондиційних умов, досягнення рівня адекватності програм висунутим до них вимогам, тобто отримання необхідної якості програмного продукту. Ця модель має малі цикли (на відміну від великого життєвого циклу) доводки програмних засобів. Про це вже згадувалось вище. Причиною проведення цих циклів доводки є не вимоги замовника, закладені у технічному завданні, а дефекти програмних засобів, що виникли під час розробки за вини самого розробника чи то через неадекватно сприйняті розробником вимоги замовника, чи то через невдало вибрану технологію проектування, кодування й реалізації. Саме це й впливає на характеристики системи, вносить розбіжності між ними і характеристиками, зазначеними у вимогах. Ці розбіжності відкладаються на ординаті “Аналіз вимог і розбіжності характеристик”. На першому циклі - аналіз вимог, а на інших - розбіжності характеристик.

4. Узагальнена спіральна модель життєвого циклу інформаційної системи

Після усунення дефектів, що були виявлені на стадії тестування програмної системи, тобто після відпрацювання моделі доводки, можна повертатись до попередньої моделі, до моделі життєвого циклу розробки і продовжувати по всіх стадіях цей етап розробки нової версії програмної системи відповідно до наведеної моделі аж до стадії переходу до дослідної експлуатації та супроводження системи. І так до тих пір, поки розроблена програмна система не задовольнить замовника по всіх параметрах та характеристиках, коли він (замовник) прийме систему в промислову експлуатацію. Узагальнена (об'єднуюча всі процеси) модель життєвого циклу розробки і доведення програмної системи. Процес режиму розробки системи (модель розробки ) включає три версії та по два цикли режиму доведення системи (модель доведення) кожної версії. Зрозуміло, що це зображення умовне , тому що може буде достатньо і однієї версії, а можливо, й трьох буде замало. Це залежить, як вже згадувалось, від досвідченості фахівців замовника при формулюванні та висуванні вимог до програмної системи, від досвідченості та кваліфікації фахівців розробника при проектуванні та реалізації системи та багатьох інших об 'єктивних і суб'єктивних причин. І не в останню чергу залежить і часто визначається типом створюваної програмної системи. Так, наприклад , автоматизовані системи управління організацією (підприємством ) весь час потребують змін через появу нових або необхідності вдосконалення вже існуючих функціональних задач, через розширення виробництва, зміну партнерів , зміни в потребах ринку, котирування продукції, зміни нормативних актів тощо. Тому для такого типу систем потреба у нових версіях буде завжди, доки існуватиме організація. Процес розробки автоматизованих інформаційних систем у меншій мірі, але теж прихильний до багатоітераційності внаслідок включення до системи нових задач, розширення її меж (масштабів). Особливо це стосується територіально розподілених інформаційних систем, що охоплюють великі галузі народного господарства, органи державного управління, міністерства, відомства. Для процесу розробки програмних систем, призначених для наукових, інженерно-технічних розрахунків або навіть моделюючих програмних систем, така багатоітераційність менш характерна. Це пояснюється тим, що сама задача та її межі ясні замовнику з самого початку і вимоги свої він формулює чітко і конкретно. Якщо ж і з'явиться необхідність у доробці системи, то це стосуватиметься скоріш за все невеликих змін у алгоритмі розрахункової частини програмного забезпечення, що не вплине на архітектуру системи .

Висновок

Треба зазначити, що узагальнена модель життєвого циклу інформаційної системи, як і попередні моделі, представлені в ідеалізованому вигляді. В них кутова відстань (розміри кута) між променями або напівосями не відповідає когнітивній відстані між стадіями (кількості інтелектуальних зусиль, які необхідно затратити розробникові програмного забезпечення для того, щоб перевести систему, що розробляється, з однієї стадії життєвого циклу в іншу). Точки перерізу гілки спіралі з променями та напівосями не враховують величини інтегрованих показників, що повинні бути адекватними кількісним (розміри, об'єм, обсяг) чи якісним характеристикам тих процесів, що моделюються на цих стадіях життєвого циклу. Якби це зробити, то наведені моделі графічно виглядали б дещо інакше, що скоріше за все утруднювало б зорове сприйняття і розуміння складнощів всієї множини процесів, що протікають під час розробки програмної системи. Тим не менш зовнішній вигляд моделей спонукає до таких висновків :

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

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

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

Список використаних джерел та літератури:

1. ДСТУ 3918-99 (ISO/IEC 12207:1995) Інформаційні технології. Процеси життєвого циклу програмного забезпечення .-К .: Держстандарт України, 2002. - 49 с .

2. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії : Навч.посіб. - К .:Знання КОО, 2001. - 209 с . - (Вища освіта ХХІ століття ).

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М .:Финансы и статистика , 2000. - 352 с .

4. Баум У. Цикл реализации проекта. - Вашингтон, Институт экономического развития Всемирного Банка, 1982.

5. Руководство по циклу проекта. - Вашингтон, Институт экономического развития Всемирного Банка, 1994.