Законодательная база Российской Федерации

Приложение А
(обязательное)

Приложение А. ПРОЦЕСС АДАПТАЦИИА.1 Введение

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

Примечание - Адаптация не является требованием соответствия стандарту. Фактически адаптация не разрешается, если сделано заявление о "полном соответствии". Если же сделано заявление об "адаптированном соответствии", то адаптация должна выполняться в соответствии с изложенным ниже процессом.

А.2 Процесс адаптации

А.2.1 Цель процесса адаптации

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

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

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

c) отражающие потребности организации в поставке продукции и услуг.

А.2.2 Результаты процесса адаптации

В результате успешной реализации процесса адаптации

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

А.2.3 Деятельность в процессе адаптации

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

А.2.3.1 Идентифицировать и документировать обстоятельства, влияющие на адаптацию. Эти влияния включают (но не ограничиваются только перечисленными ниже):

a) стабильность и разнообразие среды функционирования;

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

c) новизну, размеры и сложность;

d) дату начала и продолжительность применения;

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

f) вновь возникающие технологические возможности;

g) профиль бюджета и доступные организационные ресурсы;

h) готовность предоставления услуг обеспечивающими системами;

i) роли и обязанности в полном жизненном цикле системы;

j) необходимость соответствия с другими стандартами.

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

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

a) правообладателей системы;

b) заинтересованные стороны соглашения, заключенного организацией;

c) добавление нового качества в организационные функции.

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

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

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

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

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

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

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

Приложение В
(обязательное)

Приложение В. ЭТАЛОННАЯ МОДЕЛЬ ПРОЦЕССОВ ДЛЯ ЦЕЛЕЙ ОЦЕНКИВ.1 Введение

Подразумевается, что некоторые пользователи настоящего стандарта могут пожелать оценивать определенные реализуемые процессы в соответствии с [20]. В настоящем приложении рассматривается эталонная модель процессов (ЭМП), пригодная для совместного использования с настоящим стандартом.

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

В.2 Соответствие с ИСО/МЭК 15504-2В.2.1 Общие положения

Эталонная модель процессов, представленная в настоящем приложении, приспособлена для использования в процессе аттестации, выполняемой в соответствии с [20]. Часть 2. Проведение аттестации (ISO/IEC 15504-2, Information Technology - Process Assessment - Part 2: Performing an assessment).

В подразделе 6.2 второй части [20] содержатся требования к эталонным моделям процессов, подходящим для аттестации с помощью настоящего стандарта. В последующих подразделах настоящего приложения цитируются требования к ЭМП и описывается, как они соответствуют требованиям настоящего стандарта. Выделенный курсовом текст цитирует требования из второй части [20], а текст, набранный прямым шрифтом, описывает способ, с помощью которого требование удовлетворяется в контексте настоящего стандарта.

В.2.2 Требования к эталонным моделям процессов

Эталонная модель процессов должна содержать:

a) декларацию о домене ЭМП (см. раздел 1);

b) описание, удовлетворяющее требованиям, содержащимся в 6.2.4 настоящего стандарта, и требованиям к процессам в рамках области применения ЭМП (см. В.3);

c) описание взаимосвязей между ЭМП и ее предназначением (см. раздел 5);

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

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

a) соответствующее заинтересованное сообщество должно быть охарактеризовано или задано. Соответствующим заинтересованным сообществом являются пользователи [18] и настоящего стандарта;

b) степень достижения консенсуса должна быть документирована. Оба стандарта ([18] и настоящий стандарт) являются международными стандартами, удовлетворяющими требованиям к консенсусу в ИСО/МЭК СТК 1;

c) если никаких действий не предпринято для достижения консенсуса, формулировка такого результата должна документироваться. Не применяется в настоящем стандарте.

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

В.2.3 Описания процессов

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

a) процесс должен быть описан в терминах цели и выходов;

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

c) описания процессов должны быть такими, чтобы никакие аспекты структуры работ по измерениям, как описано в разделе 5 [20], ниже первого уровня не содержались и не подразумевались.

Формулировка результата описывает какой-либо из следующих результатов:

- производство искусственного продукта;

- существенное изменение состояния;

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

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

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

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

В дополнение к этим основным атрибутам процессы могут быть охарактеризованы другими атрибутами, общими для всех процессов. Эти общие атрибуты способствуют достижению более высокого уровня возможностей процесса, как определено в [20]. Существует шесть уровней возможностей процесса в структуре измерений (см. [20]), представленных в таблице В.1.

Таблица В.1

Шесть уровней возможностей процесса

В [20] определены следующие общие атрибуты процесса, связанные с достижением более высоких уровней возможностей процесса:

- менеджмент рабочих характеристик (РА* 2.1) - определяет степень, с которой проводится менеджмент рабочих характеристик процесса. Соответствие этому атрибуту включает в себя планирование, мониторинг и настройку рабочих характеристик процесса.

---

* РА - process attributes - и цифровые обозначения атрибутов соответствуют [20] (примеч. переводчика).

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

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

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

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

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

- инновации процесса (РА 5.1) - определяет степень, с которой изменения в процессе выявляются в результате анализа отклонений в рабочих характеристиках и исследования инновационных способов определения и реализации процесса. Соответствие этому атрибуту связано с существованием активной позиции по отношению к непрерывному совершенствованию выполнения как текущих, так и проектируемых деловых целей.

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

В.3 Эталонная модель процессов

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

Таблица В.2 - Процессы настоящего стандарта

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

В.3.1 Процессы более низкого уровня, чем процесс приобретения

В.3.1.1 Процесс подготовки к приобретению

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

В.3.1.1.1 Цель

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

В.3.1.1.2 Выходы

В результате успешного осуществления процесса подготовки к приобретению:

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

b) определяются требования правообладателей;

c) разрабатывается стратегия приобретения;

d) определяются критерии выбора поставщиков.

В.3.1.2 Процесс выбора поставщика

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

В.3.1.2.1 Цель

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

В.3.1.2.2 Выходы

В результате успешного осуществления процесса выбора поставщика:

a) устанавливаются и применяются критерии выбора поставщика для оценки потенциальных поставщиков;

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

c) формируется соглашение и ведутся переговоры между приобретающей стороной и поставщиком.

В.3.1.3 Процесс мониторинга соглашений

Этот процесс является процессом более низкого уровня, чем процесс приобретения, заменяя деятельность по мониторингу соглашений (см. 6.1.1.3.5).

В.3.1.3.1 Цель

Цель процесса мониторинга соглашений состоит в отслеживании и оценке рабочих характеристик поставщика относительно согласованных требований.

В.3.1.3.2 Выходы

В результате успешного осуществления процесса мониторинга соглашений:

a) выполняются надлежащим образом совместные действия приобретающей стороны и поставщика;

b) происходит регулярный обмен информацией с поставщиком о техническом прогрессе;

c) выполняется мониторинг рабочих характеристик поставщика относительно согласованных требований;

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

В.3.1.4 Процесс приемки приобретающей стороной

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

В.3.1.4.1 Цель

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

В.3.1.4.2 Выходы

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

a) оцениваются поставленные программный продукт и (или) услуга в соответствии с соглашением;

b) приемка приобретающей стороной основывается на согласованных критериях приемки;

c) программный продукт и (или) услуга принимаются приобретающей стороной.

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

В.3.2.1 Процесс представления заявки поставщиком

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

В.3.2.1.1 Цель

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

В.3.2.1.2 Выходы

В результате успешной реализации процесса представления заявки поставщиком:

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

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

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

d) определяются подходящие ресурсы для выполнения предложенных работ;

e) готовятся и представляются предложения поставщика в ответ на запрос приобретающей стороны.

В.3.2.2 Процесс согласования контракта

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

В.3.2.2.1 Цель

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

В.3.2.2.2 Выходы

В результате успешного осуществления процесса согласования контракта:

a) проводятся переговоры, контракт (соглашение) пересматривается, принимается и предоставляется поставщику (поставщикам);

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

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

d) получается официальное подтверждение соглашения.

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

В.3.2.3 Процесс поставки и поддержки продукта (услуги)

Этот процесс является процессом более низкого уровня процесса поставки, заменяя деятельность по поставке и поддержке продукта и (или) услуги (см. 6.1.2.3.5).

В.3.2.3.1 Цель

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

В.3.2.3.2 Выходы

В результате успешного осуществления процесса поставки и поддержки продукта (услуги):

a) определяется состав выпуска продукта;

b) собирается выпуск из сконфигурированных элементов;

c) определяется и создается документация по выпуску;

d) определяются механизмы и носители поставки выпуска;

e) осуществляется утверждение выпуска по определенным критериям;

f) выпуск продукта делается доступным приобретающей стороне;

g) получается подтверждение выпуска;

h) продукт комплектуется и поставляется приобретающей стороне;

i) поддерживаются и пересматриваются приемочные тесты приобретающей стороны;

j) продукт помещается в эксплуатационную среду заказчика;

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

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

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

В.3.3.1 Процесс учреждения процессов

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

В.3.3.1.1 Цель

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

В.3.3.1.2 Выходы

В результате успешного осуществления процесса учреждения процессов:

a) устанавливается определенная и сопровождаемая стандартная совокупность процессов вместе с указанием применимости каждого процесса;

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

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

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

В.3.3.2 Процесс аттестации процессов

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

В.3.3.2.1 Цель

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

В.3.3.2.2 Выходы

В результате успешного осуществления процесса аттестации процессов:

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

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

c) сохраняются и сопровождаются точные и доступные записи об аттестациях.

В.3.3.3 Процесс совершенствования процессов

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

В.3.3.3.1 Цель

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

В.3.3.3.2 Выходы

В результате успешного осуществления процесса совершенствования процессов:

a) устанавливаются обязательства по обеспечению ресурсами для поддержки действий по совершенствованию;

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

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

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

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

f) знания, приобретенные в процессе совершенствования, распространяются в пределах организации;

g) сделанные усовершенствования оцениваются и проводится рассмотрение применения полученных решений в других процессах и подразделениях организации.

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

Примечание 2 - Текущее состояние процессов может определяться посредством оценки процессов.

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

В.3.4.1 Процесс развития навыков

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

В.3.4.1.1 Цель

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

В.3.4.1.2 Выходы

В результате успешного осуществления процесса развития навыков:

a) развивается или приобретается тренированность работников, ориентированная на потребности организации и проекта;

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

В.3.4.2 Процесс приобретения и обеспечения навыков

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

В.3.4.2.1 Цель

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

В.3.4.2.2 Выходы

В результате успешного осуществления процесса приобретения и обеспечения навыков:

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

b) поддерживается эффективное взаимодействие между работниками и группами;

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

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

В.3.4.3 Процесс менеджмента знаний

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

В.3.4.3.1 Цель

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

В.3.4.3.2 Выходы

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

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

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

c) организация выбирает подходящую стратегию менеджмента знаний.

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

В.3.5.1 Процесс применения по назначению

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

В.3.5.1.1 Цель

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

В.3.5.1.2 Выходы

В результате успешного осуществления процесса применения по назначению:

a) идентифицируются операционные риски и проводится их мониторинг при введении в действие и функционировании продукта;

b) продукт вводится в действие в заданной среде согласно установленным требованиям;

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

В.3.5.2 Процесс поддержки заказчика

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

В.3.5.2.1 Цель

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

В.3.5.2.2 Выходы

В результате успешного осуществления процесса поддержки заказчика:

a) идентифицируются и постоянно отслеживаются потребности в обслуживании заказчика;

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

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

d) удовлетворяются потребности в поддержке заказчиков путем предоставления соответствующих услуг.

Приложение С
(справочное)

Приложение С. ИСТОРИЯ РАЗРАБОТКИ СТАНДАРТА И ПОЯСНЕНИЯС.1 Введение

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

С.2 Сведения об истории разработки стандарта

Первая версия стандарта ИСО/МЭК 12207 была опубликована в 1995* году. Разработчики этой версии стандарта видели необходимость описания процессов, видов деятельности и задач процессов для облегчения разработки программных средств. Поэтому в ИСО/МЭК 12207:1995 установлено, что именно необходимо выполнять, а также описаны процессы в терминах видов деятельности и задач.

---

* В России - в 1999 г. (примеч. переводчика).

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

Определение возможностей процессов требует, чтобы их описания включали в себя четкую формулировку цели процесса и описание ожидаемых результатов. Такие формулировки цели и результатов отсутствовали в ИСО/МЭК 12207:1995 и были внесены в изменения к этому стандарту, изданные в 2002 и 2004 годах. Эти изменения дополнены также рядом процессов, детализирующих имеющиеся уровни и предназначенных для облегчения надлежащей оценки процессов жизненного цикла программных средств во всей их полноте.

Несмотря на то, что в ИСО/МЭК 12207:1995 рассматривались процессы жизненного цикла программных средств в системном контексте, было очевидно, что аналогичный стандарт был необходим также и в системной области. ИСО/МЭК 15288, опубликованный в ноябре 2002 года, полностью удовлетворил эту потребность. Разработчики стандарта извлекли пользу из опыта, полученного при разработке дополненного стандарта ИСО/МЭК 12207 и понимания потребностей, выраженных в ИСО/МЭК 15504. Таким образом, процессы в ИСО/МЭК 15288 излагались в терминах целей и выходов с описанием видов деятельности, необходимых для достижения этих выходов.

Развернутая по стадиям разработка изменений к ИСО/МЭК 12207 вместе с ИСО/МЭК 15288 и изначально иная ориентация ИСО/МЭК 12207 привели к некоторым затруднениям в применении дополненного стандарта ИСО/МЭК 12207 так же, как и в совместном применении стандартов жизненного цикла систем и программных средств. Гармонизация проекта в рамках Подкомитета 7 "Системная и программная инженерия" Совместного технического комитета N 1 ИСО/МЭК - СТК 1 "Информационные технологии" (ISO/IEC JTC 1/SC 7) являлась первым большим шагом к объединенному комплекту стандартов, описывающих жизненный цикл систем и программных средств, а ее суть заключалась в параллельно проведенном и тщательно контролируемом пересмотре ИСО/МЭК 12207, ИСО/МЭК 15288 и разработке технического отчета ИСО/МЭК 24748, представляющего собой руководящие указания для обоих международных стандартов.

С.3 Цели

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

- внедрить и приспособить оба изменения;

- применить общую терминологию в пересматриваемом стандарте ИСО/МЭК 15288 и в настоящем стандарте;

- использовать общие названия процессов в пересматриваемом стандарте ИСО/МЭК 15288 и в настоящем стандарте (где это приемлемо);

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

- вобрать в себя десятилетний опыт разработки и применения ИСО/МЭК 12207 и ИСО/МЭК 15288.

С.4 Конструкции процессов и их применение

Описания процессов в настоящем стандарте следуют четко определенным правилам. Во-первых, они объединены в логические группы. Такое группирование обусловлено:

- логическими отношениями между процессами;

- обязанностями по выполнению процессов.

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

а) процессы соглашения - два процесса (см. 5.2.2.1.1 и 6.1);

b) процессы организационного обеспечения проекта - пять процессов (см. 5.2.2.1.2 и 6.2);

c) процессы проекта - семь процессов (см. 5.2.2.1.3 и 6.3);

d) технические процессы - одиннадцать процессов (см. 5.2.2.1.4 и 6.4);

e) процессы реализации программных средств - семь процессов (см. 5.2.2.2. и 7.1);

f) процессы продержки программных средств - восемь процессов (см. 5.2.2.2.2 и 7.2);

g) процессы повторного применения программных средств - три процесса (см. 5.2.2.2.3 и 7.3).

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

В пределах настоящего стандарта:

6.а и 7.а - указывают на группу процесса;

6.а.b и 7.а.b - указывают на процесс (или процессы более низкого уровня) в пределах этой группы;

