Экономическая модель разработки ПО

Структура стоимости программного обеспечения. Использование строк кода LOC и функциональных точек в качестве единицы измерения размера программного продукта. Оценка затрат на разработку ПО. Описание жизненного цикла в конструктивной модели стоимости.

Рубрика Программирование, компьютеры и кибернетика
Вид контрольная работа
Язык русский
Дата добавления 13.10.2013
Размер файла 65,6 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

12

108

Программирование

44

396

Планирование тестирования

6

54

Верификация и аттестация

14

126

Канцелярия проекта

7

63

Управление конфигурацией и обеспечение качества

7

63

Создание руководств

6

54

Итого

100

900

СОСОМО II

Проект СОСОМО II [Boehm и другие, 1995; Horowitz, 1997] -- это работа, которая выполнялась в Центре по разработке программного обеспечения USC (USC - Centre for Software Engineering) с финансовой и технической поддержкой огромного количества промышленных предприятий. (В их число входили AT&T Bell Labs, Hewlett-Packard, Lockheed Martin, Motorola, Rational, Texas Instruments, US Army Research Lab и Xerox).

Проект имел триединую задачу:

1. Разработать модель для оценки стоимости и сроков создания ПО для того жизненного цикла, который будет применяться в конце 20 - начале 21 века.

2. Разработать базу данных стоимости программных проектов и осуществить инструментальную поддержку методов усовершенствования модели стоимости.

3. Создать количественную аналитическую схему для оценки технологий создания ПО и их экономического эффекта.

USC предполагал, что после 2000 г. на рынке ПО будут присутствовать:

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

2. разработчики компонентов (600 тыс.), которые создают приложения для конечных пользователей и вспомогательные средства;

3. интеграторы компонентов (700 тыс.), которые быстро строят приложения, используя готовые библиотеки GUI, системы управления объектами/базами данных, промежуточное ПО и специализированные для данной области компоненты;

4. системные интеграторы (700 тыс.), которые работают с системами большего масштаба, с системами, не имеющими аналогов, с приложениями, имеющими ограниченное число аналогов, с встроенными системами, требующими предварительной разработки, и с другими значительными разработками ПО на заказ;

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

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

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

Для поддержки такой стратегии в рамках модели СОСОМО II определяются три различные модели оценки стоимости:

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

· Модель ранней разработки архитектуры. Эта модель применяется для получения приблизительных оценок проектных затрат периода выполнения проекта перед тем как будет определена архитектура в целом. В этом случае используется небольшой набор новых драйверов затрат и новых уравнений оценки. В качестве единиц измерения используются функциональные точки либо KSLOC.

· Постархитектурная модель - наиболее детализированная модель СОСОМО II., которая используется после разработки архитектуры проекта. В состав этой модели включены новые драйверы затрат, новые правила подсчета строк кода, а также новые уравнения Усилиями компании Rational модель СОСОМО II интегрирует фазы и основные стадии с аналогичными объектами RUP, который в свою очередь, поддерживают распределение фаз и действий для оценщиков, использующих СОСОМО II..

В таблице 7.16 приведены характеристики этих трех моделей.

Табл. 7.16. Характеристики моделей оценки стоимости СОСОМО II

Модель композиции приложения

Модель ранней разработки архитектуры

Постархитектурная модель

Грубые входные данные

Ясно понимаемые особенности проекта

Детальное описание проекта

Оценки низкой точности

Оценки умеренной точности

Высокоточные оценки

Приблизительные требования

Ясно понимаемые требования

Стабилизировавшиеся основные требования

Концепция архитектуры

Ясно понимаемая архитектура

Стабильная базовая архитектура

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

· рассматривается макетирование пользовательских интерфейсов;

· обсуждается взаимодействие ПО и компьютерной системы;

· оценивается производительность;

· определяется степень зрелости технологии.

Модель композиции приложения ориентирована на применение объектных точек. Объектная точка -- средство косвенного измерения ПО, для его расчета определяется количество экранов (как элементов пользовательского интерфейса), отчетов и компонентов, требуемых для построения приложения. Как показано в табл. 7.17, каждый объектный экземпляр (экран, отчет) относят к одному из трех уровней сложности. В свою очередь, сложность является функцией от параметров клиентских и серверных таблиц данных (см. табл. 7.18 и 7.19), которые требуются для генерации экрана и отчета, а также от количества представлений и секций, входящих в экран или отчет.

