Лекции по управлению программными проектами

2009 г.

Лекции по управлению программными проектами

Обзор метода функциональных точек

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

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

При анализе методом функциональных точек надо выполнить следующую последовательность шагов (Рисунок 37):

Определение типа оценки.
Определение области оценки и границ продукта.
Подсчет функциональных точек, связанных с данными.
Подсчет функциональных точек, связанных с транзакциями.
Определение суммарного количества не выровненных функциональных точек (UFP).
Определение значения фактора выравнивания (FAV).
Расчет количества выровненных функциональных точек (AFP).

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

Определение типа оценки

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

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

Определение области оценки и границ продукта

Второй шаг — это определение области оценки и границ продукта. В зависимости от типа область оценки может включать:

Все разрабатываемые функции (для проекта разработки)
Все добавляемые, изменяемые и удаляемые функции (для проектов поддержки)
Только функции, реально используемые, или все функции (при оценке продукта и/или продуктов).

Третий шаг. Границы продукта (Рисунок 38) определяют:

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

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

К логическим данным системы относятся:

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

Примером логических данных (информационных объектов) могут служить: клиент, счет, тарифный план, услуга.

Подсчет функциональных точек, связанных с данными

Третий шаг — подсчет функциональных точек, связанных с данными. Сначала определяется сложность данных по следующим показателям:

DET (data element type) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's
RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.

Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности (Таблица 7).

Таблица 7. Матрица сложности данных

1-19 DET 20-50 DET 50+ DET

1 RET Low Low Average

2-5 RET Low Average High

6+ RET Average High High

Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) (Таблица 8) в зависимости от их сложности.

Таблица 8. Оценка данных в не выровненных функциональных точках (UFP) для внутренних логических файлов (ILFs) и внешних интерфейсных файлов (EIFs)

Сложность данных Количество UFP (ILF) Количество UFP (EIF)

Low 7 5

Average 10 7

High 15 10

Для иллюстрации рассмотрим пример оценки в не выровненных функциональных точках объекта данных «Клиент» (Рисунок 39).

Рисунок 39. Пример оценки в не выровненных функциональных точках объекта данных «Клиент».

Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 неповторяемых уникальное полей данных. Согласно матрице (Таблица 7), нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно Таблица 8 его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.

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

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

Транзакция — это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.

В методе различаются следующие типы транзакций (Таблица 9):

EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.
EO (external outputs) — внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.
EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Таблица 9. Основные отличия между типами транзакций. Легенда: О — основная; Д — дополнительная; NA — не применима.

Функция Тип транзакции

EI EO EQ

Изменяет поведение системы О Д NA

Поддержка одного или более ILF О Д NA

Представление информации пользователю Д О О

Оценка сложности транзакции основывается на следующих ее характеристиках:

FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.
DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.

Для оценки сложности транзакций служат матрицы, которые представлены в Таблица 10 и Таблица 11.

Таблица 10. Матрица сложности внешних входных транзакций (EI)

EI 1-4 DET 5-15 DET 16+ DET

0-1 FTR Low Low Average

2 FTR Low Average High

3+ FTR Average High High

Таблица 11. Матрица сложности внешних выходных транзакций и внешних запросов (EO & EQ)

EO & EQ 1-5 DET 6-19 DET 20+ DET

0-1 FTR Low Low Average

2-3 FTR Low Average High

4+ FTR Average High High

Оценка транзакций в не выровненных функциональных точках (UFP) может быть получена из матрицы (Таблица 12)

Таблица 12. Сложность транзакций в не выровненных функциональных точках (UFP)

Сложность транзакций Количество UFP (EI & EQ) Количество UFP (EO)

Low 3 4

Average 4 5

High 6 7

В качестве примера, рассмотрим оценку управляющей транзакции (EI) для диалогового окна, задающего параметры проверки орфографии в MS Office Outlook (Рисунок 40).

Рисунок 40. Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook

Каждый "Check box" оценивается, как 1 DET. Выпадающий список — 1 DET. Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то, для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно матрице (Таблица 10), мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с матрицей (Таблица 12), данная транзакция должна быть оценена в 3 не выровненных функциональных точек (UFP).

Определение суммарного количества не выровненных функциональных точек (UFP)

Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ).

Определение значения фактора выравнивания (FAV)

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

Обмен данными (0 — продукт представляет собой автономное приложение; 5 — продукт обменивается данными по более, чем одному телекоммуникационному протоколу).
Распределенная обработка данных (0 — продукт не перемещает данные; 5 — распределенная обработка данных выполняется несколькими компонентами системы).
Производительность (0 — пользовательские требования по производительности не установлены; 5 — время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.
Ограничения по аппаратным ресурсам (0 — нет ограничений; 5 — продукт целиком должен функционировать на определенном процессоре и не может быть распределен).
Транзакционная нагрузка (0 — транзакций не много, без пиков; 5 — число транзакций велико и неравномерно, требуются специальные решения и инструменты).
Интенсивность взаимодействия с пользователем (0 — все транзакции обрабатываются в пакетном режиме; 5 — более 30% транзакций — интерактивные).
Эргономика (эффективность работы конечных пользователей) (0 — нет специальных требований; 5 — требования по эффективности очень жесткие).
Интенсивность изменения данных (ILF) пользователями (0 — не требуются; 5 — изменения интенсивные, жесткие требования по восстановлению).
Сложность обработки (0 — обработка минимальна; 5 — требования безопасности, логическая и математическая сложность, многопоточность).
Повторное использование (0 — не требуется; 5 — продукт разрабатывается как стандартный многоразовый компонент).
Удобство инсталляции (0 — нет требований; 5 — установка и обновление ПО производится автоматически).
Удобство администрирования (0 — не требуется; 5 — система автоматически самовосстанавливается).
Портируемость (0 — продукт имеет только 1 инсталляцию на единственном процессоре; 5 — система является распределенной и предполагает установку на различные «железо» и ОС).
Гибкость (0 — не требуется; 5 — гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ∑ DI

Расчет значения фактора выравнивания производится по формуле

VAF = (TDI *0.01) + 0.65

Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1.07

Расчет количества вьровненных функциональных точек (AFP)

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

AFP = UFP * VAF.

Она учитывает только новую функциональностсть, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:

DFP = (UFP + CFP) * VAF,

где CFP (conversion functional point) — функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.

Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:

EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB),

где

ADD — функциональные точки для добавленной функциональности;
CHGA — функциональные точки для измененных функций, рассчитанные после модификации;
VAFA — величина фактора выравнивания рассчитанного после завершения проекта;
DEL — объем удаленной функциональности;
VAFB — величина фактора выравнивания рассчитанного до начала проекта.

Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP.

Метод анализа функциональных точек ничего не говорит о трудоемкости разработки оцененного продукта. Вопрос решается просто, если компания разработчик имеет собственную статистику трудозатрат на реализацию функциональных точек. Если такой статистики нет, то для оценки трудоемкости и сроков проекта можно использовать метод COCOMO II.

Назад Содержание Вперёд