Системная инженерия на раз-два

Виктор Николенко

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

Раздел I.

Основные понятия системной инженерии

1.1 Системы, которые нас окружают

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

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

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

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

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

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

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

• реализация способов эффективного хранения энергии;

• применение беспилотных авиационных систем;

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

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

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

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

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

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

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

• Существенно увеличился объем сведений для усвоения.

• Необходимо сократить сроки обучения и подготовки специалистов.

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

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

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

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

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

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

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

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

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

Среди искусственных систем можно выделить несколько типов.

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

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

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

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

Пример иерархии систем по возрастанию уровня сложности.

Двигатель самолета по сравнению с набором входящих деталей.

Самолет с двигателями и навигационной системой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2. Определения жизненного цикла

и системной инженерии

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

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

Далее потребуются еще два определения из стандарта ГОСТ 56136—2014.

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

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

Основными этапами ЖЦ являются:

• Концепция: выявление и определение потребностей системы. Сюда входит анализ заинтересованных сторон и определение критериев проверки потребностей.

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

• Производство: на этапе создается собственно система. Проводятся различные испытания, чтобы убедиться, что система построена правильно.

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

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

• Вывод из эксплуатации: реализация плана, как и когда система должна быть выведена из эксплуатации, и утилизирована безопасным и надежным образом.

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

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

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

Согласно стандарту ГОСТ Р 57193—2016 на очередном контрольном рубеже ЖЦ должны быть выполнены главные задачи проекта на предыдущей стадии:

• обоснованы гарантии, что процесс разработки приведет к удовлетворительной верификации и валидации продукта;

• обеспечена приемлемость риска перехода на следующую стадию.

Успешная разработка системы будет зависеть от технологий, которые используются на протяжении жизненного цикла системы. В случаях, когда система имеет длительные стадии эксплуатации и обслуживания, важно учитывать жизненный цикл примененных технологий. Требуется, чтобы используемая технология оставалась доступной в течение всего жизненного цикла продукта, даже если она устареет. Это важно, например, для информационных технологий, где версии программных продуктов обновляются каждые 5—10 лет. Другим примером являются музыкальные носители. В 1960-х годах это были грампластинки, в 1980-х на смену пришли кассеты. В 1990-х годах их вытеснили компакт-диски, в 2000-х появились телефоны и карманные плееры с внутренней твердотельной памятью, и т. д.

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

Базовый для нашей книги термин некоммерческая международная организация сиcтемных инженеров INCOSE формулирует следующим образом (2018).

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

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

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

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

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

Системная инженерия помогает ликвидировать пробелы, имеющиеся в традиционных подходах к разработке систем, по трем указанным составляющим: технической, управленческой, организационной. Практические вопросы применения системного подхода для успешного выполнения высокотехнологичных проектов и программ, к сожалению, недооценены или отсутствуют в отечественной литературе. Во-первых, потому что среднее поколение успело забыть дисциплину, массово преподававшуюся много лет в ВУЗах СССР под названием «Системотехника». Во время реформы ВУЗов в РФ данная тема выпала, тогда как за рубежом системотехника стала активно развиваться в различных отраслях. Во-вторых, сказалось, что многим людям некомфортно изучать многочисленные новые дисциплины и подходы. В-третьих, потому что различные теоретики, системологи и онтологи, в том числе в INCOSE, сумели надежно отпугнуть отряды любознательных практиков накрученной сложностью и «избранностью» знаний по системной инженерии. Сегодня обучение системной инженерии проводят только в десяти ВУЗах РФ.

Важнейшей основой системной инженерии являются официальные международные стандарты, излагающие правила работы. Сегодня применение стандартов системной инженерии обязательно для контрактов военных ведомств развитых стран и государственных заказчиков сложных систем, таких как Министерство обороны США (DoD), Национальная аэрокосмическая ассоциация (NASA), компаний Boeing, Airbus, гигантов в сфере телекоммуникаций и информационных технологий (Siemens, IBM), и др. Основные стандарты системной инженерии РФ перечислены в разделе 1.10.

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

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

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

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

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

• Заметно снижаются потери рабочего времени в проекте.

• Возрастает качество работ и получаемых результатов.

• Рост производительности труда после периода обучения составляет от 20 до 100%, далее обеспечивается стабильный прирост не менее 15—25% в год.

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

1.3 Основные этапы системно-инженерного подхода

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

— Удовлетворить желания клиентов в отношении новых продуктов и услуг.

— Улучшить экономику компании в долгосрочной перспективе.

— Научиться быстро реагировать на изменения на рынке.

— Стремиться стать признанным лидером в своей отрасли.

— Улучшить бизнес-модель, стратегию и процессы организации.

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

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

• Чистая энергетика (водород и возобновляемые виды энергетики).

• Новая атомная энергетика, в том числе малые атомные реакторы для удаленных территорий.

• Развитие производств новых материалов.

• Круглогодичный Северный морской путь.

• Беспилотные логистические коридоры для транспорта.

• Автономное судовождение.

• Беспилотная аэродоставка грузов.

• Персональные медицинские помощники.

• Электроавтомобиль и водородный автомобиль.

• Цифровая экосистема «Одно окно» экспортера.

• Платформа университетского технологического предпринимательства.

• Взлет — от стартапа до размещения акций на бирже.

• Передовые инженерные школы.

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

Уточним основные понятия системы и их роли.

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

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

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

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

Управление жизненным циклом системы включает все действия для выполнения программы или проекта в различных фазах, разделенных точками принятия ключевых решений или контрольными рубежами (КР). В стандарте «Процессы жизненного цикла систем» ISO 15288:2015 (ГОСТ Р 57193—2016) перечислены 30 базовых процессов жизненного цикла систем, рис. 2.

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

Указанные процессы разделены на четыре основные группы.

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

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

• Группа организационных процессов, объединяет бизнес-процессы в целом, управление предприятием, инвестициями и процессы управления жизненным циклом системы.

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

Для описания инструментов системной инженерии в последующем тексте будут использоваться еще несколько терминов.

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

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

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

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

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

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

Рис. 3. Блок-схема типового процесса

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

Основными задачами управления жизненным циклом являются:

1. Управление процессом проектирования и разработки системы.

2. Управление процессом технологической подготовки производства.

3. Управление процессом производства продукции.

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

5. Управление процессом испытаний системы, ресурсных, приемо-сдаточных, сертификационных, и др.

6. Управление процессом послепродажного обслуживания.

7. Управление процессами обучения пользователей и обслуживающего персонала.

8. Обеспечение качества на всех этапах ЖЦ.

9. Достижение заданной трудоемкости разработки и изготовления системы.

10. Управление информационной поддержкой всех процессов.

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

Для реализации проектов и программ в системной инженерии широко используется принцип декомпозиции:

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

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

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

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

Можно выделить 12 последовательных этапов системно-инженерного процесса создания системы или продукта:

1. Маркетинговая оптимизация — информация по принятию решений на основе анализа и отбора наиболее сбалансированных решений по требованиям рынка.

2. Комплексное техническое планирование — формирование планов процессов и продуктов.

3. Управление требованиями — определение и управление требованиями, которые описывают желаемые характеристики системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Детальное описание особенностей реализации процесса разработки систем можно найти в представленном в конце книги рекомендательном списке литературы [2,3,8,9]. Далее будут представлены некоторые особенности этапов разработки системы.

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

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

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

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

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

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

Есть несколько причин, зачем нужны требования:

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

• Требования определяют, что система должна делать, и управляют ее развитием.

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

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

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

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

Концепция эксплуатации должна ответить на ряд вопросов пользователя.

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

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

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

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

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

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

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

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

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

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

Требования являются ключом к успеху проекта. Хорошие требования к системе или продукту должны быть:

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

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

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

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

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

Для сбора потенциальных требований можно использовать разные источники.

1. Интервью с пользователями для уточнения дизайна продукта и улучшения качества.

2. Опрос и анкетирование, которые широко используются в социальных исследованиях и анализе рынка.

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

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

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

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

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

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

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

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

— Политика и публичные законы, которые вносят ограничения по безопасности, экологии и шуму.

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

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

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

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

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

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

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

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

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

Написание хороших требований требует инженерных знаний системы, навыков общения с людьми и, прежде всего, способности мыслить критически и творчески. Сначала требование выражают в качественной форме. Например, «Автомобиль должен иметь возможность двигаться в прямом направлении и задним ходом, а направление движения должно выбираться водителем». Далее добавляют количественные оценки. Например, «Автомобиль должен проезжать в среднем 150 км с заправкой десяти литров топлива при следующих условиях: X, Y и Z» или «Уровень шума внутри автомобиля не должен превышать 55 децибел на скорости ниже 120 км в час, при движении по стандартному асфальтовому покрытию». Качественные и количественные требования заносят в документ, называемый техническим заданием (ТЗ). Выполнение требований, указанных в ТЗ, является обязательным для результата проекта.

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

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

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

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

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

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

На стадии концептуального проектирования основные действия по проектированию включают:

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

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

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

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

• документирование исходной функциональной базовой версии системы;

• проведение обзора концептуального дизайна.

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

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

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

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

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

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

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

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

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

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

1. структура требований к системе;

2. функциональная структура конструкций, технологических систем и компонентов;

3. геометрическая структура (например, в каком отсеке изделия, на каком уровне находится оборудование);

4. структура разбиения работ проекта (см. раздел 2.2);

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

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

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

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

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

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

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

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

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

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

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

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

Приведем пример формирования технических требований для разработчика на базе требований верхнего уровня системы. В пожеланиях клиента указано, что легковой автомобиль должен иметь систему климат-контроля. Чтобы пассажиры чувствовали себя комфортно в салоне автомобиля, система должна обеспечивать температуру внутри салона в пределах 20—29° C, когда температура наружного воздуха составляет от — 20° C зимой до +45° C летом.

Систему управления климатом декомпозируют на группы подсистем:

• отопления, включающую теплообменник горячего воздуха, воздуходувку, регулятор скорости вентилятора, термостат и систему подачи горячего воздуха;

• подачи холодного воздуха, включающую теплообменник холодного воздуха, воздуходувку, регулятор скорости вентилятора, термостат и систему подачи хладагента;

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

Далее формируют требования для подсистем системы климат-контроля:

1. теплообменников горячего и холодного воздуха;

2. нагнетателя воздуха с регулируемой скоростью вентилятора;

3. трассы подачи горячей воды из системы охлаждения двигателя;

4. подачи хладагента от насоса кондиционера;

5. термостата;

6. системы воздуховодов и трубок для воздушных и жидкостных потоков;

7. электрической системы питания компонентов.

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

Для реализации сформулированных требований при разработке новой системы или продукта важно, чтобы проектное решение соответствовало сегодняшним возможностям организации. Вводится понятие зрелости технологии как меры готовности запуска нового продукта для конкретного технического решения. По существу, зрелость технологии также является мерой риска, ассоциированного с конкретным проектом. Уровень зрелости технологии связан с часто используемым уровнем технической зрелости производства нового продукта. Основной целью использования уровней технологической готовности является помощь управленческому персоналу в принятии решений, касающихся перехода на следующие стадии развития инфраструктуры компании или использования технологии. Расшифровки уровней зрелости технологий приведены в ГОСТ Р 58048—2017 «Трансфер технологий. Методические указания по оценке уровня зрелости технологий».

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

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

1.5 Функциональный анализ и синтез системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.