программное управление как вид управления качеством выделяется по такому основанию как
Управление качеством программного обеспечения
Технология и методы программирования › Управление качеством программного обеспечения
Управление качеством — процесс, лежащий в основе обеспечения конкурентоспособности производимой продукции. В начале XX века управление качеством заключалось в основном в выполнении мероприятий по контролю качества входного сырья и выходной продукции, однако, в настоящее время это сложный, непрерывный процесс, затрагивающий все этапы производства.
Основными стандартами в области качества являются международные стандарты серии ИСО 9000 [1], ИСО 8402 [2], а также, ГОСТ 15467-79 [3].
Заметка состоит из двух частей:
1 Управление качеством
Согласно ГОСТ 15467-79, управление качеством продукции — действия, осуществляемые при создании и эксплуатации или потреблении продукции в целях установления, обеспечения и поддержания необходимого уровня её качества.
Из определения видно, что управление качеством затрагивает все этапы производства (жизненный цикл) продукции. Комплекс мероприятий по обеспечению качества образует систему управления качеством, при этом, предупреждению возникновения дефектов уделяется большее внимание чем их устранению.
Качество продукции связано с объёмом брака (количеством дефектов) [4, 5]. При этом, дефектом называют любое отклонение от требований, предъявляемых к производимой продукции. Набор требований зависит от типа производимой продукции, в следующем разделе более подробно рассмотрен случай, если продуктом является программное обеспечение.
2 Особенности управления качеством программного обеспечения
Перед началом разработки ПО, к нему должны быть сформулированы требования. Требования фиксируются в техническом задании, согласно ГОСТ Р ИСО/МЭК 9126 [6] к ним относят, например:
Возможно большое количество различных требований, каждое требование может зависеть от множества факторов. Например, удобство сопровождения зависит от наличия документации, соответствия кода определенным соглашениям, архитектуры ПО (например, оно может поддерживать систему модулей, расширяющих функциональность без изменения существующего кода). Нарушение любого требования будет являться дефектом.
Разработка архитектуры ПО должна быть произведена перед началом кодирования. Во время кодирования необходимо постоянно следить за соблюдением соглашений. Документация может разрабатываться как одновременно с кодированием, так и после него. Таким образом, управление качеством ПО производится непрерывно, в течении всего жизненного цикла ПО [7].
2.1 Жизненный цикл программного обеспечения
Согласно ANSI/IEEE Std 610.12-1990 [9], жизненный цикл ПО — период времени, от момента принятия решения о необходимости создания программного продукта до момента его утилизации. Жизненный цикл делится на множество этапов, включая разработку и использование ПО. Выделяют несколько моделей жизненного цикла, в зависимости от того, каким образом он делится на этапы [8].
На рисунке схематично изображены каскадная и итерационная модели жизненного цикла: 
В обоих моделях, разработку разделяют на следующие этапы:
Переход к следующему этапу производится лишь после завершения работ на предыдущем этапе.
При использовании каскадной модели, дефекты накапливаются по мере реализации проекта. Поиск и устранение дефектов выполняется лишь на этапе отладки, при этом может быть использовано тестирование или верификация ПО.
Стоимость устранения дефекта, допущенного при проектировании значительно выше, чем стоимость дефекта этапа кодирования, поэтому проектированию уделяется большое внимание. Итеративная модель жизненного цикла позволяет снизить риски возникновения дефектов ПО на ранних стадиях.
В итеративной модели жизненный цикл делится на итерации, каждая из которых включает все этапы процесса разработки (проектирование — реализация — тестирование — оценка результатов). В результате каждой итерации создаётся работающая модель системы, при этом каждая последующая итерация должна улучшать ПО.
В итеративной модели поиск дефектов осуществляется многократно — он обязательно выполняется на каждой итерации.
2.2 Методы устранения дефектов
В ряде статей [5, 6] подчёркивается важность комплексного подхода к управлению качеством ПО, при этом, под комплексным подходом имеется ввиду необходимость поиска и устранения дефектов, на каждом этапе жизненного цикла ПО.
Рассчитано [6], что если выполнять поиск дефектов на каждом этапе, допустим, последовательной модели жизненного цикла, то к моменту внедрения проекта дефектов будет значительно меньше (если положить эффективность поиска дефектов на каждом этапе равной 50%, то при внедрении будет устранено 80.6% дефектов). Однако, тестирование ПО при последовательном жизненном цикле затруднено, т. к. нет продукта, к которому можно применить тесты, однако комплексный подход к управлению качеством ПО возможен при итеративном жизненном цикле.
Основными методами поиска дефектов являются отладка и тестирование.
Для тестирования ПО необходима разработка тестов. Если ПО имеет модульную архитектуру, то к нему возможно написание и применение юнит-тестов [10], при этом, каждый модуль программы тестируется отдельно. Такой подход позволяет локализовать модуль, в котором заключён дефект.
В настоящее время широко применяется технология покрывающего тестирования (разработка через тестирование, test-driven development, TDD) [11], при этом, наборы тестов разрабатываются до начала непосредственной разработки, а при внесении любого изменения в ПО проверяется его соответствие тестам.
Помимо тестирования может применяться верификация систем. В настоящее время, чаще всего используется верификация моделей (Model checking) [12]. Однако, верификация – очень сложный и дорогостоящий процесс, который могут позволить себе лишь очень крупные компании.
Как отмечало выше, управление качеством программного обеспечения не ограничивается одним лишь тестированием и пронизывает весь жизненный цикл. Так например, при разрабоке используюся различные внутренние соглашения кодирования, соблюдение которых приводит к написанию более единообразного, чистого кода, а значит и повышению качества ПО (упрощается сопровождение кода).
Повысить качество разрабатываемого кода возможно также за счет других методов, таких как неформальный обзор кода (при этом каждый разработчик просматривает результаты работы другого разработчика и указывает на недостатки) или, например парное программирование [13].
Помимо внутренних соглашений, возможно применение и других соглашений, так например, существует принятый стиль оформления комментариев Doxygen [14]. Использование стандарта Doxygen позволяет автоматически строить документацию по исходному коду, а значит, сокращает этап документирования ПО и снижает его стоимость.
На этапе проектирования и разработки документации широко применяется унифицированный язык моделирования (UML) [15]. UML яявляется международным стандартом, поэтому упрощает комуникацию между разработчиками и заказчиками ПО, в следсвтии чего сокращает количество дефектов, допускаемых на этапе проектирования, а также, повышает качество документации.
Значительно сократить количество дефектов, а следовательно, и повысить качество ПО возможно за счет повторного использования кода, стандартных архитектурных решений, эволюционного подхода к разработке ПО. Под эволюционным подходом [16] понимается такой подход к разработке, при котором в уже написанный и отлаженный код не вносятся изменения (а следовательно, не добавляются дефекты), при этом не только поддерживается определенный стиль кодирования, но и необходимо применение специальных архитектурных решений на этапе проектирования.
Под стандартными архитектурными решениями имеются введу шаблоны проектирования (design pattern) [17], т.е. архитектные конструкции, являющиеся решением некоторых часто возникающих проблем. За счет того, что решения являются стандартными и широко известными, упрощается процесс разработки и сопровождения системы.
Методы поиска дефектов имеют различную эффективность и стоимость, так например, неформальный обзор кода является достаточно дешевым методом, при этом его эффективность поиска дефектов составляет 35%, бета-тестирование (при числе пользователей более 1000) является дорогим методом, т.к. Необходимо привлечение пользователей, при этом его эффективность составляет 75% [5].
Управление качеством на производственном предприятии
Перед тем, как начать говорить о качестве на производстве, давайте очертим границы – мы говорим о процессах, связанных с изменением физического состояния объекта, их итоговый результат – готовая продукция, а также о процессах их поддерживающих. Утрируя, можно сказать, что существует несколько уровней готовности процессов производства:
1. Процессы неизвестны – известен только ожидаемый результат.
[Знаю что хочу достичь]
2. Процессы определены – разработана последовательность технологических, логистических и поддерживающих процессов, правильное функционирование которых в заданной последовательности должно привести к ожидаемому результату. Необходимое оборудование и инструменты известны.
[Знаю как хочу достичь]
3. Процессы установлены – уже определённая последовательность процессов развёрнута на производственной площадке, оборудование установлено.
[Имею ресурсы, чтобы достичь]
4. Процессы настроены и протестированы – в режиме пилотного запуска и корректировок стало достоверно известно, что процессы достигают требуемый результат.
[Теоретически могу достичь]
5. Процессы работают – процессы функционируют и в основном приводят к требуемому результату.
[Достигаю, но не без проблем]
6. Процессы управляемы и робастны – известны все характеристики процессов, определённые методы воздействия оказывают ожидаемое влияние, результат процесса повторяем и достоверно известен.
[Регулярно достигаю и управляю результатом]
Несмотря на то, что определение требований по качеству к процессам и объекту начинается на первом этапе, а по факту ещё раньше, само управление качеством на производстве, т.е. непосредственно там, где изменяется объект производства, начинается на третьем уровне, когда технология уже определена и необходимо обеспечить уверенность в достижении каждого следующего состояния и переход на новый, и по сути никогда не заканчивается. Глубина и сложность этого этапа зависит от того запускается ли новая производственная площадка или цех, или процессы будут развёрнуты на уже существующей площадке и оборудовании.
Однако, нет смысла уходить вглубь ни одного из этих этапов до уровня оцениваемых показателей поскольку управление качеством – это в первую очередь одна их стратегических задач и начинать надо сверху.
Сверху вниз
Говоря о качестве в производстве, мы подразумеваем, что результат процессов приводит не только к достижению требуемого состояния готовой продукции, но и к достижению необходимых экономических показателей предприятия. Иными словами, качество — это баланс между хочу и умею или планирую уметь, т.к. чем более мелкие и неочевидные проблемы мы пытаемся разрешить, тем дороже они нам обходятся.
Например, если стратегической целью является занять лидирующее место по производству двигателей независимо от критериев – нам важен рынок. Тогда в политике по качеству мы определяем задачи нашего развития, выбрав их, допустим, на основании SWOT анализа и, скорее всего, мы захотим собирать надёжные, тихие, мощные двигатели с малым расходом топлива, что и отразим в политике под словами об отношении организации к потребителям и рынку, а переведём в цели по качеству, как количество собранных изделий с первого раза без ошибок, стоимость продукта, стоимость брака, количество улучшений и тому подобное. После чего определим метрики.
Снизу вверх
Так, одними из метрик, на основании которых будем судить о собранном с первого раза правильно двигателе, соответствующим заявленным и ожидаемым требованиям, будет измерение отклонений от установленных допусков, поскольку в данном случае эти характеристики являются важным критерием, влияющим на результат. Соответственно параллельно возникнет необходимости обеспечения точности измерительных приборов и метриками процесса обеспечения точности, станут результаты их калибровок, поверок, регулярность контроля измерительных приборов и их обслуживания.
Тоже самое коснётся и самого машиностроительного оборудования. Получается, спускаясь от стратегии, к целям, до уровня метрик операций, поднимаемся к целям для процессов, обеспечивающих поддержку основного производственного процесса, как части стратегии, при минимальных затратах на них.
Изменить привычки
Можно предположить, что, основываясь на метриках процессов, для обеспечения достижения целей по качеству необходимо вводить сплошной контроль этих метрик, но это предположение неверно. Во-первых, необходимо понимать, что контроль – это издержки, которые ценность, как продукт, не создают, а только позволяют убедиться, что она есть в требуемой мере. Во-вторых, зрелый процесс включает в себя операции, обеспечивающие качество, как результат, т.е. не позволяющие процессу отклониться, а значит сама по себе потребность сплошного контроля отпадает. В-третьих, само по себе массовое наличие операций сплошного контроля говорит о том, что мы не уверены в своих процессах – пятый уровень готовности. Это не говорит о том, что контролировать не надо, особенно, если это критичные операции, контроль которых связан с обеспечением безопасности пользователей и сотрудников, но для некритичных операций он должен быть минимальным, лучше всего встроенным в процесс производства как статистический контроль характеристик оборудования, чтобы не допустить отклонение течения процесса от заданных характеристик, или как защита от непреднамеренных ошибок, когда возможность выполнить операцию отличным способом от установленного отсутствует.
Задачи управления качеством
В этом ключе, задачей управления качеством становится не контроль процессов и их результатов сам по себе, а обеспечение непрерывного стабильного ходя процессов, гарантирующих достижение требуемого результата с соблюдением конструкторских требований, требований клиентов и бизнеса, а значит возможность оперативного принятия решений и немедленного реагирования в случае необходимости. В идеальной системе управление качеством встроено во все процессы, включая процессы поддержки производства, а владельцы этих процессов понимают их важность и отслеживают требуемые показатели, отделу качества остаются только номинальные функции, связанные с документацией и роль арбитра. В неидеальной системе отдел качества функционирует как предписывающий и надзорно-карательный орган, постфактум реагирующий на случившиеся проблемы.
Для перехода к идеальной системе требуется наличие определённых процессов производства и поддержки производства – операций, из которых они состоят, их входов и выходов (результатов), показателей и требуемых метрик характеристик процессов и продукции, оценивая которые будут приниматься управленческие решения. Непрерывное течение процесса требует при этом сведения к минимуму вмешательства в него, т.е. отсутствие дополнительных операций, когда требуется прерваться от исполнения основной операции на какой-то промежуток времени для реакции на найденные отклонения, настройки оборудования или любой другой активности. При этом надо понимать, что процессы функционируют во времени и необходимо хранить исторические данные о ходе процесса с одной стороны на уровне метрик, чтобы на основании предиктивных или прескриптивных моделей заранее корректировать процесс, с другой стороны на уровне результатов процесса и трекинга связанных выпущенных изделий или заготовок, чтобы иметь данные для прослеживаемости и реакции в случае необходимости.
Методы управления качеством
Достаточность мер управления качеством при этом зависит от масштаба производственного предприятия, объёма выпуска и вариативности выпускаемых изделий. В то время, как для небольших производств с однотипной продукцией и невысокими объёмами может быть достаточно ручного управления и отслеживания, для производства сложных изделий как с высоким, так и с низким темпом производства, этого будет не хватать поскольку, к примеру, листы контроля, карты хода процесса, инструкции должны будут постоянно кем-то меняться, а значит быть где-то в наличии и кто-то должен обеспечивать их физическую доступность, а затем собирать и заносить нужные данные в информационные системы для последующего анализа.
В этом случае цифровизация процессов управления качеством является необходимостью, поскольку позволяет видеть ход всех нужных нам процессов, а мы говорим о множестве процессов, обеспечивающих результативность производства – от наличия нужного материала в точке использования, наличия паллет для заготовок, требуемых этикетках, до процессов обслуживания оборудования и снятия их характеристик по вибрации, температуре, скорости и т.п. Наличие на экранах информационных киосков или гаджетов требуемой информации в нужном месте в нужный момент позволяет снять с операторов нагрузку и переложить часть операций не создающих ценность для конечного клиента на автоматизированные системы управления производством, дав возможность сосредоточиться на выполняемой работе.
Эти же возможности, используемые на складах, в отделах технического облуживания, отделах метрологии и лабораториях аналогичным образом позволяют управлять этими поддерживающими процессами, обеспечивая непрерывное течение основного.
Выводы
Необходимо понять, что управление качеством – это не процессы, приписанные отделу качества и тем более не контроль, а совокупность мероприятий для достижения стратегических целей компании, выстроенных через поставленные задачи и установленные показатели эффективности всем отделам производственного предприятия и сотрудникам.
Чем сложнее изделие и процесс его производства, чем масштабнее бизнес, тем больше метрик и показателей требуется учитывать единовременно и оперативно, для управления не по факту, а здесь и сейчас, тем вероятнее требуется цифровизация производства, как инструмент управления качеством, для того, чтобы регулярно достигать заданных целей и управлять результатом.
Предлагаем вам познакомиться с вебинарами, освещающими вопросы управления качеством, планирования производства
Принципы управления качеством программ
Тема качества программного обеспечения сегодня весьма популярна, однако на фоне разнообразного толкования качества трудно получить целостное представление о проблеме и основных принципах управления качеством. Возможно, предлагаемый в статье обзор методов повышения качества и подход анализа качества поможет по-иному взглянуть на эту задачу.
Согласно ГОСТ Р ИСО 9000-2001, качество— это «степень соответствия присущих характеристик продукта требованиям», что для области разработки программного обеспечения может быть истолковано не совсем верно. Разработка требований применительно к ПО есть неотъемлемая часть самого процесса разработки программ. Качество требований к программному продукту напрямую влияет на качество самого этого продукта. Иными словами, если требования к программному продукту некачественны, то сам продукт, разработанный по этим требованиям, также будет некачественным даже в случае идеального соответствия. Если слово «требования» в определении ГОСТа заменить на «цели проекта», то все встает на свои места.
Итак, качество программного продукта— это степень соответствия функциональных, технических, эксплуатационных характеристик разработанного программного продукта целям, которые были поставлены перед началом разработки этого продукта. Его качество— некая функция от многих переменных, в том числе следующих:
Другие критерии можно найти, например, в [1]. Компания-разработчик определяет свои стандарты качества для каждого критерия и для каждого программного проекта. При оценке качества необходимо иметь возможность количественно оценить каждый из критериев. В таблице приведена зависимость конкретного вида деятельности и критериев качества.
На качество конечного продукта влияют все фазы и виды деятельности проекта, и от того, насколько хорошо и качественно мы работаем на каждой фазе проекта (а не только, например, на фазе тестирования), зависит, насколько качественным получится разрабатываемый продукт. Другими словами, качество процесса разработки определяет качество продукта [1, 2].
Для анализа качества введем обобщенный критерий— дефект, определяющий любое отклонение от установленных для проекта стандартов качества. Например, недостаток функциональности или лишняя функциональность— дефект; неудобный интерфейс— дефект; плохой дизайн или грязный код, который негативно скажется на сопровождаемости,— дефект; неприемлемая производительность— дефект; некорректная работа программы— частный случай дефекта; орфографическая ошибка в документации— дефект.
Дефекты можно классифицировать по следующим параметрам:
Имея подобный обобщенный показатель, становится проще оценивать и анализировать качество разрабатываемого программного продукта, а также качество самого процесса разработки. Можно считать количество дефектов или сумму их весов (по какому-либо параметру), можно оценивать плотность дефектов на единицу объема продукта, анализировать, какие фазы процесса являются наиболее проблемными для нас и т.д., сведя борьбу за качество к борьбе с дефектами.
Управление качеством программного продукта
Можно нарисовать график изменения количества дефектов в проекте с течением времени. На рис. 1 приведен график для случая водопадной модели жизненного цикла проекта и традиционного подхода к качеству программного продукта, где основной упор делается на тщательное тестирование.
Верхняя линия (рис. 1)— примерное количество внесенных дефектов на текущий момент времени, а нижняя— количество найденных и исправленных дефектов на текущий момент времени (предполагается, что дефекты исправляются практически сразу после обнаружения). Разница между линиями в каждый момент времени отображает количество имеющихся на данный момент дефектов. Чем меньше будет эта разница в конце проекта, тем качественнее продукт.
Эффективность поиска дефектов
Рассмотрим, например, фазу системного тестирования, в ходе которой обнаруживается некое количество дефектов Dfound, но сколько-то дефектов остается ненайденным на момент завершения фазы Dmissed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно Dfound + Dmissed.
Отношение найденных дефектов к их общему числу, выраженное в процентах, назовем эффективностью поиска дефектов [2]— это одна из основных характеристик качества процесса разработки, которую необходимо постоянно контролировать. Для каждой фазы, в ходе которой находятся и исправляются дефекты, при стабильном и предсказуемом процессе и прочих равных условиях эту величину можно считать приблизительно постоянной, что позволяет количественно оценивать уровень качества (выраженный в количестве ненайденных дефектов) для текущего и для планируемых проектов.
Эффективность поиска дефектов можно рассматривать как для отдельных фаз, так и для всего жизненного цикла разработки. При этом эффективности отдельных фаз определяют эффективность для всего жизненного цикла. Каждую фазу поиска дефектов можно рассматривать как своего рода фильтр, который удерживает некую часть дефектов, а весь жизненный цикл— как систему фильтров [2]. Если на ранних этапах жизненного цикла стоят плохие фильтры, которые пропускают много дефектов, то эти дефекты накапливаются, и, чтобы их хорошо отфильтровать, в конце жизненного цикла (фаза тестирования) будет необходим очень хороший фильтр.
Дефекты со временем имеют тенденцию не только накапливаться, если не предпринимать ранних мер по их устранению, но и увеличивать стоимость их исправления, причем часто эта зависимость— экспоненциальная. Для водопадной модели жизненного цикла эта зависимость хорошо иллюстрируется графиком из рис. 3. Для итерационной модели жизненного цикла картина будет похожая, изменятся только надписи: вместо названий фаз будут номера итераций.
Комплексный подход к управлению качеством
Полагаясь только на одно, даже и очень тщательное, тестирование, проблему качества не решить. Если не предпринимать никаких мер по борьбе с дефектами вплоть до этапа тестирования, то к началу тестирования в проекте может накопиться слишком много дефектов, поэтому дефекты надо искать и исправлять постоянно, на протяжении всего жизненного цикла проекта. Кроме того, надо принять все меры по предотвращению или недопущению дефектов.
Применение методов поиска дефектов на протяжении всего жизненного цикла проекта поднимает кривую найденных дефектов вверх, а применение методов предотвращения дефектов опускает кривую вносимых дефектов вниз (рис. 4). Таким образом, количество ненайденных дефектов на протяжении всего жизненного цикла уменьшается, и как результат уменьшается количество ненайденных дефектов в конце проекта.
Методы поиска и предотвращения дефектов
Известно немало методов поиска дефектов.
Эффективная стратегия поиска дефектов состоит в применении комбинации нескольких методов, каждый из которых будет иметь свой собственный уровень эффективности, выраженный в процентах. Согласно данным [1], тестирование имеет сравнительно низкую эффективность поиска дефектов (30-40%), а для того, чтобы сделать ее высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестировщиков более 1000 составляет около 75%).
Вряд ли возможно разрабатывать ПО вообще без дефектов, но попытаться уменьшить число вносимых дефектов стоит попробовать. Перечислим наиболее известные методы предотвращения дефектов.
Стоит также упомянуть человеческий фактор— никакие методы не заменят профессионализм и опыт разработчиков и менеджеров. Опытные профессионалы, как правило, делают меньше ошибок, что дает хороший задел для качественной разработки.
Итерационный жизненный цикл
Рассмотрим итерационный жизненный цикл, состоящий из пяти итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 5).
Предположим, эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций? После первой итерации эффективность будет равна 50%; после второй— 62,5%; после третьей— 70,8%; после четвертой— 76,6%; после пятой эффективность поиска дефектов всех пяти итераций будет равна 80,6%.
В реальной жизни эффективности поиска дефектов на разных итерациях, скорее всего, будут отличаться, что связано с неоднородностью деятельностей на разных итерациях, но в любом случае налицо явный прогресс в качестве перед простым водопадным жизненным циклом. На каждой последующей итерации находятся дефекты не только текущей итерации, но и оставшиеся дефекты предыдущих итераций. В результате общая эффективность поиска дефектов увеличивается.
Таким образом, получается, что добиться улучшения качества можно не только введением дополнительных методов раннего поиска дефектов (таких, как инспекции, обзоры и т.п.), но также и путем перехода от водопадного к итерационному жизненному циклу разработки ПО.
Цена качества
Может показаться, что применение множества различных методов повышения качества ПО увеличит стоимость разработки, однако это верно лишь в краткосрочной перспективе (пока процесс их использования не стабилизировался) либо при неграмотном использовании методов. В долгосрочной же перспективе комплексное применение методов повышения качества не только не удорожает разработку, но может удешевить ее.
Во-первых, чем раньше был найден дефект, тем дешевле обходится его исправление. Поэтому эффективное применение методов раннего поиска дефектов способствует снижению стоимости проекта.
Во-вторых, методы поиска дефектов помимо эффективности характеризуются также средней скоростью нахождения дефектов. Согласно статистическим данным, например из [1], этот показатель у методов тестирования в несколько раз хуже, чем у методов раннего поиска дефектов. Это означает, что, тратя время на поиск дефектов на ранних фазах, мы экономим больше времени на предстоящем тестировании.
Процесс управления качеством
Для управления качеством недостаточно простого использования различных методов его повышения— необходимо их осознанное систематическое применение, которое стало бы неотъемлемой частью процесса разработки ПО, ориентированного на качество. Необходим постоянный контроль качества разрабатываемого ПО через метрики качества (плотность дефектов, размер переделок, среднее время между отказами и др.), а также контроль качества отдельных подпроцессов, составляющих целостный процесс разработки.
Методы, которые хорошо работали вчера, сегодня могут представлять собой пустую трату времени. У каждого проекта может быть своя специфика, требующая иного набора методов повышения качества. Например, одни проекты (особо критичные) могут потребовать тщательнейшего тестирования всех тест-кейсов, в других (когда тестирование очень трудоемко) больше внимания следует уделять инспекциям, третьи (инновационные) потребуют предварительного прототипирования, четвертые (критичные к ресурсам) потребуют стресс-тестирования и т.д.. Если постоянно не контролировать эффективность методов, то со временем она может значительно снизиться.