Лекция 6. Оценка трудоемкости и сроков разработки ПО

Выводы

Мониторинг и контроль рисков

Управление рисками должно осуществляться на протяжении всего проекта. Не вести мониторинг рисков в ходе проекта — все равно, что не следить за уровнем топлива при поездке на автомобиле.

Мониторинг и управление рисками — это процесс идентификации, анализа и планирования реагирования на новые риски, отслеживания ранее идентифицированных рисков, а также проверки и исполнения операций реагирования на риски и оценка эффективности этих операций.

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

Мониторинг и управления рисками включает в себя следующие задачи:

· Пересмотр рисков.

· Аудит рисков.

· Анализ отклонений и трендов.

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

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

Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов (см. Лекция 8. Реализация проекта). На основании выходов этих анализов можно прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Отклонения от базового плана могут указывать на последствия, вызванные как угрозами, так и благоприятными возможностями.

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

Все, что мы делаем, управляя проектом разработки ПО, должно быть направлено на борьбу с рисками не уложиться в срок, перерасходовать ресурсы, разработать не тот продукт, который требуется.

Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.

Главные причины провала программных проектов:

· Требования заказчика отсутствуют / не полны / подвержены частым изменениям.

· Отсутствие необходимых ресурсов и опыта.

· Отсутствие рабочего взаимодействия с заказчиком.

· Неполнота планирования. «Забытые работы».

· Ошибки в оценках трудоемкостей и сроков работ

Оценка — вероятностное утверждение

Стив Макконнелл [1] пишет, что мы от природы склонны верить, что сложные формулы вида

всегда обеспечивают более точные результаты, чем простые формулы

Трудоемкость = КоличествоФакторов х СредниеЗатратыНаФактор

Однако, далеко не всегда это так. Сложные формулы, как правило, очень чувствительны к точности большого числа параметров (в приведенном примере формул COCOMO II содержится 21 параметр), которые надо задать, чтобы получить требуемые оценки.

Первое, что необходимо понимать при оценке проекта, это то, что любая оценка это всегда вероятностное утверждение. Если мы просто скажем, что трудоемкость данного пакета работ составляет М чел.*мес. (Рисунок 34), то это будет плохой оценкой потому, что одно единственное число ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес. Вряд ли мы можем считать себя «предсказамусами», которые точно знают что произойдет в будущем и сколько потребуется затрат на реализацию этого пакета работ.

Рисунок 34. Точечная оценка трудоемкости пакета работ ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес.

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

· Может ли вводиться несколько номеров?

· Должна ли быть проверка номеров на действительность?

· Простая или сложная проверка?

· Если реализуем простую проверку, то не захочет ли клиент заменить ее на более сложную?

· Должна ли проверка работать для иностранных номеров?

· Можно ли воспользоваться готовым решением?

· Каково должно быть качество реализации? Вероятность ошибки после поставки?

· Сколько времени потребуется на реализацию и отладку? (зависит от конкретного исполнителя).

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

То, что наша оценка должна быть вероятностным утверждением, означает, что для нее существует некоторое распределение вероятности (Рисунок 35), которое может быть очень широким (высокая неопределенность) или достаточно узким (низкая неопределенность).

Рисунок 35. Оценка — всегда вероятностная величина

Если M — наиболее вероятное значение, то это не означает что это хорошая оценка, поскольку вероятность того, что фактическая трудоемкость превысит эту оценку, составляет более 50%.

Какая оценка может считаться хорошей? Стив Макконнелл утверждает [1]: «Хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей».