Блог оценщика Как начать зарабатывать в сети интернет:полные пошаговые методики
Related Articles
COCOMO (COnstructive COst MOdel)
COCOMO и ее производные – одни из самых популярных моделей оценки трудоемкости создания ПО. Эту программу легко найти в свободном доступе, кроме того, у нее открытый расчет, и вы можете сами шаг за шагом воссоздать ее, что называется, вручную. Поэтому я решил остановиться на ней поподробнее.
COCOMO была создана Барри Боэмом в 1981 году. Первоначально он простроил ее на основе анализа 63 проектных разработок ПО американской аэрокосмической компании, будучи в этой организации директором отдела исследований. В 1997 году он доработал свою модель, дав ей название COCOMO II, а в 2000 году вышла в свет ее окончательная, обновленная версия.
В рамках модели COCOMO существуют три последовательных уровня, различающиеся набором используемых параметров, который расширяется при переходе с одного уровня на другой, и степенью точности входящих данных:
- предварительная модель (Application Composition Model);
- предпроектная модель (Early Design Model);
- детальная модель (Post Architecture Model).
Предварительная модель (базовый уровень) подходит для быстрых оценок на ранних стадиях разработки ПО, когда некоторые факторы невозможно учесть, поскольку вначале они еще не определены. Предпроектная модель (средний уровень) уже учитывает эти факторы. Детальная модель, помимо дополнительных факторов, учитывает влияние отдельных фаз проекта на его общую стоимость.
Модель COCOMO основана на простой формуле регрессии, параметры которой обусловлены отраслевыми данными и характеристиками рассматриваемого проекта. Расчет трудоемкости проекта производится в человеко-месяцах, базовая формула имеет вид:
где:
- SIZE — размер IT-продукта в KSLOC;
- EMi — множители трудоемкости;
- SFj — факторы масштаба;
- А – постоянный коэффициент, зависящий от организации-разработчика и типа разрабатываемого ПО;
- В – коэффициент, отражающий объем работ, необходимый для реализации больших проектов;
- n=7 — для предпроектной модели;
- n=17 — для детальной модели.
Как видно из формулы, одним из основных показателей, влияющих на результат расчета, является размер программного продукта, измеряемый тысячами строк исходного кода (KSLOC, Kilo Source Lines Of Code). Отмечу, что здесь речь идет о логических строках. Если размер оцениваемого ПО был определен по методу функциональных точек, то можно рассчитать количество строк кода, приходящихся на одну функциональную точку, путем применения статистических отраслевых коэффициентов.
Множителями М являются показатели, характеризующие проект и процесс разработки ПО (например, RCPX – надежность и уровень сложности разрабатываемого продукта, PDIF – сложность платформы разработки, PERS и PREX – возможности и опыт персонала и т.д.). Из семи параметров для предпроектной модели в дальнейшем образуется семнадцать для детальной. Т.е., к примеру, упомянутый выше RCPX детализируется еще в четырех показателях: RELY – степень надежности системы, CPLX – ее уровень сложности, DOCU – объем соответствующей документации, DATA – объем используемых данных. Каждому показателю присваивается определенное значение, которое берется из специальной таблицы.
Напомню, что при применении модели COCOMO мы получаем трудозатраты в человеко-месяцах. В данной модели (как, впрочем, и в остальных, подобных ей) в месячную норму заложено 152 человеко-часа, с учетом возможных отпусков и больничных персонала.
Теперь немного о недостатках COCOMO. По мнению экспертов, эта модель уже устаревает и не подходит для оценки трудозатрат на разработку сложных современных программных комплексов. Она хороша для цельных программ, не интегрированных в другие, написанных на языках третьего уровня (Java, Pascal, Delphi). Современные же ПО зачастую разрабатываются на базе других программ, которые изменяются и дорабатываются. Для таких случаев COCOMO дает не слишком достоверные результаты, в силу того, что она в последний раз обновлялась в 2000 году, когда таких программных комплексов еще не было.
SLIM на базе CONSTRUX ESTIMATE VERSION 2.0.
Модель SLIM была создана компанией CONSTRUX. Ее можно бесплатно скачать с интернет-сайта этой компании. В отличие от COCOMO, SLIM имеет закрытый расчет. Это значит, что для определения трудозатрат по модели SLIM вам нужно только запустить ее, заполнить предлагаемые поля, а затем программа сама все посчитает и выдаст результат. При вводе параметров вы увидите, что по смыслу они аналогичны показателям, которые используются в COCOMO.
В модели SLIM применяется метод Монте-Карло. Результат расчета в SLIM представлен в виде таблицы, отражающей, с какой вероятностью, за какое количество человеко-месяцев будет разработано оцениваемое ПО. Соответственно, оценщику нужно выбрать среднее значение наиболее вероятного диапазона трудозатрат, указанного в таблице.
SEER FOR SOFTWARE компании Galorath
Это «продвинутая» модель, которая постоянно обновляется. В отличие от первых двух моделей, SEER FOR SOFTWARE дает более достоверные результаты при применении к современным сложным IT-продуктам. В этой модели, например, есть возможность учитывать модификации и доработки, которые производились в оцениваемом программном комплексе. Также есть возможность учесть сопровождение на первом этапе опытной эксплуатации IT-продукта. Однако, чтобы воспользоваться этой моделью, вам придется сначала купить на нее лицензию у разработавшей ее компании Galorath. Понятно, что вы не станете этого делать ради одного-единственного заказа на оценку IT-продукта.
У этой модели закрытый расчет, и ее применение также сводится к правильному вводу запрашиваемых программой параметров и получению соответствующих результатов. Таким образом, к отчету об оценке ПО вам нужно будет приложить снимки экрана вашего монитора, подтверждающие результаты расчета данной моделью трудоемкости разработки оцениваемого IT-продукта.
Достоинством данной модели является не только проведение расчетов по параметрам, аналогичным тем, которые используются в COCOMO, но и возможность воспользоваться базой данных по сходным проектам. Тогда оценка трудозатрат получится более точной.
Кроме того, в отличие от COCOMO, в SEER FOR SOFTWARE размер оцениваемой программы определяется не по количеству строк кода, а по числу функциональных точек. Дело в том, что количество строк кода зависит от того, насколько программист эффективно реализовал в них ту или иную функцию программы. Опытные разработчики предпочитают писать меньше кода, достигая той же функциональности. Поэтому для правильной оценки потребуется запросить у заказчика код оцениваемого ПО и разобраться в нем. Для оценки же по функциональным точкам нужна лишь документация к программе, которая подробно описывает ее возможности.
Расчет прибыли предпринимателя
По вопросу расчета предпринимательской прибыли обычно возникает много дискуссий. Я бы хотел отметить следующее. Если разработка оцениваемой программы занимает длительное время (например, несколько лет), то стоит учитывать, что средства в разработку вкладываются на разных этапах (в течение ряда лет), поэтому величину предпринимательского дохода надо рассчитывать с учетом наращения.
Расчет накопленного износа
В силу того, что IT-продукты относятся к нематериальным активам, они могут быть подвержены функциональному и экономическому устареванию (физический износ отсутствует). Обычно возникает сложность с определением функционального износа: учитывать или не учитывать.
Экономический срок жизни небольших программ составляет, в среднем, 3-5 лет, крупные дорогостоящие программные комплексы рассчитаны лет на 10. Если ПО было однажды разработано и более не дорабатывалось, то, с большой степенью вероятности, через несколько лет оно уже будет никому не нужно. На рынке ежегодно появляются программные продукты с улучшенной функциональностью, работающие на новых платформах. Поэтому в такой ситуации функциональный износ у ПО налицо. Если же оцениваемое ПО имеет техническое сопровождение на протяжении всего срока своей жизни, т.е. постоянно обновляется и потому сохраняет свою актуальность для пользователей, можно говорить об отсутствии функционального устаревания.
Резюме
Думаю, вам уже стало ясно, что оценка исключительных прав на IT-продукты затратным подходом требует привлечения IT-специалистов. Квалифицированный разработчик ПО, обладающий опытом работы в различных проектах, с широким профессиональным кругозором, сможет разобраться в метриках программного продукта и подобрать подходящую модель для расчета трудоемкости его разработки. Задачей оценщика останется проведение заключительных расчетов рыночной стоимости ПО, описание выполненных исследований и обоснование принятых решений.
