Системы архитектор является информационно-коммуникационными технологиями профессионально. Системные архитекторы определяют архитектуру компьютеризированной системы (т. Е. Системы, состоящей из программного и аппаратного обеспечения) для выполнения определенных требований . Такие определения включают в себя: разбивку системы на компоненты, взаимодействия компонентов и интерфейсы (в том числе со средой, особенно с пользователем), а также технологии и ресурсы, которые будут использоваться при ее проектировании и реализации.
Занятие | |
---|---|
Имена | Системный архитектор |
Тип занятия | Профессия |
Сферы деятельности | Systems Engineering Systems Design Engineering |
Описание | |
Компетенции | знания пользовательской области , научные знания, инженерные навыки, навыки планирования и управления |
Требуется образование | Посмотреть образование |
Работа системного архитектора должна избегать проблем с реализацией и легко допускать непредвиденные расширения / модификации на будущих этапах. Из-за большого опыта, необходимого для этого, системный архитектор, как правило, является очень старшим технологом, обладающим значительными, но общими знаниями в области аппаратного обеспечения, программного обеспечения и аналогичных (пользовательских) систем. Прежде всего, системный архитектор должен быть достаточно осведомлен в области опыта пользователей (то есть архитектор системы воздушного движения должен быть более чем поверхностно знаком со всеми задачами системы воздушного движения, включая задачи всех уровни пользователей).
Обзор
Системные архитекторы взаимодействуют с множеством заинтересованных сторон в организации, чтобы понять различные уровни требований, предметную область, жизнеспособные технологии и ожидаемый процесс разработки. Их работа включает определение множества альтернатив проектирования и реализации, оценку таких альтернатив на основе всех выявленных ограничений (таких как стоимость, график, пространство, мощность, безопасность, удобство использования, надежность, ремонтопригодность, доступность и другие «проблемы» ) и выбор наиболее подходящие варианты для дальнейшего оформления. Результат такой работы устанавливает основные свойства системы и те, которые труднее всего изменить позже.
В небольших системах архитектура обычно определяется непосредственно разработчиками. Однако в более крупных системах необходимо назначить системного архитектора, который будет определять общую систему и взаимодействовать между пользователями, спонсорами и другими заинтересованными сторонами с одной стороны и инженерами с другой. Очень большие и очень сложные системы могут включать в себя несколько архитекторов, и в этом случае архитекторы работают вместе, чтобы интегрировать свои подсистемы или аспекты, и подчиняться главному архитектору, ответственному за всю систему. В общем, роль архитектора заключается в том, чтобы действовать как посредник между пользователями и инженерами, согласовывая потребности и требования пользователей с тем, что инженеры определили как выполнимые в рамках заданных (инженерных) ограничений.
При проектировании систем архитекторы (и инженеры) несут ответственность за:
- Взаимодействие с пользователем (ами), спонсором (ами) и всеми другими заинтересованными сторонами для определения их (развивающихся) потребностей.
- Генерация требований к системе наивысшего уровня , основанная на потребностях пользователей и других ограничениях.
- Обеспечение того, чтобы этот набор требований высокого уровня был последовательным , полным, правильным и оперативно определенным .
- Выполнение анализа затрат и выгод, чтобы определить, какие требования лучше всего удовлетворяются с помощью ручных, программных или аппаратных функций; максимально использовать коммерческие готовые или уже разработанные компоненты .
- Разработка алгоритмов разделения (и других процессов ) для распределения всех текущих и прогнозируемых требований по дискретным разделам таким образом, чтобы между разделами и между пользователями и системой требовался минимум обмена данными .
- Разделение больших систем на (последовательные уровни) подсистем и компонентов, каждый из которых может обрабатываться одним инженером или командой инженеров или подчиненным архитектором.
- Взаимодействие с инженерами по проектированию и внедрению и архитекторами, чтобы любые проблемы, возникающие во время проектирования или реализации, могли быть решены в соответствии с фундаментальными концепциями дизайна, а также потребностями и ограничениями пользователей.
- Обеспечение разработки максимально надежной и расширяемой конструкции.
- Создание набора требований к приемочным испытаниям вместе с дизайнерами, инженерами по тестированию и пользователями, которые определяют, что все высокоуровневые требования были выполнены, особенно для интерфейса компьютер-человек .
- Создание продуктов, таких как эскизы , модели , руководство пользователя и прототипы, чтобы пользователи и инженеры постоянно были в курсе последних событий и согласовывали систему, которая будет предоставляться по мере ее развития.
- Обеспечение того, чтобы все архитектурные продукты и продукты с архитектурным вводом поддерживались в самом актуальном состоянии и никогда не позволяли серьезно отставать или становиться устаревшими.
Системный архитектор: темы
Архитектура больших систем была разработана как способ работы с системами, слишком большими для понимания одним человеком, не говоря уже о проектировании. Системы такого размера быстро становятся нормой, поэтому архитектурные подходы и архитекторы все чаще требуются для решения проблем больших и очень больших систем. В общем, все более крупные системы уменьшаются до «человеческих» пропорций за счет многоуровневого подхода, когда каждый уровень состоит из ряда индивидуально понятных подслоев, каждый из которых имеет своего главного инженера и / или архитектора. Полный слой на одном уровне будет показан как функциональный «компонент» более высокого уровня (и может полностью исчезнуть на самых высоких уровнях).
Пользователи и спонсоры
Архитекторы которые должны понимать потребности человека и развиваются по- человечески функциональных и эстетически приятны продукции. Хороший архитектор также является основным хранителем видения конечного продукта пользователями, а также процесса выработки требований и реализации этого видения.
Архитекторы не соблюдают точных процедур. Они общаются с пользователями / спонсорами очень интерактивным, относительно неформальным способом - вместе они определяют истинные требования, необходимые для разработанной (конечной) системы. Архитектор должен постоянно поддерживать связь с конечными пользователями и (главными) системными инженерами. Следовательно, архитектор должен быть хорошо знаком с пользовательской средой и проблемой, а также с инженерной средой (ями) вероятных пространств решений.
Требования высокого уровня
Спецификация требований пользователя должна быть совместным продуктом пользователей и архитектора: пользователи приносят свои потребности и список желаний, архитектор приносит знания о том, что может оказаться выполнимым в рамках затрат, времени и других ограничений. Когда потребности пользователей переводятся в набор требований высокого уровня, это также лучшее время для написания первой версии приемочного теста , который после этого следует строго поддерживать в соответствии с требованиями. Таким образом, пользователям будет абсолютно ясно, что они получают. Это также защита от непроверяемых требований, недоразумений и сползания требований.
Разработка первого уровня инженерных требований не является чисто аналитическим упражнением, и в нем также должны участвовать как архитектор, так и инженер. Если необходимо пойти на какой-либо компромисс - для соблюдения ограничений - архитектор должен убедиться, что конечный продукт и общий внешний вид не слишком сильно расходятся с намерениями пользователей. Инженер должен сосредоточиться на разработке проекта, который оптимизирует ограничения, но гарантирует работоспособный, надежный, расширяемый и устойчивый продукт. Предоставление необходимых услуг пользователям - истинная функция спроектированной системы. Однако по мере того, как системы становятся все более крупными и сложными, а акцент в них отходит от простых аппаратных и программных компонентов, узкое применение традиционных принципов разработки систем оказалось недостаточным - применение более общих принципов систем, аппаратного обеспечения, и архитектура программного обеспечения для проектирования (под) систем считается необходимой. Архитектуру также можно рассматривать как упрощенную модель готового конечного продукта - ее основная функция состоит в том, чтобы определять части и их отношения друг к другу, чтобы можно было видеть в целом последовательное, полное и правильное представление того, что пользователи 'имел в виду - особенно для интерфейса компьютер-человек. Он также используется для обеспечения того, чтобы части соответствовали друг другу и соотносились друг с другом желаемым образом.
Необходимо различать архитектуру пользовательского мира и архитектуру инженерных систем. Первый представляет и рассматривает проблемы и решения в мире пользователя . Это в основном фиксируется в компьютерно-человеческом интерфейсе (CHI) спроектированной системы. Спроектированная система представляет собой инженерные решения - то, как инженер предлагает разработать и / или выбрать и объединить компоненты технической инфраструктуры для поддержки ОМС. В отсутствие опытного архитектора возникает досадная тенденция путать две архитектуры. Но - инженер думает в терминах аппаратного и программного обеспечения и пространства технических решений, тогда как пользователи могут думать в терминах решения проблемы доставки людей из точки А в точку Б за разумное время и с разумными затратами энергии, или предоставления необходимой информации клиентам и персоналу. Ожидается, что системный архитектор объединит знания как об архитектуре пользовательского мира, так и об (всех потенциально полезных) архитектурах инженерных систем . Первый - это совместная деятельность с пользователями; последнее - совместная деятельность с инженерами. Продукт представляет собой набор требований высокого уровня, отражающих требования пользователей, которые могут использоваться инженерами для разработки требований к системному проектированию.
Поскольку требования развиваются в ходе проекта, особенно длительного, архитектор необходим до тех пор, пока система не будет принята пользователем: архитектор гарантирует, что все изменения и интерпретации, сделанные в ходе разработки, не ставят под угрозу точку зрения пользователей.
Анализ затрат и выгод
Архитекторы универсалы. От них не ожидается, что они будут экспертами в какой-либо одной технологии, но от них ожидается знание многих технологий и способность судить об их применимости в конкретных ситуациях. Они также применяют свои знания в практических ситуациях, но оценивают затраты / выгоды различных решений с использованием различных технологий, например, аппаратное или программное обеспечение по сравнению с ручным, и гарантируют, что система в целом работает в соответствии с ожиданиями пользователей.
Многие готовые к продаже или уже разработанные аппаратные и программные компоненты могут быть выбраны независимо в соответствии с такими ограничениями, как стоимость, время отклика, пропускная способность и т. Д. В некоторых случаях архитектор уже может собрать конечную систему (почти) без посторонней помощи. Или ему / ей может потребоваться помощь инженера по аппаратному обеспечению или программному обеспечению для выбора компонентов, а также для разработки и создания какой-либо специальной функции. Архитекторы (или инженеры) могут также заручиться помощью других специалистов - в области безопасности , защиты , связи , специального оборудования, графики , человеческого фактора , тестирования и оценки , контроля качества , надежности , ремонтопригодности , доступности , управления интерфейсами и т. Д. Команда эффективных системных архитекторов должна иметь доступ к специалистам критических специальностей по мере необходимости.
Разделение и расслоение
Архитектор, планирующий здание, работает над общим дизайном, чтобы он был приятен и полезен его обитателям. В то время как одного архитектора может быть достаточно, чтобы построить дом на одну семью, может потребоваться много инженеров, кроме того, для решения детальных проблем, возникающих при проектировании нового высотного здания. Если работа достаточно большая и сложная, части архитектуры могут быть спроектированы как независимые компоненты. То есть, если мы строим жилой комплекс, у нас может быть один архитектор для комплекса и по одному для каждого типа здания в составе архитектурной группы.
Большие системы автоматизации также требуют архитектора и большого инженерного таланта. Если спроектированная система является большой и достаточно сложной, системный архитектор может передать часть работы архитектору оборудования и / или архитектору программного обеспечения, хотя все они могут быть членами совместной архитектурной группы.
Архитектор должен распределить системные требования по основным компонентам или подсистемам, которые находятся в сфере компетенции одного инженера по аппаратному обеспечению или программному обеспечению, или технического менеджера и группы. Но архитектор никогда не должен рассматриваться как технический руководитель. (Если элемент достаточно большой и / или сложный, главный архитектор распределит части между более специализированными архитекторами.) В идеале каждый такой компонент / подсистема является достаточно автономным объектом, чтобы его можно было протестировать как полный компонент. отдельно от целого, используя только простой испытательный стенд для моделирования входов и записи выходных данных. То есть не обязательно знать, как работает система управления воздушным движением, чтобы спроектировать и построить для нее подсистему управления данными. Необходимо только знать ограничения, при которых предполагается, что подсистема будет работать.
Хороший архитектор гарантирует, что система, какой бы сложной она ни была, построена на относительно простых и «чистых» концепциях для каждой (подсистемы) или уровня и легко понятна всем, особенно пользователям, без специальной подготовки. Архитектор будет использовать минимум эвристики для того , чтобы каждый раздел четко определен и очистить от кладжи , обходных , коротких разрезов или запутанных деталей и исключений. По мере развития потребностей пользователей (после того, как система введена в эксплуатацию и используется), впоследствии будет намного проще разработать простую концепцию, чем концепцию, нагруженную исключениями, особыми случаями и большим количеством мелкого шрифта.
Многослойная архитектура важна для того, чтобы архитектура оставалась достаточно простой на каждом уровне, чтобы она оставалась понятной для одного человека. По мере подъема на уровни целые системы на более низких уровнях становятся простыми компонентами на более высоких уровнях и могут полностью исчезнуть на самых высоких уровнях.
Вступительный тест
Приемка является главной обязанностью архитектора систем. Это главное средство, с помощью которого руководитель программы докажет пользователям, что система соответствует первоначальному плану и что все задействованные архитекторы и инженеры достигли своих целей.
Общение с пользователями и инженерами
Строительный архитектор использует эскизы, модели и чертежи. An автоматизация системы (или программный или аппаратное обеспечение) архитектор должен использовать эскизы, модель и прототип для обсуждения различных решений и результатов с пользователями, инженерами и другими архитекторами. Ранняя, черновая версия руководства пользователя неоценима, особенно в сочетании с прототипом. Тем не менее, важно, чтобы был создан работоспособный, хорошо написанный набор требований или спецификаций , которые были бы разумно понятны заказчику (чтобы они могли должным образом подписаться на нем, но основные требования пользователей должны быть отражены в предварительном порядке). руководство пользователя для наглядности). Но он должен использовать точный и недвусмысленный язык, чтобы дизайнеры и другие разработчики не сомневались в значениях или намерениях. В частности, все требования должны быть тестируемыми, и первоначальный проект плана тестирования должен разрабатываться одновременно с требованиями. Все заинтересованные стороны должны подписать описания приемочных испытаний или их эквиваленты в качестве единственного фактора, определяющего соответствие требованиям, в самом начале программы.
Метафора архитектора
Использование любой формы слова «архитектор» регулируется «законами о праве собственности» во многих штатах США, и для его использования человек должен иметь лицензию строительного архитектора. [1]
В Великобритании комиссия по регистрации архитекторов исключает использование «архитектора» (когда оно используется в контексте программного обеспечения и информационных технологий) из его ограниченного использования. [2]
Смотрите также
- Архитектура предприятия
- Архитектор предприятия
- Аппаратная архитектура
- Анализ требований
- Архитектура программного обеспечения
- Программная инженерия
- Системная архитектура
- Системное моделирование
- Системная инженерия
- Системный дизайн
- Бизнес-аналитик
- Фреймворк сервис-ориентированного моделирования (SOMF)
Рекомендации
- ^ Термин «архитектор» - это профессиональное название, охраняемое законом и ограниченное, в большинстве юрисдикций мира, для тех, кто обучен планированию, проектированию и надзору за строительством зданий . В этих юрисдикциях любому, кто не является лицензированным архитектором, запрещено каким-либо образом использовать это название. В штате Нью-Йорк и других штатах США несанкционированное использование названия «архитектор» является преступлением и подлежит уголовному преследованию . «Архитектура: что законно, а что нет» (PDF) . AIA штата Нью-Йорк . Проверено 9 июля 2012 года .«Архитектура штата Нью-Йорк: законы, правила и положения: Архитектура, статья 147» . Проверено 9 июля 2012 года .
- ^ «Что мы делаем, чтобы регулировать использование названия« архитектор » » . Регистрационная комиссия архитекторов . Проверено 8 июля 2019 .
дальнейшее чтение
- Дональд Файресмит и др .: Структура методов для архитектур инженерных систем , (2008)
- Марк В. Майер и Рехтин, Эберхард, Искусство системного проектирования , третье издание (2009 г.)
- Геррит Мюллер, «Системная архитектура: бизнес-перспектива», CRC Press, (2012).
- Эберхард Рехтин , Системное проектирование: создание и построение сложных систем , 1991.
- Дж. Зальцер , М. Ф. Каашук, Принципы проектирования компьютерных систем: Введение , Морган Кауфманн, 2009.
- Роб Уильямс, Архитектура компьютерных систем: сетевой подход , второе издание (декабрь 2006 г.).
Внешние ссылки
- Принципы проектирования компьютерных систем: введение - MIT OpenCourseWare
- Системная архитектура: Canaxia привлекает архитектора на борт , статья