Пять уровней зрелости требований

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

Александр Байкин, ведущий аналитик и консультант, UML2.ru

Байкин Александр работает в области информационных технологий с 1999 года, из них последние 6 лет связаны с анализом требований к ПО и построением процессов разработки. Ведущий аналитик и консультант по процессам компании «Автомир» (http://www.avtomir.ru/). Автор и идеолог самого большого ресурса по анализу и проектированию ПО um2.ru (http://www.uml2.ru/). Автор многих статей по данной тематике. Выступал на многих семинарах и профильных конференциях (РИТ 2008, Training Labs 2008 и 2009, Software Engineering Forum 2009). Тренер и консультант в области ИТ-анализа и методологий разработки ПО. Связаться с ним можно через «Мой Круг» (http://baikin.moikrug.ru) или по электронной почте (asbaikin at gmail dot com).



Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт

Новичков Александр работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним можно по адресу rational.tools.info@gmail.com



10.12.2009

Введение

За последние 20 лет придумано множество методологий, стандартов, сводов знаний, фреймворков (framework) и практик в области разработки ПО, таких как RUP, MSF, Agile, ГОСТ, ISO, CMMI, SWEBOK, BABOK и т.д. Я уже не говорю про гору книг по данной тематике. Но все эти книги и методологии учат нас тому, как должно быть в идеале во всем процессе разработки ПО. В некоторых публикациях, правда, уделяется внимание именно процессу работы с требованиями (сбор, анализ, документирование, поверка и управление требованиями), но все равно они остаются слишком теоретизированными.

А что делать, если у вас процесс работы с требованиями не налажен, а хочется улучшить? Сразу же все не выкинешь и не начнешь жить по-новому! Поэтому и была написана данная статья, которая дает рекомендации по поэтапному внедрению «правильного» процесса управлениями требованиями.

Вероятность ошибки в процессе разработки ПО

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

Рисунок 1. Доля ошибок в различных артефактах при разработке ПО
Рисунок 1. Доля ошибок в различных артефактах при разработке ПО

Вследствие ошибок на разных этапах разработки ПО приходится затрачивать 30–50% средств от общего бюджета проекта на их исправление. Причем 70–85% от общего числа исправлений связанно именно с ошибками, допущенными на этапе сбора, анализа и документирования требований.

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

Не выявлены требования12,8%
Не четко сформулированы требования12,3%
Изменения требований11,8%

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


Пять уровней модели зрелости для управления требованиями

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

Рисунок 2. Соотношение рисков и сложности проекта с наложенными на них пятью уровнями модели зрелости для управления требованиями
Рисунок 2. Соотношение рисков и сложности проекта с наложенными на них пятью уровнями модели зрелости для управления требованиями

Далее рассмотрим все пять уровней модели зрелости для управления требованиями более подробно.


Уровень 0. Хаос, нет требований

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

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

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

В доказательство сказанного выше можно привести цитату из статьи Джоэля Спольски «Безболезненные функциональные спецификации – Часть 1: Зачем беспокоиться?»:

Давайте проведаем двух воображаемых программистов в двух компаниях. Программистка Быстрякова, из компании «Скороспелые Бананы Софт», никогда не пишет спецификации. «Спецификации? Нам не нужны никакие … спецификации!». А вот господин Разумихин из компании «Хороший Характер Софт», отказывается писать код, пока спецификация не будет полностью готова. Это только двое из многих моих воображаемых друзей.

У Быстряковой и Разумихина есть нечто общее: они заботятся о проблеме обратной совместимости для версии 2.0 своих разрабатываемых продуктов. Быстрякова решает, что наилучший способ обеспечить обратную совместимость – написать конвертер, который просто преобразует файлы версии 1.0 в файлы версии 2.0. Она сразу приступает к реализации. Пишет, пишет, пишет. Клик-клик-клик по клавишам. Жесткий диск крутится. Пыль летит. После примерно 2 недель работы у нее есть сносный конвертер. Но заказчики Быстряковой недовольны. Ее код заставляет всех сотрудников в их компании сразу переходить на новую версию программы. Самый большой заказчик Быстряковой, компания «Разборные Детали Анлимитед», отказывается покупать новую программу. Ребята из «Разборных Деталей» хотят быть уверены, что программа версии 2.0 будет продолжать обрабатывать файлы, созданные в версии 1.0, не преобразуя их в новый формат. Быстрякова решает написать обратный конвертер и затем нацепить его на функцию «Сохранение файла». Это привносит путаницу, потому что когда вы добавляете в файл, созданный под версией 2.0, новшества этой версии, они выглядят работающими, пока вы не начнете сохранять файл в формате версии 1.0. Только тогда вам будет выведено сообщение, что свойство, которое вы внесли в файл полчаса назад, не может быть сохранено в старом формате файла. Итак, разработка обратного конвертера заняла еще две недели, и этот конвертер работает не так уж хорошо. Потраченное время – 4 недели.

В то же время, господин Разумихин из компании «Хороший Характер Софт» (сокращенно, «ХХС») – один из тех занудных типов, которые отказываются писать код, пока не будет готова спецификация. Он тратит 20 минут, проектируя функцию обратной совместимости, так же, как делала Быстрякова, и выдает спецификацию, которая гласит:

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

Спецификация показывается заказчику, который говорит «Минуточку! Мы не хотим сразу переходить на новый формат!». Г-н Разумихин размышляет еще немного и вносит поправку:

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

Потрачено еще 20 минут.

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

* Код будет построен так, чтобы использовать два интерфейса: V1 и V2. V1 содержит все функции первой версии, а V2, который наследуется от V1, добавляет все нововведенные функции. Теперь метод V1::Save будет использоваться для обратной совместимости, а V2::Save может быть использован для сохранения всех нововведений версии 2. Если пользователь откроет файл через V1 и попытается использовать функциональность из V2, программа его об этом предупредит, и он вынужден будет либо конвертировать файл, либо прекратить использование нововведений второй версии.

Еще 20 минут.

Г-н Разумихин рассержен. Эта переработка займет 3 недели вместо 2 изначально запланированных! Но она элегантно решит все проблемы заказчика, так что он идет и выполняет ее.

В итоге г-н Разумихин потратил: 3 недели и 1 час. Потраченное время Быстряковой: 4 недели, но ее программа далеко не так хороша.

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


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

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

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

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

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

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


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

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

Требования должны быть хорошо отформатированы. Сквозная нумерация, постоянные схемы, заголовки, шрифты и хорошее оглавление делают ваши документы легкими для прочтения, понимания и дальнейшего использования. Если ваши требования хорошо описаны, но плохо отформатированы, то ваш документ может стать бесполезным в использовании. Форматирование – это простой прием, но почему-то часто игнорируется. Здесь могут помочь корпоративные или международные шаблоны спецификаций, такие как Концепция (Vision), Спецификация требований (Software Requirement Specification) и др. Причем во всей организации должны применяться единые форматирование и шаблоны.

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

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

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


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

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

Во-первых, вы должны выделять требования как атомарные единицы для того, чтобы было легче:

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

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

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

  • приоритезировать;
  • понимать, какие описаны, какие разработаны, а какие протестированы,
  • понимать, в какой версии ПО они реализованы, и т.д.

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

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

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

На данном уровне вам уже будет трудно управлять требованиями с помощью простого текстового редактора (MS Word Open или Office Writer), и на помощь могут прийти специализированные инструменты: IBM Rational RequisitePro и IBM Telelogic Doors.


Уровень 3.1. Моделирование требований

Даже идеально структурированные и организованные требования могут не дать полной картины потребности заказчика, потому что 20–50 страниц текста воспринять очень трудно. На помощь нам могут прийти разного рода модели, которые позволяют активизировать второе полушарие мозга и взглянуть на требования «по-новому».

При изучении и документировании бизнес-требований могут помочь модель объектов предметной области (Business/Domain Object Model), модель бизнес-вариантов использования (Business Use Case Model) или модель бизнес-процессов (Business Process Model).

При более детальном изучении потребностей заказчика (пользовательские требования) помогут модель системных вариантов использования (Use Case Model), представление пользовательских классов (View of Participating Classes) или диаграммы действий, состояний, взаимодействия.

Дальше идет уже проектирование ПО: диаграммы классов приложения и БД, диаграммы взаимодействия компонентов и классов, диаграммы действий и т.д.

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


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

Реализация предыдущих трех уровней модели зрелости для управления требованиями не дает вам возможности определять и прослеживать взаимосвязь между требованиями. Система любой сложности должна иметь иерархичность требований. Например, в RUP (Rational Unified Process) иерархия требований прослеживается между бизнес-потребностями, характеристиками ПО, вариантами использования и системными требованиями. Возможность отслеживать данную взаимосвязь обычно называется трассировкой. Трассировка дает возможность проследить влияние требований друг на друга и провести анализ покрытия требований.

При изменении одного требования аналитику важно знать, какие еще требования должны при этом измениться – это и называется прослеживанием влияния требований друг на друга. А после того как мы описали набор требований, нам необходимо знать, все ли требования верхнего уровня были детализированы и описаны на более низком уровне. Последнее называется «анализ покрытия требований».

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

На данном этапе становится очевидно, что управлять требованиями в полном объеме очень трудно без специализированных средств. Здесь нам на помощь приходят системы управления требованиями, такие как: IBM Rational RequisitePro, IBM Rational Composer, IBM Telelogic Doors, или IBM Telelogic Focal Point.


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

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

Во-первых, требования служат первичным входом для разработки ПО. Поэтому архитекторы ПО должны быть уверены (должны проследить), что все требования реализованы в дизайне проекта. А разработчики должны понять, как требования соотносятся с кодом в ПО.

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

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

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

Безусловно, такая плотная интеграция нужна в больших проектах и требует немалых затрат на закупку специальных средств по разработке ПО на всех ее стадиях. И, безусловно, пальму первенства в инструментарии полного жизненного цикла ПО (Application Lifecircle Management – ALM) держат линейки IBM Rational и IBM Telelogic.


Преимущества качественного процесса управления требованиями

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

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

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


Литература

  1. Карл И. Вигерс. Разработка требований к программному обеспечению. – Русская редакция, 2004. – ISBN 5-7502-0240-2.
  2. Дин Леффингуэлл, Дон Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. – Вильямс, 2002. – ISBN: 5-8459-0275-4.
  3. Jim Heumann. The Five Levels of Requirements Management Maturity. – Rational Edge, 2003.
  4. John Simpson. What’s the value of requirements management in a down economy?». – 2008.
  5. Jama Software. The five reasons why requirements managers deserve a promotion. – 2008.
  6. Jama Software. Requirements management redefined. – 2007.
  7. Jama Software. The state of requirements management report. – 2008.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=455313
ArticleTitle=Пять уровней зрелости требований
publish-date=12102009