Методика оценки трудоемкости разработки ПО ИС на основе функциональных точек.

Согласно данной методике трудоемкость вычисляется на ос­нове функциональности разрабатываемой системы, которая определяется на основе выявления функциональных
типов — логических групп взаимосвязанных данных, используемых и поддерживаемых приложением, а также элементарных про­цессов, связанных с вводом и выводом информации.
Порядок расчета трудоемкости разработки ПО:
• определение количества и сложности функциональных ти­пов приложения;
• определение количества связанных с каждым функциональ­ным типом элементарных данных (DET), элементарных записей (RET) и файлов типа ссылок (FTR);
• определение сложности (в зависимости от количества DET,
RET и FTR);
• подсчет количества функциональных точек приложения;
• подсчет количества функциональных точек с учетом общих
характеристик системы;
• оценка трудоемкости разработки (с использованием различ­ных статистических данных).
ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ТИПОВ
В состав функциональных типов включаются следующие элементы приложений разрабатываемой системы.
1.Внутренний логический файл (ILF) — иден­тифицируемая совокупность логически взаимосвязанных записей данных, поддерживаемая внутри приложения посредством
элементарного процесса.
2. Внешний интерфейсный файл (Elf) — идентифицируемая совокупность логически взаимосвязанных за­писей данных, передаваемых другому приложению или получае­мых от него и поддерживаемых вне данного приложения.
3. Входной элемент приложения (EI) — элемен­тарный процесс, связанный с обработкой входной информации приложения — входного документа или экранной формы. Обрабатываемые данные могут соответствовать одному или более ILF.
4. Выходной элемент приложения (ЕО) — эле­ментарный процесс, связанный с обработкой выходной инфор­ приложения — выходного отчета, документа, экранной
формы.

5. Внешний запрос (EQ) ~ элементарный про­цесс, состоящий из комбинации «запрос/ответ», не связанный с вычислением производных данных или обновлением ILF (базы данных).
Виды функциональных типов
Эффективность работы конечных пользователей определяется наличи­ем следующих функциональных возможностей.

0 –нет функцион-ых зависимости

1-от 1 б до 3

2-от 4б до 5

От 4 и более+интерфейс проектировался отдельно

5- +ИС не имеет спец ср-ва, оценивабщие работу польз. Инф си-ма имеет спец ср-ва, оценивающие работу пользоват.

Перечень функциональных возможностей
• Средства навигации (например, функциональные клавиши, дина­
мически генерируемые меню).
• Меню.
• Онлайновые подсказки и документация.
• Автоматическое перемещение курсора.
• Скроллинг.
• Удаленная печать.
• Предварительно назначенные функциональные клавиши.
• Выбор данных на экране с помощью курсора.
• Использование видеоэффектов, цветового вьщеления, подчерки­
вания и других индикаторов.
• Всплывающие окна.
• Минимизация количества экранов, необходимых для выполнения
бизнес-функций.
• Поддержка двух и более языков.

Онлайновое обновление
0 Отсутствует
1 Онлайновое обновление от одного до трех управляющих файлов
Объем обновлений незначителен, восстановление несложно
2 Онлайновое обновление четырех или более управляющих файлов
Объем обновлений незначителен, восстановление несложно
3 Онлайновое обновление основных внутренних логических файлов
4 То же, плюс необходимость специальной защиты от потери данных
5 То же, кроме того, большой объем данных требует учета затрат на
процесс восстановления. Требуются автоматизированные процеду­
ры восстановления с минимальным вмешательством оператора
Сложная обработка
0 Ни одной из перечисленных функциональных возможностей^
1 Любая одна из возможностей
2 Любые две из возможностей
^ Любые три из возможностей
^ Любые четыре из возможностей
5 Все пять возможностей
• повышенная реакция на внешние воздействия и (или) специаль­
ная защита от внешних воздействий;
• экстенсивная логическая обработка;
• экстенсивная математическая обработка;
• обработка большого количества исключительных ситуаций;
• поддержка разнородных типов входных/выходных данных.
Повторное использование
0 Отсутствует
1 Повторное использование кода внутри одного приложения
2 Не более 10% приложений будут использоваться более чем одним
пользователем
3 Более 10% приложений будут использоваться более чем одним поль­
зователем
4 Приложение оформляется как продукт и (или) документируется для
облегчения повторного использования. Настройка приложения вы­
полняется пользователем на уровне исходного кода.
5 То же, с возможностью параметрической настройки приложений
Простота установки
0 К установке не предъявляется никаких специальных требований.
1 Для установки требуется специальная процедура
2 Заданы пользовательские требования к конвертированию (переносу
существующих данных и приложений в новую систему) и установке,
должны быть обеспечены и проверены соответствующие руковод­
ства. Конвертированию не придается важное значение
3 То же, однако конвертированию придается важное значение.
4 То же, что и в случае 2, плюс наличие автоматизированных средств
конвертирования и установки
5 То же, что и в случае 3, плюс наличие автоматизированных средств
конвертирования и установки
Простота эксплуатации
О- К эксплуатации не предъявляется никаких специальных требова­
ний, за исключением обычных процедур резервного копирования
1—4 Приложение обладает одной, несколькими или всеми из перечис­
ленных далее возможностей. Каждая возможность, за исключением
второй, обладает единичным весом: 1) наличие процедур запуска,
копирования и восстановления с участием оператора; 2) то же, без
участия оператора; 3) минимизируется необходимость в монтирова­
нии носителей для резервного копирования; 4) минимизируется не­
обходимость в средствах подачи и укладки бумаги при печати
5 Вмешательство оператора требуется только при запуске и заверше­
нии работы системы. Обеспечивается автоматическое восстановле­
ние работоспособности приложения после сбоев и ошибок

Количество возможных установок на различных платформах
0 Приложение рассчитано на установку у одного пользователя
1 Приложение рассчитано на много установок для строго стандартной
платформы (технические средства + программное обеспечение)
2 Приложение рассчитано на много установок для платформ с близ­
кими характеристиками
3 Приложение рассчитано на много установок для различных плат­
форм
4 То же, что в случаях 1 или 2, плюс наличие документации и планов
поддержки всех установленных копий приложения
5 То же, что в случае 3, плюс наличие документации и планов под­
держки всех установленных копий приложения
Гибкость
0 Ни одной из перечисленных возможностей
1 Любая одна из возможностей
2 Любые две из возможностей
3 Любые три из возможностей
4 Любые четыре из возможностей
5 Все пять возможностей
Определение значения фактора выравнивания (FAV)

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

1. Обмен данными (0 — продукт представляет собой автономное приложение; 5 — продукт обменивается данными по более, чем одному телекоммуникационному протоколу).
2. Распределенная обработка данных (0 — продукт не перемещает данные; 5 — распределенная обработка данных выполняется несколькими компонентами системы).
3. Производительность (0 — пользовательские требования по производительности не установлены; 5 — время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.
4. Ограничения по аппаратным ресурсам (0 — нет ограничений; 5 — продукт целиком должен функционировать на определенном процессоре и не может быть распределен).
5. Транзакционная нагрузка (0 — транзакций не много, без пиков; 5 — число транзакций велико и неравномерно, требуются специальные решения и инструменты).
6. Интенсивность взаимодействия с пользователем (0 — все транзакции обрабатываются в пакетном режиме; 5 — более 30% транзакций — интерактивные).
7. Эргономика (эффективность работы конечных пользователей) (0 — нет специальных требований; 5 — требования по эффективности очень жесткие).
8. Интенсивность изменения данных (ILF) пользователями (0 — не требуются; 5 — изменения интенсивные, жесткие требования по восстановлению).
9. Сложность обработки (0 — обработка минимальна; 5 — требования безопасности, логическая и математическая сложность, многопоточность).
10. Повторное использование (0 — не требуется; 5 — продукт разрабатывается как стандартный многоразовый компонент).
11. Удобство инсталляции (0 — нет требований; 5 — установка и обновление ПО производится автоматически).
12. Удобство администрирования (0 — не требуется; 5 — система автоматически самовосстанавливается).
13. Портируемость (0 — продукт имеет только 1 инсталляцию на единственном процессоре; 5 — система является распределенной и предполагает установку на различные «железо» и ОС).
14. Гибкость (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

После определения всех значений GSC и вычисления попра­вочного коэффициента VAF вычисляется итоговая оценка коли­чества функциональных точек (AFP):
AFP = UFP * VAF.

 

Валя как найти ufp?

 

Методика оценки трудоемкости разработки ПО на основе вариантов использования

Все действующие лица системы делятся на три типа

1)Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API).

2) Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, ASCII-терминалом).

3)Сложное действующее лицо представляет личность, пользующуюся графическим интерфейсом (GUI).

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

ОПРЕДЕЛЕНИЕ ВЕСОВЫХ ПОКАЗАТЕЛЕЙ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (UUCP)

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

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

ОПРЕДЕЛЕНИЕ ТЕХНИЧЕСКОЙ СЛОЖНОСТИ ПРОЕКТА

Техническая сложность проекта (TCF) вычисляется с учетом показателей технической сложности

ТСF= 0, 6+(0, 01*(сумм Ti*Vi))

Vi-вес

ОПРЕДЕЛЕНИЕ УРОВНЯ КВАЛИФИКАЦИИ РАЗРАБОТЧИКОВ

Уровень квалификации разработчиков (EF) вычисляется с учетом следующих показателей.

 

EF = 1, 4 + (- 0, 03 * (сум Fi * Vi))

ОЦЕНКА ТРУДОЕМКОСТИ ПРОЕКТА

В качестве начального значения предлагается использовать 20 человеко-часов на одну UCP. Эта величина может уточняться с учетом опыта разработчиков.

Рассмотрим показатели F1—F8 и определим, сколько показателей F1—F6 имеют значение меньше 3 и сколько показателей F7-F8 имеют значение больше 3.

Если общее количество меньше или равно 2, следует использовать 20 чел.-ч. на одну UCP, если 3 или 4—28. Если общее количество равно 5 или более, следует внести изменения в сам проект, в противном случае риск провала слишком высок.

Для системы регистрации получаем 28 чел.-ч. на одну UCP, таким образом, общее количество человеко-часов на весь проект равно 56, 56*28 = 1583, 68, что составляет 40 недель при 40-часовой рабочей неделе. Допустим, что команда разработчиков состоит из

четырех человек, и добавим 3 недели на различные непредвиденные ситуации, тогда в итоге получим 13 недель на весь проект. Опытные данные компании Rational Проект среднего размера (приблизительно 10 разработчиков, более чем 6—8 месяцев) может включать приблизительно 30 вариантов использования. Это соответствует тому, что средний вариант использования содержит 12 и СР, и каждая UCP требует 20-30 ч. Это означает общую трудоемкость 240-360 чел.-ч. на вариант использования. Таким образом, 30 вариантов использования потребуют приблизительно 9000 чел.-ч. (10 разработчиков в течение 6 месяцев). Однако прямой пропорции не существует: очень большой проект со 100 разработчиками и сроком 20 месяцев не начнется с 1000 вариантов

использования из-за проблем размерности. Использование описанной выше методики для простых и сложных систем хорошо согласуется с опытными данными компании Rational (приблизительно 150—350 ч. на один вариант использования). Самая простая система (весовой показатель UC = 5, А = 2, UUCP = 7) дает (при 20 чел.-ч. на UCP) приблизительно 140 чел.-ч. Сложная система (весовой показатель UC = 15, А = 3, UUCP = 18) дает приблизительно 360 чел.-ч. UCP=UUCP*TCF*EF

 

⇐ Предыдущая123456789Следующая ⇒

Поделиться: