Разработка технического задания на создание программного продукта для турагентства

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 10.06.2020
Размер файла 4,7 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Федеральное агентство связи

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

«Сибирский государственный университет телекоммуникаций и информатики» (СибГУТИ)

Кафедра математического моделирования бизнес-процессов

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

по дисциплине «Программная инженерия»

по теме: «Разработка технического задания на создание программного продукта для турагентства»

Факультет: ИВТ

Студент: Белова А. В.

Новосибирск 2019

Содержание

  • Введение
  • 1. Описание предметной области
    • 1.1 Введение в предметную область
    • 1.2 Элементы предметной области, их взаимосвязи
    • 1.3 Особенности и ограничения предметной области
    • 1.4 Используемые термины и сокращения
  • 2. Цель создания системы
    • 2.1 Формулировка цели создания системы
    • 2.2 Cуществующие аналоги системы
    • 2.3 Целевая аудитория, ожидаемый уровень использования
  • 3. Детализация функций системы
    • 3.1 Потребности заказчика в системе
    • 3.2 Описание функций системы и ее подсистем
    • 3.3 Диаграммы деятельности процессов системы
  • 4. Анализ категорий пользователей
    • 4.1 Категории пользователей системы
    • 4.2 Функциональные требования пользователей каждой категории
    • 4.3 Диаграмма вариантов использования системы
  • 5. Определение ограничений
    • 5.1 Анализ аппаратных особенностей и ограничений
    • 5.2 Анализ топологии и особенностей развертывания
    • 5.3 Определение технологических ограничений
  • 6. Совокупный список требований к системе
    • 6.1 Функциональные требования
    • 6.2 Специфические требования
    • 6.3 Прочие требования
  • 7. Выработка архитектурного решения
    • 7.1 Выбор технологической платформы
    • 7.2 Диаграммы классов системы
    • 7.3 Диаграммы состояний для классов системы
    • 7.4 Диаграммы компонентов системы
    • 7.5 Диаграмма размещения системы
  • 8. Подготовка календарного плана
    • 8.1 Оценка сложности реализации подсистем
    • 8.2 Выделение работ, построение сетевого графика
    • 8.3 Оценка сроков выполнения работ
    • 8.4 Оценка затрат на проект
  • Заключение
  • Список литературы

Введение

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

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

Функции магазина самообслуживания:

- изучение покупательского спроса на товары;

- формирование ассортимента товаров;

- составление заявок на завоз товаров;

- оказание торговых услуг покупателям.

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

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

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

Задачи:

1. Выбрать предметную область.

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

3. Подготовить техническое задание на разработку данной системы

1. Описание предметной области

1.1 Введение в предметную область

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

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

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

С помощью автоматизированной системы пропадет нужда в дополнительных сотрудниках компании.

1.2 Элементы предметной области, их взаимосвязи

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

1.3 Особенности и ограничения предметной области

Особенности:

ь Выбрать товары можно без посреднических взаимодействий с сотрудниками магазина;

ь Всегда можно проконсультироваться с менеджером и администратором;

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

Ограничения:

ь Увеличение числа краж. Система контроля за покупателями еще не совершенна;

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

1.4 Используемые термины и сокращения

МС - магазин самообслуживания.

ПО - программное обеспечение.

UML - Unifies Modeling Language.

АС - автоматизация системы.

2. Цель создания системы

2.1 Формулировка цели создания системы

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

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

Основными целями внедрения данной системы являются:

- Экономия рабочей силы;

- Снижение внутренних потерь - сокращение издержек;

-Снижение зависимости от персонала, расходов на его прием и обучение;

-Увеличение продаж при успешных внедрениях;

-Удобство эксплуатации;

-График работы оборудования кассы будет доступен в режиме нон-стоп.

2.2 Существующие аналогии системы

1. Auchan Holding. Номинально Ашан является главным структурным подразделением семейной корпорации «Ассоциация семьи Мюлье». Чтобы исключить контакт продавца с деньгами, в Ашане, были установлены терминалы самостоятельной оплаты покупок. На выходе из торгового зала разместили 13 станций сканирования -- кассы самообслуживания, где покупатель может расплатиться без помощи сотрудников ретейлера.

2. Магазин «Фасоль» без продавцов по франшизе METRO. Новая «Фасоль» станет флагманским магазином франчайзинговой программы. На площади 47 кв. м. в магазине представлены 1100 SKU. В магазине пройдут тестирование самые актуальные решения по автоматизации процессов операционной деятельности, будут доработаны новые сервисы, которые METRO впоследствии предложит своим партнерам-франчайзи. В частности, уже сейчас магазин использует электронные ценники, кассы самообслуживания, энергосберегающие холодильные системы и приложение «Фасоль на ладони» с возможностью удаленного мониторинга ключевых показателей деятельности магазина на мобильном устройстве. Концепция «без продавцов» полностью автоматизирует процесс покупки. Она призвана повысить проходимость магазина до 500 человек в сутки на одну кассу и оптимизировать работу персонала. Для периодического контроля работы магазину требуется один стюард на количество до 5 касс.

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

4. Российская розничная сеть «Лента» объявила об открытии тридцать девятого гипермаркета в Новом Девяткино в Санкт-Петербурге. Новый магазин общей площадью 8 655 кв.м получил 22 кассы, из которых 6 являются кассами самообслуживания.

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

5. Гигантские магазины IKEA по всему миру будут постепенно переходить на современные технологии самообслуживания. Самообслуживание всегда было важной частью и концепцией магазинов IKEA, но, до недавнего времени, процесс оплаты был одной из немногих вещей в магазинах IKEA, которую клиент не мог осуществить самостоятельно. Установленные электронные киоски обеспечивают быстрый процесс покупки, увеличивая скорость обслуживания и уменьшая время ожидания клиентов на кассах. IKEA Warrington, британский магазин был одним из первых, внедривший кассы самообслуживания. Проведенное двухнедельное наблюдение показало, что 90 % клиентов, которые использовали кассу самообслуживания, остались довольны легкость и быстротой обслуживания. Целью традиционных касс в магазинах IKEA сегодня состоит в том, чтобы иметь одного клиента, платящего и до трех ожидающих оплаты. Для касс самообслуживания целью является четыре платящих клиента и один ожидающий. Для клиентов это выбор оплатить с меньшим временем ожидания на кассах самообслуживания или в обычной кассе с помощью кассира. Это повышает эффективность и удовлетворенность потребителя в области оплаты.

2.3 Целевая аудитория, ожидаемый уровень использования

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

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

3. Детализация функций системы

3.1 Потребности заказчика в системе

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

Внедрение проекта самообслуживания должно минимизировать очереди и уменьшить время ожидания клиентов при покупке товара, повышая эффективность. Контроль самообслуживания позволяет клиентам просмотреть и заплатить за продукты быстро и легко

3.2 Описание функций системы и ее подсистемы

Подсистема тур агента:

Ш Прием/отклонение заявки на тур.

Ш Оперативный учет обращений туристов;

Ш Автоматический расчет суммы тура, управление заявками туристов с детализацией услуг и автоматическим оформлением документов;

Ш Система учета платежей, ведения бухгалтерии и финансового планирования.

Ш Информационное обеспечение пользователей.

Ш Обработка поступающих запросов.

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

Ш Формирование электронного каталога.

Ш Хранение документации в электронном виде.

Ш Базовый документооборот.

Ш Бонусы и скидки.

Подсистема клиента:

Ш Каталог туров.

Ш Каталог горящих туров.

Ш Бонусная карта постоянного клиента.

Ш Отзывы и фото

Ш SMS и e-mail рассылки по клиентской базе.

3.3 Описание функций системы и ее подсистемы

Рис. 4 - Диаграмма деятельности процессов системы

Рис. 5 - Декомпозированная диаграмма деятельности для процесса «Получить счет»

4. Анализ категорий пользователей

4.1 Категории пользователей системы

На основе предоставляемых возможностей системы можно выделить следующие категории пользователей:

1. Менеджеры (сотрудники магазина)

2. Покупатели (студенты, взрослые, пенсионеры, дети, частные лица)

4.2 Функциональные требования пользователей каждой категории

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

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

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

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

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

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

* Аппаратно-программный комплекс системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.

Штатный состав персонала, эксплуатирующую системы, должен формироваться на основании нормативных документов Российской Федерации.

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

Для физических лиц необходимо наличие документов в соответствии с законодательством РФ.

4.3 Диаграмма вариантов использования системы

Диаграмма вариантов использования (use case diagram) определяет поведение системы с точки зрений пользователя. Диаграмма Use Case рассматривается как главное средство для первичного моделирования динамики системы, используется для выяснения требований к разрабатываемой системе, фиксирования этих требований в форме, которая позволит проводить дальнейшую разработку. Диаграммы вариантов использования часто называют диаграммами прецедентов.

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

Правила разработки диаграмм вариантов использования:

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

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

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

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

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

Рис. 6 - Диаграмма вариантов использования

5. Определение ограничений

5.1 Анализ аппаратных особенностей и ограничений

В состав комплекса должны следующие технические средства:

§ ПК тур агента;

§ Серверы БД.

Серверы БД, серверы приложений и сервер системы формирования отчетности должны быть объединены одной локальной сетью, с пропускной способностью не менее 100 Мбит.

Требования к техническим характеристикам серверов БД:

· Процессор - 2 х Intel Xeon 3 ГГц;

· Объем оперативной памяти - 16 Гб;

· Дисковая подсистема - 4 х 146 Гб;

· Устройство чтения компакт-дисков (DVD-ROM);

· Сетевой адаптер - 100 Мбит.

Требования к техническим характеристикам ПК пользователя и ПК администратора:

· Процессор - Intel Pentium 1.5 ГГц;

· Объем оперативной памяти - 256 Мб;

· Дисковая подсистема - 40 Гб;

· Устройство чтения компакт-дисков (DVD-ROM);

· Сетевой адаптер - 100 Мбит.

Требования к техническим характеристикам ПК пользователя и ПК администратора:

· Процессор - Intel Pentium 1.5 ГГц;

· Объем оперативной памяти - 256 Мб;

· Дисковая подсистема - 40 Гб;

· Устройство чтения компакт-дисков (DVD-ROM);

· Сетевой адаптер - 100 Мбит.

5.2 Анализ топологии и особенностей развертывания

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

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих только на этапе ее исполнения (run-time). При этом представляются только те компоненты программы, которые являются исполнимыми файлами или динамическими библиотеками. Компоненты, не используемые на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.

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

5.3 Определение технологических ограничений

Система может эксплуатироваться на любых компьютерах работающих под управлением MS Windows: XP/2000/Vista/2003/2008/Win 7/Win 10.

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

сервер развертывание архитектурный пользователь

6. Совокупный список требований к системе

6.1 Функциональные требования

Диаграмма последовательности - диаграмма, предназначенная для представления взаимодействия между элементами модели программной системы в терминологии линий жизни и сообщений между ними.

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

· Диаграмма последовательности «Заказ товаров»;

Рис. 8 - Диаграмма последовательности «Заказ товаров»

Рис. 9 - Диаграмма последовательности «Управление поставкой»

· Диаграмма последовательности «Управление поставкой»;

· Диаграмма последовательности «Учет товара»;

· Диаграмма последовательности «Покупка товара»;

· Диаграмма последовательности «Обработка товара».

Рис. 10 - Диаграмма последовательности «Учет товара»

Рис. 11 - Диаграмма последовательности «Покупка товара»

Рис. 12 - Диаграмма последовательности «Обработка покупки»

6.2 Специфические требования

К специфическим требованиям можно отнести:

· Многоязычность продукта;

· Отчет по книгам (какие взяли, какие вернули, какие купили), по новым клиентам;

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

6.3 Прочие требования

· Эксплуатационная документация;

· Периодическое техническое обслуживание;

· Возможность организации автоматического и/или ручного резервного копирования данных системы.

7. Выработка архитектурного решения

7.1 Выбор технологической платформы

Проектирование системы должно быть выполнено с использованием UML - унифицированного языка моделирования и объектно-ориентированного подхода. Реализация должна быть выполнена на Visual Studio 2013.

7.2 Диаграммы классов системы

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

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

В данной курсовой работе было разработано 5 диаграмм классов:

· Диаграмма классов «Заказ товаров»;

· Диаграмма классов «Управление поставкой»;

· Диаграмма классов «Учет товара»;

· Диаграмма классов «Покупка товара»;

· Диаграмма классов «Обработка товара».

Рис. 13 - Диаграмма классов «Заказ товаров»

Рис. 14 - Диаграмма классов «Управление поставкой»

Рис. 15 - Диаграмма классов «Учет товара»

Рис. 16 - Диаграмма классов «Покупка товара»

Рис. 17 - Диаграмма классов «Обработка покупки»

7.3 Диаграммы состояний для классов системы

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

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

В данной курсовой работе мной было разработано 5 диаграмм состояний:

1. Диаграмма состояний «Заказ товаров»;

2. Диаграмма состояний «Управление поставкой»;

3. Диаграмма состояний «Учет товара»;

4. Диаграмма состояний «Покупка товара»;

5. Диаграмма состояний «Обработка покупки».

Рис. 18 - Диаграмма состояний «Заказ товаров»

Рис. 19 - Диаграмма состояний «Управление поставкой»

Рис. 20 - Диаграмма состояний «Учет товара»

Рис. 21 - Диаграмма состояний «Покупка товаров»

Рис. 22 - Диаграмма состояний «Обработка покупки»

7.4 Диаграммы компонентов системы

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

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

В данной курсовой работе мной было разработано 5 диаграмм компонентов:

· Диаграмма компонентов «Заявка на тур»;

· Диаграмма компонентов «Заказанные услуги»;

· Диаграмма компонентов «Заявка на визу»;

· Диаграмма компонентов «Договор по билетам»;

· Диаграмма компонентов «Заключение договора».

Рис. 23 - Диаграмма компонентов «Заявка на тур»

Рис. 24 - Диаграмма компонентов «Заявка на визу»

Рис. 25 - Диаграмма компонентов «Заказанные услуги»

Рис. 26 - Диаграмма компонентов «Договор по билетам»

Рис. 27 - Диаграмма компонентов «Заключение договора»

7.5 Диаграмма размещения системы

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

Диаграмма размещения, предназначена для визуализации элементов и компонентов программы, существующих только на этапе ее исполнения (run-time). При этом представляются только те компоненты программы, которые являются исполнимыми файлами или динамическими библиотеками. Компоненты, не используемые на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме развертывания они не указываются.

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

Рис. 28 - Диаграмма размещения

8. Подготовка календарного плана

8.1 Оценка сложности реализации подсистем

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

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

V(G) = E ? N + 2,

где: V - цикломатическая сложность, E - количество дуг в ориентированном графе G, N - количество вершин.

В данной работе подсчет необходимых параметров будет производиться на основе диаграммы компонентов (рис.27 - Диаграмма компонентов заключения договора). Где число ребер E = 10, число вершин N = 8. В таком случае цикломатическая сложность программы считается: V(G) = 10 - 8 = 2.

8.2 Выявление работ, построение сетевого графика

Рис. 29 - Сетевой график

Рис. 30- Диаграмма Ганта

8.3 Оценка сроков выполнения работ

Рис. 31 - Диаграмма Ганта

Рис. 32 - Сведения о проекте

Рис. 33 - Статистика проекта

На реализацию проекта в общей сложности уйдет 190 дней (включая выходные).

8.4 Оценка затрат на проект

Рис. 34 - Отчет по движению денежных средств

Заключение

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

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

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

В соответствии с поставленными задачами были выполнены следующие этапы создания технического задания:

· выполнен анализ предметной области;

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

· описаны все ограничения и требования к информационной системе.

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

1. Studbooks.net - Анализ деятельности туристической фирмы

2. С.Ю. Золотов. Проектирование информационных систем: Учебное пособие. - Томск: ТМЦДО, 2005 - 88

3. В.Б. Сибилев. Проектирование баз данных: учебное пособие. - Томск: ТМЦДО, 2007

4. Маклаков С.В. BPWin и ERWin. CASE - средства разработки информационных систем. - М.: ДИАЛОГ - МИФИ, 1992.

5. Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1978. - 616 с.: ил.

6. CRMindex - CRM для турагентства

7. САМО СОФТ - САМО - турагент - автоматизация турагентства, CRM для турагентств

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

...

Подобные документы

  • Анализ предметной области, потребности различных категорий пользователей разрабатываемой базы данных. Описание концептуальной схемы и преобразование ее в реляционную БД. Создание ER-модели в среде ER-Win. Генерация файлов, разработка запросов в SQL.

    курсовая работа [786,4 K], добавлен 15.12.2013

  • Оценка предметной области: концептуальные требования; выявление информационных объектов и связей между ними; построение базы данных. Описание входных и выходных данных информационной системы "Магазин компьютерной техники". Анализ диаграммы прецедентов.

    курсовая работа [294,8 K], добавлен 13.04.2014

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

    курсовая работа [3,5 M], добавлен 14.05.2015

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

    курсовая работа [706,2 K], добавлен 17.06.2012

  • Реализация базы данных и серверной части информационной системы склада средствами СУБД Microsoft SQL Server. Анализ предметной области, информационных задач, пользовательской системы. Программа реализации проекта. Выработка требований и ограничений.

    курсовая работа [2,4 M], добавлен 15.11.2015

  • Возможности создания баз данных средствами программного продукта SQL. Изучение предметной области и разработка проекта базы данных по учету студентов "Журнал классного руководителя". Задачи реализации программного средства, его тестирование и отладка.

    курсовая работа [3,7 M], добавлен 07.12.2012

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

    курсовая работа [877,8 K], добавлен 28.05.2012

  • Информационно-логическая модель предметной области по нотациям Ричарда Баркера. Даталогическая модель реляционной базы данных в виде диаграммы схемы отношений. Приложение интерфейса для базы данных на языке программирования С# в среде Visual Studio.

    курсовая работа [3,6 M], добавлен 23.12.2014

  • Организация, архитектура и структура информационной системы. Показатели эффективности ее работы. Цели и задачи анализа АСУ. Компоненты автоматизированных систем. Описание предметной области, входных и выходных данных. Построение диаграммы прецедентов.

    курсовая работа [231,0 K], добавлен 11.04.2014

  • Программные продукты, используемые при проектировании базы данных. Разработка базы данных "Библиотека" с использование программного проекта Microsoft SQL Server. Создание таблиц, триггеров, пользователей, репликации, запросов, функций, процедур.

    курсовая работа [897,6 K], добавлен 21.11.2011

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

    курсовая работа [4,3 M], добавлен 02.11.2015

  • Анализ предметной области с использованием моделей методологии ARIS и разработка ER-диаграммы. Описание входной и выходной информации для проектирования реляционной базы данных. Разработка управляющих запросов и связей между ними с помощью языка SQL.

    курсовая работа [975,2 K], добавлен 30.01.2014

  • Разработка информационной базы данных для компании с помощью СУБД Microsoft Office Access. Построение семантической модели предметной области. Листинг программного продукта: создание и заполнение таблиц. Инструкция по применению автоматизированной ИС.

    курсовая работа [1010,5 K], добавлен 26.03.2014

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

    курсовая работа [2,0 M], добавлен 11.01.2014

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

    курсовая работа [816,5 K], добавлен 05.02.2018

  • Описание предметной области, техническое задание на разработку программного продукта. Проектирование структуры базы данных: ER-диаграмм, диаграммы функциональных зависимостей, набор основных таблиц и описание полей. Разработка руководства пользователя.

    курсовая работа [2,9 M], добавлен 25.11.2013

  • Анализ предметной области. Сравнительный анализ систем визуализации трёхмерных объектов. Обоснование выбора среды программирования. Разработка базы данных. Архитектура программного продукта. Алгоритм шифрования Blowfish с обратной связью по шифр-тексту.

    дипломная работа [5,3 M], добавлен 22.11.2015

  • Описание объекта информатизации и предметной области. Анализ параметров объектов предметной области, сбор исходных данных. Архитектура проекта, создание интерфейса базы данных. Поиск по объектам, датам. Редактирование, отчеты. Назначение программы.

    курсовая работа [2,3 M], добавлен 20.01.2016

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

    курсовая работа [30,2 K], добавлен 23.01.2011

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

    курсовая работа [1,6 M], добавлен 17.05.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.