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

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

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

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




[4152] Пт Мар 14, 2003 06:48
Semantic Web & representation format
The Semantic Web needs Mathematical Logic to do usefull things, meaning
an abstract understanding of data, the operations that can be performed
on them and how they relate to eachother.

AI needs the Semantic Web as perhaps the first mainsteam application of
it. Unfortunatelly, research is not promoted without practical
applications. Beyond that though, I expect the SW will open new doors
for applying AI. The environment of SW can provide computational
resources and decentralized topologies that would have been impossible
otherwise.

It's not much but you get the idea. AI feeding SW feeding AI... Other
people will have far more complete suggestions than the above. You will
need to watch over the SW community to catch those brainstorms...
M. Nilsson
Гость




[4336] Пн Апр 21, 2003 11:01
Conceptual (un)clarity on the Web, however :)
It is not at all evident that such machine readable semantic information as Kazakhstan machine understandable format, will be clear and effective for human interpretation.
The hyper-linked structure of the web presents the user with a totally fluid and dynamic relationship between context and content, which makes it hard to get an overview of the conceptual context within which the information is presented. As soon as you click on a hyperlink, you are transferred, helplessly, to a new and often unfamiliar context.
This results in the all toowell-known "surfing-sickness" on the web, that could be summarized as "Within what context am I viewing this, and how did Iget here?" The conclusion we draw is that extracting usable meaning from web pages is often as difficult for a HUMAN as it is for a machine.
This strongly suggests that there is a need for a human-understandable semantics for web resources as well.
Losing the contextual information of the contentmeans more than just "surfing-sickness". It means that you will not be able to contextually integrate the concepts that you aretrying to learn, which is vitally important in order to achieve an understanding of any specific subject area.
The semantic web initiative, as it looks today, does NOT provide such a semantics!
It provides descriptions of web resources only, but no way to present them to the user in a contextually clear way. The same it is possible to say about above format
In order to solve this problem, we are working on ideas to extend the semantic web in order to provide not only semanticinformation for the machine, but also conceptual information for the human user.
Chief constructor
Новичок

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

[4343] Пн Апр 21, 2003 19:31
Re: Conceptual (un)clarity on the Web, however :)
Действительно, несомненна важность понимания читателем машинопонимаемой (простите за тавтологию) семантической информации. Я называю КМПК - формат не только машинопонимаемым, но и человекочитаемым. Только вот как сначала правильно метаданные по полочкам расположить надо, а уж потом и прочесть их будет не проблема!
Подчеркиваю – прочесть, что вовсе не означает понять, ибо для понимания надо знать систему структурирования. А классификатор на основе КМПК – формата является весьма избыточной системой, так как по определению содержит все используемые в республике системы структурирования. Определяемые машиной метаданные должны быть разложены по соответствующим позициям разнородных систем структурирования в составе классификатора. А это возможно лишь при наличии в нем некоего базисного классификатора, с которым связаны все системы структурирования.
Без него то, что сейчас делают разработчики Semantic Web, есть попытка решения одних только частных вопросов классификации web - ресурсов.
На мой взгляд, это обусловлено недостаточной проработкой как философской, так и системной сторон проблемы. Дело в том, что нет ни устоявшегося понимания таксономий, ни полиэкранного представления онтологии (подсистема – система – надсистема в прошлом, настоящем, будущем), ни онтологического базиса для практической реализации классификации документов.
Можно, конечно, попытаться создать его на основе семантического словаря, но как отразить многомерное пространство онтологий через "одномерие" такого словаря?
Вопрос открыт…
Канат
Гость




[4401] Чт Май 08, 2003 06:34
конкурс на создание 2 очереди ЕСЭДО с использованием КМПК
Приложение 2
к Конкурсной документации для потенциальных поставщиков по государственным закупкам работ по внедрению и развитию единой системы электронного документооборота и базового программного обеспечения, утвержденной приказом Министра транспорта и коммуникаций Республики Казахстан
от "25" 04 2003 года

Техническая спецификация

По лоту 1: Разработка второй очереди ЕСЭДО с учетом проведенных научно-исследовательских работ (НИР)

В день подачи (26.05.2003) конкурсных заявок потенциальному поставщику необходимо представить презентацию своего решения по данному проекту.

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

1. ПОЛНОЕ НАИМЕНОВАНИЕ РАЗРАБОТКИ
Полное наименование научно – исследовательской опытно – конструкторской разработки (далее НИОКР) – Единая Система электронного документооборота для государственных органов Республики Казахстан, вторая очередь, национальный уровень.

2. УСЛОВНОЕ ОБОЗНАЧЕНИЕ РАЗРАБОТКИ
Условное обозначение НИОКР – ЕСЭДО-Н.

3. ОСНОВАНИЯ ДЛЯ РАЗРАБОТКИ
Основанием для разработки является:
Указ Президента Республики Казахстан №427 от 30 июля 2000 года «О мерах по улучшению работы государственного аппарата, борьбе с бюрократизмом и сокращению документооборота»
Указ Президента Республики Казахстан №573 от 16 марта 2001 года «О Государственной программе формирования и развития национальной информационной инфраструктуры Республики Казахстан»
Постановление Правительства Республики Казахстан №674 от 21 мая 2001 года «Об утверждении Плана мероприятий по реализации Государственной Программы формирования и развития Национальной информационной инфраструктуры в Республике Казахстан на 2000 – 2003 годы»
Концепция развития электронного документооборота, утвержденная Правительственной Комиссией по координации работы по формированию Единого Информационного Пространства и процессов информатизации государственных учреждений 23.04.2001, протокол №2..
Техническое Задание на первую очередь Научно – Исследовательской Опытно – Конструкторской Работы по созданию Единой Системы Электронного Документооборота государственных органов Республики Казахстан. ЗАО НИТ, Астана, 2001
Заказчиком ЕСЭДО РК является Министерство Транспорта и Коммуникаций РК в лице Комитета связи и информатизации.

4. НАЗНАЧЕНИЕ И ЦЕЛЬ РАЗРАБОТКИ
ЕСЭДО РК является автоматизированной информационно-справочной системой, предназначенной для автоматизации технологических процессов подготовки, регистрации, структурирования, маршрутизации, хранения, архивации, поиска и обработки электронных документов (далее ЭД), контроля их исполнения, авторизации доступа к ним, выпуска и рассылки ЭД, извлечения информации из ЭД и ее анализа, получения знаний из накапливаемой информации, поддержки принятия решений.
В системе производится обработка создаваемых и используемых в делопроизводстве государственных органов Республики Казахстан как несекретных, так и содержащих информацию с пометой «Для служебного пользования» ЭД.
Целью разработки второй очереди ЕСЭДО РК является создание подсистем национального уровня, обеспечивающих управление ЭД на национальном уровне, в том числе:
• Создание Национального центра ЕС ЭДО (далее – НЦ ЕС ЭДО), который должен предоставлять участникам ЕСЭДО-Н сервисные функции, позволяющие эффективно вести межведомственное делопроизводство, контролировать исполнительскую деятельность, запрашивать информацию о документах, публиковать документы, проводить согласования, оповещения и ряд других функций.
• Формирование Национального Фонда электронных документов, организация массового доступа к ЭД, передача ЭД на хранение в СЭА ГО.
ЕСЭДО-Н - представляет межведомственную (национальную) информационно-справочную систему для обмена электронными документами между государственными органами. В системе производится обработка создаваемых и используемых в делопроизводстве государственных органов Республики Казахстан ЭД. Система автоматизирует технологические процессы подготовки, регистрации, структурирования, маршрутизации, хранения, архивации, поиска и обработки ЭД, контроля их исполнения, авторизации доступа к ним, рассылки ЭД, извлечения информации из ЭД и ее анализа на межведомственном уровне.

5. ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ
Объектом автоматизации является Система органов государственного управления Республики Казахстан. Каждое ведомство является участником ведомственного и межведомственного документооборота. Реализация первой очереди ЕСЭДО предусматривала внедрение электронного документооборота на ведомственном уровне. Предлагаемая система (ЕСЭДО-Н) должна рассматривать ведомство как источник или получатель ЭД. Также объектом автоматизации является НЦ ЕС ЭДО, правовой статус которого еще не определен и должен быть предложен Поставщиком, согласован и утвержден уполномоченными органами в ходе реализации Проекта.

6. СТРАТЕГИЧЕСКИЕ ТРЕБОВАНИЯ К СИСТЕМЕ
6.1. Характеристики ЕСЭДО
Масштабируемость – ЕСЭДО должна обеспечивать наращивание мощностей системы и определяется только характеристиками аппаратного обеспечения, на котором функционирует данная система, что позволяет максимально увеличивать количество рабочих мест и пропускную способность транспортной среды без внесения существенных изменений в логическую структуры системы и с наименьшими затратами на дополнительное оборудование. Масштабируемость достигается путем замены оборудования на более производительное и перераспределением нагрузки от вычислительных процессов за счет использования ресурсов подключаемого распределено другого оборудования.
Интегрированость – ЕСЭДО должна состоять из интегрированных подсистем, построенных на основе стандартных настраиваемых комплексов программного обеспечения (ПО), обеспечивающих работу системы в составе Национальной информационной инфраструктуры РК
Открытость – ЕСЭДО должна обладать открытым программным API интерфейсом, что позволяет использовать программные средства не только как готовое решение, но и как мощный инструмент разработчика.
Информационная безопасность – ЕСЭДО должна использовать механизмы, обеспечивающие автоматизацию режима ограничения доступа по чтению и / или редактированию в отношении отдельных подсистем, комплексов, отдельных документов и отдельных полей (частей) документов. ЕСЭДО обеспечивает возможность подключения внешних средств криптозащиты информации (шифрование, засекречивание) и алгоритмов электронной подписи и шифрования документов. ЕСЭДО обеспечивает минимизацию риска некорректного использования или злоупотребления за счет следующих мероприятий: получения доступа к системе только после идентификации пользователя с помощью программно – аппаратных средств идентификации, ввода корректного пароля, разграничения прав, поддержки аудита (фиксации) каждого вхождения или попыток подбора паролей, автоматического отключения пользователей после определенного интервала отсутствия активности и при выходе из прикладной программы.
Гибкость – возможность добавления новых функций в систему без нарушения её функционирования.
Распределенность – ЕСЭДО должна обеспечивать территориально распределенное хранение и доступ информации, включая удаленный доступ к ней по технологии WEB. ЕСЭДО должна обеспечивать распределенную обработку информации, расположенных на территориально распределенных серверах.
Поддержка полного жизненного цикла ЭД – система обеспечивает автоматизацию работы с ЭД, начиная с его разработки, затем согласования, подписания, регистрации, контроля исполнения и заканчивая архивным хранением. Поддержка жизненного цикла ЭД должна обеспечивать возможность сопряжения с системой маршрутизации для автоматического изменения состояния документа по мере его прохождения по маршруту.
Комплексность – ЕСЭДО должна обеспечивать поддержку смешанного характера делопроизводства, когда система обеспечивает ведение электронного делопроизводства на основе безбумажной технологии, смешанное делопроизводство с элементами безбумажной технологии обработки бумажных документов, бумажное делопроизводство. ЕСЭДО должна обеспечивать поддержку версионности документов, составных документов (с автоматической поддержкой их актуальности).
Надежность – ЕСЭДО должна обеспечивать резервное копирование информации, рестарт системы после сбойных и аварийных ситуаций без потери логической целостности баз данных, процедуры для поддержки целостности обработки данных после сбоев системы или других незапланированных простоев, логическую проверку входных данных. ЕСЭДО должна предусматривать применение средств гарантированного питания, резервирования носителей информации и основных узлов оборудования, резервного копирования, резервирования каналов связи. Для наиболее ответственных участков необходимо предусмотреть горячее резервирование серверов системы.
Поддержка гетерогенной сетевой среды – функционирование ЕСЭДО в сетевой среде, построенной с использованием различных сетевых и клиентских операционных систем. В качестве сетевых операционных систем необходимо предусмотреть использование Linux, Windows, Unix (Sun Solaris, HP-UX, OS/400, AIX). В качестве клиентских операционных систем следует предусмотреть Linux, Windows.
Расширяемость – ЕСЭДО поддерживает работу неограниченного числа организаций, имеющих свое независимое организационно-штатное расписание (работа с штатным расписанием всех филиалов и всем персоналом организации), обеспечивая при этом их объединение в единую национальную информационную инфраструктуру.
Преемственность - ЕСЭДО обеспечивает адекватное воспроизведение ранее созданной информации вне зависимости от технического прогресса и перманентной смены поколений средств вычислительной техники, носителей информации.
Модульность - ЕСЭДО в связи с разнородностью выполняемых функций должна состоять из отдельных взаимодействующих между собой подсистем, построенных на основе сопряжения путем настройки стандартных комплексов программного обеспечения (ПО), реализующего функции системы.
Унификация - методы описания, представления, передачи и обработки данных в электронной форме должны быть унифицированы.
Сопряжённость - в ЕСЭДО должны быть предусмотрены средства сопряжения с НИИ РК и системами республиканских государственных органов, а также с информационными системами учреждений-источников комплектования и учреждений, являющихся постоянными потребителями, а также с внеотраслевыми системами передачи данных, при условии утверждения государственных стандартов сопряжения.

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

6.3. Перспективы развития Системы
Предлагаемая система должна стать основой для построения специализированных Хранилищ документов, а затем и данных для выполнения анализа с помощью применения мощных аналитических инструментов (Data Mining, OLAP). В будущем, на последующих этапах, могут быть реализованы такие подсистемы как:
• Подсистема управления знаниями;
• Подсистема поддержки принятия решений.

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

6.3.2. Подсистема поддержки принятия решений
Основная задача данной подсистемы – обеспечение поддержки принятия решений как высших должностных лиц государства, так и руководителей государственных органов РК на основе содержащихся в системе знаний путем реализации следующих сценариев с возможностью расширения состава информационно – аналитических и модельно – аналитических услуг:
Мониторинг и анализ (включающий построение синтетических, сводных показателей) основных индикаторов социально-экономической ситуации в стране и ее регионах;
Прогноз - построение кратко- и средне- и долгосрочных прогнозов для основных макроэкономических показателей, характеризующих уровень социально-экономического развития региона или Республики Казахстан в целом, по заданным значениям экзогенных (в том числе, – управляемых) переменных;
Сценарный анализ - подготовка государственных решений с помощью многовариантных расчетов, позволяющих проследить последствия от планируемых изменений в бюджетной, налоговой, социальной, тарифной и т.п. сферах с точки зрения их влияния на ключевые индикаторы социально-экономического развития страны (региона);
Определение области тех допустимых значений управляемых или частично управляемых переменных, которые обеспечивают выход ключевых индикаторов социально-экономического развития страны (региона) на заданные уровни за определенное число тактов времени (кварталов, лет);
Анализ текущего влияния параметров основных мировых рынков (товарного, сырьевого, фондового, денежного) на ключевые индикаторы социально-экономического развития Казахстана и регионов;
Выработка предложений по основным направлениям стратегии социально-экономического развития страны (региона), основанных на компьютерных моделях экономического равновесия, дополненных долгосрочными экспертными прогнозами основных (глобальных) тенденций;
Проведение прогнозных расчетов по определению постатейных расходов и доходов государственного бюджета, формированию инвестиционных программ (включая инвестиционные фонды регионального развития) при различных вариантах структурной налоговой, социальной политик, внешнеэкономической ситуации и графиках погашения государственного долга;
Многовариантный расчет параметров платежного баланса при различных вариантах основных экзогенных переменных — объемах импорта, экспорта и золотовалютных запасов.
Исследование управляющих воздействий в области кредитно-денежной и инвестиционной (в территориальном разрезе) политики на основные индикаторы социально-экономического развития регионов, и в частности, на динамику каждого из них в пространстве состояний «реципиент – самодостаточный регион – донор»;
Взаимоувязка и стыковка прогнозных и сценарных расчетов по социально-экономическому развитию регионов как между собой, так и с соответствующими расчетами на уровне страны в целом.
Построение динамического межотраслевого баланса (МОБ) в прямой и обратной постановках задач.
Сценарный и прогнозный анализ ситуаций внутри отдельных секторов экономики (энергетического, транспортного, строительного, сельскохозяйственного и т.п.).

6.4. Требования к архитектуре системы

ЕСЭДО-Н должна состоять из подсистем:
Интерфейса с системами документооборота и делопроизводства ведомственного уровня;
Подсистемы документооборота и делопроизводства национального уровня;
Массового доступа к открытым электронным документам;
Транспортной среды.

6.4.1. Требования к патентной чистоте
Необходимо привести сведения о наличии лицензий на все используемые в Проекте инструменты разработки программного обеспечения, СУБД и другие программные продукты третьих сторон. В случае использования собственных разработок, указать наличие документальных свидетельств на владение интеллектуальной собственностью и авторскими правами.

6.4.2. Требования по стандартизации
Следует включить: показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений. Система кодирования и классификации, используемая для формирования нормативно-справочной информации должны отвечать требованиям классификации и атрибутирования документов, принятых на территории Республики Казахстан, а так же учитывать мировой опыт создания подобных систем.
Поддержка современных транспортных протоколов: TCP/IP, включая поддержку IP V6; HTTP 1.1; HTTPS; SSL (до уровня 3.0), WAP.
Поддержка наиболее распространенных форматов документов: Microsoft Office, PDF; HTML, XML.
Поддержка автоматического преобразования форматов документов.
Поддержка основных стандартов в области сопряжения с СУД – ODMA.
В области интеграции со средствами разработки:
Поддержка Java.
Поддержка Microsoft .Net.
Поддержка в области повышения отказоустойчивости и надежности системы:
Поддержка кластерных решений с балансировкой нагрузки.
Поддержка распределенного поиска информации.
Поддержка распределенного доступа к информации.
Возможность функционирования на различных аппаратных платформах.


6.5. Функциональные требования к ЕСЭДО-Н

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

