Модель COCOMO II: анализ и пути усовершенствования Текст научной статьи по специальности «Науки о здоровье»

Модель COCOMO II:

анализ и пути усовершенствования

М.А. Глазова,

аспирант,

кафедра МОиАИС,

Московский государственный

университет экономики,

статистики и информатики (МЭСИ)

В статье проводится анализ одной из самых популярных моделей оценки стоимости - СОСОМО II. Проверяется точности модели при использовании на проектах современного российского предприятия. Рассматриваются способы доработки модели с целью повышения точности.

В настоящее время, с ростом количества программных проектов с большим бюджетом, проблема оценки стоимости проекта на ранней стадии его развития становится одной из ключевых. Существует большое количество методов оценки - от метода «большого пальца», основанного на предположениях экспертов, до сложных методов, в основе которых лежат нейронные сети [1]. Однако наиболее популярными, вследствие возможности описания их с помощью математических формул и дальнейшей алгоритмизации, являются методы, основанные на математических моделях, и часто производные от них композитные методы, которые являются объединением двух и более методов оценки стоимости.

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

Полная формула модели COCOMO II выглядит следующим образом [2]:

Затраты = А х Kreq х Размерв х Ме + 3ampam/auto [чел. - мес.]

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

BRAK

Kreq = 1 +-

100

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

А - коэффициент масштаба, являющийся константой, определенной разработчиками модели (для модели COCOMO II калибровки 2000 года это значение равно 2,94).

Размер - размер программного кода в строках. В - общий фактор издержек масштаба.

5

B = 0,91 + 0,01£ Wi

i=1 ,

где W. - фактор масштаба. Среди факторов масштаба выделяют:

1) предсказуемость;

2) гибкость среды разработки;

3) риск архитектуры;

4) связность команды;

5) зрелость процесса.

Затраты - отражает затраты на код, генерируемый программой автоматически;

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

17

Ме =П EMi ,

i=1

где EM. - числовое значение фактора формирования затрат, характеризующего ситуацию на проекте.

Факторы формирования затрат делятся на четыре группы [3]:

1) факторы продукта;

2) факторы платформы;

Экономика, Статистика и Информатика 63 №3, 2008

3) факторы персонала;

4) факторы проекта.

К первой группе - факторы продукта — можно отнести следующие факторы:

1) требуемая надежность программного обеспечения (RELY);

2) размер базы данных (DATA);

3) сложность продукта (CPLX);

4) требуемое повторное использование кода (RUSE);

5) соответствие документации потребностям на каждом этапе жизненного цикла (DOCU).

К факторам платформы относятся:

1) Ограничения по времени исполнения операции (TIME);

2) Ограничения по объему хранилища (STOR);

3) Изменчивость платформы (PVOL).

К факторам персонала относятся:

1) возможности аналитиков (ACAP);

2) возможности программистов (PCAP);

3) опыт работы с приложением (AEXP);

4) опыт работы с платформой (PEXP);

5) опыт работы с языком и инструментарием программирования (LTEX);

6) текучесть персонала (PCON)

К факторам проекта относятся:

1) использование программных утилит (TOOL);

2) территориальный разброс проектной команды (SITE);

3) требуемый график разработки (SCED).

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

Последняя калибровка, т.е. подстройка коэффициентов модели COCOMO II на основе средних значений IT-отрасли, производилась в 2000—2003 гг. С этого момента прошло достаточно значительное время, что ставит под со-

мнение применимость модели в современных реалиях. Поэтому автором была поставлена задача проверки работоспособности СОСОМО II, и поиск путей по улучшению точности оценок с помощью данной модели.

Для проведения проверки были выбраны 40 проектов ЗАО «Системы автоматизированного управления», по которым производилась оценка с помощью модели СОСОМО II, и параллельно фиксировались фактические значения по срокам, стоимости и трудозатратам. Проекты были выбраны таким образом, чтобы факторы влияния на стоимость, длительность и трудозатраты максимально различались друг от друга, с целью недопущения выявления некорректных тенденций.

По завершении проектов был проведен сравнительный анализ результатов оценок с помощью модели СОСОМО II и фактических значений.

Расхождения рассчитывались по следующей формуле:

Расхождение =

Длителъностъоцн!!а - Длительность-^

Длительность-а*т

где Длительное тьоцш*а — длительность проекта, оцененная с помощью модели СОСОМО II;

Длительное тьфа*т — фактическая длительность проекта.

На основании данных по расхождениям была произведена оценка показателя РКЕБ.

РКЕБ(Х) - это процент значений оценки, которые оказались внутри Ь процентов фактических значений. Например, РКЕБ(0.25) отражает процент оценок, которые были внутри 25% фактических значений.

Затрат/est - Затратыact Затраты^ i

n

-rn

РЕЕЩХ) = 120 £ 11'еСли

Х " [о

где X - процент фактических значений;

Затраты асг 1 — фактическое значение затрат по проекту;

ЗатратыеЛ — предсказываемое значение затрат по проекту.

п — количество наблюдений.

Результаты оценки отражены в табл. 1.

Точность модели была определена как недостаточная (согласно [4], любая оценка с РКЕБ меньшим 60% считается недостаточно точной). Поэтому было

принято решение о добавлении новых факторов и проведении калибровки.

Для выделения перечня факторов для добавления в модель и оценки их значимости был использован метод Дельфи (техника Delphi, разработанная Rand Corporation, первоначально была предназначена для предсказания каких-то событий по проекту - отсюда возникло и название модели. Позднее технику стали использовать в группе специалистов в заданной области, чтобы придти к соглашению по какому-то вопросу. Участникам надо было произвести предварительный анализ предметной области индивидуально, без консультации с другими участниками. Результаты первого этапа собирали, упорядочивали и возвращали уже для следующего этапа, в ходе которого участников снова просили дать оценку по тому же вопросу, но уже с учетом знания результатов первого этапа, мнения других участников. Обычно второй этап сужал разброс мнений группы, выводя среднее арифметическое) с целью исключения влияния экспертов на оценки друг друга. Перед экспертами из шести областей - разработка, управление проектами, проектирование, консалтинг, тестирование и техническое сопровождение - был поставлен ряд вопросов, на основе которых первоначально были выявлены значимые факторы, а затем произведено их упорядочивание по степени важности. На основании этих данных были составлены рейтинговые шкалы новых факторов.

В уже существующие группы факторов формирования затрат добавлены:

Факторы продукта:

1) требуемый уровень безопасности, защиты программного продукта от взлома;

2) требуемый уровень эргономики;

3) необходимость перевода программного продукта на другие языки.

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

№3, 2008

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

Таблица 1

Оценка PRED по COCOMO II

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

PRED Значение

PRED(20) 45%

PRED(25) 60%

PRED(30) 65%

Таблица 2

Новые факторы формирования затрат

Наименование фактора Обозначение Описание

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

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

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

Возможности тестировщиков TCAP Отражает квалификацию тестировщиков проекта. Очень низкий уровень означает отсутствие опыта, очень высокий — большой опыт работы, знание системы, возможность локализации ошибок, вынесение предложений по их исправлению

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

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

Изменяемость затрат CCNG Отражает вероятность изменения затрат в ходе работы над проектом, сокращение финансирования. Номинальный уровень означает малую вероятность изменения затрат на проект. Сверхвысокий уровень означает высокую вероятность изменения затрат

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

Влияние со стороны внешних подразделений DEXT Отражает вероятность влияния на проект внешних подразделений: борьба за бюджеты, сотрудников или же наоборот содействие. Очень низкий уровень означает отрицательное влияние, очень высокий — положительное

Влияние со стороны рынка MEXT Отражает вероятность влияния на проект со стороны рынка: появление новых конкурентов, изменение ценовой политики. Очень низкий уровень означает отрицательное влияние, очень высокий — положительное

Влияние со стороны заказчика CEXT Отражает вероятность влияния на проект со стороны заказчика: сокращение бюджета, изменение условий. Очень низкий уровень означает отрицательное влияние, очень высокий — положительное

Влияние госу-царства / законодательства GEXT Отражает вероятность влияния на проект со стороны государства, законодательства. Очень низкий уровень означает отрицательное влияние, очень высокий — положительное

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

Факторы персонала:

1) возможности тестировщиков;

2) возможности документалистов;

3) возможности проектировщиков.

Большинство экспертов оценило

влияние персонала на проект следующим образом:

1) аналитики;

2) проектировщики;

3) разработчики;

4) тестировщики;

5) документалисты.

Порядок объяснялся последовательностью этапов, на которых вступали в работу специалисты выделенных категорий, а также тем, насколько серьезно решения специалистов влияло на систему в целом. Так, ошибки анализа и проектирования, гораздо более сложны и емки для исправления, чем ошибки тестирования или документирования. Критерии оценки для новых факторов были предложены по аналогии с уже существующими в модели СОСОМО II - с помощью процентов. 15% возможности тестировщика означают, что у него очень низкий уровень возможностей, 90% — очень высокий. Критериями оценки являются индивидуальные способности в данной области, эффективность, ответственность и коммуникабельность. Данный рейтинг не следует путать с факторами опыта работы с платформой, языком программирования или приложением - здесь оценивают личные характеристики, позволяющие работать с большей отдачей.

Практическая эксплуатация модели показала, что недостатком СОСОМО II является, в основном, учет внутренних факторов проекта, без указания внешних, которые, согласно экспертному

Экономика, Статистика и Информатика 65 №3, 2008

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

Внешние факторы:

1) изменяемость затрат;

2) недоступность ресурсов;

3) влияние со стороны внешних подразделений;

4) влияние со стороны рынка;

5) влияние со стороны заказчика;

6) влияние государства/законодательства.

Самым значительным фактором среди внешних эксперты выделили фактор недоступности ресурсов. Если для проекта не выделены нужные сотрудники, то проект не может быть завершен в срок. Чем этот риск больше, тем существенней становится влияние данного фактора на проект. На втором месте идет фактор изменяемости затрат - при сокращении бюджета менеджеру придется потратить ресурсы на перепланирование затрат, частичное сокращение функциональности, привлечение других, менее опытных сотрудников и т.п. Среди факторов влияния отмечается как наиболее значимый фактор влияния со стороны заказчика - при наличии конфликта проект может быть приостановлен, или же непонимание может привести к неточной выработке требований, и как следствие, к потере времени на разработку ненужной функциональности. Существенно могут повлиять на проект внешние подразделения, причем как в положительную, так и в отрицательную сторону. Влияние со стороны рынка и государство отражается не на всех проектах, но для ряда важных стратегических решений также должно приниматься в расчет. Описание факторов приведено в табл. 2.

Общее уравнение обновленной модели СОСОМО II — СОСОМО-Р] этапа пост-архитектуры после добавления новых факторов приобрело следующий вид:

Затраты = Л х РазмерЕ х Ме + Затраты1ииго[чел. - мес.]

где А - коэффициент масштаба, являющийся константой, первоначально равен 2,94, в дальнейшем может изменяться путем калибровки;

E - фактор издержек масштаба. E = B + 0,01 х (PREC + FLEX + + RESL + TEAM + PMAT)

B - коэффициент, является константой, первоначально равен 0,91, в дальнейшем может изменяться путем калибровки;

PREC — фактор предсказуемости;

FLEX - фактор гибкости разработки;

RESL - фактор риска;

TEAM - фактор команды;

PMAT- фактор зрелости процесса;

Затратыш(о - отражает затраты на код, генерируемый программой автоматически.

Mg - множитель поправки, который состоит из произведения факторов формирования затрат:

Me = RELY х DATA х CPLX х RUSE х DOCU х х TIME х STOR х PVOL х ACAP х PCAP х х PCON х APEX х PLEX х LTEX х TOOL х х SITE х SCED х SECR х ERGO х TRSL х х TCAP х DCAP х SCAP х CCNG х RCON х х DEXT х MEXT х CEXT х GEXT

где RELY — фактор надежности.

DATA — фактор размера базы данных.

CPLX - фактор сложности.

RUSE — фактор требуемой повторной используемости.

DOCU — фактор документирования требований.

TIME — фактор ограничения времени выполнения.

STOR — фактор ограничения оперативной памяти.

PVOL — фактор изменчивости платформы;

ACAP — фактор возможностей аналитика;

PCAP — фактор возможностей программиста;

PCON - фактор непрерывности персонала;

APEX — фактор опыта работы с приложением;

PLEX — фактор опыта работы с платформой;

LTEX — фактор опыта работы с языком и утилитами;

TOOL — фактор использования программных утилит;

SITE — фактор мультисетевой разработки;

SCED - фактор графика разработки;

SECR - фактор безопасности;

ERGO - фактор эргономики;

TRSL - фактор перевода;

TCAP — фактор возможностей те-стировщиков;

DCAP - фактор возможностей документалистов;

SCAP — фактор возможностей проектировщиков;

CCNG — фактор изменяемости затрат;

RCON - фактор недоступности ресурсов;

DEXT — фактор влияния внешних подразделений;

MEXT — фактор влияния рынка;

CEXT— фактор влияния заказчика;

GEXT — фактор влияния государства.

Автором была произведена перекалибровка модели, и получены коэффициенты для рейтинговых шкал факторов с учетом экспертных оценок и фактических данных по 56 проектам, находящимся в базе данных системы управления проектами ЗАО «Системы автоматизированного управления». Для проведения калибровки был выбран комбинированный метод, подразумевающий получение новых значений факторов, как путем экспертных оценок, так и с помощью регрессионного анализа, и дальнейшее объединение этих результатов по определенным алгоритмам, как наиболее удачно сочетающий в себе возможность объединения экспертных и полученных при практическом применении данных. В данном случае в качестве алгоритма объединения используется подход 10% взвешенного среднего, разработанный доктором Барри Боэмом, создателем модели COCOMO II [3]. Он заключается в том, что для получения новых значений факторов берется 90% значения экспертной оценки и 10% фактических данных. Боэм обосновывает выбор именно такого соотношения сравнением данных, полученных на основе экспериментов с соотношениями 40—60 и 25—75 - они получались гораздо менее точными.

Для проверки новой модели были использованы те же 40 проектов, по которым производилась оценка с помощью оригинальной модели COCOMO II.

На основании данных по расхождениям была произведена оценка показа-

№3, 2008В 66

I

Таблица 3

Оценка PRED по COCOMO II и COCOMO-PJ

PRED Модель COCOMO II Модель COCOMO-PJ

PRED(15) 32,50% 92,50%

PRED(20) 45% 95%

PRED(25) 60% 95%

PRED(30) 65% 95%

теля РКББ для определения процента оценок, которые были бы внутри 30%, 25%, 20% и 10% фактических значений. Результаты оценки скорректированной модели отражены в табл. 3. Рядом с ними для сравнения приведены результаты оценки по оригинальной модели СОСОМО II из табл. 1.

Согласно этим данным, откалибро-ванная модель с новыми факторами

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

Литература

1. Capers J. Software Estimating rules of thumb. 2007. http://www.itmpi.org/ default.aspx?pageid= 197

2. Орлов С. Технологии разработки программного обеспечения: Учеб. пособие. СПб.: Питер, 2003.

3. Barry W. Boehm. Software cost estimation with COCOMO II. Prentice Hall PTR, 2000.

Boehm B.W., Abts C., Chulani S. Software Development Cost Estimation Approaches - A Survey // University of Southern California, IBM Research.

Экономика, Статистика и Информатика

67

№3, 2008