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

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

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

найдите другую работу.

Наилучшим долгосрочным решением будет попытка просветить вашего менеджера. Это не всегда легкая задача, но одним из способов подготовиться к ней будет чтение книги Дейла Карнеги «How to Win Friends and Influence People».

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

Следующие книги освещают общие вопросы управления

программными проектами. http: cc2e.com/2813

Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley, 1988. Гилб прокладывает собственный курс на протяжении 30 лет, и большую часть времени он обгоняет остальных независимо от того, отдают ли они себе в этом отчет. Эта книга - хороший тому пример. Она была одной из первых работ, в которых обсуждались эволюционные методики разработки, управление рисками и применение формальных проверок. Гилб хорошо осведомлен о наиболее передовых подходах; действительно, эта книга, опубликованная более 15 лет назад, содержит большинство хороших методик, которые преподносятся в настоящее время в качестве быстрой (agile) разработки. Гилб исключительно практичен, и его книга до сих пор является одной из лучших в сфере управления ПО.

McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996. Эта книга охватывает вопросы руководства и управления проектами, на выполнение которых остро не хватает времени, что, по моему опыту, относится к большинству проектов.

Brooks, Frederick P., Jr. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2d ed). Reading, MA: Addison-Wesley, 1995. Эта книга - смесь метафор и фольклора, связанного с управлением программными проектами. Она увлекательна и может пролить свет на содержимое ваших собственных проектов. В ее основе лежит рассказ о трудностях, с которыми сталкивался Брукс при разработке операционной системы OS/360, что позволяет мне сделать несколько замечаний. Она полна советов наподобие «Мы сделали так, и это не сработало» и «Нам следовало сделать вот так, потому что тогда бы это работало». Наблюдения Брукса по поводу неудачных методик хорошо обоснованы, но его заявления, что другие технологии были бы удачны, слишком гипотетичны. Читайте эту книгу критически, чтобы отделять наблюдения от умозаключений. Это предупреждение не умаляет значимости книги. Ее до сих пор чаще других цитируют в компьютерной литературе, и, хотя впервые она была опубликована в 1975 году, до сих пор кажется актуальной. Ее сложно читать без того, чтобы не восклицать «Точно!» каждые пару страниц.

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

IEEE Std 1058-1998, Standard for Software Project Management Plans.

IEEE Std 12207-1997, Information Technology - Software Life Cycle Processes.



IEEE Std 1045-1992, Standard for Software Productivity Metrics.

IEEE Std 1062-1998, Recommended Practice for Software Acquisition.

IEEE Std 1540-2001, Standard for Software Life Cycle Processes - Risk Management.

IEEE Std 828-1998, Standard for Software Configuration Management Plans

IEEE Std 1490-1998, Guide - Adoption of PMl Standard - A Guide to the Project Management Body of Knowledge.

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

Хорошая практика кодирования может быть достигнута путем внедрения стандартов или более ловкими способами.

Управление конфигурацией при правильном применении делает работу программистов проще. Это особенно касается контроля изменений.

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

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

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



ГЛАВА 29

Интеграция

Содержание

http: cc2e.com/2985

29.1. Важность выбора подхода к интеграции

29.2. Частота интеграции - поэтапная или инкрементная?

29.3. Стратегии инкрементной интеграции

29.4. Ежедневная сборка и дымовые тесты

Связанные темы

Тестирование во время разработки: глава 22

Отладка: глава 23

Управление конструированием: глава 28

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

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

29.1. Важность выбора подхода к интеграции

в инженерных отраслях, отличных от разработки ПО, важность правильной интеграции хорошо известна. На северо-западном побережье Тихого океана, где я живу, столкнулись с драматическими последствиями плохой интеграции, когда футбольный стадион Университета Вашингтон частично обрушился во время строительства (рис. 29-1).



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