Оценка уровня сложности компоненты EI

Использование компонент

Компонент	RET	FTR	DET
Внешние входящие потоки (EI)		+	+
Внешние исходящие потоки (EO)		+	+
Внешние запросы (EQ)		+	+
Внешние файлы интерфейса (EIF)	+		+
Внутренние логические файлы (ILF)	+		+

Таблица 7.2

Количество FTR	Количество DET
1-4	5-15	>15
<2	Низкая (3)	Низкая (3)	Средняя (4)
	Низкая (3)	Средняя (4)	Высокая (6)
>2	Средняя (4)	Высокая (6)	Высокая (6)

Далее компоненты распределяются по «весовым категориям» в зависимости от уровня их сложности.

Например, ILF средней сложности имеет значение 10, а EQ высокой сложности значение 6.

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

UAF = EI + EO + EQ + ILF + EIF,

где EI, EO, EQ, ILF, EIF – число соответствующих функциональных точек.

Если же уровень сложности учитывается, то подсчёт нескорректированных функциональных точек Unadjusted Function Point (UFP) производится по следующей формуле [ Boehm B.W. Software engineering economics. – Prentice-Hall. – 1981. – 320 p.]:

,

где N_ij и W_ij соответственно количество экземпляров класса i сложности j и его весовое значение.

Результат расчёта может быть скорректирован с помощью фактора регулирования стоимости Value Adjustment Factor (VAF). При расчёте VAF учитываются четырнадцать общих характеристиках системы General System Characteristic (GSC), которые оценивают общую функциональность разрабатываемого приложения. Характеристики GSC отражают:

1. Связи данных. Как много связей используются для передачи данных внутри системы.

2. Распределенная обработка данных. Как обрабатываются распределенные данные.

3. Какие требования по производительности.

4. Какие требования по аппаратной части.

5. Как часто выполняются транзакции (ежедневно, еженедельно …)

6. Какой процент информации вводится онлайн.

7. Эффективность для конечного пользователя.

8. Как много ILF обновляются онлайн.

9. Используются ли сложная логическая или математическая обработка.

10. Была ли спроектирована программа для одного или многих пользователей.

11. Насколько сложна инсталляция.

12. Насколько эффективны или автоматизированы старт, резервное копирование и восстановление.

13. Было ли приложение спроектировано, разработано для множества сотрудников множества организаций.

14. Было ли приложение спроектировано для упрощения дальнейших изменений в нем.

Каждой GSC присваивается значение от 0 до 5. После того как учтены все четырнадцать общих характеристик системы рассчитывается фактор регулирования стоимости (коэффициента подстройки) по следующей формуле [4]:

,

где C_i – степень влияния i-ой GSC.

Последним, подсчитывается количество полных функциональных точек (если уровень сложности не учтен):

FP = UAF * VAF.

Если производится предварительная обработка данных для различных компонент системы, то количество функциональных точек разработки будет определяться:

DFP = (UFP + CFP) * VAF

где UFP - количество функциональных точек без подстройки, CFP - количество функциональных точек добавленных для обработки прочих функциональных точек, VAF – коэффициент подстройки.

Количество функциональных точек с учетом дополнительных требований будет определяться следующим образом:

EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB)

где ЕFP - количество дополнительных функциональных точек, ADD - количество функциональных точек без подстройки, которые были добавлены по дополнительным требованиям, CHGA - количество функциональных точек без подстройки, которые были изменены по дополнительным требованиям, CFP - количество функциональных точек без подстройки, которые были добавлены после преобразований, VAFA - коэффициент подстройки после дополнительных требований, VAFB - коэффициент подстройки до дополнительных требований, DEL - количество функциональных точек без подстройки, которые были удалены после преобразований. Обычно CFP = 0.

Существуют приложения, в оценке которых использование стандартных функциональных точек не эффективно. Эти приложения следующие [ Fenton N.E., Pfleeger S.L. Software Metrics: A Rigorous and Practical Approach. – PWS Publishing Company. – 1997. – 455 p.]: управление процессом в реальном времени, математические вычисления, симуляция, системные приложения, инженерные приложения, встроенные системы. Перечисленные приложения отличаются высокой интенсивностью вычислений, часто основанных на алгоритмах повышенной сложности. Для решения задач расчёта размера указанных приложений в 1986 году организацией Software Productivity Research (SPR) была разработана методика анализа характеристических точек ПО (feature points). Сущность ее состоит в том, что оценивается количество алгоритмов в программе и незначительно модифицируется степень значимости (weighting values) для расчёта FP. Эта методика считается экспериментальной.

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

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

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

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

Оценка по Паркинсону. Метод основывается на принципе: «Объем работы возрастает в той мере, в какой это необходимо, чтобы занять время, выделенное на ее выполнение» [ Parkinson S.N. Parkinson's Law and Other Studies in Administration. – Houghton-Miffin. – 1957.– 148 p.]. Принцип, позднее названный «законом» [1], был впервые высказан С.Н. Паркинсоном и описывал природу взаимодействия бюрократической системы в административных институтах, отображая процесс неэффективного использования ресурсов. В применении к разработке программных проектов, закон Паркинсона используется в виде следующей схемы: чтобы повысить производительность труда разработчика, необходимо уменьшить время, отведённое на разработку.

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

Аналого-сопоставительный метод. Являясь разновидностью экспертной оценки, часто выделяется в отдельный метод. Метод основывается на принципе аналогии. Оценка по аналогии, как и алгоритмические модели, использует эмпирические данные о характеристиках завершённых проектов. Ключевое различие состоит в том, что алгоритмические модели используют эти данные косвенным образом, например, для калибровки параметров моделей, а метод оценки по аналогии с помощью эмпирических данных позволяет отобрать схожие проекты.

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

Модель Путнэма (SLIM). Наиболее распространенная модель аналитической группы. Создания для проектов, объемом больше 70 000 строк кода, модель основывается на утверждении, что затраты на разработку ПО распределяются согласно кривым Нордена-Рэйли, которые являются графиками функции, представляющей распределение рабочей силы по времени [ David L. Norden-Raleigh Analysis: A Useful Tool for EVM in Development projects. – The Measurable News. – 2002. – 24 p. ].

Общий вид подобной функции:

,

где – полученное значение; – время; и – параметры, определяющие функцию.

Для большого значения , кривая стремится к параметру , который называется cost scale factor parameter. Функция возрастает наиболее быстро при . Основной причиной такого поведения модели являлось то, что изначально исследования Нордена базировались не на теоретической основе, а на наблюдениях за проектами, причем, в основном за проектами не связанными с ПО (машиностроение, строительство). Поэтому нет научного подтверждения тому, что программные проекты требуют такого же распределения рабочей силы, наоборот, зачастую количество человеко-часов, требуемых проектом, может резко изменится, сделав оценку непригодной к использованию.

После ряда эмпирических наблюдений, Путнэм выразил рабочее уравнение модели в форме:

,

где Size – размер кода в LOC, С – технологический фактор; E – общая стоимость проекта в человеко-годах; t – ожидаемое время реализации проекта.

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

Уравнение для E, выглядит как

,

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

Модель COCOMO. Семейство моделей COCOMO было создано в 1981 году на основе базы данных о проектах консалтинговой фирмы TRW [ Johnson Kim. Software cost estimation – Metrics and models. – University of Calgary. – 2001. – 115 p.].

COCOMO представляет собой три модели, ориентированные на использование в трех фазах жизненного цикла ПО:

- базовая (Basic) применяется на этапе выработки спецификаций, требований;

- расширенная (Intermediate) – после определения требований к ПО;

- Advanced – углубленная используется после окончания проектирования ПО.

В общем виде, уравнение моделей имеет вид:

,

где Е – затраты труда на проект (в человеко-месяцах); S – размер кода (в KLOC); EAF – фактор уточнения затрат (effort adjustment factor).

Параметры a и b зависят от вида разрабатываемого приложения, который может быть следующим:

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

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

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

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

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 – табличное значение [ Johnson Kim. Software cost estimation – Metrics and models. – University of Calgary. – 2001. – 115 p.].

EDM – это высокоуровневая модель, которой требуется сравнительно небольшое количество исходных параметров. Она предназначена для оценки целесообразности использования тех или иных аппаратных и программных средств в процессе разработки проекта. Для определения размера используется неприведенная функциональная точка (Unadjusted Function Point). Для ее преобразования в LOC используются данные из таблицы [ Johnson Kim. Software cost estimation – Metrics and models. – University of Calgary. – 2001. – 115 p.].

Уравнение модели раннего этапа разработки имеет вид

,

где a – константа 2.45. EAF определятся так же, как и в оригинальной модели СОСОМО. Параметры для EDM получаются комбинированием параметров для пост-архитектурной модели.

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

Уравнение PAM имеет вид:

,

где a принято за 2.55, а , где – параметры, отражающие свойства проекта, например, схожесть с ранее выполненными проектами, риск выбора архитектуры для реализации, понимание процесса разработки, сработанность команды разработчиков. Значения параметров являются табличными [ McGibbon Th. Modern Empirical and Schedule Estimation Tools. – DACS Report. – 1997. – 72 p.].

3. Средства оценки стоимости ПО

Основными критериями при выборе ПО для оценки стоимости ПО являются:

─ стоимость ПО;

─ возможность оценки на основе аналого-сопоставительных методов;

─ параметры обработки (строка кода или функциональные точки);

─ поддерживаемые модели расчета трудозатрат;

─ поддерживаемые жизненные циклы проектов;

─ результаты вычислений (общие трудозатраты, трудозатраты на этапы/работы поекта; длительность проекта, стоимость и т.д.).

Большинство из существующих инструментариев представляют собой «черный ящик», процесс работы с которым может быть разделен на следующие составляющие:

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

2. Определение общих трудозатрат – количество строк кода пересчитывается в общие проектные трудозатраты, вычисляется время, требуемое на разработку продукта. Для этого используются уравнения моделей COCOMO II, SLIM, SEER-SEM и гибридные. Для всех уравнений задаются поправочные (калибровочные) коэффициенты.

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

4. Расчет стоимости проекта – определяется исходя из стоимости человека-часа для основных разработчиков.

В большинстве инструментариев не используется никаких нестандартных подходов, и для получения оценки везде используется концепция «Размер продукта – трудозатраты»

Широко известны средства оценки ПО, основанные на моделях SLIM и СОСОМО.

SLIM Estimate компании QSM является наиболее часто используемым программным средством для оценки стоимости ПО, в котором реализована модель Путнэма.

Средство входит в состав пакета прикладного ПО и предназначено для работы над проектом ПО на начальных стадиях жизненного цикла. В пакет, кроме средства оценки, также входят средства сбора и хранения данных о реализованных проектах (SLIM DataManager), анализа этих данных (SLIM Metrics), общего контроля над процессом разработки (SLIM Control).

Данный пакет используется для оценки стоимости разрабатываемого ПО в следующих организациях: Alcatel Telecom, AT&T, Athens Group, Australian Department of Defence, BAE, Bell South Communications, Hewlett-Packard, IBM Rational Software, Lockheed Martin, Motorola Communications, Nokia, US Air Force Cost Analysis Agency.

SLIM Estimate позволяет выполнять оценку стоимости разработки программного обеспечения различными способами: мастер быстрой оценки, оценка размера, оценка PI, оценка непредвиденных обстоятельств, оценка основанная на исторических факторах.

Первым и наиболее часто используемым является использование мастера быстрой оценки (Quick Estimate Wizard). При этом используются следующие параметры:

─ тип разрабатываемого приложения;

─ максимально возможное время работы над проектом;

─ бюджет проекта;

─ ориентировочное общее количество строк;

─ индекс продуктивности команды разработчиков;

─ процент повторно используемого кода.

Формируются таблицы и строятся диаграммы, отображающие общее количество задействованной рабочей силы и ее распределение по графику работ. Шаблон рабочей книги (workbook) проекта SLIM Estimate поддерживает около 50 различных форматов представления проведенной оценки ПО. Созданные рабочие книги могут служить шаблонами для оценки стоимости последующих проектов. По умолчанию, SLIM Estimate оценивает трудозатраты с 50 % вероятностью успешной реализации проекта, для изменения этого значения следует откорректировать значение вероятности с помощью мастера настройки вероятности. Результатом оценки размера является общее количество строк кода, которое может создать команда разработчиков в данных условиях. Результат оценки индекса продуктивности представляет собой PI, необходимый для реализации проекта в заданных условиях. Оценка непредвиденных обстоятельств используется для генерации плана реализации с заданной вероятностью успешного завершения проекта. Эти способы могут использоваться как независимо, так и для уточнения результатов, полученных в результате использования мастера быстрой оценки.

С помощью функции Edit Historical Projects данные оценки могут быть экспортированы в SLIM DataManager. Для сравнительного анализа результатов оценки возможен импорт данных из программы SLIM Metrics, либо другой рабочей книги SLIM Estimate.

Для оценки размера проекта вместе с SLIM Estimate поставляется реализованная в Microsoft Excel таблица, значения из которой могут быть импортированы в рабочую книгу проекта. В ранних версиях SLIM Estimate основной единицей измерения было логическое выражение в исходном коде Logical Source Statement (LSS). Начиная с версии 5.0, в SLIM Estimate используется строки кода, функциональные и объектные точки (напрямую, без преобразования в LSS). Наиболее широко используемым способом калибровки [20] модели в SLIM Estimate является использование исторических параметров настройки (Historical Tuning Factors). Программный комплекс SLIM Estimate может экспортировать данные отчетов в наиболее популярные форматы файлов, такие, как Microsoft Word, Microsoft Excel, Enhanced Metafile, Microsoft Project, HTML.

В комплект поставки SLIM Estimate входит база реализованных проектров, которую можно использовать для калибровки используемой модели – установки значений параметров стоимости для описания характеристик проекта. Наиболее широко используемым способом калибровки модели в SLIM Estimate является использование исторических параметров настройки (Historical Tuning Factors). В случае его использования значения параметров стоимости для проекта вычисляются программным комплексом на основе выбранных проектов из базы реализованных проектов.

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

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

Costar (SoftStar Systems), Cost Xpert (Marotz), SoftwareCost Calculator (SoftwareCost.com). Средства, основанные на модели СОСОМО [14]. Допускается использование всех реализаций модели СОСОМО, моделей жизненного цикла ПО Waterfall и MBASE/RUP, поддерживается работа с проектом, составленным из компонентов, для каждого из которых можно выполнить раздельную оценку.

Costar позволяет проводить оценку в двух режимах:

· пошаговом, с помощью мастера оценки стоимости;

· интерактивном, обеспечивающим непосредственное указание значений параметров, влияющих на стоимость проекта.

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

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

Для анализа результатов оценки Costar создает различные формы отчетов, графиков и диаграмм. Отчеты, представленные в форме таблиц, могут быть сохранены в формате Microsoft Excel, графики и диаграммы – в формате растрового изображения BMP.

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

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

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

Дата добавления: 2014-01-06