Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 03.11.2013
Размер файла 280,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

, (3.23)

где c функция, вычисляемая компонентом.

Системный проектировщик использует входной профиль для компонента C, сам C (для того чтобы вычислить c путем ее выполнения), Si из таблицы данных C, и требуемое разложение подобластей выхода (Ui, берется из таблицы компонента следующего за C по проекту). Каждая Si может быть опробована случайным образом, и пробные точки С отобразятся в Ui. Деление точек из Si, попадающих в каждую из Ui, взвешенное с помощью hi, это вклад в kj от Si.

Пример применения операционных профилей

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

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

с вероятностями сбоя 0.01, 0, 0.001. Оценки вероятностей сбоя можно получить от разработчика компонента полным тестированием на малых подобластях, и тестированием с помощью случайного равномерного распределения, не обнаружившим ошибок на больших подобластях. Предположим, что входной профиль для А это <0. 3,0. 1,0.6>.

Тогда надежность компонента А:

Предположим, что таблица данных B содержит четыре подобласти:

с вероятностями сбоя 0.1, 0, 0, 0.02 соответственно.

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

Подобласть (диапазон)

от

от

от

0

0

0

0.003

1

0.002

0.147

0

0.162

0.850

0

0.836

k1= 0.3 (0)+0.1 (0)+0.6 (0)=0

k2=0.3 (0.003)+0.1 (1.0)+0.6 (0.002)=0.102

k3= 0.3 (0.147)+0.1 (0)+0.6 (0.162)=0.141

k4= 0.3 (0.850)+0.1 (0)+0.6 (0.836)=0.757

Тогда профиль В, видимый из А это <0,0. 102,0. 141,0.757> и надежность В это: RB = 0 (1-0.1)+0.102 (1-0)+0.141 (1-0)+0.757 (1-0.02)=0.986

Надежность системы в данной последовательности вычисляется как

RARB = 0.996 (0.986)=0.982.

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

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

Фаза построения архитектуры объектно-ориентированного программного обеспечения

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

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

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

Рисунок 3.1. Ход выполнения процесса через методы классов

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

Определим:

F - общее число компонент в архитектуре ПО;

Ri - коэффициент надежности компонента i, i=1., F;

Ci - стоимость разработки компонента i, i=1., F;

PUi - вероятность использования компонента i, i=1., F;

PFi - вероятность сбоя в компоненте

PLij - условная вероятность сбоя в компоненте i при сбое в компоненте j, i=1., F, j=1., F;

TAi - относительное время доступа к компоненту i, i=1., F;

TUi - относительное время использования компонента i, i=1., F;

S - коэффициент готовности системы;

Rs - коэффициент надежности системы.

Для данной модели обязательно выполнение условия:

(3.24)

Параметры TR и MTTF надежности архитектуры можно записать в виде:

(3.25)

(3.26)

Коэффициент готовности системы вычисляется по формуле

S= MTTF / (MTTF+TR) (3.27)

Коэффициент надежности системы вычисляется как:

, (3.28)

где (3.29)

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

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

Определим:

F - общее число компонент(классов) в архитектуре ПО;

Ri - коэффициент надежности компонента i, i=1,…, F;

Ci - стоимость разработки компонента i, i=1,…, F;

Zi - множество версий компонента i, i=1,…, F;

PUi - вероятность использования компонента i, i=1,…, F;

PFi - вероятность сбоя в компоненте i, i=1,…, F;

PLij - условная вероятность сбоя в компоненте i при сбое в компоненте j, i=1,…, F, j=1,…, F;

TAi - относительное время доступа к компоненту i, i=1,…, F;

TCi - относительное время анализа сбоя в компоненте i, i=1,…, F;

TEi - относительное время устранения сбоя в компоненте i, i=1,…, F;

TUi - относительное время использования компонента i, i=1,…, F;

TR - среднее время простоя системы;

MTTF - среднее время появления сбоя;

S - коэффициент готовности системы;

Rs - коэффициент надежности системы.

Для данной модели обязательно выполнение условия:

(3.30)

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

, (3.31)

где Rmul - надежность DI мета-класса, реализующего механизмы мультиверсионности. Этот класс не должен рассматриваться как компонент архитектуры и должен быть исключен из расчетов TR, MTTF и Rs.

Среднее время простоя системы вычисляется как:

(3.32)

Среднее время появления сбоя вычисляется как:

(3.33)

Коэффициент готовности системы вычисляется по формуле (3.27)

Коэффициент надежности системы вычисляется по формуле (3.28)

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

Для каждого компонента на данной фазе оценим Tr (время тестирования, необходимое для достижения надежности R) - если мы желаем узнать время, необходимое для тестирования класса, чтобы получить заданный уровень надежности, или Tf (время тестирования, необходимое для достижения низкого уровня сбоев) - если необходимо достичь заданного уровня интенсивности сбоев. Tr или Tf рассчитывается для каждого класса или метода по формулам (3.17) и (3.18).

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

На данной фазе заполняются операционные профили всех компонент системы.

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

Для мультиверсионного ПО необходимо выбрать такой набор версий избыточных компонент, чтобы обеспечить максимум надежности при минимальной стоимости разработанных модулей [5,11,16]. Множество недоминируемых решений можно найти полным перебором или использовать достаточно хорошо проверенные методы оптимизации [31,32,55,61,42,45].

Оценка параметров надежности

Параметры, полученные по завершению фазы тестирования, используются для расчета TR, MTTF, S по выражениям (3.30) (3.31) и (3.32).

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

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

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

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

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

Определим:

m - общее количество классов;

n - общее количество транзакций;

Ki - класс, i=1,…, m;

Oi - операционный профиль (множество входных диапазонов) i-го класса, i=1,…, m;

Fi - вектор, отображающий вероятности сбоя i-го класса для каждого входного диапазона, i=1,…, m;

fil - l-ый элемент вектора Fi, l - размерность вектора Fi;

Tj - транзакция, j=1,…, n;

Dj - множество классов принадлежащих j-ой транзакции, j=1,…, n;

Hij - вектор вероятностей использования диапазона значений i-го класса в j-ой транзакции;

hijk - k-й элемент вектора Hij.

Wij - вес(надежность) i-го класса j-ой транзакции;

PUj - вероятность использования j-ой транзакции, сумма всех PU равна 1;

Rtj - надежность j-ой транзакции;

Rtr - транзакционная надежность всей системы;

Вес(надежность) i-го класса j-ой транзакции определятся по формуле:

(3.34)

Надежность транзакции можно вычислить как:

(3.35)

После вычисления надежностей всех транзакций вычисляется общая транзакционная надежность системы:

(3.36)

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

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

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

Пример расчета транзакционной надежности:

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

K1: f1={0.01; 0; 0.001}

K2: f2={0; 0; 0.05}

K3: f3={0; 0.001; 0.001}

Имеется 2 транзакции с известными вероятностями использования диапазонов классов и вероятностями использования транзакций:

T1:

PU1=0.7

H11={0.3; 0.1; 0.6}

H12={0.4; 0.4; 0.2}

H13={0.8; 0.1; 0.1}

T2:

PU2=0.3

H21={0.2; 0.2; 0.6}

H22={0.3; 0.7; 0}

H23={0; 0.9; 0.1}

Вычислим веса Wij:

W11 = 0.3 x (1-0.01) + 0.1 x (1-0) + 0.6 x (1-0.001) = 0.9964

W12 = 0.4 x (1-0) + 0.4 (1-0) + 0.2 x (1-0.05) = 0.9

W13 = 0.8 x (1-0) + 0.1 x (1-0.0001) + 0.1 x (1-0.0001) = 0.9998

Аналогично вычисляем:

W21 = 0.9974

W22 = 0

W23 = 0.9990

Получаем:

Rt1= W11 x W12 x W13 = 0.8966

Rt2= W21 x W22 x W23 = 0.9964

И в итоге: Rtr= 0.7 x 0.8966 + 0.3 x 0.9964 = 0.9265

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

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

Такая модель является полезной для оценки информационных систем обработки и хранения данных, например, для современных ERP-систем.

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

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

4.1 Общие сведения

В качестве среды для разработки системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств была выбрана современная система Microsoft Business Solutions-Axapta.

Факты в пользу выбора системы Microsoft-Axapta [95-99]:

- Система Microsoft-Axapta написана на объектно-ориентированном языке Х++, схожий по синтаксису с С++ и Java;

- Система Microsoft-Axapta имеет открытый код доступный для модификаций;

- Система Microsoft-Axapta имеет встроенные средства визуального программирования;

- Система Microsoft-Axapta имеет около 2000 классов, реализующих бизнес-логику системы;

- Система Microsoft-Axapta имеет встроенный профайлер кода с детализацией времени выполнения до строки исходного кода;

- Система Microsoft-Axapta имеет встроенные средства мониторинга и трассировки ошибок;

- В системе Microsoft-Axapta имеется возможность организации распределенных вычислений.

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

Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств реализована в виде модуля «Модели надежности» ERP-системы Microsoft-Axapta.

Логика системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств написана на языке Х++ в виде иерархии классов и интегрирована в логику Microft-Axapta. Конечные и промежуточные результаты сохраняются в базе данных для возможности их дальнейшего анализа.

В модуле «Модели надежности» реализованы модели:

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

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

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

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

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

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

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

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

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

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

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

Рисунок 4.2. Иерархия классов моделей оценки надежности ПО

RModel является абстрактным классом моделей оценки надежности.

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

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

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

Таблица 4.1. Методы класса RModel - реализация в системе Microsoft-Axapta

Имя метода

Описание

Conainer LoadResults(ModelTable)

Загрузить результаты расчетов

Void SaveResults(ModelTable)

Сохранить результаты расчетов

ModelTable FindResults(ModelTable)

Найти результаты расчетов

Conainer LoadParms()

Загрузить параметры

Void SaveParms()

Сохранить параметры

ModelTable FindParms()

Найти параметры

Void InitParam(container)

Инициализировать параметры модели значениями по умолчанию (Должен быть перекрыт в дочерних классах)

New()

Метод - конструктор

ClassDescription description()

Метод - описание класса (должен быть перекрыт в дочернем классе)

Таблица 4.2. Методы класса RModel_OO - реализация в системе Microsoft-Axapta

Имя метода

Описание

Container ClacTR()

Расчет TR

Container ClacMTTF()

Расчет MTTF

Container ClacS()

Расчет S

Container ClacTf()

Расчет Tf

Container ClacTr()

Расчет Tr

Container ClacRs()

Расчет Rs - надежность системы

Container ClacRop()

Расчет Rop - надежность с операционными профилями

New()

Метод - конструктор

Void InitParam(container)

Инициализировать параметры модели значениями по умолчанию

ClassDescription description()

Метод - описание класса

*

Остальные методы наследуются из родительского класса

Таблица 4.3. Методы класса RModel_OO_NVP - реализация в системе Microsoft-Axapta

Имя метода

Описание

Container ClacTR()

Расчет TR

Container ClacMTTF()

Расчет MTTF

Container ClacS()

Расчет S

Container ClacTf()

Расчет Tf

Container ClacTr()

Расчет Tr

Container ClacRs()

Расчет Rs - надежность системы

Container ClacRop()

Расчет Rop - надежность с операционными профилями

New()

Метод - конструктор

Void InitParam(container)

Инициализировать параметры модели значениями по умолчанию

ClassDescription description()

Метод - описание класса

*

Остальные методы наследуются из родительского класса

Таблица 4.4. Методы класса RModel_OO_TR - реализация в системе Microsoft-Axapta

Имя метода

Описание

Container ClacRtr()

Расчет Rtr - надежность транзакции

Container ClacR()

Расчет R - транзакционная надежность системы

Void InitParam(container)

Инициализировать параметры модели значениями по умолчанию

ClassDescription description()

Метод - описание класса

*

Остальные методы наследуются из родительского класса

Логическая структура данных

Структура данных модуля «Модели Надежности» состоит из семи таблиц приведенных ниже.

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

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

Рисунок 4.3. Логическая структура данных модуля «Модели Надежности»

Таблица 4.5. ClassTable - таблица описывающее все множество классов

Имя поля

Описание

ClassTableId

Уникальный код класса

ClassName

Имя класса

ClassDescription

Описание класса

Таблица 4.6. DevelopParam - параметры этапа кодирования

Имя поля

Описание

DevelopParamId

Уникальный идентификатор набора параметров

Fph

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

Fpr

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

Fm

коэффициент опытности процесса разработки ПО

Fs

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

Cmax

MAX константа, определяющая кол-во ошибок/KLOC

Cmin

MIN константа, определяющая кол-во ошибок/KLOC

Таблица 4.7. ModelTable - таблица моделей

Имя поля

Описание

ModelTableId

Уникальный идентификатор

ModelName

Название модели

ModelDescription

Описание

ModelType

Тип модели

ModelDateTime

Дата и время создания модели

F

общее число компонент(классов) в архитектуре

TR

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

MTTF

среднее время появления сбоя

S

коэффициент готовности системы

Rs

коэффициент надежности системы

Rtr

транзакционная надежность системы

Таблица 4.8. ClassInModel - множество классов модели и параметры классов

Имя поля

Описание

ClassInModelId

Уникальный идентификатор

ModelTableId

Внешний ключ - ссылка на таблицу ModelTable

ClassTableId

Внешний ключ - ссылка на таблицу ClassTable

Ri

коэффициент надежности компонента

Ci

стоимость разработки компонента

PUi

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

PUi

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

TAi

относительное время доступа к компоненту

TCi

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

TEi

относительное время устранения сбоя в компоненте

TUi

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

PFi

вероятность сбоя в компоненте

Tf

время тестирования, необходимое для достижения желаемого уровня интенсивности сбоя

Tr

время тестирования, необходимое для достижения желаемого уровня надежности

Таблица 4.9. ClassRelation - взаимосвязи между классами

Имя поля

Описание

ClassRelationId

Уникальный ключ

ClassInModelId

Ссылка на таблицу ClassInModelId

ClassTableIdi

Ссылка на класс

ClassTableIdj

Ссылка на класс

PLij

условная вероятность сбоя в компоненте i при сбое в компоненте j

Таблица 4.10. ClassInTrans - множество классов транзакции и параметров классов

Имя поля

Описание

ClassInTransId

Уникальный ключ

ModelTableId

Внешний ключ - ссылка на таблицу ModelTable

ClassTableId

Внешний ключ - ссылка на таблицу ClassTable

PUj

вероятность использования транзакции

Rtj

надежность транзакции

W

вес операционного профиля в транзакции

Таблица 4.11. ClassProfile - операционные профили классов

Имя поля

Описание

ClassProfileId

Уникальный ключ

ClassInModelId

Ссылка на таблицу ClassInModelId

RangeType

Тип диапазона из профиля

RangeMin

MIN значение диапазона

RangeMax

MAX значение диапазона

RangeStep

Шаг диапазона

Pis

Вероятность использования диапазона из операционного профиля

Таблица 4.12. TransProfile - операционные профили транзакций

Имя поля

Описание

TransProfileId

Уникальный ключ

TransInModelId

Ссылка на таблицу TransInModelId

RangeType

Тип диапазона из профиля

RangeMin

MIN значение диапазона

RangeMax

MAX значение диапазона

RangeStep

Шаг диапазона

Pis

Вероятность использования диапазона из операционного профиля

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

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

Ниже на рисунке изображена иерархия классов, реализующих механизмы мультверсионных вычислений.

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

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

Рисунок 4.4. Иерархия классов, реализующих механизмы мультиверсионности

Класс NVP (N Version Programming) является абстрактным классом.

Класс NVP_CC - реализация мультиверсионности компонент с контрольными точками и возможностью восстановления компонент.

Класс NVP_R - реализация мультиверсионности компонент со сравнением только конечных результатов компонент.

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

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

Рисунок 4.5. Логическая структура класса NVP

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

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

Рисунок 4.6. Логическая структура класса NVP_R

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

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

Рисунок 4.7. Логическая структура класса NVP_CC

Таблица 4.13. Класс NVP - реализация в системе Microsoft-Axapta

Имя метода

Описание

Boolean canSwapBetweenCS()

Метод проверяет, может ли экземпляр класса быть перемещен с клиента на сервер

void deleteLast()

Метод работы с виртуальным хранилищем - удаляет последнее состояние объекта

void getLast()

Метод работы с виртуальным хранилищем - восстанавливает последнее состояние объекта

void saveLast()

Метод работы с виртуальным хранилищем - сохраняет последнее состояние объекта

boolean inGetSaveLast()

Проверка успешности последней операции с виртуальным хранилищем

void initParmDefault()

Метод вызывается, когда GetLast() ничего не возвращает для установления состояния объекта по умолчанию

boolean unpack (container packedClass)

Распаковывает состояние объекта из контейнера (должен быть перекрыт в дочернем классе)

public container pack()

Упаковывает состояние объекта в контейнер (должен быть перекрыт в дочернем классе)

ClassDescription description()

Метод - описание класса (должен быть перекрыт в дочернем классе)

Object makeObject (classId classId)

Метод создает объект

object makeObjectOnClient (classId classId)

Метод создает объект на клиенте

object makeObjectOnServer (classId classId)

Метод создает объект на сервере

container promptOnClient (classId classId, container packed)

Метод создает объект на клиенте, распаковывает контейнер с состоянием объекта и запускает на выполнение

void runOnServer (classId classId, container packed)

Метод создает объект на сервере, распаковывает контейнер с состоянием объекта и запускает на выполнение

New()

Метод - конструктор

Run()

Метод, в котором находится логика компонента (должен быть перекрыт в дочернем классе)

container FindClients()

Метод предназначен для поиска клиентских частей для распределенных вычислений

Таблица 4.14. Класс NVP_CC - реализация в системе Microsoft-Axapta

Имя метода

Описание

Void init()

Инициализация параметров

New()

Метод - конструктор

Run()

Метод, в который помещается логика для параллельного выполнения

boolean unpack (container packedClass)

Распаковывает состояние объекта из контейнера

public container pack()

Упаковывает состояние объекта в контейнер

ClassDescription description()

Метод - описание класса

void SynhroniseClients()

Метод производит синхронизацию клиентских частей

container CompareStates(container)

Метод «решающий блок(модуль)» - производит сравнение абстрактных состояний версий компонент

boolean RestoreState (container, classId)

Метод, восстанавливающий абстрактное состояние версии компонента

*

Остальные методы наследуются из родительского класса

Таблица 4.15. Класс NVP_R - реализация в системе Microsoft-Axapta

Имя метода

Описание

Void init()

Инициализация параметров

New()

Метод - конструктор

Run()

Метод, в который помещается логика для параллельного выполнения

boolean unpack (container packedClass)

Распаковывает выходы объекта из контейнера

public container pack()

Упаковывает выходы объекта в контейнер

ClassDescription description()

Метод - описание класса

container CompareExits(container)

Метод производит сравнение выходов версий компонент

*

Остальные методы наследуются из родительского класса

4.5 Описание функционирования системы

Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств реализована в виде модуля ERP системы Microsoft Business Solutions-Axapta.

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

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

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

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

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

4.6 Примеры решения задач и анализ результатов

В качестве примера будем рассматривать проект создания модуля «Управление автотранспортом» в системе Microsoft Business Solutions-Axapta.

Фаза создания архитектуры

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

Фазы кодирования и тестирования компонент

Необходимо определить начальную плотность ошибок в коде.

Перед началом данных этапов известна следующая априорная информация:

- Коэффициент командного программирования Fpr определяется как «средний» и равен 1;

- Коэффициент опытности Fm определятся как «Уровень 3» и равен 0.4;

- Границы коэффициента С лежат в диапазоне от 6 до 20;

- Коэффициент структурирования Fs примем равным 1;

- Коэффициент фазы тестирования будем использовать «тестирование модуля» - он равен 4.

Количество тысяч строк кода в каждом классе равно:

K1 - 1.1

K2 - 3.2

K3 - 2.0

K4 - 0.6

K5 - 0.3

K6 - 0.9

K7 - 1

K8 - 1.2

K9 - 2.2

K10 - 1.4

K11 - 0.4

K12 - 0.5

K13 - 1

K14 - 1.2

K15 - 1.7

K16 - 0.7

K17 - 0.6

K18 - 0.9

В результате получаем следующие расчетные данные:

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

класс

L (тыс. строк)

B1

N0max=B0

Rm

Tr

Trh (Чел.час)

K1

1,100000

90,909000

88

0,990000

18,290000

91,440000

K2

3,200000

31,250000

256

0,990000

19,360000

96,780000

K3

2,000000

50,000000

160

0,990000

18,890000

94,430000

K4

0,600000

166,667000

48

0,990000

17,680000

88,410000

K5

0,300000

333,333000

24

0,990000

16,990000

84,940000

K6

0,900000

111,111000

72

0,990000

18,090000

90,440000

K7

1,000000

100,000000

80

0,990000

18,190000

90,960000

K8

1,200000

83,333000

96

0,990000

18,370000

91,870000

K9

2,200000

45,455000

176

0,990000

18,980000

94,900000

K10

1,400000

71,429000

112

0,990000

18,530000

92,640000

K11

0,400000

250,000000

32

0,990000

17,280000

86,380000

K12

0,500000

200,000000

40

0,990000

17,500000

87,500000

K13

1,000000

100,000000

80

0,990000

18,190000

90,960000

K14

1,200000

83,333000

96

0,990000

18,370000

91,870000

K15

1,700000

58,824000

136

0,990000

18,720000

93,620000

K16

0,700000

142,857000

56

0,990000

17,840000

89,180000

K17

0,600000

166,667000

48

0,990000

17,680000

88,410000

K18

0,900000

111,111000

72

0,990000

18,090000

90,440000

В таблице Rm - желаемый уровень надежности, Tr - время тестирования, необходимое для достижения надежности Rm. Trh - время тестирования в человеко-часах (для пересчета использовался коэффициент 5).

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

В реальном проекте на тестирование 18 классов было потрачено 1700 человеко-часов.

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

В качестве примера рассмотрим формирование 2 типов в модуле «Управление автотранспортом» системы Microsoft-Axapta.

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

Таблица 4.17. Операционные профили классов

Классы

Вероятности сбоя в диапазоне

1

2

3

4

K1

0,000010

0

0,000070

0

К2

0

0

0,000010

0,000010

К3

0

0,000040

0,000550

К4

0

0

0

0,000050

К5

0

0

0,000020

0

К6

0,000340

0

0

0

К7

0

0

0,001100

0

К8

0

0

0

0,000090

К9

0

0,000001

0

0

К10

0

0,000440

0

0

К11

0,000670

0

0

0

К12

0

0

0

0,000010

К13

0,000180

0

0

0

К14

0

0,000580

0

0

К15

0

0

0,000001

0

К16

0,000010

0

0

0

К17

0

0

0,000050

0

K18

0

0,000010

0

0

Вероятности использования транзакций равны:

PU1=0,330000;

PU2=0,250000;

PU3=0,150000;

PU4=0,270000;

Опишем подмножества классов входящих в транзакции:

D1={1,2,4,5,6,8,9,11,13,14,15,17,18};

D2={1,2,3,4,5,6,16,17,18};

D3={2,3,5,7,8,10,12,15,16,17};

D4={6,7,8,15,16,17,18};

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

Таблица 4.18. Вектора вероятностей использования диапазонов и вектора весов транзакции Т1

Класс

Вероятности использования диапазонов

W1i

1

2

3

4

K1

0

0,100000

0,900000

0

0,999937

K2

0,500000

0,500000

0

0

1

K4

0

0,140000

0,030000

0,830000

0,999959

K5

0,150000

0,250000

0

0,6

1

K6

0,005000

0,044000

0,456000

0,495000

0,999998

K8

0

0,550000

0,262000

0,188000

0,999983

K9

0,999000

0,001000

0

0

1

K11

0

0,727000

0,005000

0,268000

1

K13

1

0

0

0

0,999820

K14

0

0,441000

0,334000

0,225000

0,999744

K15

0

0,456000

0

0,544000

1

K17

0,745000

0,111000

0

0,144000

1

K18

0

0,498000

0,229000

0,273000

0,999995

Таблица 4.19. Вектора вероятностей использования диапазонов и вектора весов транзакции Т2

Класс

Вероятности использования диапазонов

W2i

1

2

3

4

K1

0,045000

0,665000

0

0,290000

1

K2

0

0

0,546000

0,454000

0,999990

K3

0,564000

0,339000

0,097000

0

0,999933

K4

0,002200

0,056800

0,655000

0,286000

0,999986

K5

0

0,500000

0

0,500000

1

K6

0

0,556000

0,444000

0

1

K16

0,800000

0,180000

0,020000

0

0,999992

K17

0,100000

0

0,900000

0

0,999955

K18

0,003000

0

0,664000

0,333000

1

Таблица 4.20. Вектора вероятностей использования диапазонов и вектора весов транзакции Т3

Класс

Вероятности использования диапазонов

W3i

1

2

3

4

K2

0

0,333000

0,667000

0

0,999993

K3

0,995000

0,001000

0,004000

0

0,999998

K5

0,250000

0,250000

0,500000

0

0,999990

K7

0,333000

0,333000

0

0,334000

1

K8

0

0,125000

0,125000

0,750000

0,999933

K10

0,334000

0,556000

0,001000

0,109000

0,999755

K12

0,669000

0,223000

0,002000

0,106000

0,999999

K15

0,550000

0,330000

0

0,120000

1

K16

0

0

0,500000

0,500000

1

K17

0,222000

0,650000

0,128000

0

0,999994

Таблица 4.20. Вектора вероятностей использования диапазонов и вектора весов транзакции Т4

Класс

Вероятности использования диапазонов

W4i

1

2

3

4

K6

0

1

0

0

1

K7

0,250000

0,250000

0,250000

0,250000

0,999725

K8

0

0,333000

0,556000

0,111000

0,999990

K15

0

0,333000

0

0,667000

1

K16

0,333000

0,333000

0,334000

0

0,999997

K17

0

0,999000

0,001000

0

1

K18

0,250000

0,125000

0

0,625000

0,999999

Имея все необходимые данные, рассчитаем надежности каждой транзакции:

Rt1 = 0,999436

Rt2 = 0,999855

Rt3 = 0,999662

Rt4 = 0,999710

В результате получаем итоговую транзакционную надежность:

Rtr =0,999649

Получается, что при работе с данными типами документов система будет давать сбой в 351 случае из 106, при условии, что оператор не совершает ошибок.

В результате реального теста, по которому был сделан расчет, из 106 транзакций неуспешно завершились 338 транзакции.

Ценность эксперимента заключается в том, что были выявлены классы и их входные диапазоны, которые вносят набольший вес в вероятность сбоя. Это позволило уделить больше внимания тестированию и выявлению ошибок в коде и в «узких местах» тестируемой системы.

Наибольший вес в вероятность сбоя вносят классы: К7, К10, К14. Уменьшив вероятность сбоя на входных диапазонах в этих классах в два раза можно достичь следующих результатов:

Rt1 = 0,999564

Rt2 = 0,999855

Rt3 = 0,999784

Rt4 = 0,999860

В результате получаем новую транзакционную надежность:

Rtr = 0,999750

Фаза эксплуатации

Вычислим коэффициент готовности системы S, для этого необходимо получить значения TR и MTTF.

Таблица 4.21. Исходные данные для вычисления TR и MTTF

класс

PUi

PFi

Tai (мсек)

TUi(мсек)

K1

0,001000

0,000063

0,100000

1,400000

K2

0,130000

0,000017

0,700000

1,600000

K3

0,105000

0,000069

0,400000

2,100000

K4

0,062000

0,000056

0,900000

0,900000

K5

0,053000

0,000010

0,200000

3,700000

K6

0,074000

0,000002

0,200000

6,200000

K7

0,004000

0,000275

0,500000

1,100000

K8

0,003000

0,000094

0,800000

0,900000

K9

0,029000

0,000000

0,900000

0,300000

K10

0,107000

0,000245

0,100000

0,100000

K11

0,151000

0,000000

0,100000

0,600000

K12

0,093000

0,000001

0,400000

0,600000

K13

0,033000

0,000180

0,700000

2,700000

K14

0,037000

0,000256

0,200000

3,400000

K15

0,075000

0,000000

0,400000

5,200000

K16

0,022000

0,000011

0,100000

6,400000

K17

0,018000

0,000051

0,600000

1,800000

K18

0,003000

0,000006

0,800000

6,200000

Условные вероятности сбоев PLij на практике оказываются равными 0, если выходные значения одного класса проверяются на входе другого класса, иначе сбой распространяется в другой класс и тогда условная вероятность равна

TR = 0,000018 сек.

MTTF = 2045 сек.

S= 0,999998

Наибольший вес в вероятность сбоя вносили классы: К7, К10, К14, в результате уменьшения вероятности сбоя в соответствующих входных диапазонах удалось найти «узкие места» в системе. Получаем новые показатели:

TR = 0,000015 сек.

MTTF = 2045,1 сек.

S= 0,999999

4.7 Анализ результатов

В результате анализа практических результатов, полученных в ходе реализации реальных проектов можно сделать следующие выводы:

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

- На фазе полного тестирования системы можно найти «узкие места» в системе - те компоненты, которые вносят наибольший вес в вероятности сбоя.

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

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

Заключение

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

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

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

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

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

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

- Предложен метод реализации системы модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств путем интеграции в ERP-систему Microsoft Business Solutions - Axapta.

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

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

Список использованных источников

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

1. Авиженис, А.Н. Гарантоспособные вычисления: от идей до реализации в проектах / А.Н. Авиженис, Ж.-К. Лапри. - ТИИЭР, 1986. - Т. 74. - №5. - С. 8-21

2. Алимханов, А.М. Приложения клиент-сервер КСУП «Галактика» и модель их архитектурной надежности / А.М. Алимханов, И.В. Ковалев, Р.В. Юнусов; Вестник НИИ СУВПТ: Сб. научн. трудов/ Под общей ред. профессора Н.В. Василенко; Красноярск: НИИ СУВПТ. - 2003. Выпуск 11. - С. 97-102

3. Алимханов, А.М. Использование программной системы поддержки для повышения доступности ресурсов корпоративной СУБД / А.М. Алимханов, С.В. Савин, Р.В. Юнусов; Вестник НИИ СУВПТ: Сб. научн. трудов/ Под общей ред. профессора Н.В. Василенко; Красноярск: НИИ СУВПТ. - 2003. Выпуск 11. - С. 107-112

4. Алимханов, А.М. Мультиверсионное формирование программно-информационных технологий корпоративных интегрированных структур/ А.М. Алимханов, И.В. Ковалев, Р.В. Юнусов; Материалы V-й Всероссийской конференции с международным участием молодых ученых и аспирантов «Новые информационные технологии. Разработка и аспекты применения», 28 ноября 2002 г. Таганрог: ТРТУ. 2002. С. 162-164

5. Ашимов, А.А. Оптимальные модульные системы обработки данных / А.А. Ашимов, А.Г. Мамиконов, В.В. Кульба. - Алма-Ата: Наука. 1981. - 186 с

6. Богатырев, В.А. К повышению надежности вычисли тельных систем на основе динамического распределения функций / Изв. вузов. Приборостроение. 1981

7. Богатырев, В.А. Отказоустойчивые многомашинные вычислительные системы динамического распределения запросов при дублировании функциональных ресурсов / Изв. вузов. Приборостроение. 1996. - №4

8. Боэм, Б. Характеристики качества программного обеспечения / Б. Боэм, Дж. Браун, Х. Каспар, М. Липов, Г. Мак-Леод, М. Мерит. - М.: Мир, 1981. - 208 с

9. Боэм, Б.У. Инженерное проектирование программного обеспечения / Пер. с англ. - М.: Радио и связь, 1985. -512 с

10. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами на С++. М.: БИНОМ, 1998. - 560 с

11. Воеводин, В.В. Математические модели и методы в параллельных процессах / М.: Наука, 1986. - 328 с

12. Волик, Б.Г. Методы анализа и синтеза структур управляющих систем / Под ред. Б.Г. Волика. - М.: Энергоатомиздат, 1988. - 296 с

13. Гантер, Р. Методы управления проектированием программного обеспечения / Под ред. Е.К. Масловского. - М.: Мир, 1981. - 392 с

14. Головкин, Б.А. Расчет характеристик и планирование параллельных вычислительных процессов / М.: Радио и связь, 1983. - 272 с

15. Гудман, С. Введение в разработку и анализ алгоритмов / С. Гудман, С. Хидетниеми. - Пер. с англ. - М.: Мир, 1981. - 366 с

16. Давыдов, И.Н. Экспресс-анализ технологии и программного комплекса автоматизированной системы технической диагностики / И.Н. Давыдов, Р.В. Юнусов; Вестник НИИСУВПТ, посвященный 100-летию Красноярской железной дороги; Красноярск: НИИСУВПТ. - 1999.-Вып.1. С. 312-321

17. Давыденко, О.В. Оценка надежности программного обеспечения бортового комплекса управления / О.В. Давыденко, И.В. Ковалев. - Вестник КГТУ: Сб.научн. трудов; под ред. Б.П. Соустина. - Вып.5. - Красноярск, 1996. - С. 119-121

18. Дилон, Б. Инженерные методы обеспечения надежности систем / Б. Дилон, И. Сингх. - М.: Мир, 1984. - 318 с

19. Ковалев, И.В. Автоматизация создания программных средств систем управления / В кн.: Микроэлектронные устройства: проектирование и технология. - Красноярск. КПИ, 1990. - С. 79-85

20. Ковалев, И.В. Математический метод многоатрибутивного принятия решения при формировании мультиверсионного программного обеспечения / И.В. Ковалев, Р.Ю. Царев; Тез. докл. межрегиональной конференции «Математические модели природы и общества» - Красноярск: ТЭИ, 2002. - С. 52-58

21. Ковалев, И.В. Многоатрибутивный метод принятия решений с учетом относительной близости к лучшей альтернативе / И.В. Ковалев, Р.Ю. Царев; Тез. докл. межрегиональной конференции «Математические модели природы и общества» - Красноярск: ТЭИ, 2002. - С. 63-66

22. Ковалев И.В. Многоатрибутивная модель формирования гарантоспособного набора проектов мультиверсионных программных систем / И.В. Ковалев, Р.Ю. Царев; Вестник НИИ СУВПТ. - Вып.7. - Красноярск: НИИ СУВПТ, 2001. - С. 129-137

23. Ковалев, И.В. Оптимальное проектирование мультиверсионных систем управления / И.В. Ковалев, А.А. Попов, А.С. Привалов. - Доклады НТК с международным участием «Информационные технологии в инновационных проектах». - Ижевск: ИжГТУ, 2000. - С. 24-29

24. Ковалев, И.В. Параллельные процессы в информационно-управляющих системах. Формирование и оптимизация: Монография/ И.В. Ковалев, Р.Ю. Царев, Ю.Г. Шиповалов. - Под ред. д.т.н., проф. А.В. Медведева. - Красноярск: НИИ СУВПТ, 2001. - 143 с

25. Ковалев, И.В. Система мультиверсионного формирования программного обеспечения управления космическими аппаратами: Диссертация на соискание ученой степени доктора технических наук / Красноярск: КГТУ, 1997. - 228 с.

26. Ковалев, И.В. Мультиверсионный метод повышения качества программно-информационных технологий для корпоративных структур / И.В. Ковалев, А.М. Алимханов, Р.В. Юнусов; Россия в III тысячелетии: прогнозы культурного развития. Качество жизни. Наука. Культура. Образование. Искусство. Власть. Производство: Сборник научных трудов по материалам Всероссийской научной конференции / Изд-во АМБ, Екатеринбург, 2002. С. 171-173

27. Ковалев, И.В. Надежность архитектуры программного обеспечения телекоммуникационных технологий / И.В. Ковалев, Н.В. Василенко, Р.В. Юнусов; Международная научная конференция Telematica'2001, Санкт-Петербург, 2001 - С. 23-24

28. Ковалев, И.В. Мультиверсионный метод обеспечения отказоустойчивости программных архитектур систем управления критичными по надежности техническими объектами / И.В. Ковалев Р.В., Юнусов; Научная конференция «Научно-инновационное сотрудничество». Москва, 2002

29. Ковалев, И.В. Оценка надежности аппаратно-программного информационно-управляющего комплекса. САКС-2002 / И.В. Ковалев, Р.В Юнусов;: Тезис. докладов международной научно-практической конференции (6-7 дек. 2002, г. Красноярск)/ СибГАУ. Красноярск, 2002. С. 352-353

30. Ковалев, И.В. Мультиверсионный метод повышения программной надежности информационно-телекоммуникационных технологий в корпоративных структурах / И.В. Ковалев, Р.В. Юнусов; Телекоммуникации и информатизация образования. 2003. №2, С. 50-55

31. Колчанов, С.Ю. Использование генетических алгоритмов в задачах формирования мультиверсионных программных систем. / Вестник НИИ СУВПТ: Сб. научн. трудов/ Под общей ред. профессора Н.В. Василенко; Красноярск: НИИ СУВПТ. - 2003. Выпуск 11. - С. 166-179

32. Лебедев, В.А. Параллельные процессы обработки информации в управляющих системах: Монография / В.А. Лебедев, Н.Н. Трохов, Р.Ю. Царев. - Красноярск: НИИ СУВПТ, 2001. - 137 с

33. Липаев, В.В. Качество программного обеспечения / М.: Финансы и статистика, 1983. - 264 с

34. Липаев, В.В. Технология проектирования комплексов программ АСУ / В.В. Липаев, Л.А. Серебровский. - М.: Радио и связь, 1983. - 264 с

35. Липаев, В.В. Тестирование программ / М.: Радио и связь, 1986. - 234 с

36. Липаев, В.В. Надежность программных средств/ СИНТЕГ. - М., 1998. -232 с

37. Майерс, Г. Надежность программного обеспечения: Пер. с англ./ Под ред. В.Ш. Кауфмана. - М.: Мир, 1980. - 360 с

38. Мамиконов, А.Г. Типизация разработки модульных систем обработки данных / А.Г. Мамиконов, В.В. Кульба, С.А. Косяченко. - М.: Наука, 1989. - 165 с

39. Мамиконов, А.Г. Синтез оптимальных модульных систем обработки данных / А.Г. Мамиконов, В.В. Кульба. - М.: Наука, 1986

40. Михалевич, В.С. Вычислительные методы исследования и проектирования сложных систем / В.С. Михалевич, В.Л. Волкович. - Наука, 1982. - 286 с

41. Поздняков, Д.А. Разработка и исследование среды мультиверсионного исполнения программных модулей. / Д.А. Поздняков, И.С. Титовский, Р.В. Юнусов; Вестник НИИ СУВПТ: Сб. научн. трудов; Красноярск: НИИ СУВПТ. - 2003. Выпуск 13. - С. 155-170

42. Попов, А.А. Бинарная модель отказоустойчивой системы программного обеспечения: Доклады НТК с международным участием «Информационные технологии в инновационных проектах» / А.А. Попов, А.С. Привалов. - Ижевск: ИжГТУ, 2000. - С. 77-83

43. Раинкшкс, К. Оценка надежности систем с использованием графов / К. Раинкшкс, И.А. Ушаков. - М.: Радио и связь, 1988

44. Саркисян, А.А. Повышение качества программ на основе автоматизированных методов / М.: Радио и связь, 1991. - 160 с.

45. Системный анализ: Проектирование, оптимизация и приложения / В 2 т., под общ. Ред. Антамошкина А.Н. - Красноярск: САА, 1996. - 206 с

46. Фокс, Дж. Программное обеспечение и его разработка
/ Пер. с англ. - Под ред. Д.Б. Подшивалова. - М.: Мир, 1985. - 268 с

47. Хорошевский, В.Г. Инженерный анализ функционирования вычислительных машин и систем / М.: Радио и связь, 1987. - 256 с.

48. Царев, Р.Ю. Метод простого суммарного назначения весов при решении задачи многоатрибутивного выбора состава мультиверсионной программной системы / Решетневские чтения. Тез. докл. V Всерос. Научн.-практ. конф. студентов, аспирантов молодых специалистов 12-15 ноября 2001 г. - Красноярск: САА, 2001. - С. 86-87

49. Царев, Р.Ю. Многокритериальное принятие решений при создании отказоустойчивого программного обеспечения / Вестник НИИ СУВПТ. - Вып.2. - Красноярск: НИИ СУВПТ, 1999. - С. 190-194

50. Царев, Р.Ю. Многокритериальное принятие решений при мультиверсионном проектировании гарантоспособных программных средств / Научная сессия МИФИ - 2002 г. Научн.-тех. конференция «Научно-инновационное сотрудничество». Сборник научных трудов. В 3 частях. - М: МИФИ, 2002. - С. 153-154

51. Царев, Р.Ю. Многоцелевой выбор проекта информационной системы с эффективным распределением взаимосвязанных ресурсов / Решетневские чтения. Тез. докл. IV Всерос. Научн.-практ. конф. студентов, аспирантов молодых специалистов 10-12 ноября 2000 г. - Красноярск: САА, 2000. - С. 273

52. Царев, Р.Ю. Модель многокритериального решения при выборе проектов мультиверсионной программной системы / Р.Ю. Царев, Ю.Г. Шиповалов; Перспективные материалы, технологии, конструкции, экономика. Материалы Всероссийской научно-технической конференции 24-26 мая 2001 г. - Вып.7. - Красноярск: ГАЦМиЗ, 2001. - С. 642-644

53. Царев, Р.Ю. Преобразование атрибутов при многоатрибутивном принятии решения / Решетневские чтения. Тез. докл. V Всерос. Научн.-практ. конф. студентов, аспирантов молодых специалистов 12-15 ноября 2001 г. - Красноярск: САА, 2001. - С. 119-120

54. Чжу, У.У. Копирование и размещение программных модулей в системе распределенной обработки в реальном времени / У.У. Чжу, Ц.К. Лян. - ТИИЭР, 1987. - Т. 75, №5. - С. 23-44

55. Юдин, Д.Б. Математические методы оптимизации устройств и алгоритмов АСУ / Д.Б. Юдин, А.П. Горяшко, А.С. Немировский. - М.: Радио и связь, 1982. - 288 с

56. Юнусов, Р.В. Анализ надежности аппаратно-программного информационно-управляющего комплекса / Вестник НИИ СУВПТ: Сб. научн. трудов/ Под общей ред. профессора Н.В. Василенко; Красноярск: НИИ СУВПТ.2003. Выпуск 11. С. 103-106

57. Юнусов, Р.В. Оценка надежности программного обеспечения клиент-сервер на примере комплексной системы управления предприятием «Галактика» / Вестник НИИСУВПТ; Красноярск: НИИСУВПТ. - 2001.-Вып.7. С. 107-112

58. Юнусов, Р.В. Оценка надежности и гарантоспособная модель архитектуры программного обеспечения / Вестник НИИСУВПТ; Красноярск: НИИСУВПТ.2001. Вып.8. С. 194-208

59. Юнусов, Р.В. Моделирование программных архитектур автоматизированных систем управления / Управляющие и вычислительные системы. Новые технологии: Материалы всероссийской электронной научно-технической конференции. Вологда: ВоГТУ, 2001. С. 60-61

60. Юнусов, Р.В. Модель формирования гарантоспособной архитектуры программного обеспечения / Решетневские чтения: Тезисы докладов 4 Всероссийской Научно-практической конференции студентов, аспирантов и молодых специалистов. Красноярск: САА, 2000. С. 172-174

61. Antamoshkin, A. System Analysis, Design and Optimization / A. Antamoshkin, H.P. Schwefel, and others. - Ofset Press, Krasnoyarsk, 1993. - 312 p

62. Ashrafi, N. Optimization Models for Selection of Programs, Considering Cost & Reliability / N. Ashrafi, O. Berman; IEEE Transaction on reliability. Vol. 41, No 2, June 1992, Р.281-287

63. Avizienis, A. The N-Version approach to fault-tolerant software / IEEE Trans. on Software Engineering. - Vol. SE11, №12, December, 1985. - P. 1491-1501

64. Berman, O. Choosing an Optimal Set of Libraries / O. Berman, M. Cutler.; IEEE Transaction on reliability. Vol. 45, No 2, June 1996, Р.303-307

65. Bhatnagar, S.K. Network analysis techniques / Wiley Eastern Limited, New Delhi, 1986. - 456 p

Страница:


Подобные документы

  • Качество, надежность и тестирование программных средств

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

    лекция [370,1 K], добавлен 22.03.2014

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

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

    курсовая работа [472,9 K], добавлен 11.11.2014

  • Схема характеристик качества программных средств

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

    контрольная работа [26,6 K], добавлен 23.01.2011

  • Методы оценки программной надежности

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

    курсовая работа [71,5 K], добавлен 15.12.2013

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

    Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.

    курсовая работа [811,5 K], добавлен 29.06.2014

  • Качество, надежность и тестирование программных средств

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

    презентация [151,1 K], добавлен 22.03.2014

  • Критерии качества программных средств

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

    реферат [26,7 K], добавлен 10.10.2014

  • Качество, надежность и тестирование программных средств

    Этапы тестирования при испытаниях надежности программных средств. Комплексирование модулей и отладка автономных групп программ в статике без взаимодействия с другими компонентами. Испытания главного конструктора. Жизненный цикл программного средства.

    презентация [339,6 K], добавлен 22.03.2014

  • Программное обеспечение

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

    реферат [20,2 K], добавлен 01.04.2010

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

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

    реферат [1,8 M], добавлен 05.12.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены