Презентация Function Point Analysis

1. Function Point Analysis

2. SLOC (Source Lines of Code)

Такая, на первый взгляд очевидная метрика сложности разработки
программного продукта, как число строк исходного кода SLOC
(Source Lines of Code), не дает достоверные результаты, поскольку
не учитывает:
• высокоуровневые языки или языки визуального
программирования требуют гораздо меньшего числа строк
кода
• число строк исходного кода зависит от уровня мастерства
программиста
• в программистском сообществе не достигнуто соглашения о
методе подсчета строк кода
• фактическое число SLOC остается неизвестным до тех пор, пока
проект не будет почти завершен

3.

В основе FPA лежит взгляд на ПС извне, с позиций
пользователя системы (а не «со стороны» ее
внутренних свойств (таких, как SLOC))
Методология FPA базируется на идее декомпозиции
функций и данных до предельно допустимого (с точки
зрения пользователя) уровня.
Объем функциональных возможностей ПС
(функциональный размер) определяется в так
называемых условных единицах функциональности,
УЕФ (или FP – от Function Points)

4. Программный компонент

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

5. Ранняя оценка размера

Исходная информация, необходимая для выполнения
оценки размера на ранних стадиях ЖЦ, может быть
получена из документации на ПС (описания
требований, проекта, постановок задач, диаграмм
потоков данных)
Метод оценивания не требует знания технологии
реализации ПК и особенностей среды его
функционирования. Оцениванию подлежат
запрошенные пользователем функции ПК по
обработке данных и связанные с ними
информационные объекты.

6. Взгляд пользователя на процесс функционирования ПК

7. Определения

Граница ПК - установленная пользователем граница между информационнофункциональными объектами измеряемого ПК и других (внешних) ПК или предметной
области пользователя.
Внутренние данные ПК - идентифицируемая конечным пользователем группа логически
связанных данных или управляющая информация, сохраняемая, обновляемая, добавляемая
или удаляемая в пределах границы ПК.
Внешние данные ПК - идентифицируемая конечным пользователем группа логически
связанных данных или управляющая информация, используемая (но неизменяемая) в
пределах границы ПК, и являющаяся внутренними данными в пределах границы другого ПК.
Вход - данные или управляющая информация, попадающая извне (от пользователя либо
другого ПК) в пределы границы измеряемого ПК.
Выход - данные или управляющая информация, покидающая границы ПК (и направляемая
пользователю или другому ПК).
• Запрос - запрашиваемая и в ответ получаемая пользователем информация.
Это выход, непосредственно связанный со входом и получаемый без выполнения каких-либо
действий над внутренними или внешними данными ПК (кроме выборки и элементарного
редактирования).
• Размер ПК – суммарное число условных единиц функциональности, приписываемых каждой
функции в зависимости от количества и сложности информационных объектов, с которыми
она работает.

8. Процесс подсчета УЕФ (FP) состоит из 2 этапов:

• измерение объема и сложности
информационных объектов, с которыми
работает ПК;
• измерение объема и сложности
элементарных функций по обработке
данных в ПК.

9. Оценка размера и сложности объектов данных

• Шаг 1. Анализ документации ПС и
определение перечня всех логически
связанных групп данных, с которыми должен
работать ПК (например, больничная карта,
договор, ведомость, командный файл,
диагностическое сообщение и др.).
• Шаг 2. Определение границы измеряемого ПК
и классификация данных на:
- внутренние логические объекты ВЛО;
- внешние интерфейсные объекты ВИО.

10. Определения ВЛО и ВИО

• Внутренний логический объект (ВЛО) - идентифицируемая
конечным пользователем группа логически связанных данных и
управляющая информация, сохраняемая и сопровождаемая
(добавляемая, обновляемая или удаляемая) в пределах
границы ПК.
• Внешний интерфейсный объект (ВИО) - идентифицируемая
конечным пользователем группа логически связанных данных
или управляющая информация, используемая измеряемым ПК,
но сопровождаемая в пределах границы другого ПК.
• ВИО является внутренним логическим объектом в другом ПК.
Например, к ВИО могут относиться классификаторы,
нормативно-справочная информация, вспомогательная
информация (помощь) по работе с ПК и др.

11. Правила отнесения логической группы данных или управляющей информации к ВЛО

• группа данных выделяется в соответствии с
требованиями пользователя к данным ПК;
• группа данных сопровождается в пределах
границы ПК;
• модификация группы данных выполняется в
рамках элементарного процесса,
идентифицируемого пользователем.
• группа данных не может быть отнесена к ВИО для
данного ПК.
• Элементарный процесс – это элементарная единица действия,
идентифицируемая (воспринимаемая) конечным
пользователем в предметной области. Это самостоятельная
технологическая операция в ПК, по завершении выполнения
которой предметная область остается в целостном состоянии

