"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ. ГОСТ Р ИСО/МЭК 12207-2010" (утв. Приказом Ростехрегулирования от 30.11.2010 N 631-ст)
6.4 Технические процессы
6.4.1 Процесс определения требований правообладателей
Примечание - Процесс определения требований правообладателей в настоящем стандарте является специальным случаем процесса определения требований правообладателей в [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.1.1 Цель
Цель процесса определения требований правообладателей состоит в выявлении требований к системе, выполнение которых может обеспечивать предоставление услуг, необходимых пользователям и другим правообладателям в заданной среде применения.
Этот процесс позволяет определять правообладателей или классы правообладателей, которые связаны с системой на протяжении всего ее жизненного цикла, а также их потребности и пожелания. В рамках процесса они анализируются и преобразуются в общую совокупность требований правообладателей, которые описывают желаемое поведение системы в процессе взаимодействия со средой применения. Она служит в качестве ссылки, по отношению к которой каждая предоставляемая услуга подвергается валидации для подтверждения того, что система полностью удовлетворяет заявленным требованиям.
6.4.1.2 Выходы
В результате успешного осуществления процесса определения требований правообладателей:
a) задаются требуемые характеристики и условия использования услуг;
b) определяются ограничения для системных решений;
c) достигается возможность прослеживания от требований правообладателей к правообладателям и их потребностям;
d) описывается основа для определения системных требований;
e) определяется основа для валидации соответствия услуг;
f) формируется основа для ведения переговоров и заключения соглашений о поставке услуги или продукции.
6.4.1.3 Виды деятельности и задачи
При реализации проекта должны осуществляться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса определения требований правообладателя.
6.4.1.3.1 Идентификация правообладателей
Данный вид деятельности состоит из решения следующей задачи:
6.4.1.3.1.1 При реализации проекта необходимо идентифицировать отдельных правообладателей или классы правообладателей, имеющих законный интерес к системе в течение ее жизненного цикла.
Примечание - К ним относятся, по крайней мере: пользователи, операторы, организации поддержки, разработчики, производители, обучающие организации, организации технического обслуживания и ремонта, организации, распоряжающиеся ресурсами, приобретающие стороны и организации поставщика, стороны, ответственные за интерфейс с внешними объектами, регулирующие органы и представители общественности. В случае, если непосредственная коммуникация неосуществима (например, для потребительских товаров и услуг), выбираются представители или доверенные лица правообладателей.
6.4.1.3.2 Идентификация требований
Данный вид деятельности состоит из решения следующих задач:
6.4.1.3.2.1 Должны быть выявлены требования правообладателей проекта.
Примечание - Требования правообладателей могут выражаться в форме потребностей, пожеланий, требований, ожиданий и воспринятых ограничений отдельных правообладателей, которые, в свою очередь, выражаются в терминах модели (текстовой или формализованной), ориентированной на цели и поведение системы и описывающей ее в контексте среды и условий функционирования. Для осуществления этих действий может быть полезной модель качества продукции и требований к качеству, таких как установленные в [8] и [29]. В требованиях правообладателей должны учитываться нужды, потребности общества и ограничения, налагаемые приобретающей организацией, а также возможностями и способностями пользователей и оперативного персонала. Рекомендуется ссылаться на источники, например, на ходатайства или соглашения, их законность и обоснования, а также на допущения правообладателей и значение, которое правообладатели придают выполнению своих требований. Для потребностей ключевых правообладателей необходимо устанавливать показатели результативности, определенные таким образом, чтобы эксплуатационные характеристики могли быть измерены и оценены. Если значительные риски являются вероятным результатом возникающих вопросов (т.е. потребностей, пожеланий, ограничений, пределов, обеспокоенности, препятствий, факторов или соображений), имеющих отношения к людям (пользователям и другим правообладателям) и их вовлечению или взаимодействию с системой на любом отрезке времени в процессе жизненного цикла этой системы. Рекомендации по вопросам идентификации и трактовки взаимодействия человека с системой содержатся в [24].
6.4.1.3.2.2 В проекте необходимо определять ограничения системных решений, которые являются неизбежным следствием существующих соглашений, управленческих и технических решений.
Примечание - Ограничения могут возникать в результате:
1) примеров или областей решений, определенных правообладателями;
2) реализации решений, принятых на более высоком уровне системной иерархии;
3) требований по использованию определенных обеспечивающих систем, ресурсов и штатного персонала.
6.4.1.3.2.3 В проекте необходимо определять представительную совокупность последовательности видов деятельности для идентификации всех требуемых услуг, соответствующих ожидаемым рабочим сценариям и сценариям поддержки в заданных условиях применения.
Примечание - Сценарии используются для анализа функционирования системы в заданной среде применения с целью установления требований, которые формально не были заданы ни одним из правообладателей, например, юридические, регулирующие и социальные обязательства. Определяются и анализируются условия использования системы. Следует включать в содержание анализ действий, которые выполняют пользователи для достижения системных целей, релевантных характеристик конечных пользователей системы (например, предполагаемого обучения, степени выносливости), характеристик физической среды (например, уровня освещенности, температуры), а также любого используемого оборудования (например, оборудования для защиты или связи). Также анализируются социальные и организационные воздействия на пользователей, которые могут повлиять на применение системы или ограничивать проектные решения.
6.4.1.3.2.4 При реализации проекта необходимо определять взаимодействие между пользователями и системой, принимая во внимание способности человека и ограниченность его навыков.
Примечание 1 - Определяют требования приспособленности к работе, устанавливающие, как минимум, наиболее эффективные, результативные и надежные рабочие характеристики человека и его взаимодействия с системой. По возможности используют соответствующие стандарты, например [12], и признанные профессиональные достижения для определения:
1) физических, умственных способностей и способностей к обучению;
2) рабочих мест, условий окружающей среды и обеспечивающих эти условия средств, включая другое оборудование в контексте его применения;
3) нормальных, необычных и чрезвычайных ситуаций;
4) принятия на работу, обучения и развития операторов и пользователей.
Примечание 2 - Если приспособленность к работе имеет важное значение, то требования к ней следует планировать, задавать и выполнять через процессы жизненного цикла. Для получения желаемого уровня приспособленности к работе могут быть использованы [12], [14] и [25]. Вид процесса, фокусирующегося на приспособленности к работе, приведен в приложении Е.
6.4.1.3.2.5 В проекте необходимо установить требования к здоровью, безопасности, защищенности, окружающим условиям и другие требования и функции правообладателей, имеющие отношение к критическим свойствам. При этом необходимо учесть возможные неблагоприятные воздействия использования системы на здоровье и безопасность человека.
Примечание - Следует идентифицировать риски по безопасности и, если необходимо давать гарантии, устанавливать требования и функции для обеспечения безопасности. Сюда относятся риски, связанные с методами работы и поддержки, со здоровьем и безопасностью, угрозами собственности и воздействиями окружающей среды. При этом необходимо использовать соответствующие стандарты и признанные достижения практики в профессиональной сфере. Необходимо идентифицировать риски по защите и, если предоставляются гарантии, устанавливать все возможные области защиты системы, включая физические, процедурные, коммуникационные, компьютерные, программные, области данных и защиты от излучений. Необходимо определить функции, которые могут влиять на защищенность системы, в том числе на доступ и нанесение вреда персоналу, собственности и информации, дискредитацию важной информации и отказ в санкционированном доступе к собственности и информации. Необходимо установить требуемые функции защищенности, включая уменьшение и сдерживание угроз, ссылаясь на соответствующие стандарты и признанные достижения практики как на обязательные или уместные.
6.4.1.3.3 Оценка требований
Данный вид деятельности состоит из решения следующей задачи:
6.4.1.3.3.1 В проекте необходимо анализировать полную совокупность выявленных требований.
Примечание - Анализ включает в себя идентификацию и назначение приоритетов для противоречивых, пропущенных, неполных, неоднозначных, несовместимых, несоответствующих или непроверяемых требований.
6.4.1.3.4 Согласование требований
Данный вид деятельности состоит из решения следующих задач:
6.4.1.3.4.1 В проекте должны решаться проблемы, относящиеся к требованиям.
Примечание - К ним относятся требования, которые не могут быть реализованы или которые нецелесообразно выполнять.
6.4.1.3.4.2 В проекте должна предусматриваться обратная связь от проанализированных требований к соответствующим правообладателям для гарантии того, что их потребности и ожидания были правильно зафиксированы и выражены.
Примечание - Необходимо давать пояснения и достигать согласия по предложениям, касающимся противоречивых, нецелесообразных и неосуществимых требований правообладателей.
6.4.1.3.4.3 В проекте необходимо совместно с правообладателями определять корректность выражения их требований.
Примечание - К этой задаче относится подтверждение того, что требования правообладателей понимаются их создателями и что разрешение противоречий в требованиях не нарушает или не компрометирует намерений правообладателей.
6.4.1.3.5 Регистрация требований
Данный вид деятельности состоит из решения следующих задач:
6.4.1.3.5.1 В проекте должны регистрироваться требования правообладателей в форме, приемлемой для менеджмента требований в течение жизненного цикла и за его пределами.
Примечание - Эти записи устанавливают базовую линию требований правообладателей и сохраняют информацию об изменениях в потребностях и их происхождении в течение жизненного цикла системы. Они являются основой прослеживаемости к системным требованиям и формирования источника знаний при задании требований к последующим системам и контактах с правообладателями по статусу этих требований.
6.4.1.3.5.2 Проект должен поддерживать прослеживаемость требований правообладателей к источникам потребностей правообладателей.
Примечание - Требования правообладателей проверяются в моменты принятия ключевых решений в процессе жизненного цикла для гарантии того, что учитываются любые изменения потребностей.
6.4.2 Процесс анализа системных требований
Примечание - Процесс анализа системных требований в настоящем стандарте является специальным случаем процесса анализа требований в [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
Цель анализа системных требований состоит в преобразовании определенных требований правообладателей в совокупность необходимых системных технических требований, которыми будут руководствоваться в проекте системы.
6.4.2.2 Выходы
В результате успешного осуществления анализа системных требований:
a) устанавливается определенная совокупность системных функциональных и нефункциональных требований, описывающих проблему, подлежащую решению;
b) выполняются соответствующие технические приемы оптимизации предпочитаемого проектного решения;
c) системные требования анализируются на корректность и тестируемость;
d) осмысливается воздействие системных требований на среду применения;
e) требования расставляются по приоритетам, утверждаются и обновляются;
f) устанавливается согласованность и прослеживаемость между системными требованиями и базовой линией требований заказчика;
g) оцениваются изменения базовой линии по стоимости, графикам работ и воздействию технических решений;
h) системные требования доводятся до сведения всех участвующих сторон и включаются в базовую линию.
6.4.2.3 Виды деятельности и задачи
В проекте должны выполняться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса анализа системных требований:
6.4.2.3.1 Спецификация требований
Данный вид деятельности состоит из решения следующих задач:
6.4.2.3.1.1 Должны быть проанализированы особенности планируемого применения разрабатываемой системы для задания системных требований. Спецификация системных требований должна описывать: функции и возможности системы; требования деловой сферы, организационные и пользовательские требования; требования по безопасности, защищенности, эргономике, интерфейсам, рабочим операциям и сопровождению; проектные ограничения и квалификационные требования. Спецификация системных требований должна быть документирована.
Примечание 1 - Следует применять соответствующие технические приемы для оптимизации предпочтительных решений.
Примечание 2 - Необходимо подвергать осмыслению воздействие системных требований на среду функционирования.
Примечание 3 - Системные требования следует расставлять по приоритетам, утверждать, фиксировать в базовой линии и сообщать всем участвующим сторонам. Обновления к базовой линии требований следует оценивать по затратам, выполнению графиков работ и влиянию технических решений.
6.4.2.3.2 Оценивание требований
Данный вид деятельности состоит из решения следующих задач:
6.4.2.3.2.1 Системные требования должны оцениваться на основе перечисленных ниже критериев:
a) прослеживаемость потребностей по приобретению;
b) согласованность с потребностями по приобретению;
c) тестируемость;
d) осуществимость архитектурного проекта системы;
e) осуществимость функционирования и сопровождения.
Результаты оценивания должны быть документированы.
Примечание - Потребности приобретения включают в себя базовую линию требований правообладателей.
6.4.3 Процесс проектирования архитектуры системы
Примечание - Процесс проектирования архитектуры системы в настоящем стандарте является специальным случаем процесса проектирования архитектуры в [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.3.1 Цель
Цель процесса проектирования архитектуры системы заключается в определении того, как системные требования следует распределить относительно элементов системы.
В результате успешного осуществления процесса проектирования архитектуры системы:
a) определяется архитектурный проект системы, в соответствии с которым выполняется идентификация элементов системы и удовлетворяются заданные требования;
b) устанавливаются функциональные и нефункциональные системные требования;
c) требования распределяются по элементам системы;
d) определяются внутренние и внешние интерфейсы каждого системного элемента;
e) выполняется верификация между системными требованиями и архитектурой системы;
f) требования, распределенные по системным элементам и их интерфейсам, становятся прослеживаемыми к базовой линии требований заказчика;
g) поддерживается согласованность и прослеживаемость между системными требованиями и архитектурным проектом системы и
h) системные требования, конструкция, архитектурный проект системы и их взаимосвязи отражаются в базовой линии и сообщаются всем участвующим сторонам;
i) в системный проект включается человеческий фактор, эргономические знания, технические приемы, методы и средства;
j) определяются и выполняются действия по проектированию, ориентированные на человека.
6.4.3.3 Виды деятельности и задачи
В проекте должны выполняться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса проектирования архитектуры системы:
6.4.3.3.1 Создание архитектуры
Данный вид деятельности состоит из решения следующей задачи:
6.4.3.3.1.1 Должен быть определен верхний уровень архитектуры системы. Архитектура должна идентифицировать составные части технических средств, программных средств и ручных операций. Должно гарантироваться, что все системные требования распределяются между этими составными частями. Составные части конфигурации технических средств, программных средств и ручных операций должны последовательно идентифицироваться этими составными частями. Архитектура системы и системные требования, распределенные по составным частям, должны быть документированы.
Примечание 1 - Внутренние и внешние интерфейсы каждого системного элемента следует определять в архитектуре системы.
Примечание 2 - Следует определять и выполнять действия по проектированию, ориентированные на человека. При этом следует внедрять в системное проектирование человеческий фактор, эргономические знания, методы и средства.
Примечание 3 - Архитектурный проект системы и его отношение с системными требованиями следует отражать в базовой линии и доводить до сведения всех участвующих сторон.
6.4.3.3.2 Оценивание архитектуры
Данный вид деятельности состоит из решения следующей задачи:
6.4.3.3.2.1 Архитектура системы и требования к составным частям должны быть оценены с учетом перечисленных ниже критериев:
a) прослеживаемость системных требований;
b) согласованность с системными требованиями;
c) приспособленность стандартов и методов проектирования;
d) осуществимость программных составных частей, полностью удовлетворяющих назначенным требованиям;
e) осуществимость функционирования и сопровождения.
Примечание - Следует также обеспечивать прослеживаемость архитектуры системы к системным требованиям для прослеживаемости к базовой линии требований правообладателей.
Результаты оценок должны быть документированы.
6.4.4.1 Цель
Цель процесса реализации заключается в создании заданных элементов системы.
Примечание - Пользователи настоящего стандарта могут иметь намерение работать с программными продуктами или программными элементами больших систем. Процесс реализации программных средств (см. 7.1.1) является соответствующим примером процесса реализации в [18], приспособленного к частным потребностям реализации программного продукта или услуги. Процесс реализации программных средств заменяет процесс реализации в [18].
6.4.5 Процесс комплексирования системы
Примечание - Процесс комплексирования системы в настоящем стандарте является частным случаем процесса комплексирования в [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.5.1 Цель
Цель процесса комплексирования системы заключается в объединении системных элементов (включая составные части технических и программных средств, ручные операции и другие системы, при необходимости) для производства полной системы, которая будет удовлетворять системному проекту и ожиданиям заказчика, выраженным в системных требованиях.
6.4.5.2 Выходы
В результате успешного осуществления процесса комплексирования системы:
a) определяется стратегия комплексирования системы в соответствии с приоритетами системных требований;
b) разрабатываются критерии для верификации соответствия с системными требованиями, распределенными по элементам системы, включая интерфейсы между ними;
c) верифицируется комплексированная система с применением определенных критериев;
d) разрабатывается и применяется стратегия регрессии для повторного тестирования системы в случае, если выполняются изменения;
e) устанавливается согласованность и прослеживаемость между системным проектом и интегрированными элементами системы;
f) конструируется комплексированная система, демонстрирующая соответствие с системным проектом;
g) конструируется комплексированная система, демонстрирующая существование полной совокупности пригодных для применения поставляемых системных элементов.
6.4.5.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности и решать задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса комплексирования системы.
6.4.5.3.1 Комплексирование
Данный вид деятельности состоит из решения следующей задачи:
6.4.5.3.1.1 Составные части конфигурации программных средств при необходимости должны быть объединены в единую систему с составными частями конфигурации технических средств, ручными операциями и другими системами. Агрегированные части должны быть проверены, так как они разрабатываются в соответствии со своими требованиями. Процесс комплексирования и результаты тестирования должны быть документированы.
Примечание 1 - Действия по комплексированию системы следует выполнять согласно предварительно определенной стратегии комплексирования, которая учитывает приоритеты системных требований.
Примечание 2 - В стратегии комплексирования следует установить согласованность и прослеживаемость между конструкцией системы и комплектованными элементами системы.
6.4.5.3.2 Готовность к тестированию
Данный вид деятельности состоит из решения следующих задач:
6.4.5.3.2.1 Для каждого квалификационного требования системы должны быть разработаны и документированы: набор тестов, тестовые примеры (входы, выходы, критерии тестирования) и процедуры тестирования. Разработчик должен гарантировать готовность комплексированной системы к квалификационному тестированию.
Примечание - Следует разработать стратегию регрессии, которая будет применяться для повторного тестирования в случаях, если в системе проводятся изменения.
6.4.5.3.2.2 Комплексированная система должна быть оценена с учетом следующих критериев:
a) тестовое покрытие системных требований;
b) применимость методов тестирования и используемых стандартов;
c) соответствие ожидаемым результатам;
d) осуществимость квалификационного тестирования системы;
e) осуществимость функционирования и сопровождения.
Результаты оценки должны быть документированы.
6.4.6 Процесс квалификационного тестирования системы
Примечание - Процесс квалификационного тестирования системы в настоящем стандарте дополняет выходы процесса верификации в [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.6.1 Цель
Цель процесса квалификационного тестирования системы заключается в подтверждении того, что реализация каждого системного требования тестируется на соответствие и система готова к поставке.
6.4.6.2 Выходы
В результате успешного осуществления процесса квалификационного тестирования системы:
a) разрабатываются критерии для оценки соответствия системным требованиям;
b) комплексированная система тестируется, используя определенные критерии;
c) документируются результаты тестирования;
d) гарантируется готовность системы для поставки.
6.4.6.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса квалификационного тестирования системы.
6.4.6.3.1 Квалификационное тестирование
Данный вид деятельности состоит из решения следующих задач:
6.4.6.3.1.1 Квалификационное тестирование системы должно проводиться в соответствии с квалификационными требованиями, установленными для системы. Должны обеспечиваться гарантии проверки выполнения каждого системного требования и готовности системы к поставке. Результаты квалификационного тестирования должны быть документированы.
Примечание - В квалификационные требования для системы следует включать критерии оценки соответствия системным требованиям.
6.4.6.3.1.2 Система должна быть оценена с учетом перечисленных ниже критериев:
a) тестовое покрытие системных требований;
b) соответствие ожидаемым результатам;
c) осуществимость функционирования и сопровождения.
Примечание - Критерии оценки следует ориентировать на готовность системы к поставке.
Результаты оценки должны быть документированы.
6.4.6.3.1.3 Разработчик должен поддерживать проведение аудитов в соответствии с 7.2.7. Результаты аудитов должны быть документированы.
Примечание - Пункт 7.2.7 не применяется к тем элементам конфигурации программных средств, для которых аудиторские проверки проводились ранее.
6.4.6.3.1.4 После успешного окончания аудита (если он проводился) разработчик должен доработать и подготовить поставляемый программный продукт к инсталляции и поддержке его приемки.
Примечание - Процесс квалификационного тестирования системы может использоваться в процессе верификации программных средств (см. 7.2.4) или в процессе валидации программных средств (см. 7.2.5).
6.4.7 Процесс инсталляции программных средств
Примечание - Процесс инсталляции программных средств в настоящем стандарте дополняет выходы процесса передачи из [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.7.1 Цель
Цель процесса инсталляции программных средств заключается в установке программного продукта, удовлетворяющего заданным требованиям, в целевую среду применения.
6.4.7.2 Выходы
В результате успешного осуществления процесса инсталляции программных средств:
a) разрабатывается стратегия инсталляции программных средств;
b) разрабатываются критерии для инсталляции программных средств, предназначенные для демонстрации соответствия с требованиями к инсталляции программных средств;
c) программный продукт инсталлируется в целевую среду;
d) обеспечивается готовность программного продукта для использования в среде его применения.
6.4.7.3 Виды деятельности и задачи
В процессе реализации проекта должны осуществляться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса инсталляции программных средств.
6.4.7.3.1 Инсталляция программных средств
Данный вид деятельности состоит из решения следующих задач:
6.4.7.3.1.1 Исполнитель должен разработать план инсталляции программного продукта в среду его применения, как определено в контракте. Ресурсы и информация, необходимые для инсталляции программного продукта, должны быть определенны и быть в наличии. Как установлено в контракте, исполнитель должен содействовать приобретающей стороне при проведении установки. Если инсталлируемый программный продукт заменяет существующую систему, то исполнитель должен поддерживать любые параллельно выполняемые действия, которые требуются в соответствии с контрактом. План инсталляции должен быть документирован.
Примечание 1 - Стратегию инсталляции программных средств следует разрабатывать, согласуя с заказчиком и эксплуатирующей организацией.
Примечание 2 - Важной частью разработки стратегии инсталляции является разработка стратегии возврата к последней рабочей версии системы. Для проведения повторной инсталляции последней рабочей версии следует сделать полную резервную копию системы до начала инсталляции.
Примечание 3 - Основываясь на требованиях к инсталляции, проводящему ее исполнителю следует определить критерии для среды, в которой программное средство будет установлено.
Примечание 4 - Исполнителю следует конкретизировать требования к адаптации системы в среде применения.
Примечание 5 - Исполнителю следует адаптировать систему для удовлетворения требований к функционированию.
6.4.7.3.1.2 Разработчик должен инсталлировать программный продукт в соответствии с планом инсталляции. Необходимо гарантировать, что базы данных и программный код инициализируются, выполняются и отменяются, как установлено в контракте. События, происшедшие при инсталляции, и их результаты должны документироваться.
Примечание - Исполнителю следует гарантировать готовность программного продукта к применению в предназначенной для него среде.
6.4.8 Процесс поддержки приемки программных средств
Примечание - Процесс поддержки приемки программных средств в настоящем стандарте дополняет выходы процесса передачи из [18]. Процесс поддержки приемки программных средств в настоящем стандарте может также дополнять выходы процесса валидации из [18]. Пользователи могут рассматривать требуемое соответствие по отношению к процессу в [18] в большей степени, чем к процессу в настоящем стандарте.
6.4.8.1 Цель
Цель процесса поддержки приемки программных средств заключается в содействии приобретающей стороне в обеспечении уверенности в том, что продукт соответствует заданным требованиям.
6.4.8.2 Выходы
В результате успешного осуществления процесса поддержки приемки программных средств:
a) продукт комплектуется и поставляется приобретающей стороне;
b) поддерживаются приемочные тесты и ревизии, проводимые приобретающей стороной;
c) продукт применяется по назначению в среде заказчика;
d) проблемы, обнаруженные в течение приемки, идентифицируются и передаются ответственным за их решение.
Примечание - Поэтапную поставку следует выполнять законченными частями.
6.4.8.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса поддержки приемки программных средств.
6.4.8.3.1 Поддержка приемки программных средств
Данный вид деятельности состоит из решения следующих задач:
6.4.8.3.1.1 Разработчик должен поддерживать ревизии и тестирование программного продукта, проводимые приобретающей стороной в процессе приемки. Ревизии и тестирование должны учитывать результаты процессов ревизии программных средств (см. 7.2.6), аудита программных средств (см. 7.2.7), квалификационного тестирования программных средств и квалификационного тестирования системы (если оно проводилось). Результаты ревизий и тестирования должны быть документированы.
Примечание - Эта задача включает в себя документирование и передачу проблем, обнаруженных в течение приемочного тестирования, ответственным за их решение.
6.4.8.3.1.2 Разработчик должен комплектовать и поставлять программный продукт, как определено в контракте.
Примечание - В контракте может быть указано требование, в соответствии с которым разработчик вводит продукт для применения по назначению в среду заказчика.
6.4.8.3.1.3 Разработчик должен обеспечить начальное и продолженное обучение, а также поддержку приобретающей стороны, как определено в контракте.
Примечание - Начальная поддержка включает в себя идентификацию и передачу обнаруженных в течение приемки проблем ответственным за их решение.
6.4.9 Процесс функционирования программных средств
Примечание - Процесс функционирования программных средств, представленный в настоящем стандарте, является частным случаем процесса функционирования из [18]. Пользователи могут рассматривать требование соответствия процессу из [18], а не соответствия процессу, представленному в настоящем стандарте.
6.4.9.1 Цель
Цель процесса функционирования программных средств заключается в применении программного продукта в предназначенной для него среде и обеспечении поддержки заказчиков программного продукта.
6.4.9.2 Выходы
В результате успешного осуществления процесса функционирования программных средств:
a) определяется стратегия функционирования;
b) определяются и оцениваются условия корректного функционирования программных средств в предназначенной для них среде;
c) программные средства тестируются и настраиваются в предназначенной для них среде;
d) программные средства функционируют в предназначенной для них среде;
e) обеспечиваются содействие и консультации заказчикам программных продуктов в соответствии с условиями соглашения.
6.4.9.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности и решать задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса функционирования программных средств.
6.4.9.3.1 Подготовка к функционированию
Данный вид деятельности состоит из решения следующих задач:
6.4.9.3.1.1 Оператор должен разрабатывать план и определять эксплуатационные стандарты для выполнения действий и задач этого процесса. План должен быть документирован и реализован.
6.4.9.3.1.2 Оператор должен определять процедуры для получения, регистрации, решения, прослеживания проблем и обеспечения обратной связи. Всякий раз, когда возникают проблемы, они должны быть зарегистрированы и введены в процесс решения проблем программных средств (см. 7.2.8).
6.4.9.3.1.3 Оператор должен устанавливать процедуры тестирования программного продукта в среде его эксплуатации для включения отчетов по проблемам, заявок на модификацию процесса сопровождения программных средств (см. 6.4.10) и реализации выпуска программного продукта для его функционального применения.
6.4.9.3.2 Активизация и контроль функционирования
Данный вид деятельности состоит из решения следующих задач:
6.4.9.3.2.1 Для каждого выпуска программного продукта оператор должен выполнить тестирование на соответствие функциональным требованиям и при условии удовлетворения заданных критериев выпустить программный продукт для применения по назначению.
6.4.9.3.2.2 Оператор должен гарантировать, что программный код и база данных инициируются, реализуются и заканчивают свое действие, как указано в плане.
6.4.9.3.2.3 Оператор должен активизировать систему в предназначенной для нее функциональной среде, чтобы представить образцы услуг или показать непрерывность предоставления услуг согласно их целевому назначению.
Примечание - В согласованных случаях необходимо поддерживать возможность обеспечения непрерывности и качества предоставления услуг, когда система заменяет существующую систему, изымаемую из эксплуатации. В течение заданного периода замены или параллельной работы необходимо управлять передачей услуг так, чтобы сохранялось соответствие постоянным потребностям правообладателей.
6.4.9.3.3 Применение по назначению
Данный вид деятельности состоит из решения следующих задач:
6.4.9.3.3.1 Система должна функционировать в предназначенной для нее среде согласно пользовательской документации.
Примечание 1 - Функционирование в предназначенной для системы среде включает в себя разработку критериев использования ее по назначению так, чтобы соответствие с согласованными требованиями можно было продемонстрировать и при выполнении функционального тестирования каждого выпуска программного продукта оценивалось удовлетворение по отношению к заданным критериям.
Примечание 2 - Риски, возникающие при функционировании продукта, идентифицируют и непрерывно контролируют.
Примечание 3 - Оператор регулярно контролирует функциональные услуги, сопоставляя их, где необходимо, с определенными критериями.
Данный вид деятельности состоит из решения следующих задач:
6.4.9.3.4.1 Оператор должен обеспечивать содействие и консультации пользователей по их просьбе. Эти заявки и последующие действия должны быть зарегистрированы и проконтролированы.
Примечание - Содействие и консультации включают в себя обеспечение обучения, документирование и другие услуги поддержки, обеспечивающие эффективное использование продукта.
6.4.9.3.4.2 Оператор должен направлять заявки пользователей (по мере необходимости) для выполнения в процессе сопровождения программных средств (см. 6.4.10). Эти заявки должны направляться по назначению, а сведения о действиях, которые планируются и предпринимаются, должны сообщаться инициаторам заявок. Все решения должны контролироваться для заключения об их результативности.
6.4.9.3.5 Решение проблем функционирования
Данный вид деятельности состоит из решения следующих задач:
6.4.9.3.5.1 Оператор должен направлять возникшие проблемы в процесс решения проблем в программных средствах для их устранения.
6.4.9.3.5.2 Если проблема, приведенная в отчете, относится к временному рабочему окружению перед тем, как будет реализовано постоянное решение, то инициатор отчета о проблеме должен представить вариант его применения в этом окружении. Текущие исправления используемого программного продукта, выпуски, включающие в себя ранее пропущенные функции или свойства, а также улучшения системы должны проводиться через процесс сопровождения программных средств (см. 6.4.10).
6.4.10 Процесс сопровождения программных средств
Примечание 1 - Процесс сопровождения программных средств, представленный в настоящем стандарте, является частным случаем процесса технического обслуживания, приведенного в [18]. Пользователи могут рассматривать требование соответствия для процесса из [18], а не для процесса из настоящего стандарта.
Примечание 2 - Процесс сопровождения программных средств, представленный в настоящем стандарте, совместим с [15].
6.4.10.1 Цель
Цель процесса сопровождения программных средств заключается в обеспечении эффективной по затратам поддержки поставляемого программного продукта.
Примечание - Виды деятельности по сопровождению программных средств перед поставкой включают планирование операций после поставки, обеспечения поддержки и логистики. Виды деятельности после поставки включают в себя модификацию программных средств и поддержку функционирования, такую как обучение или работа в режиме диспетчерской связи.
6.4.10.2 Выходы
В результате успешного осуществления процесса сопровождения программных средств:
a) разрабатывается стратегия сопровождения для управления модификацией и перемещением программных продуктов согласно стратегии выпусков;
b) выявляются воздействия изменений в существующей системе на организацию, операции или интерфейсы;
c) по мере необходимости обновляется связанная с изменениями системная и программная документация;
d) разрабатываются модифицированные продукты с соответствующими тестами, демонстрирующими, что требования не ставятся под угрозу;
e) обновленные продукты помещаются в среду заказчика;
f) сведения о модификации системных программных средств доводятся до всех затронутых обновлениями сторон.
6.4.10.3 Виды деятельности и задачи
Сопровождающая сторона должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса сопровождения программных средств.
6.4.10.3.1 Реализация процесса
Данный вид деятельности состоит из решения следующих задач:
6.4.10.3.1.1 Сопровождающая сторона должна разрабатывать, документировать и выполнять планы и процедуры проведения действий и решения задач в рамках процесса сопровождения программных средств.
6.4.10.3.1.2 Сопровождающая сторона должна определять процедуры получения, регистрации и прослеживания отчетов о проблемах, заявок на модификацию от пользователей и обеспечения обратной связи с пользователями. Каждый случай возникновения проблем должен регистрироваться и вводиться в процесс решения проблем в программных средствах (см. 7.2.8).
6.4.10.3.1.3 Сопровождающая сторона должна выполнять или устанавливать организационную связь с процессом менеджмента конфигурации (см. 7.2.2) для управления модификациями в существующей системе.
6.4.10.3.2 Анализ проблем и модификаций
Данный вид деятельности состоит из решения следующих задач:
6.4.10.3.2.1 Сопровождающая сторона должна анализировать отчеты о проблемах или заявки на модификацию для определения воздействий на организацию, существующую систему и связанные с ней системы, включая:
a) тип воздействия (например, корректирующее, улучшающее, превентивное или адаптирующее к новой окружающей среде);
b) границы применения (например, масштабы модификации, привлекаемые финансовые средства, время на модификацию);
с) критичность (например, воздействие на эксплуатационные параметры, безопасность или защищенность).
6.4.10.3.2.2 Сопровождающая сторона должна скопировать или верифицировать проблему.
6.4.10.3.2.3 Основываясь на анализе, сопровождающая сторона должна разработать варианты осуществления модификации.
6.4.10.3.2.4 Сопровождающая сторона должна документально оформить заявку на решение проблемы или на модификацию, результаты анализа и варианты их выполнения.
6.4.10.3.2.5 Сопровождающая сторона должна получить одобрение выбранного варианта модификации, как определено в контракте.
6.4.10.3.3 Реализация модификации
Данный вид деятельности состоит из решения следующих задач:
6.4.10.3.3.1 Сопровождающая сторона должна провести анализ и определить, какая документация, программные модули и какая из версий нуждаются в модификации. Эти действия должны быть документированы.
6.4.10.3.3.2 Для осуществления модификации сопровождающая сторона должна принять участие в технических процессах (см. 6.4). Требования технических процессов должны быть дополнены следующими действиями:
a) должны быть определены и документированы тесты и критерии оценки для тестирования, а также оценки модифицированных и немодифицированных частей системы (программных модулей, компонентов и элементов конфигурации);
b) должна быть гарантирована полная и корректная реализация новых и модифицированных требований. Необходимо гарантировать также, что исходные немодифицированные требования не были затронуты. Результаты тестирования должны быть документированы.
6.4.10.3.4 Ревизия (приемка) сопровождения
Данный вид деятельности состоит из решения следующих задач:
6.4.10.3.4.1 Сопровождающая сторона должна проводить ревизии совместно с организацией, уполномоченной проводить модификацию, для определения целостности модифицированной системы.
6.4.10.3.4.2 Сопровождающая сторона должна получить одобрение удовлетворительного завершения модификации, как определено в контракте.
6.4.10.3.5 Перемещение
Данный вид деятельности состоит из решения следующих задач:
6.4.10.3.5.1 Если системный или программный продукт (включая данные) переносится из прежней операционной среды в новую операционную среду, то должно гарантироваться, что любой программный продукт или данные, созданные или модифицированные в течение этого перемещения, соответствуют настоящему стандарту.
6.4.10.3.5.2 Должен быть разработан, документирован и выполнен план перемещения. Запланированные действия должны включать в себя участие пользователей. План должен содержать:
a) анализ требований и определение перемещения;
b) разработку инструментария перемещения;
c) конверсию программного продукта и данных;
d) выполнение перемещения;
e) верификацию перемещения;
f) поддержку прежней среды в будущем.
6.4.10.3.5.3 Пользователи должны оповещать всех, кого это касается, о планах и действиях по перемещениям. Оповещения должны включать в себя:
a) заявление о том, почему прежняя среда не должна больше поддерживаться;
b) описание новой среды с датой ее готовности;
c) описание других доступных вариантов поддержки (при их наличии), как только будет прекращена поддержка прежней среды.
6.4.10.3.5.4 Для плавного перехода к новой среде может проводиться параллельная работа как в прежней, так и в новой среде. В течение этого периода должно быть обеспечено необходимое обучение, как определено в контракте.
6.4.10.3.5.5 Когда перемещение, запланированное графиком работ, выполнено, необходимо отправить оповещение всем, кого это касается. Относящиеся к прежней среде документация, журналы и коды должны быть помещены в архивы.
6.4.10.3.5.6 Для оценки воздействия изменений на новую среду должна быть выполнена ревизия после некоторого периода наблюдения за работой. Результаты ревизии должны быть отправлены соответствующим уполномоченным органам для информации, руководства и действий.
6.4.10.3.5.7 Данные, используемые или связанные с прежней средой, должны быть доступны в соответствии с установленными в контракте требованиями к защите данных и аудиту, применяемому к данным.
6.4.11 Процесс прекращения применения программных средств
Примечание - Процесс прекращения применения программных средств в настоящем стандарте является частным случаем процесса изъятия и списания, приведенного в [18]. Пользователи могут рассматривать требование соответствия для процесса из [18], а не для процесса из настоящего стандарта.
6.4.11.1 Цель
Цель процесса прекращения применения программных средств состоит в обеспечении завершения существования системного программного объекта.
Этот процесс прекращает деятельность организации по поддержке функционирования и сопровождения или деактивирует, демонтирует и удаляет поврежденные программные продукты, отправляя их в финальное состояние и возвращая окружающую среду в приемлемые условия. В ходе данного процесса происходит уничтожение или сохранение программных элементов системы и связанных с ними продуктов обычным способом в соответствии с действующим законодательством, соглашениями, организационными ограничениями и требованиями правообладателей. При необходимости ведутся записи с целью контроля.
Примечание - При изъятии из сферы применения существующих программных продуктов систем или услуг должна сохраняться целостность организационных операций.
В результате успешного осуществления процесса прекращения применения программных средств:
a) определяется стратегия прекращения применения;
b) ограничения по прекращению применения служат в качестве входных данных к требованиям;
c) системные программные элементы уничтожаются или сохраняются;
d) окружающая среда оставляется в согласованном состоянии;
e) обеспечивается доступ к записям, хранящим знания о действиях по прекращению применения, и результатам анализа долговременных воздействий.
6.4.11.3 Виды деятельности и задачи
При реализации проекта необходимо осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса прекращения применения программных средств.
6.4.11.3.1 Планирование прекращения применения программных средств
Данный вид деятельности состоит из решения следующих задач:
6.4.11.3.1.1 Определяется и документируется стратегия прекращения применения программных средств. Должен быть разработан и документирован план прекращения активной поддержки организациями работ, связанных с этими программными средствами. Запланированные действия должны включать в себя участие пользователей. План прекращения применения программных средств должен содержать:
a) прекращение полной или частичной поддержки через определенный период времени;
b) архивирование программного продукта и связанной с ним документации;
c) ответственность за любые оставшиеся на будущее вопросы поддержки;
d) переход к новому программному продукту (при необходимости);
e) открытый доступ к копиям архива данных.
Примечание 1 - При этом определяют графики работ, мероприятия и ресурсы, которые:
1) прекращают предоставление программных услуг;
2) преобразуют систему или оставляют ее в социально и физически приемлемом состоянии, избегая таким образом последующих отрицательных воздействий на правообладателей, общество и окружающую среду;
3) учитывают факторы здоровья, безопасности, защищенности и сохранения тайны, приемлемые для мероприятий по прекращению применения и развернутых во времени условий прекращения использования физических материалов и информации.
Примечание 2 - Ограничения по прекращению применения должны служить в качестве входных данных к требованиям для запланированных действий по прекращению применения.
6.4.11.3.2 Выполнение прекращения применения программных средств
Данный вид деятельности состоит из решения следующих задач:
6.4.11.3.2.1 Должен исполняться план прекращения применения программных средств.
6.4.11.3.2.2 Пользователи должны представить оповещения о планах и действиях по снятию с эксплуатации программных продуктов и услуг. Оповещения должны включать в себя:
a) описания любых замен или обновлений с датами их готовности;
b) пояснение, почему программный продукт не будет больше поддерживаться;
c) описание других доступных вариантов поддержки после того, как поддержка будет прекращена.
6.4.11.3.2.3 Для плавного перехода к новой системе должны проводиться параллельные работы при удалении прежнего и появлении любого нового программного продукта. В течение этого периода должно обеспечиваться обучение пользователей, как определено в контракте.
6.4.11.3.2.4 Когда наступает предусмотренное графиком работ прекращение применения, всем, кого это касается, должно быть отправлено соответствующее оповещение. Вся связанная документация по разработке, журналы и коды должны быть размещены в архивах.
6.4.11.3.2.5 Используемые данные или данные, связанные с прекращением применения программных продуктов, должны быть доступны в соответствии с требованиями контракта по защите данных и проведению аудитов применительно к данным.