* Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации АИП;

* Обеспечить присутствие пользователей на обучении работе с подсистемой, проводимом Исполнителем;

* Обеспечить соответствие помещений и рабочих мест пользователей подсистемы в соответствии с требованиями, изложенными в настоящем ТЗ;

* Обеспечить выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение «КЛ-13»;

* Совместно с Исполнителем подготовить план развертывания подсистемы на технических средствах Заказчика;

* Провести опытную эксплуатацию подсистемы.

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

Требования к документированию. Для подсистемы на различных стадиях создания должны быть выпущены следующие документы из числа предусмотренных в ГОСТ 34.201 - «Информационная технология». Комплекс стандартов на автоматизированные системы. Наиболее подробно описав все требования к подсистеме необходимо структурировать данную информацию в процесс проектирования информационной подсистемы. Для проектирования автоматизированной информационной подсистемы применяется календарный план, который учитывает жизненный цикл подсистемы и стоимость каждой фазы жизненного цикла.

В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:

1) расчет ожидаемой эффективности системы: этот пункт не рассматривается

2) оценку научно-технического уровня системы: этот пункт не рассматривается

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

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

2.2 Разработка календарного плана для записи клиентов «КЛ-13»

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

Таблица 2.2.1 - Календарный план свадебного салона «KLINFILD»

Рассмотренные в календарном плане этапы 4,5,6,7,8,9 не будут реализованы в курсовом проекте, так как не предусмотрены заданием.

3. Анализ и проектирование информационной подсистемы запись клиента свадебного салона «Кlinfild» с использованием структурного подхода

3.1 Разработка функциональной модели АИП «КЛ-13»

свадебный автоматизированный информационный примерка

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

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

Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:

* описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);

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

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

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

Модель (AS-IS, ТО-ВЕ или SHOULD-BE) может содержать 4 типа диаграмм:

* контекстную диаграмму;

* диаграммы декомпозиции;

* диаграммы дерева узлов;

* диаграммы только для экспозиции (for exposition only, FEO).

Рассмотрим IDEF0 модель для модуля записи клиента АИП «КЛ-13»:

Рисунок 3.1.1. - контекстная диаграмма модуля записи клиентов, построенная методологией IDEF0

Далее приведены декомпозиции контекстной диаграммы 1-го и 2-го порядка:

Рисунок 3.1.2. -декомпозиция контекстной диаграммы первого порядка

Рисунок 3.1.3 - декомпозиция контекстной диаграммы второго порядка

Далее разаработана функциональную модель на основе DFDметодолгии. DFD - общепринятое сокращение от англ. Data Flow Diagrams - диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуще-ствляется доступ.

Модель построенная на основе данной методологии изображена на рис. 3.1.4.

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

Рисунок 3.1.4. - Контекстная диаграмма модуля «учета клиентов» построенная методологией DFD

3.2 Исследование информационной модели АИП записи КЛ-13

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

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

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

Рисунок 3.2.1 - Концептуальная модель подсистемы «записи клиента»

Следующим этапом является логическое проектирование, в рамках которого происходит развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.). Модель, разработанная на основе данного этапа представлена на рис. 3.2.2.

Рисунок 3.2.2 - Логическая модель подсистемы «записи клиента»

В качестве завершающего этапа было выполнено физическое проектирование, которое развивает логическую модель БД с учетом выбранной целевой СУБД. Специфика целевой СУБД включает в себя ограничения наименование объектов базы данных, ограничения на поддерживаемые типы данных, выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.Построение данной модели представлено в таблицах 3.2.1, 3.2.2, 3.2.3 и на рис. 3.2.4.

Таблица 3.2.1 - База данных. Таблица запись

Таблица 3.2.2 - База данных. Таблица клиент

Таблица 3.2.3 - База данных. Таблица сотрудник

Так же в при разаработке физической модели построенна схема данных,которая представоена на рис 3.2.3.

Рисунок 3.2.3 - Физическая модель записи клиентов. Схема данных

Далее проверим работу базы данных, для этого проведем несколько процедур.(рис. 3.2.4, 3.2.5)

Рисунок 3.2.4 - Использование запроса

Рисунок 3.2.5 - Создание формы

3.3 Поведенческая модель

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

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

Основой для построения поведенческой модели, относительно данного курсового проекта, является диаграмма DFD. Построенная поведенческая модель представлена на рис. 3.3.1 и 3.3.2.

Рисунок 3.3.1 - Поведенческая модель подсистемы «записи клиентов»

Рисунок 3.3.2 - Блок - схема процесса «записи клиентов»

Заключение

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

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

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

1. ГОСТ 24.701-86 - Надежность автоматизированных систем управления.

2. ГОСТ 34.003-90 - Автоматизированные системы. Термины и определения.

3. ГОСТ 34.201-89 - Виды, комплектность и обозначение документов при создании автоматизированных систем.

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

5. РД 50-698-90 - Автоматизированные системы. Требования к содержанию документов.

6. РД 50-34.126-92 - Рекомендации. Правила поведения работ при создании автоматизированных систем.

7. ГОСТ 19.102-77 - Стадии разработки.

8. ГОСТ 19.201-78 - Техническое задание. Требования к содержанию и оформлению.

9. ГОСТ 19.701-90 (ИСО/МЭК 5807-85) - Схема алгоритмов программ, данных и систем. Условные обозначения и правила выполнения.

10. Смирнова, Г. Н., Проектирование экономических информационных систем: Учебник./ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов - М.: Финансы и статистика, 2003. - 512 с.

11. Вендров, A. M., Практикум по проектированию программного обеспечения экономических информационных систем./ А. М. Вендров - М.: Финансы и статистика, 2006. - 191 с.

12. Балдин, К. В., Информационные системы в экономике./ К. В. Балдин, В. Б. Уткин - М.: Издательский центр Академия, 2005 - 288 с.

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