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


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

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



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

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

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

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

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

1. Установление границ данного ПС не вызывает трудностей, так как оно является полностью локальным, и обмен данными с другими ПС в нем не предусматривается.

2. В ПС имеется один внутренний логический файл (ILF) для хранения информации справочника. Причем, данные могут храниться как в обычном файле, так и в таблице СУБД.

Рис. 4.5. Экранная форма телефонного справочника

 

Число типов элементов записей (RET) для этого файла может быть равно единице, если данные в файле хранятся в виде однотипных записей: «Телефон», «Фамилия» и «Адрес», допустим, представлены в символьном формате. В случае же, если номер телефона будет представлен, как целое число, а фамилия и адрес в символьном формате, то тогда внутренний логический файл будет иметь два RET. Для определенности далее будем считать, что внутренний логический файл имеет два RET.

Число типов элементов данных (DET) внутреннего логического файла будет равно трем вне зависимости от формата представления номера телефона («Телефон», «Фамилия», «Адрес»). Таким образом, уровень сложности внутреннего логического файла – низкий (см. табл. 4.1).

Внешних интерфейсных файлов (EIF) данное ПС не имеет.

3. В ПС имеются два внешних ввода (EI): «Добавление записи» и «Удаление записи», поскольку именно эти две функции ПС модифицируют данные во внутреннем логическом файле. Так как внешний ввод «Добавление записи» ссылается на один внутренний логический файл и имеет пять элементов данных (поля «Телефон», «Фамилия», «Адрес», кнопка «Добавить» и сообщение, подтверждающее факт добавления записи), то уровень сложности этого ввода низкий (см. табл. 4.2). Аналогично, уровень сложности внешнего ввода «Удаление записи» также низкий, поскольку имеется один FTR и пять DET (поля «Телефон», «Фамилия», «Адрес», кнопка «Удалить» и сообщение, подтверждающее факт удаления записи).

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

В ПС имеется также один внешний вывод (EO): вывод уведомляющего сообщения при попытке добавить запись с существующим номером телефона. Уровень сложности этого внешнего вывода – низкий, так как он имеет один FTR и два DET: номер телефона и само сообщение.

Полученные данные сведем в табл. 4.9. и рассчитаем ненормированное количество функциональных точек UFPC по формуле 4.1.

 

Таблица 4.9. Данные для расчета числа UFPC телефонного справочника

Характеристика Уровень сложности Итого
Кол. Низкий Ранг Итог
Внешние вводы (EI)        
Внешние выводы (ЕО)        
Внешние запросы (EQ)        
Внутренние логические файлы (ILF)        
Внешние интерфейсные файлы (EIF)        
Итого (UFPC)  

 

4. Подсчитаем теперь с помощью табл. 4.5. и формулы (4.2) итоговую степень влияния (TDI) общих характеристик системы и нормирующий фактор (VAF).

В результате выясним, что для телефонного справочника важны следующие характеристики:

· «Диалоговый ввод данных» (п. 6 табл. 4.5), который оценивается с весом – 5, поскольку все 100% транзакций в ПС являются интерактивными;

· «Эффективность для конечного пользователя» (п. 7 табл. 4.5), которая оценивается с весом – 1, поскольку в ПС имеются функции автоматической установки курсора, скроллинга и интерфейс с мышью;

· «Простота использования» (п. 12 табл. 4.5), которая оценивается с весом – 5, поскольку в ПС все функции автоматизированы за исключением загрузки/выключения и имеется автоматическое восстановление после ошибок;

· «Распространенность» (п. 13 табл. 4.5), которая оценивается с весом – 2, поскольку ПС рассчитано на работу на совместимом аппаратном/программном обеспечении;

· «Легкость изменения» (п. 14 табл. 4.5), которая оценивается с весом – 2, поскольку ПС хранит информацию в таблицах, поддерживаемых пользователем в диалоговом режиме.

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

Нормирующий фактор (VAF) определится как

5. Таким образом, нормированное количество функциональных точек для телефонного справочника вычисляется по формуле (4.3):

В заключение, оценим количество строк исходного кода с использованием бэкфайер-метода и табл. 4.6, исходя из того, что программу необходимо разработать с использованием языка программирования C++:

Таким образом, законченная программа телефонного справочника будет содержать примерно 975 строк исходного кода на языке программирования C++.



Поделиться:


Последнее изменение этой страницы: 2017-02-09; просмотров: 1573; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.238.161.165 (0.048 с.)