Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 28 Управление конструированием 651 Оценивайте затраты на каждое изменение Каждый раз, когда ваш заказ- чик, босс или вы сами намерены изменить систему, оценивайте время, необходи- мое на внесение изменения, включая рецензирование кода этого изменения и по- вторное тестирование всей системы. Учтите в вашей оценке расходы, касающие- ся возникновения волнового эффекта от этого изменения, распространяющего- ся по направлению от требований к проектированию, кодированию, тестирова- нию и обновлениям в пользовательской документации. Пусть все заинтересован- ные стороны знают, что ПО имеет сложнопереплетенную структуру, и что вре- менная оценка требуется, даже если изменение кажется небольшим. Независимо от того, как оптимистично вы оцениваете предложенное изменение, воздержитесь от немедленной оценки. Такие оценки обычно ошибочны в два и более раз. Относитесь с подозрением к изменениям большого объема Некоторое количество изменений неизбежно, но большой объем запросов на изменение сигнализирует о том, что требования, архитектура или высокоуровневое проек- тирование не были выполнены достаточно качественно, чтобы способствовать эффективному конструированию. Возврат к работе над требованиями или архитектурой мо- жет показаться накладным, но он гораздо дешевле, чем кон- струирование ПО более одного раза или выбрасывание кода тех функций систе- мы, которые, как выяснилось, вам не нужны. Учредите комитет контроля изменений Работа комитета контроля измене- ний состоит в отделении зерен от плевел в запросах на изменение. Любой, кто хочет предложить изменение, отправляет запрос этому комитету. Термин «запрос на изменение» относится к любому запросу, который приводит к изменению ПО: идея новой функции, изменение в существующей функциональности, «отчет об ошибке», который сигнализирует о действительной или мнимой ошибке, и т. д. Комитет периодически собирается и рассматривает предложенные изменения. Он одобряет, отвергает или откладывает каждое изменение. Комитеты контроля из- менений считаются лучшим решением для расстановки приоритетов и контроля изменений в требованиях, но они еще довольно редко встречаются в коммерче- ских структурах (Jones, 1998; Jones, 2000). Соблюдайте бюрократические процедуры, но не позволяйте страху пе- ред бюрократией препятствовать эффективному контролю изменений Нехватка дисциплинированного контроля изменений — одна из важнейших про- блем управления. Значительный процент проектов, которые считались выполнен- ными с опозданием, на самом деле могли быть сделаны в срок, если бы в них учи- тывалось влияние неотслеживаемых, но согласованных изменений. Плохой кон- троль изменений позволяет накапливаться нерегистрируемым изменениям, что подрывает возможность видеть текущее положение дел, делать долгосрочные про- гнозы, планировать выполнение работ, а также влияет на управление рисками в частности и управление проектом в целом. Контроль изменений имеет тенденцию к бюрократизации, поэтому важно искать способы по рационализации этого процесса. Если вы предпочитаете не исполь- Перекрестная ссылка Другую точку зрения на работу с изме- нениями можно найти в подраз- деле «Что делать при изменении требований во время конструи- рования программы?» раздела 3.4. Советы по безопасным из- менениям в коде см. в главе 24. 652 ЧАСТЬ VI Системные вопросы зовать традиционные запросы на изменения, заведите почтовый адрес «Change- Board» и обяжите сотрудников посылать на него запросы на изменение. Или по- просите высказывать предложения по изменениям интерактивно на заседаниях комитета контроля. Особенно действенная мера — запись запросов на измене- ния в качестве дефектов в систему отслеживания дефектов. Ревнители порядка могут классифицировать такие изменения как «дефекты требований», или их можно считать изменениями, а не дефектами. Вы можете создать официальный Комитет контроля изменений, или Группу пла- нирования продукта или Военный совет, которые будут выполнять традиционные обязанности комитета контроля изменений. Или вы можете выбрать отдельного человека в качестве Царя изменений. Но как бы вы это ни назвали, сделайте это! Время от времени я встречаю проекты, страдающие от неумелой реали- зации контроля изменений. Но в 10 раз чаще я вижу проекты, страдаю- щие от полного отсутствия вразумительного контроля изменений. Глав- ное — это сама сущность контроля изменений, поэтому не позволяйте страху перед бюрократизацией помешать реализации преимуществ этого подхода. Изменения в коде программного обеспечения Другое назначение управления конфигурацией — контроль исходного кода. Если вы изменили код и возникла новая ошибка, которая, вроде бы, никак не связана со сделанными вами правками, то при поиске ее источника, вы, возможно, захо- тите сравнить новую и старые версии кода. Если это ничем вам не поможет, вы, вероятно, захотите взглянуть на еще более старую версию. Совершить такой экс- курс в историю просто, если у вас есть инструменты управления версиями, кото- рые отслеживают многочисленные версии исходного кода. Программы управления версиями С хорошим ПО для управления версиями работать так легко, что вы едва замечаете его существование. Оно особенно полезно в групповых проектах. Один вариант управления версиями блокирует исходные файлы так, что только один человек может моди- фицировать файл в некоторый момент времени. Обычно, когда вам нужно пора- ботать с каким-то исходным кодом, вы должны снять этот файл с учета (check out) в системе управления версиями. Если кто-то уже проделал эту процедуру, вы по- лучите сообщение, что этого сделать нельзя. Когда вы извлечете этот файл, вы смо- жете с ним работать так же, как и без использования системы управления верси- ями до тех пор, пока не будете готовы снова зарегистрировать его (check in). Другой вариант управления версиями позволяет нескольким людям работать с файлами одновременно и следит за необходимостью слияния изменений во время регис- трации файлов. В обоих случаях, когда вы регистрируете файл, система спраши- вает вас, почему вы его изменили, и вы указываете причину. При таких скромных усилиях вы получаете несколько больших преимуществ: 쐽 вы не наступаете никому на ноги, работая с файлом в тот момент, когда с ним работает кто-то другой (или хотя бы вы знаете об этом); 쐽 вы легко можете обновить свои копии всех файлов проекта, чтобы они соот- ветствовали текущим версиям, обычно одной командой; ГЛАВА 28 Управление конструированием 653 쐽 вы можете вернуться к любой версии любого файла, когда-либо зарегистри- рованной в системе управления версиями; 쐽 вы можете получить список изменений, выполненных в любой версии любо- го файла; 쐽 вам не надо заботиться о персональных резервных копиях, поскольку копия в системе контроля версий служит гарантией безопасности. Контроль версий — необходимая составляющая командных проектов. Он стано- вится еще более мощным оружием при интеграции управления версиями, отсле- живания дефектов и управления изменениями. Подразделение прикладного ПО Microsoft считает собственный инструментарий управления версиями «важнейшим преимуществом» (Moore, 1992). Версии инструментария Для некоторых видов проектов может понадобиться реконструкция точной сре- ды, используемой для разработки каждой конкретной версии ПО, включая ком- пиляторы, компоновщики, библиотеки кода и т. д. В этом случае вам также следу- ет поместить эти инструменты в систему управления версиями. Конфигурации компьютеров Многие компании (включая мою) на своем опыте познали преимущества созда- ния стандартизованных машинных конфигураций. На стандартной рабочей стан- ции, содержащей необходимый инструментарий, офисные приложения и другие программы, создается образ диска. Этот образ копируется на машину каждого разработчика. Стандартная конфигурация позволяет избежать уймы проблем, свя- занных со слегка различающимися конфигурационными параметрами, версиями применяемых инструментов и т. п. Стандартизованный образ диска также силь- но упрощает подготовку новой машины по сравнению с необходимостью уста- навливать каждую программу отдельно. План резервного копирования План резервного копирования — концепция не новая. Идея в том, чтобы перио- дически делать копию вашей работы. Если вы пишете книгу, вы не оставите руко- пись на крыльце, так как ее может намочить дождь, сдуть ветер или прихватить соседская собака — почитать на сон грядущий. Вы положите свой труд в безопас- ное место. ПО менее осязаемо, поэтому гораздо проще забыть, что на вашей ма- шине есть нечто очень ценное. С компьютерными данными может произойти множество неприятностей: может повредиться жесткий диск, вы или кто-то другой можете случайно удалить самые важные файлы, рассерженный сотрудник может устроить акцию саботажа, по разным причинам (кража, наводнение, пожар) вы можете лишиться своей маши- ны. Предпринимайте шаги для защиты своей работы. Ваш план резервного копи- рования должен включать периодическое создание копий и их хранение в дру- гих помещениях. Кроме исходного кода, в нем должны присутствовать все важ- ные для вашего проекта материалы: документы, чертежи и другие записи. 654 ЧАСТЬ VI Системные вопросы Один часто забываемый аспект разработки плана резервного копирования состоит в проверке процедуры создания резервных копий. Попробуйте восстановить дан- ные на некоторый момент времени, чтобы убедиться, что резервная копия содержит необходимую информацию и восстановленная версия работоспособна. Завершив проект, создайте его архив. Сохраните в надежном месте копию всего: исходного кода, компиляторов, инструментов, требований, проекта, документа- ции — всего, что может понадобиться для полного воссоздания продукта. Контрольный список: управление конфигурацией Общие вопросы Разработан ли план управления конфигурацией так, что- бы помочь работе программистов и минимизировать накладные расходы? Лишен ли подход к SCM излишнего контроля над проектом? Группируются ли запросы на изменение либо с помощью неформальных средств (например, списка планируемых изменений), либо посредством более систематического подхода (такого, как комитет контроля изменений)? Выполняется ли систематическая оценка влияния каждого предложенного изменения на стоимость, график и качество проекта? Рассматриваете ли вы большие изменения как предупреждение о том, что разработка требований завершена не полностью? Инструментарий Используется ли ПО управления версиями для облегчения управления кон- фигурацией? Используется ли ПО управления версиями для уменьшения сложностей в координации работы команды? Резервное копирование Выполняется ли периодическое резервное копирование всех материалов про- екта? Выполняется ли периодическое перемещение резервных копий проекта в сто- ронние хранилища? Копируются ли все материалы, включая исходный код, документы, чертежи и важные записи? Протестирована ли процедура восстановления из резервной копии? Дополнительные ресурсы по управлению конфигурацией Поскольку эта книга посвящена конструированию, в данном разделе рассматривается управление изменениями с точки зрения конструирования. Но изменения затрагивают все уровни проекта, и всеобъемлющая стратегия управления изменениями должна делать то же самое. 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. Как и в http://cc2e.com/2850 http://cc2e.com/2843 ГЛАВА 28 Управление конструированием 655 предыдущей книге, здесь дается общий обзор SCM и много практической инфор- мации. Преимуществом этой книги является наличие советов, помогающих груп- пам разработчиков изолировать и координировать свою работу. SPMN. Little Book of Configuration Management. Arlington, VA: Software Program Managers Network, 1998. Эту брошюра зна- комит с процессом управления конфигурацией и опреде- ляет критически важные факторы успеха. Она находится в свободном доступе на сайте SPMN по адресу www.spmn.com/products_guidebooks.html. Bays, Michael. Software Release Methodology. Englewood Cliffs, NJ: Prentice Hall, 1999. Эта книга обсуждает управление конфигурацией ПО с акцентом на выпуске про- мышленной версии продукта. Bersoff, Edward H. and Alan M. Davis. «Impacts of Life Cycle Models on Software Con- figuration 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). Это в той же степени связано с ошибочной оценкой размера проекта и требуемых усилий, как и с плохой разработкой. В данном разделе очерчен круг вопросов, связанных с оценкой программных проектов, а также указано, где найти более подробную информацию. Подходы к оценке Вы можете оценить размер проекта и усилия, требуемые для его завершения, одним из нескольких способов: 쐽 применить оценочное ПО; 쐽 использовать алгоритмический подход, такой как Cocomo II, оценочная модель Барри Бома (Boehm et al., 2000); 쐽 привлечь внешних экспертов для оценки проекта; 쐽 обсудить предполагаемые затраты на собрании; 쐽 оценить составные части проекта, а затем сложить их вместе; 쐽 предложить каждому оценить их собственные задания, а затем просуммиро- вать полученные предположения; 쐽 применить опыт предыдущих проектов; 쐽 сохранить предыдущие оценки и посмотреть, насколько они были аккуратны, а затем применять их для коррекции новых предположений. http://cc2e.com/2857 Дополнительные сведения По- дробнее о методиках оценки гра- фика работ см. главу 8 в «Rapid Development» (McConnell, 1996) и «Software Cost Estimation with Cocomo II» (Boehm et al., 2000). 656 ЧАСТЬ VI Системные вопросы Ссылки на подробную информацию об этих подходах даны в подразделе «Допол- нительные ресурсы, посвященные оценке ПО» в конце этого раздела. Далее опи- сан правильный подход к оценке проекта. Определите цели Зачем нужна оценка? Что вы оценива- ете? Только операции конструирования или весь процесс разработки? Только затраты на проект или на проект плюс отпуска, праздники, обучение и другие мероприятия, не относящиеся к проекту? Насколько аккуратной должна быть оценка, чтобы соответствовать вашим целям? Какую она дол- жна иметь степень достоверности? Приведут ли оптимистичная и пессимистич- ная оценки к существенно различным результатам? Выделите время для оценки Скоропалительные оценки неаккуратны. Если вы оцениваете большой проект, рассматривайте процесс оценки как минипроект и выделите время для минипланирования оценки, чтобы хорошо ее выполнить. Выясните требования к программе Точно так же, как архитектор не может сказать, сколько будет стоить «доста- точно большой» дом, так и вы не сможете надежно оценить «достаточно большой» программный проект. Бессмысленно ожидать от вас оценки объема работ, требуемых для реализации чего-то, если это «что-то» еще не опре- делено. Определите требования или запланируйте подготовительный этап для исследований, прежде чем что-то оценивать. Делайте оценки на низком уровне детализации В зависимости от обозна- ченных целей основывайте оценки на подробном изучении свойств проекта. В целом чем подробней будет ваша экспертиза, тем аккуратней будет оценка. По закону больших чисел, если на одном большом интервале существует 10%-я по- грешность, ошибка составляет 10% либо в сторону увеличения, либо в сторону уменьшения. На 50 небольших интервалах часть 10%-х погрешностей будет в сто- рону увеличения, а часть — в сторону уменьшения, и погрешности будут уравно- вешивать друг друга. Используйте несколько способов оценки и сравнивай- те полученные результаты Не все методики оценки приведут к одинаковым результатам, так что попробуйте несколько. Изучите результаты, полученные разными спо- собами. Дети быстро смекают, что, если попросить третий шарик мороженного у каждого родителя в отдельности, больше шансов услышать хотя бы одно «да», чем если спра- шивать только одного родителя. Иногда родители догады- ваются, в чем дело, и дают одинаковый ответ, а иногда — нет. Выясните, какие варианты ответов вы можете получить при использовании разных методик оценки. Ни один подход не является лучшим в любых обстоятельствах, а разница между ними может многое объяснить. Например, работая над первым изданием этой книги, я навскидку оценивал ее размер в 250–300 страниц. Когда я наконец вы- полнил углубленный расчет, предполагаемый объем оказался равен 873 страни- цам. «Этого не может быть», — подумал я. Поэтому я воспользовался абсолютно другим способом оценки. В результате второй попытки я получил 828 страниц. Дополнительные сведения Эта методика основана на рекомен- дациях, предложенных в «Soft- ware Engineering Economics» (Boehm, 1981). Перекрестная ссылка О требо- ваниях к ПО см. раздел 3.4. Перекрестная ссылка Сложно найти область разработки ПО, в которой итерация не имеет важ- ного значения. Процесс предва- рительной оценки — один из примеров, где итерация может принести пользу. Об итератив- ных методиках см. раздел 34.8. |