• Текст документа
  • Статус
  • Сканер копия
Поиск в тексте
Действующий


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

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

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

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

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

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



ОКС 35.080

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

     
     
Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. N 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").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт http://shop.cntd.ru. - Примечание изготовителя базы данных.


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

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

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


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

Введение


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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


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

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 Нормативные ссылки


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


ИСО/МЭК 25000:2005ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE (ISO/IEC 25000:2005, Software Engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE)
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25000:2014.

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


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

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

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

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

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

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

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


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

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

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

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


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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- кэш (L1, 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 Хранимые данные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pi/Pase,


где PГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости - число завершенных без ошибок транзакций в интервале измерения инъекционного периода в условиях введенного возмущения;

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

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

Интерпретация измеренного значения: xГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости0. Чем больше значение, тем лучше. (На практике значение, как правило, лежит в интервале 0ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемостиxГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости1, однако, теоретически возможно, что величина может превысить значение 1 в том случае, если производительность системы под возмущением выше производительности без возмущений).

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Описание

Базовый

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

Управляемый

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

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

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

Адаптивный

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

Автономный

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интерпретация измеренного значения: 0ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемостиxГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости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 Создание отчета


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

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

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

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

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

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

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

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

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

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

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


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

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

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

A.1 Сводная информация

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

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


Отчет содержит результаты тестирования восстанавливаемости и рекомендации по продукту для приложения "Day Trader" с открытым исходным кодом 2.0 в системном решении программного обеспечения, в состав которого входят сервер HTTP "HHHH v1.6", сервер приложений "AAAA v1.6" и сервер СУБД "DDDD v6.0".

Для этого решения системы программного обеспечения получены значения индекса способности к восстановлению, равное 0,81 (из возможного значения 1,00), и индекса автономного восстановления, равное 0,63 (из возможного значения 1,00). Это является улучшением по сравнению с предыдущими полученными значениями восстанавливаемости, равными 0,75 и 0,55, соответственно для приложения "DayTrader" 1.0 с сервером HTTP "HHHH v1.5", сервером приложений "AAAA v1.6" и сервером СУБД "DDDD v5.0".

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

Более подробная информация представлена в следующих разделах отчета.

А.2 Карта оценки

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

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

Примечание - Числа, используемые в таблице А.1, условные.


Таблица А.1 - Карта оценки

Возмущение

Оценка влияния на индекс способности к восстановлению

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

Замечание

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

0101 Завершение процесса работы - СУБД

0,64

1

0102 Завершение процесса работы - сервер сообщений

0,63

1

0103 Завершение процесса работы - сервер HTTP

1,00

3

0104 Завершение процесса работы - сервер приложений

0,98

3

0105 Завершение работы операционной системы - СУБД

0,51

1

0106 Завершение работы операционной системы - сервер сообщений и сервер HTTP

0,51

1

0107 Завершение работы операционной системы - сервер приложений

0,99

3

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

0201 Потеря таблицы - СУБД

0,39

0

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

0,44

0

0203 Потеря диска - СУБД

1,00

3

0204 Потеря диска - сервер сообщений

0,44

0

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

0301 Захват ЦП - СУБД

1,00

3

0302 Захват ЦП - сервер сообщений и сервер HTTP

0,91

0

0303 Захват ЦП - сервер приложений

0,91

0

0304 Захват памяти - СУБД

0,89

0

0305 Захват памяти - сервер сообщений и сервер HTTP

0,96

0

0306 Захват памяти - сервер приложений

1,00

3

0307 Захват ввода-вывода - СУБД

1,00

3

0308 Захват дисков - СУБД

0,99

3

0309 Захват дисков - сервер сообщений

1,00

3

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

1,00

0

0311 Опасные сообщения - сервер сообщений

0,71

0

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

0401 Умеренное увеличение загрузки на 2 дополнительных пользователя

0,89

2

0402 Существенное увеличение загрузки на 10 дополнительных пользователей

0,50

2

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

0501 Перезапуск процесса СУБД

0,63

0

0502 Перезапуск процесса сервера сообщений

0,59

0

0503 Перезапуск процесса сервера HTTP

1,00

3

0504 Перезапуск процесса сервера приложений

1,00

3

0505 Перезапуск операционной системы - СУБД

0,36

0

0506 Перезапуск операционной системы - сервер сообщений

0,42

0

0507 Перезапуск операционной системы - сервер приложений

0,99

0

0508 Перезапуск операционной системы - сервер HTTP

0,99

0

Общий счет

0,81

0,63 (2,52/4)

А.3 Сводка реакции на возмущающие воздействия

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


Таблица А.2 - Сводка реакций на возмущающие воздействия

Реакция на возмущающие воздействия

Число возмущающих воздействий

Возмущение

Катастрофический отказ

18

Xxxx, xxxx, xxxx, ....

Зависание

1

0311 Захват дисковых ресурсов для сервера СУБД (Таблица выходит за допустимые границы)

Недопустимый результат

0

Снижение производительности

19

Xxxx, xxxx, xxxx, ...

Изменения производительности нет

6

Xxxx, xxxx, xxxx, ...

Повышение производительности

0

Общее количество

44

А.4 Выводы и рекомендации

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

А.4.1 Сервер приложений

Достоинства:

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

Недостатки/Возможности для улучшения:

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

А.4.2 Дефекты

Список приложений, идентифицированных дефектов продукта и их текущий статус.

Нет.

A.5 Входные данные для оценки

А.5.1 Описание тестируемой системы

А.5.1.1 Спецификация архитектуры и конфигурации аппаратных средств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аппаратные средства сервера базы данных:

Число систем:

1

Поставщик оборудования:

Корпорация IBM

Название модели:

Система IBM p5 550

Процессор:

POWER5 +

МГц:

2100

Число центральных
процессоров:

4 ядра, 2 микросхемы, 2 ядра/микросхема (мультизадачность)

Память (МБ):

16384

Кэш L1:

Встроенный: по 64 КБ (I)+32 КБ (D) на ядро

Кэш L2:

Встроенный: по 1920 КБ на микросхему

Другой кэш:

Внешний: 36 МБ на DCM, по 2 DCM на тестируемую систему

Поставщик ОС:

IBM

Имя ОС:

AIX IBM 5L v5.3

Диски:

SCSI на 1x36 ГБ, 10240 об/мин

Сетевой интерфейс:

2 встроенных порта Gigabit Ethernet

Другие аппаратные
средства:

1 двухпортовый оптоволоконный канал на 4 ГБ IBM HBA,
соединенный с двумя контроллерами систем хранения
IBM DS4700, содержащими 28 дисководов по 36 ГБ

Доступный H/W:

Август 2006 г.

Доступный O/S:

Август 2006 г.


Примечания

1 Параметры настройки:

1 vmo-o lgpg_regions=454-o lgpg_size=16777216-o v_pinshm=1.

2 aioo-o maxservers=100-o maxreqs=16384-o fsfastpath=1.

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

А.5.1.2 Спецификация конфигурации системы программного обеспечения

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

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

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

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

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

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

Число экземпляров:

1 (1 экземпляр на сервер базы данных)

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

Корпорация IBM

Название продукта:

IBM DB2 Universal Database 9.1

Дата эксплуатационной
готовности:

февраль 2007 г.


Примечание - Параметры настройки: скрипт db2tune.sh.

См. приложение XXX …


Примечания

1 Это просто пример. Приложения XXX не существует.

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

А.5.1.3 Прикладные программы

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

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

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

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

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

DayTrader 2.0

Приложение, используемое в этом тестировании, является приложением DayTrader с открытым исходным кодом 2.0. Оно доступно на сайте Ahache Geroninmo по адресу: http://cwiki.apache.org/GMOxDOC10/day-trader.html. Оно было загружено и сохранено на сервере XXXX в соответствующей директории /xxxxx/yyy/daytrader. Make-файл и необходимые параметры конфигурации находятся в директории /xxxxx/yyy/daytrader на сервере XXXX. Один экземпляр DayTrader был запущен на сервере XXXX.

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

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

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

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

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

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

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

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

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

Число экземпляров:

2 (1 экземпляр на сервер драйвера тестирования)

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

Корпорация IBM

Название продукта:

Rational Performance Tester 8.11

Дата эксплуатационной
готовности:

Апрель 2009 г.


Комплект драйвера ввода возмущения:

Число экземпляров:

2 (1 экземпляр для загрузки возмущения)

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

Разработан в отделе ХХХХ

Название продукта:

Resiliency Tester 1.0

Дата эксплуатационной
готовности:

Апрель 2009 г.

А.5.1.5 Хранимые данные

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

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

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

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

База данных создана приложением DayTrader в процессе генерации данных для 500 тысяч учетных записей.

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

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

Нет.

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

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

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

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

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

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

Приложение, используемое в этом тестировании, является приложением DayTrader с открытым исходным кодом 2.0. Оно доступно на сайте Ahache Geroninmo по адресу: http://cwiki.apache.org/GMOxDOC10/day-trader.html. Спецификация рабочей нагрузки также представлена на сайте.

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

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

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

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

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

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

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

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

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

Число пользователей - 100.

Продолжительность базового прогона - 3300 с.

Отчетный интервал - 30 с.

Смесь транзакций - 70/30 - транзакций чтения-записи (обычная смесь).

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

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

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

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

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

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

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

- Прогон 1 - 15000,45 страниц/с;

- Прогон 2 - 15600,67 страниц/с;

- Прогон 3 - 15580,45 страниц/с.

Прогоны демонстрируют непротиворечивость и устойчивость, поскольку различие между самым низким и самым высоким результатом не превышает 3,8%.

А.7 Описание ввода неисправности

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

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

А.7.1.1 Неожиданное завершение работы

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


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

Возмущение

Цель

Пример неисправности

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

СУБД

Psshutdown\\<hostname>

0102 Неожиданное завершение работы операционной системы на сервере приложений

Сервер приложений

Psshutdown\\<hostname>

0103 Неожиданное завершение работы операционной системы на сервере обмена сообщениями

Сервер сообщений

Psshutdown\\<hostname>

0104 Неожиданное завершение работы операционной системы на сервере HTTP

HTTP

Psshutdown\\<hostname>

0105 Неожиданное завершение процесса работы СУБД

СУБД

pskill\\xxx yyyy.exe

0107 Неожиданное завершение процесса работы сервера обмена сообщениями

Сервер сообщений

pskill\\ccc dddd.exe

0108 Неожиданное завершение процесса работы сервера HTTP

Сервер HTTP

pskill\\eee ffff.exe

0109 Внезапное отключение сети на СУБД

СУБД

ifconfig eth0 down

0110 Внезапное отключение сети на сервере приложений

Сервер приложений

ifconfig eth0 down

0111 Внезапное отключение сети на сервере обмена сообщениями

Сервер сообщений

ifconfig eth0 down

0112 Внезапное отключение сети на сервере HTTP

Сервер HTTP

ifconfig eth0 down

А.7.1.2 Потеря данных

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


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

Возмущение

Цель

Пример неисправности

0201 Потеря таблицы

СУБД

DBMS drop table

0202 Потеря файла базы данных

СУБД

forcedel

0203 Потеря диска для таблицы базы данных

СУБД

DDD Ipssend setstate (отключение диска в RAID)

0204 Потеря диска для очереди сообщений

Сервер сообщений

forcedsk

А.7.1.3 Состязание за ресурсы

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


Таблица А.5 - Возмущающие воздействия для состязания за ресурсы

Возмущение

Цель

Пример неисправности

0301 Захват ЦП на сервере СУБД

СУБД

CpuHog.exe - для (;;);

0302 Захват ЦП на сервере приложений

Сервер приложений

CpuHog.exe - для (;;);

0303 Захват ЦП на сервере обмена сообщениями

Сервер сообщений

CpuHog.exe - для (;;);

0304 Захват ЦП на сервере HTTP

Сервер HTTP

CpuHog.exe - для (;;);

0305 Захват памяти на сервере СУБД

СУБД

MemHog.exe - pHuge = malloc (HUGE_VALUE)

0306 Захват памяти на сервере приложений

Сервер приложений

MemHog.exe - pHuge = malloc (HUGE_VALUE)

0307 Захват памяти на сервере обмена сообщениями

Сервер сообщений

MemHog.exe - pHuge = malloc (HUGE_VALUE)

0308 Захват памяти на сервере HTTP

Сервер HTTP

MemHog.exe - pHuge = malloc (HUGE_VALUE)

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

СУБД

IoHog.exe - копирует или записывает BIG_FILE на диски базы данных

0310 Захват дисков для сервера обмена сообщениями (Переполнение очереди сообщений)

Сервер сообщений

Diskhog.exe

0311 Захват дисков для сервера СУБД (Переполнение таблицы)

СУБД

Diskhog.exe

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

СУБД

Deadlock.exe <resource1> <resource2>

0313 Захват памяти пользовательского приложения

Сервер приложений

LeakCity.ear

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

СУБД

Bigquery.exe

0315 Опасные сообщения

Сервер сообщений

Bigmsg.exe

0316 Захват сетевых ресурсов на сервере СУБД

СУБД

NetworkHog.exe <hostname>

0317 Захват сетевых ресурсов на сервере приложений

Сервер приложений

NetworkHog.exe <hostname>

0318 Захват сетевых ресурсов на сервере обмена сообщениями

Сервер сообщений

NetworkHog.exe <hostname>

А.7.1.4 Реакция на загрузку

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


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

Возмущение

Цель

Пример неисправности

0401 Умеренное увеличение загрузки на 2 дополнительных пользователя

Все

Stress.exe - client TWO_TIMES

0402 Существенное увеличение загрузки на 10 дополнительных пользователей

Все

Stress.exe - client TEN_TIMES

А.7.1.5 Обнаружение отказа перезапуска

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


Таблица А.7 - Возмущающие воздействия для отказа перезапуска

Возмущение

Цель

Пример неисправности

0501 Отказ перезапуска операционной системы сервера СУБД

СУБД

rm boot.ini

0502 Отказ перезапуска операционной системы сервера приложений

Сервер приложений

rm boot.ini

0503 Отказ перезапуска операционной системы сервера обмена сообщениями

Сервер сообщений

rm boot.ini

0504 Отказ перезапуска операционной системы сервера HTTP

HTTP

rm boot.ini

0505 Отказ перезапуска СУБД

СУБД

Rm СУБДsyscs.exe

0506 Отказ перезапуска сервера приложений

Сервер приложений

Rm startserver.bat

0507 Отказ перезапуска менеджера очередей

Сервер сообщений

rm strmqm

0508 Отказ перезапуска сервера HTTP

HTTP

rm admin.conf

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

А.7.2 Набор параметров ввода возмущения

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

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

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

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

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

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

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

- инъекционный интервал - 600 с;

- интервал обнаружения - 1200 с.

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

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

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

Сделано - см. А.11.

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

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

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

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

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

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

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

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

Рисунок А.1 - Базовая фаза. Элементы страниц в секунду

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


Рисунок А.1 - Базовая фаза. Элементы страниц в секунду


Параметры рабочей нагрузки:

- число пользователей - 100;

- смесь транзакций - 70/30 транзакции чтения-записи (обычная смесь);

- разгон - 300 с;

- интервал измерения - 3000 с (общий интервал тестирования минус разгон: 3300-300=3000 с);

- отчетный интервал - 30 с.

Результаты:

- производительность - 1500,45 страниц/с;

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

- общее количество успешных транзакций - 4501350;

- общее количество отказов в транзакциях - 4024 (0,9% из-за обычной тупиковой ситуации и пр. Неожиданные ошибки - нет).

Утилизация:


Таблица А.8 - Базовая фаза. Средний ЦП и использование ввода-вывода

В процентах

Компонент

Среднее использование ЦП

Среднее использование ввода-вывода

Сервер HTTP

80

5

Сервер приложений

80

10

Сервер сообщений

50

20

Сервер базы данных

80

20

А.10 Выходные данные тестового прогона и результирующие показатели качества

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

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

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

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

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

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

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

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

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

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

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

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

Для каждого возмущения вычисляется отношение

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


где PГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости - число завершенных без ошибок транзакций в интервале измерения инъекционного периода в условиях введенного возмущения;

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

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

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

Примечание - В качестве примера представлен результат только для одного возмущения.

А.10.1 Неожиданное завершение работы

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

Рисунок А.2 - Неожиданное завершение работы ОС СУБД. Элементы страниц в секунду

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


Рисунок А.2 - Неожиданное завершение работы ОС СУБД. Элементы страниц в секунду



Параметры рабочей нагрузки:

- те же, что при выполнении базового прогона.

Результат рабочей нагрузки:

- производительность - 1440,43 страниц/с;

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

- общее количество успешных транзакций - 4321290;

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

Загрузка:

- графики утилизации ЦП и ввода-вывода можно найти в директории /xxx/yyy/911 на сервере X.

Фаза проверки:

- выполнена путем сравнения журнала приложения, отчета о тестировании и подсчета количества строк таблиц, выполненных dbcheck.exe. Результаты совпадают. Результаты всех трех проверок можно найти в директории /xxxx/yyyy/911 на сервере X.

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

- способность к восстановлению - 4321290/4501350=0,96;

- индекс автономного восстановления - 3,33/4,0=0,83.

Анализ и замечания:

- в базе данных для автоматической обработки отказа реализована AIX HACMP, а для горячего резервирования базы данных - СУБД HADR;

- HACMP обнаруживает завершение работы операционной системы и автоматически подключает резервную базу данных HADR.

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

А.10.Х.Х (сюда добавляются результаты для других возмущающих воздействий).

А.10.Х (сюда добавляются результаты для другой категории возмущения).

А.10.Х.Х (сюда добавляются результаты для других возмущающих воздействий).

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

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

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

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

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

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

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


Таблица А.9 - Уровень автономности

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

Описание

Базовый

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

Управляемый

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

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

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

Адаптивный

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

Автономный

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.11.1 Неожиданное завершение работы


Таблица А.10 - Анкета для неожиданного завершения работы

Возмущение

Обнаружено

Проанализировано

Обработано

Оценка

Примечание

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

0102 Неожиданное завершение работы операционной системы на сервере приложений

0103 Неожиданное завершение работы операционной системы на сервере обмена сообщениями

0104 Неожиданное завершение работы операционной системы на сервере HTTP

0105 Неожиданное завершение работы процесса СУБД

0106 Неожиданное завершение работы процесса сервера приложений

0107 Неожиданное завершение работы процесса сервера обмена сообщениями

0108 Неожиданное завершение работы процесса сервера HTTP

0109 Внезапное отключение сети на СУБД

0110 Внезапное отключение сети на сервере приложений

0111 Внезапное отключение сети на сервере обмена сообщениями

0112 Внезапное отключение сети на сервере HTTP

А.11.1.1 Потеря данных


Таблица А.11 - Анкета для потери данных

Возмущение

Обнаружено

Проанализировано

Обработано

Оценка

Примечание

0201 Потеря таблицы

0202 Потеря файла базы данных

0203 Потеря диска для таблицы базы данных

0204 Потеря диска для очереди сообщений

А.11.1.2 Состязание за ресурсы


Таблица А.12 - Анкета для состязания за ресурсы

Возмущение

Обнаружено

Проанализировано

Обработано

Оценка

Примечание

0301 Захват ЦП на сервере СУБД

0302 Захват ЦП на сервере приложений

0303 Захват ЦП на сервере обмена сообщениями

0304 Захват ЦП на сервере HTTP

0305 Захват памяти на сервере СУБД

0306 Захват памяти на сервере приложений

0307 Захват памяти на сервере обмена сообщениями

0308 Захват памяти на сервере HTTP

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

0310 Захват дисков на сервере обмена сообщениями (Переполнение очереди сообщений)

0311 Захват дисков на сервере СУБД (Переполнение таблицы)

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

0313 Захват памяти пользовательского приложения

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

0315 Опасные сообщения

0316 Захват сетевых ресурсов на сервере СУБД

0317 Захват сетевых ресурсов на сервере приложений

0318 Захват сетевых ресурсов на сервере обмена сообщениями

А.11.1.3 Реакция на загрузку


Таблица А.13 - Анкета для реакции на загрузку

Возмущение

Обнаружено

Проанализировано

Обработано

Оценка

Примечание

0401 Умеренное увеличение загрузки на 2 пользователя

0402 Существенное увеличение загрузки на 10 пользователей

А.11.1.4 Обнаружение отказа перезапуска


Таблица А.14 - Анкета для обнаружения отказа перезапуска

Возмущение

Обнаружено

Проанализировано

Обработано

Оценка

Примечание

0501 Отказ перезапуска операционной системы сервера СУБД

0502 Отказ перезапуска операционной системы сервера приложений

0503 Отказ перезапуска операционной системы сервера обмена сообщениями

0504 Отказ перезапуска операционной системы сервера HTTP

0505 Отказ перезапуска СУБД

0506 Отказ перезапуска сервера приложений

0507 Отказ перезапуска менеджера очередей

0508 Отказ перезапуска сервера HTTP


Индекс автономного восстановления вычисляется как результат деления среднего всех оценок на максимальное значение оценки, равное 4.

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

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



Таблица ДА.1

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

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

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

ИСО/МЭК 25000:2005

-

*

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

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

[1] ИСО/МЭК 9126-1:2001ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Программная инженерия. Качество продукта. Часть 1. Модель качества
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25010:2011.


[2] ИСО/МЭК ТО 9126-2:2003 Программная инженерия. Качество продукта. Часть 2. Внешние метрики

[3] ИСО/МЭК ТО 9126-3:2003 Программная инженерия. Качество продукта. Часть 3. Внутренние метрики

[4] ИСО/МЭК ТО 9126-4:2004 Программная инженерия. Качество продукта. Часть 4. Метрики качества при использовании

[5] ИСО/МЭК 12207:2008 Системная и программная инженерия. Процессы жизненного цикла программного обеспечения

[6] ИСО/МЭК 14598-1:1999ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Информационные технологии. Оценка программного продукта. Часть 1. Общий обзор
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25040-2011.


[7] ИСО/МЭК 14598-6:2001 Программная инженерия. Оценка программного продукта. Часть 6. Документация модулей оценки

[8] ИСО/МЭК 15026:1998ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Информационные технологии. Уровни целостности систем и программного обеспечения
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 15026-3:2011.


[9] ИСО/МЭК 15288:2008ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Системная и программная инженерия. Процессы жизненного цикла систем
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК/ИИЕЕ 15288:2015.


[10] ИСО/МЭК 15939:2007 Системная и программная инженерия. Процесс измерений

[11] ИСО/МЭК 25001:2007ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Планирование и управление
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25001:2014.


[12] ИСО/МЭК 25010:2011 Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения

[13] ИСО/МЭК 25020:2007 Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Эталонная модель и руководство по измерениям

[14] ИСО/МЭК ТО 25021:2007ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Элементы показателя качества
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25021:2012.


[15] ИСО/МЭК 25040:2011 Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Эталонная модель и руководство по измерениям

[16] ИСО/МЭК 25051:2006ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Программная инженерия. Требования и оценка качества программного продукта (SQuaRE). Требования для качества готового коммерческого программного продукта (COTS) и инструкции по тестированию
________________
ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости Заменен. Действует ИСО/МЭК 25051:2014.

УДК 006.034:004.05:004.054:004.052.32:006.354

ОКС 35.080


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




Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2016

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

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

Номер документа: ИСО/МЭК 25045-2015

Вид документа: ГОСТ Р

Принявший орган: Росстандарт

Статус: Действующий

Опубликован: Официальное издание. М.: Стандартинформ, 2016 год
Дата принятия: 29 мая 2015

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