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

1. www.luxoft.com
Метод Функциональных Точек
Основы оценки размера проекта методом
функциональных точек
Основано на материалах David Consulting Group
Светлана Мухина

2. www.luxoft.com
Знакомимся
Светлана Мухина
ICAgile ICP, ICP-ATF, ICP-BVA, ICP- ACC, PSM I, CSPO, Professional Coach, Certified NLP
Practitioner, KMP Foundation I
Agile and Professional Coach at Luxoft Agile Practice
Опыт работы: 14+ лет в IT, Agile коуч, руководитель проектов,
компьютерный лингвист, технический писатель, бизнес-аналитик
Интересы: управление проектами, процессные трансформации,
коучинг, психология
Хобби: верховая езда, музыка, покер, плаванье, путешествия
https://www.linkedin.com/in/svetlanamukhina
https://www.facebook.com/Svetlana.Mukhina8

3. www.luxoft.com
Теория

4. www.luxoft.com
Размер
Задачи
Усилия
Человек
о-часы
Длительность
проекта
Время
Изменения
RFC
Люди
Команда
проекта
Дефекты
Качество
Критичные
ресурсы
Ограничения
Оцениваем проект
Основано на материалах David Consulting Group

5. www.luxoft.com
История
Анализ функциональных точек — стандартный метод измерения размера
программного продукта с точки зрения пользователей системы.
Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х.
Метод был впервые опубликован в 1979 году.
В 1986 году была сформирована Международная Ассоциация
Пользователей Функциональных Точек (International Function Point User
Group — IFPUG), которая опубликовала несколько ревизий метода.
Основано на материалах David Consulting Group

6. www.luxoft.com
Основные Термины
• Единица измерения функциональности программного обеспечения
с точки зрения пользовательской системы.Функциональная точка
• Человек или система, которая взаимодействует с программным
обеспечением.Пользователь
• Функциональные пользовательские требования так, как они
воспринимаются пользователем.User View
• Набор функций, который должна выполнять система в терминах
задач и сервисов. Эти требования задают “что” система должна
делать.
Функциональные
пользовательские
требования
• Эти требования задают с соблюдением “каких условий” система
должна что-то делать.
Нефункциональные
пользовательские
требования
Основано на материалах David Consulting Group

7. www.luxoft.com
• ФТ помогают точно оценивать разменость
приложения;
• ФТ могут быть подсчитаны разными людьми, в
разное время с одним и тем же результатом;
• ФТ могут быть подсчитаны прокси;
• ФТ понятны для не технических пользователей;
• С помощью ФТ можно сравнить эффективность
инструментов, команды, среды и т.д.
• Небольшой риск инфляции по сравнению с
методом подсчета строк кода или стори
поинтами;
• ФТ можно подсчитать используя написанные
требования или готовое приложение;
• ФТ - это не лучший способ оценки дефектов или
задач, связанных с производительностью
приложения;
• ФТ не очень эффективны для оценки в ситуации,
когда оценённая функциональность будет
имплементирована одни или двумя разработчиками;
• Команда разработки не принимает участие в оценке
задач;
• Метод ФТ требует значительных инвестиций в
обучение;
• Для эффективного использования метода ФТ
необходима постоянная практика;
Преимущества и недостатки метода Функциональных Точек
Основано на материалах David Consulting Group

8. www.luxoft.com
Практика

9. www.luxoft.com
Собираем
доступную
документацию
Определяем
объем работ,
границы
приложения,
функциональны
е требования
Идентифицируем
основные
функциональные
компоненты
Считаем
размер в ФТ
Документируем
результаты
подсчета
Предоставляем
результаты
заказчику
Процесс оценки в функциональных точках
Основано на материалах David Consulting Group

10. www.luxoft.com
Устанавливаем Границы Приложения
Границы приложения – это абстрактный интерфейс между
приложением и всеми его пользователями
• Что является «внешним» по отношению к оцениваемому продукту?
• Где располагается «граница системы», через которую проходят транзакции
передаваемые или принимаемые продуктом, с точки зрения пользователя?
• Какие данные поддерживаются приложением, а какие — внешние?
Основано на материалах http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml

11. www.luxoft.com
Определяем тип объекта оценки
Мы считаем
• Разработку. Оцениваем
количество функциональности
поставляемой пользователям в
первом релизе продукта.
• Изменения. Оцениваем
необходимые доработки:
добавление, изменение и
удаление функционала.
• Продукт. Оцениваем размер уже
существующего продукта.
Мы не считаем
• Поддержку – действия
необходимые совершить для
устранения дефектов в
программном обеспечение
• Улучшения - действия
необходимые совершить для
улучшения производительности,
надежности, поддерживаемости
или других атрибутов
программного обеспечения
• Нефункциональные требования
Основано на материалах David Consulting Group

12. www.luxoft.com
Что мы считаем?

13. www.luxoft.com
Внутренние логические файлы и внешние интерфейсные файлы
Приложение
Внутренний логический файл (ILFs) —
выделяемая пользователем логически
связанная группы данных или блок
управляющей информации, которые
поддерживаются внутри продукта.
Внешний интерфейсный файл (EIFs) —
выделяемый пользователем логически
связанная группы данных или блок
управляющей информации, на который
ссылается продукт, но которые
поддерживаются вне продукта.
Не считайте как ILF и EIF:
• Файлы необходимы для поддержки той или иной технологии
• Файлы индексации и сортировки
• Временные файлы данных
• Другие технические файлы
Основано на материалах David Consulting Group

14. www.luxoft.com
Элементы ILFs и EIFs
Количество ILFs и EIFs и их функциональная сложность влияет на размер приложения в
функциональных точках. Функциональная сложность файлов определяется количеством связанных с
ними элементов: логических групп данных и неповторяемых уникальных полей.
Приложение
Внешний интерфейсный файл
(EIF)
RETs
DETs
DETs
DETs
Внутренний логический файл (ILF)
RET (record element type) логическая
группа данных, например, адрес,
паспорт, телефонный номер.
DET (data element type)
неповторяемое уникальное поле
данных, например, Имя Клиента
Основано на материалах David Consulting Group

15. www.luxoft.com
Транзакции
Приложение
External Interface File
(EIF)
RETs
DETs
DETs
DETs
Internal Logical File (ILF)
RET - A record element type (RET) is a
user recognizable subgroup of data
elements within an ILF or EIF
DET is a unique user recognizable,
non-repeated attribute
User
EI = External Input
EO = External Output
EQ = External Inquiry
EI
EO
EQ
Основано на материалах David Consulting Group

16. www.luxoft.com
Описание Транзакций
Транзакция — это элементарный процесс, представляющий значение для пользователя:
EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных
или управляющей информации, поступающих в систему из вне.
- Слова, которые идентифицируют EIs: Add, Make Inactive, Allocate, Modify, Assign, Record, Associate,
Remove, Change, Reset, Create, Delete, Import, Reverse, Set, Undo, Update, Upload, Withdraw;
EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации
данных или управляющей информации, которые выходят за пределы системы. Предполагает
определенную логику обработки или вычислений информации из одного или более ILF.
- Слова, которые идентифицируют EOs: Adjust, Export, Generate, Notify, Print, Report, Summary
EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний
запрос извлекает данные или управляющую информацию из ILF или EIF.
- Слова, которые идентифицируют EQs: Browse, Display, Enquire, Extract, Inquire, List, Pick List, View
Основано на материалах David Consulting Group

17. www.luxoft.com
Определяем типы транзакций
Основано на материалах David Consulting Group,
http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml
Функция Тип транзакции
EI EO EQ
Изменяет поведение системы О Д NA
Поддерживает один или более ILF О Д NA
Представление информации пользователю Д О О
О — основная;
Д — дополнительная;
NA — не применима.

18. www.luxoft.com
Пример #1 – определяем файлы и транзакции для радиобудильника
Inputs (EIs)
• Set time
• Set alarm
• Set type of alarm (radio, buzz) Set radio station
• Set volume of radio
• Set am/fm
• Set Snooze
• On/Off alarm
Outputs (EOs/EQs)
• Alarm
• Sound(Music/ Radio/Buzzer)
• Display Time
Internal Data Stores (ILFs)
• Time Data (Alarm Data/Time Data)
• Radio Data
External Data Sources (EIFs)
• Radio Frequency
from David Consulting Group

19. www.luxoft.com
Пример #2 – считаем уникальные поля и группы данных
Основано на материалах David Consulting Group

20. www.luxoft.com
Пример #2 – Результаты
Основано на материалах David Consulting Group

21. www.luxoft.com
Как мы считаем?

22. www.luxoft.com
RETs 1-19
DETs
20-50
DETs
51+
DETs
1 Low Low Avg
2-5 Low Avg High
6+ Avg High High
Матрица сложности данных для ILF и EIF
Оценка сложности файлов ILF и EIF
Оценка сложности файлов зависит от количества неповторяемых
уникальных полей данных (DETs) и количества логических групп данных

23. www.luxoft.com
Матрица сложности данных EI
FTRs 1-4
DETs
5-15
DETs
16+
DETs
0-1 Low Low Avg
2 Low Avg High
3+ Avg High High
Матрица сложности данных для EO и EQ
FTRs 1-5
DETs
6-19
DETs
20+
DETs
0-1 Low Low Avg
2-3 Low Avg High
4+ Avg High High
Оценка сложности транзакций
Оценка сложности транзакций зависит от количество различных файлов
(информационных объектов (File type referenced FTR типа ILF и/или EIF)
модифицируемых или считываемых в транзакции.

24. www.luxoft.com
Type Low Avg High Total
EI _ X 3 + _ X 4 + _X6 =
EO _ X 4 + _ X 5 + _X7 =
EQ _ X 3 + _ X 4 + _X6 =
ILF _ X 7 + _ X 10 + _X15 =
EIF _ X 5 + _ X 7 + _X6 =
Вес транзакций в функциональных точках

25. www.luxoft.com
Пример #3 – Считаем функциональные точки приложения
ОснованонаматериалахDavidConsultingGroup

26. www.luxoft.com
Пример #3 – Результаты
Description ILF/EIF/EI/EO/EQ FTRs DETs
Add EI 1 6
Change EI 1 6
Delete EI 1 5
Student Data ILF 1 4
16 FPs
Основано на материалах David Consulting Group
(ЗFPs + ЗFPs + ЗFPs + 7FPs)

27. www.luxoft.com
Выравниваем
функциональные точки

28. www.luxoft.com
Общесистемные требования
Помимо функциональных требований на продукт накладываются общесистемные требования General
Systems Characteristics (GSCs), которые ограничивают разработчиков в выборе решения и увеличивают
сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение
фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта:
Обмен данными
Распределенная
обработка данных
Производительность
Ограничения по
аппаратным
ресурсам
Транзакционная
нагрузка
Интенсивность
взаимодействия с
пользователем
Эргономика
Интенсивность
изменения данных
Сложность
обработки
Повторное
использование
Удобство
инсталляции
Удобство
администрирования
Портируемость Гибкость
Основано на материалах David Consulting Group
http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml

29. www.luxoft.com
Определяем фактор
выравнивания (VAF, value added factor)
Оцениваем каждый
критерий от 1 до 5
Считаем общую степень
влияния (total degree of
influence, TDI)
Используя формулу, считаем
фактор выравнивания
Формула: VAF=(TDI*0.01)+0.65
Основано на материалах David Consulting Group
Общесистемные требования Вес
Обмен данными 5
Распределенная обработка данных 4
Производительность 3
Ограничения по аппаратным ресурсам 2
Транзакционная нагрузка 3
Интенсивность взаимодействия с пользователем 5
Эргономика 4
Интенсивность изменения данных 5
Сложность обработки 2
Повторное использование 3
Удобство инсталляции 1
Удобство администрирования 3
Портируемость 2
Гибкость 5
Общая степень влияния 47
Фактор выравнивания 1.12
Значени
е
Влияние на
систему
0 Не влияет
1 Незначительное
2 Умеренное
3 Среднее
4 Значительное
5 Сильное

30. www.luxoft.com
Пример #4 – Используем фактор выравнивания
Если количество не выровненных функциональных точек равно 100 (fps) и VAF равен 1.1,тогда
количество выравненных функциональных точек будет 110 fps.
Выровненные функциональные точки = не выровненные функциональные точки x VAF
 Ни одно приложение на получает 0 при оценке General
Systems Characteristics и не одно не набирает 5 по всем
параметрам, но если бы такое было возможно то,
• Для всех 0 VAF = (0*.01) +.65 = .65
• Для всех 5 VAF = (70*.01)+.65 = 1.35
 В среднем использование выравнивания изменяет оценку до
-30% до +35%
Основано на материалах David Consulting Group

31. www.luxoft.com
Чек-лист для подсчета функциональных точек
 Соберите необходимую документацию;
 Определите функциональные требования и границы приложения;
 Определите и классифицируйте основные функциональные компоненты;
 Посчитайте файлы данных;
 Внутренние логические файлы (ILF);
 Внешние интерфейсные файлы External Groupings of data or External Interface Files (EIF);
 Посчитайте транзакции;
 внешние входные транзакции (EI);
 внешние выходные транзакции (EO);
 внешние запросы (EQ);
 Определите функциональную сложность каждого компонента и его размер (L-A-H) в функциональных точках;
 Посчитайте общий размер приложения в функциональных точках;
 Выровняйте функциональные точки, используя VAF;
ОснованонаматериалахDavidConsultingGroup

32. www.luxoft.com
Что дальше почитать/посмотреть?
 Producing realistic estimates - http://www.softwarevalue.com/insights/publications/better-estimation-
better-decisions/
 Webinars and publication on Function Points: http://www.softwarevalue.com/insights/
 Trainings: http://www.softwarevalue.com/news/training/
 Статья - Обзор метода функциональных точек
http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml
 Вебинар - Основы оценки размера проекта методом функциональных
точекhttps://attendee.gotowebinar.com/register/666912455395478273?source=conf

33. www.luxoft.com

34. www.luxoft.com
Спасибо
Остаемся на связи:
https://www.facebook.com/LuxoftAgilePractice
http://www.youtube.com/c/LuxoftAgilePractice
https://www.facebook.com/Svetlana.Mukhina8
https://www.linkedin.com/in/svetlanamukhina