Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

Современные исследования надежности систем управления и систем обработки информации показали, что качество их работы напрямую зависит от надежности и безотказности программного обеспечения.

За прошедшие десятилетия было создано множество методов и моделей исследования надежности программного обеспечения (ПО), однако единого подхода к решению этой проблемы предложено не было. Причиной этому является уникальность каждой программной системы. Тем не менее, при разработке ответственных проектов, их создатели стараются в той или иной степени получить оценку надежности ПО, как правило, на основе результатов конечных испытаний. Современные программные системы используют при работе колоссальный объем данных, проходящих через стандартные модули и функции. Поэтому, выявить все связи и пути обработки информации, даже для достаточно несложной программы, практически невозможно. Исходя из этого, детализация элементов расчета надежности (условно называемых программными модулями) должна ограничиваться законченными программными образованиями, которые, взаимодействуя между собой, составляют более сложное объединение, надежность которого нас интересует.

Основными подходами при создании отказоустойчивых систем управления и обработки информации является применение алгоритмов и моделей оценки надежности программных средств на каждом шаге жизненного цикла и использование мультиверсионного программного обеспечения.

Диссертационное исследование направлено на решение следующей научной проблемы: создание комплексного подхода для оценки надежности программных средств на основных этапах жизненного цикла; обеспечение согласованности разработанных моделей и алгоритмов оценки параметров надежности программного обеспечения на основных фазах жизненного цикла.

Уверенность в успешности решения поставленной проблемы основывается на результатах исследований таких отечественных и зарубежных ученых, как Хорошевский В.Г., Липаев В.В., Ковалев И.В., Авиженис А.А, Боэм Б.У., Гросспитч К.Е, и др.

Целью диссертационной работы является разработка системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств.

Для достижения поставленной цели решались следующие задачи:

- Анализ существующих методик, моделей и алгоритмов оценки надежности программных средств.

- Анализ методик, моделей и алгоритмов оценки надежности объектно-ориентированного программного обеспечения.

- Разработка базовой модели оценки надежности программного обеспечения, которая охватывает все этапы жизненного цикла программных средств.

- Формирование ряда подмоделей оценки надежности, путем модификации базовой модели.

- Разработка структуры и реализация системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств.

- Применение системы при реализации реальных проектов разработки программных средств.

Методы исследования. При выполнении работы использовались математическое и вероятностное моделирование параметров сложных систем, методы оценки надежности сложных систем, элементы теории вероятностей, объектно-ориентированный анализ, теория надежности программного обеспечения.

Научная новизна работы:

- Создана модифицированная модель роста надежности программного обеспечения, позволяющая получить требуемое время тестирования компонент ПО для достижения требуемого уровня надежности.

- Предложена базовая модель оценки параметров надежности программных средств и ее модификации для оценки параметров надежности прикладного объектно-ориентированного программного обеспечения и объектно-ориентированного мультиверсионного программного обеспечения с распределенной архитектурой.

- Разработан алгоритм трансформации базовой модели для оценки надежности ПО любого класса.

- Предложены модель и алгоритм оценки транзакционной надежности программного обеспечения систем обработки и хранения информации.

- Реализован программный комплекс моделей и алгоритмов оценки параметров надежности программного обеспечения на основных фазах жизненного цикла.

Значение для теории. Результаты, полученные при выполнении диссертационной работы, создают теоретическую основу для разработки моделей, методов и алгоритмов, направленных на эффективный анализ программных средств на всех фазах жизненного цикла программного обеспечения.

Практическая ценность. Разработанная в диссертации система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств позволяет оценивать степень отказоустойчивости программных систем, применяемых в различных областях науки и производства.

Разработанная программная система позволяет:

- Рассчитать требуемое время тестирования компонент (в человеко-часах) ПО для достижения требуемого уровня надежности на ранних фазах жизненного цикла.

- Решать новые задачи по оценке надежности программных средств и быстрому восстановлению сбойных компонент архитектуры ПО, используя абстрактные состояния не сбойных копонент.

Базовая модель оценки надежности применяется как для любого ПО, в том числе, объектно-орентированного ПО, для мультиверсионного объектно-ориентированного ПО с распределенной архитектурой и позволяет выявлять «узкие места» в компонентах программных средств и диапазоны входных значений, в наибольшей степени влияющие на сбои в компоненте. Данная модель также позволяет рассчитывать транзакционную надежность систем обработки информации на фазе тестирования всей системы.

Достоверность полученных результатов подтверждается тестированием и оценкой результатов применения разработанной системы в реальных проектах, а также согласованностью расчетных и экспериментальных данных.

Реализация результатов работы. При использовании системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств был реализован модуль «Модели надежности» системы Microsoft Business Solutions-Axapta, используемый в официальном Центре Решений Microsoft Business Solutions в Красноярском крае.

Материалы диссертационной работы введены в учебные курсы и используются при чтении лекций студентам кафедры информатики Красноярского Государственного Технического Университета по дисциплине «Разработка программного обеспечения для информационно-управляющих систем».

На защиту выносятся:

- Базовая модель оценки параметров надежности программных средств.

- Алгоритм трансформации базовой модели, позволяющий эффективно оценить параметры надежности ПО различных классов.

- Модель и алгоритм оценки транзакционной надежности объектно-ориентированного программного обеспечения систем обработки и хранения информации.

- Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств.

Апробация работы. Основные положения и результаты работы прошли всестороннюю апробацию на всероссийских конференциях, научных семинарах и научно-практических конференциях. В том числе:

