И. Соммервилл - Инженерия программного обеспечения (1133538), страница 124
Текст из файла (страница 124)
Обычно все большие проекты разработки ПО нмек>т документ, в котором определены требования к системе. Однако во многих проектах оценка затрат проводитсл только па основании проекта требований к системс. В этом сл>чае лица. участвующие в оценке стоимости проекта, булуг иметь минимум информации для работы. Процедуры анализа требований и созлания спецификации весьма дорогостоящи. Поэтому менеджерам компании следует составить смету па нх выполнение сщс до утверждения бюджета для всего проекта. Во многих случаях популярной становитсн стратегия ценообразования с целью выиграть контракт".
Можно согласиться, что данная фраза звучит несколько некорректно и нс по.деловому, однако эта стратегия иа самом деле себя оправдывает. Стоимость работы согласовывается на основании предварительного проекта предложения. Далее проводятся переговоры между компанией-исполнителем и заказчиком с тем, чтобы обсудить детальное техническое задание, которое, однако, ограничивается согласованной суммой. Продавец и заказчик также должны обсудить приемлемые функциональпыс возможности системы. Здесь основополагающим фактором для многих проектов становятся возможности б>юджста, а нс требования к системс.
Требованил всегда можно изменить так, чтобы пе выходить за рамки принятого бюджета. Прн оценке себестонл>ости проекта менеджеры должны всегда помнить о том, что межлу прошлыми проектами и будущими разработками может быть существеннал разница. Только за последние 10 лет на свет появился целый ряд новейших разработок и технологий. Многие менеджеры очень мало ознакомлены, а иногда просто не имеют понятия об этих технологиях и о том, какое влияние они мог>т оказать па проект. Вот несколько при. мер>и> технических и технологических новшеств, которые могут повлиять на оценку стоимости проекта, основанную иа предыдущем опыте. ° Появление объекгпо-ориентированного программирования вместо процедурного.
° Применение систем типа клиент/сервер нчссто систем, основанных на мэйнфреймах. Прнмспсппс готовых коммерческих пакстон программного обеспечс>шя вместо собстнс>ншй разработки компонентов системы. ° Повторное использование колшонсптов системы вл>осто новых разработок. 23. Оценка стоимости программного продукта 479 ° Использование САБЕ средств и генераторов программ вместо разработки ПО без применения средств поддержки. Все эти факторы отнюдь не облегчают задачу лгеиеджера в оценке стоимости про. граммной продукции.
И в этом случае предыдущий опыт не всегда оказывается полезным для проведения такой оценки. 23.3. Алгоритмическое моделирование стоимости Алгоритмическое моделирование считается наиболее системным подходом к опрсдс. лению стоимости, однако это не значит, что оп всегда дает точные результаты.
Алгоритмическую модель стоимости можно построить с помощью анализа затрат и параметров уже разработанных проектов. Для прогнозирования затрат применяется математическая формула, в которой учтены данные о размере проекта, количестве программистов, а также другие факторы и процессы. В работе !198! приведены 13 алгоритмических моделей прогнозирования за~рат. построенных на анализе выполпенил предыдущих проектов.
В большинстве алгоритмических моделей г1юрмулы вычисления затрат имеют экспоненцнальный вид. Причина этого — отсутствие линейной зависимости себестоимости проекта ст его размера. С увеличением проекта появляются дополшггельные расходы, связанные с ростом за. трат на колгмуннкации, усложнением управления конфлпурацисй, увеличением объема рабат по сборке системы и т.д.
Оценки затрат также могут умножаться на коэффициенты, учитываю. щие свойства разрабатываемого программного продукта, платформу разработки, технологию создания ПО и квалификацию привлеченных специалистов. В общем случае формула длл вычисления азгоритлгл~чсской оценки стоилюсти зашкывается следующим образом: затраты = А х размер' х М, где А — постоянный коэффициент, который зависит от организации выполнения проекта и типа разрабатываемого программного обеспечения; показатель размер может соотпо. ситыя либо с размером кода программы, либо с функциональной оценкой, выраженно!! в количестве объектных или функциональных точек; показатель степени В может варьиро.
ваться в пределах от 1 до 1.5, ои отображает объем работ, требующийся для реализации больших проектов; множитель М отображает характеристики различных агапов разработки, а также характеристики создаваемого продукта. Алгоритмическим лгоделял! присущи общие проблемы. 1. На ранней стадии выполнения проекта бывает сложно определить показатель размер при наличии информации только о системных требованиях.
Несмотря па то что оцелнга, основанная на функциональных, илн объектных, точках, проще оценки размера кода, результаты тоже нс всегда будут точнымн. 2. Оценка факторов, которые влияют па показатели В и М, носит субъектившай ха. рактер. Значения этих показателей мокнут отличаться, если этим занимаются люди с разным опытом и квалификацией. Основой для многих алгоритмических моделей оценки себестоимости является количество строк программного кода в созданной системс. Оценку разисра кода можно полу чнть по аналогии с другими проектами путем преобразования функциональных точек и размер кода, сравнения размеров компонентов системы и сравнения с эталоппымп компонентами, а также просто на основе инженерной интуиции.
На размер окончателыюй системы мо|уг повлиять ре~нсния, которые были приняты а и!нг цессе реализации проси а уже после утвсрждсшш начальной сметы. Например, это можс г быть решение о толк использовать ли в созпаваемом ПО, требующем сложной системы управлспнл 480 Часть У1. Управление данными, базы данных сторонних производителей или разработать свои системы управления данными. Очевидно.
что при использовании сторонних баэ данных програлемный код, котс» рый следует создать, будет меньшего размера. Кроме того, имеет значение и язык программирования. Для таких языков, как [ага, потребуется больше строк кода, чем если бы применялся, скажем, язык С. В то же время "лишний" код на языке[эта потребует провести больше проверок программы в процессе компиляции, вследствие чего расходы на аттестацию системы наверняка снизятся.
Чему в данном случае отдать предпочтениеу Кроме прочего, также необходимо оценить объем повторного использования кода. Прн использовании алгоритмических моделей для ценообразования проекта в них должен учитываться тип проекта, при этом результаты оценивания необходимо тщатеяь. но анализировать Менеджер должен составить нс одну, а несколько оценок стоимости (среди них наименее выгодную, ожидаемую и наиболее выгодную). Следует также помнить о большой вероятности значительных ошибок при раннем прогнозировании себестоимости. Наиболее точные оценки можно пол)чить в том случае, если создаваемый продулт хорошо структурирован, модель учитывает интересы организации.эаказчнка, заранее определены язык программирования и необходимые аппаратные средства.
1х 0.5х 0.20к Рне. 23. Д Ианенчиеоенеа оцеяивнния энне)ат Точность результатов прогнозирования себестоимости также зависит от количества информации о создаваемой системе. По ходу реализации проекта увеличивается количество информации, вследствие чего оценка себестоимости становится все более точной. Если при начальном оценивании времени оп затрат длл разработки систе»зы требовалогь х месяцев, то реальная длительность выполнения проекта может колебаться от 0.25хдо 4х. Однако этот диапазон постепенно сужается в процессе выполнения проекта, как показано на рис. 23.1.
Эта схема была заимствована из статьи [44) и основана па опыте реализации многих проектов разработки программных продуктов. 23.3.1. Модель СОСОМО Существ) ст целый ряд алгоритмических моделей для прогнозирования затрат и себестоимости, а также создания графика работ для програлемных проектов. Принципиально онп между собой нс отличаются, хотя используют значения разных параметров. Одной нз самых интересных моделей я считаю СОСОМО'. Эта людель основана па опыте рсалпэвцпи лшогпх программных проектов. Онэ создана путем сбора данных о болыпол» коли- о ООГХ)1!О Гом ООтетел не г Ое! МОЕег) — кот теукмненоя е новноемноя оннъон — Г!рны, рел.
23. Оценка стоимости программного продукта 481 честве проектов и анализа этой информации, в результате чего получены формулы, наг+ лучшим образом аппроксимирующие имеющиеся данные. Я отдаю предпочтение модели СОСОМО по трем причинам. 1. Эта модель имеет хорошую техническую документацию, общедоступна, существуют коммерческис программныс средства ее поддержки.
2. Модель популярна и ценится среди широкого круга пользователей. 3. Она прошла дос"гаточно долгий путь развития со времени первого появления в 1981 году [46), была усовершенствована для разработки ПО на лзыке Аг)а [43), последняя версия модели опубликована в 1995 году [44]. Модель СОСОМО в перволг варианте (известном сейчас как СОСОМО 81) имела трехуровневую структуру, где уровни определяли сложность анализа себестоимости. На пер. вом (илн базовом) уровне проводилась начальная грубая оценка, на втором уровне эта оценка уточнялась пугем применения различных множителей, учитывающих особенности проекта и технологии разработки ПО, самый сложный уровень даст возможность рассчитать себестоимость для разных стадий проекта.
В табл. 23.5 показаны основные формулы модели СОСОМО для проектов с различной степенью сложности. Здесь множитель М идентичен тому, который булст описан далее для СОСОМО 2. Моделью СОСОМО 81 предусмотрена разработка программного обеспечения в соответствии с каскадной моделью, причем предполагается. что большая часть системы разрабатывается "с нуля". Однако со времени первой версии данной модели было сделано нс. сколько фундаментальных изменений в целях ес усовершенствования. Теперь модель допускает производство ПО путем компоновки повторно используемых компонентов, связывая их между собой с помощью какого-либо языка сценариев.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
