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

Приложение №______

к договору №_______________ от ______

УТВЕРЖДАЮ УТВЕРЖДАЮ

Должность руководителя Генеральный директор

ФГОУ ВПО «ТГПУ им.Л.Н. Толстого» <Наименование организации исполнителя>

________________ ФИО _________________ ФИО

«___»_________ 2016 г. «___»__________2016 г.

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

НАИМЕНОВАНИЕ ОБЪЕКТА АВТОМАТИЗАЦИИ

СОКРАЩЕННОЕ НАИМЕНОВАНИЕ АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

На __ листах

Действует с 1 сентября 2016 г.

СОГЛАСОВАНО

Должность руководителя согласующей

организации

Название согласующей организации

_____________________ ФИО

«___»____________ 2016 г.

Должность руководителя согласующей

организации

Название согласующей организации

____________________ ФИО

«___»___________ 2016 г.

<Наименование исполнителя> Техническое задание

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

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

1.1.1 Полное наименование системы: Разработка веб-сервиса по мониторингу сайтов медицинских учреждений Тульской области

1.1.2 Сокращенное наименование АС Мониторинг сайтов медицинских учреждений ТО

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

Работа выполняется на основании договора № … от … между организацией ФГОУ ВПО «ТГПУ им.Л.Н. Толстого» и Леоновой Надеждой Игоревной.

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

1. Заказчик

Заказчик: ФГОУ ВПО «ТГПУ им.Л.Н. Толстого»

Адрес фактический: г. Тула, пр. Ленина, 125

Телефон / Факс: +7 (4872) 35-14-88

2. Разработчик

Разработчик: Леонова Надежда Игоревна

Адрес фактический: г. Тула, пр. Ленина,125

Телефон / Факс: 8 962 270 31 67

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

Проект выполняется с 1 сентября по 31 декабря 2016 года.

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

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

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

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

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

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

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

Веб-сервис для проведения мониторинга функционирования сайтов медицинских организаций создается с целью:

- обеспечения сбора и первичной обработки исходной информации, необходимой для проведения экспертного оценивания сайта ЛПУ;

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

- создания единой системы отчетности по итогам проверки сайта;

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

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

- время сбора и первичной обработки исходной информации;

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

- время, затрачиваемое на информационно – аналитическую деятельность.

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

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

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

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

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

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

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

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

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

Система Мониторинга сайтов медицинских организаций ТО должна быть централизованной, т. е. все данные должны располагаться в центральном хранилище. Система КХД должна иметь трехуровневую архитектуру.

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

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

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

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

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

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

Численность персонала, обслуживающего ПО, должна соответствовать нормам, определяемым техническими требованиями к используемому оборудованию. В течение 12 месяцев после внедрения ПО поставщик ПО, создав внедренческую группу, должен обслуживать ПО.  Поставщик ПО осуществляет обучение сотрудников по работе со ПО в количестве не менее 3 человек. 

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбой общего или специального программного обеспечения.

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

Время восстановления работоспособности ПО при любых сбоях и отказах не должно превышать 3-х часов. Сюда входит разворачивание и настройка специального программного обеспечения на сервере(-ах), восстановление данных с использованием последней резервной копии и «накат» по журналам до состояния, предшествовавшего аварии. В указанное время не входит решение проблем с техническим обеспечением и инсталляция операционной системы. Поставщик оказывает консультативную помощь сотрудникам ЛПУ по восстановлению ПО.

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

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

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

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

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

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

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

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

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

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

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

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

ПО должно обеспечивать удобный для пользователя интерфейс, отвечающий следующим требованиям: 1) в части внешнего оформления:

а) реализация в графическом оконном режиме по стандартам, принятым для реализации программных продуктов, функционирующих под управлением графической многозадачной операционной системы (Microsoft Windows 9x, Windows NT 4, Windows XP/2000/2003); б) единый стиль оформления интерфейса пользователя для всей системы.

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

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

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

1. обеспечение стандартного SQL-интерфейса (возможность соответствия ИСО/ANSI/IEC 9579-2:1993);

2. поддержка режима удаленного доступа (возможность соответствия ИСО/ANSI/IEC 9579-1:1993);

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

4. обеспечение возможности резервного копирования данных без приостановки работы СУБД с сохранением целостности данных;

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

6. использование декларативного контроля целостности с целью повышения надежности прикладных систем;

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

8. наличие средств ограничения ресурсов на уровне пользователей;

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

4.1.7. Требования к защите информации о несанкционированного доступа.

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

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

4.1.7.2. Требования к антивирусной защите.

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

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

4.1.7.3. Разграничения ответственности ролей при доступе к <указать объект ограничения (например, отчет, показатель, измерение) >.

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

4.1.8. Требования по сохранности информации при авариях

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

4.1.9. Требования к защите от влияния внешних воздействий.

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

4.1.10. Требования по стандартизации и унификации.

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEFIX в рамках рекомендаций по стандартизации P50.1.028-2001 « Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования».

4.1.11. Дополнительные требования.

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

4.1.12. Требования безопасности.

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

4.1.13. Требования к транспортабельности для подвижных АИС.

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

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

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

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

1. Регистрация пользователей

2. Авторизация зарегистрированных пользователей

3. Экспертное оценивание

4. Результат мониторинга

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервер базы данных должен быть развернут SQL SERVER (Microsoft).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СОСТАВИЛИ

Наименование организации, предприятия	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата
	Ведущий веб-разработчик	Леонова Надежда Игоревна		09.2016 г.

СОГЛАСОВАНО

Наименование организации, предприятия	Должность	Фамилия, имя, отчество	Подпись	Дата
ФГОУ ВПО «ТГПУ им.Л.Н. Толстого»				01.09.2016 г.