Что Определяет Надежность Работы Программного Обеспечения

За последние полвека информационные технологии сделали огромный скачок, уровень автоматизации информационных процессов постоянно повышается. Разработано и функционирует большое количество компьютерных информационных систем в различных областях человеческой деятельности [2]. Надежность нужно оценивать, измерять, предсказывать — обеспечивать заданные требования к надежности в проекте и проверять их выполнение в продукте [3]. •  устойчивость   (robustness)   или   отказоустойчивость   (fault-tolerance) — способность продолжать правильно работать после отказов. Показатели оцениваются как количественные, качественные и порядковые. Их получают путем непосредственных наблюдений и обработки результатов испытаний систем.

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

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

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

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

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

• В то время как безотказность аппаратуры определяется в основном случайными отказами, зависящими от изменений параметров аппаратуры во время эксплуатации.
• С ростом сложности задач возникает необходимость формализации функций по обеспечению надёжности.
• К международным организациям инженеров и учёных в области надёжности относятся IEEE Reliability Society, American Society for Quality (ASQ) и Society of Reliability Engineers (SRE).
• Надёжность объекта техники обеспечивается при его проектировании и впоследствии поддерживается на стадии эксплуатации.

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

Испытания На Надёжность[править Править Код]

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

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

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

По Теме: Методические Разработки, Презентации И Конспекты

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

Входные параметры модели надёжности системы могут быть получены из разных источников (справочников, отчётов об испытаниях и эксплуатации и т. п.). В любом случае, данные должны быть использованы с осторожностью, так как прогнозы верны только при получении данных при тех же условиях, при которых составные части будут применяться в составе системе. В целом, создание надежных систем, https://deveducation.com/ охватывающих каждую точку возможного отказа, затруднено из-за огромного количества возможных входов и их комбинаций[4]. Поскольку для тестирования всех входов и их комбинаций потребуется слишком много времени, разработчики не могут исчерпывающе исследовать все случаи. Некоторые выбранные входные данные могут состоять из отрицательного числа, нуля и положительного числа.

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

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

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

Надёжность С Точки Зрения Науки[править Править Код]

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

При этом используют структурные схемы надёжности или деревья отказов, при помощи которых представляется взаимоотношение между различными составными частями объекта (системы). Интуитивно надёжность объектов связывают с недопустимостью отказов в работе. Это есть понимание надёжности в «узком» смысле — свойство объекта сохранять работоспособное состояние в течение некоторого времени или некоторой наработки.

Основные Определения[править Править Код]

Слепое добавление кода приводит к большему количеству ошибок, усложняет систему и усложняет её понимание[6]. Код, который не обеспечивает подкрепления уже существующему коду, нежелателен. Вместо этого новый код должен обладать эквивалентной функциональностью, чтобы в случае нарушения функции код, предоставляющий ту же функцию, смог заменить её, используя ручное или автоматическое разнесение программного обеспечения. Для этого новый код должен знать, как и когда следует учитывать точку сбоя[4]. Но поскольку система добавляет больше логики, компонентов и увеличивается в размерах, она становится все более сложной. Таким образом, при создании более избыточной системы она также становится более сложной, и разработчики должны учитывать балансирование избыточности со сложностью.

Широкое разнообразие CPU и их семейства при возросшем темпе обновления номенклатуры выпускаемых изделий предполагает рассмотрение процесса разработки ПО как сложной, но все таки технологической операции. В статических моделях (Миллса, Нельсона Коркорэна) в отличии от динамических не берётся во внимание время возникновения ошибок [17]. Они могут быть менее строгими в начальный период эксплуатации, когда идёт испытание и совершенствование ПО, а также после создания новой версии.

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

См Также[править Править Код]

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

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

Безотказность программного средства можно также характеризовать средним временем между возникновениями отказов в функционировании программы. При этом предполагается, что аппаратура компьютера находится полностью в работоспособном состоянии. Безотказность ПО можно оценивать вероятностью его работы без отказов при определенных условиях внешней среды в течении заданного времени наблюдения. Качество ПО задается на этапе логического проектирования алгоритма функционирования ИС управления [13,15]. Типичный пример восстановления — с помощью резервной (backup) копии данных. Если выполнить восстановление в латентном периоде отказа, то он никогда не проявится вовне — в этом состоит идеальная отказоустойчивость.

Базовые Принципы[править Править Код]

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