Оценка экономических ресурсов при управлении программными проектами Текст научной статьи по специальности «Компьютерные и информационные науки»

Трубссчшн Алексей АлександрсВи/ч,

(Малыгин ЕВгений ОлеясВич^ ЖикульчеВ Еёпений ВитальеВич

Оценка зкснсжическшх ресурссВ при упраВлении программ/ными проектами

В статье рассматриваются существующие подходы оценки программных проектов (размер, объем работ, сроки); проводится обзор существующих методов; предлагается интервальный подход к оценке программных проектов.

Оценка программных проектов, COCOMOII, FP, интервальный подход.

ведение

В настоящее время оценка программных проектов (ПП): размера, объема работ, сроков - является одним из основных этапов процесса создания программного обеспечения (ПО), хотя она и не выделена в отдельный процесс в стандарте ISO/IEC 12207 «Information Technology -Software Life Cycle Processes» [1]. Отсутствие или некорректная оценка параметров проектов влечет за собой разрушительные последствия, от недостаточной численности проектной команды, сжатых сроков и бюджета до свертывания разработки проекта.

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

В нашей стране создание ПО c 70-х гг. прошлого века регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации - серия ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. Процессы создания автоматизированных систем (АС), в состав которых входит и ПО, регламентированы стандартами ГОСТ 34.601-90, ГОСТ 34.602-89 ,ГОСТ 34.603-92. Нормы времени на разработку ПО отражены в рекомендациях «Укрупненные нормы времени на разработку программных средств вычислительной техники», «Укрупненные нормы времени на изготовление и сопровождение программных средств вычислительной техники», «Типовые нормы времени на программирование задач для ЭВМ». В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно [1]. В результате для каждого серьезного проекта приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПО, поэтому в отечественных разработках принято использовать современные международные стандарты [2].

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

Все методы оценки можно классифицировать как формальные и экспертные. Каждый метод имеет свои определенные допуски применение к ПП, такие как: размер проекта, стадия и стиль разработки, поддерживаемая модель разработки и точность оценки. Это говорит о том, что метод в разных ситуациях будет давать оценки разной точности. Одни методы лучше подходят для оценки объема работ, продолжительности, количества функций, другие работают независимо от вида программного обеспечения.

О О

S

S

^

Se>

О >-п S

¡=1

•nd

>■

bel О

л )

о

PQ •<

PLh

И

К

t-ч

О

Ч

ас ££

к

о щ

о

м

Метод «Сначала подсчет, затем вычисление» - состоит из нескольких этапов:

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

- Этап вычислений - основная идея заключается в преобразовании собранных исторических данных в некую оценку программного проекта. Пример: проект содержит 350 дефектов, причем ранее на исправление 150 дефектов потребовалось по 3 часа на дефект, значит, на исправление всех открытых дефектов потребуется 450 часов.

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

Метод индивидуальной экспертной оценки является самым распространенным методом оценки, но также и самым рискованным. Экспертные оценки не обязательно должны быть неформальными или интуитивными, исследования в точности показали неточность интуитивных экспертных оценок [3]. Экспертную оценку можно разделить на несколько подпроцессов, выполнение которых повышает точность оценки:

- Процесс структурирования - предназначен для условного разбиения задачи на несколько подзадач, выполнение которых потребует не более 2 дней работы, желательно чтобы гранулярность составляла У, / или полный день. Этот процесс необходим прежде всего для того чтобы в хорошо понятных задачах, оценщики не пренебрегали задачами, которые им не знакомы.

- Формирование контрольного списка оценки - предназначено для того, чтобы не забыть все особенности оцениваемого проекта. Представляет собой перечень вопросов по проекту.

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

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

- Декомпозиция по функциям или задачам - позволяет воспользоваться статическим законом больших чисел, по которому ошибки оценки группы, данные каждой функции или задаче, в сторону завышения и занижения до определенной степени компенсируют друг-друга при суммировании в общую оценки. Ледерер и Прасад обнаружили, что суммирование продолжительности подзадач отрицательно коррелируется с превышением сроков и объемов работ [2].

- Декомпозиция WBS - позволяет проявить невидимую работу, иногда скрывающуюся в виде забытых аспектов, задач проекта. Декомпозиция проекта осуществляется с применением структуры трудозатрат (WBS, Work Breakdown Structure). WBS - представляет собой список операций, который стоит учитывать при создании оценки.

- Вычисление лучшего и худшего случаев по стандартному отклонению

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

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

- Сравнение размера нового проекта с размером старого

- Формирование оценки размера нового проекта в процентах от старого

- Формирование оценки объема работ, руководствуясь размером нового проекта по сравнению с размером предыдущего проекта.

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

г

Представителями опосредованных методов являются:

Метод нечеткой логики - оценка происходит в несколько этапов.

1. Все функции классифицируются по категориям «очень малая», «малая», «средняя», «большая», «очень большая»

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

3. Вычисляется сумма произведений количества функций каждой категории на среднее количество строк в категории.

Метод стандартных компонентов - применяется для оценки проектов со сходной архитектурой. Оценка происходит в несколько этапов:

1. Идентифицируются стандартные компоненты и среднее количество строк на компонент.

2. По методу PERT определяется ожидаемое количество компонентов в новом проекте по формуле:

ОжидаемоеКоличествоКомпонентов = [Минимум + (4 * НаиболееВероятныйКоличество) + Максисмум]/6

3. Вычисляется оценка в строках кода путем произведения строк кода на количество ожидаемых компонентов.

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

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

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

Метод функциональных пунктов (function points, FP) - стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод предназначен для оценки на основе логической модели объема программного продукта количеством функционала, востребованного заказчиком и поставляемого разработчиком [4].

Общее количество функциональных точек программы зависит от количества элементарных процессов пяти типов:

- Входящие транзакции - транзакции, получающие данные от пользователя.

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

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

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

- Файлы внешних взаимодействий - файлы, участвующие во внешних взаимодействиях с другими системами.

В данной терминологии, транзакция - элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.

Голландский метод - является упрощенным «индикативным» методом вычисления функциональных пунктов предложенной ассоциацией метрик программного обеспечения Нидерландов (NESMA).

Метод ISBSG - International Software Benchmarking Standard Group разработала методику вычисления объема работ основанную на 3 факторах: размер ПО в functional points, тип среды разработки, максимальный размер группы. ISBSG создала ряд формул расчета трудозатрат для разных типов проектов (общий проект, проект среднего диапазона, настольная система, языки третьего, четвертого поколения, проект для больших компьютеров, доработка существующих проектов, новая разработка). Формулы выдают результат в человеко-месяцах:

П 4Q? v п 791

ЧеловекоМесяцы = 0,5 12 * ФукнциональныеПунты • * МаксимальныйРазмерГруппы

И О

из о

я и

СП

>

о ■-п

к

¡=1

•по

>■

bd О

л )

о

PQ •<

PLh

И

К

t-ч

О

Ч

ас ££

к

о щ

о

м

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

СрокВМесяцах = 3,0* ЧеловекоМесяцы^

Число 3 иногда заменяется на 2, 2.5, 3.5, 4.5 или другое число. Множитель может быть получен посредством калибровки по историческим данным организации.

Построение модели COCOMO (Constructive COst MOdel) и её производные являются самыми популярными алгоритмическими моделями для оценки трудоемкости разработки ПО. Базовая модель была представлена в 1981 г. Барри Боемом [5].

COCOMO - модель конструктивных затрат (COCOMO, Constructive Cost Model) является регрессионной моделью. Модель COCOMO использует три режима классификации сложности системы и среды разработки (табл. 1).

Таблица 1

Режимы классификации сложности системы и среды разработки

Режим Размер программного продукта Проект/команда Потребность в инновациях Срок сдачи и ограничения Среда разработки

Органический 2-50 KLOC Небольшой проект и команда - разработчики знакомы с инструментами и языком программирования Незначительная Либеральные Стабильная, в домашних условиях

Сблокированный 50-300 KLOC Средние проекты, средняя команда, обладающая средним уровнем возможностей Средняя Средние Средняя

Внедренный Более 300 KLOC Большие проекты, требующие большой команды Максимальная Серьезные ограничения Сложная / интерфейсы заказчика

Базовая модель СОСОМО:

Трудозатраты (Е) = а* (размер)ь [Человека - месяцев],

где а и Ь - константы, определенные на этапе регрессионного анализа (в зависимости от проекта), размер - это К1_ОС (тысячи строк кода), Е - трудозатраты в человеко-месяцах.

Значения констант а и Ь определяются с помощью регрессионного анализа, но большинство организаций не располагают массивом данных, достаточного для проведения анализа, поэтому можно воспользоваться базовыми значениями констант (табл. 2).

Таблица 2

Базовые значения констант а и Ь

Режим a b

Органический 2,4 1,05

Сблокированный 3,0 1,12

Внедренный 3,6 1,20

Длительность проекта:

Длительность проекта(ЮЕУ) = w* (Е) [Месяцев],

где ш и I - константы, значение которых определяется используемым режимом (табл. 3).

Таблица 3

Базовые значения констант w и z

Режим w z

Органический 2,5 0.38

Сблокированный 2,5 0.35

Внедренный 2,5 0.32

Численность исполнителей:

Средняя численность персонала (SS)

TDEV

[Члена команды (в среднем)]

Производительность(Р) =

COCOMO II является улучшенной версией исходной модели COCOMO. Благодаря новой версии облегчается выполнение оценки для объектно-ориентированного ПО, программ созданных с помощью спиральной и эволюционной моделей и ПО разрабатываемых на базе готовый коммерческих программ. В модели поддерживается: применение оценки на основе метода объектных точек, вероятностные диапазоны оценок. Фактически метод СОСОМО включается в себя 3 различные модели:

- Композиционная прикладная модель

- Модель ранней разработки проекта

- Пост-архитектурная модель

При выборе метода необходимо опираться на такую информацию о ПП как:

1. Размер проекта.

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

Средние проекты - преимуществом таких проектов является применение практически всех методов, подходящих как для больших, таки для маленьких проектов. Численность группы от 5 до 25 участников. Продолжительность от 3 до 12 месяцев.

Большие проекты - численность группы около 25 участников. Продолжительность от 6 до 12 месяцев и более.

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

3. Стадия разработки проекта, на которой проводится оценка - условно можно разделить на 3 стадии:

- ранняя - от момента начала построения концепции и до момента, когда требования определены;

- средняя - момент между начальным планированием и ранним конструированием;

- поздняя - момент от середины разработки и далее;

4. Возможная точность методов оценки.

Также существует такое понятие как - конус неопределенности, показывающий прогнозируемые уровни неопределенности на разных стадиях разработки проектов [2]. Другими словами конус показывает, что оценки становятся более точными по мере продвижения работы над проектом (смена жизненного цикла ПО) (рис. 1). По вертикальной оси отсчитывается относительная величина ошибки в проектах на разных стадиях разработки. Конус не будет сужаться сам собой, оценщик должен устранять источники неопределенности из проекта, т.е. уточнять концепцию, условия, требования и т.д.

р-п т рт,-№-■ мкс ■

и-.Ц-^-ВИ I |Л1Ш- л

згэшц

х^1

-------- — —^

и

Г. J

НЕ

и з*

П

п

