Архитектурой системы называют структуру компонентов, их отношений, а также принципов и руководств, регулирующих их проектирование и развитие во времени.
Системная архитектура отражает утвержденные системные требования. Она содержит наиболее важные стратегические реализационные решения, изобретения, инженерные компромиссы. В процессе разработки архитектуры формируется набор представлений, как система будет удовлетворять системным требованиям, все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Архитектура системы может включать функции, характеристики, технологию, оценку стоимости, риски, ограничения, границы системы, и т. д. Перечень функций затрагивает используемые в эксплуатации входные и выходные данные, сценарии использования, циклические процессы, функциональные требования, приоритеты. Поведение компонентов является частью архитектурного описания.
Архитектуры можно классифицировать в соответствии с отношениями между функциональными и физическими компонентами инновационных продуктов:
Интегральная архитектура характерна функциональной взаимозависимостью между компонентами, при этом каждая функция может выполняться несколькими компонентами, а также компонентами, исполняющими несколько функций. Она плохо подходит для поддержки разнообразия продуктов. Но для простых изделий, которые производятся в больших объемах, интегральная архитектура может позволить упростить спецификацию (например, шариковые ручки, одноразовые бритвы, и т.д.) и тем самым способствовать разнообразию продуктов.
Модульная архитектура отличается функционально независимыми компонентами, каждый из них отвечает за реализацию одной функции, и каждая функция выполняется одним компонентом. Модульная архитектура будет секционной, если интерфейс между каждой парой взаимосвязанных компонентов стандартизован. В модульной архитектуре компоненты могут соединяться друг с другом не напрямую, а через общий компонент (называемый шиной) и с использованием стандартного интерфейса.
На базе модульной архитектуры фирмы разрабатывают «платформенные системы», в которых общая платформа позволяет быстро разрабатывать производные продукты, отвечающие конкретным потребностям рынка. Компоненты, специфичные для производных, могут быть разработаны без необходимости перепроектирования основных и «внутриплатформенных» компонентов. Так создают семейства автомобилей, смартфонов, и др.
Вариант реализации гибкости заключается в глубокой цифровизации продукции. При этом продукт сформирован в виде «компьютера с периферией», поведение и функции которого зависят от программного обеспечения, которое будет запускаться на той же аппаратной платформе. Для этого производителю нужно оценить выбор между стоимостью продукта и гибкостью, поскольку изделие со встроенными функциональными резервами обеспечит большую гибкость, но будет более дорогим в производстве.
Архитектурное разнообразие открыто для обновлений с целью улучшения локализованных характеристик (например, установка жесткого диска большей емкости в компьютерную систему); надстроек или дополнений компонентов, придающих продукту новые функции (например, добавление внешнего источника освещения на видеокамеру); замены компонентов с целью расширения спектра действий продукта (например, сменные объективы в фотоаппаратах); адаптации компонентов для работы продукта в различных условиях (например, адаптер для питания устройства от сети переменного тока или в автомобиле).
Примером универсального модуля многочисленных электронных гаджетов может служить разъем для смартфонов USB-C, где объединен ряд функций:
A. Симметричный овальный разъем можно подключать в любой ориентации, для удобства применения функций интерфейса USB.
B. Имеются альтернативные режимы для объединения нескольких интерфейсов, включая стандартные спецификации передачи данных USB, и множество технологий и спецификаций работы в альтернативных режимах, когда контакты разъема передают данные по другим протоколам.
C. Реализована двунаправленная зарядка, которая может передавать энергию до 100 Вт. При этом устройство с портом USB-C может питать подключенное устройство, либо получать энергию от подключенного устройства для собственной зарядки.
D. Добавлено преобразование цифрового сигнала в аналоговый. В ряде смартфонов нового поколения отказались от разъемов для наушников, чтобы разместить другое аппаратное обеспечение. Пользователи могут использовать наушники со штатным разъемом 3,5 мм на своих смартфонах, подключив их через адаптер порта USB-C.
Модульная архитектура также упрощает использование стандартных компонентов, что приводит к очевидным преимуществам за счет экономии масштаба производства и снижения сложности. Иногда эти преимущества будут уравновешены дополнительными затратами, поскольку необходимость выбора среди ограниченного набора стандартных компонентов может приводить к завышению размеров по отношению к потребностям конкретного применения.
В зависимости от степени разделения работ между производителями конечного продукта и поставщиками принято различать уровни разработки продуктов «черного» и «белого ящика». В первом случае производитель конечной системы вообще не затрагивает внутреннюю работу компонентов, а ограничивается определением и тестированием значимых функций и характеристик. При разработке «белого ящика» производитель имеет прямое влияние на разработку компонентов и владение соответствующей технологией.
При проектировании архитектуры системы нужно учитывать сложную сеть взаимоотношений между функциональными элементами. Разработчику придется объединять компоненты в модули, которые относительно независимы друг от друга, и внутри которых могут проявляться существенные взаимозависимости. Варианты могут включать функциональные элементы, объединяемые одним потоком (без разветвления на другие функциональные элементы), либо организовать ветвление в потоке, когда каждая ветвь должна быть назначена отдельным модулям. Элементы, функцией которых является преобразование и передача материала, энергии или информации, обычно размещают в одном и том же модуле.
Архитектура не является единой структурой. Она определяет основные части системы и то, как эти части будут взаимодействовать друг с другом, чтобы удовлетворить общие системные требования. Определения архитектуры не уточняют, что представляют собой компоненты. При формировании архитектуры можно использовать диаграммы, наброски, рисунки, таблицы, и другие наглядные материалы для выражения пожеланий будущих пользователей. Например, в одном из стандартов имеется более 50 разделов по типам описаний архитектуры.
Верхний уровень требований к системе формируют на базе обобщенных результатов маркетинговых исследований будущей инновации. Эти данные включают выбор концепции эксплуатации, архитектуры системы, требования, включая запросы заказчика и производные (альтернативы функций, распределение требований). Также учитывают пожелания возможного заказчика.
Требованием называют утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо, а также необходимо для приемки продукта или процесса, согласно стандарту ISO/IEC 29148 «Разработка требований».
Есть несколько причин, зачем нужны требования:
Требования определяют цель программы, например, чтобы предложить хороший продукт на рынок и получить прибыль от реализации проекта.
Требования определяют, что система должна делать, и управляют ее развитием.
Требования определяют ограничения, связанные с реализацией проекта, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства, и т. д.
Требования не являются спецификациями. Они определяют функции, характеристики системы, и задачи в части окружающей среды. Распространенной ошибкой является чрезмерное ограничение проектирования путем указания ненужных барьеров для творчества архитекторов и инженеров при выполнении проекта.
Посредством требований уточняются формулировки или характеристики продукта или системы, которые разработчик хочет или должен получить. В системных требованиях учитывают запросы заинтересованных сторон, то есть производителей, поставщиков, операторов и других лиц. Сюда входят корпоративные клиенты, заинтересованные в рынке будущей системы, низких эксплуатационных и капитальных затратах; операторы системы, заинтересованные в ее производительности, долговечности, надежности, наличии запасных частей; пользователи, которые заботятся о комфорте, безопасности и удобстве использования. Эти стороны, в конечном счете, будут использовать систему, извлекать из нее выгоду, управлять, поддерживать в рабочем состоянии, влиять на нее или подвергаться ее воздействию.
Заявленные требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированы, а иногда и противоречивы по своему характеру. Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать, преобразуя внешние требования клиентов во внутренние требования разработчиков. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Вовлечение клиентов на как можно более раннем этапе определения требований способствует значительному сокращению циклов разработки и переделок, а также гарантирует, что требования, выданные клиентами, являются полными, последовательными и понятными для производителя. Документ формирует технический лидер, и он утверждается менеджером программы.
Далее выполняют преобразование требований заказчика в требования верхнего уровня проекта. Они сгруппированы по конкретным направлениям. Требования к системе и характеристикам формирует технический лидер. Промышленные требования верхнего уровня в части производственных и испытательных требований составляет управляющий производством. Требования к процессам и проектам верхнего уровня, где рассматривают процессы управления проектом, качество и требования к закупкам, входят в зону работы менеджера команды разработки.
На основе согласованных требований верхнего уровня инженерные группы каскадно формируют документы на требования, необходимые и понятные исполнителям рабочих пакетов и поставщикам. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать в проекте или программе для удовлетворения потребностей клиентов, и корпоративных контрактов ОКР.
Требование определяет одну или несколько характеристик продукта и уровни их достижения, необходимые для достижения конкретной цели (например, функция, которую необходимо выполнить, уровень производительности, который должен быть достигнут, а также ограничения по максимальной массе или размеру продукта) для данного набора условий.
Спецификация системных требований определяет требования, которым должна удовлетворять система, подсистемы, аппаратное обеспечение, компонент или другой физический элемент. Обычно используется в качестве основы для приобретения, проектирования и разработки, верификации и валидации системы, подсистемы или другого элемента.
Спецификация требований к программному обеспечению определяет требования, которым должен удовлетворять каждый элемент ПО. Используется в качестве основы для закупки, проектирования, проверочного и приемочного тестирования элемента программного обеспечения.
Спецификация требований к интерфейсу (глава 3.6) определяет требования, которые должны быть удовлетворены на интерфейсе между двумя элементами (аппаратно-аппаратное, аппаратно-человеческое, аппаратно-программное или программное обеспечение). Используется для поддержки закупок, проектирования, проверочных и приемочных испытаний одного или обоих элементов интерфейса.
Удобно классифицировать требования по видам, для дальнейшего использования:
1. Требования потребителя определяют ожидания потребителя или заинтересованной стороны от продукта или системы с точки зрения их эксплуатации, целей, функций, производительности, среды и ограничений. Определяются согласно подтвержденным потребностям целевых клиентов в течение всего жизненного цикла продукта.
2. Функциональные требования определяют, какие функции необходимо выполнить для достижения целей продукта при его использовании. Они соответствуют основным функциям и сервисам функционального анализа, и полностью характеризуют необходимые операции или задачи, которые должен выполнять продукт (что, когда, и как).
3. Нефункциональные требования, не связаны с выполнением какой-либо задачи или конкретной функции, но определяют характеристики и свойства, которыми должна обладать система, например, технические требования безопасности ИТ (конфиденциальность, целостность), производительность и доступность в соответствии с определенными критериями. В них входят, такие особенности, как совместимость (способность подсистем интегрироваться в целую систему или среду), общность использования компонента взаимозаменяемо с существующим, но другим типом компонента, экономическая эффективность как общая стоимость системы для достижения заданного уровня выгоды, ремонтопригодность как легкость, с которой ее можно отремонтировать, тестируемость или как система может быть систематически испытана и измерена на предмет ее рабочих характеристик, готовность как статус ожидаемой готовности работы системы при обращении пользователя, удобство использования или оценка навыков, обучения или способностей, необходимых для работы и обслуживания системы, устойчивость как способность системы выжить в условиях воздействия возмущений и сбоев.
4. Требования к производительности определяют, насколько хорошо продукт или система должен выполнять свои функции, измеряемые с точки зрения количества, качества, охвата, сроков или готовности. Эти требования также назначаются системным элементам (подсистемам и компонентам) посредством процессов каскадирования и распределения сверху вниз. Например, функция тормозной системы автомобиля может быть определена как способность остановить транспортное средство на дистанции 35 м от начальной скорости 100 км/ч на ровной сухой дороге при внешней температуре 20° C и усилии нажатия на педали тормоза 30 кг.