Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 28 Управление конструированием 657 Исходя из того, что оценки различались примерно на 5%, я пришел к заключе# нию, что объем книги будет гораздо ближе к 850 страницам, чем к 250, и скор# ректировал свои планы. Периодически делайте повторную оценку После пер# воначальной оценки факторы, влияющие на проект, могут измениться, поэтому планируйте периодически обновлять ваши оценки. Точность ваших расчетов будет увеличиваться по мере приближе# ния к завершению проекта (рис. 28#2). Время от времени сравнивайте реальные результаты с предполагаемыми и используйте это значение в целях уточнения расчетов для оставшейся части проекта. Рис. 28'2. Оценки, полученные на ранних стадиях проекта, в действительности не отличаются точностью. По мере продвижения проекта оценки могут стать более правильными. На протяжении проекта периодически делайте повторные расчеты и используйте данные, полученные во время каждого этапа, для уточнения оценки следующей операции Оценка объема работ по конструированию Степень влияния конструирования на график выполнения проекта частично зависит от того, какая доля проекта от# носится к конструированию, под которым понимается со# здание рабочего проекта, кодирование, отладка и модуль# ное тестирование. Взгляните еще раз на рис. 27#3: пропор# ции меняются в зависимости от размера проекта. Пока ваша компания не создаст свою историю проектов, доля време# ни для каждой операции, показанная на рисунке, может стать хорошей отправ# ной точкой для оценки ваших проектов. Самый правильный ответ на вопрос, каких затрат на конструирование потребует проект, таков: пропорции будут меняться от проекта к проекту и от организации http://cc2e.com/2864 Перекрестная ссылка Об объе- ме кодирования в проектах раз- личных размеров см. в подраз- деле «Соотношение между вы- полняемыми операциями и раз- мер» раздела 27.5. 658 ЧАСТЬ VI Системные вопросы к организации. Храните сведения об опыте проектов в вашей организации и ис# пользуйте их для оценки времени, необходимого будущим проектам. Факторы влияния на график работ Наибольшее влияние на график программного проекта ока# зывает размер создаваемой программы. Но многие другие факторы также влияют на план разработки ПО. При изуче# нии коммерческих программ были выделены следующие факторы (табл. 28#1): Табл. 28-1. Факторы, влияющие на успех программного проекта Потенциально Потенциально Фактор полезное влияние вредное влияние Централизованная/распределенная разработка –14% 22% Размер базы данных –10% 28% Соответствие документации нуждам проекта –19% 23% Гибкость, возможная при интерпретации –9% 10% требований Степень активности в обслуживании рисков –12% 14% Опыт использования языка и инструментария –16% 20% Преемственность персонала (текучесть кадров) –19% 29% Изменчивость платформы –13% 30% Совершенство процесса –13% 15% Сложность продукта –27% 74% Способности программиста –24% 34% Требуемая надежность –18% 26% Способности аналитиков по изучению –29% 42% требований Требования повторного использования –5% 24% Соответствие приложения современным –11% 12% требованиям Ограничения хранилища (какая часть 0% 46% доступного пространства будет израсходована) Сплоченность команды –10% 11% Опыт команды в данной прикладной области –19% 22% Опыт команды в работе с данной –15% 19% технологической платформой Временные ограничения (самого приложения) 0% 63% Использование специализированных –22% 17% программных инструментов Источник: «Software Cost Estimation with Cocomo II» (Boehm et al.,. 2000). А вот факторы, влияние которых на график разработки ПО измерить труднее; эти факторы извлечены из книг Барри Бома «Software Cost Estimation with Cocomo II» (2000) и Кейперса Джонса «Estimating Software Costs» (1998). Перекрестная ссылка Влияние размера программы на произ- водительность и качество не всегда интуитивно понятно (см. главу 27). ГЛАВА 28 Управление конструированием 659 опыт и способности разработчика требований; опыт и способности программиста; мотивация команды; качество управления; объем кода, использованного повторно; текучесть кадров; изменчивость требований; отношения с заказчиком; участие пользователя в разработке требований; опыт работы заказчика с данным типом приложений; степень участия программистов в разработке требований; обеспечение безопасности компьютера, программ и данных; объем документации; цели проекта (выполнение по графику, качество, удобство использования или какие#то другие возможные цели). Каждый из этих факторов может оказаться важным, так что имейте их в виду на# ряду с перечисленными в табл. 28#1 (в нее включены некоторые из приведенных факторов). Оценка или контроль Оценка — это важная часть планирования, необходимая для своевременного завершения проекта. Когда у вас есть срок поставки и спецификация продукта, то основная проблема в том, как управлять распределением человеческих и техни# ческих ресурсов для своевременной готовности продукта. С этой точки зрения, правильность начальной оценки гораздо менее важна, чем ваши последующие успехи в управлении ресурсами с целью соответствия графику. Что делать, если вы отстаете Как я уже говорил, средний проект выбивается из запланированного графика примерно на 100%. Когда вы опаздываете, увеличить время на разработку не все# гда возможно. Если сроки можно сдвинуть — сдвиньте. В противном случае вы можете принять одно или несколько из следующих решений. Надеяться, что вы сможете наверстать упущенное Обнадежи# вающий оптимизм — типичная реакция на отставание проекта от гра# фика. Обычно объяснение выглядит так: «Составление требований заня# ло чуть больше времени, чем мы ожидали, но теперь они утверждены, и мы смо# жем сэкономить немного времени позже. Мы восполним недостачу при кодиро# вании и тестировании». Ну, это вряд ли. В одном обзоре, охватывающем более 300 программных проектов, был сделан вывод, что задержки и отклонения от графи# ка обычно увеличиваются по мере приближения к концу проекта (van Genuchten, 1991). Проекты не восполняют потерянное время позже — они отстают еще больше. Увеличить команду Согласно закону Фреда Брукса (Fred Brooks) ввод допол# нительных людей на последних стадиях проекта приводит к задержке его выпол# Важный вопрос состоит в том, что вы хотите получить: прогноз или контроль? Том Гилб (Tom Gilb) 660 ЧАСТЬ VI Системные вопросы нения (Brooks, 1995). Это все равно, что подливать масло в огонь. Объяснение Брук# са выглядит убедительно: новым людям требуется время на ознакомление с про# ектом. Их обучение отнимет время у обученных работников. А само увеличение числа участников увеличивает сложность и количество вариантов взаимодействий в проекте. Брукс подчеркивает: то, что одна женщина может родить ребенка че# рез девять месяцев, не значит, что девять женщин могут родить ребенка через месяц. Несомненно, предупреждающий закон Брукса следует принимать во внимание гораздо чаще, чем это делается. Существует тенденция бросать людей на проект и надеяться, что они выполнят его вовремя. Менеджеры должны понимать, что разрабатывать ПО не то же самое, что ковать железо: большее число работников не обязательно означает больший объем выполненной работы. В то же время простое утверждение, что подключение программистов к работе над тормозящим проектом задерживает его еще больше, маскирует тот факт, что при некоторых обстоятельствах подобные меры способны ускорить работу. Как Брукс отмечает в анализе своего закона, подключение людей к программному проекту не поможет, если задачи в этом проекте нельзя разбить на составные части и выполнять их независимо. Но если задачи делятся на части, вы можете распре# делить их между разными людьми, даже недавно включившимися в работу. Дру# гие исследователи смогли формально определить обстоятельства, при которых вы можете подключать людей к проекту на поздних стадиях и не вызывать еще боль# шую его задержку (Abdel#Hamid, 1989; McConnell, 1999). Сократить проект О таком мощном способе, как сокра# щение проекта, часто забывают. Если вы исключаете какую# то функцию, вы избавляетесь от проектирования, кодирова# ния, отладки, тестирования и документирования этой функ# ции, а также от создания интерфейса между этой и други# ми функциями. При первоначальном планировании продукта разделите его возможности на ка# тегории «должны быть», «хорошо бы сделать» и «необязательные». Если вы отста# ете, расставьте приоритеты в категориях «необязательные» и «хорошо бы сделать» и отбросьте те, что имеют меньшее значение. При невозможности отмены каких#то функций вы можете представить более де# шевую версию той же функциональности. Так, вы можете сдать версию вовремя, не обеспечив при этом максимальной производительности. Или в этой версии менее важная функциональность будет реализована лишь в общих чертах. Вы можете решить отбросить требования к скорости выполнения, так как медленную версию сделать проще. Или можете решить отбросить требования к объему па# мяти, поскольку версию, интенсивно использующую память, сделать быстрее. Повторно оцените время разработки для менее важных функций. Какую функци# ональность вы можете предоставить за два часа, два дня или две недели? Какую выгоду вы получите от двухнедельной версии в отличие от двухдневной и чем двух# дневная версия будет отличаться от двухчасовой? Дополнительные сведения Аргу- менты в защиту реализации толь- ко наиболее необходимой функ- циональности см. в главе 14 «Fea- ture-Set Control» книги «Rapid De- velopment» (McConnell, 1996). ГЛАВА 28 Управление конструированием 661 Дополнительные ресурсы, посвященные оценке ПО Далее приведены ссылки на дополнительную литературу, посвященную вопросу оценки ПО. Boehm, Barry, et al. Software Cost Estimation with Cocomo II. Boston, MA: Addison#Wesley, 2000. Здесь описана оценочная модель Cocomo II — несомненно, самая популярная на сегодняшний день. Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981. Эта более старая книга содержит исчерпывающее толкование вопросов оценки программных проектов, более общее, чем в новой книге Бома. Humphrey, Watts S. A Discipline for Software Engineering. Reading, MA: Addison#Wesley, 1995. В главе 5 этой книги описывается Метод зондирования Хамфри (Humphrey’s Probe method) — способ оценки объема работ с точки зрения отдельного про# граммиста. Conte, S. D., H. E. Dunsmore and V. Y. Shen. Software Engineering Metrics and Models. Menlo Park, CA: Benjamin/Cummings, 1986. Глава 6 содержит хороший обзор мето# дик оценки, включая историю оценки, статистические модели, теоретически обо# снованные модели и составные модели. Книга также демонстрирует использова# ние каждого способа оценки для набора проектов и сравнивает полученные рас# четные значения с реальной продолжительностью проектов. Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison# Wesley, 1988. Назвав главу 16 «Десять принципов оценки атрибутов ПО» («Ten Principles for Estimating Software Attributes»), автор немного лукавит. Гилб возра# жает против оценки проектов и приводит аргументы в защиту контроля проек# тов. Указывая на то, что людям на самом деле нужны не точные прогнозы, а уп# равление конечным результатом, Гилб выводит 10 принципов, которые можно использовать, чтобы заставить проект соответствовать намеченным срокам, сто# имости или другим целям проекта. 28.4. Измерения Программные проекты можно измерить по#разному. Далее приведены важные причины, по которым вам стоит проводить измерение процесса. Для любого атрибута проекта существует возможность его из' мерения, что в любом случае не означает отказа от его изме' рения Измерение может быть не абсолютно верным, его может быть трудно сделать и, возможно, придется временами уточнять, но измерение даст вам такой рычаг управления процессом разработки ПО, который вы не сможете по# лучить иным способом (Gilb, 2004). Если данные предназначены для использования в научном эксперименте, то их надо измерить. Можете ли вы представить ученого, рекомендующего запретить новый пищевой продукт, потому что группа белых крыс «кажется, чаще болеет» по сравнению с контрольной группой? Бред! Вы бы потребовали более точного ответа, например: «Крысы, которые ели новый пищевой продукт, болели на 3,7 дня дольше, чем крысы, которые его не ели». Чтобы оценить методы разработки ПО, http://cc2e.com/2871 662 ЧАСТЬ VI Системные вопросы вы должны измерить их. Заявления типа «Этот новый метод выглядит более эф# фективным» недостаточно хороши. Отдавайте себе отчет о побочных эффектах изме' рения Измерение влияет на мотивацию. Люди обращают внимание на выполняемые измерения, предполагая, что измерения служат для их оценки. Выбирайте объекты для измерения осторожно. Люди имеют склонность сосредоточиваться на работе, которая измеряется, и игнорировать остальную. Возражать против измерений означает утверждать, что лучше не знать о том, что на самом деле происходит Если вы измерите какой#то аспект про# екта, вы узнаете о нем нечто, чего не знали ранее. Вы сможете увидеть, стал ли про# ект больше или меньше или остался таким же. Измерение предоставляет вам окно, через которое вы можете увидеть хотя бы этот аспект проекта. Окошко может быть маленьким и мутным до тех пор, пока вы не уточните свои измерения, но это все равно лучше, чем не иметь окна вообще. Возражать против любых измерений лишь потому, что некоторые из них неубедительны — все равно, что возражать против наличия окон, потому что некоторые из них могут быть мутными. Вы можете измерить практически любой аспект процесса разработки ПО. Вот некоторые виды измерений, которые некоторые профессионалы посчитали по# лезными (табл. 28#2). Табл. 28-2. Полезные объекты для измерения в области разработки ПО Размер Качество в целом Общее количество строк Общее число дефектов Общее количество строк комментариев Число дефектов в каждом классе или методе Общее число классов или методов Среднее количество дефектов на тысячу строк кода Общее количество объявлений данных Среднее время между сбоями Общее число пустых строк Ошибки, выявленные компилятором Отслеживание дефектов Удобство сопровождения Серьезность каждого дефекта Число открытых методов каждого класса Местонахождение каждого дефекта Число параметров, передаваемых каждому (класс или метод) методу Происхождение каждого дефекта Число закрытых методов и/или переменных (требования, проект, конструирование, в каждом классе тестирование) Способ, каким исправлялся каждый Число локальных переменных, используемых из дефектов каждым методом Лицо, ответственное за каждый дефект Число методов, вызываемых в каждом классе или методе Число строк, задействованных Число точек принятия решений в каждом в исправлении каждого дефекта методе Количество рабочих часов, потребовав# Сложность управляющей логики шихся для исправления каждого дефекта в каждом методе Среднее время, требуемое для поиска Число строк кода в каждом классе или методе дефекта Что измеряется, то выполня- ется. Том Питерс (Tom Peters) ГЛАВА 28 Управление конструированием 663 Табл. 28-2. (продолжение) Среднее время, требуемое Число строк комментариев в каждом классе для исправления дефекта или методе Число попыток, предпринятых Количество объявлений данных в каждом для исправления каждого дефекта классе или методе Число новых ошибок, появившихся Число пустых строк в каждом классе в результате исправления дефекта или методе Количество операторов goto в каждом классе или методе Количество операторов ввода или вывода в каждом классе или методе Производительность Количество человеко#часов, затраченных на проект Количество человеко#часов, потрачен# ных на каждый класс или метод Количество изменений каждого класса или метода Сумма в долларах, потраченная на проект Сумма в долларах, потраченная на строку кода Сумма в долларах, потраченная на каждый дефект Вы можете получить результаты для большинства этих измерений, используя со# временные программные средства. На протяжении всей книги обсуждались при# чины, по которым то или иное измерение может быть полезно. В настоящее вре# мя большинство этих измерений нужно не для поиска явных различий между программами, классами и методами (Shepperd and Ince, 1989). Они нужны в ос# новном для выявления методов, которые резко отличаются от других; необычные показатели измерений в каком#то методе предупреждают о том, что вам следует пересмотреть этот метод, дабы выяснить причину необычно низкого качества. Не начинайте сбор данных для всех возможных измерений — вы закопаетесь в таких сложных данных, что не сможете выяснить, что они означают. Начните с простого набора измерений, скажем, с количества дефектов, человеко#месяцев, общей суммы в долларах и общего количества строк кода. Стандартизуйте эти измерения во всех своих проектах, а затем уточняйте их показатели и добавляй# те к ним новые, по мере того как ваше понимание необходимых измерений улуч# шается (Pietrasanta, 1990). Убедитесь, что вы знаете причину, по которой собираете данные. Установите цели, определите вопросы, которые необходимо задать, чтобы добиться этих целей, а затем проводите измерения, чтобы узнать ответы (Basili and Weiss, 1984). Убеди# тесь, что существует возможность получить ту информацию, которую вы запра# шиваете, и не забывайте, что сбор данных всегда играет второстепенную роль по сравнению со сроками сдачи проектов (Basili et al., 2002). 664 ЧАСТЬ VI Системные вопросы Дополнительные ресурсы, касающиеся измерения ПО Oman, Paul and Shari Lawrence Pfleeger, eds. Applying Software Metrics. Los Alamitos, CA: IEEE Computer Society Press, 1996. Под обложкой этого тома собрано более 25 ключевых ста# тей, посвященных измерению ПО. Jones, Capers. Applied Software Measurement: Assuring Productivity and Quality, 2d ed. New York, NY: McGraw#Hill, 1997. Джонс — лидер в области измерения ПО, и его книга аккумулирует все знания в этой области. В ней представлена наиболее полная теория и практика существующих методик измерения и описаны проблемы, воз# никающие при использовании традиционных способов измерения. В книге при# ведена полная программа по сбору числа реализуемых функций. Джонс собрал и проанализировал огромный объем данных, касающийся качества и производитель# ности, и его труд содержит выжимку этих результатов, в том числе и захватываю# щую главу, посвященную средним значениям показателей в области разработки ПО в США. Grady, Robert B. Practical Software Metrics for Project Management and Process Impro% vement. Englewood Cliffs, NJ: Prentice Hall PTR, 1992. Гради рассказывает о внедре# нии программы по измерению ПО в Hewlett#Packard и о том, как внедрить такую программу в вашей организации. Conte, S. D., H. E. Dunsmore and V. Y. Shen. Software Engineering Metrics and Models. Menlo Park, CA: Benjamin/Cummings, 1986. Эта книга классифицирует существую# щие знания об измерениях ПО по состоянию на 1986 год, включая часто исполь# зуемые измерения, экспериментальные методики и критерии оценки результатов эксперимента. Basili, Victor R., et al. 2002. «Lessons learned from 25 years of process improvement: The Rise and Fall of the NASA Software Engineering Laboratory». Proceedings of the 24th International Conference on Software Engineering. Orlando, FL, 2002. В статье освещен опыт, полученный организацией, разрабатывающей одни из самых сложных про# граммных продуктов в мире. В центре внимания — вопросы измерения. NASA Software Engineering Laboratory. Software Measurement Guidebook, June 1995, NASA#GB#001#94. Это 100#страничное руководство возможно, лучший источник практической ин# формации о том, как настроить и использовать измерительную программу. Его можно загрузить с Web#сайта NASA. Gilb, Tom. Competitive Engineering. Boston, MA: Addison#Wesley, 2004. Книга представляет ориентированный на измерения подход к определению требований, разработке проекта, измерению качества и управлению проектом в целом. Ее можно загрузить с веб# сайта автора. 28.5. Гуманное отношение к программистам Атмосфера абстрактности в деятельности программистов требует создания непринужденной обстановки в офисе и поддержания широких контак# тов между коллегами. Высокотехнологичные компании предлагают пар# http://cc2e.com/2878 http://cc2e.com/2892 http://cc2e.com/2899 |