Главная / Уроки по Windows / Атрибуты качества программного обеспечения. Стандарты в области обеспечения качества программных систем. Процесс обеспечения качества: выходы

Атрибуты качества программного обеспечения. Стандарты в области обеспечения качества программных систем. Процесс обеспечения качества: выходы

И др.) Cleanroom OpenUP RAD RUP MSF DSDM TDD

Сопутствующие дисциплины

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

Качество исходного кода

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

Читаемость кода
Лёгкость поддержки, тестирования , отладки, исправления ошибок, изменения и портируемости
Низкая сложность кода
Низкое использование ресурсов: памяти и процессорного времени
Корректная обработка исключительных ситуаций
Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг .

Факторы качества

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

Некоторые из факторов качества:

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

С точки зрения пользователя

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

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

См. также

Ссылки


Известные деятели
Процесс
Концепции
Направления
Модели разработки
Другие модели
Прочее

Wikimedia Foundation . 2010 .

NLite
В полночь на кладбище (фильм)

Смотреть что такое "Качество программного обеспечения" в других словарях:

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

Разработка программного обеспечения - Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

Тестирование программного обеспечения - Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Производитель программного обеспечения - Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

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

Инженерия программного обеспечения - Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

Мобильность программного обеспечения - способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем. Синонимы: Переносимость программного обеспечения См. также: Качество программного обеспечения Открытые системы… … Финансовый словарь

Удобство программного обеспечения - характеристики программного продукта, которые: позволяют минимизировать усилия пользователей по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также позволяют вызывать положительные эмоции… … Финансовый словарь

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

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

Книги

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

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

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

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

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

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

В настоящий момент этот показатель регулируется международным стандартом ISO/IEC 25010:2011. Данный стандарт устанавливает многоуровневую систему оценки качества ПО, основанную на восьми базовых характеристиках.

Параметры качества ПО

Основные характеристики качества программного обеспечения согласно стандарту ISO/IEC 25010:2011:

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

Обеспечение качества и тестирование

Термины «тестирование» и «обеспечение качества», безусловно, связаны между собой, но не тождественны. В чем же различие?

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

В задачи QA-специалистов входит:

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

Тестирование – проверка программного обеспечения на соответствие требованиям.

Таким образом, вы видите, что обеспечение качества – более широкое понятие, которое включает в себя работы по тестированию.

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

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

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

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

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

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

Рис. 9.1.

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

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

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

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

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

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

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

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

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

Качество Качество Качество

процесса продукта сопровождения

Рис. 9.2.

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

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

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

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

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

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

Показатели-характеристики

Атрибуты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

готовностью к использованию (availability);
готовностью к непрерывному функционированию (reliability);
безопасностью для окружающей среды, т.е. способностью системы не вызывать катастрофических последствий в случае отказа (safety);
секретностью и сохранностью информации (confidential);
способностью к сохранению системы и устойчивости к самопроизвольному ее изменению (integrity);
способностью к эксплуатации ПО, простотой выполнения операций обслуживания, а также устранения ошибок, восстановлением системы после их устранения (maintainability);
готовностью и сохранностью информации (security) и др. Достижение надежности системы обеспечивается предотвращением отказа (fault prevention) или его устранением (removal fault), а также оценкой возможности появления новых отказов и мер борьбы с ними.

Для численной оценки надежности используются методы теории вероятностей. Каждый программный компонент, его операции и данные обрабатываются в дискретные моменты времени, например 5, 28,..., пЪ.

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

Р{ Т > пЬ} = (1 - Л.) И, где Л. - вероятность отказа, при этом среднее

время ожидания будет равно Т = -.

Положим, что значение 5 уменьшается, а время Т остается фиксированным, тогда имеем

R{T>t} =

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

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

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

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

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

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

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

В дополнение к нему выпущен набор стандартов ISO/IEK 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE.

Общий подход заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении «сверху вниз» разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEK 9126 является типичным примером такого подхода.

В рамках модели SQuaRE выделяются следующие 6 основных характеристик качества:

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

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

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

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

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

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

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

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

Билет 26 27

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

Качество исходного кода

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

Читаемость кода

Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

Низкая сложность кода

Низкое использование ресурсов: памяти и процессорного времени

Корректная обработка исключительных ситуаций

Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

Факторы качества

Некоторые из факторов качества:

понятность

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

Все необходимые части программы должны быть представлены и полностью реализованы.

краткость

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

портируемость

Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

