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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ

Государственное образовательное учреждение высшего профессионального образования

МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ

ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Кафедра математической кибернетики и информационных технологий

Проектирование информационной системы

ООО экскурсионная фирма «Сто путей»

Курсовая работа

Выполнила:

Сушевская Ирина Сергеевна

Научный руководитель:

д.ф.-м.н., профессор Воронова Лилия Ивановна

Москва, 2012 г.

Введение

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

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

Целью данной работы является разработка бизнес-модели экскурсионной фирмы «Сто путей» и разработка модели её бизнес-процессов c использованием профессиональных систем бизнес-моделирования ОРГ-МАСТЕР и CASE-средств.

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

· Модель бизнес-процессов "как есть" («as is») - модель бизнес-процессов, построенная на основе видения существующего в организации потока работ.

· Модель "как должно быть" («to be») - модель бизнес-процесса, построенная на основе видения перспективной структуры процесса и удовлетворяющая требованиям по целевым значениям показателей эффективности.

· Моделирование сверху-вниз - формирование модели бизнес-процессов от укрупненных до детальных при помощи декомпозиции.

· Моделирование снизу-вверх - формирование укрупненных бизнес-процессов путем агрегирования детальных процессов.

Задача данной работы:

· провести системный анализ предметной области предприятия, ведущего экскурсионную деятельность;

· провести обзор профессиональной системы бизнес-моделирования ОРГ-МАСТЕР;

· разработать «AS-IS» бизнес-модель экскурсионной фирмы

· провести обзор CASE-технологий, использование которых возможно для разработки бизнес-процессов предприятия и обосновать выбор CASE-средства;

· осуществить разработку «TO-BE» модели бизнес-процессов экскурсионной фирмы, интеграция базы данных.

Глава 1. Моделирование деятельности экскурсионной фирмы «Сто путей» в профессиональной системе бизнес-моделирования ОРГ-МАСТЕР

1.1 Системный анализ предметной области предприятия, ведущего экскурсионную деятельность

Фирма «Сто путей» собирается выйти на российский рынок экскурсионных услуг. Сотрудники фирмы - молодые перспективные специалисты. Многие экскурсоводы являются дипломированными специалистами в области всемирной и отечественной истории.

У фирмы есть генеральный директор, который возглавляет множество отделов, у отделов есть так же свои сотрудники: руководитель отдела и его подчинённые. экскурсионный бизнес моделирование профессиональный

Представим организационную структуру объекта автоматизации на рисунке 1.1.



Рис. 1.1 Организационная структура экскурсионной фирмы

Деятельность экскурсионной фирмы можно охарактеризовать в два этапа:

Подготовка к экскурсии:

· подбор и анализ материалов для экскурсии;

· подбор экскурсионных объектов;

· подбор транспорта;

Разработка экскурсии:

· cоставление экскурсионного маршрута;

· обработка фактического материала;

· создание содержания экскурсии;

· подбор методики проведения экскурсионного мероприятия.

1.2 Обзор профессиональной системы бизнес-моделирования ОРГ-МАСТЕР®

ОРГ-МАСТЕР® -- это система бизнес-моделирования нового поколения, обладающая уникальными возможностями по описанию и оптимизации деятельности компаний и групп.

ОРГ-МАСТЕР® относится к средствам моделирования корпоративной архитектуры (Enterprise Architecture Modeling Tool), т.е. моделирования организационного устройства компании на всех уровнях, выпуска организационных регламентов, настройки информационных систем.

Система ОРГ-МАСТЕР® создает архитектурное описание компании: от корпоративных стратегических целей до систем, структур, процессов. Именно целостное описание организации, где каждое решение вытекает из принятых ранее, и позволяет добиться оптимальной конструкции компании, а, следовательно, и достижения максимальной ее эффективности

Комплекты поставки комплекса ОРГ-МАСТЕР® рассчитаны на создание моделей разной степени сложности, которая зависит в первую очередь от размера организации, а также определяется детальностью описания ее деятельности.

ОРГ-МАСТЕР®Лайт - ориентирован, прежде всего, на моделирование деятельности небольших организаций, которые с его помощью могут создать полноценное описание своей деятельности и сформировать необходимые организационные регламенты.

Модели, применяемые в ОРГ-Мастере для описания бизнес-систем и протекающих в них процессов, используют следующие основные компоненты.

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

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

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

· Составные проекции - проекции (в терминах БИГ), получаемые посредством проекции (в терминах операций реляционной алгебры) на первую и последнюю компоненты соединения двух простых проекций R1 и R2 , по равенству второго столбца проекции R1 и первого столбца проекции R2, домены которых совпадают.

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

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

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

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

1.3. Разработка AS-IS бизнес-модели экскурсионной фирмы

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

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

Рис. 1.2. Обобщенная схема организационного бизнес-моделирования

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

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

Результаты определения миссии предприятия (в соответствие с обобщенной схемой организационного моделирования, рис. 1.2.) заносятся в классификатор «Миссия и цели». Миссию можно считать бизнес-потенциалом для данной фирмы, т.к. не рассматривается взаимодействие с поставщиками и клиентами, но определён набор видов коммерческой деятельности. Данные из классификатора «Миссия и цели» представлены на рис. 1.3. На основании миссии и целей фирмы можно определить её организационную структуру, которая описывается в классификаторе «Организационно-ролевая структура».

Рис. 1.3. Классификатор «Миссия и цели»

Данные, которые содержит классификатор, отображены на рис. 1.4.

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

Рис. 1.4. Классификатор «Организационно-ролевая структура»

После определения организационно-ролевой структуры создается классификатор «Функции». В нем определяется функционал фирмы, необходимый для поддержания коммерческой деятельности. Классификатор «Функции» представлен на рис. 1.5.

Создаём классификатор «Ресурсы», в который включены основные и вспомогательные ресурсы (рис. 1.8.).

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

После определения процессов необходимо связать функции с процессами, внутри которых они выполняются. Эти связи вносятся в матричную проекцию «Процессы_функции».

Аналогично создаются классификаторы и соответствующие им матричные проекции: «Сотрудники», «Требования», «Ресурсы», «Виды подчиненности», «Документы и сообщения», «Свойства документов», «Направления деятельности», «Процессы»; а также создаются отчёты.

Перечень классификаторов, матричных проекций и отчетов отображен в списке объектов на рисунке 1.12.

Рис. 1.12. «Список объектов модели»

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

Рис. 1.13. «Полная диаграмма бизнес-модели экскурсионной фирмы «Сто путей».

Выводы

В данной главе проведен системный анализ предметной области «Экскурсионная фирма». В ходе этого анализа перечислены основные структурные схемы компании. Произведен обзор возможностей системы бизнес-моделирования ОРГ-МАСТЕР и выбран метод бизнес-моделирования, который подходит для разработки бизнес-модели в данной системе.

В итоге разработана «AS-IS» бизнес-модель экскурсионной фирмы «Сто путей» перечислены её основные классификаторы, матричные проекции модели и сгенерированы отчёты. Построена полная схема организационной структуры компании.

Разработанная модель содержит:

· 11 классификаторов;

· 8 матричных проекций;

· 4 отчета.

Глава 2. Моделирование бизнес-процессов экскурсионной фирмы

2.1 Обзор CASE-технологий

Для успешной реализации ИС, объект проектирования должен быть адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой квалификации участвующих в ней специалистов. Все это способствует появлению программно-технологических средств специального класса - CASE-средств (Computer Aided Software Engineering), реализующих CASE-технологию создания и сопровождения ИС.

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

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

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

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

· локальные, поддерживающие один-два типа моделей и методов

· малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

· средние интегрированные средства моделирования, поддерживающие от 4 до 10--15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

Рассматриваемые CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния в 1998 году Logic Works с PLATINUM technology они выпускаются под логотипом PLATINUM technology.

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

Rational Rose - CASE-средство фирмы Rational Software Corporation (США), предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанный ими универсальный язык для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder. Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ -позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

2.2. Обзор методологий описания бизнес-процессов

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

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

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

Модель может содержать четыре типа диаграмм :

* контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

* диаграммы декомпозиции;

* диаграммы дерева узлов;

* диаграммы только для экспозиции (FEO).

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

BPwin позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования - DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляю-щими факторами и какие ресурсы для этого необходимы. Нотация IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что сущест-венно облегчает анализ деятельности предприятия. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания доку-ментооборота и обработки информации. Для описания логики взаимо-действия информационных потоков более подходит IDEF3, называемая также workflow diagramming - нотацией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.

2.3 Разработка TO-BE модели бизнес-процессов

В результате обследования предприятия строится функциональная модель существующей организации работы AS-IS (Как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, "кто что сделал" и что каждая единица бизнеса добавляет в процесс. Модель AS-IS позволяет выяснить, "что мы делаем сегодня" перед тем, как перепрыгнуть на то, "что мы будем делать завтра". Внедрение информационной системы неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправ-ляемые и дублирующиеся работы, неэффективный документооборот (нуж-ный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и входу (объекты или информация используются нерационально) и т. д.

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (Как будет) - модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернатив-ных/лучших путей выполнения работы и документирования того, как пред-приятие будет функционировать в будущем. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выби-рается наилучшая (рис. 2). Например, каждая из моделей ТО-ВЕ может соответствовать определенной информационной системе.

Рис. 2. Построение моделей ТО-ВЕ как результат анализа модели AS-IS

Модели AS-IS и ТО-ВЕ позволяют описать начальное и конечное состояние предприятия - до и после внедрения корпоративной информационной сис-темы, оставляя без внимания сам процесс разработки (выбора) и внедрения. Можно с помощью BPwin создать модель этой работы. Модель ТО-ВЕ - это не модель деятельности предприятия, а модель мероприятий по переводу предприятия на новую технологию работы. Используя эту модель можно с помощью стоимостного анализа оценить объем средств, необходимых для приобретения/разработки и внед-рения информационной системы. Такие модели можно построить для пере-хода на различные модели ТО-ВЕ, т. е. для внедрения различных инфор-мационных систем (как готовых, так и созданных на заказ) и выбрать опти-мальный вариант.

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

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

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

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

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

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

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

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

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

Контекстная диаграмма «Процессы компании»

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

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

Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 -- это не элемент управления нижестоящими работами. Работы нижнего уровня -- это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня -- это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) -- коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.

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



Декомпозиция контекстной диаграммы на 3 блока IDEF0: «Маркетинговые исследования», «Управление организацией» и «Реализация услуг».

Декомпозиция блока «Маркетинговые исследования»

Создание диаграммы DFD

Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD - процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища) [4].

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

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

В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.



Декомпозиция «Исследований целевой аудитории» (DFD)

Декомпозиция «Исследований Рынка» (DFD)



Декомпозиция «Управления организацией» (IDEF0)

Создание диаграммы IDEF3

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

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

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

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

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

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

Единицы работы -- Unit of Work (UOW) -- также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы.

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

* Старшая (Precedence) - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

* Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.

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

Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления.

Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. В качестве имени объекта можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны бытьсвязаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок -- безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous).

Наименовани	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процес-сы должны быть запу-щены
Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процес-сы запускаются одно-временно
Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновре-менно
XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

Декомпозиция «Обеспечения производственных процессов» (IDEF3)



Декомпозиция «Реализации услуг» (IDEF3)

Дерево узлов



Выводы

Во второй главе рассмотрены основные характеристики CASE-средств: BPwin и Rational Rose. Выбрана система BPwin в результате анализа. Далее рассмотрены основные методологии BPwin. Разработана модель бизнес-процессов фирмы, произведена декомпозиция отдельных процессов.

Глава 3. Программная реализация

Программная реализация объекта автоматизации «Экскурсионная фирма» произведена в курсовой работе по дисциплине базы данных. Спроектирована и программно реализована база данных (БД) для автоматизации части бизнес-процессов модели TO-BE компании. Выявлены группы пользователей, которые связаны с работой фирмы:

1) администрация

2) сотрудники

3) клиенты

Автоматизации должны быть подвергнуты процессы:

1) Подсчет конечной стоимости услуг

2) Добавление информации администрацией и сотрудниками

3) Изменение необходимой информации

4) Просмотр отчетов

3.1. Инфологическое и даталогическое проектирование БД

На основе информационных объектов предметной области, выделенных в ходе её системного анализа, построена инфологическая модель. Такой моделью является модель «сущность-связь» или ER-модель, основными элементами которой являются сущности. Выделены следующие сущности:

· Клиенты - сущность содержит информацию о клиентах фирмы;

· Сопровождающие - сущность содержит общую информацию о сотрудниках, непосредственно ведущих экскурсионную деятельность;

· Экскурсионные объекты - сущность содержит информацию обо всех экскурсионных объектах, на основе которых составляются сами экскурсии;

· Экскурсии - сущность содержит информацию о уже полностью подготовленных экскурсиях

· Автотранспорт - сущность содержит информацию об автобусах, используемых в экскурсиях;

· Оплата- сущность содержит информацию о состоянии оплаты заказанной экскурсии;

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

Рис. 3.1. Инфологическая модель предметной области «Экскурсионная фирма»

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

Клиенты Client

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
ФИО клиента		ClientName	VARCHAR(80)	NOT NULL
№ паспорта		ClientID (PK)	VARCHAR(20)	NOT NULL
Номер телефона		ClientPhone	INT	NULL

Список экскурсий TripObject

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Объект экскурсии		TripObject Object (PK)	VARCHAR(200)	NOT NULL
Цена		TripObjectPrice	INT	NOT NULL
Описание		TripObjectDescribe	VARCHAR(200)	NOT NULL
Врем начала экскурсии		IdTripObject StartTime	DATETIME	NOT NULL
Время окончании экскурсии		IdTripObject EndTime	DATETIME	NOT NULL

Договор Trip

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Номер серии паспорта заказчика		ClientID (FK)	VARCHAR(20)	NOT NULL
Объект экскурсии		TripObject Object (FK)	VARCHAR(200)	NOT NULL
Номер договора		TripIdDogovor	VARCHAR(80)	NOT NULL
Сопровождающий		ClientSoprovogd (FK)	VARCHAR(80)	NOT NULL
Номер автотранспорта		TripBus (FK)	INT	NOT NULL
Дата		CollectedMoney	DATETIME	NOT NULL
Язык		ClientLanguage	VARCHAR(20)	NOT NULL

Сопровождающие Employees

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
ФИО;		EmployeeName	VARCHAR(70)	NOT NULL
Номер паспорта;		IdEmployee(PK)	INT	NOT NULL
Телефон;		EmployeePhone	VARCHAR(8)	NULL
Должность;		EmployeeFunction	VARCHAR(20)	NOT NULL
Язык		EmployeeLanguage	VARCHAR(20)	NOT NULL

Автобусы Bus

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Номер автобуса		IdBus(PK)	INT	NOT NULL
Количество мест		BusInspectionDate	INT	NOT NULL
Марка автомобиля		BusMileage	VARCHAR(20)	NOT NULL
Наличие грузового отсека		BusLuggage	VARCHAR(20)	NOT NULL
Наличие Микрофона		BusMicrophone	VARCHAR(20)	NOT NULL

Оплата Pay

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Номер договора		TripIdDogovor	VARCHAR(80)	NOT NULL
Состояние оплаты		TripPay	VARCHAR(20)	NOT NULL
Вид оплаты		TripPayKind	VARCHAR(20)	NOT NULL

Рис.3.2. Даталогическая модель

При переходе от инфологической модели к реляционной были раскрыты связи М:М. Между отношениями «Договор» и «Сопровождающий», отношением-связкой в данном случае стало отношение «Экскурсоводы».

На основе проделанной работы построена даталогическая модель (Рис. 3.2).

Представленная схема является нормализованной до третьей нормальной формы (3НФ), так как не содержит неполных и транзитивных функциональных зависимостей.

3.2. Физическое проектирование в СУБД и реализация ПО

Для программной реализации информационной системы выбрана СУБД SQL. Эта СУБД распространяется под GNU General Public License или под собственной коммерческой лицензией. SQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, PureBasic, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

C# - объектно-ориентированный язык программирования. Разработан в 1998 - 2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нем можно создавать и компилировать даже без инструментальных средств, вроде Visual Studio.

C# относиться к семье языков с С-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов(в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщенные типы и методы, итераторы, анонимные функции с поддержкой замыканий, исключения, комментарии в формате XML.

Выводы

В качестве программной реализации разработана база данных для автоматизации бизнес-процессов TO-BE модели экскурсионной фирмы «Сто путей»

Для реализации базы данных выбрана выбрана SQL. Формы и отчеты созданы в среде разработки Visual C# на языке C#.

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

С. В. Маклаков «Моделирование бизнес-процессов с BPwin 4.0»

http://bigc.ru/

М.Н. Пущин «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ»

http://gendocs.ru

Размещено на Allbest.ru

...