Основные процессы жизненного цикла.

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

1. процесс заказа;

2. процесс поставки;

3. процесс разработки;

4. процесс эксплуатации;

5. процесс сопровождения.

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

Процесс заказа

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

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

Заказчик управляет процессом заказа на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом заказа на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4).

Список работ. Данный процесс состоит из следующих работ:

1. подготовка;

2. подготовка заявки на подряд;

3. подготовка и корректировка договора;

4. надзор за поставщиком;

5. приемка и закрытие договора.

5.1.1 Подготовка Данная работа состоит из следующих задач:

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

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

5.1.1.3 Если заказчик поручает поставщику выполнение анализа требований к системе, то заказчик должен согласовать требования, сформулированные в результате анализа.

5.1.1.4 Заказчик может выполнить определение и анализ требований к программным средствам сам или поручить решение этой задачи поставщику.

5.1.1.5 При решении задач, определенных в 5.1.1.2 и 5.1.1.4, должен использоваться процесс разработки (подраздел 5.3).

5.1.1.6 Заказчик должен рассмотреть варианты реализации заказа, начиная с анализа соответствующих критериев, включая рискованность и стоимость проекта и выгоды от каждого варианта. Анализируются следующие варианты:

a) покупка готового программного продукта, удовлетворяющего определенным требованиям;

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

c) разработка программного продукта или получение программной услуги на договорной основе;

а) комбинации по перечислениям а), b), с);

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

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

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

5.1.1.8 Заказчик должен подготовить, документально оформить и выполнить план заказа. План должен содержать:

a) требования к системе;
b) планируемую загрузку системы;
c) тип реализуемого договора;
d) обязанности организаций, участвующих в договоре;
e) обеспечение подходов к реализации договора;
f) анализ возможных рискованных ситуаций, а также методы управления такими ситуациями.

5.1.1.9 Заказчик должен определить и документально оформить принятые правила и условия (критерии) реализации договора.

5.1.2 Подготовка заявки на подряд. Данная работа состоит из следующих задач:

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

a) требования к системе;
b) описание области применения системы;
c) указания для участников торгов;
d) список программных продуктов;
e) сроки и условия реализации заказа;

О правила контроля над субподрядчиками;

g) технические ограничения (например, по условиям эксплуатации).

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

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

5.1.2.4 Требования к заказу должны быть представлены организации, выбранной для выполнения работ в процессе заказа.

5.1.3 Подготовка и корректировка договора Данная работа состоит из следующих задач:

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

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

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

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

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

Примечание— Заказчик определяет, используется ли при применении настоящего стандарта термин "договор» или «соглашение».

5.1.4 Надзор за поставщиком.

Данная работа состоит из следующих задач:

5.1.4.1 Заказчик должен осуществлять надзор за работами поставщика в соответствии с процессами совместного анализа (подраздел 6.6) и аудита (подраздел 6.7). При необходимости заказчик должен дополнять текущий надзор процессами верификации (подраздел 6.4) и аттестации (подраздел 6.5).

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

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

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

5.1.5.3 После приемки заказчик должен принять на себя ответственность за управление конфигурацией поставленного программного продукта (см. подраздел 6.2).

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

Процесс поставки

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

Поставщик управляет процессом поставки на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом поставки на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4).

Список работ. Данный процесс состоит из следующих работ:

1. подготовка;

2. подготовка ответа;

3. подготовка договора;

4. планирование;

5. выполнение и контроль;

6. проверка и оценка;

7. поставка и закрытие договора.

5.2.1 Подготовка

Данная работа состоит из следующих задач:

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

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

5.2.2 Подготовка ответа

Данная работа состоит из следующей задачи:

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

5.2.3 Подготовка договора

Данная работа состоит из следующих задач:

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

5.2.3.2 Поставщик может предложить внести изменения в текст договора по согласованию с заказчиком.

5.2.4 Планирование Данная работа состоит из следующих задач:

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

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

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

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

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

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

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

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

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

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

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

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

g) обеспечения качества (см. подраздел 6.3);

h) верификации (см. подраздел 6.4) и аттестации (см. подраздел 6.5), включая подходы к взаимоотношению с верифицирующими и аттестующими организациями, при их наличии;

i) взаимоотношений с заказчиком, которые реализуются такими средствами, как совместные анализы (см. подраздел 6.6), аудиторские проверки (см. подраздел 6.7), совещания, отчеты. модификации и изменения, реализации, утверждение, приемка и рабочие контакты;

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

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

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

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

n) средств для планирования, надзора и отчетности;

р) обучения персонала (см. подраздел 7.4).

