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

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

Какие классы содержат наибольшее число ошибок?

Естественно предположить, что дефекты распределяются по коду равномерно. Если код содержит в среднем 10 дефектов на 1000 строк, вы могли бы ожидать, что класс из 100 строк будет иметь один дефект. Это естественное предположение, но оно ошибочно.

Кейперс Джонс сообщает, что в результате принятой в IBM программы повышения качества 31 из 425 классов системы IMS получил статус «подверженный ошибкам». Эти классы были исправлены или полностью разработаны заново, благодаря чему менее чем через год частота обнаружения дефектов в IMS клиентами снизилась в 10 раз. Общие расходы на сопровождение системы снизились примерно на 45%. Мнения клиентов о качестве системы изменились с «неприемлемо» на «хорошо» GoJcs, 2000).

Большинство ошибок обычно концентрируется в нескольких особенно дефектных методах. Типичные отношения между ошибками и кодом таковы:

80% ошибок содержится в 20% классов или методов проекта (Endres, щ 1975; Gremillion, 1984; Boehm, 1987b; Shull et al., 2002);

50% ошибок содержится в 5% классов проекта Qorics, 2000).

Эти отношения могут казаться не такими уж и важными, пока вы не узнаете несколько следствий. Во-первых, 20% методов проекта обусловливают 80% затрат на разработку (Boehm, 1987b). Это не значит, что 20% самых дорогих методов являются одновременно и самыми дефектными, но такое совпадение настораживает.

Во-вторых, какой бы ни была точная доля расходов, приходящихся на jlllji разработку дефектных методов, эти методы очень дороги. В классическом исследовании, проведенном в 19б0-х, специалисты IBM проанализировали операционную систему OS/360 и обнаружили, что ошибки не были распределены равномерно между всеми методами, а были сконцентрированы в нескольких методах. Был сделан вывод, что эти методы - «самые дорогие сущности в программировании» (Jones, 1986а). Они содержали целых 50 дефектов на 1000 строк кода, а их исправление часто оказывалось в 10 раз дороже разработки всей системы (затраты включали поддержку пользователей и сопровождение системы на месте).

Пщцтпи etumu Другим "Третьих, дорогие методы оказывают очевидное влияние типом методов, часто содержа- процесс разработки. Как гласит старая пословица, «вре-щих много ошибок, являются мя - деньги». Справедливо и обратное: «деньги - время», слишком сложные методы. Об и, если вы можете исключить почти 80% затрат, избежав идентификации таких методов проблемных методов, вы можете сэкономить и много вре-» их упрощении см, подраздел наглядно иллюстрирует Главный Закон Контро-«Общие принципы уменьшения /

сложности» раздела 19.6 Качества ПО: повышение качества сокращает сроки и

снижает общую стоимость разработки системы.

В-четвертых, проблемные методы оказывают не менее очевидное влияние на сопровождение программы. При сопровождении программистам приходится сосредоточиваться на идентификации методов, подверженных ошибкам, их перепроектировании и переписывании с нуля. В вышеупомянутом проекте IMS после замены дефектных классов производительность труда при разработке новых версий IMS повысилась примерно на 15% Qoncs, 2000).



Классификация ошибок

Некоторые ученые попытались классифицировать ошибки jipjipemwi tmmift Список по типу и определить распространенность ошибок каждо- всех контрольных ШС18» при-го типа. У каждого программиста есть свой список наибо- аедеи пошсодержшшшги. лее неприятных ошибок: ошибки занижения или завышения на 1, невыполнение повторной инициализации переменной цикла и т. д. В контрольных списках я указал и многие другие типы ошибок.

Борис Бейзер объединил данные нескольких исследований и пришел к исключительно подробной классификации ошибок по распространенности (Beizer, 1990). Вот резюме его результатов:

25,18% Структурные ошибки 22,44% Ошибки в данных

16,19% Ошибки в реализации функциональности

9,88% Ошибки конструирования

8,98% Ошибки интеграции

8,12% Ошибки в функциональных требованиях

2,76% Ошибки в определении или выполнении тестов

1,74% Системные ошибки, ошибки в архитектуре ПО

4,71% Другие ошибки

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

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

Большинство ошибок имеет довольно ограниченную область видимости Одно исследование показало, что в 85% случаев исправление ошибки требовало изменения только одного метода (Endres, 1975).

Многие ошибки не связаны с конструированием Опрос 97 разработчиков позволил выяснить, что тремя наиболее частыми причинами ошибок были плохое знание прикладной области, изменения или конфликты требований, а также неэффективность общения и плохая координация действий разработчиков (Curtis, Krasner, and Iscoe, 1988).

Как правило, ошибки конструирования лежат на со- «„

ССЛл вы 9ИДпТе следы КуиЫТ,

вести программистов В двух давнишних исследовани- даайте о лошадях, а не о зеб-

ях было установлено, что из всех ошибок 95% были допу- pax. Скорее всего ОС работает

щены программистами, причиной 2% было системное ПО тршшьша. € азой данных

(компилятор и ОС), еще 2% - другое ПО, а оставшегося 1% нааерйое, ее» в порядке.

- оборудование (Brown and Sampson, 1973; Ostrand and Эт Уш »Tame

Weyuker, 1984). Системное ПО и инструменты разработки ис- "" пользуются сегодня гораздо шире, чем в 1970-х и 1980-х,



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

На удивление распространенной причиной проблем являются опечатки В одном исследовании было обнаружено, что 36% всех ошибок конструирования были опечатками (Weiss, 1975). Исследование почти 3 ООО ООО строк приложения для расчета динамики полета, проведенное в 1987 г, показало, что опечатками были 18% всех ошибок (Card, 1987). В другом исследовании было установлено, что 4% всех ошибок были орфографическими ошибками в сообщениях (Endres, 1975). В одной из моих программ коллега обнаружил ряд орфографических ошибок, просто проанализировав все строки исполняемого файла утилитой проверки орфографии. Внимание к деталям на самом деле важно. Если вы сомневаетесь в этом, учтите, что три самых дорогостоящих ошибки всех времен, приведших к убыткам объемом 1,6 миллиарда, 900 миллионов и 245 миллионов долларов, были вызваны изменением одного символа в ранее корректных программах (Weinberg, 1983).

Дов€хльно часто причиной ошибок является неправильное понгшание проекта Компилятивное исследование Бейзера показало, что 16% ошибок было обусловлено неправильной интерпретацией проекта (Beizer, 1990). В другом исследовании было обнаружено, что неправильным пониманием проекта объяснялось 19% ошибок (Weiss, 1975). Посвящайте анализу проекта столько времени, сколько нужно. Это не обеспечивает немедленную выгоду (кому-то даже может показаться, что вы не работаете!), но в итоге окупается с избытком.

Большинство ошибок легко исправить Примерно в 85% случаев на исправление ошибки требуется менее нескольких часов. Где-то в 15% случаев - от нескольких часов до нескольких дней. И только около 1% ошибок требует большего времени (Weiss, 1975; Ostrand and Weyuker, 1984; Grady, 1992). Это подтверждает и Барри Бом, заметивший, что на исправление около 20% ошибок уходит около 80% ресурсов (Boehm, 1987b). Изо всех сил старайтесь избегать трудных ошибок, выполняя предварительные обзоры требований и проектов. Исправляйте многочисленные мелкие ошибки так эффективно, как только можете.

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

Доля ошибок, обусловленных неграмотным конструированием

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



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