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

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

Каких результатов можно ожидать от инспекций?

Отдельные инспекции обычно приводят к обнаружению около 60% дефектов, что превышает эффективность других методик за исключением прототипирования и крупномасштабного бета-тестирования. Эти результаты многократно подтверждены в таких организациях, как Harris BCSD, National Software Quality Experiment, Software Engineering Institute, Hewlett Packard и многих других (Shull et al., 2002).

Комбинация инспекций проекта и кода обычно позволяет устранить из продукта 70-85 или более процентов дефектов (Jones, 1996). Инспекции способствуют раннему определению подверженных ошибкам классов, и Кейперс Джонс сообщает, что при использовании инспекций число дефектов в расчете на 1000 строк кода оказывается на 20-30% более низким, чем при использовании менее формальных методик обзора. Участвуя в инспекциях, разработчики, занимающиеся проектированием и кодированием, учатся улучшать свою работу и достигают повышения производительности труда примерно на 20% (Pagan, 1976; Humphrey, 1989; Gilb and Graham, 1993; Wiegers, 2002). Инспекции проектов и кода системы требуют около 10-15% бюджета проекта и обычно снижают общую сумму расходов на реализацию системы.

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

Роли участников инспекции

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

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

Автор Автор проекта или кода играет во время инспекции относительно небольшую роль. Одной из целей инспекции как раз и является гарантия того, что проект или код говорит сам за себя. Если проект или код, подвергающийся инспекции, кажется не)1сным, автору поручают его улучшить. Иначе автор должен объяснить не совсем ясные части проекта или кода и, если нужно, рассказать, почему аспекты, которые кажутся ошибочными, на самом деле такими не являются. Если инспекторы плохо знакомы с конкретной частью системы, автор может предоставить им полезную информацию при подготовке к инспекционному собранию.



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

Секретарь Во время инспекционного собрания секретарь регистрирует обнаруженные ошибки и запланированные действия. Ни автор, ни координатор не должны играть роль секретаря.

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

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

В инспекции должны участвовать не менее трех человек, потому что роли координатора, автора и инспектора объединять не следует. В то же время к инспекции не следует привлекать более шести человек, потому что группой большего размера слишком трудно управлять. Ученые обнаружили, что наличие более двух-трех инспекторов обычно не повышает эффективность обнаружения дефектов (Bush and Kelly, 1989; Porter and Votta, 1997). Однако это лишь обобщенные данные: по-видимому, оптимальная методика проведения инспекции зависит от типа инспектируемого материала (Wiegers, 2002). Проанализируйте свой опыт и приспособьте эти рекомендации к своей ситуации.

Общая процедура инспекции

Инспекция включает несколько отдельных этапов.

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

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



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

ПершфШИ)»! йшпи Перечень Подготовка Каждый инспектор сам ищет в проекте или контрольных списков, nowora- коде ошибки, руководствуясь при этом полученным конт-ющт повысить качестао кода, рольным списком.

приаадан посла содержания Выполняя обзор прикладного кода, написанного на высо-книги.

коуровневом языке, инспектор может проанализировать за час около 500 строк. При обзоре системного кода, также написанного на высокоуровневом языке, производительность труда инспектора составляет лишь около 125 строк в час (Humphrey, 1989). Наиболее эффективный темп подготовки может колебаться в широком диапазоне, поэтому храните данные о быстроте подготовки к инспекциям в вашей организации - это поможет вам лучше готовиться к будущим инспекциям.

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

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

Инспекционное собрание Координатор поручает одному из участников (не автору) начать изложение проекта или чтение кода (Wiegers, 2003) с объяснением всей логики, в том числе всех ветвей каждой логической структуры. Во время этой презентации секретарь записывает обнаруженные ошибки, но как только участники приходят к выводу, что они нашли ошибку, ее обсуждение прекращается. Секретарь регистрирует тип и серьезность ошибки, и инспекция продолжается. Если инспекция теряет фокус, координатору следует привлечь внимание группы и вернуть обсуждение в нужное русло.

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



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