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

Размещено на http://www.allbest.ru/

15

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

Дисципліна «Інформаційний менеджмент»

Спеціальність «Інтелектуальні системи прийняття рішень»

Зміст

Вступ

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

2. Особливоті життєвого циклу системи інформаційного сервісу

3. Спіральна модель ЖЦ ПС

4. Еволюційна модель ЖЦ ПС

Висновок

Список використаної літератури

Вступ

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

Життєвий цикл поділяється на етапи, упродовж кожного з яких створюється нова версія програмного продукту. Під моделлю життєвого циклу програмного забезпечення сприймається структура, що визначає послідовність виконання і взаємозв'язок процесів, дій і задач упродовж життєвого циклу. Головним нормативним документом, що регламентує склад процесів життєвого циклу, є міжнародний стандарт ISO/IEC 12207:1995 “Information Technology - Software Life Cycle Processing” та відповідний йому Державний стандарт України ДСТУ 3918-99 “Інформаційні технології. Процеси життєвого циклу програмного забезпечення“.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.1. Стадії визначення роботи

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

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

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

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

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

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

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

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

Сервісне обслуговування має передбачати:

надійність поставок;

технічні інструкції;

ремонт устаткування, коригування програм та актуалізацію БД;

надання знижок;

простоту вступу в контакт.

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

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

Друга фаза -- власно створення ІС та впровадження її -- може бути побудована по-різному залежно від прийнятої моделі життєвого циклу. Головну роль протягом цієї фази відіграє організація-розробник.

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

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

каскадна модель;

спіральна модель;

метод швидкого прототипу;

метод послідовного нарощування функцій;

модель, заснована на повторному використанні компонентів;

модель, заснована на автоматизованому синтезі програм.

Каскадна модель характеризується чіткою впорядкованістю таких стадій створення і впровадження АС:

визначення вимог;

розроблення технічного завдання;

планування розробки;

проектування;

реалізація;

збирання системи;

супроводження;

уточнення вимог.

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

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

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

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

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

2. Особливості життєвого циклу системи інформаційного сервісу

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

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

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

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

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

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

Рис. 2. Модель інформаційної архітектури підприємства

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

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

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

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

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

доставку і впровадження системи;

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

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

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

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

Процес експлуатації визначає дії фірми-замовника послуги (товару) і складається з процесу реалізації та безпосереднього використання.

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

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

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

інформаційний програмний цикл

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

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

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

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

Реалізація;

Тестування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

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

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

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

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

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

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

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

Размещено на Allbest.ru