Что такое инженерия информационных систем
Информационная инженерия
СОВРЕМЕННЫЕ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ.
На современном этапе развития существуют два подхода к проектированию и построению приложений: методология структурного анализа и методология объектно-ориентированного подхода.
Одной из структурных методологий, основанных на информационно-ориентированном подходе, является информационная инженерия.
Информационная инженерия вращается вокруг двух основных концепций.
1. Послойный целостный подход к разработке интегрированных приложений, базирующийся на стратегическом планировании информационных систем.
Для организаций, разрабатывающих целый ряд приложений за определенный период, бывает затруднительно приспособить их все к совместной работе. Клиенты недовольны, когда им приходится несколько раз запрашивать одну и ту же информацию в разных отделах одной организации. Служащие нуждаются в информации от всех частей организации для ответа на вопросы и решения проблем. Программистам надоедает писать одни и те же коды вновь и вновь, когда существующие функции оказываются очень похожими. Все эти примеры указывают на необходимость интеграции приложений.
Таким образом, ядром информационной инженерии является обоснованный набор шагов для планирования и построения по методу сверху вниз. Информационная инженерия также предписывает набор моделей и стратегий проектирования для моделирования приложений.
Информационная инженерия
СОВРЕМЕННЫЕ МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ПРИЛОЖЕНИЙ.
На современном этапе развития существуют два подхода к проектированию и построению приложений: методология структурного анализа и методология объектно-ориентированного подхода.
Одной из структурных методологий, основанных на информационно-ориентированном подходе, является информационная инженерия.
Информационная инженерия вращается вокруг двух основных концепций.
1. Послойный целостный подход к разработке интегрированных приложений, базирующийся на стратегическом планировании информационных систем.
Для организаций, разрабатывающих целый ряд приложений за определенный период, бывает затруднительно приспособить их все к совместной работе. Клиенты недовольны, когда им приходится несколько раз запрашивать одну и ту же информацию в разных отделах одной организации. Служащие нуждаются в информации от всех частей организации для ответа на вопросы и решения проблем. Программистам надоедает писать одни и те же коды вновь и вновь, когда существующие функции оказываются очень похожими. Все эти примеры указывают на необходимость интеграции приложений.
Таким образом, ядром информационной инженерии является обоснованный набор шагов для планирования и построения по методу сверху вниз. Информационная инженерия также предписывает набор моделей и стратегий проектирования для моделирования приложений.
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
Системная инженерия программного обеспечения: введение
Применение принципов системной инженерии к созданию крупных, сложных программных систем дает мощный инструментарий управления процессами разработки и изделиями.
Программные системы становятся все больше и сложнее. Классический пример — Microsoft Word, который 20 лет назад умещался на дискете на 360 Кбайт, а теперь для него необходим компакт-диск емкостью 600 Мбайт.
Но есть и другие причины. Программное обеспечение становится ключевым компонентом во многих, если не в большинстве технических систем. Зачастую оно обеспечивает тот уровень интеграции и управления данными, который позволяет сложной системе решать стоящие перед ним задачи.
Реализация подавляющего большинства крупных программных систем не укладывается в запланированные сроки, выходит за рамки сметы, и при этом не вполне оправдывает ожидания заказчика. Этот феномен хорошо известен как «кризис программного обеспечения» [1]. Чтобы разрешить этот кризис, разработчики программного обеспечения используют при создании продуктов различные инженерные методики.
Простой контроль управленческого и технического состояния проекта — использование ресурсов, выполнение этапов, соответствие требованиям, прохождение тестов — не дает адекватного представления о его «здоровье». На самом деле, необходимо управлять процессами и продуктами, создаваемыми в их рамках. Системная инженерия предоставляет инструментарий, требуемый для решения задачи технического управления.
Применение принципов системной инженерии к разработке программной системы выявляет операции, задачи и процедуры, называемые системной инженерией программного обеспечения: (software system engineering — SwSE). Многие считают SwSE специфичным случаем системной инженерии, а другие относят ее к программной инженерии. Однако я могу утверждать, что SwSE — совсем иной мощный инструментарий, используемый для управления технической разработкой крупных программных проектов.
В этой статье определения и процессы из стандартов IEEE на программную инженерию [2] интегрируются в процесс SwSE. Более подробное изложение этого материала, включая детальное пошаговое описание развертывания SwSE, содержится в [3].
Системы и системная инженерия
Системная инженерия — это практическое применение научных, инженерных и управленческих навыков, необходимых для преобразования операционных требований в описание конфигурации системы, которая наилучшим образом удовлетворяет этим требованиям. Это общий процесс решения проблем, который применяется ко всему техническому управлению в проекте, посвященном разработке системы, предоставляя механизм формулирования и совершенствования определений изделий и процессов системы.
Стандарт IEEE Std. 1220-1998 описывает процесс системной инженерии и ее применение на протяжении всего цикла жизни изделия [4]. Системная инженерия порождает документы, а не оборудование. Документы связывают процессы разработки с циклом жизни проекта. Они определяют предполагаемые окружения процессов, интерфейсы и инструменты управления рисками в рамках всего проекта.
Системная инженерия включает в себя пять функций.
Системная инженерия формирует основу всего хода проекта разработки, а также механизм определения пространства решений в терминах систем и интерфейсов с внешними системами. Пространство решений описывает изделие на самом высоком уровне, прежде чем требования к нему будут разделены на аппаратную и программную составляющую.
Этот подход аналогичен присущей программной инженерии практике — накладывать ограничения как можно позже в процессе разработки. Чем позже на проект будут наложены ограничения, тем более гибким будет реализованное решение.
Что такое системная инженерия ПО?
Термин «системная инженерия программного обеспечения» появился в начале 80-х годов, и его приписывают Уинстону Ройсу [5]. SwSE отвечает за общее техническое управление системой и подтверждение корректности окончательных системных продуктов. Как и системная инженерия, SwSE порождает документы, а не компоненты. В этом она отличается от программной инженерии (software engineering — SwE), порождающей компьютерные программы и руководства пользователей.
SwSE начинается, когда системные требования разделены на аппаратные и программные подсистемы. SwSE формирует основу для всей разработки программного обеспечения в проекте и, как и SwE, представляет собой одновременно и технический и управленческий процесс. Технический процесс SwSE — аналитическая работа, необходимая для преобразования операционных требований в:
SwSE не является описанием работ. Это процесс, который выполняют многие люди и организации: системные инженеры, менеджеры, программные инженеры, программисты и, не стоит забывать пользователи.
По мере того как крупные системы все больше зависят от программ, применение методов системной инженерии к разработке программного обеспечения в состоянии помочь избежать существенных проблем.
Впрочем, разработчики программного обеспечения часто игнорируют эти методы. Они считают, что чисто программные системы или системы, работающие на массовых компьютерах, — всего лишь программные, а не системные проекты. Игнорирование системных аспектов разработки программного обеспечения и ведет к кризису.
SwSE и программная инженерия
И SwSE, и SwE — это технические и управленческие процессы, однако SwE порождает программные компоненты и описывающую их документацию. Более строго, программная инженерия включает в себя следующее.
Рис. 1 иллюстрирует связи между системной инженерией, SwSE и SwE. Традиционная системная инженерия выполняет первоначальный анализ и проектирование, а также интеграцию и тестирование окончательной системы.
Рис. 1. Инженерные связи между системной инженерией, системной инженерией программного обеспечения (SwSE) и программной инженерией
Во время первой стадии разработки SwSE отвечает за анализ требований к программному обеспечению и архитектурный дизайн. SwSE также управляет окончательным тестированием программных систем. Наконец, SwE управляет тем, что системные инженеры называют инженерией компонентов.
SwSE и управление проектом
Процесс управления проектом включает в себя оценку рисков и затрат на создание программной системы, определение графика выполнения, объединение различных специалистов и инженерных групп, конфигурационное управление и постоянный аудит, позволяющий гарантировать, что проект укладывается в сроки и смету и соответствует техническим требованиям [6].
 |
