Система модельно-алгоритмической поддержки многоэтапного анализа надежности программных средств
Анализ методов оценки надежности программных средств на всех этапах жизненного цикла, их классификация и типы, предъявляемые требования. Мультиверсионное программное обеспечение. Современные модели и алгоритмы анализа надежности программных средств.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 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