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

З робочої навчальної програми:

Тема 2. Стандарти та нормативні посібники з системної та програмної інженерії.

Стандарт ISO/IEC 15288 "Системна інженерія - процеси життєвого циклу систем".

ГОСТ 34: Комплекс стандартів на автоматизовані системи.

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

2.1. Стандарт ISO 15288 «Системна інженерія – процеси життєвого циклу систем».

2.2. Життєвий циклсистеми.

2.3. Уявлення життєвого циклу системи.

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

2.5. Моделі життєвого циклу

2.6. Вибір моделі життєвого циклу

2.1. Стандарт iso 15288 "системна інженерія - процеси життєвого циклу систем".

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

Завдання стандарту:

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

Впровадити у практику організації низку ключових ідей системної інженерії:

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

Історіястворення

Спільна розробка ISO та IEC, активна участь INCOSE

Початок робіт у 1996, версії у 2002, 2005 (ГОСТ Р ИСО/МЭК 15288-2005), 2008

Покликаний гармонізувати так зване "болото стандартів" системної інженерії (чисельні стандарти, прийняті різними військовими відомствами, державами, галузевими організаціями стандартизації)

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

2.2. Життєвий цикл системи

Абревіатура русск: Ж Ц

Абревіатура англ: LC (LifeCycle)

Українська: "життєвий цикл". Англійське life cycle у техніці раніше означало та перекладалося як «термін служби», і іноді навіть «термін служби до першого капітального ремонту». "Життєвий цикл" - це відносно новий переклад. Іноді «цикл» перекладають як «період», але такий переклад не утримався (хоча він і точніше в даному випадку: «період життя» системи). Слово «цикл» має бентежити – нічого циклічного в життєвому циклі немає. Слово «цикл» має сенс «типовості», говорячи про те, що те саме відбувається і з іншими системами.

Формально: життєвий цикл – це зміна станів системи (еволюція системи) період від задуму до припинення її існування.

Система та життєвий цикл - близнюки-брати. Ми говоримо система - маємо на увазі життєвий цикл, ми говоримо життєвий цикл - маємо на увазі система.

Визначення.

Визначення стандарту ISO/IEC 15288:2008 (Визначення: life cycle - evolution of system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):

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

Визначення стандарту ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системи промислової автоматизації. Вимоги до архітектури еталонних підприємств та методології. Описує еталонну архітектуру підприємства та засоби реалізації проектів у рамках повного життєвого циклу підприємства

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

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

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

Таблиця 2.1

Стадії створення систем (ISO/IEC 15288)
№ п./п	Стадія	Опис
	Формування концепції	Аналіз потреб, вибір концепції та проектних рішень
	Розробка	Проектування системи
	Реалізація	Виготовлення системи
	Експлуатація	Введення в експлуатацію та використання системи
	Підтримка	Забезпечення функціонування системи
	Зняття з експлуатації	Припинення використання, демонтаж, архівування системи

1. Життєвий цикл ІВ та його структура. 2

1.1 Стадії життєвого циклу ІС.

1.2 Стандарти життєвого циклу ІС.

2. Моделі життєвого циклу. 6

2.1 Типи моделей життєвого циклу ІС.

2.2 Переваги та недоліки моделей життєвого циклу ІС.

3. Процеси життєвого циклу ІС............................................ .................. 11

3.1. Основні процеси життєвого циклу. 11

3.2. Допоміжні процеси життєвого циклу. 13

3.3 Організаційні процеси.. 14

Список використаної литературы.. 16

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

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

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

Повний життєвий цикл інформаційної системи включає, як правило, стратегічне планування, аналіз, проектування, реалізацію, впровадження та експлуатацію. У випадку життєвий цикл можна у свою чергу розбити на ряд стадій. У принципі, цей поділ на стадії досить довільний. Ми розглянемо один з варіантів такого поділу, пропонований корпорацією Rational Software - однією з провідних фірм на ринку програмного забезпечення засобів розробки інформаційних систем (серед яких великою популярністю користується заслужено універсальне CASE-засіб Rational Rose).

1.1 Стадії життєвого циклу ІС

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

Відповідно до методології, запропонованої Rational Software, життєвий цикл інформаційної системи поділяється на чотири стадії.

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

1) Початкова стадія

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

2) Стадія уточнення

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

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

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

3) Стадія конструювання

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

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

4) Стадія передачі у експлуатацію

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

Наприкінці стадії передачі в експлуатацію необхідно визначити, досягнуті цілі розробки чи ні.

1.2 Стандарти життєвого циклу ІВ

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

Серед найвідоміших стандартів можна виділити такі:

ГОСТ 34.601-90 - поширюється на автоматизовані системи та встановлює стадії та етапи їх створення. Крім того, стандарт містить опис змісту робіт на кожному етапі. Стадії та етапи роботи, закріплені у стандарті, більшою мірою відповідають каскадній моделі життєвого циклу.

ISO/IEC 12207 (International Organization of Standardization / International Electrotechnical Commission) 1995 - стандарт на процеси та організацію життєвого циклу. Поширюється попри всі види замовного ПЗ. Стандарт не містить опису фаз, стадій та етапів.

Rational Unified Process (RUP) пропонує ітеративну модель розробки, що включає чотири фази: початок, дослідження, побудова та впровадження. Кожна фаза може бути розбита на етапи (ітерації), у яких випускається версія для внутрішнього чи зовнішнього використання. Проходження через чотири основні фази називається циклом розробки, кожний цикл завершується генерацією версії системи. Якщо після цього робота над проектом не припиняється, то отриманий продукт продовжує розвиватися і знову мине ті самі фази. Суть роботи в рамках RUP – це створення та супровід моделей на базі UML.

Microsoft Solution Framework (MSF) подібна до RUP, так само включає чотири фази: аналіз, проектування, розробка, стабілізація, є ітераційною, передбачає використання об'єктно-орієнтованого моделювання. MSF у порівнянні з RUP більшою мірою орієнтована на розробку бізнес-додатків.

Extreme Programming (XP). Екстремальне програмування (найновіша серед аналізованих методологій) сформувалося в 1996 році. В основі методології командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту з розробки ІВ, а розробка ведеться з використанням наступних ельно допрацьованих прототипів.

2. Моделі життєвого циклу

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

Модель ЖЦ ІС включає:

результати виконання робіт на кожній стадії;

ключові події - точки завершення робіт та прийняття рішень.

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

2.1 Типи моделей життєвого циклу ІВ

В даний час відомі та використовуються такі моделі життєвого циклу:

Каскадна модель (рис. 2.1) передбачає послідовне виконання всіх етапів проекту у строго фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.

Поетапна модель із проміжним контролем (рис. 2.2). Розробка ІВ ведеться ітераціями із циклами зворотного зв'язку між етапами. Міжетапні коригування дозволяють враховувати реальний взаємовплив результатів розробки на різних етапах; Час життя кожного з етапів розтягується протягом усього періоду розробки.

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

Мал. 2.1. Каскадна модель ЖЦ ІС

Мал. 2.2. Поетапна модель із проміжним контролем

Мал. 2.3. Спіральна модель ЖЦ ІС

На практиці найбільшого поширення набули дві основні моделі життєвого циклу:

каскадна модель (характерна періоду 1970-1985 рр.);

спіральна модель (характерна періоду після 1986.г.).

2.2 Переваги та недоліки моделей життєвого циклу ІС

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

Життєвий цикл системиє найстарішим методом побудови інформаційних систем, у наші дні він використовується для створення складних проектів середнього та великого масштабів. Цей процес включає шість етапів: 1) підготовка проекту; 2) дослідження системи; 3) проектування; 4) програмування; 5) інсталяція; 6) експлуатація та освоєння системи. Ці етапи зображено на рис. 10.7. Кожен етап включає кілька процесів.

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

Systems lifecycle (життєвий цикл системи)

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

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

Етапи життєвого циклусистеми

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

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

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

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

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

Project definition (визначення проекту)

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

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

Design (проектування)

Етап, на якому розробляються проектні специфікації для системного

Programming (програмування)

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

Installation (установка)

Цей етап складається з трьох процесів: тестування, навчання персоналу та конверсії; останніх підготовчих стадій перед уведенням системи в експлуатацію. Postimplementation (експлуатація та освоєння системи)

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

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

Створення прототипу

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

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

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

На рис. 10.8 зображено процес створення прототипу, що складається з чотирьох наступних етапів (кроків):

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

Крок 2 Розробка початкового прототипу. p align="justify"> Проектувальник швидко створює робочу модель, використовуючи програмне забезпечення нового покоління, мультимедійні програми або системи автоматизованого проектування (див. гл. 14).

Крок 3 Робота із прототипом.Користувач оцінює роботу системи та дає рекомендації щодо її покращення.

Prototyping (створення прототипу)

Процес створення експериментальної системи для демонстраційних цілей та попереднього тестування, що не потребує великих витрат. Prototype (прототип)

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

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

Крок 4. Виправлення та вдосконалення прототипу.Проектувальник реалізує практично всі побажання користувачів. Після внесення змін та виправлення помилок процес повертається до кроку 3. Кроки 3 та 4 повторюються доти, доки користувач не буде повністю задоволений.

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

Використання прототипу: переваги та недоліки

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

End-user interface (інтерфейс користувача)

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

Але швидке створення прототипу може створити ілюзію непотрібності важливих етапів розробки системи. Якщо завершена модель працює нормально, керівництво компанії може вирішити, що такі процеси як програмування, реконструкція системи та підготовка вичерпної документації не відіграють істотної ролі у створенні повністю працездатної системи. Деякі із систем, створені в такі стислі терміни, не можуть оперувати великими обсягами даних або не в змозі підтримувати багато користувачів одночасно. Процес створення прототипу може також сповільнитися, якщо в ньому беруть участь дуже багато користувачів (Hardgrove, Wilson, and Eastman, 1999).

Пакети прикладних програм

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

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

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

Application software package (пакет прикладних програм)

Набір програм, які готові до роботи, які можна придбати або взяти в оренду.

Customization(кастомізація)

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

Вибір програмного пакета

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

Розробка кінцевими користувачами

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

Request for proposal (RFP) (запит пропозицій)

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

End-user development (розробка кінцевими користувачами)

Розробка інформаційних систем кінцевими користувачами за незначної участі технічних фахівців.

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

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

Повний життєвий цикл інформаційної системи включає, як правило, стратегічне планування, аналіз, проектування, реалізацію, впровадження та експлуатацію. У випадку життєвий цикл можна у свою чергу розбити на ряд стадій. У принципі, цей поділ на стадії досить довільний. Ми розглянемо один із варіантів такого поділу, пропонований корпорацією Rational Software - однією з провідних фірм на ринку програмного забезпечення засобів розробки інформаційних систем (серед яких великою популярністю заслужено користується універсальний CASE-засіб Rational Rose).

Стадії життєвого циклу ІС

1) Початкова стадія

2) Стадія уточнення

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

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

3) Стадія конструювання

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

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

4) Стадія передачі у експлуатацію

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

Наприкінці стадії передачі в експлуатацію необхідно визначити, досягнуті цілі розробки чи ні.

Стандарти життєвого циклу ІС

Серед найвідоміших стандартів можна виділити такі:

Extreme Programming (XP). Екстремальне програмування (найновіша серед аналізованих методологій) сформувалося в 1996 році. В основі методології командна робота, ефективна комунікація між замовником та виконавцем протягом усього проекту з розробки ІВ, а розробка ведеться з використанням послідовно допрацьованих прототипів.

спіральний життєвий цикл каскадний

Таблиця 2.1

Визначення.

1. Визначення стандарту ISO/IEC 15288:2008 (Визначення: life cycle - evolution of system, product, service, project or other human-made entity from conception through retirement (ISO 15288, 4.11):

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

2. Визначення стандарту ISO 15704 (Industrial automation systems - Requirements for enterprise-reference architectures and methodologies Системи промислової автоматизації. Вимоги до архітектури еталонних підприємств та методології. Описує еталонну архітектуру підприємства та засоби реалізації проектів у рамках повного життєвого

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

Коментар: життєвий цикл – завжди життєвий цикл конкретної системи. Не буває «життєвого циклу», окрім як у текстах стандартів, у житті завжди «життєвий цикл X», де X – назва цільової системи. Процеси життєвого циклу – це процеси, які актори виконують над/із системою, і які змінюють стан системи, змушуючи її еволюціонувати під час її життєвого циклу. "Управління життєвим циклом" - загальноприйнята назва підходу до опису процесів життєвого циклу (а часто і назва самої групи процесів життєвого циклу, описаних з використанням такого підходу).

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

Насамперед, треба розрізнити життєвий цикл (іноді, обмежуючись лише інженерією, але з повним ЖЦ говорять також delivery process, зрідка для софта -- software process) та інші " процесні уявлення " -- трансакції DEMO, логічні " бізнес-процеси " (практики ), workflows, проектні уявлення (докладніше - http://ailev.livejournal.com/904643.html). Хоча є безліч підходів, за яких усі ці різні аспекти описів організації та методів її роботи поєднуються.

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

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

· «Нарізана ковбаска»

· V-діаграма

Нарізана ковбаска.

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

Малюнок 2.1. Традиційне уявлення життєвого циклу

Навколо традиційної «ковбаски» можуть вказуватися ще дві додаткові: як ЖЦ бачать менеджери (особи, що керують проектом), і як ЖЦ бачать інженери (особи, що реалізують проект) (рис.2.2)

Малюнок 2.2. Приклад подання життєвого циклу

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

Рис.2.3. Різноманітність життєвих циклів