Враг: предваряющий анализ

3.5 RUP – рациональный унифицированный процесс (Rational Unified Process)

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

Наиболее важный вклад RUP состоит в шести рекомендуемых практиках:

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

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

Модель жизненного цикла включает четыре фазы проекта:

• начальная стадия;
• уточнение;
• построение;
• внедрение.

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

Внедрение – это другое имя для этапа развертывания, который отсутствует в традиционных моделях, поскольку в 70-х годах программные системы были намного проще. Фактически это крайне важный этап любого серьезного проекта. Вообразите, что вы создаете систему для управления банковскими автоматами. Если вы не понимаете сложности развертывания системы на тысячах машин с дюжиной языков, в сотнях стран со своими ограничениями и правилами регулирования банковской деятельности, то вы, скорее всего, еще не вышли из пещерного века программирования. Отведение развертыванию достойной его роли – это один из вкладов RUP.

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

3.6 Модели зрелости

Модели зрелости, корнями уходя в модели жизненого цикла, переросли их, и занимаются более серьезными проблемами. Все начиналось в восьмидесятых–девяностых годах с введения стандарта ISO 9000 (International Standarts Organization) и программно-ориентированной модели CMM (Capability Maturity Model) – модели технологической зрелости. Эта модель была разработана по заказу министерства обороны США в Институте программной инженерии, размещенном в университете Карнеги Меллона^{2Модель должна была помочь заказчику оценить качество работ исполнителя, которому министерство предполагало заказать очередной проект.}. Позже модель CMM была расширена в семейство моделей, применимых к разнообразным индустриальным дисциплинам. Новая интеграционная модель технологической зрелости – CMMI и будет предметом дальнейшего обсуждения.

Предупреждение: если вы видели другие презентации CMMI, то, возможно, обнаружите разницу с описанием, представленным ниже. Официальная документация использует ужасную бюрократическую форму. То, для чего понадобились 482 страницы, могло бы быть объяснено на 30. Поэтому нет ничего удивительного, что CMMI отвергают не только сторонники agile, но и многие профессионалы. Я потратил много времени, чтобы пробиться к смыслу и осознать, что, несмотря на всю помпезность, CMMI фактически вводит полезные концепции. В следующем обзоре эти концепции изложены простым языком.

3.6.1 CMMI простым языком

CMMI представляет собрание лучших практик, специфицированных достаточно точно, чтобы помочь в достижении идентифицируемых целей и позволить оценить компетентность организации. Эти три понятия – практики, цели, оценки – являются сердцевиной подхода. (Более простым, но и более подходящим именем могло бы быть "Каталог Оценочных Практик" – КОП.)

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

Рассмотрим такую область процесса, как управление конфигурациями, которую можно определить как идентификацию и прослеживание различных элементов, связанных с процессом разработки, – программными модулями, тестовыми случаями, аппаратурой и так далее, чья эволюция может быть субъектом строгих правил. В управлении конфигурации:

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

Здесь есть только несколько универсальных целей. Примером является "процесс узаконен как управляемый процесс", используя термины, имеющие специальный смысл в контексте CMMI. Под управляемым процессом понимается процесс, который планируется в соответствии с четко установленной политикой, обслуживается подготовленным персоналом и является объектом мониторинга. Процесс "узаконен" (институализирован), если он не только используется на практике, но и полностью поддерживается организацией с четкими обязательствами. Универсальной практикой, поддерживающей эту универсальную цель, является "план процесса".

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

Третий главный аспект CMMI, дополняющий цели и практики, – это оценивание. Модель позволяет организации, разрабатывающей ПО, предоставлять оценку качества соответствующего процесса – процесса, а не продукта! Оценивается только эффект того, как продукт разрабатывается. Любое заключение о качестве того, что производится, должно выводиться неявно. Например, применение CMMI не гарантирует отсутствия дефектов, но позволяет оценить, существуют ли точные процедуры, позволяющие оценить качество продукта, обнаружение дефектов и их отслеживание. В CMMI есть два вида оценивания, каждый с соответствующей шкалой "технологичности" или "зрелости". Непрерывная шкала покрывает оценивание специфических процессных областей, ступенчатая версия оценивает общее состояние процессов организации. В этом обсуждении ограничимся ступенчатым вариантом. Его шкала определяет пять уровней зрелости организации, начиная с наименьшего уровня 1, где практически отсутствует наблюдение за процессами.

Вы не можете просто объявить миру, что ваша организация является CMMI уровня (для ). Для получения соответствующего статуса необходимо пройти аттестацию у независимого апробированного оценщика. При этом нельзя пропускать уровни; чтобы получить уровень , необходимо иметь уровень .

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

Последовательные уровни (каждый, начиная с уровня 2, включает свойства предшественников) отражают возрастающую степень понимания и управления процессами в организации.

1. Начальный. Уровень, обычно описываемый в текстах CMMI в отрицательных тонах, напоминающий описание в agile текстах процессов, не принадлежащих миру agile: "процессы обычно нерегламентированные и хаотические. Успех зависит от компетентности и героизма работников. Проверенные процессы не используются".
2. Управляемый. Для проектов определены процессы, поддержанные адекватными ресурсами и обязательствами сопричастников.
3. Определенный. Процессы строго определены соответствующими документами, процедурами и поддержаны инструментарием. Спецификации существуют на уровне всей организации, так что, если процессу потребуется собственный вариант, он будет взят из общей базы.
4. Управляемый на основе количественных данных. В процессах используются численные критерии качества и производительности, оценка производится на основе статистических методов контроля.
5. Оптимизируемый. Процессы включают механизмы собственной оценки и непрерывного улучшения (процессы с обратной связью).

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

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

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

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

3.6.2 Персональный программный процесс

Применять CMMI имеет смысл для организаций, более того, на практике отдача может быть ощутимой для больших организаций. Уотс Хэмфри, бывший менеджер IBM, внесший большой вклад в CMMI, осознал необходимость переноса основных идей CMMI – систематическое применение признанных практик – в рекомендации, позволяющие применять эти практики каждому программисту на уровне его или ее индивидуальной работы вне зависимости от того, сертифицирована его компания или нет. Результатом его усилий стало появление модели PSP – Personal Software Project (ППП – персональный программный проект). Хэмфри ввел также TSP – Team Software Project – модель для команд.

PSP и TSP не получили широкого отклика, если не считать отрицательных, как обычно, отзывов в agile, но основные идеи заслуживают внимания. Кажется, что с самого начала стоит отвергнуть PSP, поскольку предлагается вышедшая из моды последовательная модель жизненного цикла: план–проект–код–компиляция–тестирование–анализ. Если не считать последней фазы и (сторонники agile, на секунду закройте глаза) первой, то мы не работаем уже по такой схеме. Но главный вклад PSP состоит в другом и не связан с конкретной технологией. Программисту предлагается работать в традициях инженеров: вести журнал событий, делать записи времени работы, записи ошибок и применять статистические методы количественного контроля. Эти советы широко не применяются, зачастую не известны в индустрии. Сегодня в меняющемся технологическом мире изучение PSP полезно для любого программиста.

3.6.3 CMMI/PSP и agile методы

Никаких фундаментальных противоречий между agile и CMMI (или PSP, если речь идет о его лучших качествах, только что отмеченных) не существует. Agile методы предписывают некоторые процессы и практики. CMMI требует, чтобы организация формализовала (кодифицировала) эти процессы и практики, не уточняя, какими они должны быть, и agile варианты могут использоваться наравне с другими.

Общее ощущение различно: CMMI и agile часто рассматриваются как несовместимые сущности (подобно воде и нефти). Культуры двух сообществ действительно различаются. Одно фокусируется на управлении, планировании, документах. Другое – отрицает все эти "затраты", отдавая пальму первенства коду и тестам. Ориентированные на планы части CMMI действительно с трудом могут быть приняты сторонниками agile, но большинство практик допускают согласование. Поппендик, критикуя CMMI, называет две главные причины:

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

CMMI подходит не для всех. Введение CMMI требует определенной решимости, обычно диктуемой нормативными обязательствами или коммерческими интересами в получении сертификата определенного уровня. Возможно, этот кафтан не по вашим плечам. Но если это так и вы находите некоторые agile идеи привлекательными, то возможно комбинирование идей от обеих школ. Существуют отчеты об успешных опытах, один из них, опубликованный Сазерлендом [Sutherland 2010], посвящен использованию Scrum в рамках CMMI уровня 5.

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

3.6.4 Шкала зрелости agile

Предсказуемо, что появились публикации, предлагающие "шкалу зрелости agile", содержащую пять уровней, хотя одна из публикаций датирована 1 апреля. Все они напоминают попытку сказать: "Мы тоже зрелые и можем иметь пять уровней, если захотим". (Обзорная статья [Shweigert 2012], первоапрельская – [Ambler 2010].)

Хотя шкала оценивания является наиболее обсуждаемым аспектом CMMI, это только один из трех важных компонентов наряду с целями и практиками. Agile методы имеют свои собственные практики и цели. Хотя не существует организации, осуществляющей сертификацию agile проектов на соответствие принципам, существует сертификация личностей, например, можно получить сертификат Scrum Master.

Методы agile имеют собственную трехуровневую шкалу, которую можно считать двойником CMMI. Эта шкала получила название Shu–Ha–Ri (или Shuhari), термин, пришедший из японского боевого искусства и обозначающий уровни обучения мастерству. В agile командах так характеризуется уровень мастерства владения методом:

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

Можно вспомнить другую трехуровневую шкалу: бакалавр–магистр–PhD^{3В России эта шкала, скорее, шестиуровневая: бакалавр–магистр–кандидат наук–доктор наук–член-корреспондент–академик).}, лишенную, правда, экзотической привлекательности японских слов Shu–Ha–Ri. (В образовательных кругах подобные идеи лежат в основе популярной пятиуровневой шкалы в модели Дрейфуса^{4Пять стадий обучения в модели Дрейфуса: новичок–продвинутый новичок–компетентный специалист–профессионал–эксперт.}.)

Параллель с уровнями CMMI ясна; в частности, последний уровень в Shu – Ha – Ri соответствует уровню 5 – "оптимизация" – в CMMI.