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

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

Табл. 3-1. Средняя стоимость исправления дефектов в зависимости от времени их внесения и обнаружения

Время обнаружения дефекта

Время

внесения

дефекта

Выработка Проектирование требований архитектуры

Тестирование После Конструирование системы выпуска ПО

Выработка 1 требований

Проектиро- - ванне архитектуры

Конструи- - рование

5-10 10

10 15

10-100 25-100

10-25

Источник: адаптировано из работ «Design and Code Inspections to Reduce Errors in Program Development* (Pagan 1976), «Software Defect Removal» (Dunn, 1984), «Software Process Improvement at Hughes Aircraft» (Humphrey, Snyder, and Willis, 1991), «Calculating the Return on Investment from More Effective Requirements Management* (Leffingwell, 1997), «Hughes Aircrafts Widespread Deployment of a Continuously Improving Software Process* (Willis et al., 1998), «An Economic Release Decision Model: Insights into Software Project Management* (Grady 1999), «What We Have Learned About Fighting Defects* (Shull et al., 2002) и «Balancing Agility and Discipline: A Guide for the Perplexed* (Boehm and Turner, 2004).

Эти данные говорят, например, о том, что дефект архитектуры, исправление которого при проектировании архитектуры обходится в $1000, может во время тестировании системы вылиться в $15 ООО (рис. 3-1).

Этап внесения дефекта

Выработка требований Проектирование архитектуры \ Конструирование

Затраты


Выработка требований Конструирование После выпуска ПО

Проектирование архитектуры Тестирование системы

Этап обнаружения дефекта

Рис. 3-1 С увеличением интервала между моментами внесения и обнаружения дефекта стоимость его исправления сильно возрастает. Это верно и для очень последовательных проектов (выработка требований и проектирование на 100% выполняются заблаговременно), и для очень итеративных (аналогичный показатель равен 5%)



В большинстве проектов основная часть усилий по исправлению дефектов все еще приходится на правую часть рис. 3-1, а значит, на отладку и переделывание работы уходит около 50% времени типичного цикла разработки ПО (Mills, 1983; Boehm, 1987; Cooper and Mullen, 1993; Fishman, 1996; Haley 1996; Wheeler, Brykczynski, and Meeson, 1996; Jones, 1998; Shull et al., 2002; Wiegers, 2002). В десятках компаний было обнаружено, что политика раннего исправления дефектов может в два и более раз снизить финансовые и временные затраты на разработку ПО (McConnell, 2004). Это очень веский довод в пользу как можно более раннего нахождения и решения проблем.

Тест готовности руководителя

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

Какие из этих утверждений являются самоисполняющимися пророчествами?

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

Мы не выделили много времени на тестирование, поскольку не ожидаем обнаружить много дефектов.

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

Все эти высказывания - самоисполняющиеся пророчества. Стремитесь к тому, чтобы исполнилось последнее.

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

3.2. Определите тип ПО, над которым вы работаете

Обобщая 20 лет исследований разработки ПО, Кейперс Джонс, руководитель исследовательских работ в компании Software Productivity Research, заявил, что он и его коллеги сталкивались с 40 разными методами сбора требований, 50 вариантами проектирования ПО и 30 видами тестирования, применявшимися в проектах, реализуемых более чем на 700 языках программирования (Jones, 2003). Разные типы проектов призывают к разным сочетаниям подготовки и конструирования. Каждый проект уникален, однако обычно проекты подпадают под общие стили разработки. Вот три самых популярных типа проектов, а также оптимальные в большинстве случаев методы работы над ними (табл. 3-2):



Табл. 3-2. Оптимальные методы работы над программными проектами трех популярных типов

Тип ПО

Бизнес-системы

Системы целевого назначения

Встроенные системы, от которых зависит жизнь людей

Типичные приложения

Модели жизненного цикла

Планирование и управление

Интернет-сайты. Сайты в интрасетях. Системы управления материально-техническим снабжением. Игры.

Системы управления информацией. Системы выплаты заработной платы.

Гибкая разработка (экстремальное программирование, методология Scrum, разработка на основе временных окон и т. д.).

Эволюционное, прототипирование.

Инкрементное планирование проекта. Планирование тестирования и гарантии качества по мере надобности. Неформальный контроль над изменениями.

Встроенное ПО. Игры.

Интернет-сайты. Пакетное ПО. Программные инструменты. Web-сервисы.

Поэтапная поставка.

Эволюционная

поставка.

Спиральная

разработка.

Базовое заблаговременное планирование. Базовое планирование тестирования. Планирование гарантии качества по мере надобности. Формальный контроль над изменениями.

Авиационное ПО. Встроенное ПО. ПО для медицинских устройств. Операционные системы. Пакетное ПО.

Поэтапная поставка.

Спиральная

разработка.

Эволюционная

поставка.

Исчерпывающее заблаговременное планирование. Исчерпывающее планирование тестирования.

Исчерпывающее планирование гарантии качества.

Тщательный контроль над изменениями.

Выработка Неформальная

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

Полуформальная спе- Формальная специ-цификация требований, фикация требований. Обзоры требований Формальные инспек-по мере надобности. ции требований.

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



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