1 ЦКБ-АбаваНет, г. Москва, Россия 2 Московский государственный университет имени М.В. Ломоносова, гР.оссМиоясква, 3 Федеральный исследовательский цернт«Информатика и управление», гР.АНМоскРвоас,сия

-

ON INFORMATION MODELS OF THE DIGITAL ECONOMY 1. Введение and the SysML language are discussed. As the prototype of the Russian information model of the digital economy, we propose the newest language Lifecycle Modeling Language. 2.

Что можем взять из российского опыта «Красная книга» — проект создания Общесоюзной сети ВЦ двойного наз—начвеонеиняного и гражданского, для управления экономикой страны в мирное время и Вооружёнными силами военное. К сожалению, проект «Красная книга» был отвергнут, а сам Китовгонбеынлиямп:одвеегрогнут исключили из КПСС, сняли с должности начальника, созданн-1огоМО—им безВЦ права занимать руководящие должности. Рис. 1. АСУВ «Маневр» [3]: а) командно-штабная машина МП-22Р начальника дивизии ПВО, б) пульт управления АСУВ «Маневр» Проекты В.М. Глушкова. Идеи А.И. Китова далее развил академик В.М. Глушков. Уже в 1964 г руководством был разработан первый эскизный проект Государственной сети вычислительных цент (ГСВЦ), предназначенной для перестройки на основе безбумажноойгии техонрогланизационн-о экономического управления на всех уровнях (от отдельных предприятий и учреждений до Госплан Замысел ученого получил одобрение А.Н. Косыгина, председателя Совета Министров СССР, и Глушков со свойственной ему энергией пиплрискту делу, которое впоследствии назвал главным в сво жизни. Он подсчитал, что при умелой организации работ уже через пять лет затраты на окупаться, а после ее реализации возможности экономики и благосостояние населения по меньше удвоятся. Было еще одно обязательное условие, которое он поставил, а именно: создание автори наделенного всеми полномочиями государственного органа управления ходом выполнения программ ОГАС – Государственного комитета по управлению программой (Го)с,комнаупордобие тех комитетов, с помощью которых осуществлялись космическая и ядерная программы. Это в то время было р политической крамолой: научное управление обще–сотвоумжас–! не на основе маркс-илземнаинизма, а на базе точных н–аумкатематики, автоматического управления, статистики и пр. Работы по ОГ свернули.

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

Рис. 2. Функциональная структура ОГАС (фрагмент) [ 4 ] Научный задел по ОГАС нашел некоторое продолжение в постсоветское время. -хЕщгеодовв начале в Институте кибернетики в Киеве (сейчас имени В.М. Глушкьовар)абонтаычалпиос переосмысливанию технологии программирования. Была разработана новая технология графического программирования. 1989г. был получен первый и до сих пор единственн-чылйенавх сСтЭрВанасхтандарт ISO/IEC 863-1 по Р технологии графического прогрмаимрования [ 5 ].-теРхнология графического программирования имеет сходство с языком UML (Unified Modeling Language) [ 6 ].

Программные средства для телефонных станций. В 19-ы70е годы Международный Союз Электросвязи разработал стандарты трех языков програамнмияировтелефонных станций [ 7 ]: язык спецификаций и описаний SDL (Specification and Description Language), язык программирования выс уровня CHILL и язык общения персонала с телефонной ста-нmцaиcеhйine MlaMngLuag(me)a.n Используя эти языковые среад, ствстранах членах СЭВ разрабатывалось поколение электронных станций ЕССКТ (Единая Система Средств Коммутационной Техники). Головным предприятием по пр ЕССКТ (сравнимому с проектом ЕСЭВМ) являлся институт НИИ ВЭФ (Рига, Латвия). После разв проект ЕССКТ прекратил свое существование. В качестве примера последовательного примене программных средств МСЭ можно указать цифровую электронную коммутационную систему E разработанную немецким концерном Siemens.

Цифровое предприятие. Укажем два йншовиех российских проекта в области цифрового предприятия. 1–316 декабря 2016 г. в Москве было проведено заседание Межведомственной экспер комиссии по приемке результатов проектов по направлению «Цифровое предприятие».

Объектами испытаний были следуюпщриоеграммные комплексы (всего 11 комплексов программ в импорто-независимой реализации): • система управления производственным предприятием; • система управления материальными ресурсами; • система управления трудовыми ресурсами; • система управления дсрстевами производства; • система управления производственными процессами, • система экономического управления; • система информационного анализа; • комплекс средств интеграции; • система управления основными данными; • система управления производствнеынми документами; • комплекс портальных сервисов.

20-22 июня 2017 г. в Ижевске состоялся шестой международный форум «Информационные техн на службе оборон-пнроомышленного комплекса России» (ИТ-2О0П1К7). На форуме, среди прочего, обсуждали информациноно-технологическую систему ТИС ЯОК-с.пецИиТалисты ФГУП «РФ-ЯВЦНИИЭФ» разработали и внедрили на предприятии и-нмепзоарвтиосимую информационн-отехнологическую систему ядерн-оружейного комплекса ТИС ЯОК, которая обеспечивает автоматизацию предприятия контурах «для служебного пользования» и «государственная тайна». Система начала успе тиражироваться на предприятиях яд-еоррнуожейного комплекса. Поскольку в СССР все оборонные предприятия создавались по единой производственной методологии, то и ТеИтС уЯспОеКшномож использоваться во всей отрасли ОПК. В 1987 г. появилась статья Дж.А. Захмана «Структура архитектуры информационных систе впервые было введено понятие «архитектура предприятия» [ 8 ]. Джон Захман много лет зан внедрением информационных систем IBM и переосмыслил их архитектуру. Он предложил идею, ко для И-Тотрасли сравнима с Периодической таблицей Менделеева. Он придумал новое описание сложных систем, как транснациональная корпорация. Тем самым он старлхит«еоктцуромы» а предприятия (Enterprise Architecture).

"Модель Захмана" со временем претерпела значительные изменения, появились различные модификации (в работах -199692гг.). Например, в статье 1992 года [ 9 ] были добавлены формализова графические средсвта. Модель Захмана была использована такими крупнейшими корпорациями, к General Motors, Bank of America и др. Модель Захмана послужила основой Институту NIST дл Федеральной архитектуры США (F–EFAeFderal Enterprise ArchitectureFramework), дмиектоой создания архитектуры TOGAF (The Open Group Architecture Framework) сообществом Open Group и, что важно, методикой описания архитектуры Министерства обороны США DoDAF (Department of De Architecture Framework).

Дж. Захман определил аеркхтиутру предприятия как "набор моделей (представлений), которые применимы для описания любого предприятия в соответствии с требованиями управленческ персонала и которые могут развиваться в течение длительного периода". Основная идея архит предприятия заключается в том, чтобы обеспечить возможность последовательного описания кажд отдельного аспекта системы в координации со всеми остальными [ 10 ]. Для любой достаточно системы общее число связей, условий и правил обычно превосходиит вдолзямоижхносотдновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта сис всего приводит к неоптимальным решениям как в плане производительности, так и сто реализации.

Собственно, исходная модель маЗнаах представляется в виде таблицы, имеющей столбцов, которая приведена на рис. 3. Заметим, что в исходной модели было строка (на рис. 3) появилась позже, она выходит за пределы описания работающую систему или предприятие в целом. Рис. 3. Расширенная модель Захмана Итак, модель Захмана cодержит шесть уровней. На каждом из этих уровней участники рассма одни и те же вопросы, соответствующие столбцам в таблице, но с рмазлаибчснтырмакциуировние детализации. В содержание этих колонок входят ответы на шесть вопросов: • используемые данные (что?); • процессы и функции (как?); • места выполнения этих процессов (где?); • организации и участники (кто?); • управляющие события (ког)д;а? • цели и ограничения, определяющие работу системы (почему?). Первые три уровня формируют -бриузкноевсодители.

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

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

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

Уровни с четвертого и далее описывают детали, которые представляют -имнетнеердежсердолвя иИТ проектировщиков, но ведущую роль играют отрчаизкриа.б На четвертом уров—нетехнологической (физической) моде—лиосуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен реляционной СУБД или средств работы с неструктуририованднаыннмыми, или объе-ктно ориентированной среды.

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

Шестой уровень описывает работающую систему. В исходной работе Захмана содержание этого не детализируется. На этом уровне могут быть введены такие объекты, как инструкции для системой, фактические базы данных, работа службы HelpDesk и т.д. 4.

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

Базовый сегмент представляет собой ключевой аспект деятельности предприятия в грани политико-административного деления. Например, для Министерства здравоиояхраниен социальных служб США базовым сегментом является здоровье.

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

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

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

Например, и в Министерстве здравоохранения и социальных сАлугженбт, ствие впо охране окружающей среды федерального правительства США используется служебный сегмент трудов ресурсы. Однако трудовые ресурсы для Министерства здравоохранения и социальных служб отлича от трудовых ресурсов для Агентства по охранещейокрусжреадюы. То же самое относится к службе управления безопасностью: она, по сути, одна и та же и в Министерстве здравоохранения и служб, и в Агентстве по охране окружающей среды используется такая. Эффективное упра учетными записями для зопбаесного доступа обеспечивается только в том случае, если о осуществляется на уровне предприятия.

К сожалению, результаты разработки программы FEA оказались не радужными. В официальном Федеральной счетной палаты для Конгресса США о состроаямнмиыи пFрEоAг в 2002 году был сделан вывод о том, что «в целом система FEA недостаточно развита для обоснованного п инвестиционных решений в области ИТ» [ 12 ]. К тому же программа FEA оказалась чрезвычайно Например, «к концу 2010 года федеерапльрнавоительство потратило более миллиарда долларов на корпоративную архитектуру, и многое, если не большая часть из них была потрачена впустую» 5.

Архитектура DODAF

DoDAF (Department of Defense Architecture Framework) — наиболее известный проект цифровой экономики. Do—DAэFто архитектура, позволяющая Министерству обороны управление на всех уровнях разработки (рис. 5).

вастиобл США облегчить Рис. 5. Структура описания единой информационной среды МО США Единая метамодель DoDAF (рис. 6) разратбсаятывсаеконца 1980х гг. на базе модели Захмана в по объеме (не в урезанном виде, как для FEA).

Рисунок 6 иллюстрирует взаимосвязи между основными понятиями метамодели DoDAF. Мод содержит шесть описаний, которые объединены ключевым понятием Действие:

1) описание данных (Data Descr—iptоioтnв)ечает на вопрос ЧТО (включает и описание Ресурсов, кро самих Данных);

2) описание функции (Function Descri—ptioоnт)вечает на вопрос КАК (содержит также описание Исполнителя, который выполняет Функции иветучиствыязанные с ними Действия, Правила и Условия); 3) описание сети (Network Descri—ptiГoДnЕ); 4) описание участников (People Descri—ptiКoТnО) (включает и сами Организации); 5) описание времени (Time Descri—ptiГoДnЕ); 6) описание мотивации ( Matoiotinv Description) — ПОЧЕМУ (с расширением, что включает описание требований к Функциям).

Рис. 6. Иллюстрация метамодели DoDAF Документация по единой информационной среде GIG (Global Information Grid) представлена с точек зрени–я представлений (iVewpoint) и содержит колоссальный объем мате–рциеаллыохв 52 тома. (Неудивительно, что программистам, как и другим лицам, причастным к созданию DoDAF, сложн нет желания изучать все эти тома.) Тома описывают все аспекты архитектурногорыкеонтекста, относятся к DoDAF (рис. 7): • общее описание (All View—po2int)тома; • описание сервисных компонентов (Capability View—po7int) томов: описывает требования к возможностям системы; время, необходимое для развертывания системы; возможности; развертки • описание данных и информации (Data and Information —Vie3wpoтinоtм) а: описывает взаимодействия между данными системы и согласование архитектуры данных;

