Представьте, что вы попали на конференцию лучших оценщиков. Зал заполнен людьми; вы сидите за столом в середине комнаты с тремя другими специалистами. Куда ни глянь, кругом одни оценщики. Внезапно распорядитель подходит к микрофону и говорит: «Нам нужно точно знать, сколько людей находится в зале, чтобы заказать десерт. Кто даст самую точную оценку количества собравшихся?».

За столом немедленно завязывается оживленная дискуссия по поводу того, как лучше всего получить оценку. Билл, ваш сосед справа, говорит: «Оценка размера толпы — мое хобби. На основании своего опыта могу сказать, что в комнате находится 335 людей».

Сосед напротив, Карл, говорит: «Столы расставлены равномерно, 11 в длину и 7 в ширину. Организатор банкета — мой хороший знакомый — сказал, что они собираются усадить по 5 людей за один стол. Кажется, за большинством столов сейчас действительно сидит по 5 человек. Умножаем 11 на 7, затем умножаем на 5 и получаем 385 человек. Пожалуй, это значение можно использовать как оценку».

Сосед слева, Люси, говорит: «При входе я заметила табличку, на которой написано, что зал рассчитан на 485 человек. Сейчас зал заполнен процентов на 70-80. Если умножить проценты на максимальную емкость, мы получаем от 340 до 388 человек. Давайте используем среднее — 364 человека... или 365 для надежности?».

Билл: «Итак, мы имеем оценки 335, 365 и 385. Похоже, истина где-то посередине. Согласен на 365».

«Я тоже», — говорит Карл.

Все смотрят на вас. Вы говорите: «Мне нужно кое-что проверить. Я ненадолго отлучусь, вы не возражаете?» Соседи удивлены, но не возражают.

Вы возвращаетесь через пару минут. «Помните, при входе наши приглашения обрабатывались на сканере? Я заметил, что на сканере есть счетчик, поэтому подошел к контролеру у входа. Контролер говорит, что было отсканировано 407 билетов, и из зала еще никто не выходил. Полагаю, в качестве оценки нужно использовать число 407. Что скажете?».

7.1. Сначала подсчет.

Как вы думаете, каков правильный ответ? 335, как предложил Билл, эксперт по оценке размера толпы? 385, как вычислил Карл по нескольким разумным предположенйям? 365, как вычислила Люси по другим разумным предположениям? Или правильным было число 407, отображающееся на сканере приглашений? Есть ли какие-нибудь сомнения относительно того, что 407 является наиболее точным ответом? Кстати, вся история кончилась тем, что ваш стол предложил число 407, которое оказалось правильным, и первым получил десерт.

Один из секретов этой книги состоит в том, что в,ы должны по возможности избегать того, что мы обычно называем оценкой! Если ответ можно просто посчитать, действуйте именно так. В нашей истории этот способ дал наиболее точный ответ.

Если прямой подсчет невозможен, нужно посчитать что-нибудь другое и вычислить ответ по вспомогательным (калибровочным) данным. Скажем, Карлу было известно, что на банкете за каждым столом должно было сидеть 5 человек. Он подсчитал количество столов и вычислил ответ по этому значению.

Люси действовала сходным образом: ее оценка основывалась на документированной вместительности зала. На основании своего экспертного суждения она прикинула, что зал заполнен *на 70-80 % процентов.

Наименее точная оценка поступила от Билла, который руководствовался только своим экспертным суждением для получения ответа.

СОВЕТ № 30 -.

Считайте везде, где это возможно. Если счет невозможен — вычисляйте. Используйте оценки, полученные на основании одного лишь экспертного суждения, только в крайнем случае.

7.2. Что считать.

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

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

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

Выбор показателя для подсчета определяется несколькими целями.

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

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

СОВЕТ №31 -=-.

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

Ищите счетный показатель, доступный на ранней, а не на поздней стадии цикла разработки. Чем скорее вы найдете осмысленный показатель для подсчета, тем скорее сможете обеспечить долгосрочную прогнозируемость. Количество строк программного кода в проекте часто является отличным показателем объема работы, однако этот показатель становится доступным лишь после завершения проекта. Функциональные пункты тесно связаны с окончательным размером проекта, но они остаются недоступными вплоть до появления подробных требований. Если вам удастся найти счетный показатель, доступный на более ранней стадии, используйте его для создания более ранней оценки. Например, можно создать грубую оценку на основании числа маркетинговых требований, а затем уточнить ее позднее по количеству функциональных пунктов.

Ищите счетный показатель, дающий статистически осмысленное среднее значение. С точки зрения статистики для получения осмысленного среднего значения выборка должна содержать не менее 20 элементов. Здесь 20 — не волшебное число, а всего лишь хорошая рекомендация для статической состоятельности.

Понимайте, что вы считаете. Чтобы подсчет мог послужить точной основой для оценки, необходимо проследить за тем, чтобы на них распространялись те же предположения, что и для исторических данных, используемых в оценке. Если вы считаете маркетинговые требования, убедитесь в том, что понимание «маркетинговых требований», действовавшее в отношении исторических данных, совпадает с пониманием «маркетинговых требований» в вашей оценки. Если исторические данные показывают, что в предыдущем проекте группа обрабатывала 7 неформальных требований заказчика (также называемых « историями пользователей», user story) в неделю, проследите за тем, что ваши предположения относительно размера группы, опыта программистов, технологии разработки и других факторов аналогичны предположениям в оцениваемом проекте.

4 Зак. 893.

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

Один из выводов проекта Cocomo II заключается в том, что метрика оценки размера, называемая объектными пунктами, в такой же степени коррелируется с объемом работ, что и функциональные пункты, но ее вычисление требует примерно половинного объема работы. По этой причине объектные пункты рассматриваются как эффективная альтернатива для функциональных пунктов при проведении оценки в широкой части конуса неопределенности (Boehm et al. 2000).

7.3. Используйте вычисления для преобразования счетных показателей в оценки.

Собранные исторические данные, относящиеся к счетным показателям, преобразуются в нечто более полезное — например, оценку объема работы. В табл. 7.1 приведены примеры счетных показателей и данных, необходимых для вычисления по ним оценки.

Таблица 7.1. Примеры счетных показателей

СОВЕТ № 32.

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

Пример подсчета дефектов на поздней стадии проекта. Данные, описанные в таблице, закладывают более прочную основу для создания оценок, нежели экспертное суждение. Если вы знаете, что проект содержит 400 открытых дефектов, а при исправлении 250 дефектов, обнаруженных ранее, потребовалось по 2 часа.

на дефект, значит, на исправление всех открытых дефектов потребуется примерно 400 х 2 = 800 часов.

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

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

СОВЕТ № 33 -.

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

7.4. Используйте экспертное суждение только в крайнем случае.

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

Исторические данные в сочетании с вычислениями оказываются на удивление свободными от смещений, подрывающих оценки, основанные на экспертных мнениях. Не поддавайтесь искушению подстраивать вычисленные оценки под свое экспертное суждение. Во время работы над вторым изданием книги «Code Complete» (McConnell 2004а) я руководил группой, проводившей формальный анализ первого издания — всех 900 страниц. Во время нашей первой встречи средняя скорость анализа составила 3 минуты на страницу. Выходило, что при такой скорости на анализ всей книги уйдет 45 часов. После первой встречи я заметил, что мы еще только «срабатываемся» как единая команда, а в будущем, как мне кажется, скорость должна возрасти. При планировании будущих встреч я порекомендовал использовать рабочую оценку в 2-2,5 минуты на страницу вместо 3 минут. Руководитель проекта ответил, что на данный момент мы располагаем данными только одной встречи, поэтому за основу нескольких будущих встреч нужно взять имеющиеся показатели, то есть 3 минуты на страницу. Позднее при.

необходимости планы можно будет подрегулировать на основании данных последующих собраний.

И как вы думаете, каким оказалось среднее время после завершения книги, всех 900 страниц? Вы не ошиблись, 3 минуты на страницу!.

СОВЕТ № 34 -.

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