Регламент согласования и выпуска версий государственной интегрированной информационной системы управления общественными финансами «Электронный бюджет»

Федеральное казначействоДействующий акт

Актуально на 09.11.2026.

Как цитировать: "Регламент согласования и выпуска версий государственной интегрированной информационной системы управления общественными финансами "Электронный бюджет". https://bukva.ai/docs/reglament-soglasovaniya-i-vypuska-versiy

(утв. Казначейством России 21.08.2015)

Утверждаю Заместитель руководителя Федерального казначейства

С. Б. Гуральников
21 августа 2015 года

Согласовано
Начальник Управления
финансовых технологий
В.В. ТКАЧЕНКО
21 августа 2015 года

Начальник Управления
информационных систем
С.Г. ПАВЛОВ
21 августа 2015 года

РЕГЛАМЕНТ
СОГЛАСОВАНИЯ И ВЫПУСКА ВЕРСИЙ ГОСУДАРСТВЕННОЙ
ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ
ОБЩЕСТВЕННЫМИ ФИНАНСАМИ «ЭЛЕКТРОННЫЙ БЮДЖЕТ»

Список определений и сокращений

Термин	Описание
Версия	Совокупность программных модулей и пакетов документации, связанная с доработкой подсистемы ЭБ, предназначенная для передачи Заказчику для осуществления приемки в соответствии с условиями Контракта.
Выпускающий редактор, ВР	Организация, обеспечивающая согласование и выпуск интеграционных версий ЭБ на основании и в объеме заключенного Контракта.
График выпуска версий, ГВВ	Документ с номерами интеграционных версий, датами начала ПДИ, ОЭ, ПЭ каждой из интеграционных версий.
Дефект	Под дефектом понимается невыполнение функций подсистемы, указанных в утвержденной Заказчиком документации к версии. Не является дефектом невыполнение функций подсистемы, указанных в документации к версии, если оно вызвано неправильной настройкой и/или некорректной технологией работы.
Доработка	Доработка подсистемы, ЭБ, определяемая набором требований и обозначенная идентификационным номером.
Заказчик	Федеральное казначейство.
Заявка	Формализованный способ взаимодействия между Заказчиком, Разработчиками подсистем и Выпускающим редактором. Заявкой является любой запрос на получение, восстановление функционирования или изменение ИТ-сервиса.
Заявка на анализ требования, ЗНА	Разновидность заявки, инициированная необходимостью анализа требования для вынесения доработки подсистемы или вынесения решения об отсутствии необходимости доработки.
Заявка на выпуск версии	Заявка на изменение, связанная с необходимостью передачи версии (патча) Разработчиком подсистемы Заказчику для осуществления приемки в соответствии с условиями Контракта.
Заявка на доработку, Доработка	Заявка на изменение, связанная с необходимостью доработки.
Заявка на оценку влияния, ЗОВ	Разновидность заявки на доработку, инициированная необходимостью оценки влияния доработки подсистемы на другие подсистемы.
Заявка на согласование плана доработки, ЗСП	Разновидность заявки, инициированная необходимостью согласования плана доработки подсистемы для формирования плана выпуска версий, содержащая предложения по версии реализации.
Заявка на согласование состава доработки, ЗСС	Разновидность заявки, инициированная необходимостью согласования состава доработки подсистемы, содержащая краткое описание решения и подробное описание состава доработки.
Заявка на планирование версии	Заявка на обслуживание, связанная с необходимостью планирования сроков выпуска версии для включения в ГВВ.
Интеграционная версия	Логическое обозначение выпуска версий подсистем в единые сроки с учетом функциональной и технологической зависимости доработок подсистем, идентифицированное номером интеграционной версии и включающей номера версий всех подсистем, входящих в данную интеграционную версию.
Интеграционное тестирование	Процесс выполнения взаимосвязанных операций в версиях подсистем, входящих в интеграционную версию, в целях проверки соответствия характеристик взаимодействия подсистем совокупности требований к ЭБ, выявления и устранения дефектов.
ИС	Информационная система.
Контракт	Государственный контракт, заключенный между Федеральным казначейством и Разработчиком подсистемы или Выпускающим редактором
Нормативная документация, НД	Нормативные правовые акты, приказы, разъяснительные письма и прочие документы Заказчика и органов исполнительной власти РФ, которые могут служить источником требований на изменение ЭБ.
Обращение	Заявка на обслуживание, связанная с необходимостью исправления сбоя или дефекта, выявленного при регрессионном тестировании ВР, в период ПДИ, ОЭ, интеграционного тестирования или в процессе ПЭ в рамках гарантийных обязательств РП.
ОЭ	Опытная эксплуатация. Процесс выполнения операций в прошедшей ПДИ версии, проверки соответствия количественных и качественных характеристик версии совокупности требований к подсистеме ЭБ, выявления и устранения дефектов, который проводится для определения работоспособности версии и принятия решения о приемке версии в ПЭ.
ПАК	Программно-аппаратный комплекс.
Патч	Версия, содержащая исправления сбоев, дефектов или срочные доработки.
ПВВ	План выпуска версии, представляющий собой документ с идентификационными номерами доработок прикладного программного обеспечения, их описанием и прочими реквизитами, в разрезе версий, спланированных по основным этапам процесса реализации доработок.
Пилотная группа	Группа пользователей ЭБ, участвующих в ПДИ или ОЭ.
ПиМ	Программа и методика приемочных испытаний.
Подсистема	Функциональная или технологическая подсистема/компонент системы «Электронный бюджет».
ПОИ	Подсистема обеспечения интеграции ЭБ.
ПОИБ	Подсистема обеспечения информационной безопасности ЭБ.
ПОЮЗД	Подсистема обеспечения юридической значимости документов ЭБ.
ПДИ	Предварительное приемочное испытание. Процесс проверки выполнения функций версии, проверки соответствия количественных и качественных характеристик версии совокупности требований к подсистеме ЭБ, выявления и устранения сбоев и/или дефектов, который проводится методами функционального и регрессионного тестирования для определения работоспособности версии и для принятия решения о приемке версии в ОЭ.
ПСиТО	Порядок сопровождения и технического обслуживания
ПЭ	Постоянная эксплуатация (эксплуатация). Процесс постоянного использования версии и поддержания ее в работоспособном состоянии путем устранения сбоев и/или дефектов и актуализации эксплуатационной документации.
Разработчик, Разработчик подсистемы, РП	Организация, выполняющая работы по выполнению доработок подсистемы ЭБ на основании и в объеме заключенного Контракта.
РТП	Разработчик технологической подсистемы
РФП	Разработчик функциональной подсистемы.
Ролевая матрица	Документ, определяющий роли и полномочия сотрудников ФК, Выпускающего редактора или Разработчика подсистемы.
Сбой	Факт прекращения выполнения подсистемы ЭБ части своих функций, не позволяющий пользователям ЭБ выполнять свои прямые задачи в сроки, установленные законодательством и не имеющий альтернативных (ручных или прочих) способов выполнения функций пользователями ЭБ в рамках возможностей подсистем ЭБ. Также сбоем может быть признан Дефект, при которой имеющиеся альтернативные способы выполнения функций ППО приводят к многократному превышению трудозатрат по сравнению со штатными условиями функционирования подсистем ЭБ и не позволяют пользователям ЭБ выполнить свои прямые задачи в сроки, установленные законодательством.
Система «Электронный бюджет», ЭБ	Государственная интегрированная информационная система управления общественными финансами «Электронный бюджет»
Система управления выпуском версий, СУВВ	Прикладное программное обеспечение, предназначенное для учета и обработки заявок на планирование версии или патча, заявок на доработку.
СУЭ	Система управления эксплуатацией Заказчика. В рамках процессов, описанных в Регламенте, применяется для учета и обработки заявок на выпуск версии, обращений.
Структурное подразделение, СП	Структурное подразделение центрального аппарата ФК
Технологическая подсистема	Одна из подсистем ЭБ: ПОИ, ПОИБ, ПОЮЗД.
ТФФ	Требования, предъявляемые к форматам файлов при информационном взаимодействии со сторонним прикладным программным обеспечением.
УИС	Управление информационных систем Федерального казначейства.
УФТ	Управление финансовых технологий Федерального казначейства.
ФАП	Фонд алгоритмов и программ Федерального казначейства.
Функциональная подсистема, ФП	Подсистема, обеспечивающая функциональность ЭБ по выделенному направлению прикладных задач.
ФК	Федеральное казначейство.
ЦАФК	Центральный аппарат Федерального казначейства.
ЧТЗ	Частное техническое задание
Эксплуатационная документация	Документация, определенная в перечне эксплуатационных документов к версии, указанном в Контракте.

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

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

согласование проекта графика выпуска версий;
согласование изменений в график выпуска версий;
согласование и планирование выпуска доработок.

Заказчик формирует проект графика выпуска версий с учетом потребностей структурных подразделений и планов нормотворчества. УФТ вносит проект ГВВ в систему управления выпуском версий с указанием сроков ПДИ, ОЭ, ПЭ и направляет Выпускающему редактору. Выпускающий редактор проставляет в проекте ГВВ остальные сроки, необходимые для планирования мероприятий по испытаниям и приемке версий в постоянную эксплуатацию, и направляет проект ГВВ на согласование Разработчикам подсистем.

Разработчики подсистем, при необходимости, дают мотивированные рекомендации Заказчику по переносу сроков интеграционных версий, указанных в проекте ГВВ. В случае принятия рекомендаций Заказчиком проект ГВВ повторно направляется Разработчикам подсистем.

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

После получения от всех Разработчиков подсистем информации о включении или отказе от включения в проект ГВВ версий подсистем проект ГВВ утверждается Заказчиком. Форма ГВВ приведена в п. 15.7.

Согласование изменений в график выпуска интеграционных версий происходит в случае:

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

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

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

При поступлении новых требований в связи со следующими событиями:

изменение НД;
необходимость реализации в ЭБ дополнительных сервисов;
изменение требований к объектам ТФФ внешних ИС, взаимодействующих с ЭБ;
оценка влияния доработок других подсистем,

