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

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

па«.к««о.«.»га..»... то, что одни методики - такие как инспекции - позволя-

тт сшытш исправления определить и симптомы, и причины дефектов за один

Д8ф«шв or срока их присут- этап; другие - например, тестирование - указывают на

mm в еистеи т, раэдвя «Об- симптомы дефекта, но требуют выполнения дополнитель-

ращение к данным» радела $.1 работы для диагностики и устранения его причины. В

Сами ошибки более подробно

Шщттт в ртт ПА одноэтапные методики оказываются гораздо более

дешевыми, чем двухэтапные.

В одном из подразделений Microsoft обнаружили, что при использовании инспекции кода - одноэтапной методики - на нахождение и исправление дефекта уходит 3 часа, тогда как при использовании тестирования - двухэтапной методики - на это требуется 12 часов (Moore, 1992). Кол-лофелло и Вудфилд сообщили, что при разработке программы из 700 ООО строк, над которой работало более 400 программистов, обзоры кода имели гораздо более высокую экономическую эффективность, чем тестирование: прибыль на инвестированный капитал была равной 1,38 и 0,17 соответственно (CoUofello and Woodfield, 1989).

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

формальные инспекции всех требований, всех аспектов архитектуры и всех проектов критических частей системы;

моделирование или прототипирование;

чтение или инспекции кода;

тестирование выполнения программы.

20.4. Когда выполнять контроль качества ПО?

Как было отмечено в главе 3, чем раньше ошибка внедряет-качества аредваритешщ дай- приложение, тем сильнее она переплетается с другими етвий-нш1ример,011редеший частями приложения и тем больше средств придется потра-трабоашй и разработки щт- тить на ее устранение. Дефект в требованиях может вылить-тентда - в этой книге ие рас- я в один или несколько дефектов в проекте, которые могут сматривается. Информамо т привести к появлению множества дефектов в коде. Ошибка шмшмзм можно найти в кни-

ган, штныж в разделе *До- требованиях может привести к разработке дополнительных тпщтшь ресурсы» в кон- компонентов архитектуры или подтолкнуть к неудачным ар-р тт. хитектурным решениям. Дополнительные архитектурные

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

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



ирования скорее всего повлияет только на один метод или класс. Это еще одно убедительное обоснование как можно более раннего нахождения ошибок.

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

20.5. Главный Закон Контроля Качества ПО

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

В основе этого закона лежит одно важное наблюдение: лучшим способом повышения производительности труда программистов и качества ПО является минимизация времени, затрачиваемого на исправление кода, чем бы оно ни объяснялось: изменениями требований, изменениями проекта или отладкой. Средняя для отрасли производительность труда программистов эквивалентна примерно 10-50 строкам кода на одного человека в день (с учетом всех затрат, не связанных с кодированием). Написание 10-50 строк кода требует нескольких минут, - на что же уходит остальное время?

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

тель. Определение требовании, разработка архитектуры и рщщ 27 $

другие действия, не относящиеся к кодированию, также отражены в «строках кода в день». Однако основные временные затраты объясняются не этим.

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

Этот анализ подтверждается реальными данными. В обзоре 50 проектов, потребовавших более 400 человеколет и включивших почти 3 ООО ООО строк кода, проведенном в Лаборатории проектирования ПО NASA, было обнаружено, что повышенное внимание к контролю качества позволяло снизить уровень ошибок, но не повышало общие расходы на разработку (Card, 1987).



В исследовании, проведенном в IBM, были получены аналогичные результаты:

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

Это верно и для противоположного края шкалы. В одном исследовании 1985 года ученые попросили 166 профессиональных программистов написать программы по одной и той же спецификации. Итоговые программы содержали в среднем 220 строк, а на их написание ушло в среднем чуть меньше 5 часов. Результаты оказались поистине удивительными: программисты, работавшие над своими программами средний объем времени, допустили наибольшее число ошибок. Программисты, которым потребовалось больше или меньше времени, допустили значительно меньше ошибок (DeMarco and Lister, 1985). Результаты показаны на рисунке 20-2.

Средний уровень дефектов

1.4 Ч-


500 Более 500

Время написания программы в минутах

Рис, 20-2, Ни при самом быстром, ни при самом медленном подходе к разработке ПО не наблюдается наибольший уровень дефектов

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

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

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



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.0022