Приклад використання стандарту IDEF0 для побудови моделі TO-BE, що описує процес управління договорами
Приклад використання стандарту IDEF0 для побудови моделі TO-BE, що описує процес управління договорами - раздел Высокие технологии, З курсу CASE- технології Усіх форм навчання
Розробник Моделі Перед Тим, Щоб Перейти До Побудови Моделі «Я...
Розробник моделі перед тим, щоб перейти до побудови моделі «як повинно бути», має визначити ті роботи, котрі можуть бути:
– видалені у зв’язку з їх незначущістю або по іншим причинам;
– об’єднані у зв’язку з тим, що роботи є продовженням одна одної з одним й тим же виконавцем, а формування звіту по закінченню першої роботи недоцільно;
– зменшена вартість за рахунок відмови від ітераційного узгодження, зменшення часу простоїв та передачі проміжного результату від одного виконавця – іншому та ін.
Перед формуванням моделі «як повинно бути» необхідно розробити таблицю порівняння моделей, в котрій й буде вказуватися за рахунок чого модель «як є» перетворюється в модель «як повинно бути». Фрагмент цієї таблиці для модуля «Управління договорами по виробництву та постачанню готової продукції» («як є») і модуля «Управління договорами» («як повинно бути») наведено у табл. 4.
Після того, як визначено принципи зміни, розробник виконує побудову моделі «як повинно бути».
Модель TO-BE будується так саме, як і модель AS-IS (дивись лабораторну роботу № 1). Єдиною відмінністю є те, що в діалозі Model / Model Properties на закладці General (рис. 44) необхідно вказати тип моделі – TO-BE (за замовчуванням стоїть тип AS-IS).
Таблиця 4
Таблиця порівняння моделей «як є» і «як повинно бути» для модуля «Управління договорами»
ASIS
TOBE
Відмінності
№
Найменування робіт
№
Найменування робіт
Укладання договорів
Ведения реєстру договорів
–
Планування постачань
Планування постачань
2.1
Вибір календарного плану постачань
2.1
Формування календарних планів поставок
Об’єднання робіт 2.1, 2.2, 2.3 та 2.4 у роботу «Формування календарних планів поставок»
2.2
Вибір інформації з реєстру договорів
2.3
Складання плану постачання продукції на плановий період по регіонах
2.4
Складання календарного плану постачань продукції покупцям за днями
Планування та облік випуску ГП
Планування випуску та облік ГП
Об’єднання процедур 3 та 4
3.1
Планування портфелю замовлень
2.3
Формування портфелю замовлень
Перенесення у іншу процедуру
3.2
Планування виробничої програми
3.1
Формування виробничої програми випуску продукції
3.3
Облік випуску ГП
3.3
Облік випуску ГП та передача на склад
Складський облік ГП та її відвантаження
4.1
Планування та облік відвантаження товару
3.2
Складання графіку відвантаження продукції покупцям
Базові поняття
Модель– опис системи (текстовий або графічний) з визначеним рівнем деталізації.
Об’єкт моделі – об’єкт в базі даних інструментального середовища моделюван
ТЕОРЕТИЧНА ЧАСТИНА
Для опису роботи об'єкту управління (підприємства, проекту) необхідно побудувати модель. Модель являється загальним описом предметної області. Проте модель повинна бути адекватна пр
Принципи побудови моделі IDEF0 у BPwin
Процес моделювання будь-якої системи в IDEF0 у BPwin починається з визначення контексту, тобто найбільш абстрактного рівня опису системи в цілому. У контекст входить визначення суб'
Приклад опису задачі, що моделювалася
У процесі аналізу предметної області, була складена контекстна діаграма (рис.15), для якої були визначені наступні інтерфейсні дуги:
- вхід: замовлення, заявки; банківська виписка.
ТЕОРЕТИЧНА ЧАСТИНА
Документування результатів моделювання є найважливішою задачею при проектуванні ІС, причому актуальність цієї задачі тим більше, чим масштабніше проект.
Для створення докум
Звіт Diagram Object Report.
При виборі пункту меню, який відповідає якому-небудь звіту, з'являється діалог настройки звіту. Для кожного з семи типів звітів він виглядає по-своєму. Розглянемо типовий діалог Diagram Obj
Звіт Diagram Report.
При створенні цього типу звіту необхідно звертати увагу на методологію діаграми, оскільки залежно від цього проводиться настройка параметрів звіту.
• Для діаграм IDEF0 параметри задаються
Приклад опису задачі, що моделювалася
У процесі аналізу предметної області, з урахуванням удосконалення та автоматизації деяких робіт, була складена контекстна діаграма (рис. 45), для якої були визначені наступні інтерфейсні дуги:
ТЕОРЕТИЧНА ЧАСТИНА
Функціонально-вартісний аналіз ґрунтується на оцінці та аналізі об’єктів витрат за бізнес-процесами та формування центрів витрат для них. Найчастіше для функціонально-вартісного ана
ТЕОРЕТИЧНА ЧАСТИНА
Функціонально-вартісний аналіз ґрунтується на оцінці та аналізі об’єктів витрат за бізнес-процесами та формування центрів витрат для них. Найчастіше для функціонально-вартісного ана
Приклад використання ФВА для аналізу моделі
Проектувальник повинен визначити до початку проведення функціонально-вартісного аналізу той набір центрів витрат, а також одиниці вимірювання часу і витрат для даної моделі. Це здій
Базові поняття
Одиниці робіт (Unit of Work – UOW)або роботи (activity)– ряд впорядкованих дій, процедур, які приводять до проміжного результату.
Зв'язок
ТЕОРЕТИЧНА ЧАСТИНА
Діаграми потоків даних (Data flow diagramming, DFD) використовуються для опису документообігу і обробки інформації. Подібно IDEF0, DFD представляє модельну систему як мережу зв'язан
КОНТРОЛЬНІ ЗАПИТАННЯ
1. Що зображує діаграма DFD?
2. Яка нотація використовується в BPwin для побудови діаграм DFD?
3. Перерахуйте складові частини діаграми DFD.
4. Що називає
Додаток А
Вимоги до задач, котрі входять до модуля «Управління договорами»
Задача 0601 «Ведення реєстру договорів на постачання (продаж) продукції покупця
Хотите получать на электронную почту самые свежие новости?
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Новости и инфо для студентов