Модель зрелости процессов разработки программного обеспечения

Паулк Марк

В соответствии с документированной процедурой

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

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

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

Отнесенные к ПО системные требования

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

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

Отношения типа «поставщик — заказчик»

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

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

Отслеживание процесса разработки ПО с принятием корректирующих мер в сравнении с управлением ходом работ

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

более эффективно выбирать и вносить изменения.

Контроль в сравнении с экспертной оценкой

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

Помещение в систему управления конфигурацией в сравнении с управлением и контролем

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

Если управление конфигурацией является задачей самих разработчиков, то оно обычно называется управлением конфигурацией разработчиками. Некоторые продукты, чья конфигурация должна контролироваться разработчиками, могут быть помещены в систему управления конфигурацией по достижении заранее заданных фаз в ходе выполнения проекта. Фразу «помещен в систему управления конфигурацией» можно понимать как расширение системы управления конфигурацией разработчиками. Однако ее минимальная интерпретация отражает лишь потребность в управлении конфигурацией базовой линии.

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

7.2.4. Измерения и анализ

Ключевые практики раздела «Измерения и анализ» описывают основные методы измерений, необходимых для определения статуса операций, относящихся к разделу «Выполняемые действия». Являясь неотъемлемой частью группы ключевых процессов, измерения приводятся сразу после раздела «Выполняемые действия».

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