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

(утв. и введен в действие Приказом Росстандарта от 26.05.2017 № 448-ст)

1 марта 2018 года

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 мая 2017 г. № 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 for testing», IDT).

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

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

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

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

6 ПЕРЕИЗДАНИЕ. Январь 2019 г.

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

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

Введение

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

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

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

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

• Управление качеством (ИСО/МЭК 2500n);
• Модель качества (ИСО/МЭК 2501n);
• Измерение качества (ИСО/МЭК 2502n);
• Требования к качеству (ИСО/МЭК 2503n);
• Оценка качества (ИСО/МЭК 2504n);
• Расширения (ИСО/МЭК 25050 — ИСО/МЭК 25099).

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISO/IEC 25000 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE [Системная и программная инженерия. Требования к качеству систем и программного обеспечения и их оценка (SQuaRE). Руководство по 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 Термины и определения

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

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 В определение RUSP входят:

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

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

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

4.1.7

конечный пользователь (end user): Физическое лицо, которое в конечном итоге извлекает преимущества из функциональности готового к использованию программного продукта. Примечание — Конечный пользователь может быть штатным оператором программного продукта или случайным пользователем, например человеком со стороны. [ИСО/МЭК 25000:2005]

4.1.8

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

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]

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

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 — готовый к использованию программный продукт;

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

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 Описание продукта не должно содержать внутренних противоречий.

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

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

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

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

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

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

5.1.3.5 В описании продукта должны указываться документы с требованиями, если поставщик претендует на соответствие документации, выпущенной согласно законодательству или регулирующим органом, и это влияет на 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 В описании продукта должен содержаться обзор функций продукта, которые могут быть приобретены конечным пользователем.

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

Примечания

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

• потеря данных;
• зависание.

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

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

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

• минимальные и максимальные значения;
• длина ключей;
• максимальное количество записей в файле;
• максимальное количество критериев поиска;
• минимальный размер выборки.

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

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

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

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

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

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

• конфигурации системы;
• ресурсы, необходимые для эффективной работы с 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 В описании продукта должен быть указан тип интерфейса пользователя.

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

• командная строка;
• меню;
• окно;
• функциональная клавиша.

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

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

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

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

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

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

• программируемые даты истечения сроков эксплуатации;
• интерактивные напоминания об оплате используемых копий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

• операционные системы;
• элементы процессора, в том числе сопроцессоры;
• объем основной памяти;
• типы и размеры периферийных хранилищ;
• карты расширений;
• устройства ввода и вывода;
• сетевое оборудование;
• системное программное обеспечение и прочее ПО.

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

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 В документации пользователя должна содержаться информация, необходимая для использования программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.7 Понятность

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

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

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

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

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

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

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

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

• название программного и (или) аппаратного обеспечения;
• версия;
• определенная операционная система.

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

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 Все упоминаемые в документации пользователя функции должны выполняться с соответствующими аппаратными устройствами, свойствами и данными, а также в рамках заданных ограничений и в соответствии со всеми сообщениями, содержащимися в документации пользователя.

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 Сообщения (вопросы, инструкции и т.п.) и результаты работы программного обеспечения должны быть доступными для понимания.

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

• правильной терминологией;
• графическими элементами;
• предоставлением справочной информации;
• предоставлением справочной системы;
• четким и легко читаемым текстом или графическими материалами;
• хорошо распознаваемым на слух аудиоматериалом.

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

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

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

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

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

• подтверждения;
• запросы от программного обеспечения;
• информация;
• предупреждения;
• сообщения об ошибках.

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 Работа программного обеспечения должна соответствовать функциям удобства сопровождения, указанным в документации пользователя.

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

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

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

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

• экран данных;
• модель базы данных;
• подпрограмма;
• интерфейс.

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 Согласованность

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) идентификатор документов, на которые даются ссылки в основной части документа;

f) информацию о составителях и проверяющих;

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

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

6.1.4 Подход

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

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

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

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

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

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

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

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

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

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

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

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

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

• анализа граничных значений;
• контрольного списка (чек-лист);
• анализа потоков данных;
• вставки ошибок;

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

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

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 В плане тестирования должны указываться критерии, которые использовались для принятия решения о том, насколько результаты тестирования демонстрируют соответствие программного обеспечения описанию продукта или документации пользователя.

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

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

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

6.2.3 График

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

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

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

6.2.4 Риски

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) список выявленных отклонений;

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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. При этом не создается та часть документации, которая относится к устранению несоответствий и подтверждению такового путем повторного тестирования (6.4.2.3 - 6.4.2.6).

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

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 В процессе оценки соответствия может создаваться дополнительная документация по тестированию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение A (справочное)

РЕКОМЕНДАЦИИ ПО ОЦЕНКЕ RUSP В ПРИЛОЖЕНИЯХ, ИМЕЮЩИХ КРИТИЧЕСКОЕ ЗНАЧЕНИЕ ДЛЯ ВЕДЕНИЯ БИЗНЕСА ИЛИ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица A.1

Инструкции по применению RUSP в приложениях, сопряженных с высоким риском

Функция	Цель	Возможное действие
Защита памяти	Следует убедиться в том, что приложения защищены от доступа из несанкционированного адресного пространства	Проведение тестирования, в ходе которого осуществляется попытка выполнить, считать или записать операции вне пределов их заданного диапазона адресов
Защита от переполнения стека	Следует убедиться в том, что RUSP обеспечивает возможности для защиты от переполнения стека	Тестирование методом вызова функций, приводящих к переполнению стека. Следует убедиться в том, что выполнение задания приостанавливается ядром, либо задание повреждает всю систему
Использование объема динамически выделенной памяти	Следует проверить наличие у RUSP механизмов защиты ресурсов, чтобы предотвратить неограниченное использование ресурсов вредоносным заданием	Создание задачи, которая запрашивает память в виде бесконечного цикла, при том, что другой задаче требуется минимальный объем памяти. Следует убедиться в том, что предельная задача не повреждена готовым к использованию программным продуктом
Отказоустойчивость	Следует убедиться в том, что ядро способно восстановиться и зафиксировать событие, предшествующее сбою	Тестирование RUSP должно быть построено так, чтобы можно было продемонстрировать, могут ли фундаментальные характеристики RUSP дать возможность проектировщику системы обеспечить отказоустойчивость
Одновременные прерывания и вложенность прерываний	Следует определить, как долго системе необходимо реагировать на два одновременных прерывания	Измерение времени ожидания для обслуживания прерываний с высоким или низким приоритетом. В ходе выполнения тестирования должно измеряться время, необходимое системе для реагирования на два одновременных прерывания. Необходимо убедиться в том, что обработка прерывания имеет приоритет
Включение выбираемой опции или неактивный код	Следует убедиться в неумышленном выполнении выбираемой опции или неактивного кода	Проверка наличия каких-либо условий, которые могут вызывать активирование кода «бездействия», и проведение тестирования на наличие такого условия
Использование надстроек	Следует убедиться в том, используются ли надстройки для защиты компонента RUSP в системе или для создания маски нежелательной функции	Уточнение того, используются ли компоненты RUSP в контексте, который отличается от контекста изначального проекта
Оценка RUSP	Следует определить, насколько подходят функции RUSP, а также их влияние на конструкцию системы	Быстрая внутренняя оценка и (или) прототип
План RUSP	Следует определить лицензионные, арендные соглашения и договоры об обслуживании, доступ к отчетам о проблемах и потенциальную необходимость доступа к исходному коду	Подписание поставщиком плана управления RUSP
План CM/SQA для RUSP	Следует определить происхождение CM и SQA на локальном уровне и на уровне поставщика RUSP	Подписание руководством и поставщиком RUSP планов CM/SQA. Проверка отчетов о проблемах, обеспечение контроля за версиями исходного и объектного кодов
SQC для RUSP	Внутрисистемное и внесистемное тестирование RUSP	Подтверждение системных требований
План интеграции RUSP	План конфигурирования RUSP в системе	Специальное программное обеспечение для интеграции. Специальные программные платформы для правильной работы RUSP (выбор времени, деление, непреднамеренно выполняемые функции, влияние недействительного или неактивного кода)
Поддержка продукта	Определение доступности поддержки продукта	Оценка соответствия систем поддержки (меню справки, инструкций по эксплуатации, описаний продуктов, службы поддержки)
Предварительная сертификация и (или) квалификация	История обслуживания RUSP, включая любые продукты, контролируемые регулирующими органами	Определение того, включает ли в себя история обслуживания RUSP какие-либо критически важные приложения; проведите анализ работы в такой среде
Качество использования	Обеспечение объективных свидетельств (на базе тестирования и данных экспериментов, математического моделирования и симуляции) того, что RUSP в случае использования будет соответствовать определенным требованиям клиентов и пользователей	Подтверждение и валидация для демонстрации (посредством математического моделирования и симуляции) того, что RUSP подходит для данной цели и соответствует требованиям клиентов и пользователей

Приложение B (справочное)

ПОРЯДОК ИСПОЛЬЗОВАНИЯ НАСТОЯЩЕГО СТАНДАРТА

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

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

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

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

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 25000	-	<*>
ISO/IEC 25010	IDT	ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов»
<*> Соответствующий национальный стандарт отсутствует. До его утверждения рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: - IDT — идентичный стандарт.

БИБЛИОГРАФИЯ

[1]	ISO/IEC Guide 2:2004	Standardization and 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 packages <1>
[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 (VDTs) — Part 1: General introduction
[12]	ISO 9241-2:1992	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 2: Guidance on task requirements
[13]	ISO 9241-11:1998	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability
[14]	ISO 9241-12:1998	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 12: Presentation of information
[15]	ISO 9241-13:1998	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 13: User guidance
[16]	ISO 9241-14:1997	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 14: Menu dialogues
[17]	ISO 9241-15:1997	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 15: Command dialogues
[18]	ISO 9241-16:1999	Ergonomic requirements for office work with visual display terminals (VDTs) — Part 16: Direct manipulation dialogues
[19]	ISO/IEC 25062:2006	Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — 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 Engineering Terminology
[22]	IEEE Std 829-2008	IEEE Standard for Software and System Test Documentation
[23]	IEEE Std 1044-2009	IEEE Standard Classification for Anomalies

---

<1> В процессе разработки.

УДК 004.05:006.354	ОКС 35.080
Ключевые слова: качество систем и программного обеспечения, готовый к использованию программный продукт (RUSP), инструкции по тестированию

---