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

Содержание

Введение

1. Выбор темы

2. Модель как есть

3. Автоматизация

4. Модель «Как должно быть»

5. Техническое задание

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

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

Заключение

Введение

автоматизированный управление клиент обслуживание

Цель курсовой: получение навыков проектирования автоматизированных систем обработки информации и управления (АСОИУ).

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

1. Выбор темы

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

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

2. Модель как есть

Для разработки АСПК «Ледовый дворец» была составлена модель «Как есть».Для решения проблемысвременем обслуживания клиентов, выбрана части системы, которая нуждается в автоматизации. Модель «Как есть» приведена на рисунке 1. Модель описывает процесс оформления заказа клиентом и получения коньков. Модель «Как есть» реализована с использованием нотации IDEF3. Клиент, заходя в отдел проката, проверяет очередьк окошку.Если очередь большая клиент может уйти, иначе клиент подходит кокошку проката. Клиент совершает заказ: указывает время катания, оплачивает его, оставляет в залог свои документы, получает коньки и выходит на лёд. Завершив катание вовремя либо позже(раньше), клиент возвращается к окошку, отдает коньки, доплачивает если в этом есть необходимость, забирает свои документы и уходит из отдела проката.

Рисунок 1 - Модель «Как есть»

Блок1. «Узнать время проката»

Работник отдела проката, спрашивает у клиента о количестве времени, которое необходимо тому для катания. Записывает начало проката.

Блок2. «Узнать размер»

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

Блок3. «Взять оплату и документы»

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

Блок4. «Выдать коньки»

Работник отдела проката выдаёт подготовленные коньки клиенту.

Блок5. «Взять обувь»

Работник отдела проката принимает обувь клиента на хранение, на время катания.

Блок6. «Выдать талон»

Работник отдела проката выдаёт клиенту талон, в котором написано время окончания катания и номер под которым хранится его обувь.

Блок7. «Принять талон»

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

Блок8. «Сравнить оплаченное время с фактическим»

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

Блок9. «Взять доплату»

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

Блок10. «Отдать обувь»

Работник отдела проката отдает клиенту обувь по номеру, который записан в талоне.

Блок11. «Принять коньки»

Работник отдела проката принимает от клиента коньки, которые были даны тому для катания. Затем кладет коньки на их место.

Блок12. «Отдать документы»

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

IDEF3 (англ.Integrated DEFinitionfor Process Description Capture Method) -- методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие. Больше применение IDEF3 получила при разработке информационных систем. При этом используется инструмент визуального моделирования бизнес-процессов. В наличии нотации присутствовали такие инструменты как перекрестки, именно их наличие и определило наш выбор в пользу этой нотации. Были использованы такие перекрестки как - исключающее или, которое предполагает только одно прохождение клиента из возможных.

3. Автоматизация

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

1 Установить терминалы оформления заказа в холле.

2 Установить турникеты с датчиками контроля времени на входе в зону катанияи выходе их неё для точного подсчета времени проката.

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

4 Создать блок хранения данных, для хранения оформленных заказов, и блок обработки статистики.

Все 4 блока объединить в одну систему для решения всех поставленных проблем и создания АСПК «Ледовый дворец».

4. Модель «Как должно быть»

После озвучивания предложений по автоматизации была составлена модель «Как должно быть», которая состояла из диаграммы, созданной по нотации IDEF3. В ней был рассмотрен процесс оформления заказа клиентомвотделе проката с использованием АСПК «Ледовый дворец» (Рисунок 2).

Рисунок 2 - Модель «Как должно быть.

Как видно из рисунка 2 наша модель упростилась путем убавления некоторых блоков и их заменой, однако данная модель позволяет решить проблемы ООО «Ледокол» по оформлению заказа. Также было решено установить информационное табло для посетителей проката, на котором будут изображаться различные новости и инструкции по использованию данной системы.

Блок1. «Оформление заказа»

Оформление заказа будет осуществляться с помощью установленных терминалов оплаты. Клиент подходит к терминалу оформляет заказ, путем выбора времени проката, размера коньков и их типа. Вносит плату.

Блок2. «Получение чека»

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

