Информационная технология

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ

Издание официальное

ГОССТАНДАРТ РОССИИ Москва

Предисловие

1    РАЗРАБОТАН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России

ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационная технология»

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 23 декабря 1999 г. № 675-ст

3    Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 12207—95 «Информационная технология. Процессы жизненного цикла программных средств»

4    ВВЕДЕН ВПЕРВЫЕ

5    ПЕРЕИЗДАНИЕ. Июль 2003 г.

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

© ИПК Издательство стандартов, 2000 © ИПК Издательство стандартов, 2003 © СТАНДАРТИНФОРМ, 2008 Переиздание (по состоянию на май 2008 г.)

ГОСТ Р ИСО/МЭК 12207-99

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

1)    Процесс управления (подраздел 7.1). Определяет основные работы по управлению, включая управление проектом, при реализации процессов жизненного цикла.

2)    Процесс создания инфраструктуры (подраздел 7.2). Определяет основные работы по созданию основной структуры процесса жизненного цикла.

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

4)    Процесс обучения (подраздел 7.4). Определяет работы по соответствующему обучению персонала.

4.1.2    Процесс адаптации

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

4.1.3    Взаимосвязи между процессами и организациями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7

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)    разработка программного продукта или получение программной услуги на договорной

основе;

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

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

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

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

b)    имеется в наличии соответствующая документация;

c)    соблюдены права собственности, использования, лицензирования и гарантии;

d)    предусмотрена последующая поддержка программного продукта.

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)    сроки и условия реализации заказа;

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

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

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

8

ГОСТ Р ИСО/МЭК 12207-99

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

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

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

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

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

9

проектных планов и их выполнение посредством поставки системы, программного продукта или программной услуги заказчику.

Поставщик управляет процессом поставки на проектном уровне в соответствии с процессом управления (подраздел 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)    комбинации по перечислениям а), Ь), с).

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

10

ГОСТ Р ИСО/МЭК 12207-99

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11

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    Поставщик должен помогать заказчику в поддержке поставленного программного продукта или услуги в соответствии с условиями договора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 12207-99

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

13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14

ГОСТ Р ИСО/МЭК 12207-99

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)    процедуры испытаний (тестирования) и данные для тестирования каждого программного модуля и базы данных.

15

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

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

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

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

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

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

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

d)    тестовое покрытие всех модулей;

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)    внутренняя согласованность между программными объектами;

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

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

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 12207-99

Содержание

1    Область применения....................................................... 1

1.1    Назначение.......................................................... 1

1.2    Область распространения................................................ 1

1.3    Адаптация настоящего стандарта.......................................... 1

1.4    Соответствие......................................................... 1

1.5    Ограничения......................................................... 2

2    Нормативные ссылки...................................................... 2

3    Определения............................................................. 2

4    Прикладное применение настоящего стандарта.................................. 5

4.1    Построение стандарта................................................... 5

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

5.1    Процесс    заказа........................................................ 7

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

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

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

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

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

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

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

6.3    Процесс    обеспечения качества............................................24

6.4    Процесс    верификации..................................................25

6.5    Процесс    аттестации....................................................27

6.6    Процесс    совместного анализа.............................................28

6.7    Процесс    аудита........................................................29

6.8    Процесс    решения проблем...............................................30

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

7.1    Процесс    управления....................................................31

7.2    Процесс    создания инфраструктуры.........................................32

7.3    Процесс усовершенствования.............................................32

7.4    Процесс обучения.....................................................33

Приложение А Процесс адаптации.............................................34

Приложение В Руководство по адаптации........................................35

Приложение С Руководство по процессам и организациям...........................39

Приложение D Библиография.................................................42

III

ГОСТ Р ИСО/МЭК 12207-99

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. Результаты аудиторской проверки(ок) должны быть документально оформлены.

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

17

Введение

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

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

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

IV

ГОСТ Р ИСО/МЭК 12207-99

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ

Information technology.

Software life cycle processes

Дата введения 2000—07—01

1 Область применения

1.1. Назначение

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

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

1.2    Область распространения

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

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

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

Стандарт не распространяется на готовые программные продукты, если они не входят в поставляемый продукт.

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

1.3    Адаптация настоящего стандарта

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

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

1.4    Соответствие

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

Издание официальное

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

1.5 Ограничения

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

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

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

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

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

В тексте настоящего стандарта приведен ряд перечней задач, однако ни один из перечней нельзя считать исчерпывающим, и они приведены в качестве примеров.

2    Нормативные ссылки

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

ГОСТ Р ИСО 9001-96¹ Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании

ГОСТ Р ИСО 9001-2001 Системы менеджмента качества. Требования

ГОСТ Р ИСО/МЭК 9126—93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению

ИСО/МЭК 2382-1—93² Информационная технология. Словарь. Часть 1. Основополагающие термины

ИСО/МЭК 2382-20—90² Информационная технология. Словарь. Часть 20. Разработка систем

ИСО 8402—94² Управление качеством и обеспечение качества. Словарь

3    Определения

В настоящем стандарте применяются термины с соответствующими определениями по ИСО/МЭК 2382-1, ИСО/МЭК 2382-20 и ИСО 8402, а также приведенные ниже:

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

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

П римечание — Заказчиком может быть: оптовый или розничный покупатель, клиент, владелец, пользователь.

3.2    заказ (acquisition): Процесс приобретения системы, программного продукта или программной услуги.

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

ГОСТ Р ИСО/МЭК 12207-99

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

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

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

