
- •Управление качеством требований. Начало
- •Введение
- •Часть 1. Требования
- •Определение требований
- •Классификация требований
- •Бизнес-требования
- •Ключевые возможности
- •Пользовательские требования
- •Функциональные требования
- •Характеристики качества
- •Ограничения
- •Иерархия требований
- •Стоимость ошибок в требованиях
- •Выводы к первой части
- •Литература
- •Часть 2. Управление требованиями
- •Управление требованиями
- •Бизнес-аналитик
- •Бизнес-архитектор
- •Аналитик требований
- •Спецификатор требований
- •Системный архитектор
- •Технический писатель
- •Коммуникатор
- •Основные шаги процесса
- •Планирование процесса
- •Выявление требований
- •Методы выявления требований
- •Интервью
- •Семинары требований
- •Мозговой штурм
- •Фокус-группа
- •Прототипирование
- •Варианты использования
- •Проблемы, возникающие при выявлении требований Проблемы классификации требований
- •Проблемы формулировки требований
- •Терминология
- •Предвзятые решения
- •Анализ требований
- •Уточнение требований
- •Структуризация требований
- •Приоритеты
- •Модели требований
- •Документирование требований
- •Глоссарий
- •Документ – концепция
- •Спецификация требований
- •Проверка требований
- •Управление изменениями требований
- •Выводы ко второй части.
- •Литература
- •Часть 3. Качество требований
- •Качество требований Управление качеством
- •Iso 9001:2000
- •Модель зрелости cmmi Обзор cmmi
- •Внутренняя структура описания уровней зрелости
- •Уровни зрелости
- •Группы ключевых процессов
- •Разделы
- •Ключевые практики
- •Отображение процесса управления требованиями на модель cmmi
- •Критерии качества требований
- •Правильные требования
- •Однозначные требования
- •Полные требования
- •Непротиворечивые требования
- •Ранжированные требования
- •Проверяемые требования
- •Прослеживаемые требования
- •Модифицируемые требования
- •Понимаемые требования
- •Выводы к третьей части
- •Литература
- •Часть 4 Управление качеством требований
- •Уровни зрелости требований Уровень 0 – Отсутствие требований
- •Уровень 1 – Документирование требований
- •Выявление требований
- •Интервью
- •Анализ документации
- •Документирование требований
- •Проверка требований
- •Экспертная оценка
- •Согласование документов
- •Уровень 2 – Организация требований
- •Выявление требований
- •Мозговой штурм
- •Анализ требований Уточнение требований
- •Документирование требований
- •Проверка требований Коллективная проверка
- •Документ замечаний
- •Управление изменениями требований База данных требований
- •Управление версиями
- •Уровень 3 – Структурирование требований
- •Планирование процесса План управления требованиями
- •Типы требований
- •Атрибуты требований
- •Выявление требований
- •Варианты использования
- •Прототипы
- •Анализ требований
- •Структуризация требований
- •Определение значений атрибутов
- •Документирование требований Шаблоны требований
- •Модели требований
- •Проверка требований
- •Контрольные листы
- •Рекомендация
- •Уровень 4 – Трассировка требований
- •Выявление требований
- •Анализ требований Иерархия типов требований
- •Отношения между требованиями
- •Трассировка требований
- •Анализ влияния
- •Анализ сферы деятельности
- •Документирование требований Типовые решения требований
- •Уровень 5 – Комплексность требований
- •Анализ требований Трассировка на элементы проектирования и тестирования
- •Показатели требований
- •Количественная оценка требований
- •Документирование требований
- •Заключение
- •Литература
Выводы к третьей части
Понятия качества продукта и требований к разработке продукта являются плотно связанными друг с другом. Именно то, насколько разработанный продукт соответствует требованиям заказчика, и определяет качество продукта. Как в таком случае быть уверенным, что требования, по которым будет реализовываться программный продукт, обладают приемлемым уровнем качества? Для получения «хороших» требований была произведена попытка применения к управлению требованиями система менеджмента качества. В данном случае, продуктом производства являются требования, обладающие следующими критериями качества:
корректность в описании,
понятность всем заинтересованным лицам,
полнота изложения,
однозначность понимания,
модифицируемость в случае изменения,
прослеживаемость отношения между требованиями,
возможность проверки с помощью тестирования,
ранжируемость по важности,
непротиворечивость в отношении к другим требованиям.
Для возможности поэтапного внедрения процесса управления качеством требований в проект или в компанию, используется процессная модель на основе уровней зрелости CMMI. Такой подход позволит постепенно совершенствовать процесс управление требованиями и получать в итоге более качественные требования. Следующая часть будет описывать создаваемый процесс, разделенный по уровням зрелости. Каждый уровень содержит в себе часть шагов процесса управления требования, необходимые артефакты, рекомендации и советы.
Литература
[1] Д. Леффингуэлл, Д. Уидриг, Принципы работы с требованиями к программному обеспечению. Унифицированный подход, Вильямс, 2002 [2] IIBA, A guide to the Business Analysis Body of Knowledge, v1.6, 2006 [3] IBM, Rational Unified Process v. 2003 [4] IEEE 830-1998 [5] Карл И. Вигерс. Разработка требований к программному обеспечению, Русская Редакция, 2004 [6] ISO 8402 Словарь терминов
Часть 4 Управление качеством требований
За основу процесса управления качества требованиями к программному обеспечению взята работа Джима Хеймана [1], которая была немного расширена собственным мнением автора.
В основе данной модели лежат шесть уровней зрелости процесса управления качеством требований. Каждый последующий уровень полностью включает в себя предшествующий, что способствует непрерывному совершенствованию процесса. Уровни зрелости процесса управления качеством требований представлены на рисунке 1.
Рисунок 1. Уровни зрелости процесса управления качеством требований
Процесс управления качеством на основе уровней зрелости позволит командам – разработчикам совершенствовать свой процесс работы с требованиями поэтапно, улучшая его на каждом последующем этапе. В соответствии с концепцией постоянного улучшения качества, изображенной на рисунке 2, после перехода на следующий этап команда должна закрепить на практике все соответствующие процессу действия.
Рисунок 2. Концепция непрерывного улучшения по Дж. Джурану.
Не рекомендуется сразу же переходить на следующий этап, так как множество незакрепленных и не изученных действий могут лишь запутать команду и усложнить процесс.