ТЕХНИЧЕСКОЕ ЗАДАНИЕ

реклама
Приложение № 1
к Извещению от «__» ____________ 2015 г.
№ _____________________
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на оказание услуг по разработке и внедрению информационной системы управления проектами
(ИСУП)
Настоящий документ является неотъемлемым Приложением № 1 к Договору № ________ от
«____» ________ 2015 года (далее Договор), заключенному между «________________» (далее
Исполнитель) и ОАО «МКЖД» (далее Заказчик).
Настоящее Техническое задание определяет результаты, состав оказания услуг (далее Проект)
по разработке и внедрению Информационной системы управления проектами ОАО «МКЖД».
Исполнитель оказывает упомянутые услуги Заказчику в соответствии с Договором
№ ________ от «____» ________ 2015 года.
Оглавление
1.
2.
3.
ОБЩИЕ ПОЛОЖЕНИЯ. ................................................................................................................. 4
1.1
Название проекта. .....................................................................................................................4
1.2
Сроки оказания услуг по договору. .......................................................................................4
1.3
Заказчик. .....................................................................................................................................4
1.4
Исполнитель. ..............................................................................................................................4
1.5
Источники финансирования. ..................................................................................................4
1.6
Порядок финансирования. ......................................................................................................4
1.8.
Термины и сокращения. ..........................................................................................................4
1.7
Нормативные ссылки...............................................................................................................5
НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ. .................................................................. 6
2.1
Цели оказания услуг:................................................................................................................6
2.2
Назначение системы. ................................................................................................................6
2.3
Ожидаемые выгоды. .................................................................................................................7
ТРЕБОВАНИЯ К СИСТЕМЕ. ........................................................................................................ 7
3.1
Общие требования. ...................................................................................................................7
3.1.1
Требования к структуре системы. ................................................................................. 7
3.1.2
Требования к способам и средствам связи для информационного обмена между
компонентами системы. ................................................................................................................. 8
3.1.3
Требования к режимам функционирования системы. ................................................ 8
3.1.4
Требования по диагностированию системы. ................................................................ 8
3.1.5
Требования к численности и режиму работы персонала........................................... 8
3.1.6
Показатели назначения. ................................................................................................... 9
3.1.7
Требования к надежности системы. ............................................................................. 9
3.1.8
Требования к эргономике и технической эстетике..................................................... 9
1
3.1.9
Требования к защите от несанкционированного доступа. ........................................ 9
3.1.10
Идентификация и аутентификация. ...................................................................... 10
3.1.11
Авторизация и управление доступом пользователей к системе. ....................... 10
3.1.12
Требования к периодичности резервного копирования. ........................................ 10
3.1.13
Требования к обеспечению бесперебойного питания. ........................................... 10
3.1.14
Требования по сохранности информации при авариях. ........................................ 11
3.1.15
Требования по обеспечению обратимости изменений. ........................................ 11
3.1.16
Требования к патентной чистоте. ......................................................................... 11
3.1.17
Требования по стандартизации и унификации. .................................................... 11
3.1.18
Криптографическая защита данных. ...................................................................... 11
3.1.19
Регистрация и аудит событий. ................................................................................ 11
3.2
Требования к техническому обеспечению..........................................................................12
3.2.1
Требования к программному обеспечению. .................................................................. 12
3.2.2
Требования к ИТ-архитектуре. ..................................................................................... 12
3.2.3
Требования к аппаратному обеспечению. ................................................................... 12
3.3
Требования к организационному обеспечению.................................................................14
3.3.1
Организационный объем внедрения системы. ............................................................ 14
3.3.2
Оценка роста числа пользователей системы. ........................................................... 14
3.4
Функциональные требования к системе. ...........................................................................14
3.4.1
Общие требования........................................................................................................... 15
3.4.2
Функциональные требования к подсистеме «Календарно-сетевое
планирование». ................................................................................................................................. 15
3.4.3
Интеграция с системой учета...................................................................................... 17
3.4.4
Функциональные требования к подсистеме «Проектное бюджетирование». .... 17
3.4.5
Функциональные требования к подсистеме «Проектный портал». ..................... 17
3.4.6 Функциональные требования к подсистеме «Аналитическая отчетность». ............ 19
4.
СОСТАВ И СОДЕРЖАНИЕУСЛУГ ........................................................................................... 20
4.1
Требования к составууслуг. ..................................................................................................20
4.2
Результаты и этапы проекта. ................................................................................................20
4.3
Функциональные требования к результатам услуг. ........................................................23
Этап 1. Предпроектное обследование. ......................................................................................... 23
Этап 2. Развертывание ИСУП (Календарно-сетевое планирование). .................................. 24
Этап 3. Развертывание ИСУП (Проектное бюджетирование), .............................................. 24
Этап 4. Интеграция с 1С. ............................................................................................................... 25
Этап 5. Разработка отчетных форм. ............................................................................................ 26
Этап 6. Создание проектного портала......................................................................................... 26
Этап 7. Опытная эксплуатация. ................................................................................................... 26
5.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ. .............................................................. 27
5.1
Опытная эксплуатация. .........................................................................................................28
5.2
Приемо-сдаточные испытания. ............................................................................................28
2
ТРЕБОВАНИЯ К ТЕСТИРОВАНИЮ И ИСПЫТАНИЯМ ИСУП....................................... 28
6.
6.1
Функциональное тестирование. ...........................................................................................28
6.2
Интеграционное тестирование. ............................................................................................29
6.3
Требования по подготовке объекта. ....................................................................................29
6.4
Требования к опытной эксплуатации ИСУП. ...................................................................29
6.5
Требования к технической и эксплуатационной документации. ..................................29
7.
ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА. ...............................................................................30
8.
ПОРЯДОК ВНЕСЕНИЯ ИЗМЕНЕНИЙ В ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ...................30
ОБЯЗАТЕЛЬНЫЕ УСЛОВИЯ ПРИ ОКАЗАНИИ УСЛУГ .................................................... 30
9.
10.
ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННОМУ ОБЕСПЕЧЕНИЮ. ..................................... 31
10.2
Состав рабочей группы. .........................................................................................................31
10.3
Оперативные совещания рабочей группы. ........................................................................32
10.4
Совместные рабочие совещания. .........................................................................................32
10.5
Уточнение планов оказания услуг. ......................................................................................32
10.6
Управление изменениями......................................................................................................32
3
1.
ОБЩИЕ ПОЛОЖЕНИЯ.
Название проекта.
Проект «Разработка и внедрение информационной системы управления проектами» в ОАО «МКЖД».
1.1
Сроки оказания услуг по договору.
Сроки оказания услуг по договору: В соответствии с графиком оказания услуг (Приложение №2 к
настоящему Договору).
1.2
Заказчик.
Заказчиком проекта выступает компания ОАО «МКЖД».
1.3
Исполнитель.
Исполнитель определяется по результатам закупки.
1.4
Источники финансирования.
Финансирование услуг осуществляется за счет средств ОАО «МКЖД».
1.5
Порядок финансирования.
Порядок финансирования услуг: определяется Договором, заключаемым с Исполнителем по
результатам закупочных процедур.
1.6
1.7 Порядок оформления и предъявления Заказчику результатов оказанных услуг
Результаты оказанных услуг передаются Заказчику в порядке, определенном Договором в
соответствии с Графиком оказания услуг на основании Акта приема-передачи оказанных услуг в
полном объеме.
Состав передаваемых отчетных документов на машинных носителях по результатам оказания услуг
оформляется документом «Ведомость машинных носителей информации» по форме, определяемой
РД 50-34.698-90. Исполнитель передает Заказчику материалы в электронном виде, в редактируемых
форматах (doc, docx, xls, xlsx, ppt, sprj и прочих форматах) на машинных носителях (флешнакопитель, CD-R или DVD-R по согласованию с Заказчиком) в 2 экземплярах.
1.8.
Термины и сокращения.
Термин\ Сокращения
БД
ИС
ИСУП
ИТ
КСГ
КСП
НМД
ОЭ
ОС
ОУП
ПО
ПС
ПСИ
РП
СДР
СФД
Определение\Расшифровка
База данных
Информационная система
Информационная система управления проектами
Информационная технология
Календарно-сетевой график
Календарно-сетевое планирование
Нормативно-методическая документация
Опытная эксплуатация
Операционная система
Офис управления проектами
Программное обеспечение
Подсистема
Приемо-сдаточные испытания
Руководитель проекта
Структура декомпозиции работ
Сбор фактических данных
4
СХД
СЭД
ТЗ
УП
ЦОД
ЧТЗ
Группа
проекта
Сервер хранения данных
Система электронного документооборота
Техническое задание
Управление проектами
Центр обработки данных
Частное техническое задание
реализации Сотрудники, участвующие в выполнении проекта. Состав группы
формируется руководителем проекта из специалистов, обладающих
знаниями и навыками, необходимыми для эффективного достижения
целей проекта.
ИСУП
Информационная система управления проектами.
Комплекс задач по разработке, актуализации, контролю и
корректировке календарно-сетевого графика или календарного
Календарно-сетевое
графика,
предназначенных
для повышения эффективности
планирование (КСП)
организации работ и использования ресурсов. Оптимальным
инструментом выполнения комплекса задач КСП является
специализированная информационно-аналитическая системы.
График
процесса
создания
объекта
ТПУ,
отражающий
Календарно-сетевой
технологическую зависимость и последовательность оказания услуг,
график (КСГ)
увязывающий их совершение во времени.
Опытная эксплуатация
Комплексная проверка готовности разработанной системы.
Основная цель проведения – проверка алгоритмов, отладка программ
и технологического процесса обработки данных в реальных условиях.
Техническое задание на Исходный документ на проектирование ИСУП.
ИСУП
Технический проект на Документ, содержащий окончательные проектные решения на ИСУП.
ИСУП
1.7
Нормативные ссылки.
№
Наименование
Наименование
документа
Внешние документы (источники права, стандарты и др.)
1.
Постановление Правительства Москвы от 6 сентября 2011 года N 413-ПП О формировании
транспортно-пересадочных узлов в городе Москве
2.
ГОСТ 12.1.002-84
Система стандартов безопасности труда. Электрические поля
промышленной частоты.
3.
ГОСТ 12.2.003-91
4.
ГОСТ 12.2.007.0-75
Допустимые уровни напряженности и требования к проведению
контроля на рабочих местах.
Система стандартов безопасности труда. Оборудование
производственное. Общие требования безопасности
Система
стандартов
безопасности
труда.
Изделия
электротехнические.
Общие требования безопасности
Единая система конструкторской документации.
5.
ГОСТ 2.105-95
Общие требования к текстовым документам.
Система проектной документации для строительства.
6.
ГОСТ Р 21.1101-2013
7.
ГОСТ 34.201-89
Основные требования к проектной и рабочей документации.
Информационная технология.
автоматизированные системы.
Комплекс
стандартов
на
Виды, комплектность и обозначение документов при создании
5
автоматизированных систем.
Автоматизированные системы.
8.
ГОСТ 34.601-90
9.
ГОСТ 34.602-89
Стадии создания.
Информационная технология. Комплекс стандартов на
автоматизированные системы. Техническое задание на создание
автоматизированной системы.
Методические указания.
10.
РД 50-34.698
Информационная технология.
Комплекс стандартов и руководящих
автоматизированные системы.
документов
на
документов
на
Методические указания
11.
Информационная технология.
РД 50-34.698-90
Комплекс стандартов и руководящих
автоматизированные системы.
Автоматизированные
документов.
системы
требования
к
содержанию
Постановление Главного государственного санитарного врача
РФ
11.
СанПиН
2.2.2/2.4.1340-03
от 3 июня 2003 г. N 118
"О введении в действие санитарно-эпидемиологических правил и
нормативов.
Внутренние нормативно-методические документы
1.
Устав Открытого акционерного общества «МКЖД»
2.
НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ.
2.1
Цели оказания услуг:
 внедрение единых подходов к управлению проектами развития транспортно-пересадочных
узлов;
 автоматизация процессов управления проектами;
 формирование единого информационного пространства, обеспечивающего эффективное
распределение управленческой информации между участниками проектов в процессе
планирования, исполнения и контроля проектов;
 сокращение сроков, повышение качества и снижение трудозатрат при планировании и
разработке календарно-сетевых графиков строительства и планов развития ТПУ;
 повышение скорости принятия управленческих решений;
 обеспечение руководства Компании и всех заинтересованных сторон актуальной
информацией о ходе и состоянии проекта на основании сформированной в системе
отчетности.
Назначение системы.
Система управления проектами предназначена для решения задач информационного обеспечения
процессов управления проектами:
 объединение данных о ведущихся проектах из разрозненных центров управления в
единой распределенной системе;
2.2
6
 календарно-сетевое планирование проектов с необходимым уровнем детализации,
контролем фактического состояния и прогнозированием по установленной методике;
 поддержка единого регламента взаимодействия участников проектов на различных
уровнях управления;
 хранение архива документации в привязке к транспортно-пересадочному узлу, видам
работ и работам;
 перспективное планирование;
 контроль выполнения работ;
 актуализация данных в системе;
 анализ реализации проектов;
 формирование отчетности о ходе выполнения работ проектов.
Ожидаемые выгоды.
2.3
Реализация проекта должна привести к созданию интегрированного процесса оперативного
планирования, контроля и подготовки отчетности по проектам развития ТПУ. Внедряемая система
должна обеспечить:
 автоматизацию процедур планирования, контроля, проектного бюджетирования и
управления договорами;
 создание архива проектов;
 автоматизацию обмена данными, организацию единого информационного пространства в
процессах планирования и контроля;
 доступ любого участника проекта к актуальной информации для своевременного
принятия управленческих решений;
 отчетность в соответствии с заданной формой и на основе информации, содержащейся в
любой из подсистем;
 синхронизацию и автоматический обмен данными между ИСУП и учетными
подсистемами – бухгалтерского учета, управленческого учета, финансово-договорного
обеспечения и проектного бюджетирования;
 управление поручениями.
3.
ТРЕБОВАНИЯ К СИСТЕМЕ.
3.1
Общие требования.
а) Система должна обладать простым и интуитивно понятным пользовательским
интерфейсом.
б) Должна быть обеспечена возможность создания и рассылки сообщений по событиям.
в) Внедрение ИСУП не должно привести к увеличению производственного персонала,
работающего над проектами заказчика.
3.1.1
Требования к структуре системы.
Функционирование системы должно осуществляться в многозвенной архитектуре вычислительной
сети, в виде взаимодействующего набора подсистем (модулей), совместимых на программноаппаратном и информационном уровне.
Архитектура системы должна быть разработана в соответствии с трехуровневой клиент-серверной
архитектурой и должна содержать следующие компоненты:
 уровень хранения данных;
 уровень обработки данных;
 уровень представления данных.
Уровень представления данных должен быть разработан в соответствии с принципами
архитектуры «тонкого клиента».
7






Архитектура системы должна содержать следующие компоненты:
стационарные автоматизированные рабочие места пользователей (САРМ);
мобильные автоматизированные рабочие места пользователей (МАРМ);
системы управления базами данных;
серверы приложений;
серверы управления инфраструктурой приложений;
сеть передачи данных.
Архитектура должна предусматривать централизованный характер хранения и обработки
входящей информации.
3.1.2
Требования к способам и средствам связи для информационного обмена между
компонентами системы.
При организации информационного обмена между компонентами системы должны быть
использованы стандартные протоколы обмена данными, базирующиеся на стеке транспортных
протоколов TCP/IP.
3.1.3
Требования к режимам функционирования системы.
В системе должны быть предусмотрены следующие режимы работы:
сервисный режим работы;
аварийный режим работы.
Под сервисным режимом работы понимается режим промышленной эксплуатации, котором
доступно выполнение всех функций системы.
В сервисном режиме:
 клиентское программное обеспечение и технические средства пользователей и
администратора системы должны обеспечивать возможность функционирования системы
24 часа в сутки, семь дней в неделю, с перерывами на обслуживание (включая обновление
версий программного обеспечения системы и технических средств пользователей);
 серверное программное обеспечение и технические средства северов должны обеспечивать
возможность круглосуточного функционирования системы, с перерывами на
обслуживание (включая обновление версий программного обеспечения серверов);
 должно исправно работать оборудование, составляющее весь комплекс технических
средств системы;
 программное обеспечение системы должно обеспечивать выполнение всех ее функций.
В аварийном режиме выполняются работы по настройке, тестированию и восстановлению
работоспособности системы после нештатных ситуаций.
Диагностика комплекса технических средств системы должна осуществляться в соответствии с
их эксплуатационной документацией. Процедуры диагностирования программных средств системы в соответствии с эксплуатационной документацией на используемое программное обеспечение.
Требования по диагностированию системы.
Средства
диагностирования
системы
являются
неотъемлемой
частью
подсистемы
администрирования и должны обеспечивать возможность диагностирования и контроля
работоспособности системы, а именно:
 проверка работоспособности программного обеспечения Системы;
 выявление отказов (ошибок функционирования) программного обеспечения Системы;
 автоматический контроль функционирования программных средств Системы с
фиксацией событий в соответствующих журналах (лог-файлах).
3.1.4
Требования к численности, квалификации и режиму работы персонала.
Пользователи Системы должны иметь базовые навыки работы на персональном компьютере на базе
операционной системы Microsoft Windows, а также с приложениями Microsoft Excel, Microsoft Word и
Интернет-браузерами. Под базовыми навыками понимается включение и выключение персонального
8
3.1.5
компьютера, операционной системы и прикладных приложений, выполнение операций по вводу
данных, сохранению информации, выводу информации на печать.
Показатели назначения.
Система должна обеспечивать:
 масштабируемость по количеству пользователей в пределах – до 500 всего, 100
одновременных;
 суммарный объем документов – до 1 000 000 страниц документов в год (средний размер
страницы – 100 килобайт);
 суммарный объем фото- и видеоматериалов – до 15 000 фотографий в год (средний размер
фотофайла – 6 мегабайт), до 500 видеофайлов в год средний размер видеофайла – 100
мегабайт);
 период накопления архивных данных – до 5 лет;
 открытие оконных форм системы – не более 5 секунд.
3.1.6
Требования к надежности системы.
Система должна функционировать круглосуточно, в непрерывном режиме, кроме времени
проведения работ по резервному копированию данных, восстановлению данных, смене версий
программного комплекса, др. профилактических работ по техническому обслуживанию, требующих
остановку технических средств.
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при
возникновении следующих внештатных ситуаций:
 отказы и сбои в работе серверов и сетевого оборудования;
 неправильные действия пользователей;
 ошибки технического персонала;
Надежность Системы, должна характеризоваться следующими значениями показателей:
o среднее время восстановления после сбоя – не более 24 часов;
o максимальное время восстановления – не более 48 часов;
o время наработки на отказ – не менее 10 000 часов;
o назначенный срок службы – не менее 3 лет;
Резервное копирование и восстановление баз данных с резервной копии должно осуществляться в
соответствии с разработанным регламентом функционирования ИСУП и восстановления данных.
В целях повышения надежности и работоспособности системы разграничить права доступа к ней,
ввести журнал событий системы. Требования к надежности ИСУП уточнить в документации
Технического проекта.
3.1.7
3.1.8
Требования к эргономике и технической эстетике.
Интерфейс взаимодействия пользователя с Системой должен обеспечивать простой и понятный
доступ к основным функциям и операциям Системы. Экранные формы должны проектироваться с
учетом следующих требований:
 все экранные формы должны выполняться в едином графическом дизайне;
 эргономичное расположение меню и часто используемых элементов экрана;
 для обозначения одинаковых операций во всех подсистемах использовать одни и те же
значки, кнопки, другие управляющие элементы;
 отображать элементы интерфейса в зависимости от прав доступа к Системе;
 поддерживать отображение на экране сообщений о выполнении длительных (более 5 секунд)
процессов обработки данных.
Система должна обеспечивать обработку нештатных ситуаций, вызванных неверными действиями
пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных
случаях система должна выдавать пользователю соответствующие сообщения об ошибке, после чего
возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или
недопустимым значениям входных данных.
3.1.9
Требования к защите информации от несанкционированного доступа.
9
Для обеспечения информационной безопасности:
 подтверждать аутентификацию и авторизацию пользователей средствами системы;
 разграничить права доступа пользователей в системе на выполнение следующих действий:
o
просмотр информации;
o
редактирование, добавление и удаление информации;
o
редактирование прав доступа к информации.
 разграничить права доступа пользователей к данным системы, а также экранным формам,
элементам функциональности форм, отчетам;
Идентификация и аутентификация.
Правила разграничения доступа к системе должны предусматривать назначение групповых прав
доступа к данным. В ИСУП должны быть определены группы пользователей, имеющие доступ к
функциям и данным системы, согласно предписанным им ролям. Для каждой роли пользователя
должна быть доступна информация и набор функций, определенных его правами служебного
доступа. Исключением являются справочники ИСУП, доступные для использования всеми
пользователями.
3.1.10
Авторизация и управление доступом пользователей к системе.
В целях управления доступом предусмотреть идентификацию и проверку подлинности пользователей
при входе в систему:
контроль доступа к таблицам в соответствии с матрицей доступа средствами СУБД;
 автоматическая блокировка одновременного доступа нескольких пользователей под одним
паролем;
 регистрация входа (выхода) в систему (из системы) в соответствии с требуемым набором
параметров. При неудачном входе в систему, логин и пароль записывать в лог-файл на
сервере;
 регистрация на сервере всех попыток соединения с базой данных (удачных и неудачных) с
использованием информационной системы;
 регистрация просмотра и изменения пользователем информации по объекту с указанием
уникального идентификатора объекта, а также времени доступа, имени компьютера и логина;
 регистрация формирования отчетов с указанием названия отчета, параметров, а также
времени, имени компьютера и логина;
 регистрация изменения полномочий пользователя в системе.
3.1.11
Требования к периодичности резервного копирования.
Резервному копированию подлежит вся информация, содержащаяся в системе:
 информация, необходимая для восстановления серверов и систем управления базами данных;
 базы данных;
 информация областей управления ИСУП;
 описание процессов управления проектами;
 справочники системы;
 персональные профили пользователей;
 данные интегрированных систем;
Производить три вида резервного копирования.
 Ежемесячная копия.
Информация записывается в первый календарный день текущего месяца. Срок хранения – месяц.
Хранится на сервере резервного копирования.
 Еженедельная копия.
Информация записывается в ночь с четверга на пятницу. Срок хранения информации – до
следующей пятницы. Хранится на сервере.
 Ежедневная копия.
Записывается ежесуточно, кроме ночи с четверга на пятницу. Срок хранения – сутки. Хранится
на сервере.
3.1.12
3.1.13
Требования к обеспечению бесперебойного питания.
10
Для обеспечения устойчивости к отказам электроснабжения все устройства хранения и обработки
информации должны быть подключены к электросети через источники бесперебойного питания.
Необходимо предусмотреть функцию автоматического предупреждения пользователей о
возникающих неполадках. Время гарантированной работы для завершения серверных и прикладных
приложений, в случае отключения энергоснабжения, обеспечиваемое источниками бесперебойного
питания, должно быть не менее 30 минут.
Требования по сохранности информации при авариях.
Сохранность информации должна быть обеспечена в случае возникновения следующих событий
(аварий, отказов и т.п.):
 отказ аппаратуры сервера;
 проведение регламентных работ с оборудованием ИСУП;
 отключение питания на рабочем месте и/или на сервере баз данных;
 отказ оборудования рабочей станции;
 отказ линий связи.
Порядок мер по организации действий системного администратора при возникновении нештатных
ситуаций, проведении ремонтных и регламентных работ должен быть определен в Руководстве по
эксплуатации ИСУП.
3.1.14
Требования по обеспечению обратимости изменений.
В ИСУП должна присутствовать функциональная возможность «отката» системы с восстановлением
первоначального состояния задействованных информационных изменений в случае отказа
пользователя от продолжения операции, аппаратного или программного сбоя. Функциональная
возможность «отката» ИСУП произведенных пользователями изменений должны быть приведены в
эксплуатационной документации.
3.1.15
Требования к патентной чистоте.
Программные и аппаратные решения и средства, используемые при разработке ИСУП должны
отвечать требованиям по патентной чистоте согласно действующему законодательству.
Исполнителю, в случае использования собственных разработок, необходимо указывать наличие
документальных свидетельств на владение интеллектуальной собственностью и авторскими правами.
Все программно-технические средства общего программного обеспечения, обеспечивающее
работоспособность ИСУП должны иметь разрешение на использование (лицензию) с требуемым
количеством пользователей.
3.1.16
Требования по стандартизации и унификации.
При создании ИСУП необходимо в высшей степени преследовать цели унификации технических
решений. Технический проект должен создаваться на основе действующих стандартов, норм, правил
и других нормативно-технических документов. Унификация технических решений должна
обеспечиваться единообразным подходом к решению однотипных задач ИСУП.
Типовые решения, разработанные при проектировании ИСУП, должны обеспечивать тиражирование
создаваемых программно-технических комплексов на все подразделения компании, без
дополнительного проектирования путем изменения настроек и состава компонентов системы.
Система должна использовать стандартные, унифицированные методы реализации функций (задач):
 поддержка современных транспортных протоколов: TCP/IР;
 поддержка наиболее распространенных форматов документов: HTML, XML и т.д.;
 повышение отказоустойчивости и надежности системы;
 поддержка поиска информации;
 функционирование на различных аппаратных платформах.
3.1.17
Криптографическая защита данных.
Требования к криптографической защите данных не предъявляются.
3.1.18
Регистрация и аудит событий.
Регистрация и аудит событий должны производиться с помощью средств системы и охватывать все
производимые операции по модификации данных системы, включая:
3.1.19
11
 события входа в систему (успешного/неуспешного);
 контроль активности пользователей в разрезе сессии;
 контроль изменений глобальных справочников данных в системе по выбранным критериям;
 контроль изменений данных проектов в системе по выбранным критериям;
 возможность просмотра информации о времени внесения изменений;
 возможность просмотра информации о пользователе, внесшем изменения;
 изменения полномочий пользователя в системе.
Дополнительно система должна регистрировать информацию необходимую для диагностирования
сбоев в структурах БД, а также сохранять требуемую информацию в выделенном системном журнале
сервера приложений. Протоколы аудита системы и приложений должны быть защищены от
несанкционированного доступа.
Требования к техническому обеспечению.
3.2.1
Требования к программному обеспечению.
Информационная система управления проектами с поддержкой проектного бюджетирования должна
быть реализована на основе базового функционала информационной системы Oracle Primavera P6
Enterprise Project Portfolio Management 15.1 в части планирования и Microsoft Share Point 2013 в части
контроля реализации проектов и проектного портала.
Программное обеспечение, входящее в состав системы, должно в максимальной степени
использовать данные, имеющиеся в других ИС заказчика и не допускать их дублирования. Система
должна обеспечивать возможность хранения и обработки информации, оптимальную организацию
данных с точки зрения скорости выполнения операций (загрузки информации и запросов
пользователей).
Система должна предусматривать возможность масштабирования по производительности и объему
обрабатываемой информации без модификации её программного обеспечения путем модернизации
используемого комплекса технических средств. Возможности масштабирования должны
обеспечиваться средствами используемого базового программного обеспечения.
3.2
Требования к ИТ-архитектуре.
Информационная система представлена в виде трехслойной архитектуры.
1. Сервер приложений (Oracle Primavera).
Предназначен для предоставления доступа пользователей через веб-интерфейс к системе.
2. Сервер приложений (Microsoft SharePoint).
Предназначен для предоставления доступа пользователей через веб-интерфейс к порталу.
3. Сервер БД
Предназначен для хранения внесенных данных в систему. Внесенные данные хранятся
неограниченно долго.
Сервер приложений использует данные из Сервера БД. Данные из сторонних систем интегрируются в
системе через сервер приложений посредством интеграционных сервисов. Веб-компоненты системы
делают возможным подключение посредством браузера к источнику данных сервера и обеспечивают
функциональность работы пользователя в веб-среде ИСУП.
Сотрудники ОАО «МКЖД», находящиеся вне офиса, работают через веб-интерфейс.
3.2.2
Требования к аппаратному обеспечению.
В качестве аппаратной платформы создаваемой информационной системы предполагается
использовать две виртуальные площадки:
- промышленная площадка предназначена для размещения готовой к эксплуатации системы;
- тестовая площадка предназначена для размещения системы на период разработки, внедрения и
отладки системы.
3.2.3
Табл. 1 Характеристики промышленной площадки
№
п/п
Сервер
Название
сетевого
сервиса
Параметры сервера
Примечание
12
1.
2.
3.
4.
5.
6.
Виртуальный
сервер
Виртуальный
сервер
Виртуальный
сервер
Виртуальный
сервер
СХД
Виртуальный
сервер
Сервер БД
 2 CPU 4 core
 64Gb ОЗУ
 Windows Server 2008 R2
 Oracle 11g
100 Mb/s Lan
Промышленный
сервер БД
AppServer
 2 CPU 4 core
 32Gb ОЗУ
 Windows Server 2008 R2
 Oracle WebLogic 12.1.1
 Java Sun JDK 1.7.0._21
100 Mb/s Lan
Промышленный
сервер приложений
AppServer
 2 CPU 4 core
 32Gb ОЗУ
 Windows Server 2008 R2
 Oracle WebLogic 12.1.1
 Java Sun JDK 1.7.0._21
100 Mb/s Lan
Промышленный
сервер приложений
AppServer
 2 CPU 4 core
 32Gb ОЗУ
 Windows Server 2008 R2
 MS SharePoint 2013
100 Mb/s Lan
Промышленный
сервер приложений
Data Storage
 2000 Gb HDD
 ~10 000 IOPS
 RPO 24 часа
RTO 24 часа
СХД
Сервер БД
 2 CPU 4 core
 64Gb ОЗУ
 Windows Server 2008 R2
 Oracle 11g
100 Mb/s Lan
Промышленный
сервер БД
Табл. 2 Характеристики тестовой площадки
№
п/п
1.
Сервер
Виртуальный
сервер
Название
сетевого
сервиса
Сервер БД
Параметры сервера





2.
3.
Виртуальный
сервер
AppServer
Виртуальный
сервер
AppServer










1 CPU 4 core
16Gb ОЗУ
Windows Server 2008 R2
Oracle 11g
100 Mb/s Lan
1 CPU 4 core
8Gb ОЗУ
Windows Server 2008 R2
Oracle WebLogic 12.1.1
Java Sun JDK 1.7.0._21
100 Mb/s Lan
1 CPU 4 core
8Gb ОЗУ
Windows Server 2008 R2
Oracle WebLogic 12.1.1
Примечание
Тестовый сервер БД
Тестовый сервер
приложений
Тестовый сервер
приложений
13
4.
Виртуальный
сервер
5.
СХД
AppServer
Data Storage











Java Sun JDK 1.7.0._21
100 Mb/s Lan
1 CPU 4 core
8Gb ОЗУ
Windows Server 2012 R2
MS SharePoint 2013
100 Mb/s Lan
500 Gb HDD
~5 000 IOPS
RPO 24 часа
RTO 24 часа
Тестовый сервер
приложений
СХД
Серверы выделяются Заказчиком в виртуальной среде ОАО «МКЖД». Предполагается выделение
следующих серверов - сервер БД ИС, сервер приложений ИС (2 шт.) и сервер аналитической
отчетности.
Требования к аппаратному и программному обеспечению должны быть уточнены Претендентом
при разработке технического проекта.
3.3
3.3.1
Требования к организационному обеспечению.
Организационный объем внедрения системы.
Табл. 3 Первоначальный (пилотный) организационный объем внедрения системы.
№
Организационный объем
1.
Первоначальный (пилотный) организационный объем планируется в рамках: до 30
пользователей, из них до 5 пользователей - с функционалом ведения календарных
графиков (планировщики), 25 – с функционалом доступа к проектному порталу.
2.
Максимальный организационный объем проекта (включая пилотный): 60 пользователей,
из них 10 пользователей с функционалом ведения календарных графиков
(планировщики), 50 – с функционалом доступа к проектному порталу.
Численность пользователей ИСУП определяется как общая численность пользователей со стороны
сотрудников заказчика, генерального подрядчика, компании, осуществляющей строительный
контроль, внешних пользователей системы, которым выдан доступ для просмотра отдельных видов
информации.
Для контроля реализации и приемки оказанных услуг, Заказчиком будет организована группа
реализации проекта, состоящая из профильных специалистов, и определены должностные лица,
ответственные за реализацию договора.
Управление проектом «Разработка и внедрение информационной системы управления проектами в
ОАО «МКЖД» со стороны Исполнителя и Заказчика должно выполняться с использованием ПО
Oracle Primavera. Создание и ведение проекта в Oracle Primavera осуществляется силами
Исполнителя – Заказчик при этом выполняет контрольную функцию.
3.3.2
Оценка роста числа пользователей системы.
Оценка роста числа пользователей системы на сервере приложений ИС:
 общее количество пользователей системы ~ 60 человек;
 общее начальное количество пользователей ~ 25 человек.
Оценка роста числа пользователей системы на сервере аналитической отчетности:
 общее количество пользователей системы ~ 60 человек;
 общее начальное количество пользователей ~ 30 человек.
Оценка прироста объема информации в БД системы: 10 Гб/год.
3.4
Функциональные требования к системе.
14
Общие требования.
3.4.1
- обеспечить многопользовательскую работу в единой информационной
среде, в том числе с удаленных рабочих мест с использованием сети
Internet;
- наличие гибкого генератора отчетов и средств визуализации для изменения
пользователями настроенных и формирования новых управленческих форм
и отчетов;
- табличное и графическое представление информации.
Требования к функционалу информационной системы управления проектами приведены в разделе
5.3. технического задания.
Функциональные требования к подсистеме «Календарно-сетевое планирование».
3.4.2.1
Управление содержанием (Project Scope Management).
Под управлением содержанием понимаются процессы, позволяющие производить выборку,
фильтрацию и группировку по проекту тех и только тех работ, которые понадобятся
руководителю проекта для успешного завершения проекта.
Таким образом, подсистема должна обладать следующими функциональными возможностями:
 формирование титульных списков строительства;
 формирование и управление внутриплощадочными титульными списками
строительства;
 формирование иерархической структуры ответственных;
 использование базы типовых фрагментов для стандартизации подходов к
формированию WBS;
 формирование словарей и справочников проектов, ресурсов и работ;
 редактирование неограниченного количества пользовательских полей по
различным разделам данных в системе;
 хранение неограниченного количества утвержденных планов (сценариев)
реализации проекта;
 формирование реестра документов по проекту с возможностью привязки к
электронному хранилищу документов на проектном портале и перехода к
ним по гиперссылке.
3.4.2
Управления сроками (Project Time Management)
3.4.2.2
 формирование и контроль календарно-сетевых графиков различных
уровней иерархии с обязательной поддержкой работами графика
следующих параметров:








исходная, планируемая и фактическая длительность работ;
календарь проекта, видов работ;
даты начала и окончания работ (планируемые, фактические, прогнозные, ожидаемые);
ограничения на даты начала и окончания;
технологические зависимости между работами (с возможностью связать две работы более чем
одним типом зависимости);
% выполнения работы;
шаги работы;
физический объем (план/факт).
 возможность расчета % выполнения по работам проекта и по всему
проекту на основании следующих данных:



физические объемы работ;
стоимость работ/фактические затраты;
сроки выполнения работ.
 возможность назначения на работы ответственных исполнителей
(сотрудников компании/сотрудников подрядных организаций);
 формирование иерархической структуры ресурсов: трудовых, нетрудовых
и материалов;
 обеспечить возможность расчета требуемых трудовых ресурсов на
основании:

общих принципов нормирования труда принятым в ОАО «МКЖД»;
15

фиксированного количества смен по конкретным работам, принятым в ОАО «МКЖД».
 автоматическое формирование недельно-суточных заданий на любой
период времени (в том числе формирование требуемого плана с учетом
накопленных отклонений – “recovery plan”);
 ввод оперативных данных о фактическом выполнении работ посредством
импорта заполненных обменных форм актуализации;
 автоматический пересчет расписания в зависимости от текущего
выполнения работ;
 расчет критического пути проекта с возможностью определения
критических работ на основании следующих методик:


полный резерв работ;
самый длинный путь проекта.
 формирование диаграмм Ганта с отражением требуемых показателей
(сроки, % выполнения, отв. исполнитель и другие);
 возможность использования сценарного подхода к реализации проекта;
 возможность анализа текущего графика, выявление отклонений от
утвержденного плана;
 назначение на работы графика документов посредством ссылок на другие
системы и их просмотр.
3.4.2.3
Управление стоимостью (Project Cost Management).
Под управлением стоимостью проекта понимается планирование и разработка бюджета, а также
управление расходами, которые обеспечивают завершение проекта в рамках утвержденного
бюджета. Подсистема должна поддерживать следующий функционал:
 формирование иерархической структуры статей затрат;
 определение плановой себестоимости проекта (отдельных объектов,
этапов, видов работ) двумя методами:


ресурсным методом: назначение ресурсов на работы (плановые и фактические трудозатраты,
интенсивность) и расчет стоимости работ на основании количества назначенных ресурсов и
расценки за их единицы;
методом разнесения затрат по объектам строительства и видам работ.
 контроль стоимости фактически выполненных работ по статьям затрат;
 оценка стоимости невыполненных работ;
 анализ реализации проекта с помощью метода освоенного объема*
(отображение S-кривых планового объема и освоенного объема) с
расчетом отдельно по каждому уровню структуры декомпозиции работ;
3.4.2.4
Управления коммуникациями (Project Communication Management).
Процессы управления коммуникациями применяют с целью обеспечения своевременного
формирования, подготовки, распространения, архивации, передачи, получения, использования
информации на проекте:





группировка, фильтрация и сортировка работ графика по заданным условиям;
формирование и сохранение утвержденных экранных форм представления информации с
различным уровнем детализации и за различные временные периоды по различным
показателям;
организация информационного обмена и взаимодействий вовлеченных в проект участников
между собой;
работа в одном проекте единовременно с учетом прав доступа пользователей;
экспорт и импорт данных с помощью приложений MS Office.
3.4.2.5 Управление поставками.
 формирование иерархической структуры материальных ресурсов;
 назначение требуемых материальных ресурсов на работы с указанием норм расходования;
 планирование поставок основного оборудования и строительных материалов на площадку,
диспетчеризация поставок;
 контроль сроков.
16
3.4.2.6 Сбор фактических данных. Актуализация календарно-сетевых планов.
Для сбора актуальных данных о выполнении работ использовать обменные формы. Обменные
формы представляют собой специально настроенные таблицы в формате Microsoft Excel
(предоставить возможность выбора сохранения обменной формы в любой версии указанного
продукта), созданные для упрощения коммуникаций между планировщиком проекта и
исполнителями этапов и задач проекта, таким образом:


обменные формы должны формироваться в формате Microsoft Excel;
обменные формы должны служить основанием для автоматизации при решении двух задач:


построение иерархической структуры работ КСГ проекта;
актуализация КСГ проекта.
Интеграция с системой учета.
Для автоматизации процессов по сбору фактических данных о затратах и передачи в систему
учета сформированных финансовых планов разработать механизм интеграции с системой учета.
3.4.3





3.4.4
















3.4.5
система должна поддерживать ручные и автоматические механизмы интеграции через web
сервисы и файлы обмена данными;
в системе должны фиксироваться события и ошибки процесса получения и передачи данных;
при загрузке данных в системе отражать информацию о вновь добавленных или изменённых
элементах;
выход из строя элементов инфраструктуры смежных и подключаемых систем не должен
приводить к сбоям функционирования ИСУП (кроме модулей, обеспечивающих
принудительную отправку/прием/синхронизацию данных);
представление в табличной форме распределения планируемых затрат во времени (по
кварталам, по месяцам).
Функциональные требования к подсистеме «Проектное бюджетирование».
создание многоуровневых структур бюджетов проектов;
расчет бюджета проекта на основании:
объектов-аналогов;
расценок по видам работ;
калькуляции стоимостей назначенных ресурсов.
применение шаблонных S-кривых на укрупненные работы для увеличения точности
планирования;
формирование бюджета доходов и расходов по проекту, бюджета движения денежных средств
на основании данных календарно-сетевых планов;
контроль исполнения бюджета в части:
планового объема (PV) – плана освоения в плановых расценках;
освоенного объема (EV) – фактически выполненные физ. объемы работ в плановых расценках;
фактической стоимости (AC) – фактическая стоимость заактированных физ. объемов работ;
факт оплат – фактически оплаченные работы.
анализ стратегических, годовых и оперативных бюджетов проектов в разрезе различных
статей;
управление изменениями бюджетов проектов за период с выявлением причин отклонения от
утвержденного плана работ и последующей корректировкой производственных работ;
хранение в системе откорректированных бюджетов, с возможностью сравнения с текущей
версией;
актуализация годовых и оперативных бюджетов проектов.
Функциональные требования к подсистеме «Проектный портал».
Организация взаимодействий по проектам в рамках рабочих областей, определяющих круг
участников, их роли в проекте и права доступа к информации по проекту.
17




Управление коммуникациями и изменениями в проектах:
формирование справочников: «Участники проекта», «Контрагенты», «Корреспонденция»,
«Изменения», и др., предусмотреть возможность настройки новых справочников;
создание медиатеки строительства;
использование шаблонов рабочих областей, возможность создания рабочей области нового
проекта из шаблона с использованием мастера;
система автоматического уведомления пользователей о поступлении, изменениях документов и
информации по электронной почте и RSS.
Управление документооборотом проекта:
 регистрация контрактной, тендерной и иной документации в рамках рабочей области проекта;
 регистрация и ведения реестров сопроводительных писем, запросов на предоставление
информации, проблем и подборок по ним в рамках рабочей области проекта;
 фиксация и хранение в системе материалов предоставляемых строительных контролем:





еженедельный технический отчет с приложением материалов фотофиксации;
ежедневная служебная записка по каждому объекту ТПУ, на котором осуществляется
строительный контроль.
формирование отчетов о зарегистрированных документах и информации (проблемах, запросах
на изменение и т.д.);
согласование документов и решений по проекту;
формирование отчетов о процессах согласования документов и их состоянии;
Организация хранилища проектной документации:
 формирование единого технического архива:






регистрация всей проектной, рабочей, исполнительной документации по проекту с целью
формирования единого технического архива для всех участников проекта;
регистрация
связанных
проектных
документов
(чертеж-локальная
смета-заказная
спецификация) комплектами;
использование единых справочников, проектируемых/сооружаемых объектов (титулов),
зданий/сооружений;
формирование исходного перечня требуемой документации по проекту;
печать полного перечня документации по проекту (с указанием наличия, состояния разработки
или согласования каждого комплекта).
учет и контроль изменений проектной документации:






контроль поступления проектной документации;
автоматическая рассылка уведомлений о поступлениях проектной документации по электронной
почте и RSS;
учет и контроль всех версий каждого комплекта документации;
учет даты и автора изменений, примечаний к измененной документации;
доступ ко всем предыдущим версиям документации;
контроль документации, которая находится на изменении, поступившей или измененной сегодня
документации, изменений за последнюю неделю.
Контроль исполнения поручений:
 управление совещаниями:







назначение совещаний с указанием пунктов повестки и перечня внешних и внутренних
участников;
автоматическое уведомление по электронной почте внутренних и внешних участников
совещаний;
настраиваемые шаблоны уведомлений о проведении совещаний;
отображение электронной формы совещания, содержащей информацию по пунктам повестки;
внешним и внутренним участникам, назначенным поручениям;
печать электронной формы совещания в Microsoft Word в соответствии с шаблоном компании;
ведение справочника контрагентов (внешних участников совещания).
назначение поручений:


назначение поручений в рамках проекта или портфеля проектов, поручений по совещаниям,
фиксация прямых поручений руководителями;
делегирование поручений, назначение новых поручений на основе существующего (декомпозиция
поручения);
18





настраиваемый ролевой состав участников процесса исполнения поручения (ответственный
исполнитель, контролер, автор поручения и т.д.);
автоматическое разграничение прав доступа к поручениям на основе ролей;
автоматическое уведомление по электронной почте участников при назначении нового
поручения;
учет переписки и общения, возникающего между участниками процесса исполнения поручения;
печать электронной формы поручения и истории его исполнения в Microsoft Word в
соответствии с шаблоном Компании.
 контроль исполнения поручений:
 контроль состояния исполнения поручения, процента выполнения, фактической
информации об исполнении на заданную дату;
 формирование иерархии поручений;
 автоматическое уведомление по электронной почте участников проекта об изменении
информации по исполнению поручения;
 отправка запросов на предоставление информации об исполнении поручения;
 отображение на главной странице рабочей области проекта активных поручений по
данному проекту;
 контроль исполнения поручений в разрезе совещаний, проектов, сотрудников,
состояний;
 отображение статистической информации по исполнению поручений;
 отображение графических индикаторов % выполнения поручения, состояния исполнения
поручения;
 настраиваемые шаблоны уведомлений по электронной почте;
 формирование сводных отчетов об исполнении поручений.
Функциональные требования к подсистеме «Аналитическая отчетность».
Подсистема «Аналитической отчетность» должна представлять собой единый электронный архив,
позволяющий хранить информацию о проектах в финансовых (стоимость, освоение,
финансирование) и натуральных показателях (сроки, длительность, трудоемкость, физические
параметры). Должна быть возможность хранить историю изменения показателей проектов (перечень
показателей, по которым должны сохраняться исторические данные, должен быть уточнен на этапе
разработки технического проекта).
Подсистема предназначена для организации информационного обмена в режиме реального времени с
целью анализа и увеличения скорости принятия управленческих решений, таким образом,
необходимо реализовать просмотр данных с возможностью детализации (например, от портфеля
проектов к проекту) и обобщения (от отдельных назначений ресурсов и расходов на работы ко всему
проекту). Обеспечить настройку отчетов высокого презентационного качества в табличных и
графических формах, управлять доставкой отчетов потребителям.
Организация наборов динамически связанных между собой отчетных форм, доступных через
веб-интерфейс:
 настраиваемое расписание автоматического формирования отчетов;
 автоматическая рассылка отчетов по электронной почте;
 сохранение истории сформированных отчетов (неограниченное кол-во версий);
 контекстное форматирование данных в отчете;
 экспорт в Excel, Word, PDF и печать на принтере.
Возможности анализа данных:
 сравнение двух и более проектов по стоимостным, количественным параметрам, срокам,
датам;
 сравнение по текущим и целевым планам с фактическими данными;
 анализ
проектов,
иерархической
структуры
работ,
ресурсов,
расходов
в
распределении/группировке по двум и более измерениям (время, статьи затрат, коды,
пользовательские поля и т.д.);
 поддержка временной шкалы год-квартал-месяц;
 расчет значений накопительным итогом;
 определение необходимого уровня декомпозиции.
Технические возможности:
 формирование отчетов с использованием сводных таблиц Excel;
19
3.4.6


интеграция с порталом на платформе Microsoft SharePoint 2007-2010;
автоматическое обновление данных по настроенному расписанию.
4.
СОСТАВ И СОДЕРЖАНИЕУСЛУГ.
4.1
Требования к составу услуг
Функциональные возможности ИСУП расширяются по мере оказания услуг по внедрению очередной
подсистемы. Внедрение идет поэтапно и сопровождается разработкой нормативно-методической
документации, регламентирующей работу в системе. Этапы выполняются на пилотном
организационном объеме в соответствии с Графиком оказания услуг.
Проекты документов и получаемых решений, подготавливаемых на каждой стадии, предоставляются
на предварительную экспертизу и согласование по мере их готовности во время оказания услуг по
этапу. Окончательное согласование регламентирующей документации и представляемых решений
проводится по окончании этапа внедрения, одновременно со сдачей результатов оказания услуг по
этапу.
Оказание услуг выполняется в соответствии с действующими стандартами в рамках единого
технического проекта на ИСУП и последующей разработкой частных технических заданий и рабочих
проектов на дополнительные модули ИСУП.
Результаты и этапы проекта.
4.2
№ п/п
Этап 1
1.1.
Наименование услуги
Отчетные материалы
Предпроектное обследование.
Разработка отчета о проведении Документ:
предпроектного обследования.
Отчет о проведении предпроектного обследования
Документы:
Концепция ИСУП;
1.2.
Разработка
концепции Технический проект на внедрение;
информационной
системы
Реестр справочников ИСУП;
управления проектами.
Реестр шаблонов документов ИСУП;
Реестр моделей ИСУП
1.3.
Этап 2
Описание
основных
бизнес Документ:
процессов верхнего уровня.
Описание основных бизнес-процессов верхнего уровня
Развертывание ИСУП. Модуль «Календарно-сетевое планирование».
Документы:
Частное техническое задание
Положение о проектном офисе;
2.1.
Разработка НМД.
Положение о руководителе проекта;
Положение об администраторе проекта;
Положение о группе реализации проекта;
Регламенты планирования и ведения графиков в
20
ИСУП;
Регламент взаимодействия внутренних и внешних
участников проекта;
Регламент рабочих процессов календарного
планирования и контроля;
Положение о предоставлении фактической
информации о выполнении работ;
Методика КСП;
Регламент внесения изменений в КСГ;
Инструкции пользователей ИСУП в соответствии с
проектными ролями;
Инструкция администратора системы;
Требования к качеству КСГ;
Методика оценки качества ведения КСГ
Поставка сервера с инфраструктурой;
Предоставление лицензий ПО;
Документ:
2.2.
Развертывание и настройка ПО.
Блок-схема с описанием архитектуры системы
Протоколы:
протокол настроек инфраструктуры;
протокол установки ПО
Справочники:
Справочник «Статьи затрат»;
Справочник «Объекты учета»;
Справочник «Договора»
2.3.
Создание
справочников, Шаблоны:
шаблонов документов, кодов
применительно
к
проектам Шаблоны типовых результатов и документов;
развития ТПУ.
Типовые СДР проектов по направлениям;
Типовые ключевые события/контрольные точки
проектов по направлениям
Коды:
Реестр кодов
Этап 3
Развертывание ИСУП. Модуль «Проектное бюджетирование».
Документы:
3.1.
Разработка НМД.
Частное
Техническое
задание;
21
«Положение о проектном бюджетировании»;
«Регламенты проектного бюджетирования»;
«Регламент взаимодействия подразделений
«МКЖД» при подготовке бюджетов»;
ОАО
Регламент взаимодействия подразделений
«МКЖД» при работе с модулем;
ОАО
Справочники статей затрат,
бюджетных классификаторов;
объектов
учета,
БДР, БДДС;
Документы:
«Блок-схема с описанием архитектуры модуля»;
3.2.
Развертывание и настройка ПО.
Протоколы:
протокол настроек инфраструктуры модуля;
протокол установки ПО;
документирование настроек модуля.
Этап 4
4.1.
Развертывание ИСУП. Интеграция с 1С.
Описание
схемы
ключевых Частное Техническое задание;
сущностей и мастер систем
Интеграционное решение по автоматизации обмена
данными с 1С: «Модуль интеграции с 1С»
Документы:
Схема ключевых сущностей и мастер систем;
4.2.
Разработка и развертывание
План интеграции;
модуля интеграции с 1С
Спецификация на модуль интеграции с 1С
Протоколы:
Протокол установки модуля интеграции с 1С
Этап 5
5.1.
Этап 6
Развертывание ИСУП (Аналитическая отчетность)
Разработка отчетных форм.
Документы:
Реестр отчетных форм
Развертывание ИСУП (Проектный портал)
Частное Техническое задание.
Развернутый проектный портал.
6.1.
Развертывание портала и
настройка ПО.
Документ:
Спецификация на настройку сайтов;
Протокол развертывания проектного портала.
6.2.
Адаптация дизайна.
Документ:
22
Спецификация на адаптацию дизайна
6.3.
Этап 7
Хранилище документов, включая
документооборот.
Документ:
Спецификация на хранилище документов
Опытная эксплуатация
Документы:
Технический проект ИСУП
Регламент ведения справочников ИСУП
7.1.
Разработка
документации ИСУП.
рабочей
Регламент штатного и аварийного обслуживания
ИСУП
Руководство Администратора
Руководство Пользователя
Регламент ввода ИСУП в эксплуатацию
Протоколы:
Протокол документирования настроек ИСУП
Документы:
Программа проведения испытаний ИСУП;
Журнал опытной эксплуатации.
7.2.
Опытная эксплуатация ИСУП.
Протоколы:
Протокол проведения ОЭ;
Протокол устранения замечаний по результатам
ОЭ;
Протокол проведения испытаний;
Документы:
7.3.
Разработка программы обучения
и проведение обучения.
Программа обучения пользователей ИСУП с медиа
материалами;
протокол проведения обучения;
сертификаты слушателей курсов.
4.3
Функциональные требования к результатам услуг.
Результаты услуг должны соответствовать поставленным целям и задачам, базироваться на
достоверных данных и источниках информации, соответствовать нормам и правилам
законодательства Российской Федерации.
Этап 1. Предпроектное обследование.
Основные бизнес-процессы верхнего уровня должны быть описаны до той степени детализации,
когда обозначаются переходы зон ответственности между отделами и подразделениями. Они
должны содержать графическую часть (схемы и диаграммы) и текстовую часть (пояснительную
записку). Бизнес-процессы по этапу комплексной реорганизации территорий и оформления ТПУ
должны быть описаны детально до уровня ответственных сотрудников.
23
При описании бизнес-процесса использовать текстовый, табличный и графический вид со ссылкой
на нормативную документацию. На верхнем уровне в обязательном порядке должны быть
определены:





комплексная реорганизация территорий и оформление ТПУ;
сбор исходно-разрешительной документации;
проектно-изыскательские работы;
строительно-монтажные работы;
монетизация земельных участков.
Отчет о проведении предпроектного обследования должен содержать информацию о
результатах аудита нормативно-методического, организационного обеспечения, с целью
выявления ключевых проблем и определения основных направлений совершенствования.
В рамках подготовки отчета необходимо посредством интервью провести анализ существующих
бизнес-процессов управления проектами охваченных каждой подсистемой:










определить основные потребности ОАО «МКЖД» в части проектного управления и проектного
бюджетирования;
определить основные принципы планирования;
выделить типовые проектные задачи;
определить базовые единицы выполнения работ по операциям;
проанализировать существующие графики выполнения работ;
проанализировать существующие типовые декомпозиции работ;
определить существующие проектные роли;
проанализировать существующие формы отчетности для последующей автоматизации;
разработать бизнес-модели существующих процессов;
проверить адекватность разработанных моделей (утвердить модель в соответствующем
подразделении компании).
Концепция ИСУП должна состоять из следующих разделов и подразделов:





общие сведения;
нормативные ссылки;
терминология и сокращения;
назначение системы;
функциональные требования к модулям ИСУП.
Технический проект включает в себя:
 план технической инфраструктуры;
 детальные требования к информационной системе и ее компонентам;
 техническое задание на интеграцию с существующими и разрабатываемыми
информационными системами;
 проектные решения по интеграции со смежными системами, включая схемы
информационных потоков, импорта и наследования данных, детальные планы реализации
проекта:






план разработки;
план тестирования;
план обучения;
план передачи на сервис;
план внедрения;
план проведения опытно-промышленной эксплуатации.
 сценарии использования системы в бизнес-процессах;
 эскизы пользовательских интерфейсов, отчетных форм, структур данных;
 спецификации на поставку оборудования и лицензий, необходимых для функционирования
системы;
 описание подходов к сервисному обслуживанию системы.
Этап 2. Развертывание ИСУП (Календарно-сетевое планирование) и Этап 3. Развертывание
ИСУП (Проектное бюджетирование),
24
Нормативно-методическую документацию разработать в соответствии с общепринятыми
принципами создания стандартов организации и включает в себя:


















