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

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

проектирование и спецификация интерфейса;

архитектура;

интеграция;

удаление дефектов;

системное тестирование;

документирование.

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

Программы, продукты, системы и системные продукты

Не только количество строк кода и размер команды влия-

. Д(тш!нш111»нь1е1»ейеш Другое

ют на размер проекта. Более тонкое воздействие оказыва- объяснение зтой точки зрения см. ют качество и сложность окончательной версии программ- а шаве 1 книги «ТИе Mythical Манного продукта. Для создания и отладки первой версии Giga- Month» (Brooks, 1995). tron мог потребоваться всего месяц. Это была отдельная

программа, написанная, протестированная и задокументированная одним человеком. Если Gigatron длиной 2500 строк занял один месяц, то почему окончательный вариант Gigatron, длиной 25 ООО строк потребовал 20 месяцев?

Простейший вид ПО - это отдельная «программа», используемая человеком, ее написавшим, или несколькими другими.

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

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

Создание «системного продукта» предполагает наведение глянца, прису-щего продукту, и наличие нескольких частей системы. Системный продукт примерно в девять раз дороже простой программы (Brooks, 1995, Shull et al., 2002).

Неучитываемые различия в сложности и глянце между программами, продуктами, системами и системными продуктами и являются частой причиной ошибок в оценках. Программисты, использующие свой опыт в написании программ для составления плана создания программного продукта, могут ошибиться в меньшую сторону примерно в 10 раз. Рассматривая следующий пример, обратитесь к графику на рис. 27-3. Если вы воспользуетесь своим опытом в написании 2К строк



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

При увеличении проекта конструирование требует все меньшей доли общих затрат. Если вы основываете свои расчеты только на опыте конструирования, оценочная ошибка растет. Если вы использовали свой опыт написания 2К строк для оценки времени, необходимого для разработки программы длиной 32К, ваша оценка будет включать только 50% от необходимого времени; весь процесс разработки может занять на 100% больше времени, чем вы предполагали.

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

Методология и размер

Методология используется в проектах любых размеров. В маленьких проектах методология скорее случайна и инстинктивна - в больших она скрупулезна и тщательно спланирована.

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

Формальный подход не всегда доставляет удовольствие, а если он применяется неправильно, накладные расходы могут поглотить получаемые от него преимущества. Однако возрастающая сложность больших проектов требует более осознанного отношения к методологии. Строить небоскреб и собачью будку нужно по-разному. То же относится и к программным проектам разных размеров. В больших проектах случайный выбор методологии не соответствует задаче. Успешные проектировщики выбирают стратегии для больших проектов осознанно.

В светском обществе чем формальней событие, тем более неудобную одежду нужно надевать (высокие каблуки, галстуки и т. д.). В разработке ПО чем формальней проект, тем больше бумажных документов необходимо создать, чтобы убедиться, что вы выполнили ваше домашнее задание. Кейперс Джонс указывает, что в проекте длиной в 1000 строк примерно 7% затрат приходится на бумажную работу, тогда как в проекте в 100 ООО строк затраты на бумажную работу увеличиваются в среднем до 26% Qos, 1998).

Эта работа проводится не из чистой любви к писанине. Она является прямым результатом интересного феномена: чем больше человек вам приходится координировать, тем больше требуется документов (рис. 27-1).



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

«Больше» не значит лучше, во всяком случае в том, что касается методологии. В своем сравнении быстрых и четко спланированных вариантов методологии Барри Бом и Ричард Тернер предупреждают, что обычно лучше сначала создать небольшие методы, а затем промасштабировать их для большого проекта, чем начать с создания универсального метода, а затем урезать его для маленького проекта (Boehm and Turner, 2004). Некоторые ученые мужи в области ПО говорят о «легковесной» и «тяжеловесной» методологии, но на практике главное - это учесть конкретный размер и тип вашего проекта, а затем найти «правильновесную» методологию.

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

Для дальнейшего изучения темы данной главы ознакомьтесь

со следующими источниками. тр:/Шь.а>ттт

Boehm, Barry и Richard Turner. Balancing Agility and Discipline:

A Guide for the Perplexed. Boston, MA: Addison-Wesley 2004. Бом и Тернер рассказывают, как размер проекта влияет на применение быстрых и четко спланированных методов, а также рассматривают другие вопросы, касающиеся быстроты и четкого планирования.

Cockburn, к\шш. Agile Software Development. Boston, MA: Addison-Wesley 2002. В главе 4 обсуждаются вопросы выбора подходящей методологии проекта, в том числе учитываются размеры проекта. Глава 6 представляет Кристаллическую методологию Кокберна (Cockburns Crystal Methodologies), в которой определены подходы к разработке проектов различной величины и степени критичности.

Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981. Бом всестороннее рассматривает такие зависящие от размера проекта величины, как стоимость, производительность и качество, а также другие переменные, участвующие в процессе разработки ПО. Книга включает обсуждение влияния размера на конструирование и другие операции. Глава 11 содержит отличное объяснение отрицательных последствий масштабирования ПО. Другая информация о размере проекта распределена по всей книге. Выпущенная в 2000 г книга Бома Software Cost Estimation with Сосото II содержит больше современной информации относительно оценочной модели Бома Сосото, но более ранняя книга включает более глубокое обсуждение вопроса, все еще представляющее интерес.

Jones, Capers. Estimating Software Costs. New York, NY: McGraw-Hill, 1998. Эта книга заполнена таблицами и графиками, анализирующими источники производительности разработки ПО. Что касается конкретного вопроса влияния размера проекта, то раздел «The Impact of Program Size» главы 3 изданной в 1986 г книги Джонса Programming Productivity содержит отличное обсуждение.



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