Виктор Николенко - Системная инженерия на раз-два
- Название:Системная инженерия на раз-два
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:9785005655424
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Виктор Николенко - Системная инженерия на раз-два краткое содержание
Системная инженерия на раз-два - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Архитектура системы – это структура компонентов, их отношений, а также принципов и руководств, регулирующих их проектирование и развитие во времени (определение компании Boeing).
Системная архитектура отражает утвержденные системные требования. Она содержит наиболее важные стратегические реализационные решения, изобретения, инженерные компромиссы. В процессе разработки архитектуры формируется набор представлений, как система будет удовлетворять системным требованиям, все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Архитектура может включать функции системы, характеристики, технологию, оценку стоимости, риски, ограничения, границы системы и так далее. Перечень функций затрагивает используемые в эксплуатации входные и выходные данные, сценарии использования, циклические процессы, функциональные требования, приоритеты. Поведение компонентов является частью архитектурного описания.
Архитектура не является единой структурой. Она определяет основные части системы и то, как эти части будут взаимодействовать друг с другом, чтобы удовлетворить общие системные требования. Определения архитектуры не уточняют, что представляют собой компоненты. При формировании архитектуры можно использовать диаграммы, наброски, рисунки, таблицы, и другие наглядные материалы для выражения пожеланий будущих пользователей. Например, в одном из стандартов имеется более 50 разделов по типам описаний архитектуры.
Процесс функционального проектирования заключается в определении элементов и разработке функциональной архитектуры. Идентификация функциональных элементов осуществляется путем анализа технических требований. Затем требования к характеристикам системы должны быть распределены по функциям. Нужно установить и оценить несколько вариантов функциональных архитектур, и выбрать одну. Оценка различных альтернативных архитектур в сравнении по нескольким параметрам (качество, стоимость, время, производительность, риски, и т.д.) приводит к выбору компромиссного решения для дальнейшей разработки. В ряде случаев этот шаг подменяют традиционным решением из «запасников».
После определения функциональной архитектуры системы целью процесса физического проектирования является разработка различных архитектур для поддержки этих функций. Разработка физической архитектуры включает логические модели физического решения. Эти представления могут состоять из концептуальных проектных чертежей и блок-схем, которые определяют форму и расположение компонентов системы, и связанных интерфейсов. Основные действия, выполняемые при разработке физической архитектуры и дизайна, включают анализ и синтез вариантов, идентификацию и определение физических интерфейсов и компонентов, критических атрибутов, включая проектный бюджет (например, вес, надежность), анализ ограничительных требований. Усилия на этом этапе сосредоточены на определении классов компонентов, установлении параметров и выборе критериев для присвоения элементов функциональной архитектуры физическим компонентам. Проводится сравнение нескольких возможных физических архитектур, чтобы оценить их осуществимость. Далее остается выбрать финальную архитектуру, определить окончательное проектное решение, проверить и обосновать его. Разработка физической архитектуры является итеративным процессом. Он завершается, когда система декомпозирована до самого нижнего уровня системных элементов или элементов конфигурации. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры».
Процесс разработки верхнего уровня архитектуры системы показан на рис. 5. Процесс движется из верхнего левого угла по часовой стрелке. Этапы на схеме пронумерованы.

В этом процессе важно идентифицировать производные требования и гарантировать, что они отслеживаются и являются частью общего набора требований. Рассматривают существующие технологии для удовлетворения требований пользователей.
Примерами рассматриваемых и фиксируемых целей в терминах стандарта архитектуры являются функциональность, выполнимость, применимость, предназначение и характеристики системы, известные ограничения, структура, поведение, функционирование, надежность, безопасность, информационное обеспечение, сложность, открытость, автономность, стоимость, график, динамичность, модульность. Архитектура определяет управление, изменение состояния, интеграцию подсистем, доступность данных, соответствие требованиям регуляторов, гарантии, деловые цели и стратегии, опыт заказчика, сопровождаемость, и утилизируемость системы.
После того, как архитектура системы сформирована, выполняют декомпозицию структуры системы или изделия. Структура системы связана с пятью другими ключевыми структурами:
1. структура требований к системе;
2. функциональная структура конструкций, технологических систем и компонентов;
3. геометрическая структура (например, в каком отсеке изделия, на каком уровне находится оборудование);
4. структура разбиения работ проекта (см. раздел 2.2);
5. организационная структура задействованных при реализации предприятий.
Далее необходимо дополнить и распределить требования верхнего уровня на всю структуру системы для каждого компонента. Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям:
• Требования к системе, где собраны требования к продукции, и ее характеристикам.
• Промышленные, производственные и испытательные требования.
• Требования к обеспечивающим процессам, включая применяемые процессы, управление проектом, качество и требования к закупкам.
Затем инженерные группы передают документы требований верхнего уровня исполнителям рабочих пакетов и поставщикам, для декомпозиции по компонентам и подсистемам. На основе архитектурных связей формулируются производные требования, необходимые для выполнения требований верхнего уровня.
Требования декомпозируют тремя способами: по потоку, распределением и ответвлениями. Декомпозиция требований вниз по потоку представляет прямую передачу их в подсистемы, для обеспечения характеристик системы в целом. Распределение включает количественный пропорциональный дележ требований верхнего уровня на компоненты нижнего уровня. Ответвление требований создает пропорциональную характеристику, зависящую от специфической реализации.
Читать дальшеИнтервал:
Закладка: