Development of a DSS module when preparing assessments for IT company clients

Full Text

Введение

Процесс разработки программного обеспечения (ПО) имеет собственную специфику, которая плохо укладывается в теорию классического управления проектами. Задача проекта заключается в достижении конкретной бизнес-цели, при соблюдении ограничений «железного треугольника»: содержание – стоимость – время [1]. На практике данный принцип означает, что ни одна из трех составляющих не может быть изменена без оказания влияния на две другие. Если же говорить о проекте по созданию ПО, то отдельно следует упомянуть как нематериальный характер создаваемого продукта, так и тот факт, что существенную долю затрат составляет труд ИТ-специалистов.

Начиная с 60-х гг. ХХ века (практически с момента появления рынка программного обеспечения), проблема оценки трудозатрат для ИТ-проектов остается одним из самых сложных вопросов в программной инженерии. К настоящему моменту не существует точных и одновременно простых в использовании моделей оценки трудоемкости разработки ПП, которые позволяли бы точно оценивать размер ПП на этапах планирования разработки [2].

Надежные оценки на ранних сроках реалиизации ИТ-проекта сложно получить из-за отсутствия детальной информации о будущем программном продукте (ПП). Тем не менее, на начальных стадиях реализации ИТ-проекта предварительные оценки условий и сроков выполнения заказа весьма важны.

С одной стороны, компании-разработчики заинтересованы в завышении стоимости (тем самым, увеличивая величину дохода), с другой стороны, заказчик заинтересован в снижении стоимости при сохранении полного набора функциональных возможностей будущей информационной системы. Поэтому процесс формирования сметы, от которого напрямую зависит окончательная стоимость ПП, всегда опирается на поиск компромисса между заказчиком и ИТ-исполнителями.

Недооценка стоимости, времени и ресурсов, требуемых для разработки ПП, повлечет за собой недостаточную численность участников ИТ-проекта, излишне сжатые сроки разработки и, как следствие, потерю доверия к разработчикам в случае нарушения календарного графика [3]. Если рассматривать ситуацию переоценки в сторону повышения стоимости проекта, то данная ситуация также имеет свои недостатки. Неоправданно дорогостоящий проект приведет к формированию натянутых отношений с заказчиком, и дальнейшие контакты могут быть осложнены. При задействовании излишнего числа трудовых ресурсов происходит недозагрузка и «расхолаживание» сотрудников, что негативно влияет на психологическую атмосферу в ИТ-компании в целом (сотрудники, задействованные в других проектах, будут считать, что их чрезмерно эксплуатируют). Таким образом, компании, занимающиеся промышленной разработкой ПО, должны владеть методикой и иметь инструментальные средства объективной оценки трудоемкости программных проектов.

Подобный инструментарий должен позволять компании-разработчику выполнить реальную оценку всех своих затрат на основе трудоемкости работ по созданию ПО, обладать прозрачностью для заказчика, который без использования специфических знаний и конфиденциальной информации, сможет обосновать приемлемую цену сделки.

В статье представлены результаты исследований по проектированию модуля системы поддержки принятия решений (СППР) для получения взвешенной оценки трудоемкости разработки ПП и расчета сметы на базе технического задания, учитывающего различные факторы, которые влияют на процесс разработки ПП, и применяемые нормы труда.

Особенности процесса формирования сметы на разработку программного продукта

С точки зрения управления, ИТ-проекты, наряду с традиционными трудностями, свойственными обычным проектам (дедлайны, ограниченность бюджета и нехватка разработчиков, которые могут быть задействованы в проекте, и/или недостаточно высокий уровень профессионализма участников проекта), сталкиваются со специфическими сложностями (технологические аспекты аппаратной и программной платформ, особенности операционной системы, сложность интеграции с уже существующими программными продуктами и пр.). Объяснение этих фактов заключается в природе самого понятия ИТ-проекта: во-первых, постоянно изменяются и адаптируются сами информационные технологии; во-вторых, в отличие от «стандартных» проектов, программный продукт, который должен получиться в результате окончания ИТ-проекта, неосязаем; в-третьих, успешность ИТ-проекта и качество создаваемого ПП напрямую зависит от профессионализма разработчиков. Также управление проектами по созданию ИТ-решений усложняется постоянно изменяющимися требованиями заказчика и условиями бизнеса.

Как следствие, существенную трудность представляет задача выработки четких метрик и инструментов, напрямую связанных с оценками трудоемкости, сроков и затрат ИТ-проекта.

В работе [4] выделены следующие важные характеристики ИТ-проекта, которые необходимо учитывать при составлении сметы:

1. Объем работ по организации проекта. Данный показатель требуется для определения количества организационных единиц, в которых будет осуществляться внедрение / тиражирование ПП. Этот показатель прямо пропорционально влияет на стоимость работ.
2. Объем разрабатываемых функциональных возможностей ПП. От точной оценки этого показателя напрямую зависят все остальные показатели проекта (сроки, цена проекта, количество требуемых человеко-часов, методология разработки ПП и пр.).
3. Методологический объем проекта, описывающий набор нормативно-регламентирующей документации, которую требуется разработать или доработать в ходе реализации проекта.
4. Требуемые интеграционные работы: в этом случае смета ПП может значительно увеличиться.
5. Обеспечение информационной безопасности в случае, если ПП обрабатывает данные, к которым предъявляются повышенные требования по их защите. Работы по обеспечению информационной безопасности увеличивают стоимость и сложность проекта.

На рисунке 1 представлен обобщенный процесс разработки ПП. Вопрос формирования сметы находится в зоне влияния аналитика, который в одинаковой мере должен хорошо понимать требования технического задания (ТЗ) по конкретному проекту и оценивать возможности продаваемого ПП.

 

Рисунок 1. Обобщенный процесс создания программного продукта

 

Аналитик при формировании сметы на создание ПП должен учитывать значительное число взаимосвязанных факторов, что делает актуальной задачу поиска инструментария для объективной оценки трудоемкости и сроков разработки ПП. Основной целью данного инструментария является, с одной стороны, предоставление ИТ-компании возможности объективно оценивать трудоемкость и, следовательно, стоимость будущего ПП на ранних стадиях, а, с другой стороны, обеспечение прозрачности обоснования приемлемой цены сделки для клиента.

Задача выбора методов (метрик) оценки трудоемкости и прогнозирования сроков реализации ПП, позволяющих без особых временных и финансовых затрат получить реалистичные данные, представляет определенную сложность. Были выделены следующие «болевые» точки процесса составления сметы на разработку ПП [5].

1) Неточная и изменяющаяся формулировка функциональных требований ТЗ. Как показывает практика, стоимость ПП находится в прямой зависимости от функциональных требований ТЗ, на основании которых можно переходить к формированию проектных решений и рассматривать варианты концепций ПП. Неграмотно проработанные требования и частота изменений требований со стороны заказчика непропорционально увеличивают конечную сумму.

2) Недостаточный учет (а зачастую и просто игнорирование) «второстепенных» факторов: сложность, новизна и критичность задачи; профессионализм и компетенция разработчиков, а также их занятость на других проектах; наличие технологических рисков и прочее.

3) Отсутствие прозрачности взаимосвязи между трудоемкостью и полученной себестоимостью ПП. Для подсчета трудоемкости применяют одну из метрик (COCOMO II, метод функциональных точек и пр.), а себестоимость продукта рассчитывается либо методом группировки по калькуляционным статьям, либо методом группировки по экономическим элементам.

В помощь аналитику предлагается разработка и внедрение модуля СППР формирования сметы ПП на основании требований ТЗ.

Методы расчета трудоемкости создания программного продукта

В настоящий момент рыночная стоимость ПП в большей степени представляет собой оценку спообности заказчика оплатить расходы на реализацию ИТ-проекта [6]. Характерной особенностью процесса создания ПП является существенная удельная доля трудовых затрат в общих производственных затратах, поэтому основное внимание в публикациях и исследованиях уделено вопросу оценки трудоемкости, от которого напрямую зависит конечная стоимость создаваемого продукта [3; 7; 8]. При расчете стоимости разработки ПП необходимо учитывать следующие факторы:

• размер конечного программного продукта (обычно измеряется числом строк исходного кода (SLOC));
• особенности применяемой методологии разработки ПП;
• возможности и квалификация участников ИТ-команды (personal capability);
• среда разработки ПП;
• требуемое качество продукта (quality assurance), включающее в себя функциональные возможности и нефункциональные требования (к масштабируемости, надежности, адаптируемости и пр.).

Ввиду того, что предварительная оценка стоимости разработки включает в себя множество элементов неопределенности, предприятия используют на практике широкий круг методов – от самых элементарных до весьма изощренных [1].

Анализ многообразных исследований и публикаций показал отсутствие единой общепризнанной классификации методов подсчета трудоемкости. Согласно одной из таких классификаций, многообразие методов и моделей ПП можно разделить на две группы: микрооценки и макрооценки. Методики микрооценок носят субъективно-оценочный характер, так как оценка зависит от руководителя проекта или техлида. Таким образом, если у разработчика нет опыта разработки схожего ПО, то и оценки будут неверными. Методики макрооценки основаны на использовании определенных схем и принципов (а не на применении точных формул), что значительно снижает их объективность. Однако, с учетом большего количества проектов, в которых были проведены макрооценки, они выглядят более надежными.

Другой общепризнанной классификацией является деление на две другие группы: неалгоритмические и алгоритмические. Первая группа подходов основана на интуитивно-логическом анализе проблемы, вторая – на применении определенных математических алгоритмов, использование которых дает возможность достаточно точно рассчитать размер ПП и трудозатраты на его разработку.

К неалгоритмическим относят метод экспертных оценок, метод аналогий, принцип Паркинсона, метод, ориентированный на возможностях бюджета заказчика. В соответствии с алгоритмическими методами, расчет трудоемкости разработки ПП основан на измерении количественных показателей ПП (например, количестве FP) и последующем их делении на количество усилий, затраченных на разработку этих продуктов. К этой группе методов относят, прежде всего, метод функциональных точек (FPA, Function Points Analysis), модель SLIM (Software Life-cycle Model) Л. Патнема, COCOMOII.

К современным методам отдельные авторы относят генетический метод и метод нейросетевой аппроксимации, байесовские сети, метод имитационного моделирования [3; 9].

В рамках исследования был проведен анализ популярных методов расчета трудоемкости разработки ПП (таблица 1), что облегчает выбор в пользу того или иного способа расчета трудоемкости [6; 9 – 11].

 

Таблица 1. Сравнение методов расчета трудоемкости

Критерии               Методики	Тип модели	Доступность репозитория	Время применения	Учет размера системы	Учет функциональных требований	Учет фактора персонала	Метрика
Методика Госкомтруда	закрытая	–	весь ЖЦ	+	–	–	–
COCOMO II	закрытая	–	после определения требований	+	+	–	DSI
FPA IFPUG 4.1	открытая	+	весь ЖЦ	+	+	–	FP
Puthnam (SLIM)	открытая	–	после определения требований	+	–	–	SLOC
UCM	закрытая	–	после определения требований	+	+	–	UC

 

В результате сопоставления пяти распространенных методик были выделены следующие значимые параметры, которые необходимо учитывать при выборе методики расчета трудоемкости:

• легкость осуществления оценки трудоемкости разработки ПП;
• возможность использования статистики предыдущих проектов, которая не велась в соответствии со специальными требованиями для оценки;
• возможность учета нефункциональных требований;
• гибкость методики, т.е. она не должна быть привязана к каким-то определенным единицам (функциональным блокам) и др.
• учет фактора персонала (его доступности, квалификации и компетенции).

«Наилучшего» подхода в оценке трудоемкости выделить нельзя, что на практике приводит к тому, что разные компании извлекают выгоду из разных подходов в зависимости от контекста. Вероятнее всего, универсальной методики оценки трудоемкости найдено не будет, поэтому в каждом конкретном проекте корректно говорить о применении разнообразных эмпирических подходов, комбинирующих простые в использовании метрики и сложные, но более точные модели.

Модуль системы поддержки принятия решений для расчета сметы на основании требований технического задания

В связи с существующей актуальностью вопроса оценки стоимости ПП в разделе предлагается упрощенный алгоритм разработки модуля СППР для расчета сметы на разработку ПП.

Разработка прототипа СППР для расчета сметы осуществлялась в среде разработки 1С: Предприятие 8. Выбор данного средства разработки обусловлен, прежде всего, тем, что он распространен и относительно прост в освоении. Алгоритм разработки проектируемого модуля СППР упрощенно выглядит следующим образом:

1)  Если в проекте участвуют субподрядчики, то необходимо сначала заполнить справочник о партнерах. Данный шаг является специфичным для ИТ-компаний-интеграторов, занимающихся доработкой пакетных продуктов под деятельность заказчика.

2)  Ввод справочников: данный шаг является подготовительным, при дальнейших расчетах конкретные значения берутся из справочников. К таким справочникам относят: данные договоров с субподрядчиками; сложность задачи (требования ТЗ); новизна и важность задачи (значения шкал); должности, компетенции и часовые ставки сотрудников, которые могут быть задействованы в разработке ПП.

3)  Построение структуры проекта, оценку трудоемкости которого необходимо провести. Фактически на данном шаге заполняются требования ТЗ на разрабатываемый ПП.

4)  Распределение исполнителей по задачам (требованиям ТЗ).

5)  Анализ статистических данных по выполненным ранее проектам и по исполнителям и предварительный расчет оценки трудоемкости на каждый тип элемента разрабатываемого ПП. За основу расчета взят метод функциональных точек.

6)  Автоматический перерасчет оценок элементов, в зависимости от компетенции исполнителя и важности/новизны задачи.

7)  Получение конечной оценки стоимости проекта.

На рисунке 2 представлены некоторые разработанные экранные формы.

 

Рисунок 2. Screen flow модуля СППР

 

На форме «Расчет сметы» необходимо заполнить поля:

• Партнер.
• Договор (при выборе клиента, в списке выбора договоров будут доступны для выбора только договора, заключенные с этим партнером).
• Сложность задачи (выбор из списка «Низкая», «Средняя», «Высокая»).
• Трудоемкость задачи (выбор из списка «Низкая», «Средняя», «Высокая»).
• Новизна задачи (выбор из списка «Новая», «Редко встречающаяся», «Типовая»).
• Важность задачи (выбор из списка «Некритичная», «Средняя», «Критичная»).
• Количество сотрудников (после того как вводится количество, автоматически появляются поля для ввода квалификаций и занятости сотрудников на проекте, изначально эти поля скрыты).

В реквизите «Квалификация сотрудников» необходимо будет указать должность сотрудника (для выбора будут доступны только те должности, по которым внесены цены по договору в регистре «Цены»).

В реквизите «Занятость на проекте» необходимо указать степень занятости сотрудника на проекте, по которому рассчитывается стоимость задачи (выбор из списка «Низкая», «Средняя», «Высокая», «Очень высокая»).

По кнопке «Рассчитать» рассчитывается примерная стоимость задачи, на основании данных, введенных на форме и правилам, внесенным в базу.

Применение предлагаемого инструментария должно способствовать повышению объективности при формировании сметы на создание ПП.

Заключение

Актуальность исследования обусловлена необходимостью получения корректной оценки сложности и, следовательно, трудоемкости и стоимости разрабатываемого ПП на ранних этапах работы над проектом.

При разработке ИТ-проектов основными ресурсами выступают: бюджет проекта, время на создание ПП, необходимое и доступное количество специалистов с соответствующей компетенцией и квалификацией.

Оценить объем необходимых трудозатрат на выполнение требований ТЗ без достоверной информации о его сложности достаточно тяжело. Но сделать это на начальном этапе проектирования ПП руководителю проекта необходимо. Неверная или неточная оценка трудоемкости ИТ-проекта приведет к снижению эффективности реализации ПП, поэтому разработаны различные методики и методы для прогнозирования затрат и оценки сложности ИТ-проектов. В работе проведен анализ наиболее распространенных методик расчета трудоемкости ПП. Все эти методики довольно трудоемкие, поэтому предлагается внедрить в деятельность аналитика модуль СППР для расчета сметы будущего ПП.

Внедрение модуля СППР должно позволять аналитику при анализе требований ТЗ проводить корректную оценку затрат на основе трудоемкости. Для заказчика должна быть предусмотрена возможность обосновать приемлемую цену сделки без использования специфических знаний и конфиденциальной информации.

About the authors

Alfiya R. Diyazitdinova

Povolzhskiy State University of Telecommunications and Informatics

Author for correspondence.
Email: dijazitdinova@mail.ru

Associated Professor of Applied Informatics Department, PhD in Technical Science, Associated Professor

Russian Federation, Samara

Valeria V. Zhengurova

Povolzhskiy State University of Telecommunications and Informatics; PromInfoConsalt

Email: lerazhengurova@yandex.ru

Leading Information Systems Consultant, Master’s Degree Student of Applied Informatics Department

Russian Federation, Samara; Samara

References

Supplementary files