Визначення моделі жц аїс. Моделі ЖЦ АІС. Каскадна та спіральна схеми проектування АІС. Позитивні сторони та недоліки Життєвий цикл та моделі життєвого циклу аіс

3.1 Визначення моделі ЖЦ АІС

Під моделлю життєвого циклу розробки програмного продукту розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань, що виконуються протягом життєвого циклу розробки програмного продукту. Найбільшого поширення набули такі моделі життєвого циклу розробки програмного продукту (таблица1. Короткі характеристикимоделей життєвого циклу АІС): каскадна модель, або водоспад (waterfall model); v-подібна модель (v-shaped model); модель прототипування (prototype model); модель швидкої розробки додатків, або RAD-модель (RAD-rapid application development model); багатопрохідна модель (incremental model); спіральна модель (Spiral model).

Таблиця 1. Короткі характеристики кожної з перерахованих моделей

Назва	Характеристики
Каскадна модель	Прямолінійна та проста у використанні. Потрібний постійний жорсткий контроль за ходом роботи. Розроблене програмне забезпечення недоступне для змін
v-подібна модель	Проста у використанні. Особливого значення надається тестуванню та порівнянню результатів фаз тестування та проектування
Модель прототипування	Створюється швидка часткова реалізація системи до складання остаточних вимог. Забезпечується зворотний зв'язок між користувачами та розробниками у процесі виконання проекту. Використані вимоги не повні
Модель швидкої розробки додатків	Проектні групи невеликі (3…7 осіб) та складені з висококваліфікованих спеціалістів. Зменшений час циклу розробки (до 3 місяців) та покращена продуктивність. Повторне використання коду та автоматизація процесу розробки
Багатопрохідна модель	Швидко створюється діюча система. Зменшується можливість внесення змін у процесі розробки. Неможливий перехід від поточної реалізації до нової версіїпротягом побудови поточної часткової реалізації
Спіральна модель	Охоплює каскадну модель. Розчленовує фази на менші частини. Дозволяє гнучко виконувати проектування. Аналізує ризики та керує ними. Користувачі знайомляться з програмним продуктом на ранньому етапі завдяки прототипам

3.2 Каскадна модель

У однорідних інформаційних системах 1970-х і 1980-х років прикладні програмні продукти були єдиним цілим. Для розробки такого типу програмного продукту застосовувалась каскадна модель, або «водоспад».

Каскадна модель програмного продукту подібна до моделі автоматизованої системи управління (див. розділ 1, рис.1).

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

3.3 V-подібна модель

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

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

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

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

Модель включає наступні фази:

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

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

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

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

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

Модульне тестування – виконується перевірка кожного компонента чи модуля програмного продукту;

Інтеграційне тестування – здійснюються інтеграція програмного продукту та його тестування;

Системне тестування – виконується перевірка функціонування програмного продукту після поміщення його в апаратне середовище відповідно до специфікації вимог;

Експлуатація та супровід – запуск програмного продукту у виробництво. На цій фазі програмний продукт можуть вносити поправки і може виконуватися його модернізація.

Рис.5 V-подібна модель

Переваги v-подібної моделі:

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

2) Передбачаються атестація і верифікація як самого програмного продукту, а й усіх отриманих внутрішніх та зовнішніх данных;

3) Хід виконання роботи може легко відстежуватися, оскільки завершення кожної фази є контрольною точкою.

Крім перерахованих переваг модель має і ряд недоліків:

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

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

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

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

Тема 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 Впровадження (тестування, дослідна експлуатація) – встановлення та введення системи в дію, налагодження підсистем, навчання персоналу. Оформлення акта про приймально-здатні випробування.

Зауваження 1. Етапи 2 і 3 можна поєднати в одну: техно-робоче проектування або системний синтез. 2. На кожному етапі життєвого циклу використовується певний набір технічних рішень та відповідних документів

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

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

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

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

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

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

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

Вступ

1. Архітектура автоматизованих інформаційних систем та проблеми її вдосконалення 13

1.1. Моделі архітектури та основні компоненти АІС 13

1.2. Проблеми розвитку АІС 47

1.3. Платформи реалізації нової архітектури АІС УП 53

1.4. Висновки за розділом 157

2. Модель архітектури АІС УП 58

2.1. Основні вимоги до АІС УП 59

2.2. Архітектура АІС УП 66

2.3. Компоненти АІС УП 89