Положение о проектном офисе;
Положение о руководителе проекта;
Положение об администраторе проекта;
Положение о группе реализации проекта;
Регламенты планирования и ведения графиков в ИСУП;
Регламент взаимодействия внутренних и внешних участников проекта;
Регламенты проектного бюджетирования;
Положение о предоставлении фактической информации о выполнении работ;
Методика КСП;
Методика проектного бюджетирования;
Порядок внесения изменений в КСГ;
Инструкции пользователей ИСУП в соответствии с проектными ролями;
Инструкция администратора системы;
Требования к качеству КСГ;
Методика оценки качества ведения КСГ;
Шаблоны однотипных результатов и документов;
Типовые СДР проектов по направлениям;
Типовые ключевые события/контрольные точки проектов по направлениям.
Развертывание и настройка ПО модуля предполагает выполнение следующих видов работ:



закупка лицензий, необходимых для обеспечения работы системы, передача лицензий на баланс
ОАО «МКЖД»;
инсталляция и настройка ПО;
настройка сервера.
Шаблон календарно-сетевых планов должен отражать логические взаимосвязи между задачами,
отраженными в основных бизнес-процессах, а уровень детализации должен быть пригоден для
еженедельного отслеживания статуса по проекту. Шаблон КСП должен удовлетворять
требованиям, зафиксированным в положении о планировании и контроле и положении о
проектном бюджетировании. При подготовке шаблона выполнить следующие действия:




наполнить справочники в соответствии с реестром;
создать в Oracle Primavera календарно-сетевые планы проектов развития ТПУ;
создать в Oracle Primavera бюджеты проектов развития ТПУ;
организовать пилотный сбор фактических данных по проектам через автоматическую рассылку
запросов пользователям системы.
Справочники формировать в единой системе, исключая повторный ввод. Справочники должны
удовлетворять требованиям, зафиксированным в положении о планировании и контроле и
положении о проектном бюджетировании. Перечень справочников с описанием полей должен быть
формализован в реестре справочников:



справочник «Статьи затрат»;
справочник «Объекты учета»;
справочник «Договора».
Этап 4. Интеграция с 1С.
В рамках интеграции с учетной системой 1С решается задача по автоматической загрузке данных
по фактическим затратам в разрезе реализуемых проектов, а также дорабатывается интерфейс по
вводу плана и корректировки факта непосредственно в ИСУП.
Общая схема хранения и обмена данными между 1С и ИСУП выглядит так:
25
1С
Разнесенные по
классификаторам
суммы документов,
справочники
(WEB-сервисы)
ИСУП
Хранилище
разноски
документов
(SQL)
Документы 1с
Обработка обмена 1С
– ИСУП
БК
Классификатор
объектов
Таблица разноски
документов
Таблица регистрации
обмена
Ввод/корректировка справочников,
запись разноски,
запись таблицы регистрации обмена
При разработке механизма интеграции необходимо разработать схему ключевых сущностей и
мастер систем. На схеме должны быть представлены ключевые сущности контура интеграции,
системы в которых они зарождаются, и системы, в которые они должны передаваться в рамках
бизнес процессов.
Этап 5. Разработка отчетных форм.
Отчетная информация должна предоставлять возможность контроля сроков и затрат проектов.
Доступ к отчетности реализовать, в том числе, через web-интерфейс. Обеспечить автоматическое
создание отчетов для различных уровней проектного управления формализованных в реестре
отчетных форм:






прогресс выполнения проектов;
статистика по проектам;
анализ контрольных точек;
отчет по динамическим показателям;
список критических задач;
базовая стоимость и план затрат.
Этап 6. Создание проектного портала.
Проектный портал создается для организации взаимодействий по проектам в рамках рабочих
областей, определяющих круг участников, их роли в проекте и права доступа к информации по
проекту. Доступ к порталу возможен через web-интерфейс.
На портале создать хранилище документов с исходным перечнем документации по проекту и
возможностью согласования документов, регистрации входящей и исходящей корреспонденции.
Этап 7. Опытная эксплуатация.
Перед началом опытной эксплуатации провести обучение пользователей, используя
демонстрационно-методические материалы: как печатные материалы, так и материалы в
электронном формате (методические документы, обучающие курсы и т.п.).
26
Пользователей, прошедших обучение, фиксировать в специальном протоколе и выдавать
сертификаты о прохождении обучения.
Цель проведения опытной эксплуатации – продолжительная проверка функционального
соответствия системы на продуктивных данных и выявление замечаний к системе в целом. По
результатам сформировать предложения по актуализации или изменению Технического проекта и,
как следствие, внесению изменений в систему.
Опытная эксплуатация подразумевает работу группы эксплуатации в системе с использованием
продуктивных данных и включает в себя:
 выявление и устранение дефектов и замечаний;
 подготовку системы к переводу в промышленную эксплуатацию;
 участие Исполнителя в сервисной поддержке пользователей системы;
 разработку рабочей документации в составе:



настройки инфраструктуры системного ландшафта;
настройки архитектуры системного ландшафта;
разработки и настройки системы, включая:



описание непереносимых настроек;
описание настройки межсистемных интерфейсов;
реестр и спецификации разработок;
 программы и методики испытаний, включая тестовые сценарии.
В состав группы эксплуатации входят пользователи ИСУП в соответствии с утвержденной
ролевой моделью. Перед началом работ оформить журнал опытной эксплуатации, содержащий
замечания/предложения пользователей к работе системы управления, к документации на систему
управления.
Результаты: готовность к передаче системы в промышленную эксплуатацию. Критерии
готовности:








система установлена и настроена на оборудовании Заказчика в соответствии с утвержденным
Техническим проектом;
разработаны, согласованы и утверждены Заказчиком результирующие документы:
протокол завершения опытной эксплуатации (включая реестр замечаний и отчет о ходе ОЭ);
протокол устранения замечаний по результатам ОЭ;
протокол проведения миграции данных в продуктивную среду;
актуализирован технический проект на систему;
актуализирована программа и методика испытаний;
актуализированы операционные инструкции пользователей;
По итогам опытной эксплуатации сформировать перечень замечаний и предложений, по
доработке ИСУП. Перечень оформить в отчете о проведении опытной эксплуатации. По
результатам устранения замечаний подписать протокол проведения опытной эксплуатации.
5.
ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ.
Для обеспечения проведения испытаний создается комиссия. В состав комиссии входят
представители Заказчика и Исполнителя.
Испытания представляют собой процесс проверки выполнения заданных функций системы,
выявления и устранения недостатков в программном обеспечении, оборудовании и документации.
Для проверки выполнения заданных функций системы устанавливаются следующие виды
испытаний:
1. опытная эксплуатация;
2. приемо-сдаточные испытания.
Опытную эксплуатацию ИСУП проводят с целью определения фактических значений
количественных и качественных характеристик системы и готовности персонала к работе в
условиях функционирования системы, определения фактической эффективности системы,
корректировки (при необходимости) документации.
Приемо-сдаточные испытания ИСУП проводят для определения соответствия ее техническому
заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки ИСУП
в промышленную эксплуатацию. Для планирования каждого из перечисленных видов испытаний
разрабатывается документ «Программа и методика испытаний», определяющий состав, объем и
27
методы испытания ИСУП. Испытания проводятся на технических средствах Заказчика. Допускается
использовать технические средства, находящиеся на момент проверки в эксплуатации. Работы по
проведению испытаний не должны оказывать влияния на функционирование подсистем ИСУП, не
участвующих в испытаниях.
Проверке подлежат:





качество выполнения ИСУП своих функций во всех режимах функционирования согласно
техническому заданию;
знание персоналом эксплуатационной документации и наличие у него навыков, необходимых для
выполнения установленных функций во всех режимах функционирования системы, согласно
техническому заданию;
полноту содержащихся в эксплуатационной документации указаний персоналу по выполнению им
функций во всех режимах функционирования системы согласно техническому заданию;
количественные и/или качественные характеристики выполнения автоматизированных функций
системы в соответствии с техническим заданием;
другие свойства системы, которым она должна соответствовать по техническому заданию.
5.1
Опытная эксплуатация.
На подготовительном этапе Заказчик издает приказ о проведении опытной эксплуатации с указанием
ответственных лиц и сроков ее проведения.
Опытную эксплуатацию проводят в соответствии с программой, в которой указывают:



условия и порядок функционирования частей системы и ИСУП в целом;
продолжительность опытной эксплуатации, достаточную для проверки правильности
функционирования ИСУП при выполнении каждой функции системы и готовности персонала к
работе в условиях функционирования системы;
порядок устранения недостатков, выявленных в процессе опытной эксплуатации.
Во время опытной эксплуатации ведется рабочий журнал, в который заносят сведения о
продолжительности функционирования системы, отказах, сбоях, аварийных ситуациях, изменениях
параметров объекта автоматизации, проводимых корректировках документации и программных
средств, наладке технических средств. Сведения фиксируют в журнале с указанием даты, времени,
условий проявления и лица, обнаружившего ошибку. Исполнитель фиксирует факт устранения
ошибки. В журнал могут быть занесены замечания персонала по удобству эксплуатации системы.
Сведения из рабочего журнала о проведении опытной эксплуатации системы должны поступать
координатору со стороны Заказчика, который предъявляет их Исполнителю на обработку и анализ.
По результатам опытной эксплуатации принимают решение о возможности (или невозможности)
предъявления ИСУП на приемочные испытания.
Работа завершается оформлением акта о завершении опытной эксплуатации и допуске системы к
приемочным испытаниям. По завершении этапа опытной эксплуатации с Заказчиком
подписываются следующие документы:


акт о проведении опытной эксплуатации;
рабочий журнал опытной эксплуатации.
5.2
Приемо-сдаточные испытания.
Для проведения приемочных испытаний должна быть предъявлена следующая документация:



техническое задание на создание системы;
рабочие журналы опытной эксплуатации;
протокол завершения опытной эксплуатации.
Результаты проведения приемочных испытаний фиксируют в протоколе, на основании которого
делают заключение о соответствии системы требованиям технического задания на ИСУП.
ТРЕБОВАНИЯ К ТЕСТИРОВАНИЮ И ИСПЫТАНИЯМ ИСУП.
6.
Подготовка и проведение испытаний должны включать в себя:





подготовку и настройку тестовой инфраструктуры Заказчика;
развертывание системы в тестовой среде Заказчика;
загрузку массива тестовых данных в тестовую среду Заказчика. Массив тестовых данных готовит
Исполнитель и согласовывает с Заказчиком;
разработка документации в соответствии с требованиями ОАО «МКЖД»;
проведение испытаний системы.
6.1
Функциональное тестирование.
28
Цель тестирования – проверка функционального и интеграционного соответствия системы
Техническому заданию. Проверке подлежат как отдельные компоненты системы и взаимосвязи
между ними, а также взаимосвязи с внешними, по отношению к тестируемой, системами.
Тестирование является обязательным, проводится в присутствии и на территории Заказчика.
Результаты оформляются протоколом проведения испытаний.
Тестирование проводится в соответствии с разработанной программой и должно содержать
проверку всех функций подсистем в соответствии с Техническим заданием, в том числе проверку
взаимодействия между подсистемами.
Интеграционное тестирование.
6.2
Цель тестирования - проверка корректности реализации интерфейсного взаимодействия между
модулями системы (выполняет Заказчик в присутствии Исполнителя); проверка корректности
функционирования реализованных интеграционных механизмов со смежными системами
(выполняет Исполнитель в присутствии Заказчика).
Результаты тестирования:





6.3
проведены все предусмотренные испытания системы;
подтверждено соответствие созданной системы Техническому проекту;
разработаны, согласованы экспертной группой и утверждены Заказчиком результирующие
документы:
протокол приемо-сдаточных испытаний системы, включая протоколы всех видов проведенных испытаний;
реестр замечаний ИТ-системы с указанием категории замечания и планового срока устранения.
Требования по подготовке объекта.
Исполнитель выполняет следующие работы по подготовке объекта автоматизации для выполнения
проекта:
 развертывание тестовой среды;
 развертывание продуктивной среды;
 консультации пользователей ИС в объеме, достаточном для самостоятельной работы с
системой;
 настройка оборудования, установка системного и пользовательского ПО, настройка ПО,
организация доступов.
6.4
Требования к опытной эксплуатации ИСУП.
Проведение опытной эксплуатации ИСУП включает в себя:
 настройку титульных списков строительства;
 составление и наполнение корпоративных справочников в объеме проведения опытной
эксплуатации;
 распределение и предоставление прав доступа пользователей к ИСУП;
 описание процедур постановки задач конечным исполнителям на основании введенных в
КСП операций, а также процедур формирования отчетности;
 настройку стандартных форм отчетности;
 обеспечение пользователей справочной информацией по работе в ИСУП;
 сопровождение пользователей ИСУП при выполнении задач в процессе проведения
опытной эксплуатации;
Опытная эксплуатация проводится на всех этапах на всем пилотном организационном объеме
проекта. Требования предъявляются к каждому этапу. Исполнитель осуществляет
консультационную поддержку пользователей ИСУП на протяжении опытной эксплуатации.
6.5
Требования к технической и эксплуатационной документации.
Разработанная система передается Заказчику с комплектом технической проектной и
эксплуатационной документации. Исполнитель по результатам оказанных услуг предоставляет
полный комплект документов, необходимых для эксплуатации ИСУП и отражающих текущее
состояние ИСУП при ее сдаче в промышленную эксплуатацию.
Техническая проектная документация создается на основе Технического проекта, который
разрабатывается на этапе 1 и уточняется Исполнителем в ходе последующих этапов создания
системы. Как часть результатов работ по проекту должна быть передана следующая основная
документация:
29
 Технический проект на систему в составе:




требования к качеству данных для расчетных модулей, возможность интеграционного
взаимодействия, схема информационных потоков с учетом инфраструктуры Компании;
концептуальный дизайн с описанием алгоритмов, методик, используемых в системе. В
документе должен быть представлен проект интерфейса системы, форматов аналитических
и отчётных форм;
процессный дизайн с отражением карт бизнес-процессов с описанием соответствия им
функциональных подсистем\блоков; описанием информационных потоков, рекомендации по
оптимизации бизнес-процессов;
концепция ролей и полномочий с описанием каждой роли.
 Программа и методика проведения ОЭ;
 Программа и методика проведения консультаций (обучения), содержащая график проведения
обучения, перечень тем, обучающие материалы. Перечисленная информация должна быть
представлена в разрезе ролевой модели системы (в т.ч. персонала, отвечающего за
сопровождение системы);
 Паспорт системы, включая:



описание результирующей архитектуры решения в т. ч. описание организационной
инфраструктуры;
описание непереносимых настроек;
описание настройки межсистемных интерфейсов;
 Протокол развертывания Системы на объектах Заказчика и загрузки данных, включая реестр
замечаний;
 Протокол проведения консультаций (обучения) пользователей;
 Программа и методика проведения приемочного сдаточных испытаний, включая тестовые
сценарии для всех требуемых видов тестирования с описанием:



основных принципов и порядка тестирования;
методики оценки функционала и загрузки первоначальных данных;
сценариев тестирования с указанием пошаговых действий пользователя и ожидаемых
результатов в системе;
 Протокол проведения приемо-сдаточных испытаний разработанной системы, включая реестр
замечаний;
 Протокол устранения замечаний, выявленных в результате ПСИ.
7. ГАРАНТИЙНЫЕ ОБЯЗАТЕЛЬСТВА.
Срок гарантийных обязательств (качество и корректность подготовленной документации) должен
составлять 12 месяцев.
Выполнение работ в соответствии с гарантийными обязательствами:

Осуществление работ по устранению недостатков, выявленных при эксплуатации ИСУП в
течении установленных гарантийных сроков, внесению необходимых изменений в
техническую документацию.

Исполнитель не гарантирует отсутствие недостатков или сбоев в процессе работы,
возникающих по причине несоответствия оборудования или установленного на рабочем
месте программного обеспечения конечного пользователя требованиям, предъявляемым к
характеристикам клиентских мест.
8. ПОРЯДОК ВНЕСЕНИЯ ИЗМЕНЕНИЙ В ТЕХНИЧЕСКОЕ
ЗАДАНИЕ.
Настоящее техническое задание может корректироваться в процессе разработки ИСУП по
договоренности сторон.
Не допускается вносить изменения в техническое задание после представления системы на
приемо-сдаточные испытания.
9. ОБЯЗАТЕЛЬНЫЕ УСЛОВИЯ ПРИ ОКАЗАНИИ УСЛУГ.
30

Исполнителем должно быть организовано взаимодействие с Заказчиком через одно
ответственное лицо.
Заказчик вправе потребовать замены ответственных сотрудников со стороны Исполнителя.
По результатам каждой рабочей встречи Исполнитель должен представлять Заказчику
документ, фиксирующий достигнутые договоренности (протокол встречи).
Исполнитель гарантирует качество и безопасность услуг, используемого оборудования,
программного обеспечения и материалов в соответствии с действующими стандартами,
утвержденными на данный вид оборудования, программного обеспечения, материалов,
услуг, работ и наличием сертификатов, обязательных для данного вида работ/услуг,
оборудования, программного обеспечения и материалов, оформленных в соответствии с
законодательством Российской Федерации.
Услуги, оказываемые Исполнителем, а также применяемые методы контроля качества этих
услуг должны строго соответствовать требованиям производителей обслуживаемых систем,
программ и производится компетентными в данном виде услуг специалистами Исполнителя.
Исполнитель обязан по первому требованию Заказчика предоставить письма от
производителей и копии сертификатов технических специалистов, подтверждающие
соответствие используемых методов и регламентов требованиям производителей
оборудования.
Услуги, оказываемые Исполнителем, не должны повлечь за собой утрату гарантийных
обязательств со стороны производителя (поставщика).
Исполнитель должен гарантировать, что устанавливаемые на объектах Заказчика в ходе
оказания услуг оборудование, программное обеспечение и материалы свободны от прав
третьих лиц.






10.
ТРЕБОВАНИЯ К ОРГАНИЗАЦИОННОМУ ОБЕСПЕЧЕНИЮ.
Для разработки и внедрения информационной системы управления проектами (далее - Проект),
создается следующая структура:
 руководители проекта от ОАО «МКЖД» и от исполнителя;
 рабочая группа.
10.1 Руководители проекта от Заказчика и Исполнителя.
Руководитель проекта со стороны Заказчика совместно с руководителем проекта от Исполнителя
выполняет оперативное управление проектом и контролирует выполнение задач рабочей группой.
Функциональные обязанности:
 участие во всех этапах проекта;
 обеспечение готовности инфраструктуры, необходимой для реализации проекта;
 обеспечение выделения ресурсов Заказчика, необходимых для реализации проекта;
 участие в решении оперативных вопросов, связанных с проектом.
Главной обязанностью руководителя проекта от Исполнителя является обеспечение полного
выполнения всех обязательств перед Заказчиком. Руководитель проекта выполняет оперативное
управление проектом и отчитывается по состоянию проекта перед управляющим комитетом.
Функциональные обязанности:
 разработка детального плана и расписание проекта на каждый блок работ;
 контроль и обеспечение прогресса в достижении целей проекта;
 назначение и планирование использования ресурсов в проекте;
 проведение совещаний по ходу проекта;
 отчетность перед руководством Заказчика по состоянию хода проекта;
 обеспечение своевременного решения вопросов и проблем, возникающих в ходе проекта;
 управление составом работ и изменениями в проекте.
10.2
Состав рабочей группы.
31
Для оказания услуг по проекту Исполнитель должен организовать интегрированную рабочую
группу. Поименный состав участников рабочей группы и перечень специалистов Исполнителя
утверждается Заказчиком в начале проекта и может пересматриваться в ходе оказания услуг по
проекту.
Непосредственное руководство рабочей группой осуществляется руководителем проекта со
стороны Исполнителя.
10.3
Оперативные совещания рабочей группы.
Для контроля хода проекта проводятся оперативные совещания, возглавляемые руководителем
проекта от Исполнителя. В совещании участвует руководитель проекта со стороны Заказчика,
который докладывает о статусе оказания услуг (включая существующие проблемы и риски).
Оперативные совещания, как правило, проводятся еженедельно. Периодичность проведения
оперативных совещаний может изменяться по согласованию руководителей проекта от Заказчика и
Исполнителя.
В стандартную повестку дня совещания включаются следующие вопросы:
 контроль выполнения задач, поставленных на предыдущих совещаниях;
 выполнение плана проекта;
 рассмотрение и решение возникших вопросов и проблем.
По результатам совещаний руководитель проекта со стороны Исполнителя готовит протокол
совещания, форма которого разрабатывается Исполнителем и утверждается в начале проекта.
Протокол совещания согласовывается с руководителем проекта от Заказчика. Согласованный
протокол доводится до сведения всех заинтересованных лиц в команде проекта.
10.4 Совместные рабочие совещания.
При необходимости решения вопросов комплексного характера, затрагивающих предметные
области различных направлений, их рассмотрение выполняется на совместных рабочих совещаниях
с участием представителей соответствующих структурных подразделений Заказчика или их
представителей. Эти совещания не носят периодического характера, а проводятся по предложению
руководителя проекта со стороны Заказчика или Исполнителя. Организация рабочих совещаний
осуществляется руководителем проекта от Заказчика.
10.5 Уточнение планов оказания услуг.
Ввиду сжатых сроков реализации проекта вводится процедура ежедневного уточнения планов
оказания услуг. Исполнитель ежедневно согласовывает с Заказчиком детальные планы работ и по
результатам работы за день докладывает о достигнутых результатах. При необходимости,
согласование планов закрепляется совместным протоколом заседания рабочей группы проекта.
Достижение результатов проекта фиксируется в отчетных материалах.
10.6 Управление изменениями.
Непредвиденные изменения, касающиеся функциональных рамок проекта, организационной
структуры проекта или проектных процедур, должны осуществляться с детальной оценкой
последствий для проекта (включая сроки и бюджет) при полной поддержке и согласовании их с
руководителями проекта. Для принятия решения о внесении изменений в рамки проекта или их
отклонении необходимо, чтобы предлагаемые изменения были правильно поняты, между ними
расставлены приоритеты и оценена их стоимость. Любое изменение, не способствующее целям
проекта, должно быть объявлено как выходящее за рамки проекта.
К проектным относятся изменения:
 функциональных требований;
 состава работ, либо перечня услуг;
 сроков проекта, отраженных в договоре;
 бюджета проекта.
32
Запрос на изменение может поступить от членов рабочей группы, руководителя проекта со стороны
Заказчика или руководителя проекта со стороны Исполнителя или других уполномоченных на это
должностных лиц Заказчика в соответствии со следующей процедурой:








инициатор запроса на изменение готовит обоснование и направляет запрос на изменение
руководителю проекта со стороны исполнителя в письменном виде;
запрос на изменение регистрируется;
руководство проекта рассматривает запрос на изменение и назначает ответственного
исполнителя по подготовке предложений и проекта решения по данному запросу;
ответственный исполнитель готовит предложения и проект решения по данному запросу,
включая оценку последствий данных решений и их влияния на сроки, ресурсы и бюджет
проекта;
ответственный исполнитель передает предложения и проект решений руководителю проекта со
стороны исполнителя;
руководство проектом анализирует данный запрос и проект решения по нему, и, либо
отправляет его на доработку ответственному исполнителю, либо выносит его на рабочее
совещание;
руководители проекта рассматривают данный запрос и проект решения. По результатам
рассмотрения данного запроса проект решения либо принимается, либо предоставляются
обоснованные причины отказа;
запрос на изменение передается для хранения в архиве проектной документации.
33
СУБЛИЦЕНЗИОННОЕ СОГЛАШЕНИЕ
1. ОСНОВНЫЕ ПОНЯТИЯ И ТЕРМИНЫ
Лицензиат –
«____________», заключившее Лицензионный договор (контракт) на
осуществление конкретного вида деятельности или отчуждение объекта интеллектуальной
собственности.
Официальный дистрибьютор – организация, осуществляющая продажу товаров,
приобретаемых по договору с определенным производителем на долгосрочной основе.
Дистрибьюторы обладают преимущественным правом и возможностями приобретать и продавать
оборудование, технические новинки, программное компьютерное обеспечение.
Сублицензиат – ОАО «Московская кольцевая железная дорога», приобретающее у
Лицензиата в рамках настоящего Договора простое неисключительное право на использование
Программного продукта/Программных продуктов (копии программного продукта/копии
программных продуктов) с правом его/их коммерческого использования.
Правообладатель (Лицензиар) – сторона в Лицензионном договоре, разработавшая
Программный продукт, а потому имеющая на него все права и назначающая официального
дистрибьютора, Лицензиата, имеющего право на продажу конечному пользователю, Сублицензиату
простого неисключительного права пользования копией программного продукта.
Программный продукт (копия программного продукта) – самостоятельное, отчуждаемое
произведение, представляющее собой публикацию текста программы или программ на языке
программирования или в виде исполняемого кода.
Простое неисключительное право на использование Программного продукта (копии
Программного продукта) – лицензия, предоставляющая право использования Программного
продукта (копии программного продукта), исключающее самостоятельное внесение в него
изменений и его копирование (далее Лицензия).
Коммерческое использование Программного продукта (копии программного продукта) –
использование Сублицензиатом по своему усмотрению Программного продукта (копии
программного продукта), простое неисключительное право на который он приобретает согласно
условиям настоящего Договора, любым из разрешенных способов, прямо указанных в настоящем
Договоре, не исключая возможности получения Сублицензиатом материальной выгоды
(Коммерческая лицензия).
2. ПРЕДМЕТ СОГЛАШЕНИЯ
2.1. Предмет
соглашения – предоставление Лицензиатом Сублицензиату простого
неисключительного права на использование Программного продукта, установленного на
материальном носителе, с правом его коммерческого использования (коммерческая лицензия
Программного продукта) согласно Спецификации, являющейся неотъемлемой частью настоящего
Соглашения (Приложение № 1 к Соглашению).
2.2. Лицензиат передает ОАО «МКЖД» Программный продукт на Материальном носителе,
позволяющие Сублицензиату реализовать предоставленное ему право.
2.3. Лицензиат
предоставляет Сублицензиату простое неисключительное право на
использование лицензии Программного продукта, установленного на материальном носителе,
согласно Спецификации (Приложение № 1 к Соглашению), в бессрочное пользование.
34
2.4. Лицензиат гарантирует Сублицензиату наличие у него преимущественных прав на
Программный продукт, простое неисключительное право, на использование которого, Лицензиат
предоставляет Сублицензиату по настоящему Договору.
2.5. Правообладателем исключительных имущественных прав на Программный продукт
является компания – производитель Oracle, Microsoft.
Лицензиат предоставляет неисключительные права на Программный продукт на основании
лицензионного договора, заключенного с Правообладателем (Победитель закупочных процедур
обязан указать данные лицензионного договора (номер и дату договора)).
2.6. Лицензиат
гарантирует соответствие предоставляемого Программного продукта
параметрам и возможностям, декларируемым компанией-производителем Oracle, Microsoft.
3. ПРЕДЕЛЫ ПЕРЕДАВАЕМЫХ ПРАВ
3.1. Права на использование Программного продукта передаются в следующем объеме:
использование путем воспроизведения программ для ЭВМ, ограниченного инсталляцией,
копированием и запуском программ для ЭВМ в соответствии с лицензионным соглашением для
конечного пользователя, предоставляемое с единственной целью передачи права использования
этим способом конечным пользователям, находящимся на территории России. При этом право на
использование программы для ЭВМ, в отношении которого предоставляется простая
(неисключительная) лицензия, ограничено пределами, предусмотренными лицензионным
соглашением для конечного пользователя, ознакомление с которым происходит в момент
установки/активации соответствующего Программного продукта.
3.2. Сублицензиату предоставляется простое неисключительное право на использование
Программного продукта, указанного в Спецификации (Приложение №1 к Соглашению), без права
его копирования. Установка дистрибутива Программного продукта разрешена на количество
компьютеров Сублицензиата, указанное в Спецификации (Приложение №1 к Соглашению).
Также Сублицензиату передается в собственность материальный носитель, на который
установлен Программный продукт, указанный в Спецификации (Приложение № 1 к Соглашению).
3.3. Предоставление права использования Программного продукта сопровождается
передачей Сублицензиату лицензионной копии Программного продукта на материальном носителе,
указанном в Спецификации (Приложение № 1 к Договору) и неисключительной лицензии на
использование Программного продукта в порядке, предусмотренном разделом 6 настоящего
Соглашения.
3.4. Экземпляр Программного продукта предоставляется Сублицензиату без права его
передачи третьим лицам.
3.5. Сублицензиат имеет право на передачу третьим лицам результатов моделирования,
полученных Сублицензиатом с помощью Программного продукта.
3.6. Настоящее соглашение не предоставляет Сублицензиату права:
а) передавать права на Программный продукт третьим лицам;
б) разрешать третьим лицам использовать Программный продукт, установленный на
компьютере Сублицензиата.
в) предпринимать какие-либо попытки самостоятельного получения исходных текстов
Программного продукта или алгоритмов его работы.
4. КОНТРОЛЬ ИСПОЛЬЗОВАНИЯ
35
4.1. Сублицензиат обязан принимать все меры для предотвращения неавторизированного
использования Программного продукта, не допускать к работе с Программным продуктом
посторонних лиц, не обладающих полномочиями, предоставленными Лицензиатом или компаниейпроизводителем Oracle, Microsoft.
5. СТОИМОСТЬ И ПОРЯДОК РАСЧЕТОВ
5.1. Вознаграждение за предоставление (передачу) права на использование Программного
продукта составляет _______ (_____________) рублей __ копеек, НДС не облагается (в соответствии
с п.п.26, п.2, статьи 149 НК РФ). Сумма вознаграждения является твердой и не может изменяться в
ходе исполнения Договора.
5.2. Стоимость материального носителя, на котором установлен Программный продукт
определен в Спецификации (Приложение №1 к Соглашению) и составляет ________ (________)
рублей 00 копеек, в том числе НДС 18 % ____ (____) руб. __ коп.
5.3. Оплата вознаграждения и стоимости материального носителя осуществляется
Сублицензиатом в течение 5 (пяти) рабочих дней с момента подписания Акта приема-передачи
Программного продукта и простого неисключительного права на использование лицензии, а также
Акта приема-передачи материального носителя, указанного в Спецификации (Приложение №1 к
Соглашению) на основании выставленного счета Лицензиатом по безналичному расчету
платежными поручениями путем перечисления денежных средств на расчетный счет Лицензиата,
указанный в разделе 14 Договора.
6. ПОРЯДОК ПРЕДОСТАВЛЕНИЯ
6.1. Передача и получение Программного продукта и простого неисключительного права на
его использование производится в течение 5 (пяти) рабочих дней со дня подписания Сторонами
настоящего Договора, приложением к которому является данное Соглашение.
6.2. Сублицензиат подписывает Акт приема-передачи Программного продукта и простого
неисключительного права на использование лицензии или же дает мотивированный отказ от
подписания Акта в день передачи Программного продукта.
В последнем случае Сторонами в трехдневный срок составляется двухсторонний акт с
перечнем необходимых доработок и сроков их выполнения.
В случае если недостатки
Программного продукта так и не будут устранены Лицензиатом в установленный срок, то
Сублицензиат имеет право расторгнуть Договор и возложить на Лицензиата возмещение убытков,
причиненных расторжением Договора.
6.3. Передача и получение материального носителя, на который установлен Программный
продукт, оформляется Актом о приеме-передаче.
6.4. Сублицензиат обязуется предпринять все надлежащие меры, обеспечивающие принятие
простого неисключительного права на использование лицензии Программного продукта,
предоставляемого Лицензиатом.
36
Приложение № 1 к Сублицензионному соглашению
СПЕЦИФИКАЦИЯ
№ Наименование
Количество
п/п
1 Windows Server Standard 2012 R2
2 Windows Server User CAL
3 Windows RDS User CAL (Terminal)
4 SQL Server Standard 2014 Core (на 2 ядра)
5 Sharepoint 2013
6 SharePoint Server User CAL
7 SharePoint Server User CAL Enterprise
8 Primavera P6 Enterprise Project Portfolio Management 15.1
9 Primavera P6 Enterprise Project Portfolio Management Web Services
ИТОГО:
1
2
3
4
5
6
7
8
9
10
11
12
13
SuperMicro X9DAi-B Xeon
2xLGA2011/iC602/16xDDR3/8xSATA+2xSATA3/3xPCI-E x16/2lan/Audio/eATX
OEM
SERVER CHASSIS ACC HEATSINK/PASSIVE SUPERMICRO
Case Supermicro CSE-826E16-R1200LPB (Black) 2U Rack, 12x3.5"SAS2/SATA
HSW, Expander, 1200W 1+1
Intel® Xeon® Processor E5-2643 v2 (25M Cache, 3.50 GHz) 6Cores
LSI00417 Контроллер LSI 9361-8I SGL 12Gb/s, RAID 0/1/10/5/6/50/60, 8i ports, 1Gb
Kingston DDR3 16GB ECC Reg PC3L-12800 KVR16LR11D4/16 (1600MHz, CL11,
2R, X4, 1.35V)
Adaptec ACK-I-HDmSAS-HDmSAS-0.5M (2282200-R) Кабель SAS внутр., 50см.,
разъемы SFF8643 -to- SFF8643
SERVER ACC HDD TRAY HOT-SWAP/MCP-220-00043-0N SUPERMICRO
SSD 400 Gb SATA 6Gb/s Intel DC S3710 Series <SSDSC2BA400G401> 2.5"MLC
HDD SAS Seagate 6000Gb (6Tb), ST6000NM0024, Enterprise Capacity 3.5, SAS
12Gb/s, 7200 rpm, 128Mb buffer
LSI00290 (HW Key) CacheCade® Pro 2.0
LSI00418 LSICVM02 CacheVault flash cache protection module
ИБП IPPON SMART Winner 3000 New
14 MS Electric MS-GF50VA / MU-GF50VA / -40
Генеральный директор
2
2
3
1
1
30
30
5
10
1
2
1
2
1
16
2
2
2
6
1
1
1
1
Зотов А.В
37
Скачать