[Щ

ш? %

Р1

н

щ

¥

о к о

г

г

и >-

из

о к

1=1 ■на

Ьс1

о

Рис. 1. Конус неопределенности для основных стадий проекта [1, с. 53]

1

Ц ||

л 1

о

м

•<

ей И

К

о

ас ££

к ё о ас о м

Разработка интервального подхода к оценке параметров проекта

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

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

Аппарат интервального анализа построен на основе интервальной арифметики, которую можно рассматривать как совокупность в пространстве вещественных интервалов. Интервал задается в виде границ на действительной оси х = [ . Результат операции с интервалами

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

Первым этапом обоснованно выбирается метод оценки параметров проекта (например, из приведенных выше в обзоре). На втором - происходит интервальная оценка параметров на основе имеющегося собственного опыта реализации программных систем.

На основе опыта организация может собрать статистическую информацию о выполнении 1 проектов, т.е. получить фактические значения трудозатрат (/ = 1, X) для проектов с определенными значениями соответствующих параметров модели. На основе собранной информации определяются интервалы значений коэффициентов ау уравнений трудозатрат по этапам:

1г = а1]к],

здесь - трудозатраты, ау = [а, а ] - интервальный коэффициент, к] - параметр этапа

(количество модулей, сложность алгоритмов и пр.), / - количество этапов; 7 - параметры разработки программного продукта.

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

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

В общем виде методика оценки интервальных параметров трудозатрат нефтяных месторождений состоит из трех этапов.

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

- Сбор статистических данных. Включает составление таблиц фактических трудозатрат по выполненным проектам в зависимости от исходных параметров месторождений.

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

Методика применена для управления проектами. В табл. 4 приведено сравнение трудозатрат проекта с 16-ю этапами, рассчитанных по разработанной интервальной методике с фактическими трудозатратами выполнения проекта.

Таблица 4

Сравнение оценки трудозатрат выполнения проекта по различным методикам с фактическими данными

Трудозатраты По разработанной методике Фактические данные

Минимальная оценка Максимальная оценка

Í1 48,8 61,3 51,9

Í2 3,3 6,2 4,0

Í3 98,0 115,2 114,4

Í4 96,6 101,6 100,7

Í5 153,4 209,5 179,1

Í6 364,7 410,2 383,0

Í7 70,5 87,5 78,7

Í8 78,5 108,0 94,8

Í9 84,9 106,8 99,0

Í10 32,1 36,7 34,2

Í11 45,7 65,9 53,0

Í12 15,0 18,2 16,9

Í13 20,8 23,7 21,3

Í14 24,9 30,0 25,3

Í15 54,2 84,9 67,0

Í16 18,6 25,0 21,0

Итого 1209,9 1490,7 1344,3

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

- рассчитать интервальные трудозатраты проекта;

- спланировать состав исполнителей;

- произвести расчет себестоимости проекта;

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

Заключение

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

Литература

[1] Вендоров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. -М.: Финансы и статистика, 2002.

[2] Макконнелл С. Сколько стоит программный проект. - СПб: «Русская Редакция»- Питер, 2007.

[3] Липаев В.В. Программная инженерия. Методологические основы. - М.: ВШЭ (ГУ) 2006.

[4] Кульдин С.П. Генетический подход к проблеме оценки трудоемкости и предсказания сроков сдачи программного обеспечения в эксплуатацию // Труды 4-й Международной конференции «Современные информационные технологии и ИТ-образование». - М: МГУ им. М.В.Ломоносова, 2009.

[5] Boehm B. W., Horowitz E., Madachy R. etc. Software Cost Estimation with Cocomo II. - Prentice Hall Ptr, 2000.

[6] Малыгин Е.О. Новые подходы к управлению сроками выполнения проектов // Известия высших учебных заведений. Проблемы полиграфии и издательского дела. - 2009. - №2, с. 136-140.

[7] Малыгин Е.О. Интервальный подход к оценке трудовых затрат на выполнение проектов разработки нефтяных месторождений // Нефть, газ и бизнес. - 2010. - №1, с. 75-78.

i

И О

ас о

я и

¡зс-

Ш >

£=1 о ■-п К

¡=1

•по

>■

bd О