Цель разработки
Целью работы является разработка программного средства для автоматизированного управления салоном красоты, а также оптимизацией приема и обработки различных заявок, поступающих от клиентов и мастеров. На момент написания технического задания система не имеет существующих аналогов. Целевой аудиторией являются работники салона красоты (Администратор, мастера, бухгалтер), а также клиенты, посещающие данный салон красоты.
Разработать программный продукт для салона красоты, позволяющий учитывать полный цикл взаиморасчетов с клиентом от момента записи до расчета за оказанные услуги. Автоматизация работы сотрудников салона.
Систематизация работы с поставщиками. Решение вопроса расчета с персоналом и хранения контактных данных сотрудников.
a) Анализ существующих потребностей заказчика в области автоматизированного управления салоном.
b) Совместная разработка с заказчиком технического задания.
c) Разработка, программирование и отладка.
d) Написание документации.
e) Опытная эксплуатация.
f) Разработка, программирование и отладка рабочей версии на основе замечаний, полученных по результатам опытной эксплуатации.
Система должна содержать программу, которая выполняет следующие функции:
a) создание новой учетной записи клиента – анкеты, содержащий в себе: ФИО клиента, контактная информация, список услуг, выбранные клиентами, стоимость. Изначально информация о клиенте вносится в базу, затем добавляется в форму заявки;
b) формирование списка услуг;
c) определение даты выполнения заявки;
d) предварительный расчет суммы заказа.
Требование к функциональным характеристикам программы:
a) вывод стандартной цены заказа по наименованию;
b) вывод информации о сумме заказа;
c) вывод общей стоимости по заявкам;
Требования к обеспечению надежного функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением Заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
a) организацией бесперебойного питания технических средств;
b) использованием лицензионного программного обеспечения;
c) регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
d) регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать 30-ти минут при условии соблюдения условий эксплуатации технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
Требования к интерфейсу:
a) поле выбора даты документа;
b) поле номера документа (автоматически);
c) поле выбора услуги;
d) поле выбора мастера;
e) поля выбора даты выполнения заказа;
f) поле вывода суммы
Минимально необходимыми для работы программного средства являются следующие параметры оборудования и операционной среды:
a) процессор типа IntelPentium, Celeron; AMDK5\K6, с тактовой частотой не менее 450 МГц монитор типа VGA с разрешением 640x480 или выше;
b) 32-разрядная версия ОС Windows;
c) для Windows 9x: минимум 128 Мб оперативной памяти;
d) для WindowsNT: минимум 128 Мб оперативной памяти.
Программа должна обеспечивать одновременную работу нескольких пользователей в одной системе пользователей.
1.6 Создание эскизного проекта
Отдел, занимающийся созданием эскизного проекта, получает утвержденное техническое задание, после чего в его обязанности входит составление схемы организационной структуры, структурного комплекса технических средств, схемы функциональной структуры, автоматизации. После того, как построены все схемы и графические приложения, информация передается в отдел технического проектирования.
1.7 Техническое проектирование ЭИС
При техническом проектировании осуществляют логическую проработку функциональной и системной архитектуры ЭИС, в процессе которой строится несколько вариантов всех компонентовсистемы; проводится оценка вариантов по показателям: стоимости, трудоемкости, достоверности получаемых результатов, и составляется «Технический проект» системы. Первым делом разрабатываются общесистемные проектные решения.
Следующим этапом разработки является разработка локальных проектных решений, в число которых входит разработка «Постановки задач» для задач, входящих в состав каждой функциональной подсистемы:
Таблица 3 – Постановка задач
Функциональная подсистема | Поставленные задачи |
1 Исследование и обоснование создания системы | Сбор данных об организации, анализ предметной области, утверждение информации заказчиком. |
2 Разработка ТЭО и ТЗ | Определяются организационные, экономические, информационные параметры ЭИС, разработка ТЗ |
3 Создание эскизного проекта | Построение схем и приложений структуры организации |
4 Техническое проектирование | Логическая проработка ЭИС, разработка локальных проектных решений, перестроение организационной структуры |
Также на этом этапе разрабатывается структура входных и выходных сообщений, проектируется состав и структура информационной базы, уточняется состав технических средств. Затем проект будущей КИС передается на рассмотрение заказчику.
2. Функциональное моделирование корпоративной ИС
2.1 Функциональная модель предметной области
Основу деятельности любой организации составляют ее деловые процессы или бизнес-процессы, которые определяются целями и задачами организации. Каждый бизнес-процесс характеризуется четко определенным во времени началом и концом. Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ. Описание деятельности организации с помощью бизнес-процессов позволяет определить где, когда и кем выполняется каждая функция, какие данные, информационные или функциональные взаимосвязи для этого нужны и откуда эти данные поступают.
В данной курсовой работе рассматривается салон красоты. Можно выделить такие бизнес-процессы, как оформление услуги, оформление договора, и, в конечном итоге, определение прибыли.
Каждый бизнес-процесс в данном проекте характеризуется определенными во времени началом и концом, внешними интерфейсами, которые либо связывают его с другими бизнес - процессами внутри организации, либо описывают выход во внешнее окружение, последовательностью выполняемых работ и правилами их выполнения (бизнес-правилами). Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ, условия инициализации и время выполнения.
В соответствии с описаннымибизнес-процессами построим, приведенные на рисунках 2, 3,4 диаграммы IDEF0.
Рисунок 2 - Контекстная диаграмма
Рисунок 3 – Детализация контекстной диаграммы
Рисунок 4 – Детализация процесса “Оформление заказа”
2.2 Инфологическая модель предметной области
Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Инфологическая модель представлена в виде ER-диаграммы, созданной в ErWin:
Рисунок 5 – Инфологическая модель предметной области
2.3 Даталогическое проектирование базы данных
В отличии от инфологической модели, которая осуществляет проектирование на логическом уровне, даталогическая модель позволяет рассматривать модель на физическом уровне. В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами. Основой анализа корректности схемы являются так называемые функциональные зависимости между атрибутами БД. Под процессом модификации БД понимается внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов. Приведем даталогическую модель для данной организации:
Рисунок 6 – Даталогическая модель предметной области
3 Проектирование цифровых сетей передачи данных корпоративной информационной системы