• описание операций (Operational Viewp—oint9) томов: включает операционный сценарий, активности и требования по поддержке сервисных компонентов;

• описание проекта (Project Viewp—oin3t) тома: описывает отношения между операционными требованиями и требованиями к возможностям системы;

• описание сервисов (Services View—po1in3t) томов: описываиедтентификацию сервисов, сервисных элементов и их взаимодействий;

• описание системы (System Viewp—oint)13 томов: описывает системы и соединения, поддерживающие работу Департамента Защиты;

• описание стандартов (Standard View—poin2t) тома: описыванееткоторые стандарты, которые используются в разработке решений.

Рис. 7. Структура описания архитектуры DoDAF (версия v.2) с восьми точек зрения Разработка DoDAF началась в конце 1980х и называлась информациоCн4нIоSйR, чстеотьпюоанглийски означает концепцию «Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance»В. русском вариан–теэто «Управление, контроль, связь, сбор и компьютерная обработка информации, наблюдение и разведка». Предполагается, что все иэтиявлфяюунтксяци автоматизированными. C4ISR– это оперативн-остратегический уровень, или, другими словами, уровень больших начальников и штабов.

Система С4ISR включает различные подсистемы, необходимые для технического обеспечен процесса боевого управления рувжоеонными силами. Комплекс C4ISR, по замыслу, позволяет: • автоматически определять положение своих подразделений; • автоматически определять положение противника и его перемещения, что отображается электронных картах; • автоматически выбирать маршрудтвыижения войск; • автоматически задавать цели средствам огневого поражения; • автоматически постоянно осведомлять свои подразделения о действиях и местоположении соседей и противника; • полностью автоматизировать сбор информации и ее обработку; • автоматизировать процесс предложения командиру решений на основании автоматически полученных разведданных, а также информации о силах и средствах, имеющихся в распоряжении; • моделировать бой и его возможные результаты; • предлагать частные решения для комавндихроаде боя на основе текущей ситуации. Таким образом, система С4ISR помогает созданию единого информационного пространств обеспечению возможности адаптивного управления, комплексного использования возможностей боевых сил. Опять же, как и в случаоеннэолгеоктрправительства США, результаты оказались не радужными. Как отмечали критики уже в 1992 году, Министерство обороны США представляет собой на впечатляющий пример непрерывно растущих денежных вложений, получая все те неудовлетворительные резултьаты: «Хотя DOD потратил более 10 лет и по меньшей мере 379 ми долларов на архитектуру своего б-пирзендепсриятия, его способность использовать Архитектуру для руководства и ограничения инвестиций осталась ограниченной» [ 14 ]. Подобный же скпиейссимистиче вывод эксперты делают более чем через двадцать л–евт ортачбеоттеы Федеральной счетной палаты 2015 года [ 15 ].

Итак, разработка DoDAF идет уже более 25 лет, но завершить ее никак не удается. Нап вывод, что сам замысел создания единойационнфноорйм систеым для столь сложного предпри,яктаикя Министерство обороны С,ШявАляется сегодня непосильной задачей или же сама методика разработки модели Захмана является ошибочной. 6.

Язык SysML Для упрощения работы с документацией единой инфноорймацсироенды для МО США требуются графические средства. За прошедшие годы апробированы различные средства. В итоге в графический язык SysML (System Modeling Language). Напомним его предысторию. Язык UML дав стал стандартом общения между участнриакзармаиботки программного обеспечения крупных проектов. Его богатые выразительные средства и широкий спектр поддерживающих продуктов способствов тому, что UML начал проникать в другие области деятельности, связанные с моделированием процессов. Исохдных средств языка UML оказалось недостаточно для моделирования аппаратур поэтому понадобилось добавить ряд новых графических элементов и диаграмм, которые позво описывать нюансы каждого элемента модели и взаимосвязи между элементами, заадатваактжье строго границы модели. С другой стороны, в рамках поставленной задачи UML характеризуется нек избыточностью, поэтому не все его элементы вошли в новый клон. Изменения были специфици виде профиля UML 2.0 и названы новым— SиyмsMенLе.м В ецспификацию этого языка вошли новые диаграммы — требований, внешних и внутренних блоков, времени, параметрическая. Кстати, на осн языка SysML был спроектирован орбитальный телескоп «Хаббл».

Критика DoDAF Разработка архитектуры DODAF длится уже 5боллееет, 2в ней участвуют тысячи разработчиков. В ходе разработки Министерство обороны многократно подвергалось критике за «пустую» трату д Новейший обзор состояния (на июль 2017 года) работ в области архитектуры предприятий [1 любопытное названеи «Структуры архитектуры предприятия: поветрие века». В обзоре утверждаетс исторический анализ показывает, что использование DoDAF в американском Министерстве обор обеспечивает "самый захватывающий пример непрерывно растущих затрат времени и денеж инвестиций в [архитектуру предприятия], но получение все тех же самых неудовлетворител результатов".

Одним из ярых критиков является Стивен Де–мм. ноСгаомлетонний разработчик архитектур C4ISR и DoDAF. Разработкой информационных систем для обоорторнанслоий занимается более 40 лет. Приводим рисунок из его презентации под названием «Нужна ли еще архитектура DODAF?» [ 17 ]. Н использованы обозначения: DОD–AаFрхитектура МО США, MO–DаAрFхитектура Британского МО, –NAF архитектура NATO (развернаяут в Афганистане), DN–DаAрFхитектура МО Канады.

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

Modeling Language)

Язык LML Язык Lifecycle Modeling Language (LML) является языком моделирования открытого станда разработанным для системных инженеров. Он поддерживает пиозлнненынйыйж цикл системы: от разработки концепции до ее замены новым продуктом. Спецификация была опубликована в 20 [ 18 ], руководство пользовате–люв 2014 г. [ 19 ].

Целью языка является замена я-зпырекдошвественников, таких как UML и SysML, комтнореныиею, по разработчиков LML, излишне усложняют процесс разработки системы–. этSоysMвL основном конструкции и имеет ограниченную онтологию, в то время как DoDAF MetaModel 2.0 (DM2) им онтологию. Вместо этого LML упрощает как конструкции,толтоагкию,и чтоонбы сделать их более полными, но и более удобными в использовании.

LML объединяет логические конструкции с онтологией для сбора информации. Существует толь первичных классов сущностей (primary entity classes). Устраняется один иозв нSеyдsMосLт–атк использование объектн-ориентированного подхода. SysML был разработан по методологии системного мышления программистов, однако, следует заметить, никакая другая дисциплина за все в жизненного цикла системы не пользуется о-боъреикетннтоированным подходом.

LML – это новый подход к анализу, планированию, определению, проектированию, созданию обслуживанию современных систем (рис. 9). LML фокусируется на шести целях: 1. Чтобы было легко понять 2. Легко расширить 3. Обеспечить поддержку как цифоуннакльного, так и объе-котрниоентированного подхода в рамках одного проекта

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

Рис. 9. Модели LML Онтология. Онтологии предоставляют набор определенных терминов и отношений между термин для сбора информациоип,исывающей физические, функциональные, рабочие и программные аспекты системы. Обычными способами описания таких онтологий являются три понятия: «Entity», «Relation и «Attribute» (ERA). Комплекс ERA часто используется для определения схе.м LMбаLзырасдшанинрыяехт схему ERA добавлением понятия"Attributes on Relationship" (атрибуты отношений), тем самым сокр количество требуемых «сущностей» в ERA. В соответствии с основной мыслью языка LML эт понятия: «Entity», «Relationship», «Attribuиte» «Attribute on Relationship» представляют собой эквивалентные элементы английского языка: существительное, глагол, прилагательное и наречие (n verb, adjective и adverb).

Сущность: Entity (noun). Сущность (entity) определяется как нечто уникиафлиьцниоруеимдоеент и может существовать сама по сLеMбLе.имВеется всего 12 родительских сущностей (parent entities): Action Artifact Asset Characteristic Connection Cost Decision Input/Output Location Risk Statement Time Определено несколько дочернсиухщностей для учета информации, необходимой пользователям. У дочерних сущностей в свою очередь имеются свои атрибуты и отношения к родителям дополнительные атрибуты и отношения, которые делают их уникальными. Среди дочерних сущност родительских усщностей назовем:

Conduit (от Connection) Logical (от Connection) Measure (от Characteristic) Orbital (от Location) Physical (от Location) Requirement (от Statement) Resource (от Asset) Virtual (от Location) Прилагательное: Attribute (adjective). Атрибуты используются наподобие прилагательных в обычном языке. Сущности (существительные) могут иметь имена, числа и атрибуты описания. Собстве характеристика или качество сущности является атрибутом. Каждый атрибут имеет имя, ко однозначно идентифиицрует его внутри сущности. Имена атрибутов уникальны внутри сущности, могут использоваться и в других сущностях. Имя дает обзор информации об атрибуте. Тип атрибута указывает на данные, связанные с этим атрибутом.

Отношение (глагол): Relationpshi (verb). Отношение работает так же, как– согелдаигноляет существительные или, другими словами, сущности. Отношения дают простой способ увидеть, сущности соединяются. Имена отношений уникальны по всей схеме LML.

Атрибуты отношений (наречие): Attributes on Relationships (adverb). Классическая модель ERA не имеют понятия «атрибуты отношений». Это есть существенное дополнение языковых сред Аналогично тому, как атрибуты относятся к сущностям, «атрибут отношения» имеет имя, уникаль его отношени,я но не должно быть уникальным для других отношений.

С языком LML можно ознакомиться по документу [ 20 ]. Разработчики заверяют, что LML транслировать в UML, SysML, DoDAF (DM2) и другие языки. На рис. 10 показано соответст концептуальной модеьлю DM2 и LML Schema.

Рис. 10. Соответствие между концептуальной моделью DM2 и LML Schema Уже первый открыто доступны инструмент для

первые внедрения средства нового разработки на –язIыnкnеoslaLteML[ 21 ]. Innoslate – это языка моделирования oLdiefelicnygclLeangMuage (LML). Innoslate объединяет программное обеспечение системного проектирования с требованиями управлен требованиями, анализом требований и инструментами совместной работы. Все это содержится в е решении. Innoslate, по замыслу, апврлеядест собой будущий стандарт моделирования сложных систем по подходу Mo-dBealsed Systems Engineering (MBSE). Innoslate – это облачное -впербиложение, разработанное новой компанией SPEC Innovations Выводы

Литература Об авторах: Шнепс-Шнеппе Манфред Александрович, доктор технических наук, профессор, генеральный директор компании ЦК-БАбаваНет, [e-mail] Сухомлин Владимир Александрович, доктор техничесикх наук, профессор, заведующий лабораторией открытых информационных технологий факультета вычислительной математики и кибернетики, Московский государственный университет имени М.В. Ломоносова; ведущий научный сотрудник, Федеральный исследовательский ц«еИннтфрорматика и управление» Российской академии наук, Президент Фонда «Лига -имнедтеиран»,еsт[e-mail] Намиот Дмитрий Евгеньевич, кандидат физ и-мкоатематических наук, старший научный сотрудник факультета вчыислительной математики и кибернетики, Московский государственный университет имени М.В. Ломоносdоnвaаm,[e-mail]

References

Programma Cifrovoj Jekonomiki http://d-russia.ru/wp-content/uploads/2017/05/programmaCE.pdf Retrieved: Aug, 2017 Sneps-Sneppe M. , Sukhomlin V. , Namiot D . On global information systems //International Journal of Open Information Technologies.

TAKTIChESKOE ZVENO ASUV « MANEVR »: 30 LET SPUSTJa http://otvaga2004.ru/kaleydoskop/k-ca4le/ ytadkotsikcohpeskoezveno-asuv- manevr- 30 - let-spustya/attachment/otvaga2004_manevr_13/ Retrieved: Aug, 2017 .

4. Jeskiznyj proekt Obshhegosudarstvennoj avtomatizirovannoj sistemy sbora i obrabotki informacii dlja ucheta, planirovanija i upravlenija narodnym hozjajstvom (OGAS ), 1980 .

5. ISO/IEC 8631: 1989 Information technology -- Program constructs and conventions for their representation

6. Andrey Terekhov , Timofey Bryksin, and Yurii Litvinov . How to make visual modeling more attractive to software developers http://laser .inf.ethz.ch/2014/material/terekhov/terekhov _report.pdf Retrieved: Aug , 2017

7. Carrelli , D.J. Roche . CCITT Languages for SCP Switching Systems// IEEE Trans. COMM , Vol. 30 , No 6 , June 1982 , pp. 1304 - 1309

8. J.A. Zachman ( 1987 ). " A Framework for Information Systems Architecture" . In: IBM Systems Journal , vol 26 , no 3.

9. J.F. Sowa and J. Zachman ( 1992 ). "Extending and Formalizing the Framework for Information Systems Architecture" In: IBM Systems Journal , Vol 31 , no. 3 , 1992 . p. 590 - 616 .

10. S. Karpenko . Primenenie modeli Zahmana dlja proektirovanija IT-arhitektury predprijatija . http://www.management.com.ua/ims/ims177.html Retrieved: Aug, 2017

11. The Chief Information Officers Council ( 1999 ). Federal Enterprise Architecture Framework, Version 1 .1. September 1999

12. GAO . 2002 . "Information Technology: Enterprise Architecture Use Across the Federal Government Can Be Improved," GAO-02-6 , Government Accountability Office, Washington, DC.

13. S.B. Gaver ( 2010 ) "Why Doesn't the Federal Enterprise Architecture Work?," Technology Matters, McLean, VA .

14. A.L. Lederer , and V Gardiner ( 1992 ). "Strategic Information Systems Planning: The Method/1 Approach," Information Systems Management (9:3) , pp. 13 - 20 .

15. GAO . 2015 . "DOD Business Systems Modernization: Additional Action Needed to Achieve Intended Outcomes," GAO-15-627 , Government Accountability Office, Washington, DC.

16. S. Kotusev . Enterprise Architecture Frameworks: The Fad of the Century" , British Computer Society (BCS), July 2016 http://www.bcs.org/content/conWebDoc/56347 Retrieved: Aug, 2017

17. Steven H. Dam . Do We Still Need a DoD Architecture Framework ? http://mpcog.com/lib/download/asin=1502757621&type=stream Retrieved: Aug, 2017

18. Lifecycle Modeling Language (LML) Specification 1.0 . October 2013 .

19. Steven H. Dam . DoD Architecture Framework 2 .0 - A Guide to Applying System Engineering to Develop Integrated, Executable Architectures . Published by SPEC Innovations , 2014

20. Steven H. Dam , Warren K. Vaneman . A New Open Standard: Lifecycle Modeling Language (LML) a Language for Simple, Rapid Development, Operations and Support, January 25 , 2014 http://cdn2.hubspot.net/hub/316256/file-493267217- pdf/LML_ Overview_for_Lifecycle_Management_WG-Dam_ and_Vaneman.pdf?t=1391103350000 Retrieved: Aug, 2017

21. Straightforward , powerful lifecycle management with Innoslate the complete product lifecycle management tool http ://www.systemsengineeringtool.com/innoslate/ Retrieved: Aug, 2017 Retrieved: Aug, 2017 .