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

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



Смотрите также:
Программа (типовая) организации работы с потребителями по контролю качества электрической...
Тесты по курсу мок /Методы обеспечения и оценки качества машин/ Тема Общие вопросы оценки...
Наименование и краткое содержание лекций №№ п/п Тема лекции, краткая аннотация Кол-во часов 1...
Это соблюдение всех установленных требований к продукции, процессу или услуге...
Правила организации и осуществления внешнего контроля качества работы членов...
V. A. Lobanova, O. A. Voronina, S. Y. Izvekov, O. M...
Положение о системе внутреннего мониторинга качества образования в оу общие положения...
Учебно-тематический план цель...
Контроль качества сварных соединений трубопроводов стальных, из полимерных материалов...
И. Н. Медведева (Псковский государственный педагогический институт)...
Планирование качества 13 1 Цели в области качества 13 2 Планирование системы менеджмента...
Рабочая программа дисциплины администрирование информационных систем Специальность 010503...



скачать
Л3 Планирование и контроль качества ПС

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

1.Содержание плана обеспечения качества 1

2. Сущность контроля качества ПС 2

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

ПРИЛОЖЕНИЕ. Процесс оценки уровня качества ПС по ГОСТ 28195-89 8



  1. Содержание плана обеспечения качества



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

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

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

2 .Раздел 2 Планы выпуска продукта. Назначение крайних сроков выпуска версий программного продукта, распределение ответственности за разработку продукта и его обслуживание.

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

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

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

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

  • Списки объектов контроля.

  • •Показатели и методы оценки оценки качества .

  • •Технические спецификации.

  • •Связи с другими функциональными областями управления


При работе над планом обеспечения качества важно, чтобы он был как можно более кратким.

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

Таблица 1

Показатели качества ПС

Надежность

Понятность

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

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

Возможность тестирования

Удобство эксплуатации

Устойчивость к внешним воздействиямь

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

Возможность повторного использования

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

Модульность

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



^

2. Сущность контроля качества ПС



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

•Контроль качества заключается в определении соответствия результатов проекта стандартам качества и причин нарушения такого соответствия. Результатами проекта являются как продукты, так и процессы управления.

•Исходные данные:

–Списки объектов контроля

–Технические спецификации

–План управления качеством

Контрольные проектные элементы проверяют согласно четко определенным стандартам процесса контроля качества (рис.1).





Рис. 1. Контроль качества как процесс наблюдения за процессом разработки


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

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

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

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

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

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

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

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

Таблица2.

Типы проверок качества

Тип проверки

Цель проверки

Инспекция структуры и программного кода ПС

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

Промежуточные проверки

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

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

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

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

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

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

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

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

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



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

Для обеспечения полноты измерения качества требуется  на ранних стадиях проекта на основе анализа целей проекта, области применения, ограничений и характеристик разработать комплексные проектно-ориентированные структурные метрики качества.. (design-oriented structural metrics)

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

Измерение качества в соответствии с данными метриками состоит в вычислении отклонения фактических характеристик продукта от норм и правил. Методология создания метрик качества указанным способом утверждена в стандарте IEEE 1061 Схематически методология создания метрик качества состоит из следующих шагов:

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

    • Формирование требований качества

    • Выбор свойств (атрибутов), установка приоритетов и связи с требованиями

    • Присвоение атрибутов факторам качества, которые отражают представление заказчика на качество.

    • Установка измерений для факторов качества. Определение допустимых коридоров для величин качества.

  • Второй шаг (средний уровень иерархии): Определение технического уровня (то есть уровня предназначенного для аналитиков, конструкторов, разработчиков):

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

  • Третий шаг (нижний уровень иерархии):

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


^
Рис. 2. Схема вывода метрик качества

Для иллюстрации метода можно привести следующие примеры:

Факторы качества программной системы:

  • Переносимость (portability) – усилия, требуемые для переноса системы с одной платформы на другую.

  • Надежность (reliability) – ожидаемая степень корректного выполнения системой требуемых функций

  • Тестируемость (testability) – усилия, требуемые для тестирования функций программы

