MoReq2010: Новая концепция отслеживания сроков хранения и её недостатки

Во время первого публичного обсуждения концепции MoReq2010, его авторы рисовали блок-схемы, которые должны были показать, как будет проходить процесс отслеживания (в том числе нескольких) сроков хранения документа и выполнения заданных действий по их истечении, см. http://rusrim.blogspot.com/2010/09/moreq2010-iv.html . Диаграммы были симпатичные, но критику выдерживали с трудом, поэтому от них, – а заодно и от удобной возможности назначать объекту несколько указаний по срокам хранения, – отказались.

Ко второму обсуждению авторы приготовили совсем иную концепцию, познакомившись заодно с основами теории конечных автоматов. Ей соответствует новая диаграмма, где показаны возможные состояния документа и переходы между ними (см. http://contribute2moreq.eu/portal/dc1-4?pointId=1290696245027#section-1290696245027 ):

Подробно описывать эту красоту авторы не стали. Впрочем, идея понятна и так. Согласно требованиям MoReq2010, всем документам тем или иным образом должны быть назначены указания по срокам хранения. Первоначально документ находится в состоянии 1, когда указание по срокам хранения назначено, однако событие, от которого должен отсчитываться срок хранения, ещё не произошло.

При наступлении события-триггера, документ переходит в состояние 2, в котором идёт отсчет срока хранения.

По истечении срока хранения, в зависимости от предусмотренных в указании по срокам хранения действий, возможны следующие варианты:

• Документ автоматически уничтожается (попадая сразу в конечное состояние 4),
  
  
• Документ переходит в состояние 3c, в котором система управления документами ждёт от администратора разрешения на уничтожение управляемых компонентов и/или подтверждения успешного уничтожения неуправляемых компонентов документа. После получения необходимых подтверждений, уничтожение документа завершается и от него остаются только остаточные метаданные (состояние 4).
  
  
• Документ переходит в состояние 3b, в котором осуществляется передача документа и система управления документами ждёт от администратора подтверждения успешного завершения передачи. После получения подтверждения, документ уничтожается (переход в состояние 4).
  
  
• Документ попадает на экспертизу ценности (состояние 3a), единственно возможным итогом которой может стать назначение нового срока хранения.

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

• На практике, в любой момент любому документу может быть назначено другое указание по срокам хранения. Это касается и документов, ожидающих передачи и уничтожения, но ещё не уничтоженных.
  
  
• В любой момент времени любой документ может быть отправлен на экспертизу ценности. Это также касается и документов, ожидающих передачи и уничтожения, но ещё не уничтоженных.
  
  
• Назначение нового срока хранения может отправить документ как в состояние 1, так и в состояние 2, поскольку событие-триггер нового срока хранения уже могло и произойти. Таким образом, из любого состояния, кроме 4, документ может перейти как в состояние 1, так и в состояние 2.
  
  
• По итогам экспертизы ценности документ может не только получить новый срок хранения, но и может быть отправлен на уничтожение или передачу.

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

• Электронные или бумажные документы могут быть безвозвратно утрачены вследствие пожара, кражи носителей и т.п. Система должна давать возможность перевести эти документы в конечное состояние 4.
  
  
• Маловероятна, но, тем не менее,  возможна ситуация, когда уничтоженный в системе документ восстановлен (например, с резервных копий), и в этот момент оказывается, что его хранение необходимо продолжить. В таком случае было бы желательно не регистрировать его заново, а использовать сохранившиеся остаточные метаданные – т.е. перевести из состояния 4 в какое-либо иное.

К этому добавлю, что, хотя MoReq2010 поддерживает большое число различных комбинаций возможных вариантов периодов хранения, способов их отсчета и задержек исполнения действий по истечении сроков хранения (чтобы справится со сроками типа «столько лет, начиная с первого января года, следующего за событием-триггером») – в нем, похоже, на данный момент не поддерживается такой срок хранения, как «до минования надобности» :)

Источник: сайт публичного обсуждения MoReq2010
http://contribute2moreq.eu/portal/dc1-4?pointId=1290696245027#section-1290696245027