 |
Пятиуровневая модель зрелости технологического процесса разработки программного обеспечения
|
|
|
|
Концепцию зрелости техпроцесса организации-разработчика ПО предложил институт SEI (Software Engineering Institute).
Зрелость ТП - это степень четкости (ясности) определения, управления, измерения, контроля и выполнения конкретного ТП. Зрелость свидетельствует, с одной стороны, о мощности (richness) процесса программирования в организации, и, с другой стороны, о степени его применимости (адаптируемости) к проектам организации. Производительность и качество, обеспечиваемые зрелым техпроцессом программирования, могут быть со временем повышены благодаря непрерывному росту дисциплины, достигаемому в результате использования такого процесса.
Зрелость технологического процесса в организации помогает предсказать способности проекта в достижении поставленных целей. С ростом зрелости организации различия между ожидаемыми и получаемыми результатами по проектам уменьшаются.
СММ-модель (от Capability Maturity Model) определяет характеристики техпроцессов, находящихся на определенном уровне зрелости, и указывает направление совершенствования ТП в организации до уровня зрелого упорядоченного процесса.
Такое определение СММ допускает нескольких направлений ее применения, например:
группы аналитической оценки - идентификации сильных и слабых сторон организации;
группы экспертной оценки - идентификация рисков выбора исполнителей проектов и управления работами;
менеджеры и технический персонал - оценка собственных действий по планированию и реализации программы улучшения техпроцесса в организации;
группы улучшения техпроцесса - руководство по определению и улучшению техпроцесса в организации.
СММ - это описательная (descriptive) модель, т.к она описывает существенные (или ключевые) атрибуты, которыми должен обладать процесс программирования в организации, находящейся на определенном уровне зрелости.
|
|
|
В то же время СММ - это нормативная (normative) модель, поскольку рекомендует применение определенных практических приемов. СММ обеспечивает достаточный уровень абстракции и не накладывает ограничений на способы реализации процесса программирования в организации, то есть, в любом контексте применения СММ должна существовать разумная интерпретация практических приемов.
СММ нельзя считать предписывающей (prescriptive) моделью, поскольку она дает ответ на вопрос, какими свойствами должен обладать процесс программирования в организации, имеющей тот или иной уровень зрелости, но не говорит о том, какими средствами обеспечить улучшение процесса и достижение соответствующего уровня.
Достоинства СММ:
основывается на реальных процедурах;
отражает передовую практику программной инженерии и опыт выполнения больших государственных заказов на разработку ПО;
пригодна для совершенствования или оценки процессов разработки ПО;
хорошо документирована;
продолжает уточняться (для нижних уровней) и развиваться (для верхних уровней) по мере приобретения организациями-разработчиками опыта построения зрелого ТП.
Концепция зрелости процесса разработки ПО основывается на интеграции концепций:
технологического процесса разработки ПО (software process)
широты возможностей процесса разработки ПО (software process capability)
результативности процесса разработки ПО (software process performance)
зрелости процесса разработки ПО (software process maturity).
Широта возможностей ТП - это диапазон ожидаемых результатов, достигаемых при выполнении техпроцесса. Оценка широты возможностей процесса программирования в организации - это способ предсказания наиболее вероятных результатов (выхода), которые можно ожидать от любого проекта ПО в рамках организации.
|
|
|
Результативность ТП характеризует реальные результаты, достигнутые благодаря следованию процессу. Результативность конкретного проекта, разрабатываемого в определенных условиях, может не отражать в полной мере широты возможностей процесса в организации, поскольку возможности проекта ограничены его средой (на них влияют, например, изменения технологии, требующие от персонала дополнительной подготовки).
Уровень зрелости (maturity level) организации-разработчика - это четко определенный базис для достижения зрелости процесса разработки ПО, который указывает на степень совершенства (состоятельности) процесса. Уровень зрелости описывает характеристики, которые достигает организация. На каждом уровне сконцентрировано множество целей процесса, которые, в случае их достижения, стабилизируют соответствующий важный компонент (направление) процесса программирования.
Пять уровней зрелости СММ представлены на рис.2. Стрелки на рисунке указывают вид возможностей процесса, который официально утверждается организацией на каждом уровне зрелости. Названия уровней отражают сущность изменений в основном процессе программирования:
Рис.2. Пять уровней зрелости технологического процесса разработки ПО
Каждый уровень образует фундамент для эффективной реализации процессов на последующих уровнях. Пропуск уровней противоестественен. Организации могут с успехом использовать (внедрять) процессы, описанные на вышележащих уровнях, находясь при этом на более низком уровне. Например, такие процессы как анализ требований, проектирование, кодирование и тестирование, не обсуждаются в СММ вплоть до третьего уровня, хотя организации проводят соответствующую работу уже на первом уровне. То же касается и обзоров, которые могут проводиться на 1 или 2 уровне, хотя описаны в СММ на 3 уровне. Однако, эти и другие процессы, не отнесенные, но применяемые на низлежащих уровнях, не могут в полной мере раскрыть свой потенциал, пока не будет создан соответствующий фундамент на нижних уровнях СММ.
Таким образом, СММ идентифицирует уровни, через которые организация должна эволюционировать для утверждения культуры программной инженерии. Организации, находящиеся на 1 уровне и пытающиеся создать фиксированный (defined) процесс (уровень 3), не создав перед тем повторяемый процесс (уровень 2), обычно не достигают успеха, поскольку менеджеры проекта больше всего озабочены проблемами сроков и стоимости проекта. Это основная причина, по которой нужно сначала усовершенствовать процесс управления, а затем процессы собственно инженерии. Может показаться, что определить и реализовать процесс инженерии легче, чем процесс управления (особенно с точки зрения разработчика), но без дисциплины управления процесс инженерии неминуемо скатится к проблемам сроков и стоимости. Способность организации реализовывать процессы с высших уровней зрелости не означает, что уровни зрелости могут быть пропущены.
|
|
|
По мере того, как организация достигает зрелости ТП, она официально устанавливает (учреждает, внедряет) (institutionalizes) этот процесс в виде базового (стандартного) путем принятия соответствующих административных решений, разработки стандартов и создания необходимых организационных структур. Административное оформление ТП влечет за собой создание инфраструктуры и формирование корпоративной культуры, которые призваны обеспечить воплощение в жизнь методов, практических приемов и процедур СММ.
Ключевые направления совершенствования техпроцесса (КРА, от Кey Рrocess Аreas) указывают области, на которых должна сосредоточить внимание организация для улучшения ТП.
КРА сгруппированы по уровням зрелости (табл.1) так, что каждое КРА всегда относится только к одному уровню СММ. Это не означает, что в организации, находящейся на определенном уровне зрелости, не могут выполняться процедуры в рамках направлений, относящихся к другим уровням зрелости. Заключение о том, какой уровень зрелости занимает организация, делается только по КРА, соответствующим данному уровню.
Таблица 1 Характеристика уровней зрелости технологического процесса разработки ПО
| Уровень зрелости | Характеристика уровня зрелости | Ключевые направления совершенствования ТП |
| 1. Начальный | Отсутствует стабильная среда разработки и сопровождения. Техпроцесс разработки неструктурирован и хаотичен. Бюджет, сроки и качество разработки непредсказуемы. Частые авралы. Успех проекта определяется способностями отдельных исполнителей или менеджера, а не организационной структурой коллектива. По оценкам SEI около 75% фирм-разработчиков ПО (за рубежом) находятся на этом уровне зрелости. Это же касается и подавляющего большинства отечественных организаций-разработчиков. Начальный уровень включен в модель с целью образования точки отсчета (базы) для оценивания последующих улучшений процесса на более высоких уровнях модели | |
| 2. Повторяемый | Управление проектом нацелено на контроль соблюдения планов по стоимости, срокам и функциональности разработки ПО. Процесс программирования упорядочен. Применяются неоднократно отработанные приемы управления для схожих проектов. Разработка новых проектов ведется на основе ранее накопленного опыта и в соответствии со стандартами в части определения исходных требований, управления конфигурацией, планирования и оценки качества ПО | Управление требованиями Планирование проекта ПО Мониторинг проекта ПО Управление работой соисполнителя Обеспечение качества ПО Управление конфигурацией ПО |
| 3. Фиксированный | Процесс программирования документирован, стандартизован и интегрирован в стандартный (базовый) техпроцесс. Внедрена программа обучения разработчиков ПО и менеджеров. Коллективы отдельных проектов следуют стандартизованному техпроцессу разработки в организации и настраивают его для достижения целей конкретного проекта | Обеспечение разработки техпроцессов Определение техпроцесса организации Организация обучения персонала Интегрированное управление проектом ПО Инженерный подход к разработке ПО Межгрупповая координация Коллективный просмотр |
| 4. Управляемый | Достигается цель количественной оценки качества продуктов ПО и процессов разработки в рамках единой программы измерения. Осуществляется сбор и анализ данных по проектам, что дает возможность управлять риском проекта и “возвращать" процесс в установленные рамки | Управление техпроцессом на основе количественных оценок Управление качеством ПО |
| 5. Оптимизируемый | Непрерывное улучшение техпроцесса на основе количественной оценки его слабых и сильных сторон. Данные об эффективности процесса разработки используются для анализа в целях перехода на новые технологии и совершенствования процесса разработки в организации. Данные о новых приемах инженерии изучаются и распространяются по организации. Коллективами проектов производится причинно-следственный анализ ошибок в проектах | Предупреждение ошибок Управление изменениями в технологии Управление изменениями в техпроцессах |
|
|
|
|
|
|
Для достижения определенного уровня зрелости необходимо решение всех задач ключевых направлений совершенствования ТП, связываемых с этим уровнем зрелости.
Для удобства оценивания действия в рамках каждого ключевого направления совершенствования ТП сгруппированы в следующие пять разделов:
административные меры ( commitment to perform) - действия организации для обеспечения хода и стабильности техпроцесса (обычно касаются формирования политики и обеспечения финансовой поддержки);
необходимые предпосылки ( ability to perform) - условия для обеспечения готовности ТП (необходимые ресурсы, организационные структуры и система обучения);
выполняемые процедуры ( activities performed) - правила и процедуры, необходимые для успешной реализации соответствующего участка ТП (разработка планов и процедур, выполнение технологических операций, проверка и корректировка ТП);
измерение и анализ ( measurement and analysis) - измерение показателей техпроцесса, анализ полученных результатов измерений, оценка состояния и эффективности процесса;
проведение проверки ( verifying implementation) - проверка соответствия выполняемых действий требованиям существующего техпроцесса (методы проверки - обзоры (осмотры) (reviews) и аудиторские проверки (ревизии) (audits) в ходе управления и обеспечения качества ПО).
|
|
|
