Обеспечение отказоустойчивости

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

Попытка реализовать отказоустойчивость ПП таким же обра­зом, т.е. параллельным выполнением одной и той же программы различными процессорами, приводит только к тому, что вторая копия точно такой же программы отстает на доли: секунды от пер­вой копии. Простое выполнение отдельной копии программы ни­как не отражается на отказоустойчивости- ПП.

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

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

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

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

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

Таблица 13.6

Шаблон для учета действий по обеспечению отказоустойчивости на этапах разработки, тестирования, эксплуатации и сопровождения

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

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