Критические вопросы теории и практики систем - К. Эллис

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

СИСТЕМЫ И СИСТЕМНАЯ ИНЖЕНЕРИЯ

Революция "систем" наступает. С годами постоянно меняющаяся промышленная и инженерная среда показывает, что то, что работало раньше, теперь просто не работает; сложность - это порядок дня. Системная инженерия - это рациональный подход к принятию решений, связанных с решением сложных задач в области инженерного планирования, проектирования. Развивающаяся дисциплина "системная инженерия" является естественным преемником таких дисциплин, как физика, инженерия, биология и т.д., поскольку она стоит выше этих традиционных дисциплин, стремясь создать зонтик и установить всеобъемлющий и универсальный набор принципов. Как представляется (Hitchins, 1992; Checkland, 1981), существует два вида систем, "жесткие" и "мягкие", а также два вида "системной инженерии" с различными мнениями и процессами мышления, которые привели к фундаментальному разрыву в мышлении и подходах.

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

СИСТЕМНАЯ ИНЖЕНЕРИЯ И СИСТЕМОТЕХНИКА

Утверждается (Boarder, 1995(b)), что необходимо устранить путаницу, заложенную в термине "системы". Многочисленные толкования терминов "системная инженерия", "системотехника", даже "системная инженерия" и "управление системной инженерией" должны быть разделены. Эти термины следует рассматривать в контексте, как это сделал Lacy (1992), и давать им последовательные определения. В противном случае требуется новая терминология. В любом случае, уменьшив сложность "системной инженерии" и поместив ее части в соответствующий контекст, мы сможем найти способы уменьшения сложности систем.

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

СТРУКТУРА СИСТЕМНОГО ПРОЕКТИРОВАНИЯ

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

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

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

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

- При системной инженерии фреймворк фиксирует действия и их ход для последующего анализа.

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

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

КОНТЕКСТ

Определение системы, данное Чеклендом (Checkland, 1981), - это модель целого относительно наблюдателя, характеризующаяся иерархией, эмерджентностью, связью и управлением. Эмерджентные свойства систем - это свойства, имеющие смысл только тогда, когда они приписываются целому, а не его частям. Хитчинс (Hitchins, 1992) хорошо излагает концепцию эмерджентных свойств в контексте системной инженерии, заявляя:

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

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

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

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

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

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

FRAMEWORK

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

Эта структура была частично использована в проекте руководства lEE "Практика системной инженерии" (Hitchins, Boarder and Moore, 1992), который в настоящее время тщательно пересматривается из-за его несостоятельности в качестве основы для обучения и тренинга.

Структура существует на трех уровнях определения.

Рамки первого уровня

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