Диапазоны (любого типа)
В книге уже неоднократно говорилось о том, что диапазоны позволяют наиболее адекватно отразить неточность, изначально заложенную в разных точках конуса неопределенности. Диапазоны объединяются с другими приемами, описанными в этой главе (то есть диапазоны в грубых периодах времени, диапазоны с квантификацией рисков и т.
д.).Представляя оценку в виде диапазона, попробуйте ответить на следующие вопросы. Какой уровень вероятности должен быть включен в диапазон? Ограничиться ли ±1 стандартным отклонением (68 % возможных исходов), или диапазон должен быть шире? Как диапазоны воспринимаются бюджетными и отчетными процессами вашей компании? Учтите, что во многих компаниях бюджетные и отчетные процессы отказываются принимать диапазоны, и последние часто упрощаются по причинам, никак не связанным с оценкой программного обеспечения, например: «Бюджетная электронная таблица нашей компании не позволяет вводить диапазоны». Принимайте во внимание ограничения, которым приходится подчиняться вашему руководству. Устроит ли вас средняя точка диапазона? Иногда руководство упрощает диапазоны, публикуя их нижнюю границу. Однако чаще при невозможности использования диапазона вычисляется средняя точка, которая используется в качестве оценки. Нужно ли представлять весь диапазон или только часть диапазона от номинальной оценки до верхней границы? Проекты со временем чаще увеличиваются, чем уменьшаются, и оценки обычно ошибаются в нижнюю сторону. Нужно ли представлять полный диапазон оценки от нижней до верхней границы или можно представить только часть диапазона от номинала до верхней границы? Нельзя ли объединить диапазоны с другими приемами представления оценок? Подумайте о том, чтобы представить оценку в диапазонном виде, а затем привести список предположений или воспользоваться квантификацией рисков.
СОВЕТ № 108
Используйте стиль представления оценок, который бы подчеркивал передаваемую вами информацию о точности оценки.
Полезность диапазонного представления оценок
Возможно, кто-то из руководства решит, что представление оценки в виде широкого диапазона делает ее бесполезной. На самом деле происходит другое: представление оценки в виде широкого диапазона точно передает бесполезность оценки! Не представление делает оценку бесполезной, а неопределенность, заложенная в самой оценке. Невозможно исключить неопределенность из оценки, представляя ее без неопределенности. Тем самым вы лишь игнорируете неопределенность, но это лишь обернется всем во вред.
Два крупнейших профессиональных сообщества разработчиков программного обеспечения — IEEE Computer Society и Association of Computing Machinery — совместно решили, что включение неопределенности в оценку относится к числу профессиональных обязанностей разработчиков. Статья 3.9 этического кодекса разработчика IEEE-CS/ACM гласит:
«Разработчики должны следить за тем, чтобы их продукты и модификации соответствовали высочайшим профессиональным стандартам. В частности, разработчики обязаны по обстоятельствам:
3.09 Обеспечивать реалистичную количественную оценку стоимости, сроков, персонала, качества и результатов всех проектов, в которых огш работают или собираются работать, и обеспечить анализ неопределенности в таких оценках», (выделено автором).
Иначе говоря, включение неопределенности в оценку — это не любезность, а этическая ответственность разработчика.
Диапазоны и обязательства
Когда руководство сопротивляется принятию диапазонных оценок, иногда оно на самом деле сопротивляется включению оценки в обязательства. В таких случаях следует представить широкий диапазон оценки и указать, что в оценке существует слишком большая доля неопределенности для принятия осмысленных обязательств.
После сокращения неопределенности до уровня, который позволяет принимать обязательства, диапазоны обычно не являются оптимальным средством выражения обязательств. Диапазон оценки наглядно представляет саму природу обязательств — сопряженных с большей или меньшей степенью риска, однако сами обязательства обычно должны выражаться в виде отдельных чисел.
СОВЕТ № 109 1
Не пытайтесь выражать обязательства в диапазонной форме. Обязательства должны быть более конкретными.
Дополнительные ресурсы
Gotterbarn, Don, Keith Miller, and Simon Rogerson. «Computer Society and ACM Approve Software Engineering Code of Ethics», «IEEE Computer», October 199, pp. 84-88 (www.computer.org/computer/code-of-ethics.pdf). В статье рассказано, как принимался этический кодекс разработчика, и приводится его полный текст.