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

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

Изучив результаты 13 обзоров, специалисты AT&T обнаружили, что важность собраний, посвященных обзору, была относительно невысокой: 90% дефектов разработчики находили при подготовке к собраниям и только около 10% во время самих собраний (Votta, 1991; Glass, 1999).

Презентация

Презентацией (dog-and-pony show) называют обзор, при котором система демонстрируется заказчику. Такие обзоры - обычное дело при разработке ПО для правительственных организаций, которые часто требуют выполнения обзоров требований, проектов и кода. Цель презентации - показать заказчику, что работа продвигается успешно, так что это обзор, выполняемый руководителями, а не технический обзор.

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

21.5. Сравнение методик совместного конструирования

Каковы различия между разными методиками совместного конструирования? Основные характеристики каждой методики указаны в табл. 21-1.

Табл. 21 -1. Сравнение методик совместного конструирования

Характеристика

Парное

программирование

Формальная инспекция

Неформальный обзор (анализ)

Назначаются ли участникам Да конкретные роли?

Проводится ли формальное Возможно обучение исполнению конкретных ролей?

Кто «управляет» сотрудничеством?

Фокус сотрудничества

Разработчик, сидящий за клавиатурой

Проектирование, кодирование, тестирование и исправление дефектов

Действия фокусируются Да неформально, если вообще фокусируются

Координатор Обычно автор

Сфокусирован ли обзор? Направляются ли усилия на поиск наиболее частых типов ошибок?

Выполняется ли контроль Да исправления найденных ошибок?

Предоставляется ли отдель- Это второстепенный ным программистам подроб- фактор пая обратная связь для сокращения числа ошибок в будущем?

Только обнаруже- Разный ние дефектов

Это второстепенный фактор

(ш. след. стр.)



Табл. 21 -1. (окончание)

Парное Формальная Неформальный Характеристика программирование инспекция обзор (анализ)

Используется ли анализ Нет Да Нет

результатов для повышения эффективности процесса?

Полезна ли методика Возможно Да Да

не на этапе конструирования?

Типичный процент 40-60% 45-70% 20-40%

обнаруживаемых

дефектов

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

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

Дополнительные ресурсы

Ниже я указал ряд работ, посвященных методикам совмес-http: cc2axom/ai06 ного конструирования.

Парное программирование

Williams, Laurie and Robert Kessler. Pair Programming Illuminated. Boston, MA: Addison Wesley 2002. В этой книге подробно рассматриваются все аспекты парного программирования, в том числе соответствие личностей (например, эксперт и новичок, интроверт и экстраверт) и другие вопросы реализации.

Веек, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison Wesley, 2000. Кент Бек вкратце рассматривает парное программирование и показывает, как его улучшить, дополнив другими методиками, такими как определение стандартов кодирования, частая интеграция и регрессивное тестирование.

Reifer, Donald. «How to Get the Most Out of Extreme Programming/Agile Methods», Proceedings, XP/Agile Universe 2002. New York, NY: Springer; pp. 185-196. В этой статье обобщен опыт использования экстремального программирования и методик гибкой разработки, а также указаны условия успешности парного программирования.



Инспекции

Wiegers, Karl. Peer Reviews in Software: A Practical Guide. Boston, MA: Addison Wesley, 2002. В этой книге подробно рассматриваются разные виды обзоров, в том числе формальные инспекции и менее формальные методики. Она основана на тщательных исследованиях, имеет практическую направленность и легко читается.

Gilb, Tom and Dorothy Graham. Software Inspection. Wokingham, England: Addison-Wesley, 1993. В этой книге подробно обсуждаются инспекции, выполнявшиеся в начале 1990-х. Она имеет практическую направленность и включает исследования конкретных инспекционных программ, проводившихся в нескольких организациях.

Pagan, Michael Е. «Design and Code Inspections to Reduce Errors in Program Development»./БМ ysms/owma/, 15, no. 3 (1976): 182-211.

Pagan, Michael E. «Advances in Software Inspections». IEEE Transactions on Software Engineering, SE-12, no. 7 (July 1986): 744-51. Две этих статьи написаны разработчиком методики инспекций. В них вы найдете суть того, что нужно знать для проведения инспекций, в том числе описание всех стандартных форм инспекций.

Соответствующие стандарты

IEEE Std 1028-1997 - стандарт обзоров ПО.

IEEE Std 730-2002 - стандарт планирования контроля качества ПО.

Ключевые моменты

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

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

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

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

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

Анализ и чтение кода - альтернативы инспекциям. Чтение кода позволяет каждому участнику более эффективно использовать свое время.



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