6.а.b.1 и 7.а.b.1 - описывают цель процесса;

6.а.b.2 и 7.а.b.2 - описывают выходы процесса;

6.а.b.3.с и 7.а.b.3.с - перечисляют виды деятельности в рамках процесса и пункты;

6.a.b.3.c.d и 7.a.b.3.c.d - перечисляют задачи вида деятельности "с".

Представление конструкций процессов на универсальном языке моделирования UML, применяемых в настоящем стандарте и ИСО/МЭК 15288-2007, показано на рисунке С.1.

Рисунок С.1 - Конструкции процессов в ИСО/МЭК 12207 и ИСО/МЭК 15288

С.5 Отношения между версиями стандартов

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

Отношения между конструкциями процессов в исходных документах показаны на рисунке С.2.

Отношения между конструкциями процессов в ИСО/МЭК 12207:1995 и его изменениях, 15288:2002, 15288:2007 и в настоящем стандарте

Рисунок С.2 - Отношения между конструкциями процессов

Для удобства пользователей предыдущей редакции ИСО/МЭК 12207 (с изменениями) и предыдущей редакции ИСО/МЭК 15288 в таблице С.1 приведена информация, относящаяся к источнику обеспечения согласованности процессов ИСО/МЭК 12207:2007. Информацию, представленную в таблице С.1, следует использовать с осторожностью, поскольку:

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

- условия были иногда адаптированы или расширены для лучшего соответствия с их новым содержанием;

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

В таблице С.1 указаны следующие источники:

"12207:1995" - относится к версии ИСО/МЭК 12207:1995;

"Amd 1" - соответствует изменению ИСО/МЭК 12207:1995/Изм.1:2002;

"Amd 2" - соответствует изменению ИСО/МЭК 12207:1995/Изм.2:2004;

"Amd 1/Amd 2" - соответствует Изменению 1 или Изменению 2;

"Измененный 12207" - соответствует тексту ИСО/МЭК 12207:1995, дополненному Изменением 1 и Изменением 2;

"15288" - относится к ИСО/МЭК 15288:2002;

"15939" - относится к ИСО/МЭК 15939:2002;

"16085" - относится к ИСО/МЭК 16085:2004.

Таблица С.1

Источники определения процессов в ИСО/МЭК 12207:2007

Приложение D
(справочное)

Приложение D. СООТВЕТСТВИЕ ПРОЦЕССОВ ИСО/МЭК 12207 И ИСО/МЭК 15288

В данном приложении описывается соответствие процессов в ИСО/МЭК 15288 и ИСО/МЭК 12207. Соответствие процессов следующих подразделов является простым и очевидным.

ИСО/МЭК 12207 и ИСО/МЭК 15288 используют те же названия процессов и ту же нумерацию подразделов для отдельных процессов:

6.1 Процессы соглашения,

6.2 Процессы организационного обеспечения проекта,

6.3 Процессы проекта.

В каждом случае процесс в ИСО/МЭК 12207 отражает специфику программных средств в более общем процессе ИСО/МЭК 15288.

Подраздел 6.4 в каждом стандарте называется "Технические процессы". Оба стандарта используют несколько различающиеся названия для этих процессов. В некоторых случаях процессы подраздела 6.4 исо/МЭК 12207 отражают специфику программных средств относительно процессов в исо/МЭК 15288. В других случаях процессы исо/МЭК 12207 только способствуют достижению одного или более выходов соответствующих процессов исо/МЭК 15288. В приведенной ниже таблице перечислены технические процессы и отражена природа их отношений.

Таблица D.1

Отношение технических процессов ИСО/МЭК 12207 к техническим процессам ИСО/МЭК 15288

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

Примечание 2 - Хотя в настоящем стандарте процесс валидации программных средств остался поддерживающим процессом и помещен в группу процессов поддержки программных средств раздела 7, но в случае, если этот процесс выполняется для системного программного элемента (программной составной части), данный процесс может внести вклад в один или более выходов процесса валидации из ИСО/МЭК 15288.

Приложение Е
(справочное)

Приложение Е. ВИДЫ ПРОЦЕССОВЕ.1 Введение

Существуют примеры, в которых для представления конкретного инженерного интереса было бы желательно собрать в одном месте множество видов деятельности процесса, непосредственно и в компактной форме нацеленных на объект внимания. Для этого могут быть разработаны виды процессов с целью организовать процессы, виды деятельности и задачи, отобранные из ИСО/МЭК 12207 или ИСО/МЭК 15288, и сфокусировать их на объекте внимания способом, который охватывает весь или части жизненного цикла. В данном приложении рассматривается точка зрения на процесс, которую можно использовать для определения видов процессов в упомянутых выше примерах.

Е.2 Определения

Вид: представление системы как целого исходя из рассмотрения связной совокупности объектов, представляющих интерес*.

---

* Цитировано из проекта ИСО/МЭК 42010 Системная и программная инженерия - Архитектурное описание (Systems and software engineering - Architectural description), разрабатываемого на базе IEEE P42010/D1 (примеч. переводчика).

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

Точка зрения: спецификация соглашений для конструирования и применения вида. Образец или шаблон точки зрения предназначен для разработки отдельных видов посредством установления целей и аудиторий для вида, а также технических приемов его создания и анализа [ИСО/МЭК 42010].

Е.3 Понятие "вид процесса"

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

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

Е.3.1 Точка зрения на процесс

Вид процесса согласуется с точкой зрения на процесс. Точка зрения на процесс, представленная здесь, может использоваться для создания видов процессов. Пример применения точки зрения на процесс приведен в Е.4.

Точка зрения на процесс определяется:

- правообладателями и пользователями стандарта;

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

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

наименование вида процесса,

цель вида процесса,

выходы вида процесса,

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

Примечание - Требования к документированию точек зрения изложены в ИСО/МЭК 42010:2007 Системная и программная инженерия. Рекомендованная практика архитектурного описания систем, широко использующих программные средства (ISO/IEC 42010:2007 "Systems and software engineering - Recommended practice for architectural description of software-intensive systems"). Приведенное описание согласуется с этими требованиями.

Е.4 Вид процесса, характеризующего приспособленность к применению

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

В этом примере представлен кластер интересов, называемых обычно "приспособленностью, удобством применения", "ориентированным на пользователя проектированием" или "ориентированным на человека проектированием", как описано в [7], что дает возможность оптимизировать поддержку и обучение, обеспечить рост производительности и качества работы, улучшить условия работы людей и снизить шансы непринятия системы пользователями.

Наименование: вид процесса, характеризующего приспособленность к применению.

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

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

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

2) человеческий фактор, эргономические знания и технические приемы учитываются в системном проекте;

3) идентифицируется и выполняется деятельность по проектированию, ориентированная на человека;

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

5) системы будут обладать улучшенными показателями результативности, эффективности и удовлетворенности пользователей.

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

Процессы, виды деятельности и задачи

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

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

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

j) процесс планирования проекта (см. 6.3.1) используется для:

выбора методов и технических приемов, ориентированных на человека,

планирования совершенствования пользователей и правообладателей,

планирования ориентированной на человека деятельности при проектировании;

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

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

Примечание - Там, где возможно, используются общепризнанные профессиональные достижения практики (см., например, [7] и [12]);

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

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

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

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

q) процесс измерений (см. 6.3.7) применяется в общем случае для определения подхода, который соотносит единицы и показатели измерений с желаемыми характеристиками. Применительно к программным средствам эти вопросы детально изложены в ИСО/МЭК 25020 Программная инженерия. Требования и оценка качества программных продуктов. Эталонная модель измерений и руководство (ISO/IEC 25020 "Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide");

r) процесс анализа требований к программным средствам (см. 7.1.2) используется для спецификации требований к приспособленности и эргономике программных средств. Соответствующая задача представлена в 7.1.2.3.1.1, перечисление f и примечание 3;

s) процесс функционирования программных средств (см. 6.4.9) предназначен для использования системы. Для гарантии достижения требования к приспособленности к применению используется мониторинг функционирования системы. Соответствующие задачи включают в себя 6.4.9.3.3.1, примечание 2, 6.4.9.3.4.1 и 6.4.9.3.5.1;

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

Приложение F
(справочное)

Приложение F. НЕКОТОРЫЕ ПРИМЕРЫ ОПИСАНИЯ ПРОЦЕССОВ

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

F.1 Процесс организационной настройки

F.1.1 Цель

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

F.1.2 Выходы

В результате успешного осуществления процесса организационной настройки:

1) идентифицируются конечные цели деловой деятельности организации;

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

3) формируется стратегия определения, выполнения и совершенствования процессов;

4) обеспечивается поддержка реализации этой стратегии;

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

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

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

F.2 Процесс менеджмента организации

F.2.1 Цель

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

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

F.2.2 Выходы

В результате успешного осуществления менеджмента организации:

1) организация будет осуществлять инвестиции в соответствующую инфраструктуру менеджмента;

2) идентифицируются лучшие достижения практики для поддержки выполнения эффективного менеджмента организации и проектов;

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

F.3 Процесс менеджмента изменений в контракте

F.3.1 Цель

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

F.3.2 Выходы

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

a) открыто и официально предлагается запрос на изменение контракта;

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

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

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

e) результат каждой заявки на изменение становится известным всем участвующим сторонам.

F.3.3 Виды деятельности и задачи

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

F.3.3.1 Подготовка процесса

Данный вид деятельности состоит из решения следующих задач:

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

F.3.3.1.2 Приобретающая сторона и поставщик должны определить и документировать процедуру осуществления менеджмента изменений в контракте.

F.3.3.2 Заявка на изменение в контракте

Данный вид деятельности состоит из решения следующей задачи:

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

F.3.3.3 Исследование и анализ влияния изменений

Данный вид деятельности состоит из решения следующей задачи:

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

F.3.3.4 Переговоры и соглашения

Данный вид деятельности состоит из решения следующих задач:

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

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

F.3.3.5 Модификация контракта

Данный вид деятельности состоит из решения следующих задач:

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

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

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

Приложение G
(справочное)

Приложение G. ВЗАИМОСВЯЗИ С ДРУГИМИ СТАНДАРТАМИ IEEE

---

* IEEE - Институт инженеров по электротехнике и электронике США, разрабатывающий стандарты, признанные во всем мире. В частности, настоящий стандарт, идентичный IEEE Std 12207, был принят в качестве международного стандарта государствами-членами СТК 1 ИСО/МЭК на основе консенсуса (примеч. переводчика).

Взаимосвязи со стандартами ИСО/МЭК представлены в основной части настоящего стандарта. Цель данного справочного приложения заключается в описании взаимосвязей с другими стандартами IEEE. Ниже в таблице перечислены процессы настоящего стандарта. Для многих из этих процессов в таблице представлены стандарты IEEE, которые могут оказаться полезными при создании или выполнении конкретных процессов. В каждом случае в примечании описывается характер связей между процессами. Расположение стандартов IEEE в таблице напротив конкретных процессов является ориентировочным, так как область применения многих стандартов IEEE шире, чем у какого-либо одного процесса.

Таблица G.1

Взаимосвязи IEEE Std 12207 с другими стандартами IEEE

Полные названия стандартов IEEE перечислены ниже:

IEEE Std 730 (ТМ) - 2002

IEEE Standard for Software Quality Assurance Plans

IEEE Std 828 (ТМ) - 2005

IEEE Standard for Software Configuration Management Plans

IEEE Std 829 (ТМ) - 1998

IEEE Standard for Software Test Documentation

IEEE Std 830 (ТМ) - 1998

IEEE Recommended Practice for Software Requirements Specifications

IEEE Std 982.1 (ТМ) - 1988

IEEE Standard Dictionary of Measures to Produce Reliable Software

IEEE Std 1008 (ТМ) - 1987 (R2003)

IEEE Standard for Software Unit Testing

IEEE Std 1012 (ТМ) - 2004

IEEE Standard for Software Verification and Validation

IEEE Std 1016 (ТМ) - 1998

IEEE Recommended Practice for Software Design Descriptions

IEEE Std 1028 (ТМ) - 1997 (R2002)

IEEE Standard for Software Reviews

IEEE Std 1044 (ТМ) - 1993 (R2002)

IEEE Standard Classification for Software Anomalies

IEEE Std 1045 (ТМ) - 1992 (R2002)

IEEE Standard for Software Productivity Metrics

IEEE Std 1058 (ТМ) - 1998

IEEE Standard for Software Project Management Plans

IEEE Std 1061 (ТМ) - 1998 (R2004)

IEEE Standard for a Software Quality Metrics Methodology

IEEE Std 1062 (ТМ) - 1998 (R2002)

IEEE Recommended Practice for Software Acquisition

IEEE Std 1063 (ТМ) - 2001

IEEE Standard for Software User Documentation

IEEE Std 1074 (ТМ) - 1997

IEEE Standard for Developing Software Life Cycle Processes

IEEE Std 1175.1 (ТМ) - 2002

IEEE Guide for CASE Tool Interconnections-Classification and Description

IEEE Std 1228 (ТМ) - 1994 (R2002)

IEEE Standard for Software Safety Plans

IEEE Std 1233 (ТМ) - 1998 Edition (R2002)

IEEE Guide for Developing System Requirements Specifications

IEEE Std 1320.1 (ТМ) - 1998 (R2004)

IEEE Standard for Functional Modeling Language-Syntax and Semantics for IDEF0

IEEE Std 1320.2 (ТМ) - 1998 (R2004)

IEEE Standard for Conceptual Modeling Language-Syntax and Semantics for IDEF1X 97 (IDEF object)

IEEE Std 1362 (ТМ) - 1998

IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document

IEEE Std 1420.1 (ТМ) - 1995 (R2002)

IEEE Standard for Information Technology-Software Reuse-Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM)

IEEE Std 1420.1a (ТМ) - 1996 (R2002)

Supplement to IEEE Standard for Information Technology-Software Reuse-Data Model for Reuse Library Interoperability: Asset Certification Framework

IEEE Std 1420.1b (ТМ) - 1999 (R2002)

IEEE Trial-Use Supplement to IEEE Standard for Information Technology-Software Reuse-Data Model for Reuse Library Interoperability: Intellectual property Rights Framework

IEEE Std 1462 (ТМ) - 1998 (R2004)

IEEE Standard: Adoption of International Standard ISO/IEC 14102:1995, Information Technology - Guideline for the Evaluation and Selection of CASE tools

IEEE Std 1465 (ТМ) - 1998 (R2004)

IEEE Standard: Adoption of International Standard ISO/IEC 12119:1994(E), Information Technology-Software Packages-Quality Requirements and Testing

IEEE Std 1471 (ТМ) - 2000

IEEE Recommended Practice for Architectural Description of Software Intensive Systems

IEEE Std 1490 (ТМ) - 2003

IEEE Guide: Adoption of PMI Standard, A Guide to the Project Management Body of Knowledge (PMBOK® Guide)

IEEE Std 1517 (ТМ) - 1999 (R2004)

IEEE Standard for Information Technology-Software Life Cycle Processes-Reuse Processes

IEEE Std 1540 (ТМ) - 2001

IEEE Standard for Software Life Cycle Processes-Risk Management

IEEE/EIA 12207.1 (ТМ) - 1996

Industry Implementation of International Standard ISO/IEC 12207:1995, Standard for Information

Technology-Software Life Cycle Processes-Life Cycle Data

IEEE Std 14143.1 (ТМ) - 2000

IEEE Adoption of ISO/IEC 14143-1:1998, Information Technology-Software Measurement-Functional Size Measurement-Part 1: Definition of Concepts

IEEE Std 14764 (ТМ) - 2006

Software Engineering-Software Life Cycle Processes-Software Maintenance

IEEE P90003 - 2007

Software Engineering-Guidelines for the Application of ISO 9001:2000 Computer Software