3.7    договор (contract): Обязательное соглашение между двумя сторонами, подкрепленное законодательно, или аналогичное соглашение внутри данной организации: по предоставлению программной услуги; на поставку, разработку, производство, эксплуатацию или сопровождение программного продукта.

3.8    разработчик (developer): Организация, выполняющая работы по разработке (включая анализ требований, проектирование, приемочные испытания) в процессе жизненного цикла программных средств.

3.9    оценка (evaluation): Систематическое определение степени соответствия объекта установленным критериям.

3.10    программно-аппаратное средство (firmware): Сочетание технических устройств и машинных команд или используемых вычислительной машиной данных, постоянно хранящихся на техническом устройстве в виде постоянного программного средства. Данное программное средство не может изменяться только средствами программирования.

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

3.12    персонал сопровождения (maintainer): Организация, которая выполняет работы по сопровождению.

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

3.14    непоставляемое изделие (non-deliverable item): Техническое или программное средство, которое не поставляется по условиям договора, но может быть применено при создании программного продукта.

3.15    готовый продукт (off-the-shelf product): Ранее разработанный и доступный для приобретения продукт, пригодный для использования в поставляемом или модифицированном виде.

3.16    оператор (operator): Организация, эксплуатирующая систему.

3.17    процесс (process): Набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты.

Примечание — Термин «работы» подразумевает использование ресурсов (См. 1.2 ИСО 8402).

3.18    квалификация (qualification): Процесс демонстрации возможности объекта выполнять установленные требования (См. 2.13 ИСО 8402).

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

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

3.21    обеспечение качества (quality assurance): Все запланированные и систематически выполняемые в рамках системы качества работы; при необходимости объективные доказательства, обеспечивающие уверенность в том, что объект будет полностью соответствовать установленным требованиям качества.

Примечания

1 Существуют как внешние, так и внутренние цели обеспечения качества:

a)    внутреннее обеспечение качества — внутри организации обеспечение качества создает уверенность у руководства;

b)    внешнее обеспечение качества — в договорных или других ситуациях обеспечение качества создает уверенность у потребителя или других лиц.

3

2    Некоторые виды работ по управлению качеством и обеспечению качества взаимосвязаны.

3    Если требования к качеству не полностью отражают потребности пользователя, то обеспечение качества может не создать достаточной уверенности. (См. 3.5 ИСО 8402).

3.22    выпуск (release): Конкретная версия элемента конфигурации, которая доступна для реализации конкретной цели (например, тестируемый выпуск).

3.23    заявка на подряд (request for proposal [tender]): Документ, используемый заказчиком в качестве средства для объявления о своих намерениях выступить в качестве потенциального покупателя конкретной системы, программного продукта или программной услуги.

3.24    снятие с эксплуатации (retirement): Прекращение активной поддержки действующей системы со стороны эксплуатирующей или сопровождающей организации, частичная или полная замена ее новой системой или ввод в действие модернизированной системы.

3.25    защита (security): Сохранение информации и данных так, чтобы недопущенные к ним лица или системы не могли их читать или изменять, а допущенные лица или системы не ограничивались в доступе к ним.

3.26    программный продукт (software product): Набор машинных программ, процедур и, возможно, связанных с ними документации и данных.

3.27    программная услуга (software servise): Выполнение работ, заданий или обязанностей, связанных с программным продуктом, таких как разработка, сопровождение или эксплуатация.

3.28    программный модуль (software unit): Отдельно компилируемая часть программного кода (программы).

3.29    техническое задание (statement of work): Документ, используемый заказчиком в качестве средства для описания и определения задач, выполняемых при реализации договора.

3.30    поставщик (supplier): Организация, которая заключает договор с заказчиком на поставку системы, программного продукта или программной услуги на условиях, оговоренных в договоре.

Примечания

1    Синонимами термина «поставщик» являются термины «подрядчик», «производитель», «оптовик» или

«продавец».

2    Заказчик может определить в качестве поставщика подразделение собственной организации.

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

3.32    тестовое покрытие (test coverage): Степень, до которой с помощью контрольных примеров проверяют требования к системе или программному продукту.

3.33    тестируемость (testability): Степень, до которой могут быть запланированы объективность и реализуемость тестирования, проверяющего соответствие требованию.

3.34    пользователь (user): Лицо или организация, которое использует действующую систему для выполнения конкретной функции.

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

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

Примечания

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

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

3    Термин «аттестован» используется для обозначения соответствующих состояний объекта.

4    Может быть проведен ряд аттестаций, если они преследуют различные цели. (См. 2.18 ИСО 8402).

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

Примечания

1    В процессе проектирования и разработки верификация связана с экспертизой результатов данной работы в целях определения их соответствия установленным требованиям.

2    Термин «верифицирован» используется для обозначения соответствующих состояний проверенного объекта. (См. 2.17 ИСО 8402).

3.37    версия (version): Определенный экземпляр объекта.

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

4

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

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

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

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

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

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

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

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

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

процессами являются:

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

2)    Процесс управления конфигурацией (подраздел 6.2). Определяет работы по управлению конфигурацией.

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

4)    Процесс верификации (подраздел 6.4). Определяет работы (заказчика, поставщика или независимой стороны) по верификации программных продуктов по мере реализации программного проекта.

5)    Процесс аттестации (подраздел 6.5). Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

6)    Процесс совместного анализа (подраздел 6.6). Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.

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

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

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

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

6

1

Действует до 15 декабря 2003 г.

2

Оригиналы международных стандартов ИСО/МЭК — во ВНИИКИ Госстандарта России.