Методы оценки - процесс подсчета FP

Процесс подсчета FP включает в себя следующие этапы -

  • Шаг 1 - Определите тип счета.

  • Шаг 2 - Определите границу счета.

  • Шаг 3 - Определите каждый элементарный процесс (EP), требуемый пользователем.

  • Шаг 4 - Определите уникальные EP.

  • Шаг 5 - Измерение данных функций.

  • Шаг 6 - Измерение транзакционных функций.

  • Шаг 7 - Рассчитать функциональный размер (нескорректированное количество функциональных точек).

  • Шаг 8 - Определить коэффициент корректировки значения (VAF).

  • Шаг 9 - Рассчитайте скорректированное количество функциональных точек.

Примечание. Общие характеристики системы (GSC) в ПСК 4.3.1 сделаны необязательными и перенесены в Приложение. Следовательно, этап 8 и этап 9 можно пропустить.

Шаг 1: Определите тип счета

Существует три типа подсчета функциональных точек:

  • Количество точек функции развития
  • Функция подсчета точек
  • Функция Количество очков

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

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

Функция подсчета точек

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

Функция Количество очков

Когда в программное обеспечение вносятся изменения после производства, они рассматриваются как усовершенствования. Чтобы определить размер таких проектов расширения, в приложении добавляется, изменяется или удаляется количество точек функции.

Шаг 2: Определить границу графа

Граница указывает границу между измеряемым приложением и внешними приложениями или доменом пользователя. (См. Рисунок 1)

Чтобы определить границу, поймите -

  • Назначение функции подсчета очков
  • Область применения измеряется
  • Как и какие приложения поддерживают какие данные
  • Бизнес-сферы, которые поддерживают приложения

Шаг 3: Определите каждый элементарный процесс, требуемый пользователем

Составить и / или разложить функциональные пользовательские требования на наименьшую единицу деятельности, которая удовлетворяет всем следующим критериям:

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

Например, функциональное требование пользователя - «Ведение информации о сотруднике» может быть разбито на более мелкие действия, такие как добавление сотрудника, смена сотрудника, удаление сотрудника и запрос о сотруднике.

Каждая идентифицированная таким образом единица деятельности является Элементарным Процессом (ЕП).

Шаг 4: Определить уникальные элементарные процессы

Сравнивая два уже идентифицированных EP, считайте их как один EP (тот же EP), если они -

  • Требуется такой же набор DET.
  • Требуется такой же набор FTR.
  • Требуется тот же набор логики обработки для завершения EP.

Не разбивайте EP с несколькими формами логики обработки на несколько EPS.

Например, если вы определили «Добавить сотрудника» в качестве EP, его не следует разделять на два EP, чтобы учесть тот факт, что сотрудник может иметь или не иметь иждивенцев. EP по-прежнему «Добавить сотрудника», и существуют разные варианты в логике обработки и DET для учета иждивенцев.

Шаг 5: Измерьте функции данных

Классифицируйте каждую функцию данных как ILF или EIF.

Функция данных должна быть классифицирована как -

  • Внутренний логический файл (ILF), если он поддерживается измеряемым приложением.

  • Файл внешнего интерфейса (EIF), если на него есть ссылка, но он не поддерживается измеряемым приложением.

ILF и EIF могут содержать бизнес-данные, данные управления и данные на основе правил. Например, телефонная коммутация производится всех трех типов - бизнес-данные, данные правил и контрольные данные. Бизнес-данные - это фактический звонок. Данные правила - это то, как вызов должен маршрутизироваться через сеть, а данные управления - это то, как коммутаторы взаимодействуют друг с другом.

Рассмотрим следующую документацию для подсчета ILF и EIF -

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

Шаг 5.1: Подсчет DET для каждой функции данных

Примените следующие правила для подсчета DET для ILF / EIF -

  • Подсчитайте DET для каждого уникального идентифицируемого пользователем неповторяющегося поля, которое поддерживается или извлекается из ILF или EIF посредством выполнения EP.

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

  • Подсчитайте DET для каждого атрибута, необходимого пользователю для установления связи с другим ILF или EIF.

  • Просмотрите связанные атрибуты, чтобы определить, сгруппированы ли они и учитываются ли они как один DET или считаются ли они несколькими DET. Группировка будет зависеть от того, как EP используют атрибуты в приложении.

Шаг 5.2: Подсчет RET для каждой функции данных

Примените следующие правила для подсчета RET для ILF / EIF -

  • Посчитайте один RET для каждой функции данных.
  • Подсчитайте один дополнительный RET для каждой из следующих дополнительных логических подгрупп DET.
    • Ассоциативная сущность с неключевыми атрибутами.
    • Подтип (отличный от первого подтипа).
    • Атрибутивная сущность в отношениях, отличных от обязательных 1: 1.

Шаг 5.3. Определение функциональной сложности для каждой функции данных

RETS Типы элементов данных (DET)
1-19 20-50 > 50
1 L L
От 2 до 5 L ЧАС
> 5 ЧАС ЧАС

Функциональная сложность: L = низкая; A = Средний; H = высокий

Шаг 5.4. Измерение функционального размера для каждой функции данных

Функциональная сложность FP Счет для ILF FP Счет для EIF
Низкий 7 5
Средний 10 7
Высоко 15 10

Шаг 6: Измерение транзакционных функций

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

Шаг 6.1: классифицировать каждую транзакционную функцию

Транзакционные функции должны быть классифицированы как внешний вход, внешний выход или внешний запрос.

Внешний вход

Внешний вход (EI) - это элементарный процесс, который обрабатывает данные или управляющую информацию, поступающую извне. Основной целью EI является поддержание одного или нескольких ILF и / или изменение поведения системы.

Все следующие правила должны применяться -

  • Данные или управляющая информация получаются за пределами границ приложения.

  • По крайней мере один ILF поддерживается, если данные, поступающие в границу, не являются управляющей информацией, которая изменяет поведение системы.

  • Для идентифицированного EP, одно из трех утверждений должно применяться -

    • Логика обработки является уникальной по сравнению с логикой обработки, выполняемой другими EI для приложения.

    • Набор идентифицированных элементов данных отличается от наборов, идентифицированных для других EI в приложении.

    • Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие EI в приложении.

Внешний выход

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

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

Логика обработки должна -

  • Содержать хотя бы одну математическую формулу или расчет.
  • Создать производные данные.
  • Поддерживать один или несколько ILF.
  • Измените поведение системы.

Все следующие правила должны применяться -

  • Отправляет данные или управляющую информацию вне границы приложения.
  • Для идентифицированного EP, одно из трех утверждений должно применяться -
    • Логика обработки является уникальной из логики обработки, выполняемой другими EO для приложения.
    • Идентифицированный набор элементов данных отличается от других EO в приложении.
    • Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие EO в приложении.

Кроме того, должно применяться одно из следующих правил:

  • Логика обработки содержит хотя бы одну математическую формулу или вычисление.
  • Логика обработки поддерживает как минимум один ILF.
  • Логика обработки изменяет поведение системы.

Внешний запрос

Внешний запрос (EQ) - это элементарный процесс, который отправляет данные или управляющую информацию за пределы. Основной целью EQ является представление информации пользователю посредством поиска данных или управляющей информации.

Логика обработки не содержит математической формулы или вычислений и не создает производных данных. Во время обработки не поддерживается ни ILF, ни поведение системы.

Все следующие правила должны применяться -

  • Отправляет данные или управляющую информацию вне границы приложения.
  • Для идентифицированного EP, одно из трех утверждений должно применяться -
    • Логика обработки является уникальной из логики обработки, выполняемой другими EQ для приложения.
    • Набор идентифицированных элементов данных отличается от других эквалайзеров в приложении.
    • Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие эквалайзеры в приложении.

Кроме того, должны применяться все следующие правила:

  • Логика обработки извлекает данные или управляющую информацию из ILF или EIF.
  • Логика обработки не содержит математической формулы или вычисления.
  • Логика обработки не меняет поведение системы.
  • Логика обработки не поддерживает ILF.

Шаг 6.2. Подсчет DET для каждой транзакционной функции

Примените следующие правила для подсчета DET для EI -

  • Просмотрите все, что пересекает (входит и / или выходит) границы.

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

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

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

  • Не считайте следующие предметы как DET -

    • Атрибуты, созданные внутри границы транзакционной функцией и сохраненные в ILF без выхода за границу.

    • Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.

    • Сгенерированные приложением марки, такие как атрибуты даты и времени.

    • Переменные подкачки, номера страниц и информация о расположении, например, «Строки с 37 по 54 из 211».

    • Средства навигации, такие как возможность навигации по списку с использованием «предыдущий», «следующий», «первый», «последний» и их графические эквиваленты.

Примените следующие правила для подсчета DET для EOs / EQs -

  • Просмотрите все, что пересекает (входит и / или выходит) границы.

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

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

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

  • Не считайте следующие предметы как DET -

    • Атрибуты, созданные в пределах границы без пересечения границы.

    • Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.

    • Сгенерированные приложением марки, такие как атрибуты даты и времени.

    • Переменные подкачки, номера страниц и информация о расположении, например, «Строки с 37 по 54 из 211».

    • Средства навигации, такие как возможность навигации по списку с использованием «предыдущий», «следующий», «первый», «последний» и их графические эквиваленты.

Шаг 6.3. Подсчет FTR для каждой транзакционной функции

Примените следующие правила для подсчета FTR для EI -

  • Подсчитайте FTR для каждого поддерживаемого ILF.
  • Подсчитайте FTR для каждого чтения ILF или EIF во время обработки EI.
  • Подсчитайте только один FTR для каждого ILF, который поддерживается и читается.

Примените следующее правило для подсчета FTR для EO / EQ -

  • Подсчитайте FTR для каждого чтения ILF или EIF во время обработки EP.

Кроме того, примените следующие правила для подсчета FTR для EO -

  • Подсчитайте FTR для каждого ILF, поддерживаемого во время обработки EP.
  • Подсчитайте только один FTR для каждого ILF, который поддерживается и считывается EP.

Шаг 6.4: Определить функциональную сложность для каждой транзакционной функции

финансовые права на передачу Типы элементов данных (DET)
1-4 5-15 > = 16
0-1 L L
2 L ЧАС
> = 3 ЧАС ЧАС

Функциональная сложность: L = низкая; A = Средний; H = высокий

Определите функциональную сложность для каждого EO / EQ, за исключением того, что EQ должен иметь минимум 1 FTR -

Эквалайзер должен иметь минимум 1 FTR

финансовые права на передачу

Типы элементов данных (DET)
1-4 5-15 > = 16
0-1 L L
2 L ЧАС
> = 3 ЧАС ЧАС

Функциональная сложность: L = низкая; A = Средний; H = высокий

Шаг 6.5. Измерение функционального размера для каждой транзакционной функции

Измерьте функциональный размер для каждого EI от его функциональной сложности.

сложность FP Count
Низкий 3
Средний 4
Высоко 6

Измерьте функциональный размер для каждого EO / EQ от его функциональной сложности.

сложность FP Счет для EO FP Счетчик для эквалайзера
Низкий 4 3
Средний 5 4
Высоко 6 6

Шаг 7: Рассчитать функциональный размер (нескорректированное количество функциональных точек)

Чтобы рассчитать функциональный размер, необходимо выполнить следующие шаги:

Шаг 7.1

Вспомните, что вы нашли в Шаге 1. Определите тип счета.

Шаг 7.2

Рассчитать функциональный размер или количество функциональных точек на основе типа.

  • Для подсчета баллов функции разработки перейдите к шагу 7.3.
  • Для подсчета точек функции приложения перейдите к шагу 7.4.
  • Для подсчета очков функции улучшения перейдите к шагу 7.5.

Шаг 7.3

Функция Point Point Count состоит из двух компонентов:

  • Функциональность приложения включена в требования пользователя к проекту.

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

DFP = ADD + CFP

Где,

DFP = количество точек функции разработки

ADD = размер функций, предоставленных пользователю проектом разработки

CFP = размер функции преобразования

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CFP = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

Шаг 7.4

Рассчитать количество точек функции приложения

AFP = ADD

Где,

AFP = Количество функций приложения

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

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

Шаг 7.5

Функция Point Count считает, что следующие четыре компонента функциональности -

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

EFP = ADD + CHGA + CFP + DEL

Где,

EFP = Количество точек функции улучшения

ADD = размер функций, добавляемых проектом расширения

CHGA = размер функций, изменяемых проектом расширения

CFP = размер функции преобразования

DEL = размер функций, удаляемых проектом расширения

ADD = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CHGA = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

CFP = количество FP (ILF) + количество FP (EIF) + количество FP (EI) + количество FP (EO) + количество FP (EQ)

DEL = количество FP (ILF) + количество FP (EIF) + COUNT FP (EI) + количество FP (EO) + количество FP (EQ)

Шаг 8: Определить коэффициент корректировки значения

GSC сделаны необязательными в ПСК 4.3.1 и перенесены в Приложение. Следовательно, этап 8 и этап 9 можно пропустить.

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

Общая характеристика системы Краткое описание
Передача данных Сколько средств связи существует для помощи в передаче или обмене информацией с приложением или системой?
Распределенная обработка данных Как обрабатываются распределенные данные и функции обработки?
Производительность Потребовалось ли пользователю время отклика или пропускная способность?
Сильно используемая конфигурация Насколько интенсивно используется текущая аппаратная платформа, на которой будет выполняться приложение?
Коэффициент транзакций Как часто транзакции выполняются ежедневно, еженедельно, ежемесячно и т. Д.?
Он-лайн ввод данных Какой процент информации вводится онлайн?
Эффективность конечного пользователя Было ли приложение разработано для эффективности конечного пользователя?
Онлайн обновление Сколько ILF обновляется онлайн транзакцией?
Комплексная обработка Имеет ли приложение обширную логическую или математическую обработку?
Повторное использование Было ли приложение разработано для удовлетворения потребностей одного или нескольких пользователей?
Простота установки Насколько сложна конвертация и установка?
Операционная простота Насколько эффективны и / или автоматизированы процедуры запуска, резервного копирования и восстановления?
Несколько сайтов Было ли приложение специально разработано, разработано и поддерживается для установки на нескольких сайтах для нескольких организаций?
Облегчить изменение Было ли приложение специально разработано, разработано и поддержано для облегчения изменений?

Диапазон степени влияния находится в диапазоне от нуля до пяти, от отсутствия влияния до сильного влияния.

Рейтинг Степень влияния
0 Нет или нет влияния
1 Случайное влияние
2 Умеренное влияние
3 Среднее влияние
4 Значительное влияние
5 Сильное влияние во всем

Определите степень влияния для каждого из 14 GSC.

Сумма значений 14 GSC, полученных таким образом, называется общей степенью влияния (TDI).

TDI = ∑ 14 градусов влияния

Затем рассчитайте коэффициент корректировки значения (VAF) как

VAF = (TDI × 0,01) + 0,65

Каждый GSC может варьироваться от 0 до 5, TDI может варьироваться от (0 × 14) до (5 × 14), то есть от 0 (когда все GSC низкие) до 70 (когда все GSC высокие), то есть 0 ≤ TDI ≤ 70. Следовательно, VAF может варьироваться в диапазоне от 0,65 (когда все GSC низкие) до 1,35 (когда все GSC высокие), то есть 0,65 ≤ VAF ≤ 1,35.

Шаг 9: Рассчитайте скорректированное количество функциональных точек

Согласно подходу FPA, который использует VAF (версии CPM до V4.3.1), это определяется,

Скорректированный счетчик FP = нескорректированный счетчик FP × VAF

Где нескорректированное количество FP - это функциональный размер, который вы вычислили на шаге 7.

Поскольку VAF может варьироваться от 0,65 до 1,35, VAF оказывает влияние ± 35% на окончательно скорректированное количество FP.

Преимущества функциональных точек

Функциональные точки полезны -

  • При измерении размера решения вместо размера проблемы.

  • Поскольку требования - это единственное, что необходимо для подсчета функциональных баллов.

  • Как это не зависит от технологии.

  • Как это не зависит от языков программирования.

  • В оценке проектов тестирования.

  • При оценке общих затрат проекта, графика и усилий.

  • В договорных переговорах так же предусмотрен способ более легкого общения с бизнес-группами.

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

  • При создании соотношений с другими показателями, такими как часы, стоимость, численность персонала, продолжительность и другие показатели приложения.

Репозитории ФП

Международная группа стандартизации программного обеспечения (ISBSG) расширяет и поддерживает два хранилища данных ИТ.

  • Проекты развития и совершенствования
  • Приложения для обслуживания и поддержки

В хранилище проектов развития и совершенствования находится более 6000 проектов.

Данные доставляются в формате Microsoft Excel, что упрощает дальнейший анализ, который вы хотите выполнять с ними, или вы даже можете использовать данные для каких-то других целей.

Лицензию на репозиторий ISBSG можно приобрести по адресу - http://www.isbsg.com/.

ISBSG предлагает 10% скидку для членов IFPUG при онлайн-покупках, когда используется код скидки «IFPUGMembers».

Обновления выпуска данных проекта программного обеспечения ISBSG можно найти по адресу - http://www.ifpug.org/isbsg/.

COSMIC и IFPUG совместно разработали Глоссарий терминов для нефункционального программного обеспечения и требований проекта. Его можно скачать с - cosmic-sizing.org