Документирование требований
Интеграция с другими приложениями
При интеграции с другими приложения, такими как 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