2.4. Висновки за розділом 2102

3. Методи практичної реалізації АІС УП 104

3.1. Інструментальні засоби розробки АІС УП 104

3.2. Досвід практичної реалізації моделі АІС УП 111

3.3. Висновки за розділом 3123

4. Висновок 125

5. Термінологія та абревіатури 128

6. Література

Введення в роботу

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

Протягом останніх 40 років автоматизовані інформаційні технології (ІТ) активно застосовуються для вирішення завдань обліку, планування та аналізу господарської діяльностіпідприємств різних форм власності, галузевої власності, організаційної структури та масштабів діяльності. За цей час накопичено великий практичний досвід створення автоматизованих інформаційних систем управління підприємствами (АІС УП), розроблені та отримали загальне визнання методології управління, застосування яких неможливе поза комп'ютерним середовищем. Можна повною відповідальністю стверджувати, що АІС УП стали невід'ємною складовою інфраструктури бізнесу. Теоретичні та практичні проблеми автоматизації економічних процесів глибоко досліджено у роботах Глушкова В.М., Волкова СІ., Ісакова В.І., Островського О.М., Подільського В.І., Ратмирова Ю.А., Романова О.М. , Хотяшова Е.Н., Бреді Р., Захмана Дж., Кука М., Фінкельштейна К., Хаммера М. та інших авторів. Запропоновані ними підходи стали базою для застосування обчислювальної техніки на підприємствах під час вирішення завдань обліку, планування та аналізу фінансово-господарської діяльності. Проте

пропоновані ними моделі не враховували реалій економіки інформаційного суспільства та нинішнього рівня розвитку ІТ.

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

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

У публікаціях вчених та практиків давно обговорюється ідея реалізації стандартів системної інтеграції програмних засобів, що постачаються різними виробниками. Прогрес системного інструментарію призвів до появи об'єктно-орієнтованих та компонентних технологій розробки програмного забезпечення, які дозволяють будувати великомасштабні системи з готових блоків. Провідні постачальники апаратного та системного програмного забезпечення (Intel, Microsoft, Sun, Oracle, IBM та ін.), комунікаційних засобів (Cisco, Nortel, Ericsson, Motorola), прикладних рішень (SAP, PeopleSoft, Siebel та ін.), авторитетні державні, міжнародні, комерційні та некомерційні організаціїта асоціації (ISO, IEEE, ASCII, APICS, РосСтандарт та ін.) на даний момент розробили та активно впроваджують на практиці технології інтеграції апаратних та програмних засобів, що дозволяють створювати відкриті системи на базі стандартів та протоколів обміну даними та взаємодії компонентів у гетерогенному середовищі режим реального часу.

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

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

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

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

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

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

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

Дослідити існуючі технології та стандарти, що забезпечують інтеграцію різноманітних програмних засобів;

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

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

Розробити модель архітектури АІС УП та виділити основні її складові;

Розробити принципи взаємодії та обміну даними компонент АІС УП;

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

Об'єктом дослідження є ІС управління підприємствами.

Методика дослідження заснована на конкретних додатках методології наукового пізнання у прикладних напрямках інформатики та математики.

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

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

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

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

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

Методологій планування та оперативного управління виробництвом та матеріальними запасами;

Реінжинірингу та комп'ютерного проектування бізнес-процесів;

Сучасних стандартів в інформаційних технологіях.

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

Інформаційну базу дослідження склали програмні продукти російських та зарубіжних виробників, публікації в економічних та комп'ютерних виданнях, дослідження міжнародних дослідницьких груп Gartner Group, Aberdeen, IDC, MetaGroup, DataQuest та ін. методичні матеріалипровідних вітчизняних та міжнародних консалтингових та аудиторських компаній, результати досліджень Асоціації розробників програмного забезпечення в галузі економіки,

дослідження ринку програмного забезпечення Росії та країн СНД ЦІЕС "Бізнес-Програми-Сервіс".

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

Наукову новизну містять такі результати, отримані у дисертації:

Визначення та класифікація вимог до функціональних можливостей ПЗ організаційно-економічного управління підприємствами;

Модель архітектури АІС УП, яка орієнтована на комплексну автоматизацію наскрізних бізнес-процесів;

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

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

Пропозиції щодо реалізації єдиної системиформування та класифікації звітності із застосуванням аналітичного інструментарію;

Принципи реалізації взаємодії підсистем АІС УП на базі об'єктно-орієнтованих та компонентних технологій та взаємодії програмних компонентів у розподіленій мережевій

середовищі відповідно до промислових стандартів та протоколів Інтернет;

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

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

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

Самостійне практичне значеннямають:

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

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

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

Пропозиції щодо адаптації спірально-ітераційного підходу при розробці та впровадженні ПЗ АІС УП.

Практичну значущість роботи оцінено в конкретних проектах реалізації запропонованої проблемно-орієнтованої моделі системи автоматизації підприємства:

Комплексної системи управління підприємством "Флагман" компанії "Інфософт",

Системи управління взаємовідносинами з клієнтами "eRelationship" корпорації "Pivotal Software" (Канада),

Системи корпоративної звітності Monarch ES компанії DataWatch (США),

Проекту інтеграції інформаційних систем компаній «Совінтел» та «Теле Росс».

Навчальний центр компанії "Весть-МетаТехнологія" застосовує матеріали, підготовлені автором на основі підходу, запропонованого в ході даного дослідження, при проведенні курсів з розробки інформаційних систем управління підприємствами (див. http://www.vest.msk.ru).

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

Основні положення роботи доповідалися та обговорювалися на:

Конференції "Рішення IBM в галузі інтеграції бізнесу для телекомунікаційних компаній", представництво IBM у Східній Європі (м. Москва, 18 червня 2002);

Симпозіумі "Call Center CRM Solutions 2002/Центри обробки викликів та управління взаємовідносинами з клієнтами" (м. Москва, березень 2002);

Конференції розробників інформаційних систем з урахуванням інструментарію корпорації Centura Software Corp. (м. Берлін, Німеччина, 17-19 листопада 1999 р.);

Конференції «ІнфоМісто: практика та проблеми інформатизації міст» (м. Москва, жовтень 1999 р.);

Науково-практичні конференції фірми «Інфософт» (м. Москва, 1995-1999 рр.);

Конференції фахівців у галузі АСУ та КІС «Корпоративні системи» (Москва, квітень 1998 р. та 28-30 квітня 1997 р., організатори: компанія «СофтСервіс» та представництва компаній Oracle, Informix, Sybase, Borland та Centura);

3-ї щорічної конференції «Корпоративні бази даних 98» (Москва, 31 березня-3 квітня 1998 та 26-29 березня 1996 р., організатори «Центр Інформаційних технологій» за участю ВД «Відкриті системи»);

Конференції "Техніком-97" (Москва, 24-26 листопада 1997 р., організатори: фірма "СофтСервіс", Російська АсоціаціяКористувачів Oracle, представництва компаній Microsoft, Borland, Computer Associates, Lucent Software).

Проблеми розвитку АІС

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

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

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

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

Узагальним плюси та мінуси різних варіантів архітектури ІС з погляду можливостей побудови інтегрованого рішення.

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

Проте, навіть якщо центральний сервер БД здатний забезпечити необхідну продуктивність, за такої побудови ІС неминуче виникають проблеми підтримки єдиної структури загальної БД, якщо окремі програмні компоненти ІС розробляються різними компаніямиабо навіть командами розробників усередині тієї самої організації. Установка загальної бази з доступом з програм вирішення різних прикладних завдань дозволяє забезпечити загальний інформаційний простір, перераховані вище технології дозволяють звертатися до БД великої кількості користувачів, проте це не дає гарантії правильної роботи з даними, що поділяються. Залишається проблема логічної цілісності даних. При використанні програм різних виробників стає неминучим поділ даних за підсистемами, можливо, шляхом їх денормалізації та створення надлишкових структур. Схематично архітектура із загальною базою представлена ​​наступному малюнку (Малюнок 1-14). Як випливає із наведеної схеми, модулі не взаємодіють, тобто немає виклику одного модуля іншим у режимі реального часу, немає оперативної підтримки наскрізного процесу. Дані зберігаються в базі, з яких вони доступні іншим модулям, яким необхідно містити функції відстеження змін, а від частоти перевірки оновлень залежить актуальність даних. Прикладом наскрізного процесу то, можливо виписка рахунку співробітником відділу збуту. Якщо він використовує для цього CRM-систему, сформований рахунок паралельно з випискою повинен бути оброблений у модулі логістики ERP-системи для резервування товару, і відразу після цього – фінансовим модулем збільшення заборгованості покупця. Для цього відповідні модулі мають перевірити наявність нового рахунку. Якщо цього зробити своєчасно, то, можливо виписаний рахунок на фактично зарезервований товар.

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

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

Платформи реалізації нової архітектури АІС УП

На початку ХХІ століття в індустрії ІТ розроблені та освоєні на промисловому рівні такі рішення, що забезпечили повсюдне впровадження ІТ у економічні процеси:

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

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

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

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

Вирішення проблеми інтеграції модулів АІС та вибору централізованого або децентралізованого підходу в організації їх взаємодії також можливе завдяки останнім розробкам провідних виробників системного ПЗ: операційних систем, веб-серверів, серверів додатків, СУБД та платформ проміжного рівня (middleware platforms). Інтеграція додатків стає можливою за рахунок застосування об'єктно-орієнтованої технології розробки та компонентної багатоланкової архітектури. Ключовим принципом тут є поняття програмних інтерфейсів та регламенту їх зміни та розширення (мова IDL).

Для роботи в розподіленому гетерогенному середовищі, яким є Інтернет, активно розробляються специфікації веб-служб (web services), кожна з яких може реалізувати одну або кілька бізнес-процедур або функцій (business procedures, functions). Організація OASIS, інститут BPMI та компанії IBM, Microsoft та ВЕА опублікували специфікації регулювання потоків робіт у рамках бізнес-процесів BPEL4WS (Business Process Execution Language for Web Services), мови веб-служб XLANG та WSFL (Web Services Flow Language), а коаліція WfML - XPDL (XML Process Definition Language).

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

Технічних перешкод для реалізації подібної архітектури немає. Сучасні промислові сервери додатків (наприклад, MTS/COM+/.Net, ONE або J2EE/EJB) дозволяють будувати багатоланкові системи, надають загальну платформу для доступу до різних веб-служб, забезпечують транзакційну цілісність операцій, балансування навантаження за конкурентного доступу десятків тисяч користувачів в режимі реального часу, а також гарантують відмовостійкість та відновлення після збоїв.

Важливим досягненням індустрії ІТ є широкі поширення і визнані провідними виробниками ПЗ стандарти: протоколи взаємодії компонентів (COM/DCOM, CORBA, Java RMI ) і формати обміну даними (EDI, XML , ).

Стандарт EDI та його галузеві варіанти (EDIFACT, XI2, HIPAA та ін.) експлуатуються у фінансовій та виробничій сфері Північної Америки та Європи з середини 70-х і домінують на сьогоднішній день у всьому світі. Зі зростанням популярності XML в Інтернеті EDI був переведений на XML.

На базі XML (DTD і XDR) розроблені, структуровані та форматовані дані у різних економічних сферах у вигляді так званих предметних словників або типів документів, наприклад, WIDL, OFX, FpML, IFX, XBRL, CRML та численні інші на Заході, а також CommerceML.ru та XML Partnership/ARB у Росії. Американське товариство з управління виробництвом та запасами APICS, яке займається сертифікацією систем класу ERP/MRP, публікує специфікації економічних сутностей у форматі XML, наприклад, структуру та формат даних клієнта або рахунку-фактури. Самодокументованість XML забезпечує однозначне розуміння даних як людиною, і програмами.

Архітектура АІС УП

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

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

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

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

Як ядро ​​АІС УП необхідно розробити систему, що поєднує кілька функцій, розглянутих в огляді систем управління процесами (параграфи «1.1.7 Системи управління документообігом» на стор. 31 та «1.1.8 Системи управління процесами» на стор. 34). Серед них: Workflow - підсистема управління робочими та технологічними процесами, що забезпечує зумовлену та вільну маршрутизацію завдань між виконавцями; Docflow - підсистема управління документообігом та маршрутизацією документів з відстеженням їх станів; Groupware - підсистема підтримки функцій оперативного призначення завдань та вільної машрутизації (ad hoc) завдань між членами групи виконавців; Dataflow – маршрутизація даних, пакетів даних, повідомлень між програмами.

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

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

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

Досвід практичної реалізації моделі АІС УП

З 1995 по 1999 роки під керівництвом автора дисертації була розроблена система комплексної автоматизації управління підприємством «Флагман» компанії «Інфософт», яка на поточний момент впроваджена у більш ніж ста великих і середніх промислових, будівельних, комерційних, сільськогосподарських підприємствах та бюджетних організаціяхРосії та країн СНД. Система продовжує розвиватися на базі ядра, розробленого автором, і до 2002 року "Флагман" включає понад десять основних підсистем, представлених на наступному малюнку (Малюнок 3-2):

Основою системи «Флагман» є базовий модуль «Документообіг», який відповідає за введення, обробку, маршрутизацію та друк усіх первинних документів. Іншими базовими модулями є "Адміністрування" та "Інструментальні засоби", спільні для всіх функціональних модулів. Вони дозволяють налаштовувати рольові групи та права доступу, АРМ аж до пунктів меню, макетів документів та шаблонів звітів.

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

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

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

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

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

Слід зазначити, що у системі «Флагман» реалізований уніфікований зовнішній виглядпідсистем. Загальний модуль адміністрування елементів інтерфейсу користувача, функцій АРМ, включаючи меню і панель інструментів, дозволяє налаштовувати зовнішній вигляд одноманітно.

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

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

У лютому 1999 р. система "Флагман" фірми "Інфософт", створена під керівництвом автора, була визнана найкращою російською розробкою на інструментарії Centura Team Developer корпорацією Centura Software Corp. (США) та компанією «Інтерфейс» (Росія). У 1999, 2000 та 2001 гг. КІС «Флагман» була сертифікована як інформаційна система масштабу підприємства експертами журі конкурсу «Бізнес-Софт», проведеного Асоціацією розробників програмного забезпечення в галузі економіки (АРЕП), ЦІЕС «Бізнес-Програми-Сервіс», журналом «Бухгалтерський облік» та «Фінансовою газетою» ».

Канонічне проектування АІС

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

Існує три класи методологій проектування АІС:
· Концептуальне моделювання предметної області;
· Виявлення вимог та специфікація інформаційної системи через її макетування;
· Системна архітектура програмних засобів, що підтримується інструментальними засобами CASE-технології (CASE - Computer Aided Software Engineering - технологія створення та супроводження ПЗ різних систем).

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

1. Формування вимог до АС.
2. Розробка АС концепції.
3. Технічне завдання.
4. Ескізний проект.
5. Технічний проект
6. Робоча документація.
7. Введення у дію.
8. Супровід АС.

Можна виділити три періоди створення системи: передпроектне, проектування, введення в експлуатацію.
Стадії 1, 2, 3 відносяться до першого періоду, стадії 4, 5, 6 - до другого періоду, стадії 7, 8 - до третього.
У передпроектний період розробляють техніко-економічне обґрунтування (ТЕО) та технічне завдання(ТЗ) на проектування системи. У цей період на стадії формування вимог до АС проводять три етапи робіт:

• обстеження об'єкта предметної галузі та обґрунтування необхідності створення системи;
• формування вимог користувачів до системи;
• складання звіту про виконану роботу та заявки на розробку системи.

На стадії розробки концепції АС проводять чотири етапи робіт:

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

На 3-й стадії розробляють та затверджують технічне завдання на створення АС.
Технічне завдання (ТЗ)це перелік основних експлуатаційних, технологічних економічних та інших вимог, яким повинен задовольняти проектований об'єкт на всіх етапах його існування. Після затвердження ТЗ починається другий період створення АС – період проектування системи.
Проектування -процес обґрунтованого вибору характеристик системи, формування логіко-математичних та економіко-математичних моделей, розроблення документації.
На стадії створення ескізного проекту на 1-му етапі розробляють попередні проектні рішення щодо системи та її частин, на 2-му — документацію на АС та її частини.
На 5 стадії при створенні технічного проекту в чотири етапи проводять розробку:

• проектних рішень за системою та її частинами;
• документації на АС та її частини;
• документації на постачання виробів для комплектування АС та ТЗ на їх розробку;
• завдань н# проектування у суміжних частинах проекту об'єкта автоматизації.

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

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

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

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

Для АІС умовно виділяють такі основні етапи їхнього життєвого циклу:
1. аналіз - визначення те, що повинна робити система;
2. проектування - визначення того, як система функціонуватиме: насамперед специфікація підсистем, функціональних компонентів та способів їх взаємодії в системі;
3. розробку - створення функціональних компонентів та окремих підсистем, з'єднання підсистем в єдине ціле;
4. тестування - перевірку функціональної та параметричної відповідності системи показникам, визначеним на етапі аналізу;
5. Використання - встановлення і введення системи в дію;
6. супровід - забезпечення штатного процесу експлуатації системи на підприємстві замовника.

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

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

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