Часть III. Функциональное моделирование

Содержание

26. 8. Основные понятия IDEF0

27. 8.1. Назначение

28. 8.2. Концепция

29. 8.3. Компоненты языка

30. 8.4. Имена и метки

31. 8.5. Блоки и стрелки

32. 8.6. Диаграммы

33. 8.6.1. Типы диаграмм

34. 8.6.2. Контекстная диаграмма

35. 8.6.3. Дочерняя и родительская диаграммы

36. 8.6.4. Текст и глоссарий

37. 8.6.5. Диаграммы иллюстраций и дерева узлов

38. 8.7. Свойства диаграмм

39. 8.7.1. Стрелки-условия

40. 8.7.2. Параллельное функционирование

41. 8.7.3. Связи блоков на диаграмме

42. 8.8. Правила построения диаграмм

43. 8.9. Классификация функций

44. 8.10. Управление

45. 8.11. Типизация функциональных моделей

46. 8.12. Горячие слова

47. 9. Лабораторная работа "Создание модели деятельности компании по производству пельменей"

48. 9.1. Пользовательский интерфейс BPwin

49. 9.1.1. Model Explorer

50. 9.1.2. Стандартная панель инструментов

51. 9.1.3. Палитра инструментов

52. 9.2. Построение моделей IDEF0

53. 9.3. Модели «как есть» и «как будет»

54. 9.4. Описание деятельности компании

55. 9.5. Создание контекстной диаграммы

56. 9.5.1. Контекст

57. 9.5.2. Блок

58. 9.5.3. Граничные стрелки

59. 9.6. Создание диаграммы декомпозиции

60. 9.6.1. Декомпозиция

61. 9.6.2. Связывание

62. 9.6.3. Разветвление

63. 9.6.4. Внутренние стрелки

64. 9.6.5. Словарь стрелок

65. 9.6.6. Тоннель

66. 9.7. Создание диаграммы декомпозиции А2

67. 9.8. Синтаксический контроль

68. 9.9. Создание диаграммы дерева узлов

69. 9.9.1. Создание диаграммы иллюстрации

70. 10. Лабораторная работа "Дополнение модели диаграммой IDEF3"

71. 10.1. Назначение

72. 10.2. Основные понятия

73. 10.2.1. Единица работы

74. 10.2.2. Связи

75. 10.2.3. Перекрестки

76. 10.2.4. Правила создания перекрестков

77. 10.2.5. Объект ссылок

78. 10.2.6. Горячие слова

79. 10.2.7. Декомпозиция блока IDEF0 в диаграмму IDEF3

80. 11. Лабораторная работа "Функционально-стоимостный анализ функции"

81. 11.1. Основные понятия ФСА

82. 11.2. Определение стоимости функции

83. 12. Лабораторная работа "Реинжиниринг бизнес-процессов компании по производству пельменей"

84. 12.1. Расщепление модели

85. 12.2. Слияние моделей

86. 12.3. План реинжиниринга

87. 12.4. Расщепление и модификация модели

88. 12.5. Слияние моделей

89. 12.6. Перенос блока

90. 12.6.1. Модификация IDEF3

91. 13. Лабораторная работа "Дополнение модели диаграммой DFD"

92. 13.1. Назначение

93. 13.2. Основные понятия

94. 13.2.1. Процесс

95. 13.2.2. Поток данных

96. 13.2.3. Хранилище данных

97. 13.2.4. Внешняя сущность

98. 13.3. Построение диаграммы DFD

99. 13.4. Горячие слова

100. 13.5. Декомпозиция блока

101. 13.6. Декомпозиция блока IDEF0 в диаграмму DFD

102. 13.7. Создание межстраничной ссылки

103. 13.8. Литература

104. 14. Контрольные вопросы

105. 14.1. Контрольные вопросы по функциональному моделированию

106.

Глава 8. Основные понятия IDEF0

Содержание

109. 8.1. Назначение

110. 8.2. Концепция

111. 8.3. Компоненты языка

112. 8.4. Имена и метки

113. 8.5. Блоки и стрелки

114. 8.6. Диаграммы

115. 8.6.1. Типы диаграмм

116. 8.6.2. Контекстная диаграмма

117. 8.6.3. Дочерняя и родительская диаграммы

118. 8.6.4. Текст и глоссарий

119. 8.6.5. Диаграммы иллюстраций и дерева узлов

120. 8.7. Свойства диаграмм

121. 8.7.1. Стрелки-условия

122. 8.7.2. Параллельное функционирование

123. 8.7.3. Связи блоков на диаграмме

124. 8.8. Правила построения диаграмм

125. 8.9. Классификация функций

126. 8.10. Управление

127. 8.11. Типизация функциональных моделей

128. 8.12. Горячие слова

