Следует отметить, что затраты на этапе повторного использования, как и при автоматической генерации кода модулей (например, при использовании концепции генетического программирования в мультиверсионности), не всегда равны нулю. Возникают трудозатраты на этапе работы с существующим кодом и при разработке соответствующего интерфейса. Затраты на переписывание системы могут быть меньшими, чем продолжение ее поддержки и сопровождения (по причине энтропии структуры). Однако переписывание старой системы может быть более дорогостоящим, чем создание «нового» К-го варианта системы.
Известно требование, согласно которому точка экономической безубыточности достигается в результате изменения 20% кода; после прохождения этой точки повторное использование кода не будет эффективным.
Однако следует отметить, что многие постановки задач многоатрибутивного выбора используют качественную информацию, исключение которой из оптимизационного процесса может привести к неоптимальному (и, возможно, неверному) решению. Таким образом, рассматриваемый подход к решению задачи многоатрибутивного выбора с использованием драйверов затрат на программную систему, позволяет проводить проектировщику анализ ситуаций, когда некоторая часть всей доступной ему информации может быть как качественной, так и не полной.
Список использованных источников
1. Боэм, Б. Характеристики качества программного обеспечения / Б. Боэм, Дж. Браун, Х. Каспар, М. Липов, Г. Мак-Леод, М. Мерит. - М.: Мир, 1981. - 208 с.
2. Боэм, Б.У. Инженерное проектирование программного обеспечения / Пер. с англ. - М.: Радио и связь, 1985. -512 с.
3. Липаев, В.В. Надежность программных средств/ В.В. Липаев.- М.:СИНТЕГ, 1998. -232 с.
4. Майерс, Г. Надежность программного обеспечения: Пер. с англ./ Под ред. В.Ш.Кауфмана. - М.: Мир, 1980. - 360 с.
5. Соммервилл, И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ.- М.: Издательский дом «Вильямс», 2002.
6. Царев, Р.Ю. Программно-информационные технологии формирования критичных по надежности систем управления. Монография/ Р.Ю. Царев, М.А. Русаков, С.А. Шабалин// СПб.: Ин-фоДа, 2005. - 172 с.
7. Царев, Р.Ю. Многокритериальное принятие решений при создании отказоустойчивого программного обеспечения / Вестник НИИ СУВПТ. - Вып.2. - Красноярск: НИИ СУВПТ, 1999. - С. 190-194.
УДК 004.14
Ю.А. Нургалеева, Е.В. Курманова, А.А. Ромашова
Сибирский Федеральный Университет Институт Космических и Информационных Технологий г. Красноярск, Россия
ПОДХОД К ОЦЕНКЕ СТОИМОСТИ ПРОГРАММНОГО ПРОДУКТА НА ЭТАПЕ ПОСТАРХИТЕКТУРЫ
В работе на основе концепции COTS-сопровождения архитектурного программирования предлагается модель этапа постархитектуры для оценки стоимости N-вариантного программного обеспечения систем управления и обработки информации, которая используется в период, когда уже сформирована архитектура системы, и выполняется дальнейшая разработка различных структур программного продукта.
Основное уравнение постархитектурной модели является развитием уравнения модели СОСОМО II и имеет следующий вид [1]:
ЗАТРАТЫ = А х Rreq х РАЗМЕР8 х Мр + ЗАТРАТЫаи0о [чел. - мес]
где коэффициент Kreq учитывает изменения в требованиях при формировании V-спецификаций на N-вариантные компоненты ПО, а показатель В отражает нелинейную зависимость затрат от размера проекта (размер выражается в KLOC).
Изменчивость требований при формировании N-вариантных компонент программных систем приводит к повторной работе [2], требуемой для учета предлагаемых изменений. Оценка их влияния выполняется по формуле:
Kreq = L + (BRAK/100),
где BRAK — процент кода, отброшенного (модифицированного) из-за изменения требований.
Размер проекта и продукта определяют по выражению: РАЗМЕР = PA3MEPnew + PA3MEPreuse [KLOC],
где: PA3MEPnew — размер нового (создаваемого) программного кода; PA3MEPreuse — размер повторно используемого программного кода N-вариантных компонент ПО.
Фактор A отражает стоимость решения о том, может ли ПО быть повторно используемым в n-вариантных структурах программной системы. Он зависит от размера требуемого тестирования и поддержки n-вариантного исполнения (величина изменяется от 0 до 8). Для определения множителя поправки Мр основного уравнения используют 17 факторов затрат, которые могут быть разбиты на 4 категории [3]:
Факторы продукта: требуемая надежность ПО - rely; размер базы данных - data; сложность продукта - cplx; требуемая повторная используемость — ruse; документирование требований жизненного цикла - docu.
Факторы платформы исполнения (виртуальной машины): ограничения времени выполнения -time; ограничения оперативной памяти - stor; изменчивость платформы - pvol.
Факторы персонала: возможности аналитика - асар; возможности программиста - рсар; опыт работы с приложением - аехр; опыт работы с платформой - рехр; опыт работы с языком и утилитами - ltex; непрерывность персонала - pcon.
Факторы проекта: использование программных утилит - tool; мультисетевая разработка - site; требуемый график разработки - sced.
Для каждого фактора определяется оценка (по 6-балльной шкале). На основе оценки для каждого фактора по таблице Боэма определяется множитель затрат eMj (/=1,.. .,17). Перемножение всех j множителей затрат дает множитель поправки постархитектурной модели.
Значение Мр отражает реальные условия выполнения программного проекта и позволяет троекратно увеличить (уменьшить) начальную оценку затрат. От оценки затрат легко перейти к стоимости проекта.
После определения затрат и стоимости можно оценить длительность разработки N-вариантной структуры. Модель COCOMO II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:
Длительноеmb(TDEV) = [з,0 х (ЗАТРАТЫ)(0 33+0 2(В 101))]х SCEI)P^nlüge [мес\
где B - ранее рассчитанный показатель степени.
Scedpercentage - процент увеличения (уменьшения) номинального графика. Если нужно определить номинальный график, то принимается scedpercentage = 100 и правый сомножитель в уравнении обращается в единицу.
Следует отметить, что комплексная модель оценки стоимости ограничивает диапазон уплотнения/растягивания графика (от 75% до 160%). Если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска. Зависимость между затратами и количеством разработчиков носит нелинейный характер [4]. Часто увеличение количества разработчиков приводит к возрастанию затрат, т.к. увеличивается время на обучение сотрудников, согласование совместных решений; возрастает время на определение интерфейсов между частями программной системы, особенно между N-вариантными структурами программной системы.
Модель COCOMO II явно утверждает, что длительность проекта является функцией требуемых затрат. Количество людей, требуемых на этапе планирования и формирования требований, достаточно мало. На этапах проектирования и кодирования потребность в увеличении команды возрастает, после окончания кодирования и тестирования численность необходимых сотрудников достигает минимума.
Список использованных источников
1. Орлов, С.А. Технологии разработки программного обеспечения/ С.А. Орлов.- СПб.: Питер, 2002.- 326 с.
2. Соммервилл, И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ.- М.: Издательский дом «Вильямс», 2002.- 643 с.
3. Боэм, Б.У. Инженерное проектирование программного обеспечения / Пер. с англ. - М.: Радио и связь, 1985. -512 с.
4. Липаев, В.В. Надежность программных средств/ В.В. Липаев.- М.:СИНТЕГ, 1998. -232 с.
УДК 681.3
Е.К. Гринин
Сибирский федеральный университет г. Красноярск, Россия
СРАВНЕНИЕ LAM И MADM МЕТОДОВ МНОГОАТРИБУТИВНОГО ПРИНЯТИЯ РЕШЕНИЙ ДЛЯ ФОРМИРОВАНИЯ МУЛЬТИВЕРСИОННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
В мультиверсионном программном обеспечении каждый модуль имеет несколько версий, в которых реализованы различные алгоритмы решения одной и той же задачи. Модули выполняются последовательно, версии одного модуля - параллельно. Поскольку дополнительные версии требуют дополнительных ресурсов, то существует задача выбора оптимального варианта.
Метод LAM представляет линейный компенсирующий процесс для взаимодействия и комбинации атрибутов [1]. В качестве входных данных процесса используется только порядок предпочтения. Это требование к данным позволяет избежать масштабирования атрибутов качественного типа. Метод MADM является его модификацией. Рассмотрим их работу на примере:
A T V C
A1 500 60 14000
A2 800 100 12000
A3 300 50 10000
A4 100 30 15000
В данной таблице представлены различные версии (А1 - А4) решения определённой задачи с характеристиками (атрибутами): Т, м.сек - время выполнения; V, МБ - требуемый объём оперативной памяти; С, у.е. - стоимость реализации.
Для обоих методов сначала необходимо произвести ранжирование альтернатив по атрибутам, в результате получим следующее:
Ранг X1 X2 X3
1 A4 A4 A3
2 A3 A3 A2
3 A1 A1 A1
4 A2 A2 A4
Метод LAM суммирует ранги каждой альтернативы и ранжирует их от самой маленькой сумм
мы до самой большой. Итоговые ранги получаем следующим образом: R(Ai) = ^ Ni k • k, где
k=1
Ni:k - количество ранжирований альтернативы Ai по k-му рангу, M - количество рангов. Отсюда R(A1) = 0*1 + 0*2 + 3*3 + 0*4 = 9, R(A2) = 10, R(A3) = 5, R(A4) = 6. Получаем следующий порядок предпочтений: A3, A4, Ai, A2. В результате оптимальным вариантом является A3.
Однако такой метод не может полностью учесть гипотезу компенсации, поскольку конечный ранг альтернативы зависит только от своего собственного ранжирования по атрибутам (которое суммируется), не учитывая при этом ранги по атрибутам других альтернатив. Таким образом, несмотря на простоту, данный метод не может удовлетворить основное требование - линейную компенсацию. Необходимо производить общее ранжирование, которое одновременно использует всю информацию, содержащуюся в ранжировании по атрибутам, а не использовать эту информацию последовательно как сумму рангов [2].
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.