Что используется в качестве программного обеспечения. Что такое качество программного обеспечения? Контроль качества: инструменты и техники

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту – «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение "качества ПО" в контексте международных стандартов:

Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств.

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

Характеристики качества ПО

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

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

Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

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

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

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.

Модель качества программного обеспечения

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

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

20. Основные черты качественного по.

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

21. Качество по: мобильность и модифицируемость.

Качество ПО - это такая характеристика программного обеспечения, которая описывает степень его соответствия требованиям.

Одними из требований к качественному ПО являются мобильность и модифицируемость.

Мобильность программного обеспечения - это способность программного обеспечения работать на различных аппаратных платформах или под управлением различных операционных систем.

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

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

22. Качество по: правильность и надёжность.

Одними из требований к качественному ПО являются правильность и надёжность.

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

Существуют следующие подходы по обеспечению надежности:

предупреждение ошибок;

самообнаружение ошибок;

самоисправление ошибок;

обеспечение устойчивости к ошибкам.

Правильность ПО – это качество ПО отвечать поставленным задачам и требованиям.

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

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

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

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

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

Стандартизация характеристик качества

Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Основой регламентирования показателей качества программных средств ранее являлся международный стандарт ISO 9126:1991 (ГОСТ Р ИСО / МЭК 9126-93) "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению". Завершается разработка и формализован последний проект состоящего из четырех частей стандарта ISO 9126-1--4 для замены небольшой редакции 1991 года. Проект состоит из следующих частей под общим заголовком "Информационная технология - характеристики и метрики качества программного обеспечения": "Часть 1. Характеристики и субхарактеристики качества" Часть 2. Внешние метрики качества" "Часть 3. Внутренние метрики качества" "Часть 4. Метрики качества в использовании".

В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется группа устаревших ГОСТов, которые отстают от мирового уровня на 5-10 лет .

Первая часть стандарта - ISO 9126-1 - распределяет атрибуты качества программных средств по шести характеристикам, используемым в остальных частях стандарта. Исходя из принципиальных возможностей их измерения, все характеристики могут быть объединены в три группы, к которым применимы разные категории метрик:

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

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

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

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

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

Выбор показателей качества

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

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

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

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

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

Оценка качества

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

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

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

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

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

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

Оценка защищенности программных средств включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1--3 "Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий".

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

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

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

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

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

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

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

Определения характеристик и субхарактеристик качества (ISO 9126-1)

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

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

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

Способность к взаимодействию - свойство программных средств и их компонентов взаимодействовать с одной или большим числом компонентов внутренней и внешней среды.

Защищенность - способность компонентов программного средства защищать программы и информацию от любых негативных воздействий.

Чуть больше года назад в журнале "Открытые Системы" была опубликована моя статья под названием "Принципы управления качеством программ". Онлайн версия доступна здесь: http://www.osp.ru/os/2008/06/5344965/ . Перед публикацией исходный вариант статьи был сильно переработан редакцией, в результате чего её размер уменьшился раза в 2, и текст, включая название, был также сильно перелопачен. Сейчас я решил опубликовать у себя в блоге авторскую обновлённую версию, внеся туда небольшие добавления. Статья не в формате блога, а скорее для научного или учебного издания, так что простите.

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

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

Определение качества программного продукта
Согласно ГОСТ Р ИСО 9000-2001 качество – это «степень соответствия присущих характеристик (продукта) требованиям». Это общее определение. Если его буквально перенести на область разработки программного обеспечения (ПО), то оно может быть не совсем верно истолковано. Дело в том, что разработка требований, в том смысле как этот термин понимается для области ПО, есть неотъемлемая часть процесса разработки этого ПО. Качество требований к программному продукту (ПП) напрямую влияет на качество самого этого ПП. Иными словами, если требования к ПП некачественные, то сам продукт, разработанный по этим требованиям, также будет некачественным даже в случае идеального соответствия.

Если слово «требования» в определении ГОСТа заменить словами «цели проекта» (здесь под проектом имеется в виду процесс разработки определённого программного продукта или расширения функциональности имеющегося продукта), то всё встаёт на свои места. Далее в статье мы будем под качеством ПП подразумевать следующее:

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

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

Функциональность (насколько ПП полезен для пользователя);
Качество пользовательского интерфейса (удобство использования, лёгкость в обучении);
Надёжность (отсутствие дефектов в ПП, устойчивость к сбоям);
Производительность, потребление ресурсов, требования к внешней среде;
Качество информационной поддержки (документация);
Сопровождаемость (качество архитектуры и кода, внутреннее качество);
+ возможно, другие критерии.

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

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

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

Обобщённое понятие дефекта
Удобно было бы ввести и использовать для анализа качества некий обобщённый критерий качества вместо нескольких разрозненных критериев. Таким критерием является обобщённое понятие дефекта:

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

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

Тип дефекта (определяется фазой разработки или активностью, на которой он был внесён);

Критичность дефекта (насколько критично его наличие в ПП);

Приоритет дефекта (насколько важно его исправить);

Сложность дефекта (насколько трудоёмко его исправить);

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

II. Управление качеством программного продукта

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

Рис. 1. Изменение количества дефектов в проекте с течением времени при традиционном подходе к управлению качеством и при водопадном жизненном цикле.

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

Эффективность поиска дефектов
Рассмотрим одну из фаз, направленных на поиск и исправление дефектов, например, фазу системного тестирования. В ходе этой фазы обнаруживается некое количество дефектов D found , в то же время некоторое количество дефектов остаётся ненайденным на момент завершения фазы D missed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно D found + D missed .

Рис. 2. Изменение количества дефектов в течение одной фазы.

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

ЭПД% = .

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

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

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

Рис. 3. Изменение стоимости исправления дефектов с течением времени (водопадный жизненный цикл).

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

Рис. 4. Изменение стоимости исправления дефектов с течением времени (итерационный жизненный цикл).

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

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

Второй подход, который можно и нужно применять параллельно, – это предотвращение или недопущение дефектов , , .

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

Рис. 5. Изменение количества дефектов в проекте с течением времени при комплексном подходе к управлению качеством.

Методы поиска дефектов
Методы поиска дефектов можно классифицировать по следующим признакам:

статические и динамические;
ручные и автоматизированные.

Таким образом, можно выделить 4 категории методов:

Ручной анализ артефактов:
Автоматическая статическая проверка:
Автоматизированное тестирование:
Ручное тестирование:

У каждого из перечисленных методов есть свои плюсы и минусы. Какие-то виды дефектов лучше ловятся одними методами, какие-то другими. Поэтому, эффективная стратегия поиска дефектов будет состоять в применении комбинации нескольких разнородных методов . Каждый метод поиска в зависимости от того, насколько хорошо он реализован и применяется в конкретных условиях, будет иметь свой собственный уровень эффективности, выраженный в процентах. В книге С. Макконнелл «Совершенный код» можно найти таблицу примерных значений эффективностей поиска дефектов для разных методов (см. копию этой таблицы ниже). Обратите внимание, что согласно этим данным тестирование имеет сравнительно низкую эффективность поиска дефектов (25%-40%), а для того, чтобы сделать её высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестеров >1000 около 75%).

Метод поиска	ЭПД%	Метод поиска	ЭПД%
Неформальный обзор дизайна (тех. проекта)	35%	Тестирование новой функции (компонента)	30%
Формальные инспекции дизайна (тех. проекта)	55%	Интеграционное тестирование	35%
Неформальный обзор кода (code review)	25%	Регрессионное тестирование	25%
Формальные инспекции кода	60%	Системное тестирование	40%
Моделирование и прототипирование	65%	Бета-тестирование (<10 тестеров)	35%
Юнит-тестирование	30%	Бета-тестирование (>1000 тестеров)	75%

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

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

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

Применение компонентного (или модульного) подхода . Грамотное применение компонентного подхода при построении программных систем уменьшает их сложность , а, следовательно, сужает пространство возможных дефектов.

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

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

Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать её. Частный случай этого подхода – Test-Driven Development , при котором модульные тесты разрабатываются не после, а до кодирования.

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

Ваши идеи?

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

Управление качеством при итерационном жизненном цикле
Рассмотрим для примера итерационный жизненный цикл, состоящий из 5 итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 6).

Рис. 6. Изменение количества дефектов в проекте с течением времени при итерационном жизненном цикле.

Предположим, что эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Подсчитаем по формуле ЭПД%, чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций. После 1-й итерации эта эффективность будет равна 50%; после 2-й – 62,5%; после 3-й – 70,8%; после 4-й – 76,6%; после 5-й эффективность поиска дефектов всех 5 итераций будет равна 80,6%.

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

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

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

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

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

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

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

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

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

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

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

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

систематическое применение методов предотвращения дефектов;

постоянный контроль качества разрабатываемого ПП и процесса разработки;

постоянное усовершенствование процесса разработки с целью повышения качества.

Литература

1. Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Copyright 1995 by Addison-Wesley.
2. Макконнелл С., Совершенный код. Мастер-класс / Пер. с англ. –М.: Издательско-торговый дом «Русская Редакция»; СПб.: Питер, 2005.
3. Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Copyright 2005 by Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: a self-improvement process for software engineers, ISBN 0-321-30549-3. Copyright 2005 Pearson Education, Inc.
5. Амблер С., Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. Пер. с англ. –СПб.: Питер, 2005.
6. Кролл П., Кратчен Ф., Rational Unified Process – это легко. Руководство по RUP для практиков. Пер. с англ. –М.: КУДИЦ-ОБРАЗ, 2004.
7. Торрес Р. Дж., Практическое руководство по проектированию и разработке пользовательского интерфейса. Пер с англ. –М.: Издательский дом «Вильямс», 2002.
8. Бобровский С., Программная инженерия. Технологии Пентагона на службе российских программистов. –СПб.: Питер, 2003.
9. Хант Э., Томас Д., Программист-прагматик. Путь от подмастерья к мастеру. Пер. с англ. –М.: Издательство «Лори», 2004.
10. Фаулер М., Рефакторинг: улучшение существующего кода. Пер. с англ. –СПб.: Символ-Плюс, 2005.
11. Бек К., Экстремальное программирование. Пер. с англ. –СПб.: Питер, 2002.
12. Бек К., Экстремальное программирование: разработка через тестирование. Библиотека программиста. Пер. с англ. –СПб.: Питер, 2003.
13. ГОСТ Р ИСО 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Ройс Уокер, Управление процессом создания программного обеспечения. Пер. с англ. –М.: Издательство «Лори», 2007.
15. Tian, Jeff, Software Quality Engineering, ISBN 0-471-71345-7. Copyright 2005 by the IEEE Computer Society.