5.3 Обеспечение надежности

Существует четыре основных подхода к обеспечению надежности:

• самообнаружение ошибок;

• самоисправление ошибок;

• обеспечение устойчивости к ошибкам;

• предупреждение ошибок.

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

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

• борьба со сложностью;

• обеспечение точности перевода;

• преодоление барьера между пользователем и разработчиком;

• обеспечения контроля принимаемых решений.

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

5.4 Модель разработки по (Программного Обеспечения).

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

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

• каскадная модель;

• спиральная модель;

• модель формальной разработки систем;

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

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

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

Каждый виток разбит на 4 сектора:

• оценка и разрешение рисков;

• определение целей;

• разработка и тестирование;

• планирование.

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