Оценка трудоемкости проекта

 

В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков. Приведем пример возможного уточнения.

Рассмотрим показатели Fl—F8 и определим, сколько показа­телей Fl—F6 имеют значение меньше 3 и сколько показателей F7—F8 имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4—28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск прова­ла слишком высок.

Для системы регистрации получаем 28 чел.-ч. на одну UCP, та­ким образом, общее количество человеко-часов на весь проект равно 56,56*28 = 1583,68, что составляет 40 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из четырех человек, и добавим 3 недели на различные непредвиден­ные ситуации, тогда в итоге получим 13 недель на весь проект.

Опытные данные компании Rational. Проект среднего размера (приблизительно 10 разработчиков, более чем 6-8 месяцев) мо­жет включать приблизительно 30 вариантов использования. Это соответствует тому, что средний вариант использования содержит 12 UCP, и каждая UCP требует 20-30 ч. Это означает общую тру­доемкость 240-360 чел.-ч. на вариант использования. Таким об­разом, 30 вариантов использования потребуют приблизительно 9000 чел.-ч. (10 разработчиков в течение 6 месяцев). Однако пря­мой пропорции не существует: очень большой проект со 100 раз­работчиками и сроком 20 месяцев не начнется с 1000 вариантов использования из-за проблем размерности.

Использование описанной выше методики для простых и сложных систем хорошо согласуется с опытными данными ком­пании Rational (приблизительно 150-350 ч. на один вариант ис­пользования). Самая простая система (весовой показатель UC = 5, А = 2, UUCP = 7) дает (при 20 чел.-ч. на UCP) приблизительно 140 чел.-ч. Сложная система (весовой показатель UC = 15, А = 3, UUCP = 18) дает приблизительно 360 чел.-ч.

6.5.

МЕТОДЫ, ОСНОВАННЫЕ НА ЭКСПЕРТНЫХ

ОЦЕНКАХ

 

Подходы, основанные на экспертных оценках, применяются при отсутствии дискретных эмпирических данных. Они исполь­зуют опыт и знания экспертов-практиков в различных областях. Оценки, получаемые при этом, представляют собой синтез изве­стных результатов прошлых проектов, в которых принимал учас­тие эксперт.

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

6.5.1.

МЕТОД ДЕЛЬФИ

 

Метод Дельфи был разработан в корпорации «Рэнд» в конце 1940-х гг. и использовался первоначально для прогнозирования будущих событий (отсюда метод и получил свое название по сходству с предсказаниями Дельфийского оракула в Древней Гре­ции). Позднее метод использовался для принятия решений по спорным вопросам. На предварительном этапе участники дис­куссии должны без обсуждения с другими ответить на ряд вопро­сов, относительно их мнения по спорному вопросу. Затем ответы обобщаются, табулируются и возвращаются каждому участнику дискуссии для проведения второго этапа, на котором участникам снова предстоит дать свою оценку спорного вопроса, но на этот раз, располагая мнениями других участников, полученными на первом этапе. Второй этап завершается сужением и выделением круга мнений, отражающих некоторую общую оценку проблемы. Изначально в методе Дельфи коллективное обсуждение не ис­пользовалось; обсуждение между этапами метода было впервые применено в обобщенном методе Дельфи. Метод достаточно эф­фективен в том случае, если необходимо сделать заключение по некоторой проблеме, а доступная информация состоит больше из «мнений экспертов», чем из строго определенных эмпирических данных.

6.5.2.

МЕТОД ДЕКОМПОЗИЦИИ РАБОТ

 

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

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

Наряду с процессом оценки МДР широко применяется для расчета себестоимости разработки ПО. Каждому элементу иерар­хий МДР можно приписать свой бюджет и уровень издержек, что позволяет персоналу составлять отчеты о количестве рабочего времени, которое было затрачено на выполнение заданной зада­чи в рамках проекта или какого-либо компонента проекта, кото­рые затем могут быть обобщены для административного контро­ля над использованием средств.

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

6.6.