Введение в управление требованиями.


Пройдя этапы выявления, всестороннего анализа, формализации, спецификации, проверки, требования к АИС приобретают статус документа. Стороны ставят на документе свои подписи, тем самым, удостоверяя, что именно этот (представленный в SRS) набор требований представляет свод законов, по которому создается система. Затем осуществляется проектирование и реализация системы. Готовая АИС передается Заказчику, который, совместно с Разработчиком осуществляет ее приемку и ввод в эксплуатацию. Такая схема была заложена в подходе, который известен в литературе, как "каскадный" или "водопадный"1) (см. рис. 13.1). В этой схеме нет места управлению требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во времени.


Рис. 13.1.

Каскадный подход представлял собой одну из первых систематизаций потоков работ программной инженерии и на момент своего появления представлял безусловную ценность. Однако практика выполнения проектов автоматизации в рамках данного подхода показала низкий (порядка 20%) процент успешных проектов. Первая причина - лавинообразное разрастание цены исправления ошибок, возникших на ранних этапах создания системы от этапа к этапу (схема не имела обратных связей и, соответственно, ошибки копились вплоть до этапа внедрения). Вторая - статичность схемы. Крупный проект автоматизации может длиться 2, 3 года, а требования, замороженные в SRS, перестают соответствовать бизнес-реалиям предприятия внедрения, которое за столь долгий период может существенно измениться.

Подавляющее большинство современных методологий управления проектами разработки программного обеспечения2) при всем своем разнообразии сходятся в одном: требования могут меняться! Причем практически на любой фазе производства АИС. Эта новая парадигма работы с требованиями, безусловно, импонирует Заказчикам. Теперь они имеют право ошибиться и исправить свою ошибку. Они могут дать волю своему креативу и постоянно изобретать новые возможности и формы реализации продукта. Но каково Разработчику? Если "двусмысленность - страшилка любой спецификации требований3)", то неконтролируемое изменение и разрастание требований - ходячий кошмар Разработчика. Вопрос контроля процесса изменений требований и его влияния на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. Подробно ознакомиться со всеми этапами, артефактами, приемами и методами данной дисциплины можно, изучив третью главу монографии [13.1], краткое изложение которой легло в основу этой лекции.

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

Согласно [13.1], к действиям по управлению требованиями относятся:

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


Дата добавления: 2020-11-18; просмотров: 401;


Поиск по сайту:

Воспользовавшись поиском можно найти нужную информацию на сайте.

Поделитесь с друзьями:

Считаете данную информацию полезной, тогда расскажите друзьям в соц. сетях.
Poznayka.org - Познайка.Орг - 2016-2024 год. Материал предоставляется для ознакомительных и учебных целей.
Генерация страницы за: 0.008 сек.