ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 799
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Классификатор для оценки функциональности
Масштаб
проекта
С
1
Пользователи
объекта
проектирования
С
2
Тип объекта
проектирова-
ния
С
3
Функция
1
Индивидуальное использование
1
Не требующий программирова
-ния
1
Объект
2
Потребители shareware ПО
2
Скрипт
2
Библиотека объектов
4
Академическая среда, инженерия
3
ПО встраивае- мой одноплатной системы
5
Реализация концепции
5
Внутрикорпоратив- ные, локальное использование
5
База данных
6
Прототип для последующего эволюционного развития
6
Внутрикорпоратив- ные, распределенное использование
6
Клиент- серверное ПО
8
Приложение для внутренних нужд
8
Контрактный проект,
Гражданский заказчик
7
Математическо е ПО
9
Приложение под заказ
9
Контрактный проект, заказчик — органы местной власти
8
Коммуникацио нное
ПО
11
Приложение, пригодное к рас- ширению функ- цииональности в ходе жизненного цикла
10
Коммерческий проект, предназначенный для тиражирования
9
ПО управления процессами
12
Компонент внешней системы
11
Контрактный проект, государственное бюд- жетное финансирова- ние
14
ПО встраивае- мой многопро- цессорной системы
13
Новая масштабная система
12
Проект связанный с потенциальной опасностью для жизни
(военные заказчики, служба спасения и т.д.)
15
ПО для общедоступ- ных сервисов
15
343
Таблица 7.22
Соответствие баллов функциональности объему кода для разных
языков программирования
Язык
Строк/балл
Язык
Строк/балл
Access
38
Jovial
107
Ada 83 71
Lisp
64
Ada 95 49
Machine Code
640
Al Shell
49
Modula 2 80
APL
32
Pascal
91
Assembly-Basic
320
PERL
27
Assembly-Macro
213
PowerBuilder
16
Basic-ANSI
64
Prolog
64
Basic-Compiled
91
Query-Default
13
Basic-Visual
32
Report Generator
80
C
128
Second Generation
Language
107
C++
55
Simulation-Default
46
Cobol (Ansi 85)
91
SpreadSheet
6
Database-Default
40
Third Generation
Language
80
Fifth Generation
Language
4
Unix Shell Scripts
107
First Generation
Language
320
Visual Basic 5.0 29
Forth
64
Visual C++
34
Fortran 77 107
High Level
Language
64
Fortran 95 71
HTML 3.0.
15
Fourth Generation
Language
20
Java
53
Балльная оценка информационных элементов
В EFP IFPUG FPA используется три типа информационных струк- тур: информационный объект, объект типа элементов данных и объ-
ект типа элементов последовательности. Информационный объект в методике EFP IFPUG FPA — определенная логикой задачи, пользовате- лем или разработчиком группа данных, удовлетворяющих специфиче- ским требованиям задачи или представлениям потребителя информа- ции. Физическая реализация информационного объекта не играет роли при определении их количества, поэтому последовательности данных, сформированных в рамках единой логики, но имеющих различное фи- зическое воплощение: размещенные в оперативной памяти, размещен- ных во входных или выходных интерфейсных формах или сохраненных в файле — считаются одним и тем же информационным элементом.
Объект типа элементов последовательности в методике EFP IFPUG
FPA — структура элементов данных, определенная пользователем под- группа данных внутри информационного объекта, предназначенная для
344 совершения ИТКСС того или иного бизнес-действия. Объект типа эле- ментов данных в EFP IFPUG FPA — уникальное, распознаваемое поль- зователем неповторяющееся поле записи, элемент массива, или элемент графического интерфейса. На высоком уровне абстракции (на началь- ном этапе рассмотрения проекта) информационный элемент относят к умеренно сложным или очень сложным в зависимости от количества информационных элементов более низкого уровня, включенных в рас- сматриваемый элемент согласно данным табл. 7.23.
При более детальном рассмотрении, по результатам предварительно- го проектирования информационные элементы оцениваются по степени сложности на основании числа включенных в них элементов тип DET и
RET.
Табл. 7.23
Сложность информационного элемента в зависимости
от числа информационных объектов
Сложность информационного
элемента
Число включенных
информационных объектов
Умеренно сложные
2–4
Очень сложные
5–8
На основании оценок сложности информационных элементов каж- дому из них ставится в соответствие количество баллов, определенное табл. 7.25. После проектирования структур информационных элементов
(состава и типов ассоциированных данных), на основании табл. 7.24 и
7.25 рассчитывается уточненное количество баллов функциональности, улучшая оценку трудоемкости изготовления ПО. Три колонки табл. 7.25 дают минимальную, среднюю и максимальную оценку баллов функ- циональности каждого информационного объекта. Согласно общему подходу метода EFP IFPUG FPA все три значения сохраняются, склады- ваются с балльными оценками функциональности ПО и, после норми- рования, учитывающего фактор сложности системы, используются для расчета функционально оправданной длины кода, на основании данных табл. 7.23.
Табл. 7.24
Уточненное количество баллов функциональности в зависимости числа
элементов данных
Объект типа
элементов
последователь-
ности
Объект типа элементов данных
1 - 19 20
- 50
>51 1
Простой
Простой
Промежуточный
2 - 5
Простой
Промежуточный
Комплексный
> 6
Промежуточный
Комплексный
Комплексный
345
Таблица 7.25
Уточненное количество баллов функциональности в зависимо
сти сложности информационных элементов
Информационный элемент
Минимальное значение
Среднее значение
Максимальное значение
Простой
5 6
7
Промежуточный
8 9
10
Комплексный
13 14 15
Умеренно сложный
14 18 22
Очень сложный
27 39 51
Балльная оценка «функциональности» программного
обеспечения
Категория функциональность в EFP IFPUG FPA классифицируется следующим образом: примитив, определяющийся на элементарном уровне проектирова- ния ПС; микрофункция, определяющаяся на детальный уровень проектиро- вания ПС; функция, определяющая промежуточный уровень проектирования
ПС; макрофункция, определяющая верхний уровень проектирования ПС.
Распределение по категориям также определяется количеством примитивов внутри функциональности.
Примитивом называется наименьший представимый при декомпо- зиции процесс, обладающий автономными характеристиками, позво- ляющий пользователю описывать единичные действия, составляющие часть бизнес-процедуры на операционном уровне. Примитивы, связан- ные с вводом/выводом информации, легко определяются на уровне предварительного проектирования.
Примитивы подразделяются на: примитив ввода; примитив вывода; примитив обновления.
Расчет баллов функциональности для примитивов проводится по данным табл. 7.26.
Табл. 7.26
Значения баллов функциональности для примитивов
Минимум
Среднее
Максимум
Примитив ввода
4 5
7
Примитив вывода
5 6
6
Примитив обновления
4 5
7
Микрофункции определяются как 4 типа стандартных функциональ- ных примитива:
346 создания; чтения; обновления; удаления.
Действия микрофунций относятся к элементарным данным, вклю- ченных в один или несколько информационных элементов. Примитивы и функциональные примитивы не следует смешивать между собой.
Функциональные примитивы ассоциируются с понятием управление данными и имеют более абстрактный характер, чем примитивы вво- да/вывода конкретных данных. В традиционном понимании функцио- нальные примитивы – подпрограммы ввода/вывода различных классов данных – объектов, типов и последовательностей данных, в то время как примитивы индивидуальны для каждого процесса и ассоциируются с конкретным видом данных.
Каждая микрофункция оценивается минимально 16 баллами функ- циональности, максимально – 20 баллами, при среднем значение – 18 баллов. Функции определяются как составляющая часть подсистемы – части приложения, позволяющая организовать полную обработку дан- ных пользователя для получения целостного ответа на поставленную задачу. Само приложение может обрабатывать данные для решения не- скольких сходных задач. В зависимости от числа функциональных при- митивов, функции подразделяются на малые, содержащие 5 – 12 функ- циональных примитивов, промежуточные, содержащие 13 – 19 функ- циональных примитивов и большие, содержащие 20 – 25 функциональ- ных примитивов – см. табл. 7.27.
Макрофункции определяются как промежуточные функции, соот- ветствующие в обычной терминологии, подсистемам. Иногда макро- функция и составляет весь проект. Макрофункция – составная часть всей информационной системы (функциональный модуль), решающая группу типовых задач, поставленных перед информационной системой.
Макрофункции также подразделяются на малые 2 – 3 функции, проме- жуточные – на 4 – 7 функций и большие – на 8 – 12 функций. Оценки макрофункций в баллах даны в табл. 7.28.
Табл. 7.27
Классы функций в зависимости от числа функциональных
примитивов
Класс функции
Минимум
Среднее
Максимум
Малая
45 56 67
Промежуточная
73 91 109
Большая
106 133 160
Табл. 7.28
347
Оценки макрофункций в баллах
Функция
Минимум
Среднее
Максимум
Малая
151 215 280
Промежуточная
302 431 560
Большая
603 861 1119
Из определения макрофункций следует, что их следует применять в расчетах на самом верхнем уровне проектирования, в начале постановки задачи. По мере разработки проекта следует проводить корректирую- щие расчеты функциональности программного обеспечения, оценивая функциональность с помощью функций и функциональных примити- вов.
Каждый объект оценивается тремя числовыми величинами – мини- мальным, средним и максимальным значениями, основанными на уни- версальных статистических таблицах, введенных в IFPUG97. После то- го, как каждый объект EFP идентифицирован и оценен с помощью вы- шеприведенных таблиц, все оценки суммируются. При сложении мини- мально возможные, средние и максимальные значения суммируются по отдельности, так что общая оценка – нескорректированная оценка по методу FPA – всегда содержит три значения. Разница между верхней и нижней гранями используется в качестве оценки погрешности метода.
Вычисление величины обобщенного фактора сложности задачи
Величина обобщенного фактора сложности задачи (VAF) рассчиты- вается для каждого проекта с учетом совокупности значений из 14 глав- ных системных характеристик (GSC’s), приведенных ниже. Степень влияния каждой характеристики изменяется от 0 до 5, от полного отсут- ствия влияния характеристики до сильного влияния на разрабатываемое
ПО. Влияние каждой главной системной характеристики оценивается на основании приведенного в [3] подробного описания. Оценки принима- ют значения, приведенные в табл. 7.29.
Табл. 7.29
Степень влияния системных характеристик в баллах
0
Не оказывает влияния, не присутствует в ПС
1
Влияет случайным образом
2
Умеренное влияние
3
Влияние средней силы
4
Значимое влияние
5
Прочное влияние
Основываясь на оценках главных системных характеристик можно рассчитать величину обобщенного фактора сложности задачи — VAF:
VAF = 0, 65 + i
/ 100.
Таким образом, VAF меняется от значения 0,65 (все главные систем- ные характеристики, описанные в таблице 7.30, не учитываются в раз- рабатываемой системе) до 1,35 (все главные системные характеристики полно учтены при проектировании ПС).
348
Табл. 7.30
Системные характеристики
Главная системная
характеристика
Краткое описание
Количество связей
Учитывает количество средств (способов) связи участвующих в обмене или передаче
(корректировке) информации с приложением или системой
Распределение обработки данных
Учитывает влияние на функционирование системы распределения ввода, вывода, корректировки, создания и обработки данных между различными участниками процесса.
Производительность разрабатываемой системы
Учитывает требования к времени исполнения процедур или к производительности процессов обработки данных
Степень модифициру- емости текущей аппа- ратной платформы
Определяется возможностью модификации существующей у пользователя аппаратной платформы для разрабатываемого приложения
Количество транзакций
Определяется частотой выполнения транзакции в день (неделю, месяц и т.д.)
Объем интерактивного ввода
Определяется процентом данных вводимых в интерактивном режиме
Повышение эффектив- ности работы конечного пользователя от внедрения ПС
Учитывает направленность проектирования приложения на улучшение эффективности работы конечного пользователя
Настраиваемость проектируемой ПС
Определяется количеством и типами внутренних объектов ПС, которые могут быть настроены
(скорректированы) в интерактивном режиме
Комплексность обработки
Определяется включением в разрабатываемую ПС расширенной логической или математической обработки
Многократность использования
Определяется тем, насколько полно приложение покрывает нужды конечного пользователя
Удобство установки ПС
Определяется сложностью процессов установки и переустановки ПС
Удобство обслуживания
ПС
Определяется степенью эффективности и автоматизации процессов запуска, сохранения и других существенных для обслуживания ПС процедур
Многопользовательский режим
Насколько проектируемая ПС нацелена на обслуживание разветвленного и изменяющегося в ходе работы множества пользователей и пользовательских организаций
Пригодность (оснащен- ность) ПС к проведению изменений работы без переработки ПС
Заложены ли при проектировании ПС специальные средства изменения ПС при изменении работы пользователей
349
Суммы нескорректированных значения оценок, полученные отдель- но при оценках информационного содержания задачи и ее функцио- нальности умножается на фактор размерности, учитывающий обобщен- ные характеристики программного комплекса, после чего вычисляется оценка проекта в баллах функциональности. На основании балльной оценки, коэффициента перевода (строк/балл) и приведенной производи- тельности рассчитываются прямые затраты на разработку программной системы. Полученную оценку увеличивают на нормативные отчисле- ния, накладные расходы, прочие прямые расходы и плановую прибыль, получая стоимость разработки и внедрения ПС.
Суммируя вышеизложенное, для оценки стоимости разработки и внедрения программного комплекса по методике EFP IFPUG FPA — методике определения функционально оправданной длины кода следует проделать следующие операции: классифицировать информационные и функциональные объекты, составляющие общую задачу; с помощью таблиц оценки информационных элементов и функций в баллах (7.25–7.30), провести оценку проекта; с помощью табл. 7.31 вычислить значение фактора размерности, характеризующего задачу; вычислить приведенное значение — балльную оценку — минималь- ное, усредненное и максимальное значение; с помощью данных табл. 7.24 для выбранного средства разработки кодов (языка программирования, интерфейсов баз данных, языков запросов) вычислить функционально оправданный объем кодов про- граммного комплекса (в трех вариантах); используя среднее значение производительности труда определить трудозатраты коллектива разработчиков на разработку и внедрение
ПС (в трех вариантах); используя внутренние данные разработчика (накладные расходы, маркетинговые устремления и т. д.), определить стоимость ПС с точ- ки зрения разработчика в трех вариантах;
Точность определения трудозатрат характеризуется разбросом полу- ченных значений.
Масштаб
проекта
С
1
Пользователи
объекта
проектирования
С
2
Тип объекта
проектирова-
ния
С
3
Функция
1
Индивидуальное использование
1
Не требующий программирова
-ния
1
Объект
2
Потребители shareware ПО
2
Скрипт
2
Библиотека объектов
4
Академическая среда, инженерия
3
ПО встраивае- мой одноплатной системы
5
Реализация концепции
5
Внутрикорпоратив- ные, локальное использование
5
База данных
6
Прототип для последующего эволюционного развития
6
Внутрикорпоратив- ные, распределенное использование
6
Клиент- серверное ПО
8
Приложение для внутренних нужд
8
Контрактный проект,
Гражданский заказчик
7
Математическо е ПО
9
Приложение под заказ
9
Контрактный проект, заказчик — органы местной власти
8
Коммуникацио нное
ПО
11
Приложение, пригодное к рас- ширению функ- цииональности в ходе жизненного цикла
10
Коммерческий проект, предназначенный для тиражирования
9
ПО управления процессами
12
Компонент внешней системы
11
Контрактный проект, государственное бюд- жетное финансирова- ние
14
ПО встраивае- мой многопро- цессорной системы
13
Новая масштабная система
12
Проект связанный с потенциальной опасностью для жизни
(военные заказчики, служба спасения и т.д.)
15
ПО для общедоступ- ных сервисов
15
343
Таблица 7.22
Соответствие баллов функциональности объему кода для разных
языков программирования
Язык
Строк/балл
Язык
Строк/балл
Access
38
Jovial
107
Ada 83 71
Lisp
64
Ada 95 49
Machine Code
640
Al Shell
49
Modula 2 80
APL
32
Pascal
91
Assembly-Basic
320
PERL
27
Assembly-Macro
213
PowerBuilder
16
Basic-ANSI
64
Prolog
64
Basic-Compiled
91
Query-Default
13
Basic-Visual
32
Report Generator
80
C
128
Second Generation
Language
107
C++
55
Simulation-Default
46
Cobol (Ansi 85)
91
SpreadSheet
6
Database-Default
40
Third Generation
Language
80
Fifth Generation
Language
4
Unix Shell Scripts
107
First Generation
Language
320
Visual Basic 5.0 29
Forth
64
Visual C++
34
Fortran 77 107
High Level
Language
64
Fortran 95 71
HTML 3.0.
15
Fourth Generation
Language
20
Java
53
Балльная оценка информационных элементов
В EFP IFPUG FPA используется три типа информационных струк- тур: информационный объект, объект типа элементов данных и объ-
ект типа элементов последовательности. Информационный объект в методике EFP IFPUG FPA — определенная логикой задачи, пользовате- лем или разработчиком группа данных, удовлетворяющих специфиче- ским требованиям задачи или представлениям потребителя информа- ции. Физическая реализация информационного объекта не играет роли при определении их количества, поэтому последовательности данных, сформированных в рамках единой логики, но имеющих различное фи- зическое воплощение: размещенные в оперативной памяти, размещен- ных во входных или выходных интерфейсных формах или сохраненных в файле — считаются одним и тем же информационным элементом.
Объект типа элементов последовательности в методике EFP IFPUG
FPA — структура элементов данных, определенная пользователем под- группа данных внутри информационного объекта, предназначенная для
344 совершения ИТКСС того или иного бизнес-действия. Объект типа эле- ментов данных в EFP IFPUG FPA — уникальное, распознаваемое поль- зователем неповторяющееся поле записи, элемент массива, или элемент графического интерфейса. На высоком уровне абстракции (на началь- ном этапе рассмотрения проекта) информационный элемент относят к умеренно сложным или очень сложным в зависимости от количества информационных элементов более низкого уровня, включенных в рас- сматриваемый элемент согласно данным табл. 7.23.
При более детальном рассмотрении, по результатам предварительно- го проектирования информационные элементы оцениваются по степени сложности на основании числа включенных в них элементов тип DET и
RET.
Табл. 7.23
Сложность информационного элемента в зависимости
от числа информационных объектов
Сложность информационного
элемента
Число включенных
информационных объектов
Умеренно сложные
2–4
Очень сложные
5–8
На основании оценок сложности информационных элементов каж- дому из них ставится в соответствие количество баллов, определенное табл. 7.25. После проектирования структур информационных элементов
(состава и типов ассоциированных данных), на основании табл. 7.24 и
7.25 рассчитывается уточненное количество баллов функциональности, улучшая оценку трудоемкости изготовления ПО. Три колонки табл. 7.25 дают минимальную, среднюю и максимальную оценку баллов функ- циональности каждого информационного объекта. Согласно общему подходу метода EFP IFPUG FPA все три значения сохраняются, склады- ваются с балльными оценками функциональности ПО и, после норми- рования, учитывающего фактор сложности системы, используются для расчета функционально оправданной длины кода, на основании данных табл. 7.23.
Табл. 7.24
Уточненное количество баллов функциональности в зависимости числа
элементов данных
Объект типа
элементов
последователь-
ности
Объект типа элементов данных
1 - 19 20
- 50
>51 1
Простой
Простой
Промежуточный
2 - 5
Простой
Промежуточный
Комплексный
> 6
Промежуточный
Комплексный
Комплексный
345
Таблица 7.25
Уточненное количество баллов функциональности в зависимо
сти сложности информационных элементов
Информационный элемент
Минимальное значение
Среднее значение
Максимальное значение
Простой
5 6
7
Промежуточный
8 9
10
Комплексный
13 14 15
Умеренно сложный
14 18 22
Очень сложный
27 39 51
Балльная оценка «функциональности» программного
обеспечения
Категория функциональность в EFP IFPUG FPA классифицируется следующим образом: примитив, определяющийся на элементарном уровне проектирова- ния ПС; микрофункция, определяющаяся на детальный уровень проектиро- вания ПС; функция, определяющая промежуточный уровень проектирования
ПС; макрофункция, определяющая верхний уровень проектирования ПС.
Распределение по категориям также определяется количеством примитивов внутри функциональности.
Примитивом называется наименьший представимый при декомпо- зиции процесс, обладающий автономными характеристиками, позво- ляющий пользователю описывать единичные действия, составляющие часть бизнес-процедуры на операционном уровне. Примитивы, связан- ные с вводом/выводом информации, легко определяются на уровне предварительного проектирования.
Примитивы подразделяются на: примитив ввода; примитив вывода; примитив обновления.
Расчет баллов функциональности для примитивов проводится по данным табл. 7.26.
Табл. 7.26
Значения баллов функциональности для примитивов
Минимум
Среднее
Максимум
Примитив ввода
4 5
7
Примитив вывода
5 6
6
Примитив обновления
4 5
7
Микрофункции определяются как 4 типа стандартных функциональ- ных примитива:
346 создания; чтения; обновления; удаления.
Действия микрофунций относятся к элементарным данным, вклю- ченных в один или несколько информационных элементов. Примитивы и функциональные примитивы не следует смешивать между собой.
Функциональные примитивы ассоциируются с понятием управление данными и имеют более абстрактный характер, чем примитивы вво- да/вывода конкретных данных. В традиционном понимании функцио- нальные примитивы – подпрограммы ввода/вывода различных классов данных – объектов, типов и последовательностей данных, в то время как примитивы индивидуальны для каждого процесса и ассоциируются с конкретным видом данных.
Каждая микрофункция оценивается минимально 16 баллами функ- циональности, максимально – 20 баллами, при среднем значение – 18 баллов. Функции определяются как составляющая часть подсистемы – части приложения, позволяющая организовать полную обработку дан- ных пользователя для получения целостного ответа на поставленную задачу. Само приложение может обрабатывать данные для решения не- скольких сходных задач. В зависимости от числа функциональных при- митивов, функции подразделяются на малые, содержащие 5 – 12 функ- циональных примитивов, промежуточные, содержащие 13 – 19 функ- циональных примитивов и большие, содержащие 20 – 25 функциональ- ных примитивов – см. табл. 7.27.
Макрофункции определяются как промежуточные функции, соот- ветствующие в обычной терминологии, подсистемам. Иногда макро- функция и составляет весь проект. Макрофункция – составная часть всей информационной системы (функциональный модуль), решающая группу типовых задач, поставленных перед информационной системой.
Макрофункции также подразделяются на малые 2 – 3 функции, проме- жуточные – на 4 – 7 функций и большие – на 8 – 12 функций. Оценки макрофункций в баллах даны в табл. 7.28.
Табл. 7.27
Классы функций в зависимости от числа функциональных
примитивов
Класс функции
Минимум
Среднее
Максимум
Малая
45 56 67
Промежуточная
73 91 109
Большая
106 133 160
Табл. 7.28
347
Оценки макрофункций в баллах
Функция
Минимум
Среднее
Максимум
Малая
151 215 280
Промежуточная
302 431 560
Большая
603 861 1119
Из определения макрофункций следует, что их следует применять в расчетах на самом верхнем уровне проектирования, в начале постановки задачи. По мере разработки проекта следует проводить корректирую- щие расчеты функциональности программного обеспечения, оценивая функциональность с помощью функций и функциональных примити- вов.
Каждый объект оценивается тремя числовыми величинами – мини- мальным, средним и максимальным значениями, основанными на уни- версальных статистических таблицах, введенных в IFPUG97. После то- го, как каждый объект EFP идентифицирован и оценен с помощью вы- шеприведенных таблиц, все оценки суммируются. При сложении мини- мально возможные, средние и максимальные значения суммируются по отдельности, так что общая оценка – нескорректированная оценка по методу FPA – всегда содержит три значения. Разница между верхней и нижней гранями используется в качестве оценки погрешности метода.
Вычисление величины обобщенного фактора сложности задачи
Величина обобщенного фактора сложности задачи (VAF) рассчиты- вается для каждого проекта с учетом совокупности значений из 14 глав- ных системных характеристик (GSC’s), приведенных ниже. Степень влияния каждой характеристики изменяется от 0 до 5, от полного отсут- ствия влияния характеристики до сильного влияния на разрабатываемое
ПО. Влияние каждой главной системной характеристики оценивается на основании приведенного в [3] подробного описания. Оценки принима- ют значения, приведенные в табл. 7.29.
Табл. 7.29
Степень влияния системных характеристик в баллах
0
Не оказывает влияния, не присутствует в ПС
1
Влияет случайным образом
2
Умеренное влияние
3
Влияние средней силы
4
Значимое влияние
5
Прочное влияние
Основываясь на оценках главных системных характеристик можно рассчитать величину обобщенного фактора сложности задачи — VAF:
VAF = 0, 65 + i
/ 100.
Таким образом, VAF меняется от значения 0,65 (все главные систем- ные характеристики, описанные в таблице 7.30, не учитываются в раз- рабатываемой системе) до 1,35 (все главные системные характеристики полно учтены при проектировании ПС).
348
Табл. 7.30
Системные характеристики
Главная системная
характеристика
Краткое описание
Количество связей
Учитывает количество средств (способов) связи участвующих в обмене или передаче
(корректировке) информации с приложением или системой
Распределение обработки данных
Учитывает влияние на функционирование системы распределения ввода, вывода, корректировки, создания и обработки данных между различными участниками процесса.
Производительность разрабатываемой системы
Учитывает требования к времени исполнения процедур или к производительности процессов обработки данных
Степень модифициру- емости текущей аппа- ратной платформы
Определяется возможностью модификации существующей у пользователя аппаратной платформы для разрабатываемого приложения
Количество транзакций
Определяется частотой выполнения транзакции в день (неделю, месяц и т.д.)
Объем интерактивного ввода
Определяется процентом данных вводимых в интерактивном режиме
Повышение эффектив- ности работы конечного пользователя от внедрения ПС
Учитывает направленность проектирования приложения на улучшение эффективности работы конечного пользователя
Настраиваемость проектируемой ПС
Определяется количеством и типами внутренних объектов ПС, которые могут быть настроены
(скорректированы) в интерактивном режиме
Комплексность обработки
Определяется включением в разрабатываемую ПС расширенной логической или математической обработки
Многократность использования
Определяется тем, насколько полно приложение покрывает нужды конечного пользователя
Удобство установки ПС
Определяется сложностью процессов установки и переустановки ПС
Удобство обслуживания
ПС
Определяется степенью эффективности и автоматизации процессов запуска, сохранения и других существенных для обслуживания ПС процедур
Многопользовательский режим
Насколько проектируемая ПС нацелена на обслуживание разветвленного и изменяющегося в ходе работы множества пользователей и пользовательских организаций
Пригодность (оснащен- ность) ПС к проведению изменений работы без переработки ПС
Заложены ли при проектировании ПС специальные средства изменения ПС при изменении работы пользователей
349
Суммы нескорректированных значения оценок, полученные отдель- но при оценках информационного содержания задачи и ее функцио- нальности умножается на фактор размерности, учитывающий обобщен- ные характеристики программного комплекса, после чего вычисляется оценка проекта в баллах функциональности. На основании балльной оценки, коэффициента перевода (строк/балл) и приведенной производи- тельности рассчитываются прямые затраты на разработку программной системы. Полученную оценку увеличивают на нормативные отчисле- ния, накладные расходы, прочие прямые расходы и плановую прибыль, получая стоимость разработки и внедрения ПС.
Суммируя вышеизложенное, для оценки стоимости разработки и внедрения программного комплекса по методике EFP IFPUG FPA — методике определения функционально оправданной длины кода следует проделать следующие операции: классифицировать информационные и функциональные объекты, составляющие общую задачу; с помощью таблиц оценки информационных элементов и функций в баллах (7.25–7.30), провести оценку проекта; с помощью табл. 7.31 вычислить значение фактора размерности, характеризующего задачу; вычислить приведенное значение — балльную оценку — минималь- ное, усредненное и максимальное значение; с помощью данных табл. 7.24 для выбранного средства разработки кодов (языка программирования, интерфейсов баз данных, языков запросов) вычислить функционально оправданный объем кодов про- граммного комплекса (в трех вариантах); используя среднее значение производительности труда определить трудозатраты коллектива разработчиков на разработку и внедрение
ПС (в трех вариантах); используя внутренние данные разработчика (накладные расходы, маркетинговые устремления и т. д.), определить стоимость ПС с точ- ки зрения разработчика в трех вариантах;
Точность определения трудозатрат характеризуется разбросом полу- ченных значений.