ЛАФ-2015: Ирина Гертовская. Управление требованиями и автоматизация подготовки проектных документов

Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами.  Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ — Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО.

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

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

Количественно по одной версии (периодичность версий — 2-3 месяца):

— доработок в версии по одной подсистеме: 150-250;

— изменяемых интерфейсов — 50-70;

— изменяемых подсистем: обычно 3, бывает до 6;

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

Что нам помогает:

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

2. Инструментарий

2.1. JIRA с высокой степенью кастомизации, единый подход:  

– требования НПА/запросы Заказчика, связь НПА и доработок;

— доработки в разрезе подсистем ПО;

— интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание;

— обращения, ошибки.

Настроены типы связей и стараемся их отражать.

Показать описание доработки.

2.2. Subversion, хранилище документации:

— поддержка версионности;

— структуризация хранения документов;

— обязательность использования;

— централизованное решение для распределенной команды.

Показать структуру Альбома ТФФ, версионность, ревизии.

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

— наименование, назначение, маршрутизация;

— мнемоника, тип данных, длина;

— комментарии (условия контроля реквизита в ПО);

— версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии,

— шаблон, пример.

Особенности изменения версионности ТФФ.

3. Методика, обязательная к выполнению, разработки для внутреннего использования:

— регистрация сущностей в JIRA;

— контроль взаимосвязанных элементов, синхронизация;

— разнообразные отчеты, контроль выполнения.

Точки контроля в ЖЦ доработок этапов анализа и проектирования:

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

— включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ;

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

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

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

— внесение изменений в систему ведения ТФФ;

— формирование Альбома ТФФ;

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

— согласование с Заказчиком, через Заказчика — с разработчиками внешних систем.

При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости — их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием.

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