Определение информационной системы согласно стандарту iso 12207
ГОСТ Р ИСО/МЭК 12207-99
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ
Information technology. Software life cycle processes
Дата введения 2000-07-01
1 РАЗРАБОТАН Всероссийским научно-исследовательским институтом стандартизации (ВНИИстандарт) Госстандарта России
ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационная технология»
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 23 декабря 1999 г. N 675-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 12207-95 «Информационная технология. Процессы жизненного цикла программных средств»
Введение
Программные средства являются неотъемлемыми частями информационных технологий и традиционных систем, таких как транспортные, военные, здравоохранения и финансовые. При этом подразумевается усиление роли стандартов, процедур, методов, средств (инструментария) и внешних условий для разработки и сопровождения программных средств (программного обеспечения). Подобная многоплановость подходов создает значительные трудности при управлении программными средствами и в технологиях программирования, особенно при интеграции продуктов и услуг. Требуется определенное упорядочение вопросов создания программных средств при переходе от подобной многоплановости к общей структуре, которая может быть использована профессионалами для «разговора на одном языке» при создании и управлении программными средствами. Настоящий стандарт устанавливает такую общую структуру.
Данная структура охватывает жизненный цикл программных средств от концепции замыслов через определение и объединение процессов для заказа и поставки программных продуктов и услуг. Кроме того, данная структура предназначена для контроля и модернизации данных процессов.
Процессы, определенные в настоящем стандарте, образуют множество общего назначения. Конкретная организация, в зависимости от своих целей, может выбрать соответствующее подмножество процессов для выполнения своих конкретных задач. Поэтому настоящий стандарт следует адаптировать для конкретной организации, проекта или приложения. Настоящий стандарт предназначен для использования как в случае отдельно поставляемых программных средств, так и для программных средств, встраиваемых или интегрируемых в общую систему.
1 Область применения
Настоящий стандарт устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Настоящий стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств.
Настоящий стандарт также определяет процесс, который может быть использован при определении, контроле и модернизации процессов жизненного цикла программных средств.
1.2 Область распространения
Настоящий стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг; а также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств как в самой организации, так и вне ее. Стандарт содержит также те аспекты описания системы, которые необходимы для обеспечения понимания сути программных продуктов и услуг.
Стандарт также применяется при двусторонних отношениях сторон и может в равной степени применяться, если обе стороны принадлежат к одной и той же организации. Диапазон применения может простираться от неформального соглашения о сотрудничестве до официально заключаемого контракта (договора). Стандарт может использоваться одной из сторон для самоконтроля.
Стандарт не распространяется на готовые программные продукты, если они не входят в поставляемый продукт.
Стандарт предназначен для: заказчиков систем, программных продуктов и услуг; поставщиков; разработчиков; операторов; персонала сопровождения; администраторов проектов; администраторов, отвечающих за качество, и пользователей программных продуктов.
1.3 Адаптация настоящего стандарта
Настоящий стандарт определяет набор процессов, работ и задач, предназначенных для адаптации к условиям конкретных программных проектов. Процесс адаптации заключается в исключении неприменяемых в условиях конкретного проекта процессов, работ и задач.
Соответствие настоящему стандарту определяется как выполнение всех процессов, работ и задач, выбранных из настоящего стандарта в процессе адаптации (приложение А), для конкретного программного проекта. Выполнение процесса или работы считается завершенным, когда выполнены все требуемые для них задачи в соответствии с предварительно установленными в договоре критериями и требованиями.
Любая организация (например, национальная, промышленная ассоциация, компания), применяющая настоящий стандарт в качестве условия обеспечения торговых сделок, обязана определить и опубликовать минимальный набор требуемых процессов, работ и задач, который обеспечивает проверку соответствия поставщика настоящему стандарту.
Настоящий стандарт описывает архитектуру процессов жизненного цикла программных средств, но не определяет детали реализации или выполнения работ и задач, входящих в данные процессы.
Стандарт не предназначен для определения наименований, форматов или подробного содержания выпускаемой документации. Стандарт может требовать разработки документов одного класса или типа, например различных планов, но не предусматривает, чтобы такие документы разрабатывались или комплектовались раздельно или совместно. Решение этих вопросов оставлено на усмотрение пользователей настоящего стандарта.
Стандарт не предопределяет конкретной модели жизненного цикла или метода разработки программного средства. Пользователи, применяющие настоящий стандарт, должны сами выбирать модель жизненного цикла применительно к своему программному проекту и распределять процессы, работы и задачи, выбранные из настоящего стандарта, на данной модели; выбирать и применять методы разработки программных средств и выполнять работы и задачи, соответствующие конкретному программному проекту.
Стандарт не имеет противоречий с существующими в организациях стратегиями, стандартами или процедурами. Однако любые возникающие конфликтные ситуации должны быть разрешены, а любые противоречащие условия и ситуации должны быть упомянуты в примечаниях как исключения при применении настоящего стандарта.
В тексте настоящего стандарта приведен ряд перечней задач, однако ни один из перечней нельзя считать исчерпывающим, и они приведены в качестве примеров.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ИСО/МЭК 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): Определение границ и условий, при которых будут осуществляться рабочие взаимоотношения.
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): Набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты.
3.18 квалификация (qualification): Процесс демонстрации возможности объекта выполнять установленные требования (См. 2.13 ИСО 8402).
3.19 квалификационное требование (qualification requirement): Набор критериев или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт на соответствие установленным требованиям и готовность к использованию в заданных условиях эксплуатации.
3.20 квалификационное испытание (qualification testing): Испытание (тестирование), проводимое разработчиком, при необходимости санкционированное заказчиком, для демонстрации того, что программный продукт удовлетворяет установленным требованиям и готов к использованию в заданных условиях эксплуатации.
3.21 обеспечение качества (quality assurance): Все запланированные и систематически выполняемые в рамках системы качества работы; при необходимости объективные доказательства, обеспечивающие уверенность в том, что объект будет полностью соответствовать установленным требованиям качества.
1 Существуют как внешние, так и внутренние цели обеспечения качества:
2 Некоторые виды работ по управлению качеством и обеспечению качества взаимосвязаны.
3 Если требования к качеству не полностью отражают потребности пользователя, то обеспечение качества может не создать достаточной уверенности. (См. 3.5 ИСО 8402).
3.22 выпуск (release): Конкретная версия элемента конфигурации, которая доступна для реализации конкретной цели (например, тестируемый выпуск).
3.23 заявка на подряд (request for proposal [tender]): Документ, используемый заказчиком в качестве средства для объявления о своих намерениях выступить в качестве потенциального покупателя конкретной системы, программного продукта или программной услуги.
3.24 снятие с эксплуатации (retirement): Прекращение активной поддержки действующей системы со стороны эксплуатирующей или сопровождающей организации, частичная или полная замена ее новой системой или ввод в действие модернизированной системы.
Модели жизненного цикла для разработки программных систем
За десятилетия опыта построения программных систем был наработан ряд типичных схем последовательности выполнения работ при проектировании и разработки ПС. Такие схемы получили название моделей ЖЦ.
Исторически в эту схему работ включают:
Основное назначение моделей ЖЦ состоит в следующем:
2.1. Процессы ЖЦ стандарта ISO/IEC 12207
На рис. 2.1. представлены процессы, связанные непосредственно с разработкой ПС. К категории основных процессов относятся также «первичные» процессы, определяющие порядок подготовки договора на разработку ПС, мониторинг деятельности поставщиков ПС заказчику.
Являясь стандартом высокого уровня, он не задает детали того, как надо выполнять действия или задачи, составляющие процессы. Он также не задает требований к формату и содержанию документов, выпускаемых на разных процессах.
Процессы, действия и задачи приведены в стандарте в наиболее общей естественной последовательности. Это не значит, что в такой же последовательности они должны быть применены в конкретной модели ЖЦ ПС. В зависимости от проекта процессы, действия и задачи стандарта выбираются, упорядочиваются и включаются в модель ЖЦ. При применении они могут перекрывать, прерывать друг друга, выполняться итерационно или рекурсивно. Это определяет «динамический» характер стандарта и позволяет реализовать с его помощью произвольную модель ЖЦ ПС. Поэтому организации, которая намерена применить этот стандарт в своей работе, понадобятся дополнительные стандарты или процедуры, определяющие разные детали по применению выбранных элементов ЖЦ. Отметим, что комитет ISO выпускает руководства и процедуры, дополняющие стандарт 12207.
Кроме этого, стандарт ISO /IEC 12207 предоставляет основу для принятия ряда других связанных с ним стандартов, таких как
Процессы, включенные в модель ЖЦ, предназначены для реализации стандартных задач процессов ЖЦ и могут привлекать другие процессы для реализации специализированных задач системы (например, защиты данных). Интерфейсы (входы и выходы) любых двух процессов ЖЦ должны быть минимальными и каждый из них должен удовлетворять следующим правилам:
Иными словами, если задача требуется более чем одному процессу, то она может стать процессом, используемым однократно или многократно на протяжении жизни конкретной системы. Каждый процесс должен иметь внутреннюю структуру, установленную в соответствии с тем, что он должен выполнять.
Процессы модели ЖЦ ориентированы на разработчика системы. Он может выполнять один или несколько процессов и процесс может быть выполнен одним или несколькими разработчиками. При этом один из них является ответственным за один процесс или за все процессы модели, даже если отдельные работы выполняет другой разработчик.
Создаваемая модель ЖЦ увязывается с конкретными методиками разработки систем и соответствующими стандартами в области программной инженерии либо разрабатываются самостоятельно для проекта с учетом его возможностей и особенностей. Иными словами, каждый процесс ЖЦ подкрепляется выбранными для реализации задач ПС средствами, методами программирования и методикой их применения и выполнения.
Важную роль при формировании модели ЖЦ имеют организационные аспекты:
Внедрение модели ЖЦ в практическую деятельность по созданию программного продукта позволяет упорядочить взаимоотношения между субъектами процесса разработки ПС и учитывать динамику модификации требований к проекту и к системе.
В соответствии со стандартом ISO /IEC 12207 были выявлены задачи тестирования и распределены по процессам ЖЦ ПС. В результате был получен единый непрерывный процесс тестирования разных ПС, задачами которого являются подготовка, проведение и оценивание результатов тестирования, которые распределились по 20 действиям (шагам) процесса разработки [2.7, 2.9]. Данный подход к тщательному тестированию ПС целесообразно применять, например, для систем реального времени.
На шаге подготовки осуществляется анализ рабочих продуктов процесса разработки ПС (входных для данного шагу процесса тестирования) для определения целей, объектов, сценариев и ресурсов тестирования, адекватных шагу тестирования. Результаты выполнения шагов подготовки тестирования должны фиксироваться в планах тестирования.
На шаге выполнения осуществляется фиксация результатов выполнения тестов, их сравнение с ожидаемыми результатами, определение текущего состояния рабочего продукта ПС и принятие решения о достаточности тестирования.
Каждый шаг процесса разработки состоит из набора решаемых задач, распределение по процессам и подроцессам ЖЦ (рис. 2.3).
Шаги процесса и отдельные задачи могут выполняться циклически для разных объектов ПС при их тестировании.
Определение информационной системы согласно стандарту iso 12207
ГОСТ Р ИСО/МЭК 15288-2005
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Процессы жизненного цикла систем
Information technology.
System engineering. System life cycle processes
Дата введения 2007-01-01
Сведения о стандарте
1 ПОДГОТОВЛЕН Подкомитетом «Системная и программная инженерия» Технического комитета по стандартизации ТК 22 «Информационные технологии» (с участием 3 ЦНИИ Минобороны России, Российской академии ракетных и артиллерийских наук, Международного центра по информатике и электронике, МИРЭА, ЦНИИ РТК) на основе собственного аутентичного перевода стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 декабря 2005 г. N 476-ст
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5)
1 Область применения
1.1 Назначение
В настоящем стандарте представлены также процессы, которые поддерживают определение, контроль и совершенствование процессов жизненного цикла внутри организации или в рамках какого-либо проекта. Организации и проекты могут применять эти процессы при приобретении и поставке систем.
Настоящий стандарт распространяется на системы, которые созданы человеком и состоят из одного или нескольких следующих элементов: технические средства, программные средства, люди, процессы (например, процесс оценки), процедуры (например, инструкции оператора), основные средства и природные ресурсы (например, вода, объекты живой природы, минералы).
1.2 Область распространения
Настоящий стандарт применим к полному жизненному циклу системы, включая замысел, разработку, производство, эксплуатацию и снятие с эксплуатации, а также приобретение и поставку систем, осуществляемых внутри или вне организации. Процессы жизненного цикла, представленные в стандарте, могут применяться однократно, многократно и рекурсивно по отношению к системе и ее элементам.
Существует широкий круг систем, отличающихся назначением, областью применения, сложностью, размером, новизной, адаптируемостью, количественными характеристиками, местом расположения, временем жизни и эволюции. В стандарте описываются процессы, составляющие жизненный цикл любой искусственной системы, создаваемой людьми. Он применим для систем единичного и массового производства и систем, адаптируемых по требованиям заказчика.
Настоящий стандарт может использоваться организациями, выступающими в роли как поставщиков, так и приобретающих сторон. Он может применяться одной из сторон в индивидуальном порядке или в порядке, согласованном несколькими участниками. Участвующие стороны могут принадлежать одной организации или различным организациям, а результат согласования их действий может варьироваться от неформального соглашения вплоть до официального контракта.
Процессы, представленные в настоящем стандарте, могут быть использованы как основа для формирования деловой среды, например методов, технических приемов и способов, инструментальных средств и обученного персонала. Стандарт определяет эталонную модель процесса, охарактеризованную в терминах целей и результатов, являющихся итогом успешной реализации процесса. Таким образом, настоящий стандарт может применяться в качестве эталонной модели для поддержки оценки процесса, как это определено в [17].
1.3 Ограничения
В настоящем стандарте не детализируются процессы жизненного цикла в терминах методов и процедур, необходимых для удовлетворения требований и достижения результатов процесса.
Стандарт не устанавливает требований к документации в части ее наименований, форматов, явно определенного содержания и среды для записи.
Настоящий стандарт не должен противоречить политике, процедурам и нормам любой организации, национальным законам или регулирующим документам. Каждое такое противоречие должно быть разрешено до начала использования настоящего стандарта.
2 Соответствие
2.1 Предполагаемое использование
В разделах 5, 6 и в приложении А настоящего стандарта изложены требования для определенного количества процессов, приемлемых для использования в течение всего жизненного цикла системы.
Допускается, что в отдельных проектах или в некоторых организациях может не возникать потребность использовать все процессы, приведенные в настоящем стандарте.
В таком случае применение настоящего стандарта сводится к выбору процессов, подходящих для организации или проекта. Существует два способа заявить о соответствии реализованных процессов положениям настоящего стандарта, причем любое заявление о соответствии должно быть оформлено в одной из двух приведенных ниже форм.
2.2 Полное соответствие
В заявлении о полном соответствии перечисляют процессы, которые удовлетворяют требованиям настоящего стандарта. Для доказательства полного соответствия процессов положениям настоящего стандарта демонстрируют результаты процессов.
2.3 Адаптированное соответствие
В случае использования стандарта как основы для установления какой-либо совокупности процессов, которые не могут быть квалифицированы как полностью соответствующие, разделы стандарта выбирают или модифицируют согласно процессу адаптации, приведенному в приложении А. Формируется адаптированный текст, в отношении которого заявляют о соответствии в результате адаптации. Соответствие в результате адаптации достигается путем демонстрации того, что требования к адаптированным процессам были удовлетворены. В качестве доказательства приводят результаты процессов.
3 Нормативные ссылки
Приведенный ниже нормативный документ содержит положения, которые посредством ссылок в тексте устанавливают положения настоящего стандарта. Для представленных в библиографии датированных ссылок результаты последующих изменений или пересмотров любых публикаций ссылочных документов не использовались. Однако отдельные соглашения, основанные на настоящем стандарте, стимулируют изучение и возможности применения более поздних изданий приведенного ниже нормативного документа. Для недатированных ссылок использованы самые поздние издания соответствующих нормативных документов. Члены ИСО и МЭК поддерживают в актуальном состоянии регистры действующих международных стандартов.
Изменение N 1-2002 к ИСО/МЭК 12207:1995 Информационная технология. Процессы жизненного цикла программных средств*.
* Взаимосвязь между ИСО/МЭК 15288 и Изменением N 1 к ИСО/МЭК 12207 приведена в приложении С.
4 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
4.1 приобретающая сторона (acquirer): Правообладатель, который приобретает или получает продукт или услугу от поставщика.
4.2 деятельность (activity): Совокупность действий, в результате которых расходуются время и ресурсы и выполнение которых необходимо для достижения или содействия достижению одного или нескольких результатов.
4.3 соглашение (agreement): Взаимное признание сроков и условий, в соответствии с которыми осуществляются рабочие отношения.
4.4 базовая линия (baseline): Спецификация или продукт, которые были официально рассмотрены и согласованы, чтобы впоследствии служить основой для дальнейшего развития, и которые могут быть изменены только посредством официальных и контролируемых процедур изменения.
4.5 обеспечивающая система (enabling system): Система, которая служит дополнением к рассматриваемой системе на протяжении стадий ее жизненного цикла, но необязательно вносит непосредственный вклад в ее функционирование.
1 Например, когда рассматриваемая система вступает в стадию производства, требуется обеспечивающая производственная система.
2 Каждая обеспечивающая система имеет свой собственный жизненный цикл. Настоящий стандарт может применяться для любой обеспечивающей системы, если она представляется как рассматриваемая система.
4.6 предприятие (enterprise): Часть организации, отвечающая за приобретение и поставку продукции и (или) услуг в соответствии с соглашениями.
4.7 основные средства (facility): Физические средства или оборудование, способствующие выполнению действий (например, здания, инструменты, принадлежности).
4.8 модель жизненного цикла (life cycle model): Структурная основа процессов и действий, относящихся к жизненному циклу, которая также служит в качестве общей ссылки для установления связей и взаимопонимания сторон.
4.9 оператор (operator): Лицо или организация, которые вносят вклад в реализацию функциональных возможностей системы и применяют знания, умение и процедуры при выполнении определенной функции.
1 Роль оператора и роль пользователя могут выполняться одновременно или последовательно одним и тем же человеком или организацией.
2 Некоторые операторы в сочетании с их знаниями, умением и выполняемыми процедурами могут рассматриваться как элемент системы.
4.10 организация (organization): Группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений [3].
4.11 процесс (process): Совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы [3].
4.12 проект (project): Попытка действий с определенными начальной и конечной датами, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями.
1 Адаптация определения, приведенного в [3] и [20].
2 Проект может рассматриваться как уникальный процесс, включающий в себя координируемые и контролируемые действия, и может быть комбинацией действий из процессов проекта и технических процессов, определенных в настоящем стандарте.
4.13 ресурс (resource): Активы (организации), которые используются или потребляются в ходе выполнения процесса.
1 Ресурсы могут включать в себя такие разнообразные объекты, как персонал, оборудование, основные средства, инструменты, а также коммунальные услуги: энергию, воду, топливо и инфраструктуру средств связи.
2 Ресурсы могут быть многократно используемыми, возобновляемыми или расходуемыми.
4.14 стадия (stage): Период в пределах жизненного цикла системы, относящийся к состоянию системного описания или непосредственно к самой системе.
1 Стадии относятся к периодам значительного продвижения системы и достижения запланированных сроков на протяжении жизненного цикла.
2 Стадии могут перекрывать друг друга.
4.15 правообладатель (stakeholder): Сторона, имеющая право, долю или претензии на систему или на владение ее характеристиками, удовлетворяющими потребности и ожидания этой стороны.
4.16 поставщик (supplier): Организация или лицо, которые вступают в соглашение с приобретающей стороной на поставку продукта или услуги.
4.17 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей.
1 Система может рассматриваться как продукт или как совокупность услуг, которые она обеспечивает.
2 На практике интерпретация данного термина зачастую уточняется с помощью ассоциативного существительного, например, система самолета. В некоторых случаях слово «система» может заменяться контекстным синонимом, например, самолет, хотя это может впоследствии затруднять восприятие системных принципов.