Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное
Системный подход к управлению высокотехнологичными проектами. 2-е издание, переработанное и дополненное
Виктор Юрьевич Николенко
В книге впервые в отечественной литературе кратко изложены принципы и методы управленческого компонента системной инженерии при создании высокотехнологичной продукции различного назначения.Включены практические сведения по разработке систем ГК «Ростех», «Роскосмос», «Газпром», «Росатом», для городской инфраструктуры, здравоохранения, транспорта и др.Книга рекомендуется в качестве важного дополнения к курсам управления проектами и будет полезна для всех специалистов и менеджеров по теме.
Системный подход к управлению высокотехнологичными проектами
2-е издание, переработанное и дополненное
Виктор Юрьевич Николенко
Дизайнер обложки Ольга Третьякова
© Виктор Юрьевич Николенко, 2024
© Ольга Третьякова, дизайн обложки, 2024
ISBN 978-5-0065-2004-2
Создано в интеллектуальной издательской системе Ridero
Предисловие ко второму изданию
Целью настоящей книги было дать читателю необходимые инструменты по теме для практического использования в повседневной работе. Ее первое издание (2019 г.) стало активно использоваться специалистами и студентами управленческих позиций в различных отраслях. На основании отзывов читателей и общения со слушателями на лекционных курсах подготовлено переработанное и дополненное второе издание.
Расширенное переиздание этой книги в качестве дополнения к стандартным курсам управления проектами будет полезно управленцам-практикам, менеджерам и инженерам по системам, производству и обслуживанию продуктов, а также руководителям высшего и среднего звена в отраслях разработки и производства новой техники (в авиации, космической, автомобильной, химической, нефтегазовой, транспортной, коммуникационной, медицинской технике, машиностроении, в министерствах, ведомствах и государственных корпорациях). Ее также могут использовать студенты, аспиранты и сотрудники университетов, готовящих специалистов различных высокотехнологичных отраслей.
Сегодняшние испытания, выпавшие на долю Российской Федерации, подтвердили важность лидерской роли управленческого персонала в возвращении технического суверенитета нашей страны. Необходимо эффективное и оперативное решение ряда высокотехнологичных задач. В течение следующих 20 лет мир должен будет быстро реагировать на проблемы загрязнения планеты, истощения ресурсов, а также растущего и более мобильного населения. Разработчики продуктов будут иметь все больше возможностей благодаря достижениям в области моделирования и машинного интеллекта для проектирования желаемого поведения системы. Компоненты и подсистемы будут использоваться в нескольких продуктах, поскольку потребителям требуются интегрированные решения. На рынке появятся новые материалы, с новыми свойствами или более доступные, для замены дефицитных, неэкологичных, плохо обрабатываемых образцов, обеспечения невидимости и др. Для экономии ресурсов будет возрастать необходимость повторного использования существующих компонентов и систем. Цифровизация проникнет во все аспекты жизни и окружающего мира. Возможность моделировать поведение продукта в различных сценариях использования и применение цифровых двойников повышает точность проектирования работы систем в условиях эксплуатации, прогнозирование сроков службы изделий.
Управление высокотехнологичными исследованиями и разработками в значительной степени является искусством координации и интеграции усилий высококвалифицированных участников. Менеджер должен обеспечивать порядок работ, движение к цели при исполнении проекта, разумно справляясь с неопределенностью, присущей новым разработкам. Сегодня в Российской Федерации в рамках борьбы за технологический суверенитет открыто окно возможностей импортозамещения основных отраслей высоких технологий, жизненно необходимых для качественного скачка в промышленном развитии государства. Для достижения этих целей специалистам по управлению необходимо учиться эффективно работать в тесно связанных междисциплинарных командах, объединяющих специалистов широкого профиля и узкоспециализированных экспертов, исполняя сложные проекты в рамках заданных сроков и бюджетов с требуемым качеством.
Во втором издании книги переработана и выделена в отдельную главу тема управления жизненным циклом продукции. Существенно расширено изложение вопросов формирования мультидисциплинарной команды проекта, ее обучения, мотивации и лидерства. Добавлена глава о цифровизации управленческих процессов с точки зрения менеджера в части практического применения цифровых двойников и машинного интеллекта. Внесены дополнения в базовую часть текста книги.
Глава 1. Введение
1.1. Почему эту книгу нужно прочесть
В фокусе данной книги находятся практические вопросы управления высокотехнологичными проектами и программами, недооцененные или отсутствующие, к сожалению, в отечественной литературе.
Есть много проектов, которые включают системы и ведут себя в соответствии с законами систем, что связано со спецификой инженерных программ. Методы традиционного управления проектом направляют общее планирование, организацию, контроль, управление ресурсами, однако не детализируют основное содержание управления программами разработки сложных технических систем. Управление проектами в рамках системного подхода ликвидирует указанный пробел, предоставляет руководство и инструменты для управления техническими аспектами программной деятельности, мониторинга и контроля прогресса проекта, адаптируя процессы, специфичные для инженерной программы, с целью оптимального удовлетворения потребностей заказчика.
Процессы создания новых образцов высокотехнологичной продукции в XXI веке стремительно развиваются в связи с требованиями рынка. При этом в разработках новой продукции в мире используются эффективная методология системной инженерии и техника командной работы. Данной теме посвящено значительное количество монографий, часть из которых приведена в перечне литературы в конце книги [1…10]. Обусловлено это тем, что на сегодня системно-инженерный менеджмент является самой важной практической дисциплиной реализации сложных проектов и программ с подтвержденным положительным эффектом, полезным мощным профессиональным навыком инженеров и менеджеров. Системная инженерия (СИ) оформилась на рубеже ХХ… ХХI веков на основе опыта и достижений технических и управленческих наук как организованный набор принципов, правил и процедур создания высокотехнологичных продуктов. Методология была формализована, реализована в стандартах (включая ряд российских ГОСТов) и инструкциях. В международном сообществе системных инженеров INCOSE вышло 5-е издание справочника по СИ [10]. Подробную информацию также можно найти в 3-ем издании курса системной инженерии NASA и двух томов разъяснений к нему [7, 8].
Отечественный опыт обучения системному подходу показал, что понимание методологии системно-инженерного управления приходит уже после выполнения двух… трех проектов.
Данный краткий курс предназначен для менеджеров различных отраслей, включая авиацию, космос, автомобилестроение, железнодорожный транспорт, «Ростех», «Росатом», «Газпром», «Роснефть», сферу информационных технологий, городские инфраструктуры и др. В материале книги широко использован накопленный многолетний практический опыт автора, руководителя пяти инженерных центров, который полезно учитывать при освоении и применении системной инженерии (см. биографию в конце книги).
Ранее автором издано учебное пособие «Базовый курс системной инженерии» [2] на основе опыта работы и курса лекций, прочитанных в 2013…2016 гг. на междисциплинарной кафедре Высшей школы системной инженерии МФТИ. Затем опубликована книга по практической реализации высокотехнологичных программ [4].
Книга построена в следующем порядке.
В первой главе дано краткое введение к предмету.
Вторая глава включает базовые сведения о методологии системной инженерии, необходимые для понимания последующего текста.
В третьей главе изложено основное ядро книги, системный подход к управлению высокотехнологичными проектами в разных отраслях бизнеса. Перечислены специфические параметры управления и даны пояснения по их применению.
В четвертой главе даны сведения по управлению жизненным циклом системы и компьютеризации этого важнейшего компонента управления.
Пятая глава содержит вопросы создания, обучения и мотивации команды проекта, развития карьеры сотрудников.
В шестой главе приведены базовые сведения для менеджера об использовании инструментов цифровизации работ в экономической модели управления высокотехнологичными проектами.
В седьмой, заключительной, главе обобщены выводы по теме и показаны направления деятельности для практического применения изложенного подхода.
1.2. Современная подготовка специалистов
Основной задачей обучающих и обучаемых в области высоких технологий сегодня является исполнение противоречивых требований к подготовке персонала.
• Необходимо заметно увеличить объем материала для усвоения (т.е. тенденция «вечного студента»).
• Одновременно необходимо сократить сроки обучения специалистов для улучшения экономической отдачи.
На этом фоне непрерывно появляются новые разделы знаний, продвижение «передовых теоретических» разработок имеющихся компетенций и колоссальный информационный шум вокруг «лучших новых знаний» в связи с развитием коммерциализации обучения.
На самом деле, если непредвзято аккумулировать накопленный позитивный опыт (российский и зарубежный), задача управления сложными проектами и программами решается с помощью системного подхода вполне реалистичными методами в разумные сроки. Современный набор инструментов инженера опирается на четыре базовые направления, а именно:
1) предметная инженерия (специализацию дает ВУЗ по электронике, робототехнике, автомобилям, вертолетам, нефтехимии и т.д.);
2) система менеджмента качества (как правило, изучается в организации, обеспечивает рыночный спрос и минимизацию затрат);
3) управление проектом (нерегулярный процесс получения общих сведений из многочисленных пособий типа PMBoK и курсов для управленцев);
4) системная инженерия (на сегодня минимально доступна в РФ, «клей» для объединения вышеперечисленного, универсальное дополнение к пропущенным важным элементам инженерной науки в части технической, управленческой и организационной, системный подход, предмет настоящей книги).
Кроме того, инженерные и управленческие службы уже десятки лет работают в едином информационном пространстве (цифровизация процессов, большие объемы данных). Использование данного инструмента в той или иной степени является для менеджеров обязательным наравне со знанием технического английского языка (чтобы с пользой применять возможности интернета). В настоящее время цифровизация бизнеса стала в РФ государственной программой.
Сегодня владение перечисленным набором базовых знаний является необходимым и достаточным для исполнения любых задач промышленности, в том числе авиационной, космической, атомной, нефтеперерабатывающей и др.
На основе многолетнего опыта РФ и зарубежных лидеров рынка высоких технологий автор настаивает, что в том или ином объеме упомянутый набор знаний должен быть на вооружении как инженеров, так и менеджеров. Чтобы профессионально заниматься высокими технологиями, нужно понимать предмет работ и с инженерной, и с экономико-управленческой стороны.
Системная инженерия является достаточно простым, понятным и высокоэффективным средством обучения проектных команд и отдельных специалистов, неотъемлемой частью стандартизации подходов к высокотехнологичным масштабным проектам.
Системный подход к управлению дополняет сведения стандартов проектного управления типа PMBoK в специфичной части применения научных, инженерных и управленческих усилий для:
a) выявления потребностей клиента вместе с возможностями маркетинга, бизнеса и технологий, которые ведут к созданию системы, удовлетворяющей эти потребности;
б) преобразования эксплуатационных потребностей в описание параметров производительности системы и конфигурации системы путем использования итеративного процесса определения, синтеза, анализа, проектирования, тестирования и оценки;
в) интеграции соответствующих технических параметров обеспечения совместимости всех физических, функциональных и программных интерфейсов, чтобы оптимизировать общий дизайн системы;
г) интеграции надежности, ремонтопригодности, безопасности, живучести, человеческих и других факторов в усилия на достижение затрат, сроков графика и технических целей разработки системы;
д) работы с заинтересованными лицами программы, чтобы убедиться, что созданная система сертифицирована для удовлетворения необходимых потребностей и решения проблем клиентов.
Некоторые итоги применения системного подхода в РФ.
• Обучение системно-инженерному подходу приносит заметный практический эффект для 80…90% инженеров и менеджеров (выпускников отечественных ВУЗов) различных категорий.
• Освоение происходит в оперативном режиме, через один… два года сотрудники выходят на удовлетворительные темпы и качество работ, скачкообразно растут понимание системного подхода к задачам и эффективность.
• Заметно снижаются потери рабочего времени в проекте.
• Возрастает качество работ и получаемых результатов.
• Рост производительности труда после периода обучения составляет от 20 до 100% и далее обеспечивается стабильный прирост не менее 15…25% в год (в среднем на команду).
Несколько слов об истории системной инженерии. В ВУЗах СССР широко преподавали данную дисциплину под названием «Системотехника». К сожалению, в РФ обучение системной инженерии резко сократилось. С 90-х годов прошлого века крупнейшие правительственные учреждения и ведущие мировые компании различных стран используют системно-инженерный подход для реализации своих высокотехнологических проектов. Применение стандартов системной инженерии обязательно для контрактов военных ведомств недружественных стран и государственных заказчиков сложных систем (строительство атомных станций, мостов, космических объектов, транспортной инфраструктуры), таких как Министерство обороны США (DoD), Национальная аэрокосмическая ассоциация (NASA), компаний Boeing, Airbus, гигантов в сфере телекоммуникаций и информационных технологий (Siemens, IBM) и др.
Суть системного подхода для достижения целей в рамках управления ЖЦ состоит в комплексном решении задач управления и вопросов проектирования. Данная методология дополняет («склеивает», как сказано выше) набор стандартных дисциплин высокотехнологичного проекта. Системная инженерия охватывает все стадии мультидисциплинарной разработки продукта от замысла до внедрения, руководствуясь интересами конечного пользователя. Процесс разработки изделий в СИ включает постановку проблемы, управление требованиями, нахождение технических решений, моделирование системы, оптимизацию, разработку архитектуры, управление интерфейсами, управление конфигурацией, интеграцию системы, верификацию и валидацию, эксплуатацию, утилизацию продуктов.
Системная инженерия обеспечивает практически значимые эффекты за счет использования общего междисциплинарного языка для участников проекта, целенаправленного снижения проектных рисков, исправления ошибок на ранних стадиях, когда сделать это еще относительно дешево, на основе эффективных процессов жизненного цикла, повышения производительности команды проекта.
В современных проектах на системно-инженерные процессы выделяется статья в бюджете (от 5 до 30%, цифра возрастает в зависимости от масштабов проекта), чтобы предотвратить возможные убытки, исключить последующую переделку готового изделия [7,10]. То есть результатом системной инженерии является не увеличение прибыли, а снижение вероятных убытков проекта за счет выполнения программы в заданные сроки, в рамках бюджета, с высоким качеством согласно требованиям контракта.
Определяющая роль СИ на стартовом этапе любого высокотехнологичного проекта крайне важна, так как после формирования облика продукта реализация проекта движется по заданному пути, затраты спланированы, изменения маловероятны.
Основы системной инженерии изложены в официальных международных стандартах, задающих правила работы, применимые в этой сфере. Они выделены в семейство стандартов системной и программной инженерии. В главе 2.3 этой книги приведен перечень ряда российских стандартов ГОСТ по системной инженерии, то есть отечественная нормативная база также в наличии.
Активный интерес в мире к применению системной инженерии подтверждается тем, что данный предмет входит в учебные планы всех ведущих зарубежных университетов и ведущих российских ВУЗов.
1.3. Пространство возможностей РФ
Для российских управленцев кратко представим сведения о текущем статусе экономической среды, как базы для деятельности. Экономика РФ по паритету покупательной способности (ППС) в 2023 г. вышла на четвертое место в мире (оценка World Economics). Валовой внутренний продукт России по ППС составил $6,4 трлн. Страна закрепилась в мировой пятерке лидеров второй год подряд. Выше в списке расположились Индия ($14 трлн.), США ($27 трлн.) и Китай ($33 трлн.). В 1992 г. страна находилась в этом списке только на 35-м месте. Для понимания экономических возможностей Российской Федерации далее указаны ее места в мировом рейтинге добычи природных ресурсов, производства товаров и услуг, в основном на 2017 г.
1-е место по запасам (19,8% мировых запасов) и экспорту природного газа, 2-е по добыче (2021);
1-е по запасам лесных ресурсов (23% мировых запасов);
1-е по запасам поваренной соли и 2-е по запасам калийной соли;
1-е по запасам питьевой воды;
1-е по экспорту пшеницы и 3-е по ее урожаю (2021);
1-е по запасам олова, цинка, титана, ниобия, магния;
1-е по запасам никеля (2021);
1-е по запасам железных руд (около 28% мировых запасов);
1-е по экспорту стали и 3-е по экспорту металлопроката;
1-е по экспорту азотных удобрений, 2-е и 3-е места по экспорту фосфорных и калийных удобрений;
1-е по запасам алмазов и 2-е по их добыче;
1-е по запасам серебра;
1-е по экспорту платины и 2-е по ее запасам;
1-е по протяженности электрифицированных железных дорог;
1-е по протяженности линий экологичного транспорта (троллейбусы, электробусы, трамваи и метро);
1-е по количеству проданных на экспорт самолетов-истребителей;
1-е по поставкам на экспорт средств ПВО средней и малой дальности;
1-е по экспортным контрактам на сооружение атомных электростанций;
2-е место по производству первичного алюминия (2020);
2-е по запасам редкоземельных металлов;
2-е по количеству парка вертолетов;
2-е по величине подводного флота;
3-е место по запасам каменного угля (23% мировых запасов) и 3-е по его экспорту;
3-е по числу ежегодных запусков космических аппаратов (2022);
3-е по добыче нефти (2021) и 2-е по ее экспорту;
3-е по производству никеля, вольфрама и авиационного титана (2022);
3-е по запасам золота, 2-е по его добыче (2021);
3-е по запасам меди и свинца, вольфрама и молибдена, лития и рения;
3-е по производству цемента (2021);
3-е по числу абонентов сотовой связи;
3-е по производству продуктов нефтехимии;
3-е по производству сахара-песка (2020);
3-е по поставкам вооружения всех видов;
4-е место по количеству ежегодно печатаемых книг и 4-е по числу переводов с них (доказательство заметного мирового интереса к культуре и жизни в РФ!);
4-е по производству электроэнергии (2021);
4-по запасам урана и 7-е по его добыче (2020);
5-е место по добыче угля, синтетического каучука, калийных удобрений, производству стали (2021);
5-е по производству рафинированной меди;
5-е по производству мяса свинины и мяса птицы (2021);
6-е место по производству натурального молока и растительных масел (2021);
9-е место по производству зерна, черных и цветных металлов, целлюлозы, пиломатериалов.
За 2022 и 2023 гг. в РФ введено в строй более 590 новых значимых производственных объектов (с инвестициями от 150 млн. руб.).
Располагаемые запасы природных ресурсов, уровень развития в промышленной, энергетической, добывающей и сельскохозяйственной сферах представляют уникальную базу для дальнейшего экономического развития нашего государства.
В 2024 г. Правительство РФ выделило 12 национальных проектов, реализация которых нацелена на оперативное достижение технологического суверенитета в критически важных отраслях:
1) станкостроение и робототехника,
2) новые материалы и химия,
3) обеспечение продовольственной безопасности
4) новые медицинские технологии.
5) развитие беспилотной авиации,
6) развитие космической отрасли,
7) атом и новые источники энергии,
8) производство судов и судового оборудования,
9) гражданская авиация,
10) микроэлектроника,
11) экономика данных,
12) наука и университеты.
Все они нацелены на организацию производства новой продукции на основе собственных линий разработки. Эти проекты также затрагивают кадровую политику, средства производства и интеллектуальные права.
В мире будет развиваться аддитивное фабричное производство, стимулируя расширение индивидуализации и производства по требованию. Это повлияет на развитие новых бизнес-моделей и отношений между клиентом и производителем. Расширяется использование алюминия, титана, редкоземельных металлов, полимерных, керамокомпозитных, высокотемпературных материалов и сплавов для снижения массы, повышения рабочих температур, удешевления узлов и продуктов в целом. Идет активное внедрение новых материалов в части направленного проектирования и изменения структуры и свойств материала продукта, включая обширный класс метаматериалов. Ведутся работы по новым источникам энергии, в том числе внедрение сверхпроводимых установок, водородных и топливных элементов, литий-ионных и других комбинаций аккумуляторов, развитие методов проектирования, направленных на сокращение энергозатрат. Применение роботов на всех этапах жизненного цикла продукции с расширяющимся спектром приложений будет влиять на повседневную жизнь, а также на производственную практику.
Обладание полным циклом создания и производства таких высоких технологий, как авиация, космос, атомная энергия, нефтехимия, электроника является прерогативой небольшой группы стран, технологических лидеров, куда входит и Российская Федерация. Российским управленцам необходимо постоянно учиться организационно и эффективно работать. РФ имеет огромный технологический задел, созданный в минувшие годы, обширную географию природных условий, уникальный опыт мирного сосуществования людей сотен национальностей. В настоящий момент ряд отечественных отраслей испытывает высокую потребность в конкурентоспособных продуктах, созданных в соответствии с международными стандартами. Санкции подталкивают предприятия трудиться еще интенсивнее. При этом слабо используется один важный ресурс развития страны.
Производительность труда в высокотехнологичных отраслях зависит от ряда факторов, в том числе от организации работ по созданию новых продуктов и систем, наращивания импортозамещения, исторического наследия в части послепродажного обслуживания поставленной техники, инфраструктуры и роботизации производства, уровня подготовки персонала. Этот показатель является ключевым резервом РФ в продвижении по пути развития новых технологий, так как ресурсы количественного роста персонала ограничены.
Сегодня мы заметно отстаем, например, от лидеров мировой авиационной промышленности в 5…8 раз по выработке на сотрудника. Статистика для авиационной промышленности мира по данным журнала «Эксперт» (2017 г.) показана на рис. 1. Аналогичная картина по производительности труда в ряде других высокотехнологичных отраслей.
Рис. 1. Производительность труда в мировом авиапроме
О том, как ликвидировать имеющиеся пробелы, чтобы результативно использовать на практике управленческие технологии системной инженерии для повышения эффективности проектов и программ, рассказано далее в этой книге.
Глава 2. База системной инженерии
2.1. Определение системной инженерии
Основным объектом приложения системной инженерии являются системы. Системой кратко называют интегрированный сплав людей, продуктов и процессов, обеспечивающий возможность удовлетворить требуемые нужды или цели.
Перечислим некоторые типы систем. Это бизнес-системы (управление исследованиями и разработками, производством продуктов и услуг для использования на рынке), образовательные системы (обучение и аттестация), финансовые системы (поддержка личных, коммерческих и других финансовых операций), правительственные системы (связанные с управлением людьми как обществом на уровне государства, области, города и т.д.), медицинские системы (больницы, врачи и терапевтические учреждения, управляющие потребностями здравоохранения населения), транспортные системы (наземные, морские, воздушные и космические перевозки людей и грузов), газо- и нефтеперекачивающие трубопроводные системы, городские системы (управление инфраструктурой и транспортом района, города, области), культурные системы (исполнительское искусство музыки и других развлечений, гражданские модели поведения) и др.
Примеры систем (по возрастанию сложности):
•двигатель самолета по сравнению с набором деталей;
• самолет с двигателями и авионикой;
• авиатранспортная система (АТС) с самолетами, пассажирами, грузами, тренажерами и др.;
• система систем, включая АТС, аэропорты, инфраструктуры обслуживания и наземного наблюдения.
Приведем определения из стандарта ГОСТ 56136—2014.
У каждой системы имеется жизненный цикл (ЖЦ). Это совокупность явлений и процессов, повторяющаяся с периодичностью, определяемой временем существования изделия (системы), от начала разработки до вывода из эксплуатации (утилизации).
Этапом жизненного цикла называют часть ЖЦ, выделяемую по признакам моментов контроля (контрольных рубежей), в которых предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.
Жизненный цикл проекта можно разбить на отдельные фазы, отделенные контрольными рубежами (воротами принятия решений). У NASA 7 фаз ЖЦ, в GE их 10, у Airbus 14 последовательных этапов. Пример ЖЦ системы показан на рис. 2.
Рис. 2. Типовые этапы жизненного цикла системы
Контрольный рубеж (КР) этапа жизненного цикла является моментом завершения этапа ЖЦ, на котором предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.
Перечислим основные фазы ЖЦ продукта и типовые контрольные рубежи (КР), или ворота принятия решений, на различных этапах модельного ЖЦ программы создания изделия, показанные на рис. 2.
1. Предварительный анализ изделия (КР 0).
2. Маркетинг для определения бизнес-возможности создания разрабатываемого продукта (КР 1).
3. Концептуальное проектирование и оценка выполнимости (КР 2).
4. Определение облика изделия, эскизный проект (КР 3).
5. Изготовление опытных образцов (КР 4).
6. Утверждение («замораживание») конструкции (КР 5).
7. Испытания и сертификация продукта (КР 6).
8. Производство и эксплуатация (КР 7).
9. Вывод из эксплуатации и закрытие программы (КР 8).
Декомпозиция проекта на этапы ЖЦ переводит организацию процесса разработки на более мелкие и управляемые части. Переход фазовых границ определяется в пунктах оценки прогресса проекта и решений типа «идти / не идти». То есть на контрольном рубеже следует принять решение, продолжать ли проект на следующем этапе, вернуться к чертежной доске и переделать текущую работу завершаемой фазы, или прекратить проект.
Этапы жизненного цикла используют, чтобы помочь планировать и управлять всеми основными событиями разработки высокотехнологичной сложной системы или продукта. Разделение на фазы дает менеджерам возможность контролировать и направлять действия осознанно, упорядоченно и методично, что позволяет реагировать на изменения. Это увеличивает прозрачность и упрощает контроль для успешного завершения проекта.
ЖЦ проекта представляет собой важный управленческий инструмент, который используется для распределения ресурсов, обеспечения доступности ключевых лиц, интеграции действий, поддержки своевременного принятия решений, снижения рисков и создания механизмов контроля и руководства. Так как ранние решения влияют на последующие деятельности и «более зрелую» систему труднее изменить по ходу проекта, в системной инженерии сделанное на ранних стадиях имеет наибольшее влияние на успех проекта в целом.
В истории человечества следы системно-инженерного подхода заметны при сооружении египетских пирамид, римских дорог, азиатских ирригационных каналов и других известных объектов, дошедших до наших дней. Например, «подушку» под римской дорогой для колесниц укладывали по правилам того времени из различных материалов до 5 метров толщиной. Спустя столетия эти дороги заасфальтированы и используются для современных автомобилей. Каменные мосты через реки в некоторых голландских городах используются без ремонта на протяжении 300…400 лет. Т.е. выполнено условие, когда действия на каждой фазе ЖЦ системы были направлены на улучшение жизненного цикла на последующих этапах.
Великий российский инженер XIX—XX веков Владимир Шухов за годы профессиональной деятельности реализовал со своими подрядными коллективами более 700 проектов. При этом уровень работ находился на вершине тогдашних инженерных знаний, оформлены патенты мирового уровня: горизонтальный и вертикальный паровые котлы, форсунка для мазута, нефтеналивная баржа, стальной цилиндрический резервуар, висячее сетчатое покрытие для зданий, арочное покрытие, нефтепровод, промышленная крекинг-установка, ажурная гиперболоидная башня (телецентр на Шаболовке в Москве). Всего построено около 200 башен, около 500 мостов, зерновые элеваторы, доменные печи, плавучие ворота сухого дока, вращающаяся сцена МХАТ.
План ГОЭЛРО в послереволюционной России был утвержден в декабре 1921 г. и к 1930 г. перевыполнен. В результате Россия вышла на 3-е место в мире по производству электроэнергии.
Причинами возникновения системной инженерии в ее сегодняшнем виде стали факторы, появившиеся в мире после Второй мировой войны. Активизировалась реализация больших программ, в первую очередь военно-промышленного направления, и основными приводами развития управленческой мысли стали:
1) развитие затратных высокотехнологичных программ с учетом управления рисками и информационных технологий;
2) активизация рыночного соревнования между странами и компаниями (развитие маркетинга);
3) углубление специализации разрабатываемых систем, что выявило важность типовой декомпозиции элементов, управления требованиями, интерфейсами, верификации и валидации;
4) нарастание кадровых проблем для высокотехнологичных отраслей.
Появились книги, справочники и стандарты по теме: H. Good, R. Machol, Системотехника. Введение в проектирование больших систем (1957 г.), справочник Военно-воздушных сил США по системной инженерии (1966 г.), первый СИ стандарт MIL-STD 499 (1969 г.). В СССР один из первых курсов СИ был издан в 1976 г., В. Дружинин, Д. Конторов «Вопросы военной системотехники».
Примененные технологии системной инженерии облегчили успешное получение конкурентоспособных разработок. Переход на командные методы работы по ролям упростил создание результативных коллективов с эффективными лидерами. Для реализации этих задач необходимо было обучить многочисленный персонал. Вследствие необходимости создания новых изделий и освоения высоких технологий ряду стран удалось стандартизовать подготовку творческих инженеров и менеджеров на основе подходов СИ. Сегодня все компании высокотехнологичного сектора имеют справочники системной инженерии в открытом доступе в сети интернет, адаптированные под нужный профиль (в перечне указан год актуального издания).
• Некоммерческое общество системных инженеров INCOSE, 5 изд., 2023 [10].
• Космическое агентство NASA, 3 изд., США, 2017 [7].
• Администрация гражданской авиации США FAA, 2015.
• Компания-интегратор интеллектуальных транспортных систем ITS, 3 изд., 2009.
• Министерство обороны США, DoD, 2006.
• Компания-интегратор авиатехники Airbus, 2004.
• Производитель авиационной техники Boeing, 2003.
При этом перечисленные документы включены для обязательного исполнения в требования для подрядчиков и поставщиков, чем обеспечивается скорость и глубина внедрения методологического подхода.
Приведем актуальные определения предмета книги от общества сиcтемных инженеров INCOSE (2019) и стандарта ISO/IEC/IEEE 15288 (2023).
Системой называют совокупность расположения частей или элементов, которые вместе демонстрируют поведение или значение, которого нет у отдельных компонентов. Системы могут быть физическими, концептуальными (абстрактными информационными), или их комбинацией.
Системной инженерией называют трансдисциплинарный и интегративный подход, позволяющий успешно реализовывать, использовать и выводить из эксплуатации спроектированные системы с использованием системных принципов и концепций, а также научных, технологических и управленческих методов.
СИ фокусируется на:
• установлении, балансировке и интеграции целей заинтересованных сторон, целей и критериев успеха, а также определении фактических или ожидаемых потребностей заинтересованных сторон, операционных концепций и требуемой функциональности, начиная с раннего цикла разработки;
• установлении соответствующей модели жизненного цикла, процессного подхода и структур управления с учетом уровней сложности, неопределенности, изменений и разнообразия;
• создании и оценке альтернативных концепций и архитектур решений; базовых требований и моделирования выбранной архитектуры решения для каждого этапа проекта;
• выполнении синтеза проекта, верификации и валидации системы;
• принятии во внимание проблемных и решающих областей, необходимых систем и служб обеспечения, определении ролей и отношений между частями системы для ее общего поведения и производительности, и балансировке всех этих факторов для достижения удовлетворительного результата.
Процесс СИ завершается интеграцией трех основных активностей:
1) фаза разработки, которая контролирует процесс проектирования и обеспечивает базовые результаты, увязывающие проектные усилия;
2) системная инженерия процесса, обеспечивающего структуру для решения проектных проблем и отслеживающего поток требований через проектные усилия;
3) интеграция жизненного цикла, которая вовлекает заказчиков в проектный процесс и обеспечивает жизнеспособность разработанной системы на всех стадиях ЖЦ.
Инженерной называют систему, разработанную или адаптированную для взаимодействия с ожидаемой эксплуатационной средой для достижения одной или нескольких предполагаемых целей при соблюдении применимых ограничений. Инженерные системы могут включать людей, продукты, услуги, информацию, процессы и природные элементы.
Инженерный менеджмент, как часть процессов системной инженерии, включает искусство и науку планирования, организации, распределения ресурсов, а также управления и контроля деятельности, имеющей технологический компонент.
Отметим, что в определении СИ сделан упор именно на управленческую часть системно-инженерного подхода. Применение СИ на практике позволяет вовремя выполнять решение сложнейших задач, сокращать сроки и стоимость разработок в 1,5…2 раза, снижать количество ошибок в конструкторской документации от 2 до 5 раз. Системная инженерия демонстрирует эффективность разработанных подходов, является выгодным инструментом создания новых изделий, ведет к уменьшению затрат путем оптимизации процессов и исключения переделок (из-за увеличения глубины проработки и исправления ошибок на ранних стадиях проекта). Подход СИ снижает коэффициент экспоненты убытков на масштабе бюджета проекта, причем чем крупнее проект, тем выше эффект применения СИ. Статистика NASA показала, что можно снизить перерасход бюджета на 20…90% (от мелких до очень крупных проектов). При этом оптимальная доля затрат на деятельность системных инженеров составит от 5 до 35% соответственно [7].
В стандарте «Процессы жизненного цикла систем» ISO 15288:2015 (ГОСТ Р 57193—2016) сегодня перечислены 30 базовых процессов жизненного цикла систем (рис. 3). Эти процессы разделены на четыре основные группы.
Рис. 3. Базовые процессы жизненного цикла систем
При разработке систем, продуктов или услуг необходимо найти ответы на несколько фундаментальных вопросов.
1. Что такое система?
2. Что входит в границы системы?
3. Какую роль играет система в организации пользователя?
4. Какие действия в эксплуатации выполняет система?
5. Какие ориентированные на результаты выходы дает система?
При разработке нового продукта требуется организовать структуру, которая оптимизирует управление и руководство, облегчает внутренний обмен информацией, принятие решений и потоки поставок. Рынки высоких технологий требуют от нового продукта удовлетворения уровня качества при запланированных расходах и, что критично, в заданные сроки. Координация инжиниринга, производства, обеспечения качества, маркетинговых функций в процессе разработки нового продукта является жизненно важной. Необходимость использования подходов системной инженерии обусловлена несовершенством устаревших процессов разработки новых изделий. Результатом применения системной инженерии будет повышение качества исполнения программ (выполнение проектов в заданные сроки, в рамках бюджета, согласно требованиям, с высоким качеством).
Для реализации проектов и программ в системной инженерии используют основные варианты декомпозиции.
• Декомпозиция проблемы: разделение сложной проблемы на более простые позволяет легче найти решение и четко сформулировать задачи для каждого сотрудника.
• Декомпозиция времени: разбиение проекта на фазы с указанием конкретных результатов позволяет эффективно контролировать процесс разработки, измерять эффективность и вовремя применять корректирующие меры.
• Декомпозиция продукта: разделение самых сложных изделий на системы, подсистемы, сборки и узлы позволяет эффективно управлять конфигурацией и поставщиками.
• Декомпозиция действий с последующей интеграцией: определяет четкую последовательность необходимых действий (требования, спецификация, декомпозиция, проект, интеграция, верификация, эксплуатация, вывод из эксплуатации).
СИ учитывает деловые и технические потребности приобретателей с целью предоставления качественного решения, которое отвечает требованиям заинтересованных сторон, подходит для достижения цели в эксплуатации и позволяет избежать или минимизировать неблагоприятные непреднамеренные последствия.
Целью всех видов деятельности СИ является управление рисками, включая степень снижения рисков непредоставления того, что хочет приобретатель, риска несвоевременной поставки, риска избыточных затрат и риска негативных непреднамеренных последствий.
2.2. Системное мышление
В процессе реализации высокотехнологичных проектов приходится преодолевать текущие вызовы:
1) интеграции развивающихся информационно-емких систем и технологий;
2) множества заинтересованных сторон с потенциально расходящимися точками зрения и политически мотивированными программами, дефицитными и динамично меняющимися ресурсами, доступными для поддержки проекта или программы;
3) постоянно меняющиеся требования для выполнения;
4) технологические достижения, которые нужно потенциально совместить с имеющимися и развивающимися инфраструктурами для поддержки;
5) срочность реагирования на изменения в операционных предположениях;
6) возрастающие сложности и неопределенности жизненного цикла систем.
Мышлением называют функцию человеческого мозга, отвечающую за концептуальное отражение существенных общих законов в предметах и процессах объективной действительности. Системное мышление (СМ) может предоставить менеджерам и лидерам инженерных специальностей ценные возможности для более эффективного решения упомянутых сложных проблемных областей.
СМ можно определить как новый способ взглянуть и мысленно сформировать видимые сущности; мировоззрение и образ мышления. Где следует видеть сущность или единицу в первую очередь как единое целое, с его соответствием и отношением к окружающей среде. В основе СМ лежит концепция целостности (холизма), которая предполагает, что понимание сложной системы должно охватывать уровень всей системы. Системное мышление определяет целостную философию, способную раскрыть критическую структуру системы: ее границы, входы, выходы, пространственную ориентацию, структуру процессов и сложные взаимодействия системы с окружающей средой. СМ позволяет определить для конкретной задачи набор основных системных принципов, чтобы руководить инженерами на базе более эффективного мышления, решений, действий и интерпретаций для лучшего понимания и разрешения сложных проблемных областей. Разбиение системы на составные части не дает адекватного понимания того, как система функционирует в целом.
Возрастающую сложность можно представить как динамичную, неопределенную, возникающую ситуацию, содержащую большое количество тесно взаимосвязанных элементов и факторов. Диапазон альтернатив индивидуальных точек зрения, целей и предполагаемых интересов усложняет согласование для продвижения вперед. При этом непредвиденные факторы могут включать распределение ограниченных ресурсов, контроль исполнения, личные предпочтения, интересы и др. В сложных проблемных областях заинтересованными сторонами следует считать тех физических или юридических лиц, которые имеют прямой или предполагаемый интерес в решении проблемы, что расширяет их круг, в том числе по мере изучения проблемной области.
Границы сложных систем неоднозначны. Их критерии являются произвольными и часто качественными по своему характеру. Природа границ может принимать различные формы (например, географические, временные, концептуальные, функциональные, физические), которые могут меняться со временем.
В настоящее время объем перерабатываемых для реализации проекта данных и информации растет в геометрической прогрессии. Нужны разработки эффективных подходов к сканированию, фильтрации, сокращению и преобразованию информации в действенные формы. Часто лидерам программ приходится пробираться через «болото» информации, стремясь определить выборки, которые необходимы для принятия решений и действий.
Происходящая смена поколений в рабочей силе вносит дополнительные вопросы в проблемную область. При интеграции командных усилий для создания систем необходимо преодолевать различия между поколениями. В части длительных сроков разработки новых продуктов следует понимать, что используемые знания могут носить временный характер, неполны и подвержены ошибкам.
Использование системного мышления расширяет когнитивные навыки, то есть умственные способности, связанные с тем, как мозг человека обрабатывает информацию об окружающем мире. К ним относятся внимание, память, логика и мышление, визуальная и слуховая память, скорость обработки информации, ответных реакций, регуляция эмоций и др. Это облегчает формулирование проблем, представляя набор доступных альтернатив для решения. Принимаемые решения неизбежно оказывают влияние на другие компоненты в системе, давая возможность делать осознанный выбор.
Для реализации принципов системного мышления рекомендуется действовать следующим образом.
На первом этапе необходимо провести всесторонний анализ текущей ситуации с учетом ее потенциального влияния на возможности, потребности организации и заинтересованных сторон посредством оценки технологических рисков и уровней готовности технологии. Оценивают потенциальные решения об осуществимости.
Второй этап включает выявление и определение желаемой цели, требований бизнеса, а также потребностей заинтересованных сторон. Также необходимо тщательно рассмотреть оценку затрат и планирование процесса разработки.
Третий этап содержит разработку различных типов концепций. Определяют несколько альтернатив для данной концепции, в которых потенциально предложены возможности, повышение производительности или сокращение расходов.
Четвертая фаза включает оценку и выбор предпочтительных альтернатив концепций. СМ подчеркивает необходимость их тестирования и оценки. Модели и прототипы здесь незаменимы для более глубокого понимания потребностей заинтересованных сторон, принятия архитектурных компромиссов, выявления рисков и возможностей.
Для повышения эффективности системного мышления полезно использовать некоторые общие принципы выбора альтернатив его применения.
Выбор сложности (многомерных проблем, рабочих решений) или простоты (избегания неопределенности, работы над линейными проблемами, предпочтения лучших решений и мелкомасштабных задач).
Позиция глобальной интеграции (зависимых решений и мирового уровня производительности) или автономии (независимых решений и местного уровня производительности).
Взаимодействие глобального типа (следовать общему плану, работа в команде и меньше интересов в причинно-следственных связях) или изоляции (склонность к локальному взаимодействию, подробному плану, предпочтение работать индивидуально, в небольших системах и больше интереса к причинно-следственным решениям).
Непротивление изменениям требований (принимать во внимание несколько точек зрения, уделять больше внимания долгосрочным планам, лучше работать в меняющейся среде) или принятие неизменных требований (больше сосредотачиваться на краткосрочных планах и мышлении, иметь тенденцию фиксировать решения и лучше работать в стабильной среде).
Типовые ошибки при решении системных проблем включают, например, такие пункты.
• Выбор неправильных заинтересованных сторон. Отсутствие их достоверного учета может сделать системное решение неадекватным до его развертывания.
• Узкий набор вариантов, когда из-за быстрого исключения возможных альтернативных системных опций из исследования выпадают потенциально эффективные решения.
• Неверно определены суженные границы системы, что может привести к поиску решений неправильной системной проблемы.
• Неправильная формулировка проблемы, когда язык и способ ее описания могут привести к ограничению возможных подходов исследования системы.
• Неспособность применения СМ, тогда как сложные системные проблемы должны рассматриваться комплексно с точки зрения взаимосвязей, шаблонов и границ.
Полезно принимать во внимание несколько принципов, чтобы помочь избежать потенциальных ловушек при применении системного мышления.
1. Уникальность проблемы и потребности. Даже при наличии сходства с предыдущими задачами предположение об уникальности имеет решающее значение для избегания поспешной предрасположенности к конкретному подходу, который мог быть успешным ранее.
2. Уникальность контекста проблемы, набора обстоятельств, факторов, условий или закономерностей, которые ограничат проблему системы и возможные решения.
3. Уникальность методологии развертывания, которая должна быть совместимой и подходящей для конкретной задачи, которая в свою очередь должна быть совместима с решаемой проблемой и содержанием.
4. Системное обрамление. При выработке целостного видения ситуации, разрабатывая несколько правдоподобных сценариев, инженеры и менеджеры должны открывать потенциальное пространство для принятия решений.
5. Предвидение появления системы как результата предполагает сосредоточение внимания на альтернативах, которые можно выявлять, анализировать, эффективно реагировать и оценивать для решения возникающих условий.
2.3. Управление жизненным циклом проекта и продукта
Задача управления жизненным циклом системы состоит в создании управленческих механизмов для принятия локальных решений на каждой из стадий ЖЦ, учитывая все последствия для следующих этапов, и затем позволяют вносить необходимые корректировки в процессы на других стадиях ЖЦ. Сложность объектов, созданных инженерами, определяется их размерами и количеством частей. Если современный пассажирский самолет включает примерно 100 тысяч деталей (без учета крепежа), то нефтяная океанская платформа насчитывает до 10 миллионов деталей. В системной инженерии представлены правила, инструменты и технологии для разработки продуктов и систем любой сложности.
В начале процесса управления жизненным циклом объекта разработки необходимо сделать следующее:
a) определить, что является базовой системой;
b) описать общие этапы жизненного цикла проекта, их цели, деятельности, продукцию и ворота принятия решений, которые их разделяют;
c) описать типичные цели разработки для каждой из фаз ЖЦ проекта.
Основными задачами управления жизненным циклом сложной техники, затрагивая разные фазы ЖЦ, являются (перечень не исчерпывающий, подробности см. в главе 4).
1. Управление процессом проектирования и разработки продукта.
2. Управление процессом технологической подготовки производства.
3. Управление процессом производства.
4. Управление процессами закупки ПКИ, материалов, заготовок, запчастей.
5. Управление процессом испытаний изделия (стендовых, сертификационных, государственных, приемо-сдаточных).
6. Управление процессом логистической поддержки изделия.
7. Управление процессом ППО.
8. Управление процессами подготовки эксплуатирующего состава и персонала ППО.
9. Обеспечение качества на всех этапах ЖЦ за счет процессов управления качеством, управления конфигурацией, реализации процессов системной инженерии.
10. Обеспечение планируемого темпа производства продукта.
11. Достижение заданной трудоемкости разработки и изготовления системы.
12. Управление процессом утилизации при списании изделия.
13. Управление информационной поддержкой всех процессов (с учетом циклов развития аппаратного и программного обеспечения).
Типовое описание процессов жизненного цикла показано на рис. 4. Каждый процесс состоит из входа, действия и выхода, дополненных функциями управления и обеспечения.
Рис. 4. Типовая схема процесса ЖЦ
Структура управления жизненным циклом системы включает все, что должно быть сделано для выполнения программы или проекта в различных фазах, разделенных точками принятия ключевых решений или контрольными рубежами (КР). Напомним, что КР это события, в ходе которых лицо, принимающее решение, определяет готовность программы или проекта к переходу на следующий этап жизненного цикла. В соответствии со стандартом ГОСТ Р 57193—2016 на контрольных рубежах ЖЦ должны быть выполнены главные задачи программы за предыдущую стадию: гарантировано, что последующая доработка организационных и технических базисов приемлема и приведет к удовлетворительной верификации и валидации продукта; обеспечена приемлемость риска перехода на следующую стадию; продолжено стимулирование командной работы поставщика и заказчика.
Утверждение решений на КР следует за проведением технического обзора (совещания или группы совещаний), который основывается на строгом доказательстве соответствия результатов проведенного этапа критериям контрольного рубежа.
Для каждого контрольного рубежа программы устанавливаются входные и выходные критерии. Новые мероприятия не начинаются, пока предыдущие мероприятия, от которых они зависят, не закончатся успешно. На каждом контрольном рубеже имеется набор вариантов решения:
a) приемлемо: переходить к следующей стадии проекта;
b) приемлемо с оговорками: переходить и выполнить затребованные действия, устранив замечания (проверка исполнения замечаний проводится, как правило, на следующем кр);
c) неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность;
d) неприемлемо: вернуться на предыдущую стадию;
e) неприемлемо: заморозить мероприятия проекта;
f) невосстановимо: закрыть проект.
Важными среди базовых процессов жизненного цикла изделия являются проектные процессы, относящиеся к управлению проектами и их поддержка. Налаживание взаимосвязи между процессами в ходе их реализации является одной из основных задач планирования процедур системной инженерии при создании изделия или системы.
Сегодня требования системной инженерии изложены в ряде стандартов ГОСТ РФ.
• ГОСТ Р 57193—2016 (ISO/IEC/IEEE 15288:2015). Системная и программная инженерия. Процессы жизненного цикла систем.
• ГОСТ 56136—2014. Управление жизненным циклом продукции военного назначения. Термины и определения.
• ГОСТ 56135—2014. Управление жизненным циклом продукции военного назначения. Общие положения.
• ГОСТ Р 57100—2016 (ISO 42010:2011). Системная и программная инженерия. Описание архитектуры.
• ГОСТ Р 57101—2016 (ISO/IEC/IEEE 16326:2009). Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.
• ГОСТ Р 58876—2020. Системы менеджмента качества организаций авиационной, космической и оборонной промышленности. Требования.
• ГОСТ Р 59194—2020 Управление требованиями. Основные положения.
• ГОСТ Р 59193—2020. Управление конфигурацией. Основные положения.
• ГОСТ Р 58054—2018. Изделия авиационной техники. Управление конфигурацией. Общие положения.
• ГОСТ Р 56923—2016. Информационные технологии. Системная и программная инженерия. Процессы жизненного цикла программных средств.
Продвижение по звеньям процесса по мере разработки сопровождается верификацией каждого шага, возвратом к предыдущему результату для проверки прогресса работ. При формировании процессов используют особенности описания систем, изложенные в стандарте ГОСТ Р 57193—2016:
a) важность определенных границ, которые влияют на формирование значимых потребностей и практических решений;
b) иерархическое восприятие физической структуры системы;
c) объект любого уровня иерархической структуры может рассматриваться как система;
d) характерные свойства на границе системы возникают в результате взаимодействия между элементами системы;
e) люди могут рассматриваться как внешние пользователи по отношению к системе (например, экипаж самолета) и как элементы в рамках системы (например, персонал завода-производителя);
f) система может рассматриваться как отдельный, изолированный от внешней среды объект.
Выделим 12 последовательных этапов разработки системы, которые включают следующие задачи.
1. Комплексное техническое планирование, включая формирование планов процессов СИ и продуктов.
2. Управление требованиями: определение и управление требованиями, которые описывают желаемые характеристики системы.
3. Функциональный анализ: описание функциональных характеристик (что система должна делать), которые используются для получения требований.
4. Маркетинговая оптимизация: информация по принятию решений на основе анализа и отбора наиболее сбалансированных решений по требованиям рынка.
5. Синтез: этап преобразования требований в физические решения верхнего уровня системы.
6. Управление интерфейсами: определение и управление взаимодействиями между сегментами в рамках системы или взаимодействиями с другими системами.
7. Специализированная (тематическая) инженерия: анализ системы, требования, функции, решения и интерфейсы с использованием специальных навыков и инструментов. Помощь в получении требований, синтезе решений, выборе альтернатив, а также валидации (то ли мы сделали) и верификации (так ли это работает) требований.
8. Целостный анализ: проверка, что выполненная интеграция системы обеспечила требуемый уровень точности и аккуратности.
9. Управление рисками и возможностями: определение, анализ и управление неопределенностями достижения требований программы путем разработки стратегий для снижения вероятности таких неопределенностей.
10. Управление конфигурацией: установление описания и поддержка базовой системы, управление изменениями в характеристиках системы, функциональных и физических свойствах.
11. Проверка (верификация) и контроль (валидация). Верификация определяет, что требования к системе являются правильными. Валидация определяет, что реализованное решение отвечает утвержденным требованиям.
12. Инженерия жизненного цикла: определение и управление требованиями к свойствам жизненного цикла системы, в том числе управление разработкой продукта, развертывание и передача работ, интегрированная поддержка логистики, технологическая производственная часть и вывод из эксплуатации. Разработка навыков и стандартизации для постоянного улучшения результативности и эффективности процессов и инструментов СИ (выявление, документирование и изучение уроков проектов).
Наиболее контролируемым параметром является стоимость жизненного цикла (СЖЦ), то есть общая стоимость программы или проекта за запланированный жизненный цикл от формулировки до реализации. Для долгосрочных (на десятилетия) программ, таких как программы серийного выпуска авиационной техники или функционирования международной космической станции с полетами человека в космос, трудно установить продолжительность жизненного цикла для целей определения СЖЦ. Подробности приведены в главе 4.
Процесс разработки (ЖЦ проекта) в системной инженерии можно представить в виде нескольких взаимосвязанных итерационных петель (рис. 5).
Рис. 5. Процесс разработки системы, MIL_Std-499
Вышеприведенные шаги системной инженерии для удобства иногда декомпозируют, выделяя набор из 33 подпроцессов ЖЦ проекта (стандарт EIA 632 «Process for the Engineering of a System», имеет рекомендательный статус).
А. Поставки.
1. Поставка товаров.
Б. Приобретения.
2. Приобретение товаров.
3. Оценка производительности поставщика.
В. Планирование.
4. Стратегии реализации процесса.
5. Определение технических усилий.
6. График и организация работ.
7. Технические планы.
8. Указания (директивы) для работы.
Г. Оценки.
9. Прогресс исполнения планов и графиков.
10. Оценка соответствия требованиям.
11. Технические обзоры проекта.
Д. Управление.
12. Результаты управления.
13. Распространение информации.
Е. Определение требований.
14. Требования Заказчика.
15. Требования других заинтересованных сторон.
16. Технические требования к системе.
Ж. Определение проектных решений.
17. Представление логических решений.
18. Представление физических решений.
19. Указанные требования.
З. Реализация.
20. Реализация проекта.
И. Передача Заказчику.
21. Ввод в эксплуатацию.
К. Системный анализ.
22. Анализ эффективности.
23. Анализ рыночных альтернатив.
24. Анализ рисков.
Л. Верификация требований.
25. Проверка статуса требований.
26. Проверка требований Заказчика.
27. Проверка требований других заинтересованных сторон.
28. Проверка технических требований к системе.
29. Проверка представления логических решений.
М. Верификация системы.
30. Проверка конструктивных решений.
31. Проверка конечного продукта.
32. Проверка готовности продукта к эксплуатации.
Н. Валидация конечного продукта.
33. Сертификация конечного продукта.
Выявление свойств и характеристик будущей системы начинается с задачи маркетингового исследования рынка. Постановка решаемой проблемы должным образом является одной из важнейших задач системного подхода, потому что элегантное решение неправильной проблемы меньше чем бесполезно.
Постановка задачи маркетологам описывает потребности клиента, заявляет цели проекта, очерчивает предмет проблемы, определяет концепцию эксплуатации, описывает заинтересованные стороны формируемой программы, перечисляет требуемые результаты и представляет основные решения, которые должны быть сделаны. Специалисты по маркетингу в процессе исследования должны:
•определить цели исследования ниши на рынке;
• изучить имеющиеся материалы, включая конкурентную среду, ограничения и допущения;
• выбрать критерии оценки продукта или системы и их относительную значимость (они могут быть качественными и количественными);
• определить и выбрать вероятные альтернативы исполнения системы;
• оценить эффективность каждого варианта для каждого критерия;
• выполнить анализ чувствительности для избранных вариантов;
• сравнить результаты и выбрать предпочтительный вариант продукта;
• задокументировать процесс изучения рынка и его результаты;
• сформировать бизнес-план для обоснования развития будущего продукта или системы.
Рыночная привлекательность продукта определяется набором его преимуществ (характеристики, например, для авиации стоимость пассажиро-километра, масса, надежность, наличие ППО, стоимость владения и др.). Критерии принятия решений на рынке могут быть назначены на основе мер эффективности (голос клиента) и показателей эффективности (голос инженера).
В целом критерии могут быть общими (атрибуты, имеющие значение для каждого элемента структуры продукта, такие как масса или надежность) или уникальными (атрибуты, которые имеют смысл только для определенных элементов изделия). На более низких уровнях структуры (подсистемы, компоненты) отслеживание стоимости количественных оценок можно идентифицировать с помощью функциональных и эксплуатационных требований, отнесенных к каждой отдельной системе, подсистеме и т. д.
В заключение этапа маркетинга проводится проверка финального выбора продукта. При этом необходимо выяснить:
1) были ли выполнены требования к системе и установленные ограничения;
2) является ли предварительный выбор финального варианта сильно зависящим от определенного набора входных значений и допущений или устойчивым при разумном изменении входных значений (т.е. насколько он «надежен» по чувствительности к изменению условий эксплуатации);
3) достаточны ли имеющиеся данные для утверждения предварительного выбора;
4) достаточно ли независимы методы измерения, чтобы дать уверенность, что выполненный предварительный отбор лучше отброшенных альтернатив;
5) если результаты нескольких альтернатив близки, необходим ли дальнейший анализ;
6) является ли предварительный выбор чувствительным к оценочной характеристике или ограничению. Если «да», то следует проверить полный разумный диапазон изменения каждой переменной, чтобы уточнить область, где предварительный выбор обоснован.
Ожидаемые результаты маркетинга включают выбор концепции эксплуатации системы, выбор архитектуры, производные требования (альтернативы функций, распределение требований). Все эти понятия будут обсуждены далее.
Статистика сроков исполнения программ, например компании Airbus, показывает, что сокращению длительности программ уделяется большое внимание, так как скорость выхода нового продукта на рынок сильно влияет на долю рынка, скорость возврата инвестиций, прибыль по ППО и др.
Характер инженерных проектов заметно различается в разных отраслях, организациях, технологических областях и сферах применения. Например, проект разработки программного обеспечения на мобильной платформе кажется далеким от проекта строительства большого нового моста. Для разных систем требуется, чтобы системный подход был адаптирован для системы в целом, а также индивидуально для каждой подсистемы. Методология адаптации может выполняться в два этапа.
1. Для настройки жизненного цикла определяют основные подсистемы. Для каждой из них определяют технические и организационные факторы, влияющие на жизненный цикл. С учетом этих факторов определяются этапы жизненного цикла. Далее описывают основные процессы и результаты для каждого этапа жизненного цикла. Затем этапы жизненного цикла оптимизируют для повышения их эффективности и результативности.
2. После определения жизненных циклов подсистем они объединяются в рамках жизненного цикла системы в целом. Различные этапы жизненного цикла системы синхронизируют по времени, определяют этапы и вехи подсистем, входящие в реализацию жизненного цикла системы.
Например, необходимо разработать систему антенн для применения в радиоастрономии. Объект имеет следующие технические и организационные особенности, которые формируют особенности жизненного цикла:
a) высокая стоимость цикла проектирование-сборка-испытания;
b) низкая технологическая зрелость, так как это новая конструкция;
c) умеренный объем единичного производства;
d) длительный ожидаемый срок службы (до 50 лет);
e) суровые условия эксплуатации в отдаленной пустынной местности с дистанционным управлением.
Описанные выше особенности влияют на адаптацию жизненного цикла следующим образом.
• Необходим комплексный предварительный анализ требований к жизненному циклу проектирования с акцентом на полную проверку конструкции на производительность и долговечность перед началом производства.
• Предполагается одна итерация разработки (создание прототипа) для дорогого штучного проекта.
• Оптимизация эксплуатационных расходов на длительный срок службы имеет решающее значение.
Другая система, например, включает разработку программного обеспечения для обслуживания сложной мехатронной системы предыдущего примера. Особенности жизненного цикла:
1) низкая стоимость цикла проектирования-сборки-тестирования. программные системы могут быть разработаны в виртуальной тестовой среде;
2) высокая технологическая зрелость, разработка проводится на основе хорошо зарекомендовавших себя протоколов управления и мониторинга, которые можно адаптировать к этой задаче;
3) жесткость требований и граничных условий: внешние интерфейсы программного обеспечения четко определены имеющимся аппаратным обеспечением на ранних этапах жизненного цикла, пользовательские интерфейсы также легко определяют на ранних этапах жизненного цикла;
4) используются отраслевые нормы и стандарты разработки программного обеспечения.
В этом примере оптимизация эффективности достигается путем сосредоточения усилий на этапах определения требований и проектирования архитектуры жизненного цикла, где процессы программного обеспечения часто слабы.
Третий пример рассматривает строительство гражданской инфраструктуры для типичного радиоастрономического объекта, расположенного на удаленном участке территории вне городской черты. Сюда входят дороги, здания, электрическая и оптоволоконная сети. Эта система имеет следующие особенности жизненного цикла:
a) очень высокая стоимость цикла проектирование-строительство-испытания;
b) высокая технологическая зрелость;
c) жесткие требования и граничные условия;
d) высокие эксплуатационные расходы и развертывание в удаленной среде;
e) отраслевые нормы и стандарты: в отрасли гражданского строительства существуют устоявшиеся стандартные процессы разработки и строительства;
f) нормативная среда со значительными ограничениями (безопасность, здоровье, окружающая среда и т. д.).
При адаптации ЖЦ проекта следует учитывать, что тщательное определение требований и завершение этапа детального проектирования целесообразно выполнить до заключения контракта на строительство. Процессы проектирования и строительства должны будут соответствовать стандартным нормам гражданского строительства, включая архитектурное проектирование, верификацию и валидацию проекта, постоянные проверки строительных работ и качества поставляемых комплектующих от подрядчиков, а также этап перехода системы в эксплуатацию и проверки конечным пользователем.
2.4. Формирование требований к системе
После утверждения положительных результатов маркетингового исследования идеи продукта для рассмотрения проекта выполняют анализ осуществимости задачи. Нужно оценить различные технологические подходы, которые могут быть рассмотрены при ответе на заданные функциональные требования. В целом необходимо определить различные возможные подходы к проектированию будущей системы, которые можно использовать для удовлетворения требований. Выполнить оценки наиболее вероятных альтернатив и аналогов с точки зрения производительности, эффективности, требований к логистике и техническому обслуживанию; а также экономических критериев жизненного цикла. Исследуются альтернативные применения технологий. Например, при проектировании средств связи можно выбирать между оптоволоконной технологией, сотовой (беспроводной) или традиционной с проводами. При разработке конструкции самолета нужно определить долю использования композитных материалов. При создании большой системы любого типа понять, как следует использовать интегральные микросхемы, печатные платы, системы на кристалле и др. Альтернатив может быть много, однако количество возможностей должно быть сужено до нескольких вариантов, соответствующих наличию ожидаемых ресурсов (т.е. человеческих сил, материалов и технологий) и бюджета.
Необходимым компонентом для продвижения по этапам разработки является «Концепция эксплуатации». Это документ, описывающий ожидаемые характеристики разрабатываемой системы с точки зрения пользователя (не путать со спецификацией, где изложен весь набор требований заинтересованных сторон к системе, подсистемам и элементам). Его задачей является наглядное описание целей создания системы, «что» она должна делать, а не «как». Документ также должен определять любые критические требования или цели производительности на верхнем уровне (сформулированные качественно либо количественно) и их системное обоснование. Форма изложения документа относительно свободная, можно найти много шаблонов в интернете.
В тексте «Концепции эксплуатации» должна содержаться следующая информация.
1. Почему необходима система и предварительный обзор самой системы.
2. Описание полного жизненного цикла системы от развертывания до вывода из эксплуатации.
3. Описание сценариев, иллюстрирующих конкретные эксплуатационные мероприятия, связанные с использованием системы.
4. Указание условий, при которых система используется и обслуживается.
5. Изложены различные аспекты использования системы, включая производство, техническое обслуживание, поддержку и утилизацию.
6. Перечисление различных классов пользователей, в том числе операторов, сопровождающих, партнеров, их различных навыков и ограничений.
7. Определены границы системы, ее интерфейсов и связей с другими системами.
Руководство по разработке концепции эксплуатации удобно готовить в группе заинтересованных лиц программы. При этом:
a) не следует указывать какие-либо особенности системы;
b) не нужно описывать, как идет процесс и как должна выполняться функция, надо только перечислить потребности системы;
c) в рабочую группу рекомендуется включить все заинтересованные стороны (до 15 чел.), которые должны иметь полномочия принимать окончательные решения;
d) желательно собрать всех участников группы в одном месте в одно и то же время, по крайней мере дважды;
e) модератор группы должен обладать навыками руководства группой и следить за ее работой;
f) следует ограничить размер разрабатываемого документа, не ограничивая полученную извне информацию;
g) модератору следует убедиться, что уровень технического языка в документе не препятствует пониманию текста.
После уточнения концепции эксплуатации на этапе анализа необходимо сформировать архитектуру системы, чтобы определить ее особенности, далее сформировать требования к системе и провести ее декомпозицию для упрощения стадии синтеза.
Термин «архитектура системы» обозначает основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития (ГОСТ Р 57100—2016).
Архитектура включает организованный нисходящий выбор и описание вариантов проектирования для всех важных системных функций и подфункций, для обеспечения совместимости и удовлетворения окончательных системных требований. Она содержит наиболее важные, связывающие весь проект, стратегические реализационные решения, изобретения, инженерные компромиссы; допущения и их соответствующие логические обоснования того, как система будет удовлетворять системным требованиям; все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Основные положения процесса разработки архитектуры:
1) каждая система имеет архитектуру;
2) архитектура определяет основные компоненты системы;
3) архитектура определяет обоснование компонентов и структуры;
4) архитектура определяет отношения компонентов структуры и их взаимодействия;
5) поведение компонентов является частью архитектуры;
6) определения архитектуры не фиксируют, что представляет собой компонент;
7) архитектура не является единой или единственной структурой.
Наиболее полезное описание архитектуры состоит из нескольких представлений, обеспечивая «интегрированное» представление о продукте.
Базовое представление архитектуры системы содержит описание систем и соединений, обеспечивающих или поддерживающих функции исполнения сценариев системы, включая графику.
Представление операционной архитектуры включает описание задач и действий, операционных элементов и информационных потоков, необходимых для выполнения или поддержки основной функции системы.
Представление технической архитектуры формулирует минимальный набор правил, регулирующих расположение, взаимодействие и взаимозависимость частей или элементов системы, целью которых является обеспечение соответствия системы удовлетворять заданному набору требований.
Описание архитектуры должно обеспечивать явные связи между различными представлениями, для интеграции облика и поддержки совместимости функций системы. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры». Пример одного из возможного множества изображений архитектуры самолета показан на рис. 6.
Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом.
Требованием называют заданную (ожидаемую) количественную или качественную характеристику или свойство объекта, а также связанные ограничения и условия (ГОСТ Р 59194—2020). Оно необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества).
Рис. 6. Вариант схемы архитектуры самолета
В стандарте ISO 9000 «Система менеджмента качества» сформулировано, что требование является документально изложенным критерием, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.
Требования к системе являются ключевым компонентом процесса ее создания. Требования определяют, что система должна делать и управляют ее развитием. Требования не являются спецификациями. Они определяют функции, характеристики и задачи системы в части окружающей среды. В процессе разработки системы, изображенном в виде итерационных петель (риc. 5), петля требований открывает цепочку базовых действий по созданию нового продукта. Есть несколько причин, зачем нужны требования.
• Требования определяют цель программы, например, получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши или получить прибыль от реализации проекта.
• Требования определяют нужды (проблемы) заинтересованных сторон, или иначе, бизнес-требования.
• Требования определяют вариант создания продукта, т.е. процедуры, регламенты, системные требования.
• Требования определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т. д.
Посредством требований уточняются формулировки или характеристики продукта, который разработчик хочет или должен получить. Требования также являются предметом договорных обязательств по созданию системы, составной частью документирования поставленной задачи, содержат значения, используемые при общении с заказчиком.
Технический процесс системного проектирования начинается с функциональных требований. В интересах разработчика сохранить как можно большую свободу проектирования. Затем функциональные требования обычно декомпозируют. При этом задача декомпозиции вводит новые входные и выходные данные и среду для исполнителя. Нужно минимизировать объем информации, которую приходится передавать между подсистемами. Функциональные спецификации нижнего уровня являются основой для закупок услуг по проектированию. Они записываются в виде границ. Например, указано, что масса продукта должна быть меньше или равна 25 кг.
Успех любой создаваемой системы и ее эксплуатации зависит от следующих факторов:
1) готова ли рыночная среда к внедрению системы (когда потребности рынка обусловлены «окном возможностей»);
2) как обеспечено позитивное восприятие пользователем функциональности, пригодности и доступности системы;
3) способность системы выполнять эксплуатационные требования пользователя (эффективность системы);
4) время возврата инвестиций (ресурсов, затраченных на эксплуатацию и обслуживание системы), т.е. экономическая эффективность продукта.
Правильная формулировка пакета требований к системе крайне важна для обеспечения перечисленных факторов прогнозируемого успеха, так как именно этот набор является основой формирования будущей системы. Этапы процесса системной инженерии включают также анализ и верификацию требований в разных частях жизненного цикла. При этом необходимо регулярно проверять трассировку требований «сверху вниз», т.е. влияние требований верхнего уровня на требования к подсистемам. Кроме того, требования уточняются на всех этапах процесса разработки.
К сожалению, плохо сформулированные требования являются главной причиной проблем на проекте. Требования определяют, что должно быть сделано, как хорошо и при каких ограничениях. Если разработчики получат неверные требования, проект и оборудование не будут работать. Требования являются причиной стоимости системы, бюджета проекта, графика работ, требуемых ресурсов, планов верификации, эксплуатационных процедур, т.е. всего в проекте!
Приоритетные требования (и связанные с ними ограничения и допущения) определяют решаемую проблему, они устанавливают, как будет определен успех проекта. Недопустимо, что многие команды начинают решать проблему до того, как достигнуто соглашение, что именно надо сделать.
В соответствии с иерархией структуры системы существует несколько уровней требований сверху вниз.
• Требования заинтересованных сторон являются верхним уровнем требований. Они отражают потребности пользователей, клиентов и других источников требований, таких как отраслевые, правовые, экологические нормы и требования высокого уровня внутри компании. В этих требованиях используют критерии качества для создания точного и понятного набора выполнимых и проверяемых требований, который является полным и последовательным.
• Системные требования расположены на следующем уровне. Их целью является установление точных технических требований для разработки системы. Системные требования основаны на требованиях заинтересованных сторон и их производных с учетом существующих технологий, компонентов и т. д.
• На нижеследующих уровнях формируют требования к подсистемам и компонентам. Целью этих требований является установление точных технических требований для разработки подсистемы или компонента. Они выводятся из системных требований с учетом существующих технологий, компонентов, интерфейсов и т. д.
Для инициации процесса формирования требований используют следующую информацию.
1. Исходные ожидания заинтересованных сторон, т.е. потребности, цели, результаты, допущения, ограничения, внешние интерфейсы для данного класса изделия.
2. Описание концепции эксплуатации для понимания системных целей, задач и ограничений. Включает сценарии, варианты использования и проектные задания.
3. Базовые стратегии поддержки для всех стадий ЖЦ (разработки, тестирования, производства, эксплуатации или утилизации конечного продукта).
4. Меры эффективности, т.е. соответствие результатов проекта критериям успеха (см. главу 3.8).
5. Другие данные. Например, для авиационных объектов все взаимодействия человека и системы, необходимые для эксплуатации, включая сборку, наземные операции, логистику, обслуживание в полете и на земле, эксплуатацию в полете и т. д.
Задача формирования требований в разных проектах может решаться разными путями. В начале процесса проводится выявление источников формирования требований. Каждый новый продукт реализует ряд специфических требований, которые позволяют сохранить конкурентоспособность на рынке. Некоторые источники формирования требований перечислены ниже.
•На высшем уровне полезно использовать опыт разработчиков по постановке целей. Следует организовать общение заинтересованных лиц и заказчика, которые нуждаются в соглашении с выработкой единого подхода к набору требований.
• Далее нужно определить цели и задачи программы (сформировать контракт на работу), установить допущения и ограничения, оговорить концепцию эксплуатации.
• Обсудить анализ проекта и маркетинг (вопросы сбыта продукции), уточнить матрицы критериев системы и выбранные приоритеты. Выполнить анализ иерархии, установить, какие функции должна иметь система и ее подсистемы для выполнения задач эксплуатации, провести предварительную декомпозицию и определить прослеживаемость требований на компоненты, оценить выявленные интерфейсы.
• Учесть руководящие документы для создаваемого продукта или системы, ГОСТ, ISO, федеральные и отраслевые нормы, и др.
• Определить границы системы и внешние интерфейсы. Уточнить влияние внешних систем на требования рассматриваемого проекта и стыковки по внешним интерфейсам (при наличии). Выявить эксплуатационное окружение, уточнить и задокументировать, какие дополнительные требования налагают внешняя среда и условия работы.
При выполнении анализа требования полезно классифицировать на основные типы:
A. Функциональные требования, отвечающие на вопрос «что система должна делать?». Например, обеспечить связь между землей и самолетом.
B. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?». К предыдущему примеру нужно определить применимый диапазон радиоволн, набор данных и как часто требуется выходить на связь.
C. Экологические и нефункциональные требования (сценарии использования), основанные на стандартах, отвечающие на вопрос «при каких условиях (экологии, надежности и доступности) система должна работать для удовлетворения данного требования?».
D. Ограничения системы. Точный характер ограничений может зависеть от предлагаемых решений. Так, выбранный вариант реализации заданных характеристик может вести к концепции проекта, которая скажется на росте массы конструкции. Или необходимо учитывать внешние интерфейсы, налагаемые другими системами (габарит мотогондолы на самолете, условия хранения, транспортировки, эксплуатации максимальная скорость у земли, температура, квалификационные требования по электромагнитной совместимости и др.).
E. Политика и публичные законы вносят ограничения по безопасности, экологии и шуму, важны для понимания, какие концепции полезны и практичны. Следует учесть угрозы, налагаемые известными возможностями потенциального конкурента, что ограничивает диапазон практических вариантов проекта. Если система предназначена для замены существующей, план перехода может учитывать дополнительные ограничения на концепцию и программу (например, трудоемкость ниже существующей, скорость производства выше и др.).
F. Требования к качеству (включая требования к безопасности).
G. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).
H. Требования к процессам жизненного цикла продукта, включающие административно-организационные требования (скорость выхода на рынок, послепродажное обслуживание и др.).
Подробные требования к проекту могут содержать следующие пункты.
1 Технические данные.
2 Планирование.
3 План управления системной инженерией (СИП).
3.1 Процесс системного проектирования.
3.2 Системный анализ и управление.
3.3 Технологические вопросы (процессы, оборудование).
3.4 Обеспечение технической интеграции.
4 Анализ эффективности.
4.1 Технологический анализ производства.
4.2 Анализ испытаний и верификации.
4.3 Анализ опытного производства и испытательных установок.
4.4 Эксплуатационный анализ сценариев расчетных и нештатных.
4.5 Анализ поддержки в эксплуатации.
4.6 Анализ обучения и соответствующего персонала.
4.7 Анализ процесса утилизации.
4.8 Анализ окружающей среды.
4.9 Анализ стоимости жизненного цикла.
4.10 Моделирование и цифровые двойники.
5 Детальный график системного проектирования.
6 Технические обзоры.
6.1 Планирование цепи обзоров.
6.2 Функциональные обзоры.
6.3 Обзоры системы по времени работ.
6.4 Организация сбора экспертных отзывов.
7 Структуру разбиения работ (СРР).
8 Требования к технической интеграции системы.
8.1 Надежность и ремонтопригодность.
8.2 Живучесть (где приложимо).
8.3.Электромагнитная совместимость.
8.4 Интеграция человеческих систем.
8.5 Безопасность системы для здоровья и воздействие на окружающую среду.
8.6 Безопасность системы от внешних воздействий.
8.7 Обеспечение качества.
8.8 Производство (технологические процессы, заготовки, инструменты, гибкие линии).
8.9 Интегрированную логистическую поддержку.
8.10 Испытания и оценки.
9 Прочие требования к разработке.
9.1 Приобретаемые компоненты (ПКИ).
9.2 Использование метрической системы.
9.3 Контроль деталей, включая поставки от подрядчиков.
9.4 Управление, связь и коммуникации.
9.5 Прототипирование.
10 Проверку инженерного менеджмента у подрядчиков.
Цепочка проектирования системы (продукта) включает несколько шагов определения и разработки требований.
• Определить и документально зафиксировать требования. Заинтересованные лица (включая заказчиков, пользователей и др.) формируют набор требований верхнего уровня, зачастую эти требования входят в техническое задание контракта на разработку системы.
• Провести анализ и декомпозицию полученных требований на нижележащие уровни системы для формирования указаний, необходимых исполнителям работ.
• Сформировать производные требования, вытекающие из заданных, для реализации детального проекта системы.
• Определить методы верификации требований.
Эти шаги могут выполняться параллельно, и, аналогично большинству технических процессов, реализуются посредством набора итераций.
При разработке требований рекомендуется формулировать простые утверждения. Требования включают обязательные характеристики, такие как «необходимый, проверяемый, достижимый технически, затраты, сроки». Т.е. каждое требование должно выразить одну мысль, быть кратким и простым, быть заявлено положительно, быть грамматически правильным; без опечаток и орфографических ошибок, быть понятным однозначно, должно использовать терминологию для обозначения системы (продукта) и ее частей более низкого уровня, соблюдать правила проекта (шаблонов и стилей), формат требования «кто хочет что».
Требование должно быть независимым от технической реализации, т.е. не содержать никаких технических деталей. Требование должно быть выполнимым, то есть должна быть возможность смоделировать, как требование может быть удовлетворено.
Для перевода требований заказчика в технические характеристики продукта часто используют процедуру развертывания функции качества (quality function deployment, QFD). Метод QFD представляет собой один из инструментов проектирования изделий и процессов, помогающий преобразовывать пожелания потребителя в технические требования к изделиям и процессам их производств. Основная идея технологии QFD заключается в том, чтобы связать потребительские свойства, надежность (т.е. фактические показатели качества) и установленные в стандартах параметры продукта (вспомогательные показатели качества), между которыми всегда существует большое различие.
Метод (https://clck.ru/3FNPmg) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуются в технические. Затем технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.
Например, при создании легкового автомобиля потребителю нужна тишина в салоне авто. Для технической реализации нужно уточнить следующие требования: снизить уровень шума мотора и коробки передач, применить шумопоглощающие уплотнения в перегородке салона, дверях, окнах, элементах кузова и др.
Одним из видов требований нижних уровней являются производные требования.
Производными называют требования, которые прямо не указаны в наборе требований заинтересованных сторон, но они должны быть сформулированы, чтобы удовлетворить одно или несколько конкретных высказанных требований. Их формируют на основе оперативного или технического анализа базовых требований в целях уточнения, или чтобы сделать базовые требования достижимыми.
Производные требования должны быть сформулированы и доведены до соразработчиков подсистем. Должны поддерживаться и контролироваться связи по всем уровням создаваемой системы, как «сверху вниз», так и «снизу вверх». Производные требования могут изменяться в результате изменений в дизайне, поэтому очень важно отслеживать, что откуда получено.
После сбора исходных требований верхнего уровня в процессе декомпозиции системы на подсистемы, модули и компоненты проводится декомпозиция требований на эти элементы с тем, чтобы после их создания и интеграции в продукт система в целом соответствовала требованиям верхнего уровня. Следуя функциональной архитектуре, декомпозицию и получение производных требований в ходе разработки проекта выполняют тремя способами: по потоку, распределением и ответвлениями. Декомпозиция требований вниз по потоку есть прямая передача их в подсистемы для обеспечения характеристик системы в целом. Распределение (при декомпозиции) представляет собой количественный пропорциональный дележ требований верхнего уровня на нижний уровень. Ответвление требований есть пропорциональная характеристика, зависящая от специфической реализации архитектуры системы.
Схема процесса декомпозиции требований изображена на рис.7.
Рис. 7. Этапы декомпозиции требований
На рисунке процесс движется слева направо. На шаге 1 установлены возможности системы (выставленные исходные требования). На шаге 2 проводится декомпозиция требований верхнего уровня по функциям системы, формируются производные и «дочерние» требования. На шаге 3 требования к функциям привязывают к подсистемам и компонентам системы.
Распределение требований при разработке системы можно разделить на вертикальное и горизонтальное. Вертикальное распределение отражает разложение требований с верхнего уровня системы на уровень подсистемы, далее на уровень оборудования и т. д. Горизонтальное распределение относится к соответствию между требованиями и элементами архитектурного дизайна на одном уровне.
Прослеживаемость (трассировка) и иерархия требований также являются важными компонентами управления требованиями. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками для проверки происхождения и правильности формулировки. Анализ прослеживаемости является эффективным методом контроля и обнаружения противоречий и совпадений требований.
При рассмотрении вышеуказанных вопросов производных требований важным является уточнение набора интерфейсов системы. Интерфейс описывает связь между двумя функциями или процессами, фактически отражая часть требований к системе. Интерфейсы в системе появляются при ее сопряжении с внешними системами (соединение частей комплекса с бортовыми системами, линии связи авионики с наземным центром управления полетами и др.), либо при ее декомпозиции при распределении работ, либо при разделении элементов конструкции на модули и компоненты в зоне ответственности конкретного субподрядчика. Существуют разные типы интерфейсов: механические (компоненты физически стыкуются друг к другу); электропитание (напряжение и токи между подсистемами); электронные (характеристики электрических сигналов между системами); данные (формат и содержание информации, передаваемой между подсистемами); тепловые (тепловые потоки между подсистемами); программное обеспечение (связь модулей или оборудования).
При стыковке участков работ разных команд в системе возникает множество интерфейсов. Их появление связано с наличием группы проектных команд, участием разных производителей агрегатов и поставщиков, использованием нескольких сборочных площадок, разделением работ внутри отдельных команд.
Примеры стандартных интерфейсов (механические и шины данных) показаны на рис. 8.
Рис. 8. Примеры интерфейсов
Требования к интерфейсам должны удовлетворять определенным правилам для исполнения задаваемых функций.
1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.
2. Функции, характеристики, ограничения и допущения этих интерфейсов должны быть определены и зафиксированы в требованиях к интерфейсам.
3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.
4. Требования к интерфейсу определяют функциональные, физические, характеристические, электрические, экологические, человеческие требования и ограничения, которые существуют на общей границе между двумя или более функциями, элементов системы, элементов конфигурации или систем.
5. Требования к интерфейсу включают логические и физические интерфейсы.
6. Функциональные и ресурсные распределения по подсистемам влияют на требования интерфейса. В качестве примера рассмотрим сжатие данных. Эта функция может быть выделена либо в радиолокационной подсистеме, подсистеме обработки данных или подсистеме связи.
Интерфейсы можно классифицировать на внешние и внутренние (по отношению к системе в целом или по отношению к области работ конкретного подрядчика). Разделение на внутренний и внешний интерфейсы внутри системы зависит от положения исполнителей в цепочке «заказчик-поставщик».
Внешние интерфейсы образуют границы между системой и окружением. Требования системного уровня к внешним интерфейсам установлены вместе с другими требованиями системного уровня. То есть требования к внешним интерфейсам, как и другие функциональные и эксплуатационные системные требования, распределяются по подсистемам через исходные данные, производные или вниз по потоку.
При декомпозиции системы появляется определенное количество внутренних интерфейсов, необходимых для установления связи между двумя функциями или процессами внутри системы. Типы и характеристики всех интерфейсов должны быть идентифицированы и определены. Внутренним называют интерфейс, контролируемый данным конкретным исполнителем ОКР. Например, интерфейс между двумя поставщиками, работающими по контрактам с головным исполнителем, будет для обоих поставщиков внешним. При этом для проекта головного предприятия данный интерфейс будет внутренним.
Требования для внутренних интерфейсов отличаются тем, что они создаются в рамках декомпозиции системы. Различные решения системы, то есть варианты распределения требований будут приводить к созданию разных подсистем и их интерфейсов. Эта дополнительная задача интеграции системы одновременно предоставляет мощную возможность для разработчиков оптимизировать конструкцию системы.
Требования к интерфейсам, как часть системных требований, должны быть идентифицированы во время определения системных решений. Они фиксируются в моделях функциональной и физической архитектуры, уточняются на совещаниях заинтересованных лиц. Для систем высокой сложности спецификации и планирование разработки и управления интерфейсами должны следовать структурированному подходу путем определения всех ключевых подсистем внутри общей системы и размещения их в матрице строк и столбцов N
, где каждый элемент матрицы представляет собой технический или системный интерфейс для управления.
Определение, управление и контроль интерфейса включают управление внутренними и внешними интерфейсами различных уровней продуктов и задач для поддержки интеграции продукта. Основные задачи заключаются в следующем:
a) определить интерфейс и его характеристики (физические, электрические, механические, человеческие и т.д.);
b) обеспечить совместимость интерфейса со всеми сопряженными интерфейсами, используя процесс, документированный и одобренный в проекте;
c) разработать документ управления интерфейсом;
d) определить монтажные чертежи или другую документацию, которая включает полную конфигурацию интегрируемого продукта, список деталей и инструкции по сборке;
e) определить требования к конечным продуктам, требованиям, определенным в проекте, а также конфигурационную документацию для структуры разбиения работ проекта, включая спецификации интерфейса, в форме, подходящей для процесса управления конфигурацией.
Ответственным за определение, разработку и верификацию интерфейса является заказчик продукта или его представитель. Для документирования интерфейса и постановки под управление конфигурацией должны быть оформлены основные документы интерфейса.
•Документ требований интерфейса определяет функции, характеристики, электрику, экологию, персонал, физические требования и ограничения, которые существуют на общей границе между двумя или более функциями элементов системы, элементов конфигурации или систем.
• Документ определения интерфейса является односторонним, контролируется поставщиком и предоставляет подробную информацию об интерфейсе для проектных решений, которые уже установлены. Разработчик должен спроектировать интерфейс системы, совместимый с уже существующим ответным элементом.
• Документ управления интерфейсом (ICD) излагает детали интерфейса между двумя элементами системы: числа и типы разъемов, электрических параметров, механических свойств, а также экологических ограничений, определяет дизайнерское решение на требование интерфейса.
Набор из трех документов, как правило, делается в усеченном варианте, часто используют только документ управления интерфейсом с введением отдельных данных из других документов. В документе ICD указаны персонально сотрудники, ответственные за интерфейсы (по одному на каждый, один владелец может быть у нескольких интерфейсов).
Документ «Требования к интерфейсу» входит в общий набор требований к системе, подпадает под управление конфигурацией и входит в общую контрольную «Матрицу соответствия требований к системе или продукту», верифицируемую на этапах разработки. Другие два документа интерфейса могут существовать в общем потоке документов системы по принадлежности. Отечественный и зарубежный опыт разработки высокотехнологичных систем показывает, что на проекте интерфейсы сложной системы (внешние и внутренние) нуждаются в дополнительном контроле, так как являются источником большого количества нестыковок как в ходе разработки проекта системы, так и на этапах ее интеграции и валидации.
Хорошие требования к системе или продукту должны быть:
a) специфичными, т.е. отражать только один аспект конструкции или характеристик системы, и должны быть выражены в терминах необходимости (что и как хорошо), а не решений (как);
b) измеримы, т.е. характеристика выражается объективно и количественно (например, точное требование, указывающее температуру детали в градусах, может быть проверено при испытании);
c) достижимы, т.е. технически реализуемы при доступных затратах;
d) соответствовать указанному уровню подсистемы (например, требование наличия солнечных батарей спутника не входит в уровень требований ракеты-носителя, а только в требования для подсистемы полезного груза);
e) прослеживаемыми, т.е. требования нижнего уровня (младшего, дочернего) должны четко вытекать из поддержки требований более высокого уровня (старшего, родительского). Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.
Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует «избегать» в тексте требований:
1) хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;
2) «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;
3) помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;
4) рассуждений и нечетких слов («обычно», «в основном», «часто», «нормально», «типично»);
5) использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);
6) принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).
Приведем несколько примеров требований, с точки зрения того, хорошо ли они изложены.
•Самолет должен иметь три двигателя (исходное требование для DC-3). Позже выяснилось, что самолет должен отвечать требованиям эксплуатации при отказе одного двигателя.
• Разработчики смартфонов ставили своей целью улучшить технику для телефонных звонков. Однако пользователи стали выбирать смартфоны по опции связи и мультимедиа в мессенджерах и качеству снимков фотокамеры, т.е. по ранее вспомогательным критериям.
• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Оказалось, что после срабатывания системы огонь успешно ликвидируется, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 9). Видимо, предполагалось, что она будет сливаться в водостоки. Пришлось вносить в систему доработки.
На практике нередко встречаются отклонения от требований. Для дальнейшего продвижения в проекте необходимо указать причины отклонений. Как правило, это следствие отсутствия части информации. В документах встречаются места, оставленные для заполнения в дальнейшем. В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен. Важно знать при формулировке раздела требований в англоязычных контрактах, что слово «Compliance» является единственным вариантом подтверждения строгого соответствия исполнителя требованиям контракта.
Рис. 9. Срабатывание системы пожаротушения
Также на этапе разработки требований необходимо определить методы их верификации. С целью безусловного выполнения требований проекта необходимо организовать поэтапную верификацию исполнения требований к системе, начиная с момента появления предварительного облика разрабатываемой системы (на контрольном рубеже с обзором предварительного проекта системы).
Валидация требований часто входит в один из этапов ворот принятия решений. Проверка требования включает четыре типовых вопроса.
•Правильная ли сформулирована проблема?
• Смогли ли указанные требования отразить проблему?
• Верно ли сформулированы эти требования?
• Соответствуют ли требования установленным границам системы и ограничениям?
В процессе валидации требуется проверить, что системные требования полны, непротиворечивы и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители Заказчика.
В результате процесса разработки формируется набор требований к системе, который должен быть выполнен при создании продукта или системы. Он содержится в документах контракта, спецификациях или технических заданиях на выполнение работ. Характеристики этого набора требований будут идентичны вышеописанным характеристикам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным (т.е. не нуждается в дополнительных пунктах требований). Входящие в него требования должны быть согласованными (т.е. не содержат противоречий, дублирований и др). Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 3.4).
На основании требований системного уровня выполняется функциональный анализ системы, то есть разработка функционального описания системы, которое послужит основой для определения ресурсов, необходимых системе для достижения ее целей. Функцией называют конкретное или дискретное действие (или их серию), необходимое для выполнения системой своей задачи, или действие по техническому обслуживанию, необходимое для восстановления работоспособности системы.
Функциональный анализ включает итеративный процесс разбиения требований от уровня системы до подсистем и вниз по иерархической структуре, насколько это необходимо для определения входных критериев проектирования и ограничений для различных элементов системы. Требования верхнего уровня идентифицируют, разделяют на второй и далее уровни вниз до глубины, необходимой для целей определения элементов системы.
Одной из целей функционального анализа является обеспечение прослеживаемости от требований верхнего уровня системы до требований к рабочему проектированию. Учитывая конкретные требования к оборудованию, можно двигаться «вверх» для обоснования этого требования. Функциональный анализ должен обеспечить механизм прослеживаемости «снизу вверх».
При оценке каждого функционального требования альтернативы могут включать выбор ПКИ, количество различных источников поставок, и элементы разработки, для которых требуется какая-то новая конструкция.
Функциональный анализ, в частности, формирует основу для разработки:
a) электрического и механического проектирования компонентов мониторинга состояния и средств диагностики;
b) моделей надежности;
c) анализа характера, последствий и критичности отказов;
d) анализа технического обслуживания, ориентированного на надежность;
e) анализа ремонтопригодности;
f) анализа человеческого фактора;
g) анализа безопасности и рисков системы;
h) логистического анализа (анализа цепочки поставок).
2.5. Принятие проектных решений
Следующим этапом процесса разработки является синтез системы, в ходе которого конструктор переводит функциональную архитектуру системы в физическую. Процесс сопровождается принятием множества проектных решений, где конструктор должен проявить как творческую сторону деятельности, так и профессиональный прагматизм. Термин сбалансированное решение означает, что проведено обсуждение общих рисков системы, стоимости, технической зрелости и надежности для каждой комбинации подсистем.
Основные принципы проектирования изделий можно свести к краткому перечню.
•Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. Лучшее – враг хорошего.
• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски и стоимость и обеспечить легкую реализацию и эксплуатацию.
• Излишние опции в проекте должны быть определены на ранней стадии (и удалены из целей системы), при этом влияние на характеристики продукта, вытекающие из осуществления этих опций, должно быть понятным.
• В проекте обязательны независимые обзоры промежуточных результатов для всестороннего обсуждения вопросов разработки.
Важно принимать во внимание информацию о том, что основные затраты на этапе разработки связаны с передачей в производство образцов и закупками ПКИ, тогда как уровень этих затрат определяется на раннем этапе, при разработке конструкторской документации. Т.е. принятые на ранней стадии решения являются ключевыми и определяют стоимость программы на последующих этапах ЖЦ.
Ниже суммированы некоторые полезные рекомендации, приносившие успешные результаты при проектировании изделий и систем. Каждый читатель может привнести в них свой уровень детализации, создавая базу уникальных шагов для нового проекта:
1) использовать модели для проектирования систем;
2) использовать иерархический дизайн сверху вниз;
3) сначала выполняется работа с высокорисковыми компонентами;
4) конструировать минимум интерфейсов, разделяя их на механические, электрические, программные;
5) применять в альтернативах проекта удовлетворительные конструкции;
6) рекомендуется не проводить оптимизации на ранней стадии работ, пока нет уверенности, что база оптимизации выбрана достаточно обоснованно;
7) свои ошибки нужно находить самим, т.е. определить, что не так в очередном варианте;
8) полезно перечислить функциональные требования в случае использования системы;
9) выделить каждую функцию для только одного компонента;
10) категорически нельзя использовать недокументированные функции;
11) полезно применять быстрое прототипирование (варианты аддитивных технологий);
12) разрабатывать несколько итераций и сразу тестировать результат;
13) создавать библиотеки повторно используемых субъектов;
14) написать глоссарий соответствующих терминов;
15) удобно использовать создание конструктивных резервов (запасы);
16) следует проектировать компоненты с возможностью тестирования;
17) выполнять анализ чувствительности конструкции для альтернативных вариантов;
18) изменять поведение людей в команде для достижения результата.
Процесс определения проектного решения используется для перевода требований высокого уровня, полученных от ожиданий заинтересованных сторон, и результатов логического процесса декомпозиции в реализуемое решение. Производные технические требования используют для выбора альтернативных решений. Затем эти альтернативные решения анализируют для определения предпочтительной альтернативы. Выбранная альтернатива служит базой конечного проектного решения, которое удовлетворяет техническим требованиям.
Процесс принятия системного решения является совместным, итеративным и основанным на ценностях, который можно применять на любой стадии жизненного цикла системы для максимизации вероятности успеха.
Можно выделить несколько присущих характеристик процесса.
• Процесс решения охватывает динамический поток работ по проектированию системы и эволюцию ее состояния, начиная с текущего статуса (как есть) и заканчивая системой, которая приносит пользу заинтересованным сторонам (как должно быть).
• Этот совместный процесс фокусируется на ценности, потребностях и целях заинтересованных сторон и лиц, принимающих решения (ЛПР), обеспокоенных ценностью, предоставляемой системой. Заинтересованные стороны и ЛПР определяют важные функции, цели, требования (критерии отбора, которым должны соответствовать все потенциальные решения) и ограничения.
• Процесс принятия решения состоит из четырех последовательных этапов (определение проблемы, разработка, принятие и реализация решения), которые охватывают системное мышление и применяют проверенные подходы к системному проектированию, как правило, посредством итераций.
• Самая важная задача в любом процессе принятия системных решений: идентифицировать и понять проблему, которая определяется пониманием задач, целей и ограничений от ЛПР и заинтересованных сторон.
• Целевым для процесса является создание ценности (моделирование, генерация идей и усовершенствование вариантов) в дополнение к оценке и анализу чувствительности альтернатив. Ценности должны быть движущей силой принятия проектных решений для оценки фактических или потенциальных последствий действий и бездействия, предлагаемых альтернатив и решений.
Например, процесс принятия решения технической проблемы появления дефекта рекомендуется продвигать по следующим шагам:
1) наблюдаемые симптомы;
2) определение проблемы;
3) целевой результат;
4) анализ основной причины;
5) количество компонентов в эксплуатации;
6) частота отказов среди этих компонентов;
7) происходит ли сбой равномерно по всей совокупности или он связан с конкретной партией изделий;
8) связан ли отказ с конкретным пользователем или рабочим циклом;
9) предлагаемое решение;
10) план действий;
11) результаты плана действий;
12) подтверждение решения;
13) уроки на будущее.
Такой организованный подход к решению помогает участникам обсуждения, в том числе более опытным, внести свой вклад. В литературе существует большое количество рекомендаций по подобным алгоритмам принятия решений.
Вовлекаемый в процесс выработки решений опытный критический мыслитель должен обладать следующими качествами:
a) поднимает важные вопросы и проблемы, формулируя их четко и ясно;
b) собирает и оценивает соответствующую информацию, используя абстрактные идеи и объективные данные для ее эффективной интерпретации;
c) приходит к обоснованным выводам и решениям, проверяя их на соответствие заданным критериям и стандартам;
d) думает непредвзято в рамках альтернативных систем мышления, признавая и оценивая, при необходимости, их предположения и практические последствия;
e) эффективно общается с другими коллегами, находя решения сложных проблем;
f) осознает человеческие ошибки при принятии решений и компетентен в использовании статистических методов для получения обоснованных выводов.
На этапе подготовки проекта плановый объем основных требуемых решений предлагается типизировать и расставить очередность в предпочтительном порядке по приоритетам. Приоритизация работ является важным элементом процесса, так как позволяет сосредоточиться на главных компонентах и подсистемах. При разработке нужно расставлять приоритеты на все факторы (требования, цели, нужды и ожидания потребителей, возможности, риски, директивы, инициативы, вопросы, мероприятия, варианты, функции, прецеденты, измерения технических характеристик и веса важности для критериев в маркетинговых исследованиях). Ранжирование помогает упростить решение вопросов с бюджетом, графиком, архитектурой системы, удовлетворенностью клиентов и снижением рисков.
Одной из основных задач при разработке системы является принятие решений по архитектуре системы. Лицо, принимающее решения (ЛПР), поставленное в ситуацию, когда решение необходимо принять, должно всегда выбирать, основываясь на явных или скрытых критериях оценки этого решения, то есть сознательный и обдуманный выбор критериев является жизненно важным в процессе принятия решения. Обязанностью ЛПР является получение согласованных решений проекта на этапе их принятия с учетом того, что все участники процесса имеют отличающиеся приоритетные цели в программе. При этом следует помнить, что в инженерных задачах возможно, как правило, наличие двух и более вариантов решения.
При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:
•когда решение связано с умеренным или высоким риском по результату;
• когда решение влияет на управление конфигурацией;
• когда результат решения может привести к значительным задержкам графика работ;
• когда результат решения может привести к значительным перерасходам;
• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости ПКИ.
Следует принимать во внимание, что каждое конкретное решение имеет свою «стоимость» в части объема затрат на реализацию. Схематично можно выделить четыре фазы зависимости «характеристика – ресурсы» (рис. 10). Здесь под стоимостью понимаются затраты любого ресурса (не только финансового).
Рис. 10. Кривая «стоимости» проектных решений
A. Рост характеристики от 0 до 1 дает ее заметное улучшение при минимуме затрат ресурса.
B. Рост характеристики 1—2 обеспечивает эквивалентный прирост характеристики на единицу затрат.
C. В приросте характеристики от 2 до 3 заметные затраты приводят к некоторому улучшению характеристики, но процесс сопровождается увеличением риска.
D. Рост характеристики выше 3 уровня показывает, что там невозможно получить улучшение характеристики при любом вложении ресурса.
Выбор набора базовых проектных решений, например, в компании Airbus выделен в отдельный этап и может длиться от 3 месяцев до 1,5 лет. В процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. В ходе этапа проводится принятие базовых решений по выделенному перечню концептуальных мест проекта, составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Этот руководящий документ служит защитой от принятия отдельными участниками ошибочных легковесных решений на этапах.
Традиционно процесс разработки каждого элемента конструкции является итерационным. С целью упорядочить данный процесс применяется, в частности, выделение трех уровней принятия решений (уровней зрелости конструкции). В ходе такого процесса проводится трехстадийная разработка эскизных компоновок проектных решений по всем основным местам конструкции. На первом уровне проводится вариантный отбор. Для определения последующих альтернатив применяются соответствующие критерии: масса, прочность, технологичность, ремонтопригодность, стоимость, возможности унификации. На втором и третьем уровнях зрелости проектных решений соответственно уменьшается число вариантов и возрастает глубина проработки конструкции. По трехмерной модели считают запасы прочности. При выявлении несоответствий требуется уточнить матрицу нагрузок, либо усилить конструкцию, либо изменить проектное решение.
При переходе от уровня к уровню по зрелости частных решений также идет сужение масштабов решений от системы в целом к деталям и компонентам (рис. 11).
Рис. 11. Схема реализации проектных решений
Общий процесс системного решения необходимо адаптировать к системе, решению и этапу жизненного цикла системы. Для достижения нужного качества решения полезно следовать нескольким принципам.
• При формировании будущего решения нужно учитывать масштаб проблемы и все потребности заинтересованных сторон.
• Следует выбирать творческие и осуществимые решения, которые создают ценность для заинтересованных сторон и лиц, принимающих решения.
• Значимые данные, используемые для генерации и оценки возможных решений, должны быть обоснованными, понятными и заслуживающими доверия.
• Для генерации и оценки решений необходимо провести анализ компромиссов между системными требованиями, показателями ценности и ресурсами.
• Реализация решения является одним из самых сложных этапов процесса. Для этого необходимо выявить и устранить препятствия и риски. Избегать искушения слишком поспешного выбора решения. Критически важным для принятия системных решений является учет окружающей среды, ее факторов (технологических, безопасности, экологии и экономики) и взаимодействующих систем, в которой работает продукт или система.
При принятии решений проекта важно точно формулировать цели и объемы их исполнения. При работе с европейскими авиастроителями нашей команде был предложен проект переделки списанных пассажирских самолетов в грузовые. Исходный самолет был спроектирован в бумажных чертежах, а новые чертежи нужно было делать в электронном виде. Попытки оформить предложения по правилам выпуска новой документации в проекте (для минимизации переделки серийных деталей старой конструкции) не были услышаны. Заказчики потребовали при наличии сопряжений между старой и новой деталью оцифровывать их обе. При этом формально появлялась новая деталь для конструктора и для производства. В итоге контракт был подписан на доработку по трудоемкости 30% конструкции, а по факту получилась переделка планера на 70%. Пришлось оформлять соглашение о частичной компенсации затрат на дополнительные работы. В принятии неверного решения были виновны обе стороны. Заказчики ошибочно оценили допущения по технике предлагаемых работ и выделенный бюджет, у исполнителя не получилось внятно и вовремя донести опасения до партнеров.
Процесс принятия решений может включать следующие этапы.
1. Определение альтернативных решений для проектирования. Если они определены и полностью понятны, тогда выбор можно сделать с уверенностью. Процесс должен обеспечить наиболее функциональную, безопасную и экономичную конечную систему, в границах графика проекта. Следует оценить зрелость требуемой технологии и ожидания заинтересованных сторон для эффективной эксплуатации.
2. Создание альтернативных концепций дизайна. По возможности, каждая из них должна рассматриваться в рамках широкого класса разумных конструкций. Потенциал для изменений может включать также организационную структуру, ограничения персонала, графики, процедуры и любые другие элементы, составляющие систему. Нужно определить для узлов, что лучше: сделать самим, повторно использовать или купить компонент (подсистему).
3. Анализ альтернативных проектных решений. Далее техническая группа анализирует, насколько хорошо каждая из альтернатив проекта соответствует целям системы (технологическая зрелость, эффективность, техническая достижимость, производительность, стоимость, и риск). Эта оценка осуществляется с помощью маркетинговых исследований. Следует оценить эти альтернативы с точки зрения стоимости ЖЦ системы. Для определения количественных параметров полезны математические модели. Выбранные альтернативы ранжируют в соответствии с установленными критериями отбора. Стоимость всегда является ограничивающим фактором. Однако также важны такие критерии, как время разработки, риск и надежность. Полезно оценить возможности выбора инструментов проекта и поставщиков.
4. Выбор лучшей проектной альтернативы. Эксперты выбирают лучшее решение из альтернативных концепций дизайна, принимая во внимание субъективные факторы, которые команда не могла определить количественно, например надежность. Важны также оценки того, насколько эти альтернативы соответствуют количественным требованиям: эффективности, стоимости, графику, рискам или другим ограничениям. Процесс анализа принятия решений, который описан в главе 3.9, должен использоваться для оценки альтернативных концепций дизайна и рекомендации наилучшего решения для проектирования.
5. Выбор и верификация решения для проектирования. После выбора предпочтительной альтернативы дизайна определяется окончательное решение, которое будет удовлетворять техническим требованиям и концепции эксплуатации системы. После того как решение было выбрано и задокументировано в пакете технических данных, оно должно быть верифицировано на соответствие системным требованиям и ограничениям. Нужно показать, что удовлетворены требования верхнего уровня и ожидания заинтересованных сторон.
6. Валидация проектного решения. Она отличается усеченной полнотой требований от валидации конечного продукта. Оперативная валидация может включать вопросы.
• Работает ли система так, как ожидалось?
• Как система реагирует на сбои, сбои и аномалии?
• Доступна ли система?
Если ответа на любой из этих вопросов нет, тогда потребуются изменения в проекте и процесс начнется снова.
7. Идентификация обеспечивающих продуктов. Обеспечивающими называют продукты и услуги поддержки жизненного цикла (например, производство, тестирование, развертывание, обучение, обслуживание и утилизация), которые облегчают продвижение и использование конечного продукта в течение его жизненного цикла. Поскольку конечный продукт и его поддерживающие продукты взаимозависимы, они рассматриваются как единая система. Поэтому важной задачей в процессе определения проектного решения является идентификация предоставляемых продуктов и персонала, которые понадобятся в течение жизненного цикла выбранного проектного решения.
Результаты процесса определения проектного решения рекомендуется документировать.
• Спецификации конечных продуктов, которые представляют собой подробные описания конструктивных особенностей, включая материалы, размеры и качество работы для сборки, установки или производства конечного продукта.
• Спецификации интерфейса конечного продукта, которые содержат подробные требования к построению и кодированию поведения и характеристик всех логических и физических интерфейсов, которые конечный продукт имеет с внешними элементами, включая интерфейсы человек-система.
• Начальные спецификации подсистем, которые предоставляют подробную информацию, если требуется.
• Требования к обеспечивающим продуктам, в которые входят продукты поддержки жизненного цикла, инфраструктура, персонал, логистика и услуги, которые облегчают продвижение и использование эксплуатации конечного продукта в течение его жизненного цикла.
• План верификации продукта, который включает квалификацию, приемку, предварительную, оперативную и операционную проверку действий для аппаратного и программного обеспечения.
• План валидации продукта, где включены процедуры и среда валидации, для подтверждения того, что реализованный конечный продукт соответствует ожиданиям заинтересованных сторон.
• Планы логистики и оперативных процедур, включая обработку, транспортировку, послепродажное обслуживание, и обеспечение длительного хранения для конкретного проектного решения.
Пример критериального решения показан для выбора места рабочего обеда. Назначены три критерия: расстояние до кафе (пункта питания), качество пищи и ее стоимость. В результате опроса группы сотрудников получены относительные оценки критериев в баллах. Далее проведена операция нормирования результатов, чтобы перейти к весовым коэффициентам в долях единицы (колонка справа в таблице 1).
Таблица 1
Можно видеть, что в результате критериального выбора наивысший весовой коэффициент получило кафе, расположенное ближе других. Тогда как факторы качества пищи и ее стоимости оценены существенно ниже.
Роль команды проекта заключается в тщательной подготовке материалов, на основании которых может быть принято наиболее эффективное решение. Не следует сожалеть о результате после принятия решения. Для процессов создания сложных систем часто имеется целый набор решений, близких к оптимальному. Изменение результата можно рассматривать только в рамках повторного прохождения итерационных циклов проекта либо по результатам последующего технического обзора, если выяснится, что при принятии решения не были учтены существенные факторы проекта. Очевидные выводы предостерегают от излишнего увлечения непроверенными решениями.
В каждом проекте наступает момент принятия решения о заморозке документации. После него дальнейшие изменения в дизайн продукта не могут быть внесены без финансового риска, особенно если затем проект должен быть отправлен в производство. Заморозка проекта имеет преимущество, заключающееся в минимизации последующих изменений проекта. Она также может быть необходима для своевременной закупки товаров с длительным сроком поставки, таких как заготовки, ПКИ и инструменты, необходимые для производства конечного продукта. Несоблюдение точек замораживания при проектировании оказывает значительно большее влияние на подготовку производства, чем на инженерное проектирование. После заморозки решения об изменениях принимает только руководство проекта.
Необходимы некоторые разъяснения по поводу новизны принимаемых решений, а именно, нужно ли изобретать в проекте? На основе результатов статистического исследования сделан вывод, что большинство концепций и проектов есть модификации предыдущих с относительно малой новизной (Г. Альтшуллер, автор Теории Решения Изобретательских Задач). Их следует разыскивать первыми. В качестве примера можно привести появление в 2010 г. на рынке планшетного устройства, завоевавшего умы покупателей в возрасте от 3 до 90 лет, в конструкции которого не было использовано ни единого нового компонента.
Еще одним важным вопросом принятия проектных решений является применение правила копирования при использовании компонентов, модулей, подсистем, покупаемых готовыми на рынке (ПКИ):
a) любое использование заимствованных частей изделия проверяется на качество и верифицируется также, как новое оборудование;
b) при проверках обязательно учитываются доработки проекта, изменения в эксплуатационных требованиях и условиях относительно указанных в технических условиях на ПКИ;
c) должен быть приложен набор документов, требуемых для обоснования применения ПКИ в конкретном проекте;
d) не следует проверять компоненты с рынка через теорию подобия, необходимо использовать традиционные верификационные методы: испытания, анализ, проверки.
Перечисленные правила связаны с тем, что покупные изделия разработаны для других программ, отличающихся условиями применения, ресурсом, входными данными и др. Отметим, что следует обдуманно применять в конструировании оптимизационные методы математического анализа. Как правило, математический оптимум не является лучшим инженерным решением. В пространстве поиска существует область параметров вблизи, лучше удовлетворяющих часто противоречивому набору требований проекта, в том числе стоимости и сложности исполнения.
Например, вследствие выстроенного хаотично процесса конструирования был получен перегруженный узел конструкции «парашютный замок» (используемой для закрепления лямок ранцевого парашюта на груди парашютиста). Пересмотр с позиций системной инженерии привел к уменьшению количества деталей с 46 (включая 20 резьбовых и заклепочных соединений) до 7 (2 соединения), снижению массы на 25% при увеличении разрешенной нагрузки вдвое (с 160 до 320 кг силы), себестоимость при этом снизилась на 50%.
2.6. Синтез системы
На основании принятых решений завершается выполнение проекта (синтез) и процесс интеграции системы. Синтез открывает содержание «как» для каждого пункта «что» и «как хорошо». Продукция синтеза системы включает базовую физическую архитектуру (как спроектировано) и результаты маркетинга подсистем. Место синтеза в общем процессе СИ показано на рис. 5.
На этапе синтеза продукта эффективно применяют интеграционную методологию параллельного инжиниринга. Это систематический подход различных специалистов, сотрудничающих одновременно в общей среде, реальной или виртуальной, для создания совместного дизайна, достигая сокращения времени цикла разработки продукта за счет лучшей интеграции мероприятий и процессов. В рамках параллельного инжиниринга обеспечивается общая инфраструктура инструментов, данных и поддержки информационных технологий, образуя интегрированную среду поддержки для использования командой. В совместной среде ключевые участники могут исследовать предположения и альтернативы с группой заинтересованных сторон или другими членами команды дизайнеров, и быстро переориентировать всю команду, когда происходит изменение дизайна.
Успех параллельной инженерии основан на деятельности талантливой и опытной группы инженеров и ученых, которые составляют команду, где поддерживаются соответствующие инструменты и средства, чтобы сделать свою работу более эффективно. Основные ключевые позиции в команде: заказчик, руководитель по исследованиям, системные интеграторы, инженеры подсистем (включая экспертов по рискам и расходам). При этом группа инженеров напрямую взаимодействует с заинтересованными сторонами для облегчения проектирования, а клиент становится активным участником процесса разработки. Менеджер проекта должен понимать разницу между совместной работой в общем помещении и распределенной (часто удаленной) работой. Для последней требуются дополнительные организационные усилия в части управления, инструментов и коммуникационных технологий.
Важнейшим элементом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. На ЭМИ разрабатывают чертежи и сборки, а также управляют комплектом документации. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения в ГОСТ 2.051…2.058. Он создается и направляется системой управления данными о продукте, которая поддерживает выпуск технической документации и управление конфигурацией изделия.
ЭМИ сегодня служит главным инструментом общения инженерных команд и фундаментом диалога проектантов с производством. Вокруг ЭМИ строятся регулярные совещания по статусу проекта, вместо затратных физических макетов, применявшихся ранее. Организация процесса коммуникации между командами, участвующими в проекте, и внутри команд лежит в зоне ответственности менеджера проекта. Очень важно не допустить сбоев в параллельном инжиниринге из-за распространения неверной или запаздывания правильной информации и данных, что повлечет переделку части работ и финансовые потери.
В ЭМИ могут быть включены технические данные системы, 3-Д модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Например, трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства (используемые инструменты, материалы, технологии, средства контроля и т.д.), результаты расчетов различными средствами CAE, данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов в производстве.
Электронный макет соответствует текущему этапу жизненного цикла продукта и в авиастроении включает обычно три уровня проработки (рис. 12).
Рис. 12. Три этапа «зрелости» ЭМИ
Исходной является мастер-геометрия обводов самолета (теоретические профили аэродинамики). Макет ЭМИ-1 используется для предварительных компоновочных решений по продукту и включает все внешние формы самолета или секции, основные геометрические сведения о силовом наборе (рамы, стрингеры, шпангоуты и лонжероны), важные интерфейсы, системы координат, необходимые для позиционирования подсборок между собой, общие виды.
Принятые решения пересылаются и проверяются на следующей стадии ЭМИ-2. Это макет распределения внутренних объемов самолета под компоненты и агрегаты, который служит для проработки использования допустимого пространства внутри самолета при его заполнении конструктивными элементами, определения расположения подсистем и частей оборудования, проверки их взаимной увязки. ЭМИ-2 определяется трехмерными моделями частей изделия, позиционированными в пространстве, причем система управления данными следит за соблюдением связи между геометрией и конфигурацией продукта. Инженеры проверяют взаимную предустановку частей, систем и оборудования, удобство их монтажа и обслуживания. Следующим важным этапом проектирования на ЭМИ-2 является пространственная увязка расположения систем, частей и деталей, уточнение возможности сборки при производстве, а также интерфейсы.
На базе 3-Д моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства. Компоненты РКД включают 3-Д модели и сборки согласно ЭМИ, производственные чертежи, спецификацию (график работ), извещения об изменениях, алфавитную базу данных проекта для справочных нужд. Все чаще на сложных изделиях вместо РКД передают в технологическую службу образмеренные (аннотированные) 3-Д модели деталей, согласно стандартам ISO 16792:2015, ASME Y14.41—2012, MIL-STD-31000A.
Разработанная и скорректированная рабочая документация служит основой для финального макета изделия ЭМИ-3 (справочная геометрия, сертификация). Этот макет строится в завершающей стадии конструирования на основании производственных чертежей с технологическими изменениями и служит источником для стадий производства, эксплуатации, разработки модификаций на следующих этапах ЖЦ. Также ЭМИ-3 включает базу сертификационных расчетов на прочность, сборник требований по установке систем и оборудования.
В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению и сборке изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления и используемых для планирования, оценки и организации процесса производства изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.
В состав рабочей конструкторской документации (РКД), разработанной по ЭМИ, входят стандартные компоненты. Производственные подразделения используют согласованный комплект документов, который имеет соответствующее «говорящее» кодирование (нумерацию чертежей), позволяющее в минимальном количестве цифр изложить всю необходимую информацию о детали. Вокруг разработки ЭМИ необходимо организовать процессы технического контроля (регулярные по времени ревизии). Командная работа на электронном макете является важным компонентом снижения времени разработки, повышения качества документации, упрощения обмена данными со службами технологической подготовки производства.
В каждом узле большого проекта должен работать один или несколько ЭМИ-интеграторов, чьи задачи состоят в следующем:
•проверять правильность данных, поступающих в ЭМИ, особенно затрагивающих конфигурацию, а также наличие связей файлов, необходимых для совместной работы;
• проводить анализ проблем и подтверждать корректность ЭМИ (особенно после фаз интеграции), т.е. проверки, что нет «коллизий», аномальных данных, «наездов» деталей друг на друга;
• управлять качеством данных ЭМИ (рекомендуется иметь выделенного сотрудника, занятого на этой конкретной позиции);
• помогать менеджерам связывать параллельные виды деятельности и интегрировать их результаты внутри процессов параллельного инжиниринга.
В ходе проверки результатов работ на ЭМИ удобно использовать типовые вопросники, составленные и пополняемые с учетом традиций компании-разработчика и накапливающегося опыта. Чек-листы (документированный перечень вопросов для проверки) составлены и корректируются с учетом имеющейся статистики, содержат компоненты критической базы знаний, хорошо помогают при дефиците обученного персонала, важны, чтобы не забыть задавать проясняющие вопросы. Их активно используют на этапе проверки документов или этапов работы (обнаружить проблемы пока не поздно, гарантировать их обнаружение) для нахождения ошибок оформления конструкторской документации, технических проблем и др. Хотя практика показала, что проблемы находятся нечасто, применение чек-листов полностью окупается. Текущее внесение в чек-листы типовых конструкторских ошибок существенно улучшает качество документации на финише проекта.
Вышеперечисленный объем работ нескольких проектных групп одновременно на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50 000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6…10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве. Первым самолетом, спроектированным с использованием электронной документации, был Boeing-777 (в серии с 1995 г.). Его проектирование, разработка и испытания с широким использованием моделирования и виртуального эксперимента, замена физических макетов на ЭМИ позволили получить (сравнительно с созданием предыдущих самолетов В-757, B-767) ряд преимуществ:
a) исключено более 3000 сборочных интерфейсов;
b) получено 90% снижения запросов на изменение РКД (т.е. в 10 раз);
c) на 50% ускорен цикл обработки запросов на изменения;
d) достигнуто 90% снижения переделок конструкции (т.е. в 10 раз);
e) обеспечено улучшение допусков на сборку фюзеляжа (повышена точность подгонки секций).
На рис.13 показано улучшение качества конструкторской документации на разных фазах ЖЦ при использовании ЭМИ. Здесь ПИ обозначает предварительные извещения об изменениях.
Рис. 13. Влияние ЭМИ на снижение числа изменений РКД
Процесс интеграции системы из компонентов и подсистем является одним из важнейших в проекте, так как завершает процедуру разработки получением конечного продукта. К сожалению, в отечественной практике данный этап либо не выделен, либо сведен к процессу финальной сборки производственными подразделениями и приемочным испытаниям. Целью этапа интеграции является собрать вместе все части или элементы интересующей системы в единое целое для обеспечения их совместной работы. Интеграция продукта включает в себя множество мероприятий, которые необходимо планировать на ранней стадии программы или проекта, чтобы эффективно и своевременно выполнить интеграцию. Необходимо собрать и интегрировать полученные части в систему в соответствии с указанными требованиями, конфигурационной документацией, требованиями к интерфейсу, применимыми стандартами, последовательностью и процедурами интеграции. В процесс входят управление, оценка и контроль физических, функциональных данных и интерфейсов между интегрируемыми продуктами.
Напомним некоторые термины и принципы процесса интеграции.
Принципом называют описание того, что должно быть, или того, что есть, или руководство, которое, возможно, является разумным. Принципы проверяют для верности, подтверждая опытом и экспериментами. Их можно объединить, превратить в связный массив знаний и принять в качестве основы для рассуждений, логики и действий, классифицировать и интерпретировать ситуацию с точки зрения предыдущих итераций.
Событием называют происходящее действие или происшествие, приводящее к изменению объекта вследствие преобразования входа в выход. События имеют структуру, могут быть упорядочены и распознаются как объекты, физические или интеллектуальные.
Ситуацией называют последовательность событий, в которой событие описывает деятельность, которая связывает входной сигнал или компонент с выходным.
Принцип согласованности интеграции включает согласование стратегий ключевых заинтересованных сторон с целями проекта и предоставление согласованного продукта или услуги, что имеет первостепенное значение для успеха.
Принцип разделения (декомпозиции) делит концепции высокого уровня на несколько объектов низкого уровня для упрощения работ.
Принцип индукции отражает мышление, направленное на достижение интеграции на основе правил. Это требует индуктивного рассуждения, чтобы отслеживать модели, отражающие реальность, обобщая подходы, а также собирая доказательства, которые предполагают динамику взаимодействия между процессами.
Принцип ограничения отражает тот факт, что концептуальная архитектура, концепция операций и проект системы сильно зависят от бюджетных ограничений. Следовательно, архитектура нижнего уровня соразмерно ограничена в стоимости, обусловленной распределением ресурсов.
Принцип предусмотрительности напоминает, что ключевые факторы, определяющие интеграцию, должны учитываться на этапах планирования интеграции. Это определение требований; соображения по поводу решения проблемы, включенные в проект системы; достижение и удовлетворение ключевых потребностей заинтересованных сторон, осуществляемых с помощью архитектуры; создание физических объектов, которые воплощают ожидаемые функциональные возможности (и их характеристики) и обеспечивают желаемое поведение пользователей. Планирование интеграции облегчает проблемы по ее ходу, вызванные неэффективными измерениями, компромиссами, а также непродуманным графиком или распределением ресурсов для преодоления технических проблем.
Принцип планирования интеграции заключается в определении того, сколько времени потребуется для выполнения задач. Для чего определяют тип и количества ресурсов, задержки из-за внутренних и внешних факторов, связанных с выполнением задачи и др. Сетевое планирование прогнозирует влияние на бюджеты и график различных последовательностей и длительностей объектов, которые нужно интегрировать. Управленческий резерв может быть использован для борьбы с неопределенностями, связанными с проблемным или неумелым управлением. Интеграция с эмуляторами (имитаторы компонентов системы) позволяет впервые взглянуть на вопросы интеграции для построения подфункций, пока не станет доступным реальный объект, готовый к тестированию. Процедуры использования эмуляторов для выполнения интеграции, как правило, никогда не совпадают с интеграцией намеченных объектов. Часто производительность эмулятора значительно медленнее, чем у реального объекта.
Интеграция системы проводится на различных уровнях для достижения требуемого эффекта:
• интеграция на уровне компонентов: способность убедиться, что дискретная функция компонента соответствует общей системе, в которой он находится;
• на уровне системы: слияние отдельных функций и характеристик, ранее выполнявшихся дискретными элементами управления, в область общего управления;
• на уровне процесса: постепенное наращивание компонентов продукта в единое работающее и протестированное изделие;
• на функциональном уровне: идентификация интегрированных функций как объединения многих отдельных функций для формирования наглядного эффективного (измеримого) результата.
Для достижения системной интеграции используют подходы сверху вниз или снизу вверх. В первом берут все подсистемы интересующей системы и объединяют их за один раз. Подсистемы индивидуально тестируются перед интеграцией, но все они собираются одновременно для интеграции. Этот метод сопряжен с высоким риском, поскольку в нем любую обнаруженную проблему сложно изолировать и решить. Второй подход начинается от элементов самого нижнего уровня и их интеграции с проверяемыми приращениями. Процесс движется от нижнего уровня системы к подсистемам верхнего уровня. Одним из положительных аспектов этого подхода является то, что элементы более низкого уровня обычно можно интегрировать в начале программы. Этот подход, по сравнению с первым, также снижает риск за счет одновременного введения ограниченного числа неизвестных переменных.
Интеграция является одним из самых затратных и трудоемких мероприятий в процессе системного проектирования. Для больших и сложных систем на эту деятельность может быть использовано до 40% усилий по разработке, в основном для системных испытаний. Порядок, в котором элементы системы интегрируются в единое целое, должен быть тщательно спланирован, важно учесть график работ и интерфейсы. Не следует на этом этапе объединять все или слишком много элементов одновременно. Наиболее практичный подход, используемый для новых или модифицируемых систем, заключается в том, чтобы вводить в ходе синтеза элементы системы через ряд промежуточных состояний конфигурации или стадий работы. Выполняется функциональное тестирование собранного устройства, чтобы убедиться, что сборка готова для проверочных испытаний и готова к интеграции на следующий уровень. Как правило, проверяются ключевые функции, чтобы гарантировать, что собранная система функционирует должным образом.
Планирование процесса интеграции начинается, когда определяется перечень мероприятий по проекту. Уточнение плана интеграции происходит во время этапа проектирования архитектуры высокого уровня. Интеграция выполняется, когда компоненты оборудования и программного обеспечения разработаны и сданы командами разработчиков. Интеграция и верификация являются тесно связанными итерационными процессами, следующими один за другим до тех пор, пока вся система не будет готова к оперативному развертыванию.
План интеграции охватывает подход, тестирование и проверку интегрированных подсистем, а также определение проверки интегрированной системы. Он обычно включает:
a) аспекты развития (графические ограничения, ресурсы, оборудование, рабочая сила);
b) результаты шагов разработки (проектирование системы, предварительный проект, детальное проектирование, архитектура, описания физических объектов, интерфейсов между физическими объектами, описания функциональных возможностей продукта или услуги);
c) планы тестирования (от ранней до поздней стадии). Желательно продемонстрировать функциональные связи (т.е. небольшие последовательные подфункции), которые при сквозном объединении раскрывают системную функцию.
При реализации процессов интеграции системы полезно начинать с четкой коммуникации между исполнителями, чтобы все понимали цели проекта и свои роли. Далее составить карту всего процесса для выявления потенциальных рисков и спланировать действия в чрезвычайных ситуациях. Первыми объектами, которые необходимо интегрировать, являются те, которые необходимы и достаточны для демонстрации сквозной жизнеспособности основной функции системного уровня. После завершения и демонстрации основного системного потока аналогичным образом обрабатываются параллельные, взаимодействующие и вспомогательные потоки, которые добавляют дополнительную функциональность. В процессе исполнения рекомендуются регулярные проверки для получения обновлений о ходе работ и проблемных отказов, для отслеживания задач и поддержания видимости операций. После интеграции проводится заключительное испытание, чтобы убедиться, что все работает так, как ожидалось.
Примерная последовательность шагов интеграции включает несколько этапов.
Первый этап модели системного процесса для интеграции содержит идентификацию объектов парами, которые необходимы для демонстрации функции верхнего уровня, подфункции, которые поддерживают функции верхнего уровня.
На втором этапе проводят распознавание и характеристики системных функций верхнего уровня в простейшей форме для демонстрации сквозного потока системного уровня. Несколько связанных показателей должны быть измерены и определены как эталонные для демонстрации осуществимости.
Третий этап охватывает расширение интеграции приоритетных системных функций верхнего уровня и критических независимых функций. Входит планирование тестирования, выполнение испытаний и проверка приоритетных функциональных потоков системного уровня.
Четвертый этап включает общее улучшение производительности всех потоков системного уровня за счет улучшения подфункций. Механизмы настраиваются, совершенствуются или заменяются улучшенными компонентами или объектами. Кульминацией четвертого этапа является испытание на уровне системы.
На пятом этапе выполняют подготовку валидации. Верификация проекта системы, архитектуры, концепции операций и спецификаций должна быть завершена до интеграции физических объектов, чтобы гарантировать, что в конечном итоге проводится интеграция объектов и функций, которые удовлетворяют спецификациям и требованиям. В заключение этапа осуществляется валидация системы.
В сложных проектах не всегда возможно интегрировать все системы в один этап. План системной интеграции должен учитывать интерфейсы для разработки серии запланированных промежуточных этапов, чтобы объединить различные подсистемы контролируемым образом, включая спецификацию интеграционных тестов. Разработчик системы (и подсистем) должен сотрудничать с командой испытателей и вводом объекта в эксплуатацию для планирования этих мероприятий по интеграции и тестированию, а также критериев приемлемости. Для интеграции сложных систем могут быть использованы десятки испытательных стендов.
Управление интерфейсом на этапе интеграции поддерживает процедуры сборки для обеспечения надлежащей маркировки и совместимости интерфейса со спецификациями и документом управления интерфейсом. Верификация требований к интерфейсам является критическим аспектом общей верификации системы, часто с использованием эмуляторов, которые должны соответствовать характеристикам операционной среды и требованиям проверки интерфейса.
Сбои, возникающие в процессе интеграции, имеют несколько основных причин, включая плохое управление (плохое согласование ресурсов с требуемыми задачами, плохую коммуникацию и ненадежную функциональность, связанную с тем или иным объектом), плохие навыки интеграции, инструменты или испытательное оборудование.
Входными данными для процесса интеграции системы являются следующие:
• концепция операций, которая определяет, как система должна работать и будет помогать в проверке и интеграции;
• утвержденные требования к системе и подсистемам;
• архитектура проекта высокого уровня, где определены интеграционные операции;
• материалы детального конструирования, которые содержат конструктивные ограничения для подсистем и систем;
• стратегия интеграции, где определено, когда и где подсистемы должны быть сгруппированы и развернуты;
• разработанные аппаратно-программные компоненты и подсистемы, в которых завершена интеграция на своем уровне и они готовы к следующему уровню верификации.
При создании реалистичной среды испытаний и оценки необходимо учитывать следующие факторы.
1. Выбор тестового задания. Система и ее компоненты, выбранные для испытаний, должны представлять собой проектную или производственную конфигурацию, включающую все последние утвержденные инженерные изменения.
2. Выбор испытательной площадки. Система должна быть протестирована в среде, которая будет характерна для операций пользователя; Выбранная площадка должна в максимально возможной степени имитировать условия Арктики или тропиков, равнинную или гористую местность, и др.
3. Процедуры тестирования. Выполнение задач испытаний обычно включает выполнение задач эксплуатации и технического обслуживания, которые должны следовать официально утвержденным техническим руководствам.
4. Испытательный персонал. Сюда входят лица, которые будут фактически эксплуатировать и обслуживать систему на протяжении всего испытания, вспомогательные инженеры, техники, регистраторы данных, аналитики и администраторы, которые оказывают помощь в проведении всей программы испытаний. Отобранный эксплуатационный персонал должен соответствовать требованиям с точки зрения количества и уровня квалификации.
5. Тестирование и поддержка оборудования и ПО. При использовании оборудования наземного обслуживания, испытательного оборудования, программного обеспечения следует использовать только те объекты, которые допущены к эксплуатации.
6. Снабжение испытаний. Сюда входят все запасные части, расходные материалы и вспомогательные запасы, необходимые для завершения тестирования и оценки системы. Желательна реалистичная конфигурация.
7. Испытательные мощности и ресурсы. Должны быть заранее определено и запланировано использование специальных помещений, испытательных камер, оборудования, средств экологического контроля, специальных приборов и сопутствующих ресурсов (например, тепла, воды, кондиционирования воздуха, электроэнергии, связи).
8. Требования к интерфейсу. Применимые интерфейсы и требования к тестированию должны быть определены и согласованы по всем направлениям по мере необходимости.
Во время системной интеграции дизайнеры должны быть доступны для поддержки тестирования и ввода в эксплуатацию. Они обеспечат соответствие первоначального дизайна интерфейса и разрешат изменения, требуемые при решении проблем, которые могут возникнуть во время интеграции и тестирования. В некоторых системах значительная часть системной интеграции и тестирования может быть проведена вне площадки сборки на заводе-изготовителе поставщика в качестве заводских интеграционных испытаний. Например, в процессе интеграции воздушных судов в качестве основных наземных стендов используют стенд системы электроснабжения самолета; стенд гидросистемы и механизмов с полунатурным моделированием комплексной системы управления и системой управления общесамолетным оборудованием, так называемую «железную птицу»; стенд комплексирования бортового оборудования, или «электронную птицу».
В результате процесса должен быть получен интегрированный продукт со всеми системными взаимодействиями. Оформлены документация и руководства, включая модели, данные и отчеты системного анализа, подтверждающие обоснование готовности и доступные для будущего анализа во время работы системы; отчеты по интеграции продуктов (для поддержки процесса управления техническими данными); чертежи сборки и верификации; требования к эмулятору (где приложимо); и документированные ограничения для аппаратного и программного обеспечения.
Следует отметить, что кроме технологической интеграции на этапе необходимо реализовать управленческую компоненту интеграции. Она включает интеграцию по срокам работ, затратам, ресурсам, рискам и координацию всех частей процесса интеграции в целом. Причем приоритет управленческой интеграции выше, чем технологической, из-за большего числа охвата факторов.
Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.
2.7. Верификация и валидация
Одним из основных принципов системно-инженерного подхода является пошаговая проверка результатов работ на соответствие выставленным требованиям. Для проверки результатов каждого шага разработки используются два метода: верификация и валидация.
Верификация представляет процесс подтверждения того, что требование или система соответствует входным данным. Проверка требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию? Верификация системы или ее компонента показывает, что синтез системы выполняется правильно, гарантирует, что система соответствует требованиям. Этот процесс выполняется на различных этапах создания системы, как правило, внутренними силами разработчика с привлечением коллег для контроля результатов. Используют четыре метода верификации: инспекцию, анализ, демонстрацию, испытания (тесты).
Каждый элемент системы проверяется на соответствие требованиям. Метод верификации для каждого требования должен начать формироваться на этапе анализа требований. Важно определить, как каждое требование будет проверяться на раннем этапе, чтобы любое оборудование для верификации или необходимое моделирование были доступны к этапу верификации.
Планы верификации должны быть рассмотрены заинтересованными сторонами проверяемого требования. Согласие заинтересованных сторон с планом верификации помогает обеспечить единообразное понимание требования с проектировщиками. Стоимость методов верификации важно учитывать, поскольку они могут сильно различаться по стоимости, но достигать одной и той же цели.
Валидация представляет процесс подтверждения того, что набор требований, проект или система соответствует предназначению заказчика, другими словами, построена потребная система. Валидация определяет правильность и полноту конечного продукта, и гарантирует, что система удовлетворит реальные потребности заинтересованных сторон в предполагаемой среде эксплуатации. Как правило, проводится с привлечением внешних инстанций (регулирующих органов, представителей заказчика, межведомственных комиссий и др.). На этапе валидации система проверяется во всех режимах работы или сценариях. Как и на этапе верификации, этап валидации необходимо планировать заранее. Причина раннего планирования валидации в том, что она предназначена для обеспечения окончательного утверждения системы заинтересованными сторонами. Также при валидации могут потребоваться компоненты инфраструктуры, которые нужно изготовить к определенному сроку.
Вкратце различия применения верификации и валидации можно изложить следующим образом. Верификация проводится:
• в процессе разработки;
• чтобы убедиться, что утвержденные требования будут выполнены;
• как правило, в лабораторных условиях (не натурных);
• верификация ориентирована на компоненты и подсистемы.
Аналогом в РФ выступают компонентные испытания и проверки на моделирующих стендах.
Верификация системы или ее компонентов и подсистем является более общим понятием, чем просто проведение испытания. Целью верификации является проверка, что верифицируемый объект соответствует требованиям к нему, реализован без лишних функций, удовлетворяет проектным спецификациям и стандартам. Как уже упоминалось, процесс верификации включает разные методы, то есть процесс испытаний является составной частью процесса верификации.
Валидация выполняется:
a) в процессе или после процедуры интеграции системы;
b) обычно в реальных или смоделированных условиях эксплуатации;
c) для проверки ожиданий заинтересованных сторон;
d) желательно в составе полномасштабного варианта системы.
Аналогом в РФ являются сертификация, государственные или межведомственные испытания.
Валидация системы служит доказательством, что в результате разработки системы достигнуты цели, которые планировали для эксплуатации. Другими словами, это проверка соответствия системы ожиданиям заказчика, гарантия ее качества. Когда экономически выгодно и гарантировано анализом, расходы программы могут быть смягчены путем объединения тестов для одновременной верификации и валидации конечного продукта или системы.
Основные задачи верификации при разработке перечислены ниже.
1. Планирование верификации конструкторских решений в соответствии с планом верификации, контрактом с заказчиком, применимой фазы жизненного цикла и до уровня структуры системы. Соответствующий уровень может варьироваться от системы и подсистемы вниз до уровня компонентов. Он может включать выбор и определение соответствующего метода для проверки проектных решений, процедуры верификации для следования выбранному методу (включая критерии определения успеха или неудачи проверки); создание и проверку влияния окружающей среды (например, климатические условия, оборудование, сооружения, измерительные приборы и т.д.), в которой будут реализованы метод и процедуры проверки.
2. Выполнение плана верификации проектных решений. Используют выбранные методы и процедуры в установленной для проверки окружающей среде, чтобы осуществить сбор и оценку результатов верификации для показа соответствия требованиям представленного физического решения, или определить отклонения (непроверяемые требования и ограничения). Отклонения должны быть документированы в отчете по несоответствиям или в интегрированной базе данных предприятия для оценки и разрешения проблем.
3. Повторение верификации в соответствии с планом, методом испытания или процедурой, когда отклонения (разброс данных) были вызваны недостаточной адаптацией к условиям окружающей среды в эксплуатации.
4. Фиксация записи результатов верификации, в том числе: корректирующих действий; уроков исправления, достигнутых результатов; компромиссов, анализа рисков, результатов испытаний; отклонений и проверенных решений проекта в хранилище данных предприятия.
Валидация может охватывать следующие действия.
• Тестирование производительности для проверки того, что продукт или система функционирует должным образом и соответствует ожиданиям клиентов.
• Испытание для подтверждения того, что изделие соответствует всем законодательным требованиям, требованиям безопасности и нормативным требованиям, включая формальные приемочные испытания.
• Испытание на срок службы (ресурс) для подтверждения того, что продукт будет продолжать функционировать в соответствии со своими требованиями на протяжении всего заданного срока службы.
• Экстремальные испытания для подтверждения того, что продукт будет продолжать функционировать в экстремальных сценариях эксплуатации внутри рабочего диапазона или при работе в различных условиях окружающей среды.
• Испытания на надежность, чтобы доказать, что продукт будет надежно функционировать с точки зрения частоты отказов на протяжении всего расчетного срока службы.
• Подтверждающее тестирование, чтобы продемонстрировать, что продукт, изготовленный методами массового производства, работает так же, как продукт, изготовленный на ранних этапах проекта.
Необходимым элементом валидации сложной техники являются испытания компонентов и системы в целом (модельные, натурные, квалификационные, в составе объекта, сертификационные). При испытании технические средства, такие как специальное оборудование, приборы, методы моделирования, используют для объективной оценки характеристик системы или ее компонентов на определение соответствия целевым значениям требований. Типовой тест включает процесс моделирования сценариев эксплуатации всей системы или ее части под ограниченным набором контролируемых условий, чтобы определить количественное выполнение проектных или эксплуатационных требований.
Ведутся работы по развитию численных испытаний с использованием цифровых двойников, виртуального моделирования динамических процессов в системе. Целью данного направления является замена части натурных испытаний системы (как правило, дорогостоящих и длительных) результатами цифрового моделирования статических и переходных режимов эксплуатации, а также нерасчетных случаев (частичных отказов узлов и агрегатов, нештатных условий применения и др.). Предварительно сами цифровые двойники (расчетные модели) должны быть верифицированы для подтверждения требований достоверности и точности расчетных результатов.
Комплексное тестирование включает выполнение полных рабочих сценариев для нескольких элементов конфигурации, гарантирующих, что все требования к системе будут проверены. Эксплуатационные сценарии должны быть описаны для всех режимов работы, фаз применения (например, установка, запуск, типичные примеры операций с нормальными и аварийными ситуациями, выключение и обслуживание) и критических последовательностей действий. В сценарии дается пошаговое описание того, как система должна работать в конкретных условиях применения.
В процессе валидации важно сравнить фактические результаты с ожидаемыми. После завершения деятельности по проверке результаты собирают и анализируют. Данные проверяют на качество, целостность, правильность, согласованность и достоверность. Любые несоответствия проверки (аномалии, варианты и условия несоблюдения) идентифицируют и пересматривают, определяют запросы, необходимые в результате проверки для привлечения помощи или изменения требования. Недостатки и рекомендуемые корректирующие действия и результаты разрешения должны быть записаны.
При планировании испытаний требуется:
• разработать подробные квалификационные требования к испытаниям;
• определить подробные архитектуры компонентов для тестовых ресурсов (выявить, какие специальные установки, измерительные приспособления и тестовые заглушки необходимы);
• инициировать разработку и изготовление необходимых стендов;
• сформировать матрицы испытаний (выделить производные требования к функциональным и физическим архитектурам);
• написать детальные планы квалификации для каждого компонента с учетом ресурсов;
• создать сценарии тестирования с учетом нормативной документации;
• определить необходимые данные мотивации для каждого вида деятельности;
• написать программы испытаний и процедуры анализа результатов;
• определить графики по срокам испытаний и анализа.
В таблице 2 показан пример матрицы верификации для плана испытаний продукта. В левых столбцах указаны пункты технического задания для верификации и названия этапов работ. В последних колонках показаны выбранные верификационные методы по типам.
Планирование процедур верификации узлов и компонентов должно учитывать потребные сроки на проектирование и изготовление стендов и моделей. В одной из организаций проектирование стендов поручили разработчикам системы в порядке очередности. В результате на два года сорвали сроки испытаний из-за задержки изготовления стендов.
Таблица 2
Легенда: А-анализ, Д-демонстрация, Т-тест, И-инспекция.
Для испытаний сложной техники широко применяют наземные стенды систем и компонентов, в том числе прочностные, где проводят статические и ресурсные испытания. Статические испытания определяют способность конструкции выдерживать высокие однократные нагрузки. Ресурсные испытания позволяют спрогнозировать поведение конструкции при повторяющихся нагрузках, характерных для типовой эксплуатации. В авиации, например, используют стенды для специальных испытаний, где проводят климатические тесты, а также испытания на внешние воздействия (попадание птиц, молниестойкость, пожаростойкость и др.). Полный набор базовых требований к испытаниям компонентов авиационной техники изложен в стандарте КТ-160 (DO-160G) «Условия окружающей среды и процедуры испытаний для бортового авиационного оборудования», содержащем 26 разделов. При работах по указанному стандарту используемые стенды должны быть предварительно сертифицированы на соответствие этим требованиям.
В общей сложности на этапе разработки нового гражданского самолета применяют от 20 до 50 наземных стендов в зависимости от уровня сложности решаемых технических задач. Поэтому следует стремиться замещать результатами виртуального моделирования поведения аэрокосмической, автомобильной, атомной и другой сложной техники значительную часть дорогостоящих наземных, летных и специальных испытаний.
Сложные динамические модели и виртуальное моделирование широко используют для принятия критических решений в области проектирования, разработки, производства и эксплуатации, для проверки эксплуатационных и нерасчетных режимов работы системы. Обоснование достоверности получения доброкачественных результатов моделирования достигается путем:
1) обеспечения правильной постановки задач моделирования (например, пользователи не могут вводить в расчет параметры, выходящие за пределы заданного диапазона режимов);
2) разработки процессов верификации и валидации инструментов, сертификации расчетных моделей на основе эксплуатационных данных и типовых экспериментов;
3) разработки и идентификации отраслевых стандартов для документации, управления конфигурацией и обеспечения качества моделирования;
4) разработки стандартного метода оценки достоверности результатов моделирования, представляемого уполномоченному органу, принимающему решения.
Технический лидер отвечает за обеспечение достоверности результатов этих мероприятий по моделированию. В ряде случаев на практике можно сократить плановые сроки процессов тестирования. Для этого могут быть использованы:
a) легко проверяемые требования;
b) пошаговые руководства по планированию, проведению и обработке испытаний;
c) модели и виртуальное моделирование;
d) надежная конструкция для изменения параметров компонента, процесса изготовления;
e) стандартизация процессов и документов;
f) применение ускоренных эквивалентно-циклических испытаний;
g) доступность испытательного оборудования (стендов) и измерительных систем;
h) независимость компонентов системы;
i) эмулятор оборудования для непроверенного программного обеспечения;
j) проверенное программное обеспечение для непроверенного оборудования;
k) модульное, «восходящее» (снизу-вверх) тестирование;
l) готовый план испытаний и процедуры тестирования, контроль критического пути графика работ.
В качестве примера важности верификации в космической программе рассмотрим происшествие с аппаратом Genesis в 2004 г. Он был запущен NASA в 2001 г. для сбора и анализа заряженных частиц, выдуваемых из короны Солнца (солнечного ветра). По плану возвращения на Землю, после входа в атмосферу капсула должна была выпустить первичный парашют, который бы замедлил и стабилизировал падение. Затем должен был раскрыться основной парашют для совершения мягкой посадки. Оба парашюта не сработали при приземлении, аппарат разбился о землю на скорости 350 км/час. Два разных комплекта контрольных датчиков (срабатывавших по величине ускорения торможения и по росту температуры) были включены наоборот (сравнительно со спецификациями). После работы аварийной комиссии выявлены причины происшествия:
1) схема использования датчиков для выпуска парашютов скопирована с предыдущей успешной модели;
2) верификационные требования расплывчаты, наземный тест срабатывания на центрифуге не затребован;
3) конструктор проверил срабатывание датчиков (открыто-закрыто), при этом не была проведена верификация ориентации датчиков;
4) электрик-монтажник некорректно провел верификацию ориентации по чертежу;
5) проверяющие вынесли решение, что проект системы выполнен правильно, так как скопирован с удачного аналога;
6) инженер, готовивший аппарат к полету, не замкнул обратную связь с проектантом, т.к. не потребовал обсудить результаты испытаний.
В результате аварии виновными признаны конструктор (не проведен обзор проекта) и испытатель (не выполнена верификация системы выпуска из-за копирования предыдущего решения).
2.8. Риски и возможности
Неопределенности при реализации больших, дорогостоящих программ в области высоких технологий могут существенно повлиять на успешность и себестоимость создаваемых изделий и систем. Поэтому управление рисками (в первую очередь техническими) является одной из основных задач реализации системно-инженерной методологии на проектах. Напомним определения риска.
•Риском называют будущее событие с реальной вероятностью, которое оказывает негативное воздействие на безопасность или технические характеристики проекта, стоимость или график.
• Риск включает сочетание вероятности и последствий наступления неблагоприятных событий (вероятность выхода опасного фактора из-под контроля и серьезность последствий, выражаемая степенью проявления).
• Возможностью называют будущее событие, возникающее с реалистичной вероятностью, которое может оказать положительное влияние на достижение результатов проекта.
Риск характеризуется тремя основными компонентами:
a) воздействие или сценарий, приводящий к ухудшению эффективности в отношении одного или нескольких показателей эффективности (например, разрушению основных активов, превышению пределов массы, перерасходу средств; смещению графика проекта);
b) вероятность каждого из этих сценариев;
c) последствия (качественная или количественная степень ухудшения характеристик), которые могли бы возникнуть при реализации сценария.
Недостаток достижимых характеристик проекта системы может быть связан с любым одним или несколькими разделами требований (список не ограничивается).
1. Риск затрат связан с возможностью реализации программы или проекта для достижения целей его жизненного цикла и обеспечения надлежащего финансирования. Включает риск того, что сметы расходов и цели не являются точными и разумными; и риск того, что выполнение программы не будет соответствовать целям в результате проблем с затратами, графиком и рисками эффективности.
2. Риск расписания (графика проекта) связан с адекватностью времени, оцененного и выделенного для разработки, производства, внедрения и эксплуатации системы. Включает риск, что выполнение программы не соответствует срокам расписания в результате проблем на проекте.
3. Технический риск связан с эволюцией дизайна и производства, влияющей на уровень характеристик, необходимый для удовлетворения ожиданий заинтересованных сторон и технических требований. Возможна вероятность неудачи проекта вследствие отрицательных результатов НИР или в результате недостижения запланированных технических параметров в ходе выполнения ОКР.
4. Программный риск связан с действием или бездействием извне проекта, над которым менеджер не имеет контроля, но который может оказать значительное влияние на проект. Эти воздействия могут проявляться в терминах технических, стоимостных или влияния на график, например, санкционные риски в отношении участников программы.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=71515627?lfrom=390579938) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Виктор Юрьевич Николенко
В книге впервые в отечественной литературе кратко изложены принципы и методы управленческого компонента системной инженерии при создании высокотехнологичной продукции различного назначения.Включены практические сведения по разработке систем ГК «Ростех», «Роскосмос», «Газпром», «Росатом», для городской инфраструктуры, здравоохранения, транспорта и др.Книга рекомендуется в качестве важного дополнения к курсам управления проектами и будет полезна для всех специалистов и менеджеров по теме.
Системный подход к управлению высокотехнологичными проектами
2-е издание, переработанное и дополненное
Виктор Юрьевич Николенко
Дизайнер обложки Ольга Третьякова
© Виктор Юрьевич Николенко, 2024
© Ольга Третьякова, дизайн обложки, 2024
ISBN 978-5-0065-2004-2
Создано в интеллектуальной издательской системе Ridero
Предисловие ко второму изданию
Целью настоящей книги было дать читателю необходимые инструменты по теме для практического использования в повседневной работе. Ее первое издание (2019 г.) стало активно использоваться специалистами и студентами управленческих позиций в различных отраслях. На основании отзывов читателей и общения со слушателями на лекционных курсах подготовлено переработанное и дополненное второе издание.
Расширенное переиздание этой книги в качестве дополнения к стандартным курсам управления проектами будет полезно управленцам-практикам, менеджерам и инженерам по системам, производству и обслуживанию продуктов, а также руководителям высшего и среднего звена в отраслях разработки и производства новой техники (в авиации, космической, автомобильной, химической, нефтегазовой, транспортной, коммуникационной, медицинской технике, машиностроении, в министерствах, ведомствах и государственных корпорациях). Ее также могут использовать студенты, аспиранты и сотрудники университетов, готовящих специалистов различных высокотехнологичных отраслей.
Сегодняшние испытания, выпавшие на долю Российской Федерации, подтвердили важность лидерской роли управленческого персонала в возвращении технического суверенитета нашей страны. Необходимо эффективное и оперативное решение ряда высокотехнологичных задач. В течение следующих 20 лет мир должен будет быстро реагировать на проблемы загрязнения планеты, истощения ресурсов, а также растущего и более мобильного населения. Разработчики продуктов будут иметь все больше возможностей благодаря достижениям в области моделирования и машинного интеллекта для проектирования желаемого поведения системы. Компоненты и подсистемы будут использоваться в нескольких продуктах, поскольку потребителям требуются интегрированные решения. На рынке появятся новые материалы, с новыми свойствами или более доступные, для замены дефицитных, неэкологичных, плохо обрабатываемых образцов, обеспечения невидимости и др. Для экономии ресурсов будет возрастать необходимость повторного использования существующих компонентов и систем. Цифровизация проникнет во все аспекты жизни и окружающего мира. Возможность моделировать поведение продукта в различных сценариях использования и применение цифровых двойников повышает точность проектирования работы систем в условиях эксплуатации, прогнозирование сроков службы изделий.
Управление высокотехнологичными исследованиями и разработками в значительной степени является искусством координации и интеграции усилий высококвалифицированных участников. Менеджер должен обеспечивать порядок работ, движение к цели при исполнении проекта, разумно справляясь с неопределенностью, присущей новым разработкам. Сегодня в Российской Федерации в рамках борьбы за технологический суверенитет открыто окно возможностей импортозамещения основных отраслей высоких технологий, жизненно необходимых для качественного скачка в промышленном развитии государства. Для достижения этих целей специалистам по управлению необходимо учиться эффективно работать в тесно связанных междисциплинарных командах, объединяющих специалистов широкого профиля и узкоспециализированных экспертов, исполняя сложные проекты в рамках заданных сроков и бюджетов с требуемым качеством.
Во втором издании книги переработана и выделена в отдельную главу тема управления жизненным циклом продукции. Существенно расширено изложение вопросов формирования мультидисциплинарной команды проекта, ее обучения, мотивации и лидерства. Добавлена глава о цифровизации управленческих процессов с точки зрения менеджера в части практического применения цифровых двойников и машинного интеллекта. Внесены дополнения в базовую часть текста книги.
Глава 1. Введение
1.1. Почему эту книгу нужно прочесть
В фокусе данной книги находятся практические вопросы управления высокотехнологичными проектами и программами, недооцененные или отсутствующие, к сожалению, в отечественной литературе.
Есть много проектов, которые включают системы и ведут себя в соответствии с законами систем, что связано со спецификой инженерных программ. Методы традиционного управления проектом направляют общее планирование, организацию, контроль, управление ресурсами, однако не детализируют основное содержание управления программами разработки сложных технических систем. Управление проектами в рамках системного подхода ликвидирует указанный пробел, предоставляет руководство и инструменты для управления техническими аспектами программной деятельности, мониторинга и контроля прогресса проекта, адаптируя процессы, специфичные для инженерной программы, с целью оптимального удовлетворения потребностей заказчика.
Процессы создания новых образцов высокотехнологичной продукции в XXI веке стремительно развиваются в связи с требованиями рынка. При этом в разработках новой продукции в мире используются эффективная методология системной инженерии и техника командной работы. Данной теме посвящено значительное количество монографий, часть из которых приведена в перечне литературы в конце книги [1…10]. Обусловлено это тем, что на сегодня системно-инженерный менеджмент является самой важной практической дисциплиной реализации сложных проектов и программ с подтвержденным положительным эффектом, полезным мощным профессиональным навыком инженеров и менеджеров. Системная инженерия (СИ) оформилась на рубеже ХХ… ХХI веков на основе опыта и достижений технических и управленческих наук как организованный набор принципов, правил и процедур создания высокотехнологичных продуктов. Методология была формализована, реализована в стандартах (включая ряд российских ГОСТов) и инструкциях. В международном сообществе системных инженеров INCOSE вышло 5-е издание справочника по СИ [10]. Подробную информацию также можно найти в 3-ем издании курса системной инженерии NASA и двух томов разъяснений к нему [7, 8].
Отечественный опыт обучения системному подходу показал, что понимание методологии системно-инженерного управления приходит уже после выполнения двух… трех проектов.
Данный краткий курс предназначен для менеджеров различных отраслей, включая авиацию, космос, автомобилестроение, железнодорожный транспорт, «Ростех», «Росатом», «Газпром», «Роснефть», сферу информационных технологий, городские инфраструктуры и др. В материале книги широко использован накопленный многолетний практический опыт автора, руководителя пяти инженерных центров, который полезно учитывать при освоении и применении системной инженерии (см. биографию в конце книги).
Ранее автором издано учебное пособие «Базовый курс системной инженерии» [2] на основе опыта работы и курса лекций, прочитанных в 2013…2016 гг. на междисциплинарной кафедре Высшей школы системной инженерии МФТИ. Затем опубликована книга по практической реализации высокотехнологичных программ [4].
Книга построена в следующем порядке.
В первой главе дано краткое введение к предмету.
Вторая глава включает базовые сведения о методологии системной инженерии, необходимые для понимания последующего текста.
В третьей главе изложено основное ядро книги, системный подход к управлению высокотехнологичными проектами в разных отраслях бизнеса. Перечислены специфические параметры управления и даны пояснения по их применению.
В четвертой главе даны сведения по управлению жизненным циклом системы и компьютеризации этого важнейшего компонента управления.
Пятая глава содержит вопросы создания, обучения и мотивации команды проекта, развития карьеры сотрудников.
В шестой главе приведены базовые сведения для менеджера об использовании инструментов цифровизации работ в экономической модели управления высокотехнологичными проектами.
В седьмой, заключительной, главе обобщены выводы по теме и показаны направления деятельности для практического применения изложенного подхода.
1.2. Современная подготовка специалистов
Основной задачей обучающих и обучаемых в области высоких технологий сегодня является исполнение противоречивых требований к подготовке персонала.
• Необходимо заметно увеличить объем материала для усвоения (т.е. тенденция «вечного студента»).
• Одновременно необходимо сократить сроки обучения специалистов для улучшения экономической отдачи.
На этом фоне непрерывно появляются новые разделы знаний, продвижение «передовых теоретических» разработок имеющихся компетенций и колоссальный информационный шум вокруг «лучших новых знаний» в связи с развитием коммерциализации обучения.
На самом деле, если непредвзято аккумулировать накопленный позитивный опыт (российский и зарубежный), задача управления сложными проектами и программами решается с помощью системного подхода вполне реалистичными методами в разумные сроки. Современный набор инструментов инженера опирается на четыре базовые направления, а именно:
1) предметная инженерия (специализацию дает ВУЗ по электронике, робототехнике, автомобилям, вертолетам, нефтехимии и т.д.);
2) система менеджмента качества (как правило, изучается в организации, обеспечивает рыночный спрос и минимизацию затрат);
3) управление проектом (нерегулярный процесс получения общих сведений из многочисленных пособий типа PMBoK и курсов для управленцев);
4) системная инженерия (на сегодня минимально доступна в РФ, «клей» для объединения вышеперечисленного, универсальное дополнение к пропущенным важным элементам инженерной науки в части технической, управленческой и организационной, системный подход, предмет настоящей книги).
Кроме того, инженерные и управленческие службы уже десятки лет работают в едином информационном пространстве (цифровизация процессов, большие объемы данных). Использование данного инструмента в той или иной степени является для менеджеров обязательным наравне со знанием технического английского языка (чтобы с пользой применять возможности интернета). В настоящее время цифровизация бизнеса стала в РФ государственной программой.
Сегодня владение перечисленным набором базовых знаний является необходимым и достаточным для исполнения любых задач промышленности, в том числе авиационной, космической, атомной, нефтеперерабатывающей и др.
На основе многолетнего опыта РФ и зарубежных лидеров рынка высоких технологий автор настаивает, что в том или ином объеме упомянутый набор знаний должен быть на вооружении как инженеров, так и менеджеров. Чтобы профессионально заниматься высокими технологиями, нужно понимать предмет работ и с инженерной, и с экономико-управленческой стороны.
Системная инженерия является достаточно простым, понятным и высокоэффективным средством обучения проектных команд и отдельных специалистов, неотъемлемой частью стандартизации подходов к высокотехнологичным масштабным проектам.
Системный подход к управлению дополняет сведения стандартов проектного управления типа PMBoK в специфичной части применения научных, инженерных и управленческих усилий для:
a) выявления потребностей клиента вместе с возможностями маркетинга, бизнеса и технологий, которые ведут к созданию системы, удовлетворяющей эти потребности;
б) преобразования эксплуатационных потребностей в описание параметров производительности системы и конфигурации системы путем использования итеративного процесса определения, синтеза, анализа, проектирования, тестирования и оценки;
в) интеграции соответствующих технических параметров обеспечения совместимости всех физических, функциональных и программных интерфейсов, чтобы оптимизировать общий дизайн системы;
г) интеграции надежности, ремонтопригодности, безопасности, живучести, человеческих и других факторов в усилия на достижение затрат, сроков графика и технических целей разработки системы;
д) работы с заинтересованными лицами программы, чтобы убедиться, что созданная система сертифицирована для удовлетворения необходимых потребностей и решения проблем клиентов.
Некоторые итоги применения системного подхода в РФ.
• Обучение системно-инженерному подходу приносит заметный практический эффект для 80…90% инженеров и менеджеров (выпускников отечественных ВУЗов) различных категорий.
• Освоение происходит в оперативном режиме, через один… два года сотрудники выходят на удовлетворительные темпы и качество работ, скачкообразно растут понимание системного подхода к задачам и эффективность.
• Заметно снижаются потери рабочего времени в проекте.
• Возрастает качество работ и получаемых результатов.
• Рост производительности труда после периода обучения составляет от 20 до 100% и далее обеспечивается стабильный прирост не менее 15…25% в год (в среднем на команду).
Несколько слов об истории системной инженерии. В ВУЗах СССР широко преподавали данную дисциплину под названием «Системотехника». К сожалению, в РФ обучение системной инженерии резко сократилось. С 90-х годов прошлого века крупнейшие правительственные учреждения и ведущие мировые компании различных стран используют системно-инженерный подход для реализации своих высокотехнологических проектов. Применение стандартов системной инженерии обязательно для контрактов военных ведомств недружественных стран и государственных заказчиков сложных систем (строительство атомных станций, мостов, космических объектов, транспортной инфраструктуры), таких как Министерство обороны США (DoD), Национальная аэрокосмическая ассоциация (NASA), компаний Boeing, Airbus, гигантов в сфере телекоммуникаций и информационных технологий (Siemens, IBM) и др.
Суть системного подхода для достижения целей в рамках управления ЖЦ состоит в комплексном решении задач управления и вопросов проектирования. Данная методология дополняет («склеивает», как сказано выше) набор стандартных дисциплин высокотехнологичного проекта. Системная инженерия охватывает все стадии мультидисциплинарной разработки продукта от замысла до внедрения, руководствуясь интересами конечного пользователя. Процесс разработки изделий в СИ включает постановку проблемы, управление требованиями, нахождение технических решений, моделирование системы, оптимизацию, разработку архитектуры, управление интерфейсами, управление конфигурацией, интеграцию системы, верификацию и валидацию, эксплуатацию, утилизацию продуктов.
Системная инженерия обеспечивает практически значимые эффекты за счет использования общего междисциплинарного языка для участников проекта, целенаправленного снижения проектных рисков, исправления ошибок на ранних стадиях, когда сделать это еще относительно дешево, на основе эффективных процессов жизненного цикла, повышения производительности команды проекта.
В современных проектах на системно-инженерные процессы выделяется статья в бюджете (от 5 до 30%, цифра возрастает в зависимости от масштабов проекта), чтобы предотвратить возможные убытки, исключить последующую переделку готового изделия [7,10]. То есть результатом системной инженерии является не увеличение прибыли, а снижение вероятных убытков проекта за счет выполнения программы в заданные сроки, в рамках бюджета, с высоким качеством согласно требованиям контракта.
Определяющая роль СИ на стартовом этапе любого высокотехнологичного проекта крайне важна, так как после формирования облика продукта реализация проекта движется по заданному пути, затраты спланированы, изменения маловероятны.
Основы системной инженерии изложены в официальных международных стандартах, задающих правила работы, применимые в этой сфере. Они выделены в семейство стандартов системной и программной инженерии. В главе 2.3 этой книги приведен перечень ряда российских стандартов ГОСТ по системной инженерии, то есть отечественная нормативная база также в наличии.
Активный интерес в мире к применению системной инженерии подтверждается тем, что данный предмет входит в учебные планы всех ведущих зарубежных университетов и ведущих российских ВУЗов.
1.3. Пространство возможностей РФ
Для российских управленцев кратко представим сведения о текущем статусе экономической среды, как базы для деятельности. Экономика РФ по паритету покупательной способности (ППС) в 2023 г. вышла на четвертое место в мире (оценка World Economics). Валовой внутренний продукт России по ППС составил $6,4 трлн. Страна закрепилась в мировой пятерке лидеров второй год подряд. Выше в списке расположились Индия ($14 трлн.), США ($27 трлн.) и Китай ($33 трлн.). В 1992 г. страна находилась в этом списке только на 35-м месте. Для понимания экономических возможностей Российской Федерации далее указаны ее места в мировом рейтинге добычи природных ресурсов, производства товаров и услуг, в основном на 2017 г.
1-е место по запасам (19,8% мировых запасов) и экспорту природного газа, 2-е по добыче (2021);
1-е по запасам лесных ресурсов (23% мировых запасов);
1-е по запасам поваренной соли и 2-е по запасам калийной соли;
1-е по запасам питьевой воды;
1-е по экспорту пшеницы и 3-е по ее урожаю (2021);
1-е по запасам олова, цинка, титана, ниобия, магния;
1-е по запасам никеля (2021);
1-е по запасам железных руд (около 28% мировых запасов);
1-е по экспорту стали и 3-е по экспорту металлопроката;
1-е по экспорту азотных удобрений, 2-е и 3-е места по экспорту фосфорных и калийных удобрений;
1-е по запасам алмазов и 2-е по их добыче;
1-е по запасам серебра;
1-е по экспорту платины и 2-е по ее запасам;
1-е по протяженности электрифицированных железных дорог;
1-е по протяженности линий экологичного транспорта (троллейбусы, электробусы, трамваи и метро);
1-е по количеству проданных на экспорт самолетов-истребителей;
1-е по поставкам на экспорт средств ПВО средней и малой дальности;
1-е по экспортным контрактам на сооружение атомных электростанций;
2-е место по производству первичного алюминия (2020);
2-е по запасам редкоземельных металлов;
2-е по количеству парка вертолетов;
2-е по величине подводного флота;
3-е место по запасам каменного угля (23% мировых запасов) и 3-е по его экспорту;
3-е по числу ежегодных запусков космических аппаратов (2022);
3-е по добыче нефти (2021) и 2-е по ее экспорту;
3-е по производству никеля, вольфрама и авиационного титана (2022);
3-е по запасам золота, 2-е по его добыче (2021);
3-е по запасам меди и свинца, вольфрама и молибдена, лития и рения;
3-е по производству цемента (2021);
3-е по числу абонентов сотовой связи;
3-е по производству продуктов нефтехимии;
3-е по производству сахара-песка (2020);
3-е по поставкам вооружения всех видов;
4-е место по количеству ежегодно печатаемых книг и 4-е по числу переводов с них (доказательство заметного мирового интереса к культуре и жизни в РФ!);
4-е по производству электроэнергии (2021);
4-по запасам урана и 7-е по его добыче (2020);
5-е место по добыче угля, синтетического каучука, калийных удобрений, производству стали (2021);
5-е по производству рафинированной меди;
5-е по производству мяса свинины и мяса птицы (2021);
6-е место по производству натурального молока и растительных масел (2021);
9-е место по производству зерна, черных и цветных металлов, целлюлозы, пиломатериалов.
За 2022 и 2023 гг. в РФ введено в строй более 590 новых значимых производственных объектов (с инвестициями от 150 млн. руб.).
Располагаемые запасы природных ресурсов, уровень развития в промышленной, энергетической, добывающей и сельскохозяйственной сферах представляют уникальную базу для дальнейшего экономического развития нашего государства.
В 2024 г. Правительство РФ выделило 12 национальных проектов, реализация которых нацелена на оперативное достижение технологического суверенитета в критически важных отраслях:
1) станкостроение и робототехника,
2) новые материалы и химия,
3) обеспечение продовольственной безопасности
4) новые медицинские технологии.
5) развитие беспилотной авиации,
6) развитие космической отрасли,
7) атом и новые источники энергии,
8) производство судов и судового оборудования,
9) гражданская авиация,
10) микроэлектроника,
11) экономика данных,
12) наука и университеты.
Все они нацелены на организацию производства новой продукции на основе собственных линий разработки. Эти проекты также затрагивают кадровую политику, средства производства и интеллектуальные права.
В мире будет развиваться аддитивное фабричное производство, стимулируя расширение индивидуализации и производства по требованию. Это повлияет на развитие новых бизнес-моделей и отношений между клиентом и производителем. Расширяется использование алюминия, титана, редкоземельных металлов, полимерных, керамокомпозитных, высокотемпературных материалов и сплавов для снижения массы, повышения рабочих температур, удешевления узлов и продуктов в целом. Идет активное внедрение новых материалов в части направленного проектирования и изменения структуры и свойств материала продукта, включая обширный класс метаматериалов. Ведутся работы по новым источникам энергии, в том числе внедрение сверхпроводимых установок, водородных и топливных элементов, литий-ионных и других комбинаций аккумуляторов, развитие методов проектирования, направленных на сокращение энергозатрат. Применение роботов на всех этапах жизненного цикла продукции с расширяющимся спектром приложений будет влиять на повседневную жизнь, а также на производственную практику.
Обладание полным циклом создания и производства таких высоких технологий, как авиация, космос, атомная энергия, нефтехимия, электроника является прерогативой небольшой группы стран, технологических лидеров, куда входит и Российская Федерация. Российским управленцам необходимо постоянно учиться организационно и эффективно работать. РФ имеет огромный технологический задел, созданный в минувшие годы, обширную географию природных условий, уникальный опыт мирного сосуществования людей сотен национальностей. В настоящий момент ряд отечественных отраслей испытывает высокую потребность в конкурентоспособных продуктах, созданных в соответствии с международными стандартами. Санкции подталкивают предприятия трудиться еще интенсивнее. При этом слабо используется один важный ресурс развития страны.
Производительность труда в высокотехнологичных отраслях зависит от ряда факторов, в том числе от организации работ по созданию новых продуктов и систем, наращивания импортозамещения, исторического наследия в части послепродажного обслуживания поставленной техники, инфраструктуры и роботизации производства, уровня подготовки персонала. Этот показатель является ключевым резервом РФ в продвижении по пути развития новых технологий, так как ресурсы количественного роста персонала ограничены.
Сегодня мы заметно отстаем, например, от лидеров мировой авиационной промышленности в 5…8 раз по выработке на сотрудника. Статистика для авиационной промышленности мира по данным журнала «Эксперт» (2017 г.) показана на рис. 1. Аналогичная картина по производительности труда в ряде других высокотехнологичных отраслей.
Рис. 1. Производительность труда в мировом авиапроме
О том, как ликвидировать имеющиеся пробелы, чтобы результативно использовать на практике управленческие технологии системной инженерии для повышения эффективности проектов и программ, рассказано далее в этой книге.
Глава 2. База системной инженерии
2.1. Определение системной инженерии
Основным объектом приложения системной инженерии являются системы. Системой кратко называют интегрированный сплав людей, продуктов и процессов, обеспечивающий возможность удовлетворить требуемые нужды или цели.
Перечислим некоторые типы систем. Это бизнес-системы (управление исследованиями и разработками, производством продуктов и услуг для использования на рынке), образовательные системы (обучение и аттестация), финансовые системы (поддержка личных, коммерческих и других финансовых операций), правительственные системы (связанные с управлением людьми как обществом на уровне государства, области, города и т.д.), медицинские системы (больницы, врачи и терапевтические учреждения, управляющие потребностями здравоохранения населения), транспортные системы (наземные, морские, воздушные и космические перевозки людей и грузов), газо- и нефтеперекачивающие трубопроводные системы, городские системы (управление инфраструктурой и транспортом района, города, области), культурные системы (исполнительское искусство музыки и других развлечений, гражданские модели поведения) и др.
Примеры систем (по возрастанию сложности):
•двигатель самолета по сравнению с набором деталей;
• самолет с двигателями и авионикой;
• авиатранспортная система (АТС) с самолетами, пассажирами, грузами, тренажерами и др.;
• система систем, включая АТС, аэропорты, инфраструктуры обслуживания и наземного наблюдения.
Приведем определения из стандарта ГОСТ 56136—2014.
У каждой системы имеется жизненный цикл (ЖЦ). Это совокупность явлений и процессов, повторяющаяся с периодичностью, определяемой временем существования изделия (системы), от начала разработки до вывода из эксплуатации (утилизации).
Этапом жизненного цикла называют часть ЖЦ, выделяемую по признакам моментов контроля (контрольных рубежей), в которых предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.
Жизненный цикл проекта можно разбить на отдельные фазы, отделенные контрольными рубежами (воротами принятия решений). У NASA 7 фаз ЖЦ, в GE их 10, у Airbus 14 последовательных этапов. Пример ЖЦ системы показан на рис. 2.
Рис. 2. Типовые этапы жизненного цикла системы
Контрольный рубеж (КР) этапа жизненного цикла является моментом завершения этапа ЖЦ, на котором предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.
Перечислим основные фазы ЖЦ продукта и типовые контрольные рубежи (КР), или ворота принятия решений, на различных этапах модельного ЖЦ программы создания изделия, показанные на рис. 2.
1. Предварительный анализ изделия (КР 0).
2. Маркетинг для определения бизнес-возможности создания разрабатываемого продукта (КР 1).
3. Концептуальное проектирование и оценка выполнимости (КР 2).
4. Определение облика изделия, эскизный проект (КР 3).
5. Изготовление опытных образцов (КР 4).
6. Утверждение («замораживание») конструкции (КР 5).
7. Испытания и сертификация продукта (КР 6).
8. Производство и эксплуатация (КР 7).
9. Вывод из эксплуатации и закрытие программы (КР 8).
Декомпозиция проекта на этапы ЖЦ переводит организацию процесса разработки на более мелкие и управляемые части. Переход фазовых границ определяется в пунктах оценки прогресса проекта и решений типа «идти / не идти». То есть на контрольном рубеже следует принять решение, продолжать ли проект на следующем этапе, вернуться к чертежной доске и переделать текущую работу завершаемой фазы, или прекратить проект.
Этапы жизненного цикла используют, чтобы помочь планировать и управлять всеми основными событиями разработки высокотехнологичной сложной системы или продукта. Разделение на фазы дает менеджерам возможность контролировать и направлять действия осознанно, упорядоченно и методично, что позволяет реагировать на изменения. Это увеличивает прозрачность и упрощает контроль для успешного завершения проекта.
ЖЦ проекта представляет собой важный управленческий инструмент, который используется для распределения ресурсов, обеспечения доступности ключевых лиц, интеграции действий, поддержки своевременного принятия решений, снижения рисков и создания механизмов контроля и руководства. Так как ранние решения влияют на последующие деятельности и «более зрелую» систему труднее изменить по ходу проекта, в системной инженерии сделанное на ранних стадиях имеет наибольшее влияние на успех проекта в целом.
В истории человечества следы системно-инженерного подхода заметны при сооружении египетских пирамид, римских дорог, азиатских ирригационных каналов и других известных объектов, дошедших до наших дней. Например, «подушку» под римской дорогой для колесниц укладывали по правилам того времени из различных материалов до 5 метров толщиной. Спустя столетия эти дороги заасфальтированы и используются для современных автомобилей. Каменные мосты через реки в некоторых голландских городах используются без ремонта на протяжении 300…400 лет. Т.е. выполнено условие, когда действия на каждой фазе ЖЦ системы были направлены на улучшение жизненного цикла на последующих этапах.
Великий российский инженер XIX—XX веков Владимир Шухов за годы профессиональной деятельности реализовал со своими подрядными коллективами более 700 проектов. При этом уровень работ находился на вершине тогдашних инженерных знаний, оформлены патенты мирового уровня: горизонтальный и вертикальный паровые котлы, форсунка для мазута, нефтеналивная баржа, стальной цилиндрический резервуар, висячее сетчатое покрытие для зданий, арочное покрытие, нефтепровод, промышленная крекинг-установка, ажурная гиперболоидная башня (телецентр на Шаболовке в Москве). Всего построено около 200 башен, около 500 мостов, зерновые элеваторы, доменные печи, плавучие ворота сухого дока, вращающаяся сцена МХАТ.
План ГОЭЛРО в послереволюционной России был утвержден в декабре 1921 г. и к 1930 г. перевыполнен. В результате Россия вышла на 3-е место в мире по производству электроэнергии.
Причинами возникновения системной инженерии в ее сегодняшнем виде стали факторы, появившиеся в мире после Второй мировой войны. Активизировалась реализация больших программ, в первую очередь военно-промышленного направления, и основными приводами развития управленческой мысли стали:
1) развитие затратных высокотехнологичных программ с учетом управления рисками и информационных технологий;
2) активизация рыночного соревнования между странами и компаниями (развитие маркетинга);
3) углубление специализации разрабатываемых систем, что выявило важность типовой декомпозиции элементов, управления требованиями, интерфейсами, верификации и валидации;
4) нарастание кадровых проблем для высокотехнологичных отраслей.
Появились книги, справочники и стандарты по теме: H. Good, R. Machol, Системотехника. Введение в проектирование больших систем (1957 г.), справочник Военно-воздушных сил США по системной инженерии (1966 г.), первый СИ стандарт MIL-STD 499 (1969 г.). В СССР один из первых курсов СИ был издан в 1976 г., В. Дружинин, Д. Конторов «Вопросы военной системотехники».
Примененные технологии системной инженерии облегчили успешное получение конкурентоспособных разработок. Переход на командные методы работы по ролям упростил создание результативных коллективов с эффективными лидерами. Для реализации этих задач необходимо было обучить многочисленный персонал. Вследствие необходимости создания новых изделий и освоения высоких технологий ряду стран удалось стандартизовать подготовку творческих инженеров и менеджеров на основе подходов СИ. Сегодня все компании высокотехнологичного сектора имеют справочники системной инженерии в открытом доступе в сети интернет, адаптированные под нужный профиль (в перечне указан год актуального издания).
• Некоммерческое общество системных инженеров INCOSE, 5 изд., 2023 [10].
• Космическое агентство NASA, 3 изд., США, 2017 [7].
• Администрация гражданской авиации США FAA, 2015.
• Компания-интегратор интеллектуальных транспортных систем ITS, 3 изд., 2009.
• Министерство обороны США, DoD, 2006.
• Компания-интегратор авиатехники Airbus, 2004.
• Производитель авиационной техники Boeing, 2003.
При этом перечисленные документы включены для обязательного исполнения в требования для подрядчиков и поставщиков, чем обеспечивается скорость и глубина внедрения методологического подхода.
Приведем актуальные определения предмета книги от общества сиcтемных инженеров INCOSE (2019) и стандарта ISO/IEC/IEEE 15288 (2023).
Системой называют совокупность расположения частей или элементов, которые вместе демонстрируют поведение или значение, которого нет у отдельных компонентов. Системы могут быть физическими, концептуальными (абстрактными информационными), или их комбинацией.
Системной инженерией называют трансдисциплинарный и интегративный подход, позволяющий успешно реализовывать, использовать и выводить из эксплуатации спроектированные системы с использованием системных принципов и концепций, а также научных, технологических и управленческих методов.
СИ фокусируется на:
• установлении, балансировке и интеграции целей заинтересованных сторон, целей и критериев успеха, а также определении фактических или ожидаемых потребностей заинтересованных сторон, операционных концепций и требуемой функциональности, начиная с раннего цикла разработки;
• установлении соответствующей модели жизненного цикла, процессного подхода и структур управления с учетом уровней сложности, неопределенности, изменений и разнообразия;
• создании и оценке альтернативных концепций и архитектур решений; базовых требований и моделирования выбранной архитектуры решения для каждого этапа проекта;
• выполнении синтеза проекта, верификации и валидации системы;
• принятии во внимание проблемных и решающих областей, необходимых систем и служб обеспечения, определении ролей и отношений между частями системы для ее общего поведения и производительности, и балансировке всех этих факторов для достижения удовлетворительного результата.
Процесс СИ завершается интеграцией трех основных активностей:
1) фаза разработки, которая контролирует процесс проектирования и обеспечивает базовые результаты, увязывающие проектные усилия;
2) системная инженерия процесса, обеспечивающего структуру для решения проектных проблем и отслеживающего поток требований через проектные усилия;
3) интеграция жизненного цикла, которая вовлекает заказчиков в проектный процесс и обеспечивает жизнеспособность разработанной системы на всех стадиях ЖЦ.
Инженерной называют систему, разработанную или адаптированную для взаимодействия с ожидаемой эксплуатационной средой для достижения одной или нескольких предполагаемых целей при соблюдении применимых ограничений. Инженерные системы могут включать людей, продукты, услуги, информацию, процессы и природные элементы.
Инженерный менеджмент, как часть процессов системной инженерии, включает искусство и науку планирования, организации, распределения ресурсов, а также управления и контроля деятельности, имеющей технологический компонент.
Отметим, что в определении СИ сделан упор именно на управленческую часть системно-инженерного подхода. Применение СИ на практике позволяет вовремя выполнять решение сложнейших задач, сокращать сроки и стоимость разработок в 1,5…2 раза, снижать количество ошибок в конструкторской документации от 2 до 5 раз. Системная инженерия демонстрирует эффективность разработанных подходов, является выгодным инструментом создания новых изделий, ведет к уменьшению затрат путем оптимизации процессов и исключения переделок (из-за увеличения глубины проработки и исправления ошибок на ранних стадиях проекта). Подход СИ снижает коэффициент экспоненты убытков на масштабе бюджета проекта, причем чем крупнее проект, тем выше эффект применения СИ. Статистика NASA показала, что можно снизить перерасход бюджета на 20…90% (от мелких до очень крупных проектов). При этом оптимальная доля затрат на деятельность системных инженеров составит от 5 до 35% соответственно [7].
В стандарте «Процессы жизненного цикла систем» ISO 15288:2015 (ГОСТ Р 57193—2016) сегодня перечислены 30 базовых процессов жизненного цикла систем (рис. 3). Эти процессы разделены на четыре основные группы.
Рис. 3. Базовые процессы жизненного цикла систем
При разработке систем, продуктов или услуг необходимо найти ответы на несколько фундаментальных вопросов.
1. Что такое система?
2. Что входит в границы системы?
3. Какую роль играет система в организации пользователя?
4. Какие действия в эксплуатации выполняет система?
5. Какие ориентированные на результаты выходы дает система?
При разработке нового продукта требуется организовать структуру, которая оптимизирует управление и руководство, облегчает внутренний обмен информацией, принятие решений и потоки поставок. Рынки высоких технологий требуют от нового продукта удовлетворения уровня качества при запланированных расходах и, что критично, в заданные сроки. Координация инжиниринга, производства, обеспечения качества, маркетинговых функций в процессе разработки нового продукта является жизненно важной. Необходимость использования подходов системной инженерии обусловлена несовершенством устаревших процессов разработки новых изделий. Результатом применения системной инженерии будет повышение качества исполнения программ (выполнение проектов в заданные сроки, в рамках бюджета, согласно требованиям, с высоким качеством).
Для реализации проектов и программ в системной инженерии используют основные варианты декомпозиции.
• Декомпозиция проблемы: разделение сложной проблемы на более простые позволяет легче найти решение и четко сформулировать задачи для каждого сотрудника.
• Декомпозиция времени: разбиение проекта на фазы с указанием конкретных результатов позволяет эффективно контролировать процесс разработки, измерять эффективность и вовремя применять корректирующие меры.
• Декомпозиция продукта: разделение самых сложных изделий на системы, подсистемы, сборки и узлы позволяет эффективно управлять конфигурацией и поставщиками.
• Декомпозиция действий с последующей интеграцией: определяет четкую последовательность необходимых действий (требования, спецификация, декомпозиция, проект, интеграция, верификация, эксплуатация, вывод из эксплуатации).
СИ учитывает деловые и технические потребности приобретателей с целью предоставления качественного решения, которое отвечает требованиям заинтересованных сторон, подходит для достижения цели в эксплуатации и позволяет избежать или минимизировать неблагоприятные непреднамеренные последствия.
Целью всех видов деятельности СИ является управление рисками, включая степень снижения рисков непредоставления того, что хочет приобретатель, риска несвоевременной поставки, риска избыточных затрат и риска негативных непреднамеренных последствий.
2.2. Системное мышление
В процессе реализации высокотехнологичных проектов приходится преодолевать текущие вызовы:
1) интеграции развивающихся информационно-емких систем и технологий;
2) множества заинтересованных сторон с потенциально расходящимися точками зрения и политически мотивированными программами, дефицитными и динамично меняющимися ресурсами, доступными для поддержки проекта или программы;
3) постоянно меняющиеся требования для выполнения;
4) технологические достижения, которые нужно потенциально совместить с имеющимися и развивающимися инфраструктурами для поддержки;
5) срочность реагирования на изменения в операционных предположениях;
6) возрастающие сложности и неопределенности жизненного цикла систем.
Мышлением называют функцию человеческого мозга, отвечающую за концептуальное отражение существенных общих законов в предметах и процессах объективной действительности. Системное мышление (СМ) может предоставить менеджерам и лидерам инженерных специальностей ценные возможности для более эффективного решения упомянутых сложных проблемных областей.
СМ можно определить как новый способ взглянуть и мысленно сформировать видимые сущности; мировоззрение и образ мышления. Где следует видеть сущность или единицу в первую очередь как единое целое, с его соответствием и отношением к окружающей среде. В основе СМ лежит концепция целостности (холизма), которая предполагает, что понимание сложной системы должно охватывать уровень всей системы. Системное мышление определяет целостную философию, способную раскрыть критическую структуру системы: ее границы, входы, выходы, пространственную ориентацию, структуру процессов и сложные взаимодействия системы с окружающей средой. СМ позволяет определить для конкретной задачи набор основных системных принципов, чтобы руководить инженерами на базе более эффективного мышления, решений, действий и интерпретаций для лучшего понимания и разрешения сложных проблемных областей. Разбиение системы на составные части не дает адекватного понимания того, как система функционирует в целом.
Возрастающую сложность можно представить как динамичную, неопределенную, возникающую ситуацию, содержащую большое количество тесно взаимосвязанных элементов и факторов. Диапазон альтернатив индивидуальных точек зрения, целей и предполагаемых интересов усложняет согласование для продвижения вперед. При этом непредвиденные факторы могут включать распределение ограниченных ресурсов, контроль исполнения, личные предпочтения, интересы и др. В сложных проблемных областях заинтересованными сторонами следует считать тех физических или юридических лиц, которые имеют прямой или предполагаемый интерес в решении проблемы, что расширяет их круг, в том числе по мере изучения проблемной области.
Границы сложных систем неоднозначны. Их критерии являются произвольными и часто качественными по своему характеру. Природа границ может принимать различные формы (например, географические, временные, концептуальные, функциональные, физические), которые могут меняться со временем.
В настоящее время объем перерабатываемых для реализации проекта данных и информации растет в геометрической прогрессии. Нужны разработки эффективных подходов к сканированию, фильтрации, сокращению и преобразованию информации в действенные формы. Часто лидерам программ приходится пробираться через «болото» информации, стремясь определить выборки, которые необходимы для принятия решений и действий.
Происходящая смена поколений в рабочей силе вносит дополнительные вопросы в проблемную область. При интеграции командных усилий для создания систем необходимо преодолевать различия между поколениями. В части длительных сроков разработки новых продуктов следует понимать, что используемые знания могут носить временный характер, неполны и подвержены ошибкам.
Использование системного мышления расширяет когнитивные навыки, то есть умственные способности, связанные с тем, как мозг человека обрабатывает информацию об окружающем мире. К ним относятся внимание, память, логика и мышление, визуальная и слуховая память, скорость обработки информации, ответных реакций, регуляция эмоций и др. Это облегчает формулирование проблем, представляя набор доступных альтернатив для решения. Принимаемые решения неизбежно оказывают влияние на другие компоненты в системе, давая возможность делать осознанный выбор.
Для реализации принципов системного мышления рекомендуется действовать следующим образом.
На первом этапе необходимо провести всесторонний анализ текущей ситуации с учетом ее потенциального влияния на возможности, потребности организации и заинтересованных сторон посредством оценки технологических рисков и уровней готовности технологии. Оценивают потенциальные решения об осуществимости.
Второй этап включает выявление и определение желаемой цели, требований бизнеса, а также потребностей заинтересованных сторон. Также необходимо тщательно рассмотреть оценку затрат и планирование процесса разработки.
Третий этап содержит разработку различных типов концепций. Определяют несколько альтернатив для данной концепции, в которых потенциально предложены возможности, повышение производительности или сокращение расходов.
Четвертая фаза включает оценку и выбор предпочтительных альтернатив концепций. СМ подчеркивает необходимость их тестирования и оценки. Модели и прототипы здесь незаменимы для более глубокого понимания потребностей заинтересованных сторон, принятия архитектурных компромиссов, выявления рисков и возможностей.
Для повышения эффективности системного мышления полезно использовать некоторые общие принципы выбора альтернатив его применения.
Выбор сложности (многомерных проблем, рабочих решений) или простоты (избегания неопределенности, работы над линейными проблемами, предпочтения лучших решений и мелкомасштабных задач).
Позиция глобальной интеграции (зависимых решений и мирового уровня производительности) или автономии (независимых решений и местного уровня производительности).
Взаимодействие глобального типа (следовать общему плану, работа в команде и меньше интересов в причинно-следственных связях) или изоляции (склонность к локальному взаимодействию, подробному плану, предпочтение работать индивидуально, в небольших системах и больше интереса к причинно-следственным решениям).
Непротивление изменениям требований (принимать во внимание несколько точек зрения, уделять больше внимания долгосрочным планам, лучше работать в меняющейся среде) или принятие неизменных требований (больше сосредотачиваться на краткосрочных планах и мышлении, иметь тенденцию фиксировать решения и лучше работать в стабильной среде).
Типовые ошибки при решении системных проблем включают, например, такие пункты.
• Выбор неправильных заинтересованных сторон. Отсутствие их достоверного учета может сделать системное решение неадекватным до его развертывания.
• Узкий набор вариантов, когда из-за быстрого исключения возможных альтернативных системных опций из исследования выпадают потенциально эффективные решения.
• Неверно определены суженные границы системы, что может привести к поиску решений неправильной системной проблемы.
• Неправильная формулировка проблемы, когда язык и способ ее описания могут привести к ограничению возможных подходов исследования системы.
• Неспособность применения СМ, тогда как сложные системные проблемы должны рассматриваться комплексно с точки зрения взаимосвязей, шаблонов и границ.
Полезно принимать во внимание несколько принципов, чтобы помочь избежать потенциальных ловушек при применении системного мышления.
1. Уникальность проблемы и потребности. Даже при наличии сходства с предыдущими задачами предположение об уникальности имеет решающее значение для избегания поспешной предрасположенности к конкретному подходу, который мог быть успешным ранее.
2. Уникальность контекста проблемы, набора обстоятельств, факторов, условий или закономерностей, которые ограничат проблему системы и возможные решения.
3. Уникальность методологии развертывания, которая должна быть совместимой и подходящей для конкретной задачи, которая в свою очередь должна быть совместима с решаемой проблемой и содержанием.
4. Системное обрамление. При выработке целостного видения ситуации, разрабатывая несколько правдоподобных сценариев, инженеры и менеджеры должны открывать потенциальное пространство для принятия решений.
5. Предвидение появления системы как результата предполагает сосредоточение внимания на альтернативах, которые можно выявлять, анализировать, эффективно реагировать и оценивать для решения возникающих условий.
2.3. Управление жизненным циклом проекта и продукта
Задача управления жизненным циклом системы состоит в создании управленческих механизмов для принятия локальных решений на каждой из стадий ЖЦ, учитывая все последствия для следующих этапов, и затем позволяют вносить необходимые корректировки в процессы на других стадиях ЖЦ. Сложность объектов, созданных инженерами, определяется их размерами и количеством частей. Если современный пассажирский самолет включает примерно 100 тысяч деталей (без учета крепежа), то нефтяная океанская платформа насчитывает до 10 миллионов деталей. В системной инженерии представлены правила, инструменты и технологии для разработки продуктов и систем любой сложности.
В начале процесса управления жизненным циклом объекта разработки необходимо сделать следующее:
a) определить, что является базовой системой;
b) описать общие этапы жизненного цикла проекта, их цели, деятельности, продукцию и ворота принятия решений, которые их разделяют;
c) описать типичные цели разработки для каждой из фаз ЖЦ проекта.
Основными задачами управления жизненным циклом сложной техники, затрагивая разные фазы ЖЦ, являются (перечень не исчерпывающий, подробности см. в главе 4).
1. Управление процессом проектирования и разработки продукта.
2. Управление процессом технологической подготовки производства.
3. Управление процессом производства.
4. Управление процессами закупки ПКИ, материалов, заготовок, запчастей.
5. Управление процессом испытаний изделия (стендовых, сертификационных, государственных, приемо-сдаточных).
6. Управление процессом логистической поддержки изделия.
7. Управление процессом ППО.
8. Управление процессами подготовки эксплуатирующего состава и персонала ППО.
9. Обеспечение качества на всех этапах ЖЦ за счет процессов управления качеством, управления конфигурацией, реализации процессов системной инженерии.
10. Обеспечение планируемого темпа производства продукта.
11. Достижение заданной трудоемкости разработки и изготовления системы.
12. Управление процессом утилизации при списании изделия.
13. Управление информационной поддержкой всех процессов (с учетом циклов развития аппаратного и программного обеспечения).
Типовое описание процессов жизненного цикла показано на рис. 4. Каждый процесс состоит из входа, действия и выхода, дополненных функциями управления и обеспечения.
Рис. 4. Типовая схема процесса ЖЦ
Структура управления жизненным циклом системы включает все, что должно быть сделано для выполнения программы или проекта в различных фазах, разделенных точками принятия ключевых решений или контрольными рубежами (КР). Напомним, что КР это события, в ходе которых лицо, принимающее решение, определяет готовность программы или проекта к переходу на следующий этап жизненного цикла. В соответствии со стандартом ГОСТ Р 57193—2016 на контрольных рубежах ЖЦ должны быть выполнены главные задачи программы за предыдущую стадию: гарантировано, что последующая доработка организационных и технических базисов приемлема и приведет к удовлетворительной верификации и валидации продукта; обеспечена приемлемость риска перехода на следующую стадию; продолжено стимулирование командной работы поставщика и заказчика.
Утверждение решений на КР следует за проведением технического обзора (совещания или группы совещаний), который основывается на строгом доказательстве соответствия результатов проведенного этапа критериям контрольного рубежа.
Для каждого контрольного рубежа программы устанавливаются входные и выходные критерии. Новые мероприятия не начинаются, пока предыдущие мероприятия, от которых они зависят, не закончатся успешно. На каждом контрольном рубеже имеется набор вариантов решения:
a) приемлемо: переходить к следующей стадии проекта;
b) приемлемо с оговорками: переходить и выполнить затребованные действия, устранив замечания (проверка исполнения замечаний проводится, как правило, на следующем кр);
c) неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность;
d) неприемлемо: вернуться на предыдущую стадию;
e) неприемлемо: заморозить мероприятия проекта;
f) невосстановимо: закрыть проект.
Важными среди базовых процессов жизненного цикла изделия являются проектные процессы, относящиеся к управлению проектами и их поддержка. Налаживание взаимосвязи между процессами в ходе их реализации является одной из основных задач планирования процедур системной инженерии при создании изделия или системы.
Сегодня требования системной инженерии изложены в ряде стандартов ГОСТ РФ.
• ГОСТ Р 57193—2016 (ISO/IEC/IEEE 15288:2015). Системная и программная инженерия. Процессы жизненного цикла систем.
• ГОСТ 56136—2014. Управление жизненным циклом продукции военного назначения. Термины и определения.
• ГОСТ 56135—2014. Управление жизненным циклом продукции военного назначения. Общие положения.
• ГОСТ Р 57100—2016 (ISO 42010:2011). Системная и программная инженерия. Описание архитектуры.
• ГОСТ Р 57101—2016 (ISO/IEC/IEEE 16326:2009). Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.
• ГОСТ Р 58876—2020. Системы менеджмента качества организаций авиационной, космической и оборонной промышленности. Требования.
• ГОСТ Р 59194—2020 Управление требованиями. Основные положения.
• ГОСТ Р 59193—2020. Управление конфигурацией. Основные положения.
• ГОСТ Р 58054—2018. Изделия авиационной техники. Управление конфигурацией. Общие положения.
• ГОСТ Р 56923—2016. Информационные технологии. Системная и программная инженерия. Процессы жизненного цикла программных средств.
Продвижение по звеньям процесса по мере разработки сопровождается верификацией каждого шага, возвратом к предыдущему результату для проверки прогресса работ. При формировании процессов используют особенности описания систем, изложенные в стандарте ГОСТ Р 57193—2016:
a) важность определенных границ, которые влияют на формирование значимых потребностей и практических решений;
b) иерархическое восприятие физической структуры системы;
c) объект любого уровня иерархической структуры может рассматриваться как система;
d) характерные свойства на границе системы возникают в результате взаимодействия между элементами системы;
e) люди могут рассматриваться как внешние пользователи по отношению к системе (например, экипаж самолета) и как элементы в рамках системы (например, персонал завода-производителя);
f) система может рассматриваться как отдельный, изолированный от внешней среды объект.
Выделим 12 последовательных этапов разработки системы, которые включают следующие задачи.
1. Комплексное техническое планирование, включая формирование планов процессов СИ и продуктов.
2. Управление требованиями: определение и управление требованиями, которые описывают желаемые характеристики системы.
3. Функциональный анализ: описание функциональных характеристик (что система должна делать), которые используются для получения требований.
4. Маркетинговая оптимизация: информация по принятию решений на основе анализа и отбора наиболее сбалансированных решений по требованиям рынка.
5. Синтез: этап преобразования требований в физические решения верхнего уровня системы.
6. Управление интерфейсами: определение и управление взаимодействиями между сегментами в рамках системы или взаимодействиями с другими системами.
7. Специализированная (тематическая) инженерия: анализ системы, требования, функции, решения и интерфейсы с использованием специальных навыков и инструментов. Помощь в получении требований, синтезе решений, выборе альтернатив, а также валидации (то ли мы сделали) и верификации (так ли это работает) требований.
8. Целостный анализ: проверка, что выполненная интеграция системы обеспечила требуемый уровень точности и аккуратности.
9. Управление рисками и возможностями: определение, анализ и управление неопределенностями достижения требований программы путем разработки стратегий для снижения вероятности таких неопределенностей.
10. Управление конфигурацией: установление описания и поддержка базовой системы, управление изменениями в характеристиках системы, функциональных и физических свойствах.
11. Проверка (верификация) и контроль (валидация). Верификация определяет, что требования к системе являются правильными. Валидация определяет, что реализованное решение отвечает утвержденным требованиям.
12. Инженерия жизненного цикла: определение и управление требованиями к свойствам жизненного цикла системы, в том числе управление разработкой продукта, развертывание и передача работ, интегрированная поддержка логистики, технологическая производственная часть и вывод из эксплуатации. Разработка навыков и стандартизации для постоянного улучшения результативности и эффективности процессов и инструментов СИ (выявление, документирование и изучение уроков проектов).
Наиболее контролируемым параметром является стоимость жизненного цикла (СЖЦ), то есть общая стоимость программы или проекта за запланированный жизненный цикл от формулировки до реализации. Для долгосрочных (на десятилетия) программ, таких как программы серийного выпуска авиационной техники или функционирования международной космической станции с полетами человека в космос, трудно установить продолжительность жизненного цикла для целей определения СЖЦ. Подробности приведены в главе 4.
Процесс разработки (ЖЦ проекта) в системной инженерии можно представить в виде нескольких взаимосвязанных итерационных петель (рис. 5).
Рис. 5. Процесс разработки системы, MIL_Std-499
Вышеприведенные шаги системной инженерии для удобства иногда декомпозируют, выделяя набор из 33 подпроцессов ЖЦ проекта (стандарт EIA 632 «Process for the Engineering of a System», имеет рекомендательный статус).
А. Поставки.
1. Поставка товаров.
Б. Приобретения.
2. Приобретение товаров.
3. Оценка производительности поставщика.
В. Планирование.
4. Стратегии реализации процесса.
5. Определение технических усилий.
6. График и организация работ.
7. Технические планы.
8. Указания (директивы) для работы.
Г. Оценки.
9. Прогресс исполнения планов и графиков.
10. Оценка соответствия требованиям.
11. Технические обзоры проекта.
Д. Управление.
12. Результаты управления.
13. Распространение информации.
Е. Определение требований.
14. Требования Заказчика.
15. Требования других заинтересованных сторон.
16. Технические требования к системе.
Ж. Определение проектных решений.
17. Представление логических решений.
18. Представление физических решений.
19. Указанные требования.
З. Реализация.
20. Реализация проекта.
И. Передача Заказчику.
21. Ввод в эксплуатацию.
К. Системный анализ.
22. Анализ эффективности.
23. Анализ рыночных альтернатив.
24. Анализ рисков.
Л. Верификация требований.
25. Проверка статуса требований.
26. Проверка требований Заказчика.
27. Проверка требований других заинтересованных сторон.
28. Проверка технических требований к системе.
29. Проверка представления логических решений.
М. Верификация системы.
30. Проверка конструктивных решений.
31. Проверка конечного продукта.
32. Проверка готовности продукта к эксплуатации.
Н. Валидация конечного продукта.
33. Сертификация конечного продукта.
Выявление свойств и характеристик будущей системы начинается с задачи маркетингового исследования рынка. Постановка решаемой проблемы должным образом является одной из важнейших задач системного подхода, потому что элегантное решение неправильной проблемы меньше чем бесполезно.
Постановка задачи маркетологам описывает потребности клиента, заявляет цели проекта, очерчивает предмет проблемы, определяет концепцию эксплуатации, описывает заинтересованные стороны формируемой программы, перечисляет требуемые результаты и представляет основные решения, которые должны быть сделаны. Специалисты по маркетингу в процессе исследования должны:
•определить цели исследования ниши на рынке;
• изучить имеющиеся материалы, включая конкурентную среду, ограничения и допущения;
• выбрать критерии оценки продукта или системы и их относительную значимость (они могут быть качественными и количественными);
• определить и выбрать вероятные альтернативы исполнения системы;
• оценить эффективность каждого варианта для каждого критерия;
• выполнить анализ чувствительности для избранных вариантов;
• сравнить результаты и выбрать предпочтительный вариант продукта;
• задокументировать процесс изучения рынка и его результаты;
• сформировать бизнес-план для обоснования развития будущего продукта или системы.
Рыночная привлекательность продукта определяется набором его преимуществ (характеристики, например, для авиации стоимость пассажиро-километра, масса, надежность, наличие ППО, стоимость владения и др.). Критерии принятия решений на рынке могут быть назначены на основе мер эффективности (голос клиента) и показателей эффективности (голос инженера).
В целом критерии могут быть общими (атрибуты, имеющие значение для каждого элемента структуры продукта, такие как масса или надежность) или уникальными (атрибуты, которые имеют смысл только для определенных элементов изделия). На более низких уровнях структуры (подсистемы, компоненты) отслеживание стоимости количественных оценок можно идентифицировать с помощью функциональных и эксплуатационных требований, отнесенных к каждой отдельной системе, подсистеме и т. д.
В заключение этапа маркетинга проводится проверка финального выбора продукта. При этом необходимо выяснить:
1) были ли выполнены требования к системе и установленные ограничения;
2) является ли предварительный выбор финального варианта сильно зависящим от определенного набора входных значений и допущений или устойчивым при разумном изменении входных значений (т.е. насколько он «надежен» по чувствительности к изменению условий эксплуатации);
3) достаточны ли имеющиеся данные для утверждения предварительного выбора;
4) достаточно ли независимы методы измерения, чтобы дать уверенность, что выполненный предварительный отбор лучше отброшенных альтернатив;
5) если результаты нескольких альтернатив близки, необходим ли дальнейший анализ;
6) является ли предварительный выбор чувствительным к оценочной характеристике или ограничению. Если «да», то следует проверить полный разумный диапазон изменения каждой переменной, чтобы уточнить область, где предварительный выбор обоснован.
Ожидаемые результаты маркетинга включают выбор концепции эксплуатации системы, выбор архитектуры, производные требования (альтернативы функций, распределение требований). Все эти понятия будут обсуждены далее.
Статистика сроков исполнения программ, например компании Airbus, показывает, что сокращению длительности программ уделяется большое внимание, так как скорость выхода нового продукта на рынок сильно влияет на долю рынка, скорость возврата инвестиций, прибыль по ППО и др.
Характер инженерных проектов заметно различается в разных отраслях, организациях, технологических областях и сферах применения. Например, проект разработки программного обеспечения на мобильной платформе кажется далеким от проекта строительства большого нового моста. Для разных систем требуется, чтобы системный подход был адаптирован для системы в целом, а также индивидуально для каждой подсистемы. Методология адаптации может выполняться в два этапа.
1. Для настройки жизненного цикла определяют основные подсистемы. Для каждой из них определяют технические и организационные факторы, влияющие на жизненный цикл. С учетом этих факторов определяются этапы жизненного цикла. Далее описывают основные процессы и результаты для каждого этапа жизненного цикла. Затем этапы жизненного цикла оптимизируют для повышения их эффективности и результативности.
2. После определения жизненных циклов подсистем они объединяются в рамках жизненного цикла системы в целом. Различные этапы жизненного цикла системы синхронизируют по времени, определяют этапы и вехи подсистем, входящие в реализацию жизненного цикла системы.
Например, необходимо разработать систему антенн для применения в радиоастрономии. Объект имеет следующие технические и организационные особенности, которые формируют особенности жизненного цикла:
a) высокая стоимость цикла проектирование-сборка-испытания;
b) низкая технологическая зрелость, так как это новая конструкция;
c) умеренный объем единичного производства;
d) длительный ожидаемый срок службы (до 50 лет);
e) суровые условия эксплуатации в отдаленной пустынной местности с дистанционным управлением.
Описанные выше особенности влияют на адаптацию жизненного цикла следующим образом.
• Необходим комплексный предварительный анализ требований к жизненному циклу проектирования с акцентом на полную проверку конструкции на производительность и долговечность перед началом производства.
• Предполагается одна итерация разработки (создание прототипа) для дорогого штучного проекта.
• Оптимизация эксплуатационных расходов на длительный срок службы имеет решающее значение.
Другая система, например, включает разработку программного обеспечения для обслуживания сложной мехатронной системы предыдущего примера. Особенности жизненного цикла:
1) низкая стоимость цикла проектирования-сборки-тестирования. программные системы могут быть разработаны в виртуальной тестовой среде;
2) высокая технологическая зрелость, разработка проводится на основе хорошо зарекомендовавших себя протоколов управления и мониторинга, которые можно адаптировать к этой задаче;
3) жесткость требований и граничных условий: внешние интерфейсы программного обеспечения четко определены имеющимся аппаратным обеспечением на ранних этапах жизненного цикла, пользовательские интерфейсы также легко определяют на ранних этапах жизненного цикла;
4) используются отраслевые нормы и стандарты разработки программного обеспечения.
В этом примере оптимизация эффективности достигается путем сосредоточения усилий на этапах определения требований и проектирования архитектуры жизненного цикла, где процессы программного обеспечения часто слабы.
Третий пример рассматривает строительство гражданской инфраструктуры для типичного радиоастрономического объекта, расположенного на удаленном участке территории вне городской черты. Сюда входят дороги, здания, электрическая и оптоволоконная сети. Эта система имеет следующие особенности жизненного цикла:
a) очень высокая стоимость цикла проектирование-строительство-испытания;
b) высокая технологическая зрелость;
c) жесткие требования и граничные условия;
d) высокие эксплуатационные расходы и развертывание в удаленной среде;
e) отраслевые нормы и стандарты: в отрасли гражданского строительства существуют устоявшиеся стандартные процессы разработки и строительства;
f) нормативная среда со значительными ограничениями (безопасность, здоровье, окружающая среда и т. д.).
При адаптации ЖЦ проекта следует учитывать, что тщательное определение требований и завершение этапа детального проектирования целесообразно выполнить до заключения контракта на строительство. Процессы проектирования и строительства должны будут соответствовать стандартным нормам гражданского строительства, включая архитектурное проектирование, верификацию и валидацию проекта, постоянные проверки строительных работ и качества поставляемых комплектующих от подрядчиков, а также этап перехода системы в эксплуатацию и проверки конечным пользователем.
2.4. Формирование требований к системе
После утверждения положительных результатов маркетингового исследования идеи продукта для рассмотрения проекта выполняют анализ осуществимости задачи. Нужно оценить различные технологические подходы, которые могут быть рассмотрены при ответе на заданные функциональные требования. В целом необходимо определить различные возможные подходы к проектированию будущей системы, которые можно использовать для удовлетворения требований. Выполнить оценки наиболее вероятных альтернатив и аналогов с точки зрения производительности, эффективности, требований к логистике и техническому обслуживанию; а также экономических критериев жизненного цикла. Исследуются альтернативные применения технологий. Например, при проектировании средств связи можно выбирать между оптоволоконной технологией, сотовой (беспроводной) или традиционной с проводами. При разработке конструкции самолета нужно определить долю использования композитных материалов. При создании большой системы любого типа понять, как следует использовать интегральные микросхемы, печатные платы, системы на кристалле и др. Альтернатив может быть много, однако количество возможностей должно быть сужено до нескольких вариантов, соответствующих наличию ожидаемых ресурсов (т.е. человеческих сил, материалов и технологий) и бюджета.
Необходимым компонентом для продвижения по этапам разработки является «Концепция эксплуатации». Это документ, описывающий ожидаемые характеристики разрабатываемой системы с точки зрения пользователя (не путать со спецификацией, где изложен весь набор требований заинтересованных сторон к системе, подсистемам и элементам). Его задачей является наглядное описание целей создания системы, «что» она должна делать, а не «как». Документ также должен определять любые критические требования или цели производительности на верхнем уровне (сформулированные качественно либо количественно) и их системное обоснование. Форма изложения документа относительно свободная, можно найти много шаблонов в интернете.
В тексте «Концепции эксплуатации» должна содержаться следующая информация.
1. Почему необходима система и предварительный обзор самой системы.
2. Описание полного жизненного цикла системы от развертывания до вывода из эксплуатации.
3. Описание сценариев, иллюстрирующих конкретные эксплуатационные мероприятия, связанные с использованием системы.
4. Указание условий, при которых система используется и обслуживается.
5. Изложены различные аспекты использования системы, включая производство, техническое обслуживание, поддержку и утилизацию.
6. Перечисление различных классов пользователей, в том числе операторов, сопровождающих, партнеров, их различных навыков и ограничений.
7. Определены границы системы, ее интерфейсов и связей с другими системами.
Руководство по разработке концепции эксплуатации удобно готовить в группе заинтересованных лиц программы. При этом:
a) не следует указывать какие-либо особенности системы;
b) не нужно описывать, как идет процесс и как должна выполняться функция, надо только перечислить потребности системы;
c) в рабочую группу рекомендуется включить все заинтересованные стороны (до 15 чел.), которые должны иметь полномочия принимать окончательные решения;
d) желательно собрать всех участников группы в одном месте в одно и то же время, по крайней мере дважды;
e) модератор группы должен обладать навыками руководства группой и следить за ее работой;
f) следует ограничить размер разрабатываемого документа, не ограничивая полученную извне информацию;
g) модератору следует убедиться, что уровень технического языка в документе не препятствует пониманию текста.
После уточнения концепции эксплуатации на этапе анализа необходимо сформировать архитектуру системы, чтобы определить ее особенности, далее сформировать требования к системе и провести ее декомпозицию для упрощения стадии синтеза.
Термин «архитектура системы» обозначает основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития (ГОСТ Р 57100—2016).
Архитектура включает организованный нисходящий выбор и описание вариантов проектирования для всех важных системных функций и подфункций, для обеспечения совместимости и удовлетворения окончательных системных требований. Она содержит наиболее важные, связывающие весь проект, стратегические реализационные решения, изобретения, инженерные компромиссы; допущения и их соответствующие логические обоснования того, как система будет удовлетворять системным требованиям; все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Основные положения процесса разработки архитектуры:
1) каждая система имеет архитектуру;
2) архитектура определяет основные компоненты системы;
3) архитектура определяет обоснование компонентов и структуры;
4) архитектура определяет отношения компонентов структуры и их взаимодействия;
5) поведение компонентов является частью архитектуры;
6) определения архитектуры не фиксируют, что представляет собой компонент;
7) архитектура не является единой или единственной структурой.
Наиболее полезное описание архитектуры состоит из нескольких представлений, обеспечивая «интегрированное» представление о продукте.
Базовое представление архитектуры системы содержит описание систем и соединений, обеспечивающих или поддерживающих функции исполнения сценариев системы, включая графику.
Представление операционной архитектуры включает описание задач и действий, операционных элементов и информационных потоков, необходимых для выполнения или поддержки основной функции системы.
Представление технической архитектуры формулирует минимальный набор правил, регулирующих расположение, взаимодействие и взаимозависимость частей или элементов системы, целью которых является обеспечение соответствия системы удовлетворять заданному набору требований.
Описание архитектуры должно обеспечивать явные связи между различными представлениями, для интеграции облика и поддержки совместимости функций системы. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры». Пример одного из возможного множества изображений архитектуры самолета показан на рис. 6.
Создание и развитие архитектуры является началом процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом.
Требованием называют заданную (ожидаемую) количественную или качественную характеристику или свойство объекта, а также связанные ограничения и условия (ГОСТ Р 59194—2020). Оно необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества).
Рис. 6. Вариант схемы архитектуры самолета
В стандарте ISO 9000 «Система менеджмента качества» сформулировано, что требование является документально изложенным критерием, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.
Требования к системе являются ключевым компонентом процесса ее создания. Требования определяют, что система должна делать и управляют ее развитием. Требования не являются спецификациями. Они определяют функции, характеристики и задачи системы в части окружающей среды. В процессе разработки системы, изображенном в виде итерационных петель (риc. 5), петля требований открывает цепочку базовых действий по созданию нового продукта. Есть несколько причин, зачем нужны требования.
• Требования определяют цель программы, например, получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши или получить прибыль от реализации проекта.
• Требования определяют нужды (проблемы) заинтересованных сторон, или иначе, бизнес-требования.
• Требования определяют вариант создания продукта, т.е. процедуры, регламенты, системные требования.
• Требования определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т. д.
Посредством требований уточняются формулировки или характеристики продукта, который разработчик хочет или должен получить. Требования также являются предметом договорных обязательств по созданию системы, составной частью документирования поставленной задачи, содержат значения, используемые при общении с заказчиком.
Технический процесс системного проектирования начинается с функциональных требований. В интересах разработчика сохранить как можно большую свободу проектирования. Затем функциональные требования обычно декомпозируют. При этом задача декомпозиции вводит новые входные и выходные данные и среду для исполнителя. Нужно минимизировать объем информации, которую приходится передавать между подсистемами. Функциональные спецификации нижнего уровня являются основой для закупок услуг по проектированию. Они записываются в виде границ. Например, указано, что масса продукта должна быть меньше или равна 25 кг.
Успех любой создаваемой системы и ее эксплуатации зависит от следующих факторов:
1) готова ли рыночная среда к внедрению системы (когда потребности рынка обусловлены «окном возможностей»);
2) как обеспечено позитивное восприятие пользователем функциональности, пригодности и доступности системы;
3) способность системы выполнять эксплуатационные требования пользователя (эффективность системы);
4) время возврата инвестиций (ресурсов, затраченных на эксплуатацию и обслуживание системы), т.е. экономическая эффективность продукта.
Правильная формулировка пакета требований к системе крайне важна для обеспечения перечисленных факторов прогнозируемого успеха, так как именно этот набор является основой формирования будущей системы. Этапы процесса системной инженерии включают также анализ и верификацию требований в разных частях жизненного цикла. При этом необходимо регулярно проверять трассировку требований «сверху вниз», т.е. влияние требований верхнего уровня на требования к подсистемам. Кроме того, требования уточняются на всех этапах процесса разработки.
К сожалению, плохо сформулированные требования являются главной причиной проблем на проекте. Требования определяют, что должно быть сделано, как хорошо и при каких ограничениях. Если разработчики получат неверные требования, проект и оборудование не будут работать. Требования являются причиной стоимости системы, бюджета проекта, графика работ, требуемых ресурсов, планов верификации, эксплуатационных процедур, т.е. всего в проекте!
Приоритетные требования (и связанные с ними ограничения и допущения) определяют решаемую проблему, они устанавливают, как будет определен успех проекта. Недопустимо, что многие команды начинают решать проблему до того, как достигнуто соглашение, что именно надо сделать.
В соответствии с иерархией структуры системы существует несколько уровней требований сверху вниз.
• Требования заинтересованных сторон являются верхним уровнем требований. Они отражают потребности пользователей, клиентов и других источников требований, таких как отраслевые, правовые, экологические нормы и требования высокого уровня внутри компании. В этих требованиях используют критерии качества для создания точного и понятного набора выполнимых и проверяемых требований, который является полным и последовательным.
• Системные требования расположены на следующем уровне. Их целью является установление точных технических требований для разработки системы. Системные требования основаны на требованиях заинтересованных сторон и их производных с учетом существующих технологий, компонентов и т. д.
• На нижеследующих уровнях формируют требования к подсистемам и компонентам. Целью этих требований является установление точных технических требований для разработки подсистемы или компонента. Они выводятся из системных требований с учетом существующих технологий, компонентов, интерфейсов и т. д.
Для инициации процесса формирования требований используют следующую информацию.
1. Исходные ожидания заинтересованных сторон, т.е. потребности, цели, результаты, допущения, ограничения, внешние интерфейсы для данного класса изделия.
2. Описание концепции эксплуатации для понимания системных целей, задач и ограничений. Включает сценарии, варианты использования и проектные задания.
3. Базовые стратегии поддержки для всех стадий ЖЦ (разработки, тестирования, производства, эксплуатации или утилизации конечного продукта).
4. Меры эффективности, т.е. соответствие результатов проекта критериям успеха (см. главу 3.8).
5. Другие данные. Например, для авиационных объектов все взаимодействия человека и системы, необходимые для эксплуатации, включая сборку, наземные операции, логистику, обслуживание в полете и на земле, эксплуатацию в полете и т. д.
Задача формирования требований в разных проектах может решаться разными путями. В начале процесса проводится выявление источников формирования требований. Каждый новый продукт реализует ряд специфических требований, которые позволяют сохранить конкурентоспособность на рынке. Некоторые источники формирования требований перечислены ниже.
•На высшем уровне полезно использовать опыт разработчиков по постановке целей. Следует организовать общение заинтересованных лиц и заказчика, которые нуждаются в соглашении с выработкой единого подхода к набору требований.
• Далее нужно определить цели и задачи программы (сформировать контракт на работу), установить допущения и ограничения, оговорить концепцию эксплуатации.
• Обсудить анализ проекта и маркетинг (вопросы сбыта продукции), уточнить матрицы критериев системы и выбранные приоритеты. Выполнить анализ иерархии, установить, какие функции должна иметь система и ее подсистемы для выполнения задач эксплуатации, провести предварительную декомпозицию и определить прослеживаемость требований на компоненты, оценить выявленные интерфейсы.
• Учесть руководящие документы для создаваемого продукта или системы, ГОСТ, ISO, федеральные и отраслевые нормы, и др.
• Определить границы системы и внешние интерфейсы. Уточнить влияние внешних систем на требования рассматриваемого проекта и стыковки по внешним интерфейсам (при наличии). Выявить эксплуатационное окружение, уточнить и задокументировать, какие дополнительные требования налагают внешняя среда и условия работы.
При выполнении анализа требования полезно классифицировать на основные типы:
A. Функциональные требования, отвечающие на вопрос «что система должна делать?». Например, обеспечить связь между землей и самолетом.
B. Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?». К предыдущему примеру нужно определить применимый диапазон радиоволн, набор данных и как часто требуется выходить на связь.
C. Экологические и нефункциональные требования (сценарии использования), основанные на стандартах, отвечающие на вопрос «при каких условиях (экологии, надежности и доступности) система должна работать для удовлетворения данного требования?».
D. Ограничения системы. Точный характер ограничений может зависеть от предлагаемых решений. Так, выбранный вариант реализации заданных характеристик может вести к концепции проекта, которая скажется на росте массы конструкции. Или необходимо учитывать внешние интерфейсы, налагаемые другими системами (габарит мотогондолы на самолете, условия хранения, транспортировки, эксплуатации максимальная скорость у земли, температура, квалификационные требования по электромагнитной совместимости и др.).
E. Политика и публичные законы вносят ограничения по безопасности, экологии и шуму, важны для понимания, какие концепции полезны и практичны. Следует учесть угрозы, налагаемые известными возможностями потенциального конкурента, что ограничивает диапазон практических вариантов проекта. Если система предназначена для замены существующей, план перехода может учитывать дополнительные ограничения на концепцию и программу (например, трудоемкость ниже существующей, скорость производства выше и др.).
F. Требования к качеству (включая требования к безопасности).
G. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).
H. Требования к процессам жизненного цикла продукта, включающие административно-организационные требования (скорость выхода на рынок, послепродажное обслуживание и др.).
Подробные требования к проекту могут содержать следующие пункты.
1 Технические данные.
2 Планирование.
3 План управления системной инженерией (СИП).
3.1 Процесс системного проектирования.
3.2 Системный анализ и управление.
3.3 Технологические вопросы (процессы, оборудование).
3.4 Обеспечение технической интеграции.
4 Анализ эффективности.
4.1 Технологический анализ производства.
4.2 Анализ испытаний и верификации.
4.3 Анализ опытного производства и испытательных установок.
4.4 Эксплуатационный анализ сценариев расчетных и нештатных.
4.5 Анализ поддержки в эксплуатации.
4.6 Анализ обучения и соответствующего персонала.
4.7 Анализ процесса утилизации.
4.8 Анализ окружающей среды.
4.9 Анализ стоимости жизненного цикла.
4.10 Моделирование и цифровые двойники.
5 Детальный график системного проектирования.
6 Технические обзоры.
6.1 Планирование цепи обзоров.
6.2 Функциональные обзоры.
6.3 Обзоры системы по времени работ.
6.4 Организация сбора экспертных отзывов.
7 Структуру разбиения работ (СРР).
8 Требования к технической интеграции системы.
8.1 Надежность и ремонтопригодность.
8.2 Живучесть (где приложимо).
8.3.Электромагнитная совместимость.
8.4 Интеграция человеческих систем.
8.5 Безопасность системы для здоровья и воздействие на окружающую среду.
8.6 Безопасность системы от внешних воздействий.
8.7 Обеспечение качества.
8.8 Производство (технологические процессы, заготовки, инструменты, гибкие линии).
8.9 Интегрированную логистическую поддержку.
8.10 Испытания и оценки.
9 Прочие требования к разработке.
9.1 Приобретаемые компоненты (ПКИ).
9.2 Использование метрической системы.
9.3 Контроль деталей, включая поставки от подрядчиков.
9.4 Управление, связь и коммуникации.
9.5 Прототипирование.
10 Проверку инженерного менеджмента у подрядчиков.
Цепочка проектирования системы (продукта) включает несколько шагов определения и разработки требований.
• Определить и документально зафиксировать требования. Заинтересованные лица (включая заказчиков, пользователей и др.) формируют набор требований верхнего уровня, зачастую эти требования входят в техническое задание контракта на разработку системы.
• Провести анализ и декомпозицию полученных требований на нижележащие уровни системы для формирования указаний, необходимых исполнителям работ.
• Сформировать производные требования, вытекающие из заданных, для реализации детального проекта системы.
• Определить методы верификации требований.
Эти шаги могут выполняться параллельно, и, аналогично большинству технических процессов, реализуются посредством набора итераций.
При разработке требований рекомендуется формулировать простые утверждения. Требования включают обязательные характеристики, такие как «необходимый, проверяемый, достижимый технически, затраты, сроки». Т.е. каждое требование должно выразить одну мысль, быть кратким и простым, быть заявлено положительно, быть грамматически правильным; без опечаток и орфографических ошибок, быть понятным однозначно, должно использовать терминологию для обозначения системы (продукта) и ее частей более низкого уровня, соблюдать правила проекта (шаблонов и стилей), формат требования «кто хочет что».
Требование должно быть независимым от технической реализации, т.е. не содержать никаких технических деталей. Требование должно быть выполнимым, то есть должна быть возможность смоделировать, как требование может быть удовлетворено.
Для перевода требований заказчика в технические характеристики продукта часто используют процедуру развертывания функции качества (quality function deployment, QFD). Метод QFD представляет собой один из инструментов проектирования изделий и процессов, помогающий преобразовывать пожелания потребителя в технические требования к изделиям и процессам их производств. Основная идея технологии QFD заключается в том, чтобы связать потребительские свойства, надежность (т.е. фактические показатели качества) и установленные в стандартах параметры продукта (вспомогательные показатели качества), между которыми всегда существует большое различие.
Метод (https://clck.ru/3FNPmg) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуются в технические. Затем технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.
Например, при создании легкового автомобиля потребителю нужна тишина в салоне авто. Для технической реализации нужно уточнить следующие требования: снизить уровень шума мотора и коробки передач, применить шумопоглощающие уплотнения в перегородке салона, дверях, окнах, элементах кузова и др.
Одним из видов требований нижних уровней являются производные требования.
Производными называют требования, которые прямо не указаны в наборе требований заинтересованных сторон, но они должны быть сформулированы, чтобы удовлетворить одно или несколько конкретных высказанных требований. Их формируют на основе оперативного или технического анализа базовых требований в целях уточнения, или чтобы сделать базовые требования достижимыми.
Производные требования должны быть сформулированы и доведены до соразработчиков подсистем. Должны поддерживаться и контролироваться связи по всем уровням создаваемой системы, как «сверху вниз», так и «снизу вверх». Производные требования могут изменяться в результате изменений в дизайне, поэтому очень важно отслеживать, что откуда получено.
После сбора исходных требований верхнего уровня в процессе декомпозиции системы на подсистемы, модули и компоненты проводится декомпозиция требований на эти элементы с тем, чтобы после их создания и интеграции в продукт система в целом соответствовала требованиям верхнего уровня. Следуя функциональной архитектуре, декомпозицию и получение производных требований в ходе разработки проекта выполняют тремя способами: по потоку, распределением и ответвлениями. Декомпозиция требований вниз по потоку есть прямая передача их в подсистемы для обеспечения характеристик системы в целом. Распределение (при декомпозиции) представляет собой количественный пропорциональный дележ требований верхнего уровня на нижний уровень. Ответвление требований есть пропорциональная характеристика, зависящая от специфической реализации архитектуры системы.
Схема процесса декомпозиции требований изображена на рис.7.
Рис. 7. Этапы декомпозиции требований
На рисунке процесс движется слева направо. На шаге 1 установлены возможности системы (выставленные исходные требования). На шаге 2 проводится декомпозиция требований верхнего уровня по функциям системы, формируются производные и «дочерние» требования. На шаге 3 требования к функциям привязывают к подсистемам и компонентам системы.
Распределение требований при разработке системы можно разделить на вертикальное и горизонтальное. Вертикальное распределение отражает разложение требований с верхнего уровня системы на уровень подсистемы, далее на уровень оборудования и т. д. Горизонтальное распределение относится к соответствию между требованиями и элементами архитектурного дизайна на одном уровне.
Прослеживаемость (трассировка) и иерархия требований также являются важными компонентами управления требованиями. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками для проверки происхождения и правильности формулировки. Анализ прослеживаемости является эффективным методом контроля и обнаружения противоречий и совпадений требований.
При рассмотрении вышеуказанных вопросов производных требований важным является уточнение набора интерфейсов системы. Интерфейс описывает связь между двумя функциями или процессами, фактически отражая часть требований к системе. Интерфейсы в системе появляются при ее сопряжении с внешними системами (соединение частей комплекса с бортовыми системами, линии связи авионики с наземным центром управления полетами и др.), либо при ее декомпозиции при распределении работ, либо при разделении элементов конструкции на модули и компоненты в зоне ответственности конкретного субподрядчика. Существуют разные типы интерфейсов: механические (компоненты физически стыкуются друг к другу); электропитание (напряжение и токи между подсистемами); электронные (характеристики электрических сигналов между системами); данные (формат и содержание информации, передаваемой между подсистемами); тепловые (тепловые потоки между подсистемами); программное обеспечение (связь модулей или оборудования).
При стыковке участков работ разных команд в системе возникает множество интерфейсов. Их появление связано с наличием группы проектных команд, участием разных производителей агрегатов и поставщиков, использованием нескольких сборочных площадок, разделением работ внутри отдельных команд.
Примеры стандартных интерфейсов (механические и шины данных) показаны на рис. 8.
Рис. 8. Примеры интерфейсов
Требования к интерфейсам должны удовлетворять определенным правилам для исполнения задаваемых функций.
1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.
2. Функции, характеристики, ограничения и допущения этих интерфейсов должны быть определены и зафиксированы в требованиях к интерфейсам.
3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.
4. Требования к интерфейсу определяют функциональные, физические, характеристические, электрические, экологические, человеческие требования и ограничения, которые существуют на общей границе между двумя или более функциями, элементов системы, элементов конфигурации или систем.
5. Требования к интерфейсу включают логические и физические интерфейсы.
6. Функциональные и ресурсные распределения по подсистемам влияют на требования интерфейса. В качестве примера рассмотрим сжатие данных. Эта функция может быть выделена либо в радиолокационной подсистеме, подсистеме обработки данных или подсистеме связи.
Интерфейсы можно классифицировать на внешние и внутренние (по отношению к системе в целом или по отношению к области работ конкретного подрядчика). Разделение на внутренний и внешний интерфейсы внутри системы зависит от положения исполнителей в цепочке «заказчик-поставщик».
Внешние интерфейсы образуют границы между системой и окружением. Требования системного уровня к внешним интерфейсам установлены вместе с другими требованиями системного уровня. То есть требования к внешним интерфейсам, как и другие функциональные и эксплуатационные системные требования, распределяются по подсистемам через исходные данные, производные или вниз по потоку.
При декомпозиции системы появляется определенное количество внутренних интерфейсов, необходимых для установления связи между двумя функциями или процессами внутри системы. Типы и характеристики всех интерфейсов должны быть идентифицированы и определены. Внутренним называют интерфейс, контролируемый данным конкретным исполнителем ОКР. Например, интерфейс между двумя поставщиками, работающими по контрактам с головным исполнителем, будет для обоих поставщиков внешним. При этом для проекта головного предприятия данный интерфейс будет внутренним.
Требования для внутренних интерфейсов отличаются тем, что они создаются в рамках декомпозиции системы. Различные решения системы, то есть варианты распределения требований будут приводить к созданию разных подсистем и их интерфейсов. Эта дополнительная задача интеграции системы одновременно предоставляет мощную возможность для разработчиков оптимизировать конструкцию системы.
Требования к интерфейсам, как часть системных требований, должны быть идентифицированы во время определения системных решений. Они фиксируются в моделях функциональной и физической архитектуры, уточняются на совещаниях заинтересованных лиц. Для систем высокой сложности спецификации и планирование разработки и управления интерфейсами должны следовать структурированному подходу путем определения всех ключевых подсистем внутри общей системы и размещения их в матрице строк и столбцов N
, где каждый элемент матрицы представляет собой технический или системный интерфейс для управления.
Определение, управление и контроль интерфейса включают управление внутренними и внешними интерфейсами различных уровней продуктов и задач для поддержки интеграции продукта. Основные задачи заключаются в следующем:
a) определить интерфейс и его характеристики (физические, электрические, механические, человеческие и т.д.);
b) обеспечить совместимость интерфейса со всеми сопряженными интерфейсами, используя процесс, документированный и одобренный в проекте;
c) разработать документ управления интерфейсом;
d) определить монтажные чертежи или другую документацию, которая включает полную конфигурацию интегрируемого продукта, список деталей и инструкции по сборке;
e) определить требования к конечным продуктам, требованиям, определенным в проекте, а также конфигурационную документацию для структуры разбиения работ проекта, включая спецификации интерфейса, в форме, подходящей для процесса управления конфигурацией.
Ответственным за определение, разработку и верификацию интерфейса является заказчик продукта или его представитель. Для документирования интерфейса и постановки под управление конфигурацией должны быть оформлены основные документы интерфейса.
•Документ требований интерфейса определяет функции, характеристики, электрику, экологию, персонал, физические требования и ограничения, которые существуют на общей границе между двумя или более функциями элементов системы, элементов конфигурации или систем.
• Документ определения интерфейса является односторонним, контролируется поставщиком и предоставляет подробную информацию об интерфейсе для проектных решений, которые уже установлены. Разработчик должен спроектировать интерфейс системы, совместимый с уже существующим ответным элементом.
• Документ управления интерфейсом (ICD) излагает детали интерфейса между двумя элементами системы: числа и типы разъемов, электрических параметров, механических свойств, а также экологических ограничений, определяет дизайнерское решение на требование интерфейса.
Набор из трех документов, как правило, делается в усеченном варианте, часто используют только документ управления интерфейсом с введением отдельных данных из других документов. В документе ICD указаны персонально сотрудники, ответственные за интерфейсы (по одному на каждый, один владелец может быть у нескольких интерфейсов).
Документ «Требования к интерфейсу» входит в общий набор требований к системе, подпадает под управление конфигурацией и входит в общую контрольную «Матрицу соответствия требований к системе или продукту», верифицируемую на этапах разработки. Другие два документа интерфейса могут существовать в общем потоке документов системы по принадлежности. Отечественный и зарубежный опыт разработки высокотехнологичных систем показывает, что на проекте интерфейсы сложной системы (внешние и внутренние) нуждаются в дополнительном контроле, так как являются источником большого количества нестыковок как в ходе разработки проекта системы, так и на этапах ее интеграции и валидации.
Хорошие требования к системе или продукту должны быть:
a) специфичными, т.е. отражать только один аспект конструкции или характеристик системы, и должны быть выражены в терминах необходимости (что и как хорошо), а не решений (как);
b) измеримы, т.е. характеристика выражается объективно и количественно (например, точное требование, указывающее температуру детали в градусах, может быть проверено при испытании);
c) достижимы, т.е. технически реализуемы при доступных затратах;
d) соответствовать указанному уровню подсистемы (например, требование наличия солнечных батарей спутника не входит в уровень требований ракеты-носителя, а только в требования для подсистемы полезного груза);
e) прослеживаемыми, т.е. требования нижнего уровня (младшего, дочернего) должны четко вытекать из поддержки требований более высокого уровня (старшего, родительского). Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.
Можно изложить некоторые полезные правила формирования требований, как набор рекомендаций, чего следует «избегать» в тексте требований:
1) хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;
2) «лазеек», таких как «если это необходимо», поскольку они делают требование бесполезным;
3) помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;
4) рассуждений и нечетких слов («обычно», «в основном», «часто», «нормально», «типично»);
5) использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);
6) принятия желаемого за требуемое («100% надежный», «приятный для всех пользователей», «безопасный», «подходящий для всех платформ», «не должен никогда ломаться», «быть готов к модернизациям для любых ситуаций, которые могут возникнуть в будущем»).
Приведем несколько примеров требований, с точки зрения того, хорошо ли они изложены.
•Самолет должен иметь три двигателя (исходное требование для DC-3). Позже выяснилось, что самолет должен отвечать требованиям эксплуатации при отказе одного двигателя.
• Разработчики смартфонов ставили своей целью улучшить технику для телефонных звонков. Однако пользователи стали выбирать смартфоны по опции связи и мультимедиа в мессенджерах и качеству снимков фотокамеры, т.е. по ранее вспомогательным критериям.
• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Оказалось, что после срабатывания системы огонь успешно ликвидируется, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 9). Видимо, предполагалось, что она будет сливаться в водостоки. Пришлось вносить в систему доработки.
На практике нередко встречаются отклонения от требований. Для дальнейшего продвижения в проекте необходимо указать причины отклонений. Как правило, это следствие отсутствия части информации. В документах встречаются места, оставленные для заполнения в дальнейшем. В документах на английском языке используют пометки типа TBA (to be agreed – необходимо согласовать), TBC (to be complete – необходимо завершить), TBD (to be decided – необходимо принять решение). Однако при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен. Важно знать при формулировке раздела требований в англоязычных контрактах, что слово «Compliance» является единственным вариантом подтверждения строгого соответствия исполнителя требованиям контракта.
Рис. 9. Срабатывание системы пожаротушения
Также на этапе разработки требований необходимо определить методы их верификации. С целью безусловного выполнения требований проекта необходимо организовать поэтапную верификацию исполнения требований к системе, начиная с момента появления предварительного облика разрабатываемой системы (на контрольном рубеже с обзором предварительного проекта системы).
Валидация требований часто входит в один из этапов ворот принятия решений. Проверка требования включает четыре типовых вопроса.
•Правильная ли сформулирована проблема?
• Смогли ли указанные требования отразить проблему?
• Верно ли сформулированы эти требования?
• Соответствуют ли требования установленным границам системы и ограничениям?
В процессе валидации требуется проверить, что системные требования полны, непротиворечивы и каждое требование достижимо и проверяемо. Валидацию требований проводят эксперты по конкретным вопросам, организация-разработчик и уполномоченные представители Заказчика.
В результате процесса разработки формируется набор требований к системе, который должен быть выполнен при создании продукта или системы. Он содержится в документах контракта, спецификациях или технических заданиях на выполнение работ. Характеристики этого набора требований будут идентичны вышеописанным характеристикам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным (т.е. не нуждается в дополнительных пунктах требований). Входящие в него требования должны быть согласованными (т.е. не содержат противоречий, дублирований и др). Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 3.4).
На основании требований системного уровня выполняется функциональный анализ системы, то есть разработка функционального описания системы, которое послужит основой для определения ресурсов, необходимых системе для достижения ее целей. Функцией называют конкретное или дискретное действие (или их серию), необходимое для выполнения системой своей задачи, или действие по техническому обслуживанию, необходимое для восстановления работоспособности системы.
Функциональный анализ включает итеративный процесс разбиения требований от уровня системы до подсистем и вниз по иерархической структуре, насколько это необходимо для определения входных критериев проектирования и ограничений для различных элементов системы. Требования верхнего уровня идентифицируют, разделяют на второй и далее уровни вниз до глубины, необходимой для целей определения элементов системы.
Одной из целей функционального анализа является обеспечение прослеживаемости от требований верхнего уровня системы до требований к рабочему проектированию. Учитывая конкретные требования к оборудованию, можно двигаться «вверх» для обоснования этого требования. Функциональный анализ должен обеспечить механизм прослеживаемости «снизу вверх».
При оценке каждого функционального требования альтернативы могут включать выбор ПКИ, количество различных источников поставок, и элементы разработки, для которых требуется какая-то новая конструкция.
Функциональный анализ, в частности, формирует основу для разработки:
a) электрического и механического проектирования компонентов мониторинга состояния и средств диагностики;
b) моделей надежности;
c) анализа характера, последствий и критичности отказов;
d) анализа технического обслуживания, ориентированного на надежность;
e) анализа ремонтопригодности;
f) анализа человеческого фактора;
g) анализа безопасности и рисков системы;
h) логистического анализа (анализа цепочки поставок).
2.5. Принятие проектных решений
Следующим этапом процесса разработки является синтез системы, в ходе которого конструктор переводит функциональную архитектуру системы в физическую. Процесс сопровождается принятием множества проектных решений, где конструктор должен проявить как творческую сторону деятельности, так и профессиональный прагматизм. Термин сбалансированное решение означает, что проведено обсуждение общих рисков системы, стоимости, технической зрелости и надежности для каждой комбинации подсистем.
Основные принципы проектирования изделий можно свести к краткому перечню.
•Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. Лучшее – враг хорошего.
• В проекте надо использовать принцип «сделай это проще», чтобы снизить риски и стоимость и обеспечить легкую реализацию и эксплуатацию.
• Излишние опции в проекте должны быть определены на ранней стадии (и удалены из целей системы), при этом влияние на характеристики продукта, вытекающие из осуществления этих опций, должно быть понятным.
• В проекте обязательны независимые обзоры промежуточных результатов для всестороннего обсуждения вопросов разработки.
Важно принимать во внимание информацию о том, что основные затраты на этапе разработки связаны с передачей в производство образцов и закупками ПКИ, тогда как уровень этих затрат определяется на раннем этапе, при разработке конструкторской документации. Т.е. принятые на ранней стадии решения являются ключевыми и определяют стоимость программы на последующих этапах ЖЦ.
Ниже суммированы некоторые полезные рекомендации, приносившие успешные результаты при проектировании изделий и систем. Каждый читатель может привнести в них свой уровень детализации, создавая базу уникальных шагов для нового проекта:
1) использовать модели для проектирования систем;
2) использовать иерархический дизайн сверху вниз;
3) сначала выполняется работа с высокорисковыми компонентами;
4) конструировать минимум интерфейсов, разделяя их на механические, электрические, программные;
5) применять в альтернативах проекта удовлетворительные конструкции;
6) рекомендуется не проводить оптимизации на ранней стадии работ, пока нет уверенности, что база оптимизации выбрана достаточно обоснованно;
7) свои ошибки нужно находить самим, т.е. определить, что не так в очередном варианте;
8) полезно перечислить функциональные требования в случае использования системы;
9) выделить каждую функцию для только одного компонента;
10) категорически нельзя использовать недокументированные функции;
11) полезно применять быстрое прототипирование (варианты аддитивных технологий);
12) разрабатывать несколько итераций и сразу тестировать результат;
13) создавать библиотеки повторно используемых субъектов;
14) написать глоссарий соответствующих терминов;
15) удобно использовать создание конструктивных резервов (запасы);
16) следует проектировать компоненты с возможностью тестирования;
17) выполнять анализ чувствительности конструкции для альтернативных вариантов;
18) изменять поведение людей в команде для достижения результата.
Процесс определения проектного решения используется для перевода требований высокого уровня, полученных от ожиданий заинтересованных сторон, и результатов логического процесса декомпозиции в реализуемое решение. Производные технические требования используют для выбора альтернативных решений. Затем эти альтернативные решения анализируют для определения предпочтительной альтернативы. Выбранная альтернатива служит базой конечного проектного решения, которое удовлетворяет техническим требованиям.
Процесс принятия системного решения является совместным, итеративным и основанным на ценностях, который можно применять на любой стадии жизненного цикла системы для максимизации вероятности успеха.
Можно выделить несколько присущих характеристик процесса.
• Процесс решения охватывает динамический поток работ по проектированию системы и эволюцию ее состояния, начиная с текущего статуса (как есть) и заканчивая системой, которая приносит пользу заинтересованным сторонам (как должно быть).
• Этот совместный процесс фокусируется на ценности, потребностях и целях заинтересованных сторон и лиц, принимающих решения (ЛПР), обеспокоенных ценностью, предоставляемой системой. Заинтересованные стороны и ЛПР определяют важные функции, цели, требования (критерии отбора, которым должны соответствовать все потенциальные решения) и ограничения.
• Процесс принятия решения состоит из четырех последовательных этапов (определение проблемы, разработка, принятие и реализация решения), которые охватывают системное мышление и применяют проверенные подходы к системному проектированию, как правило, посредством итераций.
• Самая важная задача в любом процессе принятия системных решений: идентифицировать и понять проблему, которая определяется пониманием задач, целей и ограничений от ЛПР и заинтересованных сторон.
• Целевым для процесса является создание ценности (моделирование, генерация идей и усовершенствование вариантов) в дополнение к оценке и анализу чувствительности альтернатив. Ценности должны быть движущей силой принятия проектных решений для оценки фактических или потенциальных последствий действий и бездействия, предлагаемых альтернатив и решений.
Например, процесс принятия решения технической проблемы появления дефекта рекомендуется продвигать по следующим шагам:
1) наблюдаемые симптомы;
2) определение проблемы;
3) целевой результат;
4) анализ основной причины;
5) количество компонентов в эксплуатации;
6) частота отказов среди этих компонентов;
7) происходит ли сбой равномерно по всей совокупности или он связан с конкретной партией изделий;
8) связан ли отказ с конкретным пользователем или рабочим циклом;
9) предлагаемое решение;
10) план действий;
11) результаты плана действий;
12) подтверждение решения;
13) уроки на будущее.
Такой организованный подход к решению помогает участникам обсуждения, в том числе более опытным, внести свой вклад. В литературе существует большое количество рекомендаций по подобным алгоритмам принятия решений.
Вовлекаемый в процесс выработки решений опытный критический мыслитель должен обладать следующими качествами:
a) поднимает важные вопросы и проблемы, формулируя их четко и ясно;
b) собирает и оценивает соответствующую информацию, используя абстрактные идеи и объективные данные для ее эффективной интерпретации;
c) приходит к обоснованным выводам и решениям, проверяя их на соответствие заданным критериям и стандартам;
d) думает непредвзято в рамках альтернативных систем мышления, признавая и оценивая, при необходимости, их предположения и практические последствия;
e) эффективно общается с другими коллегами, находя решения сложных проблем;
f) осознает человеческие ошибки при принятии решений и компетентен в использовании статистических методов для получения обоснованных выводов.
На этапе подготовки проекта плановый объем основных требуемых решений предлагается типизировать и расставить очередность в предпочтительном порядке по приоритетам. Приоритизация работ является важным элементом процесса, так как позволяет сосредоточиться на главных компонентах и подсистемах. При разработке нужно расставлять приоритеты на все факторы (требования, цели, нужды и ожидания потребителей, возможности, риски, директивы, инициативы, вопросы, мероприятия, варианты, функции, прецеденты, измерения технических характеристик и веса важности для критериев в маркетинговых исследованиях). Ранжирование помогает упростить решение вопросов с бюджетом, графиком, архитектурой системы, удовлетворенностью клиентов и снижением рисков.
Одной из основных задач при разработке системы является принятие решений по архитектуре системы. Лицо, принимающее решения (ЛПР), поставленное в ситуацию, когда решение необходимо принять, должно всегда выбирать, основываясь на явных или скрытых критериях оценки этого решения, то есть сознательный и обдуманный выбор критериев является жизненно важным в процессе принятия решения. Обязанностью ЛПР является получение согласованных решений проекта на этапе их принятия с учетом того, что все участники процесса имеют отличающиеся приоритетные цели в программе. При этом следует помнить, что в инженерных задачах возможно, как правило, наличие двух и более вариантов решения.
При принятии проектных решений следует начинать с выбора критериев оценки влияния решений на ход реализации проекта:
•когда решение связано с умеренным или высоким риском по результату;
• когда решение влияет на управление конфигурацией;
• когда результат решения может привести к значительным задержкам графика работ;
• когда результат решения может привести к значительным перерасходам;
• учитывать, что при закупке ПКИ есть 20% комплектующих, которые составляют 80% от общей стоимости ПКИ.
Следует принимать во внимание, что каждое конкретное решение имеет свою «стоимость» в части объема затрат на реализацию. Схематично можно выделить четыре фазы зависимости «характеристика – ресурсы» (рис. 10). Здесь под стоимостью понимаются затраты любого ресурса (не только финансового).
Рис. 10. Кривая «стоимости» проектных решений
A. Рост характеристики от 0 до 1 дает ее заметное улучшение при минимуме затрат ресурса.
B. Рост характеристики 1—2 обеспечивает эквивалентный прирост характеристики на единицу затрат.
C. В приросте характеристики от 2 до 3 заметные затраты приводят к некоторому улучшению характеристики, но процесс сопровождается увеличением риска.
D. Рост характеристики выше 3 уровня показывает, что там невозможно получить улучшение характеристики при любом вложении ресурса.
Выбор набора базовых проектных решений, например, в компании Airbus выделен в отдельный этап и может длиться от 3 месяцев до 1,5 лет. В процессе участвуют эксплуатационники, конструкторы, технологи, производственники, закупщики, риск-разделенные партнеры. В ходе этапа проводится принятие базовых решений по выделенному перечню концептуальных мест проекта, составляют соглашения об используемых в программе инструментах, формате данных, требований, критериев, коммуникации и др. Этот руководящий документ служит защитой от принятия отдельными участниками ошибочных легковесных решений на этапах.
Традиционно процесс разработки каждого элемента конструкции является итерационным. С целью упорядочить данный процесс применяется, в частности, выделение трех уровней принятия решений (уровней зрелости конструкции). В ходе такого процесса проводится трехстадийная разработка эскизных компоновок проектных решений по всем основным местам конструкции. На первом уровне проводится вариантный отбор. Для определения последующих альтернатив применяются соответствующие критерии: масса, прочность, технологичность, ремонтопригодность, стоимость, возможности унификации. На втором и третьем уровнях зрелости проектных решений соответственно уменьшается число вариантов и возрастает глубина проработки конструкции. По трехмерной модели считают запасы прочности. При выявлении несоответствий требуется уточнить матрицу нагрузок, либо усилить конструкцию, либо изменить проектное решение.
При переходе от уровня к уровню по зрелости частных решений также идет сужение масштабов решений от системы в целом к деталям и компонентам (рис. 11).
Рис. 11. Схема реализации проектных решений
Общий процесс системного решения необходимо адаптировать к системе, решению и этапу жизненного цикла системы. Для достижения нужного качества решения полезно следовать нескольким принципам.
• При формировании будущего решения нужно учитывать масштаб проблемы и все потребности заинтересованных сторон.
• Следует выбирать творческие и осуществимые решения, которые создают ценность для заинтересованных сторон и лиц, принимающих решения.
• Значимые данные, используемые для генерации и оценки возможных решений, должны быть обоснованными, понятными и заслуживающими доверия.
• Для генерации и оценки решений необходимо провести анализ компромиссов между системными требованиями, показателями ценности и ресурсами.
• Реализация решения является одним из самых сложных этапов процесса. Для этого необходимо выявить и устранить препятствия и риски. Избегать искушения слишком поспешного выбора решения. Критически важным для принятия системных решений является учет окружающей среды, ее факторов (технологических, безопасности, экологии и экономики) и взаимодействующих систем, в которой работает продукт или система.
При принятии решений проекта важно точно формулировать цели и объемы их исполнения. При работе с европейскими авиастроителями нашей команде был предложен проект переделки списанных пассажирских самолетов в грузовые. Исходный самолет был спроектирован в бумажных чертежах, а новые чертежи нужно было делать в электронном виде. Попытки оформить предложения по правилам выпуска новой документации в проекте (для минимизации переделки серийных деталей старой конструкции) не были услышаны. Заказчики потребовали при наличии сопряжений между старой и новой деталью оцифровывать их обе. При этом формально появлялась новая деталь для конструктора и для производства. В итоге контракт был подписан на доработку по трудоемкости 30% конструкции, а по факту получилась переделка планера на 70%. Пришлось оформлять соглашение о частичной компенсации затрат на дополнительные работы. В принятии неверного решения были виновны обе стороны. Заказчики ошибочно оценили допущения по технике предлагаемых работ и выделенный бюджет, у исполнителя не получилось внятно и вовремя донести опасения до партнеров.
Процесс принятия решений может включать следующие этапы.
1. Определение альтернативных решений для проектирования. Если они определены и полностью понятны, тогда выбор можно сделать с уверенностью. Процесс должен обеспечить наиболее функциональную, безопасную и экономичную конечную систему, в границах графика проекта. Следует оценить зрелость требуемой технологии и ожидания заинтересованных сторон для эффективной эксплуатации.
2. Создание альтернативных концепций дизайна. По возможности, каждая из них должна рассматриваться в рамках широкого класса разумных конструкций. Потенциал для изменений может включать также организационную структуру, ограничения персонала, графики, процедуры и любые другие элементы, составляющие систему. Нужно определить для узлов, что лучше: сделать самим, повторно использовать или купить компонент (подсистему).
3. Анализ альтернативных проектных решений. Далее техническая группа анализирует, насколько хорошо каждая из альтернатив проекта соответствует целям системы (технологическая зрелость, эффективность, техническая достижимость, производительность, стоимость, и риск). Эта оценка осуществляется с помощью маркетинговых исследований. Следует оценить эти альтернативы с точки зрения стоимости ЖЦ системы. Для определения количественных параметров полезны математические модели. Выбранные альтернативы ранжируют в соответствии с установленными критериями отбора. Стоимость всегда является ограничивающим фактором. Однако также важны такие критерии, как время разработки, риск и надежность. Полезно оценить возможности выбора инструментов проекта и поставщиков.
4. Выбор лучшей проектной альтернативы. Эксперты выбирают лучшее решение из альтернативных концепций дизайна, принимая во внимание субъективные факторы, которые команда не могла определить количественно, например надежность. Важны также оценки того, насколько эти альтернативы соответствуют количественным требованиям: эффективности, стоимости, графику, рискам или другим ограничениям. Процесс анализа принятия решений, который описан в главе 3.9, должен использоваться для оценки альтернативных концепций дизайна и рекомендации наилучшего решения для проектирования.
5. Выбор и верификация решения для проектирования. После выбора предпочтительной альтернативы дизайна определяется окончательное решение, которое будет удовлетворять техническим требованиям и концепции эксплуатации системы. После того как решение было выбрано и задокументировано в пакете технических данных, оно должно быть верифицировано на соответствие системным требованиям и ограничениям. Нужно показать, что удовлетворены требования верхнего уровня и ожидания заинтересованных сторон.
6. Валидация проектного решения. Она отличается усеченной полнотой требований от валидации конечного продукта. Оперативная валидация может включать вопросы.
• Работает ли система так, как ожидалось?
• Как система реагирует на сбои, сбои и аномалии?
• Доступна ли система?
Если ответа на любой из этих вопросов нет, тогда потребуются изменения в проекте и процесс начнется снова.
7. Идентификация обеспечивающих продуктов. Обеспечивающими называют продукты и услуги поддержки жизненного цикла (например, производство, тестирование, развертывание, обучение, обслуживание и утилизация), которые облегчают продвижение и использование конечного продукта в течение его жизненного цикла. Поскольку конечный продукт и его поддерживающие продукты взаимозависимы, они рассматриваются как единая система. Поэтому важной задачей в процессе определения проектного решения является идентификация предоставляемых продуктов и персонала, которые понадобятся в течение жизненного цикла выбранного проектного решения.
Результаты процесса определения проектного решения рекомендуется документировать.
• Спецификации конечных продуктов, которые представляют собой подробные описания конструктивных особенностей, включая материалы, размеры и качество работы для сборки, установки или производства конечного продукта.
• Спецификации интерфейса конечного продукта, которые содержат подробные требования к построению и кодированию поведения и характеристик всех логических и физических интерфейсов, которые конечный продукт имеет с внешними элементами, включая интерфейсы человек-система.
• Начальные спецификации подсистем, которые предоставляют подробную информацию, если требуется.
• Требования к обеспечивающим продуктам, в которые входят продукты поддержки жизненного цикла, инфраструктура, персонал, логистика и услуги, которые облегчают продвижение и использование эксплуатации конечного продукта в течение его жизненного цикла.
• План верификации продукта, который включает квалификацию, приемку, предварительную, оперативную и операционную проверку действий для аппаратного и программного обеспечения.
• План валидации продукта, где включены процедуры и среда валидации, для подтверждения того, что реализованный конечный продукт соответствует ожиданиям заинтересованных сторон.
• Планы логистики и оперативных процедур, включая обработку, транспортировку, послепродажное обслуживание, и обеспечение длительного хранения для конкретного проектного решения.
Пример критериального решения показан для выбора места рабочего обеда. Назначены три критерия: расстояние до кафе (пункта питания), качество пищи и ее стоимость. В результате опроса группы сотрудников получены относительные оценки критериев в баллах. Далее проведена операция нормирования результатов, чтобы перейти к весовым коэффициентам в долях единицы (колонка справа в таблице 1).
Таблица 1
Можно видеть, что в результате критериального выбора наивысший весовой коэффициент получило кафе, расположенное ближе других. Тогда как факторы качества пищи и ее стоимости оценены существенно ниже.
Роль команды проекта заключается в тщательной подготовке материалов, на основании которых может быть принято наиболее эффективное решение. Не следует сожалеть о результате после принятия решения. Для процессов создания сложных систем часто имеется целый набор решений, близких к оптимальному. Изменение результата можно рассматривать только в рамках повторного прохождения итерационных циклов проекта либо по результатам последующего технического обзора, если выяснится, что при принятии решения не были учтены существенные факторы проекта. Очевидные выводы предостерегают от излишнего увлечения непроверенными решениями.
В каждом проекте наступает момент принятия решения о заморозке документации. После него дальнейшие изменения в дизайн продукта не могут быть внесены без финансового риска, особенно если затем проект должен быть отправлен в производство. Заморозка проекта имеет преимущество, заключающееся в минимизации последующих изменений проекта. Она также может быть необходима для своевременной закупки товаров с длительным сроком поставки, таких как заготовки, ПКИ и инструменты, необходимые для производства конечного продукта. Несоблюдение точек замораживания при проектировании оказывает значительно большее влияние на подготовку производства, чем на инженерное проектирование. После заморозки решения об изменениях принимает только руководство проекта.
Необходимы некоторые разъяснения по поводу новизны принимаемых решений, а именно, нужно ли изобретать в проекте? На основе результатов статистического исследования сделан вывод, что большинство концепций и проектов есть модификации предыдущих с относительно малой новизной (Г. Альтшуллер, автор Теории Решения Изобретательских Задач). Их следует разыскивать первыми. В качестве примера можно привести появление в 2010 г. на рынке планшетного устройства, завоевавшего умы покупателей в возрасте от 3 до 90 лет, в конструкции которого не было использовано ни единого нового компонента.
Еще одним важным вопросом принятия проектных решений является применение правила копирования при использовании компонентов, модулей, подсистем, покупаемых готовыми на рынке (ПКИ):
a) любое использование заимствованных частей изделия проверяется на качество и верифицируется также, как новое оборудование;
b) при проверках обязательно учитываются доработки проекта, изменения в эксплуатационных требованиях и условиях относительно указанных в технических условиях на ПКИ;
c) должен быть приложен набор документов, требуемых для обоснования применения ПКИ в конкретном проекте;
d) не следует проверять компоненты с рынка через теорию подобия, необходимо использовать традиционные верификационные методы: испытания, анализ, проверки.
Перечисленные правила связаны с тем, что покупные изделия разработаны для других программ, отличающихся условиями применения, ресурсом, входными данными и др. Отметим, что следует обдуманно применять в конструировании оптимизационные методы математического анализа. Как правило, математический оптимум не является лучшим инженерным решением. В пространстве поиска существует область параметров вблизи, лучше удовлетворяющих часто противоречивому набору требований проекта, в том числе стоимости и сложности исполнения.
Например, вследствие выстроенного хаотично процесса конструирования был получен перегруженный узел конструкции «парашютный замок» (используемой для закрепления лямок ранцевого парашюта на груди парашютиста). Пересмотр с позиций системной инженерии привел к уменьшению количества деталей с 46 (включая 20 резьбовых и заклепочных соединений) до 7 (2 соединения), снижению массы на 25% при увеличении разрешенной нагрузки вдвое (с 160 до 320 кг силы), себестоимость при этом снизилась на 50%.
2.6. Синтез системы
На основании принятых решений завершается выполнение проекта (синтез) и процесс интеграции системы. Синтез открывает содержание «как» для каждого пункта «что» и «как хорошо». Продукция синтеза системы включает базовую физическую архитектуру (как спроектировано) и результаты маркетинга подсистем. Место синтеза в общем процессе СИ показано на рис. 5.
На этапе синтеза продукта эффективно применяют интеграционную методологию параллельного инжиниринга. Это систематический подход различных специалистов, сотрудничающих одновременно в общей среде, реальной или виртуальной, для создания совместного дизайна, достигая сокращения времени цикла разработки продукта за счет лучшей интеграции мероприятий и процессов. В рамках параллельного инжиниринга обеспечивается общая инфраструктура инструментов, данных и поддержки информационных технологий, образуя интегрированную среду поддержки для использования командой. В совместной среде ключевые участники могут исследовать предположения и альтернативы с группой заинтересованных сторон или другими членами команды дизайнеров, и быстро переориентировать всю команду, когда происходит изменение дизайна.
Успех параллельной инженерии основан на деятельности талантливой и опытной группы инженеров и ученых, которые составляют команду, где поддерживаются соответствующие инструменты и средства, чтобы сделать свою работу более эффективно. Основные ключевые позиции в команде: заказчик, руководитель по исследованиям, системные интеграторы, инженеры подсистем (включая экспертов по рискам и расходам). При этом группа инженеров напрямую взаимодействует с заинтересованными сторонами для облегчения проектирования, а клиент становится активным участником процесса разработки. Менеджер проекта должен понимать разницу между совместной работой в общем помещении и распределенной (часто удаленной) работой. Для последней требуются дополнительные организационные усилия в части управления, инструментов и коммуникационных технологий.
Важнейшим элементом в процессе развития параллельного инжиниринга стало освоение трехмерного электронного макета изделия (ЭМИ), используемого командами проекта 24 часа в сутки. На ЭМИ разрабатывают чертежи и сборки, а также управляют комплектом документации. Работа с ЭМИ существенно снижает время проектирования и затраты. Электронный цифровой макет изделия становится средоточием информации о продукте, определения в ГОСТ 2.051…2.058. Он создается и направляется системой управления данными о продукте, которая поддерживает выпуск технической документации и управление конфигурацией изделия.
ЭМИ сегодня служит главным инструментом общения инженерных команд и фундаментом диалога проектантов с производством. Вокруг ЭМИ строятся регулярные совещания по статусу проекта, вместо затратных физических макетов, применявшихся ранее. Организация процесса коммуникации между командами, участвующими в проекте, и внутри команд лежит в зоне ответственности менеджера проекта. Очень важно не допустить сбоев в параллельном инжиниринге из-за распространения неверной или запаздывания правильной информации и данных, что повлечет переделку части работ и финансовые потери.
В ЭМИ могут быть включены технические данные системы, 3-Д модели, документы и обеспечивающие процессы, необходимые для использования при дальнейших этапах работ. Например, трехмерная модель системы, набор и система управления техническими документами проекта, система управления составом изделия, система управления жизненным циклом изделия, технологические данные, содержащие необходимые указания для производства (используемые инструменты, материалы, технологии, средства контроля и т.д.), результаты расчетов различными средствами CAE, данные для проектирования и изготовления оснастки, технологические процессы, библиотеки операций и переходов в производстве.
Электронный макет соответствует текущему этапу жизненного цикла продукта и в авиастроении включает обычно три уровня проработки (рис. 12).
Рис. 12. Три этапа «зрелости» ЭМИ
Исходной является мастер-геометрия обводов самолета (теоретические профили аэродинамики). Макет ЭМИ-1 используется для предварительных компоновочных решений по продукту и включает все внешние формы самолета или секции, основные геометрические сведения о силовом наборе (рамы, стрингеры, шпангоуты и лонжероны), важные интерфейсы, системы координат, необходимые для позиционирования подсборок между собой, общие виды.
Принятые решения пересылаются и проверяются на следующей стадии ЭМИ-2. Это макет распределения внутренних объемов самолета под компоненты и агрегаты, который служит для проработки использования допустимого пространства внутри самолета при его заполнении конструктивными элементами, определения расположения подсистем и частей оборудования, проверки их взаимной увязки. ЭМИ-2 определяется трехмерными моделями частей изделия, позиционированными в пространстве, причем система управления данными следит за соблюдением связи между геометрией и конфигурацией продукта. Инженеры проверяют взаимную предустановку частей, систем и оборудования, удобство их монтажа и обслуживания. Следующим важным этапом проектирования на ЭМИ-2 является пространственная увязка расположения систем, частей и деталей, уточнение возможности сборки при производстве, а также интерфейсы.
На базе 3-Д моделей макета второго этапа ЭМИ-2 после «замораживания» всех проектных решений конструкции выпускается рабочая документация (РКД), которая передается намеченным производителям для согласования и доработки технологий производства. Компоненты РКД включают 3-Д модели и сборки согласно ЭМИ, производственные чертежи, спецификацию (график работ), извещения об изменениях, алфавитную базу данных проекта для справочных нужд. Все чаще на сложных изделиях вместо РКД передают в технологическую службу образмеренные (аннотированные) 3-Д модели деталей, согласно стандартам ISO 16792:2015, ASME Y14.41—2012, MIL-STD-31000A.
Разработанная и скорректированная рабочая документация служит основой для финального макета изделия ЭМИ-3 (справочная геометрия, сертификация). Этот макет строится в завершающей стадии конструирования на основании производственных чертежей с технологическими изменениями и служит источником для стадий производства, эксплуатации, разработки модификаций на следующих этапах ЖЦ. Также ЭМИ-3 включает базу сертификационных расчетов на прочность, сборник требований по установке систем и оборудования.
В стандарте ГОСТ Р 58301—2018 «Управление данными об изделии. Электронный макет изделия. Общие требования» предложена классификация моделей, привязанных к основным фазам жизненного цикла. Функциональный макет ЭМИ-Ф включает взаимосвязанную совокупность данных, описывающих устройство, состав, характеристики, принципы работы и возможные нарушения исправного состояния изделия. Конструкторский макет ЭМИ-К содержит взаимосвязанную совокупность данных, описывающих конструкцию и требования к изготовлению и сборке изделия. Технологический макет ЭМИ-Т концентрирует взаимосвязанную совокупность данных, описывающих технологию изготовления и используемых для планирования, оценки и организации процесса производства изделия. Эксплуатационный макет ЭМИ-Э включает взаимосвязанную совокупность данных, описывающих эксплуатационные свойства изделия и требования к процессу его технической эксплуатации.
В состав рабочей конструкторской документации (РКД), разработанной по ЭМИ, входят стандартные компоненты. Производственные подразделения используют согласованный комплект документов, который имеет соответствующее «говорящее» кодирование (нумерацию чертежей), позволяющее в минимальном количестве цифр изложить всю необходимую информацию о детали. Вокруг разработки ЭМИ необходимо организовать процессы технического контроля (регулярные по времени ревизии). Командная работа на электронном макете является важным компонентом снижения времени разработки, повышения качества документации, упрощения обмена данными со службами технологической подготовки производства.
В каждом узле большого проекта должен работать один или несколько ЭМИ-интеграторов, чьи задачи состоят в следующем:
•проверять правильность данных, поступающих в ЭМИ, особенно затрагивающих конфигурацию, а также наличие связей файлов, необходимых для совместной работы;
• проводить анализ проблем и подтверждать корректность ЭМИ (особенно после фаз интеграции), т.е. проверки, что нет «коллизий», аномальных данных, «наездов» деталей друг на друга;
• управлять качеством данных ЭМИ (рекомендуется иметь выделенного сотрудника, занятого на этой конкретной позиции);
• помогать менеджерам связывать параллельные виды деятельности и интегрировать их результаты внутри процессов параллельного инжиниринга.
В ходе проверки результатов работ на ЭМИ удобно использовать типовые вопросники, составленные и пополняемые с учетом традиций компании-разработчика и накапливающегося опыта. Чек-листы (документированный перечень вопросов для проверки) составлены и корректируются с учетом имеющейся статистики, содержат компоненты критической базы знаний, хорошо помогают при дефиците обученного персонала, важны, чтобы не забыть задавать проясняющие вопросы. Их активно используют на этапе проверки документов или этапов работы (обнаружить проблемы пока не поздно, гарантировать их обнаружение) для нахождения ошибок оформления конструкторской документации, технических проблем и др. Хотя практика показала, что проблемы находятся нечасто, применение чек-листов полностью окупается. Текущее внесение в чек-листы типовых конструкторских ошибок существенно улучшает качество документации на финише проекта.
Вышеперечисленный объем работ нескольких проектных групп одновременно на регулярно актуализируемом ЭМИ и его компонентах, отработка электронных сборок, включающих до 50 000 деталей, позволяют существенно повысить качество выдаваемой конструкторами документации, в 6…10 раз снизить стоимость затрат на корректировки конструкторских решений в производстве. Первым самолетом, спроектированным с использованием электронной документации, был Boeing-777 (в серии с 1995 г.). Его проектирование, разработка и испытания с широким использованием моделирования и виртуального эксперимента, замена физических макетов на ЭМИ позволили получить (сравнительно с созданием предыдущих самолетов В-757, B-767) ряд преимуществ:
a) исключено более 3000 сборочных интерфейсов;
b) получено 90% снижения запросов на изменение РКД (т.е. в 10 раз);
c) на 50% ускорен цикл обработки запросов на изменения;
d) достигнуто 90% снижения переделок конструкции (т.е. в 10 раз);
e) обеспечено улучшение допусков на сборку фюзеляжа (повышена точность подгонки секций).
На рис.13 показано улучшение качества конструкторской документации на разных фазах ЖЦ при использовании ЭМИ. Здесь ПИ обозначает предварительные извещения об изменениях.
Рис. 13. Влияние ЭМИ на снижение числа изменений РКД
Процесс интеграции системы из компонентов и подсистем является одним из важнейших в проекте, так как завершает процедуру разработки получением конечного продукта. К сожалению, в отечественной практике данный этап либо не выделен, либо сведен к процессу финальной сборки производственными подразделениями и приемочным испытаниям. Целью этапа интеграции является собрать вместе все части или элементы интересующей системы в единое целое для обеспечения их совместной работы. Интеграция продукта включает в себя множество мероприятий, которые необходимо планировать на ранней стадии программы или проекта, чтобы эффективно и своевременно выполнить интеграцию. Необходимо собрать и интегрировать полученные части в систему в соответствии с указанными требованиями, конфигурационной документацией, требованиями к интерфейсу, применимыми стандартами, последовательностью и процедурами интеграции. В процесс входят управление, оценка и контроль физических, функциональных данных и интерфейсов между интегрируемыми продуктами.
Напомним некоторые термины и принципы процесса интеграции.
Принципом называют описание того, что должно быть, или того, что есть, или руководство, которое, возможно, является разумным. Принципы проверяют для верности, подтверждая опытом и экспериментами. Их можно объединить, превратить в связный массив знаний и принять в качестве основы для рассуждений, логики и действий, классифицировать и интерпретировать ситуацию с точки зрения предыдущих итераций.
Событием называют происходящее действие или происшествие, приводящее к изменению объекта вследствие преобразования входа в выход. События имеют структуру, могут быть упорядочены и распознаются как объекты, физические или интеллектуальные.
Ситуацией называют последовательность событий, в которой событие описывает деятельность, которая связывает входной сигнал или компонент с выходным.
Принцип согласованности интеграции включает согласование стратегий ключевых заинтересованных сторон с целями проекта и предоставление согласованного продукта или услуги, что имеет первостепенное значение для успеха.
Принцип разделения (декомпозиции) делит концепции высокого уровня на несколько объектов низкого уровня для упрощения работ.
Принцип индукции отражает мышление, направленное на достижение интеграции на основе правил. Это требует индуктивного рассуждения, чтобы отслеживать модели, отражающие реальность, обобщая подходы, а также собирая доказательства, которые предполагают динамику взаимодействия между процессами.
Принцип ограничения отражает тот факт, что концептуальная архитектура, концепция операций и проект системы сильно зависят от бюджетных ограничений. Следовательно, архитектура нижнего уровня соразмерно ограничена в стоимости, обусловленной распределением ресурсов.
Принцип предусмотрительности напоминает, что ключевые факторы, определяющие интеграцию, должны учитываться на этапах планирования интеграции. Это определение требований; соображения по поводу решения проблемы, включенные в проект системы; достижение и удовлетворение ключевых потребностей заинтересованных сторон, осуществляемых с помощью архитектуры; создание физических объектов, которые воплощают ожидаемые функциональные возможности (и их характеристики) и обеспечивают желаемое поведение пользователей. Планирование интеграции облегчает проблемы по ее ходу, вызванные неэффективными измерениями, компромиссами, а также непродуманным графиком или распределением ресурсов для преодоления технических проблем.
Принцип планирования интеграции заключается в определении того, сколько времени потребуется для выполнения задач. Для чего определяют тип и количества ресурсов, задержки из-за внутренних и внешних факторов, связанных с выполнением задачи и др. Сетевое планирование прогнозирует влияние на бюджеты и график различных последовательностей и длительностей объектов, которые нужно интегрировать. Управленческий резерв может быть использован для борьбы с неопределенностями, связанными с проблемным или неумелым управлением. Интеграция с эмуляторами (имитаторы компонентов системы) позволяет впервые взглянуть на вопросы интеграции для построения подфункций, пока не станет доступным реальный объект, готовый к тестированию. Процедуры использования эмуляторов для выполнения интеграции, как правило, никогда не совпадают с интеграцией намеченных объектов. Часто производительность эмулятора значительно медленнее, чем у реального объекта.
Интеграция системы проводится на различных уровнях для достижения требуемого эффекта:
• интеграция на уровне компонентов: способность убедиться, что дискретная функция компонента соответствует общей системе, в которой он находится;
• на уровне системы: слияние отдельных функций и характеристик, ранее выполнявшихся дискретными элементами управления, в область общего управления;
• на уровне процесса: постепенное наращивание компонентов продукта в единое работающее и протестированное изделие;
• на функциональном уровне: идентификация интегрированных функций как объединения многих отдельных функций для формирования наглядного эффективного (измеримого) результата.
Для достижения системной интеграции используют подходы сверху вниз или снизу вверх. В первом берут все подсистемы интересующей системы и объединяют их за один раз. Подсистемы индивидуально тестируются перед интеграцией, но все они собираются одновременно для интеграции. Этот метод сопряжен с высоким риском, поскольку в нем любую обнаруженную проблему сложно изолировать и решить. Второй подход начинается от элементов самого нижнего уровня и их интеграции с проверяемыми приращениями. Процесс движется от нижнего уровня системы к подсистемам верхнего уровня. Одним из положительных аспектов этого подхода является то, что элементы более низкого уровня обычно можно интегрировать в начале программы. Этот подход, по сравнению с первым, также снижает риск за счет одновременного введения ограниченного числа неизвестных переменных.
Интеграция является одним из самых затратных и трудоемких мероприятий в процессе системного проектирования. Для больших и сложных систем на эту деятельность может быть использовано до 40% усилий по разработке, в основном для системных испытаний. Порядок, в котором элементы системы интегрируются в единое целое, должен быть тщательно спланирован, важно учесть график работ и интерфейсы. Не следует на этом этапе объединять все или слишком много элементов одновременно. Наиболее практичный подход, используемый для новых или модифицируемых систем, заключается в том, чтобы вводить в ходе синтеза элементы системы через ряд промежуточных состояний конфигурации или стадий работы. Выполняется функциональное тестирование собранного устройства, чтобы убедиться, что сборка готова для проверочных испытаний и готова к интеграции на следующий уровень. Как правило, проверяются ключевые функции, чтобы гарантировать, что собранная система функционирует должным образом.
Планирование процесса интеграции начинается, когда определяется перечень мероприятий по проекту. Уточнение плана интеграции происходит во время этапа проектирования архитектуры высокого уровня. Интеграция выполняется, когда компоненты оборудования и программного обеспечения разработаны и сданы командами разработчиков. Интеграция и верификация являются тесно связанными итерационными процессами, следующими один за другим до тех пор, пока вся система не будет готова к оперативному развертыванию.
План интеграции охватывает подход, тестирование и проверку интегрированных подсистем, а также определение проверки интегрированной системы. Он обычно включает:
a) аспекты развития (графические ограничения, ресурсы, оборудование, рабочая сила);
b) результаты шагов разработки (проектирование системы, предварительный проект, детальное проектирование, архитектура, описания физических объектов, интерфейсов между физическими объектами, описания функциональных возможностей продукта или услуги);
c) планы тестирования (от ранней до поздней стадии). Желательно продемонстрировать функциональные связи (т.е. небольшие последовательные подфункции), которые при сквозном объединении раскрывают системную функцию.
При реализации процессов интеграции системы полезно начинать с четкой коммуникации между исполнителями, чтобы все понимали цели проекта и свои роли. Далее составить карту всего процесса для выявления потенциальных рисков и спланировать действия в чрезвычайных ситуациях. Первыми объектами, которые необходимо интегрировать, являются те, которые необходимы и достаточны для демонстрации сквозной жизнеспособности основной функции системного уровня. После завершения и демонстрации основного системного потока аналогичным образом обрабатываются параллельные, взаимодействующие и вспомогательные потоки, которые добавляют дополнительную функциональность. В процессе исполнения рекомендуются регулярные проверки для получения обновлений о ходе работ и проблемных отказов, для отслеживания задач и поддержания видимости операций. После интеграции проводится заключительное испытание, чтобы убедиться, что все работает так, как ожидалось.
Примерная последовательность шагов интеграции включает несколько этапов.
Первый этап модели системного процесса для интеграции содержит идентификацию объектов парами, которые необходимы для демонстрации функции верхнего уровня, подфункции, которые поддерживают функции верхнего уровня.
На втором этапе проводят распознавание и характеристики системных функций верхнего уровня в простейшей форме для демонстрации сквозного потока системного уровня. Несколько связанных показателей должны быть измерены и определены как эталонные для демонстрации осуществимости.
Третий этап охватывает расширение интеграции приоритетных системных функций верхнего уровня и критических независимых функций. Входит планирование тестирования, выполнение испытаний и проверка приоритетных функциональных потоков системного уровня.
Четвертый этап включает общее улучшение производительности всех потоков системного уровня за счет улучшения подфункций. Механизмы настраиваются, совершенствуются или заменяются улучшенными компонентами или объектами. Кульминацией четвертого этапа является испытание на уровне системы.
На пятом этапе выполняют подготовку валидации. Верификация проекта системы, архитектуры, концепции операций и спецификаций должна быть завершена до интеграции физических объектов, чтобы гарантировать, что в конечном итоге проводится интеграция объектов и функций, которые удовлетворяют спецификациям и требованиям. В заключение этапа осуществляется валидация системы.
В сложных проектах не всегда возможно интегрировать все системы в один этап. План системной интеграции должен учитывать интерфейсы для разработки серии запланированных промежуточных этапов, чтобы объединить различные подсистемы контролируемым образом, включая спецификацию интеграционных тестов. Разработчик системы (и подсистем) должен сотрудничать с командой испытателей и вводом объекта в эксплуатацию для планирования этих мероприятий по интеграции и тестированию, а также критериев приемлемости. Для интеграции сложных систем могут быть использованы десятки испытательных стендов.
Управление интерфейсом на этапе интеграции поддерживает процедуры сборки для обеспечения надлежащей маркировки и совместимости интерфейса со спецификациями и документом управления интерфейсом. Верификация требований к интерфейсам является критическим аспектом общей верификации системы, часто с использованием эмуляторов, которые должны соответствовать характеристикам операционной среды и требованиям проверки интерфейса.
Сбои, возникающие в процессе интеграции, имеют несколько основных причин, включая плохое управление (плохое согласование ресурсов с требуемыми задачами, плохую коммуникацию и ненадежную функциональность, связанную с тем или иным объектом), плохие навыки интеграции, инструменты или испытательное оборудование.
Входными данными для процесса интеграции системы являются следующие:
• концепция операций, которая определяет, как система должна работать и будет помогать в проверке и интеграции;
• утвержденные требования к системе и подсистемам;
• архитектура проекта высокого уровня, где определены интеграционные операции;
• материалы детального конструирования, которые содержат конструктивные ограничения для подсистем и систем;
• стратегия интеграции, где определено, когда и где подсистемы должны быть сгруппированы и развернуты;
• разработанные аппаратно-программные компоненты и подсистемы, в которых завершена интеграция на своем уровне и они готовы к следующему уровню верификации.
При создании реалистичной среды испытаний и оценки необходимо учитывать следующие факторы.
1. Выбор тестового задания. Система и ее компоненты, выбранные для испытаний, должны представлять собой проектную или производственную конфигурацию, включающую все последние утвержденные инженерные изменения.
2. Выбор испытательной площадки. Система должна быть протестирована в среде, которая будет характерна для операций пользователя; Выбранная площадка должна в максимально возможной степени имитировать условия Арктики или тропиков, равнинную или гористую местность, и др.
3. Процедуры тестирования. Выполнение задач испытаний обычно включает выполнение задач эксплуатации и технического обслуживания, которые должны следовать официально утвержденным техническим руководствам.
4. Испытательный персонал. Сюда входят лица, которые будут фактически эксплуатировать и обслуживать систему на протяжении всего испытания, вспомогательные инженеры, техники, регистраторы данных, аналитики и администраторы, которые оказывают помощь в проведении всей программы испытаний. Отобранный эксплуатационный персонал должен соответствовать требованиям с точки зрения количества и уровня квалификации.
5. Тестирование и поддержка оборудования и ПО. При использовании оборудования наземного обслуживания, испытательного оборудования, программного обеспечения следует использовать только те объекты, которые допущены к эксплуатации.
6. Снабжение испытаний. Сюда входят все запасные части, расходные материалы и вспомогательные запасы, необходимые для завершения тестирования и оценки системы. Желательна реалистичная конфигурация.
7. Испытательные мощности и ресурсы. Должны быть заранее определено и запланировано использование специальных помещений, испытательных камер, оборудования, средств экологического контроля, специальных приборов и сопутствующих ресурсов (например, тепла, воды, кондиционирования воздуха, электроэнергии, связи).
8. Требования к интерфейсу. Применимые интерфейсы и требования к тестированию должны быть определены и согласованы по всем направлениям по мере необходимости.
Во время системной интеграции дизайнеры должны быть доступны для поддержки тестирования и ввода в эксплуатацию. Они обеспечат соответствие первоначального дизайна интерфейса и разрешат изменения, требуемые при решении проблем, которые могут возникнуть во время интеграции и тестирования. В некоторых системах значительная часть системной интеграции и тестирования может быть проведена вне площадки сборки на заводе-изготовителе поставщика в качестве заводских интеграционных испытаний. Например, в процессе интеграции воздушных судов в качестве основных наземных стендов используют стенд системы электроснабжения самолета; стенд гидросистемы и механизмов с полунатурным моделированием комплексной системы управления и системой управления общесамолетным оборудованием, так называемую «железную птицу»; стенд комплексирования бортового оборудования, или «электронную птицу».
В результате процесса должен быть получен интегрированный продукт со всеми системными взаимодействиями. Оформлены документация и руководства, включая модели, данные и отчеты системного анализа, подтверждающие обоснование готовности и доступные для будущего анализа во время работы системы; отчеты по интеграции продуктов (для поддержки процесса управления техническими данными); чертежи сборки и верификации; требования к эмулятору (где приложимо); и документированные ограничения для аппаратного и программного обеспечения.
Следует отметить, что кроме технологической интеграции на этапе необходимо реализовать управленческую компоненту интеграции. Она включает интеграцию по срокам работ, затратам, ресурсам, рискам и координацию всех частей процесса интеграции в целом. Причем приоритет управленческой интеграции выше, чем технологической, из-за большего числа охвата факторов.
Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.
2.7. Верификация и валидация
Одним из основных принципов системно-инженерного подхода является пошаговая проверка результатов работ на соответствие выставленным требованиям. Для проверки результатов каждого шага разработки используются два метода: верификация и валидация.
Верификация представляет процесс подтверждения того, что требование или система соответствует входным данным. Проверка требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию? Верификация системы или ее компонента показывает, что синтез системы выполняется правильно, гарантирует, что система соответствует требованиям. Этот процесс выполняется на различных этапах создания системы, как правило, внутренними силами разработчика с привлечением коллег для контроля результатов. Используют четыре метода верификации: инспекцию, анализ, демонстрацию, испытания (тесты).
Каждый элемент системы проверяется на соответствие требованиям. Метод верификации для каждого требования должен начать формироваться на этапе анализа требований. Важно определить, как каждое требование будет проверяться на раннем этапе, чтобы любое оборудование для верификации или необходимое моделирование были доступны к этапу верификации.
Планы верификации должны быть рассмотрены заинтересованными сторонами проверяемого требования. Согласие заинтересованных сторон с планом верификации помогает обеспечить единообразное понимание требования с проектировщиками. Стоимость методов верификации важно учитывать, поскольку они могут сильно различаться по стоимости, но достигать одной и той же цели.
Валидация представляет процесс подтверждения того, что набор требований, проект или система соответствует предназначению заказчика, другими словами, построена потребная система. Валидация определяет правильность и полноту конечного продукта, и гарантирует, что система удовлетворит реальные потребности заинтересованных сторон в предполагаемой среде эксплуатации. Как правило, проводится с привлечением внешних инстанций (регулирующих органов, представителей заказчика, межведомственных комиссий и др.). На этапе валидации система проверяется во всех режимах работы или сценариях. Как и на этапе верификации, этап валидации необходимо планировать заранее. Причина раннего планирования валидации в том, что она предназначена для обеспечения окончательного утверждения системы заинтересованными сторонами. Также при валидации могут потребоваться компоненты инфраструктуры, которые нужно изготовить к определенному сроку.
Вкратце различия применения верификации и валидации можно изложить следующим образом. Верификация проводится:
• в процессе разработки;
• чтобы убедиться, что утвержденные требования будут выполнены;
• как правило, в лабораторных условиях (не натурных);
• верификация ориентирована на компоненты и подсистемы.
Аналогом в РФ выступают компонентные испытания и проверки на моделирующих стендах.
Верификация системы или ее компонентов и подсистем является более общим понятием, чем просто проведение испытания. Целью верификации является проверка, что верифицируемый объект соответствует требованиям к нему, реализован без лишних функций, удовлетворяет проектным спецификациям и стандартам. Как уже упоминалось, процесс верификации включает разные методы, то есть процесс испытаний является составной частью процесса верификации.
Валидация выполняется:
a) в процессе или после процедуры интеграции системы;
b) обычно в реальных или смоделированных условиях эксплуатации;
c) для проверки ожиданий заинтересованных сторон;
d) желательно в составе полномасштабного варианта системы.
Аналогом в РФ являются сертификация, государственные или межведомственные испытания.
Валидация системы служит доказательством, что в результате разработки системы достигнуты цели, которые планировали для эксплуатации. Другими словами, это проверка соответствия системы ожиданиям заказчика, гарантия ее качества. Когда экономически выгодно и гарантировано анализом, расходы программы могут быть смягчены путем объединения тестов для одновременной верификации и валидации конечного продукта или системы.
Основные задачи верификации при разработке перечислены ниже.
1. Планирование верификации конструкторских решений в соответствии с планом верификации, контрактом с заказчиком, применимой фазы жизненного цикла и до уровня структуры системы. Соответствующий уровень может варьироваться от системы и подсистемы вниз до уровня компонентов. Он может включать выбор и определение соответствующего метода для проверки проектных решений, процедуры верификации для следования выбранному методу (включая критерии определения успеха или неудачи проверки); создание и проверку влияния окружающей среды (например, климатические условия, оборудование, сооружения, измерительные приборы и т.д.), в которой будут реализованы метод и процедуры проверки.
2. Выполнение плана верификации проектных решений. Используют выбранные методы и процедуры в установленной для проверки окружающей среде, чтобы осуществить сбор и оценку результатов верификации для показа соответствия требованиям представленного физического решения, или определить отклонения (непроверяемые требования и ограничения). Отклонения должны быть документированы в отчете по несоответствиям или в интегрированной базе данных предприятия для оценки и разрешения проблем.
3. Повторение верификации в соответствии с планом, методом испытания или процедурой, когда отклонения (разброс данных) были вызваны недостаточной адаптацией к условиям окружающей среды в эксплуатации.
4. Фиксация записи результатов верификации, в том числе: корректирующих действий; уроков исправления, достигнутых результатов; компромиссов, анализа рисков, результатов испытаний; отклонений и проверенных решений проекта в хранилище данных предприятия.
Валидация может охватывать следующие действия.
• Тестирование производительности для проверки того, что продукт или система функционирует должным образом и соответствует ожиданиям клиентов.
• Испытание для подтверждения того, что изделие соответствует всем законодательным требованиям, требованиям безопасности и нормативным требованиям, включая формальные приемочные испытания.
• Испытание на срок службы (ресурс) для подтверждения того, что продукт будет продолжать функционировать в соответствии со своими требованиями на протяжении всего заданного срока службы.
• Экстремальные испытания для подтверждения того, что продукт будет продолжать функционировать в экстремальных сценариях эксплуатации внутри рабочего диапазона или при работе в различных условиях окружающей среды.
• Испытания на надежность, чтобы доказать, что продукт будет надежно функционировать с точки зрения частоты отказов на протяжении всего расчетного срока службы.
• Подтверждающее тестирование, чтобы продемонстрировать, что продукт, изготовленный методами массового производства, работает так же, как продукт, изготовленный на ранних этапах проекта.
Необходимым элементом валидации сложной техники являются испытания компонентов и системы в целом (модельные, натурные, квалификационные, в составе объекта, сертификационные). При испытании технические средства, такие как специальное оборудование, приборы, методы моделирования, используют для объективной оценки характеристик системы или ее компонентов на определение соответствия целевым значениям требований. Типовой тест включает процесс моделирования сценариев эксплуатации всей системы или ее части под ограниченным набором контролируемых условий, чтобы определить количественное выполнение проектных или эксплуатационных требований.
Ведутся работы по развитию численных испытаний с использованием цифровых двойников, виртуального моделирования динамических процессов в системе. Целью данного направления является замена части натурных испытаний системы (как правило, дорогостоящих и длительных) результатами цифрового моделирования статических и переходных режимов эксплуатации, а также нерасчетных случаев (частичных отказов узлов и агрегатов, нештатных условий применения и др.). Предварительно сами цифровые двойники (расчетные модели) должны быть верифицированы для подтверждения требований достоверности и точности расчетных результатов.
Комплексное тестирование включает выполнение полных рабочих сценариев для нескольких элементов конфигурации, гарантирующих, что все требования к системе будут проверены. Эксплуатационные сценарии должны быть описаны для всех режимов работы, фаз применения (например, установка, запуск, типичные примеры операций с нормальными и аварийными ситуациями, выключение и обслуживание) и критических последовательностей действий. В сценарии дается пошаговое описание того, как система должна работать в конкретных условиях применения.
В процессе валидации важно сравнить фактические результаты с ожидаемыми. После завершения деятельности по проверке результаты собирают и анализируют. Данные проверяют на качество, целостность, правильность, согласованность и достоверность. Любые несоответствия проверки (аномалии, варианты и условия несоблюдения) идентифицируют и пересматривают, определяют запросы, необходимые в результате проверки для привлечения помощи или изменения требования. Недостатки и рекомендуемые корректирующие действия и результаты разрешения должны быть записаны.
При планировании испытаний требуется:
• разработать подробные квалификационные требования к испытаниям;
• определить подробные архитектуры компонентов для тестовых ресурсов (выявить, какие специальные установки, измерительные приспособления и тестовые заглушки необходимы);
• инициировать разработку и изготовление необходимых стендов;
• сформировать матрицы испытаний (выделить производные требования к функциональным и физическим архитектурам);
• написать детальные планы квалификации для каждого компонента с учетом ресурсов;
• создать сценарии тестирования с учетом нормативной документации;
• определить необходимые данные мотивации для каждого вида деятельности;
• написать программы испытаний и процедуры анализа результатов;
• определить графики по срокам испытаний и анализа.
В таблице 2 показан пример матрицы верификации для плана испытаний продукта. В левых столбцах указаны пункты технического задания для верификации и названия этапов работ. В последних колонках показаны выбранные верификационные методы по типам.
Планирование процедур верификации узлов и компонентов должно учитывать потребные сроки на проектирование и изготовление стендов и моделей. В одной из организаций проектирование стендов поручили разработчикам системы в порядке очередности. В результате на два года сорвали сроки испытаний из-за задержки изготовления стендов.
Таблица 2
Легенда: А-анализ, Д-демонстрация, Т-тест, И-инспекция.
Для испытаний сложной техники широко применяют наземные стенды систем и компонентов, в том числе прочностные, где проводят статические и ресурсные испытания. Статические испытания определяют способность конструкции выдерживать высокие однократные нагрузки. Ресурсные испытания позволяют спрогнозировать поведение конструкции при повторяющихся нагрузках, характерных для типовой эксплуатации. В авиации, например, используют стенды для специальных испытаний, где проводят климатические тесты, а также испытания на внешние воздействия (попадание птиц, молниестойкость, пожаростойкость и др.). Полный набор базовых требований к испытаниям компонентов авиационной техники изложен в стандарте КТ-160 (DO-160G) «Условия окружающей среды и процедуры испытаний для бортового авиационного оборудования», содержащем 26 разделов. При работах по указанному стандарту используемые стенды должны быть предварительно сертифицированы на соответствие этим требованиям.
В общей сложности на этапе разработки нового гражданского самолета применяют от 20 до 50 наземных стендов в зависимости от уровня сложности решаемых технических задач. Поэтому следует стремиться замещать результатами виртуального моделирования поведения аэрокосмической, автомобильной, атомной и другой сложной техники значительную часть дорогостоящих наземных, летных и специальных испытаний.
Сложные динамические модели и виртуальное моделирование широко используют для принятия критических решений в области проектирования, разработки, производства и эксплуатации, для проверки эксплуатационных и нерасчетных режимов работы системы. Обоснование достоверности получения доброкачественных результатов моделирования достигается путем:
1) обеспечения правильной постановки задач моделирования (например, пользователи не могут вводить в расчет параметры, выходящие за пределы заданного диапазона режимов);
2) разработки процессов верификации и валидации инструментов, сертификации расчетных моделей на основе эксплуатационных данных и типовых экспериментов;
3) разработки и идентификации отраслевых стандартов для документации, управления конфигурацией и обеспечения качества моделирования;
4) разработки стандартного метода оценки достоверности результатов моделирования, представляемого уполномоченному органу, принимающему решения.
Технический лидер отвечает за обеспечение достоверности результатов этих мероприятий по моделированию. В ряде случаев на практике можно сократить плановые сроки процессов тестирования. Для этого могут быть использованы:
a) легко проверяемые требования;
b) пошаговые руководства по планированию, проведению и обработке испытаний;
c) модели и виртуальное моделирование;
d) надежная конструкция для изменения параметров компонента, процесса изготовления;
e) стандартизация процессов и документов;
f) применение ускоренных эквивалентно-циклических испытаний;
g) доступность испытательного оборудования (стендов) и измерительных систем;
h) независимость компонентов системы;
i) эмулятор оборудования для непроверенного программного обеспечения;
j) проверенное программное обеспечение для непроверенного оборудования;
k) модульное, «восходящее» (снизу-вверх) тестирование;
l) готовый план испытаний и процедуры тестирования, контроль критического пути графика работ.
В качестве примера важности верификации в космической программе рассмотрим происшествие с аппаратом Genesis в 2004 г. Он был запущен NASA в 2001 г. для сбора и анализа заряженных частиц, выдуваемых из короны Солнца (солнечного ветра). По плану возвращения на Землю, после входа в атмосферу капсула должна была выпустить первичный парашют, который бы замедлил и стабилизировал падение. Затем должен был раскрыться основной парашют для совершения мягкой посадки. Оба парашюта не сработали при приземлении, аппарат разбился о землю на скорости 350 км/час. Два разных комплекта контрольных датчиков (срабатывавших по величине ускорения торможения и по росту температуры) были включены наоборот (сравнительно со спецификациями). После работы аварийной комиссии выявлены причины происшествия:
1) схема использования датчиков для выпуска парашютов скопирована с предыдущей успешной модели;
2) верификационные требования расплывчаты, наземный тест срабатывания на центрифуге не затребован;
3) конструктор проверил срабатывание датчиков (открыто-закрыто), при этом не была проведена верификация ориентации датчиков;
4) электрик-монтажник некорректно провел верификацию ориентации по чертежу;
5) проверяющие вынесли решение, что проект системы выполнен правильно, так как скопирован с удачного аналога;
6) инженер, готовивший аппарат к полету, не замкнул обратную связь с проектантом, т.к. не потребовал обсудить результаты испытаний.
В результате аварии виновными признаны конструктор (не проведен обзор проекта) и испытатель (не выполнена верификация системы выпуска из-за копирования предыдущего решения).
2.8. Риски и возможности
Неопределенности при реализации больших, дорогостоящих программ в области высоких технологий могут существенно повлиять на успешность и себестоимость создаваемых изделий и систем. Поэтому управление рисками (в первую очередь техническими) является одной из основных задач реализации системно-инженерной методологии на проектах. Напомним определения риска.
•Риском называют будущее событие с реальной вероятностью, которое оказывает негативное воздействие на безопасность или технические характеристики проекта, стоимость или график.
• Риск включает сочетание вероятности и последствий наступления неблагоприятных событий (вероятность выхода опасного фактора из-под контроля и серьезность последствий, выражаемая степенью проявления).
• Возможностью называют будущее событие, возникающее с реалистичной вероятностью, которое может оказать положительное влияние на достижение результатов проекта.
Риск характеризуется тремя основными компонентами:
a) воздействие или сценарий, приводящий к ухудшению эффективности в отношении одного или нескольких показателей эффективности (например, разрушению основных активов, превышению пределов массы, перерасходу средств; смещению графика проекта);
b) вероятность каждого из этих сценариев;
c) последствия (качественная или количественная степень ухудшения характеристик), которые могли бы возникнуть при реализации сценария.
Недостаток достижимых характеристик проекта системы может быть связан с любым одним или несколькими разделами требований (список не ограничивается).
1. Риск затрат связан с возможностью реализации программы или проекта для достижения целей его жизненного цикла и обеспечения надлежащего финансирования. Включает риск того, что сметы расходов и цели не являются точными и разумными; и риск того, что выполнение программы не будет соответствовать целям в результате проблем с затратами, графиком и рисками эффективности.
2. Риск расписания (графика проекта) связан с адекватностью времени, оцененного и выделенного для разработки, производства, внедрения и эксплуатации системы. Включает риск, что выполнение программы не соответствует срокам расписания в результате проблем на проекте.
3. Технический риск связан с эволюцией дизайна и производства, влияющей на уровень характеристик, необходимый для удовлетворения ожиданий заинтересованных сторон и технических требований. Возможна вероятность неудачи проекта вследствие отрицательных результатов НИР или в результате недостижения запланированных технических параметров в ходе выполнения ОКР.
4. Программный риск связан с действием или бездействием извне проекта, над которым менеджер не имеет контроля, но который может оказать значительное влияние на проект. Эти воздействия могут проявляться в терминах технических, стоимостных или влияния на график, например, санкционные риски в отношении участников программы.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=71515627?lfrom=390579938) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Виктор Николенко
Тип: электронная книга
Жанр: Просто о бизнесе
Язык: на русском языке
Издательство: Издательские решения
Дата публикации: 09.01.2025
Отзывы: Пока нет Добавить отзыв
О книге: В книге впервые в отечественной литературе кратко изложены принципы и методы управленческого компонента системной инженерии при создании высокотехнологичной продукции различного назначения.Включены практические сведения по разработке систем ГК «Ростех», «Роскосмос», «Газпром», «Росатом», для городской инфраструктуры, здравоохранения, транспорта и др.Книга рекомендуется в качестве важного дополнения к курсам управления проектами и будет полезна для всех специалистов и менеджеров по теме.