Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

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

следующие элементы приложений разрабатываемой системы.

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

\, Внутренний

логический файл

(internal logicalfiky

ILF) —

иден-

тифицируемая совокупность логически взаимосвязанных запи-

сей данных, поддерживаемая внутри приложения посредством

элементарного процесса (рис. 6.4).

Приложение

а.

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

Рис. 6.4. Внугренний логический файл

Внешний интерфейсный

файл (external

interface

file, Elf)

—

идентифицируемая совокупность логически взаимосвязанных за-

писей данных, передаваемых другому приложению или получае-

мых от него и поддерживаемых вне данного приложения (рис. 6.5).

Приложение

=г

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

Рис.

6.5. Внешний интерфейсный файл

434

Глава 6

Входной элемент приложения (external

input,

EI)

—

элемен-

тарный процесс, связанный с обработкой входной информации

приложения

—

входного документа или экранной формы. Обра-

батываемые данные могут соответствовать одному или более ILF

(рис.

6.6).

Приложение

-3 4

-Данные

Управляющая

" информация

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

Рис. 6.6. Входной элемент приложения

Выходной элемент приложения (external

output,

ЕО) —

эле-

ментарный процесс, связанный с обработкой выходной инфор-

мации приложения

—

выходного отчета, документа, экранной

формы (рис. 6.7).

Данные

1 Приложение

Управляющая

информация

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

Рис. 6.7. Выходной элемент приложения

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

Внешний запрос (external

query,

EQ) ~ элементарный про-

цесс, состоящий из комбинации «запрос/ответ», не связанный с

вычислением производных данных или обновлением ILF (базы

данных) (рис. 6.8).

<3>

рилОЖение

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

Количество

RET

2-5

' 6 +

Количество DET

1-19

Низкая

Средняя

20-50

Низкая

Средняя

Высокая

51+

Средняя

Высокая

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.

Таблица 6.2

Сложность EI

Количество

FTR

0-1

3 +

Количество

FTR

0-1

2-3

4 +

1-4

Низкая

Средняя

Слод

1-5

Низкая

Средняя

Количество DET

5-15

Низкая

Средняя

Высокая

кность ЕО

Количество DET

6-19

Низкая

Средняя

Высокая

Средняя

Высокая

Таблица 6.3

20 +

Средняя

Высокая 1

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

Сложность EQ определяется как максимальная из сложнос-

тей EI и ЕО, связанных с данным запросом.

6.2.4.

ПОДСЧЕТ КОЛИЧЕСТВА ФУНКЦИОНАЛЬНЫХ ТОЧЕК

Для каждого функционального типа подсчитывается количе-

ство входящих в его состав функциональных точек (function

point, FP)

—

условных элементарных единиц. Этот подсчет вы-

полняется в соответствии с табл. 6.4.

Таблица 6.4

Зависимость количества FP

от

сложности функционального

типа

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

тип

ILF

EIF

' EI

ЕО

Сложность

Низкая

Средняя

Высокая

В результате суммирования количества 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

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

Сбор

данных

режиме «онлайн» или дистанционная обработка, свя-

занная с пакетным процессом

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

протокола

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

онного протокола

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

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

сутствует

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

зователя

2 Данные готовятся для передачи, затем передаются и обрабатываются

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

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

только в одном направлении

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

обоих направлениях

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

ненте системы

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

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

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

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

каких специальных действий

2 Время реакции или пропускная способность являются критически-

ми

пиковые периоды. Не требуется никаких специальных решений

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

жет быть завершена в течение следующего рабочего дня

3 Время реакции или пропускная способность являются критически-

ми в обычное рабочее время. Не требуется никаких специальных ре-

шений относительно использования ресурсов процессора. Время

обработки ограничено взаимодействующими системами

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

ности достаточно серьезны, чтобы ее необходимо было анализиро-

вать на стадии проектирования

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

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

производительности используются специальные средства анализа