- на всероссийской научно-практической конференции «Решетневские чтения», Красноярск, 2000 г.;

- на всероссийской электронной научно-технической конференции, - Вологда, 2001 г.

- на международной научной конференции Telematica'2001, Санкт-Петербург, 2001 г.

- на научной конференции «Научно-инновационное сотрудничество». Москва, 2002 г.

- на международной научно-практической конференции СибГАУ САКС-2002, Красноярск, 2002 г.

- на V-й всероссийской конференции с международным участием молодых ученых и аспирантов «Новые информационные технологии. Разработка и аспекты применения», Таганрог: ТРТУ. 2002 г.

Диссертационная работа в целом обсуждалась на научных семинарах кафедры информатики Красноярского Государственного Технического Университета (2000-2003 гг.), в Академии Microsoft Business Solutions CIS, Москва 2002 г.

Публикации. По теме диссертации опубликовано 16 печатных работ. Полный список публикаций представлен в конце автореферата.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения и списка литературы.

1. Анализ методов оценки надежности программных средств на всех этапах жизненного цикла

1.1 Программное обеспечение и надежность

Интерес к оцениванию надежности программного обеспечения (ПО) возник одновременно с появлением программ. Он был вызван естественным стремлением получить традиционную вероятностную оценку надежности технического устройства (ЭВМ или персонального компьютера), работа которого, в основном, и предназначалась для функционирования ПО. Последнее было определено, как одна из составляющих частей машины, поэтому подход к оцениванию надежности программной части первоначально мало отличался от оценивания надежности техники и заключался в переносе известных статистических методов классической теории надежности на новую почву, образовав ее отдельную ветвь - теорию надежности ПО. В целом этот подход сохранился до сегодняшнего дня. Однако, по мере развития вычислительной техники пришло четкое понимание того, что ПО - не просто составная часть вычислительной техники. В современных условиях развития цифровой техники специализированное ПО перестало быть принадлежностью одной вычислительной системы (как это было раньше), а стало использоваться на сотнях и тысячах аналогичных компьютеров (в основном - персональных). Даже если не касаться вопросов информационной безопасности, проблема обеспечения устойчивого функционирования расчетных программ, выявления их ошибок, сегодня крайне остро стоит перед разработчиками.

За прошедшие десятилетия было создано множество методов, методик и моделей исследования надежности ПО. Однако, к сожалению, единого подхода к решению этой проблемы предложено не было и, по-видимому, в ближайшее время не предвидится. Тем не менее, при разработке сложных программных систем, их создатели стараются в той или иной степени получить оценку надежности ПО. Более правильный подход заключается в последовательном оценивании надежности программ на каждом этапе разработки. Основная сложность при использовании статистических методов заключается в отсутствии достаточного количества исходных данных. Динамика выявления ошибок должна тщательно фиксироваться и обрабатываться. Важной проблемой является степень детализации элемента расчета надежности. Выявить все связи обработки информации (как это порой предлагается), даже для достаточно несложной программы, практически нереально. Исходя из этого, детализация элементов расчета надежности (условно называемых программными модулями) должна ограничиваться законченными программными образованиями, которые, взаимодействуя между собой, составляют более сложное объединение (комплекс), надежность которого нас интересует. При этом допускается, что надежность самой вычислительной техники, операционной системы и среды программирования полная, нас интересует лишь надежность функционирования специальных программных средств, решающих основную целевую задачу системы.

В данной работе проводится анализ методов, моделей и методологий в области создания надежного, отказоустойчивого ПО. Делается попытка систематизировать и унифицировать существующие методологии. Разрабатываются новые модели и алгоритмы для использования на всем жизненном цикле создания гарантоспособного программного обеспечения.

1.2 Проблемы в области исследования надежности программного обеспечения

программный надежность алгоритм

В результате анализа многих работ из области исследования надежности ПО был выявлен широкий ряд проблем, основной причиной которого является отсутствие единого стандарта в области отказоустойчивого ПО.

Были изучены труды многих зарубежных исследователей, таких как Авиженис [1,63,109], Майерс[37], Боэм [8,9,66], Ашфари [62,113]; и труды отечественных авторов: Липаев [33,34,35,36], Ковалев [2,4,19-30,84-89] и других.

Среди множества различных институтов и организаций (ISREE, IEEE, NASA), независимых исследователей проблем надежности ПО не существует единой терминологии, единых параметров и показателей надежности, методологии разработки отказоустойчивого ПО [64,69,71-83,90,91,92,105,107,110,112].

Можно выделить три основные группы проблем в данной области:

- отсутствие единой методологии создания отказоустойчивого ПО;

- отсутствие единой методологии тестирования отказоустойчивого ПО;

- отсутствие единого подхода к анализу проблемной области.

Проблемы терминологии

Ошибка, сбой и дефект в программном обеспечении

Программное обеспечение содержит ошибку, если[92]:

1. Поведение ПО не соответствует спецификациям.

Недостатки: неявно предполагается, что спецификации корректны. Подготовка спецификаций - один из основных источников ошибок. Если поведение программного продукта не соответствует его спецификациям, ошибка, вероятно, имеется. Однако, если система ведёт себя в соответствии со спецификациями, мы не можем утверждать, что она не содержит ошибок.

2. Поведение ПО не соответствует спецификациям при использовании в установленных при разработке пределах.

Недостатки: если система случайно используется в непредусмотренной ситуации, её поведение должно оставаться разумным. Если это не так, она содержит ошибку.

3. Программное обеспечение ведёт себя не в соответствии с официальной документацией и поставленными пользователю спецификациями.

Недостатки: ошибки могут содержаться и в программе, и в спецификациях, или в руководстве описана только ожидаемая и планируемая работа с системой.

4. Система не способна действовать в соответствии с исходной спецификацией и перечнем требований пользователя.

Это утверждение тоже не лишено недостатков, поскольку письменные требования пользователя редко детализированы настолько, чтобы описывать желаемое поведение программного обеспечения при всех мыслимых обстоятельствах.

Окончательное определение: в программном обеспечении имеется ошибка, если оно не выполняет того, что пользователю разумно от него ожидать. Отказ программного обеспечения - это проявление ошибки в нём.

Термины «ошибка», «сбой» и «дефект» часто используются без разделения по смыслу. В ПО «ошибка» - это действия программиста, которые приводят к дефектам в ПО. «Дефект» в ПО влечет за собой сбои во время исполнения кода [93]. «Сбой» - отклонение выхода системы от желаемого при выполнении кода.

Дефект влечет за собой сбой только тогда, когда выполняется код содержащий ошибку, и распространяется до выхода системы. Уровень тестируемости дефекта определяется как вероятность обнаружения сбоя на случайно выбранном выходе.

Уровни сбоя: катастрофичный, высокий, средний, низкий, незначительный. Определения этих уровней меняются от системы к системе.

Простой или «зависание» - особый вид сбоя, зависящий как от сбоя в аппаратной части, так и в программной части системы или же от некорректных действий пользователя.

Надежность программного обеспечения

Организация IEEE определяет надежность как «способность системы или компонента выполнять требуемые функции при определенных условиях за определенный период времени». Это определение дал Авиженис, и оно считается классическим[92].

Основной недостаток такого определения - это то, что в нем не учтено различие между ошибками разных типов.

Надежность ПО, определяется как вероятность функционирования без ошибок за определенный период времени в определенной операционной системе.

Для большинства разработчиков надежность определяется как корректность ПО, т.е. количество ошибок, которое надо исправить во время теста.

Существует и другое определение надежности - операционная (транзакционная) надежность. Операционная надежность - это способность системы или компонента выполнять требуемые функции при определенных условиях в рамках транзакции. Широко используется в системах обработки и хранения информации в базах данных.

В рамках данной работы будут использоваться понятия классической и транзакционной надежности, в зависимости от места применения и используемой модели надежности.

Другие термины и определения

В определениях параметров из области надежности ПО существуют и другие определения, имеющие немаловажное значение. Одним из таких параметров является время.

Время можно разделить на два типа: календарное время и процессорное время. Процессорное время преобразуется в календарное для сравнения параметров ПО, используемого на разном аппаратном обеспечении и разных операционных системах.

При комбинировании различных моделей оценки надежности следует учитывать тот факт, что понятия времени в них могут различаться. Такие модели надо унифицировать, приводя их единому пониманию времени, вводя соответствующие формулы с коэффициентами пересчета времени.

Проблемы выбора параметров

Среди множества работ из области оценки параметров надежности ПО можно выявить несколько десятков подходов к измерению или методам оценки тех или иных количественных показателей, характеризующих надежность[106].

Надежность - имеет обозначение R (reliability) измеряется как вероятность не возникновения сбоя. Надежность используется практически во всех моделях как основной показатель.

Среднее время появления сбоя - имеет аббревиатуру MTTF (Mean Time To Failure); измеряет время между двумя последовательными сбоями [56,57,58].

Интенсивность сбоев - величина обратная MTTF, определяет количество сбоев в единицу времени.

Среднее время простоя (TR) - величина, определяющая время, затрачиваемое на выявление, устранение и восстановление системы или компонента системы после сбоя [59,60].

Коэффициент готовности системы - S, определяется как отношение разности среднего времени появления сбоя и среднего времени простоя системы к среднему времени появления сбоя.

Количество оставшихся ошибок в коде ПО - используется при разработке ПО. Показывает количество ошибок в коде на каждую тысячу строк исходного кода.

Плотность ошибок в коде - обычно измеряется как количество ошибок на тысячу строк исходного кода[78].

1.3 Классификация моделей оценки надежности программного обеспечения

Далее в работе проводится классификация существующих моделей, методов и алгоритмов оценки надежности программных средств.

Классификация по оптимизируемым параметрам надежности

Модели оптимизации сроков и стоимости проекта - такие модели используются для минимизации сроков разработки и стоимости проекта при сохранении должного уровня надежности ПО. Как правило, используются на ранних стадиях жизненного цикла разработки ПО [74,107,81].

Модели выбора оптимального набора мультиверсий в N-версионном ПО - используются разработчиками для поиска множества недоминируемых решений, удовлетворяющих критерию: максимум надежности при минимальных затратах [17,42,48-53,62,64].

Классификация по используемым формальным методам

По формальным методам модели можно проклассифицировать следующим образом:

Формальные математические модели - используют какую-либо математическую функцию для экстраполяции параметров надежности, например, для оценки плотности ошибок в коде используют экспоненциальную функцию.

Модели поведения ПО - делятся на статистические модели и модели ветвления хода выполнения (path-based) [75].

Модели ветвления используют описание внутренней структуры архитектуры ПО для оценки надежности, при этом описываются все возможные пути выполнения кода и оценивается надежность каждого пути.

