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

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

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 a) 1)

6.1.1.3.1

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

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

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

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

6.1.1.3.1.1

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

6.1.1.3.1.2

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

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 Software aspects 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 a)

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

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

6.1.1.3.1.10

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

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

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

6.1.1.3.1.11

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

6.1.1.3.1.11

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

6.1.1.3.1.12

7.2.6, 7.2.7

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

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 c)

6.1.1.3.4

ee) В некоторых случаях требования в п. 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

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

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

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

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

6.1.1.3.5.1

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

6.1.1.3.5.1

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

6.1.1.3.5.2

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

6.1.1.3 e) 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

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

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 a)

6.1.2.3.1

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

6.1.2.3 a)

6.1.2.3.1

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

6.3.1

6.3.1

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

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 c)

6.1.2.3.3

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

6.1.2.3.4.2

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

6.1.2.3.4.2

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

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)

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

6.1.2.3.4.5 n)

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

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 a)

6.3.4

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

6.1.2.3.4.8 a)

7.2.8

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

6.1.2.3.4.8

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

6.1.2.3.4.9

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

6.1.2.3.4.9

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

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 e) 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

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

6.1.2.3.5

6.1.2.3.6

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.1.3 a)

6.2.1.3 b)

Приложение A

6.2.1.3.1

6.2.1.3.2

Приложение A

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

6.2.1.3 a)

6.2.1.3 b)

6.2.1.3.1

6.2.1.3.2

Приложение A

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

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 c)

6.2.1.3.1

6.2.1.3.2

6.2.1.3.3

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

6.2.1.3 b)

6.2.1.3.2

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

6.2.1.3 b)

6.2.1.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.2.3 a)

6.2.2.3.2

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

6.2.2.3 b)

6.2.2.3.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.3.3 a)

6.2.3.3.1

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

6.2.3.3 b)

6.2.3.3.2

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

6.2.3.3 b)

6.2.3.3.2

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

6.2.3.3 a)

6.2.3.3 b)

6.2.3.3.1

6.2.3.3.1

7.3

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

6.2.3.3 b)

6.2.3.3 c)

6.3.7

6.2.3.3.2

6.2.3.3.3

6.3.7

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.2.4.3

6.2.4.3

b) Услуги человеческих ресурсов включают в себя, но не должны этим ограничиваться:

1) приобретение ресурса;

2) оценку мастерства (навыков);

3) развитие мастерства;

4) измерение уровня мастерства;

5) эффективное применение мастерства к организационным потребностям;

6) прямую и косвенную компенсацию;

7) обретение знаний, накопление и повторное применение

6.2.4.3 a)

6.2.4.3 b)

6.2.4.3 c)

6.2.4.3 d)

6.2.4.3.1

6.2.4.3.2

6.2.4.3.3

6.2.4.3.4

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

6.2.4.3 a)

6.2.4.3 b)

6.2.4.3 c)

6.2.4.3.1

6.2.4.3.2

6.2.4.3.3

Положения

ИСО/МЭК 15288

ИСО/МЭК 12207

a) Этот процесс совместим с установлением подходов менеджмента качества, которые приводят к соответствию со стандартом ИСО 9001

6.2.5

6.2.5

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

6.2.5.3 a)

6.2.5.3 b)

6.2.5.3.1

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

7.2.3

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

6.4.6

6.4.8

7.2.4

7.2.5

7.2.7

Положения

ИСО/МЭК 15288

ИСО/МЭК 12207

a) Процесс планирования проекта определяет необходимые планы по поддержке других процессов. Например,

1) принятие решения по инвестициям;

2) подготовка обоснованного ответа на ходатайство;

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

4) руководство работой, требуемой для удовлетворения требованиям установленного соглашения;

5) повторное планирование работы

6.2.3.3 a)

6.1.2.3 b) 2)

6.3.1.3 b) 6)

6.2.3.3 c)

6.3.1.3 b)

6.3.1.3 c)

6.3.1.3 a) 1)

6.3.1.3 b) 2)

6.2.3.3.1

6.1.2.3.2

6.3.1.3.2

6.2.3.3.3

6.2.3.3.2

6.3.1.3.1

6.3.1.3.2

b) Планы ограничены организационными целями и задачами и потребностями заинтересованных сторон

6.3.1.3 b)

6.3.1.3.2

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

6.3.1.3

6.2.4

6.3.4

6.4.7

6.3.1.3

6.2.4

6.3.4

6.4.7

7.1.1

7.1.6

7.2.4

7.2.5

d) Перепланирование обычно начинается:

1) когда требуется в соответствии с соглашением;

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

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

6.3.1.3 a)

6.3.2

6.3.1.3.1

6.3.2

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

6.3.1.3 a) 1)

6.3.1.3.1

6.3.4

f) Чтобы соответствовать проекту или сложности работы, неопределенности и ресурсам, включая финансирование, планы должны быть садаптированы относительно уровня и формальностей

6.3.1.3 a)

6.3.1.3 b)

6.3.1.3.1

6.3.1.3.2

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

6.3.1.3 a) 4)

6.3.2

6.3.3

6.3.4

6.3.5

6.3.6

6.3.1.3.1

6.3.1.3.2

6.3.2

6.3.3

6.3.4

6.3.5

6.3.6

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

6.3.1.3 a) 4)

6.3.1.3.1

6.3.1.3.2

i) Нижеследующие объекты 1) - 4) должны быть полезными для того, чтобы определить проектные сроки, требования к укомплектованности и ресурсам:

6.3.1.3 b)

6.2.4

6.3.1.3.2

6.2.4

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

6.3.1.3 b)

6.3.1.3.2

2) Первичные задачи, связанные с выполнением входных и выходных критериев каждого ключевого случая (например - задачи по определению требований заинтересованной стороны, завершению комплектования технических или управленческих ревизий, проведению тестирования)

6.3.1.3 b)

6.3.1.3.2

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

- по приобретению ресурсов, оборудования и услуг;

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

- по организации командировки

6.3.1.3 b) 6.2.4

6.3.1.3.2

6.3.1.3.3

6.2.4

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

6.3.1.3 c)

6.3.1.3.2

j) После санкционированного одобрения проектные сроки считаются субъектом базовой линии для изменения управления в соответствии с организационной политикой и процедурами

6.3.1.3 b) 1)

6.3.1.3 b) 2)

6.3.1.3.2

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

6.3.1.3 b) 3)

6.3.1.3.2

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

6.3.1.3 b) 6)

6.3.1.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

a) Существуют формализованные методы по управлению стоимостью и сроками. Примеры включают:

1) Проектирование по стоимости (используется для установления требований стоимости эквивалентных другим требованиям функционирования системы);

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

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

6.3.2.3 a)

6.3.2.3.3

b) Соответствующие исследования и оценки проводятся для:

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

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

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

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

5) определения эффективности и ценности поддерживающего обучения;

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

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

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

9) оценки эффективности технического сбора, обработки и распространения данных;

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

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

6.3.2.3 a)

6.3.2.3.1

6.3.2.3.3

c) Процесс оценки проекта должен использоваться для выбора, оценки и сбора показателей системы и процесса, чтобы обеспечить информацией для поддержки менеджмента проекта. Соответственно, это включает определение:

1) развития проекта;

2) информации для реакции на риски;

3) значимых финансируемых и нефинансируемых работ;

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

6.3.2.3 a)

6.3.2.3.1

6.3.2.3.3

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

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

2) приверженность методам и процедурам;

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

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

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

6.3.2.3 a)

6.3.2.3.1

6.3.2.3.3

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

6.3.2.3 a) 1)

6.3.2.3 a) 4)

6.3.2.3 a) 6)

6.3.2.3.3.1

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

6.3.2.3 a) 5)

6.3.2.3 a) 6)

6.3.2.3.3.2

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

6.3.2.3 a) 5)

6.3.2.3 a) 8)

6.3.2.3.3

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

6.3.2.3 a) 2)

6.3.2.3 a) 6)

6.3.2.3.3

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

6.3.2.3 a) 4)

6.3.2.3 a) 5)

6.3.2.3 a) 6)

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

6.3.2.3 a) 5)

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

6.3.2.3 a) 5)

6.3.2.3.3

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

6.3.2.3 a) 6)

7.2.3

7.2.6

7.2.7

m) Типичные цели ревизии включают определение:

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

2) прослеживаемости требований, обоснованность предположений и рациональность решения;

3) идентификации нерешенных проблем и тех проблем, которые не определены во время проектной работы;

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

6.3.2.3 a) 6)

7.2.6

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

6.3.2.3 a) 6)

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

6.3.2.3 a) 7)

6.3.2.3 a) 8)

6.3.2.3 a) 9)

6.3.2.3.1

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

6.3.2.3 b)

6.3.2.3.2

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

6.3.2.3 b)

6.3.2.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

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

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

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

6.3.3.3 a)

6.3.3.3 b)

6.3.3.3.1

6.3.3.3.2

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

6.3.3.3 a) 2)

6.3.3.3 b) 1)

6.3.3.3 c)

6.3.3.3.1.3

6.3.3.3.2.1

6.3.3.3.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.3.4.1

6.3.4.1

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

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

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

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

6.3.4.3 a)

6.3.4.3.1

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

6.3.4.3 a)

6.3.4.3.1

d) Управление риском включает:

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

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

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

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

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

6.3.4.3 a)

6.3.4.3.1

e) Инструментарии для управления рисками включают в себя средства для:

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

2) анализа риска - модели воздействия, вероятностные модели, диаграмма Ганта, распределение воздействия, связь рисков, структура системы или интерфейсы организационной структуры проекта и таблицы ИСО для оценки риска;

3) планирования альтернативной стратегии противодействия рискам - таблицы ИСО для оценки риска, изученные уроки, риски при использовании, гарантии и страхование;

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

5) реакция на риски - модели воздействия, лист прогнозирования рисков, шаблон риска и матрицу менеджмента риска

6.3.4.3 a)

6.3.4.3.1

f) Ключи к успешному управлению рисками включают:

1) правильные люди. Люди сообщают проблемы, опасения и неопределенности. Это существенно, чтобы определить желательное участие, способности и мотивацию;

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

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

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

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

6.3.4.3 a)

6.3.4.3.1

g) Есть три категории риска для рассмотрения:

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

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

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

6.3.4.3 b)

6.3.4.3 c)

6.3.4.3.2

6.3.4.3.3

h) Альтернативные подходы к реакции на риски включают:

1) принятие (живут с этим);

2) избегание (исключают);

3) защиту (избыточность);

4) сокращение (смягчение, культура управления рисками - выполнение правильных процессов);

5) предотвращение (деятельность команды - использование объединенных команд);

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

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

8) исследования (больше информации);

9) резервирование (обеспечение непредвиденного);

10) передачу (другому человеку или организации)

6.3.4.3 d)

6.3.4.3 e)

6.3.4.3.4

6.3.4.3.5

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

6.3.4.3 f)

6.3.4.3.6

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.3.5.3

6.3.5.3

7.2.2.3.2

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

6.3.5.3 a) 2)

6.3.4

6.3.5.3.1.2

6.3.4

7.2.2.3.3

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

6.3.5.3 b)

6.3.5.3.2

7.2.2.3.1

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.3.6.3

6.3.6.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.3.7.3 a)

6.3.7.3.1

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

6.3.7.3 b)

6.3.7.3.2

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

6.3.7.3 c)

6.3.7.3.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.1.3

6.4.1.3

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

6.4.1.3 a)

6.4.1.3.1

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

6.4.1.3 a)

6.4.1.3.1

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

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

2) экологические, местные, национальные и международные регламенты и законы;

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

6.4.1.3 a)

6.4.1.3.1

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

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

6.4.1.3 b)

6.4.1.3 c)

6.4.1.3.2

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

6.4.1.3 b) 1)

6.4.1.3.2.2

g) Стоимость может быть требованием, заявленным как фиксированные расходы (независимая переменная) или максимальная стоимость (ограничение)

6.4.1.3 b) 1)

6.4.1.3.2.2

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

6.4.1.3 b) 2)

6.4.1.3.2.3

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

6.4.1.3 b) 2)

6.4.3

6.4.8

6.4.1.3.2.3

6.4.3

6.4.8

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

6.4.1.3 c)

6.4.1.3.4

7.2.8

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

6.4.1.3 c) 1)

6.4.1.3 c) 2)

6.4.1.3 c) 3)

6.4.1.3.3.1

6.4.1.3.4.1

6.4.1.3.4.2

l) Требования заинтересованной стороны - это основание для аттестации реализованной или скомплексированной системы, которая разработана с использованием технических процессов

6.4.1.3 c) 2)

6.4.1.3 c) 3)

6.4.1.3 c) 4)

6.4.1.3 c) 5)

6.4.1.3.4.1

6.4.1.3.4.2

6.4.1.3.4.3

6.4.1.3.5.1

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

6.4.1.3 c) 6)

6.4.1.3.5.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.2.3.1.1

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

6.4.2.3.1.1

6.4.3

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

6.4.2.3.1.1

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

6.4.2.3.1.1

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

6.4.2.3.1.1

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

6.4.2.3 a) 4)

6.4.2.3.1

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

6.4.2.3.2.1 d)

6.4.2.3.2.1 e)

h) Каждое техническое требование подлежит аттестации для гарантии того, что оно отражает следующие свойства качества:

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

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

3) корректность - сформулированное требование не содержит фактической ошибки;

4) выполнимость - требование может быть удовлетворено в пределах:

- естественных физических ограничений;

- современного состояния науки и техники относительно приложения к проекту;

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

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

6) реализуемость - сформулированное требование содержит информацию, необходимую для реализации требования быть реализованным;

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

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

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

10) тестируемость - существование конечного и объективного процесса для верификации того, что требование было выполнено;

11) верифицируемость - может быть проверено на уровне структуры системы, в которой это установлено;

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

6.4.2.3 b) 1)

6.4.2.3.2

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

1) отсутствие избыточности - каждое требование задается только один раз;

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

3) непротиворечивость - требование не находится в противоречии с другими требованиями или в пределах самого себя

6.4.2.3 b) 1)

6.4.2.3.2

j) Чтобы помочь гарантировать выполнимость требований, поставщик должен учесть:

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

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

3) возможные физические решения;

4) новые интерфейсы, которые могут быть введены

6.4.2.3 b) 1)

6.4.2.3.2

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

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

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

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

4) разрешение выявленных неохваченных аспектов, различий и противоречий, включая:

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

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

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

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

6.4.2.3 b) 3)

6.4.2.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.3.3

6.4.3.3

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

6.4.3.3.1.1

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

6.4.3.3.1.1

6.4.3.3.2.1

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

6.4.3.3.1.1

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

6.4.3.3.1.1

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

6.4.3.3.1.1

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

6.4.3.3.1.1

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

6.4.3.3.2.1 d)

6.4.3.3.2.1 e)

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

6.4.3.3.2.1 d)

e) Требования для обеспечивающих систем происходят от:

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

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

6.4.3.3 a)

6.4.3.3.1

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

6.4.3.3 a)

6.4.3.3.1

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

6.4.3.3 a)

6.4.3.3.1

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

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

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

3) выполнение аппаратными средствами, программными средствами и микропрограммными физическими элементами (новыми или существующими)

6.4.3.3 a)

6.4.3.3.1

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

6.4.3.3 b)

6.4.3.3 c)

6.4.1

6.4.2

6.4.3.3.2

6.4.1

6.4.2

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

6.4.3.3 b)

6.4.3.3 c)

6.4.1

6.4.2

6.4.3.3.2

6.4.1

6.4.2

k) При определении предпочтительных физических решений для архитектурного проекта исследования каждой альтернативы выполняются с учетом следующего:

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

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

- с другими системными элементами структуры системы;

- с обеспечивающими системами;

- с внешними системами;

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

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

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

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

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

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

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

9) потребностей, требований и ограничений для обеспечивающих систем;

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

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

12) преимуществ и недостатков в реализации системного элемента или выполнении комплексирования в пределах организации или доведении до установленного поставщика;

13) преимуществ и недостатков в использовании стандартизированных системных элементов, протоколов, интерфейсов и т.д.;

14) проблем интеграции, которые могут включать:

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

- требования встроенного теста и теста для изоляции ошибки;

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

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

6.4.3.3 b)

6.4.3.3 c)

6.4.3.3.2

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

6.4.3.3 b) 2)

6.4.3.3.2

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

6.4.3.3 b)

6.4.3.3 c)

6.4.3.3.2

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

6.4.1

6.4.2

6.4.3

6.4.1

6.4.2

6.4.3

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

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

2) функции (что должно быть достигнуто) и функционирования (как хорошо каждая функция должна быть выполнена);

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

4) интерфейса и характеристик взаимозаменяемости;

5) средств для верификации соответствия

6.4.3.3 c) 1)

6.4.3.3.1

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

6.4.3.3 c) 1)

6.4.1

6.4.2

6.4.3.3.1

6.4.1

6.4.2

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

6.4.3.3 c) 1)

6.4.1

6.4.2

6.4.3.3.1

6.4.1

6.4.2

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

6.4.3.3 c) 1)

6.4.4

6.4.5

6.4.6

6.4.7

6.4.8

6.4.3.3.1

6.4.4

6.4.5

6.4.6

6.4.7

6.4.8

7.1.1

7.1.6

7.2.4

7.2.5

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

1) как должно быть выполнено требование;

2) как должна быть построена система

6.4.3.3 c) 1)

6.4.3.3.1

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

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

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

3) устранение выявленных упущений, отклонений и противоречий, включая:

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

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

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

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

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

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

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

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

6.4.3.3 c)

6.4.3.3.1

6.4.3.3.2

u) Описание базовой линии решения архитектурного проекта используется для управления конфигурацией рассматриваемой системы или системного элемента

6.4.3.3 c)

6.4.3.3.1

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

6.4.3.3 c)

6.4.3.3.1

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

6.4.3

6.4.3

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

a) См. также табл. A.26 - Процесс реализации программного средства (п. 7.1.1)

6.4.4

7.1.1

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

6.4.4.3 a)

7.1.1.3.1

c) Системный элемент - или единичный продукт или композиция продуктов в зависимости от его уровня в структуре системы и его способности быть закупленным или реализованным

6.4.4.3 b)

7.1.1.3.1

d) Системные элементы, состоящие исключительно из программных элементов, могут быть:

1) закуплены у поставщика или продавца,

2) закодированы внутри организации или

3) повторно использованы

6.4.4.3 b)

7.1.1.3.1

e) Аспекты, учитываемые при формировании стратегии реализации, включают:

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

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

3) безопасность, факторы частной жизни и собственности, экологические факторы;

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

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

6) характеристики операторов;

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

6.4.4.3 a)

7.1.1.3.1

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

6.4.4.3 b)

6.4.6

6.4.8

7.1.1.3.1

7.2.4

7.2.5

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

6.4.4.3 b)

7.1.1.3.1

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.5.3 b)

7.1.6.3.1

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

6.4.5.3 b)

6.4.5.3.2

7.1.6.3.1

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

d) какая тестовая документация должна быть подготовлена;

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

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

6.4.5.3.1.1

6.4.5.3.2.1

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

6.4.5.3.1.1

6.4.5.3.2.1

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

6.4.5.3.1.1

6.4.5.3.2.1

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.6.3 b)

6.4.6.3.1

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

6.4.6.3.1

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.7.3 a)

6.4.7.3.1

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

6.4.7.3.1.1

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

6.4.7.3 b)

6.4.7.3.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.8.3 a)

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

6.4.8.3 a)

6.4.8.3 b)

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

6.4.8.3 b)

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

6.4.8.3 b)

e) Если это применимо, поставка программной продукции включает:

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

- описание требований упаковки;

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

- процедуры модификации программных средств;

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

- описание версии программных средств

6.4.8.3.1.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.9.3 a)

6.4.9.3.1

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

6.4.9.3 a)

6.4.9.3.1

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

6.4.9.3 a)

6.4.9.3.1

d) Испытательные используемые процедуры могут быть процедурами, ранее разработанными конструктором (исполнителем), приобретающей или иной стороной

6.4.9.3.1.3

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

6.4.9.3.5.2

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.10.3 a)

6.4.10.3.1

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

6.4.10.3 a)

6.4.10.3.1

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

6.4.10.3 a)

6.4.10.3.1

6.4.10.3.3

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

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

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

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

6.4.10.3.3.1

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

6.4.10.3.3.1

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

6.4.10.3.3.2

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

6.4.10.3.3.2

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

6.4.10.3.5.3 a)

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

6.4.10.3.5.4

Положение

ИСО/МЭК 15288

ИСО/МЭК 12207

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

6.4.11.3 a)

6.4.11.3.1

b) Процесс прекращения применения программного средства также применим к любым обеспечивающим системам для этой стадии

6.4.11.3 a)

6.4.11.3.1

c) Для постепенного выведения программного продукта из эксплуатации должно быть разработано соответствующее расписание

6.4.11.3.2.2 b)

Положение

ИСО/МЭК 12207

a) См. также таблицу 18 - Процесс реализации (6.4.4)

6.4.4.3

b) Если нет предложений от приобретающей стороны или поставщика, конструктор (исполнитель) должен установить соответствующую модель(и) жизненного цикла прежде, чем переходить к процессу реализации программных средств. Содержание процесса реализации программных средств и распределение по модели жизненного цикла должны включать действия и задачи для осуществления процесса, когда они могут быть проведены и ответственных лиц за выполнение действий и задач. Дополнительное руководство по использованию моделей жизненного цикла программных средств может быть найдено в стандарте IEEE Std 1074, IEEE стандарт для разработки процесса жизненного цикла программных средств (Standard for Developing a Software Project Life Cycle Process)

7.1.1.3.1.1

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

7.1.1.3.1.2 a)

7.2.1

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

7.1.1.3.1.2 b)

7.2.2

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

7.1.1.3.1.3

7.3

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

7.1.1.3.1.4

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

7.1.1.3.1.4

h) Планирование реализации программного средства должно быть основано на модели его жизненного цикла (см. 7.1.1.3.1.1)

7.1.1.3.1.4

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

7.1.1.3.1.4

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

7.1.1.3.1.5

Положение

ИСО/МЭК 12207

a) См. также таблицу 16 - Процесс анализа системных требований (подпункт 6.4.2)

6.4.2.3

b) ИСО/МЭК 25030 определяет шесть качественных характеристик для использования: функциональность, надежность, применимость, эффективность, сопровождаемость и мобильность

7.1.2.3.1.1

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

7.1.2.3.1.1

d) Руководство относительно планов безопасности программных средств может быть найдено в стандарте IEEE 1228, IEEE стандарт для планов безопасности программных средств

7.1.2.3.1.1

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

7.1.2.3.1.2 e)

7.1.2.3.1.2 f)

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

7.1.2.3.1.3

Положение

ИСО/МЭК 12207

a) См. также таблицу 17 - Процесс проектирования архитектуры системы (6.4.3)

6.4.3.3

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

7.1.3.3.1.1

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

7.1.3.3.1.1

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

7.1.3.3.1.1

e) Конструкторское описание архитектуры программных средств включает описание замысла выполнения с участием программных компонентов

7.1.3.3.1.1

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

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

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

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

4) к подходу для ревизий проектной информации участниками проектирования.

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

7.1.3.3.1.1

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

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

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

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

4) к отношению программного архитектурного проекта с детальным проектом;

5) к подходу для ревизий проектной информации участниками проектирования;

6) к подходу к тестированию при программном комплексировании.

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

7.1.3.3.1.1

h) Архитектура программных средств должна быть совместимой с архитектурой системы

7.1.3.3.1.1

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

7.1.3.3.1.2

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

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

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

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

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

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

7.1.3.3.1.3

7.1.3.3.1.4

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

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

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

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

7.1.3.3.1.5

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

7.1.3.3.1.6

m) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE Std 1028 Стандарт IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits) может быть полезным в осуществлении этого требования

7.1.3.3.1.7

7.2.6

Положение

ИСО/МЭК 12207

a) Конструкторское детальное описание проекта должно включать описание каждой программной единицы (блока) программного объекта

7.1.4.3.1.1

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

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

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

3) к уровню деталей, связанных с детальным проектом;

4) к отношению детального проекта с отдельно компилируемой программной сущностью (объектом) и к отдельно выполнимой программной сущности (объекту);

5) к подходу для ревизий проектной информации участниками проектирования;

6) к подходу для тестирования единиц (блоков).

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

7.1.4.3.1.1

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

7.1.4.3.1.2

7.1.4.3.1.3

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

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

2) когда информация должна быть готова;

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

7.1.4.3.1.4

7.1.4.3.1.5

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

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

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

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

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

7.1.4.3.1.6

f) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE 1028 стандарт IEEE для ревизий и аудитов программных средств (IEEE Standard for Software Reviews and Audits) может быть полезным в осуществлении этого требования

