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 are described.

全文:

Организации, занимающиеся разработкой про- граммных систем, особенно для коммерческой реали- зации, в том или ином виде используют методику оценки программного проекта. Проблема состоит в том, что в России в настоящее время действуют уста- ревшие модели по оценке, утвержденные Госкомтруда в 1986 г. В этой ситуации фирмы вынуждены исполь- зовать методики иностранного происхождения. Осо- бенно остро стоит вопрос в организациях, которые получили или собираются получить сертификат по стандарту ГОСТ Р ИСО 9000-2001. Использование иностранных методик сопровожда- ется рядом проблем: методики и модели созданы без учета специфи- ки разработки программных систем в Росси; параметры моделей оцениваются по статистиче- ским данным о выполненных проектах в зарубежных странах. Сами статистические данные как правило закрыты, а потому не вызывают доверия; математические модели не представлены в пол- ном объеме, что не позволяет оценить достоверность этих моделей и самостоятельно выполнить оценку их параметров. Все методики оценки делятся на две группы: микрооценка и макрооценка. Методы микрооценки осно- ваны на точном знании процесса. Такова, например, Oracle AIM и оценки трудоемкости для него. Во всех случаях, когда для построения модели оценки необхо- димо видение разбивки работ и оценка каждой инди- видуальной работы, метод относится к группе микро- оценки. Методы макрооценки основаны на функцио- нальных требованиях. Таковы методы функциональ- ных точек (FP) типа СОСОМО. В статье Н. Михайловского [1] проведен сравни- тельный анализ методик оценки стоимости проектов по разработке программных систем. Из рассмотренных методик две имеют закрытые модели оценки, а из двух методик с открытыми моделями, у одной не дос- тупны статистические данные, на основе которых выполнялись расчеты оценки параметров модели. По- следняя методика (IFPUG FPA) основана на статисти- ческих данных зарубежных стран. Возникает потребность в открытых российских разработках такого рода методик. Открытые модели следующие: производить оценку и настраивать модели на основе собственного опыта организаций; использовать свои обозначения и понятия функ- циональных блоков, что наиболее актуально в посто- янно меняющихся технологиях разработки. В описываемой модели и методе оценки трудоем- кости программной разработки учтены наиболее су- щественные факторы. С развитием метода будут учи- тываться и другие факторы, влияющие на стоимость программного проекта. Концепция метода. Оценка программного проекта является исходными данными и отправной точкой для планирования. Для составления плана проекта необ- ходимо знать три основных показателя: длительность (продолжительность) разработки, требуемые усилия (трудозатраты), количество специалистов (штат раз- работчиков). Эти показатели позволяют определить стоимость разработки проекта. Основным показателем, который требуется оце- нить, является трудоемкость. Остальные показатели можно считать в той или иной степени производными. Для оценки трудоемкости требуется набор статисти- ческих данных о предыдущих проектах. Такими дан- ными могут являться: трудоемкость функционального блока, подсистемы и проекта в целом; длительность проекта и каждого этапа в отдельности; количество ошибок на один функциональный блок или строку программного кода; используемые технологии разра- ботки и организации процесса разработки; размер ко- манды разработчиков и их квалификация. Рассматриваемый в данной статье метод относится к группе макрооценок и основан на использовании подхода функциональных точек. Данный метод пред- полагает выполнение следующих шагов: на основе предварительного анализа требова- ний должны быть определены основные функцио- нальные подсистемы (блоки) будущего программно- го продукта; для каждого типа функционального блока опре- деляется количество типов элементов и производится оценка сложности каждого типа элемента относитель- но друг друга (в том случае, если прежде такая оценка не производилась); требований к программной системе можно выделить несколько типов элементов, из которых эти требова- ния состоят. В любом случае требования к системе делятся на функциональные и нефункциональные. От функциональных требований трудоемкость разработ- ки системы зависит в большей степени, хотя некото- рые нефункциональные требования могут очень силь- но влиять на стоимость разработки. В предлагаемом методе пока учитываются только функциональные требования. В общем случае для любых подходов функциональные требованиях к системе на самом вы- соком уровне могут быть описаны как требования к подсистемам. Каждая подсистема может состоять из набора функций (по ГОСТ 34.602-89) или набора ва- риантов использования (по IEEE 830). И те и другие имеют детальное описание или спецификацию. Для того, чтобы отвязаться от разных стандартов и подходов к описанию требований введем понятие «функциональный блок». Под функциональным бло- ком будем понимать набор однотипных функций, на- правленных на решение одной задачи. Задача может быть нацелена как на результат пользователя, так и на программный результат. Объем функционального блока может быть любым, но предпочтительно, чтобы все функциональные блоки были одного уровня абст- ракции, хотя это не обязательно. Например, для уров- ня подсистем можно считать следующие функцио- нальные блоки: «подсистема авторизации», «подсис- тема формирования отчетов», «подсистема ведения справочных данных» и т. п. Это крупные функцио- нальные блоки, для более точной оценки рекоменду- ется использовать функциональные блоки, например, уровня вариантов использования. Так как рассматриваемый метод основан на подхо- де макрооценки, то исходными данными для него яв- ляется статистика о предыдущих выполненных проек- тах. Статистические данные по каждому выполненно- му проекту должны содержать информацию по всем функциональным блокам следующего содержания: i, j Ek - количество элементов по типам сложности, где i - номер функционального блока, j - номер типа сложности, k - номер выполненного проекта; T k - трудозатраты, использованные на разработку i i-го функционального блока в k-м проекте. Очевидно, что от проекта к проекту объем (или со- держание) однотипного функционального блока мо- жет различаться. Обычно руководителю проекта из- вестны трудозатраты, использованные на разработку k для каждого функционального блока определя- функционального блока в целом ( Ti ), а не отдельных ется количество элементов каждого типа; выполняется вычисление оценки трудозатрат для каждого функционального блока разрабатываемой системы; в результате суммирования данных по всем блокам получаем оценки трудозатрат и стоимости разра- ботки всей системы. Исходные данные для оценки. В зависимости от подхода в организации к описанию и формализации его частей. Но для оценки трудоемкости такого же функционального блока в новом (оцениваемом) про- екте нужно знать трудозатраты на каждый элемент этого функционального блока в предыдущих проек- тах. Для решения этой проблемы вводится понятие сложности элементов функциональных блоков и оценка сложности ( si, j ). В качестве примера приведем возможные типы элементов функционального блока и оценки их сложности (см. таблицу). Типы элементов функционального блока Тип элемента Оценка сложности (%) Описание Простой объект 3,85 Количество простых и составных полей менее 15 Средний объект 7,69 Количество простых и составных полей более 15, но менее 50 Сложный объект 11,54 Количество простых и составных полей более 50 Простая транзакция 3,85 Выборка данных посредствам SQL-запроса или хранимой процедуры Средняя транзакция 7,69 Выполнение нескольких SQL-запросов и/или хранимых процедур Сложная транзакция 19,23 Реализация математического алгоритма Простая таблица 7,69 Таблица, состоящая из простых полей, для создания которой используется один несложный SQL-запрос Средняя таблица 15,38 Таблица, состоящая как из простых полей, так и из опциональных и/или списочных. Для создания таблицы используется один или несколько про- стых SQL-запросов Сложная таблица 23,08 Таблица, состоящая из простых полей и/или опциональных и списочных полей. Для фильтрации данных используются дополнительные поля на форме. Для загрузки данных используются один или несколько сложных SQL-запросов (хранимые процедуры) Примечание. Под объектом здесь понимается совокупность простых и составных полей, образующих некоторую сущ- ность, которая представляется в системе как единое целое на отдельной форме, закладке, в разделе и т. п. Над объектом могут совершаться стандартные операции сохранения, изменения и удаления. Под транзакцией понимается набор действий пользователя и/или системы, выполняющихся по событию на форме и приводящих к определенному ощутимому результа- ту. Например, транзакцией можно назвать реализацию некоторого математического алгоритма или выборку данных для отчета. Под таблицей понимается таблица с набором простых и составных полей, позволяющая выполнять стандартные действия над записями (сортировка, фильтрация по столбцам, настройка таблицы). В приведенном примере оценка сложности выпол- нена в процентах, общая сумма всех оценок составля- ет 100 %. Для использования оценки сложности в мо- дели удобно работать с приведенной оценкой. Тогда должно выполняться следующее условие: åsi, j = 1 , для "i . (1) j Значения оценки сложности элементов функ- ционального блока могут быть получены двумя способами: при наличии достаточного количества статисти- ческих данных о выполненных проектах оценку слож- ности можно будет рассчитать, например, через оцен- ку матожидания; при отсутствии достаточного количества стати- стических данных оценка может задаваться экспер- том, например, менеджером проекта. Оценка функциональных блоков. Очевидно, что для оценки стоимости проекта нужно использовать статистические данные из нескольких проектов. Тогда возникает вопрос, насколько достоверны данные из того или иного проекта и насколько корректно ис- пользовать эти данные с равной степенью доверия. Конечно, можно было исключить проекты с меньшей степенью достоверности. Но тогда, как оценить эту степень достоверности? Кроме того, любые статисти- ческие данные, на сколько они были бы недостовер- ны, несут в себе ценную информацию. Например, нужно оценить редкий функциональный блок, а в тех проектах, которым мы доверяем, такого рода блок не разрабатывался, вот тогда мы вынуждены взять ин- формацию из менее достоверных проектов. Чтобы можно было учитывать в методе степень доверия к исходным данным выполненных проектов, Как было отмечено выше, si, j нам необходима введем понятие значимости (веса) каждого проекта для получения трудозатрат в разрезе типов элементов, так как обычно известна информация только о стои- мости всего функционального блока. Для каждого k i ( bk ). Модель оценки значимости проектов в данной статье не рассматривается. Скажем только, что этот вес может задаваться экспертом (менеджером проек- исходного проекта рассчитывается Ti, j - трудозатра- k ты, использованные на разработку элементов j-го типа в k-м проекте для i-го функционального блока. та). Понятно, что для bi дующее условие: должно выполняться сле- Примечание. Исходные проекты - это выполненные про- i åbk = 1, для "i . (3) екты, чьи статистические данные будут использоваться для оценки стоимости нового проекта. Эти трудозатраты рассчитываются путем весового распределения трудозатрат всего функционального k В некоторых выполненных проектах могут отсут- ствовать данные по количеству разработанных эле- k блока по типам его элементов: ментов j-го типа, т. е. Ei, j = 0 . Тогда, для того чтобы T k = i, k si, j × Ek j image i T (2) не потерять вес на этих типах элементов, нужно его перераспределить по остальным проектам пропорцио- i, j . i, åsi, j × Ek j ' нально их весам: для "k' , если Ek = 0 , то j i, j k 1 1 1 bk = bi для "k . (4) T1,1 = 23, 44 ; T1,2 = 70,31 ; T1,3 = 56, 25 ; image i i 1 - bk ' T 2 = 63, 64 ; T 2 = 95, 46 ; T 2 = 191, 00 . Теперь рассчитаем трудозатраты на каждый эле- 1,1 1,2 1,3 мент каждого типа для нового проекта: k Определим важность каждого проекта путем i распределения весов ( bk ): = bk k 0 Тi, j image T , где E ¹ 0 для "i, j . (5) i, j å i k i, j 1 2 k Ei, j Для оценки трудоемкости аналогичного функцио- нального блока в новом проекте нужно знать количе- b1 = 0,3 ; b1 = 0,7 . Рассчитываем среднюю стоимость одного эле- мента каждого типа в соответствии с формулой (5): ство элементов j-го типа i-го функционального блока ( оц T 0 1,1 1,2 = 3, 62 ; T 0 1,3 = 10,90 ; T 0 = 21,80 . Ei, j ). Эти данные могут быть получены в результате выполнения детального анализа требования. После этого можно рассчитать значение трудозатрат, необ- ходимых для разработки i-го функционального блока: оц 0 оц Выполним оценку количества элементов каждо- i, j го типа ( Eоц ) в создаваемой подсистеме. Предполо- жим, в создаваемой подсистеме будет следующее ко- личество элементов: оц оц Ti = åTi, j × Ei, j . (6) Eоц = 15 ; E = 10 ; E = 5 . 1,1 1,2 1,3 j Трудозатраты всего проекта могут быть получены путем суммирования трудозатрат всех функциональ- ных блоков. Пример оценки системы. В данном примере бу- дут оценены трудозатраты на разработку подсистемы ведения справочных данных (i = 1): Определяем типы сложности элементов или са- ми элементы подсистемы ведения справочных дан- ных, если они не были определены ранее и не хранят- ся в базе данных о выполненных проектах. Для под- системы ведения справочных данных выделим три типа элементов: j = 1: простые справочники - все поля имеют про- стые типы данных (целое, строка и т. п.); j = 2: составные справочники - справочник состоит из любого количества простых полей и любого коли- чества полей, которые принимают значения других справочников; j = 3: сложные справочники - для любой записи этого справочника существует определенный набор записей из другого справочника. Оцениваем сложность каждого элемента подсис- темы ( si, j ): s1,1 = 0,1 ; s1,2 = 0,3 ; s1,1 = 0,6 . i, j Получаем данные из других проектов о количе- стве элементов ( Ek ) в оцениваемой подсистеме и i трудозатратах ( T k ), использованных на разработку этих подсистем. Предположим, что у нас есть данные по двум проектам ( k = 2 ): 8. Рассчитаем оценку трудозатрат подсистемы в соответствии с формулой (7): T оц = 272,3 . 1 Рассмотренная методика оценки программного проекта разрабатывалась с учетом требований малых и средних организаций, которые развиваются в жест- кой конкурентной борьбе и чья основная деятельности связана с производством программных продуктов. Развитие малых организаций, разрабатывающих про- граммные системы в России, осложняется еще и тем, что большая часть программного обеспечения являет- ся пиратской. Хотя последние тенденции в политике нашего государства и навязывают приобретение ли- цензионного программного обеспечения, но сложив- шийся менталитет руководителей еще не позволяет делать серьезные вложения в лицензионные системы или их разработку. Такая ситуация ставит под вопрос рентабельность фирм-разработчиков, вынуждая их уходить в оффшор. В этой ситуации разработчикам тяжело формали- зовать и автоматизировать свои собственные рабочие процессы, тем более путем приобретения технологий и программного обеспечения сторонних фирм. Как правило, такие приобретения требуют серьезных фи- нансовых вложений. Предложенная методика форма- лизует один из небольших, но важных этапов техно- логии разработки и не требует финансовых вложений в ее автоматизацию. При разработке методики оценки учитывались та- кие требования, как легкость использования оценки; возможность использования статистики предыдущих проектов, которая не велась в соответствии со специ- альными требованиями для оценки; возможность 1 1 1 1 E1,1 = 5 ; E1,2 = 5 ; E1,3 = 2 ; T1 = 150 [чел.-ч]; учета нефункциональных требований; гибкость ме- тодики, т. е. она не должна быть привязана к каким- 2 2 2 2 E1,1 = 20 ; E1,2 = 10 ; E1,3 = 10 ; T1 = 350 [ чел.-ч]. то определенным единицам (функциональным бло- i, j 4. Рассчитываем трудозатраты на разработку каж- дого типа элементов для обоих проектов на основе количества этих элементов ( Ek ) и оценки сложности ( si, j ) в соответствии с формулой (2): кам), и др. Разработанная методика в представленном виде удовлетворяет большей части предъявляемых требо- ваний и кроме всего прочего позволяет выполнять оценку на разных этапах разработки программного обеспечения. Например, в самом начале жизненного цикла программной системы требуется грубая (пред- варительная) оценка, которая может иметь точность идентификация и классификация функциональ- ных блоков программных систем; до ±200 % [2], а в конце этапа анализа требований идентификация параметров, влияющих на стои- оценка требуется более точная, поскольку на ее осно- ве рассчитывается бюджет проекта и сумма контракта. В предложенной методике уровень точности оценки зависит от детализации функциональных блоков, ко- торые могут иметь статус от элементарных блоков системы до компонент и подсистем, что существенно упрощает использование методики. В развитии предложенной методики планируются следующие исследования: i получение параметров модели (оценки сложно- сти ( si, j ) и значимости (весов) проектов ( bk )), на основе статистических данных исходных проектов; разработка методов оценки степени достоверности данных исходных проектов; мость программного проекта и на их основе уточнение модели и методики.