ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОЙ СИСТЕМЫ
- Авторы: Якунин Ю.Ю.1
-
Учреждения:
- Сибирский федеральный университет
- Выпуск: Том 9, № 2 (2008)
- Страницы: 87-90
- Раздел: Статьи
- URL: https://journals.eco-vector.com/2712-8970/article/view/508336
- ID: 508336
Цитировать
Полный текст
Аннотация
Описаны методика и математическая модель оценки трудоемкости программного проекта на базе мет- рик, основанных на функциональных точках.
Полный текст
Организации, занимающиеся разработкой про- граммных систем, особенно для коммерческой реали- зации, в том или ином виде используют методику оценки программного проекта. Проблема состоит в том, что в России в настоящее время действуют уста- ревшие модели по оценке, утвержденные Госкомтруда в 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 )), на основе статистических данных исходных проектов; разработка методов оценки степени достоверности данных исходных проектов; мость программного проекта и на их основе уточнение модели и методики.×
Список литературы
- 1. Михайловский, Н. Сравнение методов оценки стоимости проектов по разработке информационных систем [Электронный ресурс] / Н. Михайловский. Электрон. дан. Режим доступа: http://www.pmprofy.ru/content/rus/79/797-article.asp. Загл. с экрана.
- 2. Макконнелл, С. Остаться в живых. Руководство для менеджера программных проектов / С. Макконнелл. СПб. : Питер, 2006. 240 с. (Библиотека программиста).
Дополнительные файлы
![](/img/style/loading.gif)