Вычисление ожидаемого случая

Сцена: Еженедельное собрание группы...

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

Группа: По рукам!

Вы: Ладно, начинаем.

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

Тем временем ваши коллеги создали более подробную оценку с разбиением на функции. У них получилась оценка, показанная в табл. 10.1.

Таблица 10.1. Пример оценки, полученной посредством декомпозиции Функция              Оценка времени реализации (в человеко-неделях)

Вы: 27 недель? Ого. По-моему, многовато, но это скоро выяснится... Несколько недель спустя...

Вы: Теперь, когда проект завершен, мы знаем, что он занял 29 человеко-недель. Похоже, ваша оценка в 27 человеко-недель оказалась оптимистичной на 2 недели, то есть ошибка составила 7 %. Моя оценка в 22 человеко-недели смещена на 7 человеко-недель, ошибка 24 %. Похоже, вы выиграли, и я покупаю пиццу.

Кстати говоря, я хочу знать, из-за кого я «попал» на пиццу.

Несколько минут уходит на то, чтобы проанализировать величины относительной ошибки по всем оценкам и выписать данные на доску. Результат показан в табл. 10.2.

Группа: Ого, как интересно. Большинство наших индивидуальных оценок не были точнее вашей — почти все они содержали ошибку от 30 до 50 %. Наша сред- няя ошибка составляла 46 %, что гораздо больше, чем у вас. И все же наша общая ошибка составила всего 7 %, а ваша — 24 %.

Однако договор дороже денег. Хотя наши оценки были хуже вашей, пицца все равно с вас!

Таблица 10.2. Примеры результатов оценок, полученных посредством декомпозиции

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

Закон больших чисел

Оценка группы выиграла от статистического свойства, называемого законом больших чисел.

Такой подход должен работать в теории, и исследования говорят о том. что он также работает на практике. Ледерер и Прасад обнаружили, что суммирование продолжительности подзадач отрицательно коррелнруется с превышениями сроков и объемов работ (Lederer and Prasad 1992).

СОВЕТ № 47

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

Насколько мелкими должны быть оцениваемые фрагменты?

Ktvni взглянуть на ситуацию с точки зрения рис. 10.1, разработка программного обеспечения представляет собой постепенное сокращение масштаба лритшае- мых решений. В начале проекта вы принимаете решення типа: «Какие основные

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

‘т г4              1                            1

Требования высокого уровня —              I

дополнительные решения с высоким воздействием ^Концепция программного продукта —

Несколько решений с чрезвычайно высоким воздействием

Время

Рис.

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

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

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