Впровадження інформаційних систем і CASE-засоби

Зміст
1.Склад і зміст робіт на стадії впровадження інформаційних систем
2.Технологія проектування систем за CASE-методом
3.Визначення інформаційних систем управління
Висновки
Список використаної літератури

1. Склад і зміст робіт на стадії впровадження інформаційних систем
У вітчизняних стандартах процес впровадження АІС обліку складається з етапів, етапи ділять на стадії, стадії складаються з робіт, табл. 1.1 (Зірочкою помічені обов'язкові стадії).
Табл. 1.1. Стадії, етапи і роботи із створення АІС
Стадії Етапи
1.Формування вимог до АІС Обстеження об'єкту і обґрунтовування необхідності побудови системи
Формування вимог користувача до системи
Оформлення звіту і заявки на розробку АІС (технічне завдання)
2. Розробка концепції АІС
Вивчення об'єкту
Проведення необхідних дослідницьких робіт
Розробка варіантів концепції АІС і вибір одного з них
Оформлення звіту про виконану роботу
* 3. Розробка технічного завдання Розробка технічного завдання
Затвердження технічного завдання
4. Ескізне проектування Розробка попередніх проектних рішень щодо системи і її окремих частин
* 5. Технічне проектування Розробка проектних рішень щодо системи і її частин.
Розробка документації АІС і її частин.
Розробка і оформлення документації на поставку або розробку виробів для комплектування системи.
Розробка завдань на проектування в суміжних частинах проекту автоматизації.
* 6. Робоче проектування Розробка робочої документації на систему і на її частині.
Створення або пристосовування програм.
7. Введення системи в дію Підготовка об'єкту автоматизації до упровадження АІС.
Підготовка персоналу.
Комплектування АІС (програмно-технічними і інформаційними засобами).
Будівельно-монтажні роботи.
Пусконалагоджувальні роботи.
Попередні випробування.
Досвідчена експлуатація.
Приймальні випробування.
8. Стадія супроводу Виконання робіт згідно гарантійним зобов'язанням.
Післягарантійне обслуговування
Стадія 3 " Розробка технічного завдання" (ТЗ) обов'язкова. ТЗ звичайно розробляє замовник за планом: загальні відомості, призначення і ціль робіт, характеристика наочної області (відомості про процеси, які необхідно автоматизувати), основні вимоги, (це найважливіший розділ), об'єми і терміни виконання робіт, параметри системи. Об'їм ТЗ є розрізнений, наприклад, в одному випадку закінчене ТЗ на систему "Клієнт-банк займає 5 сторінок, в іншому - зверх 40. [2, стр.43].
На стадії 5 "Технічне проектування" створюється документ "Технічний проект" (ТП), сама трудомістка частина якого - описи постановок функціональних задач. Крім того, технічний проект ТП містить і опис забезпечуючої частини (проектні рішення за інформаційним, програмним, технічному і іншим видам забезпечення).
На стадії 6 "Робоче проектування" самим трудомістким процесом є створення програм і їх відладка. При об'єднанні стадій технічного і робочого проектування об'єм документації скорочується приблизно на 20%..
Особливістю американського підходу до розробки ІС є концепція безперервності вдосконалення ІС, що забезпечує виживання організації в ринкових умовах. У нас цей життєво важливий підхід сформульований як варіант технології проектування у випадку, якщо на об'єкті вже існує АІС.
Якщо АІС на об'єкті вже існує, то процес розробки нових задач (або перепроектували існуючих) охоплює 8 етапів:
1. Формулювання вимог (аналог ТЗ);
2. Постановка задачі (частина ТП);
3. Побудова алгоритму рішення задачі (частина ТП);
4. Розробка контрольного прикладу (частина ТП);
5. Розробка машинної блок-схеми і програм (частина РП);
6. Відладка нових програм на контрольному прикладі (частина РП);
7. Відладка нових програм на реальних даних (пробна експлуатація);
8. Приймання в промислову експлуатацію.
Етапи 6 і 7 можуть об'єднуватися, якщо реальні дані повноцінні, тобто дозволяють перевірити програму на всіх практично можливих ситуаціях.
Взагалі, стадії впровадження Інформаційних систем менеджменту можна означити у вигляді наступної таблиці 1.2.
Таблиця 1.2.
Стадії впровадження Інформаційних систем менеджменту
Постановка завдання й оцінка готовності підприємства до впровадження ERP-системи Суть процесу. Оцінка апаратного забезпечення, укомплектованості персоналу та інших чинників, які можуть вплинути на успішність і терміни впровадження
Навчання працівників компанії Суть процесу. Під час навчання працівникам компанії розповідають про стандартні можливості системи й розписують рекомендації для автоматизації бізнес-процесів. Після завершення тренінгів проводиться тестування персоналу
Моделювання Суть процесу. Обговорення бізнес-процесів, які планується автоматизувати в новому програмному продукті. За підсумками інтерв’ю здійснюється моделювання конфігурації системи й визначається перелік необхідних модифікацій
Конфігурування (налаштування системи) Суть процесу. Внесення до системи управління модифікацій, розроблених на попередньому етапі, перенесення довідкової інформації в систему, тестування налаштованої моделі в робочому середовищі, навчання ключових користувачів, а також внесення користувальних налаштувань
Тестування системи кінцевими користувачами Суть процесу. Навчання кінцевих користувачів, підготовка користувальної документації і повна перевірка працездатності системи
Введення системи в експлуатацію Суть процесу. Під дослідною експлуатацією розуміють паралельне використання нової та старої системи управління
Вдосконалення Суть процесу. Після введення системи в промислову експлуатацію й стабілізації роботи підрозділів систему вдосконалюють і визначають необхідні доробки
В даний час найсучаснішій і ефективній є CASE-технологія розробки ІС (ретельно розглянемо у наступному розділі), яку активно застосовують крупні промислові підприємства, створюючи автоматизовані робочі місця (АРМ) фахівців і бухгалтерів. [3, гл. 2].
2. Технологія проектування систем за CASE-методом
Оскільки у вітчизняній літературі питання створення бази моделей ІС за CASE-методом практично не висвітлене, доцільно дати опис концепції бази моделей на простому прикладі.
Нехай на підприємстві діють дві прикладні задачі:
Задача А — обчислення повного обсягу збуту продукції за п періодів часу (наприклад, місяць);
Задача В — обчислення середнього обсягу збуту продукції за п періодів часу.
Математичні моделі цих задач і інші характеристики наведені на рис. 2.1. В інформаційних системах першого покоління длярозв'язування цих задач необхідно створити дві незалежні системи зі своїми файлами даних і своїми обчислювальними функціями:
для задачі А — файл даних М1 і обчислювальна функція ПОВН, що охоплює операції підсумовування і присвоєння;
для задачі В — файл даних М1 і величина п; обчислювальні функції: ПОВН, ДІЛ (ділення), ПРИС (присвоєння).
В інформаційних системах другого покоління дані про обсяг збуту розглядались як загальний компонент і були створені два незалежні алгоритми для обробки колективно використовуваних даних.
В третьому поколінні було усвідомлено, що обчислення повного обсягу також необхідне для середнього обсягу збуту, тому один і той самий алгоритм ПОВН застосовувався в обох системах.
На цьому простому прикладі відразу помітна задача розпізнавання одиниць обчислювальних функцій, оскільки у другій прикладній задачі можна не побачити, що обчислення повного обсягу — незалежна частина алгоритму і що можна використати уже створений алгоритм.
CASE-засоби дозволяють створювати ІС і СППР за модульним принципом, причому модулі, що створюються робляться взаємозв’язуємими.
Отже, одна з важливих проблем створення такій єдиної бази моделей полягає в опису обчислень об'єктивно і незалежно від застосування, що має на меті охоплення якомога ширшого діапазону прикладних задач.
Приклад створення бази моделей БМ наведено на рис.2.1.
Заснована на знаннях (інтелектуальна) CASE-технологія передбачає впровадження в інформаційні системи та відповідні прикладні програми елементів штучного інтелекту, зокрема баз знань і правил виводу для оброблення якісної інформації, методології IDEF і природної мови для створення інтерфейсу користувача. Інформаційні системи, котрі містять у собі елементи штучного інтелекту, називаються інтелектуальними інформаційними системами.
До інформаційних систем, котрі повністю базуються на знаннях і правилах маніпулювання з ними, належать експертні системи. Створені також окремі продукти на базі комерційних технологій штучного інтелекту. Зокрема, продукт INTELLECT фірми АІ Corp., створений за CASE-технологією дає змогу збирати, показувати і аналізувати дані завдяки запитанням англійською мовою. Таких продуктів щодня стає все більше.
а)
Індекс задачі Назва задачі Математична модель Дані Обчислювальні функції
А Обчислення повного обсягу збуту V продукції за n періодів
,
де xi – обсяг збуту за період i
– ПОВН
В Обчислення середнього обсягу S збуту продукції за n періодів часу
або
ПОВН
– ДІЛ
– ПРИС
б)

Перше покоління ІС
Друге покоління ІС Третє покоління ІС
Рис. 2.1. Приклад створення бази моделей (БМ):
а — обґрунтування концепції БМ,
б — схема розв'язування задач в інформаційних системах
Останніми роками у CASE-засоби додаються нові принципи інформаційної технології, зокрема OLAP, сховища даних, програмні агенти, котрі застосовуються як самостійно, так і в компонентах інформаційних систем. Безумовно, використання їх в інформаційних системах має комплексний характер, проте вони можуть розглядатися як окремі типи програмних засобів, право на розробку яких виборюють десятки найбільших фірм світу.
На даний час розроблено досить багато аналітичних систем, сконструйованих з використанням OLAP- кубів (Hyperion OLAP, Elite OLAP, Oracle Express та багато інших). Ринок програмних OLAP- продуктів постійно розширюється. Сучасні системи оперативної аналітичної обробки дають користувачам змогу вирішувати ключові задачі управління бізнес-процесом, зокрема прикладні програми Hyperion OLAP дозволяють виконувати аналіз прибутковості; аналіз напрямків розвитку продукції; аналіз продажу; аналіз становища на ринку; аналіз асортименту продуктів; аналіз ризику; аналіз конкурентоспроможності; складання звітів з продуктивності; моделювання сценарію; аналіз бюджету і прогнозів тощо. Зауважимо, що згідно із сучасними поглядами на створення інформаційних систем OLAP- системи мають базуватися на спеціальній базі даних — сховищі даних.
Сховище даних (Data WarenHouse) як особлива форма організації бази даних, котра призначена для зберігання в погодженому вигляді історичної інформації, що надходить з різних оперативних систем та зовнішніх джерел, в останній час набуває широкого розповсюдження в інформаційних системах, зокрема в системах підтримки прийняття рішень. І хоча з формального погляду сховище даних являє собою різновид звичайної БД, проектують їх по-різному.
Для звичайних БД процес створення відбувається за схемою: вивчення предметної області; побудова інформаційної моделі; розробка на основі інформаційної моделі проекту бази даних; створення бази даних. Обов'язкові етапи створення сховищ даних інші, а саме:
· визначення інформаційних потреб користувачів стосовно даних, котрі нагромаджуються в базах даних операційних систем —систем обробки трансакцій OLTP-систем, що є джерелами оперативних даних;
· вивчення локальних баз даних OLTP-систем;
· виокремлення для кожної бази даних підмножини даних, необхідних для завантаження у сховище даних;
· інтегрування локальних підмножин даних і розробка загальної погодженої схеми сховища.
Для виконання створення сховищ даних за CASE-технологією існують різні інструментальні засоби, зокрема програмний продукт Oracle Designer та його спрощена версія Oracle Data Mart Designer, де вираз Data Mart означає вітрину даних як спеціалізоване сховище, що обслуговує один з напрямків діяльності компаній, наприклад облік запасів чи маркетинг. У вітрини даних інформація надходить або зі сховища (залежні вітрини), або безпосередньо з джерел даних, проходячи попередні узгодження та перетворення (незалежні вітрини).
Схему формування та використання сховища даних в СППР зображено на рис. 2.2. Дані беруться з різноманітних джерел оперативних даних. Після їх переміщення відбираються дані для гарантування того, що вони мають сенс, є неперервними і точними. Потім дані завантажуються в реляційні таблиці, здатні підтримувати різноманітні види аналізу та запитів, і оптимізуються для тих таблиць, котрі, як очікується, найчастіше використовуватимуться. І нарешті дані зберігаються для подальшого використання в СППР.

