Тема 3.9. Поставка программных средств на производство
Оценка стоимости разработки программного обеспечения
Одним из способов получения достоверного результата является применение разных методов на этапе анализа требований или проектирования, а затем усреднение результатов, полученных этими методами.
Линейный метод
Стоимость разработки определяется следующим образом:
С = Т х Ц,
где С — стоимость; Т — трудозатраты (например, в человеко-часах или человеко-месяцах); Ц — их удельная стоимость, которую определяют, в основном исходя из заработной платы и связанных с ней начислений.
Трудозатраты вычисляют по следующей формуле:
Т = Р х П.
Здесь Р — размер кода программы, чаше всего измеряется в строках (LOC — Lines Of Code); П — временная производительность.
Недостаток такого подхода кроется в способе, которым измеряется результат. Получается, что у программиста отсутствует стимул для повышения своего мастерства и написания лаконичного кода, более простого в отладке и соответственно более дешевого.
Метод функциональных точек
Этот метод используется для измерения производительности взамен устаревшего линейного подхода, где производительность измерялась количеством строк программного кода.
Впервые функциональные точки (function points) были предложены сотрудником IBM Аланом Альбрехтом в 1979 г.
Преимуществом данного метода является то, что поскольку применение функциональных точек основано на изучении требований, то оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом.
Для поддержки и развития данного метода в 1986 г. была создана Международная группа пользователей функционального измерения (IFPUG — International Function Point User Group).
Метод заключается в следующем.
- Сначала выделяются функции разрабатываемого программного обеспечения, причем на уровне пользователей, а не программного кода.
Например, рассмотрим программный комплекс, реализующий различные методы сортировки одномерных массивов. Одной из функций пользователя данного комплекса будет выбор метода, ее мы и будем описывать в качестве примера.
- Следующим шагом метода будет подсчет количества факторов, приведенных ниже:
• внешние входы.
Различаются только те входы, которые по-разному влияют на функцию. Функция выбор метода имеет один внешний вход;
• внешние выходы.
Различными считаются выходы для различных алгоритмов. Представим, что наша функция выдает сообщение — текстовое описание выбранного метода, и вызывает другую функцию, непосредственно реализующую выбранный алгоритм сортировки, следовательно, она имеет два выхода;
• внешние запросы. В нашем примере таковых нет;
• внутренние логические файлы — группа данных, которая создается или поддерживается функцией, считается за единицу.
В качестве внутреннего логического файла для нашей функции примем текстовый файл, содержащий описания алгоритмов;
• внешние логические файлы — пользовательские данные, находящиеся во внешних по отношению к данной функции файлах. Каждая группа данных принимается за единицу.
Внешним по отношению к нашей функции является файл с результатом обработки.
- Далее полученные значения умножаются на коэффициенты сложности для каждого фактора (по данным IFPUG) и суммируются для получения полного размера программного продукта.
Значения этих коэффициентов приведены в табл.
Таблица. Значения коэффициентов сложности
Для рассматриваемого нами примера возьмем значения, приведенные в следующей табл.
Размер нашей функции составит:
ФР =1x3+1x4+1x5+1x7+1x7 = 26.
Это число является предварительной оценкой и нуждается в уточнении.
Таблица. Пример коэффициентов сложности
Следующим шагом в определении размера программного кода методом функциональных точек является присвоение веса (от 0 до 5) каждой характеристике проекта. Перечислим эти характеристики:
1. Требуется ли резервное копирование данных?
2. Требуется обмен данными?
3. Используются распределенные вычисления?
4. Важна ли производительность?
5. Программа выполняется на сильно загруженном оборудовании?
6. Требуется ли оперативный ввод данных?
7. Используется много форм для ввода данных?
8. Поля базы данных обновляются оперативно?
9. Ввод, вывод, запросы являются сложными?
10. Внутренние вычисления сложны?
11. Код предназначен для повторного использования?
12. Требуется преобразование данных и установка программы?
13. Требуется много установок в различных организациях?
14. Требуется поддерживать возможность настройки и простоту использования?
Значения для данных характеристик определяются следующим образом:
0 — никогда; 1 — иногда; 2 — редко; 3 — средне; 4 — часто; 5 — всегда.
Эти характеристики для примера функции сведены в табл.
Таблица. Пример характеристик проектов
Определяется S — сумма всех весов.
И, наконец, уточненный функциональный размер вычисляется по формуле
УФР = ФР х (0,65 + 0,01 х S).
Уточненный функциональный размер функции выбор метода будет следующим:
УФР = 26х (0,65 + 0,01 х 29) =17,19.
Получившийся результат показывает, что функция выбор метода достаточно проста и не требует больших трудозатрат.
Полученные значения затем используются для оценки стоимости проекта.
В настоящее время существует несколько модификаций метода функциональных точек.
Точки свойств
В случае, если вышеописанные характеристики не отражают истинной сложности реализации (например, при разработке операционных систем), вместо метода функциональных точек применяют его усовершенствованный вариант, предложенный в 1988 г. Кейперсом Джонсом, — метод точек свойств.
Этот метод корректирует оценки, полученные методом функциональных точек с учетом алгоритмической сложности программного продукта.
Метод Mark II
Метод Mark II был представлен Чарльзом Саймонсом также в 1988 г. Этот метод более пригоден для оценки сложных систем, чем классический метод функциональных точек. Он позволяет добиться одного и того же результата как при оценке системы в целом, так и при суммировании оценок, полученных для составляющих ее подсистем.
Трехмерные функциональные точки
В 1991 г. софтверным подразделением корпорации Boeing было предложено еще одно решение — метод трехмерных функциональных точек. Отличием от классического метода является то, что сложность программного продукта оценивается по трем направлениям — данные, функции и управление.
Достоинством метода является его применимость не только к оценке программных проектов, но и к оценке трудоемкости задач в других сферах деятельности.
Объектные точки
Метод объектных точек адаптирует оригинальный метод функциональных точек к объектно-ориентированной технологии программирования.
Оценка с использованием эмпирических данных
Метод Демарко
Метод, разработанный Томом Демарко в 1982 г., основан на использовании так называемой «бэнг-метрики».
Этот простой, но эффективный подход к оценке стоимости ПО, близок по содержанию к методу функциональных точек с тем отличием, что полученные оценки корректируются с учетом хронологических данных по выполненным ранее проектам.
Такой подход позволяет получить не абстрактные показатели, а приближенные значения реальных затрат ресурсов и времени.
SLIM
В 1978 г. Лоуренс Патнам предложил нелинейную модель, использующую эмпирические данные при оценке стоимости ПО — SLIM (Software Life-cycle Model).
Данная методика, созданная на основе реальных данных, собранных в Министерстве обороны США, предназначена для определения трудоемкости крупных программных проектов.
Несмотря на то что широкого распространения эта модель не приобрела, некоторые фирмы до сих пор используют ее для расчета трудозатрат.
Согласно модели SLIM трудозатраты на разработку ПО вычисляются по следующей формуле:
Т = (Р/С)* td-4,
где Р — размер программы, чаще всего измеряется в строках кода, хотя можно использовать и другие единицы измерения (функциональные точки, например);
С — технологическая константа, учитывающая как уровень существующих технологий, так и производительность персонала (команды разработчиков);
td — ограничение на срок поставки, измеряется в годах.
COCOMO
Модель СОСОМО (Constructive COst MOdel), предложенная в 1981 г. известным ученым Барри Боэмом, является на сегодняшний день самой популярной методикой для оценки стоимости разработки ПО.
Для создания СОСОМО были проанализированы статистические данные 63 проектов различных типов.
Данная модель имеет три уровня детализации: базовый, промежуточный и подробный и предусматривает три режима использования в зависимости от размеров проекта и реализующей его команды (табл.)
Трудоемкость проекта на базовом уровне СОСОМО определяется с помощью следующей формулы:
Т = а х Р х b,
где а и b — константы, которые определяются режимом использования модели.
Таблица. Режимы использования СОСОМО
Длительность выполнения проекта по модели СОСОМО вычисляется по формуле
F= 2,5 х Т х k
Из формулы видно, что рост трудоемкости проекта не приведет к значительному увеличению его длительности, поскольку при этом изменяется значение константы k, зависящей от режима модели.
Таблица. Значения коэффициентов в зависимости от режимов модели
Промежуточный и подробный уровни модели СОСОМО добавляют в формулы Т = а х Р х b,и F= 2,5 х Т х k дополнительные коэффициенты, которые позволяют повысить точность оценок.
Кроме того, в модели возможна корректировка оценок на основе хронологических данных из уже выполненных проектов.
COCOMO II
Модель СОСОМО II пришла на смену устаревшей оригинальной модели в 1997 г. Выполненная на основе СОСОМО, она адаптирована к современным технологиям разработки ПО.
Так, если в СОСОМО использовалась каскадная модель жизненного цикла, то СОСОМО II предназначена для спиральной и итеративной моделей.
Размер программного продукта в СОСОМО II может измеряться как строками кода, так и
функциональными и объектными точками.
СОСОМО II имеет три варианта использования — фактически это три разные модели для решения различных задач, объединенные под одним общим названием (табл. 9.6).
Таблица 9.6. Варианты использования модели СОСОМО II
Таблица 9.6. Варианты использования модели СОСОМО II
Таким образом, при сохранении основных принципов СОСОМО модель стала намного гибче и при оценке трудоемкости и стоимости ПО учитывает намного больше различных
факторов, влияющих на выполнение проекта.
Методы оценки эффективности ПО на этапе эксплуатации
Современная финансовая теория выделяет следующие показатели экономической эффективности внедрения программных проектов:
• внутренняя норма дохода (IRR — Internal Rate of Return);
• чистая приведенная (текущая) стоимость (NPV — Net Present Value);
• срок окупаемости (РВ — Payback Period);
• совокупная стоимость владения (ТСО — Total Cost of Ownership);
• норма возврата инвестиций (ROI — Return of Investment).
Наиболее часто для оценки эффективности информационных систем используют два последних показателя — ТСО и ROI.
Под ТСО понимается сумма всех затрат на внедрение и обеспечение функционирования ИС вплоть до момента ее вывода из эксплуатации.
Существует две основные модели расчета совокупной стоимости владения:
концепция, предложенная Gartner Group,
По методике, предложенной Gartner, все затраты делятся на фиксированные и текущие.
Фиксированные затраты производятся один раз на этапе внедрения системы.
К ним относят:
стоимость разработки и внедрения проекта,
первоначальные закупки необходимого для внедрения ИС аппаратного и программного обеспечения,
привлечение внешних консультантов.
Текущие затраты — расходы, обеспечивающие функционирование системы. Это те затраты, которые требуются постоянно, пока система работает.
К ним относятся:
• обновление и модернизация системы;
• управление системой в целом — администрирование, обучение администрации и конечных пользователей, заработная плата персонала, привлечение внешних ресурсов;
• «активность пользователя» — доработка ПО, дополнительные настройки ПО, работа с данными, последствия некомпетентных действий пользователя.
Казалось бы, все просто — нужно только подсчитать затраты по каждой из вышеперечисленных статей. Но на самом деле не все расходы легко подсчитать — значительная их часть не только не закладывается заранее, но и нигде не учитывается.
результат совместных усилий Microsoft и Interpose.
Причем 75 % затрат, входящих в состав ТСО, обусловлены проблемами конечных пользователей. В модели ТСО, разработанной Microsoft и Interpose, учитываются как раз эти затраты.
Согласно их методике затраты делятся на прямые и косвенные.
Прямые затраты — те, которые предусматриваются бюджетом и планируются.
К ним относятся:
расходы на аппаратное и программное обеспечение,
управление (администрирование и проектирование),
поддержку, разработку.
Косвенные затраты — составляют более 50 % средних расходов, которые не поддаются планированию и часто вообще не регистрируются.
К ним относятся, прежде всего,
пользовательские затраты (неформальное обучение, персональная поддержка, ошибки и просчеты)
простои из-за выхода оборудования из строя или плановых профилактических остановок.
Таким образом, совокупную стоимость владения можно подсчитать по простой формуле
ТСО = Пр + Кс,
где Пр — прямые затраты;
Кс — косвенные затраты.
Эффективность вложений (возврат инвестиций) ROI — это показатель, характеризующий выгоду программного проекта.
Он рассчитывается как отношение дисконтированных поступлений, ожидаемых от внедрения данного программного продукта, к начальной стоимости инвестиций:
ROI = Эф/И
где Эф — эффект от внедрения, выраженный в денежных единицах;
И — инвестиции в ИС.
Модель ROI принадлежит Gartner Group.
Для оценки доходной части, как правило, анализируют цели бизнеса, которые нужно достичь путем внедрения программного проекта или появления каких-либо новых программных продуктов.
Берут измеримые показатели бизнеса (например, сокрашение операционных расходов, поддержку конкурентоспособного состояния, улучшение внутреннего контроля) и по ним делают оценки эффекта.
В качестве расходной части чаще всего используют показатель ТСО.
Лицензии и контракты - это лучшее средство установления прав собственности на программное изделие.
Они используются для указания гарантийных обязательств, а также помощи, которая будет оказана заказчику.
Например, ввод в действие, освоение и обучение, модификация, консультации по использованию.
При составлении лицензий и контрактов необходимо учесть:
Объем работы.
Цена.
Поставка (точная дата и место передачи).
Право собственности (кто является владельцем каждого компонента).
Гарантия (срок действия гарантии).
Ответственность.
Обязательства.
Лицензия.
Окончание работ.
При составлении лицензии и контракта и даже при их изменении следует получить квалифицированную консультацию юриста по вопросу о праве собственности.
Сопровождение и эксплуатация. Виды обслуживания.
Группа сопровождения выполняет обязанности, связанные с исправлением дефектов изготовленных программных изделий (корректирующее сопровождение) или незначительными изменениями (адаптивное сопровождение).
Изменения, проводимые на этапе сопровождения, бывают корректирующими и расширяющими.
Корректирующие изменения вызываются переменами, происходящими в окружающей среде.
Расширяющие изменения не являются обязательными и направлены лишь на улучшение характеристик ПО.
Сопровождение как вид деятельности заключается в обработке запросов на исправление, проверку и расширение.
На численность персонала группы сопровождения влияют характер и сроки взятых гарантийных обязательств.
Уровень 1.
Периодический выпуск новых редакций (только корректирующие изменения) и новых версий, содержащих дополнительно расширяющие изменения.
Уровень 2.
Периодический выпуск только новых редакций.
Уровень 3.
Выпуск новых версий или редакций не производится. На заявки отправляются ответы, которые могут содержать или не содержать решения поставленных проблем.
Чем больше изделий приходится сопровождать на уровне 1 или 2 гарантийного обслуживания, тем многочисленнее должна быть группа сопровождения.