6.5.2. Требования к реализации КМПКФ
6.5.2.1. Назначение и задачи
Казахстанский машинопонимаемый коммуникативный формат (КМПК – формат) есть реализованный на XML алгоритм обработки электронных документов. КМПКФ предназначен обеспечить возможность онтологического поиска и извлечения искомой информации, интероперабельность различных приложений программного обеспечения (ПО), функционирующих в Национальной Информационной Инфраструктуре Казахстана (НИИ РК) и сети Интернет, за счет обмена, описывающими эти документы, машинопонимаемыми метаданными.
Основной задачей разработки КМПКФ является создание единого национального стандарта на формат ЭД передаваемых в рамках ЕС ЭДО.
Формат предназначен стать "посредником" при осуществлении обмена документами между любыми организациями, являющимися участниками ЕС ЭДО. Т.е. разработка КМПКФ должна позволить участникам ЕСЭДО-Н, имеющим или создающим собственные информационные системы и системы внутриведомственного документооборота, использовать единый формат для обмена документами и их метаданными с ЕСЭДО-Н.
Также, он предназначен стать информационной основой для создания общей, сводной картотеки о документах в национальном масштабе и, как следствие, качественно улучшить любые делопроизводственные операции, обеспечить возможность накопления унифицированных данных о документообороте. Из этих требований, на основе мирового опыта должна быть разработана концепция формата, правила его формирования. Формат не должен быть статичным, должны быть разработаны и заложены правила, которые позволят в дальнейшем изменять, улучшать его без радикальных изменений системы в целом. Т.е. должны быть заложены предпосылки для его развития. Формат должен обеспечить наличие всей необходимой атрибутивной информации о документе, его аннотирование, рубрикацию. Реализация КМПКФ должна предполагать наличие как обязательных, так и факультативных тэгов.
КМПКФ не должен оговаривать форму, содержание или структуру записи локальных систем ведомственного документооборота, он может только содержать рекомендации по форме и содержанию данных, предназначенных для обмена. Необходимо, однако, обеспечить достаточный набор данных для передачи данных в НЦ ЕС ЭДО, извлекаемый в результате анализа (разбора) записи об ЭД на этапе его пересылки.
КМПК – формат должен обеспечить выполнение следующих задач обработки электронных документов путем формирования XML – схемы для каждого документа:
1. Транспортировка - обмен контентом и метаданными электронного документа между отправителем и получателем.
2. Структурирование – формирование машинопонимаемых метаданных для каждого документа по правилам КМПК – формата.
3. Сервис – дополнительные функции, расширяющие возможность использования информации, содержащейся в документе (например, данные о проведенных с документом в течение его жизненного цикла операциях, составных частях документа и приложениях, его текущее состояние и т. д.).
6.5.2.2. Принципы построения формата
Разработка КМПК-формата должна придерживаться следующих принципов:
1. Метки полей определяют поле в двух аспектах:
1.1. типом последовательности символов записанных в поле (например, имя лица)
1.2. функцией, выполняемой последовательностью символов в записи (например, ссылки). Эти аспекты фиксируются путем присвоения специальных значений позициям символов в метках полей. Метки могут быть цифровыми и буквенными. В первую очередь при формировании меток используются цифры. В случае необходимости набор цифровых символов может быть расширен за счет использования букв (предпочтительно строчных).
2. Значения индикаторов зависят от метки поля, но используются, по возможности, единообразно во всех полях. Индикаторы могут быть как цифровыми, так и буквенными. В первую очередь при формировании индикаторов используются цифры. В случае необходимости набор цифровых символов для образования индикаторов может быть расширен за счет использования букв (предпочтительно строчных).
3. Значения идентификаторов подполей зависят от метки поля, но, по возможности, одинаковые по смыслу элементы данных определены одними и теми же идентификаторами. Идентификаторы подполей могут быть цифровыми и буквенными. В первую очередь при формировании идентификаторов используются буквы (предпочтительно строчные). В случае необходимости набор буквенных символов может быть расширен за счет использования цифр. Значения, приписываемые идентификаторам подполей, служат главным образом для определения содержания подполя, а не для упорядочивания элементов данных. Порядок следования идентификаторов зависит от порядка следования элементов данных в записи и заранее не определяется.
4. Поля авторитетной / нормативной записи должны рассматриваться как изначально относящиеся к более общим категориям информации, таким как "Заголовок записи", "Формирование (трассировка) ссылки "см. также" и т.д. В машиночитаемой записи первоначальная группировка полей будет выполняться в соответствии с этими основными категориями.
6.5.2.3. Набор элементов
Модель - это только скелет описания. Для того чтобы практически описать даже самые простые атрибуты документа (название, автор, ключевые слова...) нужно дать этим атрибутам унифицированные названия, которые потом будут использоваться во всех системах. В противном случае один автор напишет "Название: Казахстанский машинопонимаемый коммуникативный формат", другой: "Заголовок: Казахстанский машинопонимаемый коммуникативный формат ", а третий "Title: Казахстанский машинопонимаемый коммуникативный формат ". На этом примере показано, что необходима стандартизация, обеспечивающая единый подход.
В настоящее время наиболее распространённым набором элементов для создания метаданных информационных ресурсов является набор, создаваемый уже в течение нескольких лет международной группой "The Dublin Core initiative" набор элементов международного коммуникативного формата UNIMARC.
Набор обязательных элементов формата UNIMARC можно разбить на пять групп:
001 - Идентификатор записи
100 - Данные общей обработки
101 - Язык документа (когда применяется)
200 - Заглавие и сведения об ответственности (обязательным является только подполе $а)
801 - Источник составления записи.
Остальные поля являются факультативными.
Набор обязательных элементов формата Dublin Core можно разбить на три группы:
Content – Title, Subject, Description, Type, Source, Relation, Coverage
Intellectual Property – Creator, Publisher, Contributor, Rights
Instantiation – Date, Format, Identifier, Language
6.5.2.4. Словари
Для того чтобы классификация ресурсов приносила пользу, мало выбрать модель и набор элементов-характеристик. Важно обеспечить ещё, заполнение конкретными значениями этих характеристик не в произвольной форме, а выбирать значения из общих справочников, классификаторов и записывать данные в понятной для всех форме. Например, формат даты и времени должен быть универсальным.
Если информационная система хочет иметь возможность выбирать ресурсы по географическим характеристикам, то нужен общепринятый справочник географических названий. Им может выступать, например, The Getty Thesaurus of Geographic Names (TGN), однако для использования таких общепринятых классификаторов и справочников, важно обеспечить их удобное применение, легкий и интуитивно-понятный интерфейс.
Очень актуален выбор тезауруса для характеристики предметной области темы документа (рубрикатора тем). Выбор конкретного, ограниченного по объёму списка облегчает поиск информации и улучшает качество поиска. Для поиска можно выделить два тезауруса: предметный тезаурус (subject tesaurus) и функциональный тезаурус (function thesaurus):
1. Предметный тезаурус содержит понятия предметной области и отражает содержание документа, он отвечает на вопрос "о чём этот документ?". Этот словарь называется просто "Тема" (Theme) и имеет многоуровневую структуру. Термины и структура верхних уровней этого словаря, общие для любых применений, заимствуются из категорий популярных поисковых систем. Дополнительно добавляются термины, специфические для НКО.
2. Функциональный тезаурус отражает роль документа в человеческой деятельности, бизнесе и отвечает на вопрос: "для чего этот документ?". Для этой цели используются словарь "Виды деятельности" (Deed) - отражает виды деятельности и предоставляемые услуги.
6.5.2.5. Размещение метаданных
Как отмечается в RDF, метаданные могут быть встроены в сам ресурс, например в HTML страницу (это самый простой подход для описания страниц), а могут хранится и обновляться независимо от ресурсов. Второй подход более универсален, т.к. в этом случае метаданные могут быть созданы для любого ресурса (например, для человека или организации). В случае размещения метаданных отдельно от ресурса сами метаданные предпочтительно хранить (и передавать) в формате XML. При этом максимально используются возможности модели RDF и обеспечивается свободный обмен информацией.
Обмен метаданными сводится к пересылке XML-файлов (т.е. текстовых файлов формата XML или просто ссылок на эти файлы), т.е. может быть полностью автоматизирован.
6.5.2.6. Практическая реализация
Пользователи системы документооборота должны иметь возможность удобно создавать описания своих документов, заполняя поля в простой форме и, где необходимо, выбирая значения из списков. Полученное описание будет передаваться вместе с электронным документом, а также храниться для самостоятельного использования.
Данный проект оказывает помощь также тем организациям, которые создают (или хотят создать) собственные информационные системы в соответствии с современными международными стандартами. Для предоставления всем заинтересованным разработчикам возможности использовать единый формат для обмена метаданными необходимо создать формальное (однозначное) описание, а также, дополнительные средства для упрощения разработки. Одним из самых сложных моментов является отслеживание прогресса в изменении международных стандартов и методик, на базе которых создаётся данное описание. Поэтому разрабатываемый формат обязательно должен предусматривать возможность своего развития.
В формат допускается включать описание любых существующих систем структурирования (классификаторов, рубрикаторов и т. д.) при условии правильного их формирования в КМПК – формате.
КМПК – формат имеет пять обязательных тэгов, а остальные являются факультативными.
КМПК - формат обеспечивает формирование классификатора. Классификатор обеспечивает функционирование каталога. Программная реализация осуществляется следующими языками:
1. Язык описания документа
2. Язык структурированных вопросов
3. Язык структурированных ответов
4. Язык согласования классификаторов - ввиду наличия большого числа подсистем ведомственного уровня, существует необходимость новые версии формата и классификатора рассылать из национального уровня на ведомственный, а также отправлять с ведомственного уровня предложения по вводу новых элементов структурирования по мере накопления новых знаний экспертам национального уровня.
Обязательные элементы (тэги) КМПК - формата:
1. Идентификатор записи. <uniqueid> Этот тэг содержит набор символов, однозначно идентифицирующий запись. Поле является обязательным для каждой записи. Не повторяется.
2. Данные общей обработки. <processingdata> Этот тэг содержит данные общей обработки.
3. Язык документа. <language> Этот тэг содержит данные о языке документа.
4. Заголовок документа. <title> Этот тэг содержит заголовок документа.
5. Автор документа. <author> Этот тэг содержит данные об авторе документа.
Количество факультативных тэгов определяется количеством обращающихся систем структурирования. Например, по данным Агентства по статистике РК в практике государственного управления РК используется большое количество различных классификаторов.
Ниже приведены некоторые из них:
1. Международные
• Международный коммуникативный формат UNIMARC
• Система национальных счетов СНС93
• Международная статистическая классификация болезней и проблем, связанных со здоровьем МКБ-10
• Перечень промышленной продукции ПРОДКОМ
• Международный классификатор изобретений МКИ
2. Межгосударственные
• Межгосударственный классификатор единиц измерения МКЕИ
• Межгосударственный рубрикатор научно–технической информации МРНТИ
• Универсальный десятичный классификатор УДК
• Десятичный классификатор Дьюи
• Классификатор товарной номенклатуры внешнеэкономической деятельности ТН ВЭД
3. Государственные
• Общий классификатор предприятий и организаций ОКПО
• Общий классификатор видов экономической деятельности ОКЭД
• Классификатор продукции по видам экономической деятельности КП ВЭД
• Классификатор занятий КЗ
• Классификатор специальностей начального и среднего профессионального образования
• Коды для обозначения валют и фондов
• Коды для обозначения наименований стран и их территориальных объединений
• Библиотечно – библиографическая классификация ББК
• Номенклатура специальностей научно – технических работников
4. Ведомственные
• Классификатор секторов экономики КСЭ
• Классификатор организационно-правовых норм хозяйствования КОПФ
• Классификатор форм и видов собственности КФС
• Классификатор размерности предприятий по численности занятых КРП
• Классификатор административно-территориальных объектов КАТО
• Система обозначений органов государственного и хозяйственного управления СООГУ
• Единый классификатор назначения платежей ЕКНП
• Номенклатура отраслей наук и специальностей
• Общий классификатор управленческой информации ОКУД
• Классификатор индивидуального потребления по целям КИПЦ
Кроме того, в каждой организации используется своя номенклатура дел и т. д.
При появлении новых тэгов в классификаторе должен проводиться пересчет взаимоотношений между ними. Таким образом, каждое добавление новых тэгов в классификатор вызывает изменение его версионности, которое учитывается в данных общей обработки.
Формой представления формата является язык разметки XML.
Идентификаторы реквизитов XML файла делятся на два вида:
• идентификатор поля реквизита - ключевое слово, за которым следует значение реквизита;
• идентификатор структуры - ключевое слово, предназначенное для описания взаимосвязанных полей в одной структуре, или объединения полей или структур, которые могут принимать множественные значения.
Поля могут содержать как коды, согласно утвержденным классификаторам, так и сами символьные значения реквизитов, а также даты в виде дд.мм.гггг.
Ниже идет перечисление идентификаторов с учетом их иерархичекой подчиненности. Обязательные идентификаторы выделены жирным курсивом, необязательные идентификаторы выделены курсивом, идентификатор структуры - жирным шрифтом.

Идентификатор
Назначение
mandatory_attributes Описание структуры пакета документов
uniqueid Идентификатор документа
language Язык документа
title Заголовок документа
processingdata Данные общей обработки
formatversion Поле номера версии коммуникативного формата
mode_document Поле вида документа
number Поле номера документа
date Поле даты документа
restriction Поле ограничения доступа к документу
recipient Описание структуры получателей пакета
name_recipient Поле имени организации получателя документа
higher_organ_r Поле наименования вышестоящей организации получателя документа
address_r Поле электронного адреса для доставки сообщений получателю документа
department_r Поле подразделения получателя документа
functionary_r Поле должности получателя документа
personal_name_r Поле фамилии, имени, отчества получателя документа
transaction Поле названия операции над документом (согласование, визирование, утверждение, исполнение и т.п.)
to_time Поле срока исполнения документа
author Описание структуры автора пакета
name_author Поле имени организации автора документа
higher_organ Поле наименования вышестоящей организации автора док-та
address Поле эл-го адреса для доставки сообщений автору документа
department Поле подразделения автора документа
functionary Поле должности автора документа
personal_name Поле фамилии, имени, отчества автора документа
6.5.2.7. Иерархическая структура коммуникативного формата
Данные в файле находятся в строго структурированном виде. Общий иерархический вид (объектная модель) выглядит следующим образом.

6.5.2.8. XML файл формата
Файл передачи пакета документов в XML-формате (DATA.xml) имеет следующий вид. Непосредственные значения реквизитов документа выделены курсивом.
<?xml version="1.0" encoding="UTF-8"?>
<uniqueid>уникальный идентификатор документа </uniqueid>
<language>язык документа</language>
<title>наименование документа</title>
<processingdata>
<formatversion>версия формата</formatversion>
<mode_document>вид документа</mode_document>
<number>номер документа</number>
<date>дата документа</date>
<restriction>ограничение доступа к документу</restriction>
<recipient>
<name_recipient>наименование организации получателя</name_recipient>
<higher_organ_r>вышестоящая организация</higher_organ_r>
<address_r>электронный адрес</address_r>
<department_r>подразделение организации получателя</department_r>
<functionary_r>должность</functionary_r>
<personal_name_r>Ф.И.О. получателя</personal_name_r>
<transaction>действия над документом</transaction>
<to_time>дата исполнения</to_time>
</recipient>

<recipient>
<name_recipient>наименование организации получателя</name_recipient>
<higher_organ_r>вышестоящая организация</higher_organ_r>
<address_r>электронный адрес</address_r>
<department_r>подразделение организации получателя</department_r>
<functionary_r>должность</functionary_r>
<personal_name_r>Ф.И.О. получателя</personal_name_r>
<transaction>действия над документом</transaction>
<to_time>дата исполнения</to_time>
</recipient>
</processingdata>
<author>
<name_author>наименование организации отправителя</name_author>
<higher_organ>вышестоящая организация</higher_organ>
<address>электронный адрес</address>
<department>подразделение организации отправителя</department>
<functionary>должность</functionary>
<personal_name>Ф.И.О. отправителя</personal_name>
</author>
</mandatory_attributes>
6.5.2.9. Требования к описанию стандарта КМПКФ
Общие требования к описанию
Описание КМПКФ должно быть представлено в виде DTD стандарта XML. Необходимым является наличие в описании КМПКФ идентификации кодировки документов, в том числе UNICODE, для обеспечения возможности обмена документами и метаданными на национальном и других языках.
Обеспечение участников ЕС ЭДО возможностью обмениваться документами в форматах отличных от КМПКФ
Обмен между участниками ЕС ЭДО в форматах отличных от КМПКФ может производиться, в случае, если участники обмена используют либо одинаковые системы автоматизации внутреннего документооборота, в которых уже заложен обмен данными с внешними корреспондентами, либо, если различные системы предусматривают единый формат обмена (отличный от КМПКФ) друг с другом. Для обеспечения работоспособности таких систем и целостности, передаваемых между данных, предлагается передавать данные в "их" формате. Но, так как при прохождении через НЦ ЕС ЭДО запись о документе должна быть распознана и зарегистрирована, то предлагается использовать специальные шаблоны преобразования (XSLT). XSLT должен обеспечить хранение правил распознавания данных формата локальной подсистемы и приведения их к КМПКФ. Такие шаблоны должны быть зарегистрированы в НЦ ЕС ЭДО самими участниками обмена использующими свои форматы.
Таким образом, если обмен документами между участниками ЕС ЭДО осуществляется в форматах отличных от КМПКФ, к ним предъявляются следующие требования:
1) В НЦ ЕС ЭДО должен быть зарегистрирован шаблон преобразования (XSLT) данного формата в КМПКФ.
2) Локальный формат должен содержать достаточный набор данных, чтобы обеспечить успешную конвертацию данных в КМПКФ
3) Получатель сообщения должен поддерживать данный формат взаимодействия.
Список корреспондентов, форматов взаимодействия, форматов поддерживаемых конкретными корреспондентами должен распространяться в качестве НСИ.
Поддержка актуальности стандарта КМПКФ
При утверждении стандарта КМПКФ должны быть сформированы правила по его изменению, в виде нормативно-правовой базы.
Поддержка актуальности стандарта КМПКФ необходима в случае изменения состава, характеристик элементов и правил составляющих КМПКФ.
Должны быть обеспечены:
1) Регистрация и рассылка обновленного DTD стандарта КМПКФ на все уровни ЕС ЭДО-Н
2) Регистрация шаблона преобразования (XSLT)
3) Обеспечение централизованного анализа/разбора записей об ЭД проходящих через НЦ ЕС ЭДО на предмет их соответствия актуальному КМПКФ

6.5.3. Описание требований к подсистемам
6.5.3.1. Универсальный интерфейс с системами документооборота ведомственного уровня
Назначение и задачи
Данная подсистема предназначена для использования на ведомственном уровне. На основе документов переданных из внутриведомственного документооборота формируется очередь для передачи документов в НЦ ЕС ЭДО. Для этого используется предлагаемый единый интерфейс, позволяющий приводить документы организаций к единому стандарту документа ЕСЭДО. После приведения к единому стандарту и постановки в очередь выполняется атрибутирование документа (автоматически, либо вручную, в зависимости от наличия всех необходимых атрибутов документа в системе ведомственного документооборота). Определяется маршрут обработки документа, после чего документ передается в НЦ ЕС ЭДО посредством СГДС.
Функции подсистемы
Приведение документа к единому стандарту ЕСЭДО-Н
Осуществляется посредством предлагаемого единого программного интерфейса.
Атрибутирование исходящих документов
Атрибутирование осуществляется с использованием классификаторов полученных из НЦ ЕС ЭДО.
Передача документов по маршруту
При формировании документа для передачи в НЦ ЕС ЭДО должен быть определен маршрут обработки документа.
Перечень шаблонов маршрута, а также определение стадий обработки для этих шаблонов распространяются в качестве НСИ. Пользователем может быть использованы следующие варианты маршрутов обработки документа:
Стандартный (типовой) шаблон маршрута обработки
Маршрут, скорректированный пользователем
Свободный маршрут, при котором маршрут делового процесса может изменяться участниками делового процесса в зависимости от конкретных условий, возникающих в процессе работы.
Построение маршрута осуществляется с помощью редактора маршрутных шаблонов обладающего следующими свойствами:
Определение маршрутов обработки документов с возможностью использования графического редактора и формирование списков рассылки документов
При определении задания можно назначить пользователю возможность переназначения пришедшего задания (например, в случае неизвестного заранее исполнителя действия задание назначается делопроизводителю или начальнику отдела, а он в свою очередь переназначает задание подчиненному)
Возможность использования в ходе создания технологического процесса в качестве основы проектируемого маршрута частей имеющихся типовых маршрутов.
Возможность определения последовательной и параллельной маршрутизации документов
Ручной ввод документов в ЕСЭДО-Н
Предназначен для предоставления возможности регистрации Входящих и Исходящих документов для участников ЕСЭДО-Н, не имеющих системы автоматизирующей внутриведомственный документооборот.
Выполняемые функции:
Учет и регистрация ВХОДЯЩЕЙ в организацию корреспонденции.
Учет и регистрация ИСХОДЯЩЕЙ в организацию корреспонденции.
Подготовка документов к сканированию.
Сканирование документов.
Распознавание отсканированной информации, в том числе:
Автоматическое определение различных форм;
Оптическое распознавание символов OCR;
Интеллектуальное распознавание символов ICR;
Оптическое распознавание метки OMR;
Распознавание штриховых кодов;
Очистка изображения
Проверка результатов распознавания и ручное индексирование.
Подтверждение индексных значений.
Полнотекстовое распознавание документов.
Контроль качества и повторное сканирование.
Автоматическое приведение документа к единому стандарту ЕСЭДО-Н
Атрибутирование документа с использованием НСИ, полученной из НЦ ЕС ЭДО
Формирование очередей документов на передачу в НЦ ЕС ЭДО
Требования к реализации
Использование для передачи документов единого стандарта сообщений в формате XML
Использование СГДС в качестве транспорта для передачи данных в НЦ ЕС ЭДО
6.5.3.2. Подсистема контроля исполнительской деятельности
Назначение и задачи
Данная подсистема предназначена для использования на государственном и ведомственном уровне. Подсистема позволяет получать сводные и агрегированные данные об исполнительской дисциплине в различных разрезах (за период, по исполнителям, и т.д.)
Функции подсистемы
Контроль над прохождением ЭД инициатором и контролером процесса обработки ЭД.
Контроль своевременного исполнения ЭД, содержащих поручения, с возможностью автоматического оповещения.
Корректировка сроков исполнения ЭД, стоящих на контроле, с указанием ЭД, являющимся основанием для корректировки данных сроков
Формирование предупредительных сводок по исполнению ЭД
Формирование сводок просроченных и неисполненных ЭД

6.5.3.3. Подсистема работы с нормативно-справочной информацией (далее - НСИ) и ведение профиля участника ЕСЭДО-Н
Назначение и задачи
Данная функциональная возможность предназначена для ведения НСИ (всех централизованных справочников, классификаторов, настроек, необходимых для функционирования системы) в НЦ ЕС ЭДО и предоставление их участникам ЕСЭДО-Н.
Принципы ведения НСИ
На ведомственном уровне должно быть предусмотрено использование НСИ в режиме «только на чтение», чтобы гарантировать целостность данных, их непротиворечивость и избежать конфликтов данных.
Изменения данных НСИ происходит по двум сценариям:
Централизованное изменение данных НСИ в НЦ ЕС ЭДО, с последующей рассылкой.
Инициирование изменения НСИ на ведомственном уровне, в виде передачи сообщения запроса на изменение в НЦ ЕС ЭДО, с последующим рассмотрением необходимых изменений и принятия их на уровне НЦ ЕС ЭДО.
Требования к реализации
Ведение НСИ должно соответствовать следующим требованиям:
Использование единых стандартов сообщений
Использование СГДС в качестве используемого транспорта для передачи
Отслеживание истории изменения НСИ на уровне НЦ ЕС ЭДО
6.5.3.4. Подсистема запроса документов и данных из БД НЦ ЕС ЭДО
Назначение и задачи
Данная подсистема предназначена для использования на ведомственном уровне. Каждая организация, как участник ЕСЭДО-Н может запрашивать из централизованной БД НЦ ЕС ЭДО всю необходимую информацию, как структурированную, так и содержание документов, при условии их наличия. Наличие структурированной информации о документах циркулирующих в рамках ЕСЭДО-Н является обязательным фактом, в то время как наличие контекста самого документа в БД определяет его владелец, определяющий политику хранения своего документа. Иными словами ведомство - владелец документа может инициировать или наоборот, запретить сохранение документа в БД НЦ ЕС ЭДО. Информация об этом должна быть заложена в едином стандарте документов ЕСЭДО-Н. Основной задачей данной подсистемы является предоставление организациям возможности делать запросы по любой структурированной и неструктурированной информации согласно прав доступа и получать запрошенные данные.
Функции подсистемы
Редактирование запросов
Получения результатов и преобразование их в распространенные форматы данных (XML, HTML)
6.5.3.5. Подсистема по передаче документов в ведомственные архивы
Назначение и задачи
Данная подсистема предназначена для использования на ведомственном уровне. Каждая организация, как участник ЕСЭДО-Н может инициировать перевод хранящихся в БД НЦ ЕС ЭДО документов в свой ведомственный архив.
Функции подсистемы
Запрос необходимых документов по различным критериям (период создания-хранения, тип документа, корреспондент, и т.п.)
Инициирование перевода отмеченных для перевода документов в ведомственный архив. Оповещение о факте перевода.
Инициирование физического удаления документов из БД НЦ ЕС ЭДО после их перевода в ведомственный архив.
6.5.3.6. Подсистема взаимодействия с Центром Сертификации
Назначение и задачи
Данная подсистема предназначена для предоставления взаимодействующим участникам ЕСЭДО как на уровне НЦ ЕСЭДО, так и на ведомственном уровне возможности использовать механизмы аутентификации и шифрования данных, предоставляемые внешними средствами криптографической защиты информации и Центрами сертификации.
Функции подсистемы.
Контроль доступа.
Контроль доступа с аутентификацией пользователя и его регистрационной информации с помощью внешних средств криптографической защиты информации и Центра сертификации.
Обеспечение конфиденциальности.
Задействование системой внешних средств криптографической защиты информации и управления ключами с целью обеспечения конфиденциальности информации.»
6.5.3.7. Подсистема публикации и доступа к опубликованным документам НЦ ЕС ЭДО
Назначение и задачи
Основная задача данной подсистемы – дать публичный доступ широкой общественности к официальным документам органов государственного управления РК и обеспечить обратную связь с населением республики; общественными, государственными и коммерческими организациями. Данная подсистема является «информационной витриной» государственных органов власти РК.
Функции подсистемы
Создание единого шлюза с выполнением всех требований по защите информации от несанкционированного доступа извне, с использованием аппаратно-программных средств ( FireWall, серверов безопасности и т.д.).
Поддержка централизованного размещения государственными органами РК информации, находящейся в НЦ ЕС ЭДО, для публичного пользования.
Обеспечение защищенного доступа к публичной информации находящейся в НЦ ЕС ЭДО, различных групп пользователей через WEB-интерфейс с поддержки профилей (аутентификация, персонификация).
Требования к реализации функциональных возможностей
Доступность информации опубликованной для общего пользования в НЦ ЕС ЭДО через информационно – телекоммуникационные сети общего пользования с преимущественной ориентацией на ИНТЕРНЕТ. В качестве программного обеспечения, необходимого для пользователей, должен выступать Интернет-браузер. Для увеличения функциональных возможностей клиентского программного обеспечения допустимо использование подключаемых модулей, в виде плагинов или ActiveX компонентов, либо Java апплетов. Аутентификация пользователей с использованием протоколов TLS, SSL
6.5.3.8. Подсистема «Транспортная среда»
Основное назначение транспортной среды – обеспечение надежной защищенной передачи данных между остальными подсистемами ЕСЭДО РК. Для этого эта подсистема должна обеспечивать:
1. Удаленный телекоммуникационный доступ к вычислительным ресурсам серверов с использованием протокола TCP/IP из всех региональных узлов.
2. Обмен данными между подсистемами ЕСЭДО РК вне зависимости от содержания передаваемой информации.
3. Гарантированную доставку данных в течение заданного интервала времени (с уведомлением о нарушении сроков доставки информации).
4. Защиту информации от несанкционированного доступа в момент передачи, сохранность информации от разрушения и живучесть транспортной системы.
5. Решение задач администрирования сети и диагностирования динамики функционирования телекоммуникационной системы.
6. Обмен ЭД между подсистемами ведомственного и национального уровня ЕСЭДО РК производится на основании метаданных ЭД в КМПКФ.


Назначение
Программно-технической реализацией транспортной среды служит система гарантированной доставки сообщений (далее – СГДС), которая должна обеспечивать гарантированную и защищенную доставку данных в виде сообщений между всеми участниками ЕСЭДО-Н.
Основные задачи
интеграция приложений в распределенной гетерогенной среде;
организация взаимодействия приложений, работа которых разделена во времени;
сложные распределенные и/или распараллеленные процессы обработки;
задачи гарантированной доставки данных;
поддержка мобильных клиентов
Элементы СГДС: Как устроена система очередей сообщений.
Основными элементами системы являются:
сообщения, которые прикладные программы посылают друг другу;
очереди, где хранятся сообщения;
менеджеры очередей, которые управляют очередями и обработкой сообщений;
каналы передачи сообщений, которые связывают менеджеры между собой.
Сообщения СГДС представляют собой структуру данных, состоящую из заголовка сообщения и прикладных данных. Заголовок должен содержать контрольную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда надо передавать сообщение.
Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. Для приложений, функционирующих под управлением различных ОС и оперирующих различными кодовыми страницами, должны поддерживаться методы конвертации данных.
Очередь сообщений - основное место хранения и обработки сообщений. Физическое управление очередями должно быть полностью скрыто от прикладных программ. Приложения могут получить доступ к очередям только через интерфейс.
Менеджер очередей должен отвечать за управление очередями сообщений и прием вывозов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы должна быть своя.
Требования к СГДС
СГДС должна предоставлять программе-отправителю одной организации (являющейся участником ЕСЭДО-Н) сервис для постановки в очередь и последующей доставки их программе-адресату в другой организации (тоже участнику ЕСЭДО-Н).
Прикладная программа должна передавать свое сообщение серверу-менеджеру очередей, который записывает сообщение в локальную очередь, а затем передает его по сети другому менеджеру очередей, содержащему очередь-адресат. Программа-адресат обращается к целевой очереди и получает доступ к сообщению. Система очередей сообщений должна предоставлять асинхронный метод взаимодействия программ, не требующий установки между ними прямой связи. При этом должно гарантироваться, что передаваемое сообщение не будет потеряно или получено дважды.
Системы очередей сообщений должны позволять программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения должны быть изолированы друг от друга транспортным слоем, состоящим из менеджеров очередей, берущих на себя задачи обеспечения коммуникаций. С помощью очередей сообщений могут быть реализованы как традиционные модели взаимодействия программ (клиент-сервер) так и модели, которые реализуются только при помощи сервиса сообщений.
Архитектура клиент/сервер. Запросы клиента передаются в виде сообщений в серверную очередь. После обработки запроса приложение-сервер, отправляет ответ в виде нового сообщения в очередь, указанную клиентом в сообщении-запросе.
Асинхронное взаимодействие. При использовании очередей сообщений, не должно быть необходимости, чтобы взаимодействующие приложения были активны одновременно. Программа может отправить сообщение другому приложению, которое обработает его, когда сочтет нужным. Отправив сообщение, программа должна иметь возможность не ожидать ответа, а продолжать выполнение других задач.
Запуск программы. Сообщение, посланное одной прикладной программой, может инициировать старт другого приложения. В таком случае по команде программы-монитора, приложение-адресат запускается и обрабатывает сообщение.
Архитектура публикация-подписка
Прикладные программы-публикаторы посылают свою информацию с указанием темы в виде сообщения менеджеру очередей. Другие приложения - подписчики присылают заявки на информацию по темам. Присланные публикации распределяются между подписчиками через очереди сообщений специальной программой - брокером в соответствии с темами публикаций.
Функции и модели взаимодействия программ ЕСЭДО-Н посредством СГДС
Системы очередей сообщений позволяют программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения изолируются друг от друга транспортным слоем, состоящим из менеджеров очередей, берущих на себя задачи обеспечения коммуникаций. С помощью очередей сообщений могут быть реализованы как традиционные модели взаимодействия программ (клиент-сервер) так и модели, которые реализуются только при помощи сервиса сообщений.
1. Адресация и маршрутизация сообщений: Как сообщение должно находить очередь назначения в распределенной среде.
Система СГДС отправляет сообщения различным адресатам, пользуясь информацией из заголовка каждого сообщения: имя менеджера очередей для идентификации узла СГДС и имя очереди для идентификации самой очереди.
2. Транзакционные свойства СГДС: Обеспечение целостности данных и синхронизация изменений.
СГДС - это транзакционное программное средство, которое может объединять группу операций по посылке-приему сообщений в единую транзакцию. Прикладная программа должна помечать часть своих получаемых и отравляемых сообщений специальной опцией - участвующие в транзакции.
3. Триггерные возможности СГДС: Активизация программ обработки.
Асинхронный характер работы системы очередей сообщений требует специального механизма внешней активизации для старта прикладных и системных компонентов.
4. Администрирование СГДС: Управление распределенной системой очередей.
Распределенная гетерогенная система, такая как ЕСЭДО-Н требует особенного внимания к вопросам удаленного администрирования. СГДС в этом аспекте должна предоставлять ряд интерфейсов и достаточное количество утилит для администрирования и конфигурации, включая администрирование очередей, каналов сообщений, безопасности.
5. Средства безопасности: Обеспечение необходимой защиты передаваемых данных.
Для обеспечения безопасности при использовании приложениями системы очередей сообщений необходимо знать, какое приложение послало то или иное сообщение, контролировать, кто получает данное сообщение, обеспечить идентификацию удаленных менеджеров, а также контролировать выполнение административных команд.
6. Доступ в Internet.
В составе модулей СГДС должен быть предусмотрен модуль, представляющий собой шлюз между Web сервером и системой СГДС, преобразующий запросы пользователей броузеров в сообщения СГДС с последующей отправкой сообщений приложениям и преобразующий полученные обратно сообщения в данные для форм HTML.
7. Открытость.
При создании приложений, должна быть обеспечена поддержка интерфейса для основных распространенных языков/сред программирования, таких как С++, Delphi, PowerBuilder, VisualBasic.
8. Поддержка транспортных протоколов
На транспортном уровне должна быть обеспечена поддержка протоколов: TCP/IP, NetBios, IPX/SPX.
9. Многоплатформенность
Менеджеры очередей должны поддерживать:
OS/390, MVS, VSE/ESA, OS/400, OS/2, OpenVMS VAX, Digital Unix, AIX, HP-UX, SunOS, Sun Solaris, SCO UNIX, UnixWare, AT&T GIS UNIX, DC/OSx, Windows NT/95/3.1.
Клиенты СГДС: Windows, DOS, Java, MacOS, Linux.
10. Масштабируемость
СГДС должна предоставлять возможность соединенния в кластеры нескольких менеджеров очередей (совместной работы нескольких менеджеров очередей).
6.5.3.9. Подсистема «Аналитика»
Назначение и задачи
Данная подсистема может быть использована на любом уровне ЕСЭДО-Н. Каждая организация, как участник ЕСЭДО-Н может запускать на выполнение любые параметризованные аналитические отчеты, зарегистрированные в НЦ ЕС ЭДО. Основной задачей данной подсистемы является предоставление организациям, органам государственного управления возможности получать аналитическую отчетность по любым данным согласно прав доступа.
Функции подсистемы
Выбор необходимого аналитического отчета из списка
Параметризация аналитического отчета и инициирование его исполнения в НЦ ЕС ЭДО.
Получение аналитических результатов и сохранение их в распространенных форматах (XML, HTML)
6.5.3.10. Требования к способам и средствам связи для информационного обмена между компонентами системы
При передаче данных (обмене данными) должно быть реализовано:
обеспечение гарантированной электронной доставки сообщений;
защита данных от несанкционированного доступа, как при передаче их по каналам связи, так и посредством произвольных носителей информации;
идентификация и учет всей передаваемой информации;
передача данных между системами, работающими на различных аппаратных и программных платформах;
Для передачи данных и информации между уровнями и участниками Системы используется СГДС. Форматы и процедуры доставки гарантированной доставки сообщений будут согласовываться на этапе выполнения работ.

7. ТРЕБОВАНИЯ К БАЗОВОМУ ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
Уровень НЦ ЕС ЭДО:
Операционная система
Системное программное обеспечение серверов баз данных и серверов приложений принадлежать классу UNIX-систем, имеющих конкретную реализацию в зависимости от серверной платформы, имеющих поддержку реализаций серверов по кластерной технологии.
СУБД
Для хранения структурированной информации и оптимизации поисковой и аналитической информации по метаданным документов необходимо предусмотреть использование промышленных СУБД типа Oracle, Informix.
Программы резервного хранения информации
Для создания масштабируемого хранилища документов предпочтительно использование специализированных продуктов ведущих мировых вендоров.
Ведомственный уровень:
Операционная система
Операционная система должна иметь интуитивно-понятный и привычный для большинства пользователей интерфейс.
В качестве клиентских операционных систем выбраны Windows 2000/ХР.
Internet-browser
Должен быть выбран Microsoft Internet Explorer 5/6, т.к. это комплексное решение, обеспечивающее полную поддержку Internet и Intranet технологий в прикладных системах. Он поддерживает большинство существующих стандартов и модификаций HTML.
Средства делопроизводства
Программные средства делопроизводства офиса являются стандартными средствами создания документов. Средства делопроизводства офиса могут быть использованы для визуализации и дополнительной обработки информации, а также организации групповой работы пользователей. Также эти средства должны поддерживать технологии ODBC, ODMA.
В качестве базового программного пакета автоматизации делопроизводства офиса выбран пакет MS Office ХР, включающий следующие программные средства:
текстовый процессор Microsoft Word 2002;
табличный процессор Microsoft Excel 2002.
Средства антивирусной защиты ПО и данных должны иметь механизмы эвристического анализа, резидентного сканирования, автоматического обновления антивирусных баз из внешнего источника.

8. ПОРЯДОК ПРИЕМКИ И ВВОДА В ЭКСПЛУАТАЦИЮ СИСТЕМЫ
Предварительное тестирование системы;
Тестирование системы;
Опытная эксплуатация;
Сбор замечаний по программному комплексу и проведение доработки;
Сдача программного комплекса ЕСЭДО-Н РК в промышленную эксплуатацию.

8.1. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Для ввода ЕСЭДО-Н в действие необходимо разработать и передать Заказчику рекомендации по определению правового статуса НЦ ЕСЭДО и ЕСЭДО РК вцелом. Документ должен будет согласован с уполномоченными органами и утвержден как нормативно-правовая база (возможно со статусом временная ) для организации НЦ ЕСЭДО до момента ввода ЕСЭДО-Н в опытную эксплуатацию.
При подготовке объекта автоматизации должны быть выполнены следующие мероприятия:
Разработка (конкретизация) плана работ по внедрению Национального уровня ЕСЭДО-Н РК;
Подготовка и обучение персонала НЦ ЕС ЭДО;
Подготовка и обучение пользователей ведомств;
Подготовка ЛВС к инсталляции программного комплекса ЕСЭДО-Н;
Подготовка сервера к инсталляции ЕСЭДО-Н
Инсталляция серверной части программного комплекса ЕСЭДО-Н на сервер;
Инсталляция клиентской части программного комплекса ЕСЭДО-Н на рабочие станции;
Настройка и параметризация ЕСЭДО-Н;
Сдача программного комплекса ЕСЭДО-Н в опытную эксплуатацию.

8.2. Порядок контроля и приемки ЕСЭДО-Н
Предварительное тестирование системы;
Тестирование системы;
Опытная эксплуатация;
Сбор замечаний по программному комплексу и проведение доработки;
Сдача программного комплекса ЕСЭДО-Н в промышленную эксплуатацию.
Перечень участвующих предприятий и организаций:
Заказчик: Комитет по связи и информатизации Министерство транспорта и коммуникаций Республики Казахстан.
Объект внедрения – будут определены Заказчиком в ходе реализации Проекта.
Исполнитель – Поставщик ЕСЭДО-Н
Место проведения - на объекте внедрения.
Сроки проведения опытной эксплуатации – определяется дополнительным соглашением сторон.

9. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
9.1. Перечень подлежащих разработке комплектов и видов документов
В состав документов должны быть включены следующие основные документы:
Пояснительная записка техно-рабочего проекта;
Общее описание системы;
Программа и методика испытаний;
Руководство администратора;
Руководство пользователя.
Технологические инструкции.

10. Потенциальный поставщик должен разработать пакет проектов нормативных правовых актов для нормального функционирования ЕС ЭДО национального уровня.

1. Разработка проектов нормативных правовых акты по удостоверяющему центру, регистрационному свидетельству и открытым и закрытым ключам электронной цифровой подписи, в соответствии с Законом «Об электронном документе и электронной цифровой подписи» (до 10 июня 2003 года)
2. Раз
Адик
Гость




[4402] Чт Май 08, 2003 06:58
Вопросы к спецификации
Вообще-то за спецификацию ТАКОГО качества надо составителя привлечь куда следует!!!!!
Вопрос 1.
В Технической Спецификации приведены «Перспективы развития Системы» (раздел 6.3). Однако далее приведенные в этом разделе подсистемы отсутствуют. Следует ли при подготовке конкурсной заявки описывать реализацию требований, приведенных в указанном разделе?

Вопрос 2.
В Технической Спецификации в разделе 4 «Назначение и цель разработки» указано: «Формирование Национального фонда электронных документов». Однако далее нигде далее это положение не раскрыто. Дайте, пожалуйста, расширенные требования, которые позволили бы осуществить разработку вышеуказанного Фонда.

Вопрос 3.
В Технической Спецификации в разделе 6.4 «Требования к архитектуре системы» указано, что «ЕСЭДО-Н должна состоять из подсистем:
Интерфейса с системами документооборота и делопроизводства ведомственного уровня…».
Однако ни в Техническом Задании на 1 очередь (далее ТЗ-1), ни в Техническом Задании на 2 очередь (далее ТЗ-2) такой интерфейс не предусмотрен и требования к нему не предъявляются. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 4.
В Технической Спецификации в разделе «Назначение и задачи НЦ ЕС ЭДО» указано, что «Основным назначением НЦ ЕС ЭДО является ведение нормативно-справочной базы ЕС ЭДО РК, организации межведомственного обмена электронными документами, диспетчеризация и протоколирование сообщений, хранение ЭД на срочной основе в собственном хранилище, управление доступом к Системе, обеспечение контроля достоверности электронных цифровых ключей». Однако ни в ТЗ-1, ни в ТЗ-2 НЦ не предусмотрен и требования к нему не предъявляются. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2 в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2.

Вопрос 5.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
Ведение общих справочников (перечень государственных органов, территориальных делений, руководящего состава ГО и т.д.);
Ведение специальных справочников и классификаторов ЕСЭДО-Н (номенклатура дел, атрибуты ЭД, уровни секретности, статусы ЭД и т.д.)…»
В ТЗ-2 в разделе 9.5 «Функции информационно – справочной работы» записано «Поддержка каталога системы.
Поддержка и согласование классификаторов системы»
Следует ли понимать под термином «справочник» какую-либо систему структурирования, входящую в вышеуказанные позиции ТЗ-2? Если да, то почему частные термины употребляются вместе с обобщенными? Можно ли уточнить, пожалуйста, данную формулировку Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2?

Вопрос 6.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
…Анализ и сохранение атрибутов ЭД в картотеке НЦ ЕСЭДО….
…Обработка запросов к картотеке ЭД…»
Следует ли понимать под словом «картотека» термин «каталог» согласно ТЗ-1, ТЗ-2? Можно ли уточнить, пожалуйста, данную формулировку Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2?

Вопрос 7.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
…Ведение профиля участника ЕСЭДО-Н»
Что подразумевается под словом профиль? Можно ли уточнить, пожалуйста, данную формулировку Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2?

Вопрос 8.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
…Ведение единой, централизованной БД ЕСЭДО-Н»
В этой БД должны храниться ЭД целиком в КМПКФ или допускается раздельное хранение метаданных и контента ЭД? Можно ли уточнить, пожалуйста, данную формулировку Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2?

Вопрос 9.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
… Отслеживание связей между документами»
Поясните, пожалуйста, что подразумевается под данной формулировкой Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2.

Вопрос 10.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
… Поддержка целостности, отсутствие избыточности и непротиворечивости информации»
Поясните, пожалуйста, что подразумевается под данной формулировкой Технической Спецификации в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2. Какими средствами в отсутствие подсистемы управления знаниями должно быть обеспечена проверка указанных свойств информации для того, чтобы обеспечить требования раздела 6.5.2.5 о полной автоматизации работы с xml - файлами? Или это требование должно быть описано как будущие возможности системы, не входящие в реализацию в этом конкурсе?

Вопрос 11.
В Технической Спецификации записано, что «НЦ ЕС ЭДО должна выполнять следующие задачи:
Ведение нормативно-справочной базы:
…Мониторинг передачи данных»
Поясните, пожалуйста, каким образом должен осуществляться указанный мониторинг в случае, если понятие НЦ не будет исключено как отсутствующее в ТЗ-1, ТЗ-2.

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

Вопрос 13.
В Технической Спецификации в разделе 6.5.2.1 записано:
«Реализация КМПКФ должна предполагать наличие как обязательных, так и факультативных тэгов» (Цитата № 1) А в разделе 6.5.2.2 «Принципы построения формата» указано: «Разработка КМПК-формата должна придерживаться следующих принципов:
1. Метки полей определяют поле в двух аспектах:
1.1. типом последовательности символов записанных в поле (например, имя лица)
1.2. функцией, выполняемой последовательностью символов в записи (например, ссылки). Эти аспекты фиксируются путем присвоения специальных значений позициям символов в метках полей. Метки могут быть цифровыми и буквенными. В первую очередь при формировании меток используются цифры. В случае необходимости набор цифровых символов может быть расширен за счет использования букв (предпочтительно строчных).
2. Значения индикаторов зависят от метки поля, но используются, по возможности, единообразно во всех полях. Индикаторы могут быть как цифровыми, так и буквенными. В первую очередь при формировании индикаторов используются цифры. В случае необходимости набор цифровых символов для образования индикаторов может быть расширен за счет использования букв (предпочтительно строчных).
3. Значения идентификаторов подполей зависят от метки поля, но, по возможности, одинаковые по смыслу элементы данных определены одними и теми же идентификаторами. Идентификаторы подполей могут быть цифровыми и буквенными. В первую очередь при формировании идентификаторов используются буквы (предпочтительно строчные). В случае необходимости набор буквенных символов может быть расширен за счет использования цифр. Значения, приписываемые идентификаторам подполей, служат главным образом для определения содержания подполя, а не для упорядочивания элементов данных. Порядок следования идентификаторов зависит от порядка следования элементов данных в записи и заранее не определяется.
4. Поля авторитетной / нормативной записи должны рассматриваться как изначально относящиеся к более общим категориям информации, таким как "Заголовок записи", "Формирование (трассировка) ссылки "см. также" и т.д. В машиночитаемой записи первоначальная группировка полей будет выполняться в соответствии с этими основными категориями.» (Цитата №2).
Поясните, пожалуйста, каким образом следует при разработке КМПКФ выполнить одновременно требования цитаты № 1 и цитаты № 2, противоречащих и полностью исключающих друг друга, т. к. цитата № 1 содержит термин «тэг», относящийся к XML, а цитата № 2 содержит принципы построения блочных систем структурирования (например UNIMARC, EDIFACT и т. п.), которые не могут быть реализованы согласно требований разделов 6.5.2.6 – 6.5.2.7.
Содержание цитаты № 2, таким образом, полностью противоречит содержанию последующих разделов 6.5.2.6 – 6.5.2.7.
Можно ли уточнить, пожалуйста, формулировку раздела 6.5.2.2 с целью ликвидации противоречий с разделами 6.5.2.1, 6.5.2.6 – 6.5.2.7?

Вопрос 14.
В Технической Спецификации в разделе 6.5.2.1 указано: «Также он предназначен стать информационной основой для создания общей, сводной картотеки о документах в национальном масштабе и, как следствие, качественно улучшить любые делопроизводственные операции, обеспечить возможность накопления унифицированных данных о документообороте. Из этих требований, на основе мирового опыта должна быть разработана концепция формата, правила его формирования. Формат не должен быть статичным, должны быть разработаны и заложены правила, которые позволят в дальнейшем изменять, улучшать его без радикальных изменений системы в целом». Объясните, пожалуйста, значение слова «картотека» здесь. Подразумевается ли под ним каталог ЕСЭДО РК? Можно ли уточнить вышеуказанную формулировку?

Вопрос 15.
В Технической Спецификации в разделе 6.5.2.6 указано: «В формат допускается включать описание любых существующих систем структурирования (классификаторов, рубрикаторов и т. д.) при условии правильного их формирования в КМПК – формате.
КМПК – формат имеет пять обязательных тэгов, а остальные являются факультативными.
КМПК - формат обеспечивает формирование классификатора. Классификатор обеспечивает функционирование каталога. Программная реализация осуществляется следующими языками:
1. Язык описания документа
2. Язык структурированных вопросов
3. Язык структурированных ответов
4. Язык согласования классификаторов - ввиду наличия большого числа подсистем ведомственного уровня, существует необходимость новые версии формата и классификатора рассылать из национального уровня на ведомственный, а также отправлять с ведомственного уровня предложения по вводу новых элементов структурирования по мере накопления новых знаний экспертам национального уровня». Дайте, пожалуйста, подробные требования (концепция, семиотика, семантика, тезаурус, принципы построения) к вышеуказанным языкам, поскольку разработка языков невозможна без запрашиваемой лингвистической подготовки.

Вопрос 16.
В Технической Спецификации в разделе 6.5.2.6 указано: «Количество факультативных тэгов определяется количеством обращающихся систем структурирования. Например, по данным Агентства по статистике РК в практике государственного управления РК используется большое количество различных классификаторов. Ниже приведены некоторые из них». Объясните, пожалуйста, какие конкретно системы структурирования должны быть включены в состав КМПКФ на момент сдачи проекта.

Вопрос 17.
В Технической Спецификации в разделе 6.5.2.6 указано: «Количество факультативных тэгов определяется количеством обращающихся систем структурирования. Например, по данным Агентства по статистике РК в практике государственного управления РК используется большое количество различных классификаторов. Ниже приведены некоторые из них». Объясните, пожалуйста, каким образом автоматизировать процесс включения их в КМПКФ без функций управления знаниями, если в ответе на вопрос 15 будет дан ответ о необходимости сдачи КМПКФ с возможностью подключения любой системы структурирования в ходе приемочных испытаний?

Вопрос 18.
Следует ли при включении однотипных систем структурирования (например, номенклатур дел) в КМПКФ осуществлять построение метасистемы во избежание «распухания» файла ЭД и неприемлемых затрат вычислительных ресурсов на его обработку в случае тысяч и десятков тысяч систем структурирования? Если да, то укажите требования к построению метаклассификатора однотипных классификаторов (концепция, принципы построения и обработки).
Вопрос 19.
В Технической Спецификации в разделе 6.5.2.6 указано: «При появлении новых тэгов в классификаторе должен проводиться пересчет взаимоотношений между ними». Укажите, пожалуйста, расширенные требования к указанному пересчету. Каким образом можно устанавливать взаимоотношения между тэгами без функционала управления знаниями? Приведите, пожалуйста, пояснения, как должны определяться соотношения между тэгами разных систем структурирования, входящих в КМПКФ?

Вопрос 20.
В Технической Спецификации в разделе 6.5.2.6 указано: «Ниже идет перечисление идентификаторов». Дайте, пожалуйста, подробную расшифровку структуры идентификатора «processingdata – данные общей обработки».

Вопрос 21.
В Технической Спецификации в разделе 6.5.2.8 указано: «Файл передачи пакета документов в XML – формате (DATA.xml) имеет следующий вид». Объясните, пожалуйста, основные отличия файла DATA.xml, который необходимо будет предъявить исполнителю в ходе приемки КМПКФ, от предъявленного в Технической Спецификации.

Вопрос 22.
В Технической Спецификации в разделе 6.5.2.9 указано: «Обеспечение участников ЕСЭДО возможностью обмениваться документами в форматах, отличных от КМПКФ». Данный раздел противоречит требованию раздела ТЗ-2 9.3.5 «Общие функции обработки ЭД в ЕСЭДО РК» - «Присвоение метаданных согласно системе классификации на основе КМПКФ». Можно ли удалить вышеуказанный раздел Технической Спецификации для преодоления противоречий между ней и ТЗ-2? Если нет, то должно ли это требование учитываться при разработке?

Вопрос 23.
В Технической Спецификации в разделе 6.5.2.9 указано: «Поддержка актуальности стандарта КМПКФ.
При утверждении стандарта КМПКФ должны быть сформированы правила по его изменению, в виде нормативно-правовой базы».
Объясните, пожалуйста, должен ли исполнитель разрабатывать стандарт КМПКФ? Если да, то должен ли исполнитель обладать необходимыми разрешениями, позволяющими ему разрабатывать стандарты?
Должен ли исполнитель утверждать стандарт КМПКФ? Если да, то объясните, пожалуйста, какие полномочия будут делегированы исполнителю для проведения исполнителем процедуры утверждения стандарта.
Объясните, пожалуйста, процедуру разработки исполнителем правил по его изменению, в виде нормативно – правовой базы. Какие полномочия будут переданы исполнителю для реализации этого требования?

Вопрос 24.
Что подразумевается под (раздел 6.2.5.9) регистрацией шаблона преобразования (XSLT)? Указанный шаблон не является ЭД ЕСЭДО?

Вопрос 25.
Можно ли требование (раздел 6.2.5.9) «Обеспечение централизованного анализа/разбора записей об ЭД проходящих через НЦ ЕС ЭДО на предмет их соответствия актуальному КМПКФ» трактовать как обработку в метаданных ЭД поля formatversion (раздел 6.5.2.Cool? Объясните, пожалуйста, что подразумевается под «актуальным КМПКФ»?

Вопрос 26.
В требованиях на «Универсальный интерфейс с системами документооборота ведомственного уровня» (раздел 6.5.3.1) записано «Данная подсистема предназначена для использования на ведомственном уровне», что противоречит Введению и разделу 1 Технической Спецификации, в которых явно указывается, что разработка предназначена для использования на национальном уровне. Является ли разработка такого интерфейса обязательным требованием?
Если да, то приведите достаточные для разработки данные о подсистемах ведомственного уровня ЕСЭДО, для которых надо разработать указанный интерфейс.

Вопрос 27.
Следует ли требование «Приведение документа к единому стандарту ЕСЭДО-Н» (раздел 6.5.3.1) понимать как формирование ЭД в соответствии с КМПКФ?.

Вопрос 28.
Следует ли требование «Атрибутирование осуществляется с использованием классификаторов» (раздел 6.5.3.1) понимать как необходимость разработки АРМ атрибутирования документоведа, автоматически классифицирующее ЭД в соответствии с КМПКФ?
Если да, то укажите список классификаторов, по которым необходимо осуществить автоматическую классификацию либо метод классификации, позволяющий это сделать.
Если нет, то укажите принципы, по которым должно осуществляться такое атрибутирование.

Вопрос 29.
В требовании «Передача документов по маршруту» (раздел 6.5.3.1) просим указать, каким образом и где «маршрут» описывается. Укажите, пожалуйста, требования к фиксации прохождения ЭД по маршруту. Если понятие «маршрут» содержится в КМПКФ, то входит ли он в состав какого – либо обязательного идентификатора? Если да, то в какой?

Вопрос 30.
В требовании «документ передается … посредством СГДС» (раздел 6.5.3.1) следует ли понимать использование разработанной и сданной ЗАО НИТ в КСИ СГДС? Если да, то опишите, пожалуйста, процедуру взаимодействия ЕСЭДО-Н с СГДС.
Если СГДС входит в состав указанного «интерфейса», то каким образом подсистема «Транспортная среда» (раздел 6.5.3.Cool выполняет функцию «Гарантированную доставку данных в течение заданного интервала времени (с уведомлением о нарушении сроков доставки информации)».
Можно ли внести корректировки в Техническую Спецификацию с тем, чтобы ликвидировать это противоречие?

Вопрос 31.
Укажите, пожалуйста, реквизиты стандарта, о котором указывается в требовании «Использование для передачи документов единого стандарта сообщений в формате XML» (раздел 6.5.3.1)

Вопрос 32.
Понятие «Подсистема контроля исполнительской деятельности» (раздел 6.5.3.2) отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 33.
Что подразумевается под формулировкой «Данная подсистема предназначена для использования на государственном и ведомственном уровне»?
Вопрос 34.
Понятие «Подсистема работы с нормативно-справочной информацией (далее - НСИ) и ведение профиля участника ЕСЭДО-Н» (раздел 6.5.3.3) отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 35.
Понятие «Подсистема по передаче документов в ведомственные архивы» (раздел 6.5.3.5) отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 36.
Указанные в ТЗ-1, ТЗ-2 «Подсистема автоматизации документооборота и делопроизводства национального уровня» и «Подсистема доступа к открытым ЭД» отсутствуют в Технической Спецификации, равно как и требования на нее. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 37.
Понятие «Подсистема взаимодействия с Центром Сертификации» (раздел 6.5.3.6) отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.

Вопрос 38.
Понятие «Подсистема публикации и доступа к опубликованным документам НЦ ЕС ЭДО» (раздел 6.5.3.7) отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2. Следует ли понимать под этим названием подсистему доступа к открытым ЭД?

Вопрос 39.
В разделе 6.5.3.8 указывается, что «Программно – технической реализацией транспортной среды служит система гарантированной доставки сообщений». Каким образом функции ПОДСИСТЕМЫ «Транспортная среда» выполняет СИСТЕМА, что противоречит иерархии терминологии ГОСТ на автоматизированные системы?

Вопрос 40.
Понятие СГДС отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.
Вопрос 41.
Понятие «Подсистема «Аналитика» отсутствует в ТЗ-1, ТЗ-2. Объясните, пожалуйста, это несоответствие Технической Спецификации ТЗ-1, ТЗ-2.
Аман
Гость




[4542] Ср Июн 04, 2003 05:40
конкурс на создание 2 очереди ЕС ЭДО
Ответы на вопросы, приведенные выше Адиком, КСИ практически не дал - так, на неактуальные что-то было...
А у должностных лиц, начинавших ЕС ЭДО, проблемы:
бывший президент Гусак лежит с инфарктом,
бывший директор документооборота Бисикеш - в следственном изоляторе, по-моему, несправедливо!
Кто будет следующим?
XML в ЭДО must die!
У нас Domino вльтернативы нет!
Мурат
Гость




[4585] Вс Июн 22, 2003 16:23
Что-то теперь будет!
Ну вот, нет теперь КСИ, а есть Агентство по связи и информатизации с Б. Канешевым во глвае. Тяжелое хозяйство ему достается!
Стнадарт электронного обмена данными должен быть принят в конце 2003 года, а деньги на него закончились еще в 2002-м...
Дальнейшая разработка КМПКФ и подзаконных актах по электронным документам и ЭЦП лежит на победителе тендера по 2-й очереди ЕС ЭДО Soft Engineering, т. е. реально - на узбеках из Naytov. Они наработают! (См. внимательно законы РУ в сфере цифрового документационного обеспечения управления http://www.ictcouncil.gov.uz/ - разрабатывали москвичи, а уродовали... догадайся с трех раз!)
Остается одна надежда, что разгонит г-н Канешев эту пригревшуюся а ИТ РК компанию (слева направо в порядке убывания важности) IBM - Maytov -NCI Projects - узбекские Алсюки (АЛСИ- Soft Engineering) да возьмется как за стандарт, так и правовую базу закона об ЭЦП, который, между прочим, вступает в силу с 1.07.2003
Аман
Гость




[4605] Чт Июн 26, 2003 10:45
Re: Агентство
Мужики, Ардак остается?
А то если КСИ упразднили, имхо, договоры должны быть расторгнуты. А Ардак счас подбивает так, чтоб все осталось! Узбеки вечны!
Вовочка
Гость




[4622] Ср Июл 02, 2003 08:20

Хм, тут вообще про XML или про что?
Такое впечатление, что вопросы "чистой" науки перерастают в казахские дрязги и разборки Smile
Куда смотрят модераторы...
Нет у них бедных полнотекстового, нечеткого, семантического, морфологического, фактографического, многоязычного, логического, машинопочитаемого и машинопонимаемого анализа!
А то бы враз забацали автоматическое, интероперабельное избавление от всей этой ахинеи, с попытками решить свои кадровые проблемы и предложением своих услуг w3c.
Кстати для несведущих, для тех у кого лапши на ушах с кило:
Г-н Кременчуцкий, главный конструктор компании ЗАО НИТ, давно уже кричащий, что построил ЕСЭДО своим мощным мозгом (на базе Documentum между прочим) на самом деле практически провалил всякие начинания внедрить документооборот (на базе Lotus) даже в нескольких гос органах Казахстана. Зайдите например в МинЮст и спросите, как там документооборот г-на Кременчуцкого поживает?
При этом деньги 2002 года выделенные на ЕСЭДО действительно скушала компания ЗАО НИТ.
А тем, кому это наследство досталось, разгребают сейчас наследие г-на главного конструктора...
Вот такие дела...
asher
Гость




[5016] Вт Сен 23, 2003 04:34
Wanted! Theories of ontology!
Every person in the world has a "tacit ontology". Thus there are at
least 6 billion ontologies. Even though, we can make "tacit inferences"
between these different ontologies. How? CYC is one project that make
these "common sense ontologies" interoperable. Common sense means
community. Communities have Ideologies and Paradigms that define a
"meta-ontology" for all their members. We had too much logical theories
of Ontology. Now we need sociological and political theories of
ontology.
Тот самый Аман
Гость




[5017] Вт Сен 23, 2003 05:15
Пробуксовки с запуском КМПКФ в СЭА ГО
Не прошло и полгода, как сляпали нанятые ЗАО АЛСИ ташкентцы свой архив и отправили в НИТ программу испытаний. А оттуда злобное ворчание:
"Ведените классификатор казахстанского машинопонимаемого коммуникативного формата и в его составе рубрикаторов, номенклатуры дел государственного органа в цифровом формате и их использование для ввода и поиска информации Добавить пункт d полнотекстовый поиск (в том числе и нечеткий), семантический, морфологический, фактографический, многоязычный, логический поиск, поиск по содержанию документов и с экспертным уточнением запросов, поддержка ODMA ТЗ СЭА ГО п. 4.1. 12"
Задумались мужики:"Как бы нам отписаться?" И пишут:
"Стандарт КМПКФ на данный момент не утвержден.
Поддержка нечеткого, семантического, запросов с экспертным уточнением предполагается в следующей версии используемого продукта IBM Content Manager. Полное соответствие данным функциональным возможностям будет продемонстрировано на третьем этапе проекта".
Господа-а, окститесь! Приемка-то осуществляется по требованиям ТЗ в полном объеме!
А вот и ТЗ, которому больше года уже - для справки:


ТЗ на создание СЭА ГО
1. ОБЩИЕ СВЕДЕНИЯ
В связи с внедрением Единой системы электронного документооборота государственных органов (далее – ЕС ЭДО) возникла объективная необходимость в создании электронных архивов государственных органов. Электронный архив является структурным подразделением ведомственного архива государственного органа либо государственного архива, осуществляющего сбор, временное хранение и использование документов архивных фондов.
Техническое задание на создание электронных архивов государственных органов разработано в целях реализации следующих документов:
• Указ Президента Республики Казахстан от 16 марта 2001 года № 573 «О Государственной программе формирования и развития национальной информационной инфраструктуры Республики Казахстан»;
• Постановление Правительства Республики Казахстан от 21 мая 2001 года № 674 «Об утверждении Плана мероприятий по реализации Государственной программы формирования и развития национальной информационной инфраструктуры Республики Казахстан на 2001-2003 годы»;
• Паспорт республиканской бюджетной программы №605 «Создание информационной инфраструктуры государственных органов» (приложение _____ к постановлению Правительства Республики Казахстан от 26 января 2002 года № 122)
Техническое задание базируется на правовых актах, регулирующих архивное дело в Казахстане, на положениях законодательных актов и нормативных документов, регулирующих процессы информатизации, к которым, в частности, относятся:
• Закон Республики Казахстан от 22 декабря 1998 года «О Национальном архивном фонде и архивах», Закон Республики Казахстан от 10 ноября 2001 года «О внесении изменений и дополнений в Закон Республики Казахстан «О Национальном архивном фонде и архивах»;

• "Положение о Национальном архивном фонде и архивах", утвержденное постановлением Правительства Республики Казахстан от 7 октября 1999 г. № 1538;
• «Государственный стандарт Республики Казахстан СТ Республики Казахстан 1042-2001 «Организационно-распорядительная документация. Требования к оформлению документов»
• Перечень документов, образующихся в деятельности Президента Республики Казахстан, Государственного секретаря и Администрации Президента Республики Казахстан, с указанием сроков хранения, утвержденный Руководителем Администрации Президента Республики Казахстан от 26 января 2000 г. № 01-58/13;
• «Инструкция о порядке и сроках временного хранения документов Национального архивного фонда Республики Казахстан в ведомственных архивах государственных юридических лиц», утвержденная приказом Председателя Комитета по управлению архивами и документацией Министерства культуры, информации и общественного согласия Республики Казахстан от 26 декабря 2000 года № 83 и зарегистрированная в Министерстве юстиции Республики Казахстан 10 января 2001 года (регистрационный номер № 1355)
• Ведомственные перечни, инструкции, памятки по вопросам делопроизводства, согласованные с уполномоченным государственным органом управления архивами и документацией Республики Казахстан.
При разработке Технического задания учитывались отраслевые научно-методические разработки, практический опыт архивных учреждений страны по работе с компьютерными технологиями, деятельность зарубежных архивов в сфере информатизации.

1.1. Полное наименование
Система электронных архивов государственных органов Республики Казахстан.

1.2. Условное обозначение
Условное обозначение - СЭА ГО РК.

1.3. Заказчик
Заказчиком СЭА ГО РК является Министерство Транспорта и Коммуникаций Республики Казахстан в лице Комитета связи и информатизации.

1.4. Генеральный подрядчик
Генеральным подрядчиком СЭА ГО РК является победитель конкурса по государственным закупкам технических средств (сервер, рабочие станции модемы) и работ по разработке и внедрению информационной системы «Государственная база данных «Физические лица» и работ по созданию системы электронных архивов государственных органов, лот №2.

1.5. Источник финансирования
Финансирование производится в соответствии с бюджетной программой 605 из средств республиканского бюджета.

1.6. Этапы решения задачи создания СЭА ГО РК
1.6.1. Первая очередь
1. Создание макета электронного архива минимальной конфигурации для целей тестирования и проведения испытаний.
2. Проведение тестирования и испытаний макета СЭА ГО.
3. Разработка и утверждение предложений по составу архивов, входящих в пилотную зону внедрения СЭА ГО.

1.6.2. Вторая очередь
1. Проведение дополнительного обследования архивов в пилотной зоне внедрения СЭА ГО, разработку технического задания на вторую очередь СЭА ГО с учетом результатов тестирования и испытаний первой очереди СЭА ГО, разработку техно – рабочего проекта и создание СЭА ГО в пилотной зоне внедрения, создание Центрального хранилища СЭА ГО
2. Проведение приемо – сдаточных испытаний СЭА ГО в пилотной зоне в режиме опытной эксплуатации.
3. Разработка предложений по правовому статусу и ведомственной принадлежности Центрального хранилища СЭА ГО

1.6.3. Третья очередь
1. Разработка технического задания на третью очередь СЭА ГО по результатам приемо – сдаточных испытаний СЭА ГО в пилотной зоне с учетом замечаний и предложений государственной комиссии.
2. Проведение работ по полномасштабному внедрению СЭА ГО в Республике Казахстан

2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1. НАЗНАЧЕНИЕ СИСТЕМЫ
СЭА ГО является автоматизированной информационно-справочной системой, предназначенной для автоматизации технологических процессов приема, регистрации, архивации, классификации, обеспечения сохранности, научно-технической обработки документов на электронных носителях информации, персонификации доступа к ним, а также поиска и использования информации в научных и практических целях.

2.2. ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
Целями разработки СЭА ГО являются:
• Развитие рациональной системы формирования, обеспечения сохранности, всестороннего использования документов и защита информационных ресурсов государственных органов.
• Повышение оперативности и снижение трудозатрат при проведении информационно-справочной работы, комплектовании, атрибутировании и рубрикации документов, поступающих из текущего делопроизводства и полученных в результате ретроконверсии бумажного архива;
• Предоставление доступа зарегистрированным пользователям системы к информационным ресурсам СЭА ГО.


3. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
В настоящее время значительная часть информационных ресурсов государственных органов сосредоточена на бумажных носителях информации и хранится в их ведомственных архивах. В соответствии со Сводом (Каталогом) данных о составе и содержании документов Национального архивного фонда Республики Казахстан и источниках его пополнения по состоянию на 1 декабря 1999 года в ведомственных архивах хранится свыше полутора миллиона единиц хранения управленческой и около миллиона единиц хранения научно-технической документации на бумажных носителях информации.
Постоянно возрастающие объемы создаваемой документации на бумажных носителях информации требуют увеличения площадей под архивохранилища ведомственных архивов государственных органов, выделения дополнительных финансовых средств на приобретение материалов и оборудования, обеспечивающих физическую сохранность и оптимальные параметры температурно-влажностного режима хранения документов. Большой объем документов на бумажных носителях информации, хранящихся в ведомственных архивах государственных органов, и несовершенная система их учета негативно влияют на оперативность поиска и предоставления необходимой информации. В силу объективных причин, связанных с ограниченными возможностями обеспечения широкого доступа в читальные залы ведомственных архивов государственных органов, значительная часть информации, зафиксированной на бумажных носителях, остается вне поля зрения потенциальных потребителей.
Современный уровень экономического, социального и политического развития страны, начавшийся процесс компьютеризации и информатизации государственных органов требуют выработки принципиально новых подходов к компактному хранению, автоматизированному учету, оперативному, полномасштабному поиску и предоставлению пользователям разноплановой информации. Эти задачи будут решаться в результате создания и функционирования электронных архивов государственных органов.
Объектом автоматизации является система органов государственного управления Республики Казахстан, которая включает в себя Администрацию Президента Республики Казахстан, Канцелярию Премьер – Министра Республики Казахстан, министерства, агентства, ведомства и акиматы.
Задачи, функции, организационная структура органов государственного управления Республики Казахстан и обобщенная схема государственного управления приведены в отчете по обследованию существующей системы документооборота в органах государственного управления Республики Казахстан.
Органы государственного управления подразделены на следующие группы:
• Администрация Президента Республики Казахстан;
• Парламент Республики Казахстан;
• Канцелярия Премьер Министра Республики Казахстан;
• государственные органы, непосредственно подчиненные и подотчетные Президенту Республики Казахстан;
• центральные исполнительные органы, входящие в состав Правительства Республики Казахстан;
• центральные исполнительные органы, не входящие в состав Правительства Республики Казахстан
• ведомства Республики Казахстан;
• местные исполнительные органы областей, городов Астана и Алматы
Всего 769 бюджетных организаций республиканского и областного уровней, финансируемых из республиканского бюджета.
Исполнительные органы дислоцированы соответственно в административных центрах областей и в городах Астана, Алматы.
В каждом государственном органе функционирует ведомственный архив, который и является объектом автоматизации для разрабатываемой системы.
Документы государственных органов на электронных носителях информации подлежат передаче на государственное хранение в сроки, установленные уполномоченным государственным органом управления архивами и документацией Республики Казахстан. Прием документов осуществляют соответствующие центральные государственные архивы Республики Казахстан, Архив Президента Республики Казахстан, специальные государственные архивы Республики Казахстан, государственные архивы областей, городов Астана и Алматы. Указанные государственные архивы также являются объектами автоматизации для разрабатываемой системы.
4. ТРЕБОВАНИЯ К СИСТЕМЕ

4.1. ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ

4.1.1. Требования к структуре и функционированию системы
Согласно описанию, приведенному в разделе 3, СЭА ГО должна состоять из следующих подсистем:
1. Подсистемы ведомственных электронных архивов
2. Подсистемы государственных электронных архивов
Разрабатываемая система строится по следующим базовым принципам:
1) Масштабируемость
Наращивание мощностей должно определяться характеристиками аппаратного обеспечения, на котором функционирует данная система. СЭА ГО должна поддерживать работу неограниченного числа пользователей.
2) Интегрированность.
СЭА ГО должна состоять из интегрированных модулей, построенных на основе стандартных настраиваемых комплексов программного обеспечения (ПО), желательно от одного производителя.
3) Распределенность.
Система должна позволять распределять информационные ресурсы и процессы их обработки по нескольким серверам, функционирующим в её составе.
4) Модульность.
В связи с разнородностью выполняемых функций СЭА ГО должна состоять из отдельных взаимодействующих между собой модулей, построенных на основе настройки стандартных комплексов программного обеспечения (ПО), реализующего функции системы.
5) Открытость.
Комплексы ПО, входящие в СЭА ГО, должны обладать открытым программным API-интерфейсом, что позволит использовать их не только как готовое решение, но и как инструмент разработчика.
6) Преемственность.
Каждая последующая версия технологии определенного типа должна позволять использовать информационные ресурсы, накопленные в рамках предыдущих версий.
7) Гибкость.
В системе должна быть предусмотрена возможность добавления новых функций без нарушения её функционирования.
Cool Комплексность.
При декомпозиции должны устанавливаются такие связи между структурными элементами системы (подсистемами, компонентами подсистем и комплексами ПО), которые обеспечивали бы целостность СЭА ГО и возможность его сопряжения с другими системами.
9) Надежность.
СЭА ГО должна обеспечивать резервное копирование информации, рестарт системы после сбойных и аварийных ситуаций без потери логической целостности баз данных, процедуры для поддержки целостности обработки данных после сбоев системы или других незапланированных простоев, логическую проверку входных данных. СЭА ГО должна предусматривать применение средств гарантированного питания, резервирования носителей информации и основных узлов оборудования, резервного копирования, резервирования каналов связи. Для наиболее ответственных участков необходимо предусмотреть горячее резервирование серверов системы.
10) Информационная безопасность.
СЭА ГО РК должна использовать механизмы, обеспечивающие автоматизацию режима ограничения доступа по чтению и\или редактированию в отношении отдельных модулей, отдельных документов и отдельных полей (частей) документов, подключение внешних средств криптозащиты информации (шифрование, засекречивание, электронная цифровая подпись). СЭА должна обеспечивать минимизацию риска некорректного использования или злоупотребления за счет следующих мероприятий: получения доступа к системе только после идентификации пользователя с помощью пароля, разграничения прав, поддержки аудита (фиксации) каждого вхождения или попыток подбора паролей, автоматического отключения пользователей после определенного интервала отсутствия активности и при выходе из прикладной программы. СЭА ГО должна иметь возможность подключения внешних алгоритмов электронной подписи и шифрования документов.
11) Унификация.
Методы описания, представления, передачи и обработки данных в электронной форме в рамках основных направлений деятельности архивных подразделений должны быть унифицированы.
12) Поддержка гетерогенной сетевой среды.
Должно быть предусмотрено функционирование СЭА ГО в сетевой среде, построенной с использованием различных сетевых и клиентских операционных систем. В качестве сетевых операционных систем необходимо предусмотреть использование Windows 2000, Unix (Sun Solaris, HP-UX, OS|400). В качестве клиентских операционных систем следует предусмотреть Windows 2000/XP .
13) Сопряжённость.
В системе должны быть предусмотрены средства сопряжения с ЕС ЭДО и системами CЭА ГО республиканских государственных органов в сфере архивного обеспечения, а также с информационными системами учреждений-источников комплектования и учреждений, являющихся постоянными потребителями архивной информации, с внеотраслевыми системами передачи данных.
14) Индустриальность.
Данный принцип предполагает использование в решении только тиражируемых компонент с минимальным объемом заказного кодирования. Только соблюдение данного принципа может дать уверенность в реализуемости предлагаемого решения.

4.1.2. Основные задачи и функции СЭА ГО
Основными задачами электронного архива государственного органа являются:
1. Прием на хранение документов на электронных носителях информации, перевод в цифровой вид документов на бумажных и пленочных носителях информации, образованных в ходе деятельности государственного органа;
2. Обеспечение качества экспертизы ценности, сохранности, учета и использования хранимых документов;
3. Обеспечение в установленном порядке доступа пользователей к хранимым документам и делам на электронных носителях информации;
4. Подготовка и передача документов на электронных носителях информации, отнесенных к составу Национального архивного фонда, на постоянное государственное хранение в соответствии с требованиями и сроками, установленными уполномоченным государственным органом по управлению архивами и документацией Республики Казахстан.
В целях выполнения основных задач электронный архив государственного органа осуществляет следующие функции:
• учет принятых на хранение документов, в том числе нормативных правовых и правовых актов;
• ведение классификатора казахстанского машинопонимаемого коммуникативного формата и в его составе рубрикаторов, номенклатуры дел государственного органа в цифровом формате и их использование для ввода и поиска информации;
• регулярный прием на хранение документов и дел на электронных носителях информации в соответствии с классификатором казахстанского машинопонимаемого коммуникативного формата;
• пакетное сканирование документов на бумажных и пленочных носителях с получением электронного образа высокого качества;
• предварительная обработка изображений для повышения качества отсканированных документов (очистка изображения от пятен, его масштабирование, разворот);
• преобразование электронного графического образа документа в текстовый формат (обработка изображения документа подсистемой оптического распознавания символов);
• верификация ввода документов (визуальную сверку исходного изображения текста с символьными данными, записываемыми в текстовый файл) и редактирование получившихся текстовых файлов с целью исправления ошибок;
• экспорт электронных образов документов и их текстовых представлений в хранилище электронного архива государственного органа;
• ведение первичных учетных данных на сканированные, аудио, видео документы в базе данных с автоматической их категоризацией на основании машинного анализа текстового, аудио, видео контента документов;
• ведение первичных учетных данных на сканированные документы в базе данных;
• подписание электронного образа документа электронной цифровой подписью руководителем электронного архива государственного органа;
• идентификацию электронного документа по его реквизитам;
• организацию хранения учетной информации о документах;
• установление и поддержание логических связей между документами;
• регулярное проведение экспертизы ценности документов на электронных носителях информации, разработка в электронном формате соответствующих описей дел и актов о выделении к уничтожению документов, не подлежащих хранению, обеспечение в установленном порядке одобрения, согласования и утверждения указанных описей и актов;
• формирование архивного электронного фонда (архивных электронных фондов);
• обеспечение сохранности и учета хранимых документов;
• разработка, ведение и поддержка работы научно-справочного аппарата к документам архивного электронного фонда (архивных электронных фондов);
• поиск документов по значениям реквизитов, введенных при работе с документами, полнотекстовый (в том числе и нечеткий), семантический, морфологический, фактографический, многоязычный, логический поиск, поиск по содержанию документов и с экспертным уточнением запросов;
• автоматическое формирования метаданных из документов по указываемым категориям заданного классификатора на основе полнотекстового (в том числе и нечеткого), семантического, морфологического, фактографического, многоязычного, логического анализа содержащейся в документах текстовой, графической (видео), аудио информации по содержанию распознанных документов;
• формирование перечней документов, подготовка и выдача произвольных статистических отчетов по запросам пользователей;
• разработка и ведение статистических и тематических отчетов о составе и содержании хранимых документов на электронных носителях информации;
• подготовка документов и их выгрузка в область обмена для передачи в другие организации;
• управление правами доступа к документам, хранимым в электронном архиве;
• управление правами доступа пользователей к подсистемам СЭА ГО;
• обеспечение доступа к учетной информации и электронным документам в соответствии с правами доступа;
• защита данных электронного архива от несанкционированного изменения, просмотра и копирования;
• защита документов в электронных архивах от их изменения, искажения, модификации;
• контроль целостности и подтверждение достоверности содержания электронных документов и учетных данных;
• фиксация в недоступной для несанкционированной модификации форме всех действий пользователей;
• формирование отчетности по работе пользователей с электронным архивом;
• просмотр журналов протоколирования действий пользователей;
• формирование отчетности по работе пользователей с электронным архивом;
• перенос исполненных документов, неактуальной информации в соответствующие дела архивной базы данных согласно номенклатуре дел организации;
• перенос документов из архивов в активные базы данных при необходимости;
• интегрированное управление потоками работ, в том числе автоматическая связь потока работ с жизненным циклом документа;
• управление составными и виртуальными документами;
• подготовка и регулярная передача документов на электронных носителях информации вместе с имеющимся научно-справочным аппаратом на постоянное государственное хранение в соответствующее государственное архивное учреждение.

4.1.3. Структура системы
СЭА ГО должна состоять из специализированных объектно – ориентированных хранилищ Docbase, в том числе центрального, модулей связи СЭА ГО с ЕСЭДО РК и набора специализированных функциональных модулей (автоматизированных рабочих мест).
Хранилища СЭА ГО, в том числе центральное, должны состоять из нескольких серверных модулей, физически располагаемых на разных серверах, входящих в состав аппаратного обеспечения СЭА ГО. Для построения СЭА ГО может быть применён также ряд специальных технических средств, как-то, документные сканеры и библиотека магнитооптических дисков.
Хранилище документов должно быть реализовано с использованием следующих аппаратных серверов:
• сервер баз данных;
• сервер хранения архива документов;
• WEB - сервер. Данный сервер должен обеспечивать доступ пользователей к СЭА ГО по технологиям Intranet/Internet. Должно быть обеспечено динамическое формирование содержимого Web – сервера на основании актуальных версий документов, хранящихся в Docbase.
Модуль связи СЭА ГО с ЕСЭДО РК должен обеспечивать обмен электронными документами между системами в формате ЕСЭДО РК
Назначение и функциональные возможности данных серверов реализуются с использованием различных программных серверных модулей, которые обеспечивают централизованную обработку и хранение информации в ЭА.
Сервер баз данных. СЭА должен использовать центральную базу данных, которая поддерживается серверным модулем СЭА. Центральная база данных должна быть построена на основе реляционной промышленной СУБД (РСУБД). Использование для хранения фактографической информации РСУБД должно обеспечить хранение всех баз данных системы на одном сервере (или группе серверов). Данная РСУБД должна позволять вести параллельную обработку информации с нескольких рабочих мест и осуществлять одновременный поиск информации большим количеством пользователей.
Сервер хранения архива документов. Данный сервер должен реализовать функции хранилища базы данных, которая объединяет информационное наполнение, автоматизацию документооборота, Web и реляционные технологии для хранения информации. В составе сервера хранения документов требуется наличие специализированного программного обеспечения для управления магнитооптическими библиотеками. Магнитооптические библиотеки применяются для хранения основного объема текстов и образов документов.
Web - сервер. Данный сервер должен обеспечивать доступ пользователей к СЭА по технологиям Intranet/Internet.
Специализированные автоматизированные рабочие места (АРМ), сгруппированы по принципу выполнения аналогичных функций и подразделяются по типам в зависимости от их функциональных возможностей. В СЭА должны быть выделены следующие автоматизированные рабочие места:
- АРМ подготовки документов;
- АРМ ввода документов, включающее верификацию и атрибутирование;
- АРМ сканирования;
- АРМ рубрикации документов;
- АРМ конечного пользователя.
Функциональные характеристики структурных модулей системы приведены в подразделе 4.2.


4.1.4. Особенности функционирования электронного архива
государственного органа
В связи с тем, что существует необходимость введения в сжатые сроки в базу данных большого объема документной информации, работа системы должна быть максимально автоматизирована с отстранением оператора от любого участия в процессе ввода, распознавания, корректировки и индексирования документов.
Система должна обеспечивать возможность автоматического поиска по содержанию и атрибутам документов.
Система должна обеспечить при необходимости экспоненциальный рост объема хранимых данных. Архивные данные инвариантны, т.е. их истинность не зависит от времени, и стабильны, т.е. они не удаляются и не модифицируются.
В отличие от электронных хранилищ данных, в которых данные имеют интегральный вид и получены из множества разнотипных СУБД и файловых систем, в электронных архивах утверждается единая технология ввода документов с автоматическим определением их метаданных в результате машинного анализа текстового, аудио, видео контента документов и разнесением метаданных по категориям казахстанского машинопонимаемого коммуникативного формата
СЭА ГО должна включать как средства оперативного ввода информации (On-line Transaction Processing - OLTP), так и средства оперативного анализа информации (On-line Analytic Processing - OLAP), средства добычи данных (data mining) и управления знаниями (knowledge management) из хранимой в СЭА ГО информации.

4.1.5. Требования к численности и квалификации персонала системы и режиму его работы

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

Основные требования к каждой категории персонала приведены в Таблице 1.
Таблица 1.
Квалификационные требования к персоналу СЭА ГО РК

Категория персонала Требования к персоналу
Операторы профессиональные навыки работы с клавиатурой компьютера.
основные навыки работы в системе Windows 2000/ XP
умение работать с электронными формами диалогами в идеологии системы Windows.
элементарные знания в области групповой работы в сети
умение работать с электронной почтой на уровне почтового абонента
знание интерфейса ввода-вывода данных в прикладной системе, принципов ввода, обработки и контроля данных
знание основ документообразования и архивного дела
Администраторы системы навыки работы с клавиатурой компьютера.
хорошие навыки работы в системе Windows 2000/ XP, UNIX
умение работать с электронными формами диалогами в идеологии системы Windows.
знания принципов и методов групповой обработки информации в сети
знание принципов работы телекоммуникационных программ, умение работать с электронной почтой на уровне администратора почтового отделения
умение работать со средствами автоматизации офиса - текстовый процессор WinWord, электронные крупноформатные таблицы Excel и их расширениями
знание принципов защиты информации от разрушения и несанкционированного использования и умение пользоваться средствами защиты и архивирования информации прикладной и операционной систем, средствами распределения прав доступа, средствами регистрации пользователей в системе
хорошее знание функциональных возможностей прикладной системы, умение работать с любой компонентой прикладной системы
умение работать с генератором отчетов прикладной системы, умение составлять запросы средствами прикладной системы
знание основных конструкций языка запросов SQL
хорошее знание структур и состава баз данных прикладной системы, принципов распределенной обработки данных, технологии передачи документов, актуализации данных
Группа сопровождения навыки работы с клавиатурой компьютера.
основные навыки работы в системе Windows 2000/ XP
умение работать с электронными формами диалогами в идеологии системы Windows.
знания в области групповой работы в сети
умение работать с электронной почтой на уровне почтового абонента
умение работать со средствами автоматизации офиса - текстовый процессор WinWord, электронные крупноформатные таблицы Excel и их расширениями
хорошее знание функциональных возможностей прикладной системы, умение работать с любой компонентой прикладной системы
умение работать со встроенными средствами настройки прикладной системы (языком построения расчетных схем генератора отчетов, построителя входных форм и пр.)
знание конструкций языка запросов SQL и умение составлять запросы на языке SQL
элементарные знания языка программирования Visual Basic
знание основ документообразования и архивного дела
Персонал технического обслуживания навыки технического обслуживания средств вычислительной техники, кабельных систем и средств телекоммуникаций
навыки диагностики отказов средств вычислительной техники
навыки мелкого ремонта средств вычислительной техники
навыки производства монтажных работ в кабельных информационных и электрических сетях
Пользователи ЭА основные навыки работы в системе Windows 2000/ XP
умение работать с электронными формами диалогами в идеологии системы Windows.
элементарные знания в области групповой работы в сети
умение работать с электронной почтой на уровне почтового абонента
умение работать со средствами автоматизации офиса - текстовый процессор WinWord, электронные крупноформатные таблицы Excel и их расширениями
знание функциональных возможностей прикладной системы, умение работать с компонентами прикладной системы


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

4.1.7. Требования к эргономике и технической эстетике
СЭА ГО должна обеспечивать казахский и русскоязычный интерфейс пользователя.
СЭА ГО должна обеспечивать доступ к электронному комплекту эксплуатационной документации в режиме «on-line» (подсистема помощи). Подсистема помощи должна предоставлять контекстно-зависимую подсказку.
Информация, не связанная с предоставленными пользователю ресурсами системы (функциями и данными), не должна выводиться на экран.
СЭА ГО должна предоставлять возможность определения поисковых атрибутов для хранимых объектов. При этом должно быть предусмотрено задание предварительных значений некоторых атрибутов. Предустановленные значения атрибутов для групп пользователей устанавливаются администраторами системы, имеющими на это соответствующие права.
В СЭА ГО должно быть предусмотрено визуальное выделение на экране атрибутов, доступных оператору только для чтения.

4.1.8. Требования к взаимодействию с другими автоматизированными информационными системами
СЭА ГО РК должна обеспечивать возможность обмена информацией с ЕС ЭДО РК и другими информационными системами Республики Казахстан и других государств в казахстанском машинопонимаемом коммуникативном формате.

4.1.9. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Система должна функционировать в круглосуточном режиме.
Администратор СЭА ГО должен иметь возможность настроить программу резервного копирования для работы в следующем режиме:
 дублирование ресурсов за счет кластерных систем и на внешние магнитные носители в непрерывном режиме;
 ежедневное копирование данных об изменениях во всех базах данных системы;
 еженедельное копирование всех баз данных системы. В зависимости от принятого порядка по ведению архива электронной информации.
Администратор СЭА ГО должен иметь возможность обеспечить сохранность коллекции копий соответствующей давности, в том числе хранить все ранее сделанные еженедельные копии баз данных СЭА ГО.
Администратор СЭА ГО должен иметь возможность проводить диагностические работы без приостановки работы пользователей. К таким работам относятся:
 проверка взаимодействия серверов между собой;
 проверка функционирования баз данных системы;
 проверка работы средств связи.
Работы в части проверки эффективности принятых мер по защите информации также относятся к диагностическим работам, но могут проводиться без обязательного требования непрерывной работы пользователей.
В документации должен быть предусмотрен регламент работ администратора по обеспечению безопасности системы.
Требования по эксплуатации могут уточняться на этапе опытной эксплуатации СЭА ГО. Уточнения должны производиться по согласованию Заказчика и Исполнителя.

4.1.10. Требования к защите информации от несанкционированного доступа
Пользователи электронного архива должны быть идентифицированы с помощью имени и пароля.
Для каждого пользователя должны быть определены права доступа к документам в СЭА ГО.
Формирование списков документов по всем запросам пользователей должно производиться только из тех документов, к которым разрешен доступ для данного пользователя.
Данные, передаваемые по локальной вычислительной сети, должны быть защищены средствами сетевой операционной системы.
Любые изменения в правах доступа должны фиксироваться в журнале работы администратора СЭА ГО.
В соответствии с технологической схемой обработки документов на разных этапах технологического процесса в системе должна быть предусмотрена возможность доступа к документу различных групп пользователей:
1) При ретроконверсии бумажного архива, на этапе непосредственной загрузки электронной версии документа в СЭА ГО, (помещении электронной версии в хранилище) документ должен быть доступным для чтения по умолчанию всем пользователям группы «Подразделение».
2) При загрузке в СЭА ГО электронной версии документа из системы текущего электронного документооборота с использованием рабочего места ввода документов документ быть доступным для чтения только пользователям группы «Подразделения», тех подразделений которые перечислены в его карточке в группе атрибутов «Рассылка».
СЭА ГО должна реализовывать следующие требования к защите информации:
 Предотвращение несанкционированного доступа для широкого круга современных и проектируемых программных комплексов и баз данных как на уровне рабочей станции, так и на уровне системы без дополнительных затрат на доработку системы
 Идентификация и контроль доступа субъектов в систему.
 Контроль доступа к файлам.
 Контроль доступа к записям (документам баз данных).
 Контроль входа/выхода субъектов доступа (ведение журнала сессий пользователей).
 Контроль запуска/завершения программ (серверных задач).
 Контроль доступа программ субъектов к защищаемым программам (проверка права на удаление базы данных).
 Контроль доступа программ субъектов к записям (проверка права на редактирование документа).
 Контроль очистки освобождаемых областей внешних накопителей (проверка очистки данных на диске после удаления документа из базы данных).
 Периодическое тестирование средств защиты от НСД (проверка запрета доступа с устаревшим паролем).
 Обнаружение атаки компьютерных вирусов и случайных либо преднамеренных искажений программ и данных, контроль целостности программного кода.
Комплекс мер и средств защиты информации от несанкционированного доступа должен разрабатываться исходя из условий размещения СЭА ГО в пределах официального расположения государственных структур Республики Казахстан.
СЭА ГО предназначена для обработки и хранения несекретных документов и документов, содержащих информацию, относящуюся к категории ограниченного доступа и по условиям её правового режима являющуюся конфиденциальной (документы с пометкой «Для служебного пользования»).
Защита информации должна обеспечиваться средствами оборудования, операционных систем, СУБД и прикладного программного обеспечения СЭА ГО.
Система защиты от несанкционированного доступа должна обеспечивать:
 Аутентификацию пользователей при подключении к локальной сети всех уровней, возможность привязки пользователя к конкретной рабочей станции.
 Аутентификацию удаленных пользователей СЭА ГО.
 Персонифицированное определение прав пользователей на ввод, корректировку, просмотр данных.
 Персонифицированное определение прав пользователей на доступ к системным ресурсам.
 Протоколирование работы пользователей, в том числе авторизацию изменений в Базах данных.
 Возможность установки усиленной защиты путем регламентации времени (расписаний) работы пользователей, периода работы, количество подключений в течение рабочего дня, максимального количества ошибок аутентификации.
 Автоматическое отключение пользователя от системы после заданного интервала неактивности.
Учитывая, что средства системного администрирования позволяют достичь максимально эффективной защиты лишь при условии, что сетевые администраторы локальных сетей и администраторы БД выполняют правила технологии «непрерывного администрирования». В частности:
 ограничение состава групп администраторов с расширенными правами;
 распределение пользователей по группам;
 присвоение соответствующих прав доступа;
 применение сложных и длинных паролей;
 квотирование жизненного цикла пароля
 использование расширенного метода аутентификации т.п.
Защита от несанкционированного доступа при передаче данных в ТС должна быть обеспечена внешними программными средствами, использующими методы криптографической защиты. Эти средства должны удовлетворять следующим требованиям:
 использование сертифицированных алгоритмов, выдержавших попытки взлома в течение достаточного периода времени.
 гибкая схема удостоверения действительности ключей, допускающая как распределенное управление доверием «сеть доверия»), так и централизованную архитектуру сертификации.

4.1.11. Требования по обеспечению государственных секретов
Требования по обеспечению сохранения государственной тайны не предъявляются для несекретных документов.
Хранение секретных документов в настоящем техническом задании не предусматривается.
Примечание. В случае возникновения потребности хранения секретных документов в СЭА ГО в установленном порядке должно быть разработано и согласовано с Канцелярией Премьер-Министра Республики Казахстан в соответствии с законодательством по защите информации отдельное техническое задание для хранения электронных документов с пометой «Для служебного пользования».

4.1.12. Требования по сохранности информации при авариях
Реализация СЭА ГО должна обеспечивать целостность базы данных системы при сбоях и отказах программно-технических средств, в том числе из-за электропитания.

4.1.13. Требования по стандартизации и унификации
Программные средства СЭА ГО РК должны удовлетворять основным мировым стандартам в области обработки документов:
 Поддержка современных транспортных протоколов: TCP/IP, включая поддержку IP V6; HTTP 1.1; HTTPS; SSL (до уровня 3.0), WAP.
 Поддержка наиболее распространенных форматов документов: Microsoft Office 97/2000, PDF; HTML.
 Поддержка автоматического преобразования форматов документов.
 Поддержка основных стандартов в области сопряжения ODMA.
В области интеграции со средствами разработки:
 Поддержка J2SE, J2EE
 Поддержка в области повышения отказоустойчивости и надежности системы:
 Поддержка кластерных решений с балансировкой нагрузки.
 Поддержка распределенного поиска информации.
 Поддержка распределенного доступа к информации.
 Возможность функционирования на различных аппаратных платформах.

4.1.14. Требования к носителю, на котором передается программный продукт и формату передачи программного продукта.
Требования к формату передачи базового лицензионного программного обеспечения следующие:
 каждый продукт должен содержаться на фирменных компакт дисках;
 к каждому продукту должна быть лицензия или сертификат подтверждающая правомочность их использования.
Требования к формату передачи прикладного программного обеспечения СЭА ГО:
 носителем должен являться компакт диск;
 обложка компакт дисков должна быть надлежащим способом оформлена (прописано название продукта, краткое описание продукта и название основных модулей программы, а также исполнитель данной программы).

4.1.15. Дополнительные требования
Для достижения необходимого квалификационного уровня в соответствии с перечисленными требованиями должна быть организована постоянная работа по повышению квалификации персонала СЭА ГО. Внедрение СЭА ГО предполагает такую технологию работы, при которой исполнение своих служебных обязанностей любой категорией персонала возможно только с применением средств вычислительной техники.
Для обучения и повышения квалификации персонала в Республике Казахстан должен быть создан единый учебно-методический центр, оснащённый полным комплектом ПО и независимыми базами данных.
Обучение персонала должно быть организовано в обязательном порядке, по возможности с отрывом от производства. Кроме подготовки персонала в области эксплуатации и технической поддержки СЭА, учебный центр должен осуществлять переподготовку персонала в предметной профессиональной области.

4.2. ТРЕБОВАНИЯ К ФУНКЦИЯМ (ЗАДАЧАМ), ВЫПОЛНЯЕМЫМ СИСТЕМОЙ
Функциональные возможности СЭА ГО должны быть реализованы функциональными модулями, соответствующими структурным:
- серверными модулями;
- специализированными функциональными модулями СЭА ГО.
Серверные модули реализуют централизованную обработку и хранение информации в СЭА ГО.
Центральное хранилище СЭА ГО на основе Docbase® должно обеспечивать выполнение следующих функций:
Функции сервера баз данных;
Основные функции центральной базы данных СЭА ГО:
1. Обеспечение надежного хранения следующих видов фактографической информации:
 электронных карточек документов;
 нормативно-справочной информации (классификаторов, номенклатуры дел и т.д.);
 сведений о полнотекстовых документах;
 сведений о пользователях и группах пользователей системы;
 сведений о правах доступа пользователей и групп пользователей к подсистемам;
 сведений о правах доступа пользователей и групп пользователей к компонентам подсистем СЭА ГО;
 сведений о правах доступа пользователей и групп пользователей к объектам системы;
 журналов истории работы.
2. Обеспечение одновременного поиска фактографической информации.
3. Обеспечение корректировки фактографической информации.
4. Создание страховочных копий базы данных.
5. Восстановление (при необходимости) базы данных из страховочных копий.
6. Ведение списка пользователей СЭА ГО.
7. Ведение списка администраторов СЭА ГО и её подсистем.
8. Определение полномочий доступа пользователей к подсистемам.
Функции магнитооптической библиотеки:
1. Обеспечение надежного хранения большого объема текстов и изображений документов.
2. Обеспечение поиска текстов и изображений документов.
3. Создание страховых копий документов.
4. Восстановление (при необходимости) документов из страховых копий.
5. Запись CD и DVD дисков в автоматическом режиме.
6. Считывание CD и DVD дисков в режиме произвольного доступа.

Функции сервера хранения архива документов:
1. Обеспечение следующих видов работ с документами:
 хранение и извлечение документов;
 управление рабочим процессом;
 службы электронной почты;
 сборка и публикация;
 просмотр и распечатка.
2. Хранение файлов содержимого (тел документов), их индексов и свойств в центральном хранилище.
3. Поддержка архитектуры клиент-сервер и Web.
4. Контроль доступа к центральному хранилищу.

Функции Web-сервера:
1. Управление документами СЭА ГО на основе Web - технологий и предоставления доступа пользователям к информации в масштабах Intemet/Extranet/Intranet. Данный модуль должен реализовать следующие функции:
 позволять стандартным клиентским Web - браузерам извлекать данные из центрального хранилища;
 поддерживать анонимный доступ к центральному хранилищу.
2. Обеспечение администраторов СЭА ГО возможностями централизованного администрирования, - опираясь на Web -технологии. Данный модуль должен реализовать функции следующего вида:
 создание и работу с федерациями баз данных центрального хранилища;
 конфигурирование центрального хранилища и ведение сеансов работы;
 работу с пользователями, группами и наборами доступа;
 управление заданиями, методами и хранением содержимого документов.
3. Обеспечение клиентам Интранет (Intranet Clients) доступа к центральному хранилищу через web - браузер:
 перемещение пользователей по ящикам и папкам через web - браузер;
 добавление и просмотр аннотаций к документу в форматах PDF;
 создание, просмотр структуры и содержимого виртуальных документов;
 просмотр свойств и наборов доступа;
 выписка и возврат объектов из центрального хранилища СЭА ГО;
 импорт документов;
 удаление документов, в том числе версий и экземпляров.

Специализированные модули СЭА ГО должны обеспечивать выполнение всех функций предметной области.
Модуль связи СЭА ГО с ЕСЭДО РК предназначен для обмена электронными документами между системами в формате ЕСЭДО РК.
АРМ подготовки документов предназначено для выполнения следующих функций:
 подготовки текста проекта документа и его верификации по результатам согласования средствами MS Word 97/ 2000;
 сохранения верифицированного файла с текстом документа;
 заполнения разнарядки средствами MS Word 97/ 2000;
 сохранения разнарядки;
 помещения файла с текстом документа и разнарядки в очередь на загрузку.

АРМ ввода документов должно включать две составляющие: АРМ верификации документов и АРМ атрибутирования.
АРМ верификации предназначено для выполнения следующих функций:
 внесения исправлений в электронную версию документа по результатам его подписания средствами MS Word 97/ 2000;
 помещения файла с исправленной версией текста документа в каталог для атрибутирования;
АРМ атрибутирования предназначено для выполнения следующих функций:
 занесения (импорт) электронных документов в электронный архив;
 атрибутирования документов;
 использования электронных справочников для ввода и поиска информации;
 установления логических связей между документами;
 ведения поиска документов;
 обеспечения доступа к учетной информации и содержанию документов в соответствии с правами доступа.

АРМ сканирования предназначено для выполнения следующих функций:
 сканирования документов;
 сохранения образов документов;
 распознавания образов документов в текстовый файл;
 сохранения текстовых файлов с распознанными текстами документов;
 помещения образов документов и распознанных текстовых файлов в очередь на верификацию.

АРМ рубрикации документов предназначено для выполнения следующих функций:
 рубрицирования документов с использованием классификаторов;
 использования электронных справочников для ввода и поиска информации;
 актуализации нормативной базы, в т.ч. создание новых версий нормативных актов и установление ссылок между нормативными актами и изменяющими их распорядительными документами и другими нормативными актами;
 установления логических связей между документами;
 ведения поиска документов;
 обеспечения доступа к учетной информации и содержанию документов в соответствии с правами доступа.

АРМ конечного пользователя предназначено для выполнения следующих функций:
 поиска документов;
 использования электронных справочников для поиска информации;
 обеспечения доступа к учетной информации и содержанию документов в соответствии с правами доступа пользователя.

АРМ администратора предназначено для выполнения следующих функций:
добавления и удаления пользователей и групп пользователей СЭА ГО;
 установления прав доступа пользователей и групп пользователей к документам;
 ведения электронных справочников;
 формирования отчетности.

4.3. ТРЕБОВАНИЯ К ВИДАМ ОБЕСПЕЧЕНИЯ
4.3.1. Требования к информационному обеспечению
Должно быть обеспечено взаимодействие с ЕСЭДО РК и, при необходимости, корректировка информационного наполнения действующих систем делопроизводства и системы автоматизированного учета поступившей корреспонденции в государственных структурах Республики Казахстан.
Необходимо предусмотреть пути загрузки справочников разрабатываемой системы: источники информации, порядок выверки и объединения данных.
Необходимо обеспечить миграцию электронных данных с устаревших форматов в рабочие.


4.3.2. Требования к лингвистическому обеспечению
Все функции системы должны поддерживать казахский и русский языки
Система должна поддерживать драйвер казахского языка, определенный в подпрограмме «Создание информационной инфраструктуры государственных органов». Программы формирования и развития Национальной информационной инфраструктуры Республики Казахстан.

4.3.3. Требования к программному обеспечению
При выборе программных и технических средств должна быть поставлена задача минимизации числа используемых программных и аппаратных платформ, что позволит значительно снизить развертывания системы СЭА ГО РК за счет унификации применяемых решений.
Программные средства должны предусматривать режим удаленного администрирования, что позволит снизить стоимость владения системой за счет снижения затрат на администрирование системы.
Программные средства системы СЭА ГО РК должны быть построены по трехуровневой схеме «клиент сервер обработки данных – сервер хранения информации», что позволяет снизить стоимость владения системой за счет концентрации обработки данных на небольшом количестве серверов обработки данных и, как следствие, снижение затрат на администрирование системы.
WEB-сайт системы должен быть построен на основе четырехзвенной архитектуры: «клиент сервер представления информации – сервер обработки данных – сервер хранения информации», что позволяет ему использовать общие информационные ресурсы и вычислительные мощности с основными подсистемами СЭА ГО РК, без их перегрузки вспомогательными процессами.
Программные средства системы должны позволять проводить обработку в распределенном режиме с резервированием серверов, что повышает надежность и живучесть системы.
Предпочтение должно отдаваться интегрированным программным продуктам, которые обеспечивают выполнение максимального числа технологических требований к системе СЭА ГО РК.
Программные системы, используемые для реализации СЭА ГО РК, должны быть объектно-ориентированными для облегчения дальнейшей реструктуризации системы.
В состав программного обеспечения входит:
 Базовое программное обеспечение;
 Прикладное программное обеспечение.

4.3.3.1. Требования к базовому ПО
Базовые программные средства электронных ведомственных архивов государственных органов включают в себя:
1) операционную сетевую среду, ориентированную на мультипотоковую обработку в сети и сертифицированную по безопасности;
2) систему управления базы данных, ориентированную на обработку сверхбольших массивов данных;
3) средства отображения и обработки данных.
Базовое ПО должно обеспечивать:
• выполнение функций операционной среды на сервере (Unix, Windows 2000) и на рабочих станциях (Windows 2000/XP);
• Работу конечных пользователей системы в интегрированной графической среде (Windows 2000/XP) с возможностью обработки текстовой и статистической информации (MS-Office)
• Поддержку версий проектов документов.

4.3.3.2. Требования к прикладному ПО
Структура клиентской и серверной части прикладного ПО должна быть модульной и обеспечивать по возможности легкий переход к альтернативным базовым средствам (операционные системы).
• Прикладное ПО должно обеспечить сканирование изображений, включая распознавание символов и проверку орфографии;
• Прикладное ПО должно предоставлять возможность функционирования нескольких серверов приложений на одном физическом сервере.
• Прикладное ПО должно позволять пользователю системы одновременно работать с несколькими серверами приложений, обслуживающих различные подсистемы. При этом рабочее место должно включать все доступные для этого пользователя возможности каждой из подсистем.
• Рабочее место пользователя должно обеспечивать динамическое формирование рабочей обстановки. Пользователь должен иметь возможность подключать доступные ему сервера приложений в произвольной конфигурации.
В составе специальных программным средств для функционирования электронных архивов государственных органов должны быть предусмотрены:
1) средства распознавания русскоязычных текстов и текстов на государственном языке;
2) средства разработки и оптимизации запросов;
3) средства полнотекстового индексирования и поиска информации;
4) средства анализа информации.

4.3.4. Требования к техническому обеспечению
Технические средства должны обеспечивать выполнение указанных в настоящем документе функций и задач системы.
Необходимо предусмотреть обеспечение СЭА ГО следующими основными аппаратными средствами:
1)потоковыми сканерами, обеспечивающих надежный высокопроизводительный ввод документной информации в объеме 40 страниц в минуты и более;
2) высокопроизводительными масштабируемыми серверами, способными вести параллельную обработку запросов и построенными на основе коммутируемой архитектуры с поддержкой «тяжелых приложений» с интенсивным вводом/выводом;
3) высокопроизводительной (100 Мбит/c и более) вычислительной сетью, ориентированная на многопотоковый ввод и обработку графических документов;
4)RAID-массивами, обеспечивающих высокопроизводительный и сверхнадежный доступ к поисковым данным системы;
5) автоматическими библиотеками компакт- или магнитооптических дисков для долговременного хранения больших массивов информации,
6) средствами переноса данных на компакт- или магнитооптические диски;
7) средствами резервного копирования на магнитную ленту;
Cool автоматизированными рабочими местами клиентов, ориентированные на обработку графической информации;
9) автоматизированными рабочими местами разработчиков конкретных приложений;
10) системой обеспечения безаварийного питания;
11) принтерами и модемами.
Вычислительные мощности СЭА ГО в каждом государственном органе должны быть объединены в ЛВС с сервером, связанным через ТС с межведомственным уровнем электронного архива и единой системой электронного документооборота как ведомственного, так и национального уровней.
На ведомственном уровне СЭА ГО серверы выполняют роль центров коммутации, хранения и обработки данных.
Взаимодействие рабочих станций с базами данных на ведомственном уровне должно осуществляться по технологии «клиент – сервер».
При использовании технологии «клиент – сервер» к рабочим станциям предъявляется требование обеспечить возможность работы в качестве клиентов СУБД.
Серверы БД CЭА ГО должны обеспечивать бесперебойное функционирование базы данных и одновременное обслуживание запросов от рабочих мест пользователей СЭА ГО.
В состав СЭА ГО должен входить учебный программно-технический комплекс, на котором проходит обучение персонала государственных органов.
Сохранность инвестиций обеспечивается выбором на текущий момент наиболее современного оборудования, которое в состоянии обеспечить функционирование системных и прикладных программных средств в течение всего жизненного цикла последних.
4.3.5. Требования к аппаратной части
В качестве сервера используется сервер со следующими характеристиками:
 Процессор Intel Pentium IV Xeon 1GHz;
 Привод чтения компакт дисков (CD-ROM);
 Привод ленточного накопителя (стример на 4Гб);
 Оперативная память – SD RAM 1Гб ECC;
 Жесткие диски – общий объем 70,16 Гб = 4 шт. по 17,54 Гбайт (интерфейс SCSI);
 Интегрированный аппаратный RAID-контроллер, поддерживающий уровни от 1 до 5 включительно;
 Сетевой адаптер Ethernet 10/100 Мбит/с;
 Видеоконтроллер SVGA с 8 МБ видеопамяти(можно интегрированное);
 используемый сервер должен иметь возможность объединения с аналогичными серверами в группу (кластер);
 используемый сервер должен иметь сертификат безопасности С2.
Операционная система данного сервера должна:
a. поддерживать лимитирование времени выполнения и количества использования дискового пространства как для пользователей так и для запускаемых задач;
b. иметь более 99 уровней приоритета для выполняемых задач;
c. иметь развитые возможности по безопасности и защите сервера и данных, хранящихся на ней (ограничение доступа по пользователям, в целом к системе к файлам, к функциональным возможностям системы).

4.3.6. Требования к локальной вычислительной сети и рабочим станциям
Локальная вычислительная сеть должна быть готова к инсталляции программного комплекса СЭА. В определение готовности входит:
• наличие на всех рабочих станциях сетевых карт обеспечивающих соединение на скорости не ниже 100Мб/с (Ethernet 100Mb/s, full or half duplex);
• увязка драйверов сетевых карт и операционных систем рабочих станций;
• наличие сетевого протокола TCP/IP;
• сервер должен иметь статический IP-адрес;
• рабочие станции могут получать IP-адрес как динамически так иметь статично прописанный IP-адрес, но должны находиться в том же IP-пространстве, что сервер электронного документооборота;
• количество каскадирования концентраторов, коммутаторов, мостов и т.п. между любой рабочей станции и сервером не должно превышать трех уровней.
Рабочие станции, где будет устанавливаться клиентские приложения СЭА, должны отвечать следующим требованиям
 процессор класса Intel Pentium 4, с частотой работы не ниже 1GHz;
 Материнская плата – Intel на чипсете Intel 845;
 оперативная память SDRAM 256 MB;
 жесткий диск – 40GB c 7200 обор/мин;
 Видеоконтроллер GeForce2 Pro 32 MB;
 Сетевой адаптер Ethernet 10/100 Мбит/с;
 Привод CD-ROM

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

Ретроконверсия бумажного архива
Занесение электронных копий документов из архива документов на бумажных носителях должна включать в себя последовательность следующих этапов:
1. Подготовку документов к сканированию.
2. Сканирование и распознавание документа.
3. Постобработку документов.
4. Верификацию документа.
5. Импорт и атрибутирование документа.
В системе должна быть предусмотрена возможность выполнения операций сканирования, распознавания, верификации и атрибутирования документов как на одном компьютере, так и на нескольких, связанных между собой локальной вычислительной сетью.
Импорт в СЭА ГО электронных версий документов из ЕС ЭДО РК.
Занесение текущих (вновь утвержденных) нормативных и распорядительных документов, сформированных в текущем делопроизводстве, в ЭА должно включать в себя последовательность следующих этапов:
1. Подготовка документов к архивированию;
2. Атрибутирование документа;
3. Рубрикация документов.

Импорт в СЭА ГО электронных версий документов, поступивших по электронной почте.
Занесение электронных версий документов, поступивших по электронной почте, в СЭА ГО должно включать в себя последовательность следующих этапов:
1. Атрибутирование документа;
2. Рубрикация документов.

Конвертирование электронных версий документов, сформированных в устаревших форматах в рабочие форматы СЭА ГО.
1. Подготовку документов к конвертированию.
2. Конвертирование документа.
3. Постобработку документов.
4. Верификацию документа.
5. Атрибутирование документа;
6. Рубрикация документов.

Поиск документов пользователями СЭА ГО
В системе ЭА ГО в АРМе конечного пользователя должны быть предусмотрены следующие виды поиска необходимой информации:
1. Поиск по атрибутам документа.
В зависимости от типа атрибута должен быть предусмотрен поиск документа по одному или нескольким заданным значениям атрибутов. При этом, должны быть предусмотрены дополнительные возможности, включающие в себя анализ совпадения по регистру и поиск всех версий с ограничением при добавлении условий поиска диапазон поиска.
2. Поиск по содержимому документа
Полнотекстовый в том числе и нечеткий), семантический, морфологический, фактографический, многоязычный, логический поиск, поиск по содержанию документов и с экспертным уточнением запросов) поиск документов по значениям реквизитов, введенных при работе с документами должен обеспечивать нахождение документов, содержащих заданное слово или фразу.
3. Комбинированный поиск.
В системе должна быть предусмотрена возможность совместного использования поиска документа по атрибутам и поиска документов по контенту.
Технология выполнения всех п
Аман
Гость




[5018] Вт Сен 23, 2003 05:23
Продолжение ТЗ на СЭА ГО - не поместилось в один заход!
Поиск документов пользователями СЭА ГО
В системе ЭА ГО в АРМе конечного пользователя должны быть предусмотрены следующие виды поиска необходимой информации:
1. Поиск по атрибутам документа.
В зависимости от типа атрибута должен быть предусмотрен поиск документа по одному или нескольким заданным значениям атрибутов. При этом, должны быть предусмотрены дополнительные возможности, включающие в себя анализ совпадения по регистру и поиск всех версий с ограничением при добавлении условий поиска диапазон поиска.
2. Поиск по содержимому документа
Полнотекстовый в том числе и нечеткий), семантический, морфологический, фактографический, многоязычный, логический поиск, поиск по содержанию документов и с экспертным уточнением запросов) поиск документов по значениям реквизитов, введенных при работе с документами должен обеспечивать нахождение документов, содержащих заданное слово или фразу.
3. Комбинированный поиск.
В системе должна быть предусмотрена возможность совместного использования поиска документа по атрибутам и поиска документов по контенту.
Технология выполнения всех поименнованных в настоящем разделе технологических операций должна быть достаточно полно изложена в соответствующих технологических инструкциях.

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ

Поскольку СЭА ГО РК является интегрированной с ЕСЭДО РК, этапы работ по созданию электронных архивов государственных органов хронологически взаимосвязаны с работами по созданию ЕС ЭДО РК.
На первом этапе «Проектные работы», охватывающем 3 и 4 кварталы 2002 года, должны быть осуществлены:
1) разработка методологии построения электронных архивов государственных органов и их взаимодействия с ЕС ЭДО;
2) разработка технического задания и технорабочего проекта на создание электронных архивов государственных органов, в котором будут определены тип вычислительной техники, программного обеспечения, сетевого оборудования, принципы информационной безопасности;
3) разработка базового и специального программного обеспечения с использованием лицензированного и апробированного в государственных органах программного обеспечения;
4) разработка и государственная регистрация в Министерстве юстиции Республики Казахстан Основных правил работы ведомственных архивов с учетом создания электронных архивов государственных органов;
5) проведение опытной эксплуатации электронных ведомственных архивов в пилотной зоне;
6) доработка программного обеспечения по результатам опытной эксплуатации.
На втором этапе «Поставка оборудования» в течение 1 и 2 кварталов 2003 года предполагается:
1) определение поставщиков оборудования из числа надежных отечественных компаний;
2) заключение договоров о поставке;
3) поставка оборудования и распределение его по регионам на основании данных проекта.
На третьем этапе «Создание сети электронных архивов государственных органов» в течение 3 и 4 кварталов 2003 года запланировано создание электронных архивов в высших и центральных государственных органах Республики Казахстан, проведение в них инсталляции, монтажа оборудования и программного обеспечения.
На четвертом этапе «Расширение сети электронных архивов государственных органов» в течение 2004 года планируется полномасштабное внедрение СЭА ГО в Центральных государственных архивах Республики Казахстан, Архиве Президента Республики Казахстан, специальных государственных архивах Республики Казахстан (Министерство обороны РК, Министерство внутренних дел РК, Комитет национальной безопасности РК, Служба охраны Президента РК, Агентство финансовой полиции РК), органах местного государственного управления, территориальных органах и подведомственных организациях министерств, агентств и ведомств, государственных архивах областей, г.Астана и Алматы.


6. ПОРЯДОК КОНТРОЛЯ И ПРИЁМКИ СИСТЕМЫ

 Предварительное тестирование системы;
 Тестирование системы;
 Опытная эксплуатация (сравнительный анализ текущих и внедряемых форм);
 Сбор замечаний по программному комплексу и их доработка СЭА;
 Сдача программного комплекса СЭА в промышленную эксплуатацию.
Перечень участвующих предприятий и организаций:
Заказчик: Комитет по связи и информатизации Министерствв транспорта и коммуникаций Республики Казахстан.
Объект внедрения – государственные органы Республики Казахстан.
Исполнитель – ЗАО НИТ РК
Место проведения - на объекте внедрения
Сроки проведения опытной эксплуатации – определяется дополнительным соглашением сторон.






7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ
При подготовке объектов автоматизации (каждого конкретного государственного органа отдельно) должны быть выполнены следующие мероприятия:
- Разработка (конкретизация) плана работ по внедрению СЭА;
- Подготовка и обучение персонала;
- Подготовка и обучение пользователей;
- Подготовка ЛВС к инсталляции программного комплекса СЭА;
- Подготовка сервера к инсталляции СЭА;
- Сбор данных о специфике ведения архива в ведомстве;
- Инсталляция серверной части программного комплекса СЭА на сервер;
- Инсталляция клиентской части программного комплекса СЭА на рабочие станции;
- Настройка и параметризация СЭА;
- Сдача программного комплекса СЭА в опытную эксплуатацию.
- Опытная эксплуатация;
- Сбор замечаний по программному комплексу и их доработка СЭА;
- Сдача программного комплекса СЭА в промышленную эксплуатацию.

8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
В состав документов СЭА должны быть включены следующие основные документы:
1. Пояснительная записка техно-рабочего проекта;
2. Общее описание системы;
3. Программа и методика испытаний;
4. Руководство администратора;
5. Руководство пользователя.
6. Технологические инструкции.
Пояснительная записка техно-рабочего проекта.
Пояснительная записка техно-рабочего проекта предназначена для определения обоснованности выбора проектных решений. Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
В качестве дополнительных разделов (или подразделов) в пояснительную записку необходимо включить структурную схему СЭА ГО и ее описание а также схему функциональной структуры СЭА ГО и её описание.
Общее описание системы
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
Программа и методика испытаний
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
Руководство администратора БД
Документ подготавливается Разработчиком и должен включать следующие разделы:
Общие положения;
Назначение и условия применения;
Установка и подготовка системы к работе;
Регистрация и сопровождение пользователей;
Распределение прав и уровней доступа в системе;
Обеспечение сохранности данных;
Обеспечение безопасности данных;
Репликация и актуализация данных;
Конвертирование данных;
Взаимодействие с внешними системами.
Руководство пользователя
Документ подготавливается Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
Технологические инструкции
Документы подготавливаются на каждую технологическую операцию Разработчиком согласно методическим указаниям по комплексу стандартов и руководящих документов на автоматизированные системы.
4. На разрабатываемое программное обеспечение должна быть представлена документация в соответствии с действующим ГОСТ (ЕСПД).
Покупные изделия должны поставляться в комплекте с документацией.
Chief constructor
Новичок

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

[5019] Вт Сен 23, 2003 08:24
О разгоревшихся страстях
Призываю участников обсуждения к уважению оппонентов и терпимости...
Когда мы в 1998 году начали подготовку первых документов по единому информационному пространству ЕИП - ныне НИИ РК, особых страстей не было, а было конструктивное обсуждение проблемы объединения существующих и разрабатываемых систем. Страсти разгорелись через пару месяцев после начала финансирования работ по НИИ, и это объяснимо. Столкнулись интересы HP, IBM, Oracle - завязалась жесткая борьба за выделенные средства.
В итоге все из тройки получили подряды - кто больше, кто меньше. Их агенты в стране были изрядно помяты, конечно, в пылу разгоревшейся свалки, а что касается личностей, то кому-то вообще туго пришлось.
В результате многие работы пошли с опозданием (еще одна иллюстрация о роли личности в НИИ Smile)
Но Госпрограмма продлена до 2005 года, за лето произошла очередная тихая революция в ИТ, OWL стал кандидатом, ядро КМПКФ обсуждается на рабочей группе, понимание необходимости принятия стандарта электронного обмена данными как склеивающего средства в процессе формирования НИИ овладело почти всеми участниками процесса.
У нас ЕСТЬ время. А поэтому давайте сконцентрируемся на конструктивном обсуждении проблем создания НИИ и о ее склейке при помощи КМПКФ, который не сможет эффективно работать без построения глобальной таксономии, тем более что, как сообщил нам сегодня Asher, число "кирпичиков" для нее - 6 000 000 000 онтологий. Прочитав об этом, подумал, что если бы каждый живущий получил по одной онтологии - кирпичу и пришел строить глобальную таксономию, вышло бы новое Вавилонское строительство, когда никто не мог бы понять то, что говорит ему сосед и тем самым нельзя было бы правильно уложить кирпичи.
А нас, работающих в SW, не 6 000 000 000, но лишь несколько сот и кирпечей на каждого в соответствующее количество раз больше, а постройка не должна развалиться.
Воистину стучите, и отворят вам.
Имеющий уши да услышит этот контент и контекст
Ralph Hodgson
Гость




[5025] Ср Сен 24, 2003 02:55
Semantic Technologies
The proceedings of a recent well-attended conference on Semantic Technologies are available on the web at http://www.topquadrant.com/conferences/tq_proceedings.htm.

The "Semantic Technologies for E-Government" Conference was held at the White House Conference Center on September 8th. This was a very successful event with over 130 attendees. Among many agencies represented were Army, Census Bureau, CIA, DIA, DOE, EPA, GSA, IRS, Navy, NARA, NASA, NSA, NSF, SSA, USDA and US Patent Office. A number of attendees were from non-profit organizations such as Aerospace.org and Mitre. Major goverment contractors were also well represented by the attendees from BBN, CSC, Lockheed Martin and SAIC.

Ralph Hodgson
Lead for Semantic Technologies Pilot, CIO Council XML Web Services Working Group
Executive Partner
TopQuadrant, Inc.
Office: (724) 846-9300, Fax: (425) 955-5469, Cell: (781) 789-1664
http://www.topquadrant.com
john hardin
Гость




[5026] Ср Сен 24, 2003 02:59
Ontologies in the web environment of tomorrow?
There is a group called the UDEF http://www.udef.org (you've probably all seen my emails recently) that is focused on the issue of semantic interoperability. We are approaching it from a universal semantic ID scenario, and gathering a significant amount of momentum among standards bodies, industry associations, research and IT leaders. We are currently specifying and preparing to build the registry/repository based solutions to support the domain expert contributions to the core UDEF data element trees (which are based on the ISO 11179 meta data standards) and to facilitate namespace based propogation for implementations of the aforementioned standards and ebusiness document formats with the UDEF ID's labeled somehow (currently being discussed and modeled - DTD, Schema, RDF and actual instance documents all appear appropriate right now.) See the http://www.udef.org/proofs.html for example OAG and xCBL purchase orders with UDEF IDs.

We feel that the software vendor market, industry ebusiness document format standards and large IT shops will be the first to bring about automated integration. This will look like "near-automated integration" to begin with, as there will need to be humans in the middle at least working out the ambiguities and the disconnects that will happen as this stands up. As the use of the ID's increases, there will be increasing agreement and easier integrations without human intervention as the semantic meaning, context and appropriate usage of data element concepts between partners or business/consumers is worked out.

There is an active mail list for working out the formats and planning for pilots/proofs etc. Archive is found at http://www.topica.com/lists/udef.builders/read. Subscribe if you like at udef.builders-subscribe@topica.com. I have sent an open letter to the internet standards and other communities, which describes the overall approach. It can be read at the archive referred to above or at my personal home page http://www.geocities.com/johnchardin/

Best regards,
john hardin

Michael Stollberg <michael.stollberg@uibk.ac.at> wrote:

This definitely is one of the main challenges in order to make the
Semantic Web become reality.

By now, there are the first technological solutions coming up: Ontology
Integration Techniques (as a superterm for ontology mapping, alignment,
merging) enable to make heterogeneous ontologies interoperable. But
these technologies are only semi-automatic, and the task of integration
(i.e. solving heterogeneous conceptualizations) is still left for humans
to decide. There seems to be no other way than semi-automated solutions,
because a machine always needs a reference to rely on for automated
decisions. For example, ontology A specifies Address by (Name, Street,
Nr., postal code, ..) and ontology B models address just in one String.
Both are conceptually correct - but for a certain use case the one or
the other is needed. For this resolution you need either a
upper-level-ontology (of the use case, for example) for automatic
resolution, or the application developer has to determine a usable
representation and make the ontologies A and B interoperable.

The next problem is how to maintain many interrelated, distributed and
multi-author ontologies. There are 2 basic requirements to keep an
ontology usable as the underlying data model of a Semantic Web
Application: the information consistency in the ontology and the affects
that changes in an ontology might have for a dependent system component.
The solution followed as this point of time in Semantic Web - driven
application is to have interrelated, but centrally controlled ontology
maintenance. This is due to not mature tool support for tracking changes
in ontologies (versioning) and thereby control consistency and affects
on dependent components. The grounding problem is the same as above:
Human investigation is by now the only way to control ontology
maintenance correctly.

A a closing statement this means that state-of-the-art techniques for
ontology maintenance do not allow to built the dream of "a network of
interweaved, dynamincally evolving and distributively maintained
ontologies" as the semantical basis of the Semantic Web. It is just
possible to have some closed information spaces in the Web modelled with
ontologies, and human investigation for ensuring therir usability. This
might entail in standardized conceptual models wherein the ontologies
are only used to provide a mean to specify formally (machine-readable)
semantics, but they are no longer a mean for collaborative knowledge
modelling (at least not at the same time). The other way would be to
further elaborate techniques for ontology maintenance in order to allow
distributed and multi-author ontology maintenance - although current
apporaches are very far away from this.

Michael Stollberg
Next Web Generation Group, University of Innsbruck, Austria