COST ESTIMATION FOR MODERNIZATION OF CRITICAL RELIABILITY SYSTEMS SOFTWARE

Abstract

The authors present the approach of estimation of cost of software upgrade with the account of different stages of life cycle and putting into effect software redundancy. The calculations of the cost of modernization of the software of the real system are made.

Full Text

При разработке высокобюджетных программных банкротству компании-разработчика. Существует проектов важную роль играет оценка затрат. Расхож- множество простых и сложных моделей и основанных дение планируемых затрат с фактическими может на них методик оценки будущей стоимости проекта, привести к серьезным финансовым потерям и даже но они в совокупности имеют следующие недостатки. 62 Вестник Сибирского государственного аэрокосмического университета имени академика М. Ф. Решетнева Во-первых, при оценке трудозатрат не различаются явным образом затраты персонала компании-разработчика на этапах проектирования, разработки, тестирования, документирования, а также затраты на руководителей, на организацию всего жизненного цикла проекта. Во-вторых, расчет трудозатрат базируется на оценке объема кода программного продукта, что при современных технологиях проектирования и разработки не совсем адекватно отражает трудоемкость технологического процесса разработки. В-третьих, не учитывается явным образом трудоемкость модернизации части системы, что заставляет рассматривать каждую новую доработку системы как отдельный новый проект. Современные сложные программные комплексы имеют большую иерархическую программную архитектуру, и доработка одного программного компонента обязательно влечет за собой изменения в других, связанных с ним компонентах. Поэтому при модернизации системы должна учитываться глубина доработки. В-четвертых, информация, необходимая для расчета многих параметров, может отсутствовать на ранних этапах проекта, а их предполагаемая оценка может быть ошибочной. В-пятых, в существующих моделях не учитываются затраты на повышение надежности наиболее важных компонентов путем введения программной избыточности. Снижение вероятности сбоя получают за счет одновременной работы нескольких версий одного и того же компонента, реализованных разными командами разработчиков или с использованием разных языков программирования. Таким образом снижается вероятность того, что на одних и тех же входных данных откажут все версии компонента. Для одновременной работы нескольких версий необходима разработка среды их исполнения. В среду исполнения входит алгоритм голосования, который выбирает наиболее приемлемые выходные данные от всех версий [1]. Введение программной избыточности необходимо для обеспечения безопасности функционирования критически важных информационных систем, связанных с управлением технологическими процессами или финансовыми расчетами. Следовательно, необходима разработка методики оценки трудозатрат на модернизацию уже существующего программного продукта, которая поможет менеджерам проектов уменьшить ошибку оценки и снизить финансовые риски компании. При расчете размера оцениваемой системы будут учитываться объектные указатели (компоненты) системы, аналогично модели COMOMO II [2]. Рассмотрим основные этапы методики оценки затрат на модернизацию программного обеспечения критических по надежности систем. 1. Анализ технических требований заказчика. Заказчик передает свои задокументированные требования на доработку системы для анализа компании разработчика или аналитики выявляют требования заказ чика в ходе интервью. После проведенного анализа формируется проект технического задания на модернизацию системы. 2. Декомпозиция задач. На этапе проектирования архитектуры системы задачи модернизации декомпозируются на множество простых. Затем задачи сопоставляются с доработкой уже существующих компонентов системы или разработкой новых. 3. Группировка компонентов. Компоненты, которые необходимо разработать или модернизировать, группируются на типы по аналогичному назначению и сложности. 4. Определение избыточности программных компонентов. Для уменьшения вероятности сбоя в наиболее важных компонентах определяется количество версий, которые будут реализованы или разными командами разработчиков, или с использованием различных технологий. Также проводится оценка трудозатрат на разработку алгоритма голосования для данного компонента. 5. Оценка трудозатрат на разработку компонентов. Вычисляется среднее время разработки компонента каждого типа, на основании предыдущих работ или с помощью экспертной оценки. Если тип компонентов ранее не разрабатывался, то время определяется экспертно, исходя из анализа подобных типов компонентов. 6. Определение глубины модернизации компонентов. Определяется глубина доработки компонентов (весовые коэффициенты) в процентах. 7. Вычисление трудоемкости разработки. Суммируется трудоемкость разработки компонентов каждого типа. Если компонент подлежит модернизации, то трудоемкость разработки этого компонента умножается на весовой коэффициент. Также учитываются затраты на разработку алгоритма голосования данного компонента и на его версии, если компонент реализуется с применением программной избыточности. 8. Определение затрат на этапы жизненного цикла. На основании предыдущих работ вычисляется соотношение среднего времени, затраченного на другие этапы жизненного цикла, и среднего времени разработки. Вычисленные коэффициенты (соотношения) умножаются на трудоемкость этапа разработки. Таким образом, получается трудоемкость этапов анализа или проектирования, разработки, тестирования и работ по организации процесса. 9. Вычисление финансовых затрат на модернизацию проекта. Трудоемкость каждого этапа умножается на среднюю норму оплаты труда сотрудника, работающего на данном этапе жизненного цикла. Затем полученные суммы складываются. Для проведения расчетов по приведенной методике используются следующие параметры: M - множество типов компонентов; i - тип компонента, i е M; N - множество новых и подлежащих доработке компонентов i-го типа; 63 Математика, механика, информатика j - номер компонента i-го типа, j е N; T - трудоемкость разработки нового или уже имеющегося компонента i-го типа, человеко-часов; Wj - весовой коэффициент модернизации существующего j-го компонента i-го типа (для новых компонентов равен Wj = 1, если нет j компонента i-го типа, то Wj = 0); rj - количество версий в компоненте, если вводится программная избыточность (если программная избыточность не вводится, то = 1); TRij - трудоемкость разработки алгоритма голосования для j-го компонента i-го типа (если программная избыточность не вводится, то TRiJ- = 0); Tm - общие трудозатраты на управление и организацию проекта, человеко-часов; Wm - весовой коэффициент, определяющий процент трудоемкости организации от трудоемкости разработки; Cm - стоимость оплаты одного человеко-часа менеджера проекта, руб.; Ta - общая трудоемкость работы аналитиков и проектировщиков, человеко-часов; Wa - весовой коэффициент, определяющий процент трудоемкости анализа и проектирования от трудоемкости разработки, человеко-часов; Ca - стоимость одного человеко-часа аналитика или проектировщика, руб.; Tdev - общая трудоемкость этапа разработки, человеко-часов; Cdev - стоимость оплаты одного человеко-часа разработчика, руб.; Tt - общая трудоемкость этапа тестирования; wt - весовой коэффициент, определяющий процент трудоемкости анализа от трудоемкости разработки; Ct - стоимость оплаты одного человеко-часа тестировщика, руб.; Tdoc - общая трудоемкость документирования доработок системы, человеко-часов; Wdoc - весовой коэффициент, определяющий процент трудоемкости документирования от трудоемкости разработки; Ct - стоимость оплаты одного человеко-часа специалиста по технической документации, руб.; Tp - общая трудоемкость проекта, человеко-часов; Ср - общая стоимость проекта, руб. Трудоемкость разработки рассчитывается по матрице Wj и с учетом введения программной избыточности следующим образом: i=1 j=1 Трудоемкости остальных этапов жизненного цикла рассчитываются по соответствующим весовым коэффициентам из трудоемкости разработки: T = w Tj m m dev > Ta = W a Tdev , Tt = WtTdev , Tdoc = WdocTdev. Общая трудоемкость рассчитывается по формуле Tp =(1 + Wm + Wa + Wt + Wdoc )Tdev ■ Формула расчета общей стоимости в детализированном виде выглядит следующим образом: Cp = (WmCm + WaCa + Cdev + WtCt + WdocCdoc )x M N ХЪЪ\( +( - 1)T' + TRj ) i=1 j=1 Для проверки корректности оценки по предложенной методике был проведен анализ оценочных и фактических данных на шести примерах модернизации системы. Расхождение фактической и прогнозируемой стоимости вычислялось по формуле Расхождение = = Стоимостьпрогнозируемая - Стоимостьфакгич еская I СтоимостьфактиЧеская На основании данных по расхождениям была произведена оценка показателя PRED(L). Он отражает процент оценок, отклонение которых от фактических значений меньше L [3]. Показатель рассчитывается по следующей формуле: 100 -П И Расхождение < L, PRED(L) = — Х]0 n i=1 I0, где n - общее количество оценок. В таблице приведены значения PRED(L) для параметра L, равного 20, 25 и 30 %. Таблица L PRED(L) PRED(20) 83 % PRED(25) 83 % PRED(30) 100 % Согласно этим данным, расчеты по предложенной методике достаточно точны, что позволяет принять решение о ее использовании в ИТ-компаниях, занимающихся разработкой и поддержкой программного обеспечения сложных информационно-управляющих систем. Предложенная методика оценки затрат на модернизацию программного обеспечения позволяет учитывать трудозатраты персонала на различных этапах жизненного цикла программного обеспечения; определять размер системы исходя из количества объектных указателей; учитывать глубину доработки архитектурных компонентов программной системы; использовать для расчета коэффициентов экспертную оценку, если нет актуальных данных по предыдущим работам; учитывать трудозатраты на введение программной избыточности.