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

Общая цель анализа по методу функциональных точек – это подсчет нормированного количества функциональных точек. Этот процесс включает в себя пять шагов:

1. Определение границ ПС.

2. Идентификация и оценка функциональности данных (ILF, EIF).

3. Идентификация и оценка функциональности транзакций (EI, EO, EQ).

4. Определение значения нормирующего фактора (VAF).

5. Подсчет нормированного количества функциональных точек.

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

Источниками информации для выполнения всех этих шагов могут служить:

· Общая спецификация на ПС (техническое задание - ТЗ), включающая функциональную спецификацию и спецификацию качества;

· Имеющаяся на момент оценки документация по интерфейсам;

· Имеющаяся на момент оценки документация разработчика;

· Отчеты по другим метрикам ПС;

· Общение с пользователями;

· Прототип руководства пользователя;

· Результаты функционального моделирования;

· Логическая модель данных;

· Диаграммы потоков данных;

· Результаты системного анализа, полученные с использованием различных методик, например, таблиц решений, сетей Петри, диаграмм UML и т.п.

1. Определение границ ПС.

Границы ПС могут быть установлены уже на ранних этапах жизненного цикла продукта. Например, если ПС разрабатывается в ходе замещающего проекта, то его границы должны, очевидно, быть подобны (а, возможно, и полностью совпадать) с границами ранее существовавшего ПС. Если ПС является принципиально новым то, чтобы правильно определить его границы, необходимо установить границы других ПС, работающих совместно с рассматриваемым.

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

Границы для приложений клиент/сервер должны формироваться и для клиента и для сервера. Причина заключается в том, что ни клиент, ни сервер не обеспечивают в отдельности требований пользователя. То есть по отдельности они не являются завершенным ПС.

2. Идентификация и оценка функциональности данных (ILF и EIF).

Как уже отмечалось, ILF и EIF являются логически связанными группами данных (файлами, таблицами баз данных и т.п.), определяемыми пользователем и необходимыми для работы рассматриваемого ПС. Оба эти типа файлов могут использоваться ПС при генерации внешних выводов (EO), а также при обслуживании внешних запросов (EQ). Разница между ними состоит лишь в том, что ILF поддерживаются самим рассматриваемым ПС путем использования внешних вводов (EI), а EIF поддерживаются каким-либо другим ПС.

Функциональность логических файлов (ILF и EIF) оценивается путем подсчета количества типов элементов записей (RET) и количества типов элементов данных (DET), входящих в соответствующие логические группы данных. При этом под количеством RET обычно понимается количество различных логических подгрупп данных, выделяемых в файле с точки зрения пользователя, или количество различных используемых форматов записей, а под количеством DET - количество различных элементарных полей в этих записях.

Основным источником информации для оценки количества RET и DET в логическом файле могут служить, например, словарь данных (Data Dictionary), составленный в ходе моделирования информационной системы с использованием диаграмм потоков данных, логическая структура баз данных, полученная при построении моделей «сущность-связь», логическая структура файлов или баз данных, поддерживаемых другими ПС и описанная в их документации (для EIF), и т.п.

В целом задача оценки количества RET в методе функциональных точек одна из самых сложных и результат ее решения достаточно сильно зависит от точки зрения оценивающего.

Что касается количества DET в логическом файле, то их выделение и подсчет можно связать с процедурой поддержки этого файла, осуществляемой с помощью транзакционной функции внешнего ввода (EI). Очевидно, что все различные типы полей данных, используемые во внешних вводах (EI), поддерживающих данный логический файл, и составят набор DET этого файла. Как подсчитывается количество DET во внешнем вводе, будет рассмотрено несколько позже.

3. Идентификация и оценка функциональности транзакций (EI, EO, EQ).

Напомним, что элементарные процессы, в которых данные пересекают границу ПС снаружи внутрь, называются внешними вводами (EI). Важными источниками информации для определения внешних вводов являются форматы экранов и диалогов ввода, а также любые другие формы ввода данных в ПС. Например, дополнительные вводы из других приложений или вводы с различных внешних устройств, органов управления, датчиков и т.п. в системах реального времени и встраиваемых системах также необходимо учитывать. При этом такие вводы должны обновлять внутренние логические файлы рассматриваемого ПС.

Элементарные процессы, в которых данные пересекают границу ПС изнутри наружу, называются внешними выводами (EO). Важными источниками информации для определения внешних выводов являются форматы экранов и диалогов вывода, формы отчетов и уведомляющих сообщений, а также любые другие формы вывода данных в ПС. Например, выводы на различные внешние устройства, органы управления, исполнительные механизмы и т.п. в системах реального времени и встраиваемых системах также необходимо учитывать. При этом такие выводы должны сопровождаться процессами генерирования выводимых данных или управляющей информации, вычислениями и т.п.

Элементарные процессы, в которых данные пересекают границу ПС в обе стороны в ходе диалога, называются внешними запросами EQ. Важными источниками информации для определения внешних запросов являются форматы экранов и диалогов ввода-вывода, а также любые другие формы ввода-вывода данных в ПС, осуществляемые в диалоговом режиме. Например, выводы на различные внешние устройства, органы управления, исполнительные механизмы и т.п. каких-либо фиксированных данных в ответ на введенный каким-либо образом запрос в системах реального времени и встраиваемых системах также необходимо учитывать. Главным отличием внешних запросов EQ от внешних вводов EI и внешних выводов EO является то, что введенные в ПС с их помощью данные не записываются во внутренние логические файлы, а выводимая ими информация не является результатом какого-либо вычислительного процесса, а просто выбирается без всякой обработки из внутренних логических или внешних интерфейсных файлов.

В табл. 4.7. приведены примеры элементов данных, которые могут рассматриваться в различных видах транзакций в методе функциональных точек применительно к ПС с преобладанием графического пользовательского интерфейса (GUI), например, информационных систем, а также ПС систем реального времени и встраиваемых систем.

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

Различные FTR позволяют отличать внешние вводы, выводы или запросы друг от друга. Любой FTR должен быть либо внутренним логическим файлом (ILF), либо внешним интерфейсным файлом (EIF). Каждый внутренний логический файл, связанный с внешним вводом, выводом или запросом считается за один FTR. Каждый внешний интерфейсный файл, связанный с внутренним логическим файлом в ходе элементарного процесса поддержки внутреннего логического файла, внешнего вывода или запроса, также считается за FTR. Например, внешний ввод может обновлять внутренний логический файл, но в то же время ссылаться на «файл безопасности», являющийся по отношению к рассматриваемому ПС внешним интерфейсным файлом, чтобы убедиться, что пользователь имеет соответствующий уровень доступа. Это как раз тот случай, когда необходимо для данного внешнего ввода учитывать два FTR.

Таблица 4.7. Примеры элементов данных для транзакций модели функциональных точек

Транзакция	Элементы данных
	ПС с преобладанием GUI	ПС систем реально го времени и встраиваемых систем
Внешний ввод	Различные поля ввода данных, сообщения об ошибках, вычисляемые значения, радио-кнопки, флажки, кнопки управления, вводы из других приложений, подтверждающие сообщения и т.п.	Элементы управления программные и аппаратные, показания датчиков, радиосигналы, положения переключателей и т.п.
Внешний вывод (ЕО)	Поля данных в отчетах, заголовки полей данных отчетов из внутренних логических файлов, вычисляемые значения, сообщения об ошибках, подтверждающие и уведомляющие сообщения и т.п.	Световые сигналы, звуковые сигналы, сигналы на исполнительные механизмы, переключатели, показания индицирующих элементов и т.п.
Внешний запрос (EQ)	Вводимые элементы: поля, используемые для поиска, управляющие кнопки и т.п. Выводимые элементы: отображаемые на экране поля, изображения, звуки и т.п.	Вводимые элементы: элементы управления программные и аппаратные и т.п. Выводимые элементы: световые сигналы, звуковые сигналы, показания индицирующих элементов и т.п.

Различные группы элементов данных (DET) также позволяют отличать внешние вводы, выводы или запросы друг от друга. Таким образом, можно считать, что уникальная группа DET создает элементарный процесс, называемый EI, EO или EQ.

В современных ПС наибольшее распространение получил графический пользовательский интерфейс (GUI), поэтому приведем более подробно правила подсчета DET при использовании такого типа интерфейса в табл. 4.8.

Таблица 4.8. Правила подсчета элементов данных (DET) при использовании GUI

Элемент данных	Правило подсчета
Поле ввода данных	Считается одним элементом данных
Группа радио­кнопок (Eadio Buttons)	Так как в группе при каждом вводе можно выбрать только одну радио-кнопку, вся группа считается одним элементом данных
Группа флажков (Check Box)	Так как в группе при каждом вводе можно выбрать несколько флажков, каждый флажок считается одним элементом данных
Командная кнопка (Button)	Каждая командная кнопка, которая инициирует транзакцию считается одним элементом данных
Список (pick List, Drop Down, Lookup)	Данные списка могут быть получены в результате внешнего запроса, и могут быть элементом данных внешнего ввода
Элемент графического изображения	Изображение, сохраняющееся во внутреннем логическом файле целиком, считается одним элементом данных
Сообщение об ошибке	Считается одним элементом данных соответствующей транзакции, а не отдельным внешним выводом или запросом
По д тв ер ущ ающ ее сообщение	Считается одним элементом данных соответствующей транзакции, а не отдельным внешним выводом или запросом
Уведомление (предупреждающее сообщение)	Уведомление рассматривается как внешний вывод, так как использует данные из внутреннего логического или внешнего интерфейсного файла и производится при определенном состоянии ПС
Звуковой сигнал	Считается одним элементом данных соответствующей транзакции вне зависимости от длительности воспроизведения или количества воспроизводимых нот

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

Каждый управляющий ключ (командная кнопка, такая как OK, Next и т.п.) считаются как один DET, если они инициируют какую-либо транзакцию. С другой стороны, если группа управляющих ключей выполняет одну и ту же функцию (транзакцию), то такую группу также учитывают как один DET.

4. Определение значения нормирующего фактора (VAF).

Определение значения нормирующего фактора (VAF) производится с использованием табл. 4.5. и формулы 4.2. экспертным способом.

5. Подсчет нормированного количества функциональных точек.

Подсчет нормированного количества функциональных точек производится с использованием формул 4.1. и 4.3. Следует заметить, что во многих организациях процедуру нормирования количества функциональных точек считают опциональной (необязательной).