Летний Аналитический Фестиваль - Управление требованиями и автоматизация подготовки проектных документов

Летний Аналитический Фестиваль

Управление требованиями и автоматизация подготовки проектных документов


Партнёры
Уже зарегистрировалось
180
Организатор
Оргкомитет

Доклад (40 минут)
Автор: Ирина Гертовская

Уважаемые представители оргкомитета!

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

Если читать долго (много буквов!) - сообщите, напишу короче.

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

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

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

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

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

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

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

- (продумать еще количественные показатели).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показать зависимости функциональности ПО и изменений интерфейсов.

Пример зависимости изменения интерфейса и ПО.

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

Показать схему ЖЦ доработок этапов анализа и проектирования с  указанием точек контроля:

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

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

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

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

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

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

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

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

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

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

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

Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный.