Прогнозирование стоимости разработки систем с программной избыточностью

Тип работы:
Реферат
Предмет:
Общие и комплексные проблемы технических и прикладных наук и отраслей народного хозяйства


Узнать стоимость

Детальная информация о работе

Выдержка из работы

Д. А. Шеенок*, В. В. Кукарцев**
ПРОГНОЗИРОВАНИЕ СТОИМОСТИ РАЗРАБОТКИ СИСТЕМ С ПРОГРАММНОЙ ИЗБЫТОЧНОСТЬЮ
* Красноярский институт железнодорожного транспорта ** Сибирский государственный аэрокосмический университет
dmitryshkras@rambler. ru, kukarcev@mx1. sibsau. ru
Рассмотрены методы применения программной избыточности. Приведены этапы методики оценки затрат на разработку отказоустойчивых программных систем. Предложен алгоритм применения методики при согласовании сроков и стоимости работ на реализацию системы.
Ключевые слова: программная избыточность, отказоустойчивость, программное обеспечение.
D. A. Sheenok*, V. V. Kukarcev**
COST FORECASTING THE DEVELOPMENT OF SYSTEMS WITH SOFTWARE REDUNDANCY
*Krasnoyarsk Institute of Railway Transport **Siberian State Aerospace University
The methods of application software redundancy. Stages of assessment methodology development cost fault-tolerant software systems. An algorithm using the technique when negotiating timetable and costs for implementation of the system.
Keywords: software redundancy, fault tolerance, software.
Введение систем. В таких областях, как производство,
Разработка отказоустойчивого программно- транспорт, финансы, оборона и медицина, сбой
го обеспечения (ПО) — отдельный аспект разра- в работе программного обеспечения может
ботки надежных информационно-управляющих привести к катастрофическим последствиям.
Поэтому одной из основных задач при разработке программного обеспечения является создание таких алгоритмов или методов разработки ПО, которые обеспечивали бы устойчивость системы к программным и аппаратным сбоям.
Разработка таких систем требует большего вклада временных, трудовых и финансовых ресурсов. Поэтому в разработке высокобюджетных программных систем для применения в критически важных областях большую роль играет предварительная оценка затрат. Расхождение планируемых и фактических затрат может привести не только к срыву сроков сдачи продукта, но и к серьезным финансовым потерям и даже к банкротству компании разработчика.
1. Методы разработки отказоустойчивого программного обеспечения
Одной из наиболее перспективных и уже положительно зарекомендовавших себя методологий обеспечения высокой надежности и отказоустойчивости программного обеспечения является введение программной избыточности, т. е. дублирование программных компонентов. Но простое дублирование компонентов, как при аппаратном резервировании, недопустимо, так как в отличие от аппаратуры, программные дефекты имеют внутреннюю природу. При дублировании будут копироваться имеющиеся ошибки. Поэтому при введении программной избыточности предполагается, что возникновение сбоя в функционально эквивалентных модулях (версиях) на одних и тех же входных данных происходит в различных точках исполнения.
Создание функционально-эквивалентных, но, тем не менее, разных модулей может быть достигнуто с помощью разнообразия при разработке версий одного модуля. Разнообразие применяют для разработки компонентов, к которым происходит наиболее частое обращение, или результаты работы которых участвуют в критических циклах управления.
Существует несколько подходов к реализации программной избыточности [1]:
1. NVP (N-version programming — N-версион-ное программирование) — был предложен Ави-жиенисом в 1985 году. Версии выполняются параллельно во времени, а результат их работы определяется с помощью какого-либо алгоритма голосования. Алгоритмы голосования могут быть разными в зависимости от задачи. Обычно используется выбор результата по абсолютному большинству (эквивалентных выходов больше половины) или по согласованному боль-
шинству (самая большая группа эквивалентных выходов). При этом выходные значения являются идентичными при заданной погрешности.
2. RB (Recovery Block — блок восстановления) — был предложен Брайеном Ренделом в 1975 году. Версии выполняются последовательно. После выполнения первой версии программного компонента приемочный тест, который по результатам выполнения принимает результаты вычисления, либо запускает следующую версию компонента.
3. CRB (consensus RB — согласованный блок восстановления) — был предложен Китом Скоттом в 1987 году. Гибридный метод, который работает как NVP, но в случае невозможности выбрать результат алгоритмом голосования продолжает работу как блок восстановления.
4. NSCP (N-self-checking programming — NVP с самоконтролем) — был предложен Жан-Клодом Лапри в 1987 году. Также гибридный метод, учитывающий, что в некоторых версиях результат может быть неприемлемым. Приемочный тест играет роль фильтра в алгоритме голосования.
Надежность функционирования программного компонента зависит от глубины программной избыточности (количества версий).
2. Методика оценки стоимости разработки программного обеспечения
Во многих случаях контракты и предварительные планы на создание программного обеспечения подготавливаются и оцениваются на основе неформализованных представлений заказчиков о требуемых функциях и характеристиках качества.
Значительные системные ошибки при определении требуемых показателей качества, оценке трудоемкости, стоимости и длительности разработки являются достаточно массовыми и типичными. Многие созданные программные системы не способны выполнять полностью требуемые функциональные задачи с гарантированным качеством и их приходится долго и иногда безуспешно дорабатывать для достижения необходимого качества и надежности функционирования, затрачивая дополнительные финансовые и временные ресурсы. В результате, часто проекты систем не соответствуют исходному, декларированному назначению, функциональным и нефункциональным требованиям, и не укладываются в согласованные графики и бюджет разработки.
В российской практике, как правило, имеющийся огромный опыт отдельных организаций,
а также успешно реализованные ими планы и процессы разработки предшествующих ПС высокого качества игнорируются, не обобщаются и не используются в качестве реальной базы для прогнозирования и планирования новых проектов.
Существует множество простых и сложных моделей и основанных на них методик оценки будущей стоимости проекта, но они в совокупности имеют следующие недостатки [2]:
1. При оценке трудозатрат не различаются явным образом затраты персонала компании разработчика на этапах проектирования, разработки, тестирования, документирования, а также затраты на руководителей организации всего жизненного цикла проекта.
2. Расчет трудозатрат базируется на оценке объема кода программного продукта, что при современных технологиях проектирования и разработки не совсем адекватно отражает трудоемкость технологического процесса разработки.
3. В существующих моделях не учитываются затраты на повышение надежности наиболее важных компонентов путем введения программной избыточности.
Авторами предлагается методика оценки затрат на разработку программного обеспечения с применением избыточности. При расчете размера оцениваемой системы будут учитываться объектные указатели (функциональные точки), аналогично модели COMOMO II. СОСОМО II является одной из самых популярных моделей, и была впервые опубликована в 1999 году. COCOMO II использует модели композиции приложения (объектные указатели) раннего этапа проектирования и этапа постархитектуры. Они заменили базовый, промежуточный и детализированный этапы модели COCOMO. Модель композиции приложения позволяет брать в расчет современные методы разработки (например, такие как создание прототипа), поскольку при визуальной разработке оценка размера продукта с помощью строк кода не всегда является верной. Вместо этого в модели используются объектные указатели. Это количество экранных форм, отчетов, модулей, каждый из которых соотносится с одним из трех уровней — простой, средний и сложный в соответствии с уровнем сложности [3].
Рассмотрим основные этапы методики оценки затрат на модернизацию программного обеспечения критических по надежности систем:
1. Сбор и анализ технических требований заказчика. Заказчик передает свои задокумен-
тированные требования на доработку системы компании разработчика для анализа, или требования заказчика выявляют аналитики в ходе интервью. После проведенного анализа формируется проект технического задания на разработку системы.
2. Декомпозиция задач, дизайн архитектуры. На этапе проектирования архитектуры системы, задачи декомпозируются на множество простых. Системный архитектор определяет общую структуру каждого архитектурного представления, декомпозицию представлений и интерфейсы взаимодействия элементов. Таким образом, происходит разбиение большой системы на более мелкие части (компоненты), в соответствии с определенным уровнем абстракции. Поэтому архитектурный компонент может быть определен по-разному в зависимости от архитектурного подхода и степени подробности описания архитектуры.
3. Группировка компонентов. Компоненты группируются на типы (функциональные точки) по аналогичному назначению и сложности.
4. Определение избыточности программных компонентов. Для уменьшения вероятности сбоя в наиболее важных компонентах определяется количество версий, которые будут реализованы разными командами разработчиков, или с использованием различных технологий. Также проводится оценка трудозатрат на разработку среды исполнения версий каждой функциональной точки.
5. Оценка трудозатрат на разработку компонентов. Вычисляется среднее время разработки компонента каждой функциональной точки, на основании предыдущих работ или с помощью экспертной оценки. Если тип компонентов ранее не разрабатывался, то время определяется экспертно, исходя из анализа подобных типов компонентов, разрабатываемых ранее по аналогичной технологии.
6. Вычисление трудоемкости разработки. Суммируется трудоемкость разработки компонентов каждого типа. Если компонент реализуется с применением программной избыточности, то суммируются затраты на разработку всех его версий и среды их исполнения (метакласса среды исполнения и алгоритма голосования или приемочного теста).
7. Определение затрат на этапы жизненного цикла. Предполагается, что затраты времени на другие этапы работ в жизненном цикле программного обеспечения пропорциональны затратам на этап разработки. На основании ра-
бот по более ранним проектам вычисляется соотношение среднего времени, затраченного на другие этапы жизненного цикла, к среднему времени разработки. Вычисленные коэффициенты (соотношения) умножаются на трудоемкость этапа разработки. Другими этапами могут быть работы по анализу или проектированию, тестированию, документированию и работы менеджера по организации процесса.
8. Вычисление финансовых затрат на разработку системы. Трудоемкость каждого этапа умножается на среднюю норму оплаты труда сотрудника, работающего на данном этапе жизненного цикла. Затем полученные суммы складываются.
3. Расчет стоимости разработки отказоустойчивого программного обеспечения
Для проведения расчетов по приведенной методике используются следующие параметры:
М — множество типов компонентов (функциональных точек) — г — тип компонента, г е М- N — множество новых и подлежащих доработке компонентов г-го типа- у — номер компонента г-го типа, у е Д- Тг — трудоемкость разработки компонента г-го типа, чел. -час- Уу — количество версий в компоненте, если вводится программная избыточность (если программная избыточность не вводится, то Уу = 1) — КБ, — трудоем-
кость разработки среды исполнения г-й функциональной точки для блока восстановления, чел. -час (если КБг& gt-0, то Д5СРг-=0- ЛУРг=0- СКБг=0) — ДУРг — трудоемкость разработки среды исполнения г-й функциональной точки для Диверсионного программирования, чел. -час (если ЫУР& gt-0, то КБг=0- ШСР. =0- СКБг=0) — ОКБ, -трудоемкость разработки среды исполнения г-й функциональной точки для согласованного блока восстановления, чел. -час (если СКБ& gt-0, то КБ,=0- ДУР=0- Д5СРг=0) — ЖСРг — трудоемкость разработки среды исполнения г-й функциональной точки для Д-версионного программирования с самопроверкой, чел. -час (если Д5СР& gt-0, то КБ=0- ДУР,=0- СЛБР0) — ТЛеу — трудоемкость этапа разработки, чел. -час- СЛеу -стоимость оплаты одного чел. -часа разработчика, руб- ws — весовой коэффициент, определяющий долю трудоемкости этапа 5 от трудоемкости этапа разработки- Т5 — трудоемкость этапа 5, зависящего от этапа разработки- С5 -стоимость оплаты одного чел. -часа сотрудника, занятого на этапе 5, руб- Тр — общая трудоемкость проекта, чел. -час- Ср — общая стоимость проекта, руб.
Трудоемкость разработки рассчитывается как сумма трудозатрат на разработку всех компонентов каждого типа, с учетом матрицы Уу, и трудозатрат на реализацию среды исполнения следующим образом:
М N
г*. =И (+(- 1+ + (ср + щ + шр1 + сщ)).
?=1 і=
Трудоемкость 5-го этапа жизненного цикла рассчитывается по соответствующему весовому коэффициенту и трудоемкости этапа разработки:
Формула расчета общей стоимости в детализированном виде выглядит следующим обОбщая трудоемкость проекта рассчитывается как разом:
(Е МЫ
ср = [?(?*?.) + С^ + (- 1+ + (Р + щ + ЫУр + СЯБгТ
?=1 j=1
Заключение примерах модернизации системы. Расхождение
Для проверки адекватности оценки по фактической и прогнозируемой стоимости вы-
предложенной методике был проведен анализ числялось по формуле
оценочных и фактических данных на десяти
Расхождение =
Стоимость — Стоимостьф
прогнозируемая фактическая
Стоимость
фактическая
На основании данных по расхождениям бы- отражает процент оценок, отклонение которых
ла произведена оценка показателя РЛЕЮ (Ь). Он от фактических значений меньше Ь [3]. Показа-
тель рассчитывается по следующей формуле:
100% «(1, если Расхождение & lt- Ь- РЯЕБ (Ь) = ^^& lt-1 ' '
п г=1 [0, если Расхождение & gt- Ь,
где п — общее количество оценок.
В таблице приведены значения РЯЕО (Ь) для параметра Ь, равного 20, 25 и 30%.
Ь РКЕЭ (Ь)
РЯЕБ (20) 60%
РЯЕБ (25) 90%
РЯЕБ (30) 100%
Согласно показателю РЯЕО, расчеты по предложенной методике достаточно точны, что позволяет использовать ее в ИТ-компаниях, занимающихся разработкой и поддержкой отказоустойчивых программных систем.
Рассчитанная по методике прогнозная стоимость разработки может учитываться при согласовании с заказчиком смет на выполнение
работ того или иного проектного решения.
Таким образом, предложенная методика оценки затрат на модернизацию программного обеспечения позволяет:
— учитывать трудозатраты персонала, занятого на различных этапах жизненного цикла программного обеспечения-
— определять размер системы исходя из количества различных функциональных точек-
— учитывать трудозатраты на введение программной избыточности различными методами.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Новой, А. В. Система анализа архитектурной надежности программного обеспечения: дис. … канд. техн. наук / А. В. Новой. — Красноярск, 2011. — 131 с.
2. Кукарцев, В. В. Оценка затрат на модернизацию программного обеспечения критических по надежности систем / В. В. Кукарцев, Д. А. Шеенок // Вестник СибГАУ. Вып. 5(45). — Красноярск, 2012. — С. 62−65.
3. Глазова, М. А. Моделирование стоимости разработки проектов в ИТ-компаниях: дис. … канд. экон. наук / М. А. Глазова. — М., 2008. — 205 с.

ПоказатьСвернуть
Заполнить форму текущей работой