Ключевые моменты.

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

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

А Наличие зрелого процесса оказывается более важным, чем простое прохождение проверок.

А Зрелому процессу не страшны внезапные проверки. Если организация говорит, что она делает, и делает, что говорит, нет никакой необходимости специально готовиться к проверкам.

Е.1 ОБЩИЙ ОБЗОР СММ.

В СММ определены пять уровней зрелости процесса создания ПО, основанных на том, какие конкретные «ключевые» области процесса (Key Process Area, КРА) поддерживаются организацией. Уровень 1 (самый низший) соответствует организации с незрелым или неописанным.

процессом. Уровень 2 (воспроизводимый), уровень 3 (определенный), уровень 4 (управляемый) и уровень 5 (оптимизированный) описывают организации с более высокими уровнями зрелости процесса создания ПО. КРА, соответствующую каждому из этих уровней, можно охарактеризовать следующим образом:.

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

■ КРА уровня 3: большое внимание процессу организации, определение процесса организации, программа обучения, интегрированное управление созданием ПО, разработка программных продуктов, координация между группами, визуальные проверки.

ш КРА уровня 4: измерение и анализ параметров процесса, управление качеством, предотвращение появления дефектов.

■ КРА уровня 5: нововведения в технологию, управление изменением процесса.

Целью большинства организаций является достижение процесса уровня 3. Для определения зрелости организации используется оценка возможностей ПО (Software Capability Evaluation, SCE). SCE позволяет выяснить, действительно ли организация «говорит то, что она делает, и делает то, что говорит», посредством оценки процесса создания ПО, используемого в данной организации (обычно в виде отдельных положений, определяющих политику), и практики выполнения проектов. Политика организации — «говорит, что она делает» — и реализация проектов — «делает то, что говорит» — оцениваются по соответствующей КРА-схеме. Процесс оценки не является совершенным, однако он может служить хорошим относительным показателем зрелости процесса создания ПО.

Для типичной SCE в качестве одной из частей тщательной проверки применяется SEI Maturity Questionnaire («Вопросник для определения зрелости») [SEI, 1998]. Это определение зрелости включает в себя подробный анализ, интервью и другие формы оценки. Данный вопросник, вообще говоря, используется в качестве отправной точки для создания контекста, в котором будет производиться оценка.

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

Одним из главных недостатков SEI СММ является то, что КРА ориентируются прежде всего на документальные рабочие продукты традиционного процесса (такие, как проект, требования и документы, определяющие соответствие требованиям), а также на контракты, контракты субподряда, планы и отчеты. Очень немногие КРА реально обращаются к изменяющимся рабочим продуктам, касающимся разработки (модели требований, проектные модели, исходный код или выполняемый код), к.

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

Таблица Е.1.

Распределение по уровням зрелости в индустрии ПО

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

■ Уровень 1 соответствует случайному (непредсказуемому) выполнению.

■ Уровень 2 позволяет достигать воспроизводимого выполнения от проекта к проекту.

■ Уровень 3 демонстрирует улучшение выполнения следующих друг за другом проектов в терминах затрат, сроков или качества.

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

■ Уровень 5 соответствует идеальному выполнению следующих друг за другом проектов или существенному улучшению сразу всех параметров. Организации уровня 5 обычно занимают очень узкую нишу.

На рис. Е.1 показано ожидаемое выполнение следующих один за другим проектов в организациях с различным уровнем зрелости.

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

Рис. Е.1. Ожидаемое выполнение проектов для различных уровней зрелости СММ.

■ Объективное понимание текущей зрелости.

■ Объективное понимание выполнения проекта в терминах затрат и сроков, поддающихся количественному выражению.

■ Реальное улучшение выполнения проекта.

■ Минимальное время, необходимое для подготовки к проведению оценки.

Зрелая организация и зрелые проекты понимают процесс и следуют ему. Им не приходится тратить время на подготовку к проверке. Если вы думаете, что ваша организация соответствует уровню 3, то ответьте на такой вопрос: сможет ли она выдержать внезапную проверку?.

Е.2 ПРАКТИЧЕСКОЕ УЛУЧШЕНИЕ ПРОЦЕССА.

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

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

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

■ Метрики ПО. Объективные измерения, необходимые для оценки качества программного продукта и прогресса в работе, — это два взгляда под различными углами зрения на создание ПО. Разработчики архитектуры больше интересуются показателями качества, в то время как менеджерам обычно нужны показатели прогресса. Успех любого процесса создания ПО, в котором значения метрик собираются вручную, будет ограниченным. Большинство самых важных метрик ПО — это простые, объективные измерения того, каким образом продукт/проект изменяется с различных точек зрения. Измерение абсолютных значений обычно менее важно, чем измерение относительных изменений в зависимости от времени. Из-за динамичного характера проектов по созданию ПО эти измерения должны быть доступны в любое время, необходима возможность их адаптации для ■ различных составных частей постоянно изменяющегося продукта (подсистемы, версии, компонента, команды), и они должны содержаться в таком виде, чтобы можно было оценить тенденции (первую и вторую производные). Постоянная доступность была достигнута на практике только тогда, когда метрики стали поддерживаться в онлайновом режиме в качестве автоматизированного побочного продукта среды разработки.

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

■ Процесс в сравнении с методом. Процесс управления проектом имеет дело с иными понятиями, нежели технический метод. Первый характеризуется итерационной разработкой, основанными на демонстрациях оценками и управлением рисками; второй — объектно-ориентированными методами, подходами к архитектуре и UML-представлениями. Плохое управление процессом, вероятно, никогда не сможет быть спасено с помощью хорошего метода, а вот хорошее управление процессом, скорее всего, приведет к успеху при использовании большинства технических методов. Понятно, что одни методы лучше других. Результат, который получается с помощью хорошего метода разработки, совмещенного с хорошим процессом управлением, — абсолютен. Это — основная цель.

Е.З ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ.

Ниже обсуждается подход к процессу, представленному в настоящей книге, с точки зрения SEI СММ. «Вопросник для определения зрелости» SEI [SEI, 1998] использовался мной в качестве сценария для оценки степени завершенности подхода к процессу с общепринятой точки зрения на зрелость процесса. Каждый цитируемый вопрос выделяется курсивом, а за ним следует мой ответ со ссылками на материалы, различные виды работ и контрольные точки процесса.

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

Управление требованиями, уровень 2.

1.

Используются ли ваши системные требования, относящиеся к ПО, в качестве базы для разработки и управления проектом?.

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

2.

Вносятся ли необходимые уточнения в планы, рабочие материалы и виды деятельности по мере изменения требований, относящихся к ПО?.

▲ При итерационной разработке каждая новая итерация сопровождается новыми спецификациями версии и соответствующим обновлением технических рабочих продуктов. Назначением запросов на внесение изменений в ПО (SCO) типа 3 и является обращение к необходимым изменениям, вызванным изменением требований.

3.

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

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

4.

Обучался ли персонал, ответственный за управление требованиями, методам управления требованиями ?.

А Обучение зависит от конкретной организации.

<.

5.

Используются ли измерения, проводимые для onpedejieuua состояния, работ, при управлении требованиями (например, общее число изменений требований, которые предложены, открыты, приняты и внесены в базовую версию)?.

A SCO типа 3 должны отслеживаться и учитываться при периодических оценках состояния.

6.

Подвергается ли деятельность по управлению требованиями проверкам на подтверждение качества ПО (Software Quality Assurance, SQA)?.

А Контроль качества является обязанностью всех команд. Независимая организация, которая выполняет тестирование и на которую возлагается основная ответственность за обеспечение качества, просто не рассматривает вопросы управления требованиями; она активно участвует в создании спецификаций версии и в обеспечении ее соответствия набору требований. Совет по контролю за конфигурацией (Configuration Control Board, ССВ) также рассматривает изменения требований, содержащиеся в SCO. Кроме того, комплект рабочих продуктов требований применяется при осуществлении разработки, связанной с усовершенствованием моделей вариантов использования, комплекта рабочих продуктов проектирования, комплекта рабочих продуктов реализации и при демонстрациях комплекта рабочих продуктов внедрения.

Планирование проекта по созданию ПО, уровень 2.

1. Документируются ли оценки (размера, стоимости и сроков) для использования при планировании и для контроля за ходом выполнения проекта ?.

A WBS определяет базовую стоимость и план. Бизнес-план и план разработки ПО определяют приблизительный график, содержание итерации и приблизительные размеры с различных точек зрения. Оценки состояния являются механизмом, позволяющим отслеживать прогресс и качество по сравнению с базовыми планами и их уточнениями. На более низких уровнях в SCO отражаются подробные оценки, планы и реальное положение вещей.

2.

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

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

3.

Согласны ли все группы и лица, к которым это имеет отношение, со своими задачами, касающимися проекта по созданию ПО?.

А Декомпозиция работ (WBS) предоставляет механизм для проведения переговоров о поручениях между менеджером проекта и подчиненными ему менеджерами. SCO и ССВ обеспечивают механизм для ведения переговоров о поручениях более низкого уровня.

4.

Следует ли проект политике организации при планировании работ по созданию ПО?.

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

5.

Обеспечено ли планирование проекта по созданию ПО адекватными ресурсами (т.е. финансированием и опытным персоналом)?.

а Менеджер проекта по созданию ПО, ответственный за план, создает его и отвечает за его успех. Этот бизнес-план содержит ожидания и поручения, необходимые организации для определения отдачи от инвестиций по каждому виду работ. Адекватность ресурсов для планирования не определяется политикой. Хорошей отправной точкой может служить цифра 10% — приблизительно такая часть ресурсов проекта должна быть направлена на планирование и работы по управлению. Определение адекватных ресурсов специфично для каждого проекта. Эти оценки должны стать предметом тщательного изучения PRA и должны пересматриваться по достижении всех основных контрольных точек.

6.

Используются ли измерения для определения состояния работ по планированию проекта по созданию ПО (т.е. завершенности этапов работ по планированию) ?.

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

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

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

Отслеживание и контроль за выполнением проекта по созданию ПО, уровень 2.

1.

Сравнимы ли реальные показатели выполнения проекта (сроки, размеры и затраты) с оценками, содержащимися в планах по созданию ПО?.

А Оценки состояния позволяют сравнивать планируемые результаты с реальными по показателям прогресса. Описания версий дают возможность сравнивать планируемые показатели качества (критерии оценки) с реально полученными результатами. В SCO также содержатся сравнения планируемых и реально полученных результатов для детального управления изменениями.

2.

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

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

3.

Согласовываются ли изменения в распределении обязанностей со всеми заинтересованными группами и лицами ?.

А Изменения в распределении обязанностей обсуждаются при изменении WBS, планов разработки ПО и оценок состояния. Поручения более низкого уровня также рассматриваются ССВ, отслеживаются по SCO и отражаются в описаниях версий.

4.

Следует ли проект политике организации по отслеживанию и контролю за деятельностью по разработке ПО?.

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

5.

Существует ли в рамках проекта лицо, на которое возложена особая ответственность за отслеживание продуктов и работ по созданию ПО (например, трудозатрат, сроков и финансирования)?.

А Таким ответственным лицом является менеджер проекта по созданию ПО. Оценки состояния предоставляют механизм, гарантирующий периодические рассмотрения и отчетность в соответствие с основой WBS.

6.

Используются ли измерения для определения состояния работ по отслеживанию и контролю за ПО (например, суммарных трудозатрат на выполнение работ по отслеживанию и контролю)t.

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

7.

Рассматриваются ли работы по отслеживанию и контролю за ходом выполнения проекта вышестоящим руководством на регулярной основе (например, ход выполнения проекта, нерешенные проблемы, риски и необходимые действия)?.

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

Управление субподрядчиками по созданию ПО, уровень 2.

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

1.

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

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

2.

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

А Здравый смысл подсказывает, что это всегда должно быть именно так.

3.

Производится ли регулярный обмен технической информацией с субподрядчиками ?.

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

4.

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

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

5.

Следует ли проект политике организации по работе с субподрядчиками ?.

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

6.

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

А Обучение зависит от конкретной организации.

7.

Используются ли измерения состояния работ для управления субподрядом по созданию ПО (например, соответствие срокам с учетом дат планируемых поставок и трудозатрат, израсходованных на управление субподрядом)?.

А Субподрядчики должны управляться точно так же, как генеральный подрядчик.

8.

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

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

Подтверждение качества ПО, уровень 2.

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

1.

Планируются ли работы по SQA ?.

А В плане разработки ПО описываются работы по тестированию, определению метрик и деятельность по контролю качества. В WBS содержатся многие детали плана. Спецификации версий также являются механизмом для планирования деятельности по SQA.

2.

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

А Спецификации версии указывают цели конкретной итерации. Планы разработки ПО определяют стандарты и процедуры выполнения проекта. В спецификациях версии описывается также качество промежуточных продуктов относительно объективных критериев по принципу соответствует/не соответствует. ССВ и SCO гарантируют, что процедуры и стандарты более низкого уровня проверяются и отслеживаются. На автоматизированные инструменты среды (компиляторы, создание документации, управление изменениями) должно быть возложено подтверждение того, что продукты точно соответствуют применяемым в данном случае стандартам.

3.

Передаются ли результаты SQA-рассмотрений и проверок заинтересованным группам и лицам (например, тем, кто выполнял работу, или тем, кто отвечает за ее выполнение)?.

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

4.

Рассматриваются ли случаи несоответствия стандартам, которые не региены в рамках проекта, вышестоящим руководством (например, отклонения от применяемых стандартов)?.

а Это является одной из прямых задач утверждения планов разработки и оценок состояния со стороны PRA (Project Review Authority). Регулярные PRA-рассмотрения касаются любых предполагаемых отклонений от политики организации по мере прогресса проекта.

5.

Следует ли проект политике организации по реализации SQA ?.

А Политика организации и планы разработки ПО должны обеспечивать SQA-политикой организацию и проект соответственно.

6.

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

А Адекватность ресурсов, выделяемых на SQA, не определяется политикой. Хорошей контрольной цифрой являются 25% от всех работ в рамках проекта, направляемых на работу команды по выполнению оценок (тестирование, оценка, метрики, ССВ). Несмотря на то, что адекватность ресурсов специфична для каждого конкретного проекта, эти оценки, очевидно, должны выполняться под тщательным контролем PRA.

7.

Используются ли измерения для определения затрат и сроков по работам, связанным с SQA (например, объем завершенных работ, трудозатраты и финансовые затраты по сравнению с запланированными)?.

А Основа содержится в WBS, а периодические оценки Состояния позволяют отслеживать реальность по сравнению с планами для всех видов деятельности.

8.

Рассматриваются ли работы по SQA совместно с вышестоящим руководством на регулярной основе ?.

А Это одна из основных задач PRA-рассмотрений и PRA-утверждения плана разработки ПО.

Управление конфигурацией ПО, уровень 2.

Все виды деятельности и весь персонал вовлекаются в управление конфигурацией ПО (Software Configuration Management, SCM) точно так же, как в SQA. Независимая команда, выполняющая оценку, принимает на себя основную ответственность за деятельность по управлению конфигурацией, включая сопровождение базы данных SCO, администрирование ССВ и управление базовой версией. Эти виды работ должны выполняться параллельно (для экономии времени) и независимо (для разнообразия технических точек зрения). Вообще говоря, действия по SCM выполняются всеми разработчиками ПО и поддерживаются прежде всего средой разработки ПО. Для ответов на эти вопросы деятельность независимой команды по оценке максимально приближена к определению SCM, принятому в СММ.

1.

Были ли запланированы работы по управлению конфигурацией в рамках проекта?.

А План разработки ПО автоматически должен содержать и поддерживать работы по SCM.

2.

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

A SCO и все рабочие продукты находятся под управлением конфигурацией.

3.

Следует ли проект зафиксированной процедуре контроля над изменениями, вносимыми в элементы/модули конфигурации?.

a SCO обеспечивают механизм контроля над изменениями в онлайновом режиме, как это записано в политике организации и в плане разработки ПО.

4.

Распространяются ли среди заинтересованных групп и лиц стандартные отчеты по базовым версиям ПО (например, протоколы заседания ССВ, обзор запросов на внесение изменений, отчеты о состоянии)?.

А Оценки состояния, которые содержат в себе результаты работы ССВ в виде стандартных параметров, должны быть доступны для всех заинтересованных сторон и команд проекта.

5.

Следует ли проект политике организации в области реализации работ по управлению конфигурацией ПО?.

А Это обеспечивается политикой организации и планами разработки ПО.

6.

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

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

7.

Используются ли измерения для определения состояния работ по управлению конфигурацией ПО (например, затраты труда и финансов на работы по управлению конфигурацией ПО)?.

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

8.

Производятся ли регулярные проверки на соответствие базовых версий ПО и их документации (например, SCM-группой)?.

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

Наиболее важные аспекты процесса, используемого в организации, уровень 3.

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

А Все планы по разработке и оценке состояния рассматриваются и утверждаются органом, ответственным за процесс разработки ПО (Software Engineering Process Authority, SEPA). Эти механизмы обеспечивают координацию и непротиворечивость в рамках организации.

2.

Регулярно ли оценивается процесс создания ПО в вашей организации ?.

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

3.

Следует ли ваша организация документированному плану разработки и усовершенствования своего процесса создания ПО?.

A SEPA должен документировать этот план и приложить его к политике организации.

4.

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

А Степень участия вышестоящего руководства в этой деятельности легко определить по составу группы SEPA и по деталям политики организации. Другим показателем участия руководства является та степень, с которой процесс, используемый в данной организации, поддерживается посредством капиталовложений в автоматизацию.

5.

Несет ли отдельное лицо или группа лиц полную или частичную ответственность за процесс создания ПО, используемый в данной организации (например, группа по разработке процесса создания ПО)?.

А Эта ответственность возлагается на SEPA. Состоит ли данный орган из одного человека, работающего по совместительству, или это команда, занимающаяся только этим вопросом, зависит от специфики организации.

6.

Применяются ли измерения для определения состояния деятельности по разработке и усовершенствованию процесса создания ПО, используемого в данной организации (например, объем трудозатрат на оценку и усовершенствование процесса создания ПО)?.

а Политика организации должна учитывать R0I для SEPA-деятельности и периодически обновляться.

7.

Регулярно ли деятельность по разработке и совершенствованию процесса создания ПО рассматривается вышестоящим руководством ?.

А Следует обращаться к генеральному менеджеру организации для утверждения всех текущих изменений в политике организации.

Определение процесса, используемого организацией, уровень 3.

1. Разработан и поддерживается ли вашей организацией стандартный процесс создания ПО?.

А Политика организации определяет стандарт процесса создания ПО, который периодически обновляется.

2.

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

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

3.

Следует ли организация заданной политике в области разработки и поддержки своего стандартного процесса создания ПО?.

А Политика организации определяет стандарт процесса и его поддержку.

4.

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

А Обучение зависит от конкретной организации.

5.

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

А Информация о R0I от деятельности SEPA должна храниться в виде приложения к политике организации.

6.

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

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

Программа обучения, уровень 3.

1.

Планируется ли деятельность по обучению?.

А Обучение зависит от конкретной организации. .

2.

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

А Обучение зависит от конкретной организации.

3.

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

А Обучение зависит от конкретной организации.

4.

Следует ли ваша организация заданной политике для удовлетворения ее собственных нужд в обучении?.

А Обучение зависит от конкретной организации.

5.

Выделяются ли достаточные ресурсы на реализацию программы обучения, принятой в организации (например, финансирование, программный инструментарий, соответствующие условия для обучения)?.

А Обучение зависит от конкретной организации.

6.

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

А Обучение зависит от конкретной организации.

7.

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

А Обучение зависит от конкретной организации.

Управление интегрированным ПО, уровень 3.

1.

Был ли описанный процесс создания ПО, использованный для выполнения проекта, разработан путем адаптации стандартного процесса создания ПО, применяемого внутри организации?.

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

2.

Осуществляется ли планирование и управление процессом в соответствии с описанным для проекта процессом создания ПО?.

А Менеджер проекта по созданию ПО составляет и утверждает план разработки ПО, он же является ответственным за план при периодических PRA-обзорах.

3.

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

А Политика организации — это политика, зафиксированная в виде документов.

4.

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

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

5.

Используются ли измерения для определения эффективности деятельности по управлению интегрированным ПО (например, частота, причины и размеры затрат на изменение планов)?.

А В проектах используются оценки состояния, включая необходимые метрики, для оценки прогресса и качества. Эти метрики собираются и анализируются SEPA и PRA для определения эффективности и любых требуемых усовершенствований.

6.

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

а План разработки ПО рассматривается как PRA, так и SEPA (который отвечает за SQA в данной организации).

Разработка программного продукта, уровень 3.

1.

Создаются ли промежуточные программные продукты в соответствии с определенным для данного проекта процессом создания ПО?.

А Менеджер проекта по созданию ПО ответственен за выполнение плана разработки ПО. Любые отклонения от плана или от стандартов (или от того и другого одновременно) периодически рассматриваются при оценке состояния, после чего вносятся соответствующие изменения в последующие итерации или базовые версии продуктов.

2.

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

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

3.

Следует ли проект заданной политике организации при осуществлении деятельности по разработке ПО (например, политике, которая предполагает использование конкретных методов и инструментов для создания и сопровождения программных продуктов)?.

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

4.

Обеспечивается ли выполнение заданий по разработке ПО адекватными ресурсами (например, финансированием, обученным персоналом и необходимым инструментарием)?.

А Адекватность ресурсов, выделяемых на разработку ПО, не определяется политикой. Хорошей контрольной отметкой может служить цифра 50% — именно такую часть всех трудозатрат следует направлять на выполнение задач по разработке ПО: 10% — на описание требований, 15% — на проектирование и 25% — на реализацию компонентов. Определение адекватности ресурсов и персонала специфично для каждого конкретного проекта и должно тщательно изучаться PRA.

5.

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

а Основная цель вычисления метрик и их рассмотрения при выполнении оценок состояния заключается в определении прогресса и качества.

6.

Подвергаются ли деятельность и промежуточные продукты деятельности по разработке ПО SQA-рассмотрениям и проверкам (например, выполняется ли необходимое тестирование, определяется ли соответствие требований к системе требованиям к ПО, проекту, коду и вариантам тестирования) ?.

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

Координация между группами, уровень 3.

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

1. Сотрудничают ли группа по разработке ПО и другие группы разработчиков в процессе выполнения проекта с заказчиком для определения системных требований?.

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

2.

Согласны ли группы разработчиков с возложенными на них обязанностями, которые зафиксированы в общем плане проекта?.

А Планы и поручения содержатся в планах разработки ПО, спецификациях версий и WBS.

3.

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

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

4.

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

А ССВ, PRA и команды по проведению демонстраций как раз и являются междисциплинарными командами.

5.

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

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

6.

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

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

7. Рассматривается ли деятельность по координации между группами менеджером проекта на регулярной основе и при наступлении определенных событий?.

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

Экспертные оценки, уровень 3.

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

1.

Запланированы ли экспертные оценки ?.

А ССВ, оценки состояния и демонстрации следует включать в планы и проводить систематически.

2.

Отслеживается ли деятельность по устранению дефектов, обнаруженных при экспертных оценках, до тех пор, пока они не будут исправлены ?.

А Исправление всех дефектов — независимо от того, каким именно способом они были обнаружены, — отслеживается посредством SCO, а все метрики определяются для оценок состояния.

3.

Следует ли проект политике организации в области выполнения экспертных оценок?.

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

4.

Проходят ли участники экспертных оценок необходимое обучение для выполнения своих обязанностей?.

А Обучение зависит от конкретной организации.

5.

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

▲ ССВ предоставляют широкий набор метрик для управления изменениями. Для описаний версий требуется сбор тех же метрик, что и для демонстраций. SEPA периодически оценивает R0I анализа тенденций для данной организации посредством данных оценки состояния.

6. Подвергаются ли деятельность и промежуточные продукты, связанные с экспертными оценками, SQA-рассмотрениям и проверкам (например, проводятся ли планируемые просмотры, отслеживаются ли окончательные проверки)?.

А Менеджеры проектов по созданию ПО, ССВ и PRA постоянно следят, чтобы эти виды деятельности доводились до конца.

Управление количественными показателями процесса, уровень 4.

1.

Следует ли проект документированному плану управления количественными показателями процесса?.

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

2.

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

А Все данные собираются и передаются SEPA в процессе выполнения оценок состояния. Эти метрики служат для установления обратной связи при планировании каждой последующей итерации.

3.

Известны ли количественные характеристики возможностей стандартного процесса по созданию ПО в рамках данного проекта ?.

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

4.

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

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

5.

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

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

6.

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

А В приложении к политике организации должна быть ссылка на R0I от SEPA-деятельности.

7.

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

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

Управление качеством ПО, уровень 4.

1.

Запланирована ли в рамках проекта деятельность по управлению качеством ПО?.

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

2.

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

А Для этого существуют спецификации версий и соответствующие им демонстрации, описания версий и метрики.

3.

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

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

4.

Следует ли проект политике организации в области управления качеством ПО?.

А Политика организации действительно определяет механизмы управления качеством ПО (спецификации версий, описания версий, параметры качества, PRA и CCB/SC0).

5.

Проходят ли члены группы по разработке ПО и других групп, имеющих отношение к ПО, необходимое для управления качеством ПО обучение (например, обучение по сбору измеряемых данных и по преимуществам количественного определения качества продукта)?.

А Обучение зависит от конкретной организации.

6.

Используются ли измерения для определения состояния деятельности по управлению качеством ПО (например, затраты на низкое качество)?.

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

7.

Проверяется ли вышестоящим руководством деятельность по управлению качеством ПО на регулярной основе?.

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

Предотвращение дефектов, уровень 5.

1.

Планируется ли деятельность по предотвращению дефектов?.

А Вопрос не рассматривается.

2.

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

а Вопрос не рассматривается.

3.

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

А Вопрос не рассматривается.

4.

Следует ли проект политике организации в области деятельности по предотвращению дефектов ?.

А Вопрос не рассматривается.

5.

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

А Обучение зависит от конкретной организации.

6.

Проводятся ли измерения деятельности по предотвращению дефектов (например, временных и финансовых затрат на обнаружение и исправление дефектов, а также количества предложенных, открытых и завершенных проблем)?.

А В проектах должен использоваться набор метрик, позволяющий определять эффективность исправления и состояние дефектов. Деятельность по предотвращению дефектов специально не описывается и не подвергается формализации, но ее основы четко определены посредством параметров управления и качества. PRA-рассмотрения, SCO и ССВ предоставляют различные механизмы для предотвращения дефектов на практике.

7.

Подвергаются ли деятельность по предотвращению дефектов и ее промежуточные продукты SQA-рассмотрениям и проверкам?.

А Все оценки состояния и PRA-рассмотрения предоставляются SEPA (для SQA данной организации). Оценки состояния распространяются среди персонала проекта и заинтересованных сторон, а данные no SCO рассматриваются ССВ для подтверждения того, что весь персонал вносит свой вклад в получение данных по предотвращению дефектов.

Управление изменением технологии, уровень 5.

1.

Следует, ли организация плану управления изменениями технологии? а Вопрос не рассматривается.

2.

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

А Вопрос не рассматривается.

3.

Следует ли организация документированной процедуре включения новых технологий в свой стандарт процесса по созданию ПО?.

А Вопрос не рассматривается.

4.

Способствует ли вышестоящее руководство управлению изменением технологии (например, создавая долговременные планы и поручения по финансированию, по найму персонала и выделению других ресурсов)?.

А Вопрос не рассматривается.

5.

Имеются ли данные по процессу, помогающие в выборе новой технологии ? А Вопрос не рассматривается.

6.

Используются ли измерения для определения состояния деятельности в рамках управления изменением технологии (например, эффекта от реализации изменений в технологии)?.

а Вопрос не рассматривается.

7.

Подвергается ли деятельность в рамках управления изменением технологии рассмотрению вышестоящим руководством на регулярной основе?.

А Вопрос не рассматривается.

Управление изменением процесса, уровень 5.

1.

Следует ли организация документированной процедуре разработки и сопровождения планов по усовершенствованию процесса создания ПО?.

а В политике организации должно иметься приложение, касающееся усовершенствований процесса.

2.

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

А Участвуют SEPA и PRA. Участие остальных зависит от конкретной организации.

3.

Постоянно ли вносятся изменения в стандарт процесса по созданию ПО данной организации и в процесс создания ПО для данного проекта ?.

А На каждой новой итерации при осуществлении проекта имеется возможность внесения усовершенствований в план создания ПО. Политика организации также нуждается в периодической переоценке и усовершенствовании.

4.

Следует ли организация принятой политике в области реализации усовершенствований процесса создания ПО?.

а Такая политика должна включаться в виде приложения в общую политику организации.

5.

Требуется ли обучение усовершенствованиям процесса создания ПО для руководящего состава и для технических работников ?.

А Обучение зависит от конкретной организации.

6.

Используются ли измерения для определения состояния деятельности по совершенствованию процесса создания ПО (например, эффекта от реализации каждого усовершенствования процесса по сравнению с объявленными целями)?.

А От политики организации и SEPA требуются регулярные оценки R0I от деятельности по усовершенствованию в рамках данной организации.

7. Рассматривается ли деятельность по совершенствованию процесса создания ПО вышестоящим руководством на регулярной основе?.

а Генеральный менеджер организации отвечает за утверждение всех изменений в политике организации.

Е.4 ВОПРОСЫ, КОТОРЫЕ НЕ ВОШЛИ В «ВОПРОСНИК ДЛЯ ОПРЕДЕЛЕНИЯ ЗРЕЛОСТИ».

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

Отчетность персонала, уровень 2.

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

1.

Вводит ли организация должность для сопровождения описания своего процесса и других активов?.

2.

Хранится ли у SEPA история проектов и их воздействия на корпоративную стратегию?.

3.

Составляют ли менеджеры проектов по созданию ПО свои планы разработки?.

4.

Представляют ли менеджеры проектов по созданию ПО оценки состояния самостоятельно?.

Автоматизация среды, уровень 3.

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

1.

Описывает ли политика организации минимальное ядро среды?.

2.

Поддерживает ли среда набор метрик в качестве естественного побочного продукта процесса?.

3.

Является ли документация автоматизированным однородным побочным продуктом разработки (в отличие от отдельного, неоднородного вида материалов)?.

4.

Автоматизирована ли «круговая» разработка?.

5.

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

6.

Адекватно ли автоматизировано регрессионное тестирование?.

7.

Используются ли случайные сценарии и внеурочное тестирование для обеспечения статистического тестового покрытия?.

8.

Интегрированы ли редакторы языков программирования, среда управления конфигурацией, компилятор и отладчик?.

Разработка архитектуры, уровень 3.

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

1.

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

2.

Уделяется ли основное внимание при экспертных оценках действительно критичным компонентам?.

3.

Существует ли четко сформулированное определение архитектуры?.

4.

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

5.

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

Управление изменениями, уровень 3.

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

1.

Имеют ли вносимые в ПО изменения однозначное определение их типа и приоритета?.

2.

Собираются ли, оформляются и анализируются данные по внесенным изменениям?.

3.

Определены ли и распределены обязанности по сопровождению базы данных изменений?.

4.

Существует ли механизм подтверждения того, что инициатор запроса на внесение конкретного изменения удовлетворен реализацией данного изменения?.

5.

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

Предсказуемость, уровень В.

Самым лучшим показателем зрелости процесса является предсказуемость получаемых результатов.

,.

1.

Производит ли организация сравнение запланированных и реально полученных данных?.

2.

Имеется ли документально зафиксированная корреляция между планировавшимися и реально полученными данными по последним выполненным проектам?.

3.

Используются ли такие «исторические» планы и реальные данные в текущих проектах?.

4.

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

Интегрированная экономика, уровень 4.

Соответствующая экономическая мотивация должна быть вплетена в ткань процесса.

1.

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

2.

Используются ли систематически результаты измерений, выполненных на предыдущих итерациях, при планировании последующих итераций?.

3.

Производятся ли SEPA текущие оценки зрелости процесса организации?.

4.

Производится ли измерение деятельности по усовершенствованию процесса в данной организации с точки зрения отдачи от инвестиций?.

5.

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

Е.5 ОБЩАЯ ОЦЕНКА ПРОЦЕССА.

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

Верным признаком того, что организация достигла этого уровня зрелости, будет ее способность (1) предоставить развернутые ответы на вопросы документа с подробным объяснением специфичных для организации и проекта реализаций и (2) проиллюстрировать каждый ответ конкретными примерами из опыта в данной области. Если процедура подготовки к такой проверке процесса требует более одной или двух человеко-недель, то SE.PA является в большей степени вывеской, чем фактором, приносящим пользу в работе организации. Дополнительное обеспечение, необходимое для проверки процесса, должно являться естественным побочным продуктом процесса управления проектом.