Является структурным элементом модели смм. Зрелость проектных организаций. Методология CMM. Модель развития программного обеспечения

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

Разработка такого обзора была вызвана запросом американского федерального правительства на предоставление метода оценки субподрядчиков для разработки ПО. Реальная же проблема состояла в неспособности управлять большими проектами. Во многих компаниях проекты выполнялись со значительным опозданием и с превышением запланированного бюджета. Необходимо было найти решение данной проблемы.

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, в следствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в кот 196 орой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.

В результате был выпущен стандарт CMM, Version 1.1, который до настоящего времени активно используется во всем мире.

Рис. 1. Глобальное влияние использования СММ

Причины такого интереса к СММ понятны. Несмотря на то, что и сами разработчики ПО, и их руководство зачастую очень хорошо знают свои постоянные проблемы, они не могут прийти к единому мнению о том, какие изменения необходимы компании в первую очередь. Без выработки единой стратегии проведения улучшений руководство не может найти взаимопонимания со своими сотрудниками относительно наиболее приоритетных задач по улучшению. Для достижения максимального результата от усилий, потраченных на улучшение процессов, необходимо иметь поэтапную стратегию развития, которая позволит улучшать зрелость процессов разработки постепенно, эволюционным путем.

Постоянное улучшение процессов базируется на постепенном взращивании культуры компании, а не на проведении революционных инноваций. В СММ представлена схема такого постепенного улучшения, разделенная по 5 уровням зрелости процессов. Эти 5 уровней представляют собой шкалу для оценки уровня зрелости процессов разработки ПО в компании и для измерения их параметров.

Рис. 2. Принцип последовательного повышения уровня зрелости: возможности развития организации

Приведем основные характеристики каждого уровня:

1. Initial - Процесс разработки носит хаотический характер. Определены лишь немногие из процессов и успех проектов зависит от конкретных исполнителей.
2. Repeatable - Установлены основные процессы управления проектами: отслеживание затрат, графика работ и функциональности. Упорядочены некоторые процессы, необходимые для того, чтобы повторить предыдущие достижения на аналогичных проектах (проектах с аналогичными приложениями).
3. Defined - Процессы разработки ПО и управления проектами описаны и внедрены в единую систему процессов компании. Во всех проектах используется стандартный для организации процесс разработки и поддержки ПО, адаптированный под конкретный проект.
4. Managed - Собираются детальные количественные данные по функционированию процессов разработки и качеству конечного продукта. Анализируется значение и динамика этих данных.
5. Optimizing - Постоянное улучшение процессов основывается на количественных данных по процессам и на пробном внедрении новых идей и технологий.

Введение в SW-CMM

(Улучшение зрелости процессов разработки программного обеспечения на основе модели Software Engineering Institute Capability Maturity Model for Software)

Курс предназначен для:
Для руководителей компаний-разработчиков программного обеспечения, руководителей отделов и проектов разработки ПО и специалистов по качеству, которые заинтересованы в:

улучшении прозрачности существующих производственных процессов;

повышении производительности процессов и компании в целом;

снижении себестоимости производства продукции и объема существующего "скрытого" производства;

повышении репутации компании в профессиональной среде;

открытии новых рынков сбыта продукции.

2.1 Стоимость, продолжительность и получаемые результаты. Статистические данные по отрасли
2.2 Эффективность инвестиций в CMM

3.1 TQM (Total Quality Management), SPI (Software Process Improvement) и Best Business Practices как основа CMM
3.2 Базовые понятия TQM. Применение подходов TQM при производстве программных продуктов
3.3 Преимущества и риски, заложенные в модели улучшения процессов по CMM
3.4 Понятие процесса. Основные составляющие процессного подхода
3.5 Уровни зрелости процессов

9.1 Система стандартов для IT индустрии (Roadmap)
9.2 Взаимосвязь ISO с CMM, Rational Unified Process, Project Management
9.3 Применение CMM для небольших организаций
9.4 Чего нет в СММ
9.5 Документы и процессы

10.1 Заключительный обзор модели SW-CMM. Распространение в мире. Основные трудности
10.2 CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM

Комлект слайдов, материалы практических занятий, дополнительные материады для самостоятельного изучения.

Полный комлект документов по SW-CMM (текст стандарта, методики проведения оценки, статистические материалы по отрасли, примеры документов)

Практический курс по технологии внедрения модели SW-CMM в IT-компаниях

