WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 27 | 28 || 30 | 31 |   ...   | 33 |

Составная часть капитала Стоимость X % полного Итого компании (%/год) капитала Чистая прибыль 10% X 10% 1,00% Обыкновенные акции 12% X 10% 1,20% Привелигированные акции 9% X 15% 1,35% Долговые обязательства 10% X 65% 6,50% Итого 10,05% Таким образом, в примере WACC равна 10,05 %/год.

Приведем теперь пример расчета NPV для проекта, график движения денежных средств по календарным периодам которого показан в таблице 3 (+ означает поступление средств, - означает платеж). Предположим, что стоимость капитала равна 10% за календарный период (все периоды предполагаются одинаковой длительности).

Таблица 3.

Пример: данные для расчета NPV.

Номер Платежи, $ периода 0 -7,1 +2,2 +2,3 +2,4 +2,5 +2,Расчет NPV для этого примера показан в таблице 4.

Таблица 4.

Пример: расчет NPV.

Дисконтированные Накопленный Номер Платежи, $ платежи, $ дисконтированный периода платеж, $ 0 -18000 -18000 -1 8000 7272,73 -10727,2 6000 4958,68 -5768,3 4000 3005,26 -2763,4 4000 2732,05 -31,5 3000 1862,76 1831,ИТОГО NPV 1831,Расчет NPV дает ответ на еще один важный для финансового менеджера вопрос: когда проект начинает окупаться, иными словами, позволяет определить точку безубыточности (breakeven point) проекта. Из таблицы 4 видно, что с учетом стоимости капитала проект выходить на окупаемость не раньше окончания четвертого календарного периода, т.е. через пять календарных периодов после начала.

10.3. Оценки стоимостей и планирование затрат 10.3.1. Грубая предварительная оценка стоимости проекта Грубая предварительная оценка стоимости проекта должна быть произведена менеджером на самом начальном этапе, когда по сути дела еще точно не известно, какое в точности программное обеспечение должно разрабатываться (есть только разве что самая общая идея, полученная из предварительных контактов с заказчиком). В процессе переговоров с заказчиком и детализации требований эта оценка уточняется и в уже уточненном виде является основой определения договорной цены. Адекватная оценка стоимости проекта важна как для заказчика, так и для исполнителя проекта.

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

Вероятно, одной из наиболее известных моделей данного рода является конструктивная модель стоимости (Constructive Cost Model – COCOMO), разработанная в конце 70х годов Барри Боэмом (Barry Boehm). Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает в виде простой эвристической формулы соответствие между размером системы в тысячах условных строк кода (KSLOC – Kilo Source Lines of Code) и трудоемкостью (в человеко-часах), а значит, при наличии оценки усредненной по компании стоимости человеко-часа, и стоимостью разработки.

Базовый тип модели COCOMO рассчитан только на относительно маленькие проекты, разрабатываемые командами, хорошо знакомыми с прикладной областью. Более развитые модели, основанные на COCOMO, вводят в расчет до 15 поправочных факторов, принадлежащих к одной из четырех категорий:

атрибуты продукта, такие, как его сложность и требования к его надежности;

атрибуты системы, такие, как ограничения на оперативную память и время выполнения;

атрибуты команды исполнителей, такие, как опыт в прикладной области;

атрибуты проекта, такие, как используемые средства разработки.

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

Рассмотрим в качестве примера расчет трудоемкости, стоимости и длительности разработки с использованием модели COCOMO (это самая простая и, наверное, самая употребительная модель, основанная на тысячах условных строк кода, причем именно своей простотой она выгодно отличается от других моделей). Заложенные в модель формулы элементарны:

Объем работы (трудоемкость в человеко-месяцах) = 3.0*EAF*(KSLOC)1.12, Длительность = 2.5*(Работа)0.Предполагается, что рассчитанные величины не включают затраты на планирование и определение требований. Здесь EAF – поправочный коэффициент, равный произведению 15 поправочных факторов, оценивающих упомянутые выше атрибуты. Для конкретности рассмотрим пример оценки трудоемкости и длительности разработки программного комплекса объемом примерно 170.000 строк кода (при этом, естественно, не считаются комментарии, директивы компилятору и отладочные инструкции, поэтому этот параметр также принято называть KDSI — Kilo Delivered Source Instructions). Пример мы взяли с сайта http://www.saitistica.ru – это пример реально существующей платформы управления интернет-системами (корпоративным webконтентом).

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

Таблица 5.

Пример: расчет EAF Фактор Значение Влияние Знание языка Номинальное 1.программирования Ограничение времени Номинальное 1.выполнения Размер базы данных Номинальный 1.Межремонтный срок Номинальный 1.службы компьютера Знание виртуальной Номинальное 1.машины Изменчивость Номинальная 1.виртуальной машины Использование Высокое 0.программных инструментов Использование Номинальное 1.современных методов Ограничение объема Низкое 1.памяти Знание приложений Высокое 0.Ограничение по срокам Номинальное 1.разработки Требуемая надежность Номинальная 1.Сложность продукта Номинальная 1.Способности Номинальные 1.персонала/команды Способности Номинальные 1.аналитика ИТОГО EAF 1.013*0.9*0.95 = 0.Расчет трудоемкости и длительности разработки дает Трудоемкость = 3.0*0,855*(170)1.= 2.8*0.855*= 808 человеко-месяца, Длительность = 2.5*(808)0.35 = 2.5*9.5 = 26 месяцев, без учета планирования и определения требований Заметим, что фигурирующие в формулах фиксированные мультипликативные константы и показатели степени могут меняться в зависимости от сложности системы. Стандартная модель COCOMO предусматривает три уровня сложности систем – простые, промежуточные и сложные (каждому уровню соответствует свой набор констант). В данном примере мы считаль сложность системы промежуточной.

В современных развитых вариантах модели COCOMO заложены и распределение трудоемкости и длительности по стадиям жизненного цикла в зависимости от выбранной модели жизненного цикла. Так, для классической водопадной модели имеем Вид деятельности Трудоемкость (%) Длительность (%) Планирование и (+8) (+36) определение требований Проектирование 18 продукта Детальное 25 проектирование Кодирование и 26 тестирование отдельных модулей Интеграция и 31 тестирование ИТОГО: 108% 136% Это дает итоговые цифры для приведенного примера:

Трудоемкость 872 человеко-месяца Длительность 35 месяцев.

В модели COCOMO можно получить и распределение работ по видам деятельности WBS. Для «стандартной» (в смысле COCOMO) структуры WBS в данном примере имеем^ Этап проекта Бюджет (%) Трудоемкость (человеко-месяцы) Анализ требований 4 Проектирование 12 продукта Программирование 44 Планирование 6 тестирования Верификация и 14 аттестация Канцелярия проекта 7 Управление 7 конфигурацией и обеспечение качества Создание руководств 6 ИТОГО 100% Наконец, можно получить и прогноз на требуемое количество работников на протяжении всего цикла создания продукта.

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

Программа Количество строк Примечания Communiware 80 тыс.

Navision Axapta 400 тыс.

Галактика 1.5 млн.

SAP R/3 10 млн.

SUN StarOffice 6 9 млн.

Система управления 236 тыс. Стоила $85 млн.

огнем для истребителя Усилия по F-16 сопровождению программ комплекса, их улучшению и устранению ошибок потребовали дополнительно $млн.

Компьютерная сеть 10 млн. Стоимость – $300 млн.

Олимпийских игр в Солт Лейк Сити Электронная система 11 млн. Только на поддержку в торгов NASDAQ 2000 году потрачено $55 млн.

Solaris 7 12 млн.

Windows NT 4.0 16 млн.

Компьютерная системе 25 млн.

Агентства национальной безопасности США Программное 40 млн.

обеспечение проекта НАСА "Space Shuttle" Windows 2000 40 млн.

Debian Linux 55 млн. Самый полный вариант, более 10 CD Существенным недостатком описанных моделей является то, что они основаны на тысячах условных строк кода, как метрике размера программного комплекса. Эта метрика была популярна в 60-70х годах прошлого века, но в настоящее время не считается адекватной мерой объема проекта.

Видимо, одной из первых попыток отойти от данной метрики, была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем.

Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), было опубликовано несколько ревизий метода.

Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании. Другими аналогичными методами, являются Feature Points, разработанный Кэйперсом Джонсом (Capers Jones) и 3D Points, разработанный в компании Boeing.

Со временем модель СОСОМО оказалась устаревшей в значительной своей части. Поэтому на ее основе была разработана модель СОСОМО II, опубликованная в 1999 году. Она усовершенствует оригинальную модель в следующих основных направлениях:

использование входных данных, доступных на ранних этапах жизненного цикла системы для оценки ее сложности (в частности, использование функциональных точек);

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

объектно-ориентированные подходы, поддерживаемые распределенным ПО промежуточного слоя;

влияние зрелости процессов разработки.

новые – циклические и обобщенные – модели процессов разработки;

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

10.3.2. Планирование затрат и составление смет Планирование затрат (Budgeting) – определение потребности в финансировании по этапам жизненного цикла проекта.

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

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

Бюджет проекта (Project Budget) – сметная стоимость, распределенная по периодам выполнения проекта.

Анализ распределения затрат во времени (графиков расходования средств) нужен для того, чтобы правильно планировать поступление денежных средств от заказчика (или со стороны). Здесь важен принцип:

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

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

Как правило, менеджер проекта:

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

10.5. «Карта памяти» по теме 10.6. Список использованной и рекомендованной литературы 1. Баранов С. Н. Управление программным проектом. Лекции по спецкурсу "Технология программирования". - СПб: СанктПетербургский государственный электротехнический университет, рукопись, 1998.

2. Boehm B. W. Software Engineering Economics. Prentice Hall, 1981.

Тема 11. Управление рисками проекта 11.1. Введение Рисками называют негативные события вероятностного характера, отрицательно влияющие на исход проекта. Для успешной реализации проектов одной из основ управления проектом должно быть управление рисками. Оно представлено как одно из девяти основных областей знаний в области управления проектами, описанных PMI (Американским институтом управления проектами).

Изучив учебный материал данной темы, Вы:

• узнаете или пополните свои знания о том, что такое риск, и о характеристиках риска;

• узнаете или пополните свои знания о об основных источниках риска в проектах по разработке программного обеспечения;

• получите общее представление о порядке управления рисками проекта по разработке программного обеспечения.

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

• риски при разработке программного обеспечения;

• порядок управления рисками программных проектов.

Pages:     | 1 |   ...   | 27 | 28 || 30 | 31 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.