запускается процесс согласования доработок функциональных и/или технологических подсистем. По результатам внутреннего согласования между структурными подразделениями ФК о необходимости анализа требований, СП-технолог подсистемы-инициатора направляет Разработчику заявку на анализ требований. Форма заявки приведена в п. 15.6.

При выявлении Разработчиком в результате анализа требований необходимости изменений системы/подсистемы — в СУВВ регистрируется доработка. На первом этапе процесса согласования состав доработки уточняется и детализируется.

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

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

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

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

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

После прохождения ПДИ и устранения Разработчиком сбоев и/или дефектов, препятствующих передаче в ОЭ, Выпускающий редактор устанавливает версию подсистемы на промышленном ПАК для прохождения ОЭ.

После прохождения ОЭ и устранения Разработчиком сбоев и/или дефектов, препятствующих передаче в ПЭ, версия подсистемы принимается в ПЭ.

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

1.1. Этапы выполнения работ

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

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

1.2. Нормативные сроки выполнения этапов работ

Этап	Ответственные и сроки основных задач этапа, рабочие дни.
Согласование проекта графика выпуска версий	Предоставление Заказчику рекомендаций по изменению сроков направленного Заказчиком проекта ГВВ — Разработчик подсистемы, 2 дня после получения проекта ГВВ. Ответ Заказчика Разработчику подсистемы на рекомендации по изменению сроков ГВВ — Заказчик, 2 дня после получения рекомендаций. Предоставление Заказчику информации о включении версий подсистемы в проект ГВВ — Разработчик подсистемы, 5 дней после получения проекта ГВВ. Формирование заявок на планирование версий подсистемы на срок действия Контракта — Разработчик подсистемы, 10 дней после заключения Контракта. Согласование заявки на планирование версий подсистемы Заказчиком, Разработчиком, ВР — Заказчик, Разработчик, ВР, 1 день после получения заявки на планирование версий подсистемы. Принятие решения о планировании новой интеграционной версии по заявке Разработчика и запуск согласования изменений в ГВВ — Заказчик, 1 день после получения заявки на планирование версий подсистемы.
Согласование требований	Анализ требований в заявке на анализ требований и регистрация доработки, предварительная оценка — Разработчик подсистемы, 4 дня после получения заявки. Уточнение состава доработки в процессе согласования с Заказчиком — СП технологи подсистемы, 5 дней после получения заявок на согласование состава доработок. Направление заявок на оценку влияния доработки Разработчикам других подсистем — СП технолог подсистемы, 1 день с даты согласования состава доработки.
Согласование планов выпуска	Формирование заявок на согласование плана выпуска доработки — Разработчик подсистемы, 2 дня после согласования состава доработки. Выявление противоречий в планах выпуска смежных доработок, уточнение планов выпуска с Выпускающим редактором — Разработчик подсистемы, Выпускающий редактор, 1 день после направления заявок на согласование плана выпуска Выпускающему редактору. Утверждение плана выпуска доработки Заказчиком — Заказчик, 2 дня после направления заявки на согласование плана выпуска Выпускающим редактором на утверждение.
Согласование детальных требований	Разработка и согласование ЧТЗ, Разработка и согласование объекта ТФФ — согласно требованиям Контракта Разработчика подсистемы.
Реализация доработки	Реализация и внутреннее тестирование доработки в соответствии с ЧТЗ, доработка/разработка эксплуатационной документации — согласно требованиям Контракта Разработчика подсистемы.
Подготовка к ПДИ	Сборка версии — Выпускающий редактор, 1 день после получения заявки на сборку. Установка версии на тестовый стенд ПДИ — Выпускающий редактор, 5 дней после получения заявки на установку. Регрессионное тестирование версии Выпускающим редактором на тестовом стенде ПДИ — согласно требованиям Контракта Выпускающего редактора. Разработка и согласование ПиМ — согласно требованиям Контракта Разработчика подсистемы. Функциональное тестирование версии Разработчиком подсистемы на тестовом стенде ПДИ — Разработчик подсистемы, одновременно с регрессионным тестированием Выпускающим редактором. Определение пилотной группы — СП-технолог подсистемы, 10 дней до начала ПДИ. Передача плана ПДИ — согласно требованиям Контракта Разработчика подсистемы.
Проведение интеграционного тестирования	Подготовка сценария интеграционного тестирования — Разработчик подсистемы (в части своей подсистемы), одновременно с ПиМ. Определение сроков интеграционного тестирования и пилотной группы — СП технолог подсистемы, 10 дней до начала ПДИ. Прохождение сценариев интеграционного тестирования, обработка замечаний, выявленных в ходе интеграционного тестирования — Разработчик подсистемы (в части своей подсистемы), в сроки интеграционного тестирования.
Проведение ПДИ	Прохождение сценариев ПиМ ПДИ, обработка замечаний, выявленных в ходе ПДИ, — согласно требованиям Контракта Разработчика подсистемы.
Подготовка к ОЭ	Передача плана ОЭ — согласно требованиям Контракта Разработчика Подсистемы. Установка версии на ПАК для ОЭ — согласно требованиям Контракта Выпускающего редактора.
Опытная эксплуатация	Прохождение сценариев ПиМ ОЭ, обработка замечаний, выявленных в ходе ОЭ, утверждение ЧТЗ — согласно требованиям Контракта Разработчика подсистемы.
Передача в эксплуатацию.	Подписание акта принятия в эксплуатацию, подписание протоколов сдачи-приемки доработок версии — согласно требованиям Контракта Разработчика подсистемы.

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

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

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

Проектные роли и полномочия сотрудников Заказчика, Выпускающего редактора и Разработчиков подсистем фиксируются в документах «Ролевая матрица сотрудников ФК», «Ролевая матрица сотрудников Выпускающего редактора ЭБ», «Ролевая матрица сотрудников Разработчика подсистемы ЭБ». Шаблоны ролевых матриц приведены в п. п. 15.1, 15.2, 15.3.

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

2.2. Порядок взаимодействия

В качестве способов взаимодействия могут использоваться:

система управления выпуском версий (СУВВ);
совещания с фиксацией принятых решений в протоколах;
официальные письма.

Каналом связи, по которому осуществляется передача и обработка заявок на планирование версии, заявок на доработку, является СУВВ.

Каналом связи, по которому осуществляется передача и обработка заявок на выпуск версии, обращений является СУЭ.

3. Формат номера версии подсистемы

В заявках на планирование версии, ГВВ, заявках на доработку, ПВВ, проектной документации, заявках на выпуск версии применяется единый формат номера версий подсистем i1.i2.i3.i4.ss.s1.s2.s3. Где

i1.i2.i3.i4 — четыре сегмента номера интеграционной версии. Первый сегмент используется для нумерации плановых версий, второй для внеочередных версий. Третий сегмент используется для нумерации плановых еженедельных патчей в ГВВ, четвертый для внеочередных экстренных патчей.
ss — сегмент с числовым кодом подсистемы согласно справочнику «Коды подсистем», приведенному в Приложении 15.9.
s1.s2.s3 — три сегмента с номером версии подсистемы.

