X Международная студенческая научная конференция Студенческий научный форум - 2018

Введение

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

В подготовке современного технического специалиста важное место отводится выполнению практических и лабораторных работ. Практические занятия направлены на усвоение научно-теоретических основ учебной дисциплины, приобретение умений и выработку навыков решения практических заданий. Цели лабораторных работ – организация управляемой познавательной деятельности студентов в условиях, приближенных к реальной практической деятельности [5]. При изучении дисциплины «Теория надежности систем» особое место отводится выполнению лабораторной работы по теме «Метрические характеристики надежности программных средств».

Цели и задачи лабораторной работы

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

Теоретическая часть

1. Основные понятия и определения

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

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

К числу организаций, вкладывающих ресурсы в исследования по тематикам SRE, относятся:Alkatel, AT&T, Hewlett-Packard, Hitachi, IBM Corp, Motorola, NASA, US Air Force, US Navy, US Army, Toshiba. Хотя точные экономические данные получить не представляется возможным в силу их конфиденциального характера, можно утверждать, что использование методов SRE позволяет повысить эффективность программных проектов до шести раз.

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

Деятельность по SRE включает в себя:

измерение (оценку на основе фактических данных) и прогнозирование (оценку посредством моделей) значений показателей надежности;

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

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

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

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

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

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

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

Информация об условиях использования количественно характеризуется посредством «операционного профиля».

Время является внешней характеристикой производительности программного продукта, получаемой в результате его применения [1]. Лучшей характеристикой производительности является «собственное время системы» - время выполнения операций центральным процессором (CPU). Вместе с тем, допускается изменение и других параметров для их последующего использования в моделях надежности – например, календарное время; время регистрации по часам; число перезапусков системы; время выполнения и др. В зависимости от того, «какое время» используется, определяются разные метрики: доступность для вычислений; чувствительность к ошибкам; среднее время наработки до отказа; среднее время восстановления после сбоя и т.д. Использование времени как косвенную объективную характеристику надежности имеет следующие преимущества. Во-первых, имеет ясно физическое понимание этого показателя. Во-вторых, использование этого показателя дает комплексную характеристику надежности аппаратной и программной компонент. Подчеркнем, что время является лишь одной из возможных косвенных характеристик надежности. Допускается использование и других показателей, например, «число напечатанных страниц» (для принтера).

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

Дефект (fault, defect, bug) – неполные, пропущенные, либо избыточные указания, либо последовательность взаимосвязанных инструкций, следование которым является причиной одной или более свершившихся, либо потенциальных отказов. Разделяют «врожденные» дефекты – те, которые изначально присутствуют в программном продукте. «Дефекты модификации» - те, которые внесены в результате выполнения корректировок, либо изменения проектных решений. В качестве метрической характеристики дефектов выступает плотность дефектов, например количество дефектов на тысячу строк исполняемого кода. Дефекты имеют субъективную природу – они являются следствием ошибок, допущенных людьми. Если, например, допущена ошибка при изображении условного оператора на структурной схеме алгоритма, результатом будет дефект в коде. При выполнении программы будет иметь место ошибка обработки данных (вычисления пойдут не по той ветке), так что пользователь будет наблюдать на экране результат отличный от того, который должен быть. Иными словами, пользователь наблюдает симптом дефекта – отказ программного продукта.

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

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

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

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

2. Метрики и модели

2.1. Надежность

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

Наиболее употребительной метрикой надежности является частота отказов. Частота отказов определяется как число отказов, зарегистрированных в единицу времени (секунду/час/день/неделю...). Синонимом «частоты отказов» является «относительное число отказов». Другой часто применяемой метрикой является среднее время между отказами. Между интенсивностью отказов и средним временем между отказами существует обратная зависимость. Интенсивность отказов является хорошим показателем качества программного продукта с точки зрения пользователя. При росте надежности во времени, интенсивность отказов падает.

Если дефекты не устраняются, можно установить простые соотношения между интенсивностью отказов и надежностью:

, (1)

где есть характеристика надежности;

- определяемый, исходя из назначения системы, период наблюдения.

Пример: Допустим, система функционирует в образцовых и неизменных условиях и выявленные дефекты не устраняются. Допустим, что за 10 000 часов зарегистрировано 7 отказов. В этом случае оценка интенсивности отказов составит в час. Средняя наработка между отказами составит часов. Оценка вероятности безотказной работы в течение ближайших 10 часов составит

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

Рассмотрим две из множества известных моделей, соответствующих случаю растущей надежности. В обеих моделях предполагается, что устранение отказов происходит мгновенно без внесения новых дефектов. В модели «основное время выполнения» («Basic Execution Time - BET») интенсивность отказов описывается выражением

(2)

где - начальная интенсивность; - общее ожидаемое число дефектов.

Эта модель может быть преобразована к линейному виду

(3)

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

(4)

В модели LPET (Logarithmic-Poisson Execution Time) интенсивность отказов при периоде наблюденияопределяется соотношением

, (5)

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

Выражение (5) можно преобразовать к виду

, (6)

где есть среднее число отказов. зарегистрированных в течение периода наблюдения , т.е. . (7)

Модель BET относится к классу «моделей с конечным числом отказов». Для этой модели среднее значение функции приближается к некоторому асимптотическому значению по мере роста значения периода наблюдения. Модель LPET относится к классу «моделей с неограниченным числом отказов». В действительности модели, относимые к упомянутым классам, предназначены для поддержки процессов устранения дефектов, которых на самом деле может быть очень ограниченное число.

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

Важно отметить, что есть два различных пути использования моделей:

Модель как аккумулятор исторических данных.

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

Прогнозирование – одно из наиболее интересных приложений модели, но в то же время наиболее опасное. В литературе отмечается, что ни одна из моделей не обеспечивает точного решения задачи прогнозирования. Более того, результаты, полученные посредством разных моделей, могут достаточно сильно различаться [3].

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

Пример: предположим, что в качестве базовой модели выбрана модель BET. Из формул (2)-(4) следует, что число ошибок, которые следует устранить для того, чтобы достичь требуемой интенсивности отказов, определяется соотношением:

, (8)

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

(9)

В случае, если дефектов в коде; =15 отказов в час (например, CPU); при текущем значении =2.55 отказа в час и при целевом значении =0.0005 отказов в час, значение

21 отказ.

68.3 часов (например, CPU).

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

Приведенные оценки относятся к классу «точечных» и дают значение «вероятных», т.е. средних величин. На практике, однако, важно вычислять также доверительные границы для оценивания параметров и получить меру (т.е. количественную характеристику) того, насколько можно доверять полученным цифрам. Вместо того, чтобы представлять ожидаемые значения в виде одной величины, представляется подходящий интервал (например, 70%, 90%, 95% доверительный интервал). В этом случае, вместо того, чтобы говорить о том, что ожидается 21 отказ, следует говорить о том, что с вероятностью 90% число отказов будет лежать в диапазоне от 17 до 25.

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

2.2. Готовность

Одной из часто используемых характеристик надежности является готовность [4]. Например, Bell core целевым показателем простоя элементов телекоммуникационной сети определяет 3 минуты в год. Готовность есть вероятность того, что система (элемент системы) окажется работоспособным в заранее указанное время. Неготовность, напротив, означает вероятность того, что система (элемент) окажется неработоспособным в заранее заданный момент времени. Понятие готовности (неготовности) тесно связано с понятием устранения отказов. Количественно устранение отказов можно охарактеризовать коэффициентом восстановления, который определяется числом отказов, устраняемых в единицу времени. Например, отказ в программной компоненте, в среднем приводит к10-минутному простою аппаратно-программного комплекса. Коэффициент восстановления составит 1/10 на отказ в минуту.

Готовность системы может быть охарактеризована разными показателями. Например, мгновенная готовность выражается вероятностью застать систему исправной в любой момент времени t в течение времени жизни системы. Средняя готовность есть доля заранее определенного временного интервала [0,T], в течение которого система должна быть готовой к использовании.

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

(10)

Соответственно коэффициент простоя (интенсивность отказов)

(11)

Коэффициент восстановления (интенсивность восстановления) определен как

(12)

Если период T достаточно длинный, средняя готовность преобразуется к виду «установившегося значения средней готовности» . Этому понятию соответствует соотношение (коэффициент простоя):

(13)

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

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

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

3. Практическое использование формального аппарата надежности

Практически невозможно обеспечить надежность программного продукта не имея логичного и реалистичного плана верификации процессов и активностей, относящихся ко всем стадиям жизненного цикла. Пример такого плана представлен в IEEE Std – 1012; ESA-PSS – 05-10. SRE предписывает использование современных технологий ориентированных на предупреждение, идентификацию дефектов, обеспечение устойчивости к ним; уменьшение обусловленных ими негативных последствий. SRE предписывает увязывать эти технологии с бизнес-процессами. Это включает в себя конструирование и квантификацию профилей пользователей, а также обеспечение баланса между надежностью программного продукта и другими ограничениями. Практика SRE предписывает сбор и анализ данных о свойствах программного продукта; оценивание и определение направления изменения надежности; управление процессами создания программного продукта в терминах ресурсов, а также критерия «когда остановить тестирование»; отслеживать состояние деятельности, связанной с обеспечением надежности программного продукта. Отслеживание уровня надежности и направления её изменения используется для совершенствования системы управления и поддержки процесса создания прикладного программного продукта и повышения уровня удовлетворенности потребителей. IEEE&ESA-PSS- стандарты V&V (Verification & Validation) предполагают, что на стадии формирования и анализа требований будут решены следующие задачи [5]:

планирование генерации системных тестов;

планирование генерации тестов приемлемости.

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

– выявить и классифицировать все дефекты в программном продукте;

– определить реальные требования к надежности со стороны покупателей и определить с экономической точки зрения компромиссное решение в пространстве трех показателей: сроки – качество - цена;

– определить профиль пользователей программного продукта;

– определить целевые показатели надежности программного продукта.

Идентификация и классификация отказов программных продуктов, а также тяжести их последствий, зависит от области приложений, а также особенностей сопровождения. Например, U.S. Federal Communications Commissions (FCC) требует, чтобы в случае нарушения сервисного обслуживания более чем на 30 минут, либо в случае, когда нарушение сервисного обслуживания затрагивает интересы более чем 50 000 абонентов, информация об этом в течение не более чем 30-ти минут после наступления события, должна поступать в Federal Communications Commission.

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

отказы аппаратной компоненты;

отказы программной компоненты;

ошибки персонала;

нерасчетные воздействия окружающей среды;

неизвестные.

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

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

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

– возможностей разработчиков;

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

– расписания выполнения работ.

Обычно, для того, чтобы достичь определенной категории по показателям надежности, выделяется совокупность частных целей. Например, Bellcome установило общее требование для оценки производительности телекоммуникационных систем. Целевое значение для сетевых переключательных элементов – простой не более 3-х минут в год (при этом время восстановления после отдельного отказа не превышает 30 секунд); фиксируется состояние полного отказа, если сервис недоступен более чем 30 секунд. Это, конечно, не требование надежности, но это требование готовности. Фактически средняя недоступность системы (из-за отказа переключательных элементов) составляет (мин.). Для вычисления целевого показателя надежности, также необходимо установить целевое значение показателя, связанного с восстановлением системы. Например, приняв упрощающее предположение о том, что система находится в установившемся состоянии, можно воспользоваться соотношением (13) для расчета целевого значения характеристики восстановления. Пусть среднее значение частоты восстановления составляет отказа в минуту. В этом случае, зная требуемое значение готовности 1-0.00000571=0.99999429 и зная частоту восстановлении, посредством (13) можно определить, что средняя частота отказов не должна превышать 0.00000171 отказов в минуту.

В стандарте IEEE Std-1012-1998 также предполагается, что следующие задачи решаются в ходе проектирования, кодирования, помодульного и интеграционного тестирования:

анализ трассируемости проектных решений и кодов;

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

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

проектирование, генерация и выполнение тестовых наборов.

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

определились с функциональностью и сформировали операционный профиль;

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

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

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

отслеживали и управляли процессами искусственного внесения дефектов и их устранения (для оценки эффективности систем диагностики).

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

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

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

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

Требования к содержанию и оформления отчета

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

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

Контрольные вопросы

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

Дайте содержательное толкование терминов «отказ», «дефект», «тяжесть ошибок»

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

Критерии оценки выполнения лабораторной работы

Задание считается выполненным, если выполнены работы, оформлен отчет, осуществлена его защита.

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

Список литературы

Иванова А. Д. Педагогическая практика аспирантов: практикум / А.Д. Иванова; Уфимск. гос. авиац. техн. ун-т. – Уфа: РИК УГАТУ, 2017. – 84 с.

Программные проекты: базовые термины и определения: учебное пособие/ В.Е. Гвоздев и др.; Уфимс. гос. авиац. техн. ун-т. – Уфа: УГАТУ, 2011. – 218 с.

Элементы системной инженерии: методологические основы разработки программных систем на основе V-модели жизненного цикла: монография/ М.Б. Гузаиров, В.Е. Гвоздев, Б.Г. Ильясов, О.Я. Бежаева. – М.: Машиностроение, 2013. – 180 с.

Практическое руководство по реализации программных проектов: учебное пособие / В.Е. Гвоздев, О.Я. Бежаева, Д.В. Блинова, А.Ю. Хасанов, Н.И. Ровнейко, М.А. Абдрафиков: Уфимс. гос. авиац. техн. ун-т. – Уфа: УГАТУ, 2015. – 192 с.

Элементы системной инженерии. Технологии формирования требований к аппаратно-программным комплексам на основе экспертно-статистических методов: монография/ [Н.К. Криони и др.]. – М.: «Издательство «Инновационное машиностроение», 2017. – 295 с.

Код для цитирования: Скопировать