Таб. 7.17. Оценка количества объектных указателей

Тип объекта

Количество

Вес

Итого

Простой

Средний

Сложный

Экран

___

х1

х2

х3

=___

Отчет

___

х2

х5

х8

=___

3GL компонент

___

х10

=___

Объектные указатели

=___

Табл. 7.18. Оценка сложности экрана

Экраны

Количество серверных (срв) и клиентских (клт) таблиц данных

Количество представлений

Всего < 4 (< 2 срв, <3клт)

Всего < 8 (2-3 срв, 3-5 клт)

Всего > 8 (>3срв, >5клт)

<3

Простой

Простой

Средний

3-7

Простой

Средний

Сложный

>8

Средний

Сложный

Сложный

Табл. 7.19. Оценка сложности отчета

Отчеты

Количество серверных (срв) и клиентских (клт) таблиц данных

Количество представлений

Всего < 4

(< 2 срв, < 3 клт)

Всего < 8

(2-3 срв, 3-5 клт)

Всего > 8

(>3срв, > 5 клт)

0 или 1

Простой

Простой

Средний

2 или 3

Простой

Средний

Сложный

>4

Средний

Сложный

Сложный

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

Для учета реальных условий разработки вычисляется процент повторного использования программных компонентов %REUSE и определяется количество новых объектных точек NOP:

NOP = (Объектные точки) х [(100 - %REUSE) /100].

Для оценки затрат, основанной на величине NOP, надо знать скорость разработки продукта PROD. Эту скорость определяют по табл. 7.20, учитывающей уровень опытности разработчиков и зрелость среды разработки.

Проектные затраты оцениваются по формуле:

ЗАТРАТЫ = NOP /PROD [чел.-мес],

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

Табл. 7.20. Оценка скорости разработки

Опытность/ возможности разработчика

Зрелость/ возможности среды разработки

PROD

Очень низкая

Очень низкая

4

Низкая

Низкая

7

Номинальная

Номинальная

13

Высокая

Высокая

25

Очень высокая

Очень высокая

50

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

Общее уравнение оценки стоимости имеет вид:

Работа = 2,45*ЕArch*(Размер)р,

Где Работа -- число человеко-месяцев;

EArch -- результат применения семи уточняющих факторов ранних этапов проектирования (см. таблицу 7.21);

Размер -- число функциональных точек (предпочтительно) или KSLOC;

Р -- показатель степени.

Табл. 7.21. Уточняющие факторы на ранних этапах проектирования

Идентификатор

Составные уточняющие факторы

Сложность продукта

RELY-DATA-CPLX-DOCU

Необходимость повторного использования

RUSE

Сложность платформы

TIME-STOR-PVOL

Опытность персонала

AEXP-PEXP-LTEX

Способности персонала

ACAP-PCAP-PCON

Возможности

TOOL-SITE

Сроки

SCED

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

Работа=2,45*EApp*(Размер)р,

где: Работа -- число человеко-месяцев;

EApp -- результат применения семнадцати уточняющих факторов постархитектурных этапов разработки (см. таблицу 7.22);

Размер -- число функциональных точек или KSLOC (предпочтительно);

Р -- показатель степени.

Табл.7.22. Усовершенствованная постархитектурная модель COCOMO II

Идентификатор

Уточняющий фактор работ

Изменение в COCOMO II

RELY

Требуемая надежность

Без изменений относительно COCOMO

DATA

Размер базы данных

Без изменений относительно COCOMO

CPLX

Сложность продукта

Без изменений относительно COCOMO

RUSE

Требуемый уровень повторного использования

DOCU

Документация

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

TIME

Ограничение времени выполнения

Без изменений относительно COCOMO

STOR

Ограничение объема основной памяти

Без изменений относительно COCOMO

PVOL

Изменчивость платформы

Фактор изменчивости платформы

ACAP

Способности аналитика

Без изменений относительно COCOMO

AEXP

Знание приложений

Без изменений относительно COCOMO

PCAP

Способности программиста

Без изменений относительно COCOMO

PCON

Преемственность персонала

Новый параметр

LTEX

Знание языка программирования и инструментария

Изменен с целью охвата знаний инструментария и языка

SITE

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

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

TOOL

Использование программных инструментов

Без изменений относительно COCOMO

SCED

Требуемые сроки разработки

Без изменений относительно COCOMO

Коэффициенты EApp отражают совместное влияние многих параметров. В постархитектурной модели применяются параметры, аналогичные используемым в традиционной модели СОСОМО. Эти параметры позволяют характеризовать и нормировать среду разработки по параметрам, содержащимся в базе данных проектов модели СОСОМО II (в 2002 г. - это 83 проекта). Каждый параметр в зависимости от установленного значения (очень низкое, низкое, номинальное, высокое, очень высокое) вносит свой вклад в виде множителя с диапазоном значений обычно от 0.5 до 1.5. Результат учета этих 17 эффектов и используется при вычислении работы в уравнении стоимости.

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

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

Модель СОСОМО II использует одну и ту же показательную функцию для моделей ранних этапов проектирования и для постархитектурных моделей. Показатель степени может изменяться в диапазоне от 1.01 до 1.26 и определяется как сочетание влияния следующих параметров:

1. Наличие прецедентов у приложения: уровень опыта организации-разработчика в данной области;

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

3. Разрешение рисков, присущих архитектуре: степень технической осуществимости, продемонстрированной до перехода к полномасштабному производству;

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

5. Зрелость процесса: уровень зрелости организации-разработчика, определяемая в соответствии с моделью СММ.

Параметризация экспоненты в модели СОСОМО II является эволюционным развитием подхода, использованного в предыдущих моделях СОСОМО. В таблице 7.19 обобщены возможные значения параметров. Реальный показатель экспоненциальной функции модели СОСОМО II определяется как сумма эффектов всех параметров. Объединенное влияние этих параметров процесса может оказаться весьма существенным. Вместе с тем команда разработчиков модели СОСОМО II допускает реальную экономию при больших масштабах (это означает, что значение Р никогда не становится меньше единицы). Они убеждены в том, что экономия при больших масштабах может быть достигнута за счет сокращения размера в результате использования коммерческих компонентов и повторного использования кода, CASE-средств и объектно-ориентированных технологий.

Еще одно интересное усовершенствование в модели СОСОМО II -- уравнение для оценки сроков, которое теперь является функцией как оценки работы, так и параметров процесса. Результирующее влияние лучшего процесса приводит к уменьшению как работы, так и сроков.

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

программный стоимость код затраты

Табл. 7.19. Параметры показателя экспоненциальной функции модели COCOMO II

Параметр

Очень низкое (0,00)

Низкое (0,01)

Номинальное (0,02)

Высокое (0,03)

Очень высокое (0,04)

Чрезвычайно высокое (0,05)

Наличие прецедентов

Полное отсутствие прецедентов

Почти полное отсутствие прецедентов

Наличие некоторого количества прецедентов

Общее знакомство

Широкое знакомство

Исчерпывающее знакомство

Гибкость разработки

Строгая

Случайные послабления

Некоторые послабления

Общее соответствие

Некоторое соответствие

Общие цели

Разрешение рисков в архитектуре

Малое 20%

Некоторое 40%

Частое 60%

В целом 75%

Почти полное 90%

Полное 100%

Сплоченность команды

Сильно затрудненное взаимодействие

Несколько затрудненное взаимодействие

Некоторая согласованность

Повышенная согласованность

Высокая согласованность

Взаимодействие как единого целого

Зрелость процесса

Уровень 1

Уровень 2

Уровень 2+

Уровень 3

Уровень 4

Уровень 5

Литература

1. Гультяев А.К. Microsoft Project. Управление проектами: Русифицированная версия. - М.: Корона принт, 2003.

2. Карпова В.С. Опыт использования Primavera на фазе инициации проекта. //Вестник ПМСофт. Журнал по управлению проектами для профессионалов. №1, 2005. -- С.26-30.

3. Культин Н.Б. Инструменты управления проектами: Project Expert и Microsoft Project. - СПб.: БХВ-Петербург, 2009. - 160 с. Ил.

4. Трофимов В.В., Иванов В.Н., Казаков М.К., Евсеев Д.А., Карпова В.С. Управление проектами с Primavera. Учебное пособие. СПб.: Изд-во СПбГУЭФ, 2005. -- 180 с.

5. Управление инновационными проектами: Учеб. пособие / Под ред. проф. В.Л. Попова. - М.: ИНФРА, 2007. - 336с.

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.