Ключевые концепции:

• Теория Систем
• Общая теория систем
• Система систем

Мы буквально чуть-чуть заглянем в эту область для того, чтобы ответить на вопрос: "Почему самолеты безопаснее автомобилей ?" (шутка ;-)).

На самом деле мы действительно получим ответ на этот вопрос, но лишь косвенно, как побочный эффект от изучения вопросов, что такое система.

Для этого мы будем рассматривать пять основных блоков:

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

На что мы можем влиять?

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

Под совмещением понимается такое объединение компонентов или элементов среды, которые создают некоторое новое качество или свойство.

Это принципиально важно — новое качество (эмерджентное свойство) появляется от совмещения элементов вместе, и каково назначение этого объединенного нового для того, чтобы мы могли им оперировать.

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

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

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

Внутри системы есть взаимосвязи между различными компонентами системы.

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

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

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

Помимо характеристик, мы будем рассматривать еще свойства системы.

В данном уроке мы начнем с таких свойств, как модульность и независимость от реализации.

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

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

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

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

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

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

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

Как системы развиваются ?
Ну, неужели вот сразу — раз, и с нуля сделали большую сложную систему?

Естественно, это не так. Как мы с вами уже знаем из теории сложности, с точки зрения возможности создать систему существует некоторая эволюция, системы начинают создаваться в комплекс-среде (Complex) и представляют собой достаточно подвижную конструкцию.

По мере нарастания в этой среде количества систем, системы начинают объединяться в некоторые совокупности, для которых не так давно было сформулировано определение так называемых система-систем (system-of-system).

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

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

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

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

Поскольку система-систем — это относительно новое понятие, то есть в научных статьях его начали определять в 2003-2004 году, нужно рассмотреть, чем система-систем отличается от системы подсистем.

Так как система-систем не имеет общего назначения, то есть это — своего рода экосистема, в которой никто не задал главное правило, контракт с надсистемой, Контракт с надсистемой это есть сумма контрактов взаимодействия систем между собой.

И, соответственно, каждая система, которая входит в такую систему-систем, ограничена в своем развитии только теми контрактами, которые у нее есть с другими системами.

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

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

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

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

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

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

Сначала система зарождается и становится системой-систем, когда есть ограничения, есть связи, но, по сути дела, каждая система еще очень гибкая. И, соответственно, применение гибких методологий в данной ситуации оправдано. По мере созревания система становится комплексной(complicated) и переходит в состояние, когда ее необходимо проектировать, то есть много раз подумать, прежде чем изменить.

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

Это ситуация администрирования системы, либо совершенствования характеристик без изменения интерфейсов.

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

И, таким образом, цикл как бы замыкается. Если система не способна адаптироваться и изменить какие-то свои характеристики или границы, система, соответственно, погибает.

Что примечательно: этот жизненный цикл очень похож на древнеиндийские представления о мире и о ролях божеств. Есть этап создания (Брахма), есть этап управления или поддержания(Вишну), и есть этап размораживания или смерти, то есть бог Шива отвечает и за переход в мир иных, и за зарождение, появление нового.

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

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

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

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

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

Контекст — это некоторые объекты среды, которые будут взаимодействовать с системой, но на которые мы не имеем влияния или не будем влиять. Соответственно, у нас получается граница системы (Scope) — это то, мы собираемся сделать, реализовывать.

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

Соответственно, когда в наше поле зрения попадает какой-то объект, он может попасть в три зоны.

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

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

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

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

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

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

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

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

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

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

Что принципиально важно понимать?

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

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

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

Цепочка принятия решений должна быть поддержана, с другой стороны, цепочкой проверки и валидации.

Откуда берется вторая часть этого… этой замечательной схемы? Представьте себе, что по той или иной причине надсистема перестала выполнять свою работу. То есть, мы здесь столкнулись с часто возникающей проблемой — что-то не работает. (:-))

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

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

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

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

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

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

Итак перейдем от теории ближе к практике. Бизнес-система.

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

Хороший вопрос — является ли бизнес-система живой (система-систем) или иерархической?

На самом деле, вопрос неточен.

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

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

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

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

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

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

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

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

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

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

Какие роли здесь можно выделить?

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

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

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

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

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

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

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