"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ. ГОСТ Р ИСО/МЭК 12207-2010" (утв. Приказом Ростехрегулирования от 30.11.2010 N 631-ст)
6 Процессы жизненного цикла систем
6.1 Процессы соглашения
6.1.1.1 Цель
Цель процесса приобретения состоит в получении продукта и (или) услуги в соответствии с потребностями приобретающей стороны. Процесс начинается с выяснения потребностей заказчика и заканчивается приемкой продукта и (или) услуги, необходимых приобретающей стороне.
6.1.1.2 Выходы
В результате успешного осуществления процесса приобретения:
a) определяются потребности в приобретении, конечные цели, критерии приемки продукта и (или) услуги и стратегии приобретения;
b) разрабатывается соглашение, которое ясно выражает ожидания, ответственность и обязательства как приобретающей стороны, так и поставщика;
c) выбирается один или несколько поставщиков;
d) приобретается продукт и (или) услуга, которые удовлетворяют заданным потребностям приобретающей стороны;
e) приобретение контролируется таким образом, чтобы удовлетворялись заданные ограничения, такие как, например, ограничения по стоимости, срокам и качеству;
f) принимаются продукты и (или) услуги от поставщиков;
g) по всем идентифицированным открытым позициям получены удовлетворительные заключения, согласованные приобретающей стороной и поставщиком.
6.1.1.3 Виды деятельности и задачи
Приобретающая сторона должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса приобретения.
Примечание - Виды деятельности и задачи в настоящем процессе могут выполняться одним или несколькими поставщиками.
6.1.1.3.1 Подготовка к приобретению
Данный вид деятельности состоит из решения следующих задач:
6.1.1.3.1.1 Приобретающая сторона начинает процесс приобретения, описывая свое представление или потребность в приобретении, разработке или расширении системы, программного продукта или программной услуги.
6.1.1.3.1.2 Приобретающая сторона должна определять и анализировать системные требования. Необходимо, чтобы системные требования охватывали деловые, организационные и пользовательские требования, а также требования к безопасности, защищенности и другим критическим свойствам, наряду со связанными с ними проектированием, тестированием, стандартами и процедурами оценки соответствия.
6.1.1.3.1.3 Приобретающая сторона может выполнять определение и анализ требований к программным средствам самостоятельно или поручить поставщику осуществить эту задачу.
6.1.1.3.1.4 Если приобретающая сторона поручает какому-либо поставщику выполнить анализ системных требований или требований к программным средствам, то она должна оставить за собой право утвердить проанализированные требования.
6.1.1.3.1.5 Технические процессы (см. 6.4) следует использовать для выполнения задач в соответствии с 6.1.1.3.1.2 и 6.1.1.3.1.4. Приобретающая сторона может использовать процесс определения требований правообладателей для установления требований заказчиков.
6.1.1.3.1.6 Приобретающая сторона должна рассмотреть варианты приобретения на основе анализа соответствующих критериев, учитывающих риски, стоимость и полезность каждого варианта. Варианты приобретения включают в себя:
a) покупку готового программного продукта, удовлетворяющего требованиям;
b) разработку программного продукта или получение программной услуги внутри приобретающей организации;
c) разработку программного продукта или получение программной услуги по контракту;
d) комбинации из содержания пунктов а), b) и с);
е) расширение свойств существующего программного продукта или услуги.
6.1.1.3.1.7 Если приобретается готовый программный продукт, то приобретающая сторона должна гарантировать, что выполнены следующие условия:
a) удовлетворяются требования к программному продукту;
b) имеется в наличии необходимая документация;
c) соблюдаются права собственности, применения, владения, гарантий и лицензирования;
d) предусматривается последующая поддержка программного продукта.
6.1.1.3.1.8 Приобретающей стороне следует подготовить, документировать и выполнить план приобретения. План должен содержать:
а) требования к системе;
b) запланированное применение системы;
c) тип используемого контракта;
d) ответственность организаций-участников;
e) концепцию поддержки, которая будет использована;
f) рассмотренные риски, а также методы менеджмента рисков.
6.1.1.3.1.9 Приобретающая сторона должна определить и документировать стратегию и условия (критерии) приемки.
6.1.1.3.1.10 Приобретающей стороне следует документировать требования к приобретению (например, заявки на условия приобретения), состав которых зависит от вариантов приобретения, определенных в 6.1.1.3.1.6. В документацию по приобретению следует включать:
a) системные требования;
b) формулировку области применения;
c) инструкции для претендентов;
d) перечень программных продуктов;
e) сроки и условия;
f) контроль подрядчиков;
g) технические ограничения (например, со стороны окружающей среды).
6.1.1.3.1.11 Приобретающей стороне следует определить, какие процессы настоящего стандарта предназначаются для приобретения, и сформулировать свои требования к адаптации этих процессов. Приобретающей стороне следует конкретизировать, не выполняются ли какие-либо процессы другими сторонами, отличными от поставщиков, так, чтобы поставщики в своих предложениях могли определить свой подход к поддержке работы других сторон. Приобретающая сторона должна установить область применения задач, определенных контрактом.
6.1.1.3.1.12 В документации по приобретению должны также указываться контрольные сроки, определенные в контракте, в соответствии с которыми текущая деятельность поставщика должна пересматриваться и подвергаться аудиту в качестве части процесса мониторинга приобретения (см. 7.2.6 и 7.2.7).
6.1.1.3.1.13 Требования к приобретению следует доводить до сведения организации, выбранной для выполнения деятельности по приобретению.
6.1.1.3.2 Объявление о приобретении
Данный вид деятельности состоит из решения следующей задачи:
6.1.1.3.2.1 Приобретающая сторона должна отправить заявку на поставку продукта или услуги идентифицированным поставщикам.
Примечание - Этот вид деятельности может включать в себя установление партнерских отношений между руководителями в цепочке поставок, которые обмениваются информацией с соответствующими поставщиками и приобретающими сторонами для достижения гармонизированного или коллективного подхода к общим техническим и коммерческим проблемам.
Данный вид деятельности состоит из решения следующих задач:
6.1.1.3.3.1 Приобретающей стороне следует устанавливать процедуру выбора поставщика, включающую в себя предложенные критерии оценки и значимые требования по соответствию.
6.1.1.3.3.2 Приобретающей стороне следует выбрать поставщика, основываясь на оценке предложений от поставщиков и их возможностей в соответствии со стратегией и условиями приемки приобретающей стороны.
6.1.1.3.4 Контрактные соглашения
Данный вид деятельности состоит из решения следующих задач:
6.1.1.3.4.1 До заключения контракта приобретающая сторона может привлекать другие стороны, включая потенциальных поставщиков или какие-либо необходимые третьи стороны (такие как, например, регулирующие органы), к определению требований приобретающей стороны с целью адаптации настоящего стандарта к условиям проекта. При определении этих требований приобретающая сторона должна учитывать воздействие процессов, организационно принятых у поставщика, на требования к адаптации. Приобретающая сторона должна включить в контракт требования к адаптации или сослаться на них в тексте контракта.
6.1.1.3.4.2 Приобретающая сторона затем должна подготовить и согласовать контракт с поставщиком, который соответствует требованиям к приобретению, включая стоимость и график работ для поставляемого программного продукта или услуги. В контракте должны быть оговорены права собственности, использования, владения, гарантии и лицензирования, связанные с повторно применяемыми готовыми программными продуктами.
6.1.1.3.4.3 В ходе реализации контракта приобретающая сторона должна контролировать изменения в контракте через переговоры с поставщиком в качестве части механизма управления изменениями. Изменения в контракте должны быть изучены для внесения изменений в планы проекта, стоимость, полезность, качество и график работ.
Примечание 1 - Приобретающая сторона определяет, используется ли при применении настоящего стандарта термин "контракт" или "соглашение".
Примечание 2 - В соглашении между приобретающей стороной и поставщиком следует явно выразить ожидания, ответственность и обязательства обеих сторон.
Примечание 3 - В механизме управления изменениями контракта следует отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и повторных переговоров по контракту, а также связи с заинтересованными правообладателями. Содержит пример процесса менеджмента изменений в контракте, который может использоваться для поддержки этого процесса, приведен в справочном приложении F.
6.1.1.3.5 Мониторинг соглашения
Данный вид деятельности состоит из решения следующих задач:
6.1.1.3.5.1 Приобретающая сторона должна осуществлять мониторинг деятельности поставщика в соответствии с процессом ревизии программных средств (см. 7.2.6) и процессом аудита программных средств (см. 7.2.7). При необходимости приобретающей стороне следует дополнять мониторинг процессом верификации программных средств (см. 7.2.4) и процессом валидации программных средств (см. 7.2.5).
6.1.1.3.5.2 Приобретающая сторона должна взаимодействовать с поставщиком для своевременного обеспечения всей необходимой информацией и решения всех отложенных проблем.
6.1.1.3.6 Приемка приобретающей стороной
Данный вид деятельности состоит из решения следующих задач:
6.1.1.3.6.1 Приобретающей стороне следует приготовиться к приемке, основываясь на стратегии и критериях, установленных для приемки. В подготовку следует включать тестовые примеры и данные, процедуры тестирования и условия проведения тестирований. Следует определить степень участия поставщика в процессе приемки.
6.1.1.3.6.2 Приобретающая сторона должна провести приемочный осмотр и приемочное тестирование поставляемого программного продукта или услуги и должна принять их от поставщика, если все условия приемки удовлетворены. Процедуру приемки следует согласовать с 6.1.1.3.1.9.
6.1.1.3.6.3 После приемки приобретающей стороне следует принять на себя ответственность за менеджмент конфигурации поставленного программного продукта (см. 7.2.2).
Примечание - Приобретающая сторона может инсталлировать программный продукт или выполнить программную услугу в соответствии с инструкциями, определенными поставщиком.
6.1.1.3.7 Закрытие
Данный вид деятельности состоит из решения следующей задачи:
6.1.1.3.7.1 Приобретающая сторона должна произвести оплату или выполнить другие согласованные расчеты за предоставленные поставщиком продукты или услуги.
Примечание 1 - Если поставленный продукт или услуга соответствуют условиям соглашения, а идентифицированные открытые позиции были удовлетворительно закрыты, приобретающая сторона завершает действие соглашения путем оплаты или других согласованных расчетов и уведомления о завершении действия соглашения.
Примечание 2 - Продукт или услуга могут быть поставлены и оплачены по частям.
6.1.2 Процесс поставки
6.1.2.1 Цель
Цель процесса поставки заключается в обеспечении приобретающей стороны продукцией или услугой, удовлетворяющей согласованным требованиям.
6.1.2.2 Выходы
В результате успешного осуществления процесса поставки:
a) определяется приобретающая сторона для продукта или услуги;
b) дается ответ на заявку приобретающей стороны;
c) заключается соглашение между приобретающей стороной и поставщиком на разработку, сопровождение, применение, упаковку, распределение и инсталляцию продукта и (или) услуги;
d) разрабатывается продукт и (или) услуга, удовлетворяющие согласованным требованиям;
e) продукт и (или) услуга поставляются приобретающей стороне в соответствии с согласованными условиями поставок и
f) продукт инсталлируется в соответствии с согласованными требованиями.
6.1.2.3 Виды деятельности и задачи
Поставщик должен осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса поставки.
6.1.2.3.1 Идентификация возможностей
Данный вид деятельности состоит из решения следующей задачи:
6.1.2.3.1.1 Поставщику следует определять существование и идентифицировать приобретающую сторону, которая представляет организацию или организации, имеющие потребность в продукте или услуге.
Примечание - Для продукта или услуги, разработанной для потребителей, приобретающая сторона может исполнять роль посредника, например, реализуя функцию маркетинга в пределах организации поставщика.
6.1.2.3.2 Представление заявки поставщиком
Данный вид деятельности состоит из решения следующих задач:
6.1.2.3.2.1 Поставщику следует провести рассмотрение требований, изложенных в заявке, принимая во внимание политики, принятые в организации, и другие положения.
6.1.2.3.2.2 Поставщику следует решить: предложить или принять контракт.
6.1.2.3.2.3 Поставщик должен подготовить предложение в ответ на заявку.
6.1.2.3.3 Согласование контракта
Данный вид деятельности состоит из решения следующих задач:
6.1.2.3.3.1 Поставщик должен провести переговоры и заключить контракт с приобретающей стороной на предоставление программного продукта или услуги.
6.1.2.3.3.2 Поставщик может предложить внести изменения в текст контракта в качестве части механизма управления изменениями.
6.1.2.3.4 Выполнение контракта
Данный вид деятельности состоит из решения следующих задач:
6.1.2.3.4.1 Поставщик должен проводить рассмотрение требований по приобретению для определения структуры работ по руководству и обеспечению проекта, а также для обеспечения качества поставляемого программного продукта или услуги.
6.1.2.3.4.2 Поставщик должен определить или выбрать модель жизненного цикла (если иное не оговорено в контракте) в соответствии с областью применения, масштабом и сложностью проекта. Модель жизненного цикла должна содержать стадии, цели и результаты каждой стадии. В модели жизненного цикла должны быть выбраны и отображены процессы, виды деятельности и задачи настоящего стандарта.
Примечание - В идеальном случае эта задача решается посредством применения организационно определенной модели жизненного цикла.
6.1.2.3.4.3 Поставщик должен установить требования для планов осуществления менеджмента и обеспечения проекта, а также обеспечения качества поставляемого программного продукта или услуги. В требования для таких планов следует включать необходимые ресурсы и участие приобретающей стороны.
6.1.2.3.4.4 После установления запланированных требований поставщик должен рассмотреть варианты разработки программного продукта или предоставления программной услуги в соответствии с анализом рисков, связанных с каждым вариантом. Варианты включают в себя:
a) разработку программного продукта или предоставление программной услуги с использованием внутренних ресурсов;
b) разработку программного продукта или предоставление программной услуги путем заключения контрактов с подрядчиками;
c) приобретение готовых программных продуктов от внутренних или внешних поставщиков;
d) комбинации из перечисленных выше пунктов а), b) и с).
6.1.2.3.4.5 Поставщик должен разработать и документировать план (планы) менеджмента проекта, основанный на требованиях к планированию и вариантах, выбранных в соответствии с 6.1.2.3.4.4.
В план (планы) включают следующие основные позиции:
a) организационная структура проекта, полномочия и ответственность каждого подразделения организации, включая внешние организации;
b) инженерная среда (для разработки, применения или сопровождения), включая условия тестирования, библиотеки, оборудование, удобство обслуживания, стандарты, процедуры и инструментарий;
c) структура распределения работ в рамках процессов и видов деятельности жизненного цикла, включая программные продукты, программные услуги и непоставляемые элементы, с учетом бюджета, состава исполнителей, материальных ресурсов, размеров программных средств и календарных планов, связанных с этими задачами;
d) менеджмент характеристик качества программных продуктов или услуг. Допускается разработка отдельных планов по обеспечению качества;
e) менеджмент безопасности, защиты и других критических требований к программным продуктам или услугам. Допускается разработка отдельных планов по безопасности и защите;
f) менеджмент подрядчиков, включая выбор подрядчиков и взаимоотношения между подрядчиком и приобретающей стороной;
g) обеспечение гарантии качества (см. 7.2.3);
h) верификацию (см. 7.2.4) и валидацию (см. 7.2.5), включая подход к взаимоотношениям с организацией, проводящей верификацию и валидацию, при наличии соответствующих требований;
i) участие приобретающей стороны, в первую очередь через участие в проведении ревизий (см. 7.2.6), аудитов (см. 7.2.7), неформальных встреч, составление отчетов, модификацию и изменения, реализацию, официальные соглашения, приемку и доступ к средствам;
j) участие пользователей, которое реализуется через требования к настройке упражнений, демонстрации и оценке прототипов;
k) менеджмент рисков, то есть менеджмент областей проекта, которые связаны с потенциальными техническими, финансовыми и плановыми рисками;
l) политика по защите, то есть правила ознакомления и доступа к информации на каждом уровне проекта организации;
m) официальное принятие, требуемое регулирующими положениями, положениями о сертификации, правах собственности, монопольном применении, гарантиях, лицензиях и т.п.;
n) средства для формирования графиков работ, проведения надзора и составления отчетов;
о) обучение персонала (см. 6.2.4).
6.1.2.3.4.6 Поставщик должен формировать и исполнять план (планы) менеджмента проекта (проектов), разработанный (разработанные) в соответствии с 6.1.2.3.4.5.
6.1.2.3.4.7 Поставщик должен:
a) разработать программный продукт в соответствии с техническими процессами (см. 6.4);
b) использовать программный продукт в соответствии с процессом функционирования программных средств (см. 6.4.9);
c) сопровождать программный продукт в соответствии с процессом сопровождения программных средств (см. 6.4.10).
6.1.2.3.4.8 Поставщик должен осуществлять мониторинг и управление развитием и качеством программных продуктов или услуг проекта на всем протяжении жизненного цикла, указанного в контракте, что должно быть постоянной, многократно повторяющейся задачей, которая обеспечивает:
a) мониторинг изменений в технических характеристиках, расходах, графиках работ и отчетности о состоянии проекта;
b) выявление возникающих проблем, их регистрацию, анализ и решение.
6.1.2.3.4.9 Поставщик должен руководить и управлять деятельностью подрядчиков в соответствии с процессом приобретения (см. 6.1.1). Поставщик должен выполнить все установленные контрактом требования, гарантирующие, что поставляемый приобретающей стороне программный продукт или услуга разрабатывается или изготавливается в соответствии с первостепенными требованиями контракта.
6.1.2.3.4.10 Поставщик должен взаимодействовать с независимой организацией, проводящей верификацию, валидацию или тестирование, как определено в контракте и планах проекта.
6.1.2.3.4.11 Поставщик должен взаимодействовать с другими сторонами, как определено в контракте и планах проекта.
6.1.2.3.4.12 Поставщику следует координировать проведение предусмотренной контрактом ревизии действий, взаимоотношений и коммуникаций с организацией приобретающей стороны.
6.1.2.3.4.13 Поставщик должен проводить неформальные встречи или участвовать в них, анализе условий приемки, приемочном тестировании, совместных ревизиях и аудитах вместе с приобретающей стороной, как определено в контракте и планах проекта. Совместные ревизии должны проводиться в соответствии с 7.2.6, аудиторские проверки - 7.2.7.
6.1.2.3.4.14 Поставщику следует выполнять верификацию и валидацию согласно 7.2.4 и 7.2.5 соответственно для демонстрации того, что программные продукты или услуги и процессы полностью удовлетворяют установленным требованиям.
6.1.2.3.4.15 Поставщик должен сделать доступными для приобретающей стороны отчеты об оценках, ревизиях, аудиторских проверках, тестированиях и решениях возникших проблем, как определено в контракте.
6.1.2.3.4.16 Поставщик должен обеспечивать приобретающей стороне доступ к своим средствам и средствам подрядчиков для проведения ревизий программных продуктов или услуг, как определено в контракте и планах проекта.
6.1.2.3.4.17 Поставщик должен осуществлять деятельность по обеспечению гарантии качества в соответствии с 7.2.3.
6.1.2.3.5 Поставка и поддержка продукта (услуги)
Данный вид деятельности состоит из решения следующих задач:
6.1.2.3.5.1 Поставщик должен поставлять программный продукт или услугу, как определено в контракте.
Примечание - Поставщику следует инсталлировать продукт в соответствии с установленными требованиями, если это требуется по соглашению.
6.1.2.3.5.2 Поставщик должен обеспечивать содействие приобретающей стороне в поддержке поставленного программного продукта или услуги, как определено в контракте.
Данный вид деятельности состоит из решения следующих задач:
6.1.2.3.6.1 Поставщик должен принять и подтвердить оплату или другие согласованные способы расчета.
6.1.2.3.6.2 Поставщик должен передать ответственность за продукт или услугу приобретающей стороне или другой стороне в порядке, предусмотренном соглашением.
Примечание - В соглашении следует указывать сроки и полномочия для инициации закрытия проекта.
6.2 Процессы организационного обеспечения проекта6.2.1 Процесс менеджмента модели жизненного цикла
Цель процесса менеджмента модели жизненного цикла заключается в определении, сопровождении и обеспечении гарантии наличия политик, процессов жизненного цикла, моделей жизненного цикла и процедур для использования организацией в пределах области применения настоящего стандарта.
Данный процесс предусматривает политики, процессы и процедуры жизненного цикла, согласованные с целями организации, которые определяются, адаптируются, совершенствуются и сопровождаются для поддержки отдельных потребностей проекта в пределах задач и функций организации и которые готовы к применению с использованием эффективных испытанных методов и инструментария.
6.2.1.2 Выходы
В результате успешного осуществления процесса менеджмента модели жизненного цикла:
a) предоставляются политики и процедуры менеджмента и развертывания моделей и процессов жизненного цикла;
b) определяются обязанности, ответственность и полномочия менеджмента жизненного цикла;
c) определяются, сопровождаются и совершенствуются процессы, модели и процедуры жизненного цикла для применения организацией;
d) осуществляется процесс усовершенствований в порядке установленных приоритетов.
6.2.1.3 Виды деятельности и задачи
Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента модели жизненного цикла.
6.2.1.3.1 Учреждение процессов
Данный вид деятельности состоит из решения следующей задачи:
6.2.1.3.1.1 Организация должна учредить совокупность организационных процессов для всех процессов и моделей жизненного цикла программных средств, используемых в деловой деятельности. Эти процессы и их применение в конкретных случаях должны документироваться в публикациях организации. При необходимости следует установить механизм управления процессами при разработке, мониторинге, управлении и совершенствовании процессов.
Примечание - Установление механизма управления процессами включает в себя определение обязанностей, ответственности и полномочий для менеджмента жизненного цикла.
6.2.1.3.2 Оценка процессов
Данный вид деятельности состоит из решения следующих задач:
6.2.1.3.2.1 Организации следует разработать, документировать и применять процедуру оценки процессов. Записи об оценках необходимо осуществлять и поддерживать.
6.2.1.3.2.2 Организация должна планировать и осуществлять ревизии процессов через определенные интервалы времени для гарантии того, что процессы остаются пригодными и результативными в свете результатов проведения оценок.
6.2.1.3.3 Совершенствование процессов
Данный вид деятельности состоит из решения следующих задач:
6.2.1.3.3.1 Организация должна проводить такие улучшения своих процессов, какие она посчитает необходимыми по результатам оценки и ревизии процессов. Процесс документирования следует также обновлять для отражения улучшений в организационных процессах.
6.2.1.3.3.2 Исторические, технические данные, а также данные оценивания следует накапливать и анализировать для усиления понимания сильных и слабых сторон применяемых процессов. Этот анализ следует использовать в качестве обратной связи для совершенствования процессов, выработки рекомендаций по изменениям в текущих или последующих проектах и определения потребностей в передовых технологиях.
6.2.1.3.3.3 Данные о затратах на качество следует накапливать, сопровождать и использовать для совершенствования процессов организации, обусловленных действиями ее руководства. Эти данные должны служить цели установления затрат как на предупреждение, так и на разрешение проблем и несоответствий в программных продуктах и услугах.
6.2.2 Процесс менеджмента инфраструктуры
6.2.2.1 Цель
Цель процесса менеджмента инфраструктуры заключается в снабжении проекта обеспечивающей инфраструктурой и услугами для поддержки организации и целей проекта в течение всего жизненного цикла.
Данный процесс определяет, предоставляет и обслуживает средства, инструментарий, активы коммуникационных и информационных технологий, необходимые для деловой деятельности организации в соответствии с областью применения настоящего стандарта.
6.2.2.2 Выходы
В результате успешного осуществления процесса менеджмента инфраструктуры:
a) определяются требования к инфраструктуре для поддержки процессов;
b) идентифицируются и специфицируются элементы инфраструктуры;
c) приобретаются элементы инфраструктуры;
d) реализуются элементы инфраструктуры;
e) обслуживается и совершенствуется стабильная и надежная инфраструктура.
Примечание - Элементами инфраструктуры могут быть технические средства, программные средства, методы, инструментарий, технические приемы, стандарты, а также средства для разработки, применения по назначению или сопровождения.
6.2.2.3 Виды деятельности и задачи
Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента инфраструктуры.
6.2.2.3.1 Реализация процесса
Данный вид деятельности состоит из решения следующих задач:
6.2.2.3.1.1 Инфраструктуру следует определять и документировать для выполнения требований процесса, использующего данный процесс, рассматривая подходящие процедуры, стандарты, инструментарий и технические приемы.
6.2.2.3.1.2 Официальное создание этой инфраструктуры следует планировать и документировать.
6.2.2.3.2 Создание инфраструктуры
Данный вид деятельности состоит из решения следующих задач:
6.2.2.3.2.1 Конфигурацию инфраструктуры следует планировать и документировать. При этом следует рассмотреть функциональность, эксплуатационные характеристики, безопасность, защиту, готовность, требования к размещению, оборудование, затраты и временные ограничения.
6.2.2.3.2.2 Инфраструктура должна быть развернута во времени для выполнения соответствующего процесса.
6.2.2.3.3 Сопровождение инфраструктуры
Данный вид деятельности состоит из решения следующей задачи:
6.2.2.3.3.1 Инфраструктура должна сопровождаться, контролироваться и модифицироваться по мере необходимости для гарантии того, что она продолжает удовлетворять требованиям процесса, использующего данный процесс. В качестве части обслуживания инфраструктуры должна быть определена степень воздействия на инфраструктуру менеджмента конфигурации.
6.2.3 Процесс менеджмента портфеля проектов
6.2.3.1 Цель
Цель процесса менеджмента портфеля проектов заключается в инициации и поддержке необходимых, достаточных и подходящих проектов для выполнения стратегических целей организации.
Данный процесс совершает инвестирование адекватных фондов и ресурсов организации, а также санкционирует полномочия, необходимые для осуществления выбранных проектов. Он выполняет постоянную квалификацию проектов с целью подтверждения их обоснованности или может быть переориентирован на обоснование продолжения инвестирования.
6.2.3.2 Выходы
В результате успешного осуществления процесса менеджмента портфеля проектов:
a) уточняются, расставляются по приоритетам и выбираются возможности, инвестиции или потребности деловой сферы с учетом рисков;
b) определяются и распределяются ресурсы и денежные средства для каждого проекта;
c) определяются полномочия и ответственность руководства проектом;
d) поддерживаются проекты, удовлетворяющие условиям соглашения и требованиям правообладателей;
e) переориентируются или прекращаются проекты, не удовлетворяющие условиям соглашения или требованиям правообладателей.
6.2.3.3 Виды деятельности и задачи
Организация должна выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента портфеля проектов.
6.2.3.3.1 Инициация проекта
Данный вид деятельности состоит из решения следующих задач:
6.2.3.3.1.1 Организация должна определять, располагать по приоритетам, выбирать и устанавливать новые возможности в деловой сфере, степень риска или реализуемости способом, который соответствует стратегии деловой деятельности и планам действий организации.
Примечание - Следует расставлять приоритеты для проектов и устанавливать пороговые значения для определения того, какие проекты будут выполняться.
6.2.3.3.1.2 Организация должна определять ответственность и полномочия для каждого проекта.
6.2.3.3.1.3 Организация должна определять ожидаемые результаты осуществления проектов.
6.2.3.3.1.4 Организация должна распределять ресурсы для достижения целей проекта.
6.2.3.3.1.5 Организация должна определять любые взаимосвязи между многими проектами, которые должны управляться или поддерживаться данным проектом.
Примечание - Данная задача включает в себя применение обеспечивающих систем и общих системных элементов, используемых более чем одним проектом одновременно.
6.2.3.3.1.6 Организация должна устанавливать требования к отчетности по проекту и рассматривать промежуточные контрольные сроки, в соответствии с которыми будет осуществляться руководство выполнением проекта.
6.2.3.3.1.7 Организация должна санкционировать начало выполнения утвержденных планов проекта, включая технические планы.
6.2.3.3.2 Оценка портфеля
Данный вид деятельности состоит из решения следующих задач:
6.2.3.3.2.1 Организация должна оценивать текущие проекты с целью подтверждения того, что:
a) проекты продвигаются в направлении достижения поставленных конечных целей;
b) проекты осуществляются согласно действующим директивам;
c) проекты реализуются в соответствии с планами и процедурами жизненного цикла систем;
d) проекты остаются жизнеспособными, что подтверждается, например, постоянной потребностью в услуге, практичным исполнением продукта, приемлемыми доходами от инвестиций.
6.2.3.3.2.2 Организация должна принимать меры по продолжению успешно развивающихся проектов или переориентировать проекты, если можно ожидать, что они будут развиваться успешно в этом случае.
6.2.3.3.3 Закрытие проекта
Данный вид деятельности состоит из решения следующих задач:
6.2.3.3.3.1 В случаях, оговоренных соглашением, организация должна принять меры по отмене или приостановке проектов, недостатки или риски которых для организации перевешивают пользу от продолжения инвестиций.
6.2.3.3.3.2 После выполнения всех пунктов соглашения на продукты и услуги организация должна закрыть проект в соответствии с соглашением, политиками и процедурами организации.
Примечание 1 - Организация гарантирует, что после закрытия проекта она несет ответственность за оставшуюся у нее документацию.
Примечание 2 - После закрытия проекта организация может разрешить удаление этого проекта из портфеля проектов.
6.2.4 Процесс менеджмента людских ресурсов
6.2.4.1 Цель
Целью процесса менеджмента людских ресурсов является обеспечение организации необходимыми людскими ресурсами и поддержание их компетентности согласно потребностям деловой деятельности.
Процесс гарантирует обеспечение поддержки персонала, обладающего навыками, опытом и квалификацией для выполнения процессов жизненного цикла, направленных на достижение целей организации, проекта и заказчика.
6.2.4.2 Выходы
В результате успешного осуществления процесса менеджмента людских ресурсов:
a) определяются навыки, требуемые проектами;
b) проекты обеспечиваются необходимыми людскими ресурсами;
c) развиваются, поддерживаются или улучшаются навыки персонала;
d) разрешаются конфликты, возникающие из-за потребностей в людских ресурсах многих проектов, и
e) накапливаются, совершенствуются и используются совместно и многократно индивидуальные знания, информация и навыки в пределах всей организации.
6.2.4.3 Виды деятельности и задачи
Организация должна осуществлять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента людских ресурсов:
6.2.4.3.1 Идентификация навыков
Данный вид деятельности состоит из решения следующих задач:
6.2.4.3.1.1 Для своевременного приобретения или развития ресурсов и навыков, необходимых для руководства и технического персонала, должны проводиться регулярные пересмотры требований проектов и организации. Новые потребности могут быть удовлетворены через обучение, наем или другие механизмы развития штатного персонала.
6.2.4.3.1.2 Должны быть определены типы и уровни обучения и знаний, необходимые для удовлетворения требований проектов и организации.
6.2.4.3.2 Развитие навыков
Данный вид деятельности состоит из решения следующих задач:
6.2.4.3.2.1 Должен быть разработан и документирован план обучения, ориентированный на выполнение графиков работ, требований к ресурсам и потребностей в обучении.
6.2.4.3.2.2 Следует разработать или приобрести учебные руководства, в том числе наглядные пособия, используемые для обеспечения обучения.
6.2.4.3.2.3 Должен реализовываться план обучения для обеспечения обучения персонала. Следует поддерживать записи о проведении обучения.
6.2.4.3.3 Приобретение и обеспечение навыков
Данный вид деятельности состоит из решения следующих задач:
6.2.4.3.3.1 Разработать систематически обновляемую программу найма штатного персонала, соответствующего потребностям проектов и организации. Обеспечить возможности для карьерного роста существующего штатного персонала.
6.2.4.3.3.2 Определить объективные критерии, которые могут использоваться для оценки рабочих характеристик штатного персонала.
6.2.4.3.3.3 Оценить рабочие характеристики штатного персонала по отношению к его вкладу в достижение конечных целей проекта или организации.
6.2.4.3.3.4 Гарантировать обеспечение обратной связи от результатов выполненных оценок к штатному персоналу.
6.2.4.3.3.5 Сопровождать адекватные записи о рабочих характеристиках штатного персонала, включая информацию о навыках, законченном обучении и оценках рабочих характеристик.
6.2.4.3.3.6 Определять потребности проектов и организаций в проектных группах. Определять структуру группы и правила работы.
Примечание - Следует разрешать конфликты, возникающие из-за ограниченности ресурсов, требуемых многими проектами.
6.2.4.3.3.7 Уполномочить группы для выполнения своих ролей, гарантируя, что эти группы обладают:
a) пониманием своей роли в проекте;
b) совместным видением или ощущением общих интересов в успехе проекта;
c) соответствующими механизмами или средствами для коммуникации и взаимодействия между группами;
d) поддержкой соответствующего руководства для выполнения требований проекта.
6.2.4.3.3.8 Следует гарантировать наличие необходимого сочетания прав и категорий соответственно обученного персонала для своевременного выполнения запланированных действий и задач.
6.2.4.3.4 Менеджмент знаний
Данный вид деятельности состоит из решения следующих задач:
6.2.4.3.4.1 Организация должна планировать требования для управления активами знаний организации. Планирование должно включать в себя определение инфраструктуры и обучение для поддержки вкладчиков и пользователей активов знаний организации, схемы классификации активов и критериев активов.
6.2.4.3.4.2 Организация должна учредить сеть экспертов в пределах организации. Сеть должна содержать идентификацию экспертов организации, список областей их экспертизы и идентификацию доступной информации в пределах схемы классификации, например, область знаний. Организация должна гарантировать, что сеть сопровождается и соответствует текущему моменту.
6.2.4.3.4.3 Организация должна устанавливать механизм поддержки обмена информацией между экспертами (потоком информации от экспертов) и проектами организации. Механизм должен поддерживать доступ организации, хранение и поиск требований.
6.2.4.3.4.4 Организация должна выполнять менеджмент конфигурации активов в соответствии с процессом менеджмента конфигураций, определенным в 6.4.2.
6.2.4.3.4.5 Организации должны собирать и сопровождать информацию, доступ к которой конкретная организация получает через план.
6.2.5 Процесс менеджмента качества
6.2.5.1 Цель
Целью процесса менеджмента качества является гарантия того, что продукты, услуги и реализации процессов жизненного цикла соответствуют целям организации в области качества и удовлетворяют заказчика.
6.2.5.2 Выходы
В результате успешного осуществления процесса менеджмента качества:
a) определяются политики и процедуры в области менеджмента качества организации;
b) определяются цели организации в области качества;
c) определяются обязанности и полномочия менеджмента качества;
d) осуществляется мониторинг степени удовлетворенности заказчика и
e) предпринимаются соответствующие действия, когда цели в области качества не достигаются.
6.2.5.3 Виды деятельности и задачи
Организация должна выполнять следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента качества.
6.2.5.3.1 Менеджмент качества
Данный вид деятельности состоит из решения следующих задач:
6.2.5.3.1.1 Организация должна определять политики, стандарты и процедуры в области менеджмента качества.
Примечание 1 - Модель процесса для системы менеджмента качества в [4]. Для организаций, желающих развить положения [4] в направлении непрерывного совершенствования эксплуатационных характеристик, соответствующее руководство приведено в [5].
Примечание 2 - Руководство по применению [4] для программных средств приведено в [31].
6.2.5.3.1.2 Организация должна устанавливать конечные и текущие цели менеджмента качества, основанные на стратегии, направленной на обеспечение удовлетворенности заказчика.
6.2.5.3.1.3 Организация должна определять обязанности и полномочия при реализации менеджмента качества.
6.2.5.3.1.4 Организация должна оценивать степень удовлетворенности заказчика и составлять отчеты.
Примечание - Выполнение требований настоящего стандарта предоставляет организации подход для достижения удовлетворенности заказчика.
6.2.5.3.1.5 Организация должна проводить периодические ревизии планов обеспечения качества проектов.
Примечание - Необходимо гарантировать, что цели в области качества, основанные на требованиях правообладателя, устанавливаются для каждого проекта.
6.2.5.3.1.6 Организация должна проводить мониторинг состояния совершенствования продукции и услуг в области качества.
6.2.5.3.2 Корректирующие действия менеджмента качества
Данный вид деятельности состоит из решения следующих задач:
6.2.5.3.2.1 Организация должна предпринимать корректирующие действия, если конечные цели менеджмента качества не достигнуты.
6.2.5.3.2.2 Организация должна выполнять корректирующие действия и сообщать о результатах в пределах организации.
6.3 Процессы проекта6.3.1 Процесс планирования проекта
6.3.1.1 Цель
Цель процесса планирования проекта состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана.
Данный процесс определяет область применения менеджмента проекта и технических мероприятий, результаты процесса, проектные задачи и поставки, устанавливает графики для выполнения задач проекта, включая критерии достижения и ресурсы, необходимые для выполнения задач проекта.
6.3.1.2 Выходы
В результате успешного осуществления процесса планирования проекта:
a) определяется область проведения работ по проекту;
b) оценивается возможность достижения конечных целей проекта с имеющимися ресурсами и ограничениями;
c) определяются размеры и оцениваются задачи и ресурсы, необходимые для выполнения работы;
d) идентифицируются интерфейсы между элементами в проекте и с другими проектами и подразделениями организации;
e) разрабатываются планы реализации проекта;
f) активизируются планы реализации проекта.
6.3.1.3 Виды деятельности и задачи
Менеджер должен выполнять следующие виды деятельности в соответствии с принятыми в организации политиками и процедурами в отношении процесса планирования проекта:
6.3.1.3.1 Инициация проекта
Данный вид деятельности состоит из решения следующих задач:
6.3.1.3.1.1 Менеджер должен определять требования инициируемого проекта.
Примечание - Определение этих требований включает в себя идентификацию целей, мотиваций и ограничений проекта.
6.3.1.3.1.2 После определения требований проекта менеджер должен оценить осуществимость проекта, проверяя, что ресурсы (персонал, материалы, технологии и окружающая среда), необходимые для выполнения и управления проектом, доступны, адекватны и выделены, а сроки завершения проекта достижимы.
6.3.1.3.1.3 По мере необходимости и при согласии всех заинтересованных сторон требования проекта могут быть изменены на этом этапе для достижения критериев завершения.
6.3.1.3.2 Планирование проекта
Данный вид деятельности состоит из решения следующих задач:
6.3.1.3.2.1 Менеджер должен подготовить планы выполнения проекта. Планы, связанные с выполнением проекта, должны включать в себя описания связанных действий и задач и идентификацию программных продуктов, которые будут поставляться. Эти планы должны включать в себя, по крайней мере:
a) графики работ для своевременного завершения задач;
b) оценку усилий;
c) ресурсы, необходимые для выполнения задач;
d) распределение задач;
e) распределение обязанностей;
f) количественное определение рисков, связанных с задачами или самим процессом;
g) мероприятия по гарантии качества для применения в пределах всего проекта;
h) затраты, связанные с выполнением процесса;
i) обеспечение окружающей среды и инфраструктуры;
j) определение и сопровождение модели жизненного цикла, состоящей из стадий, используя конкретные модели жизненного цикла для проектов организации.
Примечание - Организационные модели, применяемые в проекте, следует обеспечивать через процесс менеджмента модели жизненного цикла.
6.3.1.3.3 Активизация проекта
Данный вид деятельности состоит из решения следующих задач:
6.3.1.3.3.1 Менеджер должен получить полномочия на проект.
6.3.1.3.3.2 Менеджер должен представить заявки на необходимые ресурсы для выполнения проекта.
6.3.1.3.3.3 Менеджер должен инициировать выполнение планов проекта для удовлетворения совокупности целей и критериев осуществления управления проектом.
6.3.2 Оценка проекта и процесс управления
6.3.2.1 Цель
Цель оценки проекта и процесса управления заключается в определении состояния проекта и гарантии того, что проект выполняется в соответствии с планами и графиками работ в пределах бюджета и удовлетворяет техническим параметрам.
При необходимости этот процесс включает в себя переориентацию деятельности в рамках проекта, корректировку выявленных отклонений и изменений, связанных с менеджментом других проектов или с техническими процессами. Соответственно переориентация может включать в себя перепланирование.
6.3.2.2 Выходы
В результате успешного осуществления оценки проекта и процесса управления:
a) проводится мониторинг и выпускаются отчеты о развитии проекта;
b) осуществляется мониторинг интерфейсов между элементами в проекте и другими проектами и подразделениями организации;
c) предпринимаются действия по корректировке отклонений от плана и для предотвращения повторения проблем, выявленных в проекте, если проектные задания не достигнуты;
d) цели проекта достигаются и регистрируются.
6.3.2.3 Виды деятельности и задачи
Менеджер должен осуществлять следующие виды деятельности в соответствии с применяемыми в организации методиками и процедурами в отношении оценки проекта и процесса управления:
6.3.2.3.1 Мониторинг проекта
Данный вид деятельности состоит из решения следующей задачи:
6.3.2.3.1.1 Менеджер должен осуществлять мониторинг полного выполнения проекта, обеспечивая как предоставление внутренних отчетов о продвижении проекта, так и предоставление отчетов приобретающей стороне, как определено в контракте.
Примечание - Менеджер гарантирует, что внутренние интерфейсы элементов проекта так же, как и интерфейсы с другими проектами и организационными подразделениями, постоянно контролируются в течение этого вида деятельности.
Данный вид деятельности состоит из решения следующих задач:
6.3.2.3.2.1 Менеджер должен исследовать, проанализировать и принять решения по проблемам, обнаруженным при выполнении проекта. Решение проблем может привести к изменениям в планах. В обязанности менеджера входит обеспечение гарантии того, что воздействие любых изменений определяется, регулируется и контролируется. Проблемы и их решения должны документироваться.
6.3.2.3.2.2 Менеджер должен представлять отчеты в согласованные сроки о развитии проекта, показывая соблюдение планов и решения в случае остановки в развитии проекта. Отчеты могут быть внутренними и внешними в соответствии с требованиями контракта и процедурами организации.
6.3.2.3.3 Оценка проекта
Данный вид деятельности состоит из решения следующих задач:
6.3.2.3.3.1 Менеджер должен гарантировать, что программные продукты и планы оцениваются для определения выполнения установленных требований.
6.3.2.3.3.2 Менеджер должен определять результаты оценки программных продуктов, действий и задач, завершенных в процессе реализации проекта, для достижения целей и завершения выполнения планов.
Примечание - Менеджер использует результаты оценки, чтобы принять меры для предотвращения будущих повторений проблем, выявленных в проекте.
6.3.2.3.4 Завершение проекта
Данный вид деятельности состоит из решения следующих задач:
6.3.2.3.4.1 Когда все программные продукты, действия и задачи завершаются, менеджер должен определить, закончен ли проект, принимая во внимание критерии, указанные в контракте или установленные как часть процедуры организации.
6.3.2.3.4.2 Эти результаты и отчеты должны быть архивированы в соответствующей среде, как определено в контракте.
6.3.3 Процесс менеджмента решений
6.3.3.1 Цель
Цель процесса менеджмента решений заключается в выборе из существующих альтернатив наиболее предпочтительного направления проектных действий.
Данный процесс является реакцией на возникающие в течение жизненного цикла системы запросы на принятие решений, направленных на достижение заданных, желаемых или оптимальных результатов вне зависимости от происхождения или источника таких запросов. Альтернативные действия анализируются, выбирается и указывается направление действий. Решения и их обоснования документируются для поддержки принятия будущих решений.
6.3.3.2 Выходы
В результате успешного осуществления процесса менеджмента решений:
a) определяется стратегия принятия решений;
b) определяются альтернативные направления действий;
c) выбирается наиболее предпочтительное направление действий;
d) принятое решение, его обоснование и допущения документируются и доводятся до сведения заинтересованных сторон.
6.3.3.3 Виды деятельности и задачи
В проекте должны реализовываться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента решений.
6.3.3.3.1 Планирование решений
Данный вид деятельности состоит из решения следующих задач:
6.3.3.3.1.1 Проект должен определять стратегию принятия решений.
Примечание - К этой задаче относится определение категории решений, схем установления приоритетов и идентификация ответственных сторон. Также определяются лица, принимающие решения, распределяются обязанности и предоставляются полномочия по принятию решений. Потребность в принятии решений может возникать вследствие оценки результативности, принятия компромиссных технических решений, наличия проблем, требующих решений, необходимости реагировать на риски, когда их уровень выходит за допустимые пределы, появления новых возможностей или перехода проекта на следующую стадию жизненного цикла. Стратегия принятия решений включает в себя установление и распределение ответственности и полномочий при принятии решений.
6.3.3.3.1.2 Проект должен привлекать заинтересованные стороны к принятию решений для использования их опыта и знаний.
6.3.3.3.1.3 Проект должен устанавливать обстоятельства и необходимость принятия решений.
Примечание - Следует документировать, классифицировать, своевременно и объективно сообщать о проблемах или возможностях и альтернативных направлениях деятельности, которые способны разрешить существующие проблемы.
6.3.3.3.2 Анализ решений
Данный вид деятельности состоит из решения следующих задач:
6.3.3.3.2.1 При реализации проекта необходимо выбирать и объявлять стратегию принятия решения для каждой ситуации, в которой необходимо принять решение. Проект должен определять желаемые результаты и измеримые критерии успешного принятия решений.
6.3.3.3.2.2 При реализации проекта необходимо оценивать баланс последствий альтернативных действий, используя определенную стратегию принятия решений с целью оптимизации или улучшения ситуации принятия решений.
6.3.3.3.3 Прослеживание решений
Данный вид деятельности состоит из решения следующих задач:
6.3.3.3.3.1 При реализации проекта необходимо регистрировать, отслеживать, оценивать и сообщать о результатах принятия решений для подтверждения эффективности решения проблем, устранения отрицательных тенденций и получения возможных преимуществ.
6.3.3.3.3.2 При реализации проекта необходимо поддерживать записи о проблемах и возможностях их решения, а также размещать записи в соответствии с соглашениями или организационными процедурами таким образом, который позволяет проводить аудит и изучать полученный опыт.
6.3.4 Процесс менеджмента рисков
6.3.4.1 Цель
Цель процесса менеджмента рисков заключается в постоянном определении, анализе, обработке и мониторинге рисков. Процесс менеджмента рисков является непрерывным процессом для систематичной адресации риска по всему жизненному циклу системного или программного продукта или услуги. Это может быть применимо к рискам, связанным с приобретением, разработкой, сопровождением или применением по назначению системы.
6.3.4.2 Выходы
В результате успешного осуществления процесса менеджмента рисков:
a) определяется область применения выполняемого менеджмента рисков;
b) определяются и выполняются соответствующие стратегии менеджмента рисков;
c) определяются риски по мере их выявления и в течение проведения проекта;
d) риски анализируются и определяются приоритеты использования ресурсов для обработки этих рисков;
e) определяются, применяются и оцениваются степени риска для установления изменений состояния риска и прогресса в действиях по его обработке;
f) предпринимается обработка для исправления или уклонения от воздействия риска, основанная на его приоритете, вероятности и последствиях или другом определенном пороговом значении риска.
6.3.4.3 Виды деятельности и задачи
В проекте должны реализоваться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента рисков.
Примечание - В [22] процесс менеджмента рисков предусматривает более детальную совокупность действий и задач, которые согласуются с действиями и задачами, представленными ниже.
6.3.4.3.1 Планирование менеджмента рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.1.1 Должны быть определены политики менеджмента рисков, описывающие руководящие указания, регламентирующие выполнение менеджмента рисков.
6.3.4.3.1.2 Должно быть документировано описание осуществляемого процесса менеджмента рисков.
6.3.4.3.1.3 Должны быть определены стороны, ответственные за выполнение менеджмента рисков, их роли и обязанности.
6.3.4.3.1.4 Ответственные стороны должны быть обеспечены ресурсами, достаточными для выполнения процесса менеджмента рисков.
6.3.4.3.1.5 Должно быть предоставлено описание процесса оценки и совершенствования процесса менеджмента рисков.
Примечание - Эта задача включает в себя накопление полученных знаний и опыта.
6.3.4.3.2 Менеджмент профиля рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.2.1 Содержание процесса менеджмента рисков должно быть определено и документировано.
Примечание - Эта задача включает в себя описание перспектив правообладателей, категорий риска и описание (возможно посредством ссылки) технических и управленческих целей, допущений и ограничений.
6.3.4.3.2.2 Должны быть документированы пороговые значения риска, определяющие условия, при которых уровень риска может быть принят.
6.3.4.3.2.3 Должен устанавливаться и поддерживаться профиль рисков.
Примечание - Записи профиля рисков включают в себя содержание менеджмента рисков; запись каждого состояния риска, включая его вероятность, последствия и пороговые значения риска; приоритет каждого риска, основанный на критериях риска, представленных правообладателями; требования по осуществлению действий, связанных с состоянием и обработкой риска. Профиль рисков обновляется, если имеются изменения в отдельном состоянии риска. Приоритеты в профиле рисков используются для определения применения ресурсов для обработки рисков.
6.3.4.3.2.4 Содержание соответствующего профиля рисков должно периодически доводиться до сведения правообладателей в зависимости от их потребностей.
6.3.4.3.3 Анализ рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.3.1 Риски должны быть идентифицированы в категориях, описанных в контексте менеджмента рисков.
6.3.4.3.3.2 Должна быть оценена вероятность возникновения и последствия каждого идентифицированного риска.
6.3.4.3.3.3 Каждый риск должен быть оценен по отношению к его пороговым значениям.
6.3.4.3.3.4 Для каждого риска, который находится выше его порогового значения, должны быть определены и документированы рекомендуемые стратегии обработки. Измеримые значения показателей, характеризующих результативность альтернативных вариантов обработки, также должны быть определены и документированы.
Примечание - Стратегии обработки риска включают в себя, по крайней мере: устранение риска, уменьшение вероятности его появления или серьезности последствий или принятие риска.
6.3.4.3.4 Обработка рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.4.1 Правообладатели должны предоставлять рекомендованные альтернативы обработки риска в требованиях на действия по отношению к риску.
6.3.4.3.4.2 Если правообладатели посчитают, что следует предпринять действия для того, чтобы сделать риск приемлемым, то должна быть реализована альтернатива обработки риска.
6.3.4.3.4.3 Если правообладатели принимают риск, который превышает пороговое значение, то этот риск должен рассматриваться как высоко приоритетный и непрерывно контролироваться для определения необходимых будущих действий по его обработке.
6.3.4.3.4.4 Как только обработка риска выбрана, она должна следовать тем же действиям, что и при менеджменте проблем, в соответствии с действиями по аттестации и управлению, изложенными в 6.3.2 настоящего стандарта или в [18].
6.3.4.3.5 Мониторинг рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.5.1 Все риски и содержание менеджмента рисков должны подвергаться мониторингу для выявления изменений. В случае изменения состояния риска должна быть выполнена его оценка.
6.3.4.3.5.2 Для оценки результативности обработки риска должны разрабатываться и контролироваться соответствующие измеримые показатели.
6.3.4.3.5.3 В течение всего жизненного цикла проекта должен проводиться постоянный мониторинг возникновения новых рисков и их источников.
6.3.4.3.6 Оценка процесса менеджмента рисков
Данный вид деятельности состоит из решения следующих задач:
6.3.4.3.6.1 Должна собираться информация в течение всего жизненного цикла проекта для целей улучшения процесса менеджмента рисков и извлечения практических уроков.
Примечание - Информация о рисках включает в себя идентифицированные риски, их источники, причины, обработку и примеры успешного применения выбранных вариантов обработки.
6.3.4.3.6.2 Процесс менеджмента рисков должен периодически пересматриваться в плане его результативности и эффективности.
6.3.4.3.6.3 Информация об идентифицированных рисках, их обработке и примерах успешной обработки должна периодически пересматриваться с целью выявления системных проектных и организационных рисков.
6.3.5 Процесс менеджмента конфигурации
6.3.5.1 Цель
Цель процесса менеджмента конфигурации состоит в установлении и поддержании целостности всех идентифицированных выходных результатов проекта или процесса обеспечения доступа к ним любой заинтересованной стороны.
6.3.5.2 Выходы
В результате успешного осуществления процесса менеджмента конфигурации:
a) определяется стратегия менеджмента конфигурации;
b) определяются составные части, нуждающиеся в менеджменте конфигурации;
c) устанавливается базовая линия конфигурации;
d) осуществляется управление изменениями в составных частях, находящихся под менеджментом конфигурации;
e) осуществляется управление конфигурацией составных частей, входящих в выпуск;
f) статус составных частей, на которые распространяется менеджмент конфигурации, становится доступным на протяжении всего жизненного цикла.
Примечание - Процесс менеджмента конфигурации программных средств является специальным случаем процесса менеджмента конфигурации и входит в группу процессов поддержки программных средств.
6.3.5.3 Виды деятельности и задачи
В проекте должны осуществляться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента конфигурации.
6.3.5.3.1 Планирование менеджмента конфигурации
Данный вид деятельности состоит из решения следующих задач:
6.3.5.3.1.1 В проекте должна быть определена стратегия менеджмента конфигурации.
Примечание - К этой задаче относят: определение полномочий на запрет или разрешение доступа, выпуск и управление изменениями элементов конфигурации; определение места и условий хранения, включая требования к окружающей среде, а в случае информации - определение носителей для хранения в соответствии с назначенными уровнями целостности, защищенности и безопасности; определение критериев или событий, соответствующих началу управления конфигурацией и сопровождению базовых линий развития конфигураций; определение стратегии аудита и ответственности за гарантии непрерывной целостности и защищенности информации, описывающей конфигурацию. Деятельность менеджмента конфигурации следует согласовать с руководством, представленным в [6].
6.3.5.3.1.2 В проекте должны быть идентифицированы составные части, которые являются предметом управления конфигурацией.
Примечание - Составные части, где это необходимо, различаются уникальными долговременными идентификаторами или маркировками. Идентификаторы должны соответствовать стандартам и соглашениям производственного сектора так, чтобы составные части, находящиеся под управлением конфигурации, однозначно соответствовали своим спецификациям или их эквивалентам, документированным описаниям.
6.3.5.3.2 Осуществление менеджмента конфигурации
Данный вид деятельности состоит из решения следующих задач:
6.3.5.3.2.1 Проект должен поддерживать информацию о конфигурации на приемлемом уровне целостности и защищенности.
Примечание - При решении этой задачи необходимо учитывать особенности составных частей, находящихся под управлением конфигурацией. Конфигурация описывает, где это возможно, соответствие технологическим стандартам или стандартам на продукцию. Необходимо гарантировать, что информация о конфигурации позволяет иметь прямую и обратную прослеживаемость к другим состояниям конфигурации, описываемым базовой линией. Необходимо объединять развивающиеся состояния составных частей конфигурации для формирования документированной базовой линии на определенные моменты времени или при определенных обстоятельствах. Необходимо регистрировать обоснования для базовой линии и связанных с этим полномочий по отношению к данным о базовой линии конфигурации. Необходимо поддерживать записи о конфигурации в течение всего жизненного цикла системы и архивировать их в соответствии с соглашениями, законодательством или передовым производственным опытом.
6.3.5.3.2.2 При реализации проекта необходимо гарантировать надлежащее проведение идентификации, регистрации, оценивания, утверждения, внедрения и верификации при изменениях базовой линии конфигурации.
Примечание - Эта задача также может включать в себя объединение в процессе развития конфигурации состояний ее составных частей для формирования документированной базовой линии на определенный момент времени или при определенных обстоятельствах; регистрацию состояний конфигурации, обоснования для базовой линии и связанных с этим полномочий по отношению к данным о базовой линии конфигурации; поддержку записей о конфигурации в течение всего жизненного цикла системы и архивирование в соответствии с соглашениями, законодательством или наилучшей производственной практикой; управление выполнением записей, изменениями и утверждениями текущего статуса конфигурации и статуса всех предыдущих конфигураций для подтверждения корректности, своевременности, целостности и защищенности информации; проведение аудита для проверки соответствия базовой линии чертежам, документам по управлению интерфейсами и другим согласованным требованиям.
6.3.6 Процесс менеджмента информации
6.3.6.1 Цель
Цель процесса менеджмента информации состоит в своевременном предоставлении заинтересованным сторонам релевантной, своевременной, полной, достоверной и, если требуется, конфиденциальной информации в течение и соответственно после завершения жизненного цикла системы.
В рамках данного процесса реализуется создание, сбор, преобразование, хранение, поиск, распространение и использование информации. Процесс управляет информацией, включая техническую, проектную, организационную, пользовательскую информацию, а также информацию, содержащуюся в соглашениях.
6.3.6.2 Выходы
В результате успешного осуществления процесса менеджмента информации:
a) определяется информация, подлежащая управлению;
b) определяются формы представления информации;
c) информация преобразуется и распределяется в соответствии с требованиями;
d) документируется статус информации;
e) информация является актуальной, полной и достоверной;
f) информация становится доступной для уполномоченных сторон.
Примечание - Процесс менеджмента документации программных средств является частным случаем процесса менеджмента информации и входит в группу процессов поддержки программных средств.
6.3.6.3 Виды деятельности и задачи
В проекте должны осуществляться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса менеджмента информации.
Примечание - В [19] суммируются требования к информационным блокам (документации) и приводится руководство по их разработке.
6.3.6.3.1 Планирование менеджмента информации
Данный вид деятельности состоит из решения следующих задач:
6.3.6.3.1.1 В проекте должны определяться информационные блоки, которые будут подвергаться менеджменту в течение жизненного цикла системы и согласно политике организации или законодательству поддерживаться в течение определенного периода после его окончания.
6.3.6.3.1.2 При реализации проекта необходимо распределять полномочия и обязанности, относящиеся к зарождению, созданию, накоплению, архивированию и использованию информационных блоков.
6.3.6.3.1.3 При реализации проекта должны быть определены права, обязанности и обязательства, касающиеся хранения, передачи и доступа к информационным блокам.
Примечание - Необходимо уделять должное внимание законодательству, защите и сохранению тайны информации и данных, например, по правам владения, договорным ограничениям, правам доступа, интеллектуальной собственности и патентному законодательству. В случае применения ограничений или допущений информация идентифицируется соответствующим образом. Штатному персоналу, который ознакомлен с подобными блоками информации, сообщается о его обязанностях и ответственности.
6.3.6.3.1.4 При реализации проекта необходимо определять содержание, семантику, форматы и средства для представления, хранения, передачи и поиска информации.
Примечание - Информация может появляться и исчезать в любой форме (например, вербальной, текстовой, графической и числовой) и может быть сохранена, обработана, продублирована и передана при помощи любых носителей (например, электронных, печатных, магнитных, оптических). Необходимо учитывать ограничения организации, например, относящиеся к инфраструктуре, связям между организациями и распределенным работам над проектом. Стандарты и соглашения, касающиеся хранения, преобразования, передачи и представления информации, используются в соответствии с политиками организации, соглашениями и ограничениями, указанными в законодательных актах.
6.3.6.3.1.5 При реализации проекта должны определяться действия по сопровождению информации.
Примечание - Эти действия включают в себя анализ состояния хранимой информации в отношении ее целостности, достоверности, доступности и любых потребностей в копировании или переносе на альтернативные носители. Следует рассматривать варианты: либо сохранить инфраструктуру как технологические изменения, чтобы архивные носители данных могли быть прочитаны, либо осуществить перезапись архивных носителей данных, используя новую технологию.
6.3.6.3.2 Выполнение менеджмента информации
Данный вид деятельности состоит из решения следующих задач:
6.3.6.3.2.1 При реализации проекта должны использоваться идентифицированные блоки информации.
Примечание - К этой задаче может относиться формирование информации или ее сбор от соответствующих источников.
6.3.6.3.2.2 При реализации проекта необходимо сопровождать блоки информации и хранящиеся записи этих блоков в соответствии с требованиями к целостности, защищенности и секретности.
Примечание - Следует регистрировать статус составных частей информации, например, описание версий, запись распространения, классификация уровней защиты. Необходимо располагать четкой информацией, хранить и поддерживать ее так, чтобы она легко извлекалась из средств, обеспечивающих подходящую среду, предотвращающую порчу, деградацию и потерю информации.
6.3.6.3.2.3 При реализации проекта необходимо находить и распространять информацию назначенным сторонам в соответствии с требованиями согласованных графиков работ или при определенных обстоятельствах.
Примечание - Информация предоставляется назначенным сторонам в приемлемой форме.
6.3.6.3.2.4 При реализации проекта необходимо предоставлять официальную документацию в соответствии с требованиями.
Примечание - Примерами официальной документации являются сертификаты, свидетельства аккредитации, лицензии и оценочные рейтинги.
6.3.6.3.2.5 При реализации проекта необходимо архивировать заданную информацию в соответствии с целями аудита, сохранением знаний и завершением проекта.
Примечание - Необходимо выбирать носители, их расположение и способы защиты информации в соответствии с заданными периодами хранения и восстановления информации, политикой организации, соглашениями и законодательством. По договоренности гарантируется, что после закрытия проекта на местах остается необходимая документация.
6.3.6.3.2.6 При реализации проекта необходимо уничтожать нежелательную, искаженную или не поддающуюся проверке информацию в соответствии с политикой организации, требованиями к защищенности и сохранению тайны.
6.3.7 Процесс измерений
6.3.7.1 Цель
Цель процесса измерений заключается в сборе, анализе и составлении отчетов о данных, относящихся к разработанным продуктам и процессам, реализованным в пределах определенного организационного подразделения, для поддержки эффективного менеджмента процессов и объективной демонстрации качества этих продуктов.
6.3.7.2 Выходы
В результате успешного осуществления процесса измерений:
а) идентифицируются информационные потребности технических процессов и процессов менеджмента;
b) идентифицируется и (или) разрабатывается соответствующая совокупность единиц измерения, управляемых информационными потребностями;
c) определяются и планируются действия по измерениям;
d) необходимые данные собираются, сохраняются, анализируются и интерпретируются результаты;
e) используются информационные продукты для поддержки решений и обеспечения объективной основы для коммуникаций;
f) оцениваются единицы измерений и процесс измерений;
g) сведения об усовершенствованиях сообщаются владельцу процесса измерений.
6.3.7.3 Виды деятельности и задачи
При реализации проекта должны выполняться следующие виды деятельности и задачи в соответствии с принятыми в организации политиками и процедурами в отношении процесса измерений.
Примечание 1 - В [21] представлена более подробная совокупность действий и задач, которые согласуются с действиями и задачами, приведенными ниже.
Примечание 2 - В [4] конкретизируются требования системы менеджмента качества для измерения и мониторинга процессов и продуктов.
6.3.7.3.1 Планирование измерений
Данный вид деятельности состоит из решения следующих задач:
6.3.7.3.1.1 В проекте необходимо описать характеристики организации, проводящей измерения.
6.3.7.3.1.2 В проекте необходимо идентифицировать и распределить по приоритетам потребности в информации.
6.3.7.3.1.3 При реализации проекта должны быть выбраны и документированы единицы измерения, удовлетворяющие информационным потребностям.
6.3.7.3.1.4 В проекте необходимо определять процедуры сбора данных, анализа и представления отчетов.
6.3.7.3.1.5 В проекте необходимо определять критерии для оценки информационных продуктов и процесса измерений.
6.3.7.3.1.6 При реализации проекта необходимо рассмотреть, одобрить и обеспечить ресурсы для решения задач измерений.
6.3.7.3.1.7 В проекте должно быть предусмотрено приобретение и развертывание поддерживающих технологий.
6.3.7.3.2 Выполнение измерений
Данный вид деятельности состоит из решения следующих задач:
6.3.7.3.2.1 В проекте необходимо объединять процедуры для создания, сбора, анализа данных и представления отчетов в соответствующие процессы.
6.3.7.3.2.2 Данные при реализации проекта должны накапливаться, сохраняться и проверяться.
6.3.7.3.2.3 В рамках проекта необходимо выполнять анализ данных и разрабатывать информационные продукты.
6.3.7.3.2.4 При реализации проекта необходимо документировать и сообщать результаты пользователям измерений.
6.3.7.3.3 Оценивание измерений
Данный вид деятельности состоит из решения следующих задач:
6.3.7.3.3.1 При реализации проекта необходимо оценивать информационные продукты и процесс измерений.
6.3.7.3.3.2 В проекте должно быть предусмотрено выявление потенциальных улучшений и информирование о них.
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 Используемые данные или данные, связанные с прекращением применения программных продуктов, должны быть доступны в соответствии с требованиями контракта по защите данных и проведению аудитов применительно к данным.