В индустрии разработки программного обеспечения (ПО) существуют много различных методологий разработки, которые представляют из себя достаточно концептуальные видения того, как следует реализовывать проекты по созданию ПО. В качестве примеров таких методологий можно привести: Rational Unified Process (RUP), Microsoft Solution Framework (MSF), Extreme Programming (XP), Agile, Capability Maturity Model Integration (CMMI) и многие другие.

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

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

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

Содержание

• Ролевая модель
• Схема бизнес-процесса
• Участие ролей в операциях бизнес-процесса (выравнивание профилей загрузки ролей на всем протяжении проекта)
• Информационная модель бизнес-процесса
• Средства автоматизации бизнес-процесса

Ролевая модель

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

Схема бизнес-процесса

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

Бизнес-процесс включает в себя пять групп (контуров) работ:

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

Контур сбора требований

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

В частности, требованиями являются:

• Ошибки, выявленные при внутреннем или внешнем (ПСИ) тестировании, в процессе эксплуатации решения
• Функциональные требования (доработки)
• Нефункциональные требования (ограничения, которым должно удовлетворять решение)

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

• Представители Заказчика
• Тестеры в составе проектной команды
• Руководства компании

Все требования хранятся в Репозитории требований. Подробнее о требованиях (их атрибутах и жизненном цикле) написано в разделе «Информационная модель».

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

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

Все требования делятся на две группы с точки зрения подхода к их реализации:

• Мелкие доработки

  • o длительность их реализации до 1 человеко-дня И
  • o не требуют аналитической проработки (написания Технического проекта)
• Средние и крупные доработки

  • o длительность реализации более человеко-дня ИЛИ
  • o требуют аналитической проработки (написания Технического проекта)

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

Реализация средних и крупных доработок происходит постадийно:

• Планируется реализация доработок и аналитических работ по их проработке (Контур среднесрочного планирования)
• Проводятся аналитические работы, по их результатам составляется Технический проект (ТП) на реализацию требования (Контур аналитических работ)
• В рамках детального планирования работ по разработке текущей версии выбираются проработанные требования с готовыми ТП и включаются в состав задач для рабочего проектирования и реализации в текущей версии (Контур разработки версии)

Контур среднесрочного планирования

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

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

На основании среднесрочного плана по реализации требований производится детальное планирование аналитических работ по написанию ТП с постановкой задачи по их реализации.

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

Контур аналитических работ

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

Технический проект, подготовленный Аналитиком, согласуется с:

• Руководителем проекта
• Руководителем группы
• Архитектором

После составления и согласования ТП требование помечается как готовое к включению в план разработки версии.

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

Контур разработки версии

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

При планировании работ по версии проектная команда просматривает требования, выбирая среди них те, которые:

• в соответствии со среднесрочным планом должны быть реализованы в рамках настоящей версии И
• по которым завершена аналитическая проработка (имеется согласованный ТП)

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

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

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

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

• Архитектором
• Руководителем группы
• Руководителем проекта

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

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

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

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

Также после согласования новой функциональности Аналитик обновляет пользовательскую документацию на решение.

После того, как все доработки, запланированные в версии, реализованы Билд-инженер производит сборку версии. Билд-инженер, формирует Сопроводительный документ к версии, в котором:

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

Собранная версия тестируется Тестером при участии Аналитика согласно плану тестирования, являющегося составной частью Технического проекта, разработанного Аналитиком. Выявленные ошибки регистрируются в Репозитории требований в виде требований с типом «Ошибка тестирования версии».

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

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

• Все «Ошибки тестирования версии» устранены
• Принимается решение о выпуске версии с рядом не устраненных ошибок

После того как принято решение о выпуске версии Билд-инженер готовит дистрибутивы и Сопроводительный документ (актуализирует его при необходимости) и передает его для развертывания.

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

Контур небольших доработок

Небольшие доработки – доработки с длительностью реализации менее человеко-дня, не требующие написания Технического проекта и Рабочего проекта.

Все небольшие доработки делятся на две группы:

• С нормальным приоритетом – включаются в следующую основную версию.
• С критическим приоритетом – для них выпускается промежуточная версия путем внесения требуемых изменений в экземпляр с кодом текущей развернутой версии.

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

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

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

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

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

Участие ролей в операциях бизнес-процесса

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

На схеме ниже в качестве примера приведено распределение работ при разработке версии с длительностью 8 недель. Рассмотрена вся проектная команда, задействованная во всех контурах работ.

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

Также важным моментом является участие Разработчика, как в плановых работах по версии, так и в устранении мелких, в т.ч. высоко критичных замечаний.

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

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

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

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

Информационная модель бизнес-процесса

Все виды информации в рамках бизнес-процесса разработки распределяются по пяти хранилищам (репозиториям):

• Репозиторий требований
• Репозиторий архитектуры
• Репозиторий документации
• Репозиторий кода
• Репозиторий задач (план работ)

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

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

Средства автоматизации бизнес-процесса