1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Оценка трудоемкости создания программного обеспечения 461

Для системы регистрации сложность вариантов использова­ ния определяется следующим образом:

Сложность вариантов использования

Таким образом, общий весовой показатель равен: иСР = 5*5+10*3 = 45.

В результате получаем показатель UUCP (unadjusted use case points):

ииСР=Л + иС = 56.

6.4.3. ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОЙ СЛОЖНОСТИ ПРОЕКТА

Техническая сложность проекта (TCF — technical complexity factor) вычисляется с учетом показателей технической сложности (табл. 6.15).

Таблица 6.15

Показатели технической сложности

Каждому показателю присваивается значение 7} в диапазоне от О до 5 (О означает отсутствие значимости показателя для дан­ ного проекта, 5 — высокую значимость). Значение ГС/"вычисля­ ется по следующей формуле:

TCF = 0,6 + (0,01 * (Z Т;. * Вес,.)). Вычислим TCF для системы регистрации (табл. 6.16).

Оценка трудоемкости создания программного обеспечения 463

TCF = 0,6 +(0,01 * 40) = 1,0.

6 . 4 . 4 . ОПРЕДЕЛЕНИЕ УРОВНЯ КВАЛИФИКАЦИИ РАЗРАБОТЧИКОВ

Уровень квалификации разработчиков (EF — environmental factor) вычисляется с учетом следующих показателей (табл. 6.17).

Таблица 6.17

Каждому показателю присваивается значение в диапазоне от

О до 5. Для показателей F1 — F4 О означает отсутствие, 3 — сред­ ний уровень, 5 — высокий уровень. Для показателя F5 О означает отсутствие мотивации, 3 — средний уровень, 5 — высокий уровень мотивации. Для F6 О означает высокую нестабильность требова­ ний, 3 — среднюю, 5 — стабильные требования. Для F7 О означа­ ет отсутствие специалистов с частичной занятостью, 3 — средний уровень, 5 — все специалисты с частичной занятостью. Для пока­ зателя F8 О означает простой язык программирования, 3 — сред­ нюю сложность, 5 — высокую сложность.

Значение EF вычисляется по следующей формуле: EF = 1,4 + (- 0,03 * (S /;•* Вес,)).

Вычислим EF для системы регистрации (табл. 6.18).

Таблица 6.18

Показатели уровня квалификации разработчиков системы регистрации

Оценка трудоемкости создания программного обеспечения 465

В результате получаем окончательное значение UCP (use case points):

UCP = UUCP * TCP * EF = 56*1,0*1,01 = 56,56.

6 . 4 . 5 . ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА

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

Рассмотрим показатели F1—F8 и определим, сколько показа­ телей F1—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 требует 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-х гг. и использовался первоначально для прогнозирования будущих событий (отсюда метод и получил свое название по сходству с предсказаниями Дельфийского оракула в Древней Гре­ ции). Позднее метод использовался для принятия решений по спорным вопросам. На предварительном этапе участники дис­ куссии должны без обсуждения с другими ответить на ряд вопро­ сов, относительно их мнения по спорному вопросу. Затем ответы обобщаются, табулируются и возвращаются каждому участнику дискуссии для проведения второго этапа, на котором участникам снова предстоит дать свою оценку спорного вопроса, но на этот раз, располагая мнениями других участников, полученными на первом этапе. Второй этап завершается сужением и выделением круга мнений, отражающих некоторую общую оценку проблемы.

Оценка трудоемкости создания программного обеспечения 467

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

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

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

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

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

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

6.6. СРЕДСТВА ОЦЕНКИ ТРУДОЕМКОСТИ

Ряд средств оценки является коммерческими продуктами — SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (SPR). Эти про­ дукты нельзя назвать совершенными, и все они требуют от поль­ зователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «что заложишь, то и получишь»). В лучшем случае с помощью таких продуктов можно получить оценку с точностью 10%. Даже если точность будет 50%, это все равно лучше, чем брать данные «с потолка».

Существуют специальные профаммные средства, автомати­ зирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является KnowledgePLAN — продукт фирмы SPR.

KnowledgePLAN разработан на основе исследований, прове­ денных в фирме SPR, в области оценок сложности, трудоемкости и производительности при разработке ПО. Оценка и планирова­ ние в пакете KnowledgePLAN ведется на основе статистических закономерностей, выведенных на основе анализа более чем 8000 успешно завершенных проектов из различных областей примене­ ния. Исходные данные для вычислений находятся в специальном репозитории, который обновляется по результатам выполнения реальных проектов. В качестве метрик для оценки размеров ПО

Оценка трудоемкости создания программного обеспечения 469

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

KnowledgePLAN обладает следующими возможностями:

•формирование близкого к реальному плана работ по проекту;

•определение трудоемкости и стоимости планируемых про­ ектов;

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

•проведение анализа «what ~ if» («что-если») для поиска луч­ ших решений;

•проведение сравнительного анализа качества и производи­ тельности разработки разнотипных проектов, или однотип­ ных проектов, при выполнении которых использовались различные технологии;

•накопление статистической многомерной информации о проекте и его участниках;

•классификация проектов для принятия решения о структу­ ре управления проектом;

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

6.7. ПЛАНИРОВАНИЕ ИТЕРАЦИОННОГО ПРОЦЕССА СОЗДАНИЯ ПО

При планировании процесса создания ПО важно не только оценить длительность разработки (как это, например, предлага­ лось сделать в подразд. 6.3.2), но и представлять себе соотноше­ ние длительности различных стадий процесса создания ПО. Так, например, поданным компании Rational Software, распределение времени и объема работ по стадиям представлено в табл. 6.19.

Такое распределение справедливо для проекта, имеющего следующие характеристики:

•средний размер проекта и средний объем работ;

•незначительное число рисков и нововведений;

•нахождение в начальном цикле разработки;

•отсутствие предопределенной архитектуры.

Данное распределение может быть достаточно гибким, оно подчиняется указанным ниже эвристическим правилам.

•Если для определения области действия проекта, изыскания финансирования, изучения рынка или создания первона­ чального прототипа нужно значительное время, — увеличи­ вается начальная стадия.

•Если отсутствует архитектура, предусматривается примене­ ние новых (или незнакомых) технологий и (или) имеются жесткие ограничения производительности, значительное число технических рисков, а персонал большей частью сос­ тоит из новичков, — увеличивается стадия разработки.

•Если проект представляет собой разработку второго поколе­ ния существующего продукта и в архитектуру не вносятся значительные изменения — уменьшаются стадии разработ­ ки и конструирования.

•Если нужно быстро выпустить продукт на рынок (из-за вы­ сокой конкуренции) и спланировать постепенное заверше­ ние разработки — уменьшается стадия конструирования и увеличивается стадия ввода в действие.

•Если затруднено внедрение, например, при замещении од­ ной системы другой без прерывания эксплуатации или при необходимости сертификации (в таких областях, как меди­ цинское оборудование, ядерная промышленность или авиа­ ционная электроника), — увеличивается стадия ввода в

действие.

Следующий важный вопрос «Сколько итераций будет содер­ жать каждая стадия?». Прежде чем принять решение по этому воп­ росу, нужно рассмотреть продолжительность каждой итерации.