База ГОСТовallgosts.ru » 35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ » 35.080. Программное обеспечение

ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию

Обозначение: ГОСТ Р ИСО/МЭК 25051-2017
Наименование: Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию
Статус: Принят

Дата введения: 03/01/2018
Дата отмены: -
Заменен на: -
Код ОКС: 35.080
Скачать PDF: ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию.pdf
Скачать Word:ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию.doc


Текст ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

ИСО/МЭК 25051-

2017

Информационные технологии Системная и программная инженерия

ТРЕБОВАНИЯ И ОЦЕНКА КАЧЕСТВА СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(SQuaRE)

Требования к качеству готового к использованию программного продукта (RUSP) и инструкции

по тестированию

(ISO/IEC 25051:2014, Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, IDT)

Издание официальное

Москва

Стандартииформ

2017

ГОСТ Р ИСО/МЭК 25051—2017

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИА8Ц) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом лостандартиэацииТК22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 мая 2017 г. No 448-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25051:2014 «Системная и программная инженерия. Оценка и требования к качеству программного обеспечения и систем (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию» (ISO/IEC 25051:2014 «Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and instructions fortesting». IDT).

ИСО/МЭК 25051 разработан подкомитетом ПК 7 «Системная и программная инженерия» совместного технического комитета СТК 1 «Информационные технологии» Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р1.5—2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместоссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

6    Некоторые положения международного стандарта, указанного в пункте 4. могут являться объектом патентных прав. ИСО и МЭКне несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации в Российской Федерации». Информация об измене• ниях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты». а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае лересмот-ра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

© Стандартинформ.2017

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

ГОСТ Р ИСО/МЭК 25051—2017

Содержание

1    Область применения...................................................1

2    Соответствие требованиям..............................................2

3    Нормативные ссылки..................................................2

4    Термины, определения и сокращения........................................2

4.1    Термины и определения..............................................2

4.2    Сокращения.....................................................2

5    Требования к RUSP...................................................5

5.1    Требования к описанию продукта........................................5

5.2    Требования к документации пользователя..................................5

5.3 Требования к качеству программного обеспечения.............................9

6    Требования к документации по тестированию..................................11

6.1    Общие требования................................................14

6.2    Требования к плану тестирования.......................................14

6.3    Требования к описанию процедуры тестирования............................16

6.4    Требования к результатам тестирования..................................17

7    Инструкции по оценке соответствия требованиям................................18

7.1    Общие принципы.................................................18

7.2    Предварительные условия для оценки соответствия требованиям..................18

7.3    Мероприятия по оценке соответствия требованиям...........................18

7.4    Процесс оценки соответствия требованиям................................19

7.5    Отчет об оценке соответствия требованиям................................19

7.6    Контроль оценки соответствия требованиям................................20

Приложение А (справочное) Рекомендации по оценке RUSP в приложениях, имеющих критическое

значение для ведения бизнеса или обеспечения безопасности...............21

Приложение В (справочное) Порядок использования настоящего стандарта................24

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам....................................25

Библиография........................................................26

in

ГОСТ Р ИСО/МЭК 25051—2017

Введение

Второе издание ИСО/МЭК 25051 прекращает действие и заменяет первое издание ИСО/МЭК 25051:2006. которое было технически пересмотрено. Это издание также включает в себя Тех-ническую поправку ИСО/МЭК 25051:2006/Кор.1:2007.

Основные изменения заключаются в следующем:

•    исправлены заголовки на английском и французском языках;

•    внесены изменения в определение готового к использованию программного продукта (RUSP). область его применения и соответствующие примеры:

•    достигнута гармонизация с текущей серией стандартов SQuaRE.

ИСО/МЭК 25051 является составной частью серии международных стандартов SQuaRE. которая состоит из следующих разделов:

•    Управление качеством (ИСО/МЭК2500п);

-    Модель качества (ИСО/МЭК2501П);

•    Измерение качества (ISO/IEC 2502п);

•    Требованияккачеству (ИСО/МЭК 2503п);

•    Оценка качества (ИСО/МЭК2504п);

-    Расширения (ИСО/МЭК25050—ИСО/МЭК 25099).

Область применения RUSP непрерывно расширяется, и их правильная эксплуатация имеет боль* шое значение для ведения бизнеса, обеспечения безопасности и удовлетворения личных потреб* ностей.

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

Выбор готового к использованию программного продукта высокого качества имеет большое значение, поскольку к RUST может предъявляться требование о возможности его использования в разных средах. Кроме того, может отсутствовать возможность сравнения данного продукта с другими схожими продуктами. Поставщикам необходимо убедиться в возможности использования функций RUSP пользователями. Некоторые поставщики могут предпочесть, чтобы оценка или сертификация таких функций проводилась группой оценки соответствия.

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

ИСО/МЭК 25051:2006 разработан на основе ИСО/МЭК 9126-1:2001 и заменяет ИСО/МЭК 12119:1994. Второе издание ИСО/МЭК 25051 представляет собой версию ИСО/МЭК 25051:2006. пересмотренную с целью соответствия ИСО/МЭК 25010:2011. который заменил модель качества ИСО/МЭК 9126-1:2001.

Указанные выше документы представляют собой основу для второй редакции стандарта, содержащей набор требований к готовому к использованию программному продукту и требования к тестированию RUSP на предмет соответствия.

IV

ГОСТ Р ИСО/МЭК 25051—2017

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии Системная и программная инженерия

ТРЕБОВАНИЯ И ОЦЕНКА КАЧЕСТВА СИСТЕМ И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (SQuaRE)

Требования к качеству готового к использованию программного продукта (RUSP)

и инструкции по тестированию

information technologies. Systems and software engineering.

Systems and software Quality Requirements and Evaluation (SQuaRE).

Requirements for quality of Ready to Use Software Product (RUSP) and instructions fortesting

Дета введения — 2018—03—01

1 Область применения

Настоящий стандарт применяется к готовому к использованию программному продукту (RUSP). Сокращение «RUSP» в настоящем стандарте используется как определение, означающее «готовый к использованию программный продукт».

Примечания

1    Ниже приводится неисчерлывающий список примеров RUSP: текстовые процессоры, таблицы. ПО для управления базами данных, графические пакеты, ПО для рвботы с встроенными техническими, научными или интерактивными функциями. ПО для управления персоналом, продажами, приложения для смартфонов, бесплатное ПО и веб-приложения, такие как программы для создания веб-свйтое и (или) аеб-страниц.

2    Программное обеспечение с открытым исходным кодом не относится к RUSP.

Настоящий стандарт устанавливает:

a)    требования к RUSP;

b)    требования к документации по тестированию RUSP. включая план тестирования, описание тестов и их результатов.

Примечание — Набор документов для тестирования называется документацией по тестированию.

c)    инструкции по оценке соответствия RUSP.

8 стандарт также входят рекомендации в отношении RUSP. критически важные для безопасности и ведения бизнеса.

Настоящий стандарт предназначен исключительно для того, чтобы обеспечить пользователям уверенность в соответствии предлагаемых свойств RUSP их требованиям. Стандарт не относится к реализации продукции (включая мероприятия по продаже и промежуточные продукты, например спецификации). Система обеспечения качества поставщика не входит в область применения настоящего стандарта.

Целевая аудитория настоящего стандарта включает:

a)    поставщиков, которые:

1)    определяют требования к RUSP:

2)    оценивают собственные программные продукты на предмет соответствия заявленным характеристикам;

3)    выпускают декларации соответствия (см. ИСО/МЭК 17050);

4)    обращаются за сертификатами или знаками соответствия (см. Руководство 23 ИСО/МЭК);

b)    сертифицирующие органы, которые могут устанавливать схемы сертификации (международные. региональные или национальные) (см. Руководство 28 ИСО/МЭК):

Издание официальное

1

ГОСТ Р ИСО/МЭК 25051—2017

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

d)    организации дляаккредитации регистрирующих или сертифицирующих органов и лабораторий тестирования:

e)    потенциальных приобретателей, которые могут:

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

2)    осуществлять поиск сертифицированного RUSP;

3)    проверять соответствие требованиям иными способами;

f)    конечных пользователей, которые могут извлекать преимущества из программных продуктов более высокого качества:

д) организации:

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

2)    при управлении и совершенствовании собственных процессов по обеспечению качества «и управления персоналом»;

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

2 Соответствиетребованиям

RUSP соответствует настоящему стандарту, если:

a)    обладает свойствами, приведенными в разделе 5;

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

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

1)    не нарушают заявленный уровень качества:

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

Раздел 7 и приложение А носят справочный характер.

Примечание — Чтобы облегчить оценку соответствия, требования настоящего стандарта должны иметь структуру, отвечающую трем условиям (с нумерацией в формате X.X.X.X). Справочные примечания дополняют ати условия и выступают в качестве инструкций.

3    Нормативные ссылки

Нормативные документы, полностью или частично упомянутые в настоящем стандарте, обязательны для их применения. Для датированных документов используют только указанные издания. Для недатированных документов используют самые последние издания (с учетом всех изменений).

ISO/IEC 25000 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Руководство no SQuaRE)

ISO/IEC 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models (Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Модели качества систем и программного обеспечения)

4    Термины, определения и сокращения

4.1 Термины и определения

Для целей, предусмотренных настоящим стандартом, используются следующие термины и определения:

2

ГОСТ Р ИСО/МЭК 25051—2017

4.1.1

приобретатель, приобретающая сторона (acquirer): Заинтересованная сторона, которая при* обретает или получает продукт или услугу от поставщика.

Примечание — Приобретателем может являться одно из следующих лиц: покупатель, клиент, владелец. заказчик.

[ИСО/МЭК 12207:2008)

4.1.2

несоответствие (anomaly): Любое состояние, не соответствующее ожиданиям, основанным на спецификациях требований, проектной документации, стандартах и пр. либо на чьем-либо восприятии или опыте.

[ИИЭР Std 1044—2009]_

4.1.3    функция администрирования приложения (application administration function): Функция, выполняемая пользователем, включая установку, конфигурирование, резервирование приложения, обслуживание (внесение исправлений и модернизация) и удаление.

4.1.4

оценка соответствия (conformity evaluation): Систематический анализ того, насколько продукт, процесс или услуга соответствуют указанным требованиям.

[ИСО/МЭК Guide 2:2004]_

4.1.5    отчет об оценке соответствия требованиям (conformity evaluation report): Документ, описывающий проведение и результаты оценки RUSP.

Примечание — Адаптация из ИИЭР 610.12—1990.

4.1.6    готовый к использованию программный продукт. RUSP (Ready to Use Software Product. RUSP): Программный продукт, доступный для любого пользователя за плату или без нее и готовый к использованию без дополнительной разработки.

Примечания

1    8 определение RUSP входят:

•    описание продукта (включая всю информацию, указанную на упаковке, спецификацию, информацию с интернет-сайте и пр.);

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

•    программное обеспечение, содержащееся не чувствительных компьютерных носителях (дискетах, компьютерных дисках. загружаемых из сети Интернет и т. п.).

2    Программное обеспечение в основном состоит из программ и денных.

3    Это определение применяется также к описанию продукта, документации пользователя и программному обеспечению, которые создаются и поддерживаются как отдельные товары, к которым при этом могут не применяться стандартные коммерческие тарифы и лицензии.

4.1.7

конечный пользователь (end user): Физическое лицо, которое в конечном итоге извлекает преимущества из функциональности готового к использованию программного продукта.

Примечание — Конечный пользователь может быть штатным оператором программного продукта или случайным пользователем, например человеком со стороны.

[ИСО/МЭК 25000:2005]_

4.1.8

ошибка (fault): Неверный шаг. процесс или определение данных в компьютерной программе. [ИИЭР Std 610.12—1990)

3

ГОСТ Р ИСО/МЭК 25051—2017

4.1.9

обслуживание (maintenance): Процесс изменения системы или компонента программного обеспечения после поставки с целью исправить ошибки, повысить производительность или скорректировать прочие свойства, либо адаптировать к изменившимся условиям.

(ИИЭР Std 610.12—1990)_

4.1.10

критерии прохождения или нвпрохождения (pass/fail criteria): Правила принятия решений о том. пройдено ли или не пройдено элементом или функцией программного обеспечения некое испытание.

[ИИЭР Std 829.12—1998)_

4.1.11    описание продукта (product description): Документ, описывающий свойства программного обеспечения, основная цель которого состоит в содействии потенциальным приобретателям в оценке того, насколько программное обеспечение подходит для них. перед его покупкой.

4.1.12    идентификация продукта (product identification): Название программного продукта, версия. модификация и дата выпуска.

4.1.13    документ с требованиями (requirements document): Документ, содержащий в любой комбинации требования или нормативы, которым должен соответствовать готовый к использованию программный продукт (RUSP).

Примечание — В качестве таких документов могут выступать технические отчеты, стандарты, списки требований (или спецификации требований к модели) для разных типов пользователей пибо регламенты и нормы, предписываемые руководящими или регулирующими органами.

4.1.14    функция программного обеспечения (software function): Реализация алгоритма в программном обеспечении, при помощи которого конечный пользователь или программное обеспечение может частично или полностью выполнить рабочее задание.

Примечание — При этом не обязательно, чтобы функция вызывалась конечным пользователем (например, при автоматическом резервировании или сохранении данных).

4.1.15 _

тестовая среда программного обеспечения (software test environment): Средства, оборудование. программное обеспечение, встроенные программы, процедуры и документация, необходимые для проведения квалификации или иного тестирования программного обеспечения.

[ИСО/МЭК/ИИЭР 24765:2010]_

4.1.16

поставщик (supplier): Юридическое или физическое лицо, заключающее соглашение с приобретателем о поставке продукта или услуги.

Примечания

1    В качестве «поставщика» может также выступать подрядчик, производитель, продавец или разработчик.

2    Иногда приобретатель и поставщик могут входить в одну организацию.

[ИСО/МЭК 12207:2008]_

4.1.17

испытание (test): Деятельность, в ходе которой система или элемент выполняются при определенных условиях под наблюдением или с записью результатов, причем оценка производится в отношении определенного аспекта системы или элемента.

[ИИЭР Std 610.12—1990)_

4.1.18

контрольный пример (test case): Набор входных данных, условий выполнения и ожидаемых результатов, разработанный для определенной цели, например для выполнения определенного пути программы или подтверждения соответствия определенному требованию.

[ИИЭР Std 610.12—1990]

ГОСТ Р ИСО/МЭК 25051—2017

4.1.19    документация по тестированию (testdocumentation): Набор документации, относящейся к мероприятиям по тестированию.

4.1.20    цель тестирования (test objective): Определенный набор характеристик программного обеспечения, измеряемых при определенных условиях путем сравнения фактического режима работы с требуемым.

Примечание — Адаптация ИИЭР Std 610.12— 1990.

4.1.21    план тестирования (test plan): Документ, описывающий покрытие, метод, ресурсы и график намеченных мероприятий по тестированию.

Примечание — Адаптация ИИЭР Std 610.12—1990.

4.1.22

процедура тестирования (test procedure): Подробные инструкции по настройке, выполнению и анализу результатов для определенного контрольного примера.

(ИИЭР Std 610.12—1990)_

4.1.23

тестирование (testing): Процесс эксплуатации системы или компонента при определенных условиях под наблюдением или с записью результатов, а также проведение анализа определенного аспекта системы или компонента.

[ИИЭР Std 610.12—1990)_

4.1.24    описание тестирования (testing description): Описание условий проведения тестирования (т. е. процедуры тестирования).

4.1.25

пользователь (user): Частное лицо или группа лиц, пользующихся RUSP в процессе эксплуатации.

Примечание — Роль пользователя и роль оператора может быть одновременно или последовательно возлагаться на одно и то же частное лицо или организацию.

[ИСО/МЭК 12207:2008]_

4.1.26    документация пользователя (user documentation): Информация, поставляемая еместес программным обеспечением для помощи пользователям в работе с ним.

4.2 Сокращения

RUSP — готовый к использованию программный продукт;

СМ — управление конфигурацией;

SQA — гарантия качества программного обеспечения:

SQC — контроль качества программногообеслечения.

5 Требования к RUSP

5.1    Требования к описанию продукта

Примечание — Информация, указанная не упаковке согласно ИСО/МЭК 9127 «Программная инженерия. Документация пользователя и информация, указанная на упаковке», может использоваться в качестве исходных денных для создания олисвния продукте.

5.1.1    Доступность

5.1.1.1    Описание продукта должно быть доступно для потенциальных приобретателей и пользователей продукта.

5.1.2 Содержание

5.1.2.1    В описании продукта должно содержаться сообщение о качественных характеристиках е процессе эксплуатации программного обеспечения.

5.1.2.2    Вописании продукта должна содержаться информация, необходимая потенциальным приобретателям для оценки того, насколько программное обеспечение подходит для их нужд.

5.1.2.3    Описание продукта не должно содержать внутренних противоречий.

S

ГОСТ Р ИСО/МЭК 25051—2017

5.1.2.4 Включенные в описание продукта сообщения должны быть подтверждаемы путем тестирования или верификации.

5.1.3 Идентификация и указатели

5.1.3.1    В описании продукта отображается уникальный идентификатор.

5.1.3.2    RUSP идентифицируется по обозначению изделия.

5.1.3.3    8 описании продукта должно содержаться его наименование и адрес поставщика (почтовый илиадресинтернет-ресурса).атаюке. если применимо, адреса продавцов, интернет-продавцов или дистрибьюторов.

5.1.3.4    В описании продукта должно содержаться описание рабочих задач, для решения которых предназначен продукт, а также сервисов, которые могут быть обеспечены программным продуктом.

5.1.3.5    8 описании продукта должны указываться документы с требованиями, если поставщик претендует на соответствие документации, выпущенной согласно законодательству или регулирующим органом, и это влияет на RUSP.

5.1.3.6    В описании продукта должно указываться, предлагается ли поддержка RUSP.

5.1.3.7    В описании продукта должно указываться, предлагается ли обслуживание продукта. Если такое обслуживание предлагается, в описании продукта должны уточняться предлагаемые услуги.

5.1.4    Преобразование данных

5.1.4.1    Все упомянутые в описании продукта функции должны классифицироваться в соответствии с требованиями ккачеству характеристик программного обеспечения (см. 5.3.2—5.3.9).

5.1.5    Качество продукта — функциональная пригодность

5.1.5.1    Если это применимо, описание продукта должно содержатьсообщение о функциональной пригодности с учетом функциональной полноты, функциональной правильности и функционального соответствия. Это сообщение должно быть изложено таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

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

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

Примечании

1    Такими критическими для пользователя дефектами могут быть:

- потеря данных.

•    зависание.

2    Для получения дополнительной информации см. ИСО/МЭК 15026.

5.1.5.4    8 описании продукта должны быть отражены все известные ограничения, с которыми может столкнуться пользователь.

Примечание — Такими ограничениями могут быть:

•    минимальные и максимальные значения.

•    длина ключей:

•    максимальное количество записей в фвйле:

•    максимальное количество критериев поиска:

•    минимальный размер выборки.

5.1.5.5    Если у программных компонентов имеются параметры или версии, они должны быть прямо указаны.

5.1.5.6    Если существует защита от умышленного или непреднамеренного несанкционированного доступа к программному обеспечению, в описании продукта должна быть отражена соответствующая информация.

5.1.6    Качество продукта — уровень производительности

5.1.6.1    Описание продукта должно содержать сообщения об уровне производительности с учетом характера изменений во времени, использования ресурсов и возможности системы. Этисообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.6.2    Необходимо описание всех известных условий обеспечения определенного уровня производительности.

Примечание — Такими условиями могут быть:

•    конфигурации системы;

6

ГОСТ Р ИСО/МЭК 25051—2017

•    ресурсы, необходимые для эффективной работы с RUSP. например, полоса пропускания, объем жесткого диска, объем оперативной памяти, ресурсы видеокарты, адаптер беспроводной сети, скорость процессора и пр.

5.1.6.3 В описании продукта должна быть указана возможность систем, имеющих прямое отиоше-ние к системам компьютера.

5.1.7    Качество продукта — совместимость

5.1.7.1    Описание продукта должно содержать сообщения о совместимости с учетом сосуществования иоператиеной совместимости. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.7.2    Вописании продукта должно указываться, в какой части готовыйкиспользованию программный продукт зависит от определенного программного и (или) аппаратного обеспечения с предоставлением соответствующих ссылок.

Примечание — В качестве таких ссылокможетбыть указано следующее:

•    наименование программного и (или) аппаратного обеспечения (сервер, платформа и пр.):

- версия:

•    определенная операционная система.

5.1.7.3    В описании продукта должны быть указаны вызываемые пользователем интерфейсы и соответствующее программное обеспечение.

5.1.8    Качество продукта — удобство использования

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

5.1.8.2    В описании продукта должен быть указан тип интерфейса пользователя.

Примечание — 8 качестве таких интерфейсов могут выступать:

•    командная строка:

•    меню:

•    окно:

•    функциональная клавиша.

5.1.8.3    В описании продукта должно быть указано, какие конкретно знания требуются для использования и эксплуатации программного обеспечения.

Примечание — Это могут быть:

•    знания, относящиеся к вызову базы данных и используемому протоколу:

•    знания в технической области:

•    знания операционной системы:

•    знания, которые можно получить в результате специального обучения:

•    впадение языком, если описание продукта составлено на другом языке.

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

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

Примечание — В качестве таких мер зашиты могут выступать.

•    программируемые даты истечения сроков эксплуатации:

•    интерактивные напоминания об оплате используемых копий.

5.1.8.6    В описании продукта должны быть отражены положения об удобстве его использования, в частности для пользователей сограниченными возможностями или языковыми отличиями.

5.1.9    Качество продукта — надежность

5.1.9.1 Описание продукта должно содержать сообщения о надежности с учетом завершенности, удобстве его использования, отказоустойчивости и возможности восстановления. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрироватьподтвврждаемыесвидетельства соответствия на основе ИСО/МЭК 25010.

7

ГОСТ Р ИСО/МЭК 25051—2017

Примечание — Сообщения а отношении надежности не являются необходимыми, кроме случаев, когда разработчик может обосновать сообщение рабочими или иными подтверждаемыми данными.

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

5.1.9.3    6 описании продукта должна быть отражена информация о методах сохранения и восстановления данных.

Примечание — Достаточно будет указать на то. что резервирование данных может быть выполнено с помощью функций операционной системы.

5.1.10    Качество продукта — безопасность

5.1.10.1    Описание продукта должно содержать сообщения о безопасности с учетом конфиденциальности. целостности, предотвращения отказов, отчетности и подлинности. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.11    Качество продукта — удобство сопровождения

5.1.11.1    Описание продукта должно содержать сообщения об удобстве сопровождения с учетом модульности, возможности повторного использования, возможности анализа, возможности внесения изменений и проведения тестирования. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК250Ю.

5.1.11.2    Описание продукта должно включать информацию об обслуживании, предназначенную для пользователя.

Примечание — Информация об обслуживании может быть следующей:

•    постоянный мониторингдинамическойлроизводительностилриложения:

•    мониторинг непредвиденных сбоев и существенных условий;

•    мониторинг эксплуатационных индикаторов, таких как журналы, экраны оповещений.

•    мониторинг локальныхдвнных. управляемых приложением.

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

Примечание — Условия могут быть следующими:

•    изменение параметров:

-    изменение алгоритмов расчета;

•    настройки интерфейса.

-    назначения функциональных клавиш.

5.1.12    Качество продукта — мобильность

5.1.12.1    Описание продукта должно содержать сообщения о мобильности с учетом пригодности к адаптации, возможности установки и замены. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК250Ю.

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

Примечания

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

2    Такими системами могут быть:

-    операционные системы;

-    элементы процессора, в том числе сопроцессоры:

-    объем основной памяти;

•    типы и размеры периферийных хранилищ.

-    карты расширений.

-    устройства ввода и вывода:

•    сетевое оборудование:

•    системное программное обеспечение и прочее ПО.

5.1.12.3    В описании продукта должна содержаться информация о процедуре установки.

8

ГОСТ Р ИСО/МЭК 25051—2017

5.1.13    Качество использования — эффективность

5.1.13.1    Описание продукта должно содержать сообщения об эффективности. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.13.2    В описании продукта должны содержаться ссылки на соответствие продукта требованиям. чтобы пользователи могли решать свои конкретные задачи.

5.1.14    Качество использования — производительность

5.1.14.1    Описание продуктадолжносодержатьсообщенияо производительности. Этисообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.14.2    В описании продукта должно быть указано, предназначен ли RUSP для одновременного использования несколькими пользователями или одним конечным пользователем е рамках одной системы. а также максимальное количествоодновременноработающих конечных пользователей при определенном уровне производительности требуемой системы.

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

5.1.15    Качество использования — удовлетворенность

5.1.15.1    Описание продукта должно содержать сообщения о качестве использования в контексте удовлетворенности с учетом полезности, доверия, удовольствия от работы и удобства. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.15.2    Описание продукта должно содержать определенные контактные данные поставщика для цепей гарантии удовлетворенности пользователя продукта.

5.1.16    Отсутствие рисков

5.1.16.1    Описание продукта должно содержать сообщения о качестве использования в контексте отсутствия рисков с учетом снижения экономических рисков, рисков возникновения угрозы здоровью, а также экологических рисков. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

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

5.1.17    Покрытие

5.1.17.1    Описание продукта должно содержать сообщения о качестве использования в контексте покрытия обстоятельств с учетом полноты среды и гибкости. Эти сообщения должны быть изложены таким образом, чтобы можно было продемонстрировать подтверждаемые свидетельства соответствия на основе ИСО/МЭК 25010.

5.1.17.2    Если описание продукта содержит информацию о соответствии, должен быть точно указан^) уровень (степень) покрытия такого соответствия.

5.2    Требования кдокументации пользователя

Примечание — Информация, указанная на упаковке согласно ИСО/МЭК 9127 «Программная инженерия. Документация пользователя и информация, указанная на упаковке», может использоваться в качестве исходных данных для создания документации пользователя.

5.2.1    Доступность

5.2.1.1    Документация пользователя должна быть доступной для пользователей продукта.

5.2.2    Содержание

5.2.2.1    Включенные в документацию пользователя функции должны быть подтверждаемы путем тестирования или верификации.

5.2.3    Идентификация и указатели

5.2.3.1    В документации пользователя отображается уникальный идентификатор.

5.2.3.2    RUSP идентифицируется пообозначвнию изделия.

5.2.3.3    Документация пользователя должна содержать название и адрес (почтовый или адрес интернет-ресурса) поставщика.

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

5.2.4    Полнота

5.2.4.1 В документации пользователя должна содержаться информация, необходимая для использования программногообеспечения.

9

ГОСТ Р ИСО/МЭК 25051—2017

5.2.4.2    8 документации пользователя должны быть описаны все функции, указанные в описании продукта, и все функции, которые может приобрести конечный пользователь.

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

5.2.4.4    8 документации пользователя должны содержаться инструкции по резервированию и восстановлению необходимых данных.

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

Примечание — Для получения дополнительной информации см. приложение А.

S.2.4.6 8 документации пользователя указан минимальный размер пространства, необходимого для установки на диске.

5.2.47 8 документации пользователя должна содержаться вся информация, необходимая пользователю для работы с функциями администрирования приложения.

Примечание — Пример информации: информация, дающая пользователю возможность подтвердить успешное завершение работы с функциями администрирования приложения.

5.2.4.8 Если документация пользователя предоставляется в нескольких частях, по меньшей мере, в одном элементе должен присутствовать список всех частей.

5.2.5    Корректность

5.2.5.1    Вся информация, содержащаяся в документации пользователя, должна быть достаточной для основной пользовательской аудитории.

Примечание — Происхождение всей информации, содержащейся в документации пользователя, должно подтверждаться авторитетным источником для гарантии ее правильности.

5.2.5.2    Информация в документации пользователя должна быть представлена в недвусмысленной форме.

5.2.6    Последовательность

5.2.6.1    8 документации пользователя не должны содержаться внутренние противоречия, а также разночтения с описанием продукта.

5.2.7    Понятность

5.2.7.1    Документация пользователя должна быть понятной конечным пользователям, для которых в основном предназначен RUSP. В частности, должны использоваться понятные для целевой аудитории терминология и стиль.

5.27.2    Понимание документации пользователя облегчается предоставлением структурированного списка документов.

5.2.8    Качество продукта — функциональная пригодность

5.2.8.1    6 документации пользователя должны быть указаны все ограничения, содержащиеся в описании продукта.

5.2.9    Качество продукта — совместимость

5.2.9.1    8 документации пользователя должна содержаться информация, необходимая для идентификации совместимости при использовании программного обеспечения.

5.2.9.2    8 документации пользователя должно указываться, в какой части готовый к использованию программный продукт зависит от определенного программного и (или) аппаратного обеспечения с предоставлением соответствующих ссылок.

Примечание — В качестве таких ссылок могут быть указаны:

-    название программного и {или) аппаратного обеспечения:

• версия:

-    определенная операционная системе.

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

10

ГОСТ Р ИСО/МЭК 25051—2017

5.2.10    Качество продукта — возможность использования и (или) обучения

5.2.10.1    В документации пользователя должна содержаться информация, необходимая для обучения пользованию программным обеспечением.

Примечание — В документации пользователя могут приводиться ссылки на дополнительную информацию о RUSP или дополнительные материалы, например обучающие.

5.2.11    Качество продукта — возможность использования и (или) эксплуатации

5.2.11.1    Если документация пользователя в печатной форме не предоставляется, в документации должнобытьукаэано. можно ли ее напечатать. Если печать возможна, должен бытьуказанпорядокполу-чения печатной копии.

5.2.11.2    За исключением карточек и кратких справочных руководств, в документации пользователя должно содержаться оглавление или слисок тем. а также указатель.

5.2.11.3    В документации пользователя должны быть даны определения терминов и сокращений, необходимых для понимания конкретной терминологии, используемой в документе.

5.2.12    Качество продукта — надежность

5.2.12.1    В документации пользователя должны быть указаны характеристики надежности и соответствующие операции.

5.2.13    Качество продукта — безопасность

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

5.2.14    Качество продукта — удобство сопровождения

5.2.14.1    В документации пользователя должно указываться, предлагается ли обслуживание продукта. Если обслуживание предлагается, документация пользователя должна описывать услуги сопровождения всоотеетстеии с планом выпуска программного продукта.

5.2.15    Качество использования — эффективность

5.2.15.1    Документация пользователя должна содействовать в достижении качества использования в контексте эффективности согласно описанию продукта.

5.2.16    Качество использования — производительность

5.2.16.1    Документация пользователя должна содействовать пользователю в достижении качества использования в контексте производительности согласно описанию продукта.

5.2.17    Качество использования — удовлетворенность

5.2.17.1    Документация пользователя должна содействовать пользователю в достижении качества использования в контексте удовлетворенности согласно описанию продукта.

5.2.17.2    Документация пользователя должна содержать определенные контактные данные поставщика для целей обмена информацией об уровне удовлетворенности пользователя продуктом.

5.2.18    Качество использования — отсутствие рисков

5.2.18.1    Документация пользователя должна содействовать пользователю в достижении качества использования в контексте отсутствия рисков согласно описанию продукта.

5.2.19    Качество использования — покрытие

5.2.19.1    Документация пользователя должна содействовать пользователю в достижении качества использования покрытия контекста согласно описанию продукта.

5.3    Требования к качеству программного обеспечения

5.3.1    Качество продукта — функциональная пригодность

5.3.1.1    После установки должна присутствовать ясность того, может ли быть выполнена определенная функция или нет.

Примечание — Правильное функционирование может быть проверено за счет использования поставляемых контрольных примеров либо с помощью процедуры самотестирования с соответствующими сообщениями, а также путем проведения тестов самим пользователем.

5.3.1.2    Все упоминаемые в документации пользователя функции должны выполняться с соответствующими аппаратными устройствами, свойствами и данными, а также в рамках заданных ограничений и в соответствии со всеми сообщениями, содержащимися в документации пользователя.

и

ГОСТ Р ИСО/МЭК 25051—2017

5.3.1.3    Программное обеспечение должно соответствовать всем требованиям, содержащимся в документе, на который дается ссылка в описании продукта.

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

Примечание — Пример: дев одинаковых действия должны девать одинаковый результат.

5.3.1.5    Должна быть предусмотрена возможность контроля работы программного обеспечения конечным пользователем в соответствии с документацией пользователя. Работа программного обеспечения должна быть последовательной.

5.3.2    Качество продукта — уровень производительности

5.3.2.1    Программное обеспечение должно соответствовать заявленному в описании продукта уровню производительности.

Примечание — Отправка сообщений пользователю во время ожидания не имеет смысла.

5.3.3    Качество продукта — совместимость

5.3.3.1    Если установка может быть выполнена пользователем, программное обеспечение должно предоставлять средства контроля совместимости установленных компонентов.

5.3.3.2    Работа программного обеспечения должна соответствовать функциональной совместимости. указанной в документации пользователя и описании продукта.

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

5.3.3.4    В документации пользователя должны быть четко указаны тип совместимости, функция, данные или поток.

5.3.3.5    Программное обеспечение должно указывать, какие его компоненты отвечают за совместимость.

5.3.3.6    Если пользователь может выполнить установку, а у программного обеспечения имеются ограничения совместимости с каким-либо из установленных компонентов, это должно быть указано до начала установки.

5.3.4 Качество продукта — доступность для использования

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

5.3.4.2    Сообщения (вопросы, инструкции и т. п.) и результаты работы программного обеспечения должны быть доступными для понимания.

Примечание- Доступность для понимания может быть обеспечена:

•    правильной терминологией;

•    графическими элементами.

•    предоставлением справочной информации;

•    предоставлением справочной системы;

•    четким и легко читаемым текстом или графическими материалами.

•    хорошо распознаваемым на слух вудиоматеривлом.

Что касается доступности для использования, сторонам соглашений, заключаемых на базе настоящего стандарта, рекомендуется изучить возможности применения последних версий стандартов серии ИС09241. В частности, разделов 1.2.10—17 стандарта серии ИС09241 иИСО 25062.

5.3.4.3    Во всех сообщениях об ошибках, выдаваемых программным обеспечением, должны быть указаны меры по устранению ошибки или контакты лиц, которым необходимо сообщить об ошибке.

Примечание — В качестве такой информации может выступать ссылка на документацию пользователя.

5.3.4.4    Сообщения программного обеспечения должны быть составлены таким образом, чтобы конечный пользователь мог без затруднений понять, к какому типу относится сообщение.

Примечание — В качестве таких сообщений могут выступать:

•    подтверждения:

- запросы от программного обеспечения.

•    информация:

•    предупреждения;

12

ГОСТ Р ИСО/МЭК 25051—2017

•    сообщения об ошибках.

5.3.4.5    Пользователям должны быть полностью понятны форматы экранов ввода, отчеты и про* чая выводимая информация.

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

Примечание — Стирание и перезапись данных, а также прерывание длительных операций по обработке данных, имеющих серьезные поспедствия.

5.3.4.7    Конечный пользователь должен иметь возможность научиться использованию функции, предоставляемой интерфейсом пользователя, справочной системой или документацией пользователя.

5.3.4.8    Пользователь должен получать уведомление© выполнении функции с временем отклика, выходящим за общепринятые пределы.

5.3.4.9    На каждом элементе (носитель данных, файл и т. п.) должен присутствовать идентификатор продукта. Если таких идентификаторов два или более, то должен быть указан номер идентификатора или его текст.

5.3.4.10    Интерфейс пользователя должен быть понятным для пользователя поставлять удовлетворительное впечатление от работы.

5.3.5 Качество продукта — надежность

5.3.5.1    Работа программного обеспечения должна соответствовать функциям надежности, указанным в документации пользователя.

5.3.5.2    Функция обработки ошибок должна соответствовать заявленным в описании продукта и документации пользователя параметрам.

Примечание — На программное обеспечение не должны списываться разнообразные сбои, возникающие е результате работы системы ипи сети.

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

Примечание — Это требование может быть выполнено, если:

•    возможности системы используются в указанных пределах:

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

•    конечный пользователь ипи другое программное обеспечение, указанное в описании продукта, вводит неправильные данные:

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

5.3.5.4    Программное обеспечение должно распознавать нарушения синтаксиса вводимых данных и не обрабатывать такие данные как недопустимые.

5.3.5.5    Программное обеспечение должно восстанавливаться после критической ошибки и работать а прозрачном для пользователя режиме.

5.3.6    Качество продукта — безопасность

5.3.6.1    Работа программного обеспечения должна соответствовать характеристикам безопасности, указанным в документации пользователя.

5.3.6.2    Программное обеспечение при помощи соответствующих функций должно препятствовать несанкционированному доступу (случайному или преднамеренному) к программам и данным.

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

5.3.6.4    Программное обеспечение должно поддерживать управление правами доступа е отношении функций безопасности.

5.3.6.5    Программное обеспечение должно предоставлять инструмент обеспечения конфиденциальности данных и ограничения доступа авторизованными лицами.

5.3.7    Качество продукта — удобство сопровождения

5.3.7.1 Работа программного обеспечения должна соответствовать функциям удобства сопровождения, указанным в документации пользователя.

Примечание — Примеры: слособностьдиагностироеать дефекты, возможность инициировать изменения.

13

ГОСТ Р ИСО/МЭК 25051—2017

5.3.7.2    Программное обеспечение должно для каждого базового компонента идентифицировать номер выпуска и соответствующие качественные характеристики, параметры и модель данных.

5.3.7.3    Программное обеспечение должно в любой момент идентифицировать номер выпуска каждого базового компонента установленной версии и влияющего на функции программного обеспечения.

Примечание — 8 качестве базовых компонентов могут выступать:

•    экран данных:

•    модель базы данных:

•    подпрограмма:

•    интерфейс.

5.3.8    Качество продукта — мобильность

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

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

5.3.8.3    Программное обеспечение должно обеспечивать пользователю возможность удалить все установленные компоненты.

5.3.9    Качество использования — эффективность

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

5.3.9.2    Программное обеспечение должно предоставлять средства для оценки влияния программного обеспечения на заданные цели соответствия.

5.3.10    Качество использования — производительность

5.3.10.1    Программное обеспечение должно работать в соответствии с функциями обеспечения производительности, указанными в описании продукта и документации пользователя.

5.3.10.2    Программное обеспечение должно предоставлять средства для оценки производительности используемого ПО при достижении целей.

5.3.11    Качество использования — удовлетворенность

5.3.11.1    Программное обеспечение должно работать в соответствии с функциями обеспечения удовлетворенности, указанными в описании продукта и документации пользователя.

5.3.11.2    Программное обеспечение должно предоставлять способ непосредственной связи со службой поддержки при наличии договора об обслуживании.

5.3.12    Качество использования — отсутствие рисков

5.3.12.1    Программное обеспечение должно работать в соответствии с функциями обеспечения отсутствия рисков, указанными в описании продукта и документации пользователя.

5.3.12.2    Программный продукт должен обеспечивать конкретный процесс валидации и администрирования. подходящий для всех функций, сопряженных с риском.

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

5.3.13    Качество использования — покрытие

5.3.13.1    Программное обеспечение должно работать в соответствии с функциями покрытия контекста. указанными в описании продукта и документации пользователя.

5.3.13.2    Если программным обеспечением используются параметры, ограничивающие функциональное покрытие, пользователю должно быть известно текущее покрытие контекста.

6 Требования к документации по тестированию

6.1    Общие требования

6.1.1    Цель

6.1.1.1    Цель документации по тестированию заключается в демонстрации соответствия программного обеспечения требованиям согласно 5.3. В ней должны содержаться все элементы, дающие возможность такой демонстрации.

6.1.2 Согласованность

14

ГОСТ Р ИСО/МЭК 25051—2017

6.1.2.1    Информация, содержащаяся в документации по тестированию, должна быть правильной и поддающейся проверке.

6.1.2.2    Вся документация по тестированию не должна содержать противоречивых сведений или несоответствий описанию продукта и документации пользователя.

6.1.3 Требования к контенту

6.1.3.1    Документация по тестированию должна содержать:

a)    план тестирования:

b)    процедуры тестирования:

c)    результаты тестирования.

6.1.3.2    Документация по тестированию должна содержатьсписок всех документов, изкоторыхона состоит, с названиями и идентификаторами.

6.1.3.3    Каждый элемент документации для тестирования должен включать:

a)    название:

b)    идентификатор продукта:

c)    историю изменений или любой другой элемент, описывающий развитие документа;

d)    содержание или описание содержания:

e)    идентификатор документов, на которые даются ссылки в основной части документа:

0 информацию о составителях и проверяющих:

д) глоссарий.

6.1.3.4    Документация по тестированию может состоять из одного или более документов.

6.1.4    Подход

Примечание — Рекомендации по конкретным техникам или методам тестирования не предоставляются.

6.1.4.1    Все качественные характеристики, упоминаемыеволисании продукта согласно 5.3. атакже в требованиях к качеству программного обеспечения, должны проверяться контрольными примерами.

6.1.4.2    Каждая качественная характеристика, упоминаемая в описании продукта и в 5.3. а также в требованиях к качеству программного обеспечения, должна проверяться по меньшей мере одним контрольным примером.

Примечание — 8 плаке тестирования могут содержаться ссылки на любой другой документ при условии. что между таким документом и документацией пользователя имеется определенная связь.

6.1.4.3    Все описанные в документации пользователя функции, атакже комбинации функций, относящиеся к поставленной задаче, должны проверяться контрольными примерами.

6.1.4.4    Каждая описанная в документации пользователя функция должна подтверждаться по меньшей мере одним контрольным примером.

6.1.4.5    Контрольные примеры демонстрируют соответствие программного обеспечения сообщениям. содержащимся в документации пользователя.

6.1.4.6    Если в описании продукта упоминаются документы с требованиями, они должны проверяться контрольными примерами.

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

Примечание — 8 качестве твкой функции может выступать:

•    пункт документации пользователя:

•    команда оболочки:

•    кнопка интерфейса пользоаатепя.

•    команда языка.

6.1.4.8    Необходимо указывать метод создания контрольных примеров.

Примечание — Контрольные примеры могут создаваться с помощью следующих методов:

•    анализа граничных значений:

•    контрольного списка (чек-лист);

•    анализа потоков данных;

•    вставки ошибок;

•    объемного тестирования.

6.1.4.9    Все процедуры установки должны проверяться контрольными примерами.

1S

ГОСТ Р ИСО/МЭК 25051—2017

6.1.4.10    Контрольными примерами должны проверяться все эксплуатационные ограничения. ука-эанные в описании продукта и документации пользователя.

6.1.4.11    Контрольными примерами должны проверяться выявленные нарушения синтаксиса.

6.1.4.12    Если в документации пользователя указаны примеры, они должны использоваться в качестве контрольных примеров; при этом полное тестирование не должно ограничиваться этими при» мерами.

6.1.4.13    Если какое-либо из требований, изложенных в 5.3 (требования к качеству программного обеспечения), не применимо, должна указываться причина его неприменения.

6.1.4.14    Программное обеспечение тестируется во всех конфигурациях, упомянутых в описании продукта и (или) документации пользователя.

6.2 Требования к плану тестирования

6.2.1    Критерии прохождения и (или) кепрохождения

6.2.1.1    8 плане тестирования должны указываться критерии, которые использовались для принятия решения о том. насколько результаты тестирования демонстрируют соответствие программного обеспечения описанию продукта или документации пользователя.

6.2.2    Тестовая среда программного обеспечения

6.2.2.1    В плане тестирования должна указываться среда, в которой производится тестирование программного обеспечения.

Примечание — Демонстрация равнозначности используемых конфигураций.

6.2.3    График

6.2.3.1    8 плане тестирования должны быть указаны контрольные точки тестирования и график каждого мероприятия по тестированию.

Примечание — Примеры мероприятий по тестированию:

•    настройка среды тестирования;

•    документация по тестированию;

•    проведение тестирования.

6.2.4    Риски

6.2.4.1    8 плане тестирования должны указываться, обновляться и учитываться риски, связанныес мероприятиями по тестированию, и статусы корректирующих действий.

6.2.5    Людские ресурсы

6.2.5.1    8 плане тестирования должны быть указаны людские ресурсы, выделяемые для каждого мероприятия по тестированию.

6.2.6    Инструменты и оборудование

6.2.6.1    6 плане тестирования должны быть указаны инструменты, необходимые для выполнения тестирования.

6.2.6.2    Если используется некий конкретный инструмент или среда, вплане тестирования должны быть указаны причины выбора этого инструмента и ожидаемые результаты.

6.2.7    Передача информации

6.2.7.1    8 плане тестирования должна быть указана модель передачи информации и методы, используемые для передачи документации по тестированию и объектов тестирования заинтересован* ным сторонам.

6.3 Требования к описанию процедуры тестирования

6.3.1    Описание контрольных примеров

6.3.1.1    8 контрольных примерах должно быть указано следующее:

a)    цель тестирования;

b)    уникальный идентификатор:

c)    входные данные и предельные значения тестирования;

d)    подробная информация о выполняемых действиях;

e)    ожидаемая реакция системы;

f)    ожидаемый результат тестирования;

д) критерии интерпретации результата;

16

ГОСТ Р ИСО/МЭК 25051—2017

h)    критерии, используемые для суждения о положительном илиотрицательном результате тести* рования:

i)    ссылки на качественные характеристики на базе ИСО/МЭК250Ю.

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

6.3.2    Процедуры тестирования

6.3.2.1    Процедура тестирования должна включать в себя следующие этапы:

a)    подготовка к тестированию:

b)    действия, необходимые для начала и проведения тестирования:

c)    действия, необходимые для учета результатов тестирования;

d)    условия и действия для прекращения и последующего повторного запуска тестирования.

6.3.2.2    Процедуры тестирования должны быть детализированы в достаточной степени, чтобы обеспечить возможность повторения и воспроизводимость.

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

Примечание — Для описания процедур тестирования может использоваться псевдоязык или язык команд.

6.4 Требования к результатам тестирования

6.4.1    Отчет о выполнении

6.4.1.1    В отчете о выполнении должна содержаться общая сводка результатов тестирования.

6.4.1.2    В отчете о выполнении тестирования должно быть продемонстрировано выполнение всех тестовых сценариев согласно плану тестирования.

6.4.1.3    Отчеты о выполнении каждого из тестов должны включать:

a)    идентификатор контрольных примеров;

b)    дату выполнения тестирования;

c)    фамилию и функции лица, выполнившего тестирование;

d)    результат выполнения тестирования;

e)    список выявленных отклонений:

0 ссыпки на соответствующий отчет по каждому отклонению:

д)    ссылки на качественные характеристики на базе ИСО/МЭК 25010.

6.4.2 Отчет об отклонениях

6.4.2.1    Отчет об отклонениях должен включать в себя полный список найденных отклонений, и, если они имеются, необходимо указать меры по их исправлению (или устранению) и последующей проверке путем повторного тестирования.

6.4.2.2    Для каждого отклонения в описательной части отчета оботклонениях должно содержаться следующее:

a)    идентификатор отклонения;

b)    идентификатор программного обеспечения;

c)    описание отклонения;

d)    этап тестирования, на котором было отмечено отклонение;

е)    степень серьезности и возможность воспроизведения отклонения;

0    ссылки на качественные характеристики на базе ИСО/МЭК 25010.

Примечания

1    возможные степени серьезности: «полный выход из строя», «блокировке», «серьезнея неисправность», «незначительная неисправность», «мелкая неисправность».

2    возможности воспроизведения: «при любых условиях», «иногда», «при случайных условиях», «попытки не производились», «воспроизведение невозможно», «недоступно».

6.4.2.3    В части отчета, связанной с устранением отклонений, должны быть отражены все устраненные отклонения или причины, по которым отклонения не были устранены.

6.4.2.4    Для каждого отклонения в части отчета, связанной с устранением отклонений, оботклонениях должно содержаться следующее:

a)    идентификатор мер по исправлению (или устранению) отклонения:

b)    дата принятия мер по устранению отклонения;

c)    название принимаемых мер по устранению отклонения;

17

ГОСТ Р ИСО/МЭК 25051—2017

d)    идентификатор изменения, которое соответствует мерам по устранению отклонения:

e)    возможное влияние на принимаемые меры по устранениюотклонения;

f)    комментарии специалиста, применившего коррективную меру.

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

6.4.2.5    Контрольное подтверждение путем повторной проверки отчета об отклонениях должно содержать следующие элементы:

a)    идентификатор контрольного подтверждения:

b)    дата контрольного подтверждения:

c)    фамилия и имя лица, выполняющего проверку;

d)    контрольные примеры, используемые для контрольного подтверждения:

e)    результаты контрольного подтверждения:

f)    ссылки на качественные характеристики на базе ИСО/МЭК 25010.

6.4.3 Оценка результатов тестирования

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

7 Инструкции по оценке соответствия требованиям

7.1    Общие принципы

Описание продукта, документация пользователя и предлагаемое программное обеспечение, входящие в комплект RUSP, анализируются на предмет соответствия требованиям раздела 5.

Примечание — Термин «оценка соответствия» не предполагает использование какого-либо конкретного метода или инструмента, тестирования, валидации, подтверждения, проверки, анализа и пр.

Данные инструкции в основном предназначены для анализа соответствия требованиям группой специалистов. Группа специалистов по оценке соответствия может представлять собой лабораторию для проведения испытаний, работающую согласно определенному регламенту сертификации, или внутреннюю лабораторию для проведения испытаний, которая не зависит от поставщика RUSP.

7.2    Предварительные условия для оценки соответствия требованиям

7.2.1    Наличие компонентов RUSP

Для оценки RUSP необходима поставка всех компонентов (см. 5.2.4.8). а также документов с требованиями. указанных в описании продукта (см. 5.1.3.5).

7.2.2    Наличие системных компонентов

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

7.3 Мероприятия по оценке соответствия требованиям

Примечание — Рекомендации по конкретным способам или методам не предоставляются.

В соответствующем документе должен быть описан метод оценки соответствия.

7.3.1    Оценка соответствия описания продукта

Чтобы определитьсоответствие описания продукта требованиям согласно 5.1. проводится оценка соответствия.

7.3.2    Оценка соответствия документации пользователя

Чтобы определить соответствие документации пользователя требованиям, изложенным в 5.2, проводится оценка соответствия.

7.3.3    Оценка соответствия программного обеспечения

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

18

ГОСТ Р ИСО/МЭК 25051—2017

устранению несоответствий и подтверждению такового путем повторного тестирования (6.4.2.3—6.4.2.6).

Примечание — 8 документвциюпотестироввниювходит описательная честь выявленныхотклонений. При этом устранение выявленных отклонений не входит в область оценки соответствия группой специалистов.

7.4    Процесс оценки соответствия требованиям

Поставщик предоставпяет RUSP группе оценки соответствия. Поставщик также может предоставить документацию по тестированию.

Если поставщик предоставляет только RUSP без документации по тестированию, группа оценки соответствия должна:

a)    провестиоценку соответствия описания продукта, документации пользователя и программного обеспечения согласно 7.3;

b)    записать результаты в отчете об оценке соответствия согласно 7.5.

Если поставщик предоставляет RUSP и документацию по тестированию, группа оценки соответствия должна:

a)    провести оценку соответствия описания продукта и документации пользователя согласно 7.3.1 и 7.3.2;

b)    провести оценку соответствия документации по тестированию требованиям раздела 6;

c)    записать результаты в отчете об оценке соответствия согласно 7.5.

Примечания

1    Соответствие документации по тестированию требованиям раздела 6 обеспечивает соответствие программного обеспечения требованиям согласно 5.3.

2    8 процессе оценки соответствия может создаваться дополнительная документация по тестированию.

7.5    Отчет об оценке соответствия требованиям

Группа оценки соответствия должна подготовить отчет об оценке соответствия.

8 отчете об оценке соответствия указывается соответствие RUSP требованиям раздела 5.

8 отчете об оценке соответствия должны содержаться следующие данные:

a)    идентификационный номер RUSP;

b)    фамилия и имя лица, проводившего оценку;

c)    дата завершения оценки и (при наличии) завершения тестирования;

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

e)    используемые документы с идентификаторами;

0 список мероприятий по оценке соответствиям (при наличии) мероприятия по тестированию;

д) результаты оценки соответствия и (при наличии) мероприятия по тестированию:

h) подробные результаты оценки соответствия и (при наличии) тестирования;

I) список несоответствий требованиям (при наличии).

Раздел с результатами отчета об оценке соответствия (пункты f— h) должен включать результаты оценки соответствия описания продукта и документации пользователя. 6 зависимости от поставляемых компонентов, в нем также должна содержаться следующая информация:

a)    результаты тестирования программного обеспечения на соответствие требованиям согласно 5.3, т. е. описательный раздел отчета об отклонениях (см. в.4.2.2). если поставщик предоставляет RUSP без документации по тестированию;

b)    результаты оценки соответствия документации по тестированию требованиям раздела 6. если поставщик предоставляет RUSP и документацию по тестированию.

Примечание — 8 отчете об оценке соответствия содержится только описательный раздел отчета об отклонениях, поскольку а обязанности группы оценки соответствия не входит устранение отклонений.

На каждой странице печатной копии отчета об оценке соответствия должны быть указаны идентификационные данные отчета об оценке соответствия (лаборатория, где проводилось тестирование. RUSP. дата составления отчета об оценке соответствия). Также должно быть указано общее количество страниц на каждой странице отчета.

Отчет об оценке соответствия должен включать следующее:

а) указание на то. что влияние результатовоценки и тестирования (при наличии) относится только к оцениваемым и тестируемым компонентам;

19

ГОСТ Р ИСО/МЭК 25051—2017

Ь) указание на то. что отчет об оценке соответствия не может копироваться без предварительного письменного согласия лаборатории, где проводились испытания (за исключением случаев, когда отчет копируется полностью).

7.6 Контроль оценки соответствия требованиям

При повторной оценке RUSP сучетом проведенной ранееоценки соответствия необходимо следующее:

a)    все измененные части документации и компоненты программного обеспечения оцениваются так. как если бы они относились к новому RUSP;

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

c)    все прочие компоненты должны, по меньшей мере, оцениваться по образцам.

20

ГОСТ Р ИСО/МЭК 25051—2017

Приложение А

(справочное)

Рекомендации по оценке RUSP в приложениях, имеющих критическое значение для ведения бизнеса или обеспечения безопасности

А.1 Общая информация

Как правило. RUSP используются в приложениях, сопряженных с низким уровнем риска. Многие из них разрабатывались без учета рисков, связанных с безопасностью, ведением бизнеса, юридической стороной дела или целями организации. В приложениях, не имеющих критически важного значения, функции RUSP в случае выхода их из строя или неправильной рвботы в худшем случае приведут к неудовлетворенности пользователя их работой. 8 связи с чем разработчик должен обеспечить восстановление работы путем устранения дефектов, добавления и (или) удаления функций с целью повышения удовлетворенности пользователей. Во многих подобных случаях рыночная конъюнктуре не требует проведения серьезного тестирования и допускает наличие в готовых к использованию программных продуктах определенных дефектов.

Однако, если использование RUSP очевидным образом влияет на безопасность или ведение бизнеса, последствия неверного применения или тестирования RUSP могут быть куда более серьезными, возможности использования RUSP в денной среде включвют такие области, как авиация, медицинское оборудование, фармацевтике. космическая отрасль и исследования, телекоммуникации, строительство, бухгалтерский учет, подъемное оборудование, железные дороги, оборонные системы и прочее. Управление воздушными и железнодорожными перевозками, лечение раковыхбольных радиационным облучением, точность налоговой и бухгалтере кой отчетности и тому подобное — вот лишь немногие примеры систем, где деже одна ошибка может привести к серьезным последствиям. Функциональные требования к этим системам учтены в самых разных архитектурах оборудования и программного обеспечения, разработанных для широкого диапазона проектных задач. Некоторые проектные задачи могут быть реализованы в аппаратном обеспечении, например специализированные интегральные микросхемы и логические устройства с функцией электрического программирования, а другие задачи — в готовом к использованию программном продукте.

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

Конструктивные особенности программного обеспечения, которые может поддерживать RUSP. включают следующее.

А.2 Выявление неисправностей и адаптация, включая резервирование программного обеспечения

Выявление неисправностей представляет собой процесс проверки системы на наличие ошибочных состояний. С помощью методов адаптации неисправностей можно выявлять «безопасные состояния», при которых система функционирует должным образом. При помощи программ диагностики программное обеспечение производит самопроверку, в также проверку оборудования на наличие неверных результатов. Программы диагностики можно запусквть периодически или обеспечить их непрерывную работу в виде фоновых процессов. 8 качестве диагностических программ может применяться двойное (или более) дублирование расчетов, а также проверки при помощи циклического кода. При работе с критически важными функциями резервирования голосование между резервируемыми компонентами используется с целью принятия решения о правильности работы таких компонентов. (МЭК61508-7. раздел 11).

А.З Исправление неисправностей путем ловторениядействия

Исправление неисправностей путем повторения действия часто используется в коммуникационных системах. Этот метод не имеет распространения в быстрых системах, работающих в режиме реального времени. Системе производит самоанализ неисправностей и перезапускается в предыдущее безопасное состояние, после чего продолжает работу. При использовании в системах, работающих в режиме реального времени, необходимо убедиться в том. что восстановление может быть завершено до того, как неисправность проявит себя на внешнем системном уровне. (МЭК 61506-7. раздел 11]

А.4 Мультиверсионноепрограммирование

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

21

ГОСТ Р ИСО/МЭК 25051—2017

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

А.5 Программирование с блоками восстановления

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

А.6 Следование модели

Следование модели представляет собой метод, при котором элементарная модель компонента RUSP представлена в системе и используется для оценки правильной работы самого готового к использованию программного продукте. Модель может быть представлена любым количеством способов, начиная с простого поиска таблицы до полноценного представления модели в зависимости от сложности и требований, предъявляемых моделируемой функцией RUSP.

А.7 Надстройки

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

А.8 Методы, которые можно использовать для создания качественных характеристик RUSP

в таблице А.1 представлен список методов подтверждения, с помощью которых можно оценить целостность RUSP в приложении, подверженном высокой степени риска.

Таблице А.1— Инструкции по применению RUSP в приложениях, сопряженных с высоким риском

Функция

Цель

возможное действие

Защита памяти

Следует убедиться в том. что приложения защищены от доступа из несанкционированного адресного пространства

Проведение тестирования, в ходе которого осуществляется попытка выполнить, считать или записать операции вне пределов их заданного диапазона адресов

Защита от переполнения стека

Следует убедиться в том. что RUSP обеспечивает возможности для защиты от переполнения стека

Тестирование методом вызова функций, приводящих к переполнению стека. Следует убедиться в том. что выполнение задания приостанавливается ядром, либо задание повреждает всю систему

Использование объема динамически выделенной памяти

Следует проверить наличие у RUSP механизмов защиты ресурсов, чтобы предотвратить неограниченное использование ресурсов вредоносным заданием

Создание задачи, которая запрашивает память в виде бесконечного цикла, при том. что другой задаче требуется минимальный объем памяти. Следует убедиться в том. что предельная задача не повреждена готовым к использованию программным продуктом

Отказоустойчивость

Следует убедиться в том. что ядро способно восстановиться и зафиксировать событие, предшествующее сбою

Тестирование RUSP должно быть построено так. чтобы можно было продемонстрировать. могут ли фундаментальные характеристики RUSP дать возможность проектировщику системы обеспечить отказоустойчивость

Одновременные прерывания и вложенность прерываний

Следует определить, как долго системе необходимо реагировать на два одновременных прерывания

Измерение времени ожидания для обслуживания прерываний с высоким или низким приоритетом. В ходе выполнения тестирования должно измеряться время, необходимое системе для реагирования на два одновременных прерывания. Необходимо убедиться в том, что обработка прерывания имеет приоритет

22

ГОСТ Р ИСО/МЭК 25051—2017

Окончание таблицы А.1

Функция

Цепь

Возможное действие

Включение выбираемой опции или неактивный код

Следует убедиться в неумышленном выполнении выбираемой опции или неактивного кода

Проверка наличия каких-либо условий, которые могут вызывать активирование кода «бездействия», и проведения тестирование на наличие такого условия

Использование надстроек

Следует убедиться в том. используются ли надстройки для защиты компонента RUSP в системе или для создания маски нежелательной функции

Уточнение того, используются ли компоненты RUSP в контексте, который отличается от контекста изначального проекта

Оценка RUSP

Следует определить, насколько подходят функции RUSP. а также их влияние на конструкцию системы

Быстрая внутренняя оценка и (или) прототип

План RUSP

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

Подписание поставщиком плана управления RUSP

План CM/SQA для RUSP

Следует определить происхождение СМ и SOA на локальном уровне и на уровне поставщике RUSP

Подписание руководством и поставщиком RUSP планов CM/SQA. Проверка отчетов о проблемах, обеспечение контроля за версиями исходного и объектного кодов

SQCдляRUSP

Внутрисистемное и внесистемное тестирование RUSP

Подтверждение системных требований

План интеграции RUSP

Ппвн конфигурирования RUSP в системе

Специальное программное обеспечение для интеграции. Специальные программные платформы для правильной работы RUSP (выбор времени, деление, непреднамеренно выполняемые функции, влияние недействительного или неактивного кода)

Поддержка продукта

Определение доступности поддержки продукта

Оценка соответствия систем поддержки (меню справки, инструкций по эксплуатации, описаний продуктов, службы поддержки)

Предварительная сертификация и (или) квалификация

История обслуживания RUSP, включая любые продукты, контролируемые регулирующими органами

Определение того, включает ли в себя история обслуживания RUSP какие-либо критически важные приложения; проведите анализ работы в такой среде

Качество использования

Обеспечение объективных свидетельств (на базе тестирования и данных экспериментов, математического моделирования и симуляции) того, что RUSP а случае использования будет соответствовать определенным требованиям клиентов и пользователей

Подтверждение и валидация для демонстрации (посредством математического моделирования и симуляции) того, что RUSP подходит для данной цели и соответствует требованиям клиентов и пользователей

23

ГОСТ Р ИСО/МЭК 25051—2017

Приложение В

(справочное)

Порядок использования настоящего стандарта

Нестоящий стандарт можно использовать следующим образом:

•    требования высокого уровня к спецификации RUSP. а также требования к его качеству в виде исходных дан-ныхдля уточнения спецификаций согласно разделу 5;

•    требования к тестированию программного обеспечения как части RUSP: разработка документации по тестированию на базе требований, определенных в разделе 6:

•    демонстрация качества RUSP. т. в. демонстрация соответствия настоящему стандарту, проведение оценки соответствия согласно разделу 7. сертификация или гарантии поставщика на базе отчета об оценке соответствия.

Применение — Каждая из этих возможностей может быть реализована, только если была реализована предыдущая возможность (взаимозависимость).

Кроме этого, приложение А можно использовать для программного продукта, связанного с высоким риском при обеспечении безопасности или ведении бизнеса.

24

ГОСТ Р ИСО/МЭК 25051—2017

Приложение ДА

(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Обозначение ссы ночного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

ISO/IEC 25000

ISO/IEC 25010

IDT

ГОСТ Р ИСО/МЭК 25010—2015 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»

* Соответствующий национальный стандарт отсутствует. До его утверждений рекомендуется использовать перевод на русский язык данного международного стандарта.

Примечание—В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта:

• IDT — идентичный стандарт.

2S

ГОСТ Р ИСО/МЭК 25051—2017

Библиография

[1]    ISO/IEC Guide 2:2004. Standardization end related activities — General vocabulary

[2]    ISO/IEC 17050*1:2004. Conformity assessment — Supplier's declaration of conformity — Part 1: General requirements

[3]    ISO/IEC 17050*2:2004, Conformity assessment — Supplier's declaration of conformity—Part 2: Supporting documentation

[4]    ISO/IEC 12207:2008. Systems and software engineering — Software life cycle processes

[5]    ISO/IEC    TR 9126*2:2003. Software engineering — Product quality    —    Part 2: External metrics

[6]    ISO/IEC    TR 9126*3:2003. Software engineering — Product quality —    Part 3: internal metrics

[7]    ISO/IEC    TR 9126*4:2004. Software engineering — Product quality    —    Part 4: Quality in use metrics

[8]    ISO/IEC    9127. Software engineering — User documentation and    cover information for consumer software

packages1)

[9]    ISO/IEC 15026:2010. Information technology — System and software integrity levels

[10]    ISO/IEC 17025:2005. General requirements for the competence of testing and calibration laboratories

[11]    ISO 9241*1:1997. Ergonomic requirements for office work with visual display terminals (VOTs) — Part 1: General introduction

[12]    ISO 9241*2:1992. Ergonomic requirements for office work with visual display terminals (VOTs) — Part 2: Guidance on task requirements

[13]    ISO 9241-11:1998. Ergonomic requirements for office work with visual display terminals (VOTs)—Part 11: Guidance on usability

[14]    ISO 9241-12:1998. Ergonomic requirements for office work with visual display terminals (VOTs)—Part 12: Presentation of information

[15]    ISO 9241-13:1998. Ergonomic requirements for office work with visual display terminals (VOTs) — Part 13: User guidance

[16]    ISO 9241*14:1997. Ergonomic requirements for office work with visual display terminals (VOTs) — Part 14: Menu dialogues

[17]    ISO 9241-15:1997. Ergonomic requirements for office work with visual display terminals (VOTs)—Part 15: Command dialogues

[18]    ISO 9241-16:1999. Ergonomic requirements for office work with visual display terminals (VOTs) — Part 16: Direct manipulation dialogues

[19]    ISO/IEC 25062:2006. Software engineering — Software product Quality Requirements and Evaluation (SOuaRE) — Common Industry Format (CIF)for usability test reports

[20]    ISO/IEC 25021. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality measure elements

[21]    IEEE Std 610.12—1990. IEEE Standard Glossary of Software Englneenng Terminology

[22]    IEEE Std 829—2008. IEEE Standard for Software and System Test Documentation

[23]    IEEE Std 1044—2009. IEEE Standard Classification for Anomalies

" В процессе разработки.

26

ГОСТ Р ИСО/МЭК 25051—2017

УДК 004.05:006.354    ОКС 35.080    IDT

Ключевые слова: качество систем и программного обеспечения, готовый к использованию программный продукт (RUSP). инструкции по тестированию

27

БЗ 7—2017/117

Редактор А А. Кабанов Технический редактор 8.Н. Прусакова Корректор Дупъмова Компьютерная верстка А.Н. Зопотарввой

Сдано в набор 29.05.2017. Подписано а печать Ов.Ов.2017.    Формат 00 х 84    Гарнитура Ариал.

Уел. леч. п. 0.72. Уч.-иад. п. З.Эв. Тираж 30 эы. Эак 939.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ». >23995 Москва. Гранатный пер., 4. www.90slinto.1u