CMMI
Модель Capability Maturity Model Integration (CMMI) была разработана в течение 1990-х годов в университете Карнеги-Меллона (Carnegie Mellon University.) совместно с Software Engineering Institute (SEI) и другими организациями. Одним из главных спонсоров разработки стало Министерство обороны США. CMMI была создана путем объединения (отсюда слово Integration в названии) трех более ранних специализированных моделей разработки: CMM for Software (SW-CMM), Electronic Industries Alliance Interim Standard (EIA/IS) 731 и Integrated Product Development Capability Maturity Model (IPD-CMM). Последняя версия спецификации CMMI 1.2 была опубликована в августе 2006 года.
Цель внедрения CMMI – построить инфраструктуру процессов, устанавливающую общий стандарт выполнения проектов внутри организации. Для каждого отдельного проекта стандартный процесс должен быть модифицирован в соответствии со спецификой этого проекта. При помощи формальных метрик измеряется эффективность процессов, а сами процессы постоянно оптимизируются.
Необходимо сказать, что CMMI не описывает какой-то конкретный процесс разработки. CMMI-совместимым может быть проект с водопадным, итеративным или другим жизненным циклом. Правильнее думать о CMMI как о наборе элементов процессов, приемов и методик, из которых, как из конструктора, нужно собрать законченный процесс.
Внедрение CMMI в организации может происходить на непрерывной (continuous) или ступенчатой (staged) основе. Содержание модели CMMI в обоих случаях одно и тоже, меняется только ее представление. Непрерывное представление дает возможность производить улучшения в отдельных процессных областях в произвольном порядке. Ступенчатое представление определяет четкую последовательность шагов по внедрению CMMI; каждый шаг соответствует достижению так называемого уровня зрелости (maturity level). Организации необходимо принять решение, до какого уровня зрелости она намерена дойти, а также необходимо ли проходить официальную сертификацию на соответствие этому уровню.
Остановимся подробнее на ступенчатом представлении, поскольку именно оно чаще всего используется на практике.
Структура CMMI (ступенчатое представление)
Основными элементами модели CMMI являются процессные области, общие и специальные задачи, общие и специальные практики.
CMMI определяет 22 процессные области, такие как планирование проекта (Project Planning), управление рисками (Risk Management), разработка требований (Requirements Development) и т.д. В ступенчатом представлении процессные области сгруппированы по пяти уровням зрелости (от 1 до 5). В непрерывном представлении каждая процессная область находится на одном из шести (от 0 до 5) уровней производительности (capability level).
Процессы в каждой процессной области должны достигать ряда целей. Общие цели (generic goals) относятся к нескольким процессным областям. Специальные цели (specific goals) уникальны для своей процессной области.
Для достижения специальных и общих целей служат специальные и общие практики (practices). Практики – это деятельность или задачи, которые должны быть выполнены для достижения соответствующей цели.
Рисунок 4.
В качестве примера рассмотрим процессную область Планирование проекта (Project Planning). В нее входит определение проектных артефактов, разбиение работ на отдельные задачи и их оценка, планирование необходимых ресурсов, составление графика проекта, анализ рисков, и т.д. В результате планирования проекта создается план проекта (project plan) – основной документ для организации и контроля проектных работ, управления бюджетом и оценки доходности , управления изменениями и рисками.
ПРИМЕЧАНИЕ
Часто путают план (plan) и график (schedule) проекта. План проекта – более широкое понятие; как правило, он включает в себя график.
|
Процессная область Планирование проекта должна достигать трех специальных и двух общих целей. В рамках этих целей необходимо:
-
Установить оценки (специальная цель): подготовить реалистичные оценки, такие как трудоемкость и стоимость проекта, для дальнейшего планирования.
-
Разработать проектный план (специальная цель): создать документ, одобренный заинтересованными сторонами, описывающий жизненный цикл проекта, бюджет, ресурсы, риски, график, стратегию обеспечения качества и т.п.
-
Получить обязательства участников проекта (специальная цель): участники проекта, ответственные за его выполнение, должны считать проектный план реалистичным и выполнимым, и подтвердить обязательство выполнить свои задачи в рамках заданного графика, ресурсов и качества.
-
Учредить управляемый процесс (общая цель): общее требование к процессам на уровне зрелости 2.
-
Учредить определенный (defined) процесс (общая цель): общее требование к процессам на уровне зрелости 3.
Перечислим практики, позволяющие достичь цели «разработать проектный план».
-
Установить бюджет и график проекта.
-
Идентифицировать риски.
-
Спланировать управление данными (определить источники и форматы данных, необходимые процедуры для миграции, репликации и получения данных, требования по безопасности и т.д.).
-
Определить необходимые ресурсы.
-
Определить требования к профессиональным навыкам сотрудников, запланировать тренинги.
-
Запланировать вовлечение всех заинтересованных лиц.
-
Создать проектный план.
Как уже говорилось, ступенчатое представление CMMI позволяет классифицировать организации по уровням зрелости.
-
Уровень 1: начальный (Initial). Процессы в организации формируются спонтанно и хаотично. Отдельные проекты могут завершаться успешно, однако вероятность их успешного завершения, а также соответствие запланированным графику и бюджету малопредсказуемы.
-
Уровень 2: управляемый (Managed). Основная задача при внедрении этого уровня – установить для каждого проекта стандартные процессы управления требованиями, планирования, наблюдения и контроля над проектом, управления конфигурациями. Естественно, процессы должны соответствовать требованиям CMMI, а именно достигать всех специальных целей в соответствующих процессных областях, а также общих целей, относящихся к уровню 2. Для каждого проекта периодически проводится анализ его соответствия установленным процедурам и, при необходимости, корректирование процессов. Также периодически измеряются и анализируются метрики (производительности, качества и т.п.)
-
Уровень 3: определенный (Defined). Уровень 3 включает в себя все требования уровня 2, а также добавляет множество обязательных процессных областей (разработка требований, интеграция, тестирование, управление рисками, и другие). Однако главное его отличие от уровня 2 заключается не в этом. В то время как уровень 2 требует определить процесс для каждого отдельного проекта, на уровне 3 набор стандартных процессов должен существовать на уровне всей организации. Процессы для отдельных проектов создаются при помощи настройки (tailoring) стандартных процессов организации, при этом изменения должны быть ограничены правилами настройки (tailoring guidelines). Настройка процессов – это также процессная область, определенная в CMMI как Organizational Process Definition.
-
Уровень 4: количественно управляемый (Quantitatively Managed). Этот уровень требует количественного измерения метрик производительности и качества используемых процессов. По сравнению с уровнем 3 уровень 4 дает возможность предсказания и сравнения (на основе статистических данных) измеряемых характеристик процессов.
-
Уровень 5: оптимизирующий (Optimizing). Уровень 5 – высшая ступень развития организации, использующей CMMI. При помощи метрик с уровня 4 организация постоянно изменяет свои процессы для того, чтобы улучшить производительность и качество создаваемых продуктов.
Практика
В каких организациях и на каких проектах лучше всего работает CMMI? Для того чтобы понять это, необходимо выделить основные характеристики модели.
CMMI вполне заслуженно считается тяжеловесной методологией, причем требует ощутимых затрат как во время, так и после внедрения. Тяжеловесность процессов нарастает с продвижением по уровням зрелости. Уже первый из интересных в практическом смысле уровней зрелости – уровень 3 – требует значительных усилий по обучению проектной команды, ведению проектной документации, периодическому аудиту процессов.
Как уже говорилось, под требования CMMI можно подогнать самые разнообразные процессы разработки, однако некоторые сочетания явно не имеют смысла. К примеру, вряд ли можно найти разумное применение процессу XP, дополненному формальным документированием требований и сбором метрик.
Что получает организация в обмен на усилия и ресурсы, потраченные на внедрение CMMI? Прежде всего, предсказуемость сроков и бюджета выполнения более или менее аналогичных проектов. Точность планирования – это основная цель 3 и 4 уровней зрелости CMMI, эффективность разработки становится ключевым фактором лишь на уровне 5. Благодаря хорошо документированным процессам и промежуточным результатам работ становится возможным быстро подключать к проекту новых сотрудников (возможно, более типичная ситуация – заменять ушедших).
Таким образом, представляется целесообразным использование CMMI в следующих условиях.
-
В относительно больших организациях, которые могут позволить себе значительные накладные расходы на внедрение и использование процесса.
-
При высокой текучести кадров, когда тем не менее необходимо поддерживать скорость разработки и качество продуктов на достойном уровне.
-
В случаях, когда организация выполняет большое количество более или менее однотипных проектов, CMMI позволяет достаточно точно планировать сроки и бюджет, и выполнять проекты в этих рамках.
-
Важная, а часто и определяющая причина для внедрения CMMI – возможность официальной сертификации на достижение определенного уровня зрелости. Нередко наличие или отсутствие сертификации по CMMI является решающим фактором в выборе компании-подрядчика.
Очевидно, что не имеет большого смысла использовать CMMI для одного или нескольких отдельных проектов. Внедрение должно происходить во всей организации, департаменте и т.д.
Вряд ли использование CMMI принесет какие-либо преимущества при разработке новых продуктов, а особенно в исследовательских проектах (research and development). Поскольку при этом отнюдь не исчезают все накладные расходы, связанные с этой моделью, на мой взгляд, нецелесообразно использовать CMMI для разработки новых продуктов или сервисов. Однако проекты по внедрению этих продуктов вполне могут эффективно использовать CMMI.
Выводы
Мы увидели, что современные процессы, использующиеся в реальных проектах, весьма разнообразны. Каждый из них имеет свои преимущества, которые проявляются в соответствующих условиях. Даже, казалось бы, безнадежно устаревшая водопадная модель совершенна адекватна для некоторых проектов. Каждый процесс обладает также и рядом характеристик, которые ограничивают область его эффективного использования. Эта ситуация вполне типична для разработки ПО, где уже накоплено множество технологий и методик, но не существует универсального метода, оптимального для любой задачи.
Несомненно, область процессной инженерии еще далека от зрелости и в ближайшем будущем будут созданы новые методологии. Из существующих процессов, не описанных в статье, имеет смысл обратить внимание на методологию Microsoft Solutions Framework (MSF). Это гибкая и достаточно легковесная методология, построенная на итеративной модели разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нетрадиционные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.
Интересным примером является OpenUP – семейство открытых (в отличие от проприетарного RUP) процессов, создаваемое в рамках проекта Eclipse Process Framework (EPF). Процесс OpenUP/Basic основан на принципах RUP, максимально упрощенного для гибкой разработки небольших проектов. Одновременно с ним развивается OpenUP/MDD, следующий методологии разработки через моделирование (Model Driven Development).
OpenUP/Basic и OpenUP/MDD реализуются в виде расширений EPF Composer, средства для создания и настройки процессов. Пользователи EPF Composer могут создавать свои процессы, используя в качестве компонентов фрагменты процессов, доступные в расширениях наподобие OpenUP/Basic и OpenUP/MDD.
RUP
Один из самых известных процессов, использующих итеративную модель разработки – Rational Unified Process (RUP). Он был создан во второй половине 1990-х годов в компании Rational Software. Основными разработчиками были Филипп Крачтен (Philippe Kruchten), Грейди Буч (Grady Booch), Джеймс Рамбо (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Кстати, последние трое являются также создателями нотации UML.
Термин RUP означает как методологию разработки, так и продукт компании IBM (ранее – Rational) для управления процессами разработки. Методология RUP описывает абстрактный общий процесс, на основе которого организация или проектная команда должна создать специализированный процесс, ориентированный на ее потребности.
Можно выделить следующие основные характеристики процесса RUP.
Разработка требований
Для описания требований в RUP используются прецеденты использования (use cases). Это не слишком удивительно, учитывая, что один из создателей RUP, Айвар Якобсон, является также автором концепции прецедента использования. Полный набор прецедентов использования системы вместе с логическими отношениями между ними (прецеденты могут включать и расширять другие прецеденты) называется моделью прецедентов использования.
Каждый прецедент использования – это описание сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. Разумеется, не имеет смысла документировать в виде прецедентов нефункциональные требования (к производительности, качеству т.д.). Однако согласно RUP все функциональные требования должны быть представлены в виде прецедентов использования. Считается, что модель прецедентов дает более целостное представление о функциональности системы по сравнению с традиционным описанием требований (перечислением функций, которыми должна обладать система).
Итеративная разработка
Проект в RUP состоит из последовательности итераций с рекомендованной продолжительностью от 2 до 6 недель. Основной единицей планирования итераций является прецедент использования. Перед началом очередной итерации определяется набор прецедентов использования, которые будут реализованы к ее завершению.
Итеративная модель, подробно описанная выше, позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.
Архитектура
Можно сказать что RUP – ориентированная на архитектуру методология. Считается, что реализация и тестирование архитектуры системы должны начинаться на самых ранних стадиях проекта. RUP использует понятие исполняемой архитектуры (executable architecture) – основы приложения, позволяющей реализовать архитектурно значимые прецеденты использования. Основы исполняемой архитектуры должны быть реализованы как можно раньше. Это позволяет оценить адекватность принятых архитектурных решений и внести необходимые коррективы еще в начале проекта. Таким образом, для первых нескольких итераций необходимо выбирать прецеденты, которые требуют реализации большей части архитектурных компонентов.
RUP поощряет использование визуальных средств для анализа и проектирования. Как правило, используется нотация и, соответственно, средства моделирования UML (такие как Rational Rose). Модель предметной области документируется в виде диаграммы классов, модель прецедентов использования – при помощи диаграммы прецедентов, взаимодействие компонентов системы между собой описывается диаграммой последовательности и т д.
Жизненный цикл проекта
Жизненный цикл проекта RUP состоит из четырех фаз. Последовательность этих фаз фиксирована, но число итераций, необходимых для завершения каждой фазы, определяется индивидуально для каждого конкретного проекта. Фазы RUP нельзя отождествлять с фазами водопадной модели– их назначение и содержание принципиально различны.
Начало (Inception)
Фаза Начало обычно состоит из одной итерации. В ходе выполнения этой фазы необходимо:
-
Определить видение и границы проекта.
-
Создать экономическое обоснование (business case).
-
Идентифицировать большую часть прецедентов использования и подробно описать несколько ключевых прецедентов.
-
Найти хотя бы одно возможное архитектурное решение.
-
Оценить бюджет, график и риски проекта.
Если после завершения первой итерации заинтересованные лица приходят к выводу о целесообразности выполнения проекта, проект переходит в следующую фазу. В противном случае проект может быть отменен или проведена еще одна итерация фазы Начало.
Проектирование (Elaboration)
В результате выполнения этой фазы на основе требований и рисков проекта создается основа архитектуры системы. Проектирование может занимать до двух-трех итераций или быть полностью пропущенным (если в проекте используется архитектура существующей системы без изменений). Целями этой фазы являются:
-
Детальное описание большей части прецедентов использования.
-
Создание оттестированной (при помощи архитектурно значимых прецедентов использования) базовой архитектуры.
-
Снижение основных рисков и уточнение бюджета и графика проекта.
В отличие от модели водопада, основным результатом этой фазы является не множество документов со спецификациями, а действующая система с 20-30% реализованных прецедентов использования.
Построение (Construction)
В этой фазе (длящейся от двух до четырех итераций) происходит разработка окончательного продукта. Во время ее выполнения создается основная часть исходного кода системы и выпускаются промежуточные демонстрационные прототипы.
Внедрение (Transition)
Целями фазы Внедрения являются проведение бета-тестирования и тренингов пользователей, исправление обнаруженных дефектов, развертывание системы на рабочей площадке, при необходимости – миграция данных. Кроме того, на этой фазе выполняются задачи, необходимые для проведения маркетинга и продаж.
Фаза внедрения занимает от одной до трех итераций. После ее завершения проводится анализ результатов выполнения всего проекта: что можно изменить для улучшения эффективности в будущих проектах?
Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.
Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.
Среди наиболее известных стандартов можно выделить следующие:
-
ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4].
-
ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].
-
Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.
-
Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML [6].
-
Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
-
Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
|
