Четверг, 19.09.2024, 06:23
Приветствую Вас Гость | RSS
Меню сайта
Категории раздела

Информационные системы

Каталог статей

Главная » Статьи » Мои статьи [ Добавить статью ]

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

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

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

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

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

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

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

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

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

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

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

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

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

В зависимости от типа область оценки может включать:

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

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

Третий шаг. определяют:

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

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

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

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

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

Сначала определяется сложность данных по следующим показателям:

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

• RET (record element type) — логическая группа данных, например, адрес, паспорт, телефонный номер.Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности. Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) в зависимости от их сложности

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

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

В методе различаются следующие типы транзакций

• EI (external inputs) — внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.

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

• EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.Оценка сложности транзакции основывается на следующих ее характеристиках:

• FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.

• DET (data element type) — неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.
Категория: Мои статьи | Добавил: ASSAHI (13.11.2013)
Просмотров: 944 | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]