Каталог статей
| Главная » Статьи » Мои статьи | [ Добавить статью ] |
Методика оценки трудоемкости разработки ПО на основе вариантов использования
| Все действующие лица системы делятся на три типа: простые, средние и сложные. Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API). Среднее действующее лицо представляет либо внешнюю сис тему, взаимодействующую с данной системой посредством про токола наподобие TCP/IP, либо личность, пользующуюся тексто вым интерфейсом (например, ASCII-терминалом). Сложное действующее лицо представляет личность, пользую щуюся графическим интерфейсом (GUI). Подсчитанное количество действующих лиц каждого типа умножается на соответствующий весовой коэффициент, затем вычисляется общий весовой показатель А.ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ Все варианты использования делятся на три типа: простые, средние и сложные, в зависимости от количества транзакций в потоках событий (основных и альтернативных). В данном случае под транзакцией понимается атомарная последовательность действий, которая выполняется полностью или отменяется. Подсчитанное количество вариантов использования каждого типа умножается на соответствующий весовой коэффициент, за тем вычисляется общий весовой показатель UCP . Другой способ определения сложности вариантов использо вания заключается в подсчете количества классов анализа, участ вующих в их реализации. ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОЙ СЛОЖНОСТИ ПРОЕКТА Техническая сложность проекта (TCF — technical complexity factor) вычисляется с учетом показателей технической сложности ОПРЕДЕЛЕНИЕ УРОВНЯ КВАЛИФИКАЦИИ РАЗРАБОТЧИКОВ Уровень квалификации разработчиков (EF — environmental factor) вычисляется с учетом следующих показателей. ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА В качестве начального значения предлагается использовать 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 чел.-ч. | |
| Просмотров: 3131 | |
| Всего комментариев: 0 | |