Методика EARLY FUNCTION POINTS для определения трудоемкости разработки программного приложения кратко

Привет, Вы узнаете о том , что такое медика early function points, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое медика early function points, определение трудоемкости разработки приложения , настоятельно рекомендую прочитать все из категории Управление разработкой программных IT проектов.

Введение

Метод Early Function Points (метод раннего прогнозирования размера будущей программы) был предложен Роберто Мели в 1997 году (Италия) как показано в работах .

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

Метод Early Function Points предполагает оценивание таких объектов, как логические элементы данных, макрофункции, функции, микрофункции и функциональные примитивы .

Функциональные примитивы – элементарные процессы, не поддающиеся дальнейшей детализации (процессы ввода, вывода и запроса) [8-9].

Микрофункции – функциональные примитивы (создание, удаление, обновление и выборка), функции управления данных.

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

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

Логические элементы данных – группа связных элементов данных, классифицируемых по пяти уровням сложности: «низкий», «средний», «высокий», «сложный», «сверхсложный»

На высоком уровне владения знанием о будущем приложении используются все перечисленные объекты. Но на примере мобильного приложения можно использовать ILF, EIF, EI, EO, EQ. И придерживаться данного алгоритма работы:

• – как можно подробней изучить предметную область, выделим нужные функции и задачи, детализируем их;
• – определить каждую функцию к соответствующему ее типу (ILF, EIF, EI, EO, EQ);
• – оценить сложность каждой функции (низкая, средняя, высокая);
• – вычислить общее количество нескорректированных точек функций;
• – проведести расчет трудозатрат для данного проекта.

Исходные данные

Определим, какими функциями будет обладать наше мобильное приложение для кофейни для автоматизации заказов:

• – авторизация в системе пользователей и персонала;
• – добавление/удаление/изменение пользователей (клиентов, персонала);
• – добавление/удаление/изменение блюд и напитков в меню;
• – просмотр информации о тех или иных блюдах или напитках.

В задачи проекта будут входить:

• – хранение меню и взаимодействие с его составляющими;
• – хранение информации о клиентах и персонале.

Все необходимые для работы приложения данные хранятся в базе данных. База данных программы включает в себя следующие таблицы (табл. 1).

Таблица 1. Структура и состав баз данных

Название БД	Количество полей
Клиент	5
Персонал	4
Элемент меню	4

Расчет трудозатрат на разработку программного продукта для кофейни

Приложение будет состоять из следующих окон:

• – вход в приложение;
• – регистрация в приложении;
• – личный кабинет;
• – главное окно программы;
• – история покупок и оплаты;
• – меню;
• – информация о том или ином блюде или напитке.

Следуя используемой методике Early Function Points и базовым таблицам ранга и оценки сложности методики Function Points, составим таблицу информационных характеристик для дальнейшего расчета (табл. 2).

Таблица 2. Исходные данные для расчета

Наименование	Число элементов данных	Ранг
Внешние вводы
Экран с формой авторизации	2	3
Экран с вводом информации для регистрации	6	3
Экран с вводом информации о блюде или напитке	4	3
Наименование	Число элементов данных	Ранг
Экран с вводом информации о персонале	4	3
Главный экран	7	3
Внешние выводы
Профиль пользователя	5	4
Внешние запросы
Запрос блюда или напитка	1	3
Запрос корректности авторизации	2	3
Запрос меню	2	3
Запрос состава персонала	4	3
Запрос заказа	3	3
Внутренние логические файлы
Данные о пользователе	5	7
Данные о персонале	4	7
Внешние интерфейсные файлы
База данных меню	4	5
Итого	53

Используя данные из таблиц 2 и 3, вычислим количество функциональных указателей по формуле (1):

, (1)

