Экономическая модель разработки ПО
Структура стоимости программного обеспечения. Использование строк кода 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
...Подобные документы
Подсчет количества функциональных точек. Расчет трудозатрат на разработку программного средства и ориентировочного времени его разработки, модель жизненного цикла. Разработка технического задания на создание автоматизированной системы, требования к ней.
курсовая работа [2,0 M], добавлен 11.01.2014Модель этапа пост-архитектуры. Предварительная оценка программного проекта на основе LOC-метрик. Расчет затрат на разработку ПО. Стоимость, длительность разработки проекта на основе модели этапа пост-архитектуры конструктивной модели стоимости СОСОМО II.
курсовая работа [89,9 K], добавлен 29.09.2009Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.
презентация [874,4 K], добавлен 19.09.2016Общая характеристика основных моделей жизненного цикла: каскадная, инкрементная, спиральная. Стадия как часть процесса создания программного обеспечения, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта.
презентация [159,1 K], добавлен 27.12.2013Характеристика программного продукта и стадий разработки. Расчет затрат на разработку и договорной цены, эксплуатационных расходов, связанных с использованием нового программного продукта. Оценка конкурентоспособности. Изучение, оценка рыночного спроса.
курсовая работа [139,0 K], добавлен 22.09.2008Понятие технологии разработки программного обеспечения и модели жизненного цикла. Сущность объектно-ориентированного подхода. Строительные блоки, общие механизмы языка моделирования UML, диаграммы классов, состояний, взаимодействий и компонентов.
курсовая работа [262,5 K], добавлен 10.07.2014Понятие и этапы жизненного цикла программного обеспечения как некоторых событий, которые происходят с системой компьютера в процессе ее создания, внедрения и сопровождения. Модели данного процесса: каскадная, спиральная, их отличительные особенности.
доклад [33,5 K], добавлен 06.04.2015Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
презентация [114,7 K], добавлен 14.08.2013Обзор и анализ существующих методик управления проектами и оценки трудоемкости. Разработка алгоритма задания параметров и вычисления трудоемкости и стоимости программного продукта. Отладка и тестирование продукта. Разработка руководства пользователя.
дипломная работа [2,5 M], добавлен 18.11.2017Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Общий календарный план выполнения этапов проекта программного обеспечения. Последовательность разработки согласно классической каскадной модели. Изображение хода работ по спиральной модели согласно Боему. Технические требования на продукт, WBS-структура.
лабораторная работа [614,1 K], добавлен 17.01.2014Краткая характеристика программного средства и стадии ее разработки, предъявляемые требования и функциональные особенности. Определение трудоемкости и состава группы исполнителей. Вычисление затрат на разработку программного продукта и договорной цены.
курсовая работа [464,5 K], добавлен 05.02.2016Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.
презентация [1,0 M], добавлен 11.05.2015Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
курсовая работа [1,8 M], добавлен 20.11.2010Создание программного продукта, представляющего моделирование на компьютере логнормального распределения, определение вероятностной оценки стоимости актива. Описание работы программного продукта. Работа с графиками, таблицами, математическими функциями.
курсовая работа [742,7 K], добавлен 08.01.2009Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
отчет по практике [296,1 K], добавлен 19.04.2015Характеристика программных средств, использованных при разработке сайта. Параметры аппаратных средств для демонстрации ПП. Особенности архитектуры программного обеспечения. Анализ модели жизненного цикла программного продукта. Построение Gant-диаграммы.
курсовая работа [886,9 K], добавлен 30.05.2015Экономическая роль индустрии информационных технологий. Методы оценки трудозатрат на разработку программного обеспечения. Модель Путнэма жизненного цикла ПО. Принципы, которыми нужно пользоваться при оценке трудозатрат проекта. Роль ИТ-индустрии в мире.
курсовая работа [91,0 K], добавлен 02.12.2012Архитектура Windows NT 5. Приоритеты выполнения программного кода. Описание формата MIDI-данных. Установка драйвера в системе. Выбор средств разработки программного обеспечения. Обработка запросов драйверной модели WDM. Использование библиотеки DirectKS.
курсовая работа [498,8 K], добавлен 24.06.2009Архитектура программного продукта и требования к платформе, обоснование выбора разработки. Закономерности и основные этапы алгоритмизации и программирования, а также отладка и тестирование продукта. Разработка и содержание руководства пользователя.
дипломная работа [2,3 M], добавлен 19.01.2017