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

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

Парвкиеши mm%t О го% что делать о изменениями проекта приложений и самого кода, см. раздел П±

П9$щш1ая еешха Об итвра-тианых подходах к разргкотке ом. подраздел «Используйте итерацию» раздела 5,4 и раздел 29.3.

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

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

Используйте те подходы к разработке, которые адаптируются к изменениям Некоторые подходы к разработке ПО позволяют особенно легко реагировать на изменения требований. Подход эволюционного прототипиро-вания (evolutionary prototyping) помогает исследовать требования к системе до начала ее создания. Эволюционная поставка ПО подразумевает предоставление системы пользователям по частям. Вы можете создать фрагмент системы, получить от пользователей отзывы, немного подкорректировать проект, внести несколько изменений и приступить к созданию другого фрагмента. Суть этого подхода - короткие циклы разработки, позволяющие быстро реагировать на пожелания пользователей.

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

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

Ооод-

ходах к разработке, поддержи-еающих гибкие грШшт, см. книгу «aptd

{мсОопшн, тщ.

Щттш ттш О разли-чж межш формальными и не-формальным/! проектами (которые часто йШттш различиями размеров проектов) см. главу 27.

rittp: cc2exom/0323

Контрольный список: требования

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

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



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

Специфические функциональные требования

□ Определены ли все способы ввода данных в систему с указанием источника, точности, диапазона значений и частоты ввода?

а Определены ли все способы вывода данных системой с указанием назна-чения, точности, диапазона значений, частоты и формата?

□ Определены ли все форматы вывода для Web-страниц, отчетов и т. д.? а Определены ли все внешние аппаратные и программные интерфейсы?

а Определены ли все внешние коммуникационные интерфейсы с указанием протоколов установления соединения, проверки ошибок и коммуникации?

□ Определены ли все задачи, в выполнении которых нуждается пользователь?

□ Определены ли данные, используемые в каждой задаче, и данные, являющиеся результатом выполнения каждой задачи?

Специфические нефункциональные требования (требования к качеству)

□ Определено ли ожидаемое пользователем время реакции для всех необходимых операций?

□ Определены ли другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы?

а Определен ли уровень защищенности системы?

□ Определена ли надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе, информация, которая должна быть защищена от сбоев, и стратегия обнаружения и исправления ошибок?

□ Определены ли минимальные требования программы к объему памяти и свободного дискового пространства?

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

□ Включено ли в требования определение успеха? Или неудачи?

Качество требований

□ Написаны ли требования на языке, понятном пользователям? Согласны ли с этим пользователи?

а Нет ли конфликтов между требованиями?

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

□ Не присутствуют ли в требованиях элементы проектирования?

а Согласован ли уровень детальности требований? Следует ли какое-нибудь требование определить подробнее? Менее подробно?

□ Достаточно ли ясны и понятны требования, чтобы их можно было передать независимой группе конструирования? Согласны ли с этим разработчики?

□ Каждое ли требование релевантно для проблемы и ее решения? Можно ли проследить каждое требование до его источника в проблемной среде?



□ Можно ли протестировать каждое требование? Можно ли будет провести независимое тестирование, которое позволит сказать, выполнены ли все требования?

□ Определены ли все возможные изменения требований и вероятность каждого изменения?

Полнота требований

а Указаны ли недостающие требования, которые невозможно определить до начала разработки?

□ Полны ли требования в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо?

а Не вызывают ли какие-нибудь требования у вас дискомфорта? Исключили ли вы требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника?

3.5. Предварительные условия, связанные с разработкой архитектуры

Архитектура - это высокоуровневая часть проекта прило- t\t%peetw9n ссьша О проек-жения, каркас, состоящий из деталей проекта (Buschman et тированйи на всах уровнях см. al., 1996; Fowler, 2002; Bass Clements, Kazman 2003; Clements гпаеы 5-9. et al, 2003). Архитектуру также называют «архитектурой системы», «высокоуровневым проектом» и «проектом высокого уровня». Как правило, архитектуру описывают в единственном документе, называемом «спецификацией архитектуры» или «высокоуровневым проектом». Некоторые разработчики проводят различие между архитектурой и высокоуровневым проектом: архитектурой называют характеристики всей системы, тогда как высокоуровневым проектом - характеристики, описывающие подсистемы или наборы классов, но не обязательно в масштабе всей системы.

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

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

Хорошая архитектура облегчает конструирование. Плохая архитектура делает его почти невозможным. Другую проблему, связанную с плохой архитектурой, иллюстрирует рис. 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.0023