Моделирование стоимости разработки проектов в ИТ-компаниях тема диссертации по экономике, полный текст автореферата

Автореферат диссертации по теме "Моделирование стоимости разработки проектов в ИТ-компаниях"

и

На правах рукописи

ГЛАЗОВА МАРИЯ АЛЕКСАНДРОВНА

МОДЕЛИРОВАНИЕ СТОИМОСТИ РАЗРАБОТКИ ПРОЕКТОВ В ИТ-КОМПАНИЯХ

Специальность 08.00.13 - «Математические и инструментальные методы

экономики»

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата экономических наук

Москва - 2008

003449021

Работа выполнена в Московском государственном университете экономики, статистики и информатики (МЭСИ) на кафедре математического обеспечения и администрирования информационных систем.

Научный руководитель: кандидат экономических наук, доцент

Грибанов Владимир Петрович

Официальные оппоненты: доктор экономических наук, профессор

Защита диссертации состоится «30» октября 2008 г. в 14 часов на заседании диссертационного совета Д 212.151.01 в Московском государственном университете экономики, статистики и информатики по адресу: 119501, г. Москва, ул. Нежинская, 7.

С диссертацией можно ознакомиться в библиотеке Московского государственного университета экономики, статистики и информатики.

Автореферат разослан «*/<£_» С&с/ь-Л'с^Л 2008 г.

Емельянов Александр Анатольевич

кандидат экономических наук, доцент

Голкина Галина Евгеньевна

Ведущая организация:

ЗАО ЛАНИТ

Ученый секретарь диссертационного совета

Общая характеристика работы

Актуальность темы. В эпоху быстро развивающихся информационных технологий, растущего числа высоко бюджетных проектов в области разработки программного обеспечения, очень важным становится умение оценить на ранних этапах возможные выгоды и убытки от проекта, проанализировать возможные сценарии развития событий. По статистике примерно четверть всех начатых проектов завершается своевременно, четверть отменяется, и около половины всех проектов завершается с превышением бюджетных затрат или с опозданием. Согласно ежегодно публикуемому обзору группы The Standish Group в среднем превышение сроков составляет порядка 120%, а затрат - около 100%'. Реальная оценка может быть еще менее оптимистичной, так как у части завершенных с превышением сроков и стоимости проектов оказываются частично урезанными те функции, которые были описаны в первоначальном проекте.

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

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

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

• при принятии решения относительно инвестиций в программный проект;

• при осуществлении контроля за бюджетом и расписанием проекта;

• при принятии решения по рискам, связанным со стоимостью проекта и графиком работ;

• при принятии решения относительно повторного использования кода, модификации кода и системной интеграции;

' Макконнелл С. Сколько стоит программный проект. - М «Русская Редакция», Спб Питер, 2007 С 44

• при разработке стратегии улучшения, повышения зрелости процессов внутри организации.

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

Степень научной проработанности темы. На настоящий период времени выполнено достаточно большое количество исследований в области моделирования оценки стоимости. В основном эти исследования проводятся университетами США и Европы.

Наиболее значимые результаты исследований отражены в работах Нельсона (одно из первых исследований в области оценки стоимости), Волвертона (модель Волвертона), Барри Боэма, Суниты Девнани-Чулани (модель СОСОМОII), Лоуренса Путнама (концепция функциональных точек, модель SLIM), Каперса Джонса (система Checkpoint), Ф.Фреймэна(модель PRICE-S).

Классификация моделей оценки стоимости, методы калибровки систем оценки стоимости приведены в трудах Суниты Девнани-Чулани, Костаса Каву-санакиса, Терри Слоана.

Описание современных существующих программных продуктов по оценке стоимости приведено в работе Джины Кингстон и Мартина Бурка.

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

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

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

Для достижения цели диссертационного исследования поставлены и решены следующие задачи:

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

2. Обобщение и выработка требований, предъявляемых к современным программным средствам по оценке стоимости.

3. Оценка существующих продуктов на соответствие заданным требованиям.

4. Выбор модели на основе которой будет разрабатываться новое программное средство по оценке стоимости.

5. Определение путей по улучшению модели оценки стоимости с целью повышения точности оценок, доработка существующей модели, проверка ее работоспособности.

6. Разработка нового программного средства с учетом всех выработанных требований на основе доработанной модели.

7. Расчет экономической эффективности от внедрения созданного программного продукта.

Объект исследования. Объект исследования - модели оценки стоимости и программные продукты, построенные на их основе.

Предмет исследования. Предмет исследования - процесс моделирования оценки стоимости программного проекта.

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

В ходе проектирования системы оценки стоимости применялись методы множественного регрессионного анализа, пакеты математического моделирован™.

В качестве инструментальных средств исследования применялись современные системы управления базами данных, программные средства, разработанные автором, пакеты программ проектирования и программирования.

В качестве исходных данных для проверки корректности разработанной системы оценки стоимости использовались исторические (архив данных по выполненным проектам) и текущие данные по проектам ЗАО «Системы автоматизированного управления».

Научная новизна. Научная новизна исследования заключается в разработке единого набора требований для моделей оценки стоимости и программных продуктов по оценке стоимости, с целью упрощения процесса выбора близкой к оптимальной модели для нужд ИТ-предприятия; в усовершенствовании модели СОСОМОII с целью повышения точности оценок; в разработке качественно нового программного продукта для автоматизации получения оценок стоимо-

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

Кроме того, получены следующие результаты, имеющие элементы научной новизны:

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

• произведен анализ рынка программных продуктов по оценке стоимости, отмечены наиболее значимые продукты, произведен их сравнительный анализ, выделены сильные и слабые стороны;

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

• определены пути решения проблемы низкой точности оценок с помощью моделей оценки стоимости, произведена алгоритмизация процесса улучшения модели;

• проведена апробация решений по улучшению модели СОСОМО II на фактических данных, сделан сравнительный анализ оценок, полученных при помощи модели до и после доработки, подсчитан процент ошибок и выполнена оценка точности доработанной модели;

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

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

Были сформулированы требования, предъявляемые к системам оценки стоимости, предназначенным для использования на крупных предприятиях-разработчиках программного обеспечения. На основе этих требований предприятия могут выбрать продукт для оценки, разработать собственную систему, доработать существующие с учетом приведенных замечаний.

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

Были сформулированы пути и методы улучшения модели оценки стоимости в случае недостаточной точности оценок; проведена доработка используемой в

разработанной системе модели СОСОМО II, с учетом новых тенденций в процессах разработки программного обеспечения, появившихся за последние годы, и не учитывавшихся в классической модели СОСОМО II. Благодаря новой улучшенной модели COCOMO-PJ - точность оценок существенно возросла, что позволяет предприятиям моделировать стоимость с высокой степенью уверенности в полученных результатах. Кроме того, поскольку процесс улучшения модели и оценки точности был автоматизирован, модель легко можно использовать практически на любом предприятии-разработчике программного обеспечения с учетом особенностей процессов внутри данного предприятия.

Результаты работы были апробированы и используются в реальных условиях ИТ-среды, в ЗАО «Системы автоматизированного управления», основным видом деятельности которого является разработка профессионального программного обеспечения, в качестве инструментария для прогнозирования стоимости проектов, для анализа изменений стоимости и длительности в результате возможных изменений параметров проекта.

Публикации. По теме исследования опубликовано 4 работы, общим объемом 2,1 пл.

Структура работы. Диссертационная работа состоит из введения, трех глав, заключения, списка литературы и приложений. Общий объем работы составляет 154 страницы. Диссертация содержит 5 приложений, 39 таблиц и 15 рисун-' ков. Список использованной литературы состоит из 102 наименований.

Основные положения диссертации

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

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

Согласно определению международной веб-энциклопедии NationMaster, модель оценки стоимости - это математический алгоритм, используемый для того, чтобы оценить стоимость продукта или проекта.

История исследований в области оценки стоимости программных проектов берет свое начало в 1965-1966 годах, с опубликования труда Нельсона «Настольная книга по управлению оценкой стоимости затрат на программирование». Книга содержала результаты статистического анализа затрат и факторов затрат, характеризующих процессы разработки, а также расчеты по оценке трудозатрат. Публикация привела к появлению ряда других работ в этом направлении, и в конце 60-х - начале 70-х появились первые модели оценки - Delphi, Wolverton, а также была разработана новая концепция функциональных точек, которая позволила оценивать сложность и предполагаемый размер программ-

ного продукта на ранних стадиях разработки. В 1977 году вышел первый коммерческий программный продукт по оценке стоимости, получивший название PRICE-S. Вслед за ним появились система SLIM, SEER, Estimacs и ряд других.

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

Исследования продолжили активно развиваться, совершенствуя уже существующие модели и программные продукты с одной стороны, и создавая новые с другой.

Направления оценки стоимости программного обеспечения можно поделить на несколько категорий:

1. Методы оценки, основанные на моделях - имеют в качестве своего ядра математическую модель, на основе которой, в соответствии с входными параметрами, полученными от проекта, вычисляется его стоимость.

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

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

4. Динамические методы оценки используют динамику изменения таких показателей как затраты, навыки, усилия для расчета стоимости проекта.

5. Регрессионные методы, используются в сочетании с методами оценки, основанными на моделях и включают стандартную регрессию, робаст-ную регрессию и т.п.

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

На основе анализа существующих моделей оценки были определены четыре модели - SEER-SEM и СОСОМО И, SLIM и PRICE-S - наиболее полно удовлетворяющие выделенным требованиям:

• поддержка разных метрик подсчета размера программного кода;

• учет в расчетах атрибутов программы, таких как сложность, язык программирования, повторное использование и надежность;

• поддержка атрибутов аппаратного обеспечения: ограничения производительности и устойчивость платформы;

• поддержка факторов персонала: возможностей, опытности и текучести кадров;

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

• учет в расчетах таких этапов проекта как: начало работ, разработка проекта, создание программного продукта и его техническое сопровождение.

В ходе исследования были рассмотрены наиболее крупные представители систем по оценке стоимости программных проектов: SUM Tools, KnovvledgeP-lan и Charismatek's Function Point WORKBENCH™ (FPW), Cost XPert, Borland CaliberRM, На основании анализа их функциональных возможностей автором были выработаны требования к программному продукту по оценке стоимости, исходя из потребностей современных ИТ-предприятий. Согласно этим требованиям, продукт должен обеспечивать:

• ввод, хранение с полной историей изменений и возможностью повторного использования информации по проектам и оценкам проектов;

