УДК 331.103.3:004.413.5

Измерение трудозатрат на разработку информационной системы по методике COCOMO II и с помощью хронометража

The measurement of labor costs for the development of an information system by the method of COCOMO II and by timing

К. В. Рочев

K. V. Rochev

Ухтинский государственный технический университет, г. Ухта

Ukhta State Technical University, Ukhta

В данной статье рассматривается оценка трудозатрат на разработку программного Silverlight проекта с помощью методики Constructive Cost Model и данные хронометража трудозатрат по стадиям жизненного цикла на примере информационной системы «Мобильный хронометр».

This article discusses the evaluation of labor for software development  on Silverlight using the techniques Constructive Cost Model and timing on a life-cycle stages on the example of an information system «Mobile chronometer».

Ключевые слова: трудозатраты, хронометраж, Constructive Cost Model, COCOMO II, Мобильный хронометр, жизненный цикл, Silverlight .

Keywords: labor cost, timing, Constructive Cost Model, COCOMO II, Mobile chronometer, life cycle, Silverlight .

Оценка трудозатрат на разработку программного продукта является весьма важным этапом, поскольку позволяет определить как стоимость будущей программной системы, так и целесообразность её разработки. Одной из наиболее популярных методик оценки трудозатрат является модель COnstructive COst MOdel – модель издержек разработки (COCOMO II) [1]. Именно сопоставление результатов расчёта трудозатрат с помощью различных вариаций этой модели с данными полученными путём хронометража (учёта затрат времени на все действия по разработке ИС «Мобильный хронометр» [2], см. Рисунок 1) представлено в данной статье.


Рисунок 1. Интерфейс информационной системы «Мобильный хронометр».

Оценка стоимости и трудозатрат с помощью COCOMO II – уровень предварительного прототипирования

В соответствии с моделью COCOMO 2 (Constructive Cost Model) в качестве базового соотношения для расчета затрат используется следующее:

PM = (NOP * (1 — %многократного использования)) / PROD

(1)

где    PM – затраты, выраженные в человеко-месяцах;

NOP – количество объектных точек;

PROD – табличное значение производительности команды разработчиков (объектных точек в месяц);

%многократного использования – доля повторного использования компонентов.

Таблица 1. Табличное значение производительности команды разработчиков

Опыт и возможности
программиста

Очень низкие

Низкие

Средние

Высокие

Очень высокие

Уровень и возможности
CASE-средств

Очень низкие

Низкие

Средние

Высокие

Очень высокие

Производительность

(объектных точек в месяц)

4

7

13

25

50

Уровень и возможности используемых Case-средств (от компании Microsoft) очень высокие, однако реально они использовались относительно слабо, поэтому используемая часть их возможностей оценивается как средние. Производительность разработчика выбрана как средняя.

Таким образом, средняя производительность (количество объектных точек в месяц) будет равна (13 + 13) / 2 = 13.

Доля повторного использования компонентов

Процент многократного использования рассчитывается следующим образом: считается количество компонентов, написанных для проекта лично Kл (каждый объект, каждая коллекция, каждый постер, каждая команда, манипуляторы и контроллеры – не считаются) и количество компонентов заимствованных из среды разработки Kз (каждый уникальный класс интерфейсного элемента, TForm, TFrame).

%многократного использования = Кз/(Kл + Кз).

(2)

Таблица 2 – Количество компонентов, написанных для проекта лично
и заимствованных из среды разработки

Тип компонента

Написанные лично

Заимствованные

Объекты

155

35

Коллекции

8

9

Постеры

6

12

Интерфейсные элементы

12

35

Итого

181

91

Таким образом, %многократного использования = 91 / (181 + 91) * 100% = 33,46 %.

Расчёт количества объектных точек

Обращение к таблице или объекту (представлению, хранимой процедуре, LINQ-запрос), использующему 1 – 2 таблицы – 2 объектных точки; обращение к объекту, использующему 3 – 8 таблиц – 5 объектных точек; обращение к объекту, использующему более 9 таблиц – 8 объектных точек.

Таблица 3 – Сложность отчетов в объектных точках

Отчет

Используемые таблицы

Объектные точки

Отображение действий: за период

TAction, Tcategory

2

Отображение действий: по категории

Taction, Tcategory, TcategoryTree

5

Отображение действий: весь фильтр

Taction, Tcategory, TcategoryTree, TactionProperty, Tproperty

5

Диаграмма соотношения действий

TAction, TCategory, TCategoryTree

5

Итого объектных точек

97

Количество изображений на дисплее

Простые изображения принимаются за 1 точку, изображения умеренной сложности – за 2, сложные за 3. Новое изображение – это каждая уникальная форма проекта (модальные диалоги «Вы действительно хотите удалить что-нибудь там» – считаются). Если на форме до 4х (включительно) активных интерфейсных элементов – считаем её простой, если от 5-и до 8-и – считаем, что она средней сложности, если 9 и больше – квалифицируем как сложную.

Таблица 4 – Сложность форм приложения в объектных точках

Форма

Интерфейсные элементы

Объектные точки

Главная форма


3*2

Просмотр статистики


7*3

Редактор категорий


3*2

Списки свойств, действий, категорий


2*3

Мастер сохранения и экспорта


3

Лента

12

Подсказки и диалоговые окна


1*3

Окно о программе

2

Итого объектных точек

59

Количество объектных точек NOP

Итого получаем 97 объектных точек на отчеты и 59 на оконные формы.

Однако в главное значение в данном проекте имеет удобство, скорость использования программы и ее внешний вид. Учитывая эти факторы необходимо скорректировать полученное значение сложности создания интерфейса.

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

В результате получим сложность разработки интерфейса равную 142 объектных точек.

Суммарная сложность составит 97 + 142 = 239 объектных точек.

Таким образом, оценка трудозатрат на разработку ИС «Мобильный хронометр» составляет:

PM = (239 * (1 – 0,33)) / 13 = 12,3 человеко-месяца.

Оценка стоимости и трудозатрат с помощью COCOMO II – уровень предварительного проектирования

На этом уровне оценка затрат вычисляется по следующей формуле:

PM = A * размерB * M + PMm

(3)

где:    A – константа, характеризующая уровень, на котором выполняется оценка, для уровня предварительного проектирования. А = 2,5;

Размер – размер системы, выраженный в количестве программного кода, тыс. строк;

B – показатель степени, отражающий рост затрат по мере увеличения проекта.

При расчёте B учитывается комплекс показателей характеризующих новизну проекта, гибкость процесса разработки, применяемые процессы управления рисками, сплоченность команды-разработки, уровень управления проектом. В итоге B рассчитывается по следующей схеме. Выполняется бальная оценка пяти показателей, представленных в таблице (таблица 5).

Низшее значение показателя соответствует 5 баллам, высшее 0. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени.

Получаем значение В = (15 / 100) + 1,01 = 1,16.

Размер системы в строках по меркам Visual Studio 2010 равен 8 тыс. строк, что является достаточно большим показателем, поскольку в этом значении не учитываются комментарии, переносы длинных строк, заголовки методов пустые скобки и некоторые другие элементы кода. Полное измерение количества строк показывает большее значение: для ИС «Мобильный хронометр» оно составляет 24 тысячи – в .cs файлах, 2 тысячи – в .xaml файлах и ещё 12 тысяч занимает авто сгенерированный код. Для расчётов возьмём данные, предоставляемые средой Visual Studio, поскольку вычисления трудозатрат для 26-ти тысяч строк дают результат 144 человеко-месяца.

 

Таблица 5 – Показатели роста затрат по мере увеличения проекта

Показатель

Пояснение

Предлагаемое значение

Новизна проекта Есть ли у нас опыт работы в подобных проектах? Предварительно специально создана небольшая система на Silverlight
Гибкость процесса разработки.  Определен ли процесс разработки жестко или может быть изменен в ходе разработки?
Может быть изменен в любое время.
Анализ архитектуры системы и рисков.  Проводился ли тщательный анализ архитектуры системы и рисков?
Проводился незначительный анализ архитектуры.
Сплочённость команды.  Оценка уровня взаимоотношений в команде.
Самого с собой – нормальная, с остальными — низкая.
Уровень развития процесса разработки.  Уровень развития процесса разработки в организации-разработчике.
Определяется по опроснику CMM.

M – показатель, характеризующий проект и процесс разработки и рассчитываемый по формуле:

M = PERS*RPCX*RUSE*PDIF*PREX*FCIL*SCED

(4)

где:    PERS – возможности персонала;

RPCX – надёжность и уровень сложности разрабатываемой системы;

RUSE – повторное использование компонентов;

PDIF – сложность платформы разработки;

PREX – опыт персонала;

FCIL – средства поддержки;

SCED – график работ.

Для ИС «Мобильный хронометр» значение М составляет:

M = 1*1*1*1*1,2*1*1,1 = 1,32

Для клиентского модуля на ПК трудозатраты составляют:

PM = 2,5 * 51,16 * 1,32 = 21,3 человеко-месяца.

А для всего проекта и того больше:

PM = 2,5 * 7,61,16 * 1,32 = 34,7 человеко-месяца.

Оценка стоимости и трудозатрат с помощью COCOMO II – постархитектурный уровень

На этом уровне оценка затрат вычисляется аналогично расчету для уровня предварительного проектирования, только учитывается количество кода, выброшенного из-за изменений требований:

PM = 2,5 * ((1+0,70) * 7,6)1,16 * 1,32 = 64,2 человеко-месяца.

Оценка трудозатрат с помощью хронометража

Разработка проекта «Мобильный хронометр» началась в ноябре 2009 года [1, 3, 4]. Всего процесс разработки продолжался в течение 20 месяцев, и проходил в свободное время, поэтому был достаточно неравномерен (см. Рисунок 2).


Рисунок 2. Среднедневные затраты времени на разработку
системы «Мобильный хронометр» по месяцам

По данным хронометража с 11.05.2010 по 15.07.2011 на создание системы было затрачено 490 часов. Ранее хронометраж автора не был попроектным, однако, если предположить, что разработка велась с той же интенсивностью, то суммарные трудозатраты составят 710 часов, или 30 суток, что соответствует 88-и полным рабочим дням или 4,2 месяцам (при режиме работ 8/21). Если из этого времени выделить трудозатраты именно на разработку системы, то получится ещё меньше: 3,3 месяца. А без документирования системы – 2,4 месяца.

Распределение трудозатрат по стадиям жизненного цикла

По собранным данным было получено соотношение трудозатрат по стадиям жизненного цикла системы показывающее преобладание стадии конструирования и документирования над остальными стадиями (рисунок 4).


Рисунок 3. Затраты времени на разработку системы
«Мобильный хронометр» по стадиям жизненного цикла


Рисунок 4. Диаграмма соотношения трудозатрат на разработку
системы «Мобильный хронометр» по стадиям жизненного цикла

Выводы

Результаты оценки трудозатрат на разработку системы «Мобильный хронометр» различными методами представлены на рисунке 5.


Рисунок 5. Оценка трудозатрат на разработку ИС «Мобильный хронометр» различными методами

Как видно, оценка сложности проекта по методике COCOMO увеличивается с каждым этапом, ввиду достаточно большого объёма программного кода и его многократного рефакторинга. Тем не менее, полученные в результате замеров времени данные значительно меньше расчётных трудозатрат. Единственное сопоставимое значение – это срок всей разработки, однако параллельно с ИС «Мобильный хронометр» автором выполнялся ряд других проектов, поэтому данное значение имеет смысл уменьшить, как минимум, в 2 раза, что будет соответствовать оценке сложности системы на уровне прототипирования (то есть по её интерфейсу). А если учесть тот факт, что хронометраж отсекает все отвлечения, которые составляют значительную часть рабочего времени, полученные данные подтверждают относительную точность оценки сложности проекта.

Трудозатраты в 2 – 6 (и более 12, при не минимальных адекватных параметрах) человеко-лет, полученные при оценке трудности проекта по размерам кода вполне могут быть объяснены целым рядом факторов.

Таким образом видно, что отклонение оценки сложности проекта по методике COCOMO при некоторых условиях может быть весьма велико – в рассмотренном случае в 2 – 16 раз. Это говорит о том, что выйти на высокую точность предварительной оценки трудозатрат можно только в случае поочерёдной разработки нескольких программных систем одним коллективом.

Библиографический список

  1. Кулямин В. В. Технологии программирования. Компонентный подход [Электронный ресурс] // Institute for System Programming of the Russian Academy of Sciences [сайт]. Url: http://panda.ispras.ru/~kuliamin/lectures-sdt/Lecture16.pdf. Систем, требования: Adobe Reader. (дата обращения 01.05.2012).
  2. Рочев К.В. Автоматизированная информационная система «Мобильный Хронометр» / XI межрегиональная молодежная научная конференция «Севергеоэкотех – 2010»: материалы конференции (17-19 марта 2010 г., Ухта): в 5 ч.; ч. 1. – Ухта: УГТУ, 2010. – С. 240–243.
  3. Рочев К.В. Оценка экономической эффективности информационной системы «Мобильный хронометр» / XII Международная молодежная научная конференция «Севергеоэкотех – 2011»: материалы конференции (16–18 марта 2011 г., Ухта): в 5 Ч.; Ч. 3 – Ухта: УГТУ, 2011. – С. 360–363.
  4. Сайт проекта «Мобильный хронометр» [Электронный ресурс]. Url: http://chronom.ru/ (дата обращения 01.05.2012).
  5. COCOMO II – Constructive Cost Model [Электронный ресурс] // Naval Postgraduate School [сайт]. Url: http://diana.nps.edu/~madachy/tools/COCO-MOII.php (дата обращения 02.05.2012).
  6. COCOMO™ II with Heuristic Risk Assessment [Электронный ресурс] // Center for Systems and Software Engineering [сайт]. Url: http://sunset.usc.edu/ research/COCOMOII/expert_cocomo/expert_cocomo2000.html (дата обращения 02.05.2012).

 

Статья поступила в редакцию: 02.05.2012

VN:F [1.9.17_1161]
Rating: 6.6/10 (9 votes cast)
VN:F [1.9.17_1161]
Rating: +2 (from 4 votes)
VN:F [1.9.17_1161]
Стиль изложения
Информативность
Сложность вопроса
Научная новизна
Коммерциализуемость
Rating: 3.5/5 (4 votes cast)
Измерение трудозатрат на разработку информационной системы по методике COCOMO II и с помощью хронометража, 6.6 out of 10 based on 9 ratings