5.2.5 Выполнение и контроль

Данная работа состоит из следующих задач:

5.2.5.1 Поставщик должен реализовать планы управления проектом, разработанные в соответствии с 5.2.4.

5.2.5.2 Поставщик должен:

a) разработать программный продукт в соответствии с процессом разработки (подраздел 5.3);

b) провести опытную эксплуатацию программного продукта в соответствии с процессом эксплуатации (подраздел 5.4);

c) сопровождать программный продукт в соответствии с процессом сопровождения (подраздел 5.5).

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

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

b) выявление возникающих проблем, их документальное оформление, анализ и решение.

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

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

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

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

5.2.6.2 Поставщик должен проводить или участвовать в совещаниях, подготовке приемки, приемочных испытаниях, совместных анализах и аудиторских проверках вместе с заказчиком в соответствии с договором и проектными планами. Совместные анализы должны проводиться в соответствии с подразделом 6.6, а аудиторские проверки — в соответствии с подразделом 6.7.

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

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

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

5.2.6.6 Поставщик должен выполнять работы по обеспечению качества в соответствии с подразделом 6.3.

5.2.7 Поставка и закрытие договора Данная работа состоит из следующих задач:

5.2.7.1 Поставщик должен поставить программный продукт или услугу заказчику в соответствии с условиями договора.

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

Процесс разработки

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

Разработчик управляет процессом разработки на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом разработки на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если разработчиком является поставщик разрабатываемого программного продукта, то разработчик должен также выполнять процесс поставки (подраздел 5.2).

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;

2. анализ требований к системе;

3. проектирование системной архитектуры;

4. анализ требований к программным средствам;

5. проектирование программной архитектуры;

6. техническое проектирование программных средств;

7. программирование и тестирование программных средств;

8. сборка программных средств;

9. квалификационные испытания программных средств;

10. сборка системы;

11. квалификационные испытания системы;

12. ввод в действие программных средств;

13. обеспечение приемки программных средств.

5.3.1 Подготовка процесса,

Данная работа состоит из следующих задач:

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

Примечание— Данные работы и задачи могут пересекаться или взаимодействовать и выполняться итерационно или рекурсивно.

5.3.1.2 Разработчик должен:

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

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

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

d) выполнить вспомогательные процессы (раздел 6) в соответствии с условиями договора.

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

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

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

5.3.2 Анализ требований к системе

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

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

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

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

a) учет потребностей заказчика;

b) соответствие потребностям заказчика;

c) тестируемость;

d) выполнимость проектирования системной архитектуры;

e) возможность эксплуатации и сопровождения.

5.3.3 Проектирование системной архитектуры

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

5.3.3.2 Системная архитектура и требования к объектам архитектуры должны быть оценены с учетом следующих критериев (при этом результаты оценок должны быть документально оформлены):

a) учет требований к системе;

b) соответствие требованиям к системе;

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

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

e) возможности эксплуатации и сопровождения.

5.3.4 Анализ требований к программным средствам

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

5.3.4.1 Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества (рекомендации по определению характеристик качества приведены в ГОСТ Р ИСО/МЭК 9126):

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

b) требования к внешним интерфейсам программного объекта архитектуры;

c) квалификационные требования;

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

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

О эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию «человек-машина», персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала;

g) требования к определению данных и базе данных;

h) требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения;

i) требования к документации пользователя;

j) требования к эксплуатации объекта пользователем;

k) требования к обслуживанию пользователя.

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

a) учет требований к системе и проекту системы;

b) внешняя согласованность с требованиями к системе;

c) внутренняя согласованность требований к объектам между собой;

d) тестируемость требований;

e) выполнимость программного проекта;

О возможность эксплуатации и сопровождения.

5.3.4.3 Разработчик должен провести совместный анализ(ы) в соответствии с подразделом 6.6. После успешного проведения анализа(ов) должно быть зафиксировано состояние требований к программному объекту.

5.3.5 Проектирование программной архитектуры

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

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

5.3.5.3 Разработчик должен разработать и документально оформить общий (эскизный) проект базы данных.

5.3.5.4 Разработчик должен разработать и документально оформить предварительные версии документации пользователя.

5.3.5.5 Разработчик должен определить и документально оформить предварительные общие требования к испытаниям (тестированию) программного объекта и график сборки программного продукта.

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

a) учет требований к программному объекту;

b) внешняя согласованность с требованиями к программному объекту;

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

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

e) возможность технического проектирования;

f) возможность эксплуатации и сопровождения.

