Кредит — очень частое явление. Вследствие чего ежедневно люди стоят в больших очередях чтобы подать заявку либо выплатить кредит. По этой причине стандартную схему выдачи потребительских кредитов можно изменить, добавив систему подачи заявок через интернет, благодаря которой клиенту нужно всего лишь зайти на интернет ресурс, на котором имеется форма бланка для подачи заявки, заполнить ее, дождаться ответа на электронный адрес, и прийти для заключения кредитного договора.
Таким образом, большее число клиентов может обращаться с заявками, не стоя в километровой очереди.
Построение модели TO BE
Найденные в модели AS-IS недостатки исправляются путем создания модели ТО-ВЕ (как будет), т.е. модели новой организации процессов на предприятии. Создание и внедрение ИС приводит к изменению условий выполнения отдельных операций, структуры процессов и предприятия в целом. Это приводит к необходимости изменения системы правил, используемых на предприятии, модификации должностных инструкций сотрудников.
Пример бизнес-процесса «Оплата самолёта и отеля с карточки» в BPMN
Функциональная модель TO-BE позволяет уже на стадии проектирования будущей ИС определить эти изменения. Применение функциональной модели TO-BE позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям. Модель ТО-ВЕ нужна для анализа альтернативных (лучших) путей выполнения функции и документирования того, как компания будет делать бизнес в будущем.
Функциональная модель TO-BE позволит четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов после предлагаемого реинжиниринга.
Дополнительные функции и возможности при построении функциональной модели процессов в модели TO-BE:
· модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности.
· модель позволяет четко определить распределение ресурсов между этапами процесса, что дает возможность оценить эффективность использования ресурсов.
Последняя задача особенно актуальна при создании новых процессов на предприятии. Например, предприятие, которое ранее специализировалось на выпуске серийной продукции, решило выпускать продукцию под заказ, для чего необходимо создать собственную службу сбыта. Функциональная модель процесса по продаже такого оборудования позволит руководству предприятия более четко определить, какие ресурсы необходимо выделить для того, чтобы обеспечить функционирование службы сбыта, сколько сотрудников необходимо привлечь для работы в новой службе, какие функциональные обязанности эти сотрудники должны выполнять и т.д.
Общепринятая технология проектирования ИС подразумевает сначала создание модели AS-IS, затем на основе ее анализа определяются направления улучшение процессов, т.е. создание модели ТО-ВЕ. Только на основе разработанной модели ТО-ВЕ в дальнейшем происходит построение модели данных, прототипа и затем окончательного вариант ИС. Если в основу автоматизации предприятия будет изначально заложена модель AS-IS, то создаваемая «новая» ИС будет выполняться по принципу «все оставить, как есть», и вместо информатизации предприятия на основе новых ИТ, произойдет (в лучшем случае) простая компьютеризация несовершенных процессов. В результате внедрение и эксплуатация такой «новой» ИС приведет к дополнительным издержкам на закупку оборудования, создание программного обеспечения и их сопровождение.
Пример процесса BPMN «Подготовка отправки товара»
DFD
Итак, немного немало, мы добавили в стандартную систему кредитования интернет ресурс. Благодаря нему, процесс переговоров с заявителем перекладывается на специальный сайт, на котором клиенты оставляют заявки. Заявки обрабатываются службами банка, а затем банк оповещает клиента по электронному адресу или контактному телефону о принятом решении. Получив положительный ответ, клиент приходит в банк для заключения кредитного договора. Теперь ему всего лишь остается выплачивать кредит в течении установленного срока.
Источник: studentopedia.ru
Методология IDEF0 в BPWin. Модель AS-IS и TO-BE
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Моделируемая система рассматривается как произвольное подмножество Вселенной.
Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования.
Первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — мы определяем, что будет рассматриваться внутри системы, а что снаружи.
Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плавающей области»).
Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
• Почему этот процесс должен быть замоделирован?
• Что должна показывать модель?
• Что может получить читатель?
Примерами формулирования цели могут быть следующие утверждения: «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений», «Идентифицировать роли и ответственность служащих для написания должностных инструкций», «Описать функциональность предприятия с целью написания спецификаций информационной системы» и т. д.
Точка зрения (Viewpoint). Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования.
Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.
IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т.д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации. Для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра».
Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных (лучших) путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.
Технология проектирования ИС подразумевает сначала создание модели AS-1S, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Report/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет.
Диаграммы IDEF0. Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
• контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);
• диаграммы декомпозиции;
• диаграммы дерева узлов;
• диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты.
Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели для иллюстрации альтернативной точки зрения, либо для специальных целей.
Источник: poisk-ru.ru
V Международная студенческая научная конференция Студенческий научный форум — 2013
РАЗРАБОТКА МОДЕЛИ TO-BE ДЛЯ ИС ООО «РЕСТОРАН «ЭЛИСТА»
Корнякова Б.С. 1
1 Московский технический университет связи и информатики
Работа в формате PDF
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF
В статье кратко изложен результаты курсового проекта по дисциплине «Проектирование ИС» (МТУСИ, ФИ, 4 курс, научн.рук. проф.Воронова Л.И.) связанного с разработкой модели TO-BE для ИС ООО «Ресторан «Элиста»
Ресторанный бизнес — важный субъект рыночной инфраструктуры, поэтому разработка ИС для предприятий малого бизнеса является актуальной задачей.
Целью курсовой работы являлось проектирование ИС ООО «Ресторан «Элиста» с дальнейшей интеграцией с разработанной для компании базой данных. Стадии и этапы создания ИС должны соответствовать ГОСТ 34.601-90.
Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. При формировании требований к ИС производится обследование объекта и обоснование необходимости создания ИС. Также разрабатываются концепции ИС, техническое задание и документация. Информационная модель проектируется в двух видах «как есть» и «как должно быть». В работе курсовой работе проведён системный анализ предметной области, краткий обзор информационных систем, изложены основные принципы проектирования информационных систем, моделирование моделей «как есть» и «как должно быть», разработана инфологическая модель предметной области и осуществлен переход к реляционной модели базы данных, разработан пакет сопровождающих моделирование документов. Программная реализация выходит за рамки данного проекта.[1]
Проектирование информационной системы для ООО «Ресторан«Элиста»
Разработка модели TO-BE
Основной принцип процессного подхода определяет структурирование бизнес–системы в соответствии с деятельностью и бизнес-процессами предприятия, а не в соответствии с его организационно-штатной структурой. Именно бизнес-процессы, обеспечивающие значимый для потребителя результат, представляют ценность и для специалистов, проектирующих ИС. Процессная модель компании должна строиться с учетом следующих положений: верхний уровень модели должен отражать только контекст диаграммы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром. На втором уровне должны быть отражены тематически сгруппированные бизнес-процессы предприятия и их взаимосвязи. Каждая из деятельностей должна быть детализирована на бизнес-процессы.
Руководствуясь этими знаниями разработаем модель «TO-BE», используя процессный подход с помощью средства BPWin.[2]
1. Создание модели в стандарте IDEF0
IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).
Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны : — стрелка входа приходит всегда в левую кромку активности, — стрелка управления — в верхнюю кромку, — стрелка механизма — нижняя кромка, — стрелка выхода — правая кромка.
Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку. [3][4]
Разработаем диаграммы в методологии моделирования IDEF0. Контекстная диаграмма (рис.1.) содержит общее описание системы. Компания получает заявку клиента, и сотрудники, руководствуясь правилами, выполняет заказ.
Рис. 1 Контекстная диаграмма Рис. 2 Диаграмма декомпозиции
«Деятельность компании» IDEF0 «Деятельность компании» IDEF0
Создадим диаграмму декомпозиции диаграммы «Деятельность компании» в методологии IDEF0 (рис.2). В компании ведется деятельность основная и деятельность поддерживающая. Основная деятельность работает с заявками клиентов, поддерживающая деятельность работает с заявками сотрудников основного штаба, получая от них заявку, устраняет проблему, например, с техническим обеспечением.
Поступление заказа может быть двух видов: заказ на банкет и простой заказ (в режиме повседневной работы). При заказе на банкет заключается договор об оплате, происходит организация банкета и полная отчетность о банкете. При простом заказе происходит обслуживание клиента и ежедневная отчетность. Создадим диаграмму декомпозиции Деятельность основная» в методологии IDEF0(рис.3).
Рис. 3 Диаграмма декомпозиции «Деятельность основная» IDEF0.
2. Создание модели в стандарте DFD
DFD — общепринятое сокращение от англ. Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.
Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML.
Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.
Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием). Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.
Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.[3][4]
При заказе банкета происходит проверка: свободен ли ресторан в запрашиваемую клиентом дату и вместит ли он необходимое количество человек. Если она прошла успешно, происходит внесение заказа. Вносится информация о клиенте, дата банкета и количество человек. На выходе мы получаем информацию о банкете и договор об оплате. Здесь целесообразно использовать стандарт DFD.
На основании выходных данных с Внесения заказа (рис.4) формируется Договор об оплате(рис.5). Он состоит из суммы к оплате, процента предоплаты, даты предоплаты и контактной информации о клиенте.
Рис. 4 Диаграмма декомпозиции Рис. 5 Диаграмма декомпозиции «Договор
«Заказ банкета» DFD об оплате» DFD
Организация банкета происходит следующим образом: сначала согласуются все детали с клиентом, затем зал оформляется для банкета и закрывается для других посетителей. Также производится расчет и закупка необходимых продуктов и напитков и приготовление блюд. С началом банкета происходит обслуживание гостей и после банкета уборка зала. Здесь снова используем стандарт IDEF0 (рис.6).
Рис. 6 Диаграмма декомпозиции «Организация банкета» IDEF0.
3. Создание модели в стандарте IDEF3.
IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. Система описывается как упорядоченная последовательность событий с одновременным описанием объектов, имеющих отношение к моделируемому процессу.
IDEF3 состоит из двух методов: Process Flow Description (PFD) — Описание технологических процессов, с указанием того, что происходит на каждом этапе технологического процесса; Object State Transition Description (OSTD) — описание переходов состояний объектов, с указанием того, какие существуют промежуточные состояния у объектов в моделируемой системе.
Основу методологии IDEF3 составляет графический язык описания процессов. Модель в нотации IDEF3 может содержать два типа диаграмм: диаграмму Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) и диаграмму Сети Трансформаций Состояния Объекта (Object State Transition Network, OSTN). [3][4]
Рис. 7 Диаграмма декомпозиции «Согласование с клиентом»IDEF3.
При согласовании заказа на банкет с клиентом необходимо выяснить дату банкета, количество человек. Клиент также должен выбрать из меню блюда для банкета. Он может потребовать особенного оформления зала или еще какие-либо дополнительные требования. После того, как все согласовано, заключается договор об оплате. Используем при этом стандарт IDEF3(рис.7).
При работе в повседневном режиме происходит следующее: клиента обслуживают и принимают у него заказ. Затем официант сообщает заказ на кухню или бармену, заказ приготавливается, и официант относит готовый заказ клиенту. После необходимо рассчитать клиента.
Рис. 8 Диаграмма декомпозиции «Работа в повседневном режиме» IDEF0.
При поступлении клиента его необходимо встретить, проводить до столика и дать время сделать заказ, принять заказ и передать его на приготовление(рис.9).
Рис. 9 Диаграмма декомпозиции «Обслуживание клиента»IDEF3.
Для приготовления заказа в повседневном режиме необходимо заранее рассчитать и закупить нужное количество продуктов и напитков для меню, сделать заготовки блюд, если это возможно. И непосредственно при получении заказа на кухню или бармену приготовить его. Отразим это на диаграмме декомпозиции в стандарте IDEF0(рис.10).
Рис. 10 Диаграмма декомпозиции «Приготовление заказа» IDEF0.
После того, как заказ приготовится, его нужно подать клиенту, а также поинтересоваться у него, не требуется ли ему что-либо еще. По просьбе клиента, его необходимо рассчитать и обязательно выдать сдачу. После того, как клиент покинет столик, его нужно убрать и сервировать заново для новых клиентов (рис.11).
Рис. 11 Диаграмма декомпозиции «Расчет клиента»IDEF3.
В основную деятельность компании входит сбор документов о банкетах и документов о ежедневной работе. Для документов о банкетах берется информация о банкете из внесения заказа. На основе этих документов строится БД банкетов. А на основе ежедневной отчетности стоится БД заказов, так же в документы ежедневной работы входит информация из БД сотрудников и состояний меню (рис.12).
Рис. 12 Диаграмма декомпозиции «Сбор документов» DFD.
Перейдем к проектированию поддерживающей деятельности. Сотрудники обеспечивающего штаба получают заявки от сотрудников основного штаба и устраняют проблемы. Для декомпозиции воспользуемся стандартом IDEF0 (рис.13), а на рис 14 приведен список полученных диаграмм.
Рис. 13 Диаграмма декомпозиции Рис. 14. Список диаграмм
Таким образом, для при проектировании ИС разработана модель «TO-BE» с помощью средств BPWin. При разработке в BPWin диаграммы были построены согласно всем трем стандартам(IDEF0, IDEF3, DFD) и были продекомпозированы до четвертого уровня. В результате получено 7 диаграмм декомпозиций в стандарте IDEF0, 3 в стандарте IDEF3 и 3 в стандарте DFD.
Список источников и литературы.
1. Курс лекций по дисциплине «Проектирование Информационных Систем».
2. Федотова Д., Семенов Ю., Чижик К., «CASE-технологии. Практикум», 2005 г
3. Сайт «Википедия» http://ru.wikipedia.org.
4. Описание продукта AllFusion Process Modeler7 (BPwin), сайт «Internet and software company» http://www.interface.ru
5. Вендров А.М. «CASE-технологии: Современные методы и средства проектирования информационных систем», 1998.
Источник: scienceforum.ru
