Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 [152] 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

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

Перекрестная ссылка Ш обзо- Формальные технические обзоры Важный аспект уп-рах и йиспекмш см, тщ 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 показано, какое место заняла каждая группа по каждому целевому показателю.



Табл. 20-1. Места, занятые каждой группой по каждому целевому показателю

Целевая характеристика

качества, на которую

Читабель-

группа должна была

Минималь-

ность выво- Читабель-

Минималь-

обратить максимальное

ный объем

димых

ность

Компакт-

ное время

внилланио

памяти

данных

кода

ность кода

разработки

Минимальный объем

памяти

Читабельность

выводимых данных

Читабельность кода

Компактность кода

Минимальное время

разработки

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

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

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

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

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

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

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

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



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 [152] 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0099