xmlhack.ru XML-форумы
Обсуждение XML и связанных с ним технологий

Казахстанский машинопонимаемый коммуникативный формат

На страницу Пред.  1, 2, 3, 4

Автор Сообщение
Гость





[5097] Пн Окт 13, 2003 16:59
На "уразуметь задачу. .. или идею"
Добросовестно вспоминаю, как все было.
Этап 1 . Освоение
Обследование пилотной зоны электронного документооборота, в котором вместе со мной принимал участие разработчик лотусового документооборота в Казактелекоме – Олег Ильин. Тогда кроме Лотуса, ничего другого близко не было видно. Но в КОНЦЕ обследования, по мере накопления знаний, появилась неудовлетворенность в подходе Лотуса к созданию систем управления документами (СУД). Например, к:
Управлению потоками работ, в т. ч. сквозной документооборот;
Коллективной работы, в т. ч. версионность, особенно последовательная (Check in, Check out)
Контролю исполнительской дисциплины;
Работе с взаимосвязанными документами, в т. ч. виртуальными
Регламентации прав доступа
Подключению производственных (технологических) задач организации в систему единого документооборота, в том числе из КИС в СУД
После многочисленных споров в группе назрела необходимость высвободиться из пут Лотуса полностью (Panagon, Documentum) либо частично (Domino.Doc)
Автор в результате долгих размышлений, конференций и консультаций склонился в сторону Documentum’a.
Этап 2. Творчество
Создание концептуальной части ТЗ на первую очередь ЕСЭДО РК. Была предоставлена полная свобода творчества – пиши, дерзай, только надо, чтобы через полгода ЭТО zarabotok.bbspam.com. В тесном контакте с Константином Синюшиным (ген. Д-р Documentum Services), Андреем Афанасьевым (Весть – Метатехнология), проводя консультации с Евгением Распопиным (IBM) и его экспертами, специалистами «ГАЛАКТИКИ» по продвижению продуктов FileNET написал концептуальную часть ТЗ с понятиями «национальный уровень» (где собираются ВСЕ вышедшие за пределы ведомственного уровня документ), управление знаниями, поддержка принятия решений, языки работы с электронными документами (ЭД), классификаторы.
Этап 3. Компромисс
Создание ТЗ в части ведомственного уровня ЕСЭДО в минимальной конфигурации. Один из руководителей ЗАО НИТ тогда был человеком испуганно – осторожным и когда увидел, что ТЗ имеет в основе своей Documentum и тогда Conver’y, стал препятствовать разработке на основании невозможности положить исходные коды в депозитарий (ха-ха!). Вот тут-то и было упущено время, вот здесь и появились лотусовщики, а от них – раздел 10 ТЗ «ТРЕБОВАНИЯ К МИНИМАЛЬНОЙ КОНФИГУРАЦИИ ПЕРВОЙ ОЧЕРЕДИ ЕСЭДО РК» из лотусовой программы КУШПЕНТЕЛЕКОМА. Умеющий читать сквозь строки – добавь сюда воистину шекспировский накал страстей и изощренную борьбу!
Этап 4. Попытки выбраться из трясины
Тесное сотрудничество с кушпеновцами и понимание, что единственный способ – это купировать нищий функционал ведомственного уровня богатыми функциональными возможностями национального уровня. Как? Только один путь – пусть кушпеновская программа работает в сфере автоматизации бумажного документооборота, а национальный уровень будет обеспечивать работу с ЭД (до принятия закона о ЭД и ЭЦП оставался еще год с небольшим). Две реки – полноводная бумажная и сухой ручеек ЭД. Со временем бумажная река усыхает, а ручеек ЭД набирает силу.
Тогда появляется БАЗОВЫЙ ПРИНЦИП 1 (всего их более 20 сейчас).
«ЭД и документы на бумажных носителях существуют на основании разных нормативно – правовых баз. К ЭД применимы исключительно требования нормативно – правовых актов для ЭД и неприменимы требования нормативно – правовых актов для документов на бумажных носителях. К документам на бумажных носителях применимы исключительно требования нормативно – правовых актов для документов на бумажных носителях и неприменимы требования нормативно – правовых актов для ЭД.»
Надо разрабатывать новые акты для ЭД. Что в них заложить? Три уровня – метаданные, контент, ЭЦП.
По каким рубрикам какого классификатора раскладывать метаданные? Предложение – давайте разработаем свой классификатор и будем периодически собирать группу, пересматривающую его.
Явный тупик. Госорганы – не библиотека, где допустимы большие задержки. По мере развития государства время отклика на новые вызовы должно уменьшаться. Отсюда предположил, что классификатор должен быть ДИНАМИЧЕСКИМ. Если своего создавать не хочу, надо использовать существующие.
Ergo, пусть расцветают все классификаторы. Но тогда должны быть связки между ними.
Про связки я уже достаточно писал, не буду повторяться.
Пусть АРМ документоведа разложи т метаданные по ВСЕМ классификаторам – это ему не трудно.
Тогда АРМ присоединен к мощной СУЗ ( системе управления знаниями)
В СУЗ заложен принцип обучаемости. Но как обучать СУЗ без тренера? Далее уже тоже писал.
Отступление – вы спрашиваете - зачем чиновникам ТАКАЯ система? Документооборот – нац. Фонд ЭД – знания! Отвечаю – этот подход УТВЕРЖДЕН, слава Богу. Зачем вам докапываться до процедур?
Давайте сыграем в одну игру, не обсуждая, почему она такая.
По секрету (тс-с!) Я вижу в конце пути: Создание ГЕНЕРАЛЬНОЙ ТАКСОНОМИИ.
С другой стороны и может, правильно критиковал меня ранее Taylor.
Ну и что? Это мое видение, и только. Может, вдобавок и неверное, практически нереализуемое. Но это похоже на мизинец идеи???

Написал примерно 20% от того, что хотел, но времени не хватило. Жду комментариев.
Спасибо вам. Bazilio, сожалею, что давно не писал Taylor.
Где вы, ребята из Sun? Я все жду обещанных замечаний!
Да и с софтинжами хотелось бы поспорить – с писателями, а не менеджерами – с ними я завтра встречаюсь все больше по процедурным вопросам.
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5098] Пн Окт 13, 2003 17:18
Извинения
Прошу прощения, предыдущее сообщение было моим - непрвильно зашел. Тогда в качесте извинений добавлю материал, содержаций часть базовых принципов - новая страничка все-таки, надо загрузить Smile Они, правда, сильно устарели, но все равно, может, кто-то и найдет что-то полезное, хоть и с некоторыми повторами.
1. Цель создания второй очереди Единой Системы Электронного Документооборота государственных органов Республики Казахстан ЕСЭДО РК
Перед государственным управлением РК стоит задача максимально эффективного накопления информации, извлечения знаний из нее и организация управления информацией и знаниями.
При ручной обработке информации на бумажных носителях затраты времени недопустимо велики при посредственном качестве. Применение же автоматизированных систем управления документами (СУД) повышает качество выдаваемой информации и уменьшает время ее обработки.
В ходе создания первой очереди ЕСЭДО РК были разработаны подсистемы ведомственного уровня типа ЕСЭДО-В-1, обеспечивающие автоматизацию бумажного делопроизводства. Внедрение ЕСЭДО-В в пилотной зоне внедрения электронного документооборота позволило автоматизировать деловые процессы органов государственного управления пилотной зоны, действующие на основе нормативно - правовой базы делопроизводства на бумажных носителях информации и, таким образом, цель первой очереди создания ЕСЭДО РК была достигнута.
C принятием Закона об электронном документе и электронно - цифровой подписи, проведением научно - исследовательской работы "Разработка технического задания по созданию второй очереди ЕСЭДО РК и предварительных решений по казахстанскому машинопонимаемому коммуникативному формату" создались предпосылки для проведения работ по созданию второй очереди ЕСЭДО РК, обеспечивающей постепенный переход органов государственного управления РК на электронный документооборот с использованием в качестве основного электронного способа хранения информации.
Повсеместный переход государственного управления на электронные документы (ЭД) позволит совершить качественный скачок в управлении информацией и извлекаемых из нее знаний.
Тактические преимущества от внедрения электронного документооборота:
" Физическое освобождение места.
" Уменьшение затрат на копирование.
" Уменьшение затрат на доставку информации в бумажном виде.
" Уменьшение затрат на ресурсы: людей и оборудование.
" Уменьшение затрат на бумагу.
" Уменьшение количества безвозвратно потерянных документов.
Повышение продуктивности работы: более быстрое выполнение работ, увеличение общего количества выполняемых работ, улучшение работы с данными/записями (документами, имеющими юридические обязательства), возможность выполнения новых типов работ или выполнения работ по новым алгоритмам.
Стратегические преимущества:
" Качественно иной общенациональный доступ к информации и знаниям
" Сквозной контроль за деловыми процессами;
" Повышение качества и оперативности принятия решений.
Таким образом, цель создания второй очереди ЕСЭДО РК есть создание системы управления ЭД государственных органов РК и извлекаемыми из ЭД знаниями, на национальном уровне.
В конкурсных требованиях предусмотрено достижение этой цели путем создания и внедрения подсистем национального уровня ЕСЭДО РК - автоматизированной информационно-справочной системы, предназначенной для автоматизации технологических процессов подготовки, регистрации, структурирования, маршрутизации, хранения, архивации, поиска и обработки электронных документов, контроля их исполнения, авторизации доступа к ним, выпуска и рассылки ЭД, извлечения информации из ЭД и ее анализа, получения знаний из накапливаемой информации, поддержки принятия решений.

2. Технология работы ЕСЭДО-Н, построенной на программных решениях компаний Documentum, Verity, ABBYY и разработанных нами принципов создания нормативно - правовой базы электронного документооборота в РК
В этом разделе дано наше видение технологии работы ЕСЭДО - Н и приведены базовые принципы, на основании которых мы будем разрабатывать нормативно - правовую базу электронного документооборота.
ЕСЭДО-Н решает следующие основные задачи:
1. Разработка и согласование новых ЭД
2. Ввод в систему с преобразованием в ЭД в случае записи информации на неэлектронных носителях: писем, обращений, предложений и других документов граждан Республики Казахстан, иностранных граждан и других физических лиц, общественных, политических, государственных, коммерческих организаций и прочих юридических лиц в государственные органы РК в ЭД с дальнейшей регистраций, формированием метаданных, каталогизацией и маршрутизаций получаемых ЭД, а также занесением их в Национальный фонд ЭД при наличии соответствующих разрешающих признаков в метаданных ЭД.
3. Управление потоками работ с ЭД (workflow), в том числе сквозной контроль исполнения ЭД на всех уровнях.
4. Формирование Национального Фонда ЭД, ведение каталога ЕСЭДО РК, классификатора на основе казахстанском машинопонимаемом коммуникативном формате (далее КМПКФ) и информационно - справочного фонда находящихся в ЕСЭДО РК ЭД.
5. Извлечение и анализ данных из ЭД, хранящихся в ЕСЭДО РК.
6. Формализация, обработка и обобщение знаний, получаемых из ЭД ЕСЭДО РК.
7. Предоставление пользователю информации и знаний из всех доступных ему в соответствии с предоставленными правами доступа источников, хранящихся в НИИ РК.
8. Поддержка принятия решений высших должностных лиц государственных органов РК, в том числе создание ситуационной комнаты. Передача документов в СЭА ГО для их хранения и организация доступа по запросам пользователей ЕСЭДО РК.
9. Поддержка открытого централизованного WEB-сайта Электронного Документооборота, содержащего классифицированные открытые документы государственных организаций и поддерживающий передачу вводимых гражданами документов через сайт в ЕСЭДО РК.

2.1. Разработка и согласование новых ЭД
Разработка и согласование новых ЭД должны производиться на основании создаваемой нормативно - правовой базы ЭД. Помимо контента (содержательной части), ЭД должен содержать метаданные, составленные в Казахстанском машинопонимаемом формате (далее КМПКФ). ЕСЭДО-Н принимает ЭД в Национальный Фонд Электронных документов (НФЭД) только при условии их правильного формирования (well - formed electronic documents)..
Неправильно сформированные ЭД в НФЭД не принимаются и автоматически возвращаются отправителю. При этом подразумевается, что такая процедура возможна лишь в случае формирования ЭД без использования автоматизированного рабочего места (АРМ) документоведа. АРМ Documentum с прозрачным подключением Verity не позволяет неправильно формировать ЭД и, таким образом, на выходе указанного АРМ всегда получаются правильно сформированные ЭД.
Технология разработки ЭД в ЕСЭДО - Н заключается такова.
Разработчик документа - пользователь ЕСЭДО создает контент с использованием офисных приложений. Клиентский модуль сопрягаются с офисным программным обеспечением фирмы Microsoft (в т.ч. и Microsoft Word, Excel, Visio) и другими, используемыми для подготовки документов или разделов (полей) документов. ЕСЭДО-Н обеспечивает возможность прозрачного вызова вышеперечисленных программ при подготовке документов и включении файлов любых форматов в поля документов, выступающих в качестве контейнеров.
Documentum 4i, поддерживает совместную работу со всеми основными офисными приложениями, а также позволяет настроить программы-редакторы других форматов. Для редакторов, поддерживающих стандарт ODMA, подключаются свои собственные диалоги редактирования и сохранения текста документа (т.н. "жесткая интеграция"), когда вместо обычного диалога офисного приложения вызывается диалог ЕСЭДО-Н. Пример такой интеграции приведен на Рис. 2.1.


Рис.2.1. Пример "жесткой" интеграции офисных приложений
Для некоторых редакторов (типа Microsoft Word, Excel) возможна и так называемая "мягкая интеграция", когда в меню редактора добавляются отдельные пункты открытия/сохранения текста в САД. Гибкость данной интеграции заключается в том, что пользователь может использовать как диалог сохранения документа в САД, так и сохранять файлы в локальной файловой системе. Пример такой интеграции приведен на Рис. 2.2.


Рис. 2.2.Пример "мягкой" интеграции офисных приложений
Работая с контентом в приложении, сопряженном с ЕСЭДО-Н, пользователь может вставить в тело ЭД объект (другой документ) их хранилища (БД), при этом возможна вставка как самого тела документа, так и объекта с сохранением с ним логической связи. Пример такого диалога, доступного из офисного приложения приведен на Рис. 2.3


Рис. 2.3. Пример диалога вставки в тело документа объекта
(другого документа) из хранилища
Платформа Documentum 4i поддерживает более 200 форматов представления данных (см. Рис. 2.4). Это офисные, почтовые, графические, аудио, видео и другие форматы.


Рис.2.4. Список поддерживаемых форматов (выдержка)
Пользователи могут сохранять одновременно несколько представлений (внешних видов, форматов) одного и того же документа (см. Рис. 2.5).


Рис.2.5. Пример выбора формата при создании нового документа
Хранилище Documentum 4i автоматически синхронизирует содержимое всех сохраненных представлений и при запросе, вводе и/или импорте документов их формат автоматически определяется и конвертируется в определяемый пользователем. Для предоставления документов внешним пользователям платформа Documentum 4i eBusiness использует универсальное представление, автоматически переводя документ в PDF или в HTML-форматы. Для унификации предоставления документов в Documentum 4i используют AutoRender Pro - программный модуль, предназначенный для перевода офисных приложений в PDF и/или HTML - форматы, для обеспечения доступа к ним вне зависимости от приложений конечного пользователя.


Рис.2.6. Поддержка офисных и других форматов документов хранилищем Documentum 4i
Если пользователь осуществляет поиск документа через Explorer (см. Рис. 2.6), то возможна пересылка текста как в оригинальном формате (в формате того текстового процессора, в котором он хранится в хранилище), так и конвертация документа в универсальный формат PDF или HTML. Во втором случае имеются следующие преимущества:
" у пользователя на компьютере может отсутствовать указанный текстовый процессор, в котором находится оригинал текста документа (что довольно часто для документов с большим сроком давности);
" возможно формирование PDF файла таким образом, что пользователь не сможет распечатать документ и делать копирование текста, имея возможность его просмотра;
" возможность формирование PDF файла с включением ЭЦП (электронно - цифровой подписи) (к примеру, при переходе документа из состояния жизненного цикла "На подписи" в состояние "Приказ принят"), возможно автоматически переконвертировать документ с созданием PDF файла, который будет включать ЭЦП под данным документом.
Пользователь, закончив составление / подбор контента, ставит при необходимости свою ЭЦП и задает режим в клиентской части ЕСЭДО-В "Формирование метаданных", после чего осуществляет корректировку сформированных метаданных и добавление тех метаданных, которые невозможно было извлечь из контента (например, маршрут, операции и т.д.).
При создании нового ЭД, пользователь-разработчик документа автоматически получает на него определенные права, причем Documentum 4i позволяет настраивать устанавливаемые права в зависимости от следующего:
" Прав по умолчанию на данный тип документа (например, на созданный проект документа пользователь получает права на удаление документа, а на созданный входящий документ - права на чтение);
" Ящика/папки, в которой создается документ (например, на созданный документ в ящике "Проекты" пользователь получает права на удаление документа, а на созданный документ в ящике "Входящие" - права только на чтение);
" Матрицы доступа, установленной по умолчанию (например, на любой созданный документ определенного типа, который может создавать пользователь, его руководитель будет автоматически получать права на чтение, сам пользователь - права на удаление, а рабочая группа, в которой он работает, - права создания версии данного документа);
" Жизненного цикла документа, автоматически, или с участием пользователя назначаемого на данный тип документа. Например, на созданный документ типа "Входящий", в зависимости от значения атрибута "Кому", будет назначен жизненный цикл "Входящий документ для юридического отдела", и пользователи группы "Юридический отдел" получат права на чтение, тогда как остальные пользователи САД не будут даже знать о существовании данного документа, так как у них не будет прав доступа к нему;
" Участия документа в технологических процессах (например, на документ типа "Проект приказа", пришедший в рамках технологического процесса, руководителю подразделения могут быть установлены права создания версии документа для внесения комментариев, а после того, как документ ушел по технологическому процессу от руководителя подразделения исполнителю, права на документ могут быть восстановлены в состояние, которое он имел до того, как попал руководителю).
Созданный ЭД в процессе дальнейшей работы с ним на протяжении всех этапов жизненного цикла, начиная с процесса создания до момента списания в архив, может иметь различные жизненные циклы, участвовать в различных технологических процессах, переходит на новые этапы жизненного цикла и возвращаться в предыдущие состояния (например проект приказа может несколько раз находится в состояниях жизненного цикла "На утверждение" и "На доработку"). Для соответствующих этапов жизненного цикла могут автоматически устанавливаться новые права (в т.ч. запрет удаления после этапа регистрации). Определенные пользователи, группы пользователей и определенные должностные лица могут получить права принудительно снять документ с обработки, т.е. прекратить обработку документа. Например, руководителю подразделения может быть предоставлено право снять с согласования проект документа, разработанного в данном подразделении.
Documentum 4i имеет возможность установки прав как для определенных пользователей и групп, так и на определенные должностные роли, называемые псевдонимами (например можно назначить доступ на документ для роли "Руководитель юридического отдела", в дальнейшем, изменив значение роли для определенных пользователей, можно обеспечить автоматическую передачу прав на документ от одних пользователей другим).
ЕСЭДО-Н обеспечивает продвижение ЭД по этапам их жизненного цикла согласно заданной технологии. В зависимости от функций по обработке документов, выполняемых конкретным пользователем (регистрация документов, выдача резолюций, визирование проектов документов и т.п.), для каждого пользователя формируются очередь документов на обработку.
Если к данному пользователю документы поступают с различными целями (на рассмотрение с целью выдачи резолюции, на исполнение, на ознакомление и т.п.), то осуществляется автоматическое формирование нескольких очередей документов на обработку, в зависимости от цели поступления. В случае необходимости пользователь также видит перечни документов, обрабатываемых в текущий момент другими пользователями (например, перечень подготовленных пользователем проектов документов, находящихся на согласовании в других подразделениях). Пример структуры очереди проектов документов, обрабатываемых в структурном подразделении, представлен на Рис.2.7.


Рис. 2.7. Пример структуры очереди проектов документов
Перечень очередей обработки документов различными пользователями (различными типами пользователей) определяется конкретной технологией делопроизводства, настраивается из соответствующих классификаторов КМПКФ и может модифицироваться в процессе эксплуатации без использования дополнительного программирования.
Данная очередь формируется из ссылок на соответствующие документы и отображается в табличной форме. Состав столбцов таблицы настраивается.. Пользователю из данного списка предоставляется возможность просмотра или редактирования метаданных контента ЭД. Пример очереди документов приведен на Рис. 2.8.


Рис. 2.8. Пример очереди ЭД, поступивших на обработку
Результаты обработки документа на рабочем месте фиксируются в РК документа вручную или автоматически (в зависимости от состава информации). После того, как обработка документа завершена, документ должен быть передан далее по технологической цепочке. Для этого используется рассылка документа. Если по результатам обработки документа возможны различные варианты рассылки, то пользователь должен выбрать тип рассылки. Например, для учтенного в системе проекта документа может быть выбран один из следующих типов рассылки:
" на визирование непосредственному руководителю;
" на согласование;
" на утверждение.
Доступные пользователю типы рассылок определяются технологией делопроизводства. В процессе эксплуатации ЕСЭДО пользователю может предоставляться доступ к существующим типам рассылок без использования дополнительного программирования.
В зависимости от выбранного типа рассылки автоматически формируется список рассылки. Например, при выборе руководителем, выдавшим резолюцию, типа рассылки "на исполнение", в список рассылки будут автоматически включены сотрудники, которым адресована данная резолюция. Пример выбора типа рассылки представлен на Рис. 2.9.


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

БАЗОВЫЙ ПРИНЦИП 1.
ЭД и документы на бумажных носителях существуют на основании разных нормативно - правовых баз. К ЭД применимы исключительно требования нормативно - правовых актов для ЭД и неприменимы требования нормативно - правовых актов для документов на бумажных носителях. К документам на бумажных носителях применимы исключительно требования нормативно - правовых актов для документов на бумажных носителях и неприменимы требования нормативно - правовых актов для ЭД.

2.2. Преобразование информации на неэлектронных носителях в ЭД
В случае записи информации на неэлектронных носителях: писем, обращений, предложений и других документов граждан Республики Казахстан, иностранных граждан и других физических лиц, общественных, политических, государственных, коммерческих организаций и прочих юридических лиц, не прошедшие через государственные органы РК, а поступившие в ЕСЭДО-Н, в случаях предусмотренных разрабатываемыми нормативно - правовыми актами об электронном документообороте, производится обработка их на АРМ документоведа с преобразованием в ЭД с дальнейшей регистраций, формированием метаданных, каталогизацией и маршрутизаций получаемых ЭД, а также занесением их в НФЭД при наличии соответствующих разрешающих признаков в метаданных ЭД..
Вышеуказанные задачи аппаратно - программное обеспечение ЕСЭДО-Н на базе Documentum с использованием программных продуктов фирмы ABBY выполняет через осуществление следующих функций:
" пакетное сканирование документов на бумажных и пленочных носителях с получением электронного образа высокого качества;
" предварительная обработка изображений для повышения качества отсканированных документов (очистка изображения от пятен, его масштабирование, разворот);
" преобразование электронного графического образа документа в текстовый формат (обработка изображения документа подсистемой оптического распознавания символов);
" верификация ввода документов (визуальную сверку исходного изображения текста с символьными данными, записываемыми в текстовый файл) и редактирование получившихся текстовых файлов с целью исправления ошибок;
" введение метаданных на сканированные, аудио, видео документы с автоматической их категоризацией на основании машинного анализа текстового, аудио, видео контента документов и вручную;
" подписание электронного образа документа электронной цифровой подписью уполномоченного лица;
" формирование ЭД как результат завершения предыдущих операций (некоторые особенности формирования ЭД могут быть представлены с учетом представленной в предыдущем подразделе информации).

2.3. Регистрация и рассылка ЭД
После завершения процесса согласования ЭД и утверждения (подписания его необходимыми ЭЦП) документ попадает на АРМ документоведа, где происходит добавление необходимых метаданных с добавлением ЭЦП уполномоченного на то документоведа и при правильном формирования ЭД согласно требованиям КМПКФ он передается в НФЭД ЕСЭДО-Н и далее обрабатывается согласно метаданных ЭД. На каждом этапе дальнейшей обработки ЭД в его метаданные в тэг данных общей обработки добавляются сведения о результатах обработки
ЕСЭДО - Н обеспечивает ведение по каждому ЭД журнала, фиксирующего действия, связанные с созданием, согласованием и утверждением проекта, с регистрацией, обращениями, оформлением резолюций и поручений к документу. Данные журнала отображаются в табличной форме. Состав столбцов таблицы настраивается без применения дополнительного программирования. Пример данной таблицы приведен на Рис. 2.10


Рис.2.10. Пример ведения истории работы с ЭД

2.4. Поддержка шаблонов
ЕСЭДО -Н включает средства формирования шаблонов, обеспечивающие возможность структурирования текстовой части контента ЭД путем разделения ее на поля и группы полей (секции) с возможностью определения для них типов данных, правил заполнений и агентских процедур обработки событий.

Сервер приложений e-Content server Documentum 4i позволяет создавать группы шаблонов, на базе которых могут создаваться необходимые типы документов. Все форматы документов записываются в хранилище. На каждый из таких форматов возможно определение отдельных прав доступа, вследствие чего каждый пользователь или группа пользователей будет видеть только те шаблоны, к которым у них имеются права доступа.
В Documentum 4i предусмотрена возможность создания составного документа (см. Рис. 2.11), в котором каждый из входящих в него документов может быть документом разного типа со своими правилами обработки. Например, составной документ по кредитной операции может иметь следующие типы документов, каждый из которых может формироваться на базе шаблона MS Word, MS Excel, или любого другого, импортированного в хранилище:
" кредитный договор, распоряжение на рассмотрение возможной кредитной операции;
" отчет службы безопасности по кредитополучателю;
" сводный документ по истории финансовых операций с кредитуемой организацией;
" текущая дебиторская задолженность кредитуемой организации;
" текущая кредиторская задолженность кредитуемой организации;
" указание на выдачу кредита.

Рис.2.11. Пример интерфейса менеджера сводных ЭД с группами входящих в него документов разного формата и типа

Каждый из этих документов имеет свои метаданные, поля и группы полей, типы данных, правила обработки, доступные жизненные циклы и состояния жизненных циклов, маршруты прохождения, набор административных агентов, обеспечивающих как обработку событий как по каждому из документов, так и по составному документу в целом. Однако вместе они будут логически связаны и образуют составной ЭД.
В хранилище Documentum 4i можно импортировать любые шаблоны ЭД, которые будут иметь свой тип, а следовательно и типы данных, метаданных, правила обработки и список доступных шаблонов текстов, на базе которых они будут формироваться. Для работы с текстом шаблона ЭД возможно задействовать функционал соответствующего редактора для включения в текст данных из хранилища (значений атрибутов, список связей и т.д.), или, используя внутренние правила обработки, обеспечиваемые текстовым (табличным) процессором (например, при создании табличного документа на базе шаблона MS Excel вводимые данные будут приводить к автоматическому пересчету значений в таблице).

В составе Documentum 4i есть средства обработки, обеспечивающие также способы формирования шаблонов на базе обработки XML/XSLT и схемной организации формирования документа на базе имеющегося шаблона XSLT и описания структуры документа через DTD (document type definition), обеспечивающие мощные средства работы при Internet/Intranet решениях, связи документов и их метаданных с другими функциональными системами.

2.5. Доступ участников электронного документооборота к ЭД (в том числе проектам ЭД)
Доступ участников электронного документооборота к ЭД, в том числе проектов ЭД, осуществляется с учетом проверки их полномочий. При проведении согласований и утверждений их участникам передаются ссылки, которые открывают доступ к проектам документов без их физического перемещения. Сразу после создания полный доступ к проекту имеет лишь его автор (исполнитель), вышестоящие руководители подразделения и отдела могут только читать проект или передавать его другим исполнителям. В дальнейшем, по ходу визирования, согласования и утверждения проекта полномочия лиц, работающих с проектом, меняются в соответствии с изменениями состояния проекта.
Documentum 4i для любого объекта поддерживает список прав доступа (по пользователям, группам, функциональным ролям (псевдонимам).
Нарастающие (последующие включают предыдущие):
" None - нет доступа (не виден).
" Browse - просмотр атрибутов (но не текста).
" Read - просмотр текста без возможно внесения правок.
" Relate - можно подключать аннотации и связывать с другими документами.
" Version - можно создавать версии (т.е. текущую версию можно только просматривать, а сохранять изменения только в новой).
" Write - можно исправлять объект (атрибуты и текст).
" Delete - можно удалять объект.

Расширенные права (в любой комбинации):
" Change Location - можно перемещать объект в другую папку
" Change Permissions - можно менять доступ к объекту
" Change State - можно менять состояние жизненного цикла
" Execute Procedure - можно вызывать методы
" Take Ownership - можно менять владение объектом


Рис.2.12. Пример назначения прав на версию документа
Права могут быть проставлены пользователем как вручную в метаданных, так и меняться автоматически при смене жизненного цикла или выполнении серверного метода.
Кроме того, для каждого пользователя / роли в системе указаны его привилегии и "тип клиента", сразу определяющие круг действий, которые пользователь может выполнять в системе (соответствие уровня доступа к функциональному классу действиям над документами).
ЕСЭДО-Н использует эти права и привилегии в операциях с документом, а также управляет назначением прав при переходах документа между участниками документооборота. В частности, при создании проекта разработчик может иметь на него права WRITE (на запись), а его руководство будет иметь права VERSION (может читать текущую версию и создать новую с исправлениями).

2.6. Уникальная идентификация ЭД в ЕСЭДО - Н и классификаторы на основе КМПКФ
ЕСЭДО - Н обеспечивает уникальную идентификацию ЭД при их регистрации. При регистрации документ сохраняется в централизованной БД. Ему присваивается уникальный системный идентификатор DocID, который не представляется пользователям в явном виде и используется для внутрисистемных целей. Однако он проставляется в метаданных в тэге uniqueid. Пользователи идентифицируют документ по его регистрационному номеру DocRN.
Алгоритм формирования регистрационного номера определяется выбранной технологией и может модифицироваться в процессе эксплуатации.
Documentum может быть настроен как на централизованную, так и на децентрализованную нумерацию документов. В рамках первого типа нумерации поддерживаетcz единый счетчик документов определенного типа в пределах всей ЕСЭДО. В рамках второго типа нумерации обеспечивает ведение индивидуальных счетчиков ЭД для каждой организации. Таким образом, функционал Documentum обеспечивает широкие возможности обработки метаданных ЭД.
Documentum 4i позволяет создавать новые типы документов со своим набором атрибутов, а также наследовать существующие типы с наследованием всех их атрибутов и настроек с добавлением своих атрибутов и возможностью переопределения стандартных операций (открытия РК, текста, выписывания/сохранения в БД и т.д.).

БАЗОВЫЙ ПРИНЦИП 2.
В электронном документообороте функцию структурирования ЭД выполняют классификаторы КМПКФ и поэтому группировка ЭД может быть осуществлена пользователем по любому классифицирующему признаку. Поэтому сколько есть таких признаков в данной версии КМПКФ, столько виртуальных номенклатур дел можно получить в ЕСЭДО.

В общем случае Documentum 4i предоставляет широкие возможности как по созданию классификаторов внутри Documentum 4i, так и использованию внешних. В частности, внешние классификаторы могут быть либо импортированы в Documentum 4i, либо к ним возможен доступ через API подсистемы управления знаниями, в которой эти справочники хранятся.
В ЕСЭДО - Н на момент проведения ее тестирования будут существовать следующие классификаторы:
для обязательных тэгов КМПКФ (имеется всегоодин неклассифицируемый тэг из числа обязательных - заголовок ЭД title);
" Классификатор общей обработки ЭД processingdata;
" Классификаторы языков;
" Классификаторы авторов
И для формирования факультативных тэгов КМПКФ (в том числе справочники, рубрикаторы и пр. системы структурирования):
" Классификатор формата КМПКФ (formatversion)
" Классификатор видов ЭД (mode document);
" Классификатор маршрутов ЭД;
" Классификатор обработки ЭД;
" Классификатор виртуальных дел;
" Справочник корреспондентов (физических и юридических лиц);
" Международный коммуникативный формат UNIMARC
" Система национальных счетов СНС93
" Международная статистическая классификация болезней и проблем, связанных со здоровьем МКБ-10
" Перечень промышленной продукции ПРОДКОМ
" Международный классификатор изобретений МКИ
" Межгосударственный классификатор единиц измерения МКЕИ
" Межгосударственный рубрикатор научно-технической информации МРНТИ
" Универсальный десятичный классификатор УДК
" Десятичный классификатор Дьюи
" Классификатор товарной номенклатуры внешнеэкономической деятельности ТН ВЭД
" Общий классификатор предприятий и организаций ОКПО
" Общий классификатор видов экономической деятельности ОКЭД
" Классификатор продукции по видам экономической деятельности КП ВЭД
" Классификатор занятий КЗ
" Классификатор специальностей начального и среднего профессионального образования
" Коды для обозначения валют и фондов
" Коды для обозначения наименований стран и их территориальных объединений
" Классификатор направлений подготовки и специальностей высшего профессионального образования РК
" Библиотечно - библиографическая классификация ББК
" Единая классификация литературы для книгоиздания в СССР
" Номенклатура специальностей научно - технических работников
" Классификатор секторов экономики КСЭ
" Классификатор организационно-правовых норм хозяйствования КОПФ
" Классификатор форм и видов собственности КФС
" Классификатор размерности предприятий по численности занятых КРП
" Классификатор административно-территориальных объектов КАТО
" Система обозначений органов государственного и хозяйственного управления СООГУ
" Справочник оргструктур
" Классификатор предприятий по объему производства КПОП
" Бюджетная классификатор доходов и расходов РК
" Единый классификатор назначения платежей ЕКНП
" Номенклатура отраслей наук и специальностей
" Общий классификатор управленческой информации ОКУД
" Классификатор индивидуального потребления по целям КИПЦ
" Статистическая номенклатура товаров по видам услуг торговли СНТВУТ
" Статистический классификатор промышленной продукции
" Статистический классификатор продукции сельского, лесного и рыбного хозяйства
" Статистический классификатор строительных работ (услуг)
Для работы с системами структурирования предусмотрены встроенные сервисные функции, обеспечивающие многоуровневую иерархию справочников, быстрое нахождение записи путем ограничения или подсвечивания записей при наборе начальных букв, а также средства поиска.
ЕСЭДО обеспечивает включение классификаторов в КМПКФ извне с пересчетом взаимоотношений между включаемыми и существующими классификаторами, в случае изменения каких либо классификаторов и т. п..

2.7. Управление потоками работ с использованием метаданных ЭД
БАЗОВЫЙ ПРИНЦИП 3.
Вся информация об обработке и движении ЭД записывается в его метаданных. ЕСЭДО - Н осуществляет автоматическое управление потоками работ, обрабатывая информацию о технологическом процессе (маршруте) ЭД, записанной в тэгах деловых процессов метаданных ЭД и записывая в них результат обработки.

Средство визуального проектирования произвольного технологического процесса (маршрута) ЭД (Workflow manager) Documentum, доступно каждому пользователю. В составе дизайнера технологических процессов можно представить графически процесс прохождения ЭД или группы ЭД, указать, какие операции, кем и в какой последовательности будут производиться. При этом существует возможность указать как определенную группу или конкретного пользователя, так и функциональную роль (например - "руководитель отдела"). Назначение задачи данному пользователю может производиться как при запуске технологического процесса, так и процессе его работы
Также можно назначить для выбранного типа ЭД необходимые жизненные циклы, использовать набор должностных ролей (псевдонимов), набор состояний в проектируемом жизненном цикле.
Предусмотрена возможность настройки на каждом этапе жизненного цикла функционала обработки ЭД, условий, необходимых для ЭД в данное состояние, правил обработки их до и после попадания в определенное состояние, установки автоматических процедур осуществления операций над ЭД как до, так и после прохождения им соответствующего этапа. Возможна настройка перемещения ЭД в базовое состояние с учетом изменения как контента , так и метаданных, а также планового перемещения ЭД из состояния в состояние по времени, с учетом наличия не только "обычных", но и "экстраординарных" состояний. Все эти возможности настройки предусмотрены для каждого состояния жизненного цикла.
В процессе настройки предусмотрена возможность определения динамического исполнителя, когда известно, какое действие должно быть произведено над ЭД (например, для операции "Утверждение" ее исполнитель, назначается на одном из этапов прохождения ЭД по маршруту). Возможно задание исполнения данного действия как всеми пользователями группы или роли (например, при согласовании ЭД он должен быть просмотрен всеми пользователями группы), так и одним пользователем из группы (например, для ЭД, направленного в секретариат, где работают несколько пользователей назначенной группы, достаточно назначить из их числа одного исполнителя). В этом случае может автоматически осуществляется динамическая балансировка загрузки исполнителей (задание появится у того, у кого находится наименьшее количество задач), или же задание будет назначено первому из исполнителей, кто возьмет его на исполнение. Имеется возможность определять дальнейший маршрут прохождения а как в зависимости от выбора пользователя, выполняющего задание на определенном этапе маршрута, так и в зависимости от атрибута ЭД.
При определении задания можно назначить пользователю возможность переназначения пришедшего задания. Например, в случае неизвестного заранее исполнителя действия задание назначается документоведу или начальнику отдела, а он в свою очередь переназначает задание подчиненному. Для любого задания можно установить уведомление о сроках исполнения, если данное действие не было выполнено в определенный промежуток времени как с начала получения задания исполнителем, так и со времени запуска технологического процесса.
В процессе создания технологического процесса возможно использование в качестве основы проектируемого маршрута части имеющегося в хранилище типового маршрута. После создания, сохранения и проверки непротиворечивости маршрута технологического процесса ЭД или группа ЭД может быть запущен по этому маршруту. В процессе прохождения ЭД или группы ЭД по маршруту можно всегда узнать, где именно находится ЭД на маршруте (см.Рис. 2.13). При этом отражается не только, где именно находится сам ЭД, но также и указывается статус задачи, в рамках которой он послан.
После подтверждения получения задания автоматически генерируется изменение статуса задания, оно переходит из статуса "Доступно" в статус "Принято", а в статусе задачи в средстве мониторинга изменяется цвет индикатора под задачей. Цвет индикатора свидетельствует о состоянии данной задачи. Имеются следующие виды индикатора:
- задание неактивно
- задание доставлено и доступно для исполнения
- задание выполнено
- задание приостановлено
- задание не выполнено в срок или остановлено


Рис.2.13. Мониторинг прохождения ЭД по маршруту технологического процесса
При настройке возможна реализация как стандартных процессов с формированием строго определенных маршрутов, в том числе из классификатора деловых процессов, что позволяет более наглядно представить (разбить по этапам) пришедшие к пользователю задания (по очередям на обработку с названиями соответствующих этапов: "на резолюцию", "для согласования", "для утверждения" и т.д.), так и предоставление пользователю возможности создания других маршрутов. Возможно подключение внешнего маршрута, например спроектированного системным администратором с последующим запуском ЭД по данному маршруту. Возможна реализация варианта свободной рассылки на любого пользователя в папку "свободная рассылка" без контроля маршрута, а также отправление ЭД без какого либо маршрута определенному пользователю, группе функциональной роли, или по списку рассылки.

2.8. Формирование НФЭД
Национальный Фонд электронных документов является основным хранилищем обращающихся в госорганах ЭД, из которого извлекаются информация и знания для поддержки принятия решений.
Формирование НФЭД основывается на следующих базовых принципах:

БАЗОВЫЙ ПРИНЦИП 4.
ЭД в НФЭД ЕСЭДО - Н всегда хранится в единственном экземпляре, и везде, где он виден - это ссылки на него (это касается наличия документа в разных папках, ссылках на него из технологических процессов (маршрутах,workflow), отображении их в настройке делопроизводства). В этом случае при работе с документом всегда будет доступна последняя и актуальная его версия. Имеется возможность просмотра всех списков версий и порождения ветвей от них (к примеру, новая версия документа будет браться не из последней, а из предпоследней версии документа, в этом случае образуется новая ветвь), тогда как при рассылке текста документа никогда нет гарантии, что эта версия актуальна и в нее не внесены какие - либо изменения с момента рассылки или копирования.

БАЗОВЫЙ ПРИНЦИП 5.
Любой правильно сформированный ЭД с достоверными электронно - цифровыми подписями, прошедший через Транспортную среду, сохраняется в НФЭД. В противном случае ЭД возвращается по адресу отправителя с отметкой об ошибке. По истечении установленного времени хранения после завершения своего жизненного цикла ЭД передается в СЭА ГО и затем по получении подтверждения о приеме удаляется из НФЭД.

БАЗОВЫЙ ПРИНЦИП 6.
Каждая единица хранения ЭД в НФЭД включает две составляющие - проект ЭД и собственно ЭД.

ЕСЭДО-Н обеспечивает хранение проектов ЭД и собственно ЭД в специальной базе, называющейся хранилищем (Docbase).. Предусмотрено, что ЭД может представляться в ЕСЭДО-Н только с метаданными без хранения контента (при этом метаданным может не сопоставляться никакого файла или сопоставляться пустой файл).
Атрибутивная информация хранится в структурированном виде в СУБД (MS SQL, Oracle, DB2 и др.), а контент ЭД - в закрытых правами операционных систем каталогах, доступ к которым производится через сервер приложений e-Content Server, при этом могут использоваться следующие операционные системы:
" Windows
" Solaris
" AIX
" HP UX
" любая другая, к которой обеспечен доступ на уровне бинарных файлов.
Сервер приложений e-Content Server системы Documentum 4i, являющийся ядром подсистемы документооборота и делопроизводства национального уровня, автоматически поддерживает требуемые связи и целостность БД, операции над метаданными и контентом (в том числе полнотекстовую индексацию), а со стороны пользователя и разработчиков все документы представляются едиными объектами. Подобная организация хранения проектов и документов предоставляет следующие преимущества:
" управление метаданными средствами соответствующей СУБД, обеспечивающей высокую производительность работы с метаданными, автоматический контроль целостности и непротиворечивости вводимой информации, отслеживание связей между объектами;
" гибкое управление физическим расположением контентом ЭД.
В процессе создания, тестирования, эксплуатации возможно изменение конфигурации Documentum 4i. Выбор конфигурации зависит от нагрузки, объема и потока документов и т.д. Возможны следующие конфигурации системы с точки зрения организации хранения:
" организация различных физических мест хранения контента ЭД на одном сервере Documentum;
" установка нескольких серверов Documentum 4i (в том числе на большом удалении между офисами со связью по каналам относительно невысокой пропускной способности) с репликацией контента ЭД между ними;
" разнесение системы на несколько физических БД (например, каждый тип документа на отдельную БД);
" .организация удаленных рабочих мест для быстрого внедрения электронного документооборота в государстве с подключением госорганов, не имеющих внутреннего электронного документооборота, но получающих в результате подключения отделов документационного обеспечения к ЕСЭДО через удаленные рабочие места.


БАЗОВЫЙ ПРИНЦИП 7.
ЭД, хранящийся в НФЭД, а после передачи его в СЭА ГО, является эталоном ЭД. Эталон ЭД используется в случаях, предусмотренных нормативно - правовых актами проверках подлинности ЭД.

БАЗОВЫЙ ПРИНЦИП 8.
Эталон ЭД может быть удален из НФЭД только на основании соответствующих нормативно - правовых актов. Ответственность за исполнение этого принципа несет уполномоченный орган, обеспечивающий функционирование ЕСЭДО-Н.

БАЗОВЫЙ ПРИНЦИП 9.
Любая модификация эталона ЭД вызывает формирование его версии. Версии связаны между собой гиперссылками.

БАЗОВЫЙ ПРИНЦИП 10.
Между ЭД, а равно как их версиями, могут быть прямые и обратные гиперссылки Тэг обратной гиперссылки в метаданных ЭД содержит список хранимых в НФЭД и СЭА ГО ЭД, ссылающихся на данный ЭД.

2.9. Ведение каталогов, классификаторов и информационно - справочного фонда ЕСЭДО РК
Каталоги, классификаторы, информационный фонд и КМПКФ поддерживаются ПО Documentum и Verity на основании следующих базовых принципов:

БАЗОВЫЙ ПРИНЦИП 11.
Главный Каталог ЕСЭДО-Н является средством раскрытия содержания НФЭД, помощи пользователям ЕСЭДО РК и НИИ РК в выборе ЭД. Широта тематики и многообразие видов ЭД, а также существенное различие запросов обуславливают необходимость создания сложной системы Главного Каталога ЕСЭДО-Н, базирующейся на КМПКФ. Группировка ЭД в Главном Каталоге ЕСЭДО- Н осуществляется по всем классификаторам, имеющимся в КМПКФ. Все каталоги ЕСЭДО РК основаны на Главном Каталоге ЕСЭДО-Н.

БАЗОВЫЙ ПРИНЦИП 12.
Каталогизация ЭД как совокупность описания, классификации, предметизации ЭД и организации каталогов ЕСЭДО РК осуществляется в АРМ атрибутирования документоведа. Для поддержки актуальности каталогизации на местах периодически (обычно один раз в сутки) осуществляется согласование классификаторов ЕСЭДО-В с Главным Классификатором ЕСЭДО-Н.

БАЗОВЫЙ ПРИНЦИП 13.
Классификатор ЕСЭДО РК есть система упорядоченного расположения ЭД, выполненная согласно принципам КМПКФ, в логической последовательности и соподчинении на основе признаков, различаемых в КМПКФ. Классификатор ЕСЭДО РК также есть совокупность описания, классификации, предметизации ЭД и организации каталогов ЕСЭДО РК. Поддерживается подсистемой управления знаниями.

БАЗОВЫЙ ПРИНЦИП 14.
Информационно - справочный фонд ЭД ЕСЭДО РК есть система ранжированного предъявления конкретному пользователю находящихся в ЕСЭДО РК ЭД, сформированная на основе анализа и изучения информационных потребностей пользователей ЕСЭДО РК различных категорий. Поддерживается подсистемой управления знаниями.

2.10. Формирование справок и отчетов
ЕСЭДО-Н обеспечивает формирование справок о реквизитах и состоянии конкретных проектов и документов (где находится, кем согласован, какие по проекту замечания, какие по документу резолюции, поручения и т.д.), а также делопроизводственных отчетов с возможностью их параметризации и установки фильтров (т.е. включения в отчеты проектов и документов с заданными значениями или областями значений реквизитов).
Справки и отчеты реализуются в системе Documentum 4i несколькими способами, применение которых зависит от пожеланий пользователей, в т.ч.:
" путем сохранения формируемых поисковых запросов;
" путем программно формируемых запросов, также представляемых пользователю в виде сохраненных запросов;
" через специальное средство для формирования отчетов - Reporting Gateway, поставляемое с Documentum 4i;
" путем вывода результатов соответствующих запросов, формируемых через язык запросов DQL или DFC в текст документов Microsoft office (формирование Word и Excel -документа).
Сохранение формируемых поисковых запросов выполняется через визуальный интерфейс (см. Рис. 2.14), в котором можно указать один или несколько атрибутов, сопоставляя каждому из атрибутов единственное значение или диапазон значений, задаваемый с использованием логических операторов. При этом можно указывать как определенные папки хранилищ (БД), так и полностью хранилище или группу хранилищ, а также диапазон дат.


Рис. 2.14. Пример задания значений реквизитов
для формирования отчета
Предусматривается задание полнотекстового поиска вхождения указанного текста в тело документа, автора, даты создания, типа документа и любых других атрибутов и групп атрибутов, с визуально настраиваемой группировкой и сортировкой атрибутов, включаемых в выводимый отчет.
Программно формируемые запросы представляются пользователю в виде сохраненных запросов
При их формировании существуют дополнительные возможности использования встроенного языка запросов Documentum Query Language с возможностью вызова определенных служебных функций, включающих запросы как к внешним справочникам, так и к внутренним объектам Documentum, (например, с ограничением списка выводимых документов по участию в определенных маршрутах прохождения, или находящихся в определенном состоянии жизненного цикла, указанием времени их нахождения в данном состоянии). Преимущества данного метода формирования отчетов заключаются в оптимизации построения выборки по производительности на стадии проектирования запроса.
Для построения отчетов могут быть использованы стандартные промышленные генераторы отчетов, которые способны получать данные по ODBC протоколу. Documentum 4i имеет модуль Documentum Report Gateway, который по сути является ODBC драйвером к объектно-ориентированному хранилищу информации системы Documentum 4i. Промышленные генераторы отчетов способны сохранять информацию в различных форматах, выводить её на печать. Наиболее современные изделия этого класса имеют специализированные WEB сервера для формирования отчета и удаленного их анализа. Примером такого генератора отчетов является Crystal Report Enterprise Edition (текущая версия 8.5).
Documentum Report Gateway позволяет работать с хранилищем (БД) как с реляционной базой данных. Преимущества данного метода состоят в использовании всей мощи специальных средств (генераторов отчетов), включая графическое представление, создание многостраничных отчетов с различной группировкой и сортировкой по полям, построение аналитических выборок, однако его недостаток - необходимость специального модуля, или генератора отчетов на каждом рабочем месте, где требуется создание таких отчетов.
Возможен также вывод результатов соответствующих запросов, формируемых через язык запросов DQL или DFC в текст документов Microsoft office (формирование Word и Excel -документа) обеспечивает такие преимущества как простота использования, отсутствие на рабочем месте пользователя каких - либо генераторов отчетов, возможность использования заранее заготовленных бланков отчетов, возможность дальнейшей работы с таким файлом как с документом MS OFFICE - форматированием, изменением теста, распечаткой и т.д.
ЕСЭДО-Н обеспечивает формирование отчетов с включением документов с заданными значениями или областями значений реквизитов:
" По проектам документов - вывод списка проектов, содержащихся в хранилище с указанием для каждого проекта его автора, даты создания, даты утверждения, вида документа, основания для разработки (реквизитов поручения, на основании которого был создан проект).
" По содержимому обязательных и персональных дел - вывод списка документов, содержащегося в конкретном деле, с указанием для каждого документа наименования, регистрационного номера, даты регистрации, подразделения, где был подготовлен документ, автора документа, вида документа, полномочий доступа
" По поручениям руководителей - список выданных поручений с указанием для каждого поручения (выполнено/отменено/ в работе). Невыполненные поручения должны выделяются жирным шрифтом (возможно выделение иным способом)
" По персональным накопителям - список документов, находящихся в накопителе с указанием для каждого документа даты поступления, отправителя или адресата вида документа. Невыполненные поручения выделяются жирным шрифтом (возможно выделение иным способом)
В ЕСЭДО-Г возможно формирование отчетов и другими методами на основе информации, хранящейся в системе.
При формировании отчетов строго учитываются права доступа на документ, при этом в отчеты включаются только те документы, на которые у пользователя, формирующего отчет, имеются права (требуются права как минимум на то, чтобы пользователь имел доступ на чтение метаданных ЭД).


2.11. Извлечение и анализ данных из ЭД
Извлечение и анализ данных из ЭД есть первый этап формирования знаний из содержащейся в ЭД информации, где под знаниями понимается результат осмысления информации по заданным критериям. Отсюда для извлечения и анализа данных первоначально должны быть заданы критерии, по которым производится извлечение данных.
Для удобства пользователя критерии должны быть описаны на приближенном к человеческому языке, который при этом должен сделать их машинопонимаемыми. Для достижения последнего подсистеме управления знаниями необходимо обеспечить большую структурированность контента отобранных по каталогу ЕСЭДО РК ЭД. Этот процесс идет в четыре этапа:
" Использование автоматически созданных таксономий;
" Категоризация контента;
" Презентация и доставка контента;
" Мониторинг и поддержка структуры категоризации.
В подсистеме управления знаниями на базе ПО Verity автоматическая разработка таксономий достигается за счет средства создания тематических карт, которое позволяет идентифицировать основные темы и концепции контента .
Категоризация контента осуществляется ПО как на основе деловых правил, так и на основе идентификации тем и определения иерархической организации тем.
Стратегия презентации закладывает фундамент для навигации по структуре классификации, что вместе с удобной для пользователя доставкой контента позволяет пользователю понять контекст информации без загрузки ЭД в процессе человеко - машинного диалога по извлечению данных из ЭД.
Поддержка актуальности контента осуществляется через мониторинг и поддержку процесса анализа контента, что является необходимым условием учета изменений приоритетов управления, технологий, языка, знаний в условиях постоянно укорачивающихся жизненных циклов документов.
Собственно извлечение данных осуществляется интеллектуальными агентами, представляющими собой специально написанное для конкретной предметной области ПО, обрабатывающее контент ЭД по таксономиям.
Для решения задачи интеллектуального анализа данных подсистема управления знаниями обладает следующими функциональными возможностями:
1. Свободный поиск
" Выявление закономерностей условной логики
" Выявление закономерностей ассоциативной логики
" Выявление трендов и колебаний
2. Прогностическое моделирование
" Предсказание неизвестных значений
" Прогнозирование развития процессов
3. Анализ исключений
4. Выявление отклонений
5. Непосредственное использование обучающих данных. Построение алгоритмов на основе анализа прецедентов (алгоритмы типы Lazy - Learning - метод ближайшего соседа, метод k-того соседа, метод NGE и т. п.)
6. Выявление и использование формализованных закономерностей
" Использование методов кросс - табуляции (кросс - табличная визуализация, байесовские сети)
" Использование методов логической индукции (деревья решений, индукция правил)
" Использование методов вывода уравнений (нейронные сети, ряды динамики, корреляционно - регрессионный анализ, нелинейная регрессия)

2.12. Формализация, обработка и обобщение знаний
БАЗОВЫЙ ПРИНЦИП 15.
Знания - это фундаментальный ресурс, базирующийся на практическом опыте специалистов и на данных, используемых в конкретной организации. Ресурсы знаний различаются в зависимости от отраслей индустрии и приложений, но, как правило, в них входят методики, технологии, процедуры обработки информации, накопившиеся в процессе функционирования предприятия; руководства, документы, новости, сведения о заказчиках и конкурентах, схемы, чертежи и другие данные.

ЕСЭДО РК обеспечивает пользователей открытыми знаниями на основе явной информации в виде ЭД, каталогов ЭД, информационно - справочного фонда и т. п.
Аппаратно - программное обеспечение ЕСЭДО-Н предоставляет пользователю возможность извлечения скрытых знаний, возникающих на основе персонального опыта специалистов, при помощи:
" поддержки специальных процедур переноса компетентности специалиста на аналитика - пользователя;
" поддержка выделения основных понятий и структуры представления информации;
" формализация и преобразование выделенных знаний в ЭД;
" обслуживание знаний - корректировка формализованных данных и знаний (добавление, обновление); "чистка" - удаление устаревшей информации из информационно- справочного фонда.
ЕСЭДО - Н поддерживает пользователя при работе со всем спектром документирования знаний - от хорошо до слабо документированных.
ЕСЭДО - Н обеспечивает поддержку пользователю при работе с предметными областями знаний:
" хорошо структурированными - с четкими определениями, устоявшейся технологией и терминологией;
" среднеструктурированными - с определившейся терминологией, развивающейся технологией, явными взаимосвязями между процессами;
" слабоструктурированными - с размытыми определениями, часто меняющейся структурой, скрытыми взаимосвязями, с большим количеством "белых пятен".
Таким образом, пользователю ЕСЭДО РК предоставляется полный функционал управления знаниями. Ввод ЕСЭДО - Н в эксплуатацию создаст условия для устранения следующих недостатков в работе органов государственного управления:
" большие затраты времени специалистов на поиск необходимой информации;
" использование опыта ведущих и наиболее квалифицированных сотрудников только ими самими;
" захоронение ценных знаний в огромном количестве документов и данных, доступ к которым затруднен;
" повторение дорогостоящих ошибок из-за недостаточной информированности и игнорирования предыдущего опыта.

БАЗОВЫЙ ПРИНЦИП 16.
Управление знаниями (knowledge management, KM) - это совокупность процессов, которые управляют созданием, распространением, обработкой и использованием информации

2.13. Предоставление информации и знаний пользователям
Пользователь, желающий получить информацию и знания из ЕСЭДО РК, должен осуществить поиск со своего рабочего места следующими путями:
" Задать метаданные ЭД в случае, если он знает, в каком либо каких конкретно ЭД находится требуемая ему информация. Данный вид поиска строится по технологии "запрос по образцу". Технология предусматривает задание критериев поиска в качестве образца, с которым сравниваются метаданные всех хранимых ЭД. Если значения метаданных ЭД совпадают с заданными значениями, то ЭД включается в результаты поиска.
" Осуществить полнотекстового поиска, подразумевающего поиск ЭД, в текст или метаданные которого входят заданные слова. Предусмотрены построения полнотекстового поискового запроса: с помощью логических операторов словообразований (фраз) или составление списка отдельных слов. В первом случае в качестве условия полнотекстового поиска пользователь может задать одно или несколько словообразований, построенных с учетом принятых правил. В результатах поиска будут выбраны данные, значение которых совпадает с одним из указанных значений критерия отбора (словообразований). При выборе типа поиска по отдельным словам пользователь в качестве критериев поиска может задать одно или несколько слов, которые встречаются в содержании искомых ЭД. При этом в качестве дополнительных могут быть заданы условия поиска заданного списка слов: "Любое из перечисленных" или "Все перечисленные". При выборе условия "Любое из перечисленных" будут найдены все ЭД, в содержании которых встречается хотя бы одно слово из заданного списка. При выборе условия "Все перечисленные" будут отобраны только те ЭД, в содержании которых есть все слова заданного списка. Кроме того, пользователь может при необходимости задать порядок поиска слов из списка по содержанию ЭД. Для этого в системе предусмотрены режимы поиска: "в любом порядке", "в том же порядке". Режим поиска "в любом порядке" предусматривает поиск слов из заданного списка в порядке их расположения в содержании ЭД. Режим поиска "в том же порядке" предусматривает поиск слов в содержании ЭД в порядке их расположения в заданном списке. Результаты поиска представляют собой список ЭД, соответствующих критериям поиска, отображаемый в табличной форме.
" В полнотекстовом поиске использовать возможности нечеткого поиска (с учетом опечаток, ошибок и т.п.),. автоматического определения кодировок и форматов текстовой информации, многоязычного поиска, логического поиска, с указанием диапазонов и дат, формата файла
" Задать морфологический анализ с использованием словоформ и омонимов
" Использовать семантические сети, в том числе сети с многоуровневой иерархией.
" Применить многоступенчатый комбинированный поиск с экспертным уточнением запроса.
" Осуществить фактографического анализа.
" Употребить поиск по образцу.
" Подключить экстракторы (например, для поиска отпечатков пальцев, лиц и т. д.).
" Использовать фонемный анализ (при распознавании речи в аудио информации).
При этом пользователю предоставляются из найденных ЭД только соответствующие его правам доступа.
Пользователь ЕСЭДО РК, желающий осуществить поиск информации в СЭА ГО и имеющий на это полномочия, делает со своего рабочего места поисковый запрос с указанием на необходимость использования СЭА ГО.. Подсистема автоматизации документооборота и делопроизводства национального уровня передает данный запрос в СЭА ГО, который там и исполняется. Результаты запроса попадают на рабочее место пользователя.
Пользователь ЕСЭДО РК, желающий осуществить поиск информации в других системах НИИ РК, подключенных к ЕСЭДО РК, должен при составлении запроса выбрать из классификатора подключенных систем НИИ РК выбрать искомую систему. При этом запрос должен быть составлен на языке структурированного запроса.
Подсистема автоматизации документооборота и делопроизводства национального уровня передает данный запрос в подключенную к ЕСЭДО РК систему, который там и исполняется. Результаты запроса попадают на рабочее место пользователя ЕСЭДО РК..

2.14. Передача ЭД из НФЭД в СЭА ГО
ЭД хранятся в НФЭД в течение времени, определенного нормативно - правовыми актами для ЭД.
По завершении этого срока ЭД автоматически передаются в СЭА ГО и после подтверждения из СЭА ГО о приеме ЭД удаляются из НФЭД.
Поскольку все ЭД, обращающиеся в ЕСЭДО и СЭА ГО, выполнены в КМПКФ, процесс передачи ЭД из НФЭД в СЭА ГО осуществляется путем обработки соответствующих тэгов ЭД, отражающих этапы жизненного цикла ЭД.
.
БАЗОВЫЙ ПРИНЦИП 17.
ЭД, находящиеся на архивном хранении в СЭА ГО, переклассифицируются согласно происходящим в ЕСЭДО изменениям классификаторов.

Согласно этого принципа, ЭД передается из ЕСЭДО в СЭА ГО согласно действующим на момент передачи классификаторам. При этом пользователь ЕСЭДО имеет возможность при необходимости поиска архивных ЭД применить действующие в ЕСЭДО классификаторы.
Таким образом, согласование работы ЕСЭДО и СЭА ГО основано на регулярном (ориентировочно один раз в сутки) согласовании классификаторов и КМПКФ. Пользователь ЕСЭДО имеет возможность составить запрос к СЭА ГО с использованием как атрибутивного, так и полнотекстового поиска.
Указанный запрос поступает из подсистемы ЕСЭДО-Н через Транспортную среду в СЭА ГО, обрабатывается там и результат обработки по тому же пути поступает на АРМ пользователя ЕСЭДО.

2.15. Поддержка принятия решений высших должностных лиц государственного управления
Пользователь с правами высшего должностного лица имеет доступ к подсистеме поддержки принятия решений.
Подсистема поддержки принятия решений (далее ППР) основана на использовании структурированных данных Хранилища, заполняемого как интеллектуальными агентами из НФЭД, так и иными способами (согласно реализованным на основании поставленных задач уполномоченными на то органами ПО, вручную и т. д.).
В подсистеме ППР настраиваются согласно поставленных задач в рамках ее функциональности деловые процессы, результаты которых представляются в информационной системе руководителя и отображаются на программно - аппаратном обеспечении ситуационной комнаты.
Согласно имеющихся данных подсистема ППР предоставляет пользователю OLTP - функции.
При этом в подсистеме ППР имеется библиотека показателей деятельности, которые могут быть легко видоизменены и дополнены с учетом конкретных требований той или иной организации.
Фактические данные по показателям деятельности приобретают истинное значение лишь тогда, когда эти последние тесно увязаны с поставленными перед организацией целями. "Администратор Деятельности организации" подсистемы ППР оснащен средствами, позволяющими задавать любые цели с учетом специфики деятельности организации. При этом можно задать максимально допустимые верхние и нижние значения для каждого показателя деятельности, а цветовые сигналы на экране дисплея сообщат, когда показатели будут находиться в опасной близости от заданных пределов, благодаря чему имеется возможность своевременно, еще до того, как ситуация выйдет из-под контроля, предпринять все необходимые шаги. При этом следует отметить, что предельные значения могут быть заданы для любого интересующего периода, а затем легко откорректированы. Также имеется возможность узнать не только фактическое значение интересующего показателя, но и получить данные о его максимально и минимально допустимых значениях, а также об ответственном исполнителе.
Плановые показатели, т.е. формируемые цели нуждаются в корректировке с учетом постоянно меняющихся условий внутри и вне организации. Поэтому пакет "Администратор Деятельности организации" имеет средства, которые позволяют при изменившихся обстоятельствах, ввести в систему не только новый верхний и нижний предел показателя, но и его новое плановое значение. По любому показателю деятельности можно задать тренды плановых значений, для чего используются формулы, посредством которых рассчитываются прогнозы относительно развития организации в будущем.
В основном сеансе используется скелетная диаграмма "Ишикава", которая подходит для показа иерархических отношений между показателями деятельности. Подобная схема представления информации удобна в обращении и даже при беглом взгляде дает исчерпывающую информацию о причинно-следственных связях отдельно взятого показателя. Благодаря использованию цветовой кодировки критических значений сразу же выделяются "болевые" точки, где требуется аналитический просмотр для получения более подробной информации.
Фактические данные по отдельно взятым показателям представлены в подсеансах детального просмотра. Также отображаются текущие значения связанных с ними других индикаторов, агрегирование данных по которым и явилось причиной подобного поведения упомянутого показателя. Здесь же приводятся его плановые значения, а также верхний и нижний допустимые пределы.
Модуль Intelligence Suite позволяет моделировать и проигрывать ситуации при изменении имеющихся данных, предоставляя пользователю функции OLAP.
На первоначальном этапе создания национального уровня ЕСЭДО РК функциональность подсистемы ППР позволит сформировать потребности пользователя, но на последующих этапах потребуется массовая разработка алгоритмов и программ интеллектуальных агентов, решающих новые задачи за пределами начального функционала. Существующая система организации связи ПО ЕСЭДО-Н с ПО третьих фирм позволяет осуществить данные стыковки с наименьшими затратами времени и усилий.

2.16. Поддержка открытого централизованного WEB - сайта электронного документооборота
ПО Documentum обеспечивает функционирование подсистемы массового доступа к открытым ЭД и знаниям на следующей стратегии - обеспечить единое пространство для:
" Создания элементов контента, доступа к нему, редактирования и маршрутизации
" Предоставлять на портал достоверный контент, гарантируя надежность информации
" Реализовать возможность персонализации контента (сохранение по контексту)
" Автоматически удалять устаревший контент, поддерживая актуальность информации
Ниже приведена лестница интеграции, где боль
Bazilio
Гость




[5100] Пн Окт 13, 2003 21:14

Согласно тому, что выше, классификаторы есть и "структурируют ЭД", плюс ясно изложено: "группировки МОГУТ - по любому классифицирующему признаку".

Впечатление-1: ВСЕ прописано, учтено, вероятно, проверено практикой, ни вам, ни мне не видно истоков проблемы создания и ведения классификаторов (мы о тех, что для чиновников):
>> АРМ документоведа разложит метаданные по ВСЕМ классификаторам – это ему не трудно!

Yes, good. На фронте ЭД все Ok! Одна загадка: откуда постановка: "Как использовать ЧИТАТЕЛЯ для классификации..

Нет, нельзя на это ответить, не видя ЦЕЛИ, не видя перед собой Пользователя классификации (я только усек, что это не чиновник)

>> Отвечаю – этот подход УТВЕРЖДЕН, слава Богу. Зачем вам докапываться до процедур?

ды "тайны парижа" не интересуют. Волнует другое, все "утверждено", значит, кто-то должен был "как-то представить и расписать": кто, для кого и в каком месте выполняет оную классификацию.. (ну или на чьи конкретно плечи эта функция утверждена документами?)

Впечатление-2: Если мы с вами согласны, что для ЭД "все определено + практикой поверено" - тогда вопрос опять и снова к вам: а сами-то вы - где конкретно видите источник проблемы? Более того : кто/что мешает ТЕМ ЖЕ САМЫМ изготовленным (для чиновника) КЛАССИФИКАТОРАМ "эффективно работать" в обратную сторону - для тех-самых (сетевых) читателей.. а мож, и писателей?

Понимаю, вы хотите дополнительно нарастить ЭД знаниями сети (очевидно, для сетевых пользователей KZ)? - ну.. тогда скажем, конкретно для этого возьмите классификатор у любой из сетевых служб.. (Они не годятся ни для чего другого, кроме сети, но для сетевого читателя прекрасно сойдут - ведь у всех же работают). Ну, в крайнем возьмите из Google простейшую dmoz-онтологию (им же хватает!) да переведите на казахский. {ps: то, что у них всегда вверху} вида:

> Kids and Teens > School Time > Social Studies > World Cultures > .....

Кого и куда время поджимает? (тем более вы не так давно сами писали, что "время для обсуждений есть")

Нет, не ясно мне, зачем: "Как использовать ЧИТАТЕЛЯ для классификации.. Для ЭД - этого нам не нужно, для сетевого читателя - ды зачем вам на шею такие приключения? А.. понимаю.. мож, чистого искусства ради - той самой "глобальной таксономии?" - но вот тут чур-чур, вот тогда увольте.. [в скобках: Вы точно в курсе, сколько человеко-лет ушло на CYC? и почти все под хвост - но не будем..]
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5136] Пт Окт 24, 2003 04:24

Sorry за задержку - причина более чем прозаичная: неотложные дела перед отъездом из Астаны, потом болел. В общем, дела мирские...
Теперь по существу вопросов Bazilio: "значит, кто-то должен был "как-то представить и расписать": кто, для кого и в каком месте выполняет оную классификацию". Это записано в определнии КМПКФ - принципиально любая обращающаяся в РК система классификации, но при наличии соответствующего классификатора на национальном уровне. Кто-то - персонал ЕСЭДО - Н, который будет набираться из числа опытных экспертов для поддержки системы, НСИ, каталога.
"а сами-то вы - где конкретно видите источник проблемы?" - поскольку реалии создания ЕСЭДО-Н таковы, что в этом году автоматизированного АРМ документоведа не будет, то запролнение метаданных ЭД будет проводится вручную по нескольким параметрам. Это приведет к тому, что данные ЭД нельзя будет найти по метаданным классификаторов. Усеченный запуск системы породит множество проблем - опять будем иметь ситуацию свалки - подобную Инету. Отсюда желание решить задачу методами ТРИЗ, за счет читателя, за счет сторонних ресурсов.
Получится, хорошо, не получится, другой подход найдем
"мож, чистого искусства ради - той самой "глобальной таксономии?" - но вот тут чур-чур, вот тогда увольте" - зайдите на страничку моего друга Александра Костинского "Седьмой континент" www.svoboda.org - 22/10/03 хорошая передача была про электронные словари! А оттуда ассоциативно можно и про глобальную таксономию поразмыслить... От их подхода отталкиваясь, можно дальше пойти. А возможный результат? Подразумеваю, что хорошо, если документ сразу по всем классификаторам разложить, однако значительно лучше, если при поиске по заданному классификатору предоставляется возможность использовать и другой - как в библиотеке: из систематического вы идете в алфавитный.
Или вы считаете, что это излишняя роскошь? Тогда аргументируйте...
Chief constructor
Новичок

Зарегистрирован: 24.02.2003
Сообщения: 16

[5138] Пт Окт 24, 2003 14:22
P.S. - автоматизированное АРМ
Выше было допущено мной тавое вот выражение. Прочитал и подумал - вот уж действительно Бедлам... это надо глубоко в теме быть, чтобы наши нюансы понимать Smile
В ТЗ на вторую очередь ЕСЭДО явно указывается следующее:
9.3. Управление ЭД (электронный документооборот)
9.3.1. Разработка, согласование и утверждение ЭД
1. Создание проектов ЭД, ЭД с возможностью использованию хранящихся системы шаблонов.
2. Возможность автоматического формирования проектов ЭД, ЭД, состоящего из различных частей с отслеживанием актуальности каждой части (виртуальные ЭД).
3. Маршрутизация вновь созданных проектов ЭД, ЭД для их согласования и утверждения, согласно полномочиям конкретного пользователя системы.
4. Формирование метаданных ЭД, согласно КМПКФ.

9.3.2. Обработка внутренних ЭД организации
5. Создание задания на разработку внутреннего ЭД по инициативе пользователей, имеющих на это полномочия.
6. Создание новых ЭД согласно заданию на разработку ЭД на основе шаблонов, хранящихся в системе.
7. Возможность автоматического формирования ЭД, состоящего из различных частей с отслеживанием актуальности каждой части (виртуальные ЭД);
8. Маршрутизация вновь созданных внутренних ЭД для их согласования и утверждения, согласно полномочиям конкретного пользователя системы.
9. Утверждение внутренних ЭД посредством механизма ЭЦП.
10. Регистрация утвержденных внутренних ЭД в ЕСЭДО-В организации.
11. Хранение зарегистрированных внутренних ЭД в ЕСЭДО – В организации и автоматическое информирование заинтересованных пользователей системы о поступлении новых ЭД..

9.3.3. Обработка исходящих ЭД
1. Формирование и ведение списков рассылки организации.
2. Назначение списков рассылки исходящим ЭД, в том числе и индивидуальных списков рассылки.
3. Организация процесса согласования, визирования, утверждения и/или подписания исходящих ЭД у соответствующих сотрудников организации (руководства организации, руководителей структурного подразделения организации, имеющих право подписи) посредством механизма ЭЦП.
4. Регистрация утвержденных исходящих ЭД.
5. Автоматическая рассылка ЭД.

9.3.4. Контроль исполнения ЭД
1. Прозрачный контроль за прохождением ЭД инициатором процесса обработки ЭД (руководителем организации или структурного подразделения организации).
2. Контроль своевременного исполнения содержащих поручения ЭД.
3. Возможность постановки отдельных частей ЭД на контроль.
4. Корректировка сроков исполнения ЭД, стоящих на контроле, с указанием ЭД, являющимся основанием для корректировки данных сроков.
5. Формирование предупредительных сводок по исполнению ЭД.
6. Формирование сводок просроченных и неисполненных ЭД.
7. Получение отчетов по исполнению ЭД по запросам пользователей..

9.3.5. Общие функции обработки ЭД в ЕСЭДО РК
8. Присвоение метаданных согласно системе классификации на основе КМПКФ.
9. Автоматический учет всех создаваемых ЭД.
10. Сохранение внутренних, исходящих и входящих ЭД в ЕСЭДО-В организации.
11. Передача ЭД через Транспортную Среду ЕСЭДО РК
12. Сохранение исходящих и входящих ЭД в Национальном фонде ЭД.
13. Маршрутизация ЭД на всех уровнях его обработки без ограничения числа уровней (начиная с руководства организации и заканчивая конкретными исполнителями).
14. Автоматическая поддержка жизненного цикла ЭД с изменением прав доступа к ЭД по мере прохождения им отдельных этапов обработки.
15. Поддержка обработки составных ЭД, состоящих из различных частей, хранящихся в различных форматах и имеющих разные права доступа, с возможностью сборки окончательного ЭД в произвольный момент времени (поддержка виртуальных ЭД).
16. Возможность работы с содержащими видео и аудио информацию ЭД (аннотирование, просмотр, просмотр без запуска авторского приложения, перевод ЭД в другие форматы).
17. Классификация ЭД с использованием метаданных, получаемых в результате автоматической обработки содержания ЭД с использованием полнотекстового (в том числе и нечеткого), семантического, морфологического, фактографического, многоязычного, логического поиска, ручного ввода, а затем с окончательной корректировкой метаданных при необходимости с экспертным уточнением запросов поиска
18. Возможность поиска ЭД как по их содержанию, так и по метаданным.
19. Определение связей между ЭД."
Так вот, в этом году требования п. 17 раздела 9.3.5 ТЗ на 2 очередь выполнены не будут АРМдокументоведа АВТОМАТИЗИРОВАННО реквизиты проставлять не будет, а делать это будет ВРУЧНУЮ документовед, заполняя 5-6 полей.Такая вот тавтология получается - АРМ есть, но без СУЗ оно автоматизированно проставлять метаданные не может. Это вопросы не ко мне, к заказчику, который СУЗ из этого года выбросил...
В последнее время часто вспоминаю историю про С. П. Королева, который написал на блокнотном листочке "Луна твердая. Королев" инструктору ЦК. "Метаданные по заданным классификаторам положить можно! Smile"
Shanyar
Гость




[5572] Вт Мар 16, 2004 14:53

Hello,
An internet-draft by the name of "The web of physical objects Uniform Resource Identifier" has been submitted by me and can be found at the following link.
http://www.ietf.org/internet-drafts/draft-shariyar-wop-uri-00.txt
Beta - tester
Гость




[5573] Вт Мар 16, 2004 15:05
Испытания
1 Объект испытаний
1.1 Полное наименование проекта
Полное наименование разработки – программное обеспечение Единой системы электронного документооборота для государственных органов Республики Казахстан, вторая очередь, национальный уровень.
Условное обозначение - ЕСЭДО-Н.
1.2 Комплектность испытательной системы
В испытательную систему входят:
• Сервер национального центра (НЦ) ЕСЭДО с установленным системным и прикладным программным обеспечением
• Сервера ведомственной системы ЕСЭДО-В-1.1
o Министерство Сельского Хозяйства
o Министерство Экономики и Бюджетного Планирования
• Сервера портала НЦ ЕСЭДО
o Внутренний (Intranet)
o Внешний (Internet)
• АРМы ведомственной системы ЕСЭДО-В-1.1
o Министерство Сельского Хозяйства
o Министерство Экономики и Бюджетного Планирования
• АРМ администратора НЦ ЕСЭДО
• Каналы связи
1.3 Область применения
ЕСЭДО РК является автоматизированной информационно-справочной системой, предназначенной для автоматизации технологических процессов подготовки, регистрации, структурирования, маршрутизации, хранения, архивации, поиска и обработки электронных документов (далее ЭД), контроля их исполнения, авторизации доступа к ним, выпуска и рассылки ЭД. Данная функциональность предназначена для системы государственных органов Республики Казахстан.
ЕСЭДО РК второй очереди (ЕСЭДО-Н) представляет собой межведомственную (национальную) информационно-справочную систему для обмена электронными документами между государственными органами. В системе производится обработка создаваемых и используемых в делопроизводстве государственных органов Республики Казахстан ЭД.
2 Цель испытаний
Цель испытаний – показать на опытных примерах соответствие функциональных возможностей, реализованных в системе, требованиям, определенным в документе «Техническое задание на разработку ЕСЭДО РК. Вторая очередь. НИОКР».
3 Общие положения
Испытания проводятся на основании вышеуказанного Технического Задания и «Технической спецификации на разработку второй очереди ЕСЭДО РК с учетом проведенных научно-исследовательских работ», определяющего детальные требования к подсистемам национального уровня ЕСЭДО РК.
Испытания проводятся в г.Астана, на распределенном испытательном стенде, который состоит из следующих частей:
• Сервер НЦ ЕСЭДО, расположенный в ТОО «СофтИнженер»
• Ведомственная система ЕСЭДО-В, установленная в Министерстве Сельского Хозяйства
• Ведомственная система ЕСЭДО-В, установленная в Министерстве Экономики и Бюджетного Планирования
Испытания проводят в течение пяти рабочих дней.
В испытании принимают участие следующие организации:
1. Агентство Информатизации и Связи
2. ЗАО НИТ
3. Министерство экономики и бюджетного планирования РК
4. Министерство сельского хозяйства Республики Казахстан

В испытании также принимает участие рабочая группа ЕСЭДО РК и представители ведомств – объектов пилотной зоны проекта.
4 Объем испытаний
4.1 Этапы испытаний
Программа предварительных испытаний включает в себя автономные испытания подсистем (сервисов), а также комплексные испытания системы в целом.
Автономное тестирование функций системы осуществляется двумя способами:
• Через ведомственные системы, подключенные программным способом через модуль подключения к сервисам, и вызывающим функции сервисов через специфицированный программный интерфейс;
• Через пользовательский интерфейс портала НЦ.
Автономное тестирование заключается в выполнении прецедентов – автономных элементарных действий, которые с прикладной точки зрения соответствуют пользовательской операции, и включают в себя выполнение одной или нескольких функций сервисов системы.
Комплексные испытания включает в себя выполнение нескольких ролевых сценариев взаимодействия.
4.2 Последовательность проведения испытаний
Испытания проводятся в следующей последовательности:
1. Испытания функций сервисов НЦ ЕСЭДО через работу подключенных к ним ведомственных систем
2. Испытания работы сервисов НЦ ЕСЭДО через портал НЦ ЕСЭДО
3. Выполнение ролевых сценариев комплексного тестирования:
3.1. Создание и ведение общего справочника
3.2. Регистрация типа документа и ведение документов
3.3. Согласование проекта документа
3.4. Контроль исполнительской дисциплины
3.5. Администрирование разделения прав доступа
4.3 Требования по испытаниям программных средств
Подготовленные и согласованные тесты (контрольные примеры) на этапе автономных испытаний должны обеспечить:
1) Соответствие системы ТЗ ЕСЭДО РК и «Технической спецификации»
2) Полную проверку функций и процедур по перечню, согласованному с заказчиком;
3) Комплектность системы
Автономные и комплексные испытания должны проверять степень выполнения требований функционального назначения системы. Система должна обеспечивать выполнение следующих функций:
1. Ведение общих справочников (перечень государственных органов, территориальных делений, руководящего состава ГО и т.д.);
2. Ведение специальных справочников и классификаторов ЕСЭДО (номенклатура дел, атрибуты ЭД, уровни секретности, статусы ЭД и т.д.);
3. Диспетчеризация и протоколирование движения ЭД;
4. Обработка входящей/исходящей очередей ЭД;
5. Управление приоритетами обработки очередей;
6. Регистрация движения документов в журнале;
7. Анализ и сохранение атрибутов ЭД в картотеке НЦ ЕСЭДО;
8. Сохранение содержания документов в хранилище в результате анализа атрибутов ЭД;
9. Регистрация ошибок и возврат ЭД отправителю в случае определенных статусов ошибок;
10. Контроль достоверности ЭЦП отправителя/получателя;
11. Обработка запросов к картотеке ЭД;
12. Удаление из хранилища неактуальных ЭД;
13. Формирование отчетности;
14. Рассылка уведомлений получателям ЭД;
15. Ведение профиля участника ЕСЭДО-Н;
16. Поддержка единых стандартов документов и сообщений ЕСЭДО-Н;
17. Контроль исполнительской деятельности на государственном уровне;
18. Ведение единой, централизованной БД ЕСЭДО-Н;
19. Отслеживание связей между документами;
20. Поддержка целостности, отсутствие избыточности и непротиворечивости информации;
21. Мониторинг передачи данных;
22. Централизованная защита документов и данных о них.
4.4 Перечень работ, проводимых после завершения испытаний
По завершению испытаний анализируются результаты и выполняются следующие работы:
1. Составление отчета и акта по результатам испытаний.
2. Изменение технического задания (при необходимости).
3. Доработка программного обеспечения (при необходимости).
4. Доработка документов, предъявляемых к испытаниям (при необходимости).
Отчет отражает степень соответствия системы Техническому заданию и Технической спецификации, в отчете указывается о необходимости изменения технического задания (если требуется), о доработке прикладного программного обеспечения (если требуется), о доработке документов, предъявляемых к испытаниям (если требуется).
По результатам испытаний составляется акт, в котором отражаются основные выводы отчета.
5 Условия и порядок проведения испытаний
5.1 Условия проведения испытаний
Испытания проводятся в следующих условиях:
1. На сервере НЦ ЕСЭДО установлено следующее системное и прикладное программное обеспечение
a. ОС AIX 5.1
b. СУБД Oracle Server 9i
i. Oracle Workflow
c. Oracle9i Internet Application Server
i. Oracle Content Manager SDK
ii. Oracle Reports Services
iii. Инфраструктура Oracle iAS
d. ПО сервисов НЦ ЕСЭДО
2. На сервере портала НЦ ЕСЭДО установлено следующее системное и программное обеспечение:
a. Oracle9i Internet Application Server
i. Oracle Portal
3. На сервере СГДС установлено ПО СГДС (почтовый сервер либо MQ-Series)
4. На серверы ЕСЭДО-В в ведомствах установлено следующее системное и прикладное обеспечение:
a. ОС AIX 5.1
b. Lotus Domino Server
5. Сервер СГДС (почтовый сервер либо MQ-Series)
6. На АРМы ЕСЭДО-В в ведомствах установлено следующее системное и прикладное обеспечение:
a. ОС Windows 98/2000/XP
b. Клиентский модуль сервисов НЦ ЕСЭДО
c. Lotus Notes
d. Клиентское ПО ЕСЭДО-В
7. Между сервером НЦ ЕСЭДО и ведомственными системами работает выделенный канал связи с пропускной способностью не ниже 128 Кбит/сек.
5.1.1 Структура испытательного стенда

Функционал сервисов НЦ ЕСЭДО размещен на трех связанных серверах (на этапе испытаний объединенные в один):
• Хранилище (СУБД Oracle)
• Сервер приложений (Oracle iAS)
• Прикладной функционал сервисов на основе Oracle CM SDK
К этому функционалу идет обращение со стороны портала, а также сервера СГДС, принимающее сообщения от приложений участников ЕСЭДО (на схеме показаны два ведомства-участника – МСХ и МЭБП).
НЦ имеет следующие АРМы:
• Технолог НСИ (нормативно-справочной информации)
• Технолог маршрутизации
• Администратор НЦ ЕСЭДО
1.1.1.1 Сторона ведомств-участников ЕСЭДО
На стороне участников-ведомств размещены:
• Сервер Lotus Domino
• Сервер СГДС для связи с функционалом сервисов НЦ ЕСЭДО
• АРМы сотрудников ведомств-участников (Lotus Notes)
Имеющиеся ограничения приведены в п.5.3. Необходимое оборудование для испытательного стенда – см. п.6.
1.2 Условия начала и завершения отдельных этапов испытаний
Условия начала этапа автономного тестирования совпадают с условиями проведения испытаний (раздел 5.1).
Условия завершения этапа автономного тестирования:
• Успешно выполнены действия, предусмотренные «Методикой автономных испытаний функций сервисов ЕСЭДО через ведомственные системы» (Приложение А).
Условия начала этапа комплексного тестирования совпадают с условиями проведения испытаний (раздел 5.1).
Условия завершения этапа комплексного тестирования:
• Успешно выполнены действия, предусмотренные «Методикой комплексных испытаний на основе ролевых сценариев взаимодействия» (Приложение Б).
1.3 Имеющиеся ограничения в условиях проведения испытаний
При проведении испытаний существуют следующие допущения и ограничения:
1. В качестве СГДС используется разработанная для испытаний почтовая система по протоколам POP3 и SMTP, имитирующая функции СГДС.Имитация СГДС возможна также на базе продуктов IBM MQ-Series.
2. В качестве удостоверяющего центра и средств криптографии используется разработанный для испытаний криптографический модуль, использующий алгоритмы RSA (стандартизированные W3C), входящие в состав Microsoft крипто-API и J2EE.
3. Портал не делится на внешний и внутренний по причине отсутствия необходимого дополнительного выделенного сервера.
1.4 Требования к техническому обслуживанию системы
В период испытаний требуется обеспечить нормальную и бесперебойную работу всего аппаратно-программного комплекса, а также бесперебойную работу каналов связи. Специальных требований к техническому обслуживанию системы не требуется.
1.5 Меры, обеспечивающие безопасность и безаварийность проведения испытаний
Меры, обеспечивающие безопасность и безаварийность проведения испытаний В период испытаний нужно соблюдать обычные меры безопасности, соблюдаемые при работе с компьютерами и периферийными устройствами задействованными в испытаниях, указанные в инструкциях по эксплуатации этих устройств. Специальных мер обеспечения безопасности и безаварийности испытаний системы разрабатывать не требуется.
1.6 Порядок взаимодействия организаций, участвующих в испытаниях
1. ТОО СофтИнженер (Исполнитель)
Исполнитель обеспечивает необходимую техническую подготовку, установку, настройку испытываемой системы на базе технических средств предоставленных ЗАО НИТ.
Исполнитель проверяет предоставленные технические средства и каналы связи на предмет их пригодности для проведения испытаний совместно с техническими специалистами ЗАО НИТ.
2. Агентство Информатизации и Связи (АИС)
Ответственное и уполномоченное лицо от АИС присутствует при проведении испытаний, испытывает систему согласно подготовленных сценариев и контрольных примеров.
Также ответственные и уполномоченные лица от АИС и ЗАО НИТ совместно решают организационные вопросы проведения испытаний.
3. ЗАО Национальные Информационные Технологии (ЗАО НИТ)
ЗАО НИТ организовывает проведение испытаний, обеспечивает помещения, установку серверов, рабочих станций и других технических средств указанных в разделе 6 «Материально-техническое обеспечение испытаний».
Также ЗАО НИТ обеспечивает предоставление необходимые для проведения испытаний каналы связи.
Ответственные и уполномоченные лица от АИС присутствуют и осуществляют испытания системы совместно с Исполнителем согласно подготовленных сценариев и контрольных примеров.
4. Министерство экономики и бюджетного планирования РК (МЭБП)
Ответственное и уполномоченное лицо(лица) от МЭБП присутствуют на испытаниях и испытывают систему согласно подготовленных сценариев и контрольных примеров.
5. Министерство сельского хозяйства Республики Казахстан (МСХ)
Ответственное и уполномоченное лицо(лица) от МСХ присутствуют на испытаниях и испытывают систему согласно подготовленных сценариев и контрольных примеров.
1.7 Требования к персоналу, проводящему испытания, и порядок его допуска к испытаниям
Персонал участвующий в испытаниях должен обладать навыками работы с персональными компьютерами, операционной системой Windows, MS Office, почтовыми клиентами и работой в веб-браузере.
Администраторы системы, баз данных и базового ПО применяющегося в системе должны обладать соответствующей квалификацией для обеспечения администрирования и настройки системы на период ее испытаний.
Технологи системы должны обладать знаниями бизнес-процессов документооборота , автоматизируемых системой.
1.8 Порядок испытаний
Испытания проводятся в следующем порядке:
1) Проверка комплектности испытательного стенда в соответствии с п.5.1.1 и 5.3.
2) Проверка соответствия функциональным требованиям согласно разделу 5.9 и методике автономных испытаний в Приложении А (автономное тестирование функций сервисов).
3) Проверка степени выполнения требований функционального назначения системы согласно разделу 4.3 и методике комплексного тестирования в Приложении Б (тестирование по ролевым сценариям).
1.9 Соответствие функциональным требованиям
1.9.1 Соответствия функциональным требованиям функций сервисов
Система должна удовлетворять функциональным требованиям, приведенным в списке общих функций в п.4.3. Ниже по каждой функции раскрыты виды и способы испытаний с перечислением требований к функциям отдельных сервисов.
1.9.1.1 Ведение общих справочников
Функция проверяется на соответствие требованиям функций сервиса ведения справочников и классификаторов, приведенным в пп. 5.9.2.1, 5.9.2.2, 5.9.2.5, 5.9.2.6. Испытания проводятся в соответствии с методикой автономных испытаний по пп. 8.3.1, 8.3.2, 8.3.5, а также Сценарием 1 методики комплексных испытаний (п. 9.5.1).
1.9.1.2 Ведение специальных справочников и классификаторов ЕСЭДО
Функция проверяется на соответствие требованиям функций сервиса администрирования, приведенным в пп. 5.9.5.1, 5.9.5.3, а также функциям сервиса ведения справочников и классификаторов, приведенным в пп. 5.9.2.1- 5.9.2.6. Испытания проводятся в соответствии с методикой автономных испытаний по пп. 8.3.1 - 8.3.5.
1.9.1.3 Диспетчеризация и протоколирование движения ЭД
Функция проверяется на соответствие требованиям функций сервиса маршрутизации, приведенных в п. 5.9.4. Испытания проводятся в соответствии со Сценарием 3 методики комплексных испытаний (п. 9.5.3).
1.9.1.4 Обработка входящей/исходящей очередей ЭД
Функция реализуется теми же механизмами, что и для п.5.9.1.3, проверка на соответствие функциональным требованиям осуществляется тем же способом.
1.9.1.5 Управление приоритетами обработки очередей
Данная функция тестируется в рамках испытаний СГДС, являющейся внешней подсистемой по отношению к рассматриваемой в данной программе системе.
1.9.1.6 Регистрация движения документов в журнале
Функциональные требования к сервису маршрутизации, касающиеся удовлетворения данной функции, перечислены в пп. 5.9.4. Функциональные требования к сервису ведения документов приведены в пп. 5.9.3.3 (функции работы с версионными типами документов).
1.9.1.7 Анализ и сохранение атрибутов ЭД в картотеке НЦ ЕСЭДО
Функциональные требования к сервису ведения документов приведены в пп. 5.9.3.1 - 5.9.3.4. Испытания проводятся в соответствии Испытания проводятся в соответствии с методикой автономных испытаний по пп. 8.4.1, 8.4.2, а также со Сценарием 2 методики комплексных испытаний (п. 9.5.2).
1.9.1.8 Сохранение содержания документов в хранилище в результате анализа атрибутов ЭД
Проверяются функциональные требования к сервису ведения документов, приведенные в п. 5.9.3.3. испытания проводятся в соответствии с пп. 8.4.3 методики автономных испытаний.
1.9.1.9 Регистрация ошибок и возврат ЭД отправителю в случае определенных статусов ошибок
Данное функциональное требование проверяется на всех этапах испытаний, как автономных, так и комплексных.
1.9.1.10 Контроль достоверности ЭЦП отправителя/получателя
Данное функциональное требование проверяется на всех этапах испытаний через ведомственные системы, как автономных, так и комплексных.
1.9.1.11 Обработка запросов к картотеке ЭД
Проверяются функциональные требования к сервису ведения документов, приведенные в п. 5.9.3.4.
1.9.1.12 Удаление из хранилища неактуальных ЭД
Проверяются функциональные требования к сервису ведения документов, приведенные в п. 5.9.3.3 (удаление документов). Испытания проводятся в соответствии с п. 8.4.3.3 методики автономных испытаний.
1.9.1.13 Формирование отчетности
Проверяются функциональные требования к сервису создания отчетов, приведенные в п. 5.9.6. Испытания проводятся в соответствии со Сценарием 4 методики комплексных испытаний (п. 9.5.4).
1.9.1.14 Рассылка уведомлений получателям ЭД
Проверяются функциональные требования к сервису маршрутизации, приведенные в п. 5.9.4.2, а также к сервису администрирования в п. 5.9.5.4. Испытания проводятся в соответствии со Сценарием 2 и 3 методики комплексных испытаний (пп. 9.5.2 и 9.5.3.).
1.9.1.15 Ведение профиля участника ЕСЭДО-Н
Проверяются функциональные требования к сервису администрирования, приведенные в п. 5.9.5.1.
1.9.1.16 Поддержка единых стандартов документов и сообщений ЕСЭДО-Н
Проверяются на всех этапах испытаний, в ходе контроля за сообщениями, поступающими из/в НЦ ЕСЭДО, а также корректности их автоматической обработки ведомственными системами.
1.9.1.17 Контроль исполнительской деятельности на государственном уровне
Проверяются функциональные требования к сервису маршрутизации, приведенные в п. 5.9.4.2, а также к сервису отчетов (п. 5.9.6). Требования проверяются согласно Сценарию 3 (п. 9.5.3) и Сценарию 4 (п. 9.5.4) методики комплексных испытаний.
1.9.1.18 Ведение единой, централизованной БД ЕСЭДО-Н
Проверяется на всех этапах испытаний: НЦ имеет единую БД, на основе которой работают сервисы.
1.9.1.19 Отслеживание связей между документами
Проверяются функциональные требования к сервису ведения документов, приведенные в п. 5.9.3.3.
1.9.1.20 Поддержка целостности, отсутствие избыточности и непротиворечивости информации
Данное требования проверяется проверкой функциональных требований к сервису ведения документов, приведенные в п. 5.9.3.3.
1.9.1.21 Мониторинг передачи данных
Требование предполагает контроль за сообщениями из/в НЦ ЕСЭДО. Проверяется на всех этапах испытаний контролем за отправляемыми/принимаемыми сообщениями из ведомственных систем (ЕСЭДО-В), а также средствами мониторинга СГДС.
1.9.1.22 Централизованная защита документов и данных о них.
Проверяются функциональные требования к сервису администрирования (п. 5.9.5.3). Требования проверяются на всех этапах тестирования, в части работ, касающихся назначения прав доступа.
1.9.2 Сервис ведения справочников и классификаторов
1.9.2.1 Работа со справочниками
Сервис должен обеспечивать выполнение следующих функций работы со справочниками:
• Создание нового справочника
• Изменение существующего справочника
• Удаление существующего справочника
• Извлечение данных существующего справочника
1.9.2.2 Работа с атрибутами справочника
Сервис должен обеспечивать выполнение следующих функций работы с атрибутами справочника:
• Создание нового атрибута в справочнике
• Изменение существующего атрибута
• Удаление существующего атрибута
1.9.2.3 Работа с классификаторами
Сервис должен обеспечивать выполнение следующих функций работы с классификаторами:
• Создание нового классификатора
• Изменение существующего классификатора
• Удаление существующего классификатора
• Извлечение данных существующего классификатора
1.9.2.4 Работа с Папками Классификатора:
Сервис должен обеспечивать выполнение следующих функций работы с папками классификатора:
• Создание новой папки
• Изменение существующей папки
• Удаление существующей папки
• Извлечение данных существующей папки
• Привязка разделов к разделу классификатора
• Удаление привязки папок к папке классификатора
1.9.2.5 Работа с элементами справочника
Сервис должен обеспечивать выполнение следующих функций работы с элементами справочника:
• Создания нового элемента
• Изменение существующего элемента
• Удаление существующего элемента
• Привязка элементов к папке классификатора
• Удаление привязки элементов к папке классификатора
• Извлечение элемента для редактирования
• Помещение элемента новой версии
• Отмена извлечения элемента
• Получение списка папок содержащих элемент
• Получение всех версий элемента
• Получение версии элемента по номеру
1.9.2.6 Поисковые функции:
Сервис должен обеспечивать выполнение следующих поисковых функций:
• Поиск элементов в справочниках, разделах и классификаторах
• Поиск справочников
• Поиск классификаторов
• Поиск папок
1.9.3 Сервис ведения документов
1.9.3.1 Работа с типами документов
Сервис должен обеспечивать выполнение следующих функций работы с типами документов:
• Создание нового типа документа
• Изменение существующего типа документа
• Удаление существующего типа документа
• Извлечение данных по типу документа
1.9.3.2 Работа с атрибутами типов документов
Сервис должен обеспечивать выполнение следующих функций работы с атрибутами типов документов:
• Создание нового атрибута в типе документов
• Изменение существующего атрибута
• Удаление существующего атрибута
1.9.3.3 Работа с документами:
Сервис должен обеспечивать выполнение следующих функций работы с документами:
• Создание нового документа
• Изменение существующего документа
• Удаление существующего документа
• Привязка документов к папке классификатора
• Удаление привязки документов к папке классификатора
• Получение списка папок содержащих документ
• Извлечение документа для редактирования
• Помещение документа новой версии
• Отмена извлечения документа
• Получение всех версий документа
• Получение версии документа по номеру
1.9.3.4 Поисковые функции:
Сервис должен обеспечивать выполнение следующих поисковых функций:
• Поиск документов в типах, разделах и классификаторах
• Поиск типов документов
1.9.4 Сервис маршрутизации
1.9.4.1 Работа с маршрутами
Сервис должен обеспечивать выполнение следующих функций работы с маршрутами:
• Настройка шаблонов
• Настройка маршрутов
• Запуск маршрутов
• Отслеживание исполнения маршрутов
1.9.4.2 Работа с заданиями
Сервис должен обеспечивать выполнение следующих функций работы с заданиями:
• Получение задания
• Исполнение задания
1.9.5 Сервис администрирования
1.9.5.1 Работа с профилями участников
Сервис должен обеспечивать выполнение следующих функций работы с профилями участников ЕСЭДО:
• Создание участника
• Изменение свойств участника
• Удаление участника
• Получение полного списка участников
• Регистрация ведомственного приложения
• Изменение свойств ведомственного приложения
• Удаление ведомственного приложения из списка
• Получение списка ведомственных приложений
1.9.5.2 Работа с пользователями и ролями
Сервис должен обеспечивать выполнение следующих функций работы с пользователями и ролями:
• Создание пользователя
• Изменение свойств пользователя
• Удаление пользователя
• Создание роли
• Изменение свойств роли
• Удаление роли
• Добавление пользователя в роль
• Исключение пользователя из роли
• Получение полного списка пользователей
• Получение полного списка ролей
• Получение пользователя
• Получение роли
1.9.5.3 Работа с правами доступа
Сервис должен обеспечивать выполнение следующих функций работы с правами доступа:
• Назначение разрешительных прав доступа
• Назначение запретительных прав доступа
• Удаление прав доступа
• Проверка прав доступа к данному объекту
• Проверка прав доступа данного субъекта
• Проверка прав доступа данного субъекта к данному объекту
1.9.5.4 Работа с подписками
Сервис должен обеспечивать выполнение следующих функций работы с подписками:
• Подписка на события
• Отмена подписки
• Получение полного списка подписок
• Чтение списка подписок по объекту
• Чтение списка подписок по подписчику
• Чтение подписки
• Уведомление о событии
1.9.6 Сервис отчетов
Сервис должен обеспечивать выполнение следующих функций работы с отчетами:
• Создание шаблона отчета
• Изменение шаблона отчета
• Удаление шаблона отчета
• Получение списка отчетов
• Получение отчета по шаблону
1.9.7 Функциональные требования к порталу
Портал должен включать следующие страницы:
1. Главная страница
2. Страница авторизации
3. Просмотр классификаторов для анонимных пользователей
4. Управление классификаторами
5. Просмотр классификаторов
6. Управление типами документов
7. Поиск документов
8. Работа с документами
9. Поиск справочников
10. Управление справочниками
11. Работа с элементами
12. Администрирование со стороны субъектов
13. Администрирование со стороны объектов
14. Страница управления отчетами
15. Подписка на уведомления со стороны объектов
16. Подписка на уведомления со стороны субъектов
17. Маршрутизация: регистрация шаблонов маршрутов
18. Маршрутизация: управление процессами
19. Маршрутизация: исполнение заданий
20. Приемная
1.9.7.1 Главная страница
Главная страница предназначена для входа в систему, а также отображения обшей актуальной информации по порталу. Функции:
• Авторизация
• Доступ через главное меню к следующим страницам:
o Классификаторы
o Добавление документа
o Поиск документов
o Типы документов
o Отчеты
o Справочники
o Управление классификаторами
o Маршрутизация
o Исполнение заданий
o Управление подпиской
o Администрирование
1.9.7.2 Страница авторизации
На странице пользователь указывает логин и пароль.
1.9.7.3 Просмотр классификаторов для анонимных пользователей
На странице возможно выполнение следующих операций:
• Просмотр списка классификаторов
• Просмотр структуры классификатора
• Просмотр содержимого папки
• Просмотр документа
• Просмотр элемента справочника
• Загрузка содержимого документа
1.9.7.4 Управление классификаторами
На странице возможно выполнение следующих операций:
• Просмотр списка классификаторов
• Создание классификатора
• Удаление классификатора
• Настройка классификатора
• Просмотр структуры классификатора
• Просмотр корневой папки
• Просмотр выбранной папки
• Перемещение папки
• Удаление папки
• Создание папки
• Настройка папки
1.9.7.5 Просмотр классификаторов
На странице возможно выполнение следующих операций:
• Просмотр структуры классификатора
• Просмотр корневой папки
• Просмотр выбранной папки
• Перемещение документа/элемента
• Удаление документа/элемента из папки
• Добавление документа/элемента в папку
• Просмотр документа/элемента
1.9.7.6 Управление типами документов
На странице возможно выполнение следующих операций:
• Просмотр списка типов документов
• Создание типа документов
• Удаление типа документа
• Просмотр типа документа
• Изменение типа документов
o Добавление атрибута
o Удаление атрибута
o Изменение атрибута
o Редактирование свойств типа документа
1.9.7.7 Поиск документов
На странице возможно выполнение следующих операций:
• Поиск по типу документа
• Поиск по папке и типу документа
• Поиск по всем типам документов
• Поиск по всем типам документа по папке
1.9.7.8 Работа с документами
На странице возможно выполнение следующих операций:
• Создание документа
• Удаление документа
• Редактирование документа
• Просмотр документа
1.9.7.9 Управление справочниками
На странице возможно выполнение следующих операций:
• Просмотр списка справочников
• Создание справочника
• Удаление справочника
• Просмотр справочника
• Изменение справочника
o Добавление атрибута
o Удаление атрибута
o Изменение атрибута
o Редактирование свойств справочника
1.9.7.10 Работа с элементами
На странице возможно выполнение следующих операций:
• Создание элемента
• Удаление элемента
• Редактирование элемента
• Просмотр элемента
• Поиск элемента
1.9.7.11 Администрирование со стороны субъектов
На странице возможно выполнение следующих операций:
• Просмотр списка ролей
• Просмотр списка пользователей
• Добавление роли
• Удаление роли
• Просмотр списка пользователей у роли
• Просмотр списка ролей у пользователя
• Добавление пользователя
• Удаление пользователя
• Добавление пользователя в роль
• Удаление пользователя из роли
• Просмотр свойств пользователя
• Просмотр свойств роли
• Просмотр прав доступа у пользователя по объектам
• Просмотр прав доступа у роли по объектам
• Редактирование прав доступа у пользователя по объектам
• Редактирование прав доступа у роли по объектам
1.9.7.12 Администрирование со стороны объектов
На странице возможно выполнение следующих операций:
• Выбор объекта
• Просмотр прав доступа по субъектам
• Добавление субъекта
• Удаление субъекта
• Редактирование прав доступа у субъекта
1.9.7.13 Страница управления отчетами
На странице возможно выполнение следующих операций:
• Просмотр списка отчетов
• Запуск отчета
1.9.7.14 Подписка на уведомления со стороны объектов
На странице возможно выполнение следующих операций:
• Выбор объекта
• Просмотр подписок
• Добавление подписки
• Удаление подписки
• Редактирование подписки
1.9.7.15 Подписка на уведомления со стороны субъектов
На странице возможно выполнение следующих операций:
• Выбор подписчика
• Просмотр списка подписок
• Добавление подписки
• Удаление подписки
• Редактирование подписки
1.9.7.16 Маршрутизация: регистрация шаблонов маршрутов
На странице возможно выполнение следующих операций:
• Просмотр списка шаблонов маршрутов
• Добавление шаблона маршрута
• Удаление шаблона маршрута
• Редактирование шаблона маршрута
1.9.7.17 Маршрутизация: управление процессами
На странице возможно выполнение следующих операций:
• Просмотр списка маршрутов
• Создание маршрута
• Настройка маршрута
• Удаление маршрута
• Запуск маршрута
• Остановка маршрута
1.9.7.18 Маршрутизация: исполнение заданий
На странице возможно выполнение следующих операций:
• Просмотр списка заданий
• Просмотр задания
• Выполнение задания
• Просмотр папки с документами
1.9.7.19 Приемная
На странице возможно выполнение следующих операций:
• Заполнение личных данных пользователя
• Выбор организации для обращения
• Заполнение формы обращения
• Отправка обращения и показ результата отправки

1.10 Требования к информационной и программной совместимости
Функции сервисов должны вызываться ведомственными системами посредством клиентского модуля.
Клиентский модуль должен иметь специфицированные интерфейсы, доступные для вызова ведомственными системами с учетом сокращения усилий по интеграции их ЕСЭДО-Н. Интерфейсы должны учитывать платформу работы ведомственных интегрируемых систем, и должны быть согласованы с их разработчиками.
1.11 Требования по стандартизации и унификации
Программные средства ЕСЭДО РК должны удовлетворять основным мировым стандартам в области обработки документов:
1) Поддержка современных транспортных протоколов: TCP/IP, HTTP 1.1; HTTPS; SSL (до уровня 3.0).
2) Поддержка наиболее распространенных форматов документов: Microsoft Office, PDF; HTML, XML.
3) В области интеграции со средствами разработки:
1. Поддержка Java.
2. Поддержка Microsoft .Net.
4) Поддержка в области повышения отказоустойчивости и надежности системы:
1. Поддержка кластерных решений с балансировкой нагрузки.
2. Поддержка распределенного поиска информации.
3. Поддержка распределенного доступа к информации.
1.12 Требования к эргономике и технической эстетике
Испытания на соответствие требованиям к эргономике и технической эстетике осуществляются при тестировании всех функциональных операций, приведенных в прилагаемых Методиках, в соответствии с ТЗ и «Технической спецификацией».
2 Материально-техническое обеспечение испытаний
Агентство по Информатизации и Связи совместно с ЗАО НИТ обеспечивают следующее оборудование:
2.1 Сервера и рабочие станции
№ Наименование Платформа OS Проц ОЗУ Шт Базовое ПО Примечание
1 CM SDK RISC AIX 4 4Гб 1 Oracle 9iAS
2 Хранилище RISC AIX 4 4Гб 1 СУБД Oracle
3 Инфраструктура Oracle iAS RISC AIX 1 2Гб 1 Oracle Internet Directory
4 Сервер СГДС INTEL Server WIN 2003 1 1Гб 3 POP3 и SMTP Сервер POP3 и SMTP применяются временно для имитации СГДС. В дальнейшем, возможен переход на другую СГДС и соответственно на другие протоколы обмена данными.
5 Портал INTEL Server WIN 2003 1 1Гб 1 Oracle 9iAS
6 Внутриведомственный Сервер RISC/Intel AIX/ Server WIN 2003 1 1Гб 2 Lotus Domino
7 Рабочая Станция Intel Win 2000/XP 1 256 Мб 3-7
Сервера, обозначенные в первых трех позициях, можно объединить и установить на одном физическом сервере. Однако при этом будет невозможно продемонстрировать требуемую масштабируемость и полноценное «ресурсное» тестирование, а также усложнится администрирование.
2.2 Прочее оборудование
Наименование Кол-во Примечание
Коммуникационное
Оборудование (например CISCO, HUB|SWITCH, MODEM и т.п.) по необходимости Любая защищенная корпоративная сеть обеспечиваяющая передачу данных по TCP/IP со скоростью не ниже 10Mbps
Необходимо обеспечить “прямую видимость” между всеми серверами СГДС (в НЦ, МСХ и МБЭП), по протоколу TCP/IP
Выбор конкретного коммуникационного оборудования зависит от вида предоставленного канала связи.
Возможные каналы связи – спутниковая связь, СПДСМ, пр.

3 Отчетность
На испытания должен быть представлен следующий перечень документов:
1. Общее описание системы
2. Программа и методика испытаний
В результате испытаний должны быть подготовлены следующие документы:
1. Отчет о результатах испытаний
2. Протокол испытаний
3. Акт об испытаниях
Отчет о результатах испытаний и протокол испытаний готовит ЗАО «НИТ» в течение недели после завершения испытаний. На основании протокола ЗАО НИТ, ТОО СофтИнженер и АИС подписывают акт о проведении испытаний системы.


4 Приложение А.
Методика автономных испытаний функций сервисов ЕСЭДО через ведомственные системы
4.1 Общие сведения
Настоящая методика описывает последовательность действий и ожидаемые результаты при автономном тестировании функций сервисов НЦ ЕСЭДО работой подключенных ведомственных приложений.
4.2 Общая схема работы при автономных испытаниях
При автономных испытаниях тестируется корректная работа функций сервисов НЦ ЕСЭДО при вызове их через программный интерфейс системами ведомственного уровня.
Для проверки работы функций пользователь ведомственной системы, работая в АРМе ведомственной системы ЕСЭДО-В 1.1, выполняет операции описанным в методике образом и отслеживает результат их выполнения.
Ведомственная система взаимодействует с сервисами НЦ ЕСЭДО обменом XML-сообщениями. Со стороны ведомства вызов функции сервисов происходит в виде исходящего сообщения, результат выполнения – в виде входящего сообщения. Отслеживание работы сервисов возможно как проверкой реакции ведомственной системы на получение ответного сообщения (рекомендуемый способ), так и просмотром самих исходящих/входящих сообщений.
Поскольку СГДС построен на асинхронном транспортном протоколе, то между вызовом функции и получением результата может проходить некоторое время, определяемое настройками СГДС и состоянием канала связи.
4.3 Сервис ведения справочников и классификаторов
4.3.1 Работа со справочниками
4.3.1.1 Создание нового справочника
Тестируемая функция: createDictionary
Для создания нового справочника необходимо нажать на кнопку «Создать справочник» в панели действий представления «4.Работа с НЦ». Будет открыт новый документ, в котором необходимо описать все параметры данного справочника:
1. Описание справочника:
• Код справочника (уникальный кодовый идентификатор);
• Имя справочника;
• Описание справочника.
2. Имя формы – указать, по какой форме создаются документы для данного справочника.
3. Атрибуты справочника – нужно перечислить описание всех полей, значения которых необходимо передавать в НЦ. В описание атрибута входит:
• Код атрибута (уникальный кодовый идентификатор);
• Имя атрибута;
• Описание атрибута.
Для добавления, изменения или удаления атрибута в еще незарегистрированном справочнике необходимо нажать кнопку «Добавить» в разделе «Атрибуты».
После внесения всех данных, надо нажать на кнопку «Отправить в НЦ» в панели действий документа, после чего создано соответствующее сообщение, а документ – сохранен и закрыт.
Затем, по нажатию на «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение регистрации справочника в НЦ, а в документ справочника будет внесен ID-номер справочника, под которым он зарегистрирован в НЦ.
4.3.1.2 Изменение существующего справочника
Тестируемая функция: changeDictionary
После того как справочник зарегистрирован в НЦ, все изменения данных описания справочника (название, код, комментарий) на стороне ведомства должны быть отражены в НЦ.
Для изменения данных описания справочника необходимо:
• Нажать на кнопку «Изменить» в разделе свойств справочника, которая видна только в режиме редактирования;
• В диалоге изменения свойств справочника внести необходимые данные и нажать кнопку ОК;
Измененные данные будут отправлены в НЦ и там зарегистрированы. Затем, по нажатию на кнопку «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение изменения справочника в НЦ, а в документ справочника будут внесены изменения свойств.
4.3.1.3 Удаление существующего справочника
Тестируемая функция: removeDictionary
Для удаления справочника, зарегистрированного в НЦ, необходимо:
• Нажать на кнопку «Удалить справочник» панели действий представления «4.Работа с НЦ»;
• В появившемся диалоговом окне выбрать код справочника, который надо удалить и нажать ОК.
После этого автоматически будет создано сообщение, после обработки которого справочник будет удален в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus данное сообщение будет раскодировано и соответствующий справочник удален из ведомственной БД.
4.3.2 Работа с атрибутами справочника
4.3.2.1 Создание нового атрибута в справочнике
Тестируемая функция: createAttribute
Для добавления нового атрибута необходимо нажать кнопку «Добавить» в разделе «Атрибуты», которая видна только в режиме редактирования. После этого надо внести все данные в появившееся диалоговое окно. Если документ еще не зарегистрирован в НЦ, то данные атрибута будут автоматически добавлены в таблицу. Если же регистрация уже состоялась – то вначале будет создано сообщение для регистрации данного атрибута в НЦ, после обработки которого данный атрибут будет добавлен в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатию на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующий справочник Лотусовой БД будет добавлен данный атрибут.
4.3.2.2 Изменение существующего атрибута
Тестируемая функция: changeAttribute
Для редактирования атрибута необходимо нажать кнопку «Изменить» в разделе «Атрибуты», которая видна только в режиме редактирования. В появившемся диалоге выбора атрибута надо выбрать необходимый. После этого надо внести все данные в появившееся диалоговое окно. Если документ еще не зарегистрирован в НЦ, то данные атрибута будут автоматически изменены в таблице. Если же регистрация уже состоялась – то вначале будет создано сообщение для регистрации изменения данного атрибута в НЦ, после обработки которого данный атрибут будет изменен в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатию на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующем справочнике Лотусовой БД будет изменен данный атрибут.
4.3.2.3 Удаление существующего атрибута
Тестируемая функция: removeAttribute
Для удаление атрибута необходимо нажать кнопку «Удалить» в разделе «Атрибуты», которая видна только в режиме редактирования. В появившемся диалоге выбора атрибута надо выбрать необходимый. Если документ еще не зарегистрирован в НЦ, то данные атрибута будут автоматически изменены в таблице. Если же регистрация уже состоялась – то вначале будет создано сообщение для регистрации удаления данного атрибута в НЦ, после обработки которого данный атрибут будет изменен в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатию на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующем справочнике Лотусовой БД будет удален данный атрибут.
4.3.3 Работа с Классификаторами
4.3.3.1 Создание нового классификатора
Тестируемая функция: createClassifier
Для создания нового справочника необходимо нажать на кнопку «Создать классификатор» в панели действий представления «4.2 Сервис классификаторов». Будет открыт новый документ, в котором необходимо описать все параметры данного классификатора:
• Код классификатора (уникальный кодовый идентификатор);
• Имя классификатора;
• Описание классификатора.
После внесения всех данных, надо нажать на кнопку «Отправить в НЦ» в панели действий документа, после чего создано соответствующее сообщение, а документ – сохранен и закрыт.
Затем, по нажатию на «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение регистрации классификатора в НЦ, а в документ классификатора будет внесен ID-номер классификатора, под которым он зарегистрирован в НЦ.
4.3.3.2 Изменение существующего классификатора
Тестируемая функция: changeClassifier
После того как классификатор зарегистрирован в НЦ, все его изменения должны отражаться в НЦ.
Для изменения данных описания классификатора необходимо:
• В документе классификатора нажать на кнопку «Изменить» в разделе свойств классификатора, который виден только в режиме редактирования;
• В диалоге изменения свойств классификатора внести необходимые данные и нажать кнопку ОК;
Измененные данные будут отправлены в НЦ и там зарегистрированы. Затем, при нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение изменения классификатора в НЦ, а в документ классификатора будут внесены изменения свойств.
4.3.3.3 Удаление существующего классификатора
Тестируемая функция: removeClassifier
Для удаления классификатора, зарегистрированного в НЦ необходимо:
• Нажать на кнопку «Удалить классификатор» панели действий представления «4.Работа с НЦ»;
• В появившемся диалоговом окне выбрать код классификатора, который надо удалить и нажать ОК.
После этого автоматически будет создано сообщение, после обработки которого классификатор будет удален в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus данное сообщение будет раскодировано и соответствующий классификатор удален из Лотусовой БД.
4.3.4 Работа с Папками Классификатора:
4.3.4.1 Создание новой папки
Тестируемая функция: createFolder
Для создания новой папки необходимо выбрать классификатор или папку, которые будут родительской для данной и нажать на кнопку «Создать папку» в панели действий представления «4.2 Сервис классификаторов». Будет открыт новый документ, в котором необходимо описать все параметры данной папки:
• Код папки (уникальный кодовый идентификатор);
• Имя папки;
• Описание папки.
После внесения всех данных, надо нажать на кнопку «Отправить в НЦ» в панели действий документа, после чего создано соответствующее сообщение, а документ – сохранен и закрыт.
Затем, по нажатии на «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение регистрации папки в НЦ, а в документ папки будет внесен ID-номер классификатора, под которым он зарегистрирован в НЦ.
4.3.4.2 Изменение существующей папки
Тестируемая функция: changeFolder
После того как папка зарегистрирована в НЦ, все изменения нужно обязательно там зарегистрировать.
Для изменения данных описания папки необходимо:
• В документе папки нажать на кнопку «Изменить» в разделе свойств папки, которая видна только в режиме редактирования;
• В диалоге изменения свойств папки внести необходимые данные и нажать кнопку ОК;
Измененные данные будут отправлены в НЦ и там зарегистрированы. Затем, по нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus будет получено подтверждение изменения папки в НЦ, а в документ папки будут внесены изменения свойств.
4.3.4.3 Удаление существующей папки
Тестируемая функция: removeFolder
Для удаления папки, зарегистрированного в НЦ необходимо:
• Нажать на кнопку «Удалить классификатор» панели действий представления «4.Работа с НЦ»;
• В появившемся диалоговом окне выбрать код классификатора/папки, который надо удалить и нажать ОК.
После этого автоматически будет создано сообщение, после обработки которого папка будет удален в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus данное сообщение будет раскодировано и соответствующая папка удалена из Лотусовой БД.
4.3.5 Работа с элементами справочника
4.3.5.1 Создание нового элемента справочника
Тестируемая функция: createElement
Для создания нового элемента справочника в НЦ необходимо:
• Выделить элемент.
• В меню «Работа с НЦ» выбрать пункт меню Отправка.
После нажатия на кнопку «Отправка» будет создано сообщение, в котором необходимые данные будут отправлены в НЦ. После обработки этого сообщения данный элемент будет добавлен в НЦ, а в ответ будет послано подтверждающее сообщение. По нажатию на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующий элемент будет внесен ID-номер, под которым он зарегистрирован в НЦ.
4.3.5.2 Изменение существующего элемента справочника
Тестируемая функция: changeElement
Для изменения документа в НЦ необходимо
• Внести изменения в элемент в Лотус-клиенте и сохранить его.
• Нажать на кнопку «Изменить в НЦ» в панели действий текущего представления.
После этого будет создано сообщение, в котором необходимые изменения будут отправлены в НЦ. После обработки этого сообщения данный элемент будет изменен в НЦ, а в ответ будет послано подтверждающее сообщение. При нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующий элемент будет внесены необходимые изменения.
4.3.5.3 Удаление существующего элемента справочника
Тестируемая функция: removeElement
Для удаления элемента необходимо выбрать данный элемент и нажать на кнопку «Удалить в НЦ» в панели действий текущего представления. После этого будет создано сообщение об удалении данного элемента в НЦ. После обработки этого сообщения данный документ будет удален в НЦ, а в ответ будет послано подтверждающее сообщение. При нажатии на кнопку «Принять пакет» меню «Действия» клиента Lotus, данное сообщение будет раскодировано и в соответствующий элемент будет удален и в базе данных Лотус.
4.4 Сервис ведения документов
4.4.1 Работа с типами документов
4.4.1.1 Создание типа документов
4.4.1.2 Изменение типа документов
4.4.1.3 Удаление типа документов
4.4.2 Работа с атрибутами
4.4.2.1 Добавление атрибута
4.4.2.2 Изменение атрибута
4.4.2.3 Удаление атрибута
4.4.3 Работа с документами
4.4.3.1 Создание документа
4.4.3.2 Изменение документа
4.4.3.3 Удаление документа

5 Приложение Б
Методика комплексных испытаний на основе ролевых сценариев использования
5.1 Общие сведения
Комплексные испытания заключаются в выполнении нескольких ролевых сценариев. Каждый сценарий представляет собой логически законченную последовательность операций, выполняемую пользователями системы с определенными функциональными ролями.
Функциональная роль в данном документе соответствует роли (группе пользователей), настраиваемой в сервисе администрирования. Выделенные функциональные роли имеют предварительный характер, т.е. описанные роли будут доопределяться, также возможно появление новых функциональных ролей в ходе эксплуатации системы. Создание и настройка ролей – штатная функциональная возможность системы.
5.2 Общая схема работы при комплексных испытаниях
В ходе комплексных испытаний несколько пользователей, проводящих испытания, находятся в различных АРМах испытательного стенда. В соответствии с настоящей методикой в зависимости от назначенных функциональных ролей ими последовательно выполняется ряд операций.
Каждый сценарий охватывает некоторое подмножество функционала сервисов и представляет собой пример реальной работы связки сервисов и ведомственных систем.
Выполняются следующие сценарии:
1. Создание и ведение общего справочника
2. Регистрация типа документа и ведение документов
3. Согласование проекта документа
4. Контроль исполнительской дисциплины
5. Администрирование разделения прав доступа
5.3 Перечень функциональных ролей
5.3.1 Роли в ведомстве
Роль Функции
Технолог Управление структурой справочников и типов документов, а также процессами уведомлений об изменениях
Сотрудник канцелярии Подписывает сообщения, отправленные в НЦ, ЭЦП
Сотрудник Работа со справочниками и документами, настройка и запуск маршрутов, получение и исполнение заданий
5.3.2 Роли в НЦ
Роль Функции
Администратор Управление правами доступа
Технолог маршрутизации Создание шаблонов маршрутов, настройка и запуск маршрутов
Технолог типов документов Управление структурой типов документов
Технолог справочников Управление структурой справочников
Примечание.
Дальнейшее дробление ролей в ведомстве на этапе предварительных испытаний представляется нецелесообразным: права доступа на запуск маршрутов определенных шаблонов, работу с документами определенных типов и определенных справочников назначаются в зависимости от конкретных потребностей, определяемых деятельностью ведомств при эксплуатации системы.
5.4 Операции, выполняемые функциональными ролями
5.4.1 Технолог ведомства, ответственный за ведение справочника (типа документов), технологи справочников и типов документов НЦ:
• Изменение структуры справочников
• Изменение структуры типов документов
• Регистрация справочника
• Удаление справочника
• Регистрация типа документа
• Удаление типа документа
• Настройка подписки на события
Уведомления - владельцам, подписчикам и в обязательном порядке технологам НЦ
Вести структуру справочников и типов документов, а также создавать и удалять справочники и типы документов могут технологи как на стороне ведомств, так и в НЦ. Со стороны ведомства назначается ответственный пользователь, который может править структуру справочника (типа документа). Это ведомство закрепляется за справочником (типом документа) как владелец. Также структуру любых справочников и типов документов могут править технологи НЦ.
Технологи на стороне ведомств и НЦ могут настраивать подписки на изменения справочников и документов, в т.ч. их структуры.
5.4.2 Технолог маршрутизации:
• Регистрация шаблона маршрута
• Создание и настройка маршрута
Технолог маршрутизации на стороне НЦ отвечает за создание и настройку шаблонов маршрутов (в WorkFlow Builder), а также за создание и подготовку маршрутов (т.е. он может выполнять функции владельца маршрута - см. далее).
5.4.3 Владелец маршрута:
• Настройка маршрута
• Запуск маршрута
• Отслеживание маршрута
• Остановка маршрута
Владелец маршрута (сотрудник ведомства) донастраивает маршрут: определяются адресаты, заполняются документами рабочие папки исполнителей, затем маршрут запускается и владелец может отслеживать выполнение заданий.
5.4.4 Администратор НЦ:
• Регистрация пользователя
• Регистрация роли
• Настройка прав доступа
• Настройка подписки на события
5.4.5 Сотрудник ведомства:
• Получение заданий
• Исполнение заданий
• Создание, удаление, изменение документов
• Создание, удаление, изменение эл-тов справочников
• Запуск и отслеживание маршрутов, остановка маршрутов
5.5 Типовые сценарии взаимодействия
Рассматриваются следующие сценарии взаимодействия:
1. Создание и ведение общего справочника
2. Регистрация типа документа и ведение документов
3. Согласование проекта документа
4. Контроль исполнительской дисциплины
5. Администрирование разделения прав доступа
5.5.1 Сценарий 1. Создание и ведение общего справочника
5.5.1.1 Цель испытаний
Проверка степени выполнения требований функционального назначения системы в части:
• Создания общих справочников
• Централизованного ведения общих справочников
• Поддержание ведомственными системами справочников в актуальном состоянии посредством механизма отправки уведомлений об изменениях
5.5.1.2 Участвующие роли:
Технолог ведомства А, сотрудник ведомства А, технолог ведомства Б, технолог по справочникам НЦ, администратор, приложения ведомства Б, подписанные на события соответствующих типов к данному справочнику.
5.5.1.3 Создание справочника:
1. В ведомстве А, регистрирующем новый справочник, технолог с помощью функционала ведомственной системы, либо посредством портала, создает новый справочник в НЦ. При этом технологи всех ведомств (Б), технолог справочников НЦ, и администратор НЦ получают уведомления о создании нового справочника в НЦ.
2. Администратор по согласованию с технологом ведомства А, либо сам технолог при наличии соответствующих прав, назначает права доступа на созданный справочник. Права на изменение структуры справочника должны быть у технолога ведомства А и технолога НЦ по справочникам. По умолчанию права на просмотр и редактирование элементов данного справочника должны быть у технолога ведомства А и технолога НЦ по справочникам, а также у Администратора.
5.5.1.4 Изменение элемента:
1. В ведомстве А, отвечающем за ведение данного справочника, сотрудником правится некоторый элемент справочника. НЦ получает сообщение об этом от ведомственной системы.
2. После проверки прав доступа элемент меняется в НЦ, подписчикам на изменения в данном справочнике высылаются уведомления. Подписчиками являются приложения ведомственных систем (приложение в ведомстве Б).
3. Приложения-подписчики изменяют соответствующий элемент в ведомственных БД.
5.5.1.5 Создание элемента
4. В ведомстве А, отвечающем за ведение данного справочника, сотрудником создается новый элемент справочника. НЦ получает сообщение об этом с указанием всей необходимой информации о новом элементе.
5. После проверки прав доступа элемент создается в НЦ, подписчикам на изменения в данном справочнике высылаются уведомления.
6. Приложения-подписчики добавляют соответствующий элемент в ведомственных БД.
5.5.1.6 Удаление элемента
7. В ведомстве А, отвечающем за ведение данного справочника, сотрудником удаляется элемент справочника. НЦ получает сообщение об этом с указанием ID удаляемого элемента.
8. После проверки прав элемент удаляется в НЦ, подписчикам на изменения в данном справочнике высылаются уведомления.
9. Приложения-подписчики (приложение в ведомстве Б) удаляют соответствующий элемент в ведомственных БД.
5.5.2 Сценарий 2. Регистрация типа документа и ведение документов
5.5.2.1 Цель испытаний
Проверка степени выполнения требований функционального назначения системы в части:
• Регистрации типов документов
• Централизованного ведения документов
• Групповой работы с документами
• Работы с разделами классификаторов
5.5.2.2 Участвующие роли:
Технолог ведомства А, сотрудник 1 ведомства А, сотрудник 2 ведомства А, технолог ведомства Б, технолог по документам НЦ, технолог по классификаторам НЦ, администратор, приложения ведомства Б, подписанные на события соответствующих типов к данному типу документа.
5.5.2.3 Регистрация типа документа:
1. В ведомстве А, регистрирующем новый тип документа, технолог с помощью функционала ведомственной системы, либо посредством портала, создает новый тип документа в НЦ. При этом технологи всех ведомств (А и Б), технолог документов НЦ, и администратор НЦ получают уведомления о создании нового типа документа в НЦ.
2. Администратор по согласованию с технологом ведомства А, либо сам технолог при наличии соответствующих прав, назначает права доступа на созданный тип документа. Права на изменение структуры типа документа должны быть у технолога ведомства А и технолога НЦ по документам. По умолчанию права на просмотр и редактирование документов данного типа должны быть у технолога ведомства А и технолога НЦ по документам, а также у Администратора.
5.5.2.4 Редактирование неверсионного документа:
3. В ведомстве А сотрудником правится некоторый документ. НЦ получает сообщение об этом от ведомственной системы.
4. После проверки прав доступа документ меняется в НЦ, подписчикам на изменения документов данного типа высылаются уведомления. Подписчиками являются приложения ведомственных систем (приложение в ведомстве Б).
5. Приложения-подписчики изменяют соответствующий документ в ведомственных БД.
5.5.2.5 Редактирование версионного документа
6. В ведомстве А сотрудником 1 правится некоторый документ. Это происходит вызовом команды «Взять на редактирование». НЦ получает сообщение с запросом о том, чтобы взять документ на редактирование пользователем.
7. НЦ после проверки прав доступа меняет статус документа на Checked-out (Взят на редактирование) и отправляет актуальную версию ведомственному приложению.
8. Приложение при получении сообщения отображает смену статуса документа и разрешает его редактировать пользователю.
9. В ведомстве А сотрудник 2 видит изменение статуса документа (Взят на редактирование), а также убеждается в невозможности редактирования документа в этом статусе.
10. Сотрудник 2 ведомства А завершает редактирование документа и сохраняет его в ведомственной системе со снятой пометкой «Оставить на редактировании». Происходит операция check-in (Возвращение отредактированного документа). Сообщение с отредактированным документом отправляется в НЦ.
11. НЦ после проверки прав доступа создает новую версию документа и меняет статус с Checked-out на Normal. Приложениям, подписанным на события изменения документов данного типа, высылаются сообщения-уведомления.
12. Приложения-подписчики изменяют соответствующий документ в ведомственных БД.

5.5.2.6 Создание документа
13. В ведомстве А сотрудником создается новый документ. НЦ получает сообщение об этом с указанием всей необходимой информации о новом документе.
14. После проверки прав доступа документ создается в НЦ, подписчикам на изменения документов данного типа высылаются уведомления.
15. Приложения-подписчики добавляют соответствующий документ в ведомственных БД.
5.5.2.7 Удаление документа
16. В ведомстве А сотрудником удаляется документ. НЦ получает сообщение об этом с указанием ID удаляемого документа.
17. После проверки прав доступа документ удаляется в НЦ, подписчикам на события удаления документов данного типа высылаются уведомления.
18. Приложения-подписчики (приложение в ведомстве Б) удаляют соответствующий документ в ведомственных БД.

5.5.3 Сценарий 3. Согласование проекта документа
5.5.3.1 Участвующие роли
Сотрудник ведомства А – владелец маршрута, сотрудники ведомств Б, В, технолог маршрутизации НЦ.
5.5.3.2 Краткое описание сценария
1. Владелец маршрута (сотрудник ведомства А) подает заявку на создание шаблона маршрута. Заявка представляет собой документ определенного типа, который заявитель кладет в определенную папку.
2. Технолог маршрутизации создает шаблон маршрута. В шаблоне указываются название, задается кол-во и последовательность адресатов, логика выполнения.
3. Владелец маршрута создает маршрут на основе шаблона (выбирая его из списка доступных). При этом он настраивает маршрут, указывая адресатам конкретных исполнителей, выбирая их из справочников должностных лиц ведомств. Также в настройку входит указание рабочих документов для рассылки и времени выполнения заданий. Рабочие документы выбираются из доступных классификаторов и типов документов.
4. После настройки сотрудник ведомства А запускает маршрут. Дальнейший процесс согласования осуществляется сервисом маршрутизации под контролем данного сотрудника.
5. Исполнитель ведомства Б получает задание (согласовать документ). Меняется состояние задания на портале, это может проконтролировать сотрудник ведомства А – владелец маршрута.
6. Исполнитель ведомства Б выполняет задание (меняет статус его с каким-то результатом, выбираемым из списка: Cогласовано | Отправить на доработку | Отказать). Сообщение с результатом выполнения отправляется в НЦ, результат становится виден сотруднику ведомства А – владельцу маршрута. Ему также отправляется оповещение (в ведомственное приложение).
7. В случае, если результат выполнения согласования – «Отправить на доработку», новое задание (досогласовать документ) отправляется исполнителю в ведомство В.
8. Исполнитель ведомства В получает задание. Меняется состояние задания на портале, это может проконтролировать владелец маршрута.
9. Исполнитель ведомства В выполняет задание (меняет статус его с каким-то результатом, выбираемым из списка: Документы доработаны | Документы отклонены). Сообщение с результатом выполнения отправляется в НЦ, результат становится виден сотруднику ведомства А – владельцу маршрута. В ведомственное приложение ведомства А отправляется оповещение.
10. В зависимости от результата выполнения заданий процесс согласования или завершается, или снова создается задание и отсылается ведомству Б.
11. Маршрут завершает свою работу. Владелец маршрута извещается сообщением о выполнении маршрута и его результатах.
5.5.3.3 Подробное описание сценария
Отправка заявки на регистрацию шаблона маршрута
Для передачи заявок на регистрацию шаблона маршрута будет создана папка («Заявки на создание шаблона маршрута»), а также соответствующий тип документа («Шаблон маршрута»). Технолог маршрутизации в НЦ, должен быть подписан на события о создании новых документов данного типа.
1. Заявитель формирует документ типа «Шаблон маршрута» и передает в НЦ
2. Документ помещается в соответствующую папку (Заявки на создание шаблона маршрута)
3. Технолог получает оповещение о создании нового документа
Создание шаблона маршрута
Формируется шаблон с использованием Oracle Workflow Builder

Указывается наименование шаблона маршрута: Согласование документов
Создаются параметры шаблона маршрута, (далее заполняемые при запуске данного маршрута):
1. Согласующий орган
2. Время выполнения согласования (в днях)
3. Орган, выполняющий доработку документов, в случае необходимости их доработки


Рис. 2 Маршрут согласования
Регистрация шаблона маршрута
Регистрация шаблона маршрута производится с использованием портала НЦ, где определяются следующие свойства:
• Наименование
• Описание
• Орган, инициировавший создание данного шаблона маршрута
• Изображение шаблона (см. Рис. 1)
• Наименование шаблона маршрута в Oracle Workflow (ItemType)

Все эти параметры указываются пользователем (технологом маршрутизации).
Запуск маршрута
(Жирным шрифтом выделены действия, совершаемые непосредственно пользователем).
Ведомственной системой в НЦ посылается запрос на список возможных шаблонов маршрутов (retrieveProcessDefinitionList)
1. Выбирается шаблон маршрута (пользователем)
2. Формируются необходимые для согласования документы
3. Определяются параметры папки, в которой будут находится данные документы
4. Определяются параметры для запуска (выбираются из списка пользователем)
a. Согласующий орган
b. Время выполнения согласования
c. Орган, выполняющий доработку документов, в случае необходимости их доработки
5. Осуществляется запуск маршрута (LaunchProcessFD) (по команде пользователя)
a. Создается папка в НЦ (См. Сервис ведения справочников и классификаторов) (пользователем указывается название)
b. Создаются документы (См. Сервис ведения справочников и классификаторов) (пользователем выбираются из списка)
c. Документы помещаются в соответствующую папку (отправкой ведомственной системой соответствующих сообщений в НЦ)
d. Созданная папка с документами становится свойством Запускаемого маршрута

Рис.2 Диаграмма последовательности выполнения запуска маршрута

Ход выполнения
Стадия согласования
1. Согласующий орган получает Задание в виде
a. Рабочей папки маршрута (Документы, требующие согласования)
b. Списка возможных вариантов выполнения данного задания
(Список: Отправить на доработку | Согласовано)
Задание появляется в списке заданий исполнителя. Оно становится доступным для мониторинга владельцем маршрута (пользователем, запустившим маршрут).
2. Выполнение задания заключается в следующем
a. Выбор исполнителем из списка возможных вариантов выполнения и помещения ведомственной системой выбранного варианта в свойство Result, объекта Задания
b. Формируются замечания, по согласуемым документам
i. Создается папка в НЦ
ii. Создаются документы в НЦ (пользователем)
iii. Документы помещаются в соответствующую папку
c. Папка документов фиксируется как рабочая папка данного задания (это происходит на шаге 2-b-i )
d. Выполненное задание отправляется в НЦ для отражения его статуса и результата (activityIsDone)

Стадия доработки
1. Согласующий орган получает Задание в виде
a. Рабочей папки маршрута (Документы, требующие согласования)
b. Списка возможных вариантов выполнения данного задания
(Список: Отправить на доработку | Согласовано)
2. Выполнение задания зак
stratexpert
Новичок

Зарегистрирован: 07.01.2009
Сообщения: 1

[13428] Ср Янв 07, 2009 23:02
КМПКФ и ЕСЭДО
Насзсколько мне известно, ЕСЭДО тихо скончалось, деньги отмыты и все хорошо. После КМПКФ еще были НИР на разработку Единой НСИ (ЕНСИ) - там тоже все успешно освоено.