Сравнение методов оценки стоимости проектов по разработке информационных систем

Программа конференции

Контракты по разработке информационных систем и оценка проектов

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

• Плохое управление проектом
• «Плывущие»  требования
• Неправильная оценка проекта

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

«Плывущие»  требования

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

• Постепенное понимание заказчиком того, что же ему на самом деле нужно
• Изменение бизнеса заказчика за время реализации проекта

Понятны и негативные следствия плывущих требований:

• Разногласия между заказчиком и поставщиком
• Превышения сроков
• Работа, сделанная впустую.
• Превышение бюджетов и финансовые потери

Неправильная оценка проекта

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

• Отсутствие опыта или методики оценки проекта
• Непредвиденные проблемы в используемых средствах и компонентах
• Непонимание ключевых технических проблем проекта

Контрактная сторона вопроса

Естественно, все вышеописанные проблемы в первую очередь упираются в деньги. А раз в деньги, то, значит, и в контракты, по которым эти деньги выплачиваются (или, не приведи господь, не выплачиваются). Значит, важно составить контракт так, чтобы обе стороны выигрывали. При этом, на наш взгляд, вопрос упирается в едницу имерения контракта.

Наиболее популярые единицы измерения – время и проект.

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

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

Вввиду всего вышесказанного, зотелось бы иметь едницу измерения проекта такую, которая:

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

Методы оценки размера проектов

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

• Методы микрооценки основаны на точном знании процесса. Такова,  например, Oracle AIM и оценки трудоемкости для него. В любом случае, когда для построения оценки необходимо построение разбивки работ и оценка каждой индивидуальнрой работы (разделяй и властвуй), метод является методом микрооценки
• Методы макрооценки, основанные на функциональных требованиях и/или продукте. Таковы методы функциональных точек и методы тпа СОСОМО.

В данном докладе мы не будем рассматривать методы микрооценки. Мы рассмотрим с позиций, приведенных выше. Следующие методы макрооценки:

• IFPUG FPA
• COCOMO II
• модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году
• FPA mkII

Основные модели для определения объемов работ при разработке информационных систем

Вероятно, одним из наиболее известных моделей данного рода является конструктивная  модель стоимости (Constructive Cost Model  – COCOMO), разработанная в конце 70х годов Барри Боэмом (Barry Boehm). Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и «классом» проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.

Базовый тип модели COCOMO учитывает только класс проекта – естественный, полуинтегрированный, «встроенных систем». Естественные проекты – относительно маленькие и разрабатываются командами, знакомыми с прикладной областью.  Полуинтегрированные проекты – системы среднего размера и сложности, разрабатываемые группами разработчиков с различным опытом. Проекты «встроенных систем» выполняются при значтельных аппаратных, программных и организационных ограничениях.

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

Существенным недостатком данной модели является ее основанность на тысячах условных строк кода, как метрике размера программного комплекса. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем. Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), было опубликовано несколько ревизий метода.

Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от  FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании.

Другими аналогичными методами, которые мы здесь не рассматриваем, являются Feature Points, разработанный Кэйперсом Джонсом (Capers Jones) и 3D Points, разработанный в компаниии Боинг (Boeing).

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

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

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

Параметры для сравнения основных моделей для определения объемов работ при разработке информационных систем

Перечислим те параметры, по которым можно сравнить описанные выше модели.

Тип модели

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

Доступность репозиториев

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

Время применения

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

Независимая оценка трудоемкости и времени

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

Учет факторов размера системы

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

Непрерывная зависимость от сложности проекта

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

Учет функциональной сложности

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

Учет нефункциональных требований к системе

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

Поддержка различных жизненных циклов и разбиения по стадиям жизненного цикла

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

Учет  степени  новизны

Модель может позволять учитывать степень новизны системы – абсолютной либо для конкретных разработчиков.

Учет использования в разработке типовых элементов

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

Учет реинжиниринга или конверсии

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

Учет интеграции готовых коммерческих продуктов

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

Учет жесткости требований

Желательно, чтобы  модель отражала степень жесткости требований к системе. Это связано с тем фактом, что жесткость требований к системе повышает трудоемкость ее разработки.

Учет качества управления проектом, организационных факторов, инфраструктурных факторов, персонала

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

Учет зависимости трудоемкости от средств разработки

Желательно, чтобы  модель отражала зависимость трудоемкости от средств разработки.

Учет влияния графика на трудоемкость

Желательно, чтобы  модель отражала возрастание трудоемкости разработки в более сжатые сроки.

Сравнение моделей для определения объемов работ при разработке информационных систем

В соответствии с вышеизложенным, главными факторами при выборе модели должны являться:

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

Данные факторы для анализируемых нами моделей сведены в следующей таблице (Таблица 1).

Таблица 1 – Основные параметры качества для анализируемых моделей

Таблица 2 – Учет требований к системе в моделях

Проанализирум подробнее модели на основе этих факторов.

Время применения и учет факторов размера системы

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

  Тип модели и доступность репозиториев

Методика Госкомтруда и COCOMO 2.0 являются закрытыми, а FPA IFPUG4.1 и MK II FPA­– открытыми. В то же время авторам неизвестны открытые репозитории статистики MK II FPA. Ввиду последнего обстоятельства, использование MK II FPAв данном проекте представляется сомнительным, несмотря на все остальные преимущества модели.

Учет функциональной сложности

Функциональная сложность в моделях COCOMO 2.0 и FPA IFPUG 4.1 оценивается на основе подсчета функциональных точек. Таким образом, в этом смысле эти две модели аналогичны.

Чтобы сравнить их с методикой Госкомтруда, разберем последнюю несколько подробнее. По этой методике, приближенная общая трудоемкость разработки  ПС  (

) рассчитывается по формуле

,

где

  - базовая трудоемкость разработки ПС;

  - коэффициент сложности ПС.

  - поправочный коэффициент, учитывающий конкретные условия и средства разработки ПС.

Базовая трудоемкость разработки ПС 

  определяется по таблице в зависимости от группы сложности ПС, и от объема ПС (

).

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

Группа сложности  ПС определяется в зависимости от наличия или отсутствия у разрабатываемого ПС одной  или  нескольких из 11 основных характеристик,  приведенных в этой таблице.

Таблица 3 – Таблица зависимости группы сложности ПС от их характеристик

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

Общий объем разрабатываемого ПС 

   определяется по формуле:

где

  - объем i-й функции ПС;

n - общее число функций ПС.

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

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

Таблица 4 – Каталог функций программных средств ЭВМ

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

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

В нижеприведенной таблице вседено сравнение методик по остальным параметрам.

Выводы

В соответствии с вышеизложенным, мы рекомендуем применение методик, основанных на методе функциональных точек IFPUG FPA. При этом собственно IFPUG FPA наиболее предпочтительно применять на стороне заказчика, а СОСОМО II  – на стороне разработчика, так как для заказчика разница в конкретных условиях разработки не важна, а для разработчика – важна.

Версия для печати