Типовые требования к управлению электронными официальными документами (стр. 33 )

Среднее время отклика системы на запросы пользователей э(68) на практике будет также зависеть от внешних по отношению к СУЭОД э(32) факторов, включая:

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

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

Соответственно, для правильной интерпретации этих требований следует ввести стандартизованное понимание «времени отклика». Это понимание будет варьироваться от среды к среде в зависимости от особенностей инфраструктуры.

Например, если СУЭОД э(32) специфицируется для существующей инфраструктуры, может быть разумным специфицировать время отклика в терминах интервала времени между получением сервером командной строки и посылкой отклика; и наоборот, если СУЭОД э(32) специфицирована для новой системы, уместно будет определить время отклика в терминах интервала времени между посылкой командной строки и отображением результата на рабочей станции.

Специфические требования для работы в автономном режиме и на расстоянии описаны в  разделе 10.11, и данные примерные требования будет необходимо еще более модифицировать  для таких условий.

СУЭОД э(32) обязательно должна быть способна выполнять все функции и действовать последовательно,  чтобы отвечать потребностям бизнеса и пользователей, как определено в примерных требованиях ниже.

№	Примерное Требование	Тест
СУЭОД э(32), отвечая потребностям бизнеса, обязательно должна обеспечивать адекватное время отклика для обычно выполняемых функций в стандартных условиях, например: <100%> от общего ожидаемого числа пользователей э(68) зарегистрированы в системе и активны; <100%> от ожидаемого общего объема документов э(26), находятся под управлением системы; пользователи э(68) выполняют различные типы транзакций с различной интенсивностью; при постоянстве производительности на протяжении по крайней мере десяти попыток выполнения транзакции.	Н
СУЭОД э(32) обязательно должна быть способна вернуть результат (список совпадений) на простой поисковый запрос в течение <3 секунд> и на сложный поисковый запрос (комбинацию из четырех терминов) в течение <10 секунд> вне зависимости от объема хранения или числа дел э(34) и официальных документов э(52) в системе.	Н
В данном контексте выполнение запроса подразумевает получение списка совпадений (смотри э8.1.10). Оно не включает собственно извлечение официальных документов э(52).
СУЭОД э(32) обязательно должна быть способна извлекать и отображать в течение <4 секунд> первую страницу официального документа э(52),  к которому происходило обращение в течение предыдущих <xx> месяцев, вне зависимости от отъема хранения или числа дел э(34) и официальных документов э(52) в системе.	Н
Это и э11.2.4 требования применяются только к документам э(26), которые могут быть представлены э(50) в виде страниц. Если документы э(26) необычно велики, может быть необходимым увеличить допустимое  время отклика.
Включение «в течение предыдущих <xx> месяцев» подразумевает использование этапного или  иерархического материального механизма  хранилища. Смотри также следующее требование.
Данное требование имеет своей целью обеспечить быстрое извлечение часто используемых официальных документов э(52), полагая, что частота использования обычно коррелирует с недавним использованием. Интервал времени определяется организацией на основе оценки времени, после которого интенсивность обращения к официальным документам э(52) снижается.
СУЭОД э(32) обязательно должна быть способна извлекать и отображать в течение <20 секунд> первую страницу официального документа э(52), к которому не происходило обращение в течение предыдущих <xx> месяцев, вне зависимости от объема хранения или числа дел э(34) и официальных документов э(52) в системе.	Н
Данное требование предназначено для учета случаев когда используется иерархические система управления хранением, официальные документы э(52) используются нечасто и сохранены на медленных носителях информации (по сравнению со скоростными носителями для официальных документов э(52) оперативного хранения) или хранятся на подключаемых устройствах. Временная шкала должна быть определена организацией, основываясь на оценке сроков, по истечении которых заканчивается активное использование официальных документов э(52).
Для этого и предыдущего требования: если все электронные официальные документы э(31) хранятся с использованием единого материального механизма (а именно без этапного или иерархического хранения), тогда фраза «в течение предыдущих <xx> месяцев» к ним не относится и должна быть удалена.
	СУЭОД э(32) обязательно должна допускать единую реализацию системы, чтобы иметь хранилище электронных официальных документов э(31) не менее <xx Гигабайт / Терабайт / Петабайт> или <xx тысяч / миллионов / миллиардов> официальных документов э(52) и обслуживать не менее <xx сотен / тысяч> пользователей э(68) одновременно с уровнем производительности, описанным в этом разделе.	Н
