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

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:42, 24 мая 2017.

Основные положения

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

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

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

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

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

Близким к описанному стандарту по идеологии, структуре и содержанию является стандарт ГОСТ 28195-89. На верхнем, первом уровне выделено 6 показателей - факторов качества:

  1. надежность,
  2. корректность,
  3. удобство применения,
  4. эффективность,
  5. универсальность
  6. сопровождаемость.

Эти факторы детализируются в совокупности 19 критериями качества на втором уровне. Дальнейшая детализация показателей качества представлена метриками и оценочными элементами, которых насчитывается около 240.

Рис. 1.1. Шесть основных характеристик качества ПС

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

В стандарте ГОСТ 28806-90 формализуются общие понятия программы, программного средства, программного продукта и их качества. Даются определения 18 наиболее употребляемых терминов, связанных с оценкой характеристик программ. Уточнены понятия базовых показателей качества, приведенных в стандарте 28195-89.

Функциональная пригодность

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

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

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

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

Корректность программы

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

  1. детерминированно,
  2. стохастически,
  3. в реальном времени.

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

Надежность программы

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

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

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

Классификация сбоев и отказов

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

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

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

Устойчивость и восстанавливаемость работоспособного состояния ПС

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

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

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

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

Наработка на отказ

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

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

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

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

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

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

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

Литература

  1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. /Под ред. А.А. Красилова. - М.:Радио и связь, 1985.
  2. Безопасность информации. Сб. материалов международной конференции. М.: Изд.РИА. 1997.
  3. Гантер Р. Методы управления проектированием программного обеспечения: Пер. с англ. /Под ред. Е.К. Масловского М.:Мир,1981.
  4. Герасименко В.А. Защита информации в автоматизированных системах обработки данных. Книга 1 и 2. М.: Энергоат-омиздат. 1994.
  5. Гласе Р. Руководство по надежному программированию: Пер. с англ. М.: Финансы и статистика, 1982.
  6. Гласе Р., Нуазо Р. Сопровождение программного обеспечения: Пер. с англ. /Под ред. Ю.А. Чернышева. - М.: Мир, 1983.
  7. Евстигнеев В.А. Применение теории графов в программировании. М.:Наука, 1985.
  8. Испытательные центры за рубежом.-М.: Изд. стандартов, 1989.
  9. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). М.: Изд.ЛОРИ. 1996.
  10. Ю.Карповский Е.Я., Сагач В.В., ЧернецкийА.А. Надежность алгоритмов управления. К.: Техника, 1983.
  11. Костогрызов А.И., Липаев В.В. Сертификация качества функционирования автоматизированных информационных систем. М.: Изд. Вооружение. Политика. Конверсия. 1996.
  12. Котляров В.П. CASE-технология и возможности современных CASE-средств в поддержке этапов проектирования программного продукта // Системная информатика. Новосибирск. ВО "Наука". Сибирская издательская фирма. Вып 4.1995.
  13. Леман М.М. Программы, жизненные циклы и законы эволюции программного обеспечения //ТИИЭР. Техника программного обеспечения: Пер. с англ. - М.:Мир, 1980. -Т.68. - N 9. - С.26-45.
  14. Липаев В.В. Надежность программного обеспечения АСУ. -М.: Энергоиздат, 1981.
  15. Липаев В.В., Потапов А.И. Оценка затрат на разработку программных средств. - М.: Финансы и статистика, 1988.
  16. Липаев В.В. Отладка сложных программ. - М.:Энергоатом-издат, 1993.
  17. Липаев В.В. Программно-технологическая безопасность информационных систем. М.: Изд.МИФИ.1997.
  18. Липаев В.В., Филинов Е.Н. Мобильность программ и данных в открытых информационных системах. М.: РФФИ. 1997.
  19. Липаев В.В. Документирование и управление конфигурацией программных средств. М.: СИНТЕГ. 1998.
  20. Лонгботтом Р. Надежность вычислительных систем: Пер. с англ. /Под ред. П.П. Пархоменко. М.: Энергоатомиздат, 1985.
  21. Майерс Г. Надежность программного обеспечения: Пер. с англ. /Под ред. В.Ш. Кауфмана.М.:Мир, 1980.
  22. Майерс Г. Искусство тестирования программ: Пер. с англ.-М.:Финансы и статистика, 1982.
  23. Мобильность программного обеспечения: Пер. с англ. /Под ред. Д.Б. Подшивалова. - М.:Мир, 1980.
  24. Пальчун Б.П.,Юсупов P.M. Оценка надежности программного обеспечения. СПб.: Наука, 1994.
  25. Применение имитационного моделирования для динамической отладки и испытания комплексов программ управления / П.Г.Гаганов, А.Н.Зубковский, А.М.Крылов, А.Б.Козлов. //Управляющие системы и машины. 1984.N3.С.56-61.
  26. Савицкий В.И. Автоматизированные системы управления воздушным движением. Справочник. - М.: Транспорт, 1986.
  27. Сертификация продукции. Международные стандарты и руководства ИСО/МЭК в области сертификации и управления качеством. -М.:Изд-во стандартов, 1990.
  28. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения. Пер. с англ. М.:Мир, 1981.
  29. Характеристики качества программного обеспечения /Б.Боэм, Дж.Браун, Х.Каспар и др./ Пер. с англ. Е.К. Масловского. -М.:Мир, 1981.
  30. Шаракшанэ А.С, Шахин В.П., Халецкий А.К. Испытания программ сложных автоматизированных систем. - М.:Высшая школа, 1982.
  31. Штрик А.А., Осовецкий Л.Г., Мессих И.Г. Структурное проектирование надежных программ встроенных ЭВМ. -Л.:Машиностроение, 1989.
  32. Шураков В.В. Надежность программного обеспечения систем обработки данных. М.:Статистика, 1981.
  33. Щербо В.К., Козлов В.А. Функциональные стандарты в открытых системах. Часть 1. Концепция открытых систем. М.: Изд. МЦНТИ. 1997.
  34. Юсупов P.M., Пальчун Б.П. Безопасность компьюторной инфосферы систем критических приложений. // Вооружение. Политика. Конверсия. 1993. N 2. С.52-56. N 3. С.23-31.
  35. Beizer В. Software testing techniques. N.Y.: Van Nostrand Reinhold. 1990.
  36. Buckle J.K. Software configuration management. - London: Macmillan Press, 1982.
  37. Charett R. Software engineering risk analysis and management.N.Y.: McGraw - Hill, 1989.
  38. DoD Software Reuse Initiative Vision and Strategy. DoD USA.July 15, 1992.
  39. Dunham J.R. Verification and validation in next decade //IEEE Software. - 1989. - May. - P.47-53.
  40. Fisher A.S. CASE: using the newest tools in software development. - N.Y.: John Wiley & Sons, 1988.
  41. Gilb T. Principles of software engineering management.Wokingham, England: Addison-Wesley, 1988.
  42. House D.E., Newman W.F. Testing large software products //ACM Sigsoft. Software engineering notes. 1989. v. 14. N2. p.71-78.
  43. Howden W.E. Functional program testing and analysis. N.Y.: McGraw-Hill, 1987.
  44. Kit E. Software Testing in the Real World - Improving the Process. Addison-Wesley. 1996.
  45. Levendel Y. Reliability analysis of large software systems: defect data modeling// IEEE transaction on SE. 1990. v.l6. N2. p 141-152.
  46. Littlewood B. ed. Software Reliability - Achievement and Assessment. London. Blackwell Scientific Publications. 1987.
  47. Martin J., McClure C. Software maintenance, the problems and its solutions. - N.Y.: Prentice-Hall, 1983.
  48. Musa J.D., lannino A., Okumoto K. Software ReHability: Measurement, Prediction, Application.N.Y. McGraw Hill, 1990.
  49. Ng P.A., Yeh R.T. ed. Modern software engineering. Foundations and current perspectives. - N.Y.: Van Nostrand Reinhold, 1990.
  50. Parnas D.L. Software aspects of strategic defence systems //Communications of the ACM. - 1985. - V.28, - N 12. - p. 1326-1335.
  51. Quarterman J.S., Wilhelm S. Unix, Posix and open systems: The open standards puzzle. N.Y., Addison - Wesley. 1993.
  52. Shooman M.L. Software Engineering: Reliability, Developmen and Management. N.Y. McGraw-Hill. 1983.
  53. Sommerville I. Software engineering. Addison - Wesley. Lancaster University. 1992.
  54. Vincent J., Waters A., Sinclair J. Software quality assurance. Vol. П. A programme guide. - Englewood Cliffs, New Yersey: Prentice-Hall, 1988.

См. также