Постархитектурный уровень

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

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

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

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

Оценка затрат на повторное использование компонентов в модели СОСОМО 2 рассчитывается по следующей формуле:

ESLOC = ASLOC ´ (АА + SU + 0.4 DM + 0.3 СМ + 0.3 1М)/100.

Здесь ESLOC – количество строк нового кода, ASLOC – количество строк повторно используемого кода, требующего изменений, DM – процент изменений в архитектуре системы, СМ – процент измененного кода, a IM – процент затрат на интеграцию повторно используемого программного обеспечения. Коэффициент SU зависит от затрат на адаптацию повторно используемых программных компонентов и колеблется в пределах от 50 (для сложного неструктурированного кода) до 10 (для грамотно написанного объектно-ориентированного кода). Коэффициент АА отображает затраты на начальную оценку возможности повторного использования компонентов. Его значение колеблется от 0 до 8. Показатель степени в формуле расчета затрат в модели СОСОМО 1 имеет три возможных значения, которые соотносятся с различными уровнями сложности проекта. С возрастанием уровня сложности проекта увеличивается значимость размера системы. Однако отрицательный эффект размера системы можно нивелировать с помощью организационных мероприятий, что учтено в модели СОСОМО 2. Здесь показатель степени рассчитывается с учетом пяти показателей, которые описаны в табл. 24.7. Они отсчитываются по шестибалльной шкале от низшего (5 баллов) до наивысшего (0 баллов) уровня. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени.

Таблица 24.7. Показатели, используемые при расчете показателя степени в модели СОСОМО 2

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

Для оценки показателя степени используются перечисленные ниже показатели проекта.

1. Новизна проекта. Это новый проект для организации, данный показатель имеет низкий уровень (оценивается в 4 балла).

2. Гибкость процесса разработки. Нет вмешательства заказчика – уровень показателя очень высокий (оценивается в 1 балл).

3. Анализ архитектуры системы и рисков. Анализ не был проведен – уровень данного показателя очень низкий (оценивается в 5 баллов).

4. Сплоченность команды. Команда разработчиков новая, информация о ней отсутствует – уровень этого показателя оценивается как обычный (3 балла).

5. Уровень развития процесса разработки. Определенное управление проектом имеет место – показатель оценивается как обычный (3 балла).

Сумма значений всех этих показателей составляет 16 баллов, поэтому значение показателя степени будет равно 1.17.

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

1. Характеристики программного продукта, которые определяются системными требованиями.

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

3. Характеристики персонала, которые учитывают опыт и возможности специалистов, работающих над проектом.

4. Характеристики проекта, учитывающие определенные параметры и показатели проекта разработки ПО.

Таблица 24.8. Проектные характеристики, формирующие стоимость проекта

В табл. 24.9 показан пример того, каким образом эти характеристики влияют на предварительную оценку затрат. Показатель степени 1.17, полученный в предыдущем примере, RELY, CPLX, STOR, TOOL и SCED являются основными характеристиками, формирующими стоимость проекта. Все другие характеристики имеют значение 1, поэтому не влияют на оценку затрат.

Таблица 24.9. Расчет оценки затрат

* DSI (Delivered Source Instructions) - количество инструкций в конечной программе.

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

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

Алгоритмические модели стоимости в планировании проекта

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

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

Стоимость проекта складывается из трех компонентов.

1. Стоимость целевых аппаратных средств, на которых будет функционировать разрабатываемая система.

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

3. Стоимость затрат на разработку системы.

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

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

Рис. 24.2. Проектные показатели и характеристики, учитываемые при расчете стоимости

В табл. 24.10 показаны аппаратные и программные средства, обеспечивающие реализацию характеристик А-Е, описанных на рис. 24.2. Стоимость данного проекта в соответствии с моделью СОСОМО 2 (без учета проектных характеристик (множителей), влияющих на формирование стоимости, см. предыдущий раздел) оценивается в 45 человеко-месяцев. Стоимость затрат на один человеко-месяц составляет $15 000.

Соответствующие множители, влияющие на формирование стоимости, учитывают ограниченность времени исполнения и объема памяти (показатели TIME и STORE), доступность средств поддержки системы разработки, таких, как кроссплатформенные компиляторы и т.п. (показатель TOOL), и опыт команды разработчиков (показатель LTEX). Для всех проектных характеристик множитель RELY (показатель надежности) равен 1.39; это означает, что для разработки надежной системы требуются дополнительные затраты.

Стоимость программного продукта (SC) вычисляется следующим образом:

SC = оценка затрат х RELY x TIME х STOR x TOOL х ЕХР х $15000.

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

Таблица 24.10. Параметры стоимости

Проектная характеристика Г обеспечивает самые низкие затраты на разработку системы. Здесь нет необходимости в дополнительных затратах на аппаратные средства, зато нужно нанимать новый персонал для работы по проекту. Если такой персонал уже имеется в наличии в организации-разработчике, тогда этот вариант будет наиболее выгодным и выбор следует остановить именно на нем. Если же нет, то наем нового персонала порождает дополнительные расходы и риски. Это может привести к тому, что преимущества в стоимости могут оказаться не такими значительными, как показано в табл. 23.10. В проекте с характеристикой В сэкономлено почти $50 000, при этом риск практически отсутствует. Менеджеры проектов с консервативным складом ума предпочтут этот вариант более рискованному варианту Г.

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