Методы оценки - пункты прецедента

А Use-Case представляет собой серию взаимосвязанных взаимодействий между пользователем и системой, которые позволяют пользователю достичь цели.

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

Рекомендации по использованию - Определение

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

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

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

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

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

История точек прецедентов

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

Процесс подсчета баллов прецедента

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

  • Рассчитать нескорректированные UCP
  • С учетом технической сложности
  • Сделайте поправку на сложность окружающей среды
  • Рассчитать скорректированные UCP

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

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

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

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

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

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

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

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

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

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

Сложность варианта использования Вес варианта использования Количество вариантов использования Продукт
просто 5 NSUC 5 × NSUC
В среднем 10 NAUC 10 × NAUC
Сложный 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Где,

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

NAUC - это нет. средних вариантов использования.

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

Step 1.2 - Определите нескорректированный вес актера.

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

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

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

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

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

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

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

Актерская сложность Вес актера Количество Актеров Продукт
просто 1 АНБ 1 × АНБ
В среднем 2 NAA 2 × NAA
Сложный 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA

Где,

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

NAA - это нет. рядовых актеров.

NCA - нет. сложных актеров.

Step 1.3 - Расчет нескорректированных точек прецедента.

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

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

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

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

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

Фактор Описание Вес
Т1 Распределенная система 2.0
Т2 Время отклика или целевые показатели производительности 1.0
Т3 Эффективность конечного пользователя 1.0
Т4 Комплексная внутренняя обработка 1.0
Т5 Код должен быть многоразовым 1.0
T6 Легко установить .5
T7 Легко использовать .5
T8 Портативный 2.0
T9 Легко изменить 1.0
T10 Одновременный 1.0
T11 Включает особые цели безопасности 1.0
T12 Обеспечивает прямой доступ для третьих лиц 1.0
T13 Требуются специальные средства обучения пользователей 1.0

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

Step 2.2 - По каждому из 13 факторов оцените проект и оцените его от 0 (неактуально) до 5 (очень важно).

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

Impact of the Factor = Impact Weight × Rated Value

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

Фактор Описание Вес (Вт) Номинальное значение (от 0 до 5) (RV) Удар (I = W × RV)
Т1 Распределенная система 2.0
Т2 Время отклика или целевые показатели производительности 1.0
Т3 Эффективность конечного пользователя 1.0
Т4 Комплексная внутренняя обработка 1.0
Т5 Код должен быть многоразовым 1.0
T6 Легко установить .5
T7 Легко использовать .5
T8 Портативный 2.0
T9 Легко изменить 1.0
T10 Одновременный 1.0
T11 Включает особые цели безопасности 1.0
T12 Обеспечивает прямой доступ для третьих лиц 1.0
T13 Требуются специальные средства обучения пользователей 1.0
Total Technical Factor (TFactor)

Step 2.5 - Рассчитайте коэффициент технической сложности (TCF) как -

TCF = 0.6 + (0.01 × TFactor)

Шаг 3: внесите поправку на сложность окружающей среды

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

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

Step 3.2 - По каждому из 8 факторов оцените проект и поставьте балл от 0 (нерелевантно) до 5 (очень важно).

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

Impact of the Factor = Impact Weight × Rated Value

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

Фактор Описание Вес (Вт) Номинальное значение (от 0 до 5) (RV) Удар (I = W × RV)
F1 Знаком с используемой моделью проекта 1.5
F2 Опыт применения .5
F3 Объектно-ориентированный опыт 1.0
F4 Возможности ведущего аналитика .5
F5 Мотивация 1.0
F6 Стабильные требования 2.0
F7 Персонал, занятый неполный рабочий день -1,0
F8 Сложный язык программирования -1,0
Total Environment Factor (EFactor)

Step 3.5 - Рассчитайте фактор окружающей среды (EF) как -

1.4 + (-0.03 × EFactor)

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

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

UCP = UUCP × TCF × EF

Преимущества и недостатки точек прецедента

Преимущества точек прецедента

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

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

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

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

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

Недостатки точек прецедента

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

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

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

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