Прямые измерения факторов качества:

  • Переносимость (portability) – трудоемкость - количество чел.-час., требуемое для переноса программы с платформы X на платформу Y. Допустимый порог: 1 чел.-час. на 1K строк исходного кода .

  • Надежность (reliability) – среднее время наработки на отказ. Допустимый порог: 120 операционных дней.

  • Тестируемость (testability) – трудоемкость – количество чел.-час., требуемое для полного тестирования 90% всех модулей. Допустимый порог 10 чел.-час. на 1K строк исходного кода.

Следующий шаг – проведение декомпозиции приведенных факторов на суб-факторы (рис. 3).


^
Рис. 12. Пример структуры факторов качества






Должны быть даны определения суб-факторов качества. Примеры требуемых определений (по Артуру (Arthur L.A.): 

  • Точность (accuracy) – правильность вычислений и контроля;

  • Сложность (complexity) – трудность разработки и модификации;

  • Совместимость (consistency) – использование унифицированной технологии проектирования и разработки на протяжении всего цикла разработки;

  • Устойчивость к ошибкам (error tolerance) – степень ущерба от возникающих ошибок;

  • Универсальность (generality) – широта потенциального использования;

  • Аппаратная независимость (hardware independence) – степень применимости программы на другом аппаратном обеспечении;

  • Оснащенность средствами контроля (instrumentation) – степень контроля программы собственного выполнения и идентификации возникающих ошибок;

  • Модульность (modularity) – степень функциональной независимости программных компонент;

  • Удобочитаемость (readability) – уровень смыслового наполнения комментирования, соответствие стандартам кодирования и именования;

  • Простота (simplicity) – легкость понимания программы;

  • Системная независимость (system independence) степень независимости от нестандартных характеристик системного окружения и ограничений.

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

Сложность (complexity):  – использование метрики цикломатической сложности Мак Кэйба (McCabe’s cyclomatic complexity metric )

Устойчивость к ошибкам (error tolerance): использование правила (нормы): «все модули должны содержать обработчики предопределенных исключительных ситуаций. Все обрабатываемые исключительные ситуации должны быть либо распространены на внешний уровень, либо разрешены».

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

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

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

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

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

Заключение


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

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


^

ПРИЛОЖЕНИЕ. Процесс оценки уровня качества ПС по ГОСТ 28195-89


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

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

Таблица 2

Выбор показателей качества в фазах жизненного цикла

№ п/п

Критерий

Метрика

Фаза жизненного цикла

Анализ

Проектирование

Реализация, тестирование, изготовление, сопровождение

1

2

3

4

5

6

1

Устойчивость

функционирования

Средства восстановления при ошибках на входе







Средства восстановления при сбоях оборудования







Реализация управления средствами восстановления







2

Работоспособность

Функционирование в заданных режимах







Обеспечение обработки заданного объема информации







3

Простота конструкции

Простота архитектуры проекта







Сложность архитектуры проекта







Межмодульные связи







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







4

Наглядность

Экспертиза принятой системы идентификации







Комментарии логики программного проекта







Оформление текста программ







5

Структурность

Использование основных логических структур







Соблюдение принципа нисходящего программирования







Обоснование декомпозиции программ при кодировании







6

Повторяемость

Использование типовых компонентов








Использование типовых проектных решений








7

Легкость освоения

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







Документация для освоения







8

Доступность эксплуатационных документов

Полнота документации







Точность документации







Понятность документации







Техническое исполнение документации







Прослеживание вариантов документации







9

Удобство эксплуатации и обслуживания

Эксплуатация







Управление меню







Функция поддержки справочной системы (помощи)







Управление данными







Рабочие процедуры







10

Уровень автоматизации

Функции автоматизации







11

Временная эффективность

Затраты времени







12

Ресурсоемкость

Использование вычислительных ресурсов







13

Гибкость

Широта охвата функций







Простота архитектуры проекта







Сложность архитектуры проекта







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







Применение стандартных протоколов связи







Применение стандартных интерфейсных программ







14

Мобильность

Зависимость от используемого комплекса технических средств







Зависимость от базового программного обеспечения








Изоляция немобильности








15

Модифицируемость

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









Число комментариев









Качество комментариев









Использование описательных средств языка









Независимость модулей









16

Полнота реализации

Полнота документации разработчика







Полнота программной документации









17

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

Непротиворечивость документации








Непротиворечивость программы









Единообразие межмодульных и пользовательских интерфейсов







Единообразие кодирования и определения переменных








Соответствие документации стандартам








Соответствие программы стандартам программирования







Соответствие программы документации







18

Логическая корректность

Реализация всех решений







Отсутствие явных ошибок







19

Проверенность

Требования к полноте тестирования









2. Показатели качества объединяют в систему из четырех уровней (рис. 5). Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней. Допускается вводить дополнительные показатели на каждом из уровней. Для обеспечения возможности получения интегральной оценки по группам показателей качества используют факторы качества (1-й уровень): надежность, сопровождаемость, удобство применения, эффективность, универсальность, корректность. Каждому фактору качества соответствует определенный набор критериев качества (комплексных показателей 2-го уровня): устойчивость функционирования, работоспособность, структурность, простота конструкции, наглядность, повторяемость, легкость освоения, доступность эксплуатационных документов, удобство эксплуатации и обслуживания, уровень автоматизации, временная эффективность, ресурсоемкость, гибкость, мобильность, модифицируемость, полнота реализации, согласованность, логическая корректность, проверенность. Критерии качества определяют одной или несколькими метриками (3-й уровень). Метрики составляют из оценочных элементов (единичных показателей – 4 уровень), определяющих заданное в метрике свойство. Число оценочных элементов, входящих в метрику, не ограничено. Взаимосвязь критериев и метрик показана в таблице 2. Выбор оценочных элементов в метрике зависит от функционального назначения оценочного элемента и определяется с учетом данных, полученных при проведении испытаний различных видов, а также по результатам эксплуатации программного обеспечения. Для накопления информации об оценочных элементах формируют справочник оценочных элементов на основе ранее полученных данных о качестве аналогичных программных средств.

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

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

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

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

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

(1)

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

Определение усредненной оценки оценочного элемента по нескольким его значениям проводят по формуле для среднего арифметического:

(2)

где s – количество значений оценочного элемента Мэ, k – порядковый номер метрики, q – порядковый номер оценочного элемента метрики.

Итоговую оценку метрики определенного критерия проводят по формуле для среднего значения составляющих метрику усредненных значений оценочных элементов:

(3)

где Q – число оценочных элементов в k-ой метрике j-го критерия.

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

(4)

где n – количество метрик, относящихся к j-тому критерию.

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

(5)

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

(6)

где N – число критериев качества, относящихся к i-тому фактору.

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

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

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

Для оценки качества программного обеспечения в этих условиях используем рекомендации ГОСТ 28195-89.

Используемый ГОСТ 28195-89 классификатор программной продукции позволяет отнести оцениваемое программное обеспечение к классу программ для решения экономических задач (класс 506).

Согласно рекомендациям ГОСТ 28195-89 для этого класса программной продукции, выберем следующую номенклатуру показателей качества (таблица 1):

устойчивость функционирования,

доступность эксплуатационных документов,

полнота реализации,

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

логическая корректность,

проверенность.

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

Значения базовых показателей надежности и корректности установим на уровне 0,63 и 0,9 соответственно.

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

7)

где элементами кортежа являются оценки факторов надежности и корректности (6).

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

Критерии и метрики выбранной номенклатуры показателей качества представлены в таблице 3.

Для получения численных значений выбранных критериев используем восемь метрик (таблица 3) и пятнадцать оценочных элементов, указанных в таблице 4.

Таблица 3

Показатели качества

Критерий

Метрика

Устойчивость функционирования

Требования к средствам восстановления при ошибках на входе.

Требования к средствам восстановления при сбоях оборудования.

Полнота реализации

Требования, предъявляемые к полноте документации разработчика.

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

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

Требования, предъявляемые к единообразию кодирования, символики и определения общих переменных.

Требования, предъявляемые к соответствию стандартам программирования.

Проверенность

Требования, предъявляемые к полноте тестирования.

Логическая корректность

Требования, предъявляемые к реализации

Результаты оценки устойчивости функционирования экспертами представлены в табл. 4.

Таблица 4

Оценка устойчивости функционирования

Оценочный элемент

Код

(ГОСТ 28195-89)

Значение

1

2

3

Наличие требований к программе по устойчивости функционирования

Н0101

1

Возможность обработки ошибочных ситуаций

Н0102

0,5

Полнота обработки ошибочных ситуаций

Н0103

0,5

Наличие тестов для проверки допустимых значений входных данных

