Модели зрелости процессов: ISO 9000 и CMMI
Коротко Модели зрелости описывают, как способ работы организации развивается от импровизации к измеряемому и непрерывно совершенствуемому. ISO 9000 предлагает общие принципы менеджмента качества; CMM и CMMI дают организациям, которые разрабатывают ПО и системы, поэтапный путь, и управление требованиями в нём — одна из первых практик, которые нужно наладить.
По материалам: Ю. А. Маглинец, «Анализ требований к информационным системам», лекция 8; К. Вигерс, «Разработка требований к программному обеспечению», 2-е изд., прил. B.
На этой странице
Главные идеи#
ISO 9000#
Семейство стандартов ISO 9000 выросло из идей непрерывного совершенствования процессов и всеобщего управления качеством (Total Quality Management, TQM); этим идеям часто приписывают заметную роль в послевоенном промышленном подъёме Японии. Принципы менеджмента качества, на которых построен ISO 9001:2000: ориентация на потребителя, лидерство руководства, вовлечение персонала, процессный подход, системный подход к менеджменту, постоянное улучшение, принятие решений на основе фактов и взаимовыгодные отношения с поставщиками.
Маглинец отмечает сильную сторону стандарта (он проверен во множестве организаций по всему миру) и слабую (рекомендации носят общий характер и не учитывают специфику ИТ). Среди моделей, созданных именно для ИТ, — SEI CMM и CMMI, ISO/IEC 15504 (SPICE), Bootstrap и TickIT.
CMM: пять уровней зрелости#
Модель зрелости возможностей (Capability Maturity Model, CMM) Института программной инженерии (SEI) при Университете Карнеги — Меллона оценивает организацию-разработчика ПО по пяти уровням: начальный, повторяемый, определённый, управляемый и оптимизирующий. Начиная со второго уровня каждый уровень определяется ключевыми областями процессов.
В исходной модели для ПО (SW-CMM), как её описывает Вигерс, управление требованиями находится на уровне 2 вместе с планированием проекта, отслеживанием проекта, управлением субподрядами, обеспечением качества и управлением конфигурацией. Отдельной области для разработки требований нет; эта работа частично входит в конструирование программного продукта на уровне 3.
CMMI#
CMMI для системной и программной инженерии (CMMI-SE/SW, 2000) объединяет более ранние модели и имеет два представления: - Ступенчатое (staged): пять уровней зрелости и 22 области процессов. Уровень 2 (управляемый) включает управление требованиями, планирование проекта, мониторинг и контроль проекта, управление соглашениями с поставщиками, измерения и анализ, обеспечение качества и управление конфигурацией. Уровень 3 (определённый) добавляет, среди прочего, разработку требований, техническое решение, интеграцию продукта, верификацию, валидацию и управление рисками. Уровни 4 (количественно управляемый) и 5 (оптимизирующий) добавляют количественный контроль и непрерывные инновации. - Непрерывное (continuous): те же области процессов, сгруппированные в четыре категории (управление процессами, управление проектами, инженерия, поддержка); каждая область оценивается по собственному уровню возможностей. Организация может независимо решать, насколько развивать каждую область.
Почему управление требованиями идёт первым#
Управление требованиями стоит на уровне 2, потому что делает проекты предсказуемыми: согласованные базовые версии, контролируемые изменения и трассировка. В CMMI трассировка явно включает запись происхождения каждого требования, прослеживание его вниз до рабочих продуктов, которые его реализуют, и связи между родственными требованиями. Только на уровне 3 модель требует более качественной разработки требований: выводить требования клиента из потребностей заинтересованных сторон, распределять требования к продукту по компонентам и интерфейсам и валидировать производные требования.
Это не значит, что до уровня 2 требования можно не собирать. Это значит, что контроль над ними — первый шаг к предсказуемой поставке, а улучшение того, как вы их разрабатываете, — следующий.
Как совершенствоваться: цикл по Вигерсу#
Вигерс, в пересказе Маглинца, советует совершенствоваться постепенно, непрерывно и циклически, отталкиваясь от реальных проблем, ориентируясь на ясные цели и оформляя работу как проект. Типовой цикл: 1. Оцените текущую практику с помощью интервью, семинаров и модели «как есть». Внешние консультанты помогают сохранить беспристрастность оценки. 2. Спланируйте: стратегический план плюс короткие планы действий не более чем из десяти пунктов, каждый из которых завершается за два-три месяца. 3. Создайте и опробуйте новые процессы: эволюция, а не революция. Опробуйте их на реальных проектах с участниками, открытыми к новому. 4. Оцените и примите решение: сделайте поправку на кривую обучения. Пока люди осваивают новый способ работы, производительность обычно сначала падает и только потом растёт.
Как применять#
- Используйте уровни зрелости для диагностики, а не как знак отличия. Спросите себя, отсутствие каких практик делает ваши проекты непредсказуемыми.
- Если изменения требований постоянно срывают проекты, начните с основ уровня 2: базовые версии, процесс изменений и трассировка.
- Если проекты предсказуемы, но требования слабые, вкладывайтесь в практики уровня 3: структурированное выявление, моделирование и валидацию.
- Делайте каждое действие по улучшению небольшим и ограниченным по времени и опробуйте его на одном проекте.
- Предупредите спонсоров о спаде на кривой обучения до того, как он наступит.
Пример#
Внешняя команда разработки, которая работает на «Мастерскую», вымышленную сеть веломастерских, постоянно срывает сроки релизов, потому что требования меняются по телефону и электронной почте. Быстрая оценка по практикам уровня 2 показывает: нет ни базовой версии, ни журнала изменений. План действий на следующий квартал состоит из трёх пунктов: согласовывать базовую версию требований для каждого релиза, проводить каждое изменение через единый журнал изменений, который еженедельно разбирают с владельцем, и связывать каждое изменение с затронутыми пользовательскими историями. Улучшение выявления откладывается до следующего цикла.
Подводные камни#
- Гонятся за сертификатом → решайте проблемы, которые мешают поставке.
- Меняют всё сразу → держите планы действий короткими и ограниченными по времени.
- Путают шкалы → CMMI оценивает организации, которые разрабатывают ПО и системы; шкала BPM CBOK оценивает управление процессами в масштабе предприятия.
Источники и что почитать#
- Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 8 «Совершенствование процессов работы с требованиями» (ISO 9000, SEI CMM/CMMI, цикл совершенствования по Вигерсу).
- K. Wiegers. Software Requirements, 2nd ed. Microsoft Press, 2003. Рус. изд.: К. Вигерс. Разработка требований к программному обеспечению, 2-е изд. М.: Русская редакция, 2004. Прил. B «Модели совершенствования требований и технологических процессов» (SW-CMM и CMMI-SE/SW).
- ISO 9001:2000; SEI CMM и CMMI-SE/SW — в изложении двух работ выше.