1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfОценка трудоемкости создания программного обеспечения 431
•единственный способ учета с помощью LOC по отношению
кразрабатываемому ПО заключается в использовании ме тода аналогии на основе сравнения функциональных свойств у подобных программных продуктов, либо в ис пользовании мнений экспертов (однако эти методы не от носятся к числу точных);
•генераторы кода зачастую продуцируют чрезмерный объем кода, в результате чего искажаются показатели LOC.
Результатом этих соображений явилось осознание необходи мости другой единицы измерения, в качестве которой стали выс тупать функциональные точки.
6-2. МЕТОДИКА ОЦЕНКИ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ ТОЧЕК
Определение числа функциональных точек является методом количественной оценки ПО, применяемым для измерения функ циональных характеристик процессов его разработки и сопро вождения независимо от технологии, использованной для его ре ализации.
Подсчет функциональных точек, помимо средства для объек тивной оценки ресурсов, необходимых для разработки и сопро вождения ПО, применяется также в качестве средства для опре деления сложности приобретаемого продукта с целью принятия решения о покупке или собственной разработке.
Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной орга низацией IFPUG (International Function Point User Group). Рас сматриваемый в данном разделе сокращенный вариант методики оценки трудоемкости разработки ПО основан на материалах IFPUG и компании SPR (Software Productivity Research), которая является одним из лидеров в области методов и средств оценки характеристик ПО.
Согласно данной методике трудоемкость вычисляется на ос нове функциональности разрабатываемой системы, которая, в свою очередь, определяется на основе выявления функциональных типов — логических групп взаимосвязанных данных, используе-
Оценка трудоемкости создания программного обеспечения 4 3 3
\, Внутренний логический файл (internal logicalfiky ILF) — иден тифицируемая совокупность логически взаимосвязанных запи сей данных, поддерживаемая внутри приложения посредством элементарного процесса (рис. 6.4).
Приложение
о
о
Ф
оIT
а.
Пользователь Рис. 6.4. Внугренний логический файл
2. Внешний интерфейсный файл (external interface file, Elf) —
идентифицируемая совокупность логически взаимосвязанных за писей данных, передаваемых другому приложению или получае мых от него и поддерживаемых вне данного приложения (рис. 6.5).
Приложение
|
о |
|
о |
|
ф |
|
=г |
|
о |
|
а |
UL |
с |
Ш |
|
Пользователь
Рис. 6.5. Внешний интерфейсный файл
4 34 |
Глава 6 |
3. Входной элемент приложения (external input, EI) — элем тарный процесс, связанный с обработкой входной информации приложения — входного документа или экранной формы. Обра батываемые данные могут соответствовать одному или более ILF (рис. 6.6).
Приложение
|
|
-Данные |
-3 4 |
ш |
Управляющая |
|
" информация
Пользователь
Рис. 6.6. Входной элемент приложения
4. Выходной элемент приложения (external output, ЕО) —
ментарный процесс, связанный с обработкой выходной инфор мации приложения — выходного отчета, документа, экранной формы (рис. 6.7).
1 Приложение
Данные1
О
ш
Управляющая
информация
Пользователь
Рис. 6.7. Выходной элемент приложения
Оценка трудоемкости создания программного обеспечения 435
5. Внешний запрос (external query, EQ) ~ элементарный про цесс, состоящий из комбинации «запрос/ответ», не связанный с вычислением производных данных или обновлением ILF (базы данных) (рис. 6.8).
|
прилОЖение |
|
|
|
< 3 > |
U. |
1 |
О |
|
^ |
,— ....^ |
ш |
Входные/ |
|
U. |
*•*..«..*> |
^ — |
1^ выходные |
|
ш |
|
• |
|
данные |
Пользователь
Рис. 6.8. Внешний запрос
6.2.2. ОПРЕДЕЛЕНИЕ КОЛИЧЕСТВА И СЛОЖНОСТИ ФУНКЦИОНАЛЬНЫХ ТИПОВ ПО ДАННЫМ
Количество функциональных типов по данным (внутренних логических файлов и внешних интерфейсных файлов) определя ется на основе диафамм «сущность-связь» (для структурного подхода) и диаграмм классов (для объектно-ориентированного подхода). В последнем случае в расчете участвуют только устой чивые (persistent) классы, или классы-сущности.
Устойчивый класс соответствует ILF (если его объекты обяза тельно создаются внутри самого приложения) или EIF (если его объекты не создаются внутри самого приложения, а получаются в результате запросов к базе данных).
Примечание. Если операции класса являются операциями-запроса ми, то это характеризует его принадлежность к EIE
Для каждого выявленного функционального типа (ILF и EIF) определяется его сложность (низкая, средняя или высокая). Она зависит от количества связанных с этим функциональным типом элементарных данных (data element types, DET) и элементарных
Оценка трудоемкости создания программного обеспечения 437
и выходных документов, экранных форм, отчетов, а также по ди аграммам классов (в расчете участвуют граничные классы).
Далее для каждого выявленного функционального типа (EI, ЕО или EQ) определяется его сложность (низкая, средняя или высокая). Она зависит от количества связанных с этим функцио нальным типом DET, RET и файлов типа ссылок (file type refer enced, FTR) ~ ILF или EIF, читаемых или модифицируемых функциональным типом.
Правила расчета DET для EI:
•каждое нерекурсивное поле, принадлежащее (поддерживае мое) ILF и обрабатываемое во вводе;
•каждое поле, которое пользователь хотя и не вызывает, но оно через процесс ввода поддерживается в ILF;
•логическое поле, которое физически представляет собой множество полей, но воспринимается пользователем как единый блок информации;
•группа полей, которые появляются в ILF более одного раза, но в связи с особенностями алгоритма их использования воспринимаются как один DET;
•фуппа полей, которые фиксируют ошибки в процессе об работки или подтверждают, что обработка закончилась ус пешно;
•действие, которое может быть выполнено во вводе.
Правила расчета DET для ЕО:
•каждое распознаваемое пользователем нерекурсивное поле, участвующее в процессе вывода;
•поле, которое физически отображается в виде нескольких полей его составляющих, но используемое как единый ин формационный элемент;
•каждый тип метки и каждое значение числового эквивален та при графическом выводе;
•текстовая информация, которая может содержать одно сло во, предложение или фразу;
•литералы не могут считаться элементами данных;
•переменные, определяющие номера страниц или генериру емые системой логотипы не являются элементами данных.
438 |
Глава 6 |
Правила расчета DET для EQ.
Правила определения ОЕТдля вводной части:
•каждое распознаваемое пользователем нерекурсивное поле, появляющееся во вводной части запроса;
•каждое поле, которое определяет критерий выбора данных;
•группа полей, в которых выдаются сообщения о возникаю щих ошибках в процессе ввода информации в DET или подтверждающих успешное завершение процесса ввода;
•фуппа полей, которые позволяют выполнять запросы.
Правила определения ОЕТдля выводной части:
•каждое распознаваемое пользователем нерекурсивное поле, которое появляется в выводной части запроса;
•логическое поле, которое физически отображается как группа полей, однако воспринимается пользователем как единое поле;
•группа полей, которые в соответствии с методикой обработ ки могут повторяться в ILF;
•литералы не могут считаться DET.
•колонтитулы или генерируемые системой иконки не могут считаться DET.
Зависимость сложности функциональных типов от количест ва DET, RET или FTR определяется по табл. 6.2 и 6.3.
|
|
Сложность EI |
Таблица 6.2 |
|
|
|
|
|
|
Количество |
|
Количество DET |
|
|
FTR |
1-4 |
5 - 15 |
16 + |
|
0 - 1 |
Низкая |
Низкая |
Средняя |
|
2 |
Низкая |
Средняя |
Высокая |
|
3 + |
Средняя |
Высокая |
Высокая |
|
|
|
Слодкность ЕО |
Таблица 6.3 |
|
|
|
|
|
|
Количество |
|
Количество DET |
|
|
FTR |
1-5 |
6 - 1 9 |
20 + |
|
0 - 1 |
Низкая |
Низкая |
Средняя |
|
2 - 3 |
Низкая |
Средняя |
Высокая |
1 |
4 + |
Средняя |
Высокая |
Высокая |
1 |
Оценка трудоемкости создания программного обеспечения 439
Сложность EQ определяется как максимальная из сложнос тей EI и ЕО, связанных с данным запросом.
6. 2.4. ПОДСЧЕТ КОЛИЧЕСТВА ФУНКЦИОНАЛЬНЫХ ТОЧЕК
Для каждого функционального типа подсчитывается количе ство входящих в его состав функциональных точек (function point, FP) — условных элементарных единиц. Этот подсчет вы полняется в соответствии с табл. 6.4.
|
|
|
|
Таблица 6.4 |
|
|
Зависимость количества FP от сложности функционального типа |
||||
|
Функциональный |
|
Сложность |
|
|
|
тип |
Низкая |
Средняя |
Высокая |
|
|
ILF |
7 |
10 |
15 |
|
|
EIF |
5 |
7 |
10 |
|
' |
EI |
3 |
4 |
6 |
|
|
ЕО |
4 |
5 |
7 |
|
|
EQ |
3 |
4 |
6 |
1 |
|
В результате суммирования количества FP по всем функцио |
||||
нальным типам |
получается |
общее количество |
FP |
(UFP, |
Unadjusted Function Points) без учета поправочного коэффициен та. Значение поправочного коэффициента (VAF, Value Adjustment Factor) определяется набором из 14 общих характеристик систе мы (GSC, General System Characteristics) и вычисляется по следу ющей формуле:
VAF = (0,65 + (sum GSC * 0,01)).
Значения GSC варьируются в диапазоне от О до 5 и определя ются по данным, приведенным ниже.
Коммуникации данных
0 Полностью пакетная обработка на локальном ПК
1 Пакетная обработка, удаленный ввод данных или удаленная печать
2 Пакетная обработка, удаленный ввод данных и удаленная печать