 |
Постархитектурный уровень
|
|
|
|
Для получения оценки на постархитектурном уровне используется такая же формула, как и для оценки на уровне предварительного проектирования. На этом уровне оценка будет более точной, для предварительной оценки затрат будут использоваться уже не семь, а семнадцать показателей.
Здесь при оценке количества строк программного кода учитываются два важных фактора.
• Возможность изменения системных требований. Следует учитывать повторные работы, которые необходимо выполнить вследствие изменения системных требований. Оценка этих работ выражается в количестве строк программного кода, которое необходимо изменить, и затем прибавляется к предварительной оценке размера системы.
• Степень повторного использования компонентов. Если степень повторного использования программных компонентов значительна, в оценку количества строк разрабатываемого кода необходимо внести поправки. Однако в [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. Здесь показатель степени рассчитывается с учетом пяти показателей, которые описаны в табл. 23.7. Они отсчитываются по шестибалльной шкале от низшего (5 баллов) до наивысшего (0 баллов) уровня. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени.
|
|
|
Таблица 23.7. Показатели, используемые при расчете показателя степени в модели СОСОМО 2
| Показатель | Пояснение |
| Новизна проекта | Отображает предыдущий опыт организации в реализации проектов данного типа. Очень низкий уровень этого показателя означает отсутствие опыта, наивысший уровень указывает на компетентность организации-разработчика в данной области ПО |
| Гибкость процесса разработки | Отображает возможность изменения процесса разработки ПО. Очень низкий уровень этого показателя означает, что процесс определен заказчиком заранее, наивысший – заказчик определил лишь общие задачи без указания конкретной технологии процесса разработки ПО |
| Анализ архитектуры системы и рисков | Отображает степень детализации анализа рисков, основанного на анализе архитектуры системы. Очень низкий уровень данного показателя соответствует поверхностному анализу рисков, наивысший уровень означает, что был проведен тщательный и полный анализ всевозможных рисков |
| Сплоченность команды | Отображает степень сплоченности команды и их способность работать совместно. Очень низкий уровень этого показателя означает, что взаимоотношения в команде сложные, а наивысший – что команда сплоченная и эффективная в работе, не имеет проблем во взаимоотношениях |
| Уровень развития процесса разработки | Отображает уровень развития процесса создания ПО в организации-разработчике. Оценка этого показателя основывается на вопроснике модели СММ (см. главу 25) |
|
|
|
Приведем пример. Предположим, организация-разработчик выполняет программный проект в той области, в которой у нее мало опыта разработок. Заказчик ПО не определил технологический процесс, который будет использовать при создании программного продукта, а также не выделил в плане работ времени на анализ возможных рисков. Для создания программной системы необходимо сформировать новую команду специалистов. Организация-разработчик недавно привела в действие программу усовершенствования технологического процесса разработки ПО и может котироваться как организация второго уровня в соответствии с моделью оценки уровня развития СММ (об этой модели речь идет в главе 25). Для оценки показателя степени используются перечисленные ниже показатели проекта.
1. Новизна проекта. Это новый проект для организации, данный показатель имеет низкий уровень (оценивается в 4 балла).
2. Гибкость процесса разработки. Нет вмешательства заказчика – уровень показателя очень высокий (оценивается в 1 балл).
3. Анализ архитектуры системы и рисков. Анализ не был проведен – уровень данного показателя очень низкий (оценивается в 5 баллов).
4. Сплоченность команды. Команда разработчиков новая, информация о ней отсутствует – уровень этого показателя оценивается как обычный (3 балла).
5. Уровень развития процесса разработки. Определенное управление проектом имеет место – показатель оценивается как обычный (3 балла).
Сумма значений всех этих показателей составляет 16 баллов, поэтому значение показателя степени будет равно 1.17.
|
|
|
Проектные характеристики, используемые для уточнения предварительной оценки затрат на постархитектурном уровне (табл. 23.8), разбиваются на четыре группы.
1. Характеристики программного продукта, которые определяются системными требованиями.
2. Характеристики аппаратных средств, представляющие собой ограничения, накладываемые на разрабатываемое ПО выбранной платформой вычислительных средств.
3. Характеристики персонала, которые учитывают опыт и возможности специалистов, работающих над проектом.
4. Характеристики проекта, учитывающие определенные параметры и показатели проекта разработки ПО.
Таблица 23.8. Проектные характеристики, формирующие стоимость проекта
| Характеристики программного продукта | |
| RELY | Требуемая надежность системы |
| CPLX | Сложность системных модулей |
| DOCU | Объем необходимой документации |
| DATA | Размер используемой базы данных |
| RUSE | Процент повторного использования компонентов |
| Характеристики аппаратных средств | |
| TIME | Показатели, ограничивающие время исполнения |
| PVOL | Возможность изменения платформы разработки |
| STOR | Ограничение объема памяти |
| Характеристики персонала | |
| АСАР | Способности лиц, выполняющих анализ проекта |
| PCON | Сплоченность команды разработчиков |
| РЕХР | Опыт программирования в данной области ПО |
| РСАР | Способности программистов |
| АЕХР | Опыт аналитика проекта в данной области ПО |
| LTEX | Опыт применения данного языка программирования и средств разработки |
| Характеристики проекта | |
| TOOL | Использование вспомогательных программных средств |
| SCED | Уплотнение графика работ |
| SITE | Количество работ, выполняемых в разных местах, и качество коммуникаций |
В табл. 23.9 показан пример того, каким образом эти характеристики влияют на предварительную оценку затрат. Я взял показатель степени 1.17, полученный в предыдущем примере, и предположил, что RELY, CPLX, STOR, TOOL и SCED являются основными характеристиками, формирующими стоимость проекта. Все другие характеристики имеют значение 1, поэтому не влияют на оценку затрат.
|
|
|
Таблица 23.9. Расчет оценки затрат
| Значение показателя степени | 1.17 |
| Размер системы (с учетом повторного использования компонентов и возможного изменения требований) | 128 000 DSI* |
| Начальная оценка по модели СОСОМО без учета проектных характеристик | 730 человеко-месяцев |
| Надежность системы | Очень высокая, множитель 1.39 |
| Сложность системных модулей | Очень высокая, множитель 1.3 |
| Ограничение объема памяти | Высокое, множитель 1.21 |
| Использование вспомогательных средств | Низкое, множитель 1.12 |
| График работ | Ускоренный, множитель 1.29 |
| Уточненная оценка по модели СОСОМО | 2306 человеко-месяцев |
| Надежность системы | Очень низкая, множитель 0.75 |
| Сложность системных модулей | Очень низкая, множитель 0.75 |
| Ограничение объема памяти | Нет, множитель 1 |
| Использование вспомогательных средств | Очень высокое, множитель 0.72 |
| График работ | Нормальный, множитель 1 |
| Уточненная оценка по модели СОСОМО | 295 человеко-месяцев |
* DSI (Delivered Source Instructions) - количество инструкций в конечной программе. - Прим. ред.
В этом примере я присвоил максимальные и минимальные значения ключевым характеристикам с тем, чтобы показать, каким образом они влияют на оценку затрат. Значения были взяты из руководства по модели СОСОМО 2 [41]. Вы можете сами убедиться, что высокие значения для характеристик, влияющих на формирование стоимости, привели к увеличению оценки затрат более чем в три раза, тогда как при низких значениях оценка затрат была снижена почти в три раза по сравнению с начальной. Этот пример показывает отличия разных типов проектов, а также трудности переноса опыта разработок из одной области ПО в другую.
Хотя формула, предложенная разработчиками модели СОСОМО, отображает их опыт разработчиков и основана на большой базе данных, однако я полагаю, что эта модель излишне сложна для практического использования. Слишком много показателей необходимо учитывать и слишком широкие рамки для определения их значений. Таким образом, каждый, кто хочет воспользоваться этой моделью, должен выверить и приспособить ее к своим данным, накопленным при реализации предыдущих проектов, так как именно они дадут информацию о тех частных обстоятельствах, которые могут оказать влияние на ход выполнения данного проекта. Некоторые организации накопили достаточно информации о прошлых проектах в той форме, которая способна проверить и настроить модель СОСОМО.
|
|
|
23.3.2. Алгоритмические модели стоимости в планировании проекта
Алгоритмические модели стоимости применяются для сравнения различных инвестиций в целях снижения стоимости проекта. Это особенно важно в тех случаях, когда принимаются решения в отношении покупки аппаратных или программных средств либо возникает необходимость найма новых сотрудников с особыми навыками, нужными для реализации проекта.
В качестве примера рассмотрим встроенную систему для управления экспериментом, который будет проводиться в космосе. Оборудование для проводимых в космосе экспериментов должно быть предельно надежным и подлежит строгим весовым ограничениям. Поэтому, например, может появиться необходимость свести к минимума количество чипов на монтажной плате. Если взять для оценки модель СОСОМО, то множители, зависящие от ограничений в проекте и надежности, будут иметь значение больше единицы.
Стоимость проекта складывается из трех компонентов.
1. Стоимость целевых аппаратных средств, на которых будет функционировать разрабатываемая система.
2. Стоимость платформы (вычислительная техника плюс программное обеспечение), используемой для разработки системы.
3. Стоимость затрат на разработку системы.
На рис. 23.2 представлены некоторые проектные показатели и характеристики, которые могут учитываться при расчете стоимости. Например, снижение стоимости ПО может потребовать больших затрат на целевые аппаратные средства или вложения дополнительных средств в усовершенствованные инструменты разработки.
Дополнительные расходы на аппаратные средства в данном случае допустимы, так как разрабатываемая система является узкоспециализированной и не предназначена для массовой продажи. Если же аппаратные средства встраивается в коммерческие продукты, то дополнительные вложения в целевые аппаратные средства (для снижения стоимости ПО) используются редко, потому что это повышает цену продаваемого продукта.
Рис. 23.2. Проектные показатели и характеристики, учитываемые при расчете стоимости
В табл. 23.10 показаны аппаратные и программные средства, обеспечивающие реализацию характеристик А-Е, описанных на рис. 23.2. Стоимость данного проекта в соответствии с моделью СОСОМО 2 (без учета проектных характеристик (множителей), влияющих на формирование стоимости, см. предыдущий раздел) оценивается в 45 человеко-месяцев. Стоимость затрат на один человеко-месяц составляет $15 000.
Соответствующие множители, влияющие на формирование стоимости, учитывают ограниченность времени исполнения и объема памяти (показатели TIME и STORE), доступность средств поддержки системы разработки, таких, как кроссплатформенные компиляторы и т.п. (показатель TOOL), и опыт команды разработчиков (показатель LTEX). Для всех проектных характеристик множитель RELY (показатель надежности) равен 1.39; это означает, что для разработки надежной системы требуются дополнительные затраты.
Стоимость программного продукта (SC) вычисляется следующим образом:
SC = оценка затрат х RELY x TIME х STOR x TOOL х ЕХР х $15000.
Проекту с характеристикой А соответствует стоимость разработки системы с уже имеющимся персоналом и средствами поддержки. Проекты с другими характеристиками требуют расходов либо на аппаратные средства, либо на наем нового персонала (с соответствующими расходами и степенью риска). На примере проекта с характеристикой Б видно, что модернизация аппаратных средств не обязательно снизит затраты, так как множитель, учитывающий опыт команды разработчиков, в этом случае будет очень весомым. Также видно, что модернизация только памяти окажется более эффективной, чем усовершенствование всей вычислительной системы.
Таблица 23.10. Параметры стоимости
| Характеристика | RELY | STOR | TIME | TOOL | LTEX | Общие затраты | Стоимость ПО | Стоимость аппаратных средств | Итоговая стоимость |
| А | 1.39 | 1.06 | 1.11 | 0.86 | 949 393 | 100 000 | 1 049 393 | ||
| Б | 1.39 | 1.12 | 1.22 | 1 313 550 | 120 000 | 1 402 025 | |||
| В | 1.39 | 1.11 | 0.86 | 895 653 | 105 000 | 1 000 653 | |||
| Г | 1.39 | 1.06 | 1.11 | 0.86 | 0.84 | 769 008 | 100 000 | 897 490 | |
| Д | 1.39 | 0.72 | 1.22 | 844 425 | 220 000 | 1 044 159 | |||
| Е | 1.39 | 1.12 | 0.84 | 851 180 | 120 000 | 1 002 706 |
Проектная характеристика Г обеспечивает самые низкие затраты на разработку системы. Здесь нет необходимости в дополнительных затратах на аппаратные средства, зато нужно нанимать новый персонал для работы по проекту. Если такой персонал уже имеется в наличии в организации-разработчике, тогда этот вариант будет наиболее выгодным и выбор следует остановить именно на нем. Если же нет, то наем нового персонала порождает дополнительные расходы и риски. Это может привести к тому, что преимущества в стоимости могут оказаться не такими значительными, как показано в табл. 23.10. В проекте с характеристикой В сэкономлено почти $50 000, при этом риск практически отсутствует. Менеджеры проектов с консервативным складом ума предпочтут этот вариант более рискованному варианту Г.
Приведенный анализ показал важность такого показателя, как опыт персонала. Если организация наймет квалифицированных сотрудников с большим опытом, это может значительно снизить стоимость проекта. Данный показатель напрямую связан с факторами производительности, описанными в разделе 23.1. Этот пример также показывает, что вложения в новые аппаратные средства могут оказаться не слишком выгодными. Обычно такую стратегию предпочитают программисты, которые любят работать с новыми системами. Однако недостаток опыта работы с новыми системами в данном случае может имеет более сильное отрицательное влияние на стоимость проекта, чем те преимущества, которые ожидаются от приобретения новых аппаратных средств.
|
|
|
