bigpo.ru
добавить свой файл
1 2

Методи та засоби програмної інженерії

УДК 004.413:338.5

МОДЕЛИ, МЕТОДЫ И СРЕДСТВА ОЦЕНКИ СТОИМОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Н.А. Сидоров, Д.В. Баценко, Ю.Н. Василенко, Ю.В. Щебетин

Национальный авиационный университет

03058, Киев, проспект космонавта Комарова, 1,

тел.: 406 7396; e-mail: sna@nau.edu.ua

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

This article reviews models, methods and tools for software cost estimation also there are given results of the experiment in cost estimation, the peculiarities of calibration are studied and the conclusions are drawn on the expediency of application of reviewed models, methods and tools.


Развитие моделей, методов и средств оценки стоимости программного обеспечения (ПО) достигло уровня практического применения. Однако из-за отсутствия информации, средств и специалистов они не используются при разработке ПО в Украине.

В работе приводятся результаты аналитического обзора литературы с учетом опыта авторов по указанной теме. Работа состоит из четырёх частей. В первой рассматриваются единицы размера ПО, которые используются в моделях, методах и средствах оценки стоимости ПО, во второй – модели и методы оценки, в третьей – средства оценки, в четвёртой – на примере показывается использование средств для оценки ПО.

1. Единицы размера ПО

В оценке стоимости ПО используют две единицы размера: строка кода Line of Code (LOC) [1] и функциональная точка Function Point (FP) [2].

Line of Code – это строка исходного кода ПО (исключаются пустые строки, комментарии и специфические операторы). К преимуществам использования LOC, как единицы размера ПО, относят простоту, а недостатками являются следующие: размер проекта в LOC может быть определён только после его завершения; LOC зависит от языка программирования; LOC не учитывает качество кода. Производительность (S) программиста с использованием LOC подсчитывается по следующей формуле , где n – количество строк кода, написанных программистом (LOC); m – время работы программиста (в человеко-часах). Видно, что чем больше строк кода, тем выше производительность разработчика. Однако, очевидно можно реализовать одну и ту же функцию, написав меньшее количество строк кода. Единица размера LOC не отражает функциональные свойства кода. Поэтому, если разработчик стремится оптимизировать процесс разработки, с целью уменьшения трудозатрат на реализацию проекта, то при использовании LOC как основной единицы размера проекта под уменьшением трудозатрат подразумевается уменьшение количества строк кода в программе, при этом не оценивается его функциональность.

Существуют также проблемы с применением LOC и в проектах, использующих несколько языков программирования. Например, 10.000 LOC языка C++ очевидно нельзя сравнивать с 10.000 LOC языка COBOL, а в случае применения автоматизированных или основанных на шаблонах, визуальных средств разработки подсчёт LOC тем менее эффективен, чем больше кода создаётся автоматически.

Function Point была введена как альтернатива LOC [2]. Методика анализа функциональных точек была разработана А. Дж. Альбректом (A. J. Albrecht) для компании IBM в середине 70-х годов прошлого столетия, когда возникла потребность в подходе к оценке затрат труда на разработку ПО, который бы не зависел от языка и среды разработки. С 1986 года продвижение методики и разработку соответствующего стандарта продолжает International Function Point User Group (IFPUG). Эта организация разработала руководство по практике применения расчёта функциональных точек Function Point Counting Practices Manual (FPCPM) и последняя версия этого документа (4.1) официально признана ISO как стандарт оценки размера ПО [3].

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

В соответствии с принятым стандартом [3] используются пять классов компонентов, на которых основывается анализ:

- внутренний логический файл Internal Logical File (ILF) – группа логически связанных данных, находящихся внутри границ приложения и поддерживаемых вводом извне;

- внешний интерфейсный файл External Interface File (EIF) – группа логически связанных данных, находящихся вне границ приложения и являющихся внутренним логическим файлом для другого приложения;

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

- внешний вывод External Output (EO) – транзакция, при выполнении которой данные пересекают границу приложения изнутри. Из ILF и EIF создаются файлы вывода или сообщения и отправляются другому приложению. Вывод также содержит производные данные, получаемые из ILF;

- внешний запрос External Inquiry (EQ) – транзакция, при выполнении которой происходит одновременный ввод и вывод. В результате информация возвращается из одного или более ILF и EIF. Вывод не содержит производных данных, а ILF не обновляются.

Классы компонентов оцениваются по сложности и относятся к категории высокого, среднего или низкого уровней сложности. Для транзакций (EI, EO, EQ) уровень определяется по количеству файлов, на которые ссылается транзакция File Types Referenced (FTR) и количеству типов элементов данных Data Element Types (DET). Для ILF и EIF имеют значение типы элементов записей Record Element Types (RET) и DET. Типы элементов записей это подгруппа элементов данных в ILF или EIF. Типы элементов данных – это уникальное не рекурсивное поле подмножества ILF или EIF. Уровни сложности и соответствующие им значения FTR и DET описаны в FPCPM [3].

Например, для EI с количеством FTR от 3 и более и DET от 5 до 15 уровень сложности определяется как высокий. Далее компоненты распределяются по «весовым категориям» в зависимости от уровня их сложности. Например, ILF средней сложности имеет значение 10, а EQ высокой сложности значение 6. После этого, производится подсчёт нескорректированных функциональных точек Unadjusted Function Point (UFP) по соответствующей формуле [1]:

,

где Nij и Wij соответственно количество экземпляров класса i сложности j и его весовое значение. Результат расчёта может быть скорректирован с помощью фактора регулирования стоимости Value Adjustment Factor (VAF)[4]. При расчёте VAF учитываются четырнадцать общих характеристиках системы General System Characteristic (GSC), которые оценивают общую функциональность разрабатываемого приложения. Эти характеристики отражают возможность повторного использования кода, производительность, возможность распределённой обработки, и другие свойства приложения [2]. Каждой GSC присваивается значение от 0 до 5. После того как учтены все четырнадцать общих характеристик системы рассчитывается фактор регулирования стоимости по следующей формуле [4]:

,

где Ci – степень влияния i-ой GSC. Последним, подсчитывается количество полных функциональных точек [4]: FP = UAF * VAF.

Существуют приложения, в оценке которых использование стандартных функциональных точек не эффективно. Эти приложения следующие [5]: управление процессом в реальном времени, математические вычисления, симуляция, системные приложения, инженерные приложения, встроенные системы. Перечисленные приложения отличаются высокой интенсивностью вычислений, часто основанных на алгоритмах повышенной сложности. Для решения задач расчёта размера указанных приложений в 1986 году организацией Software Productivity Research (SPR) была разработана методика анализа характеристических точек ПО (feature points) [5]. Сущность ее состоит в том, что оценивается количество алгоритмов в программе и незначительно модифицируется степень значимости (weighting values) для расчёта FP. Эта методика считается экспериментальной [5].

2. Методы и модели оценки стоимости ПО

Методы и модели оценки стоимости ПО можно разделить на две группы: неалгоритмические методы и алгоритмические модели. К неалгоритмическим методам относятся Price-to-win, оценка по Паркинсону, экспертная оценка, оценка по аналогии. К алгоритмическим моделям относятся SLIM и COCOMO.

Неалгоритмические методы. Сущность неалгоритмических методов состоит в том, что при оценке стоимости ПО используются определенные схемы и принципы, а не математические формулы. К этим методам относятся следующие:

Price-to-win [1]. Метод основывается на принципе «клиент всегда прав». Суть метода состоит в том, что независимо от предполагаемых реальных затрат на разработку проекта, оценка стоимости ПО корректируется в соответствии с пожеланиями заказчика. Price-to-win фактически является политикой проведения переговоров с клиентом, поэтому часто применяется компаниями, не имеющими средств для качественной оценки проектов. Применение метода может иметь для разработчика следующие негативные последствия: нехватка ресурсов для выполнения проекта, невыполнение сроков сдачи проекта и как результат – потеря контракта или банкротство [1].

Оценка по Паркинсону [1]. Метод основывается на принципе: «Объем работы возрастает в той мере, в какой это необходимо, чтобы занять время, выделенное на ее выполнение» [6]. Принцип, позднее названный «законом» [1], был впервые высказан С.Н. Паркинсоном и описывал природу взаимодействия бюрократической системы в административных институтах, отображая процесс неэффективного использования ресурсов [6]. В применении к разработке программных проектов, закон Паркинсона используется в виде следующей схемы: чтобы повысить производительность труда разработчика, необходимо уменьшить время, отведённое на разработку [1].

