Главная | Обратная связь | Поможем написать вашу работу!

Алгоритмическое моделирование стоимости

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

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

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

затраты = А х размер^В х М,

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

Алгоритмическим моделям присущи общие проблемы.

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

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

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

На размер окончательной системы могут повлиять решения, которые были приняты в процессе реализации проекта уже после утверждения начальной сметы. Например, это может быть решение о том, использовать ли в создаваемом ПО, требующем сложной системы управления данными, базы данных сторонних производителей или разработать свои системы управления данными. Очевидно, что при использовании сторонних баз данных программный код, который следует создать, будет меньшего размера. Кроме того, имеет значение и язык программирования. Для таких языков, как Java, потребуется больше строк кода, чем если бы применялся, скажем, язык С. В то же время "лишний" код на языке Java потребует провести больше проверок программы в процессе компиляции, вследствие чего расходы на аттестацию системы наверняка снизятся. Чему в данном случае отдать предпочтение? Кроме прочего, также необходимо оценить объем повторного использования кода.

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

Рис. 23.1. Изменчивость оценивания затрат

Точность результатов прогнозирования себестоимости также зависит от количества информации о создаваемой системе. По ходу реализации проекта увеличивается количество информации, вследствие чего оценка себестоимости становится все более точной. Если при начальном оценивании временных затрат для разработки системы требовалось х месяцев, то реальная длительность выполнения проекта может колебаться от 0.25х до 4х. Однако этот диапазон постепенно сужается в процессе выполнения проекта, как показано на рис. 23.1. Эта схема была заимствована из статьи [44] и основана на опыте реализации многих проектов разработки программных продуктов.

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

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

* СОСОМО (от Constructive COst MOdel) - конструктивная стоимостная модель. - Прим. ред.

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

2. Модель популярна и ценится среди широкого круга пользователей.

3. Она прошла достаточно долгий путь развития со времени первого появления в 1981 году [46], была усовершенствована для разработки ПО на языке Ada [43], последняя версия модели опубликована в 1995 году [44].

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

Моделью СОСОМО 81 предусмотрена разработка программного обеспечения в соответствии с каскадной моделью, причем предполагается, что большая часть системы разрабатывается "с нуля". Однако со времени первой версии данной модели было сделано несколько фундаментальных изменений в целях ее усовершенствования. Теперь модель допускает производство ПО путем компоновки повторно используемых компонентов, связывая их между собой с помощью какого-либо языка сценариев. Сегодня прототипирование и пошаговая разработка – наиболее распространенные модели создания программного продукта. Во многих случаях используются серийные компоненты, доступные на рынке программных продуктов. Кроме того, существующие программы модифицируются в целях создания нового программного обеспечения. Поддержка CASE-средств уже стала доступной для многих видов работ по созданию ПО.

Таблица 23.5. Модель СОСОМО 81

Сложность проекта	Формула*	Описание
Простой проект	РМ = 2.4 (KDSI)^1.05 х М	Простые проекты для небольших команд разработчиков
Средней сложности	РМ = 3.0 (KDSI)^1.12 х М	Более сложные проекты, при разработке которых члены команды могут ощущать нехватку опыта и знаний соответствующих систем
Проект встроенной системы	РМ = 3.6 (KDSI)^1.20 х М	Сложные проекты, где ПО является частью комплекса аппаратных и программных средств, других технических механизмов и устройств

* В этих формулах РМ (от Person-Months) обозначает человеко-месяцы, KDSI (от thousand (Kilo-) of Delivered Source Instructions) - количество инструкций (в тысячах) в конечной программе (общепринятая единица измерения объема работ по программированию). – Прим. ред.

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

1. Уровень предварительного прототипирования. Для определения необходимых затрат осуществляется оценка размера системы на основе объектных точек прототипа с помощью простой формулы "размер-производительность".

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

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

⇐ Предыдущая 158 159 160 161 162163164 165 166 167 Следующая ⇒