Жизненный цикл и процессы разработки ПО

Группа стандартов CMM, разработанных SEI

• Модель зрелости возможностей CMM (Capability Maturity Model) [12,13] предлагает унифицированный подход к оценке возможностей организации выполнять задачи различного уровня. Для этого определяются 3 уровня элементов: уровни зрелости организации (maturity levels), ключевые области процесса (key process areas) и ключевые практики (key practices). Чаще всего под моделью CMM имеют в виду модель уровней зрелости. В настоящий момент CMM считается устаревающей и сменяется моделью CMMI (см. ниже).

  • Уровни зрелости.

    CMM описывает различные степени зрелости процессов в организациях, определяя 5 уровней организаций.

    • Уровень 1, начальный (initial).

      Организации, разрабатывающие ПО, но не имеющие осознанного процесса разработки, не производящие планирования и оценок своих возможностей.
    • Уровень 2, повторяемый (repeatable).

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

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

      В этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством.
    • Уровень 5, совершенствующийся (optimizing).

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

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

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

    Ключевые области процесса описываются с помощью наборов ключевых практик. Ключевые практики классифицированы на несколько видов: обязательства (commitments to perform), возможности (abilities to perform), деятельности (activities performed), измерения (measurements and analysis) и проверки (verifying implementations).

    Например, управление требованиями связано со следующими практиками:

    • Обязательство.

      Проекты должны следовать определенной политике организации по управлению требованиями.
    • Возможности.

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

      Требования должны быть документированы.

      Для управления требованиями должны быть выделены адекватные ресурсы и бюджет.

      Персонал должен проходить обучение в области управления требованиями.
    • Деятельности.

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

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

      Изменения в требованиях анализируются и включаются в проект.
    • Измерение.

      Производится периодическое определение статуса требований и статуса деятельности по управлению ими.
    • Проверки.

      Деятельность по управлению требованиями периодически анализируется старшими менеджерами.

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

      Группа обеспечения качества проводит анализ и аудит деятельности по управлению требованиями и отчитывается по результатам этого анализа.

  Таблица 2.4 суммирует информацию о количестве практик различных видов, приписанных к разным ключевым областям процесса.

  Таблица 2.4. Количество ключевых практик в разных областях процесса по CMM версии 1.1

  Уровни	Область процесса	Обязательства	Возможности	Деятельности	Измерения	Проверки
  2	Управление требованиями	1	4	3	1	3
  	Планирование проектов	2	4	15	1	3
  	Надзор за ходом проекта	2	5	13	1	3
  	Управление подрядчиками	2	3	13	1	3
  	Обеспечение качества ПО	1	4	8	1	3
  	Управление конфигурацией	1	5	10	1	4
  3	Контроль соблюдения технологического процесса	3	4	7	1	1
  	Выработка и поддержка технологического процесса	1	2	6	1	1
  	Обучение персонала	1	4	6	2	3
  	Интегрированное управление	1	3	11	1	3
  	Разработка программного продукта	1	4	10	2	3
  	Координация деятельности групп	1	5	7	1	3
  	Проведение экспертиз	1	3	3	1	1
  4	Управление процессом на основе метрик	2	5	7	1	3
  	Управление качеством ПО	1	3	5	1	3
  5	Предотвращение дефектов	2	4	8	1	3
  	Управление изменениями технологий	3	5	8	1	2
  	Управление изменениями процесса	2	4	10	1	2
• Интегрированная модель зрелости возможностей CMMI (Capability Maturity Model Integration) [14,14].

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

  Основные изменения по сравнению с CMM следующие.

  • Созданы два несколько отличающихся изложения модели — непрерывное и поэтапное. Первое предназначено для облегчения миграции от поддержки американского отраслевого стандарта EIA/AIS 713 и постепенного усовершенствования процессов за счет внедрения различных практик. Второе предназначено для облегчения миграции от поддержки CMM и поуровневого рассмотрения вводимых практик.
  • Элементы модели получили четкие пометки о том, являются ли они обязательными (required), рекомендуемыми (expected) или информативными (informative).
  • Используемые практики разделяются на общие (generic) и специфические (specific). Они дополняются набором общих и специфических целей, которые необходимы для достижения определенного уровня зрелости в определенных областях процесса.
  • Некоторые уровни зрелости получили другие названия. Второй уровень назван управляемым (managed), а четвертый — управляемым на основе метрик (quantitatively managed).
  • Набор выделяемых областей процесса и практик значительно изменился.

    Все области процесса делятся на 4 категории. В приводимом ниже списке области процесса помечены номером уровня, начиная с которого они должны поддерживаться согласно CMMI.

    • Управление процессом.

      Включает выработку и поддержку процесса (3), контроль соблюдения процесса (3), обучение (3), измерение показателей процесса (4), внедрение инноваций (5).
    • Управление проектом.

      Включает планирование проектов (2), контроль хода проекта (2), управление соглашениями с поставщиками (2), интегрированное управление проектами (3), управление рисками (3), построение команд (3), управление поставщиками (3) и измерение показателей результативности и хода проекта (4).
    • Технические.

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

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

В целом перечисленные стандарты связаны так, как показано на рис. 2.1 (сплошные стрелки указывают направления исторического развития, жирная стрелка обозначает идентичность, пунктирные стрелки показывают влияние одних стандартов на другие).

увеличить изображение
Рис. 2.1. Стандарты, описывающие структуру жизненного цикла ПО

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

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

Кроме того, данные стандарты не предписывают четких и однозначных схем построения жизненного цикла ПО, в частности, связей между отдельными деятельностями. Это сделано намеренно, поскольку ранее действовавшие стандарты типа DoD-Std-2167 были достаточно жестко привязаны к каскадной модели жизненного цикла (см. ниже) и тем самым препятствовали использованию более прогрессивных технологий разработки. Современные стандарты стараются максимально общим образом определить набор видов деятельности, которые должны быть представлены в рамках жизненного цикла (с учетом целей отдельных проектов — т.е. проект, не стремящийся достичь каких-то целей, может не включать деятельностей, связанных с их достижением), и описать их при помощи наборов входных документов и результатов.

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