Оценка трудозатрат и сроков разработки программных средств с использованием модели cocomo в программном пакете cosmos

Цель работы

Ознакомиться с Конструктивной Моделью Стоимостного Анализа (COnstructive COst MOdel - COCOMO), реализованной в программном пакете COSMOS, приобрести практические навыки в оценивании сроков разработки программных средств (ПС) и трудозатрат, необходимых для их создания.

2. Теоретическая справка

Разновидности модели COCOMO

Конструктивная Модель Стоимостного Анализа, или COCOMO, была впервые предложена Бэрри Боэмом в 1981 г. для того, чтобы параметрически оценивать трудозатраты и сроки разработки программных продуктов. Она подробно описана в его книге “Инженерное проектирование программного обеспечения” [1]. Причем Б. Боэмом были предложены три разновидности модели COCOMO: базовая, промежуточная и детальная.

Базовая модель COCOMO наиболее простая, но при этом наименее точная, поскольку при оценке трудоемкости программных проектов и сроков их выполнения в ней учитывается лишь информация о типе разрабатываемого программного продукта и о его размере (в строках исходного кода - Source Lines Of Code - SLOC).

Промежуточная модель COCOMO определяет трудозатраты и сроки создания ПС как функции от размера и типа разрабатываемого программного продукта, а также субъективной экспертной оценки 15 влияющих (стоимостных) факторов. Именно промежуточная модель COCOMO является основой соответствующей функции программного продукта COSMOS. Она позволяет получать вполне удовлетворительные оценки для большинства небольших и средних проектов при относительно невысокой трудоемкости самой операции оценивания.

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

Структурная схема промежуточной модели COCOMO, реализованной в программном пакете COSMOS показана на рис. 5.1.

Рис. 5.1. Структурная схема промежуточной модели COCOMO в программном пакете COSMOS

 

Согласно этой схеме входными данными модели COCOMO будут являться: объем проекта в SLOC, тип программной разработки и заданные пользователем рейтинги стоимостных факторов. Рассмотрим несколько подробнее основные источники и способы получения этих входных данных.

Количество строк исходного кода (SLOC)

Как известно, на практике достаточно сложно оценить количество строк исходного кода (SLOC) на ранних стадиях цикла разработки программного продукта, когда детального проекта еще нет. В программе COSMOS эту проблему предлагается решать путем применения бэкфайер-метода к результатам анализа, произведенного с использованием метода функциональных точек (см. лабораторную работу № 4).

Однако не исключаются и другие источники информации о предполагаемом количестве строк исходного кода, разрабатываемого ПС, например, результаты экспертных оценок, оценок, полученных с использованием метода аналогий (см. лабораторную работу № 6) и т.п.

В любом случае при оценке количества строк исходного кода для модели COCOMO следует руководствоваться следующими правилами:

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

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

· одна команда - это одна строка кода;

· декларации считаются командами;

· комментарии не считаются командами.

Типы программной разработки

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

Для распространенного типа (Organic Mode) характерны отдельные программы с небольшим количеством ограничений и интерфейсов, разрабатываемые с использованием стандартных средств разработки ПО, без применения принципиально новых алгоритмов. Обычно это небольшой программный проект (как правило, не более 50000 SLOC), над которым работает небольшая группа разработчиков с достаточным опытом работы. В целом, к проекту предъявляются довольно мягкие требования.

Для полунезависимого типа (Semidetached Mode) характерны средние по размеру проекты (как правило, не более 300000 SLOC), для которых может быть определен ряд как мягких, так и строгих ограничений. Такой проект обычно выполняется группой разработчиков с разным опытом работы. В целом к полунезависимому типу можно отнести проекты, которые сочетают в себе характеристики проектов как распространенного, так и встроенного типов.

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

Стоимостные факторы

В модели СОСОМО при вычислении трудозатрат используется коэффициент нормирования трудозатрат (Effort Adjustment Factor - EAF), получаемый путем оценивания 15 стоимостных факторов (атрибутов), которые сгруппированы в четыре основные категории: атрибуты программного продукта, атрибуты аппаратных средств, атрибуты персонала и атрибуты проекта.

Атрибуты создаваемого программного продукта:

· RELY (Required Software Reliability) - требуемая надежность ПО, т.е. уровень привнесения ошибок, которые могут быть допустимы в программном продукте. “Ненадежная” программа может причинять небольшие неудобства, а может угрожать человеческой жизни.

· DATA (Size of Application Database) - размер базы данных приложения, т.е. отношение размера базы данных к размеру программы.

· CPLX (Complexity of Product) - сложность программного продукта, т.е. степень сложности функций, используемых в программах-приложениях. Простые функции содержат простые выражения в операциях вычисления, несложные команды управления, операции по управлению данными используют простые массивы в основной памяти. Сложные функции содержат сложные вложенные инструкции управления, трудоемкие математические вычисления, динамическое управление данными в базе данных, кодирование на языках машинного уровня (ассемблере) аппаратно зависимых частей ПО (драйверов).

Атрибуты аппаратных средств, т.е. аппаратной платформы, используемой при работе:

· TIME (Run-Time Performance) - ограничение по быстродействию, т.е. степень использования отведенного для выполнения времени.

· STOR (Memory Constraints) - ограничение по оперативной памяти, т.е. степень использования доступного пространства памяти.

· VIRT (Virtual Machine Volatility) - изменяемость виртуальной машины, т.е. относительная частота изменений, которым подвергается виртуальная машина. Для конкретного программного изделия виртуальной машиной называется комплекс аппаратуры и системного ПО (ОС, СУБД и т.п.), используемый при выполнении задач изделия.

· TURN (Required Turnaround Time) - требуемое оборотное время, т.е. время, затрачиваемое на ожидание обслуживания и обработку задания в системе (время реакции, время отклика, необходимое для обратной связи с пользователем).

Атрибуты персонала, т.е. характеристики членов команды проекта:

· ACAP (Analyst Capability) - квалификация аналитиков, т.е. процентная оценка способностей аналитиков.

· PCAP (Software Engineer Capability) - квалификация программистов, т.е. процентная оценка способностей программистов.

· AEXP (Application Experience) - опыт работы в данной прикладной области, т.е. количество лет, в течение которых персонал получал знания о прикладном программировании в данной области.

· LEXP (Programming Language Experience) - опыт работы с языком программирования, т.е. количество лет, в течение которых персонал работал с данным языком программирования.

· VEXP (Virtual Machine Experience) - опыт работы с виртуальной машиной, т.е. количество лет, в течение которых персонал работал с данной операционной системой и аппаратными средствами.

Атрибуты проекта, т.е. характеристики процесса разработки данного программного продукта:

· TOOL (Use of Software Tools) - использование программных инструментов, т.е. характеристики средств и инструментов, используемых для создания ПО. Средства могут быть очень простыми, требующими значительного объема “ручного” программирования, или крайне сложными, с автоматическим проектированием, разработкой документов и кодированием.

· MODP (Application of SE Methods) - практика современного программирования, т.е. степень использования современных методов и технологий разработки ПО, а также опыта программирования.

· SCED (Required Development Schedule) - ограничение сроков проектирования, т.е. значимость даты поставки продукта. Высокая степень значимости подразумевает, что продукт желательно или необходимо поставить как можно раньше.

Для каждого стоимостного фактора устанавливается соответствующий ему рейтинг. Шкала рейтингов состоит из 6 уровней градации от “очень низкого” до “сверхвысокого”. Детально процедура ранжирования стоимостных факторов в модели COCOMO представлена с помощью табл. 5.1. В табл. 5.2. приведена информация для оценивания фактора CPLX - сложности программного продукта.

Таблица 5.1. Оценивание стоимостных факторов в модели COCOMO

Продолжение табл. 5.1.

Продолжение табл. 5.1.

Таблица 5.2. Рейтинг сложности (CPLX) в зависимости от типа преобладающих в ПС операций

Продолжение табл. 5.2.