Життєвий цикл та моделі життєвого циклу аїс. Етапи створення аїс моделі життєвого циклу аїс. Стадії життєвого циклу інформаційної системи

Тема 1.2 Життєвий цикл АІС та моделі життєвого циклуАІС

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

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

Домогтися цього протягом усього ЖЦ АІС - досить складне з низки об'єктивних і суб'єктивних причин завдання, у результаті переважна більшість проектів АІС впроваджується з порушеннями якості, термінів чи кошторису; майже третина проектів припиняють своє існування незавершеними. За даними Standish Group у 1996 р. 84 % проектів АІС були завершені у встановлені терміни, в 1998 р. це число скоротилася до 74 %, після 2000 р. воно не опускається нижче 50 %. Головною причиною такого положення є те, що рівень технології аналізу та проектування систем, методів та засобів управління проектами не відповідає складності створюваних систем, яка постійно зростає у зв'язку з ускладненням та швидкими змінами бізнесу.

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

Процес проектування АІС регламентований наступною документацією (стандартами, методологіями, моделями):

ГОСТ 34.601-90- стандарт на стадії та етапи створення АІС, що відповідають каскадній моделі ЖЦ ПЗ (розглядається нижче). Наводиться опис змісту робіт кожному етапі;

180/1ЄС 12207:1995- стандарт на процеси та організацію життєвого циклу; поширюється на всі види програмного забезпечення; не містить опису фаз, стадій та етапів;

Custom Develoment Method(методологія Oracle) - технологічний матеріал з розробки прикладних АІС, деталізований до рівня заготівель проектних документів у розрахунку на використання Oracle. Застосовується для класичної моделі ЖЦ (передбачені всі роботи, завдання та етапи), а також для технологій «швидкої розробки» або «полегшеного підходу», що рекомендуються у разі малих проектів.

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

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

Extreme Programming (ХР)- екстремальне програмування (найновіша серед аналізованих методологій); сформувалося в 1996 р. Основою методології є робота у команді, ефективні комунікації між замовником та виконавцем протягом усього проекту; розробка АІС ведеться з використанням прототипів, що послідовно допрацьовуються.

Стандарт ISO/IЕС 12207 у структурі життєвого циклу визначає процеси, які виконуються під час створення ПЗ АІС. Ці процеси поділяють на три групи:

основні(придбання, постачання, розробка, експлуатація та супровід);

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

організаційні(Управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого життєвого циклу, навчання).

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

РозробкаАІС включає всі роботи зі створення програмного забезпечення та його компонентів відповідно до заданих вимог. Цей процес також передбачає:

Оформлення проектної та експлуатаційної документації;

Підготовка матеріалів, необхідних для тестування розроблених програмних продуктів;

Розробку матеріалів, необхідні навчання персоналу.

Як правило, складовими процесу розробки є стратегічне планування, аналіз, проектування та реалізація (програмування).

До процесу експлуатаціївідносяться:

Конфігурування бази даних та робочих місць користувачів;

Забезпечення користувачів експлуатаційною документацією;

Навчання персоналу.

Основні експлуатаційні роботи включають:

Безпосередньо експлуатацію;

Локалізацію проблем та усунення причин їх виникнення;

Модифікацію програмного забезпечення;

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

Розвиток та модернізацію системи.

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

До попередніх дій при організації технічного обслуговуванняАІС відносяться:

Виділення найбільш відповідальних вузлів системи та визначення для них критичності простою (це дозволить виділити найбільш критичні складові АІС та оптимізувати розподіл ресурсів для технічного обслуговування);

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

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

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

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

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

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

Організаційні процесимають дуже велике значення, оскільки сучасні АІС – це великі комплекси, у створенні та обслуговуванні яких зайнято багато людей різних спеціальностей.

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

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

Вибір методів та інструментальних засобів реалізації проекту;

Визначення методів опису стану процесу розробки;

Розробку методів та засобів випробувань створеного програмного забезпечення;

Навчання персоналу.

Забезпечення якості проекту пов'язане із проблемами верифікації, перевірки та тестування компонентів АІС.

Верифікація -процес визначення відповідності поточного стану розробки, досягнутого на даному етапі, вимогам цього етапу

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

У 2002р. Було опубліковано стандарт на процеси ЖЦ автоматизованих систем (ISO/IEC 15288 System Life cycle processes). У розробці стандарту брали участь фахівці із різних галузей діяльності; враховувався практичний досвід створення систем в урядових, комерційних, військових та академічних організаціях. Відповідно до стандарту ISO/IEC серії 15288 структуру ЖЦ включені такі групи процесів.

1. Договірні процеси:

Придбання (внутрішні рішення чи рішення зовнішнього постачальника);

Постачання (внутрішні рішення або рішення зовнішнього постачальника).

2. Процеси підприємства:

Управління довкіллямпідприємства;

Інвестиційне управління; в управління ЖЦ ІВ;

Управління ресурсами;

Управління якістю.

3. Проектні процеси:

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

Оцінка проекту;

Контроль проекту;

Управління ризиками;

Управління конфігурацією;

Управління інформаційними потоками;

Ухвалення рішень.

4. Технічні процеси:

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

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

Розробка архітектури;

Впровадження;

Інтеграція;

Верифікація;

Перехід;

Атестація;

Експлуатація;

Супровід;

Утилізація.

5. Спеціальні процеси:

Визначення та встановлення взаємозв'язків виходячи із завдань та цілей.

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

У 1970-х роках. IBM запропонувала методологію Business System Planning (BSP) або методологію організаційного планування.

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

Таблиця 1.4.Стадії створення АІС (ISO/IEC 15288)

За опублікованими даними кожен етап розробки АІС потребує певних витрат часу. В основному (45-50%) час йде на кодування, комплексне та автономне тестування (рис.14). У середньому розробка АІС займає третину всього ЖЦ системи (рис.1.5).

Рис.1.4. Розподіл часу під час розробки АІС

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

1) передпроектне обстеження (або аналіз) організації,

2) проектування АІС,

3) реалізація АІС,

4) використання АІС,

5) функціонування (експлуатація, використання)

6) супровід АІС,

7) модернізація проекту АІС.

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

Слід зазначити, АІС є продуктом інформаційного виробництва, як автомобіль є продуктом машинобудівного виробництва, ковбаса – продуктового виробництва тощо, тому стадії ЖЦ АІС 1 по 5 аналогічні етапам ЖЦ будь-якого продукту.

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

Фізичний знос АІС – неможливість задовольнити вимоги організації до АІС через поломку, збій або відмову в роботі компонентів системи.

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

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

Вище були перераховані всі стадії ЖЦ АІС, але деякі з них проходять паралельно, тому виділяють все 5 етапів у ЖЦ АІС(Рис.35):

На першому етапі « Передпроектне обстеження»(рис. 33) прийнято виділяти два основні підетапи та один додатковий підетап:

1.1. проведення передпроектного обстеження та збирання матеріалів обстеження;

1.2. аналіз матеріалів обстеження та розробка на основі аналізу техніко-економічного обґрунтування (ТЕО) та технічного завдання(ТЗ);

1.3. вибір та розробка варіанта концепції системи.

Цілями етапу «передпроектне обстеження» є таке:

· сформулювати потреби у новій АІС, тобто. ідентифікувати всі недоліки ІС;

· Вибрати напрям і визначити економічну доцільністьпроектування АІС.

Роботи з проведення обстеження розпочинаються з аналізу первинних вимог та планування робіт, які займають від 2 днів до 4 тижнів. Далі проводиться саме обстеження діяльності підприємства (тривалість обстеження становить 1-2 тижні).

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

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

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

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

2. Формується Модель "як має бути",що інтегрує перспективні пропозиції керівництва та співробітників підприємства, експертів та системних аналітиків та дозволяє сформувати бачення нових раціональних технологій роботи підприємства. Вона є Концепція майбутньої АІС.

Створення концепції майбутньої системи включає проведення наступних робіт:

Детальне вивчення об'єкта автоматизації;

Необхідні науково-дослідні роботи (НДР), пов'язані з пошуком шляхів та оцінкою можливості реалізації вимог користувача;

Розробка альтернативних варіантів концепції створюваної АІС та планів їх реалізації;

Оцінка необхідних ресурсів на їх реалізацію та забезпечення функціонування;

Оцінка переваг та недоліків кожного варіанту;

Зіставлення вимог користувача та характеристик запропонованої системи та вибір оптимального варіанту;

Визначення порядку оцінки якості та умов приймання системи;

Оцінка ефектів, які отримують від системи;

Оформлення звіту, що містить опис виконаних робіт;

Опис та обґрунтування запропонованого варіанта концепції системи.

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

Фактично цьому етапі дається у відповідь питання: " Що має робити майбутня система? " . Саме тут лежить ключ до успіху всього проекту автоматизації. У практиці створення великих програмних систем відомо чимало прикладів невдалої реалізації саме через неповноту та нечіткість визначення системних вимог.

На цьому етапі визначаються:

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

§ інтерфейси та розподіл функцій між людиною та системою;

§ вимоги до програмних та інформаційних компонентів системи, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонентів системи, їх інтерфейси;

§ склад людей та робіт, що мають відношення до системи;

§ обмеження у процесі розробки (директивні терміни завершення окремих етапів, наявні ресурси);

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

В рамках системного проектування здійснюється:

Визначення складу, структури та характеристик функціональних завдань у рамках діяльності структурних підрозділів;

Визначення складу та структури програмних засобів автоматизації для технології вирішення завдань з урахуванням існуючих коштів у структурних підрозділах;

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

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

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

Системний проектповинен включати:

· Повну функціональну модель вимог до майбутньої системи;

· Коментарі до функціональної моделі (специфікації процесів нижнього рівня в текстовому вигляді);

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

· Концептуальну модель інтегрованої бази даних (пакет діаграм);

· архітектуру системи з прив'язкою до концептуальної моделі;

· пропозиції щодо оргштатної структури для підтримки системи.

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

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

Описати, "побачити" та скоригувати майбутню систему до того, як її буде реалізовано фізично;

Зменшити витрати на розробку та впровадження системи;

