Технические требования к системе Уфа 2016 Автоматизированная система расчета плановых уровней добычи

Технические требования к системе
Автоматизированная система расчета плановых уровней добычи
нефти, жидкости и закачки рабочего агента
Уфа 2016
Содержание
1
Общие положения .......................................................................................... 3
1.1 Общие сведения о Системе ........................................................................ 3
1.2 Требования к системе в целом ................................................................... 4
1.3 Требования по взаимосвязям системы с внешними и со
смежными системами, обеспечению ее совместимости ......................... 4
1.4 Требование к реализации расчетного модуля .......................................... 5
1.5 Перечень документов, на основании которых создается Система ........ 5
1.6 Список используемых сокращений........................................................... 5
2
Требования к персоналу ............................................................................... 7
2.1 Требования к структуре и численности персонала ................................. 7
2.2 Требования к квалификации, порядку подготовки и контролю
знаний персонала ........................................................................................ 7
2.2.1
Требования к квалификации, порядку подготовки и
контролю знаний конечных пользователей ..................................... 7
2.2.2
Требования
к квалификации,
порядку
подготовки
администратора Системы................................................................... 7
2.2.3
Требования
к квалификации,
порядку
подготовки
администратора технической инфраструктуры ............................... 8
3
Требования к документации ...................................................................... 10
4
Требования к техническому обеспечению .............................................. 11
4.1 Общие требования к технической архитектуре системы ..................... 11
4.2 Схема архитектуры серверов Системы .................................................. 11
4.3 Требования к техническим характеристикам серверов ........................ 14
4.4 Требования к персональным компьютерам ........................................... 14
4.5 Требования к архитектуре вычислительных сетей и окружению
системы ...................................................................................................... 14
4.6 Требования к системе резервного копирования .................................... 14
4.7 Требования к мощности и доступности Системы ................................. 15
4.8 Требования к защите информации и шифрованиюError! Bookmark not define
2
1
Общие положения
1.1 Общие сведения о Системе
Таблица 1 – Общие сведения о Системе
Параметр
Полное наименование
Системы
Условное
Системы
ИС
Заказчик
обозначение
Значение
Автоматизированная система расчета плановых
уровней добычи нефти, жидкости и закачки
рабочего агента в пласт
Система
Информационные системы блока РиД
ПАО АНК «Башнефть»
Система должна быть реализована в виде веб-приложения с
многопользовательским режимом доступа. Интерфейс согласовывается с
Заказчиком в процессе реализации модуля.
Система
включает
в
себя
следующие
функциональные
и
технологические подсистемы:
1) Функциональные подсистемы:
 Сбор данных:

Автоматизированная подгрузка исходных данных из
ИС , эксплуатируемых в блоке РиД
 Ручной ввод недостающих исходных данных;
 Модуль работы со сценариями расчета;
 Модуль расчета прогнозных показателей по добыче нефти,
жидкости, закачке рабочего агента в пласт
 Формирование отчетности;
 Формирование факторного анализа на основе результатов
выполения Расчета;
 Модуль интеграции - выгрузка отчетности в ИС Заказчика
2) Технологические подсистемы:
 Обмен данными;
 Формирование отчетов;
3
 Расчет и прогнозирование;
 Хранение и обработка данных;
 Администрирование и информационная безопасность.
1.2 Требования к системе в целом
Система должна обеспечивать:
- одновременную
пользователей;
работу
с
системой
 ручной ввод недостающих
неограниченного
количества
исходных данных для выполнения
Расчета;
 автоматическую загрузку исходных данных, для которых у
Заказчика имеются цифровые источники данных, поддерживающие
интеграцию;
 выполнение Расчета за заданный пользователем произвольный
период;
 централизованное хранение исходных данных и результатов
Расчета;
 централизованное хранение истории изменения исходных данных и
выполнения Расчетов;
 Возможность увеличения количества одновременно работающих
пользователей
на
различных
уровнях
иерархии
объекта
автоматизации.
1.3 Требования по взаимосвязям Системы с внешними и со
смежными системами, обеспечению ее совместимости
В рамках работ по развитию Системы может быть обеспечена
возможность интеграции через принятые в компании стандартные
интерфейсы: ODBC или SAP PI (для получения исходных данных для
выполнения расчета и выгрузка результатов расчетов) со следующими
внешними источниками данных:

OilInfoSystem;
4

SAP;
 автоматизированная
система
оценки
эффективности
разработки
месторождений. (Prognoz Platform);
 другие ИС блока РиД, выявленные на этапе формирования ТЗ на
разработку и внедрение Системы.
Excel-шаблоны для недостающих исходных данных расчета (формат должен
быть уточнен при формировании ТЗ)
1.4 Требование к реализации расчетного модуля
Расчетный модуль реализуется по алгоритмам, установленным
Заказчиком и утвержденным техническим заданием к Системе. Изменение
алгоритмов допускается только по согласованию с Заказчиком в процессе
реализации модуля.
1.5 Перечень документов, на основании которых создается
Система
Система разрабатывается на основании следующих документов:
 Техническое задание на создание ИС «Автоматизированная система
расчета плановых уровней добычи нефти, жидкости и закачки
рабочего агента в пласт».
1.6 Список используемых сокращений
HTTP
–
(HyperText
Transfer
Protocol)
Протокол
прикладного
уровня
передачи
данных,
использующийся также в качестве «транспорта»
для других протоколов прикладного уровня
ODBC
–
(Open Database Connectivity) Программный
интерфейс (API) доступа к базам данных
RDP
–
(Remote Desktop Protocol) Протокол удалённого
рабочего стола
ДО
–
Дочерние
и
зависимые
общества
5
ПАО АНК «Башнефть»
ЛВС
–
Локальная вычислительная сеть
НСД
–
Несанкционированный доступ
ПАО
АНК «Башнефть»
–
Публичное акционерное общество «Акционерная
нефтяная Компания «Башнефть»
–
Автоматизированная система расчета плановых
уровней добычи нефти, жидкости и закачки
рабочего агента в пласт
Система
OCI
–
ТИ
КСПД
–
–
Oracle Call Interface – программный интерфейс в
Oracle.
Техническая инфраструктура
Корпоративная сеть передачи данных
6
2
Требования к персоналу
2.1 Требования к структуре и численности персонала
Персонал Системы должен подразделяться на следующие группы:
1) Пользователи Системы (специалисты ПАО АНК «Башнефть» и
специалисты дочерних и зависимых обществ (далее – ДЗО));
2) Администраторы Системы;
3) Администраторы
технической
инфраструктуры
(далее
–
администраторы ТИ).
Совокупность
выполняемых
задач
и
ответственность
должна
определяться ролью, установленной для конечного пользователя или
администратора.
2.2 Требования к квалификации, порядку подготовки и контролю
знаний персонала
2.2.1 Требования к квалификации, порядку
контролю знаний конечных пользователей
подготовки
и
Для успешной работы с Системой пользователям необходимо владеть
базовыми навыками работы с web-приложениями.
Пользователям необходимо обладать знаниями и навыками работы в
качестве Пользователя персональных компьютеров и пройти обучение по
работе с Системой.
При
развитии
и
модернизации
функциональности
Системы
предусматривается повышение квалификации пользователей в очной форме с
помощью проведения семинаров или заочной форме с помощью руководства
пользователя.
2.2.2 Требования
к
квалификации,
администратора Системы
порядку
подготовки
Администратор Системы должен выполнять следующие функции:
1)
Создание, удаление пользователей;
2)
Конфигурирование набора прав ролей пользователей;
7
3)
Управление реестром пользователей, в том числе: отмена роли,
переназначение роли, присвоение роли;
4)
Управление правами доступа пользователей;
5)
Просмотр журнала аудита действий пользователей;
6)
Ведение нормативно-справочной информации;
7)
Настройка форм сбора и обработки данных, форм аналитической и
оперативной отчетности, и аналитических панелей;
8)
Контроль операций резервного копирования данных Системы и
восстановление Системы;
9) Обновление Системы;
10) Администрирование БД Системы.
Недопустимо
привлечение
к
обслуживанию
и
эксплуатации
администратора Системы, не имеющего необходимой подготовки и
квалификации, подтвержденной по результатам обучения работе с Системой
и/или другими квалификационными документами.
В процессе внедрения Системы подрядчик/исполнитель работ по
внедрению должен провести обучение администраторов Системы.
2.2.3 Требования
к
квалификации,
порядку
администратора технической инфраструктуры
подготовки
Администратор ТИ должен выполнять следующие функции:
1) Системно-техническое
обслуживание
комплекса
технических
средств;
2) Системное
обслуживание
общесистемного
программного
обеспечения (операционная система, драйверы, системные утилиты,
телекоммуникационные
программы,
программное
обеспечение
резервного копирования);
3) Мониторинг и контроль состояния комплекса технических средств,
общесистемного программного обеспечения;
4) Администрирование общесистемного программного обеспечения;
8
5) Администрирование СУБД Oracle, в случае использования его в
качестве СУБД, или какой-то иной СУБД.;
6) Проведение операций резервного копирования и восстановления
общесистемного программного обеспечения.
Уровень квалификации администраторов ТИ должен соответствовать
требованиям эксплуатационной документации.
В
процессе
внедрения
подрядчик
не
проводит
обучение
администраторов ТИ.
9
3
Требования к документации
В ходе выполнения работ по разработке Системы должны быть
разработаны следующие документы:
 Техническое задание (далее – ТЗ);
 Устав проекта;
 Технические требования к Системе (настоящий документ);
 Альбом форм (Приложение А к ТЗ);
 Программа и методика испытания;
 Руководство пользователя Системы;
 Инструкция администратора Системы;
 План ликвидации аварийных ситуаций;
 Описание ролей и полномочий пользователей Системы;
 Инструкции по регламентному обслуживанию Системы;
 Инструкция по установке клиентской части Системы;
 План поддержки и сопровождения Системы;
 Карточка услуги;
 Протокол обучения пользователей и администраторов;
 Отчет о проведении опытно-промышленной эксплуатации;
 Журнал
устранения
замечаний
по
результатам
опытной
эксплуатации;
 Протокол проведения приемо-сдаточных испытаний;
 Акт приемки Системы в промышленную эксплуатацию.
10
4
Требования к техническому обеспечению
4.1 Общие требования к технической архитектуре системы
Система должна функционировать на технических средствах и
программно-аппаратных платформах, предоставляемых Заказчиком.
Должно быть обеспечено резервирование оборудования с хранимой на
нем
исторической
архивной
информацией
для
гарантированного
продолжения работы в случае его отказа.
4.2 Схема архитектуры серверов Системы
Архитектура Системы должна включать в себя следующие уровни
(Рисунок 1):
 Презентационный уровень – реализует пользовательский интерфейс
для работы с персональными компьютерами и предоставляет доступ
пользователям к функциональности Системы. Доступ пользователей
к функциональности осуществляется через тонкий клиент. Данный
уровень
предполагается
для
доступа
с
рабочих
станций
пользователей;
 Уровень взаимодействия – на данном уровне находятся модули,
которые
взаимодействуют
с
внешней
средой
Системы,
взаимодействие может осуществляться по протоколу TCP напрямую
или по протоколу HTTP через веб-сервер (сервер приложений);
 Уровень данных – представляет собой реляционную СУБД для
надежного хранения и управления данными Системы. На этом
уровне хранятся данные, используемые экземпляром программного
комплекса. К общим данным относятся таблицы оборудования,
пользователей, системных настроек.
В части размещения технических средств Системы должен быть
предусмотрен двухсистемный ландшафт, включающий зону промышленной
эксплуатации Системы и зону тестирования Системы.
11
Зона промышленной эксплуатации Системы должна быть представлена
виртуальным сервером постоянной эксплуатации, который включает в себя
сервер БД и сервер приложений.
Зона тестирования Системы должна быть представлена виртуальным
тестовым сервером, который включает в себя сервер БД и сервер
приложений.
Информационное взаимодействие между серверами приложений зоны
промышленной эксплуатации/зоны тестирования и клиентской станцией
пользователя
Системы
должно
осуществляться
через
КСПД
по
HTTP/HTTPS протоколу.
Информационное
взаимодействие
между
серверами
БД
зоны
промышленной эксплуатации/зоны тестирования и клиентской станцией
пользователя
Системы
должно
осуществляться
через
КСПД
по
OCIпротоколу.
Информационное
взаимодействие
между
серверами
зоны
промышленной эксплуатации/зоны тестирования и клиентской станцией
администратора должно осуществляться с помощью удаленного рабочего
стола через ЛВС по RDP протоколу.
Информационное взаимодействие между серверами зоны тестирования
и клиентской станцией подрядчика-разработчика должно осуществляться с
помощью удаленного рабочего стола,опубликованного в инфраструктуре
Citrix.
Информационное взаимодействие между сервером БД и сервером
приложений в рамках виртуального сервера должно осуществляться по
протоколу ODBC.
Подключение внешних пользователей через сеть Интернет не
подразумевается.
12
Сервер БД
Сервер БД
Oracle
Oracle
Firewall
Рисунок 1 – Схема архитектуры серверов Системы
13
4.3 Требования к техническим характеристикам серверов базы
данных и приложений будут сформированы в процессе
подготовки Технического задания.
4.4 Требования к персональным компьютерам
Рекомендуемые требования к персональным компьютерам приведены
далее в таблице (Таблица 2).
Таблица 2 – Рекомендуемые требования к персональным компьютерам
Аппаратное обеспечение
Процессор: Intel Core i5
3Ghz
Разрядность платформы: 64разрядная
Оперативная память: не
менее 4 Gb свободной
памяти
Операционные
системы
Microsoft Windows
XP/Vista/7 с
поддержкой 64битной
архитектуры
4.5 Требования к архитектуре
окружению системы
Перечень ПО
Интернет-браузер
(Microsoft Internet
Explorer версии не ниже
11.0, Mozilla Firefox
версии не ниже 25.0,
Google Chrome не
ниже 31)
Java 8.0
Prognoz Platform 7
вычислительных
сетей
и
Ограничениями в архитектуре вычислительных сетей являются
следующие требования:
1) Каналы связи между серверами – не менее 1Гбс.
2) Каналы между серверами и локальными сетями пользователей – не
менее 128 Кбс на каждого активного пользователя.
4.6 Требования к системе резервного копирования
Требования к резервированию компонентов Системы и всей Системы в
целом должны иметь следующие значения:
 Время восстановления (RTO – Recovery Time Objective) –
допустимое время простоя в случае сбоя Системы – 4 (четыре) часа.
Т.е. RTO – это время, которое необходимо потратить на
14
восстановление Системы, например, извлечь данные из резервной
копии и запустить сервис, предоставляющий эти данные.
 Точка возврата (RPO – Recovery Point Objective) – допустимый объем
возможных потерь данных в случае сбоя Системы – 1 (одни) сутки.
Т.е. RPO – это время создания последней резервной копии, на
момент которой необходимо вернуться в случае сбоя.
 Допустимая нагрузка резервной Системы (RCO – Recovery Capacity
Objective) – часть нагрузки, которую должна обеспечивать резервная
Система – 50 (пятьдесят) пользователей. Т.е. RCO – это мощность
резервной Системы.
Хранилище данных должно обеспечивать резервное копирование на
случай непредвиденного сбоя.
4.7 Требования к характеристикам качества
Система
должна
удовлетворять
следующим
качественным
характеристикам:
 Мощность (Capacity) – одновременное количество пользователей,
имеющих возможность использовать Систему – не менее 50
(пятидесяти) пользователей;
 Производительность (Performance) – время формирования сводного
отчета при одновременной работе 10 (десяти) пользователей – не
более 10 (десяти) секунд;
 Доступность
использования
(Availability)
–
Системы
возможность
на
фактического
согласованном
производительности всеми пользователями
уровне
24 (двадцать четыре)
часа в сутки, 7 (семь) дней в неделю;
 Безопасность
пользователей
(Security)
при
–
корректность
обращении
к
Системе,
аутентификации
соответствие
предоставляемых пользователям данных требованиям действующих
политик безопасности, защиты от несанкционированного доступа;
15
 Гибкость (Agility) – возможность доработок Системы без нарушения
ее основной функциональности. Например, разработка новых
отчетных форм.
4.8 Требования к защите информации от несанкционированного
доступа
Компоненты
Системы
должны
обеспечивать
защиту
от
несанкционированного доступа посредством:
 класс защищенности системы не ниже 1Г.
 идентификации пользователя посредством доменной авторизации;
 проверки полномочий пользователя при работе с Системой;
 исключения возможности несанкционированного доступа за счёт
обеспечения механизмов разграничения доступа к информации в
соответствии с правами;
 регистрации входа и выхода пользователей в Систему;
 ведение журнала активности пользователей.
 шифрования хранимых паролей
Система должна быть защищена от несанкционированного доступа:
 стандартными
средствами
безопасности,
предоставляемыми
операционной системой;
 стандартными средствами СУБД;
 средствами Системы (идентификация пользователей и разграничение
прав доступа);
Система дожна обеспечить:
.. Реализацию ролевой модели доступа
• Интеграцию с системой сбора событий информационной безопасности.
• Интеграцию с системой автоматизации предоставления доступа к ИТресурсам.
• Доступ к интерфейсу подсистем, работающих на web-платформе, должен
производиться по протоколу HTTPS.
• Для взаимодействия через публичные и выделенные каналы связи
(Интернет, телефонные и беспроводные линии связи и т.д.) используются
способы, основанные на технологии Citrix.
16
Лист регистрации изменений
Всего
Входящий
листов №
№ сопроводиПод- ДаИзм.
(стр. в докутельного
пись та
измененных замененных новых изъятых доку- мента документа
менте)
и дата
Номера листов (страниц)
17