Читать онлайн Секреты успешных НИОКР бесплатно

1.1. Задачи управления проектами НИОКР

Текущие события мировой политики в очередной раз поставили перед Российской Федерацией вопрос о выживании этноса, обретении частично утраченного технологического суверенитета, выхода на ведущие роли в перестройке картины мира от гегемонии заокеанских толстосумов, диктата «золотого миллиарда», к ликвидации агрессивного блока НАТО, построению многополярного, разносторонне развивающегося, экономически полноценного общества.

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

Сегодня мир в своем развитии перешел в фазу 4-й индустриальной революции. Ее отличительными компонентами являются (вариант):

• активизация науки о материалах;

• внедрение аддитивного производства;

• эффективное хранение энергии;

• БАС (беспилотные авиационные системы);

• движение к полностью электрическому самолету;

• появление гиперзвуковых летательных аппаратов;

• развитие нанотехнологий;

• широкое развитие робототехники;

• внедрение элементов искусственного интеллекта;

• развитие интернета вещей;

• использование квантовых компьютеров.

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

Основным объектом приложения системной инженерии являются системы.

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

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

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

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

Процесс вывода инновации на рынок обычно называют коммерциализацией. Можно выделить четыре типа инноваций.

1. Новые для организации продукты, которые могут включать улучшенные копии продуктов конкурентов.

2. Новые продукты для рынка.

3. Расширение существующих продуктовых линеек за счет добавления новых функций.

4. Усовершенствование имеющихся продуктов.

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

В 2021 г. в Национальной инженерной академии США сформулированы привлекательные инновационные темы для реализации в XXI веке.

• Более экономичное использование солнечной энергии, в том числе создание коммерческих самолетов на солнечной энергии.

• Обеспечение населения энергией от ядерного синтеза.

• Эффективные методы улавливания углерода.

• Управление циклом использования азота, «умные» удобрения.

• Обеспечение доступа к чистой воде, опреснение, интеллектуальное орошение территорий.

• Улучшение городской инфраструктуры, интеллектуальные транспортные системы, «умные» сети.

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

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

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

• Предотвращение ядерного террора, пассивный мониторинг ядерных материалов.

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

• Усовершенствованное персонализированное обучение, эволюционные обучающие и современные образовательные системы.

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

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

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

1.2. Жизненный цикл системы и определение системной инженерии

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

Системы могут различаться по сложности, например:

• двигатель самолета по сравнению с набором деталей;

• самолет с двигателями и навигационной системой;

• авиатранспортная система (АТС) с самолетами, пассажирами, грузами, тренажерами, и др.;

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

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

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

1. Цели и критерии эффективности системы в целом.

2. Окружающая среда и ограничения системы.

3. Ресурсы системы.

4. Элементы системы, их функции, свойства и показатели эффективности.

5. Взаимодействие между элементами системы.

6. Управление системой.

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

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

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

Напомним два определения из прикладного стандарта ГОСТ 56136—2014.

• Этап жизненного цикла (life cycle phase) это часть ЖЦ, выделяемая по признакам границ контроля (контрольных рубежей), на которых предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.

• Контрольный рубеж (КР) этапа жизненного цикла (milestone, decision gate) это момент завершения этапа ЖЦ, когда предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.

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

Выделяют основные этапы ЖЦ. Замысел разработки: обычно включает действия по определению цели (зачем нужна система? кто будет ее использовать?) и понимание требований (как должна выглядеть система? как система будет использоваться?). Определение целей и приложений проекта имеет решающее значение для разработки успешных систем.

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

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

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

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

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

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

Пример ЖЦ системы показан на рис.1.1. Пронумерованные аббревиатуры КР обозначают контрольные рубежи между этапами ЖЦ.

Рис. 1.1. Этапы жизненного цикла системы (пример)

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

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

Теперь приведем базовые определения рассматриваемого подхода от некоммерческого общества сиcтемных инженеров INCOSE (2018).

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

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

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

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

В истории человечества следы системно-инженерного подхода заметны при сооружении египетских пирамид, римских дорог, азиатских ирригационных каналов и ряда других объектов, дошедших до наших дней. Так, «подушку» под римской дорогой для колесниц укладывали по правилам того времени до пяти метров толщиной (!), из различных материалов. Спустя столетия эти дороги заасфальтированы и используются для современных автомобилей. Каменные мосты через реки в некоторых голландских городах используются без ремонта на протяжении 300—400 лет. То есть выполнено условие заботы о жизненном цикле продукта в целом: действия на каждой фазе ЖЦ системы были направлены на улучшение жизненного цикла на последующих этапах.

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

2. Промышленные, производственные и испытательные требования.

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

Требования являются ключом к успеху проекта. Для хороших требований к системе или продукту важно наличие следующих свойств.

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

• Измеримость, когда характеристика выражается объективно и количественно, может быть проверена при испытании.

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

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

При выполнении анализа требования полезно классифицировать, разделяя на основные типы.

1. Функциональные требования, отвечающие на вопрос «что система должна делать?» Например, обеспечить связь между землей и самолетом.

2. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»

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

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

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

6. Требования к качеству (включая требования к безопасности).

7. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).

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

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

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

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

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

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

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

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

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

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

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

3. Сформировать производные требования.

4. Определить методы верификации требований.

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

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

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

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

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

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

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

• хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

• лазеек, выражений типа «если это необходимо», поскольку они делают требование бесполезным;

• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

• неконкретных рассуждений;

• нечетких слов, таких как «обычно», «в основном», «часто», «нормально», «типично»;

• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

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

При написании детальных требований к системе используют, в частности, функцию развертывания качества (quality function deployment, QFD). Она переводит потребительские качества, желаемые пользователем, в технические функции и средства для их реализации и развертывания доступных ресурсов при создании продукта или услуги [2]. Метод QFD основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуют в технические. Технические характеристики преобразуют в характеристики компонентов, далее в характеристики процессов и, в завершение, в характеристики контроля продукта. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве.

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

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

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

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

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

1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.

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

3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.

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

5. Требования к интерфейсу включают логические и физические интерфейсы.

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

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

В результате процесса разработки формируется набор требований, который должен быть выполнен при создании продукта или системы. Этот завершающий комплект требований содержится в документах контракта, спецификациях или технических заданиях на выполнение работ (statement of work, SOW). Характеристики этого набора будут идентичны вышеописанным пунктам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным, то есть не нуждается в дополнительных пунктах требований. Входящие в него требования должны быть согласованными, то есть не содержат противоречий, дублирований, и др. Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 2.2).

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

1.4 Организация команды проекта и синтез системы

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

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

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

• Пользователь: функциональность, удобство использования.

• Клиент, спонсор, руководство: корпоративные цели, видение, выгода.

• Законодатели: стандарты, руководящие принципы, этические, моральные и правовые условия.

• Заказчик, покупатель: стоимость лицензии, условия контракта, цена.

• Поставщик, продавец: маржа, объем функций, условия контракта.

• Маркетинг, продажи: набор функций, цена, срок поставки, доступность.

• Противники и сторонники проекта: корректировка целей проекта.

• Ремонтный и обучающий персонал: техническое обслуживание, обучение.

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

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

Концептуальное проектирование является первым, и наиболее важным шагом в процессе проектирования системной инженерии. Чтобы объективно оценить возможность успеха реализации проекта, изучают потенциальный рынок и группы клиентов, учитывают факторы окружающей среды, доступ к необходимым ресурсам, готовность персонала, и наличие текущих или разрабатываемых технологий. На предыдущем этапе фиксируют системные потребности и эксплуатационные требования, которые собирают в один всеобъемлющий документ. На основе требований к системе изучаются концепции проектирования в сочетании с анализом осуществимости системы. На этой стадии рассматривают наиболее широкий спектр потенциально возможных решений, которые могут дать значительные преимущества для будущего продукта. Анализ осуществимости проекта дает ответы на вопросы «Выгодно ли проектировать систему?» и «Сможем ли мы это сделать?» Критериями при оценке осуществимости ОКР выбирают стоимость проекта и ценности для организации, полученные при проектировании.

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

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

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

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

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

1. Аппаратные или физические элементы для построения системы, статические или динамические, такие как объект, рама системы, детали, провода, и так далее.

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

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

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

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

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

• Реализацию каждой конкретной функции рекомендуется связывать с каким-то одним модулем системы.

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

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

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

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

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

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

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

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

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

• когда решение связано с умеренным или высоким риском по результату;

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

• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости объема ПКИ.

Полезно использовать проверенные принципы для выработки проектных решений ОКР:

• Лучше продвигаться по проекту, имея несколько запасных стандартных решений, чем опоздать с графиком в поисках одного «совершенного» варианта. Здесь лучшее будет врагом хорошего.

• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски, стоимость разработки и эксплуатации.

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

Для повышения эффективности формирования системы многие компании используют процедуру коллективного экспертного выбора конструкторских решений будущих изделий. Этап выбора базовых проектных решений, например, в компании Airbus, может длиться от 3 месяцев до 1,5 лет. В этом процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. Предпочтительно работы проводятся при личном общении участников на единой площадке. В ходе этапа определяют перечень позиций, по которым должны быть приняты общие заключения, обсуждение и утверждение базовых конструкторских решений. Детально расписан процесс принятия решений и их количество на данном этапе. Примерами критериев принятия оптимальных решений могут быть масса системы, прочность, новизна технологии, стоимость, варианты конструкции, унификация, и др. Согласованный перечень проектных решений далее является руководством к действиям разработчиков на этапах предварительного и детального проектирования системы. Составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Набор этих результатов должен быть задокументирован и является опорным при дальнейшей разработке сложных систем. Так повышается качество разработки, потому что за облик конструкции отвечают совместно эксперты разных направлений. Нет места ошибкам, типа недавно озвученной каким-то самолетостроителем РФ, что проблемы при работе одной из систем нового изделия связаны с тем, что ее проектирование поручили молодому специалисту.

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

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

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

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

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

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

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

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

Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.

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

Важнейшим инструментом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения можно найти в ГОСТ 2.051…2.058.

Электронный макет в процессе разработки включает обычно три уровня.

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

Данные решения проверяются на следующей стадии макета ЭМИ-2 (space allocation mock-up), макет распределения внутренних объемов продукта под компоненты и агрегаты, который развивает мастер-геометрию и служит для проработки использования допустимого пространства внутри изделия при его заполнении конструктивными элементами, определения расположения подсистем и частей оборудования, проверки их взаимной увязки. На базе 3D-моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства.

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

В результате в ЭМИ включены технические данные системы, трехмерные (3-D) модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Сюда входят трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства, результаты расчетов, производственные данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов.

Требования к точности цифровых моделей изложены в ГОСТ Р 57700.23—2020 «Компьютерные модели и моделирование. Валидация. Общие положения». На этом этапе формируется набор цифровых двойников системы.

Цифровым двойником (ЦД) изделия называют систему, состоящую из цифровой модели изделия и двусторонних информационных связей с изделием и его составными частями, согласно ГОСТ Р 57700.37—2021 «Компьютерные модели и моделирование. Цифровые двойники изделий. Общие положения». В основе цифрового двойника лежит модель изделия, которая, в свою очередь, является «системой математических и компьютерных моделей, а также электронных документов изделия, описывающей структуру, функциональность и поведение вновь разрабатываемого или эксплуатируемого изделия на различных стадиях жизненного цикла». Она приближенно описывает структуру, функциональность и поведение вновь разрабатываемого или эксплуатируемого изделия на различных стадиях жизненного цикла. Эта виртуальная модель физической системы постоянно обновляется по следам изменений своего реального прототипа. Разрешением модели называют степень детализации и точности, достигаемую при представлении реального мира в статической или динамической (изменяемой во времени) модели.

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

В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения работоспособного или исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению (сборке) изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления (сборки) изделия и используемых для планирования, оценки и организации процесса изготовления изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.

Вышеперечисленный объем работ на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6—10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве.

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

При этом уточняются следующие наборы данных.

1. Базовая конфигурация (см. раздел 1.5) системы на уровне элементов и компонентов. Она включает утвержденную документацию по конфигурации системы, списки компонентов и частей, их технические спецификации, инженерные чертежи, модели прототипов системы и интегрированные проектные данные.

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

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

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

1.5 Конфигурация и технические данные системы

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

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

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

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

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

• Распределенный базовый вариант «как спроектировано» содержит утвержденную конструкторскую документацию для разрабатываемого КЭ, которая описывает функциональные характеристики, производительность и свойства интерфейса.

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

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

Частным случаем управления конфигурацией является проведение изменений в проекте. Изменением называют модификацию ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов, и т. п. Правила внесения изменений в конструкцию изложены в ГОСТ 2.503—2013. Решения об изменениях проекта принимают, если в процессе проектирования выявлены места, где конструкция неудовлетворительна из-за невыполнения функций, сборки, обслуживания или внешнего вида. Некоторые изменения неизбежно происходят на разных этапах процесса проектирования. Причинами являются изменения требований клиентов, изменения в технологиях и ресурсах, и так далее. На более поздних фазах разработки, таких как этап рабочего проектирования, небольшое изменение в спецификации системы может оказать значительное влияние на всю систему. Следует определять причины изменений как можно раньше. Чем позже в проекте происходят изменения, тем дороже они становятся. Необходимо соблюдать надлежащую процедуру контроля изменений, чтобы свести к минимуму воздействие на всю разработанную систему. Одной из задач руководителя проекта является минимизация количества изменений конструкции для каждой подсистемы.

Общие данные программы, то есть многообразие видов используемой информации, можно разделить на технические данные, программное обеспечение, управленческую и финансовую информацию. Информацией называют организованные данные, которые имеют значение и ценность для получателя. В каждом проекте или программе должны быть определены наборы ключевых технических данных, используемых в течение жизненного цикла системы. Их основу составляют полные сведения о продукте, включая определение требований, конструирование, испытания, производство, упаковку, хранение, эксплуатацию, обслуживание, модификации и утилизацию продукта. Текущая версия конфигурации также входит в технические данные. ГОСТ Р 58675—2019 «Автоматизированная система управления данными об изделии. Общие требования» включает полезные рекомендации по составу информации.

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

Интегрированный объем технических данных об изделии можно классифицировать в соответствии с этапами его ЖЦ.

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

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

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

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

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

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

Сегодняшний этап цифровизации (развития компьютерных технологий и связанных с этим сфер деятельности) часто называют «цифровой индустрией 4.0». Его характеризуют, например, следующими признаками (зависит от источников информации).

1. Компьютеризация для цифрового управления всеми основными компонентами производства.

2. Сетевое взаимодействие между компонентами.

3. Создание цифрового отображения или «виртуального двойника» предприятия (визуализация бизнес-процессов).

4. Прозрачность цифрового отображения аналитических систем с так называемыми «большими данными».

5. Прогнозирование.

6. Адаптивность бизнеса к изменяющимся внешним условиям.

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

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

1.6 Верификация и валидация,

обзоры проекта

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

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

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

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

Верификация ориентирована на компоненты и подсистемы, и проводится:

• в процессе разработки;

• чтобы убедиться, что утвержденные требования будут выполнены;

• как правило, в лабораторных условиях (не натурных).

Основные задачи верификации при разработке перечислены ниже:

1. демонстрация соответствия конструкции и характеристик установленным требованиям на заданных уровнях;

2. обеспечение соответствия продукта разработанному проекту, отсутствия дефектов производства, и пригодности к применению;

3. подтверждение способности системы в целом выполнять требования программы в эксплуатации, включая инструменты, процедуры и ресурсы;

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

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

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

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

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

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

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

Испытания являются наиболее ресурсоемкой методикой верификации. Они делятся на три группы.

1. Испытания, проводимые разработчиком, чтобы убедиться, что проект системы соответствует системным требованиям.

2. Испытания, выполняемые изготовителем или строителем для подтверждения качества работ.

3. Испытания, проводимые заказчиком, чтобы убедиться, что система соответствует требованиям пользователя и другим договорным соглашениям.

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

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

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

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

Методы верификации могут быть разбиты на подвиды.

1. Техническая оценка соответствия требованиям.

2. Поэтапные обзоры результатов.

3. Расчетный анализ.

4. Оценка безопасности компонентов.

5. Стендовые испытания на модельном прототипе или макете.

6. Проверка регулирующими органами.

7. Моделирование динамических режимов с использованием ЦД.

8. Аттестация используемого оборудования.

9. Проверка производственных операций, и др.

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

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

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

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

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

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

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