Разработка методики предварительной оценки стоимости IT-проектов

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Разработка методики предварительной оценки стоимости IT-проектов

Выпускная квалификационная работа магистра

по направлению подготовки 38.04.05 "Бизнес-информатика"

(образовательная программа "Информационная аналитика в управлении предприятием")

Пермь 2016



Аннотация

стоимостной программный проект риск

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

Для достижения цели, поставленной в данной работе, было проведено исследование в четырёх разных компаниях, специализирующихся на разработке сайтов:

«Амадо», интернет-агентство, город Пермь.

«Vitamin group», студия, город Пермь.

«Digital spectr», web-студия, город Пермь.

«Digital wand», web-студия, город Москва.

Проведён анализ возможных рисков характерных для данной предметной области и значимости последствий их возникновения.

Работа содержит 49 страниц, 4 таблицы, 1рисунок, 3 приложения.

2016 год, кафедра информационных технологий в бизнесе.



Оглавление

Аннотация

Оглавление

Введение

Глава 1. Оценка программных проектов

Глава 2. Обзор существующих методов оценки проектов

2.1 Общие методы оценки

2.2 Метод Delphi

2.3 COCOMO

2.4 SLIM

2.5 SEER-SEM

2.6 Экстремальное программирование

2.7 PERT

2.8 Покер планирование

Глава 3. Существующая практика анализа проектов в сфере web-разработки

Глава 4. Разработанная методика предварительной оценки стоимости IT-проекта в сфере web-разработок

Заключение

Библиографический список



Введение

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

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

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

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

Наиболее точная предварительная оценка стоимости проекта позволит снизить риск потери проекта и предотвратить возникновение убытков вместо прибыли.

Данное исследование направлено на совершенствование системы анализа затрат на проект ИТ-предприятия и решение следующих проблем:

Нечёткое распределение средств на ИТ-проекты. Между планируемыми расходами и фактическими в большинстве случаев наблюдается существенное различие.

Нечёткая оценка предполагаемых затрат (стоимости ИТ-проектов).

Возникновение отрицательной оценки со стороны заказчика о работе компании.

Отсутствие контроля над денежными потоками.

Отсутствие обоснования расходов ИТ-отдела.

Отсутствие регламентированного метода для составления бюджета проекта.

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

Основным направлением работы является разработка методики, которая помогла бы разрешить данную проблему и снизить риски возникновения убытков или помочь покрыть их за счёт других работ организации.

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

Решение данных проблем предполагается посредством методов, направленных на:

Сбор и анализ требований к проекту.

Предварительная оценка стоимости проекта.

Анализ предварительной оценки стоимости.

Корректировка предварительной оценки стоимости.

Составление итогового плана на проект.

Объект исследования: управление IT-проектами.

Предмет исследования: формирование стоимости IT-проектов.

Цель данной работы: Разработка и обоснование метода предварительной оценки стоимости проекта.

Для достижения заданной цели на данном этапе были поставлены следующие задачи:

Изучить процесс управления стоимостью IT-проекта.

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

Выявить достоинства и недостатки существующих методов определения стоимости проекта.

Выявить возможные риски, которым могут подвергаться проекты web-студий.

Изучить методы оценки проектов, используемые в исследуемых организациях.

Разработать и опробовать методику для составления предварительной оценки проекта.

Проанализировать полученные результаты.

Для выполнения задач и достижения цели будет проведено исследование методов составления оценки ИТ-проектов, чтобы предоставить комплексное решение для построения и анализа бюджет.



Глава 1. Оценка программных проектов

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

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

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

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

Что касается недооценки, то она тоже имеет свои минусы и не решит проблемы, которые могут возникнуть при переоценке проекта. Недооценка создаёт множество проблем как очевидных, так и скрытых. При наблюдении за процессами оценки и разработки программных продуктах в исследуемых организациях были выявлены такие негативные аспекты как:

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

Статистическое снижение вероятности своевременного завершения. Разработчики обычно склонны оценивать объём работ на 20-30 % ниже реального [30]. Даже если просто воспользоваться их обычными оценками, планы проекта будут весьма оптимистичными.

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

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

Дополнительные встречи с начальством и обсуждение хода проекта и мер, необходимых для того, чтобы нормализовать план работ по проекту.

Частые переоценки для определения новой даты сдачи проекта.

Общение с клиентом по поводу нарушения срока.

Подготовка промежуточных версий продукта.

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

6. Реализация задач обходными, менее эффективными решениями из-за поджимающих сроков.

Зарубежная статистика говорит, что многие ИТ-проекты не достигают своей цели. Так, по разным оценкам, доля ИТ-проектов, заканчивающихся неудачей, колеблется в диапазоне от 37 до 75%. По результаты исследования PMI, в котором анализировались 23 тысячи проектов по разработке приложений, только 26% ИТ-проектов выполняется вовремя и в рамках бюджета, 46% опаздывают или выходят за рамки бюджета, а 28% проваливаются. Общей статистики по российским проектам, к сожалению, нет. Существует единственное исследование Hewlett-Packard и Economist Intelligence Unit согласно которому, только 5% российских ИТ-проектов завершаются в срок [23].

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

Исследование российской ассоциации управления проектами СОВНЕТ показало, что профессиональное управление проектами позволяет сэкономить до 30% времени и до 20% средств [22].

При этом необходимо понимать, что управление проектом - затратная деятельность. Согласно мировой статистике на управление проектом уходит от 2 до 15% его бюджета. Управление проектом имеет смысл и окупается только в том случае, если перед проектом стоят действительно серьезные ограничения: по срокам, бюджету, качеству и т.д. Если же перед организацией и проектом серьезных вызовов - конкурентных, нормативных, экономических и т.д. нет, то управление проектами внедрять не имеет смысла - оно не будет работать [23].

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

Здесь стоит сделать уточнение какой проект можно считать успешным, а какой провальным. По словам председателя комитета по стандартам Российского союза ИТ-директоров (СоДИТ) Марины Аншиной, успешным можно считать тот проект, суммарные затраты на выполнение, которого меньше, чем полученные от его внедрения выгоды, включая побочные эффекты. Соответственно неуспешный проект - тот, затраты на который превышают полученные от него выгоды. Поэтому определить успешность проекта далеко не просто - даже грамотно посчитать затраты удается далеко не всем, а уж выразить выгоды в денежном эквиваленте зачастую вообще невозможно [22].

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

Альберт Ледерер (Albert Lederer) и Джайеш Прасад (Jayesh Prasad) (научные деятели из университета Dayton (США) в сфере информационных технологий), обнаружили, что самым распространённым методом оценки является сравнение нового проекта с похожими проектами, которые выполнялись в организации ранее, причём метод опирается исключительно на экспертное мнение. Как выяснилось данная методика имеет мало общего с точной оценкой. Также их исследование выяснило, что догадки, интуиция, неструктурированные экспертные оценки, аналогии и т.д. являются преобладающими стратегиями, используемыми в 60-85 % случаев.

Причины возникновения ошибок:

Неточная информация о проекте.

Неточная информация о возможностях организации-исполнителя.

Попытки оценить изменяющиеся цели.

Нестабильные требования.

Незнакомая область деятельности.

Незнакомая технологическая область.

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

Завышенные ожидания от применения новых средств и методов разработки.

Слишком упрощённая оценка.

Импровизированная оценка.

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

Изменение требований.

Изменения в требованиях часто не отслеживаются, а проект не подвергается переоценке, как это должно быть. В хорошо управляемом проекте исходный набор требований принимается за точку отсчета, на основании которой оцениваются затраты и сроки. По мере добавления новых или пересмотра старых требований оценки затрат и стоимости также должны пересматриваться с учетом этих изменений. На практике руководители проектов часто пренебрегают обновлением оценок стоимости и затрат при изменении требований. Возникает парадоксальная ситуация: оценка исходной функциональности могла быть правильной, но после того, как проект был расширен десятками новых требований (согласованных, но не учтенных), у него не остается ни малейшего шанса выдержать исходную оценку. Все согласны, что добавленные возможности были полезными, - а проект становится опоздавшим [30].

