Цель работы:
Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существующих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0.
Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.
Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними.
Функциональные блоки (работы) на диаграммах изображаются прямоугольниками, означающими поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Имя работы должно быть выражено отглагольным существительным, обозначающим действие.
IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.
Каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов. Такое обозначение отражает определенные системные принципы: входы преобразуются в выходы управление ограничивает или предписывает условия выполнения преобразований, механизмы показывают, что и как выполняет функция.
Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.
Наиболее доминирующий блок обычно размещается в верхнем левом углу диаграммы, а наименее доминирующий - в правом углу.
Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок, изображаемых одинарными линиями со стрелками на концах. Стрелки представляют собой некую информацию и именуются существительными.
В IDEF0 различают пять типов стрелок.
Вход - объекты, используемые и преобразуемые работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы.
Управление -.информация, управляющая действиями работы. Обычно управляющие стрелки несут информацию, которая указывает, что должна выполнять работа. Каждая работа должна иметь хотя бы одну стрелку управления, которая изображается как входящая в верхнюю грань работы.
Выход - объекты, в которые преобразуются входы. Каждая работа должна иметь хотя бы одну стрелку выхода, которая рисуется как исходящая из правой грани работы.
Механизм - ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.
Вызов - специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней части работы и используется для указания того, что некоторая работа выполняется за пределами моделируемой системы.
Рис. 2.1 Типы стрелок
В методологии IDEF0 требуется только пять типов взаимодействий между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.
Рис. 2.2. Связь по выходу
Рис. 2.3. Связь по управлению
Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более сложными, поскольку представляют собой итерацию или рекурсию. А именно выходы из одной работы влияют на будущее выполнение других работ, что впоследствии повлияет на исходную работу.
Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.
Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.
Рис. 2.4. Обратная связь по входу
Рис. 2.5. Обратная связь по управлению
Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).
В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.
Разветвление дуг, изображаемое в виде расходящихся линий, означает, что все содержимое дуг или его часть может появиться в каждом ответвлении. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами:
Слияния дуг в IDEFO, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:
Рис. 2.6. Связь выход-механизм
Для проведения количественного анализа диаграмм перечислим показатели модели:
Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент. Таким образом, убывание этого коэффициента говорит о том. что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 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.17).
Рис. 2.16. Декомпозиция работы «Изменение БД»
Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12
Проведение дальнейшей декомпозиции «Изменения БД» будет усложнять модель, объясняя, как осуществляется физическое изменение БД в системе. При этом пользователь не получит никакой дополнительной информации о работе системы службы занятости. Декомпозицию этой работы целесообразно проводить в процессе проектирования БД системы на этапе создания логической модели БД.
Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.
Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.
Рассмотрим изменение коэффициента К b у двух вариантов моделей.
для второго варианта
Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.
Будем считать, что уровень декомпозиции рассмотренных диаграмм достаточен для отражения цели моделирования, и на диаграммах нижнего Уровня в качестве наименований работ используются элементарные функции (с точки зрения пользователя системы).
Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.
Список Контрольных вопросов :
Дата
08 Авг 2013
Тема: Знакомство с CASE-средством разработки информационных систем BPwin
Цель работы : познакомиться с CASE-средством BPwin фирмы Computer Associates, научиться строить модель в методологии IDEF0 .
Порядок работы:
1. Ознакомиться с принципами построения модели в BPwin.
2. Ознакомиться с основной панелью инструментов.
3. Ознакомиться с палитрой инструментов IDEF0.
4. Научиться строить контекстную диаграмму, определять цель, точку зрения, границы модели. Освоить работу с закладками General, Purpose, Definition, Status, Numbering, Display.
5. Научиться строить декомпозирующие диаграммы.
6. Выполнить практическое задание.
7. Ответить на контрольные вопросы.
1. Краткая информация об CASE-средстве BPwin
BPwin - CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию бизнес-процессов. Поддерживается методология IDEF0 (функциональная модель), IDEF3 (Work Flow Diagram), DFD (Data Flow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE).
Процесс построения информационной модели в BPwin состоит из следующих шагов:
построение контекстной диаграммы;
проводится функциональная декомпозиция;
после каждого сеанса декомпозиции проводится сеанс экспертизы.
На основе модели BPwin можно построить модель данных. В программе поддерживается связь с ERwin.
2. Инструментальная среда BPwin
При запуске BPwin по умолчанию появляется основная панель инструментов (рис.1), палитра инструментов и навигатор модели Model Explorer (рис.2).
Рис.1 Внешний вид панели управления BPwin4.0
Панель инструментов представлена следующими кнопками (слева направо):
создать модель (пункт меню File/New);
открыть модель (пункт меню File/Open);
сохранить модель (пункт меню File/Save);
напечатать модель (пункт меню File/Print);
выбор масштаба (View/Zoom);
уменьшить модель (View/Zoom);
увеличить модель (View/Zoom);
проверить правописание (Tools/Spelling);
включение и выключение навигатора модели (View/Model Explorer);
включение и выключение дополнительной панели инструментов работы с Model Mart (Model Mart).
Рис.2 Внешний вид окна навигатора модели Model Explorer
При создании новой модели возникает диалог, в котором следует указать, будет ли модель создаваться заново, или она будет открыта из файла либо из репозитария Model Mart. Также необходимо внести имя модели и выбрать методологию, в которой будет построена модель (рис.3).
Рис.3 Диалог создания модели.
BPwin поддерживает три методологии моделирования:
функциональное моделирование (IDEFO);
описание бизнес-процес¬сов (IDEF3);
диаграммы потоков дан¬ных (DFD).
В зависимости от выбранной методологии программой автомати¬чески подбирается нужная панель инструментов BPwin Toolbox. В BPwin существует три разных панели инструментов - по числу поддерживаемых програм¬мой методологий. На рис.4 представлена палитра для IDEF0.
Рис.4 Палитра инструментов IDEF0.
Вы можете показывать или скрывать панель инструментов, используя функцию «View» на панели меню.
3. Построение модели IDEF0. Контекстная диаграмма
Функциональное моделирование является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объектов, которые обеспечивают их исполнение. Моделировать деловой про¬цесс можно исходя из различных перспектив и временных рамок. На¬пример, вы можете моделировать процесс заказа услуг клиентом так, как вы видите его в идеале, а не так, как это происходит в настоящее время. Также можно абстрагироваться от проблем физической реализации модели.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения КОНТЕКСТА, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить ГРАНИЦЫ СИСТЕМЫ, определить, что входит в систему, а что лежит за ее пределами. То есть необходимо решить, что будет рассматриваться как компоненты системы, а что как внешнее воздействие. Другими словами, первоначально необходимо определить область (Scope) моделирования.
Наименование функции самого высокого уровня опи¬сывает систему непосредственно и, как правило, состоит из одного активного глагола в сочетании с обобщающим существительным, ко¬торое разъясняет цель деятельности с точки зрения самого общего взгляда на систему. Например «Изготовить изделие».
Формулировка цели моделирования (Purpose) позволяет команде аналитиков сфокусировать усилия в нужном направлении. Модель не может быть построена без четко сформулированной цели.
Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения.
Для определения контекста модели в BPwin следует выбрать пункт меню Model/Model Properties. В закладке General указывается наименование и сведения об авторе модели, в закладку Purpose следует внести цель и точку зрения, а в закладку Definition – определение модели и описание области (рис.5).
Для создания контекстной диаграммы необходимо сначала соз¬дать новую модель, выбрав пункт «New» в меню «File». В появившем¬ся диалоге необходимо набрать имя модели и выбрать ее тип. Этот диалог также отображается при запуске BPwin.
После создания модели можно задать ее параметры. Кроме вышеперечисленных свойств модели (Model Properties) можно задать состоя¬ние, в котором находится модель, например «в работе» или «для публикации» (закладка Status).
Рис.5 Диалог задания свойств модели.
Каждый блок может иметь различные типы связанных с ним стре¬лок. Стрелки обозначают людей, место, вещи, понятия или события. Стрелки связывают границы диаграммы с блоками, а также действия (блоки) на диаграмме между собой. В диаграммах IDEF0 имеется че¬тыре основных типа стрелок.
Вход блока представляет материал или информацию, которая должна быть использована или преобразована блоком, чтобы произ¬вести продукцию (выпуск). Стрелки входа всегда направляются в левую сторону блока. Стрелки входа необязательны, так как не все действия могут преобразовать или изменять (заменять) что-либо.
Каждый блок должен иметь по крайней мере одну стрелку контро¬ля (управления). Управление всегда входит в вершину блока. Управ¬ление, как правило, представляется в виде правил, инструкций, поли¬тики компании, процедур или стандартов. Оно влияет на деятельность без фактического преобразования чего-либо. Управление может так¬же использоваться для описания процедуры начала или окончания вы¬полнения действия.
Стрелки выхода (выпуска) - это материал или информация, про-изведенная блоком. Каждый блок должен иметь по крайней мере одну стрелку выхода (выпуска). Процессы, которые не производят продук¬ции (выпуска), лучше не моделировать вообще.
Механизмы исполнения - это те ресурсы, которые обеспечивают выполнение действия. В качестве механизма исполнения могут быть рассмотрены персонал компании, машины или оборудование, кото¬рые обеспечивают выполнение деятельности. Стрелка механизма мо¬жет отсутствовать, если определено, что это не важно для работы блока.
Рис.6 Пример контекстной диаграммы.
4. Декомпозиция
Декомпозиционное разложение модели используется в моделиро¬вании бизнес-процессов, для того чтобы дать более подробное описа¬ние блоков. Каждый из них может в свою очередь быть де¬композированным. При каждой декомпозиции блока создается новая диаграмма. Число декомпозиций не ограничено и полностью зависит от уровня сложности, который необходимо показать в модели.
Чтобы выполнить декомпозицию функции, необходимо щелкнуть по кнопке . Возникает диалог Activity Box Count (рис.7), в котором следует указать нотацию новой диаграммы и количество блоков на ней. Для IDEF0 рекомендуется 3-6 блоков.
Рис.7 Диалог Activity Box Count.
BPwin создает новую диаграмму, которая является диаграммой разложения родительской диаграммы. Заметьте, что новые действия не связаны между собой и не поименованы - это следующая задача. Необходимо задать взаимодействие между блоками и «привязать» к но¬вым блокам стрелки, которые автоматически унаследованы от роди¬тельской диаграммы (рис.8).
Рис.8 Пример несвязанных стрелок.
Имя блока и другие его свойства вводятся в закладке «Name» спи¬ска свойств блока. Для вывода свойств блока на экран достаточно два¬жды щелкнуть мышью на блоке.
Следующим шагом при создании диаграммы должно быть соеди¬нение всех использованных на диаграмме блоков с помощью стрелок, представляющих входы, результаты работы, средства управления и механизмы. Для этого достаточно соединить исходящую точку стрел¬ки с точкой ее окончания. Окончанием стрелки может быть как одна из сторон функциональных блоков, так и граница диаграммы. BPwin автоматически выделяет допустимые окончания для создаваемых стрелок. Для рисования стрелки пользуются инструментом из комплекта инструментов. Задание имени стрелки производится в закладке «Name» диалога свойств стрелок. Для вызова этого диалога достаточно дважды щелк¬нуть мышью на нужной стрелке.
Если количества блоков на диаграмме окажется недостаточным, существует возможность добавления на нее новых блоков с использованием кнопки панели инструментов. Для добавления блока сле¬дует щелкнуть на этом инструменте, а затем - на диаграмме в том месте, где необходимо расположить новый блок. После того как до¬полнительный блок создан, вы можете связать его стрелками с други¬ми блоками и задать его название и другие свойства.
Обра¬тите внимание на рис.9. Если действие не было декомпозирова¬но, в верхнем левом углу блока будет по¬являться символ «листа». После деком-позиции данного блока символ «листа» исчезнет.
Рис.9 Пример недекомпозированного блока.
Нумерация блоков производится автоматически при их создании. Номера могут быть относительными или постоянными, они отражают иерархическое положение блока в пределах модели. Вы можете управлять нумерацией блоков на диаграмме, используя закладку «Numbering» диалога ввода свойств модели (рис.5).
Перемещение любых объектов на диаграмме осуществляется с по¬мощью их «захвата» мышью и перемещения в новое место. При пере¬мещении блоков одновременно перемещаются и связанные с ними стрелки. Функциональные блоки могут также быть перемещены меж¬ду диаграммами с использованием команд «Cut/Paste» из меню «Edit». При изменении взаимного расположения блоков могут меняться и их но¬мера.
Для идентификации граничных стрелок предназначены ICOM-коды. Код содержит префикс, соответствующий типу стрелки (Input, Control, Output, Mechanism) и порядковый номер. BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога свойств.
Практическое задание:
1. Согласно варианту, создайте контекстную диаграмму. Определите цель, точку зрения модели. Опишите свойства в соответствующих закладках диалога Model Properties.
2. Задайте входы, выходы, механизмы и управление.
3. Создайте декомпозицию контекстной диаграммы, состоящую из 2-3 блоков. Задайте автоматическую нумерацию блоков и ICOM-кодов.
4. Установите связи между блоками. Задайте имена дуг.
5. Сохраните проект в отдельный файл.
Контрольные вопросы:
1. Для чего используется методология IDEF0.
2. Объясните необходимость задания цели и точки зрения модели?
3. Перечислите и расскажите назначения кнопок на панели инструментов.
4. Перечислите этапы декомпозиции блока.
5. Расскажите, каким образом на диаграмму добавить блок, дугу.
6. Дайте определение ICOM-кодов.
7. Для чего используются закладки General, Purpose, Definition, Status, Numbering, Display в диалоге Model Properties.
Варианты к практическим работам
Вариант 1
Система должна описывать порядок подготовки к экзамену, предполагающий получение отличной оценки.
Вариант 2
Система должна описывать порядок выполнения практической работы по дисциплине «Проектирование ИС».
Вариант 3
Система должна описывать порядок получения водительских прав.
Вариант 4
Система должна описывать порядок организации городского спортивного соревнования.
Вариант 5
Система должна описывать порядок организации общеинститутского студенческого мероприятия.
Вариант 6
Система составления учебного графика дисциплин, изучаемых на факультете
Вариант 7
Система должна описывать порядок поставок товара в систему розничных киосков.
Вариант 8
Система должна описывать порядок обработки заказов в службе быта.
Вариант 9
Система должна описывать работу одного из участков автосалона.
Вариант 10
Система должна описывать работу приемного покоя в больнице.
Вариант 11
Система должна описывать порядок приема заявки на поставку продукции на хлебокомбинате.
Вариант 12
Система должна описывать процесс поставки сезонных товаров в оптовой фирме.
Вариант 13
Система должна описывать процесс работы торгового отдела.
Вариант 15
Система учета в видеопрокате.
Вариант 16
Система учета проката на лыжной базе
Кафедра «Прикладная информатика в экономике»
КУРСОВОЙ ПРОЕКТ
по дисциплине «Бизнесреинжиниринг»
на тему: «Проектирование бизнес-процессов предприятия сферы обслуживания (предприятие по оказанию услуг в сфере проката автомобилей)»
ВВЕДЕНИЕ...………………………………………………… ……………………………...…..3
1. АНАЛИТИЧЕСКИЙ
РАЗДЕЛ……………………………………………….…………… ….4
1.1. Основные
направления деятельности предприятия………………………………………4
1.2 Структурно-функциональное
моделирование бизнес-процессов предприятия…………5
1.3 Недостатки существующей
структурно-функциональной модели
бизнес-процессов предприятия………………………………………………… …………………………………..14
2. ПРОЕКТНЫЙ
РАЗДЕЛ……………………………………………………………… ...……16
2.1 Автоматизация
структурно-функциональных моделей
бизнес-процессов предприятия…… ……………………………………………………………………………… ..16
3. ПРОЕКТ ИНФОРМАЦИОННОЙ
СИСТЕМЫ…………………………………………….31
3.1 Модель данных
ИС………………………………………………………………………… 31
3.2 Интерфейс
пользователя……………………………………………… …………………...33
4. ЭКОНОМИЧЕСКИЙ
РАЗДЕЛ……………………………………………………………. ..38
4.1 Анализ затрат
по проекту…………………………………………………………… ……..38
4.2 Расчет основных
экономических показателей…………… ……………………………...
41
ЗАКЛЮЧЕНИЕ.………………………………………………… ………..…………………….44
БИБЛИОГРАФИЧЕСКИЙ
СПИСОК…...………………………………….……………… …45
ВВЕДЕНИЕ
Современный
этап развития общества характеризуется
внедрением автоматизированных информационных
систем во все сферы деятельности, в том
числе и сфере обслуживания.
Прокат
автомобилей вот уже много лет остается
очень востребованным на территории России.
Залог устойчивого положения на российском
рынке как ООО «VolgaRent», так и отдельных
его филиалов, - удовлетворение всех потребностей
клиентов.
Целью
данного курсового проекта является
разработка информационной системы, автоматизирующей
бизнес-процесс предприятия сферы обслуживания,
занимающегося прокатом автомобилей.
Задачами
данного курсового проекта является:
1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ
1.1 Основные направления деятельности предприятия
Предприятие
ООО «VolgaRent», деятельность которого
планируется автоматизировать, занимается
прокатом авто. Важнейшим звеном в данной
деятельности является спецоборудование.
В зависимости от того, насколько работа
персонала автоматизирована, можно судить
об эффективности его работы. Каждый день
организация осуществляет прием и выдачу
автомобилей разных марок, окрасов, и съёмной
стоимости.
Персонал
заполняет БД клиентов (ФИО, адрес, тел),
если его еще там нет. После
этого персонал осуществляет поиск
интересующего автомобиля в БД. После
того как клиент получает интересующий
его авто, редактируется информация о
выданных автомобилях. После возвращения
клиентом взятого авто, вновь редактируется
БД выданных авто и данные о взятых клиентом
автомобиле.
Ниже
(см. рис. 1.1) представлена схема
организационной структуры
нашей предметной области.
Рис. 1.1 Организационная структура
Рис. 1.2 Организационная структура автоматизируемого подразделения
Данная информационная система разрабатывается с расчетом на одного пользователя – обслуживающего персонала, поскольку все функции по работе с клиентами возложены только на него. При работе с системой обслуживающий персонал должен иметь возможность решать следующие задачи:
1.2 Структурно-функциональное моделирование бизнес-процессов предприятия
Для
проведения анализа и реорганизации
бизнес-процессов воспользуемся CASE-средством.
Bpwin поддерживает методологии IDEF0 (функциональная
модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).
Функциональная
модель предназначена для описания
существующих бизнес-процессов на предприятии
(так называемая модель AS-IS) и идеального
положения вещей - того, к чему нужно стремиться
(модель ТО-ВЕ). Для начала построим функциональные
диаграммы бизнес-процессов, которые предстоит
улучшить, т.е. модели AS-IS:
На
рисунках 1.3 и 1.4 представлены контекстная
диаграмма и диаграмма декомпозиции процесса
«Выбор авто». На вход поступает информация
о финансовых возможностях клиента, и
текущий модельный ряд автомобилей. С
помощью любезного персонала клиенту
предоставляется возможность выбрать
понравившийся автомобиль, и тем самым
на выходе вы получаем выбранный авто.
За управление процессами отвечают государственные
стандарты. Механизмами служат клиент,
который выбирает авто, и персонал, который
обслуживает клиента.
Рис. 1.3 Контекстная диаграмма функциональной модели процесса «Выбор авто»
Рис. 1.4 Диаграмма декомпозиции процесса «Выбор авто»
Рис. 1.5 Контекстная диаграмма функциональной модели процесса «Выдача авто»
Рис. 1.6 Диаграмма декомпозиции процесса «Выдача авто»
Рис. 1.7 Контекстная диаграмма функциональной модели процесса «Оформление квитанции»
Рис. 1.8 Диаграмма декомпозиции процесса «Оформление квитанции»
Рис. 1.9 Контекстная диаграмма функциональной модели процесса «Оплата за ренту»
Рис. 1.10 Диаграмма декомпозиции процесса «Оплата за ренту»
Рисунки
1.5 и 1.6 отображают процесс «Выдача авто».
Входом является модельный ряд и сведения
о клиенте. На выходе клиенту выдаётся
автомобиль. Ресурсной стрелкой является
обслуживающий персонал, который и выдаёт
клиенту авто. Управляют процессами внутренние
правила предприятия «VolgaRent».
На
рисунках 1.7 и 1.8 представлены диаграммы
процесса «Оформление квитанции». Входным
материалом является заявка клиента, которая
передаётся обслуживающему персоналу,
который в свою очередь обрабатывает заявку
при помощи ИС, и на выходе клиент получает
чек, который обязан оплатить и квитанцию
об оплате.
Завершающим
процессом является «Оплата за ренту».
Контекстная диаграмма и диаграмма
декомпозиции этого процесса отображены
на рисунках 1.9 и 1.10. Входная стрелка
– это заявка и непосредственно деньги
от клиента, которые передаются обслуживающему
персоналу. Персонал, обрабатывает полученную
информацию, производит пересчёт средств,
и на выходе клиент получает чек об оплате
за авто. За управление в данном процессе
отвечает законодательство РФ.
1.3 Недостатки существующей структурно-функциональной модели бизнес-процессов предприятия
После изучения структурно-функциональных моделей бизнес процессов предприятия по прокату автомобилей можно выделить несколько проблем, которые необходимо решить:
2. ПРОЕКТНЫЙ РАЗДЕЛ
2.1 Автоматизация структурно- функциональных моделей бизнес-процессов предприятия
Найденные
в модели AS-IS недостатки можно исправить
при создании модели ТО-ВЕ (как будет) -
модели новой организации бизнес-процессов.
Технология проектирования ИС подразумевает
сначала создание модели AS-IS, ее анализ
и улучшение бизнес-процессов, то есть
создание модели ТО-ВЕ, и только на основе
модели ТО-ВЕ строится модель данных, прототип
и затем окончательный вариант ИС.
Как
правило, данная модель создается на
основе AS-IS, с устранением недостатков
в существующей организации бизнес-процессов,
а так же с их совершенствованием
и оптимизацией. Это достигается за
счет устранения выявленных на базе анализа
AS-IS узких мест.
В
традиционном реинжиниринге именно на
основе модели TO-BE рекомендуется производить
автоматизацию бизнес-процессов и проектировать
КИС. Подразумевается, что это позволяет
существенно снизить риск проявления
автоматизации как исключительно источника
затрат из-за автоматизации несовершенных
процессов.
Построим
функциональные диаграммы ТО-ВЕ бизнес-процессов,
которые мы изменили.
На
рисунках 2.1 и 2.2 представлены контекстная
диаграмма и диаграмма декомпозиции процесса
«Выбор авто». На вход поступает информация
о финансовых возможностях клиента, и
текущий модельный ряд автомобилей. С
помощью любезного персонала клиенту
предоставляется возможность выбрать
понравившийся автомобиль, и тем самым
на выходе вы получаем выбранный авто.
За управление процессами отвечают государственные
стандарты. Механизмами служат клиент,
который выбирает авто, и персонал, который
обслуживает клиента. В результате автоматизации
предприятия произошло внедрение ИС в
данный процесс. ИС позволила выбрать
авто из каталога БД.
Рисунки
2.3 и 2.4 отображают процесс «Выдача
авто». Входом является модельный ряд
и сведения о клиенте. На выходе клиенту
выдаётся автомобиль. Ресурсной стрелкой
является обслуживающий персонал, который
и выдаёт клиенту авто. Управляют процессами
внутренние правила предприятия «VolgaRent».
В результате процесса «Выдача авто» выдаётся
доверенность клиенту на управление выбранным
транспортным средством.
Рис. 2.1 Контекстная диаграмма функциональной модели процесса «Выбор авто» после автоматизации
Рис 2.2 Диаграмма декомпозиции процесса «Выбор авто» после автоматизации
Рис. 2.3 Контекстная диаграмма функциональной модели процесса «Выдача авто» после автоматизации
Рис 2.4 Диаграмма декомпозиции процесса «Выдача авто» после автоматизации
Рис. 2.5 Контекстная диаграмма функциональной модели процесса «Оформление квитанции» после автоматизации
Рис 2.6 Диаграмма декомпозиции процесса «Оформление квитанции» после автоматизации
Рис. 2.7 Контекстная диаграмма функциональной модели процесса «Оплата за ренту» после автоматизации
Рис 2.8 Диаграмма декомпозиции процесса «Оплата за ренту» после автоматизации
На
рисунках 2.5 и 2.6 представлены диаграммы
процесса «Оформление квитанции». Входным
материалом является заявка клиента, которая
передаётся обслуживающему персоналу,
который в свою очередь обрабатывает заявку
при помощи ИС, и на выходе клиент получает
чек, который обязан оплатить и квитанцию
об оплате. В результате поправок в законодательстве
РФ в процессе «Оформление квитанции»,
формируется квитанция и выдаётся чек
клиенту, благодаря ИС.
Завершающим
процессом является «Оплата за ренту».
Контекстная диаграмма и диаграмма
декомпозиции этого процесса отображены
на рисунках 2.7 и 2.8
Входная
стрелка – это заявка и непосредственно
деньги от клиента, которые передаются
обслуживающему персоналу. Персонал, обрабатывает
полученную информацию, производит пересчёт
средств, и на выходе клиент получает чек
об оплате за авто. За управление в данном
процессе отвечает законодательство РФ.
Вследствие автоматизации данного процесса
появилась возможность выдачи гарантии
на арендуемое авто.
3. ПРОЕКТ ИНФОРМАЦИОННОЙ СИСТЕМЫ
3.1 Модель данных ИС
Процесс
моделирования в Erwin базируется на
методологии проектирования реляционных
баз данных IDEF1X.
Для
проектирования базы данных проектов
использовалась модель «сущность –
связь» (Entity – Relationship model, или ER – модель).
ER – модель представляет собой высокоуровневую
концептуальную модель данных, цель которой
- упрощение задачи проектирования баз
данных. Данная модель данных включает
в себя набор концепций, которые описывают
структуру базы данных и связанные с ней
транзакции обновления и выборки данных.
Следует подчеркнуть, что концептуальная
модель данных не зависит от конкретной
СУБД или аппаратной платформы, которая
используется для физической реализации
базы данных.
Основными
элементами IDEF1X являются сущности, атрибуты
и связи.
Каждая
сущность является множеством подобных
индивидуальных объектов, называемых
экземплярами. Каждый экземпляр индивидуален
и должен отличаться от всех остальных
экземпляров. Атрибут выражает определенное
свойство объекта. Атрибут или группа
атрибутов, которые идентифицируют сущность,
называется первичным ключом. С точки
зрения БД (физическая модель) сущности
соответствует таблица, экземпляру сущности
- строка в таблице, а атрибуту - колонка
таблицы.
Сущности
изображаются в виде прямоугольников.
Имя сущности показывается над прямоугольником,
изображающим сущность, список атрибутов
сущности - внутри прямоугольника. Список
разделен горизонтальной чертой, выше
которой расположены атрибуты первичного
ключа, ниже – не ключевые атрибуты.
В
IDEF1X также различают зависимые
и независимые сущности. Тип сущности
определяется ее связью с другими
сущностями. Зависимая сущность изображается
прямоугольником со скругленными углами.
Результатом
нормализации является модель данных,
которую легко поддерживать, не содержащая
неопределенностей в данных и повторений
данных.
После
выделения информационных объектов
необходимо объединить их в одну систему,
то есть установить связи между ними.
Объект
«Марки» связан с полем «Автомобили» связью
«один ко многим». Этот тип связи применяется,
когда одному значению вспомогательного
объекта соответствует много значений
главного. По аналогии с этим устанавливаются
связи «один ко многим» у остальных информационных
объектов «Персонал», «Клиенты», «Выдача
авто», с соответствующими полями связанных
между собой таблиц. Схема логической
модели данных представлена на рисунке
3.1.
Рис. 3.1 Логическая модель базы данных.
3.2 Интерфейс пользователя
Рис. 3.2 Форма «Прокат автомобилей»
Форма
«Прокат автомобилей» - это начальная
форма приложения, с помощью неё осуществляется
возможность доступа к формам: «Автомобили»,
«Комплектация», «Клиенты», «Персонал»,
«Выдача автомобилей».
Рис. 3.3 Форма «Автомобили»
С
помощью формы «Автомобили», осуществляется
редактирование информации об имеющихся
в прокате авто, редактирование производится
с помощью стандартных кнопок: «Удалить»,
«Добавить», «Переместить», и «Откат действия».
Также на форме осуществляется
сортировка по: коду, марке, году, комплектации,
и цене проката. На данной форме предусмотрена
возможность поиска и фильтрации данных
по выбранным параметрам, а также добавление
фотографий имеющихся автомобилей, функция,
создана для отображения внешнего вида
автомобиля, что значительно экономит
время просмотра авто клиентом.
Рис.
3.4 Форма «Комплектация»
Через
форму «Комплектация» осуществляется
редактирование данных об имеющихся данных.
Редактирование данных осуществляется
при помощи кнопок: «Добавить», «Удалить»,
«Переместить», «Откат действия». На данной
форме предусмотрена возможность сортировки,
поиска и фильтрации данных по выбранным
параметрам.
Рис. 3.5 Форма «Клиенты»
Через форму «Клиенты» осуществляется редактирование данных о клиентах. Редактирование данных осуществляется при помощи кнопок: «Добавить», «Удалить», «Переместить», «Откат действия». На данной форме предусмотрена возможность сортировки, поиска и фильтрации данных по выбранным параметрам.
Рис.
3.7 Форма «Персонал»
Через
форму «Персонал» осуществляется редактирование
данных о обслуживающем персонале.
Редактирование данных осуществляется
при помощи кнопок: «Добавить», «Удалить»,
«Переместить», «Откат действия». На данной
форме предусмотрена возможность сортировки,
поиска и фильтрации данных по выбранным
параметрам.
Рис. 3.8 Форма «Выдача»
Форма
«Выдача автомобилей» - это главная
форма приложения, в которую заносятся
данные о менеджере, отдавшем автомобиль
в ренту, клиенте, который этот автомобиль
взял в прокат, об арендуемом автомобиле,
и о дате аренды.
Редактирование
данных осуществляется при помощи кнопок:
«Добавить», «Удалить», «Переместить»,
«Откат действия», «Отчёт». На данной форме
предусмотрена возможность сортировки,
поиска и фильтрации данных по выбранным
параметрам.
При
нажатии кнопки «запрос по дате»,
отбираются сведения о клиенте, менеджере
и рентуемом автомобиле, который был взят
в прокат в этот день.
При
нажатии на кнопку «Отчет» формируется
отчет по данным о клиентах, представленный
на рис. 3.9
.
Рис. 3.9 Отчет по выдачам автомобилей
4. ЭКОНОМИЧЕСКИЙ РАЗДЕЛ
4.1 Анализ затрат по проекту
Затраты
на ресурсы процесса «Выбор авто»:
Затраты
на рекламу – 5000 р.
Оплата
персоналу – 26000 р.
Создание
каталога – 2000 р
Рис. 4.1 Диаграмма дерево узлов процесса «Выбор авто»
Затраты
на ресурсы процесса «Выдача авто»:
Зар.плата
персоналу – 17500 р
Электроэнергия
– 700 р
Рис. 4.2 Диаграмма дерево узлов процесса «Выдача авто»
Затраты
на ресурсы процесса «Оформление
квитанции»:
Зар.плата
персоналу – 14700 р
Канцтовары
– 500 р
Электроэнергия
– 300 р
Рис. 4.3
Диаграмма дерево узлов
процесса «Оформление
квитанции»
и т.д.................
Основные функции отдела сбыта заключаются в реализации автомобилей и ведении их учета. Деятельность отдела сбыта регулирует начальник отдела сбыта, который осуществляет руководство по развитию и функционированию, организовывает подготовку и проводит внутренние проверки, анализирует их результаты, контролирует выполнение корректирующих мероприятий.
Менеджер по продажам осуществляет связь между покупателем и производителем товаров или услуг. Главная задача менеджера по продажам - реализация товара. Продавцы-консультанты - это специалисты по консультационным продажа. Консультационные продажи предполагают информационное сопровождение клиента, ведение переговоров с клиентами всех уровней, обслуживание покупателей в соответствии с технологиями продаж, оказание консультационной помощи покупателям относительно свойств, характеристик товаров, расчет итоговой стоимости покупки.
Организация учета реализации автомобилей в автосалоне предполагает следующие бизнес-процессы:
1. Заказ автомобиля - после выбора автомобиля оформляется заказ на выбранную модель, подготавливается и отправляется запрос на завод - изготовитель, принимается предоплата и выдается квитанция о предоплате;
2. Прием автомобиля - принятие автомобиля на внутренний учет, проведение предпродажной подготовки и диагностики автомобиля, оповещение покупателя;
3. Реализация автомобиля - осмотр автомобиля покупателем, оформление договора купли-продажи;
4. Регистрация оплаты;
5. Формирование отчетных документов:
Формирование отчета «Прайс-лист»;
Формирование отчета «Анализ продаж»;
Формирование отчета «Заказы автомобилей»;
Формирование отчета «Состояние заказов».
Для формализованного описания вышеописанных бизнес-процессов построим функциональную модель IDEF0. Основной структурной единицей IDEF0-модели является диаграмма, представляющая собой графическое описание модели предметной области или ее части. Главными компонентами IDEF0-диаграммы являются блоки. Каждый блок диаграммы соответствует некоторой функции, для которой необходимо определить исходные данные, результат, управляющую функцию и механизм ее реализации. Взаимодействие функций с внешним миром и между собой описывается с помощью дуг (связей). В IDEF0 различают пять типов дуг:
1) Вход - материал или информация, которые используются или преобразуются блоком для получения результата (выхода);
2) Выход - результат выполнения функции (материал или информация);
3) Управление - условия, правила, стандарты, которые влияют на выполнение функции;
4) Механизм - ресурсы, с помощью которых выполняется работа;
5) Вызов - специальная дуга, указывающая на другую модель предметной области.
На рисунках 1.3 (а, б, в) представлена IDEF0-модель «Информационная система автосалона», декомпозированная на 3 подуровня. На первом уровне блок А0 отвечает за реализацию автомобилей на основе следующих данных: заказ клиента и поставщик автомобилей. В результате на выходе получаем выполненный заказ. В качестве управления выступают: законодательство РФ, лицензия на продажу, каталог автомобилей. Механизм - Автосалон «AlongTheRoad».
Рисунок 1.3 (а)
При декомпозиции (рис. 1.3(б)) блок А0 разбивается на 4 блока: А1, А2, А3, А4. В блоке А1 формируется план закупок, руководствуясь входными данными заказ клиента, поставщик автомобилей. Блок А2 - Договор с поставщиками соединяется с блоком А3 - Формирование каталога автомобилей. Блок А4 отвечает за сбыт автомобилей, на выходе - выполненный заказ. Механизмами выступают: отдел по закупке автомобилей, юридический отдел, отдел рекламы и PR, отдел бухгалтерии, отдел сбыта автомобилей. Таким образом, выделили 4 подзадачи, произведя детализацию первого уровня.
Рисунок 1.3 (б) - Диаграмма декомпозиции
Перейдем на 3 уровень декомпозиции блока А4 - Сбыт автомобилей (рис. 1.3(в)). Диаграмма представлена тремя блоками: А41 - Принятие заявки, А42 - Оформление договора, А43 - Продажа автомобиля. В качестве управления остаются те же стандарты и правила, что и на первом уровне, на выходе получаем выполненный заказ.
Рисунок 1.3 (в) - Диаграмма декомпозиции
В результате анализа деятельности отдела сбыта был выявлен комплекс информационных потоков.
Входные данные:
Сведения о клиентах;
Заказы клиентов;
Сведения об автомобилях;
Данные для формирования отчетов;
Сведения о поставщиках.
Выходные документы:
Отчет «Прайс-лист»;
План закупок;
Договор с поставщиками;
Каталог автомобилей;
Отчет «Анализ продаж»;
Отчет «Заказы автомобилей»;
Отчет «Состояние заказов».
В результате исследования информационных потоков была построена DFD модель, которая показывает, какие информационные потоки возникают при выполнении функций. Она будет применяться при проектировании базы данных. В приложении А представлены диаграммы потоков данных ИС «Автоматизация торговых операций в автосалоне».
Таким образом, целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (DFD). Диаграммы потоков данных предназначены для описания документооборота и обработки информации. При создании диаграммы потоков данных используются четыре основных понятия:
– Потоки данных;
– Процессы (работы) преобразования входных потоков данных в выходные;
– Внешние сущности;
– Накопители данных (хранилища).
Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Процессы (работы) служат для преобразования входных потоков данных в выходные. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных моделирует данные, которые будут сохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных.
