Методы оценки - процесс подсчета FP
Процесс подсчета FP включает следующие шаги -
Step 1 - Определите тип подсчета.
Step 2 - Определите границу счета.
Step 3 - Определите каждый элементарный процесс (EP), необходимый пользователю.
Step 4 - Определите уникальные EP.
Step 5 - Функции измерения данных.
Step 6 - Измерьте транзакционные функции.
Step 7 - Расчет функционального размера (нескорректированное количество функциональных баллов).
Step 8 - Определите коэффициент корректировки значения (VAF).
Step 9 - Рассчитайте количество скорректированных функциональных точек.
Note- Общие характеристики системы (GSC) сделаны необязательными в CPM 4.3.1 и перенесены в Приложение. Следовательно, шаги 8 и 9 можно пропустить.
Шаг 1. Определите тип подсчета
Есть три типа подсчета функциональных баллов:
- Подсчет очков функции развития
- Подсчет точек функции приложения
- Подсчет очков улучшенной функции
Подсчет очков функции развития
Функциональные баллы можно подсчитывать на всех этапах проекта разработки от требования до этапа реализации. Этот тип подсчета связан с новыми разработками и может включать прототипы, которые могли потребоваться в качестве временного решения, поддерживающего усилия по преобразованию. Этот тип подсчета называется подсчетом базовых функциональных баллов.
Подсчет точек функции приложения
Количество приложений рассчитывается как количество предоставленных функций и исключает любые усилия по преобразованию (прототипы или временные решения) и существующие функциональные возможности, которые могли существовать.
Подсчет очков улучшенной функции
Когда в программное обеспечение после производства вносятся изменения, они считаются улучшениями. Для определения размера таких улучшенных проектов в приложении добавляется, изменяется или удаляется счетчик функциональных точек.
Шаг 2: Определите границу счета
Граница указывает границу между измеряемым приложением и внешними приложениями или доменом пользователя. (См. Рисунок 1)
Чтобы определить границу, поймите -
- Цель подсчета функциональных баллов
- Объем измеряемого приложения
- Как и какие приложения хранят какие данные
- Сферы деятельности, поддерживающие приложения
Шаг 3. Определите каждый элементарный процесс, необходимый пользователю.
Составьте и / или разложите функциональные требования пользователя на наименьшую единицу деятельности, которая удовлетворяет всем следующим критериям:
- Имеет значение для пользователя.
- Представляет собой законченную транзакцию.
- Самостоятельно.
- Оставляет бизнес подсчитываемого приложения в согласованном состоянии.
Например, функциональное требование пользователя - «Ведение информации о сотруднике» можно разложить на более мелкие действия, такие как добавление сотрудника, изменение сотрудника, удаление сотрудника и запрос о сотруднике.
Каждая идентифицированная таким образом единица деятельности представляет собой элементарный процесс (EP).
Шаг 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 должно применяться одно из трех утверждений:
- Логика обработки отличается от логики обработки, выполняемой другими ОР для приложения.
- Набор идентифицированных элементов данных отличается от других ОР в приложении.
- Упомянутые ILF или EIF отличаются от файлов, на которые ссылаются другие EO в приложении.
Кроме того, должно применяться одно из следующих правил -
- Логика обработки содержит по крайней мере одну математическую формулу или расчет.
- Логика обработки поддерживает по крайней мере один ILF.
- Логика обработки изменяет поведение системы.
Внешний запрос
Внешний запрос (EQ) - это элементарный процесс, который отправляет данные или управляющую информацию за границу. Основная цель эквалайзера - предоставить пользователю информацию посредством извлечения данных или управляющей информации.
Логика обработки не содержит математических формул или вычислений и не создает производных данных. Во время обработки не поддерживается ни ILF, ни поведение системы.
Должны применяться все следующие правила -
- Отправляет данные или управляющую информацию за пределы границы приложения.
- Для идентифицированного EP должно применяться одно из трех утверждений:
- Логика обработки отличается от логики обработки, выполняемой другими эквалайзерами приложения.
- Набор идентифицированных элементов данных отличается от других EQ в приложении.
- Упомянутые файлы ILF или EIF отличаются от файлов, на которые ссылаются другие эквалайзеры в приложении.
Кроме того, должны применяться все следующие правила:
- Логика обработки извлекает данные или управляющую информацию из ILF или EIF.
- Логика обработки не содержит математических формул или вычислений.
- Логика обработки не меняет поведение системы.
- Логика обработки не поддерживает ILF.
Шаг 6.2: Подсчитайте DET для каждой транзакционной функции
Примените следующие правила для подсчета DET для EI -
Просмотрите все, что пересекает (входит и / или выходит) за границу.
Подсчитайте одно DET для каждого уникального идентифицируемого пользователем неповторяющегося атрибута, который пересекает (входит и / или выходит) за границу во время обработки транзакционной функции.
Подсчитайте только одно DET для каждой транзакционной функции для возможности отправки ответного сообщения приложения, даже если имеется несколько сообщений.
Подсчитайте только одно DET на каждую транзакционную функцию для возможности инициировать действие (я), даже если для этого есть несколько способов.
Не считайте следующие элементы как DET -
Атрибуты, сгенерированные внутри границы транзакционной функцией и сохраненные в ILF без выхода за границу.
Литералы, такие как заголовки отчетов, идентификаторы экрана или панели, заголовки столбцов и заголовки атрибутов.
Приложение генерирует штампы, такие как атрибуты даты и времени.
Переменные пейджинга, номера страниц и информация о местоположении, например, «Строки с 37 по 54 из 211».
Вспомогательные средства навигации, такие как возможность перемещаться по списку, используя «предыдущий», «следующий», «первый», «последний» и их графические эквиваленты.
Примените следующие правила для подсчета DET для EO / EQ:
Просмотрите все, что пересекает (входит и / или выходит) за границу.
Подсчитайте одно 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 для ОР:
- Подсчитайте FTR для каждого ILF, поддерживаемого во время обработки EP.
- Подсчитайте только один FTR для каждого ILF, который поддерживается и читается EP.
Шаг 6.4: Определите функциональную сложность для каждой транзакционной функции
| FTRs | Типы элементов данных (DET) | ||
|---|---|---|---|
| 1-4 | 5-15 | >=16 | |
| 0-1 | L | L | А |
| 2 | L | А | ЧАС |
| > = 3 | А | ЧАС | ЧАС |
Функциональная сложность: L = Низкий; A = Среднее; H = Высокий
Определите функциональную сложность для каждого EO / EQ, за исключением того, что EQ должен иметь минимум 1 FTR -
Эквалайзер должен иметь минимум 1 FTR FTRs |
Типы элементов данных (DET) | ||
|---|---|---|---|
| 1-4 | 5-15 | > = 16 | |
| 0-1 | L | L | А |
| 2 | L | А | ЧАС |
| > = 3 | А | ЧАС | ЧАС |
Функциональная сложность: L = Низкий; A = Среднее; H = Высокий
Шаг 6.5: Измерьте функциональный размер каждой транзакционной функции
Измерьте функциональный размер каждого EI по его функциональной сложности.
| Сложность | Количество FP |
|---|---|
| Низкий | 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
Подсчет очков функции разработки состоит из двух функциональных компонентов:
Функциональность приложения включена в требования пользователя к проекту.
Функциональность конвертации включена в требования пользователя к проекту. Функциональные возможности преобразования состоят из функций, предоставляемых только при установке для преобразования данных и / или обеспечения других заданных пользователем требований к преобразованию, таких как специальные отчеты преобразования. Например, существующее приложение может быть заменено новой системой.
DFP = ADD + CFP
Куда,
DFP = Подсчет очков функции развития
ADD = Размер функций, предоставляемых пользователю проектом разработки
CFP = Размер функции преобразования
ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
CFP = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
Шаг 7.4
Вычислить количество точек функции приложения
AFP = ADD
Куда,
AFP = Количество точек функции приложения
ADD = Размер функций, предоставленных пользователю проектом разработки (исключая размер любой функции преобразования), или функциональность, которая существует при подсчете приложения.
ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
Шаг 7.5
Счетчик точек функции расширения учитывает следующие четыре компонента функциональности:
- Функциональность, добавляемая в приложение.
- Функциональность, измененная в Приложении.
- Функциональность конвертации.
- Функциональность, удаленная из приложения.
EFP = ADD + CHGA + CFP + DEL
Куда,
EFP = Подсчет очков улучшающей функции
ADD = Размер функций, добавляемых проектом улучшения
CHGA = Размер функций, изменяемых проектом улучшения
CFP = Размер функции преобразования
DEL = Размер функций, удаляемых проектом улучшения
ADD = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
CHGA = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
CFP = Счетчик FP (ILF) + Счетчик FP (EIF) + Счетчик FP (EI) + Счетчик FP (EOs) + Счетчик FP (EQ)
DEL = Подсчет FP (ILF) + подсчет FP (EIF) + подсчет FP (EI) + подсчет FP (EO) + подсчет FP (EQ)
Шаг 8: Определите коэффициент корректировки значения
GSC сделаны необязательными в CPM 4.3.1 и перенесены в Приложение. Следовательно, шаги 8 и 9 можно пропустить.
Коэффициент корректировки стоимости (VAF) основан на 14 GSC, которые оценивают общую функциональность подсчитываемого приложения. GSC - это бизнес-ограничения пользователей, не зависящие от технологий. Каждая характеристика имеет связанные описания для определения степени влияния.
| Общая характеристика системы | Краткое описание |
|---|---|
| Передача данных | Сколько существует средств связи для передачи или обмена информацией с приложением или системой? |
| Распределенная обработка данных | Как обрабатываются распределенные данные и функции обработки? |
| Спектакль | Потребовалось ли пользователю время отклика или пропускная способность? |
| Широко используемая конфигурация | Насколько активно используется текущая аппаратная платформа, на которой будет выполняться приложение? |
| Скорость транзакции | Как часто транзакции выполняются ежедневно, еженедельно, ежемесячно и т. Д.? |
| Он-лайн ввод данных | Какой процент информации вводится онлайн? |
| Эффективность конечного пользователя | Было ли приложение разработано для повышения эффективности конечного пользователя? |
| Онлайн-обновление | Сколько ILF обновляется с помощью онлайн-транзакции? |
| Комплексная обработка | Есть ли в приложении обширная логическая или математическая обработка? |
| Возможность повторного использования | Было ли приложение разработано для удовлетворения потребностей одного или нескольких пользователей? |
| Легкость установки | Насколько сложна переоборудование и установка? |
| Удобство работы | Насколько эффективны и / или автоматизированы процедуры запуска, резервного копирования и восстановления? |
| Несколько сайтов | Было ли приложение специально разработано, разработано и поддержано для установки на нескольких сайтах для нескольких организаций? |
| Содействовать изменениям | Было ли приложение специально разработано, разработано и поддержано для облегчения изменений? |
Диапазон степени влияния - от нуля до пяти, от отсутствия влияния до сильного влияния.
| Рейтинг | Степень влияния |
|---|---|
| 0 | Нет или не влияет |
| 1 | Случайное влияние |
| 2 | Умеренное влияние |
| 3 | Среднее влияние |
| 4 | Значительное влияние |
| 5 | Сильное влияние во всем |
Определите степень влияния для каждого из 14 GSC.
Сумма значений 14 GSC, полученных таким образом, называется общей степенью влияния (TDI).
TDI = ∑14 Degrees of Influence
Затем рассчитайте коэффициент корректировки значения (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), это определяется следующим образом:
Adjusted FP Count = Unadjusted FP Count × VAF
Где нескорректированное количество FP - это функциональный размер, рассчитанный на шаге 7.
Поскольку VAF может изменяться от 0,65 до 1,35, VAF оказывает влияние ± 35% на окончательное скорректированное количество FP.
Преимущества функциональных очков
Функциональные точки полезны -
Измеряя размер решения, а не размер проблемы.
Поскольку требования - это единственное, что нужно для подсчета функциональных баллов.
Поскольку это не зависит от технологии.
Поскольку он не зависит от языков программирования.
При оценке тестовых проектов.
При оценке общей стоимости проекта, графика и усилий.
В переговорах по контрактам, поскольку это обеспечивает более легкий способ общения с бизнес-группами.
Поскольку он количественно определяет и присваивает значение фактическому использованию, интерфейсам и целям функций в программном обеспечении.
При создании соотношений с другими показателями, такими как часы, стоимость, численность персонала, продолжительность и другие показатели приложения.
Репозитории FP
International Software Benchmarking Standards Group (ISBSG) растет и поддерживает два репозитория для ИТ-данных.
- Проекты развития и усовершенствования
- Приложения для обслуживания и поддержки
В репозитории проектов развития и усовершенствования находится более 6000 проектов.
Данные предоставляются в формате Microsoft Excel, что упрощает дальнейший анализ, который вы хотите с ними делать, или вы даже можете использовать данные для других целей.
Лицензию на репозиторий ISBSG можно приобрести у - http://www.isbsg.com/
ISBSG предлагает 10% скидку для членов IFPUG на покупки в Интернете при использовании кода скидки «IFPUGMembers».
Обновления выпуска данных проекта программного обеспечения ISBSG можно найти по адресу - http://www.ifpug.org/isbsg/
COSMIC и IFPUG совместно разработали Глоссарий терминов для нефункционального программного обеспечения и требований проекта. Его можно скачать с - cosmic-sizing.org