Приложение № 1 «Регистр качества образования Тульской области»

Приложение № 1
к запросу котировок
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на выполнение работ по созданию и внедрению информационно-аналитической системы
«Регистр качества образования Тульской области»
1.1. Полное наименование системы и её условное обозначение
Полное наименование системы: «Регистр качества образования Тульской области»
(далее - Система).
1.2. Термины и сокращения
ВШК – внутришкольный контроль;
ЭЖД – электронный журнал/дневник;
ЧТЗ – частное техническое задание;
ОЗУ - Оперативное запоминающее устройство;
ПДн – персональные данные;
ГИА – государственная итоговая аттестация;
ЕГЭ – единый государственный экзамен;
ИСПДн – информационная система персональных данных;
КЭС – коды элементов содержания;
СУБД – система управления базами данных;
ТЗ – техническое задание на создание Системы;
УМК – учебно-методический комплект;
1.3. Порядок оформления и предъявления заказчику результатов работ по
созданию Системы.
Компоненты Системы внедряются на основе приёмки по результатам опытной
эксплуатации.
Порядок предъявления Системы и её окончательной приемки определен в п.8
настоящего ТЗ. Совместно с предъявлением Системы производится сдача разработанного
Подрядчиком комплекта документации согласно п.7 настоящего ТЗ.
1.4. Перечень нормативно-технических документов, методических
материалов, использованных при разработке ТЗ.
При разработке автоматизированной Системы и создании проектноэксплуатационной документации Подрядчик должен руководствоваться требованиями
следующих нормативных документов:

ГОСТ 19.201-78. Техническое задание. Требования к содержанию и
оформлению;

ГОСТ 34.601-90. Комплекс стандартов на автоматизированные
системы. Автоматизированные системы. Стадии создания;

ГОСТ 34.201-89. Информационная технология. Комплекс стандартов
на автоматизированные системы. Виды, комплексность и обозначение документов
при создании автоматизированных систем;

РД 50-34.698-90. Методические указания. Информационная
технология.
Комплекс
стандартов
на
автоматизированные
системы.
Автоматизированные системы. Требования к содержанию документов.

1.5. Срок выполнения работ: в течение 70 (семидесяти) рабочих дней с даты
заключения Договора, допускается удаленное выполнение работ.
1.6. Место выполнения работ: административное здание, расположенное по
адресу: 300041, г. Тула, пр. Ленина, д.2., допускается удаленное выполнение работ.
2. Назначение и цели создания Системы
Основным назначением информационно-аналитической Системы является создание и
внедрение ее в образовательную среду для объективной оценки качества образования,
управления качеством образования на всех уровнях региональной системы образования с
привлечением всех участников образовательного процесса с целью повышения качества
образования в Тульской области и его открытости для общественности.
Цели системы оценки качества образования Тульской области следующие:
 Оценка уровня соответствия получаемых образовательных результатов учащихся
Тульской области государственным образовательным стандартам, ожиданиям
потребителей, общероссийскому и международному уровням.
 Обеспечение различных пользователей достоверной информацией о состоянии
образовательной системы Тульской области и реальном качестве регионального
образования.
 Создание инструментов общественного участия в управлении социальнообразовательной средой Тульской области.
Задачи построения модели тульского регистра качества образования:
 Создание тульского регистра качества образования с учетом сложившихся
информационных потоков по существующим направлениям оценки качества
образования.
 Формирование системы индикаторов и измерителей для различных пользователей
на всех уровнях (региональном, муниципальном, школьном), позволяющей
эффективно реализовывать основные цели и функции оценки качества образования
и влиять на развитие качества образования через включение показателей оценки в
новую систему оплаты труда.
 Сетевое распределение ответственности по оценке качества образования на
школьном, муниципальном, региональном уровнях управления, а также между
различными организационными структурами системы образования Тульской
области.
 Создание сети лабораторий качества образования и внутренних систем управления
качеством образования на уровне образовательных учреждений.
 Подготовка квалифицированных кадров для экспертизы и оценки качества
образования на всех уровнях: региональном, муниципальном, конкретного
образовательного учреждения.
3. Состав и содержание работ по созданию Системы
Регистр качества образования Тульской области представляет собой единую
региональную информационную систему сбора, хранения и обработки данных, необходимых
для объективной оценки и управления качеством образования в Тульской области. В основу
регистра положен перечень показателей качества образования, разработанный с учетом
сложившихся процессов региональной оценки качества образования (городской
мониторинг уровня обученности, на основе проведения диагностики образовательных
достижений учащихся; ГИА-9, ЕГЭ; международные, региональные олимпиады и
конкурсы обучающихся; конкурсы профессионального мастерства; общественногосударственная экспертиза деятельности ОУ и педагогов; внутришкольный контроль;
лицензирование образовательной деятельности и государственная аккредитация ОУ;
самообследование и анализ деятельности образовательных учреждений, педагогов,
учащихся, социологические исследования в области образования и др.). На основе данных
показателей возможно провести оценку качества реальных образовательных результатов и
образовательного процесса в целом.
Регистр качества образования Тульской области должен обеспечить:
 сбор, интеграцию и обработку данных, необходимых для оценки качества тульского
образования на областном, общегородском, и школьном уровнях;
 прозрачность процедур оценки качества деятельности педагогов и образовательных
учреждений на основе оценки реальных образовательных результатов и достижений
обучающихся;
 формирование в информационной системе электронных портфолио трех типов:
школы, учителя, ученика;
 анализ актуального состояния качества образования и возможность планирования его
дальнейшего развития.
Описание модели регистра качества образования Тульской области
«Регистр качества образования Тульской области» – информационно-аналитическая
система Тульской области, объединяющая информацию о качестве образования в
образовательных учреждениях Тульской области и позволяющая управлять областной
системой качества образования с учетом вовлечения в нее всех категорий пользователей
на всех уровнях региональной системы образования.
Основная цель регистра – обеспечить непрерывность полнофункционального
мониторинга качества образования в общеобразовательных учреждениях.
Анализ данных регистра позволит образовательной системе Тульской области получать
регулярные аналитические обзоры состояния качества образования, прогнозировать
тенденции развития системы образования, конкретных образовательных учреждений и
областных систем.
Основные принципы:
 непрерывность мониторинга;
 прозрачность;
 достоверность;
 Концепция системы: «пополняемая и расширяемая база данных о качестве
образования и условиях его реализации.
Элементы структуры регистра качества образования Тульской области:
 информационные потоки;
 образовательный аудит и самоаудит;
 образовательная статистика;
 итоговая аттестация выпускников 9-х, 11-х классов;
 система внутреннего мониторинга качества образования;
 образовательные достижения учащихся;
 мониторинг и диагностика обученности;
 лицензирование и аттестация учреждений образования аккредитационная экспертиза
учреждений образования;
 общественно-государственная экспертиза деятельности учреждения;
 профессиональная аттестация педагогов;
 профессиональные конкурсы мастерства;
Три составляющие образования
 условия образовательного процесса
 организация образовательного процесса
 результаты образовательного процесса

Уровни структурирования информации




ученик
педагог
образовательная организация – информационное ядро
муниципальное образование (учредители, экспертные и контрольно-надзорные
службы)
 Область (учредители, экспертные и контрольно-надзорные службы).
Истории образовательных достижений обучающихся и профессиональной деятельности
педагогов сохраняются на протяжении всего периода обучения, работы в
общеобразовательном учреждении (включая переход ученика, учителя в другое
образовательное учреждение Тульской области).
Пользователи информации о качестве образования
 родители, ученик
 педагог, образовательная организация
 работодатели
 общественность
 органы управления
Автоматизированная информационная система (АИС) автоматически определяет уровни
доступа пользователей и формирует необходимый программный интерфейс для работы в
системе.
Описание модулей системы:
Портфолио ученика.
 Общие сведения
 Фамилия, имя и отчество, дата и место рождения.
 Социальное положение
 Группа здоровья (пополняемая история здоровья).
 Успеваемость по предметам (на базе вводимых диагностик и расчетов).
 Сводные ведомости по итоговой успеваемости обучающихся.
 Успехи и достижения обучающегося
Портфолио педагогического работника.
 Общие сведения
 Фамилия, имя и отчество, дата и место рождения.
 Опыт работы: трудовой стаж, педагогический стаж, стаж работы в данном
образовательном учреждении).
 Категория или разряд.
 Квалификационные характеристики
 Образование (диплом, его номер, кем и когда выдан).
 Повышение квалификации (название курсов повышения квалификации, кол-во
часов, сроки, тема).
 Ученая степень, звание (диплом, номер, кем и когда выдан).
 Обучение в аспирантуре (наименование учебного заведения).
 Учебная нагрузка
 Классное руководство с привязкой к номеру класса и обучающимся в данном
классе.
 Результаты аттестации
 Методический потенциал





Наличие собственных методических разработок и их публикаций по проблемам
образования (с указанием вида публикации, наименования работы, издательства,
объёма печатных листов и даты издания).
Перечень используемых в обучении учебных УМК.
Участие в конкурсах (название, год, результат):
Результаты обучающихся
Сведения о поощрениях (наличие и количество дипломов, грамот и
благодарственных писем об участии педагогов в различных мероприятиях
(конкурсы, спортивные соревнования, мастер-классы, конференции, олимпиады и
прочие значимые мероприятия).
Портфолио образовательного учреждения.
 Общая информация об образовательной организации (с возможностью изменения,
смены статуса).
 Подчинение;
 Название по Уставу и аккредитации;
 Тип и вид образовательной организации с сохранением истории изменений.
 Фактический адрес всех зданий.
 Директор организации (приказ о назначении, дата, номер).
 Номер и срок действия лицензии.
 Номер и срок действия аккредитации.
 Наличие структурных подразделений (приказы по каждому структурному
подразделению с указанием даты начала действия).
 Реализуемые образовательные программы
 Формы обучения.
 Количественный состав обучающихся (данные автоматически формируются на
основании заполненных портфолио учащихся). Наличие портфолио каждого
обучающегося обязательно.
 Группы здоровья (данные автоматически формируются на основании заполненных
портфолио учащихся).
 Кадровый состав
 Административный, административно-хозяйственный, педагогический и учебновспомогательный состав
 Квалификационные категории учителей (% учителей с соответствующей
квалификационной категорией). Данный пункт формируется автоматически из
данных портфолио учителя.
 Педагогический стаж учителей: % молодых учителей до 5 лет, имеющих
педагогический стаж работы от 5 до 10 лет, более 10 лет, пенсионеры (с указанием
стажа работы в данном учебном заведении). Данный пункт формируется
автоматически из данных портфолио Учителя.
 Ресурсное обеспечение образовательного процесса
 Результативность деятельности образовательной организации по результатам ГИА,
ЕГЭ, олимпиад и конкурсов.
 Удовлетворенность образовательной организацией
 Общественная оценка (родители, ученики, общественность): возможность
заполнения специальной анкеты для формирования отзыва по каждому
образовательной организации путем проставления баллов по различным критериям
на специально выделенном для этого интернет-ресурсе, включенном в данные
проект.
Личные кабинеты и уровни доступа к информации
Личный кабинет педагогического работника
 Возможность работы со своими учащимися согласно «портфолио ученика».
 Пополнение данных о себе в «портфолио педагогического работника»
 В случае, если учитель имеет статус психолога, данный учитель имеет
возможность вносить данные по психологическим особенностям учащихся.
 Персональный интерфейс классного руководителя.
 Ввод результатов обученности учащихся (технология Московского центра качества
образования).
 Получение аналитики по обученности класса, а также мониторинг индивидуальных
учебных достижений учащихся.
 Личный кабинет административного работника образовательного учреждения
 Ввод данных в «портфолио образовательного учреждения».
 Расстановка кадров согласно тарификации.
 Планирование деятельности
 Результаты внутришкольного контроля и внешней оценки деятельности школы.
 Движение учащихся.
 Движение кадрового состава и наличие вакансий
 Анализ данных, внесенных педагогическим работником..
Личный кабинет муниципального образования (области)
 Получение аналитических материалов по образовательным организациям.
 Доступ к информации по образовательным организациям и кадровому составу.
 Возможность в режиме реального времени контролировать и анализировать
качество деятельности образовательных организаций с использованием данных
реестров.
 Возможность
информационного
взаимодействия
с
образовательными
организациями и педагогическими работниками.
Модуль аналитики (примеры выборок).
 Выборки качества обучения и усвоения материалов по предметам применительно к
отдельно взятому учащемуся, классу или же образовательному учреждению в
целом.
 Преподавательский состав и его характеристика, методический потенциал,
повышение квалификации и общественная активность преподавателей.
 Анализ удовлетворенности родителей образовательной организации в режиме
реального времени.
 Анализ обученности учащихся.
На уровне учредителя создаются списки сотрудников уровня учредителя и руководители
образовательных организаций, словари значений основных параметров образовательных
организаций, сами образовательные организации. Созданные сотрудники уровня
учредителя имеют разные уровни доступа - с доступами к своим зонам ответственности в
Системе. Значения из словарей отображаются на страницах кабинетов в соответствующих
разделах, требующих заполнения этих значений для школ или детских садов, учебных
групп, классов, учеников. Образовательные организации получают доступ
администратора с правом предоставления уровней доступа, логинов и паролей
сотрудникам, ученикам и их родителям.
На уровне руководителя происходит заполнение конкретной информации по
образовательным организациям - добавление учеников, сотрудников, их прав и уровней
доступа, атрибутов (зданий, аудиторий, инвентаря и детского сада и т.п.). Также на этом
уровне происходит управление мероприятиями, управление процедурами контроля,
блоками внутреннего и внешнего управления образовательной организацией.
На уровне сотрудника происходит управление текущим учебным процессом,
добавление и изменение тем уроков, домашних заданий, контрольных работ,
проставление оценок.
На уровне ученика и родителя осуществляется контроль над текущим учебным
процессом, домашними заданиями, контрольными работами, оценками.
На уровне кабинета инспекции создаются списки сотрудников уровня инспекции,
эксперта, словари значений основных параметров образовательных организаций. Также на
этом уровне происходит управление процессами лицензирования, аккредитации и других
контрольно-надзорных мероприятий.
На уровне кабинета администратора происходит поддержка работоспособности
всех модулей, разделов и кабинетов Системы.
Система включает также в себя ряд нижеописанных блоков, каждый из которых
выполняет свои функциональные задачи.
3.1. Журнал/Дневник
Журнал позволят проставлять оценки за все виды активности в ходе учебного
процесса. Можно добавлять виды активности для конкретного урока, связывать уроки с
учебным планом. В журнал преподаватель также заносит домашние задания и
контрольные работы. Ученик в дневнике в соответствующем интерфейсе может
ознакомиться с информацией о текущей активности в школе, о невыполненных домашних
заданиях и предстоящих контрольных работах.
Статистика по каждому классу для любого периода по любому предмету может быть
выведена как в виде таблиц, так и в виде графиков.
3.2. ВШК
Внутришкольный контроль производится автоматически по параметрам,
заносимым в Систему преподавателями. Контрольные работы отображаются в качестве
статистики любого вида. Также в Системе должна быть доступна возможность
персонального контроля.
Модуль ВШК предназначен для автоматизации следующих технологических процессов:
- интеграция всех процессов, связанных с проведением контрольных работ в ЭЖД;
– выгрузки содержания состоявшейся контрольной работы по КЭС;
– выгрузки протокола качества выполнения контрольной работы в личные электронные
кабинеты родителей и учащегося;
– выгрузки оценок за состоявшуюся контрольную работу в электронный журнал и
дневник учащегося;
3.3. Аттестация
Аттестация может быть инициирована как с уровня преподавателя, так и с других
уровней. При этом создается событие аттестации, связанное с конкретным человеком. В
зависимости от типа аттестации для участников процесса аттестации доступны даты
мероприятий аттестации. Для аттестуемого преподавателя доступно общение с
проверяющим документы экспертом. О событиях аттестации, требующих присутствия
преподавателя, преподаватель своевременно узнает из Системы. Все заинтересованные
лица также получают уведомление об исходе процедуры аттестации.
3.4. Отчеты
Отчеты могут быть выведены для всех процессов, происходящих в Системе, как в
виде таблиц, так и в виде графиков за любой период.
3.5. Реестры
В Системе должен функционировать раздел, в котором размещены необходимые
реестры, организованные через фильтр для удобства.
Данный реестр будет включать в себя перечень:
 Образовательных организаций, при нажатии на которые, должно
открываться карточка образовательной организации;
 Кадров каждой образовательной организации, при нажатии на
определённого
сотрудника
должно
открываться
портфолио
сотрудника
образовательной организации;
 Список учащихся данной образовательной организации, при нажатии на
фамилию и инициалы ребёнка должно открываться портфолио учащегося;
 Список результатов и достижений сотрудников и руководителей
образовательных организаций в агрегированном виде.
Необходим единый реестр успеваемости школьников по классам, единый реестр
организаций, подведомственных министерству образования Тульской области, единый
реестр педагогических и управленческих кадров области:

ФИО,

повышение квалификации,

образование,

ученая степень,

награды,

самообразобразование,

методические разработки, публикации,

аттестация, квалификационная категория,

стаж работы,

педагогическая нагрузка,

выбор УМК,

классное руководство,

результаты ЕГЭ, ГИА,

результаты участия учащихся в олимпиадах, конкурсах, спортивных
соревнованиях,

результаты контрольных работ.
Детализированные требования к функционированию данного раздела должны быть
определены в частном техническом задании (ЧТЗ) «Настройка кабинетов пользователей
Системы».
3.6. Лицензирование, Аккредитация и другие Контрольно-Надзорные мероприятия.
Работа с ними осуществляется по типу аттестации. Инициирующей стороной
создается событие мероприятия. Данные обо всех событиях оперативно поступают ко
всем участникам процесса. Из базы по критериям выбирается эксперт, получающий
доступ к интересующей его информации. У него есть возможность также добавить
опросник для дополнительных вопросов. Свои выводы он также загружает в Систему.
Итог мероприятия доводится до всех заинтересованных лиц через Системы общения и
управления процедурами надзора и контроля.
Детализированные требования к настройке данных блоков Системы, а также
требования к настройке всех кабинетов пользователей Системы должны быть определены
в частном техническом задании (ЧТЗ) «Настройка кабинетов пользователей Системы».
4. Требования к Системе
В системе должны быть организованы кабинеты для всех категорий пользователей:
Кабинет учредителя, инспекции, управления образовательной организации,
руководителя образовательной организации, кабинет учителя, кабинет ученика/родителя,
кабинет эксперта.
Все настройки кабинетов и их функциональные требования прописываются в ЧТЗ.
5. Требования к составу и параметрам технических средств
5.1. Требования к техническим средствам
5.1.1 Требования к аппаратной конфигурации серверной части Системы
Исходя из требований максимальной нагрузочной способности на тестовый период
и требований на объем динамического контента, передаваемого с сервера приложений
можно определить следующие требования к аппаратной конфигурации:
Максимальное время отклика Системы в моменты пиковой нагрузки не должно
превышать 20 секунд. Максимальное количество одновременно подключенных
пользователей Системы во время пиковой нагрузки составит 200 образовательных
организаций * 100 пользователей в каждой образовательной организации = 20000
пользователей. При заданном объеме контента 500 кБ на пользователя, объем
передаваемых данных от кластера серверов приложений по выходному каналу ЦОД
составит 20000 пользователей * 0,5 МБайт / 20 секунд = 500 MБайт/сек.
Таким образом, ЦОД в моменты пиковой нагрузки на Систему должен иметь
выходной интернет-канал с пропускной способностью не менее 4 ГБит/с. Один сервер
приложений, с конфигурацией, указанной в данном ТЗ сможет обеспечить отдачу
контента со скоростью 10 ГБит/сек. Таким образом, кластер серверов приложений на
тестовый период должен составлять с учетом потерь на кластеризацию и дублирование 2
(два) сервера приложений.
На генерацию контента на одного пользователя в объеме 500 кБайт будет
среднестатистически выполняться 5 запросов к базе данных. Примерно 20% из которых
будут представлять собой табличные данные, которые будут составлять примерно 70%
объема передаваемого контента. Тогда, объем данных, получаемых от кластера СУБД,
будет равен 350 МБайт/сек. Один сервер СУБД, с конфигурацией, указанной в п. 5.1
данного ТЗ сможет обеспечить отдачу данных со скоростью 10 ГБит/сек. Следовательно,
кластер серверов СУБД с учетом потерь на кластеризацию, репликацию и дублирование
должен составлять 2 (два) сервера СУБД. Каждый сервер СУБД при этом будет
обрабатывать 20000 пользователей * 5 запросов / 20 секунд = 5000 запросов на кластер / 2
сервера = 2500 запросов в секунду.
Web-проекты с нагрузкой выше 50000 посетителей и проекты со специальными
требованиями по безопасности должны проектироваться на физически выделенных
серверах.
5.1.2 Предлагаемая конфигурация вычислительного кластера для обеспечения
требуемой нагрузки.
Сервер СУБД/Приложения: HP ProLiant DL160 Gen8:
Intel® Xeon® E5-2667 (2.9GHz/6-core/15MB/8GT-s QPI/130W, DDR3-1600, HT,
Turbo2- 3/3/3/4/5/6) – на тестовый период используется 1 процессор (из 2-х возможных)
размер 1U;
24 слота для памяти DDR3-1600 ;
Поддержка до 768 ГБ ОЗУ – на тестовый период используется 16 ГБайт;
SAS RAID контроллер HP SmartArray P420 (до 2ГБайт ОЗУ DDR3-1333);
2 x HDD 600 Gb SAS 2.0 Hitachi Ultrastar 15K600 < HUS156060VLS600> 3.5"
15000rpm 64Mb
5.2. Требования к программным средствам
5.2.1. Требования к программному обеспечению серверной части
Для распределения нагрузки на сервера приложений и соответствующие им
сервера баз данных и обеспечения в тоже время целостности данных, СУБД в кластере
должны синхронизироваться по схеме репликации транзакций (TransactionalReplication).
При этом выбирается сервер кластера, который будет выполнять роль Ведущего (Master),
остальные сервера выполняют роль Ведомых (Slave). Для репликационных данных на
стадии тестового периода выделяется место на дисковом пространстве одного из Ведомых
серверов кластера. Для передачи реплик синхронизации выделяется отдельный сегмент
локальной сети с пропускной способностью 1 Гбит/с, для чего сервера баз данных должны
быть оборудованы дополнительными сетевыми интерфейсами.
Пропускная способность канала для реплик синхронизации определяется
отношением объема реплицируемых данных к данным, отдаваемым в канал серверов
приложений, которые соотносятся как менее чем 1/10 и определяется отношением объема
операций Запись/Чтение.
5.2.2 Требования к клиентскому программному обеспечению
Система должен быть доступен для полнофункционального просмотра с помощью
следующих браузеров:
Microsoft Internet Explorer 8.0 и выше
Opera 11.0 и выше
Google Chrome 14.0
Mozilla Firefox 5.0 и выше
AppleSafari 5.0 и выше
Требования к рабочим местам определяются возможностью запуска и
комфортной работой вышеуказанных браузеров на соответствующих операционных
Системах. Пример желательной, но не обязательной конфигурации: CPU - IntelCore 2 Duo
1,8 ГГц, ОЗУ - 1ГБ, HDD – 80 ГБ, Windows 7 Начальная. Минимальная конфигурация:
Intel Pentium 300 Мгц, ОЗУ – 128 МБ, HDD – 4Гб, Windows XP Home Edition SP3, Internet
Explorer 8.i
6. Специальные требования
6.1. Требования к надежности
Надежность информационной Системы определяется совокупностью факторов
надежности: кабельной компоненты Системы, сетевого оборудования, источников
питания, вычислительной техники, системного, сетевого и прикладного программного
обеспечения.
При размещении на
территории ЦОД, удовлетворяющего требованиям
эксплуатационной документации, Система должна обеспечивать обслуживаемое
функционирование в режиме 24х7х365 с допустимыми перерывами на профилактику,
перенастройку и простоями в связи с неисправностью, исходя из требования обеспечить
коэффициент готовности Системы 0,95.
6.1.1 Перечень аварийных ситуаций
Ниже приводится перечень возможных аварийных ситуаций с указанием
требований к средствам восстановления работоспособности Системы.
Сбой общего или специального программного обеспечения Системы, отдельного
рабочего места или сервера.
После сбоя серверной операционной Системы или СУБД в процессе выполнения
пользовательских задач должно быть обеспечено восстановление данных в базе данных до
состояния на момент окончания последней нормально завершенной перед сбоем
транзакции.
Время восстановления работоспособности при сбоях и отказах не должно
превышать 6-х часов. В это время не входит разворачивание и настройка специального
программного обеспечения на сервере(ах). В указанное время не входит решение проблем
с техническим обеспечением и инсталляция операционной Системы.
Выход из строя части технических средств Системы.
Выход из строя одного из рабочих мест или нарушение канала связи локальной
сети между рабочим местом и сервером не должны приводить к прекращению
функционирования Системы, при этом должна обеспечиваться возможность выполнения
функций, связанных с вышедшим из строя рабочем месте на другом рабочем месте
пользователя.
Выход из строя сервера Системы не должен приводить к прекращению работы
функционирования Системы при этом должна предусматриваться работа с одним или
более дублирующим сервером.
Сбои или выход из строя активного накопителя на жестком магнитном диске.
В Системе должна быть предусмотрена отказоустойчивая Система хранения
данных с использованием избыточности информации.
В Системе должна быть обеспечена возможность восстановления данных с
внешнего накопителя после восстановления активного накопителя.
Импульсные помехи, сбои или прекращение электропитания.
Импульсные помехи, сбои или прекращение электропитания не должны приводить
к выходу из строя технических средств Системы и/или нарушению целостности данных.
6.1.2 Требования к надежности технических средств и программного
обеспечения
Ниже приводится перечень требований к надежности технических и программных
средств:
Технические средства должны обеспечивать сохранность информации
центральных серверов при сбоях в электропитании технических средств. Сбои и отказы
электропитания не должны приводить к разрушению основных технических средств и
разрушению подсистемы защиты информации.
Центральные устройства Системы (серверы приложений, серверы СУБД,
основные сетевые устройства) не должны терять работоспособности при
кратковременных (до 15 мин.) перебоях в электропитании. Для этого должны
использоваться бесперебойные источники питания (UPS) с последующим штатным
выводом Системы из функционирования.
Технические средства должны сохранять работоспособность и обеспечивать
целостность данных за счет резервирования критических компонентов оборудования
узлов и программного обеспечения, мер по обеспечению структурной избыточности,
вводимой при проектировании узла. Конкретные технические решения и список
подсистемы, подлежащих резервированию, уточняются при техническом проектировании.
Для обеспечения надежности функционирования компонент Системы
должны быть предусмотрены организационно – технические меры по поддержанию их
работоспособности при выходе из строя основных носителей информации и источников
питания, а также средства автоматического корректного завершения работы серверов при
полном отказе по питанию.
Характеристики надежности технических средств, входящих в Систему,
определяются техническими условиями на эти средства.
Среднее время восстановления работоспособности оборудования Системы
зависит от наличия и комплектности запасных изделий и принадлежностей, а также
состава
контрольно-измерительных
приборов,
имеющегося
у Заказчика
в
эксплуатационных подразделениях.
6.1.3 Детализированные требования к надежности
Требования к надежности программно-технических компонентов Системы
должны быть уточнены на стадиях испытаний и эксплуатации Системы и согласовываться
соответствующим протоколом. Для оценки надежности Системы могут использоваться
расчетные, опытно-статистические, экспертные методы, а также их комбинации.
6.2. Требования к защите информации от несанкционированного доступа
6.2.1 Требования к разделению доступа
Система должна обеспечивать:

идентификацию пользователя;

аутентификацию пользователя;

идентификацию технических средств пользователя по логическому
имени;

регистрацию успешных и неуспешных попыток доступа к
функциональным возможностям Системы;

проверку полномочий пользователя при попытке запуска Системы;

проверку полномочий пользователя при попытке запуска средств
администрирования Системы.
Аутентификация для работы со средствами размещения информации в Системе
должна производиться по персональным именам пользователя и паролю.
Система разграничения доступа должна обеспечивать следующие возможности:

ведение полномочий пользователей;

разграничение доступа пользователя к Системе в соответствии с его
полномочиями на уровне:

функциональной компоненты;

информационного объекта;

элементарного действия.

Система разграничения доступа должна обеспечивать поддержку
следующих уровней доступа:

запрет доступа к данным;

доступ только на чтение;

доступ на редактирование;

доступ на добавление/удаление (полный доступ).

Разграничение доступа к Системе на уровне функциональной
компоненты
должно
обеспечивать
возможность
определять
список
функциональных компонент, которые может запускать конкретный пользователь.
К рассматриваемым компонентам относятся:

средство администрирования Системы;

функциональная подсистема;

функциональная задача подсистемы;

шаблоны ввода информации;

отчеты.
Разграничение доступа к Системе на уровне элементарных действий определяет
перечень элементарных действий, которые пользователь не может выполнять над
информационными объектами. К запрещаемым элементарным действиям относятся:

первоначальный ввод объекта учета;

корректировка полей объекта учета;

удаление объекта учета;

изменение логических связей объекта учета.
По умолчанию все действия во всех модулях для вновь создаваемых пользователей
запрещены. Каждое из вышеуказанных действий может быть по отдельности разрешено
или запрещено для определенного пользователя для каждого из разделов
(функциональных блоков) подсистемы.
В Системе должна существовать возможность входа под главной
административной учетной записью, которая предоставляет право на совершение любых
предусмотренных функционалом подсистемы действий в любых разделах подсистемы.
Полномочия пользователей должны устанавливаться только администратором
средств защиты информации в соответствии с требованиями Заказчика.
Данные о полномочиях пользователей должны храниться в базе данных и
защищаться штатными средствами используемой Системы управления базами данных.
6.2.2 Требования по защите персональных данных
Поскольку Система использует и обрабатывает персональные данные, она должна
удовлетворять требованиям Федерального закона № 152-ФЗ «О персональных данных».
Данные, используемые в Системе, такие как Имя, Фамилия, Отчество, Год, Месяц, Дата и
Место рождения определяют 3-ю категорию ПДн. Учитывая охватываемое количество
пользователей Системы более 100 000 субъектов ПДн, классификация ИСПДн в
соответствии с Приказом ФСТЭК России, ФСБ России, Мининформсвязи России №
55/86/20 от 18.02.2009 г. «Об утверждении порядка проведения классификации
информационных Системы персональных данных» соответствует классу ИСПДн К2.
Требования к Системе в соответствии с классом ИСПДн К2 на уровне
разрабатываемого Web-приложения:
6.2.2.1 Идентификация и проверка подлинности
Идентификация и проверка подлинности пользователя при входе в Систему должна
осуществляться по паролю условно-постоянного действия длиной не менее шести
буквенно-цифровых символов.
6.2.2.2 Регистрация взаимодействия
При входе/выходе пользователя в/из Системы сохраняются регистрационные
данные, такие как дата и время входа/выхода, результат попытки входа (успешная или
неуспешная), идентификатор (код или фамилия), предъявленный при попытке доступа.
6.2.2.3 Обеспечение целостности
Обеспечение целостности программных средств защиты персональных данных,
обрабатываемой информации, а также неизменность программной среды. Целостность
программных средств проверяется при загрузке Системы по контрольным суммам
компонентов средств защиты информации, а целостность программной среды
обеспечивается использованием трансляторов с языков высокого уровня и отсутствием
средств модификации объектного кода программ в процессе обработки и (или) хранения
защищаемой информации.
6.2.2.4 Физическая охрана информационной Системы
Физическая охрана информационной Системы (устройств и носителей
информации) предусматривает контроль доступа в помещения информационной Системы
посторонних лиц, наличие надежных препятствий для несанкционированного
проникновения в помещения информационной Системы и хранилище носителей
информации, учет всех защищаемых носителей информации с помощью их маркировки и
занесения учетных данных в журнал учета с отметкой об их выдаче (приеме)
осуществляется на уровне ЦОД.
6.2.2.5 Периодическое тестирование функций Системы
Периодическое тестирование функций Системы защиты персональных данных при
изменении программной среды и пользователей информационной Системы с помощью
тест-программ, имитирующих попытки несанкционированного доступа;
6.2.2.6 Безопасность передачи данных
Для обеспечения безопасности предаваемых данных по каналу связи от клиентской
машины до сервера Системы данные передаются по защищенному протоколу HTTPS. Так
же группа документов, нуждающаяся в защите от несанкционированного доступа и
хранящаяся на региональных ЦОД должна передаваться по HTTPS. Поэтому имена
региональных серверов должны представлять собой субдомены вида «*.domain.ru», для
упрощения процедуры получения сертификата (с поддержкой субдоменов).
6.2.2.7 Защита от DDOS атак
Для обеспечения защиты от DDOS должны использоваться как программные так и
аппаратные средства.
6.3. Требования по сохранности информации при авариях
Сохранность информации в Системе будет обеспечиваться при следующих
аварийных ситуациях:
•
Полный или частичный отказ технических средств Системы, включая сбои и
отказы накопителей на жестких магнитных дисках;
•
Сбой общего или специального программного обеспечения Системы.
Будут разработаны процедуры резервного копирования и средства восстановления
данных и программного обеспечения на случай возникновения аварии (физическая порча
носителей, находящихся в эксплуатации, выход из строя основного оборудования,
повреждение кабельной Системы). Будут предусмотрены меры по регулярному
сохранению (архивированию) файлов и баз данных (нормативно-справочных,
технологических, производственно-хозяйственных т.п.) на всех уровнях КИС.
6.4. Прочие требования
6.4.1 Требования к информационному обеспечению
6.4.1.1 Требования к хранению данных
Все данные Системы должны храниться в структурированном виде под
управлением реляционной СУБД. Исключения составляют файлы данных,
предназначенные для просмотра и скачивания (изображения, видео, шаблоны документов
и т.п.). Такие файлы сохраняются на отдельных серверах контента. Для защищенных
документов на региональных ЦОД должны соблюдаться условия на ограничение доступа
к информации.
Наполнение Системы (контент), функционирование которого поддерживается
одной и той же инсталляцией Системы, должно храниться под управлением единой
СУБД.
Учетная запись, которая будет использоваться для получения данных сервером
приложения от кластера СУБД должна быть ограничена в правах на доступ к другим
(Системным) базам данных и на доступ к изменению в структуре БД.
6.4.1.2 Требования к языкам программирования
Для реализации статических страниц и шаблонов должны использоваться языки
XHTML 1.1 и CSS 2.1. Исходный код должен разрабатываться в соответствии со
стандартами W3C (XHTML 1.1).
Для реализации интерактивных элементов клиентской части должны
использоваться языки JavaScript с использованием технологии jQuery.
Для реализации динамических страниц должен использоваться язык PHP.
6.4.1.3 Требования к организации гиперссылок
Все ссылки в Системе должны быть относительными (за исключением внешних).
Внешние ссылки должны помечаться значком .
6.4.1.4 Требования по обеспечению доступности Web-контента
Все страницы Системы должны быть доступны по спецификации WCAG 2.0
уровня АА для обеспечения доступа к информации пользователей с ограниченными
возможностями, включая пользователей с ограничениями по зрению (незрячих и
слабовидящих), по слуху (глухих и слабослышащих), пользователей с когнитивными
ограничениями, нарушениями моторики и речи, фоточувствительностью и различными
комбинациями перечисленного.
6.4.1.5 Требования к иллюстрациям
Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы)
должны быть выполнены с замещающим текстом (использование тэга ALT спецификации
языка XHTML 1.1, см. также п. 3.4.4). Все рисунки должны быть в формате GIF (для
изображений с несколькими цветами, например, логотип), JPEG (для детализированных
изображений с большим количеством цветов, таких как фотографий) или PNG (для
оформления дизайна, где требуется изображения с прозрачностью).
6.4.1.6 Требования к объему одной страницы
Объем одной стандартной загружаемой страницы Системы, включая табличные,
динамически подгружаемые данные, в среднем не должен превышать 500 kb.
К объему статических данных особые требования не предъявляются.
6.4.1.7 Требования к рендерингу и скорости передачи контента.
На страницах должна использоваться отложенная загрузка JavaScript.
Все JavaScript и CSS файлы должны быть объединены в один и минимизированы.
6.4.1.8 Требования к кэшированию контента.
Для проверки изменений контента на сервере следует использовать валидатор
ETag. Для его корректного функционирования Web-сервер должен быть настроен на его
использование как на этапе разработки, так и на этапе эксплуатации Системы.
6.4.2 Требования к лингвистическому обеспечению
Разработка Системы должна осуществляться с применением промышленных
средств анализа и моделирования компонент Системы на основе структурного и
объектно-ориентированного подходов, средств управления требованиями, средств
конфигурационного управления и управления изменениями, средств оценки трудоемкости
и планирования разработки, средств документирования, а также средств тестирования.
В качестве языка манипулирования данных должны быть использованы версии
языка SQL (Structured Query Language) для выбранных целевых СУБД.
7. Требования к программной документации
7.1 Требования к документированию.
Помимо общих требований, описанных в данном техническом задании, по
Договору должно быть разработано детализированное частное техническое задание (ЧТЗ)
«Настройка кабинетов пользователей Системы».
Вся разработанная документация будет представлена Заказчику в 3-х экземплярах
на бумажном и в 3-х экземплярах на машинном носителях в согласованном с Заказчиком
формате.
Тексты программ будут представляться только на машинных носителях в формате
(нотации) используемой среды разработки.
Проектная и рабочая документация будет соответствовать требованиям ГОСТ
34.201-89 «Виды, комплектность и обозначения документов при создании
автоматизированных Системы» и РД 50-34.698-90 «Автоматизированные Системы.
Требования к содержанию документов».
Общее системное программное обеспечение и технические средства снабжаются
документацией, входящей в поставляемый производителем комплект, отдельная
документация не разрабатывается.
7.2. Полный состав, формат представления и содержание рабочей
документации уточняются на стадии технического проектирования.
В состав рабочей документации будут включены, как минимум:
Общее описание Системы;
Инструкции пользователям по работе с отдельными подсистемами Системы;
Инструкция администратора Системы;
Программа опытной эксплуатации;
Тексты программ (только на машинном носителе).
По итогам испытаний Подрядчиком будут оформлены и согласованы с Заказчиком:
Протокол предварительных испытаний;
Отчет об опытной эксплуатации;
Протокол опытной эксплуатации;
Протокол приемочных испытаний.
Подрядчик разрабатывает, согласовывает с государственным заказчиком регламент
технической поддержки, включающий:
категоризацию важности (критичности) обращения в увязке с моделью угроз и
рисков;
перечень специалистов и должностных лиц государственного заказчика и
пользователя, имеющих право инициировать процедуры технической поддержки;
определение способов реагирования на обращение в зависимости от его характера
и категории важности (консультирование и инструктирование, дистанционное
обслуживание Системы по сетям связи, выезд для проведения работ по местонахождению
технических средств).
Подрядчик обязан разработать регламент технического обслуживания,
включающий в себя:
перечень процедур (операций) технического обслуживания и обоснование
необходимости каждой в увязке с моделью угроз и рисков;
периодичность выполнения каждой операции.
временные рамки (длительность) каждой операции;
уровень деградации доступности (работоспособности) обслуживаемой подсистемы
(сервиса) на время выполнения операции;
перечень специалистов и должностных лиц Подрядчика, государственного
заказчика и пользователя, отвечающих за организацию процедур технического
обслуживания.
Подрядчик составляет и представляет Подрядчику отчет о проведенных
мероприятиях по подготовке объекта автоматизации к вводу в действие и внедрению
Системы, включающий:

перечень работ по переносу информационного обеспечения Системы
из существующих баз данных;

перечень проведенных учебных занятий с указанием данных
обученных пользователей и персонала Системы;

перечень обращений за консультациями и принятых мер (выданных
рекомендаций).
8. Порядок сдачи-приемки работ.
Прием осуществляется комиссией по пунктам технического задания с
демонстрацией функционала страниц. В ходе тестирования также проверяется
быстродействие, соответствие предъявляемым в данном техническом
требованиям к интерфейсам и взаимодействию пользователя с системой.
Директор государственного автономного
учреждения Тульской области «Центр
информационных технологий»
задании
И.Г. Маградзе
Ответственный за составление технического
задания – начальник отдела контроля и
планирования комитета Тульской области по
инновациям и информатизации
Я.Ю. Раков