Безопасность информационной системы – свойство, заключающееся в способности системы обеспечить конфиденциальность и целостность информации, то есть защиту информации от несанкционированного доступа с целью её раскрытия, изменения или разрушения.
В руководящих документах Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования к защите информации» и «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации» рекомендовано для оценки защиты информации от несанкционированного доступа использовать показатели:
- вероятность попадания информации абоненту, которому она не предназначена;
- вероятность не прохождения сигнала тревоги.
При оптимизации систем защиты информации удобнее использовать вместо вероятностей и коэффициенты 
и 
, где 
- вероятность появления несанкционированного обращения (
и 
- условные вероятности событий при условии возникновения несанкционированного обращения).
3. 2. Основные понятия теории надёжности
Надёжность – важнейшая характеристика качества и эффективности любой системы, поэтому разработана специальная теория – теория надёжности.
Теория надёжности может быть определена, как научная дисциплина, изучающая закономерности, которых следует придерживаться при разработке и эксплуатации систем для обеспечения оптимального уровня их надёжности с минимальными затратами ресурсов.
Надёжность – характеристика временная, она может быть ориентирована либо в прошлое, либо в будущее время и не допускает «точечных» во времени оценок. Иными словами, надёжность – это свойство системы «штатно» функционировать во времени.
Надёжность – комплексное свойство системы; оно включает в себя более простые свойства, такие как безотказность, ремонтопригодность, долговечность и т.д.
Безотказность – свойство системы сохранять работоспособное состояние в течении некоторого времени или наработки (наработка – продолжительность или объём работы системы).
Ремонтопригодность – свойство системы, заключающееся в приспособленности к предупреждению и обнаружению причин возникновения отказов, повреждений и поддержанию и восстановлению работоспособного состояния путём проведения технического обслуживания и ремонта.
Долговечность – свойство системы сохранять при установленной системе технического обслуживания и ремонта работоспособное состояние до наступления предельного состояния, то есть такого момента, когда дальнейшее использование системы по назначению недопустимо или нецелесообразно.
Одним из основных понятий теории надёжности является отказ. Отказом называют полную или частичную потерю работоспособности системы или её элемента. Отказы бывают внезапные и постепенные, зависимые и независимые; полные и частичные, устойчивые или самоустраняющиеся, аппаратные, эргатические, программные и т.п.
Устойчивый отказ обусловливает длительную неработоспособность системы и устраняется только в результате её технического обслуживания, то есть выполнения специальных мер, принятых для восстановления работоспособности системы. Самоустраняющийся отказ (обычно его называют сбоем) – отказ, имеющий кратковременный характер и самоустраняющийся произвольно, без принятия специальных мер для его устранения. Ряд сбоев одного и того же характера, следующих друг за другом, называют перемежающимся отказом.
Аппаратный отказ обусловлен нарушением работоспособности технического элемента системы, соответственно, эргатический – эргатического и программный – программного элемента системы. В соответствии с последней классификацией отказов можно рассматривать и надёжность трёх видов:
§ Аппаратная;
§ Эргатическая;
§ Программная.
Все системы в теории надёжности классифицируются по ряду признаков. Важными классификационными группами являются:
§ Восстанавливаемые;
§ Невосстанавливаемые;
§ Обслуживаемые;
§ Необслуживаемые системы.
Восстанавливаемой называется такая система, работоспособность которой в случае возникновения отказа подлежит восстановлению. Невосстанавливаемая система – такая система, работоспособность которой в случае отказа восстановлению не подлежит.
Обслуживаемая система – система, для которой предусматривается проведение регулярного технического обслуживания. Необслуживаемая система – система, для которой не предусматривается проведение регулярного технического обслуживания.
Информационные и вычислительные системы первых поколений, за редким исключением, относятся к восстанавливаемым обслуживаемым системам. Многие современные вычислительные системы относятся к необслуживаемым восстанавливаемым системам (например, персональные компьютеры) и даже к необслуживаемым и невосстанавливаемым системам (отдельные узлы вычислительных систем, например микропроцессор).
Определение надёжности программного изделия
Применительно к сложным системам, надёжность определяется, как свойство системы выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования [8].
Приведённое определение надёжности приемлемо и для такой сложной системы, какой является программное обеспечение. Однако, в этом определении не отражается различие между типами возможных ошибок, степенью влияния конкретной ошибки на функционирование системы. Это означает, что надёжность ПО должна определяться как функция от степени влияния ошибок и частоты их проявления.
Следовательно, надёжность ПО – это вероятность того, что программа какой-то период времени будет работать без сбоев, с учётом степени их влияния на выходные результаты. Другими словами, надёжность ПО есть функция от ущерба, наносимого ошибкой пользователю. Надёжность не является свойством, присущим программе, а в большей мере относится к тому, как используется программа.
Надежность ПО в значительной степени отличается от надёжности оборудования. Действительно, ПО не подвержено износу, практически отсутствуют ошибки производства, так встречаются они редко и легко могут быть исправлены (например, ошибки перезаписи при копировании). Ненадёжность ПО целиком определяется ошибками разработки, т.е. в основе ненадёжности ПО лежат предопределённые ошибки. Программные ошибки в большей степени зависят от входной информации. Причина появления ошибки в какой-то конкретный момент времени заключается в том, что в этот момент была обработана уникальная последовательность входных данных, вызвавшая проявление ошибки.
В литературе [20] надёжность ПО рассматривается как пределы, в которых система порождает пригодные действия, когда последние требуются. Надёжность является статистической оценкой, связывающей систему с набором требований, в соответствии с которым она должна разрабатываться. Принято считать систему очень надёжной, если велика вероятность того, что при обращении к ней получена требуемая услуга. Система рассматривается как ненадёжная, если она допускает сбои в особых ситуациях, даже если ситуации составляют небольшой процент от общего времени использования системы
Основные количественные показатели надёжности
Показатель надёжности – это количественная характеристика одного или нескольких свойств, определяющих надёжность системы. В основе большинства показателей надёжности лежат наработки системы, то есть продолжительности или объёма работы, выполненной системой. Показатель надёжности, относящийся к одному из свойств надёжности, называется единичным. Комплексный показатель надёжности характеризует несколько свойств, определяющих надёжность системы.
Единичные показатели надёжности
К единичным показателям надёжности в соответствии с ГОСТ 27.002-80 относятся показатели безотказности, показатели ремонтопригодности и показатели долговечности.
Показатели безотказности
1. Вероятность безотказной работы P(t) – вероятность того, что в пределах заданной наработки отказ системы не возникает
, (3.4.)
где 
- плотность вероятностей.
Вероятность безотказной работы за некоторый промежуток времени может быть определена статистическим путём по результатам тестирования как отношение числа испытуемых объектов (операторов, программных модулей, информационных совокупностей), в которых была обнаружена ошибка (отказ) к общему числу объектов, поставленных на испытания:
, (3.5)
где n – начальное число испытываемых объектов, 
- число объектов, в которых обнаружена ошибка, за которой последовал отказ или сбой, за время 
.
2. Вероятность отказа Q(t) – обратная величина, вероятность того, что в пределах заданной наработки отказ системы возникает
(3.6)
3. Плотность распределения отказов – отношение числа объектов 
отказавших в интервале наработки 
к произведению общего числа объектов 
на длительность интервала наработки 
, (3.7)
Вероятностное определение плотности распределения отказов
. (3.8.)
Плотность распределения отказов по существу является плотностью распределения (плотностью вероятности) случайной величины 
- наработки объекта до отказа.
4. Средняя наработка до отказа T0 = M(t) – математическое ожидание наработки системы до первого отказа (существенно для невосстанавливаемых систем)
, (3.9)
где 
- количество объектов, работоспособных к моменту наработки , n – начальное число испытываемых объектов, 
- общее число объектов, отказавших к началу рассматриваемого промежутка времени .
При вероятностном определении средняя наработка на отказ определяется
. (3.10)
5. Средняя наработка на отказ 
– отношение наработки восстанавливаемой системы к математическому ожиданию числа её отказов в пределах этой наработки (имеет смысл только для восстанавливаемых систем).
6. Интенсивность отказов (
) – отношение среднего числа отказов для восстанавливаемой системы за произвольно малую её наработку к значению этой наработки
. (3.11)
показывает, какая доля исправных в данный момент объектов отказывает в единицу времени (для малых промежутков времени). Эта характеристика надёжности может быть получена из опытных данных по формуле:
, (3.12)
где n – начальное число испытываемых объектов, - число объектов, в которых обнаружена ошибка, за которой последовал отказ или сбой, за время , - общее число объектов, отказавших к началу рассматриваемого промежутка времени .
Функцию зависимости интенсивностей отказов от времени часто называют лямбда-характеристикой [6, 28].
Показатели ремонтопригодности
Ремонтопригодность – свойство объекта непрерывно сохранять работоспособность в течение некоторой наработки или в течение некоторого времени
Показателями ремонтопригодности считаются:
1. Вероятность восстановления работоспособного состояния (
) – вероятность того, что время восстановления работоспособного состояния не превысит заданного.
(3.13)
2. Среднее время восстановления работоспособного состояния (
) – математическое ожидание времени восстановления работоспособного состояния системы.
(3.14)
Показатели долговечности
Долговечность – это свойство это свойство объектов сохранять работоспособное состояние до наступления предельного состояния при установленной системе технического обслуживания и ремонта.
Предельное состояние объекта характеризуется таким состоянием, при котором дальнейшее его применение по назначению недопустимо или нецелесообразно, либо восстановление исправного или работоспособного состояния невозможно или нецелесообразно.
Объект может перейти в предельное состояние, оставаясь работоспособным, если его дальнейшее применение по назначению станет недопустимым по требованиям безопасности, экономичности или эффективности. Специфика такого объекта как программный такова, что при соблюдении заданных технических условий он может сохранять работоспособное состояние достаточно долго. Поэтому критерием предельного состояния программного объекта может служить именно несоответствие требованиям эффективности.
В общем случае долговечность объектов измеряется техническим ресурсом, под которым понимается наработка объекта от начала его эксплуатации или возобновления после ремонта определённого вида до перехода в предельное состояние.
Основными количественными показателями долговечности являются [25]:
1. Средний ресурс (
) – математическое ожидание наработки системы от начала её эксплуатации или её возобновления после ремонта до перехода в предельное состояние.
(3.15)
2. Срок службы (
) – календарная продолжительность от начала эксплуатации системы или её возобновления после ремонта до перехода в предельное состояние.
3.3. Примеры оценки основных показателей качества
Одним из подходов к оценке показателей качества является подход на основании результатов проведённого тестирования разработанного программного продукта.
Оценка функциональных возможностей
Как уже было сказано выше одним из количественных показателей функциональных возможностей программного продукта, характеризующим истинность информации, является показатель достоверности информации.
Рассмотрим один из подходов к оценке данного показателя на следующем примере:
Пример 1:
Во время проведения пробных тестовых испытаний программного объекта, в модуле, содержащем 100 операторов, была обнаружена ошибка.
Рассчитать математическое ожидание количества ошибок и достоверность информации, обрабатываемой всей программой, содержащей 400 операторов.
Решение:
Вероятностная оценка искомых величин
Вероятность появления ошибки в информационной совокупности из 100 операторов:
,
тогда вероятность безошибочной работы, а следовательно и достоверность информации:
Математическое ожидание количества ошибок в информационной совокупности из 400 операторов:
.
Вероятность появления 4 ошибок в программе, содержащей 400 операторов (
) и достоверность обрабатываемой информации определим с помощью распределения Пуассона: 
;
Оценка надёжности программного изделия
К единичным показателям надёжности в соответствии с ГОСТ 27.002-80 относятся показатели безотказности, показатели ремонтопригодности и показатели долговечности.
Рассмотрим количественную оценку данных показателей на следующем примере
Пример 2.
В результате тестовых испытаний программного изделия, состоящего из 10 модулей было получено следующие данные для параметров n, 
di, di ( п.3.2):
| Время (t) | t0 | t1=5c | t2=10с | t3=15c | t4=20c |
| параметры | |||||
| n | |||||
| di
| - | ||||
| di | - | ||||
| 0.02 | 0.022 | 0.025 | 0.03 | |
| Pоп | 0.9 | 0.8 | 0.7 | 0.5 | |
| 0.02 | 0.02 | 0.02 | 0.04 |
Параметры , Pоп, определяются по формулам (3.12), (3.5), (3.7) соответственно.
Используя полученные данные можно построить графики функции плотности распределения отказов , и лямбда-характеристики исследуемого процесса.
Вероятностная оценка показателей надёжности в данном случае может быть, например, следующей.
Сформулируем задачу следующим образом:
а) какова вероятность возникновения хотя бы одного отказа в течении 1 часа испытаний;
б) какова вероятность возникновения двух отказов за 1 час;
в) какова вероятность, что возникнет более 5 отказов в течение 1 часа испытаний
Решение:
По условию задачи - среднее количество ошибок возникающих в единицу времени (параметр интенсивности отказов) 
, время испытаний 
.
а) оценим вероятность не возникновения отказа в течение требуемого интервала времени (воспользуемся формулой распределения Пуассона (2.25):
,
Тогда вероятность возникновения хотя бы одного отказа в рассматриваемом промежутке времени:
б) 
в) События «возникло менее пяти отказов» и «возникло более пяти вызовов» противоположны, поэтому искомая вероятность того, что за 60 минут произойдёт более 5 сбоев
следовательно, вероятность того, что в заданном промежутке времени произойдёт более 5 сбоев очень велика
Оценка эффективности программного изделия
В рамках оценки эффективности программного изделия рассмотрим пример расчёта коэффициента использования оперативной памяти
Коэффициент использования оперативной памяти ПИ, определяется по формуле (3.2) или (3.3) в зависимости от начальных условий по итогам предварительного тестирования исследуемой и эталонной программ.
1. Для определения коэффициента использования оперативной памяти по формуле (3.2) рекомендуется оставить таблицу следующего вида:
Таблица 3. 1
| Реализация | Номер этапа | Длительность этапа, (с) | Используемый объём памяти, (Кбайт) |
| 1. 2. 3. … | … |
Т (общее время работы) =
M (общее число этапов)=
К (общий объём оперативной памяти)=
2. Коэффициенты согласования эталонных программ для расчёта коэффициента оперативной памяти по формуле (3.3) могут быть определены статистически при функционировании программ, реализующих подобные задачи. Для проведения статистической оценки рекомендуется использовать, например, следующую таблицу:
Таблица 3. 2
| Параметры сравнения | Исследуемая программа | Эталонная программа |
| Характеристики ЭВМ: 1. Тип ОС 2. Объём ОП 3. Частота МП 4. … | + + – | + + – |
| Параметры программы: 1. 2. 3. | ||
| ||
|
+ - совпадение параметров
– - несовпадение параметров.
Оценка сопровождаемости
Как уже говорилось выше исходным материалом для оценки сопровождаемости программного изделия служит программная документация, поэтому её качество является критическим фактором сопровождаемости.
В настоящее время производство ПИ регулируется Единой системой программной документации (ЕСПД), которая представляет собой комплекс взаимосвязанных государственных стандартов, устанавливающих общие положения, виды программ и программных документов, правила разработки, оформления, обращения программ и программной документации, и распространяется на документацию всех типов программ независимо от назначения, области их использования и разработчика.
Качество программной документации можно оценить, проверив её на соответствие с ГОСТ 19 «Единая система программной документации». В котором предлагается следующий набор документов:
1. Спецификация (ГОСТ 19.202-78)
2. Ведомость держателей подлинников.
3. Текст программы. (ГОСТ 19.401 – 78).
4. Описание программы (ГОСТ 19.402-78).
5. Порядок и методика испытаний (ГОСТ 19.301-79).
6. Техническое задание (ГОСТ 19.201-78, а также более новый ГОСТ 34.602-89).
7. Пояснительная записка (ГОСТ 19.404-79).
8. Эксплуатационные документы.
4. ТЕСТИРОВАПНИЕ ПРОГРАММНЫХ ПРООДУКТОВ
Понятие тестирования
Тестирование является одним из этапов жизненного цикла ПИ, направленным на повышение качественных характеристик. При создании типичного ПИ около 40% общего времени и более 40% общей стоимости расходуется на проверку (тестирование) разрабатываемой программы.
Программы как объекты тестирования имеют ряд особенностей, которые отличают процесс их тестирования от общепринятого, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПИ являются:
§ Отсутствие эталона (программы), которому должна соответствовать тестируемая программа;
§ Высокая сложность программ и принципиальная невозможность исчерпывающего тестирования
§ Практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого разнообразия ПИ по их сложности, функциональному назначению, области использования и т.д.
Применительно к ПИ тестирование – это процесс многократного выполнения программы с целью обнаружения ошибок [17].
Роль тестирования в процессе разработки программ
До начала 80-х годов процесс тестирования ПО был разделен с процессом разработки: вначале программисты реализовывали заданную функциональность, а затем тестировщики приступали к проверке качества созданных программ. Однако такой подход создает множество проблем. Например, разработка программ может оказаться достаточно длительной (скажем, несколько месяцев) - чем в это время должны заниматься тестировщики?
Другая, более серьезная проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевой вопрос таков: сколько времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного времени на исправление, а исправление известных ошибок будет неизбежно связано с внесением новых. Steve McConnell приводит в своей книге [29] следующую мрачную статистику: даже однострочное изменение в программе с вероятностью 55% либо не исправляет старую ошибку, либо вносит новую. Если же учитывать изменения любого объема, то в среднем менее 20% изменений корректны с первого раза!
В связи с этим в 90-х годах появилась другая методика разработки, которую мы вслед за Microsoft'ом будем называть zero-defect mindset. Основная идея этой методики заключается в том, что качество программ проверяется не post factum, а постоянно в процессе разработки [27, 28]. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее.
При такой постановке вопроса тестирование становится центральной частью любого процесса разработки программ. С другой стороны, zero-defect mindset предъявляет существенно более высокие требования к квалификации инженера тестирования: теперь в сферу его ответственности попадает не только функциональное тестирование, но и организация процесса разработки (процесс ежедневной сборки, участие в инспекциях, сквозных просмотрах и обычное чтение исходных текстов тестируемых программ). Поэтому идеальной кандидатурой на позицию тестировщика становится наиболее опытный программист.
4.1. Различные подходы к тестированию (черный ящик, белый ящик)
Долгое время основным способом тестирования было тестирование методом "черного ящика" - программе подавались некоторые данные на вход и проверялись результаты, в надежде найти несоответствия [3]. При этом как именно работает программа считается несущественным. Отметим, что даже при таком подходе необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать результаты.
Этот подход до сих пор является самым распространенным в повседневной практике, но у него есть целый ряд недостатков. Во-первых, таким способом невозможно найти взаимоуничтожающихся ошибок, во-вторых, некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и потому их трудно найти и воспроизвести и т.д.
В связи с этим появились методы тестирования, которые изучают не только внешнее поведение программы, но и ее внутреннее устройство (исходные тексты). Такие методики обобщенно называют тестированием "белого ящика". Назовем некоторых представителей этого класса методик: чтение программ, формальные просмотры программ, инспекции и т.п.). Основной трудностью подобных методов является сложность отслеживания вычислений времени выполнения.
Внимательное изучение этих методов тестирования показывает, что они дополняют друг друга, то есть различные методы находят разные ошибки. Поэтому наиболее эффективные процессы разработки ПО используют некоторую комбинацию методик "черного ящика" и "белого ящика".
В следующей таблице, заимствованной из книги [8], приводятся показатели минимальной, средней и максимальной эффективности различных методов тестирования. Обратите особое внимание на последнюю строчку, описывающую общую эффективность процесса, использующего все эти методики:
Таблица 4.1
| Название методики | Минимальная эффективность | Средняя эффективность | Максимальная эффективность |
| Персональные просмотры проектных документов | 15% | 35% | 70% |
| Неформальные групповые просмотры | 30% | 40% | 60% |
| Формальные просмотры проектных документов | 35% | 55% | 75% |
| Формальные инспекции кода | 30% | 60% | 70% |
| Моделирование и прототипирование | 35% | 65% | 80% |
| Проверка за партой | 20% | 40% | 60% |
| Тестирование модулей | 10% | 25% | 50% |
| Функциональное тестирование | 20% | 35% | 55% |
| Комплексное тестирование | 25% | 45% | 60% |
| Тестирование в реальных условиях | 35% | 50% | 65% |
| Применение всех перечисленных методик тестирования | 93% | 99% | 99% |
Итак, очевидно, что тестирование максимально эффективно в тех случаях, когда программа проверяется не только путем запуска, но и путем чтения, статических проверок и т.п. Поэтому классическое определение Майерса, приведенное выше, оказывается слишком узким и не охватывающим всех аспектов современного тестирования. В связи с этим мы будем пользоваться другим определением тестирования:
Определение.
Тестирование - это любая деятельность, направленная на обнаружение ошибок в программном продукте.
4.2. Смежные вопросы тестирования
Экономическая сторона тестирования. Тестирование само по себе является затратной деятельностью, отнимающей у нас время и деньги. Поэтому в большинстве случаев разработчики программного обеспечения (ПО) заранее формулируют какой-либо критерий качества создаваемых программ (определяют так называемую планку качества), добиваются выполнения этого критерия и после этого прекращают тестирование и выпускают продукт на рынок. Такая концепция получила название Good Enough Quality (достаточно хорошое ПО), в противовес более очевидной концепции Best Possible Quality (максимально качественное ПО).
К сожалению, принцип Good Enough Quality зачастую понимают неправильно, ближе к формулировке Quality - If Time Permits (качество - если будет время). Конечно, выпуск плохо протестированного продукта из-за недостатка времени - это плохая практика. Практика показывает, что пользователи склонны со временем забывать даже значительные задержки с выпуском продукта, но плохое качество выпущенного продукта запоминается на всю жизнь.
На самом деле, Good Enough Quality - это просто поиск разумного компромисса между затратами на тестирование, длительностью разработки продукта и его качеством.
Психологические аспекты тестирования. Тестирование принципиально отличается от программирования по своим психологическим характеристикам [26]. Дело в том, что программирование носит конструктивистский характер, а тестирование ПО - деструктивно по своей природе. Можно сказать, что программист строит что-то, создает из ничего нечто, а тестировщик отыскивает недостатки этих построений. Поэтому программисты так часто не замечают очевидных ошибок в своих программах: к своему творчеству трудно относиться критично - как к своим детям.
Все это не значит, что тестирование "хуже", чем программирование, или что в процессе тестирования нет места творчеству - просто эти виды деятельности отличаются коренным образом, и для тестирования требуется иной склад характера, чем для программирования. Следовательно, программист не должен тестировать свои собственные программы; для этого необходим другой человек. Более того, программист не должен тестировать даже чужие программы! Дело в том, что программист потратит какое-то время просто на "раскачку", перенастраиваясь на новую задачу. Даже переключение с одной программистской задачи на другую требует обычно от 10 минут до получаса. Понятно, что переключение с одного образа мышления на другой отнимет существенно больше времени - возможно даже день или два.
Именно поэтому с точки зрения разработчика e-mail значительно выгоднее телефона (есть возможность ответить на вопросы после достижения некоторой логической точки в работе). Более того, программистам рекомендуют проверять почту не постоянно, а два-три раза в день - чтобы увеличить среднее время работы без отвлечений.
Из всего вышесказанного следует очевидный вывод о том, что команда разработчиков не должна совпадать с командой инженеров тестирования, но при этом разработчики и тестировщики должны постоянно взаимодействовать друг с другом для достижения приемлемого качества окончательного продукта.
заключение
Конец 20-го и начало 21-го века характеризуются началом перехода от постиндустриального общества к информационному. Процесс, обеспечивающий переход от индустриального общества к информационному – это процесс создания, развития и всеобщего применения информационных средств и технологий, обеспечивающих достижение и поддержание уровня информированности всех членов общества, необходимого и достаточного для кардинального улучшения качества труда и условий жизни в обществе. При этом информация становится важнейшим стратегическим ресурсом общества и занимает ключевое место в экономике, образовании и культуре. Неизбежность информатизации общества обусловлена резким восстановлением роли и значения информации. Информационное общество характеризуется высокоразвитой информационной сферой, которая включает деятельность человека по созданию, переработке, хранению, передаче и накоплению информации.
Для решения задач обеспечения качества, надёжности, безопасности и экономической эффективности ИС информация о работоспособности оборудования и оперативного персонала имеет первостепенное значение.
Одной из современных тенденций обеспечения высокого уровня надёжности, безопасности и эффективности ИС является их анализ по двум направлениям: первое – «информация – информационная технология – информационный ресурс» и второе – «модель – алгоритм – программа».
Современные информационные системы отличатся большой разветвлённостью подсистем, разнотипностью выполняемых задач, сложностью алгоритмов управления.
Прогнозирование работоспособности, эффективности и надёжности ИС представляет собой комплексную задачу, решение которой позволяет снизить до минимума вероятность возникновения отказов в процессе эксплуатации. И наиболее важным, по мнению авторов, является установление количественных закономерностей разрабатываемого процесса на этапе проектирования
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Автоматизированная система управления предприятием. Система нормативов на ресурсы. ГОСТ 4.071.033-80, 1980.
2. Баронов В. В. и др. Информационные технологии и управление предприятием. – М.: Компания АйТи, 2004. – 328 с.
3. Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. – СПб.: Питер, 2004 г. 318 с.
4. Беклешов В. К. Технико-экономическое обоснование дипломных проектов. – М.: Высшая школа, 1991. – 176 с.
5. Благодатских В.А. и др. Экономика, разработка и использование программного обеспечения ЭВМ. – М.: Финансы и статистика, 1995. – 288 с.
6. Готра З. Ю., Николаев И.М. Контроль качества и надёжность микросхем: Учебник для техникумов. М.: Радио и связь, 1989. 168 с.
7. Деверадж С., Кохли Р. Окупаемость ИТ: Измерение отдачи от инвестиций в информационные технологии. – М.: ЗАО «Новый издател