Рефераты. Модели и характеристики качества. Повышение качества.

Модели и характеристики качества. Повышение качества.

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

Санкт-Петербургский государственный университет

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

Кафедра № 44

Преподаватель Пятлина Е.О.

Модели и характеристики качества.

Повышение качества.

ДОКЛАД

по курсу: Технология программирования

Работу выполнил

Студент группы 4142 Гарезин А.С.

Санкт-Петербург

2006

1. Модели и характеристики качества

1.1Модели и характеристики качества (Models and Quality Characteristics)
В различных источниках (таксономиях и моделях) терминология характеристик качества программного обеспечения отличается. Каждая модель включает различное число уровней иерархии и общее число <”распознанных”> характеристик качества. Различные авторы создали разные модели качества со своим набором характеристик и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла разработки программного обеспечения, которая рассматривается автором за рамками перевода и комментирования SWEBOK). Эти модели могут быть полезны для обсуждения, планирования, (адаптации, прим. автора) и оценки качества программных продуктов. ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126–01 Software Engineering – Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598–98 Software Product Evaluation).

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

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

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

Существует два важнейших стандарта в области качества программного обеспечения. Tick IT – касается рассмотрения общей системы менеджмента качества 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.

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

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

Понимание термина “продукт” расширено включением всех артефактов, создаваемых на выходе всех процессов, используемых для создания конечного программного продукта. Примерами продукта являются (но не ограничиваются этим): полная спецификация системных требований (system requirements specification), спецификация программных требований для программных компонент системы (software requirements specification, SRS), модели, код, тестовая документация, отчеты, создаваемые в результате работ по анализу качества. Хотя, чаще всего термин качество используется в отношении конечного продукта и поведения системы в процессе эксплуатации, хорошей инженерной практикой является требование к тому, чтобы соответствие заданным характеристикам качества оценивалось и для промежуточных результатов/продуктов жизненного цикла в рамках всех процессов программной инженерии.

2. Стандарт ISO 9126

Еще не так давно все требования к приложениям делились на функциональные и нефункциональные. Первые, как правило, были представлены двоичным значением «работает/не работает», а вторые — длинным списком свойств, верифицируемых субъективно (например, «дружелюбность, устойчивость, безопасность»). В последнее время ситуация изменилась, и полный список типов возможных требований был стандартизован в рамках стандарта ISO 9126 .

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

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

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

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

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

Страницы: 1, 2