it лаб работы. IT_лаб работы_ЗАОЧНОЕ. Лабораторная работа 1 2 Оценка размера и сложности программных средств методом функциональных точек с использованием пакета cosmos 2
 Скачать 2.46 Mb.
|
2.2. Внешние и внутренние метрики размера ПС. Сравнение функциональных точек и количества строк исходного кодаИзвестно, что в большинстве случаев именно размер ПС определяет его сложность и наиболее существенно влияет на график работ по его реализации. Поэтому измерение размера ПС является ключевым фактором для точной оценки трудоемкости его разработки и планирования работ по его реализации. Основные метрики размера ПС – это количество строк исходного кода (SLOC) и количество функциональных точек (FPC). FPC является внешней метрикой, так как при её расчёте не берется во внимание технология разработки и кодирования ПС, не учитывается используемый язык программирования. Достаточно наличия подробного внешнего описания ПС, т.е. технического задания на его разработку, в котором перечислены и раскрыты все реализуемые им функции. SLOC же является внутренней метрикой и по своей природе требует знания внутреннего строения ПС, от которого во многом зависит. Очень сложно точно оценить SLOC на начальных этапах проектирования ПС, исходя из одних требований к системе и не принимая во внимание детали реализации. Только при наличии готового кода ПС это можно сделать с большой точностью. Однако и в этом случае данная метрика будет характеризоваться высокой степенью субъективизма, так как очевидно, что одну и ту же задачу программисты разной квалификации и разной культуры программирования могут решить так, что количество строк исходного кода в этих решениях будет отличаться в разы. Это ограничивает применение SLOC при планировании и распределении бюджета, где необходимо заранее располагать некоторыми объективными данными о трудоемкости программного проекта, до начала работ по его реализации. С FPC дело обстоит иначе, этот метод напрямую связан с требованиями пользователя к системе, которые уже выражены в виде логических групп данных и автоматизированных бизнес-процессов. Это означает, что FPC можно посчитать достаточно точно даже на ранних этапах цикла разработки ПС. Объективность же оценки FPC зависит только от правильности использования метода функциональных точек и от качества подготовленного внешнего описания ПС. Всё это делает FPC очень удобной метрикой для планирования графика работ и распределения бюджета программных проектов. В отличие от SLOC, существует проверенная годами стандартная методология с очень детальным руководством для подсчёта FPC, IFPUG Counting Practices Manual (Руководство по методам расчётов организации IFPUG). В этом руководстве есть множество примеров, демонстрирующих расчёты различных показателей для разных видов ПС (базы данных; системы, базирующиеся на структурном анализе и проектировании, на объектно-ориентированном анализе и проектировании, системы с графическим интерфейсом пользователя, системы реального времени и т.д.). Приведённые примеры демонстрируют высокую корреляцию между FPC и реальным объемом работ, требующихся для завершения проекта. Именно поэтому правомерно подставлять FPC вместо SLOC в параметрические модели оценки трудозатрат, которые требуют SLOC в качестве входных данных (например, модели COCOMO, Релея и т.п.). Метод обратного запуска в этом случае как раз является тем средством, которое делает возможной такую замену. Так как FPC не привязано к конкретной реализации ПС, то его можно использовать для сравнения различных вариантов реализаций, не прибегая к нормализации. 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. Примеры элементов данных для транзакций модели функциональных точек
Различные группы элементов данных (DET) также позволяют отличать внешние вводы, выводы или запросы друг от друга. Таким образом, можно считать, что уникальная группа DET создает элементарный процесс, называемый EI, EO или EQ. В современных ПС наибольшее распространение получил графический пользовательский интерфейс (GUI), поэтому приведем более подробно правила подсчета DET при использовании такого типа интерфейса в табл. 4.8. Таблица 4.8. Правила подсчета элементов данных (DET) при использовании GUI
Рекурсивные поля ввода или вывода, т.е. поля, используемые одним и тем же способом многократно, считаются как один DET. По этой причине одним элементом данных считается звуковой сигнал вне зависимости от длительности воспроизведения или количества воспроизводимых нот. Каждый управляющий ключ (командная кнопка, такая как OK, Next и т.п.) считаются как один DET, если они инициируют какую-либо транзакцию. С другой стороны, если группа управляющих ключей выполняет одну и ту же функцию (транзакцию), то такую группу также учитывают как один DET. 4. Определение значения нормирующего фактора (VAF). Определение значения нормирующего фактора (VAF) производится с использованием табл. 4.5. и формулы 4.2. экспертным способом. 5. Подсчет нормированного количества функциональных точек. Подсчет нормированного количества функциональных точек производится с использованием формул 4.1. и 4.3. Следует заметить, что во многих организациях процедуру нормирования количества функциональных точек считают опциональной (необязательной). | |||||||||||||||||||||||||||||||||||||