Ковалев Д.В.
преподаватель.
Южный Федеральный Университет
Российская Федерация. Ростов на Дону
ОЦЕНКА ВРЕМЕННЫХ ЗАТРАТ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В статье обосновывается роль процедуры оценки временных затрат разработки программного обеспечения в системе управления реализацией ИТ-проектов. Рассматриваются и анализируются методики проведения такой оценки. Делается вывод о возможности их применения в российской практике.
Ключевые слова: ИТ-проекты, информационная система, временные затраты.
В числе главных факторов условий реализации модернизационного развития экономики России, обеспечивающих прогнозируемые темпы государственной политики, является информация, как ключевой ориентир экономических трансформаций на макро-, мезо- и микроуровнях и необходимая среда осуществления инноваций [1]. В современном бизнесе существует четкое понимание того, что информационные технологии являются важным инструментом повышения конкурентоспособности и эффективности деятельности.
Проведенный анализ показал, что сегодня средняя российская компания тратит около 6% до 7% доходов на информационные технологии, а если включить в выборку те организации, которые высоко зависят от ИТ – такие, как финансовые и телекоммуникационные компании – траты составляют больше 15%16. Причем расходы на программное обеспечение продолжают расти. Так, по данным Forbes ежегодный прирост затрат на развитие систем аналитики и обработки данных составляет 20% — 30%17. Прогнозируемый суммарный объем затрат на системы обработки данных и аналитические сервисы в 2015 году составит приблизительно 3 млрд. $. Одновременно ряд аналитиков отмечают, что значительная часть ИТ-проектов не приносит ожидаемый экономический эффект. По данным StandishGroup за период 2003-2012 гг. только 6% из отслеженных крупных проектов разработки программного обеспечения были успешно внедрены. Еще 52% были завершены со срывом сроков и превышением бюджета проекта, что повлекло снижение экономического эффекта, и 42% были завершены неудачно или вовсе не завершены18.
Рисунок Статистика разработки ПО.
По мнению ИТ-экспертов, основные проблемы, приводящие к данной ситуации, заключается в нереальных или невнятно сформулированных целях проекта; неточном определение необходимых ресурсов; плохо определенных системных требований; недостаточной и редкой отчетности о статусе проекта; наличии неуправляемых рисков; плохой связи между клиентами, разработчиками и пользователями; использовании незрелых технологий; неспособности проследить за всеми сторонами сложного проекта; небрежности разработки. По нашему мнению, к этому стоит добавить также изначальное некорректное определение сроков и бюджета проекта. По статистике менеджеры изначально озвучивают цифры, составляющие 25% реальной стоимости проекта и 75% реальных временных затрат19.
Это обусловливает актуальности исследования проблематики оценки временных затрат разработки программного обеспечения.
К наиболее известным и получившим в настоящее время широкое распространение методам оценки проектов относятся метод функциональных точек и метод COCOMO.
Метод функциональных точек предназначен для оценки на основе логической модели объема программного продукта количеством функционала, востребованного заказчиком и поставляемого разработчиком. Достоинством метода является то, что измерения не зависят от технологической платформы, на которой будет разрабатываться продукт, и он обеспечивает единообразный подход к оценке всех проектов в компании. Кроме того, оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом, так как применение функциональных точек основано на изучении требований.
При анализе методом функциональных точек надо выполнить следующую последовательность шагов: 1) определение типа оценки, 2) определение области оценки и границ продукта, 3) подсчет функциональных точек, связанных с данными, 4) подсчет функциональных точек, связанных с транзакциями, 5) определение суммарного количества не выровненных функциональных точек (UFP), 6) определение значения фактора выравнивания (FAV),7) расчет количества выровненных функциональных точек (AFP).
Определение суммарного количества UFP выполняется по формуле:
 [1]
А значение фактора выравнивания (VAF) определяется по формуле:
 [2]
Итоговый результат, то есть количество выровненных функциональных точек, рассчитывается в зависимости от типа оценки, каждый из которых был перечислен выше. Формула для программного приложения:
 [3]
Проект доработки и совершенствования продукта оценивается в EFP:
EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB) [4]
где
ADD — функциональные точки для добавленной функциональности;
CHGA — функциональные точки для измененных функций, рассчитанные после модификации;
VAFA — величина фактора выравнивания рассчитанного после завершения проекта;
DEL — объем удаленной функциональности;
VAFB — величина фактора выравнивания рассчитанного до начала проекта.
В конечном итоге, зная трудоемкость проекта, выраженного в AFP (DFP, EFP) и производительность команды, выраженной в AFP/час, можно оценить необходимые временные и денежные ресурсы. Кроме того, данный анализ хорошо показывает сложность и трудоемкость проекта, позволяя оценить общую степень риска и рентабельность разработки программного обеспечения.
Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке. Суммарный размер продукта рассчитывается, как сумма размеров его компонентов:
 [5]
Базовая трудоемкость проекта рассчитывается по формуле:
 [6]
где SCED — сжатие расписания (очень низкое — 75% от номинальной длительности; очень высокое — 160% от номинальной длительности).
Далее рассчитывается базовая трудоемкость каждого компонента в отдельности:
 [7]
На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED:
 [8]
Итоговая трудоемкость проекта определяется по формуле:
 [9]
Длительность проекта в методике COCOMO II рассчитывается следующим образом:
 [10]
где С = 3,67; D = 0,28; PMNS — трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.
Главной особенностью методики является то, что для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода. Размер программного продукта может быть оценен экспертами с применением метода PERT20 или метода функциональных точек, который описан в пункте выше.
Общепризнанной методики оценки временных затрат на разработку программного обеспечения предприятий малого бизнеса на данный момент нет, что приводит к определенного рода проблемам. Нереалистично короткие плановые сроки наряду с небольшой, а часто и неполной командой разработчиков провоцируют отказ от дополнительного тестирования программного продукта, составления документации, внешних и внутренних совещаний. По данным калифорнийской аудиторской компании Netwrix за 2014 год, 65% ИТ-специалистов небольших компаний вносят не задокументированные изменения в информационную систему предприятия, которые приводят к остановке работы системы; 52% вносят в информационную структуру изменения, которые сопровождаются простоями от раза в неделю до ежедневных, а 39% вносят изменения, которые приводят к появлению брешей в системе безопасности компаний. Более того, 57% разработчиков никогда не документировали какие-либо изменения системы, хотя более 80% малых ИТ-компаний имеют автоматизированные средства для контроля таких изменений21.
Таким образом, построение информационной системы предприятия предполагает проведение предварительной оценки временных затрат разработки программного обеспечения и требует использование адекватных методов. В сложившихся условиях российской экономики на фоне нестабильного курса неадекватная оценка может обернуться для небольших компаний серьезными убытками вплоть до банкротства.
Использованные источники:
Современные тенденции инновационного развития региональных экономических систем. Коллективная монография / под ред. Черновой О.А., Матвеевой Л.Г. – Таганрог: Изд-во ЮФУ. 2010.
Прикладная информатика в экономике: теория и практика / под общ. ред. Проф. Л.Г. Матвеевой, проф. О.А. Черновой – Ростов н/Д: «Содействие ХХI век», 2013.
|
