Хорошие продукты и сервисы
Наш Поиск (введите запрос без опечаток)
Наш Поиск по гостам (введите запрос без опечаток)
Поиск
Поиск
Бизнес гороскоп на текущую неделю c 29.12.2025 по 04.01.2026
Открыть шифр замка из трёх цифр с ограничениями

ГОСТ Р 56923-2016; Страница 62

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы ГОСТ 10213.2-2002 Волокно штапельное и жгут химические. Методы определения разрывной нагрузки и удлинения при разрыве Staple chemical fibre and tow. Methods for determination of breaking strength and breaking elongation (Настоящий стандарт распространяется на химические штапельное волокно и жгут и устанавливает методы определения разрывной нагрузки и удлинения при разрыве штапельных волокон и элементарных нитей в жгуте в сухом и мокром состоянии. Стандарт не распространяется на углеродное, асбестовое и стеклянное волокна) ГОСТ Р 56809-2015 Композиты полимерные. Метод определения предела прочности на сжатие параллельно плоскости «сэндвич»-конструкций Polymer composites. Method for determination of compressive strength parallel to the plane of sandwich constructions (Настоящий стандарт устанавливает метод определения предела прочности на сжатие параллельно плоскости «сэндвич»-конструкций. Метод применим для всех материалов внутреннего слоя «сэндвич»-конструкций, как с поверхностью непрерывного склеивания (например, пробковое дерево и пенопласты), так и с поверхностью прерывистого склеивания (например, сотовая структура)) ГОСТ Р 56922-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования Software and systems engineering.Software testing. Part 3. Test documentation (Настоящий стандарт определяет шаблоны документации тестирования программного обеспечения, которые могут использоваться в любой организации, любом проекте или каком-либо действии тестирования проекта)
Страница 62
Страница 1 Untitled document
ГОСТ Р 56923—2016
Продолжение таблицы А. 1
Положение
ИССиМЭК 15288
ИСОЛИЭК 12207
с)Для определения замысла с помощью системы, программных продуктов
или услуг, которые будут приобретены, должны быть использованы все воз
действующие дисциплины. Эксплуатационный замысел должен изменять
ся.’обновляться периодически для отражения текущих потребностей
Эксплуатационный замысел должен быть направлен на полный жизненной
цикл (приобретение, поставку, реализацию, функционирование, сопрово
ждение) системы, программного продукта или услуг. Описание эксплуата
ционного замысла может быть использовано для:
1) получения согласия между приобретающей стороной, поставщиком, кон
структором (исполнителем), сопровождающей стороной и пользователями
на эксплуатационный замысел и замысел сопровождения предлагаемой
системы;
2) помощи пользователям для понимания и адаптации к необходимым экс
плуатационным изменениям и изменениям в сопровождении как результат
модификаций при реинжениринге. дополнении новых способностей или
иных модификациях
6.1.1.3.1.1
d) Требования системы должны быть написаны на соответствующем уров
не. основанном на уровне знания об эксплуатационном замысле и системе,
которая будет приобретена. Требования к системе развиваются, поскольку
знание получаются всеми вовлеченными сторонами. Многие методы до
ступны для использования в определении требований системы (например,
исследование замысла, прототипирование)
6.1.1.3.1.2
е) Определение безопасности системы и требования к безопасности долж
ны также включать то. что не должна делать система
6.1.1.3.1.2
f) Всистемах, содержащих программные средства с требованиями безопас
ности. может быть уместным применить стандарт IEEE Std 1228. Стандарт
IEEE для планов безопасности программных средств. Учет программных
средств при сертификации бортовых систем и оборудования (IEEE Standard
for Software Safety Plans. RTCA DO-178B. Software Considerations inAirborne
Systems and Equipment Certification), ссылка на него также может оказаться
полезной
6.1.1.3.1.2
д) В системах, содержащих программные средства с высокими требовани
ями зависимости, может быть уместно применить стандарт IEEE Std 982.1.
Стандарт IEEE Словарь показателей зависимости в программных аспектах
(IEEE Standard Dictionary of Measures of the Sofhv areaspects of Dependabili
ty). чтобы сформулировать измеримые требования зависимости
6.1.1.3.1.2
h) Приобретающая сторона должна гарантировать, что получающиеся тре
бования системы обеспечивают соответствующую гибкость для проектиро
вания. модификаций или расширения поставляемых систем. Например, в
соответствующих ситуациях требования системы могут включать подход
«открытых систем». Альтернативно требования системы могут вызывать к
использованию области применения специальной архитектуры или содер
жательные связи со специальной архитектурой или с архитектурой других
профаммных систем вэксплуатационной окружающей среде
6.1.1.3.1
А
i) Рассматривая опции 6.1.1.3.1.6. приобретающая сторона должна запра
шивать входы от потенциальных поставщиков
6.1.1.3.1.6
j) План приобретения готовится с использованием процесса планирования
проекта
6.1.1.3 а)
6.3.1
6.1.1.3.1.8
6.3.1
к) План приобретения должен определить проектный процесс приобрете
ния и должен описать отношения проектного процесса приобретения к ор
ганизационному процессу приобретения
6.1.1.3.1.8
58