VI Международная студенческая научная конференция Студенческий научный форум - 2014

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

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

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

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

- используется для создания количественного и качественного прогнозирования значения одной переменной, которое получается, опираясь на значения других переменных;

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

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

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

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

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

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

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

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

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

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

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

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

Основнымипреимуществами модели СОСОМО являются следующие пункты:

- подбираются фактические данные, отвечающие требованиям существующих программ, которые хранят набор постоянных переменных СОСОМО и факторов корректировки, подходящих конкретной организации;

- процесс, который используется в данном случае, является повторяемым;

- является, по сути, универсальным методом и может хранить разные «режимы» и «уровни»;

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

- вероятна высокая степень сортировки, которая основывается на предыдущем опыте с данными;

- обязательная документация;

- относительная простота и легкость в использовании и в дальнейшем применении.

Ниже перечислены основные недостатки регрессионной модели СОСОМО:

• исключается изменяемость требований и документация;

• не принимаются во внимание атрибуты заказчика – навыки и знания, кооперирование, возможность быстрого реагирования;

• достаточно сильно облегчается воздействие вопросов безопасности;

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

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

• игнорируется воздействие персонала (уровень);

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

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

• значения и оценки, базированные на опыте, могут являться некорректными по причине хронологических данных, которые становятся устаревшими;

• имеется прямая связь между знаниями по драйверам затрат и тем количеством времени, которое расходуется на определенной фазе.

Также в регрессионной модели исключаются следующие моменты:

• разработка и спецификация тех требований, которые не слишком часто используются в некоторых коммерческих организациях;

• менеджмент, который обычно совершается на уровне строк;

• издержки и расходы (также расходы на поездки и другое);

• поддержка тестирования и системное объединение или интеграция;

• обеспечение полей для теста;

• компьютерное обеспечение;

• поставки (источники);

• назначенное место в офисе.

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

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

Опираясь на концепцию Боэма, трудозатраты первоначально делились так, чтобы 30% определялось на дизайн, 30% на тестирование и кодирование модуля, а 40% на тестирование и интеграцию.

Рис. Фазы, которые включаются в COCOMO

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

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

Библиографический список

1) http://ru.wikipedia.org/wiki/COCOMO

2) http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html

 

Код для цитирования: Скопировать