close

Вход

Забыли?

вход по аккаунту

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

код для вставки
министЕрство оБрАзовАниrI и нАуки российской ФрдЕрАIд4и
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИrI
(ОРJlОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
имени И.С.
ТУРГЕНЕВА)
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ
РАБОТА
по направлению подготовки: 09,04.03 Прикладная информатика
наПравленность (профиль): Приклалная информатика в аналитической экономике
Мlагистранта: Снегиревой Татьяны Сергеевны, шифр 150783
Факул ьтет : физико-математичес кий
Тема выпускной квалификационной работы
РАЗРАБОТКА ИНФОР]ЧIАЦИОННОЙ СИСТЕМЫ ТУРИСТИЧЕСКОГО
АГЕНТСТВА: ИНТЕРАКТИВНАЯ lVIОДЕЛЬ И ПРОЕКТИРОВАНИЕ
ч
(поdпuсь)
Орёл 2011
2
СОДЕРЖАНИЕ
Содержание
Введение ................................................................................................................... 3
Глава 1. Моделирование сложных систем............................................................ 6
1.1 Проблема управления сложными системами.............................................. 6
1.2 Обзор моделей системной динамики ......................................................... 13
1.3 Моделирование стратегических решений с помощью системной
динамики ............................................................................................................. 19
Глава 2. Проектирование информационной системы ....................................... 27
2.1 Анализ требований к системе ..................................................................... 27
2.2 Детальное проектирование ......................................................................... 35
2.3 Алгоритмическое обеспечение ................................................................... 46
2.4 Расчет временной продолжительности проекта ....................................... 48
2.5 Финансовый анализ стоимости информационной системы
турагентства ........................................................................................................ 53
Заключение ............................................................................................................ 58
СПИСОК ЛИТЕРАТУРЫ..................................................................................... 60
3
Введение
Проблема выбора при принятии решений присутствует абсолютно во
всех сферах деятельности современного человека. При этом принимаемое
решение должно быть наилучшем из представленных альтернатив, поэтому
все факторы и детали, которые могут влиять на выбор в принятии решения,
рассматриваются как сложная система. Также процесс принятия решения затрудняет то, что любую сложную систему необходимо исследовать в динамике с учетом поведенческих аспектов. Туристическое агентство является
сложной системой, при принятии решения требуется учитывать множество
факторов, что обуславливает необходимость построения модуля поддержки
принятия решения.
Также для поддержания конкурентоспособности туристические фирмы
должны постоянно повышать качество обслуживания клиентов, что невозможно без разработки, внедрения и функционирования современных систем
автоматизации. Использование автоматизированных информационных систем способно значительно упростить работу, повысив производительность
труда путем перекладывания рутинных обязанностей с персонала на компьютер. Таким образом, проблема создания автоматизированной информационной системы (АИС) туристической фирмы достаточно актуальна.
Проблеме моделирования поведения сложных систем посвящены работы многих зарубежных и отечественных исследователей. Среди зарубежных
в первую очередь следует выделить работу Дж. Форрестера, посвященную
применению аппарата системной динамики для моделирования развития таких сложных социально-экономических систем, как город и предприятие.
Среди
отечественных
исследователей
можно
выделить
работы
Н.П. Бусленко, Н.Н. Лычкиной, Д.Ю. Каталевского.
Объектом исследования выпускной квалификационной работы является деятельность туристического агентства.
4
Предмет исследования составляют технологии моделирования поведения сложных систем, а также технологии проектирования программного
обеспечения.
Целью выпускной квалификационной работы является проектирование
информационной системы сопровождения деятельности туристического
агентства и построение интерактивной модели принятия решения.
Для достижения заданной цели требуется решить ряд задач:
1. Изучить наиболее распространенные методологические подходы
к моделированию сложных систем;
2. Провести критический обзор моделей системной динамики, подходящих для определения стратегии развития экономической
системы;
3. Построить модель системной динамики, описывающую туристическое агентство;
4. Разработать проектную документацию на создание информационной системы сопровождения деятельности туристического
агентства.
В ходе выполнения выпускной квалификационной работы принимались следующие теоретические методы: методы системной динамики, финансового планирования, проектирования информационных систем (нотации
IDEF0, IDEF3, BPMN, UML).
Для получения экономических данных и их последующей обработки
использовались технологии экспертного оценивания и технологии построения причинно-следственных диаграмм.
Теоретическая значимость выпускной квалификационной работы состоит в построении новой модели, описывающей различные сценарии развития туристического агентства.
Практическая значимость работы заключается в подготовленной проектной документации на создание информационной системы сопровождения
деятельности туристического агентства.
5
Структура выпускной квалификационной работы построена в соответствии с целью и задачами, указанными выше, и состоит из введения, двух
глав, заключения и списка литературы.
Во введении обосновывается актуальность выбранной тематики, сформулирована цель и основные задачи, приводится теоретическая и практическая значимость и структура выпускной квалификационной работы.
В первой главе рассматривается понятие сложной системы, методы построения моделей сложных систем, приводится анализ существующих моделей, а также представляется модель системной динамики, учитывающая факторы, влияющие на деятельность турагентства.
Вторая глава содержит проектирование информационной системы в
нотации языка UML и BPMN, построение модуля поддержки принятия решений с помощью продукционных правил. Также выделены работы по созданию программного обеспечения и время их исполнения, рассчитана общая
сумма стоимости информационной системы для туристического агентства.
Заключение представляет собой обобщение основных результатов проделанной работы.
Список литературы содержит список источников, используемых при
написании работы.
6
Глава 1. Моделирование сложных систем
1.1 Проблема управления сложными системами
Термин «система» появился в научной литературе давно и является
фактически неопределенным. Наиболее широко этот термин использовался в
механике, где обозначал материальную систему, то есть совокупность точек,
подчиненных определенным связям.
Впоследствии ученые приступили к исследованию сложных систем,
динамика которых во многом зависит от человека, и принимаемых им решений. Процессы, протекающие в сложных системах, описываются большим
числом параметров, соответствующие уравнения и соотношения, как правило, аналитически разрешены быть не могут. Эти системы уникальны, то есть
даже аналогичные по назначению системы имеют ярко выраженные специфические свойства, во многом определяющие их поведение [1].
Продолжительность экспериментов с такими системами обычно велика, а иногда вообще недопустимо. К тому же, практически невозможно ставить численные опыты – системы приходится изучать во всем многообразии
действующих факторов.
Сложная система имеет следующие характерные особенности [20]:
 уникальность. Существующие аналоги объектов заметно отличаются друг от друга. Следствием этого на практике является необходимость строить новые модели;
 слабая структурированность теоретических и фактических знаний о системе. Так как изучаемые системы уникальны, то процесс накопления и систематизации знаний о них затруднен. Слабо изучены сами процессы. При идентификации сложных систем
присутствует большая доля субъективных экспертных знаний о
системе;
7
 составной характер системы. Сложные системы не сводится к
простой совокупности элементов, расчленяя систему на отдельные части, изучая каждую из них в отдельности, нельзя познать
свойства системы в целом. Поэтому описание отдельных подсистем необходимо выполнять с учетом их места во всей системе в
целом, и наоборот, система в целом исследуется исходя из
свойств отдельных подсистем. Одну из основных черт сложных
систем составляет взаимодействие выделенных подсистем. Необходимо учитывать результат воздействия одной подсистемы на
другую и их взаимодействие с внешней средой. Расчленение
сложной системы на подсистемы зависит от целей создания системы, приняты технических решений и взглядов исследователя
на нее;
 разнородность подсистем и элементов, составляющих систему.
Это определяется и многообразием природы (физической разнородностью подсистем, имеющих различную природу), и разнородностью математических схем, описывающих функционирование различных элементов, а также одних и тех же элементов на
различных уровнях изучения;
 случайность и неопределенность факторов, действующих в системе. Учет этих факторов приводит к резкому усложнению задач
и увеличивает трудоемкость исследований (необходимость получения представительного набора данных);
 многокритериальность оценок процессов, протекающих в системе. Невозможность однозначной оценки (выбора единого обобщенного критерия) диктуется следующими обстоятельствами:
наличием множества подсистем, каждая из которых имеет свои
цели, оценивается по своим локальным критериям; множественностью показателей (иногда противоречивых, – в этом случае,
выбирается компромиссный вариант), характеризующих работу
8
всей системы; наличием неформализуемых критериев, используемых при принятии решений, основанных на практическом
опыте лиц, принимающих решение;
 процесс исследования системы носит итерационный характер.
Исходная модель усложняется путем детализации. Однако создание полной модели сложной системы бесполезно, т.к. она будет
столь же сложна в изучении, как и система. Следствием этого является необходимость использования ансамбля (комплекса) моделей при анализе системы. Различные модели могут отражать
как разные стороны функционирования системы, так и разные
уровни отображения исследователем одних и тех же процессов.
Также любую сложную систему необходимо исследовать в динамике с
учетом поведенческих аспектов, что затрудняет процесс управления системой.
Современная экономическая реальность такова, что лицо, принимающее решение, вынуждено принимать решения, действуя в рамках сложной и
быстроменяющейся окружающей среды. С конца 1970-х гг. исследователями
был введен в оборот термин «принятие решений в динамической среде», который, как принято считать, наиболее полно охарактеризовал Б. Бремер. Согласно исследователю, для ситуации принятия решений в динамически
сложной среде характерно следующее [15]:
 необходимость принять несколько решений для достижения поставленной цели, каждое из которых должно рассматриваться в
контексте остальных решений;
 принимаемые решения не являются независимыми: каждое последующее решение ограничено последствиями принятых ранее
и в свою очередь накладывает ограничения на последующие решения;
 среда принятия решений изменяется как сама по себе, так и
вследствие принимаемых решений;
9
 решения принимаются в реальном времени (т.е. непосредственно
в процессе изменения среды принятия решений).
Принятие решений в динамической среде характерно для таких распространенных явлений, как, например, выбор маршрута при движении автомобиля, инвестирование на фондовом рынке в условиях высокой волатильности
цен, командование армией в ходе боя, диспетчерский контроль за авиаперевозками, управление поставками и логистикой и т.п. Согласно Бремеру, исследования в этих областях и дали толчок развитию этой области.
При моделировании поведения сложной системы следует учитывать
поведение окружающих эту систему объектов. В литературе [16] подобный
методологический подход принято называть стейкхолдерским. В данном
подходе действия конкретной системы зависят от множества практически не
связанных между собой заинтересованных лиц, таких, как потребители, поставщики, акционеры, управляющие, работники и др. Например, поставщики
фирмы являются стейкхолдерами, так как влияют на стоимость сырья, на
сроки и условия поставки, что напрямую связано с издержками любой компании. Посредники фирмы относятся к стейкхолдерам, так как могут влиять
на затраты компании (например, исследовательские и рекламные агентства).
Между стейкхолдерами также могут существовать различные отношения, которые не всегда носят характер сотрудничества, совпадения интересов, а могут быть и конкурентными. Решения принимаются с учетом этих
разнонаправленных интересов, при этом каждый из стейкхолдеров имеет определенные права на контроль над фирмой.
Рассмотренные выше особенности исследования сложных систем обуславливают потребность в специальных способах построения и анализа моделей сложных систем.
Моделирование представляет собой один из основных методов познания, является формой отражения действительности и заключается в выяснении или воспроизведении тех или иных свойств реальных объектов, предметов и явлений с помощью других объектов, процессов, явлений, либо с по-
10
мощью абстрактного описания в виде изображения, плана, карты, совокупности уравнений, алгоритмов и программ [20].
В процессе моделирования всегда существует оригинал (объект) и модель, которая воспроизводит (моделирует, описывает, имитирует) некоторые
черты объекта.
Исследуя современные сложные системы, человечество придумало
различные классы моделей. Развитие информационных технологий можно в
известном смысле интерпретировать как возможность реализации моделей
различного вида в рамках информационных систем различного назначения:
Информационные системы, Системы распознавания образов, Системы искусственного интеллекта, Системы поддержки принятия решений. В основе
этих систем лежат модели различных типов: семантические, логические, математические и т.п.
Приведем общую классификацию основных видов моделирования:
 концептуальное моделирование – представление системы с помощью специальных знаков, символов, операций над ними или с
помощью естественных или искусственных языков,
 физическое моделирование – моделируемый объект или процесс
воспроизводится исходя из соотношения подобия, вытекающего
из схожести физических явлений;
 структурно-функциональное – моделями являются схемы (блоксхемы), графики, диаграммы, таблицы, рисунки со специальными
правилами их объединения и преобразования;
 математическое моделирование – построение модели осуществляется средствами математики и логики;
 имитационное (программное) моделирование – при котором логико-математическая модель исследуемой системы представляет
собой
алгоритм
функционирования
реализуемый на компьютере.
системы,
программно-
11
Указанные виды моделирования могут применяться самостоятельно
или одновременно, в некоторой комбинации.
Компьютерное моделирование – метод решения задач анализа или синтеза сложной системы на основе использования ее компьютерной модели.
К компьютерному моделированию относят:
• структурно-функциональное,
• имитационное.
Под термином «компьютерная модель», чаще всего понимают:
 условный образ объекта или некоторой системы объектов (или
процессов), описанный с помощью взаимосвязанных компьютерных таблиц, блок-схем, диаграмм, графиков, рисунков, анимационных фрагментов, гипертекстов и т.д. и отображающих структуру и взаимосвязи между элементами объекта. Компьютерные модели такого вида называются структурно-функциональными;
 отдельную программу (совокупность программ, программный
комплекс) позволяющий с помощью последовательности вычислений и графического отображения их результатов, воспроизводить (имитировать) процессы функционирования объекта, системы объектов при условии воздействия на объект различных, как
правило, случайных факторов. Такие модели называются имитационными.
Суть компьютерного моделирования заключена в получении количественных и качественных результатов на имеющейся модели. Качественные
результаты анализа обнаруживают неизвестные ранее свойства сложной системы: ее структуру, динамику развития, устойчивость, целостность и др. Количественные выводы в основном носят характер анализа существующей
сложной системы или прогноза будущих значений некоторых переменных.
Методологией компьютерного моделирования является системный
анализ (направление кибернетики, общая теория систем). Центральной процедурой системного анализа является построение обобщенной модели, отра-
12
жающей все факторы и взаимосвязи реальной системы. Предметом компьютерного моделирования может быть любая сложная система, любой объект
или процесс. Категории целей при этом могут быть самыми различными.
Компьютерная модель должна отражать все свойства, основные факторы и
взаимосвязи реальной сложной системы, критерии, ограничения. Компьютерное моделирование сегодня предлагает совокупность методологических
подходов и развитых технологических средств, используемых для подготовки и принятия решений экономического, организационного и социального
или технического характера.
Эффективный метод анализа динамики сложных систем был предложен в Массачусетском технологическом институте профессором Дж. Форрестером. Первоначально метод был известен как «индустриальная динамика»
и применялся исключительно для изучения проблем управления в производстве. Спустя некоторое время это название перестало соответствовать содержанию, так как применение метода оказалось гораздо шире. Он оказался эффективен и для решения других проблем, например, связанных с городской
динамикой, управлением ресурсами, распространением болезней и так далее.
В связи с тем, что данный метод может применяться для моделирования и
изучения практически любых сложных систем, он был назван системной динамикой.
Системная динамика является одним из наиболее мощных инструментов, используемых в настоящее время для анализа, проектирования и моделирования сложных систем [18].
Системная динамика направлена на изучении не самих систем, а задач,
связанных с этими системами. Главными особенностями таких систем является то, что они динамические (изменяющиеся во времени), содержат петли
обратной связи, а также их структура характеризуется задержками, нелинейностью и переменчивостью причин сложного поведения.
Необходимость в динамическом моделировании обусловлена возникновением новых научно-технических проблем (в частности, проблем совер-
13
шенствования организационного управления), что сопровождается ростом
требований к средствам моделирования.
Системную динамику наиболее эффективно использовать при решении
следующих задач:

исследование сложных систем, с целью выявления причинно-
следственных связей;

прогнозирование последствий изменения стратегий управления
сложной системой;

обучение
специалистов
работе
со
сложными
природно-
техническими комплексами.
Используя этот метод, Дж. Форрестеру удалось выявить фундаментальные закономерности развития сложных социальных систем. Показать
связь таких параметров мировой системы, как численность населения, потребление ресурсов, выработка загрязнений и других.
1.2 Обзор моделей системной динамики
В конце 1970-х – начале 1980-х гг. многие исследования в области принятия решений основывались на проведении экспериментов в рамках статичных систем. Однако со временем выводы таких исследований были подвергнуты критике, и возникла необходимость в проведении экспериментов в области принятия решений в динамических системах. Появились исследования,
в которых испытуемые должны были принимать решения в экспериментальных системах, включавших в себя обратную связь, эффекты запаздывания во
времени и нелинейное поведение. Это стало возможным благодаря использованию компьютерных имитационных моделей [15].
Краткий обзор некоторых классических исследований в данной области представлен ниже.
1. Исследования Д. Дёрнера. Эксперимент проводился в рамках компьютерной имитационной модели небольшого города. Испытуемые получали
14
роль мэра города на десятилетний период для управления городским производством, налогообложением, системой городского образования и т. п.
В ходе исследования установлено, что хотя некоторые люди и преуспевали, большинство участников эксперимента показывали относительно низкие результаты. По мнению Д. Дёрнера, низкие результаты большинства участников были обусловлены тремя основными причинам:
 испытуемые концентрировались на текущих проблемах и не понимали процессов, которые задавали важные тенденции развития,
 испытуемые не успевали эффективно действовать в условиях быстрого роста, вызванного позитивной обратной связью (например, когда система начинает меняться в неблагоприятную сторону, что-либо предпринять уже сложно — соответствующие шаги
следовало делать ранее, когда предпосылки развития негативного
сценария только формировались).
 участники эксперимента действовали исходя из убежденности в
линейной и прямой зависимости причины и следствия, не принимая во внимание возможные негативные последствия от принятых решений на другие переменные системы управления городом
(недооценка сложности и взаимосвязанности параметров системы).
Описанный выше набор ошибок, названный «логикой неудачи», характерен практически для любого человека при первых попытках управления
сложными системами (крупная организация, городское хозяйство, экономика
страны и т. п.).
2. Исследования Дж. Стермана. В основе эксперимента лежала имитационная компьютерная модель экономики, в которой испытуемые принимали
решение относительно распределения инвестиций в производство определенного товара. Участники эксперимента играли роль управляющих произ-
15
водством, в функции которых входил контроль за системой производства посредством получения и распределения заказов на товар.
В результате исследований Дж. Стерман выявил, что в среднем участники эксперимента были очень далеки от принятия эффективных решений.
Пытаясь достичь целей имитации (удовлетворить спрос на товар), испытуемые добивались этого с издержками, более чем в тридцать раз превышающими оптимум. Согласно Дж. Стерману, подобная неэффективность принятия решений объяснялась двумя причинами: во-первых, непониманием и недооценкой эффекта запаздывания в системе (между размещением заказов потребителеми получением их на производстве) и, во-вторых, недопониманием
эффекта обратной связи.
3. Исследования Б. Бремера. В основе эксперимента лежала имитационная компьютерная модель системы пожаротушения. Задание для испытуемых заключалось в управлении командами пожарников для минимизации
случаев возгорания и территории пожаров. Имитационная модель была достаточно сложной, основывалась на действии нескольких петель обратной
связи. Согласно Б. Бремеру, после первой попытки управления системой эффективность испытуемых в среднем была в 8,5 раз ниже оптимальной.
4. Исследования Д. Кляйнмунтца и Дж. Томаса. Эксперимент основывался на имитационной компьютерной модели системы медицинского управления. Участники эксперимента играли роль доктора, который должен был
подобрать систему диагностики болезни и ее лечения нескольким пациентам.
Модель была очень динамичной: здоровье пациентов быстро ухудшалось в
случае, если они не получали нужного лечения. Неправильное лечение или
же задержка в оказании помощи приводили к смерти пациента. Риск того,
что предлагаемое лечение приведет к смерти пациента, распределялся статистически. Посредством эксперимента удалось установить, что в ситуации высокого риска стратегия значительного использования средств диагностики
была оправданна. В ситуациях же низкого риска стратегия быстрого подбора
16
пациентам определенного типа лечения без затянутых процедур диагностики
была наиболее оптимальной.
Исследователи отмечали, что участникам эксперимента было трудно
выявить и применить оптимальную стратегию в зависимости от ситуации и
степени
риска
в
быстроменяющейся
сложной
обстановке.
Соглас-
но Кляйнмунтцу и Томасу, наблюдался также эффект от кривой обучения:
примерно после тридцати попыток участники эксперимента меньше пользовались диагностикой и им требовалось меньше времени для того, чтобы вылечить пациента, хотя доля вылечившихся при этом возрастала незначительно.
5. Исследования Д. Броадбента и Б. Астона. Эксперимент основывался
на эконометрической модели экономики Великобритании. Участники эксперимента, работая в командах по 11 человек каждая, периодически принимали
решения по поводу трех контрольных переменных — государственных расходов, уровня налогообложения и количества денежной массы в обращении.
Система была относительно сложной. Помимо неочевидных причинноследственных связей между переменными присутствовал также эффект запаздывания: увеличение государственных расходов спустя определенный
промежуток времени вызывало инфляцию.
Одно из заданий заключалось в прогнозировании влияния их решений
на уровень инфляции и безработицы. Со временем участникам эксперимента
удалось научиться сравнительно точно предсказывать уровень безработицы.
Однако прогнозы испытуемых относительно инфляции так и остались неточными. Исследователи считали, что участникам эксперимента так и не удалось добиться точности в данной области вследствие запаздывания – существовал длительный промежуток времени между влиянием контрольных переменных на инфляцию и проявлением этого эффекта.
В литературе известно много работ, в которых рассматривалась деятельность крупных фирм с точки зрения причинно-следственных связей. Например, в своей книге Д. Ю. Каталевский рассматривал с помощью систем-
17
ной динамики компанию «Евросеть». «Евросеть» – крупнейшая российская
торговая сеть по продажам оборудования и услуг сотовой связи. Основана
была в 1997 г., в период с 1999 г. по 2008 г. произошел стремительный рост
компании.
С помощью системной динамики было выявлено, что главными показателями роста для компании «Евросеть» стали:
 развитие сети дистрибуции (компания агрессивно наращивала
количество салонов связи);
 ориентация на политику низких цен (позиционировала себя
фирма как компания-дискаунтер, взяла ориентацию на «массового покупателя», снизила торговую наценку);
 повышение осведомленности от агрессивной рекламы и эпатажных PR-акций (способствовали росту узнаваемости бренда);
 поглощение конкурентов (компания так выросла, что фактически
стала монополистом);
 уровень обслуживания (фирма уделяла много внимания на подготовку персонала, работал специальный центр подготовки новых сотрудников).
Возрастающая отдача от использования нескольких показателей роста
позволила Евросети добиться высокой «рыночной власти» над пользователями и контрагентами (поставщиками), реализовав на практике эффекты зависимости от предыдущей траектории развития и блокировки рынка. За счет
этого Евросеть смогла существенно повысить барьеры на вход для своих
конкурентов и завоевать значительную долю рынка.
А. А. Кугаенко рассматривал методы динамического моделирования и
управления социально-экономическими объектами.
Управление социально-экономическими объектами обусловлено наличием большого числа взаимно влияющих факторов и обратных связей. Поэтому умение ориентироваться в сложной изменяющейся обстановке требует
формирования определенных навыков. Отсюда возникает необходимость
18
внедрения динамических тренажеров. С помощью экономического тренажера
за короткое время можно провести анализ и получить навыки реагирования
на множество неожиданных ситуаций [18].
Кугаенко представлен набор из 18 тренажеров, отображающих различные стороны экономической динамики. В основе каждого из них лежит модель, описывающая управляемый объект и воздействующие на него условия.
Тренажеры ориентированы на получение навыков управления конкретными
экономическими объектами как на макро-, так и на микроэкономическом
уровне. Создана возможность выполнения экономических экспериментов путем непрерывного управления объектом и наблюдения за результатами возникающих изменений.
Сети Петри разрабатывались для моделирования систем с параллельными взаимодействующими компонентами. Сети Петри впервые предложил
Карл Адам Петри, в настоящее время теория имеет обширное применение
практически во всех отраслях научных исследований [1].
Сети Петри представляют собой математические модели, построенные
в рамках определенной концепции структуризации и на основе различающихся в отдельных деталях, но единых по своей сути регулярных технологических приемов формализации объектов исследований.
Важной особенностью метода формализации, применяемого при построении сетей Петри, является то обстоятельство, что эти модели сами могут выступать в качестве объектов аналитических исследований, цель которых состоит в выявлении свойств сетей, хорошо интерпретируемых в терминах базовых понятий предметной области.
Сеть Петри представляет собой двудольный ориентированный граф,
состоящий из вершин двух типов — позиций и переходов, соединённых между собой дугами. Вершины одного типа не могут быть соединены непосредственно. В позициях могут размещаться метки (маркеры), способные перемещаться по сети.
19
Событием называют срабатывание перехода, при котором метки из
входных позиций этого перехода перемещаются в выходные позиции. События происходят мгновенно, либо разновременно, при выполнении некоторых
условий.
Переходы отображают действия, происходящие в системе, а позиции состояния, предшествующие этим действиям, и состояния, принимаемые
системой после выполнения действия. Таким образом, модель сети Петри
служит для отображения и анализа причинно-следственных связей в системе.
В данном параграфе рассмотрены основные модели управления сложными системами, которые в дальнейшей работе учитывались для построения
модели турагентства.
1.3 Моделирование стратегических решений с помощью системной
динамики
В рамках данной работы рассматривается деятельность туристического
агентства. Туристическое агентство (турагентство) – фирма, занимающаяся
реализацией туров населению, организуемых туроператорами, а также продажей потребителям отдельных туристических услуг (транспортных билетов,
экскурсий, размещения и др.).
На начальных этапах создания информационной системы необходимо
понять, как работает организация, которая будет автоматизироваться. Согласно ГОСТ 24.103-84 («Автоматизированные системы управления») наиболее удобным языком моделирования бизнес-процессов является методология IDEF0 [9], предложенная более 20 лет назад Дугласом Россом и называвшийся первоначально SADT («Методология структурного анализа и проектирования»).
IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции [3].
20
В соответствии с РД IDEF0-2000 [28] процесс моделирования какойлибо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. Контекстная диаграмма —
диаграмма, расположенная на вершине древовидной структуры диаграмм,
представляющая собой самое общее описание системы и ее взаимодействие с
внешней средой. Далее контекстная диаграмма декомпозируется. В процессе
декомпозиции, функциональный блок, который в контекстной диаграмме
отображает систему как единое целое, подвергается детализации на другой
диаграмме. Получившаяся диаграмма содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком). В свою очередь, функциональный блок — предок
называется родительским блоком по отношению к дочерней диаграмме, а
диаграмма, к которой он принадлежит — родительской диаграммой [25].
Перейдем к описанию функциональной модели турагентства, основной
задачей которого является продажа путевок. Для этой задачи нужны клиенты
и материальные средства. Они будут входными параметрами, без которых не
может функционировать турагентство. В своей деятельности предприятие
использует персонал и руководствуется Законами РФ и внутренними документами фирмы. После предоставления услуг клиентам и, вычитая затраченные денежные средства, на выходе фирма получает прибыль. Но кроме материальной выгоды для турагентства являются очень важным отзывы клиентов.
Любое турагентство стремиться, чтобы клиенты остались довольны предоставляемыми услугами. Данную информацию представлена на контекстной
диаграмме нотации IDEF0 (рисунок 1.1).
21
Законы РФ
Внутренние
документы фирмы
Прибыль
Клиенты
Продажа путевок
Отзывы клиентов
Материальные средства
A0
Персонал
Рисунок 1.1 — Контекстная диаграмма
С помощью декомпозиции первого уровня, если рассматривать продажу путевок с точки зрения фирмы, можно выделить следующие бизнес процессы: процесс принятия заявки, процесс обработки заявки и процесс продажи путевки (рисунок 1.2).
Законы РФ
Внутренние документы фирмы
Клиент
Принятие
заявки
A1
Материальные средства
Обработка
заявки
A2
Прибыль
Продажа
путевки
Отзывы клиентов
A3
Персонал
Рисунок 1.2 — Декомпозиция первого уровня с точки зрения фирмы
Бизнес-процесс «Принятие заявки» подразделяется на следующие
функции: помочь в выборе тура, составить заявку.
Бизнес-процесс «Обработка заявки» начинается после выполнения бизнес-процесса «Принятия заявки» и содержит такие функции, как: проверить
22
наличие путевок (связаться с контрагентом), записать информацию о клиенте
и о выбранном туре в БД.
В бизнес-процессе «Продажа путевки» можно выделить следующие
функции: составить договор, подписать договор с клиентом и проследить за
своевременной оплатой путевки.
Для более понятного описания последовательности выполнения действий построена диаграмма в нотации IDEF3.
IDEF3 является стандартом документирования технологических процессов, происходящих на предприятии, и предоставляет инструментарий для
наглядного исследования и моделирования их сценариев. Сценарием называется описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса [29].
Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания
нескольких работ. Поэтому на диаграмме IDEF3 используются перекрестки,
которые отображают логику взаимодействия стрелок при слиянии и разветвлении или отображают множество событий, которые могут или должны быть
завершены перед началом следующей работы.
Типы соединений [29]:
 & (и) — означает, что действие, стоящее после него инициализируется, а до него должно быть завершено.
 О (или) — одно (или более) действий инициализируются или завершаются.
 Х (исключающее или) — одно и только одно действие должно завершаться или инициализироваться.
Последовательность действий процесса взаимосвязи с клиентом в туристической фирме, созданная в нотации IDEF3, представлена на рисунке 1.3. После того, как менеджер по продажам выслушает пожелания и предпочтения клиента, он должен либо подобрать тур из уже существующих, либо, если планируется групповая поездка, помочь составить индивидуальный
23
туристический маршрут. Далее сотрудник фирмы составляет договор и отчет,
согласовывает договор с заказчиком и следит за своевременной оплатой путевки.
Итак, с помощью нотации IDEF3 создана упорядоченная последовательность действий туристического агентства, что позволяет более детально
рассмотреть картину обслуживания клиента.
При моделировании работы туристического агентства не стоит забывать и о внешних факторах, влияющих на деятельность фирмы. Для этого будем использовать модели системной динамики, описанные в предыдущем
параграфе. Суть данной модели состоит в выявлении зависимости между
факторами и построении причинно-следственных отношений.
Перейдем к рассмотрению туристического агентства. Главным показателем деятельности туристического агентства является объем продаж, от которого зависят многие показатели фирмы. Схематично данные отношения
можно представить так: чем выше объем продаж, тем выше выручка агентства, чем выше выручка — тем выше доход, который определяет возможность
расширения компании.
Продажи зависят и от привлекательности фирмы для клиентов. На привлекательность безусловно влияет ассортимент туров, который может предложить агентство, и уровень сервиса. Также для любого туристического
агентства важна реклама «из уст в уста», то есть отзывы клиентов, уже
столкнувшихся с фирмой. Чем выше будет прибыль компании, тем больше
можно вложить в расходы на рекламу, что соответственно повысит узнаваемость агентства и увеличит объем продаж. Также с повышением прибыли
можно увеличить затраты на заработную плату, повысив мотивацию сотрудников к улучшению сервиса обслуживания клиентов.
24
Рисунок 1.3 — Последовательность действий процесса взаимодействия с клиентом
25
Очень важным показателем, влияющим на объемы продаж, является
спрос клиентов, который непосредственно зависит от дохода потребителей.
Соответственно чем выше цена на туристические путевки, тем вероятнее понижение спроса на них.
На цену в агентстве влияет множество факторов, первыми из которых
являются затраты, которые несет фирма: расходы на рекламу, затраты на заработную плату сотрудников, а также налоги, отчисления в социальные фонды, аренда помещения. Также на цену путевки агентства влияет цена, назначенная туроператором, и класс обслуживания, который выбирает клиент (вид
транспорта, уровень гостиницы, экскурсии и т.д.).
Вся данная схема представлена в модели системной динамике на рисунке 1.4.
Знаками «+» и «–» на рисунке 1.4 показаны направления взаимовлияния факторов друг на друга
Таким образом, можно увидеть, что для принятия решения в туристическом агентстве требуется учитывать множество факторов, изменение которых влияет на работу всей фирмы. Дальнейшее построение модели представлено во 2 главе работы.
26
Рисунок 1.4 – Модель системной динамики работы туристического агентства
27
Глава 2. Проектирование информационной системы
2.1 Анализ требований к системе
Для моделирования бизнес-процессов турагентства используем нотацию BPMN.
Основной целью языка BPMN является обеспечение абсолютно доступной нотацией для описания бизнес-процессов всех бизнес-пользователей.
BPMN нацелен на устранение расхождения между моделями бизнеспроцессов и их реализацией.
В нотации BPMN 2.0 можно выделить пять основных категорий графических элементов:
1. Элементы управления – действия, события, логический оператор;
2. Соединительные элементы – поток управления, направленная и ненаправленная ассоциация;
3. Артефакты – группа, аннотация, ссылка;
4. Данные – объект данных, хранилище данных, сообщение;
5. Зоны ответственности – пул и дорожки;
Событие – факт (ситуация, набор условий или обстоятельств), который
активирует или оказывает влияние на дальнейшее развитие одного или более
процессов. Событие инициируют действия или являются их результатами
[31].
Действие или набор действий, выполняемых исполнителем в ходе процесса.
Логический оператор используется для обозначения слияния и/или
ветвления потока событий и действий.
Потоки управления связывают отдельные операции, логические операторы и события в логическую цепочку и устанавливают порядок их выполнения.
28
Сообщение отражает факт передачи информации между участниками
процесса.
Зоны ответственности – пулы и дорожки есть графические элементы,
служащие для логической группировки операций процесса. Пул – структурное подразделение, которому поручено выполнение действия (фирма, организация, отдел, служба). Дорожка – должность исполнителя или роль субъекта, которому поручено выполнение действия.
Спецификация BPMN 2.0 регламентирует следующие типы диаграмм
бизнес-процессов:
1. Диаграммы оркестровки (схемы потока работ)
2. Диаграммы взаимодействия участников одного или нескольких бизнес-процессов (Collaboration);
3. Диаграммы диалогов (Conversation).
4. Диаграммы хореографии (Choreography).
Схема диалога позволяет отобразить информационный обмен сообщениями, сгруппированными по темам обсуждения. Например, заказ товаров,
перевозка грузов, выписка счета и т.д. По сути, такие схемы изображают различные сценарии общения участников межу собой.
Схема хореографии показывает последовательность процедур обмена
сообщениями между двумя и более участниками. В отличие от обычного
процесса, который обязательно изображается внутри пула, хореография
обычно описывается без пулов. В целом, хореография похожа на схему приватного процесса, поскольку она так же состоит из цепочки задач хореографии, событий и логических операций. Тем не менее, хореография отличается
от диаграммы оркестровки тем, что операции на ней отображают факт передачи сообщения между двумя и более участниками
Диаграмма оркестровки - это схема, показывающая очередность выполнения операций процесса. Диаграмма закрытого процесса есть схема процесса, моделируемого внутри некоторого контейнера, называемого пулом.
Этот контейнер можно изображать на схеме явно или только подразумевать.
29
Если пул явно указывается на диаграмме процесса, то схема называется закрытой. Диаграмма открытого процесса есть схема процесса, на которой пул
только подразумевается. Диаграмма приватного взаимодействия (private) показывает процесс, который исполняется в пределах какой-либо организации
или координируется из единого центра. Для неисполняемой аналитической
модели это означает, что у процесса единый владелец. Диаграмма публичного взаимодействия (public) показывает коммуникацию между двумя приватными процессами, у каждого свой центр управления, каждый из них имеет
своего владельца. Диаграмма публичного взаимодействия может иметь разную степень детализации.
Для деятельности турагентства можно выделить 2 диаграммы оркестровки: составления заказа клиентом (рисунок 2.1) и стадии прохождения заказа со стороны оператора (рисунок 2.2).
Рисунок 2.1 — Диаграмма оркестровки с точки зрения клиента
Рисунок 2.2 — Диаграмма оркестровки с точки зрения оператора
30
Схемы взаимодействия показывают обмен сообщениями между двумя
и более участниками. Участники по отдельности управляют своими бизнеспроцессами, у каждого есть свой владелец. Для изображения участников на
схеме взаимодействия обычно используют графический элемент пул. Взаимодействие между участниками осуществляется при помощи потоков сообщений. Следует учитывать, что схема определяет лишь наличие потока сообщений, но не детализирует его содержимое. На схеме показываются только
операции, которые участвуют в обмене сообщениями. Пул, изображающий
участника, может быть пустым, не иметь внутри себя ни одной операции. В
этом случае, такой процесс называется «черный ящик». Потоки сообщений
могут изображаться только между пулами.
Для описания взаимодействия с клиентом в туристическом агентстве
используем диаграмму взаимодействия (рисунок 2.3).
Рисунок 2.3 — Диаграмма взаимодействия
Построенная в главе 1 модель системной динамики необходима для
директора турагентства, чтобы принять взвешенное решение, учитывая все
факторы. С помощью диаграммы оркестровки представлена очередность
действий директора при работе с модулем поддержки принятия решения (рисунок 2.4).
31
Рисунок 2.4 — Диаграмма оркестровки с точки зрения директора
Определив бизнес-процессы взаимодействия турагентства и клиента, а
также порядок действия принятия решения, приступим к проектированию
системы.
Проектирование ИС турагентства начинается с выявления требования к
системе с помощью диаграммы вариантов использования в нотации языка
UML.
В книге [5] дается следующее определение UML: «Унифицированный
язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. С помощью UML можно разработать детальный план создаваемой системы, содержащий не только ее концептуальные элементы, такие как системные функции и бизнес-процессы, но и конкретные особенности, например классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования».
UML — это не просто набор графических символов [4]. За каждым из
них стоит хорошо определенная семантика. Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим.
Диаграмма вариантов использования (use case diagram, диаграмма прецедентов) в нотациях языка UML — диаграмма, отражающая отношения между
действующими
лицами
(актерами)
и
вариантами
использования
(прецедентами), позволяющая описать систему на концептуальном уровне
[27].
32
Действующее лицо является внешним источником, который взаимодействует с системой через вариант использования. Действующие лица могут
быть как реальными людьми, так и другими компьютерными системами или
внешними событиями.
При взаимодействии актера с системой, последняя выполняет ряд работ, которые образуют вариант использования системы. Каждый актер может
использовать систему по-разному, то есть инициировать выполнение разных
прецедентов. Таким образом, каждый вариант использования — есть некоторое функциональное требование к системе.
Связи между актерами и вариантами отображаются с использованием следующих отношений [2]:
 ассоциации;
 обобщения;
 включения;
 расширения.
Отношение ассоциации служит для обозначения взаимодействия актера
с вариантом использования и отображается сплошной линией [19].
Отношение обобщения служит для указания того факта, что некоторый
вариант использования А может быть обобщен до варианта использования В.
В этом случае вариант А будет являться специализацией варианта В. При
этом, В называется предком или родителем по отношению к А, а А — потомком по отношению к В. Потомок наследует все свойства и поведение своего
родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией
со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
Отношение включения указывает, что некоторое заданное поведение
одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Стрелка
33
включения направлена от базового (составного) варианта к включаемому и помечена стереотипом «include».
В отличие от отношения включения, отношение расширения определяет
возможность включения поведения одного варианта использования в состав другого. Т. е. дочерний вариант использования может как вызываться, так и не вызываться родительским. Стрелка расширения должна быть направлена от включаемого варианта к базовому и помечена стереотипом «extend».
Для информационной системы турагентства были выделены следующие действующие лица:

Посетитель;

Клиент;

Контрагент;

Оператор;

Директор.
Группа «Посетитель» — это пользователи, функциональными требованиями которых являются: просмотр информации о существующих туристических поездках и подбор тура по конкретно заданным параметрам.
Группа «Клиент» является подгруппой «Посетитель», и представляет
собой пользователей, зарегистрированных в системе. Данный класс обладает
возможностью отправки заявки и оставления отзыва о деятельности турагентства.
Группа «Контрагент» — пользователи, которые являются представителями туроператора фирмы. Они могут просматривать информацию о существующих туристических поездках, а так же связываться с группой «Оператор»
для уточнения каких-либо вопросов.
Группа «Оператор» — пользователи, работающие в турагентстве (персонал фирмы), занимающиеся продажей путевок. Их функциональные требования: просмотреть информации о существующих туристических поездках,
изменить эту информацию, принять заказ от клиентов фирмы и проследить за
своевременной оплатой проданных путевок.
34
«Директор» — лицо, принимающее решение.
С помощью диаграммы вариантов использования на рисунке 2.5 представлена вся информация о пользователях турагентства и их требования.
Для более подробного рассмотрения требований к системе необходимо
изучить процесс взаимодействия с клиентом в туристической фирме с помощью диаграммы деятельности.
Просмотреть информацию
о турах
Посетитель
<<включить>>
Сделать заказ
Клиент
Подобрать тур онлайн
Оператор
Оставить отзыв
Контрагент
Принять заказ
Изменить информацию
о турах
<<включить>>
Просмотреть информацию
о турах
Связаться с оператором
Внести информацию о новой групповой или
индивидуальной поездке
Проследить за своевременной
оплатой путевки
Проанализировать результаты
Директор
Рисунок 2.5 — Диаграмма вариантов использования
35
В [17] А. Коберн предлагает способ представления вариантов использования в виде текстовых спецификаций. Спецификация состоит из общей
информации о варианте использования. Спецификация прецедента «Проанализировать результаты», который включает в себя модель поддержки принятия решения, приведена в таблице 1.
Таблица 1 — Спецификация варианта использования «Проанализировать результаты»
Имя варианта использования
Краткое описание
Проанализировать результаты
Директор просматривает результаты,
сформированные моделью поддержки принятия решения
Действующие лица
Основное: директор
Предусловие
Выбрать опцию «Проанализировать
результаты»
Основной поток
Директор заполняет изменившиеся
факторы, влияющие на деятельность
фирмы, система выполняет расчет по
данным факторам
Постусловие
Видит результаты подсчетов, на основании которых принимает решение
Альтернативный поток
Если директор заполнил не все поля,
то ему придет сообщение «Заполнено
неверно»
Таким образом, определены основные бизнес-процессы турагентства в
нотации BPMN, выявлены пользователи и их функциональные требования с
помощью диаграммы вариантов использования.
2.2 Детальное проектирование
Диаграмма классов
Диаграмма классов (class diagram) — основной способ описания структуры системы. Она показывает классы и их отношения в логической схеме
проектов, позволяет представить архитектуру системы [22].
36
Класс – это множество объектов, связанных общностью свойств, поведения, связей и семантики. Класс объединяет в себе данные (атрибуты) и поведение (операции).
Атрибуты класса или свойства записываются во второй сверху секции
прямоугольника класса. В языке UML каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута,
имени атрибута, его кратности, типа значений атрибута.
Квантор видимости может принимать одно из трех возможных значений и отображается при помощи соответствующих специальных символов,
представленных ниже:
 «+» обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или
виден из любого другого класса пакета, в котором определена
диаграмма;
 «#» обозначает атрибут с областью видимости типа защищенный
(protected). Атрибут с этой областью видимости недоступен или
невиден для всех классов, за исключением подклассов данного
класса;
 «-» обозначает атрибут с областью видимости типа закрытый
(private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.
Квантор видимости может быть опущен. В этом случае его отсутствие
означает, что видимость атрибута не указывается [22].
Тип атрибута представляет собой выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML
тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели.
Операции или методы класса записываются в третьей сверху секции
прямоугольника. Совокупность операций характеризует функциональный
37
аспект поведения класса. Каждой операции класса соответствует отдельная
строка, которая состоит из квантора видимости операции, имени операции.
Квантор видимости, как и в случае атрибутов класса, может принимать
одно из трех возможных значений и отображается соответствующими символами. Квантор видимости для операции может быть опущен.
Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются отношения между классами. Базовыми отношениями в языке UML являются [27]:
 зависимости;
 ассоциации;
 обобщения.
Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.
Отношение зависимости графически изображается пунктирной линией
между соответствующими элементами со стрелкой, направленной от классаклиента зависимости к независимому классу или классу-источнику.
Отношение ассоциации соответствует наличию некоторого отношения
между классами. Данное отношение обозначается сплошной линией, которое
может использоваться с кратностью классов.
Кратность отдельного класса обозначается в виде интервала целых чисел. Интервал записывается рядом с концом ассоциации [23].
Отношение обобщения является обычным отношением между более
общим элементом (предком) и более частным или специальным элементом
(потомком). Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.
При этом предполагается, что класс-потомок обладает всеми свойствами и
поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. Стрелка указывает на общий
38
класс (класс-предок или суперкласс), а ее отсутствие — на специальный
класс (класс-потомок или подкласс).
Для ИС турагентства выделены следующие классы системы:
 «Посетитель» является обобщаемым классом для класса «Клиент»;
 «Клиент» — класс пользователей, зарегистрированных в системе;

«Оператор» представляет пользователей, работающих в агентстве;
 «Контрагент» — пользователи, которые являются представителями туроператора фирмы;
 «Идентификация и аутентификация» класс, являющийся обобщаемым для всех пользователей системы, так как пользователи
должны быть зарегистрированы;
 «Тур» — хранит в себе данные о существующих турах агентства;
 «Заявка» — включает в себя все поля и действия заявки;
 «Документация по заявке» — содержит все данные о документации по каждой заявке;
 «Статистика» — класс, подсчитывающий статистику выбранных
туров.
Все классы с соответствующими атрибутами, операциями, интерфейсами и отношения между ними ИС турагентства представлены на рисунке
2.6.
Для подробного рассмотрения взаимодействия директора и модели
поддержки принятия решения выделены следующие классы:
 «Директор» — лицо, принимающее решение (ЛПР);
 «Статистика» — класс, который на основании данных, введенных сотрудниками фирмы, предоставляет статистику выбранных
туров;
39
<<Интерфейс>>
Контрагент
+Просмотреть ин ф о туре()
+Переслать инф о новых или
измен ившихся турах
+Просмотреть статистику()
+Просмотреть отчет()
Документация по заявке
Контрагент
+ Просмотреть ин ф о туре()
+ Просмотреть статистику()
+ Переслать инф о новых или
измен ившихся турах()
+Просмотреть отчет()
1
+ num: int
+ name: string
1..*
+Составить документацию()
+Составить отчет()
Статистика
extends
Идентификация и
аутентификация
extends
+Составить статистику
Оператор
1
<<Интерфейс>>
+log:string
+pass:string
+kat: enum=
{Клиент, Оператор, Контрагент}
extends
Оператор
+ Просмотреть ин ф о туре()
+ Редактировать инф о туре()
+
1 Принять заказ()
+ Записать в БД()
+ Составить статистику()
+ Составить документацию()
+ Составить отчет()
+Удалить ту р()
1
1..*
1..*
1..*
+ num: int
+surname:string
+name:string
+patronymic:string
+tel:string
+adress:string
+index_t:string
+seri ya:string
+number_t:string
+when_t:date
+who:string
+number_adult:int
+number_child^int
+ Проверить заполненность
обязательных полей()
+ Отправить данные()
+Промежуточное сохранение данных в
заявке()
+Редактировать заявку()
+Удалить заявку()
+Сохранить заявку()
Тур
Пользователь
Заявка
1..*
1..*
+ Просмотреть ин ф о туре()
+ Подобрать тур онлайн()
-memberName
+ name: string
+ cost: int
+ inf: string
+Просмотреть ин ф о туре()
+Подобрать тур онлайн()
+Редактировать инф о туре()
+Удалить ту р()
extends
1..*
Клиент
<<Интерфейс>>
1
+ Сделать заказ()
+Промежуточное сохранение данных в
заявке()
+Редактировать заявку()
+Удалить заявку()
+ Оставить отзыв()
Клиент
+Просмотреть ин ф о туре()
+Подобрать тур онлайн()
+Сделать заказ()
+Промежуточное сохранение данных в
заявке()
+Редактировать заявку()
+Удалить заявку()
+Оставить отзыв()
Рисунок 2.6 — Диаграмма классов
+Просмотреть ин ф о туре()
+Редактировать инф о туре()
+Удалить ту р()
+Принять заказ()
+Составить статистику()
+Составить документацию()
+Составить отчет()
+Сохранить заявку()
40

«Идентификация и аутентификация» — класс, являющийся
обобщаемым для всех пользователей системы, так как пользователи должны быть зарегистрированы;

«Модуль решения» — содержит аппарат, делающий расчеты по
факторам, влияющим на деятельность фирмы и выводящий результаты.
По результатам данного «модуля решений» ЛПР анализирует
результаты и принимает взвешенное решение.
Данное взаимодействие директора с системой представлено на рисунке
2.7.
Статистика
1
1
<<Интерфейс>>
Директор
Идентификация и
аутентификация
extends
+log: string
+pass: string
Директор
+Просмотреть статистику
+Ввести данные об изменившихся
факторах
+Проанализировать результаты
+Просмотреть статистику
+Ввести данные об изменившихся
факторах
+Проанализировать результаты
1
Модуль решения
+Посчитать введенные данные
+Вывести результаты
1
Рисунок 2.7 — Диаграмма классов взаимодействия директора с системой
Диаграмма последовательности
Диаграмма последовательности (sequence diagram) в нотациях языка
UML — диаграмма, на которой показано взаимодействие объектов (обмен
между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления.
Основными элементами диаграммы последовательности являются [5]:
 обозначения (прямоугольники с названиями объектов),
41
 «линии жизни», вертикальные линии на диаграмме последовательности, которые представляет существование объекта в течение определенного периода времени,
 фокус управления — специальный символ на диаграмме последовательности, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном
состоянии, изображается в форме вытянутого узкого прямоугольника,
 стрелки, показывающие обмен сигналами или сообщениями между объектами.
На данной диаграмме объекты располагаются слева направо.
Крайним слева на диаграмме изображается объект, который является
инициатором взаимодействия. Правее изображается другой объект, который
непосредственно взаимодействует с первым. Таким образом, все объекты на
диаграмме последовательности образуют некоторый порядок, определяемый
степенью активности этих объектов при взаимодействии друг с другом.
Второе измерение диаграммы последовательности — вертикальная
временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними
объектами другим. Сообщения изображаются в виде горизонтальных стрелок
с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже.
Проектирование системы турагентства в части обработки заявок пользователя с помощью диаграммы последовательности представлено на рисунке 2.8.
Инициатором данного процесса взаимодействия является клиент фирмы. Как видно из диаграммы, после того как подана заявка пользователем,
система должна проверить ее на корректность введенных данных. То есть
42
информация введена именно в том типе данных, который предполагается в
ИС, и введены все обязательные поля. Далее составленная заявка проходит
цикл, по исходу которого клиент получает отчет.
Рисунок 2.8 — Диаграмма последовательности обработки заявки
Диаграмма пакетов
Диаграмма пакетов (package diagram) — структурная диаграмма, предназначенная для описания основных элементов проектируемой системы [27].
Основными элементами диаграммы являются пакеты и зависимости
между ними, а также области видимости элементов пакета. Зависимости между элементами диаграммы пакетов отображаются с помощью пунктирных
43
стрелок, начало которых размещается на зависимом элементе (клиенте), а
острие на элементе, поддерживающем зависимость (серии).
Все классы, присутствующие в проекте, должны быть распределены по
пакетам (каждый класс в одном пакете). Если классы не распределены по пакетам, то считается, что каждый из них образует пакет верхнего уровня.
Отношения зависимости пакетов:
 использование (use). Элементы пакета Р2 некоторым образом используют открытые элементы пакета Р1. Если зависимость между пакетами указана без стереотипа, то считается, что это зависимость типа use.
 импорт (import). Открытые элементы пространства имен Р1 добавляются как открытые элементы в пространство имен Р2. При
этом элементы Р2 могут организовывать доступ к открытым элементам поставщика с помощью неполных имен.
 доступ (access). Открытые элементы в пространстве имен Р1 являются доступны в пространстве имен Р2. При этом Р2 может
осуществлять доступ о всем открытым элементам Р2 по неполному имени.
 слияние (merge). Открытые элементы пакета Р1 объединяются с
элементами Р2, данный вид зависимости используется только при
создании наиболее общей модели и в проектной документации,
как правило, не встречается.
 трассировка (trace). Данный вид отношений представляет историческое развитие одного элемента в другую более развитую
версию. Обычно данный вид отношений используется между моделями, а не элементами этих моделей.
Поскольку диаграмма пакетов предполагает в разделении системы на
относительно небольшое число независимых элементов, то возникает необходимость в определении контрактов взаимодействия этих элементов. Роль
контрактов между подсистемами выполняют интерфейсы.
44
Интерфейс — это набор операций, используемых для специфицирования услуг, предоставляемых классом или компонентом. В отличие от классов, интерфейсы не описывают структуры (поэтому не могут содержать атрибуты) но может включать любое число операций, которые могут быть дополнены кванторами видимости операций, именами операций.
Интерфейсы разделяются на предоставляемые и требуемые. Интерфейс, который реализуется соответствующим классификатором называется
предоставляемым. Иными словами, предоставляемый интерфейс — это то,
что получится в результате работы классификатора. Интерфейсы необходимые для работы классификатора называются требуемыми.
Для туристического агентства выделены следующие пакеты:
 «Личный кабинет» — в данном пакете содержится все, что касается личных данных пользователей системы;
 «Заявка» — включает в себя такие классы, как: «Заявка», «Документация по заявке» и «Статистика»;
 «Тур» — заключает в себе данные о каждом туристическом маршруте фирмы.
Все пакеты взаимодействуют с базой данных, что необходимо для успешной работы автоматизированной информационной системы.
Диаграмма, включающая в себя выделенные пакеты, интерфейсы и связи между ними представлена на рисунке 2.9.
45
Пользователь
Оператор
extends
Контрагент
extends
extends
Клиент
Автоматизация и аутентификация
extends
use
use
use
<<Interface>>
<<Interface>>
<<Interface>>
Клиент
Оператор
Контрагент
+Просмотреть ин ф о туре()
+Подобрать тур онлай н()
+Сделат ь заказ()
+Промежуточное сохранение данных в
заявке()
+Редак тировать заявку()
+Удалить заявку()
+Ост ави ть отзыв()
+Просмотреть ин ф о туре()
+Редак тировать инф о туре()
+Удалить ту р()
+При нять зак аз()
+Составить статистику()
+Составить документац ию()
+Составить от чет()
+Сохрани ть заявку()
use
use
+Просмотреть ин ф о туре()
+Переслат ь инф о новых или
измен ившихся турах()
+Просмотреть стат ист ику()
+Просмотреть отчет
use
realize
realize
realize
Тур
Заявка
Документация по заявке
Статистика
use
<<Database>>
Турфирма
use
Рисунок 2.9 — Диаграмма пакетов
45
46
2.3 Алгоритмическое обеспечение
Согласно модели системной динамики, представленной в главе 1, выделены факторы, влияющие на деятельность турагентства. Из данной модели
можно сделать вывод, что основным показателем успешной работы фирмы
является выручка. Выручка состоит из 2 показателей, а именно из объема
продаж и цены тура:
Выручка = Объем продаж * Цена тура
Каждый из данных показателей зависит от своих переменных, что
можно представить как функции:
Объем продаж = f(x1, x2, x3),
где
х1 — реклама «из уст в уста» (отзывы);
х2 — уровень сервиса;
х3 — ассортимент фирмы.
Цена тура = g(y1, y2, y3, y4, y5),
где
у1 — затраты на з/п;
у2 — отчисления в социальные фонды;
у3 — арендная плата;
у4 — цена туроператора;
у5 — расходы на рекламу.
При этом сами функции имеют обратно пропорциональную зависимость, то есть:
Если Цена тура увеличится, то Объем продаж понизится и наоборот.
Применяя экспертное оценивание было принято решение представить
описанные выше переменные в виде одного из значений (0, 1, 2):
0 — означает, что изучаемый фактор понижается (ухудшается);
1 — показывает, что изучаемый фактор не изменяется;
47
2 — представляет код, согласно которому показатель фактора повышается (улучшается).
С помощью продукционных правил данные функции представлены
ниже.
Если х1=2, то Объем продаж повысится;
Если х1=1, то Объем продаж не изменится или понизится;
Если х1=0, то Объем продаж понизится;
Если х2=2, то Объем продаж повысится или не изменится;
Если х2=1, то Объем продаж не изменится;
Если х2=0, то Объем продаж понизится;
Если х3=2, то Объем продаж повысится;
Если х3=1, то Объем продаж не изменится;
Если х3=0, то Объем продаж понизится или не изменится.
В случае рассмотрения факторов, влияющих на функцию Объем продаж, в совокупности, получатся следующие продукционные правила.
Если (х1=0) и (х2=0) и (х3=0), то Объем продаж понизится.
Если (х1=0) и (х2=0) и (х3=1), то Объем продаж понизится.
Если (х1=0) и (х2=1) и (х3=0), то Объем продаж понизится.
Если (х1=1) и (х2=0) и (х3=0), то Объем продаж понизится.
Если (х1=1) и (х2=0) и (х3=1), то Объем продаж понизится или не изменится.
Если (х1=1) и (х2=1) и (х3=0), то Объем продаж понизится или не изменится.
Если (х1=1) и (х2=1) и (х3=1), то Объем продаж не изменится.
Если (х1=1) и (х2=1) и (х3=2), то Объем продаж не изменится или повысится.
48
Если (х1=1) и (х2=2) и (х3=1), то Объем продаж не изменится или повысится.
Если (х1=2) и (х2=1) и (х3=1), то Объем продаж повысится.
Если (х1=2) и (х2=1) и (х3=2), то Объем продаж повысится.
Если (х1=2) и (х2=2) и (х3=1), то Объем продаж повысится.
Если (х1=2) и (х2=2) и (х3=2), то Объем продаж повысится.
Аналогично представленным выше правилам, рассматривая функцию
Цена тура было отмечено, что функция Цена тура состоит из переменных,
описывающих затраты фирмы, поэтому повышение любых переменных приведет к повышению функции, а любое понижение соответственно приведет к
снижению. Функция останется неизменной только если все факторы не изменятся.
Таким образом, представлена формализованная модель факторов,
влияющих на деятельность туристического агентства, с помощью продукционных правил.
2.4 Расчет временной продолжительности проекта
Оценка предстоящих затрат и результатов при определении эффективности проекта осуществляется в пределах периода его продолжительности
[7]. Поэтому необходимо правильно выявить все возможные работы по созданию информационной системы и рассчитать их длительность.
Расчет расписания работ проекта – процесс определения даты начала и
окончания каждой работы проекта. Это центральный процесс планирования
[26].
В соответствии с ГОСТ Р ИСО/МЭК 12207-99 составлен перечень работ, необходимых для создания автоматизированной системы туристического агентства [10]:
 Подготовка к разработке
 Анализ требований к системе
49
 Проектирование системной архитектуры
 Проектирование программной архитектуры
 Программирование и тестирование программных средств
 Сборка системы
 Квалифицированные испытания системы
 Ввод в действие ПО
Декомпозиция данных работ представлена на дереве целей проекта,
изображено на рисунке 2.10. Результатом их выполнения будет готовое ПО.
Для отображения работ, их взаимосвязи и последовательности, а также
для расчета общей продолжительности проекта на практике строится сетевой
график [21].
Сетевой график — это динамическая модель производственного процесса, отражающая технологическую зависимость и последовательность выполнения комплекса работ.
Каждая отдельная работа, входящая в проект, требует затрат времени.
При выполнении комплекса работ всегда можно выделить ряд событий, то
есть итогов какой-то деятельности, позволяющих приступить к выполнению
следующих работ. Если каждому событию поставить в соответствие вершину
графа, а каждой работе — ориентированное ребро, то получится граф, который будет отражать последовательность выполнения отдельных работ и наступление событий в едином комплексе. Если под ребрами проставить время,
необходимое для завершения соответствующей работы, то получится сеть.
Изображение такой сети называют сетевым графиком.
50
Рисунок 2.10 – Дерево целей проекта
51
Сетевой график состоит из двух типов основных элементов: работ и
событий. Работа представляет собой выполнение некоторого мероприятия.
Этот элемент сетевого графика связан с затратой времен и расходом ресурсов. Поэтому работа всегда имеет начало и конец. Событие выражает факт
окончания одной или нескольких непосредственно предшествующих работ,
необходимых для начала непосредственно следующих (выходящих из события) работ. Событие, стоящее в начале работы, называется начальным, а в
конце — конечным.
Общая продолжительность проекта рассчитывается по сетевому графику при условии, что известна продолжительность каждого мероприятия,
требуемого в соответствии с проектом.
Резерв времени – это количественный показатель подвижности определенного действия при условии обязательного завершения проекта в минимально возможные сроки.
Сетевой график взаимосвязи и продолжительности работ, необходимых для создания автоматизированной системы туристического агентства,
представлен на рисунке 2.11. В левый сектор кружка с событием записано
ранний срок свершения события, в правый – поздний срок его свершения. В
нижнем секторе – номер события, в верхнем – резерв времени события [21].
Жирным шрифтом на графике представлен критический путь: 0-1-2-34-5-6-7-8-9-10-12-13-14-15-18-19-21-20-23-24-25.
52
Рисунок 2.11 – Сетевой график
53
2.5 Финансовый анализ стоимости информационной системы турагентства
Для расчета себестоимости готового ПО необходимо сложить все возможные затраты на его разработку, а именно: затраты на оплату труда, отчисления в социальные фонды, затраты на коммунальные и интернет услуги,
услуги клининговой компании, арендную плату.
Для создания информационной системы туристического агентства понадобятся следующие работники:
 менеджер проекта – 1 человек;
 программист – 2 человека;
 проектировщик – 1 человек;
 тестировщик – 1 человек;
 специалист по внедрению ПО – 1 человек.
Заработная плата каждого специалиста, взятая средним показателем по
Орловской области, указана в таблице 8.
Таблица 2 – Заработные платы специалистов проекта
Специалист
Заработная плата (руб/мес)
менеджер проекта
28000
программист
35000
проектировщик
24000
тестировщик
25000
специалист по внедрению ПО
23000
Не все специалисты будут работать на протяжении длительности всего
проекта. Поэтому необходимо составить матрицу ответственности, которая
установит степень ответственность каждого участника проектной команды за
выполнение отдельных этапов и задач проекта.
При составлении матрицы ответственности проекта использовалась методика RACI, являющаяся удобным и наглядным средством планирования
54
ответственности членов проектной команды при выполнении задач на каждом из этапов проекта.
Термин RACI (или ARCI) является аббревиатурой [31]:
 Ответственный (Accountable) – полностью отвечает за исполнение этапа/задачи, вправе принимать решения по способу реализации. В качестве ответственного за задачу может назначаться
только один человек.
 Исполнитель (Responsible) – исполняет задачу, не несет ответственность за выбор способа её решения, но отвечает за качество и
сроки реализации. У каждой задачи должен быть хотя бы один
исполнитель.
 Консультант (Consult before doing) – оказывает консультации в
ходе решения задач проекта, контролирует качество реализации.
 Наблюдатель (Inform after doing) – может оказывать консультации в ходе решения задач проекта, не несет ответственности.
Матрица ответственности специалистов необходимых для создания
информационной системы турагентства представлена в таблице 9.
внед.
Спец. по
Тестир.
тиров.
Проек-
работ
мист
Сроки
Мен-р
Работы
Програм
Таблица 3 – Матрица ответственности
Подготовка к разработке
Заключение контракта
0-1
ИО
Сбор команды
Выбор стандартов, методов,
инструментариев и языков
программирования для разработки ПО
Анализ требований к системе
1-4
ИО
4-5
ИО
К
5-12
К
ИО
Проведение обследования
объекта автоматизации
Продолжение таблицы на следующей странице
55
Продолжение таблицы
Выявление технических требований к системе
Составление и утверждение
ТЗ
Проектирование системной
архитектуры
12-17
К
ИО
17-19
О
И
19-33
Н
ИО
Проектирование модулей
33-45
Н
ИО
Проектирование интерфейса
45-52
Н
ИО
Проектирование БД
Программирование и тестирование программных
средств
Разработка модуля авторизации и аутентификации пользователей в системе
Разработка модуля создания
и отправки заявки
Разработка модуля обработки заявки
Разработка модуля связи между клиентом и оператором
Разработка модуля связи между оператором и контрагентом
Разработка модуля поиска по
БД
Разработка модуля статистики
Тестирование каждого модуля
52-57
Н
ИО
57-71
Н
ИО
57-67
Н
ИО
67-72
Н
ИО
72-82
Н
ИО
82-92
Н
ИО
71-75
Н
ИО
75-91
Н
ИО
92-113
Н
113-125
139-144
Н
Н
125-139
Н
139-146
Н
Проектирование программной архитектуры
Сборка системы
Сборка системы и отладка
ПО
Устранение ошибок
Квалификационные испытания системы
Ввод в действие ПО
Создание документации
пользователя
ИО
ИО
ИО
ИО
ИО
Продолжение таблицы на следующей странице
56
Продолжение таблицы
Установка и отладка ПО у
заказчика
Обучение персонала
Сдача ПО
О
О
О
144-147
147-150
150-151
И
И
И
Рассчитанная заработная плата специалистам по созданию ПО с учетом
количества отработанных дней представлена в таблице 10.
ПО
Итого
внедрению
по внедрению
Специалист
Тестировщик
щик
Проектиров-
Программист
Менеджер
Таблица 4 – Затраты на заработную плату по месяцам
1 месяц
(1-23 день)
28000
0
19826,09
0
0
47826,09
28000
0
24000
0
0
52000
28000
36521,74
11478,26
0
0
76000
28000
70000
0
0
0
98000
28000
6086,96
0
22826,09
0
56913,04
28000
30434,78
0
15217,39
0
73652,17
15826,09
15217,39
7304,35
0
7000
45347,83
2 месяц
(24-46 день)
3 месяц
(47-69 день)
4 месяц
(70-92 день)
5 месяц
(93-115 день)
6 месяц
(116-138 день)
7 месяц
(139-151 день)
Кроме затрат на заработную плату специалистам проекта и отчислений
во все фонды, в проекте имеются и другие затраты, которые представлены в
таблице 11. Аренда помещения составляет 20000 руб. в месяц, но на проект
переносится только 10% затрат. Затраты на коммунальные платежи, интернет
услуги и услуги клининговой компании переносятся лишь на 50%.
57
Таблица 5 – Расчет себестоимости ПО
Затраты на з/п
Отчисления в ПФРФ
(22%)
Отчисления в
ФФОМС (5,1%)
Отчисления в ФФС
(2,9%)
Аренда (10%)
Коммунальные платежи (50%)
Интернет (50%)
Услуги клиннинговой компании (50%)
Всего
1
47826,09
2
52000,00
3
76000,00
4
98000,00
5
56913,04
6
73652,17
7
45347,83
Всего
449739,13
10521,74
11440,00
16720,00
21560,00
12520,87
16203,48
9976,52
98942,61
2439,13
2652,00
3876,00
4998,00
2902,57
3756,26
2312,74
22936,70
1386,96
2000,00
1508,00
2044,00
2204,00
2088,97
2842,00
2134,93
1650,48
2181,89
2135,91
2229,90
1315,09
2278,95
13042,44
14000,00
2000,00
1500,00
2044,00
1533,00
2088,97
1566,73
2134,93
1601,19
2181,89
1636,42
2229,90
1672,42
2278,95
1709,21
14000,00
10500,00
1000,00
68673,92
1022,00
74100,00
1044,48
105300,00
1067,46
133900,00
1090,95
80486,96
1114,95
102247,82
1139,48
65452,18
7000,00
630160,88
Таким образом, себестоимость проекта по созданию информационной системы турагентства для компании-разработчика
составит 630160,88 рублей.
58
Заключение
В итоге выполнения выпускной квалификационной работы была достигнута поставленная цель, а именно, спроектирована информационная система сопровождения деятельности туристического агентства и построена интерактивная модель принятия решения.
В первом разделе данной работы рассмотрены наиболее распространенные методологические подходы к моделированию сложных систем, в частности концептуальное, математическое, имитационное моделирование и
системная динамика. Далее проведен критический обзор моделей системной
динамики, из которого видно, что наиболее интересующие исследователей
области построения — это динамические системы предприятий и управления
городом. Данные модели рассматриваются за длительный период функционирования. После проведен анализ объекта автоматизации, с помощью нотации IDEF0 и IDEF3 смоделирована деятельность фирмы, выделены бизнес
процессы агентства и представлена последовательность их выполнения. Также построена модель системной динамики, описывающая деятельность туристического агентства.
Второй раздел содержит разработанную проектную документацию на
создание информационной системы сопровождения деятельности туристического агентства в нотациях языка UML и BPMN, в частности, построены диаграммы оркестровки, взаимодействия, вариантов использования, деятельности, классов, последовательности и пакетов. После этого построен модуль
поддержки принятия решений с помощью продукционных правил. По проекту по созданию информационной системы предложены работы и срок их выполнения, последовательность которых представлена на сетевом графике.
Выявлены основные затраты на проект, а именно, затраты на заработную
плату, на отчисления в социальные фонды, на арендную плату, коммунальные услуги и интернет, услуги клиннинговой компании. Рассчитана себестоимость проекта, которая составила около 633277 рублей. Стоимость ПО
для заказчика с учетом прибыли составила 733277рублей.
59
Таким образом, все поставленные задачи были выполнены, а цель достигнута.
60
СПИСОК ЛИТЕРАТУРЫ
1.
Аврамчук Е.Ф. Технология системного моделирования/ Е.Ф. Ав-
рамчук, А.А. Вавилов, С.В. Емельянов и др.; Под общ. ред. С.В. Емельянова
и др. – М.: Машиностроение; Берлин: Техник, 1988. – 520 с.
2.
Арлоу, Дж. UML 2 и Унифицированный процесс. Практический
объектно-ориентированный анализ и проектирование/ Дж. Арлоу, А. Нейштадт – 2-е изд. – Символ-Плюс, 2007. – 624 с.
3.
Бахтизин, В. В. Методология функционального проектирования
IDEF0: учеб. пособие по курсу «Технология разработки программного обеспечения» / В. В. Бахтизин, Л. А. Глухова – Минск: БГУИР, 2003. – 24 с.
4.
Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. – М.:Лори,
2004. – 510 с.
5.
Буч, Г. Язык UML. Руководство пользователя./ Буч Г., Рамбо Д.,
Якобсон И. – 2-е изд. изд. – М.: ДМК Пресс, 2006. – 496 с.
6.
Вендров А. М. Проектирование программного обеспечения эко-
номических информационных систем / А. М. Вендров. – 2-е изд., перераб. и
доп. изд. М.: Финансы и статистика, 2006. – 544 с.
7.
Виленский, П. Л. Оценка эффективности инвестиционных проек-
тов. Теория и практика: учеб. пособие – 2-е изд., перераб и доп – М.:Дело,
2002. – 888 с.
8.
Воронцовский, А. В. Инвестиции и финансирование: Методы
оценки и обоснования / А. В. Воронцовский. – СПб. : Изд-во С.Петербургского ун-та, 1998. – 528 с.
9.
ГОСТ 24.103–84 Автоматизированные системы управления. Об-
щие положения. Введ. 01.07.1985. . – М.: Изд-во стандартов, 1985.
10.
ГОСТ Р ИСО/МЭК ТО 12207–99 Информационная технология.
Процессы жизненного цикла программных средств. Введ. 01.07.2000. – М.:
Изд-во стандартов, 2000.
61
11.
Грачева, М. В. Управление рисками в инновационной деятельно-
сти: учеб. пособие для студентов вузов, обучающихся по экономическим
специальностям/ М. В. Грачева, С. Ю. Ляпина. – М.: ЮНИТИ-ДАНА, 2010. –
351 с.
12.
Заренков, В. А. Управление проектами: учебное пособие / В. А.
Заренков. – 2-е изд. – М.: Изд-во АСВ, 2006. – 312 с.
13.
Информационные системы и технологии в экономике и управле-
нии / Под ред. В. В. Трофимова. – М.: Высш. образование, 2006. – 480 с.
14.
Ишимова А. Ю. Анализ и реинжиниринг бизнес-процессов пред-
приятия [текст] / А. Ю. Ишимова, Г. А. Гареева // Science Time – 2015. – №2
(14). – С. 57-61.
15.
Каталевский, Д.Ю. Основы имитационного моделирования и сис-
темного анализа в управлении: учебное пособие; 2-е изд., перераб. и доп. /
Д.Ю. Каталевский. — М.: Издательский дом «Дело» РАНХиГС, 2015. —
496с.
16.
Клейнер Г.Б. Стратегия предприятия/ Г.Б. Клейнер – М.: Изда-
тельство «Дело» АНХ, 2008. – 568 с.
17.
Коберн, А. Современные методы описания требований к систе-
мам/ А. Коберн – М.:Лори, 2011. – 288 с.
18.
Кугаенко А.А. Методы динамического моделирования в управле-
нии экономикой: Учебное пособие с компакт-диском/ Под ред. П.Е. Кондрашова. - 2-е изд., испр. и доп. – М.: Университетская книга, 2005. – 456 с.
19.
Ларман, К. Применение UML 2.0 и шаблонов проектирования.
Введение в объектно-ориентированный анализ, проектирование и итеративную разработку / К. Ларман – Вильямс, 2013. – 736 с.
20.
Лычкина Н.Н. Имитационное моделирование экономических
процессов. Учебное пособие / Н.Н. Лычкина – М.: Инфра-М, 2012. – 253 с.
21.
Мазур, И.И. Управление проектами: учеб. пособие для студентов,
обучающихся по специальности «Менеджмент организации» / И. И. Мазур,
В.Д. Шапиро. – 6-е изд. – М.: Издательство «Омега-Л», 2010. – 960 с.
62
22.
Новиков, А. Ф. Анализ и проектирование на языке UML / А. Ф.
Новиков. – СПб.: ИТМО, 2007. – 286 с.
23.
Новиков, Л. Введение в Rational Unified Process / Л. Новиков.
24.
Орлова Ю. А. Методика анализа текста технического задания
[текст] / Ю.А. Орлова // Известия Тульского государственного университета.
Технические науки. – 2011. – №3. – С. 213-220.
25.
Попова Л. П. Моделирование системы управления технологиче-
ским процессом обогащения с помощью методологий IDEF0 [текст] / Л. П.
Попова, А. Г. Олейник // Труды Кольского научного центра РАН – 2010. –
№3. – С. 139-145.
26.
Разу, М.Л. Управление проектом. Основы проектного управле-
ния: Учебник / М.Л. Разу. – М.: КНОРУС, 2007. – 749 с.
27.
Рамбо, Д. UML 2.O. Объектно-ориентированное моделирование и
разработка / Д. Рамбо, М. Блаха. – 2-е изд. изд.– СПб.: Питер, 2007. – 544 с.
28.
РД IDEF0–2000. Методология функционального моделирования
IDEF0. –М.: Изд-во стандартов, 2000. – 75 с.
29.
Черемных, С. В. Моделирование и анализ систем. IDEF-
технологии / С. В. Черемных, И. О. Семенов, В. С. Ручкин. – М.: Финансы и
статистика, 2006. – 192 с.
30.
Шеер, А.В. ARIS – моделирование бизнес-процессов / А.В. Ше-
ер.– 3-е изд. – М.: Вильямс, 2010. – 224 с.
63
Аннотация
Туристическое агентство является сложной системой, при принятии
решения требуется учитывать множество факторов, исследовать систему в
динамике с учетом поведенческих аспектов, что обуславливает необходимость построения модуля поддержки принятия решения. Также для поддержания конкурентоспособности туристические фирмы должны постоянно повышать качество обслуживания клиентов, что невозможно без разработки,
внедрения и функционирования современных систем автоматизации. С помощью информационной системы (ИС) турагентства повышается производительность труда, улучшается эффективность управления фирмой.
Целью данной работы является проектирование ИС сопровождения
деятельности туристического агентства и построение интерактивной модели
принятия решения. Объектом исследования магистерской работы является
деятельность туристического агентства. Предмет исследования составляют
технологии моделирования поведения сложных систем, а также технологии
проектирования программного обеспечения. При выполнении работы принимались следующие теоретические методы: методы системной динамики,
финансового планирования, проектирования ИС (нотации IDEF0, IDEF3,
BPMN, UML). Для получения экономических данных и их последующей обработки использовались технологии экспертного оценивания и технологии
построения причинно-следственных диаграмм. Полученные результаты
имеют практическую значимость. В частности, они могут быть использованы
при проектировании и разработке ИС туристического агентства.
Магистерская диссертация состоит из введения, двух глав, заключения,
списка литературы из 30 наименований. Основной текст изложен на 62 страницах машинописного текста, содержит 15 рисунков.
Ключевые слова: системная динамика, IDEF-технологии, язык UML,
нотация BPMN, вариант использования, актер, спецификация, класс, пакет,
интерфейс, продукционные правила, сетевой график, матрица ответственности.
;l :: il ,ni},lil * р
{q*жtffi
-ýJЗ&ГМеТ
жýiыi;W.
W_"-.-"_л:
]t**рll"тЁ
W
i{.}ь{тьЕн}{lэ8,ь1
Орловский
/btBilt
ГУ
спрлвкл
о результатах проверки текстового документа на
наличие заимствований
пповепка выполнена в системе
' Антиплагиат.ВУЗ
Автор работы
енегя,рева Татьяrrя СýргёеЕfi Ь
Факульте,г. кафелра,
H0\,lep гр},пгlы
Физико-матем атический факультrг,
экономика
Тип работы
.Щиrrломная работа
Название работы
Раsработхаинф<iртаа
gЁЕФй.]Мсr,ýиъi,t} l ЁМФёfr€ýцо_,Ё€МýФ
.йtлiёрЪ_ýtввая
,
модель и про9ктироваgие
Название файла
Спегирсва Татьяяа СсрrвоВла;dосх
Проuент заимствOвания
30,78Уо
IIрочент цитирования
0,8буо
Проuент оригинLlьносl,и
68,36%
/]ата проверки
l l : 12:
Молули поиска
Молулъ поиска ЭБС "БиблиоРоссика';; Цшгирвание; Модуль пOцска ЭБС
"УнЬерситетская бибпаоiека оклайн"; КоллёкцЙ диссертачий РБl Коллекlия
I2
13 lrюня 201 7г.
Мs.дуль!оиска
ы-IвRДRY.кU;,Молульпоиsка'lАйб}ýiоltiМодулъ.й9.цýка
ЭБС "Лань"; Молупь поиска "ФГБОУ ВО ФГY иЙ, И€, ТурrетlСрдl;,ДgФ,льчо вузов,
Работу, провариrl
Селютин Владим ир .I[митриевич'
Ф1,1(J
flроверяк}щего
К,-"ffi",:",,:,,l:.;
[ата по;tttиси
Чтобы убедиться
в поминности справки,
используйте QR-код, который
содержит ссылку на 0тчет,
л.и обнаруженное заимствовавие
коррёктным, система оставhяет на усмотрение про8еряюцего.
предоставленная информация не помежит использованию в
коммерческих целях.
Орет на вопрос/ является
1/--страниц
Пожаловаться на содержимое документа