CC BY
39О ПРИМЕНЕНИИ ФРЕЙМВОРКА XAF ДЛЯ ОРГАНИЗАЦИИ ПРОЕКТНОЙ ДЕЯТЕЛЬНОСТИ СТУДЕНТОВ НА КАФЕДРЕ
Тишина Е.А.
Тишина Евгения Алексеевна - бакалавр системного анализа и управления, студент магистратуры, кафедра стратегического планирования и методологии управления, Национальный исследовательский ядерный университет «МИФИ»,
г. Москва
Аннотация: в данной статье приведено обоснование необходимости архитектуры для команд проектов, которые осуществляются на кафедре, описаны требования к архитектурному подходу и обоснованы возможность и способ применения фреймворка XAF (Extreme Architecture Framework).
Ключевые слова: архитектурный фреймворк, архитектура предприятия, организация, кафедральный проект, экстремальный фреймворк.
Введение
Практическая направленность обучения и вовлечение учащихся в проектную деятельность является на сегодняшний день одной из приоритетных задач современного образования, о чем свидетельствуют стратегии развития государств и программы развития образования. Так, одной из задач в Британской цифровой стратегии является поддержка студенческих стартапов и создание условий для формирования класса студентов-новаторов [1]. Другим примером является программа развития 5 - 100, где одним из ключевых показателей эффективности является количество студентов и аспирантов, занятых в малых инновационных предприятиях [2].
Ключевой особенностью проектной деятельности студентов является отсутствие либо малый опыт работы участников в проектах. При этом привлечение студентов к проектной деятельности часто происходит на младших курсах, когда уровень профессиональных навыков относительно невысок, вследствие чего овладение инструментами управления проектами и знаниями для выполнения задач приводит к большим временным затратам, чем ожидается от студентов. И тогда большинство из них теряют интерес, не зная с чего начать. Отсюда появляется задача упростить для студентов начало работы в проектной группе. Одним из ее решений может стать наличие типовой архитектуры, принятой в виде некоторого шаблона, что позволит быстрее создать интегрированное описание для таких организаций, составленное с различных точек зрения.
Требования к архитектурному фреймворку
Архитектурный фреймворк, который может быть выбран в качестве типового, должен, на наш взгляд, удовлетворять следующим требованиям:
• Простота описания - схема архитектуры должна выглядеть так, чтобы можно было однозначно и легко понять, как устроена организация. В случае, где сотрудники организации, то есть участники проектной группы, практически не имеют опыта такой деятельности, чем проще решение, тем лучше (при условии соответствия другим требованиям).
• Гибкость в применении - возможность встраивания деятельности разных проектных групп в один фреймворк, то есть создание и использований множества описаний конкретной организации - команды проекта на основе одного фреймворка.
• Доступность инструментальной среды, реализующей фреймворк либо возможность создания описания в стандартных прикладных программах, например, Microsoft Word, Microsoft Office Visio.
Требование доступности инструментальной среды, в свою очередь, включает в себя:
o Возможность легко найти ссылку для скачивания среды в Интернете.
o Бесплатную либо установку программы, либо возможность использования демо-версии.
• Возможность четко обозначить зону ответственности участников проектной группы: архитектурная модель должна давать участникам проекта ясное понимание того, с каким компонентом архитектуры связана их работа.
Что такое XAF?
Фреймворк XAF (Extremely Architecture Framework или Extreme Enterprise Framework) был разработан австралийскими консультантами Филом Робинсоном и Флорисом Гоутом. В его основу легли следующие стандартные фреймворки [3]:
• Фреймворк Захмана [4], который признан одним из лучших фреймворков для архитектуры предприятия. Представление XAF в виде матрицы отражает влияние данного фреймворка.
• NIST [5] является одним из самых ранних подходов для описания архитектуры организационно-технических систем и оказал сильное влияние на многие последующие фреймворки. Его влияние отражено в архитектурных представлениях (architectural views), принятых в XAF в качестве матричных столбцов.
• TOGAF [6] представляет собой общую методологию архитектуры предприятия, которая делает сильный акцент на совместимости между системами. Влияние данного фреймворка на XAF отражено в выборе систем - матричных строк.
Общее представление фреймворка (рис. 1) выглядит следующим образом:
Activity Information Software Data Technology
Sector
Enterprise
Process
Application
Component
Рис. 1. Фреймворк XAF
Основной для XAF идеей является то, что организация представляет собой совокупность систем человеческой деятельности и программного обеспечения [7]:
• Отрасль (industry sector, sector) - система взаимодействующих предприятий, все из которых занимаются схожим типом деятельности.
• Предприятие (enterprise) - это совокупность индивидов, выполняющих систематические и целенаправленные действия в поддержку четко определенной миссии.
• Бизнес - процесс (process) - это «последовательность действий, которые на выходе создают ценность для потребителей процесса» [8].
• Программное приложение (software application, application) - это механизм для упаковки и физической реализации набора функций программного обеспечения.
• Программный компонент(СотропеП) - часть программного обеспечения, которая легко может быть заменена другой частью программного обеспечения и потенциально может быть повторно использована во множестве разных приложений.
Как уже было указано выше, под влиянием фреймворка NIST в XAF были приняты следующие архитектурные представления:
• Архитектура деятельности(Айт1у): описание процессов и потоков работ на уровне предприятия.
• Информационная архитектура (Information): описывает информацию, которая требуется для обеспечения процессов, описанных в архитектуре деятельности (Activity).
• Архитектура ПО (Software): содержит описание программного обеспечения, которое необходимо для поддержки деятельности (Activity) и обеспечения информации(1п£эгтайоп).
• Архитектура данных (Data): содержит описание логической и физической структуры хранилищ данных, поддерживаемых ПО.
• Технологическая архитектура (Technology): содержит описание технической среды, в которой работает ПО.
Каждая ячейка таблицы используется для размещения архитектурного контента. Например, [9]:
• Ячейка на пересечении строки Sector и столбца Activity содержит то, что описывает действий, осуществляемых внутри отрасли.
• Ячейка на пересечении строки Process и столбца Data содержит то, что описывает данные, связанные с бизнес - процессом.
• Ячейка на пересечении строки Application и столбца Software содержит то, что описывает требования для конкретной прикладной программы.
Робинсон и Гоут также предлагают пример более развернутого представления фреймворка с характеристикой каждого элемента ячеек таблицы, что можно увидеть во множестве публикаций, посвященных XAF. В данной статье отметим только то, что при заполнении таблицы допускается группирование ячеек таблицы.
Типичным архитектурным контентом, который размещается в ячейках матрицы, может быть:
• Виденье некоторого желаемого, будущего состояния архитектурного элемента и связанного с ним элементов предприятий: виденье должно описывать, какой вклад будущее состояние будет вносить в стратегию и цели бизнеса. Например, виденье того, что данные будут легко передаваться между различными видами деятельности. Такое виденье могло бы применяться одинаково ко всем бизнес - процессам.
• Основополагающий принцип, связанный с архитектурным элементом: принцип -краткое утверждение, которое определяет или ограничивает некий аспект архитектурного элемента. Принципы, как правило, определяют фундаментальные аспекты архитектуры, которые нечасто меняются или корректируются. Принципы, которые определяют разработку и реализацию архитектуры, также могут быть указаны. Например, принципы минимизации избыточности данных и дублирования или принцип осуществления ввода данных в начале сбора данных. Опять же эти принципы были бы одинаково применимы ко всей информации и требованию к хранилищу.
• Стратегия или направление деятельности для достижения желаемого, будущего состояния архитектурного элемента: например, стратегия облегчения передачи данных между бизнес-операциями путем интеграции программных приложений с использованием топологии «звезда».
• Модель, список или определение, описывающее элементы. Например, список ключевых бизнес - процессов, глоссарий с определениями ключевых бизнес - целей, которые относятся к отрасли либо UML - модель, описывающая программу управления системой.
• Оценка либо SWOT - анализ текущего состояния элемента предприятия. Например, оценка качества данных, связанных с бизнес - процессом, или SWOT -анализ пользовательского интерфейса существующей программы управления системой. Оценки могут также относиться к потенциальным рискам и выгодам, связанным с текущим состоянием элемента предприятия.
• Потенциальный риск, связанный с элементом предприятия.
• Потенциальная выгода, связанная с элементом предприятия.
Сами авторы также называют XAF экстремальным, потому что, во-первых, архитектура предприятия окружена крайностями. В одной из крайностей, строители корпоративных соборов, стремящиеся к идеалу. В другой крайности, строители хаотических трущоб, которые берут первое, что попалось в руки. Робинсон и Гоут [3] приводят, таким образом, метафоричное сравнение между собором, трущобами и скромным загородным домом, который является «серединой» и представляет собой наиболее привлекательную альтернативу двум другим крайностям. Этот самый дом является символом самодостаточности, осуществимости и прагматизма - тех качеств, которые больше подходят для современного предприятия, чем изобилие и порядок кафедральных соборов или бедность и хаос, имеющие место в трущобе. И для такого предприятия нужен фреймворк «среднего пути», который дает упорядоченное, но при этом не излишне усложненное представление системы. В качестве такого авторы и предлагают экстремальный архитектурный фреймворк. Во - вторых, XAF, по мнению Робинсона и Гоута, включает в себя лучшие аспекты других фреймворков.
Почему XAF?
Для ответа на этот вопрос вернемся к требованиям к фреймворку, сформулированным в настоящей статье, и свойствам самого фреймворка.
Первое требование - простота описания. XAF вполне соответствует данному требованию, поскольку его описание основано на простой матрице размером пять на пять. Тело матрицы может при этом быть заполнено лишь 18 архитектурными элементами. Заполненная матрица предлагает целостное представление предприятия, и, глядя на нее, легко понять взаимосвязь и взаимодействие между элементами в смежных ячейках и увидеть влияние изменений. При этом многие архитектурные фреймворки, напротив, громоздки и сложны для описания. Так, документация для TOGAF версии 8 составляет 313 страниц и содержит множество сложных диаграмм.
Однако здесь может возникнуть вопрос: «Почему мы не выбираем непосредственно Захмана, который является и простым для описания, и знаком практически всем студентам курса архитектуры предприятия (либо другой смежной дисциплины)?». Да, модель Захмана действительно является описанием одного из самых простых «стандартно читаемых» фреймворков и включает в себя всего лишь одну модель. Однако фреймворк Захмана обнаруживает такие недостатки в применении на практике как:
• Затруднения, связанные с пониманием архитектурных представлений, которые основаны на организационных ролях: планировщик, владелец, конструктор, проектировщик, разработчик. В то время как архитектурные представления, заимствованные из NIST и принятые впоследствии в других фреймворках, в том числе и XAF, на практике оказываются проще для понимания.
• Фреймворк Захмана определяет не менее чем 36 моделей, размещенных в разных ячейках таблицы. В то время как при использовании XAF можно группировать ячейки и создать достаточно полное описание системы из 18 архитектурных элементов. Отсутствие правила, связанного с созданием большого числа детальных моделей при описании позволяет создать общий, состоящий из меньшего числа элементов шаблон, который будет подходить для разного типа архитектурного контента, что в, свою очередь, делает фреймворк XAF более гибким в применении и таким образом обеспечивает соответствие второму требованию - гибкость в применении.
Таким образом, исходя из приведенных утверждений, получается, что XAF выигрывает перед моделью Захмана как и по простоте описания, так и по гибкости применения.
Следующее требование - доступность инструментальной среды. Поскольку выбранный для рассмотрения фреймворк реализован в виде таблицы, создание которой возможно за счет использования стандартных прикладных программах (например, программы Microsoft Office), то можно утверждать, что данное требование выполняется. Если говорить о средствах описания архитектурного контента для ячеек таблицы, то это опять же могут быть стандартные приложения для создания текстовых документов либо CASE - средства для создания моделей, например, на языке UML, среди которых есть и бесплатные, и имеющие демоверсию.
И последнее требование - обозначение зон ответственности участников проекта. Данное требование также выполняется при использовании XAF, поскольку данный фреймворк:
• Позволяет обозначить зоны ответственности отдельных групп.
• Позволяет обозначить зоны совместной ответственности за счет группирования ячеек таблицы.
• Дает представление о том, где нужна кооперация участников, занятых разной деятельностью. Например, пересечение строки компонента(Сотропей) и столбца архитектуры данных может отображать взаимодействие разработчиков и администраторов данных.
Исходя из вышесказанного, фреймворк XAF полностью удовлетворяет сформулированным нами требованиям и имеет преимущества в сравнении с другими фреймворками. Поэтому мы выбираем XAF.
XAF как архитектурный подход при разработке проектной документации
Чтобы показать возможность применения фреймворка XAF для команды проектов, состоящей из студентов, мы взяли в рассмотрение группу студентов, которые заняты в кафедральном проекте и должны разработать документацию к системе.
Такой выбор основан на нашем опыте выполнения задания по созданию документов для верификации и валидации программно-аппаратного комплекса системы управления нательными видеорегистраторами. Работу организации трудно назвать успешной ввиду следующих взаимосвязанных причин:
• Низкой вовлеченностью участников.
• Непониманием участниками, что и как они должны сделать при создании конкретного документа.
• «Пробелами» в исходных данных. Например, отсутствие альтернативных сценариев работы программы управления системой нательных видеорегистраторов.
• Неправильным подходом к управлению изменениями, о которых стало известно не непосредственно при их появлении, а во время очной консультации по вопросам функционирования программно - аппаратного комплекса.
Все вышеуказанные недостатки работы проектной группы не могут не заставить задуматься о создании целостного описания такой организации, которое может впоследствии быть использовано в качестве шаблона на аналогичных проектах кафедры. Поэтому мы решили предложить архитектуру такой проектной группы с использованием фреймворка XAF, выбор которого был обоснован нами в настоящей статье. Для нашей организационно-технической системы мы взяли вариант данного фреймворка, который Робинсон и Гоут предлагают в своих работах1 (рис. 2).
1 Мы не стали приводить определения архитектурных элементов, поскольку их можно увидеть практически в любой публикации по ХАТ и это не является основной целью нашей работы.
41
Activity Information Software Data Technology
Sector Subject Areas Information Requirements
Enterprise Activities Workflow Functional Areas Business Objects
Process
Application Use Cases Interface Requirements Functional Requirements Non-Functional Requirements Storage Requirements Networks Platforms Frameworks
Component User Interface Architecture Code Test Cases Schemas
Рис. 2. Вариант XAF, предложенный авторами
Таблица 1. Архитектура проектной группы
Activity Information Software Date Technology
Sector • Разработ ка • Исходные данные: • Текстовые редакторы • Виды проектной
Enterprise
документов o Целевая • Средства документаци
• Проверка модель системы создания таблиц и
документов o Описание от • CASE - • Роли
• Утвержд заказчика средства участников:
ение o ТЗ • Программы o Автор
документов o Презентация для облачной o Лицо,
• Утвержд o Сценарии работы с осуществляю
ение работы системы документами щее проверку
изменений (основные и • Почтовые и
альтернативные) программы согласование
o Список документа
документов, o Пользова
которые нужно тель ПК
разработать документа Internet
• Дополнитель • Права Облачное
Process ная информация доступа к хранение
об изменениях документам: документов
• Шаблоны o Чтение
документов o Чтение и
• Критерии сохранение
проверки o Чтение,
документов сохранение и
• Процедурны редактирован
е правила ие
проверки и • Сроки
создания согласования
документов документов и
• Требования к утверждения
версионировани изменений
ю документов
• Создание • Требования к • Описание • Требован
документа интерфейсам функций ия к
• Редактир редакторов прикладных хранению
ование документов программ в версий
документа • Требования к справочных/ документов
• Добавлен интерфейсу обучающих версий
ие облачного материалах документов
примечаний хранилища • Требования • Требован
в документ документа к расширению ия к
• Удалени • Требования к документов разграничени
Application е документа интерфейсу • Ограничени ю доступа к
• Загрузка почтовых я объема документам
документа - программ документов для • Ограниче
вложения загрузки ния объема
при отправке вложения при хранилища
• Отправка отправке/ данных
документа загрузки в
• Просмот облачное
р,загрузка хранилище
документа на
ПК
• Интерфейс редакторов • Код, на о Структур
документов котором а хранения
• Интерфейс почтовых написаны: документов в
программ o Текстовые сетевой папке
• Интерфейс облачного редакторы о Структур
хранилища документов o Средства а документов
создания таблиц в облачном
Component o CASE -средства o Программы для облачной работы с документами o Почтовые программы хранилище о Топологи я сети рабочих ПК
При применении данного фреймворка к группе, занимающейся созданием проектной документации, была создана архитектура, указанная в табл. 1.
Таким образом, нами была показана возможность применения фреймворка XAF к команде кафедрального проекта и дано конкретизированное под задачу организации видение архитектуры, которое может, во-первых, использоваться при выполнении аналогичных заданий, во-вторых, как конкретный пример применения, который упростит студентам понимание данного архитектурного подхода.
Список литературы
1. The digital sectors - making the UK the best place to start and grow a digital business/UK Digital Strategy. [Электронный ресурс], 1 March 2017. Режим доступа: https://www.gov.uk/government/publications/uk-digital-strategy/3-the-digital-sectors-making-the-uk-the-best-place-to-start-and-grow-a-digital-business./ (дата обращения: 28.05.2017).
2. План мероприятий по реализации программы повышения конкурентоспособности («дорожная карта») федерального государственного автономного образовательного учреждения высшего профессионального образования «Национальный исследовательский ядерный университет «МИФИ» на 2013-2020 годы (1 этап - 2013 - 2014 годы). [Электронный ресурс]. Москва, 2013. Режим доступа: https://mephi.ru/upload/road_map.pdf/ (дата обращения: 28.05.2017).
3. Robinson Ph. and Gout F., 2007.Chapter II: Extreme Architecture Framework: A Minimalist Framework for Modern Times.Handbook of Enterprise Systems Architecture in Practice, Edited By: Pallab Saha, IGI Global. P. 18-38.
4. Zachman J., 1987. A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26. № 3: P. 276-292.
5. Fong E.N. and Goldfine A.H., 1989. Information management directions: The integration challenge. National Institute for Standards and Technology (NIST).
6. The Open Group, 2003. The Open Group architecture framework (TOGAF). Version 8. Enterprise Edition, San Francisco, California: The Open Group. Retrieved July 18, 2003.
7. Phil Robinson and Floris Gout, March 2006. XAF: A Minimalist EA Framework for an Agile Environment. Cutter IT Journal. Vol 19. № 3: P. 16-25.
8. Hammer M. and Champy J., 2003. Reengineering the Corporation: A Manifesto for Business Change. Harper Collins.
9. Robinson Ph. and Gout F., Winter 2004. Extreme Architecture - Part 2. Architecture Components. Oracle Scene. Issue 20: P. 35-38.
