Калибровка и исторические данные

Калибровка и исторические данные

Область применения методов этой главы
Калибровка средними данными по отрасли
Калибровка.
историческими.
данными
Калибровка.
проектными.
данными
Что оценивается
Размер, объем
Размер, объем
Размер, объем
работ, сроки,
работ, сроки,
работ, сроки,
функциональность
функциональность
функциональность
Размер проекта
М С Б
М С Б
М С Б
Стадия разработки
Ранняя-средняя
Ранняя-средняя
СреДняя-поздняя
Итеративный или последовательный стиль
Оба
Оба
Оба
Возможная точность
Низкая-средняя
Средняя-высокая
Высокая
Калибровка используется для преобразования счетных показателей в оценки — строк кода в объем работы, историй пользователей в календарное время, требований в тестовые сценарии и т. д. Оценка всегда подразумевает некую разновидность калибровки, прямую или косвенную. Калибровка с использованием различных типов данных образует вторую часть метода «сначала подсчет, затем вычисления», описанного в главе 7.
Ваши оценки могут калиброваться по трем типам данных.
• Среднеотраслевые данные — данные других организаций, занимающихся разработкой аналогичного программного обеспечения.
• Исторические данные — в книге так называются данные организации, которая занимается оцениваемым проектом.
• Проектные данные — данные, полученные ранее в ходе оцениваемого проекта.
Исторические и проектные данные приносят огромную пользу и позволяют существенно повышать точность оценок. Отраслевые данные — не более чем временная, резервная информация, которая может пригодиться при отсутствии исторических или проектных данных.
8.1. Улучшение точности и другие преимущества исторических данных.
Основная причина для использования исторических данных вашей организации заключается в том, что они заметно повышают точность оценки. Использование исторических данных, или «документированных фактов», отрицательно коррелируется с превышением сроков и затрат — иначе говоря, для проектов, оцениваемых на основе исторических данных, превышения не характерны (Lederer and Prasad 1992).
В следующих разделах представлены некоторые причины для повышения точности оценок.
Учет организационных факторов.
Прежде всего, исторические данные учитывают великое множество организационных факторов, влияющих на результат проекта. В очень малых проектах результат определяется личными качествами работников. С увеличением размера проекта талантливые личности по-прежнему важны, однако их вклад либо поддерживается, либо подрывается влиянием организационных факторов. В средних и крупных проектах организационные характеристики начинают играть не менёе важную роль, чем личные качества.
Далее перечислены некоторые организационные факторы, влияющие на результат проекта.
• Насколько сложна программа, какие ограничения накладываются на ее быстродействие, какую надежность необходимо обеспечить, сколько документации требуется, существуют ли предыдущие аналоги — другими словами, какое место занимает проект в системе факторов Cocomo И, относящихся к типу разрабатываемого проекта (см. главу 5)?.
• Может ли организация определиться с устойчивыми требованиями, или рабочая группа должна учитывать возможные изменения на протяжении всего проекта?.
• Может ли руководитель проекта избавиться от проблемного участника, или же кадровая политика организации затрудняет (или делает невозможной) его увольнение?.
• Может ли группа полностью сосредоточиться на текущем проекте, или ее участникам приходится часто отвлекаться на запросы, связанные с поддержкой предыдущих проектов?.
• Может ли организация включать новых участников в проект, как было запланировано, или она откажется «выдергивать» работников из других проектов вплоть до их завершения?.
• Поддерживает ли организация использование эффективных методов проектирования, конструирования, контроля качества и тестирования?.
• Работает ли организация в регламентированной среде (например, под действием нормативных актов FAA или FDA), предписывающей обязательное следование некоторым правилам?.
• Может ли руководитель проекта рассчитывать на то, что участники группы останутся на работе вплоть до завершения проекта, или для организации характерна высокая текучесть кадров?.
Пытаться учитывать каждый из этих факторов по отдельности трудно, к тому же при этом повышается вероятность ошибки. Исторические данные вносят поправку на все эти факторы независимо от того, известны вам конкретные детали или нет.
Предотвращение субъективизма и необоснованного оптимизма.
Один из путей, по которым субъективизм проникает в оценку: руководитель проекта или оценщик смотрит на новый проект, сравнивает его со старым, замечает множество различий между ними, а затем делает вывод, что новый проект пойдет лучше старого. Он говорит: «В предыдущем проекте у нас была большая текучесть кадров; на этот раз этого не будет, и наша работа станет более эффективной. К тому же нас постоянно отвлекали на поддержку предыдущей версии; мы позаботимся о том, чтобы этого не произошло. Отдел маркетинга вносил поздние изменения в требования. Мы и с этим справимся лучше. Вдобавок на этот раз мы будем использовать более современную технологию и новые, более эффективные методы разработки. При таких усовершенствованиях наша работа будет гораздо более продуктивной».
В обоснованиях такого рода легко прослеживается оптимизм. Однако перечисленные факторы находятся под контролем организации, а не конкретного руководителя проекта, поэтому большинство из них будет трудно контролировать на уровне отдельного проекта. Другие факторы подвергаются оптимистичной переоценке, из-за чего в оценку вносится смещение.
При наличии исторических данных используется упрощенное предположение.
о том, что следующий проект пойдет примерно так же, как прошлый проект. Вполне разумное предположение. По словам гуру в области оценки Лоренса Путнэма, производительность является атрибутом организации и не может легко изменяться между проектами (Putnam and Myers 1992, Putnam and Myers 2003). Аналогичная концепция представлена в экстремальном программировании в виде «принципа вчерашней погоды»: сегодняшняя погода не всегда будет такой же, как вчера, но она будет похожа на вчерашнюю погоду с большей вероятностью, чем на что-либо другое (Beck and Fowler 2001).
Стройте свои оценки производительности на исторических данных. Производительность вашей организации в прошлом дает наилучшее представление о ее производительности в будущем.
Снижение влияния политических факторов при оценке.
Одна из потенциальных проблем моделей оценки с большим количеством регулируемых факторов заключается в том, что многие регуляторы верхнего уровня относятся к персоналу. Например, модель Cocomo II требует оценки навыков аналитиков и программистов наряду с несколькими менее субъективными факторами, относящимися к опыту. Оценщик должен дать оценку программистов, выбирая между 90-й, 75-й, 55-й, 35-й и 15-й процентилью (эти значения процентилей являются общеотраслевыми).
Представьте, что руководитель проекта представляет высшему начальству оценку Cocomo И, и теперь идет собрание, в ходе которого выясняется, не заложены ли в оценке какие-либо излишества. Легко представить себе следующий разговор.
Руководитель: Я знаю, что мы должны выпустить продукт за 12 педель, но мои оценки показывают, что работа займет 16 недель. Давайте проанализируем оценку при помощи этой программы. Вот несколько предположений, которые я сделал. Сначала нужно откалибровать модель оценки. Для фактора «квалификация программистов» я указал, что наши программисты относятся к 35-й процентили...
Начальство: Что?! В нашем штате нет ни одного человека ниже среднего уровня! Нужно быть более уверенным в своих оценках! Что же вы за руководитель? Возможно, у пас есть несколько человек, которые чуть отстают от остальных, но в целом группа не может быть настолько плохой. Давайте предположим, что они по крайней мере на среднем уровне, хорошо? Это можно ввести в программу?.
Руководитель: Ладно. Следующий фактор — квалификация разработчиков требований. Мы никогда не ставили себе задачу набрать хороших аналитиков или развить эти навыки в своих работниках, поэтому я использовал 15-ю процентиль...
Начальство: Постойте! 15-я процентиль? Наши люди очень талантливы, хотя они и не прошли формального обучения в разработке требований. Они долэкжы быть по крайней мере не хуже среднего. Можно заменить этот фактор средним значением?.
Руководитель: Не представляю, как можно назвать их средними. У нас нет ни одного человека, которого можно было бы назвать специалистом по требованиям.
Начальство: Хорошо. Предлагаю компромисс: сойдемся на 35-й процентили.
Руководитель: Ладно (вздыхает).
В результате разговора оценка объема работы, полученная руководителем с использованием регулирующих факторов Cocomo II, сократилась на 23 %. А если бы начальству удалось уговорить руководителя на среднюю оценку специалистов по.
требованиям вместо 35-й процентили, то оценка бы сократилась на 39 %. Так или иначе, один разговор приводит к весьма существенным различиям.
Руководитель, калибрующий оценку историческими данными, обходит все рассуждения о том, как работают программисты — лучше или хуже среднего. Производительность непосредственно следует из данных. Человеку, ответственному за принятие решений, но не имеющему технического образования, трудно спорить с простыми выкладками типа: «По статистике один человек за месяц у нас выдает от 300 до 450 строк кода; мы откалибровали модель с предположением 400 строк за человеко-месяц. Возможно, это немного оптимистично, но в пределах разумного».
Бесспорно, квалификация половины программистов в отрасли ниже средней. Тем не менее я почти не встречал руководителей проектов или начальников, которые бы согласились признать, что их программисты имеют квалификацию ниже средней.
СОВЕТ № 36 -.
Исторические данные помогают избежать решений, имеющих политическую подоплеку и возникающих из предположений типа «Моя группа ниже среднего».
8.2. Сбор данных.
Если вы еще не занимались сбором исторических данных, начните с очень маленького набора.
• Размер (строки программного кода или другой показатель, который можно получить после выпуска программы).
• Объем работы (человеко-месяцы).
• Время (календарные месяцы).
• Дефекты (с классификацией по степени тяжести).
Эта информация, даж^ собранная по завершении всего двух-трех проектов, даст достаточные основания для калибровки нескольких коммерческих пакетов оценки. Кроме того, по ней можно будет вычислять простые производные показатели, такие как количество строк кода на человеко-месяц.
Наряду с признанием того факта, что этих четырех видов данных достаточно для калибровки моделей оценки, большинство экспертов рекомендует начинать с малого и хорошо разобраться в сути собираемых данных (Pietrasanta 1990, NASA SEL 1995). В противном случае может оказаться, что собранные данные не согласуются между проектами и потому становятся бессмысленными. В зависимости от того, как именно определяются эти четыре показателя, полученные числа могут отличаться в два раза и более.
Проблемы определения размера.
Размер завершенных проектов может измеряться в функциональных пунктах, историях пользователей, веб-страницах, таблицах баз данных и множеством других способов, но большинство организаций в конечном счете предпочитает измерять исторические данные, относящиеся к размеру проектов, в строках программного кода. (Достоинства и недостатки измерения в строках программного кода обсуждаются в разделе 18.1.).
Чтобы вычислить размер проекта в строках кода, необходимо принять решения по нескольким вопросам, в том числе:.
• Учитывать ли весь код, или только код, входящий в выпущенную версию программы? (Например, нужно ли считать временный связующий код, код фиктивных объектов, код модульных тестов и код тестирования системы?).
• Как учитывать код, позаимствованный из предыдущих версий?.
• Как учитывать свободно распространяемый код или код библиотек сторонних производителей?.
• Включать ли в подсчет пустые строки и комментарии?.
• Как учитывать интерфейсы классов?.
• Как учитывать объявления данных?.
• Как подсчитывать одну логическую строку кода, разбитую на несколько физических строк для удобства чтения?.
Никаких отраслевых стандартов на этот счет не существует. Более того, не так уж важно, как именно вы на них ответите
. Важно другое: чтобы вы не меняли принятых решений между проектами, а предположения, заложенные в уже собранные данные, сознательно распространялись на ваши будущие оценки.
Проблемы измерения объема работ.
Аналогичные проблемы возникают при сборе данных по объему работ.
• Как измеряется время — в часах, днях или других единицах?.
• Сколько рабочих часов в день заложено в вычисления? Стандартные 8 часов или фактическое время, действующее в конкретном проекте?.
• Учитывать ли неоплаченные сверхурочные?.
• Учитывать ли выходные, отпуска и время обучения?.
• Учитывать ли время, проведенное на собраниях уровня компании?.
• Какие работы включать в подсчет? Тестирование? Управление первого уровня? Написание документации? Требования? Проектирование? Исследования?.
• Как учитывать время, разделенное между несколькими проектами?.
• Как учитывать время, потраченное на поддержку предыдущих версий той же программы?.
• Как учитывать время, потраченное на общение со службой продаж, на проведение выставок и т. д.?.
• Как учитывать время командировок?.
• Как учитывать нечеткий первоначальный период — время, потраченное на проработку концепции программы до полного определения проекта?.
Как и в предыдущем случае, главной целью должно стать достаточно четкое определение собираемых данных. Представьте, что данные из прошлых проектов содержали большой процент неоплаченных сверхурочных и эти исторические данные используются для оценки будущего проекта. Как вы думаете, что при этом произойдет? Вы сами закладываете в свой будущий проект высокий процент сверхурочных.
Проблемы измерения календарного времени.
Как ни странно, во многих организациях возникают затруднения с определением сроков работы над тем или иным проектом.
• Что следует считать началом работы над проектом? Формальное согласование бюджета? Начало первых обсуждений проекта? Полное комплектование персоналом? Кейперс Джонс сообщает, что четко определенная начальная точка встречается менее чем в 1 % проектов (Jones 1997).
• Когда проект может считаться завершенным? Когда будет собрана окончательная версия? Когда предполагаемая окончательная версия передается на тестирование? А если большинство программистов прекратило работу над проектом за месяц до выхода официальной версии? Джонс сообщает, что в 15 % проектов встречаются неоднозначные сроки завершения (Jones 1997).
В этой области организации сильно пригодятся четкие определениях ключевых точек начала и завершения проекта. Как и в предыдущих случаях, прежде всего следует стремиться к простому пониманию собираемых данных.
Проблемы измерения дефектов.
Наконец, результаты измерения дефектов также могут изменяться в 2-3 раза в зависимости от того, что именно считается дефектом.
• Считаются ли дефектами все запросы на изменения или только те, которые в конечном итоге были отнесены к дефектам (то есть за исключением запросов на внесение новых возможностей)?.
• Как рассматривать разные сообщения об одном дефекте — как один или как несколько дефектов?.
• Учитывать ли дефекты, обнаруженные разработчиками, или только дефекты, обнаруженные при тестировании?.
• Учитывать ли дефекты программирования, обнаруженные до начала альфа- или бета-тестирования?.
• Учитывать ли дефекты, о которых сообщили пользователи после выпуска программы?.
При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показателей, и не изменяйте его между проектами.
Другие проблемы сбора данных.
Исторические данные проще всего собирать во время работы над проектом. Трудно будет вернуться через полгода после завершения проекта и попытаться припомнить «нечеткий первоначальный период», чтобы определить дату начала проекта, сколько приходилось работать сверхурочно в конце проекта и т. д.
СОВЕТ № 38 -.
Собирайте исторические данные как можно раньше после начала проекта.
Данные, собранные в конце проекта, также полезны, но еще полезнее «моментальные снимки», сделанные непосредственно в ходе работы. Статистика по размерам, объему работ и дефектам, собираемая каждые 1-2 недели, способна дать ценную информацию о динамике проекта.
Например, сбор информации о выявленных дефектах помогает прогнозировать частоту обнаружения дефектов и их исправления в будущих проектах. Данные о распределении объема работы по времени помогут понять, в какой степени ваша организация способна мобилизовать персонал на поддержку проекта. Если комплектование персоналом одного проекта происходит медленнее, чем требуется, возможно, это случайное отклонение. Если же исторические данные указывают на то, что три последних проекта комплектовались с одинаковой скоростью, вполне возможно, что вы столкнулись с организационным фактором влияния, который не удастся легко изменить в следующем проекте.
СОВЕТ № 39 -.
Организуйте периодический сбор исторических данных во время работы над проектом. Это позволит вам позднее построить профиль выполнения проекта, базирующийся на собранных данных.
8.3. Способ калибровки.
Конечной целью сбора данных является преобразование данных в модель, которая может использоваться для оценки. Несколько примеров возможных моделей.
• Наши разработчики в среднем выдают X строк кода за человеко-месяц.
• Группа из трех человек может реализовать X историй пользователей за календарный месяц.
• Нашей группе в среднем требуется X человеко-часов на создание сценария использования и Y часов на его конструирование и реализацию.
• Наши специалисты по тестированию в среднем создают тестовый сценарий за X часов.
• В нашей рабочей среде один функциональный пункт обычно реализуется X строками кода на языке C# и Y строками на Python.
• До текущего момента работа по исправлению дефектов в проекте в среднем занимала X часов на дефект.
Эти примеры лишь дают представление о моделях, строящихся по историческим данным. Другие примеры приведены в табл. 7.1 из предыдущей главы.
Общей характеристикой всех моделей является их линейность. Математические формулы работают одинаково в системах как на 10 ООО, так и на 100 ООО строк. Тем не менее из-за эффекта издержек масштаба некоторые модели нуждаются в дополнительной регулировке для разных диапазонов размеров. Разбиение по размерам можно попробовать выполнить на неформальном уровне. В табл. 8.1 показан один из примеров.
Таблица 8.1. Пример неформального учета издержек масштаба (только для демонстрационных целей)
Размер группы
Среднее количество историй пользователя на календарный месяц
1
5
2-3
12
4-5
22
6-7
31
8
Для проектов этого размера данные отсутствуют
Такой подход состоятелен при малых расхождениях в размерах проекта. О том, как учитываются большие расхождения в размерах, рассказано в разделах 5.1 и 5.6.
8.4. Уточнение оценок по данным проекта.
Ранее в этой главе я указывал, что исторические данные полезны тем, что они учитывают влияние организационных факторов — как признанных, так и скрытых. Тот же принцип применим к использованию исторических данных в конкретных проектах (Gilb 1988, Cohn 2006). Отдельные проекты обладают динамикой, несколько отличающейся от динамики организаций. Использование данных из самого проекта учитывает все факторы влияния, уникальные для данного проекта. Чем скорее в проекте вы начнете основывать оценки на данных самого проекта, тем ваши оценки станут по-настоящему точными.
СОВЕТ №40 -.
Используйте данные, полученные в ходе текущего проекта (проектные данные), для создания высокоточных оценок для оставшейся части проекта.
Даже если вы не располагаете историческими данными из прошлых проектов, соберите данные по текущему проекту и используйте их для оценки оставшейся части проекта. Ваша задача — как можно скорее переключиться с организационных или отраслевых данных на проектные. Чем более итеративными будут ваши проекты, тем скорее появится такая возможность.
Сбор и использование данных из ваших проектов более подробно рассматриваются в разделе 16.4. В разделе 12.3 представлен конкретный пример использования проектных данных для уточнения оценок.
8.5. Калибровка средними отраслевыми данными.
Если вы не располагаете собственными историческими данными, особого выбора не остается — используйте средние отраслевые показатели; это приемлемый, хотя и не лучший вариант. Как видно из табл. 5.2, производительность разных организаций в одной отрасли может отличаться на порядок. Средняя производительность не учитывает то обстоятельство, что ваша организация может находиться на верхней или нижней части диапазона.
На рис. 8.1 показан пример оценки, созданной по отраслевым данным. Каждая точка графика представляет возможный результат проекта, созданный с использованием статистического моделирования по методу Монте-Карло. Сплошные черные линии представляют срединные значения объемов работ и сроков, найденные в результате моделирования. Пунктирные черные линии представляют 25-й и 75-й процентили объема работ и сроков.
Рис. 8.1. Пример оценки результатов, откалиброванной по среднеотраслевым данным. Разброс оценок объема работ составляет целый порядок (от 25 до 250 человеко-месяцев).
На рис. 8.2 изображен пример сходной оценки, откалиброванной по историческим данным одного из моих клиентов.
Рис. 8.2. Пример оценки результатов, откалиброваннои по историческим данным. Оценка объема работ расходится всего в 4 раза (от 30 до 120 человеко-месяцев).
Размеры и номинальные производительности в обоих проектах идентичны, но величины разброса в двух оценках кардинально различаются. Из-за того, что среднеотраслевая оценка должна учитывать различия производительности, достигающие целых порядков, среднеквадратическое отклонение для оценок, построенных по таким данным, составило почти 100 %! Если вы хотите предоставить начальству оценку с достоверностью от 25 до 75 % на основании среднеотраслевых данных, вам придется заложить в нее интервал от 50 до 160 человеко-месяцев —троекратные различия!.
Если же заменить среднеотраслевые данные историческими, диапазон оценки составит от 70 до 95 человеко-месяцев — верхняя граница диапазона отличается от нижней в 1,4 раза. Среднеквадратическое отклонение оценки, созданной по историческим данным, составляет лишь около 25 %.
Анализ исследований по точности оценок показал, что в тех случаях, когда оценочная модель не калибровалась по рабочей среде, экспертные оценки давали более точный результат, чем модели. Но при использовании моделей, откалиброванных по историческим данным, выяснялось, что модели дают такой же или лучший результат, чем экспертные оценки (Jorgensen 2002).
СОВЕТ № 41.
Там, где это возможно, используйте для калибровки оценок проектные или исторические данные вместо среднеотраслевых. Помимо повышения точности оценок, исторические данные сокращают разброс оценок, обусловленный неопределенностью предположений по поводу производительности.
8.6. Итоги.
Теперь, когда вы знаете, какими возможностями обладают исторические данные, пренебрегать ими в ваших оценках было бы непростительно. В следующем году, когда вы будете снова перечитывать эту главу, вы уже не должны огорченно повторять: «Как жаль, что у меня нет исторических данных!».
СОВЕТ №42 -.
Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно скорее.

Популярные статьи

Свежие статьи