согласованность

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

сопровождаемость

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

тестируемость

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

удобство использования

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

надёжность

отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок:

структурированность

эффективность

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

Безопасность

ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) - «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». ISO 9126 это международный стандарт, определяющий оценочные характеристики качества программного обеспечения (далее ПО). Российский аналог стандарта ГОСТ 28195. Стандарт разделяется на 4 части, описывающие следующие вопросы: модель качества; внешние метрики качества; внутренние метрики качества; метрики качества в использовании

Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в 6-ти структурных наборах характеристик, которые в свою очередь детализированы под-характеристиками(субхарактеристиками), такими как:

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

Пригодностью для применения

Корректностью (правильностью, точностью)

Способностью к взаимодействию (в частности сетевому)

Защищенностью

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

Уровнем завершенности (отсутствия ошибок)

Устойчивостью к дефектам

Восстанавливаемостью

Доступностью

Готовностью

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

Понятностью

Простотой использования

Изучаемостью

Привлекательностью

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

Временной эффективностью

Используемостью ресурсов

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

Удобством для анализа;

Изменяемостью

Стабильностью

Тестируемостью

Мобильность - Набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими под характеристиками (субхарактеристиками):

Адаптируемостью

Простотой установки (инсталляции)

Сосуществованием (соответствием)

Замещаемостью

Подхарактеристика Соответствие не приведена в вышеописанном списке, но она принадлежит всем характеристикам. Эта характеристика должна отражать отсутствие противоречий с иными стандартами или характеристиками. Например соответствие надежности и практичности.

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

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

Системная эффективность - "Применения программного продукта по назначению"

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

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

Удовлетворение требований и затрат пользователей в соответствии с целями применения ПС

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

Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений характеристик ПС.

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

Фил Кросби: Качество — это соответствие пользовательским требованиям.
Уотс Хемпфри: Качество — это достижение отличного уровня пригодности к использованию.
Компания IBM: ввела в оборот фразу «качество, управляемое рыночными потребностями (market-driven quality)».
Критерий Бэлдриджа: «качество, задаваемое потребителем (customer-driven quality)».
Система менеджмента качества ISO 9001: Качество — это степень соответствия присущих характеристик требованиям.

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

Качество в проектной деятельности:

Управление требованиями («атрибуты качества» как категория нефункциональных требований);
Тестирование (т.н. наработка на отказ, такие метрики как MTTF — Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п.).

«Приемлемое качество» можно сравнивать с уровнем обслуживания в рамках заданного SLA – Service Level Agreement. То есть, приемлемое качество может рассматриваться как <количественно выраженный> компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах <решения задач> заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как «cost of quality» – «стоимость качества»).

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

Рисунок «Модель системы менеджмента качества»

Основы качества программного обеспечения (Software Quality Fundamentals)

Согласие, достигнутое по требованиями к качеству (в оригинале — quality requirements), наравне с четким доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и формального определения многих аспектов качества.

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

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

Культура и этика программной инженерии (Software Engineering Culture and Ethics)

Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей <профессиональной> культуры.
Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. IEEE Computer Society и ACM разработали кодекс этики (“моральный кодекс” – code of ethics) и профессиональной практики, основанный на восьми принципах, помогающих инженерам укрепить их отношение к качеству и независимость <в решении вопросов обеспечения достойного качества создаваемых программных продуктов> в их повседневной работе.

Значение и стоимость качества (Value and Costs of Quality)

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

Стоимость качества (cost of quality) может быть дифференцирована на:

стоимость предупреждения <дефектов> (prevention cost),
стоимость оценки (appraisal cost),
стоимость внутренних сбоев (internal failure cost),
стоимость внешних сбоев (external failure cost).

Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью. Ценность программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и связанной с ними стоимостью. Является ли характеристики качества чисто декоративными или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно приниматься процессе работы с требованиями, однако эти вопросы могут подниматься на протяжении всего жизненного цикла программного обеспечения. Не существует каких-то <“стандартных”> правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы и их стоимость.

Модели и характеристики качества (Models and Quality Characteristics)

ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering — Product Quality, Part 1: Quality Model):

внутреннее качество,
внешнее качество и
качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598-98 Software Product Evaluation).

Качество процессов программного обеспечения (Software engineering process quality)

Управление качеством (software quality management) и качество процессов программной инженерии (software engineering process quality) имеют непосредственное отношение к качеству создаваемого программного продукта.

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

TickIT — касается рассмотрения общей системы менеджмента качества ISO 9001-00 в приложении к программным проектам.
Другой важный стандарт – CMMI , обсуждаемый в области знаний “Процесс программной инженерии”, предоставляет рекомендации по совершенствованию процесса. Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI:
- обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”),
- проверка (verification, категория “Engineering”) и
- аттестация (validation, категория “Engineering”).

При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы.

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

Качество программного продукта (Software product quality)

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

Стандарт ISO 9126-01 (Software Engineering — Product Quality, Part 1: Quality Model) определяет для двух из трех описанных в нем моделей, связанные характеристики и «суб-характеристики» качества, а также метрики, полезные для оценки качества программных продуктов.

Понимание термина “продукт” расширено включением всех артефактов, создаваемых на выходе всех процессов, используемых для создания конечного программного продукта. Примерами продукта являются (но не ограничиваются этим):

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

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

Повышение качества (Quality Improvement)

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

процессами жизненного цикла,
процессом обнаружения, устранения и предотвращения сбоев/дефектов и
процессов улучшения качества.

К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества. Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип “building in quality”. Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта напрямую связано с качеством используемых для его создания процессов.

Такие подходы, как TQM (Total Quality Management – всеобщее управление качеством) и PDCA (Plan, Do, Check, Act – Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами достижения задач, связанных с качеством. Поддержка менеджмента помогает в выполнении процессов, оценке продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или организации, в целом) детально идентифицирует все действия и проекты по улучшению <отдельных аспектов деятельности> в рамках определенного периода времени, за который такие проекты можно осуществить с успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка менеджмента тесно связана с реализацией активного взаимодействия в коллективе, и должна предупреждать возникновение потенциальных проблем (и пассивного или даже активного противодействия реализации программы совершенствования или отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров среднего звена и выделенные ресурсы на уровне проекта – эти вопросы обсуждаются в области знаний “Процесс программной инженерии”.

Процессы управления качеством программного обеспечения (Software Quality Processes)

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

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

Планирование качества программного обеспечения включает:

Определение требуемого продукта в терминах характеристик качества.
Планирование процессов для получения требуемого продукта.

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

SQM может использоваться для оценки и конечных и промежуточных продуктов. Некоторые из специализированных процессов SQM определены в стандарте 12207:

Процесс обеспечения качества (quality assurance process);
Процесс верификации (verification process);
Процесс аттестации (validation process);
Процесс совместного анализа (joint review process);
Процесс аудита (audit process).

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

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

Управление рисками также может играть значительную роль для выпуска качественного программного обеспечения. Включение “регулярного” (как постоянно действующего, а не периодического; в оригинале – disciplined) анализа рисков и <соответствующих> техник управления <рисками> в процессы жизненного цикла программного обеспечения может увеличить потенциал для производства качественного продукта. Более подробную информацию по управлению рисками можно найти в области знаний “Управление программной инженерией”.

Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)

Процессы SQA обеспечивают подтверждение того, что программные продукты и процессы жизненного цикла проекта соответствуют заданным требованиям. Такое подтверждение проводится на основе планирования (planning), постановки <работ> (enacting) и исполнения (performing) набора действий, направленных на то, чтобы качество стало неотъемлемой частью программного обеспечения.
Такой взгляд подразумевает ясное и точное формулирование проблемы, а также то, что определены и четко выражены, полны и однозначно интерпретируемы требования к соответствующему <программному> решению. SQA добивается обеспечения качества в процессе разработки и сопровождения за счет выполнения различных действий на всех этапах <жизненного цикла>, что позволяет идентифицировать проблемы еще на ранних стадиях, которые практически неизбежны в любой сложной деятельности.

Управление рисками (Risk Management) является серьезным дополнительным инструментом для обеспечения качества программного обеспечения.

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

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

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

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

Кроме того, SQA-план касается и вопросов работ по обеспечению качества, относящихся к другим типам деятельности, описанным в <различных> планах по созданию программного обеспечения, к которым также относятся поставка, установка, обслуживание заказных и/или тиражируемых/готовых программных решений (commercial off-the-shelf, COTS), необходимых для данного проекта программного обеспечения. SQA-план может содержать необходимые для обеспечения качества критерии приемки программного обеспечения и действия по формированию отчетности и управлению <и контролю над> работами.

Проверка (верификация) и аттестация (Verification and Validation, V&V)

Проверка и аттестация программного обеспечения – упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований.
V&V напрямую адресуется вопросам качества программного обеспечения и использует соответствующие техники тестирования для обнаружения тех или иных дефектов. V&V может применяться для промежуточных продуктов, однако, в том объеме, который соответствует промежуточным “шагам” <соответствующих> процессов жизненного цикла.

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

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

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

Оценка (обзор) и аудит (Review and Audits)

Пять типов оценок и аудитов:

Управленческие оценки (management reviews)
Технические оценки (technical reviews)
Инспекции (inspections)
“Прогонки” (walk-throughs)
Аудиты (audtis)

Управленческие оценки (Management Reviews)

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

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

Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии), V&V-отчетов, а также различных типов планов — управления рисками проекта/проектного управления, конфигурационного управления, безопасности <использования> программного обеспечения (safety), оценки рисков и т.п.

Технические оценки (Technical Reviews)

Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения (decision-maker); лидер оценки (review leader); регистратор (recorder); а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке.

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

Формулировки целей
Конкретного программного продукта (подвергаемого оценке)
Заданного плана проекта (плана управления проектом)
Списка проблем (вопросов), ассоциированных с продуктом
Процедуры технической оценки

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

Инспекции (Inspections)

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

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

Инспектирование программного обеспечения всегда вовлекает авторов промежуточного или конечного продукта, в отличие от оценок, которые не требуют этого в обязательном порядке. Инспекции (как временные организационные единицы – группы, команды) включают лидера, регистратора, рецензента и нескольких (от 2 до 5) инспекторов. Члены команды инспектирования могут специализироваться в различных областями экспертизы (обладать различными областями компетенции), например, предметной области, методах проектирования, языке и т.п. В заданный момент (промежуток) времени инспекции проводятся в отношении отдельного небольшого фрагмента продукта (в большинстве случаев, фокусируясь на отдельных функциональных или других характеристиках; часто, отталкиваясь от отдельных бизнес-правил, функциональных требований или атрибутов качества, прим. автора). Каждый член команды должен исследовать программный продукт и другие входные данные до проведения инспекционной встречи, применяя, возможно, те или иные аналитические техники в небольшим фрагментам продукта или к продукту, в целом, рассматривая в последнем случае только один его аспект, например, интерфейсы. Любая найденная аномалия должна документироваться, а информация передаваться лидеру инспекции. В процессе инспекции лидер руководит сессией <инспекции> и проверяет, что все <члены команды> подготовились к инспектированию.

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

Принятие <продукта> с отсутствием либо малой необходимостью переработки
Принятие <продукта> с проверкой переработанных фрагментов
Необходимость повторной инспекции

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

Прогонки (Walk-throughs)

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

Главные цели прогонки состоят в:

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

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

Аудиты (Audits)

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

Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор (lead auditor), второй аудитор (another auditor), регистратор (recorder) и инициатор (initiator). В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде <разработки> для принятия корректирующих действий.

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

Практические соображения (Practical Considerations)

Требования к качеству программного обеспечения (Software Quality Requirements)

Факторы влияния (Influence factors)

На планирование, управление и выбор SQM-действий и техник оказывают влияние различные факторы, среди которых:

Область применения системы, в которой будет работать программное обеспечение (критичное для безопасности <людей>), критичное для бизнеса и т.п.)
Системные и программные требования
Какие компоненты используются в системе – коммерческие (внешние) или стандартные (внутренние)
Какие стандарты программной инженерии применимы в заданном контексте
Каковы методы и программные инструменты, применяемые для разработки и сопровождения, а также для обеспечения качества и совершенствования (продукта и процессов)
Бюджет, персонал, организация проектной деятельности, планы и расписания для всех процессов
Кто целевые пользователи и каково назначение системы
Уровень целостности системы

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

Гарантоспособность (Dependability)

Гарантоспособость – гарантия <высокой> надежности, защищенности от сбоев.
В случаях, когда сбой системы может привести к крайне тяжелым последствиям (такие системы иногда называют в англоязычных источниках “high confidence” или “high integrity system”, в русском языке к ним иногда применяют название “системы повышенной надежности”, “высокой доступности” и т.п.), общая (совокупная) гарантоспособность системы (как сочетания аппаратной части, программного обеспечения и человека) является главным и приоритетным требованием качества, по отношению к основной функциональности <системы>.

Гарантоспособность (dependability) программного обеспечения включает такие характеристики, как защищенность от сбоев (fault-tolerance), безопасность использования (safety – безопасность в контексте приемлемого риска для здоровья людей, бизнеса, имущества и т.п.), информационная безопасность или защищенность (security – защита информации от несанкционированных операций, включая доступ на чтение, а также гарантия доступности информации авторизованным пользователям, в объеме заданных для них прав), а также удобство и простота использования (usability). Надежность (reliability) также является критерием, который может быть определен в терминах гарантоспособности.

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

Уровни целостности программного обеспечения (Integrity levels of software)

Уровень целостности программного обеспечения определяется на основании возможных последствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когда важны различные аспекты безопасности (применения и информационной безопасности), при разработке планов работ в области идентификации возможных очагов аварий могут использоваться техники анализа опасностей (в контексте безопасности использования, safety) и анализа угроз (в информационной безопасности, security). История сбоев аналогичных систем может также помочь в идентификации наиболее полезных техник, направленных на обнаружение сбоев и <всесторонней> оценки качества программного обеспечения.

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

Характеристика дефектов (Defect Characterization)

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

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

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

Частичные определения понятий такого рода выглядят следующим образом:

Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом <полученным с использованием программного обеспечения>”
Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”
Сбой (failure): “<Некорректный> результат, полученный в результате недостатка”
Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”

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

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

Данные о несоответствиях и дефектах, найденных в процессе реализации соответствующих техник SQM, должны фиксироваться для предотвращения их потери. Для некоторых техник (например, технической оценки, аудита, инспекций), присутствие регистратора (recorder) – обязательно, именно для фиксирования такой информации, наравне с вопросами (в том числе, требующими дополнительного рассмотрения) и принятыми решениями. В тех случаях, когда используются соответствующие средства автоматизации, они могут обеспечить и получение необходимой выходной информации о дефектах (например, сводную статистику по статусам дефектов, ответственным исполнителям и т.п.). Данные о дефектах могут собираться и записываться в форме запросов на изменения (SCR, software change request) и могут, впоследствии, заноситься в определенные типы баз данных (например, в целях отслеживания кросс-проектной/исторической статистики для дальнейшего анализа и совершенствования процессов), как вручную, так и в автоматическом режиме из соответствующих средств анализа (ряд современных средств проектирования и специализированных инструментов позволяют анализировать код и модели с применением соответствующих метрик, значимых для обеспечения качества продуктов и процессов). Отчеты о дефектах направляются управленческому звену организации/организационной единицы или структуры (для принятия соответствующих решений в отношении проекта, продукта, процесса, персонала, бюджета и т.п.).

Техники управления качеством программного обеспечения (Software Quality Management Techniques)

Техники SQM могут быть распределены по нескольким категориям:

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

Статические техники (Static techniques)

Статические техники предполагают <детальное> исследование (examination) проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения. Эти техники могут включать другие, рассматриваемые ниже, действия по “коллективной” оценке или “индивидуальному” анализу, вне зависимости от степени использования средств автоматизации.

Техники коллективной оценки (People-intensive techniques)

Форма такого рода техник, включая оценку и аудит, может варьироваться от формальных собраний до неформальных встреч или обсуждения продукта даже без обращения к его коду. Обычно, такого рода техники предполагают очного взаимодействия минимум двух, а в большинстве случаев, и более специалистов. При этом, такие встречи могут требовать предварительной подготовки (практически всегда касающейся определения содержания встреч, то есть перечня выносимых на обсуждение вопросов). К ресурсам, используемым в таких техниках, наравне с исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут относится различного рода листы проверки (checklists) и результаты аналитических техник (рассматриваются ниже) и работ по тестированию. Данные техники рассматриваются, например, в стандарте 12207 при обсуждении оценки (review) и аудита (audit).

Аналитические техники (Analytical techniques)

Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитические техники. С точки зрения Agile-методик и подходов, individuals and interactions предполагает <непосредственное> общение и постоянное взаимодействие членов команды.

Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают “ручную” работу. Многие могут помогать находить дефекты напрямую, но чаще всего они используются для поддержки других техник. Ряд техник также включает различного рода экспертизу (assessment) как составной элемент общего анализа качества. Примеры таких техник — анализ сложности (complexity analysis), анализ управляющей логики (или анализ контроля потоков управления — control flow analysis) и алгоритмический анализ (algorithmic analysis).

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

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

Динамические техники (Dynamic techniques)

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

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

В зависимости от организации <ведения> проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах. В силу того, что план SQM адресуется вопросам тестирования, данная тема включает некоторые комментарии по тестированию.

Тестирование (Testing)

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

трассируемости (traceability),
согласованности (consistency),
полноты/завершенности (completeness),
корректности (correctness)
и непосредственно выполнения <требований> (performance).

Такое подтверждение также охватывает любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов. SQA-деятельность обеспечивает гарантию того, что соответствующие (необходимые в заданном контексте проекта) типы тестов спланированы, разработаны и реализованы, а V&V – разработку планов тестов, стратегий, сценариев и процедур <тестирования>.
Вопросы тестирования детально обсуждаются в области знаний “Тестирование”. Два типа тестирования следуют задачам, задаваемым SQA и V&V, потому как на них ложится ответственность за качество данных, используемых в проекте:

Оценка и тестирование инструментов, используемых в проекте
Тестирование на соответствие (или оценка тестов на соответствие) компонент и COTS-продуктов (COTS — commercial of-the-shelf, готовый к использованию продукт) для использования в создаваемом продукте.

Иногда, независимые V&V-организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, документировать/фиксировать) реальное выполнение <тестов> на предмет их проведения в соответствии с заданными процедурами. С другой стороны, может быть сделано обращение к V&V может быть направлено на оценку и самого тестирования: достаточности планов и процедур, соответствия и точности результатов.

Другой тип тестирования, которое проводится под началом V&V-организации – тестирование третьей стороной (third-party testing). Такая третья сторона сама не является разработчиком продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона является независимым источником оценки, обычно аккредитованным на предмет обладания соответствующими полномочиями (например, организацией-разработчиком того или иного стандарта, соответствие которому оценивается независимым экспертом и чьи действия подтверждены создателем стандарта). Назначение такого рода тестирования состоит в проверке продукта на соответствие определенному набору требований (например, по информационной безопасности).

Количественная оценка качества программного обеспечения (Software Quality Measurement)

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

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

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

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

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

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

Основанные на статистических методах (например, анализ Pareto, нормальное распределение и т.п.)
Статистические тесты
Анализ тенденций
Предсказание (например, модели надежности)

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

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

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

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

Примечания:

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

Практичность (Usability) — Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной оценки такого использования определенным или предполагаемым кругом пользователей.

Примечания:

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

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

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

Примечания:

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

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

Качество программного продукта

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

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

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

Представление пользователя

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

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

Имеются ли требуемые функции в программном обеспечении?
Насколько надежно программное обеспечение?
Насколько эффективно программное обеспечение?
Является ли программное обеспечение удобным для использования?
Насколько просто переносится программное обеспечение и другую среду?

Представление разработчика

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

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

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

Представление руководителя

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

Оценка качества программного продукта

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

Рисунок «Модель процесса оценивания»

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

Модель качества процесса

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

Рисунок «Концептуальная модель качества процесса разработки»

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

Руководство по применению характеристик качества

1 Применяемость

2 Представления о качестве программного

2.1 Представление пользователя
2.2 Представление разработчика
2.3 Представление руководителя

3.1 Установление требований к качеству

3.2 Подготовка к оцениванию

3.2.1 Выбор метрик (показателей) качества
3.2.2 Определение уровней ранжирования
3.2.3 Определение критерия оценки

3.3 Процедура оценивания

3.3.1 Измерение
3.3.2 Ранжирование
3.3.3 Оценка

1 Введение

2 Определение комплексных показателей качества

2.1 Функциональные возможности (Functionality)

2.1.1 Пригодность (Suitability)
2.1.2 Правильность (Accuracy)
2.1.3 Способность к взаимодействию (Interoperability)
2.1.4 Согласованность (Compliance)
2.1.5 Защищенность (Security)

2.2 Надежность (Reliability)

2.2.1 Стабильность (Maturity)
2.2.2 Устойчивость к ошибке (Fault tolerance)
2.2.3 Восстанавливаемость (Recoverability)

2.3 Практичность (Usability)

2.3.1 Понятность (Understandability)
2.3.2 Обучаемость (Learnability)
2.3.3 Простота использования (Operability)

2.4 Эффективность (Efficiences)

2.4.1 Характер изменения во времени (Time behavior)
2.4.2 Характер изменения ресурсов (Resource behavior)

2.5 Сопровождаемость (Maintainability)

2.5.1 Анализируемость (Analysability)
2.5.2 Изменяемость (Changeability)
2.5.3 Устойчивость (Stability)
2.5.4 Тестируемость (Testability)

2.6 Мобильность (Portability)

2.6.1 Адаптируемость (Adaptability)
2.6.2 Простота внедрения (Installability)
2.6.3 Соответствие (Conformance)
2.6.4 Взаимозаменяемость (Replaceabilily)

Примечания:

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

Качество проекта

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

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

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

Принципы качества (ISO 9000)

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

Рисунок «Различия в понимании управления качеством в ISO 9000 и PMBoK»

Управление качеством проекта (PMI): подпроцессы

Планирование качества
Обеспечение качества
Контроль качества

Планирование качества

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

Процесс планирования качества: входы

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

Процесс планирования качества: инструменты и технологии

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

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

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

Обеспечение качества

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

Процесс обеспечения качества: входы

Рабочие инструкции. Еще один выход процесса планирования качества.
Результаты контрольных измерений качества. Выход процесса контроля качества.

Процесс обеспечения качества: инструменты и техники

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

Аудиты качества

Структурированные «осмотры», которые подтверждают «выученные уроки». Типы аудита качества бывают:

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

Процесс обеспечения качества: выходы

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

Контроль качества

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

Процесс контроля качества: входы

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

Контроль качества: инструменты и техники

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

«Цель использования инструментов – зафиксировать результаты или изменения, отобразить их графически, и далее выявить и скорректировать проблемы подходящим способом».

Процесс контроля качества: выходы

Улучшение качества. Выход из процесса обеспечения качества.
Принятие решений. Решения принимаются в зависимости от того, принят или отклонен проинспектированный объект.
Корректирующие действия. Действие, проводимое, чтобы привести в соответствие несоответствующий объект.
Заполненные проверочные списки.
Настройка процесса.

Использованная литература

http://sorlik.blogspot.com, Сергей Орлик, 2004-2005
Генельт А.Е. Учебно-методическое пособие по дисциплине «Управление качеством разработки ПО» 2007, Санкт-Петербург

Атрибуты качества программного обеспечения. Стандарты в области обеспечения качества программных систем. Процесс обеспечения качества: выходы

Качество исходного кода

Факторы качества

С точки зрения пользователя

См. также

Ссылки

Смотреть что такое "Качество программного обеспечения" в других словарях:

Книги

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

Параметры качества ПО

Обеспечение качества и тестирование

Основы качества программного обеспечения (Software Quality Fundamentals)

Культура и этика программной инженерии (Software Engineering Culture and Ethics)

Значение и стоимость качества (Value and Costs of Quality)

Модели и характеристики качества (Models and Quality Characteristics)

Качество процессов программного обеспечения (Software engineering process quality)

Качество программного продукта (Software product quality)

Повышение качества (Quality Improvement)

Процессы управления качеством программного обеспечения (Software Quality Processes)

Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)

Проверка (верификация) и аттестация (Verification and Validation, V&V)

Оценка (обзор) и аудит (Review and Audits)

Управленческие оценки (Management Reviews)

Технические оценки (Technical Reviews)

Инспекции (Inspections)

Прогонки (Walk-throughs)

Аудиты (Audits)

Практические соображения (Practical Considerations)

Требования к качеству программного обеспечения (Software Quality Requirements)

Факторы влияния (Influence factors)

Гарантоспособность (Dependability)

Уровни целостности программного обеспечения (Integrity levels of software)

Характеристика дефектов (Defect Characterization)

Техники управления качеством программного обеспечения (Software Quality Management Techniques)

Статические техники (Static techniques)

Техники коллективной оценки (People-intensive techniques)

Аналитические техники (Analytical techniques)

Динамические техники (Dynamic techniques)

Тестирование (Testing)

Количественная оценка качества программного обеспечения (Software Quality Measurement)

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

Качество программного продукта

Представление пользователя

Представление разработчика

Представление руководителя

Оценка качества программного продукта

Модель качества процесса

Руководство по применению характеристик качества

Качество проекта

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

Планирование качества

Процесс планирования качества: входы

Процесс планирования качества: инструменты и технологии

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

Обеспечение качества

Процесс обеспечения качества: входы

Процесс обеспечения качества: инструменты и техники

Аудиты качества

Процесс обеспечения качества: выходы

Контроль качества

Процесс контроля качества: входы

Контроль качества: инструменты и техники

Процесс контроля качества: выходы

Использованная литература

Восстановление пароля