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

Лекция 5. Оценка стоимости программного продукта Цели Цель этой лекции - изложить различные методы оценки стоимости и затрат, необходимых для создания программного продукта. Изучив ее, вы должны: • знать, как оценивается себестоимость и назначается цена программного продукта, и понимать сложные взаимосвязи между этими двумя процессами; • знать три системы оценивания производства программного продукта; • понимать, что для правильной оценки стоимости ПО и для создания графика работ необходимо применять широкий спектр различных методов оценки стоимости программного продукта; • знать принципы работы модели СОСОМО 2 для алгоритмической оценки стоимости. Ранее мы рассматривали процесс управления программным проектом. При этом проект разбивался на ряд этапов, выполняемых параллельно или последовательно, и требовалось определить их взаимозависимости и распределения специалистов по работам, выполняемым на каждом этапе. В этой лекции мы рассмотрим общую проблему оценки затрат и времени, необходимых для выполнения определенных этапов проекта. Менеджеры проекта должны научиться давать правильные ответы на следующие вопросы. 1. Какие затраты необходимы для выполнения этапа? 2. Сколько это займет времени? 3. Какова стоимость выполнения данного этапа? Оценка стоимости проекта и планирование графика работ проводятся параллельно. Однако некоторые предварительные расчеты должны быть выполнены на ранней стадии, еще до начала разработки точного плана проекта. Такие расчеты необходимы для утверждения бюджета проекта или для выставления цены заказчику. Как только проект начинает действовать, все расчеты должны регулярно обновляться. Это помогает планировать работу и содействует эффективному использованию средств. Если фактические расходы значительно превышают планируемые, менеджеру необходимо предпринять какие-либо действия. Это может быть перечисление дополнительных средств на проект либо изменение будущих этапов работ в соответствии с фактическим бюджетом. Обычно для оценки проекта по разработке программного обеспечения используются три параметра. • Стоимость аппаратных средств и программного обеспечения, включая их обслуживание. • Расходы на командировки и обучение. • Расходы на персонал, в основном на привлечение со стороны специалистов по программному обеспечению. В большинстве проектов доминируют расходы на персонал. Компьютеры, имеющие достаточно мощности для разработки программного продукта, в наше время относительно дешевые. Значительными могут быть затраты на командировки, если проект разрабатывается в разных местах, однако для большинства проектов они все же не очень существенны. Более того, расходы на командировки можно сократить, используя вместо них электронную почту, факс или телеконференции. Расходы на персонал — это не только оплата труда работников. В них могут включаться накладные расходы, т.е. все расходы, которые касаются работы организации, деленные на количество работающего персонала. Таким образом, общая сумма расходов на персонал состоит из нескольких статей расходов. 1. Расходы на содержание, отопление и освещение офисов. 2. Расходы на содержание вспомогательного персонала - бухгалтеров, секретарей, уборщиц и технического персонала. 3. Расходы на содержание компьютерной сети и средств связи. 4. Расходы на централизованные услуги - библиотеки, места отдыха и развлечения и т.д. 5. Расходы на социальное обеспечение и выплаты служащим (например, пенсии и медицинская страховка). Обычно накладные расходы приравниваются к удвоенной зарплате программиста, в зависимости от размера компании и расходов на ее содержание. Например, если специалист по программному обеспечению получает 90 000 рублей в месяц, расходы организации на этот месяц составляют сумму 180 000 рублей, или 6 000 рублей в день. Оценка стоимости должна быть объективной, чтобы дать компании-разработчику достаточно точный прогноз себестоимости проекта. Если себестоимость рассчитывается для включения в коммерческое предложение заказчику, следует принять решение о том, какую цену назначить за проект. Традиционно в цену продукта включают издержки производства плюс предлагаемая прибыль. Однако определить соотношение себестоимости проекта и цены, выставляемой заказчику, не всегда просто. На определение цены программного продукта могут повлиять организационные, экономические, политические и коммерческие соображения. Эти факторы показаны в табл. 1. Таким образом, взаимоотношения цены и себестоимости совсем не так просты, как может показаться. Кроме того, необходимо учитывать глобальные цели организации, поэтому назначением цены за программный продукт вместе с менеджерами проектов занимается и старший руководящий состав компании. Таблица 1. Факторы , влияющие на стоимость программного продукта Фактор Описание Возможности рынка ПО Организация-разработчик может выставить низкие цены на программный продукт из-за намерения переместиться в другой сегмент рынка ПО. Даже если организация примет более низкую прибыль в первом проекте, это все равно может привести к более высоким доходам в будущем, поскольку полученный опыт позволит заниматься разработкой подобных программных продуктов и в дальнейшем Невозможно учесть все факторы, влияющие на стоимость Если организация примет фиксированную величину стоимости, издержки производства могут возрасти из-за непредвиденных расходов Условия контракта Заказчик может позволить разработчику сохранить за собой право владения программным кодом с последующим его использованием в других проектах. При этом назначенная цена может быть ниже, чем в том случае, если право на программный код передано заказчику Изменение требований При изменении требований к ПО организация может снизить цену с тем, чтобы выиграть контракт. Если контракт уже заключен, за изменение требований можно назначить дополнительную цену Финансовая стабильность Фирмы, испытывающие финансовые затруднения, для получения заказа могут снизить цены на свои разработки. Как правило, лучше сегодня получить более низкую прибыль или даже работать на уровне самоокупаемости, чем обанкротиться в будущем 1. Производительность Производительность в промышленности обычно измеряется путем деления количества единиц выпущенной продукции на количество человеко-часов, необходимых для их производства. Однако в области разработки ПО любая задача имеет несколько вариантов решения, каждый со своими особенностями. Одно проектное решение отличается эффективным способом выполнения, другое имеет программный код, который легко читается либо удобен в эксплуатации. Поэтому не имеет смысла сравнивать уровни производительности при разработке решений с разными качественными характеристиками. Несмотря на это, менеджеры могут оценить производительность самих специалистов по разработке программного обеспечения. Это понадобится при оценивании проекта и определении эффективности усовершенствования процесса и технологии разработки ПО. Оценка производительности в этом случае будет основана на измерении количественных показателей программных продуктов и последующем делении их на количество усилий, затраченных на разработку этих продуктов. При этом можно использовать два типа показателей. 1. Показатель размера. Зависит от размера выходного результата очередного этапа работ. Наиболее часто применяемым критерием такого типа является количество строк разработанного программного кода. За аналогичный показатель также можно взять количество инструкций объектной программы или количество страниц системной документации. 2. Функциональный показатель. Зависит от функциональных возможностей программного продукта в целом. Производительность в этом случае выражается количеством полезных выполняемых функций, разработанных в определенный отрезок времени. К наиболее распространенным показателям этого типа относится количество функциональных и объектных точек. Количество строк программного кода за человеко-месяц - наиболее популярный критерий оценки производительности. Он определяется путем деления общего количества строк кода на количество времени в человеко-месяцах, которое потребуется для завершения проекта. Это время, потраченное на анализ, проектирование, кодирование, тестирование и разработку документации программного продукта. Данный подход впервые появился еще во время массового использования таких языков программирования, как FORTRAN, язык ассемблера и COBOL. Затем программы переводились на перфокарты, каждая из которых содержала по одному оператору. Таким образом, было легко подсчитывать количество строк кода. Оно соответствовало количеству перфокарт в колоде. Однако программы, написанные на языках типа Java или C++, состоят из описаний, выполняемых операторов и комментариев. Они также могут включать макрокоманды, которые состоят из нескольких строк кода. С другой стороны, в одной строке может находиться не один, а несколько операторов. Таким образом, соотношения между операторами и строками в листинге могут быть достаточно сложными. Одни методы подсчета строк основываются только на выполняемых операторах; другие подсчитывают выполняемые операторы и объявления данных; третьи ведут подсчет всех строк программы, независимо от их содержимого. Были предложены определенные стандарты подсчета строк в различных языках программирования, однако они не приобрели широкой популярности. Поэтому практически невозможно сравнивать производительность различных компаний-разработчиков, если только все они не используют один и тот же метод подсчета строк кода. Также может ввести в заблуждение и сравнение производительности программистов, пишущих на разных языках программирования. Чем выразительнее язык, тем ниже производительность. Это "странное" утверждение объясняется тем, что при оценивании производительности создания ПО берется во внимание вся деятельность по разработке программного продукта, тогда как данная система измерения основывается лишь на оценивании процесса программирования. Для примера возьмем систему, которая должна быть написана с помощью кода ассемблера (5000 строк) или с помощью языка высокого уровня (1500 строк). Время выполнения различных этапов создания ПО показано в табл. 2. Специалист, программирующий на языке ассемблера, будет иметь производительность 714 строк в месяц, а у программиста, работающего с языком высокого уровня, производительность будет в два раза ниже - 300 строк в месяц. И это несмотря на то, что программирование на языке высокого уровня стоит дешевле и занимает меньше времени. Таблица 2. Время выполнения этапов разработки программной системы Анализ (недели) Проектирование (недели) Кодирование (недели) Тестирование (недели) Документирование (недели) Язык ассемблера 3 5 8 10 2 2 Язык высокого уровня 3 5 8 6 Размер (строки кода) Затраченное время (недели) Производительность (строк в месяц) Язык ассемблера 5000 28 714 Язык высокого уровня 1500 20 300 Альтернативой показателю размера при оценивании производительности может служить функциональный показатель. В этом случае можно избежать тех "аномалий" в оценке производительности, которые встречаются при использовании показателя размера, так как функциональность не зависит от языка программирования. Одним из наиболее распространенных методов этого типа является метод функциональных точек. Функциональные точки не зависят от применяемого языка программирования, благодаря чему появилась возможность сравнения производительности разработки программных систем, написанных на различных языках программирования. Критерием оценки производительности выступает количество функциональных точек, созданных за человеко-месяц. Функциональная точка — это не какая-то отдельная характеристика программного продукта, а целая комбинация его свойств. Подсчет общего количества функциональных точек в программе проводится путем измерения или оценивания следующих свойств программы. • Интенсивность использования ввода и вывода внешних данных. • Взаимодействие системы с пользователем. • Внешние интерфейсы. • Файлы, используемые системой. Сложность каждого из указанных критериев оценивается отдельно, в результате каждому критерию присваивается определенная весовая величина, которая может колебаться от 3 (для простого ввода данных) до 15 баллов за использование сложных внутренних файлов. Можно использовать весовые величины или величины, основанные на личном опыте. Нескорректированный подсчет функциональных точек (unadjusted function-point count - UFC) выполняется путем вычисления суммы произведений оценки каждого фактора (количество элементов, составляющих данный фактор) на выбранную весовую величину этого фактора: UFC = X (количество элементов данного типа) х (весовая величина). Первоначальный метод подсчета функциональных точек был в дальнейшем усовершенствован путем добавления тех факторов, значение которых зависит от общей сложности проекта. Здесь принимается во внимание степень распределенности обработки данных, многократность использования программных элементов, качество функционирования и т.п. Значение, полученное при нескоректированном подсчете функциональных точек, нужно умножить на факторы, определяющие сложность проекта, в результате будет получено итоговое значение. Вместе с тем оценка сложности несет в себе также и субъективный фактор, так как подсчет функциональных точек зависит от лица, проводящего оценивание. Люди имеют разные понятия о сложности. Так как подсчет функциональных точек зависит от мнения оценивающего, существует множество вариаций подсчета функциональных точек. Это приводит к разным взглядам на значимость функциональных точек. Однако многие заявляют, что, несмотря на все недостатки, на практике этот метод себя оправдывает. Альтернативой функциональным точкам являются объектные точки, особенно если при разработке ПО используется язык программирования четвертого поколения. Метод объектных точек применяется в модели оценивания СОСОМО 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 строк кода для языков программирования четвертого поколения. Производительность отдельных программистов, работающих в организации-разработчике, зависит от множества факторов, влияющих на их работу. Некоторые из наиболее значимых факторов представлены в табл. 3. Однако различия в индивидуальных способностях программистов намного важнее всех этих факторов. В исследованиях ранних этапов программирования отмечается, что производительность некоторых программистов в 10 раз выше, чем у других. Это наблюдение подтверждается и моим личным опытом. Большие команды, члены которых имеют необходимый набор личностных качеств и способностей, будут иметь "среднюю" производительность. Вместе с тем в командах небольшого размера общая производительность во многом зависит от индивидуальных умений и навыков каждого члена команды. Таблица 3. Факторы, влияющие на производительность программиста Фактор Описание Опыт разработки ПО для данной предметной области Для эффективной разработки программного продукта необходимо знание той предметной области, где будет эксплуатироваться разрабатываемое ПО. Инженеры, имеющие понятие об этой предметной области, выявят наивысшую производительность Процесс управления качеством Применяемый метод программирования может оказать существенное влияние на производительность написания кода. Размер проекта Чем больше проект, тем больше времени уходит на согласование различных вопросов внутри группы разработчиков. Тем самым уменьшается время, расходуемое непосредственно на разработку ПО, и снижается производительность Поддержка технологии разработки ПО Хорошая поддержка технологии разработки ПО, например CASE-средства или системы управления конфигурацией, может значительно повысить производительность труда программиста Рабочая обстановка Спокойное рабочее окружение с индивидуальными рабочими местами способствует повышению производительности Должен отметить, что не существует какой-либо величины, определяющей "среднюю" производительность программиста, которую можно было бы применять в разных организациях и при создании разных программных продуктов. Например, при разработке больших систем производительность может быть очень низкой и доходить до 30 строк за человеко-месяц. На простых программных системах производительность может подняться до 900 строк в месяц. В целом производительность программиста может колебаться от 4 до 50 объектных точек в месяц, в зависимости от наличия средств поддержки и от способностей программиста. Недостатком оценок, которые основываются на подсчете объема выполненной работы или определении количества затраченного времени, является то, что они не принимают во внимание такие важные нефункциональные свойства разрабатываемой системы, как надежность, удобство эксплуатации и т.п. Обычно здесь работает простое правило: больше — значит, лучше. Если вы работаете над постоянным усовершенствованием и упрощением системы, то подсчет строк ничего не даст. Описанные методы также не учитывают многократность использования программного продукта. В действительности необходимо оценить стоимость повторного использования определенной системы с данным набором функциональных и качественных характеристик, имеющей собственные показатели удобства сопровождения и т.д. Все эти параметры только косвенно соотносятся с такими количественными показателями, как, например, размер системы. Трудности также могут возникнуть в случае, если менеджеры используют показатели производительности для оценивания способностей персонала. В этом случае качество выполненной программистом работы может отойти на второй план по отношению к производительности. Может случиться, что "менее продуктивный" программист создаст код, который будет надежнее, понятнее и дешевле в использовании. Поэтому нельзя пользоваться показателями производительности как единственным источником оценивания труда программиста. 2. Методы оценивания Не существует простого метода определения будущих затрат, необходимых для разработки программного продукта. Начальное оценивание можно провести, основываясь на определенных пользовательских требованиях высокого уровня. Но заранее не известно, какие технологии будут применяться при разработке ПО и какие компьютеры будет использоваться. Также невозможно предугадать, какие люди будут работать над проектом и какие у них будут навыки и опыт. Это показывает, что чрезвычайно трудно провести точную оценку стоимости проекта на самом раннем этапе. Более того, основная проблема в оценке себестоимости проектов заключается в низкой точности применяемых методов оценивания. Часто в расчет себестоимости проекта закладывается его окупаемость. Таким образом, первоначальная оценка себестоимости определяет бюджет проекта, за рамки которого нельзя выходить при реализации проекта. Вместе с тем я не знаю ни одного реализованного проекта, где бы стоимость не корректировалась по ходу его выполнения. Но всегда в ходе реализации проекта фактические расходы сравниваются с предварительной оценкой затрат. Несмотря ни на что, организации-разработчики обязательно должны оценивать затраты на разработку и себестоимость программного продукта. Для этого можно применять методы, описанные в табл. 4. В литературе описан эксперимент, в котором менеджеров попросили провести предварительную оценку размера будущей программной системы и необходимых для ее разработки затрат. Менеджеры при этом использовали мнения экспертов и оценку по аналогии. Результаты эксперимента показали, что менеджеры провели достаточно точную оценку затрат, однако определение размера будущей системы при этом было менее точным. Это означает, что оценка затрат, основанная только на данных о размере программы, будет неточной. Методы предварительной оценки себестоимости могут выполняться с применением нисходящего или восходящего подходов. При нисходящем подходе оценка себестоимости начинается на уровне системы: рассматриваются функциональные возможности программы в целом и то, как эти возможности реализуются посредством функций более низкого уровня. Здесь учитывается себестоимость таких этапов разработки, как сборка системы, управление конфигурацией и создание технической документации. В отличие от нисходящего подхода, восходящий начинается на уровне системных компонентов. Система разбивается на компоненты и определяются затраты на разработку каждого из них. Затем эти затраты суммируются для определения полной стоимости проекта. Недостатки восходящего подхода являются достоинствами нисходящего и наоборот. Восходящий подход может недооценить затраты, необходимые для решения сложных проблем, возникающих при разработке таких специфических компонентов системы, как интерфейсы для нестандартных аппаратных средств. Детального обоснования для составления сметы затрат в этом случае не существует. Нисходящий подход, напротив, дает такое обоснование, а также возможность рассмотреть каждый компонент в отдельности. Вместе с тем данный подход больше акцентирует внимание на таких этапах реализации проекта, как, например, сборка системы. Кроме того, нисходящий подход является более дорогостоящим. Для его применения нужно иметь хотя бы предварительный результат проектирования системы с тем, чтобы оценить каждый ее компонент. Каждый метод оценивания, безусловно, имеет слабые и сильные стороны. Для работы с большими проектами необходимо применить несколько методов оценивания себестоимости для их последующего сравнения. Если при этом получаются совершенно разные результаты, значит, информации для получения более точной оценки недостаточно. В этом случае необходимо воспользоваться дополнительной информацией, после чего повторить оценивание, и так до тех пор, пока результаты разных методов не станут достаточно близкими. Таблица 4. Методы оценки себестоимости Метод Описание Алгоритмическое моделирование себестоимости Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного показателя программного продукта (обычно это размер программного кода). Проводится оценка этого показателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты Оценка эксперта Проводится опрос нескольких экспертов по технологии разработки ПО, знающих область применения создаваемого программного продукта. Каждый из них дает свою оценку себестоимости проекта. Потом все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предварительной сметы проекта Оценка по аналогии Этот метод используется в том случае, если в данной области применения создаваемого ПО уже реализованы аналогичные проекты. В таком случае при оценке затрат для сравнения берутся предыдущие проекты. Закон Паркинсона Согласно этому закону усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проекту являются человеческие ресурсы, а не целевая оценка самого программного продукта. Если проект, над которым работает пять человек, должен быть закончен в течение 12 месяцев, то затраты на его выполнение исчисляются в 60 человеко-месяцев Назначение цены с целью выиграть контракт Затраты на проект определяются наличием тех средств, которые имеются у заказчика. Поэтому себестоимость проекта зависит от бюджета заказчика, а не от функциональных характеристик создаваемого продукта Описанные методы оценивания применимы, если документированы требования для будущей системы. В таком случае существует возможность определить функциональные характеристики разрабатываемой системы. Обычно все большие проекты разработки ПО имеют документ, в котором определены требования к системе. Однако во многих проектах оценка затрат проводится только на основании проекта требований к системе. В этом случае лица, участвующие в оценке стоимости проекта, будут иметь минимум информации для работы. Процедуры анализа требований и создания спецификации весьма дорогостоящи. Поэтому менеджерам компании следует составить смету на их выполнение еще до утверждения бюджета для всего проекта. Во многих случаях популярной становится стратегия ценообразования с целью "выиграть контракт". Можно согласиться, что данная фраза звучит несколько некорректно и не по-деловому, однако эта стратегия на самом деле себя оправдывает. Стоимость работы согласовывается на основании предварительного проекта предложения. Далее проводятся переговоры между компанией-исполнителем и заказчиком с тем, чтобы обсудить детальное техническое задание, которое, однако, ограничивается согласованной суммой. Продавец и заказчик также должны обсудить приемлемые функциональные возможности системы. Здесь основополагающим фактором для многих проектов становятся возможности бюджета, а не требования к системе. Требования всегда можно изменить так, чтобы не выходить за рамки принятого бюджета. При оценке себестоимости проекта менеджеры должны всегда помнить о том, что между прошлыми проектами и будущими разработками может быть существенная разница. Только за последние 10 лет на свет появился целый ряд новейших разработок и технологий. Многие менеджеры очень мало ознакомлены, а иногда просто не имеют понятия об этих технологиях и о том, какое влияние они могут оказать на проект. Вот несколько примеров технических и технологических новшеств, которые могут повлиять на оценку стоимости проекта, основанную на предыдущем опыте. • Появление объектно-ориентированного программирования вместо процедурного. • Применение систем типа клиент/сервер вместо систем, основанных на мэйнфреймах. • Применение готовых коммерческих пакетов программного обеспечения вместо собственной разработки компонентов системы. • Повторное использование компонентов системы вместо новых разработок. • Использование CASE-средств и генераторов программ вместо разработки ПО без применения средств поддержки. Все эти факторы отнюдь не облегчают задачу менеджера в оценке стоимости программной продукции. И в этом случае предыдущий опыт не всегда оказывается полезным для проведения такой оценки. 3. Алгоритмическое моделирование стоимости Алгоритмическое моделирование считается наиболее системным подходом к определению стоимости, однако это не значит, что он всегда дает точные результаты. Алгоритмическую модель стоимости можно построить с помощью анализа затрат и параметров уже разработанных проектов. Для прогнозирования затрат применяется математическая формула, в которой учтены данные о размере проекта, количестве программистов, а также другие факторы и процессы. В большинстве алгоритмических моделей формулы вычисления затрат имеют экспоненциальный вид. Причина этого - отсутствие линейной зависимости себестоимости проекта от его размера. С увеличением проекта появляются дополнительные расходы, связанные с ростом затрат на коммуникации, усложнением управления конфигурацией, увеличением объема работ по сборке системы и т.д. Оценки затрат также могут умножаться на коэффициенты, учитывающие свойства разрабатываемого программного продукта, платформу разработки, технологию создания ПО и квалификацию привлеченных специалистов. В общем случае формула для вычисления алгоритмической оценки стоимости записывается следующим образом: затраты = А х размерВ х М, где А - постоянный коэффициент, который зависит от организации выполнения проекта и типа разрабатываемого программного обеспечения; показатель размер может соотноситься либо с размером кода программы, либо с функциональной оценкой, выраженной в количестве объектных или функциональных точек; показатель степени В может варьироваться в пределах от 1 до 1.5, он отображает объем работ, требующийся для реализации больших проектов; множитель М отображает характеристики различных этапов разработки, а также характеристики создаваемого продукта. Алгоритмическим моделям присущи общие проблемы. 1. На ранней стадии выполнения проекта бывает сложно определить показатель размер при наличии информации только о системных требованиях. Несмотря на то, что оценка, основанная на функциональных, или объектных, точках, проще оценки размера кода, результаты тоже не всегда будут точными. 2. Оценка факторов, которые влияют на показатели В и М, носит субъективный характер. Значения этих показателей могут отличаться, если этим занимаются люди с разным опытом и квалификацией. Основой для многих алгоритмических моделей оценки себестоимости является количество строк программного кода в созданной системе. Оценку размера кода можно получить по аналогии с другими проектами путем преобразования функциональных точек в размер кода, сравнения размеров компонентов системы и сравнения с эталонными компонентами, а также просто на основе инженерной интуиции. На размер окончательной системы могут повлиять решения, которые были приняты в процессе реализации проекта уже после утверждения начальной сметы. Например, это может быть решение о том, использовать ли в создаваемом ПО, требующем сложной системы управления данными, базы данных сторонних производителей или разработать свои системы управления данными. Очевидно, что при использовании сторонних баз данных программный код, который следует создать, будет меньшего размера. Кроме того, имеет значение и язык программирования. Для таких языков, как Java, потребуется больше строк кода, чем если бы применялся, скажем, язык С. В то же время "лишний" код на языке Java потребует провести больше проверок программы в процессе компиляции, вследствие чего расходы на аттестацию системы наверняка снизятся. Чему в данном случае отдать предпочтение? Кроме прочего, также необходимо оценить объем повторного использования кода. При использовании алгоритмических моделей для ценообразования проекта в них должен учитываться тип проекта, при этом результаты оценивания необходимо тщательно анализировать. Менеджер должен составить не одну, а несколько оценок стоимости (среди них наименее выгодную, ожидаемую и наиболее выгодную). Следует также помнить о большой вероятности значительных ошибок при раннем прогнозировании себестоимости. Наиболее точные оценки можно получить в том случае, если создаваемый продукт хорошо структурирован, модель учитывает интересы организации-заказчика, заранее определены язык программирования и необходимые аппаратные средства. Рис. 1. Изменчивость оценивания затрат Точность результатов прогнозирования себестоимости также зависит от количества информации о создаваемой системе. По ходу реализации проекта увеличивается количество информации, вследствие чего оценка себестоимости становится все более точной. Если при начальном оценивании временных затрат для разработки системы требовалось х месяцев, то реальная длительность выполнения проекта может колебаться от 0.25х до 4х. Однако этот диапазон постепенно сужается в процессе выполнения проекта, как показано на рис. 1, который основан на опыте реализации многих проектов разработки программных продуктов. 3.1. Модель СОСОМО Существует целый ряд алгоритмических моделей для прогнозирования затрат и себестоимости, а также создания графика работ для программных проектов. Принципиально они между собой не отличаются, хотя используют значения разных параметров. Одной из самых интересных моделей я считаю СОСОМО1. Эта модель основана на опыте реализации многих программных проектов. Она создана путем сбора данных о большом количестве проектов и анализа этой информации, в результате чего получены формулы, наилучшим образом аппроксимирующие имеющиеся данные. Я отдаю предпочтение модели СОСОМО по трем причинам. 1. Эта модель имеет хорошую техническую документацию, общедоступна, существуют коммерческие программные средства ее поддержки. 2. Модель популярна и ценится среди широкого круга пользователей. Она прошла достаточно долгий путь развития со времени первого появления в 1981 году, была усовершенствована для разработки ПО на языке Ada, последняя версия модели опубликована в 1995 году. COCOMO была впервые опубликована в 1981 году в книге Боэма «Экономика разработки программного обеспечения» в качестве модели для оценки трудоемкости, себестоимости и плана-графика для проектов по разработке программного обеспечения. Она использовала исследование 63 проектов в аэрокосмической компании TRW, в которой Барри Боэм был директором отдела исследований программного обеспечения и технологий. В исследовании проекты классифицировались по размеру в зависимости от количества строк кода (от 2 до 100 тысяч), а также по языку программирования (от ассемблеров до высокоуровневого языка PL/1). Эти проекты были основаны на водопадной (классической) модели жизненного цикла разработки ПО, доминировавшей в отрасли в 1981 году. В 1997 году была разработана модель COCOMO II, окончательно доработанная и опубликованная в 2000 году в книге «Оценка стоимости разработки ПО с COCOMO II». COCOMO II является наследником первоначальной модели и более подходящей для оценивания современных проектов разработки ПО. Она предоставляет более полную поддержку современных процессов разработки ПО и построена на обновленной базе проектов. COCOMO состоит из иерархии трех последовательно детализируемых и уточняемых форм. Первый уровень, Базовый, подходит для быстрых ранних оценок стоимости разработки ПО и обладает неточностью вследствие некоторых факторов, которые невозможно учесть на ранних стадиях разработки. Средний уровень COCOMO учитывает эти факторы, тогда как Детальный уровень дополнительно учитывает влияние отдельных фаз проекта на его общую стоимость. Базовый уровень (COCOMO Model 1: Basic) Базовый уровень рассчитывает трудоемкость и стоимость разработки как функцию от размера программы. Размер выражается в оценочных тысячах строк кода (KLOC - kilo lines of code). COCOMO применим к трем классам проектов разработки ПО: • Органический (Organic mode) – маленькие команды с хорошим опытом работы и не жесткими требованиями к разработке • Полуразделенный вид (Intermediate/Semi-detached mode) – средние по размеру команды со смешанным опытом разработки и со смешанными требованиями (как жесткими, так и нет). • Встроенный вид (Intered/Embedded mode) – разрабатываются с учетом множества жестких ограничений (по аппаратному, программному, операционному обеспечению и т.д.) Вот базовые уравнения COCOMO: Трудоемкость= ab(KLOC)bb [человеко-месяцев] Срок разработки или длительность= cb(Трудоемкость)db[месяцев] Число разработчиков= Трудоемкость/ Срок разработки[человек] Коэффициенты ab, bb, cb и db приведены в следующей таблице. Таблица 5. Коэффициенты модели COCOMO Базового уровня Тип проекта ab bb cb db Органический 2.4 1.05 2.5 0.38 Полуразделенный 3.0 1.12 2.5 0.35 Встроенный 3.6 1.20 2.5 0.32 Базовый уровень COCOMO хорош для быстрой оценки стоимости разработки. Однако он не принимает во внимание различия в аппаратных ограничениях, качестве и опыте персонала, а также использованию современных техник и средств разработки и других факторов. Средний уровень (COCOMO Model 2: Intermediate) Средний уровень рассчитывает трудоемкость разработки как функцию от размера программы и множества «факторов стоимости», включающих субъективные оценки характеристик продукта, проекта, персонала и аппаратного обеспечения. Это расширение включает в себя множество из четырёх факторов, каждый из которых имеет несколько дочерних характеристик. • Характеристики продукта ◦ Требуемая надежность ПО ◦ Размер БД приложения ◦ Сложность продукта • Характеристики аппаратного обеспечения ◦ Ограничения быстродействия при выполнении программы ◦ Ограничения памяти ◦ Неустойчивость окружения виртуальной машины ◦ Требуемое время восстановления • Характеристики персонала ◦ Аналитические способности ◦ Способности к разработке ПО ◦ Опыт разработки ◦ Опыт использования виртуальных машин ◦ Опыт разработки на языках программирования • Характеристики проекта ◦ Использование инструментария разработки ПО ◦ Применение методов разработки ПО ◦ Требования соблюдения графика разработки Каждому из этих 15 факторов ставится в соответствие рейтинг по шести бальной шкале, начиная от «очень низкий» и до «экстравысокого» (по значению или важности фактора). Далее значения рейтинга заменяются множителями трудоемкости из нижеприведенной таблицы. Произведение всех множителей трудоемкости составляет Регулирующий фактор трудоемкости (РФТ). Обычно он принимает значения в диапазоне от 0.9 до 1.4. Коэффициенты представлены в таблице ниже. Таблица 6. Коэффициенты рейтинга Факторы стоимости Рейтинг Очень низкий Низкий Средний Высокий Очень высокий Критический Характеристики продукта 1. Требуемая надежность ПО 0.75 0.88 1.00 1.15 1.40 2. Размер БД приложения 0.94 1.00 1.08 1.16 3. Сложность продукта 0.70 0.85 1.00 1.15 1.30 1.65 Характеристики аппаратного обеспечения 4. Ограничения быстродействия при выполнении программы 1.00 1.11 1.30 1.66 5. Ограничения памяти 1.00 1.06 1.21 1.56 6. Неустойчивость окружения виртуальной машины 0.87 1.00 1.15 1.30 7. Требуемое время восстановления 0.87 1.00 1.07 1.15 Характеристики персонала 8. Аналитические способности 1.46 1.19 1.00 0.86 0.71 9. Опыт разработки 1.29 1.13 1.00 0.91 0.82 10. Способности к разработке ПО 1.42 1.17 1.00 0.86 0.70 11. Опыт использования виртуальных машин 1.21 1.10 1.00 0.90 12. Опыт разработки на языках программирования 1.14 1.07 1.00 0.95 Характеристики проекта 13. Применение методов разработки ПО 1.24 1.10 1.00 0.91 0.82 14. Использование инструментария разработки ПО 1.24 1.10 1.00 0.91 0.83 15. Требования соблюдения графика разработки 1.23 1.08 1.00 1.04 1.10 Формула модели COCOMO для среднего уровня принимает вид E=ai(KLoC)(bi)РФТ где E – трудоемкость разработки ПО в человеко-месяцах, KLoC – оценочный размер программы в тысячах строках исходного кода, и РФТ – регулирующий фактор. Коэффициенты ai и показатель степени bi представлены в следующей таблице. Таблица 7. Коэффициенты Среднего уровня модели COCOMO Тип проекта ai bi Органический 3.2 1.05 Полуразделенный 3.0 1.12 Встроенный 2.8 1.20 Расчет времени разработки для среднего уровня COCOMO совпадает с расчетом для Базового уровня. Детальный уровень (COCOMO Model 3: Advanced/Detailed) Детальный уровень включает в себя все характеристики среднего уровня с оценкой влияния данных характеристик на каждый этап процесса разработки ПО. Оценка метода COCOMO Критерии для применения метода COCOMO • Средние и крупные проекты Для небольших проектов, затраты на проведение оценки в соответствии со средним и детальным уровнями метода COCOMO слишком высоки. Однако результаты оценки, полученные от применения одного лишь базового уровня метода COCOMO, недостаточно точны. • Техническое применение Для программных проектов, занятых разработкой коммерческих приложений, метод COCOMO обычно приводит к завышенным значениям оценки затрат. Поэтому метод COCOMO применяется только к разработке технического программного обеспечения. Моделью СОСОМО 81 предусмотрена разработка программного обеспечения в соответствии с каскадной моделью, причем предполагается, что большая часть системы разрабатывается "с нуля". Однако со времени первой версии данной модели было сделано несколько фундаментальных изменений в целях ее усовершенствования. Теперь модель допускает производство ПО путем компоновки повторно используемых компонентов, связывая их между собой с помощью какого-либо языка сценариев. Сегодня прототипирование и пошаговая разработка - наиболее распространенные модели создания программного продукта. Во многих случаях используются серийные компоненты, доступные на рынке программных продуктов. Кроме того, существующие программы модифицируются в целях создания нового программного обеспечения. В таблице 7 приведены упрощенные формулы для оценки трудоемкости проекта. Таблица 7. Модель СОСОМО 81 Сложность проекта Формула* Описание Простой проект РМ = 2.4 (KDSI)1.05 хМ Простые проекты для небольших команд разработчиков Средней сложности РМ = 3.0 (KDSI)1.12 xM Более сложные проекты, при разработке которых члены команды могут ощущать нехватку опыта и знаний соответствующих систем Проект встроенной РМ = 3.6 (KDSI)1.20хМ Сложные проекты, где ПО является частью комплекса аппаратных системы и программных средств, других технических механизмов и устройств * В этих формулах РМ (от Person-Months) обозначает человеко-месяцы, KDSI (от thousand (Kilo-) of Delivered Source Instructions) - количество инструкций (в тысячах) в конечной программе (общепринятая единица измерения объема работ по программированию). Принимая во внимание все эти изменения, модель СОСОМО 2 допускает самые разнообразные подходы к процессу разработки программных продуктов: прототипирование, сборку систем из отдельных компонентов, использование языков программирования четвертого поколения и т.д. Но теперь уровни модели не только отображают возрастающую сложность определения себестоимости разработки ПО, но и учитывают этапы работы над программой, что позволяет провести предварительную оценку себестоимости на ранних этапах выполнения проекта с последующей ее детализацией после определения архитектуры системы. 1. Уровень предварительного прототипирования. Для определения необходимых затрат осуществляется оценка размера системы на основе объектных точек прототипа с помощью простой формулы "размер-производительность". 2. Уровень предварительного проектирования. Этот уровень предусматривает окончание работы над системными требованиями и, возможно, над начальным проектом архитектуры программы. Оценка затрат на этом уровне основана на функциональных точках, которые затем пересчитываются в количество строк кода программ. Здесь используются формулы, подобные описанным выше, с соответствующим набором множителей. 3. Постархитектурный уровень. После разработки архитектуры системы существует реальная возможность достаточно точно оценить размер программы. Однако оценка на этом уровне уже будет включать более расширенный ассортимент множителей, которые должны отражать возможности персонала, а также характеристики создаваемого программного продукта и проекта в целом. Уровень предварительного прототипирования Этот уровень был введен в модель СОСОМО для оценки затрат на прототипирование проектов, а также для тех проектов, в которых программное обеспечение разрабатывалось путем сборки уже существующих компонентов. Здесь оценка затрат основана на подсчете взвешенных объектных точек (это понятие рассматривается в разделе 1), деленных на стандартное значение производительности. Производительность зависит от опыта и способностей разработчика, а также от возможностей CASE-средств, используемых для поддержки процесса разработки. В табл. 8. показаны различные уровни производительности, которые были предложены разработчиками модели. Таблица 8. Производительность, выраженная в объектных точках Опыт и возможности программиста Очень низкие Низкие Средние Высокие Очень высокие Уровень и возможности CASE-средств Очень низкие Низкие Средние Высокие Очень высокие Производительность (количество объектных точек в месяц) 4 7 13 25 50 На этом уровне повторное использование компонентов не редкость, поэтому прогнозируемое количество объектных точек должно учитывать процентное соотношение (долю) повторного использования компонентов (далее обозначено как % многократного использования). Таким образом, формула для предварительного определения объема работ будет выглядеть следующим образом: РМ = (NOP х (1 - %многократного использования/100))/ PROD. Здесь РМ — это затраты, выраженные в человеко-месяцах, NOP - количество объектных точек, a PROD - производительность, как показано в табл. 8. Уровень предварительного проектирования На этом этапе оценка основана на стандартной формуле алгоритмических моделей, а именно: затраты = А х размерВ х М. Основываясь на собственном банке данных, Боэм (Boehm) предложил значение коэффициента А принять равным 2.5, если оценка осуществляется на этом уровне. Размер системы выражается в KSL0C, что означает количество строк программного кода в тысячах. Он определяется путем подсчета количества функциональных точек в программе и перевода их в KSL0C с помощью стандартных таблиц, которые определяют соотношение размера программы с функциональными точками для различных языков программирования. Эта оценка размера применима скорее к кодам, написанным вручную, нежели к генерированным или повторно используемым. Показатель степени В отражает затраты, которые увеличиваются по мере увеличения размера проекта. Это не постоянная величина, как в предыдущей версии модели СОСОМО, она изменяется от 1.1 до 1.24, что зависит от того, насколько новаторским является данный проект, от гибкости процесса разработки ПО, от применяемых процессов управления рисками, сплоченности команды программистов и уровня управления организацией-разработчиком. О том, как рассчитывается этот показатель, речь идет в следующем разделе. Множитель М является произведением семи показателей, характеризующих проект и процесс создания ПО, а именно: надежность и уровень сложности разрабатываемой системы (RCPX), повторное использование компонентов (RUSE), сложность платформы разработки (PDIF), возможности персонала (PERS), опыт персонала (PREX), график работ (SCED) и средства поддержки (FCIL). Это позволяет провести оценивание по шестибалльной шкале, где число 1 будет соответствовать самым малым значениям этих показателей, а число 6 - самым высоким значениям. С другой стороны, их можно вычислить путем комбинирования значений более детализированных показателей, которые используются на постархитектурном уровне. Таким образом, оценка затрат вычисляется по следующей формуле: РМ = А х размерВ х М + РМт, где М = PERS х RCPX x RUSE x PDIF x PREX x FCIL x SCED. Последнее слагаемое в формуле (РМт) обозначает фактор, используемый в случаях, когда значительная часть кода генерируется автоматически. При этом часть кода всегда требуется вводить вручную, но уровень производительности все равно будет выше, чем при полностью ручном вводе. Затраты РМт рассчитываются отдельно по приведенной ниже формуле, а затем добавляются к оценке затрат на введенный вручную код. PMт = (ASLOC х (AT/100))/ ATPROD, где ASLOC — это количество строк кода, произведенных автоматическим способом, ATPROD - уровень производительности автоматической генерации кода. Однако следует заметить, что требуется также выполнение определенных работ для согласования сгенерированного кода с остальной частью системы. Объем этих работ зависит от процента автоматически сгенерированного кода во всей системе (коэффициент AT). Фактически производительность зависит от количества созданных программных модулей. Чем меньше объем сгенерированного кода, тем больший объем работ необходим для интеграции его с другими кодами системы. Постархитектурный уровень Для получения оценки на постархитектурном уровне используется такая же формула, как и для оценки на уровне предварительного проектирования. На этом уровне оценка будет более точной, для предварительной оценки затрат будут использоваться уже не семь, а семнадцать показателей. Здесь при оценке количества строк программного кода учитываются два важных фактора. • Возможность изменения системных требований. Следует учитывать повторные работы, которые необходимо выполнить вследствие изменения системных требований. Оценка этих работ выражается в количестве строк программного кода, которое необходимо изменить, и затем прибавляется к предварительной оценке размера системы. • Степень повторного использования компонентов. Если степень повторного использования программных компонентов значительна, в оценку количества строк разрабатываемого кода необходимо внести поправки. Однако расходы на повторное использование компонентов не всегда линейно зависят от размера этих компонентов, так как требуют затрат на их подбор и на то, чтобы разобраться с их возможностями и интерфейсами; кроме того, могут потребоваться затраты на внесение изменений в эти компоненты. Оценка затрат на повторное использование компонентов в модели СОСОМО 2 рассчитывается по следующей формуле: ESLOC = ASLOC х (АА + SU + 0.4 DM + 0.3 СМ + 0.3 1М)/100. Здесь ESLOC - количество строк нового кода, ASLOC - количество строк повторно используемого кода, требующего изменений, DM - процент изменений в архитектуре системы, СМ - процент измененного кода, a IM - процент затрат на интеграцию повторно используемого программного обеспечения. Коэффициент SU зависит от затрат на адаптацию повторно используемых программных компонентов и колеблется в пределах от 50 (для сложного неструктурированного кода) до 10 (для грамотно написанного объектно-ориентированного кода). Коэффициент АА отображает затраты на начальную оценку возможности повторного использования компонентов. Его значение колеблется от 0 до 8. Показатель степени в формуле расчета затрат в модели СОСОМО 1 имеет три возможных значения, которые соотносятся с различными уровнями сложности проекта. С возрастанием уровня сложности проекта увеличивается значимость размера системы. Однако отрицательный эффект размера системы можно нивелировать с помощью организационных мероприятий, что учтено в модели СОСОМО 2. Здесь показатель степени рассчитывается с учетом пяти показателей, которые описаны в табл. 9. Они отсчитываются по шестибалльной шкале от низшего (5 баллов) до наивысшего (0 баллов) уровня. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени. Таблица 9. Показатели, используемые при расчете показателя степени в модели СОСОМО 2 Показатель Пояснение Новизна проекта Отображает предыдущий опыт организации в реализации проектов данного типа. Очень низкий уровень этого показателя означает отсутствие опыта, наивысший уровень указывает на компетентность организации-разработчика в данной области ПО Гибкость процесса разработки Отображает возможность изменения процесса разработки ПО. Очень низкий уровень этого показателя означает, что процесс определен заказчиком заранее, наивысший - заказчик определил лишь общие задачи без указания конкретной технологии процесса разработки ПО Анализ архитектуры системы и рисков Отображает степень детализации анализа рисков, основанного на анализе архитектуры системы. Очень низкий уровень данного показателя соответствует поверхностному анализу рисков, наивысший уровень означает, что был проведен тщательный и полный анализ всевозможных рисков Сплоченность команды Отображает степень сплоченности команды и их способность работать совместно. Очень низкий уровень этого показателя означает, что взаимоотношения в команде сложные, а наивысший - что команда сплоченная и эффективная в работе, не имеет проблем во взаимоотношениях Уровень развития процесса разработки Отображает уровень развития процесса создания ПО в организации-разработчике. Оценка этого показателя основывается на вопроснике. Приведем пример. Предположим, организация-разработчик выполняет программный проект в той области, в которой у нее мало опыта разработок. Заказчик ПО не определил технологический процесс, который будет использовать при создании программного продукта, а также не выделил в плане работ времени на анализ возможных рисков. Для создания программной системы необходимо сформировать новую команду специалистов. Организация-разработчик недавно привела в действие программу усовершенствования технологического процесса разработки. Для оценки показателя степени используются перечисленные ниже показатели проекта. 1. Новизна проекта. Это новый проект для организации, данный показатель имеет низкий уровень (оценивается в 4 балла). 2. Гибкость процесса разработки. Нет вмешательства заказчика - уровень показателя очень высокий (оценивается в 1 балл). 3. Анализ архитектуры системы и рисков. Анализ не был проведен - уровень данного показателя очень низкий (оценивается в 5 баллов). 4. Сплоченность команды. Команда разработчиков новая, информация о ней отсутствует - уровень этого показателя оценивается как обычный (3 балла). 5. Уровень развития процесса разработки. Определенное управление проектом имеет место -показатель оценивается как обычный (3 балла). Сумма значений всех этих показателей составляет 16 баллов, поэтому значение показателя степени будет равно 1.17. Проектные характеристики, используемые для уточнения предварительной оценки затрат на постархитектурном уровне (табл. 10), разбиваются на четыре группы. 1. Характеристики программного продукта, которые определяются системными требованиями. 2. Характеристики аппаратных средств, представляющие собой ограничения, накладываемые на разрабатываемое ПО выбранной платформой вычислительных средств. 3. Характеристики персонала, которые учитывают опыт и возможности специалистов, работающих над проектом. 4. Характеристики проекта, учитывающие определенные параметры и показатели проекта разработки ПО. Таблица 10. Проектные характеристики, формирующие стоимость проекта Характеристики программного продукта RELY Требуемая надежность системы CPLX Сложность системных модулей DOCU Объем необходимой документации DATA Размер используемой базы данных RUSE Процент повторного использования компонентов Характеристики аппаратных средств TIME Показатели, ограничивающие время исполнения PVOL Возможность изменения платформы разработки STOR Ограничение объема памяти Характеристики персонала ACAP Способности лиц, выполняющих анализ проекта PCON Сплоченность команды разработчиков PEXP Опыт программирования в данной области ПО PCAP Способности программистов AEXP Опыт аналитика проекта в данной области ПО LTEX Опыт применения данного языка программирования и средств разработки Характеристики проекта TOOL Использование вспомогательных программных средств SCED Уплотнение графика работ SITE Количество работ, выполняемых в разных местах, и качество коммуникаций В табл. 11 показан пример того, каким образом эти характеристики влияют на предварительную оценку затрат. Я взял показатель степени 1.17, полученный в предыдущем примере, и предположил, что RELY, CPLX, STOR, TOOL и SCED являются основными характеристиками, формирующими стоимость проекта. Все другие характеристики имеют значение 1, поэтому не влияют на оценку затрат. Таблица 11. Расчет оценки затрат Значение показателя степени 1.17 Размер системы (с учетом повторного использования компонентов и возможного изменения требований) 128 000 DSI* Начальная оценка по модели СОСОМО без учета проектных характеристик 730 человеко-месяцев Надежность системы Очень высокая, множитель 1.39 Сложность системных модулей Очень высокая, множитель 1.3 Ограничение объема памяти Высокое, множитель 1.21 Использование вспомогательных средств Низкое, множитель 1.12 График работ Ускоренный, множитель 1.29 Уточненная оценка по модели СОСОМО 2306 человеко-месяцев Надежность системы Очень низкая, множитель 0.75 Сложность системных модулей Очень низкая, множитель 0.75 Ограничение объема памяти Нет, множитель 1 Использование вспомогательных средств Очень высокое, множитель 0.72 График работ Нормальный, множитель 1 Уточненная оценка по модели СОСОМО 295 человеко-месяцев * DSI (Delivered Source Instructions) – количество инструкций в конечной программе. В этом примере я присвоил максимальные и минимальные значения ключевым характеристикам с тем, чтобы показать, каким образом они влияют на оценку затрат. Значения были взяты из руководства по модели СОСОМО 2. Вы можете сами убедиться, что высокие значения для характеристик, влияющих на формирование стоимости, привели к увеличению оценки затрат более чем в три раза, тогда как при низких значениях оценка затрат была снижена почти в три раза по сравнению с начальной. Этот пример показывает отличия разных типов проектов, а также трудности переноса опыта разработок из одной области ПО в другую. Хотя формула, предложенная разработчиками модели СОСОМО, отображает их опыт разработчиков и основана на большой базе данных, однако я полагаю, что эта модель излишне сложна для практического использования. Слишком много показателей необходимо учитывать и слишком широкие рамки для определения их значений. Таким образом, каждый, кто хочет воспользоваться этой моделью, должен выверить и приспособить ее к своим данным, накопленным при реализации предыдущих проектов, так как именно они дадут информацию о тех частных обстоятельствах, которые могут оказать влияние на ход выполнения данного проекта. Некоторые организации накопили достаточно информации о прошлых проектах в той форме, которая способна проверить и настроить модель СОСОМО 3.2. Алгоритмические модели стоимости в планировании проекта Алгоритмические модели стоимости применяются для сравнения различных инвестиций в целях снижения стоимости проекта. Это особенно важно в тех случаях, когда принимаются решения в отношении покупки аппаратных или программных средств либо, возникает необходимость найма новых сотрудников с особыми навыками, нужными для реализации проекта. В качестве примера рассмотрим встроенную систему для управления экспериментом, который будет проводиться в космосе. Оборудование для проводимых в космосе экспериментов должно быть предельно надежным и подлежит строгим весовым ограничениям. Поэтому, например, может появиться необходимость свести к минимуму количество чипов на монтажной плате. Если взять для оценки модель СОСОМО, то множители, зависящие от ограничений в проекте и надежности, будут иметь значение больше единицы. Стоимость проекта складывается из трех компонентов. 1. Стоимость целевых аппаратных средств, на которых будет функционировать разрабатываемая система. 2. Стоимость платформы (вычислительная техника плюс программное обеспечение), используемой для разработки системы. 3. Стоимость затрат на разработку системы. На рис. 2 представлены некоторые проектные показатели и характеристики, которые могут учитываться при расчете стоимости. Например, снижение стоимости ПО может потребовать больших затрат на целевые аппаратные средства или вложения дополнительных средств в усовершенствованные инструменты разработки. Рис. 2. Показатели и характеристики проекта Дополнительные расходы на аппаратные средства в данном случае допустимы, так как разрабатываемая система является узкоспециализированной и не предназначена для массовой продажи. Если же аппаратные средства встраивается в коммерческие продукты, то дополнительные вложения в целевые аппаратные средства (для снижения стоимости ПО) используются редко, потому что это повышает цену продаваемого продукта. В табл. 12 показаны аппаратные и программные средства, обеспечивающие реализацию характеристик А-Е, описанных на рис. 2. Стоимость данного проекта в соответствии с моделью СОСОМО 2 (без учета проектных характеристик (множителей), влияющих на формирование стоимости см. предыдущий раздел) оценивается в 45 человеко-месяцев. Стоимость затрат на один человеко-месяц составляет 15000. Соответствующие множители, влияющие на формирование стоимости, учитывают ограниченность времени исполнения и объема памяти (показатели TIME и STORE), доступность средств поддержки системы разработки, таких, как кроссплатформенные компиляторы и т.п. (показатель TOOL), и опыт команды разработчиков (показатель LTEX). Для всех проектных характеристик множитель RELY (показатель надежности) равен 1.39; это означает, что для разработки надежной системы требуются дополнительные затраты. Стоимость программного продукта (SC) вычисляется следующим образом: SC = оценка затрат х RELY x TIME x STOR x TOOL x EXP x 15000. Проекту с характеристикой А соответствует стоимость разработки системы с уже имеющимся персоналом и средствами поддержки. Проекты с другими характеристиками требуют расходов либо на аппаратные средства, либо на наем нового персонала (с соответствующими расходами и степенью риска). На примере проекта с характеристикой Б видно, что модернизация аппаратных средств не обязательно снизит затраты, так как множитель, учитывающий опыт команды разработчиков, в этом случае будет очень весомым. Также видно, что модернизация только памяти окажется более эффективной, чем усовершенствование всей вычислительной системы. Таблица 12. Параметры стоимости Характеристика RELY STOR TIME TOOL LTEX Общие затраты Стоимость ПО Стоимость аппаратных средств Итоговая стоимость А 1.39 1.06 1.11 0.86 1 63 949 393 100 000 1 049 393 Б 1.39 1 1 1.12 1.22 88 1313 550 120 000 1 402 025 В 1.39 1 1.11 0.86 1 60 895 653 105 000 1 000 653 Г 1.39 1.06 1.11 0.86 0.84 51 769 008 100 000 897 490 Д 1.39 1 1 0.72 1.22 56 844 425 220 000 1 044 159 Е 1.39 1 1 1.12 0.84 57 851 180 120 000 1 002 706 Проектная характеристика Г обеспечивает самые низкие затраты на разработку системы. Здесь нет необходимости в дополнительных затратах на аппаратные средства, зато нужно нанимать новый персонал для работы по проекту. Если такой персонал уже имеется в наличии в организации-разработчике, тогда этот вариант будет наиболее выгодным и выбор следует остановить именно на нем. Если же нет, то наем нового персонала порождает дополнительные расходы и риски. Это может привести к тому, что преимущества в стоимости могут оказаться не такими значительными, как показано в табл. 12. В проекте с характеристикой В сэкономлено почти 50 000, при этом риск практически отсутствует. Менеджеры проектов с консервативным складом ума предпочтут этот вариант более рискованному варианту Г. Приведенный анализ показал важность такого показателя, как опыт персонала. Если организация наймет квалифицированных сотрудников с большим опытом, это может значительно снизить стоимость проекта. Данный показатель напрямую связан с факторами производительности, описанными в разделе 1. Этот пример также показывает, что вложения в новые аппаратные средства могут оказаться не слишком выгодными. Обычно такую стратегию предпочитают программисты, которые любят работать с новыми системами. Однако недостаток опыта работы с новыми системами в данном случае может имеет более сильное отрицательное влияние на стоимость проекта, чем те преимущества, которые ожидаются от приобретения новых аппаратных средств. 4. Продолжительность проекта и наем персонала Кроме расчета затрат, необходимых для работы над проектом, и определения стоимости этих затрат, менеджеры проектов также должны определить длительность выполнения проекта (т.е. составить временной график работ) и время начала найма персонала для непосредственной работы. Чаще всего компании-разработчики "сжимают" график работ до минимума с тем, чтобы доставить программный продукт на рынок раньше своих конкурентов. Взаимосвязь между количеством работающих над проектом сотрудников, общими затратами и длительностью разработки не является прямолинейной. С увеличением количества сотрудников возрастают затраты, в том числе временные, поскольку больше времени будет уходить на общение внутри группы разработчиков. Также больше времени потребуется для определения интерфейсов между частями системы, которые они будут разрабатывать. Увеличивая вдвое количество персонала, нельзя гарантировать, что время разработки сократится также вдвое. Модель СОСОМО включает формулу для определения календарного времени (TDEV) реализации проекта. Для всех уровней модели СОСОМО существует единая формула расчета времени: TDEV = 3x(PM)(0.33 + 0.2*(B-1.01)) где РМ - оценка затрат в человеко-месяцах, В - показатель степени, способ определения которого описан ранее (В равен единице для уровня предварительного прототипирования). С помощью этой формулы определяется прогнозируемая длительность проекта. Однако прогнозируемая длительность проекта и продолжительность графика работ, который определяется планом выполнения проекта, — это не одно и то же. Планируемый график работ может оказаться длиннее или короче прогнозируемой длительности проекта. Разность между этими двумя длительностями учитывается в модели СОСОМО 2: TDEV = 3 х (РМ) (0.33 + 0.2*(В - 1.01)) х %SCED/100 где %SCED - процент увеличения (или уменьшения) прогнозируемой длительности проекта. Значительные расхождения прогнозируемой длительности с планируемым графиком работ означают неминуемые проблемы в процессе реализации проекта. Рассмотрим пример вычисления длительности проекта по модели СОСОМО в предположении, что, по предварительной оценке, затрат для реализации проекта требуется 60 человеко-месяцев (проект с характеристикой В из табл. 12.). Примем число 1.17 за значение показателя степени В. Тогда TDEV = 3(60) 0.36 = 13 месяцев. Если в данном случае нет расхождения с длительностью графика работ, последнее выражение в формуле длительности не влияет на окончательный результат. Интересным в модели СОСОМО может показаться то, что время, требующееся для реализации проекта, — это функция всех затрат по проекту. Причем оно не зависит от количества программистов, работающих над проектом. Это подтверждает идею о том, что не имеет смысла включать большее количество программистов в отстающий от графика проект с тем, чтобы ускорить его завершение. В литературе исследован вопрос ускорения реализации проекта и сделан вывод, что в работе неизбежны проблемы, если для разработки ПО не выделяется достаточно времени. Распределяя прогнозируемые затраты на реализацию проекта, мы все же не можем точно знать, сколько человек необходимо включить в команду разработчиков. Часто набор программистов происходит по принципу от меньшего к большему с последующим постепенным уменьшением их численности. Это объясняется тем, что на раннем этапе разработки требуется относительно небольшое количество специалистов, которые будут заниматься только планированием системы и разработкой спецификации. По мере выполнения проекта увеличивается и объем выполняемых работ, а количество персонала увеличивается до максимума. После кодирования и тестирования системы количество специалистов уменьшается, пока не остается один-два человека. Очень быстрое наращивание количества персонала часто указывает на отставание проекта от графика работ. Менеджерам не следует набирать слишком много специалистов на самом раннем этапе выполнения проекта. Наращивание объема работ можно смоделировать с помощью так называемой кривой Рэлея; оценочная модель Путмана (Putnam) использует модель наращивания персонала, основанную на этих кривых. Модель Путмана учитывает время разработки как ключевой фактор, поскольку с уменьшением времени на разработку экспоненциально увеличиваются затраты на создание системы.