Статистические модели, использующие исторические данные - аналогично формальным математическим моделям используют статистическую функцию для экстраполяции параметров надежности. Самые распространенные модели - это модели, использующие регрессию, с помощью которых по накопленным статистическим данным можно достаточно точно оценивать параметры надежности.

Марковские цепи используют для описания поведения структуры программного обеспечения, в таких моделях надежность ПО рассматривается как матрица вероятностей сбоев компонент архитектуры[75].

Нейро-сети - используются для экстраполяции параметров надежности. Для обучения нейро-сетей используют исторические данные или выходные данные других моделей.

1.3.3 Классификация моделей по их месту в процессе разработки

Проклассифицировать модели по их месту в процессе разработки можно следующим образом [14,15,118,38-40,46,47,70]:

- модели, использующиеся на стадии анализа;

- модели, использующиеся на стадии дизайна архитектуры;

- модели, использующиеся на стадии создания кода;

- модели, использующиеся на стадии тестирования;

- модели, использующиеся на стадии опытной эксплуатации;

- модели, использующиеся на стадии промышленной эксплуатации.

Прочие модели

Модели, использующие информацию об ошибках в коде, используются для предсказания количества ошибок в коде, зависимости надежности от количества строк в коде, оценки времени исправления оставшихся ошибок в коде.

Модели, использующие информацию о внутренней структуре ПО, вычисляют оценку надежности как ПО состоящего из компонент, или используются для моделирования структуры ПО как множества путей ветвления хода выполнения программы.

Модели, использующие искусственную эмуляцию ошибок, оценивают надежность путем прямого теста ПО с искусственным внедрением ошибочных данных или эмуляцией сбоев в аппаратном обеспечении.

Гибридные модели

Гибридные модели - используют различные комбинации из всех выше перечисленных классов моделей. Могут использоваться для оценки любых параметров надежности на разных этапах жизненного цикла программного обеспечения.

1.4 Методы и средства обеспечения надежности программного обеспечения

Методы проектирования надежного программного обеспечения

Методы проектирования надежного программного обеспечения можно разбить на следующие группы:

1. Предупреждение ошибок - методы, позволяющие минимизировать или исключить появление ошибки.

2. Обнаружение ошибок - методы направленные на разработку дополнительных функций программного обеспечения, помогающих выявить ошибки.

3. Устойчивость к ошибкам - дополнительные функции программного обеспечения, предназначенные для исправления ошибок и их последствий, обеспечивающие функционирование системы при наличии ошибок.

Методы предупреждения ошибок

Методы предупреждения ошибок концентрируются на отдельных этапах процесса проектирования программного обеспечения и включают в себя:

- методы достижения большей точности при преобразовании информации;

- методы улучшения обмена информацией;

- методы немедленного обнаружения и устранения ошибок.

Методы обнаружения ошибок

Методы обнаружения ошибок базируются на введении в программное обеспечение системы различных видов избыточности:

- Временная избыточность. Использование части производительности аппаратных средств для контроля исполнения и восстановления работоспособности ПО после сбоя.

- Информационная избыточность. Дублирование части данных информационной системы для обеспечения надёжности и контроля достоверности данных.

- Программная избыточность включает в себя: «взаимное недоверие» - компоненты системы проектируются, исходя из предположения, что другие компоненты и исходные данные содержат ошибки, и должны пытаться их обнаружить; немедленное обнаружение и регистрацию ошибок; выполнение одинаковых функций разными модулями системы и сопоставления результатов обработки; контроль и восстановление данных с использованием других видов избыточности.

Методы обеспечения устойчивости к ошибкам

Методы обеспечения устойчивости к ошибкам направлены на минимизацию ущерба, вызванного появлением ошибок, и включают в себя:

- обработку сбоев аппаратуры;

- повторное выполнение операций;

- динамическое изменение конфигурации;

- сокращенное обслуживание в случае отказа отдельных функций системы;

- копирование и восстановление данных;

- изоляцию ошибок.

1.5 Фазы разработки программного обеспечения

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

В общем случае жизненный цикл ПО можно разделить на следующие фазы [10,12,13,34,43-45,54,94]:

1. Концептуальная фаза. Построение общей концепции будущей информационной системы. Аналитики и эксперты проблемной области изучают поставленные задачи. Результатом фазы является общая концепция построения системы.

2. Определение требований. На данном этапе разработчики взаимодействуют с заказчиком для выявления потребностей и требований к системе. На этом этапе делается незначительное количество ошибок. Изменение требований на более поздних стадиях может повлечь появление большого количества ошибок.

3. Дизайн архитектуры. Строится спецификация взаимосвязей модулей таким образом, что каждый модуль четко разделен, разрабатывается и тестируется независимо. Дизайн может пересматриваться для выявления ошибок.

4. Кодирование. На данном этапе пишется реальный код программы, как правило, на языке высокого уровня. Иногда возможно использование низкоуровневых языков программирования для достижения высокой производительности или для сопряжения с нестандартной аппаратурой. Код постоянно анализируется на предмет наличия ошибок.

5. Тестирование. Эта фаза одна из самых важных и трудоемких. Может занимать от 30 до 60% временных и материальных ресурсов проекта. Обычно разделяется на несколько последовательных фаз.

5.1. Тестирование модулей. На этом этапе каждый модуль тестируется отдельно, делаются модификации модуля для исправления ошибок. Каждый модуль значительно меньше всей программы и может быть более тщательно протестирован.

5.2. Групповое тестирование. Модули группируются на подсистемы. Подсистемы тестируются независимо. Позволяет выявить ошибки в интерфейсах между модулями. Добавление и удаление модулей из подсистемы позволяет проще идентифицировать ошибки.

5.3. Тестирование системы. Тестируется вся система полностью. Отладка происходит до тех пор, пока не будет достигнут какой-либо критерий. Цель данного этапа - определить максимально возможное количество ошибок за минимальное время.

5.4. Тестирование приемлемости. Цель - оценка производительности и надежности в определенной операционной системе. Собирается информация о том, как пользователи будут использовать систему. Это называется «альфа-тестирование». Могут привлекаться реальные пользователи - в этом случае называется «бета-тестирование».

6. Использование. Система эксплуатируется и ошибки, выявленные пользователями, не исправляются пока не выйдет новая версия ПО.

7. Регрессивное тестирование. Новая версия тестируется на работоспособность и проверяется, не уменьшилась ли (регрессировала) надежность ПО.

Наиболее важными являются фазы, которые вносят наибольший вклад в надежность ПО: фаза дизайна архитектуры, фаза кодирования, фаза тестирования компонент и фаза тестирования системы.

1.6 Фаза дизайна архитектуры программного обеспечения

Широкое применение средств вычислительной техники породило понятие «архитектура ПО», которое, несмотря на свою распространенность, воспринимается, как правило, интуитивно и употребляется чаще всего при сравнении вычислительных машин.

Под архитектурой ПО, как и вообще любых других средств обработки информации, понимают в узком смысле совокупность их свойств и характеристик, призванных удовлетворить запросы пользователей. В более широком смысле, архитектура ПО - обобщенная модель информационной системы, достаточная для понимания принципов ее функционирования.

Создание архитектуры программного обеспечения, как этап проектирования информационной системы

Разработка архитектуры - это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы и уровни абстракции.

Процесс разработки архитектуры - необходимый шаг в процессе проектирования ПО или комплекса программ (КП). КП представляет собой набор решений множества различных, но связанных между собой задач.

Зависимость надежности от архитектуры программного обеспечения

Надежность архитектуры включает в себя надежность индивидуальных элементов. Сбой отдельного элемента приводит к неработоспособности этого и, возможно, других элементов, но не для всей системы в целом. Сбой в системе или ее функциях может выразиться в периоде простоя системы. Период простоя системы определятся, как отрезок времени, на котором система или ее часть не может выполнять функции. Период простоя системы приводит к резкому снижению производительности, поэтому уменьшение времени простоя системы является одним из наиболее важных факторов при разработке архитектур распределенного программного обеспечения.

Основные понятия теории надежности комплексов программ базируются на понятиях теории надежности, первоначально развившейся применительно к аппаратным комплексам, однако имеются существенные различия в принципах обеспечения надежности программного обеспечения и других технических систем.

В рамках определенного программного проекта трудоемкость создания и возможность достижения заданных параметров надежности определяются, с одной стороны, объемами выделенных ресурсов, а с другой технологическими средствами, используемыми при проектировании ПО.

Для достижения низких показателей сбоев для компонентов аппаратного обеспечения можно увеличить надежность дублированием наиболее критических компонентов архитектуры. В некоторых случаях, при отказе компонента, его функции могут выполняться дублирующим компонентом. Надежность программного обеспечения нельзя увеличить таким методом, поскольку дублирование компонентов ПО приведет также к дублированию его ошибок. Существуют методы, использующие разнообразие в спецификации, разработке, внедрении и тестировании.

Эксперименты показывают, что применение избыточности на самых ранних этапах разработки, насколько это возможно, уменьшает вероятность появления ошибок. Надежное ПО можно создать с помощью тщательной разработки архитектуры и выявления ошибок в компонентах, которые больше всего оказывают влияние на надежность системы. Эти компоненты определяются как наиболее часто используемые или архитектурно связанные с множеством других компонентов, влияя, таким образом, на их надежность.

Компоненты архитектуры

Модульная организация предполагает деление ПО на функционально завершенные части (модули), унификацию связей между ними и установление иерархии взаимодействия компонентов, которая определяется последовательностью их вызова. Вызов осуществляется передачей управления от вызывающего модуля к вызываемому, который по окончании выполнения возвращает управление вызывающему модулю. Вызов группы программ осуществляется передачей управления диспетчеру группы программ более низкого уровня иерархии, входящей в данный КП.

Основные методы современной практической разработки программных комплексов базируются на функциональной декомпозиции с использованием модульно-иерархических принципов [3,4,58,59]. При этом на каждом иерархическом уровне ограничивается сложность компонентов и их связей. В результате общая сложность системы растет значительно медленнее с возрастанием объема задач, чем при неструктурированном проектировании. Эти принципы привели к созданию структурного программирования, как стандартного способа построения модульных программ.

Определение модульной программы опирается на ограничения по размерам программ и на понятие их независимости, т.е. модульная программа должна состоять из модулей конечных размеров, которые имеют точку входа и точку выхода. Преимущества модульности состоят в упрощении проектирования и модификации программы, облегчении тестирования и отладки программ, возможности создания библиотеки стандартных модулей и т.д. Недостатки - увеличение времени исполнения программ и объема памяти, усложнение межмодульного взаимодействия - в целом окупаются выигрышем, получаемым от сокращения срока разработки и упрощения сопровождения программ.

