Опубликован: 18.06.2007 | Уровень: специалист | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 13:

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

< Лекция 12 || Лекция 13: 123 || Лекция 14 >
Аннотация: Вопрос контроля процесса изменений требований и его влияние на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. В этой лекции можно ознакомиться с этапами, артефактами, приемами и методами данной дисциплины

Пройдя этапы выявления, всестороннего анализа, формализации, спецификации, проверки, требования к АИС приобретают статус документа. Стороны ставят на документе свои подписи, тем самым, удостоверяя, что именно этот (представленный в SRS) набор требований представляет свод законов, по которому создается система. Затем осуществляется проектирование и реализация системы. Готовая АИС передается Заказчику, который, совместно с Разработчиком осуществляет ее приемку и ввод в эксплуатацию. Такая схема была заложена в подходе, который известен в литературе, как "каскадный" или "водопадный" 1Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9 (см. рис. 13.1). В этой схеме нет места управлению требованиями, т.к. они статичны, сформулированы в начале проекта и неизменны во времени.


Рис. 13.1.

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

Подавляющее большинство современных методологий управления проектами разработки программного обеспечения 2Исключение составляют, например, некоторые классы военных разработок, где до сих пор применяются модификации каскадного подхода, базирующиеся на очень тщательной проработке и верификации спецификаций и гарантирующие точное соответствие продукта спецификациям. при всем своем разнообразии сходятся в одном: требования могут меняться! Причем практически на любой фазе производства АИС. Эта новая парадигма работы с требованиями, безусловно, импонирует Заказчикам. Теперь они имеют право ошибиться и исправить свою ошибку. Они могут дать волю своему креативу и постоянно изобретать новые возможности и формы реализации продукта. Но каково Разработчику? Если "двусмысленность - страшилка любой спецификации требований 3Lawrence, Brian. 1996. Unresolved Ambiguity. American Programmer 9(5}:17-22 ", то неконтролируемое изменение и разрастание требований - ходячий кошмар Разработчика. Вопрос контроля процесса изменений требований и его влияния на другие рабочие потоки программной индустрии настолько серьезен, что породил отдельную инженерную дисциплину - управление требованиями. Подробно ознакомиться со всеми этапами, артефактами, приемами и методами данной дисциплины можно, изучив третью главу монографии [13.1], краткое изложение которой легло в основу этой лекции.

Согласно RUP 4http://www-306.ibm.com/software/rational/ , управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе. Данное соглашение, как и тексты исходных требований, подлежит документальному оформлению.

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

  • определение основной версии требований (моментальный срез требований для конкретной версии продукта);
  • просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
  • включение одобренных изменений требований в проект установленным способом;
  • согласование плана проекта с требованиями;
  • обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
  • отслеживание отдельных требований до проектирования, исходного кода и вариантов тестирования;
  • отслеживание статуса требований и действий по изменению на протяжении всего проекта.
< Лекция 12 || Лекция 13: 123 || Лекция 14 >
Александр Медов
Александр Медов

Здравствуйте, прошел весь курс,хотел заказать версию для печати но она не кликается,когда исправяте данную опцию?

Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Евгений Динер
Евгений Динер
Россия, Уральская государственная юридическая академия, 2009