Процесс проектирования архитектуры

 

5.5.4.1 Цель процесса проектирования архитектуры

 

Цель процесса проектирования архитектуры состоит в синтезе решения, которое бы удовлетворяло системным требованиям.

 

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

 

5.5.4.2 Результаты процесса проектирования архитектуры

 

В результате успешного осуществления процесса проектирования архитектуры:

 

a) устанавливается порядок, в соответствии с которым выполняется проектирование архитектуры;

 

b) задается реализуемый набор описаний системных элементов, которые удовлетворяют требованиям, предъявляемым к системе;

 

c) включаются в решение по проектированию архитектуры требования к интерфейсу;

 

d) устанавливается связь между проектированием архитектуры и системными требованиями;

 

e) определяется основа для верификации системных элементов;

 

f) устанавливается основа комплексирования системных элементов.

 

5.5.4.3 Деятельность в процессе проектирования архитектуры

 

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

 

a) определять приемлемые проекты логической архитектуры.

 

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

 

 

b) выполнять декомпозицию функций системы, определенных в процессе анализа требований, и поставить им в соответствие элементы архитектуры системы, сформировать производные требования, необходимые для такого сопоставления;

 

c) анализировать итоговый проект архитектуры с целью установления проектных критериев для каждого элемента.

 

Примечание - Проектные критерии включают физические, эксплуатационные, поведенческие характеристики, характеристики надежности и устойчивости. Обычно процессы определения требований правообладателей, анализа требований и проектирования архитектуры рекурсивно применяются для последовательной детализации системной архитектуры до тех пор, пока элементы не смогут быть созданы, приобретены, повторно использованы или реализованы с помощью стандарта (например, Изменение N 1 к ИСО/МЭК 12207 для программных средств);

 

 

d) определять, какие системные требования должны выполняться операторами.

 

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

 

1) ограниченные возможности человека;

 

2) ограничения, обусловленные действиями человека, которые могут привести к аварийной ситуации, а также ограничения, обусловленные тем, как может повлиять на ситуацию определенная последовательность человеческих ошибок;

 

3) особенности, связанные с интеграцией эргономических характеристик человека в системы и их совместным функционированием.

 

 

Руководство по человеко-ориентированным процессам проектирования для интерактивных систем представлено в [13];

 

e) определять, доступны ли в готовом виде те элементы технического и программного обеспечения, которые удовлетворяют проектным и интерфейсным критериям.

 

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

 

 

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

 

Примечание - К данному действию относятся:

 

1) оценка и сообщение о появлении неблагоприятных свойств системы, обусловленных взаимодействием потенциальных системных элементов или в результате изменений в элементах системы;

 

2) гарантии того, что ограничения обеспечивающих систем приняты в расчет в данном проекте;

 

3) проведение оценок результативности, анализа компромиссных решений, анализа рисков, которые приводят к разработке выполнимого, эффективного, стабильного и оптимизированного проекта;

 

 

g) определять и документировать области взаимодействия между системными элементами и области взаимодействий на границе системы с внешними системами.

 

Примечание - Определение проводится с той степенью детализации и контроля, которая соответствует созданию, использованию и обеспечению целостности системы. При этом сторонами, ответственными за взаимодействие с внешними элементами, осуществляется документирование интерфейсов. Интерфейсы типа "человек-система" и "человек-человек" также определяются и контролируются. Определения интерфейсов должны соответствовать конкретному производственному сектору или международным стандартам, в которых они присутствуют, например, [10] - для интерфейса "человек-компьютер" или [2] - для семиуровневой модели взаимодействия открытых систем при передаче данных;

 

 

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

 

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

 

 

i) вести документальный учет информации по проектированию архитектуры.

 

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

 

 

j) поддерживать взаимосвязь и взаимозависимость между архитектурой и системными требованиями.