• возможность гибкого, наглядного предоставления выходной информации по результатам оценок и сравнительного анализа;

• возможность прогнозирования, анализа «что если»;

• учет в оценке разных языков программирования, методов оценки величины программного кода, разных моделей жизненного цикла;

• возможность подстройки системы под нужды конкретного предприятия;

• наличие системы разграничения доступов пользователей по проектам оценки и операциям;

• возможность совместной работы группы пользователей над одним проектом в рамках системы;

• возможность двухстороннего взаимодействия с системой управления проектами.

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

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

• наличие механизма анализа расхождений между оценочными и фактическими данными.

Реализация выделенных требований в полном объеме в одном программном продукте позволило разработать удобное средство для получения точных

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

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

В качестве основы новой системы выбрана модель СОСОМО II, как наиболее полно отвечающая требованиям к моделям оценки стоимости.

Модель СОСОМО II поддерживает разные модели жизненного цикла, языки программирования и методики подсчета размера программного кода, может использоваться на разных этапах жизненного цикла разработки.

Всего в модели СОСОМО II используется три способа оценки размера программного продукта: объектные точки, функциональные точки и количество строк кода.

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

Определение термина «строка кода» имеет определенные сложности, поскольку подсчет исполняемых элементов в разных языках программирования сильно различается в связи с особенностями объявления переменных, конструкций языка и т.п. В модели СОСОМО II в качестве единицы строки кода были выбраны логические строки кода (то есть строки кода, которые несут в себе конкретную операцию или выражение, что позволяет учесть особенности языка), в отличие от физических строк кода, которые являются элементами для подсчета суммарного количества строк без учета операций).

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

Модель СОСОМО II существует в трех видах. Выбор того или иного вида модели для оценки стоимости программного обеспечения зависит от типа проекта и стадии разработки.

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

Модель раннего проектирования включает в себя изучение альтернативных архитектур и концепций работы. На этой стадии недостаточно общего опи-

сания проекта, требуются детали. Это включает в себя использование функциональных точек и небольшое количество дополнительных факторов затрат.

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

Основные уравнения модели выглядят следующим образом: Уравнение СОСОМОII для модели композиции приложения:

иьл N0P

РМ =--(1 \

PROD ^

РМ - длительность работы в человеко-месяцах.

NOp=OP'( 100-reuse) (2) 100

OP - количество объектных точек, reuse- процент повторного использования кода. PROD - уровень продуктивности, определяется по рейтинговой шкале.

Уравнение СОСОМО II для модели раннего этапа проектирования:

Затраты = А х Размерв х Ме + Затратыашо [чел. - мес.] (3)

Затратыац1о - отражает затраты на код, генерируемый программой автоматически.

Затраты - итоговые затраты по проекту в человеко-месяцах.

Размер - размер программного кода в строках.

Ме - множитель поправки, который состоит из множества факторов формирования затрат, количество которых варьируется от типа модели.

Ме определяется по формуле:

Ме=П£М,; (4)

1=1

ЕМ, - числовое значение i-ro фактора формирования затрат, характеризующего ситуацию на проекте.

В - объединенный фактор издержек масштаба;

А - коэффициент масштаба, являющийся константой, определенной разработчиками модели (для модели СОСОМО II калибровки 2000 года это значение равно 2,94).

С ростом размера проекта число коммуникационных путей связи между сотрудниками растет в квадратичной зависимости от количества участников проекта. Следствием экспоненциального роста количества коммуникационных каналов (наряду с другими факторами) является экспоненциальный рост трудоемкости с увеличением размера проекта. Данное явление называется издержками масштаба, а факторы влияния - факторами издержек масштаба проекта.

B = 0,91 + 0,01YjWi (5)

W, - факторы, составляющие объединенный фактор издержек масштаба: предсказуемость, гибкость среды разработки, риск архитектуры, связность команды и зрелость процесса. Уравнение СОСОМОIIдля модели этапа пост-архитектуры:

Затраты = А х КК1/ х Размер 3 х М£ + Затраты аШ0[чел. - мес.] (6) Kreq - коэффициент, который отражает вероятность того, что могут измениться требования к разрабатываемому программному продукту.

, BRAK

"нйГ (7>

BRAK - процент кода, который приходится исключать/изменять из-за корректировки требований.

17

Ме - множитель поправки.

ЕМ, - числовое значение i-ro фактора формирования затрат, характеризующего ситуацию на проекте. Факторы формирования затрат делятся на 4 группы:

1. Факторы продукта.

2. Факторы платформы.

3. Факторы персонала.

4. Факторы проекта.

К первой группе - факторы продукта - можно отнести следующие факторы:

1. Требуемая надежность программного обеспечения (RELY).

2. Размер базы данных (DATA).

3. Сложность продукта (CPLX).

4. Требуемое повторное использование кода (RUSE).

5. Соответствие документации потребностям на каждом этапе жизненного цикла (DOCU).

К факторам платформы относятся:

1. Ограничения по времени исполнения операции (TIME).

2. Ограничения по объему хранилища (STOR).

3. Изменчивость платформы (PVOL). К факторам персонала относятся:

1. Возможности аналитиков (АСАР).

2. Возможности программистов (РСАР).

3. Опыт работы с приложением (АЕХР).

4. Опыт работы с платформой (РЕХР).

5. Опыт работы с языком и инструментарием программирования (LTEX).

6. Текучесть персонала (PCON). К факторам проекта относятся:

1. Использование программных утилит (TOOL).

2. Территориальный разброс проектной команды (SITE).

3. Требуемый график разработки (SCED).

В модели раннего этапа проектирования используются обобщенные факторы затрат:

1. Возможности персонала (PERS) - обобщенный фактор затрат АСАР, РСАР, PVOL.

2. Надежность и сложность разработки (RCPX) - обобщенный фактор затрат RELY, DATA, CPLX, DOCU.

3. Повторное использование (RUSE) - соответствует фактору заграт RUSE.

4. Трудность платформы (PDIF) - обобщенный фактор затрат TIME, STOR, PVOL.

5. Опытность персонала (PREX) - обобщенный фактор затрат АЕХР, РЕХР, LTEX.

6. Средства поддержки (FCIL) - обобщенный фактор затрат TOOL, SITE.

7. График (SCED) - соответствует фактору затрат SCED.

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

Стоимость = Затраты X Рабочий коэффициент (9) Среднее значение рабочего коэффициента составляет 15000.

Если модель, применяемая в заданной предметной области, не выдает результатов приемлемой точности (для анализа точности используется подсчет процента оценок, которые попадают внутрь 30%, 25% и 20% фактических значений. Значения, большие 80% считают удовлетворительными, 60-80% - приемлемыми, ниже 60% - недостаточными), то у менеджера проекта возникает выбор, что делать в сложившейся ситуации. Есть три пути решения:

1. Разработка принципиально новой модели. Является наиболее ресурсоемким, требует большого количества проектов для проверки корректности модели. Используется только в том случае, если специфика отрасли очень существенно отличается от той, в которой применялись существующие модели оценки.

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

3. Калибровка модели. Наименее ресурсоемкий процесс, но при небольшом количестве данных не гарантирует точность и улучшения результатов. Применяется для подстройки модели под нужды конкретного предприятия. Калибровка может производиться тремя способами:

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

b) путем множественного регрессионного анализа. Это означает, что с помощью определенных преобразований при наличии достаточно

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

1. Имеется рейтинговая шкала значений фактора. Это априорная модель.

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

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

Г«ы = (Fpr0)fot, (10)

где Fdd- значение фактора, основанное на данных.

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

4. Проводится преобразование данных для получения апостериорной модели. Чтобы новые значения факторов были в достаточной степени точны, необходимо взять некоторое значение, полученное на основе экспертной оценки и преобразованных фактических данных. Для этого используется подход 10% взвешенного среднего, разработанный Барри Боэмом. Он заключается в том, что для получения новых значений факторов берется 90% значения экспертной оценки и 10% фактических данных. Боэм обосновывает выбор именно такого соотношения сравнением данных, полученных на основе экспериментов с соотношениями процентов 40-60 и 25-75 - они получались

гораздо менее точными. В общем виде формула выглядит следующим образом:

^ = 0.9 + ^X0.1 О1)

где Рр05( - апостериорное значение фактора, значение фактора, основанное на данных.

Рргв - значение фактора, основанное на экспертной оценке.

В целом, критерии того, насколько хорошо модель предсказывает затраты, применительно к СОСОМО II выглядят следующим образом:

• Аф-Я2 показывает пропорцию изменений, описываемых в модели. Он, наряду со среднеквадратическим отклонением дает информацию о том, насколько точно модель подходит для описания проекта.

4 \n-k~ г)к 5:¡Lt(5a^OTJыacrsЗWíal™ыtЛ)f-,' 4 '

• среднеквадратическая ошибка (ЕягЗЕ). Критерий показывает разброс в

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

(^(Затратьг^-Затрать.

• РЯЕО(Ь) - это процент значений оценки, которые оказались внутри Ь процентов фактических значений. Например, РКЕВ(0.25) отражает процент оценок, которые были внутри 25% фактических значений. Это значение зависит от значения ошибок.

, ч юо V-«

1-1

Затраты„г - Затраты,,^, п

1'"СЛВ-Ззтратьгасс,-'^100 (14)

0

РЕ ■

пропорциональная ошибка (РЕ) - это мера измерения ошибок, используемая для расчета Р11ЕО(Ь). С ростом размера проектов, растет и количество оценок, и разница между фактическими затратами и моделируемыми затратами нормализуется к размеру проекта. Следующее выражение демонстрирует данную нормализацию:

' [Затраты^ Затраты ^^ - 1, (затра>ше11 - Затратыас|.) >0 (¡5) -[Затраты^-?-Затраты^] +1, (Затраты^ - Затраты аи) < 0

где Затрата^,Затраты1 - фактическое значение затрат по проекту

(¡-му проекту).

Затраты - предсказываемое значение затрат по проекту.

Затраты - среднее значение затрат.

л - количество наблюдений. к - количество факторов.

Для проверки работоспособности программного средства и корректности оценки с помощью модели СОСОМО II был проведен сравнительный анализ оценочных данных и фактических по 40 проектам, с расчетом показателя РЮЮ для определения процента оценок, которые были бы внутри 30%, 25% и 20% фактических значений. Точность модели определена как недостаточная (всего 45% оценок оказались внутри 20% фактических значений). Частично причиной этого мог служить тот факт, что СОСОМО II была построена в 1997 году, для нее была произведена калибровка в 2000 году, и с тех пор прошло достаточно много времени, в течение которого технологии разработки программного обеспечения изменились, и появились новые факторы, которые следует принимать в расчет при прогнозировании стоимости. Поэтому принято решение о добавлении новых факторов и проведении калибровки.

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

В уже существующие группы факторов формирования затрат добавлены: Факторы продукта

1. Требуемый уровень безопасности, защиты программного обеспечения от взлома.

2. Требуемый уровень эргономики.

3. Необходимость перевода интерфейса на другие языки. Факторы персонала

1. Возможности (квалификация и качество работы) тестировщиков.

2. Возможности (квалификация и качество работы) документалистов.

3. Возможности (квалификация и качество работы) проектировщиков.

Практическая эксплуатация модели показала, что недостатком СОСОМО II

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

1. Возможность изменения затрат.

2 Недоступность ресурсов.

3. Влияние со стороны внешних подразделений.

4. Влияние со стороны рынка.

5. Влияние со стороны заказчика.

6. Влияние государства/законодательства.

Описание факторов приведено в таблице 1.

Таблица 1

___Новые факторы формирования затрат_

Наименование фактора Обозначение Описание

Требуемый уровень безопасности 5ЕСЯ Отражает, насколько серьезные доработки по безопасности нужны в системе, насколько важным эю является для системы. Номинальный уровень означает, что дополнительных доработок не требуегся, сверхвысокий- что фактор безопасности очень важен, требуются доработки и возможно дополнительная сертификация

Требуемый уровень эргономики Е1ЮО Определяет, насколько ключевым является понятие эргономики для системы. Важно ли для пользователя удобство использования, или же при разработке необходимо сделать упор на функциональность Номинальный уровень означает, что дополнительных доработок, проверок по эргономике не требуегся Сверхвысокий уровень означает, что эргономика важна, проводится полное тестирование на соответствие эргономическим требованиям.

Необходимость перевода ТЯБЬ Определяет, делается ли локализация системы на другие языки в ходе разработки Номинальный уровень означает, что перевода не требуется. Сверхвысокий уровень означает, что требуется перевод как интерфейса, так и документации, птюс доработка программы с учетом друшх размеров шрифтов, особенностей языка и т н

Возможности тестировщиков ТСАР Отражает квалификацию тестировщиков проекта Очень низкий уровень означает отсутствие опыта, очень высокий — большой опыт работы, знание системы, возможность локализации ошибок, вынесение предложений по их исправлению.

Возможности документалистов ПСЛР Отражает квалификацию документалистов проекта Очень низкий уровень означает отсутствие или небольшой опьгт в данной области Очень высокий уровень означает отличное знание системы, большой опыт работы

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

Возможность изменения затрат ССШ Отражает вероятность изменения затрат в ходе работы над проектом, сокращение финансирования Номинальный уровень означает малую вероятность изменения затрат на проект Сверхвысокий уровень означает высокую вероятность изменения затрат

Наименование фактора Обозначение Описание

Недоступность ресурсов RCON Определяет вероятность недоступности ресурсов в ходе работы над проектом, не выделение нужного ресурса, отсутствие ресурса Номинальный уровень означает малую вероятность возникновения проблемы недоступности ресурса. Очень высокий уровень означает высокую вероятность того, что ресурс станет недоступным

Влияние со стороны внешних подразделений DEXT Отражает вероятность влияния на проект внешних подразделений. борьба за бюджеты, сотрудников или же наоборот содействие Очень низкий уровень означает отрицательное влияние, очень высокий - положительное

Влияние со стороны рынка МЕХТ Отражает вероятность влияния на проект со стороны рынка, появление новых конкурентов, изменение ценовой политики. Очень низкий уровень означает отрицательное влияние, очень высокий - положительное.

Влияние со стороны заказчика СЕХТ Отражает вероятность влияния на проект со стороны заказчика' сокращение бюджета, изменение условий Очень низкий уровень означает отрицат сльнос влияние, очень высокий -положительное

Влияние госу-дарст- ва/законодател ьства QEXT Отражает вероятность влияния на проект со стороны государства, законодательства Очень низкий уровень означает отрицательное влияние, очень высокий - положительное

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

В качестве априорной модели для уже существующих факторов была выбрана модель СОСОМО II, откалиброванная в 2000 году. Для калибровки модели с новыми факторами - COCOMO-PJ был проведен регрессионный анализ на основе данных по 56 проектам, хранившимся на данный момент в системе управления проектами в ЗАО «Системы автоматизированного управления». Проекты были отобраны по возможности в наибольшей степени различные друг от друга с целью получения наиболее точных результатов, на которые бы не повлияла схожесть ряда проектов. Регрессионный анализ проводился с помощью пакета Arc, программного средства для статистического анализа. На основе полученных оценок была построена модель, основанная на фактических данных.

С помощью метода 10% взвешенного среднего на основании полученных результатов была построена апостериорная модель.

Для проверки новой модели были использованы те же 40 проектов, по которым производилась оценка с помощью оригинальной модели СОСОМО II.

На основании данных по расхождениям была произведена оценка показателя PRED для определения процента оценок, которые были бы внутри 30%, 25%,

20% и 10% фактических значений. Результаты оценки скорректированной модели отражены в таблице 2. Рядом с ними для сравнения приведены результаты оценки по первоначально построенной общей модели СОСОМО II.

Таблица 2

Оценка PRED но СОСОМО II и COCOMO-PJ

PRED Модель СОСОМО II Модель COCOMO-PJ

PRED(15) 32,50% 92,50%

PRED(20) 45% 95%

PRED(25) 60% 95%

PRED(30) 65% 95%

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

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

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

Клиентская часть системы оценки стоимости написана в среде визуального проектирования с элементами объектно-ориентированного программирования Oracle Forms 6 на языке программирования PLASQL. Серверная часть реализована в виде объектов Oracle (пакетов, таблиц, последовательностей, индексов) версии 9.2. Пакеты также написаны на языке программирования PL\SQL.

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

Система оценки стоимости программного проекта включает в себя несколько подсистем:

1. Подсистема справочников. Подсистема содержит все основные термины, списки, используемые при оценке. Это позволило поддержать мультия-

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

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

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

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

5. Подсистему разграничения доступов. Подсистема содержит настройки доступности операций пользователей системы по тем или иным проектам.

6. Подсистему калибровки. Подсистема включает в себя серверные пакеты, предназначенные для калибровки факторов модели с целью увеличения точности оценки.

Функции разработанной системы оценки стоимости разделяются по признаку подсистемы, которая их использует:

• функции подсистемы разграничения доступов;

• функции подсистемы хранения и анализа;

• функции подсистемы справочников,•

• функции подсистемы настройки;

• функции подсистемы оценки стоимости;

• функции подсистемы калибровки.

Функции подсистемы разграничения доступов разделяются на три вида:

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

• Функции ведения доступных ролям операций. Данные функции позволяют определять состав роли - какие операции будут доступны для той или иной роли.

• Назначение ролей сотрудникам. Данные функции позволяют администратору назначить ранее созданную роль определенному сотруднику применительно к определенному проекту.

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

• ведение информации по проектам оценки. Данная функция позволяет сохранять общие характеристики проекта оценки.

• Ведение информации по факторам проекта. Данная функция позволяет вносить данные по всем факторам проекта, что в дальнейшем будет использоваться для анализа.

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

• Ведение информации по объектам проекта. Данная функция позволяет произвести классификацию объектов проекта и описать их основные характеристики.

• Ведение информации по оценке в объектных точках. Данная функция позволяет оценить объект проекта в объектных точках и сохранить результат для дальнейшего использования.

• Ведение информации об оценке в элементах (функциональных точках). Данная функция позволяет оценить объект проекта в элементах и сохранить полученный результат.

• Ведение информации об оценке в строках кода. Данная функция позволяет оценить объект проекта в количестве строк кода.

Функции подсистемы справочников можно разделить на виды:

• добавление данных;

• корректировка данных;

• удаление данных;

• поиск данных.

Функции подсистемы настройки можно разделить на следующие виды:

• настройка факторов;

• настройка мультипликаторов;

• настройка объектных точек;

• настройка элементов (функциональных точек);

• настройка весов объектов;

• ведение общей схемы настроек, связи настроек и проектов;

• настройка механизмов пересчета количества строк кода в функциональные точки.

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

Функции подсистемы оценки стоимости можно разделить на следующие виды:

• моделирование оценки стоимости.

Данная группа функций позволяет произвести моделирование оценки стоимости программного проекта на основе полученной информации.

• анализ «что если».

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

• сравнительный анализ проектов.

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

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

• подстройка в соответствии с расхождениями.

Эти функции позволяют на основе полученного анализа расхождений произвести подстройку характеристик модели СОСОМО II под нужды конкретного предприятия.

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

Был проведен анализ экономической эффективности от внедрения системы оценки стоимости на предприятии. Результаты показали, что проект окупится за весьма короткое время, и что он позволит значительно уменьшить затраты предприятия при разработке программных проектов. Согласно проведенным

расчетам, при внедрении проекта трудовые затраты уменьшатся в 3,95 раза, а стоимостные затраты уменьшатся в 4,17 раза.

Программное обеспечение было внедрено в ЗАО «Системы автоматизированного управления» и успешно используется в качестве инструментария для моделирования оценки стоимости.

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

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

Основные результаты и выводы настоящего исследования заключаются в следующем:

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

2. Выработаны требования, предъявляемые к программному продукту оценки стоимости с тем, чтобы он соответствовал современным требованиям предприятий.

3. Разработаны предложения по улучшению моделей оценки стоимости с целью повышения точности оценок.

4. Осуществлена доработка и калибровка модели СОСОМО II для увеличения точности оценок по проектам; проведена проверка работоспособности обновленной модели и подтверждена правильность сделанной корректировки

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

6. Произведено внедрение продукта на предприятии; проверена корректность оценок с помощью используемой в нем модели СОСОМО II.

7. Оценена экономическая эффективность от внедрения системы оценки стоимости на предприятии для определения необходимости и обоснованности ее использования.

¡C ^

По теме диссертации опубликованы следующие работы:

В изданиях, рекомендованных ВАК•

1. Грибанов В.П., Глазова М.А. Оценка стоимости проектов: программный инструментарий //Открытое образование, №5,2008 (0,5 п.л.).

В других изданиях.

1. Глазова М.А. Моделирование оценки стоимости как средство улучшения качества управления проектами на предприятии // XI научно-практическая конференция «Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями» (РБП-СУЗ-2008): Сборник научных трудов. - М.: МЭСИ, 2008 (0,2 п.л.).

2. Глазова М.А. Модель СОСОМО II. Анализ и пути усовершенствования // Экономика, статистика и информатика. Вестник УМО, №3, 2008 (0,4 п.л.).

3. Глазова М.А. Системы оценки стоимости проектов по разработке программного обеспечения // Прикладная информатика, №6,2008 (1 п.л.).

4. Грибанов В.П., Глазова М.А. Проблема оценки моделирования затрат в разработке программного обеспечения // Сборник научных статей. - М.: Компания Спутник+, 2004 (0,4 п.л.).

Подписано к печати 24.09.08

Формат издания 60x84/8 Бум. офсетная №1 Печать офсетная

Печ.л. 1,5 Уч.-изд.л. 1,4 Тираж 100 экз.

Заказ № 7704

Типография издательства МЭСИ. 119501, Москва, Нежинская ул., 7

Диссертация: содержание автор диссертационного исследования: кандидата экономических наук, Глазова, Мария Александровна

Введение.

Глава 1. Исследование моделирования оценки стоимости программных проектов.

1.1. История развития моделирования оценки стоимости программных проектов.

1.2. Основные направления оценки стоимости.

1.2.1. Модель SLIM.

1.2.2. Модель Checkpoint.

1.2.3. Модель SEER.

1.2.4. Модель СОСОМО.

1.2.5. Методика Госкомтруда.

1.2.5. Модель Delphi.

1.2.6. Оценка по структуре работ.

1.2.7. Case модель.

1.2.8. Нейронные сети.

1.2.9. Динамические модели.

1.2.9. Регрессионные модели.

1.2.10. Композитные техники.

1.3. Сравнительный анализ методов оценки стоимости.

1.4. Программная реализация моделей оценки стоимости.

1.4.1. SLIM Tools.

1.4.2. KnowledgePlan и Charismatek's Function Point WORKBENCH™ (FPW).

1.4.3. Cost XPert.

1.4.4. Borland CaliberRM.

1.4.5. Другие программные продукты оценки стоимости.

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

Выводы по главе 1.

Глава 2. Проектирование системы оценки стоимости программного проекта.

2.1. Задачи, решаемые системой оценки стоимости.

2.2. Описание модели СОСОМО П.

2.2.1. Общее описание модели.

2.2.2. Способы оценки размера программного кода.

2.2.2.1. Объектные точки.

2.2.2.2. Строки кода.

2.2.2.3. Функциональные точки.

2.2.3. Факторы влияния на проект в СОСОМО П и уравнение модели на разных этапах.

2.3. Пути улучшения моделей оценки стоимости.

2.3.1. Разработка новой модели.

2.3.2. Добавление новых факторов в модель.

2.3.3. Калибровка модели.

2.4. Проверка и корректировка модели СОСОМО П.

2.5. Исследование структуры и состава информационных потоков.

2.5.1. Информационная модель.

2.6. Программное обеспечение задачи.

2.6.1. Общие положения (дерево функций и сценарий диалога).

2.6.1.1. Функции подсистемы разграничения доступов.

2.6.1.2. Функции подсистемы хранения и анализа.

2.6.1.3. Функции подсистемы справочников.

2.6.1.4. Функции подсистемы настройки.

2.6.1.5. Функции подсистемы оценки стоимости.

2.6.1.6. Функции подсистемы калибровки.

2.6.1.7. Сценарий диалога системы.

2.6.2. Особенности программного продукта.

Выводы по главе 2.

Глава 3. Практическое применение системы оценки стоимости.

3.1. Пример расчета оценки стоимости программного проекта с помощью моделей

СОСОМО П и COCOMO-PJ.

3.2. Расчет оценки стоимости программного проекта с помощью системы оценки стоимости.

3.3. Расчет экономической эффективности и результаты внедрения проекта.

Выводы по главе 3.

Диссертация: введение по экономике, на тему "Моделирование стоимости разработки проектов в ИТ-компаниях"

В эпоху быстро развивающихся информационных технологий, растущего числа высоко бюджетных проектов в области разработки программного обеспечения, очень важным становится умение оценить на ранних этапах возможные выгоды и убытки от проекта, проанализировать возможные сценарии развития событий. Ошибка, недооценка сложностей, с которыми предстоит столкнуться в процессе разработки, переоценка сил команды, просто непринятие в расчет тех или иных факторов, часто приводит к многомиллионным потерям, и даже банкротству компаний. По статистике примерно четверть всех начатых проектов завершается своевременно, четверть отменяется, и около половины всех проектов завершается с превышением бюджетных затрат или с опозданием. Согласно ежегодно публикуемому обзору группы The Standish Group в среднем превышение сроков составляет порядка 120%, а затрат — около 100%. Реальная оценка может быть еще менее оптимистичной, так как у части завершенных с превышением сроков и стоимости проектов оказались частично урезаны функции, описанные в первоначальном проекте.

В таблице 1 [22] приведена информация по наиболее серьезным ошибкам оценки, приведшим к закрытию проектов.

Таблица 1

Ошибки в оценках стоимости проектов

Проект Оценка Статус при завершении

Стоимость, млн. S Трудозатраты, мес.

Первая оценка Итоговая оценка Первая оценка Итоговая оценка

PROMS 12 более 21 22 46 Отменен, 28 месяц

Лондонская медицинская система 1,5 более 6 7 более 17 Отменен, 17 месяц

Лондонская биржа 60-75 150 19 70 Отменен, 36 месяц

Confirm (бронирование путешествий) 56 более 160 45 более 60 Отменен, 48 месяц

FAA 3700 более 7000 48 96 Отменен, 70 месяц

Master Net (банковская система) 22 более 80 9 более 48 Отменен, 48 месяц

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

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

Можно выделить следующие случаи, в которых может потребоваться использование модели оценки стоимости [22]:

• требуется определить, делать ли инвестиции, или принять иные финансовые решения, касающиеся разработки программного продукта;

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

• надо принять решение, чем стоит пожертвовать в данной ситуации -денежными затратами, временем, функциональностью, интерфейсом или качеством. Это важно, например, если надо определиться, что будет дешевле и выгоднее — разработать недорогую или же полнофункциональную, отвечающую всем стандартам качества программную систему;

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

• необходимо решить, какую часть программного обеспечения следует разработать, какую — повторно использовать, а какую приобрести у внешнего 5 производителя. Хорошая модель оценки стоимости позволит понять, что будет дешевле — разработать компоненту заново, приобрести ее, или же переработать уже существующую;

• требуется определить, какие части программного обеспечения модифицировать в первую очередь, какие убрать, на разработку каких назначить внешних исполнителей в случае разработки новой версии системы;

• ведется процесс разработки стратегии улучшения процессов внутри организации путем повторного использования кода, более совершенного инструментария для разработки, повышения зрелости процессов. Используя модель оценки, пользователь может оценить, какая стратегия будет максимально эффективной, а какая принесет минимум улучшений при большом количестве затрат.

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

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

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

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

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

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

Во второй главе приводится подробное описание выбранной модели оценки стоимости, которая стала основой для разрабатываемой системы оценки — СОСОМО П. Описываются возможные способы оценки размера программного кода - показателя, который используется ■ в модели, факторы влияния на проект в модели СОСОМО П. Рассматриваются возможные пути и алгоритмы улучшения моделей стоимости, процесс доработки модели и ее калибровки под предприятие, проводится сравнительный анализ результатов, полученных до и после улучшения модели. Для нового программного продукта по оценке стоимости проводится построение информационной модели, описываются функции, сценарий диалога, приводится краткое описание внутренней структуры.

В третьей главе исследования работы модели СОСОМО П на фактических данных предприятия. Приводится пример расчета оценки стоимости с помощью модели СОСОМО Л и доработанной модели - COCOMO-PJ. Обосновывается экономическая эффективность проекта, проводится расчет основных ее показателей.

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

Диссертация: заключение по теме "Математические и инструментальные методы экономики", Глазова, Мария Александровна

Выводы по главе 3

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

2. По результатам расчета экономической эффективности было определено, что при внедрении проекта системы оценки стоимости на предприятии трудовые затраты уменьшатся в 3,95 раза, а стоимостные затраты уменьшатся в 4,17 раза.

3. Программный продукт был внедрен и успешно используется в ЗАО «Системы автоматизированного управления» для моделирования оценки стоимости. По мере увеличения количества проектов в системе модель будет снова калиброваться и усовершенствоваться (программный продукт позволяет выполнить это достаточно просто), что позволит и дальше повышать точность оценок.

Заключение

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

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

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

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

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

Был проведен анализ результатов, полученных на основании использовании в системе настроек оригинальной модели СОСОМО П и их сравнение с полученными фактическими данными по проектам. Поскольку точность оценок оказалось недостаточной, модель была улучшена путем добавления новых факторов и проведения калибровки. На основании проверки модели на 40 проектах было определено, что точность оценок, полученных в ходе использования улучшенной модели, в значительной степени улучшилась.

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

В главе Ш диссертационного исследования была рассмотрена практическая значимость системы оценки стоимости. Был приведен пример оценки на разных этапах жизненного цикла, анализа «что если». Результаты были сопоставлены с фактическими оценками стоимости и длительности проекта. Наиболее точной получилась оценка на последней этапе - этапе пост-архитектуры. Далее был приведен пример работы непосредственно с системой оценки стоимости. В завершение был проведен анализ экономической эффективности от внедрения системы оценки стоимости на предприятии. Результаты показали, что проект окупится за весьма короткое время, и что он значительным образом позволит уменьшить затраты предприятия в области разработки программных проектов.

Поставленные задачи были успешно реализованы в программном продукте.

В качестве дальнейших путей по исследованию направления оценки стоимости можно выделить следующие:

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

• проведение калибровки и проверки точности модели COCOMO-PJ для этапа раннего проектирования;

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

В качестве путей дальнейшего развития разработанного программного продукта можно выделить следующие:

• расширение возможностей представления отчетной информации по историческим данным проектов, в различных срезах для анализа тенденций;

• расширение возможности по интеграции с другими программными продуктами оценки стоимости и управления программными проектами;

• расширение возможностей калибровки на основе межотраслевых данных по проектам, а не только на основе данных, хранимых на предприятии;

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

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