Моделирование оценки характеристик надежности банковских тиражных программных систем на основе нейросетевых технологий

• Автор: Никольский, Святослав Олегович
• Шифр специальности: 05.13.18
• Научная степень: Кандидатская
• Год защиты: 2006
• Место защиты: Брянск
• Количество страниц: 178 с. : ил.

СОДЕРЖАНИЕ
Введение

Глава 1 Анализ существующих моделей надежности программного обеспечения

1.1. Основные положения теории надежности программного обеспечения

1.2. Особенности применения теории надежности для банковских тиражных программных систем

1.3. Классификация моделей надежности

1.4. Анализ моделей типа черный ящик.

1.4.1. Экспоненциальный класс моделей

1.4.2. Гамма и Вебулаклассы моделей

1.4.3. Модели категории бесконечных отказов

1.5. Анализ моделей типа белый ящик

1.6. Анализ статических моделей надежности.
1.7. Обзор используемых в исследовании технологий
1.7.1. Метрики кода программного обеспечения.
1.7.2. Инструментирование исходного кода.
1.7.3. Обнаружение дефектов с помощью анализа исходных кодов
1.7.4. Тестирование программного обеспечения.
1.8. Выводы по главе.
Глава 2 Построение модели надежности на основе нейросетей
2.1. Основные принципы модели
2.2. Методы реализации предложенных принципов
2.2.1. Общий вид разрабатываемой модели
2.2.2. Структурный взгляд на программную систему.
2.2.3. Функциональный граф и иерархия системы
2.2.4. Мера связи функций в функциональном графе.
2.2.5. Меры связи функций с функциональными блоками
2.2.6. Меры связи блоков высшего уровня в иерархии системы
2.2.7. Нейросеть изменения.
2.2.8. Сложность функций.
2.2.9. Адаптация модели
2.2 Требования к процессу разработки.
2.3. Архитектура нейросети изменений
2.3.1. Модель искусственного нейрона.
2.3.2. Выбор архитектуры нейронной сети
2.3.3. Выбор алгоритма обучения нейронной сети.
2.3.4. Выбор числа скрытых слоев и нейронов в них
2.4. Простейшая модель отказов для единичного изменения.
2.4.1. Структура системы.
2.4.2. Разработка системы.
2.4.3. Оценка внесенного изменения
2.4.4. Распространения отказов по функциональному графу.
2.4.5. Распространение отказов верх по иерархии.
2.5. Расширение модели для многих изменений
2.5.1. Цепочка отказов
2.5.2. Добавление новых входов к нейросети изменений
2.5.3. Раздвоение модели
2.5.4. Реализация новых функций .
2.7. Выводы по главе..
Глава 3 Разработка программного комплекса iii
3.1. Этапы применения комплекса iii .
3.2. Архитектура комплекса iii
3.2. Сущности и отношения в предметной области.
3.3. Функции программного комплекса
3.3.1. Редактирование данных системы
3.3.2. Инструментирование исходного кода исследуемой программной системы
3.3.3. Загрузка результатов выполнения инструментированного кода.
3.3.4. Измерение сложности функций.
3.3.5. Загрузка результатов измерения сложности функций
3.3.6. Загрузка сведений о запросах
3.3.7. Обучение нейросети изменения
3.3.8. Прогнозирование отказов по функциям.
3.3.9. Прогнозирование отказов по функциональным блокам
3.3 Просмотр функционального графа.
3.4. Выводы по главе.
Глава 4 Применение ПК для моделирования надежности крупной
банковской тиражной программной системы
4.1. Характеристики исследуемой программной системы
4.2. Допущенные упрощения
4.3. Обучение модели.
4.3. Тестирование модели.
4.3.1. Применение первого класса нейросетей
4.3.2. Применение второго класса нейросетей
4.3.3. Применение третьего класса нейросетей.
4.3.4. Прогнозирование числа отказов в функциональных блоках
системы
4.4. Варианты внедрения модели
4.4.1. Внедрение модели в начале разработки
2.6.2. Внедрение модели в устоявшийся процесс разработки.
4.4. Выводы по главе.
ЗАКЛЮЧЕНИЕ.
ЛИТЕРАТУРА


Теория надежности программного обеспечения значительно отличается от традиционной теории надежности в одном факте - отказы в традиционной теории надежности, как правило, происходят вследствие износа механических частей рассматриваемых объектов. Основным отличием, конечно, является то, что программное обеспечение со временем не изнашивается (в отличие от технических систем), а его надежность, при заданных внешних условиях, изменяется только при внесении изменений в исходный код [5]. На данный момент большинство моделей надежности программного обеспечения относятся к т. SRGMs) [8]. Это означает то, что они основываются на том предположении, что все изменения, вносимые в код в ходе применения модели, носят исправляющий характер. То есть никакие новые доработки не делаются - исправляются лишь существующие в системе дефекты. При этом еще одним стандартным упрощением является то, что эти. Таким образом, перед началом применения модели в системе имеется N дефектов и при исправлении каждого дефекта, их число всегда сокращается ровно на 1. Все рассматриваемые ниже модели надежности, в своей основе, ориентированы на программные проекты, как на конечные продукты - то есть продукты, все требования к которым сформулированы еще до начала работы над проектом и, следовательно, объем их исходного кода изначально конечен. Модель надежности в этом случае применяется единственный раз, на фазе тестирования (либо на ранних фазах, если это модель типа «белый ящик»). Другим широко распространенным типом проектов является тиражное программное обеспечение (circulation software) [,], разработка и доработка которого ведется постоянно и требования к которому также постоянно обновляются. Каждый патч или сборку можно рассматривать в качестве отдельного конечного программного продукта, применяя традиционные модели надежности, но, в таком случае, будет упущена возможность рассматривать весь жизненный цикл продукта как единое целое. Моделей же, специально ориентированных на тиражные проекты, не существует. Рассмотрим, пример развития некоторой гипотетической банковской тиражной программной системы, показанный на Рис. Рис. То есть, невзирая на объем доработки и последствия от нее (в смысле надежности), здесь будет и вся реализуемая новая функциональность, и исправления всех найденных ошибок. VI - в какой-то момент времени от основной ветви отделилась сборка VI. Это событие, как правило, совпадает с «внутренним» событием для проекта - крупные задачи, не требующие срочной реализации, продолжают выполняться в основной ветви, но не выполняются в сборке VI и ее патчах - в сборке только исправляются ошибки и реализуются критичные доработки. V. 1. V. 1. В них будут исправляться ошибки. Однако, каждая сборка имеет свой «лимит поддержки». Так, к примеру, к моменту выхода сборки V. V. 1. Л.2 поддерживаться ограниченно (исправляются только самые критичные ошибки). Таким образом, спецификой банковской тиражной программной системы является то, что в разные сборки делаются разные изменения. Однако, если имеется некая критичная ошибка, она исправляется во всех сборках, в которых она имеется. Так, на Рис. Еще одной отличительной особенностью банковской тиражной программной системы является то, что каждая сборка имеет своей основой предыдущую сборку. То есть, исходные файлы сборки А+1 - это исходные файлы сборки А плюс изменения, реализованные в сборку А+1. Как правило, при разработке масштабной банковской тиражной системы, одновременно существует несколько поддерживаемых сборок. И перед руководителем проекта встает вопрос - как, в условии ограниченных ресурсов (время, число тестировщиков), распределить их таким образом, чтобы все выпускаемые сборки имели наибольшую возможную надежность? Кроме того, использование таких моделей, приводит к потере сведений, накопившихся до выхода исследуемой сборки - ведь каждый программный продукт имеет свои особенности разработки. И учет эти особенностей в модели, конечно, привел бы к лучшему прогнозированию. Вот тут и возникает потребность в модели, специально ориентированной на банковские тиражные программные разработки - учитывающую их специфику, накапливающую данные в ходе всего периода разработки. At с момента предыдущего отказа //Ч.