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

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

Введение

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

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

1. Выбор темы

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

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

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

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

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

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

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

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

1 Установить датчики на кассах для подсчета количества человек, стоящих в очереди.

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

3 Создать блок хранения данных, для хранения статистики и использование её для блоков составления расписания и блок обработки статистики.

4 Создать блок составления расписания и рассылки его сотрудникам, для решения проблемы по неэффективному использованию кассиров.

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

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

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

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

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



Рисунок 3 - АИС.

На рисунке 3 можно увидеть структуру автоматизированной информационной системы «Касса», как видно из рисунка данная структура позволяет обеспечить составление актуального расписания для сотрудников для рационального использования их сил и сокращения фонда заработной платы.

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

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

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

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

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

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

Автоматизированная система проката коньков.

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

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

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

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

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

Заказчик

Заказчик: ООО «Ледовый дворец»

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

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

Разработчик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбор статистики по посещаемости не ведется.

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

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

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

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

автоматизированный система управление модель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· СУБД Microsoft SQL Server 2008 R2;

· MicrosoftVisualStudio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- MicrosoftSQLServer 2008 R2;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервер базы данных должен быть развернут на 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 Тб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виды и объем испытаний системы

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

1. Предварительные испытания.

2. Опытная эксплуатация.

3. Приемочные испытания.

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

Состав, объем и методы опытной эксплуатации системы определяются документом «Программа опытной эксплуатации», разрабатываемым на стадии «Ввод в действие».

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

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

Стадия испытания	Участники испытания	Место и срок проведения	Порядок согласования документации	Статус приемочной комиссии
Предварительные испытания	Организации Заказчика и Разработчика	На территории Заказчика, с 01.11.2012 по 11.11.2012	Проведение предварительных испытаний. Фиксирование выявленных неполадок в Протоколе испытаний. Устранение выявленных неполадок. Проверка устранения выявленных неполадок. Принятие решения о возможности передачи АСПК в опытную эксплуатацию. Составление и подписание Акта приёмки АСПК в опытную эксплуатацию	Экспертная группа
Опытная эксплуатация	Организации Заказчика и Разработчика	На территории Заказчика, с 15.11.2012 по 01.12.2012	Проведение опытной эксплуатации. Фиксирование выявленных неполадок в Протоколе испытаний. Устранение выявленных неполадок. Проверка устранения выявленных неполадок. Принятие решения о готовности АСПК к приемочным испытаниям. Составление и подписание Акта о завершении опытной эксплуатации АСПК	Группа тестирования
Приемочные испытания	Организации Заказчика и Разработчика	На территории Заказчика, с 03.12.2012 по 25.12.2012	Проведение приемочных испытаний. Фиксирование выявленных неполадок в Протоколе испытаний. Устранение выявленных неполадок. Проверка устранения выявленных неполадок. Принятие решения о возможности передачи АСПК в промышленную эксплуатацию. Составление и подписание Акта о завершении приемочных испытаний и передаче АСПК в промышленную эксплуатацию. Оформление Акта завершения работ.	Приемочная комиссия

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

Основные мероприятия по подготовке объекта автоматизации к вводу системы в действие:

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2) изменения, которые необходимо осуществить в объекте автоматизации;

3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

4) создание необходимых для функционирования системы подразделений и служб;

5) сроки и порядок комплектования штата и обучения персонала.

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

Технические мероприятия

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

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

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

- организовано необходимое сетевое взаимодействие.

Организационные мероприятия

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

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

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

- выделение ответственных специалистов со стороны Заказчика для взаимодействия с проектной командой по вопросам взаимодействия с системами-источниками данных.

Изменения в информационном обеспечении

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

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



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

Этап	Документ
Проектирование. Разработка эскизного проекта. Разработка технического проекта.	Ведомость эскизного проекта
	Пояснительная записка к эскизному проекту
	Ведомость технического проекта
	Пояснительная записка к техническому проекту
	Схема функциональной структуры
Разработка рабочей документации. Адаптация программ	Ведомость эксплуатационных документов
	Ведомость машинных носителей информации
	Паспорт
	Общее описание системы
	Технологическая инструкция
	Руководство пользователя
	Описание технологического процесса обработки данных (включая телеобработку)
	Инструкция по формированию и ведению базы данных (набора данных)
	Состав выходных данных (сообщений)
	Каталог базы данных
	Программа и методика испытаний
	Спецификация
	Описание программ
	Текст программ
Ввод в действие	Акт приёмки в опытную эксплуатацию
	Протокол испытаний
	Акт приемки Системы в промышленную эксплуатацию
	Акт завершения работ

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

Настоящее Техническое Задание разработано на основе следующих документов и информационных материалов:

- Договор № 1 от 15.09.2012 между ООО «Ледовый дворец» и ООО «АП»

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

- ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для различных климатических районов. Категории, условия эксплуатации, хранения и транспортирования в части воздействия климатических факторов внешней среды».