|
УТВЕРЖДАЮ
Президент
АО «НИАЭП»
В.И. Лимаренко
____________________________
подпись
«___» ________ 2015 года
|
ЗАКУПОЧНАЯ ДОКУМЕНТАЦИЯ
открытый одноэтапный запрос предложений в электронной форме без квалификационного отбора на право заключения договора на выполнение работ по теме: «Разработка программного обеспечения «Модуль формирования пропусков» для нужд АО «НИАЭП»
лот № 231ИТ/ЗП-015
том 2 «техническая часть»
2015
Оглавление
Термины и сокращения ………………………………………………………………… 3
Общие сведения ……………………………………………………………………… 4
Объект использования программного обеспечения …………………………… 4
Наименование Исполнителя и Заказчика …………………………………………4
Перечень документов, на основании которых разрабатывается программное обеспечение …………………………………………………………………………… 5
Порядок оформления и предъявления заказчику результатов работ
по разработке программного обеспечения ……………………………………… 5
Назначение программного обеспечения …………………………………………. 5
Задачи, решаемые исполнителем …………………………………………………..7
Описание функционала программного обеспечения …………………………… 8
8.1 Технические требования …………………………………………….………….. 8
8.2 Основной функционал программного обеспечения ………………………… 8
8.3 Требования к интерфейсу ……………………………………………………….11
Характеристика объекта автоматизации …………………………………………11
Требования к системе в целом …………………………………………………… 12
Требования к видам обеспечения ………………………………………………… 15
Порядок приемки и контроля результатов работ ……………………................ 16
Термины и сокращения
БП
|
Бюро пропусков
|
БП АО «НИАЭП»
|
Представительство АО «НИАЭП» в Республике Беларусь
|
БелАЭС
|
Белорусская АЭС
|
Заявитель
|
Лицо, формирующее заявку на пропуск
|
ФИО
|
Фамилия, имя, отчество сотрудника
|
КПП
|
Контрольно-пропускной пункт
|
ЛВС НИАЭП
|
Локально-вычислительная сеть АО «НИАЭП»
|
ЛПР
|
Лицо, принимающее решение о выдаче пропуска. Назначается из числа ответственных сотрудников организации, нуждающейся в пропуске
|
Отдел СБ
|
Отдел специальной безопасности Представительства АО «НИАЭП» в Республике Беларусь
|
Оператор
|
Сотрудник бюро пропусков
|
ПО
|
Программное обеспечение
|
ОС
|
Операционная система
|
БД
|
База данных
|
СУБД
|
Система управления базами данных
|
ПДн
|
Персональные данные сотрудника
|
СЗ
|
Служебная записка
|
ТМЦ
|
Товарно-материальные ценности
|
DMZ-зона
|
(«Демилитаризованная зона») – сегмент сети АО «НИАЭП», содержащий общедоступные сервисы
|
ТСД
|
Мобильный переносной терминал сбора данных
|
Программное обеспечение системы учета персонала или ПО Системы учета персонала
|
Лицензионное программное обеспечение «Integra.HR», разработчик ООО «Интегра»
|
Сервер учета персонала
|
Сервер, на котором развернуто программное обеспечение Системы учета персонала
|
ПК
|
Персональный компьютер
|
РФ
|
Российская Федерация
|
Общие сведения.
Наименование разрабатываемого программного обеспечения: «Модуль формирования пропусков» - далее ПО Модуль пропусков.
Разработанный функционал программного обеспечения должен соответствовать требованиям, описанным в п.8 Описание функционала программного обеспечения.
Предусматривается передача исключительных прав на программное обеспечение: «Модуль формирования пропусков», включая:
передачу дистрибутива модуля;
передачу подробной инструкции по установке модуля;
передачу исходного программного кода модуля;
передачу инструкций оператора-администратора.
Разработанное Исполнителем ПО «Модуль формирования пропусков» должно быть способно к правовой охране и государственной регистрации данного программного обеспечения в качестве интеллектуальной собственности Заказчика.
Срок разработки ПО Модуль пропусков, передачи дистрибутива программного обеспечения и передачи исключительного права: не позднее 22.12.2015 г.
Объект использования программного обеспечения.
ПО Модуль пропусков предполагается первоначально для объекта: «Автоматизированная система электронного учета рабочего времени». Инвентарный № А0006853.
Объект находится на бухгалтерском учете Представительства АО «НИАЭП» в Республике Беларусь.
Место поставки программного обеспечения: 231201, Республика Беларусь, Гродненская область, г. Островец, площадка строительства атомной электростанции.
Место установки программного обеспечения: Сервер учета персонала Автоматизированной системы электронного учета рабочего времени.
Однако с момента передачи Заказчику ПО Модуля пропусков по Акту выполненных работ Заказчик в праве тиражировать ПО Модуль пропусков, устанавливать и использовать его в иных обособленных подразделениях и месте нахождения Заказчика, передавать неисключительные и исключительные права третьим лицам, а также осуществлять иные права Заказчика, в качестве правообладателя данного программного обеспечения, предусмотренные заключаемым с Исполнителем договором и действующим законодательством РФ.
-
Наименование Исполнителя и Заказчика
Заказчик: Акционерное общество «НИЖЕГОРОДСКАЯ ИНЖИНИРИНГОВАЯ КОМПАНИЯ «АТОМЭНЕРГОПРОЕКТ» (АО «НИАЭП»), выступающее на территории Республики Беларусь через Представительство АО «НИАЭП» в Республике Беларусь.
Исполнитель: определяется по результатам конкурентной процедуры закупки в соответствии с Единым отраслевым стандартом закупок (положением о закупке) Государственной корпорации по атомной энергии «Росатом».
-
Перечень документов, на основании которых разрабатывается программное обеспечение
Приказ АО «НИАЭП» от 27.01.2015 №40/91-П «Об утверждении плана работ и структуры трудозатрат по проекту «Доработка системы учета персонала на площадке строительства Белорусской АЭС» управления информационных проектов развития»;
Техническое задание на выполнение работ по разработке программного обеспечения «Модуль формирования пропусков».
-
Порядок оформления и предъявления заказчику результатов работ по разработке программного обеспечения
Отчетные документы должны быть переданы Заказчику в бумажном виде в количестве 2 (двух) экземпляров, по одному для Заказчика и Исполнителя, каждый из которых должен содержать на титульной странице подписи лиц, ответственных за утверждение, и фирменные печати организации Исполнителя. А так же в электронном виде (широко используемом редактируемом формате MS Office, Open Office и т.д.) на CD/DVD-диске в количестве 1 (одного) экземпляра.
Отчетные документы должны быть оформлены с учетом требований нормативно-методических документов. Вся документация, разрабатываемая Исполнителем, должна быть на русском языке.
Исполнитель обязан использовать терминологию и формулировки, официально приводимые в текстах российского законодательства и нормативно-методических документах.
Уточнение и согласование отчётных документов с Заказчиком выполняется Исполнителем в ходе непосредственного выполнения работ.
Акт выполненных работ утверждается уполномоченным лицом Представительства АО «НИАЭП» в Республике Беларусь.
Утверждение Заказчиком Акта выполненных работ означает завершение работ.
Назначение программного обеспечения.
Программное обеспечение «Модуль формирования пропусков» предназначено для автоматизации деятельности подачи заявки, согласования и печати определенного вида пропусков специально назначенными работниками субподрядных организаций (участвующих в строительстве АЭС), допущенными к данной программе, с их рабочего места, имеющего доступ к сети Интернет.
Так же данное программное обеспечение включает в себя мобильное приложение для переносного мобильного терминала, с целью обеспечения учета персонала, проходящего через КПП площадки строительства по бумажным пропускам со штрих-кодом.
Задачи создания программного обеспечения «Модуль формирования пропусков»:
Создание отлаженной технологии формирования заявки на различные виды пропусков.
Улучшение согласованности деятельности сотрудников отдела специальной безопасности Представительства АО «НИАЭП» в республике Беларусь и представителей субподрядных организаций проекта сооружения АЭС в ходе процесса получения пропусков на площадку строительства.
Максимально возможное сокращение сроков формирования пропусков.
Создание единой системы учета и контроля пропускного режима на площадке строительства АЭС.
Накопление базы данных выданных пропусков.
Для выполнения перечисленных задач необходимо произвести разработку логики процесса работы и описать виды деятельности процесса формирования пропусков, а также разработать логику работы сотрудников отдела специальной безопасности Представительства АО «НИАЭП» в республике Беларусь и представителей субподрядных организаций проекта сооружения АЭС и внедрить специализированную систему автоматизации процесса формирования пропусков (далее Система), которая позволит:
Гарантировать организацию непрерывного процесса формирования и выдачи пропусков на строительную площадку сотрудниками отдела специальной безопасности;
Накапливать базу данных по выданным пропускам с целью автоматизации процесса повторной выдачи пропусков;
Формировать разовые пропуска на строительную площадку на бумажном носителе со штрихкодом, необходимые для инициализации в Системе учета персонала водителей, товарно-материальных ценностей, а также сотрудников, не имеющих пластиковые пропуска с RFID-меткой.
Обеспечивать контроль и учет персонала на КПП с помощью мобильных переносных терминалов сбора данных с целью обеспечения пропускного режима для сотрудников, имеющих бумажные пропуска со штрихкодом.
Для достижения поставленных целей должны быть решены следующие задачи:
Разработка основного программного функционала «Модуль формирования пропусков», устанавливаемого на Сервер учета персонала;
Интеграция программного функционала «Модуль формирования пропусков» с программным обеспечением Системы учета персонала в части использования информации из баз данных ПО Системы учета персонала;
Разработка мобильного приложения «Модуля формирования пропусков», устанавливаемого на мобильных переносные терминалы сбора данных;
Периодическая синхронизация и обновление баз данных мобильного приложения с базами данных основного функционала «Модуля формирования пропусков» и базами данных ПО Системы учета персонала.
Задачи, решаемые исполнителем.
Программное обеспечение «Модуль формирования пропусков» является программным продуктом, автономно устанавливаемым на ПК (или сервер), позволяющее посредством собственного интерфейса осуществлять:
- регистрацию пользователей и присвоение им учетных записей;
- подачу, обработку и согласование заявки на пропуск;
- хранение, редактирование и просмотр внесенной информации;
- формирование статистики на основе истории пользования и т.д.
Исполнитель должен:
- создать программный продукт, не требующий приобретения специальных лицензий, и не имеющий других ограничений, заложенных разработчиком этого ПО.
- предложить и согласовать с Заказчиком решения по программной реализации всех функциональных модулей и процессов взаимодействия их друг с другом.
- предложить и согласовать с Заказчиком основные решения по настройке интерфейса и порядку доступа пользователей (включая дистанционный удаленный доступ через WEB-интерфейс).
- программно реализовать набор согласованных программных и интерфейсных решений в соответствии с требованиями настоящего Технического задания.
Исполнитель по требованию Заказчика должен предоставить гарантии об отсутствии в разрабатываемом им программном обеспечении недекларированных возможностей (вирусы, «логические бомбы», «трояны» и программные закладки).
Исполнитель по окончанию разработки программного обеспечения «Модуль формирования пропусков» обязан установить его на оборудование (сервер учета персонала и мобильные терминалы сбора данных), входящее в состав Автоматизированной системы электронного учета рабочего времени, и подтвердить работоспособность программного обеспечения, проведя успешные комплексные испытания в условиях, приближенных к промышленной эксплуатации, в составе Автоматизированной системы электронного учета рабочего времени.
Описание функционала программного обеспечения
8.1 Технические требования.
Все компоненты программного обеспечения «Модуль формирования пропусков» должны функционировать без необходимости приобретения Заказчиком дополнительного программного обеспечения третьих лиц и/или Исполнителя.
СУБД: предпочтительно MySQL версии не ниже 5.5.х.
Операционная система: предпочтительно 64-битная Linux Ubuntu версия 12.04.
Web-сервер: предпочтительно Web-server Apache 2.4x.
Web-сервер и СУБД должны устанавливаться на разных серверах (данный вопрос требует дополнительного согласования с Заказчиком).
8.2 Основной функционал программного обеспечения.
Программное обеспечение «Модуль формирования пропусков» должно быть отдельным программным продуктом с независимым функционалом. Архитектура модуля должна обеспечивать функциональное взаимодействие с программным обеспечением Системы учета персонала без применения дополнительных программных средств и адаптеров. Передача и получение данных должны быть в таком объеме, чтобы полностью обеспечивать функциональность ПО «Модуль формирования пропусков» совместно с Системой электронного учета персонала в соответствии с требованиями данного технического задания. Структуру и формат баз данных предоставляет Заказчик.
Виды пропусков, для которых должен быть реализован функционал Модуля:
Временный обезличенный пропуск (RFID-карта стандарта EM-Marine, выдается на срок командировки).
Пропуск на провоз ТМЦ (в бумажном виде со штрих-кодом).
Разовый бумажный пропуск для сотрудника со штрих-кодом. Действует в указанный период времени.
Разовый бумажный пропуск на автотранспорт со штрих-кодом. Действует в указанный период времени.
Функционал ПО «Модуль формирования пропусков» должен состоять из:
Модуля подачи заявки на пропуск (интерфейс в виде «Рабочего стола сотрудника сторонней организации», доступный из сети Интернет).
Модуля обработки заявки на пропуск (интерфейс в виде «Рабочего стола сотрудника БП», доступный из внутренней сети АО «НИАЭП»).
Мобильного приложения для переносного мобильного терминала, позволяющего после считывания штрих-кода или RFID-карты стандарта EM-Marine просматривать информацию о составе согласованной заявки на пропуск. В целях увеличения быстродействия по обмену информацией с сервером на мобильных считывателях требуется установка собственной базы данных, которая должна синхронизироваться с БД центрального сервера каждые 15 мин. Синхронизация и обмен данными должны происходить по GSM/GPRS каналу связи, встроенному в переносной мобильный терминал.
Описание процесса получения доступа в Модуль подачи заявки на пропуск:
Доступ должен быть авторизованный, то есть должен происходить после ввода логина и пароля (требование к паролю: минимальная длина пароля составляет 8 символов, максимальная длина 16 символов.
Пароль может содержать только символы:
• латинские и русские заглавные буквы (A – Z, А - Я);
• латинские и русские строчные буквы (a – z, а - я);
• цифры (0 - 9) или символы специальных знаков (например,!, $, #, %). В пароле должен присутствовать хотя бы один символ из каждой вышеперечисленной категории символов. Пароль не должен повторять последние ранее использовавшиеся 24 пароля.
Описание требуемого алгоритма формирования пропусков в соответствии с видом пропуска:
Заявка на пропуск:
|
Формируется Заявителем через Интернет в Модуле подачи заявки на пропуск.
В соответствии с видом пропуска указывается тип заявки.
В заявку заносятся необходимые данные и прикрепляются необходимые сканированные документы. Перечень данных, указываемых в заявке, окончательно уточняется у Заказчика. Заказчик уточняет состав реализуемых справочников для хранения данных.
Статусы заявки (необходимо предусмотреть цветовой индикатор статуса заявок):
- черный цвет: «новая» - Заявка занесена в систему;
- желтый цвет: «на согласовании» - Заявка направлена на согласование ЛПР;
- синий цвет: «на рассмотрении» - Заявка направлена Оператору;
- зеленый цвет: «согласована» - Заявка согласована Оператором;
- красный цвет: «отклонена» - Заявка отклонена Оператором.
Смена статусов происходит автоматически, после соответствующих действий оператора в системе.
После окончательного формирования заявки и нажатия кнопки «оформить пропуск», заявка направляется на согласование ЛПР (согласно справочнику «Организация - ЛПР»), ей присваивается статус «на согласовании». После согласования, заявка удаляется из Модуля подачи заявки и перемещается в Модуль обработки заявки.
|
Согласование заявки ЛПР:
|
После направления заявки на согласование, сервер должен прислать запрос на электронный адрес ЛПР (электронный адрес указывается справочнике «Организация - ЛПР»):
«Подтвердите согласование заявки …. ». Рядом с текстом в данном электронном сообщении должна быть ссылка для подтверждения согласования, и ссылка для отказа в согласовании с последующим вводом комментария о причине отказа.
При согласовании заявки, ЛПР переходит по ссылке «Согласовать» и заявка уходит на рассмотрение Оператору, заявке присваивается статус «на рассмотрении».
При отклонении заявки, ЛПР переходит по ссылке «Отказать» и заявка удаляется.
|
Рассмотрение заявки Оператором:
|
Рассмотрение заявки проводит Оператор в Модуле обработки заявки на пропуск.
В случае согласования заявки на временный пропуск, Оператор в ПО «Системы учета персонала» привязывает одну из свободных RFID-карт к этому Сотруднику. Согласование дублируется на электронную почту Заявителя.
В случае согласования заявки на разовый бумажный пропуск, пропуск на автотранспорт или пропуск на ТМЦ, автоматически генерируется пропуск со штрих-кодом в файл и отправляется Заявителю по электронной почте.
В обоих случаях заявке присваивается статус «согласована».
При отклонении заявки, ей присваивается статус «отклонена» и сообщением дублируется на электронную почту Заявителя с указанием причины отказа.
|
Печать или Выдача пропуска:
|
- Разовый бумажный пропуск, пропуск на автотранспорт или пропуск на ТМЦ распечатывается Заявителем на бумаге собственными силами. Распечатанный пропуск содержит уникальный штрих-код. Распечатанный пропуск не требует подписи и печати Отдела СБ. Распечатанный разовый пропуск со штрих-кодом действует только при предъявлении паспорта и только в указанный период времени.
- Выдача обезличенной RFID-карты с бумажным вкладышем (на вкладыше предусмотреть нанесение ФИО и паспортных данных сотрудника и времени посещения объектов стройплощадки) осуществляется в бюро пропусков по предъявлению паспорта.
|
Проход через КПП:
|
Временный пропуск (обезличенная RFID-карта с бумажным вкладышем):
Сотрудник прикладывает пропуск к считывателям турникета, турникет открывается.
Разовый бумажный пропуск:
Предъявляется охраннику. Охранник сканирует штрих-код с помощью мобильного считывателя и сверяет информацию с экрана мобильного считывателя с паспортными данными и/или данными о грузе. Факт прохода/проезда фиксируется в системе ПО СУП Multi-D в режиме онлайн после передачи информации со считывателя в систему.
В обоих случаях в программном обеспечении фиксируются все проходы/проезды по аналогии с именным пропуском с указанием всех необходимых данных, связанных с картой.
|
Сдача пропуска:
|
Сдача RFID-карты происходит в бюро пропусков. Оператор отвязывает RFID-карту от Сотрудника.
Сдача бумажного пропуска на сотрудника или водителя происходит на КПП при выходе/выезде с охраняемой территории.
Сдача бумажного пропуска на ТМЦ осуществляется сразу после проверки на КПП.
|
8.3 Требования к интерфейсу.
Доступ к модулю пропусков конечного пользователя должен осуществляться посредством WEB-браузера;
Модуль пропусков должен корректно работать под управлением следующих WEB-браузеров: MS Internet Explorer 6 и выше, Mozilla FireFox 3.6 и выше;
Пользовательский интерфейс должен в нормальном режиме обеспечивать отображение информации на пользовательских экранах разрешением 1024х768 пикселей и выше;
Интерфейс должен быть упрощен. Из меню должны быть исключены не использующиеся строки, из окон программы, деактивированы и скрыты не использующиеся поля ввода.
-
Характеристика объекта автоматизации
В настоящее время в отделе собственной безопасности Представительства АО «НИАЭП» в Республике Беларусь для выдачи пропусков требуется личное присутствие сотрудников с пакетом разрешительных документов на бумажном носителе. На процесс формирования и выдачи пропуска в большинстве случаев оказывает влияние время передачи бумажного носителя, очередь его рассмотрения и удаленная от рабочего места работа лиц, принимающих решения.
Программный продукт «Модуль формирования пропусков» должен позволить автоматизировать данный процесс и сократить время подготовки принятия решения и доведения его до исполнителя.
Исполнитель производит все работы по установке и настройке, как серверной части программного обеспечения, так и программного обеспечения, находящегося на терминалах сбора данных. Также Исполнитель проводит работы по синхронизации баз данных «Модуля формирования пропусков» с базами данных ПО Системы учета персонала и базами данных мобильного приложения установленного на ТСД.
Указанная архитектура (рис.1) описывает реализацию единой сетевой развертки всего программного обеспечения, участвующего в процессе.
Рисунок 1. Архитектура системы
Требования к системе в целом.
9.1 Требования к режимам функционирования системы:
Система должна функционировать непрерывно круглосуточно. Под непрерывным режимом работы Системы понимается режим работы, при котором Система постоянно находится во включенном состоянии за исключением времени, необходимого для ее планового и внепланового технического обслуживания.
Система должна поддерживать многопользовательский режим работы.
Принцип построения Системы должен предусматривать возможности для развития и модернизации Системы.
9.2 Требования к численности и квалификации пользователей системы и режиму их работы:
9.2.1 Требования к численности пользователей Системы:
Численность пользователей Системы должна определяться с учетом следующих требований:
быть достаточной для реализации автоматизированных функций Системы во всех режимах ее работы;
быть достаточной для обеспечения бесперебойного функционирования Системы.
структура и конфигурация системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала;
структура Системы должна предоставлять возможность управления всем доступным функционалом системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами.
9.2.2 Требования к квалификации пользователей, порядку их подготовки и контроля знаний и навыков:
Квалификация персонала должна обеспечивать качественное и эффективное функционирование программных средств Системы во всех режимах работы.
Для администрирования Системы к администратору не должны предъявляться требования по знанию всех особенностей функционирования элементов, входящих в состав администрируемых компонентов Системы.
9.2.3 Требуемый режим работы персонала автоматизированной системы:
Аппаратно-программный комплекс Системы не должен требовать круглосуточного обслуживания и присутствия администраторов у консоли управления.
9.3.1 Степень приспособляемости Системы к изменению процессов и методов управления, к отклонениям параметров объекта управления:
Система должна предусматривать возможность масштабирования по производительности и объему обрабатываемой информации без модификации ее программного обеспечения путем модернизации используемого комплекса технических средств. Возможности масштабирования должны обеспечиваться средствами используемого базового программного обеспечения.
9.3.2 Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы:
Аппаратно-программный комплекс Системы должен обеспечивать:
полноту покрытия функциональных требований к Системе;
отсутствие повторного ввода информации, если это не противоречит требованиям проверки достоверности информации;
механизмы проверки информации, вводимой в Систему, на корректность, полноту и соответствие основным справочникам;
одновременную работу всех подключенных к Системе пользователей (многопользовательский режим работы), в т.ч. территориально удаленных друг от друга;
отклик Системы на действия пользователя при работе с элементами интерфейса (например, открытие/закрытие экранной формы, переключение на другую вкладку, выбор информации с помощью элементов форм, нажатие на кнопку и пр.) не более 3 сек.
Продуктивное использование Системы не менее пяти лет с момента ввода в эксплуатацию без необходимости перехода на новую версию.
9.4 Требования к надежности
9.4.1 Состав и количественные значения показателей надежности для системы в целом или ее подсистем:
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла Системы;
при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции системы возлагается на ОС;
при ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
9.5 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы:
Система должна быть рассчитана на эксплуатацию в составе программно–технического комплекса Заказчика и учитывать разделение ИТ инфраструктуры Заказчика на внутреннюю и внешнюю. Техническая и физическая защита аппаратных компонентов системы, носителей данных, бесперебойное энергоснабжение, резервирование ресурсов, текущее обслуживание реализуется техническими и организационными средствами, предусмотренными в ИТ инфраструктуре Заказчика.
Все обновления системы, касающиеся как программного обеспечения, так и базы данных должны предоставляться Исполнителем в удобном для Заказчика формате с подробной инструкцией по самостоятельной установке.
9.6 Требования к защите информации от несанкционированного доступа:
В Системе должна быть обеспечена защита информации (хранимой, отображаемой, передаваемой) от всех следующих видов угроз:
нарушение конфиденциальности;
нарушение целостности;
нарушение доступности.
Система должна обеспечивать информационную безопасность как от непреднамеренных или случайных действий, так и от преднамеренных угроз – несанкционированное получение информации и несанкционированная манипуляция данными, ресурсами и самой Системой.
Информационная безопасность должна строиться на основании применения:
на автоматизированных рабочих местах (включая переносные мобильные терминалы) и серверах, обеспечивающих функционирование Системы:
авторизацию пользователей по логину и паролю;
разграничение прав на основании ролей и полномочий;
средств защиты от несанкционированного доступа;
средств антивирусной защиты;
средств резервного копирования и аварийного восстановления информации.
В Системе должно быть предусмотрено логирование действий пользователей и администраторов, контроль несанкционированного доступа и действий пользователей, администраторов и посторонних лиц, в т.ч. регистрация входа (выхода) в систему (из системы). Защита Системы от несанкционированного доступа обеспечивается средствами внутренней сети АО «НИАЭП».
Система должна соответствовать требованиям Федерального закона РФ от 27.07.2006 №152-ФЗ «О персональных данных».
9.7 Требования по сохранности информации при авариях
Сохранность информации в Системе должна быть обеспечена за счет:
исключения несанкционированного доступа к данным;
организации бесперебойного электропитания серверов;
создания резервных копий хранилищ данных;
восстановления данных из резервных копий в случаях сбоев.
Резервное копирование должно осуществляться средствами СУБД, под управлением которых размещаются хранилища данных подсистемы.
Программное обеспечение Системы должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств.
9.8 Требования к администрированию системы.
Система не должна администрироваться посредством удаленного доступа из недоверенных сетей. Система должна администрироваться только из доверенной корпоративной локальной сети (с рабочего места сотрудника специальной безопасности).
Система не должна связываться в автоматическом режиме с серверами производителя программного продукта, Исполнителя работ, а также передавать данные через другие продукты и процессы.
В системе должна быть настроена бизнес-логика, соответствующая имеющимся процессам компании.
11. Требования к видам обеспечения.
Требования к системам управления базами данных
Хранение, обработка и доступ к базам данных в хранилище бизнес-информации должны быть организованы на платформе современной СУБД, обладающей масштабируемой архитектурой, которая позволяла бы осуществить развертывание Системы и ее бесперебойное функционирование независимо от объемов хранимых и обрабатываемых данных.
Требования к техническому обеспечению:
Техническое обеспечение Системы должно максимально и наиболее эффективным образом использовать существующие у Заказчика технические средства.
Требования к организационному обеспечению:
Система должна обеспечивать автоматическую проверку на предмет ошибочности действий персонала и запрет на выполнение таких действий, в т.ч.:
попытка внесения данных несоответствующего типа;
попытка изменения расчетных или не редактируемых полей и пр.
12. Порядок приемки и контроля результатов работ
Перечень документов, по ГОСТ 34.201-89, предъявляемых по окончании соответствующих стадий и этапов работ:
1. Рабочий проект системы, включающий в себя:
- Общее описание Системы;
- Описание принятых решений по настройкам и параметрам конфигурации;
- Описание автоматизированных функций Системы;
- Описание программного обеспечение Системы (описание открытых интерфейсных модулей);
2. Программа и методика предварительных испытаний (в соответствии с разделами Рабочего проекта);
3. Протокол испытаний Системы;
4. Файлы исходных программных кодов;
5. Паспорт системы;
6. Руководство администрирования исходного кода;
7. Рабочие (ролевые) инструкции в составе:
- инструкция Администратора Системы;
- инструкция Пользователя Системы.
Объем и последовательность проведения испытаний должны быть согласованы с Заказчиком. Испытания проводятся с целью определения готовности Системы к вводу в эксплуатацию. В ходе испытаний оценивается соответствие разработанной Системы требованиям настоящего Технического задания и ее работоспособность. Для проведения испытаний Исполнителем должна быть подготовлена Программа и методика проведения испытаний (ПМИ), утверждаемая Заказчиком. Результаты испытаний должны оформляться протоколом испытаний. В протоколах отражаются результаты проведенных проверок по каждому пункту программы, выводы и рекомендации по ним. Испытания Системы должны производиться на территории Заказчика на развернутых и настроенных программно-технических средствах Системы. Для проведения испытаний Заказчик назначает приемочную комиссию. Приемочная комиссия осуществляет приемку работ в соответствии с требованиями Технического задания. По результатам сдачи-приемки работ оформляется акт сдачи-приемки работ, который подписывается уполномоченным представителем Заказчика, Исполнителем.
Создаваемый в рамках настоящей работы программный продукт передаётся Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе.
Исключительные права на результаты работ по настоящему Техническому заданию принадлежат Заказчику с момента подписания акта сдачи-приемки выполненных работ.
|