129. В этой главе использовано учебное пособие Моделирование бизнес-процессов с помощью CASE-средства BPwin за 7 дней..

130. Грамматика не предписывает законов языку, но изъясняет и утверждает его обычаи.

131. А.С. Пушкин. Заметки и афоризмы разных годов

Назначение

133. Постоянное усложнение производственно-технических и организационно-экономических систем - фирм, предприятий и других субъектов производственно-хозяйств енной деятельности, а также необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливает необходимость наличия специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность с связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий [1].

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

135. Общая методология IDEF включает частные методологии, основанные на графическом представлении систем: IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3 и др. Подробные спецификации на эти стандарты можно найти на сайте http://www.idef.com.

136. Методология IDEF0 основана на подходе, разработанном Дугласом Россом в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, - метод структурного анализа и проектирования) [3]. Основу подхода и, как следствие, методологии IDEF0 составляет графический язык моделирования систем, обладающий следующими свойствами:

137. (1) Графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации.

138. (2) Язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания.

139. (3) Язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (предприятия).

140. (4) Язык может генерироваться рядом CASE-средств, например, BPwin (компания Computer Associates, http://www.ca.com), AI0 WIN (компания KBSI, http://www.idef.com).

141. Эти свойства предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в принятии методологии в качестве федерального стандарта США [2]. В 2000 г. методология IDEF0 была принята в качестве стандарта в Российской Федерации [1].

142.

Концепция

Методология IDEF0 основана на следующих концептуальных положениях [1].

Модель - искусственный объект, представляющий собой отображение системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А (М - модель, А - моделируемый объект). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или проектировании новой системы.

Система представляет собой совокупность взаимосвязанных и взаимодействующих элементов, выполняющих некоторую полезную работу. Элементами системы могут быть любые комбинации разнообразных сущностей, включающих людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергоносители. Модель описывает: (1) что происходит в системе, (2) как ею управляют, (3) какие сущности она преобразует, (4) какие средства использует для выполнения своих функций и (5) что производит.

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

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

Итеративное моделирование. Разработка модели в IDEF0 представляет собой итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению и последующему редактированию, после чего цикл повторяется.

Отделение «организации» от «функций». При разработке моделей следует избегать изначальной привязки функций исследуемой системы к существующей организационной структуре моделируемого объекта. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет: (1) оценить адекватность модели, (2) предложить решения, направленные на совершенствование этой структуры.

Компоненты языка

Компоненты синтаксиса языка IDEF0 - блоки, стрелки, диаграммы, правила [1].

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

Пример блока показан на рисунке 1. Внутри блока помещается его имя Почистить картофель и номер 1.

Рис. 1. Блок

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

Рис. 2. Стрелки

Имена и метки

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

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

Блоки и стрелки

Каждая сторона блока имеет своё определенное значение с точки зрения связи блок-стрелка. Верхняя сторона имеет значение «управление», левая - «вход», правая - «выход», а нижняя - «механизм». В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль.

В IDEF0 различают пять классов стрелок - (1) стрелка входа, (2) стрелка выхода, (3) стрелка управления, (4) стрелка механизма, (5) стрелка вызова.

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

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

Стрелка выхода - это данные или материальные объекты, произведенные функцией. Стрелка выхода рисуется как выходящая из правой грани блока. Каждая функция должна иметь хотя бы одну стрелку выхода. Функция без выхода не имеет смысла и не должна моделироваться.

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

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

Стандартное расположение стрелок показано на рис. 3.

Рис. 3. Расположение стрелок блока

Диаграммы

Типы диаграмм

IDEF0-модели состоят из трех типов документов: (1) графических диаграмм, (2) текста, (3) глоссария. Эти документы имеют перекрестные ссылки друг на друга [1].

Графическая диаграмма - главный компонент модели, содержащий блоки, стрелки, соединения блоков и стрелок. Диаграмма является единицей описания системы и располагается на отдельном листе.

Блоки представляют основные функции моделируемого объекта. Эти функции могут быть декомпозированы на составные части и представлены в виде более подробных диаграмм. Процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

Модель может содержать следующие типы графических диаграмм: (1) контекстная, (2) декомпозиции, (3) дерева узлов, (4) иллюстрации.

Контекстная диаграмма

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Пример такой диаграммы показан на рис. А.

Диаграмма А-0 устанавливает область моделирования и ее границу. Необходимо установить, что входит в систему, а что лежит за ее пределами, то есть определить, что будет рассматриваться как компоненты системы, а что - как внешнее воздействие.

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

Цель - это краткая формулировка причины создания модели. Цель должна отвечать на вопросы: почему этот процесс должен быть смоделирован? что должна показать модель? что может получить читатель? Примером цели может быть следующее утверждение: «Определить роли и ответственность служащих для написания должностных инструкций».

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