Що означає об’єктно-орієнтований метод розробки моделі інформаційної системи та які методології при цьому використовуються?
1. Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення. Життєвий цикл ПЗ - це безперервний процес, який починається з моменту ухвалення рішення про необхідність його створення і закінчується у момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:
− основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
− допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
− організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язку процесів, дій і завдань, що виконуються впродовж ЖЦ.
Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.
Найбільшого поширення набули наступні дві основні моделі ЖЦ:
− каскадна модель;
− спіральна модель.
Для розробки однорідних (простих) ІС застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному. Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони застосування каскадного підходу:
− на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;
− виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна достатньо точно і повно формулювати всі вимоги, з тим щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання. Проте, в процесі використання цього підходу виявився ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку жорстку схему. В процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше ухвалених рішень.
Методологія описує процес створення й супроводження інформаційних систем у вигляді життєвого циклу ІС, представляючи його як послідовності стадій і виконуваних на них процесів.
Кожна стадія розбивається на етапи. Для кожного етапу визначаються послідовність виконуваних робіт, одержувані результати, методи й засоби, необхідні для виконання робіт, ролі й відповідальність учасників і т.д. Такий формальний опис життєвого циклу ІС дозволяє змістувати й організувати процес колективної розробки й забезпечити керування цим процесом.
Життєвий цикл (ЖЦ) ІС включає стадії:
✔ аналізу,
✔ проектування,
✔ розробки,
✔ тестування
✔ інтеграції,
✔ впровадження,
✔ супроводження
✔ розвитку ІС,
А також процеси, виконувані протягом усього ЖЦ - процеси керування й інтегральні процеси.
Ці процеси в тім або іншому ступені присутні на кожному з етапів. Процеси керування проектом: Змістування, організація, контроль.
Інтегральні процеси: керування конфігурацією, документування, перевірки, інтеграція.
Стадії і етапи життєвого циклу ІС
1. Аналіз.
1.1. Обстеження й створення моделей функціонування організації.
1.2. Аналіз моделей існуючих інформаційних мереж.
1.3. Формування вимог до інформаційної мережі організації.
1.4. Розробка Змісту створення інформаційної мережі організації.
2. Проектування.
2.1. Концептуальне проектування інформаційної мережі організації.
2.2. Розробка архітектури інформаційної мережі організації.
2.3. Проектування спільної моделі даних.
2.4. Формування вимог до додатків.
3. Розробка.
3.1. Розробка, прототипування й тестування додатків.
3.2. Розробка інтегральних тестів.
3.3. Розробка документації для користувача.
4. Інтеграція й тестування.
4.1. Інтеграція й тестування додатків у складі системи.
4.2. Оптимізація додатків і баз даних.
4.3. Підготовка експлуатаційної документації.
4.4. Тестування системи.
5. Впровадження.
5.1. Навчання користувачів.
5.2. Розгортання системи на місці експлуатації.
5.3. Інсталяція баз даних.
5.4. Експлуатація.
5.5. Здійснення приймально-здавальних випробувань.
6. Супроводження.
6.1. Реєстрація, діагностика й локалізація помилок.
6.2. Внесення змін і тестування.
6.3. Керування режимами роботи ІС.
2. Інжиніринг - це процес застосування взаємозалежного набору формальних технологій (моделей) для аналізу, проектування, створення й експлуатації інформаційних систем. Пропоновані в інжинірингу методи дозволяють описувати, аналізувати й проектувати структуру й діяльність організацій подібно технічним системам.
Реінжиніринг - це процес застосування формальних технологій, що дозволяють відновлювати модель розглянутої існуючої системи по її інформаційних компонентах.
У цей час триває активний процес розвитку й удосконалювання методологій створення інформаційних систем. У цій галузі працюють багато провідних спеціалістів в усім світі.
3. Життєвий цикл ПЗ - це безперервний процес, який починається з моменту ухвалення рішення про необхідність його створення і закінчується у момент його повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за стандартом ISO/IEC 12207 базується на трьох групах процесів:
− основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);
− допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
− організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка і поліпшення самого ЖЦ, навчання).
4. Інформаційні системи підприємств (ІСП) створюються для вдосконалювання керування й забезпечують нерозривний зв'язок між інформацією й керуванням.
Створення ІСП складна проблема. Навіть для дрібних організацій вона припускає розробку ряду підсистем, які повинні відповідати принципам інтеграції й керованості. Істотний вплив на розроблювальну інформаційну модель робить стратегія (або система поглядів) щодо організації ІСП. На практиці застосовуються різні сполучення типових стратегій.
Підхід від організаційної структури
Підхід від організаційної структури може бути застосований в системі, що базується на існуючих межах організації і її структурі. До функціональних областей діяльності організації звичайно належать фінанси, виробництво продукції, персонал, участь у ринку й замовлення. Інформаційна система ґрунтується на цих традиційних границях.
Цей підхід не є радикально новим, і реалізація ІСП при цьому не вимагає перебудови існуючої системи керування. Як тільки керівники різних функціональних галузей зрозуміють переваги нової системи, діяльність організації в цілому ряді областей можна поліпшити.
Основний недолік такого підходу полягає в тім, що може бути упущена можливість удосконалювання організації й що застарілі системи й методи, що втрачають у будь-якій організації свою життєздатність через певний період часу, найімовірніше, опиняться перенесеними в нову систему. Цей підхід не враховує сутності інтегрованої природи більшості організацій і дозволяє отримати дуже мало інформації, що виходить за межі підсистем. Однак лише деякі організації можуть протиставити цьому підходові деякі альтернативи, і він може бути досить добре використаний у замкнутих підсистемах. Деяким компаніям у чинність природи їхнього бізнесу властивий більш радикальний підхід, але вони все-таки можуть вважати, що підхід, заснований на організаційній структурі, найбільш прийнятний у випадку, коли сфера їхньої діяльності досить консервативна, і що цей підхід дає час для того, щоб сприйняти нову технологію.
Підхід з відкладеною інтеграцією
Підхід з відкладеною інтеграцією, по суті, являє собою підхід типу "вільної конкуренції" відносно конструювання ІСП. Її підсистеми в цьому випадку розвиваються тільки тоді, коли в них відчувається необхідність, і не робиться ніяких спроб пристосуватися до яких-небудь визначених думок про те, як буде розроблятися ІСП організації. Для деяких організацій такий підхід ідеальний.
Наприклад, компанія з п'ятьома віддаленими фабриками, що роблять різну продукцію для відділень збуту, може знайти зручним дозволити фабрикам розробляти власні системи й самим вирішувати свої основні проблеми, передбачаючи наступну інтеграцію ІСП на основі гарної технології.
Цей підхід розумний, якщо не існує цілком ясного уявлення про те, як буде розвиватися ІСП в організації; він породжує менше проблем, ніж надмірно амбіційний зміст.
Труднощі застосування даного підходу полягають у тому, що незалежні підсистеми можуть розвиватися в великі системи й наступна інтеграція, якщо вона буде можлива, може виявитися складною й дорогою. Задача остаточного об'єднання системи може зштовхнутися з більше серйозними проблемами, чим просто затримка процесу інтеграції.
Зазначений підхід, можливо, був цілком виправданий у минулому; сьогодні ж існує технологія й методологія розробки незалежних систем із закладеними в них можливостями наступної інтеграції. Цей підхід стає усе менше прийнятним, тому що усе більше адміністраторів бажають мати доступ до інформації, що перебуває в різних підсистемах. Це викликає необхідність інтеграції. Багато фахівців з обробки даних переконалися на власному досвіді, що для наступної інтеграції доводилося перепроектувати й переробляти системи, щоб досягти їхньої сумісності.
Підхід, що базується на зборі даних
У рамках цього підходу на першому етапі проектування ІСП особливе значення надається збору всіх даних, які можуть бути використані в системі. Дані ретельно класифікуються. Цей процес надзвичайно важливий, оскільки детальна класифікація допомагає зрозуміти, як будуть використовуватися дані, і певним чином впливає на способи цього використання. З комерційної точки зору ідея збору даних у випадку, коли результат може виявитися корисним протягом деякого обмеженого відрізка часу в майбутньому, має мало сенсу. Однак у більшості комерційних систем дані збираються як побічний продукт їхнього функціонування.
Звичайно це повідомлення, що складаються з поточних вивірених даних, і на їхній основі може бути розроблена дуже гарна ІСП. Ретельно обрана детальна класифікація полегшує використання даних на наступних стадіях. Фактично в неї міститься великий обсяг семантики. При поганій класифікації велика кількість потенційної інформації втрачається.
Підхід, заснований на використанні баз даних
Цей підхід також передбачає здійснення збору, зберігання й підтримки великої кількості даних. Дані повинні бути деталізовані настільки, щоб містити все необхідне для операційного й адміністративного керування в діловій сфері. Відповідна база даних використовується всіма підсистемами й абонентами, які в міру необхідності здійснюють доступ до неї. Бази даних підтримуються досить розвинутим програмним забезпеченням системами керування базами даних, які у відповідності зі специфікаціями користувачів можуть забезпечити безпеку, таємність і точність даних. Таке програмне забезпечення є дуже великим і дорогим, і хоча воно доступно, його використання пов'язане з організацією досить складної служби. Необхідно, наприклад, щоб всі дані, збережені в базі даних, знаходилися на піклуванні її адміністратора.
Підхід, заснований на сучасній технології ведення баз даних, у майбутньому заслужить ще більше визнання за двома причинами: по-перше, навіть якщо зрештою й не вийде завершеної ІСП, то за рахунок незалежності даних спроститься розвиток системи; по-друге, при такому підході забезпечується можливість за допомогою язика запитів надати користувачам безпосередній доступ до інформації.
Підхід "зверху вниз"
Такий підхід передбачає визначення інформаційних потреб для всієї послідовності рівнів керування, починаючи від оцінки потреб керування й спільних цілей усього бізнесу. Якщо інформація, необхідна на вищому рівні, залишається відносно стійкою за ступенем детальності, змістом й частотою використання, то системи зможуть задовольняти цим вимогам. Корисність розглянутого підходу залежить від сутності організації.
На рівні державної статистики потрібно цілком інший погляд на організацію, відмінний від того, котрий є в адміністративного апарата організації. Наприклад, адміністрація комерційної компанії має справу із замовленнями, конкретними рахунками, запасами й т.п. А державній компанії або компанії-власникові може вимагатися інформація про прибуток на вкладений капітал і про прогноз вільних наявних коштів.
Розглянутий підхід може бути виправданим там, де існує різниця в типі інформації, необхідній на різних рівнях. Однак при цьому втрачаються дві основних переваги баз даних, утримуючих поопераційні дані, що випливають із того, що цінність інформації визначається операцією й що вірогідність даних може бути встановлена в контексті операції, що їх породжує.
Наприклад, якщо управлінський апарат вищого рівня отримає відомості про загальне число службовців із платіжної відомості, то дані, імовірно, будуть точні, а спосіб їхнього одержання дешевий. Якщо ж для цієї мети буде використовуватися окрема система, у якій загальне число службовців підраховується на основі персональних карток, то спосіб одержання даних може виявитися більше дорогим, а результат – більш важким у смислі встановлення вірогідності.
Загальносистемний підхід
Загальносистемний підхід ґрунтується на припущенні, що ще до реалізації системи ми деяким обґрунтованим способом можемо розпізнати взаємозв'язки між частинами її базової інформації. Процеси збору, зберігання й обробки даних проектуються й реалізуються в рамках всієї системи в цілому. Хоча цей підхід є ідеальним, його застосування в повному обсязі може виявитися досить важким через практичні, політичні й соціальні проблеми. При вже існуючій системі проектування ідеальної системи може стати просто академічною вправою, тому що її реалізація спричинить радикальні перетворення. Справді, сліпе, без визначеної технології, використання проектувальниками цього підходу може призвести до катастрофи ілюзій, що й трапляється в багатьох сьогоднішніх обчислювальних системах. Однак в організаціях, які ще не мають розроблених систем, що діють і вважаються задовільними, розглянутий підхід може бути успішно застосований.
Він є ідеалізованим і не може в повному обсязі застосовуватися в реальній організації. Як можна було побачити при розгляді шістьох підходів, стратегія вибору підходу повинна формуватися з урахуванням особливостей конкретної системи. Варто взяти до уваги такі фактори, як розмір організації, природа її ділових операцій і досвід. Істотно, що вибір стратегії повинен бути зроблений після ретельної оцінки ступеня ризику й переваг можливих підходів.
Підхід, керований подіями
Організацію можна охарактеризувати через ресурси, якими вона маніпулює. Очевидні ресурси - такі, як гроші, люди, запаси й засоби виробництва, - легко ідентифікувати. Менш очевидні ресурси, що характеризують специфіку конкретної організації. Для авіаліній це число вільних місць, лікарень і готелів – відповідно ліжка й номери. У системі освіти важливе поняття ресурсу формується шляхом розподілу людей на персонал і студентів; можливо подальший розподіл персоналу на викладацький і допоміжний. В обробній промисловості може бути корисним розподіл запасів таким чином, щоб виділити ті з них, які необхідні в процесі обробки, і ті, які в сутності є сировиною для виробництва. ІСП, заснована на характеристиках ресурсів організації, дає переваги не тільки в обслуговуванні й відображенні істотних функцій керування, але й у смислі готовності конкретних елементів даних до використання. Застосовуючи цей підхід, можна отримати всю основну необхідну нам інформацію з документів організації, які відображають події, що відбуваються. Документи (замовлення, рахунки-фактури, заявки на роботу, бланки податкової декларації, квитанції, чеки й т.д.) дадуть всю істотну інформацію: дані, джерело яких відоме, перевіряються на вірогідність у ході операційних процедур і датуються.
У більшості випадків немає необхідності формувати штучні конструкції даних. Усе, що потрібно, уже міститься в даних, одержуваних з ділової сфери. Вони утворюються із джерела, органічного для бізнесу, тобто з документів або аналізу подій. Наступний крок - відображення ресурсів з метою показати їхній життєвий цикл і відбити статичну й динамічну фази. Облік всіх видів взаємин і документування вимагають великої майстерності, оскільки достаток деталей утрудняє розуміння; необхідна для їхнього обліку робота важка, а занадто дрібні деталі марні. Найкращий підхід перебуває в побудові такого відображення, що ідентифікує головні файли й зв'язує їх так, щоб ідентифікувати основні потоки даних у системі. Результуюча схема повинна наочно відображати ділову сферу організації. В останні роки цей підхід одержав назву процесорного підходу.
Даний підхід орієнтований на збалансовану організацію, що складається з декількох однакових за розміром підсистем. Однак багато галузей більше відповідають картині, де одна підсистема домінує над іншими. Прикладами можуть служити виписування рахунків за газ і електрику, облік студентів, що навчаються в університеті, і т.п. У цьому випадку викладається методологія, що, відкриває перед організацією корисну перспективу. Система, реалізована для такої організації, імовірно, буде розподіленою. Це означає, що будуть створюватися окремі інформаційні системи, які на наступних стадіях будуть зв'язуватися для одержання інформації керування.
5. Структурним прийнято називати такий метод дослідження системи або процесу, що починається із загального огляду об'єкта дослідження, а потім передбачає його послідовну деталізацію.
Структурні методи мають три основні особливості:
• розчленовування складної системи на частини, що уявляють як «чорні ящики», а кожний чорний ящик реалізує певну функцію системи керування;
• ієрархічне впорядкування виділених елементів системи з визначенням взаємозв'язків між ними;
• використання графічного подання взаємозв'язків елементів системи.
Модель, побудована із застосуванням структурних методів, являє собою ієрархічний набір діаграм, що графічно зображують функції, виконувані системою, й взаємозв'язки між ними. Попросту кажучи, це малюнки, на яких показаний набір прямокутників, певним чином пов'язаних між собою. У діаграми також включається текстова інформація для забезпечення точного визначення змісту функцій і взаємозв'язків. Використання графічного подання процесів істотно підвищує наочність моделі й полегшує процес її сприйняття.
Від звичайних малюнків, за допомогою яких можна уявити процес керування, структурні діаграми відрізняються тим, що виконуються за цілком визначеними правилами, а процес їхнього складання й аналізу підтримується відповідним програмним забезпеченням.
У числі методологій структурного аналізу до найпоширеніших можна віднести наступні:
• SADT (Structured Analysis and Design Technique) – технологія структурного аналізу й проектування і її підмножина стандарт IDEF (IcamDefinition);
• DFD (Data Flow Diagrams) - діаграми потоків даних;
• ERD (Entity-Relationship Diagrams) - діаграми «сутність-зв'язок»;
• STD (State Transition Diagrams) - діаграми переходів станів.
6. Об’єктно-орієнтовані методи
Об’єктно-орієнтований підхід до побудови моделей системи керування відрізняється від структурного більшим рівнем абстракції й ґрунтується на уявленні системи у вигляді сукупності об'єктів, взаємодіючих між собою шляхом передачі певних повідомлень. Як об'єкти предметної області можуть служити конкретні предмети або абстраговані сутності - замовлення, клієнт і т.п.
У результаті застосування об’єктно-орієнтованого підходу модель системи так само, як і при використанні структурних методів, представляється сукупністю діаграм, які будуються за певними правилами. Одним із прикладів об’єктно-орієнтованих методологій може служити методологія UML (Unified Modeling Language). Відзначимо, що об’єктно-орієнтований підхід не протиставляється структурному, а може служити його доповненням. Наприклад, для формалізації моделі бізнесу може використовуватися методологія IDEF, а при побудові моделі системи керування - методологія UML.