Содержание
1.ВВЕДЕНИЕ3
2.ТЕХНИЧЕСКОЕ ЗАДАНИЕ.4
2.1.Требования к структуре ИС.4
2.2.Требования к информационному обеспечению.4
2.3.Требования к функциональности ПО.4
2.4.Требования к среде разработки.4
3.ТЕХНИЧЕСКИЙ ПРОЕКТ5
3.1.Разработка структуры ИС5
3.2.Разработка информационных и организационных мероприятий.5
4.РАБОЧИЙ ПРОЕКТ7
4.1.Разработка серверного информационного обеспечения7
4.1.1.Построение модели базы данных.7
4.1.2.Разработка политики безопасности14
4.2.Разработка клиентского программного обеспечения.16
4.2.1.Взаимосвязи и назначение модулей.16
4.2.2.Исходный код программы17
4.2.3.SQL запросы использованные в программе.58
5.РАБОЧАЯ ДОКУМЕНТАЦИЯ.60
5.1.Руководство администратора.60
5.2.Руководство пользователя.60
5.2.1.Модуль аутентификации.60
5.2.2.Главное окно программы.61
5.2.3.Окно фильтрации.63
5.2.4.Окно добавления и редактирования записи студента.65
5.2.5.Окно перевода студента.66
5.2.6.Окно редактирования переводов студента.66
5.2.7.Окно редактирования успеваемости.67
5.2.8.Окно редактирования справочников.68
5.2.9.Отчеты.70
6.ЗАКЛЮЧЕНИЕ71
7.СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ72
Выдержка из текста работы
В России свадебный бизнес находится в стадии становления, но при этом рынок свадебных услуг развивается очень динамично. Причины этого развития — улучшение экономической ситуации в стране и, как следствие, повышение благосостояния населения. В связи с этим люди стремятся к хорошему образу жизни и готовы к большим затратам на бытовом уровне, включая такие значимые события как свадьба. Важной причиной можно также назвать и психологический фактор, сопровождающий рост благосостояния — желание избавить себя от хлопот. Именно поэтому в ближайшие годы возможно продолжение роста российского рынка свадебных услуг, как минимум, в два раза. Основная часть бюджета свадебного мероприятия — это приобретение свадебного наряда и сопутствующих аксессуаров. Данным видом деятельности и занимаются свадебные салоны.
Учитывая вышесказанное, проектирование автоматизированной подсистемы прием клиентов в свадебный салон “KLINFILD” является актуальным решением для одноименного предприятия.
Объектом исследования выбран свадебный салон «KLINFILD», а предметом исследования — его деятельность. Проектирования очень сложный, и состоит из нескольких этапов, регламентируемых документами на разработку автоматизированной информационной подсистемы управлением функционирования работы менеджера и рассматривающийся в данном курсовом проекте.
На начальной стадии проектирования одним из первых является обследование объекта и обоснование необходимости создания АИП. Поэтому необходимо подробно изложить основные положения и особенности функционирования объекта исследования.
После того как будут изложены основные понятия и особенности функционирования объекта исследования.
Приступаем к рассмотрению таких составляющих курского проекта, как разработка технического задания и календарного плана и проектирование информационной подсистемы запись клиента на примерку с использованием структурного подхода для этого используется не только теория с лекций, а так же дополнительный материал.
1.1 Статическое описание свадебного салона «KLINFILD»
В настоящее время работа свадебного салона «KLINFILD» является достаточно трудоемкой.
В данном курсовом проекте принято решение о разработке автоматизированного рабочего места специалиста, а точнее менеджера, салона свадебной и вечерней моды «KLINFILD».Таким образом, в качестве объекта исследования принят свадебный салон «KLINFILD» (далее — СС «К»), располагающийся в г. Хабаровске оказывающий различные свадебные услуги, а именно подбор свадебного наряда невесте, подбор свадебного костюма жениху, так же подбор различных аксессуаров.
Как упоминалось ранее, требуемая ИС должна охватывать всю деятельность СС «К». Первоначальный анализ показал большой объем необходимой автоматизации, следовательно, применительно к курсовому проекту к рассмотрению принята разработка подсистемы для записи СС «К». Главной задачей данной подсистемы (далее — АИП) является повышение эффективности функционирования регистрации клиентов на примерку, которая занимается приёмом и обслуживанием клиентов СС «К». В г. Хабаровск существует достаточное количество различных свадебных салонов, в которые обращается большое количество граждан. Поэтому для повышения конкурентоспособности СС «К» важно активизировать свою деятельность, повысив тем самым качество обслуживания клиентов.
Проектируемая АИП может быть разработана на основе существующих методов проектирования АИС, базирующихся на понятии жизненного цикла (ЖЦ), как непрерывного процесса, начинающегося с момента принятия решения о создании ИС и заканчивающегося в момент полного изъятия из эксплуатации.
Исходя из того, что существует три модели жизненного цикла [1], а именно, каскадная, инкрементальная и спиральная, было принято решено разрабатывать АИП на основе каскадной модели, подразумевающую линейную последовательность прохождения стадий создания АИП, а переход с одной стадии на следующую — только после завершения работы над текущей.
Первой стадией ЖЦ АИП является Системный анализ [1], основными целями которого являются:
· формулировка потребностей в АИП;
· выбор направления и определение экономической обоснованности проектирования АИП.
Для достижения данных целей необходимо решить следующие задачи:
1. Проанализировать существующую структуру СС «К».
2. Исследовать бизнес-модель СС «К».
СС «К» обладает линейно-функциональной структурой. Главой СС «К» является Директор, занимающийся координацией работы всех специалистов различных подразделений, также он осуществляет контроль над их работой и представляет СС «К» на различных конференциях и семинарах. В управлении СС «А» необходим единый подход к обслуживанию клиентов.
В Салоне работает 4 человека: директор; администратор; бухгалтер; юрист. Организационная структура представлена рис. 1.1.1.
Рисунок 1.1.1. — Организационная структура СС «К»
Согласно рис. 1.1.1. Директор организует всю работу данного предприятие, и несет ответственность за его работоспособность. Во-первых, это заключение договора по найму работников Салона. Организует обучение, если это необходимо. Руководит внедрением прогрессивных форм обслуживания; обеспечивает соблюдение работниками правил безопасности; санитарных требований. Во-вторых, поиск и сотрудничество с поставщиками. Рассматривая работу директора в процессе работы Салона можно описать так: после того как клиент сформирует заказ, его документы поступают самому директору, для того чтобы он подписал необходимые документы и передал дальше на обработку заказа. После того как заказ пройдет все этапы обработки, документы вновь поступает директору. Это необходимо для отчетности перед поставщиком.
Администратор подчиняется непосредственно директору. Он является организатором всей работы с покупателем. Администратор принимает пожелание клиента, после того как клиент выбрал необходимый дизайн ему необходимо заполнить некоторые документ. Данные документы предоставляет администратор, после заполнения отправляет директору на одобрения продажи данного товара. После того как директор подпишет, эти документы вновь возвращаются администратору. После данной процедуры, администратор отправляет клиента вместе с подписанными документами к бухгалтеру. После всех процедур выполнения бухгалтером, документы вновь поступают администратору. И только после этого администратор предоставляет товар Салона при наличии всех документов.
Бухгалтер в свою очередь ждет клиента с необходимыми документами, для того чтобы оплатить товар. Также в его обязанности входит не только процедура оплаты товара, но также и устанавливает результаты финансово — хозяйственной деятельности.
Юрист непосредственно занимается юридическим оформлением документации, консультирование служб и сотрудников. Юрист представляет Салон в арбитражном и гражданском судах.
Администратор является первым сотрудником СС «К», который взаимодействует с клиентом.
Основными его задачами являются:
· регистрация клиентов;
· ведение книги клиентов;
· оформление заказа клиента;
· работы сотрудников;
· предоставление клиентам различной информации, в частности по доп. Услугах.
Информационные потоки менеджера, характерные для данной предметной области, представлены следующие документы:
· журнал регистрации клиентов;
· справочник доп. Услуг;
· квитанция об оплате товара;
· справочник дизайнеров;
· талон на примерку;
· книга клиента.
Необходимо отметить, что неотъемлемой частью менеджера является запись к дизайнеру, он координирует процедуру записи к дизайнеру как по телефону, так и непосредственно в СС «К».
Менеджер должен:
· обладать всей возможной информацией о месте работы;
· уметь чётко планировать свою работу;
· решать вопросы, проблемы и недоразумения клиентов;
· организовывать предоставление дополнительных услуг вне установленного графика дизайнера по телефону и при личном посещении салона на определенную дату.
В данной курсовой работе предметной области необходимо автоматизировать процесс доступа к конкретным данным сотрудников, пациентов и организации работы самого салона. Причем обязательна выдача клиенту талона о записи на примерку (в бумажном или электронном виде). Доступ к данным разрешается только под личным паролём, т.к. личная информация клиента должна храниться в закрытом доступе. Так же эта программа разрешает сотруднику без пароля, иметь обычный доступ к минимальной информации клиента.
При приеме у каждого клиента будет своя личная страница в программе, где будет вестись личная информация, карта будет распечатываться только на примерку по записи. Координация работы дизайнера будет составлен в зависимости от нагрузки на его специализацию.
Определив процессы предприятия, которые будут автоматизированы, можно сделать вывод, что для данной предметной области необходимо автоматизировать процесс учетов клиентов. Исходя, из составленных предложений по технологической структуре АИС данная система предполагается быть созданной на местном уровне.
Так как пользователями системы будут являться в основном менеджер, необходимым условием будет наличие индивидуального пароля сотрудника.
Программное обеспечение предполагается быть разработанным под операционную систему Windows 7.Для её функционирования требуется СУБД Microsoft SQL Server. Так же доступ к интернету.
Миссия согласно [ISO-15704] -это
1. Деятельность, осуществляемая предприятием для того, чтобы выполнить функцию, для которой оно было учреждено, — предоставления заказчикам продукта или услуги.
2. Механизм, с помощью которого предприятие реализует свои цели и задачи.
Миссия компании по удовлетворению социально-значимых потребностей рынка определяется как компромисс интересов рынка и компании.
Исходя из данной информации, формируется миссия СС «К».
Миссия: заключается, в своевременном, качественном предоставление свадебных услуг клиенту
Миссию салона можно выполнить с помощью организационного подхода, который проводится по определенной схеме с помощью полной бизнес — модели объекта анализа, как целевой, открытой, социально — экономической системы, принадлежащее иерархической совокупности открытых внешних и внутренних подсистем.
Возможности салона определяются характеристиками её структурных подразделений и организацией их взаимодействия.
Дерево целей формирует дерево стратегий — иерархические списки уточнения и детализации достижения целей.
На основе данной информации формируется дерево целей и стратегии их достижения для менеджера. Ниже представлено дерево целей.
Дерево целей:
1) Облегчение процесса записи клиентов на подбор и примерку свадебного наряда.
2) Повышение качества предоставляемых услуг СС «К».
Далее формируем дерево стратегий:
1) Создание и обновление личных карт клиента;
2) Ведение учета дополнительных услуг;
3) Реклама в социальных сетях, размещение сайта на надежном хостинге, реклама в поисковых системах.
Все это дает возможность сформировать бизнес-потенциал компании.
Бизнес-потенциал компании — набор видов коммерческой деятельности, направленный на удовлетворение потребностей конкретных сегментов рынка. Бизнес-потенциал, в свою очередь, определяет функционал компании — перечень бизнес-функций, функций менеджмента и функций обеспечения, требуемых для поддержания на регулярной основе указанных видов коммерческой деятельности. Построение бизнес — потенциала и функционала компании позволяет с помощью матрицы проекций определить зоны ответственности менеджмента.
Матрица проекций — модель, представленная в виде матрицы, задающей систему отношений между классификаторами в любой их комбинации.
Описание бизнес — потенциала, функционала и соответствующих матриц ответственности представляет собой статическое описание компании. На этом этапе бизнес — моделирования формируется общепризнанный набор основополагающих внутрифирменных регламентов:
— базовое Положение об организационно-функциональной структуре компании;
— пакет Положений об отдельных видах деятельности (финансовой, маркетинговой и т.д.);
— пакет Положений о структурных подразделениях (цехах, отделах, секторах, группах и т.п.);
— должностные инструкции.
Это вносит прозрачность в деятельность компании за счет четкого разграничения и документального закрепления зон ответственности сотрудников салона.
Исходя из данной информации, формируются модели бизнес — потенциала и функционала работы менеджера. Это позволит разработать матрицу проекций. Через матрицу проекций формируются зоны ответственности сотрудников салона.
|
Деятельность менеджера |
||
|
Запись клиента |
X |
|
|
Определение к дизайнеру |
X |
|
|
Учёт времени на подбор и примерку свадебного наряда |
X |
Рисунок 1.1.2.- схема функционала подсистемы
|
Этапы управленческого цикла |
Компоненты менеджмента |
Персонал |
Учет |
|
|
Сбор информации |
Х |
|||
|
Выработка решений |
Х |
|||
|
Реализация |
Х |
Х |
||
|
Контроль |
X |
X |
Рисунок 1.1.3 — Схема формирования основных функций салона
|
МЦ «А» |
||||||
|
СС «К» |
Прием клиента |
Контроль над работой |
||||
|
получение информации |
Обработка информации |
создание плана работ |
проверка по |
|||
|
Директор |
x |
|||||
|
Менеджер |
x |
x |
||||
|
Специалист ПО |
x |
Рисунок 1.1.4. — Схема формирования зон ответственности салона.
1.2 Динамическое описание свадебного салона «KLINFILD»
Дальнейшее развитие является детализация бизнес — модели, происходит на этапе динамического описания компании, на уровне процессных потоковых моделей.
Процессные потоковые модели — это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. Сначала (на верхнем уровне) описывается логика взаимодействия участников процесса, а затем (на нижнем уровне) — технология работы отдельных специалистов на своих рабочих местах.
Логика менеджера заключается в записи клиентов. Запись к дизайнеру может быть осуществлено как по телефону, так и заранее в МЦ «А»
Менеджер должен, во-первых, обладать всей возможной информацией о СС «К». Во-вторых, он должен уметь чётко планировать свою работу. Все вопросы, проблемы и недоразумения клиентов должны разрешаться также с его помощью. Так же в его обязанности входят дополнительные услуги, который предоставляет салон вне установленного времени работы дизайнера. Запись к дизайнеру на доп. Услуги производиться как по телефону, интернету, так в самом салоне у менеджера на определенную дату. Приходя в салон, клиент должен иметь с собой некоторые документы (паспорт, личные параметры). Все перечисленные документ клиент передает менеджеру, который в свою очередь начинает заполнять определённую форму в программе. В то же время менеджер имеет права спросить некоторую информацию у клиента. После записи клиента на услуги салона выдает талон к дизайнеру, это делается для того чтобы упростить работу дизайнера.
Чтобы наиболее структурировано показать данные взаимодействия строится процессная потоковая модель.
Так же необходимо построить организационно — функциональную структуру менеджера.
Для построения организационно-функциональной модели используется всего два типа элементарных моделей: древовидные модели (классификаторы) и матричные модели.
В начальной модели применяется всего несколько классификаторов предметной области:
· основные группы продуктов и услуг салона;
· ресурсы, потребляемые салона в ходе своей деятельности;
· функции (процессы), поддерживаемые в салоне;
· организационные звенья свадебного салона.
В классификаторе функций обычно выделяют три базовых раздела:
· основные функции — непосредственно связанные с процессом преобразования внешних ресурсов в продукцию и услуги салона;
· функции управления салона;
· функции обеспечения — поддерживающие производственную, коммерческую и управленческую деятельность.
Исходя из выше перечисленной информации построим организационно — функциональную модель регистрационного отдела, построение которой основывается на:
· Положение об организационной структуре предприятия:
· функциональной схеме деятельности предприятия:
· функции, выполняемых предприятием:
|
Функциональная область |
Запись клиента |
Контроль работы |
|
|
Директор |
Х |
||
|
Менеджер |
Х |
||
|
Специалист по |
Х |
Рисунок 1.2.1 — Схема функций выполняемых салоном
Стандартная практика построения моделей организационно-функциональной структуры салона поддерживает два уровня детализации:
1) Агрегированную модель;
2) Детализированную модель.
Агрегированная модель — модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3 уровней.
Целью построения данной модели является предоставление информации об организационной структуре высшим руководителям салона для проведения стратегического анализа, анализа соответствия данной структуры стратегии и внешнему окружению компании.
Детализированная модель — модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем в агрегированной модели. Степень детализации в модели обусловлена конкретными потребностями компании (создание определенных организационных регламентов).
Целью построения данной модели является предоставление информации о распределении функциональных обязанностей между подразделениями салона, а также об организации бизнес-процессов. Построение детализированной модели позволяет создавать различные внутрифирменные регламенты.
Таким образом, организационный анализ предполагает построение комплекса взаимосвязанных информационных моделей компании, который включает:
Ш Стратегическую модель целеполагания (отвечает на вопросы: зачем компания занимается именно этим бизнесом, почему предполагает быть конкурентоспособной, какие цели и стратегии для этого необходимо реализовать);
Ш Организационно-функциональную модель (отвечает на вопрос кто — что делает в компании и кто за что отвечает);
Ш Функционально-технологическую модель (отвечает на вопрос что — как реализуется в компании);
Ш Процессно-ролевую модель (отвечает на вопрос кто — что — как — кому);
Ш Количественную модель (отвечает на вопрос, сколько необходимо ресурсов);
Ш Модель структуры данных (отвечает на вопрос, в каком виде описываются регламенты компании и объекты внешнего окружения).
Представленная совокупность моделей обеспечивает необходимую полноту и точность описания компании и позволяет вырабатывать понятные требования к проектируемой информационной системе.
1.3 Формирование требований
Формулирование требований к разрабатываемой информационной системе необходимо для разработки технического задания.
Разрабатываемая подсистема предназначена для работы менеджера
Чтобы осуществить поставленные цели, подсистеме необходимо поставить ряд требований.
1) Подсистема предназначена для автоматизации процесса учета клиентов.
2) Подсистема должна хранить информацию о клиентах.
3) Каждый оформленный клиент вноситься подсистемой в базу данных СС «К».
4) В подсистеме должна храниться и своевременно обновляться информация о клиентах.
Для дальнейшей реализации курсового проекта необходимо сформулировать проект информационной системы.
Доступ к подсистеме производится под личным логином и паролем менеджера.
Подсистема должна располагаться на сервере.
Для дальнейшей реализации курсового проекта необходимо сформулировать проект информационной системы.
Информационная система будет располагаться на одном компьютере, которая находятся на рабочем месте менеджера.
В данном салоне сотрудники будут соединены локальной сетью для ознакомления с требуемой информацией, которая будет храниться в данной информационной системе.
Информационная система будет иметь один модуль:
1. Один модуль будет представлять информацию о клиентах, дополнительных услугах.
Проектная документация для структурного подхода SADT.
Так же необходимо разработать проект архитектуры информационной системы.
а) Архитектура вычислительной системы АИП состоит из:
· Компьютера — 1шт.,100000 рублей.
· Факса — 1шт.,8590 рублей.
· Телефон — 1шт., 2590 рублей.
· Многофункциональное устройство (сканер, принтер, копировальный аппарат) — 1шт.,38900 рублей.
b) Архитектура программного обеспечения состоит из:
· Программы Microsoft Office.
· Internet Explorer или иной аналогичный браузер.
Для использования выше перечисленных программ необходимо установить операционную систему Windows 7.
c) Архитектура информационного обеспечения состоит из:
· Справочника амортизационных норм.
· Устава СС «К».
· Инструкций и должностных указаний менеджера и остальных сотрудников салона.
· Гражданского кодекса Российской Федерации.
Для дальнейшего проектирования информационной системы необходимо перейти на следующую стадию жизненного цикла — проектирование, в рамках который необходимо разработать техническое задание и календарный план системы
2.1 Техническое задание свадебного салона «KLINFILD»
Следующей стадией создания информационной подсистемы является — проектирование, которое из следующих разделов:
* Технического задания.
* Технического проекта.
* Тестирования.
Техническое задание — это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки информационной системы. Состав и содержание технического задания определяет ГОСТ 34.602-89.
Техническое задание является основополагающим документом всего проекта и всех взаимоотношений заказчика и разработчика. Корректный документ, написанный и согласованный между всеми заинтересованными и ответственными лицами — залог успешной реализации проекта.
Разработка систем для свадебного салона, в частности для менеджера, требует серьезного проектного исследования. Как правило, на эти исследования выделяется отдельный бюджет и больше времени.
Обычно заказчик не является профессионалом в области высоких технологий, и задача им ставится на общем уровне. В таком случае Исполнитель может сам предложить варианты, очередность решения поставленной задачи. Заказчик в дальнейшем выбирает наиболее оптимальный вариант.
Вся работа разбивается на несколько этапов, это делается для того, чтобы Заказчик мог проконтролировать работу исполнителя и постоянно находится в курсе процесса разработки, с другой стороны за каждый этап вносится предоплата.
В техническом задании расписывается каждый из этапов проектирования, причем необходимо указать, что должно быть получено от заказчика в начале каждого этапа и что должно быть на выходе.
1. Общие сведения
Полное наименование подсистемы: автоматизированная информационная подсистема записи клиентов в СС «К». Краткое наименование подсистемы: АИП запись КЛ-13.
Основания для проведения работ: работа выполняется на основании договора №0000001 от 3.09.13 между заказчиком (Свадебного салона) и разработчиком (ИП “34И”). Создание АИП запись «КЛ-13» выполняется на основании следующих документов:
1. Договор на разработку и создание АИП.
2. Доверенность на заключение договора лица со стороны управления центра.
3. Доверенность на получение документов необходимых для разработки АИП
4. ГОСТ 34.003-90 — Автоматизированные системы. Термины и определения.
5. ГОСТ 34.201-89 — Виды, комплектность и обозначение документов при создании автоматизированных систем.
6. ГОСТ 34.601-90 — Автоматизированные системы. Стадии создания.
7. РД 50-698-90 — Автоматизированные системы. Требования к содержанию документов.
8. РД 50-34.126-92 — Рекомендации. Правила поведения работ при создании автоматизированных систем.
9. ГОСТ 19.102-77 — Стадии разработки.
10. ГОСТ 19.201-78 — Техническое задание. Требования к содержанию и оформлению.
11. ГОСТ 19.701-90 (ИСО/МЭК 5807-85) — Схема алгоритмов программ, данных и систем. Условные обозначения и правила выполнения.
Наименование предприятий разработчика и заказчика (пользователя) подсистемы и их реквизиты:
Разработчик: ИП “34И”; Инн 951237894561; г.Хабаровск, ул. Павловича, 38; индекс 680000; телефон: 800-800; к/с 412368742301478623, БИК 987456321
Заказчик: СС «К» Инн 513248697102;г. Хабаровск, ул. Ленина 75; индекс 680058; телефон: 25-85-65; к/с 2369874100258796413, БИК 230456879
Плановые сроки начала и окончания работы: Согласно договору №0000001, датой предоставления проекта заказчику назначено 30.12.13.
Источники и порядок финансирования: Плановые сроки начала, и окончания работы по созданию подсистемы: Оплата производится сразу после приемо-сдаточных работ в полном объеме.
Порядок оформления и предъявления заказчику результатов работ: Сдача-приемка результатов работ осуществляется сторонами посредством проведения приемо-сдаточных испытаний в соответствии с условиями государственного контракта.
Испытания проводятся на основе Программы и методики испытаний, включающей разработанный Исполнителем контрольный пример, построенный на основе реальных данных. Контрольный пример должен быть отлажен на согласованной с Заказчиком конфигурации подсистемы и утвержден в качестве эталона для использования при обучении пользователей и внедрении подсистемы.
Программа и методика испытаний, включая контрольный пример, должна быть согласована и утверждена Заказчиком перед началом проведения приемо-сдаточных испытаний. При подготовке подсистемы к приемо-сдаточным испытаниям должна быть проведена ее опытная эксплуатация. Опытная эксплуатация должна проводиться на основе контрольного примера, на программно-технических средствах Заказчика, на ограниченном составе рабочих мест (до 4 рабочих мест пользователей) в течение не менее 7 дней. Перед проведением опытной эксплуатации должно быть проведено экспресс-обучение пользователей работе с подсистемой. Во время проведения испытаний должен вестись протокол испытаний подсистемы, в котором отражаются и отмечаются последовательно все действия пользователя и функциональная работоспособность модулей подсистемы, а также выявленные замечания, отклонения, дефекты, ошибки.
По окончании всех работ Исполнитель представляет Заказчику:
* акт сдачи-приемки работ, подписанный Исполнителем в 2 экземплярах;
* акт приемочной комиссии в 2 экземплярах;
* другие результаты работ, предусмотренные техническим заданием.
Все программные продукты, необходимые для функционирования подсистемы и приобретаемые по лицензии у третьих лиц оформляются на Заказчика и передаются в его собственность.
По окончании работы Исполнитель передает Заказчику все исключительные права на разработанные в ходе выполнения работ алгоритмы и программное обеспечение. Все передаваемые в качестве результатов работ материалы должны быть свободны от обязательства третьих лиц. Исполнитель передает Заказчику все лицензии и прочие документы, необходимые для эксплуатации автоматизированных систем и программного обеспечения в Российской Федерации.
Далее по техническому заданию идет «Назначение и цели создания подсистемы». Назначение подсистемы: АИП запись «КС-13» предназначается для автоматизированной записи клиентов, а также для хранения данных в электронном виде. Подсистема направлена на максимальное сокращение «бумажных работ».
Цели создания подсистемы:
Подсистема предназначена для информации о следующей деятельности менеджера:
* приём и обработка заявок на дополнительные услуги;
* составление графика приема клиентов;
* автоматизация ввода данных о клиентах;
* автоматизация обработка и анализ информации;
* облегчение поиска данных по БД.
Характеристики объектов автоматизации
Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию. Выявление бизнес процессов в свадебном салоне а именно рабочего места менеджера:
* запись клиентов
* предоставление дополнительных услуг
Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды:
АИП записи «КЛ-13» будет установлена в регистратуре на одном компьютере, техническое оборудование будет установлено в салоне, в котором будет функционировать кондиционер, поддерживающий необходимую температуру (30оС) для работы специалистов; должна проводиться ежедневная уборка.
Работа с АИП запись «КЛ-13» должна проходить на надежном хостинге, имеющим стабильный канал связи и отсутствие перебоев в работе. Так же должна быть проведена необходимая работа по защите АИП запись «КЛ-13» от постороннего доступа и атак.
Далее говорим о требовании к подсистеме.
Требования к подсистеме в целом
Подсистема должна содержать необходимый объем информации, механизм своевременной актуализации содержания и базовый набор сервисов работы с информацией, обеспечивающий требуемую полноту информационных услуг.
Требования к структуре и функционированию подсистемы
В подсистеме предлагается выделить следующие функциональные комплексы:
* Комплекс сбора, обработки и загрузки данных, который предназначен для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для корректной работы комплекса хранения данных;
* Комплекс хранения данных, предназначен для хранения данных в структурах, нацеленных на принятие решений;
* комплекс формирования и визуализации отчетности, который предназначен для формирования данных и отчетности.
Подсистема должна поддерживать следующие режимы функционирования:
* основной режим, в котором комплексы выполняют все свои основные функции;
* профилактический режим, в котором некоторые комплексы не выполняют своих функций;
В основном режиме функционирования автоматизированная подсистема должна обеспечивать:
* работу пользователя в режиме — 24 часов в день, 5 дней в неделю;
* выполнение своих функций — сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.
В профилактическом режиме подсистема должна обеспечивать возможность проведения следующих работ:
* техническое обслуживание;
* модернизацию аппаратно-программного комплекса;
* устранение аварийных ситуаций.
Общее время проведения профилактических работ не должно превышать 10% от общего времени работы подсистемы в основном режиме.
Требования к численности и квалификации персонала под-системы и режиму его работы: Требования к численности персонала: В состав персонала, необходимого для обеспечения эксплуатации АИП в рамках соответствующих подразделений заказчика, необходимо выделение следующих ответственных лиц:
* Директор — 1 человек;
* Администратор — 1человек;
* Бухгалтер — 1 человек.
* Юрист — 1 человек
Требования к способам и средствам связи для информационного обмена между компонентами подсистемы
В качестве протокола взаимодействия между компонентами подсистемы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Для организации информационного обмена между компонентами подсистемы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.
Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.
Требования к квалификации персонала к квалификации персонала, эксплуатирующего АИП запись «КЛ-13», предъявляются следующие требования: Конечный пользователь должен обладать знаниями в соответствующе предметной области; знаниями и навыками работы с автоматизированными информационными подсистемами.
Требования к режимам работы персонала: Режим работы определяется расписанием предприятия — заказчика.
Показатели назначения. Параметры, характеризующие степень соответствия подсистемы назначению: требования к приспособляемости подсистемы к изменениям:
Обеспечение приспособляемости подсистемы должно выполняться за счет: своевременности администрирования;
* Модернизации процессов сбора, обработки и загрузки данных в соответствии с новыми требованиями;
* Модификации процедур доступа и представления данных конечным пользователям;
* Наличия настроечных и конфигурационных файлов у ПО комплексов;
Требования сохранению работоспособности подсистемы в различных вероятных условиях
В зависимости от различных вероятных условий подсистема должна выполнять требования, приведенные ниже:
* При Нарушении в работе подсистемы внешнего электроснабжения серверного оборудования продолжительностью до 15 мин — функционирование в полном объеме.
* При выходе из строя сервера БД — уведомления ответственного лица о сбое подсистемы.
Требования к надежности. Состав показателей надежности для подсистемы в целом
Надежность должна обеспечиваться за счет:
* применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;
* своевременного выполнения процессов администрирования подсистемы;
* соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;
* предварительного обучения пользователей и обслуживающего персонала.
Перечень аварийных ситуаций, по которым регламентируются требования к надежности:
Под аварийной ситуацией понимается аварийное завершение процесса. При работе АИП запись «КЛ-13», возможны следующие аварийные ситуации, влияющие на работоспособность процесса:
* Сбой в электроснабжении сервера
* Сбой в электроснабжении рабочей станции пользователей подсистемы
* Поломка локальной сети
Сбой программного обеспечения сервера. Требования к надежности технических средств и программного обеспечения:
* Должно быть обеспечено бесперебойное питание активного сервера оборудования
* АИП должна иметь возможность отката или восстановления подсистемы, в случае сбоя
* Подсистема должна быть укомплектована комплексом оповещения об ошибках и сбоях
Надежность аппаратных средств и программных средств в должна обеспечиваться за счет предварительного обучения конечных пользователей и обслуживающего персонала. Также за счет своевременного выполнения процессов администрирования и соблюдения правил эксплуатации АИП.
Требования к методам оценки и контроля показателей надежности на разных стадиях создания подсистемы в соответствии с действующими нормативно-техническими документами.
Проверка выполнения требований по надежности должна производиться на этапе проектирования расчетным путем, а на этапах испытаний и эксплуатации — по методике Разработчика, согласованной с Заказчиком.
Требования по эргономике и технической эстетике
Дизайн подсистемы должен удовлетворять следующим требованиям по эргономике и технической эстетике:
* должно быть обеспечено наличие локализованного (русскоязычного) интерфейса пользователя;
* быть достаточно «легким» по объему графических элементов и обеспечивать как можно большую скорость загрузки данных;
* обладать развитой системой поиска информации;
* корректно отображаться при всех возможных разрешениях и количестве одновременно отображаемых цветов монитора;
* обладать системой подсказок в местах, где у пользователя потенциально могут возникнуть затруднения;
* должен использоваться шрифт: Arial;
* размер шрифта должен быть: 12пт;
* в шапке отчетов должен использоваться логотип медицинского центра;
* при возникновении ошибок в работе комплекса на экран монитора должно выводиться сообщение с наименованием ошибки и с рекомендациями по её устранению на русском языке.
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов подсистемы.
Подсистема должна быть рассчитана на эксплуатацию в составе программно-технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры Заказчика на внутреннюю и внешнюю. Техническая и физическая защита аппаратных компонентов системы, носителей данных, бесперебойное энергоснабжение, резервирование ресурсов, текущее обслуживание реализуется техническими и организационными средствами, предусмотренными в ИТ инфраструктуре Заказчика.
Для нормальной эксплуатации разрабатываемой системы должно быть обеспечено бесперебойное питание ПЭВМ. При эксплуатации, подсистема должна быть обеспечена соответствующими стандартам хранения носителей и эксплуатации ПЭВМ температура и влажность воздуха.
Периодическое техническое обслуживание используемых технических средств должно проводиться в соответствии с требованиями технической документации изготовителей, но не реже одного раза в год.
Периодическое техническое обслуживание и тестирование технических средств должны включать в себя обслуживание и тестирование всех используемых средств, включая рабочие станции, серверы, кабельные системы и сетевое оборудование, устройства бесперебойного питания.
В процессе проведения периодического технического обслуживания должны проводиться внешний и внутренний осмотр и чистка технических средств, проверка контактных соединений, проверка параметров настроек работоспособности технических средств и тестирование их взаимодействия.
Восстановление работоспособности технических средств должно проводиться в соответствии с инструкциями разработчика и поставщика технических средств и документами по восстановлению работоспособности технических средств и завершаться проведением их тестирования. Размещение помещений и их оборудование должны исключать возможность бесконтрольного проникновения в них посторонних лиц и обеспечивать сохранность находящихся в этих помещениях конфиденциальных документов и технических средств.
Размещение оборудования, технических средств должно соответствовать требованиям техники безопасности, санитарным нормам и требованиям пожарной безопасности.
Все пользователи подсистемы должны соблюдать правила эксплуатации электронной вычислительной техники.
Квалификация персонала и его подготовка должны соответствовать технической документации.
Требования к защите информации от несанкционированного доступа.
АИП должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Госкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем» 1992 г.
Компоненты подсистемы защиты от НСД должны обеспечивать:
* идентификацию пользователя;
* проверку полномочий пользователя при работе с системой;
* разграничение доступа пользователей на уровне задач и информационных массивов.
Протоколы аудита подсистемы и приложений должны быть защищены от несанкционированного доступа как локально, так и в архиве.
Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Госкомиссии России «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».
Защищённая часть подсистемы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).
Защищённая часть подсистемы должна автоматически блокировать сессии пользователей и приложений по заранее заданным временам отсутствия активности со стороны пользователей и приложений
Защищённая часть подсистемы должна использовать многоуровневую систему защиты. Защищённая часть системы должна быть отделена от незащищённой части системы межсетевым экраном.
Требования по сохранности информации при авариях АИП «КЛ-13» должна восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно-технического комплекса Заказчика.
Приведенные выше требования не распространяются на компоненты подсистемы, разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений, рекомендованных производителями покупного программного обеспечения.
Требования к защите от влияния внешних воздействий.
* Подсистема должна иметь возможность функционирования при колебаниях напряжения электропитания в пределах от 155 до 265 В (220 ± 20% — 30%);
* Подсистема должна иметь возможность функционирования в диапазоне допустимых температур окружающей среды, установленных изготовителем аппаратных средств.
* Подсистема должна иметь возможность функционирования в диапазоне допустимых значений влажности окружающей среды, установленных изготовителем аппаратных средств.
* Подсистема должна иметь возможность функционирования в диапазоне допустимых значений вибраций, установленных изготовителем аппаратных средств.
Требования по стандартизации и унификации. Разработка подсистемы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.н.
Экранные формы должны проектироваться с учетом требований унификации:
* все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
* для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
* внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов.
Дополнительные требования: АИП должно разрабатываться и эксплуатироваться на уже имеющемся у заказчика аппаратно-техническом комплексе.
Требования к безопасности: аппаратное обеспечение подсистемы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91.
АИП “ КЛ-13” является стационарным и после установки и проведения наладочных работ транспортировке не подлежит.
Требования к функциям (задачам), выполняемым подсистемой. Система сбора, обработки и загрузки данных. Комплекс обработки информации должен осуществлять хранение оперативных данных подсистемы, данных для формирования аналитических отчетов, документов системы, сформированных в процессе работы отчетов. Подсистема должна обеспечивать периодическое резервное копирование и сохранение данных на дополнительных носителях информации. Подсистема должна содержать необходимые данные о клиентах, о заказах, а так же информацию о обработанных заказах для дальнейшей статистики. Все справочники, входящие в состав подсистемы, должны обладать следующей основной функциональностью:
* Постоянное хранение данных;
* Добавление новых элементов;
* Редактирование элементов;
* Удаление (удаление элементов возможно лишь в том случае, если другие существующие объекты системы не ссылаются на удаляемый элемент);
* Просмотр элементов;
* Просмотр списка элементов;
* Фильтрация и сортировка списка элементов;
* Поиск элементов;
* Экспорт и импорт элементов.
* Перечень функций справочников должен быть уточнен на стадиях технического проектирования и опытной эксплуатации.
Подсистема управления нормативно-справочной информацией должна обеспечивать ведение следующих справочников и реестров:
* Реестр «Сотрудники «;
* Реестр «Клиенты»;
Требования к видам обеспечения: требования к математическому обеспечению подсистемы. Математические методы и алгоритмы, используемые для шифрования/дешифрования данных, а также программное обеспечение, реализующее их, должны быть сертифицированы уполномоченными организациями для использования в государственных органах Российской Федерации.
Требования к информационному обеспечению подсистемы. Информация в базе данных подсистемы должна сохраняться при возникновении аварийных ситуаций, связанных со сбоями электропитания. Подсистема должна иметь бесперебойное электропитание, обеспечивающее её нормальное функционирование в течение 15 минут в случае отсутствия внешнего энергоснабжения, и 5 минут дополнительно для корректного завершения всех процессов. Резервное копирование данных должно осуществляться на регулярной основе, в объёмах, достаточных для восстановления информации в подсистеме хранения данных.
Требования к лингвистическому обеспечению подсистемы. Под лингвистическим обеспечением понимаются:
* язык операционной системы и серверных приложений, на базе которых построена подсистема;
* язык приложений, используемых для подготовки документов;
* кодировка подготавливаемых и хранимых документов;
* язык документов и web-приложений;
Разработка прикладного ПО должна вестись на языках высокого уровня.
Пользователи должны взаимодействовать с подсистемой на уровне графического пользовательского интерфейса. Все функции подсистемы должны поддерживать русский язык и обеспечивать русскоязычный интерфейс пользователя.
Требования к программному обеспечению подсистемы. Общее программное обеспечение, как правило, представлено операционной системой с набором стандартных пользовательских приложений, именуемых аксессуарами и обладающих некоторым минимальным набором функций для решения, часто встречающихся задач обработки информации, например для работы с текстом. Специальное программное обеспечение, как правило, работает «поверх» общего ПО (т.е. под управлением операционной системы) и обычно является клиентской частью. Взаимодействующей с серверной частью, установленной на удаленном (или не очень) сервере, по локальной или глобальной компьютерной сети.
Для корректной работы автоматизированной информационной подсистемы требуются следующие программные средства:
* операционная система Microsoft Windows;
* система управления базой данных Microsoft Access 2007;
* пакет Microsoft Office 2007.
Система управления базой данных необходима для взаимодействия автоматизированной системы с базой данных, в которой будут находиться данные о клиентах и сделках.
Microsoft Office необходим для формирования отчетов и других видов документов, связанных с данным видом деятельности.
Требования к техническому обеспечению
Техническое обеспечение подсистемы должно максимально и наиболее эффективным образом использовать существующие в органах федерального агентства технические средства.
В состав комплекса должны следующие технические средства:
* Серверы БД;
* Сервер системы формирования отчетности;
* Веб — сервер;
* ПК начальника и сотрудников.
Требования к метрологическому обеспечению. Метрологическое обеспечение — установление и применение научных и организационных основ, технических средств, правил и норм, необходимых для достижения единства и требуемой точности проводимых измерений. Проектируемая подсистема не будет содержать данное обеспечение.
Требования к организационному обеспечению. Организационное обеспечение подсистемы должно быть достаточным для эффективного выполнения персоналом возложенных на него обязанностей при осуществлении автоматизированных и связанных с ними неавтоматизированных функций подсистемы. Заказчиком должны быть определены должностные лица, ответственные за:
* обработку информации;
* администрирование;
* обеспечение безопасности информации;
К работе с подсистемой должны допускаться сотрудники, имеющие навыки работы на персональном компьютере, ознакомленные с правилами эксплуатации и прошедшие обучение работе с подсистемой.
Требования к методическому обеспечению. В состав методического обеспечения подсистемы должны входить законодательные акты, стандарты, нормативы, инструкции.
Требования к патентной чистоте. По всем техническим и программным средствам, применяемым в подсистеме, должны соблюдаться условия лицензионных соглашений и обеспечиваться патентная чистота. Патентная чистота — это юридическое свойство объекта, заключающиеся в том, что он может быть свободно использован в данной стране без опасности нарушения действующих на ее территории патентов исключительного права, принадлежащего третьим лицам (права промышленной собственности).
Состав и содержание работ по созданию (развитию) подсистемы.
Конкретные сроки выполнения стадий и этапов разработки и создания подсистемы определяются планом выполнения работ, являющимся неотъемлемой частью Договора на выполнение работ по настоящему частному техническому заданию. Перечень организаций — исполнителей работ, определение ответственных за проведение этих работ организаций определяются договором.
Порядок контроля и приемки подсистемы. Виды и объем испытаний подсистемы.
Подсистема подвергает испытания следующих видов:
* Предварительные испытания
* Опытная эксплуатация
* Приемочные испытания
Виды, состав, объем, и методы испытаний подсистемы должны быть изложены в составе рабочей документации.
Требования к приемке работ по стадиям. Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и календарным планом.
Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии. Все создаваемые в рамках настоящей работы программные изделия (за исключением покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске или флэш).
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие. В ходе выполнения проекта на объекте автоматизации требуется выполнить работы по подготовке к вводу подсистемы в действие. При подготовке к вводу в эксплуатацию АИП «УЛ-13» Заказчик должен обеспечить выполнение следующих работ:
* Определить подразделение и ответственных должностных лиц, ответственных за внедрение и проведение опытной эксплуатации АИП;
* Обеспечить присутствие пользователей на обучении работе с подсистемой, проводимом Исполнителем;
* Обеспечить соответствие помещений и рабочих мест пользователей подсистемы в соответствии с требованиями, изложенными в настоящем ТЗ;
* Обеспечить выполнение требований, предъявляемых к программно-техническим средствам, на которых должно быть развернуто программное обеспечение «КЛ-13»;
* Совместно с Исполнителем подготовить план развертывания подсистемы на технических средствах Заказчика;
* Провести опытную эксплуатацию подсистемы.
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие, включая перечень основных мероприятий и их исполнителей должны быть уточнены на стадии подготовки рабочей документации и по результатам опытной эксплуатации.
Требования к документированию. Для подсистемы на различных стадиях создания должны быть выпущены следующие документы из числа предусмотренных в ГОСТ 34.201 — «Информационная технология». Комплекс стандартов на автоматизированные системы. Наиболее подробно описав все требования к подсистеме необходимо структурировать данную информацию в процесс проектирования информационной подсистемы. Для проектирования автоматизированной информационной подсистемы применяется календарный план, который учитывает жизненный цикл подсистемы и стоимость каждой фазы жизненного цикла.
В состав ТЗ на АС при наличии утвержденных методик включают приложения, содержащие:
1) расчет ожидаемой эффективности системы: этот пункт не рассматривается
2) оценку научно-технического уровня системы: этот пункт не рассматривается
Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.
В рамках данного курсового проекта технический проект был наиболее подробно рассмотрен на предыдущей стадии жизненного цикла, а тестирование информационной системы не предусмотрено заданием.
2.2 Разработка календарного плана для записи клиентов «КЛ-13»
Далее необходимо разработать календарный план, так как он является следующим этапом в разработке информационной подсистемы после технического задания. Календарный план проекта — это совокупность сроков начала и окончания работ, совершения событий проекта. Календарный план представлен ниже в таблице 2.2.1.
Таблица 2.2.1 — Календарный план свадебного салона «KLINFILD»
|
№ Этапа |
Наименование основных этапов |
Срок выполнения начало-окончание (число, месяц, год) |
Расчетная цена этапа, руб. в % к договорной цене |
|
|
1 |
2 |
3 |
4 |
|
|
1 |
Анализ организационной структуры и ИТ/С предприятий информационной сферы |
12.09.13-22.09.13 |
4000 8,5% |
|
|
1.1. |
Анализ бизнес процессов |
22.09.13-28.09.13 |
4000 8,5% |
|
|
1.2. |
Анализ и формирование требований к «ПЦ-1» |
28.09.13-01.10.13 |
4000 8,5% |
|
|
1.3 |
Анализ существующего ПО предприятия, выработка плана интег. правляющей сист. сайта |
02.10.13-05.10.13 |
4000 8,5% |
|
|
2 |
Проектирование подсистемыАИП учета ПЦ-1 |
05.10.13-14.10.13 |
9000 15,0% |
|
|
3 |
Проектирование модели подсистемы |
15.10.13-22.10.13 |
8000 13,5% |
|
|
4 |
Проектирование архитектуры подсистемы |
23.10.13-28.10.13 |
6500 8,5% |
|
|
5 |
Проектирование дизайна подсистемы |
29.10.13-05.11.13 |
6500 8,5% |
|
|
6 |
Создание скрипа для запросов в БД, на данные клиентов и информации по сделкам |
06.11.13-15.11.13 |
8500 15,0% |
|
|
7 |
Разработка скрипта ведущего учет заключенных договоров |
16.11.13-25.11.13 |
8500 15,0% |
|
|
8 |
Подготовка к введению подсистемы в эксплуатацию |
26.11.13-02.12.13 |
3000 3,3% |
|
|
9 |
Отладка и тестирование |
03.12.13-10.12.13 |
3500 6,4% |
|
|
10 |
Интеграция АИП; настройка оборудования и конфигураций |
11.12.13-16.08.13 |
1500 2,3% |
|
|
11 |
Сдача АИП в эксплуатирование, подготовка отчета о проделанной работе |
16.12.13-30.12.13 |
1500 2,3% |
|
|
Итого |
75500 |
Рассмотренные в календарном плане этапы 4,5,6,7,8,9 не будут реализованы в курсовом проекте, так как не предусмотрены заданием.
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 с.
Размещено на
