В статье рассматривается специфика процесса управлениями требованиями проекта в зависимости от специфики предметной области: от наиболее формализованной (ИТ-проекты) до наименее формализованной (дизайн-проекты). Далее показано, что весь спектр приложений, которые касаются этой темы, можно рассматривать с единых позиций — как установление эффективного канала коммуникаций между заказчиком и бизнес-аналитиком (дизайнером). Рассмотрены особенности коммуникаций для вышеуказанных предметных областей и проблемы, связанные с созданием такого канала.
управление проектом, управление требованиями, коммуникации, эффективность коммуникаций.
Введение
Управление требованиями проекта как самостоятельная дисциплина развивается в рамках IT-проектов. Пока она находится на уровне корпоративной методологии. Например, в методологии RUP (Rational Unifed Process) управление требованиями является одним из этапов выполнения проектов [6]. Здесь дается следующее определение: «Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе». Как само соглашение, так и исходные требования подлежит документальному оформлению. В настоящее время имеются программные продукты, которые поддерживают базу данных с требованиями и отслеживают сквозное их выполнение при разработке модулей. Также имеются принятые стандарты для формализации требований, например спецификация требований по стандарту IEEE 830-1998 [14]. Для управления требованиями разработаны формализованные языки, например, сценарии использования в UML 2.0 [2]. Но в стандартах по управлению проектами, таких как PMBOK, IPMA, управление требованиями не выделяется в самостоятельный раздел стандарта [9; 11]. Известны попытки ряда авторов создать методику для выявления и анализа требований [12].
Рассмотрим более подробно особенности процесса управления требованиями. В сравнении с другими этапами разработки системы установление требований в наименьшей степени касается технических сторон проекта. В действительности речь идет об успешном решении социальных, коммуникативных и управленческих вопросов. Недостаточно тщательное выполнение этого этапа может привести к более серьезным последствиям, чем в случае с другими стадиями проекта. В лучшем случае это приведет к лавинообразному росту расходов, вызванных не зафиксированными, упущенными или неверно понятыми требованиями заказчиков. В худшем случае — это вообще невозможность завершения проекта.
Специфика предметной области диктует специфику методик управления. Прежде всего это касается стратегии выполнения проекта, которая будет зависеть от того, насколько тщательно выявлены требования и предпочтения заказчика. Чаще всего необходима итерационная стратегия, связанная с последовательным выполнением одного или нескольких этапов. Причем сам руководитель проекта не всегда может гарантировать заранее, что все требования заказчика будут выполнены. Целью настоящей статьи является изучение специфики процесса управления требованиями для ряда предметных областей, выработка единой точки зрения на процесс управления требованиями и доказательство того, что предложенная точка зрения не противоречит существующим профессиональным стандартам.
1. Атабекова А.А. Лингвистический дизайн WEB-страниц: проблемы «коммуникативных неудач» // Материалы международной научно-практической конференции «Коммуникация: теория и практика в различных социальных контекстах» - «Коммуникация-2002» («Communication Across Differences»). Ч. 1. Пятигорск: Изд-во ПГЛУ, 2002. С. 148-153.
2. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя. 2-е изд. ДМК Пресс, 2007.
3. Вигерс К. Разработка требований к программному обеспечению / Перев. с англ. М.: Русская редакция, 2004.
4. ГОСТ Р 52807-2007 Руководство по оценке компетентности менеджеров проектов. НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. Дата введения 2010-01-01.
5. Конецкая В.П. Социология коммуникации. М., 1997.
6. Кролл П., Крачтен Ф. Rational Unified Process - это легко. Руководство по RUP для практиков. Кудиц, 2004.
7. О´Коннор Дж., Сеймор Д. Введение в нейролингвистическое программирование : Новейшая психология личного мастерства / Предисл. Р. Дилтца, Дж. Гриндер; Перев. с англ. А.Б. Бродского. Челябинск: Версия, 1997.
8. Разработка сайта: дизайн, управление и прочие важные моменты // Web-студия Мистери-групп. URL: http://mysterygroup.ru/articles/create_sites/2217/
9. Руководство к Своду знаний по управлению проектами (Руководство PMBOK®). 4-е изд. М., 2010.
10. Скибкин Ю.В. Введение в эргономику: Методические указания к изучению дисциплины для студентов специальности «Информационные системы и технологии» очной и заочной форм обучения. Самара: СамГАПС, 2004.
11. Управление Проектами. Основы Профессиональных Знаний. Национальные Требования к Компетентности (НТК) специалистов / Сертификационная комиссияСОВНЕТ. М.: КУБС, 2001.
12. Халл Э., Джексон К., Дик Дж. Разработка и управление требованиями. Практическое руководство пользователя. 2-е изд. М.: Telelogic.
13. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide).Version 2.0 / International Institute of Business Analysis. Toronto, Ontario, Canada, 2009.
14. IEEE Recommended Practice for Software Requirements Specifications/ Software Engineering Standards Committee of the IEEE Computer Society. Approved 25 June 1998 IEEE-SA Standards Board.
15. IEEE Standard Glossary of Software Engineering Terminology / Software Engineering Standards Committee of the IEEE Computer Society. 610.12. 1990.
