Методы оценки трудоемкости: Метод FunctionPoints.

Один из методов, который успешно применятся для предварительной оценки длительности и трудозатрат проектов разработки программного обеспечения является FunctionPoints. В инструкции от Ильи Коленцева (LUXOFT) находится описание методики и рекомендации по ее применению. Кроме того, в документе описываются возможности анализа методом FunctionPoints с помощью пакета COCOMO. Документ от DavidLongstreet более развернут, и его полезно прочитать для того, чтобы получить максимально глубокое представление о методике. А мастер в формате hlp поможет применить эту методику на практике.

Анализ функциональных точек — стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (AlanAlbrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (InternationalFunctionPointUserGroup — IFPUG), которая опубликовала несколько ревизий метода.

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

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

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

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

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

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

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

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

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

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

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

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

3. Продукт. Оценивается объем уже существующего и установленного продукта.

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

· Все разрабатываемые функции (для проекта разработки)

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

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

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

· Что является «внешним» по отношению к оцениваемому продукту.

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

· Какие данные поддерживаются приложением, а какие — внешние.

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

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

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

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

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

· DET (dataelementtype) — неповторяемое уникальное поле данных, например, Имя Клиента — 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) — 9 DET's

· RET (recordelementtype) — логическая группа данных, например, адрес, паспорт, телефонный номер.

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

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

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