Совершенствование процессов работы с требованиями
Парадигма управления качеством, как способ организации производства, появилась давно. Идеи, заложенные в группе стандартов ISO90001), уходят корнями, в частности, и в такие "советские" изобретения, как поддержка рационализаторских предложений, наставничества и др.
В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций.
Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.
Модели совершенствования
ISO9000
Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) [14.1]. Подъем экономики послевоенной Японии во многом был обусловлен идеям, заложенным в TQM.
Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. [14.1].
Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать.
Основные принципы ISO9000:
- Концентрация на потребностях заказчика;
- Активная лидирующая роль руководства;
- Вовлечение исполнителей в процессы совершенствования;
- Реализация процессного подхода;
- Системный подход к управлению;
- Обеспечение непрерывных улучшений;
- Принятие решений на основе фактов;
- Взаимовыгодные отношения с поставщиками.
Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже.
SEI-CMM, SEI-CMMI
Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.
Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в [14.2-14.3]). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.
В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем [14.3].
CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) соответствует структуре SW-CMM с небольшими уточнениями наименований уровней. Пять уровней зрелости содержат 22 области технологических процессов, показанных в таблице 14.1. (CMU/SEI, 2000а). Непрерывное представление (continuous representation), содержит другой взгляд: те же 22 области структурируются по 4 категориям: управление процессами, управление проектами, конструирование и поддержка (CMU/SEI, 2000b).
В непрерывном представлении вместо уровней зрелости определяются шесть уровней способностей (capability levels) для каждой области технологических процессов. Это представление позволяет каждой организации решать, какой уровень способностей ей соответствует в каждой из 22 областей технологических процессов.
Как и в CMM, в рассматриваемом стандарте на уровне 2 имеется область, именуемая "Управление требованиями", но, в отличие от предыдущего стандарта, на уровне 3 есть и отдельная область "Разработка требований". Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований [14.3].
Таблица 14.1. | ||
Уровень зрелости | Название | Области процессов |
Начальный | (нет) | |
Управляемый | Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией | |
Определенный | Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов | |
Количественно управляемый | Производительность организационных процессов Количественное управление проектом | |
Оптимизирующий | Организационные нововведения и их развертывание Случайный анализ и разрешение |
Область процессов "Управление требованиями"
Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:
- обеспечение записи источников низкоуровневых или вторичных требований;
- трассирование каждого требования вниз, к вторичным требованиям, и его размещение по функциям, объектам, процессам и исполнителям;
- установка горизонтальных связей между требованиями, принадлежащими к одному типу.
Область процессов "Разработка требований"
В CMMI-SE/SW описаны три набора приемов разработки требований:
- приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц; преобразовать нужды и ограничения в требования клиентов);
- приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу);
- приемы получения вторичных требований, понимания требований и их подтверждения (установить оперативные концепции и сценарии; определить требуемую функциональность системы; проанализировать вторичные требования; оценить стоимость, сроки и риск создания продукта; утвердить требования).
Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по разработке ПО должны стремиться в различных областях процессов. В них также рекомендуются технические приемы, помогающие достичь этих целей.
CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).
Рис. 14.1.
Дата добавления: 2020-11-18; просмотров: 438;