Глава 3. Модели оценки затрат на разработку ПО

3.1 Модель Путнэма жизненного цикла программного обеспечения – SLIM

SLIM была разработана на основе анализа жизненного цикла ПО, котором применялось распределение Рейлиха (Rayleigh distribution) для оценки усилий разработчиков за определенное время. Усилия потраченные собственно на разработку, как правило составляют 40 процентов от всего жизненного цикла. Подразумевается, что эта модель не должна применяться до стадий кодирования и проектирования.

Уравнение Путнэма:

SLOC = C E1/3 t4/3

SLOC – число строк кода

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

Оценка для С:

C=2000 (недостаточно)

C=8000 (хорошо)

C=12000 (отлично)

E – общие усилия приложенные при разработке проекта, измеряется в человек за год.

t - время, которое понадобится для реализации проекта, измеряется в годах

С определяется следующими факторами:

1) уровнем зрелости компании и используемыми практиками управления процессов

2) степенью применения хороших практик программирования

3) используемыми языками программирования

4) средствами разработки ПО

5) умением и опытом команды разработчиков

6) сложность, разрабатываемого продукта

Для оценки, приложенных усилий Путнэм предложил использовать уравнение, построенное на человеческой производительности (manpower-buildup equation):

D = E / t3

D – ускорение производительности работника (manpower acceleration), константа.

Значения D:

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

D=15 для систем, не предназначенных для взаимодействия с другими системами

D=27 для изменения уже существующих систем

Применяя уравнение построенное на человеческой производительности мы можем найти общее усилие E:

E = (SLOC / C)9/7× D4/7

Преимущества:

SLIM-модель проста и имеет небольшое число параметров.

Недостатки:

SLIM-модель практически бесполезна до стадии планирования и кодирования

SLIM-модель сильно зависит от технологического параметра.

SLIM-модель нечувствительна и не применима для небольших проеков.

На сегодняшний день QSM разработала набор средств основанный на SLIM-модели:

SLIM-Control, SLIM-Metrics, SLIM-estimate.

3.2 Checkpoint

Checkpoint – это основанный на знаниях инструмент для оценки проектов, разработанный в SPR на основе работ Каперса-Джонса. Он содержит базу данных, включающую 8000 программных проектов и он сфокусирован на 4-х областях, которыми необходимо управлять, чтобы улучшать качество и продуктивность ПО. Checkpoint использует метод показателей функциональности для первоначального ввода размера. Эта модель сфокусирована на 3-х основных возможностях для поддержки всего жизненного цикла создания ПО.

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

Измерения: Checkpoint позволяет используя метрики проекта проводить сравнительный анализ производительности (методом прогона контрольных задач) (benchmark analysis), определять лучшие практики и совершенствовать внутренние базы знаний.

Оценивание (assessment): Checkpoint способствует сравнивает действительные и оцененные действия с учетом промышленных стандартов. Эта модель также оценивает сильные и слабые стороны среды программного продукта (software environment).

3.3 PRICE-S

Уравнения на которых основывается модель засекречены, хотя некоторые алгоритмы были опубликованы. PRICE-S модель состоит из трех подмоделей, которые оценивают графики работ и затраты на разработку ПО. Три основные подмодели и их функции:

Подмодель приобретение (The acquisition submodel): эта подмодель рассматривает графики работ и затраты. Модель описывает все типы разработки ПО, включая бизнес системы, системы управления и контроля, авиа и космические системы. PRICE-S обращает внимание на методы разработки ПО, доступные на сегодняшний день такие как объектно-ориентированное программирование, реинжениринг, генерация кода, спиральная разработка, быстрая разработка и измерения продуктивности ПО.

Подмодель-измерение (The sizing model): эта подмодель облегчает оценивание размера ПО, которое должно быть разработано. Измерение может быть произведено в числе строк кода, в функциональных точках или в предсказывающих объектных точках (Predictive Object Point – POP).

Подмодель жизненный цикл затрат (The Life-cycle Cost Submodel): эта подмодель используется для быстрого и легкого оценивания во время стадий сопровождения и поддержки ПО. Используется вместе с подмоделью приобретения, в которой определяются затраты на разработку и планирование.

Разработкой инструментов на основе этой модели занимается компания PRICE Systems которая уже создала инструмент Foresight 2.0 для оценки времени, затрат и усилий необходимых для реализации коммерческих и невоенных правительственных проектов.

3.4 SELECT Estimator

SELECT Estimator разработан компанией SELECT Software Tools и представляет часть набора интегрированных продуктов разработанных для проведения моделирования на элементной основе.

SELECT Estimator был выпущен в 1988г., с целью разработки широко масштабных распределенных систем. Он объектно-ориентирован и основывает свои оценки на базе бизнес-объектов и компонент. Этот инструмент предполагает разбиение на части жизненного цикла (но может быть ориентирован под другие модели развития).

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

На более поздних стадиях, с появлением большего количества информации, оценки соответственно становятся более надежными.

Применяемая техника оценки основана на методе объектной матрицы (Object Matrix) разработанной Object Factory. Объектная матрица работает, измеряя размер проекта и классифицируя элементы проекта. Проект определен в рамках бизнес приложений построенных на базе классов и поддерживающий набор используемых случаев, плюс инфраструктуры, состоящей из повторно использующихся компонентов (экранов, отчетов и модулей).

Техники объектной матрицы, начинается с измерения размера трудозатрат в человеко-днях обычно необходимых для разработки частей данного проекта. Эта оценка трудозатрат учитывает все виды деятельности необходимых для нормального жизненного цикла разработки программного обеспечения, но не учитывает ничего касательно характеристик проекта или используемой технологии, что может квалифицироваться как оценка трудозатрат. Предварительно определенные профили деятельности, охватывающие планирование, анализ, разработку, программирование тестирование, интеграцию и оценку используются в соответствии с типом элемента проекта, который разделяет обычные трудозатраты в трудозатраты по виду деятельности. (Эти профили деятельности основаны на собранных и поддерживаемых Object Factory проектных данных.)

Основная оценка трудозатрат производится, при помощи “квалификаторов” для добавления или извлечения процентного соотношения из каждого отдельно оцененного вида деятельности.

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

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

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

SELECT Estimator уточняет оценку затрат посредством объектной матрицы, повышая качество факторов квалификатора и технологических факторов.

3.5 Модель COCOMO II

Модель оценивания затрат COCOMO II является развитием иерархической модели Б. Боэма COCOMO и предназначена для оценивания трудовых затрат (трудоемкости) на разработку ПО. Эта модель использует сочетание экспертного и алгоритмического методов оценивания и учитывает современный уровень программной инженерии (характеристик ПО, технологий разработки, организации процесса разработки). В настоящее время это наиболее полная, конструктивная и широко применяемая модель оценивания трудозатрат.

Модель ориентирована на порционность поступления информации для оценивания на протяжении всего периода разработки ПО и является трехуровневой:

Предварительная модель (Application Composition Model). Обеспечивает предварительную оценку трудозатрат на ПС на ранних стадиях разработки. Модель предназначена для оценки трудоемкости прототипирования, а также разработки ПО с использованием интегрированных сред (ICASE).

Предпроектная модель (Early Design Model). Обеспечивает предварительную оценку трудозатрат на разработку как ПО в целом, так и отдельных программных компонентов (подсистем) на предпроектных стадиях ЖЦ. Может применяться для технико-экономического обоснования затрат на создание ПО а также для распределения затрат по стадиям разработки.

3. Детальная модель (Post Architecture Model). Уточняет оценку, выполненную по предпроектной модели. Обеспечивает поуровневую оценку трудозатрат на разработку ПО - от программных компонентов до программных модулей. Может применяться на стадиях проектирования и разработки ПО, а также при сопровождении.

В числе достоинств модели СОСОМО II следует отметить: определенность, точность, объективность, детальность, простота применения.

Недостатки модели COCOMOII:

Оценка трудозатрат по Предварительной модели:

Оценка трудозатрат по модели выполняется на уровне программной системы в целом.

Расчет трудозатрат на разработку ПО производится по следующему алгоритму.

1. Вычисляется функциональный размер ПО. Для этого сначала определяется общий функциональный размер ПО (ОР) по всем составляющим ее информационно-функциональным объектам (экранам, отчетам, модулям), включая все объекты, которые будут использоваться в системе повторно.

Затем определяется функциональный размер разрабатываемых компонентов ПО (NOP) по формуле

NOP = (OP – (100 - %Reuse))/100

где %Reuse – доля (в процентах) повторно используемых объектов (экранов, отчетов и модулей).

2. Оценивается уровень производительности, PROD, как среднее атрибутов “Опыт работы и квалификация разработчика” и “Зрелость и возможности ICASE”

3. Трудозатраты на разработку вычисляются в человеко-месяцах (чел-мес.) по формуле:

Т = NOP/PROD

Вычисление трудозатрат для предпроектной модели:

Атрибут приложенных трудозатрата – EAF (effort adjustment factor) вычисляется на основе 15 атрибутов затрат, которые группируются в четыре категории: продукт, компьютер, персонал и проект. Каждый из этих оценивается по шести бальной шкале на основе имеющихся таблиц.

Затем все значения из этих таблиц перемножаются и получаем EAF.

Основное уравнение для подсчета трудозатрат для предварительной модели:

E = a×KLOC×EAF,

где a = 2,45 константа, полученная по результатам статистического анализа фактических данных более 80 реальных проектов

KLOC – число линий кода

Вычисление трудозатрат для детальной модели:

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

Уравнение трудозатрат для детальной модели:

E = a×KLOCb×EAF

где a = 2,55 константа, полученная по результатам статистического анализа фактических проектов

b = 1.01 + 0.01 ×Σ Wi

Wi - i-ый фактор

3.6 Принципы, которыми нужно пользоваться при оценке трудозатрат проекта

Не получать зависимости только от оценки стоимости или графика работ

Использовать несколько техник или моделей оценки трудозатрат, сравнивать результат и анализировать случаи, когда происходит расхождение

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

Совершенствовать процесс разработки ПО

Поддерживать и обновлять базу данных с информацией об уже завершенных проектах.