Н0104

1

Наличие системы контроля полноты входных данных

Н0105

0

Наличие средств контроля корректности входных данных

Н0106

1

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

Н0107

1

Наличие проверки параметров и адресов по диапазону их значений

Н0108

1

Наличие обработки граничных результатов

Н0109

1

Наличие обработки неопределенностей (деление на 0 и. т. д)

Н0110

1

Значение метрики из элементов Н0101-Н0110

0,8

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

Н0201

1

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

Н0202

0

Наличие средств восстановления процесса в случае сбоев оборудования

Н0203

0

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

Н0204

1

Наличие возможности повторного старта с точки останова

Н0205

1

Значение метрики из элементов Н0201-Н0205

0,6

Коэффициент важности первой метрики (таблица 3)

0,8

Коэффициент важности второй метрики (таблица3)

0,2

Абсолютное значение показателя (формула 4 )

0,80,8 + 0,60,2=0,76

Базовое значение показателя

0,8

Относительное значение показателя (формула 5)

0,76/0,63= 1,2



ПРИМЕЧАНИЕ: буква в коде оценочного элемента соответствует первой букве наименования оцениваемого фактора качества (Н-надежность), а комбинация цифр – номеру метрики и оценочного элемента).

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

(8)

Второй элемент кортежа (7) - фактор корректности мы оцениваем не одним, а четырьмя критериями: полнотой реализации, согласованностью, проверенностью и логической корректностью (таблица 3). Оценки по (5) и (6) требует введения не только весовых коэффициентов для метрик, но и для каждого из четырех критериев. Допустим, что все критерии равноценны и имеют весовой коэффициент 0,25. Допустим, что действуя согласно рекомендациям ГОСТ 28195-89 по оценочным элементам, получены оценки значений метрик из таблицы 3:

1. Требования, предъявляемые к полноте документации разработчика – оценка 0,8.

2. Требования, предъявляемые к единообразию интерфейсов между модулями и пользователями – оценка 0,5.

3. Требования, предъявляемые к единообразию кодирования, символики и определения общих переменных - оценка 0,9.

4. Требования, предъявляемые к соответствию стандартам программирования – оценка 0,5.

5. Требования, предъявляемые к полноте тестирования – оценка 0,5.

6. Требования, предъявляемые к реализации – оценка 1.

Полагая равновесными метрики отдельных критериев таблицы 3, из (4) получим абсолютные значения показателей качества:

полноты реализации (0,8=0,81);

согласованности (0,627=0,33(0,5+0,9+0,5));

проверенности (0,5=0,51);

логической корректности (1=11).

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

Таблица 5

Относительные показатели качества по критериям корректности

Критерий

Абсолютное значение

Базовое значение

Относительное значение

Коэффициент важности

Полнота реализации

0,8

0,9

0,89

0,25

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

0,627

0,5

1,25

0,25

Проверенность

0,5

0,5

1

0,25

Логическая корректность

1

0,9

1,1

0,25



Используя данные таблицы 5, из (6) получим оценку фактора корректности

(9)

Таким образом, качество программного обеспечения на ранней стадии разработки характеризуется кортежем значений

(10)

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




Скачать 291,81 Kb.
оставить комментарий
Дата16.10.2011
Размер291,81 Kb.
ТипДокументы, Образовательные материалы
Добавить документ в свой блог или на сайт

Ваша оценка этого документа будет первой.
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх