Основы качества программного обеспечения

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

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

Рисунок 18.1. Область знаний «Качество программного обеспечения».

Качество ПО является предметом стандартизации. Согласно ГОСТ качество ПО есть совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика в соответствии с назначением. Этот стандарт регламентирует базовую модель качества и показатели, главным среди которых является надежность. Стандарт ISO/IEC 12207 определил не только основные процессы ЖЦ разработки ПО, но и организационные и дополнительные процессы, которые регламентируют инженерию, планирование и управление качеством ПО.

Согласно этому стандарту на всех этапах ЖЦ разработки ПО должен проводиться следующий контроль качества ПО:

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

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

- тестирование готового ПО, сбор данных об отказах, дефектах и других ошибках, обнаруженных в системе;

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

- оценка показателей качества, заданных в требованиях на разработку ПО.

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

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

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

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

Качество ПО характеризуется тремя аспектами: качеством процессов ЖЦ, качеством ПП и качеством сопровождения, или внедрения (рис. 18.2).

Рисунок 18.2. Основные аспекты качества ПО.

Аспект, связанный с процессами ЖЦ, определяет степень формализации, достоверности самих процессов ЖЦ разработки ПО, а также верификацию и валидацию (кратко: V&V) промежуточных результатов этих процессов. Поиск и устранение ошибок в готовом ПО проводится методами тестирования, которые снижают количество ошибок и повышают качество этого продукта.

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

Модель качества ПО имеет следующие четыре уровня представления.

Первый уровень соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользователя на качество. Согласно существующим стандартам (ISO/IEC 9126, ДСТУ 2844 – 1994, ДСТУ 2850 – 1994, ДСТУ 3230 – 1995) в модель качества входит шесть характеристик или шесть показателей качества (рис. 18.3): функциональность (functionality), надежность (realibility), удобство (usability), эффективность (efficiency), сопровождаемость (maitainnability), переносимость (portability).

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

Третий уровень предназначен для измерения качества с помощью метрик, каждая из которых, согласно стандарту ISO/IEC 9126, определяется как комбинация метода измерения атрибута и шкалы измерения его значений. При оценке атрибутов качества на этапах ЖЦ (при просмотре документации и программ, а также результатов тестирования программ) используются метрики с заданным оценочным весом для нивелирования результатов метрического анализа совокупности атрибутов конкретного показателя и качества в целом.

Атрибут качества определяется с помощью одной или нескольких методик оценки на этапах ЖЦ и на завершающем этапе разработки.

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

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

Рисунок 18.3. Модель характеристик качества.

2. Характеристики показателей качества

Рассмотрим более подробно показатели качества ПО.

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

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

Правильность (точность) – атрибут, который показывает степень достижения правильных результатов.

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

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

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

К подхарактеристикам (субхарактеристикам) надежности ПО относятся.

Безотказность – атрибут, который определяет способность ПО функционировать без отказов (как программы, так и оборудования).

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

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

К некоторым типам «критических систем» (реального времени, радарных, систем безопасности, коммуникаций и др.) предъявляются требования по обеспечению высокой надежности (недопустимость ошибок, точность, достоверность, удобство применения и др.). Таким образом, надежность ПО в значительной степени зависит от числа оставшихся и не устраненных ошибок в процессе его разработки и на этапах ЖЦ. В ходе эксплуатации ошибки обнаруживаются и устраняются. Если при исправлении ошибок не вносятся новые ошибки или число новых ошибок меньше, чем число устраняемых, то в ходе эксплуатации надежность ПО непрерывно возрастает. Чем интенсивнее проводится эксплуатация, тем интенсивнее выявляются ошибки и быстрее растет надежность ПО.

На надежность ПО влияют следующие факторы:

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

- угроза как проявление нарушения безопасности системы;

- целостность как способность системы сохранять устойчивость работы и не иметь риска.

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

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

Новое направление – инженерия программной надежности (Software– reliability engineering) – ориентировано на количественное изучение операционного поведения компонентов системы по отношению к пользователю, ожидающему надежную работу системы, и включает следующие аспекты:

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

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

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

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

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

- готовностью к использованию (availability);

- готовностью к непрерывному функционированию (reliability);

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

- секретностью и сохранностью информации (сonfidential);

- способностью к сохранению системы и устойчивостью к самопроизвольному ее изменению (integrity);

- способностью к эксплуатации ПО, простотой выполнения операций обслуживания, а также устранения ошибок и восстановление системы после их устранения (maintainability);

- готовностью и сохранностью информации (security) и др.

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

Для численной оценки надежности используются методы теории вероятностей. Каждый программный компонент, его операции и данные обрабатываются в дискретные моменты времени, например, δ, 2δ, …, nδ. Пусть за время T после первого неудачно обработанного компонента системы появился отказ, для которого справедливо выражение P{T > nδ} = (1 – q_s)ⁿ, где q_s – вероятность отказа, при этом среднее время ожидания будет равно T = δ /q_s.

Положим, что значениеδ уменьшается, а время T остается фиксированным, тогда имеем , где t – время до отказа, в данном случае – непрерывная величина, распределенная экспоненциально.

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

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

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

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

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

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

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

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

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

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

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

Cопровождаемость определяется следующими атрибутами:

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

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

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

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

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

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

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

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

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

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

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

Метрики и атрибуты качества

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

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

Согласно стандарту ISO 14598 метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта. Остановимся на классификации существующих метрик ПО, правилах проведения метрического анализа и процесса их измерения.

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

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

Внешние метрики программного продукта:

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

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

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

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

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

Внутренние метрики программного продукта:

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

- метрики сложности, необходимые для определения сложности продукта;

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

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

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

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

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

Стандарт ISO/IEC 9126–2 рекомендует следующие меры (метрики) программного продукта:

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

- мера времени (функционирования системы, выполнения компонента и др.);

- мера усилий (производительность труда, трудоемкость и др.);

- мера учета (количество ошибок, число отказов, ответов системы и др.).

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

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

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

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

Но на практике обычно широко используются следующие метрики процесса:

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

- время модификации моделей;

- время выполнения работ на процессе;

- число найденных ошибок при инспектировании;

- стоимость проверки качества;

- стоимость процесса разработки.

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

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

По определению стандарта ISO/IES 9126–2 метрика качества ПО представляет собой «модель измерения атрибута, связываемого с показателем его качества». При измерении показателей качества ПО стандарт ISO/IES 9126–2 рекомендует использовать следующие типы мер:

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно стандарту ДСТУ 3230 – 1995 для оценки значений показателей качества используются следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов).

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

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

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

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

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

- шкала метрическая (абсолютная, относительная, интегральная);

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

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

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

Стандарт ISO/IES 9126–2 рекомендует к применению пять видов шкал измерения и порядок их использования, от менее строгой оценки к более строгой.

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

2. Порядковая шкала служит для упорядочивания характеристик по возрастанию или убыванию путем сравнения их с базовыми значениями.

3. Интервальная шкала задает существенные свойства объекта (например, календарная дата).

4. Относительная шкала задает некоторое значение относительно выбранной единицы.

5. Абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

Управление качеством

Под управлением качеством понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством –Software Quality Management (SQM) базируется на применении стандартных положений по гарантии качества – Software Quality Assurance (SQA).

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

Гарантию качества обеспечивают следующие процедуры процесса SQA:

- проверка непротиворечивости и выполнимости планов;

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

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

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

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

- проверка принятых метрик продуктов, процессов и приемов их измерения на соответствие утвержденным стандартам и процедурам измерения.

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

При выполнении процесса SQM предполагается следующее:

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

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

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

- проводится контроль качества (SQA, верификация и валидация);

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

Анализ основных стандартных положений (ISO/IEC 9126, ДСТУ2844 – 1994, ДСТУ 2850 – 199 4, ДСТУ 3230 – 1995, NASA – STD – 2201) по созданию качественного продукта и оценке достигнутого уровня качества позволяет выделить два процесса достижения качества на этапах ЖЦ ПП:

1) гарантия (подтверждение) качества ПП как результат определенной деятельности на каждом этапе ЖЦ, с проверкой соответствия создаваемой системы стандартам и процедурам, ориентированным на достижении качества;

2) инженерия качества как процесс предоставления ПП свойств функциональности, надежности, сопровождения и других характеристик качества.

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

- оценку стандартов и процедур, которые выполняются при разработке ПП;

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

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

- анализ и контроль проведения приемочного тестирования (испытания) ПП.

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