ПРИМЕР ОЦЕНКИ ТРУДОЕМКОСТИ

ПРОГРАММНОГО ПРОДУКТА

НА ОСНОВЕ МЕТОДА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Данная методика основана на материалах компании Rational Software.

Для расчета используем диаграмму потоков данных, приведённую на рис. 1.

1) простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом;

2) среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола, либо личность, пользующуюся тек­стовым интерфейсом (например, алфавитно-цифровым термина­лом);

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

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

Таблица 1

Весовые коэффициенты действующих лиц

Рассмотрим действующих лиц данной системы (табл. 2).

Таблица 2

Типы действующих лиц

Используя весовые коэффициенты табл. 1, рассчитаем общий весовой показатель действующих лиц , имеем: 2 сложных, 1 простой и 4 средних типа.

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

Таблица 3

Весовые коэффициенты вариантов использования

Тип варианта использования	Описание	Весовой коэффициент
Простой	транзакций
Средний	от 4 до 7 транзакций
Сложный	транзакций

В результате получаем показатель UUCP (Unadjusted Use Case Points - точки случая нерегулируемого использования) по формуле:

(1)

Рассчитаем сложность вариантов использования, для этого определим тип использования (табл. 4).

Таблица 4

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

Используя весовые коэффициенты табл. 3, рассчитаем общий весовой показатель вариантов использования UC. В результате имеем 5 простых типов и 1 средний тип.

Получаем общий показатель по формуле (1):

Оценим техническую сложность проекта (TCF ­ Technical Complexity Factor), которая вычисляется с учетом показателей технической сложности (табл. 5).

Таблица 5

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

Каждому показателю присваивается значениев диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для дан­ного проекта, 5 - высокую значимость).

Значение TCFвычисля­ется по следующей формуле:

(2)

Вычислим:

Значение TCFвычисля­ется по формуле (2):

Далее рассматривается уровень квалификации разработчиков EF (Environmental Factor - фактор влияния окружающей среды), который вычисляется с учётом показателей (табл. 6). Каждому показателю присваивается значение в диапазоне от 0 до 5 (для создания проекта планируется привлечение программиста, опыт работы которого около 3-х лет). Для показателей F₁-F₄ 0 означает отсутствие, 3 - сред­ний уровень, 5 - высокий уровень. Для показателя F₅ 0 означает отсутствие мотивации, 3 - средний уровень, 5 - высокий уровень мотивации. Для F₆ 0 означает высокую нестабильность требова­ний, 3 - среднюю, 5 - стабильные требования. Для F₇ 0 означает отсутствие специалистов с частичной занятостью, 3 - средний уровень, 5 - все специалисты с частичной занятостью. Для пока­зателя F₈ 0 означает простой язык программирования, 3 - сред­нюю сложность, 5 - высокую сложность.

Таблица 6

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

Значение EF вычисляется по формуле:

Используя весовые показатели из табл. 6, имеем:

Таким образом, получим:

В результате получаем окончательное значение UCP (Use Case Points - точки случая использования), которое рассчитывается по формуле:

Имеем:

Далее производится оценка трудоемкости проекта в человеко-часах.

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

Рассмотрим показатели F₁-F₈ и определим, сколько показа­телей F₁-F₆ имеют значение меньше 3 и сколько показателей F₇-F₈ имеют значение больше 3. Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4 - 28 чел.-ч. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск прова­ла слишком высок.

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

Таким образом, трудоемкость данного проекта составляет 438,2 чел.-ч.

Оценим срок исполнения проекта. Над проектом планируется работа двух человек: руководителя и программиста. Рассмотрим примерный план работ над проектом и долю участия руководителя и программиста в разработке (табл. 7).

Таблица 7

Комплекс работ по разработке проекта

Таким образом, получаем, что руководитель участвует в проекте на 14 %, а программист – на 100 %. Принимая программиста за единицу приведенного исполнителя, получаем, что руководитель составляет 0,14 приведенного исполнителя, т. е. в разработке проекта участвует 1,14 приведенного человека.

Получаем трудоемкость проекта:

чел.-ч.

При расчете срока исполнения учитываем, что рабочий день составляет 8 ч., и в итоге получаем 48 дней работы над проектом.

По данным компании «Rational Software», в реальности длительность работы над проектом на 20-30 % больше, поэтому за срок разработки можно принять 60 дней.

• ⇐ Назад
• 123
• 4
• 5
• 6
• 7
• Далее ⇒