СДЕЛАЙТЕ СВОИ УРОКИ ЕЩЁ ЭФФЕКТИВНЕЕ, А ЖИЗНЬ СВОБОДНЕЕ

Благодаря готовым учебным материалам для работы в классе и дистанционно

Скидки до 50 % на комплекты
только до

Готовые ключевые этапы урока всегда будут у вас под рукой

Организационный момент

Проверка знаний

Объяснение материала

Закрепление изученного

Итоги урока

Оценка трудоемкости разработки на основе диаграммы вариантов использования

Категория: Информатика

Нажмите, чтобы узнать подробности

В данной работе рассматривается оценка трудоемкости разработки  программных продуктов на основе диаграммы вариантов использования. Материал полезен для проведения занятий по дисциплине МДК.04.01." Моделирование и анализ программного обеспечения" специальности 09.02.03 "Программирование в компьютерных системах" СПО углубленной подготовки

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

ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ на основе диаграммы вариантов использования

ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ

на основе диаграммы вариантов использования

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ДЕЙСТВУЮЩИХ ЛИЦ  Все действующие лица системы делятся на три типа: простые, средние и сложные.  Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API).  Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством про­токола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, ASCII-терминалом).

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ

ДЕЙСТВУЮЩИХ ЛИЦ

Все действующие лица системы делятся на три типа: простые, средние и сложные.

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

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

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

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

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

 В качестве примера рассмотрим систему регистрации для учебного заведения. Таким образом, общий весовой показатель равен: А= 2*1 + 3*3 = 11.

В качестве примера рассмотрим систему регистрации для учебного заведения.

Таким образом, общий весовой показатель равен:

А= 2*1 + 3*3 = 11.

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ  ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ   Все варианты использования делятся на три типа: простые,средние и сложные, в зависимости от количества транзакций в потоках событий (основных и альтернативных).  В данном случае под транзакцией понимается атомарная последовательность действий, которая выполняется полностью или отменяется.  Подсчитанное количество вариантов использования каждого типа умножается на соответствующий весовой коэффициент, затем вычисляется общий весовой показатель UCP

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Все варианты использования делятся на три типа: простые,средние и сложные, в зависимости от количества транзакций в потоках событий (основных и альтернативных).

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

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

 Другой способ определения сложности вариантов использования заключается в подсчете количества классов анализа, участвующих в их реализации

Другой способ определения сложности вариантов использования заключается в подсчете количества классов анализа, участвующих в их реализации

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

Пример:

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

.

 Таким образом, общий весовой показатель равен:  U СР = 5*5+10*3 = 45.   В результате получаем показатель UUCP (unadjusted use case points): UU СР= A + U С P = 56.  ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОЙ  СЛОЖНОСТИ ПРОЕКТА  Техническая сложность проекта (TCF — technical complexity  factor) вычисляется с учетом показателей технической сложности ( см. таблицу на следующем слайде).

Таким образом, общий весовой показатель равен:

U СР = 5*5+10*3 = 45.

В результате получаем показатель UUCP (unadjusted use case points): UU СР= A + U С P = 56.

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

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

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

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

 Каждому показателю присваивается значение Т i  в диапазоне от 0 до 5 ( 0 означает отсутствие значимости показателя для данного проекта, 5 — высокую  значимость).  Значение TCF вычисляется по следующей формуле:

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

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

Пример: Вычислим TCF для системы регистрации Показатели технической сложности системы регистрации

Пример: Вычислим TCF для системы регистрации

Показатели технической сложности системы регистрации

TCF = 0,6 +(0,01 * 40) = 1,0.  ОПРЕДЕЛЕНИЕ УРОВНЯ КВАЛИФИКАЦИИ РАЗРАБОТЧИКОВ   Уровень квалификации разработчиков (EF — environmental factor) вычисляется с учетом следующих показателей:

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

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

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

 Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 — F4  0 означает отсутствие, 3 — средний уровень, 5 — высокий уровень. Для показателя F5 - 0 означает  отсутствие мотивации, 3 — средний уровень, 5 — высокий уровень мотивации.

Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 — F4

0 означает отсутствие, 3 — средний уровень, 5 — высокий уровень. Для показателя F5 - 0 означает

отсутствие мотивации, 3 — средний уровень, 5 — высокий уровень мотивации.

 Для F6 – 0 означает высокую нестабильность требований, 3 — среднюю, 5 — стабильные требования. Для F7- 0 означает отсутствие специалистов с частичной занятостью, 3 — средний уровень, 5 — все специалисты с частичной занятостью.  Для показателя F8 - 0 означает простой язык программирования, 3 — среднюю сложность, 5 — высокую сложность.  Значение EF вычисляется по следующей формуле:

Для F6 – 0 означает высокую нестабильность требований, 3 — среднюю, 5 — стабильные требования. Для F7- 0 означает отсутствие специалистов с частичной занятостью, 3 — средний уровень, 5 — все специалисты с частичной занятостью.

Для показателя F8 - 0 означает простой язык программирования, 3 — среднюю сложность, 5 — высокую сложность.

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

Пример: Вычислим EF для системы регистрации

Пример: Вычислим EF для системы регистрации

EF = 1,4+ (-0,03 * 13) =1,01.   В результате получаем окончательное значение UCP (use case points):   UCP = UUCP * TCP * EF = 56*1,0*1,01 = 56,56  ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА    В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.  Пример: Рассмотрим показатели F1—F8 и определим, сколько показателей F1—F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3 .

EF = 1,4+ (-0,03 * 13) =1,01.

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

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

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

В качестве начального значения предлагается использовать 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 недель на весь проект

Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4 , то 28. Если общее количество равно 5 или более, следует

внести изменения в сам проект, в противном случае риск провала слишком высок.

Для системы регистрации получаем 28 чел.-ч. на одну UCP, таким образом, общее количество человеко-часов на весь проект равно

56,56*28 = 1583,68,

что составляет 40 недель при 40-часовой рабочей неделе.

Допустим, что команда разработчиков состоит из

четырех человек, и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 13 недель на весь проект

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

Опытные данные компании Rational

Проект среднего размера(приблизительно 10 разработчиков, более чем 6—8 месяцев) может включать приблизительно 30 вариантов использования. Это соответствует тому, что средний вариант использования содержит 12 U СР, и каждая UCP требует 20-30 ч. Это означает общую трудоемкость 240-360 чел.-ч. на вариант использования. Таким образом, 30 вариантов использования потребуют приблизительно

9000 чел.-ч. (10 разработчиков в течение 6 месяцев). Однако прямой пропорции не существует: очень большой проект со 100

разработчиками и сроком 20 месяцев не начнется с 1000 вариантов использования из-за проблем размерности. Использование описанной выше методики для простых и c ложных систем хорошо согласуется с опытными данными компании Rational (приблизительно 150—350 ч. на один вариант использования).

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

Самая простая система (весовой показатель UC = 5,

А = 2, UUCP = 7) дает (при 20 чел.-ч. на UCP) приблизительно 140 чел.-ч.

Сложная система (весовой показатель UC = 15,

А = 3, UUCP = 18) дает приблизительно 360 чел.-ч.