IDEF0 диаграммы строятся с помощью программы BPWin. Предназначены они для графического моделирования происходящих бизнес-процессов

О методологии IDEF0

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

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

Элементы, используемые для IDEF0

Как уже упоминалось, используется 2 типа геометрических примитивов: прямоугольники и стрелки. Прямоугольники обозначают определённые процессы, функции, работы или задачи, что имеют цели и ведут к обозначенному результату. Взаимодействие процессов между собой и внешней средой обозначается с помощью стрелок. В IDEF0 различают 5 различных типов стрелок.

Возможности использования IDEF0

Методологию IDEF0 можно применять для описи функционального аспекта любой информационной системы.

Типы связей между процессами IDEF0

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

1. Иерархическая («часть» - «целое») связь.

2. Управляющая (регламентирующая, подчинённая):

2) обратная связь управления.

3. Функциональная или технологическая:

2) обратная входная.

3) потребительская;

4) логическая;

5) методическая или коллегиальная;

6) ресурсная;

7) информационная;

8) временная;

9) случайная.

Построение блоков и связей в диаграммах

Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной.

Построение блоков в диаграммах декомпозиции

Количество блоков, которое будет на одной диаграмме, рекомендовано в численности 3-6. Если их меньше, то такие диаграммы вряд ли будут нести смысловую нагрузку. Если количество блоков будет огромным, то прочитать такую диаграмму будет весьма сложно, учитывая наличие ещё и дополнительных стрелок. Для улучшения восприятия информации размещать блоки рекомендуется сверху вниз и слева направо. Такое расположение позволит отразить логику исполнения последовательности процессов. А также стрелки будут создавать меньшую путаницу, обладая минимальным количеством пересечений друг с другом.

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

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

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

Именование

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

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

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

Информация о стрелках

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

Пример реализации методологии IDEF0 на конкретной модели

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

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

Исходной информацией выступают:

1. данные про линию путей;
2. паспорт всей дистанции;
3. план пути.

Управляющие данные:

1. Указание начальника, заведующего службой путей.
2. Сведения о существующем потоке передвижения составов.
3. Сведения о запланированных ремонтах, реконструкциях и изменении путей.

Результатом модели является:

1. Ограничение допустимых скоростей с указанием причины ограничения.
2. Допустимые скорости при движении на раздельных пунктах и во время перегона составов.

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

Заключение

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

Методология IDEF0

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

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.1 Типы стрелок

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

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

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

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

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

Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.

Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.

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

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

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

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

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

непомеченные ветви содержат вес объекты, указанные в метке дуги перед разветвлением;

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

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

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

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

помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,

количество блоков на диаграмме - N;

уровень декомпозиции диаграммы - L ;

сбалансированность диаграммы - В;

число стрелок, соединяющихся с блоком, - А

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

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

Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 2.7: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка -- готовое изделие.

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.

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

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

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

Рис.2.8 Диалог создания модели

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

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

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

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

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

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

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

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Рис 2.9. Контекстная диаграмма системы

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

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

Выбор подсистемы.

Обращение к подсистеме.

Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

Рис. 2.11. Декомпозиция работы «Определение уровня доступа в систему»

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

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

Открытие БД.

Выполнение запроса.

Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

Необходимо отметить, что в «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. На этапе выполнения запроса может потребоваться изменение содержимого БД, например при составлении экспертных оценок. Поэтому, на диаграмме необходимо предусмотреть такую возможность.

Рис. 2.12.

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.

Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).

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

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

БД пользователей,

БД студентов,(вариант 2)

БД вакансий,

БД успеваемости,

БД тестов,

БД экспертных оценок,

БД резюме.

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

Определяется БД, в которой будет изменяться информация.

Оператором формируется временный набор данных и предоставляется администратору.

Администратор осуществляет контроль данных и вносит их в БД.

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

Рис. 2.16. Декомпозиция работы «Изменение БД»

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного на рис. 2.12

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

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента К b у двух вариантов моделей.

для второго варианта

Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

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

IDEF0 - нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

использование контекстной диаграммы;

поддержка декомпозиции;

доминирование;

выделение 4 типов стрелок.

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

Рисунок 1. Диаграмма A-0 в нотации IDEF0

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

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

Выделение 4 типов стрелок. Выделяются следующие типы стрелок: "Вход", "Выход", "Механизм", "Управление". Входы преобразуются или расходуются процессом, чтобы создать то, что появится на его выходе. Управления определяют условия, необходимые процессу, чтобы произвести правильный выход. Выходы - данные или материальные объекты, произведенные процессом. Механизмы идентифицируют средства, поддерживающие выполнение процесса. Таким образом, блок IDEF0 показывает преобразование входа в выход с помощью механизмов с учетом управляющих воздействий.

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

Название	Графический символ	Описание
		Процесс обозначается прямоугольным блоком. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
		Стрелки обозначают входящие и исходящие из процесса объекты (данные). Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Стрелки, входящие в блок сверху - управления. Стрелки, покидающие процесс справа - выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Туннелированная стрелка		Туннелированные стрелки означают, что данные, передаваемые с помощью этих стрелок, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме. Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции. Стрелка, помещаемая в туннель на свободном конце, означает, что выраженные ею данные отсутствуют на родительской диаграмме. Туннелированные стрелки могут быть использованы на диаграммах процессов в нотациях IDEF0, "Процесс", "Процедура".
		Элемент обозначает место, сущность или субъект, которые находятся за границами моделируемой системы. Внешние ссылки используются для обозначения источника или приемника стрелки вне модели. На диаграммах внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки. Внешние ссылки могут быть использованы на диаграммах процессов в любых нотациях.
		Элемент, обозначающий другую диаграмму. Междиаграммная ссылка служит для обозначения перехода стрелки на диаграмму другого процесса без отображения стрелки на вышележащей диаграмме (при использовании иерархических моделей). В качестве междиаграммной ссылки не может выступать диаграмма процесса в нотациях EPC и BPMN. Междиаграммные ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, "Процесс", "Процедура".
		Элемент обозначает ссылку на типовую модель процесса. Наиболее часто повторяющиеся процессы в рамках модели бизнес-процессов могут быть выделены в качестве типовых в отдельную папку в Навигаторе . Диаграмма типового процесса формируется один раз в одном месте Навигатора . Далее на любой диаграмме может быть использован процесс-ссылка на типовой процесс. Параметры типового процесса заполняются непосредственно в Окне свойств типового процесса. Постоянный список субъектов, принимающих участие в выполнении типового процесса, формируется также в Окне свойств типового процесса. Список субъектов, принимающих участие при выполнении типового процесса в рамках вышележащего процесса, формируется в Окне свойств процесса-ссылки на типовой процесс. Процессы-ссылки могут быть использованы на диаграммах процессов в любых нотациях.
		Выносной элемент, предназначенный для нанесения комментариев. Элемент может быть использован на диаграммах процессов в любых нотациях.

IDEF0 Diagrams Software - Create IDEF0 diagrams and business diagrams rapidly with rich examples and templates. Provide some IDEF0 knowledge.

IDEF Definition

IDEF is based on the Structured Analysis and Design Technique (SADT), a graphical approach to system description, introduced by Douglas T. Ross in the early 1970s. Since then, system analysts at Softech, Inc. have refined and used SADT in a wide variety of problems. In 1981, the U.S. Air Force Program for Integrated Computer-Aided Manufacturing (ICAM) standardized and made public a subset of SADT, called IDEF.

Was originally used to apply structured methods to better understand how to improve manufacturing productivity. IDEF0 was initially created at Northrop Corporation in 1966, and first available commercially by SofTek in 1972. An IDEF0 activity diagram contains one level of decomposition of a process. Boxes within a diagram show the subprocesses of the parent process named by the diagram. Arrows between the boxes show the flow of products between processes.

Innovative IDEF0 Software

Edraw Max is an easy to use IDEF0 diagrams software, which creates IDEF0 diagrams and business diagrams rapidly with rich examples and templates.

Build hierarchical diagrams using IEDF0 process charting models for model configuration management, need and benefit analyses, requirements definitions, and continuous improvement models.

System Requirements

Works on Windows 7, 8, 10, XP, Vista and Citrix

Works on 32 and 64 bit Windows

Works on Mac OS X 10.2 or later

Software Features

Edraw is:

1. state of the art
2. vector-based
3. more than just IDEF0, IDEF1, IDEF2 Diagrams which can make over 200 kinds of diagrams
4. easy to use with drag and drop interface, premade symbols and automatic formatting tools
5. accompanied by a plethora of well-designed templates and examples
6. designed with broad file format compatibility

IDEF0 diagrams typically include the following components:

Context diagram - The topmost diagram in an IDEF0 model.

Parent/child diagram - An IDEF0 decomposition hierarchy using parent/child relationships.

Node trees - Tree-like structures of nodes rooted at a chosen node, and used to represent a full IDEF0 decomposition in a single diagram.

The Benefits of Using IDEF0 to Model Business Processes

1. Understanding - modeling helps discover the nature of the business being modeled; that is, what is being done in the business.
2. Communication - once understanding has been reached, the nature of the business processes can be documented and these documents easily communicated.
3. Enlightenment - modeling helps to uncover anomalies, redundancies deficiencies and inefficiencies in the existing (as-is) business process.
4. Improvement - a model allows you to select deficient areas of the business and its processes and improve them.
5. Redesign - a model provides a tangible basis for redesigning the process, performing simulations of the redesigned (to-be) business process as defined by the strategy. This means that strategies can be tested before implementation takes place.

The IDEF0 Modeling Techniques

An IDEF0 model represents the activities of the business from the point of view of the business, how those business activities interrelate, resources used to conduct each activity, and the result or output of each activity. The model consists of graphics and associated text supporting the graphics.

The IDEF0 modeling technique consists of a graphic language and a modeling process that can be used to develop a rich process description. It is an intuitive way to define, analyze and document the business as a whole and the processes of the business.

Размещено на http://www.allbest.ru/

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

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

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

Главной целью курсовой работы является разработка информационной системы для учета компьютерной техники предприятия, с использованием методологии функционального моделирования и графической нотации IDEF0, диаграмм потоков данных DFD и стандарта документирования процессов IDEF3, посредством программного продукта Computer Associates AllFusion Process Modeler r7.3. 2

2.1 Анализ программных продуктов 8

ВВЕДЕНИЕ

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

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

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

Главной целью курсовой работы является разработка информационной системы для учета компьютерной техники предприятия, с использованием методологии функционального моделирования и графической нотации IDEF0, диаграмм потоков данных DFD и стандарта документирования процессов IDEF3, посредством программного продукта Computer Associates AllFusion Process Modeler r7.3.

Для достижения этой цели необходимо решить следующие задачи:

Анализ программных продуктов;

Изучение методов проектирования информационных систем;

Функциональное моделирование контекстной диаграммы и диаграмм декомпозиций бизнес – процесса (IDEF0) «Учет компьютерной техники предприятия»;

Проектирование информационной системы с использованием диаграмм потоков данных (DFD);

Использование методологии моделирования и стандарта документирования процессов IDEF3.

информационный поликлиника документирование программный

1. МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

В современной практике моделирования управленческой и производственной деятельности для обозначения объектов моделирования принято использовать термин «бизнес – процесс». При моделировании бизнес – процессов следует уделить внимание ряду факторов:

Корректная постановка целей;

Грамотная информированность персонала организации относительно целей и результатов проекта;

Эффективное применение инструментов моделирования;

Наличие корпоративных стандартов описания и регламентации бизнес – процессов.

Для моделирования бизнес - процессов используется несколько различных методов. Их основой являются как структурный, так и объектно-ориентированный подходы к моделированию. Наиболее развитые методы используют элементы обоих подходов. К числу наиболее распространенных методов можно отнести:

метод функционального моделирования SADT (IDEF0);

метод моделирования процессов IDEF3;

моделирование потоков данных DFD;

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

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

Метод функционального моделирования IDEF0(Function Modeling) – совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой – либо предметной области. Функциональная модель объекта отображает производимые им действия и связи между ними.

В соответствии с этим методом бизнес – модель должна выглядеть следующим образом:

Верхний уровень модели должен отражать только контекст системы, то есть её взаимодействие с внешним миром.

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

Дальнейшая детализация бизнес – процессов осуществляется посредством бизнес – функций, то есть совокупностей операций, сгруппированных по определенным признакам.

Описание элементарной бизнес – операций осуществляется с помощью задания алгоритма ее выполнения.

Метод моделирования потоков данных DFD (Data Flow Diagrams)- диаграммы потоков данных. Основное средство моделирования функциональных требований к проектируемой системе.

Компоненты модели: диаграммы; словарь данных; спецификации процессов.

Элементы диаграмм: поток данных; хранилище; внешняя сущность.

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

Внешняя сущность-объект\субъект вне контекста системы, который является.

Хранилище – срез потоков данных во времени, содержащий данные, которые нужно сохранить между процессами.

Основные преимущества:

возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

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

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

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

существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического преобразования иерархии DFD в структурные карты, демонстрирующие межсистемные, внутрисистемные связи и иерархию систем

Недостатки:

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

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

Метод моделирования процессов IDEF3 (Integrated DEFinition for Process Description Capture Method) – методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.

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

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

2. Проектирование информационной системы «учет компьютерной техники предприятия»

2.1 Анализ программных продуктов

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

Программное обеспеченье IT Invent (it-invent.ru)

Программное обеспеченье Hardware Inspector (hwinspector.com)

Конфигурация 1С:Учёт компьютеров и оборудования 8.1 (odineskin.ru)

Первая ИС, IT Invent, это не только учет компьютеров, принтеров, программ и комплектующих. Это так же учет ремонтов и обслуживаний, работ по поддержке техники, заказов поставщикам, поступлений и перемещений оборудования, учет контрагентов, сотрудников и многое другое. Основная форма программы IT Invent показана на рисунке 1.

Рисунок 1 «IT Invent»

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

Поддержка базы данных MS Access и MS SQL Server.

Многопользовательский режим работы - все филиалы работают с единой базой.

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

Учет выполнения работ любых видов внутри организации.

Уникальная система создания и печати инвентарных этикеток. Поддержка принтеров штрих-кодов.

Поддержка работы со сканером штрих-кодов. Поиск записей в базе по штрих-коду.

Ведение истории изменений по оборудованию.

Учет ремонтов и профилактических обслуживаний оборудования и компьютеров.

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

Учет расходных материалов, комплектующих запчастей и канцелярии.

Закрепление учетных единиц за сотрудниками организации. Акты приёма-передачи.

Ведение базы поставщиков, сервисных организаций и прочих контрагентов.

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

Настройка E-Mail оповещений по событиям в программе.

Большое количество встроенных печатных форм и отчетов с возможностью их редактирования.

Импорт и просмотр данных напрямую из Active Directory.

Программа IT Invent является сетевой. Для работы по сети с единой базой данных, необходимо у каждого пользователя программы в файле "DBPath.ini" прописать путь для подключения к файлу базы данных или указать этот путь выбрав пункт меню "Файл" -> "Выбор базы данных". При этом нужно не забыть выставить каталогу с базой данных права на чтение и запись для всех пользователей программы.

Вторая ИС, это программа Hardware Inspector. Программа предназначена для автоматизированного учета и инвентаризации компьютерной техники и иного оборудования в организациях. Уникальность программы Hardware Inspector заключается в возможности вести учет не просто текущего состояния параметров компьютера, а всей истории жизни отдельных комплектующих. На рисунке 2, показано наглядное представление устройств в дереве рабочих мест.

Рисунок 2 «Hardware Inspector»

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

Детальный учёт компьютеров и ПО;

Жизненный цикл учетных объектов;

Импорт устройств, ПО, рабочих мест и настроек сети;

Автоматизированный аудит рабочих мест;

Кроссировка сети;

Учет и планирование расходных материалов;

Учет заявок от пользователей;

Инвентаризация учетных объектов;

Гибкое разграничение доступа;

Поиск информации;

Более 30 встроенных настраиваемых отчетов;

Подробные справочники по всем аспектам учета;

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

Третья ИС, это конфигурация 1С:Учёт компьютеров и оборудования 8.1. Учет оборудования основан главные образом на штрихкодировании, таким образом, любая операция поиска, подбора или техники становится гораздо проще. С помощью этой конфигурации удобно учитывать и проводить инвентаризации компьютеров, оргтехники и любых других материальных ценностей (оборудование, телефоны, мебель), а так же автоматизировать другие сферы деятельности.

На рисунке 3 показана основная форма конфигурации 1С.

Рисунок 3 «1С:Учёт компьютеров и оборудования 8.1»

Основные характеристики продукта:

Учёт любой техники, мебели, программного обеспечения,

Учёт серийных, инвентарных номеров оборудования,

Импорт из системы аппаратного аудита Everest (автоматический сбор данных)

Максимально удобный пользовательский интерфейс

Учёт заявок поставщикам

Критерий		«Hardware Inspector»	Конфигурация 1С
Функциональность	Многофункциональна	Многофункциональна	Многофункциональна
Интерфейс	Интуитивно понятный	Простой – интуитивно понятный	Максимально удобный
		Приемлемый	Стандартный
Удобство для пользователя		Проста в использовании	Индивидуальные наборы настроек
Достоинства	Работает по сети	Работает по локальной сети Обновление 2 раза в месяц Одну лицензию можно установить на любое количество компьютеров, внутри одной локальной сети, одной организации	Действует бесплатная линия консультаций по электронной почте и ICQ, а в случае необходимости консультации по телефону.
Недостатки	Программа платная	Программа платная	Программа платная

Учёт заявок пользователей и работы с ними

Учёт расходных материалов

Автоматический поиск при сканировании

Индивидуальные наборы настроек и др.

Сравним выбранные информационные системы в Таблице 1 по следующим критериям: Функциональность, Интерфейс, Дизайн, Удобство для пользователя, Достоинства и недостатки;

Таблица 1 - Сравнение информационных систем

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

2.2 Описание Диаграмм бизнес процесса «Учет компьютерной техники предприятия»

2.2.1 Описание IDEF0 диаграммы

Для построения бизнес процесса была использована IDEF0 диаграмма. Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма). Было построено три уровня диаграммы:

Контекстная

Функциональная декомпозиция

Декомпозиция каждой работы

Рисунок 1 - Контекстная диаграмма «Учет компьютерной техники предприятия»

На рисунке 1 представлена контекстная диаграмма бизнес процесса «Учет компьютерной техники предприятия». Она отображает систему в целом и ее взаимодействие с основными внешними потоками информации.

На контекстной диаграмме обозначены стрелки.

Виды стрелок:

Входная информация для обработки:

Компьютеры – ПК (персональные компьютеры) находящиеся на предприятии

Комплектующие – материалы, необходимые для модернизации компьютеров (видеокарты, материнские платы, процессоры, корпуса, блоки питания, модули памяти)

Выходные потоки:

Отчет – готовый отчет по учету компьютерной техники предприятия

Входные управления:

Правила – условия, которые необходимо соблюсти, что бы достичь поставленной цели.

Приказы – поставленная задача предприятию (провести учет компьютерной техники на предприятии с помощью тех или иных информационных систем)

Руководители – директора и главные управляющие предприятием.

Входные ресурсы:

ПК – компьютеры, с помощью которых ведется учёт.

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

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

Рисунок 2 - Функциональная декомпозиция «Учет компьютерной техники предприятия»

Были выделены следующие виды работ:

Оформление поставок – процесс, в котором происходит присвоение id товару, отправка на хранение, на склад и занесение информации о товаре в программу.

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

Стрелка связь по входу между работами Оформление поставок и Обслуживание компьютера (компьютер);

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

Обслуживание компьютера – процесс, в котором происходит сборка, ремонт и модернизация компьютеров.

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

Стрелка управление – правила, приказы, руководитель;

Стрелка связь по входу между работами Обслуживание компьютера и Расстановка (занесение данных в базу), между работами Обслуживание компьютера и Составление отчета (занесение данных в базу);

Расстановка – процесс, в котором происходит расстановка компьютеров по офисам (кабинетам).

Стрелки управление – правила, приказы, руководитель;

Стрелка механизма – сотрудники;

Стрелка связь по входу между Расстановка и Составление отчета (присвоение id);

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

Затем каждая подсистема разбивается на более мелкие декомпозиции и так далее, до достижения нужной степени подробности.

На рисунке 3 представлена диаграмма, показывающая работу Оформления поставок более подробно.

В результате детализации были выделены основные функции. В раздел «Оформление поставок» входит семь главных стрелок (вход, выход, управление, механизм).

Стрелка входа – компьютеры и комплектующие;

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

Стрелки механизма, разветвляющие – ПК, сотрудники;

Стрелки входа, управления, механизмы повторяются во всех работах.

Присвоение номера – присвоение индивидуального номера компьютерам и комплектующим.

Стрелки входа – компьютеры и комплектующие. Стрелка компьютеры повторяется в последующих работах, кроме составления отчета;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – ПК и Сотрудники;

Стрелка связь по входу между работами Присвоение номера и Отправка товара на склад (перемещение), между «Присвоение номера» и «Постановка на баланс» (внесение в базу);

Отправка товара на склад – оправка товара с присвоенным номером на склад.

Стрелка выхода – компьютер;

Стрелки управления – правила, приказы и руководитель.

Стрелка связь по входу между работами «Отправка товара на склад» и «Постановка на баланс» (количество);

Постановка на баланс – занесение информации в компьютер.

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – ПК и Сотрудники;

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

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

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

Сборка компьютеров – конфигурация компьютеров по индивидуальному заказу руководителей.

Стрелка входа – компьютеры;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

Стрелка связь по входу между работами: «Сборка компьютеров» и «Ремонт компьютеров» (компьютер);

Ремонт компьютеров – сборка утвержденных к улучшению компьютеров.

Стрелка входа – компьютеры;

Стрелка выхода – занесение в базу;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

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

Стрелка связь по входу между работами: «Ремонт компьютеров» и «Upgrade» (комплектующие);

Upgrade – усовершенствование, улучшение, обновление компьютера.

Стрелка выхода – занесение в базу;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

Стрелки управления, механизма являются разветвляющимися;

На рисунке 5 представлена диаграмма «Составление отчета» более подробно. В декомпозицию работы Составление отчета входит 4 граничных стрелки (вход, выход, управление, механизмы). Внутренние стрелки (обратная связь по входу, связь по входу).

В результате работы были выведены следующие функции:

Сбор данных – сбор информации для анализа и принятия решений.

Стрелка входа – присвоение id;

Стрелки управления – правила, приказы и руководитель;

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

Стрелка связь по входу между работами: Сбор данных и Проверка данных (записи);

Проверка данных – проверка информации и отправка ее на составление отчета.

Стрелка входа – присвоение id, занесение данных в базу;

Стрелка выхода – Отчет;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники, ПК;

Стрелки входа (присвоение id), управления, механизма являются разветвляющимися;

Стрелкой обратной связи по входу с «Проверки данных» на «Сбор данных» (повторная проверка).

Закрытие ИП