Апр
15

Рубрика: Качество требований, Статья

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

Управление качеством требований

За основу процесса управления качества требованиями к программному обеспечению взята работа Джима Хеймана [1], которая была немного расширена собственным мнением автора.

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

Рисунок 1. Уровни зрелости процесса управления качеством требований

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

Рисунок 2. Концепция непрерывного улучшения по Дж. Джурану.

Уровни зрелости требований

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

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

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

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

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

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

Выявление требований

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

Интервью

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

Анализ документации

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

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

Документирование требований

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

Проверка требований

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

Экспертная оценка

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

Рисунок 3. Скорость проведения экспертной оценки

Правила проведения экспертизы:

• 1-2 страницы в час считается оптимальной скоростью для наиболее эффективного обнаружения ошибок в спецификации
• 2-4 страницы в час являются практически рекомендуемыми.
• Корректируйте норму экспертизы, основываясь на:

1) объеме текста на каждой странице,

2) сложности спецификации,

3) рисках, связанных с пропуском ошибок,

4) критичности материалов экспертизы для успешного завершения проекта,

5) квалификации человека, написавшего спецификацию требований.

• Начинайте экспертизу, когда спецификация требований готова на 10-20%.

Согласование документов

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

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

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

Далее рассмотрим ключевые процессы для данного уровня зрелости и их состав.

Выявление требований

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

Анкеты

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

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

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

Мозговой штурм

Описание мозгового штурма приведено в статье, посвященной управлению требований

Анализ требований

Уточнение требований

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

Документирование требований

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

Проверка требований

Коллективная проверка

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

Документ замечаний

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

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

Управление изменениями требований

База данных требований

Требования могут храниться не только в текстовом документе. Альтернативой является размещение их в базе данных. Наличие базы данных с требованиями позволяет уникально идентифицировать каждое требования, определять права членов команды для доступа к требованиям, создавать любые запросы в базу данных, осуществляя сложные выборки требований по различным критериям. Все современные инструментальные средства для работы с требованиями позволяют хранить требования в реляционной базе данных. IBM Rational RequisitePro предоставляет пользователям возможность выбора источника требований, т.е. позволяет определять, где первоначально было создано требование, в документе или в базе данных. Еще одним преимуществом хранения требования в базе данных является создание из нее отчетов (спецификаций требований). В случае отсутствия специализированных средств, можно воспользоваться, например, базой данных Microsoft Access.

Управление версиями

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

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

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

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

Планирование процесса

План управления требованиями

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

Типы требований

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

Атрибуты требований

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

Выявление требований

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

Варианты использования

Подход на основе вариантов использования (Use Case Driven Approach) позволяет не только описывать пользовательские требования, он лежит в основе объектно-ориентированного подхода к разработке программного обеспечения. Это метод анализа и проектирования сложных систем, представляющий собой способ описания поведения системы с точки зрения того, как различные пользователи взаимодействуют с ней для достижения своих целей. Такой ориентированный на пользователя подход позволяет исследовать различные варианты поведения системы при привлечении пользователя на ранних этапах разработки.

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

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

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

Рисунок 4. Системная диаграмма для крупномасштабной системы

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

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

Рисунок 5. Пример диаграммы вариантов использования для подсистемы

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

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

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

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

Прототипы

Анализ требований

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

Структуризация требований

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

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

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

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

Определение значений атрибутов

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

Документирование требований

Шаблоны требований

Для того чтобы улучшить понимание требований, их классификацию и ускорить процесс документирования, в процессе текстового описания требований можно применять так называемые шаблоны требований [2]. Шаблоны требований позволяют по-разному описывать требования разного типа. В таблице 1 приведены шаблоны требований и их краткое описание.

Таблица 1 - Шаблоны требований

Тип требования

Шаблон

Описание

Пример

Пользовательское требование

<Тип пользователя> должен иметь возможность <описание возможности>

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

Клиент должен иметь возможность оплачивать услуги интернет магазина.

Пользовательское требование с ограничением

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

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

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

Ограничение (бизнес правило)

<Тип пользователя> не должен подпадать по действие <соответствующее законодательство>

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

Водитель скорой помощи не должен подпадать под действие законодательства, предусматривающего ответственность за нарушение правил дорожного движения.

Функциональное требование

<Система> должна <выполняемая функция> не менее чем <количество> <объект> функционируя в <условиях эксплуатации>

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

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

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

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

Таким образом, процесс создания требований с помощью шаблонов может быть разбит на два этапа:

• выбор наиболее подходящего шаблона из общего набора шаблонов;
• подстановка конкретных данных для заполнения пустующих полей в шаблоне.

Модели требований

Применение моделей при анализе и документировании требований позволяет решить проблемы понимания требований и дальнейшего моделирования и проектирования программной системы. При использовании моделей для анализа требований возможен плавный и последовательный переход к моделям проектирования. Данный процесс для объектно-ориентированных систем, разрабатываемых с использованием языков C# и Java, удобнее организовывать с использованием диаграмм в нотации UML.

Проверка требований

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

Контрольные листы

Контрольные листы (checklists) используются как технология контроля качества требований. Они представляет собой набор вопросов, которые аналитик или другой член команды, задает себе при проверке требований. Данные вопросы должны быть составлены таким образом, чтобы покрывать полностью проверяемую с их помощью задачу или артефакт. Большое количество готовых контрольных листов описано в [3, Глава 29], [4] и [5].

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

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

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

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

Выявление требований

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

Анализ требований

Иерархия типов требований

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

Отношения между требованиями

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

Трассировка требований

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

Анализ влияния

Анализ влияния, прежде всего, предназначены для того, чтобы управлять изменениями требований. Он ясно показывает, как изменение одного требования может воздействовать на другие. С помощью связей между требованиями аналитик принимает решения о том принять или отклонить изменения требований. Например, если кто-то желает изменить ключевую возможность, и связь влияния показывает, что такое изменение вызовет изменения в нескольких вариантах использования (повлияет на график проекта), необходимо взвесить все «за» и «против» изменения ключевой возможности и принять правильное решение. Анализ влияния легче всего осуществлять с помощью матрицы и дерева трассировок, которые показывают отношения между требованиями. На рисунках 6 и 7 приведены матрица трассировки и дерево трассировки, созданные в среде IBM Rational RequisitePro 7.

Рисунок 6. Матрица трассировки требований

Рисунок 7. Дерево трассировки требований

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

Анализ сферы деятельности

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

Документирование требований

Типовые решения требований

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

На сегодняшний день специалистами со всего мира описано большое количество типовых решений для применения в различных ситуациях [6], [7] и [8]. Наиболее популярными являются типовые решения для описания требований в виде вариантов использования [7].

Рассмотрим один из самых часто встречающихся типовых решений – CRUD. Типовое решение CRUD (Create, Read, Update, Delete) предназначается для описания ситуаций управления различной информацией. Под управлением информацией будем понимать ее запись в базу данных, обновление и чтение, а также удаление из базы данных. Управление информацией является пользовательским требованием, так как именно пользователь, например оператор, будет работать с информацией. На первый взгляд, кажется, что удобно было бы создать четыре отдельных варианта использования: «Записать информацию», «Обновить информацию», «Получить информацию» и «Удалить информацию». Однако каждый из приведенных выше вариантов использования, является атомарной операцией, выполняемой системой по действию пользователя. В случае большого количества разнородной информации, набор таких атомарных вариантов использования будет довольно большим, что приведет к усложнению модели и как следствие к невозможности ее структурирования и управления. Также, как показывает практика, все четыре приведенных варианта использования, должны реализовываться разработчиками одновременно, так как относятся к одной обрабатываемой информации. Именно для того чтобы упростить модель вариантов использования, сделать ее боле понятной и необходимо применение типового решения CRUD. В случае его применения, будет создан один вариант использования, например «Управление информацией». Различные же действия, для каждой конкретной операции (запись, чтение, удаление), можно оформить в виде отдельных сценариев одного варианта использования.

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

Уровень 5 – Комплексность требований

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

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

Анализ требований

Трассировка на элементы проектирования и тестирования

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

Системные архитекторы и проектировщики в данном процессе должны гарантировать, что все требования учтены при проектировании. Rational Unified Process[5] осуществляет данную задачу, рассматривая варианты использования как входной элемент для дисциплины анализа и проектирования. Установка связей между требованиями и элементами проектирования играет в данном случае ключевую роль. Трассировка подобного рода позволяет проследить реализацию функционала от бизнес требований до классов и программного кода.

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

В таких случаях к общим типам требований необходимо добавить такие типы требований, как сценарии тестирования, диаграммы классов и диаграммы взаимодействия [9] и установить их связь с требованиями более высокого порядка. Подобную задачу можно выполнять только с использованием специальных инструментальных средств. Для примера среда разработки и управления требованиями Rational RequisitePro интегрируется со средством проектирования Rational Software Architect, что позволяет отслеживать изменение требований на уровне проектирования.

Показатели требований

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

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

Количественная оценка требований

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

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

Количественная оценка вариантов использования была разработана Густавом Карнером (Gustav Karner) в 1993 году как способ измерения размера программного обеспечения по количеству, размеру и сложности вариантов использования, данного программного обеспечения.

На рисунке 8 изображен процесс вычисления оценки вариантов использования.

Рисунок 8. Количественная оценка вариантов использования.

Данный процесс начинается с определения весовых коэффициентов действующих лиц, инициирующих вариант использования. Весовой коэффициент зависит от типа действующего лица (Таблица 2). Далее рассчитывается общий вес действующих лиц по формуле UAW = 1*Q1+2*Q2+3*Q3, где Q1, Q2, Q3 – количество вариантов использования, инициируемых простым, средним и сложным типом действующих лиц, соответственно.

Таблица 2 - Весовые коэффициенты действующих лиц

Тип

Описание

Весовой коэффициент

Простой

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

1

Средний

Внешняя система, взаимодействующая через протоколы, такие как TCP/IP или пользователь, взаимодействующий через интерфейс на основе командной строки.

2

Сложный

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

3

Вторым шагом является определение весовых коэффициентов для вариантов использования. Оценка данных коэффициентов приведена в таблице 3. Под транзакциями понимается общее количество потоков событий (основных и альтернативных).

Таблица 3 - Весовые коэффициенты вариантов использования

Тип

Количество транзакций

Весовой коэффициент

Простой

1-3

5

Средний

4-7

10

Сложный

7 и более

15

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

Далее рассчитываем влияние внешней среды EF = 1,4 – 0.03*Efactor и технического фактора TCF = 0,6 + 0,01*Tfactor, соответственно.

В приведенных выше формулах Efactor и Tfactor являются коэффициентами, характеризующими влияние внешней среды и требований к характеристикам качества. Значения данных величин берется из специальной таблица и их можно найти в [10].

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

Трудозатраты = 28*UUCP * TCF * EF

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

Документирование требований

Интеграция с другими приложениями

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

Управление изменениями требований

Система управления изменениями

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

Выводы по четвертой части

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

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

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

Рисунок 9. Уровни зрелости и их состав

Заключение

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

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

Литература

[1] Jim Heumann, The Five Levels of Requirements Management Maturity, Rational Edge, Feb. 2003
[2] E. Hull, K. Jackson, D. Dick, Requirements Engineering, Springer Science, 2005.
[3] Д. Леффингуэлл, Д. Уидриг, Принципы работы с требованиями к программному обеспечению. Унифицированный подход, Вильямс, 2002
[4] D. Firesmith, «Quality Requirements Checklist», Journal of object technology. vol.4 № 9, pp. 31-38, , 2005
[5] IBM, Rational Unified Process v. 2003
[6] A. Cockburn, Patterns of Effective Use Cases
[7] G. Oveergard, Use Case Patterns and Blueprints, Addison Wesley Professional, 2004
[8] S. Withall, Software Requirements Patterns, Microsoft Press, 2007
[9] Zielczynski, Requirements management using IBM Rational RequisitePro, IBM Press, 2008
[10] Karl E. Wiegers, More About Software Requirements, Microsoft Press, 2006

Автор: Виталий Григораш