ГОСТ Р 56923—2016
Окончание таблицы А.28
Положение
ИССШЭК 12207
j) Конструктор (исполнитель) часто планирует и готовит пользовательскую документацию,
поскольку во многих системах используется взаимодействие между людьми. Конструктор
(исполнитель) должен общаться с пользователем относительно всех проблем, которые воз
действуют на пользователя (например, требования, проект, тест, пользовательские проблемы
документации). Предварительные версии пользовательской документации могут быть под
готовлены как часть деятельности проектирования архитектуры программных средств и об
новлены во время последующих действий. Важно гарантировать, чтобы все задействованные
стороны понимали:
1) каким образом входы от пользователей должны быть собраны и объединены в процессе
реализации программных средств:
2) какая пользовательская документация должна быть подготовлена;
3) когда должна быть готова предварительная и обновленная информация;
4) какие стороны должны быть ответственными за подготовку/рассмотрение.’обновление ин
формации.
Вопросы приемки пользовательской документациидолжны быть отражены в соглашении при
обретающей стороны с поставщиком
7.1.3.3.1.3
7.1.3.3.1.4
k) В процессе реализации программного средства конструктор (исполнитель) должен опреде
лить подходящее время для начала планирования комплексирования программных средств и
тестирования. Конструктор (исполнитель) может определить и задокументировать требо
вания предварительных испытаний и сроки для комплексирования программных средств как
часть деятельности проектирования архитектуры или задокументировать тестовую информа
цию во время процесса реализации программных средств. Важно гарантировать, чтобы все
задействованные стороны понимали:
l) какая испытательная документация должна быть подготовлена;
2) когда должна быть готова предварительная и обновленная информация;
3) какие стороны должны быть ответственными за подготовку/рассмотрение/обновление ин
формации
7.1.3.3.1.5
I) Оценивая и документируя результаты этих оценок, конструктор (исполнитель) должен объ
яснить осуществимость архитектуры, чтобы реализовать требования и удовлетворить поль
зовательские потребности
7.1.3.3.1.6
т) Проведение ревизий включает планирование и принятие участия в совместных техниче
ских и управленческих ревизиях. Стандарт IEEE Std 1028 Стандарт IEEE для ревизий и ауди
тов программных средств (IEEE Standard for Software Reviews and Audits) может быть полез
ным в осуществлении этого требования
Таблица А.29 — Процесс детального проектирования программных средств (7.1.4)
7.1.3.3.1.7
7.2.6
Положение
ИСОГМЭК12207
а) Конструкторское детальное описание проекта должно включать описание каждой про
граммной единицы (блока) программного объекта
7.1.4.3.1.1
Ь) Стандарты поставщика, методы, и инструментарии, описанные в плане(ах) реализации,
должны ясно излагать подход к созданию детального проекта, кодированию программных
средств и тестированию программных средств всех уровней. В частности, план(ы) должен
(должны) обращаться:
1) к используемым стандартам, методам и инструментариям;
2) к терминологии и графическим способам описания различных проектных элементов;
3) к уровню деталей, связанных сдетальным проектом.
4) к отношению детального проекта с отдельно компилируемой программной сущностью (объ
ектом) и к отдельно выполнимой программной сущности (обьекту);
5) к подходу для ревизий проектной информации участниками проектирования;
6) к подходу для тестирования единиц (блоков).
7.1.4.3.1.1
94