ГОСТ Р 56923-2016/ISO/IEC TR 24748-3:2011. Национальный стандарт Российской Федерации. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)
5.4 Применение к проектам
5.4.1 Обзор
Процессы жизненного цикла по ИСО/МЭК 12207 могут использоваться проектом по крайней мере в семи целях:
a) установить соглашения с организационными сущностями (объектами), внешними и внутренними к проекту, приобрести или поставлять продукцию или услуги (процессы соглашения);
b) гарантировать способность организации приобрести и поставлять продукцию или услуги через инициацию, поддержку и управление проектами (процессы организационного обеспечения проектов);
c) установить и разработать проектные планы, выполнять их, оценивать фактическое достижение и продвижение согласно планам и управлять проектом через выполнение (процессы проекта);
d) сотрудничать для удовлетворенности на одной или более стадиях жизненного цикла в достижении системных технических целей (технических процессов);
e) сотрудничать для удовлетворенности на одной или более стадиях жизненного цикла в достижении технических целей применительно к элементам программной системы (процессы реализации программных средств);
f) помогать с реализацией программных объектов как интегрирующей части для достижения цели, способствуя успеху и качеству программного проекта (процессы поддержки программных средств);
g) поддерживать способность организации к повторному использованию программных объектов с учетом границ проекта (процессы повторного применения программных средств).
Требование выполнения ИСО/МЭК 12207 не зависит от размера или сложности системы. Наряду с этим факторы, такие как, например, системные требования и замысел функционирования, затрагивают размер и сложность системы. Таким образом, выходные результаты и действия по ИСО/МЭК 12207 предназначены быть общими и применимыми к разработке любой программной системы из области назначения международного стандарта. На выполнение работ проекта могут воздействовать размеры и сложность системы, например, могут воздействовать выполняемые задачи для достижения результатов деятельности в процессе жизненного цикла системы или тип и форма рабочих продуктов процессов для их последующего применения.
5.4.2 Применение процессов соглашения на проект
5.4.2.1 Применение процесса приобретения
Процессы по ИСО/МЭК 12207 могут использоваться для достижения соглашения. Рисунок 17 иллюстрирует использование процессов соглашения в объединении с другими процессами жизненного цикла по ИСО/МЭК 12207. Соглашения могут быть между организациями, между проектами, а для реализации рабочих усилий - в пределах проекта. Такие случаи проиллюстрированы в 4.6.
Рисунок 17 - Применение процесса к форме
формального соглашения
Модель на рисунке 17 не предназначена для отражения всех возможных потоков процесса для достижения соглашения. Модель призвана показать, что у всех процессов ИСО/МЭК 12207 может быть роль в формировании соглашений, особенно формальных соглашений, которые могут быть обязательными по закону. Намного меньше формальностей, нежели в предложенной на рисунке 17 модели, ожидается, когда в пределах того же самого проекта соглашение использует отношения между людьми в подпроектах. Следующие положения на рисунке 17 в качестве приемлемых описывают процессный поток модели и ограничения.
Процессы по ИСО/МЭК 12207 могут быть начаты с запроса на приобретение, такого как, например, формальный запрос на предложение или запрос в виде неформальной внутренней директивы для определенной работы, подлежащей выполнению. Это могло бы стать причиной формирования проекта для нового инженерного усилия или усилий в пределах проекта, если это связано с работой по проекту.
Рассмотрение и подготовка ответа на запрос на предложение могут быть поручены соответствующей команде или отдельному специалисту в зависимости от размера и сложности проекта. Для меньших проектов возможно назначение отдельного специалиста в качестве ответственного за подготовку ответа, выполнение работы и создание необходимых рабочих продуктов, которые в итоге будут поставлены.
Назначенная команда или отдельный специалист должны выполнить действия процесса поставки, соответствующего заключенному соглашению. Чтобы понять требуемые возможности для выполнения запрашиваемой работы, сначала команда или отдельный специалист должны сделать необходимое планирование на область стратегии для принятия усилий по подготовке к ответу. План должен включать перечень контрольных точек и критериев принятия решения для ответа с учетом целей организации или проекта, а также применимых инвестиционных критериев решений.
Чтобы решить, ответить ли на запрос на предложение или определить специфические особенности ответа, могут быть запланированы и выполнены технические процессы применительно к уровню структуры системы, соответствующей природе и размеру программной системы и стадии жизненного цикла программных средств. Кроме того, должны быть определены объемы работ, стоимость системы и степень удовлетворения требований в пределах данных ограничений. Применение технических процессов должно быть осуществлено в соответствии с планом, оценено и находиться под контролем с использованием соответствующих процессов проекта. Процессы организационного обеспечения проекта должны быть реализованы до такой степени, которая необходима для поддержки технических процессов, контроля выходных результатов и принятия соответствующего ответа.
При определении общих оснований для приобретающей стороны и поставщика в понимании требований проекта согласно уровню формальности следует использовать следующий перечень ожиданий:
a) требования к системе и услуге;
b) ожидаемые поставки;
c) реализация и прохождение контрольных точек;
d) условия приемки, исключений в обращении с процедурами; условия, требующие пересмотра соглашения; условия, требуемые для законного завершения соглашения; условия для наложения штрафов или выплаты премий и сроков оплаты;
e) права и ограничения, связанные с техническими данными, интеллектуальной собственностью, авторскими правами и патентами.
Переговоры можно считать завершенными, когда сроки соглашения являются приемлемыми и для приобретающей стороны, и для поставщика.
Примечание - IEEE 1062-1998 обеспечивает дополнительное руководство относительно процесса приобретения, включая выбор поставщика.
5.4.2.2 Применение процесса поставки
После того, как соглашение установлено, проект сформирован, чтобы удовлетворить требованиям соглашения и выполнить работу, соответствующие процессы соглашения, проекта и организационного обеспечения проекта по ИСО/МЭК 12207 используются в объединении с техническими процессами. Модель на рисунке 18 иллюстрирует пример отношений процессов, используемых в пределах проекта для того, чтобы удовлетворить требованиям соглашения.
Рисунок 18 - Применение процесса
для удовлетворения соглашения
Этот пример не предназначен для отражения всех возможных потоков процесса и всех возможных проектов. Это, однако, обеспечивает подход, который можно рассмотреть в установлении потока процесса как соответствующего специфическому проекту. Для меньших проектов делаются те же самые процессы, но формализация, документация и уровень деятельности могут быть уменьшены по своим масштабам соответственно экономике проекта.
Проектная работа не должна предприниматься до получения востребованных ресурсов, таких как фонды, участники команды, оборудование и услуги для удовлетворения проектных соглашения и планов.
Проект существует для удовлетворения соглашения с ожидаемым качеством и обеспечением необходимых поставок. Проект выполняется с помощью процесса планирования проекта, который может содержать обновление планов, используемых для формирования ответа на запрос приобретения или на применяемые планы из предыдущей стадии жизненного цикла. Соответствующим командам поручается работа с ожидаемым соответствием запланированным требованиям. Эти команды делают работу, связанную с применением технических процессов для получения требуемых рабочих продуктов. Должны использоваться процессы оценки и контроля проекта, процесс принятия решения, процесс управления риском, процессы управления конфигурацией и информацией, чтобы контролировать, управлять и оценивать выходные результаты технических процессов с тем, чтобы быть в состоянии удерживать работу в пределах приемлемой стоимости, сроков и рисков для удовлетворения требованиям эксплуатации системы. Процессы организационного обеспечения проекта и процессы проекта реализуются, чтобы оказать поддержку проекту и рассматривать проект как приемлемый.
Действия процессов, показанные на рисунке 18, можно рассматривать как полные, когда соглашение полностью удовлетворено поставкой необходимых продуктов и услуг.
Фактическая понятая форма рассматриваемой системы, составной системы или системного элемента может варьироваться от концептуальной модели до предоставляемой продукции. Понятая форма поставки является обычной функцией выходных критериев применимой стадии жизненного цикла системы и требований соглашения.
5.4.3 Применение технических процессов к проекту
5.4.3.1 Общее
Рисунок 19 иллюстрирует модель для применения технических процессов по ИСО/МЭК 12207. Эта модель включает только технические процессы, которые прежде всего используются для инженерии рассматриваемой системы. Три из технических процессов не показаны на рисунке 19:
- процесс функционирования программного средства;
- процесс сопровождения программного средства;
- процесс прекращения применения программного средства.
Рисунок 19 - Применение технических процессов к инженерии
рассматриваемой системы
Указанные три процесса должны использоваться соответствующим образом для обеспечения входов процессу определения требований правообладателей. Требования могут быть предоставлены в форме требований приобретающей стороны, таких как, например, удобство использования, поддерживаемость и способность к выведению из эксплуатации или в форме других требований заинтересованных сторон, таких, например, которые касаются обеспечивающих систем для оказания соответствующих услуг. В последующих обсуждениях по модели технического процесса для инженерии системы процесс применения используется в приложении именно к системе, является ли это рассматриваемой системой высокого уровня или одной из составных систем или системным элементом в структуре системы. Если применение процесса будет относиться только к рассматриваемой системе или системному элементу в структуре системы, то будет использоваться специальная терминология.
Несмотря на то, что к любой системе нужно обращаться, охватывая ее полный жизненный цикл, достаточно характерным для проектов является охват лишь части этого жизненного цикла. Например, один проект может определить систему, в то время, как другой проект превращает проектирование в реализацию системы. Помня об этом, применение технических процессов к проекту охвачено в двух пунктах этого стандарта. 5.4.3.2 обсуждает определение системы, а 5.4.3.3 обращается к реализации системы.
Процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы используются, чтобы спроектировать решение для каждой составной системы из структуры системы. Для поиска желательного решения проекта применение этих процессов может быть итеративным (см. 4.4.4.3).
Процесс реализации, процесс комплексирования системы, процесс квалификационного тестирования системы, процесс инсталляции программных средств и процесс поддержки приемки программных средств используются, чтобы принять решение для проектирования архитектуры каждой составной системы в структуре системы. Аналогичным образом применение этих процессов может быть итеративным.
Процесс определения требований правообладателей, процесс анализа требований и процесс проектирования архитектуры применяются рекурсивно к рассматриваемой системе и ее подсистемам сверху вниз, пока системный элемент не окажется реализованным (например построенный, купленный, повторно используемый) с использованием процесса реализации. Это случается, когда не требуется разрабатывать никакие дальнейшие системы. После того, как все элементы структуры системы реализованы, рекурсивно начинают выполняться процесс комплексирования системы, процесс квалификационного тестирования системы, процесс инсталляции программных средств и процесс поддержки приемки программных средств на каждой системе снизу вверх, включая высший уровень рассматриваемой системы.
Примечание - См. 5.4.4 для применения процессов реализации программного средства к проекту.
Каждый процесс этой модели описан ниже. Дополнительные примечания, призванные помочь использованию этих процессов, находятся в приложении A.
5.4.3.2 Соответствующие технические процессы для определения системы
5.4.3.2.1 Общее
Чтобы создать проектные решения от высшего уровня рассматриваемой системы вниз вплоть до самого низкого уровня элемента системной структуры, должны использоваться процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы. Процессы для реализации системы изложены в 5.4.3.3.
5.4.3.2.2 Процесс определения требований правообладателей
Процесс определения требований правообладателей может использоваться для идентификации, сбора и соответствующего определения требований заинтересованных сторон. Приобретающая сторона и другие заинтересованные стороны вместе формируют множество заинтересованных сторон, связанных с инженерией системы. Приобретающая сторона обеспечивает начальный набор требований для каждой системы в структуре системы. Другие заинтересованные стороны обычно обеспечивают дополнительные требования, которые могут влиять на проектные решения. Примеры даны в перечне ниже, это:
a) интерфейсы с соответствующими обеспечивающими системами или интерфейсы с другими системами в намеченной эксплуатационной окружающей среде;
b) необходимость учета критических факторов, таких как безопасность, производительность, надежность, пригодность, применимость и сопровождаемость;
c) потребности, мастерство (навыки), компетентности и рабочая окружающая среда оператора и пользователя.
Получающееся множество требований заинтересованных сторон представляет собой набор требований, помещаемых в инженерию системы. Эти требования заинтересованной стороны включают в себя функции, подлежащие выполнению, требования к тому, насколько хорошо они должны быть выполнены, требования к окружающей среде, в которой они должны быть выполнены, любые необходимые характеристики системы и любые услуги, связанные с обеспечивающими системами. Должны быть исследованы все процессы по ИСО/МЭК 12207 с тем, чтобы гарантировать, что все возможные источники требований заинтересованных сторон учтены. В качестве примеров соответствующие действия каждого из процессов - процесса реализации, процесса комплексирования системы, процесса квалификационного тестирования системы, процесса инсталляции программных средств и процесса поддержки приемки программных средств - могут стать генераторами требований, которые иначе могут быть упущенными, что будет отрицательно влиять на создаваемую систему. Аналогичным образом должны также быть исследованы действия нетехнических процессов, чтобы увидеть, генерируют ли они требования заинтересованной стороны.
После того, как множество требований заинтересованных сторон определено, должна быть осуществлена их прослеживаемость сверху вниз и снизу вверх (или проверки на полноту и непротиворечивость) для гарантий того, что никакие требования не были упущены или добавлены без обоснований.
Это множество требований заинтересованных сторон должно быть использовано при выполнении процесса поддержки приемки программных средств после того, как система будет реализована или скомплексирована и верифицирована. Это важно принять во внимание для функционирования системы и ведения бизнеса при обращении к процессу определения требований правообладателей.
Примечание - ИСО/МЭК 29148 обеспечит руководство о реализации требований, связанных с процессами по ИСО/МЭК 12207.
5.4.3.2.3 Процесс анализа требований системы
Требования заинтересованной стороны не всегда декларируются в технических терминах и, возможно, не подготовлены к использованию для проектирования архитектуры. Чтобы выполнить анализ требований заинтересованных сторон и преобразовать их в ряд технических требований, пригодных к употреблению, может быть использован процесс анализа требований системы. Он включает идентификацию и анализ внешних требований интерфейса, функциональных требований, требований эксплуатации системы и ограничений, а также количественных и качественных мер, связанных с этими требованиями.
Получающееся множество технических требований должно быть проверено на прослеживаемость сверху вниз и снизу вверх, чтобы гарантировать, что никакое требование заинтересованной стороны не было упущено, у всех требований заинтересованных сторон есть порожденные технические требования и у всех технических требований есть изначальное требование заинтересованной стороны. Получающееся множество технических требований должно быть проверено для составных требований, содержащих множественные части, которые должны, в свою очередь, декомпозироваться в частные требования.
Примечание - ИСО/МЭК 29148 обеспечит руководство о реализации требований, связанных с процессами по ИСО/МЭК 12207.
При выполнении процессов, связанных с требованиями и проектированием, важно помнить, что любому требованию, которое вызывает разработку программной продукции, могут соответствовать существующие программные средства повторного применения, которые выполняют предъявляемые требования и отвечают установленным критериям. Чтобы удовлетворить часть или все требования, программные средства повторного применения могут использоваться в виде, как есть, или в модифицированном виде. Например, требование может быть удовлетворено путем использования существующего плана, спецификации или проекта. В приложении B предоставлено больше информации об использовании программных средств повторного применения.
5.4.3.2.4 Процесс проектирования архитектуры системы
5.4.3.2.4.1 Общее
Процесс проектирования архитектуры системы может быть использован для преобразования определенного набора технических требований в приемлемое решение архитектурного проекта, которое реализует технические требования для создаваемой системы. Это решение должно быть задокументировано в пакет технических данных или в базу данных, которая включает в себя множество спецификаций решения архитектурного проекта и другие описания конфигурации.
5.4.3.2.4.2 Логическое определение архитектуры
Первый шаг должен служить преобразованию множества технических требований в более детализированное множество таких технических требований, которые получаются с помощью ряда логических моделей архитектурного проектирования (см. ИСО/МЭК 12207 подпункт 6.4.3.3). Это может быть достигнуто выполнением задачи логического проектирования из процесса проектирования архитектуры системы путем разделения и формирования интерфейсов. Логические модели архитектурного проектирования могут проявляться в одной или нескольких формах, как это описано ниже:
a) функциональная блок-схема потока, отражающая декомпозицию главных функций в их подфункции;
b) диаграмма потока данных, которая декомпозирует функции, явно показывая данные, необходимые для каждой функции;
c) структура данных с соответствующими функциями и обработкой потоков, связанных с данными и ассоциируемых с назначенными техническими требованиями;
d) документы определения интерфейса с логическими, физическими и функциональными характеристиками системного элемента и системы в целом с обозначением внешних границ;
e) функциональная диаграмма, которая описывает входные источники и выходные результаты с помощью функций и включает соответствующий функциональный заказ по критериям входа и выхода;
f) диаграмма контроля, которая указывает контролируемые факторы функции и результирующего функционирования;
g) системные состояния и режимы;
h) временные графики, которые распределяют временные требования во множество функций;
i) таблица функциональных проявлений и последствий отказов, которая показывает возможные проявления и последствия отказов, таких, как невыполнение с учетом проектирования или неожиданного выполнения функции. Должны быть предложены возможные решения для каждого проявления отказа;
j) объекты, которые инкапсулируют разделение и схематичное представление технических требований и характеризуются услугами (поведениями, функциями и операциями) предоставленными инкапсулированными атрибутами (значениями, характеристиками и данными);
k) ряд алгоритмов, произошедших из контекстных диаграмм;
l) диаграмма IDEF0.
Примечание - IDEF0 (Определение интеграции 0) моделирование функции обозначено, чтобы представить решения, действия и деятельность существующей или предполагаемой организации или системы. См. дополнительную информацию - IEEE Std. 1320.1.
Для определения воздействия модели на качество системы должна быть оценена каждая логическая модель проектирования архитектуры.
Множество технических требований может быть распределено с помощью моделей архитектурного проектирования, чтобы сформировать множество производных технических требований, учитывающих эксплуатационную окружающую среду. Эти полученные технические требования могут использоваться как основание для физического архитектурного проектирования.
Для утверждения логических моделей архитектурного проектирования следует рассмотреть существующие системные элементы или введение новой технологии. Использование существующих систем помогает уменьшить время и стоимость, но может увеличить сложность. Использование новых технологий может обеспечить конкурентное превосходство, но может также увеличить риск. С учетом этого новые интерфейсы могут быть введены и должны быть включены во множество технических требований через повторение процесса анализа требований системы.
Для восходящей и нисходящей прослеживаемости относительно множества технических требований, произведенных процессом анализа требований системы, должно быть проверено множество декомпозируемых и произведенных технических требований.
5.4.3.2.4.3 Физическое проектирование архитектуры
5.4.3.2.4.3.1 Общее
Физический проект архитектуры использует выходные результаты логического определения архитектуры, и эти два процесса итеративно взаимодействуют. В выполнении физического проекта архитектуры для формирования альтернативных физических решений проекта могут использоваться логические модели архитектурного проектирования, полученные технические требования и те технические требования, которые не распределены по логическим моделям архитектурного проекта (см. ИСО/МЭК 12207 подпункт 6.4.3.3). После оценки каждого альтернативного физического проекта с использованием соответствующего анализа стоимостной и эксплуатационной эффективности и рисков для проектирования архитектуры должно быть выбрано наиболее предпочтительное решение.
5.4.3.2.4.3.2 Результаты физического проектирования архитектуры
Выбранное решение для проектирования архитектуры должно быть полностью определено для того, чтобы обеспечить выходные результаты, перечисленные ниже:
a) описание конфигурации, включая системные спецификации системы, которая была определена с помощью процесса определения требований правообладателей, процесса анализа требований системы и процесса архитектурного проектирования системы. После реализации или комплексирования системы это описание конфигурации должно использоваться по выполнении процесса квалификационного тестирования системы;
b) требования, которые будут предъявляться к следующим, более низким, уровням систем или системным элементам. Эти требования должны использоваться как начальные спецификации (или требования) приобретающей стороны для реализации систем низшего уровня или системных элементов. Если решение для проектирования архитектуры предназначено только для системного элемента, то для разработки какие-либо иные системы низшего уровня могут отсутствовать;
c) требования для обеспечивающих систем, необходимые для поддержки жизненного цикла спроектированной системы. Эти требования должны быть использованы приобретающей стороной, которой востребована обеспечивающая система.
Описания конфигурации могут быть предоставлены в форме спецификаций, базовых линий, диаграмм и других соответствующих описаний проекта. Определенные описания конфигурации будут зависеть от стадии жизненного цикла, в которой используется процесс проектирования архитектуры системы. Информация должна удовлетворять выходным критериям стадии жизненного цикла и критериям входа для следующей стадии.
5.4.3.2.4.3.3 Прослеживаемость физических результатов проектирования архитектуры
Требования, выраженные в результатах описания конфигурации, должны быть проверены соответствующими способами для гарантий того, что они прослеживаемы сверху и снизу. Прослеживаемость должна быть проверена на соответствие трем источникам требований:
a) произведенным техническим требованиям из логического архитектурного проекта;
b) произведенным техническим требованиям, которые получены из результатов анализа альтернативных физических решений для проекта;
c) требованиям из выходных результатов процесса анализа требований системы, которые не были распределены по модели логического архитектурного проекта. Это могло произойти, когда техническое требование после анализа требований не нашло распределения согласно модели логического архитектурного проектирования.
Процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы могут быть выполнены вновь по мере необходимости для уточнения требований по решению физического проектирования архитектуры и соответствующих описаний выходных результатов (см. пояснения по понятиям итераций в п. 4.4.4.3 этого стандарта). Факторы, которые могут вызвать эту итерацию, включают определение потребности в новых требованиях заинтересованных сторон в ходе проектирования архитектуры или выявление ошибок по результатам проверки прослеживаемости сверху и снизу.
5.4.3.2.4.4 Определение структуры системы
Возможными результатами физического проектирования архитектуры являются требования для следующих, более низких, уровней системы или системных элементов. Эти требования выходных результатов - требования приобретающей стороны для рекурсивного применения процесса определений требований правообладателей, процесса анализа требований и процесса проектирования архитектуры к системному элементу или системе низшего уровня в структуре системы. Системы или системные элементы на следующем, более низком уровне структуры системы, будут позже скомплексированы в систему, от которой произошли требования.
Рекурсивное применение процесса определений требований правообладателей, процесса анализа требований системы и процесса проектирования архитектуры системы показано на рисунке 19 в виде петли, определяемой как нисходящий поток требований приобретающей стороны для каждого уровня структуры системы. Для каждого системного элемента или системы из структуры разрабатываемой системы должны быть применены процесс определения требований правообладателей, процесс анализа требований системы и процесс проектирования архитектуры системы. Также, чтобы сформировать входное множество требований заинтересованных сторон для каждого системного элемента или системы на следующем уровне структуры системы, должны быть определены другие требования заинтересованной стороны (см. пояснения по понятию рекурсии в 4.4.4.2).
Рекурсивная петля на рисунке 19 продолжается, пока все системные элементы структуры системы не будут определены, и никакие дополнительные системы или системные элементы не должны более быть разработаны. Системные элементы могут произойти на любом уровне "x" структуры системы. На каждом уровне, когда никакое дальнейшее развитие не является необходимым для системы в структуре системы, должно быть выполнено следующее множество процессов для реализации. Это пример рекурсивного применения технических процессов, чтобы улучшить определение высшего уровня для рассматриваемой системы путем определения систем более низкого уровня и системных элементов. Высший уровень для одной организации может быть системой, которая будет закуплена потребителем на коммерческом рынке, например такой системой, как автомобиль. Высший уровень для другой организации может быть системой в пределах структуры системы, например, такой системой, как двигатель, который будет собран в автомобиль другой организацией.
Кроме того, на любом уровне системный элемент может быть определен как имеющий уникальный стандарт, который может быть использован для реализации системы.
Рекурсивное применение первых трех процессов на рисунке 19 повторяется в пределах структуры системы, пока процесс реализации применим для системного элемента и пока будут реализованы все системные элементы. В этой точке структура системы будет полностью определена.
5.4.3.3 Соответствующие технические процессы для реализации системы
5.4.3.3.1 Общее
Технические процессы для определения системы описаны в 5.4.3.2. Процесс реализации, процесс комплексирования системы, процесс квалификационного тестирования системы, процесс инсталляции программных средств и процесс приемки программных средств должны использоваться для реализации решений архитектурного проектирования рассматриваемой системы применительно к каждой составной системе и каждому системному элементу до систем высшего уровня структуры системы.
Каждый реализованный системный элемент должен быть верифицирован с использованием процесса верификации и аттестован с использованием процесса валидации прежде, чем будет выполнено комплексирование на следующем, более высоком уровне структуры системы.
Определение структуры системы завершается после того, как все системные элементы структуры системы соответствующим образом реализованы. После этого снизу вверх выполняется рекурсивное применение процесса комплексирования системы, процесса квалификационного тестирования системы, процесса инсталляции программных средств и процесса поддержки приемки программных средств от уровня m к уровню 1 для каждой системы из структуры системы и для рассматриваемой системы в целом.
5.4.3.3.2 Процесс реализации
Процесс реализации может использоваться, когда более не требуется дальнейшего проектирования системного элемента. В этой точке может быть реализован системный элемент, определенный как часть решения архитектурного проекта. Процесс реализации должен использоваться, чтобы преобразовать определения системного элемента в продукты или услуги, соответствующие применимой стадии жизненного цикла. Реализованный системный элемент может быть или единственным продуктом или сложным продуктом в зависимости от его положения в структуре системы и его способности, которая будет соответствующим образом промоделирована, построена, куплена или повторно использована.
Примечание - См. 5.4.4 для применения процессов реализации программных средств к проекту.
5.4.3.3.3 Процесс комплексирования системы
Процесс комплексирования системы может использоваться после того, как системные элементы более низкого уровня были реализованы и поставлены интегратору, ответственному за комплексирование системы на следующем, более высоком уровне. Комплексирование системных элементов может быть выполнено той же самой стороной, которая выполнила реализацию, или приобретающей стороной. Реализованные системные элементы комплексируются в высокоуровневую систему в соответствии с описаниями конфигурации, разработанными во время нисходящего определения и проектирования системы. Эта новая скомплексированная система верифицируется с использованием процесса квалификационного тестирования системы, передается приобретающей стороне на следующий, более высокий уровень с использованием процесса инсталляции программных средств и аттестуется с использованием процесса поддержки приемки программных средств. Это восходящее комплексирование системы продолжается с использованием тех же самых процессов до реализации рассматриваемой системы высшего уровня.
5.4.3.3.4 Процесс квалификационного тестирования системы
Процесс квалификационного тестирования системы может использоваться для установления соответствия между функционированием и характеристиками системы относительно технических требований и других требований соглашения. Этот процесс гарантирует, что каждый системный элемент из структуры системы и рассматриваемая система в целом были реализованы или скомплексированы корректно с перспективой выполнения технических требований системы.
Верификация должна быть выполнена в соответствии с планом верификации. Верификация может зависеть от формы системы, от решений, принятых относительно входа стадии жизненного цикла и выходных критериев, а также от специфики стадии жизненного цикла. Методы примера верификации перечислены ниже:
a) экспертиза (например, экспертиза чертежей);
b) анализ (например, использующий математическое моделирование, имитации, прототип виртуальной реальности или подобие. Пример подобия уже использует выполненные верификации подобных систем с подобными описаниями конфигурации или систем, которые были уже сертифицированы на соответствие стандарту);
c) демонстрация (например, с использованием макетов, физических моделей или функционирования. Пример функционирования - верификация описаний конфигурации, которые применимы к анализу затрат в жизненном цикле или системным показателям, таким как, например, средняя наработка системы на отказ);
d) тестирование (например, с использованием физических продуктов, прототипов).
Для выполнения верификации используется реализованная или скомплексированная система. Для верификации на ранних стадиях жизненного цикла системы следует использовать экспертизу, анализ, демонстрацию или подобие. Для более поздних стадий может использоваться функционирование или тестирование. Вместе с тем, во время любой стадии жизненного цикла для некритических требований для уменьшения затрат при верификации может оказаться полезным использование экспертизы, анализа (включая моделирование) и демонстрации.
В общем случае верификации проводятся при управляемых условиях для гарантий того, что каждое требование описания конфигурации удовлетворено системой. Как таковые, фактическая эксплуатационная окружающая среда и использование операторов не являются воздействующими факторами. Если же эксплуатационная окружающая среда все же является воздействующим фактором для специального требования, тогда она должна быть включена в любое моделирование, имитацию или иную форму верификации.
Ошибка при квалификационном тестировании системы может следовать из неадекватного проведения верификации или несоответствующей реализации или интеграции системы. Отклонения, которые обнаружены во время верификации какой-либо системы (или системного элемента или рассматриваемой системы в целом), должны быть соответствующим образом разрешены до передачи системы приобретающей стороне и до принятия программных средств.
5.4.3.3.5 Процесс инсталляции программных средств
Процесс инсталляции программных средств способствует процессу передачи по ИСО/МЭК 15288 и может быть использован, чтобы поставить приобретающей стороне полностью скомплексированную и квалифицированную программную систему. Поставленная система может также быть аттестована, если соглашение требует, чтобы аттестация (валидация) была проведена поставщиком перед передачей. Для этого обычно используется процесс поддержки приемки программных средств. Соответствующая передача должна быть выполнена снизу вверх для каждого системного элемента, составной системы и рассматриваемой системы.
Для передачи должны соответственно учитываться упаковка и отгрузка, установка и гарантии, что каждая сторона должным образом подготовлена к установке системы. Действия передачи будут зависеть от стадии жизненного цикла и положения системы в пределах структуры системы.
5.4.3.3.6 Процесс поддержки приемки программных средств
Для установления соответствия между функционированием и характеристиками системы относительно требований заинтересованных сторон и других требований соглашения может использоваться процесс поддержки приемки программных средств. Аттестация (валидация) во время этого процесса должна гарантировать, что была реализована или скомплексирована "правильная" система, выполняющая требования заинтересованной стороны или оправдывающая ожидания. Множество требований заинтересованных сторон, используемых для аттестации, является выходным результатом для процесса определений требований правообладателей. Для того, чтобы выполнить аттестацию в ее фактической эксплуатационной окружающей среде (рассматривающий другие системные элементы установления связи с компьютером или в рассматриваемых системах) или в моделируемой эксплуатационной окружающей среде, должна использоваться реализованная, скомплексированная и верифицированная система. Окружающая среда аттестации зависит от положения системы в структуре системы. Форма системы будет зависеть от стадии жизненного цикла, в которой выполняется аттестация.
Аттестация должна быть проведена, чтобы продемонстрировать, что "правильная" система была реализована или скомплексирована после того, как та же самая система была верифицирована, используя процесс квалификационного тестирования системы. Система должна быть верифицирована на то, что она была правильно реализована или скомплексирована прежде, чем показать, что это "правильная" система.
Аттестация может быть выполнена приемлемым образом с имитацией или математическим моделированием, с технологическим прототипом, с опытным прототипом или с поставленной или инсталлированной системой, чтобы удовлетворить входные или выходные критерии применимой стадии жизненного цикла системы и соглашения. По возможности и приемлемости аттестация должна быть выполнена с использованием операторов или пользователей, ожидаемых при эксплуатации.
Аттестация может быть завершена или до передачи приобретающей стороне, или после передачи, как определено в соглашении. Если аттестация системы ("как смоделировано", "как построено" или "как скомплексировано" и "как верифицировано") выполнена перед передачей, то поставщик нормально осуществляет передачу. В ином случае приобретающая сторона аттестует "как поставлено" систему до комплексирования с другими приобретенными системами более низкого уровня и системными элементами, применимыми к комплексируемой системе. Процесс поддержки приемки программных средств может быть выполнен с использованием математической или имитационной модели, когда стоимость аттестации является воздействующим фактором или где эксплуатационная окружающая среда не всегда доступна.
Для того, чтобы выполнить процесс поддержки приемки программных средств, существует несколько подходов, таких как перечислено ниже:
a) аттестация на соответствие требованиям приобретающей стороны и заинтересованной стороны, используя те же самые методы, что используются для верификации, то есть анализ (включая моделирование или математическое моделирование), экспертизу, демонстрацию и/или тестирование;
b) сертификационные тесты на соответствие установленным требованиям;
c) приемочные испытания с использованием эксплуатационных процессов и персонала в эксплуатационной окружающей среде;
d) как определено в соглашении.
Используемый подход зависит от стадии жизненного цикла системы, в которой аттестация проводится с учетом стоимости, сроков, уровня системы в пределах структуры системы и доступных ресурсов.
Ошибки при аттестации могут быть результатом неадекватного проведения аттестации или ненадлежащего преобразования требований заинтересованных сторон в предпочтительное решение для проектирования архитектуры. Отклонения, обнаруженные при аттестации, должны быть соответственно разрешены до передачи системы (или системного элемента или рассматриваемой системы) приобретающей стороне (если аттестация сделана поставщиком) или до комплексирования с другими системами или системными элементами в систему более высокого уровня (если аттестация сделана приобретающей стороной после получения от поставщика).
5.4.3.4 Соответствующие технические процессы для использования системы
5.4.3.4.1 Общее
Процесс функционирования, процесс сопровождения и процесс прекращения применения должны быть применены, чтобы использовать систему повсюду и до завершения ее жизненного цикла. Они не рассматриваются как часть определения системы (см. 5.4.3.2) или реализация системы (см. 5.4.3.3). Процесс функционирования и процесс сопровождения должны использоваться, чтобы позволить заинтересованным сторонам извлекать пользу от услуг и/или продукции, получаемых от системы, на желаемом уровне и свыше назначенного периода времени, как они первоначально были определены в требованиях заинтересованных сторон. Чтобы гарантировать, что система выводится из эксплуатации и, если приемлемо, физически утилизируется таким способом, который гарантирует, что не будет нарушена безопасность, не будут созданы экологические, эксплуатационные или иные опасности, должен использоваться процесс прекращения применения.
5.4.3.4.2 Процесс функционирования
Процесс функционирования может использоваться всякий раз, когда реализация системы существенно развивает систему для предоставления заинтересованным сторонам желаемых результатов, даже если уровень результатов значительно ниже полной намеченной способности системы. Для систем все более и более характерно совершенствоваться и развиваться некоторым модульным или пошаговым способом, начиная с более скромных основных способностей. Старт в точке, характеризующейся меньшей зрелостью, может позволить заинтересованной стороне раньше понять возможности выгодного возвращения их инвестиций, нежели это может произойти в противном случае. В то же самое время раннее использование процесса функционирования позволяет учиться операторам. Тем самым получается функциональная польза от системы (которая может быть различной, нежели просто обученные операторы системы), например, тем, кто поддерживает систему в процессе сопровождения. Эта возможность изучения и обработки требований для финальной системы может быть формализована в концепции инкрементного построения.
Процесс функционирования может быть применен для намного более длительных периодов времени и в различной окружающей среде, нежели предусмотрено любым определением продукции или процессов реализации. Если не все части процесса функционирования рассмотрены всюду по сроку службы системы, а также, когда изменения в системе, большой или маленькой, происходят быстро или медленно, могут возникнуть ошибки в процессе функционирования, и, как следствие, отказы в получении намеченной пользы от системы в течение ее жизни.
5.4.3.4.3 Процесс сопровождения
Процесс сопровождения может использоваться даже раньше, чем систему формально считают эксплуатируемой. Возможно наложение между процессами реализации системы и сопровождения, которое может принести пользу и разработчикам, и сопровождающим сторонам. Этим способом может быть проверено качество документации и обучения, а также адекватность мер логистики.
Так, процесс функционирования и процесс сопровождения могут быть применены для намного более длительных периодов времени и в различной окружающей среде, нежели предусмотрено любым определением продукции или процессов реализации. Если не все части процесса сопровождения рассмотрены всюду по сроку службы системы, а также, когда изменения в системе, большой или маленькой, происходят быстро или медленно, могут возникнуть соответствующие ошибки в процессе сопровождения, и, как следствие, отказы в получении намеченной пользы от системы в течение ее жизни. В будущем долгосрочный успех процесса сопровождения также зависит от гарантий того, что имеет место поддержка изменений в функционировании системы, с соответствующей потребностью понять изменения, происходящие в процессе функционирования.
5.4.3.4.4 Процесс прекращения применения
Процесс прекращения применения может использоваться в то время как система все еще эксплуатируется и может быть применен к части системы, а также как ко всей системе. В случае инкрементного развития выведение части системы из эксплуатации является вполне обычным явлением. В этих случаях стратегия прекращения применения может стать сложной, и следует тщательно рассмотреть аспекты такой стратегии.
С другой стороны, такая же ситуация является вполне обычной и для части используемого процесса прекращения применения. Например, устаревшая часть системы может быть выведена из эксплуатации, но все еще оставлена неизменной и способной, если потребуется, к применению, например, при чрезвычайной ситуации или как платформа при тестировании способностей к дальнейшему развитию системы. Это особенно важно в подобных сложных случаях, так как процесс прекращения применения всегда нуждается в разработке и выполнении в условиях синхронизации с функционированием и сопровождением системы.
Процесс прекращения применения должен обратить особое внимание на архивирование информации, связанной с прекращением применения, и на гарантии того, что все необходимые свидетельства получены и считаются доступными. Это может быть необходимо для неопределенно широкого периода времени.
5.4.3.5 Определение и реализация обеспечивающей системы
Обеспечивающие системы относятся ко всем частям жизненного цикла и потенциально поддерживают любой процесс. Для каждого решения по проектированию архитектуры в структуре системы должны быть определены требования к обеспечивающей системе, связанные с самой системой. Требования к обеспечивающей системе должны быть удовлетворены или путем создания обеспечивающей системы, которая подлежит разработке, или путем приобретения или планированием использования какой-либо из существующих и доступных обеспечивающих систем. Эти действия должны быть выполнены для гарантий того, что услуги обеспечивающей системы будут доступны тогда, когда необходимо поддержать рассматриваемую систему в ее структуре во время применяемой стадии жизненного цикла. Рисунок 20 иллюстрирует использование обеспечивающих систем, связанных со стадиями жизненного цикла.
| - | требования рассматриваемой системы к обеспечивающим системам; |
| - | услуги обеспечивающих систем, предоставляемые рассматриваемой системе |
Рисунок 20 - Реализация обеспечивающих систем
Нижеследующие положения поясняют на рисунке 20 пример пригодности оборудования и инструментариев, необходимых для реализации системного элемента или для интеграции системных элементов низшего уровня или систем. Если такое оборудование и инструментарии уже существуют, процессы рисунка 19 не должны использоваться. Вместо этого существующие обеспечивающие системы должны быть приобретены или намечены к применению как приемлемые. Однако, если оборудование или инструментарии должны быть разработаны, процессы, показанные на рисунке 19, должны использоваться способом, описанным в 5.4.3.2 и 5.4.3.3. Требования приобретающей стороны для каждой обеспечивающей системы вытекают из требований, сформулированных во время применения процесса определений требований правообладателей, процесса анализа требований системы и процесса проектирования архитектуры системы применительно к системе, которая должна быть реализована. Такие требования могут включать в себя допустимые пределы приемлемости, типы материалов и их обработки, такие как, например, обрезка, размалывание и штамповка. Дополнительно замысел функционирования (или стратегия) для реализации должен быть доступным так же, как любые ограничения в реализации, чтобы подключать специальные методы, планируемые к использованию. Рисунок 20 предлагает, чтобы у обеспечивающей системы, определенной и реализованной как рассматриваемая система, использующая процессы рисунка 19, также было свое собственное множество обеспечивающих систем для оказания соответствующей поддержки жизненного цикла.
5.4.4 Применение процессов реализации программных средств к проекту
5.4.4.1 Обзор
Рисунок 21 обеспечивает модель для применения процессов реализации программного средства по ИСО/МЭК 12207.
Рисунок 21 - Применение процесса реализации к инженерии
рассматриваемой программной системы
5.4.4.2 Соответствующие процессы реализации для определения программных средств
5.4.4.2.1 Общее
Чтобы создать решения для проекта рассматриваемой программной системы из структуры системы, должны использоваться процесс анализа требований, процесс проектирования архитектуры и процесс детального проектирования программного средства. Процессы для реализации программных средств описаны в 5.4.4.3.
5.4.4.2.2 Процесс анализа требований программных средств
Для выполнения анализа требований заинтересованных сторон и преобразования этих требований во множество технических требований, пригодных к употреблению для реализации рассматриваемой программной системы, может использоваться процесс анализа требований программных средств.
Руководство, предоставленное в 5.4.3.2.3 для процесса анализа требований системы, также применимо к процессу анализа требований программных средств.
5.4.4.2.3 Процесс проектирования архитектуры программных средств
Чтобы преобразовать определенное множество технических требований в приемлемое решение для проектирования архитектуры, которое выполняет технические требования для спроектированных программных средств, может использоваться процесс проектирования архитектуры программных средств. Руководство, предоставленное в 5.4.3.2.4 для процесса проектирования архитектуры системы, также применимо к процессу проектирования архитектуры программных средств.
5.4.4.2.4 Процесс детального проектирования программных средств
Один из возможных результатов из проекта архитектуры программных средств включает в себя требования для следующих, более низких уровней системных элементов или программной системы. Эти требования из выходного результата являются требованиями приобретающей стороны для рекурсивного применения процесса анализа требований программных средств и процесса проектирования архитектуры программных средств к системному элементу или к программной системе более низкого уровня в структуре программной системы. Системы или системные элементы на следующем, более низком уровне структуры программной системы, будут позже объединены в систему, от которой были назначены требования.
Рекурсивное применение процесса анализа требований программных средств и процесса проектирования архитектуры программных средств показано на рисунке 21 как петля, определенная как нисходящий поток требований приобретающей стороны для каждого уровня структуры программной системы. Для каждого системного элемента или составной системы из структуры системы, которая должна быть разработана, должны быть применены процесс анализа требований программных средств и процесс проектирования архитектуры программных средств. Чтобы сформировать входное множество требований заинтересованных сторон для каждого системного элемента или системы на следующем уровне структуры программной системы, должны также быть определены другие требования заинтересованной стороны (см. пояснение по понятию рекурсии в 4.4.4.2).
Рекурсивная петля рисунка 21 применяется до того, пока будут определены все системные элементы структуры программной системы и никакие дополнительные системы или системные элементы не должны быть разработаны. Системные элементы могут появиться на любом уровне структуры системы. На каждом уровне, когда никакая дальнейшая разработка не является необходимой для системы в структуре программной системы, должно быть выполнено последующее множество процессов для реализации программных средств.
Кроме того, на любом уровне программный элемент может быть определен как имеющий уникальный стандарт, который может использоваться для конструирования той системы.
Рекурсивное применение первых трех процессов на рисунке 21 повторяется в пределах структуры системы до тех пор, пока процесс конструирования программных средств окажется неприменимым для элемента программных средств и пока все элементы программных средств не будут построены.
5.4.4.3 Соответствующие процессы реализации программного средства
5.4.4.3.1 Общее
Процессы реализации для определения программных средств описаны в п. 5.4.4.2. Чтобы понять решение для проектирования архитектуры для каждой системы в структуре программной системы от нижнего программного элемента до рассматриваемой системы высокого уровня из структуры программной системы, должны использоваться процесс конструирования программных средств, процесс комплексирования программных средств и процесс квалификационного тестирования системы.
Каждый реализованный системный элемент должен быть верифицирован, используя процесс верификации, и аттестован с использованием процесса валидации прежде, чем будет выполнено комплексирование на следующем, более высоком уровне структуры системы.
После того, как все системные элементы структуры программной системы соответствующим образом реализованы, определение структуры программной системы считается завершенным. После этого сверху вниз должно быть выполнено рекурсивное применение процесса комплексирования программных средств и процесса квалификационного тестирования системы - от уровня n к уровню 1 из структуры программной системы для каждой составной системы и для рассматриваемой программной системы.
5.4.4.3.2 Процесс конструирования программных средств
Когда дальнейшее проектирование программного элемента не является необходимым, может использоваться процесс конструирования программных средств. С этого момента может быть сконструирован программный элемент, определенный как часть решения архитектурного проекта программных средств. Процесс конструирования программных средств должен использоваться для преобразования определенного таким образом программного элемента в продукты или услуги, соответствующие применимой стадии жизненного цикла. Реализованный программный элемент может быть или единичным продуктом или сложным продуктом в зависимости от его положения в структуре системы и его способности, которая будет соответственно смоделирована, построена, закуплена или повторно применена.
5.4.4.3.3 Процесс комплексирования программных средств
После того, как элементы более низких уровней программных средств были реализованы и поставлены интегратору, ответственному за комплексирование в систему на следующем, более высоком уровне, может использоваться процесс комплексирования программных средств. Комплексирование элементов программных средств может быть выполнено той же самой стороной, которая выполнила реализацию, или приобретающей стороной. Реализованные программные элементы комплексируются в высокоуровневую систему в соответствии с описаниями конфигурации, разработанными во время нисходящего определения и проектирования той системы.
5.4.4.3.4 Процесс квалификационного тестирования программных средств
Процесс квалификационного тестирования программных средств может использоваться для установления соответствия между функционированием и характеристиками программных средств относительно технических требований и других требований соглашения. Этот процесс гарантирует, что каждый программный элемент, составная система из структуры системы и рассматриваемая система в целом были реализованы или скомплексированы правильно, исходя из перспектив выполнения технических требований.
Эта верификация должна быть выполнена в соответствии с планом верификации.
5.4.5 Применение процессов в модели жизненного цикла
5.4.5.1 Обзор
ИСО/МЭК 12207 требует, чтобы установление модели жизненного цикла служило основой, в которой выполнены процессы международного стандарта (см. ИСО/МЭК 12207 подпункт 6.2.1.2). Это также требует определения цели и результатов для каждой стадии в установленной модели жизненного цикла. ИСО/МЭК 24748-1 обеспечивает в разделе 4 описание, включая цель и результаты, модели жизненного цикла с множеством из шести стадий жизненного цикла. Эта модель включена на рисунке 22 как ссылка для двух связанных между собой представлений жизненного цикла системы - организационного и инженерного представлений.
Рисунок 22 - Организационное и инженерное представления,
связанные с соответствующей моделью жизненного цикла системы
Модель жизненного цикла системы, проиллюстрированная на рисунке 22, не подразумевает прикладного прецедента или последовательности для применения по ИСО/МЭК 12207. Заказ использования процессов жизненного цикла находится под воздействием множественных факторов, таких как социальные обязанности, мировые торговые законы, организационные культуры и технические рассмотрения. Каждый из этих факторов может измениться во время жизни системы. Менеджер стадии жизненного цикла системы типовым образом выбирает соответствующее множество процессов жизненного цикла для удовлетворения выходных критериев и других целей этой стадии. Например, для удовлетворения системным требованиям во время любой из более поздних стадий жизненного цикла менеджер, чтобы управлять системой в то время, как она выполняет свои необходимые функции или обслуживается, может использовать процесс функционирования программного средства, процесс сопровождения программного средства и процесс прекращения применения программного средства. Чтобы помочь управлять реализацией системы, а также затронуть выведение из эксплуатации ненужных продуктов или тех рабочих продуктов, которые больше не являются необходимыми, во время более ранних стадий жизненного цикла могут использоваться те же самые процессы.
Для определения, какие процессы выбрать и применять во время стадии жизненного цикла системы, менеджер руководствуется целью и результатами для каждой из стадий (см. ИСО/МЭК 24748-1 раздел 4). Выбор соответствующих процессов позволяет развивать систему через управление ее жизненным циклом. Модель жизненного цикла системы на рисунке 22 можно рассматривать как иллюстрацию упорядоченного прохождения, связанного с системой, идущей от одной стадии жизни к другой. И организационные, и инженерные представления рисунка 22 могут быть полезными в обеспечении возможности этого прохождения.
У организации (например, автомобильной компании или поставщика медицинского оборудования) или группы организаций из какой-то области (например правительственное оборонное агентство или группа промышленности) часто есть уникальный взгляд на жизненный цикл системы для управления прохождением от одной стадии жизненного цикла системы до следующей. Иллюстрированное организационное представление включает охваченные управлением действия, которые используются для формирования прохождения через контрольные точки и решения.
Организация использует эти прохождения через контрольные точки как объекты решения, где инвестиционные решения могут быть приняты относительно того, должна ли система перейти к следующей стадии жизненного цикла или должна быть изменена, остановлена или выведена из эксплуатации, или, проанализировав перед одобрением, должны быть выработаны планы относительно следующей стадии. Эти прохождения через контрольные точки и решения могут использоваться организациями, чтобы адекватно реагировать на неизбежные неопределенности и риски, связанные с затратами, планами и функциональностью, когда система создается или используется.
Организационное представление на рисунке 22 служит основой примера, в котором могут использоваться различные подходы в соответствии с целями и задачами организации. Основные и примерные подходы для организационного представления описаны в 5.4.5.2.
Для удовлетворения выходным критериям система должна быть создана соответствующим образом, произведены приемлемые рабочие продукты, обеспечена информация для принятия решения и требуемого доведения. Таким образом, чтобы получить результаты и удовлетворить целям стадии или ряда стадий, во время каждой стадии жизненного цикла системы должны иметь место запланированные технические действия. Инженерное представление на рисунке 22 служит примерной основой инженерных действий, требуемых в модели жизненного цикла системы для удовлетворения критериям прохождения управленческих решений и связанных с ними контрольных точек. Это инженерное представление описано в 5.4.5.3.
5.4.5.2 Организационное представление
5.4.5.2.1 Подходы
Организационное представление на рисунке 22 может варьироваться согласно природе, назначению, использованию и преобладающим обстоятельствам применительно к рассматриваемой системе или бизнесу организации. Однако, несмотря на необходимое и, очевидно, безграничное разнообразие в таких представлениях, есть основное отвлеченное множество характерных прохождений контрольных точек и решений. Каждое прохождение контрольной точки и решения имеет свою цель и роль в жизненном цикле системы. Планируя и осуществляя жизненный цикл системы, необходимо рассмотреть эти прохождения контрольных точек и решений. Контрольные точки обеспечивают временную возможность управления, чтобы проанализировать прогресс между или перед возможными решениями. Примеры контрольных точек предоставлены ниже. Прохождения решений служат основой, в пределах которой организационный менеджмент имеет наивысший уровень представления и возможности управления проектом.
Во время ранних стадий жизненного цикла системы менеджмент может использовать установленные прохождения решений, чтобы определить, были ли достигнуты цели (как финансовые, так и технические) стадий жизни системы удовлетворительным образом и готова ли система переходить к следующей стадии. Во время более поздних стадий жизненного цикла, когда система используется (эксплуатация и сопровождение), прохождения решений используются типовым образом, чтобы принять одно из трех решений, суть которых перечислена ниже:
a) должна ли технология системы быть актуализирована (изменение базовой линии конфигурации без изменения функционирования);
b) должна ли быть внедрена новая системная технология (с изменением функционирования);
c) должна ли система быть соответствующим образом выведена из эксплуатации.
На стадии замысла модели жизненного цикла системы есть два главных варианта прохождения решения. Первый вариант прохождения решения - после периода предварительных исследований. До этого прохождения решения выполняются соответствующие исследования и реализации, исследуются технологические вызовы и возможности и анализируются потенциальные системные замыслы. Замыслы, у которых есть перспективы будущих бизнес-возможностей, предоставляются менеджменту для одобрения и продолжения реализации более многообещающих замыслов. Замыслы могут оказаться необходимыми, чтобы развить новый рынок, ответить на определенную угрозу или ответить на запрос на предложение.
После изучения выполнимости альтернативных замыслов используется второй вариант прохождения решения. Прежде, чем принять решение о начале выполнения стадии организационного представления, должно быть определено:
a) выполним ли замысел и существует ли способность противостоять идентифицированным угрозам или применять возможности;
b) достаточно ли совершенен замысел, чтобы гарантировать продолженную реализацию новой продукции или линейки продуктов;
c) одобрять ли предложение, подготовленное для ответа на запрос.
Для организаций, которые отвечают на запрос на предложение, есть важная контрольная точка стадии технико-экономического обоснования. Эта контрольная точка используется для решения, основано или нет предложение на начальных результатах технико-экономического обоснования.
Организационное представление, иллюстрированное на рисунке 22, включает в себя действия, связанные с четырьмя стадиями жизненного цикла системы - реализацией, производством, использованием и поддержкой. Обычно есть два варианта прохождения решения и две контрольные точки, связанные с действиями осуществления организационного представления. Первая контрольная точка обеспечивает возможность управления для рассмотрения планов относительно выполнения прежде, чем дать сигнал к продвижению в жизненном цикле. Вторая контрольная точка обеспечивает возможность рассмотреть продвижение прежде, чем решение будет принято, чтобы начать производство. Варианты прохождения решения могут использоваться для определения, производить ли разработанную рассматриваемую систему и улучшать ее или списать.
Это организационное представление применяется не только к рассматриваемой системе, но также и к ее составным системам и системным элементам, которые составляют структуру системы. Различные организации могут быть ответственными за различные системы из структуры системы. И у составных систем, и у системных элементов может быть более короткая жизнь по сравнению с рассматриваемой системой, в которую они встроены, и в течение жизни рассматриваемой системы. Они могут нуждаться в замене улучшенными системами или системными элементами.
Организации используют действия по осуществлению организационного представления из рисунка 22 различными способами, чтобы удовлетворить разнообразный бизнес и стратегии реакции на риски. Часто используются последовательные, инкрементные или эволюционные подходы. Эти подходы обсуждены в положениях ниже. Альтернативно может быть разработана приемлемая комбинация этих подходов.
Выбор, реализация и использование организацией одного из этих подходов зависят от нескольких факторов, таких как упомянутые ниже:
a) политика приобретения организации;
b) природа и сложность системы;
c) устойчивость системных требований;
d) технологические возможности;
e) потребность в различных способностях системы в различное время;
f) готовность ресурсов.
5.4.5.2.2 Последовательный подход
5.4.5.2.2.1 Общее
Последовательный подход может быть приемлемым для систем, у которых циклы разработки составляют пять или более лет перед поставкой первой системы. Многие системы, такие как, например, связанные с производством в автомобильной промышленности, используют подобный подход к разработке, начинающейся за три года до того, как будет введена новая автомобильная модель. Проекты, используя этот подход, сталкиваются со многими трудностями, включая контроль за уровнем издержек, финансирование изменений, технологические изменения, проблемы с рабочей силой и заключительное удовлетворение требований заказчика или приобретающей стороны. Эти вызовы появляются из-за длительности периода от установления начальных требований для системы до предложения системы на рынок.
Последовательный подход проиллюстрирован организационным представлением на рисунке 22. Он определяет прохождение решения так, чтобы организация могла управлять упорядоченным развитием системы от концепции (замысла) до выведения из эксплуатации. Для систем, которые полагаются на коммерческие системные элементы, реализацию часто предписывается начинать с фазы выполнения на рисунке 22 без осуществления исследований замысла. В этом случае, при отсутствии разработки инженерии по снижению риска на более ранних стадиях, проект должен знать о рисках стартовой реализации. Использование коммерческих элементов не облегчает инженерии, требуемой для гарантий выполнимости системы или выполнения исследований по снижению рисков и оценок эффективности, необходимых для гарантий того, что интерфейсы совместимы и что системные элементы, как ожидают, будут совместимыми и интероперабельными для удовлетворения функциональных требований. То, что делает этот коммерческий подход, - это уменьшение потребности в прохождении более ранних решений, не устраняя необходимости анализа для уменьшения рисков.
Последовательный подход является наиболее эффективным и самым экономически обоснованным подходом для инженерных систем, где требования известны и устойчивы или для обновлений существующих систем.
5.4.5.2.2.2 Применимые системы
Этот подход действует для систем, которые представляют один или несколько видов тех систем, которые производят большие количества продукции. Примерами систем, для которых может примениться этот подход, являются инфраструктурные системы информационных технологий, модификации производственных систем, автомобили, системы управления и потребительские продукты. Во время стадии производства могут быть произведены и поставлены одна или несколько систем. Или же может быть начато производство большого количества, которое может продолжаться стадиями эксплуатации и поддержки. Стадии эксплуатации и поддержки - это обычно самый длительный период жизненного цикла, продолжающийся многие годы. Реализованные большие системы, использующие этот подход, часто имеют период функционирования в десятки лет с модификациями, используя технологические обновления и вставки, сделанные для поддержки устойчивости системы и увеличения срока ее полезного использования.
Этот последовательный подход также применим к модернизации устаревших систем. Однако инженерия сделана для расширяющейся системы и связана с ее соответствующими системами и системными элементами более низких уровней из структуры системы. Должно быть проанализировано воздействие на рассматриваемую систему. И там, где выявлены противоречия, должны быть сделаны изменения в высокоуровневых системах и в рассматриваемой системе, или же требования к применяемой системе должны быть пересмотрены.
5.4.5.2.2.3 Риски
Используя последовательный подход, из-за долгой продолжительности реализации перед принятием подхода нужно рассмотреть и определиться по нескольким рискам, перечисленным ниже:
a) за эти годы реализации могут измениться ожидания и требования, связанные с системой;
b) из команд могут уйти знающие работники;
c) может измениться персонал, принимающий решения в организации;
d) может измениться персонал заказчика в организации приобретающей стороны;
e) могут уйти из бизнеса поставщики системных элементов и связанных услуг или измениться технологии;
f) могут иметь место технические риски;
g) за время длительной реализации может возникнуть техническое устаревание.
5.4.5.2.2.4 Возможности
С последовательным подходом могут быть связаны такие возможности, как перечислены ниже:
a) подход преднамеренного поэтапного уточнения, посредством чего прогресс в реализации системы тщательно оценивается в каждой контрольной точке, позволяет оценивать системные качество и риски и подтверждать инвестиционные решения прежде, чем осуществляется переход к следующей стадии реализации, производства или поставки партии на рынок;
b) все способности системы поставляются в одно и то же время;
c) штатные решения по модификации позволяют определить, осуществлять ли сопровождение, существенную модификацию или вывести систему из обслуживания;
d) старые системы могут быть синхронно выведены из обслуживания или удалены с рынка.
5.4.5.2.3 Инкрементный подход
5.4.5.2.3.1 Общее
Инкрементный подход относится к организациям, которые регулярно или в запланированных интервалах поставляют на рынок новые версии продукции. Организационное представление мало чем отличается от представления на рисунке 22. Однако контрольные точки установлены в запланированных интервалах, чтобы ввести запланированную версию системы, которая может быть выпущена на рынок. Система, реализованная как результат стадии замысла, может оказаться первой версией.
Вполне обычно, когда полные способности последней версии, которая будет представлена на рынке, могут быть известны в начале реализации системы. Однако в первой версии размещается ограниченное множество способностей. С каждой последовательной версией добавляется больше способностей, пока последний выпуск полностью не включит в себя полное множество способностей.
Применение ИСО/МЭК 12207, как это проиллюстрировано на рисунках 17, 19 и 20, выполняется для реализации каждой версии. Функционирование и поддержка каждой версии осуществляются параллельно с реализацией, эксплуатацией и поддержкой последовательных версий. Ранние версии системы и поддержки тем версиям могут быть постепенно сокращены, поскольку более новые версии закупаются и используются клиентской базой, или же к более ранним версиям применима модификация какого-либо блока, а также могут быть сделаны включения новых способностей из более поздней версии.
5.4.5.2.3.2 Применимые системы
Этот подход применяется главным образом к системам, которые полагаются на новые, расширяемые версии способностей системы, которые будут вводиться в короткие сроки для сохранения конкурентоспособности на рынке. Примеры включают системы информационных технологий, такие как бизнес-системы, медицинские системы, маршрутизаторы и межсетевые экраны.
5.4.5.2.3.3 Риски
Инкрементный подход связан с рисками, такими как перечислены ниже, которые нужно рассмотреть и определиться по ним прежде, чем принять этот подход:
a) у начальных версий системы может быть такое ограниченное множество способностей, что заказчики могут быть не удовлетворены и не заинтересоваться закупкой следующей версии;
b) версии, проданные со слишком коротким интервалом, могут привести к неудовлетворенности заказчика с учетом затрат на модернизацию или переобучение;
c) затраты для обучения (время и деньги), чтобы перейти от одной версии к следующей, могут оказаться недопустимо большими;
d) ожидания могут оказаться неоправданными, если заказчики желают полного множества способностей сразу в первой версии;
e) могут быть получены неадекватные результаты, если требования также непоняты, как и первоначальные задумки;
f) незапланированные технологические изменения или конкурентные способности системы могут потребовать перенаправления реализации и оказать существенное воздействие на затраты и сроки для последующих версий;
g) заказчик может изменить требования при реализации.
5.4.5.2.3.4 Возможности
С инкрементным подходом могут быть связаны такие возможности, как перечислено ниже:
a) требования приобретающей стороны могут быть удовлетворены для ранних способностей;
b) у разработанных прототипов для каждой ранней контрольный точки может быть место на рынке;
c) в условиях конкуренции раннее выведение системы, даже с ограниченными способностями, может позволить эксплуатацию на рынке.
5.4.5.2.4 Эволюционный подход
5.4.5.2.4.1 Общее
Эволюционный подход также применим к организациям, которые регулярно или в запланированных интервалах поставляют на рынок новые версии продукции. Главное различие этого подхода с инкрементным подходом то, что когда предпринимается эволюционная реализация, полное множество способностей последней версии системы неизвестно. Первоначально требования для системы частично определены и затем уточняются с каждой последовательной версией системы, поскольку уроки, изученные из опыта использования ранней версии, учтены в новых востребованных способностях системы.
ИСО/МЭК 12207, как проиллюстрировано на рисунках 17, 19 и 20, применен для реализации каждой версии. В этом случае, реализация новых версий может быть сделана последовательно или параллельно с частичным перекрыванием. Как с версиями, разработанными с использованием инкрементного подхода, различные версии могут быть управляемы и поддерживаемы параллельно. Однако специальное внимание должно быть уделено для сопровождения управления конфигурацией каждой версии так, чтобы функционирование, обучение и процедуры поддержки были приемлемыми для используемой версии.
Часто новая версия с расширенными способностями может заменить более раннюю версию, или к более ранней версии может быть применена модификация какого-либо блока для включения новых способностей из более поздней версии.
5.4.5.2.4.2 Применимые системы
Этот подход применяется главным образом к сложным системам, для которых требования хорошо не ясны даже при том, что потребность в системе понята и очевидна. Обычно эти системы представляют один или несколько видов тех систем, которые производят малое количество продукции. Примерами могут выступать таможенные системы информационных технологий, военные системы информационных технологий и специальные системы безопасности информационных технологий. Этот подход также полезен для систем, которые гарантированно должны достигать требуемого качества при использовании.
5.4.5.2.4.3 Риски
Эволюционный подход связан с рисками, такими как перечислены ниже, которые нужно рассмотреть и определиться по ним прежде, чем принять этот подход:
a) может оказаться предпочтительным одновременная готовность полного множества способностей;
b) затраты на обучение могут оказаться недопустимыми для продвижения следующей версии;
c) может иметь место неопределенность, связанная с определением будущих требований;
d) может иметь место неопределенность относительно планирования сроков выпуска следующей версии;
e) управление конфигурацией может быть проблематичным;
f) неприемлемо раннее использование прототипа продукта в производстве.
5.4.5.2.4.4 Возможности
С эволюционным подходом могут быть связаны возможности, такие как перечислены ниже:
a) требования приобретающей стороны для ранних способностей могут быть удовлетворены;
b) обратная связь с заказчиком может быть использована для увеличения способностей будущей версии системы;
c) прототипы, разработанные для удовлетворения ранних контрольных точек, могут найти использование на рынке;
d) раннее выведение ограниченной системы способностей может позволить противостояние угрозам со стороны конкурентов;
e) использование преимуществ появляющихся технологий.
5.4.5.3 Инженерное представление
5.4.5.3.1 Общее
Инженерия связана с системой с ранних стадий жизненного цикла (замысел и разработка), когда система изучается, определяется и создается. Дополнительная инженерия вовлекается в более поздние стадии (производство, применение, поддержка, списание), когда нежелательные и неожиданные изменения появляются из-за ошибок проектирования или отказов или возникновения новых требований, появляющихся из-за технологических, конкурентных изменений или угроз.
Для создания выполнимого решения для системы во время стадии замысла структура системы должна быть в достаточной мере определена и оценена. Это должно быть сделано для того, чтобы обеспечить удовлетворение требований системы, а затраты и риски стали понятными для воплощения выбранного замысла системы. Когда перечень частей образует выходные критерии (например, требуемые как часть предложения или в порядке подготовки предложения по кредитоспособной стоимости), должна быть выполнена достаточно детализированная инженерия для гарантии того, что перечень частей полон, а затраты и риски понятны.
Для создания системного решения в течение стадии реализации система должна быть спроектирована с соответствующими деталями от уровня рассматриваемой системы сверху вниз через последовательные уровни системы, пока системный элемент не будет сделан, закуплен, повторно применен или реализован программными средствами. Каждая система должна быть верифицирована на предмет того, что она отвечает своим специфичным требованиям, включенным в описания конфигурации из архитектурного проекта, и аттестована на то, что она удовлетворяет требованиям приобретающей стороны и другим требованиям заинтересованных сторон. Каждый системный элемент должен перейти к приобретающей стороне, где он может быть собран и скомплексирован в систему более высокого уровня, которая верифицируется, передается и аттестуется. Это действие продолжается через последовательные уровни снизу вверх для реализации желаемой рассматриваемой системы.
Данный подход, применим ли он к стадии замысла или стадии реализации, является типовым, инженерным подходом сверху вниз и снизу вверх и описывает один блок инженерных действий, проиллюстрированных в инженерном представлении на рисунке 22. Подходы нисходящего и восходящего проектирования проиллюстрированы на рисунке 23 и идентифицируются в технической литературе как диаграмма V или V-модель. Этот рисунок отражает рабочие продукты и действия, которые ожидаемы от рекурсивного применения процессов из рисунка 19 для определения и реализации структуры системы.
Рисунок 23 - V-модель в инженерии
Хотя инженерия V-модели на рисунке 23 показывает только четыре уровня, процессы определения требований правообладателей, анализа требований системы и проектирования архитектуры системы должны быть применены к рассматриваемой системе, системам и системным элементам из структуры системы. Типовые рабочие продукты (спецификации и планы верификации и аттестации) должны быть разработаны для каждого уровня структуры системы, как это проиллюстрировано на рисунке 19.
Основание V на рисунке 23 представляет собой применение процесса реализации на любом уровне структуры системы. Результат - реализованный системный элемент, который может быть математической моделью или физическим прототипом или физическим продуктом, который передается приобретающей стороне. Фактический продукт зависит от стадии жизненного цикла системы и от выходных критериев организационного представления для прохождения решения или контрольных точек.
Правая сторона V на рисунке 23 иллюстрирует применение процесса комплексирования системы, процесса верификации, процесса передачи и процесса валидации для формирования высокоуровневых систем. Эти процессы применены рекурсивно на каждом уровне к каждому элементу системы, каждой системе и, наконец, к рассматриваемой системе. Это иллюстрирует, что каждая система, включая рассматриваемую систему из структуры системы, должна быть скомплексирована, верифицирована и аттестована по описаниям конфигурации и других описательных документов относительно соответствующей системы слева.
Инженерные усилия исправить отклонения или отказы и удовлетворить измененным требованиям адекватным образом предпринимаются на уровне системы в пределах структуры системы и ниже уровня рассматриваемой системы. При этом является приемлемым тот же самый общий инженерный подход с использованием V-модели. Однако в этом случае задействованная система имеет то место в структуре системы, где начинаются усилия реинжениринга. Требования для изменения анализируются относительно того, как они могут затронуть интерфейсные и взаимодействующие системы и работу рассматриваемой системы. Затем процесс определения требований правообладателей, процесс анализа требований системы и процесс архитектурного проектирования системы используются сверху вниз через последовательные уровни структуры системы, чтобы определить архитектурные решения. После того, как элементы системы реализованы, используя процесс реализации, процесс комплексирования, процесс верификации, процесс передачи и процесс валидации, они могут использоваться снизу вверх через последовательные уровни к рассматриваемой системе. Этот подход часто называют в инженерии "от середины".
V-модель инженерии используется на каждой из стадий жизненного цикла системы как приемлемая для определения входов стадии или выходных критериев или удовлетворения контрольной точке организационного представления или требованиям прохождения решения. Такое использование проиллюстрировано на рисунке 24, с заменой "инженерных действий" идентифицированных блоков, показанных на рисунке 22, с V-моделью на рисунке 23. Есть точки вдоль жизненного цикла системы, когда все функции были определены и могут быть охвачены в управляемом множестве конфигурационных документов, которые часто называют функциональной базовой линией. Подобная точка возникает, когда все функции размещены по аппаратным и программным средствам, процессам, процедурам, услугам, людям или естественно происходящим сущностям (объектам) и может быть осуществлено аналогичное размещение базовой линии. В то время, как могут быть установлены другие такие базовые линии, лишь после того, как сделана первая продукционная инсталляция системы, обычно делается третья базовая линия. Это называют базовой линией продукции, где продукция может относиться в одинаковой степени и к услуге согласно определению системы по ИСО/МЭК 15288.
Рисунок 24 - Инженерное представление с V-моделью
Для каждого применения V-модели обеспечиваются представительные выходные результаты. Эти продукты используются для удовлетворения требования в применимых контрольных точках или прохождениях решений организационного представления (см. рисунок 22).
5.4.5.3.2 Технические ревизии
Для каждого проекта должны быть проведены технические ревизии на соответствие используемому инженерному представлению, такие как перечислены ниже:
a) ревизия, проводимая до выполнения процесса анализа требований для гарантий того, что требования заинтересованной стороны полны, совместимы с намерением приобретающей стороны, понимаемы поставщиком и аттестованы. Эта ревизия может предотвратить продолжение с меньшим, чем приемлемое множество требований;
b) ревизия, проводимая, чтобы учесть все рассматриваемые замыслы и определить, имеет ли предпочтенный замысел потенциал удовлетворения заданных требований заинтересованных сторон и основан ли он на множестве жизнеспособных, прослеживаемых технических требований, которые сбалансированы относительно стоимости, сроков и рисков;
c) оценка установленной базовой линии требований, осуществляемая для гарантий того, что множество технических требований сбалансировано относительно стоимости, сроков и рисков;
d) оценка установленной функциональной базовой линии, осуществляемая для гарантий того, что определение системы основано на достижении технических требований. Это также может использоваться, чтобы гарантировать готовность к продвижению предварительного проекта каждой системы из структуры системы;
e) ревизия, проводимая для предварительного проекта каждой системы из структуры системы, чтобы подтвердить следующее:
1) спецификации и другие описания конфигурации определены как приемлемые;
2) решение для проекта совместимо с требованиями приобретающей стороны;
3) требования к обеспечивающим системам достаточно определены, чтобы начать их реализацию или приобрести приемлемые существующие обеспечивающие системы;
4) подходы, запланированные для разработки проектов прототипов подготовки производства, являются приемлемыми;
5) риски идентифицированы и планы реакции на них выполнимы и обоснованы как эффективные;
f) ревизии, проводимые для детального проекта каждой системы из структуры системы, чтобы продемонстрировать следующее:
1) спецификации и чертежи определены как приемлемые для понимания решения проекта соответственно через реализацию или комплексирование;
2) решение для проекта совместимо с соответствующими требованиями приобретающей стороны;
3) требования к обеспечивающим системам для оказания поддержки жизненного цикла достаточно определены, чтобы начать их реализацию или приобрести приемлемые существующие обеспечивающие системы;
g) ревизии, проводимые до каждой запланированной серии тестов на реализованной или скомплексированной испытательной системе, чтобы гарантировать тестовую готовность, подтверждая, что все тесты, имевшие отношение к обеспечивающей системе, находятся на месте и испытательная окружающая среда подготовлена для достижения целей тестирования (испытаний);
h) ревизии, проводимые до выпуска каждого решения для проекта первой системы или серийного производства, чтобы гарантировать готовность производства, подтверждая, что обеспечивающие системы производства и материалы находятся на месте и окружающая среда производства подготовлена для достижения целей производства.
После завершения детального проекта каждой системы из структуры системы, которая основана на распределенной базовой линии, и с доказательством того, что система производства готова и другие обеспечивающие системы готовы или, как ожидается, будут доступны, когда необходимо, система может быть реализована для производства. Произведенная система может быть одного из видов, первой из ограниченной версии или первой из многих версий, которые будут произведены.
5.4.5.3.3 Аудиты конфигурации
Два типа аудитов конфигурации могут быть выполнены - функциональный аудит и физический аудит. Эти два аудита описаны ниже:
a) функциональный аудит используется для демонстрации того, что результаты верификации системы отвечают спецификациям, на соответствие которым верификация выполнялась, и что запланированные процедуры верификации осуществлены. Этот аудит также используется, чтобы подтвердить, что результаты верификации отвечают документации конфигурации, такой как чертежи, санкционированным изменениям и записям "как построено" или "как закодировано". Обычно для верификации используются прототип для подготовки производства или первая произведенная система. Этот аудит должен заканчиваться перед выпуском системы для начального производства;
b) физический аудит выполняется для проверки "как построена" или "как закодирована" система в сравнении с ее документацией конфигурации, такой как чертежи, ведомость материалов, спецификации, кодовые перечни, руководства, процедуры верификации и данные приемки. Проверенная "как построена" или "как закодирована" система должна быть одной или более из первого множества систем, произведенных во время начального производства. Выбор систем, которые будут использоваться в аудите, должен быть сделан случайным образом аудиторами.
Цели физического аудита представлены ниже:
1) подтвердить, что система была правильно реализована в соответствии с ее чертежами или спецификациями;
2) подтвердить, что информационная база данных представляет существенное множество рабочих продуктов или артефактов от инженерных усилий;
3) подтвердить, что требуемые изменения к ранее утвержденным спецификациям были включены;
4) подтвердить, что обеспечивающие системы для будущих стадий жизненного цикла системы будут готовы, могут быть применены и отвечают требованиям заинтересованной стороны;
5) обеспечить основания для одобрения дальнейшего производства системы, если применимость имеет место.
Подписаться на обновления