Без имени (стр. 1 )

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

на создание автоматизированной системы

поддержки работы на оптовом рынке электроэнергии и мощности

(АС ОРЭМ)

ОГЛАВЛЕНИЕ

1.        Введение        3

1.1        Полное наименование информационной системы        3

1.2        Термины и сокращения        3

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

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

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

2.1        Сведения об объекте автоматизации        5

2.2        Исходное состояние объекта автоматизации        5

2.3        Целевое состояние объекта автоматизации        5

2.4        Категория обрабатываемой информации        5

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

3.1        Структура системы        6

3.2        Требования к АРМ        6

3.3        Требования к оснащению рабочих мест пользователей:        6

3.4        Требования к серверному оборудованию        7

3.5        Функциональная архитектура Системы        8

3.6        Подсистема «Сбор данных»        8

3.7        Подсистема «НСИ»        9

3.8        Подсистема «Работа с торговой системой»        10

3.9        Подсистема «Формирование отчетов и анализ»        10

3.10        Подсистема «Администрирование»        11

3.11        Требования по взаимодействию с другими системами        11

3.12        Дополнительные требования к системе        12

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

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

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

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

3.17        Требования к информационной  безопасности        15

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

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

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

4.        Порядок контроля и приемки системЫ        20

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

4.2        Этапы и результаты работ по созданию системы        20

4.3        Требования к испытаниям системы и ее составных частей        22

4.4        Мероприятия по обучению персонала        23

4.5        Мероприятия по организационному обеспечению        24

5.        Требования по организации гарантийной технической поддержки        25

6.        ПРИЛОЖЕНИЯ        26

6.1        Приложение 1. Функциональная архитектура Системы        26

6.2        Приложение 2. Перечень данных, подлежащих автоматическому сбору        27

6.3        Приложение 3. Взаимодействие со смежными системами        34

Введение Полное наименование информационной системы Автоматизированная система поддержки энергосбытовой деятельности участника на оптовом рынке электроэнергии и мощности (далее - Система). Условное обозначение системы: АС ОРЭМ. Термины и сокращения

АИИС КУЭ	- автоматизированная информационно-измерительная система коммерческого учета электроэнергии;
АПК	- аппаратно-программный комплекс;
АРМ	- автоматизированное рабочее место;
БД	- база данных;
БР	- балансирующий рынок;
ВСВГО	- выбор состава включенного генерирующего оборудования;
ГТП	- группа точек поставки;
ДПМ	- Договор поставки мощности;
ЕСПД	- единая система программной документации;
Заказчик	- ;
ЗСП	- Зона свободного перетока;
Исполнитель	- организация, на основании договора выполняющая работы по созданию информационной системы в соответствии с настоящими требованиями;
Информационная система	- Совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств;
ККС	Информационно-телекоммуникационная сеть, объединяющая локальные вычислительные сети организаций системы «Транснефть» и обеспечивающая защищенный обмен информацией между ними;
КОМ	- конкурентный отбор мощности;
Коммерческий оператор (КО)	- Коммерческий оператор оптового рынка электроэнергии и мощности, ;
Макет 30308	- Формат СО для предоставления заявок на почасовое потребление участников ОРЭМ;
НСИ	- нормативно-справочная информация;
ОДУ	- объединенное  диспетчерское управление, филиал ЕЭС»;
ОРЭМ	- оптовый рынок электроэнергии (мощности);
ОС	- операционная система;
ПО	- программное обеспечение;
ППП	- плановое почасовое потребление;
РД	- регулируемые договора;
РДУ	- региональное диспетчерское управление, филиал ЕЭС»;
РСВ	- рынок на сутки вперед;
СДД	- свободные двухсторонние договора;
СДЭМ	- свободные договора электроэнергии и мощности;
Системный оператор (СО)	- Системный оператор единой энергетической системы, ЕЭС»;
СУБД	- система управления базами данных;
ТЗ	- Техническое задание на создание Системы;
ФСТ	- федеральная служба по тарифам;
ЭЦП	- Электронно-цифровая подпись.

Назначение системы Система предназначена для автоматизации процесса сбора, обработки, и представления показателей работы Заказчика на оптовом рынке электроэнергии и мощности, на основании данных АИИС КУЭ, внутренней отчетности, а также сведений, представляемых Коммерческим оператором и Системным оператором по конкретному участнику ОРЭМ. Система также предназначена для автоматизации расчетов на ОРЭМ и подачи ценовых заявок. Цели создания системы Целью создания Системы является повышение эффективности деятельности Заказчика за счет:

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

Характеристики объекта автоматизации Сведения об объекте автоматизации Система создается как локальная система , организационный объем внедрения охватывает отдел по работе на ОРЭМ. Объектом автоматизации являются бизнес-процессы отдела по работе на ОРЭМ . Исходное состояние объекта автоматизации На текущий момент бизнес-процессы отдела по работе на ОРЭМ не автоматизированы. Информация с сайтов КО и СО загружается специалистами отдела вручную, данные о плановых объемах потребления ОСТ поступают в виде excel-файлов, получение информации из автоматизированной системы «1С-Предприятие» осуществляется периодической ручной выгрузкой, формирование ценовых заявок ведется в АРМ «Заявки» (предоставляется КО), формирование макетов 30308, а также анализ результатов работы Заказчика на ОРЭМ ведется посредством MS Excel. Целевое состояние объекта автоматизации По завершении внедрения Системы, деятельность по обеспечению работы Заказчика на ОРЭМ должна вестись в Системе. Сбор информации с сайтов КО и СО, информации, регулярно поступающей по e-mail, информации из АИИС КУЭ должен быть максимально автоматизирован. Формирование макетов 30308 и ценовых заявок должно производиться в Системе в автоматизированном режиме. Система должна вести накопление информации о результатах работы общества на ОРЭМ для ее дальнейшего анализа и формирования необходимых отчетов. Система должна обеспечивать работу следующих типов (групп) пользователей:

Пользователь; Администратор; Куратор информационной безопасности.

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

Автоматизированные рабочие места (АРМ); Технологические узлы (Серверы).

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

сервер(ы) БД; сервер(ы) с модулями программного обеспечения.

Система должна иметь возможность интеграции и информационного обмена с имеющимися автоматизированными системами Заказчика. Количество пользователей системы: 20 конкурентных клиентских мест. Требования к АРМ Разрабатываемые АРМы Системы должны обладать следующими общими функциональными возможностями:

Управление процессом ввода и обработки данных (ввод, отмена ввода, сохранение данных, изменение данных); Просмотр введенной (полученной) информации на экране монитора; Печать информации на бумажном носителе; Доступ к выполнению всех операций ввода, вывода или просмотра должен предоставляться в соответствии с правами и полномочиями пользователя.

Требования к оснащению рабочих мест пользователей: Аппаратные средства (предоставляются Заказчиком):

Системный блок: тип процессора: Intel Core 2 Duo 2 GHz; объем оперативной памяти: не менее 4096 MB; жесткий диск: от 500GB, свободное место не менее 100 GB; сетевая карта: 100Mbps. Монитор: разрешение: от 1280х1024; диагональ: от 20’’; Клавиатура; Мышь.

Программные средства:

Операционная система Windows 7 и выше; MS Internet Explorer 8.0 и выше.

Аппаратные и программные средства рабочих мест пользователей предоставляются Заказчиком Связь между АРМ и технологическими узлами Системы должна осуществляться техническими и программными средствами сети передачи данных. Система должна обеспечивать возможность ввода и корректировки данных, как ручным способом, так и путем автоматической обработки (загрузки) данных, полученных посредством электронной почты или через общую файловую систему с использованием форматов TXT, XML, XLS, CSV. Разрабатываемое ПО не должно иметь лицензионных ограничений по количеству каких-либо объектов НСИ, временных ограничений использования, ограничений на количество запусков системы и всех ее модулей. Требования к серверному оборудованию Аппаратные средства (предоставляются Заказчиком):

Аппаратный или виртуальный сервер с параметрами не хуже: архитектура: 2-х процессорный; тип процессора: Intel Xeon E5-2650; частота не ниже 2 GHz; объем оперативной памяти: не менее 8 GB; объем дискового  массива: не менее 500 GB; сетевая карта: 1Gbps.

Программные средства:

операционная система: Семейство Windows Server 2008-2012 (MS Windows Server 2012 (R2) Standard); СУБД: MS SQL-Server версии не ниже 2008 (MS SQL-Server 2012 (R2) Standard).

Окончательные параметры и состав серверного оборудования согласовываются на этапе согласования ТЗ. Необходимые лицензии в рамках Microsoft Enterprise Agreement предоставляются Заказчиком. Функциональная архитектура Системы Система должна состоять из следующих подсистем:

Подсистема «Сбор данных» - предназначена для автоматизированного сбора данных по показателям работы на оптовом рынке электроэнергии и мощности; Подсистема «НСИ» - обеспечивает возможность ввода и редактирования нормативно-справочной информации о различных информационных объектах, используемых при работе на ОРЭМ; Подсистема «Работа с торговой системой» - предназначена для формирования уведомлений СО о ППП и ценовых заявок КО для участия в торгах на РСВ; Подсистема «Формирование отчетов и анализ» - предназначена для формирования отчетности о результатах торгов на ОРЭМ, количественных и ценовых показателях ОРЭМ.

Функциональная архитектура Системы приведена в Приложении 1. Подсистема «Сбор данных» Подсистема должна обеспечивать выполнение следующих функций:

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

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

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

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

Имя пользователя и пароль для доступа к персональному разделу сайта КО; Перечень почтовых серверов, имен пользователей и паролей для загрузки данных по электронной почте; Перечень файловых каталогов для загрузки файлов данных; Реестр типов обрабатываемых макетов; Допустимое количество параллельных потоков обработки (разбора) поступивших макетов, выполняемых на сервере Системы.

Перечень данных, подлежащих автоматическому сбору, обработке и сохранению в БД, представлен в Приложении 2. Подсистема «НСИ» Подсистема должна обеспечивать возможность ведения справочников следующих информационных объектов:

Справочник контрагентов; Справочник ГТП; Справочник ЗСП; Справочник регионов; Справочник секторов ОРЭМ; Справочник ценовых зон; Справочник типов обязательств ОРЭМ; Реестр договоров РД; Реестр договоров ДПМ; Реестр договоров КОМ; Реестр договоров РСВ; Реестр договоров БР; Реестр договоров СДД; Реестр внебиржевых СДЭМ; Графики поставки и платежей по договорам; Реестры обязательств по договорам; Реестр платежей по договорам; Тарифы ФСТ по станциям, индикативные цены по регионам.

Полный перечень хранимых информационных объектов должен быть определен на этапе разработки ТЗ. Подсистема должна предоставлять возможность отбора (поиска) информационных объектов по произвольным критериям. Подсистема должна поддерживать ведение версионности (историчности) информационных объектов. Подсистема должна предоставлять возможность выгрузки реестров информационных объектов в формате MS Excel. Подсистема «Работа с торговой системой» Подсистема предназначена для подготовки ценовых заявок СО и КО для участия в торгах на РСВ. Подсистема должна обеспечивать выполнение следующих задач:

Формирование и подача заявки на плановое почасовое потребление на технологический сайт СО как в разрезе ГТП, так и в целом по ОДУ; Формирование и подача заявки на плановое почасовое потребление с использованием ПО «АРМ Заявки» для отправки заявок в КО; Выполнять корректировку сформированных ценовых заявок; Обеспечивать хранение сформированных заявок; Выполнять сервисные операции: печать, экспорт.

Подсистема «Формирование отчетов и анализ» Подсистема предназначена для формирования статистической отчетности о результатах торгов на оптовом рынке электроэнергии (мощности) с возможностью формирования плановых данных об объемах, ценах и стоимости покупки электроэнергии и мощности на ОРЭМ по ГТП в разрезе месяц, квартал, год. Отчетность необходимо получать как в табличном, так и в графическом виде. Состав и формат стандартизированных форм отчетности определяется на этапе разработки ТЗ. Сведения в отчетах необходимо детализировать по временным периодам, а также по различным объектам учета:

ГТП; узлам расчетной модели; видам финансовых обязательств.

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

формирование аналитических отчетов о результатах оптовой торговли электроэнергией в стандартизированном формате с возможностью корректировки (пользователь самостоятельно устанавливает необходимую структуру отчетов, состав данных и период отчета); формирование плановой структуры затрат на ОРЭМ (месяц, контрольная дата) по ГТП на основе данных предыдущих периодов, данных о плановых объемах и структуре потребления электроэнергии и мощности, тарифах и ценах; формирование разноски оплат по договорам ОРЭМ в разрезе секторов и контрагентов; контроль исполнения бюджетных показателей; расчет стоимости услуг инфраструктурных организаций; визуальное представление сведений, содержащихся в отчетах, в виде графиков и диаграмм.

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

В гибкой системе формирования отчетов должна быть возможность использовать все данные, перечисленные в п. п.3.6 и 3.7 настоящих Технических требований; Экспорт отчетов в форматах: документов MS Office, XML, HTML, PDF.

