Общие характеристики качества программного средства

Общие термины.

1. Качество программного средства (software quality)

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

3. Свойство программного средства (software attribute.)

4. Отличительная особенность ПС, которая может проявляться при его создании, использовании, анализе или изменении.

5. Характеристика качества программного средства: (software quality characteristic) Набор свойств ПС, посредством которых описывается и оценивается его качество. Характеристика качества ПС может быть определена путем задания иерархии ее подхарактеристик.

6. Подхарактеристика качества программного средства(software quality subcharacteristic)

7. Характеристика качества ПС, входящая в состав другой характеристики качества.

8. Показатель качества программного средства (software quality metric) Характеристика качества ПС, обладающая количественным значением.

9. Критерий оценки качества программного средства (software quality assessment criterion)

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

1. Функциональность программного средства (functionality)

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

2. Удобство использования программного средства (usability).

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

3. Эффективность программного средства (efficiency).

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

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

5. Мобильность программною средства (portability)

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

6. Надежность программного средства (reliability)

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

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

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

2. Сложность программ. Рассматривается в трех аспектах:

· сложность процесса разработки программ;

· сложность программы как объекта разработки (статическая);

· сложность выполнения программы (динамическая) — учитывает ресурсы, необходимые для ее выполнения.

3. Трудоемкость - совокупные затраты труда на создание или использование программы.

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

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

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

В зависимости от характеристик и особенностей показателя качества применяются различные виды метрик и шкал для их измерения.

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

· временем выполнения программы,

· числом маршрутов в программе,

· числом таблиц в базе данных,

· объемом программы и т.д.

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

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

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

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

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

Для программ управления в них входят:

· показатели точности, диапазоны изменения параметров,

· время реакции на запрос или выполнения программы,

· адаптивность к внешним воздействиям и т.д.

В системах автоматизации обработки информации функциональные показатели отражают:

· номенклатуру и объем данных,

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

· разнообразие функций доступа к данным и редактирования.

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

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

· трудоемкость, сложность программ,

· надежность функционирования,

· степень использования ресурсов ЭВМ,

· корректность и т.д.

Конструктивные критерии зависят не от области применения, а от этапа жизненного цикла программы (ЖЦП). На различных этапах ЖЦП рекомендуется использовать разные критерии:

Критерии этапа разработки:

1. Трудоемкость (статическая сложность).

2. Корректность (правильность) программы.

Критерии этапа эксплуатации ПП:

1. Функциональность.

2. Производительность (ресурсоемкость).

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

Критерии этапа сопровождения:

1. Трудоемкость.

2. Понимаемость программы.

3. Производительность программы.

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

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

Рис. 7.1

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

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

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

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

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

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

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

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

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

Длина программы

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

Объем программы.

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

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

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

Уровень программы.

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

Определение интеллектуального содержания программ

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

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

Метрики структурной сложности программ.

Структурная сложность программ определяется:

· числом взаимодействующих компонент;

· числом связей между компонентами;

· сложностью взаимодействия компонент.

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

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

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

Все маршруты исполнения программного модуля условно можно разделить на две группы:

· вычислительные маршруты;

· маршруты принятия логических решений.

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

Для проверки вычислительных маршрутов можно построить достаточно простую стратегию их проверки. Во всем диапазоне входных переменных нужно выбрать несколько характерных точек [предельные значения, значения в точках разрыва и несколько (1-3) промежуточных значений], для которых проверяется работоспособность программы. Предполагается, что в большинстве промежуточных точек программу можно не проверять из-за гладкости значений непрерывных переменных.

Наряду с аналитическими методами для исследования и оценки параметров программ активно используются измерительные методы. Привлекательной стороной этих методов является их высокая достоверность. Поэтому они применяются для проверки имитационных и аналитических методов оценки характеристик программ по принципу: практика — лучший критерий истины.

В целом измерительные методы имеют следующее назначение:

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

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

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

Необходимые условия применения измерительных методов:

1) Наличие готовой программы, подлежащей измерительному исследованию;

2) Наличие реальной вычислительной системы (а не её модели) для прогона программы;

3) Наличие аппаратных или программных средств проведения измерений;

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

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

2) Выбор (разработка) средств регистрации параметров потребления ресурсов системы.

3) Выбор (разработка) алгоритмов расчетов характеристик программ по результатам измерений.

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

Существует два основных способа регистрации измеряемых параметров:

- трассирующий;

- выборочный.

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

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

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

- как и на что расходуется время работы программы;

- сколько раз выполняется данная строка программы;

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

Надежность программного обеспечения (ПО) отличается от надежности технических средств следующим:

· элементы ПО не стареют от износа;

· число способов контроля ПО значительно больше числа способов контроля аппаратуры;

· в ПО значительно больше объектов для контроля, чем в аппаратуре;

· в ПО гораздо проще вносить исправления и дополнения, чем в аппаратуру, но это трудно делать корректно и безошибочно.

Основные понятия, связанные с надежностью программного обеспечения:

· ошибки в программах и признаки их наличия;

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

· интенсивность обнаружения ошибок (или функция риска);

· прогон программы;

· отказ программы.

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

· при выполнении программы появилась ошибочная операция;

· использование некорректного операнда в программе;

· несоответствие функций, выполняемых программой, ее спецификации;

· ошибки в самой спецификации, которые вызывают необходимость корректирования программы;

· ошибки в вычислениях (например, переполнение и т.п.);

· ошибки интерфейса программы с пользователем.

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

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

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

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

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

· Вид «функции риска», определяющей временную структуру появления ошибок в программе;

· Сложность разработки программы;

· Способы «посева» ошибок и оценки числа исходных ошибок по соотношению исходных и внесенных;

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

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

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

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

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

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

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

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

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

В Законе "О сертификации продукции и услуг" определены два вида сертификации: обязательная и добровольная.

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

Объектами, подлежащими добровольной сертификации, являются:

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

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

- сертификация программного обеспечения контроллеров и вычислительных блоков;

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

- сертификация программного обеспечения тренажеров и иных имитационных систем;

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

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

- сертификация программного обеспечения баз данных;

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

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

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

1. В чем разница оценки характеристик аппаратного и программного обеспечения.

2. В каком ГОСТе дана оценка качества программных средств.

3. Дать определение функциональности программного средства.

4. Дать определение эффективности программного средства.

5. Дать определение мобильности программного средства.

6. Дать определение надежности программного средства.

7. По каким физическим измеряемым показателям контролируется программа.

8. В чем заключается метрика программ, предложенная Холстедом.

9. Каковы виды сертификации программ.

10. Каковы объекты добровольной сертификации программ.

Рекомендуемая литература

1. Авен О.И. Оценка качества и оптимизация вычислительных систем / О.И. Авен – М.: Наука, 1982 – 485 с.

2. Благовещенский В.С. Метрология вычислительных систем / В.С. Благовещенский – Чита, изд. ЧГУ, 2012

3. Боэм Б.У. Инженерное проектирование программного обеспечения / Б.У. Боэм – М.: Радио и связь, 1985 – 512 с.

4. Гагарина Л.Г. Технология разработки программного обеспечения. Учебное пособие / Л.Г Гагарина – М.: ИД «Форум», ИНФРА – 2008

5. Липаев В.В. Надежность программного обеспечения / В.В. Липаев – М.: Финансы и статистика, 1983 – 263 с.

6. Липаев В.В. Надежность программного обеспечения / В.В. Липаев – М.: Энергоиздат, 1981 – 241с.

7. Липаев В.В. Проектирование программных средств / В.В Липаев – М.: Высшая школа, 1990 -301 с.

Дата добавления: 2014-12-27