4. Согласование графика выпуска версий

Согласованный график выпуска версий формируется как результат согласования Заказчиком проектов ГВВ и согласования изменений в график выпуска версий. Форма графика выпуска версий с примером заполнения приведена в Приложении 15.7.

4.1. Согласование проекта графика выпуска версий

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

Разработчики подсистем при необходимости дают мотивированные рекомендации Заказчику по переносу сроков интеграционных версий, указанных в проекте ГВВ. В случае принятия рекомендаций Заказчиком проект ГВВ повторно направляется Разработчикам подсистем.

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

После получения от всех Разработчиков подсистем информации о включении или отказе от включения в проект ГВВ версий подсистем проект ГВВ утверждается Заказчиком.

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

Интеграционным версиям из полугодового ГВВ присваиваются номера с «0» в сегментах 2, 3, 4.

Пример: 2.0.0.0.1300.8.11.0 — плановая версия ФП «Учет и отчетность».

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

Пример: 2.1.0.0.1300.8.12.0 — внеплановая версия ФП «Учет и отчетность».

Для обозначения плановых патчей, входящих в полугодовой ГВВ, отличный от «0» сегмент 3.

Пример: 2.1.2.0.1300.8.12.1 — патч с исправлением дефектов версии ФП «Учет и отчетность».

Для обозначения экстренных патчей, изначально не входящих в полугодовой ГВВ, используется отличные от «0» сегменты 3,4.

Пример: 2.1.2.1.1300.8.12.2 — патч с исправлением дефектов версии ФП «Учет и отчетность», вышедший после планового интеграционного патча 2.1.2.0.

4.2. Согласование изменений в график выпуска версий

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

Заявка на планирование версий подсистемы направляется на согласование СП-технологу подсистемы, ВР.

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

При формировании заявок Разработчик должен ориентироваться на сроки выпуска интеграционных версий в согласованном ГВВ и стараться минимизировать создание новых интеграционных версий. Если Заказчик подтверждает необходимость создания новой интеграционной версии, запускается процесс согласования проекта ГВВ, описанный в п. 4.1, в результате которого в ГВВ вносится новая интеграционная версия.

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

5. Согласование требований

5.1. Регистрация требований

В связи с событиями, описанными в п. 1, и по результату внутреннего согласования между структурными подразделениями ФК необходимости анализа требований на доработку, СП-постановщик подсистемы регистрирует в СУВВ требование с приложением материалов:

Описание требования в терминах вариантов использования;
Редакцию проекта НД/утвержденной НД и требования по анализу влияния изменений НД на ФП;
Альбом/проект альбома ТФФ;
Подсистема инициатор (должна быть указана подсистема для которой требуется изменение)

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

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

Описание требования в терминах вариантов использования;
Номер заявки СУЭ;
Номер доработки ФП, для реализации которой требуются дополнительные сервисы;
Подсистема инициатор (должна быть указана подсистема для которой требуется изменение)
Влияние на подсистемы (как минимум, должна быть указана подсистема, по которой требуется изменение)

Срок реализации нового требования.

После регистрации требования СП-технолог подсистемы инициатора направляет Разработчикам заявки на анализ требований (ЗНА). Реквизитный состав ЗНА приведен в Приложении 15.6.

5.2. Согласование состава доработок

По факту получения ЗНА, Разработчик подсистемы проводит анализ требований. В результате анализа, при выявлении Разработчиком необходимости изменений системы/подсистемы, в СУВВ регистрируется доработка. В доработке уточняется и детализируется состав требований. После вынесения доработки инициирующая ЗНА закрывается РП. Если изменений системы/подсистемы не выявлено, то ЗНА отклоняется РП с поясняющим комментарием.

В системе управления выпуском версий в адрес структурных подразделений, отмеченным в Ролевой матрице ФК (п. 15.1) как технологи подсистемы, РП формирует заявки на согласование состава доработки (ЗСС).

При наличии замечаний к поступившим условиям реализации доработки подразделение ФК переводит ЗСС на анализ Разработчика подсистемы.

Процесс продолжается до тех пор, пока все ЗСС не будут согласованы подразделениями ФК, либо пока хотя бы одно из подразделений ФК не отклонит ЗСС.

По отклоненным доработкам все работы прекращаются.

5.3. Оценка влияния доработки

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

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

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

6. Согласование планов выпуска

6.1. Формирование плана выпуска доработки

После согласования состава доработки (п. 5.2) Разработчик подсистемы формирует заявки на согласование плана выпуска доработки (ЗСП) для формирования плана выпуска версий.

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

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

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

При выявлении противоречий в сроках выпуска смежных доработок подсистем Выпускающий редактор отправляет ЗСП Разработчикам подсистем смежных доработок.

Процесс продолжается до тех пор, пока все противоречия не будут устранены.

6.3. Утверждение плана выпуска доработки

После согласования ЗСП Выпускающим редактором в адрес структурных подразделений, отмеченных в Ролевой матрице ФК как технологи подсистемы, поступают ЗСП.

При наличии замечаний к поступившим условиям реализации доработки подразделение ФК переводит ЗСП на анализ Разработчика подсистемы.

Процесс продолжается до тех пор, пока все ЗСП не будут согласованы подразделениями ФК, либо пока хотя бы одно из подразделений ФК не отклонит доработку.

По отклоненным доработкам все работы прекращаются.

После согласования плана выпуска доработка считается включенной в ПВВ. Форма плана выпуска версий с примером заполнения приведена в Приложении 15.7.

7. Согласование детальных требований

Процесс разработки и согласования ЧТЗ и объектов ТФФ проводится согласно требованиям Контракта на соответствующую подсистему.

8. Реализация доработки

Процесс реализации и внутреннего тестирование доработки в соответствии с ЧТЗ, доработка/разработка эксплуатационной документации проводятся согласно требованиям Контракта на соответствующую подсистему.

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

9. Подготовка к ПДИ

9.1. Регрессионное тестирование версии Выпускающим редактором

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

Процесс инициируется Разработчиком подсистемы с помощью заявки на выпуск версии, адресованной в СУЭ на Выпускающего редактора. В заявке указываются номер версии и ссылка на репозиторий с исходными кодами, инструкциями и сопроводительными документами к версии согласно Контракту Разработчика.

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

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

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

При выявлении дефектов регрессионного тестирования или проблем, связанных со сборкой и установкой версии подсистемы на стенд, Выпускающий редактор заводит обращения в СУЭ на Разработчика подсистемы. Обработка обращений осуществляется согласно условиям Контракта Разработчика подсистемы.

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

В случае успешного прохождения регрессионного тестирования заявка на выпуск версии закрывается.

9.2. Функциональное тестирование версии Разработчиком подсистемы

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

9.3. Разработка и согласование ПиМ

Разработка и согласование ПиМ производятся согласно требованиям контракта Разработчика подсистемы.

9.4. Определение пилотной группы, передача плана ПДИ

Для проведения ПДИ СП-технолог подсистемы определяет пилотную группу, которая будет осуществлять прохождение сценариев ПиМ.

После получения информации от СП-технолога подсистемы о пилотной группе, Разработчик подсистемы согласно требованиям Контракта, готовит план ПДИ со сроками этапов ПДИ.

10. Предварительные приемочные испытания

ПДИ версии подсистемы проводятся согласно требованиям Контракта Разработчика подсистемы.

11. Интеграционное тестирование

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

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

Заказчик определяет сроки проведения интеграционного тестирования и пилотную группу и информирует Разработчиков.

Интеграционное тестирование осуществляется на стенде для проведения ПДИ.

Обработка обращений интеграционного тестирования осуществляется согласно правилам обработки обращений ПДИ.

12. Подготовка к ОЭ

12.1. Подготовка плана ОЭ

Разработчик подсистемы готовит план ОЭ согласно требованиям Контракта.

12.2. Установка версии на ПАК для ОЭ, передача в ФАП

После получения положительных протоколов о прохождении ОЭ, Выпускающий редактор передает версию подсистемы в ФАП согласно требованиям своего Контракта. Одновременно Выпускающий редактор производит установку версии на промышленный ПАК.

13. Опытная эксплуатация

ОЭ версии подсистемы проводится согласно требованиям Контракта Разработчика подсистемы.

14. Передача в ПЭ

Передача в ПЭ версии подсистемы проводится согласно требованиям Контракта Разработчика подсистемы.

15. Приложения

15.1 Ролевая матрица Федерального казначейства для подсистем ЭБ.

Подразделение ФК/Сотрудник (ФИО)	Должность	e-mail	Телефон	Скайп	Подсистема (из справочника - п. 15.9)	Роль (из справочника - п. 15.10)
	Подразделение 1


Подразделение 2

15.2 Ролевая матрица Разработчика подсистемы ЭБ.

Подразделение РП/Сотрудник (ФИО)	Должность	e-mail	Телефон	Скайп	Подсистема (из справочника - п. 15.9)	Роль (из справочника - п. 15.11)
	Подразделение 1


Подразделение 2

15.3 Ролевая матрица Выпускающего редактора ЭБ.

Подразделение ВР/Сотрудник (ФИО)	Должность	e-mail	Телефон	Скайп	Подсистема (из справочника - п. 15.9)	Роль (из справочника - п. 15.12)
	Подразделение 1


Подразделение 2

15.4 Заявка на планирование интеграционной версии.

Сводная версия ЭБ	Выпуск подсистемы в составе интеграционной версии	Версия подсистемы	Дата передачи кодов ВР	Дата начала ПДИ	Дата окончания ПДИ	Дата начала ОЭ	Дата окончания ОЭ	Дата начала ПЭ	Резолюция
	Номер версии

15.5 Заявка на планирование версии подсистемы.

Сводная версия ЭБ	Версия подсистемы	Дата передачи кодов ВР	Дата начала ПДИ	Дата окончания ПДИ	Дата начала ОЭ	Дата окончания ОЭ	Дата начала ПЭ	Резолюция
	Номер версии

15.6 Заявка на анализ требований.

№ п/п	Номер SAM	Название	Описание	Приоритет	Примечание

15.7.

15.8 График выпуска версий и план выпуска версий.

График выпуска:

Интеграционная версия	Дата начала ПДИ	Дата начала ОЭ	Дата начала ПЭ
Номер версии

План выпуска:

№ п/п	Номер SAM	Название	Описание	Подсистема (из справочника - п. 15.9)	Подсистема инициатор (из справочника - п. 15.9)	Приоритет	Основание работ	Статус согласования	Заявка на анализ	Мероприятия со стороны РФП по внедрению доработки

15.9 Справочник кодов подсистем.

Числовой код	Код	Код (Л)	Подсистема
0100	ПОИ	EB	Подсистема обеспечения интеграции, ведения реестров и формуляров
0200	ПОИБ	SEC	Подсистема обеспечения информационной безопасности
0300	ПОЮЗД	LAW	Подсистема обеспечения юридической значимости электронных документов
0400	НСИ	REF	Подсистема ведения нормативной справочной информации
0410	НСИ_СВР	REF_SVR	Сводный реестр УНБП
0420	НСИ_БПГУ	REF_BPGU	Базовые (отраслевые) перечни государственных услуг (работ)
0430	НСИ_ВПГУ	REF_VPGU	Ведомственные перечни государственных услуг (работ)
0440	НСИ_ПДИ	REF_PDI	Перечень источников доходов
0450	НСИ_ПББС	REF_PBBS	Перечень бюджетов бюджетной системы РФ
0500	БП	BPL	Бюджетное планирование
0600	УД	REV	Подсистема управления доходами
0700	УР	EXP	Подсистема управления расходами
0710	УР_РГЗ	EXP_RGZ	Реестр госзаданий
0720	УР_РС	EXP_RS	Реестр соглашений
0800	УЗ	PUR	Управление закупками
0900	УГДиФА	DFA	Управление долгом и финансовыми активами
1000	НФА	№ FA	Подсистема управления нефинансовыми активами
1100	УКР	HRM	Подсистема управления кадрами
1200	УДС	CAM	Подсистема управления денежными средствами
1300	УиО	ARP	Учет и отчетность
1400	ФК	FCT	Подсистема финансового контроля
1500	ИАО	BIR	Подсистема информационно-аналитического обеспечения
1600	ЕПБС	PEB	Единый портал бюджетной системы

15.10 Справочник ролей ФК.

Роль	Описание	Полномочия
ЗРФК	Курирующий ЭБ заместитель руководителя ФК	Утверждение ПиМ, ЧТЗ, ТР, Альбомов ТФФ, протоколов ПДИ, Актов приема версии в ОЭ, протоколов ОЭ, Актов приема версии в ПЭ. Утверждение Графика выпуска версий.
Координатор	Координатор подсистемы	Согласование заявок на выпуск интеграционных версий. Ввод и согласование требований.
Постановщик	Постановщик задачи конкретной доработки подсистемы от УФТ, УИИСГФ, УИС, других СП	Ввод и согласование требований.
Руководитель проекта	Руководитель проекта доработки подсистемы — менеджер контракта	Визирование ПиМ, ЧТЗ, ТР, Альбомов ТФФ, протоколов ПДИ, Актов приема версии в ОЭ, протоколов ОЭ, Актов приема версии в ПЭ. Визирование Графика выпуска версий. Визирование деловой переписки. Согласование заявок на выпуск интеграционных версий. Формирование пилотных групп для проведения ПДИ и ОЭ. Согласование планов проведения ПДИ и ОЭ.
Технолог	Технолог подсистемы	Формирование заявок на анализ требования. Формирование заявок на оценку влияния. Согласование состава доработки. Согласование трудоемкости. Согласование планов мероприятий. Согласование ПиМ, ЧТЗ, ТР, Альбомов ТФФ, протоколов ПДИ, Актов приема версии в ОЭ, протоколов ОЭ, Актов приема версии в ПЭ.
Администратор	Администратор проекта подсистемы	Обработка деловой переписки. Назначение при необходимости зарегистрированных заявок на исполнителей внутри системы учета заявок.

15.11 Справочник ролей РП.

Роль	Описание	Полномочия
Руководитель проекта	Руководитель проекта доработки подсистемы	Визирование ПиМ, ЧТЗ, ТР, Альбомов ТФФ, протоколов ПДИ, Актов приема версии в ОЭ, протоколов ОЭ, Актов приема версии в ПЭ. Визирование Графика выпуска версий. Визирование деловой переписки. Формирование и согласование заявок на выпуск версий. Формирование и согласование планов мероприятий. Формирование и согласование трудоемкости.
Аналитик	Аналитик или архитектор разработчика подсистемы	Анализ требований в заявках на доработку и регистрация доработок. Согласование требований. Разработка и согласование ЧТЗ, ТР, Альбомов ТФФ.
Инженер по тестированию	Инженер по тестированию доработок подсистемы	Разработка и согласование ПиМ. Формирование планов проведения ПДИ и ОЭ. Обработка обращений Выпускающего редактора по регрессионному тестированию. Обработка обращений пилотных групп во время ПДИ и ОЭ.
Менеджер производства	Менеджер производства подсистемы	Передача исходных кодов подсистемы выпускающему редактору по акту.
Администратор	Администратор проекта подсистемы	Обработка деловой переписки. Назначение при необходимости зарегистрированных заявок на исполнителей внутри системы учета заявок.

15.12 Справочник ролей ВР.

Роль	Описание	Полномочия
Руководитель проекта	Руководитель проекта по услугам Выпускающего редактора ЭБ	Визирование Графика выпуска версий. Визирование деловой переписки. Формирование и согласование заявок на выпуск интегрированных версий. Анализ противоречий в планах мероприятий и согласование планов мероприятий.
Инженер по тестированию	Инженер по тестированию доработок подсистем ЭБ.	Формирование обращений по регрессионному тестированию.
Менеджер производства	Менеджер производства по услугам Выпускающего редактора ЭБ.	Приемка исходных кодов от Разработчика подсистемы для регрессионного тестирования по акту. Уведомление Разработчика подсистемы о развертывании версии или патча на тестовой среде для функционального тестирования. Уведомление пилотной группы и Разработчика подсистемы о развертывании версии на тестовой среде для прохождения ПДИ. Уведомление пилотной группы и Разработчика подсистемы о развертывании версии на промышленной среде для прохождения ПДИ.
Администратор	Администратор проекта подсистемы	Обработка деловой переписки. Назначение при необходимости зарегистрированных заявок на исполнителей внутри системы учета заявок.