Меню Рубрики

Укажите чему должна соответствовать точка зрения

Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (Scope). Определение области моделирования подразумевает описание:

· субъекта моделирования (субъект – сама система), в процессе описания которого устанавливается:

ü что входит в систему (является ее компонентами),

ü что лежит за ее пределами (является внешним воздействием).

· цели моделирования (Purpose –закладка Purpose меню Edit/Model Properties), которая должна отвечать на следующие вопросы:

ü почему этот процесс должен быть замоделирован?

ü Что должна показывать модель?

ü Что может получить читатель?

Примеры: а) «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений»,

б) Идентифицировать роли и ответственность служащих для написания должностных инструкций,

в) описать функциональность предприятия с целью написания спецификаций ИС и т.д.

· точки зрения (Viewpoint —закладка Purpose меню Edit/Model Properties) на модель.

Точка зрения – перспектива, с которой наблюдалась система при построении модели (Черемных) или иначе – это взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно точки зрения, например, финансиста и технолога различны и поэтому выбирается точка зрения человека, ответственного за систему в целом, например руководителя предприятия.

· Источников информации для построения модели (Source)

Пример: «Опрос экспертов предметной области и анализ документации».

· Статуса модели: черновой вариант, рабочий, окончательный и т.д.

· Временных рамок (AS-IS или TO-BE)

Вначале создается модель, на которой можно определить слабые места предприятия, например бесполезные, дублирующие и неуправляемые работы, неэффективный документооборот (нет нужных документов на нужном месте в нужное время), отсутствие обратной связи по управлению (нет результата) или по входу (информация используется нерационально).

AS-IS — «что мы делаем сегодня», перед тем как перепрыгнуть на то, «что мы будем делать завтра». Неверно, если создается идеализированная модель (например, на основе знаний руководителя, а не конкретного исполнителя), такая модель называется SHOULD BE (как должно бы быть).

После анализа модели AS-IS и улучшения бизнес-процессов, создается модель TO-BE, и только на основе модели TO-BE строится впоследствии модель данных, прототип, а затем окончательный вариант ИС

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Студент — человек, постоянно откладывающий неизбежность. 9480 — | 6695 — или читать все.

193.124.117.139 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Создание функциональной модели предметной области — 3

Ключевые слова:функциональная модель, методологияIDEF0,CASE-средства, предметная область, область моделирования, цель моделирования, точка зрения.

Методические указания к лабораторной работе

Цель:закрепить навыки моделирования предметной области.

Времы выполнения:2 часа.

Задание:создать функциональную модель (1 уровень декомпозиции исключая нулевой) в выбранной (из вариантов) предметной области.

1. Разработать функциональную модель процесса учета товаров на складе

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

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

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

5. Разработать функциональную модель процесса учета валютных операций в кассе банка.

6. Разработать функциональную модель процесса оптовой продажи товаров предприятия.

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

8. Разработать ункциональную модель процесса начисления зарплаты.

9. Разработать функциональную модель процесса платного приема больных в поликлинике.

Этапы выполнения работы

Выбрать вариант задания.

Определить цель моделирования.

Определить точку зрения модели.

Описать статус модели.

Создать контекструю диаграмму.

Создать один уровень декомпозиции.

Проверить синтаксис построенной модели.

Сформировать дерево узлов NodeTree.

Создать каркас диаграммы.

Получить отчеты BPWin(7 отчетов).

Выбор области моделирования

В начале построения модели необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования.

При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.

Выбор цели моделирования

Цель моделирования определяется из ответов на следующие вопросы:

Почему этот процесс должен быть смоделирован?

Что должна показывать модель?

Что может получить клиент?

Выбор точки зрения

Под точкой зрения (Viewpoint) понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.

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

На рис. показано, как автор модели экспериментального механического цеха перечисляет претендентов (механик, кон­тролер), с точки зрения которых можно было бы описывать механический цех.

Рис. Пример определения цели и точки зрения модели ЭМЦ

«Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. С этой фиксированной точки зрения можно создать согласованное описание системы так, чтобы модель не дрейфовала вокруг да около, и в ней не смешивались бы несвязанные описа­ния. Например, если в модели эксперименталь­ного механического цеха не зафиксировать определенную точку зрения, то легко можно смешать проблему обслуживания станков цеха с тем, как будет обработана деталь. Если это про­изойдет, то читатель модели столкнется с труд­ностями при определении конкретных обязан­ностей персонала.

Иногда только одна из множества возмож­ных точек зрения может дать описание, удовлет­воряющее цели модели. Например, для создания согласованной модели механического цеха можно встать на точку зрения как мастера, так и меха­ника или контролера, но ни одна из них сама по себе не даст модели, которая позволила бы напи­сать учебное руководство для всего персонала. Только с позиции начальника цеха можно уви­деть все виды работ, выполняемых в цехе. Имен­но с его точки зрения, как указано в замечании на рис. 1-1, можно проследить взаимосвязи обя­занностей различных работников. Точка зрения начальника цеха позволяет создателю модели определить роль каждого работника в изготов­лении отдельных деталей и описать координацию обязанностей персонала.

Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате).

В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет.

Укажите, чему должна соответствовать точка зрения

-: мнению различных людей

21. Какое назначение имеет стоимостный анализ?

+: понять происхождение выходных затрат

-: определить очередность выполнения работ

+: определить действительную стоимость производства продукта

+: обеспечить менеджеров финансовой мерой предлагаемых изменений

22. Для описания сценариев действий сотрудников организации или вариантов работы информационной системы служат:

+: диаграммы нотации IDEF3

-: диаграммы потоков данных

-: диаграммы нотации IDEF0

-: диаграммы нотации IDEF1X

23. Объект Переход в диаграммах STD определяет:

+: перемещение моделируемой системы из одного состояние в другое

-: стартовую точку для начала функционирования системы

-: условие устойчивости для системы

-: связь между двумя или более сущностями

24. Словарь данных при построении диаграмм потоков данных (DFD):

+: обеспечивает аналитика средствами описания деталей компонентов DFD, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ

-: рассматривается как условие функционирования проектируемой системы

-: используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD

25. Тип взаимосвязей между блоками SADT диаграммы Выход – Механизм отражает ситуацию, при которой:

-: один из блоков должен полностью завершить работу, перед началом работы другого блока и Выход становится Входом для блока с меньшим доминированием

-: Выход одного блока непосредственно влияет на блок с меньшим доминированием

-: Выход некоторого блока влияет на блок с большим доминированием

+: Выход одной функции становится средством достижения цели другой функции

-: Выход одного блока становится Входом другого с большим доминированием

26. Миниспецификации обработки, описывающие DFD-процессы:

-: обеспечивают аналитика средствами описания деталей компонентов DFD, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ

-: позволяет формально описать расщепление/объединение потоков

-: представляют собой алгоритмы описания задач, выполняемых процессами

+: используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD

27. Назначение диаграммы переходов состояний (STD)-:

Читайте также:  Что кушать чтобы у ребенка было хорошее зрение

-: документировать механизмы передачи и обработки информации в моделируемой системе

+: моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования

-: описывать информационные потоки между моделируемой областью и внешними объектами

28. SADT модель может основываться на:

+: входных данных системы

+: выходных данных системы

29. Сущность представляет собой множество:

-: отношений между хранилищами данных

-: потоков данных и потоков управления

+: экземпляров реальных или абстрактных объектов, обладающих общими атрибутами или характеристиками

30. Информационную модель системы (ERD) можно описать с помощью следующих терминов:

-: отношение, состояние, переход, поток данных

-: поток данных, хранилище данных, процесс, внешняя сущность

+: отношение, связь, сущность, атрибут

-: категория, условие, действие

-: атрибут, состояние, связь

31. Идентифицирующая связь в диаграммах ERD:

-: связь, при которой экземпляр дочерней сущности не идентифицируется через свою ассоциацию с родительской сущностью

+: связь, при которой экземпляр дочерней сущности идентифицируется через свою ассоциацию с родительской сущностью

-: служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней

32. Упорядочите приведенные этапы создания функциональных диаграмм процесса Моделирования:

1: выбор цели о точки зрения

2: составление списка данных

3: составление списка функций

4: построение и обобщение диаграммы А0(А0 – А-0)

5: декомпозиция ограниченного объекта

7: итерационный процесс рецензирования

8: завершение моделирования

33. Нотация — :

-: техника генерации описаний компонентов ИС

-: правила использования методов, с помощью которых разрабатывается проект ИС

-: описание проекта системы на формальных и естественных языках

-: специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС

+: отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм

34. Дайте определение понятию «Основные бизнес-процессы»

+: процессы, ориентированные на производство товаров и услуг

-: процессы, обеспечивающие получение дохода

-: процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и бизнес-системы в целом

35. Какая модель отвечает на вопросы кто-что-как-кому?

-: стратегическая модель целеполагания

-: модель структуры данных

36. Какие модели описывают процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес — функции или функции менеджмента?

+: процессные потоковые модели

-: модели структур данных

37. Какая модель отражает представление о новых технологиях работы организации?

-: модель «как есть»

+: модели «как должно быть»

38. Какие основные понятия используются при создании функциональной диаграммы IDEF0?

-: внешние источники и получатели данных

-: хранилища, требуемые процессами для своих операций

39. Какие стрелки называются граничными? Стрелки, которые:

-: служат для описания взаимодействия с окружающим миром

+: начинаются у границы и заканчиваются у работы

+: начинаются у работы и заканчиваются у границы

-: начинаются у границы и заканчиваются у границы

40. Укажите, с какой целью строятся диаграммы для экспозиции (FEO)?

+: для иллюстрации отдельных фрагментов модели

+: для иллюстрации альтернативной точки зрения

+: для иллюстрации специальных целей

-: для иллюстрации взаимосвязи между работами

41. Укажите, что входит в определение контекста модели&

+: определение субъекта моделирования

+: определение цели моделирования

+: определение точки зрения

-: определение количества уровней декомпозиции

42. Диаграмму потоков данных (DFD) можно описать с помощью следующих терминов:

-: состояние, хранилище данных, связь, действие

-: хранилище данных, поток, процесс, атрибут, условие

+: сущность, поток, процесс, накопитель данных

-: отношение, категория, функция, переход

43. Какой вариант правильно описывает цифрами последовательность этапов АВС-анализа?

1. Определение затрат на выполнение бизнес — задач (расходы ресурсов, – прямые затраты материалов и труда, косвенные затраты труда и накладные расходы)

2. Формирование перечня ресурсов и стоимостных объектов («центров затрат»)

studopedia.org — Студопедия.Орг — 2014-2019 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.005 с) .

Точка зрения (Viewpoint).

Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 7.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

Рис. 7.3.Диалог задания свойств модели

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 7.4).

Рис. 7.4.Диалоговое окно для формирования отчета по модели

На рис. 7.5 представлен отчет, сформированный по вышеуказанным полям.

Рис. 7.5.Предварительный просмотр отчета

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

Модель может содержать четыре типа диаграмм:

· контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма );

· диаграммы дерева узлов ;

· диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.

Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.

Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Деятельность компании», «Прием заказа» и т.д.). Работа «Деятельность компании» может иметь, например, следующее определение: «Это учебная модель, описывающая деятельность компании». При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 7.6).

Рис. 7.6.Пример контекстной диаграммы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. 7.7).

Рис. 7.7.Редактор задания свойств работы

Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке

на панели инструментов.

Возникает диалог Activity Box Count (рис. 7.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 7.9). Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис. 7.8.Диалог Activity Box Count

Рис. 7.9.Пример диаграммы декомпозиции

Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.

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

Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже).

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 7.9 все работы еще не были декомпозированы.

Читайте также:  Можно ли сделать коррекцию зрения при дальнозоркости

Стрелки (Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными. (Например, «Звонки клиентов», «Правила и процедуры», «Бухгалтерская система».)

В IDEF0 различают пять типов стрелок:

Вход (Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, «Звонки клиентов» на рис. 7.6 — это нечто, что перерабатывается в процессе «Деятельность компании» для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при «Приеме пациента» карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — «Заполненная карта пациента»). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет — управление.

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 7.6 стрелка «Правила и процедуры» — управление для работы «Деятельность компании». Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 7.6 стрелки «Маркетинговые материалы» и «Проданные продукты» являются выходом для работы «Деятельность компании».

Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 7.6 стрелка «Бухгалтерская система» является механизмом для работы «Деятельность компании». По усмотрению аналитика стрелки механизма могут не изображаться в модели.

Вызов (Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. 7.10 стрелка «Другая модель работы » является вызовом для работы «Изготовление изделия». Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

Рис. 7.10.Стрелка вызова, появляющаяся при расщеплении модели

Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.

Для внесения граничной стрелки входа следует:

· щелкнуть по кнопке с символом стрелки ;

· в палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

· щелкнуть один раз по полоске (откуда выходит стрелка ) и еще раз в левой части работы со стороны входа (где заканчивается стрелка );

· вернуться в палитру инструментов и выбрать опцию редактирования стрелки ;

· щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

Стрелки управления, входа, механизма и выхода изображаются аналогично. Имена вновь внесенных стрелок (рис. 7.11) автоматически заносятся в словарь Arrow Dictionary.

Рис. 7.11.Диалог IDEF0 Arrow Properties

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 — это не элемент управления нижестоящими работами. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties) (рис.7.12).

Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий (рис. 7.13). Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т. е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик — автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.

Рис. 7.12.Включение опции ICOM codes на закладке Display

Рис. 7.13.Редактирование словаря стрелок

Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/ Report /Arrow Report. ) и получить толковый словарь терминов предметной области, использующихся в модели.

Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

На рис. 7.14 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы «Сборка настольных компьютеров» (см. рис. 7.9). Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и потом по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.

Рис. 7.14.Пример несвязанных стрелок

Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.

Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ.

Связь по входу ( output-input ), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей (например, на рис. 7.15 стрелка «Собранные компьютеры» связывает работы «Сборка и тестирование компьютеров» и «Отгрузка и получение» ).

Рис. 7.15.Связь по входу

Связь по управлению ( output-control ), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. 7.16 стрелка «Заказы клиентов» связывает работы «Продажи и маркетинг» и «Сборка и тестирование компьютеров».

Рис. 7.16.Связь по управлению

Обратная связь по входу ( output-input feedback ), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 7.17 стрелка «Результаты тестирования» связывает работы «Тестирование компьютеров» и «Отслеживание расписания и управление сборкой и тестированием».

Рис. 7.17.Обратная связь по входу

Обратная связь по управлению ( output-control feedback ), когда выход нижестоящей работы направляется на управление вышестоящей ( стрелка «Результаты сборки и тестирования», рис. 7.18). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. На рис. 7.18 объем продаж может быть повышен путем непосредственного регулирования процессов сборки и тестирования компьютеров (выхода) работы «Сборки и тестирование компьютеров».

Рис. 7.18.Обратная связь по управлению

Связь выход-механизм ( output-mechanism ), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. 7.19).

Рис. 7.19.Связь выход-механизм

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. 7.20).

Рис. 7.20.Пример именования разветвляющейся стрелки

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. 7.21).

Рис. 7.21.Пример именования разветвляющейся стрелки

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

Правила именования сливающихся стрелок полностью аналогичны — ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.

Читайте также:  Как восстановить зрение после операции на голове

Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. 7.22).

Рис. 7.22.Неразрешенная (unresolved) стрелка

Для их «перетаскивания» наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel (рис. 7.23).

Рис. 7.23.Выбор команды из контекстного меню

Появляется диалог Border Arrow Editor (рис. 7.24).

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel — стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце (рис. 7.25).

Рис. 7.24.Диалог Border Arrow Editor

Рис. 7.25.Типы туннелирования стрелок

Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется «не-в-родительской-диаграмме».

Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется «не-в-дочерней-работе» (рис. 7.25).

Нумерация работ и диаграмм. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. из диаграммы можно получить декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер — C-number, который должен присваиваться автором модели вручную. C-number — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

| следующая лекция ==>
Построение модели IDEF0 | Диаграммы дерева узлов и FEO

Дата добавления: 2017-09-19 ; просмотров: 260 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Моделирование бизнес-процессов средствами BPwin

Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology ), Silverrun (Silverrun technology ), Oracle Designer ( Oracle ), Rational Rose (Rational Software ) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.

BPwin поддерживает три методологии моделирования: функциональное моделирование ( IDEF0 ); описание бизнес-процессов ( >диаграммы потоков данных ( DFD ).

Инструментальная среда BPwin

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов , палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer (рис. 7.1).

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. 7.2).

Как было указано выше, BPwin поддерживает три методологии — IDEF0 , >DFD , каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0 , так и >DFD . Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Модель в BPwin рассматривается как совокупность работ , каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню , каждый пункт которого соответствует редактору какого-либо свойства объекта.

Построение модели >На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.

Наиболее удобным языком моделирования бизнес-процессов является IDEF0 , где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.

Цель моделирования

Цель моделирования определяется из ответов на следующие вопросы:

  • Почему этот процесс должен быть смоделирован?
  • Что должна показывать модель?
  • Что может получить клиент?

Точка зрения (Viewpoint).

Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.

IDEF0 -модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 7.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.

Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 7.4).

На рис. 7.5 представлен отчет, сформированный по вышеуказанным полям.

Источники:
  • http://studfiles.net/preview/5316981/
  • http://studopedia.org/8-114420.html
  • http://helpiks.org/9-29822.html
  • http://www.intuit.ru/studies/courses/2195/55/lecture/1630