CC BY
125
все фирмы-покупатели промышленной продукции принимают решения рационально, на основе изучения ценности предложения; во-вторых, для покупателя промышленной продукции важна, главным образом, не цена приобретения, а затраты и выгоды на протяжении жизненного
цикла использования промышленной продукции.
Кроме того, знание подходов к расчету потребительской ценности позволит поставщикам промышленной продукции быстрее адаптироваться к маркетинговому ценообразованию.
СПИСОК ЛИТЕРАТУРЫ
1. Долан, Р. Дж. Эффективное ценообразование [Текст] : пер. с англ. / Р. Дж. Долан, Г. Саймон. - М.: Экзамен, 2005. - 416 с.
2. Липсиц, И.В. Ценообразование [Текст] : учебник / И.В. Липсиц. - М.: Экономиста, 2006. - 448 с.
1. Бест, Р. Маркетинг от потребителя [Текст] : пер. с англ. / Р. Бест. - М.: Манн, Иванов и Фербер, 2008. - 760 с.
2. Леман, Д.Р. Управление товаром [Текст] / Д.Р. Леман, Р.С. Винер. - 3-е изд. - М.: Изд. дом «Вильямс», 2004. - 624 с.
УДК 330.47
Х.Р. Алиев
Комбинированная модель оценки трудоемкости разработки
программного обеспечения
Экономические исследования в сфере разработки информационных систем в последнее время становятся весьма актуальными. Затруднения в развитии методов и процессов технико-экономического обоснования проектов программных средств обусловлены, в частности, их сложностью и, в ряде случаев, неопределенностью характеристик предполагаемого программного продукта, технологических этапов и процессов разработки, производства и применения программ.
При разработке программных изделий на различных этапах выполнения проекта его участники сталкиваются с задачами оценивания. Прежде всего, это задачи оценки трудозатрат и ресурсов, потребных для их успешной реализации: время и финансирование, выделенное на решаемую задачу, инструментальное обеспечение, обеспеченность разработчиками и т. п. Причем одним из определяющих факторов успешности выполняемого проекта является точность полученных оценок. Тематика оценки трудоемкости и стоимости разработки программного обеспечения (ПО) на всех стадиях жизненного цикла в полной мере в нашей стране еще не раскрыта. Также стоит остро вопрос средств оценивания. К сожалению, еще присутствует и такой
негативный фактор, как настороженное отношение к средствам оценки. К примеру, исследования Software Engineering Institute (SEI) [7] показывают, что около 80 % всех внедренных систем количественной оценки процесса разработки ПО оказываются практически невостребованными на протяжении первых двух лет.
Таким образом, можно отметить несомненность необходимости исследований в сфере разработки и оценки программного обеспечения и информационных систем на фоне быстрорастущего рынка IT и такого сервиса, как «IT-аутсорсинг».
Построение прототипа приложения в конструктивной модели
Первой фазой разработки проекта согласно положений COCOMO II (Constructive Cost Model)1 является этап построения прототипа приложения (Application Composition) [3]. Для оценки трудоемкости разработки в рамках этой
1 COCOMO - наиболее известная модель оценки трудозатрат на разработку ПО, конструктивная модель стоимости, разработанная в конце 70-х гг. Барри Боэмом (Barry Boehm). Данная модель усовершенствована в 1999 г., - COCOMO II.
фазы используется понятие объектной точки (object point). Этот метод наиболее сильно привязывается к RAD2 и CASE3 - средствам разработки, где объектной точке находится соответствующее понятие в инструменте разработки. Форма, компонент, объект, реализованный в модуле, отчет -примеры объектных точек.
Для таких объектов, как отчеты и экранные формы, существует метод определения степени сложности (табл. 1, 2).
Таблица 1
Экранные формы
Количество встроенных компонентов, модификаций формы Степень сложности
Количество источников данных
< 4 < 8 > 8
< 3 Простая Простая Средняя
3-7 Простая Средняя Сложная
> 8 Средняя Сложная Сложная
Таблица 2
Отчеты
Количество секций Степень сложности
Количество источников данных
< 4 < 8 > 8
< 3 Простая Простая Средняя
3-7 Простая Средняя Сложная
> 8 Средняя Сложная Сложная
Степень сложности определяет вес объекта при подсчете количества объектных точек (Object-Point count) (табл. 3).
ObjectPts = ^ ObjectWeighti [3],
где ObjectPts - количество объектных точек; ObjectWeightj - вес объекта, определяется по табл. 3.
2 RAD (от англ. rapid application development - быстрая разработка приложений) - концепция создания средств разработки программных продуктов.
3 CASE (от англ. Computer-Aided System Engineering) - программный комплекс, автоматизирующий технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем.
Таблица 3
Весовые коэффициенты сложности
Весовые коэффициенты сложности
Тип объекта Степень сложности
простая средняя сложная
Экранная форма 1 2 3
Отчет 2 5 8
Компонент, класс - - 10
Необходимо внести поправку на переиспользование объектов. В итоге новое количество объектных точек (NOP) подсчитывается по формуле
NOP = ObjectPts(100 - reuse) /100,
где reuse - процент переиспользования объектов.
Далее определяем уровень продуктивности (PROD), который имеет следующий вид (табл. 4):
Таблица 4
Оценка уровня продуктивности
Опыт разработчиков, их уровень Зрелость среды разработки и ее возможности PROD
Очень низкий Очень низкая 4
Низкий Низкая 7
Номинальный Номинальная 13
Высокий Высокая 25
Очень высокий Очень высокая 50
PROD = NOP /person-month,
где person-month - количество человеко-месяцев.
На следующем этапе вычисляем количество человеко-месяцев, необходимых для реализации программного продукта:
PM = NOP /PROD.
Так вычисляется оценка трудоемкости разработки на первом этапе - построении прототипа приложения согласно модели COCOMO II [3]. Однако существуют попытки расчетов для фазы построения прототипа на основе функциональных точек. Для этого объекты классифицируют более подробно, каждому виду объекта сопоставляется среднестатистическое ко-
личество функциональных точек, например классификация объектов по [1]:
1. Количество таблиц в базе данных.
2. Количество модулей входа.
3. Количество модулей логирования.
4. Количество модулей оповещения.
5. Количество модулей построения отчетов.
6. Количество ролей.
7. Количество простых интерфейсных форм (количество страниц).
8. Количество сложных интерфейсных форм (новые элементы управления).
9. Количество сторонних компонент (например, SDK компоненты).
10. Количество подсистем.
Эта номенклатура может расширяться. Классам объектов находятся соответствия по классической модели функциональных точек (внешние входные элементы, внешние выходные элементы, внешние запросы, внутренние логические файлы, внешние интерфейсные файлы). Оценка по функциональным точкам более рациональна на ранних этапах разработки проекта. По теории функциональная точка не зависит от языка им-плементации, поэтому их количество не зависит от выбора языка и среды разработки. Применяя метод аналогий и классификацию типовых объектов, из которых строится система, можно исследовать предыдущие проекты, которые реализованы в ИТ-компании, выявить объекты типовой сложности и подсчитать типовое количество функциональных точек для каждого класса. В дальнейшем это упростит переход от построения прототипа к следующим этапам оценки.
Рассмотрим ряд методик для оценки трудоемкости инициируемых программных проектов.
Метод функциональных точек и конструктивная модель оценки
Следующие две фазы разработки проекта учитываются в модели раннего дизайна (Early Design Model) и постархитектурной модели (Postarchitecture model) конструктивной методики стоимости (COCOMO II) [3].
Метод функциональных точек включает оценку степени влияния 14 характеристик системы на разработку проекта в соответствии с масштабом от 0,0 до 0,5 для каждой характеристики. Эти характеристики складываются и прибавляется 0,65, чтобы выровнять поправочный коэффициент от 0,65 до 1,35. Каждая из этих характеристик, таких как распределенные функции, требования к производительности и переиспользованию, например, имеют максимальный вклад 5 % в оценку трудоемкости [2]. Это противоречит модели COCOMO II. Поэтому в рамках COCOMO II нельзя использовать подстроечный коэффициент для расчета количества функциональных точек из теории функциональных точек.
Методика подсчета функциональных точек для COCOMO II следующая (см. табл. 5, 6).
UFP = ILF • WILF + EIF • WEIF + + EI • We, + EO • WEO + EQ • WEQ.
Существует среднестатистическое отношение между количеством UFP и SLOC (количеством строк кода) для каждого языка имплемента-ции. Если в проекте комбинируются несколько
Таблица 5
Уровни сложности
Для Internal Logical File и External Logical File Для External Inquiry и External Output Для External Input
Количество записей Количество элементов данных Количество типов файлов Количество элементов данных Количество типов файлов Количество элементов данных
1-19 20-50 51+ 1-5 6-19 20+ 1-4 5-15 16+
1 L L A 0 или 1 L L A 0 или 1 L L A
2-5 L A H 2-3 L A H 2-3 L A H
6+ A H H 4+ A H H 3+ A H H
Обозначения : Ь - низкий уровень сложности; А - средний уровень сложности; Н - высокий уровень сложности.
Таблица 6
Весовые коэффициенты сложности для подсчета количества UFP
Тип функции L A H
ILF 7 10 15
EIF 5 7 10
EI 3 4 6
EO 4 5 7
EQ 3 4 6
Обозначения : ILF - внутренний логический файл (Internal Logical File); EIF - внешний интерфейсный файл (External Interface File); EI - внешний входной элемент (External Input); EO - внешний выходной элемент (External Output); EQ - внешний запрос (External Inquery).
языков, то для преобразования UFP ^ SLOC можно воспользоваться формулой
SLOC = Y, UFPi • slocperfpi,
где UFP; - количество функциональных точек на i язык имплементации, slocperfpi - усредненное приблизительное количество строк кода для языка i на функциональную точку (примеры даны в табл. 7).
Таблица 7 Данные при средней сложности кода
Если известен процент использования функциональных точек на различных языках, то:
БЬОС = ИЕР^ • 81оерег1р1,
где 81осрег1р1 может определяться более точно на основе анализа предыдущих выполненных проектов.
Для этого делается выборка из N различных проектов по SLOC и UFP и их отношению, выявляется среднее (mean) по отношению SLOC/UFP, а также среднеквадратичное отклонение (stdev), анализ по персентилям, из которых можно получить среднее slocperfp, а также минимальное и максимальное slocperfp для определенной вероятности. Расчет может проводиться по трем параметрам - минимальному, среднему и максимальному, которые определяют границы результатов оценки.
Пример анализа по 20 проектам взят нами из репозиторных отчетов компании Exigen Sevices4 (см. табл. 8). В таблице приведены: количество UFP, AFP, SLOC и их отношения; типы приложений b = batch5, o = online6 [5].
На рис. 1 представлен график, где заметен существенный разброс отношения SLOC/UFP7 (Source Lines of Code / Unadjusted Functional Points) и SLOC/AFP8 (Source Lines of Code / Adjusted Functional Points). Можно сделать вывод, что на практике постановка среднестатистических значений может исказить результат вычисления трудоемкости по COCOMO II.
Далее представим таблицу с результатами анализа статистики по отношениям SLOC/UFP и SLOC/AFP для выборки по 20 проектам (табл. 9).
Статистика имеет большое СКО (среднеквадратичное отклонение) по SLOC/UFP выборки и отношение максимального и минимального отношений SLOC/UFP. Откуда следует, что оно неустойчиво и не может быть заменено постоянным коэффициентом. Вывод можно сделать следующий. В качестве коэффициента приведения UFP к SLOC необходимы экспертные оценки и метод аналогий на основе предыдущих проектов, которые близки к разрабатываемому проекту,
4 Exigen Sevices - крупное ИТ-предприятие (около 2000 программистов) по разработке заказного программного обеспечения («аутсорсинг»), CMM-5 Level, ISO-9001, РФ г.Санкт-Петербург. - URL: www.exigen-services.com
5 Batch-проекты - пакетные приложения.
6 Online-проекты - web-системы, интерактивные сервисы.
7 Отношение количества строк кода (SLOC) к неотрегулированным функциональным точкам (UFP), без учета коэффициента подстройки VAF [2].
8 Отношение количества строк кода (SLOC) к отрегулированным функциональным точкам (AFP), c учетом коэффициента подстройки.
Язык программирования Количество строк кода на функциональную точку
C# 55
C++ 55
JAVA 55
SQL 13
Perl 20
HTML 15
Таблица 8
Типы приложений
Name Type_b/o UFP_Size AFP_Size SLOC SLOC/UFP SLOC/AFP
APP1 b 10 8 1620 162,00 202,50
APP2 b 53 37 3571 67,38 96,51
APP3 b 91 61 6253 68,71 102,51
APP4 o 46 33 7552 164,17 228,85
APP5 b 79 58 11153 141,18 192,29
APP6 o 176 125 11275 64,06 90,20
APP7 b 56 39 12564 224,36 322,15
APP8 o 87 87 16703 191,99 191,99
APP9 b 468 309 18074 38,62 58,49
APP10 o 126 99 20890 165,79 211,01
APP11 b 467 308 22309 47,77 72,43
APP12 o 129 117 24070 186,59 205,73
APP13 b 335 248 36174 107,98 145,86
APP14 o 280 255 40959 146,28 160,62
APP15 o 328 257 56963 173,67 221,65
APP16 b 472 350 58804 124,58 168,01
APP17 o 354 344 61764 174,47 179,55
APP18 o 629 648 130794 207,94 201,84
APP19 o 1010 1043 143305 141,89 137,40
APP20 o 584 549 211020 361,34 384,37
т. е. с теми же технологиями (рис. 2, 3). Для таких проектов, взятых как базис, оценка будет ближе к реальности. По этим исходным данным приведем таблицу (см. табл. 10) оптимистического и пессимистического прогнозов для времени реализации проекта, состоящего из 500 FP [6].
Если база выполненных проектов достаточно большая, можно использовать технику аппроксимации данных аналитической нелинейной функцией для расчета данных по текущему проекту вида
SLOC = f(UFP).
Модели оценки трудоемкости часто имеют экспотенциальную форму:
Effort = A х (Size)B; A = 2,55.
Если B < 1,0, то трудоемкость растет медленнее, чем объем проекта, если B = 1,0 - отношение линейно, если B > 1,0, то с ростом проекта трудоемкость растет быстрее за счет роста количества связей в системе и расходов на ее поддержку.
В COCOMO существовали три класса разработки - Organic, Semidetached и Embedded [3], для всех видов классов здесь B > 1,0, что говорит о том, что трудоемкость растет быстрее, чем размер системы: Borganic = 1,05; Bsemidetached = 1,12;
BEmbedded = 1,2°.
В COCOMO II существует более точная подстройка коэффициента масштабирования B для фаз 2 и 3, для стадии создания прототипа B = 1,0 (см. табл. 11):
B = 1,01 + 0,01£ W.
АРР1
АРР18
АРР17
АРР16
АРР15
АРР14
АРР20
800,00
АРР1Э
АРР13
АРР2
АРРЗ
АРР4
АРР5
АРР6
АРР7
АРР8
АРРЭ
АРР12
АРР10
Рис. 1. График отношений: 1 - SLOC/UFP; 2 - SLOC/AFD
Таблица 9
Таблица статистики для отношений SLOC/UFP и SLOC/AFP
Показатели SLOC/UFP SLOC/AFP
Среднее 148,04 178,70
СКО 74,1873655 79,418177
Минимум 38,62 58,49
Максимум 361,34 384,37
Отношение макс/мин 9,3562614 6,5713633
Таблица 1 0 Прогнозы трудоемкости для SLOC/FP и SLOC
SLOC/FP SLOC Прогноз трудоемкости в чел.-мес.
оптимистический номинальный пессимистический
39 (min) 19500 62 77 96
148 (avg) 74000 267 334 417
361 (max) 180500 712 890 1113
Таким образом, Effort - это номинальная трудоемкость, полученная через экспотенци-альную форму, учитывающую зависимость затрат на разработку от ее объема. В модели раннего этапа проектирования и модели этапа пост-архитектуры COCOMO II необходимо внести поправку9 [3] в номинальную трудоемкость
9 Согласно базовой модели СОСОМО II в расчете трудоемкости участвует группа множителей, которые уточняют оценку; они корректируют основную формулу, исходя из экспертных оценок по проекту.
с учетом дополнительных множителей трудоемкости по формуле
РМаф1^ = РМПот1Па1 ^П ЕМ ^ ,
где ЕМ1 - множители трудоемкости.
Описание данных множителей приводится в табл. 12.
Существуют оптимистическая и пессимистическая оценки для трех моделей в зависимости от полученной трудоемкости (см. табл. 13).
UFP 600 -500 -400 -300 -200 -100 -
0 -
D
Рис. 3. Отношения SLOC vs UFP для онлайн-проектов
Таблица 11
Схема оценок W для коэффициента масштабирования [3]
10000 20000 30000 40000 50000 60000 70000 Рис. 2. Отношения SLOC vs UFP для batch-проектов
Фактор W Прецедентность Гибкость разработки Архитектура / разрешение рисков, % Сплоченность команды Зрелость процессов разработки
Очень низкий (5) Абсолютно не знакомо Очень низкая 20 Сложная Очень низкая
Низкий (4) Большей степенью Низкая 40 Немного Низкая
не знакомо сложнее
Номинальный (3) Кое-что знакомо Номинальная 60 Базовая Номинальная
Высокий (2) В общем знакомо Высокая 75 Сильная Высокая
Очень высокий (1) В большей степени Очень 90 Очень сильная Очень высокая
знакомо высокая
Чрезвычайно Полностью знакомо Чрезвычайно 100 Прозрачная Чрезвычайно
высокий (0) высокая высокая
С течением разработки проекта во времени диапазон оптимистических и пессимистических оценок сужается в пределах фактической длительности проекта. Поскольку накапливается
больше информации и уточняются оценки, модель в процессе реализации проекта может калиброваться для пересмотра первоначальной оценки.
Таблица 1 2
Таблица 1 3
Множители, используемые в модели раннего дизайна и постархитектурной модели
Оптимистическая и пессимистическая оценки моделей
Множители
Модель раннего дизайна Постархитектурная модель
RCPX RELY, DATA, CPLX, DOCU
RUSE RUSE
RDIF TIME, STOR, PVOL
PERS ACAP, PCAP, PVOL
PREX AEXP, PEXP, LTEX
FCIL TOOL, SITE
SCED SCED
Модель Оценка
оптимистическая пессимистическая
Прототип 0,50E 2,0E
Раннего дизайна 0,67E 1,5E
Пост-архитектуры 0,80E 1,25E
Обозначения . PREC - опыт подобных разработок; FLEX - определенность предполагаемого процесса разработки; RESL - степень выполняемого анализа риска; TEAM - слаженность команды; PMAT - зрелость процесса организации).
Факторы продукта: RELY - требуемая надежность ПО; DATA - размер базы данных; CPLX - сложность продукта; REUSE - требуемая повторная используемость; DOCU -документирование требований жизненного цикла.
Факторы платформы (виртуальной машины): TIME -ограничения времени выполнения; STOR - ограничения памяти; PVOL - изменчивость платформы.
Факторы персонала: ACAP - возможности аналитика; PCAP - возможности программиста; AEXP - опыт работы с приложением; PEXP - опыт работы с платформой; LTEX -опыт работы с языком и утилитами; PCON - непрерывность персонала.
Факторы проекта: TOOL - использование программных утилит; SITE - мультисетевая разработка; SCED - требуемый график разработки.
Таким образом, как показывает практика, проведение расчетов и прогнозирование трудозатрат с приемлемой точностью оценки можно получить благодаря комбинированным методикам. Использование и применение не одной модели, а комплекса моделей - моделей, построенных на аналогиях с учетом исторического опыта разработок, экспертных моделей, моделей объектных точек, различного рода формализованных моделей (конструктивная модель стоимости COCOMO II -2000; функциональных точек (Functional Point), а также их доработок дают более точную оценку.
Разработанная нами на основе перечисленных моделей комбинированная модель позволяет создать приемлемый инструмент для гибкого сравнительно анализа трудозатрат, ресурсоемкости и связанных с ними рисков на различных этапах проектирования и разработки ИС. Апробация предлагаемых решений проведена с использованием фактических данных созданных и инициируемых проектов в различных ИТ-компаниях.
СПИСОК ЛИТЕРАТУРЫ
1. Morris, P.M. Function Point Analysis Validating the result [Text] / P.M. Morris, J.M. Desharnais // Total Metrics Pty Ltd and LMAGL, July 2001.
2. Garmus, D. Function Point Analysis [Text] / David Garmus, David Herron // Addison-Wesley, November 2001.
3. Boehm, B.W. Software Cost Estimation with Co-como II [Text] / Barry W. Boehm, Chris Abts, A. Winsor Brown // Prentice Hall Ptr, August 2000.
4. Wiegers, K.E. Software Requirements [Text] / Karl E. Wiegers // Microsoft Press, December 1999.
5. Galorath, D.D. Software Sizing, Estimation, And Risk Management: When Performance Is Measured Performance Improves [Text] / Daniel D. Galorath, Michael W. Evans // Auerbach Publications, March 2006.
6. Boehm, B.W. Software Engineering Economics [Text] / Barry W. Boehm // Prentice Hall Ptr, October 1981.
7. [Electronic resource] / Software Engineering Institute. - URL: http://www.sei.cmu.edu
8. [Electronic resource] / Ассоциация «Software Metrics». - URL: http://www.softwaremetrics.com