7.1.4.3.1.8

7.2.6

Положение

ИСО/МЭК 12207

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

7.1.5.3.1.1

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

7.1.5.3.1.1

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

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

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

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

7.1.5.3.1.2

7.1.5.3.1.3

7.1.5.3.1.4

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

7.1.5.3.1.5

Положение

ИСО/МЭК 12207

a) См. также таблицу 19 - Процесс комплексирования системы (подпункт 6.4.5)

6.4.5.3

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

7.1.6.3.1.1

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

7.1.6.3.1.2

d) В ИСО/МЭК 12207 тест состоит из одного или более тестовых случаев

7.1.6.3.1.2

7.1.6.3.1.4

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

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

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

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

7.1.6.3.1.4

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

7.1.6.3.1.2

7.1.6.3.1.4

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

7.1.6.3.1.4

h) Проведение ревизий включает планирование и принятие участия в совместных технических и управленческих ревизиях. Стандарт IEEE 1028, IEEE Standard for Software Reviews and Audits может быть полезным в осуществлении этого требования

7.1.6.3.1.6

7.2.6

Положение

ИСО/МЭК 12207

a) См. также таблицу 20 - Процесс квалификационного тестирования системы (6.4.6)

6.4.6.3

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

7.1.7.3.1.1

Положение

ИСО/МЭК 12207

a) См. также таблицу 13 - Процесс менеджмента информации (6.3.6)

6.3.6.3

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

7.2.1.3.2.1

Положение

ИСО/МЭК 12207

a) См. также таблицу 12 - Процесс менеджмента конфигурации (6.3.5)

6.3.5.3

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

7.2.2.3.1.1

c) Дополнительное руководство по управлению конфигурацией может быть найдено в ИСО 10007

7.2.2.3.1.1

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

7.2.2.3.2.1

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

7.2.2.3.3.1

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

7.2.2.3.3.1

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

7.2.2.3.4.1

h) Управление выпуском и требования поставки обращаются к стороне, которая выпускает программную продукцию

7.2.2.3.6.1

Положение

ИСО/МЭК 12207

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

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

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

7.2.3.3.1.1

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

7.2.3.3.1.2

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

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

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

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

7.2.3.3.1.2

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

7.2.3.3.1.2

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

7.2.3.3.1.3 e)

f) Три главных требования существуют в 7.2.3.3.1.6 с возможно различными сторонами, ответственными за разные части:

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

2) ответственность начать и эффектно решать проблемы;

3) ответственность за верификацию решений проблем.

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

7.2.3.3.1.6

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

7.2.3.3.2.3

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

7.2.3.3.2.3

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

7.2.3.3.2.3

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

7.2.3.3.4.1

Положение

ИСО/МЭК 12207

Нет руководства

-

Положение

ИСО/МЭК 12207

Нет руководства

-

Положение

ИСО/МЭК 12207

a) Вопросы риска должны быть включены в ревизии

7.2.6.3.1.3

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

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

2) решить в совместных технических ревизиях проблемы, которые не могли быть решены;

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

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

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

7.2.6.3.2

c) Поставщик, включая конструктора (исполнителя) и/или сопровождающую сторону и/или оператора, если применимо, должны запланировать и принять участие в объединенных технических ревизиях в местоположении и в сроки, предлагаемые поставщиком и согласуемые приобретающей стороной. Эти ревизии должны быть посещаемы специалистами с техническим знанием программных продуктов, которые будут проводить ревизии. Дисциплины процесса поддержки (например, обеспечения качества, управления конфигурацией, верификация, аттестация) должны обеспечить вход процесса или использоваться в совместных ревизиях. Ревизии в большей степени должны сосредоточиваться на незавершенных и заключительных продуктах программных средств, нежели на материалах, произведенных специально для ревизии. У ревизий могут быть следующие цели:

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

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

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

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

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

7.2.6.3.3

Положение

ИСО/МЭК 12207

Нет руководства

-

Положение

ИСО/МЭК 12207

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

7.2.8.3.1

Положение

ИСО/МЭК 12207

Нет руководства

-

Положение

ИСО/МЭК 12207

Нет руководства

-

Положение

ИСО/МЭК 12207

Нет руководства

-