Модель якості програмного забезпеченняКачество ПО является относительным понятием, которое имеет смысл только при учете реальных условий его применения, поэтому требования, предъявляемые к качеству, ставятся в соответствии с условиями и конкретной областью их применения. Качество ПО характеризуется тремя главными аспектами: качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения (рис. 9.1). Аспект, связанный с процессами ЖЦ, характеризуется степенью формализации, достоверностью и качеством самих процессов ведения разработки ПО, а также верификацией и валидацией полученных промежуточных результатов на процессах ЖЦ, уменьшающих количество ошибок в ПО и тем самым способствующих повышению качества готового продукта.
Качество продукта Качество сопровождения
Рис. 9.1 Основные аспекты качества ПО Качество продукта целиком и полностью определяется процессами ЖЦ. Эффект от внедрения полученного программного продукта в значительной степени зависит от качества сопровождения и знаний обслуживающего персонала. Модель качества ПО имеет следующие четыре уровня детализации. Первый уровень соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную точку зрения пользователя на качество. Согласно стандартов [1-4] определено шесть характеристик или шесть показателей качества в стандартной модели качества: 1. функциональность (functionality), 2. надежность (realibility), 3. удобство (usability), 4. эффективность (efficiency), 5. сопровождаемость (maitainnability), 6. переносимость (portability). Второму уровню соответствуют атрибуты качества для каждой характеристики, которые детализируют разные аспекты конкретной характеристики. Набор атрибутов характеристик качества используется при оценки качества. Третий уровень предназначен измерения качества с помощью метрик, каждая из них согласно стандарта [1] определяется как комбинация метода измерения атрибута и шкалы измерения значений атрибутов. Для оценки атрибутов качества на этапах ЖЦ (при просмотре документации, программ и результатов тестирования программ) используются метрики с заданным оценочным весом для нивелирования результатов метрического анализа совокупных атрибутов конкретного показателя и качества в целом. Атрибут качества определяется с помощью одной или нескольких методик оценки на этапах ЖЦ и на завершающем этапе разработки ПО. Четвертый уровень задает оценочный элемент метрики для оценки количественного или качественного значения отдельного атрибута показателя ПО с учетом его веса. В зависимости от назначения, особенностей и условий сопровождения ПО выбираются наиболее важные характеристики качества и их приоритеты. Выбранные для каждой характеристики атрибуты и их приоритеты отражаются в требованиях на разработку систем. Для программных систем, при разработки которых в требованиях не указан приоритет характеристик качества, используется приоритет эталона -класса ПО, к которому оно относится. Модель качества приведена на рис.9.2, а короткое описание семантики каждой из шести характеристик качества и ее атрибутов приводится ниже. 1). Функциональность - совокупность свойств, определяющих способность ПО выполнять в заданной среде перечень функций в соответствии с требованиями к обработке и общесистемным средствам. Под функцией понимается некоторая упорядоченная последовательность действий для удовлетворения некоторых потребительских свойств. Функции бывают целевые (основные и вспомогательные). К атрибутам функциональности относятся: - функциональная полнота - свойство компонента, которое показывает степень достаточности основных функций для решения задач в соответствии с назначением ПО; - правильность (точность) - атрибут, который показывают степень достижения правильных результатов; - интероперабельность - атрибут, который показывают на возможность взаимодействовать ПО со специальными системами и средами (ОС, сеть); - защищенность - атрибут, который показывают на необходимость предотвратить несанкционированный доступ (случайный или умышленный) к программам и данным. 2). Надежность - совокупность атрибутов, которые определяют способность ПО преобразовывать исходные данные в результаты при условиях, зависящих от периода времени жизни (износ и его старение не учитывается). Снижение надежности ПО происходит из-за ошибок в требованиях, проектировании и выполнении. Отказы и ошибки в программах появляются на заданном промежутке времени [8-13]. К подхарактеристикам надежности ПО относятся: - безотказность - атрибут, который определяет функционирование системы без отказов (программы или оборудования); - устойчивость к ошибкам - атрибут, который показывают на способность ПО выполнять функции при аномальных условиях (сбоях аппаратуры, ошибках в данных и интерфейсах, нарушениях в действиях оператора и др.); - восстанавливаемость - атрибут, который показывают на способность программы к перезапуску для повторного выполнения и восстановления данных после отказов. К некоторым типам систем (реального времени, радарных, систем безопасности, коммуникация и др.) предъявляются требования для обеспечения высокой надежности (недопустимость ошибок, точность, достоверность, удобство применения и др.). Таким образом, надежность ПО в значительной степени зависит от числа оставшихся и не устраненных ошибок в процессе разработки на этапах ЖЦ. В ходе эксплуатации ошибки обнаруживаются и устраняются. Если при исправлении ошибок не вносятся новые, или, по крайней мере, новых ошибок вносится меньше, чем устраняется, то в ходе эксплуатации надежность ПО непрерывно возрастает. Чем интенсивнее проводится эксплуатация, тем интенсивнее выявляются ошибки и быстрее растет надежность ПО. К факторам, влияющим на надежность ПО, относятся: - риск как совокупность угроз, приводящих к неблагоприятным последствиям и ущербу системы или среды ее функционирования; - угроза как проявление нарушения безопасности системы; - целостность как способность системы сохранять устойчивость работы и не иметь риска.
Обнаруженные ошибки могут быть результатом угрозы извне или отказов, они повышают риск и уменьшают некоторые свойства надежности системы. 3). Удобство применения характеризуется множеством атрибутов, которые показывают на необходимые и пригодные условия использования (диалоговое или недиалоговое) ПО определенным кругом пользователей для получения соответствующих результатов. В стандарте [3] удобство применения определено как специфическое множество атрибутов программного продукта, характеризующих его эргономичность.
Подхарактеристиками удобства применения являются: - понимаемость - атрибут, который определяет усилия, затрачиваемые на распознавание логических концепций и условий применения ПО; - изучаемость (легкость изучения) - атрибут, который определяет усилия пользователей при определении применимости ПО, используя, например, операционный контроль, ввод, вывод, диагностику, а также процедуры, правила и документацию; - оперативность - атрибут, который показывает на реакцию системы при выполнении операций и операционного контроля; - согласованность - атрибут, который показывает соответствие разработки требованиям стандартов, соглашений, правил, законов и предписаний.
4). Эффективность - множество атрибутов, которые определяют взаимосвязь между уровнем выполнения ПО, количеством используемых ресурсов (средства, аппаратура, другие используемые материалы - бумага для печатающего устройства и др.) и услуг выполняемых штатным обслуживающим персоналом и др.
К подхарактеристикам эффективности ПО относятся: - реактивность - атрибут, который показывает время отклика, обработки и выполнения функций; - эффективность ресурсов - атрибут, показывающий количество и продолжительность используемых ресурсов при выполнении функций ПО; - согласованность: атрибут, который показывает соответствие данного атрибута с заданными стандартами, правилами и предписаниями. 5). Сопровождаемость Сопровождаемость - множество свойств, которые показывают на усилия, которые надо затратить на проведение модификаций, включающих корректировку, усовершенствование и адаптацию ПО при изменении среды, требований или функциональных спецификаций. Сопровождаемость включает подхарактеристики: - анализируемость - атрибут, определяющий необходимые усилия для диагностики в отказов или идентификации частей, которые будут модифицироваться; - изменяемость - атрибут, определяющий усилия, которые затрачиваются на модификацию, удаление ошибок или внесение изменений для устранения ошибок или введения новых возможностей в ПО или в среду функционирования; - стабильность - атрибут, указывающие на риск модификации; - тестируемость - атрибут, показывающий на усилия при проведении валидации, верификации с целью обнаружения ошибок и несоответствий требованиям, а также на необходимость проведения модификации ПО и сертификации; - согласованность - атрибут, который показывает соответствие данного атрибута с определенными в стандартах, соглашениях, правилах и предписаниях. 6). Переносимость - множество показателей, указывающих на способность ПО приспосабливаться к работе в новых условиях среды выполнения. Среда может быть организационной, аппаратной и программной. Поэтому перенос ПО в новую среду выполнения может быть связан с совокупностью действий, направленных на обеспечение его функционирования в среде, отличной от той среды, в которой оно создавалось с учетом новых программных, организационных и технических возможностей. Переносимость включает подхарактеристики: - адаптивность - атрибут, определяющий усилия, затрачиваемые на адаптацию к различным средам; - настраиваемость (простота инсталлирования) - атрибут, который определяет на необходимые усилия для запуска или инсталляции данного ПО в специальной среде; - сосуществование - атрибут, который определяет возможность использования специального ПО в среде действующей системы; - заменяемость - атрибут, который обеспечивают возможность интероперабельности при совместной работе с другими программами с необходимой инсталляцией или адаптацией ПО; согласованность - атрибут, который показывают на соответствие стандартам или соглашениями по обеспечению переноса ПО.
Согласие, достигнутое по требованиями к качеству (в оригинале - quality requirements), наравне с четким доведением до инженеров того, что составляет качество <получаемого продукта>, требуют обсуждения и формального определения многих аспектов качества. Инженеры должны понимать смысл, вкладываемый в концепцию качества, характеристики и значение качества в отношении разрабатываемого или сопровождаемого программного обеспечения. Важной идеей является то, что программные требования определяют требуемые характеристики качества программного обеспечения, а также влияют на методы количественной оценки и сформулированные для оценки этих характеристик <соответствующие> критерии приемки. Культура и этика программной инженерии (Software Engineering Culture and Ethics) Ожидается, что инженеры по программному обеспечению воспринимают вопросы качества программного обеспечения как часть своей <профессиональной> культуры. SWEBOK дает ссылки на источники, описывающие здоровую культуру программной инженерии. Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров <к своей работе>. 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). Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью (значимое для решения определенных задач или достижения целей). Ценность программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и связанной с ними стоимостью. Является ли характеристики качества чисто декоративными (умозрительными) или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно приниматься процессе работы с требованиями (см. область знаний SWEBOK "Программные требования"), однако эти вопросы могут (и должны) подниматься на протяжении всего жизненного цикла программного обеспечения. Не существует каких-то <"стандартных"> правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы (в достижении различного уровня качества) и их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более подробно обсуждаются вопросы значимости качества и соответствующих характеристик стоимости. Модели и характеристики качества (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) имеют непосредственное отношение к качеству создаваемого программного продукта. Модели и критерии оценки возможностей организаций, занимающихся разработкой программного обеспечения, прежде всего касаются рассмотрения организации проектных работ и аспектов управления. Соответственно, они рассматриваются в областях знаний SWEBOK "Управление программной инженерией" и "Процесс программной инженерии". Конечно, невозможно полностью отделить качество процесса от качества продукта. Качество процесса, обсуждаемое в области знаний "Процесс программной инженерии", влияют на характеристики качества продукта, которые, в свою очередь, отражаются в восприятии качества продукта в процессе эксплуатации со стороны заказчика. Существует два важнейших стандарта в области качества программного обеспечения. TickIT -касается рассмотрения общей системы менеджмента качества ISO 9001-00 в приложении к программным проектам (и, в частности, сочетания такого взгляда с положениями стандарта жизненного цикла ISO 12207) и представленный, также, в виде специальных рекомендаций ISO 90003-04 "Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to Computer Software". Другой важный стандарт - CMMI, обсуждаемый в области знаний "Процесс программной инженерии", предоставляет рекомендации по совершенствованию процесса. (здесь нельзя не упомянуть и ISO 15504 "Information Technology - Software Process Assessment", известный как SPICE - Software Process Improvement and Capability dEtermination, который также рассматривается в упомянутой области знаний). Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI "Support"), проверка (verification, категория "Engineering") и аттестация (validation, категория "Engineering"). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207. Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения - CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация по 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) Качество программного обеспечения может повышаться за счет итеративного процесса постоянного улучшения. Это требует контроля, координации и обратной связи в процессе управления многими одновременно выполняемыми процессами: (1) процессами жизненного цикла, (2) процессом обнаружения, устранения и предотвращения сбоев/дефектов и (3) процессов улучшения качества. К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества. Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип "building in quality". Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта напрямую связано с качеством используемых для его создания процессов. Такие подходы, как TQM (Total Quality Management - всеобщее управление качеством) PDCA (Plan, Do, Check, Act - Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами достижения задач, связанных с качеством. Поддержка менеджмента помогает в выполнении процессов, оценке продуктов и получению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой и охватывает работу подразделения или организации, в целом) детально идентифицирует все действия и проекты по улучшению <отдельных аспектов деятельности> в рамках определенного периода времени, за который такие проекты можно осуществить с успешным решением соответствующих задач. При этом, поддержка менеджмента означает, что все проекты по улучшению обладают достаточными ресурсами для достижением поставленных целей. Поддержка менеджмента тесно связана с реализацией активного взаимодействия в коллективе, и должна предупреждать возникновение потенциальных проблем (и пассивного или даже активного противодействия реализации программы совершенствования или отдельных ее проектов). Формирование рабочих групп, поддержка менеджеров среднего звена и выделенные ресурсы на уровне проекта - эти вопросы обсуждаются в области знаний "Процесс программной инженерии".
|
