Введение в управление требованиями
Вопрос контроля процесса изменений требований и его влияние на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. В этой лекции можно ознакомиться с этапами, артефактами, приемами и методами данной дисциплины
Пройдя этапы выявления, всестороннего анализа, формализации, спецификации, проверки, требования к АИС приобретают статус документа. Стороны ставят на документе свои подписи, тем самым, удостоверяя, что именно этот (представленный в SRS) набор требований представляет свод законов, по которому создается система. Затем осуществляется проектирование и реализация системы. Готовая АИС передается Заказчику, который, совместно с Разработчиком осуществляет ее приемку и ввод в эксплуатацию. Такая схема была заложена в подходе, который известен в литературе, как "каскадный" или "водопадный" 1)(см.рис. 13.1). В этой схеме нет места управлению требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во времени.
Рис. 13.1.
Каскадный подход представлял собой одну из первых систематизаций потоков работ программной инженерии и на момент своего появления представлял безусловную ценность. Однако практика выполнения проектов автоматизации в рамках данного подхода показала низкий (порядка 20%) процент успешных проектов. Первая причина - лавинообразное разрастание цены исправления ошибок, возникших на ранних этапах создания системы от этапа к этапу (схема не имела обратных связей и, соответственно, ошибки копились вплоть до этапа внедрения). Вторая - статичность схемы. Крупный проект автоматизации может длиться 2, 3 года, а требования, замороженные в SRS, перестают соответствовать бизнес-реалиям предприятия внедрения, которое за столь долгий период может существенно измениться.
Подавляющее большинство современных методологий управления проектами разработки программного обеспечения 2)при всем своем разнообразии сходятся в одном: требования могут меняться! Причем практически на любой фазе производства АИС. Эта новая парадигма работы с требованиями, безусловно, импонирует Заказчикам. Теперь они имеют право ошибиться и исправить свою ошибку. Они могут дать волю своему креативу и постоянно изобретать новые возможности и формы реализации продукта. Но каково Разработчику? Если "двусмысленность - страшилка любой спецификации требований3)", то неконтролируемое изменение и разрастание требований - ходячий кошмар Разработчика. Вопрос контроля процесса изменений требований и его влияния на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. Подробно ознакомиться со всеми этапами, артефактами, приемами и методами данной дисциплины можно, изучив третью главу монографии[13.1], краткое изложение которой легло в основу этой лекции.
Согласно RUP 4), управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе. Данное соглашение, как и тексты исходных требований, подлежит документальному оформлению.
Согласно [13.1], к действиям по управлению требованиями относятся:
определение основной версии требований (моментальный срез требований для конкретной версии продукта);
просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
включение одобренных изменений требований в проект установленным способом;
согласование плана проекта с требованиями;
обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
отслеживание отдельных требований до проектирования, исходного кода и вариантов тестирования;
отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Принципы и приемы управления требованиями Базовая версия требований
Чтобы договориться об изменении требований, сначала нужно их зафиксировать в "первозданном виде".
Базовая версия (baseline) - это набор функциональных и нефункциональных требований, которые разработчики обязались реализовать в определенной версии (итерации).
Управление требованиями - это рабочий процесс, следовательно, он должен подчиняться определенным правилам и процедурам.
Процедуры управления требованиями
Процедуры управления требованиями базируются на:
инструментах, приемах и соглашениях по управлению версиями различных документов требований и отдельных требований;:
правилах составления базовой версии требований;
статусах требований, которые будут использоваться, и категориях лиц, которые имеют право изменять их;
способах, с помощью которых новые требования и изменения существующих требований предлагаются, обрабатываются, обсуждаются и передаются всем заинтересованным лицам;
методах анализа влияния предложенного изменения;
отслеживании связей планов и обязательств проекта с изменением требований.
Контроль версий
Каждая версия документа требований должна содержать историю переработки, где указываются внесенные изменения, дата каждого из них, лицо, внесшее изменение, а также причина. Целесообразно добавлять номер версии к названию каждого отдельного требования, который можно последовательно увеличивать при модификации требований.
Для документирования версий используются текстовые процессоры, электронные таблицы. Существуют специализированные средства для контроля версий и конфигураций 5)
Атрибуты требований
С позиций управления, каждое из требований представляет собой самостоятельный объект. Изменения осуществляются в описательной части данного объекта. Контроль изменений удобнее осуществлять с помощью атрибутов требований. Набор атрибутов подбирается для каждого проекта индивидуально, исходя из максимальной результативности для команды проекта. При первом внедрении средств управления изменениями рекомендуется использовать не более пяти атрибутов. Это количество можно будет расширить впоследствии, когда команда "войдет во вкус" процесса управления изменениями и в том случае, если добавление новых атрибутов оправдано практическими соображениями.
В качестве шаблона описания атрибутов требований К.Вигерс [13.1]предлагает следующий набор:
дата создания требования;
номер его текущей версии;
автор требования;
лицо, ответственное за удовлетворение требования;
ответственный за требование или список заинтересованных лиц (чтобы принимать решения о предложенных изменениях);
состояние требования;
происхождение или источник требования;
логическое обоснование требования;
подсистема (или подсистемы), для которых предназначено требование;
номер версии продукта, для которого предназначено требование;
используемый метод проверки или критерий тестирования приемлемости;
приоритет реализации;
стабильность требования
Контроль статуса требований
В автоматизированных средствах управления проектами, например MS Project, для контроля степени выполнения той или иной работы используется понятие степени выполнения (progress), выражаемой в процентах. Данный способ слабо применим в программистских разработках, где, в силу их слабой формализованности, трудно оценить работу в процентах. При управлении требованиями рекомендуется оперировать не процентом, а статусом. К.Вигерс предлагает следующий шаблон для определения статуса требования:
|
Таблица 13.1. | |
|
Состояние |
Определение |
|
Proposed (Предложено) |
Требование запрошено авторизированным источником |
|
Approved (Одобрено) |
Требование проанализировано, его влияние на проект просчитано, и оно было размещено в базовой версии определенной версии. Ключевые заинтересованные в проекте лица согласились с этим требованием, а разработчики ПО обязались реализовать его |
|
Implemented (Реализовано) |
Код, реализующий требование, разработан, написан и протестирован. Требование отслежено до соответствующих элементов дизайна и кода |
|
Verified (Проверено) |
Корректное функционирование реализованного требования подтверждено в соответствующем продукте. Требование отслежено до соответствующих вариантов тестирования. Теперь требование считается завершенным |
|
Deleted (Удалено) |
Утвержденное требование удалено из базовой версии. Опишите причины удаления и назовите того, кто принял это решение |
|
Rejected (Отклонено) |
Требование предложено, но не запланировано для реализации ни в одной будущих версий. Опишите причины отклонения требования и назовите того, кто принял это решение |