Код доступа будет занесен в базу данных.

Блок3. «Подойти к соответствующему окну»

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

Блок4. «Выдача коньков»

Подойдя к ячейке, клиент подносит чек к датчику и считав код ячейка открывается. Клиент берет свои коньки.

Блок5. «Проход через турникет»

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

Блок6. «Проход через турникет2»

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

Блок7. «Проверка времени проката»

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

Блок8. «Внести доплату»

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

Блок9. «Подойти к соответствующему окну2»

Клиент проходит к ячейке где брал коньки и сняв их кладет в эту ячейку.

5. Техническое задание

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

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

1.1.1 Полное наименование системы

Автоматизированная система проката коньков «Ледовый дворец».

1.1.2 Краткое наименование системы

"АСПК". В дальнейшем просто - "Система".

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

Работа выполняется на основании договора № 1 от 15.09.2012 между ООО «Ледокол» и ООО «АП»

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

1.3.1 Заказчик

Заказчик: ООО «Ледокол»

Адрес фактический: г. Красноярск ул. 9 мая д. 80

Телефон: 277-77-77

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

Разработчик: ООО «АП»

Адрес фактический: г. Красноярск ул. Ак. Киренского д. 26 «Б»

Телефон: 291-21-85

1.4 Плановые сроки начала и окончания работ

Начало работ: 20.09.2012

Окончание работ: 25.12.2012

1.5 Источники и порядок финансирования

По договору № 1 от 15.09.2012 между ООО «Ледокол» и ООО «АП»

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

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

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

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

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

Система должна обеспечить:

· Сбор, обработку, хранение информации получаемой из оперативной базы данных;

· Автоматическую генерацию уникальных номеров и их печати на чековой ленте;

· Автоматический контроль входа в зону катания и выхода из нее.

· Автоматическое смс-оповещение об окончании времени проката по желанию клиента

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

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

Внедрение АСПК позволит:

· Повысить качество и уровень обслуживания клиентов за счет внедрения системы;

· Оптимизировать работу ледового дворца.

2.3 Технические параметры системы

Система должна обладать следующими параметрами:

- Количество терминалов оплаты - не менее 6;

- Количество каналов одновременной записи и обработки данных- не менее 4;

- Количество языков смс сообщений - не менее 2;

- Количество стоек информации - 2;

- Количество типов сообщений - не менее 3.

- Количество локальных зон - не менее 3;

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

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

В рамках данного проекта объектами автоматизации являются процессы выполняемые в следующих отделах:

· Отдел проката;

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

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

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

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

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

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

Функции системы:

1) Сбор данных

2) Хранение данных

3) Анализ данных

4) Вывод информации

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

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

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

· подсистема формирования и визуализации отчетности.

Турникеты с датчиками сбора информации о времени проката и терминалыоформления заказа подключаются к серверу через LAN-порты.В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP. В качестве хранилища данных должна использоваться СУБД MicrosoftSQLServer 2008 R2. Для реализации программных компонентов Системы необходимо использовать языки программирования из программной платформы .NETFramework не ниже 4-й версии.

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

· Основной режим, в котором подсистемы АСПК выполняют все свои основные функции;

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

В основном режиме функционирования АСПК должна обеспечивать:

· работу пользователей в режиме - 12 часов в день, 7 дней в неделю (12х7);

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

В профилактическом режиме АСПК должна обеспечивать возможность проведения следующих работ:

· техническое обслуживание;

· модернизацию аппаратно-программного комплекса;

· устранение аварийных ситуаций.

Общее время проведения профилактических работ не должно превышать 5% от общего времени работы системы в основном режиме (360 часов в месяц).

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

Диагностирование АСПК должно осуществляться следующими штатными средствами, входящими в комплект поставки программного обеспечения:

· СУБД Microsoft SQL Server 2008 R2;

· MicrosoftVisualStudio

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

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

4.1.2 Требования к составу оборудования

Система должна состоять из следующих аппаратных компонентов:

Блок управления (сервер системы) - компонент, обеспечивающий функционирование системы в целом.

Рабочее место администратора - рабочее место сотрудника, оборудованное персональным компьютером, на который устанавливается «виртуальный пульт оператора». В системе предусматривается использование существующих у Заказчика персональных компьютеров любой конфигурации с тактовой частотой процессора не ниже 2,5 ГГц, оперативной памятью не менее 2048Мб, достаточным свободным местом (не менее 10 Гб) на винчестере для установки программного обеспечения.

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

Электронный турникет - турникет с датчиками контроля времени. Оснащен сканерами, способными считать номер с талона клиента.

Блок доплаты - сенсорный терминал, оснащенный сенсорным экраном с диагональю не менее 10 дюймов. Блок позволяет выбирать услуги из предлагаемого меню прикосновением руки (с использованием автоподсказок). Оснащен принтером для печати чеков. Напольное исполнение. Должна иметься возможность выбора цветовой гаммы блока по желанию Заказчика.

Информационное табло - табло, расположенное в зоне ожидания в удобном для обзора месте, которое позволяет посетителю ознакомиться с правилами пользования терминалами. На табло выводятся обучающие ролики и инструкции. Также, в соответствии со спецификой организации, должна быть реализована возможность вывода разнообразной информации, в том числе в виде бегущей строки и видеоряда. В системе предусматривается использование ЖК-телевизоров с диагональю 40 дюймов (размер диагонали в зависимости от зоны ожидания) с соответствующим креплением.

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

4.1.3.1 Требования к численности персонала

В состав персонала, необходимого для обеспечения эксплуатации АСПК в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:

· Руководитель эксплуатирующего подразделения - 1 человек.

· Администратор системы АСПК - 2 человека.

Данные лица должны выполнять следующие функциональные обязанности:

· Руководитель эксплуатирующего подразделения - на всем протяжении функционирования АСПК обеспечивает общее руководство группой сопровождения.

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

4.1.3.2 Требования к квалификации персонала

К квалификации персонала, эксплуатирующего АСПК, предъявляются следующие требования.

- Администратор системы АСПК - знание методологии проектирования хранилищ данных; знание методологии проектирования ETL процедур; знание интерфейсов интеграции ХД с источниками данных; знание СУБД; знание языка запросов SQL; опыт администрирования СУБД; знание и навыки операций архивирования и восстановления данных; знание и навыки оптимизации работы СУБД; глубокие знания программирования; знание инструментов разработки; понимание принципов многомерного анализа; знание методологии проектирования хранилищ данных.

4.1.3.3 Требования к режимам работы персонала

Персонал, работающий с АИС «Касса» и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:

- Администратор системы АСПК - сменный график, поочередно.

4.1.4 Показатели назначения

4.1.4.1 Параметры, характеризующие степень соответствия системы назначению

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

- Количество измерений - X.

- Количество показателей - Y.

4.1.4.2 Требования к приспособляемости системы

Обеспечение приспособляемости системы должно выполняться за счет:

- своевременности администрирования;

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

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

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

4.1.4.3 Требования к сохранению работоспособности системы в различных вероятностных условиях

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

Вероятное условие	Требование
Нарушения в работе системы внешнего электроснабжения серверного оборудования продолжительностью до 15 мин.	Приостановка работы АСПК
Выход из строя сервера подсистемы хранения данных	Уведомление администратора системы
Выход из строя датчика контроля времени	Уведомление администратора системы
Выход из строя терминала оформления заказа	Система функционирует в обычном режиме, уведомление администратора

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

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

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

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

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

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

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

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

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

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

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

- при выходе из строя АСПК - не более 6 часов.

Система должна соответствовать следующим параметрам:

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

- коэффициент готовности W - определяется как результат отношения средней наработки на отказ к сумме средней наработки на отказ и среднего времени восстановления;

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

Средняя наработка на отказ АСПК не должна быть меньше 60 часов.

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

Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой АСПК, а также «зависание» этого процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- система должны быть укомплектована подсистемой оповещения Администраторов о переходе на автономный режим работы;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

Технические средства Системы и персонал должны размещаться в существующих помещениях Заказчика, которые по климатическим условиям должны соответствовать ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды» (температура окружающего воздуха от 5 до 40 °С, относительная влажность от 40 до 80 % при Т=25 °С, атмосферное давление от 630 до 800 мм ртутного столба). Размещение технических средств и организация автоматизированных рабочих мест должны быть выполнены в соответствии с требованиями ГОСТ 21958-76 «Система "Человек-машина". Зал и кабины операторов. Взаимное расположение рабочих мест. Общие эргономические требования».

Для электропитания технических средств должна быть предусмотрена трехфазная четырехпроводная сеть с глухо заземленной нейтралью 380/220 В (+10-15)% частотой 50 Гц (+1-1) Гц. Каждое техническое средство запитывается однофазным напряжением 220 В частотой 50 Гц через сетевые розетки с заземляющим контактом.

Для обеспечения выполнения требований по надежности должен быть создан комплект запасных изделий и приборов (ЗИП).

Состав, место и условия хранения ЗИП определяются на этапе технического проектирования.

4.2 Требования к функциям, выполняемым системой

4.2.1 Подсистема обработки, сбора и загрузки данных

4.2.1.1 Перечень функций, задач подлежащей автоматизации

Функция	Задача
Управляет процессами сбора, обработки и загрузки данных	Создание, редактирование и удаление процессов сбора, обработки и загрузки данных
	Формирование последовательности выполнения процессов сбора, обработки и загрузки данных
	Определение и изменение расписания процессов сбора, обработки и загрузки данных
Выполнение процессов сбора, обработки и загрузки данных из источников в ХД	Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения
	Обработка и преобразование извлечённых данных
Протоколирует результаты сбора, обработки и загрузки данных	Ведение журналов результатов сбора, обработки и загрузки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

4.2.1.2 Временной регламент реализации каждой функции, задачи

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

4.2.1.3 Требования к качеству реализации функций, задач

Задача	Форма представления выходной информации	Характеристики точности и времени выполнения
Создание, редактирование и удаление процессов сбора, обработки и загрузки данных	В стандарте интерфейса ETL средства	Определяется регламентом эксплуатации
Формирование последовательности выполнения процессов сбора, обработки и загрузки данных	В стандарте интерфейса ETL средства	Определяется регламентом эксплуатации
Определение и изменение расписания процессов сбора, обработки и загрузки данных	В стандарте интерфейса ETL средства	Определяется регламентом эксплуатации
Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения		Запуск должен производится точно по установленному расписанию
Обработка и преобразование извлечённых данных	Данные в структурах БД	Запуск должен производится точно по установленному расписанию
Ведение журналов результатов сбора, обработки и загрузки данных	Текстовые файлы	В момент выполнения сбора, обработки и загрузки данных
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Текстовый файл, оконное сообщение, email	Не позднее 5 минут после возникновения нештатной ситуации

4.2.1.4 Перечень критериев отказа для каждой функции

Функция	Критерий отказа	Время восстановления	Коэффициент готовности
Управляет процессами сбора, обработки и загрузки данных	Не выполняется одна из задач функции.	1.5 часа	0.75
Запускает процессы сбора, обработки и загрузки данных из источников в ХД	Не выполняется одна из задач функции.	1.5 часа
Протоколирует результаты сбора, обработки и загрузки данных	Не выполняется одна из задач функции.	1.5 часа	0.75

4.2.2 Подсистема хранения данных

4.2.2.1 Перечень функций, задач подлежащей автоматизации

Функция	Задача
Резервное копирование БД	Удаление резервных копий, выходящих из временных пределов хранения
	Создание резервной копии БД
	Протоколирование создания и удаления резервной копии
Протоколирование ошибок	Ведение журналов ошибок
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

4.2.2.2 Временной регламент реализации каждой функции, задачи

Задача	Требования к временному регламенту
Удаление резервных копий, выходящих из временных пределов хранения	При возникновении необходимости (срок хранения резервной копии 6 месяцев)
Создание резервной копии БД	Еженедельно
Протоколирование создания резервной копии	При возникновении необходимости, при удалении или создании резервной копии
Ведение журналов ошибок	Регулярно, при возникновении нештатной ситуации в процессе работы подсистемы
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Регулярно, при возникновении нештатной ситуации в процессе работы подсистемы

4.2.2.3 Требования к качеству реализации функций, задач

Задача	Форма представления выходной информации	Характеристики точности и времени выполнения
Удаление резервных копий, выходящих из временных пределов хранения	Запись в журнале событий	Определяется регламентом эксплуатации
Создание резервной копии БД	Запись в журнале событий	Определяется регламентом эксплуатации
Протоколирование создания и удаления резервной копии	Запись в журнале событий	Определяется регламентом эксплуатации
Ведение журналов ошибок	Таблица в БД	Определяется регламентом эксплуатации
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Текстовый файл, оконное сообщение, email	Не позднее 5 минут после возникновения нештатной ситуации

4.2.2.4 Перечень критериев отказа для каждой функции

Функция	Критерий отказа	Время восстановления	Коэффициент готовности
Резервное копирование БД	Не выполняется одна из задач функции.	1 час	0.95
Протоколирование ошибок	Не выполняется одна из задач функции.	1 час	0.9

4.2.3 Подсистема анализа данных

4.2.3.1 Перечень функций, задач подлежащей автоматизации

Функция	Задача
Анализ статистики	Выгрузка данных из подсистемы хранения данных
	Обработка и анализ данных
Анализ текущей информации с терминалов и турникетов	Обработка текущих данных с терминалов и турникетов
	Загрузка данных в подсистему вывода текущей информации
Протоколирует результаты работы	Ведение журналов результатов обработки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

4.2.3.2 Временной регламент реализации каждой функции, задачи

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

4.2.3.3 Требования к качеству реализации функций, задач

Задача	Форма представления выходной информации	Характеристики точности и времени выполнения
Выгрузка данных из подсистемы хранения данных	В интерфейсе подсистемы	Определяется регламентом эксплуатации
Обработка и анализ данных	В интерфейсе подсистемы, таблица	Определяется регламентом эксплуатации
Обработка текущих данных с терминалов и турникетов	В интерфейсе подсистемы	Определяется регламентом эксплуатации
Загрузка данных в подсистему вывода текущей информации	В интерфейсе подсистемы	Определяется регламентом эксплуатации
Ведение журналов результатов обработки данных	Текстовые файлы	Определяется регламентом эксплуатации
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Текстовый файл, оконное сообщение, email	Не позднее 5 минут после возникновения нештатной ситуации

4.2.3.4 Перечень критериев отказа для каждой функции

Функция	Критерий отказа	Время восстановления	Коэффициент готовности
Анализ статистики	Не выполняется одна из задач функции.	3 часа
Анализ текущей информации с терминалов и турникетов	Не выполняется одна из задач функции.	3 часа
Протоколирует результаты работы	Не выполняется одна из задач функции.	3 часа

4.2.4 Подсистема вывода текущей информации

4.2.4.1 Перечень функций, задач подлежащей автоматизации

Функция	Задача
Вывод информации на информационные экраны	Выгрузка данных из подсистемы анализа данных. Визуализация информации
Вывод данных на печать	Выгрузка данных из подсистемы анализа данных. Печать на чековой ленте
Протоколирует результаты работы	Ведение журналов результатов обработки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

4.2.4.2 Временной регламент реализации каждой функции, задачи

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

4.2.4.3 Требования к качеству реализации функций, задач

Задача	Форма представления выходной информации	Характеристики точности и времени выполнения
Выгрузка данных из подсистемы анализа данных	В интерфейсе подсистемы	Определяется регламентом эксплуатации
Визуализация информации	В интерфейсе подсистемы, таблица на информационном экране	Определяется регламентом эксплуатации
Печать на чековой ленте	Чек	Определяется регламентом эксплуатации
Ведение журналов результатов обработки данных	Текстовые файлы	Определяется регламентом эксплуатации
Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы	Текстовый файл, оконное сообщение, email	Не позднее 5 минут после возникновения нештатной ситуации

4.2.4.4 Перечень критериев отказа для каждой функции

Функция	Критерий отказа	Время восстановления	Коэффициент готовности
Вывод информации на информационные экраны	Не выполняется одна из задач функции.	3 часа	0.9
Протоколирует результаты работы	Не выполняется одна из задач функции.	3 часа	0.9

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

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

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

