CC BY
763
N93(15)2008
М.А. Глазова
Системы оценки стоимости проектов по разработке программного обеспечения
Сейчас, в эпоху быстро развивающихся информационных технологий, растущего числа высокобюджетных проектов в области разработки программного обеспечения, очень важным становится умение оценить на ранних этапах возможные выгоды и убытки от проекта, проанализировать возможные сценарии развития событий. По статистике, примерно четверть всех начатых проектов завершается своевременно, четверть отменяется и около половины всех проектов завершается с превышением бюджетных затрат или с опозданием. Большая часть причин связана с некорректностью оценок стоимости проекта, что делает это направление одним из важнейших, особенно для крупных предприятий.
Согласно ежегодно публикуемому обзору The Standish Group, в среднем превышение сроков осуществляемых проектов составляет около 120%, а затрат— около 100% [1]. Реальная оценка может быть еще менее оптимистичной, так как у части завершенных с превышением сроков и стоимости проектов оказываются частично урезанными те функции, которые были описаны в первоначальном проекте.
Основными причинами провалов проектов являются:
• фактор неопределенности, особенно на ранних стадиях проекта;
• плохое управление проектом, создающее дополнительную неопределенность, нестабильные требования;
• невключение в расчет части задач;
• излишний оптимизм оценки, наличие субъективизма в оценках;
• непродуманные и необоснованные оценки;
• незнание предметной области;
• упрощение оценки при передаче ее на верхние уровни управления;
• отсутствие единого механизма оценки стоимости.
Как видно, большая часть причин связана с некорректностью оценок стоимости 12
проекта, что делает это направление одним из важнейших, особенно для крупных предприятий, где количество проектов может достигать более сотни в год.
Для выполнения корректной оценки стоимости необходимо иметь такой инструмент, который бы позволял производить точные оценки даже начинающему менеджеру. Причем для предприятия, использующего современные информационные технологии в своей работе, существенно, чтобы инструмент был частично или полностью автоматизирован.
Задачу получения точных оценок путем несложных расчетов, доступных начинающему менеджеру, позволяет решить механизм построения модели оценки стоимости. Модель оценки стоимости — это математический алгоритм, используемый для того, чтобы оценить стоимость продукта или проекта.
Выделим случаи, в которых может потребоваться использование модели оценки стоимости:
• требуется определить: делать инвестиции или принять иные финансовые решения, касающиеся разработки программного продукта;
• необходимо осуществлять контроль за бюджетом и расписанием проекта (на-
№>3(15)2008
пример, могут потребоваться такие оценки: сколько людей необходимо привлечь к выполнению проекта на той или иной его стадии, сколько денежных и трудовых затрат потребуется, чтобы достичь главных целей проекта);
• надо принять решение, чем стоит пожертвовать в данной ситуации — денежными затратами, временем, функциональностью, интерфейсом или качеством. Это важно, например, если надо определиться, что дешевле и выгоднее — разработать недорогую или полнофункциональную, отвечающую всем стандартам качества программную систему;
• следует принять решения относительно рисков, связанных со стоимостью проекта и графиком работ (например, если пользователь не до конца уверен, к чему приведет то или иное решение, он может провести моделирование и проанализировать последствия тех или иных изменений в проекте);
• необходимо решить, какую часть программного обеспечения следует разработать, какую — повторно использовать, а какую — приобрести у внешнего производителя. Хорошая модель оценки стоимости позволит понять, что будет дешевле — разработать компонент заново, приобрести его или же переработать уже существующий компонент;
• требуется определить, какие части программного обеспечения модифицировать в первую очередь, какие — убрать, на разработку каких назначить внешних исполнителей в случае разработки новой версии системы;
• ведется процесс разработки стратегии улучшения процессов внутри организации путем повторного использования кода, более совершенного инструментария для разработки, повышения зрелости процессов. На основе модели оценки пользователь может оценить, какая стратегия будет максимально эффективной, а какая — принесет минимум улучшений при большом объеме затрат.
В настоящее время существует множе- § ство различных моделей оценки стоимости. ^ Чтобы определить, какая модель лучше всего подойдет для нужд конкретного пред- ^ приятия, необходимо разработать список единых критериев, по которым можно оценить эти модели, провести их сравнительный анализ и выбрать ту, которая наиболее полно и правильно описывает процесс разработки, позволяя получить точные результаты.
Следующей задачей, которую решает менеджер, отвечающий за оценку стоимости программных проектов на предприятии, является анализ существующего рынка программного обеспечения, на базе которого можно оценить стоимость проекта. Прежде всего следует рассмотреть сильные и слабые стороны каждого программного продукта, выделить те требования, которым этот продукт должен удовлетворять исходя из потребностей предприятия. Если на рынке отсутствует продукт, удовлетворяющий необходимым требованиям, его следует разработать.
Выбранные модель и программное обеспечение должны быть проверены на реальных проектах с целью выявления расхождений между теми значениями, которые были получены на основе модели и программного обеспечения, и фактическими значениями по проекту. На основании полученных результатов можно будет сделать вывод о целесообразности использования выбранных модели и программного обеспечения в качестве модели оценки стоимости. В случае выявления расхождений необходимо найти способ их устранения, определить возможность улучшения модели, повышения точности ее оценок.
История развития
моделирования оценки стоимости программных проектов
До возникновения моделей оценки стоимость программного продукта оценивалась по «правилу большого пальца» [8]. Согласно нему создаваемое приложение часто ог-
N93(15)2008
раничивалось определенной сферой деятельности, в которой были свои эксперты. Эти специалисты могли с той или иной степенью достоверности сказать, каковы будут размер создаваемого кода и его стоимость. Применяемое в большинстве случаев, это правило часто не подходило для нетиповых проектов разработки. Активно использовалось и оценивание по аналогии — данные брались из похожего, успешно завершенного проекта и перекладывались на новый проект. Разумеется, степень достоверности таких оценок была очень невысока.
По мере увеличения количества и размера программных проектов область оценки их стоимости тоже стала расширяться. Эксперты, работающие в области управления программными проектами, стали определять общие тенденции и правила оценки стоимости, которые активно использовали в своей работе. Накопив материал на достаточно большом количестве проектов, они .к старались вывести формулы для оценки g стоимости. Разумеется, риск неточности § расчетов оставался высоким, поскольку границы действия правил, выводимых экс-
0 пертами, можно было определить лишь со § временем, с увеличением числа проектов, | на которых эти правила проверялись.
& Начало интенсивных исследований в об-& ласти моделирования оценки стоимости да-§ тируется 1965-1966 годами, когда Э.А. Нельсон, сотрудник компании System Develop-Ц ment Corporation (SDC), выполнявшей ис-^ следование в области подсчета стоимости S программного обеспечения для Военно-§ воздушных сил США, опубликовал работу ^ под названием «Настольная книга по управ-g лению оценкой стоимости затрат на про-
1 граммирование» [18]. В книге были приве-§ дены результаты статистического анализа ^ затрат и факторов затрат, характеризую-| щих процессы проектирования, программи-!э рования и тестирования 169 законченных Л программных проектов. Кроме того, были ^ произведены расчеты по оценке таких за-^ трат, как человеко-месяцы, приведены советы по их использованию.
14
После издания этой книги — в конце 60-х — начале 70-х — появилось достаточно большое количество моделей оценки (Delphi, Wolverton и др.).
Модель Delphi была создана корпорацией Rand еще в далеком 1940 году, однако результаты исследований были опубликованы только в 70-е годы. Эта техника во многом опиралась на мнение экспертов, нежели на результаты расчетов, поэтому могла использоваться только с учетом доли погрешности, но поскольку она требовала мнения нескольких экспертов и их обсуждения, вероятность ошибки в некоторой степени уменьшалась.
Модель сотрудника компании TRW Р.У. Волвертона, позже ставшего вместе с группой других исследователей создателем одной из наиболее широко используемых моделей оценки стоимости — COCOMO, появилась в 1974 году [26]. Это была одна из наиболее ранних попыток формально измерить продуктивность работы программиста с использованием количества строк кода. Р.У. Волвертон предложил использовать объектные инструкции на человеко-месяц как меру производительности, опубликовал типовые значения инструкций и примеры их использования.
Проблемой оставался тот факт, что измерения осуществлялись в единицах количества строк кода, которые, во-первых, изменялись от проекта к проекту при использовании разных языков программирования и, во-вторых, могли применяться уже на этапе программирования, когда разработчик мог с большой долей вероятности оценить предполагаемый размер программного кода.
Важной вехой в развитии направления оценки программного проекта стало появление концепции функциональных точек [6]. В 1977 году они впервые были представлены сотрудником компании IBM Аланом Альбрехтом. Функциональные точки позволяли оценивать сложность и приблизительный размер программного продукта на ранних стадиях разработки — на эта-
№>3(15)2008
пах анализа и проектирования. В 1984 году Альбрехт усовершенствовал механизм оценки, а в 1986 году появилась международная группа пользователей метода функциональных точек (International Function Point User Group — IFPUG). В 1988 году Кэ-перс Джонс, основатель и ведущий специалист по науке компании Software Productivity Research LLC, предложил расширение для модели функциональных точек, которое дало возможность оценивать системы реального времени путем использования нового, дополнительного параметра [15]. В 1988 году [22] и в 1991 году [23] эта модель была модифицирована Чарльзом Симонсом, исследователем из компании Nolan, Norton & Co (NNC), Лондон. До сих пор она широко используется в Европе и США.
В 1977 году также появился первый коммерческий продукт по оценке стоимости программного проекта. Им стала модель PRICE-S, разработанная сотрудниками компании Martin Marietta Price Systems Ф. Фрей-мэном и доктором Р. Парком [19]. В модели использовались как концепция количества строк программного кода, так и концепция функциональных точек. Это сделало ее универсальной. В 1987 году PRICE-S была модифицирована с учетом практики современных проектов.
Чуть позже, в 1978 году, появляется вторая коммерческая модель — SLIM, созданная компанией Quantitative Software Management, Inc. (QSM).
К концу 70-х — началу 80-х годов появляется еще ряд серьезных моделей — таких как SEER, ESTIMACS.
В 1981 году доктор Барри Боэм, исследователь, директор центра системного и программного обеспечения университета Южной Калифорнии, предложил свою модель COCOMO (The COnstructive COst MOdel — конструктивная модель затрат), которая основывалась на метрике подсчета строк кода [10]. Благодаря ее высокой точности и возможности ее калибровки для разных проектов, она быстро стала одной
из наиболее популярных. В 1995 году был § опубликован обновленный вариант модели g [24]. ^
В 80-е годы к исследованию проблемы ^ оценки стоимости подключаются крупные организации — такие как Rome Air Development Center (RADC) и NASA.
Хотя большинство исследователей работали независимо, рано или поздно все они вставали перед проблемой: с ростом размера программного продукта возрастала и его сложность, в результате процесс оценки становился более сложным, а часто — даже невозможным. Эта сложность будоражила интерес исследователей.
В данной области существовало много слабых мест. Из-за быстрого изменения природы разработки программного обеспечения, появления новых технологий сложно было выделить параметрические модели, которые бы отвечали всем требованиям и могли использоваться во всех отраслях разработки. Создание такой модели стало одной из важнейших целей специалистов по информационным технологиям. Если проанализировать современные разработки, то можно сказать, что они во многом построены на основе тех моделей, которые создавались в 70-80-х годах. Наиболее часто появлялись методы, включающие классический мультипликативный регрессионный подход [9]. Также были разработаны методы, основанные на других подходах. В частности, среди наиболее современных моделей оценки следует отметить модели, основанные на нейронных сетях [25]. Обладая возможностью обучения, эти модели считаются достаточно перспективными, особенно с учетом постоянного развития информационных технологий и возрастания сложности проектов. Также появились модели, использующие композитный подход [9]. Однако коммерческие продукты на основе этих моделей пока не созданы, так как не накоплено достаточного объема информации для того, чтобы подтвердить или опровергнуть их корректность.
ИвЗ(15) 2008
I
IS
о
5
6
о &
£ I
to
SI
<u
о &
u
i о
и
г
I
а
Основные направления оценки стоимости
Направления оценки стоимости программного обеспечения можно подразделить на несколько категорий [9]:
1) методы оценки, основанные на моделях, — имеют в качестве ядра математическую модель. Они содержат алгоритм, на основе которого в соответствии с входными параметрами, полученными от проекта, вычисляется его стоимость;
2) методы оценки, основанные на экспертном мнении, — опираются на точку зрения экспертов, имеющих значительный опыт в разработке программного обеспечения в заданной сфере;
3) методы оценки с возможностью обучения — являются, по сути, обновленным методом оценки по аналогии с последующим обучением системы оценки путем техники искусственного интеллекта (такой, как нейронные сети);
4) динамические методы оценки — используют динамику изменения таких показателей, как затраты, навыки, усилия для расчета стоимости проекта;
5) регрессионные методы — используются в сочетании с методами оценки, основанными на моделях, и включают стандартную регрессию, робустовскую регрессию и т.п.;
6) композитные методы оценки являются комбинацией двух и более методов оценки для формирования наиболее подходящей формы оценки.
В табл. 1 [9] представлены результаты проведенного автором сравнительного анализа основных существующих на данный момент моделей оценки стоимости. Анализ проводился на основе факторов, влияющих на стоимость проекта, которые принимались или не принимались в расчет в данных моделях. Знак вопроса в таблице означает невозможность однозначно определить, учитывается данный фактор или нет. Это значит, что атрибут отсутствует
в явном виде как параметр модели, но, по сути, может подразумеваться другими параметрами.
В процессе исследования автором было установлено, что наибольшей полнотой учета факторов обладают две модели — SEER-SEM и COCOMO II. Также приемлемый охват факторов имеют модели SLIM [20] и PRICE-S [19]. Рассмотрим их преимущества и недостатки более подробно.
Преимуществами модели SEER-SEM и соответствующего программного продукта оценки являются:
• возможность ее использования в режиме реального времени;
• возможность ее подключения к различным системам;
• гибкость по отношению к различным доменам;
• поддержка планирования;
• множество отчетов;
• возможность производить калибровку как с историческими данными, так и с организационной информацией;
• анализ рисков.
Среди недостатков модели SEER-SEM можно выделить следующее:
• недоступны алгоритмы модели для возможности создания на ее основе программных продуктов сторонних производителей, так как SEER-SEM изначально создавалась для коммерческого использования; отсюда возникает неясность, поддерживаются определенные типы входных данных или нет;
• нет опубликованных независимых исследований об использовании этой модели;
• модель требует калибровки для того, чтобы можно было использовать информацию от организации.
Таким образом, модель SEER-SEM, обладая огромным потенциалом, является частью программного продукта — «черного ящика», и поскольку алгоритмы вычисле-
16
-^ №3(15)2008
Таблица 1 §
о
Сравнительный анализ моделей оценки стоимости §
С
Атрибуты Количество инструкций в коде + + + - + - +
размера Функциональные точки + + + + + - +
Объектно-ориентированные + + + ? + + +
метрики
Атрибуты Тип/домен + + + + + + -
программы Сложность + + + + + + +
Язык + + + ? + + +
Повторное использование + + + ? + + +
Требуемая надежность ? ? + + + - +
Атрибуты Ограничения ресурсов + ? + + + - +
компьютера Устойчивость платформы ? ? ? ? + - +
Атрибуты Возможности персонала + + + + + + +
персонала Текучесть кадров ? ? ? ? ? - +
Опыт персонала + + + + + - +
Атрибуты Инструментарий и техники + + + + + + +
проекта Разрывы + + + ? + + +
Ограничения графика + + + + + + +
Зрелость проекта + + ? ? + - +
Сплоченность команды ? + + ? + + +
Вопросы безопасности ? ? ? ? + - -
Множественная разработка ? + + + + - +
Этапы Начало работ + + + + + + +
Разработка + + + + + + +
Создание + + + + + + +
Поддержка + + + - + - +
ний не раскрыты, модель невозможно использовать в независимых программных продуктах.
Преимуществами модели COCOMOII являются:
• надежная отлаженная модель, хорошо известная и изученная;
• простая для использования;
• обладает достаточной точностью;
• поддерживает современный процесс разработки программного обеспечения.
Среди недостатков модели COCOMO II можно отметить следующее:
• необходимость производить калибровку модели в отдельных случаях, а калибровка требует большого количества сведений о предыдущих проектах, которых может не быть.
Преимуществами модели SLIM можно считать следующее:
• легкое ее приложение к автоматизации, простота пользовательского интерфейса;
• функции анализа рисков;
• анализ чувствительности модели;
• в программной реализации модели присутствует множество отчетов.
N93(15)2008
Недостатки модели SLIM:
• фактор сжатия графика преувеличен;
• нет статистических доказательств, что индекс продуктивности, используемый в модели, должен быть именно таким;
• база данных проекта не опубликована.
Преимуществами модели PRICE-S и соответствующего программного продукта являются:
• возможность использования в реальном времени;
• есть анализ рисков;
• поддерживается вычисление размера как в строчках кода, так и в функциональных точках;
• хорошая калибровка модели;
• хороший пользовательский интерфейс;
• поддержка операционными системами Windows и Unix;
| • возможность экспорта в MS Project.
I
Среди недостатков модели PRICE-S мож-
0 но отметить следующее: |
5 • модель основана на свойствах (т.е.
6 жизненный цикл проекта описывается таки-& ми свойствами, как количество инсталля-§ ций, ожидаемый рост, качество и т.п.). Поскольку такое описание является достаточно
Ц размытым, при отсутствии четкого регламен-
^ та оценки тех или иных свойств могут воз-
S никнуть существенные расхождения в оцен-
5; ке одинаковых по жизненным циклам про-
^ ектов разными менеджерами проектов;
g • база данных, на основании которой
1 производилась первоначальная калибров-§ ка модели, недоступна пользователям —
эти данные являются закрытой коммерче-
| ской информацией;
!э • повышенная чувствительность к от-
§ дельным факторам, в частности, к факто-
^ рам производительности, сложности и плат-
^ форме. Поскольку в реальности их влияние
на проекты разных типов, с персоналом
разной степени опытности может серьезно варьировать, точность оценки в этих случаях может значительно снизиться.
Программная реализация моделей оценки стоимости
В настоящее время на рынке программных продуктов существует достаточно много систем управления проектами от таких компаний, как Primavera, Microsoft и ряд других. Проблема заключается в том, что в них нет механизма моделирования оценки стоимости проекта на основе таких моделей, ^^OCOMO, SLIM как таковых. Моделирование заключается лишь в создании некоторого пробного проекта как объекта системы, в распределении ресурсов и подсчете стоимости затрат и времени как результата. При этом прямо не учитывается целый ряд факторов — например, сложность программного продукта, квалификация персонала. Эти факторы менеджер проекта должен анализировать и в зависимости от их значения увеличивать или уменьшать ресурсы на выполнение работ, в том числе и временные. Чтобы упростить решение задачи, были разработаны несколько программных продуктов, основанных на моделях оценки стоимости, которые в удобной графической или текстовой форме призваны помочь менеджеру в составлении и проработке концепции программного проекта и анализе его состояния в зависимости от различных факторов.
В ходе проведенного исследования автор выделил основные характеристики и провел сравнительный анализ наиболее функциональных продуктов для оценки стоимости (табл. 2). На основании анализа наиболее крупных представителей систем по оценке стоимости программных проектов — SLIM Tools, KnowledgePlan и Charis-matek's Function Point WORKBENCH™ (FPW), Cost XPert, Borland CaliberRM [11] и анализа потребностей рынка автором были выработаны требования к программному продукту, основанному на математической модели оценки стоимости программного
№>3(15)2008
Таблица 2 §
о
<3
Сравнительный анализ программных продуктов оценки стоимости £
Наименование характеристики SLIM Tools KnowledgePlan FPW Cost XPert Borland CaliberRM
Поддержка различных моделей жизненного цикла Имеются шаблоны для разных жизненных циклов 32 стандарта и модели жизненного цикла
Поддержка различных языков программирования — + — + +
Простота использования Наличие мастеров для быстрой оценки Наличие мастеров для упрощения работы Возможность визуального построения процессов, различные режимы для новичка и профессионала Около 15 минут на первичную оценку Наличие мастеров
Наличие возможности проработки сценариев «что, если» Возможность просмотра в динамике + + + +
Наличие репозито-рия, возможности хранения истории Возможность переноса данных из истории на текущую оценку, имеется база знаний Есть база знаний + Возможность хранения информации о завершенных проектах и дальнейшего ее использования
Возможности экспорта/импорта MS Office, html MS Project, связь с внешними системами через ODBC .html, .xml-фор-маты MS Project, Primavera +
Наличие механизма поддержки принятия решений Предлагает варианты решения проблемы - — — —
Гибкость оценки размера кода 5 различных методик - - + +
Возможность калибровки + + - + +
Возможность совместной работы - + + - +
Разграничение доступов — - - — Возможность администрирования
Возможность коммуникаций внутри системы — - - — +
19
N93(15)2008
проекта. Согласно этим требованиям продукт должен иметь:
• возможность хранения и повторного использования данных об оценке;
• гибкую отчетность;
• возможность анализа типа «что, если», возможность построения прогнозов;
• возможность поддерживать не одну, а несколько моделей оценки или хотя бы методы оценки величины программного кода. Необходимость наличия более одного метода оценки в системе возникает в связи с большим разнообразием проектов, которыми приходится заниматься компаниям — разработчикам программного обеспечения. Внутри одного проекта могут создаваться компоненты с помощью различных технологий программирования, программных языков, для которых могут потребоваться разные методы оценки с целью достижения приемлемого уровня точности результата. Необходимо иметь механизм, с помощью ко-
5 торого можно было бы достаточно точно оце-§ нить размер программного кода этих компонентов, а также перевести это значение в
о единый формат для всей системы в целом; § • возможность поддерживать разные мо-
| дели жизненного цикла, а также разные язы-
6 ки программирования, на которых реализу-& ется оцениваемый программный проект;
§ • возможность калибровки программы, т.е. подстройки системы под конкретное предприятие на основе данных по проектам.
^
0
^ Если же рассматривать программный £ продукт, который будет использоваться на ^ крупном предприятии, необходимо добавить еще одно условие:
и
1
§ • высокая информационная безопас-
^ ность продукта. Это подразумевает нали-
| чие подсистемы, отвечающей за защиту ин-
!э формации от несанкционированной утечки.
Ц Информация по проектам обладает высо-
^ ким уровнем конфиденциальности, поэтому
^ в системе должно быть четкое разграничение доступов.
20
В процессе исследования программных продуктов по оценке стоимости проектов автором установлено, что последнее условие не было реализовано полностью ни в одной из рассмотренных систем, тогда как является тоже весьма существенным. Оно предполагает возможность ограничения просмотра информации для пользователей системы в зависимости от их привилегий, а также возможность ограничения их действий внутри системы. К примеру, ряду пользователей нужно давать доступ только на просмотр информации, другим же (менеджерам проекта) нужна возможность выполнения оценки и прогнозирования, но в рамках лишь проектов, в которых они участвуют. Иным сотрудникам может понадобиться полная информация по всем существующим проектам для возможности составления прогнозов и анализа эффективности работы предприятия в целом. Таким образом, система разграничения доступов обязательно должна присутствовать.
Другим обязательным требованием для системы в крупной компании является возможность совместной работы пользователей системы в рамках как одного, так и нескольких проектов оценки. Необходимо, чтобы была возможность разделения данных и использования их таким образом, чтобы это было удобно для всех пользователей. Такая возможность имеется лишь в трех системах из рассматриваемых пяти: в KnowledgePlan, в FPW и в Borland Cali-berRM.
Система оценки стоимости программного проекта также должна встраиваться в корпоративную систему предприятия. В противном случае возникает большое количество проблем экспорта/импорта данных — по сути, получается «лоскутная» автоматизация вместо целостной. К примеру, если компания использует систему управления предприятием, одним из компонентов которой является подсистема управления проектами, но для оценки стоимости проекта применяется сторонний продукт, то это означает, что данные необходимо дублиро-
№>3(15)2008
вать. Кроме того, при переносе велика вероятность ошибки, а если это продукт без возможности совместного использования, то такой вариант может принести больше проблем, чем пользы. При наличии связи системы оценки стоимости с системой управления предприятием появляется возможность переноса разграничения доступов в соответствии с должностными полномочиями, а также — при наличии системы коммуникации — возникает совместное информационное пространство, в рамках которого можно производить обсуждение проекта, сохранять комментарии, которые будут полезны для последующего использования.
Поскольку никакой из существующих на рынке программных продуктов в полной мере не удовлетворял перечисленным условиям, автором было принято решение разработать новое программное средство по оценке стоимости программного проекта.
Модель COCOMO II
как основа программного продукта по оценке стоимости GBOSSmis.PJ.Cost
В качестве модели, на основе которой автор создал систему оценки стоимости, была выбрана СОСОМО II как обладающая наибольшим количеством преимуществ по сравнению с остальными моделями оценки и, что немаловажно для программной реализации, имеющая подробное описание алгоритмов настройки и последующей оценки.
Модель СОСОМО II поддерживает разные модели жизненного цикла и языки программирования, может использоваться на различных этапах жизненного цикла разработки.
Всего в модели СОСОМО II используются 3 способа оценки размера программного продукта:
• объектные точки;
• функциональные точки;
• количество строк кода.
Оценка с использованием объектных точек — сравнительно новый подход к изме-
рению размера программного продукта, но § она оптимально подходит для компаний, за- g нимающихся настройкой и продажей программных продуктов. Этот вид оценки за- ^ ключается в анализе сложности форм, отчетов и компонентов приложения на основе подсчета количества окон, клиентских и серверных таблиц, которые использует тот или иной компонент. Каждому компоненту ставятся в соответствие уровень сложности — простой, средний или сложный, а также значение веса. Далее веса складываются, и полученное значение используется в формуле для расчета стоимости проекта [24]. Данный вид оценки хорошо проходит для систем визуального проектирования, в которых есть понятия «экранная форма», «отчет», «компонент». Однако в языках программирования, которые используют понятия «класс», «наследование», «инкапсуляция», подсчет объектов становится затруднительным. В этом случае разумнее применять оценку по количеству строк кода.
Определение термина «строка кода» имеет некоторые сложности, поскольку подсчет исполняемых элементов в разных языках программирования сильно различается в связи с особенностями объявления переменных, конструкций языка и т.п. В модели COCOMO II в качестве единицы строки кода были выбраны логические строки (т. е. строки кода, которые содержат конкретную операцию или выражение, что позволяет учесть особенности языка, в отличие от физических строк без разбивки на операции).
Для минимизации проблем, связанных с оценкой количества строк кода, Институт программной инженерии (Software Engineering Institute — SEI) разработал специальный анкетный лист, по результатам которого можно оценить размер кода. Для использования в модели COCOMO II лист был модифицирован. Документ содержит несколько разделов, в которых подробно описываются свойства кода, особенности языка. На основе данной информации становится проще выделить логические строки и подсчитать их общее количество.
N93(15)2008
Оценка методом функциональных точек основана на оценке размера функциональности в программном проекте и на наборе индивидуальных факторов проекта. Функциональные точки удобны тем, что они основываются на информации, доступной на ранних этапах жизненного цикла. Метод оценки заключается в разбивке компонентов системы по признакам 5 функциональных типов. Каждый экземпляр этих функциональных типов подразделяется по уровню сложности. Уровням сложности соответствует набор весов, которые применяются к соответствующему значению для подсчета общего количества функциональных точек. От функциональных точек можно перейти к размеру программного кода в строках. Для этого существуют таблицы соответствий, в которых для каждого языка программирования указывается количество строк кода, соответствующих одной функциональной точке. Этот показатель используется в формулах расчета стоимости | проекта.
§ Модель СОСОМО II подразделяется на 3 различные модели. Выбор той или иной о модели для оценки стоимости программно-§ го обеспечения зависит от типа проекта || и степени понимания продукта. & Модель композиции приложения вклю-& чает оценку прототипа пользовательского § интерфейса, взаимодействия системы и программного обеспечения. Она используется Ц на ранних стадиях разработки проекта. ^ Модель раннего проектирования вклю-^ чает изучение альтернативных архитектур £ и концепций работы. На этой стадии недос-^ таточно общих представлений о проекте, ¡8 здесь уже требуются детали. Детальное | описание проекта для последующего рас-§ чета стоимости включает использование ^ функциональных точек и небольшое коли-| чество дополнительных драйверов затрат. !э Модель постархитектуры связана с ре-§ альной разработкой и эксплуатацией программного продукта. Эта модель работает <2 наиболее эффективно, если разработана
архитектура жизненного цикла, проверено 22
ее соответствие миссии компании, концепции взаимодействия, рискам, определена структура компонентов разрабатываемого продукта. Модель использует инструкции и/или функциональные точки для оценки размера с модификаторами повторного использования и коэффициентами брака, набор из 17 мультипликативных факторов затрат, а также набор из 5 факторов для более точной настройки.
Важной особенностью модели СОСОМО II является то, что для повышения точности выполняемых с помощью модели оценок менеджер может со временем перенастроить рейтинговые шкалы и коэффициенты под свои нужды — производить так называемую калибровку модели. Это необходимо делать потому, что каждое предприятие имеет свою специфику технологий, жизненного цикла, которая может вносить неточности в стандартную модель, предлагаемую ее создателями.
Калибровка может производиться двумя способами:
1) путем экспертных оценок. Это означает, что менеджер, накопив большой опыт в области оценки стоимости управления проектами, может с той или иной долей вероятности утверждать, что для данного проекта определенный фактор (например, опытность персонала) окажет большее влияние, чем предлагает стандартная модель. Поэтому менеджер увеличивает значение фактора, тем самым изменяя конечную стоимость проекта;
2) путем множественного регрессионного анализа. Это означает, что с помощью определенных преобразований, при наличии достаточно большого объема данных о результатах выполненных проектов в конкретной организации, можно получить набор измененных значений факторов и коэффициентов, лучше подходящих для оценки стоимости в данной организации.
Таким образом, изменяя базовые формулы расчета системы, менеджер может
№>3(15)2008
последовательно повысить точность оценок и результативность модели в целом.
В процессе исследования автор установил, что свойства, характерные для модели COCOMO II, отвечают требованиям, сформулированным ранее на основе изучения программных продуктов стоимостного анализа и предъявляемым к продукту по оценке стоимости: имеется поддержка разных методов оценки величины программного кода, поддержка разных моделей жизненного цикла и языков программирования, возможность калибровки системы. Поэтому модель COCOMO II была взята за основу создаваемого продукта по оценке стоимости.
Общее описание программного продукта СBOSSmis.PJ.Cost
Клиентская часть системы оценки стоимости, как и вся система управления проектами в целом, написана в среде визуального проектирования с элементами объектно-ориентированного программирования Oracle Forms 6 на языке программирования PL/SQL. Серверная часть реализована в виде объектов Oracle (пакеты, таблицы, последовательности, индексы) версии 9.2. Пакеты также написаны на языке программирования PL/SQL.
Система была реализована автором с учетом всех требований [2] по оптимизации производительности для систем, предназначенных для нужд крупных предприятий. Нагрузка на клиентскую часть минимизирована — все сложные расчетные операции полностью проводятся на сервере.
Все данные, за исключением промежуточных, хранятся в таблицах. Это позволило реализовать требование возможности хранения и повторного использования данных об оценке: при наличии соответствующего доступа к проекту пользователь может посмотреть полную историю оценок, включая все изменения, которые производились с данными по проектам.
Система оценки стоимости программного проекта включает несколько подсистем.
1. Подсистема справочников. §
Подсистема содержит все основные ^
термины, списки, используемые для удобства пользователей (такие, например, как ^ «Сложность», «Тип модели»). Это позволило поддержать мультиязычность системы — хранить в таблицах термины как на русском, так и на других поддерживаемых системой языках, и подставлять термины на языке текущего пользователя системы.
2. Подсистема настройки.
Подсистема содержит таблицы, в которых хранятся данные по настройкам формул, рейтинговых шкал, используемых для подсчета стоимости проекта на основе модели оценки.
3. Подсистема хранения и анализа.
Подсистема содержит таблицы, в которых хранятся данные по оценкам проектов. С помощью этих данных можно производить сравнительный анализ проектов, выявлять расхождения в оценках и определять их причины.
4. Подсистема оценки стоимости.
Подсистема включает серверные пакеты, функции и процедуры которых осуществляют оценку стоимости на основе значений из подсистемы хранения и анализа.
5. Подсистема разграничения доступов.
Подсистема содержит настройки доступности операций пользователей системы по тем или иным проектам.
6. Подсистема калибровки.
Подсистема включает серверные пакеты, предназначенные для калибровки факторов модели с целью увеличения точности оценки.
Функции разработанной системы оценки стоимости разделяются по признаку подсистемы, которая их использует. Это функции:
• подсистемы разграничения доступов;
• подсистемы хранения и анализа;
• подсистемы справочников;
• подсистемы настройки;
• подсистемы оценки стоимости;
• подсистемы калибровки.
N93(15)2008
Функции подсистемы разграничения доступов разделяются на 3 вида:
• функции ведения проектных ролей.
Данные функции предназначены для
создания, редактирования, удаления и поиска ролей, которые в дальнейшем можно будет использовать в различных проектах. Роль была разработана как некоторый контейнер, в который помещается ряд доступных операций. Например, в роль «Менеджер проекта» добавлена операция «Оценка проекта» с типом «Доступен». Это означает, что если в систему оценки входит сотрудник, имеющий роль «Менеджер проекта» по указанному проекту, то он может производить оценку проекта. Если операция не добавлена в роль или же у нее стоит доступ с типом «Не доступен», то это означает, что сотрудник с данной ролью не может выполнять указанную операцию;
• функции ведения доступных ролям операций.
5 Данные функции позволяют определять § состав роли — какие операции будут доступны для той или иной роли;
0 • назначение ролей сотрудникам.
§ Данные функции позволяют назначить ра-| нее созданную роль определенному сотруд-
6 нику относительно к определенному проекту.
1
§ Функции подсистемы хранения и анализе за можно разделить на следующие виды: &
§
^ • ведение информации по проектам
^ оценки.
£ Данная функция позволяет сохранять
^ общие характеристики проекта оценки;
• ведение информации по факторам | проекта.
§ Эта функция позволяет вносить данные
^ по всем факторам проекта, которые в даль-
| нейшем будут использоваться для анализа; !э • ведение информации по мультиплика-
| торам проекта.
^ Данная функция предназначена для хра-
^ нения сведений о значениях мультипликаторов проекта. Факторы и мультипликаторы
24
представляют собой некоторые коэффициенты, участвующие в расчетах моделирования стоимости проекта. Отличием мультипликатора от фактора в рамках данного программного средства является наличие формулы расчета. Фактор является некоторым значением, хранимым в системе, используемым в расчете на основе информации, полученной от пользователя, и описательных данных, хранимых в системе. Мультипликатор же получается на основе совокупности факторов, значений и формулы, заданной в настройках системы;
• ведение информации по объектам проекта.
Данная функция позволяет произвести классификацию объектов проекта и описать их основные характеристики;
• ведение информации по оценке в объектных точках.
Данная функция позволяет оценить объект проекта в объектных точках и сохранить результат для дальнейшего использования;
• ведение информации об оценке в элементах (функциональных точках).
Данная функция позволяет оценить объект проекта в элементах и сохранить полученный результат;
• ведение информации об оценке в строках кода.
Данная функция позволяет оценить объект проекта в количестве строк кода.
Функции подсистемы справочников можно разделить на следующие виды:
• добавление данных;
• корректировка данных;
• удаление данных;
• поиск данных.
Функции подсистемы настройки можно разделить на следующие виды:
• ведение настроек факторов;
• ведение настроек мультипликаторов;
• ведение настроек объектных точек;
№>3(15)2008
• ведение настроек элементов (функциональных точек);
• ведение настроек весов объектов;
• ведение общей схемы настроек, связи настроек и проектов;
• ведение механизмов пересчета количества строк кода в функциональные точки.
Все данные настройки в целом представляют собой некоторые константы и их описания, согласно значениям которых в дальнейшем производится оценка с помощью модели СОСОМО II. Эти настройки были реализованы автором таким образом, чтобы было возможно их изменение по результатам калибровки для увеличения точности оценки.
Функции подсистемы оценки стоимости можно разделить на следующие виды:
• моделирование оценки стоимости.
Данные функции позволяют произвести
моделирование оценки стоимости программного проекта на основе полученной информации;
• анализ «что, если».
Данные функции на основе информации по программному проекту и тех значений, которые пользователь предполагает изменить, чтобы промоделировать, какая ситуация возникнет в случае их изменения, позволяют получить полную картину того, что ожидает менеджера проекта в случае развития ситуации по указанному им сценарию;
• сравнительный анализ проектов.
Эти функции были созданы с той целью, чтобы можно было сравнить несколько проектов для выявления их различий, для лучшего понимания менеджером ситуации (что пошло не так и как это исправить) или для использования сравнения в качестве обучающего материала.
Данные функции позволяют выводить результаты анализа как на экран, так и на печать (в виде отчета) по требованию пользователя.
Функции подсистемы калибровки подразделяются на 2 вида:
• анализ расхождений между фактиче- § скими и моделируемыми значениями. ^
Поскольку система оценки стоимости была разработана автором с возможно- ^ стью интеграции с системой управления проектами, менеджер с течением времени может получить точные фактические результаты стоимости программного проекта. Эта информация может быть полезна для системы оценки стоимости с целью увеличения точности оценки, потому как те значения, которые указаны в модели СОСОМО II, ориентированы все-таки на общую модель проекта, без учета специфики технологий предприятия. Поэтому, анализируя расхождения фактических и моделируемых значений, можно понять, в каких константах есть расхождения и что следует скорректировать для повышения точности оценки;
• подстройка в соответствии с расхождениями фактических данных по стоимости и срокам проектов от данных, полученных на основе моделирования оценки стоимости в системе.
Эти функции позволяют на основе полученного анализа расхождений произвести подстройку значений модели СОСОМО II под нужды конкретного предприятия.
Порядок работы с программным продуктом выглядит следующим образом. Сначала производится настройка системы. Она начинается с заполнения всех таблиц-справочников. Далее осуществляется настройка подсистемы разграничения доступов. Для этого определяется, какие роли будут присутствовать в проекте, каким ролям будут доступны какие операции. Также для каждой операции указывается, с каким статусом доступа она включается в данную роль. Статусов может быть два:
• операция не доступна;
• операция доступна.
После того как выполнена настройка системы, производится заполнение данных
по конкретному проекту. Заполняются дан-
N93(15)2008
ные по объектам проекта, проводится назначение проектных ролей конкретным сотрудникам, работающим по проекту и имеющим доступ к тем или иным операциям системы оценки стоимости.
Заполнение таблиц в ходе работы с системой выглядит следующим образом. Пользователь создает по конкретному проекту проект оценки, в который вносит информацию о том, кто и когда производит эту операцию и какой тип моделирования используется. Далее пользователь оценивает размер кода разрабатываемого программного продукта в объектных/функциональных точках или в количестве строк кода. После этого в зависимости от типа модели пользователю предлагается заполнить значения факторов, а также ввести данные, необходимые для расчета мультипликаторов.
Если пользователю необходимо произвести сравнительный анализ двух проектов и выявить какие-то различия, то по таблицам подсистемы хранения и анализа выбирается
5 информация по заданным проектам, прово-§ дится детализация тех показателей, которые
выбрал пользователь, они выдаются на эк-о ран, а в случае необходимости — ив виде от-§ чета «Сравнительный анализ проектов». || В ходе выполнения работы по проекту
6 менеджеру может понадобиться произве-& сти анализ «что, если». В этом случае на ос-§ нове некоторых общих данных, введенных
пользователем по проекту оценки и задан-Ц ной информации о том, изменение како-^ го/каких факторов нужно смоделировать, ^ система производит создание множества £ проектов оценки с разными значениями ^ этих факторов. Информация о расхождениях, ухудшениях, улучшениях значений стои-| мости, сроков проекта выдается пользова-§ телю на экран и по требованию на печать — ^ в виде «Отчета по анализу "что, если"». | При накоплении достаточного объема !э сведений по проектам пользователь может Ц также произвести калибровку модели. Это ^ означает, что значения факторов в на-^ стройках могут быть изменены на основе
данных о расхождениях фактических и мо-26^-
делируемых значений. Результатом данной операции будут являться измененные значения в соответствующих таблицах и, по требованию пользователя, «Отчет о калибровке системы». Результаты калибровки могут быть сохранены в конкретной настройке, которую можно будет применять как для одного конкретного проекта, так и для ряда проектов.
Итак, в процессе исследования возможностей по оценке стоимости программных проектов автором была решена задача разработки программного обеспечения, отвечающего всем сформулированным на основе изучения программных продуктов стоимостного анализа и перечисленным ранее требованиям к программному продукту по оценке стоимости. Программное обеспечение было апробировано в рамках опытной эксплуатации в ЗАО «Системы автоматизированного управления». Оно использовалось менеджерами проектов в качестве инструментария для моделирования оценки стоимости. Параллельно велось фиксирование фактических данных в системе управления проектами, на основании которых был проведен анализ точности оценок. В ходе процесса проверки и анализа полученных результатов было установлено, что наименее точной является оценка на этапе модели композиции приложения: фактическая длительность проекта оказалась более чем в 2 раза больше первоначальной оценки. Наиболее точной была оценка на этапе постархитектуры — разница между оцененными и фактическими значениями составила менее 1 человеко-месяца.
Автором был также произведен расчет экономической эффективности от внедрения системы оценки стоимости. Полученные результаты показали, что стоимостные затраты на оценку стоимости сократятся почти в 4 раза. Такое значительное снижение затрат достигается за счет существенного облегчения расчетов для менеджеров проектов и автоматической генерации требуемой отчетности по оценке стоимости.
№>3(15)2008
В целом разработанная система оценки решила поставленные задачи — с ее помощью точную оценку стоимости проекта может осуществить даже менеджер среднего уровня квалификации.
На данный момент система успешно используется в ЗАО «Системы автоматизированного управления» для прогнозирования стоимости проектов. Осуществляется активное накопление данных по проектам и оценкам стоимости с целью проведения полноценной калибровки системы и анализа возможностей адаптации модели под нужды конкретного предприятия.
Список литературы
1. Макконнелл С. Сколько стоит программный проект. М.: Русская Редакция; СПб.: Питер, 2007.
2. Миллсап К., Хольт Д. Oracle. Оптимизация производительности. СПб.: Символ-Плюс, 2006.
3. Орлов С. Технологии разработки программного обеспечения. Учебное пособие. 2-е изд. СПб.: Питер, 2003.
4. Шафер Д., Фатрелл Р., ШаферЛ. Управление программными проектами: достижение оптимального качества при минимуме затрат: Пер. с англ. М.: Издательский дом «Вильямс», 2003.
5. Barry W. Boehm. Software cost estimation with COCOMO II. Prentice Hall PTR, 2000.
6. AlbrechtA.J. Measuring application development productivity // IBM Applications develop. Symp. CA.1979.
7. Arthur J.D., Henry (Eds.) S.M., Baltzer J.C. AG, Using Artificial Neural Networks and Function Points to Estimate 4GL Software Development Effort// Australian Journal of Information Systems №1,1994.
8. Barry W. Boehm, Chris Abts. Cocomo II Model Definition Manual (http://sunset.usc.edu/research/ COCOMOII)
9. Barry W. Boehm, Chris Abts, Sunita Chulani. Software Development Cost Estimation Approaches — A Survey. University of Southern California, IBM Research. (http://sunset.usc.edu/publications/ TECHRPTS/2000/usccse2000-505/usccse2000-505. pdf)
10. Barry W. Boehm. Software Engineering Economics. Prentice Hall, 1981.
11. Bernstein L. Strategic Evolution of ESE Data § Systems (SEEDS) Survey of Cost Estimation Tool. | 2001. (http://guinness.cs.stevens-tech.edu/~lbernste/ >2 papers/Cost_EstimationTools.doc ) ^
12. Boehm B, ClarkB, Horowitz E, WestlandC, MadachyR., SelbyR. Cost Models for Future. 1995.
13. BoehmB, ClarkB, HorowitzE, WestlandC, MadachyR., SelbyR. Software Life-cycle Processes: COCOMO 2.0. //Annals of Software Engineering Special Volume on Software Process and Product, 1995.
14. Caliber Programmer Guide. Borland, 2005. (http://www.borland.com)
15. Capers J. Feature Points (Function Point Logic for Real Time and System Software) // IFPUG Fall 1988 Conference. Montreal: QuEbec, 1988.
16. Capers Jones. Software Estimating rules of thumb. 2007. (http://www.itmpi.org/default.aspx? pageid=197)
17. Kostas Kavoussanakis, Terry Sloan. UKHEC Report on software estimation. The University of Edinburgh. (http://www.epcc.ed.ac.uk/)
18. Nelson E.A. Management Handbook for the Estimation of Computer Programming Costs. Systems Development Corp., 1966.
19. Park. R. The Central Equations of the PRICE Software Cost Model // 4th COCOMO Users' Group Meeting. 1988.
20. Putnam L., Myers W. Measures for Excellence, Yourdon Press Computing Series, 1992.
21. Sunita Devnani-Chulani. Incorporating Baye-sian Analysis to Improve the Accuracy of COCOMO II and its Quality Model Extension. University of Southern California Center for Software Engineering Computer Science Department, 1998.
22. Symons C.R. Function Points Analysis: Difficulties and Improvements // IEEE Transactions on Software Engineering. 1988. №1.
23. Symons C. R. Software Sizing and Estimating Mk II Function PointAnalysis. John Wiley & Sons, 1991.
24. The COCOMO 2.0 Software Cost Estimation Model (http://sunset.usc.edu/research/COCOMOII/ Docs/ispa95.pdf)
25. Wittig G. Estimating Software Development Effort with Connectionist Models. Monash University, 1995.
26. Wolverton R. W. The Cost of Developing Large-Scale Software // IEEE Transactions on Computers. 1974. №6.
