ГОСТ Р 56923-2016/ISO/IEC TR 24748-3:2011 Информационные технологии (ИТ). Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.1.1.3

6.2, 6.3, 6.4

6.1.1.3

6.2, 6.3, 6.4

7.1, 7.2

b) Обычно в любой ситуации приобретения есть несколько подходов или способов сделать что-либо. Желателен подход или путь, который лучше всего ведет к достижению целей приобретения при ограничениях. Для использования учитываются:

1) Возможности сбыта;

2) Деловая политика;

3) Окружающая среда организации;

4) Готовность финансовых ресурсов;

5) Человеческие факторы;

6) Стратегия усовершенствования;

7) Интеграция и интероперабельность;

8) Логистика (поддерживаемость);

9) Устаревание;

10) Эксплуатационная окружающая среда;

11) Производительность;

12) Техногенная безопасность;

13) Безопасность;

14) Конкурентоспособность;

15) Цели заинтересованной стороны;

16) Жизнеспособность;

17) Ограничения рынка по времени;

18) Потенциальные риски для приобретения и поставки

6.1.1.3 а) 1)

6.1.1.3.1

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

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

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

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

6.1.1.3.1.1

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

6.1.1.3.1.2

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

6.1.1.3.1.2

f) В системах, содержащих программные средства с требованиями безопасности, может быть уместным применить стандарт IEEE Std 1228, Стандарт IEEE для планов безопасности программных средств. Учет программных средств при сертификации бортовых систем и оборудования (IEEE Standard for Software Safety Plans. RTCA DO-178B, Software Considerations in Airborne Systems and Equipment Certification), ссылка на него также может оказаться полезной

6.1.1.3.1.2

g) В системах, содержащих программные средства с высокими требованиями зависимости, может быть уместно применить стандарт IEEE Std 982.1, Стандарт IEEE Словарь показателей зависимости в программных аспектах (IEEE Standard Dictionary of Measures of the Softw* areaspects of Dependability), чтобы сформулировать измеримые требования зависимости

6.1.1.3.1.2

___________________

     * Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.    

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

6.1.1.3.1.4

i) Рассматривая опции 6.1.1.3.1.6, приобретающая сторона должна запрашивать входы от потенциальных поставщиков

6.1.1.3.1.6

j) План приобретения готовится с использованием процесса планирования проекта

6.1.1.3 а)

6.3.1

6.1.1.3.1.8

6.3.1

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

6.1.1.3.1.8

l) Для d) 6.1.1.3.1.8 поставщик ответственен за координацию контракта с субподрядчиком(ами). Если проект использует многофункциональные команды, приобретающая сторона и субподрядчик(и) могут также быть участниками команды

6.1.1.3.1.8

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

6.1.1.3.1.8

n) Так как приемка продукции или услуг обычно освобождает поставщика от ответственности по контракту, приобретающая сторона должна тщательно рассмотреть приемную стратегию и условия. Факторы для рассмотрения включают в себя:

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

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

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

4) временную поддержку поставщика/конструктора (исполнителя);

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

6) обучение;

7) гарантии.

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

6.1.1.3.1.9

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

6.1.1.3.1.10

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

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

2) поддержку после передачи в случае необходимости.

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

6.1.1.3.1.10

q) Приобретающая сторона может задать в запросе на предложение использование ИСО/МЭК 12207 и других критериев как основание для оценки процессов поставки и плана(ов) и сделать известными критерии оценки

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

6.1.1.3.1.10

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

6.1.1.3.1.10

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

6.1.1.3.1.10

6.3.7

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

6.1.1.3.1.10

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

6.1.1.3.1.11

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

6.1.1.3.1.11

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

6.1.1.3.1.11

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

6.1.1.3.1.11

у) Приобретающая сторона должна только приобрести данные жизненного цикла, которые она ожидает для использования в течение договорного периода или позже. Информационные объекты, описанные в ИСО/МЭК 15289, должны быть приспособлены к их компонентному уровню, чтобы избежать разработки и приобретения бесполезных данных. У подлежащих поставке данных должны быть содержание, местоположение, формат, медиа-отображение и упаковка, которые являются приемлемыми для организации или проекта, где они разработаны и зарегистрированы. Приобретающая сторона должна убедиться, что поставленные данные отвечают намеченным потребностям

6.1.1.3.1.11

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

6.1.1.3.1.12

7.2.6, 7.2.7

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

6.1.1.3 b)

6.1.1.3.2

bb) Критерии оценки могут включать в себя согласованность с национальными стандартами, международными стандартами, включая ИСО/МЭК 12207, и зрелость процессов

6.1.1.3.3.1

6.1.1.3.1.13

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

6.1.1.3.3.2

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

6.1.1.3 с)

6.1.1.3.4

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

6.1.1.3.4.1

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

6.1.1.3.4.2

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

6.1.1.3.4.2

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

6.1.1.3.4.2

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

1) какую информацию нужно поставить приобретающей стороне;

2) какая информация должна быть доступной для приобретающей стороны;

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

4) требования любого формата и содержания для информации;

5) когда информация должна быть произведена

6.1.1.3.4.2

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

6.1.1.3.4.3

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

6.1.1.3.4.3

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

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

