Планирование и контроль уровня качества: план обеспечения качества, сущность контроля и проверок качества, процесс оценки (измерения) комплексных показателей и уровня качества. Содержание плана обеспечения качества 1
| скачать Л3 Планирование и контроль качества ПС Планирование и контроль уровня качества: план обеспечения качества, сущность контроля и проверок качества, процесс оценки (измерения) комплексных показателей и уровня качества. 1.Содержание плана обеспечения качества 1 2. Сущность контроля качества ПС 2 3. Процесс оценки комплексных показателей и уровня качества 5 ПРИЛОЖЕНИЕ. Процесс оценки уровня качества ПС по ГОСТ 28195-89 8
Сущностью планирования качества является определение того, какие стандарты качества следует использовать, чтобы содержание проекта оправдывало ожидания участников проекта.•Планирование качества включает, как идентификацию этих стандартов, так и поиск путей их реализации. Планирование качества начинают на самой ранней стадии проекта. Результатом процесса планирования является план обеспечения качества. План обеспечения качества должен быть основан на предполагаемых свойствах продукта и методах их проверки. Для этого прежде всего для ПС необходимо наполнить содержанием понятие "требуемый уровень качества". Без этого программисты могут работать, делая акценты на разных свойствах продукта. Из всех организационных стандартов в плане обеспечения качества нужно указать наиболее подходящие к создаваемому программному продукту или процессу его разработки. Если в проекте используются новые методы или инструментальные средства, то могут быть добавлены новые стандарты к уже существующим. Обычно план оформляется как документ со следующими разделами. 1. Раздел 1. ^ Описание продукта, намечаемый рынок его сбыта, а также ожидаемые свойства. 2 .Раздел 2 Планы выпуска продукта. Назначение крайних сроков выпуска версий программного продукта, распределение ответственности за разработку продукта и его обслуживание. 3. Раздел 3. Описания процессов. Представление процессов разработки и обслуживания программного продукта в ходе выполнения проекта и управления им со ссылками на используемые стандарты. 4. Раздел 4. Цели качества. Планы и цели обеспечения качества продукта, включая описание наиболее важных его характеристик. 5. Раздел 5. Риски и управление рисками. Описание основных видов риска, которые могут оказать влияние на уровень качества продукта, и мероприятия, направленные на снижение рисков. В самом общем случае план управления качеством содержит правила поведения команды проекта при осуществлении управления качеством. План управления качеством входит в общий план проекта и должен описывать контроль, обеспечение и улучшение качества проекта. Он может быть формальным или неформальным, высоко детализированным или общим в зависимости от осуществляемого проекта. Его •результаты должны содержать:
При работе над планом обеспечения качества важно, чтобы он был как можно более кратким. Существует ряд потенциальных показателей качества ПС (табл. 1), которые практически всегда учитывают при составлении плана обеспечения качества. На практике трудно создать настолько совершенную систему, чтобы она идеально удовлетворяла всем этим показателям, однако для конкретного проекта можно выбрать наиболее важные показатели и спланировать пути их достижения. Поэтому в плане обеспечения качества должны быть определены приоритеты основных показателей качества разрабатываемого продукта, их базовые значения, к которым нужно стремиться, .и указан процесс количественного оценивания фактического уровня качества. . Таблица 1 Показатели качества ПС
^ Контроль качества предусматривает наблюдение за процессом разработки ПО с тем, -чтобы гарантировать соблюдение определенных нормативных процедур и стандартов. •Контроль качества заключается в определении соответствия результатов проекта стандартам качества и причин нарушения такого соответствия. Результатами проекта являются как продукты, так и процессы управления. •Исходные данные: –Списки объектов контроля –Технические спецификации –План управления качеством Контрольные проектные элементы проверяют согласно четко определенным стандартам процесса контроля качества (рис.1).  Рис. 1. Контроль качества как процесс наблюдения за процессом разработки Процесс контроля качества имеет собственный набор процедур и отчетов, которые' могут быть использованы в процессе разработки ПС. Они должны иметь четкую структуру-и быть понятными специалистам по разработке ПС. Существует два взаимодополняющих подхода к процессу контроля качества. 1. Проверки качества, когда программный продукт, сопровождающая документация и процесс разработки анализируются группой проверяющих. Эта группа ответственна за проверку соблюдения стандартов проекта, а также за соответствие документации этим стандартам. Любые отклонения от стандартов регистрируются и подаютя на рассмотрение менеджеру проекта. 2. Автоматизированная оценка ПС, когда программный продукт и его документация проверяются специальной компьютерной программой, которая сопоставляет их с._ стандартами данного проекта. В такую автоматизированную проверку можно включить количественный контроль некоторых характеристик ПС. Заметим, что проектная документция, которой будет отчитываться разработчик (если такая норма предусмотрена) в форме пояснительных записок и разного рода отчетов, а также документ, описывающий предметную область (анализ предметной области) может быть весьма удобным средством контроля качества со стороны ответственных лиц. Традиционными методами контроля качетсва обычной (не программной продукции) являются различного рода проверки, или инспекции, с использованием статистических выборок, диаграмм Парето или других диаграмм контроля качества. Проверки — наиболее распространенный способ оценивания качества как процесса разработки, так и самого ПС. Для проверки, как правило, подбирают группу специалистов, которые изучают отдельный этап или процесс разработки в целом, создаваемую программную систему и сопровождающую документацию для выявления возможных проблем. Результаты проверки обычно заносят в официальный отчет и передаются разработчикам системы либо лицу, ответственному за исправление ошибок. В табл. 2 представлены некоторые типы различных проверок в ходе разработки, относящихся к контролю качества. Инспектирование программ и промежуточные проверки – это часть процесса управления разработкой, связанная с верификацией и аттестацией (проверка соответствия спецификации и соответствия ожиданиям заказчика), а проверки качества – это относительно самостоятельный элемент процесса управления качеством. Таблица2. Типы проверок качества
Целью группы проверки качества является обнаружение ошибок и противоречий для того, чтобы довести их до сведения разработчика или автора документации. Важно, что все проверки основаны на документации, однако они не ограничены только спецификацией, структурой системы или программным кодом. Проверке подвергаются и такие документы, как модель процесса разработки, планы тестирования, процедура управления конфигурацией, стандарты процесса разработки и руководство пользователя. Таким образом документация- основной и самый важный артефакт для проведения контроля качества. В команду проверки качества должны быть включены те специалисты, которые могут прнести наибольшую пользу. Например, при проверке структуры ПС в такую команду должны входить программисты, которые участвовали в разработке подобных ПС. Ядром группы должно быть не более 3-4 человек, отобранных в качестве основных проверяющих. Один из них должен быть старшим, т.е. ответственным за принятие технический решений. Основные проверяющие могут приглашать других разработчиков проекта для участия в проверке. Им не обязательно принимать участие во всей проверке. Достаточно, чтобы они проверяли те части проекта, которые могут непосредственно повлиять на их работу. Кроме того, команда проверки качества может раздать тестируемый документ, чтобы получить письменные комментарии от других членов коллектива разработчиков. Документы должны быть розданы до начала проверки с тем, чтобы рецензенты могли ознакомитья с ними и понять их суть. Хотя такие задержки и затягивают иногда процесс, но проверка не будет иметь смысла, если команда не разберется в документе перед проведением проверки. Конечно, проверяемые документы должны быть розданы заранее, до начала проверки, чтобы рецензенты могли ознакомиться с ними и понять суть. Сама проверка должна быть короткой , не более двух часов, в течении которого автор документа вместе с группой проверки работают с документом по определенному сценарию. Один из группы руководит процессом проверки, а другой протоколирует результаты . При проверке должны быть рассмотрены все письменные замечания, которыми располагает группа проверки. По окончании проверки все •действия проверяющих должны быть занесены в отчет, который подписывается проверяющим лицом, возглавляющим проверку. В дальнейшем эти отчеты составят часть офици-циальной документации по проекту. Если были обнаружены только незначительные недоработки, проводить повторную проверку после доработки нет необходимости, но возглавляющий проверку специалист обычно несет ответственность за выполенение необходимых изменений в проекте. Если необходимо внести много изменений, то после их внесения по разработанному плану, проверку нужно провести повторно.- ^ В настоящее время разработано множество метрик качества программного обеспечения общего назначения, таких как сложность, модульность, тестируемость и т.п. Использование данных метрик, безусловно, очень полезно, вместе с тем следует учитывать, что универсальные метрики в совокупности не дают полного численного описания уровня качества. В частности, вследствие универсальности им присущи следующие недостатки: они базируются в большей степени на лексических и синтаксических характеристиках и не учитывают семантическую составляющую продукта; они сконструированы без учета особенностей требуемой предметной области, операционного окружения и методологии разработки. Традиционные метрики не учитывают качество обрабатываемых данных и взаимодействие данных с потоком вычислений
Должны быть даны определения суб-факторов качества. Примеры требуемых определений (по Артуру (Arthur L.A.):
Окончательно, для приведенных суб-факторов должны быть определены правила (нормы) и метрики. В случае возможности, целесообразно использовать стандартные метрики для проведения измерений. Приведем несколько примеров: Сложность (complexity): – использование метрики цикломатической сложности Мак Кэйба (McCabe’s cyclomatic complexity metric ) Устойчивость к ошибкам (error tolerance): использование правила (нормы): «все модули должны содержать обработчики предопределенных исключительных ситуаций. Все обрабатываемые исключительные ситуации должны быть либо распространены на внешний уровень, либо разрешены». Метрики и правила (нормы) могут быть использованы для планирования уровня качества и для непосредственных измерений. Например, метрикой для правила может быть количество нарушений нормы на единицу объема программного обеспечения. Важным свойством приведенных иерархических метрик является возможность предсказания уровня качества, которое может быть выведено на основе измерения непрямых метрик. При этом получение измерения на верхнем уровне иерархии производится обычно расчетом взвешенной суммы метрик нижнего уровня. Преимущества методологии качества IEEE основано на возможности обеспечения полноты управления качеством в проектах разработки программного обеспечения. При этом эффективность управления качеством будет зависеть от тщательности проектирования иерархической структуры метрик качества на основе целей и особенностей конкретного проекта разработки программного обеспечения. Важной особенностью подхода IEEE является возможность управлять качеством на всех этапах жизненного цикла разработки программного обеспечения, поскольку разработанные правила и нормы (guidelines) для всех факторов качества являются не только метриками, но и инструкциями, выполнение которых может планироваться до исполнения и контролироваться в процессе работы. Детальная разработка системы качества по данной методике требует времени и средств, поэтому в практике разработки программных систем она используется при создании и внедрении высококритичных программных систем с высокой стоимостью разработки (системы управления транспортом, системы военного назначения, системы обеспечения безопасности, банковские системы и т.п.) ЗаключениеОпыт управления качеством показывает, что финансовые затраты, произведенные для улучшения качества продукта, являются безусловно целесообразными и дают в итоге высокий экономический эффект. Причина, по которой многие организации воздерживаются от таких расходов, состоит, прежде всего, в трудностях связанных с планированием и оценкой результатов повышения качества. Частой является ситуация, когда реализуется решение о повышении качества, основываясь на неформальных, интуитивных способах оценки качества. Это неизбежно ведет к неэффективному расходованию ресурсов и фактически увеличивает реальную цену качества. Тщательно проведенный метрический анализ качества в соответствии с целями разработки создает основу для корректного планирования и контроля затрат на качество для достижения требуемых показателей и эффективности использования ресурсов. ^ Процесс оценки качества программного обеспечения для каждой фазы жизненного цикла, согласно ГОСТ 28195-89, содержит группы работ, объединенных в нижеследующую последовательность четырех высокоуровневую процедур. 1. Выбор номенклатуры показателей качества, их оценку и сопоставление значений показателей, полученных в результате сравнения с базовыми показателями, проводят в зависимости от фазы жизненного цикла (таблица 2). Таблица 2 Выбор показателей качества в фазах жизненного цикла
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 Оценка устойчивости функционирования
ПРИМЕЧАНИЕ: буква в коде оценочного элемента соответствует первой букве наименования оцениваемого фактора качества (Н-надежность), а комбинация цифр – номеру метрики и оценочного элемента). Полученное в таблице 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,81); согласованности (0,627=0,33(0,5+0,9+0,5)); проверенности (0,5=0,51); логической корректности (1=11). Расчет относительных показателей качества по критериям корректности и соответствующие коэффициенты важности представлены в таблице 5. Таблица 5 Относительные показатели качества по критериям корректности
Используя данные таблицы 5, из (6) получим оценку фактора корректности  (9)Таким образом, качество программного обеспечения на ранней стадии разработки характеризуется кортежем значений  (10)Значения элементов кортежа большие единицы свидетельствуют о том, что разработчики обеспечили заданный уровень качества.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ваша оценка этого документа будет первой.
Ваша оценка: 