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

Работая над статьей о роли требований в процессе разработки программного обеспечения я обнаружил шкалу уровней зрелости процесса управления требованиями (requirements management maturity), предложенную в 2003 году одним из специалистов по работе с требованиями Rational Software Джимом Хьюманном (Jim Heumann).

Хочу поделиться с читателями habrahabr данной классификацией.

Введение

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

Ниже приведена шкала уровней зрелости процесса управления требованиями, построенная по аналогии с моделью CMMI. Эти модели никак не связаны между собой, но имеют некоторое пересечение. Так, достижение уровня 5 (Интеграция требований) зрелости процесса управления требованиями позволит получить как минимум уровень 3 (Процессы определены на уровне всей организации) по модели CMMI. Однако это не является прямым следствием, так как достижение высокого уровня зрелости в одном процессе не гарантирует общего повышения зрелости организации в целом.

Шкала зрелости

Уровень 0. Отсутствие требований

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

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

В результате получается продукт, который:

• не имеет требуемой функциональности;
• имеет излишнюю функциональность;
• имеет низкое качество.

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

Уровень 1. Документирование требований

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

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

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

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

Уровень 2. Организация требований

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

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

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

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

Уровень 3. Структурирование требований

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

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

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

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

Уровень 4. Трассировка требований

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

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

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

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

Уровень 5. Интеграция требований

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

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

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

Снова от меня: Как уже было сказано ранее, принятие решения о достижении того или иного уровня зрелости процесса управления требованиями должно осуществляться взвешено и на основании четкого понимания целей и задач, стоящих перед командой проекта или компанией. Очевидно, что излишне заниматься трассировкой требований в стартап-команде, состоящей из 3-5 человек. Однако в российской действительности все еще встречаются компании, которые долгое время разрабатывают программное обеспечение, не утруждаясь даже документированием. Конечно же, в таких компаниях зрелость сопутствующих процессов разработки крайне низка, что безусловно отражается на качестве выпускаемых программных продуктов.

Автор: algusen

Источник