Оцінити розробку за часом та результатами;

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

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

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

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

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

Малюнок 33. Послідовність робіт на етапі передпроектної стадії ЖЦ АІС.

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

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

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

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

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

Розробка пропозицій щодо технічних засобів;

Розробка пропозицій щодо програмних засобів;

Розробка топології, складу та структури локальної обчислювальної мережі;

Розробка пропозицій щодо етапів та термінів автоматизації.

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

Другий етап « Проектування»(рис.34) виконує такі підетапи:

1) ескізне проектування: уточнення вимог ТЗ, оформлення та затвердження ескізного проекту;

2) технічне проектування: вибір проектних рішень з усіх аспектів розробки АІС, опис усіх компонентів АІС, оформлення та затвердження технічного проекту;

3) робоче проектування: вибір та розробка математичних методів та алгоритмів програм, коригування структури баз даних (БД), створення документації на постачання та розробку програмних продуктів, вибір комплекту технічних засобів АІС, створення документації на постачання та встановлення технічних засобів, розробка робочого проекту АІС .

Цілями цього етапу є наступне:

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

· Розробити системну архітектуру обраного варіанту АІС, тобто склад підсистем, що забезпечують.

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

Визначення функції АІС;

Визначення функції підсистем, їх цілі та ефекти;

Визначення складу комплексів завдань та окремих завдань;

визначення концепції інформаційної бази, її укрупнена структура;

Визначення функцій системи керування базою даних;

Визначення складу обчислювальної системи;

Визначення функції та параметри основних програмних засобів.

Розробка документації на цю частину проекту.

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

На підетапі 2. Технічне проектування » виконуються роботи з логічної розробки та вибору кращих варіантівпроектних рішень, у результаті створюється технічний проект (ТП). У рамках створення технічного проекту проводиться:

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

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

- власне роботи з технічного проектування:

Розробка загальних рішень щодо системи та її частин,

Розробка загальних рішень щодо функціонально-алгоритмічної структурі системи,

Розробка загальних рішень щодо функцій персоналу та організаційної структури,

Розробка загальних рішень щодо структури технічних засобів,

Розробка загальних рішень щодо алгоритмів розв'язування задач та мов,

Розробка загальних рішень щодо організації та ведення інформаційної бази,

Розробка загальних рішень щодо системи класифікації та кодування інформації,

Розробка загальних рішень щодо програмного забезпечення;

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

Розробка та оформлення документації на постачання виробів для комплектування АІС та/або технічних вимог(технічних завдань) з їхньої разработку;

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

Підетап 3. « Робоче проектування пов'язаний з фізичною реалізацією обраного варіанту проекту та отриманням документації робочого проекту (РП).

На цьому підетапі здійснюється:

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

Розробка програм та програмних засобів системи, а також вибір, адаптацію та/або прив'язку придбаних програмних засобів,

Розробка програмної документації.

Організація тендерів на постачання комплектуючих АІС виробів (програмних та технічних засобів, програмно-технічних комплексів, інформаційних виробів).

Малюнок 34. Послідовність робіт на етапі проектування ЖЦ АІС.

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

Третій етап « Реалізація»(Мал. 35) - це фізичне проектування системи в наступній послідовності:

1) отримання та встановлення технічних засобів;

2) кодування, тестування та доведення програм;

3) отримання та встановлення програмних засобів;

4) створення інформаційного забезпечення, включаючи заповнення баз даних;

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

Ці роботи практично можуть здійснюватися паралельно.

На четверному етапі ЖЦ АІС Впровадження» Існують такі підетапи:

1) дослідне використання:

· Введення в дослідну експлуатацію технічних засобів,

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

· Навчання та сертифікування персоналу.

Досвідчене використанняполягає у перевірці працездатності елементів та модулів проекту, усуненні помилок на рівні елементів та зв'язків між ними.

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

Реалізацію проектних рішень щодо організаційної структури АІС;

забезпечення підрозділів об'єкта управління інструктивно-методичними матеріалами;

Впровадження класифікаторів інформації;

Навчання персоналу,

Перевірка його здатності забезпечити функціонування АІС.

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

Здійснюють випробування АІС на працездатність та відповідність технічному завданню відповідно до підготовлених заздалегідь програм та методики попередніх випробувань;

Усунення несправностей та доопрацювання (за потреби) програмного забезпечення, внесення змін до документації на АІС, у тому числі експлуатаційну відповідно до протоколу випробувань.

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

2) промислове використання (здавання в промислову експлуатацію):

· Здача в експлуатацію,

· Підписання актів приймання-здавання робіт.

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

Проводять випробування на відповідність технічному завданню відповідно до підготовлених заздалегідь програмою та методикою приймальних випробувань;

Аналіз результатів випробувань АІС та усунення недоліків, виявлених при випробуваннях.

Закінчуються роботи про формуванням акта про приймання АІС у постійну експлуатацію.

На останньому п'ятому етапі ЖЦ АІС виконуються експлуатація, супровід та модернізаціяпрограмних, технічних засобів та всього проекту.

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

Післягарантійне обслуговування полягає:

У виконанні робіт з аналізу функціонування системи;