Основным средством реализации модульности программ является структурное программирование. Целями структурного программирования служат повышение читабельности и ясности программ, увеличение производительности работы программистов и упрощение процесса разработки. Само понятие структурного программирования представляет собой некоторые принципы написания программ в соответствии с совокупностью определенных правил. Согласно «структурной теореме» для построения любой программы необходимы три основные базовые конструкции:

· простая вычислительная последовательность, означающая, что два действия должны выполняться одно за другим;

· альтернатива или ветвление, при котором на основе проверки некоторого условия делается выбор между двумя возможными путями;

· цикл или итерация, обеспечивающая повторное выполнение некоторой последовательности действий.

Применяемый при структурном программировании сквозной структурный контроль необходим для обнаружения и исправления ошибок на ранних стадиях проектирования, пока стоимость исправления ошибок минимальна, а последствия их наличия незначительны. Такой контроль обеспечивается регулярным обсуждением принятых решений всеми взаимодействующими разработчиками. Кроме того, базовые структуры, унификация правил взаимодействия компонентов и заведомо известная последовательность их разработки в порядке соподчиненности создают предпосылки для автоматизации процесса структурного контроля.

Модульность построения приводит к использованию иерархической структуры взаимодействия модулей программы. Иерархическая схема, отражая функции модулей, одновременно показывает структуру связей между ними. Иерархические структуры системы характеризуются, с одной стороны, вертикальным управлением, когда модули верхнего уровня имеют право вмешательства и координирования работы модулей нижнего уровня. С другой стороны, действия модулей верхнего уровня зависят от информации, полученной в результате функционирования нижних иерархических уровней. Таким образом, сверху вниз идут в основном управляющие воздействия, а снизу вверх - информация о соответствующих решениях и переменных.

Архитектура программного обеспечения формируется из ряда компонентов, соединенных различными средствами зависимости и связи. Архитектурный компонент может быть определен по-разному в зависимости от архитектурного подхода и степени подробности описания архитектуры. Наиболее критическими компонентами архитектуры программного обеспечения являются компоненты, к которым происходят частые обращения, или компоненты архитектурно связанные (через зависимости и связи) со множеством других компонентов, влияя таким образом на их надежность. Процесс - компонент, который занимает слот в таблице процессов процессора. Процессом может также быть компонент, который управляется как процесс через использование примитивов операционной системы. Модуль состоит из нескольких файлов, логически связанных и образующих часть функционального кода. Размер модуля может изменяться в широком диапазоне, и зависит от созданного прикладного программного обеспечения.

Свойства компонентов архитектуры

В зависимости от свойств архитектуры, компоненты программного обеспечения, а также их связи и зависимости могут быть определены по-разному. Рассматриваются следующие свойства архитектуры:

· статическая и динамическая зависимость компонентов;

· интерфейсы компонентов;

· связь и управление;

· загруженность системы.

Архитектура ПО со статической зависимостью компонентов формируется как дерево систем, подсистем, модулей, и функций. При этом подходе неисправность в более высоком узле уровня может привести к недоступности более низких узлов уровня. Эта архитектура со статической зависимостью компонентов не включает зависимость между динамическими процессами, таким образом, информации относительно использования компонентов программного обеспечения в течение обработки запросов пользователей, администрирования и сопровождения модель не дает.

При динамической зависимости компонентов программная архитектура формируется как граф процессов, которые используют подсистемы, модули и функции. Процессы могут выполняться, неоднократно с использованием тех же самых подсистем, модулей и функций. Процесс может использовать несколько различных функций в течение своего выполнения.

Интерфейсы компонентов включают описание взаимодействия между различными компонентами, а также интерфейсы внутри компонентов ПО, помещенных в различные аппаратные составляющие, в соответствии с аппаратными конфигурациями. Интерфейсы компонентов зависят от распределения программного обеспечения и от связей, наложенных аппаратной архитектурой.

Связь и управление включает связь (в смысле сообщений), имеющуюся между процессами при обработке запросов пользователя, а также при сопровождении и администрировании. Вследствие того, что различные компоненты программного обеспечения помещены в аппаратные компоненты, которые взаимосвязаны, аппаратная архитектура также воздействует на связь, и на управление.

Загруженность системы зависит от количества и типа запросов пользователя и от процедур администрирования и сопровождения. Загруженность системы отражается количеством и типом процессов и сообщений, и использованием компонентов программного обеспечения.

Надежность архитектуры программного обеспечения

Зависимости компонентов позволяют неисправности распространяться из компонента, в котором она происходит, к другим компонентам. Это распространение может вызывать сбои в цепочке (или в дереве) компонентов. Обнаружение отказов зависит от выполненных тестов или от количества и типа запросов пользователя. Ошибка может произойти в любом компоненте. Эта ошибка может быть вызвана сбоем, переданной другим компонентом, или это может быть сбой, произошедший именно в этом компоненте. Ошибка может быть прослежена через цепочку (или дерево) зависимости компонентов для устранения всех сбоев, которые связаны с этой ошибкой.

Уровни архитектуры

Надежность ПО зависит от уровня, соответствующего различным компонентам и их зависимостям. В зависимости от того, где произошел сбой, длительность отказа системы и его влияние на надежность системы различны. Сбой может происходить на различных уровнях архитектуры, в модуле, процессе, интерфейсе компонента или в связи и механизме контроля.

Число архитектурных уровней в модели архитектуры ПО зависит от частного проекта системы. Каждый архитектурный уровень содержит граф компонентов каждого типа (граф модулей и граф процессов) рисунок 1.1. Процессы используют модули в течение их выполнения: эти зависимости показаны прерывистыми линиями. Процесс может использовать несколько различных модулей, и модуль может использоваться несколькими различными процессами. Граф процессов представляет динамическую зависимость компонентов, а граф модулей представляет статическую зависимость компонентов. Эта архитектура может быть расширена до произвольного числа уровней с графами компонентов на различных уровнях.

