Концепція idef0 Роботи (Activity)



Скачати 370.94 Kb.
Дата конвертації06.01.2018
Розмір370.94 Kb.
ТипКонцепція

Зміст

Вступ…………………………………………………………………………………………...………..2

1 Створення моделі процесів в Bpwin……………………………………………………………...3

1.1 Концепція IDEF0……………………………………………………………………………...4

1.1.1 Роботи (Activity) ………………………………………………………………………….5

1.1.2 Стрілки (Arrow) …………………………………………………………………………..7

1.1.3 Діаграми дерева вузлів………………………………………………………………….10

1.1.4 Вартісний аналіз (ABC) ………………………………………………………………...11

1.1.5 Рекомендації по малюванню діаграм…………………………………………………..13

1.2 DFD – діаграми потоків даних……………………………………………………………...13

1.2.1 Роботи…………………………………………………………………………………….15

1.2.2 Зовнішні сутності……………………..…………………………………………………15

1.2.3 Стрілки (потоки даних)………………………………………………………………….15

1.2.4 Сховища даних…………………………………………………………………………..16

1.2.5 Нумерація об'єктів………………………………………………………………………....17

1.3 Метод опису процесів IDEF3……………………………………………………………..17

1.3.1 Одиниці роботи - Unit of Work (UOW)………………………………………………...18

1.3.2 Зв'язки…………………………………………………………………………………….18

1.3.3 Об'єкт посилання………………………………………………………………………...20

2 Створення моделі даних за допомогою Erwin…………………………………………….22

2.1 Палітра інструментів в Erwin……………………………………………………………..22

2.2 Створення логічної моделі даних………………………………………………………...23

2.2.1 Рівні логічної моделі…………………………………………………………………….23

2.2.2 Сутності та атрибути……………………….…………………………………………....24

2.2.3 Зв'язки…………………………………………………………………………………….26

2.2.4 Ієрархія спадкоємства (або ієрархія категорій)………………………………………..28

3 Завдання до лабораторних робіт……………………………………………………………30

Додатки…………………………………………………………………………………………36

Література……………………………………………………………………………………...43

Вступ

Створення складних інформаційних систем є складним завданням, рішення якого вимагає застосування спеціальних методик та інструментів. Недивно, що останнім часом серед системних аналітиків і розробників значно виріс інтерес до CASE- технологіям (Computer-Aided Software/System Engineering) та інструментальних CASE-засобів, що дозволяють максимально систематизувати і автоматизувати всі етапи розробки програмного забезпечення.

Пропонований методичний посібник є практичним керівництвом по створенню інформаційних систем за допомогою ефективних інструментів аналізу і проектування фірми PLATINUM technology - BPWin і ERWin.

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

Перший розділ присвячений викладу основ методології функціонального моделювання і побудові моделей IDEF0, DFD, IDEF3 за допомогою PLATINUM BPwin.

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

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

1 Створення моделі процесів в BPwin

BPwin є хорошим інструментом для створення моделей, що дозволяють аналізувати, документувати і планувати зміни складних бізнес-процесів. BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства і графічного зображення цієї інформації у вигляді цілісної і несуперечливої моделі. Причому, оскільки модель є деяким графічним представленням дійсності, можна стверджувати, що людина повернулася до свого улюбленого засобу документування бізнес-процесів - до малюнка. Але повернення це відбулося на новому рівні - цілісність і несуперечність моделі-малюнка (якості, про які раніше не було й мови) гарантуються поряд методологій і нотацій, яким слідують творці моделі. BPwin підтримує три таких методології: IDEFO, DFD і IDEF3, що дозволяють аналізувати ваш бізнес з трьох ключових точок зору:

З погляду функціональності системи. В рамках методології IDEFO (Integration Definition for Function Modeling) бізнес-процес представляється у вигляді набору елементів-робіт, які взаємодіють між собою, а також показується інформаційні, людські та виробничі ресурси, споживані кожною роботою.

З погляду потоків інформації (документообігу) в системі. Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що вже відображене в моделі IDEF3, оскільки вони описують потоки даних, дозволяючи прослідкувати, яким чином відбувається обмін інформацією між бізнес-функціями усередині системи. У той же час діаграми DFD залишають без уваги взаємодія між бізнес-функціями.

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

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

Р
ис.1 Діалог створення моделі

1.1 Концепція IDEF0

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

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

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



Мета моделювання (Purpose). Модель не може бути побудована без чітко сформульованої мети. Мета повинна відповідати на наступні питання:

Чому цей процес повинен бути замоделірован?

Що повинна показати модель?

Прикладів формулювання мети може служити наступні твердження: "Описати функціонування фінансових потоків підприємства з метою знаходження місць по нераціональному їх використанню".



Точка зору (Viewpoint). Точку зору можна показати як погляд людини, яка бачить систему в потрібному для моделювання аспекті. Точка зору повинна відповідати меті моделювання. Наприклад, “Головний бухгалтер”.

Для внесення мети і точки зору в моделі IDEF0 в Bpwin слід вибрати пункт меню Model/Model Properties, що викликає діалог Model Properties. У закладці Purpose слід внести мету і точку зору, а в закладку Definition - визначення моделі (наприклад, “Бізнес-процеси оборотів МТЦ на складі підприємства при виконанні повсякденної діяльності”) і опис області (наприклад, “Складський облік”). У закладці Status того ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний і т.д.). У закладці Source описуються джерела інформації для побудови моделі (Наприклад, “Опит експертів в наочній області і аналіз документації”). Закладка General служить для внесення імені проекту і моделі, імені та ініціалів автора і тимчасових рамок моделі - AS-IS (як є) і TO-BE (як повинно бути).

Результат опису моделі можна отримати в звіті Model Report. Діалог настройки звіту викликається з пункту меню Tools/Report/Model Report. У діалозі настройки слід вибрати необхідні поля, при цьому автоматично відображається черговість виведення інформації в звіт.

1.1.1 Роботи (Activity)

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

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

При створенні нової моделі автоматично створюється контекстна діаграма з єдиною роботою, що зображає систему в цілому (рис.2). Для внесення імені роботи слід клацнути по роботі правою кнопкою миші, вибрати в меню Name і в діалоговому вікні, що з'явилося, внести ім'я роботи. Для опису інших властивостей роботи служить діалог Activity Properties. Вміст словника робіт можна роздрукувати у вигляді звіту (меню Tools/Report/Diagram Object Report).




Рис.2 Приклад контекстної діаграми

Діаграми декомпозиції містять дочірні роботи. Для створення діаграми декомпозиції слід клацнути по кнопці:

В
иникає діалог Activity Box Count, в якому слід вказати нотацію нової діаграми і кількість робіт на ній. Для забезпечення наочності і кращого розуміння модельованих процесів рекомендується використовувати від трьох до шести блоків на одній діаграмі. Якщо виявилось, що кількості робіт недостатньо, то роботу можна додати в діаграму, клацнувши спочатку по кнопці:

н
а палітрі інструментів, а потім у вільне місце на діаграмі.

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

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

Р
ис.3 Ієрархія діаграм


1.1.2 Стрілки (Arrow)

Взаємодія робіт між собою і зовнішнім світом описується у вигляді стрілок. Стрілки є якоюсь інформацією та іменуються іменниками (наприклад, сировина). У IDEF0 розрізняють п'ять типів стрілок (малюнок 4):

Вхід (Input) - матеріал або інформація, які використовуються або перетворяться роботою для отримання результату (виходу). Допускається, що робота може не мати жодної стрілки входу. Стрілка входу малюється як вхідна в ліву грань роботи.

Управління (Control) - правила, стратегії, процедури або стандарти, якими керується робота. Кожна робота повинна мати хоч би одну стрілку управління. Стрілка управління малюється якщо входить у верхню грань роботи.

Вихід (Output) - матеріал або інформація, які проводяться роботою. Кожна робота повинна мати хоч би одну стрілку виходу. Робота без результату не має сенсу і не повинна моделюватися. Стрілка виходу малюється як вихідна з правої грані роботи.

Механізм (Mechanism) - ресурси, які виконують роботу. Стрілка механізму малюється як вхідна в нижню грань роботи.

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

Р
ис. 4 Функціональний блок і інтерфейсні дуги

Взаємодія між блоками зображається дугами. Існує п'ять видів взаємозв'язків між блоками:

Вихід - Вхід (output - input). Вихід одного блоку є входом іншого. Зв'язок по вхідному зворотному зв'язку має місце тоді, коли вихід одного блоку стає входом іншого блоку з великим домінуванням.

· Вихід - Управління (output - control). Вихід одного блоку є дією, що управляє, іншого.

· Вихід - Механізм (output - mechanism). Вихід одного блоку є засобом іншого.

· Вихід - Механізм - Зворотний зв'язок (output - mechanism- feedback).

· Вихід - Управління - Зворотний зв'язок (output - control - feedback). Зворотний зв'язок по управлінню виникає тоді, коли вихід деякого блоку впливає на блок з великим домінуванням. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т.д. (рис.5).

Р
ис.5 Приклад зворотного зв'язку

Стрілки в IDEF0, як правило, зображають набори предметів, тому вони можуть розгалужуватися і з'єднуватися разом різним чином. Розгалуження стрілки означають, що частина її вмісту (або весь набір предметів) може з'явитися в кожному відгалуженні стрілки. Стрілка завжди позначається до розгалуження, щоб дати назву всьому набору. Крім того, кожне відгалуження стрілки може бути помічене відповідно до наступних правил: вважається, що непомічена гілка містить всі предмети, вказані в мітці перед розгалуженням; кожна мітка гілки уточнює, що саме містить ця гілка. Злиття стрілок указує, що вміст кожної гілки бере участь у формуванні після злиття об'єднаної стрілки. Після злиття стрілка завжди позначається для вказівки нового набору, крім того, кожна гілка перед злиттям може позначатися відповідно до наступних правил: вважається, що непомічені гілки містять всі предмети, вказані в загальній мітці після злиття; кожна мітка уточнює, що саме містить ця гілка.

Для внесення на діаграму стрілки необхідно:

К
лацнути по кнопці з символом стрілки в палітрі інструментів:


перенести курсор до лівої сторони екрану, поки не з'явитися початкова штрихова смужка;

клацнути один раз по смужці (звідки виходить стрілка) і ще раз в лівій частині роботи з боку входу (де закінчується стрілка);

· повернутися в палітру інструментів і вибрати опцію редагування стрілки:

·
клацнути правою кнопкою миші на лінії стрілки, в спливаючому меню вибрати Name Editor і додати ім'я стрілки в закладці Name, у вкладці Definition занести визначення стрілки і додатковий опис. Також можна змінити стиль, розмір шрифту і колір стрілки.

Вміст словника стрілок можна роздрукувати у вигляді звіту (меню Tools/Report/Arrow Report.) і отримати тим самим тлумачний словник термінів наочної області, що використовуються в моделі.
1.1.3 Діаграми дерева вузлів
Діаграма дерева вузлів показує ієрархію робіт в моделі і дозволяє розглянути всю модель цілком, але не показує взаємозв'язку між роботами (стрілки). Для створення діаграми дерева вузлів слід вибрати в меню пункт Diagram/Node Tree. У діалозі Node Tree слід вказати глибину дерева - Number of Levels (за умовчанням 3) і корінь дерева (за умовчанням - батьківська робота поточної діаграми). За умовчанням нижній рівень декомпозиції показується у вигляді списку, решта робіт - у вигляді прямокутників. Для відображення всього дерева у вигляді прямокутників слід вимкнути опцію Bullet Last Level. При створенні дерева вузлів необхідно вказати ім'я діаграми.
1.1.4 Вартісною аналіз (ABC)
Вбудований в BPwin механізм обчислення вартості дозволяє оцінювати і аналізувати витрати на здійснення різних видів ділової активності. Механізм обчислення витрат на основі виконуваних дій (Activity-Based Costing, ABC) - це технологія, вживана для оцінки витрат і використовуваних ресурсів. Вона допомагає розпізнати і виділити найбільш дорогі операції для подальшого аналізу. ABC є широко поширеною методикою, використовуваною міжнародними корпораціями і державними організаціями (зокрема Департаментом оборони США) для ідентифікації дійсних рушіїв витрат в організації. Вартісною аналіз є угода про облік, використовувана для збору витрат, пов'язаних з роботами, з метою визначити загальну вартість процесу. Вартісною аналіз заснований на моделі робіт, оскільки кількісна оцінка неможлива без детального розуміння у функціональності підприємства. Зазвичай ABC застосовується для того, щоб зрозуміти походження вихідних витрат і полегшити вибір потрібної моделі робіт при реорганізації діяльності підприємства.

Р
ис.6 Діалог Cost Center Editor

При проведенні вартісного аналізу спочатку задаються одиниці вимірювання часу і грошей. Для завдання одиниць вимірювання слід викликати діалог Model Properties (меню Model/Model Properties), закладка ABC Units. Якщо в списку вибору відсутня необхідна валюта, її можна додати. Діапазон вимірювання часу в списку Time Unit достатній для більшості випадків - від секунд до років. Потім описується центр витрат (cost centers). Для внесення центрів витрат необхідно викликати діалог Cost Center Editor (меню Model/Cost Center Editor). Кожному центру витрат слід дати докладний опис у вікні Definition (рис.6).

Для завдання вартості робіт (для кожної роботи на діаграмі дерева композиції) слід клацнути правою кнопкою миші по роботі і на спливаючому меню вибрати Cost. У діалозі Cost указується частота проведення даної роботи в рамках загального процесу (вікно Frequency) і тривалість (Duration). Потім слід вибрати в списку один з центрів витрат і у вікні Cost задати його вартість. Аналогічно призначаються суми по кожному центру витрат, тобто задається вартість кожної роботи по кожній статті витрати. Загальні витрати по роботі розраховуються як сума по всіх центрах витрат. При обчисленні витрат вищестоящої роботи спочатку обчислюється твір витрат дочірньої роботи на частоту робіт, потім результати складаються. Якщо у всіх роботах моделі включений режим Compute from Decompositions, подібні обчислення автоматично проводяться за всією ієрархією робіт від низу до верху. Це достатньо спрощений принцип підрахунку справедливий, якщо роботи виконуються послідовно. Якщо схема виконується складніша (наприклад, роботи виконуються альтернативно), можна відмовитися від підрахунку і задати підсумкові суми для кожної роботи уручну (Override Decompositions). В цьому випадку результати розрахунків з нижніх рівнів декомпозиції ігноруватимуться, при розрахунках на верхніх рівнях враховуватиметься сума, задана уручну. На будь-якому рівні результати розрахунків зберігаються незалежно від вибраного режиму, тому при виключенні опції Override Decompositions розрахунок від низу до верху проводиться звичайним способом.

Результати вартісного аналізу наочно представляються на спеціальному звіті - Activity Cost Report (меню Tools/Report/ Activity Cost Report).
1.1.5 Рекомендації по малюванню діаграм
У реальних діаграмах до кожної роботи може підходити і від кожної може відходжувати близько десятка стрілок. Якщо діаграма містить 6-8 робіт, то вона може містити 30-40 стрілок, причому вони можуть зливатися, розгалужуватися і перетинатися. Такі діаграми можуть стати дуже погано читаними. У IDEF0 існують угоди по малюванню діаграм. Деякі з цих правил BPwin підтримує автоматично, виконання інших слід забезпечити уручну.

Прямокутники робіт повинні розташовуватися по діагоналі з лівого верхнього в правий нижній кут (порядок домінування);

· Слід максимально збільшити відстань між вхідними або такими, що виходять стрілками на одній грані роботи;

· Зворотні зв'язки по входу малюються “нижньою” петлею, зворотний зв'язок по управлінню - “верхньою”;

· Слід мінімізувати число перетинів, петель і поворотів стрілок.
1.2 DFD - діаграми потоків даних
Діаграми потоків даних (Data flow diagramming, DFD) використовуються для опису документообігу і обробки інформації.

DFD описує:

функції обробки інформації (роботи);

· документи (стрілки), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;

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

· таблиці для зберігання документів (сховища даних).

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

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

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

На відміну від IDEF0, де система розглядається як взаємозв'язані роботи, DFD розглядає систему як сукупність предметів.

Таким чином, основними компонентами діаграм потоків даних є:

роботи;


· зовнішня суть;

· стрілки (потоки даних);

· сховище даних.

Для того, щоб доповнити модель IDEF0 діаграмою DFD потрібно в процесі декомпозиції в діалозі Activity Box Count "кликнути" по радіокнопці DFD. У палітрі інструментів на новій діаграмі DFD з'являються нові кнопки:



додати в діаграму зовнішнє посилання;

додати в діаграму сховище даних.

1.2.1 Роботи

У DFD роботи є функції системи, що перетворюють входи у виходи. Роботи зображаються прямокутниками з округляючими кутами. Їх сенс співпадає з сенсом робіт IDEF0, вони також мають входи і виходи, але не підтримують управління і механізми.


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

Р
ис. 7 Зовнішня суть

Зовнішня суть зображається у вигляді прямокутника з тінню і зазвичай розташовуються по краях діаграми (рис.7). Одна зовнішня суть може бути використана багато разів на одній або декількох діаграмах. Зазвичай такий прийом використовують, щоб не малювати дуже довгих і заплутаних стрілок.
1.2.3 Стрілки (потоки даних)
Стрілки описують рух об'єктів з однієї частини системи в іншу. Оскільки в DFD кожна сторона роботи не має чіткого призначення, як в IDEF0, стрілки можуть підходити і виходити з будь-якої грані прямокутника роботи. Кожен потік даних має ім'я, зміст, що відображає його (рис.8).

У DFD застосовуються двонаправлені стрілки для опису діалогів типу «команда - відповідь» між роботами, між роботою і зовнішньою суттю і між зовнішньою суттю (рис.9).

Р
ис.8 Потік даних



Рис.9 Діалог типу "команда-відповідь" (контекстна діаграма)

У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описувати декомпозицію стрілок. Кожен новий сегмент зливається і стрілки, що розгалужується, може мати своє власне ім'я.
1.2.4 Сховища даних
На відміну від стрілок, що описують об'єкти в русі, сховища даних зображають об'єкти у спокої. Сховища даних можуть бути реалізовані фізично у вигляді ящика в картотеці, таблиці в оперативній пам'яті, файлу на магнітному носієві і т.д. Сховища даних на діаграмі потоків даних зображаються, як показано на малюнку 10.

Рис.10 Накопичувач даних

У матеріальних системах сховища даних зображаються там, де об'єкти чекають обробки, наприклад в черзі. У системах обробки інформації сховища даних є механізмом, який дозволяє зберегти дані для подальших процесів. Ім'я накопичувача вибирається з міркування найбільшої інформативності для проектувальника.
1.2.5 Нумерація об'єктів
У DFD номер кожної роботи може включати префікс, номер батьківської роботи (А) і номер об'єкту. Номер об'єкту - це унікальний номер роботи на діаграмі. Унікальний номер мають сховища даних і зовнішню суть не залежно від їх розташування на діаграмі. Кожне сховище даних має префікс D і унікальний номер, наприклад D5. Кожна зовнішня суть має префікс E і унікальний номер, наприклад E5.
1.3 Метод опису процесів IDEF3
Діаграми IDEF3 можуть бути використані в моделюванні бізнес - процесів для аналізу завершеності процедур обробки інформації. З їх допомогою можна описувати сценарії дій співробітників організації. Під сценарієм розумітимемо послідовність ситуацій або дій, які описують типовий клас проблем, присутніх в організації або системі, опис послідовності властивостей об'єкту, що повторюється, в рамках даного процесу (наприклад, послідовність обробки замовлення).

IDEF3 представляє інструментарій для наочного дослідження і моделювання сценаріїв виконання процесів. Метод дозволяє проводити опис з необхідним ступенем подробиці за допомогою використання декомпозиції. IDEF3 як інструмент моделювання фіксує наступну інформацію про процес:

· Об'єкти, які беруть участь при виконанні сценарію;

· Ролі, які виконують ці об'єкти (наприклад, агент, транспорт і т.д.);

· Відносини між працівниками в ході виконання сценарію процесу;

· Стану і зміни, якою піддаються об'єкти;

· Час виконання і контрольні точки синхронізації робіт;

· Ресурси, які необхідні для виконання робіт.

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

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


1.3.1 Одиниці роботи - Unit of Work (UOW)
UOW, також звані роботами, є центральними компонентами моделі. У IDEF3 роботи зображаються прямокутниками з прямими кутами і мають ім'я, що позначає процес дії, і номер (ідентифікатор); інший іменник у складі тієї ж фрази зазвичай відображає основний вихід (результат) роботи (наприклад, «Виготовлення виробу»). Зазвичай номер роботи складається з номера батьківської роботи і порядкового номера на поточній діаграмі.
1.3.2 Зв'язки
Зв'язки показують взаємовідношення робіт. Всі зв'язки в IDEF3 однонаправлени і можуть бути направлені куди завгодно, але зазвичай діаграми IDEF3 прагнуть побудувати так, щоб зв'язки були направлені зліва направо. У IDEF3 розрізняють три типи стрілок, що зображають зв'язки, стиль яких встановлюється через меню Model/Default Arrow Types:

Старша (Precedence) - суцільніша лінія, що зв'язує одиниці робіт. Малюється зліва направо або зверху вниз. Показує що робота - джерело повинна закінчитися перш, ніж робота-мета почнеться.

· Відносини (Relational Link) - пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (робота-мета починається, коли робота-джерело ще не закінчилася), а так само між одиницями робіт і об'єктами посилань.

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

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

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



Перехрестя (Junction). Закінчення однієї роботи може служити сигналом до початку декількох робіт, або ж ода робота для свого запуску може чекати закінчення декількох робіт. Перехрестя використовуються для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out Junction) стрілок. Перехрестя не може одночасно використовуватися для злиття і розгалуження. У діалозі Select Junction Type указується тип перехрестя. Розрізняють декілька типів перехресть (таблиця 1). Всі перехрестя на діаграмі нумеруються, кожен номер має префікс J. Можна редагувати властивості перехрестя за допомогою діалогу Definition Editor. На відміну від IDEF0 і DFD в IDEF3 стрілки можуть зливатися або розгалужуватися тільки через перехрестя.

Таблиця 1



Назва

Зміст у випадку злиття стрілок (Fan-in Junction)

Зміст у випадку розгалуження стрілок (Fan-out Junction)

1

2

3

Asynchronous (AND)


Всі процеси, що були перед тим повинні бути завершені

Всі наступні процеси повинні бути розпочаті

Synchronous (AND)

Всі процеси, що були перед тим повинні бути завершені одночасно

Всі наступні процеси повинні бути розпочаті одночасно

Asynchronous (OR)

Один чи декілька процесів, що були перед тим повинні бути завершені

Один чи декілька наступних процесів повинні бути розпочаті

Synchronous (OR)

Один чи декілька процесів, що були перед тим завершені одночасно

Один чи декілька наступних процесів розпочаті одночасно

XOR (Exclusive OR)

Тільки один процес, що був перед тим завершений

Один наступний процес розпочатий


1.3.3 Об'єкт посилання
Об'єкт посилання в IDEF3 виражає якусь ідею, концепцію або дані, які не можна пов'язати із стрілкою, перехрестям або роботою (рис.11). Для внесення об'єкту посилання служить кнопкав палітрі інструментів:

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

Р
ис.11 Об'єкт посилання.

Офіційна специфікація IDEF3 розрізняє три стилі об'єктів посилань - безумовні (unconditional), синхронні (Synchronous) і асинхронні (Asynchronous). BPwin підтримує тільки безумовні об'єкти посилань. Синхронні і асинхронні об'єкти посилань, використовувані на діаграмах переходів станів об'єктів, не підтримуються. При внесенні об'єктів посилань крім імені слід указувати тип об'єкту посилання (таблиця 2).

Таблиця 2


Тип об'єкту посилання

Мета опису

1

2

OBJECT

Описує участь важливого об'єкту в роботі

GOTO

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

UOB (Unit of behavior)

Застосовується коли необхідно підкреслити множинне використання якої-небудь роботи, але без циклу. Наприклад, робота «Контроль якості» може бути використаний в процесі «Виготовлення виробу» кілька разів, після кожної одиничної операції. Зазвичай цей тип посилання не використовується для моделювання робіт, що автоматично запускаються.

NOTE

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

ELAB (Elaboration)

Використовується для удосконалення графіків або їх детального опису. Зазвичай уживається для детального опису розгалуження і злиття стрілок на перехрестях.


2 Створення моделі даних за допомогою ERwin
Erwin має два рівні представлення даних: логічний і фізичний. Логічний рівень - це абстрактний погляд на дані, на нім дані представляються так, як виглядають в реальному світі, наприклад "Постійний клієнт", "Відділ" або "Прізвище співробітника". Фізична модель даних, навпаки, залежить від конкретної СУБД, фактично будучи відображенням системного каталога. У фізичній моделі міститься вся інформація про всі об'єкти БД.

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


Р
ис.12 Перемикання між логічною і фізичною моделлю

При перемиканні, якщо фізичної моделі ще не існує, вона буде створена автоматично.


2.1 Палітра інструментів в Erwin
Палітра інструментів виглядає так:

Кнопка покажчика (режим миші) - в цьому режимі можна встановити фокус на якому-небудь об'єкті моделі;

·
Кнопка внесення суті - для внесення суті потрібно клацнути лівою кнопкою миші по кнопці внесення суті і один раз по вільному простору на моделі;

·
Кнопка категорії. Для встановлення зв'язку необхідно клацнути по кнопці, потім один раз клацнути по суті - родовому предкові, потім - по суті-нащадкові;

·
Кнопки створення зв'язку: що ідентифікує, "многие-ко-многим" і що не ідентифікує.

E
rwin має декілька рівнів відображення діаграми: рівень суті, рівень атрибутів, рівень визначень, рівень первинних ключів і рівень ікон. Перемикатися між ними можна за допомогою контекстного меню, яке з'являється, якщо "кликнути" по будь-якому місцю діаграми, не зайнятому об'єктами моделі. У контекстному меню слід вибрати пункт Display Level, і потім необхідний рівень відображення.


2.2 Створення логічної моделі даних
2.2.1 Рівні логічної моделі
Розрізняють три рівні логічної моделі, що відрізняються по глибині представлення інформації:

Діаграма суть-зв'язок (Entity Relationship Diagram, ERD);

· Модель даних, заснована на ключах (Key Based model, KB);

· Повна атрибутивна модель (Full Attributed model, FA).



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

Модель даних, заснована на ключах, - докладніше представлення даних. Вона включає опис всієї суті і первинних ключів і призначена для представлення структури даних і ключів, які відповідають наочній області.

Повна атрибутна модель - найбільш детальне представлення структури даних: включає всю суть, атрибути і зв'язки.Побудову моделі даних припускає визначення суті і атрибутів, тобто необхідно визначити яка інформація зберігатиметься в конкретній суті або атрибуті. Суть можна визначити як об'єкт, подію або концепцію, інформація про яких повинна зберігатися. Суть повинна мати найменування з чітким смисловим значенням, іменуватися іменникам в однині, не носити "технічних" найменувань і бути досить важливими для того, щоб їх моделювати. Наприклад, "Продавець" з атрибутами "Унікальний номер", "Прізвище", "Адреса". Для внесення суті до моделі необхідно "кликнути" по кнопці суть на панелі інструментів, потім "кликнути" по тому місцю на діаграмі, де необхідно розташувати нову суть. Клацнувши правою кнопкою миші по суті і вибравши із спливаючого меню пункт Entity Properties, можна викликати діалог Entities, в якому визначаються ім'я, опис і коментарі суті. Закладка Definition використовується для введення визначення суті. Закладка Note дозволяє додавати зауваженнУ закладці Icon кожної суті можна поставити у відповідність зображення, яке зображатиметься в режимі проглядання моделі на рівні ікон. У цій закладці можна задати, як велику ікону, яка відображатиметься на рівні Icon, так і малу ікону, яка відображатиметься на всіх рівнях проглядання моделі. Для пов'язання зображення з суттю необхідно клацнути по кнопці:

У
діалозі, що з'явився, клацнути по кнопці Import і вибрати відповідний файл bmp.

я об суть, яка не була відображена у визначенні, введеному в закладці Definition. Тут можна ввести корисне зауваження, що описує яке-небудь бізнес-правило або угода по організації діаграми. Закладка Note 3 дозволяє вводити приклади даних для суті (у довільній формі).
2.2.2 Суть і атрибути
діл" або "Прізвище співробітника". Фізична модель даних, навпаки, залежить від конкретної СУБД, фактично будучи відображенням системного каталога. У фізичній моделі міститьсяКожен атрибут зберігає інформацію про певну властивість суті, а кожен екземпляр суті повинен бути унікальним. Атрибут або група атрибутів, які ідентифікують суть називають первинним ключем. Для опису атрибутів слідує, "кликнути" правою кнопкою миші по суті, вибрати в меню, що з'явилося, пункт Attributes. З'явитися діалог Attributes. Якщо клацнути по кнопці New, то в діалозі, що з'явився, можна вказати ім'я атрибуту, ім'я відповідною йому у фізичній моделі колонки(рис.13).



Рис.13 Діалог New Attribute

Для атрибутів первинного ключа в закладці General необхідно зробити позначку у вікні вибору Primary Key. Закладка Definition дозволяє записувати визначення окремих атрибутів. Закладка Note дозволяє додавати зауваження про одному або декілька атрибутів суть, яка не увійшла до визначень. Для більшої наочності діаграми кожен атрибут можна пов'язати з іконою. За допомогою списку вибору Icon в закладці General можна пов'язати ікону з атрибутом. Для відображення ікони атрибуту слід вибрати в контекстному меню пункт Format/Entity Display і в каскадному меню включити опцію Attribute Icon. Мала ікона буде показана зліва від імені атрибуту на рівні відображення моделі (рис.14).

Р
ис.14 Відображення суті на рівні атрибутів з включеною опцією Attribute Icon

Дуже важливо дати атрибуту правильне ім'я. Атрибути повинні іменуватися в однині і мати чітке смислове значення. Кожен атрибут повинен бути визначений, при цьому слід уникати циклічних визначень.
2.2.3 Зв'язки
Зв'язок є логічним співвідношенням між суттю. Кожен зв'язок повинен іменуватися дієсловом або дієслівною фразою (Relationship Verb Phrases). Ім'я зв'язку виражає деяке обмеження або бізнес-правило і полегшує читання діаграми, наприклад (рис.15):

Кожен КЛІЄНТ <розміщує > Замовлення;

· Кожне ЗАМОВЛЕННЯ <виконується> Співробітником.



Рис.15 Ім'я зв'язку - Relationship Verb Phrases

Зв'язок показує, які саме замовлення розмістив клієнт і який саме співробітник виконує замовлення. За умовчанням ім'я зв'язку на діаграмі не показується. Для відображення імені слідує в контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші по будь-якому місцю діаграми, не зайнятому об'єктами моделі, вибрати пункт Relationship Display/Verb Phase.

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

Розрізняють залежну і незалежну суть. Тип суті визначається її зв'язком з іншою суттю. Ідентифікуючий зв'язок встановлюється між незалежною (батьківський кінець зв'язку) і залежною (дочірній кінець зв'язку) суттю. Коли малюється ідентифікуючий зв'язок, Erwin автоматично перетворить дочірню суть в залежну. Залежна суть зображається прямокутником з округляючими кутами (рис.16). Екземпляр залежної суті визначається тільки через відношення до батьківської суті, тобто в структурі інформація про заявку не може бути внесена і не має сенсу без інформації про брокера, який її розміщує. При встановленні ідентифікуючого зв'язку атрибут первинного ключа батьківської суті автоматично переноситься до складу первинного ключа дочірньої суті. Ця операція доповнення атрибутів дочірньої суті при створенні зв'язку називається міграцією атрибутів. У дочірній суті нові атрибути позначаються як зовнішній ключ - (FK).

Р
ис.16 Ідентифікуючий зв'язок між незалежною і залежною таблицею


При встановленні неідентифікуючого зв'язку (рис.17) дочірня суть залишається незалежною, а атрибути первинного ключа батьківської суті мігрують до складу неключових компонентів батьківської суті. Наприклад, екземпляр суті СПІВРОБІТНИК може існувати безвідносно до якого-небудь екземпляра суті ВІДДІЛ, тобто співробітник може працювати в організації, не числившись в якому-небудь відділі.

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

Р
ис.17 Неідентифікуючий зв'язок

Потужність зв'язку (Cardinality) - служить для позначення відношення числа екземплярів батьківської суті до екземплярів дочерней. Для завдання потужності треба "кликнути" правою кнопкою миші по зв'язку і в меню, що з'явилося, вибрати пункт Properties закладку General.

Розрізняють чотири типи потужності:

загальний випадок, коли одному екземпляру батьківської суті відповідає 0,1 або багато екземплярів батьківської суті не позначається яким-небудь символом;

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

· символом Z позначається випадок, коли одному екземпляру батьківської суті відповідають 0 або 1 екземпляр дочірньої суті;

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

За умовчанням символ, що позначає потужність зв'язку, не показується на діаграмі. Для відображення імені слідує в контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші по вільному місцю діаграми, вибрати пункт меню Relationship Display/Cardinality.

Ім'я зв'язку (Verb Phrase) - фраза, що характеризує відношення між батьківською і дочірньою суттю. Для зв'язку одін-ко-многим ідентифікує або не ідентифікує досить вказати ім'я, що характеризує відношення від батьківської до дочірньої суті (Parent-to-Child). Для зв'язку многої-ко-многим слід вказати імена як Parent-to-Child так і Child-to-Parent.

2.2.4 Ієрархія спадкоємства (або ієрархія категорій)
Ієрархія спадкоємства є особливим типом об'єднання суті, яка розділяє загальні характеристики. Наприклад, при переписі населення переписують всіх дорослих і дітей. З їх загальних властивостей можна сформувати загальну суть (родовий предок) ЧОЛОВІК (рис.18), щоб представити інформацію, загальну для всіх. Специфічна для кожного типу інформація може бути розташована в категоріальній суті (нащадках) ДОРОСЛИЙ і ДИТИНА.

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

Р
ис.18 Ієрархія спадкоємства. Неповна категорія

Ієрархії категорій діляться на два типи - повні і неповні. У повній категорії одному екземпляру родового предка (суть ЧОЛОВІК рис.19) обов'язково відповідає екземпляр в каком- або нащадку, тобто в прикладі людьми обов'язково є або дорослий, або дитина.

Якщо категорія ще не збудована повністю і в родовому нащадку можуть існувати екземпляри, які не мають відповідних екземплярів в нащадках, то така категорія буде неповною. На малюнку 18 показана неповна категорія - СПІВРОБІТНИК може бути не тільки постійним або сумісником, але і консультантом, проте суть КОНСУЛЬТАНТ ще не внесена до ієрархії спадкоємства.

Р
ис.19 Ієрархія спадкоємства. Повна категорія

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

Для створення категорійной зв'язку слідує:

клацнути по кнопці категорія панелі інструментів;

· клацнути спочатку по родовому предкові, а потім по нащадкові;

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

Р
ис.20 Ієрархія спадкоємства. Комбінація повної і неповної категорії


3 Завдання до лабораторних робіт
Створити модель на одну з тем:

Робота приймальної комісії;

· Виготовлення деталі;

· Продаж автомобіля;

· Виготовлення меблів;

· Заготівка деревини;

· Покупка (вибір) комп'ютера;

· Робота ріелтерськой компанії;

· Випуск номера газети;

· Приготування тістечка;

· Виготовлення пластмаси;

· Будівництво будинку;

· Пошивши одяг;

· Робота фотолабораторії;

· Робота складу по обліку матеріальних цінностей;

· Робота мережевого адміністратора.



Можна запропонувати свою тему.

Завдання до 1 лабораторної роботи:

  1. Побудувати модель на одну з вище вказаних тим, використовуючи методологію IDEF0 програмного пакету BPWin 4.0.

  2. Сформулювати мету моделювання, точку зору, визначення моделі, опис області і джерело інформації.

  3. У роботі використовувати (по можливості) всі види стрілок.

  4. Зберегти роботу на дискеті.



