Приложение к Извещению о проведении открытого запроса коммерческих предложений

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

выполнение работ по разработке ПО «Система сопровождения Договора о присоединении» и оказание услуг по сопровождению ПО

Москва, 2020

Оглавление

1. Порядок проведения запроса коммерческих предложений.......................................2. Требования к продукции................................................................................................3. Критерии и порядок оценки заявок (коммерческих предложений). Определение победителя закупочной процедуры...............................................................4. Требования к участникам запроса коммерческих предложений. Подтверждение требований.....................................................................................................5. Проект договора...............................................................................................................

2

1. ПОРЯДОК ПРОВЕДЕНИЯ ЗАПРОСА КОММЕРЧЕСКИХ ПРЕДЛОЖЕНИЙ

1.1. Ассоциация «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью» (Ассоциация «НП Совет рынка», место нахождения в соответствии с Уставом: 123610, г. Москва, Краснопресненская набережная, д. 12, подъезд 7, этаж 7 и 8, приглашает юридических лиц и индивидуальных предпринимателей к участию в открытом запросе коммерческих предложений на выполнение работ по разработке программного обеспечения «Система сопровождения Договора о присоединении» и оказание услуг по сопровождению программного обеспечения.

1.2. Порядок проведения запроса коммерческих предложений указан в разделе 1, критерии и порядок оценки коммерческих предложений (заявок) и определения победителя закупочной процедуры – в разделе 2 настоящей Закупочной документации. В разделе 3 настоящей Закупочной документации приведены требования к участникам запроса коммерческих предложений и порядок подтверждение данных требований. В разделе 4 настоящей Закупочной документации представлен проект Договора.

1.3. В коммерческих предложениях (заявках) на первой (титульной) странице в обязательном порядке указывается Общая стоимость работ и услуг по Договору, в том числе НДС (20%), которая согласно Закупочной документации является критерием оценки коммерческих предложений (заявок), кроме того в том числе необходимо указать:

1. Стоимость работ по разработке программного обеспечения «Система сопровождения Договора о присоединении» (далее - ПО)

2. Стоимость оказания услуг по сопровождению ПО за 5 (пять) лет и отдельно за каждый год.

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

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

1.5. Стоимость в коммерческих предложениях (заявках) должна быть зафиксирована в рублях РФ.

1.6. Обеспечение заявки на участие в настоящей закупочной процедуре не требуется.1.7. Начальная стоимость закупки (предельная цена заключаемого по итогам

процедуры договора) не устанавливается.1.8. Подача коммерческого предложения означает полное ознакомление и согласие

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

1.9. Коммерческие предложения (заявки) подаются в запечатанных конвертах с обязательным указанием на конверте:

наименования и ИНН Участника;

3

наименование Закупочной процедуры - «Открытый запрос коммерческих предложений на выполнение работ по разработке программного обеспечения «Система сопровождения Договора о присоединении» и оказание услуг по сопровождению программного обеспечения»;

«В закупочную комиссию Ассоциации «НП Совет рынка»; «Не вскрывать до <<указать время и дату вскрытия конвертов,

указанные в настоящем Извещении>>».1.10. Каждый Участник вправе подать только одно коммерческое предложение

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

1.11. Коммерческое предложение (заявка) Участника должно действовать не менее 20 (двадцати) дней, начиная с даты сопоставления коммерческих предложений (заявок) и подведения итогов запроса коммерческих предложений (заявок), установленной настоящей Закупочной документацией.

1.12. Коммерческие предложения (заявки) принимаются по рабочим дням (Пн, Вт, Ср, Чт - с 9:00 до 18:00, Пт - с 9:00 до 16:45) по адресу: 123610, г. Москва, Краснопресненская набережная, д. 12, подъезд 7, этаж 14, комната 1407 в срок до 10 часов 00 минут МСК 03.11.2020.

1.13. Дата, время и место вскрытия конвертов – 12 часов 00 минут МСК 03.11.2020, 123610, г. Москва, Краснопресненская набережная, д. 12, подъезд 7, этаж 9.

1.14. Дата, время и место подведения итогов запроса коммерческих предложений – 12 часов 00 минут МСК 10.11.2020, 123610, г. Москва, Краснопресненская набережная, д. 12, подъезд 7, этаж 9.

1.15. Настоящий открытый запрос коммерческих предложений не является офертой или публичной офертой Ассоциации «НП Совет рынка», а также не является Извещением о проведении конкурса и не имеет соответствующих правовых последствий. Ассоциация «НП Совет рынка» имеет право в любое время и по любой причине прекратить процедуру открытого запроса коммерческих предложений и отказаться от всех полученных предложений, не неся при этом никакой ответственности перед участниками.

4

2. ТРЕБОВАНИЯ К ПРОДУКЦИИ

Требования изложены в Приложении № 1 к Проекту Договора.

5

3. КРИТЕРИИ И ПОРЯДОК ОЦЕНКИ ЗАЯВОК (КОММЕРЧЕСКИХ ПРЕДЛОЖЕНИЙ). ОПРЕДЕЛЕНИЕ ПОБЕДИТЕЛЯ ЗАКУПОЧНОЙ ПРОЦЕДУРЫ.

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

№ Критерий Вес критерия Максимальный балл

1 Общая стоимость работ и услуг по Договору, в том числе НДС (20%).

75% 100

2 Квалификации исполнителя 25% 100

2.1 Опыт реализации аналогичных проектов 60

2.2 Квалификация сотрудников участника 20

2.3 Соответствие методик работы, используемых участником, поставленной задаче

20

В отношении критерия 1.Критерию оценки присваивается балл от 0 до 100 в порядке, предусмотренном настоящим приложением.При определении баллов по критерию оценки № 1 применяется следующая формула расчета баллов:

Ri , где:Ri – балл, присуждаемый i-ому коммерческому предложению (заявке) по критерию наименьшей стоимости услуг;Pmax - начальное (предельное) значение соответствующего критерия оценки, а в случае, если предельное (начальное) значение не установлено закупочной документацией, максимальное, отличное от нуля, значение критерия оценки в заявках, принятых к рассмотрению;Pi – значение стоимости услуг, указанное в i-м коммерческом предложении (заявке).Если Pi по i-ой заявке равно нулю, то по данному критерию оценки присваивается балл, равный 100.

В отношении критерия 2.

При оценке критерия «Квалификация исполнителя» будут учитываться следующие факторы:

При оценке фактора по пункту 2.1 будет учитываться: 6

представленные портфолио по выполненным проектам; экспертная оценка выполненных проектов на соответствие предметной области внедряемого ПОПри оценке фактора по пункту 2.2 будет учитываться: соответствие направленных в соответствии с п. 5 и 6 Требований к участнику закупочной процедуры подтверждений квалификации сотрудников предметной области внедряемого ПО; соответствие перечня специальностей и компетенций, которыми обладает компания, предметной области внедряемого ПО

При оценке фактора по пункту 2.3 предпочтение отдается участникам, готовым использовать для взаимодействия с заказчиком Scrum и/или Kanban.

В отношении критерия № 2 применяется следующий подход: при полном соответствии потребностям Партнерства присваивается балл, равный 100, при минимальном соответствии – балл, равный 0. Полное соответствие подразумевает, что дальнейшее улучшение по критерию оценки относительно уровня, представленного в заявке, не даст какого-либо дополнительного экономического эффекта Партнерству. Значения в диапазоне от 1 до 99 присваиваются исходя из относительной предпочтительности той или иной заявки по данным критериям оценки среди всех рассматриваемых заявок в рамках закупочной процедуры. Посредством умножения балла, присвоенному коммерческому предложению (заявке) по критерию оценки, на значимость (вес) соответствующего критерия оценки, определяется рейтинг по критерию оценки. На основании полученного рейтинга коммерческие предложения (заявки) ранжируются по убыванию рейтинга (т.е. по убыванию степени предпочтительности). Все дробные значения рейтинга округляются до двух десятичных знаков после запятой по математическим правилам округления.Если по результатам оценки коммерческих предложений (заявок), по двум и более коммерческим предложениям (заявкам) рейтинги оказались равными, такие коммерческие предложения (заявки) ранжируются по дате и времени их получения по убыванию времени и даты. При совпадении даты и времени получения заявок, они ранжируются по убыванию номера входящего документа.Участник, коммерческому предложению (заявке) которого присвоен первый номер при ранжировании заявок, признается победителем закупочной процедуры.

7

4. ТРЕБОВАНИЯ К УЧАСТНИКАМ ЗАПРОСА КОММЕРЧЕСКИХ ПРЕДЛОЖЕНИЙ. ПОДТВЕРЖДЕНИЕ ТРЕБОВАНИЙ.

1. Описание требований Перечень документов для подтверждения требований к участникам

1. Предоставление информации о собственниках (цепочке собственников), включая конечных бенефициаров Участника, исполнительных органах Участника:

Ф.И.О. (наименование), ИНН учредителей Участника, включая конечных бенефициаров (в отношении учредителей, являющихся юридическими лицами, наименование и ИНН их учредителей и т.д.);

Ф.И.О. единоличного исполнительного органа, Ф.И.О. членов коллегиального исполнительного органа.

Справка (рекомендованная форма приведена в табл. 3.1) с приложением заверенных надлежащим образом копий документов, подтверждающих сведения о собственниках, учредителях и исполнительных органах Участника, а именно:

• копия устава контрагента;• копия свидетельства о

государственной регистрации контрагента;

• копия свидетельства о постановке контрагента на учет в налоговом органе;

• копия выписки из решения (протокола) органа управления о назначении (избрании) единоличного исполнительного органа контрагента.

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

2. Необходимо предоставить перечень лицензируемого ПО, приобретение которого будет необходимо для бесперебойной работы целевого ПО в течение 5 (пяти) лет с даты подписания Акта сдачи-приемки выполненных работ по Договору с указанием стоимости лицензий (включая продление срока действия лицензий в случае его истечения, а также осуществление необходимых обновлений лицензируемого ПО). В случае, если на этапе подготовки заявки на участие в конкурсе

Перечень лицензируемого ПО, приобретение которого будет необходимо для бесперебойной работы целевого ПО в течение 5 (пяти) лет с даты подписания Акта сдачи-приемки выполненных работ по Договору с указанием стоимости лицензий (включая продление срока действия лицензий в случае его истечения, а также осуществление необходимых обновлений лицензируемого ПО). В случае, если на этапе подготовки заявки на участие в конкурсе невозможно однозначно определить перечень

8

невозможно однозначно определить перечень лицензируемого ПО, необходимо представить возможные варианты с подробными пояснениями, чем может быть обусловлен выбор того или иного лицензируемого ПО, и его стоимостью. В случае, если необходимость приобретения лицензируемого ПО отсутствует, необходимо прямое указание об этом.

лицензируемого ПО – информация о возможных вариантах с подробными пояснениями, чем может быть обусловлен выбор того или иного лицензируемого ПО, и его стоимостью.

3. Наличие подтвержденного опыта реализации проектов по разработке и функциональному сопровождению программного обеспечения для целей построения электронных архивов документов и/или контент-менеджмента (далее – предметная область), не менее 2 (двух) проектов за последние 5 лет.

Перечень реализованных проектов с кратким описанием (портфолио) и приложением копий актов выполненных работ по указанным проектам (не менее 2 (двух) проектов за последние 5 лет).

4. Наличие специальностей и компетенций, соответствующих предметной области разрабатываемого ПО.

Не менее 1 (одного) сертификата или иного документа, выданного компаниями–вендорами платформ и информационных систем класса ECM или их авторизованными партнерами в области разработки и функционального сопровождения программного обеспечения для целей построения электронных архивов документов и/или контент-менеджмента.

5. Использование методик работы, соответствующих поставленной задаче.

Перечень процедур/методологий (например, Scrum, Lean, Kanban, Six Sigma и др.), которые готов использовать участник для взаимодействия с заказчиком при ведении проектов.

6. Наличие необходимых для реализации проекта специалистов:1) не менее 3 (трех) специалистов,

привлекаемых к выполнению работ, должны иметь опыт/квалификацию по разработке программного обеспечения для целей построения хранилищ, электронных архивов документов и оптимизации бизнес-процессов;

2) не менее чем 1 (один) специалист из состава привлеченных к процессам методологической проработки во время выполнения работ должен иметь опыт работы в качестве бизнес-аналитика.

Предоставляются резюме специалистов на русском языке с указанием характера их привлечения к работе (трудовой или гражданско-правовой договор, иное), сведений об образовании и квалификации (сертификаты, дипломы и другие аккредитации, соответствующие предметной области разрабатываемого ПО), описанием проектов, реализованных с их участием, ролей (функций) данных специалистов в указанных проектах и пояснением, к какому направлений относится указанный опыт.

В отношении специалистов, являющихся иностранными гражданами 9

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

10

Таблица 4.1. Рекомендованная форма раскрытия информации о собственниках (бенефициарах) и исполнительных органах Участника

Информация о цепочке собственников, руководителях и конечных бенефициарах _____________________________________________________ (наим

енование организации, представившей информацию)

№ № п/п

Наименование контрагента (ИНН, вид деятельности)

№ № п/п

Информация о цепочке собственников контрагента, включая бенефициаров(в том числе конечных)

ИН

Н

ОГР

Н

Наи

мено

вани

е ко

нтра

гент

а

Код

ОК

ВЭ

Д

Фам

илия

, имя

, от

чест

во

руко

води

теле

й (е

дино

личн

ого

испо

лнит

ельн

ого

Ном

ер

доку

мент

а,

удос

тове

ряю

щег

о ли

чнос

ть

ИН

Н

ОГР

Н

Наи

мено

вани

е/

ФИ

О

Адр

ес

реги

стра

ции

Сер

ия и

ном

ер

доку

мент

а,

удос

тове

ряю

щег

о ли

чнос

ть ф

изич

еско

го

Руко

води

тель

/ уч

астн

ик/ а

кцио

нер/

бе

нефи

циар

Инф

орма

ция

о по

дтве

ржда

ющ

их

доку

мент

ах

(наи

мено

вани

е,

рекв

изит

ы и

т.д

.)Д

оля

%

11

22

33 4

55 6 7

113

114

115 16 17 18 19 20

221

1              

5. ПРОЕКТ ДОГОВОРА

ДОГОВОР № ___

г. Москва «___» _______ 20__ года

Ассоциация «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью» (Ассоциация «НП Совет рынка»), именуемая в дальнейшем «Заказчик», лице _____________________, действующего на основании ________________________, с одной стороны, и

_______________________________, в лице _________________________, действующего на основании ________________________, именуемая в дальнейшем «Исполнитель», с другой стороны, вместе именуемые «Стороны», а каждая по отдельности «Сторона», заключили настоящий договор (далее – Договор) о следующем:

1. ПРЕДМЕТ ДОГОВОРА

1.1. Исполнитель по заданию Заказчика обязуется:

1.1.1. выполнить работы по разработке программного обеспечения «Система сопровождения Договора о присоединении» (далее - ПО) в соответствии с Техническими требованиями (Приложение № 1 к Договору) в порядке и сроки, указанные в Договоре (далее – работы);

1.1.2. оказать услуги по сопровождению ПО в порядке и сроки, указанные в Договоре (далее – услуги),

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

1.2. Целью заключения Договора является оптимизация бизнес-процесса внесения в Договор о присоединении изменений, принятых Наблюдательным советом Ассоциации «НП Совет рынка».

2. ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТ

2.1. Срок выполнения работ по Договору составляет 18 (восемнадцать) месяцев с даты подписания Сторонами Договора.

2.2. Результатом выполнения работ по Договору является:

ПО, функционирующее на программно-аппаратном комплексе Заказчика и представленное Заказчику на оптическом носителе в виде пакета инсталляционных материалов, исходных кодов, файлов конфигурации, исполняемых файлов, необходимых для работы ПО и иных данных, обеспечивающих работу ПО;

оформленная в бумажном и в электронном виде документация, необходимая для эксплуатации ПО, а именно: проектная и эксплуатационная документация (руководство администратора,

руководство системного администратора, руководство пользователей, руководство программиста, Техническое задание, Архитектурный документ);

программа проведения обучения; программа и методика испытаний (ПМИ); информация о лицензиях, необходимых для работы ПО (полный перечень); иная документация, необходимая Заказчику для эксплуатации ПО (полный

перечень представлен в разделе 6 Технических требований).

12

2.3. Порядок взаимодействия Сторон по созданию, испытанию и приемке ПО изложен в разделе 5 Приложения № 1 к Договору.

2.4. С целью реализации права Заказчика проверять ход и качество выполнения работ Стороны согласовали, что Исполнитель выполняет работы по Договору в 5 (пять) этапов в соответствии с планом-графиком выполнения работ (Приложение № 2 к Договору) с поэтапной итерационной разработкой частных технических заданий (ЧТЗ), части Архитектурного документа в соответствии с функциональностью соответствующего этапа. Результаты выполнения работ по каждому из этапов указаны в плане-графике выполнения работ.

2.5. ЧТЗ должно содержать следующие обязательные разделы в соответствии с Межгосударственным стандартом Информационная технология «Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» ГОСТ 34.602-89: требования к функциям ПО; требование к архитектуре ПО; требования к технологиям ПО; требования к надежности ПО; требования к производительности ПО; требования к безопасности ПО.

2.6. В ЧТЗ должны быть приведены сценарии использования, разрабатываемого ПО.

2.7. ЧТЗ должно содержать эскизы/дизайны всех необходимых интерфейсных форм, описанных в Технических требованиях.

2.8. Принимая во внимание, что для надлежащего выполнения работ необходимо участие Заказчика в процессе их выполнения, Стороны договорились:

2.8.1. об информировании Исполнителя о целях разработки ПО на любом этапе выполнения работ по Договору;

2.8.2. о приоритизации Заказчиком реализуемых Исполнителем задач: как в рамках отдельных этапов, так и в рамках всего плана-графика выполнения работ;

2.8.3. о конкретизации Заказчиком Технических требований к ПО и задач из плана-графика выполнения работ;

2.8.4. об оперативном информировании о ходе выполнения работ: по запросу Заказчика Исполнитель в течение 1 (одного) рабочего дня предоставляет запрашиваемую информацию о ходе выполнения работ, в отсутствие запроса – еженедельно допускается обмен сообщениями по электронной почте уполномоченных представителей Сторон, указанных в пункте 9.1 Договора);

2.8.5. об оперативном предоставлении Заказчиком информации, необходимой Исполнителю для выполнения работ;

2.8.6. о промежуточном согласовании Заказчиком хода выполнения работ.

2.9. В рамках реализации пункта 2.8.6 Договора Исполнитель согласовывает с Заказчиком результаты выполнения работ по каждому из этапов в соответствии с планом-графиком выполнения работ по электронной почте путем направления сообщений Сторонами со следующих электронных адресов:

со стороны Заказчика – ______________

со стороны Исполнителя – _______________

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

13

результата выполнения работ по __ этапу Договора направляем ____».

2.10. Направление замечаний Заказчиком и их исправление Исполнителем осуществляется до окончательного устранения Исполнителем всех замечаний Заказчика к разрабатываемому ПО/документации по соответствующему этапу и не предполагает приостановления сроков выполнения работ по Договору.

2.11. Заказчик вправе не согласовать результат выполнения работ по этапу, если он не соответствует Техническим требованиям, указанным в Приложении № 1 к Договору, и другим критериям качества. В таком случае Исполнитель должен устранить замечания Заказчика в срок, установленный Заказчиком (не превышающий 10 (десяти) рабочих дней с даты получения по электронной почте замечаний Заказчика). Исполнитель обязан продемонстрировать исправленное по замечаниям ПО на разрабатываемую функциональность/направить исправленную документацию на адрес электронной почты Заказчика. Просрочка выполнения работ в таком случае считается возникшей по вине Исполнителя.

2.12. Если Исполнитель не приступает своевременно к исполнению Договора или выполняет работы настолько медленно, что окончание их к сроку становится явно невозможным (отступление от сроков плана-графика составляют 10 (десять) календарных дней и более), Заказчик вправе отказаться от исполнения Договора в одностороннем внесудебном порядке и потребовать от Исполнителя возмещения причиненных убытков.

2.13. Если во время выполнения работ станет очевидным, что они не будут выполнены надлежащим образом (работы выполняются Исполнителем с отступлениями от Договора, включая, но не ограничиваясь, условий Технических требований Приложения № 1 к Договору, или с иными недостатками, которые делают результат выполнения работ непригодным для предусмотренного в Договоре использования, в том числе если более 5 (пяти) раз не устраняются замечания Заказчика в рамках согласования выполнения работ по каждому из этапов), Заказчик вправе назначить Исполнителю разумный срок для устранения недостатков, который в любом случае не может превышать 10 (десять) рабочих дней с даты предъявления Заказчиком соответствующего требования, и при неисполнении Исполнителем в назначенный срок этого требования отказаться от Договора в одностороннем внесудебном порядке, а также потребовать возмещения убытков.

2.14. В случае если у Заказчика отсутствуют замечания к разрабатываемому ПО/документации по соответствующему этапу Заказчик направляет Исполнителю по электронной почте уведомление о согласовании результата выполнения работ по соответствующему этапу.

Результат выполнения работ по каждому из этапов считается согласованным Заказчиком, если сообщение направлено с электронного адреса, указанного в пункте 2.9 Договора, возможно бесспорно определить дату отправки сообщения, и сообщение содержит следующую формулировку: «В соответствии с пунктом 2.14 Договора уведомляем о согласовании результата выполнения работ по __ этапу Договора».

2.15. После согласования Заказчиком результата выполнения работ по соответствующему этапу в порядке, указанном в пункте 2.14 Договора, Исполнитель вправе переходить к выполнению работ по следующему этапу в соответствии с планом-графиком выполнения работ.

2.16. Выполнение работ по последнему (пятому) этапу в соответствии с планом-графиком выполнения работ предполагает комплекс мероприятий по проведению комплексных испытаний ПО в соответствии с разделом 5 Технических требований (тестирование и опытно-промышленная эксплуатация ПО в контуре инфраструктуры Заказчика) и сдаче-приемке ПО на стороне Заказчика. В рамках выполнения работ Исполнитель также проводит обучение представителей Заказчика работе с созданным ПО.

14

2.17. По результатам комплексных испытаний ПО должен быть оформлен Протокол комплексных испытаний ПО, содержащий сведения о результатах испытаний в соответствии с разделом 5 Технических требований (далее – Протокол испытаний).

2.18. В случае наличия в Протоколе испытаний указаний на отступления в работе ПО от Технических требований или на иные недостатки результата выполнения работ Исполнитель обязан устранить недостатки в разумный срок, который в любом случае не может превышать 10 (десять) календарных дней с даты направления Заказчиком сканированной копии Протокола испытаний Исполнителю по электронной почте.

2.19. Заказчик вправе не согласовать результат работ по последнему (пятому) этапу, если он не соответствует Техническим требованиям (Приложение № 1 к Договору), документации, утвержденной на соответствующем этапе в соответствии с пунктом 2.4 Договора, включая документацию, утвержденную на предыдущих этапах выполнения работ, и/или содержит иные скрытые недостатки. В таком случае Исполнитель должен устранить замечания Заказчика в срок, установленный Заказчиком (не превышающий 10 (десяти) рабочих дней с даты получения по электронной почте замечаний от Заказчика). Просрочка выполнения работ в таком случае считается возникшей по вине Исполнителя.

2.20. В случае, если Исполнитель предоставляет Заказчику более 4 (четырех) раз для проведения комплексных испытаний ПО, в котором обнаружены отступления от Технических требований, включая, но не ограничиваясь следующих требований:

к скорости работы (быстродействию) ПО, выражающемуся в том числе, в скорости обработки информации;

к производительности при заданной нагрузке и масштабируемости ПО, то есть способности ПО справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов, увеличении объема информации или количества пользователей;

к надежности (стабильности) ПО, то есть способности ПО выдерживать ожидаемую нагрузку (количество пользователей и объем информации и ресурсов) в течение заданного времени;

к потреблению ресурсов (способности ПО функционировать корректно при использовании заданных ресурсов);

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

к безопасности ПО (устойчивости ПО к различного рода атакам и вирусам); к совместимости ПО (корректному функционированию ПО в заданном окружении)и (или) иные недостатки, любые недостатки результата работы ПО (отступления от документации, Технических требований) будут рассматриваться Сторонами как существенные и неустранимые, дающие Заказчику право на основании пункта 3 статьи 723 Гражданского кодекса Российской Федерации в одностороннем внесудебном порядке отказаться от исполнения Договора и потребовать возмещения причиненных, документально подтвержденных, убытков.

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

2.21. Заказчик по результатам комплексных испытаний ПО (тестирования и опытно-промышленной эксплуатации ПО в контуре инфраструктуры Заказчика) на последнем

15

(пятом) этапе выполнения работ по Договору вправе:

2.21.1. Направить Исполнителю по электронной почте уведомление об отсутствии замечаний к результату выполнения работ по Договору и о готовности подписать Акт сдачи-приемки выполненных работ по Договору в порядке, указанном в пункте 2.14 Договора. В этом случае Исполнитель не позднее 3 (трех) рабочих дней с даты получения уведомления передает Заказчику по Акту приема-передачи согласованную ранее по электронной почте документацию, указанную в пункте 2.2 Договора, на бумажном и электронном носителе, ПО на оптическом носителе, а также подписанные со своей стороны 2 (два) экземпляра Акта сдачи-приемки выполненных работ по Договору (далее – Акт) и Акта приема-передачи прав на разработанное ПО.

2.21.2. Направить Исполнителю по электронной почте замечания/предложения к работе ПО и/или документации, указанной в пункте 2.2 Договора, с указанием срока их устранения. В этом случае Исполнитель обязан доработать ПО/документацию с учетом замечаний и предложений Заказчика. Доработка Исполнителем ПО/документации не подлежит дополнительной оплате. После проведения комплексных испытаний доработанного Исполнителем ПО/рассмотрения доработанной документации Заказчик вправе принять одно из решений, указанных в пунктах 2.21.1-2.21.2 Договора.При этом Заказчик вправе отказаться от исполнения Договора в одностороннем внесудебном порядке в соответствии со статьей 715 Гражданского кодекса, если замечания не были устранены Исполнителем в установленный Заказчиком срок.

2.22. Заказчик в течение 10 (десяти) рабочих дней с даты получения от Исполнителя 2 (двух) экземпляров Акта обязан направить Исполнителю в документарном виде 1 (один) экземпляр подписанного со своей стороны Акта либо, при наличии недостатков, оформить письменно и направить Исполнителю мотивированный отказ от подписания Акта.

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

В сроки, указанные Заказчиком в мотивированном отказе от подписания Акта, Исполнитель предоставляет Заказчику результат выполнения работ с учетом устранения замечаний.

2.23. Факт подписания Акта не означает, что Заказчик не вправе ссылаться на недостатки созданного ПО, которые не могли быть обнаружены при обычном способе его приемки в том числе в процессе согласования результата выполнения работ по каждому из этапов (скрытые недостатки), а также предъявлять Исполнителю претензии в связи с обнаружением таких недостатков созданного ПО после подписания Акта.

3. ПОРЯДОК ОКАЗАНИЯ УСЛУГ

3.1. Услуги по сопровождению ПО включают в себя, в том числе1: консультирование работников Заказчика по вопросам работы ПО в режиме «вопрос-

ответ» (в рабочие дни с 09.00 до 18.00 по московскому времени по телефону/факсу __________________ или электронной почте _________________);

1 Участник закупочной процедуры вправе расширить перечень оказываемых услуг в рамках сопровождения разработанного ПО.

16

проведение анализа причин, приведших к возникновению дефектов (сбоев) ПО; устранение дефектов (сбоев) ПО вне гарантийного срока, включая при

необходимости корректировку ПО (отладка и устранение ошибок в исходном коде ПО), необходимую для дальнейшего функционирования ПО

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

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

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

Время подготовки решения/временного решения по критическим ошибкам составляет не более 6 (шести) рабочих часов, по прочим ошибкам – не более 16 (шестнадцати) рабочих часов;

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

ведение архива изменений исходного кода ПО; адаптацию ПО к изменениям окружения ПО без существенных доработок его

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

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

3.2. Сроки оказания услуг по сопровождению ПО - 5 (пять) лет с даты подписания Сторонами Акта сдачи-приемки выполненных работ по Договору.

Для целей Договора применяется отчетный период оказания услуг - 1 (один) год. При этом датой начала оказания услуг (датой начала первого отчетного периода оказания услуг) является дата подписания Сторонами Акта сдачи-приемки выполненных работ по Договору.

3.3. Исполнитель оказывает услуги по своей инициативе (с обязательным уведомлением об этом Заказчика) и/или на основании обращений Заказчика (письменных, по телефону, электронной почте, указанной в пункте 9.1 Договора, или заявок во внутренней системе Заказчика по размещению и контролю исполнения заявок - Системе JIRA).

3.4. В целях взаимодействия Сторон в рамках оказания услуг по Договору Заказчик на период оказания услуг по Договору предоставляет Исполнителю доступ к Системе Jira, принадлежащей Заказчику (путем предоставления паролей и кодов доступа, необходимых для авторизации представителей Исполнителя).

3.5. Исполнитель обязан вести учет всех обращений Заказчика по вопросам оказания услуг (письменных, по телефону, электронной почте, указанной в пункте 9.1 Договора, или заявок в Системе JIRA) и по запросу Заказчика предоставлять перечень обращений Заказчика за соответствующие периоды.

3.6. По результатам каждого отчетного периода по Договору Исполнитель составляет в свободной форме отчет об оказанных в рамках отчетного периода по Договору услугах (в том числе информацию о выполненных Исполнителем обращениях/заявках Заказчика).

3.7. В течение 10 (Десяти) календарных дней по истечении каждого отчетного периода Исполнитель передает Заказчику подписанные со своей стороны:

17

2 (два) экземпляра Акта об оказании услуг за прошедший отчетный период по форме, предусмотренной Приложением № 3 к Договору;

отчет об оказанных Исполнителем услугах Исполнителя за прошедший отчетный период (далее по тексту – Отчет).

3.8. Заказчик в течение 10 (десяти) рабочих дней с даты получения от Исполнителя 2 (двух) экземпляров Акта об оказании услуг и Отчета обязан направить Исполнителю в документарном виде 1 (один) экземпляр подписанного со своей стороны Акта об оказании услуг и подписанный Отчет либо, при наличии недостатков, оформить письменно и направить Исполнителю мотивированный отказ от подписания Акта об оказании услуг и Отчета.

В случае непредоставления Заказчиком в установленный Договором срок мотивированного отказа от подписания Акта об оказании услуг и/или Отчета, услуги считаются оказанными Исполнителем надлежащим образом и принятыми Заказчиком, а Акт об оказании услуг – подписанным Сторонами.

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

4. ПРАВА И ОБЯЗАННОСТИ СТОРОН

4.1. Исполнитель вправе:4.1.1. привлекать третьих лиц к выполнению работ и оказанию услуг только при наличии

письменного согласия Заказчика;4.1.2. осуществлять иные права, предусмотренные Договором.

4.2. Исполнитель обязан:4.2.1. выполнить работы и оказать услуги в порядке и сроки, предусмотренные

Договором;4.2.2. в течение 5 (пяти) рабочих дней с даты подписания Договора передать Заказчику

список физических лиц, уполномоченных на проведение работ/оказание услуг в рамках Договора (далее – представители Исполнителя), а также следующие документы и информацию в отношении каждого представителя Исполнителя: копию паспорта гражданина Российской Федерации или документа, на

основании которого представитель Исполнителя находится в Российской Федерации;

в отношении представителей Исполнителя, являющихся иностранными гражданами или лицами без гражданства – копии документов, подтверждающих их право заниматься в Российской Федерации деятельностью по трудовому договору или гражданско-правовому договору;

сведения о наличии трудовых или гражданско-правовых отношений между Исполнителем и представителями Исполнителя;

согласие на обработку персональных данных в бумажном виде по форме, предусмотренной Приложением № 5 к Договору;

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

4.2.4. по требованию Заказчика сообщать сведения о ходе исполнения Договора (в том числе участвовать в организованных Заказчиком встречах);

4.2.5. устранять обозначенные Заказчиком недостатки в установленный Заказчиком срок;

18

4.2.6. при выполнении работ по Договору руководствоваться требованиями государственных стандартов Российской Федерации и межгосударственных стандартов, регламентирующих разработку автоматизированных систем, в том числе Межгосударственного стандарта Информационная технология «Виды испытаний автоматизированных систем» (ГОСТ 34.603-92), в части, не урегулированной Договором и не противоречащей требованиям Договора;

4.2.7. разработать и предоставить на согласование Заказчику документацию на ПО;4.2.8. организовывать регулярные демонстрации представителям Заказчика

функционально завершённых компонентов ПО не реже 1 (одного) раза в месяц, а также предоставление актуализированной документации на ПО с целью контроля Заказчиком на ранних стадиях правильности выбранных решений (при условии предварительного согласования с Заказчиком сценариев проведения демонстраций, а также подготовки всех необходимых для этого тестовых данных);

4.2.9. выполнять работы, необходимые для ввода ПО в промышленную эксплуатацию, в том числе установить и настроить ПО на ресурсах инфраструктуры Заказчика, провести комплексные испытания, обучить сотрудников службы эксплуатации Заказчика установке, настройке и обслуживанию комплекса программно-технических средств ПО;

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

4.2.11. назначить ответственного работника (руководителя проекта) для оперативного решения технических и организационных вопросов, связанных с выполнением работ по Договору;

4.2.12. самостоятельно и за свой счет выплачивать вознаграждения авторам (соавторам) созданного ПО, включая авторов, являющихся работниками Исполнителя, и/или иные компенсации авторам (соавторам) созданного ПО, включая возмещение убытков. При этом Исполнитель не будет иметь претензий к Заказчику, связанных с выплатой авторам (соавторам) авторских вознаграждений и/или иных компенсаций;

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

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

4.3. Заказчик вправе:4.3.1. расторгнуть Договор в одностороннем порядке на любом этапе выполнения работ

по Договору с соответствующей компенсацией затрат Исполнителю. При этом Стороны договорились о фиксированном размере затрат Исполнителя по каждому из этапов: по первому этапу – 1 % от стоимости работ по Договору; по второму этапу – 15 % от стоимости работ по Договору; по третьему этапу – 15 % от стоимости работ по Договору; по четвертому этапу – 25 % от стоимости работ по Договору; по пятому этапу – 44 % от стоимости работ по Договору;

4.3.2. требовать от Исполнителя надлежащего выполнения работ по Договору, проверять ход и качество выполнения Исполнителем работ по Договору (в том числе путем организации регулярных встреч с представителями Исполнителя);

4.3.3. осуществлять иные права, предусмотренные Договором.

4.4. Заказчик обязан:

4.4.1. оплатить выполненные Исполнителем работы и оказанные Исполнителем услуги в порядке и сроки, предусмотренные Договором;

19

4.4.2. оказывать Исполнителю содействие в выполнении работ и оказанию услуг по Договору;

4.4.3. предоставлять по требованию Исполнителя дополнительную информацию, необходимую для выполнения Исполнителем работ по Договору;

4.4.4. предоставить работникам Исполнителя доступ к ПО и Системе JIRA, в том числе дистанционный доступ для оказания услуг по Договору;

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

4.5. Стороны договорились о том, что взаимодействие по всем техническим вопросам, связанным с разработкой ПО, осуществляется с использованием внутреннего информационного ресурса Заказчика – системы Jira. Заказчик представляет Исполнителю доступ к системе Jira до даты начала выполнения Исполнителем работ по второму этапу Договора путём предоставления паролей и кодов доступа, необходимых для авторизации представителей Исполнителя.

4.6. В целях организации взаимодействия по техническим вопросам, связанным с исправлением недостатков результатов работ, в том числе ошибок в ПО, Заказчик вправе предоставить Исполнителю доступ к внутренним информационным системам, в частности, MantisBT, в порядке, аналогичном порядку доступа к системе Jira в соответствии с пунктом 4.5 Договора.

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

5. ЦЕНА ДОГОВОРА И ПОРЯДОК РАСЧЁТОВ

5.1. Стоимость работ по Договору составляет _____________ (________________) рублей __ копеек, в том числе НДС 20% - __________ (___________________) рублей __ копеек. Стоимость работ по Договору учитывает все затраты Исполнителя, связанные с исполнением Договора, в том числе вознаграждение за передачу прав на ПО.

5.2. Оплата Заказчиком общей стоимости работ по Договору осуществляется в следующем порядке:

5.2.1. 5 (пять) % стоимости работ по Договору, указанной в пункте 5.1 Договора, не позднее 2 (двух) месяцев с даты подписания Сторонами Договора при условии получения от Исполнителя счета на оплату;

5.2.2. 10 (десять) % стоимости работ по Договору, указанной в пункте 5.1 Договора, не позднее 7 (семи) месяцев с даты подписания Сторонами Договора при условии получения от Исполнителя счета на оплату;

5.2.3. 85 (восемьдесят пять) % стоимости работ по Договору, указанной в пункте 5.1 Договора, по результатам выполнения работ по Договору в течение 10 (десяти) рабочих дней с даты получения от Исполнителя счета на оплату при условии подписания Сторонами Акта сдачи-приемки выполненных работ по Договору.

5.3. Общая стоимость услуг по Договору составляет ______ (______) рублей 00 копеек, включая НДС (20%) в сумме ________ (__________) рублей 00 копеек, из них:

стоимость услуг за первый отчетный период составляет ____ (__________) рублей 00 копеек, включая НДС (20%) в сумме __________ (_______________________) рублей __ копеек;

стоимость услуг за второй отчетный период составляет ____ (__________) рублей 00 копеек, включая НДС (20%) в сумме __________ (_______________________) рублей __ копеек;

20

стоимость услуг за третий отчетный период составляет ____ (__________) рублей 00 копеек, включая НДС (20%) в сумме __________ (_______________________) рублей __ копеек…

5.4. Оплата стоимости оказанных услуг осуществляется Заказчиком на основании выставленного Исполнителем счета в течение 15 (пятнадцати) рабочих дней с даты подписания Сторонами Акта об оказании услуг за соответствующий отчетный период при условии получения счета на оплату.

5.5. Денежные обязательства Заказчика по Договору подлежат оплате в безналичном порядке путем перечисления денежных средств на расчетный счет Исполнителя, указанный в разделе 10 Договора.

5.6. Днем оплаты считается день списания денежных средств с расчетного счета Заказчика.

6. ПРАВА НА РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ РАБОТ

6.1. Исключительное право на результат выполнения работ по Договору принадлежит Заказчику в полном объеме и без каких-либо ограничений с даты подписания Сторонами Акта сдачи-приемки выполненных работ.

6.2. Заказчик вправе любым способом распоряжаться результатом выполнения работ по Договору, а также исключительным правом на него (в том числе уступать третьим лицам) с даты подписания Сторонами Акта сдачи-приемки выполненных работ.

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

6.4. Исполнитель подтверждает и гарантирует, что:

6.4.1. использование Заказчиком результата выполнения работ (в том числе необходимых для его работы ПО, исключительное право на которое принадлежит правообладателям – третьим лицам) не будет нарушать прав третьих лиц;

6.4.2. использование Заказчиком результата выполнения работ не будет нарушать прав работников Исполнителя как авторов.

6.5. Исполнитель гарантирует Заказчику, что качество выполняемых работ по Договору, результата выполнения работ и всех его составляющих соответствует и будет соответствовать в течение гарантийного срока равного 12 (двенадцати) месяцам с даты подписания Сторонами Акта сдачи-приемки выполненных работ (далее – гарантийный срок) требованиям Договора (в том числе Требованиям к ПО), требованиям Заказчика, правилам, государственным стандартам Российской Федерации и межгосударственным стандартам, требованиям нормативно-технической документации и обычно предъявляемым к результатам выполнения работ требованиям.

6.6. В случае обнаружения Заказчиком в течение гарантийного срока того, что работы выполнены Исполнителем с отступлениями от Договора, ухудшившими результат выполнения работ, имеются ошибки, в том числе в методологических и дизайнерских подходах, в настройках и в ПО или иные недостатки, которые делают результат выполнения работ непригодным для предусмотренного в Договоре использования (в том числе в случае сбоев по причине увеличения количества обрабатываемой ПО информации), Заказчик вправе по своему выбору потребовать от Исполнителя:

безвозмездного устранения недостатков в работе созданного ПО в разумный срок, который в любом случае не может превышать 10 (десять) календарных дней с даты предъявления требования;

21

возмещения своих расходов на устранение недостатков.

6.7. В случае, если для работы ПО необходимо использовать результаты интеллектуальной деятельности, исключительное право на которые принадлежит правообладателям – третьим лицам, Исполнитель, гарантирует, что имеет и будет иметь соответствующие полномочия от правообладателей – третьих лиц в период действия Договора, и обязуется предоставить Заказчику, выступающему в роли Сублицензиата, соответствующие права использования (лицензии), выступая в качестве Лицензиата. При этом Исполнитель вправе включать в состав ПО результаты интеллектуальной собственности третьих лиц только с предварительного письменного согласия Заказчика.

Передача Заказчику (Сублицензиату) прав использования (лицензий) производится Исполнителем путем заключения Сторонами соответствующего сублицензионного договора. При этом объем предоставляемых Заказчику прав на результаты интеллектуальной собственности третьих лиц, включенных Исполнителем в состав ПО, должен предусматривать предоставление Заказчику права использования таких результатов любыми не противоречащими закону способами, в том числе указанными в ст. 1270, ст. 1280 Гражданского кодекса Российской Федерации, без ограничения территории и срока. Заказчик должен быть освобождён от обязанности предоставлять любым третьим лицам отчёты об использовании результатов интеллектуальной собственности, включенных в состав ПО.

6.8. Исполнитель подтверждает и гарантирует, что использование Заказчиком результата выполнения работ (в том числе необходимых для его работы ПО, исключительное право на которое принадлежит правообладателям – третьим лицам) не будет нарушать прав третьих лиц и работников Исполнителя как авторов.

7. ОТВЕТСТВЕННОСТЬ СТОРОН. ПОРЯДОК РАЗРЕШЕНИЯ СПОРОВ

7.1. За неисполнение или ненадлежащее исполнение своих обязательств по Договору Стороны несут ответственность в соответствии с законодательством Российской Федерации и Договором.

7.2. В случае нарушения Исполнителем указанного в пункте 2.1 Договора срока выполнения работ по Договору Заказчик вправе потребовать от Исполнителя уплаты неустойки в размере 0,1 (одна десятая) % от стоимости работ по Договору, указанной в пункте 5.1 Договора, за каждый день просрочки.

7.3. В случае нарушения гарантий, указанных в разделе 6 Договора, Заказчик вправе потребовать от Исполнителя уплаты неустойки в размере 5 (пяти) % от стоимости работ по Договору, а также вправе в одностороннем внесудебном порядке отказаться от Договора. Выплата неустойки в случае нарушения Исполнителем гарантий, установленных в разделе 6 Договора, не лишает Заказчика права требовать от Исполнителя урегулирования возникших претензий третьих лиц, в том числе обеспечения представления интересов Заказчика в суде, возмещения Заказчику всех расходов, вызванных предъявлением третьими лицами претензий к Заказчику.

7.4. В случае нарушения Заказчиком указанных в разделе 5 Договора сроков оплаты работ и услуг Исполнитель вправе потребовать от Заказчика уплаты неустойки в размере 0,1 (одна десятая) % от неоплаченной в срок суммы за каждый день просрочки.

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

22

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

При этом Стороны согласились, что под существенными и неустранимыми недостатками в целях Договора понимаются любые неустранимые недостатки, которые не могут быть устранены без несоразмерных расходов или затрат времени (более 10 (десяти) рабочих дней с даты предъявления соответствующего требования), или выявляются неоднократно (более одного раза), или проявляются вновь после их устранения, или другие подобные недостатки.

7.7. Предоставленное Договором право на односторонний внесудебный отказ от Договора осуществляется Стороной путем направления, подписанного уполномоченным лицом Стороны уведомления другой Стороне об отказе от Договора. Договор прекращается с момента получения второй Стороной данного уведомления, за исключением положений Договора, направленных на урегулирование отношений Сторон в случае расторжения Договора. Уведомление считается полученным, если оно было доставлено на адрес, указанный в разделе 10 Договора в качестве адреса для направления юридически значимых сообщений.

7.8. Уплата неустойки не освобождает Стороны от исполнения своих обязательств по Договору.

7.9. Стороны освобождаются от ответственности за неисполнение или ненадлежащее исполнение взятых на себя обязательств, если надлежащее исполнение оказалось невозможным вследствие непреодолимой силы.

7.10. Стороны будут стремиться к тому, чтобы решить любой спор, возникающий из Договора или в связи с ним, в том числе спор о порядке заключения Договора, его действительности или обязательности, внесении в него изменений и дополнений, о его расторжении, путем переговоров. В случае невозможности разрешения такого спора путем переговоров он может быть передан на разрешение Арбитражного суда города Москвы после принятия мер по досудебному урегулированию по истечении 10 (десяти) календарных дней со дня направления претензии.

8. СРОК ДЕЙСТВИЯ ДОГОВОРА. ПОРЯДОК ИЗМЕНЕНИЯ И ПРЕКРАЩЕНИЯ ДОГОВОРА

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

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

8.3. В случае изменения сведений, указанных в пункте 9.1 и разделе 10 Договора, Сторона обязана в день изменения в письменной форме уведомить об этом другую Сторону.

8.4. Договор может быть расторгнут по письменному соглашению Сторон.

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

23

9. ПРОЧИЕ УСЛОВИЯ

9.1. Текущее взаимодействие с Исполнителем осуществляется следующими представителями Заказчика:

_______________________

_______________________

Указанные лица уполномочены на получение/направление документов и проведение переговоров от имени Заказчика по вопросам, связанным с исполнением Сторонами обязанностей по Договору, и не имеют права подписи дополнительных соглашений, актов, финансовых документов.

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

В случае утраты и/или разглашения конфиденциальной информации Исполнитель обязан по требованию Заказчика возместить Заказчику убытки, понесённые им в связи с такой утратой и/или разглашением конфиденциальной информации, в полном объеме.

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

Иная информация, предоставляемая Сторонами друг другу по Договору, считается конфиденциальной, если Сторона обозначает ее как конфиденциальную (при условии, что такая информация не является общедоступной).

9.3. Если иное не предусмотрено Договором, все документы на бумажном носителе вручаются Стороне по акту или путем направления почтового сообщения посредством оператора почтовой связи или курьерской доставкой по адресу, указанному в разделе 10 Договора. Расходы по передаче документов лежат на Стороне-отправителе и компенсации не подлежат.

9.4. Сообщения на электронные адреса/телефонные номера факсов, указанные в пункте 2.9, 9.1 и разделе 10 Договора, будут рассматриваться как надлежащий обмен документами при условии, что возможно бесспорно определить дату отправки сообщения, факт его получения и что документ исходит от Стороны по Договору. Сообщения, указанные в настоящем абзаце, признаются в качестве доказательств в спорах между Сторонами.

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

9.6. Договор составлен в 2 (двух) экземплярах, имеющих одинаковую юридическую силу, по 1 (одному) для каждой из Сторон.

10. АДРЕСА И РЕКВИЗИТЫ СТОРОН

24

ЗАКАЗЧИК:

Ассоциация «НП Совет рынка»

_____________________ _____________м.п.

ИСПОЛНИТЕЛЬ:

______________________ _____________м.п.

25

Приложение № 1к Договору № _______ от «__» ________ 20__ года

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯНА СОЗДАНИЕ СИСТЕМЫ СОПРОВОЖДЕНИЯ ДОГОВОРА О ПРИСОЕДИНЕНИИ

Москва 202026

ОГЛАВЛЕНИЕ

1 Общие сведения...............................................................................................................241.1 Наименование системы и её обозначение..............................................................241.2 Основные понятия, термины и сокращения...........................................................24

2 Назначение и цели создания Системы...........................................................................252.1 Назначение Системы................................................................................................252.2 Цели создания Системы...........................................................................................25

3 Характеристика объекта автоматизации........................................................................253.1 Описание текущего процесса..................................................................................253.2 Недостатки текущего процесса...............................................................................263.3 Описание целевого процесса...................................................................................27

4 Требования к Системе.....................................................................................................284.1 Требования к функциям Системы...........................................................................28

4.1.1 Требования к обеспечению разграничения доступа........................................284.1.2 Типы данных, атрибуты и статусы документов, обрабатываемых Системой294.1.3 Импорт документов ДОП и Таблиц изменений в хранилище Системы .......324.1.4 Работа с правкой ДОП........................................................................................334.1.5 Работа с накопителем правок (НП)...................................................................364.1.6 Работа с переменными ДОП..............................................................................374.1.7 Отправка уведомления на электронную почту................................................384.1.8 Работа с каталогом неопубликованных документов ДОП (КНД).................394.1.9 Подготовка и публикация документов из КНД в КОД...................................404.1.10 Параметрический поиск опубликованных документов ДОП .......................424.1.11 Работа с документами, утратившими силу....................................................434.1.12 Функции администрирования..........................................................................44

4.2 Нефункциональные требования..............................................................................444.2.1 Требования к архитектуре..................................................................................444.2.2 Требования к технологиям.................................................................................444.2.3 Требования к надежности..................................................................................454.2.4 Требования к производительности...................................................................454.2.5 Требования к безопасности................................................................................454.2.6 Требования к результатам разработки..............................................................45

4.3 Общие требования к Системе..................................................................................465 Требования к порядку ведения и содержанию работ...................................................46

5.1 Полномочия и обязанности Заказчика....................................................................465.2 Обязанности Исполнителя.......................................................................................475.3 План-график работ по созданию Системы.............................................................125.4 Регулярные демонстрации.......................................................................................48

27

5.5 Испытания и приёмка Системы..............................................................................486 Требования к документированию..................................................................................487 Приложения......................................................................................................................52

7.1 Шаблон правки.........................................................................................................527.2 Шаблон пояснительной записки к правке..............................................................547.3 Шаблон таблицы изменений...................................................................................55

7.3.1 Шаблон ТИ для ДОП..........................................................................................557.3.2 Шаблон ТИ для Регламентов ОРЭМ.................................................................567.3.3 Шаблон ТИ для Стандартных форм договоров...............................................57

7.4 Пример справочника наименований ДОП.............................................................587.5 Визуальные формы (примеры) отчетов..................................................................60

7.5.1 Пример карточки переменной...........................................................................607.5.2 Пример справочника переменных ДОП...........................................................617.5.3 Пример отчет об ошибках по переменным......................................................627.5.4 Пример отчет об ошибках в тексте документа ДОП.......................................637.5.5 Пример поиска по документам ДОП................................................................647.5.6 Пример накопителя ТИ......................................................................................657.5.7 Пример разметки документа ДОП гиперссылками.........................................66

7.6 Атрибуты переменной ДОП....................................................................................677.7 Пример статических справочников в Справочник переменных ДОП................69

7.7.1 Пример Справочник регламент ов .....................................................................697.7.2 Пример Справочника Ответственное подразделение.....................................707.7.3 Пример Справочник Ответственная организация...........................................707.7.4 Пример Справочник Размерность (единица измерения)................................717.7.5 Пример Справочник Сектор рынка...................................................................717.7.6 Пример Справочник География........................................................................727.7.7 Пример Справочник Время................................................................................727.7.8 Пример Справочник Объект..............................................................................727.7.9 Пример Справочник Показатель.......................................................................73

28

1 Общие сведения

1.1 Наименование системы и её обозначение

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

1.2 Основные понятия, термины и сокращения

Версионируемый документ – документ, изменяемый с течением времени, для каждой версии которого определены даты начала и окончания действия (для текущей версии дата окончания действия может отсутствовать).Дата вступления – дата вступления в силу изменений в ДОП, принятых на НС.Дата НС – дата проведения заседания НС, на котором утверждаются изменения в ДОП.Документы ДОП – набор версионируемых документов, состоящий из:

стандартной формы договора о присоединении (ДОП) регламентов ОРЭМ стандартных форм иных договоров

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

29

регламента, а в правой – соответствующие фрагменты предлагаемой редакции (см. шаблон правки в Приложении 7.1)Текущая редакция документа ДОП, текущая редакция - это максимальная по дате вступления версия документа из перечня всех опубликованных версий этого документа, у которых дата вступления меньше текущей даты, а также дата окончания отсутствует или больше текущей даты.УРКЦ – Управление развития конкурентного ценообразования НП СР.Хранилище документов ДОП, хранилище – хранилище опубликованных документов ДОП, неопубликованных редакций документов ДОП, а также таблиц изменений в Системе.

2 Назначение и цели создания Системы

2.1 Назначение Системы

Основным назначением Системы является автоматизация процесса сопровождения внесения изменений в ДОП, в рамках которого выполняется подготовка новых версий документов ДОП, их утверждение на НС и публикация в общем доступе на официальном сайте НП СР. Среди задач при разработке Системы:

автоматизация создания правки в ДОП; организация единого справочника Переменных ДОП; реализация функции контроля ссылочной целостности внутри и между документами

ДОП.

2.2 Цели создания Системы

К целям создания Системы относится: повышение качества публикуемых Документов ДОП; улучшение механизма просмотра, хранения Документов ДОП и поиска по документам; оптимизация бизнес-процесса внесения изменений в ДОП после принятия правок на

НС.

3 Характеристика объекта автоматизации

3.1 Описание текущего процесса

В настоящее время сопровождение внесения изменений в ДОП осуществляется сотрудниками УРКЦ в порядке, определённом должностными инструкциями, без использования специального программного обеспечения, автоматизирующего данный бизнес-процесс. Все документы, связанные с данным процессом, обрабатываются программами из пакета Microsoft Office на персональных рабочих станциях сотрудников УРКЦ. Совместная работа сотрудников организуется средствами электронной почты и с использованием сетевых папок.Схематично действующий бизнес-процесс внесения изменений в ДОП описывается следующей последовательностью шагов:

1. Инициатор направляет в адрес НП СР редакцию правки либо в бумажном виде письмом, либо электронном виде через Персональную страницу заявителя участника ОРЭМ (ПСЗ)

2. В системе внутреннего электронного документооборота (1С) документ поступает ответственным сотрудникам УРКЦ

3. Сотрудники УРКЦ выполняют необходимые действия, связанные с вынесением правки на утверждение НС, а именно:

готовят пакет документов, подготовленных по форме создают запрос в системе автоматизации процесса согласования правок (на базе

Jira) запускают и курируют процесс согласования до НС

30

4. Сотрудники УРКЦ корректируют пакет документов в соответствии с версией правки, принятой на НС

5. Сотрудники УРКЦ дорабатывают документ ДОП с учётом принятых на НС правок6. Сотрудники УРКЦ публикуют новую версию документа ДОП на сайт НП СР

В процессе на постоянной основе участвуют шесть сотрудников УРКЦ: пять специалистов и начальник структурного подразделения. Также при необходимости на различных этапах могут подключаться другие сотрудники УРКЦ.

3.2 Недостатки текущего процесса

Особенности обработки документов ДОП, отсутствие автоматизации некоторых операций и всего процесса в целом, а также текущий порядок организации совместной работы с документами обуславливает наличие следующих проблем:

отсутствие контроля корректности перекрестных ссылок внутри документа и между документами ДОП;

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

отсутствие единого справочника переменных ДОП и, как следствие, ошибки в написании переменных и их определениях;

отсутствие ссылок с упоминаний в тексте переменных ДОП на их определения в том же или другом документе ДОП;

существенные временные затраты на создание правок в ДОП и его приложения, из-за необходимости выполнения данной операции сотрудником вручную в текстовом редакторе;

невозможность осуществления централизованного поиска по всем правкам в ДОП, а также по неопубликованным документам ДОП;

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

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

31

3.3 Описание целевого процесса

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

1) Любой пользователь Системы в ИФ «Работа с правкой» подготавливает свою редакцию изменений в документы ДОП (правку).

2) Внутренние пользователи Системы имеют возможность сохранить созданный документ в Системе, с возможностью последующего продолжения работы с ним на ИФ «Накопитель правок», в том числе объединить несколько правок в одну для вынесения, например, общих технических правок на НС. Внешний пользователь имеет возможность сохранить документ только на свой компьютер.

32

3) После проведения НС, пользователи Системы с ролью (корректор/модератор) имеют возможность подготовить новую версию документа ДОП в Системе с учетом принятых на НС изменений в ИФ «Работа с каталогом неопубликованных документов» (КНД).

4) Корректоры должны иметь возможность направить уведомление через Систему всем Кураторам о необходимости внесения изменений в «Справочник переменных ДОП».

5) Кураторы вносят изменения в документы ДОП, после чего изменения становятся доступны для использования всем пользователям Системы.

6) Корректоры готовят новые редакции документов ДОП, используя функциональность ИФ «Каталог неопубликованных документов», при этом документы получают статус «Готов к Публикации». Далее документы проходят все необходимые проверки, в том числе контроль необходимости внесения изменений в «Справочник переменных ДОП», после чего документам ДОП в статусе «Готов к Публикации» и прошедшим все проверки устанавливается статус «Опубликован».

7) Результатом/завершением процесса сопровождения изменений в документы ДОП является опубликованный документ, доступный на просмотр в КОД любому пользователю Системы (в том числе не аутентифицированному).

4 Требования к Системе

4.1 Требования к функциям Системы

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

1. Доступ пользователей к функциям и данным Системы должен определяться предоставленными им ролями. Определение ролей пользователей (их авторизация) Системой должно быть реализовано на основе механизма учётных записей.

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

Роли/Пользователи

Системы

ФункцииПоиск и чтение

документов

Создание таблиц

изменений2

Работа с накопителем

таблиц изменений

Создание / редактирование / публикация

документов

Управление справочнико

м переменных

Управление

ролями

Внешний пользователь

+ +

Внутренний пользователь + + +

Корректор + + + +Модератор + + + + +Куратор + + + +Администратор +

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

2 Для роли «Внешний пользователь» должно быть доступно создание ТИ (правок) без возможности сохранения в Системе

33

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

4.1.2 Типы данных, атрибуты и статусы документов, обрабатываемых Системой

1) В Системе должно быть реализовано хранение данных следующих типов: ДОП, договор Регламент Правка Таблица изменений Переменная

2) При создании или загрузке документа в Систему, пользователь должен иметь возможность указать необходимые атрибуты, которые должны быть ему присвоены:

Тип документа – ДОП / Регламент/Договор/Правка/ТИ.Номер документа – номер соответствующего документа, для документа с типом «ТИ» данный атрибут должен содержать номер соответствующего документа ДОП (см. пример в Приложении 7.4).Дата вступления в силу – Дата вступления в силу редакции документа ДОП, определенная на НС. Может быть меньше текущей даты.Дата окончания – Дата окончания действия редакции документа ДОП, определенная на НС. По умолчанию ставится дата «01.01.3000»).Дата НС – дата НС, с которой действует текущая редакция документа.Комментарий – произвольное текстовое поле.Инициатор – автор создания документа с типом «Правка» / «ТИ».Является приложением – произвольное текстовое поле.

Документы ДОП - Список номеров документов ДОП, использующихся в правке. Заполняется из выпадающего списка номеров документов ДОП (договоров и регламентов). Может быть выбрано несколько значений. При сохранении список должен быть отсортирован по возрастанию.

34

Атрибут документа ДОП Регламент Договор Правка ТИ

Тип документа + + + + +

Номер документа + + + – +

Дата вступления в силу + + + + +

Дата окончания +/– +/– +/– +/– +/–

Дата НС + + + + +

Комментарий +/– +/– +/– +/– +/–

Инициатор – – – + +

Является приложением – +/– +/– – –

Документы ДОП – – – +/– –

Условные обозначения:

«+» – обязательный атрибут

«+/–» – необязательный атрибут

«–» – не заполняется

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

Название статуса

Возможные значения Интерпретация Обяза-

тельностьТипы документов

Примеча-ние

Статус публикации

«Не опубликован»

Присваивается документу при создании или импорте. Да

ДОП, Регламент, Договор, Таблица изменений (правка)

См пункт 4.1.3

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

См пункт 4.1.9

«В работе» Присваивается Нет ДОП, 35

Статус документов ДОП

неопубликованному документу в КНД при работе авторизованным пользователем Регламент,

Договор, Таблица изменений

См. пункт 4.1.8

«Готов к публикации»

Присваивается неопубликованному документу в КНД после прохождения всех проверок

Статус правок «Текущие правки»

Присваивается документу при работе авторизованным пользователем

Нет ПравкаСм. пункт 4.1.5

«Архив» Присваивается документу после перемещения его в Архив

4) В Системе должна быть возможность заведения дополнительных признаков для документов:

Название признака

Возможные значения Интерпретация Обяза-

тельностьТипы документов

Примеча-ние

Редактирование доступа данных

«Видно только мне»

Присваивается документу при работе с ним авторизованным пользователем, означает, что документ не доступен на просмотр другим авторизированным пользователям

Нет Правка См. пункт 4.1.5«Закрытое

редактирование»

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

Признак актуальности документов ДОП

«Утратил силу»

Присваивается опубликованному документу, переставшему быть актуальным

Нет

ДОП, Регламент, Договор, Таблица изменений

См пункт 4.1.11

5) При добавлении нового элемента в «Справочник переменных ДОП» или при изменении существующего, пользователь должен иметь возможность указать необходимые (обязательные) атрибуты, которые должны быть присвоены переменной:

Наименование – текстовое или символьное (формульное) наименование переменной в формате TeХ, в том числе с указанием верхних и/или нижних индексов переменной;

Краткое описание – пояснение к наименованию переменной; Определение – подробное описание переменной из пункта-определения переменной в

документе ДОП.36

Дата начала действия – Дата вступления в силу редакции документа ДОП, где определяется/изменяется переменная. Может быть меньше текущей даты.

Дата окончания действия – Дата вступления в силу редакции документа ДОП, где переменная удаляется. По умолчанию ставится дата «01.01.3000».

 Идентификатор Множественность

Изменяемость

Обязательность

Метод заполнения

Тип данных

Роль заполнения

Наименование Ед Перем О Ручной ввод Текст

КураторКраткое описание Ед Перем О Ручной ввод Текст

Определение Ед Перем О Ручной ввод Текст

Дата начала действия

Ед Перем О Ручной ввод Дата

Дата окончания действия

Ед Перем О Nvl (Ручной ввод, Авто)

Дата

Полный перечень атрибутов переменной ДОП, включая дополнительные, приведен в Приложении 7.6.

4.1.3 Импорт документов и переменных в хранилище Системы

1) Должна быть реализована функция импорта документов ДОП и Таблиц изменений в Систему. Требуется поддержка импорта документов в формате Microsoft Office Word (2003 и более поздние версии). При этом пользователь в интерфейсе Системы должен иметь возможность указать путь к импортируемому файлу, а также указать тип документа и задать соответствующие типу значения атрибутов. После импорта значение атрибута «Статус публикации» для документа должно быть установлено равным «Не опубликован».

2) При импорте документа любого типа кроме ТИ, Система должна выполнить его преобразование во внутреннее представление, при этом должно быть предусмотрено автоматическое выявление структуры документа (нумерованные заголовки / пункты, абзацы и списки) и формул в тексте документа для целей его дальнейшего редактирования, в том числе для разметки гиперссылками.

3) Пользователь должен иметь возможность при импорте указать необходимость преобразования документа во внутреннее представление, при этом импортированные без преобразования документы должны храниться в Системе в исходном виде в формате MS Office Word. Такие документы не предполагают редактирование в рамках Системы, и требования к функциональности Системы по работе с такими документами ограничиваются пунктами, включёнными в разделы 4.1.8 – 4.1.11.

4) Необходимо реализовать механизм автоматизированного пакетного импорта документов. С помощью данного механизма в Систему перед началом промышленной эксплуатации должны быть загружены все документы ДОП, опубликованные на сайте НП СР. Механизмом импорта должно быть предусмотрено автоматическое заполнение значений атрибутов импортируемых документов в хранилище Системы на основе информации о структуре хранения документов на сайте НП СР, имен файлов или иных сведений. Документы должны импортироваться с установлением значения атрибута «Статус публикации» равным «Не опубликован». Также для всех документов должна быть

37

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

5) Необходимо реализовать механизм автоматизированного пакетного импорта переменных. С помощью данного механизма в Систему перед началом промышленной эксплуатации должны быть загружены все действующие на момент импорта переменные ДОП. Механизмом импорта должно быть предусмотрено автоматическое заполнение значений атрибутов импортируемых переменных в хранилище Системы на основе информации об атрибутах, содержащихся в подготовленном Заказчиком сводном загрузочном файле о переменных и их атрибутах.

4.1.4 Работа с правкой ДОП

1) В Системе должна быть реализована ИФ для возможности подготовки правки в форме ТИ или совокупности нескольких ТИ с применением шаблонов ТИ для последующего рассмотрения правки на НС.

2) Доступ к данной ИФ должен быть предоставлен всем пользователям Системы, в том числе не аутентифицированным.

3) Одна правка ДОП может содержать несколько ТИ, при этом каждая ТИ может быть добавлена в отношении только одного документа ДОП (см. шаблоны ТИ).

4) Создание правки должно предусматривать следующие шаги: Заполнение правки по шаблону (см шаблон правки). Включение в правку новой ТИ по шаблону (одной или нескольких). Заполнение новой ТИ текстом действующего документа ДОП. По необходимости, дополнение включённых ранее ТИ текстом документов ДОП,

либо добавление новых ТИ. Редактирование текста внутри документа (таблицы изменений) с использованием

всех возможностей Системы. Сравнение 2 редакций документа, с выделением различий в тексте действующей

редакции документов ДОП и отредактированной версии. Проверка корректности ссылок из других документов ДОП, ссылающихся на

редактируемые в ТИ разделы документов ДОП. Добавление произвольных табличных форм в правку в качестве приложений. Создание ПЗ к правке по (шаблону). Сохранение правки ДОП с заполнением атрибутов правки.

5) В данной ИФ должна быть предусмотрена возможность создания новой правки по шаблону (см шаблон правки)

6) Внутри созданной правки в данной ИФ должна быть предусмотрена возможность создания новой таблицы изменений ДОП в виде последовательности следующих шагов:

пользователь в интерфейсе Системы открывает документ ДОП на просмотр; пользователь выделяет мышью текст, затем выбирает команду создания таблицы

изменений на основании выделенного текста; Система создает таблицу изменений по шаблону ТИ (см. Шаблон таблицы

изменений).7) После создания новой ТИ в Системе должна быть предусмотрена возможность

заполнения новой Таблицы изменений (ТИ) в интерфейсе по следующим правилам: Заполнить наименование таблицы изменений текстом из шаблона; Заполнить первую колонку таблицы изменений номерами пунктов в изменяемом

документе, соответствующими номерам пунктов скопированных фрагментов текста из исходного документа;

38

Заполнить оставшиеся две колонки скопированным выделенным текстом с сохранением ссылок и правил форматирования – нумерацией, отступами и шрифтами.

8) После создания новой ТИ в Системе должна быть предусмотрена возможность дополнения правки ДОП. Возможны 2 варианта дополнения правки ДОП:

Дополнение правки ДОП новым текстом внутри редактируемой ТИ.

Дополнение таблицы изменений ДОП должно выполняться в последовательности следующих шагов:

пользователь в интерфейсе Системы открывает документ ДОП на просмотр; пользователь выделяет мышью текст, затем выбирает команду дополнения таблицы изменений на основании выделенного текста; Система должна дополнить таблицу изменений (в рамках того же вида и номера ТИ). Новый текст должен быть добавлен в редактируемую ТИ ниже текущего текста новой строкой.

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

Дополнение правки ДОП новой ТИ.

Добавление новой таблицы в текущую правку ДОП должно выполняться в последовательности следующих шагов:

пользователь в интерфейсе Системы открывает документ ДОП на просмотр; пользователь выделяет мышью текст, затем выбирает команду создания таблицы изменений на основании выделенного текста; Система создает таблицу изменений по шаблону ТИ (см. Шаблон таблицы изменений).

Новая Таблица изменений в уже редактируемую правку должна добавляться ниже текущей/текущих ТИ.Заполнение новой ТИ (см. п. 7 текущего раздела).

9) В данной ИФ должна быть предусмотрена возможность редактирования документа (в т.ч. текста правки в ТИ в колонке «Предлагаемая редакция»).Редактирование документа должно предусматривать следующую функциональность:

Редактирование текстаВ Систему должен быть встроен текстовый WYSIWYG редактор для ввода и редактирования документовТекстовый редактор должен поддерживать ограниченный набор стилей форматирования: Заголовок 1-го уровня. Заголовок 2-го уровня. Заголовок 3-го уровня. Маркированный список. Нумерованный список.

39

Обычный текст. Цитата.Текстовый редактор должен поддерживать возможность вставки в текст изображений в форматах JPEG и (или) PNG, произвольных таблиц. Изображения загружаются и хранятся в Системе.Система должна позволять копировать текст из внешних источников через буфер обмена с сохранением форматирования текста.

Добавление / удаление переменной из «Справочник переменных ДОП» включает в себя шаги:

Определение местоположения для добавления / удаления переменной в тексте документа.

Выбор необходимой переменной из «Справочник переменных ДОП» для добавления /удаления переменной в тексте.

Обновление информации по переменным из «Справочника переменных ДОП». При обновлении осуществляется проверка корректности наименований переменных (см п. 5 раздела «Работа с переменными ДОП»).

Навигация по выбранной переменной (перемещение внутри текущего документа ДОП к предыдущей / следующей, к первому / последнему упоминанию переменной).

Добавление / изменение / удаление формулы: В Системе должен быть реализован редактор формул. Возможности по

редактированию формул должны быть аналогичны функциям Microsoft Equation 3.0. Редактор формул должен позволять добавлять переменные в тело формулы из справочника переменных, при этом ссылка на переменную должна оставаться активной (ссылка на источник переменной в «Справочнике переменных ДОП»).

Редактор формул должен поддерживать копирование в буфер обмена и вставку формул из Microsoft Office Word (для версий Microsoft Office 2013 и выше).

Добавление / изменение / удаление гиперссылки на раздел / пункт / буллит в текущем или другом документе:

Переход по гиперссылке в текущий или другой документ. При изменении номера пункта или раздела, на который ссылаются иные пункты

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

Проверка корректности гиперссылок в редактируемом документе: поиск ссылок на пункты / разделы, которые не определены.

10) В системе должно быть предусмотрено два способа сравнения редактируемого текста (исходной и результирующей редакции):

1 вариант (сравнить изменения в текущей ТИ):Система должна предоставить возможность пользователю автоматического сравнения 2 частей ТИ (действующая редакция и предлагаемая редакция). В результате сравнения различия в документе должны выделяться цветом.

2 вариант (сравнить изменения прямо в исходном тексте документа ДОП): пользователь в интерфейсе Системы открывает документ ДОП на просмотр; пользователь вводит новый текст внутри открытого документа, затем выбирает

команду «Показать внесенные изменения».

40

Система должна сформировать новую ТИ на основе внесенных в документ изменений с цветовым выделением различий. В ТИ попадают лишь те разделы документа, которые изменились.

Далее у пользователя должна быть возможность добавить созданную Системой ТИ в правку ДОП. Добавление ТИ в правку должно быть реализовано аналогично п. 8 настоящего раздела:

в случае того же вида и номера ТИ, Система должна дополнить таблицу изменений. Новый текст должен быть добавлен в редактируемую ТИ ниже текущего текста новой строкой.

новая Таблица изменений в уже редактируемую правку должна добавляться ниже текущей/текущих ТИ.

11) В Системе должна быть предусмотрена возможность просмотра списка документов и разделов, ссылающихся на данный документ или на выбранный раздел документа в разделе ТИ («Редакция, действующая на момент вступления в силу изменений»). В рамках данной функциональности Система должна:

Переходить по гиперссылке из окна просмотра списка ссылок (из данного документа в просмотр текущей редакции документа ДОП, содержащего закладку).

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

12) В Системе должна быть предусмотрена возможность добавления произвольных табличных форм (например, для внесения изменений в Приложения к Регламентам (см приложение)

13) В Системе должна быть предусмотрена возможность сформировать по шаблону и заполнить Пояснительную записку к правке. (см приложение)

14) В Системе должна быть предусмотрена возможность сохранения созданной правки: В БД (для авторизованных пользователей). На ПК в формате MS Office Word (для любого пользователя Системы).

При сохранении в Системе должно быть реализовано заполнение пользователем атрибутов новой правки, по которым можно будет идентифицировать правку в Системе (см. далее раздел Работа с накопителем правок).

4.1.5 Работа с накопителем правок (НП)

1) В Системе должна быть реализована ИФ «Накопитель правок» (НП), в которой должны отображаться все документы с типом «Правка».

2) Данная ИФ доступна ролям: внутренний пользователь, модератор, куратор.3) Пользователи должны иметь возможность отфильтровать перечень документов по

заданным параметрам (см. список атрибутов правки п. 4.1.2). Если фильтры не заданы, то в НП отображаются все правки Системы.

4) При создании правки в Системе она автоматически получает признак «Видно только мне». При работе в НП пользователь имеет возможность снять этот признак. При снятии признака, документ становится виден в НП всем пользователям.

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

41

редактировании. Такие документы получают статус «Закрытое редактирование» и не доступны на просмотр/редактирование другим пользователям. При снятии признака, документ становится виден в НП всем пользователям.

6) Работа в НП по созданию (или «склейке») новой правки на основе нескольких выбранных правок должна включать в себя шаги:

Выбрать необходимые правки Объединить выбранные правки – создать объединенную правку с атрибутами

правки (см п. 4.1.2). Внутри объединенной правки отсортировать ТИ по наименованиям. Внутри объединенной правки объединить в единую таблицу ТИ с одинаковым

наименованием. При этом Система должна автоматически отсортировать строки по первым колонкам таблиц (по пунктам исходного документа).

Редактировать объединенную правку с учетом всех возможностей Системы по редактированию текста (см п.9 раздела «Работа с правкой ДОП»).

Сохранить объединенную правку в Систему. В Системе также должна быть предусмотрена возможность сохранения пользователем объединенной правки в формате MS Office Word в произвольно задаваемую директорию.

Присвоить исходным (выбранным) правкам статус «Архив».7) Система должна автоматически присваивать правкам со сроком создания больше одного

года статус «Архив».8) При попытке изменения параметров или работы с уже открытым другим пользователем

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

9) В Системе должна быть предусмотрена возможность удалить правку.

4.1.6 Работа с переменными ДОП

1) В Системе должен быть предусмотрена ИФ «Справочник переменных ДОП» для корректного использования (добавления/изменения) переменных в документах ДОП).

2) Данная ИФ доступна пользователю с ролями: куратор/модератор.

3) Работа с переменными ДОП должна предусматривать следующую функциональность: Создание переменной ДОП («Карточки переменной»). Изменение переменной ДОП. Просмотр ссылок на документы по источникам использования переменной.

4) В Системе должна быть предусмотрена возможность создания/изменения переменной. Для создания переменной пользователь должен выполнить следующие шаги:

Открыть «Справочник переменных ДОП». Выбрать функцию Создание новой переменной. Заполнить все необходимые атрибуты и значения (см раздел 4.1.2). Атрибут

«Наименование переменной» должен заводиться в Системе с помощью редактора формул в порядке, аналогичном описанному в разделе 4.1.4 п 9), при этом заведённое значение должно сохраняться в Системе в нотации TeX.

Сохранить внесенные изменения.При сохранении изменений Система должна обеспечить проверку внесенных изменений - проверить уникальность наименования переменной. В случае, если наименование не уникально - выдавать ошибку, прерывать выполнение операции.

42

5) В Системе должна быть предусмотрена возможность изменения выбранной переменной. (Возможность изменения любых атрибутов «Карточки переменной» (см Приложение 7.6.). При изменении «Наименования переменной» необходима повторная проверка на уникальность новой переменной (см п.4).

6) Во время редактирования переменной пользователем Система должна обеспечивать недоступность данной переменной для изменения ее другим пользователям.

7) В Системе должна быть предусмотрена возможность формирования списка по источникам использования переменной: Система должна предусматривать возможность отображения перечня документов, содержащих выбранную переменную (внутри ВСЕХ действующих на текущую дату документов Системы), с указанием номеров соответствующих документов и пунктов разделов внутри документа, где встречается переменная (куда она ранее была добавлена как гиперссылка). (см. Приложение 7.5.1).

8) В «Карточке переменной» должен быть указан номер документа ДОП и раздел, где она впервые определена, а также возможность перехода в текст этого документа.

9) В Системе должна быть предусмотрена возможность отображения перечня всех переменных ДОП Системы, актуального на указанную дату, с возможностью выгрузки в формат MS Office Excel. Данная возможность необходима Заказчику для последующей интеграции со смежными системами Заказчика с целью синхронизации (установления связи) переменных ДОП и ТЗ на внутренние системы Заказчика.

10) В Системе должна быть предусмотрена возможность отображения перечня всех изменений по переменным ДОП, сформированных на указанный период, с возможностью выгрузки в формат MS Office Excel. Данная возможность необходима Заказчику для последующей интеграции со смежными системами Заказчика с целью синхронизации (установления связи) переменных ДОП и ТЗ на внутренние системы Заказчика.

4.1.7 Отправка уведомления на электронную почту

Пользователь с ролью «Корректор» или «Модератор» должен иметь возможность отправить сообщение по электронной почте одновременно всем пользователям с ролью «Куратор». Сообщение должно содержать стандартную формулировку о необходимости внесения изменений в «Справочник переменных ДОП» в связи с принятием изменений на очередном НС.

Примечание. Данное требование необходимо для того, чтобы после принятия правки на НС корректор смог включить при необходимости в новую редакцию документа ДОП новые переменные или изменить существующие переменные.

4.1.8 Работа с каталогом неопубликованных документов ДОП (КНД)

1) В Системе должна быть реализована ИФ «Каталог неопубликованных документов» (КНД) для работы по изменению редакций документов ДОП в соответствии с принятыми изменениями (правками) на НС.

2) Данная ИФ доступна ролям: модератор, корректор.

43

3) Все документы, в статусе «Неопубликованные» должны находится в указанном Каталоге. 4) Работа в КНД по созданию новой редакции документа ДОП на основании принятых

изменений должна предусматривать следующие шаги: Создание новой редакции документа ДОП (с нуля/ на основе действующей

редакции документа ДОП/на основе неопубликованной редакции документа ДОП). Заполнение пользователем атрибутов нового документа ДОП (см раздел 4.1.2). Импорт необходимых неопубликованных документов в КНД (например, ТИ). Работа по наполнению нового документа изменениями из правок. Редактирование текста внутри создаваемого документа Сравнение Системой различий текста действующей редакции документа ДОП и

отредактированной версии. Сохранение созданного документа в Систему с проверками.

5) В Системе должна быть предусмотрена возможность создания нового документа ДОП 3 способами:

Новый документ ДОП На основе действующей редакции документа ДОП. При этом пользователю должен

быть предоставлен выпадающий список всех действующих документов ДОП, сгруппированных по типам и отсортированных по номерам.

На основе неопубликованной редакции документа ДОП. При этом пользователю должна быть представлена возможность выбора в Системе списка документов, созданных в КНД со статусом «В работе» сгруппированных по типам и отсортированных по номерам.

При создании в КНД новый документ получает статус «Неопубликованный», а также статус «В работе».

6) При создании новой редакции документа ДОП в КНД пользователю необходимо заполнить соответствующие атрибуты документа ДОП (см раздел 4.1.2)

7) В Системе пользователю для работы в КНД должна быть предоставлена возможность импорта из внешнего источника необходимых документов (см п. 4.1.3), например, ТИ, созданных из принятых правок в формате MS Office Word. При импорте ТИ из внешнего источника, Система должна обеспечить необходимость заполнения пользователем атрибутов импортируемого документа (см п. 4.1.2).

8) В КНД пользователю должна быть предоставлена возможность видеть отдельное окно со списком импортированных правок в статусе «В работе», а также окно для работы с редактируемым документом. При этом Система должна обеспечить возможность добавлять текст из выбранной правки в редактируемый документ.В КНД должна быть предусмотрена возможность редактирования текста создаваемого документа ДОП с учетом всех возможностей Системы по редактированию (п. 9 раздела «Работа с правкой ДОП»).

9) В КНД должна быть предусмотрена возможность сравнения двух версий документа в статусе «В работе» для того, чтобы установить какие изменения были внесены в документ/редакцию документа. При этом:

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

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

44

10) При сохранении изменений в редактируемом документе Система должна автоматически проверять корректность гиперссылок (разметки в тексте) и ссылок на переменные. Если проверка не пройдена Система выдает сообщение с перечислением ошибок.Варианты ошибок в переменных (см Приложение 7.5.3):

отсутствует определение у переменной (из справочника переменных). переменная удалена (из справочника переменных).

Варианты ошибок в тексте документа (см Приложение 7.5.4): ссылка на несуществующий пункт. ошибка в источнике ссылки.

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

4.1.9 Подготовка и публикация документов

1) В Системе должна быть предусмотрена возможность публикации документов, из КНД в ИФ «Каталог опубликованных документов» (КОД). Визуальное представление ИФ «Каталог опубликованных документов» (КОД) должно быть аналогично текущему размещению опубликованных документов на внешнем сайте НП СР. В рамках этого процесса созданный документ ДОП должен автоматически менять свой статус в Системе с «Неопубликованного» на «Опубликованный».

2) Работа по подготовке и публикации документов КНД должна предусматривать следующие шаги:

Смена статуса редактируемого документа. Сортировка редактируемых в КНД документов. Редактирование уже существующего неопубликованного документа. Изменение атрибутов документа (см также раздел 4.1.2). Проверка документа/документов перед публикацией. Публикация выбранного документа КНД (или сразу нескольких выбранных

документов) в статусе «Готов к публикации» в КОД.

3) В Системе должна быть возможность смены статуса документа ДОП с «В работе» на «Готов к публикации». Система должна предоставлять возможность публиковать документы через КНД только в статусе «Готов к публикации».

4) В Системе должна быть возможность сортировки редактируемых в КНД документов.Документы в КНД в статусе «Готов к публикации» должны быть упорядочены: сгруппированы по типу, затем упорядочены по номеру документа, все версии одного документа ДОП должны быть сгруппированы: сначала отображается минимальная по дате вступления версия документа, редакции документа второй по дате вступления и последующих версий необходимо отображать под первой по дате вступления версией в виде выпадающего списка. При этом, если у документа ДОП есть опубликованные версии с датой вступления в силу позже предполагаемой даты вступления изменений в силу, Система должна уведомить пользователя о наличии документов, требующих актуализации.

5) В Системе должна быть возможность редактирования уже существующего неопубликованного документа. Редактирование состоит из шагов:

Выбор документа в Каталоге на редактирование. Открытие документа на редактирование (см. раздел «Работа с КНД»).

45

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

6) В КНД должна быть реализована возможность изменения атрибутов создаваемых документов. Шаги по изменению атрибутов создаваемых документов ДОП включают в себя:

Выбор документа в Каталоге. Открытие окна изменения атрибутов документа ДОП. Изменение атрибутов документа ДОП (см. раздел 4.1.2) Сохранение атрибутов (также должна быть возможность отменить внесение

изменений в атрибуты документа) и обновление информации по документу в КНД.

7) В Системе должны быть обеспечены следующие проверки документов в Статусе «Готов к Публикации»:

Для непреобразованных документов ДОП, импортируемых в Систему в рамках раздела п.4.1.3 (в формате MS Office Word):

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

Для ТИ (формат MS Office Word): Проверка заполнения необходимых атрибутов документа (см раздел 4.1.2). Проверка наличия опубликованного документа ДОП, к которому относится

соответствующая ТИ на соответствующую дату вступления в силу.

Для документов ДОП: Проверка заполнения необходимых атрибутов документа (см раздел 4.1.2). Проверка корректности гиперссылок (см. п.10 раздела «Работа с КНД»). Проверка неиспользуемых переменных в документах ДОП (см. п.10 «Работа с

КНД»).

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

8) В Системе должна быть реализована возможность публикации выбранного в Каталоге документа (или сразу нескольких выбранных документов) в КОД. Публикация документов ДОП в Системе должна происходить следующим образом:

Система должна отображать список документов в статусе «Готов к Публикации» после проведения всех проверок (см. п.7).

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

В зависимости от типа документа, его номера и других атрибутов документа (см 4.1.2), Система должна публиковать документ в соответствующий раздел КОД. При этом для ТИ Система должна предусматривать необходимость первоначальной публикации соответствующего документа ДОП.

В Системе должна быть предусмотрена возможность публикации документов в формате MS Office Word, например, для непреобразованных документов (см раздел 4.1.3).

При публикации документы меняют статус в Системе с «Неопубликованного» на «Опубликованный».

46

Отображение опубликованных документов ДОП в ИФ КОД должно быть реализовано аналогично текущему отображению версий документов на сайте НП СР, в том числе, необходимо реализовать все фильтры, существующие в настоящий момент на сайте НП СР.

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

4.1.10 Работа с каталогом опубликованных документов (КОД)

1) В Системе должна быть реализована ИФ «Каталог опубликованных документов» (КОД) для поиска и просмотра опубликованных документов и их атрибутов.

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

3) Доступ к данной ИФ должен быть предоставлен всем пользователям Системы, в том числе не аутентифицированным.

4) Форма поиска опубликованных документов ДОП в КОД должна быть реализована аналогично текущей форме поиска документов ДОП на сайте НП СР.

5) Параметры поиска должны включать в себя следующий перечень: наименование документа (выпадающий список); тип документа; номер документа ДОП; дата вступления (от/до); дата НС (от/до); полнотекстовый поиск по наименованию документа.

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

6) В результате поиска, найденные документы должны отображаться в КОД в структуре вложенности (иерархической структуре списка документов ДОП (см Приложение 7.5.5)). При этом для каждого найденного документа должны отображаться его атрибуты: тип документа, номер документа, дата НС, дата вступления в силу.

7) Для всех найденных документов должны перечисляться все даты НС, на которых были приняты редакции этих документов с датой вступления в силу, попадающей в заданный диапазон дат вступления в силу (см. п.5).

8) При работе с данной ИФ должна быть дополнительная возможность просмотра текущих версий документов ДОП. В выборку документов ДОП на текущую дату должны попадать все документы ДОП с последней (максимальной) датой вступления в силу, которая наступает не позднее текущей даты.

9) Для преобразованных документов (см раздел 4.1.3) в Системе должен быть предусмотрен просмотр найденного документа. В рамках этой функциональности в Системе должно быть обеспечено следующее: При просмотре найденного документа пользователь Системы должен иметь

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

47

Система должна предоставлять возможность текстового поиска внутри документа: быстрый поиск пункта (при просмотре документа на экране целиком отображается структура документа с уровнем вложенности до подпунктов и буллитов с выделением разделов, где введенный текст встречается). (см Приложение 7.5.7).

В Системе должен быть обеспечен переход к предыдущему/следующему месту просмотра документа (в том числе при перемещении по гиперссылкам внутри документа).

В Системе должна быть предусмотрена возможность перехода по гиперссылке из окна просмотра списка гиперссылок (в этот или иной документ ДОП данного среза данных):

У пользователя должна быть возможность, нажав на гиперссылку из списка, перейти по ней на закладку, которая может быть расположена в этом или другом документе в рамках одного и того же среза данных.

Пользователю должна быть доступна возможность просмотра и перехода по гиперссылкам в тексте документа (закладка может быть расположена в этом или другом документе в рамках одного и того же среза данных).

В Системе должна быть предусмотрена возможность печати выделенного фрагмента текста, копирования выделенного текста в буфер обмена.

10) Для непреобразованных документов (см раздел 4.1.3) в Системе должна быть доступна функция просмотра найденного документа в формате MS Office Word. В рамках этой функциональности пользователь Системы должен иметь возможность также сохранить документ у себя на ПК в формате MS Office Word.

4.1.11 Работа с документами, утратившими силу

1) В Системе должна быть реализована ИФ для возможности работы с опубликованными документами ДОП, переставшими быть актуальными.

2) Данная ИФ доступна ролям: модератор, куратор.3) Работа с документами, утратившими силу должна предусматривать следующие шаги:

Поиск документа по атрибутам (см. раздел 4.1.2). Просмотр документа. Присвоение документу статуса «Утратил силу».

4) Система должна автоматически при появлении у документа статуса «Утратил силу» перемещать документ, опубликованный в КОД в ИФ «Документы, утратившие силу» (http://www.np-sr.ru/regulation/joining/obsoleted/index.htm).

5) Система должна предоставлять возможность отката изменения (возможность убрать статус «Утратил силу»).

4.1.12 Функции администрирования

1) Пользователь с правами Администратора должен иметь возможность: Сменить пароль для любого пользователя Системы; Редактировать права доступа пользовательской роли к определенным функциям и

разделам в интерфейсе Системы; Назначать роли пользователям; Заполнять и редактировать данные профилей пользователей, такие как адрес

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

48

4.2 Нефункциональные требования

4.2.1 Требования к архитектуре

1) Архитектура Системы должна обладать следующими характеристиками: Классическая трехуровневая Централизованная (активные компоненты Системы расположены в едином ЦОД) Web-ориентированная

2) Бизнес-логика должна быть отделена от слоя хранения данных и интерфейса. 3) Архитектура должна позволять развивать Систему как в части пользовательского

интерфейса и функциональности, так и в части объемов хранимых данных (не менее 300 документов, суммарно содержащих 11 000 страниц, 25 000 000 символов и 30 000 формул с ежегодным приростом объема данных в 10%

4) Интерфейс должен быть доступен пользователям без необходимости устанавливать дополнительное программное обеспечение (кроме Web-браузера).

5) Система должна поддерживать интеграцию со смежными Системами через вызов REST API (HTTP). Перечень доступных функций определяется объектами Системы и доступными операциями над ними.

6) Предложенная Исполнителем архитектура решения должна быть подтверждена Заказчиком перед началом разработки.

4.2.2 Требования к технологиям

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

2) Перечень рекомендуемых к использованию технологий

Система управления базами данных PostgreSQL версии 9.2 и вышеWEB-сервер Apache HTTPDСервер приложений Apache TomcatОбъектно-реляционное отображение HibernateБиблиотека клиентских интерфейсов Smartclient версии 10.0 и выше

3) Система должна поддерживать следующий набор Web-браузеровBrowser VersionMicrosoft Internet Explorer Version 11 (only) for Windows Apple Safari 6.1.6 or later (Mac only) Mozilla Firefox 31 or laterGoogle Chrome 35 or later

4) Перечень выбранных Исполнителем технологий должен быть подтвержден Заказчиком перед началом разработки.

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

1) Так как Система предназначена для автоматизации бизнес-критичных функций, необходимо, чтобы в архитектуру Системы была заложена поддержка кластеризации приложений по схеме Active – Standby на случай дальнейшего развития Системы.

2) Должна быть предусмотрена функция резервного копирования данных с возможностью восстановления в режиме Point-in-time.

3) Должна быть обеспечена поддержка систем управления резервным копированием: IBM Tivoli Storage Manager

49

CommVault Simpana4) Все данные Системы должны постоянно сохраняться на дисках, что в случае перебоев с

электропитанием должно позволить избежать их потери.5) Система должна включать средства самодиагностики, корректно обрабатывать

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

4.2.4 Требования к производительности

1) Архитектура Системы должна обеспечивать возможность линейного горизонтального масштабирования каждого из активных компонентов ЦОД (см. п 4.2.1).

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

3) Скорость обработки, передачи информации в Системе, а также время реакции (отклика) пользовательского интерфейса должны удовлетворять требованиям автоматизируемого бизнес-процесса и обеспечивать эффективность и удобство выполнения пользователями своих задач. Конкретные длительности выполнения основных операций в Системе с учётом пиковых нагрузок должны быть оценены и согласованы с Заказчиком перед началом разработки.

4.2.5 Требования к безопасности

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

2) Система должна включать средства обеспечения обмена данными с использованием защищённых каналов связи на базе протокола http с использованием TLS шифрования версии 1.2 или выше (работа по протоколу https).

4.2.6 Требования к результатам разработки

1) В результате разработки Исполнителем должны быть представлены следующие материалы:

Исходные коды Системы; Дистрибутив Системы; Документация на Систему; Развёрнутый на ресурсах Заказчика экземпляр Системы.

2) Дистрибутив Системы должен поддерживать возможности первичной установки Системы, обновления, удаления и автоматической конфигурации общесистемного ПО для соответствия требованиям Системы.

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

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

1) Система должна предусматривать: Ведение журнала всех действий пользователей Системы;

50

Возможность пошагового отката произведенных действий аутентифицированных пользователей Системы в текущей сессии работы с документом;

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

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

3) Система должна предусматривать хранение данных с сохранением принципов историчности и версионности, что должно включать в себя: В рамках принципа историчности Система должна обеспечивать:

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

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

5 Требования к порядку ведения и содержанию работ

При взаимодействии в рамках разработки Системы Заказчик отдает предпочтение гибким методологиям разработки ПО - Scrum и/или Kanban.

5.1 Полномочия и обязанности Заказчика

1) Рассмотрение и согласование разработанной Исполнителем документации на Систему;2) Предоставление необходимых Исполнителю для целей разработки сведений в отношении

действующих процедур поддержки ДОП, уточнения требований к разрабатываемой Системе, имеющихся у Заказчика программно-технических средств и иной требуемой такого рода информации, в том числе результатов разработки пилотной версии программного обеспечения по сопровождению ДОП и исполнительной документации (по запросу);

3) Предоставление Исполнителю доступа к ресурсам инфраструктуры Заказчика, необходимым для развёртывания экземпляра Системы с целью проведения комплексных испытаний Системы и последующего перевода её в опытно-промышленную эксплуатацию;

4) Участие в комплексных испытаниях Системы;5) Направление Исполнителю замечаний к Системе, выявленных в ходе испытаний;6) Контроль соблюдения Исполнителем согласованного с Заказчиком плана-графика работ,

согласование его корректировок.

5.2 Обязанности Исполнителя

1) Разработка и предоставление на согласование Заказчику документации на Систему;2) Выполнение необходимого комплекса работ по созданию Системы;3) Организация регулярных демонстраций представителям Заказчика функционально

завершённых компонентов Системы, а также предоставление актуализированной документации на Систему с целью контроля Заказчиком на ранних стадиях правильности выбранных решений;

4) Предоставление по требованию Заказчика и в согласованные с ним сроки отчётов о результатах выполняемых Исполнителем работ;

51

5) Выполнение работ, необходимых для ввода Системы в эксплуатацию, в том числе установка и настройка Системы на ресурсах инфраструктуры Заказчика, проведение комплексных испытаний, обучение сотрудников службы эксплуатации Заказчика установке, настройке и обслуживанию комплекса программно-технических средств Системы;

6) Устранение недоработок и ошибок в сроки, согласованные с Заказчиком, выявляемые по результатам проведения комплексных и повторных испытаний, а также в результате опытной эксплуатации;

7) Предоставление дистрибутива Системы, исходных кодов и комплекта документации;8) Разработка, актуализация и согласование с Заказчиком плана-графика работ.

5.3 План-график работ по созданию Системы

1) Исполнитель должен согласовать с Заказчиком и предоставить на согласование детальный план-график работ с указанием предельных сроков выполнения работ и подписать его одновременно с договором на разработку Системы в срок не позднее, чем 10 (десять) рабочих дней с момента заключения между Заказчиком и Исполнителем договора на разработку Системы;

2) Исполнитель также обязан согласовать и утвердить с Заказчиком детальные планы-графики работ по этапам на каждом предваряющем этапе работ по проекту в срок не позднее, чем 5 (пять) рабочих дней до начала очередного этапа работ, по которому согласовывается детальный план-график;

3) План-график должен содержать все мероприятия по созданию и внедрению Системы, как со стороны Исполнителя, так и со стороны Заказчика;

4) При необходимости, план-график и/или детальные планы-графики могут быть скорректированы Исполнителем по согласованию с Заказчиком;

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

Технического задания и Архитектурного документа; Разработка компонентов Системы; Промежуточные демонстрации отдельных компонентов Системы Заказчику; Комплексные испытания Системы в соответствии с программой и методикой

испытаний; Доработка Системы по результатам испытаний; Передача Заказчику дистрибутива Системы, исходных кодов и комплекта

документации;

5.4 Регулярные демонстрации

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

2) Периодичность проведения демонстраций должна быть согласована Исполнителем с Заказчиком на этапе составления плана-графика работ, но не должна быть реже, чем один раз в месяц;

3) Исполнитель должен выполнять подготовку и предварительное согласование с Заказчиком сценариев проведения демонстраций, а также подготовку всех необходимых для этого тестовых данных (загружаемых файлов, данных внутри Системы, атрибутирование документов, их разметка и т. д.);

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

52

5.5 Испытания и приёмка Системы

1) Приёмка и перевод в опытно-промышленную эксплуатацию разработанной Системы должны осуществляться по результатам проведения комплексных испытаний Системы и её опытной эксплуатации в промышленном контуре инфраструктуры Заказчика.

2) Порядок проведения и объёмы испытаний Системы должны быть достаточными для подтверждения удовлетворения Системы требованиям, изложенным в настоящем документе, а также разработанному Техническому заданию и требованиям Архитектурного документа.

3) Комплексные испытания Системы должны проводиться в соответствии с документом Программа и методика испытаний Системы, разработанным Исполнителем и согласованным с Заказчиком.

4) В рамках комплексных испытаний должна быть проверена работоспособность всех функций Системы и корректность получаемых результатов, как по отдельности, так и при решении типовых пользовательских задач автоматизируемого Системой бизнес-процесса.

5) Комплексные испытания должны проводиться на стенде в тестовом контуре инфраструктуры Заказчика с участием уполномоченных представителей Заказчика в заранее оговорённые, не позднее чем за десять рабочих дней до начала испытаний, сроки.

6) По результатам комплексных испытаний должен быть оформлен документ Протокол комплексных испытаний Системы, содержащий сведения о результатах испытаний.

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

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

9) Опытно-промышленная эксплуатация Системы должна проводиться в соответствии с документом Программа опытно-промышленной эксплуатации, подготавливаемым Заказчиком.

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

11) По факту завершения опытной эксплуатации должно приниматься решение о готовности Системы к промышленной эксплуатации, либо, в противном случае, должен быть сформирован перечень необходимых доработок с указанием рекомендуемых сроков их реализации.

5.6 Устранение замечаний

1) Замечаниями должны считаться любые несоответствия в реализации Системы настоящим Техническим требованиям, а также разработанным Исполнителем и согласованным с Заказчиком документам Техническое задание и Архитектурный документ, выявленные в ходе испытаний Системы.

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

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

53

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

4) Проблема с замечанием должна считаться решенной только в том случае, если Заказчик подтверждает устранение этого замечания.

6 Требования к документированию

1) Перечень подлежащих разработке документов должен включать в себя: Техническое задание на разработку системы; Архитектурный документ; Эксплуатационную документацию; Программу и методику испытаний Системы; Набор документов для передачи Системы в эксплуатацию.

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

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

Функциональную схему компонентов Системы; Описание системных, структурных и иных ограничений, которые должны быть

учтены при реализации компонентов Системы; Описание связей и зависимостей между функциональными компонентами

Системы; Компонентную схему комплекса технический средств, включая оценку требований

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

обеспечивает требуемую функциональность; При необходимости, описание реализуемых программных интерфейсов.

4) Эксплуатационная документация на Систему должна включать в себя: Руководство пользователей; Руководство администратора; Руководство системного администратора; Руководство программиста.

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

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

Документ должен быть удобен для быстрого поиска описаний функций Системы, в том числе благодаря использованию перекрёстных ссылок;

Документ должен содержать описание порядка выполнения в Системе пользователями типовых задач;

54

Описываемые в документе функции Системы и задачи, решаемые пользователями, должны быть сгруппированы в соответствии с пользовательскими ролями, для которых эти функции доступны;

Документ должен при описании функций содержать снимки экрана реализованной Системы для наглядной демонстрации их работы;

Документ должен содержать методические рекомендации по последовательному выполнению пользователями отдельных задач, как в Системе, так и за её границами, для достижения целей в рамках автоматизируемого бизнес-процесса;

Документ должен позволять встраивание его в Систему в виде HTML-справки.6) Руководство администратора должно включать описание процедур управления

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

7) В Руководстве системного администратора должны быть описаны основные работы сотрудников службы эксплуатации Заказчика, которые должны быть выполнены в процессе подготовки серверных ресурсов к установке Системы, работы по настройке Системы, обслуживанию, обновлению системного ПО и резервному копированию, при этом структура документа и степень детализации описания отдельных работ должны быть согласованы Исполнителем с Заказчиком на этапе разработки Архитектурного документа.

8) Руководство программиста должно содержать техническое описание реализации компонентов Системы, при этом структура документа и степень детализации описания отдельных модулей Системы должны быть согласованы Исполнителем с Заказчиком на этапе разработки Архитектурного документа.

9) Документ Программа и методика испытаний должен удовлетворять следующим требованиям:

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

В программе испытаний должна быть предусмотрена проверка каждого функционально законченного элемента Системы;

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

В методике испытаний должны описываться действия, которые должны выполняться при испытаниях Системы с указанием названий функций Системы, выполняемых шагов и отсылок к номерам пунктов Технических требований или Технического задания;

В документе должна содержаться форма протоколирования результатов испытаний, а также ожидаемые результаты по каждому пункту программы испытаний.

10) Набор документов для передачи Системы в эксплуатацию должен включать в себя: Протокол комплексных испытаний Системы; Перечень выполненных по результатам испытаний доработок; Акт готовности к переводу Системы в опытно-промышленную эксплуатацию.

55

7 Приложения

7.1 Шаблон правки

Изменения, связанные с <краткое наименование предложения>Приложение

Инициатор: <наименование>.Обоснование: <краткое обоснование необходимости предлагаемого изменения>.Дата вступления в силу: <указывается предлагаемая дата вступления в силу предложения>.

Пример части правки, касающейся предлагаемых изменений в табличную форму

Действующая редакция

Приложение 26

РЕЕСТР БАНКОВСКИХ ГАРАНТИЙ, ПОЛУЧЕННЫХ АО «ЦФР» В СООТВЕТСТВИИ С СОГЛАШЕНИЯМИ О ПОРЯДКЕ РАСЧЕТОВ, СВЯЗАННЫХ С УПЛАТОЙ

ПРОДАВЦОМ ШТРАФОВ ПО ДПМ ВИЭ

№ п/п

Номер соглашени

я

Дата заключе

ния соглаше

ния

Принципал

Код

принципа

ла

Код ГТП

генерации

Номер банковс

кой гаранти

и

Дата предоставления банковс

кой гаранти

и

...

1 2 3 4 5 6 7 8 9

Предлагаемая редакция

Приложение 26

РЕЕСТР БАНКОВСКИХ ГАРАНТИЙ, ПОЛУЧЕННЫХ АО «ЦФР» В СООТВЕТСТВИИ С СОГЛАШЕНИЯМИ О ПОРЯДКЕ РАСЧЕТОВ, СВЯЗАННЫХ С УПЛАТОЙ

ПРОДАВЦОМ ШТРАФОВ ПО ДПМ ВИЭ

№ п/п

Номер соглашени

я

Дата заключени

я соглашени

Продавец

Код прода

вца

Код ГТП

генерации

Номер банковско

й гарантии

Дата банков

ской гарант

...

56

я ии1 2 3 4 5 6 7 8 9

57

7.2 Шаблон пояснительной записки к правке

«Наименование организации»

ПОЯСНИТЕЛЬНАЯ ЗАПИСКАОб изменениях, связанных с …

1. Инициатор: …

2. Цель предлагаемых изменений: …

3. Описание действующего порядка и его недостатки: …4. Предлагаемое решение:

…5. Предлагаемая дата вступления в силу:

…6. Указание норм права, в соответствии с которыми разработаны изменения:

…7. Оценка экономического влияния предложенных изменений:

…

58

7.3 Шаблон таблицы изменений

7.3.1 Шаблон ТИ для ДОП

Заседание Наблюдательного совета Ассоциации «НП Совет рынка»от ___ по вопросу №__«[Название вопроса]»

<Наименование вопроса>

Инициатор: <наименование>.Обоснование: <краткое обоснование необходимости предлагаемого изменения>.Дата вступления в силу: <указывается предлагаемая дата вступления в силу предложения>.

Предложения по изменениям и дополнениям в СТАНДАРТНУЮ ФОРМУ ДОГОВОРА О ПРИСОЕДИНЕНИИ К ТОРГОВОЙ СИСТЕМЕ ОПТОВОГО РЫНКА

№ пункта

Редакция, действующая на момент вступления в силу изменений

Предлагаемая редакция(изменения выделены цветом)

59

7.3.2 Шаблон ТИ для Регламентов ОРЭМ

Заседание Наблюдательного совета Ассоциации «НП Совет рынка» от ___ по вопросу №__«[Название вопроса]»

Наименование вопроса

Инициатор: <наименование>.Обоснование: <краткое обоснование необходимости предлагаемого изменения>.

Дата вступления в силу: <указывается предлагаемая дата вступления в силу предложения>.

Предложения по изменениям и дополнениям в РЕГЛАМЕНТ <Название регламента> (Приложение № <Номер регламента> к Договору о присоединении к торговой системе оптового рынка)

№ пункта Редакция, действующая на момент вступления в силу изменений

Предлагаемая редакция(изменения выделены цветом)

60

7.3.3 Шаблон ТИ для Стандартных форм договоров

Заседание Наблюдательного совета Ассоциации «НП Совет рынка»от ___ по вопросу №__«[Название вопроса]»

Наименование вопроса

Инициатор: <наименование>.Обоснование: <краткое обоснование необходимости предлагаемого изменения>.Дата вступления в силу: <указывается предлагаемая дата вступления в силу предложения>.

Предложения по изменениям и дополнениям в СТАНДАРТНУЮ ФОРМУ ДОГОВОРА <Название договора> (Приложение № <номер договора> к Договору о присоединении к торговой системе оптового рынка)

№ пункта Редакция, действующая на момент вступления в силу изменений

Предлагаемая редакция(изменения выделены цветом)

61

7.4 Пример справочника наименований ДОП

Вид Номер Наименование Наименование документа для выпадающего списка в ИФ

Наименование таблицы изменений

Формат файла

ДОП - Не заполняется ДОП Предложения по изменениям и дополнениям в СТАНДАРТНУЮ ФОРМУ ДОГОВОРА О ПРИСОЕДИНЕНИИ К ТОРГОВОЙ СИСТЕМЕ ОПТОВОГО РЫНКА

GA_[dvs]_[dns] _[version]

Регламент 19.3 Не заполняется Р 19.3 Предложения по изменениям и дополнениям в РЕГЛАМЕНТ ПРОВЕДЕНИЯ КОНКУРЕНТНЫХ ОТБОРОВ МОЩНОСТИ (Приложение № 19.3 к Договору о присоединении к торговой системе оптового рынка)

R19_3_[dvs]_[dns]_[version]

Договор 14 Не заполняется Д 14 Предложения по изменениям и дополнениям в СТАНДАРТНУЮ ФОРМУ ДОГОВОРА КУПЛИ-ПРОДАЖИ (ПОСТАВКИ) МОЩНОСТИ НОВЫХ ГИДРОЭЛЕКТРОСТАНЦИЙ (В ТОМ ЧИСЛЕ ГИДРОАККУМУЛИРУЮЩИХ ЭЛЕКТРОСТАНЦИЙ) (Приложение № Д 14 к Договору о присоединении к торговой системе оптового рынка)

AD_14_[dvs]_[dns]_[version]

Таблица изменений

Р 19.3 Не заполняется Не заполняется

Не заполняется CH_R19_3_[dvs]_[dns]_[version]

62

Формат файла:

[Type]_ [dvs] _ [dns] _ [version], где:• [Type] – тип документа: (GA – для ДОП/ R_n – для Регламента (R) с номером (n), AD_n –

для договора (AD) с номером (n, (CH)_R_n – для таблицы изменений CH c номером соответствующего регламента (R_n))

• [dvs] – дата вступления в силу (не заполняется для типа документов (SR))• [dns] – дата НС (не заполняется для типа документов (SR))• [version] – идентификатор версии файла в хранилище

63

7.5 Визуальные формы (примеры) отчетов

7.5.1 Пример карточки переменной

64

7.5.2 Пример справочника переменных ДОП

65

7.5.3 Пример отчет об ошибках по переменным

66

7.5.4 Пример отчет об ошибках в тексте документа ДОП

67

7.5.5 Пример поиска по документам ДОП

68

7.5.6 Пример накопителя ТИ

69

7.5.7 Пример разметки документа ДОП гиперссылками

70

7.6 Атрибуты переменной ДОП

Атрибуты Переменной ДОП:

Идентификатор; Наименование – текстовое или символьное (формульное) наименование переменной в

формате TeХ, в том числе с указанием верхних и/или нижних индексов переменной; Краткое описание – пояснение к наименованию переменной; Определение – подробное описание переменной из пункта регламента, содержащего

её определение; Комментарий; Дата начала действия - Дата вступления в силу редакции документа ДОП, где

определяется/изменяется переменная. Может быть меньше текущей даты. Дата окончания действия - Дата вступления в силу редакции документа ДОП, где

переменная удаляется. По умолчанию ставится дата «01.01.3000». Тэги – свободная характеристика переменной в виде ключевых слов; № документа – номер документа ДОП, в котором определяется переменная. (должен

быть использован выпадающий список действующих документов ДОП); Пункт документа – номер пункта документа ДОП, в котором определяется

переменная; Бизнес-подразделение (ответственное) – подразделение внутри группы компаний (НП

СР, АТС, ЦФР), ответственное за ведение переменной ДОП (должен быть использован выпадающий список действующих подразделений) (см. в прил. Ответственное подразделение);

Организация – владелец – инфраструктурная организация ОРЭМ, ответственная за ведение переменной ДОП;

Размерность – единица измерения; Запрос Jira – инициатор – номер запроса в системе управления задачами и проектами

группы компаний, в которой было инициировано создание переменной; Автор – ФИО пользователя или логин пользователя, который внес изменения в

Справочник переменных ДОП; Сектор рынка – сектор торговли товара на ОРЭМ, к которому относится переменная

ДОП; Место определения (Закладка) – адрес закладки на текст, определяющий переменную

ДОП; География – параметр отнесения переменной ДОП к определенной территории; Время – параметр отнесения переменной ДОП к определенному интервалу времени; Объект – параметр отнесения переменной ДОП к определенному объекту ОРЭМ; Показатель – параметр отнесения переменной ДОП к определенной качественной или

количественной характеристике.

Характеристика атрибутов переменных ДОП:

  Множ Изм Обяз МЗ ТД РЗ

Идентификатор Ед Пост О Авто Текст -

Наименование Ед Перем О Ручной ввод

Текст Куратор

Краткое описание Ед Перем О Ручной ввод

Текст Куратор

Определение Ед Перем О Ручной Текст Куратор

71

ввод

Комментарий Ед Перем НО Ручной ввод

Текст БП

Дата начала действия Ед Перем О Ручной ввод

Дата Куратор

Дата окончания действия

Ед Перем О Nvl (Ручной ввод, Авто)

Дата Куратор

Тэги Мн Перем НО Ручной ввод

Текст БП

№ документа Ед Пост НО Авто Текст Куратор

Пункт документа Ед Перем НО Авто Текст Куратор

Ответственное подразделение

Ед Перем НО Авто Текст Куратор

Ответственная организация

Ед Пост НО Ручн - Вып.список

Текст Куратор

Размерность (единица измерения)

Ед Пост НО Ручн - Вып.список

Текст БП

Запрос Jira – инициатор

Ед Пост НО Ручн Текст БП

Автор Ед Пост О Авто Текст -

Сектор рынка Ед Пост НО Ручн - Вып.список

Текст БП

Место определения (Закладка)

Ед Пост О Авто Текст -

География Мн Перем НО Ручн - Вып.список

Текст БП

Время Ед Пост НО Ручн - Вып.список

Текст БП

Объект Мн Перем НО Ручн - Вып.список

Текст БП

Показатель Ед Пост НО Ручн - Вып.список

Текст БП

72

7.7 Пример статических справочников в Справочник переменных ДОП

7.7.1 Пример Справочник регламентов

Справочник, содержащий актуальное множество документов ДОП на ОРЭМ (доступен по адресу http://www.np-sr.ru/regulation/joining/index.htm).

№ Регламента

Значения Описание Название для наименования

Р1 Приложение 1. Регламент допуска к торговой системе оптового рынка

R1

Р1.1 Приложение 1.1. Положение о порядке получения статуса субъекта оптового рынка и ведения реестра субъектов оптового рынка

R1_1

Р11.1 Приложение 11.1. Автоматизированные информационно-измерительные системы коммерческого учета электрической энергии (мощности). Технические требования

R1_1_pril_11_1

Р11.1.1 Приложение 11.1.1. Формат и регламент предоставления результатов измерений, состояний средств и объектов измерений в АО "АТС", АО "СО ЕЭС" и смежным субъектам

R1_1_pril_11_1_1

Р11.3 Приложение 11.3. Порядок установления соответствия АИИС КУЭ техническим требованиям оптового рынка и присвоения класса АИИС КУЭ

R1_1_pril_11_3

Р2 Приложение 2. Регламент внесения изменений в расчетную модель электроэнергетической системы

R2

Р3 Приложение 3. Регламент актуализации расчетной модели R3

…    

Р6.2Пр1 Приложение 1.2017 (Европа) к регламенту 6.2 R6_2_pril_1

ДОП Договор о присоединении к торговой системе оптового рынка

GA

ПрД1.32 Приложение Д 1.32. Стандартная форма Регулируемого договора купли-продажи электрической энергии и мощности для энергосбытовых компаний, гарантирующих поставщиков (энергоснабжающих организаций) для поставки населению на 2017 год

AD_1_32

…    

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

AD_22

73

 …    

7.7.2 Пример Справочника Ответственное подразделение

Справочник, содержащий актуальный перечень ответственных за переменные ДОП бизнес-подразделений группы компаний.

 Бизнес-подразделение (ответственное) – организация

Значения Описание

СР-ПУ Ассоциация "НП Совет рынка" - Правовое управление

СР-УКЦ Ассоциация "НП Совет рынка" - Управление развития конкурентного ценообразования

СР-УРЦ Ассоциация "НП Совет рынка" - Управление сопровождения рынков с регулируемым ценообразованием

СР-УАЭС Ассоциация "НП Совет рынка" - Управление аудита и технологической экспертизы

СР-УК Ассоциация "НП Совет рынка" - Управление мониторинга и контроля

АТС-ДКУ АО "АТС" - Департамент коммерческого учета

АТС-ДТЭ АО "АТС" - Департамент технической экспертизы

АТС-ДФР АО "АТС" - Департамент финансовых расчетов

АТС-ЮД АО "АТС" - Юридический департамент

АТС-ДД АО "АТС" - Департамент допуска

АТС-ДТ АО "АТС" - Департамент торговли

ЦФР АО "ЦФР"

7.7.3 Пример Справочник Ответственная организация

Справочник, содержащий актуальный перечень инфраструктурных организаций, отвечающих за расчет переменных ДОП.

Ответственная организация

Значения Описание

СР Ассоциация «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью»

74

КО Акционерное общество «Администратор торговой системы оптового рынка электроэнергии»

СО Акционерное общество «Системный оператор Единой энергетической системы»

ФСК Публичное акционерное общество «Федеральная сетевая компания Единой энергетической системы»

ЦФР Акционерное общество «Центр финансовых расчетов»

Субъект Субъект оптового рынка или Участник оптового рынка 

7.7.4 Пример Справочник Размерность (единица измерения)

Справочник множества единиц измерений переменных, используемых для определения переменных в документах ДОП.

Размерность (единица измерения)

Мвт*ч

кВт*ч

МВт

руб

тыс.руб

руб/МВт*ч

руб/кВт*ч

руб/МВт

руб/кВт

кВ

кВт

радиан

МВт/мин

процент

… 

7.7.5 Пример Справочник Сектор рынка

Справочник актуальных секторов торговли электроэнергией и мощностью

Сектор рынка

75

РСВ

БР

СДД

РМ

РД

… 

7.7.6 Пример Справочник География

Справочник разделения переменных ДОП по территориальному признаку

География

Субъект РФ

Ценовая зона

Неценовая зона

ЗСП

… 

7.7.7 Пример Справочник Время

Справочник разделения переменных ДОП по временному признаку

Время

Минута

Час

Сутки

Год

Период

… 

7.7.8 Пример Справочник Объект

Справочник разделения переменных ДОП по принадлежности к объекту ОРЭМ

Объект

ГА / ЕГО

РГЕ

ГТП

76

ГТПГ

ГТПП

ГТПЭ

ГТПИ

Станция

Узел

Ветвь

Сечение

Участник

… 

7.7.9 Пример Справочник Показатель

Справочник разделения переменных ДОП по количественным / качественным характеристикамПоказатель

Объем

Цена

Стоимость

Коэффициент

Множитель

Мощность

Напряжение

Переток

Предел

Предел регулирования

Разница

Тариф

…

77

Приложение № 2к Договору № _______ от «__» ________ 20__ года

План-график выполнения работ по Договору

Этап Описание этапов Описание основных работ Результат выполнения работ

Срок выполне

ния работ

1 этап Разработка и согласование плана-графика и концепции Системы, с указанием перечня предполагаемых технологий, а также демонстрация макетов экранных форм с возможностью определения поведения пользователя (Mockup)

утверждение детального плана-графика работ по следующему этапу проекта;

разработка и утверждение концепции Системы, с указанием перечня предполагаемых технологий, архитектурных решений;

разработка и утверждение макетов экранных форм с возможностью определения поведения пользователя (Mockup)

детальный план-график работ по 2-му этапу проекта;

концепция Системы;

макеты экранных форм.

Не более 2 (двух) календарных месяцев с даты подписания Договора

2 этап Проектирование и разработка функциональности по работе с текстом (раздел 4.1.4 пп. 8 Технических требований (далее -ТТ)

разработка и утверждение ЧТЗ и Архитектурного документа по функциональности соответствующего этапа, включая сценарии тестирования/эскизы (дизайны) всех необходимых форм;

согласование скорректированной концепции в части архитектурных решений;

разработка и согласование ПО по функциональности соответствующего этапа;

демонстрация Заказчику результатов разработки по этапу (дополнительно к регулярным демонстрациям частичных разработок);

тестирование Заказчиком ПО и направление замечаний Исполнителю;

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

утверждение ПО по

согласованное с Заказчиком ЧТЗ и Архитектурный документ по функциональности 2 этапа;

разработанное ПО по функциональности 2 этапа, прошедшее предварительное тестирование, доработку и утверждение;

детальный план-график работ по 3-му этапу проекта.

Не более 7 (семи) календарных месяцев с даты подписания Договора

78

функциональности соответствующего этапа;

внесение изменений в документацию в соответствии с реализованной функциональностью;

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

утверждение детального плана-графика работ по следующему этапу проекта.

3 этап Проектирование и разработка функциональности в соответствии с ТТ (раздел 4.1.1 - 4.1.4, включая пп 8 ТТ)

Подэтапы аналогичны предыдущим (см. 2 этап)

согласованное с Заказчиком ЧТЗ и Архитектурный документ по функциональности 3 этапа;

разработанное ПО по функциональности 3 этапа, прошедшее предварительное тестирование, доработку и утверждение;

детальный план-график работ по 4-му этапу проекта.

Не более 11 (одиннадцати) календарных месяцев с даты подписания Договора

4 этап Проектирование и разработка остальных функциональных модулей ТТ на стороне Исполнителя, с учетом ранее разработанных

Подэтапы аналогичны предыдущим (см. 2 этап)

согласованное с Заказчиком ЧТЗ и Архитектурный документ по функциональности 4 этапа;

разработанное ПО по функциональности 4 этапа, прошедшее предварительное тестирование, доработку и утверждение;

детальный план-график работ по 5-му этапу проекта.

Не более 14 (четырнадцати) календарных месяцев с даты подписания Договора

5 этап Развертывание ПО и доработка и согласование Утвержденное ТЗ и Не более 79

опытно-промышленная эксплуатация на стороне Заказчика

Технического задания и Архитектурного документа с учетом всех доработок на предыдущих этапах;

разработка и согласование эксплуатационной документации;

разработка и согласование программы и методики испытаний (ПМИ);

сдача-приемка Системы на аппаратных ресурсах Исполнителя;

инструктаж специалистов Заказчика (1 администратора 8 часов, 1 программиста 8 часов, пользователей 8 часов);

развертывание ПО на аппаратных ресурсах Заказчика;

опытно-промышленная эксплуатация на аппаратных ресурсах Заказчика;

устранение замечаний, не выявленных на этапе сдачи-приемки на аппаратных ресурсах Исполнителя.

Архитектурный документ в целом по проекту с учетом ранее выявленных доработок;

эксплуатационная документация;

ПМИ;Прохождение

приемочного тестирования на аппаратных ресурсах исполнителя;

обучение (инструктаж) ключевых специалистов Заказчика;

передача разработанного и согласованного ПО и всей сопроводительной документации Заказчику;

начало опытно – промышленной эксплуатации ПО на аппаратных ресурсах Заказчика;

устранение замечаний, выявленных на аппаратных ресурсах Заказчика и не выявленных ранее на аппаратных ресурсах Исполнителя.

18 (восемнадцати) календарных месяцев с даты подписания Договора

ЗАКАЗЧИК:

Ассоциация «НП Совет рынка»

_____________________ _____________м.п.

ИСПОЛНИТЕЛЬ:

______________________ _____________м.п.

80

Приложение № 3к Договору № ______ от «___» _____ 20__ года

ФормаАКТ СДАЧИ-ПРИЕМКИ ВЫПОЛНЕННЫХ РАБОТ

г. Москва «___» _________ 20___ года

Ассоциация «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью», именуемая в дальнейшем «Заказчик», в лице____________________________________________, действующего на основании доверенности № _________ от __ ___________ 20___ года, с одной стороны, и

____________________________, в лице _______________________, действующего на основании ______________________, именуем__ в дальнейшем «Исполнитель», с другой стороны, в дальнейшем совместно именуемые «Стороны», а по отдельности – «Сторона», составили настоящий Акт сдачи-приемки выполненных работ по Договору №______________ от ________________ 20__ года (далее – Договор) о нижеследующем:

1. Работы по разработке программного обеспечения «Система сопровождения Договора о присоединении» выполнены Исполнителем полностью и в срок. Заказчик претензий по объему, качеству и срокам выполнения работ не имеет.

2. Стоимость выполненных Исполнителем работ по Договору составила _________ (______________________) рублей, в том числе НДС (20%) - ___________рублей.

3. Акт составлен в 2 (двух) экземплярах, имеющих одинаковую юридическую силу, по одному для каждой из Сторон.

Приложения 1. __ л. в __ экз.2. …

ИСПОЛНИТЕЛЬ: ЗАКАЗЧИК:

____________________/____________ МП

___________________/____________ МП

Форма Акта согласована Сторонами:

ИСПОЛНИТЕЛЬ: ЗАКАЗЧИК:

____________________/____________ МП

___________________/____________ МП

81

Приложение № 4к Договору № ______ от «___» _____ 20__ года

ФормаАКТ ОБ ОКАЗАНИИ УСЛУГ

г. Москва «___» _________ 20___ года

Ассоциация «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью», именуемая в дальнейшем «Заказчик», в лице____________________________________________, действующего на основании доверенности № _________ от __ ___________ 20__ года, с одной стороны, и

____________________________, в лице _______________________, действующего на основании ______________________, именуем__ в дальнейшем «Исполнитель», с другой стороны, в дальнейшем совместно именуемые «Стороны», а по отдельности – «Сторона», составили настоящий Акт об оказании услуг (далее – Акт) по Договору №______________ от ________________ 20__ года (далее – Договор) о нижеследующем:

1. Исполнитель оказал Заказчику услуги по сопровождению программного обеспечения «Система сопровождения Договора о присоединении» (далее – услуги) за следующий отчетный период: ___________________.

2. Услуги оказаны в полном объеме, надлежащего качества и в установленные сроки.

3. Настоящим Актом Стороны подтверждают, что стоимость подлежащих оплате услуг составляет _____________________________, в том числе НДС (20%) в размере ___________________________.

4. Настоящий Акт составлен в 2 (Двух) подлинных экземплярах, имеющих равную юридическую силу, по одному для каждой из Сторон.

Приложения 1. __ л. в __ экз.2. …

ИСПОЛНИТЕЛЬ: ЗАКАЗЧИК:

____________________/____________ МП

___________________/____________ МП

Форма Акта согласована Сторонами:

ИСПОЛНИТЕЛЬ: ЗАКАЗЧИК:

____________________/____________ ___________________/____________ 82

МП МП Приложение № 5к Договору № ______ от «___» _____ 20__ года

ФОРМА

СОГЛАСИЕ НА ОБРАБОТКУ ПЕРСОНАЛЬНЫХ ДАННЫХ

Я, ___________________, паспорт серия ___ номер ________ выдан 2__________________________________, зарегистрированный по адресу: ________________________________, в соответствии с Федеральным законом от 27 июля 2006 года № 152-ФЗ «О персональных данных» свободно, своей волей и в своем интересе даю согласие Ассоциации «Некоммерческое партнерство Совет рынка по организации эффективной системы оптовой и розничной торговли электрической энергией и мощностью» (ОГРН 1027739482616, ИНН 7705429930, место нахождения: Российская Федерация, 123610, г. Москва, Краснопресненская набережная, д. 12, подъезд 7, этажи 7 и 8) на любое действие (операцию) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с моими персональными данными, включая сбор, запись, систематизацию, накопление, хранение (в том числе хранение копий документов, содержащих персональные данные), уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ) третьим лицам, обработку персональных данных указанными третьими лицами, получение от третьих лиц, обезличивание, блокирование, удаление, уничтожение (далее – обработку) моих персональных данных, предоставленных мною с целью получения допуска в помещения и к промышленным информационным системам (базам данных) Ассоциации «НП Совет рынка» в рамках исполнения договора № ___ от «__» ______ 20___ года.

В перечень моих персональных данных на обработку которых я даю согласие Ассоциации «НП Совет рынка», входят:

фамилия, имя, отчество; фамилия и имя в соответствии с документом, удостоверяющим личность гражданина

Российской Федерации, по которому граждане Российской Федерации осуществляют выезд из Российской Федерации и въезд в Российскую Федерацию;

дата рождения (число, месяц, год); место рождения; пол; гражданство; данные паспорта гражданина Российской Федерации (серия, номер, дата и место

выдачи, сведения о выдавшем его органе, код подразделения); адрес места жительства; адрес для направления почтовой корреспонденции и информирования; мобильный, рабочий номера телефонов (добавочный номер); адрес электронной почты; …3

Я оставляю за собой право отозвать настоящее согласие посредством составления соответствующего письменного заявления. При получении моего заявления об отзыве настоящего согласия на обработку персональных данных Ассоциация «НП Совет рынка» обязана прекратить обработку персональных данных в целях, указанных в настоящем согласии, в сроки, предусмотренные законодательством Российской Федерации. При этом бумажные носители

3 Перечень персональных данных может быть скорректирован.83

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

Я подтверждаю, что предоставленные мною персональные данные являются актуальными и достоверными.

Настоящее согласие действует со дня его подписания до дня отзыва в письменной форме.

«__» ________ 20__года___________/______

Форма согласована Сторонами:

ИСПОЛНИТЕЛЬ: ЗАКАЗЧИК:

____________________/____________ МП

___________________/____________ МП

84