SW-CMM описывает пять уровней зрелости (maturity levels) no возрастанию эффективности процессов разработки ПО. Организации уровня зрелости 1 обычно проводят свои проекты неформально и непоследовательно. Они достигают успеха в основном за счет героических усилий талантливых исполнителей и менеджеров. Организации более высоких уровней зрелости сочетают действия способных, творческих и подготовленных людей с соответствующими технологическими процессами конструирования ПО и управления проектами, последовательно добиваясь успеха в создании ПО.
Для достижения уровня 2 в SW-CMM организация должна продемонстрировать, что достигла заявленных целей в шести ключевых областях процессов (key process areas) разработки и управления ПО (табл. Б-1). SW-CMM описывает несколько ключевых приемов (key practices), помогающих командам, работающим над проектами, достигать каждого набора целей, сгруппированных по действиям, которые необходимо предпринять, предварительным условиям выполнения работы, признакам серьезности намерений организации и приемов подтверждения и измерения производительности. Управление требованиями, выделенное жирным шрифтом в табл. Б-1, — это одна из шести ключевых областей технологических процессов на уровне 2. У нее две цели (Paulk и др., 1995):
· системные требования, размещенные по ПО, направляются для создания основной версии, используемой в конструировании и управлении ПО;
· поддерживается соответствие планов, действий и продуктов, получаемых в результате разработки ПО, с системными требованиями, размещенными для ПО.
Таблица Б-1. Структура the Capability Maturity Model for Software
| Уровень зрелости | Название | Ключевые области процессов |
| Первоначальный | (нет) | |
| Повторяемый | Управление требованиями Планирование проекта по разработке ПО Трассирование и контроль проекта по разработке ПО Управление субконтрактами по разработке ПО Проверка качества ПО Управление конфигурацией ПО | |
| Определенный | Экспертные оценки Координация работы между группами Конструирование ПО Интегрированное управление разработкой ПО Программа обучения Концентрация сотрудников организации на процессе Определение процесса организацией | |
| Управляемый | Управление качеством ПО Количественное управление процессом | |
| Оптимизирующий | Предотвращение дефектов Управление изменениями процесса. Управление изменениями технологий |
|
|
Вне зависимости от своих знаний и отношения к SW-CMM, большинство организаций-разработчиков ПО выиграют от достижения этих двух целей. SW-CMM выявляет несколько предпосылок и технических приемов, позволяющих последовательно достигать этих целей. Тем не менее она не предписывает, какими конкретно технологическими процессами управления требованиями организация должна пользоваться..
Ключевые области процессов управления требованиями не включают сбор и анализ требований к проекту. Предполагается, что требования для ПО уже были собраны или размещены на основе системных требований более высокого уровня (отсюда фраза «системные требования, размещенные для ПО»). Эта ситуация отражает происхождение СММ — изначально она предназначалась для правительственных организаций (в основном, для министерства обороны), нанимающих подрядчиков для производства сложных систем, включающих и оборудование, и ПО.
|
|
После того как требования получены и документированы, группа разработчиков ПО и все, кого это касается, например группа проверки качества и группа тестирования, просматривают их. Найденные проблемы разрешаются при участии клиентов или других источников требований. Менеджер проекта создает план разработки ПО на основе утвержденных требований. Группа разработчиков должна согласиться с требованиями и выявить любые ограничения, факторы риска, возможные непредвиденные обстоятельства или невысказанные предположения прежде, чем давать какие-либо обязательства клиентам, менеджерам или другим заинтересованным в проекте лицам. На вас могут оказывать давление, чтобы вы приняли требования, не выполнимые технически или по срокам, но не давайте обязательств, которых не сможете выполнить.
Ключевые области процессов также рекомендуют, какими документами требований следует управлять посредством приемов контроля версий и контроля изменений. Контроль версий гарантирует, что известна версия требований, которая используется при разработке и планировании. Контроль изменений обеспечивает организованное внесение изменений в требования, при котором учитываются хорошие бизнес- и технические решения о том, принимать ли предложенные изменения или отказаться от них. По мере модификации, добавления или удаления требований в процессе разработки важно обновлять план разработки ПО, чтобы он соответствовал новым требованиям. Планы, не отражающие текущую ситуацию, не могут с пользой направлять ваш проект.
|
|
В отличие от управления требованиями, разработка требований не стала отдельной ключевой области процессов в SW-CMM. На мой взгляд, это — крупный недостаток модели Большинству организаций сложнее выявлять и составлять хорошие требования, чем управлять имеющимися требованиями, какими бы они ни были. О разработке требований говорится в единственном ключевом приеме работы в ключевой области технологических процессов, «Конструирование ПО» на уровне 3 (выделена в табл. Б-1). Действие 2 этой области звучит так: «Требования для ПО разрабатываются, сопровождаются, документируются и проверяются посредством систематического анализа размещенных требований согласно определенному в проекте процессу». Это действие описывает приемы разработки требований, подобные описанным в данной книге, в том числе:
· анализ требований на осуществимость и другие желательные качества;
· документирование требований;
· проверка документации требований с участием представителей;
· клиентов;
· определение того, как будет проверяться и утверждаться каждое требование.
Трассирование требований также включено в уровень 3 SW-CMM. Действие 10 ключевой области «Конструирование ПО» сформулировано так: «Поддерживается соответствие между различными продуктами работы над ПО, включающими планы разработки ПО, описания технологических процессов, размещение требований, программные требования, программные конструкции, код, планы и процедуры тестирования». Подразделы этого действия включают конкретные указания о том, как следует выполнять трассирование требований в организации.
Даже если вы не используете SW-CMM в качестве руководства для действий по совершенствованию, принципы и приемы, приведенные в ключевых областях процессов управления требованиями и конструирования продукта ПО, весьма разумны. Каждая организация-разработчик ПО может выиграть от их продуманного применения.
CMMI-SE/SW
Модель интеграции СММ сочетает технологические процессы для систем и конструирования ПО. CMMI-SE/SW имеет две формы. Ступенчатое представление (the staged representation) аналогично структуре SW-CMM и включает пять уровней зрелости, содержащих 22 области технологических процессов, показанных в табл. Б-2 (CMU/SEI, 2000а) Другая форма — это непрерывное представление (continuous representation) (подобное устаревшей SE-CMM), группирующей те же 22 области технологических процессов по четырем категориям: управление процессами, управление проектами, конструирование и поддержки (CMU/SEI, 2000b). В непрерывном представлении общие уровни зрелости не определяются. Вместо них определяются шесть уровней способностей (capability levels) для каждой области технологических процессов. Непрерывное представление CMMI-SE/SW позволяет каждой организации решать, какой уровень способностей ей соответствует в каждой из 22 областей технологических процессов. Например, вы можете решить, что должно быть на уровне 4 (количественно управляемый) для разработки требований и на уровне 3 (определенный) для управления требованиями. Содержимое областей процессов одинаково в обоих представлениях.
Как и the Capability Maturity Model for Software, в CMMI-SE/SW на уровне 2 имеется область, именуемая «Управление требованиями», но также в ней на уровне 3 есть и отдельная область «Разработка требований». Размещение этой области на уровне 3 не подразумевает, что требования для проектов организации, не достигших уровня 2, собирать и документировать не нужно. Конечно же, это следует делать для каждого проекта. Управление требованиями рассматривается как способ, помогающий создавать более предсказуемые и менее хаотичные проекты, что составляет сущность уровня 2 СММ. Приняв порядок управления изменениями и проверки статуса требований, организация может больше внимания уделять разработке высококачественных требований.
Это разумный аргумент, но с другой стороны, не важно, насколько эффективно вы управляете плохими, ошибочными или несуществующими требованиями. Организации — разработчики ПО, озабоченные повышением эффективности, будут работать над теми аспектами разработки и управления требованиями, которые доставляют им больше всего проблем, вне зависимости от структуры the Capability Maturity Model.
Таблица Б-2. Структура CM Ml-SE/SW, ступенчатое представление