Файл: Технол_разраб_прогр_обесп_Гагарина_Кокарева.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 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.

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


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

Контрольные вопросы

  1. Перечислите методы оценки стоимости ПО.

  2. Опишите линейный метод.

  3. Опишите метод функциональных точек.

  4. Какие существуют модификации метода функциональных точек?

  5. Приведите методы оценки стоимости ПО с использованием эмпирических данных.

  6. Охарактеризуйте СОСОМО и СОСОМО II.

  7. Как производится оценка эффективности ПО на этапе эксплуатации?

  8. Что такое показатели ТСО и ROI?


Лабораторный практикум

ЛАБОРАТОРНАЯ РАБОТА 1. Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия ссТехническое задание»

Цель работы: ознакомиться с правилами написания технического задания.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе

  1. Ознакомиться с лекционным материалом по теме «Этапы разработки программного обеспечения. Постановка задачи» учебной дисциплины «Технология разработки программного обеспечения».

  2. Изучить соответствующие разделы в изданиях [1, 4].

  3. Ознакомиться с разделами гл. 2 данного пособия.

Теоретическая часть. Разработка технического задания

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


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

Порядок разработки технического задания

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

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

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

1. Общие положения

  1. Техническое задание оформляют в соответствии с ГОСТ 19.106—78 на листах формата А4 и АЗ по ГОСТ 2.301—68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

  2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104—78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

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

1.4. Техническое задание должно содержать следующие разделы:

  • введение;

  • наименование и область применения;

  • основание для разработки;

  • назначение разработки;

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

  • технико-экономические показатели;

  • стадии и этапы разработки;

  • порядок контроля и приемки;

  • приложения.

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

2. Содержание разделов

  1. Введение должно включать краткую характеристику области применения программы или программного продукта, а также объекта (например, системы), в котором предполагается их использовать. Основное назначение введения — продемонстрировать актуальность данной разработки и показать, какое место эта разработка занимает в ряду подобных.

  2. В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

  3. В разделе «Основание для разработки» должны быть указаны: