Концепция процесса выполнения программных проектов

УДК 004.412.3
Ю.Ю. Якунин
Оценка трудоѐмкости разработки программной системы
Описывается методика и математическая модель оценки трудоѐмкости программного
проекта на базе метрик, основанных на функциональных точках
Введение
Организации, занимающиеся разработкой программных систем, особенно для
коммерческой реализации в том или ином виде используют методику оценки программного
проекта. Проблема состоит в том, что в России в настоящее время действует устаревшие
модели по оценке, утвержденные Госкомтруда в 1986 году. В этой ситуации фирмы
вынуждены использовать методики иностранного происхождения. Особенно остро стоит
вопрос в организациях, которые получили или собираются получить сертификат по
стандарту ГОСТ Р ИСО 9000-2001.
Использование иностранных методик сопровождается рядом проблем: 1) Методики и
модели созданы без учѐта специфики разработки программных систем в Росси; 2) Параметры
моделей оцениваются по статистическим данным о выполненных проектах в зарубежных
странах. Сами статистические данные как правило закрыты, а потому не вызывают доверия;
3) Математические модели не представлены в полном объѐме, что не позволяет оценить
достоверность этих моделей и самостоятельно выполнить оценку параметров моделей.
Все методики оценки делятся на две группы: микрооценка и макрооценка. Методы
микрооценки основаны на точном знании процесса. Такова, например, Oracle AIM и оценки
трудоемкости для него. Во всех случаях, когда для построения модели оценки необходимо
видение разбивки работ и оценка каждой индивидуальной работы, метод относится к группе
микрооценки. Методы макрооценки основаны на функциональных требованиях. Таковы
методы функциональных точек (FP) и методы типа СОСОМО.
В статье Н. Михайловского [1] проведѐн сравнительный анализ методик оценки
стоимости проектов по разработке программных систем. Из рассмотренных Михайловским
методик две имеют закрытые модели оценки, а из двух методик с открытыми моделями, у
одной не доступны статистические данные, на основе которых выполнялись расчѐты оценки
параметров модели. Последняя методика (IFPUG FPA) основана на статистических данных
зарубежных стран.
Поэтому возникает потребность в открытых российских разработках такого рода методик.
Открытые модели позволят: 1) Производить оценку и настраивать модели на основе
собственного опыта организаций; 2) Использовать свои обозначения и понятия
функциональных блоков, что наиболее актуально в постоянно меняющихся технологиях
разработки.
В данной статье описывается модель и метод оценки трудоѐмкости программной
разработки, в котором учтены наиболее существенные факторы. С развитием метода, в нѐм
будут учитываться и другие факторы, влияющие на стоимость программного проекта.
Концепция метода
Оценка программного проекта является исходными данными и отправной точкой для
планирования. Для составления плана проекта необходимо знать три основных показателя:
длительность (продолжительность) разработки, требуемые усилия (трудозатраты),
количество специалистов (штат разработчиков). Эти показатели позволяют определить
стоимость разработки проекта.
Основным показателем, который требуется оценить, является трудоѐмкость. Остальные
показателя можно считать в той или иной степени производными. Для того чтобы можно
было оценить трудоѐмкость, требуется набор статистических данных о предыдущих
проектах. Такими данными могут являться: трудоѐмкость функционального блока,
подсистемы и проекта в целом; длительность проекта и каждого этапа в отдельности;
количество ошибок на один функциональный блок или строку программного кода;
используемые технологии разработки и организации процесса разработки; размер команды
разработчиков и их квалификация.
Рассматриваемый в данной статье метод относится к группе макрооценок и основан на
использовании подхода функциональных точек. Данный метод предполагает выполнение
следующих шагов:
1) На основе предварительного анализа требований должны быть определены
основные функциональные подсистемы (блоки) будущего программного продукта;
2) Для каждого типа функционального блока определяется количество типов
элементов и производится оценка сложности каждого типа элемента относительно друг
друга (в том случае, если прежде такая оценка не производилась);
3) Для каждого функционального блока определяется количество элементов каждого
типа;
4) Выполняется вычисление оценки трудозатрат для каждого функционального блока,
разрабатываемой системы;
5) В результате суммирования данных по всем блокам получаем оценки трудозатрат и
стоимости разработки всей системы.
Исходные данные для оценки
В зависимости от подхода в организации к описанию и формализации требований к
программной системе можно выделять несколько типов элементов, из которых эти
требования состоят. В любом случае требования к системе делятся на функциональные и
нефункциональные. От функциональных требований трудоѐмкость разработки системы
зависит в большей степени, хотя некоторые нефункциональные требования могут очень
сильно влиять на стоимость разработки. В предлагаемом методе пока учитываются только
функциональные требования. В общем случае для любых подходов функциональные
требованиях к системе на самом высоком уровне могут быть описаны как требования к
подсистемам. Каждая подсистема может состоять из набора функций (по ГОСТ 34.602-89)
или набора вариантов использования (по IEEE 830). И те и другие имеют детальное описание
или спецификацию.
Для того чтобы отвязаться от разных стандартов и подходов к описанию требований
введѐм понятие «функциональный блок». Под функциональным блоком будем понимать
набор однотипных функций направленных на решение одной задачи. Задача может быть
нацелена как на результат пользователя, так и на программный результат. Объѐм
функционального блока может быть любым, но предпочтительно, чтобы все
функциональные блоки были одно уровня абстракции, хотя это не обязательно. Например,
для уровня подсистем можно считать следующие функциональные блоки: «подсистема
авторизации», «подсистема формирования отчѐтов», «подсистема ведения справочных
данных» и т.п. Это крупные функциональные блоки, для более точной оценки рекомендуется
использовать функциональные блоки, например, уровня вариантов использования.
Так как рассматриваемый метод основан на подходе макрооценки, то исходными данными
для него является статистика о предыдущих выполненных проектах. Статистические данные
по каждому выполненному проекту должны содержать информацию по всем
функциональным блокам следующего содержания:
Eik, j − количество элементов по типам сложности, где i - номер функционального блока, j номер типа сложности, k - номер выполненного проекта;
Ti k − трудозатраты, использованные на разработку i-го функционального блока в k-ом
проекте.
Очевидно, что от проекта к проекту объѐм (или содержание) однотипного
функционального блока может различаться. Обычно руководителю проекта известны
трудозатраты, использованные на разработку функционального блока в целом ( Ti k ), а не
отдельных его частей. Но для оценки трудоѐмкости такого же функционального блока в
новом (оцениваемом) проекте, нужно знать трудозатраты на каждый элемент этого
функционального блока в предыдущих проектах. Для решения этой проблемы вводится
понятие сложности элементов функциональных блоков и оценка сложности (  i, j ). В
качестве примера в таблице 1 приведены возможные типы элементов функционального
блока и оценки их сложности.
В приведѐнном примере (см. таблицу 1) оценка сложности выполнена в процентах, и
общая сумма всех оценок составляет 100%. Для использования оценки сложности в модели
удобно работать с приведѐнной оценкой. Тогда должно выполняться следующее условие:
 i, j  1, для i
(1)
j
Значения оценки сложности элементов функционального блока могут быть получены
двумя способами: 1) при наличии достаточного количества статистических данных о
выполненных проектах оценку сложности можно будет рассчитать, например, через оценку
матожидания; 2) при отсутствии достаточного количества статистических данных оценка
может задаваться экспертом, например, менеджером проекта.
Как было отмечено выше,  i, j нам необходима для получения трудозатрат в разрезе типов
элементов, так как обычно известна информация только о стоимости всего функционального
блока. Для каждого исходного проекта рассчитывается Ti ,kj − трудозатраты использованные
на разработку элементов j-го типа в k-ом проекте для i-го функционального блока.
Примечание: исходные проекты – это выполненные проекты, чьи статистические данные
будут использоваться для оценки стоимости нового проекта. Эти трудозатраты
рассчитываются путѐм весового распределения трудозатрат всего функционального блока по
типам его элементов:
k
i, j
T

 i , j  Eik, j
 i, j  Eik, j
j
 Ti k
(2)
Таблица 1
Типы элементов функционального блока
№
Тип элемента
1.
2.
Простой объект
Средний объект
3.
4.
Сложный объект
Простая
транзакция
Средняя
транзакция
Сложная
транзакция
Простая таблица
5.
6.
Оценка
Описание
сложности (%)
3,85
Количество простых и составных полей менее 15
7,69
Количество простых и составных полей более 15
но менее 50
11,54
Количество простых и составных полей более 50
3,85
Выборка данных посредствам SQL-запроса или
хранимой процедуры
7,69
Выполнение нескольких SQL-запросов и/или
хранимых процедур
19,23
Реализация математического алгоритма
Таблица, состоящая из простых полей, для
создания которой используется один несложный
SQL-запрос
8. Средняя таблица 15,38
Таблица, состоящая как из простых полей, так и
из опциональных и/или списочных. Для создания
таблицы используется один или несколько
простых SQL-запросов
9. Сложная таблица 23,08
Таблица, состоящая из простых полей и/или
опциональных и списочных полей. Для
фильтрации данных в таблицы используются
дополнительные поля на форме. Для загрузки
данных в таблицу используются один или
несколько сложных SQL-запросов (хранимые
процедуры)
Примечание. Под объектом здесь понимается совокупность простых и составных полей,
образующих некоторую сущность, которая представляется в системе как единое целое на
отдельной форме, закладке, в разделе и т.п. Над объектом могут совершаться
стандартные операции сохранения, изменения и удаления. Под транзакцией понимается
набор действий пользователя и/или системы, выполняющихся по событию на форме и
приводящих к определѐнному ощутимому результату. Например, транзакцией можно
назвать реализацию некоторого математического алгоритма или выборку данных для
отчѐта. Под таблицей понимается таблица с набором простых и составных полей,
позволяющая выполнять стандартные действия над записями (сортировка, фильтрация по
столбцам, настройка таблицы).
7.
7,69
Оценка функциональных блоков
Очевидно, что для оценки стоимости проекта нужно использовать статистические данные
из нескольких проектов. Тогда возникает вопрос насколько достоверны данные из того или
иного проекта и на сколько корректно использовать эти данные с равной степенью доверия.
Конечно, можно было исключить проекты с меньшей степенью достоверности. Но тогда как
оценить эту степень достоверности? Кроме того, любые статистические данные, на сколько
они были бы недостоверны, несут в себе ценную информацию. Например, нужно оценить
редкий функциональный блок, а в тех проектах, которым мы доверяем, такого рода блок не
разрабатывался, вот тогда мы вынуждены взять информацию из менее достоверных
проектов.
Чтобы можно было учитывать в методе степень доверия к исходным данным,
выполненных проектов, введѐм понятие значимости (веса) каждого проекта (  ik ). Модель
оценки значимости проектов в данной статье не рассматривается. Скажем только, что этот
вес может задаваться экспертом (менеджером проекта). Понятно, что для  ik должно
выполняться следующее условие:

k
i
 1 , для i
(3)
k
В некоторых выполненных проектах могут отсутствовать данные по количеству
разработанных элементов j-го типа, т.е. Eik, j  0 . Тогда, для того чтобы не потерять вес на
этих типах элементов, нужно его перераспределить по остальным проектам
'
пропорционально их весам: для k ' , если Eik, j  0 , то
 ik 
 ik
1   ik
'
для k
(4)
Теперь рассчитаем трудозатраты на каждый элемент каждого типа для нового проекта:
Ti ,0j    ik
k
Т ik, j
E
k
i, j
, где Eik, j  0 для i, j
(5)
Для оценки трудоѐмкости аналогичного функционального блока в новом проекте нужно
знать количество элементов j-го типа i-го функционального блока ( Eiоц, j ). Эти данные могут
быть получены в результате выполнения детального анализа требования. После этого можно
рассчитать значение трудозатрат необходимых для разработки i-го функционального блока:
Ti оц   Ti ,0j  E iоц, j
(6)
j
Трудозатраты всего проекта могут быть получены путѐм суммирования трудозатрат всех
функциональных блоков.
Пример оценки системы
В данном примере будут оценены трудозатраты на разработку подсистемы ведения
справочных данных (i = 1).
1. Определяем типы сложности элементов или сами элементы подсистемы ведения
справочных данных, если они не были определены ранее и не хранятся в базе данных о
выполненных проектах. Для подсистемы ведения справочных данных выделим три типа
элементов:
j = 1 : простые справочники – все поля имеют простые типы данных (целое, строка и т.п.);
j = 2: составные справочники – справочник состоит из любого количества простых полей
и любого количества полей, которые принимают значения других справочников;
j = 3: сложные справочники – для любой записи этого справочника существует
определѐнный набор записей из другого справочника.
2. Оцениваем сложность каждого элемента подсистемы (  i, j )
 1,1  0.1 ;  1, 2  0.3 ;
 1,1  0.6
3. Получаем данные из других проектов о количестве элементов ( Eik, j ) в оцениваемой
подсистеме и трудозатратах ( Ti k ), использованных на разработку этих подсистем.
Предположим, что у нас есть данные по двум проектам ( k  2 ):
E11,1  5 ;
E11, 2  5 ;
E12,1  20 ; E12, 2  10 ;
E11,3  2 ;
T11  150чел.  час.;
E12,3  10 ;
T12  350чел.  час. ;
4. Рассчитываем трудозатраты на разработку каждого типа элементов для обоих проектов
на основе количества этих элементов ( Eik, j ) и оценки сложности (  i, j ) в соответствии с
формулой (2):
T11,1  23.44 ;
T11, 2  70.31 ;
T11,3  56.25 ;
T1,21  63.64 ;
T1,22  95.46 ;
T1,23  191.00 ;
5. Определим важность каждого проекта путѐм распределения весов (  ik ):
 11  0.3 ;  12  0.7 ;
6. Рассчитываем среднюю стоимость одного элемента каждого типа в соответствии с
формулой (5):
T10,1  3.62 ;
T10, 2  10.90 ;
T10,3  21.80 ;
6. Выполним оценку количества элементов каждого типа ( Eiоц, j ) в создаваемой подсистеме.
Предположим, в создаваемой подсистеме будет следующее количество элементов:
E1оц,1  15 ;
E1оц, 2  10 ;
E1оц,3  5 ;
7. Рассчитаем оценку трудозатрат, оцениваемой подсистемы в соответствии с формулой
(6):
T1оц  272.3
Заключение
Рассмотренная методика оценки программного проекта разрабатывалась с учѐтом
требований малых и средних организаций, которые развиваются в жѐсткой конкурентной
борьбе и чья основная деятельности связана с производством программных продуктов.
Развитие малых организаций, разрабатывающих программные системы в России,
осложняется ещѐ и тем, что большая часть программного обеспечения является пиратским.
Хотя последние тенденции в политике нашего государства и навязывают приобретение
лицензионного программного обеспечения, но сложившийся менталитет руководителей ещѐ
не позволяет делать серьѐзные вложения в лицензионные системы или в их разработку.
Такая ситуация ставит под вопрос рентабельность фирм-разработчиков, вынуждая их
уходить в оффшор.
В этой ситуации разработчикам тяжело формализовать и автоматизировать свои
собственные рабочие процессы, тем более путѐм приобретения технологий и программного
обеспечения сторонних фирм. Как правило, такие приобретения требуют серьѐзных
финансовых вложений. Предложенная в статье методика формализует один из небольших,
но важных этапов технологии разработки и не требует финансовых вложений на еѐ
автоматизацию.
При разработке методики оценки учитывались такие требования, как: легкость
использования оценки; возможность использования статистики предыдущих проектов,
которая не велась в соответствии со специальными требованиями для оценки; возможность
учѐта нефункциональных требований; гибкость методики, т.е. она не должна быть привязана
к каким-то определѐнным единицам (функциональным блокам); и др.
Разработанная методика в том виде, в котором представлена в данной статье
удовлетворяет большей части предъявляемых требований, и кроме всего прочего позволяет
выполнять оценку на разных этапах разработки программного обеспечения. Например, в
самом начале жизненного цикла программной системы требуется грубая (предварительная)
оценка, которая может иметь точность до  200% [2], а в конце этапа анализа требований
оценка требуется более точная, поскольку на еѐ основе рассчитывается бюджет проекта и
сумма контракта. В предложенной методике уровень точности оценки зависит от
детализации функциональных блоков, которые могут иметь статус от элементарных блоков
системы до компонент и подсистем, что существенно упрощает использование методики.
В развитии предложенной методики планируются следующие исследования: 1) получение
параметров модели (оценки сложности (  i, j ) и значимости (весов) проектов (  ik )), на основе
статистических данных исходных проектов; 2) разработка методов оценки степени
достоверности данных исходных проектов; 3) идентификация и классификация
функциональных блоков программных систем; 4) идентификация параметров, влияющих на
стоимость программного проекта и на их основе уточнение модели и методики.
Список литературы
1 Михайловский, Н. Сравнение методов оценки стоимости проектов по разработке
информационных систем [Электронный ресурс] / Н. Михайловский. 2003. – 10 с. – Режим
доступа: http://www.pmprofy.ru/content/rus/79/797-article.asp.
2 Макконнелл С. Остаться в живых. Руководство для менеджера программных
проектов. Библиотека программиста / С. Макконнелл. – СПб.: Питер, 2006. – 240 с.
Yu. Yu. Yakunin
ESTIMATION OF LABOUR PRODUCTIVITY OF DEVELOPMENT OF PROGRAM
SYSTEM
The technique and mathematical model of an estimation of labour productivity of the program
project on the basis of the metrics based on functional points is described.