Модель життєвого циклу - структура, що визначає послідовність виконання та взаємозв'язку процесів, дій та завдань, що виконуються протягом ЖЦ.
Найбільшого поширення набули дві основні моделі ЖЦ:
· Каскадна модель (70-85 рр.);
· Спіральна модель (86-90 рр.).
Каскадна модель
Каскадний спосіб - розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершено роботу на поточному (рис.2).
Позитивні сторони застосування каскадного підходу:
· На кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості;
· Виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Каскадний підхід добре зарекомендував себе при побудові інформаційних систем, для яких на самому початку розробки можна точно і повно сформулювати всі вимоги. До цієї категорії потрапляють складні розрахункові системи, системи реального часу та інші подібні завдання.
Рис.2 Схема каскадного підходу
Однак реально в процесі створення ІС постійно виникає потреба у поверненні до попередніх етапів, уточнення чи перегляду раніше прийнятих рішень. Реальний процес створення інформаційної системинабуває наступного вигляду (рис.3):
Рис.3 Реальний процес створення ІВ на базі каскадної моделі
Одна з назв такої схеми організації робіт, що використовувалися в західній літературі: "водоспадна модель" (waterfall model).
Основним недоліком каскадного підходу є суттєве запізнення з одержанням результатів. Моделі (як функціональні, так і інформаційні) об'єкта, що автоматизується, можуть застаріти одночасно з їх затвердженням. Інший недолік – таке проектування інформаційної системи веде до примітивної автоматизації (по суті – "механізації") існуючих виробничих дій працівників.
У спіральної моделі життєвого циклу (рис.4) наголошується на початкові етапи ЖЦ: аналіз та проектування. Реалізація технічних рішень перевіряється шляхом створення прототипів.
Рис. 4.
Кожен виток спіралі відповідає створенню нового фрагмента чи версії інформаційної системи, у ньому уточнюються цілі та характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Один виток спіралі у своїй є закінчений проектний цикл на кшталт каскадної схеми. Такий підхід називався також "Продовженням проектування". Пізніше проектний цикл додатково стали включати стадії розробки та випробування прототипу системи. Це називалося: "швидке прототипування", rapid prototyping approach або "fast-track".
Однак застосування таких методів поряд із швидким ефектом дає зниження керованості проектом загалом та стикуваності різних фрагментів інформаційної системи. Основна проблема спірального циклу – визначення моменту переходу на наступний етап. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, та особистого досвідурозробників.
Моделі ЖЦ АІС –Структура, що визначає послідовне здійснення процесів, дій, завдань, що виконуються протягом ЖЦ та взаємозв'язку між цими процесами.
Каскадні моделі.Перехід на наступний етап означає повне завершення робіт на попередньому етапі. Вимоги, визначені на стадії формування вимог, суворо документуються як технічного завдання і фіксуються весь час розробки проекту. Кожна стадія завершується випуском повного комплекту документації, достатньої для того, щоб технологія могла бути продовжена іншою командою розробників.
Етапи проекту відповідно до каскадної моделі:
1. Формування вимог;
2. Проектування;
3. Розробка;
4. Тестування;
5. Використання;
6. Експлуатація та супровід.
Переваги:
-Повна та узгоджена документація на кожному етапі;
-Певний порядок послідовності робіт;
-Дозволяє чітко спланувати терміни та витрати.
Недоліки:
-Істотна затримка одержання готових результатів;
-Помилки на будь-якому з етапів виявляються на наступних етапах, що призводить до необхідності повернення та переоформлення проектної документації;
-Складність управління проектом.
Спіральна модель. Кожна ітерація відповідає створенню фрагмента або версії ПЗ, на ній уточнюються цілі та характеристики проекту, оцінюється якість отриманих результатів та плануються роботи наступної ітерації.
Кожна ітерація - закінчені цикли розробки у вигляді першої версії АІС.
Етапи ітерації:
1.Формування вимог
3.Проектування
4.Розробка
5.Інтеграція
На кожній ітерації оцінюються:
Ризик перевищення термінів та вартості проекту;
Необхідність виконання ще однієї ітерації;
Ступінь повноти та точності розуміння вимог до системи;
Доцільність припинення проекту.
Переваги:
-Спрощується процес внесення змін до проекту;
-забезпечує велику гнучкість в управлінні проектом;
-Можливість отримання надійної та стійкої системи, т.к. помилки та невідповідності виявляються на кожній ітерації;
-Вплив замовника працювати у процесі перевірки кожної ітерації.
Недоліки:
-Складність планування;
-Напружений режим роботи для розробників;
-Планування робіт проводиться на основі наявного досвіду та недостатньо метрик для вимірювання якості кожної версії.
Вимоги до технології проектування, розробки та супроводу АІС
Технологія проектування- Визначає сукупність трьох складових:
-покрокової процедури, Що визначає послідовність технологічних операційпроектування;
-Правила, що використовуються для оцінки результатів виконання технологічних операцій;
-Уявлення проектної розробкина експертизу та затвердження.
Технологічні інструкції, що становлять основний зміст технології, повинні складатися з опису послідовності технологічних операцій, умов, залежно від яких виконується та чи інша операція, та описів самих операцій.
Технологія проектування, розробки та супроводу ІС має задовольняти наступним загальним вимогам:
Технологія має підтримувати повний ЖЦ ПЗ;
Технологія повинна забезпечувати гарантоване досягнення цілей розробки ІВ із заданою якістю та у встановлений час;
Технологія має забезпечувати можливість ведення робіт із проектування окремих підсистем невеликими групами (3-7 осіб). Це зумовлено принципами керованості колективу та підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
Технологія повинна передбачати можливість управління конфігурацією проекту, ведення версій проекту та його складових, можливість автоматичного випуску проектної документації та синхронізацію її версій із версіями проекту;
Застосування будь-якої технології проектування, розробки та супроводу ІС у конкретній організації та конкретному проекті неможливе без вироблення низки стандартів (правил, угод), які повинні дотримуватись усіма учасниками проекту. До таких стандартам відносяться такі:
-стандарт проектування;
-стандарт оформлення проектної документації;
-стандарт інтерфейсу користувача.
Вимога розробки
- Виконання робіт із створення програмного забезпечення;
Підготовка до впровадження АІС;
Контроль, тестування основних показників проекту.
Вимоги до супроводу
Завершення впровадження КІС має супроводжуватись публікацією системи адміністративних регламентіві посадових інструкцій, Що визначають порядок функціонування організації З моменту введення інформаційної системи в дію експлуатація відбувається на основі «Регламенту функціонування інформаційної системи» та низки нормативних актів. Супровід системи та її безперебійної роботи здійснюється підрозділом організації, уповноваженим відповідним наказом. Доопрацювання інформаційної системи після введення в експлуатацію здійснюється відповідно до окремих проектів та технічних завдань.
У процесі супроводу КІС поставлено завдання підтримки її життєздатності. Життєздатність КІС багато в чому визначається наскільки вона відповідає реальним завданням та потребам ВНЗ, які змінюються протягом життєвого циклу КІС.
Опис презентації Етапи створення АІС Моделі життєвого циклу АІС за слайдами
Життєвий циклАІС - сукупність стадій та етапів, які проходить АІС у своєму розвитку від моменту прийняття рішення про створення системи до моменту припинення її функціонування.
Етапи життєвого циклу 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), підтримання логічної цілісності даних є ще більш трудомістким завданням. У цьому випадку необхідно регламентувати та реалізувати реплікацію (синхронізацію) даних, уніфікацію довідників, правил кодування та класифікації, розробити чи впровадити сам механізм реплікації. Усе це вимагає організаційних заходів із синхронізації БД. Залишається проблема автоматичного продовження процесу (приклад з випискою рахунку).
Платформи реалізації нової архітектури АІС УП
До початку XXIстоліття в індустрії ІТ розроблені та освоєні на промисловому рівні такі рішення, що забезпечили повсюдне впровадження ІТ в економічні процеси:
інструмент персональних обчислень, що полягає в тому, що в багатьох видах робіт зникла необхідність у посередниках між постановкою завдання та її виконавцем, тобто співробітники функціональних служб підприємства здатні виконувати інформаційні процедури, що знаходяться в їх компетенції, за допомогою комп'ютерів без залучення або з мінімальною підтримкою супроводжуючого технічного персоналу ;
засоби автоматизованої підтримки узгодженої спільної роботи групи («команди») працівників над одним проектом, документом, завданням тощо;
механізм електронних комунікацій, що дозволили у багатьох випадках виключити необхідність передачі паперових документівзвести до мінімуму необхідність у зустрічах, що особливо важливо при територіальній віддаленості учасників того чи іншого ділового процесу.
Завдяки цим рішенням стала можливою автоматизація більшості робочих процесів, що відбуваються як усередині підприємства у його фінансово-господарській, виробничо-комерційній діяльності, так і пов'язаних з зовнішніми функціями. Об'єднання програмних та технічних засобів, що автоматизують різні функції та робочі місця, дозволяє пов'язати в наскрізні бізнес-процеси технологічні (на базі обладнання та технічних пристроїв) та робочі процеси (за участю співробітників усіх підрозділів підприємств). Таким чином, з'являється принципова можливість вирішення проблеми відірваності пунктів виникнення даних від центрів їх зберігання та обробки, роз'єднаності робочих місць один від одного.
Вирішення проблеми інтеграції модулів АІС та вибору централізованого або децентралізованого підходу в організації їх взаємодії також можливе завдяки останнім розробкам провідних виробників системного ПЗ: операційних систем, веб-серверів, серверів додатків, СУБД та платформ проміжного рівня (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 pp. КІС «Флагман» була сертифікована як інформаційна система масштабу підприємства експертами журі конкурсу «Бізнес-Софт», що проводиться Асоціацією розробників програмного забезпечення в галузі економіки (АРЕП), ЦІЕС «Бізнес-Програми-Сервіс», журналом «Бухгалтерський облік» та «Фінансовою газетою» ».
Каскадний підхід добре зарекомендував себе при побудові ІВ, для яких на початку розробки можна досить точно і повно сформувати всі вимоги для того, щоб надати розробникам вільно реалізовувати їх технічно якнайкраще. У цю категорію потрапляють складні системи з великою кількістю завдань обчислювального характеру системи реального часу та ін.
Модель життєвого циклу АІС- це структура, що описує процеси, дії та завдання, які здійснюються та ході розробки, функціонування та супроводу протягом усього життєвого циклу системи.
Вибір моделі життєвого циклу залежить від специфіки, масштабу, складності проекту та набору умов, у яких АІС створюється та функціонує.
Модель ЖЦ АІС включає:
Результати виконання робіт на кожній стадії;
Ключові події або точки завершення робіт та прийняття рішень.
Відповідно до відомих моделей ЖЦ ПЗ визначають моделі ЖЦ АІС - каскадну, ітераційну, спіральну.
I. Каскадна модельописує класичний підхід до розробки систем у будь-яких предметних галузях; широко використовувалася в 1970-80-х роках.
Каскадна модель передбачає послідовну організацію робіт, причому основною особливістю моделі є розбиття всієї роботи на етапи. Перехід від попереднього етапу до наступного відбувається лише після завершення всіх робіт попереднього.
Виділяють п'ятьстійких етапів розробки, що практично не залежать від предметної області
на першимНа етапі проводиться дослідження проблемної галузі, формулюються вимоги замовника. Результатом даного етапує технічне завдання (завдання розробці), узгоджене з усіма зацікавленими сторонами.
В ході другогоетапу, згідно з вимогами технічного завдання, розробляються ті чи інші проектні рішення. В результаті з'являється набір проектної документації.
Третійетап – реалізація проекту; по суті, розробка програмного забезпечення (кодування) відповідно до проектних рішень попереднього етапу. Методи реалізації у своїй принципового значення немає. Результатом виконання етапу є готовий програмний продукт.
на четвертомуНа етапі проводиться перевірка отриманого програмного забезпечення на предмет відповідності вимогам, заявленим у технічному завданні. Досвідчена експлуатація дозволяє виявити різноманітні приховані недоліки, що виявляються в реальних умовах роботи АІС.
Останній етап – здавання готового проекту, і головне тут - переконати замовника у цьому, що його вимоги виконані повною мірою.
Рис.1.1 Каскадна модель ЖЦ АІС
Етапи робіт у рамках каскадної моделі часто називають частинами проектного циклуАІС, оскільки етапи складаються з багатьох ітераційних процедур уточнення вимог до системи та варіантів проектних рішень. ЖЦ АІС істотно складніше і довше: він може включати довільне число циклів уточнення, зміни і доповнення вже прийнятих і реалізованих проектних рішень. У цих циклах відбувається розвиток АІС та модернізація окремих її компонентів.
Переваги каскадної моделі:
1) на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості. На заключних етапах розробляється документація користувача, що охоплює всі передбачені стандартами види забезпечення АІС (організаційне, інформаційне, програмне, технічне тощо);
2) послідовне виконання етапів робіт дозволяє планувати терміни завершення та відповідні витрати.
Каскадна модель спочатку розроблялася на вирішення різноманітних інженерних завдань і втратила свого значення для прикладної області до нашого часу. Крім того, каскадний підхід ідеально підходить для розробки АІС, як вже на самому початку розробки можна досить точно сформулювати всі вимоги з тим, щоб надати розробникам свободу технічної реалізації. До таких АІС, зокрема, належать складні розрахункові системи та системи реального часу.
Недоліки каскадної моделі:
Істотна затримка у отриманні результатів;
Помилки та недоробки на будь-якому з етапів виявляються, як правило, на наступних етапах робіт, що призводить до необхідності повернення;
Складність паралельного ведення робіт із проекту;
Надмірна інформаційна перенасиченість кожного з етапів;
Складність управління проектом;
Високий рівеньризику та ненадійність інвестицій.
Затримка в отриманні результатівпроявляється в тому, що послідовний підхід до розробки узгодження результатів із зацікавленими сторонами проводиться тільки е завершення чергового етапу робіт. В результаті може виявитися, що АІС, що розробляється, не відповідає вимогам, і такі невідповідності можуть виникати на будь-якому етапі розробки; крім того, помилки можуть ненавмисно вноситися і проектувальниками-аналітиками, і програмістами, оскільки вони не повинні добре розумітися на тих предметних галузях, для яких розробляється АІС.
Повернення більш ранні стадії.Цей недолік є з проявів попереднього: поетапна послідовна робота над проектом може призвести до того, що помилки, допущені більш ранніх етапах, виявляються лише наступних стадіях. У результаті проект повертається на попередній етап, переробляється і потім передається в наступну роботу. Це може спричинити зрив графіка та ускладнення взаємовідносин між групами розробників, які виконують окремі етапи.
Найгірший варіант, коли недоробки попереднього етапу виявляються не на наступному етапі, а пізніше. Наприклад, на стадії дослідної експлуатації можуть бути помилки в описі предметної області. Це означає, що частина проекту має бути повернена на початковий етап роботи.
Складність паралельного ведення робітпов'язана з необхідністю узгодження різних частин проекту Чим сильніший взаємозв'язок окремих частин проекту, тим частіше і ретельніше має виконуватися синхронізація, тим більше залежать один від одного групи розробників. В результаті переваги паралельного проведення робіт просто губляться; відсутність паралелізму негативно позначається і організації роботи всього колективу.
Проблема інформаційної перенасиченостівиникає внаслідок сильної залежності між різними групами розробників. Справа в тому, що при внесенні змін до однієї з частин проекту необхідно сповіщати тих розробників, які використовували (можли використати) її у своїй роботі. За наявності великої кількості взаємозалежних підсистем синхронізація внутрішньої документації стає окремою найважливішим завданням: розробники повинні постійно знайомляться із змінами та оцінювати, як позначаться ці зміни на отриманих результатах.
Складність управління проектомв основному зумовлена суворою послідовністю стадій розробки та наявністю складних взаємозв'язків між різними частинами проекту. Регламентована послідовність робіт призводить до того, що одні групи розробників повинні очікувати на результати роботи інших команд, тому потрібне адміністративне втручання для узгодження термінів і складу документації, що передається.
У разі виявлення помилок у роботі необхідне повернення до попередніх етапів; Поточна роботатих, хто схибив, переривається. Наслідком цього є зрив термінів виконання як виправлюваного, і нового проектів.
Спростити взаємодію між розробниками та зменшити інформаційну перенасиченість документації можна, скорочуючи кількість зв'язків між окремими частинами проекту, але далеко не кожну АІС можна розділити на слабко пов'язані підсистеми.
Високий рівень ризику.Чим складніше проекттим довше триває кожен етап розробки і тим складніше взаємозв'язки між окремими частинами проекту, кількість яких також збільшується. Причому результати розробки можна реально побачити та оцінити лише на етапі тестування, тобто після завершення аналізу, проектування та розробки – етапів, виконання яких потребує значного часу та коштів.
Запізнена оцінка породжує серйозні проблеми при виявленні помилок аналізу та проектування - потрібне повернення на попередні стадії та повторення процесу розробки. Однак повернення на попередні стадії може бути пов'язане не тільки з помилками, але і зі змінами, що відбулися в предметній галузі або вимог замовника за час розробки. При цьому ніхто не гарантує, що предметна область знову не зміниться на той момент, коли буде готова наступна версія проекту. Фактично це означає, що існує ймовірність «зациклювання» процесу розробки: витрати на проект постійно зростатимуть, а терміни здачі готового продукту постійно відкладатимуться.
ІІ. Ітераційна модель (Поетапна модель із проміжним контролем) полягає у серії коротких циклів (кроків) з планування, реалізації, вивчення, дії.
Створення складних АІС передбачає проведення погоджень проектних рішень, отриманих під час реалізації окремих завдань. Підхід до проектування «знизу – вгору» обумовлює необхідність таких ітерацій повернень, коли проектні рішення щодо окремих завдань об'єднуються у загальні системні. У цьому виникає потреба у перегляді раніше сформованих вимог.
ПеревагаІтераційна модель у тому, що міжетапні коригування забезпечують меншу трудомісткість розробки в порівнянні з каскадною моделлю.
Недолікиітераційної моделі:
· Час життя кожного етапу розтягується на весь період роботи;
· Внаслідок великої кількості ітерацій виникають неузгодження виконання проектних рішень та документації;
· заплутаність архітектури;
· Проблеми використання проектної документації на стадіях застосування та експлуатації викликають необхідність перепроектування всієї системи.
III. Спіральна модель, На відміну від каскадної, але аналогічно попередньої передбачає ітераційний процес розробки АІС. При цьому зростає значення початкових етапів, таких як аналіз та проектування, на яких перевіряється та обґрунтовується реалізованість технічних рішень шляхом створення прототипів.
Кожна ітерація є закінченим циклом розробки, що призводить до випуску внутрішньої або зовнішньої версії виробу (або підмножини кінцевого продукту), яке вдосконалюється від ітерації до ітерації, щоб стати закінченою системою (рис. 1.2).
Мал. 1.2. Спіральна модель ЖЦ АІС
Таким чином, кожен виток спіралі відповідає створенню фрагмента або версії програмного виробу, на ньому уточнюються цілі та характеристики проекту, визначається його якість, плануються роботи на наступному витку спіралі. Кожна ітерація служить поглиблення і послідовної конкретизації деталей проекту, у результаті вибирається обгрунтований варіант остаточної реалізації.
Використання спіральної моделі дозволяє здійснювати перехід на наступний етап виконання проекту, не чекаючи повного завершення поточного - недороблену роботу можна буде виконати на наступній ітерації. Головна задачакожної ітерації – якнайшвидше створити працездатний продукт для демонстрації користувачам. Таким чином, суттєво спрощується процес внесення уточнень та доповнень до проекту.
Спіральний підхід до розробки програмного забезпечення дозволяє подолати більшість недоліків каскадної моделі, крім того забезпечує ряд додаткових можливостей, роблячи процес розробки більш гнучким.
Перевагиітераційного підходу:
Ітераційна розробка суттєво спрощує внесення змін до проекту за зміни вимог замовника;
З використанням спіральної моделі окремі елементи АІС інтегруються у єдине ціле поступово. Оскільки інтеграція починається з меншої кількості елементів, виникає набагато менше проблем при її проведенні;
Зниження рівня ризиків (наслідок попередньої переваги, оскільки ризики виявляються саме під час інтеграції). Рівень ризиків є максимальним на початку розробки проекту, у міру просування розробки він знижується;
Ітераційна розробка забезпечує велику гнучкість в управлінні проектом, даючи можливість внесення тактичних змін до виробу, що розробляється. Так, можна скоротити терміни розробки за рахунок зниження функціональності системи або використовувати як складові продукцію сторонніх фірм замість власних розробок (актуально при ринкової економікиколи необхідно протистояти просуванню виробу конкурентів);
Ітераційний підхід спрощує повторне використання компонентів, оскільки набагато простіше виявити (ідентифікувати) загальні частини проекту, коли вони вже частково розроблені, ніж намагатися виділити їх на початку проекту. Аналіз проекту після кількох початкових ітерацій дозволяє виявити загальні компоненти, які багаторазово використовуються, які на наступних ітераціях будуть удосконалюватися;
Спіральна модель дозволяє отримати більш надійну та стійку систему. Це з тим, що з розвитком системи помилки і слабкі місця виявляються і виправляються кожної ітерації. Одночасно коригуються критичні параметри ефективності, що у разі каскадної моделі є лише перед використанням системи;
Ітераційний підхід дозволяє вдосконалювати процес
розробки - в результаті аналізу наприкінці кожної ітерації проводиться оцінка змін організації розробки; на наступній ітерації вона покращується.
Основна проблема спірального циклу- Проблема визначення моменту переходу на наступний етап. Для її вирішення необхідно запровадити тимчасові обмеження на кожен із етапів життєвого циклу. Інакше процес розробки може перетворитися на нескінченне вдосконалення вже зробленого.
Залучення користувачів у процес проектування та копіювання програми дозволяє отримувати зауваження та доповнення до вимог безпосередньо у процесі проектування програми, скорочуючи час розробки. Представники замовника отримують можливість контролювати процес створення системи та впливати на її функціональне наповнення. Результатом є здавання в експлуатацію системи, яка враховує більшість потреб замовників.
Модель життєвого циклу та технологія проектування
Раніше ми говорили, що технологія проектування визначає послідовність дій, необхідних для отримання проекту ІС. Очевидно, що виконання кожної з таких дій означає перехід інформаційної системи з одного стану до іншого. Отже, будь-яка технологія проектування однозначно описує деяку модель життєвого циклу. З іншого боку, побудувавши модель життєвого циклу інформаційної системи, тобто:
· Завдання, склад і послідовність виконуваних робіт;
· Отримувані результати кожної виконуваної дії;
· Методи та засоби, необхідні для виконання робіт;
· Ролі та відповідальність учасників;
· Іншу інформацію, необхідну для планування, організації та управління колективною розробкою ІВ,
ми отримаємо однозначний опис обраної нами технології проектування. Таким чином, модель життєвого циклу – це невід'ємна та найважливіша частина технології проектування інформаційних систем.
Етапи та стадії проектування
Часто змішують поняття «етап» та «стадія» проектування. Іноді говорять про етапахабо фазахжиттєвого циклу, крокахпроектування. Постає питання: як правильно?
Слід пам'ятати, що у різних міжнародних стандартахвикористовується термінологія може відрізнятися. Ми, по можливості, орієнтуватимемося на термінологію вітчизняних ГОСТів. Етапом проектуванняназиватимемо частину процесу створення ІВ, обмежену деякими часовими рамками і закінчується випуском конкретного продукту (моделі, документації, тексту програми тощо).По спільності цілей етапи проектування можуть об'єднуватися в стадії. Наприклад, стадія "Технічний проект", стадія "Впровадження" тощо.
За опублікованими даними кожен етап розробки АІС потребує певних витрат часу. В основному (45-50%) час йде на кодування, комплексне та автономне тестування. У середньому розробка АІС займає третину всього ЖЦ системи.
Мал. Розподіл часу під час розробки АІС
Стадії створення АІС (ISO/IEC 15288)
Стандарт ISO/IEC 12207 визначає структуру життєвого циклу, що містить процеси, дії та завдання, які мають бути виконані під час створення інформаційної системи.
