Совершенствование методики экспертной оценки трудозатрат при оценке стоимости разработки ПО в судах
Проблематика
В ходе рассмотрения споров российские суды регулярно сталкиваются с необходимостью оценки стоимости программного обеспечения. Если ПО было создано на заказ, то у суда нет объективной оценки его стоимости, поскольку разработка носит уникальный характер. Классическим примером является спор по договору подряда, в соответствии с которым исполнитель обязался разработать некий программный продукт по согласованному с заказчиком техническому заданию. Однако по окончании очередного этапа или по результатам завершения разработки в целом заказчик отказывается принимать результат выполненных работ (программный продукт), ссылаясь на его несоответствие техническому заданию или договору. В этом случае судами назначается судебная экспертиза, цель которой — определить стоимость полностью разработанного программного продукта или его части.
В настоящий момент отсутствует общепринятая методика проведения таких экспертиз. При этом разные эксперты предлагают собственные методики и применяют их для проведения своих экспертиз.
В рамках настоящей статьи предлагается развитие и улучшение одной из существующих методик, а именно «Методики экспертной оценки трудозатрат».
Постановка задачи
Как справедливо отмечено в статье Евгения Царева «Методика экспертной оценки трудозатрат при оценке стоимости программного обеспечения в судах», опубликованной на https://www.anti-malware.ru/ (далее — базовая статья), в судах, а также досудебных спорах все чаще поднимается вопрос о стоимости разработки программного обеспечения.
Росту количества споров способствуют следующие факторы:
1) Рост рынка разработки программного обеспечения «под заказ».
2) Отсутствие четких законодательных регулирующих механизмов (существующие ГОСТы носят рекомендательный характер либо морально устарели).
3) Некомпетентность сторон (как со стороны заказчика, так и со стороны исполнителя).
4) Общее финансовое положение многих компаний и граждан, желающих минимизировать затраты или максимизировать доходность, в том числе и за счет подобных споров.
Если первый и последний факторы в целом не являются техническими, и даже организационными, то недостаточная законодательная база и формальный подход к постановке задачи, а зачастую и к приему/сдаче работ, требуют отдельного рассмотрения. Надеюсь, данная статья поможет не только в разрешении споров, но и в их предотвращении.
Ввиду сложности и большого разнообразия как категорий программных продуктов, так и средств их разработки, законодательством не определены четкие нормы времени по выполнению тех или иных работ, составляющих процесс создания, а также, что не маловажно, сопутствующие процессы.
Предлагаемое решение
Автором базовой статьи выделены четыре основных этапа:
-
Этап 1. Проектирование.
-
Этап 2. Разработка.
-
Этап 3. Тестирование.
-
Этап 4. Разработка документации.
Подобное разбиение видится недостаточным. Следует дополнить перечень как минимум подэтапами процесса проектирования. Как известно, разработка технического задания должна занимать не менее половины трудозатрат на создание информационной системы. В противном случае результат будет если не плохим, то далеким от ожидаемого. По этой причине следует выделить:
-
Описания функционала (принципиальная модель).
-
Описание структуры данных (модель данных).
-
Описание интерфейса (прототип, альбом макетов).
После этого составляется техническое задание на собственно разработку программного продукта.
Также в статье не освещены этапы внедрения, обучения, поддержки, написания технической документации (справочной, нормативной и т. д.). Справедливости ради следует отметить, что подобные этапы крайне редко являются причиной споров.
Как правило, к эксперту (в данном случае именно к эксперту, а не к оценщику), попадает договор на разработку (реже с техническим заданием) и функционирующий программный продукт. В ряде случаев доступны исходные коды программного продукта.
Исходя из этого рекомендуется учесть следующие значимые факторы этапа разработки программных продуктов:
-
Качество кода (степень структурированности).
-
Организацию структуры данных (степень нормализации).
-
Отображение интерфейса в различных режимах эксплуатации (различных платформах запуска, браузерах и т. д.).
Очевидно, что при отсутствии исходных кодов, эксперт вынужден оценивать систему как черный ящик. Это, с одной стороны, не позволяет провести полного исследования, но, с другой, повышает его объективность.
Поскольку достаточно часто применяется договорная основа Time & Material (T&M, «Оплата по факту»), в договоре следует четко указать средства фиксации времени трудозатрат — автоматизированные, бумажные. При возникновении споров будет не только дополнительная информация, но и возможность оценить уровень разработчиков — если разработчик тратит на создание, скажем, простого отчета для «1С» 5–6 часов, то его квалификация ниже средней, что важно для методики, указанной в базовой статье. Кроме того, при оценке квалификации специалиста (и, соответственно, стоимости часа его работы) следует учесть качество его работы. Например, использование запросов в циклах «1С» или применение сложного php-кода в шаблонах веб-страниц является технологически недопустимым, и обнаружение подобных примеров говорит о неудовлетворительной квалификации программиста.
Помимо этого, оценивая трудозатраты на разработку, следует учитывать два фактора:
-
Используемые средства разработки.
-
Объем используемых готовых решений.
Средства разработки принципиально влияют на процесс и скорость работы программиста. Безусловно, есть случаи, когда при помощи текстового редактора знающий программист за 15 минут сделает то, что разработчик, имеющий опыт два-три года, будет делать 30 минут с помощью системы программирования. Но в целом применение различных IDE (Integrated Development Environment — интегрированная среда разработки) в несколько раз снижает трудозатраты на разработку. При этом оценивая стоимость разработки, необходимо учитывать и стоимость применения самой IDE, что является, в свою очередь, нетривиальной задачей, поскольку лицензии на IDE, как правило, бессрочные (и могли приобретаться ранее для других проектов), а часть IDE — бесплатные.
Объем используемых готовых решений напрямую зависит от принятой технологии разработки (идеально, если она специфицирована в договоре или техническом задании). Однако на практике почти всегда приходится вручную определять объем заимствованного исходного кода. Причем подобный код не всегда должным образом обозначен — из умысла или нечаянно. Используемый сторонний исходный код может быть:
-
Корректно подключен как внешняя библиотека (самый простой случай, необходимо лишь исключить данную библиотеку из расчета трудоемкости и проверить лицензионное соглашение об использовании).
-
Скопирован в общий код (самый трудный случай, зачастую не удается выделить заимствованные фрагменты).
-
Вариативно скопирован в различные места исходных кодов без указания лицензионных соглашений, авторства и т. д., но и не отмечен как собственноручно разработанный.
Заимствован исходный код может быть как у сторонних разработчиков (открытые библиотеки типа jQuery) или на общедоступных ресурсах типа https://github.com/, так и, что часто встречается, из других проектов. При подобном заимствовании без явного указания признаками того, что модуль, библиотека и т. д. разрабатывались не в рамках проекта, являются:
-
Избыточный функционал;.
-
Следы другого проекта (в наименованиях процедур, справочной информации и т. д.);.
-
Подключение модуля, отличное от других (отдельный каталог для его хранения, явное указание ссылок и т. д.).
Выводы
Учитывая все вышеизложенное, хотелось бы сделать следующие дополнения к статье Евгения Царева:
1) При оценке трудоемкости создания программного продукта нужно отдельно и подробно рассматривать этап проектирования, его подэтапы и его результат — техническое задание.
2) При выборе стоимости часа работы специалиста необходимо учитывать его квалификацию, исходя из качества результатов его работы.
3) Оценивая фактические затраты времени на разработку, надо принимать во внимание применяемые технические средства разработки и объем использования готовых решений.
Автор: Федор Музалевский, эксперт ЭУ «Воронежский центр экспертизы», к. ф.-м. н., доцент кафедры информационных технологий, моделирования и управления Воронежского государственного университета инженерных технологий
Опубликовано 08.12.2017