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

"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ. ГОСТ Р ИСО/МЭК 12207-2010" (утв. Приказом Ростехрегулирования от 30.11.2010 N 631-ст)

6.1.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 Выбор поставщика

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

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 Закрытие

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

6.1.2.3.6.1 Поставщик должен принять и подтвердить оплату или другие согласованные способы расчета.

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

Примечание - В соглашении следует указывать сроки и полномочия для инициации закрытия проекта.