| Рис. 2. Управленческие связи между системной инженерией программного обеспечения, программной инженерией и проектным менеджментом |
Рис. 2 иллюстрирует управленческие связи между проектным менеджментом, SwSE и SwE. Руководство проектом включает в себя общее управление распределением работ в проекте и полномочия предоставления ресурсов. SwSE определяет технический подход, принимает технические решения, взаимодействует с техническими представителями заказчика, а также одобряет и принимает конечный программный продукт. SwE отвечает за разработку программного дизайна, кодирование и разработку программных компонентов.
Функции SwSE
В таблице 1 перечислены пять основных функций системной инженерии, коррелирующих с SwSE; дано краткое описание функций SwSE.
Таблица 1. Функции системной инженерии, коррелирующие с системной инженерией ПО
Анализ требований
Первый шаг в любой активности, связанной с разработкой программного обеспечения, — определение и документирование требований системного уровня в виде спецификации системных требований или в виде спецификации программных требований. Программные требования включают в себя свойства, которые необходимы пользователю для решения тех или иных задач, а также свойства, которые нужны системе или компоненту для выполнения тех или иных формально представленных документов [7].
Программные требования можно классифицировать следующим образом [8].
Анализ программных требований начинается после того, как системная инженерия определила системные требования заказчика. В его функции входят указание всех (или максимального числа) требований к программной системе, и завершение анализа означает формирование утвержденных базовых требований [2].
Дизайн программного обеспечения
Дизайн программного обеспечения — это процесс выбора и документирования наиболее эффективных элементов, которые в совокупности будут реализовать требования к программной системе [9]. Дизайн определяет специфический, логический подход к удовлетворению программных требований.
Дизайн программного обеспечения традиционно разделяется на две части.
Предложенная в статье методология архитектурный дизайн относит к SwSE, а детальный дизайн — к SwE.
Планирование процессов
Планирование специфицирует цели и назначение проекта, а также стратегии, политику, планы и процедуры, позволяющие их добиться. Оно заранее определяет, что делать, как делать, когда делать и кто это будет делать.
Существует ошибочное предположение, что проектный менеджмент выполняет все действия по планированию проекта. На самом же деле, планирование проекта состоит из двух составляющих — одна относится к проектному менеджменту, а другая — к SwSE, причем основная часть выполняется именно в рамках SwSE. (Это вовсе не означает, что менеджеры проекта не могут выполнять обе функции.)
В таблице 2 показан пример разделения функций планирования для проекта программной системы.
Таблица 2. Планирование процессов и планирование проекта
Контроль процессов
Контроль — совокупность операций управления, используемых для того, чтобы гарантировать развитие проекта в соответствии с утвержденным планом. Контроль процессов предусматривает определение производительности и результатов в соответствии с планами, выявление отклонений и выполнение корректирующих действий, призванных гарантировать соответствие фактических результатов планам.
Контроль процессов — система обратной связи, необходимая для того, чтобы определить, как движется проект. Контроль процессов предполагает ответы на следующие вопросы. Есть ли потенциальные проблемы, способные привести к задержке с выполнением конкретного требования в указанные сроки и в рамках имеющегося бюджета? Есть ли риск, что такие проблемы станут реальными? Выполним ли подход к проектированию?
Контроль должен порождать корректирующие действия — либо приводить состояние проекта в соответствие с планом, либо изменять план, либо прекращать проект. Контроль проекта также состоит из двух отдельных компонентов: контроль, который предусмотрен проектным менеджментом и контроль, который выполняется в рамках инженерии программных систем. В таблице 3 содержится пример разделения функций контроля для проекта программной системы.
Таблица 3. Контроль процессов и контроль проекта
Верификация, подтверждение и тестирование
Процесс верификации, подтверждения и тестирования (verification, validation and testing — VV&T) определяет, корректен ли процесс инженерии, и соответствуют ли продукты предъявляемым требованиям [10].
VV&T — это непрерывный процесс мониторинга операций системной инженерии, SwSE, SwE и проектного менеджмента с целью убедиться, что они следуют техническим и управленческим планам, спецификациям, стандартам и процедурам. Кроме того, VV&T оценивает промежуточные и окончательные продукты проекта SwE. Промежуточные продукты включают в себя спецификации требований, описание архитектуры, планы тестирования и оценку результатов. К окончательным продуктам относятся программное обеспечение, руководства пользователей, учебные материалы и т.д.
SwSE использует методы и инструментарий VV&T для оценки требований спецификаций, описания архитектуры и других промежуточных продуктов. Тестирование выполняется для того, чтобы определить, соответствует ли окончательный продукт спецификациям требований данного проекта.
Финальный шаг в любой деятельности, связанной с разработкой программного обеспечения, — это подтверждение и тестирование окончательного программного продукта на соответствие спецификации программных требований, а также подтверждение и тестирование окончательного системного продукта на соответствие этой спецификации.
Системная инженерия и SwSE — дисциплины, используемые в первую очередь для технического планирования «на входе» жизненного цикла системы и для проверки того, что к окончанию проекта все планы были выполнены. К сожалению, в реальных проектах эти дисциплины часто игнорируются.
Игнорирование системных аспектов программного проекта может привести к созданию программного обеспечения, которое не будет работать на выбранной аппаратной платформе или не будет интегрироваться с другими программными системами.
1. W.W. Gibbs, «Software’s Chronic Crisis», Scientific Am., 1994, Sept.
2. IEEE, Software Engineering Standards Collection, vols. 1-4, IEEE Press, Piscataway, N.J., 1999
3. R.H. Thayer, «Software System Engineering: A Tutorial», Software Engineering Volume 1: The Development Process, 2nd ed., R.H. Thayer and M. Dorfman, eds., IEEE CS Press, Los Alamitos, Calif., 2002
4. IEEE Std. 1220-1998, Standard for Application and Management of the System Engineering Process, IEEE Press, Piscataway, N.J., 1998
5. W.W. Royce, «Software Systems Engineering», seminar presented as part of the course titled Management of Software Acquisition, Defense Systems Management College, Fort Belvoir, Va., 1981-1988
6. IEEE Std. 1058-1998, Standard for Software Project Management Plans, IEEE Press, Piscataway, N.J., 1998
7. IEEE Std. 610.12-1990, Standard Glossary of Software Engineering Terminology, IEEE Press, Piscataway, N.J., 1990
8. IEEE Std. 830-1998, Recommended Practice for Software Requirements Specifications, IEEE Press, Piscataway, N.J., 1998
9. IEEE Std. 1016-1998, Recommended Practice for Software Design Descriptions, IEEE Press, Piscataway, N.J., 1998
10. IEEE Std. 1012-1998, Standard for Software Verification and Validation, IEEE Press, Piscataway, N.J., 1998
Ричард Тэйер (r.thayer@computer.org) — почетный профессор программной инженерии Калифорнийского университета в Сакраменто, консультирует по программной инженерии и управлению проектами, ведет исследования и читает лекции в Университете Стречклайда (Глазго, Шотландия).
Richard H. Thayer. Software System Engineering: A Tutorial. IEEE Computer, April 2002. Copyright 2002, IEEE Computer Society. Translated and reprinted with permission.
Поделитесь материалом с коллегами и друзьями
Системная инженерия
Системная инженерия
Наиболее активно после биологии и менеджмента системный подход разрабатывался в системной инженерии(systems engineering). В русскоязычных переводах инженерной литературы менеджеры слово engineering не удосуживаются перевести как «инженерия», так и оставляют «инжинирингом». Перевод «системный инжиниринг» уже побеждает — это легко отследить по результатам сравнения в интернет-поисковых системах. Можно считать, что «системная инженерия» и «системный инжиниринг» синонимы, но есть маленькая проблема: в России почему-то в тех местах, где занимаются инженерным менеджментом, а не инженерией, называют его тоже «системным инжинирингом» — хотя при этом никаких инженерных (т.е. по изменению конструкции и характеристик системы) решений не принимается, речь идёт только об организации работ по созданию системы. Так что будем считать «инженерию» и «инжиниринг» синонимами, но в случае «инжиниринга» проверять на всякий случай, не менеджмент ли имеется в виду вместо инженерной работы (то есть занимаются ли в ходе «инжиниринга» изменением конструкции системы, или это делают в ходе какой-то другой «инженерии»).
Самое современное и одновременно устаревшее определение системной инженерии дано в Guide to the Systems Engineering Body of Knowledge (руководство по корпусу знаний системной инженерии). Короткое определение: системная инженерия — это междисциплинарный подход и способы обеспечения воплощения успешной системы (Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems). В этом определении можно подчеркнуть:
По-английски «системная инженерия» — systems engineering, хотя более ранние написания были как system engineering. Правильная интерпретация (и правильный перевод) — именно «системная» (подразумевающая использование системного подхода) инженерия, а не инженерия систем (engineering of systems) — когда любой «объект» обзывается «системой», но не используется системный подход во всей его полноте. Под инженерией систем (например, control systems engineering, manufacturing systems engineering) понимаются обычные инженерные специальности, там легко выкинуть слово «система», которое лишь обозначает некий «научный лоск». Предметные/прикладные (не системные) инженеры легко любой объект называют «системой», не задумываясь об осознанном использовании при этом системного мышления, не используя системный подход. В самом лучшем случае про систему предметные инженеры скажут, что «она состоит из взаимодействующих частей» — на этом обычно разговор про «систему» и «системность» заканчивается, он не длится больше двадцати секунд. Занимающиеся «инженерией систем» очень полезны и нужны, но они не системные инженеры.
А вот из системной инженерии квалификатор «системный» без изменения смысла понятия выкинуть нельзя. Неформально определяемая системная инженерия — это инженерия с системным мышлением в голове (а не любая инженерия, занимающаяся объектами, торжественно поименованными системами просто для добавления указания о сложности этих объектов и научности в их описании).
Целостность (полнота охвата всех частей целевой системы согласованным их целым, многоуровневое разбиение на части-целые), трансдисциплинарность (полнота охвата самых разных дисциплин системной инженерией) — это ключевое, что отличает системную инженерию от всех остальных инженерных дисциплин. Роль системного инженера отличают по тому, что человек в этой роли занимается всей системой в целом в разбиении на много уровней вниз и вверх от границы системы, а не только отдельными частями системы или только отдельными инженерными (теплотехника, электротехника) или менеджерскими (операционный менеджмент, лидерство) прикладными дисциплинами.
Более длинное определение системной инженерии включает ещё одну фразу: «Она фокусируется на целостном и одновременном/параллельном понимании потребностей проектных ролей; исследовании возможностей; документировании требований; и синтезировании, проверке, приёмке и постепенном появлении инженерных решений, в то время как в расчёт принимается полная проблема, от исследования концепции системы до вывода системы из эксплуатации» (Вторая фраза в определении системной инженерии из SEBoK: It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.)
Системная инженерия поначалу применялась главным образом для борьбы со сложностью аэрокосмических проектов, и она была там крайне эффективна. Для того, чтобы маленький проект уложился в срок и бюджет, нужно было на системную инженерию потратить 5% проекта, что предотвращало возможный рост затрат проекта на 18%. Для средних проектов на системную инженерию оптимально тратить было уже 20% усилий всего проекта, но если не тратить — возможный рост затрат проекта был бы 38%. Для крупных и очень крупных проектов оптимальные затраты на системную инженерию оказались 33% и 37% соответственно, и это для того, чтобы предотвратить возможный рост затрат проекта на всяческие переделки плохо продуманного 63% и 92% соответственно.
Как и можно ожидать, системная инженерия в простых небольших проектах почти не даёт эффекта (там всё хорошо продумывается «в уме» и не требует особых мыслительных практик), но оказывается ключевой в сложных и очень крупных проектах: без системного мышления в них допускаются ошибки, которые потом оказывается очень дорого переделывать. Без системного мышления сталкиваться со сложностью выйдет чуть ли не вдвое дороже за счёт дополнительной работы по переделкам допущенных ошибок.
Люди, которые выполняли в проектах роль системных инженеров, не прикладывали положения системного подхода к своей основной инженерной работе, а наоборот, к мыслительной базе системного мышления адаптировали все свои инженерные знания. Системные инженеры строили своё инженерное мышление на основе системного мышления.
В результате системным инженерам удалось выполнить сверхсложные проекты — например, они в 1969—1972 году отправили на орбиту вокруг Луны 24 космонавта, а по самой Луне пешком ходили 12 человек. Да что там пешком, рекорд скорости по Луне на луномобиле составил 18.6 км/час, при этом люди уезжали от ракеты на Луне на расстояние больше 7 километров! Достижения современной космонавтики, думаю, тоже не нужно рекламировать, даже с учётом того, что инженерное развитие в этой области было существенно искажено военными проектами, а инженеры развращены государственным финансированием. Но сложность космических проектов не позволяла добиваться успехов «обычной инженерией». Так, советская школа инженерии не смогла повторить достижений лунной программы, не смогла повторить многих и многих достижений планетарных программ, которых достигли в NASA. Конечно, у отечественной космонавтики есть и отдельные достижения (например, удачные ракетные двигатели), но при росте сложности проекта в целом неудачи начинают резко перевешивать достижения — типа четырёх неудач лунного старта Н-1.
Тут нужно отдельно оговорить, что всё это были достижения ещё первого поколения системного мышления, когда не обращали внимания на успешность системы как удовлетворения интересов самых разных проектных ролей. Космические программы имели астрономические бюджеты, и критиковались за то, что вместо помощи больным и голодным людям деньги выкидывались на удовлетворение каких-то политических амбиций (это было верно и для США, и для СССР, поэтому лунные старты и были прекращены на десятки лет!). В книге будет подраздел о том, почему государственные проекты не могут быть успешными по критериям самой системной инженерии.
Тем не менее, технический успех (работоспособность сложных технических систем, если не обращать внимания на цену, заплаченную налогоплательщиками за эту работоспособность) в аэрокосмических программах США был поразительным.
Метод работы западных аэрокосмических инженеров — именно системная инженерия, инженерия с использованием системного мышления. Системные инженеры (и отчасти программные инженеры) уточняли и развивали положения системного подхода, проверяя их действенность в сложных проектах, а самое важное из этих уточнённых и обновлённых положений попало в международные инженерные стандарты.
По иронии судьбы, стагнация системной инженерии от государственных и военных проектов наблюдается и прямо сейчас. Так, на международном симпозиуме INCOSE в 2020 году собралось много системных инженеров из военных и государственных проектов, и демонстрировались умеренные инженерные достижения. Но не было никаких докладов от SpaceX, хотя фронтир системной инженерии демонстрирует сегодня именно эта фирма. Системная инженерия перестала развиваться в ассоциации из по факту чиновников-инженеров, её развитие переместилось в реальные коммерческие проекты. Системное мышление развивается в таких проектах, как становящиеся автономными автомобили Tesla, инфраструктура быстрого космического интернета StarLink от SpaceX, суперкомпьютеры для искусственного интеллекта от NVIDIA и Google.
В отличие от многих и многих вариантов системного подхода, «системноинженерный вариант» в начале 21 века был проверен тысячами сверхсложных проектов, обсуждён десятками тысяч инженеров, унифицирован и доказал свою эффективность на деле. Он не имеет авторства (ибо в его создании участвовало множество людей), он не является «оригинальным исследованием», он не изобретает велосипеды в части самого системного подхода. Он просто отражает всё самое важное, что было накоплено системным движением за десятки лет и оказалось практичным и относительно легко применяемым на практике десятками тысяч людей.
Подробней про системную инженерию и её вариант системноинженерного мышления можно прочесть в учебнике «Системноинженерное мышление» 2015 года. Наша же книга посвящена версии системного мышления, универсальной для инженеров, менеджеров, предпринимателей, людей творческих профессий и остальных сфер деятельности.
Вдобавок к инженерам «железных» и программных систем, системным подходом и его стандартами заинтересовались инженеры и архитекторы предприятий (enterprise engineers и enterprise architects), они начали адаптировать применение системного подхода к задачам менеджмента, а потом и к задачам предпринимательства.
Решающим в выборе для нашего учебника именно этого (из стандартов системной инженерии) варианта системного подхода является его ориентация на человеческую деятельность, на изменение окружающего мира, а не просто на «понимание», «исследования», «анализ», «науку». Анализ-понимание полезен только в контексте последующего синтеза-созидания чего-то в нашем физическом мире, в контексте изменяющей физический мир к лучшему деятельности по созданию новых и модернизации уже имеющихся систем.
Наш учебник представляет тот вариант системного мышления, который изначально ориентирован на создание успешных систем (помним о специальном смысле слова «успешные»!) — будь это «железные» системы (самолёт, атомная электростанция), программные системы, биологические системы (клетки и организмы — ими занимается системная биология, генная инженерия), системы-предприятия (организационные системы), или даже такие нестандартные системы как танец или марафонский бег.
Источник: учебник А. Левенчука «Системное мышление 2020»