Для проектов в сфере web-разработок могут быть свойственны такие риски как:

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

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

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

Клиент не предоставляет необходимые данные. На первых этапах проектов от клиента требуется максимум информации о том, каким он видит готовой продукт, какой функционал ему нужен и как он должен выглядеть. Затягивание клиентом принятия решений и предоставления списка требований, фотографий, образцов документов и форм откладывает старт разработки проекта на неопределённый срок.

Нечёткие требования. Ситуация, чем-то похожая на предыдущую. Когда требования предоставляются в начале проекта, техническое задание утверждено, составлен план работ, составлены необходимые оценки, а требования от клиента всё ещё продолжают поступать. Хуже всего, если новые противоречат предыдущим, работы для реализации, которых уже выполнено и деньги потрачены.

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

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

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

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

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

Учёт рисков не означает отказ от борьбы с ними, это не попытка ухода от проблемы вместо её решения. Во многих случаях правильней будет именно создать такие условия, когда риск из разряда вероятных переходит в разряд невозможных. Возможно, однако, что часть рисков так и не смогут быть устранены. Именно в этом случае и будет полезно учесть подобные риски.



Глава 2. Обзор существующих методов оценки проектов

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

Для того, чтобы выяснить какие средства и подходы существуют для решения проблемы, обозначенной в данной курсовой работе, был проведён анализ научной литературы в области информационных технологий. В список рассматриваемых работ вошли в основном публикации журналов ВАК, статьи из междисциплинарного научного журнала «Бизнес-информатика», работы из архива высшей аттестационной комиссии и другие источники.

ВАК - Высшая аттестационная комиссия при Министерстве образования и науки Российской Федерации, созданная в целях обеспечения государственной научной аттестации, имеющая официальный Интернет-ресурс для публикации работ.

«Бизнес-информатика» - рецензируемый междисциплинарный научный журнал, выпускаемый с 2007 года Национальным исследовательским университетом «Высшая школа экономики» (НИУ ВШЭ). Администрирование журнала осуществляется факультетом бизнес-информатики НИУ ВШЭ. В соответствии с решением президиума Высшей аттестационной комиссии Российской Федерации с 2010 года журнал включен в Перечень российских рецензируемых научных журналов, в которых должны быть опубликованы основные научные результаты диссертаций на соискание ученых степеней доктора и кандидата наук.

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

В статье Н.Л. Коровкина и Е.П. Трушкина «Разработка модели количественной оценки уровня зрелости управления ИТ-проектами» рассматривается методика оценки ИТ-проекта, построенная на утверждении П. Страссмана, в котором говорится, что расходы на ИТ имеют сильную корреляцию с административными, коммерческими и управленческими расходами [13,14]. В методике, описанной в данной статье акцентировано внимание на то, что западные модели для оценки проектов в исходном виде не совсем подходят для предприятий Российского рынка, проведён анализ и сделаны некоторые поправки в описанной методологии, так же учитываются расходы на аутсорсинг. «Затраты на аутсорсинг входят в эксплуатационные затраты, но не относятся непосредственно к поддержке каких бы то ни было ИТ-активов на балансе предприятия. Однако, любой аутсорсинг представляет собой либо использование внешнего ИТ-персонала для обслуживания активов заказчика, либо использование как персонала, таки активов провайдера» [14]. Принципы оценки ИТ-проектов в приведённой статье рассчитаны на более масштабные и дорогостоящие проекты, чем те, которые выполняются в web-студиях, вдобавок, они не учитывают ряд специфических характеристик и условий, свойственных для интернет-проектов.

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

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

В статье А.А. Кратенок «Инструментальный метод оценки стоимости ИТ-проектов на стадии предварительного проектирования» предлагает использовать такие модели как COCOMO II (Constructive Cost Model), метод PERT или анализ продукта методом функциональных точек [16].

В статье В.В. Жуковой «Финансовая структура и модель бюджетирования в торговой компании» описывается финансовая структура и финансовая модель бюджетирования торговой компании. Описаны должности и их роли в финансовых потоках предприятия. Также приводится список возможных расходов предприятия. Опираясь на эту статью, можно составить список расходов исследуемой организации. Проанализировать какие роли существуют в компании сейчас, сравнить их с теми, которые описаны в статье. Безусловно, финансовая структура и система бюджетирования, представленная в данном источнике не подходит для применения к исследуемым компаниям или любой другой организации в сфере информационных технологий, однако, может быть очень полезна для построения необходимой модели [10].

Процессно-ориентированное бюджетирование исследуется также Дж. Антосом, Дж. Бримсоном, И.Б. Немировским, И.А. Старожуковой. Они не рассматривают финансовые ресурсы детально, однако бюджеты организаций напрямую связаны с их стратегическими целями. Вместе с тем, не существует ЦФО, которые бы относились к производственным подразделениям предприятия, что приводит к следующей парадоксальной ситуации: если в рамках одного подразделения ведется несколько направлений деятельности, хоть и частично, то руководитель подразделения не несет никакой ответственности за результаты финансового характера.

К сожалению, в ходе любой деятельности могут возникать ошибки и недочёты. О том, какие ошибки могут подстерегать в процессе бюджетирования и как их избежать изложено в статье В.В. Жуковой «Ошибки в бюджетировании на российских предприятиях и способы их исправления» [11].

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

Полезные тезисы можно найти в статьях журнала «Бизнес-информатика», таких как:

«Влияние информационно-коммуникационных технологий на управление бизнес-процессами малых и средних предприятий в развивающихся странах» - В.В. Таратухин, доктор философии, кандидат технических наук, заведующий базовой кафедрой SAP Национального исследовательского университета «Высшая школа экономики», Е.А. Баженова, аспирант кафедры инноваций и бизнеса в сфере информационных технологий Национального исследовательского университета «Высшая школа экономики».

«Потенциальная доходность информационных объектов» - Р.А. Будник, кандидат юридических наук, ведущий научный сотрудник Научно-методического Центра «Кафедра ЮНЕСКО по авторскому праву и другим правам интеллектуальной собственности» Национального исследовательского университета «Высшая школа экономики».

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

«Информационная мощность компании» - В.К. Абросимов, доктор технических наук, старший научный сотрудник, руководитель аналитической службы ЗАО «Бизнес Компьютер Центр», С.А. Канев, вице-президент ЗАО «Бизнес Компьютер Центр», DBA.

«Разработка и внедрение систем управления финансовой эффективностью» - С.Н. Брускин, заведующий лабораторией сложных организационно-технологических систем МФТИ.

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

«Обоснование инвестиций в информационные технологии на основе дерева бизнес-драйверов» - Н.Л. Коровкина, доцент кафедры корпоративных информационных систем, факультет бизнес-информатики, Национальный исследовательский университет «Высшая школа экономики».

В последней статье из приведённого списка предложен подход к разработке методики обоснования инвестиций в ИТ-проекты за счет установления их взаимосвязи с бизнес-драйверами компании. Представляя собой факторы повышения ценности компании, бизнес-драйверы позволяют определить, каким образом стратегические преимущества от реализации ИТ-проектов влияют на показатели предприятия. Дерево бизнес-драйверов базируется на модели Val IT, отображая иерархию нескольких финансовых факторов повышения добавочной экономической стоимости, и дополняется несколькими индивидуальными для индустрий и компаний нефинансовыми факторами (такими, как внутренняя оптимизация, способность к инновациям). Таким путем обеспечивается основа для определения стратегической целесообразности инвестирования в проект.

Подобный метод формулирования потенциальных выгод от информационных технологий (ИТ) в терминах бизнеса становится одним из критериев принятия решений об инвестициях и дополняет идею концепции Value-Based Management.

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

Непосредственно программные средства для оценки проекта и управления бюджетом предлагает компания «Прогноз».

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

«Прогноз» утверждает, что с помощью инструментов, реализованных в программном продукте «ПРОГНОЗ. Аналитика для компании», можно значительно повысить эффективность и оперативность подготовки бюджетов как на уровне центрального аппарата, так и на уровне подотчетных структур компании [21]. Недостаток такой системы заключается в высокой стоимости и излишней универсальности, к тому же, система ориентирована на управление компанией в целом, а не на оценку именно ИТ-проектов.

Ещё одно решение для управления проектами и их стоимостью предлагает компания Microsoft. Продукт «Microsoft Project» позволяет легко планировать проекты и сотрудничать с другими пользователями. Но этот продукт не обладает хорошими аналитическими инструментами. «Microsoft Project» больше подходит для планирования сроков выполнения задач по проектам и оценки загруженности сотрудников.

Стоит сказать про ещё один продукт на рынке программного обеспечения - «Budget Simple». Это ПО позволяет отслеживать расходы и доходы. Обладает аналитическим инструментом, который может анализировать расходы и сделать выводы о том, на чём и на сколько можно сократить расходы. Но, как и два предыдущих инструмента, «Budget Simple «не обладает аналитическим аппаратом, необходимым именно для анализа и оценки стоимости именно ИТ-проектов [27].

2.1 Общие методы оценки

Майкл Ньюэл, вице-президент компании PSM Consulting, член Института управления проектами, в своей книге «Preparing For The Project Management Professional (PMP) Certification Exam», посвящённой вопросу оценки стоимости программных продуктов, описал такую категорию методов оценки, как общие [31].

Общие методы оценки:

Метод оценки «сверху вниз».

Метод оценки «снизу вверх».

Метод оценки «по аналогу».

Методы параметрических оценок.

Метод оценки стоимости «сверху вниз» (англ. top down estimate) лучше использовать для оценки стоимости на ранних стадиях проекта, когда требования к проекту ещё нечёткие. Смысл такой оценки в том, что она производится без детализации, обобщённо и проект оценивается в общем по нескольким или вообще одному показателю. Этот метод хорошо тем, что не требует сложных вычислений, больших усилий и времени. К числу недостатков можно отнести тот факт, что точность при такой оценки не самая высокая.

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

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

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

Допустим, появилась необходимость разработать новый программный продукт, и его модули во многом похожи с модулями другого, уже разработанного продукта, но должны содержать более расширенный функционал. В общих чертах предыдущий и предстоящий проекты очень похожи. Если число задач в новом проекте приблизительно на 30 % больше, чем в предыдущем, то метод оценки «по аналогу» допускает предположение, что и затраты на новый проект будут на 30 % выше, чем затраты на разработку предыдущего. Стоимость ресурсов в данном подходе неизменна.

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

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

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

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

2.2 Метод Delphi

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

План действий

Сформировать рабочую группу для сбора и обобщения мнений экспертов.

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

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

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

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

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

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

Достоинства:

Способствует независимости мышления членов группы.

Обеспечивает спокойное и объективное изучение проблем.

Недостатки:

Чрезмерная субъективность оценок.

Требует достаточно много времени и организационных усилий.

2.3 COCOMO

COCOMO (Constructive Cost Model) - Модель сотрудника компании TRW Р.У. Волвертона, позже ставшего вместе с группой других исследователей создателем одной из наиболее широко используемых моделей оценки стоимости - COCOMO, появилась в 1974 году. Это была одна из наиболее ранних попыток формально измерить продуктивность работы программиста с использованием количества строк кода.

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

COCOMO II (Constructive Cost Model II) - одна из самых популярных алгоритмических моделей оценки трудоемкости программного обеспечения, ставшая стандартом. Параметры модели варьируются в зависимости от сложности разрабатываемого программного обеспечения, а также режимов использования модели [16].

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

Объектные точки.

Функциональные точки.

Количество строк кода.

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

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

В модели COCOMO II в качестве единицы строки решено было использовать логические строки (т.е. строки кода, которые содержат определённую операцию или выражение, это позволяет учесть особенности языка, в отличие от физических). Для устранения потенциальных проблем с оценкой количества строк кода, Институт программной инженерии (Software Engineering Institute - SEI) предложил специальный чек- лист, по результатам которого оценивается объём программного кода. Для использования в модели COCOMO II лист был модифицирован. Лист состоит из нескольких разделов, содержащих подробное описание свойства кода, особенности синтаксиса языка. Таким образом, посчитать логические строки становится гораздо проще.

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

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

Число и формы ввода данных и вывода.

Число запросов пользователей.

Число внутренних и внешних файлов.

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

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

Недостатки:

Не учитываются особенности разработчиков, опыт, степень квалификации.

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

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

Модель COCOMO II состоит из трёх различных моделей. Выбор модели для составления оценки стоимости программного обеспечения зависит от типа проекта и степени детализации требований к продукту.

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

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

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

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

COCOMO II может использоваться для принятия решений в следующих ситуаций:

Принятие инвестиционных или иных финансовых решений, связанных с разработкой программного обеспечения.

Составление проектных бюджетов и графиков в качестве основы для планирования и контроля.

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

Оценка программного обеспечения и управление рисками.

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

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

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

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

Достоинства:

Надежная отлаженная модель, хорошо известная и изученная.

Обладает достаточной точностью.

Поддерживает современный процесс разработки программного обеспечения.

Недостатки:

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

2.4 SLIM

SLIM (Software Life-cycle Model) - математическое моделирование на основе менеджмента жизненного цикла разработки программного обеспечении. Нелинейная модель расчета трудоемкости программного средства была разработана Лоуренсом Патнамом в 1978 г. на основе эмпирических данных программных разработок Министерства обороны США [7]. Согласно представленной модели, трудоемкость прямо пропорциональна размеру проекта (в LOC-оценке или FPA-оценке) и обратно пропорциональна уровню применяемых технологий, производительности персонала и прочих факторов технологической среды реализации проекта. Расчет затрат на оплату труда базируется на учете трудоемкости разработки программного продукта и тарифной ставке привлекаемых к проекту разработчиков.

Достоинства:

SLIM-модель проста и имеет небольшое число параметров.

Функции анализа рисков.

Анализ чувствительности модели.

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

Недостатки:

Модель практически бесполезна до стадии планирования и кодирования.

Модель сильно зависит от технологического параметра.

Модель нечувствительна и не применима для небольших проектов.

Нет статистических доказательств, что индекс продуктивности, используемый в модели, должен быть именно таким.

База данных проекта не опубликована.

2.5 SEER-SEM

SEER-SEM Параметрическая оценка усилий, времени, затрат и риска. Основывается на оценке минимального времени вовлечения персонала в соответствии с законом Брука. SEER состоит из нескольких взаимосвязанных продуктов. SEER-SEM предназначается для оценки, планирования и управления; SEER-SSM - для углубленной оценки размеров программных проектов, a SEER-AccuScope - для простой оценки размеров.

Достоинства:

Возможность ее использования в режиме реального времени.

Возможность ее подключения к различным системам.

Гибкость по отношению к различным доменам.

Поддержка планирования.

Множество отчетов.

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

Анализ рисков.

Недостатки:

Недоступны алгоритмы модели для возможности создания на ее основе программных продуктов сторонних производителей, так как SEER-SEM изначально создавалась для коммерческого использования; отсюда возникает неясность, поддерживаются определенные типы входных данных или нет

Нет опубликованных независимых исследований об использовании этой модели

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

Таким образом, модель SEER-SEM, обладая огромным потенциалом, является частью программного продукта - «черного ящика», и поскольку алгоритмы вычислений не раскрыты, модель невозможно использовать в независимых программных продуктах

2.6 Экстремальное программирование

Экстремальное программирование одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень.

Экстремальное программирование включает «игру в планирование», которую можно рассматривать, как метод оценки затрат.

Основная цель игры в планирование - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.

...