АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
ГЛАВА 6. АРХИТЕКТУРНОЕ ПРОЕКТИРОВАНИЕ ИС 6.1. Архитектурный процесс в разработке ПО Архитектурный процесс описывает разработку проектного решения и является основным подпроцессом в Проектировании ПО (рис.6.1) и состоит из следующих задач [83]: Работа с командами сбора требований, которая сфокусирована на сборе требований от заказчика. Работа с различными заинтересованными сторонами. Архитектор должен гарантировать, что интересы каждой из сторон поняты и удовлетворяются проектным решением. Управление командой технического дизайна, которая может состоять из ведущих специалистов групп разработки, системных администраторов или других архитекторов (в крупных проектах). Взаимодействие с командой управления проектом. Архитектор тесно взаимодействует с командой управления проекта, помогая в декомпозиции, оценке и планировании работ по проекту. Для решения этих задач используется итеративный архитектурный процесс, состоящий из трех видов деятельности (рис. 6.1): Определение архитектурных требований, которые будут вести архитектурный процесс. Разработка проектного решения. Валидация (тестирование) проектного решения на удовлетворение всем требованиям. При выполнении работ в рамках архитектурного процесса важно руководствоваться следующими принципами [84]: Архитектурный процесс ведется на основе запросов от заинтересованных сторон, которые являются ядром процесса. При этом следует учитывать, что запросы могут противоречить друг другу и их следует согласовывать между собой. Должны поддерживаться эффективные коммуникации, в результате которых заинтересованные стороны имеют полное представление о принятых решениях и принципах. Архитектурные решения и принципы должны исполняться во время всего процесса разработки ПО. Архитектурный процесс должен быть структурированным, с описанием входа, выхода и шагов. Прагматичный подход к принятию решений – должны учитываться внешние факторы (время, нехватка денег и т.п.). Процесс должен быть достаточно гибкий, чтобы его можно было адаптировать к используемому процессу разработки. Процесс должен использовать лучшие практики и опираться на стандарты.  Рис. 6.1. Архитектурный процесс Определение архитектурных требований. Все архитектурные решения должны приниматься на основе зафиксированных и ранжированных по приоритету требований. В настоящее время организациями ISO и IEC ведут активные работы по разработке группы стандартов под общим названием Systems and Software engineering – Software product Quality Requirements and Evaluations (SQuaRE) (Системная и программная инженерия – Требования к качеству и оценка программного продукта). Серия стандартов SQuaRE включает целый ряд стандартов, краткое описание некоторых из них приведено в табл. 6.1. Таблица 6.1. Серия стандартов SQuaRE
В рамках данных стандартов качество системы определяется как степень удовлетворенности заинтересованных сторон. Эти потребности выражаются в терминах моделей качества, которые имеют иерархическую структуру. На верхнем уровне находятся характеристики, на следующем – подхарактеристики, на нижнем уровне – атрибуты, которые описывают численные значения подхарактеристик. Стандарт ISO/IEC 25010:2011. Это стандарт является ключевым в системе стандартов SQuaRE, поэтому рассмотрим его более подробно. В 2011 году стандарт ISO/IEC 9126-1: 2001 был заменен на стандарт ISO/IEC 25010: 2011 из серии стандартом SQuaRE, определяющих требования как к качеству ПО, так и к качеству ИС [85]. В стандарте ISO/IEC 25010: 2011 определены 2 модели качества: модель качества в использовании и модель качества самой системы (рис. 6.2). Модель качества в использовании. Эта группа качеств определяет степень применимости системы для удовлетворения потребностей пользователей в достижении их целей с определенной результативностью, свободой от риска и их удовлетворенностью в заданных контекстах. Эти показатели определяют как качество ПО, так и качество аппаратных средств. Модель качества в использовании (рис. 6.2) включает 5 характеристик, относящихся к человеко-машинному взаимодействию. Результативность (Effectiveness) – это полнота и точность, с которой достигаются цели пользователей. Эффективность (Efficiency) – ресурсы, которые требуется затратить в зависимости от полноты и точности, с которыми пользователь достигает цели. Удовлетворенность (Satisfaction) – степень удовлетворения потребностей пользователя при использовании системы или продукта в заданном контексте использования. В качестве подхарактеристик удовлетворенности выступают применимость (usefulness), доверие (trust), удовольствие (pleasure), комфорт (comfort).  Рис. 6.13. Модели качества Свобода от риска (Freedom from risk) – степень уменьшения потенциальных рисков, в частности, для человеческой жизни, здоровья, окружающей среды, а также для экономического статуса. В качестве подхарактеристик выступают уменьшение риска для здоровья и безопасности (health and safety risk mitigation), окружающей среды (environmental risk mitigation), уменьшение экономического риска (economic risk mitigation). Покрытие контекста (Context coverage) – степень применимости системы или продукта с результативностью, эффективностью, удовлетворенностей и свободой от риска определенных контекстах использования. В качестве подхарактеристик выступают полнота контекста (context completeness) и гибкость контекста (flexibility). Модель качества системы (продукта) включает 8 характеристик, относящихся к статическим и динамическим свойствам ИС. Данная модель может быть использована как применительно к ИС, так и программным системам. Функциональное соответствие (Functional suitability) – степень обеспечения системой или программным продуктом потребностей пользователя. В качестве подхарактеристик выступают функциональная полнота (functional completeness), функциональная правильность (functional correctness), фукциональная пригодность (functional appropriateness). Эффективность функционирования (Performance efficiency) – зависимость функционирования от количества таких используемых ресурсов как другие системы или продукты, программная и аппаратная конфигурация системы и т.д. В качестве подхарактеристик выступают поведение во времени (time behavior), использование ресурсов (resource utilization), емкость capacity). Совместимость (Compatibility) – степень способности системы или программного продукта обмениваться данными с другими системами или продуктами и способность системы или продукта взаимодействовать с другими системами и продуктами для решения задач пользователей. В качестве подхарактеристик выступают сосуществование (coexistence), способность к взаимодействию (interoperability). Удобство использования (Usability) – степень применимости системы или продукта для достижения пользователем целей с требуемой результативностью, эффективностью и удовлетворенностью в заданном контексте применения. В качестве подхарактеристик выступают распознаваемость пригодности (appropriateness recognizability), обучаемость (learnability), простота использования (operability), защита от ошибок пользователя (user error protection), эстетичность пользовательского интерфейса (user interface aesthetics) и доступность (accessibility). Надежность (Reliability) – степень выполнения системой или продуктом заданных функций в заданных условиях в течение заданного отрезка времени. В качестве подхарактеристик выступают зрелость (Maturity), готовность (availability), устойчивость к ошибкам (fault tolerance) и восстанавливаемость (recoverability). Защищенность (Security) – степень защиты системой или программным продуктом данных и разрешения доступа к ним в соответствии с типом и уровнем авторизации. В качестве подхарактеристик выступают конфиденциальность (confidentiality), целостность (integrity), неопровержимость (non-repudiation), идентифицируемость (accountability), аутентичность (authenticity). Сопровождаемость (Maintainability) – степень результативности и продуктивности модификаций системы или программного продукта, которые планируются персоналом, отвечающим за сопровождение системы или продукта. В качестве подхарактеристик выступают модульность (modularity), повторная используемость (reusability), анализируемость (analyzability), модифицируемость (modifiability) и тестируемость (testability). Переносимость (Portability) – степень результативности и эффективности переноса системы или программного продукта на другую программную или аппаратную платформу. В качестве подхарактеристик выступают адаптируемость (adaptability), простота установки (installability) и взаимозаменяемость (replaceability). Для того, чтобы учесть интересы и требования всех заинтересованных сторон на ранних стадиях, Институт SEI разработал метод Семинары Атрибутов Качества (QualityAttributeWorkshops, QAW) [86]. Семинары [87] – это интенсивное учебное мероприятие, на котором участники учатся, прежде всего, благодаря собственной активной работе. QAW ориентируется на проведение семинаров с количеством участников от 5 до 30 человек. Такого количества участников хватает для охвата всех заинтересованных сторон. В ходе проведения мероприятия участники должны совместными усилиями получить ответы на следующие вопросы: Какого точное значение атрибутов качества в контексте построения системы? Как Вы можете обнаружить, описать и приоритезировать ключевые атрибуты качества до того, как система будет создана? Какие есть возможности для организации взаимодействия между всеми заинтересованными лицами, даже если они географически разделены? Как вся эта информация может быть использована? Мероприятие проходит по следующему сценарию: Презентация QAW, введение в метод и мотивация его применения. Презентация бизнеса и миссии. Часовая презентация, в рамках которой до слушателей доносят контекст системы, ее связь с бизнесом/миссией компании; высокоуровневое описание требований, ограничений и атрибутов качества. Презентация существующего высокоуровневого описания архитектуры, планов и стратегий достижения бизнес-целей с помощью обсуждаемой информационной системы. Выявление архитектурных драйверов (архитектурный драйвер – комбинация функциональных и бизнес-требований, атрибутов качества, которая формирует архитектуру). По результатам активной работы участников должен быть получен согласованный окончательный список архитектурных драйверов. Мозговой штурм по поиску сценариев использования. Требуется, чтобы: сценарии были хорошо оформлены; для каждого архитектурного драйвера должен быть хотя бы один репрезентативный сценарий; каждое заинтересованное лицо должно предложить, как минимум, два сценария. Объединение сценариев. Все похожие сценарии объединяются, при этом заинтересованные лица приходят к консенсусу по поводу получившегося после слияния сценария. Сценарии приоритизируются путем голосования заинтересованных лиц. После приоритизации несколько самых важных сценариев (5 или 7) прорабатываются очень детально. В результате проведения семинара получаются следующие артефакты, которые в целом согласованы между всеми заинтересованными лицами: Список архитектурных драйверов. Исходные сценарии Приоритезированный список исходных сценариев. Проработанные сценарии. Разработка проектного решения (архитектуры). Любые проектные решения архитектора должны обосновываться требованиями, согласованными со списками заинтересованных лиц. При разработке решения, архитектор должен всегда рассматривать следующие ключевые моменты [88]: Одновременное выполнение задач (синхронизация, планирование задач по расписанию). Управление событиями. Хранение долго живущих данных. Схема размещения программных компонент на физических серверах. Управление ошибками и устойчивость к падению. Взаимодействие с пользователем и предоставление данных. Безопасность. Перед разработкой проектного решения полезно создать метафору системы, комплексно ее описывающей. Метафора может быть взята из любой предметной области – главное, чтобы она максимально соответствовала решению. Например, для системы обрабатывающей заявки с высокими требованиями к скорости, можно использовать метафору водопроводной системы. Для системы с требованиями к безопасности может подойти метафора крепости с воротами (элементами, в которых происходит обеспечение безопасности). Хорошая метафора значительно улучшает понимаемость архитектуры. Описать архитектуру с высокоуровневой точки зрения также помогает выбранный архитектурный стиль. Он задает общий принцип построения системы, накладывая на архитектурные элементы (компоненты) требования как по взаимодействию друг с другом, так и к логике работы. В высокоуровневое описание также включаются системы, которые будут взяты готовыми. Сюда входят как хранилища данных (например, использование только определенной СУБД), промежуточное (middleware) ПО, ОС так и специализированные средства для решения задач (например, готовая система управления содержимых сайтов). Для выбора сторонних специализированных систем, которые решают часть задач бизнес-логики приложения, в Мадридском университете им. Карлоса III предлагают метод «Магического кольца» (Magic Ring) [89]. Метод состоит из 7 шагов (рис. 6.3): Осведомленность. На этом шаге надо изучить кандидата на использование в систему в первую очередь с точки зрения предоставляемых им возможностей интеграции. Например, методы его программного интерфейса (API). Надо удостовериться, что кандидат действительно удовлетворяет нашим требованиям. Мотивация. При разработке информационной системы всегда есть главная цель. Кандидат должен рассматриваться как средство достижения этой цели и рассматриваться исключительно с этой точки зрения. Самоконтроль. Все выбираемые для включения в систему сторонние компоненты должны делать конкретную функцию, которую мы от них ожидаем. При этом они должны обеспечить ее надлежащим и изолированным от других подсистем способом. Партнерство. Оценка того, насколько кандидат хорошо подходит в качестве встраивания в систему. На данном шаге оценивается удобство применения API кандидата для решения задачи разрабатываемой информационной системы. Применяются метрики объектно-ориентированного дизайна – высокая сфокусированность (т.е. кандидат решает одну задачу) и низкая связность (интеграция с кандидатом будет простая и не потребует подключения других зависимостей). Посредничество. Оценивается, насколько кандидат совместим с нашей информационной системой. Проводится анализ как по данным (поддерживаем мы протокол взаимодействия, насколько подходит модель данных для решений нашей задачи) так и по программным интерфейсам. Существенно повышает оценку кандидата использования стандартов, наличие механизмов адаптации и расширяемости. Рефлексия. Кандидат оценивается по возможностям работать в различных условиях, гибкость его настройки к различным потребностям и конфигурациям. Помолвка. Кандидат больше не изолированный компонент. Он будет взаимодействовать и обмениваться информацией с другими компонентами ИС, но при этом очень важно, чтобы кандидат был хорошо задокументирован, поддерживался сообществом или разработчиком и был протестирован в различных сценариях. Если артефакт разработан и поддерживается коммерческой компанией нужно проверить её стабильность, опыт работы, положение на рынке и т.д. Данный метод позволяет получить экспертную оценку различных кандидатов на использование и включить их в систему. К сожалению, он не учитывает такой важный момент как опыт использования компоненты внутри компании разработчика. При относительно равных продуктах предпочтительнее выбрать тот, для которого накоплен опыт использования. Даже если конкурирующее решение имеет незначительные преимущества.  Рис. 6.14 Метод выбора ПО сторонних производителей Magic Ring После составления первого варианта высокоуровневого дизайна архитектуры необходимо осуществить более детальную проработку. При создании окончательного варианта архитектуры необходимо проработать ее элементы (подсистемы, компоненты) и удостовериться, что окончательный вариант удовлетворяет всем предъявляемым требованиям качества. Институт SEI предлагает метод attribute driven design [90] – дизайн, ведомый атрибутами. Метод является рекурсивным и подразумевает последовательную проработку элементов до нужной степени детализации. При этом каждый этап проработки заканчивается проверки соответствия решения на предъявляемые требования. Метод состоит из 7 шагов (рис. 6.4): Подтвердить полноты требований. На первом шаге происходит проверка списка требований. Все недостаточно проработанные или не имеющие приоритета требования возвращаются на доработку к заинтересованным лицам. Выбрать элемент для декомпозиции. Когда этот шаг выполняется первый раз, существует лишь один элемент для декомпозиции – вся система целиком. В ином случае стоит вопрос выбора элемента, который будет проработан. Следует обращать внимание на факторы: количество связей элемента с другими элементами (выбирать более связанные); насколько сложно провести анализ элемента и сколько рисков присутствует в этом элемент (выбирать более сложные, с большим количеством рисков); насколько элемент необходимо для поставки продукта, какую роль он играет в текущем релизе.  Рис.6.15. Метод attribute driven design Определить кандидатов в архитектурные драйвера. Выбираются требования, которые оказывают влияние на компонент. Для каждого требования дополнительно к приоритету от заинтересованных лиц ставится степень влияния на архитектуру. По полученным приоритетам выбирается 5-6 требований, которые имеют максимальную оценку по обеим параметрам. Выбранный требования называются «кандидаты в архитектурные драйвера». Дальнейший анализ может исключить некоторые выбранные кандидаты из архитектурных драйверов. Выбрать концепцию дизайна. Первоначально определяются ключевые нефункциональные требования к элементу (производительность, доступность, надежность и т.п.). Далее для каждого требования выбирается список способов его удовлетворения. В список могут входить архитектурные тактики имеющиеся на рынке решения, шаблоны реализации и т.д. Важно для каждого требования найти несколько способов. Далее составляется и заполняется таблица принятия решений, в которой каждый выбранный способ рассматривается с точки зрения каждого архитектурного драйвера (табл. 6.2). На основе анализа принимается решение о выбранных способах достижения ключевых требований и их документирование. Архитектурное описание содержит типы компонентов и связи между ними. Таблица 6.2. Таблица принятия решений
Выделить архитектурные элементы и распределить обязанности. Для каждого типа компонента выделяется один элемент реализации, которому назначается обязанности, учитывая функциональные требования и архитектурные драйвера. При этом требуется ответить на ряд таких вопросов, как: общее количество экземпляров компонента, запущенных в режиме выполнения, зависимости от других компонент, как будет происходит взаимодействие между компонентами и другие. Определить интерфейсы для выделенных компонент. На основе требований, архитектурных драйверов и обязанностей компонента, его элементам назначаются обязанности. Обязанности – это не просто список названий функций и их параметров, а также описание семантики операций, пред- и пост-условий, ограничений, обрабатываемой информации и т.д. Также указываются атрибуты качества (для каждой операции или всего элемента в целом). Верифицировать и уточнить требования, сделать их ограничениями для выделенных элементов. Проверка качества проделанной работы. Проверяется, что все поставленные перед элементом требования соблюдены, а все обязанности распределены между его компонентами. Валидация проектного решения (архитектуры). Список требований, упорядоченный по приоритетам, дает архитектору возможность оценивать различные варианты архитектуру по согласованным с заинтересованными лицами критериям. Самым сложным при разработке проектного решения является учет различных ограничений, которые накладывают требования к информационной системе и контекст ее поставки (сроки, бюджет, доступность сотрудников определенной квалификации и навыков и т.п.). Для сравнения и выбора наилучшего варианта были разработаны разнообразные методы оценки вариантов архитектурного решения. Выделяют четыре категории методов оценки [91]: Экспертная оценка – эксперт или консультант дает оценку архитектуре. Имитационное моделирование – может быть осуществлено на высокоуровневых прототипах системы. Может использоваться для оценки таких параметров качества как производительность, надежность, корректность. Математическое моделирование – может быть использовано для проверки производительности и надежности. На основе сценариев – архитектура проверяется путем воспроизведения (возможно, мысленного) различных сценариев. Хорошо подходит для проверки функциональных и нефункциональных требований. Методы оценки архитектуры на основе сценариев являются специфичными для деятельности по разработке архитектуры ИС и были специально разработаны для использования архитекторами ПО. Поэтому подробней будут рассмотрены именно они. Первым описанным методом был Метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM) [92]. Главным отличием от существующих подходов стал отказ от использования метрик объекто-ориентированного дизайна (сфокусированность, связность и т.п.) для оценки архитектур в пользу оценки на основе сценариев, а также ориентация не только на техническую сторону вопросу, но и социальную (организацию взаимодействия между заинтересованными лицами). Суть метода показа на рис. 6.5.  Рис. 6.16. Метод SAAM В дальнейшем метод SAAM был заменен на Метод анализа компромиссов архитектуры методом (Architecture Tradeoff Analysis Method, ATAM) [91]. Исходной предпосылкой метода является констатация факта наличия компромиссов в любой архитектуре - изменение в одном компоненте архитектуры могут затронуть качество другого компонентов или всей системы в целом. ATAM помогает идентифицировать такие зависимости между атрибутами и называет их «точками компромисса» (tradeoff points). Метод является итеративным и состоит из 6 шагов, разбитых на четыре фазы (рис. 6.6). Сбор сценариев – базовый для разработки архитектуры шаг, который заключается в построение приоритезированного списка сценариев от всех заинтересованных лиц. Сбор требований, ограничений и информации об окружении. Важно, что вся собранная информация должна в итоге быть представлена как набор атрибутов. Данный шаг выполняется на этапе сбора архитектурных требований. Описание архитектурного представления. Создается на основе требований, сценариев, информации об окружении и подходов к созданию архитектуры. Архитектура должна быть описана в понятиях архитектурных элементов, релевантных каждому важному атрибуту качества. Данный шаг выполняется на этапе разработки архитектурного решения. Анализ конкретных атрибутов. Для варианта архитектуры осуществляется определение значений атрибутов качества на основе выбранных сценариев. На данном шаге все атрибуты анализируется независимо друг от друга. Определение чувствительных точек. Все моделируемые значения, на которые значительно влияют изменения архитектуры, рассматриваются как чувствительные точки. Определение компромиссов. На данном шаге осуществляется критическая оценка построенной модели, при этом анализ осуществляется с точки зрения взаимного влияния друг на друга чувствительных точек (т.е. анализируются точки компромиссов).  Рис. 6.17. Метод ATAM 6.2. Компетенции архитектора ИС Каждая компания предъявляет свои требования к сотрудникам на различных ролях. Кроме того, понимание ролей может сильно различаться в разных организациях. Для создания единого понимания, что должен человек на той или иной позиции, и какие требования к нему предъявлять, разрабатывают фреймворки компетенций. Понятие компетенций трактуется достаточно широко, но на текущий момент базовой является модель Знания-Навыки-Возможности- Иное (Knowledge-Skills-Abilities-Others, KSAO) [93]. В рамках этой модели компетенция описывается как совокупность характеристик: Знания (Knowledge) – теоретическая подготовка, необходимая для решения задач. Навыки (Skills) – наблюдаемая компетенция выполнять обученные действия Возможности (Abilities) – выполнение наблюдаемого поведения, которое приводит к наблюдаемого продукту Другое (Others) – иные характеристики. Исследование «Компетенции архитекторов ИТ» (CompetenceofITArchitects. Требования к архитекторам были рассмотрены на основе архитектурного фреймворка выравнивания бизнес и его IT-составляющей GRAAL (Guidelines Regarding Architecture Alignment – рекомендации относительно выравнивания архитектуры) [94, 95]. Фреймворк предлагает описывать информационную систему на основе четырех ортогональных измерений: Системные аспекты – наблюдаемые снаружи свойства системы. В свою очередь они делятся на две группы: Службы (сервисы): поведение, взаимодействие, данные Метрики качества: как для пользователя (удобство использования, эффективность, безопасность и т.п.), так и для разработчиков (поддерживаемость, расширяемость и т.п.) Агрегация системы – построение системы из подсистем Время жизни системы – от концепции до отказа Уровни описания – от абстрактного (видениe) до уточненного, с подробным описанием. Помимо измерений, GRAAL вводит свои уровни архитектуры ИС относительно бизнеса. При этом на каждом уровне выделяется своя роль архитектора (табл. 6.3). Таблица 6.3. Роли архитектора
На основе архитектурного фреймворка и выделенных ролей, авторы GRAAL предлагают фреймворк компетенций архитекторов информационных систем. В табл. 6.4 приведены компетенция, необходимые для решения задач по разработке архитектуры ИС. Помимо этого, на основе результатов опросов крупных компаний, был также получен портрет архитектора ИС на основе психологической модели личности «Большая пятерка» (Big Five). В отличии от компетенций, Big Five позволяет оценить личностные характеристики человека по пяти характеристикам [85]: экстраверсия – интроверсия; привязанность – обособленность; самоконтроль – импульсивность; эмоциональная неустойчивость – эмоциональная устойчивость; экспрессивность – практичность. Таблица 6.4. Компетенции архитектора
В табл. 6.5 приведены сводные результаты тестирования по характеристикам. Таблица 6.5. Сводные результаты тестирования
В исследовании отмечается, что наиболее востребованными у архитекторов чертами характера являются: коммуникативность, умение работать в команде, умение мыслить абстрактно, аналитический склад ума и креативность. Также выделены два измерения, которые лучше характеризуют разные типы архитекторов: Мужской - женский стиль Мужской стиль – ориентирование на результат, решительность и убедительность; Женский стиль – командный игрок, который слушает других и проявляется эмпатию. Визионер – аналитик Архитектор – визионер — это мечтатель, который создает видение решения в крупных мазках; Архитектор – аналитик, который организованно и систематично прорабатывает решение до мелочей. Архитектурный фреймворк TOGAF консорциума Open Group, который будет подробно рассмотрен ниже, также содержит фреймворк компетенций. В нем выделены несколько крупных ролей, участвующих в разработке архитектуры ИС. Далее будут рассмотрены только роли Архитектора. Каждая роль соответствует одному из этапов проработки архитектуры в TOGAF ADM [96]: Корпоративный архитектор (Enterprise Architect) – роль, включающая в себя все остальные роли архитектора. Бизнес-архитектор – разработка бизнес архитектуры предприятия (управление бизнес-процессами), внедрение изменений. Согласованность целей IT-отделов и бизнеса. Архитектор данных – разработка структур данных Архитектор приложений – разработка приложений, обрабатывающих данные. Архитектор технологий – выбор технологического стека размещения приложений (сетевые технологии, общее программного обеспечение и т.п.). Особенностью фреймворка TOGAF является анализ только навыков и опыта. Навыки сгруппированы по областям: Общие навыки – управление, лидерство, коммуникации и т.д. Бизнес-навыки и методы – анализ и построение бизнес-кейсов, бизнес-процессов, стратегическое планирование и т.д. Навыки корпоративного архитектора – моделирование, определение компонент системы, приложений и ролей, интеграции и т.д. Навыки управления проектами. Общее знание ИТ – управление активами, планирование миграции, поддержка качества обслуживания и т.д. Технические навыки в ИТ – разработка и построение ПО, безопасность, управление датами, интеграция и т.д. Юридические навыки – знания законов о защите данных, навык составление контрактов и т.д. 6.3. Трудовые обязанности архитектора информационных систем Архитектор ИС всегда выполняет несколько бизнес-ролей (business roles). В свою очередь каждая бизнес-роль описывается ответственностью, трудовыми функциями (business function) и бизнес-процессами, которые она должна выполнять. В зависимости от процессов работы организации, обязанности Архитектора ИС могут сильно варьироваться. В Российской Федерации принят профессиональный стандарт Архитектор Программного обеспечения (Утвержден Приказом Минтруда России №228н от 11.04.2014). В стандарте описаны трудовые функции, а также умения и знания, которые необходимы для их успешного выполнения. При разработке стандарта был использован опыт Европейского союза и США. Профессиональный стандарт вводит три уровня квалификации Архитектора Программного Обеспечения, от 4 до 6. На 4-м, начальном, уровне Архитектор может создавать проектные решение, документировать их и планировать их реализацию группой работников. При этом деятельность осуществляется под общим руководством с самостоятельным решением практических задач. На 5-м уровне ожидается полная самостоятельность в работе, а также добавляются функции оценки требований к программному обеспечению, оценка и выбор архитектурного решения, выделение повторно используемых компонентов. Участие в разработке может сводится к контролю над реализациями. На 6-м, высшем уровне, Архитектор должен давать оценку возможности создания архитектурного проекта, определять цели и ключевые сценарии для архитектурного проекта. На данном уровне квалификации можно ожидать не просто технологический вариант размещение информационной системы, но и его технико-экономическое обоснование, включая сравнительный анализ нескольких вариантов. Отдельно выделяется модернизация программного обеспечение, внедрение новой системы взамен старой. Также Архитектор 6-го уровня квалификации осуществляет выбор средств и технологий разработки программного обеспечения. В табл. 6.6 приведен список обобщенных трудовых функций и соответствующий им уровень классификации. Таблица 6.6. Обобщенные трудовые функции и соответствующий им уровень классификации
Контрольные вопросы Покажите связь между моделями предприятия из GRAAL и приведенной в первой главе. Чем отличается экспертиза Архитектора приложений и Архитектора данных? Как можно наложить роли архитекторов из GRAAL на роли из TOGAF? Объясните, почему роль Бизнес-Архитектора требует общих знаний процесса и методологий разработки ПО. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||