Краткая аннотация:
Данный курс направлен на то, чтобы помочь компаниям самостоятельно и грамотно спланировать и выполнить работы по внедрению модели улучшения зрелости процессов, помочь избежать типичных ошибок и проблем, возникающих при внедрении.

Курс предназначен для:
Курс предназначен для руководителей предприятий и подразделений, занимающихся разработкой ПО, руководителей проектов, менеджеров по качеству и других лиц, заинтересованных в повышении качества своих разработок и в сертификации своего процесса по CMM.

Обзор признанных стандартов в области менеджмента качества для IT (ISO 9000, SW-CMM, CMMI, TickIT, SPICE)

17. К CMM через ISO?

5 эволюционных этапов в управлении организационными процессами. Объяснение Capability Maturity Model (Модель развития функциональных возможностей). CMM

Моделью Capability Maturity Model (Модель зрелости возможности) CM-CEI организационная модель, которая описывает 5 эволюционных этапов (уровней), на которых управляются процессы в организации.

Смысл Capability Maturity Model (Модель зрелости возможности), первоначально созданной для развития программного обеспечения, в том, что организация должна быть способна принять и поддерживать приложения своего программного обеспечения. Модель также предлагает конкретные шаги и инициативы, которые помогут организации развиться до следующего уровня.

5 этапов Capability Maturity Model (Модель развития функциональных возможностей)

Начальный (Initial) (процессы специальные, хаотичные или, на самом деле, немногие из них определены) Повторяемый (Repeatable) (основные процессы установлены, и существует дисциплина для того, чтобы придерживаться этих процессов) Определяемый (Defined) (все процессы определены, документированы, унифицированы и интегрированы) Управляемый (Managed) (процессы измеряются путем агрегирования подробных данных о процессах и их качестве) Оптимизирование (Optimizing) (непрерывное развитие процесса с помощью количественной обратной связи и испытания новых идей и технологий)

Модель развития программного обеспечения

CMM описывает принципы и практики, которые лежат в основе понятия зрелости программного процесса. Они предназначены для того, чтобы помочь фирмам по разработке и продаже программного обеспечения улучшить совершенность своих программных процессов эволюционным путем. Начиная от специальных, хаотичных процессов, переходя к зрелым, дисциплинированным программным процессам. Фокус делается на определение ключевых областей процессов и примерные практики, которые могут составить дисциплинированные программные процессы. Концепция зрелости CMM создает контекст, в котором:

Практики можно повторить. Если вы не повторяете какую-то операцию, то не стоит ее улучшать. Существуют правила, процедуры и практики, которые принуждают организацию к внедрению и последовательному исполнению. Лучшие методы организации производственных работ можно быстро распространить между группами. Практики определены так, чтобы позволить обмен между проектами, таким образом обеспечивая некоторцю стандартизацию для организации. Отклонения в исполнении этих методов минимизируются. Количественные цели установливаются для задач; и установливаются, производятся и поддерживаются измерения для формирования основы для оценки. Практики непрерывно улучшаются для совершенствования возможности (оптимизирование).

Модель зрелости возможности полезна не только для развития программного обеспечения, но также для описания эволюционных уровней организаций в общем и описания уровня менеджмента, который организация реализовала или хочет достигнуть.

Структура Модели развития функциональных возможностей

Уровни зрелости - многоуровневая концепция, обеспечивающая последовательность дисциплины, которая необходима для достижения непрерывного улучшения. Важно отметить здесь, что организация развивает способность оценивания последствий новой практики, технологии или инструмента. Следовательно, дело не в принятии этих нововведений, а скорее в том, как эти инновационные усилия оказывают влияние на существующие практики. Это оказывает поддержку проектам, группам и организациям давая им основание для обоснованного выбора. Ключевые области процессов - Ключевая область процессов/Key process area (KPA) определяет группу родственных операций, которые при совместном выполнении, достигают ряда важных целей. Цели - цели ключевой области процессов описывают положения, которые должны существовать для той ключевой области процессов. Положения необходимо внедрить эффективным и надежным способом. Объем, в котором цели выполнены, показывает какого рода возможность организация установила на этом уровне совершенности. Цели очерчивают сферы деятельности, границы, и цель каждой ключевой области процессов. Общие характеристики - общие характеристики включают практики, которые внедряют и институционализируют ключевые области процессов. Эти 5 типов общих характеристик включают: Обязателъство исполнить, Способность исполнить, Выполняемые инициативы, Измерение и Анализ, и Контроль внедрения. Ключевые практики - ключевые практики описывают элементы инфраструктуры и практики, которые вносят наиболее эффективный вклад во внедрение и институционализацию ключевых областей процессов.

Критерии для пределения процесса

Критерии для пределения процесса - это совокупность элементов процесса, которые необходимо включить в описание программного процесса для того, чтобы люди могли использовать их на практике. Для того, чтобы установить критерии вам надо задать вопрос - «Какая информация по программному процессу нужна для документирования?»

Модели совершенствования

Совершенствование процессов работы с требованиями

Парадигма управления качеством, как способ организации производства, появилась давно. Идеи, заложенные в группе стандартов ISO9000 1) , уходят корнями, в частности, и в такие "советские" изобретения, как поддержка рационализаторских предложений, наставничества и др.

В современной концепции процессно-ориентированной организации бизнеса процесс непрерывного совершенствования качества занимает одну из ключевых позиций.

Применительно к софтверной индустрии, помимо серии ISO9000, наиболее успешно себя зарекомендовавшими стандартами качества являются SEI CMM, SEI CMMI, ISO/IEC 15504 (SPICE), Bootstrap, TickIT.

Активное внедрение методов управления качеством на Западе началось в начале 1960-х годов. В основу стандартов серии ISO9000 легла философия подходов CPI (Continuous Process Improvement) и TQM (Total Quality Management) . Подъем экономики послевоенной Японии во многом был обусловлен идеям, заложенным в TQM.

Качество - термин, который для одних означает необходимость делать то, что желает потребитель, для других - то, что отвечает его потребностям. Менеджмент качества, как он определен в ИСО 9001:2000, исходит прежде всего из того, что люди работают лучше, если им известно то, чем они занимаются. .

Поэтому прежде, чем приступить к какому-либо действию, следует получить ответы на вопросы: что нужно делать, кто будет проверять сделанное, как это нужно делать и как определить, что работа завершена? Необходимо также продумать, как вы собираетесь управлять данным процессом и как его можно усовершенствовать.

Основные принципы ISO9000:

• Концентрация на потребностях заказчика;
• Активная лидирующая роль руководства;
• Вовлечение исполнителей в процессы совершенствования;
• Реализация процессного подхода;
• Системный подход к управлению;
• Обеспечение непрерывных улучшений;
• Принятие решений на основе фактов;
• Взаимовыгодные отношения с поставщиками.

Безусловное достоинство стандартов этой группы связано с тем, что они апробированы на множестве предприятий мира. Однако рекомендации данных стандартов носят достаточно общий характер и не учитывают специфику предприятий отрасли IT. Для этого были разработаны специализированные подходы, рассмотренные ниже.

Стандарт СММ (the Capability Maturity Model) разработан институтом инженерии программного обеспечения (SEI) при университете Карнеги-Меллон.

Назначение стандарта - оценка уровня "зрелости" (maturity levels) организации - разработчика программного обеспечения. Выделяются пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий (подробнее см. в ). Данный стандарт получил широкую известность, значительное количество западных IT-компаний сертифицировано по CMM.

В 2000 г. SEI выпустил CMMI-SE/SW, интегрированную модель совершенствования как ПО, так и возможностей конструирования систем .

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.1.
Уровень зрелости	Название	Области процессов
	Начальный	(нет)
	Управляемый	Управление требованиями Планирование проекта Мониторинг и контроль проекта Управление соглашениями с поставщиками Измерения и анализ Обеспечение качества процессов и продуктов Управление конфигурацией
	Определенный	Разработка требований Техническое решение Интеграция продуктов Верификация Валидация Концентрация внимания на процессе Определение процесса организацией Организационное обучение Интегрированное управление проектом Управление риском Анализ и разрешение вопросов
	Количественно управляемый	Производительность организационных процессов Количественное управление проектом
	Оптимизирующий	Организационные нововведения и их развертывание Случайный анализ и разрешение

Область процессов "Управление требованиями"

Ключевые темы включают в себя то, как команда разработчиков должна приобретать понимание требований и разрешать вопросы с клиентами, вовлекать участников проекта в работу с требованиями и управлять изменениями. В отличие от SW-CMM, трассирование (одно из ключевых свойств требований) включено в рассматриваемую область процессов. В стандарте обсуждаются следующие качества трассирования:

• обеспечение записи источников низкоуровневых или вторичных требований;
• трассирование каждого требования вниз, к вторичным требованиям, и его размещение по функциям, объектам, процессам и исполнителям;
• установка горизонтальных связей между требованиями, принадлежащими к одному типу.

Область процессов "Разработка требований"

В CMMI-SE/SW описаны три набора приемов разработки требований:

• приемы, определяющие полный набор требований клиентов, которые затем используются для разработки требований для продукта (выявить нужды заинтересованных в проекте лиц; преобразовать нужды и ограничения в требования клиентов);
• приемы, определяющие полный набор требований для продукта (установить компоненты продукта; разместить требования по компонентам продукта; определить требования к интерфейсу);
• приемы получения вторичных требований, понимания требований и их подтверждения (установить оперативные концепции и сценарии; определить требуемую функциональность системы; проанализировать вторичные требования; оценить стоимость, сроки и риск создания продукта; утвердить требования).

Как в СММ, так и в CMMI формулируются цели, к которым проект или организация по разработке ПО должны стремиться в различных областях процессов. В них также рекомендуются технические приемы, помогающие достичь этих целей.

CMMI-SE/SW регламентирует взаимосвязи между управлением требованиями, разработкой требований и другими областями процессов (рис. 14.1).

Качество программных продуктов - пожалуй, одна из самых серьезных проблем индустрии программного обеспечения. Качество - это гораздо больше, чем просто отсутствие ошибок. Оно предполагает набор различных характеристик: надежность, устойчивость ко взлому, способность к адаптации, совместимость, сопровождаемость, переносимость, эффективность и т. п. Неудивительно, что в индустрии ПО существует такое многообразие стандартов качества.

Качество было легко измерить: или нам платили, или нет.
Дин Леффингуэлл, Дон Уидриг.
Управление программными требованиями

CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) - модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше - основные его положения были опубликованы еще в 1986 г.

Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных , методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

№ уровня	Название уровня	Ключевые области процесса
1	Начальный	Если организация находится на этом уровне, то ключевых областей процессов для нее не предусмотрено
2	Повторяющийся	Управление программными конфигурациями.Обеспечение качества программных продуктов.Управление контрактами подрядчиков.Контроль за ходом проектов.Планирование программных проектов.Управление требованиями
3	Определенный	Экспертные оценки.Координация взаимодействий проектных групп.Инженерия программного продукта.Комплексный менеджмент ПО.Программа обучения персонала.Определение организационного процесса.Область действия организационного процесса
4	Управляемый	Менеджмент качества ПО.Управление процессом на основе количественных методов
5	Оптимизируемый	Управление изменением процесса.Управление технологическими изменениями.Предотвращение дефектов

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

Стандарт CMM оказался весьма успешным, и впоследствии на его основе была создана целая серия стандартов (табл. 2). Притом он получил новое имя - SW-CMM (Capability Maturity Model for Software), точнее отражающее его положение в достаточно многочисленном семействе стандартов.

Таблица 2. Развитие стандартов CMM

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга - разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних организаций
Integrated Product Development CMM (IPD-CMM)	Служит средой для интеграции усилий по разработке на всех этапах жизненного цикла и со стороны каждого отдела компании

Однако практическое применение стандартов серии CMM показало, что они не обеспечивают безоговорочного успеха в разработке ПО. Эти стандарты не были хорошо согласованы между собой - одновременное внедрение различных модификаций CMM могло оказаться достаточно сложной задачей и приводило в недоумение специалистов организаций, которые с этим сталкивались.

Также существенная проблема CMM состоит в необходимости «выравнивания» всех процессов. Если организация пытается сертифицироваться на определенный уровень, то она должна обеспечить соответствующий уровень для всех своих процессов. Даже если специфика, методология или особенности разработки не располагают к выполнению определенных процессов, сертификация это требует.

Еще одна проблема вызвана тем положением, которое заняли стандарты CMM в современной индустрии ПО. Поскольку организация, обладающая высоким уровнем в соответствии с CMM, должна обеспечивать более высокие показатели программных продуктов по сравнению с теми, кто сертифицирован на низших уровнях, то стандарт стал применяться в качестве критерия отбора для участия в тендерах на разработку ПО или в аутсорсинговых проектах. Спрос на сертифицированные организации породил предложение по «быстрой и безболезненной сертификации».

Подобная ситуация стала возможной благодаря недостаткам процесса сертификации. Сертификации подлежит не вся организация в целом, а только определенный проект. Ничто не мешает организации создать «образцово-показательный» проект, выполняемый с учетом всех требований высоких уровней стандарта CMM, получить соответствующий уровень сертификации и заявить о том, что все продукты отвечают такому-то уровню стандарта.

Разрешить большинство проблем CMM призван новый стандарт SEI - Capability Maturity Model Integrated (CMMI) - Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления - классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

Помимо государственных и международных стандартов, существует несколько подходов к сертификации процесса разработки. Наиболее известными из них в России являются, по-видимому, CMM и CMMI.

CMM (Capability Maturity Model) - модель зрелости процессов создания ПО, которая предназначена для оценки уровня зрелости процесса разработки в конкретной компании. В соответствии с этой моделью имеется пять уровней зрелости процесса разработки. Первый уровень соответствует разработке «как получится», когда на каждый проект разработчики идут как на подвиг. Второй соответствует более-менее налаженным процессам, когда можно с достаточной уверенностью рассчитывать на положительный исход проекта. Третий соответствует наличию разработанных и хорошо описанных процессов, используемых при разработке, а четвертый - активному использованию метрик в процессе управления для постановки целей и контроля их достижения. И наконец, пятый уровень означает способность компании оптимизировать процесс по мере необходимости.

Требования CMM и CMMI

После появления CMM стали разрабатываться специализированные модели зрелости для создания информационных систем, для процесса выбора поставщиков и некоторые другие. На их основе была разработана интегрированная модель CMMI (Capability Maturity Model Integration). Кроме того, в CMMI была предпринята попытка преодолеть проявившиеся к тому времени недостатки CMM - преувеличение роли формальных описаний процессов, когда наличие определенной документации оценивалось значительно выше, чем просто хорошо налаженный, но не описанный процесс. Тем не менее CMMI также ориентирован на использование весьма формализованного процесса.

Таким образом, основой моделей CMM и CMMI является формализация процесса разработки. Они нацеливают разработчиков на внедрение детально описанного в регламентах и инструкциях процесса, который, в свою очередь, не может не требовать разработки большого объема проектной документации для соответствующего контроля и отчетности.

Связь CMM и CMMI с итеративной разработкой более опосредованная. Формально ни та ни другая не выдвигают конкретных требований к тому, чтобы придерживаться каскадного или итеративного подхода. Однако, по мнению ряда специалистов, CMM в большей степени совместима с каскадным подходом, в то время как CMMI допускает также и применение итеративного подхода.

Безусловно, RUP - это итеративная методология. Хотя формально обязательность выполнения всех фаз или какого-то минимального числа итераций нигде в RUP не обозначена, весь подход ориентирован на то, что их достаточно много. Ограниченное количество итераций не позволяет в полной мере использовать все преимущества RUP. Вместе с тем RUP можно применять и в практически каскадных проектах, включающих реально всего пару итераций: одну в фазе «Построение», а другую в фазе «Передача». Кстати говоря, в каскадных проектах реально используется именно такое количество итераций. Ведь проведение испытаний и опытной эксплуатации системы предполагает внесение исправлений, которые могут подразумевать определенные действия, связанные с анализом, проектированием и разработкой, то есть фактически являются еще одним проходом через все фазы разработки.

Методология RUP

Что касается формальности методологии, то здесь RUP представляет пользователю весьма широкий диапазон возможностей. Если выполнять все работы и задачи, создавать все артефакты и достаточно формально (с официальным рецензентом, с подготовкой полной рецензии в виде электронного или бумажного документа и т.д.) проводить все рецензирования, RUP может оказаться крайне формальной, тяжеловесной методологией. В то же время RUP позволяет разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте. А выбранные артефакты могут выполняться и рецензироваться с произвольной степенью формальности. Можно требовать детальной проработки и тщательного оформления каждого документа, предоставления столь же тщательно выполненной и оформленной рецензии и даже, следуя старой практике, утверждать каждую такую рецензию на научно-техническом совете предприятия. А можно ограничиться электронным письмом или наброском на бумаге. Кроме того, всегда остается еще одна возможность: сформировать документ в голове, то есть обдумать соответствующий вопрос и принять конструктивное решение. И если это решение касается только вас, то ограничиться, например, комментарием в коде программы.

Таким образом, RUP - итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки.

Подведем итоги второй части статьи. RUP, в отличие от большинства других методологий, позволяет в широком диапазоне выбирать степень формализации и итеративности процесса разработки в зависимости от особенностей проектов и разрабатывающей организации.

А почему это так важно - мы обсудим в следующей части.