5.3.5.7 Разработчик должен провести совместный анализ(ы) в соответствии с подразделом 6.6.

5.3.6 Техническое проектирование программных средств

5.3.6.1 Разработчик должен разработать технический проект для каждого компонента программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать (кодировать), компилировать и тестировать независимо. Должно быть обеспечено распределение технических требований к компонентам программного объекта между программными модулями. Технический проект должен быть документально оформлен.

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

5.3.6.3 Разработчик должен разработать и документально оформить технический проект базы данных.

5.3.6.4 Разработчик должен, при необходимости, уточнить документацию пользователя.

5.3.6.5 Разработчик должен определить и документально оформить требования к испытаниям и программе испытаний программных модулей. Требования к испытаниям должны определять воздействие на программный модуль в пределах установленных к нему требований.

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

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

a) учет требований к программному объекту;
b) внешнее соответствие спроектированной архитектуре;
c) внутренняя согласованность между компонентами программного объекта и программными модулями;
d) соответствие методов проектирования и используемых стандартов;
e) возможность тестирования;
f) возможность эксплуатации и сопровождения.

5.3.6.8 Разработчик должен провести совместный анализ(ы) в соответствии с подразделом 6.6.

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

5.3.7.1 Разработчик должен разработать и документально оформить следующие продукты:

a) каждый программный модуль и базу данных;
b) процедуры испытаний (тестирования) и данные для тестирования каждого программного модуля и базы данных.

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

5.3.7.3 Разработчик, при необходимости, должен уточнить документацию пользователя.

5.3.7.4 Разработчик должен уточнить общие требования к тестированию и программу сборки программных средств.

5.3.7.5 Разработчик должен оценить запрограммированные элементы программного объекта и результаты их тестирования по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) учет требований к программному объекту и проекту объекта в целом;
b) внешнее соответствие требованиям и проекту программного объекта;
c) внутреннее соответствие между требованиями к программным модулям;
а) тестовое покрытие всех модулей;
e) соответствие методов программирования и используемых для них стандартов;
f) возможность сборки и тестирования;
g) возможность эксплуатации и сопровождения. 5.3.8 Сборка программных средств

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

5.3.8.2 Разработчик должен собрать программные модули и компоненты и протестировать их как продукты, разработанные в соответствии с планом сборки. Должно быть обеспечено, чтобы каждая сборка удовлетворяла требованиям к программному объекту и чтобы программный объект был полностью собран в результате данной работы. Результаты сборки и тестирования должны быть документально оформлены.

5.3.8.3 Разработчик, при необходимости, должен уточнить документацию пользователя.

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

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

a) учет требований к системе;

b) внешнее соответствие требованиям к системе;

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

а) тестовое покрытие требований к программному объекту;

e) соответствие используемых испытательных стандартов и методов испытаний;

f) соответствие ожидаемым результатам;

g) выполнимость квалификационного испытания программного объекта;

h) возможность эксплуатации и сопровождения.

5.3.8.6 Разработчик должен проводить совместный анализ(ы) в соответствии с подразделом 6.6.

5.3.9 Квалификационные испытания программных средств

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

5.3.9.2 Разработчик, при необходимости, должен уточнить документацию пользователя.

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

a) тестовое покрытие требований к программному объекту;

b) соответствие ожидаемым результатам;

c) возможность сборки и тестирования системы (при их проведении);

d) возможность эксплуатации и сопровождения.

5.3.9.4 Разработчик должен обеспечить проведение аудиторской проверки(ок) в соответствии с подразделом 6.7. Результаты аудиторских проверок должны быть документально оформлены. Если при реализации конкретного проекта разрабатывались или собирались как технические, так и программные средства, то проведение аудиторских проверок может быть отложено до квалификационных испытаний системы.

5.3.9.5 После успешного завершения аудиторских проверок, если они проводились, разработчик должен:

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

b) определить состояние конфигурации (базовую линию) проекта и программ данного программного объекта.

Примечание — Квалификационное испытание может быть выполнено в процессах верификации (подраздел 6.4) или аттестации (подраздел 6.5).

5.3.10 Сборка системы

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

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

5.3.10.3 Собранная система должна быть оценена по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) тестовое покрытие требований к системе;

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

c) соответствие ожидаемым результатам;

d) выполнимость квалификационных испытаний системы;

e) возможность эксплуатации и сопровождения. 5.3.11 Квалификационные испытания системы:

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

5.3.11.2 Система должна быть оценена по следующим критериям (при этом результаты оценок должны быть документально оформлены):

a) тестовое покрытие требований к системе;
b) соответствие ожидаемым результатам;
c) возможность эксплуатации и сопровождения.

