ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 13467
Скачиваний: 411
![]()
(9.4)
где Р — размер программы, чаще всего измеряется в строках кода, хотя можно использовать и другие единицы измерения (функциональные точки, например);
С — технологическая константа, учитывающая как уровень существующих технологий, так и производительность персонала (команды разработчиков);
td — ограничение на срок поставки, измеряется в годах.
сосомо
Модель СОСОМО (Constructive COst MOdel), предложенная в 1981 г. известным ученым Барри Боэмом [59], является на сегодняшний день самой популярной методикой для оценки стоимости разработки ПО. Для создания СОСОМО были проанализированы статистические данные 63 проектов различных типов. Данная модель имеет три уровня детализации: базовый, промежуточный и подробный и предусматривает три режима использования в зависимости от размеров проекта и реализующей его команды (табл. 9.4).
Трудоемкость проекта на базовом уровне СОСОМО определяется с помощью следующей формулы:
Т = а х Р х Ъ,
(9-5)
где а и Ъ — константы, которые определяются режимом использования модели.
Из формулы (9.5) видно, что трудозатраты зависят от размера проекта и при смене режима модели скачкообразно изменяются (табл. 9.5).
Длительность выполнения проекта по модели СОСОМО вычисляется по формуле
Г= 2,5 х Т х к. (9.6)
Из формулы (9.6) видно, что рост трудоемкости проекта не приведет к значительному увеличению его длительности, поскольку при этом изменяется значение константы к, зависящей от режима модели.
Таблица 9.5. Значения коэффициентов в зависимости от режимов модели
|
Режим |
Коэффициент а |
Коэффициент b |
Коэффициент к |
|
Органичный |
2,4 |
1,05 |
0,38 |
|
Сблокированный |
3,0 |
1,12 |
0,35 |
|
Внедренный |
3,6 |
1,20 |
0,32 |
KLOC (KiloLines Of Code) — тысяч строк кода.
Промежуточный и подробный уровни модели СОСОМО добавляют в формулы (9.5) и (9.6) дополнительные коэффициенты, которые позволяют повысить точность оценок. Кроме того, в модели возможна корректировка оценок на основе хронологических данных из уже выполненных проектов.
СОСОМО II
Модель СОСОМО II пришла на смену устаревшей оригинальной модели в 1997 г. Выполненная на основе СОСОМО, она адаптирована к современным технологиям разработки ПО. Так, если в СОСОМО использовалась каскадная модель жизненного цикла, то СОСОМО II предназначена для спиральной и итеративной моделей. Размер программного продукта в СОСОМО II может измеряться как строками кода, так и функциональными и объектными точками.
СОСОМО II имеет три варианта использования — фактически это три разные модели для решения различных задач, объединенные под одним общим названием (табл. 9.6).
Таблица 9.6. Варианты использования модели СОСОМО II
|
Название модели |
Описание |
|
Композиционная прикладная |
Ориентирована на проекты, создаваемые с применением современных инструментальных средств и иМЬ, использует в качестве метрики объектные точки |
|
Ранней разработки проекта |
Применяется для получения приближенных оценок по проекту до определения его архитектуры, использует в качестве метрик количество строк кода или функциональные точки |
|
Постархитектурная модель |
Наиболее детализированная модель, используется после разработки архитектуры проекта и позволяет получить самые точные оценки, применяет в качестве метрик количество строк кода или функциональные точки |
Таким образом, при сохранении основных принципов СОСОМО модель стала намного гибче и при оценке трудоемкости и стоимости ПО учитывает намного больше различных факторов, влияющих на выполнение проекта.
9.2. Методы оценки эффективности ПО на этапе эксплуатации
Современная финансовая теория выделяет следующие показатели экономической эффективности внедрения программных проектов:
-
внутренняя норма дохода (IRR — Internal Rate of Return);
-
чистая приведенная (текущая) стоимость (NPV — Net Present Value);
-
срок окупаемости (РВ — Payback Period);
-
совокупная стоимость владения (ТСО — Total Cost of Ownership);
• норма возврата инвестиций (ROI — Return of Investment). Наиболее часто для оценки эффективности информационных систем используют два последних показателя — ТСО и ROI.
Под ТСО понимается сумма всех затрат на внедрение и обеспечение функционирования ИС вплоть до момента ее вывода из эксплуатации. Существует две основные модели расчета совокупной стоимости владения: концепция, предложенная Gartner Group, и результат совместных усилий Microsoft и Interpose. По методике, предложенной Gartner, все затраты делятся на фиксированные и текущие.
Фиксированные затраты производятся один раз на этапе внедрения системы. К ним относят: стоимость разработки и внедрения проекта, первоначальные закупки необходимого для внедрения ИС аппаратного и программного обеспечения, привлечение внешних консультантов.
Текущие затраты — расходы, обеспечивающие функционирование системы. Это те затраты, которые требуются постоянно, пока система работает. К ним относятся:
• обновление и модернизация системы;
-
управление системой в целом — администрирование, обучение администрации и конечных пользователей, заработная плата персонала, привлечение внешних ресурсов;
-
«активность пользователя» — доработка ПО, дополнительные настройки ПО, работа с данными, последствия некомпетентных действий пользователя.
Казалось бы, все просто — нужно только подсчитать затраты по каждой из вышеперечисленных статей. Но на самом деле не
все расходы легко подсчитать — значительная их часть не только не закладывается заранее, но и нигде не учитывается. Причем 75 % затрат, входящих в состав ТСО, обусловлены проблемами конечных пользователей. В модели ТСО, разработанной Microsoft и Interpose, учитываются как раз эти затраты. Согласно их методике затраты делятся на прямые и косвенные.
Прямые затраты — те, которые предусматриваются бюджетом и планируются. К ним относятся расходы на аппаратное и программное обеспечение, управление (администрирование и проектирование), поддержку, разработку.
Косвенные затраты — составляют более 50 % средних расходов, которые не поддаются планированию и часто вообще не регистрируются. К ним относятся, прежде всего, пользовательские затраты (неформальное обучение, персональная поддержка, ошибки и просчеты) и простои из-за выхода оборудования из строя или плановых профилактических остановок.
Таким образом, совокупную стоимость владения можно подсчитать по простой формуле
ТСО = Пр + Кс, (9.7)
где Пр — прямые затраты; Кс — косвенные затраты.
ROI =
![]()
Эффективность вложений (возврат инвестиций) ROI — это показатель, характеризующий выгоду программного проекта. Он рассчитывается как отношение дисконтированных поступлений, ожидаемых от внедрения данного программного продукта, к начальной стоимости инвестиций:
(9.8)
где Эф — эффект от внедрения, выраженный в денежных единицах;
И — инвестиции в ИС.
Модель ROI принадлежит Gartner Group.
Для оценки доходной части, как правило, анализируют цели бизнеса, которые нужно достичь путем внедрения программного проекта или появления каких-либо новых программных продуктов. Берут измеримые показатели бизнеса (например, сокраше
ние операционных расходов, поддержку конкурентоспособного состояния, улучшение внутреннего контроля) и по ним делают оценки эффекта. В качестве расходной части чаще всего используют показатель ТСО.
Контрольные вопросы
-
Перечислите методы оценки стоимости ПО.
-
Опишите линейный метод.
-
Опишите метод функциональных точек.
-
Какие существуют модификации метода функциональных точек?
-
Приведите методы оценки стоимости ПО с использованием эмпирических данных.
-
Охарактеризуйте СОСОМО и СОСОМО II.
-
Как производится оценка эффективности ПО на этапе эксплуатации?
-
Что такое показатели ТСО и ROI?
Лабораторный практикум
ЛАБОРАТОРНАЯ РАБОТА № 1. Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия ссТехническое задание»
Цель работы: ознакомиться с правилами написания технического задания.
Лабораторная работа рассчитана на 4 академических часа.
Подготовка к лабораторной работе
-
Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Постановка задачи» учебной дисциплины «Технология разработки программного обеспечения».
-
Изучить соответствующие разделы в изданиях [1, 4].
-
Ознакомиться с разделами гл. 2 данного пособия.
Теоретическая часть. Разработка технического задания
Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и
регламентирован процесс приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных исследований, научного прогнозирования и т. п.
Порядок разработки технического задания
Разработка технического задания выполняется в следующей последовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы представления.
Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения.
1. Общие положения
-
Техническое задание оформляют в соответствии с ГОСТ 19.106—78 на листах формата А4 и АЗ по ГОСТ 2.301—68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.
-
Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104—78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
-
Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:
-
введение;
-
наименование и область применения;
-
основание для разработки;
-
назначение разработки;
-
технические требования к программе или программному изделию;
-
технико-экономические показатели;
-
стадии и этапы разработки;
-
порядок контроля и приемки;
-
приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. При необходимости допускается в техническое задание включать приложения.
2. Содержание разделов
-
Введение должно включать краткую характеристику области применения программы или программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения — продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.
-
В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.
-
В разделе «Основание для разработки» должны быть указаны: