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

Введение

программный автоматизация гостиница

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

По определению ВТО, гостиница - это коллективное средство размещения, состоящее из определенного количества номеров, имеющее единое руководство, предоставляющее набор услуг (минимум - заправку постелей, уборку номера и санузла) и сгруппированное в классы и категории в соответствии с предоставляемыми услугами и оборудованием номеров.

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

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

Также гостиница предоставляет возможность бронирования номеров.

Таким образом, в функционирование гостиницы входит:

Регистрация клиентов;

Учет состояния номеров;

Прием заявок на бронирование номеров;

Расчет стоимости проживания;

Ведение отчетности.

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

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

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

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

1. Предметная область

1.1 Профили стандартов

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

РД 50-34.698-90 - Испытания системы должны быть проведены на основании соответствующей программы и методики испытаний, разработанной исполнителем и утверждённой заказчиком. РД 50-34.698-90 используется в курсовом проекте на этапе отладки.

Стандарт ISO 15504:1-5:2003-2006 регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями. Он используется на каждом этапе написания курсового проекта.

ГОСТ 34.201--89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. Применяется при документировании проекта.

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

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

Целями диаграмм вариантов использования являются:

- достижение соглашения между разработчиками, заказчиками и пользователями о том, что должно делать программное средство;

- достижение лучшего понимания разработчиками поведения программного средства;

- ограничение системной функциональности;

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

- определение пользовательского интерфейса.

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



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

1.3 Кооперативные диаграммы

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

На рисунке 2 представлена диаграмма кооперации для варианта использования «Регистрация клиентов». Администратор вводит личные данные клиента, дату въезда и выезда, а также номер апартаментов, предоставленный клиенту. В итоге, все данные введенные администратором сохраняются в БД клиентов. Объектами выступают администратор, личные данные клиента, даты въезда и выезда, номер апартаментов и БД клиентов.



Рис. 2 Регистрация клиентов.

На рисунке 3 представлена диаграмма кооперации для варианта использования «Формирование отчетности». Администратор вносит все необходимые данные о номере в отчет, который впоследствии храниться в БД отчетов. Объектами выступают Администратор, окно нового отчета и БД отчетов.

Рис. 3 Формирование отчетности.

На рисунке 4 представлена диаграмма кооперации для варианта использования «Прием заявок на бронирование». Администратор вводит в систему личные данные о клиенте, дату въезда и выезда, а также тип номера в котором клиент хотел бы заселиться. Все данные хранятся в БД клиентов. Объектами выступают администратор, личные данные клиента, даты въезда и выезда, тип номера и БД клиентов.



Рис. 4 Прием заявок на бронирование.

На рисунке 5 представлена диаграмма кооперации для варианта использования «Расчет стоимости проживания». Администратор, взаимодействуя с ПК, запускает программу для расчета стоимости проживания - калькулятор. Рассчитанная сумма выводится в отчет вместе с детальной информацией по расчету.

Рис. 5 Расчет стоимости проживания.

На рисунке 6 представлена диаграмма кооперации для варианта использования «Учет состояния номеров». Администратор, взаимодействуя с программой, вносит сведения о состоянии номера, периодически обновляя их. Все данные о состоянии номеров хранятся в БД номеров отеля.



Рис. 6 Учет состояния номеров.

2. Выбор и обоснование средств и методов разработки

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

Для проектирования программного продукта по расчету стоимости проживания в гостиничном номере была выбрана методология объектно-ориентированного анализа и проектирования на языке UML. ArgoUML - бесплатное средство для создания UML-диаграмм. Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически

Argo UML является открытым программным обеспечением и распространяется под лицензией EPL. Особенности ArgoUML:

Предлагает интуитивно понятный и насыщенный пользовательский графический интерфейс;

Реализована возможность отмены/повтора действий пользователя;

Работает на любой платформе с установленным Java 5 или Java 6;

Поддержка спецификаций UML 1.3, 1.4, XMI 1.0, 1.1, 1.2, 9 видов диаграмм UML (диаграммы классов, состояний, кооперации, последовательности, деятельности, прецедентов, объектов, компонентов, развёртывания);

Поддержку OCL для классов;

Генерацию исходного кода на языках программирования Java, C++, C# и PHP;

Автоматическую верификацию модели UML (design critics).

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

UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

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

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

3. Проектирование логической структуры программного средства

3.1 Диаграммы классов

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

На рисунке 7 представлена диаграмма классов для программного средства расчета стоимости проживания в гостиничном номере. Выделены такие классы, как сотрудник, клиент, номер апартаментов и отчет. У каждого класса имеются свои атрибуты и операции.

Рис. 7 Диаграмма классов.

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

Таблица 1. Класс «Сотрудник».

Наименование	Обозначение	Тип	Размерность
Должность	Dol	String	100

Таблица 2. Класс «Клиент».

Наименование	Обозначение	Тип	Размерность
ФИО	FIO	String	150
Вид документа	Vid_dok	String	100
Номер документа	Nomer_dok	Integer	20
Место жительства	Mesto_git	String	100
Номер апартаментов	Nomer_apart	Integer	100

Таблица 3. Класс «Номер апартаментов».

Наименование	Обозначение	Тип	Размерность
Тип номера	Tip_nom	String	50
Количество комнат	Kol_komn	Integer	10
Общая площадь	Plosh	Integer	50

Таблица 4. Класс «Отчет».

Наименование	Обозначение	Тип	Размерность
Отчет	Otchet	Integer	40
БД отчетов	BD_otch	Integer	100

3.2 Диаграмма последовательности

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

Данный вид диаграмм отражает следующие аспекты проектируемой системы:

- обмен сообщениями между объектами (в том числе в рамках обмена сообщениями со сторонними системами);

- ограничения, накладываемые на взаимодействие объектов;

- события, инициирующие взаимодействия объектов.

На рисунке 8 изображена диаграмма последовательности для варианта использования «Регистрация клиентов». Администратор вводит личные данные клиента, дату въезда и выезда, а также номер апартаментов, предоставленный клиенту. В итоге, все данные введенные администратором передаются и сохраняются в БД клиентов.

Рис. 8 Регистрация клиентов.

На рисунке 9 представлена диаграмма последовательности для варианта использования «Формирование отчетности». Администратор вносит все необходимые данные о номере, далее отчет сохраняется и отправляется в БД отчетов.



Рис. 9 Формирование отчетности

На рисунке 10 представлена диаграмма последовательности для варианта использования «Прием заявок на бронирование». Администратор вводит в систему личные данные о клиенте, дату въезда и выезда, а также тип номера, в котором клиент хотел бы заселиться. В БД клиентов создается новая учетная запись в которой хранятся все данные о клиенте.

Рис. 10 Прием заявок на бронирование.

На рисунке 11 представлена диаграмма последовательности для варианта использования «Расчет стоимости проживания». Администратор вводит свои данные в ПК, далее происходит инициализация и аутентификация для подтверждения личности пользователя. Следующим действием является запуск программы для расчета стоимости проживания - калькулятор. Он рассчитывает предварительную стоимость проживания и сохраняет данные в отчет вместе с детальной информацией по расчету.



Рис. 11 Расчет стоимости проживания.

На рисунке 12 представлена диаграмма последовательности для варианта использования «Учет состояния номеров». Администратор вводит свои данные в ПК, далее происходит инициализация и аутентификация для подтверждения личности пользователя. Далее в окно состояния номера он вносит сведения о состоянии номера. Все данные о состоянии номеров хранятся в БД номеров отеля.

Рис. 12 Учет состояния номеров.

3.3 Диаграммы состояний

Диаграммы состояний используются для описания поведения отдельных объектов. У диаграммы состояний основными элементами являются «Переход» и «Состояние». Состояние может содержать только имя или имя и дополнительно список внутренних действий. Список внутренних действий содержит перечень действий или деятельностей, которые выполняются во время нахождения объекта в данном состоянии. Данный список фиксированный. Список основных действий включает следующие значения:

entry - действие, которое выполняется в момент входа в данное состояние (входное действие);

exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);

do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии

defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.

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



Рис. 13 Диаграмма состояния номера апартаментов.

3.4 Диаграммы деятельности

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

На рисунке 14 изображена диаграмма деятельности для объекта отчет. После входа в программу необходимо выбрать нужное действие. К ним относятся: добавить отчет, удалить отчет и открыть отчет. Далее происходит сохранение изменений выполненных пользователем. После сохранения программа предоставляет возможность отменить все действия или сохранить отчет.



Рис. 14 Диаграмма деятельности для объекта отчет.

3.5 Алгоритм работы программного средства.

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

Рис. 15 Алгоритм работы программного средства.

4. Разработка физической структуры программного средства

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

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

На рисунке 16 изображена диаграмма компонентов для программного средства по расчету стоимости проживания в гостиничном номере. Исполняемым компонентом является клиент, включающий интерфейс пользователя, средства графического отображения и файлы с расширением .exe. К библиотекам кода относятся БД, средства графического отображения, библиотеки программ и подпрограмм и файлы с расширением .exe. Между ними действует набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами, называемые протоколы TCP/IP.

Рис. 16 Диаграмма компонентов.

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

- Узел устройства;

- Узел среды выполнения.

На рисунке 17 представлена диаграмма развертывания для программного продукта по расчету стоимости проживания в гостиничном номере. На данной диаграмме узлом устройства является сервер администрации, а узлом среды выполнения является ПК клиента.

Рис. 17 Диаграмма развертывания.

5. Разработка интерфейсных компонентов программного средства

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

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

Рис. 18 Макет интерфейсных компонентов программного средства.

На рисунке 19 отображена форма для регистрации клиента. Здесь необходимо ввести личные данные клиента, такие как фамилия, имя, отчество, вид и номер документа, а также постоянное место жительства. Помимо личных данных, водится номер апартаментов и дата заезда. При нажатии кнопки регистрация, вся информация о клиенте попадает в БД клиентов.



Рис. 19 Регистрация клиента.

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

Рис. 20 Учет состояния номеров.

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



Рис. 21 Расчет стоимости проживания.

6. План выполнения работ по созданию программного продукта

На рисунке22 представлен план выполнения работ по курсовому проекту. На анализ предметной области отводится 17 дней. Из них 12 дней на постановку задачи, 5 дней на выбор профилей стандартов и 5 дней на выбор и обоснование средств и методов разработки.

На реализацию проекта отводится 37 дней. Из них 5 дней на разработку диаграммы вариантов использования. 19 дней на проектирование логической структуры и 8 дней на разработку физической структуры.

К проектированию логической структуры относятся разработка диаграмм: последовательности - 5 дней, кооперации - 2 дня, классов - 8 дней, состояния - 5 дней, деятельности - 5 дней.

К разработке физической структуры относится разработка: диаграммы развертывания - 4 дня, диаграммы компонентов - 4 дня и интерфейсных компонентов - 4 дня.

Заключительный этап - отладка, происходит в течении 7 дней.

Рис. 22 План выполнения работ.

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

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

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

Рис. 23 Диаграммы Ганта.

Заключение

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

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

В процессе создания были преодолены следующие этапы:

- изучение предметной области;

- выбор профилей стандартов;

- выбор и обоснование средств и методов разработки;

- проектирование логической структуры программного средства;

- разработка физической структуры программного средства;

- разработка интерфейсных компонентов программного средства;

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

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

- освобождению работников от рутинной работы за счет ее автоматизации;

- обеспечению достоверности информации;

- замене бумажных носителей данных на магнитные и оптические, что приводит к более рациональной организации переработки информации на компьютере и снижению объемов бумажных документов;

- уменьшению затрат на производство продуктов и услуг.

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

1. Грекул, В. И. Проектирование информационных систем [Текст] : курс лекций: учеб. пособие для вузов / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина . - М. : Интернет-Ун-т Информ. Технологий, 2005. - 304 с. : ил.. - (Основы информационных технологий). - Библиогр.: с. 298-299. - ISBN 5-9556-0033-7.

2. Леоненков, А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose [Текст] : учеб. пособие / А. В. Леоненков . - М. : Интернет-Ун-т Информ. Технологий : БИНОМ. Лаборатория знаний, 2006. - 320 с. - (Основы информационных технологий). - Библиогр.: с. 317-318. - ISBN 5-9556-0043-4. - ISBN 5-94774-408-2.

3. Мацяшек Л. Практическая программная инженерия на основе учебного примера [Текст] : учебное пособие/ Л.А. Мацяшек, Б.Л. Лионг: пер. с англ. - М.: БИНОМ. Лаборатория знаний, 2009. - 956 с.: ил. - (Программисту). ISBN/ISSN:978-5-94774-488-0.

4. Бухгалтерия Онлайн [Электронный ресурс]. - М.: BUHONLINE.RU, 2008 - 2014. Режим доступа: http://www.buhonline.ru/forum/index?g=posts&t=48918 - 28.11.2014.

Приложение

Техническое задание на разработку программного средства по расчету стоимости проживания в гостиничных номерах.

Общие сведения

Наименование системы

Полное наименование системы: Расчет стоимости проживания в гостиничном номере.

Краткое наименование системы: ПС РСП

1.3. Наименование организаций - Заказчика и Разработчика

1.3.1. Заказчик: Цыганова И. А.

1.3.2. Разработчик: Преснякова А.Н.

1.3. Плановые сроки начала и окончания работы: 1.09.2014 - 1.12.2014

1.4. Порядок оформления и предъявления заказчику результатов работ

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

1.5 Основания для проведения работ:

Основанием для исполнения работ в рамках развития функциональности ПС РСП, предусмотренных в настоящем Техническом Задании, является задание курсового проекта.

1.6 Нормативные документы.

Настоящее Техническое Задание разработано в соответствии с требованиями

- ГОСТ 34.60289 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

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

- ГОСТ 34. Информационная технология. Комплекс стандартов на автоматизированные системы.

- РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

2. Назначение и цели создания системы.

2.1. Назначение системы.

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

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

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

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

Цель системы ПС РСП:

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

- освобождение работников от рутинной работы за счет ее автоматизации;

- обеспечение достоверности информации;

- замена бумажных носителей данных на магнитные и оптические, что приводит к более рациональной организации переработки информации на компьютере и снижению объемов бумажных документов;

- уменьшение затрат на производство продуктов и услуг.

3. Характеристика объектов автоматизации.

Система позволит автоматизировать рабочие процессы расчета стоимости проживания в гостиничном номере и организовать оперативное взаимодействие с внешней САПР AutoCAD.

Основными процессами в ПС РСП будут являться:

- расчет предварительной стоимости проживания в гостиннице;

- осуществление и контроль процессов экспертизы и согласования рабочих продуктов проекта;

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

- учет состояния номеров в отеле;

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

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

В ПС РСП предлагается выделить следующие функциональные подсистемы:

- подсистема сбора, обработки и загрузки данных, которая предназначена для реализации процессов сбора данных из систем источников (САПР AutoCAD), приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных;

- подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений;

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

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

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

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

4.1.2 Требования к гарантийному периоду

Гарантийный период (срок предоставления гарантии качества работ) на аппаратное обеспечение и другие работы, выполняемые в соответствии с настоящим контрактом, составляет 24 месяцев с момента утверждения акта сдачи-приемки работ. В случае выявления в течение этого срока недостатков в программах для ЭВМ или иных разработках, составляющих результаты работ, Исполнитель обязуется по требованию Заказчика незамедлительно устранять такие недостатки за свой счет. При этом гарантийный срок продлевается на период устранения недостатков.

4.1.3. Требования к надежности

4.1.3.1. Состав показателей надежности для системы в целом:

Уровень надежности должен достигаться согласованным применением организационных, организационно-технических мероприятий и программно-аппаратных средств.

Надежность должна обеспечиваться за счет:

- применения технических средств, системного и базового программного обеспечения;

-соответствующих классу решаемых задач;

-своевременного выполнения процессов администрирования Системы РП;

-соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

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

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

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

- при перерыве и выходе за установленные пределы параметров программного обеспечением -- не более 2 часов.

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

При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:

- сбой в электроснабжении сервера;

- сбой в электроснабжении рабочей станции пользователей системы;

- сбой в электроснабжении обеспечения локальной сети (поломка сети);

- ошибки Системы, не выявленные при отладке и испытании системы;

- сбои программного обеспечения сервера.

4.1.3.3. Требования к надежности технических средств и программного обеспечения

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

- предварительного обучения пользователей и обслуживающего персонала;

- своевременного выполнения процессов администрирования;

- периодические технические осмотры программно-аппаратных средств;

- периодические тестирования процессов функционирования ПС РСП;

-соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

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

Надежность программного обеспечения подсистем обеспечивается за счет:

- надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;

- проведением комплекса мероприятий отладки, поиска и исключения ошибок;

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

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

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

4.1.4. Требования к эргономике и технической эстетике.

Ко всем подсистемам ПС РСП предъявляются следующие требования к эргономике и технической эстетике.

В части внешнего оформления:

-интерфейсы по подсистемам должен быть типизированы.

В части диалога с пользователем:

-для наиболее частых операций должны быть предусмотрены «горячие» клавиши;

-при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке;

-должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;

- наиболее часто используемые операции должны быть организованы в отдельную область на панели инструментов.

В части процедур ввода-вывода данных:

- должна быть возможность получения отчетности по мониторингу работы подсистем;

- должна быть предусмотрена клавиша «История» для быстрого доступа к ранее сделанным графикам, а также для последующего их использования в других проектах;

-должна быть сформирована история графиков;

- при возникновении ошибок в работе подсистемы на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке;

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

4.1.5. Требования к защите информации от несанкционированного доступа

4.1.5.1. Требования к информационной безопасности.

Обеспечение информационное безопасности ПС РСП должно удовлетворять следующим требованиям:

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

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

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

4.1.5.2. Требования к антивирусной защите

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

Средства антивирусной защиты рабочих местах пользователей и администраторов должны обеспечивать:

- централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;

- централизованную автоматическую инсталляцию клиентского ПО на рабочих местах пользователей и администраторов;

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

- ведение журналов вирусной активности;

- администрирование всех антивирусных продуктов.

4.1.5.3. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

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

4.1.5.4. Требования к контролю, хранению, обновлению и восстановлению данных

К контролю данных предъявляются следующие требования:

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

К хранению данных предъявляются следующие требования:

- хранение исторических данных в системе должно производиться не более чем за 3 (три) предыдущих года. По истечению данного срока данные должны переходить в архив;

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

К обновлению и восстановлению данных предъявляются следующие требования:

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

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

Технико-правовые требования.

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

4.1.7 Пользователи ПС РСП.

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

4.1.7.2 Пользователи системы:

- Главный проектировщик принимает и контролирует работу рядового проектировщика в части составления планировки и документации, участвует в испытаниях Системы, по итогам которых по мере необходимости проводит корректировку документации и устраняет выявленные недостатки программного обеспечения;

- Проектировщик является непосредственным пользователем ПС РСП: использует все возможности Системы в построении графиков, отчетов, взаимодействует через ПС РСП с САПР AutoCAD;

4.2.1 Требования к организационному обеспечению.

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

- решение административных вопросов (организация встреч, предоставление допусков, рассмотрение и согласование проектной документации и т.п.);

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

- нормативно-методическое и информационное обеспечение проектных работ.

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

Требования к методическому обеспечению.

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

- ГОСТ 34. Информационная технология. Комплекс стандартов на автоматизированные системы;

- ГОСТ 19. Единая система программной документации;

-РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

5. Состав и содержание работ по созданию системы.

Стадии и этапы работ по созданию системы выполняются в соответствие с планом курсового проекта.

6. Порядок контроля и приёмки системы

6.1. Сдача-приёмка работ.

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

6.2.Испытания.

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

По результатам испытаний оформляются:

- протокол испытаний;

- перечень выявленных недостатков и замечаний (при их наличии).

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

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

7. Требования к документированию.

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

7.1 Методологические материалы.

Доработанная пользовательская документация на ПС РСП:

- руководство пользователя ПС РСП,

- руководство администратора ПС РСП;

-регламент главного проектировщика по работе с ПС РСП;

- регламент проектировщика по работе с ПС РСП;

- регламент исполнителя по работе с ПС РСП;

- регламент эксперта по работе с ПС РСП.

7.2 Отчёт о выполненных работах по ГОСТ 7.32-2001, включающий разделы.

- о перечне выполненных доработок;

- о перечень запросов на техническую поддержку с описанием мер, предпринятых для выполнения запросов;

- о рекомендациях по развитию и дальнейшей поддержке ПС РСП.

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