Завдання до 2 лабораторної роботи:

  1. Зробити опис властивостей (Definition) для кожної роботи, стрілки (у моделі створеною на 1 лабораторній роботі).

  2. Провести вартісною аналіз.

  3. Створити можливі звіти.

  4. Показати діаграму дерева вузлів.

  5. Лабораторна робота повинна бути надана викладачеві в роздрукованому вигляді (лістинг (не меншого 4 листів), всі види звітів, діаграма дерева вузлів).



Завдання до 3 лабораторної роботи:

  1. Побудувати модель на одну з вище вказаних тим, використовуючи методологію DFD програмного пакету BPWin 4.0.

  2. Сформулювати мету моделювання, точку зору, визначення моделі, опис області і джерело інформації.

  3. У роботі використовувати (по можливості) всі види стрілок.

  4. Зберегти роботу на дискеті.



Завдання до 4 лабораторної роботи:


  1. Зробити опис властивостей (Definition) для кожної роботи, стрілки, сховищ даної і зовнішньої суті (у моделі створеною на 3 лабораторній роботі).

  2. Провести вартісною аналіз.

  3. Створити можливі звіти.Лабораторна робота повинна бути надана викладачеві в роздрукованому вигляді (лістинг (не меншого 4 листів), всі види звітів, діаграма дерева вузлів).



  4. Показати діаграму дерева вузлів.



Завдання до 5 лабораторної роботи:


  1. Построить модель на одну из выше указанных тем, используя методологию IDEF3 программного пакета BPWin 4.0.

  2. Сформулировать цель моделирования, точку зрения, определение модели, описание области и источник информации.

  3. В работе использовать (по возможности) все виды стрелок.

  4. Сохранить работу на дискете.


Завдання до 6 лабораторної роботи:

  1. Зробити опис властивостей (Definition) для кожної роботи, стрілки, об'єкту посилання, перехрестя (у моделі створеною на 5 лабораторній роботі).

  2. Провести вартісною аналіз.

  3. Створити можливі звіти.

  4. Показати діаграму дерева вузлів.

  5. Лабораторна робота повинна бути надана викладачеві в роздрукованому вигляді (лістинг (не меншого 4 листів), всі види звітів, діаграма дерева вузлів).


Завдання до 7 лабораторної роботи:


  1. Вивчити можливості логічного рівня програмного пакету ERwin.

  2. Створити повну атрибутивну модель відображення ікон, імен і потужності зв'язку (використовувати як можна більша кількість видів зв'язку), відобразити ієрархію спадкоємства (повну і неповну).

  3. Надати лістинг викладачеві в роздрукованому вигляді.


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

Технічне забезпечення - комплекс технічних засобів, призначених для роботи ІС, а також відповідна технічна документація на ці засоби і технічні процеси. До них відносяться компаратори, пристрої збору, наповнення, обробки, передачі і виведення інформації, пристрої передачі даних і лінії зв'язку і т.д.

Документацію можна розділити на 3 групи:

1. Загальносистемна, включає державні і галузеві стандарти по технічному забезпеченню;

2. Спеціалізована, така, що сполучає комплекс методик по всіх етапах розробки технічного забезпечення;

3. Нормативно-довідкова.

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

Все ПО діляться на 3 групи:

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

2. Спеціалізоване - сукупність програм, розроблених при створенні конкретної ІС.

3. Технічна документація на розробку програмних засобів.

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

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

1. Статус ІС

2. Має рацію і обов'язку, відповідального персоналу

3. Порядок створення і використання інформації.


Теми:

1. Розробка мультимедійних інтерактивних 3D моделей

2. Організація діяльності птахофабрики

3. Організація діяльності хлібобулочного підприємства

4. Технологічний процес виробництва паперу

5. Організація обліку товару на складі

6. Виготовлення друкарської продукції

7. Організація діяльності розрахункової частини підприємства

8. Робота складального конвейєра машинобудівного підприємства

9. Автоматизація документообігу підприємства

10. Автоматизація бібліотечного фонду

11. Розробка програмного забезпечення

12. Організація діяльності податкової інспекції

13. Організація взаєморозрахунків з клієнтами в торговому підприємстві

14. Організація діяльності підприємств телекомунікацій

15. Реалізація автомобілів на ринку міста Архангельська

16. Надання послуг з ремонту автомобілів

17. Виготовлення рекламної продукції



18. Виготовлення продукції з радіо кераміки

Література



  1. Вендров А.М. CASE – технологии. Современные методы и средства проектирования информационных систем. – ИТМО, http://cs.ifmo.ru/win/education/documentation/case/index/shtml

  2. Маклаков С.В. "BPwin, ERwin. CASE-средства разработки информационных систем." М:Диалог-МИФИ, 1999г.

  3. Окулесский В.А. "Функциональное моделирование - методологическая основа реализации процессного подхода". НИЦ "Прикладная логистика"

  4. Типовой СТП. CALS – технологии. Моделирование процессов предприятия с использованием методологии IDEF0. – НИЦ CALS – технологии: «Прикладная логистика»,2001.


Поділіться з Вашими друзьями:


База даних захищена авторським правом ©wishenko.org 2017
звернутися до адміністрації

    Головна сторінка