За последние 20 лет придумано множество методологий, стандартов, сводов знаний, фреймворков (framework) и практик в области разработки ПО, таких как RUP, MSF, Agile, ГОСТ, ISO, CMMI, SWEBOK, BABOK и т.д. Я уже не говорю про гору книг по данной тематике. Но все эти книги и методологии учат нас тому, как должно быть в идеале во всем процессе разработки ПО. В некоторых публикациях, правда, уделяется внимание именно процессу работы с требованиями (сбор, анализ, документирование, поверка и управление требованиями), но все равно они остаются слишком теоретизированными.
А что делать, если у вас процесс работы с требованиями не налажен, а хочется улучшить? Сразу же все не выкинешь и не начнешь жить по-новому! Поэтому и была написана данная статья, которая дает рекомендации по поэтапному внедрению "правильного" процесса управлениями требованиями.
Вероятность ошибки в процессе разработки ПО
По данным исследовательской организации Standish Group, наибольшее количество ошибок происходит на этапе сбора, анализа и документирования требований. Доля ошибок в различных артефактах при разработке ПО представлена на рисунке 1.
Рисунок 1. Доля ошибок в различных артефактах при разработке ПО
Вследствие ошибок на разных этапах разработки ПО приходится затрачивать 30-50% средств от общего бюджета проекта на их исправление. Причем 70-85% от общего числа исправлений связанно именно с ошибками, допущенными на этапе сбора, анализа и документирования требований.
Наибольшее количество ошибок в требованиях происходит из-за следующих факторов:
| Не выявлены требования | 12,8% |
|---|---|
| Не четко сформулированы требования | 12,3% |
| Изменения требований | 11,8% |
Резюмируя сказанное выше в данном разделе, можно сделать вывод, что ошибка, допущенная в самом начале проекта (на этапе сбора, анализа и документирования требований), обходится в 200 раз дороже при внедрении и сдаче ПО. Следовательно, руководители организаций должны очень тщательно относиться к одному из основополагающих процессов разработки ПО - сбору, анализу и документированию требований, усовершенствуя данный процесс внутри организации.
Пять уровней модели зрелости для управления требованиями
Чем выше сложность проекта, тем больше рисков при его разработке, и число рисков будет возрастать, если у вас не налажен процесс управления требованиями. Следующая диаграмма показывает соотношение числа рисков и сложности проекта с наложенными на них пятью уровнями модели зрелости для управления требованиями (рисунок 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 Requirements Composer, IBM Telelogic Doors, или IBM Telelogic Focal Point.
Уровень 5. Интеграция требований
Как мы уже говорили, требования служат неким соглашением между тем, что заказчик хочет и тем, что должно делать ПО. Но до этого момента мы не могли четко проследить связь от потребностей заказчика до кода в ПО. На пятом уровне мы должны интегрировать процесс управления требованиями с процессами управления изменениями, проектирования, разработки, тестирования и управления проектом.
Во-первых, требования служат первичным входом для разработки ПО. Поэтому архитекторы ПО должны быть уверены (должны проследить), что все требования реализованы в дизайне проекта. А разработчики должны понять, как требования соотносятся с кодом в ПО.
Интеграция требований в процесс управления изменениями даст уверенность, что требования не добавляются без тестирования и утверждения. И что любое изменение не будет добавлено в ПО, не пройдя стадию анализа.
Тестирование должно основываться на требованиях точно так же, как дизайн разрабатывается в соответствии с ними. Данный процесс даст уверенность, что ПО обеспечивает всю необходимую заказчику функциональность.
Менеджеры проекта должны планировать работу по разработке ПО, опираясь на требования, так как они являются основой процесса разработки ПО. Менеджеры проекта должны иметь прямой доступ к требованиям, чтобы управлять проектом и снимать метрики с требований: насколько качественные требования, как часто они меняются, в каком статусе находятся, какие есть риски по реализации данных требований и т.д.
Безусловно, такая плотная интеграция нужна в больших проектах и требует немалых затрат на закупку специальных средств по разработке ПО на всех ее стадиях. И, безусловно, пальму первенства в инструментарии полного жизненного цикла ПО (Application Lifecircle Management - ALM) держат линейки IBM Rational и IBM Telelogic.
Преимущества качественного процесса управления требованиями
Улучшение процесса сбора, анализа, документирования, проверки и управления требованиями дает следующие ощутимые преимущества:
- уменьшение ошибок и издержек при выпуске ПО;
- повышение удовлетворенности заказчика и качества ПО;
- уменьшение времени разработки ПО;
- ужесточение контроля над изменениями;
- повышение точности планирования;
- повышение точности стратегического развития комплекса ПО на предприятии;
- использование требований на разных стадиях разработки ПО;
- повышение производительности аналитиков и других членов команды;
- улучшение обмена информацией по проектам;
- повышение заинтересованности заказчика;
- вовлечение всей команды в разработку;
В зависимости от сложности проекта, квалификации команды и требуемого качества ПО нужно выбирать тот или иной уровень зрелости управления требованиями и постепенно к нему переходить.