Состав подсистем определен в п.4.1.1. настоящего Технического задания. Дальнейшее его уточнение и детализация должны выполняться на стадиях внедрения по согласованию Заказчика и Исполнителя.

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

4.3.2 Требования к информационному обеспечению

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

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

Данные должны быть организованы в виде реляционной модели.

Система должна быть установлена на серверных мощностях Заказчика.

Способы организации Системы должны предусматривать доступ к данным посредством специализированных АРМ, в строгом соответствии с необходимыми правами и привилегиями пользователей системы.

4.3.2.2 Требования к информационному обмену между компонентами системы

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

	Подсистема сбора, обработки и загрузки данных	Подсистема хранения данных	Подсистема формирования и визуализации отчетности
Подсистема сбора, обработки и загрузки данных		Х	X
Подсистема хранения данных	Х		Х
Подсистема формирования и визуализации отчетности	X	Х

4.3.2.3 Требования к информационной совместимости со смежными системами.

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

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

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

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

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

Основные классификаторы и справочники в системе (клиенты, абоненты, бухгалтерские статьи и т.д.) должны быть едиными.

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

4.3.2.5 Требования по применению систем управления базами данных

Для реализации подсистемы хранения данных должна использоваться промышленная СУБД MicrosoftSQLServer 2008 R2.

4.3.2.6 Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-холодная копия - ежеквартально;

-логическая копия - ежемесячно (конец месяца);

-инкрементальное резервное копирование - еженедельно (воскресение);

-архивирование - ежеквартально;

4.3.2.9 Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы

Требования не предъявляются.

4.3.3 Требования к лингвистическому обеспечению

При реализации системы должны применяться следующие языки высокого уровня: языки программирования из программной платформы .NETFramework не ниже 4-й версии

При реализации системы должны применяться следующие языки и стандарты взаимодействия АСПК со смежными системами и пользователей с АСПК: должны использоваться встроенные средства диалогового взаимодействия BI приложения; С++; HTML; др.

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

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

Для описания предметной области (объекта автоматизации) должен использоваться Erwin.

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

4.3.4 Требования к программному обеспечению

Перечень покупных программных средств:

- MicrosoftSQLServer 2008 R2;

- Службы интеграции MicrosoftSQLServer;

- BI-приложение Jaspersoft.

СУБД должна иметь возможность установки на ОС WindowsServer 2008.

ETL-средство должно иметь возможность установки на ОС WindowsServer 2008.

BI-приложение должно иметь возможность установки на ОС WindowsServer 2008.

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

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

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

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

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

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

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

Необходимость согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ отсутствует.

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

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

Сервер базы данных должен быть развернут на HPIntegritySuperDome, минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: неограничен; NetworkCard: 2 (2 Gbit); FiberChannel: 4.

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

CPU: 8 (16 core); RAM: 32 Gb; HDD: 100 Gb; Network Card: 2 (1 Gbit); Fiber Channel: 2.

Сервер приложений должен быть развернут на платформе HPIntegrity, минимальная конфигурация которого должна быть: CPU: 6 (12 core); RAM: 64 Gb; HDD: 300 Gb; NetworkCard: 3 (1 Gbit).

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

4.3.6 Требования к метрологическому обеспечению

Не предъявляются.

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

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

Обеспечивает эксплуатацию Системы подразделение информационных технологий Заказчика.

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

К организации функционирования АСПК и порядку взаимодействия персонала, обеспечивающего эксплуатацию, и пользователей предъявляются следующие требования:

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

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

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

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

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

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

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

Приводятся название методик, инструкций и ссылки на них дляПО и АПК каждой из подсистем.

4.3.9 Требования к патентной чистоте

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

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

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

Работы по созданию системы выполняются в три этапа:

Проектирование. Разработка эскизного проекта. Разработка технического проекта (продолжительность -- 20 дней).

Разработка рабочей документации. Адаптация программ (продолжительность -- 40 дней).

Ввод в действие (продолжительность -- 35 дней).

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

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