Секреты успешных НИОКР

Великий российский инженер В. Шухов за годы работы реализовал со своими командами более 700 проектов, сложность которых находилась на вершине тогдашних инженерных знаний. Оформлены патенты мирового уровня: паровые котлы, форсунка для мазута, нефтеналивная баржа, стальной цилиндрический резервуар, висячее сетчатое покрытие для зданий, нефтепроводы, промышленная крекинг-установка, ажурная башня в форме гиперболоида (телецентр на Шаболовке в Москве). Построены сотни башен и мостов, зерновые элеваторы, доменные печи, вращающаяся сцена МХАТ.

План ГОЭЛРО в послереволюционной России был выполнен за 9 лет. В результате Россия вышла на 3-е место в мире по производству электроэнергии.

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

В стандарте «Процессы жизненного цикла систем» ISO 15288:2015 (ГОСТ Р 57193—2016) перечислены 30 базовых процессов жизненного цикла систем (рис. 1.2).

Рис. 1.2. Базовые процессы жизненного цикла систем

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

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

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

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

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

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

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

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

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

1. Принцип декомпозиции (разбиения):

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

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

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

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

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

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

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

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

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

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

Выделим 12 последовательных этапов разработки системы.

1. Комплексное техническое планирование, включая формирование планов процессов СИ и продуктов.

2. Управление требованиями, куда входит определение и управление требованиями, которые описывают желаемые характеристики системы. Нужно определить потребности заинтересованных сторон, преобразовать их в требования. Определить системные требования, выполнить анализ и вести управление ими.

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

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

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

6. Управление интерфейсами для определения и управления взаимодействиями между сегментами в рамках системы или взаимодействиями с внешними системами.

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

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

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

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

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

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

Сегодня требования системной инженерии изложены в ряде стандартов ГОСТ РФ. Важные для нашего изложения документы перечислены далее.

• ГОСТ Р 57193—2016 (ISO/IEC/IEEE 15288:2015). Системная и программная инженерия. Процессы жизненного цикла систем.

• ГОСТ Р ЕН 9100—2011. Системы менеджмента качества организаций авиационной, космической и оборонной промышленности, требования.

• ГОСТ 56136—2014. Управление жизненным циклом продукции военного назначения, Термины и определения.

• ГОСТ 56135—2014. Управление жизненным циклом продукции военного назначения, Общие положения.

• ГОСТ Р 58054—2018. Изделия авиационной техники. Управление конфигурацией. Общие положения.

• ГОСТ Р ИСО 10007—2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.

• ГОСТ Р 59193—2020. Управление конфигурацией. Основные положения.

• ГОСТ Р 57100—2016 (ISO 42010:2011). Системная и программная инженерия. Описание архитектуры.

• ГОСТ Р ISO/МЭК 12207—2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.

• ГОСТ Р 57101—2016 (ISO/IEC/IEEE 16326:2009). Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.

1.3 Формирование требований к системе

Напомним основные понятия системы и их роли.

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

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

• Жизненный цикл: определяет, как система будет построена или произведена, ее испытания, продажи, финансирование, эксплуатацию, обслуживание и утилизацию по завершению эксплуатации.

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

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

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

• Функцией называют конкретное действие, которое система выполняет, или значимую цель, для которой система разработана или спроектирована. Функции не надо путать с задачами. Например, в системе кофейного автомата «подача кофейной капсулы» и «дозировка горячей воды» являются функциями автомата. Однако действия «вставить чашку» и «выбрать напиток нажатием кнопки» являются задачами пользователя, а не функциями.

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

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

• Базовая версия системы. Это задокументированная точка отсчета для оценки результатов системного проектирования. На определенных этапах проектирования системы предыдущая базовая версия сменяется на более проработанную или зрелую.

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

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

Необходимым стартовым компонентом для продвижения по этапам разработки является «Концепция эксплуатации» (concept of operation). Это документ, описывающий ожидаемые характеристики разрабатываемой системы с точки зрения пользователя (не путать со спецификацией, где изложен весь набор требований заинтересованных сторон к системе, подсистемам и элементам). В стандартах РФ такой документ не фигурирует. Его задачей является наглядное описание целей создания системы («что» она должна делать, а не «как»). Концепция эксплуатации является базовым источником для остальных действий по реализации системы. Последующие действия по разработке преобразуют вопросы эксплуатации системы и функций поддержки ЖЦ в реальную систему.

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

• Что требуется от системы с функциональной точки зрения?

• Какие основные и второстепенные функции должна выполнять система?

• Что ограничивает ее возможности?

• Что пользователи ценят в ожидаемом продукте?

• Когда необходимо построить и поставить систему?

• Как будет поддерживаться запланированный жизненный цикл системы после продажи?

• Какова предполагаемая стоимость жизненного цикла системы?

• Где предполагается использовать систему?

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

Документирование «Концепции эксплуатации» системы должно завершиться до формирования требований. Она является связующим звеном между желаниями и требованиями для создания и тестирования решения.

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

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

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

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

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

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

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

• Функциональная архитектура, содержащая список действий или функций, необходимых для выполнения требований системы.

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

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

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

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

Рекомендуется ознакомиться с ГОСТ Р 57100—2016 (ISO/IEC/IEEE 42010:2011) «Системная и программная инженерия. Описание архитектуры».

Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом. Требования к системе являются ключевым компонентом процесса ее создания. В стандарте ISO/IEC 29148 определено, что «Требованием называют утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим органом обеспечения качества)».

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

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

Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям.

1. Требования к системе, где собраны требования к продукции, и ее характеристикам.