6.1.1.3 d)

6.1.1.3.5

6.4.8

7.2.6

7.2.7

7.2.8

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

6.1.1.3.5.1

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

6.1.1.3.5.1

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

6.1.1.3.5.1

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

6.1.1.3.5.1

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

6.1.1.3.5.2

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

6.1.1.3 е)

6.4.6

6.4.8

6.1.1.3.6

6.4.6

6.4.8

7.1.7

7.2.3

7.2.4

7.2.5

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

6.1.1.3.6.1

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

6.1.1.3.6.1

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

6.1.1.3.6.2

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

6.1.1.3.6.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.1.2.3

6.2, 6.3, 6.4

6.1.2.3

6.2, 6.3, 6.4

7.1, 7.2

b) Ходатайство от внутренней или внешней бизнес-единицы (которая может находиться внутри проекта) является обычным явлением. Нет необходимости в том, чтобы ходатайство было формальным

6.1.2.3 а)

6.1.2.3.1

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

6.1.2.3 а)

6.1.2.3.1

d) Используя процесс планирования проекта, готовится план поставки

6.3.1

6.3.1

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

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

2) бизнес-цели единицы;

3) конкурентоспособность;

4) окружающая среда организации, политика и процедуры;

5) готовность ресурсов;

6) соответствующие риски менеджмента, технические и ресурсные риски

6.1.2.3 b)

6.1.2.3.2

f) Предпочтительно, чтобы проектная реализация по ИСО/МЭК 12207 была ориентирована применительно к требованиям организации в части соответствия ИСО/МЭК 12207

6.1.2.3.2.1

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

6.1.2.3.2.2

6.1.2.3.2.3

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

6.1.2.3.2.2

6.1.2.3.2.3

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

6.1.2.3 b)

6.1.2.3 с)

6.1.2.3.3

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

6.1.2.3.4.2

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

6.1.2.3.4.2

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

6.1.2.3.4.3

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

6.1.2.3.4.5

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

6.1.2.3.4.5 i)

6.1.2.3.4.5 j)

о) Основы измерения программных средств, установленные в 6.1.2.3.4.3, должны использоваться для сбора данных

6.1.2.3.4.5 n)

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

6.1.2.3.4.5

q) Поставщик должен сделать запись о стратегии и подходе к передаче в плане(ах) управления проектом

6.1.2.3.4.5

r) План(ы) управления проектом должен (должны) обновляться/изменяться по мере необходимости, отражать изменения в требованиях, политике и процедурах

6.1.2.3.4.6

s) Приобретающие стороны нужно держать в курсе обновлений план(ов)

6.1.2.3.4.6

t) Каждый из перечисленных процессов - это реализации соответствующих процессов организации

6.1.2.3.4.7

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

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

6.1.2.3 d)

6.1.2.3.4.8

6.4.8

7.2.6

7.2.7

7.2.8

v) Управление риском должно быть включено в предпринимаемые действия

6.1.2.3.4.8 а)

6.3.4

w) Поставщик должен использовать процесс решения проблем в программных средствах (7.2.8)

6.1.2.3.4.8 а)

7.2.8

х) Основы измерения программных средств, установленные в 6.1.2.3.4.3, должны использоваться для сбора данных

6.1.2.3.4.8

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

6.1.2.3.4.9

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

6.1.2.3.4.9

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

6.1.2.3.4.10

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

6.1.2.3.4.12

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

6.1.2.3.4.13

6.1.2.3.4.14

6.1.2.3.4.15

6.1.2.3.4.16

dd) Устанавливают, кто уполномочен принять каждый поставляемый продукт или услугу и на какой основе, включая применяемые процессы квалификации, верификации и валидации (аттестации)

6.1.2.3 е)

6.4.6

6.4.8

6.1.2.3.5

6.4.6

6.4.8

7.1.7

7.2.3

7.2.4

7.2.5

ее) Поставщик должен сделать записи о стратегии и подходе к передаче в плане управления проектом

6.1.2.3.5

6.1.2.3.6

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.1.3 а)

6.2.1.3 b)

Приложение А

6.2.1.3.1

6.2.1.3.2

Приложение А

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

6.2.1.3 а)

6.2.1.3 b)

6.2.1.3.1

6.2.1.3.2

Приложение А

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

6.2.1.3 b)

6.2.1.3.1

6.2.1.3.2

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

6.2.1.3 b)

6.2.1.3 с)

6.2.1.3.1

6.2.1.3.2

6.2.1.3.3

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

6.2.1.3 b)

6.2.1.3.2

f) ИСО/МЭК 15504 предоставляет детальное множество видов деятельности и задач для оценки процесса

6.2.1.3 b)

6.2.1.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.2.3 а)

6.2.2.3.2

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

6.2.2.3 b)

6.2.2.3.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.3.3 а)

6.2.3.3.1

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

6.2.3.3 b)

6.2.3.3.2

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

6.2.3.3 b)

6.2.3.3.2

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

6.2.3.3 а)

6.2.3.3 b)

6.2.3.3.1

6.2.3.3.1

7.3

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

6.2.3.3 b)

6.2.3.3 с)

6.3.7

6.2.3.3.2

6.2.3.3.3

6.3.7