
- •Оглавление
- •Введение.
- •Организация процесса конструирования. Жизненный цикл программных средств.
- •Определение технологии конструирования программного обеспечения
- •Классический жизненный цикл
- •Макетирование
- •Стратегии конструирования по
- •Инкрементная модель
- •Быстрая разработка приложений
- •Спиральная модель
- •Компонентно-ориентированная модель
- •Тяжеловесные и облегченные процессы
- •Модели качества процессов конструирования
- •Планирование программного проекта. Оценка трудоемкости и стоимости программного проекта. Конкурентоспособность.
- •Процесс руководства проектом
- •Начало проекта
- •Измерения, меры и метрики
- •Планирование проектных задач
- •Размерно-ориентированные метрики
- •Функционально-ориентированные метрики
- •Выполнение оценки в ходе руководства проектом
- •Выполнение оценки проекта на основе loc- и fp-метрик
- •Конструктивная модель стоимости
- •Модель композиции приложения
- •Модель раннего этапа проектирования
- •Модель этапа постархитектуры
- •Предварительная оценка программного проекта
- •Анализ чувствительности программного проекта
- •Сценарий понижения зарплаты
- •Сценарий наращивания памяти
- •Сценарий использования нового микропроцессора
- •Сценарий уменьшения средств на завершение проекта
- •Организация разработки программного проекта.
- •Кризис программирования и способ выхода из него
- •Модель cmm-sei
- •Управление качеством разработки программного продукта с помощью системы стандартов iso 9001
- •Примерная структура процесса и организации, занимающейся разработкой программных продуктов
- •Внедрение программного проекта.
- •Что такое проект внедрения.
- •Определение стратегических целей проекта и тактического плана внедрения
- •Обучение специалистов группы внедрения.
- •Моделирование бизнеса.
- •Обучение конечных пользователей работе с системой.
- •Опытно-промышленная эксплуатация
- •Ввод системы в промышленную эксплуатацию.
- •Ключевые факторы успеха.
- •Эволюция программного обеспечения.
- •5.1. Наследуемые системы
- •Количество сбоев аппа- Характеризуются ли аппаратные средства высоким уровнем ратных средств и по сбоев в работе? Является ли по поддержки причиной аварийных перезагрузок системы?
- •5.2. Модернизация программного обеспечения
- •Прогнозирование сопровождения
- •5.3. Реинжениринг программного обеспечения
- •Преобразование исходного кода программ
- •Анализ систем
- •Создание программных модулей
- •Создание абстракций данных
- •Изменение данных
- •5.4. Управление конфигурациями
- •Планирование управления конфигурацией
- •Определение конфигурационных объектов
- •База данных конфигураций
- •Управление изменениями
- •Управление версиями и выпусками
- •Идентификация версий
- •Управление выходными версиями
- •Сборка системы
- •Case-средства для управления конфигурацией
- •Средства поддержки управления изменениями
- •Средства поддержки управления версиями
- •Средства сборки систем
- •Экономическая эффективность эксплуатации программного проекта.
- •6.1. Особенности экономики производства крупных программных продуктов
- •6.2. Проблемы анализа экономики производства программных продуктов
- •6.3. Проблемы организации экономически эффективного производства программных продуктов
- •6.4. Оценка стоимости разработки программного обеспечения
- •6.4.1. Линейный метод
- •6.4.2. Метод функциональных точек
- •6.4.3. Оценка с использованием эмпирических данных
- •6.5. Методы оценки эффективности по на этапе эксплуатации
- •Список литературы.
6.4.3. Оценка с использованием эмпирических данных
Альтернативой методам, описанным выше, являются методы, основанные на уже имеющемся опыте, которые позволяют добиться хороших результатов при относительно невысоких затратах.
Метод Демарко
Метод, разработанный Томом Демарко в 1982 г., основан на использовании так называемой «бэнг-метрики». Этот простой, но эффективный подход к оценке стоимости ПО, близок по содержанию к методу функциональных точек с тем отличием, что полученные оценки корректируются с учетом хронологических данных по выполненным ранее проектам. Такой подход позволяет получить не абстрактные показатели, а приближенные значения реальных затрат ресурсов и времени.
SLIM
В 1978 г. Лоуренс Патнам предложил нелинейную модель, использующую эмпирические данные при оценке стоимости ПО — SLIM (Software Life-cycle Model). Данная методика, созданная на основе реальных данных, собранных в Министерстве обороны США, предназначена для определения трудоемкости крупных программных проектов. Несмотря на то что широкого распространения эта модель не приобрела, некоторые фирмы до сих пор используют ее для расчета трудозатрат.
Согласно модели SLIM трудозатраты на разработку ПО вычисляются по следующей формуле:
где Р — размер программы, чаще всего измеряется в строках кода, хотя можно использовать и другие единицы измерения (функциональные точки, например);
С — технологическая константа, учитывающая как уровень существующих технологий, так и производительность персонала (команды разработчиков);
td — ограничение на срок поставки, измеряется в годах.
сосомо
Модель СОСОМО (Constructive COst MOdel), предложенная в 1981 г. известным ученым Барри Боэмом [59], является на сегодняшний день самой популярной методикой для оценки стоимости разработки ПО. Для создания СОСОМО были проанализированы статистические данные 63 проектов различных типов. Данная модель имеет три уровня детализации: базовый, промежуточный и подробный и предусматривает три режима использования в зависимости от размеров проекта и реализующей его команды (табл. 9.4).
Трудоемкость проекта на базовом уровне СОСОМО определяется с помощью следующей формулы:
Т = охРх6, (9.5)
где а и b — константы, которые определяются режимом использования модели.
Таблица
9.4.
Режимы использования СОСОМО
Режим
Размер
проекта
Описание
Органичный
До
50 KLOC
Некрупный
проект и небольшая команда, для
которой нехарактерны нововведения,
и среда остается стабильной
Сблокированный
50-300
KLOC
Относительно
небольшая команда занимается проектом
среднего размера, в процессе разработки
необходимы определенные инновации,
среда характеризуется незначительной
нестабильностью
Внедренный
Более
300 KLOC
Большая
команда разработчиков трудится над
крупным проектом, необходим значительный
объем инноваций, среда состоит из
множества элементов, которые не
характеризуются стабильностью
Из формулы (9.5) видно, что трудозатраты зависят от размера проекта и при смене режима модели скачкообразно изменяются (табл. 9.5).
Длительность выполнения проекта по модели СОСОМО вычисляется по формуле
F= 2,5 х Т х к. (9.6)
Из формулы (9.6) видно, что рост трудоемкости проекта не приведет к значительному увеличению его длительности, поскольку при этом изменяется значение константы к, зависящей от режима модели.
Режим |
Коэффициент а |
Коэффициент b |
Коэффициент к |
Органичный |
2,4 |
1,05 |
0,38 |
Сблокированный |
3,0 |
1,12 |
0,35 |
Внедренный |
3,6 |
1,20 |
0,32 |
Промежуточный и подробный уровни модели СОСОМО добавляют в формулы (9.5) и (9.6) дополнительные коэффициенты, которые позволяют повысить точность оценок. Кроме того, в модели возможна корректировка оценок на основе хронологических данных из уже выполненных проектов.
СОСОМО II
Модель СОСОМО II пришла на смену устаревшей оригинальной модели в 1997 г. Выполненная на основе СОСОМО, она адаптирована к современным технологиям разработки ПО. Так, если в СОСОМО использовалась каскадная модель жизненного цикла, то СОСОМО II предназначена для спиральной и итеративной моделей. Размер программного продукта в СОСОМО II может измеряться как строками кода, так и функциональными и объектными точками.
СОСОМО II имеет три варианта использования — фактически это три разные модели для решения различных задач, объединенные под одним общим названием (табл. 9.6).
Таблица
9.6.
Варианты использования модели СОСОМО
II
Название
модели
Описание
Композиционная
прикладная
Ориентирована
на проекты, создаваемые с применением
современных инструментальных средств
и UML,
использует
в качестве метрики объектные точки
Ранней
разработки проекта
Применяется
для получения приближенных оценок
по проекту до определения его
архитектуры, использует в качестве
метрик количество строк кода или
функциональные точки
Постархитектурная
модель
Наиболее
детализированная модель, используется
после разработки архитектуры проекта
и позволяет получить самые точные
оценки, применяет в качестве метрик
количество строк кода или функциональные
точки
Таким образом, при сохранении основных принципов СОСОМО модель стала намного гибче и при оценке трудоемкости и стоимости ПО учитывает намного больше различных факторов, влияющих на выполнение проекта.