Общие характеристики системы

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

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

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

Как указывалось выше, система должна быть ориентирована на удовлетворение интересов пользователя. Недопустимо вводить какую-либо регламентацию поведения пользователя исходя из интересов или удобства разработчиков. Упрощая себе процесс разработки за счет предъявления излишних требований к пользователям, разработчики рискуют создать нежизнеспособную систему, к которой пользователи просто не будут обращаться. Сказанное в полной мере относится к нарушениям нормальной работы системы. Если они серьезно влияют на ритм работы пользователя, требуют от него существенной дополнительной работы, то есть большая вероятность отказа от такой системы.

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

Перейти на страницу: 1 2