Значение языкового множителя для метода обратного запуска

Внешние и внутренние метрики размера ПС

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

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

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

С FPC дело обстоит иначе, этот метод напрямую связан с требованиями пользователя к системе, которые уже выражены в виде логических групп данных и автоматизированных бизнес-процессов. Этоозначает, что FPC можно посчитать достаточно точно даже на раннихэтапах цикла разработки ПС. Объективность же оценки FPC зависит
только от правильности использования метода функциональных точек и от качества подготовленного внешнего описания ПС. Всѐ этоделает FPC очень удобной метрикой для планирования графика работи распределения бюджета программных проектов.
В отличие от SLOC, существует проверенная годами стандартная методология с очень детальным руководством для подсчѐта FPC,IFPUG CountingPracticesManual (Руководство по методам расчѐтоворганизации IFPUG). В этом руководстве есть множество примеров,демонстрирующих расчѐты различных показателей для разных видов
ПС (базы данных; системы, базирующиеся на структурном анализе и
проектировании, на объектно-ориентированном анализе и проектировании, системы с графическим интерфейсом пользователя, системыреального времени и т.д.).

Приведѐнные примеры демонстрируют высокую корреляциюмежду FPC и реальным объемом работ, требующихся для завершенияпроекта. Именно поэтому правомерно подставлять FPC вместо SLOCв параметрические модели оценки трудозатрат, которые требуютSLOC в качестве входных данных (например, модели COCOMO,Релея и т.п.). Метод обратного запуска в этом случае как раз являетсятем средством, которое делает возможной такую замену.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 7