Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

.pdf
Скачиваний:
115
Добавлен:
14.05.2016
Размер:
14.05 Mб
Скачать

Оценка трудоемкости создания программного обеспечения 431

единственный способ учета с помощью LOC по отношению

кразрабатываемому ПО заключается в использовании ме­ тода аналогии на основе сравнения функциональных свойств у подобных программных продуктов, либо в ис­ пользовании мнений экспертов (однако эти методы не от­ носятся к числу точных);

генераторы кода зачастую продуцируют чрезмерный объем кода, в результате чего искажаются показатели LOC.

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

6-2. МЕТОДИКА ОЦЕНКИ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ ТОЧЕК

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

Подсчет функциональных точек, помимо средства для объек­ тивной оценки ресурсов, необходимых для разработки и сопро­ вождения ПО, применяется также в качестве средства для опре­ деления сложности приобретаемого продукта с целью принятия решения о покупке или собственной разработке.

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной орга­ низацией IFPUG (International Function Point User Group). Рас­ сматриваемый в данном разделе сокращенный вариант методики оценки трудоемкости разработки ПО основан на материалах IFPUG и компании SPR (Software Productivity Research), которая является одним из лидеров в области методов и средств оценки характеристик ПО.

Согласно данной методике трудоемкость вычисляется на ос­ нове функциональности разрабатываемой системы, которая, в свою очередь, определяется на основе выявления функциональных типов — логических групп взаимосвязанных данных, используе-

432

Глава 6

мых и поддерживаемых приложением, а также элементарных про­ цессов, связанных с вводом и выводом информации (рис. 6.2).

Приложение

Пользователь

Рис. 6.2. Выявление функциональных типов

Порядок расчета трудоемкости разработки ПО:

определение количества и сложности функциональных ти­ пов приложения;

определение количества связанных с каждым функциональ­ ным типом элементарных данных (DET), элементарных за­ писей (RET) и файлов типа ссылок (FTR);

определение сложности (в зависимости от количества DET, RET и FTR);

подсчет количества функциональных точек приложения;

подсчет количества функциональных точек с учетом общих характеристик системы (рис.6.3);

оценка трудоемкости разработки (с использованием различ­ ных статистических данных).

Функциональные

типы

Общие

характеристики

системы

Модель

Количество

функциональных

- ^ функциональных

точек

точек

Рис. 6.3. Определение количества функциональных точек

6.2.1. ОПРЕДЕЛЕНИЕ ФУНКЦИОНАЛЬНЫХ ТИПОВ

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

Оценка трудоемкости создания программного обеспечения 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) и элементарных

436

Глава 6

записей (record element types, RET), которые в свою очередь оп­ ределяются следующим образом:

DET — уникальный идентифицируемый нерекурсивный элемент данных (включая внешние ключи), входящий в ILF или EIF;

RET — идентифицируемая подфуппа элементов данных, входящая в ILF или EIE На диаграммах «сущность-связь» такая подгруппа обычно представляется в виде сущностиподтипа в связи «супертип-подтип».

Один DET соответствует отдельному атрибуту или связи класса. Количество DET не зависит от количества объектов клас­ са или количества связанных объектов. Если данный класс свя­ зан с некоторым другим классом, который обладает явно задан­ ным идентификатором, состоящим более чем из одного атрибу­ та, то для каждого такого атрибута определяется один отдельный DET (а не один DET на всю связь). Производные атрибуты могут игнорироваться. Повторяющиеся атрибуты одинакового форма­ та рассматриваются как один DET.

Одна RET на диаграмме устойчивых классов соответствует либо абстрактному классу в связи обобщения (generalization), ли­ бо классу - «части целого» в композиции, либо классу с рекур­ сивной связью «родитель-потомок» (афегацией).

Зависимость сложности функциональных типов от количест­ ва DET и RET определяется следующей таблицей (табл. 6.1).

Таблица 6.1

 

 

Сложность ILF и EIF

 

 

 

Количество

 

Количество DET

 

 

 

RET

1-19

20-50

5 1 +

j

 

1

Низкая

Низкая

Средняя

 

 

2 - 5

Низкая

Средняя

Высокая

 

'

6 +

Средняя

Высокая

Высокая

 

6.2.3. ОПРЕДЕЛЕНИЕ КОЛИЧЕСТВА И СЛОЖНОСТИ ТРАНЗАКЦИОННЫХ ФУНКЦИОНАЛЬНЫХ ТИПОВ

Количество транзакционных функциональных типов (вход­ ных элементов приложения, выходных элементов приложения и внешних запросов) определяется на основе выявления входных

Оценка трудоемкости создания программного обеспечения 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 Пакетная обработка, удаленный ввод данных и удаленная печать

440

Глава 6

Коммуникации данных

3Сбор данных в режиме «онлайн» или дистанционная обработка, свя­ занная с пакетным процессом

4Несколько внешних интерфейсов, один тип коммуникационного протокола

5Несколько внешних интерфейсов, более одного типа коммуникаци­ онного протокола

Распределенная обработка данных

0Передача данных или процессов между компонентами системы от­ сутствует

1Приложение готовит данные для обработки на ПК конечного поль­ зователя

2Данные готовятся для передачи, затем передаются и обрабатываются на другом компоненте системы (не на ПК конечного пользователя)

3Распределенная обработка и передача данных в режиме «онлайн» только в одном направлении

4Распределенная обработка и передача данных в режиме «онлайн» в обоих направлениях

5Динамическое выполнение процессов в любом подходящем компо­ ненте системы

Производительность

0К системе не предъявляется специальных требований, касающихся производительности

1Требования к производительности определены, но не требуется ни­ каких специальных действий

2Время реакции или пропускная способность являются критически­ ми в пиковые периоды. Не требуется никаких специальных решений относительно использования ресурсов процессора. Обработка мо­ жет быть завершена в течение следующего рабочего дня

3Время реакции или пропускная способность являются критически­ ми в обычное рабочее время. Не требуется никаких специальных ре­ шений относительно использования ресурсов процессора. Время обработки ограничено взаимодействующими системами

4То же, кроме того, пользовательские требования к производитель­ ности достаточно серьезны, чтобы ее необходимо было анализиро­ вать на стадии проектирования

5То же, кроме того, на стадиях проектирования, разработки и (или) реализации для удовлетворения пользовательских требований к производительности используются специальные средства анализа