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

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.4. Другие методики совместной разработки ПО

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

Анализ проекта или кода

Анализ (walk-through) проекта или кода - популярный тип обзора. Этот термин не имеет точного определения и по крайней мере некоторую часть его популярности можно приписать тому факту, что почти любой тип обзора можно назвать «анализом».

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

за проведение и координацию анализа обычно отвечает автор проекта или кода, подвергающегося обзору;



предметом анализа являются технические вопросы - это рабочее собрание;

все участники готовятся к анализу, изучая проект или код и выискивая в нем ошибки;

анализ позволяет опытным программистам передавать опыт и дух корпоративной культуры молодым программистам; с другой стороны, молодые программисты во время анализа могут предложить новые методологии и подвергнуть сомнению старые и, возможно, уже неэффективные методики;

как правило, анализ длится от 30 до 60 минут;

главная цель анализа - обнаружение ошибок, а не их исправление;

руководители в анализе не участвуют;

идея анализа обладает значительной гибкостью и легко адаптируется к специфическим потребностям организации.

Каких результатов ждать от анализа?

При грамотном и дисциплинированном использовании анализ может принести результаты, похожие на результаты инспекции, т. е. в типичной ситуации он позволяет обнаружить в программе 20-40% ошибок (Myers, 1979; Boehm, 1987b; Yourdon, 1989b; Jones, 1996). Тем не менее обычно анализ значительно менее эффективен, чем инспекция Os, 1996).

При неразумном использовании анализ невыгоден. Нижняя граница эф-фективности анализа - 20% - не заслуживает особого внимания, к тому же по крайней мере в одной организации (Boeing Computer Services) взаимные обзоры кода оказались «очень дорогими». Специалисты Boeing обнаружили, что участников проекта было трудно убедить согласованно применять методики анализа, а при повышенном давлении внешних факторов проведение анализа стало практически невозможным (Glass, 1982).

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

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

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

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



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

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

Чтение кода

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

Исследование, проведенное в Лаборатории проектирования ПО NASA, показало, что при чтении кода разработчики находили около 3,3 дефекта в час, а при тестировании - около 1,8 ошибки в час (Card, 1987). Кроме

того, на всем протяжении проекта чтение кода позволяло найти на 20-60% больше ошибок, чем разные виды тестирования.

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

В начале подготовки к собранию автор кода раздает листинги участникам обзора. Листинги включают от 1000 до 10 ООО строк; типичный объем - 4000 строк.

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

Участники обзора читают код независимо друг от друга. Обычно продуктивность составляет примерно 1000 строк в день.

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

Автор кода исправляет обнаруженные проблемы.

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



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