Рисунок 1.1. Архитектурные уровни в модели архитектуры ПО

В модели архитектуры граф процессов находится на самом верхнем уровне, а графы остальных компонентов, например - функции, примитивы, данные, структуры и сообщения, находятся на отдельных уровнях.

В архитектуре программного обеспечения можно выделить следующие архитектурные уровни [62,76,110]:

· процессы;

· функции;

· примитивы;

· данные;

· структуры;

· сообщения.

Процесс - это компонент, который занимает ячейку в таблице процессов процессора. Процесс может также являться компонентом, который управляется с помощью примитивов операционной системы. Для каждого процесса в системе собрана информация относительно функций, примитивов, данных, структур, и сообщений, используемых процессом. Функции определены в той же самой подсистеме, что и процесс. Примитивы включают все функции вне подсистемы, в которой они определены, и вызываются функциями в процессе. Данные вызываются функциями в процессе. Структуры включают все структуры данных, вызванные функциями в процессе. Сообщения включают все данные, вызванные функциями в процессе.

Для числа изменений, вызванных неисправностями в модулях подсистемы ПО, собираются дополнительные данные. Используя эти данные, а также информацию относительно архитектуры, процессов системы, и дефектных изменений модуля, можно оценивать и изменять надежность архитектуры.

В крупных современных системах обработки информации часто используются СУБД, как компонент архитектуры. Быстродействие и надежность СУБД значительно влияет на надежность всей системы, поэтому оптимизации быстродействия СУБД должно уделяться больше внимания на всех стадиях разработки ПО [3,57,101-104]

Среднее время простоя системы

Среднее время простоя системы в архитектуре зависит от условных и безусловных вероятностей сбоев на всех уровнях архитектуры и от среднего времени доступа, анализа и восстановления сбойных компонентов. Время устранения сбоя равно времени, которое требуется для доступа, анализа, восстановления, это означает, что время восстановления меньше, чем время устранения сбоя. Если используется автоматическое восстановление и компонент не содержит сбоев, то он рассматривается как восстановленный компонент. Ошибка того же типа, что была устранена, считается новой ошибкой.

Среднее время простоя системы вычисляется для всех архитектурных уровней и всех компонентов на каждом уровне. Для каждого архитектурного уровня в ПО вероятность использования каждого компонента зависит от вероятности сбоя компонента и средних времен анализа, доступа и восстановления для этого компонента.

Вдобавок, сбойный компонент может вызывать сбои в зависящих от него компонентах, как на других уровнях архитектуры, так и на том же самом уровне. Поэтому, для каждого отдельного уровня архитектуры и для всех компонентов, надо учитывать условную вероятность появления сбоя и относительные времена доступа, анализа и восстановления этих компонентов. Также, для одного уровня и для всех компонентов, условная вероятность появления сбоя зависит от относительных времен доступа, анализа и восстановления этих компонентов.

Среднее время появления сбоя зависит от условных и безусловных вероятностей сбоев во всех компонентах на всех архитектурных уровнях и от относительного времени использования компонентов, в которых сбоя не происходит. Среднее время сбоя вычисляется для всех архитектурных уровней и всех компонентов на каждом архитектурном уровне.

В каждом отдельном архитектурном уровне и для всех компонентов, условная вероятность работы без сбоев зависит от относительного времени использования этих компонентов.

Коэффициент готовности архитектуры программного обеспечения

Время появления сбоя (MTTF) и среднее время простоя системы (TR) характеризуют возможность архитектуры программного обеспечения по обеспечению потенциальной производительности и для достижения этой производительности после отказа. Первый показатель связан с понятием отказа ПО, а второй - с понятием восстановления. Время появления сбоя позволяет пользователю оценить возможность решения той или иной задачи. Среднее время простоя информирует о том, когда отказавшая система будет восстановлена.

Время появления сбоя и среднее время простоя системы характеризуют поведение архитектуры ПО на начальном этапе работы вычислительной системы. Эти показатели не информативны при оценке работы архитектуры в течение длительного времени функционирования.

Готовность системы к эксплуатации в данный момент времени определяется как вероятность того, что система нормально функционирует в данный момент времени.

Коэффициент надежности архитектуры программного обеспечения

Надежность программного обеспечения определяется как вероятность того, что программное обеспечение функционирует без сбоев, в определенной операционной среде, в течение определенного промежутка времени. Коэффициент надежности архитектуры ПО можно оценить по формуле[89]:

, (1.1)

где M - число уровней архитектуры ПО;

Ni - число компонент на уровне i, i=1., M;

PU_ij - вероятность использования компонента;

R_ij - надежность компонента.

Оценить данные параметры на фазе разработки архитектуры невозможно, численные показатели в модель берутся непосредственно на фазах кодирования и тестирования.

1.7 Фаза кодирования

Количество ошибок в выполнимом коде напрямую зависит от ошибок, сделанных на стадии кодирования. Одним из самых часто используемых параметров оценки корректности ПО является плотность ошибок.

Начальную плотность ошибок можно оценить как[93]:

, (1.2)

где

F_ph - коэффициент фазы тестирования;

F_pr - коэффициент командного программирования;

F_m - коэффициент опытности и «зрелости» процесса разработки ПО;

