Стандартизированные процедуры оценки

Стандартизированные процедуры оценки

Область применения методов этой главы
Стандартизированная процедура оценки
Проверка эффективности процедуры оценки
Что оценивается
Размер, объем работ, сроки, функциональность
Размер, объем работ, сроки, функциональность
Размер проекта
М С Б
М С Б
Стадия разработки
Ранняя-поздняя
Ранняя-поздняя
Итеративный или последовательный стиль
Оба
Оба
Возможная точность
Высокая
Высокая
Стандартизированная процедура оценки представляет собой четко определенный процесс создания оценок, принятый на уровне организации и устанавливающий правила на уровне отдельных проектов. Стандартизация защищает от типичных ошибок — таких, как «оценка наобум» и догадки. Она защищает от произвольного изменения оценок только из-за того, что влиятельному участнику проекта не понравился конкретный результат. Она способствует логическому единству процесса оценки. Наконец, в случае особенно неудачной оценки стандартизация позволяет проанализировать свои действия и усовершенствовать процедуру оценки со временем.
Стандартизированные процедуры в равной степени полезны в любых проектах — в крупных и мелких, в итеративных и последовательных, однако специфика изменяется в зависимости от типа проекта.
17.1. Типичные элементы стандартизированной процедуры.
В соответствии с описанием типичной последовательности формирования оценки, приведенным в главе 16, стандартизированная процедура оценки:.
• по возможности базируется на подсчете и вычислениях, а не на субъективных оценках;.
• поощряет применение нескольких альтернативных оценок и сравнение результатов;.
• подразумевает план пересмотра оценки в заранее определенных точках проекта;.
• определяет изменения метода оценки в ходе жизненного цикла проекта;.
• содержит четкое описание неточности оценки;.
• определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта;.
• определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств;.
• требует архивации оценочных данных и анализа эффективности процедуры.
Чтобы стандартизированная процедура оценки справлялась со своими задачами, очень важно, чтобы организация рассматривала процедуру как стандарт. Отклонения от процедуры должны объясняться в письменном виде, и такие случаи должны быть редкими.
Сама процедура должна быть описана в документе «Стандарты разработки программного обеспечения» или «Стандартизированная процедура оценки» и в дальнейшем подвергаться формальному контролю изменений. В конце проекта в процедуру могут вноситься изменения с целью повышения ее точности в будущих проектах. Изменения «на ходу» недопустимы — они слишком подвержены смещениям, подрывающим как точность оценки в конкретном случае, так и эффективность процедуры в будущих проектах.
СОВЕТ № 77 -.
Определите стандартизированную процедуру оценки на уровне организации и применяйте ее на уровне отдельных проектов.
17.2. Адаптация оценки для процесса поэтапного контроля.
Во многих крупных организациях используется определенный жизненный цикл разработки программного обеспечения (SDLC, Software Development Life Cycle). Такие жизненные циклы обычно являются частью процессов поэтапного контроля — процессов, определяющих жизненный цикл продуктов в виде нескольких.
«этапов» и «контрольных точек» (Cooper 2001). К числу компаний, использующих процессы поэтапного контроля, относятся ЗМ, Agilent, Corning, Exxon, GE, Guinness, Hewlett-Packard, Intel, Kodak, Proctor & Gamble и многие другие.
На рис. 17.1 показан типичный процесс поэтапного контроля.
Контрольная 12 3 4 5.
точка.
Рис. 17.1. Типичный процесс поэтапного контроля разработки программного продукта.
Процесс SDLC определяет операции по разработке программного обеспечения, обычно выполняемые на каждом этапе. Кроме того, он определяет критерии выхода, на основании которых проекту разрешается завершить один этап и перейти к следующему (то есть сместиться к следующей контрольной точке). Специфика процесса SDLC сильно зависит от организации. В табл. 17.1 показано, как SDLC координируется с типичным процессом поэтапного контроля, ориентированным на программный продукт.
Таблица 17.1. Типичный процесс поэтапного контроля, ориентированный на программный продукт (сокращенный вариант)
Этап
Основные операции
Контрольная.
точка
Основной критерий выхода
0. Обнаружение
• Выявление рыночной возможности.
• Оценка технической приемлемости на высоком уровне.
• Разработка предварительной экономической модели
1
• Согласование предварительной экономической модели
1. Анализ требований
• Формирование концепции продукта.
• Разработка рыночных требований.
• Согласование концепции с потребителями
2
• Согласование концепции продукта.
• Согласование маркетинговых требований
2. Планирование
• Разработка подробных требований.
• Разработка подробных планов.
• Разработка оценки бюджета.
• Разработка окончательной экономической модели
3
• Согласование планов разработки программного продукта.
• Согласование бюджета.
• Согласование окончательной экономической модели
Таблица 17.1 (продолжение)
Этап
Основные операции
Контрольная.
точка
Основной критерий выхода
3. Разработка
• Основной жизненный цикл разработки продукта.
• Разработка маркетингового и оперативного планов.
• Разработка окончательного плана тестирования
4
• Согласование плана выпуска программного продукта.
• Согласование маркетингового.
и оперативного планов.
• Согласование плана тестирования программного продукта
4. Тестирование и контроль готовности
• Исполнение окончательного плана тестирования.
• Принятие решения о выпуске
5
• Выполнение критериев выпуска
5. Запуск
• Исполнение плана развертывания.
• Проведение ретроспективного анализа проекта.
• Сбор мнения клиентов.
и сообщений о дефектах.
• Отслеживание экономических результатов
С точки зрения оценки, поэтапный контроль создает некоторые проблемы, но и открывает ряд возможностей. Проблемы обусловлены тем фактом, что многие процессы поэтапного контроля изначально разрабатывались для оборудования, потребительских или других продуктов, не имеющих отношения к программам. Хотя основная структура таких процессов остается полезной, ее приходится адаптировать к специфике программного обеспечения, чтобы она работала с такой же эффективностью, как и при разработке других видов продуктов.
Одна из стандартных проблем заключается в том, что разработка часто представляется в виде одного этапа (этап 3 в табл. 17.1). Операции, выполняемые в процессе разработки, занимают от 75 до 90 % общего объема работы программного проекта, и в общем случае я бы предпочел видеть на этом этапе несколько промежуточных контрольных точек вместо одной точки, обозначающей конец этапа. Это одна из ситуаций, в которых следует периодически пересматривать оценки во время этапа. Тем самым обеспечивается эффективное планирование и управление проектом независимо от того, как относится организация к пересмотру оценок на в середине этапа.
Вторая стандартная проблема: этапы анализа требований и планирования, определенные в табл. 17.1, часто объединяются в один этап. Фактически это означает, что контрольная точка 3 находится в фазе сужения конуса неопределенности до ±25 %, что может происходить когда угодно от 15 до 35 % календарного времени проекта (эти процентные показатели более подробно рассматриваются в главе 21). Участникам проекта, не связанным с технической стороной, часто приходится объяснять, какие операции по разработке программного обеспечения должны быть завершены для получения осмысленного представления о «контрольной точке № 3». Количество и глубина таких операций часто превышают ожидания.
Но когда «не технические» участники проекта получат представление о связи между процессом поэтапного контроля и жизненным циклом программного продукта, процесс SDLC обеспечит мощную поддержку для стандартизированных процедур оценки. Привязка диапазонов оценки к различным контрольным точкам выглядит естественно и помогает регламентировать концепцию неопределенности оценки.
В табл. 17.2 показан пример соответствия между диапазонами оценки и процессами SDLC.
Таблица 17.2. Типичное соответствие между контрольными точками SDLC и оценками
Контрольная точка SDLC
Точность оценки (для оставшейся части проекта)
Использование оценки
1
-75 %, +300 %
Оценка общего представления. Предназначена исключительно для внутреннего использования; не публикуется за пределами группы разработки
2
-50 %, +100 %
Исследовательская оценка.
Для внутреннего использования в границах компании; не публикуется за ее пределами
3
-20 %, +25 %
Бюджетная оценка. Допускается внешняя публикация верхней границы диапазона. Нижняя граница и среднее значение не публикуются
4
-10 %, +10 %
Оценка окончательных обязательств. Допускается внешняя публикация среднего значения
СОВЕТ № 78 -.
Координируйте стандартизированную процедуру оценки с процессом SDLC, принятым в вашей организации.
В двух следующих разделах представлены примеры стандартизированных процедур оценки. В разделе 17.3 описан пример процедуры, используемой в последовательных проектах, а в разделе 17.4 — пример процедуры для итеративных проектов.
17.3. Пример стандартизированной процедуры оценки для последовательных проектов.
В табл. 17.3 приведен пример стандартизированной процедуры оценки, которая может применяться в последовательных программных проектах. Процедура оценки предполагает, что главным приоритетом организации является функциональность,.
а основная цель оценки заключается в повышении точности оценок стоимости и сроков.
Таблица 17.3. Пример стандартизированной процедуры оценки для последовательных проектов — с упором на оценку стоимости и сроков.
I.
Исследовательская оценка (согласованное определение продукта).
A.
Создайте как минимум одну оценку, используя каждый из перечисленных методов.
1.
Один оценщик применяет восходящий метод по структуре трудозатрат (WBS).
2.
Один оценщик применяет метод стандартных компонентов.
3.
Один оценщик применяет нисходящий метод и оценку по аналогии с похожими прошлыми проектами.
Б. Оценщики применяют широкополосный Дельфийский метод и вырабатывают точечную номинальную оценку (N).
B.
Оценки всегда должны выдаваться в виде диапазонов 0,5N-2,0N (например, -50 %, +100 %).
1.
Точечная номинальная оценка, разработанная для использования в этих вычислениях, не публикуется.
2.
Полученные оценки не должны использоваться для формирования бюджета и внешних обязательств, кроме согласования бюджета с целью завершения стадии проектирования продукта.
II.
Бюджетная оценка (завершение проектирования продукта).
A.
Создайте новые оценки, используя два метода из этапа I.
1.
Восходящий метод по структуре трудозатрат (WBS).
2.
Метод стандартных компонентов.
Б. Создайте оценку методом функциональных пунктов.
1.
Вычислите функциональные пункты по спецификации требований.
2.
Откалибруйте оценочную программу по историческим данным своей организации.
3.
Оцените номинальный объем работ и сроки с использованием коммерческого оценочного программного пакета.
B.
Проводите итеративный пересмотр оценок II.A(l), И.А(2) и И.Б до тех пор, пока не будет достигнуто схождение оценок в пределах 5 %. Используйте среднюю величину оценки как номинал N.
Г. Вычислите диапазонную оценку 0,8N-1,25N.
1.
Бюджет определяется на основе показателя 1.0N.
2.
Резерв на непредвиденные расходы определяется на основе показателя 0,25N.
3.
Возможно выделение дополнительного резерва на основании исторических данных роста требований в данной организации.
4.
Публикуется только верхняя граница диапазона (1,25N).
5.
Оценка не должна использоваться во внешних обязательствах.
III.
Оценка предварительных обязательств (после второй внутренней версии).
А. Постройте восходящую оценку.
1. Создайте подробный список задач.
(а) Список задач должен быть согласован с руководителями разработки, тестирования и подготовки документации.
2.
Поручите каждому разработчику, специалисту по тестированию и другим участникам проекта оценить объем работ, необходимых для реализации требований, за которые он отвечает.
(а) Модули должны оцениваться по лучшему, худшему и ожидаемому случаю.
(б) Номинальные оценки модулей вычисляются по формуле [ЛучшийСлучай +.
(4 х ОжидаемыйСлучай) + ХудшийСлучай)/6.
3.
Просуммируйте номинальные оценки отдельных модулей.
Б. Сравните оценку II.Г с III.А(3). Вычислите номинальную оценку N по следующей формуле:.
(2 х БолыиаяОценка + МеньшаяОценка)/3.
В. Вычислите диапазонную оценку 1,0N-1,1N.
1.
Верхняя граница диапазона (1,1N) может использоваться во внешних публикациях.
2.
Внешние обязательства принимаются по оценке 1,1N.
3.
Диапазон 1,014-1,1N может использоваться во внутренних публикациях.
IV.
Оценка окончательных обязательств (после третьей внутренней версии).
А. Сравните оценку с фактическими результатами, полученными на этапе III.
1.
Вычислите заново пересмотренное номинальное значение по формуле: ОставшийсяОбъемРабот = ЗапланированныйОстатокДФактическийПредшествующийОбъем/ ЗапланированныйПредшествующийОбъем).
2.
Добавьте все задачи, не учтенные на шаге III.
Б. Сумма IV.А. 1 и IV.A.2 может использоваться в качестве нового номинального объема работ, N.
1.
Номинал (1,0N) может использоваться во внешних публикациях.
2.
Внешние обязательства могут делаться по оценке 1,0N.
3.
Диапазон 0,9N-1,1N может использоваться во внутренних публикациях.
V.
Оценка проекта может пересматриваться в любой момент в ответ на значительные изменения в проектных предпосылках.
А. Изменения в предпосылках включают в себя (хотя и не ограничиваются) расширение требований, изменения в определениях основных требований, изменения в доступности персонала и изменения в целевых сроках.
VI.
Завершение проекта.
А. Соберите и заархивируйте данные по фактическим результатам проекта для использования в будущем.
Б. Проанализируйте точность каждой оценки.
1.
Проанализируйте глубинные причины всех основных ошибок.
2.
Решите, можно ли было достичь той же точности с меньшими усилиями.
3.
Предложите изменения в стандартизированной процедуре оценки.
Процедура оценки, показанная в табл. 17.3, содержит все элементы, обычно присутствующие в подобных процедурах. Она:.
• по возможности базируется на подсчете и вычислениях, а не на субъективных оценках. Вычисление исследовательской оценки (оценка I в табл. 17.3) требует применения декомпозиции со структурой трудозатрат, оценки по аналогии и метода стандартных компонентов. Ни один из этих методов не обладает выдающейся точностью, но каждый из них по крайней мере не ограничивается субъективным суждением и сопряжен с определенными вычислениями;.
• поощряет применение нескольких альтернативных оценок и сравнение результатов. В первых трех оценках (I, II и III) задействован метод сравнения альтернативных оценок. Альтернативные методы обычно используются на ранней стадии проекта, когда возможности применения вычислительных методов еще ограничены;.
• подразумевает план пересмотра оценки в заранее определенных точках проекта. В плане задействованы оценки с I по V, что указывает на намерение периодического пересмотра оценок. Каждая оценка связывается с определенными контрольными точками в проекте;.
• определяет изменения метода оценки в ходе жизненного цикла проекта.
Шаги отличаются друг от друга и базируются на совершенствующихся данных, которые были получены в ходе проекта и становятся доступными на более поздних этапах. Ближе к концу проекта его исторические данные становятся основным материалом для формирования оценок;.
• содержит четкое описание неточности оценки. В каждом этапе процедуры заложено выражение неточности оценки. Скажем, оценка I.B требует диапазона -50 %, +100, а в оценке IV.B неточность сужается до ±10 %;.
• определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта. Оценка II названа «бюджетной оценкой». В описании оценки I явно указано, что она не может использоваться в качестве основы для формирования бюджета;.
• определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств. Оценка III называется «оценкой предварительных обязательств», а оценка IV — «оценкой окончательных обязательств». В описаниях более ранних оценок явно указано, что они не могут использоваться в качестве основы для принятия внешних обязательств.
17.4. Пример стандартизированной процедуры оценки для итеративных проектов.
В табл. 17.3 приведен пример стандартизированной процедуры оценки, адаптированной для итеративных программных проектов. Такие процедуры обычно работают с наибольшей эффективностью в организациях с годичным бюджетным циклом. Бюджет фиксируется в начале цикла; это означает, что укомплектованность штата тоже фиксируется. Следовательно, подобные оценки не должны быть направлены ни на оценку стоимости (которая фиксируется бюджетом), ни на оценку сроков (которые для годичных бюджетных циклов составляют один год). Задача оценщика — оценить объем функциональности, которая может быть реализована с фиксированным штатом за фиксированный промежуток времени.
Процедура, описанная в табл. 17.4, предполагает, что итерации находятся под правильным управлением — каждая итерация доводится до уровня качества, обеспечивающего возможность выпуска версии, при выходе каждой версии выполняется необходимая «зачистка», отставания от графика не накапливаются и т. д.
Таблица 17.4. Пример стандартизированной процедуры оценки для итеративных проектов — с упором на оценку функциональности.
I.
Исследовательская оценка (для планирования первой итерации).
А. Запланированная функциональность оценивается с применением абстрактных рейтингов.
Б. Первая итерация планируется с использованием исторических данных организации.
1.
Длина итерации не должна превышать одного месяца.
2.
Оценка для всего проекта не создается.
3.
Никакие обязательства не принимаются.
II.
Плановая оценка (планирование второй и третьей итераций).
A.
Вычислите среднее количество абстрактных пунктов на человеко-неделю (для калибровки объема работ).
Б. Вычислите среднее количество абстрактных пунктов на календарную неделю (для калибровки сроков).
B.
Данные И.А и И.В используются для планирования второй и третьей итераций.
1.
Длина итерации не должна превышать одного месяца.
2.
Номинальная оценка всего проекта (N) составляется в форме абстрактных пунктов, которые могут быть реализованы при заданном периоде времени и численности штата.
(а) Оценка может использоваться во внутренних публикациях в виде диапазона 0,75N-1,0N.
(б) Оценка не должна использоваться во внешних публикациях.
(в) Никакие обязательства не принимаются.
III.
Оценка для формирования обязательств (после третьей итерации).
A.
Вычислите среднее количество абстрактных пунктов на человеко-неделю по данным первых трех итераций (для калибровки объема работ).
Б. Вычислите среднее количество абстрактных пунктов на календарную неделю по данным первых трех итераций (для калибровки сроков).
B.
Данные III.A и Ш.Б используются для планирования оставшейся части проекта.
1. Номинальная оценка всего проекта (N) составляется в форме абстрактных пунктов, которые могут быть реализованы при заданном периоде времени и численности штата.
(а) Оценка может использоваться во внутренних публикациях в виде диапазона 0,9N-1,1N.
(б) Во внешних публикациях оценка может использоваться в виде диапазона 0,9N-1,0N.
(в) Обязательства принимаются на основе диапазона 0,9N-1,0N.
IV.
Оценка проекта может пересматриваться в любой момент в ответ на значительные изменения в проектных предпосылках.
А. Как минимум калибровка оценок проекта должна обновляться после каждой третьей итерации с учетом изменений в комплектации штата, повышения производительности и других факторов.
V.
Завершение проекта.
А. Соберите и заархивируйте данные по фактическим результатам проекта для использования в будущем.
7 Зак. 893.
Б. Проанализируйте точность каждой оценки.
1.
Проанализируйте глубинные причины всех основных ошибок.
2.
Решите, можно ли было достичь той же точности с меньшими усилиями.
3.
Предложите изменения в стандартизированной процедуре оценки.
Процедура оценки, показанная в табл. 17.4, содержит многие элементы, обычно присутствующие в подобных процедурах. Она:.
• по возможности базируется на подсчете и вычислениях, а не на субъективных оценках. В оценке II задействованы фактические данные, и дальнейшие оценки вычисляются на основании исторических данных проекта;.
• поощряет применение нескольких альтернативных оценок и сравнение результатов. Данная процедура не требует альтернативных оценок. Впрочем, если вы решили использовать эту процедуру, но считаете, что исторические пункты не обеспечивают достаточной точности прогноза, измените процедуру и включите в нее дополнительные методы оценки;.
• подразумевает план пересмотра оценки в заранее определенных точках проекта. В планировании задействованы оценки I—III, что указывает на намерение производить периодический пересмотр оценок;.
• определяет изменения метода оценки в ходе жизненного цикла проекта.
Как и в случае с последовательной процедурой, все этапы процедуры отличаются друг от друга на основании исторических данных, сгенерированных проектом;.
• содержит четкое описание неточности оценки. В оценке I просто сказано, что оценка всего проекта не производится, а оценка II обеспечивает диапазон неопределенности от 75 до 100 % предполагаемой функциональности;.
• определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта. В данном случае финансовый бюджет фиксирован;.
• определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств. Оценка III называется « оценкой для формирования обязательств». В описаниях более ранних оценок явно сказано, что они не могут использоваться для принятия внешних обязательств.
17.5. Пример стандартизированной процедуры оценки от прогрессивной организации.
В табл. 17.5 описана процедура оценки, используемая лабораторией разработки программного обеспечения NASA (NASA SEL), одной из самых передовых организаций по разработке программного обеспечения.
17.5. Пример процедуры оценки от прогрессивной организации 195 Таблица 17.5. Процедура оценки NASA SEL
Входные
Выходные данные
данные.
Фаза проекта
Входные данные для оценки
Оценка.
размера
Оценка объема работ
Оценка срока
Диапазон.
неопреде¬.
ленности
5
Завершение.
анализа.
требований
Количество подсистем
11 ООО строк кода
6
3000 часов на подсистему
Количество подсистем умножается на 83 недели и делится на численность персонала
+75 % -43 %
Завершение.
предварительного.
проектирования
Количество модулей (функций и/или подпрограмм)
190 строк кода на модуль
52 часа на модуль
Количество модулей умножается на 1,45 недели и делится на численность персонала
+40 % -29 %
Завершение.
подробного.
проектирования
Количество новых и существенно измененных модулей (N).
Количество переработанных и незначительно измененных модулей (R)
Строки кода = 200 х х (N + 0,2R)
0,31 часа на строку кода
Количество строк кода умножается на 0,0087 недели и делится на численность персонала
+25 % -20 %
Завершение.
реализации
Текущий размер в строках кода.
Объем работы, выполненной до настоящего момента.
Время,затраченное до настоящего момента
Текущий размер увеличивается на 26 %.
(с учетом тестирования)
Объем выполненной работы увеличивается на 43 % (с учетом работы по завершению)
Затраченное время увеличивается на 54 %
+10 % -9%
Завершение.
тестирования.
системы
Общий объем выполненной работы
Окончательный размер программного проекта становится известным
Объем выполненной работы увеличивается на 13 % (с учетом работы по завершению)
Затраченное время увеличивается на 18 %
+5%.
-5%
Источник: Адаптировано по материалам «Manager’s Handbook for Software Development», Revision 1 (NASA SEL 1990).
Самая замечательная особенность процедуры оценки NASA SEL заключается в том, что она требует меньшей работы для создания более точных оценок. Это характерно для общего правила: чем более изощренными становятся ваши оценки, тем меньше усилий требуется для создания точных оценок.
Конкретные числа в этой процедуре относятся к специфике NASA SEL. Они были откалиброваны за несколько десятилетий сбора и анализа данных и характерны для высокоразвитых организаций, занимающихся разработкой программного обеспечения. Для других организаций они не подходят.
Отличия от процедур, которые могут использоваться менее развитыми организациями, весьма поучительны. Впрочем, существует и определенное сходство. Процедура NASA SEL:.
• по возможности базируется на подсчете и вычислениях, а не на субъективных оценках. Процедура NASA SEL интересна тем, что даже ранние проектные оценки базируются на подсчетах и вычислениях. Объем работ и сроки никогда не оцениваются напрямую;.
• поощряет применение нескольких альтернативных оценок и сравнение результатов. Данная процедура не требует одновременного применения нескольких альтернативных методов в любой момент времени. Лаборатория NASA SEL достаточно долго собирала и анализировала исторические данные, что позволяет ей составлять точные оценки с малыми усилиями;.
• подразумевает план пересмотра оценки в заранее определенных точках проекта. В табл. 17.5 отмечены точки проекта, в которых создаются новые оценки;.
• определяет изменения метода оценки в ходе жизненного цикла проекта.
Каждая строка таблицы представляет отдельный метод оценки для конкретной точки жизненного цикла проекта;.
• содержит четкое описание неточности оценки. В крайнем правом столбце содержатся величины поправок номинальной оценки. Первая сноска содержит хорошую общую рекомендацию: «...консервативные принципы управления рекомендуют использовать оценки, лежащие между прогнозируемым значением и верхней границей»;.
• определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта. В данном случае этот элемент не выражен;.
• определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств. Эти элементы не выражены в процедуре напрямую. Обратите внимание: первая строка таблицы относится к «завершению анализа требований». В терминологии NASA SEL «анализом требований» называется операция, выполняемая после «постановки требований». Таким образом, из таблицы следует, что первая оценка проекта может строиться в относительно широкой части конуса неопределенности.
17.6. Улучшение стандартизированной процедуры.
Если процедура оценки создавалась специально для конкретного случая, оценку трудно усовершенствовать, потому что вы никогда не знаете точно, какой из аспектов оценки привел к появлению неточности. При использовании стандартизированных процедур вам точно известно, каким образом строилась каждая оценка; это поможет в будущем повторить удачи и избежать неудач.
После каждого проекта эффективность оценок анализируется по нескольким направлениям.
• Насколько точными были ваши оценки? Входил ли окончательный результат во все диапазоны (см. раздел 16.6)?.
• Достаточно ли широкими были ваши диапазоны? Нельзя ли было их сузить, не утрачивая выявленной изменчивости?.
• В какую сторону обычно смещались ваши оценки — завышения или занижения? Или смещения не было и оценки были нейтральными?.
• Какие источники стали причиной искажения оценки?.
• Какими методами были получены самые точные оценки? Действительно ли эти методы обеспечивают самые точные оценки, или они просто случайно обеспечивали лучшую оценку в данном случае?.
• Правильно ли было выбрано время для пересмотра оценок? Сколько было пересмотров — слишком много, слишком мало, в самый раз?.
• Был ли процесс оценки более сложным, чем требовалось? Нельзя ли упростить его без потери точности?.
СОВЕТ № 79 -.
Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повысить точность оценок и свести к минимуму затраты на их создание.