ГОСТ Р 56923—2016
Таблица А.28 — Процесс проектирования архитектуры программных средств (7.1.3)
Положение
ИСО/МЭК 12207
а) См. также таблицу 17— Процесс проектирования архитектуры системы (6.4.3)
6.4.3.3
Ь) Во многих случаях уместно рассмотреть архитектуру программных средств как механизм
для того, чтобы облегчить связь среди проектировщиков системы, проектировщиков про
граммных средств и других ключевых заинтересованных сторон относительно разъяснения
требований и их воздействия на структуру программных средств
7.1.3.3.1.1
с) Архитектурная деятельность касается создания строгой полной структуры для программ
ных средств. Во время этой деятельности внимание должно быть обращено на структурные
механизмы архитектуры системы. Например, проектирование архитектуры должно произве
сти общие механизмы для того, чтобы управлять неизменяемыми объектами, обеспечивая
пользовательский интерфейс и управляющее хранение
7.1.3.3.1.1
d) Часто является приемлемым (и поддерживаемым критериями оценки) использовать ар
хитектуру как средство для формулировки и регистрации решений проекта программных
средств (т. е. решений о поведенческом проекте программных средств и других решений, за
трагивающих выбор и проект компонентов программных средств). Результаты таких решений
могут быть зарегистрированы в форме проекта программного объекта. Результаты решений
относительно определения компонентов программных средств и прослеживаемости требова
ний могут быть зарегистрированы в форме проектирования архитектуры и ссылок прослежи
ваемости
7.1.3.3.1.1
е) Конструкторское описание архитектуры программных средств включает описание замысла
выполнения с участием программных компонентов
7.1.3.3.1.1
f) Для каждого обьекта программных средств отсутствует какой-либо универсальный вид со
глашения о том. сколько деталей проекта должно быть зарегистрировано и рассмотрено как
«структура высшего уровняв. Поэтому конструкторские стандарты, методы и инструментарии,
описанные в планах реализации, должны ясно излагать подход к созданию программных ар
хитектурных и детальных проектов. В частности, планы должны обращаться:
1) к используемым стандартам, методам и инструментариям:
2) к терминологии и графическим способам описания различных модулей;
3) к уровню деталей, связанных с архитектурным идетальным проектом;
4) к подходу для ревизий проектной информации участниками проектирования.
Чтобы избежать неверных представлений различными проектными заинтересованными сто
ронами. важно, чтобы эти связанные с проектом проблемы были решены, задокументирова ны
и ясно понимаемы
7.1.3.3.1.1
д) Термин «программный компонент» в ИСО/МЭК 12207 представляет собой сущность (объ
ект). которая уточняется на более низких уровнях, содержит программные единицы (блоки) и
протестирована как часть программного комплекса. План(ы) реализации должен ясно уста
новить подход к созданию программных средств структуры высшего уровня, архитектурный и
детальный проекты, кодирование программных средств, а также все уровни тестирования
программных средств. Вчастности, планы должны обращаться:
1) к используемым стандартам, методам и инструментариям:
2) к терминологии и графическим способам описания различных модулей:
3) к уровню деталей, связанных с архитектурным идетальным проектом:
4) к отношению программного архитектурного проекта с детальным проектом;
5) к подходу для ревизий проектной информации участниками проектирования;
6) к подходу к тестированию при программном комплексировании.
Чтобы избежать неверных представлений различными проектными заинтересованными сто
ронами. важно, чтобы эти связанные с проектом проблемы были решены, задокументирова
ны и ясно понимаемы
7.1.3.3.1.1
h) Архитектура программных средств должна быть совместимой с архитектурой системы
7.1.3.3.1.1
i) Конструкторское описание проекта интерфейса должно включать описание характеристик
интерфейса программных объектов, внешних сущностей и программных компонентов
7.1.3.3.1.2
93