Надежность и правильность программных средств
Программа считается правильной, если она не содержит ошибок. Такая программа не дает неверных результатов, т.е. она абсолютно надежна. Этот факт породил ложное представление о том, что число ошибок в программе можно считать наиболее естественной мерой надежности. Было выполнено довольно много работ, в которых предлагались различные методы оценки числа оставшихся в программе ошибок по результатам ее тестирования, в том числе метод "засорения" известными ошибками, однако, как показывают приводимые ниже соображения, количество ошибок в программе не имеет никакого отношения к ее надежности:
1. Число ошибок в программе - величина "ненаблюдаемая", наблюдаются не сами ошибки, а результат их проявления.
2. Неверное срабатывание программы может быть следствием не одной, а сразу нескольких ошибок.
3. Ошибки могут компенсировать друг друга, так что после исправления какой-то одной ошибки программа может начать "работать хуже".
4. Надежность характеризует частоту проявления ошибок, но не их количество; в то же время хорошо известно, что ошибки проявляются с разной частотой: некоторые ошибки остаются невыявленными после многих месяцев и даже лет эксплуатации, но, с другой стороны, нетрудно привести примеры, когда одна единственная ошибка приводит к неверному срабатыванию программы при любых исходных данных, т.е. к нулевой надежности.
Согласно [ГОСТ 9126] качество программного обеспечения это весь объем признаков и характеристик программного обеспечения, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.
Качество программного обеспечения оценивается следующими характеристиками:
Функциональные возможности (Functionality).Набор атрибутов,относящихся к сути набора функций и их конкретным свойствам. Функциями являются те, которые реализуют установленные или предполагаемые потребности.
Надежность (Reliability).Набор атрибутов относящихся к способности программногообеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени.
Практичность (Usability).Набор атрибутов,относящихся к объему работ,требуемых дляиспользования и индивидуальной оценки такого использования определенным и предполагаемым кругом пользователей.
Эффективность (Efficiencies).Набор атрибутов,относящихся к соотношению междууровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях.
Сопровождаемость (Maintainability).Набор атрибутов,относящихся к объему работ,требуемых для проведения конкретных изменений (модификаций).
Мобильность (Portability).Набор атрибутов,относящихся к способности программногообеспечения быть перенесенным из одного окружения в другое.
В общем случае под ошибкой подразумевается неправильность, погрешность или неумышленное искажение объекта или процесса, что может быть причиной ущерба – риска при функционировании или применении программы. При этом предполагается, что известно правильное, эталонное состояние объекта или процесса по отношению к которому может быть определено наличие отклонения. Исходным эталоном для любого программного обеспечения являются спецификации требований заказчика или потенциального пользователя, предъявляемых к программам и ожидаемый пользователем или заказчиком эффект от использования программного обеспечения. Важной особенностью при этом является отсутствие полностью определенной программы – эталона, которой должны соответствовать текст и результаты функционирования разрабатываемой программы. Поэтому определить качество программного обеспечения и наличие ошибок в нем путем сравнения разрабатываемой программы с эталонной программой невозможно.
Риски проявляются как негативные последствия проявления ошибок в программном обеспечении в ходе его применения и функционирования, которые могут нанести ущерб системе, в которой применяется это программное обеспечение, внешней среде или пользователям этой системы в результате отклонения характеристик программного обеспечения заданных или ожидаемых пользователем или заказчиком.
Исходя из определения ошибки в программном обеспечении, приведенном выше, можно сделать вывод, что ошибки, проявляющиеся в ходе функционирования программного обеспечения, могут влиять на все показатели качества. В работе рассматриваются ошибки, проявления которых влияют на надежность функционирования программного обеспечения.
По определению, установленному в программу, надежность – свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующим заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования.
Рис. 1. Надежность по ГОСТ 27.002 – 89
При этом надежность является комплексным свойством, которое в зависимости от назначения объекта и условий его применения может включать безотказность, долговечность, ремонтопригодность и сохраняемость или определенные сочетания этих свойств (рис. 1). Поскольку программное обеспечение в процессе эксплуатации не изнашивается, его поломка и ремонт в общепринятом смысле не производится, то надежность программного обеспечения имеет смысл характеризовать только с точки зрения безотказности его функционирования и возможности восстановления функционирования после отказов вызванных проявлениями ошибок.
В данном случаи надежность программного обеспечения предлагается характеризовать с помощью следующих характеристик (рис. 2): стабильность, устойчивость и восстанавливаемость.
Рис. 2. Надежность программного обеспечения
В этом случае стабильность и устойчивость характеризуют безотказность программного обеспечения, а восстанавливаемость – возможность восстановления функционирования программного обеспечения после его отказа. Для количественной оценки надежности программного обеспечения необходимо определить показатели надежности для каждого свойства и методику их определения (оценки).
Для оценки стабильности программного обеспечения возможно использование показателей характеризующих безотказность технических устройств(рис. 3).
Рис. 3. Показатели безотказности
В большинстве случаев поток программных ошибок может быть описан негомогенным процессом Пуассона. Это означает, что программные ошибки происходят в статистически независимые моменты времени, наработки
подчиняются экспоненциальному распределению, а интенсивность проявления ошибок изменяется во времени. Обычно используют убывающую интенсивность проявления ошибок. Это означает, что ошибки, как только они выявлены, эффективно устраняются без введения новых ошибок. Главная цель анализа надежности программного обеспечения заключается в том, чтобы определить форму функции интенсивности проявления ошибок и оценить ее параметры по наблюдаемым данным. Как только функция интенсивности проявления ошибок определена, могут быть найдены такие показатели надежности как:
• общее количество ошибок;
• количество остающихся ошибок;
• время до проявления следующей ошибки;
• вероятность безошибочной работы;
• интенсивность проявления ошибок;
• остаточное время испытаний (до принятия решения);
• максимальное количество ошибок (относительно срока службы).
При этом следует различать понятия ошибка и отказ. Применительно к надежности программного обеспечения ошибка это погрешность или искажение кода программы, неумышленно внесенные в нее в процессе разработки, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования. Под отказом в общем случае понимают событие, заключающееся в нарушении работоспособности объекта. Состояние объекта, при котором значения всех параметров характеризующих способность выполнять заданные функции, соответствуют требованиям нормативно – технической и (или) конструкторской (проектной) документации – называется работоспособным. При этом критерии отказов, как признаки или совокупность признаков нарушения работоспособного состояния программного обеспечения, должны определяться исходя из его предназначения в нормативно – технической и (или) конструкторской (проектной) документации.
В общем случае отказ программного обеспечения можно определить как:
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание) на время превышающее заданный порог;
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) на время не превышающее заданный порог, но с потерей всех или части обрабатываемых данных;
прекращение функционирования программы (искажения нормального хода ее выполнения, зацикливание ) потребовавшее перезагрузки ЭВМ, на которой функционирует программное обеспечение.
При этом исходя из всего, все отказы в программном обеспечении следует трактовать как сбои (самоустраняющиеся отказы или однократные отказы, устраняемые незначительным вмешательством оператора), поскольку восстановление работоспособного состояния программного обеспечения может произойти без вмешательства оператора (перезагрузка ЭВМ не требуется), либо при участии оператора или эксплуатирующего персонала (перезагрузка ЭВМ необходима).
Приведенные выше критерии отказов приводят к необходимости анализа временных характеристик функционирования программы и динамических характеристик потребителей данных, полученных в ходе функционирования программного обеспечения. Временная зона перерыва нормальной выдачи информации и потери работоспособности, которую следует рассматривать как зону сбоя (отказа), тем шире, чем более инертный объект находится под воздействием данных, полученным в ходе работы программы. Пороговое время восстановления работоспособного состояния системы, при превышении которого следует фиксировать отказ, близко к периоду решения задач для подготовки информации (данных) соответствующему потребителю (абоненту).
Для любого потребителя данных существует допустимое время отсутствия данных от программы, при котором его характеристики находятся в допустимых пределах . Исходя из этого времени, можно установить границы временной зоны, которая разделяет работоспособное и неработоспособное состояние программного обеспечения и позволяет использовать данные критерии отказов.
Из приведенного выше определения программной ошибки с точки зрения надежности, можно сделать вывод о том , что ошибки, при их проявлении, не всегда вызывают отказ программного обеспечения и каждую ошибку можно характеризовать условной вероятностью возникновения отказа при проявлении этой ошибки. Следует также отметить, что само по себе наличие ошибки в исходном коде не определяет надежность программы до тех пор, пока не произойдет проявления этой ошибки, поэтому пользоваться для оценки надежности программного обеспечения только показателями характеризующие общее количество ошибок в программе, количество оставшихся ошибок и максимального количества ошибок нельзя.
В данном случаи стабильность предлагается оценивать вероятностью безотказной работы, которая оценивается исходя из модели относительной частоты, при этом применение ее ограничено периодом эксплуатации программного обеспечения, что не всегда приемлемо, поскольку надежность объекта, как правило, необходимо оценивать не только в процессе его эксплуатации, но и до начала эксплуатации этого объекта. Ограничение модели относительной частоты вызвано тем, что в этой модели не учитываются процессы тестирования и отладки, а конкретно то, что при возникновении отказа программного обеспечения, ошибка, вызвавшая этот отказ, исправляется.
Наиболее приемлемыми показателями характеризующими стабильность (безотказность) программного обеспечения представляются показатели сходные с показателями безотказности технических систем: вероятность безотказной работы, интенсивность отказов, и среднее время наработки на отказ. Эти показатели взаимосвязаны и, зная один из них, можно определить другие. При определении этих показателей в большинстве случаев можно исходить из модели надежности, предполагающей, что интенсивность проявления ошибок убывает по мере исправления этих ошибок, время между проявлениями ошибок распределено экспоненциально, а интенсивность проявления ошибок постоянна между двумя соседними проявлениями ошибок. Применение такой модели надежности программного обеспечения позволит оценить надежность программного обеспечения во время тестирования и отладки.
Устойчивость, как свойство или совокупность свойств программного обеспечения, характеризующие его возможность поддерживать приемлемый уровень функционирования при проявлениях ошибок в нем , можно оценивать условной вероятностью безотказной работы при проявлении ошибки. Согласно правилу устойчивость оценивается с помощью трех метрик, включающих двадцать оценочных элементов.
Устойчивость программного обеспечения;
Средство восстановления при ошибках на входе;
Наличие требований к программе по устойчивости функционирования при наличии ошибок во входных данных;
1. Возможность обработки ошибочных ситуаций;
2. Полнота обработки ошибочных ситуаций;
3. Наличие тестов для проверки допустимых значений входных данных;
4. Наличие системы контроля полноты входных данных;
5. Наличие средств контроля корректности входных данных;
6. Наличие проверки параметров и адресов по диапазону их знаний;
7. Наличие обработки граничных результатов;
8. Наличие обработки неопределенностей (деление на 0, квадратный корень из отрицательного числа).
Средства восстановления при сбоях в оборудовании;
1. Наличие требований к программе по восстановлению результатов при отказах процессора, операционной системы;
2. Наличие требований к программе по восстановлению процесса выполнения в случае сбоя операционной системы, процессора, внешних устройств;
3. Наличие средств восстановления процесса в случае сбоев оборудования;
4. Наличие возможности разделения по времени выполнения отдельных функций программ;
5. Наличие возможности повторного старта с точки остановки.
Реализация управления средствами восстановления;
1. Наличие централизованного управления процессами, конкурирующими между ресурсами;
2. Наличие возможности автоматически обходить ошибочные ситуации в процессе вычисления;
3. Наличие средств, обеспечения завершения процесса в случае помех;
4. Наличие средств, обеспечивающих выполнение программы в сокращенном объёме в случае ошибок и помех;
5. Показатель устойчивости к искажающим воздействиям.
Метрики и оценочные элементы устойчивости программного обеспечения по ГОСТ 28195 – 89
Результаты оценки каждой метрики определяются результатами оценки определяющих ее оценочных элементов, а результат оценки устойчивости определяются результатами соответствующих ему метрик. Программное обеспечение по каждому из оценочных элементов оценивается группой экспертов – специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Для оценочных элементов принимается единая шкала оценки от 0 до 1.
Недостатком такого подхода является одинаковая оценка устойчивости для всех возможных ошибок. Поскольку вероятность возникновения отказа при проявлении разных ошибок может быть разной, возникает необходимость разделения ошибок на несколько категорий. Признаком, по которому в этом случае можно относить ошибки к той или иной категории, можно считать тяжесть ошибки. Под тяжестью ошибки в этом случае следует понимать количественную или качественную оценку вероятного ущерба при проявлении
этой ошибки, а если говорить о надежности, то оценку вероятности возникновения отказа при проявлении ошибки. При этом категорией тяжести последствий ошибки будет являться классификационная группа ошибок по тяжести их последствий, характеризуемая определенным сочетанием качественных и/или количественных учитываемых составляющих ожидаемого (вероятного) отказа или нанесенного отказом ущерба. В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки целесообразно использовать условную вероятность отказа и его возможных последствий при проявлении ошибок разных категорий. Для программного обеспечения, создаваемого для систем управления, потеря работоспособности которых может повлечь за собой катастрофические последствия, возможные категории тяжести ошибок приведены в таблице