Оценки требований хранилища и числа официальных документов э(52) и числа пользователей э(68) определяются организацией. Заметим, что в больших организациях могут накапливаться большие объемы официальных документов э(52) – в некоторых случаях до миллиардов официальных документов э(52).
	СУЭОД э(32) обязательно должна обеспечить уровни производительности, указанные в этом разделе, с объемами как минимум: <xx> классов э(11); <xx> дел э(34) в классе э(11); <xx> разделов э(66) в деле э(34); <xx> томов э(74) в разделе э(66); <xx> официальных документов э(52) в томе э(74).	Н
Эти параметры являются только показательными. Организациям следует определить, применимы ли другие подобные параметры в их обстоятельствах.
	Должно быть обязательно возможным расширение СУЭОД э(32) контролируемым путем для соответствия росту организации до как минимум <xx сотен/тысяч> пользователей э(68), непрерывно обеспечивая их надлежащим уровнем сервиса.	Н
Суть данного требования состоит в том, что расширение должно быть возможным только путем «регламентных» обновлений, которые не приводят к большим перерывам в работе.
СУЭОД э(32) обязательно должна поддерживать вышеуказанный уровень производительности, включая регламентные процедуры обслуживания: ролей э(62), пользователей э(68) и групп пользователей э(69); грифов ограничения доступа э(63); профилей э(51) доступа; схем классификации э(14); баз данных; порядков хранения, отбора и передачи э(61); режимов предотвращение перемещения или уничтожения перед лицом ожидаемых организационных изменений, не навязывая избыточных системных и административных накладных расходов (смотри также главу 9).	Н
В случаях, когда предъявляются жесткие требования по производительности, может быть необходимо определить количественные характеристики уровня организационных изменений.
СУЭОД э(32) обязательно должна быть масштабируемой и в обязательном порядке иметь возможность быть применимой и в крупных и в малых организациях  с различным числом структурных подразделений разного размера и в различных условиях территориального расположениях.	Н

Доступность Системы

Во многих организациях совместное использование СУЭОД э(32) и ЭХД э(28) увеличивает зависимость пользователей э(68) от информационной сети в целом до степени, когда они не смогут продолжать работу в случае недоступности СУЭОД э(32) и ЭХД э(28).

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

№	Примерное Требование	Тест
	СУЭОД э(32) обязательно должна быть доступна пользователям э(68): с <xx:00> до <xx:00>  <каждый день / по всем рабочим дням / xx дней в году>.	Н
	Время запланированного простоя СУЭОД э(32) ни в коем случае не должно превышать <xx> часов в каждом <трехмесячном периоде>.	Н
Определение «простоя» может зависеть от архитектуры и инфраструктуры. Например, в некоторых условиях аппаратный сбой серверного оборудования может рассматриваться как сбой СУЭОД э(32); в иных условиях такой сбой будет рассматриваться как ошибка иного рода, не относящаяся к СУЭОД э(32).
Подходящее к конкретному случаю определение должно быть согласовано; в качестве отправной точки предлагается следующее определение: «СУЭОД э(32) считается находящейся в состоянии простоя если более, чем <xx%> пользователей э(68) не могут нормально выполнять функции СУЭОД э(32) по причине сбоя одного из компонентов СУЭОД э(32) (кроме рабочих станций пользователей э(68))».
	Время незапланированного простоя СУЭОД э(32) ни в коем случае не должно превышать <xx> часов в каждом <трехмесячном периоде>.	Н
При приобретении может быть уместным запросить количественные показатели значимого времени для решения вопросов обслуживания проблем данного требования.
	Число случаев незапланированного простоя СУЭОД э(32) ни коем случае на должно превышать <xx> случаев за каждый <трехмесячный период>.	Н
При приобретении может быть уместным запросить количественные показатели значимого времени между сбоями для поддержки данного требования.
	В случае любого программного или аппаратного сбоя обязательно должно быть возможным восстановить СУЭОД э(32) в известном состоянии (не позднее даты <предыдущего дня резервного копирования>) в течение не более <xx> часов с момента приведения аппаратной части в рабочее состояние.	Н

Технические стандарты

СУЭОД э(32) должна соответствовать стандартам де-факто и де-юре, имеющим отношение к данному предмету. Там где это возможно, предпочтительно использование в СУЭОД э(32)  открытых интерфейсов по сравнению с проприетарными / proprietary (т. е. собственническими, «неоткрытыми», патентованными) интерфейсами.