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

Перекрестная ссылка Ш обзо- Формальные технические обзоры Важный аспект уп-рах и йиспекмш см, тщ 21. равления процессом разработки ПО - исправление проблем

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

ЙврвФвшаяссыяхаОзависй- <Ворота качества» не предполагают, что этапы выработки тш подходов к разработке ПО требований или разработки архитектуры нужно выполнить от ша проекта см. раздея 3.2, на 100%; они позволяют определить, достаточно ли хороши требования или архитектура, чтобы разработчики могли перейти к следующим этапам. В одних случаях «ворота качества» могут требовать определения только самых важных аспектов архитектуры, а в других - определения почти всех деталей. Разумеется, это зависит от природы конкретного проекта.

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

Процесс разработки

{полиитальиые сведения Разра ьш из упомянутых элементов явно связан с контролем ботка ПО как процесс обср<да- качества и неявно - с процессом разработки ПО. Методи-eTCflBKHHfe<<lof$ssJona($oftwai ки разработки, включающие действия, направленные на 08vek)pment» <МсСооле11, ШЩ. контроль качества, способствуют созданию более качественного ПО. Другие процессы, не являющиеся сами по себе аспектами контроля качества, также влияют на качество ПО.

Щттщ ШШ о контро- процедуры контроля изменений Повышению качества яе изменений см, рздел 28.2. часто препятствуют неконтролируемые изменения. Не-

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

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

Оценка результатов Только оценив результаты выполнения плана контроля качества, вы сможете узнать, эффективен ли он. Оценка позволяет не только узнать эффективность плана, но и изменить процесс разработки контролируемым образом с целью его улучшения. Кроме того, вы можете извлечь дополнительную выгоду оценивая сами атрибуты качества: корректность, практичность, эффективность и т. д. Обсуждение оценки атрибутов качества см. в главе 9 книги «Principles of Software Engineering» (Gilb, 1988).

Прототипирование Прототипированием называют разработку реа-JlnL листичных моделей важных функций системы. Так, разработчики могут использовать прототипирование для определения удобства пользовательского интерфейса, времени выполнения важных вычислений или объема памяти, нужного для хранения типичных наборов данных. Анализ 16 опубликованных и 8 неопубликованных исследований конкретных случаев, посвященный сравнению прототипирования с традиционными методиками разработки, основанными на спецификациях, показал, что прототипирование повышает эффективность проектирования, способствует более полному удовлетворению потребностей пользователей и облегчает сопровождение ПО (Gordon and Bieman, 1991).

Задание целей

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

Джеральд Вайнберг и Эдвард Шульман провели один очень интересный эксперимент, посвященный изучению влияния задания целевых аспектов качества на производительность труда программистов (Weinberg and Schulman, 1974). Они попросили пять групп разработчиков написать одну и ту же программу и указали одни и те же пять целевых характеристик качества, но каждой группе было сказано оптимизировать разные характеристики: одной - минимизировать объем используемой программой памяти, второй - обратить максимальное внимание на ясность выводимых данных, третьей - создать как можно более удобочитаемый код, четвертой - сделать программу максимально компактной, а пятой - написать программу за минимальное время. В табл. 20-1 показано, какое место заняла каждая группа по каждому целевому показателю.

Источник: «Goals and Performance in Computer Programming* (Weinberg and Schulman, 1974).

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

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

20.3. Относительная эффективность методик контроля качества ПО

Не все методики контроля качества имеют одинаковую эффективность. Эффективность многих методик в плане нахождения и устранения дефектов уже известна. В данном разделе мы обсудим этот и некоторые другие аспекты «эффективности» методик контроля качества.

Эффективность обнаружения дефектов

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

Еспи бы щшш дозводили щмий так, как программисты пишут программы, первый же щеп у1шт0жйл бы цивилизацию.