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

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

вы можете вернуться к любой версии любого файла, когда-либо зарегистрированной в системе управления версиями;

вы можете получить список изменений, выполненных в любой версии любого файла;

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

Контроль версий - необходимая составляющая командных проектов. Он становится еще более мощным оружием при интеграции управления версиями, отслеживания дефектов и управления изменениями. Подразделение прикладного ПО Microsoft считает собственный инструментарий управления версиями «важнейшим преимуществом» (Moore, 1992).

Версии инструментария

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

Конфигурации компьютеров

Многие компании (включая мою) на своем опыте познали преимущества создания стандартизованных машинных конфигураций. На стандартной рабочей станции, содержащей необходимый инструментарий, офисные приложения и другие программы, создается образ диска. Этот образ копируется на машину каждого разработчика. Стандартная конфигурация позволяет избежать уймы проблем, связанных со слегка различающимися конфигурационными параметрами, версиями применяемых инструментов и т. п. Стандартизованный образ диска также сильно упрощает подготовку новой машины по сравнению с необходимостью устанавливать каждую программу отдельно.

План резервного копирования

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

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



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

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

Контрольный список: управление конфигурацией

http: cc2e.com/2843

Общие вопросы

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

□ Лишен ли подход к SCM излишнего контроля над проектом?

□ Группируются ли запросы на изменение либо с помощью неформальных средств (например, списка планируемых изменений), либо посредством более систематического подхода (такого, как комитет контроля изменений)?

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

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

Инструментарий

□ Используется ли ПО управления версиями для облегчения управления конфигурацией?

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

Резервное копирование

□ Выполняется ли периодическое резервное копирование всех материалов проекта?

□ Выполняется ли периодическое перемещение резервных копий проекта в сторонние хранилища?

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

□ Протестирована ли процедура восстановления из резервной копии?

Дополнительные ресурсы по управлению конфигурацией

Поскольку эта книга посвящена конструированию, в данном http: cc2Mom/28SO разделе рассматривается управление изменениями с точки

зрения конструирования. Но изменения затрагивают все уровни проекта, и всеобъемлющая стратегия управления изменениями должна делать то же самое.

Hass, Anne Mette Jonassen. Configuration Management Principles and Practices. Boston, MA: Addison-Wesley, 2003. Эта книга дает общую картину управления конфигурацией ПО, а также практические советы, как его внедрить в процесс разработки.

Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston, MA: Addison-Wesley, 2003. Как и в



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

SPMN. Little Book of Configuration Management. Arlington, VA:

Software Program Managers Network, 1998. Эту брошюра зна- Mtp: cc28.com/2857

комит с процессом управления конфигурацией и определяет критически важные факторы успеха. Она находится в свободном доступе на сайте SPMN по адресу umwspmn.com/products guidebooks.btml.

Bays, Michael. Software Release Methodology. Englewood Cliffs, NJ: Prentice Hall, 1999. Эта книга обсуждает управление конфигурацией ПО с акцентом на выпуске промышленной версии продукта.

Bersoff, Edward Н. and Alan М. Davis. «Impacts of Life Cycle Models on Software Configuration Management». Communications of the ACM 34, no. 8 (August, 1991): 104-118. В этой статье описано, как влияют на SCM новые подходы к разработке ПО, особенно касающиеся создания прототипов. Статья в особенности актуальна для сред, использующих практику быстрой (agile) разработки приложений.

28.3. Оценка графика конструирования

Управление программным проектом - одна из исключительно трудоемких задач XXI века, причем оценка размера проекта и усилий, требуемых для его завершения, - один из сложнейших аспектов управления проектом. Большой программный проект в среднем завершается на год позже заявленного срока и на 100% превышает первоначальный бюджет (Standish Group, 1994; Jones, 1997; Johnson, 1999). При опросах программистов по поводу разницы между ожидаемым и реальным графиками выполнения проекта выяснилось, что разработчики имеют склонность к оптимистичным оценкам в пределах 20-30% (van Genuchten, 1991). Это в той же степени связано с ошибочной оценкой размера проекта и требуемых усилий, как и с плохой разработкой. В данном разделе очерчен круг вопросов, связанных с оценкой программных проектов, а также указано, где найти более подробную информацию.

Подходы к оценке

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

его завершения, одним из нескольких способов: дробнее о шодиш оценки гра-

применить оценочное ПО; фика работ см. гпаву 8 в «RapJd

использовать алгоритмический подход, такой как Сосото Oevelopmem>> (McCortneB, 1996)

„ . , ллч и «$oftwaf6 Cost Estimation with

II, оценочная модель Барри Бома (Boehm et al., 2000); 3 2000),

привлечь внешних экспертов для оценки проекта;

обсудить предполагаемые затраты на собрании;

оценить составные части проекта, а затем сложить их вместе;

предложить каждому оценить их собственные задания, а затем просуммировать полученные предположения;

применить опыт предыдущих проектов;

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



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