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

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

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

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

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

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

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

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

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

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

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

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

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

Эффективность поиска дефектов

Рассмотрим, например, фазу системного тестирования, в ходе которой обнаруживается некое количество дефектов Dfound, но сколько-то дефектов остается ненайденным на момент завершения фазы Dmissed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно Dfound + Dmissed.

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

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

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

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

Рис. 3. Изменение стоимости исправления дефектов

Комплексный подход к управлению качеством

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

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

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

Методы поиска и предотвращения дефектов

Известно немало методов поиска дефектов.

  • Ручной анализ, или обзор разрабатываемых артефактов. Персональные проверки (personal review) [2], формальные инспекции [2, 3], групповые обзоры (walkthrough), парное программирование [4], групповое проектирование и т.п.
  • Автоматическая статическая проверка. Компиляция (помимо явных дефектов компилятор умеет находить неявные), статический анализ кода с помощью специальных анализаторов, проверка на соблюдение принятого код-стандарта и стиля.
  • Автоматизированное тестирование. Модульное или блочное тестирование (unit testing) [4, 5], функциональное (комплексное) тестирование, тестирование графического интерфейса пользователя, тестирование производительности, стресс-тестирование, использование утверждений (asserts) [6] и т.д.
  • Ручное тестирование Интеграционное, системное, сравнительное, верификация требований, «охота за ошибками» (bug bash), пошаговая трассировка [6] и т.д.

Эффективная стратегия поиска дефектов состоит в применении комбинации нескольких методов, каждый из которых будет иметь свой собственный уровень эффективности, выраженный в процентах. Согласно данным [1], тестирование имеет сравнительно низкую эффективность поиска дефектов (30-40%), а для того, чтобы сделать ее высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестировщиков более 1000 составляет около 75%).

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

  • Прототипирование. Создание и опробование модели разрабатываемой системы с целью проверить ее характеристики и выявить неверные предположения и решения, которые могли бы привести к серьезным дефектам (и переделкам) при разработке [6].
  • Использование стандартов на все виды продуктов, производимых в ходе разработки ПО (требования, дизайн, код, различная документация и т.д.).
  • Применение компонентного подхода [6].
  • Использование готовых компонентов— чем меньше приходится разрабатывать новых решений, тем меньше ошибок.
  • Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать ее. Частный случай этого подхода— Test-Driven Development, при котором модульные тесты разрабатываются не после, а до кодирования.
  • Рефакторинг кода, то есть приведение его в надлежащий вид [5].
  • Регулярный анализ причин появления наиболее серьезных дефектов и поиск путей устранения этих причин. Это может происходить на периодических собраниях команды разработчиков [3], или можно проводить такой анализ для каждого серьезного дефекта, найденного на этапах системного тестирования или после внедрения. Результатом такого анализа должны быть модификации процесса разработки, направленные на устранение причин появления дефектов или, как минимум, способствующие более раннему обнаружению подобных дефектов.

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

Итерационный жизненный цикл

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

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

Предположим, эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций? После первой итерации эффективность будет равна 50%; после второй— 62,5%; после третьей— 70,8%; после четвертой— 76,6%; после пятой эффективность поиска дефектов всех пяти итераций будет равна 80,6%.

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

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

Цена качества

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

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

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

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

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

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

Литература

  1. Макконнелл С., Совершенный код. Мастер-класс / Пер. с англ.— М.: «Русская Редакция»; СПб.: Питер, 2005.
  2. Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Addison-Wesley Longman, 1995.
  3. Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Addison Wesley Longman, 2005.
  4. Бек К., Экстремальное программирование. Пер. с англ.— СПб.: Питер, 2002.
  5. Фаулер М., Рефакторинг: улучшение существующего кода. Пер. с англ.— СПб.: Символ-Плюс, 2005.
  6. Хант Э., Томас Д., Программист-прагматик. Путь от подмастерья к мастеру. Пер. с англ.— М.: Издательство «Лори», 2004.

Вадим Савкин (vadim.savkin@gmail.com) — инженер по процессам разработки ПО компании CQG (Москва).

Таблица. Зависимость видов деятельности и критериев качества

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

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

  • Персональные проверки.
  • Обязательные формальные инспекции всех артефактов (требования, архитектура, проектные модели, тест-планы, код).
  • Автоматизированное модульное тестирование.
  • Различные виды тестирования вручную (интеграционное, системное, релиз, верификация требований, «охота за ошибками»).
  • Автоматизированное функциональное тестирование (для некоторых систем).
  • Обязательные стандарты на все артефакты: планы проектов, требования, дизайн, тест-планы, код.
  • Прототипирование на самых ранних стадиях проектов.
  • Регулярные собрания команд разработчиков с целью анализа причин появления наиболее серьезных дефектов и поиска путей устранения этих причин.

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

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

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

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