Экспертная оценка [7]. Метод основывается на принципе экспертной оценки и применяется в проектах использующих новые технологии, новые процессы или решающих инновационные задачи. К процессу оценки привлекаются инженеры-разработчики, которые сами оценивают курируемую ими часть проекта. После этого созывается собрание, на котором результаты отдельных оценок интегрируются в единую, целостную систему. Предположения, на которых основывалась оценка отдельных экспертов, заносятся в протокол и открыто обсуждаются. При опросе экспертов используются Дельфийская или расширенная Дельфийская методика, ориентированная на приведение экспертов к консенсусу [1]. В результате достигается баланс оценки при интеграции отдельных компонентов в общую систему. Далее следует очередная стадия покомпонентной оценки, и по мере увеличения количества итераций точность оценки увеличивается.

Оценка по аналогии [8]. Являясь разновидностью экспертной оценки, часто выделяется в отдельный метод. Метод основывается на принципе аналогии [8]. Оценка по аналогии, как и алгоритмические модели, использует эмпирические данные о характеристиках завершённых проектов. Ключевое различие состоит в том, что алгоритмические модели используют эти данные косвенным образом, например, для калибровки параметров моделей, а метод оценки по аналогии с помощью эмпирических данных позволяет отобрать схожие проекты. Схема оценки основанная на указанном принципе состоит из нескольких этапов. На первом этапе осуществляется сбор данных по разрабатываемому проекту. В рамках ЖЦ ПО оптимальными формами для этого являются анализ требований и проектирование. На основе экспертной оценки производится отбор характеристик, по которым будут сравниваться проекты. Выбор характеристик зависит от типа приложения, среды разработки и набора известных параметров приложения. Следующий этап включает в себя поиск и анализ проектов «аналогичных» по выбранным характеристикам разрабатываемому. Результатом данного этапа является, как правило, несколько проектов имеющих наименьшие различия в численных значениях характеристик оценки. Для отбора проектов, наиболее близких разрабатываемому, может использоваться метод измерения Евклидова расстояния в n- мерном пространстве. Каждой характеристике присваивается значение веса (множитель), определяющее значимость характеристики для проекта. В упрощённом варианте вес равен единице, т. е. все характеристики проекта считаются равнозначными по важности. Далее проекты и их соответствующие характеристики отображаются в n – мерном пространстве как точки (n равно количеству переменных, для каждой переменной используется своё измерение), после чего вычисляется Евклидово расстояние между соответствующими точками [8]:

,

где a и b – точки в пространстве, a1…ai и b1…bi – координаты точек в соответствующих плоскостях.

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

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

Модель Путнэма (SLIM). Наиболее распространенная модель аналитической группы. Создания для проектов, объемом больше 70 000 строк кода, модель основывается на утверждении, что затраты на разработку ПО распределяются согласно кривым Нордена-Рэйли, которые являются графиками функции, представляющей распределение рабочей силы по времени [9 ]. Общий вид подобной функции – , где – полученное значение; – время; и параметры, определяющие функцию. Для большого значения , кривая стремится к параметру , который называется cost scale factor parameter. Функция возрастает наиболее быстро при [9]. Основной причиной такого поведения модели являлось то, что изначально исследования Нордена базировались не на теоретической основе, а на наблюдениях за проектами, причем, в основном за проектами не связанными с ПО (машиностроение, строительство). Поэтому нет научного подтверждения тому, что программные проекты требуют такого же распределения рабочей силы, наоборот, зачастую количество человеко-часов, требуемых проектом, может резко изменится, сделав оценку непригодной к использованию. После ряда эмпирических наблюдений, Путнэм выразил рабочее уравнение модели в форме: , где Size – размер кода в LOC, С – технологический фактор; E – общая стоимость проекта в человеко-годах; t – ожидаемое время реализации проекта. Технологический фактор включает в себя характеристику проекта в следующих аспектах: методы управления и понимание процесса, качество используемых методов инженерии ПО, уровень используемых языков программирования, уровень развития среды, навыки и опыт команды разработчиков, сложность приложения.

Уравнение для E, выглядит как , где коэффициент, выражающий количество необходимой работы (значения от 8 до 12, означает ПО полностью новое, с большим количеством связей; значения до 27 – требуется переработка существующего кода). Связывая два уравнения, получаем уравнение и , которые показывают, что затраты пропорциональны размеру кода в степени . Это достаточно близко к модели Б. Боэма, где данный фактор лежит в пределах от 1.05 до 1.20 [10].

В 1991 году Путнэмом была представлена альтернативная реализация модели, выполненная по заказу Quantitative Software Management (QSM) Inc. и примененная в комплексе SLIM Estimate для оценки стоимости ПО [14]. Полное уравнение в этой реализации выглядит как: . Если на общее время реализации проекта ограничения не накладываются, то возможно использование упрощенного уравнения . Здесь B – фактор специальных навыков; P – фактор продуктивности; Schedule – время разработки по графику (в месяцах). Уравнение может быть использовано, если предполагаемые затраты больше 20 человеко-месяцев.

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

Модель COCOMO. Семейство моделей COCOMO было создано в 1981 году на основе базы данных о проектах консалтинговой фирмы TRW [10].

COCOMO представляет собой три модели, ориентированные на использование в трех фазах жизненного цикла ПО: базовая (Basic) применяется на этапе выработки спецификаций; требований расширенная (Intermediate) – после определения требований к ПО; Advanced – углубленная используется после окончания проектирования ПО. В общем виде, уравнение моделей имеет вид , где Е – затраты труда на проект (в человеко-месяцах); S – размер кода (в KLOC); EAF – фактор уточнения затрат (effort adjustment factor). Параметры a и b зависят от вида разрабатываемого приложения, который может быть следующим:

- относительно простой проект, работа над которым ведется однородной командой разработчиков, требования носят рекомендательный характер, отсутствует заранее выработанная исчерпывающая спецификация (например, несложное прикладное ПО);

- проект средней сложности, работа над которым ведется смешанной командой разработчиков, требования к проекту определяются спецификацией, однако могут изменяться в процессе разработки проекта (например, ПО системы управления банковским терминалом);

- проект, который должен быть реализован в жестких рамках заданных требований (например, ПО системы управления полетами).

В базовой модели фактор EAF принимается равным единице. Для определения значения этого фактора в расширенной модели используется таблица, содержащая ряд параметров определяющих стоимость проекта. При использовании углубленной модели, вначале проводится оценка с использованием расширенной модели на уровне компонента, после чего каждый параметр стоимости оценивается для всех фаз ЖЦ ПО [10].

COCOMO ІІ также является семейством моделей и представляет собой развитие базовой (Basic) модели COCOMO. COCOMO ІІ включает три модели – создания приложений Application Composition Model (ACM), раннего этапа разработки Early Design Model (EDM) и пост-архитектурная Post Architecture Model (PAM).

ACM используется на раннем этапе реализации проекта, для того, чтобы оценить следующее: интерфейс пользователя, взаимодействие с системой, производительность. За начальный размер принимается количество экранов, отчетов и 3GL – компонентов. Если предположить, что в проекте будет использовано r % объектов из ранее созданных проектов, количество новых объектных точек в проекте Object Points (OP) можно рассчитать, как

OP = (object points)x(100 – r)/100.

Тогда затраты можно вычислить по формуле:

,

где PROD – табличное значение [10].

EDM – это высокоуровневая модель, которой требуется сравнительно небольшое количество исходных параметров. Она предназначена для оценки целесообразности использования тех или иных аппаратных и программных средств в процессе разработки проекта. Для определения размера используется неприведенная функциональная точка (Unadjusted Function Point). Для ее преобразования в LOC используются данные из таблицы [10]. Уравнение модели раннего этапа разработки имеет вид [10], где a – константа 2.45. EAF определятся так же, как и в оригинальной модели СОСОМО. Параметры для EDM получаются комбинированием параметров для пост-архитектурной модели.

PAM – наиболее детализированная модель, которая используется, когда проект полностью готов к разработке. Для оценки стоимости ПО с помощью PAM необходим пакет описания жизненного цикла проекта [20], который содержит подробную информацию о факторах стоимости и позволяет провести более точную оценку. PAM используется на этапе фактической разработки и поддержки проекта. Для оценки размеров могут использоваться как строки кода, так и функциональные точки с модификаторами, учитывающими повторное использование кода. Модель использует 17 факторов стоимости и 5 факторов, определяющих масштаб проекта (в модели СОСОМО масштаб определялся параметрами вида приложения). Уравнение PAM имеет вид ,где a принято за 2.55, а , где параметры, отражающие свойства проекта, например, схожесть с ранее выполненными проектами, риск выбора архитектуры для реализации, понимание процесса разработки, сработанность команды разработчиков. Значения параметров являются табличными [11].


следующая страница >>