Правительство Российской Федерации

Государственное образовательное бюджетное учреждение

высшего профессионального образования

«Национальный исследовательский университет Высшая школа экономики»

Факультет бизнес-информатики

Практическое задание №2

По предмету «Архитектура предприятия»

Синтаксис и семантика IDEF0, IDEF3 и DFD-диаграмм

Выполнил:

Студент группы №371

Фоос П. Ю.

Проверила:

Гончарова Д.А.

Москва 2013

Оглавление

Введение. 2

Этапы проектирования функциональной модели. 3

Сравнение структурного и процессного подходов управления деятельностью предприятия. 5

Методология структурного моделирования. 6

Синтаксис и семантика моделей DFD. 8

Пример. 11

Функциональные диаграммы. 12

Синтаксис и семантика моделей IDEF0. 14

Пример. 17

Методология IDEF3. 18

Синтаксис и семантика. 19

Пример. 21

Список литературы. 23

Введение.

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

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

В настоящее время двумя наиболее популярными методологиями построения функциональных моделей являются IDEF0 и DFD, и

IDEF0 — Function Modeling — методология функционального моделирования, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временная последовательность. В DFD (диаграмма потоков данных) же показывают, как объекты (включая и данные) реально перемещаются от одного действия к другому [1].

Именно эти модели будут подробно рассмотрены в данном реферате.

Этапы проектирования функциональной модели.

Рис. 1. Схема построения функциональной модели.

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

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

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

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

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

Рис. 2. Фрагмент матрицы РАЗУ.

Эта матрица представляет собой таблицу, в подлежащем которой располагаются наименования подразделений и служб (работники аппарата управления могут быть указаны конкретно), а в сказуемом перечисляются задачи, выполняемые этими исполнителями. Условным знаком обозначается отношение каждого подразделения, службы или конкретного работника к решению определенной задачи [2].

Сравнение структурного и процессного подходов управления деятельностью предприятия.

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

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

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

• отсутствие цельного описания технологий выполнения работы, в лучшем случае существует только фрагментарная (на уровне структурных элементов), и то не совсем актуальная документируемость технологий;

• отсутствие ориентации на внешнего клиента, а также внутренних потребителей промежуточных результатов деятельности;

• высокие накладные расходы, как правило, непонятно откуда появляющиеся;

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

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

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

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

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

Методология структурного моделирования.

Нотация диаграмм потоков данных (Data Flow Diagram, DFD) позволяет отображать как шаги бизнес-процесса, так и поток документов и управления (в основном управления, поскольку на верхнем уровне описания процессных областей значение имеет передача управления). Также на диаграмме можно отображать средства автоматизации шагов бизнес-процессов. Обычно используется для отображения третьего и ниже уровня декомпозиции бизнес-процессов (первый уровень — перечень бизнес-процессов (IDEF0), а второй — функции, выполняемые в рамках бизнес-процессов (IDEF3)).

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

–– моделирование функциональных требований к проектируемой системе;

–– моделирование существующего процесса движения информации;

–– описание документооборота, обработки информации;

–– дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота;

––проведение анализа и определения основных направлений реинжиниринга информационной системы.

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

Методология DFD (Data Flow Diagram) удобна для описания не только бизнес-процессов (как дополнение к IDEF0), но и программных систем:

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

––наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершённость IDEF0 (моделирование обрывается на некотором достаточно низком уровне, когда дальнейшая детализация модели становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.

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

На схемах бизнес-процесса отображаются:

–– функции процесса;

–– входящая и исходящая информация при описании документов;

–– внешние бизнес-процессы, описанные на других диаграммах;

–– точки разрыва при переходе процесса на другие страницы.

При моделировании DFD система рассматривается как сеть связанных между собой функций, т. е. как совокупность сущностей. Методология основана на идее нисходящей иерархической организации. Целью является преобразование общих, неясных знаний о требованиях к системе в точные определения. Внимание фокусируется на потоках данных.

Варианты методологии DFD.

Существует два основных варианта методологии DFD: методология Гейна–Сарсона и методология Йордана–Де Марко.

Главной отличительной чертой методологии Гейна-Сарсона является наличие этапа моделирования данных, определяющего содержимое хранилищ данных (БД и файлов) в DFD. Этот этап включает построение списка элементов данных, располагающихся в каждом хранилище данных; анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных; представление всей информации по модели в виде связанных нормализованных таблиц.

Кроме того, эти методологии отличаются нотацией.

Обе методологии основаны на простой концепции нисходящего поэтапного разбиения функций системы на подфункции:

1) формирование контекстной диаграммы верхнего уровня, идентифицирующей границы системы и определяющей интерфейсы между системой и окружением;

2) формирование списка внешних событий, на которые система должна реагировать (после интервьюирования эксперта предметной области), для каждого из которых строится пустой процесс (Bubble) в предположении, что его функция обеспечивает требуемую реакцию на это событие (в большинстве случаев включает генерацию выходных потоков и событий);

3) проведение детализации для каждого из пустых процессов.