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

Техническое задание по ГОСТ 34.602-89

 

Сформируем техническое задание на создание информационной системы для фитнес-центра:

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

Полное наименование системы: ИС «Учет клиентов для фитнес-центра».

Наименование предприятия разработчика и заказчика системы и их реквизиты:

Заказчик:

Разработчик:

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

Методология SADT (метод IDEF0, метод IDEF1X, метод IDEF3, нотация в терминах DFD), ГОСТ 34.602-89.

Плановые сроки начала и окончания проекта по созданию системы:

Начало: 14.01.2014 г.

Окончание: 03.06.2014 г.

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

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

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

3) Характеристика объектов автоматизации представлена в таблице 1.

 

Таблица 1 - Характеристика объектов автоматизации

Наименование процесса	Возможность автоматизации	Решение об автоматизации в ходе проекта
Регистрация клиентов	Возможна	Будет автоматизирован
Обработка анкет здоровья	Возможна	Будет автоматизирован
Сохранение и увеличение клиентской базы	Возможна	Будет автоматизирован

 

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

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

) Требования к структуре и функционированию

В системе можно выделить информационное хранилище - базу данных (Microsoft Access 2010). Система должна обеспечивать работу пользователей в режиме 12 часов в день, 7 дней в неделю.

) Требования к численности и квалификации персонала системы и режиму его работы

Конечный пользователь системы должен обладать навыками работы на компьютере (Microsoft Office), а также знаниями соответствующей предметной области.

) Требования к функциям

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

) Требования к видам обеспечения

СУБД Access (версия не ниже 2007)

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

Создание информационной системы учета клиентов. Начало этапа: 14.01.2014 г., конец этапа: 30.05.2014 г.

) Источники разработки

ГОСТ 34.602-89 - «Техническое задание на создание автоматизированной системы»;

ГОСТ 34.601-90 - «Автоматизированные системы. Стадии создания»;

Методология SADT (IDEF-методы, DFD);

Унифицированный язык моделирования UML.

 

Моделирование системы

 

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

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

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

Одним из главных блоков разрабатываемой системы является информационное хранилище - база данных. Для разработки базы данных «Работа с клиентами» использовался расширенный метод IDEF1X.

Сущности: Клиенты, Учет, Абонемент, Тренеры, Залы, Скидки. Сущность Клиенты содержит атрибуты: Фамилия, Имя, Отчество, Телефон, Дата_рождения, Место_жительства, Эл_почта. Таким образом, в базу данных вносится основные данные клиента. Сущность Учет содержит атрибуты: Начало_действия, Конец_действия - это сроки действия клубной карты, которую приобретает клиент, также Сумма, которую он должен оплатить и атрибут Оплачено, который в дальнейшем будет отображать наличие оплаты либо ее отсутствие. Сущность Абонемент содержит атрибуты: Наименование (описание занятия, на которое выдается абонемент), Цена этого абонемента (за месяц). Сущность Тренеры содержит атрибуты: Фамилия, Имя, Отчество и Должность. Это также основные данные тренера. Сущность Залы содержит атрибуты: Название (залом также называется бассейн, теннисный корт и т.д.), Площадь этого зала. У сущности Скидки один атрибут - Сумма (в%). Преобразовав типы данных, получаем физическую модель.

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

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

 

Таблица 2 - Описание сущностей физической модели

Сущность Клиенты
Ключ	Атрибут	Тип данных	Комментарий
(PK)	Код_клиента	Counter	Атрибут, однозначно идентифицирующий клиента
	Фамилия	Text (25)	Атрибут, содержащий фамилию клиента
	Имя	Text (15)	Атрибут, содержащий имя клиента
	Отчество	Text (30)	Атрибут, содержащий отчество клиента
	Телефон	Integer	Атрибут, содержащий номер телефона клиента
	Дата_рождения	Date/Time	Атрибут, содержащий дату рождения клиента
	Место_жительства	Text (40)	Атрибут, содержащий адрес клиента
	Эл_почта	Text (25)	Атрибут, содержащий электронный адрес клиента
(FK)	Код_тренера	Long integer	Атрибут, содержащий того тренера, занятия которого посещает клиент
(FK)	Код_скидки	Long integer	Атрибут, содержащий скидку (если есть)
Сущность Абонемент
Ключ	Атрибут	Тип данных	Комментарий
(PK)	Код_абонемента	Counter	Атрибут, идентифицирующий абонемент
	Наименование	Text (25)	Атрибут, содержащий описание данного абонемента
	Цена	Integer	Атрибут, содержащий цену абонемента (за месяц)
(FK)	Код_зала	Long integer	Атрибут, содержащий тот зал, в котором проходит занятие по данному абонементу
Сущность Учет
Ключ	Атрибут	Тип данных	Комментарий
(FK)	Код_клиента	Long integer	Атрибут, содержащий определенного клиента
(FK)	Код_абонемента	Long integer	Атрибут, содержащий определенный абонемент
	Начало_действия	Date/Time	Атрибут, содержащий дату начала действия
	Конец_действия	Date/Time	Атрибут, содержащий дату конца действия
	Сумма	Integer	Атрибут, содержащий сумму за все абонементы
	Оплачено	Yes/No	Атрибут, показывающий, произведена ли оплата
Сущность Тренеры
Ключ	Атрибут	Тип данных	Комментарий
(PK)	Код_тренера	Counter	Атрибут, однозначно идентифицирующий тренера
	Фамилия	Text (25)	Атрибут, содержащий фамилию тренера
	Имя	Text (15)	Атрибут, содержащий имя тренера
	Отчество	Text (30)	Атрибут, содержащий отчество тренера
	Должность	Text (50)	Атрибут, содержащий должность тренера
Сущность Скидки
Ключ	Атрибут	Тип данных	Комментарий
(PK)	Код_скидки	Counter	Атрибут, однозначно идентифицирующий скидку
	Сумма (в%)	Integer	Атрибут, содержащий скидку в%-ном выражении
Сущность Залы
Ключ	Атрибут	Тип данных	Комментарий
(PK)	Код_зала	Counter	Атрибут, однозначно идентифицирующий зал
	Название	Text (18)	Атрибут, описывающий предназначение зала
	Площадь	Integer	Атрибут, описывающий площадь зала (в м2)

 

Таким образом, получили ER-модель фитнес-центра. В дальнейшем она позволит реализовать конечную базу данных в среде Microsoft Access.

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

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

Опишем более подробно каждый из классов. Спецификация класса Клиент приведена в таблице 3.

 

Таблица 3 - Класс Клиент

Параметр	Значение
Комментарий	Класс, представляющий собой клиента фитнес-центра
Атрибуты	Фамилия, Имя, Отчество, Телефон, Дата_рождения, Место_жительства, Электронная_почта - данные о клиенте
Операции	Добавить клиента() Редактировать данные() Удалить клиента() Получить информацию о клиенте()

 

Спецификация класса Клубная карта приведена в таблице 4.

 

 

Таблица 4 - Класс Клубная_карта

ПараметрЗначение
Комментарий	Класс, представляющий собой клубную карту клиента с купленными абонементами
Атрибуты	Номер_карты, Начало_действия, Конец_действия
Операции	Создать клубную карту() Получить информацию()

 

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

Спецификация класса Абонемент приведена в таблице 5.

 

Таблица 5 - Класс Абонемент

ПараметрЗначение
Комментарий	Класс, представляющий собой абонементы, которые приобрел клиент
Атрибуты	Наименование, Цена
Операции	Оплатить абонемент() Получить информацию об абонементе()

 

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

Класс Клиент и Клубная_карта - отношение ассоциации, поскольку данные два класса просто связаны друг с другом и никакие другие типы связей здесь применить нельзя. Один клиент может приобрести несколько клубных карт, но каждая карта принадлежит только одному клиенту, поэтому кратность связи со стороны класса Клиент - 1, со стороны Клубная_карта - 1..n.

Класс Клубная_карта и Абонемент - отношение композиции, поскольку абонементы записаны на клубную карту, и без них карта существовать не может. На одной карте может быть записано несколько абонементов, а абонемент записан в одной карте, поэтому кратность связи со стороны Клубной_карты - 1, со стороны Абонемента - 1..n.

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

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

Добавим управляющий класс Управление_картами, который обеспечивает работу с клубными картами клиентов. Данный класс будет связан с классами Добавить_новую_картуи Клубная_карта. Отношение между классами Добавить_новую_картуиПараметры_карты- однонаправленная ассоциация с кратностью связи 1 к 1, поскольку один экземпляр класса Добавить_новую_картувзаимодействует только с одним экземпляром класса Параметры_карты. Отношение между классами Управление_картамии Клубная_карта - однонаправленная ассоциация с кратностью связи 1 к 1..n, поскольку один класс Параметры_карты может взаимодействовать с несколькими классами Клубная_карта.

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

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

Подробное описание всех компонентов диаграммы последовательности информационной системы представлено в таблице 6.

Таблица 6 - Спецификация диаграммы последовательности

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

 

Рассмотрим поведение системы с точки зрения внешнего наблюдателя. Для этого построим диаграмму прецедентов. Диаграмма прецедентов(USE CASE вариантов использования) является исходной концептуальной моделью системы в процессе ее проектирования и разработки.

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

.   Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

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

Кооперaция может быть предстaвленa нa двух уровнях:

) нa уровне спецификaции - покaзывaет роли клaссификaторов и роли aссоциaций в рaссмaтривaемом взaимодействии;

2) нa уровне примеров - укaзывaет экземпляры и связи, обрaзующие отдельные роли в кооперaции.

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

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

 

Заключение

имитационный информационный модель

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

При построении модели деятельности «AS-IS» («как есть») на диаграмме просматривается основная деятельность центра, где видно, что на сотрудников возлагается рутинный и, главное, неэффективный процесс регистрации клиентов в журнале. Особенно неудобным и нерациональным этот процесс становится при возрастающем потоке клиентов. Это усложняет работу не только отдельного сотрудника, но и всего центра.

Рассмотрев модель деятельности «TO-BE» («как должно быть»), видно, что в результате оптимизации всего одного пункта, происходит кардинальное изменение всего процесса работы. Существенно сокращается время регистрации клиента, появляется возможность быстрого поиска клиентов по различным параметрам, а также корректировка данных уже существующих клиентов. Кроме того, система позволяет реализовать лояльность по отношению к клиентам - это начисление скидок. Полностью исключается возможность ошибки, так как с помощью системы влияние человеческого фактора сводится к минимуму.

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

1) изучена предметная область фитнес-центра;

)   проведено обследование предприятия;

)   разработана информационная система.

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