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

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

опыт и способности разработчика требований;

опыт и способности программиста;

мотивация команды;

качество управления;

объем кода, использованного повторно;

текучесть кадров;

изменчивость требований;

отношения с заказчиком;

участие пользователя в разработке требований;

опыт работы заказчика с данным типом приложений;

степень участия программистов в разработке требований;

обеспечение безопасности компьютера, программ и данных;

объем документации;

цели проекта (выполнение по графику, качество, удобство использования или какие-то другие возможные цели).

Каждый из этих факторов может оказаться важным, так что имейте их в виду наряду с перечисленными в табл. 28-1 (в нее включены некоторые из приведенных факторов).

Оценка или контроль

Оценка - это важная часть планирования, необходимая для gg gp i g своевременного завершения проекта. Когда у вас есть срок у- потеть: прогноз

поставки и спецификация продукта, то основная проблема или контроль? в том, как управлять распределением человеческих и техни- там гш (Тт ШШ)

ческих ресурсов для своевременной готовности продукта.

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

Что делать, если вы отстаете

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

Надеяться, что вы сможете наверстать упущенное Обнадеживающий оптимизм - типичная реакция на отставание проекта от графика. Обычно объяснение выглядит так: «Составление требований заняло чуть больше времени, чем мы ожидали, но теперь они утверждены, и мы сможем сэкономить немного времени позже. Мы восполним недостачу при кодировании и тестировании». Ну, это вряд ли. В одном обзоре, охватывающем более 300 программных проектов, был сделан вывод, что задержки и отклонения от графика обычно увеличиваются по мере приближения к концу проекта (van Genuchten, 1991). Проекты не восполняют потерянное время позже - они отстают еще больше.

Увеличить команду Согласно закону Фреда Брукса (Fred Brooks) ввод дополнительных людей на последних стадиях проекта приводит к задержке его выпол-



нения (Brooks, 1995). Это все равно, что подливать масло в огонь. Объяснение Брукса выглядит убедительно: новым людям требуется время на ознакомление с проектом. Их обучение отнимет время у обученных работников. А само увеличение числа участников увеличивает сложность и количество вариантов взаимодействий в проекте. Брукс подчеркивает: то, что одна женщина может родить ребенка через девять месяцев, не значит, что девять женщин могут родить ребенка через месяц.

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

В то же время простое утверждение, что подключение программистов к работе над тормозящим проектом задерживает его еще больше, маскирует тот факт, что при некоторых обстоятельствах подобные меры способны ускорить работу. Как Брукс отмечает в анализе своего закона, подключение людей к программному проекту не поможет, если задачи в этом проекте нельзя разбить на составные части и выполнять их независимо. Но если задачи делятся на части, вы можете распределить их между разными людьми, даже недавно включившимися в работу. Другие исследователи смогли формально определить обстоятельства, при которых вы можете подключать людей к проекту на поздних стадиях и не вызывать еще большую его задержку (Abdel-Hamid, 1989; McConnell, 1999). Дшолйкгельньш шдш» Аргу- Софатить проект О таком мощном способе, как сокра-меитывзащйтуреанйзаритоль- щение проекта, часто забывают. Если вы исключаете какую-ко наиболее необщимой функ- то функцию, вы избавляетесь от проектирования, кодирова-циональности см. в главе 14 «Fea- ния, отладки, тестирования и документирования этой функ-ture-SelComrol» книги <«RapldDe- цр,, также от создания интерфейса между этой и други-velopmentMMcConneili99e). 1 / к/

ми функциями.

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

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

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



Дополнительные ресурсы, посвященные оценке ПО

Далее приведены ссылки на дополнительную литературу,

посвященную вопросу оценки ПО. tittp: cc2e,com/2871

Boehm, Barry, et al. Software Cost Estimation with Сосото IL

Boston, MA: Addison-Wesley, 2000. Здесь описана оценочная модель Сосото II - несомненно, самая популярная на сегодняшний день.

Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981. Эта более старая книга содержит исчерпывающее толкование вопросов оценки программных проектов, более общее, чем в новой книге Бома.

Humphrey, Watts S. Л Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995. В главе 5 этой книги описывается Метод зондирования Хамфри (Humphreys Probe method) - способ оценки объема работ с точки зрения отдельного программиста.

Conte, S. D., Н. Е. Dunsmore and V. У. Shen. Software Engineering Metrics and Models. Menlo Park, CA: Benjamin/Cummings, 1986. Глава 6 содержит хороший обзор методик оценки, включая историю оценки, статистические модели, теоретически обоснованные модели и составные модели. Книга также демонстрирует использование каждого способа оценки для набора проектов и сравнивает полученные расчетные значения с реальной продолжительностью проектов.

Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988. Назвав главу 16 «Десять принципов оценки атрибутов ПО» («Теп Principles for Estimating Software Attributes»), автор немного лукавит. Гилб возражает против оценки проектов и приводит аргументы в защиту контроля проектов. Указывая на то, что людям на самом деле нужны не точные прогнозы, а управление конечным результатом, Гилб выводит 10 принципов, которые можно использовать, чтобы заставить проект соответствовать намеченным срокам, стоимости или другим целям проекта.

28.4. Измерения

Программные проекты можно измерить по-разному Далее приведены важные причины, по которым вам стоит проводить измерение процесса.

Для любого атрибута проекта существует возможность его измерения, что в любом случае не означает отказа от его измерения Измерение может быть не абсолютно верным, его может быть трудно сделать и, возможно, придется временами уточнять, но измерение даст вам такой рычаг управления процессом разработки ПО, который вы не сможете получить иным способом (Gilb, 2004).

Если данные предназначены для использования в научном эксперименте, то их надо измерить. Можете ли вы представить ученого, рекомендующего запретить новый пищевой продукт, потому что группа белых крыс «кажется, чаще болеет» по сравнению с контрольной группой? Бред! Вы бы потребовали более точного ответа, например: «Крысы, которые ели новый пищевой продукт, болели на 3,7 дня дольше, чем крысы, которые его не ели». Чтобы оценить методы разработки ПО,



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