12. Правила отнесения логической группы данных или управляющей информации к ВИО

• группа данных выделяется в соответствии с
требованиями пользователя к данным ПК;
• группа данных используется в ПК;
• группа данных не сопровождается в
измеряемом ПК;
• группа данных является ВЛО по крайней
мере в одном из других ПК;
• группа данных не может быть отнесена к
ВЛО измеряемого ПК.

13. Шаг 3. Определение сложности каждого ВЛО и ВИО

• Уровень сложности может квалифицироваться как «низкий»,
«средний» и «высокий». Отнесение объекта к тому или иному
уровню сложности производится исходя из числа подгрупп
данных и числа элементарных данных ВЛО или ВИО.
• Подгруппа данных объекта (ПДО) - идентифицируемая
пользователем подгруппа группы данных ВЛО или ВИО. ПДО не
является самостоятельной группойданных. Например, объект
«больничная карта» может иметь ПДО «информация о
болезни» (диагноз, назначение и др.) и «информация о
больном» (паспортные данные, адрес) и др.
• Элементарное данное объекта (ЭДО) - уникальное
(неповторяющееся) идентифицируемое пользователем данное
(поле) ВЛО или ВИО.

14. Матрица оценки сложности данных ПК

15. Шаг 4. Взвешивание ВЛО и ВИО по уровням сложности

Веса ВЛО и ВИО

16. Шаг 5. Подсчет условных единиц функциональности по всем ВЛО и ВИО

Для подсчета условных единиц
функциональности информационных объектов
(УЕФо) необходимо определить количество ВЛО
и ВИО по каждому уровню сложности и
полученные значения просуммировать.
Например, если выявлено 2 ВЛО низкого уровня
сложности, 3 - среднего, а также 1 ВИО среднего
уровня сложности и 2 - высокого, то

17. Оценка размера и сложности функций обработки данных

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

18. Шаги для измерения элементарных функций обработки данных ПК

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

19.

• Шаг 2. Отнесение каждой элементарной
функции в пределах одного
функционального требования к одной из
трех категорий:
· внешний ввод;
· внешний вывод;
· внешний запрос

20. Определения

• Внешний ввод (ВВД) – элементарный процесс обработки
входа в ПК.
ВВД выполняет функцию управления ПК или сопровождения (добавления,
обновления или удаления) данных в ВЛО. Например, ввод данных в поле экрана,
выбор данных из списка, обработка щелчка на кнопке.
• Внешний вывод (ВЫВ) - элементарный процесс генерации
выхода из ПК.
Например, формирование и печать отчета, формирование и вывод данных на
экран.
• Внешний запрос (ЗАП) - элементарный процесс непосредственной
выборки
запрашиваемых пользователем по определенному критерию данных из ВЛО или
ВИО без какого-либо изменения и без сопровождения данных в ВЛО.
Например, получение тематической справки, получение контекстной помощи,
вывод классификатора, многокритериальный поиск информации.

21. Шаг 3. Определение сложности каждого ВВД, ВЫВ и ЗАП

Уровень сложности функции может квалифицироваться как
«низкий», «средний» и «высокий». Отнесение функции к тому или
иному уровню сложности производится исходя из числа
ссылочных объектов функции и числа элементарных данных
функции, представляющих вход, выход или выборку.
• Ссылочный объект функции (СОФ) - внутренний логический
объект, который сопровождается функцией, или внешний
интерфейсный объект, который используется функцией
измеряемого ПК.
• Элементарное данное функции (ЭДФ) - уникальное
(неповторяющееся) идентифицируемое пользователем данное
(поле), относящееся ко входу, выходу или выборке функции.
Например, вводимое поле, список, управляющее воздействие,
отождествляемое со щелчком на управляющем объекте экрана
(кнопке).

22. Взаимосвязь понятий в FPA

23. Матрица оценки уровня сложности ВВД

Матрица оценки уровня сложности ВЫВ

24. Шаг 4. Взвешивание ВВД, ВЫВ и ЗАП по уровням сложности

Шаг 5. Подсчет условных единиц функциональности по
всем функциям обработки данных ПК
Для подсчета условных единиц функциональности для функций (УЕФф)
необходимо определить количество ВВД, ВЫВ и ЗАП по каждому уровню
сложности для каждого функционального требования и просуммировать
значения.

25. Шаг 6. Определение размера (объема) функциональных возможностей (показателя функционального размера (ПФР))

26. Эквивалентное число строк исходного кода для УЕФ

27. Учет нефункциональных требований к программной системе

28.

29. Оценка общесистемных характеристик

выполняется экспертным путем по 5 уровням
сложности от 0 до 5:
• 0 – не оказывает никакого влияния;
• 1 – оказывает несущественное влияние;
• 2 - оказывает умеренное влияние;
• 3 - оказывает среднее влияние;
• 4 - оказывает существенное влияние;
• 5 – оказывает сильное влияние.

30. Учет требований по передаче данных

Примечание. Приложение, которое поддерживает web-запросы и
локальный доступ, должно получить оценку 3, а приложение, которое
допускает модификацию объектов ВЛО через Интернет и локальное
обновление, должно получить оценку 5.

31. Учет требований по распределенной обработке данных

32. Учет требований по производительности

33. Учет требований по конфигурации и занятости технических средств

34. Учет требований по интенсивности транзакций

35. Учет требований по оперативному вводу данных

36. Учет требований по интенсивности транзакций

37. Учет требований по оперативному вводу данных

38. Учет требований по эффективности работы пользователя

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

39.

40. Учет требований по оперативности модификации данных

41. Учет требований по сложности обработки данных

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

42. Учет требований по повторному использованию

43. Учет требований по простоте установки

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

44. Учет требований по простоте использования

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

45. Учет требований по распространенности приложения

Если приложение должно устанавливаться во многих местах (многих
организациях), в проекте должны отражаться вопросы эффективного
функционирования приложения в различных аппаратно-программных
средах.

46. Учет требований по простоте внесения изменений

Если приложение специально разрабатывается так, чтобы в него было просто вносить
изменения, в его проекте должны предусматриваться следующие возможности:
• · предоставление гибких справок и отчетов, получением которых можно
• управлять с помощью простых запросов; например, логика «И/ИЛИ» применима
• только к одному ВЛО (учитывается при подсчете как один элемент);
• · предоставление гибких справок и отчетов, получением которых можно
• управлять с помощью запросов средней сложности; например, логика «И/ИЛИ»
• применима к более чем одному ВЛО (учитывается при подсчете как 2 элемента);
• · предоставление гибких справок и отчетов, получением которых можно
• управлять с помощью сложных запросов; например, комбинация логики «И/ИЛИ»
• применима к одному или более ВЛО (учитывается при подсчете как 3 элемента);
• · эталонные (контрольные) бизнес-данные хранятся в таблицах, которые
• поддерживаются потребителем с помощью оперативных интерактивных процессов,
• но изменения вступают в действие только на следующий рабочий день;
• · эталонные (контрольные) бизнес-данные хранятся в таблицах, которые
• поддерживаются потребителем с помощью оперативных интерактивных процессов,
• и изменения вступают в силу немедленно (учитывается как два элемента).

47.

48. Показатель сложности технических требований

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

49. Пример

50. Выделение компонент

На основе DFD схемы выделяем следующие компоненты и подсчитываем их:
Внешние входы (EI):
– situation ok (low) → 1 EI
– store items to warehouse (low) → 1 EI
Внешние выходы (EO):
– send bill to customer (low) → 1 EO
– report stored items list (average) → 1 EO
– report customer item list (high) → 1 EO
Внешние запросы (EQ):
– Send store request (low) → 1 EQ
– Send request to get items (low) → 1 EQ
– item place information (average) → 1 EQ
Внутренние логические файлы (ILF):
–
–
–
–
warehouse information (low) → 1 ILF
items information (low) → 1 ILF
retrieve items locations (low) → 1 ILF
places information (low) → 1 ILF

51. Расчет функциональных точек (FP)

52. Подсчет

• EI:
2 × 3 = 6 FP
• EO:
4 + 5 + 7 = 16 FP
• EQ:
2 × 3 + 4 = 10 FP
• ILF:
4 × 7 = 28 FP
• Общее количество необработанных FP(ПФР):
• 6 + 16 + 10 + 28 = 60

53. Корректировка по фактору сложности (КСложн):

• Сумма баллов:
2+3+0+0+1+1+3+5+2+4+4+1+0+1=27
• Используем формулу для корректировки
FP:
• FPкор = 60*(0.65+0.01*27) = 55.2

54. Определение количества строк кода (SLOC):

• Для перевода функциональных точек в
строки кода на C++ используем средний
коэффициент:
• SLOC = 55.2*80=4416 СТРОК КОДА