где Fi – коэффициенты регулировки сложности, принимающие целые значения от 0 до 5 в зависимости от сложности реализации соответствующей характеристики проекта (табл. Об этом говорит сайт https://intellect.icu . 3).

Таблица 3. Значение системных параметров

№	Системный параметр	Значение (Fi)
1	Передача данных	3
2	Распределенная обработка данных	5
3	Производительность обработки	3
4	Эксплуатационные ограничения	3
5	Частота транзакций	4
6	Оперативный ввод данных	3
7	Эффективность работы	4
8	Оперативное обновление	3
9	Сложность обработки	2
10	Повторная используемость	4
№	Системный параметр	Значение (Fi)
11	Простота установки	2
12	Простота эксплуатации	2
13	Разнообразные условия	3
14	Простота изменений	3

Суммарное значение коэффициентов регулировки сложности (Σ Fi) оказалось равным 44.

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

FP = 53 × (0,65 + 0,01 × 44) = 57,77.

Полученная FP-оценка пересчитывается в LOC-оценки V по следующей формуле (2):

V = Kяз × FP, (2)

где Kяз – зависит от языка программирования, используемого для реализации ПО.

В разработке данного программного проекта будет использоваться язык программирования C# с коэффициентом языка программирования (Kяз) равным 53, поэтому расчет будет следующим:

V = 53 × 57,77 = 3061,81 LOC.

По рассчитанному количеству строк кода (V) отнесем данную программу к типу распространенного программного обеспечения. Следуя из этого, возьмем коэффициенты N1 = 3,2; N2 = 1,05 и N3 = 0,38 по таблице 4.

Таблица 4. Коэффициенты N1, N2, N3

Тип ПО	N1	N2	N3
Распространенное	3,2	1,05	0,38
Полунезависимое	3,0	1,12	0,35
Встроенное	2,8	1,20	0,32

Номинальную трудоемкость (без учета коэффициентов затрат труда, стоимостных факторов и сложности) вычислим по формуле (3):

(3)

где KSLOC (тыс. строк) = V / 1000, а значения N1 и N2 определяются по таблице 4.

Согласно полученным данным трудоемкость создания мобильного приложения составляет:

Время разработки вычисляется по формуле (4):

(4)

Используя формулу (4), получим срок создания мобильного приложения:

tразр. = 2,5 × TN3­ = 2,5 × 10,36^0,38­­ = 6,08 мес.

Следуя рекомендуемому правилу распределения затрат проекта – 40−20−40:

• – на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%);
• – на кодирование – 20%;
• – на тестирование и отладку – 40%;

получим время в месяцах для разработки проекта (табл. 5).

Таблица 5. Распределение временных затрат

Этап	Доля затрат, мес.
Анализ и проектирование	2,432
Кодирование	1,216
Тестирование и отладка	2,432
Общие временные затраты	6,08

Исходя из полученных данных, мы можем утверждать, что для разработки мобильного приложения для кофейни нам потребуется около 11 человек разработчиков, 3062 строк кода и 6,08 месяца на создание данного программного проекта при перечисленных условиях. В процессе разработки полученные данные будут изменяться, но на начальном этапе проектирования мы, таким образом, уже можем оценить трудозатраты на данное программное обеспечение.

Таким образом, мы провели расчет по методу Early Function Points, в результате которого определили длительность разработки приложения, необходимое количество строк кода и требуемое количество разработчиков для данного проекта [13-14], несмотря на то, что в настоящих расчетах и выкладках по методу Early Function Points использовалась информация о функциях, не детализированная с той точностью, с которой это можно сделать на более поздних стадиях жизненного цикла программного проекта.

Вау!! 😲 Ты еще не читал? Это зря!

• Методики оценки проектов:
  • Экспертная оценка
  • Оценка по аналогии
  • Use Case Points (UCP)
  • Function Points (FP)
  • Early Function Points (EFP)
  • Fast Function Points (EFP)
• метод функциональных точек , точки использования , ucp , function points ,

Исследование, описанное в статье про медика early function points, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое медика early function points, определение трудоемкости разработки приложения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Управление разработкой программных IT проектов

Из статьи мы узнали кратко, но содержательно про медика early function points