К вопросу об управлении требованиями в проектах по разработке и внедрению программного обеспечения по гибким методикам разработки

Перелыгин Тимур Вадимович
Выпускник группы ITM-23B
РАНГХиГС при Президенте РФ.
Руководитель проектов. ЗАО Спектр

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

Начнем с процесса управления требованиями. Как правило,  управление требованиями производится в соответствии с неким регламентом,  который формализует процесс работы с требованиями. Определим задачи данного регламента:         

• Работа по данному регламенту должна позволить четко сформулировать и зафиксировать в договоре с Заказчиком требования к создаваемой(модифицируемой)  системе. В моменты времени, определяемые договором, мы должны однозначно понимать,  выполнены обязательства перед Заказчиком или нет, и если нет  то, что нужно сделать для того, чтобы обязательства были выполнены в полном объеме.
• В связи с тем, что передача результатов работы по договору,  как правило, осуществляется по результатам приемо-сдаточных испытаний, данный регламент должен обеспечивать однозначное соответствие между требованиями и тест - кейсами, которые проверяют реализацию требований.
• Работа по данному регламенту должна позволить определить правдоподобную трудоемкость реализации требований. С тем чтобы можно было оценить стоить работ и включить ее в договор с Заказчиком.
• Работа по данному регламенту должна позволить зафиксировать требования к создаваемой(модифицируемой) системе от  всех классов заинтересованных лиц. Для того, что бы Заказчик , по окончании работ,  получил систему,  полностью удовлетворяющею его требованиям.
• Работа по данному регламенту должна позволить вносить изменения в требования к системе в произвольный момент времени. При этом должна быть обеспечена управляемость проектом. Т.е. изменяя те или иные требования,  добавляя новые требования,  мы должны понимать как изменятся основные параметры проекта. Такие как сроки и стоимость проекта. При этом качество продукта не может быть снижено.
• Работа по данному регламенту должна позволить определить какие ограничения накладывает отсутствие реализации того или иного требования. Т.е. планируя промежуточный показ функционала, мы должны понимать,  что мы можем показать Заказчику, а что нет. Либо,  какие ограничения  необходимо внести в программу показа. Как следствие,  регламент должен позволять осуществлять фиксацию приоритета требований. 
• Работа по данному регламенту должна обеспечивать динамическую приоритезацию требований. Т.е. в зависимости от задач,  стоящих перед руководством проектом,  требованиями должны изменить свой приоритет.

Для решения этих задач, сформулируем   термин «Требование». Единого определения не существует,  но нашим целям  больше соответствует определение, данное Карлом Вигерсом в его книге «Разработка требований к программному обеспечению».

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

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

• Трудоемкость реализации требования – определяет количество трудозатрат,  необходимых для анализа  и реализации требования.
• Приоритет требования – не может быть требований с одинаковым приоритетом. На каждом этапе проекта одно требование более важно,  чем другие.
• Проверяемость требования – Целью проверки является понимание того,  что все требования реализованы в продукте.
• Изменение требований – изменение требований не должно вести к ухудшению управляемости проекта.
• Текущее состояние реализации требований – менеджер проекта должен иметь возможность отследить текущее состояние реализации требований.

За характеристики  требований,  относящиеся ко второму классу, как правило, отвечает аналитик проекта.

• Полнота требования - они должны содержать всю необходимую информацию, чтобы разработчики смогли создать фрагмент функциональности,  определяемый данными требованием.
• Корректность требования - Каждое требование должно точно описывать желаемую функциональность.
• Осуществимость требования – У исполнителя должна быть возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды.
• Необходимость требования - Каждое требование должно отражать только те возможности, которые действительно необходимы пользователям или которые нужны для соответствия внешним системным требованиям или стандартам.
• Недвусмысленность требования – Все, кто читает требования,   должны понимать их однозначно.

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

В докладе Юрия Булуя на конференции SEC-R2006 сделано подробное сравнение вариантов типизации требований. Он сравнивает подходы к типизации требований,  предлагаемые Карлом Вигерсом, Дином Леффингуэллом,  а так же отношение к классификации требований в методологиях IBM RUP(Rational Unified Process), IEEE SWEBOK(Software Engineering Body of Knowledge) и ГОСТах серии 34.

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

• Бизнес требования – определяют высокоуровневые цели заказчиков системы. Они объясняют, почему заказчику нужна разрабатываемая  система, то есть бизнес требования описывают цели, которые организация-заказчик  намерена достичь с ее помощью. Бизнес требования фиксируются в документе «Устав продукта». В этом документе описываются основные преимущества, которые новая система даст ее заказчикам, покупателям и пользователям. Описываются бизнес –требования к системе, образ решения, масштаб и ограничения проекта, бизнес-контекст.
• Требования пользователей  – описывают цели и задачи, которые система позволит решить пользователям. При этом указываются бизнес - правила в виде регламентов различного рода и требования к атрибутам качества системы. Требования пользователей фиксируются в документе «Требования пользователей».  Данный документ состоит из трех частей.

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

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

• Функциональные требования – определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Функциональные требования документируются в спецификации требований к ПО, где описывается так полно, как необходимо, ожидаемое поведение системы. Данный документ, конвертирует пользовательские требования, описанные в документе «Требования пользователей», в  требования к системе. В документе предусмотрено три раздела:

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

Рисунок 1.

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

Рассмотрим предлагаемую технологию разработки более подробно.

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

Спринт — итерация в scrum, в ходе которой создаётся дополнительный законченный функционал системы. Жёстко фиксирован по времени. Длительность одного спринта составляет 2 недели.

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

Резерв спринта  — это список требований к функциональности, выбранный владельцем продукта из резерва проекта. Все требования детализированы по задачам, каждая из которых оценивается скрам - командой.
Шаблон для резерва спринта приведен в таблице 1

Таблица 1. Шаблон для резерва спринта

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

Диаграмма сгорания задач – показывает количество сделанной и оставшейся работы. Обновляется каждый день с тем, чтобы в простой форме показать подвижки в работе над спринтом. Диаграмма общедоступна для всех участников проекта. Пример диаграммы сгорания приведен на рисунке 2.

Рисунок 2. Пример диаграммы сгорания

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

Диаграмма сгорания задач для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте. 
И диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Реализация процесса разработки программного обеспечения в рамках методологии Скрам предполагает наличие следующих ролей:

• Скрам-мастер — проводит совещания и следит за соблюдением всех принципов Scrum, разрешает противоречия и защищает команду от отвлекающих факторов.
• Владелец продукта  — представляет интересы конечных пользователей и других, заинтересованных в продукте сторон.
• Скрам-команда — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Основные активности процесса разработки приведены на рисунке 3.

Рисунок 3. Основные активности процесса разработки.

• Планирование спринта происходит в начале новой итерации Спринта.

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

Обсуждается и принимается решение о том,  как будет реализован этот объем работ. Продолжительность совещания ограничена сверху 4 часами. На совещании обязательно фиксируется дата проведения демонстрации итогов спринта.

• Периодическое совещание проводиться раз в два дня.  В течение совещания каждый член команды отвечает на 3 вопроса:
• Что сделано с момента предыдущего совещания?
• Что будет сделано с момента текущего совещания до следующего?
• Какие проблемы мешают достижению целей спринта?

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

• Обзор итогов спринта проводится после завершения спринта. При этом команда демонстрирует приращение функциональности продукта всем заинтересованным лицам. Показ предполагает демонстрацию завершенного функционала. Т.е. инкремент функционала должен приносить результат значимый для конечного пользователя. В показе участвует вся команда,  привлекается максимальное количество зрителей. Длительность показа ограничивают 4мя часами.
• Ретроспективное совещание проводится после завершения спринта и предназначено для улучшения процесса разработки. При этом члены команды высказывают своё мнение о прошедшем спринте и отвечают на два основных вопроса:
• Что было сделано хорошо в прошедшем спринте?
• Что надо улучшить в следующем?

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

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

Список использованных источников

• Юрий Булуй. Классификация требований к программному обеспечению и ее представление в стандартах и методологиях. Доклад на конференции SEC-R 2006(сетевая публикация).
• Леффингуэлл Дин, Уидриг Дон. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. Москва. Издательский дом «Вильямс», 2002. 448с.
• Карл И. Вигерс. Разработка требований к программному обеспечению. Издательско-торговый дом «Русская Редакция», 2004. 576с.
• Филипп Крачтен. Введение в Rational Unified Process. Москва. Издательский дом «Вильямс», 2002 . 297с.
• ГОСТ 34.602 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Термины и определения. ГОСТ 34.003-90. Государственный Стандарт Российской Федерации, 1999. Госстандарт России, Москва 1990.
• Джефф Сазерленд. Scrum и XP: заметки с передовой. (Сетевая публикация)
• Корнипаев И. Требования для программного обеспечения: рекомендации по сбору и документированию. – М.: «Книга по требованию», 2013. 118с.