Товары в корзине: 0 шт Оформить заказ
Стр. 1 

41 страница

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

 Скачать PDF

Идентичен ISO/IEC 25010:2011

Оглавление

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

     1.1 Характеристики

     1.2 Уровень оценки

     1.3 Метод

     1.4 Применимость

2 Соответствие

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

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

5 Входные данные и показатели

     5.1 Методика оценки

     5.2 Входные данные для оценки

     5.3 Элементы данных

     5.4 Показатели качества

6 Интерпретация результатов

     6.1 Представление показателей

     6.2 Создание отчета

     6.3 Процедура подачи заявки

Приложение А (справочное) Пример отчета

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

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

 

41 страница

Дата введения01.06.2016
Добавлен в базу01.02.2017
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

29.05.2015УтвержденФедеральное агентство по техническому регулированию и метрологии466-ст
РазработанООО ИАВЦ
ИзданСтандартинформ2016 г.

Information technology. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Evaluation module for recoverability

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

ГОСТ Р исо/мэк

25045-

2015

Информационные технологии

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

ISO/IEC 25045:2010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) —

Evaluation module for recoverability (IDT)

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

Москва Стандартен форм 2016

Предисловие

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

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

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

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 25045:2010 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости» (ISO/IEC 25045:2010 «Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Evaluation module for recoverability»).

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

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

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

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

© Стандартинформ, 2016

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

ГОСТР ИСО/МЭК 25045—2015

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

Продолжительность интервала прогона зависит от рабочей нагрузки. Большие рабочие нагрузки с более высокой пропускной способностью, как правило, требуют более длительного периода разгона для достижения устойчивого состояния, при котором можно начать измерения. Вот один из примеров, который можно использовать для определения баланса между эффективностью и временем, необходимым тестируемой системе для обнаружения вводимых возмущений и восстановления после их воздействия. Для выполнения базовой фазы системе позволяют прогреться в течение 5 мин, а следующие 50 мин используются непосредственно для базовой фазы. Для тестового прогона системе позволяют прогреться в течение 5 мин, а затем начинают 50-минутную фазу тестирования, которая разбита на 10-минутный инъекционный интервал, 20-минутный объединенный интервал обнаружения и инициирования восстановления и 20-минутный интервал восстановления и задержки.

5.1.2 Возмущающие воздействия

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

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

ниже.

5.1.2.1 Неожиданное завершение работы

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

Таблица 1 — Возмущающие воздействия для неожиданного завершения работы

Наименование возмущения

Описание

Неожиданное завершение работы операционной системы для приложений СУБД, HTTP и серверов обмена сообщениями

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

Неожиданное завершение работы процесса для приложений СУБД, HTTP и серверов обмена сообщениями

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

Отключение сетевого соединения для приложений СУБД, HTTP и серверов обмена сообщениями

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

5.1.2.2 Состязание за ресурсы

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

Таблица 2 — Возмущающие воздействия для состязания за ресурсы

Наименование возмущения

Описание

Захват памяти в СУБД, приложении, серверах HTTP и обмена сообщениями

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

Захват ввода-вывода на сервере СУБД

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

Неконтролируемый запрос к СУБД

Этот сценарий возмущения представляет собой случай выполнения СУБД неконтролируемого запроса. Он предназначен для моделирования ситуации случайной выдачи в процессе обычной работы запроса, которая требует затрат значительного времени и других ресурсов запроса. Не следует путать такой запрос с пакетом меньших выполнимых запросов

Лавинная рассылка опасных сообщений с сервера обмена сообщениями

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

Исчерпание объема хранения данных для СУБД и сервера обмена сообщениями

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

Захват сети сервером HTTP, приложений, СУБД или обмена сообщениями

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

Тупиковая ситуация на сервере СУБД

Этот сценарий возмущения представляет собой случай, когда одно или несколько приложений блокируют значительное количество ресурсов СУБД (записей или таблиц), что делает их недоступными для других приложений. Любые запросы к СУБД на эти заблокированные ресурсы не будут завершаться успешно

Неосвобождение памяти пользовательским приложением

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

5.1.2.3 Потеря данных

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

Таблица 3 — Возмущающие воздействия для потери данных

Наименование возмущения

Описание

Потеря файла СУБД

Этот сценарий возмущения представляет собой потерю в базе данных файла, который содержит критические для бизнеса данные. Он предназначен для моделирования ситуации, когда оператор случайно вводит команду операционной системе на удаление одного или более файлов СУБД, которые содержат данные определенного объекта базы данных. СУБД уже не может обращаться к этому файлу в составе файловой системы. Эта ситуация отличается от потери дескриптора файла ОС, которая относится к ошибкам в операционной системе

Потеря диска СУБД и системой обмена сообщениями

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

5.1.2.4 Реакция на загрузку

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

Т аблица 4 — Возмущающие воздействия для реакции на загрузку

Наименование возмущения

Описание

Значительное увеличение загрузки и реакция

Этот сценарий возмущения представляет собой случай, когда нагрузка на тестируемую систему резко увеличивается (обычно примерно в 10 раз по сравнению с предыдущей нагрузкой). Он предназначен для моделирования ситуации, при которой из-за чрезвычайного события или отказа основной системы значительно увеличилась нагрузка. Наилучшим результатом обработки этого возмущения является возможность обработки, по крайней мере, того же количества информации, что и прежде, без перезагруженное™ экстремальным увеличением запросов. Иллюстрируют эту характеристику технологии управления потоками и качеством мониторов службы

5.1.2.5 Обнаружение отказа перезапуска

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

Таблица 5 — Возмущающие воздействия для отказа перезапуска

Наименование возмущения

Описание

Отказ перезапуска процесса приложения СУБД и серверов HTTP и обмена сообщениями

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

5.2 Входные данные для оценки

Примечание — В А.5 —А.8 в образце отчета приводится пример входных данных, перечисленных далее.

5.2.1    Описание тестируемой системы

5.2.1.1    Спецификация конфигурации аппаратных средств и операционной системы

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

- поставщики номер модели;

-    дата эксплуатационной готовности системы;

-    ЦП (тип процессоров, число и скорость процессоров (МГц/ГГц));

-    кэш (LI, L2, L3 ит. д.);

-    оперативная память (в мегабайтах);

-    используемые диски и файловая система;

-    сетевой интерфейс;

-    количество систем с точно такой же конфигурацией;

-    операционная система (название продукта, поставщик и дата эксплуатационной готовности);

-    параметры настройки операционной системы и опции, значения которых были изменены со значений по умолчанию;

-    настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке операционной системы;

-    логическое или физическое разделение, используемое этой системой для размещения экземпляров программного обеспечения;

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

5.2.1.2    Спецификация конфигурации компонентов программного обеспечения

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

-    имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

-    параметры настройки и опции, значения которых были изменены со значений по умолчанию;

-    настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

-    количество экземпляров продукта в каждой системе.

5.2.1.3    Прикладные программы

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

-    имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

-    параметры настройки и опции, значения которых были изменены со значений по умолчанию;

-    настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

-    число экземпляров в каждой системе.

5.2.1.4    Дополнительное необходимое программное обеспечение

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

-    имя поставщика, название продукта, его версия и дата эксплуатационной готовности;

-    настройка параметров и опций изменилась со значений по умолчанию;

-    настройки компиляции, компоновки и оптимизации времени выполнения, использованные при построении/установке компонентов программного обеспечения;

-    число экземпляров в каждой системе.

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

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

5.2.1.5    Хранимые данные

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

-    файлы с данными, требуемыми для корректного вычисления;

ГОСТР ИСО/МЭК 25045—2015

-    те файлы выходных данных, используемые программами, которые не являются пустыми перед запуском теста;

-    данные из системы базы данных.

5.2.1.6 Дополнительная информация для обоснования

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

5.2.2 Описание рабочей нагрузки

5.2.2.1    Спецификация рабочей нагрузки

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

-    описание тестируемой транзакции или операции;

-    описание тестовых данных;

-    сценарии тестирования.

Ъ.2.2.2 Набор параметров рабочей нагрузки

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

-    общее количество пользователей;

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

-    учетный интервал (в секундах), в течение которого в ходе прогона учитывается скорость транзакций;

-    состав смеси транзакции рабочей нагрузки (например, 10 % — новые заказы, 20 % — запросы состояния и т. д.);

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

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

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

5.2.2.3    Набор параметров для доказательства состоятельности и устойчивости рабочей нагрузки

Для правильной оценки эффекта инъекции возмущения необходимо показать повторяемость и

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

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

-    статистическая значимость результатов измерений должна быть включена в отчет;

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

5.2.3    Описание ввода неисправности

5.2.3.1    Спецификация ввода неисправности

9

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

5.2.3.2    Набор параметров ввода неисправности

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

-    интервал измерения (в секундах), называемый также продолжительностью инъекционного периода;

-    инъекционный интервал (в секундах);

-    интервал обнаружения (в секундах).

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

5.2.3.3    Анкета автономной завершенности

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

5.3    Элементы данных

Примечание — В А.9 — А.11 в демонстрационном отчете приводится пример выходных данных, описанных далее.

5.3.1    Выходные данные выполнения базового прогона

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

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

-    интервал измерения;

-    отчетны й интервал (например, каждые 30 с ил и каждые 10 мин и т. д. в течение прогона под рабочей нагрузкой);

-    общее число транзакций, завершенных без ошибки в интервале измерения и между отчетными интервалами;

-    общее число транзакций, завершенных с ошибками в интервале измерения;

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

5.3.2    Выходные данные тестового прогона

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

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

-    интервал измерения (в секундах);

-    инъекционный интервал (в секундах);

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

-    отчетный интервал (в секундах, например, каждые 30 с или каждые 10 мин и т. д. в течение всего тестирования);

-    общее число транзакций, завершенных без ошибки в интервале измерения и между каждым отчетным интервалом;

-    общее число транзакций, завершенных с ошибками в интервале измерения;

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

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

ГОСТР ИСО/МЭК 25045—2015

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

5.3.3 Заполнение анкеты автономной завершенности

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

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

5.4 Показатели качества

Примечание — В А.2 и А. 10 приводятся примеры отчетов, содержащих описанные далее выходные данные.

5.4.1    Показатели качества и элементы показателя качества (ЭПК)

Характеристика качества — надежность.

Подхарактеристика качества — восстанавливаемость:

-    показатель качества — способность к восстановлению:

-    ЭПК — число транзакции под возмущением — число завершенных без ошибок транзакций в интервале измерения при условии, что возмущение(я) введено(ы);

-    ЭПК — число транзакций без каких-либо возмущений — число завершенных без ошибоктран-закций в интервале измерения при условии, что возмущающие воздействия не введены;

-    показатель качества — индекс автономного восстановления:

-    ЭПК — автономная оценка завершенности.

В следующих пунктахописаны другие показатели качества и элементы показателя качества.

5.4.2    Показатель качества — способность к восстановлению

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

Наименование показателя — способность к восстановлению.

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

Методика применения приведена в 5.1.

Измерение, формула и вычисление значения элемента данных. Для каждого возмущения вычисляется отношение

Pi/Pbase,

где Pj — число завершенных без ошибок транзакций в интервале измерения инъекционного периода в условиях введенного возмущения;

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

Общая способность к восстановлению вычисляется как среднее от способностей к восстановлению для каждого инъекционного периода.

Интерпретация измеренного значения: х>0. Чем больше значение, тем лучше. (На практике значение, как правило, лежит в интервале 0 <х<1, однако, теоретически возможно, что величина может превысить значение 1 в том случае, если производительность системы под возмущением выше производительности без возмущений).

Тип шкалы показателя — абсолютный.

Тип измерения Р# и Phase — подсчет.

Входные данные для измерения — отчет о тестировании.

Ссылки: ИСО/МЭК 12207:2008 «Системная и программная инженерия. Процессы жизненного цикла программного обеспечения» (пункт 6.4.5 «Процесс системной интеграции», пункт 6.4.6 «Процесс квалификационного тестирования систем», пункт 6.4.9 «Процесс эксплуатации программного обеспечения»).

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

5.4.3    Показатель качества — индекс автономного восстановления

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

Наименование показателя — индекс автономного восстановления.

11

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

Методика применения.

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

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

Таблица 6 — Уровни автономности

Уровень автономности

Описание

Вазовый

Управление компонентами ИТ осуществляется действиями на основе отчетов, продуктов и инструкций

Управляемый

Программные продукты обеспечивают упрощение и автоматизацию задач ИТ на месте

Прогнозирующий

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

Адаптивный

Компоненты ИТ в совокупности в состоянии контролировать, анализировать и принимать меры с минимальным вмешательством человека

Автономный

Компоненты ИТ в совокупности управляемы автоматически на основе бизнес-правил и политик

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

-    А (базовый уровень) — 0 баллов;

-    ВО (базовый/управляемый) — 0,5 балла;

-    В (управляемый) — 1 балл;

-    С (прогнозирующий) — 2 балла;

-    D (адаптивный) — 3 балла;

-    Е (автономный) — 4 балла.

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

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

-    Каким образом было обнаружено возмущение?

А: служба поддержки сообщила операторам о многочисленных жалобах;

ВО: операторы самостоятельно обнаружили проблему на основе мониторинга нескольких источников данных;

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

С: автономная управляющая программа уведомила оператора о возможной проблеме;

D: автономная управляющая программа обнаружила проблему без участия человека;

Е: то же, что и в случае «D». Однако «Е» выбирается только в случае ответа на следующий вопрос: «Каким образом осуществляется анализ возмущения?», т.е. если система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, что обеспечивает принятие мер без участия человека;

-    Каким образом осуществляется анализ возмущения?

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

В: оператор анализирует данные, полученные от единственного инструмента управления;

С: система осуществляет мониторинг и анализ данных, что ведет к рекомендуемым действиям по восстановлению;

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

ГОСТР ИСО/МЭК 25045—2015

Е: система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, что обеспечивает принятие мер безучастия человека;

- Какие действия предпринимаются?

А: оператор выполняет требуемые процедуры и выдает команды отдельно для каждого затронутого ресурса;

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

С: оператор подтверждает и инициирует действия восстановления;

D: автономная система инициирует действия восстановления. Никаких действий от человека не требуется;

Е: тоже, что и в случае «D». Однако «Е» выбирается только в случае ответа на следующий вопрос: «Каким образом осуществляется анализ возмущения?», т. е. если система осуществляет мониторинг и анализ данных на основе бизнес-правил и политик, то обеспечивает принятие мер безучастия человека.

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

Общий индекс автономного восстановления вычисляется как среднее значение по всем инъекционным периодам, нормализованное к самому высокому возможному значению уровня автономности (т. е. к 4). Результатом будет число от 0 до 1.

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

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

Интерпретация измеренного значения: 0 <х < 1. Чем ближе значение к 1, тем лучше считается результат.

Тип шкалы показателя — абсолютный.

Тип измерения — подсчет.

Входные данные для измерения — записи мониторинга пользователей.

Ссылки: ИСО/МЭК 12207:2008 «Системная и программная инженерия. Процессы жизненного цикла программного обеспечения» (пункт 6.4.5 «Процесс системной интеграции», пункт 6.4.6 «Процесс квалификационного тестирования систем», пункт 6.4.9 «Процесс эксплуатации программного обеспечения»).

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

5.4.4 Элемент показателя качества (ЭПК). Число транзакций под возмущением

Таблица 7 — ЭПК. Число транзакций под возмущением

Информация

Описание

Название ЭПК

Число транзакций под возмущением

Идентификатор ЭПК

Определение

Число завершенных без ошибок транзакций в интервале измерения в условиях введенного возмущения

Метод измерения

Подсчет

Детали

Берется число транзакций из отчета работы или тестирования под рабочей нагрузкой в соответствии с 5.4.1

Документация

Аспект — Масштаб измерения

Отношение

Аспект — Фокус измерения

Внешний

Аспект — Метод измерения

Объективный

Входные данные

Отчет о работе.

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

Используется для вычисления

Способность к восстановлению

5.4.5 Элемент показателя качества (ЭПК). Число транзакций без возмущений

Таблица 8 — ЭПК. Число транзакций без возмущений

Информация

Описание

Название ЭПК

Число транзакций без возмущений

Идентификатор ЭПК

Определение

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

Метод измерения

Подсчет

Документация

Аспект — Масштаб измерения

Отношение

Аспект — Фокус измерения

Внешний

Детали

Берется число транзакции из отчета работы или тестирования под нагрузкой

Аспект — Метод измерения

Объективный

Входные данные

Отчет о работе.

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

Используется для вычисления

Способность к восстановлению

5.4.6 Элемент показателя качества (ЭПК). Индекс автономной завершенности

Таблица 9 — ЭПК. Индекс автономной завершенности

Информация

Описание

Название ЭПК

Индекс автономной завершенности

Определенный идентификатор ЭПК

Определение

Подсчет на основе ответов на вопросы анкеты автономной завершенности, присваивая различное количество баллов соответственно одному из шести ответов

Метод измерения

Подсчет

Детали

Определяется в соответствии с 5.4.2 настоящего стандарта

Документация

Аспект — Масштаб измерения

Отношение

Аспект — Фокус измерения

Внешний

Аспект — Метод измерения

Субъективный

Входные данные

Отчет о работе.

Отчет по тестированию. Мониторинг тестирования

Используется для вычисления

Индекс автономного восстановления

6 Интерпретация результатов

6.1    Представление показателей

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

6.2    Создание отчета

В отчет должны входить следующие пункты:

ГОСТР ИСО/МЭК 25045—2015

Содержание

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

1.1    Характеристики...................................................1

1.2    Уровень оценки...................................................1

1.3    Метод.........................................................1

1.4    Применимость....................................................2

2    Соответствие.......................................................2

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

4    Термины и определения................................................3

5    Входные данные и показатели.............................................3

5.1    Методика оценки..................................................3

5.2    Входные данные для оценки...........................................7

5.3    Элементы данных.................................................10

5.4    Показатели качества...............................................11

6    Интерпретация результатов.............................................14

6.1    Представление показателей..........................................14

6.2    Создание отчета..................................................14

6.3    Процедура подачи заявки............................................15

Приложение А (справочное) Пример отчета.....................................16

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации.........................32

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

ГОСТР ИСО/МЭК 25045—2015

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

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

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

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

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

-    элементы данных, определенные в 5.3, и показатели качества, определенные в 5.4;

-    графики для базового и тестового прогонов для каждого возмущения для визуализации каждого интервала измерения и инъекционного периода. ОсьХграфика должна представлять собой время, а ось У — количество транзакций;

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

Пример отчета приводится в приложении А.

6.3 Процедура подачи заявки

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

15

Введение

Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) формируют специализированную систему для всемирной стандартизации. Национальные органы по стандартизации, являющиеся членами ИСО или МЭК, участвуют в разработке международных стандартов через технические комитеты, созданные соответствующей организацией для рассмотрения вопросов конкретных сфер технической деятельности. Технические комитеты ИСО и МЭК сотрудничают в сферах, представляющих взаимный интерес. Другие правительственные и неправительственные международные организации, взаимодействующие с ИСО и МЭК, также принимают участие в работе. В сфере информационной технологии ИСО и МЭК создали совместный технический комитет ИСО/МЭК СТК 1.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, Часть 2.

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

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

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

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

-    раздел «Менеджмент качества» (ИСО/МЭК2500п);

-    раздел «Модель качества» (ИСО/МЭК2501 п);

-    раздел «Измерение качества» (ИСО/МЭК 2502п);

-    раздел «Требования к качеству» (ИСО/МЭК 2503п);

-    раздел «Оценка качества» (ИСО/МЭК2504п).

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

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

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

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

SQuaRE обеспечивает:

-    термины и определения;

ГОСТР ИСО/МЭК 25045—2015

-    эталонные модели;

-    общее руководство;

-    отдельные разделы руководства;

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

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

Серия стандартов SQuaRE замещает серии стандартов ИСО/МЭК 9126 и ИСО/МЭК 14598.

ИСО/МЭК 25040 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Эталонная модель и руководство по измерениям» заменяет часть ИСО/МЭК 14598-1 «Информационные технологии. Оценка программного продукта. Часть 1. Общие положения».

ИСО/МЭК 25041 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модули оценки» заменяет ИСО/МЭК 14598-6 «Программная инженерия. Оценка продукта. Документация модулей оценки».

ИСО/МЭК 25001 «Программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и менеджмент» заменяет ИСО/МЭК 14598-2 «Программная инженерия. Оценка продукта. Часть 2. Планирование и менеджмент».

На рисунке 1 показана организация серии международных стандартов SQuaRE, которая представлена семействами стандартов, называемых также разделами.

Раздел «Модель качества» 2501п

Раздел «Требования к качеству» 2503п

Раздел «Менеджмент качества» 2500л

Раздел

«Оценка

качества»

2504л

Раздел «Измерение качества» 2502л

Рисунок 1 — Организация серии международных стандартов SQuaRE

В модель SQuaRE входят следующие разделы:

-    ИСО/МЭК 2500п — раздел «Менеджмент качества». Международные стандарты, входящие в данный раздел, определяют общие модели, термины и определения, используемые во всех других стандартах серии SQuaRE. Направляющие ссылки, используемые во всех документах SQuaRE, и высокоуровневые практические предложения по применению соответствующих стандартов в случаях конкретных приложений помогут всем потребителям. В разделе также представлены требования и методические материалы, касающиеся поддерживающей функции, отвечающей за менеджмент требований к программной продукции, спецификацию и оценку;

-    ИСО/МЭК 2501 п — раздел «Модель качества». Международные стандарты, которые входят в данный раздел, представляют детализированные модели качества программного обеспечения, качества при использовании и качества данных. Кроме того, в них представлено практическое руководство по использованию модели качества;

-    ИСО/МЭК2502п — раздел «Измерение качества». Международные стандарты, входящие в данный раздел, включают в себя эталонную модель измерения качества программной продукции, математические определения показателей качества и практическое руководство по их использованию. В данном разделе представлены показатели внутреннего качества программного обеспечения, показатели внешнего качества программного обеспечения и показатели качества при использовании. Кроме того, в них определены и представлены элементы показателей качества (ЭПК), формирующие основу для вышеперечисленных показателей;

V

-    ИСО/МЭК 2503п — раздел «Требования к качеству». Международные стандарты, которые входят в данный раздел, помогают сформулировать требования к качеству. Такие требования к качеству могут использоваться в процессе формирования требований к качеству, при сборе информации перед разработкой программной продукции или как исходные данные для процесса оценки. Процесс определения требований отнесен к техническим процессам, определенным в ИСО/МЭК 15288 «Системная и программная инженерия. Процессы жизненного цикла систем»;

-    ИСО/МЭК 2504п — раздел «Оценка качества». Международные стандарты, которые входят в данный раздел, формулируют требования, рекомендации и методические материалы для оценки качества программного продукта, выполняемой как независимыми оценщиками, таки приобретателями или разработчиками. Кроме того, в них представлена поддержка документирования измерения как модуля оценки.

Настоящий стандарт является частью раздела оценки качества (ИСО/МЭК 2504л), в который входят следующие международные стандарты (см. рисунок 1):

-    ИСО/МЭК 25040 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Процесс оценки» содержит общие требования к спецификации и оценке качества программного обеспечения, а кроме того, и общие понятия. В нем содержится также описание процесса оценки качества программного продукта и устанавливаются требования для использования этого процесса. Процесс оценки является основой оценки качества программной продукции для различных целей и подходов. Поэтому процесс может использоваться для оценки показателей внешнего и внутреннего качества программного обеспечения, а также показателей качества при использовании. Кроме того, процесс может быть применен для оценки качества как уже разработанного программного обеспечения, так и заказанного программного обеспечения в процессе его разработки. Оценка качества программного продукта может быть произведена, например, приобретателем, организацией разработчика, поставщиком или независимым оценщиком;

-    ИСО/МЭК 250421) «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модули оценки» определяет структуру и содержание документации, которую следует использовать для описания модуля оценки. Данные модули оценки содержат спецификацию модели качества (то есть характеристики, подхарактеристики и соответствующие показатели внутреннего, внешнего качества или показатели качества при использовании), соответствующие данные, а также информацию о планируемом использовании модели и информацию о ее фактическом применении. Для каждой оценки выбираются соответствующие модули оценки. В некоторых случаях, возможно, потребуется разработка новых модулей оценки. Руководство по разработке новых модулей оценки можно найти в ИСО/МЭК 25042. Данный международный стандарт также может использоваться организациями, разрабатывающими новые модули оценки;

1)

-    ИСО/МЭК 25045 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости» приводит спецификацию оценки подхарактеристики восстанавливаемости, определенной как подмножество характеристик надежности из модели качества. В связи с тем, что время простоя зачастую имеет серьезные экономические и другие последствия, особую важность имеет способность программного продукта, а следовательно, и системы оставаться в рабочем состоянии или восстанавливаться в течение приемлемого интервала времени. Все больше внимания уделяется способностям программной продукции работать автономно и, как следствие этого, системам, функционирующим с минимальным участием человека. В связи с этим определенный интерес, как со стороны пользователей, так и со стороны промышленности, представляет вопросотом, насколько хорошо программный продукт, а следовательно, и система обрабатывает конкретные возмущающие воздействия — как их обнаруживает, анализирует, корректирует и восстанавливается. Данный международный стандарт определяет показатели качества — способность к восстановлению и индекс автономного восстановления в случае, когда выполняющая операции информационная система, состоящая из одного или более программных продуктов, подвергается серии возмущающих воздействий. Возмущающее воздействие может быть операционным сбоем (например, внезапным завершением процесса работы операционной системы, которое приводит систему в нерабочее состояние) или событием (например, существенным увеличением числа пользователей системы), или чем-либо иным, что может вызвать изменение состояния системы.

В процессе подготовки.

VI

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

Информационные технологии

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

восстанавливаемости

Information technologies. Systems and software engineering. Systems and software Quality Requirements and Evaluation (SQuaRE). Evaluation module for recoverability

Дата введения — 2016—06—01

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

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

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

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

1.1    Характеристики

Данный модуль оценки измеряет показатели качества, определенные для следующих указанных ниже характеристик и подхарактеристик модели качества, как установлено в ИСО/МЭК 9126-1.

Примечание — Ссылка на ИСО/МЭК 9126-1 будет заменена ссылкой на ИСО/МЭК 25010 после публикации последнего.

Характеристика — надежность.

Подхарактеристика — восстанавливаемость:

-    показатель качества — способность к восстановлению;

-    показатель качества — индекс автономного восстановления.

1.2    Уровень оценки

Уровень оценки — D, как это определено в ИСО/МЭК 14598-5. Данная оценка предназначена для систем, состоящих из исполнимых продуктов.

Примечание — Ссылка на ИСО/МЭК 14598-5 будет заменена ссылкой на ИСО/МЭК 25040 после публикации последнего.

1.3    Метод

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

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

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

-    неожиданное завершение работы — например, внезапное завершение работы операционной системы (ОС), завершение работы процессора, завершение работы сети;

-    конкуренция за ресурсы — например, процессор/память/ввод-вывод, неосвобождение памяти, очередь запросов к системе управления базой данных (СУБД), блокирование СУБД, переполнение очереди к СУБД и хранилищу сервера;

-    потеря данных — например, потеря данных СУБД, потеря файла СУБД, потери организации очередей СУБД и диска сервера;

-    реакция на загрузку — например, умеренное или существенное увеличение числа пользователей или рабочей нагрузки;

-    отказы перезапуска — например, отказ перезапуска операционной системы и процесса сервера промежуточного программного обеспечения.

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

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

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

Подробная методика оценки приводится в 5.1.

1.4 Применимость

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

Модуль оценки может использоваться в следующих случаях:

a)    оценка как часть системного тестирования верификации;

b)    оценка в тестовой среде производственной системы для измерения восстанавливаемости и идентификации недостатков;

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

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

2    Соответствие

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

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

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

i)

ИСО/МЭК 25000:200s1) Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE (ISO/IEC 25000:2005, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE)

Заменен. Действует ИСО/МЭК 25000:2014.

ГОСТР ИСО/МЭК 25045—2015

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

В настоящем стандарте используются термины и определения, данные в ИСО/МЭК 25000, а также следующие термины с соответствующими определениями:

4.1    базовый уровень производительности (performance baseline): Производительность системы под нормальной рабочей нагрузкой без воздействия возмущений.

4.2    возмущающее воздействие (disturbance): Операционный сбой (например, внезапное завершение процесса работы операционной системы, которое приводит систему в нерабочее состояние), событие (например, существенное увеличение числа пользователей системы) или что-либо иное, что может вызвать изменение состояния системы.

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

4.3    инъекционный период (период действия введенного возмущения) (injection slot): Временной интервал проверки восстанавливаемости тестируемой системы при введении возмущающего воздействия в процессе рабочего функционирования системы.

5    Входные данные и показатели

5.1 Методика оценки

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

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

Базовая фаза

Тестирование

Проверка

Время

Инъекционный Инъекционный    Инъекционный

период 1

период 2

период N

Рисунок 2 — Три фазы оценки

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

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

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

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

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

3

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


Инъекционный период


Инъекция

возмущения

Прединъекционный

интервал


Г


♦К

's-


Система обнаруживает и восстанавливает

__Л--


обнаружения I восстанов ления


Интервал : Инициация


Действия по восстановлению

(если необходимо)

Интервал :    Интервал


Отмена

возмущения

(если необходимо)


восстанов

ления


задержки


-V-

Измерительный интервал


У


Рисунок 3 — Интервалы инъекционного периода


На рисунке 3 показаны пять интервалов, входящих в состав инъекционного периода:

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

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

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

-    Интервал восстановления — время, необходимое системе для выполнения восстановления;

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

Необходимо отметить два следующих момента:

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

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

5.1.1 Практические соображения по методологии

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

По требованию клиента или с его согласия (например, для ускорения тестирования или понимания, как система реагирует на многочисленные возмущающие воздействия, которые проявляются одно за

4