Подсистема «Администрирование» Подсистема «Администрирование» должна обеспечивать возможность:

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

Требования по взаимодействию с другими системами Система должна иметь возможность интеграции и информационного обмена с имеющимися информационными системами Заказчика. Схема взаимодействия с информационными системами приведена в Приложении 3. Подсистема «Сбор данных» должна взаимодействовать со следующим ПО (импорт данных): «1С Предприятие», ПК «Энергосфера» (данные АИИС КУЭ), Банк Клиент (настраиваемый интерфейс обмена данными), Почтовая система Заказчика (MS Exchange) с возможностью приема подписанных ЭЦП и/или зашифрованных сообщений, АРМ Участника ОРЭМ, Биллинг . Подсистема НСИ должна взаимодействовать со следующим ПО (импорт/экспорт данных): Биллинг , ПО «1С Предприятие», Банк Клиент (настраиваемый интерфейс обмена данными). Подсистема «Работа с торговой системой» должна взаимодействовать со следующим ПО (импорт/экспорт данных): Почтовая система Заказчика (MS Exchange) с возможностью приема и отправки подписанных ЭЦП и/или зашифрованных сообщений, АРМ «Заявки». Работа с ЭЦП (прием и отправка подписанных и зашифрованных сообщений), а также доступ в закрытые (персональные) разделы сайтов КО и СО должны осуществляться посредством ПО CryptoPro. Дополнительные требования к системе Система и входящие в ее состав подсистемы должны поддерживать следующие режимы функционирования:

Основной режим; Профилактический режим.

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

Масштабируемость Системы как относительно количества объектов НСИ, пользователей Системы, объема накопленных оперативных данных, так и модернизации аппаратных средств серверной и клиентских частей; В рамках технической поддержки Системы должно быть предусмотрена оперативная адаптация выполняемых Системой функций в случае изменения норм и правил (регламентов) работы ОРЭМ.

Требования к численности и квалификации персонала Системы и режиму его работы В состав персонала, обеспечивающего физическую эксплуатацию АРМ и технологических узлов Системы, должны быть включены следующие типы пользователей:

Администратор; Пользователи; Куратор информационной безопасности.

Окончательный список типов персонала, осуществляющего эксплуатацию Системы, определяется на этапе согласования ТЗ. Администратор – обеспечивает функционирование технических и программных средств подсистем. Его функциональные обязанности:

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

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

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

Куратор информационной безопасности – имеет доступ к просмотру журналов событий (логов) системы, прав уровня доступа для различных групп пользователей. Эксплуатация Системы должна проводиться персоналом, прошедшим обучение работе с Системой. Администраторы должны пройти обучение у поставщика соответствующего общесистемного программного обеспечения (ПО) и иметь (по возможности) соответствующие сертификаты. Численность, должностные обязанности и режим работы персонала, а также требования к его квалификации определяются на стадии «Рабочая документация» на основании (с учетом) организационной структуры объекта автоматизации. Показатели назначения Система должна быть реализована как открытая, т. е. допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов. Разрабатываемое ПО Системы должно быть гибким, т. е. легко настраиваемым в соответствии с изменениями условий функционирования и организационной структуры объекта автоматизации Системы. Разрабатываемое ПО должно сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой технологического узла, но не менее 20 АРМ. Технологические узлы должны обеспечивать возможность модернизации как путем замены на новую версию общесистемного ПО, так и за счет модернизации ПО разрабатываемых Исполнителем подсистем. Требования к надежности Архитектура Системы должна обеспечивать отказоустойчивый режим функционирования при круглосуточном режиме работы, при наличии связи между АРМ и технологическим узлом, а так же проведение полного и инкрементального архивирования данных. В качестве аппаратных платформ при построении технологических узлов Системы должны использоваться средства повышенной надежности. Среднее время восстановления аппаратно-программных комплексов (АПК) технологических узлов не должно превышать 4 часов. Надежность ПО Системы должна обеспечиваться следующими средствами:

Совокупностью общесистемного и разрабатываемого Исполнителем ПО, в том числе: средствами управления базами данных; ПО разрабатываемой Исполнителем Системы; общесистемным ПО АРМ; средствами резервного копирования БД и серверной конфигурации Системы; (обеспечивается Заказчиком) проведением Исполнителем комплекса мероприятий отладки, поиска и исключения ошибок на стадии «Ввод в действие» (этап «Проведение опытной эксплуатации»); алгоритмы и программные комплексы должны быть проверены на наличие системных и логических ошибок путем проведения испытаний; на этапе опытной эксплуатации должны быть исправлены все выявленные ошибки кодирования и сборки программ.

Проверка выполнения требований по надежности должна производиться на стадии «Ввод в действие» - по методике Исполнителя, согласованной с полномочными представителями Заказчика. В Системе должно быть обеспечено создание резервных копий данных и основных настроек системы, а также восстановление после сбоев. Максимальное время восстановления работоспособности подсистемы при любых сбоях и отказах технологического узла не должно превышать 4-х часов. За это время должны быть выполнены:

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

Требования к эргономике и технической эстетике Требования текущего раздела не распространяются на интерфейс пользователя общесистемных программных средств, а относятся лишь к разрабатываемому Исполнителем ПО, непосредственно взаимодействующему с операторами Системы:

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

Организация графического пользовательского интерфейса должна препятствовать ошибочным действиям пользователей, в том числе:

Пользователь должен иметь возможность контролировать ввод данных: просматривать введенные данные, производить их корректировку или же отказаться от ввода; При вводе должны максимально использоваться справочники и списки допустимых значений; Должна обеспечиваться возможность определения и сохранения значений по умолчанию; При обнаружении Системой ошибок в действиях пользователя должно выдаваться сообщение с диагностикой, достаточной для исправления ошибки. Алгоритмы определения ошибочных действий пользователя и содержание сообщений должны быть определены и согласованы с Заказчиком на стадии «Технорабочий проект».

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

- ОР-35.240.00-КТН-09907 Регламент организации работ по защите информации при разработке, внедрении и эксплуатации информационных систем, информационно-коммуникационных сетей и автоматизированных систем предприятий группы «Транснефть»; - Политика парольной защиты в , утвержденной приказом ; - других нормативных документов по работе с информацией, имеющей ограничительные грифы «Конфиденциально» и «Коммерческая тайна».

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

Разрабатываемое ПО не должно требовать для установки, активации, работы, обновления или деинсталляции связи с ресурсами разработчика или ресурсами, размещенными в публичной (общедоступной) сети Интернет. Разрабатываемое ПО не должно использовать в своей работе протоколы, передающие аутентификационные данные в открытом виде. В случае, если разрабатываемое ПО предполагает многопользовательский доступ к системе, ПО должно позволять назначать каждому пользователю уникальный идентификатор. Для взаимодействия компонентов ПО в автоматическом режиме должны использоваться уникальные предустанавливаемые технологические учетные записи. Все предустановленные учетные записи должны иметь возможность смены пароля. Должна осуществляться идентификация субъектов доступа при входе в систему. Должна осуществляться аутентификация (проверка подлинности) субъекта при доступе в систему на основе имени пользователя и пароля. Пароль должен отвечать требованиям Политики парольной защиты в , утвержденной приказом . Отображение аутентификатора при вводе его пользователем должно обеспечивать защиту от несанкционированного использования. Должна быть обеспечена криптографическая защита аутентификационных данных, хранимых и передаваемых по сети в рамках процедур идентификации и аутентификации. Разрабатываемое ПО не должно требовать использования в штатном режиме работы пользователей съемных носителей информации. Все типовые операции обмена файлами должны быть автоматизированы. Место расположения объекта для выгрузки/загрузки должно быть настраиваемым и должно позволять загружать/выгружать файлы с ресурса сети, идентифицируемого IP-адресом или DNS-именем. Разрабатываемое ПО должно обеспечивать возможность разграничения доступа на основе ролевой модели. Набор предоставляемых роли полномочий должен быть настраиваемым. Любое назначение прав в системе должно выполняться явным образом. 12)        Административные функции должны быть отделены от пользовательских функций. Доступ к наиболее критичным функциям, влияющим на безопасность системы, в том числе правам управления учетными записями, изменениям настроек протоколирования работы системы, должен предоставляться в явном виде. Должна осуществляться регистрация следующих видов событий: вход субъектов доступа в систему; использование административных привилегий, в том числе создание, модификация, удаление учетных записей, а также изменение прав доступа к системе. В параметрах регистрации должны быть указаны: дата и время события; вид события; идентификатор пользователя. Разрабатываемое ПО не должно требовать для работы пользователей предоставления им дополнительных привилегий в ОС или СУБД. Разрабатываемое ПО должно ограничивать возможность ввода и проверять достоверность вводимых данных на предмет синтаксиса, формата данных, соответствия диапазонам граничных значений и др.

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

Документация на разрабатываемое ПО должна содержать: описание реализованных защитных мер; перечень используемых протоколов/сервисов с указанием их назначения; перечень и описание предустановленных учетных записей, в том числе технологических. Документ «Программа и методика испытаний» на разрабатываемое ПО должен в явном виде включать в себя тесты по безопасности, обеспечивающие проверку работоспособности реализованных защитных мер. В случае выявлений уязвимостей в разработанном им программном обеспечении в период действия гарантийного срока или услуг по технической поддержке, Разработчик обязан обеспечить выпуск обновления, закрывающего данную уязвимость, не позднее 30 дней с момента уведомления его о наличии уязвимости. Должна быть обеспечена совместимость прикладного ПО с критичными обновлениями безопасности (патчами) используемых ОС и СУБД. В период действия гарантийного срока или услуг по технической поддержке Разработчик обязан в срок, не превышающий 30 дней от выпуска соответствующего  обновления разработчиком ОС или СУБД, подтвердить возможность установки данного обновления на промышленные системы без риска нарушения их работоспособности или, в случае наличия неразрешенного конфликта между прикладным ПО и обновлением, предложить компенсационные меры снижения риска, связанного с незакрытыми уязвимостями, на период устранения данного конфликта. Обновления ПО должны быть обеспечены способом, исключающим его случайное или преднамеренное искажение.

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

импульсные помехи, сбои и перерывы в электропитании; нарушение или выход из строя каналов связи; полный или частичный отказ технических средств Системы, включая сбои и отказы накопителей на жестких магнитных дисках; сбой общесистемного ПО, отдельного АРМ, сервера технологического узла; ошибки в работе персонала.

Требования к патентной чистоте Проектные решения Системы должны отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации. Необходимые лицензии общесистемного ПО (ОС, СУБД и т. д.) не входящие в Microsoft Enterprise Agreement должны быть предоставлены Исполнителем в рамках договора по созданию Системы. Все лицензии на Систему (неисключительные), обеспечивающие отсутствие каких-либо ограничений на использование Системы за исключением количества пользователей, указанного в п.3.1.8, а также используемого серверного оборудования, указанного в п.3.4.1 настоящих ТТ,  должны быть предоставлены Исполнителем в рамках договора по созданию Системы. Требования по стандартизации и унификации При разработке Системы должна обеспечиваться унификация и стандартизация на уровне интерфейсов взаимодействия пользователей с разрабатываемыми Исполнителем подсистемами Системы. Должна обеспечиваться возможность совмещения на одном физическом рабочем месте нескольких подсистем и различных АРМ (в соответствии с правами пользователя). Порядок контроля и приемки системЫ Порядок оформления и предъявления заказчику результатов работ. Сдача-приемка этапов выполненных работ на стадиях работ осуществляется по предъявлении Исполнителем комплектов соответствующих документов и завершается оформлением акта сдачи-приемки, подписанного Исполнителем и утвержденного Заказчиком. В процессе приемки результатов должна быть осуществлена их проверка на соответствие требованиям «Технического задания». Испытания Системы должны быть проведены на стадии «Ввод в эксплуатацию» на основании Программы и методики испытаний, подготовленной Исполнителем и утвержденной Заказчиком на стадии «Технорабочий проект». Этап «Предварительные испытаний» завершается оформлением акта о приемке Системы в опытную эксплуатацию с приложением к нему протоколов испытаний. Результаты работ по этапу «Опытная эксплуатация» принимаются с оформлением Акта о завершении опытной эксплуатации. Все замечания к ПО и эксплуатационной документации, выданные Заказчиком при сдаче системы в опытную эксплуатацию или в процессе опытной эксплуатации, должны быть устранены Исполнителем до предъявления Системы к приемочным испытаниям. Порядок и сроки проведения приемочных испытаний определяются на этапе «Опытная эксплуатация». Приемку работ осуществляет приемочная комиссия, сформированная Заказчиком, в состав которой могут быть включены представители Заказчика и других организаций по согласованию с Заказчиком. Этап «Проведение приемочных испытаний» заканчивается оформлением акта о приемке Системы в промышленную эксплуатацию. Этапы и результаты работ по созданию системы

Таблица 4.2.1