у виявленні відхилень фактичних експлуатаційних характеристик АІС від проектних значень;

у встановленні причин цих відхилень;

усунення виявлених недоліків та забезпечення стабільності експлуатаційних характеристик АІС;

У внесенні необхідних змін до документації на АІС.

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

Малюнок 35. Етапи життєвого циклу АІС.

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

Найбільшого поширення набули три моделі ЖЦ:

· Каскадна модель (до 70-х років) - послідовний перехід на наступний етап після завершення попереднього;

· Ітераційна модель (70 - 80-і роки) - з ітераційними поверненнями на попередні етапи після виконання чергового етапу;

· Спіральна модель (80 - 90-і роки) - прототипна модель, що передбачає поступове розширення прототипу АІС.

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

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

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

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

В основі спіральної моделі ЖЦ є застосування прототипної технології або RAD-технології (rapid application development – ​​технологія швидкої розробки додатків).

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

Природно, що з прототипної технології скорочується кількість ітерацій і менше виникає помилок і невідповідностей, які потрібно виправляти наступних ітераціях, саме проектування здійснюється швидшими темпами, спрощується створення проектної документації. Для більш точної відповідності проектної документації розробленої АІС все більшого значення надається веденню загальносистемного репозитарію та автоматизації проектування, зокрема використанню CASE (Computers Aids System Engineering)-технологій.

При використанні спіральної моделі:

· відбувається накопичення та повторне використання проектних рішень, засобів проектування, моделей та прототипів АІС та інформаційних технологій;

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

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

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

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

Репозитарій містить інформацію про об'єкти проектованої АІС та взаємозв'язки між ними, всі підсистеми обмінюються даними з ним.

I. Блоки побудови АІС. Методи та засоби проектування Проектування- процес створення проекту-прототипу, прообразу передбачуваного чи можливого об'єкта, його стану. Сучасна технологіястворення АІС - сукупність ефективних засобів та методів проектування, що дозволяють спростити цей процес, зменшити вартісні витрати, скоротити календарні терміни проектування системи та, зрештою, за рахунок можливості ширшого вибору перевірених прогресивних проектних рішень, підвищити якість розробки. Основні засоби проектування: -Стандартні засоби операційних систем, що забезпечують автоматичне проходження на ЕОМ певного класу завдань; -процедури, що реалізують типові процеси обробки даних, наприклад контроль вихідної інформації та її сортування; -Інструментальні засоби, до яких відноситься сукупність взаємопов'язаних спеціальних програмних засобів, призначених для інструментальної підтримки окремих елементів процесу проектування АІС. Це створення та актуалізація словника даних, документування проекту, автоматизація контролю проектування та ін; -типові компоненти, представлені у вигляді типових проектних рішень (ТПР) та пакетів прикладних програм (ППП). ТПР – сукупність алгоритмічних, програмних, інструктивно-методичних елементів, що забезпечують машинну реалізацію завдань чи комплексу за допомогою відповідних технічних засобів. ТПР - основа створення ППП, яких ставляться комплекси програм, які забезпечують роботу типових змін обчислювальної техніки, діалогових систем під час вирішення типових функціональних завдань; -Системи автоматизованого проектування (САПР), що передбачають використання ЕОМ на всіх етапах створення АІС і займають вищий щабель в еволюції засобів проектування системи У методах проектування розрізняють класи та підкласи: Класи: -оригінальне проектування. Кошти, що використовуються при цьому методі: - Стандартні засоби операційних систем; - Процедури, що реалізують типові процеси обробки даних. - типове проектування. Підкласи: елементи, підсистеми, об'єктне, групове. Кошти: стандартні засоби операційних систем; типові компоненти (ТПР, ППП); деякі інструментальні засоби. - автоматизоване проектування. Підкласи: модульне; ін Засоби: стандартні засоби операційних систем САПР; взаємопов'язаний комплекс інструментальних засобів Кошти проектування поділяються на: -комплексні - це ТПР, ППП, типові проекти автоматизованих систем, САПР. -локальні - велика різноманітність, до їх складу входять системи управління базами даних, телеобробки, інструментальні засоби та ін. Загальні вимоги до засобів проектування: -повне охоплення всього процесу створення АІС; -сумісність, що вимагає узгоджених рішень як у процесі створення системи та її підсистем, що забезпечують, так і в процесі їх функціонування; -Універсальність у своєму класі, що допускає можливість застосування тих самих засобів для різних об'єктів; -д.б. легко доступними, не потребують особливих зусиль у освоєнні та прості у реалізації; -Можливість організації процесу проектування в режимі інтерактивної взаємодії розробника системи, проектувальника та ЕОМ; -д.б. адаптованими та економічно ефективними. Методи оригінального проектуванняє традиційними та орієнтовані одне підприємство. Характерна риса- розробка оригінальних методик обстеження об'єкта, його впровадження, створення необхідної проектної документації як індивідуального проекту. Гідність - відображення у проекті АІС специфічних особливостей об'єкта автоматизації. Недоліки: порівняно висока трудомісткість і великі терміни розробки, низький показник функціональної надійності та адаптованості до умов, що змінюються. Проекти, створені оригінальним методом, піддаються модернізації, однак у чистому виглядіцей метод використовується рідко. При його реалізації використовуються в даний час різні засоби проектування і лише для окремих частин проекту потрібні оригінальні проектні рішення. Так, загальносистемні проектні рішення щодо розробки інформаційного забезпечення включають методи збору, контролю та передачі даних, створення нормативно-довідкових масивів інформації, за програмним забезпеченням, визначають версію операційної системи, типові процедури обробки інформації та ін. Це дещо згладжує його недоліки. Цей метод особливо актуальний під час автоматизації складних, неординарних об'єктів. Типове проектування- індустріальний метод створення АІС, який використовує ТПР та ППП, характеризується наявністю апробованих, типових організаційно-економічних, технічних, інформаційних, математичних та програмних засобів автоматизації управління. Позитивні якості: зменшує трудомісткість, знижує вартість і скорочує терміни проектування, підвищуючи його якість шляхом більш повного охоплення завдань функціональних підсистем, суворого дотримання вимог нормативних документівзастосування передових технічних рішень. Типове проектування покликане усунути дублювання проектів, створити основу для розширення обміну готовими типовими компонентами, полегшити розробку рекомендацій щодо зміни організаційної структури та методів управління з урахуванням галузевих та внутрішньогосподарських особливостей. Процес типового проектування полягає у виборі та прив'язці зазначених коштів відповідно до треб-ми конкретної системи. Типова частина АІС є комплексом інформаційного, програмного і технічного забезпечення. Типовий характер першого досягається шляхом суворого дотримання єдності структури інформаційної бази, складу масивів, форм вхідних та вихідних документів; другого- на використанні ППП, і останнього в результаті застосування ЕОМ одного або спільних типів. Основами елементного проектуванняє ТПР - результат виконання кількох взаємозалежних технологічних операцій проектування, розробки проекту використовується вже готове рішення з невеликими модифікаціями, а чи не розробляється нове. Комплекс типових проектних рішень поділяється на три групи: "Техніка", "Завдання", "Персонал". Перша групаслужить для вибору та комплектації всіх видів технічних засобів обчислювальних центрів або інших організаційних форм їх застосування. Друга- містить документацію щодо організаційно-економічної сутності кожного завдання, алгоритми їх вирішення, опис вхідної та вихідної інформації, відповідні програмні модулі з їх описами та інструкціями щодо застосування. Третя- Посадові інструкції всіх категорій працівників, що визначають їх права та обов'язки. ТПР створюються за модульним принципом, коли кожне проектне рішення розчленовується на окремі складові частини-модулі, які реалізують певну частину ТПР. Це дозволяє створити проект нової автоматизованої системи шляхом поєднання окремих типових модулів. При використанні підсистемного методупроектування передбачається більш високий рівень інтеграції типових елементів системи, коли кожної підсистеми створюються проекти рішень і пакети прикладних програм. Виділення підсистем-залежно від об'єкта господарсько-виробничого процесу. Для кожної з підсистем розробляється своє автоматизоване проектне рішення та ППП, які можуть бути загальносистемними або функціональними призначеннями. До першої групи належать ППП управління даними, типових процедур їх обробки, методів математичної статистики та дискретного програмування, вирішення безперервних завдань, наприклад диференціальних рівнянь. До другої групи входять пакети, орієнтовані на промислові підприємстваз дискретним чи безперервним характером виробництва, на непромислову сферу, галузеве управління. Важливе вимога, що висувається до ППП,- сумісність, т.к. при проектуванні АІС доцільно використати відразу кілька пакетів. Проектування систем із застосуванням ППП фактично зводиться до прив'язки обраних за певними параметрами пакетів до конкретних умов об'єкта автоматизації. Переваги: ​​менш трудомісткий процес, займає менше часу проти оригінальним проектуванням, реалізує прогресивні методи обробки даних, спрощує документування проекту, т.к. використовується документація пакетів, підвищується надійність проектованих систем. Метод об'єктного проектуваннябазується на застосуванні типових проектів автоматизованих систем керування. Застосовується досить широко, т.к. занадто багато різноманітних об'єктів, а модифікація типового проекту системи відповідно до конкретних умов об'єкта автоматизації вимагає великих трудових та матеріальних витрат. Окремою групою виділяється метод групового проектування. Його сутність: попередньо підбирається група об'єктів, однотипних за характеристиками їх інформаційних систем, Серед них вибирається базовий об'єкт, для якого і розробляється проект, причому можуть використовуватися різні методи та способи проектування, головне це забезпечення його високої адаптивності. Основна сфера застосування цього методу - непромислові об'єкти (наприклад, склади), т.к. вони стійкіші з позиції економічної інформаційної системи. Серед автоматизованих методів особливе місце посідають методи модульного проектування. Створення та використання САПР забезпечує досить високий рівень функціональної надійності, комплексне охоплення всіх технологічних процесів, зниження трудомісткості проектних робіт із максимальним урахуванням інтересів об'єкта автоматизації. Однак цей метод досить дорогий і потребує висококваліфікованих розробників. Ключова вимога до САПР - можливість побудови та підтримки в системі проектування в адекватному стані деякої глобальної економічної інформаційної моделі об'єкта автоматизації. Модель- Відображення інформаційних компонентів об'єкта автоматизації та відношення між ними, задані в явному вигляді. Основна мета побудови моделі - створення відповідного цієї моделі проекту АІС, що враховує та активно використовує всі характеристики об'єкта. Така модель повинна містити у формалізованому вигляді опис сукупностей інформаційних компонентів та відносини між ними, включаючи інформаційні зв'язки та алгоритмічну взаємодію. За допомогою модульного методу проектування застосовується системний підхід, що обумовлює використання ЕОМ не тільки на всіх стадіях створення системи, а й у процесі аналізу результатів її промислової експлуатації. Розвиток та застосування САПР зумовило перехід до створення індивідуальних проектівале на значно вищому рівні, порівняно з оригінальним методом проектування. Розробкою, впровадженням, супроводом та експлуатацією корпоративних інформаційних систем (або скорочено КІС) займаються фахівці з інформаційних технологій (ІТ). Інформаційні технології є дуже широким поняттям, оскільки вони визначають методи та засоби створення, збору, реєстрації, передачі, обробки, зберігання та видачі інформації в інформаційних системах. В даний час поряд з назвою Корпоративні інформаційні системи (КІС) використовуються, наприклад, такі назви: · Автоматизовані системиуправління (АСУ); · Інтегровані системи управління (ІСУ); · Інтегровані інформаційні системи (ІІС); · Інформаційні системи управління підприємством (ІСУП). Основні стадії проектування автоматизованих інформаційних систем · Перед початком проектування АІС необхідно детально обґрунтувати необхідність її створення, докладно описати цілі та завдання проекту, очікуваний прибуток, тимчасові витрати, доступні ресурси, обмеження тощо. Такі роботи часто називають стратегічним плануванням інформаційної системи, та їх здійснення призначається менеджер проекту. Необхідність розробки будь-якої АІС може бути обумовлена наступними факторами: зростанням значущості інформаційного середовища підприємства; комплексністю системи керування підприємством; необхідністю аналізу потенційних можливостей та небезпек підприємства; необхідністю систематизації діяльності підприємства; необхідністю постійного підвищення ефективності використання основних фондів підприємства, покращення співвідношення ціни та якості; підвищення ролі капіталовкладень у сферу інформатизації підприємства; необхідністю кадрового планування для адекватного забезпечення розвитку підприємства; зростанням складності та комплектності існуючих ІВ, що тягне за собою ускладнення функціональних вимог до ІВ та їх розвитку. Головна особливість стратегічного плануванняінформаційної системи у тому, що у період уточнюються потреби організації у інформації, як і визначає можливі варіанти структури інформаційної системи. Залежно від інтенсивності функціонування інформаційно-технологічного комплексу виділяють такі групи організацій: організації, розвиток яких залежить від використання інформаційних технологій для щоденної діяльності (банки, страхові компаніїі т. д.); організації, які залежать від інформаційних технологій, але здатні в майбутньому широко використовувати їх для досягнення конкурентних переваг; організації, у діяльності яких інформаційні технологіїне можуть стати джерелом конкурентної переваги; організації, що використовують інформаційні технології для підтримки діяльності, що не є основною. Для кожної з описаних груп розробляються інформаційні системи, що автоматизують відповідні ділянки діяльності організації. Розробка та впровадження будь-якої АІС здійснюється у певній послідовності відповідно до технічного завдання. Зміст першої черги управлінської системи визначається складом завдань обліку, аналізу, планування та оперативного управління, що найбільше піддаються автоматизації та мають істотне значення для прийняття управлінських рішеньу створенні. У процесі розробки наступних черг системи відбувається розширення та інтеграція інформаційного, програмного та математичного забезпечення, модернізація технічних засобів. Життєвий цикл АІС дозволяє виділити чотири основні періоди: передпроектний, проектний, впровадження, експлуатація та супровід. Технологія проектування автоматизованих інформаційних систем в даний час визначається чинним ГОСТ 34.601-90, згідно з яким весь процес розбитий на стадії та етапи. 1. Стадія «Формування вимог до АІС»: визначення обсягу обґрунтування, необхідного для створення АІС (збір даних про об'єкт автоматизації та здійснювані види діяльності, оцінка якості його функціонування, виявлення проблем, вирішення яких можливе засобами автоматизації, оцінка доцільності створення АІС); формування вимог користувача до АІС; оформлення звіту про виконані роботи та подання заявки на розробку АІС. 2. Стадія "Розробка концепції АІС": вивчення об'єкта АІС; проведення необхідних дослідницьких та проектних робіт; розробка варіантної концепції АІС та вибір варіанта, який задовольняє вимогам користувача, оцінка переваг та недоліків альтернативних варіантів; оформлення звіту про виконану роботу. 3. Стадія «Технічне завдання»: розробка та оформлення технічного завдання на створення АІС ( загальні відомості, призначення та цілі створюваної системи, характеристика об'єкта автоматизації, вимоги до системи в цілому, її функцій та завдань, видів забезпечення, планів робіт зі створення, введення в дію та приймання). 4. Стадія «Ескізний проект»: розробка попередніх проектних рішень щодо системи та її частин (функції АІС, її підсистеми, склад завдань, концепція та структура інформаційної бази, склад та основні характеристики технічних засобів); розробка документації на АІС та її елементи. 5. Стадія « Технічний проект»: розробка проекту рішень за системою та її елементами, за функціональною, алгоритмічною та організаційною структурою системи, структурою технічних засобів, організацією та веденням бази даних, за системою класифікації та кодування інформації, алгоритмом вирішення завдань, що використовуються мовами програмування та програмного забезпечення; розробка документів АІС; розробка та оформлення документації на постачання виробів для комплектування АІС та технічних вимог на їх розробку; розробка завдань проектування. 6. Стадія «Робоче проектування»: розробка робочої документації на систему та її частини; розробка чи адаптація програм. 7. Стадія "Введення в дію": підготовка АІС до впровадження; здавання завдань та підсистем у дослідну експлуатацію; складання звіту про введення у дію. 8. Стадія "Супровід АІС": аналіз функціонування системи; авторський нагляд. Особливість розробки АІС полягає в концентрації складності та трудомісткості на стадіях передпроектного обстеження, оскільки помилки, допущені на етапах обстеження, аналізу та проектування, породжують на етапах впровадження та експлуатації часто нерозв'язні проблемидосягнення поставлених цілей та ефективності використання АІС. Формування вимог до системи передбачає визначення її функціональних можливостей, вимог користувача, вимог до надійності та безпеки, до зовнішніх інтерфейсів і т. д. Планування робіт включає попередню економічну оцінкупроекту, побудова плану-графіка виконання робіт, створення та навчання спільної робочої групи. На цьому етапі здійснюється системний аналіз аналізованої системи, який включає опис структури елементів системи і проведення обстеження діяльності автоматизованого об'єкта; аналіз розподілу функцій за підрозділами та співробітниками, інформаційних потоків усередині підрозділів та між ними, зовнішніх по відношенню до організації об'єктів та зовнішніх інформаційних взаємодій. Fuckyeah. Аналіз завершується побудовою моделей діяльності організації, що передбачають обробку матеріалів обстеження та побудови функціональних та інформаційних моделей двох видів: моделі «as is» («як є»), що відображає існуючий стан справ в організації; моделі «to be» («як має бути»), що відображає уявлення про нові технології та бізнес-процеси організації. За результатами обстеження визначається перелік завдань, вирішення яких доцільно автоматизувати та черговість їх розробки (рис. 8.2). Мал. Результати обстеження Технічне завдання - це документ, що визначає цілі, вимоги та основні вихідні дані, необхідні для розробки АІС та визначення рівня економічної ефективностіїї застосування. Зміст та оформлення технічного завдання регламентуються вимогами ГОСТ 34.602-89. Стадія ескізного проектування передбачає попередній вибір методів проектування та оцінку очікуваних результатів, проте найчастіше ця стадія вводиться до складу технічного проектування. Технічний проект розробляється з метою визначення основних проектних рішень щодо створення системи. На цьому етапі здійснюється комплекс дослідницьких робітдля вибору найкращих варіантів рішень, провіодяться експериментальна оцінка проектних рішень та розрахунок економічної ефективності системи. Для кожного завдання, включеного в комплекс першочергових завдань, виконується детальна постановка задачі та розробка алгоритму її розв'язання. Метою цієї стадії є формування нової структурисистеми та логічних взаємозв'язків її елементів, які функціонуватимуть на обраній технологічній основі. Побудова системної архітектури передбачає виділення елементів та модулів інформаційного, технічного, програмного забезпечення та інших підсистем, що забезпечують зв'язки з інформації та управління між виділеними елементами та розробку технології обробки інформації. Робоче проектування включає розробку специфікацій кожного компонента та матеріалів, що забезпечують ефективну експлуатацію АІС, які містять уточнені дані та деталізовані загальносистемні проектні рішення, програми та інструкції щодо вирішення завдань, а також уточнену оцінку економічної ефективності АІС. Технічна частина робочого проекту передбачає визначення технічних засобів, опис технологічного процесуобробки даних, розрахунок та складання графіка завантаження комплексу технічних засобів, опис режиму функціонування АІС. Впровадження розробленого проекту передбачає виконання наступних етапів: підготовка об'єкта управління до впровадження АІС, дослідне впровадження, тобто перевірка працездатності елементів та модулів проекту та усунення виявлених помилок, та промислове впровадження - етап здачі в експлуатацію та перевірки на рівні функцій, контроль відповідності вимогам , сформульованим на стадії системного аналізу (рис. 8.3) На стадії експлуатації та супроводу збирається статистика щодо якості роботи кожного з компонентів системи, виправляються виявлені недоліки, у деяких випадках приймається рішення про необхідність розширення функціональності системи (рис. 8.4). У цілому нині процес проектування АІС умовно включає у собі тільки основні стадії, а реальний набір етапів і технологічних операцій значною мірою залежить від обраного підходу проектування. Мал. Основні роботи, які виконуються на стадії впровадження АІС Мал. Роботи, що виконуються на стадії експлуатації та супроводу

Моделі ЖЦ АІС –Структура, що визначає послідовне здійснення процесів, дій, завдань, що виконуються протягом ЖЦ та взаємозв'язку між цими процесами.

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

Етапи проекту відповідно до каскадної моделі:

1. Формування вимог;

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

3. Розробка;

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

5. Використання;

6. Експлуатація та супровід.

Переваги:

-Повна та узгоджена документація на кожному етапі;

-Певний порядок послідовності робіт;

-Дозволяє чітко спланувати терміни та витрати.

Недоліки:

-Істотна затримка одержання готових результатів;

-Помилки на будь-якому з етапів виявляються на наступних етапах, що призводить до необхідності повернення та переоформлення проектної документації;

-Складність управління проектом.

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

Кожна ітерація - закінчені цикли розробки у вигляді першої версії АІС.

Етапи ітерації:

1.Формування вимог

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

4.Розробка

5.Інтеграція

На кожній ітерації оцінюються:

Ризик перевищення строків та вартості проекту;

Необхідність виконання ще однієї ітерації;

Ступінь повноти та точності розуміння вимог до системи;

Доцільність припинення проекту.

Переваги:

-Спрощується процес внесення змін до проекту;

-забезпечує велику гнучкість в управлінні проектом;

-Можливість отримання надійної та стійкої системи, т.к. помилки та невідповідності виявляються на кожній ітерації;

-Вплив замовника працювати у процесі перевірки кожної ітерації.

Недоліки:

-Складність планування;

-Напружений режим роботи для розробників;

-Планування робіт проводиться на основі наявного досвіду та недостатньо метрик для вимірювання якості кожної версії.

Вимоги до технології проектування, розробки та супроводу АІС

Технологія проектування- Визначає сукупність трьох складових:

-покрокової процедури, Що визначає послідовність технологічних операцій проектування;

-Правила, що використовуються для оцінки результатів виконання технологічних операцій;

-представлення проектної розробки на експертизу та затвердження.

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

Технологія проектування, розробки та супроводу ІС має задовольняти наступним загальним вимогам:

Технологія має підтримувати повний ЖЦ ПЗ;

Технологія повинна забезпечувати гарантоване досягнення цілей розробки ІВ із заданою якістю та у встановлений час;

Технологія має забезпечувати можливість ведення робіт із проектування окремих підсистем невеликими групами (3-7 осіб). Це зумовлено принципами керованості колективу та підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

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

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

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

-стандарт оформлення проектної документації;

-стандарт інтерфейсу користувача.

Вимога розробки

- Виконання робіт із створення програмного забезпечення;

Підготовка до впровадження АІС;

Контроль, тестування основних показників проекту.

Вимоги до супроводу

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

У процесі супроводу КІС поставлено завдання підтримки її життєздатності. Життєздатність КІС багато в чому визначається наскільки вона відповідає реальним завданням та потребам ВНЗ, які змінюються протягом життєвого циклу КІС.

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

Існує 2 способи опису моделі:

1) статичний, що розглядає структуру моделі, тобто. такі її аспекти, у яких можна знехтувати часом;

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

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

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

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

Малюнок 1 – Модель ієрархічно організованої компанії

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

Серед відомих моделей життєвого циклу АІС можна виділити каскадні, ітераційні та спіральні моделі.

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

Малюнок 2 – Схема каскадної моделі

Перевагикаскадної моделі:

1) на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості;

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

Недолікикаскадної моделі:

1) запізнення із отриманням результатів;

2) украй важливість повернення до попередніх етапів.

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

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

Рисунок 3 – Схема поетапної ітераційної моделі

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

Спіральна модель(80-90 п.) – спирається на початкові етапи життєвого циклу: аналіз, попереднє та детальне проектування.

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

Малюнок 4 – Схема спіральної моделі

В основі спіральної моделі життєвого циклу лежить застосування прототипної технології або RAD-технології ( Rapid Application Development –технології швидкої розробки програм). Відповідно до цієї технології АІС розробляється шляхом розширення програмних прототипів, повторюючи шлях від деталізації вимог до деталізації програмного коду. Природно, що за цієї технології скорочується кількість ітерацій і виникає менше помилок і невідповідностей, які дуже важливо виправляти на наступних ітераціях. При цьому проектування АІС йде швидшим, спрощується створення проектної документації. Для більш точної відповідності проектної документації розробленої АІС все більшого значення надається веденню загальносистемного репозитарію та використанню САSЕ-технологій.

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

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

2) проектування : користувачі беруть участь у технічному проектуванні під керівництвом фахівців-розробників;

3) використання : фахівці-розробники навчають користувачеві роботи в середовищі нової АІС.

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

Існує три класи методологій проектування АІС:

Концептуальне моделювання предметної галузі;

Виявлення вимог та специфікація інформаційної системи через її макетування;

Системна архітектура програмних засобів, що підтримується інструментальними засобами CASE-технології (CASE – Computer Aided Software Engineering – технологія створення та супроводу ПЗ різних систем).

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

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