скачать книгу бесплатно
72. Данилин А. В., и Зиндер Е. З., (2006) Разработка концепции единой архитектуры «электронного правительства». Презентация. слайд 20 http://www.myshared.ru/slide/189128/
73. Данилин А. В., Слюсаренко А. И. Курс лекций: ИТ-стратегия. Лекция 8: Архитектуры для государственных ведомств. Примеры. М.: Интернет-Университет Информационных Технологий. https://www.book.ru/book/917728/view2/10
74. Дёмина А. В. (2015) Электронный бизнес. Саратов: Саратовский социально-экономический институт (филиал) ФГБОУ ВПО «РЭУ им. Г. В. Плеханова». C.176 ISBN 978–5–4345–0331–0 http://www.seun.ru/content/learning/4/science/1/doc/Demina_Elektronnij_biznes.pdf
75. Дрожжинов В. И. (2010) «Оценка европейских моделей предоставления государственных и муниципальных услуг в электронном виде на местном уровне», Москва: EuropeAid/126204/SER/RU Проект G2C по поддержке э-правительства Российской Федерации. Компонент 2: Политические, законодательные и нормативно-правовые рамки. Активность 2.2: Подготовить аналитические заметки по ключевым стратегическим вопросам о развитии э-правительства в России. C. 72 http://doc.knigi-x.ru/22yuridicheskie/417536–1-europeaid-126204-ser-ru-vladimir-drozhzhinov-vladimir-drozhzhinov-issledovanie-ocenka-evropeyskih-modeley-predo.php
76. Косяков А, Свит У. и др. (2014) Системная инженерия. Принципы и практика. Пер. с англ. Под ред. В. К. Батоврина. М.: ДМК Пресс C.636: илл. https://search.rsl.ru/ru/record/01008645598
77. Ларина Е. (2013) IBM Watson: путь к когнитивно-вычислительному бизнесу. Портал Trebunet http://www.therunet.com/articles/2211-ibm-watson-put-k-kognitivno-vychislitelnomu-biznesu
78. Левенчук А. (2015) Системноинженерное мышление. М.: TechInvestLab. 305 С. 2 апреля http://techinvestlab.ru/files/systems_engineering_thinking/systems_engine
79. Липунцов Ю. П. (2010) Электронное государство. Часть 1. Модели и архитектура: Раздел 2.5. Архитектура электронного государства России в книге: Учебное пособие. М.: Экономический факультет МГУ им. М. В. Ломоносова. ТЕИС. C. 272. https://istina.msu.ru/publications/book/1322644/
80. Малиновский Б. Н. (1995) История вычислительной техники в лицах. К.: фирма «КИТ». ПТОО «А.С.К.». C. 384. ил. ISBN 5–7707–6131–8 http://lib.ru/MEMUARY/MALINOWSKIJ/0.txt_with-big-pictures.html
81. Михайлова О. В. (2014) Сетевая архитектура государственного управления: проблемы концептуализации и практики. Диссертация на соискание ученой степени доктора политических наук МГУ им. Л. В. Ломоносова http://www.dslib.net/polit-instituty/setevaja-arhitektura-gosudarstvennogo-upravlenija-problemy-konceptualizacii-i.html
82. Михеев Ю. А. (2011) Система государственного управления в информационном обществе и информационно-коммуникационные технологии. М. Типография ГМЦ Росстата. C.256 http://docplayer.ru/43032493-Yu-a-miheev-sistema-gosudarstvennogo-upravleniya-v-informacionnom-obshchestve-i-informacionno-kommunikacionnye.html
83. Николаев В. Г. (2015) «Геоинформационная платформа «Единое информационное пространство геоданных» для создания комплексных региональных систем» М. Журнал: ГЕОМАТИКА № 1. С.80–87. ISSN: 2410–6879 https://elibrary.ru/item.asp?id=23335150
84. Правила и процедуры Системы межведомственного электронного взаимодействия при взаимодействии по Методическим рекомендациям 3.0 http://d-russia.ru/wp-content/uploads/2014/12/project_SMEV_3.pdf
85. Проект «Хроника взаимооотношений Минкомсвязи и Ростелекома по проекту электронное правительство» 2009–2016 Tadviser. http://tadviser.ru/a/218533
86. Резолюция Генеральной Ассамблеи ООН от 25 сентября 2015 года/ Преобразование нашего мира: Повестка дня в области устойчивого развития на период до 2030 года http://unctad.org/meetings/en/SessionalDocuments/ares70d1_ru.pdf
87. Рейтинг электронного правительства ООН (2016) Tadviser http://tadviser.ru/a/319289
88. Справочные модели, опубликованные как отдельные документы в переводе на русский язык, можно найти на странице Центра компетенции по электронному правительству при Американской торговой палате в России (2002–2004 гг.) на сайте Центра технологий электронного правительства НИУИТМО http://library.egov.ifmo.ru/ru/biblio?f[author]=66
89. Ханнес Асток (2008) Мобильное правительство: мобильные сервисы в государственном секторе http://zelao.ru/files/videoseminar1/Opyt_Estonii_v_sfere_mobilnogo_pravitelstva.pdf
90. Целищева Е. Ф. От электронного правительства к электронному государству. Электронный журнал научных публикаций студентов и молодых учёных http://ego.uapa.ru/en/issue/2011/02/1/
91. Центр компетенции по электронному правительству (1999) Руководство по разработке архитектуры федерального предприятия. Версия 1.1. Разработано Советом руководителей информационных служб CIO. Расширенный реферат по материалам: Federal Enterprise Architecture Framework. Ver. 1.1. Developed by: The Chief Information Officers Council http://library.egov-center.ru/sites/default/files/Federal_EA_CIO.pdf
92. Центр компетенции по электронному правительству (2001) Практическое руководство по разработке архитектуры федерального предприятия Совет Руководителей служб информационных систем. Версия 1.0. Февраль 2001. Расширенный реферат по материалам: A Practical Guide to Federal Enterprise Architecture Chief Information Officer Council. Ver. 1.0 http://egov.ifmo.ru/files/000052.pdf
93. Что такое интернет вещей (2017) Tadviser http://tadviser.ru/a/135141
Часть 2 Электронное правительство как объект системной инженерии
Введение
К созданию электронных правительств страны приступают после информатизации органов власти, когда созданы системы, которые автоматизируют деятельность органов власти и местного самоуправления. Эти системы являются социотехническими, т. е. объединяют техническую составляющую и лиц, принимающих решения либо обеспечивающих их подготовку, чтобы обеспечить эффективное исполнение государственных функций. В процессе создания и развития э-правительства стоит задача не только интегрировать эти системы на базе инфраструктуры ЭП для автоматизации предоставления услуг населению и бизнесу, но также провести трансформацию систем и процессов деятельности, не прерывая при этом исполнение функций и принятие решений.
Таким образом, электронное правительство включает как собственные развиваемые инфраструктурные и социотехнические системы, так и социотехнические развиваемые системы органов власти. Находясь на различных административных уровнях власти – национальном, федеральном, региональном и местном, – эти многочисленные государственные организации, учреждения и предприятия в значительной мере самостоятельны в своей деятельности и управлении своими системами. Поэтому и системы, входящие в состав э-правительства, в общем случае остаются автономными – не зависят одна от другой с административной и технической точек зрения. Они могут обмениваться информацией через каналы связи, но среда их взаимодействия отличается высокой гетерогенностью.
Автономных систем (системы систем), отличаются от свойств системы из подсистем. А ее жизненный цикл – от жизненного цикла системы, изначально спроектированной как одно целое и имеющей единого владельца. Это приводит к значительным особенностям применения системной инженерии при построении э-правительства, которым мы и посвятили вторую часть монографии.
Интерпретация э-правительства как системы систем была предложена нами в 2014 году [52], и в специальной литературе еще недостаточно исследована. На наш взгляд, такая интерпретация позволяет более точно сформулировать жизненный цикл э-правительства, наиболее адекватно учесть его свойства и особенности функционирования. Для частичного заполнения этого пробела в главе 4 мы рассматриваем основные понятия и особенности методов системной инженерии, применяемые при создании и функционировании системы систем, значение интероперабельности для интеграции гетерогенных систем и особенности интеграции систем при различных руководящих принципах реализации э-правительства (см. часть 1).
Возможности и свойства сложных информационных систем в значительной мере зависят от начального этапа их разработки, когда системная инженерия вносит наиболее важный вклад в успех всего проекта. Анализ автоматизируемой деятельности, определение заинтересованных сторон и их потребностей, выработка системных требований предваряют формирование концепции функционирования, которая, как правило, становится первым базовым документом при создании системы. Положения концепции итеративно уточняются в процессе описания архитектуры, для которого системная инженерия предоставляет необходимые методы и инструменты. Применительно к электронному правительству эта часть процесса разработки направлена на структурирование представлений участников об ЭП, создание его концептуальной модели, определение состава и методик построения/развития набора моделей э-правительства. Описание архитектуры электронного правительства дает возможность с большей степенью детализации определить и консолидировать различные позиции (интересы) его участников и потребителей, а также планировать жизненный цикл и управлять изменениями для согласованного развития ЭП и входящих в него систем.
Основные понятия архитектуры систем и методы описания архитектуры как набора моделей представлений с точки зрения различных заинтересованных сторон представлены в главе 5. Применение эталонных моделей, абстрактных и независимых от технологии, в качестве основы процесса построения архитектуры и переход от эталонных моделей к разработанным в результате этого процесса конкретным моделям рассматриваются в главе 6. Методики построения архитектуры и рекомендации по использованию этих методов обсуждаются в главе 7.
Применение методов системной инженерии с учетом особенностей системы систем, обоснованный выбор и использование методов построения архитектуры имеют решающее значение для успешного создания и функционирования э-правительства.
Глава 4 Системная инженерия электронного правительства
4.1. Системы систем: особенности применения системной инженерии
Середина ХХ века ознаменовалась быстрым ростом сложности инженерных объектов, что привело к возникновению системной инженерии как прикладной методологии успешного построения систем. Первый крупный вклад в развитие системной инженерии внес [23] Д. У. Гилмен, который, вероятно, сделал первую попытку учить системных инженеров в Массачусетском технологическом институте в 1950 году. Развитие системной инженерии было связано с работами ряда зарубежных и отечественных исследователей, обзор основных публикаций которых приведен в [19] и [54].
В 1990 году была создана первая профессиональная организация для исследований в области системной инженерии – Национальный совет по системной инженерии (NCOSE). Летом 1995 года организация официально изменила свое название на Международный совет по системной инженерии (INCOSE), чтобы отразить растущее участие специалистов из десяти различных стран мира. К настоящему времени INCOSE объединяет 16 000 специалистов из 35 стран[138 - https://www.incose.org/incose-impact].
Нужно заметить, что в СССР системная инженерия (она называлась системотехникой) с 60-х годов активно развивалась, но в период перестройки соответствующие дисциплины постепенно перестали преподаваться в учреждениях высшей школы. Последние учебники на русском языке по этой дисциплине относятся к 80-м гг. прошлого столетия, и лишь в 2013 г. в МФТИ открылась выпускающая межфакультетская кафедра системного инжиниринга[139 - http://sehs.mipt.ru/school/about]. «В середине 2000-х годов в течение короткого периода наши специалисты пытались интегрироваться в мировое сообщество создателей нормативно-технического обеспечения системной инженерии, они, в частности, приняли участие в разработке стандарта ISO/IEC 15288. В 2007 году в Москве прошло заседание ISO/IECJTC1/SC7, в котором от России приняло участие около 10 человек» [53]. А в 2009 году было организовано российское отделение INCOSE, которое к концу 2012 года насчитывало 135 членов[140 - https://incose-rus.weebly.com].
Основные вехи в развитии системной инженерии с 1950 до 2012 года проиллюстрированы на рис. 2.1 [53].
Рис. 2.1. Системная инженерия. Важные вехи [53]
В 2012 году была опубликована первая версия фундаментального «Руководства по своду знаний в области системной инженерии» (Guide to the Systems Engineering Body of Knowledge, далее – SEBoK) [21], после чего дальнейшее управление развитием этого свода знаний было передано INCOSE[141 - http://www.incose.org/]. А с 2013 года к этой работе подключились другие крупнейшие организации системных инженеров – Исследовательский центр системного инжиниринга (Systems Engineering Research Center, SERC)[142 - http://www.sercuarc.org/] Международного Совета по системной инженерии (INCOSE) и Институт инженеров по электротехнике и электронике – Компьютерное общество (Institute of Electrical and Electronics Engineers Computer Society, ІЕЕЕ-CS)[143 - http://www.ieee.org/index.html]. SEBoK постоянно расширяется: в 2017 году вышла версия 1.8 [22], в разработке которой приняло участие более сотни специалистов из 17 стран.
В соответствии с SEBoK под системной инженерией понимают «междисциплинарный подход и способы обеспечения воплощения успешных систем» [22, Glossary]. Взаимодействие ключевых элементов системной инженерии проиллюстрировано на рис. 2.2.
Для определения места системной инженерии в создании и внедрении систем удобно использовать диаграмму Венна[144 - Диаграмма Венна – это схема, которая показывает все возможные логические отношения между конечной коллекцией различных наборов. Диаграмма Венна состоит из нескольких пересекающихся замкнутых кривых, обычно кругов, каждый из которых представляет собой набор, см. J. Venn M. A., «On the diagrammatic and mechanical representation of propositions and reasonings», https://www.cis.upenn.edu/~bhusnur4/cit592_fall2014/venn%20diagrams.pdf]. На рис. 2.3 показаны область действия и пересечения системной инженерии, внедрения систем и управления проектом/системой.
Рис. 2.2. Ключевые элементы системной инженерии
Источник: SEBoK v1.8 [22, Introduction to Systems Engineering]
Рис. 2.3. Границы системной инженерии,
внедрения систем и управления проектом/системой [22]
Авторы SEBoK подчеркивают, что системная инженерия «ориентирована на целостное и одновременное понимание потребностей заинтересованных сторон; обследование возможностей; документирование требований; обобщение, верификацию, валидацию и совершенствование решений при рассмотрении комплексной проблемы, начиная с анализа концепции и заканчивая утилизацией системы»[145 - http://sebokwiki.org/wiki/Systems_Engineering_(glossary)] [22, Glossary].
К основным понятиям (концепциям) системной инженерии в соответствии с ГОСТ Р 57193–2016 [15н][146 - Разработан с учетом основных нормативных положений международного стандарта ISO/IEC/IEEE 15288:2015 [32] т.] относятся:
1. Система (system) – комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей.
2. Жизненный цикл (life cycle) – развитие системы, продукции, услуги, проекта или другой создаваемой человеком сущности от замысла до списания.
3. Заинтересованная сторона (stakeholder) – индивидуум или организация, имеющие право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими их потребности и ожидания.
«Эволюция целевой системы связывается в системной инженерии с прохождением последовательности определенных стадий, увязанных с совокупностью управленческих решений, для обоснования которых используются объективные свидетельства того, что система на принятом уровне материализации является достаточно зрелой для перехода от одной стадии жизненного цикла к другой. При этом на каждом этапе жизненного цикла система имеет относительно стабильный набор характеристик. При моделировании жизненного цикла используются совокупности процессов жизненного цикла»[147 - Системная инженерия. Гуманитарная энциклопедия [Электронный ресурс] // Центр гуманитарных технологий, 2010–2016 (последняя редакция: 30.10.2016), http://gtmarket.ru/concepts/7110. Текст статьи: © Батоврин В. К., Голдберг Ф. И., Александров А. Н. Подготовка электронной публикации и общая редакция: Центр гуманитарных технологий.].
Формально в ГОСТ Р 57193–2016 [15н] процесс (process) определен как совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы. При этом выделены[148 - Указанная классификация характерна для ГОСТ Р 57193-2016. Такие организации, как NASA, SAE, EIA и другие используют свои классификации процессов жизненного цикла.] 4 группы процессов жизненного цикла:
• процессы соглашения (Agreement Processes);
• процессы организационного обеспечения проекта (Organizational Project-Enabling Processes);
• процессы проекта (Technical Management Processes);
• технические процессы (Technical Processes).
Процессы жизненного цикла системы в стандарте ГОСТ Р 571932016 описаны относительно системы, которая составлена из ряда системных элементов для взаимодействия, каждый из которых может быть реализован таким образом, чтобы выполнить соответствующие ему заданные требования.
Следующие положения являются основными относительно характеристик рассматриваемой системы:
a) определенные границы характеризуют значимые потребности и практические решения;
b) существуют иерархические или иные отношения между системными элементами;
c) какая-либо сущность на любом уровне в рассматриваемой системе может быть рассмотрена как система;
d) система включает интегрированное, определенное множество нижестоящих системных элементов;
e) свойства характеристик в границах системы определяются результатами взаимодействий между системными элементами;
f) люди могут рассматриваться как пользователи внешние к системе и как системные элементы (т. е. операторы) в пределах системы;
g) система может быть рассмотрена в изоляции как некая сущность, например, как продукт или набор функций, способных к взаимодействию с окружающей средой, т. е. как множество услуг.
Концепциям, принципам и методам системной инженерии посвящено значительное количество работ[149 - Обзорный доклад по этим вопросам был сделан 11.02. 2015 года профессором В.К. Батовриным на 100-м заседании INCOSE RUS, https://incose-rus.weebly.com/systems_engineering_essentials.html. Там же можно найти список литературы.], которые, безусловно, оказали большое влияние на ее развитие. Хотя рассмотрение оснований системной инженерии выходит далеко за пределы монографии, следует обратить внимание на то, что в современной «системной инженерии рассматриваются не любые, а именно большие (крупномасштабные) и сложные системы. Общепризнанной границы, разделяющей большие и сложные системы, нет. Однако отмечается, что термин „большая система“ характеризует многокомпонентные системы, включающие значительное число элементов с однотипными многоуровневыми связями. Большие системы – это пространственно-распределенные системы высокой степени сложности, в которых подсистемы (их составные части) также относятся к категориям сложных. <…> В свою очередь, термин „сложная система“ характеризует структурно и функционально сложные многокомпонентные системы с большим числом взаимосвязанных и взаимодействующих элементов различного типа и с многочисленными и разнородными связями между ними. Сложные системы отличаются многомерностью, разнородностью структуры, многообразием природы элементов и связей, организационной разносопротивляемостью и разночувствительностью к воздействиям, асимметричностью потенциальных возможностей осуществления функциональных и дисфункциональных изменений. При этом каждый из элементов подобной системы может быть также представлен в виде системы (подсистемы)» [55].
Такой подход к рассмотрению систем как совокупности иерархически организованных систем (подсистем) хорошо исследован в теории систем [64] и широко используется в практике проектирования. При этом отмечается, что большие технические системы «с иерархической структурой являются многоуровневыми многокритериальными системами, обладающими сложным (с наличием неопределенности) поведением, и характеризуются усложнением постановки и решения оптимизационных задач» [71].
Проблема сложности является ключевой для системной инженерии и теории систем. Ее исследование началось в середине 60-х годов [57, 66], а к 80-м годам «сложилась специальная научная дисциплина, названная теорией сложности. В 1984 году был основан Институт Санта Фе в Нью-Мексико, а двумя годами позже – Центр изучения сложных систем в университете штата Иллинойс» [72]. Интеграция гетерогенных сложных систем приводит к образованию систем с труднопредсказуемым поведением и неожиданными свойствами, а внесение изменений в процессе эксплуатации постоянно повышает их сложность. Принципы системной инженерии и практика их применения также активно развиваются, отвечая на эти усложнения.
Группы систем, в которых отдельные системы могут существовать автономно – поскольку были разработаны и функционируют независимо друг от друга – и при этом представлять собой полноценную целевую систему, получили название система систем (System of Systems, SoS). Основой для исследований в области SoS являются принципы системной инженерии. Однако ряд существенных особенностей SoS привел к возникновению новой области системной инженерии, которая должна обеспечить управление жизненным циклом системы систем, при том, что каждая составляющая система SoS может находиться на своей стадии жизненного цикла.
Исследования свойств SoS c 1970-x годов [1] проводились индивидуальными исследователями до начала 2000-х годов, когда системы систем стали предметом серьезного внимания ведущих исследовательских организаций [19]. В период 2008–2009 гг. в различных работах, например [33], был представлен ряд определений SoS, не все из которых были положительно приняты мировым сообществом. Современное определение SoS, объединившее более ранние определения различных авторов, дано в глоссарии SEBoK[150 - http://www.sebokwiki.org/wiki/System_of_Systems_(SoS)_(glossary)]:
«SoS – это интеграция конечного числа составляющих систем, которые являются независимыми и функционирующими, объединенных в сеть на определенный период времени для достижения определенной высшей цели».
А на десять лет раньше, в 1998 году, были сформулированы [37] базовые характеристики SoS:
1) эксплуатационная независимость отдельных систем – SoS состоит из систем, интегрированных в SoS, независимых и пригодных к работе по отдельности;
2) административная независимость отдельных систем – системы, составляющие SoS, работают независимо ради достижения поставленных перед ними целей, которые могут отличаться от назначенных SoS;
3) территориальная распределенность – системы, входящие в состав SoS, могут находиться далеко друг от друга и обмениваться между собой только информацией;
4) эмерджентное[151 - Эмерджентность в теории систем – наличие у какой-либо системы особых свойств, не присущих ее подсистемам и блокам, а также сумме элементов, не связанных особыми системообразующими связями; несводимость свойств системы к сумме свойств ее компонентов; синоним – «системный эффект», http://ru.wikipedia.org/wiki/Эмерджентность]поведение – ожидание синергетического эффекта является главной причиной объединения отдельных независимых систем. SoS может создаваться для осуществления цели и выполнения функций, не обязательно свойственных какой-либо из входящих в ее состав систем;
5) эволюционное развитие – входящие в состав SoS системы, их компоненты, структуры, функции и цели изменяются по мере накопления опыта работы с системой.
Причем эксплуатационная и административная независимость определены как две основные отличительные характеристики для применения термина «система систем». Система, которая не проявляет этих двух характеристик, не считается SoS вне зависимости от сложности и географического распределения ее компонентов. Многие авторы [19] объединяют эти две характеристики, говоря об автономности как способности составляющих SoS систем делать независимый выбор, включая административную и эксплуатационную независимость. При этом эмерджентность также рассматривается как неотъемлемая характеристика SoS, ради которой, собственно, и объединяются составляющие системы. Однако SoS могут проявлять не только предсказуемую эмерджентность: в силу автономности составляющих систем возможно возникновение непредвиденных последствий и нежелательного поведения. Своевременное выявление и пресечение такой непредвиденной эмерджентности является важной задачей системной инженерии SoS.
Характеристика автономности определяет, по нашему мнению, принципиальное отличие системы систем от системы из подсистем, которое состоит в том, что у каждой системы в SoS есть свой владелец («хозяин»), тогда как у системы из подсистем есть только один владелец («хозяин») всей системы. Это свойство (наличие владельца системы), которое традиционно не учитывается в теории систем (как системы из подсистем), вносит новое качество на различных уровнях. Например, для ведомственной системы владельцем может быть ведомство (заказчик или оператор), для web-приложения – провайдер сервиса, для средства обеспечения доступа – пользователь.
Нужно отметить, что три приведенные выше ключевые характеристики – эксплуатационная и административная независимость, а также эмерджентность – закреплены новой (действующей) редакцией международного стандарта по системной инженерии ГОСТ Р 57193–2016 [15н]. Причем стандарт также обращает внимание на сложную динамику взаимодействия составляющих систем, которая может приводить к непредсказуемой эмерджентности: «Главной характеристикой SoS являются неожиданные случаи, т. е. непредвиденные эффекты на уровне SoS, отн сенные к сложной динамике взаимодействия составляющих систем. В SoS составляющие системы преднамеренно рассматриваются в их комбинации с тем, чтобы получить и проанализировать результаты, невозможные к получению от единичных систем. Сложность составляющих систем и факт того, что они, возможно, были разработаны безотносительно к их роли в SoS, может привести к новым, неожиданным поведениям. Определение и обращение к непредвиденным эмерджентным результатам – это особенная сложная проблема в инженерии SoS».
Кроме приведенных выше характеристик, многие исследователи [19] считают важными также следующие характерные особенности SoS:
• Принадлежность – составляющие системы имеют право и возможность выбирать принадлежность к SoS исходя из собственных потребностей. Существование SoS повышает значимость цели составляющей системы, возвеличивает роль этой системы, поскольку ее принадлежность делает достижение общей цели SoS более быстрым и эффективным.
• Связанность – возможность оставаться подключенными к другим составляющим системам. Необходимо создание связанности, или, другими словами, достижение интероперабельности между унаследованными системами и, возможно, добавленными новыми системами в SoS.
• Разнообразие – свидетельство явной гетерогенности. SoS должна быть, по необходимости, весьма разнообразной по своим возможностям по сравнению с довольно ограниченным функционалом составляющих систем. Существует фундаментальное различие между основанной на требованиях, управляемой конструкцией обычной системой для определенной предметной области и основанной на возможностях SoS, которая должна проявлять значительное разнообразие функций как необходимый ответ на высокую изменчивость потребностей, постоянные неожиданности и деструктивные новации.
Со временем было предложено добавить еще две важных характеристики SoS:
1. «Самоорганизация. SoS имеет динамическую организационную структуру, способную реагировать на изменения в окружении и изменения поставленных целей и задач.
2. Адаптация. Как и развивающаяся организация, сама структура SoS может быть динамичной и реагировать на внешние изменения и восприятие среды» [61].
Следует обратить внимание, что SoS необязательно формируется на постоянной основе, она может быть необходима для интеграции систем и сетей с какими-либо конкретными целями и на определенный период. Причем способы организации совместной работы систем, входящих в SoS, могут существенно различаться.
В 2008 году Министерство обороны США выпустило руководство по системной инженерии специально для SoS [46], в котором (со ссылкой на работы ряда исследователей [37, 10]) было выделено четыре категории подобных систем:
• виртуальная – в виртуальной SoS нет центрального пункта управления и единой согласованной цели. Поведение, характерное для крупномасштабных систем, вероятно и, возможно, даже желательно, но предполагается, что в SoS такого типа для поддержания должны использоваться сравнительно слабо выраженные механизмы;
• коллаборативная – входящие в состав коллаборативной SoS отдельные системы взаимодействуют на более или менее добровольной основе для достижения согласованных общих целей. Стандарты применяются, но нет никакого центрального органа, который контролировал бы их соблюдение. Основные игроки сообща решают, нужно ли предоставлять (и если нужно, то как предоставлять) обслуживание, обеспечивая тем самым некоторую степень следования стандартам регулирования и обслуживания;
• общепризнанная – у общепризнанной SoS имеются осознанные цели, назначенный руководитель и выделенные ресурсы. Однако у составляющих ее систем по-прежнему есть независимые владельцы, цели, финансирование, подходы к разработке и обеспечению функционирования. Для внесения изменений в каждую отдельную систему необходимо добровольное сотрудничество между ней и SoS;
• целевая – целевыми называются интегрированные SoS, которые создаются и управляются для достижения конкретных целей. Они централизованно управляются на протяжении длительного срока службы для выполнения как ранее поставленных, так и новых задач, которые могут представлять интерес для владельцев системы. Составляющие системы сохраняют возможность работать независимо, но в нормальном режиме их работа подчинена общей цели[152 - Заметим, что в ГОСТ Р 57193-2016 эти категории SoS названы соответственно виртуальная, объединенная, познаваемая и руководимая.].
Существенно различная организация взаимодействия в SoS перечисленных категорий не может не сказываться на их характеристиках. Например, при переходе от виртуальных или коллаборативных SoS к более «жестко» организованным общепризнанным или целевым SoS следует ожидать возрастания зависимости SoS в целом от изменений составляющих систем. Однако внесение изменений в таких SoS производится по согласованию заинтересованных сторон, что дает возможность снизить непредсказуемую эмерджентность.
Самым известным примером SoS является интернет. С точки зрения провайдеров, обеспечивающих магистральную передачу данных и последнюю «милю», – это коллаборативная SoS. Провайдеры взаимодействуют на более или менее добровольной основе, вступая в соответствующие договорные отношения, применяют стандарты и обеспечивают обслуживание клиентов. При этом они остаются независимыми и не имеют какого-либо общего руководителя.
Вместе с тем компании и индивидуальные пользователи имеют возможность создавать сетевые сервисы, используя не только инфраструктуру интернета, но и опубликованные сервисы других владельцев. Например, вставляя чужие фреймы в свой публичный или корпоративный портал. По сути, таким способом формируется множество виртуальных SoS со слабоорганизованными взаимодействиями: действительно, ведь в нашем примере ответственность за работоспособность «чужого» сервиса лежит на том, кто его вставил в свой портал, если нет специального контракта с владельцем сервиса. То есть в данном случае репутация владельца становится решающей. Естественно, такая виртуальная SoS будет существовать в течение того временного отрезка, на котором она решает поставленную задачу.
Именно виртуальные и коллаборативные SoS становятся «главными» в цифровом мире. И если 20 лет назад разработки SoS были прерогативой оборонных ведомств, то сейчас можно привести множество примеров SoS из ежедневной жизни и различных предметных областей:
• «транспорт – управление воздушным движением, Европейская железнодорожная сеть, интегрированное управление наземным транспортом, грузовым транспортом, управление скоростными магистралями и космические системы;
• энергетика – умные сети, умные дома и интегрированное производство/потребление;
• здравоохранение – системы управления областными учреждениями, аварийно-спасательными службами и управления персональным здоровьем;
