ar-net.ru a) определять функциональные границы системы в терминах ее поведения и свойств, которые должны быть обеспечены.
Примечание - К ним относятся входные воздействия на систему, а также реакция системы на действия пользователя и поведение внешней среды, анализ и описание взаимодействий между системой и средой относительно интерфейсных ограничений, например, механических, электрических, весовых, температурных, а также ограничений материальных и информационных потоков. Таким образом, устанавливается ожидаемое поведение системы, выраженное в количественных показателях, а также границы их допустимых значений;
b) определять каждую функцию, которую система должна выполнять, насколько хорошо система, включая операторов, должна выполнять эту функцию, условия, при которых система способна выполнять данную функцию и при которых система начинает и прекращает ее выполнение.
Примечание - Условия выполнения функций могут содержать ссылки на состояния и требуемые режимы функционирования системы. Системные требования сильно зависят от абстрактных представлений о подходящих характеристиках системы и могут включать многочисленные методы и виды моделирования для достаточно полного описания заданных системных требований;
c) определять необходимые ограничения по изготовлению системы и ее элементов, которые обусловлены требованиями правообладателей или неизбежными ограничениями, связанными с принятием решений.
Примечание - К ним относятся решения по созданию системы, принятые при проектировании на более высоких уровнях системной иерархии;
d) определять технические показатели и показатели качества при использовании, позволяющие оценивать технические достижения.
Примечание - При этом оцениваются критические параметры функционирования системы, связанные с каждым показателем результативности, соответствующим принятым требованиям правообладателей. Критические показатели функционирования анализируются и проверяются для подтверждения удовлетворения требований заказчика и для определения стоимости проекта, проектных графиков или эксплуатационных рисков, связанных с любыми несоответствиями. В [21] описаны процессы установления, определения и использования соответствующих показателей. Показатели качества для программных средств могут быть взяты из [6]-[9];
e) устанавливать системные требования и функции, в соответствии с которыми определяются риски и критические параметры системы, связанные с такими свойствами, как здоровье, безопасность, защищенность, безотказность, готовность, а также со свойствами обеспечивающих систем.
Примечание - Эти действия включают анализ и определение мер безопасности, в том числе имеющих отношение к способам функционирования и сопровождения, воздействиям окружающей среды и ущербу для жизни и здоровья персонала. Сюда же относится анализ каждой функции, связанной с обеспечением безопасности, а целостность этих функций, выраженная в показателях необходимого снижения риска, задается и распределяется по заданным системам безопасности. Также необходимо использовать стандарты, относящиеся к функциональной безопасности, например [19], и защите окружающей среды, например [14]; анализировать меры по защите, в том числе связанные с защитой секретной информации, данных и материалов; определять риски, связанные с защищенностью: административные, кадровые, физические, компьютерные, коммуникационные, сетевые и др.; определять риски, связанные с вредными излучениями и вредным воздействием на окружающую среду, и использовать соответствующие стандарты по защите;
f) анализировать целостность системных требований для обеспечения уверенности в том, что каждое требование, пары требований или наборы требований обладают системной целостностью.
Примечание - Каждое положение проверяется для установления его уникальности, полноты, непротиворечивости, совместимости с другими требованиями, реализуемости и проверяемости. Недостатки, противоречия и "узкие" места определяются и устраняются в рамках полного набора системных требований. Окончательные системные требования анализируются с целью подтверждения их полноты, совместимости, достижимости (при данных технологиях или знаниях технологического прогресса) и выражаются с соответствующей степенью детализации. Проводится подтверждение того, что системные требования являются, с одной стороны, необходимыми и достаточными для удовлетворения требований правообладателей, а с другой - необходимыми и достаточными входными данными для других процессов, в частности для проектирования архитектуры;
g) демонстрировать связь между системными требованиями и требованиями правообладателей.
Примечание - Необходимо отслеживать взаимосвязь между системными требованиями и требованиями правообладателей, то есть всем достижимым требованиям правообладателей соответствует одно или несколько системных требований, и все системные требования удовлетворяют или способствуют удовлетворению хотя бы одного требования правообладателя. Системные требования хранятся в соответствующем архиве данных, что позволяет отслеживать связь между потребностями правообладателей и проектированием архитектуры системы;
h) на протяжении всего жизненного цикла вести учет совокупности системных требований вместе с их обоснованиями, связанными решениями и допущениями.
5.5.4 Процесс проектирования архитектуры
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) задавать выбранные физические проектные решения в соответствии с порядком проектирования архитектуры в терминах проектных функций, характеристик эксплуатации, поведения, интерфейсов и неизбежных ограничений при реализации проекта.