Конференция: ЛАФ-2015Уважаемые представители оргкомитета!
Выполняя просьбу Александра о наиболее подробном описании темы и с учетом вопросов по докладу Минска, многое (не все) написано не в формате тезисов, а в формате доклада и с заметками для слайдов (курсивом). Но, конечно, это не окончательный доклад.
Если читать долго (много буквов!) - сообщите, напишу короче.
Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами. Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ - Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО.
По заявкам, поступающим от Заказчика (на основании изменений к нормативно-правовых актов (далее - НПА, проекты НПА) или для оптимизации работ) в системе учета JIRA регистрируются доработки для каждой подсистемы отдельно в разрезе заявки и подсистемы. После предварительного анализа и определения трудозатрат и в соответствии со сроком вступления в действие НПА доработки включаются в версию, передаваемую Заказчику к заранее определенной дате. Версия содержит изменения по всем ПО в зоне ответственности Исполнителя. Доработки, по различным заявкам Заказчика (имеющие разные основания для включения в версию), входящим в одну версию, часто затрагивают одну и ту же функциональность или влияют на смежные функции системы. Т.е. в версии могут содержаться разные доработки, влекущие изменение одних и тех же функций одного и того же документа. Но в процессе работ по доработкам версии от Заказчика могут поступить изменения к проектам НПА, поступившим первоначально или перенос сроков вступления в действие НПА или новые заявки (которые нужно реализовать в те же сроки), влияющие на ту же функциональность.
Система достаточно большая, сроки проектирования, разработки, подготовки проектных документов очень жесткие. Зачастую изменения проектов НПА поступает уже после начала не только проектирования, но и разработки. Поэтому отследить все изменения в оперативном режиме, вовремя перепроектировать, передать в разработку по всем подсистемам и не сломать решения по доработкам, связанным с другими заявками Заказчика, но по этой же функциональности - задача не совсем простая. При этом проектную документацию нужно передать в установленные сроки по версии и строго описывающую доработки с учетом поступивших изменений.
Количественно по одной версии (периодичность версий - 2-3 месяца):
- доработок в версии по одной подсистеме: 150-250;
- изменяемых интерфейсов - 50-70;
- изменяемых подсистем: обычно 3, бывает до 6;
- (продумать еще количественные показатели).
Мой рассказ о том, как мы формируем требования к интерфейсам обмена на основании доработок, контролируем синхронность функциональных изменений в разных подсистемам (учетной, транспортной, отчетной) и по связанной функциональности.
Что нам помогает:
1. Договоренность с Заказчиком о сроках поступления заявок и включении доработок в версию. Конечно, сроки далеко не всегда выдерживаются в т.ч. по причинам, не зависящим от Заказчика.
2. Инструментарий
2.1. JIRA с высокой степенью кастомизации, единый подход:
– требования НПА/запросы Заказчика, связь НПА и доработок;
- доработки в разрезе подсистем ПО;
- интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание;
- обращения, ошибки.
Настроены типы связей и стараемся их отражать.
Показать описание доработки.
2.2. Subversion, хранилище документации:
- поддержка версионности;
- структуризация хранения документов;
- обязательность использования;
- централизованное решение для распределенной команды.
Показать структуру Альбома ТФФ, версионность, ревизии.
2.3. Система ведения требований к интерфейсов обмена (ТФФ), единое хранилище состояния интерфейсов (ТФФ), программы формирования Альбома с учетом отражения артефактов в разных разделах Альбома и контроля непротиворечивости. Хранимые значения:
- наименование, назначение, маршрутизация;
- мнемоника, тип данных, длина;
- комментарии (условия контроля реквизита в ПО);
- версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии,
- шаблон, пример.
Особенности изменения версионности ТФФ.
3. Методика, обязательная к выполнению, разработки для внутреннего использования:
- регистрация сущностей в JIRA;
- контроль взаимосвязанных элементов, синхронизация;
- разнообразные отчеты, контроль выполнения.
Показать зависимости функциональности ПО и изменений интерфейсов.
Пример зависимости изменения интерфейса и ПО.
Показать связи отражения изменений ПО и интерфейсов на разных этапах работ с указанием зоны ответственности бизнес анализа, системного анализа, разработки.
Показать схему ЖЦ доработок этапов анализа и проектирования с указанием точек контроля:
- полнота регистрации доработок по подсистемам, наличие зарегистрированных изменений интерфейсов;
- включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ;
- проверка изменяемых функций ПО по доработкам и изменяемых интерфейсов;
- подготовка бизнес требований по изменяемым интерфейсам;
- согласование бизнес требований внутри бизнес аналитиков по смежным функциям ПО;
- внесение изменений в систему ведения ТФФ;
- формирование Альбома ТФФ;
- согласование Альбома со стороны бизнес аналитиков, системных аналитиков (технических архитекторов) всех подсистем;
- согласование с Заказчиком, через Заказчика - с разработчиками внешних систем.
При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости - их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием.
Автоматизация позволила быстро вносить изменения и переформировывать Альбом, исключить ручное дублирование одних и тех же сведений в разных разделах Альбома (и соответственно, технические ошибки, особенно по срочным изменениям Альбома перед самой публикацией). И конечно, снижение трудозатрат, снижение стрессовости работ.
Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный.