Структурно-статистические методы обеспечения контролепригодности программных систем

• Автор: Зеленский, Владимир Павлович
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2005
• Место защиты: Нижний Новгород
• Количество страниц: 169 с. : ил.

ВВЕДЕНИЕ
ГЛАВА 1 ОБЗОР СУЩЕСТВУЮЩИХ МЕТОДОВ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ПРОГРАММНЫХ СИСТЕМ И ПОСТАНОВКА ЗАДАЧИ ИССЛЕДОВАНИЯ.

1.1 ЖИЗНЕННЫЙ ЦИКЛ ПС

1.2 МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПО.

1.3 ОСНОВНЫЕ ИСТОЧНИКИ ОШИБОК

1.4 ПОСТАНОВКА ЗАДАЧИ ТЕСТИРОВАНИЯ ПРОГРАММНЫХ СИСТЕМ.

1.5 ОСОБЕННОСТИ ТЕСТОВОГО ДИАГНОСТИРОВАНИЯ ПС

1.6 МЕТОДЫ ПОСТРОЕНИЯ ТЕСТОВ.

1.7 ПОСТАНОВКА ЗАДАЧИ ИССЛЕДОВАНИЯ.

ГЛАВА 2 МАТЕМАТИЧЕСКАЯ МОДЕЛЬ И СТРАТЕГИИ ОПРЕДЕЛЕНИЯ СОСТОЯНИЯ ПРОГРАММНЫХ СИСТЕМ.

2.1 ОРИЕНТИРОВАННЫЙ УПОРЯДОЧЕННЫЙ ГРАФ.

2.2 МАТРИЧНАЯ МОДЕЛЬ.
2.3 ОБОБЩННАЯ ВЕРОЯТНОСТНОСТРУКТУРНАЯ МОДЕЛЬ.
2.4 СТРАТЕГИЯ ОПРЕДЕЛЕНИЯ СОСТОЯНИЯ СИСТЕМЫ
2.5 ВЫВОДЫ.
ГЛАВА 3 МЕТОДЫ И АЛГОРИТМЫ ОБЕСПЕЧЕНИЯ КОНТРОЛЕПРИГОДНОСТИ ПРОГРАММНЫХ СИСТЕМ.
3.1 ОПТИМИЗАЦИЯ ПРИНЯТИЯ РЕШЕНИЯ О СОСТОЯНИИ ПС
3.2 ОПТИМИЗАЦИЯ ВЫБОРА МНОЖЕСТВА ТЕСТОВ
3.3 ОРГАНИЗАЦИЯ ВИРТУАЛЬНЫХ ПРОГРАММНЫХ МОДУЛЕЙ ВПМ
3.4 ВЫВОДЫ.
ГЛАВА 4 ПРАКТИЧЕСКИЕ АСПЕКТЫ ПРОБЛЕМЫ ОБЕСПЕЧЕНИЯ КОНТРОЛЕПРИГОДНОСТИ ПРОГРАММНОГО КОМПЛЕКСА
4.1 ИМИТАЦИОННАЯ МОДЕЛЬ МКАНАЛЬНОЙ СИСТЕМЫ МАССОВОГО ОБСЛУЖИВАНИЯ.
4.2 ВЫВОДЫ.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК.
ПРИЛОЖЕНИЯ.
КОД ПРОГРАММЫ, РЕАЛИЗУЮЩЕЙ АЛГОРИТМ ПРИНЯТИЯ
РЕШЕНИЯ О СОСТОЯНИИ СИСТЕМЫ.
КОД ПРОГРАММЫ, РЕАЛИЗУЮЩЕЙ АЛГОРИТМ РАЗБИЕНИЯ
БЛОКОВ ПО КОНСТРУКТИВНЫМ ЕДИНИЦАМ.
КОД ПРОГРАММЫ, РЕАЛИЗУЮЩИЙ АЛГОРИТМ ОПТИМИЗАЦИИ
МАТРИЦЫ ПУТЕЙ.
ВВЕДЕНИЕ
Создание программных систем ПС с постоянно расширяющимся составом программных модулей, приводит к необходимости правильного и своевременного решения проблемы обеспечения их надежной и эффективной работы.
В обеспечении требуемого уровня надежности и качества функционирования ПС особая роль принадлежит диагностированию, по результатам которого определяется их действительное состояние. Эффективность диагностирования ПС в свою очередь во многом определяется их контролепригодностью. Разработка ПС без учета требований контролепригодности приводит к большим затратам на тестирование, которые в среднем составляют общих затрат на разработку программ, а в отдельных случаях и более.
Основной вклад в решение проблемы диагностирования ПС внесли П.П.Пархоменко, П.А.Правильщиков, В.А.Гуляев, В.В. Липаев,
В.И.Сагунов, С.И.Беляева, Р.Гласс, Т.Тайер, Г.Майерс, .V. и другие российские и зарубежные ученые. Тем не менее, остается еще обширная область нерешенных вопросов и проблем, например, не решена в общем виде задача локализации ошибок произвольной кратности. Кроме этого, на пути реализации известных алгоритмов возникают сложности, связанные с большим объемом вычислений.
Таким образом, проблема разработки методов и алгоритмов обеспечения контролепригодности ПС является актуальной.
В диссертационной работе обосновывается целесообразность применения информационного подхода для решения данной проблемы и включение статистического моделирования в процесс
диагностирования, что позволяет обойти трудности реализации, связанные с большим объемом вычислений.
Диссертационная работа выполнялась по межвузовской научнотехнической программе Диагностические и информационнопоисковые системы.
Актуальность


Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем рис. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Рис. Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической
точки зрения. В эту категорию попадают сложные расчетные системы, системы реального времени и другие подобные задачи. Однако, в процессе использования этого подхода обнаружился ряд его недостатков, вызванных, прежде всего тем, что реальный процесс создания ПО никогда полностью не укладывался в такую жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПО принимал следующий вид рис. Рис. Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС заморожены в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО, пользователи получают систему, не удовлетворяющую их потребностям. Модели как функциональные, так и информационные автоматизируемого объекта могут устареть одновременно с их утверждением. Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ рис. ЖЦ анализ и проектирование. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Рис 1. Понятие ошибки в программе трактуется в среде программистов неоднозначно. Согласно Майерсу считается, что в программе имеется ошибка, если она не выполняет того, что разумно ожидать от нее пользователю. Разумное ожидание пользователя формируется на основании документации по применению этой программы. Следовательно, понятие ошибки в программе является существенно не формальным. Для выявления типов ошибок имеет смысл посмотреть на причины их появления и возможные источники. В предлагается рассматривать первоначально ошибки в том порядке, в котором они чаще всего возникают на различных этапах ЖЦ ПО. При разработке общих требований к вычислительной управляющей системе, которая должна управлять некоторым объектом, часто возникают ошибки, которые при создании ПО приводят, к так называемым, системным ошибкам.