Введение (стр. 10 )

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

Требования формируют часть структуры оценки процесса, который:

поощряет самооценку;

принимает во внимание контекст, в котором оцененные процессы функционируют;

производит наборы рейтингов процесса (профили процесса);

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

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

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

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

2. Цель оценки.

3. Сферу оценки, включая:

а) процессы, которые будут исследованы внутри организации;

б) самый верхний уровень возможности, который должен исследоваться;

в) часть организации, которая разворачивает эти процессы;

г) контекст процесса, который, как минимум, включает: размер организации; демографию организации; предметную область продукта или услуг организации; размер, уязвимость и сложность изделий или услуг; качественные характеристики изделий (см., например, ИСО/МЭК 9126-91 Характеристики качества ПО).

4. Ограничения целостности оценки, которые могут включать:

а) доступность ключевых ресурсов;

б) максимальное количество времени, которое должно использоваться для оценки;

в) специфические процессы, которые должны быть исключены из оценки;

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

д) собственность на выполнение оценки и любые ограничения на их использование;

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

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

6. Личности экспертов-консультантов, включая компетентного эксперта-консультанта, ответственного за оценку.

7. Личности экспертов-консультантов и персонала поддержки со специфическими обязанностями для оценки.

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

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

Компетентный эксперт-консультант должен гарантировать, что оценка проводится в соответствии с определенными требованиями и принимает во внимание релевантные руководства в других частях ИСО/МЭК 15504.

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

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

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

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

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

должны быть явно идентифицированы стратегия и методы сбора и анализа данных;

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

каждый процесс, идентифицированный в области оценки, должен быть оценен на основе целевого доказательства;

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

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

Эти записи должны включать:

а) методы и исследованные рабочие продукты;

б) имена личностей, обеспечивающих информацию;

в) обсуждение оценок;

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

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

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

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

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

Критерии для квалификации компетентного эксперта-консультанта должны быть зарегистрированы.

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

Запись оценки, как минимум, должна содержать:

дату оценки;

вход оценки (исходные данные);

используемый метод оценки и инструментальные средства;

имена экспертов-консультантов, которые провели оценку, включая компетентного эксперта-консультанта, ответственного за оценку;

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

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

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

время, потраченное экспертом-консультантом, и уровень возможности процесса или уровни, как определено в эталонной модели.

Запись должна содержать следующее утверждение :  эта оценка провелась в соответствии с требованиями ISO 15504. Оценка процесса разработки программного обеспечения.

4.4. Модель оценки

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

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

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

Рис. 4.7 Отношения между эталонной моделью, моделью оценки и методами оценки.

Структура и принципы модели оценки

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

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

Рис. 4.8 Связь между эталонной моделью и моделью оценки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.9 Связь между показателями и оценками атрибута процесса.

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

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

В модели оценки, полное описание каждого процесса включает:

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

Для примера приведем описание по одному процессу из каждой категории.

CUS.1 Приобретение ПО

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

будет разработан контракт, в котором ясно выражено ожидание, обязанности и ответственность, как поставщика, так и клиента;

продукт и/или услуга, которые будут произведены, удовлетворят потребность клиента;

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

Базовые методы:

CUS.1.1 Определение потребности. Определите потребность приобретения, разработки или усовершенствования программного продукта.

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

CUS.1.2 Определение требований. Определите требования для системы и/или программного продукта, которые удовлетворят потребность в новом продукте и/или услуге.

Примечание. Это определение требований может быть выполнено полностью или частично поставщиком. См. ENG.1 и ENG.2. Также см. CUS.2. CUS.1 фокусируется на определение требований, когда программная организация выступает в качестве клиента. CUS.2 фокусируется на определение требований, когда программная организация выступает в качестве поставщика. Первичное различие - одна из перспектив, в зависимости от выполняемой роли.

CUS.1.3 Подготовка стратегии приобретения. Подготовьте стратегию приобретения продукта.

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

CUS.1.4 Подготовка заявки для предложений. Подготовьте заявки для предложений, включая требования приобретения и график проекта.

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

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

CUS.1.7 Заключение контракта. Заключите контракт с поставщиком.

CUS.1.8 Поддержка контракта. Установите и обеспечьте поддержку, требующуюся контрагентом.

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

CUS.1.9 Приемка поставленного продукта. Установите и согласуйте критерии приемки и средства оценки, которые должны использоваться. Выполните оценки продукта или услуг в соответствии с согласованными критериями.

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

ENG.2 Разработка требований к ПО

Цель процесса Разработки программных требований - формулировка требований к программному обеспечению системы. Как результат успешной реализации этого процесса:

будут определены требования, предъявляемые к различным программным компонентам системы и их интерфейсам, соответствующие настоящим и предполагаемым потребностям клиента;

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

должно быть понято влияние программных требований на операционную среду;

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

программные требования должны быть проверены и откорректированы, если необходимо;

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

Базовые методы:

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

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

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

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

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

ENG.2.4 Определение стратегии выпуска версии ПО. Определите приоритетность требований к ПО и отобразите их в будущих версиях.

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

ENG.2.6 Связь с требованиями к ПО. Определите связывающий механизм для распределения информации о требованиях к ПО (и изменениях в них).

SUP.3 Выполнение гарантии качества

Целью процесса Гарантия качества является обеспечение гарантии того, что рабочие продукты и действия процесса или проекта согласуются со всеми применяемыми стандартами, процедурами и требованиями. Результат успешной реализации процесса:

должны быть определены, спланированы и расписаны действия по гарантии качества процессов и проекта;

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

должны быть установлены ресурсы и ответственность для выполнения действий по обеспечению гарантии качества;

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

должны быть выполнены определенные действия по гарантии качества в соответствии с планами и графиками.

Базовые методы:

SUP.3.1 Выбор критериев качества. Определите роли, сферу и степени гарантии качества и выберите приемлемые стандарты и процедуры.

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

SUP.3.3 Гарантия качества действий инжиниринга ПО. Выполните серию действий для обеспечения требуемого уровня уверенности, что действия инжиниринга программного обеспечения выполняются в соответствии с планами и выбранными стандартами и процедурами.

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

SUP.3.5 Сообщение о результатах. Сообщите результаты вышеперечисленных действий, в частности, отклонения, на соответствующих уровнях управления и штата.

SUP.3.6 Обработка отклонений. Направьте отклонения на соответствующий уровень управления, передавая их на следующий более высокий уровень, до тех пор, пока они не будут разрешены.

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

MAN.2 Управление качеством

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

будут установлены цели качества, основанные на требованиях качества заказчика, для различных контрольных точек внутри жизненного цикла ПО;

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

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

будут выполнены идентифицированные действия качества;

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

Базовые методы:

MAN.2.1 Установление целей качества. Установите цели качества для продукта и процесса, основанные на требованиях качества клиента, которые могут быть оценены в проекте.

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

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

MAN.2.4 Выполнение действий качества. Выполните идентифицированные действия для обеспечения качества.

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

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

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

ORG.2 Определение процесса

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

будет существовать хорошо определенный и поддерживающий стандарты комплект процессов, вместе с индикацией применимости каждого процесса;

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

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

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

Базовые методы:

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

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

ORG.2.2 Определение текущих действий, роли, прав и обязанностей. Определите действий, которые входят в путь, по которому процесс в настоящее время и/или должен выполняться и идентифицируйте роли, права и обязанности для этих действий.

ORG.2.3 Определение входов и выходов. Определите входы и выходы каждого процесса.

ORG.2.4 Определение критериев входа и выхода. Определите критерии для входа и выхода процесса.

ORG.2.5 Определение точек контроля. Определите точки процесса, где делаются ключевые обзоры и принимаются решения.

ORG.2.6 Идентификация внешних интерфейсов. Определите интерфейсы со связанными процессами, которые поддерживают входы и используют выходы.

ORG.2.7 Идентификация внутренних зависимостей. Определите зависимости между действиями процесса.

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

Примечание. Меры процесса направляют такие цели, как эффективность процесса и качество.

ORG.2.9 Документирование стандартного процесса. Зафиксируйте стандарты, процедуры и модели для выполнения процесса и характеристики его выходов.

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

спецификация требований; методы проектирования;

стиль кодирования; языки программирования;

тестирование; защита;

человеческие факторы; документация;

планы управления проектом; планы обеспечения качества ПО;

планы управления конфигурацией.

ORG.2.10 Установление стратегии. Установите и запишите стратегии организации для выполнения процесса.

ORG.2.11 Установление ожиданий выполнения. Установите ожидания выполнения процесса при использование семейства стандартных процессов организаций.

ORG.2.12 Развертывание процесса. Разверните семейство стандартных процессов организации, доступных всей организации.

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

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

Таблица 4.5.

CUS.1 Приобретение ПО

Вход	Выход
83) Просьба клиента 52) Внутренние требования 48) Ответ на предложения поставщика 49) Запись истории поставщика 29) Записи оценки / проверки 51) Контракт 21) Анализ результатов 45) Стратегия приобретения	44) Оценка потребности в продукте 52) Требования на продукт / услугу 45) Стратегии / план приобретение 47) Просьба о предложении 21) Результаты Анализа 31) Записи Обзора 51) Контракт 68) Стратегия приемосдаточного испытания

 Таблица 4.6.

CUS.2 Управление потребностями клиента

Вход	Выход
83) Просьба клиента 52) Требования клиента 21) Результаты анализа 22) Запись анализа риска 51) Контракт 96) История изменения 6) Структура прерывания работы	83) Просьба клиента 46) Анализ рынка 87) Механизм связи 31) Записи обзора 44) Оценка потребностей в продукте 82) Процедуры поддержки клиента 50) Обязательство / соглашение 52) Требования клиента 51) Контракт 95) Контроль изменений 96) История изменения 17) План проекта 87) Механизм связи 58) Трассируемость записи / распределения 97) Поправочные действия

 Таблица 4.7.