Стандарт iso iec 12207 определяет. Техническая документация

5.2.2 Краткое содержание процессов жизненного цикла

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

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

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

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

Таким образом, процессы соглашения, приведенные в настоящем стандарте, ориентированы на программные средства процессами соглашения из .

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

Процессы организационного обеспечения проекта включают в себя:

a) процесс менеджмента модели жизненного цикла;

B) процесс менеджмента инфраструктуры;

c) процесс менеджмента портфеля проектов;

d) процесс менеджмента людских ресурсов;

e) процесс менеджмента качества.

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

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

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

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

а) процесс планирования проекта;

b) процесс управления и оценки проекта.

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

a) процесс менеджмента решений;

b) процесс менеджмента рисков;

c) процесс менеджмента конфигурации;

d) процесс менеджмента информации;

е)процесс измерений.

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

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

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

Технические процессы состоят из следующих процессов:

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

b) анализ системных требований (специальный случай процесса анализа требований);

C) проектирование архитектуры системы (специальный случай процесса проектирования архитектуры, приведенного в );

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

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

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

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

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

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

j) процесс сопровождения программных средств (специальный случай процесса сопровождения, приведенного в );

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

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

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

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

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

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

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

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

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

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

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

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

a) процесс менеджмента документации программных средств;

b) процесс менеджмента конфигурации программных средств;

c) процесс обеспечения гарантии качества программных средств;

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

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

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

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

H) процесс решения проблем в программных средствах.

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

Процессами повторного применения программных средств являются:

a) процесс проектирования доменов;

b) процесс менеджмента повторного применения активов;

C) процесс менеджмента повторного применения программ.

ISO/IEC 12207-2008 «System and software engineering -- Software life cycle processes» - стандарт ISO, описывающий процессы жизненного цикла ПО. Стандарт разработан подкомитетом ПК 7 «Системная и программная инженерия» (англ. SC 7 System and Software Engineering) Совместного технического комитета №1 ИСО/МЭК «Информационные технологии». Стандарт был выпущен взамен стандарту ISO/IEC 12207-95.

Стандарт ISO/IEC 12207-2008 взаимосвязан со стандартами IEEE, такими как:

· IEEE Std 730 - 2002 - Процесс обеспечения гарантии качества программных средств

· IEEE Std 1012 - 2004 - Процесс верификации и валидации программных средств

· IEEE Std 828 - 2005 - Процесс менеджемента конфигурации программных средств

· IEEE Std 829 - 1998 - Процесс квалификационного тестирования программных средств и др.

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

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

1. Основные процессы

2. Поддерживающие процессы

3. Организационные процессы

4. Адаптация.

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

Процессы жизненного цикла

Группы процессов жизненного цикла включают в себя:

· процессы соглашения -- 2;

· процессы организационного обеспечения проекта -- 5;

· процессы проекта -- 7;

· технические процессы -- 11;

· процессы реализации программных средств -- 7;

· процессы поддержки программных средств -- 8;

· процессы повторного применения программных средств -- 3.

Процессы соглашения

· Поставка

· Приобретение

Процессы организационного обеспечения проекта

· Процесс менеджмента модели жизненного цикла;

· Процесс менеджмента инфраструктуры;

· Процесс менеджмента портфеля проектов;

· Процесс менеджмента людских ресурсов;

· Процесс менеджмента качества.

Процессы проекта

· Процессы менеджмента проекта

· процесс планирования проекта;

· процесс управления и оценки проекта.

· Процессы поддержки проекта

· процесс менеджмента решений;

· процесс менеджмента рисков;

· процесс менеджмента конфигурации;

· процесс менеджмента информации;

· процесс измерений.

Технические процессы

· Определение требований правообладателей

· Анализ системных требований

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

· Процесс реализации

· Процесс комплексирования системы

· Процесс квалификационного тестирования системы

· Процесс инсталляции программных средств

· Процесс поддержки приемки программных средств

· Процесс функционирования программных средств

· Процесс сопровождения программных средств

· Процесс изъятия из обращения программных средств

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

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

· Процесс проектирования архитектуры программных средств;

· Процесс детального проектирования программных средств;

· Процесс конструирования программных средств;

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

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

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

· Процесс менеджмента документации программных средств;

· Процесс менеджмента конфигурации программных средств;

· Процесс обеспечения гарантии качества программных средств;

· Процесс верификации программных средств;

· Процесс валидации программных средств;

· Процесс ревизии программных средств;

· Процесс аудита программных средств;

· Процесс решения проблем в программных средствах.

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

· Процесс проектирования доменов;

· Процесс менеджмента повторного применения активов;

· Процесс менеджмента повторного применения программ.

Настоящий стандарт является результатом гармонизации четырех исходных документов (рис.1), таких как ИСО/МЭК 12207-95, ИСО/МЭК 12207-2010, ИСО/МЭК 15288-2002 и ИСО/МЭК 15288-2007.

Несмотря на то, что в ИСО/МЭК 12207:1995 рассматривались процессы жизненного цикла программных средств в системном контексте, было очевидно, что аналогичный стандарт был необходим также и в системной области. ИСО/МЭК 15288, опубликованный в ноябре 2002 года, полностью удовлетворил эту потребность. Разработчики стандарта извлекли пользу из опыта, полученного при разработке дополненного стандарта ИСО/МЭК 12207 и понимания потребностей, выраженных в ИСО/МЭК 15504. Таким образом, процессы в ИСО/МЭК 15288 излагались в терминах целей и выходов с описанием видов деятельности, необходимых для достижения этих выходов.

Развернутая по стадиям разработка изменений к ИСО/МЭК 12207 вместе с ИСО/МЭК 15288 и изначально иная ориентация ИСО/МЭК 12207 привели к некоторым затруднениям в применении дополненного стандарта ИСО/МЭК 12207 так же, как и в совместном применении стандартов жизненного цикла систем и программных средств. Гармонизация проекта в рамках Подкомитета 7 "Системная и программная инженерия" Совместного технического комитета N 1 ИСО/МЭК - СТК 1 "Информационные технологии" (ISO/IEC JTC 1/SC 7) являлась первым большим шагом к объединенному комплекту стандартов, описывающих жизненный цикл систем и программных средств, а ее суть заключалась в параллельно проведенном и тщательно контролируемом пересмотре ИСО/МЭК 12207, ИСО/МЭК 15288 и разработке технического отчета ИСО/МЭК 24748, представляющего собой руководящие указания для обоих международных стандартов.

Сравнительный анализ стандартов ISO/IEC 12207-95 и ISO/IEC 12207-2008

Сравнивая, эти два стандарта видно, что стандарт ISO/IEC 12207-2008 наиболее подробный, точный. Если в стандарте 1995 года описаны только применение и процессы ЖЦ программных средств, то в стандарте 2008 года уже описаны не только программные средства, но и процессы ЖЦ систем. Если раньше какие-то процессы были отдельными пунктами в старом стандарте, то сейчас это всего лишь подпроцессы процессов, которые так же включают в себя и новые пункты.

Отношения между конструкциями процессов в исходных документах показаны на рисунке 1.

Рисунок 1

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

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

2) Обеспечивает максимальную степень адаптивности – множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами ИС. Адаптация сводится к исключению процессов, видов деятельности и задач, которые не применяются в конкретном проекте.

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

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

5) Ценность стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.д. , дающие всесторонний охват проектных решений.

6) Хотя стандарт не предписывает использовать конкретную модель ЖЦ или метод разработки, он определяет, что стороны участники проекта несут ответственность за следующие моменты:

выбор модели ЖЦ для разрабатываемого проекта;

адаптация процессов и задач стандарта к выбранной модели;

выбор и применение методов разработки ПО;

выполнение действий и задач, подходящих для данного проекта ПО.

Стандарты комплекса гост 34.

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

Объекты стандартизации : автоматизированные системы различных видов и все виды их компонентов.

Стандарты ГОСТа предусматривают стадии и этапы выполнения работ по созданию автоматизированной системы, но не предусматривают в явном виде сквозных процессов, которые имеют место при реализации ЖЦ.

Согласно ГОСТу разработка автоматизированной системы разбивается на следующие этапы и стадии:

1 этап формирования требований к АС :

Стадия а: обследование объекта и обоснование необходимости разработки автоматизированной системы;

Стадия б: формирование требований заказчика к автоматизированной системе;

Стадия в: разработка отчета о проделанной работе и подготовка заявки на разработку технического задания.

2 этап разработки концепции :

а: изучение объекта;

б: проведение необходимых НИР;

в: разработка вариантов концепции АС, удовлетворяющей требованиям заказчика;

г: разработка отчета о проделанной работе.

3 этап разработки и утверждения технического задания на создание АС .

4 этап разработки эскизного проекта АС :

а: разработка предварительных проектных решений по всей системе в целом и по её отдельным компонентам;

б: разработка документации.

5 этап разработки технического проекта :

а: разработка проектных решений по всей системе и по её частям;

б: разработка документации на автоматизированную систему и подсистемы, входящие в её состав;

в: разработка и оформление документации на поставку изделий для комплектования АС или разработка и оформление технических требований на разработку этих изделий.

6 этап разработки технической документации :

а: разработка рабочей документации на систему её части;

б: разработка или адаптация ПО.

7 этап ввода разработанной системы в действие :

а: подготовка объекта автоматизации к внедрению АС;

б: подготовка персонала;

в: комплектации АС программными и техническими средствами;

г: монтажные работы;

д: пуско-наладочные работы;

е: предварительные испытания;

ж: опытная эксплуатация;

з: приемочные испытания.

8 этап сопровождения :

а: выполнение работ в соответствие с гарантийными обязательствами;

б: послегарантийное обслуживание.

В России в настоящее время используется стандарт ГОСТ Р ИСО/МЭК 12207-2010 Процессы жизненного цикла программных средств(ISO/IEC 12207:2008 System and software engineering - Software life cycle processes)

ISO/IEC 12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Общая структура – см. самостоятельно!

Особенности:

Стандарт ISO состоит из очень крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

- «Динамический» характер стандарта определяется способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовывать любую модель ЖЦ.

Степень адаптивности: максимальная. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте.

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

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

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

МОДЕЛЬ SEI SW-CMM

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов.

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

СММ – стандарт де-факто.

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

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

СММ определяет 5 уровней технологической зрелости компании:

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

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

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

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

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

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

Базовая линия (baseline) по ГОСТ Р ИСО/МЭК 12207-2010

или, которые были официально рассмотрены и с тем, чтобы впоследствии служить основой для дальнейшего, и которые могут быть изменены только посредством официальных и контролируемых изменения [из п. 4.6 ГОСТ Р ИСО/МЭК 12207-2010]

Валидация (validation) по ГОСТ Р ИСО/МЭК 12207-2010

Подтверждение (на основе представления объективных свидетельств) того, что, предназначенные для конкретного или применения, выполнены. Примечание - Валидация в контексте представляет собой совокупность действий, гарантирующих и обеспечивающих уверенность в том, что способна реализовать свое предназначение, текущие и перспективные [из п. 4.54 ГОСТ Р ИСО/МЭК 12207-2010]

Верификация (verification) по ГОСТ Р ИСО/МЭК 12207-2010

Подтверждение (на основе представления объективных свидетельств) того, что заданные полностью выполнены. Примечание - Верификация в контексте представляет собой совокупность действий по сравнению полученного результата жизненного цикла с требуемыми характеристиками для этого результата. Результатами жизненного цикла могут являться (но не ограничиваться ими) заданные требования, описание и непосредственно [из п. 4.55 ГОСТ Р ИСО/МЭК 12207-2010]

Гарантия качества (quality assurance) по ГОСТ Р ИСО/МЭК 12207-2010

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

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

[из п. 4.34 ГОСТ Р ИСО/МЭК 12207-2010]