5.3.11.3 Разработчик должен обеспечить проведение аудиторской проверки(ок) в соответствии с подразделом 6.7. Результаты аудиторской проверки(ок) должны быть документально оформлены.

Примечание— Этот подпункт не применяется к тем объектам программной конфигурации, для которых аудиторские проверки были проведены ранее.

5.3.11.4 После успешного завершения аудиторских проверок, если они проводились, разработчик должен:

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

b) определить состояние конфигурации (базовую линию) проекта и программ каждого объекта программной конфигурации.

Примечание— Квалификационное испытание системы может быть выполнено в процессах верификации (подраздел 6.4) или аттестации (подраздел 6.5).

5.3.12 Ввод в действие программных средств Данная работа состоит из следующих задач:

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

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

5.3.13 Обеспечение приемки программных средств

Данная работа состоит из следующих задач:

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

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

5.3.13.3 Разработчик должен, соблюдая условия договора, обеспечить первоначальное и непрерывное обучение и поддержку персонала заказчика.

Процесс эксплуатации

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

Оператор управляет процессом эксплуатации на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом эксплуатации на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если оператор является поставщиком программной услуги, то оператор выполняет также процесс поставки (подраздел 5.2).

Список работ. Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) эксплуатационные испытания;

3) эксплуатация системы;

4) поддержка пользователя.

5.4.1 Подготовка процесса

Данная работа состоит из следующих задач:

5.4.1.1 Оператор должен разработать план эксплуатации и определить набор стандартов по эксплуатации для выполнения работ и задач данного процесса. План должен быть документально оформлен и выполнен.

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

5.4.1.3 Оператор должен установить процедуры для: тестирования программного продукта в эксплуатационной среде; ввода сообщений о проблемах и предложений об изменениях в процесс сопровождения (подраздел 5.5); ввода программного продукта в эксплуатацию.

5.4.2 Эксплуатационные испытания

Данная работа состоит из следующих задач:

5.4.2.1 Для каждого введенного в опытную эксплуатацию программного продукта оператор должен провести эксплуатационные испытания и при соответствии результатов испытаний установленным требованиям ввести программный продукт в промышленную эксплуатацию.

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

5.4.3 Эксплуатация система

Данная работа состоит из следующей задачи:

5.4.3.1 Система должна эксплуатироваться в установленной для нее эксплуатационной среде в соответствии с документацией пользователя.

5.4.4 Поддержка пользователя

Данная работа состоит из следующих задач:

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

5.4.4.2 Оператор должен, при необходимости, направлять запросы пользователя для анализа и ответа в процесс сопровождения (подраздел 5.5). Данные запросы должны быть приняты, а ответы по планируемым и выполняемым ответным действиям должны быть направлены инициаторам запросов. Все принимаемые решения должны контролироваться вплоть до их выполнения.

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

Процесс сопровождения

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

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

Персонал сопровождения управляет процессом сопровождения на проектном уровне в соответствии с процессом управления (подраздел 7.1), который конкретизируется в данном процессе;

определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2); адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации (приложение А) и управляет процессом сопровождения на организационном уровне в соответствии с процессами усовершенствования (подраздел 7.3) и обучения (подраздел 7.4). Если персонал сопровождения является поставщиком услуги по сопровождению, он реализует процесс поставки (подраздел 5.2).

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;

2. анализ проблем и изменений;

3. внесение изменений;

4. проверка и приемка при сопровождении;

5. перенос;

6. снятие с эксплуатации.

5.5.1 Подготовка процесса

Данная работа состоит из следующих задач:

5.5.1.1 Персонал сопровождения должен разработать, документально оформить и выполнить планы и процедуры для проведения работ и задач процесса сопровождения.

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

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

5.5.2 Анализ проблем и изменений

Данная работа состоит из следующих задач:

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

a) типу, например: корректировка, модернизация, профилактика или адаптация к новым условиям;
b) объему, например: размеру изменения, стоимости, времени на реализацию изменения;
c) критичности, например: влиянию на производительность, безопасность или защиту.

5.5.2.2 Персонал сопровождения должен продублировать или верифицировать возникшую проблему.

5.5.2.3 На основе проведенного анализа персонал сопровождения должен разработать варианты реализации изменения.

5.5.2.4 Персонал сопровождения должен документально оформить: сообщение о проблеме или заявку на внесение изменений; результаты их анализа и варианты реализации изменений.

5.5.2.5 Персонал сопровождения должен получить согласование выбранного варианта изменения в соответствии с договором. 5.5.3 Внесение изменений Данная работа состоит из следующих задач:

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

5.5.3.2 Персонал сопровождения должен использовать процесс разработки (подраздел 5.3) для реализации изменений. Требования к процессу разработки должны быть дополнены следующим образом:

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

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

5.5.4 Проверка и приемка при сопровождений

Данная работа состоит из следующих задач:

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

5.5.4.2 Персонал сопровождения должен получить подтверждение того, что внесенное изменение удовлетворяет требованиям, установленным в договоре.

5.5.5 Перенос

Данная работа состоит из следующих задач:

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

5.5.5.2 Должен быть разработан, документально оформлен и выполнен план переноса объекта. К планируемым работам должны привлекаться пользователи. В содержание плана должны быть включены:

a) анализ и установление требований к переносу;

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

c) настройка программного продукта и данных к новым условиям эксплуатации;

d) выполнение переноса;

e) верификация переноса;

f) последующая поддержка прежней среды.

5.5.5.3 Пользователям должно быть направлено уведомление о планах и работах по переносу объекта. В содержание уведомления должно быть включено:

a) объяснение того, почему прежняя среда не может больше поддерживаться;

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

c) описание других доступных вариантов поддержки в случае прекращения поддержки прежней среды.

5.5.5.4 Для плавного перехода в новую среду параллельно могут выполняться работы в прежней и новой среде. В течение этого периода должно быть обеспечено необходимое обучение персонала в соответствии с условиями договора.

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

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

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

5.5.6 Снятие с эксплуатации

Данная работа состоит из следующих задач:

Примечание — Программный продукт может сниматься по заявке собственника.

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

a) сроки прекращения полной или частичной поддержки;

b) требования по архивации программного продукта и соответствующей документации;

c) обязательства по любым оставшимся вопросам поддержки;

d) сроки перехода, при необходимости, к новому программному продукту;

e) требования по доступу к архивным копиям данных.

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

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

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

c) описание других доступных вариантов поддержки в случае прекращения поддержки прежнего объекта.

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

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

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

6. Вспомогательные процессы жизненного цикла:

вспомогательные процессы жизненного цикла:

1. процесс документирования;

2. процесс управления конфигурацией;

3. процесс обеспечения качества;

4. процесс верификации;

5. процесс аттестации;

6. процесс совместного анализа;

7. процесс аудита;

8. процесс решения проблем.

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

Данная организация организует и выполняет управление вспомогательным процессом на проектном уровне в соответствии с процессом управления (подраздел 7.1); определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (подраздел 7.2);

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

Процесс документирования

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

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;

2. проектирование и разработка;

3. выпуск;

4. сопровождение.

6.1.1 Подготовка процесса

Данная работа состоит из следующих задач:

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

a) заголовок или наименование;

b) назначение;

c) пользователи документа;

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

e) сроки выпуска промежуточных и окончательных редакций.

6.1.2 Проектирование и разработка

Данная работа состоит из следующих задач:

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

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

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

6.1.З Выпуск

Данная работа состоит из следующих задач:

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

6.1.3.2 Средства управления документированием должны быть определены в соответствии с процессом управления конфигурацией (подраздел 6.2).

6.1.4 Сопровождение

Данная работа состоит из следующей задачи:

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

6.2 Процесс управления конфигурацией

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

управления изменениями и выпуском объектов; описания и сообщения о состояниях объектов и заявок на внесение изменений в них; обеспечения полноты, совместимости и правильности объектов; управления хранением, обращением и поставкой объектов.

Примечание— Когда данный процесс применяется к другим программным продуктам или объектам, термин «программный объект» интерпретируется ниже соответствующим образом.

Список работ. Данный процесс состоит из следующих работ:

1. подготовка процесса;

2. определение конфигурации;

3. контроль конфигурации;

4. учет состояний конфигурации;

5. оценка конфигурации;

6. управление выпуском и поставка.

6.2.1 Подготовка процесса

Данная работа состоит из следующей задачи:

6.2.1.1 Должен быть разработан план управления конфигурацией. План должен определять:

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

Примечание— Данный план может быть частью плана управления конфигурацией системы.

6.2.2 Определение конфигурации.

Данная работа состоит из следующей задачи:

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

6.2.3 Контроль конфигурации

Данная работа состоит из следующей задачи:

6.2.3.1 Должны быть выполнены: обозначение и регистрация заявок на внесение изменений;

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

6.2.4 Учет состояний конфигурации

Данная работа состоит из следующей задачи:

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

6.2.5 Оценка конфигурации

Данная работа состоит из с