Гужва В.М. Інформаційні системи і технології на підприємствах

Подождите немного. Документ загружается.

комірник.

Обов’язок являє собою деяку задачу, за допомогою якої спе-

цифікується роль (тобто функція, виконувана групою працівни-

ків), наприклад:

— «Доступність для рекомендації»;

— «Необхідність у консультації»;

— «Необхідність в інформуванні»;

— «Прийняття остаточного рішення»;

— «Виконання»;

— «Контроль виконання».

З роботою можуть бути пов’язані не більше шести ролей. Для

кожної ролі можна задати не більше шести обов’язків.

Ролі й обов’язки наслідуються на нижніх рівнях бізнес-

процесів. Якщо для деякого бізнес-процесу одна роль використо-

вується для всіх обов’язків у всіх роботах, то достатньо пов’язати

цю роль і відповідні обов’язки з даним процесом. Спадкування

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

нтів і бізнес-функцій.



Модель бізнес-організації

Модель бізнес-організації — це опис організаційної структу-

ри та структури персоналу організації. Структура персоналу мо-

же бути описана на абстрактному рівні за допомогою опису ро-

лей або на конкретному рівні — зіставленням працівників і

організаційних одиниць.

Модель бізнес-організації має такі цілі:

• одержати уявлення про поточну і, по можливості, майбутню

(цільову) організаційні структури і задокументувати їх;

• одержати уявлення про зміни в структурах підрозділів ком-

панії залежно від розташування їх у загальній системі й задоку-

ментувати їх;

• зробити можливим створення інтерфейсу користувача кор-

поративної системи в розрізі працівників або виконуваних функ-

цій, що полегшується накладанням організаційної моделі на мо-

дель бізнес-процесу.

Модель бізнес-організації має такі характеристики:

• організаційна модель складається з низки організаційних

компонентів. З цими організаційними компонентами можна спів-

віднести ім’я, тип і текст;

• між організаційними компонентами можуть бути встановле-

ні функціональні відношення. З такими функціональними відно-

шеннями можна співвіднести текст;

• організаційна модель може складатися з однієї або біль-

ше організаційних схем. Дані схеми можуть співвідноситися

одна з одною за допомогою визначення компонентів суб-

діаграм;

• користувачі й функції, які ними виконуються, можуть спів-

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

• організаційні моделі можуть визначатися за фазами оптимі-

зації так, щоб створити наочне уявлення про ефект проекту на-

кладання бізнес-процесів на організацію.

У загальному випадку модель підприємства включає такі

об’єкти:

а) основні дані;

б) референтні моделі;

в) проектні моделі.

Перш ніж скористатися деякою референтною моделлю та по-

будувати на її основі для конкретного підприємства проектну

модель, треба спочатку ввести деякі основні дані (рис. 2.13). По-

перше, повинна бути визначена версія, на основі якої створюва-

тиметься модель. По-друге, компоненти, що використовуються в

моделях, мають бути визначені як основні дані. Останні включа-

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

Ці основні дані розміщуються в так званому архіві, що містить

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

Потім створюються референтні моделі, що являють собою ви-

користання досвіду й типології організацій із найвищою ефектив-

ністю моделювання. Кожна референтна модель складається з мо-

делі бізнес-функцій, моделі організації і моделі бізнес-процесів.

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

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

бізнес-функції. Моделі бізнес-функцій і моделі бізнес-процесів

референтних моделей побудовані шля-

хом копіювання з архіву, в якому ці

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

рюються проектні моделі, що являють

собою структуру певної організації. Ці

моделі подібні до референтних моде-

лей, за винятком того, що вони є

прив’язаними до однієї конкретної ор-

ганізації. У проектних моделях також

Основні дані

Проектна

модель

Референтна

модель

Рис. 2.13. Зв’язок між

об’єктами моделювання

можна визначити варіанти бізнес-функцій, що подають різнома-

нітні засоби виконання бізнес-функцій. Для цих варіантів можуть

бути визначені зв’язки оптимізації, які наводять оптимальні шля-

хи, що ними потрібно йти, переходячи від одного засобу роботи

до більш оптимізованого засобу.

Підсумовуючи, можна зробити такі висновки:

1) референтні моделі складаються з ряду компонентів, доступ-

них в архіві (як визначено в бізнес-об’єкті Основні дані);

2) проектні моделі часто засновані на референтних моделях;

3) проектні моделі складаються з ряду компонентів, доступ-

них в архіві (або нещодавно включених, або отриманих за допо-

могою референтних моделей);

4) референтні моделі можуть бути засновані на проектних

моделях.

Мережі Петрі як засіб побудови

динамічних моделей підприємства

Метод моделювання «Мережі Петрі» був розроблений Ада-

мом Петрі у 60-х роках ХХ ст. З того часу він став одним із най-

більш визнаних стандартних методів моделювання процесів. У

динамічному моделюванні підприємства метод мереж Петрі слу-

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

опису використовуються чотири базових конструктивних елеме-

нти (табл. 2.3).

Таблиця 2.3

КОНСТРУКТИВНІ ЕЛЕМЕНТИ МЕРЕЖ ПЕТРІ

Конструктивний

елемент

Характеристика

Стани:

Стани несуть у собі символи роботи, що повинні

опрацюватися в діяльності, яка йде за символом ста-

ну. Приклад символу в стані — комерційне замов-

лення, що буде прийняте і підтверджене. Стан може

фіксувати певний тип символу роботи, описаний

при визначенні стану

Дії управління:

Дії управління відповідають за пересування символу

роботи в потоці процесу. Є три можливості:

• (X) OR-розвилка (напрям 1 або 2);

• AND-розвилка (паралельний);

• AND-поєднання (синхронізація)

Процеси:

Ручні або автоматизовані дії, що перетворюють сим-

вол роботи зі cтану входу в інший символ роботи в

стані виходу

Підпроцеси:

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

більш низькому рівні

Таблиця 2.4

КОНСТРУКТИВНІ БЛОКИ МЕРЕЖ ПЕТРІ

Конструктивний блок Характеристика

Діяльність A

Діяльність B

Діяльність C

Розподіл дій:

Діяльність розбита на дві

дії B і C, виконані у зазна-

ченому порядку

AND-поєднання

AND-

розвилка

Діяльність A

Діяльність B

Діяльність C

Дії, виконані паралельно:

Діяльність розбита на дві

дії B і C. Послідовність, у

кій виконуються B і C, не

має ніякого значення. Про-

те обидві повинні бути ви-

конані до закінчення про-

цесу

OR-розвилка

Діяльність A

Діяльність

Спеціалізовані дії:

Діяльність розбита на дві

альтернативні дії B або C.

На підставі визначеної ді-

яльності стану B або C ві-

дібрані (не обидві, тому

тільки або) OR-поєднан-

ням — єдиним місцем ви-

ходу наприкінці процесу

Закінчення табл. 2.4

Конструктивний блок Характеристика

OR-розвилка

Діяльність A

Діяльність В

Ітерація дій:

Виконання дії припускає

виконання діяльності B

один або більшу кількість

разів. Число ітерацій уре-

гульоване під час визна-

чення стану

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

декількох принципах:

• діяльність починається, коли є принаймні один символ ро-

боти у всіх поєднаних станах входу діяльності;

• діяльність споживає один символ роботи з кожного стану

входу і продукує один символ роботи для кожного поєднаного

стану виходу;

• дії управління мають спеціальні можливості (табл. 2.4):

 вони можуть множити один символ роботи зі стану входу і

поміщати їх у два або більшу кількість станів виходу. Для цього

будується конструкція AND-розвилка;

 вони можуть маршрутизувати символ роботи через процес,

розміщаючи цей символ в один із поєднаних станів виходу, за-

снованих на певних станах. Цей засіб реалізується через конструк-

ції OR-розвилки;

 вони можуть синхронізувати дії, виконані в рівнобіжних

кроках. Для цього використовується конструкція AND-поєд-

нання.

На основі досвіду моделювання процесів у потоках мереж Пет-

рі можна зробити кілька рекомендацій:

• кожен потік процесу починається і закінчується тільки од-

ним станом;

• вхід і вихід потоку повинні мати чітке й однозначне форму-

вання. Потрібно використовувати лише стандартні блоки. Це га-

рантує коректні мережі Петрі, що можуть бути реалізовані сис-

темою керування потоками;

• процес слід обмежувати п’ятьма-десятьма кроками. Якщо

потрібна більша кількість кроків — будується підпроцес;

• поєднання сторінок не використовується. Достатньо струк-

турувати процес ієрархічним методом.

Наведемо приклад бізнес-процесу «Циклічна інвентаризація

на складах», скориставшись розглянутими вище засобами та пра-

вилами побудови мереж Петрі (рис. 2.14).

Генерація замовлень на

циклічну інвентарізацію

Друк замовлень на

циклічну інвентаризацію

Введення даних по

циклічній інвентаризації

на складах

Опрацювання даних по

циклічній інвентаризації

Вилучення замовлень на

циклічну інвентаризацію

Друк перевірювального

звіту по циклічній

інвентаризації

Рис. 2.14. Приклад бізнес-процесу

«Циклічна інвентаризація на складах»

2.4. САSЕ-ТЕХНОЛОГІЇ — ІНСТРУМЕНТАРІЙ ПІДТРИМКИ

ЖИТТЄВОГО ЦИКЛУ ІНФОРМАЦІЙНИХ СИСТЕМ

Практично жоден серйозний проект зі створення АІСУП не

здійснюється без використання САSЕ-засобів. САSЕ (Computer-

Aided Software / System Engineering) являє собою сукупність ме-

тодологій аналізу, проектування, розробки і супроводження склад-

них програмних систем, підтриману комплексом взаємопов’я-

заних засобів автоматизації. САSЕ — це інструментарій для

системних аналітиків, розробників і програмістів, що замінює їм

папір і олівець комп’ютером для автоматизації процесу проекту-

вання і розробки програмного забезпечення.

Основна мета САSЕ полягає в тому, щоб відокремити почат-

кові етапи (аналіз і проектування) від подальших етапів розроб-

ки, а також не обтяжувати розробників усіма деталями середо-

вища розробки і функціонування системи. Чим більший обсяг

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

ще. Під час використання САSЕ трансформуються всі етапи

життєвого циклу АІСУП, при цьому найбільші зміни стосуються

етапів аналізу і проектування.

Крім автоматизації методологій і, як наслідок, можливості за-

стосування сучасних методів системної і програмної інженерії

САSЕ мають такі основні переваги:

1) поліпшують якість системи, що створюється, за допо-

могою засобів автоматичного контролю (передусім контролю

проекту);

2) дозволяють за короткий час створювати прототип майбут-

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

результат;

3) прискорюють процес проектування і розробки;

4) звільняють розробника від рутинної роботи, дозволяючи

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

5) підтримують розвиток і супровід розробки;

6) підтримують технології повторного використання компо-

нентів розробки.

Зараз існує два покоління САSЕ. Засоби першого покоління

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

ктури системи і є першою технологією, адресованою безпосеред-

ньо системним аналітикам і проектувальникам. Вони включають

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

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

чаткових кроках проекту — системному аналізі, визначенні ви-

мог, системному проектуванні, логічному проектуванні БД. Засо-

би другого покоління призначені для підтримки повного

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

засоби підтримки автоматичної кодогенерації, а також забезпечу-

ється повна функціональна підтримка для створення графічних

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

і зв’язування системної інформації, а також інформації щодо

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

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

нерації документів з проекту; контролю на відповідність стандар-

там по всіх етапах ЖЦ.

Нижче стисло характеризуються основні функціональні мож-

ливості САSЕ-засобів.

1) Спільна графічна мова. САSЕ забезпечує всіх учасників

проекту (в тому числі й замовників) спільною мовою, наочною,

строгою та інтуїтивно зрозумілою. Це дозволяє залучати замовни-

ка до процесу розробки, спілкуватися з експертами предметної об-

ласті, захищати проект перед керівництвом, поділити діяльність

системних аналітиків, проектувальників і програмістів, а також за-

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

стему:

Графічна орієнтація САSЕ полягає в тому, що програми є

двовимірними схемами, набагато простішими у використанні,

аніж описи на кілька сторінок.

2) Загальна БД проекту. Основа САSЕ — це використання

БД-проекту (репозитарію) для зберігання всієї інформації про

проект, яка може розподілятися між розробниками відповідно

до їхніх прав доступу. Зміст репозитарію включає не тільки

об’єкти різних типів, але і відносини між їх компонентами, а

також правила використання або опрацювання цих компонен-

тів. Репозитарій може зберігати понад 100 типів об’єктів, прик-

ладами яких є діаграми, визначення екранів і меню, проекти зві-

тів, описи даних, логіка опрацювання, моделі даних, моделі під-

приємства, моделі опрацювання, початкові коди, елементи

даних і т. ін.

3) Інтеграція засобів. На основі репозитарію здійснюються

інтеграція САSЕ-засобів і розподіл системної інформації між ро-

зробниками. При цьому можливості репозитарію забезпечують

кілька рівнів інтеграції: загальний інтерфейс користувача по всіх

засобах, передачу даних між засобами, інтеграцію етапів розроб-

ки через єдину систему подань фаз ЖЦ, передачу даних і засобів

між апаратними платформами.

4) Підтримка колективної розробки й управління проек-

том. САSЕ підтримує групову роботу над проектом за допомо-

гою засобів роботи в мережі, експорту-імпорту будь-яких фра-

гментів проекту для розвитку і/або модифікації, а також плану-

вання, контролю, управління, взаємодії, тобто функцій,

необхідних для розробки і супроводження проектів. Ці функції

також реалізуються на основі репозитарію. Зокрема, через ре-

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

доступу, привілеї доступу), контроль версій, контроль змін

тощо.

5) Прототипування. Важливу роль в автоматизації ранніх

етапів ЖЦ відіграють можливості підтримки прототипування.

САSЕ дозволяє будувати швидкі прототипи системи, що дає змо-

гу на ранніх етапах розробки оцінити, наскільки майбутня систе-

ма влаштовує замовника і наскільки «дружня» вона майбутньому

користувачеві.

6) Генерація документації. Вся документація з проекту ге-

нерується автоматично на базі репозитарію (як правило, на базі

вимог відповідних стандартів). Безперечна перевага САSЕ по-

лягає в тому, що документація завжди відповідає поточному

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

дбиваються в репозитарії. Відомо, що за традиційних під-

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

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

ження.

7) Верифікація проекту. САSЕ забезпечує автоматичну

верифікацію і контроль проекту на повноту і спроможність

на ранніх етапах розробки, що впливає на успіх розробки в

цілому.

8) Автоматична кодогенерація. Кодогенерація здійснюється

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

ко 80—90% об’єктних кодів або текстів програм мовами високо-

го рівня. При цьому різними САSЕ-пакетами підтримуються

практично всі відомі мови програмування, однак найчастіше як

цільові мови виступають СОВОL, C і АDА.

9) Супроводження і реінжиніринг. Супроводження системи

в межах САSЕ характеризується тим, що супроводжується про-

ект, а не програмні коди. Засоби реінжинірингу і реверсного ін-

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

інтегрувати отримання схеми в проект, автоматично оновлюва-

ти документацію під час заміни кодів, автоматично змінювати

специфікації при редагуванні кодів і т. ін.