Научная статья на тему 'Оценка экономических ресурсов при управлении программными проектами'

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

CC BY
388
187
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ОЦЕНКА ПРОГРАММНЫХ ПРОЕКТОВ / ИНТЕРВАЛЬНЫЙ ПОДХОД / COCOMO II / FP

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Трубочкин Алексей Александрович, Малыгин Евгений Олегович, Никульчев Евгений Витальевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Трубочкин Алексей Александрович, Малыгин Евгений Олегович, Никульчев Евгений Витальевич

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Assessment of economic resources in the management of software projects

The article deals with current approaches assessment of software projects (size, scope, timing); review of existing methods; proposed interval approach to estimating software projects.

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

ных экспертных оценок [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 различные модели:

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

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

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

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

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.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

[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 О

i Надоели баннеры? Вы всегда можете отключить рекламу.