Техническое задание на выполнение работ по теме: «Автоматизация процессов присвоения кодов информационной модели АЭС»

Согласовано

Наименование подразделения	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата
АО «НИАЭП», Московский филиал	Заместитель директора
АО «НИАЭП»	Заместитель директора по управлению качеством - начальник управления качества и контроля безопасности
АО «НИАЭП», ОИМ АЭС БКП-1	Начальник отдела
АО «НИАЭП», ОСАПР	Начальник отдела
АО «НИАЭП», ОИТ	Начальник отдела
АО «НИАЭП», ОУК	Начальник отдела

Разработано

Наименование подразделения	Должность исполнителя	Фамилия, имя, отчество	Подпись	Дата
АО «НИАЭП», ОРСК	Начальник группы
АО «НИАЭП», ОУК	Начальник группы
АО «НИАЭП», ОУК	Ведущий инженер

СОДЕРЖАНИЕ

Наименование раздела	№ стр.
1 Наименование работ	5
2 Сроки выполнения работ	5
3 Исполнители	5
4 Заказчик	5
5 Цель выполнения работ	5
6 Задачи, решаемые Исполнителем	5
7 Основные требования к работе по доработке программных модулей и инструментов	7
7.1 Общие требования к системе	7
7.2 Механизм присвоения кодов системной нумерации функциональных систем	8
7.3 Механизм присвоения кодов документу	9
7.4 Рабочий стол	11
7.4.1 Рабочий стол специалиста ГКК ОУК	11
7.4.2 Рабочий стол Разработчика документации	11
8 Результаты работ, передаваемые по окончании работ Заказчику	11
9 Порядок приема и сдачи работ	12
Приложение 1 – Блок схема процессов присвоения системной нумерации функциональных систем	13
Приложение 2 – Блок схема процессов присвоения кодов документу	14

НАИМЕНОВАНИЕ РАБОТ

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

СРОКИ ВЫПОЛНЕНИЯ РАБОТ

Начало: с момента заключения договора.

Окончание: в соответствии с Календарным планом (Приложение к Договору).

ИСПОЛНИТЕЛИ

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

ЗАКАЗЧИК

АО «НИАЭП».

ЦЕЛЬ ВЫПОЛНЕНИЯ РАБОТ

Целью выполнения работ является повышение эффективности проектной деятельности за счет автоматизации процессов:

присвоения кодов проектной, рабочей и технической документации на основании СТО СМК-ПКФ-018-4.1-11; присвоения системной нумерации функциональных систем на основании соглашения по применению системы кодирования KKS; автоматическое формирование отчетов по различным критериям; хранение истории по различным объектам, находящимся в системе, в том числе по регистрации Пользователя, истории изменения, создания и удаления объектов.

ЗАДАЧИ, РЕШАЕМЫЕ ИСПОЛНИТЕЛЕМ

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

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

Исполнитель в процессе выполнения технического задания должен разработать:

механизм присвоения системной нумерации функциональных систем; механизм присвоения кодов проектной и рабочей документации; рабочий стол Разработчика документации и специалиста ГКК ОУК.

Общие требования по безопасности информации

Разработанная система должна быть протестирована Исполнителем на предмет совместимости с ПО контроля безопасности и обеспечения целостности данных
АО «НИАЭП».

Исполнитель по требованию Заказчика должен предоставить гарантии об отсутствии в разрабатываемом им программном обеспечении недекларированных возможностей (вирусы, «логические бомбы», «трояны» и программные закладки).

ОСНОВНЫЕ ТРЕБОВАНИЯ  ПО РАЗРАБОТКЕ ПРОГРАММНЫХ МОДУЛЕЙ И ИНСТРУМЕНТОВ

7.1 Общие требования к системе

При разработке системы необходимо предусмотреть:

открытость системы для обеспечения возможности дальнейшего обмена данными с другими системами; идентификацию в системе в соответствии с требованиями учетной политики АО «НИАЭП»; совместимость с клиентским ПО Internet Explorer 8.0 и Java 6.23 (и выше);

фильтрация по каждому доступному столбцу (полю) с возможностью применения спецсимволов, заменяющих знак, либо откидывающих значения до/после символа; ролевой доступ в систему с возможность настройки ролевой политики Администратором системы; интерфейсно настраиваемая система отчетности, путем вывода всех доступных атрибутов и указания атрибутов, которые необходимо вывести в Excel; дублирование строки заявки для создания на ее основе новой строки; жизненный цикл заявки по статусам: «Выполнена»; «Отклонена»;

Предусмотреть обязательное поле для ввода комментария о причине отклонения в случае перевода заявки в статус «Отклонена»;

оповещение пользователей по e-mail о переходе заявки из одного жизненного цикла в другой.

При создании заявки предусмотреть оповещение на e-mail специалиста ГКК ОУК, при переходе в статус «Выполнена» или «Отклонена» на e-mail Разработчика документации, создавшего заявку.

создание групп Пользователей: Разработчик документации, специалист ГКК ОУК;

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

предложение системой вариантов заполнения поля (из заранее сформированных значений) при наборе значений в поле с типом данных «список».

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

       7.2 Механизм присвоения кодов системной нумерации функциональных систем

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

Таблица 1

№	Наименование	Тип поля данных	Размер поля данных
1	Разработчик	Список
2	Наименование проекта	Список
3	Функциональная система	Список
4	Номер системной нумерации	Текст с ограничением по допускаемым символам	50 символов
5	Примечание	Текст	1000 символов

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

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

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

Необходимо предусмотреть возможность добавления значений в списковые атрибуты, как через интерфейс системы, так и с использование формата *.xls и *.xlsx.

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

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

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

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

Основные операции процесса присвоения системной нумерации приведены в Приложении 1.

7.3 Механизм присвоения кодов документу

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

Таблица 2

№	Наименование	Тип поля данных	Размер поля данных
1	Номер заявки	Число, заполняется автоматически
2	Разработчик	Список
3	Наименование проекта	Список
4	Стадия документа или ИТТ	Список
5	Здание или функциональная система	Список
6	Системная нумерация	Список
7	Агрегат	Список
8	№ агрегата	Число	3 символа
9	Часть агрегата	Список
10	№ части агрегата	Число	2 символа
11	Техническая специальность	Список
12	Тип документа	Список
13	Название	Текст	500 символов
14	Примечание	Текст	1000 символов

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

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

Необходимо предусмотреть автоматический механизм доступа к заполнению ячеек (автоматическому заполнению ячеек) в зависимости от значения атрибута «Стадия документации или ИТТ».

Подготовительный период

Атрибут 5 автоматически принимает значение «Общестанционный».

Атрибуты 6-10 не доступны для заполнения.

Остальные атрибуты доступны для заполнения.

Проектная документация

Атрибут 5 доступен для выбора из списка зданий, сооружений и систем преднастроенного списка в зависимости от Проекта.

Поле 6 активно в случае одновременного заполнения атрибута 5 и установки в атрибуте 12 значения «План на отметке». Поле 11 – выбор специальности из справочника. Поле 12 – Типы документов из списка. Поля 13, 14 заполняются вручную.

Атрибуты 7-10 не доступны для заполнения.

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

Рабочая документация

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

Новое ИТТ

Поле 5 может принимать значение из перечня функциональных систем данного проекта либо значение «общестанционный». Поле 6 заполняется из списка доступных функциональных потоков для выбранной системы. Поля 7,9 выбираются из справочника агрегатов и частей агрегатов. Поле 12 не активно.

Для значения поля 4 «новое ИТТ» будет создаваться необходимый набор обязательных документов ИТТ (титульный блок, ведомость комплекта, общие технические требования, лист регистрации изменений). Для дополнения ИТТ опросными листами или другими прилагаемыми документами необходимо предусмотреть кнопку «добавить в ИТТ», которая появляется только при выборе в поле 4 значения «новое ИТТ» При нажатии этой кнопки появляется дополнительная строка с такими же позициями как рассмотрено выше, за исключением: вместо поля 4 «стадия документации» появляется поле «ИТТ», которое принимает значение из списка всех существующих ИТТ или значение «текущее ИТТ». Поле 11 не активно для заполнения и принимает значение в зависимости от значения поля «ИТТ». Поле 12 выбирается из справочника возможных типов документа ИТТ.

Поле 1 «№ заявки» заполняется автоматически при создании заявки, путем сквозной нумерации. После нажатия Разработчиком документации кнопки «Завершить» номер заявки сохраняется в БД. В случае отмены создания заявки номер не записывается в БД и доступен при создании следующей заявки.

Основные операции процесса присвоения кодов документу приведены в Приложении 2.

7.4 Рабочий стол

Для разделения потока заявок необходимо разработать рабочие столы эксперта ОУК и Разработчика документации.

7.4.1 Рабочий стол специалиста ГКК ОУК

Рабочий стол специалиста ГКК ОУК должен представлять собой интерфейс работы в системе, в котором отображаются созданные заявки. Специалист ГКК ОУК должен иметь возможность перевести заявку в статус «Выполнена». После чего поданная заявка блокируется и не может быть удалена Разработчиком документации.

7.4.2 Рабочий стол Разработчика документации

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

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

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

РЕЗУЛЬТАТЫ РАБОТ, ПЕРЕДАВАЕМЫЕ ПО ОКОНЧАНИИ РАБОТ ЗАКАЗЧИКУ

Исполнитель проводит работы на собственных серверах с установленным ПО.

По завершению работ Заказчику передается следующая отчетная документация и материалы в составе:

Руководство пользователя специалиста ОУК; руководство пользователя Разработчика документации; руководство администратора; руководство по установке ПО; протоколы испытаний разработанных функциональных инструментов; программа и методика испытаний разработанных инструментов;

файлы исходного кода.

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

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

В процессе работ должны быть соблюдены общие требования, предписываемые ГОСТ 2.105-95 «ЕСКД. Общие требования к текстовым документам»; ГОСТ 8.417-2002

«ГСИ. Единицы величин»; ГОСТ Р 21.1101-2009 «СПДС. Основные требования к проектной и рабочей документации»; ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

ПОРЯДОК ПРИЕМА И СДАЧИ РАБОТ

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

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

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

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