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

Оценка стоимости программного продукта

Цели

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

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

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

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

q знать принципы работы модели СОСОМО 2 для алгоритмической оценки стоимости.

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

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

1. Какие затраты необходимы для выполнения этапа?

2. Сколько это займет времени?

3. Какова стоимость выполнения данного этапа?

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

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

Обычно для оценки проекта по разработке программного обеспечения используются три параметра.

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

• Расходы на командировки и обучение.

• Расходы на персонал, в основном на привлечение со стороны специалистов по программному обеспечению.

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

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

1. Расходы на содержание, отопление и освещение офисов.

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

3. Расходы на содержание компьютерной сети и средств связи.

4. Расходы на централизованные услуги – библиотеки, места отдыха и развлечения и т.д.

5. Расходы на социальное обеспечение и выплаты служащим (например, пенсии и медицинская страховка).

Обычно накладные расходы приравниваются к удвоенной зарплате программиста, в зависимости от размера компании и расходов на ее содержание. Например, если специалист по программному обеспечению получает 90 000 долларов в год, расходы организации на этот год составляют сумму 180 000 долларов, или 15 000 долларов в месяц.

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

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

Таблица 23.1. Факторы, влияющие на стоимость программного продукта

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

Производительность

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

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

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

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

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

Данный подход впервые появился еще во время массового использования таких языков программирования, как FORTRAN, язык ассемблера и COBOL. Затем программы переводились на перфокарты, каждая из которых содержала по одному оператору. Таким образом, было легко подсчитывать количество строк кода. Оно соответствовало количеству перфокарт в колоде. Однако программы, написанные на языках типа Java или C++, состоят из описаний, выполняемых операторов и комментариев. Они также могут включать макрокоманды, которые состоят из нескольких строк кода. С другой стороны, в одной строке может находиться не один, а несколько операторов. Таким образом, соотношения между операторами и строками в листинге могут быть достаточно сложными.

Одни методы подсчета строк основываются только на выполняемых операторах; другие подсчитывают выполняемые операторы и объявления данных; третьи ведут подсчет всех строк программы, независимо от их содержимого. Были предложены определенные стандарты подсчета строк в различных языках программирования [269], однако они не приобрели широкой популярности. Поэтому практически невозможно сравнивать производительность различных компаний-разработчиков, если только все они не используют один и тот же метод подсчета строк кода.

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

Для примера возьмем систему, которая должна быть написана с помощью кода ассемблера (5000 строк) или с помощью языка высокого уровня (1500 строк). Время выполнения различных этапов создания ПО показано в табл. 23.2. Специалист, программирующий на языке ассемблера, будет иметь производительность 714 строк в месяц, а у программиста, работающего с языком высокого уровня, производительность будет в два раза ниже – 300 строк в месяц. И это несмотря на то, что программирование на языке высокого уровня стоит дешевле и занимает меньше времени.

Таблица 23.2. Время выполнения этапов разработки программной системы

	Анализ (недели)	Проектирование (недели)	Кодирование (недели)	Тестирование (недели)	Документирование (недели)
Язык ассемблера
Язык высокого уровня
	Размер (строки кода)	Затраченное время (недели)	Производительность (строк в месяц)
Язык ассемблера
Язык высокого уровня

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

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

• Интенсивность использования ввода и вывода внешних данных.

• Взаимодействие системы с пользователем.

• Внешние интерфейсы.

• Файлы, используемые системой.

Сложность каждого из указанных критериев оценивается отдельно, в результате каждому критерию присваивается определенная весовая величина, которая может колебаться от 3 (для простого ввода данных) до 15 баллов за использование сложных внутренних файлов. Можно использовать весовые величины, предложенные в статье [7], или величины, основанные наличном опыте.

Нескорректированный подсчет функциональных точек (unadjusted function-point count – UFC) выполняется путем вычисления суммы произведений оценки каждого фактора (количество элементов, составляющих данный фактор) на выбранную весовую величину этого фактора:

UFC = ∑ (количество элементов данного типа) х (весовая величина).

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

Вместе с тем в [330] отмечено, что оценка сложности несет в себе также и субъективный фактор, так как подсчет функциональных точек зависит от лица, проводящего оценивание. Люди имеют разные понятия о сложности. Так как подсчет функциональных точек зависит от мнения оценивающего, существует множество вариаций подсчета функциональных точек. Это приводит к разным взглядам на значимость функциональных точек [122]. Однако многие заявляют, что, несмотря на все недостатки, на практике этот метод себя оправдывает [196].

Альтернативой функциональным точкам являются объектные точки [19], особенно если при разработке ПО используется язык программирования четвертого поколения. Метод объектных точек применяется в модели оценивания СОСОМО 2, которая рассматривается далее в главе. (Объектные точки – это отнюдь не классы объектов, которые производятся в результате применения объектно-ориентированного подхода в работе над программой, что можно было бы предположить, исходя из названия.) Количество объектных точек в программе можно получить путем предварительного подсчета ряда элементов.

1. Количество изображений на дисплее. Простые изображения принимаются за 1 объектную точку, изображения умеренной сложности принимаются за 2 точки, а очень сложные изображения принято считать за 3 точки.

2. Количество представленных отчетов. Для простых отчетов назначаются 2 объектные точки, умеренно сложным отчетам назначаются 5 точек. Написание сложных отчетов оценивается в 8 точек.

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

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

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

Подсчет функциональных точек можно проводить параллельно с методом подсчета количества строк кода. Количество функциональных точек при этом используется для оценивания окончательной величины кода. На основе анализа выполнения предыдущих программных проектов для определенных языков программирования можно оценить среднее количество строк кода (average number of lines of code – AVC), необходимых для реализации одной функциональной точки. В этом случае получим оценку размер кода нового проекта, рассчитанную следующим образом:

размер кода = AVC x количество функциональных точек.

Значение AVC варьируется от 200 до 300 строк кода на одну функциональную точку в языке ассемблера и от 2 до 40 строк кода для языков программирования четвертого поколения.

Производительность отдельных программистов, работающих в организации-разработчике, зависит от множества факторов, влияющих на их работу. Некоторые из наиболее значимых факторов представлены в табл. 23.3. Однако различия в индивидуальных способностях программистов намного важнее всех этих факторов. В исследовании ранних этапов программирования [305] отмечено, что производительность некоторых программистов в 10 раз выше, чем у других. Это наблюдение подтверждается и моим личным опытом. Большие команды, члены которых имеют необходимый набор личностных качеств и способностей, будут иметь "среднюю" производительность. Вместе с тем в командах небольшого размера общая производительность во многом зависит от индивидуальных умений и навыков каждого члена команды.

Таблица 23.3. Факторы, влияющие на производительность программиста

Фактор	Описание
Опыт разработки ПО для данной предметной области	Для эффективной разработки программного продукта необходимо знание той предметной области, где будет эксплуатироваться разрабатываемое ПО. Инженеры, имеющие понятие об этой предметной области, выявят наивысшую производительность
Процесс управления качеством	Применяемый метод программирования может оказать существенное влияние на производительность написания кода. Этот фактор рассматривается в главе 25
Размер проекта	Чем больше проект, тем больше времени уходит на согласование различных вопросов внутри группы разработчиков. Тем самым уменьшается время, расходуемое непосредственно на разработку ПО, и снижается производительность
Поддержка технологии разработки ПО	Хорошая поддержка технологии разработки ПО, например CASE-средства или системы управления конфигурацией, может значительно повысить производительность труда программиста
Рабочая обстановка	Как уже упоминалось в главе 22, спокойное рабочее окружение с индивидуальными рабочими местами способствует повышению производительности

Должен отметить, что не существует какой-либо величины, определяющей "среднюю" производительность программиста, которую можно было бы применять в разных организациях и при создании разных программных продуктов. Например, при разработке больших систем производительность может быть очень низкой и доходить до 30 строк за человеко-месяц. На простых программных системах производительность может подняться до 900 строк в месяц. В [44] высказано предположение, что производительность программиста может колебаться от 4 до 50 объектных точек в месяц, в зависимости от наличия средств поддержки и от способностей программиста.

Недостатком оценок, которые основываются на подсчете объема выполненной работы или определении количества затраченного времени, является то, что они не принимают во внимание такие важные нефункциональные свойства разрабатываемой системы, как надежность, удобство эксплуатации и т.п. Обычно здесь работает простое правило: больше – значит, лучше. Бек (Beck, [32]) приводит удачное замечание, что если вы работаете над постоянным усовершенствованием и упрощением системы, то подсчет строк ничего не даст.

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

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

Методы оценивания

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

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

Несмотря ни на что, организации-разработчики обязательно должны оценивать затраты на разработку и себестоимость программного продукта. Для этого можно применять методы, описанные в табл. 23.4 [46].

Таблица 23.4. Методы оценки себестоимости

Метод	Описание
Алгоритмическое моделирование себестоимости	Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного показателя програ.ммного продукта (обычно это размер программного кода). Проводится оценка этого показателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты
Оценка эксперта	Проводится опрос нескольких экспертов по технологии разработки ПО, знающих область применения создаваемого программного продукта. Каждый из них дает свою оценку себестоимости проекта. Потом все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предварительной сметы проекта
Оценка по аналогии	Этот метод используется в том случае, если в данной области применения создаваемого ПО уже реализованы аналогичные проекты. В таком случае при оценке затрат для сравнения берутся предыдущие проекты. В книге [251] дано достаточно ясное описание этого метода
Закон Паркинсона	Согласно этому закону усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проекту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работает пять человек, должен быть закончен в течение 12 месяцев, то затраты на его выполнение исчисляются в 60 человеко-месяцев
Назначение цены с целью выиграть контракт	Затраты на проект определяются наличием тех средств, которые имеются у заказчика. Поэтому себестоимость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого продукта

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

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

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

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

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

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

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

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

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

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

• Применение систем типа клиент/сервер вместо систем, основанных на мэйнфреймах.

• Применение готовых коммерческих пакетов программного обеспечения вместо собственной разработки компонентов системы.

• Повторное использование компонентов системы вместо новых разработок.

• Использование CASE-средств и генераторов программ вместо разработки ПО без применения средств поддержки.

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

⇐ Предыдущая 157 158 159 160 161162163 164 165 166 Следующая ⇒