И. Соммервилл - Инженерия программного обеспечения (1133538), страница 126
Текст из файла (страница 126)
Следует учитывать повторные работы, которые необходимо выполнить вследствие изменения системных требований. Оценка этих работ выражается в количестве строк программного кола, которое необходимо изменить, и затем прибавляется к предварительной оценке размера системы. ° Степень яэамэрнэго исяааыовпяил качяокенжав. Если степень повторного использования программных компонентов значительна, в оценку количества строк разрабатываемого кода необходимо внести поправки. Однако в [309] показано, что расходы на повторное использование компонентов не всегда линейно зависят от размера этих компонентов, так как требуют затрат на их подбор и на то, чтобы разобраться с их возможностями и интерфейсами; кроме того, могуг потребоваться затраты па внесение изменений в эти компоненты.
Оценка затрат на повторное использование компонентов в модели СОСОМО2 рассчитывается по следующей формуле: ЕЗЕОС = АЗЕОС Х (АА + 80 + 0 4 ОМ + 0 3 СМ + 0 3 (М)/100. Здесь ЕЗЕОС вЂ” количество строк нового кода, А8(.ОС вЂ” количество строк повторно используемого кода, требующего изменений, ОМ вЂ” процент изменений в архитектуре системы, СМ вЂ” процент измененного кода, а )М вЂ” процент затрат на интеграцию повторно используемого программною обеспечения. Коэффициент 80 зависит от затрат на адаптацию повторно используемых программных компонентов и колеблется в пределах от 50 (для сложного неструктурированного кода) до 10 (для грамотно написанного объектноориентированного кода).
Коэффициент АА отображает затраты иа начальную оценку возможносги повторного использования компонентов. Его значение колеблется от О до 8. Показатель степени в формуле расчета затрат в мелели СОСОМО 1 имеет три возможных значения, которые соотносятся с различными >ровиями сложности проелта. С возрастанием уровня сложности проекта увеличивается значимость размера системы.
Однако отрицательный эффект размера системы можно нивелировать с помощью организационных мероприятий, что учтено в' модели СОСОМО2. Здесь показатель степени рассчитывается с учетом пяти показателей, которые описаны в табл. 23.7. Онн отсчитываются по шестнбалльной шкале от низшего (5 баллов) до наивысшего (О баллов) уровня. Значения показателей суммируются, сумма делится на 100, результат прибавляется к числу 1.01, после чего получается значение показателя степени. Таблица 23.7.
Показатели, используемые цри расчете показателя степени в модели СОСОМО 2 Пояснение Показатель Новизна проекта Отображает предыдущий опыт организации в реализации проек. тов данного типа. Очень низкий >ровень этого показателя овна. част отсутствие опыта, наивысший уровень указывает па комис. тентпость организации-разработчика в данной области ПО 23. Оценка стоимости программного продукта 485 Окончание шаба.
23. 7 Показатель Пояснение гибкость процесса раз- работки Отображает возможность изменения процесса разработки ПО. Очень низкий уровень этого показателя означает, что процесс определен заказчиком заранее, наивысший — заказчик опреде- лил лишь общие задачи без указания конкретной технологии процесса разработки ПО Отображает степень детализации анализа рисков, основанного на анализе архитектуры системы. Очень низкий уровень данно- го показателя соответствует поверхностному анализу рисков, наивысший уровень означает, что был проведен тщательный и полный анализ всевозможных рисков Анализ архитектуры системы и рисков Сплоченность коианды Отображаетсгепеньсплоченности команды иихспособность работать совместно.
Очень низкий уровень этого показателя означает, что взаимоотношения в команде сложные, а наивыс- н~ий — что команда сплоченная и эффективная в работе, не имеет проблем во взаимоотношениях Отобралшет уровень развития процесса создания ПО в органи- зации-разработчике.' Оценка этого показателя основывается на вопроснике модели СММ (см, главу 25) Уровень развития про- цесса разработки 1. Новизна яроехэю.
Зто новый проект для организации, данный показатель имеет низкий уровень (оценивается в 4 балла). 2. Гкйикта ярокесса )зьз)ыбожки. Нет вмешательства заказчика — уровень показателя очень высокий (оценивается в 1 балл). 3. Анаькз архиэмкму!Эы омтяечм и рисков. Анализ не был проведен — уровень данного по. казатсля очень низкий (оценивается в 5 баллов).
4. Сллочениесэм команды. Команда разработчиков новая, информация о ней отсутствует — уровень этого показателя оценивается как обычный (3 балла). 5, Уровень укмвкмкя я)мкьсга рлзрлбээжк. Определенное управление проектом имеет иесто — показатель оценивается как обычный (3 балла). Сумма значений всех этих показателей составляет 16 баллов, поэтому значение показателя степени будет равно 1.17. Проектные характеристики, используемые для уточнения предварительной оценки затрат на постархитеатурном уровне (табл.
23.8), разбиваются на четыре группы. Приведем пример. Предположим, организация.разработчик выполнлст программный про. ект втой области, а которой у нее мало опыта разработок Закаэчик ПО не определил техноло. гический процесс, который будет использовать при создании программного продукта, а также не выделил в плане работ времени на анализ возможных рисков. Для создания программной системы необходимо сформировать новую команду специалистов. Организация-разработчик недавно привела в действие программу усовершенствования технологического процесса разработки ПО и может котироваться как оршннзация второго уровня в соотас гствии с моделью оценки уровня развития СММ (об этой модели речь идет в главе 25).
Для оценки показателя степени используются перечисленные ниже показатели проекта. 486 т4асть ~Ч. Управление 1. Характеристики программного продукта, которые определяются систеиными требованияии. 2. Характеристики аппаратных срелств. представляющие собой ограничения, накладываемые на разрабатываемое ПО выбранной платформой вычислительных средств. 3.
Характеристики персонала, которые учитывают опыт и возможности специалистов, работающих над проекгои. 4. Характеристики проекта, учитывающие определенные параметры и показатели проекта разработки ПО. Таблица 2$.8. Проектные характеристики, формирующие стоимость проекта Характеристики программного продукта ЕЕ1Х СРЕХ Характеристики Т1МЕ аппаратных средств РЧОЕ РТОВ Характеристики персонала АСЛР РСО ч' РЕХР РСАР Характеристики проекта ТООЕ ВАСЕВ ЯТЕ В табл. 25.9 показан пример того, каким образом эти характеристики влияют на предварительную оценку затрат.
Я взял показатель степени 1.17, полученный в предыдущеи примере. н прслположнл, что ЯЕ1.У, СР1Х, ЗТОй, Т001. н ЗСЕР являются основными ха. ракгеристикачи, формирующими стоимость проекта. Все другие характеристики имеют значение 1, поэтому не влияют па оценку затрат. 11ОСС ВАТА ВСЗЕ Требуемая надежность системы Сложность системных модулей Объем необходимой документации Размер используемой базы данных Процент повторного использования коьшонентов Показатели, ограничивающие время исполнения Возможность изменения платформы разработки Ограничение объема памяти Способности лиц, выполняющих анализ проекта Сплочснностькоманды разработчиков Опыт программирования в данной области ПО Способности программистов Опыт аналитика проекта в данной области ПО Опыт применения данного языка программирования и средств разработки Использование вспомогательных программных средств Уплотнение графика работ Количество работ, выполнлемых в разных местах, и качест.
во коммуникаций 2$. Оценка стоимости программного продукта 487 Таблица 2$.9. Расчет оценки затрат 1.17 Значение показателя степени 128 000 1е$1з Размер системы (с учетом повторного использования компонентов и возможного изменения требований) Начальная оценка по модели СОСОМО без учета про ектпьпг характеристик 730 человеко-месяцев Очень высокая, множитель 1.39 Очень высокая, множитель 1г$ Высокое, множитель 1.21 Низкое, множитель 1.12 Надежность системы Сложность системных модулей Ограничение объема памяти Использование вспомогательных средств График работ Уточненная оценка по модели СОСОМО Ускоренный, множитель 1.29 230бчеловеко-месяцев Очень низкая, множитель 0.75 Очень низкая, множитель 0.75 Нет, множитель 1 Очень высокое, множитель 0.72 Надежность системы Сложность системных модулей Ограничение объема памяти Использование вспомогательных средств График работ Уточненная оценка по моделя СОСОМО Нормальный, множитель 1 295 человеко-месяцев 23.3.2.
Алгоритмические модели стоимости в планировании проекта Алгоритмические модели стоимости применяются для сравнения различных инвестиций в целях снижения стоимости проекта. Это особенно важно в тех случаях, когда прн- ! 03! !г!е!!оеео!Боипе гэеепиьопе) - кооичееома икеоерункиге е коне гной «роеракче. Призе. рел.
В этол! примере я присвоил максимальные и минимальные значения ключевым характеристикам с тем, чтобы показать, каким образом они влияют на оценку затрат. Значения были взяты из руководства по модели СОСОМО 2 [41!. Вы можете сален убедиться, что высокие значения для характеристик, влияющих на формирование стоимости, привели к увеличению оценки затрат более чем в три раза, тогда как при низких значениях оценка заграт была снижена почти в три раза по сравнению с начальной. Этот пример показывает отличия разных типов проектов, а также трудности переноса опыта разработок нз одной области ПО в другую. Хотя формула, предложенная разработчиками модели СОСОМО. отображает их опыт рэзработчилов и основана на большой базе данных, однако я полагаю, что эта модель излишне сложна для практическою использования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
