"Марк Паулк, Билл Куртис. Модель зрелости процессов разработки программного обеспечения " - читать интересную книгу автора

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

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

Отношения типа "поставщик - заказчик"

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

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

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