лянути можливість їх накопичення в деякій проміжній ємності - буфері, де вони зберігаються в очікуванні обслуговування.
Коефіцієнт готовності системи визначається як ймовірність того, що вона виявиться працездатною в довільно обраний момент часу в сталому (стаціонарному) режимі експлуатації. Іншими словами, це частка або відсоток часу, протягом якого система фактично працездатна в стаціонарному режимі, щодо загального часу, коли вона повинна бути працездатна. Переважна більшість порушень працездатності в АСУ пов'язано зі збоями або виходом з ладу різних елементів технічних засобів; в меншій мірі, але помітно, позначаються недоліки в програмному забезпеченні.
Час відновлення обумовлює максимальну і середню тривалість неробочого стану системи і розподіл перерв у роботі за часом. Користувачеві не байдуже, чи відбувається в системі одна перерва на добу тривалістю 30 хв або один перерву на 2 хв щогодини, хоча загальний час непрацездатності в обох випадках однаково.
Яким би високим буде коефіцієнт готовності, розробник повинен вирішити ряд питань, пов'язаних з можливими перервами роботи, і в першу чергу визначити, що повинно відбуватися в цей час в системі. Крім звичайних заходів по введенню в дію резерву, якщо він економічно виправданий, слід так розробляти систему, щоб забезпечити можливість автономної роботи протягом деякого часу всіх елементів системи, крім, природно, що вийшли з ладу.
Відновлення нормального режиму не повинна вимагати від користувача будь-яких спеціальних заходів та операцій, він повинен просто продовжувати перервану роботу. Це означає, що розробник повинен передбачити можливість автоматичного запам'ятовування стану системи в момент, що безпосередньо передує аварійної ситуації, і повного відновлення цього стану після її ліквідації. Всі операції, виконані в автономному режимі, повинні бути згодом оброблені так, як якби вони виконувалися в нормальному режимі. Якщо провести повне відновлення системи в автоматичному режимі з яких-небудь причин неможливо, система повинна підказувати користувачу, які операції йому необхідно додатково виконати і з якого місця почати повторення операцій перерваної завдання. У кожному разі неприпустима втрата якоїсь частини введеної в систему інформації.
Як вказувалося вище, система повинна бути орієнтована на задоволення інтересів користувача. Неприпустимо вводити яку-небудь регламентацію поведінки користувача виходячи з інтересів або зручності розробників. Спрощуючи собі процес розробки за рахунок пред'явлення зайвих вимог до користувачів, розробники ризикують створити нежиттєздатну систему, до якої користувачі просто не звертатимуться. Сказане повною мірою відноситься до порушень нормальної роботи системи. Якщо вони серйозно впливають на ритм роботи користувача, вимагають від нього істотною додаткової роботи, тобто велика ймовірність відмови від такої системи.
Значну складність для розробника представляє аналіз можливих ко...
