Системный архитектор

Системный архитектор
	Системные архитекторы делят большие и сложные системы на управляемые подсистемы, которыми могут управлять отдельные инженеры.
Занятие
Имена	Системный архитектор
Тип профессии	Профессия
Секторы деятельности	Системная инженерия ; Системы ; Дизайн ; Инженерное дело
Описание
Компетенции	пользовательской знание области , научные знания, инженерные навыки, навыки планирования и управления
Требуется образование	См. образование

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

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

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

Обзор [ править ]

Системные архитекторы взаимодействуют с множеством заинтересованных сторон в организации, чтобы понять различные уровни требований, предметную область, жизнеспособные технологии и ожидаемый процесс разработки. Их работа включает в себя определение множества альтернатив проектирования и реализации, оценку таких альтернатив на основе всех выявленных ограничений (таких как стоимость, график, пространство, мощность, безопасность, удобство использования, надежность, ремонтопригодность, доступность и другие «функции» ) и выбор наиболее подходящие варианты для дальнейшего дизайна. Результаты такой работы определяют основные свойства системы и те, которые сложнее всего изменить в дальнейшем.

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

При проектировании систем архитекторы (и инженеры) несут ответственность за:

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

Системный архитектор: темы [ править ]

Архитектура больших систем была разработана как способ управления системами, слишком большими для того, чтобы один человек мог их представить, не говоря уже о проектировании. Системы такого размера быстро становятся нормой, поэтому для решения проблем больших и очень больших систем все чаще требуются архитектурные подходы и архитекторы. В общем, все более крупные системы уменьшаются до «человеческих» пропорций с помощью многоуровневого подхода, при котором каждый уровень состоит из ряда индивидуально понятных подуровней, каждый из которых имеет своего главного инженера и/или архитектора. Полный слой на одном уровне будет отображаться как функциональный «компонент» более высокого уровня (и может вообще исчезнуть на самых высоких уровнях).

Пользователи и спонсоры [ править ]

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

Архитекторы не следуют точным процедурам. Они общаются с пользователями/спонсорами высокоинтерактивным и относительно неформальным способом — вместе они извлекают истинные требования, необходимые для спроектированной (конечной) системы. Архитектор должен постоянно поддерживать связь с конечными пользователями и (главными) системными инженерами. Следовательно, архитектор должен быть хорошо знаком со средой и проблемой пользователей, а также с инженерной средой возможных пространств решения.

Требования высокого уровня [ править ]

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

Разработка первого уровня инженерных требований не является чисто аналитическим мероприятием и должна включать в себя как архитектора, так и инженера. Если необходимо пойти на какие-либо компромиссы (чтобы удовлетворить ограничения), архитектор должен гарантировать, что конечный продукт и общий внешний вид не отклоняются слишком далеко от намерений пользователей. Инженер должен сосредоточиться на разработке конструкции, которая оптимизирует ограничения, но обеспечивает работоспособный, надежный, расширяемый и надежный продукт. Предоставление необходимых услуг пользователям — это истинная функция инженерной системы. Однако по мере того, как системы становятся все более крупными и сложными, а их акцент отходит от простых аппаратных и программных компонентов, узкое применение традиционных принципов разработки систем оказывается недостаточным — применение более общих принципов систем, аппаратного обеспечения, и архитектура программного обеспечения для проектирования (под)систем являются необходимыми. Архитектуру также можно рассматривать как упрощенную модель готового конечного продукта: ее основная функция — определить части и их взаимоотношения друг с другом, чтобы целое можно было рассматривать как последовательное, полное и правильное представление того, что используют пользователи. имел в виду — особенно для компьютерно-человеческого интерфейса. Он также используется для обеспечения того, чтобы детали подходили друг к другу и взаимодействовали желаемым образом.

Необходимо различать архитектуру мира пользователей и архитектуру инженерных систем. Первый представляет и решает проблемы и решения в мире пользователя . В основном это фиксируется в компьютерно-человеческих интерфейсах (CHI) инженерной системы. Проектируемая система представляет собой инженерные решения — то, как инженер предлагает разработать и/или выбрать и объединить компоненты технической инфраструктуры для поддержки ОМС. В отсутствие опытного архитектора существует досадная тенденция путать две архитектуры. Но инженер думает с точки зрения аппаратного и программного обеспечения и пространства технических решений, тогда как пользователи могут думать с точки зрения решения проблемы доставки людей из точки А в точку Б за разумное время и с разумными затратами времени. энергии или предоставления необходимой информации клиентам и персоналу. Ожидается, что системный архитектор объединит знания как об архитектуре мира пользователей, так и о (всех потенциально полезных) инженерных разработках. системные архитектуры . Первое представляет собой совместную деятельность с пользователями; последнее является совместной деятельностью с инженерами. Продукт представляет собой набор требований высокого уровня, отражающих требования пользователей, которые могут быть использованы инженерами для разработки требований к проектированию систем.

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

Анализ затрат/выгод [ править ]

Архитекторы — универсалы. От них не ожидается, что они будут экспертами в какой-либо одной технологии, но ожидается, что они будут хорошо осведомлены о многих технологиях и смогут судить об их применимости в конкретных ситуациях. Они также применяют свои знания в практических ситуациях, но оценивают затраты/выгоды различных решений с использованием разных технологий (например, аппаратное обеспечение, программное обеспечение или ручное управление), и гарантируют, что система в целом работает в соответствии с ожиданиями пользователей.

Многие готовые к продаже или уже разработанные аппаратные и программные компоненты могут быть выбраны независимо в соответствии с такими ограничениями, как стоимость, отклик, пропускная способность и т. д. В некоторых случаях архитектор уже может собрать конечную систему (почти) без посторонней помощи. Или ему/ей может потребоваться помощь инженера по аппаратному или программному обеспечению для выбора компонентов, а также для проектирования и создания какой-либо функции специального назначения. Архитекторы (или инженеры) также могут заручиться помощью других специалистов — в области безопасности , защиты , связи , аппаратного обеспечения специального назначения, графики , человеческого фактора , тестирования и оценки , контроля качества , надежности , ремонтопригодности , доступности , интерфейсом управления и т. д. Команда эффективного системного архитектора должна иметь доступ к специалистам критически важных специальностей по мере необходимости.

Разделение и наслоение [ править ]

Архитектор, планирующий здание, работает над общим дизайном, следя за тем, чтобы оно было приятным и полезным для его жителей. Хотя одного архитектора может быть достаточно, чтобы построить дом на одну семью, кроме того, может потребоваться множество инженеров для решения детальных проблем, возникающих при проектировании нового высотного здания. Если работа достаточно большая и сложная, части архитектуры можно проектировать как независимые компоненты. То есть, если мы строим жилой комплекс, у нас может быть один архитектор на комплекс и по одному на каждый тип здания в составе архитектурной команды.

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

Архитектор должен распределить системные требования по основным компонентам или подсистемам, которые находятся в пределах компетенции одного инженера по аппаратному или программному обеспечению или инженерного менеджера и команды. Но архитектора ни в коем случае нельзя рассматривать как научного руководителя. (Если объект достаточно большой и/или сложный, главный архитектор передаст его части более специализированным архитекторам.) В идеале каждый такой компонент/подсистема представляет собой достаточно автономный объект, чтобы его можно было протестировать как законченный компонент. отдельно от целого, используя только простой испытательный стенд для моделирования входных данных и записи выходных данных. То есть не обязательно знать, как работает система управления воздушным движением, чтобы спроектировать и построить для нее подсистему управления данными. Необходимо только знать ограничения, при которых будет работать подсистема.

Хороший архитектор гарантирует, что система, какой бы сложной она ни была, построена на относительно простых и «чистых» концепциях для каждой (под)системы или уровня и будет легко понятна каждому, особенно пользователям, без специальной подготовки. Архитектор будет использовать минимум эвристики , чтобы гарантировать, что каждый раздел четко определен и очищен от ошибок , обходных путей , сокращений или запутанных деталей и исключений. По мере развития пользователей (после того, как система будет внедрена и использована), впоследствии будет намного проще разработать простую концепцию, чем ту, которая перегружена исключениями, особыми случаями и большим количеством «мелкого шрифта».

Многослойность архитектуры важна для того, чтобы архитектура оставалась достаточно простой на каждом уровне и оставалась понятной для одного человека. По мере подъема слоев целые системы на нижних уровнях становятся простыми компонентами на более высоких уровнях и могут вообще исчезнуть на самых высоких уровнях.

Приемочный тест [ править ]

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

Общение с пользователями и инженерами [ править ]

Архитектор здания использует эскизы, модели и чертежи. Архитектор систем автоматизации (или программного или аппаратного обеспечения) должен использовать эскизы, модели и прототипы для обсуждения различных решений и результатов с пользователями, инженерами и другими архитекторами. Ранняя черновая версия руководства пользователя имеет неоценимое значение, особенно в сочетании с прототипом. Тем не менее, важно создать работоспособный, хорошо написанный набор требований или спецификацию , которая будет достаточно понятна заказчику (чтобы он мог должным образом подписать ее, но требования основных пользователей должны быть зафиксированы в предварительной форме). руководство пользователя для разборчивости). Но он должен использовать точный и недвусмысленный язык, чтобы у дизайнеров и других разработчиков не оставалось сомнений относительно значений и намерений. В частности, все требования должны быть проверяемыми , а первоначальный проект плана тестирования должен разрабатываться одновременно с требованиями. Все заинтересованные стороны должны подписать описания приемочных испытаний или их эквиваленты как единственный фактор, определяющий удовлетворение требований в начале программы.

Метафора архитектора [ править ]

Использование любой формы слова «архитектор» регулируется «законами о праве собственности» во многих штатах США, и для его использования человек должен иметь лицензию строительного архитектора. ^[1]

В Великобритании совет по регистрации архитекторов исключает использование слова «архитектор» (при использовании в контексте программного обеспечения и информационных технологий) из своего ограниченного использования. ^[2]

См. также [ править ]

Ссылки [ править ]

^ Термин «архитектор» — это профессиональное звание, защищенное законом и доступное в большинстве юрисдикций мира только тем, кто обучен планированию, проектированию и надзору за строительством зданий . В этих юрисдикциях любому, кто не является лицензированным архитектором, запрещено использовать это название каким-либо образом . В штате Нью-Йорк, как и в других штатах США, несанкционированное использование звания «архитектор» является преступлением и подлежит уголовному преследованию . «Архитектура: что законно, что нет» (PDF) . AIA штата Нью-Йорк . Проверено 9 июля 2012 года . «Архитектура штата Нью-Йорк: Законы, правила и положения: Статья 147 «Архитектура»» . Проверено 9 июля 2012 года .
^ «Что мы делаем, чтобы регулировать использование титула «архитектор» » . Комиссия по регистрации архитекторов . Проверено 8 июля 2019 г.

Дальнейшее чтение [ править ]

Дональд Файерсмит и др.: Методическая основа для архитектуры инженерных систем (2008).
Марк В. Майер и Рехтин, Эберхардт, Искусство системного проектирования , третье издание (2009 г.)
Геррит Мюллер, «Системная архитектура: бизнес-перспектива», CRC Press, (2012).
Эберхардт Рехтин , Системное проектирование: создание и построение сложных систем , 1991.
Дж. Х. Зальцер , М. Ф. Каашук, Принципы проектирования компьютерных систем: введение , Морган Кауфманн, 2009.
Роб Уильямс, Архитектура компьютерных систем: сетевой подход , второе издание (декабрь 2006 г.).

Внешние ссылки [ править ]

Принципы проектирования компьютерных систем: введение – MIT OpenCourseWare
Системная архитектура: Canaxia привлекает к работе архитектора , статья

[1] Термин «архитектор» — это профессиональное звание, защищенное законом и доступное в большинстве юрисдикций мира только тем, кто обучен планированию, проектированию и надзору за строительством зданий . В этих юрисдикциях любому, кто не является лицензированным архитектором, запрещено использовать это название каким-либо образом . В штате Нью-Йорк, как и в других штатах США, несанкционированное использование звания «архитектор» является преступлением и подлежит уголовному преследованию . «Архитектура: что законно, что нет» (PDF) . AIA штата Нью-Йорк . Проверено 9 июля 2012 года . «Архитектура штата Нью-Йорк: Законы, правила и положения: Статья 147 «Архитектура»» . Проверено 9 июля 2012 года .

[2] «Что мы делаем, чтобы регулировать использование титула «архитектор» » . Комиссия по регистрации архитекторов . Проверено 8 июля 2019 г.

[1]

[2]