Рис. 2.2. Схема формування і використання сховища даних у СППР
Коли сховища даних уже створені та оптимізовані, необхідно ефективно завантажувати нові дані в систему, завантажувати їх без переривання процесу підтримки прийняття рішень. Проте зі збільшенням кількості даних розробники змушені визначати нові синтаксичні формати та формат запитів, які є більш швидкими та легкими, а також вишукувати нові підходи до поєднання реляційних таблиць і добування даних із цих дуже великих баз даних з використанням різновиду програмних агентів — інтелектуальних («розумних») агентів (Intelligent agents).
СППР належать до інформаційних систем нового покоління, основне призначення яких полягає в забезпеченні комп'ютерною підтримкою прийняття рішень зі слабоструктурованих та неструктурованих проблем організаційного управління на різних фазах створення рішень і моніторингу . Незважаючи на те, що на даний час у світі розроблено сотні типів СППР (сам термін DSS уперше був запроваджений 1971 року Горрі і Мортоном), такі системи в Україні практично не використовуються. Більш того, існує плутанина із самим терміном СППР.Не маючи змоги докладно спинитися на цій проблемі (СППР докладніше розглядаються в окремому розділі цього посібника), лише зауважимо, що у класичному розумінні СППР є інформаційна система, котра має компоненти (рис. 2.3): інтерфейс користувача,систему управління базами даних (СУБД), систему управління базами моделей (СУБМ), систему управління повідомленнями (СУП), причому підсистема СУП з'явилася лише останніми роками. Ця структура може бути основою для виокремлення дійсних СППР.

