Учебники

Методы оценки – точки использования

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

Варианты использования – это способ отразить функциональные требования системы. Пользователь системы называется «Актер». Варианты использования в основном в текстовой форме.

Точки использования – определение

Точки использования (UCP) – это метод оценки программного обеспечения, используемый для измерения размера программного обеспечения с использованием вариантов использования. Концепция UCP похожа на FP.

Количество UCP в проекте основано на следующем:

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

    • Среда, в которой будет развиваться проект (например, язык, мотивация команды и т. Д.)

Различные нефункциональные требования (такие как переносимость, производительность, ремонтопригодность), которые не записаны как варианты использования.

Среда, в которой будет развиваться проект (например, язык, мотивация команды и т. Д.)

Оценка с использованием UCP требует, чтобы все варианты использования были написаны с целью и примерно на одном уровне, давая одинаковое количество деталей. Следовательно, перед оценкой команда проекта должна убедиться, что они написали свои варианты использования с определенными целями и на детальном уровне. Вариант использования обычно завершается в течение одного сеанса, и после достижения цели пользователь может перейти к какому-либо другому действию.

История точек использования

Метод оценки Точки Использования был введен Густавом Карнером в 1993 году. Позднее работа была лицензирована Rational Software, которая слилась с IBM.

Процесс подсчета точек использования

Процесс подсчета баллов прецедентов состоит из следующих этапов:

  • Рассчитать нескорректированные UCP
  • Отрегулируйте для технической сложности
  • Приспособиться к экологической сложности
  • Рассчитать скорректированные UCP

Шаг 1: Рассчитайте нескорректированные точки использования.

Сначала вы вычисляете нескорректированные баллы прецедентов, выполнив следующие шаги:

  • Определите нескорректированный вес прецедента
  • Определите нескорректированный вес актера
  • Рассчитать нескорректированные точки использования

Шаг 1.1. Определите нескорректированный вес варианта использования.

Шаг 1.1.1 – Найти количество транзакций в каждом сценарии использования.

Если варианты использования записаны с уровнями целей пользователя, транзакция эквивалентна шагу в сценарии использования. Найдите количество транзакций, посчитав шаги в прецеденте.

Шаг 1.1.2. Классифицируйте каждый вариант использования как простой, средний или сложный на основе количества транзакций в сценарии использования. Кроме того, присвойте Вес варианта использования, как показано в следующей таблице –

Сложность варианта использования Количество транзакций Вес прецедента
просто ≤3 5
Средний 4 до 7 10
Сложный > 7 15

Шаг 1.1.3 – Повторите для каждого варианта использования и получите все веса вариантов использования. Нескорректированный вес варианта использования (UUCW) представляет собой сумму всех весов варианта использования.

Шаг 1.1.4 – Найти нескорректированный вес варианта использования (UUCW), используя следующую таблицу –

Сложность варианта использования Вес прецедента Количество вариантов использования Товар
просто 5 NSUC 5 × NSUC
Средний 10 NAUC 10 × НАУК
Сложный 15 NCUC 15 × NCUC
Нескорректированный вес варианта использования (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Куда,

NSUC это нет. простых случаев использования.

НАУК это нет. средних случаев использования.

NCUC это нет. комплексных вариантов использования.

Шаг 1.2 – Определите нескорректированный вес актера.

Актором в прецеденте может быть человек, другая программа и т. Д. Некоторые действующие лица, такие как система с определенным API, имеют очень простые потребности и лишь незначительно увеличивают сложность прецедента.

Некоторые участники, такие как система, взаимодействующая через протокол, имеют больше потребностей и в определенной степени увеличивают сложность варианта использования.

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

Шаг 1.2.1 – Классифицировать актеров как простых, средних и сложных и назначить веса актеров, как показано в следующей таблице –

Актер Сложность пример Актер Вес
просто Система с определенным API 1
Средний Система, взаимодействующая через протокол 2
Сложный Пользователь, взаимодействующий через GUI 3

Шаг 1.2.2 – Повторите для каждого актера и получите все веса актеров. Нескорректированный вес актера (UAW) – это сумма всех весов актера.

Шаг 1.2.3 – Найти нескорректированный вес актера (UAW), используя следующую таблицу –

Актер Сложность Актер Вес Количество актеров Товар
просто 1 NSA 1 × АНБ
Средний 2 NAA 2 × NAA
Сложный 3 NCA 3 × NCA
Масса актера без корректировки (UAW) 1 × АНБ + 2 × НАА + 3 × НКА

Куда,

АНБ нет. простых актеров.

NAA это нет. средних актеров.

NCA это нет. комплексных актеров.

Шаг 1.3 – Расчет нескорректированных точек использования.

Нескорректированный вес прецедента (UUCW) и нескорректированный вес актера (UAW) вместе дают нескорректированный размер системы, называемый нескорректированными точками прецедента.

Нескорректированные точки использования (UUCP) = UUCW + UAW

Следующие шаги должны отрегулировать нескорректированные точки использования (UUCP) для технической сложности и экологической сложности.

Шаг 2: Настройтесь на техническую сложность

Шаг 2.1. Рассмотрим 13 факторов, которые способствуют влиянию технической сложности проекта на точки использования и соответствующие им веса, как указано в следующей таблице.

фактор Описание Вес
T1 Распределенная Система 2,0
T2 Время отклика или показатели производительности 1,0
T3 Эффективность конечного пользователя 1,0
T4 Комплексная внутренняя обработка 1,0
T5 Код должен быть многоразовым 1,0
T6 Прост в установке 0,5
T7 Легко использовать 0,5
T8 портативный 2,0
T9 Легко изменить 1,0
T10 параллельный 1,0
T11 Включает в себя специальные цели безопасности 1,0
T12 Предоставляет прямой доступ третьим лицам 1,0
T13 Требуются специальные средства обучения пользователей 1,0

Многие из этих факторов представляют нефункциональные требования проекта.

Шаг 2.2 – Для каждого из 13 факторов оцените проект и оцените его от 0 (не имеет значения) до 5 (очень важно).

Шаг 2.3 – Рассчитать влияние фактора из ударного веса фактора и номинального значения для проекта как

Влияние фактора = ударный вес × номинальное значение

Шаг (2.4) – Рассчитать сумму воздействия всех факторов. Это дает общий технический коэффициент (TFactor), как указано в таблице ниже –

фактор Описание Вес (Вт) Номинальная стоимость (от 0 до 5) (RV) Воздействие (I = W × RV)
T1 Распределенная Система 2,0
T2 Время отклика или показатели производительности 1,0
T3 Эффективность конечного пользователя 1,0
T4 Комплексная внутренняя обработка 1,0
T5 Код должен быть многоразовым 1,0
T6 Прост в установке 0,5
T7 Легко использовать 0,5
T8 портативный 2,0
T9 Легко изменить 1,0
T10 параллельный 1,0
T11 Включает в себя специальные цели безопасности 1,0
T12 Предоставляет прямой доступ третьим лицам 1,0
T13 Требуются специальные средства обучения пользователей 1,0
Общий технический фактор (TFactor)

Шаг 2.5 – Рассчитать коэффициент технической сложности (TCF) как –

TCF = 0,6 + (0,01 × TFactor)

Шаг 3: приспособиться к экологической сложности

Шаг 3.1. Рассмотрим 8 факторов окружающей среды, которые могут повлиять на выполнение проекта, и их соответствующие веса, приведенные в следующей таблице.

фактор Описание Вес
F1 Знаком с моделью проекта, которая используется 1,5
F2 Опыт применения 0,5
F3 Объектно-ориентированный опыт 1,0
F4 Возможность ведущего аналитика 0,5
F5 мотивация 1,0
F6 Стабильные требования 2,0
F7 Частичная занятость -1,0
F8 Сложный язык программирования -1,0

Шаг 3.2 – Для каждого из 8 факторов оцените проект и оцените его от 0 (не имеет значения) до 5 (очень важно).

Шаг 3.3. Рассчитать влияние фактора из ударного веса фактора и номинального значения для проекта как

Влияние фактора = ударный вес × номинальное значение

Шаг 3.4 – Рассчитайте сумму воздействия всех факторов. Это дает общий фактор среды (EFactor), как указано в следующей таблице:

фактор Описание Вес (Вт) Номинальная стоимость (от 0 до 5) (RV) Воздействие (I = W × RV)
F1 Знаком с моделью проекта, которая используется 1,5
F2 Опыт применения 0,5
F3 Объектно-ориентированный опыт 1,0
F4 Возможность ведущего аналитика 0,5
F5 мотивация 1,0
F6 Стабильные требования 2,0
F7 Частичная занятость -1,0
F8 Сложный язык программирования -1,0
Общий фактор окружающей среды (EFactor)

Шаг 3.5 – Рассчитать фактор окружающей среды (EF) как –

1,4 + (-0,03 × EFactor)

Шаг 4: Расчет скорректированных точек использования (UCP)

Рассчитайте скорректированные точки использования (UCP) как –

UCP = UUCP × TCF × EF

UCP основаны на вариантах использования и могут быть измерены очень рано в жизненном цикле проекта.

UCP (оценка размера) не зависит от размера, навыков и опыта команды, которая реализует проект.

Оценки на основе UCP оказываются близкими к фактическим, когда оценка проводится опытными людьми.

UCP прост в использовании и не требует дополнительного анализа.

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

UCP может использоваться только тогда, когда требования написаны в форме вариантов использования.

Зависит от целенаправленных, хорошо написанных сценариев использования. Если варианты использования не хорошо или равномерно структурированы, результирующее UCP может быть неточным.

Технические факторы и факторы окружающей среды оказывают большое влияние на UCP. Необходимо соблюдать осторожность при назначении значений технических факторов и факторов окружающей среды.

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