F_s - коэффициент структурирования;

С - константа, определяющая кол-во ошибок/KLOC (ошибок на тысячу строк исходного кода).

Коэффициенты F_pr, F_m, F_s и С зависят только от мастерства и опыта команды разработчиков.

Коэффициент командного программирования (F_pr): плотность ошибок зависит от конкретных людей, их опыта написания программ и отладки.

Можно принять следующие значения параметра: «Высокий», «Средний», «Низкий». Числовые показатели определяются и задаются экспертом.

Коэффициент опытности и «зрелости» процесса разработки ПО (F_m).

Можно принять следующие значения параметра: «Уровень 1», «Уровень 2»,

«Уровень 3», «Уровень 4», «Уровень 5». Числовые показатели определяются и задаются экспертом.

Коэффициент структурирования (F_s): Этот параметр берет во внимание зависимость плотности ошибок от языка программирования (отношение количества кода на ассемблере и языка высокого уровня)

F_s=1+0.4а, (1.3)

где а - отношение количества кода на ассемблере и языка высокого уровня. Предполагается, что код на ассемблере может содержать на 40% ошибок больше.

1.8 Фаза тестирования

Фаза тестирования самая продолжительная и может занять до 60% от всего проекта. Во время тестирования выявляется самое большое количество ошибок в ПО.

Рассмотрим меры покрытия теста, используемые на данной фазе:

- покрытие выражений - доля всех условных выражений, выполненных во время теста;

- покрытие ветвлений - доля всех ветвлений, выполненных во время теста;

- покрытие предикатов - доля всех переменных, которые используются для проверки условий перед условным переходом.

В начальной плотности ошибок (1.2) коэффициент фазы тестирования (F_ph) принимает следующие значения[93]: «Тестирование модуля», «Подсистемы», «Системы», «Приемлемость». Числовые показатели определяются и задаются экспертом.

Параметры для оценки D по выражению (1.2) должны быть скорректированы с использованием данных, накопленных в результате деятельности разработчиков ПО. Коэффициент С обычно лежит в диапазоне от 6 до 20 ошибок/KLOC. Можно брать как средние значения, так и MAX и MIN значения для оценки диапазона плотности ошибок.

Методология тестирования программного обеспечения

Для тестирования ПО берется набор выходов программы и наблюдается реакция системы. Если ответ отличен от ожидаемого, то ПО имеет хотя бы одну ошибку. Тестирование преследует две цели: увеличить надежность так быстро, как это возможно и найти максимальное количество ошибок. С другой стороны, в течение испытаний, цель состоит в том, чтобы оценить надежность, таким образом, уровень найденных ошибок должен соответствовать фактическому.

Методы тестирования программных средств можно разделить на два основных класса[92]:

1. «Черный ящик» (функциональное тестирование). Для тестирования рассматриваются только входы и выходы ПО. Внутренняя структура ПО во внимание не берется. Это наиболее общий способ тестирования.

2. «Белый ящик» (структурное тестирование). Для теста используются знания о структуре ПО.

На практике комбинация двух методов приводит к наилучшим результатам. Тестирование ПО как «черный ящик» требует функционального описания программы, хотя, некоторая информация о структуре позволяет тестировщикам выбрать наилучшие параметры для входов системы. Выбор входов может происходить случайным образом или разбиваться на группы. Группы входов могут подвергаться более тщательному тестированию. Комбинирование двух способов выбора входных диапазонов тоже применяется для тестирования ПО.

Некоторые ошибки достаточно легко обнаружить - это ошибки, имеющие высокий уровень обнаружимости. Ошибки, которые трудно обнаружить, называются ошибками с низким уровнем обнаружимости - они появляются при очень редко встречающихся комбинациях значений входных диапазонов. В начале тестирования большое количество ошибок имеет высокий уровень обнаружимости - они легко обнаруживаются и устраняются. На последующих стадиях остаются ошибки, имеющие низкий уровень обнаружимости.

Тщательность тестирования может быть измерена с помощью коэффициента полноты покрытия теста. Коэффициент покрытия ветвлений кода - более четкая мера, чем коэффициент покрытия выражений. Некоторые разработчики используют коэффициент покрытия ветвлений равный 0.85, как минимальное значение коэффициента.

Чтобы оценить операционную (транзакционную) надежность ПО, тестирование должно быть выполнено в соответствии с операционными профилями. Операционный профиль - множество несвязанных и непересекающихся входных диапазонов и вероятностей их использования компонентами. Для разных операционных систем профили могут различаться. Получение операционного профиля требует разделения пространства входных диапазонов на подмножества(листья), и затем оценки вероятностей использования каждого подмножества(листа). Подмножество с достаточно высокой вероятностью использования может быть разделено на зоны меньшего размера.

Моделирование роста надежности программного обеспечения

Доля достижения требуемого уровня надежности ПО может достигать 60% ресурсов проекта. Следовательно, тестирование должно быть тщательным образом спланировано для реализации проекта к заданной дате. Даже после длительного периода тестирования, дополнительное тестирование может выявить новые ошибки. ПО выходит из проекта с должным уровнем надежности, но все равно содержит ошибки. Для планирования и принятия решений используются SGRM (Software Growth Reliability Model) - модели роста надежности ПО[92]. В модели SGRM предполагается, что надежность растет пропорционально времени тестирования, которое может быть измерено во времени использования процессора. Рост надежности определяют в терминах интенсивности сбоев л(t) или количества ожидаемых ошибок за время t м(t).