Рис. 2.3. Компоненти системи підтримки прийняття рішень
СППР широко застосовуються у США (ринок створюваного програмного забезпечення СППР тут щорічно досягає мільярда доларів) та в інших розвинутих країнах у різних сферах людської діяльності (економіка, бізнес, юриспруденція, державне управління тощо). Наприклад, для управління фінансами корпорацій (а також в управлінні виробництвом, у статистиці) ефективно використовується СППР Visual IFPS/Plus, котра була створена ще на початку 70-х років минулого століття і модифікувалася згодом під клієнт-серверну платформу (компанія COMSHARE продає Visual IFPS/Plus під Windows NT за 15000 дол. США). На ринку України пропонується російськомовна СППР для маркетингових досліджень Marketing Expert. Перспективними напрямками розвитку СППР є групові системи підтримки прийняття рішень (ГСППР), котрі призначені для комп'ютерної підтримки прийняття рішень групами індивідів, а також виконавчі інформаційні системи (ВІС).
Архітектура СППР представляється різними авторами по-різному. Приведемо приклад. Marakas (1999) запропонував узагальнену архітектуру, що складається з 5 різних частин:
(a) система керування даними (the data management system - DBMS),
(b) система керування моделями (the model management system - MBMS),
(c) машина знань (the knowledge engine (KE)),
(d) інтерфейс користувача (the user interface) і
(e) користувачі (the user(s)).

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию