Опубликован: 04.04.2012 | Доступ: свободный | Студентов: 1988 / 60 | Оценка: 4.60 / 4.40 | Длительность: 13:49:00
Лекция 11:

Технологии инженерии программ

Модели способностей и зрелости

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

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

В начале 90-х годов необходимость объективной оценки программистских фирм возникла у Министерства обороны Соединенных Штатов — крупнейшего заказчика ПО для своих нужд. Для решения этой задачи Институту программной инженерии Университета Карнеги-Меллона был сделан заказ на разработку модели, определяющей уровень зрелости программистских фирм. Разработанная ими модель получила название "Capability Maturity Model" (акроним CMM), а позже модель была расширена и стала называться CMMI-моделью — "интеграционная модель зрелости и способностей". Эта модель оказала существенное влияние на некоторые сегменты рынка ПО, в частности:

  • на оборонные контракты МО США — ее первого заказчика;
  • программистские компании Индии, которые увидели в получении внешних сертификатов CMM (CMMI) возможность независимого подтверждения их зрелости, что открывало им дорогу на мировые рынки.

Модель CMMI используется и вне этих сообществ. Доля организаций, работающих с оборонными заказами и сертифицированных по CMMI, неуклонно сокращается, в 2004 году она составляла 40%1 Российские компании, работающие на оффшорном рынке, также сертифицируются по CMMI, например, компания VDI.

Некоторые компании в поисках процесса улучшения организации работ и квалификации предпочитают другие модели. Серия стандартов 9000 ISO также устанавливает международные стандарты качества. Стандарт SPIQE комбинирует элементы предыдущих двух стандартов. В этом обзоре рассматривается только CMMI.

Область действия CMMI

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

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

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

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

CMMI-дисциплины

Как указывает буква "I" в акрониме (Integration), CMMI пошла дальше CMM для того, чтобы расширить сферу воздействия на модели, отличные от программных. Четыре дисциплины кроме инженерии программ включают также:

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

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

Цели, практики и области процессов

Основа CMMI — определение целей и рекомендуемых практик.

  • Целью является достижение желаемого свойства процесса. Например, каждый проект должен иметь хорошие требования, описывающие потребности пользователей. Из этого выводимы две цели: "Разработка требований заказчиков" и "Анализ и проверка правильности требований". Недостаточно просто создать требования, должна быть формальная процедура проверки их реализуемости и проверки того, что они удовлетворяют всех сопричастников.
  • Практика — это метод, помогающий в достижении цели. Примерами являются "Задать определение требуемой функциональности" и "Проанализировать требования для установления баланса между потребностями сопричастников и ограничениями проекта".

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

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

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

Две модели

CMMI существует в двух вариантах — ступенчатом, или поэтапном, и непрерывном.

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

Общим для обоих вариантов является понятие уровня оценивания. В поэтапном варианте организация получает оценку от 1 до 5 (как в школе). Чем выше оценка, тем выше уровень контроля процессов. В непрерывном варианте оценивается каждая область, здесь добавляется уровень 0, свидетельствующий о том, что организация не занимается этой конкретной областью процессов.

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

Как следствие этих концепций, цели и практики разделяются на две категории.

  • Родовые: характеризующие CMMI-уровень, но не принадлежащие какой-либо области процесса.
  • Те, что принадлежат области процесса, называемые специфическими.

Уровни оценивания

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

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

Следующая таблица более точно описывает, что должно достигаться на каждом уровне (начиная со 2-го, поскольку по определению на уровне 1 нет точных требований).

Уровень Имя Области процессов
2 Управляемый
  • Управление требованиями
  • Планирование проекта
  • Мониторинг проекта и управления
  • Управление соглашениями с поставщиками
  • Измерения и анализ
  • Страхование качества процесса и продукта
  • Управление конфигурацией
3 Определенный
  • Разработка требований
  • Технические решения
  • Интеграция продукта
  • Верификация
  • Проверка правильности
  • Выделение организационного процесса
  • Определение организационного процесса
  • Организационный тренинг
  • Управление интегрированным проектом
  • Управление рисками
  • Интегрированная команда
  • Интегрированное управление поставщиками
  • Анализ решений и выводы
  • Организационное окружение для интеграции
4 Количественно управляемый
  • Производительность организационного процесса
  • Количественное управление проектом
5 Оптимизирующий
  • Организационные инновации и развертывание
  • Анализ причин и выводы

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

Надежда Александрова
Надежда Александрова

Уточните пожалуйста, какие документы для этого необходимо предоставить с моей стороны. Курс "Объектно-ориентированное программирование и программная инженения".