Научная статья на тему 'Анализ требований к системе Электронный документооборот на предприятии с высокой степенью ответственности с точки зрения применения современных информационных систем'

Анализ требований к системе Электронный документооборот на предприятии с высокой степенью ответственности с точки зрения применения современных информационных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
322
22
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
СОВРЕМЕННЫЕ СИСТЕМЫ ДОКУМЕНТООБОРОТА / БЕЗОПАСНОСТЬ ДАННЫХ / ИНТЕГРАЦИЯ СЛОЖНЫХ СИСТЕМ

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Платонов Юрий Георгиевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Платонов Юрий Георгиевич

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Анализ требований к системе Электронный документооборот на предприятии с высокой степенью ответственности с точки зрения применения современных информационных систем»

АНАЛИЗ ТРЕБОВАНИЙ К СИСТЕМЕ "ЭЛЕКТРОННЫЙ ДОКУМЕНТООБОРОТ" НА ПРЕДПРИЯТИИ С ВЫСОКОЙ СТЕПЕНЬЮ ОТВЕТСТВЕННОСТИ

С ТОЧКИ ЗРЕНИЯ ПРИМЕНЕНИЯ СОВРЕМЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Ю. Г. Платонов Институт систем информатики СО РАН, 630090, Новосибирск, Россия

УДК 62-52

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

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

This article considers the problem of the development of the information system 'Documents Circulation', as a subsystem of an information complex, implemented for enterprises with the high level of responsibility for resulting product. The subsystem must provide the high functionality and a high level of the data security, therefore it is of interest for researcher. As the enterprise — prospective customer of the system, the article considers the JSC Information Satellite Systems — Reshetnev Company (Geleznogorsk) that designs and manufactures navigation and geodetic satellites. The article describes the requirements for 'Documents Circulation' subsystem, analyzes some modern software products, and their ability to be used as the subsystem (entirely or partially, after the integration with other products) and draws a conclusion of a necessity of some scientific researches to implement the original program product.

Key words: modern systems of documents drculation, compound system, compound systems integration, data security.

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

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

1. Общие требования к подсистеме "Электронный документооборот". Подсистема "Электронный документооборот" является частью информационной системы, предназначенной для поддержки жизненного цикла программного обеспечения. Под такой системой

(сопровождения жизненного цикла изделия) следует понимать совокупность подсистем, интегрированных между собой тем или иным способом, которые в полной мере реализуют процессы проектирования, производства (программирования) продукта, контроль качества и сроков выполнения работ, а также хранения для последующей модификации и повторного использования [1].

"Электронный документооборот" следует рассматривать как подсистему системы сопровождения, обеспечивающую хранение, изменение и электронное согласование документов управления в процессе разработки, сопровождения и изготовления изделия [2].

В соответствии с работами [3, 4] сформулируем общие требования к такой подсистеме, разрабатываемой для предприятий с высокими требованиями к надежности и функциональным возможностям программного обеспечения. Система документооборота должна обеспечивать согласование документа между всеми его исполнителями, его исполнение и возможность контроля. При этом под движением документов понимается передача прав на их применение с уведомлением конкретных пользователей. В системе электронного документооборота должны автоматически отслеживаться изменения в документах, сроки их исполнения, движение документов, а также контролироваться все их версии. Иными словами, система документооборота должна включать систему поддержки стандартных процессов "Поручения" и "Согласования". Например, работы над изменением состояния документа один из пользователей может поручить кому-либо из прочих пользователей, и в процессе работы над документом пользователь-исполнитель обладает некоторой ролью, позволяющей выполнить назначенную ему задачу. По завершении выполнения этой задачи и (или) при изменении статуса документа система формирует и рассылает оповещения всем пользователям — участникам процесса, что позволяет своевременно продолжить работы по дальнейшему согласованию и обновлению документа.

Таким образом, для идентификации пользователей и определения набора их полномочий система должна использовать ролевой подход, где:

Пользователь — идентифицированный участник системы.

Роль — совокупность прав доступа пользователя к объектам компьютерной системы.

Соответственно в любой момент времени для каждого пользователя системы "Электронный документооборот" в контексте каждого документа должен быть задан набор его прав, совокупность которых определяется как роль данного пользователя в системе.

Кроме того, каждый документ должен иметь определенный набор атрибутов-метаданных. К метаданным относятся, например, дата занесения документа в хранилище и идентификатор пользователя, совершившего это действие. По мере необходимости система управления документами должна извлекать метаданные из документа автоматически или запрашивать их у пользователя. Система "Электронный документооборот" должна позволять производить поиск документа по ключевым словам, содержащимся в нем.

Таким образом, с учетом специфики выбранной для исследования отрасли (высокие требования к ответственности выходного кода, политике безопасности и сложности общей структуры производства [5]) можно сформулировать необходимые требования к подсистеме:

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

— достаточно высокий уровень защиты информации;

— высокая степень расширяемости файл-репозитория;

— наличие дружественного интерфейса и простота использования при обучении персонала;

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

2. Требования к подсистеме "Электронный документооборот", выдвигаемые ИСС им. Решетнева. Сопоставим сформулированные ранее общие требования к подсистеме "Электронный документооборот" с реальными требованиями, выдвигаемыми потенциальным предприятием-заказчиком — ИСС им. Решетнева [6]. Это позволит убедиться в том, что удовлетворение требований, обоснованных теоретически для разработки абстрактной системы поддержки электронного документооборота (см. п. 1), в полном объеме обеспечивает удовлетворение требований, вызванных необходимостью практической реализации такой системы.

Специфика рассматриваемого предприятия с высокой степенью ответственности за конечный продукт (ИСС им. Решетнева) обусловливает использование ряда терминов и сокращений. ИСС им. Решетнева — ведущий российский разработчик и производитель спутников связи, телевещания, навигации и геодезии. Его документооборот обеспечивает поддержку разработки бортового программного обеспечения (БПО) спутников. В настоящее время ИСС им. Решетнева использует информационную систему АСПИД для автоматизации производства. Система подразделяется на три каталогизированных архива: "Архив изделий" (АИ), "Архив проектов программ" (АПП) и "Архив документов" (АД).

"Архив изделий" (АИ) — каталогизированная иерархическая коллекция версий сборок. Каталогизация кода осуществляется по глобальному принципу. Это означает, что программный код в архиве не привязан к какому-либо изделию. Каждый объект архива изделий разрабатывается в рамках конкретного изделия и специфицируется парой атрибутов (тема, изделие). Если версия была создана на основе другого объекта, то у нее имеется атрибут, указывающий на прототип.

"Архив проектов программ" (АПП) — каталогизированная иерархическая коллекция компонентов.

"Архив документов" (АД) — каталогизированная коллекция документов.

Объекты АПП и АИ по сути подобны: это некая версия документированных программных модулей, которая однозначно определена в архиве и файл-репозитории. При этом в качестве объекта (единицы) хранения АИ и АПП следует рассматривать директорию, в которой содержатся файлы программного кода или документации, связанные с объектом архива (АП или АИ) и структурированные определенным образом в зависимости от типа архива. Структура Дерева подкаталогов объекта хранения определяется заранее. Элементом архива документов будем считать документ БПО — электронный документ, сопровождающий разработку БПО. Согласно СТП 154.123-2005 в процессе разработки БПО следует использовать документы типа указанных ниже.

В случае возникновения несоответствий между работой программы и требованиями архитектурного проекта программного обеспечения (ПО) системы, а также при возникновении дополнительных требований к детальному проекту готовится документ БПО под названием "Отчет о проблеме" (ОПР). Указанием на необходимость внесения изменений в архитектурный проект является документ БПО "Запрос-отчет" (ЗАО). Результатом работы по документу "Задание-заключение" (ЗАЗ) является изменение части архитектурного проекта подсистемы, т. е. создание новой версии изделия или подпрограммы.

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

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

С точки зрения файл-репозитория версия как объект хранения представляет собой директорию определенной структуры, где файлы определенного типа размещаются в поддиректориях. Оба архива поддерживают версионность. Подсистема "Документооборот" должна занимать промежуточное место и поддерживать создание, управление и хранение служебных документов, которые регламентируют всю хронологию работы с имеющимися архивами.

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

Для более удобного ведения документооборота все архивы должны быть разделены на две части (рабочую и базовую).

Базовый архив — представление объектов архива, разработка которых завершена. Для разрабатываемых в настоящий момент объектов указано место в архиве, где они будут размещены после окончания разработки, однако текущий состав объекта в данном представлении не виден.

Рабочий архив — представление объектов архива, которые в данный момент находятся в разработке, и объектов, разработка которых закончена, но которые не были окончательно утверждены.

Соответственно рабочий архив должен представлять собой изменяемую часть архива, т. е. ту часть, в которой ведется текущая разработка, а базовый — некую картотеку ранее разработанных объектов, доступную для просмотра и копирования, в случае повторного использования связанных с ней объектов АП и АИ.

^Кизненный цикл изделия (программного продукта) — совокупность процессов, выполняемых с момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта (ISO 9004-1).

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

Анализ приведенных на рис. 1-4 диаграмм позволяет выделить следующие этапы технологического процесса:

Рис. 1. Диаграмма связи документов с "Архивом изделий" и "Архивом программ"

— возникновение новой заявки или доработки;

— решение;

— обсуждение решения и выдача замечаний на доведение решения до требуемых стандартов;

— этап согласования и резервирования версии в архиве программ;

— реализация решения;

— проверка результатов;

— фиксирование кода версии программ;

— сборка изделия.

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

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

— возможность гибкой настройки графа перехода для документа, а также возможность настройки последовательности согласований;

— возможность создания связей с "Архивом изделий" и "Архивом программ".

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

Таким образом, любая система поддержки электронного документооборота, удовлетворяющая общим требованиям, сформулированным в п. 1, будет соответствовать требованиям, выдвигаемым предприятием-заказчиком.

Создавший ЗАЗ отв. за ПО получает роль "Владелец" для этого ЗАЗ

Добавить ЗАЗ {роль: Отв. за ПО}

Черновик

Предварительно должны быть получены подписи:

1. Исполнитель.

2. Отв. за ПО.

3. Отв. за КП (если указан).

Опубликовать {роль: Владелец}

ь.

Опубликоват]

Обязательные поля: * Исполнитель; * Отв. за ПО; * Утверждающий;

* Начальник сектора;

* Изделие; * Дата начала;

* Компонент/Сборка;

* Версия.

Аннулировать {роль: Владелец |

Отв. за ПО}

[создание версии]

Подготовлен

Аннулировать {роль: Владелец || Отв. за ПО}

}

Принят

[подписание] {роль: Начальник сектора}

[отмена подписи] {роль: Начальник сектора}

Аннулировать {роль: Владелец || Отв. за ПО}

В работе

[подписание] {роль: Начальник сектора и дата работ < даты подписи Начальника сектора}

[отмена подписи] {роль: Начальник сектора и работы не были начаты}

Версия в разработке

[согласование] этап "Разработка" завершен

О

у у

[отмена подписи этапа] {роль: любой Отв.}

утвердить {роль:

Утверждающий}

Работы завершены

утвердить {роль:

Утверждающий}

(1

отменить

утверждение

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

{роль:

Утверждающий}

Утвержден

Промежуточное состояние, указывающее, что все работы завершены. Пропускается, если этап "Разработка" исключен

[перенос версии в архив] [версия перенесена в архив]

г N

Аннулирован

V У

^В архиве^«

отменить утверждение {роль: Утверждающий}

ЗАЗ утвержден

отменено утверждение ЗАЗ

Версия утверждена

Принять в Базовый архив {роль:

Архивариус}

Версия в архиве

I

Рис. 2. Граф состояний, описывающий жизненный цикл рассматриваемого документа для ЗАЗ

Опубликовать

Прочие условия:

1. Обязательные поля:

* Исполнитель;

* Ведущий по теме;

* Нач. с. программирования;

* Нач. с. проектирования;

* Нач. отдела;

* Изделие;

* Дата начала;

2. Должны быть указаны этапы.

Создавший ЗАО отв. за ИД получает роль "Владелец" для этого ЗАО

Т\

Добавить ЗАО {роль: Отв. за

ид} ,

С

Черновик

Аннулировать {роль: Владелец || Отв.за ИД}

С

{

Опубликовать {Роль: Владелец}

Принять

Предварительно должны быть получены подписи:

1. Исполнитель.

2. Ведущий по теме.

3. Нач. с. программирования.

4. Нач. с. проектирования.

5. Нач. с. изготовления.

6. Согласующий (если указан).

Подготовлен К

[подписание] {роль: Начальник отдела}

Аннулировать {роль: Владелец || Отв.за ИД}

{

>

Принят

Начать работу {роль: Отв. за ИД || Начальник отдела}

Аннулировать {роль: Владелец || Отв.за ИД}_

{

>

В работе

[подписание] {роль: Начальник отдела} и дата начала работ < даты подписи Начальника отдела

[отмена подписи] {роль: Начальник отдела}

[отмена подписи] {роль: Начальник отдела} и работы с документом не проводились

Автоматическая процедура

при утверждении последнего связанного ЗАЗ

С

Работы завершены

Утвердить {Роль: Начальник отдела}

Аннулирован

С

Утвердить {Роль: Начальник отдела} и все ЗАЗ утверждены

В архиве №

>

Промежуточное состояние, указывающее на то, что работы по всем связанным ЗАЗ завершены (все связанные ЗАЗ в состоянии "Утвержден" или "В архиве")

Л

Отменить утверждение ЗАО нельзя

Л

Рис. 3. Граф состояний, описывающий жизненный цикл рассматриваемого документа для ЗАО

С

Добавить ОПР {роль: Отв. за ПО || Отв. за ИД}

Создавший ОПР Отв. за ИД ^

или Отв. за ПО получает

роль "Владелец" для этого ОПР

Опубликовать {роль: Владелец}

Аннулировать {роль: Владелец || Отв. за ПО|| Отв. за ИД}

[подписание] {роль: Утверждающий}

Аннулировать {роль: Владелец || Отв. за ПО|| Отв. за ИД}

Закрыть {роль: Утверждающий}

Аннулирован

С

Закрыт №

)

Автоматическая процедура утверждения ЗАЗ, ЗАО на основании данного ОПР {Все ЗАЗ и ЗАО утверждены}

Рис. 4. Граф состояний для ОПР

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

Из многообразия систем электронного документооборота, представленных на рынке в настоящее время, можно выделить следующие программные продукты:

— Borland StarTeam 2005;

— "Аналитика: документооборот";

— BizTalk Server;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

— "Кодекс: документооборот";

— "EOS for SharePoint";

— "Нордис/2: корпоративный документооборот".

Ниже приведен обзор выбранных продуктов с описанием их преимуществ и недостатков в рассматриваемом аспекте.

3.1. Borland StarTeam 2005. Borland StarTeam 2005 [7] — автоматизированная система управления конфигурацией и изменениями, осуществляющая эффективный контроль процесса разработки. StarTeam обеспечивает взаимодействие между сотрудниками предприятия, предоставляя пользователям доступ к любой важной информации проекта через центральный репозитарий, который поддерживается системой управления технологическими потоками и процессами. StarTeam предоставляет пользователям комплексное решение на основе систем управления требованиями, управления изменениями, отслеживания дефектов, контроля файловых версий, тематических обсуждений, управления задачами и управления проектом. StarTeam осуществляет централизованный контроль над проектными ресурсами и предоставляет платформу для согласования и управления всеми этапами разработки программного обеспечения.

Защита и повторное использование проектных ресурсов в пределах одной организации обеспечиваются центральным репозитарием. За счет использования центрального репозита-рия все проектные ресурсы находятся в актуальном состоянии, что существенно улучшает взаимодействие и коммуникацию между разработчиками и повышает общую продуктивность. Интегрированная функциональность StarTeam предоставляет возможности управления. Система поддерживает управление изменениями, отслеживание дефектов, версион-ный контроль файлов, управление проектом и его задачами (рис. 5). Все это позволяет осуществлять контроль над всем процессом разработки. На всех стадиях жизненного цикла раз-Рис. 5. Электронная форма создания работки организации могут усовер-

в StarTeam новой задачи шенствовать и расширить настраива-

емые бизнес-процессы в соответствии со своими индивидуальными требованиями.

Дополнительно компанией Borland, разработчиком Star Team, анонсирован новый программный продукт Borland Star Team SDK (Borland Star Team Solution Developer Kit), раз-

работанный на платформе Sun JRE 1.5_09 и представляющий собой набор функций для

доступа к репозиторию, списку документов проекта и истории их изменений (официальный сайт компании Borland, проект StarTeam http://www.borland.com/downloads/download _starteam_integrations.html). Borland Star Team SDK предназначен для разработчиков программного обеспечения и позволяет осуществлять интеграцию системы Star Team и других программных продуктов, несмотря на то что Star Team имеет закрытый программный код.

Преимущества:

— централизованный контроль над проектными ресурсами и задачами;

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

— многократное использование одних и тех же ресурсов во многих проектах;

— увеличение эффективности за счет совершенствования процесса разработки программного обеспечения;

— высокий уровень защиты и безопасности для критически важных ресурсов проекта.

Недостатки:

— закрытый программный код с отсутствием гибкой настройки бизнес-процессов;

— возможность дальнейшей интеграции для автоматизации полного жизненного цикла только в качестве внешнего компонента, несмотря на то что появление SDK, безусловно, может увеличить степень интеграции.

3.2. "Аналитика: документооборот". Информационная система "Аналитика: документооборот" позволяет быстро и эффективно автоматизировать электронный документооборот для небольших и средних по численности работников предприятий (официальный сайт компании "Аналитика" http://www.1c-doc.ru/work-with-docs/). "Аналитика: документооборот" соответствует большинству рекомендаций ГОСТа, имеет центральный репозитарий документов, что позволяет поддерживать их в актуальном состоянии и обеспечивать коммуникацию между пользователями системы. Одним из преимуществ системы является пользовательский интерфейс, представленный в виде навигатора. Навигатор позволяет выбрать желаемый вариант организации закладок, фильтров и группировок. Функциональность контроля версий документов обеспечивает гибкий контроль над всем процессом разработки. Гибкий полнотекстовый поиск упрощает поиск требуемой информации и уменьшает время формирования документов и их согласования. Кроме того, функциональные возможности системы обеспечивают возможность быстрого оповещения пользователей. Если пользователь включен в список получателей информационной рассылки и включенный в систему документ был изменен, то пользователь получает соответствующее оповещение с помощью e-mail или sms. Удобный дизайнер позволяет создавать новые бизнес-процессы предприятия и редактировать существующие.

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

Система отчетов позволяет использовать шаблоны Microsoft Office и Open office. Программный продукт "Аналитика: документооборот" работает на платформе "1С: Предприятие 8" и может использоваться как отдельное приложение или интегрироваться в типовые конфигурации "1С: Предприятие 8".

"Аналитика: документооборот" является специализированным бизнес-приложением, разработанным на платформе "1С: Предприятие 8", с расширенным спектром функциональных возможностей. Отметим общие возможности базового программного комплекса:

1. Комплекс позволяет назначить роли пользователям в контексте проекта в целом.

2. Дополнительные права назначаются пользователю на конкретный документ и контролируются бизнес-логикой приложения "Аналитика: документооборот". Подобное разделение неудобно, так как права пользователя на документ определены статично и не могут меняться в зависимости от поведения (состояния) документа.

3. Все документы репозитория хранятся во внутреннем формате приложения внутри базы данных, что является дополнительной защитой от несанкционированного копирования репозитория, но в случае большого количества документов (размер репозитория может достигать 10 Тбайт) подобное хранение документов не является эффективным.

4. В случае интеграции с другими подсистемами "1С: Предприятие 8" в качестве механизма взаимодействия используется собственный механизм обмена данными. В качестве формата обмена используются XML-документы, при этом не накладываются дополнительные ограничения на состав и структуру сообщений. В качестве сервера сообщений может также использоваться выделенный BizTalk-сервер.

5. В дополнение к описанной выше технологии или отдельно от нее для интеграции с другими программными системами предлагается использовать технологию Native API, представляющую собой набор библиотек, которые реализуют собственный интерфейс системного программирования "1С: Предприятие 8".

Преимущества:

— использование широко известной платформы "1С: Предприятие 8";

— открытый код программы, возможность внесения изменений;

— удобный пользовательский интерфейс;

— дизайнер бизнес-процессов (рис. 6);

— централизованное хранение документов.

Недостатки:

— целевая ниша — небольшие и средние предприятия;

— отсутствует система верификации файлов, и архитектура репозитария не позволяет использовать подобные внешние системы;

— защита цифровой подписи осуществляется только дополнительными внешними компонентами;

— относительно невысокая скорость работы системы;

— недостаточная надежность сохранения документов и низкая степень защиты от несанкционированного доступа;

— ограниченная возможность дальнейшей интеграции с другими потенциальными подсистемами.

3.3. BizTalk Server. BizTalk Server — продукт компании Microsoft, предназначенный для решения задач интеграции приложений и использующийся в сложных бизнес-системах в качестве центрального интегратора, в котором реализуется инфраструктура интеграции, предоставляющая возможность работы с различными транспортными протоколами и стандартами форматирования сообщений, а также со средствами обеспечения безопасности и надежной доставки сообщений (рис. 7) (официальный сайт продукта Microsoft BizTalk Server http://www.microsoft.com/biztalk/en/us/overview.aspx).

Старт

Подготовка «Ï [ет У Последовательное согласование? t 1

\

Г Поручение очередному пеиензенту

Поручение всем рецензентам

Инициатор 4>г А согласование? Ля

ь W —V )— А \ \ / Аа

Обработка рецензий Л F

Г

À Согласовать повторно? 1а

Л

Hi гг

Завершение

Рис. 6. Пример бизнес-процесса, представленного в редакторе системы "Аналитика: документооборот"

Собственно интеграция представляет собой обмен сообщениями между приложением и BizTalk Server. Затем сообщение преобразуется во внутреннее представление сообщений в BizTalk Server, XML и поступает на вход преобразователя, который трансформирует сообщение в выходной XML-формат по правилам, заданным в описании преобразования. Далее этот XML-файл преобразуется с помощью выходного преобразователя в один из поддерживаемых форматов (XML, EDI и Flat file) и отправляется по одному из транспортных протоколов приложению-получателю. С помощью приложения BizTalk Orchestration Designer, построенного на базе инструментария Microsoft Visio, можно сконструировать бизнес-процесс, состоящий из действий, условий, циклов и параллельно выполняемых операций. Действием в этом процессе может быть отправка или получение сообщения от интегрируемого приложения. В данном случае применение BizTalk Server следует рассматривать только как создание некоторого узла интеграции, как возможность расширения системы в будущем, а также интеграции уже готовой подсистемы документооборота с ранее написанной системой "Архив сопровождения программных проектов и документов" (АСПИД).

Преимущества:

— обеспечение интеграции подсистемы с другими составляющими информационной системы;

Рис. 7. Упрощенная схема обмена данными в информационной системе BizTalk

— возможность расширения системы в дальнейшем.

Недостатки:

— необходимость доработки уже существующих архивов программ и изделий;

— усложнение конечной архитектуры системы.

3.4. "Кодекс: документооборот". Система "Кодекс: документооборот" принадлежит к классу систем специализированного электронного документооборота и изначально проектировалась как система консолидированного документооборота для бюджетных организаций. Назначение системы определяет ее основные особенности:

— большая пропускная способность (способность обрабатывать большое количество документов);

— масштабируемость (возможность быстрого увеличения количества пользователей);

— надежность (стабильность работы в условиях перегрузки);

— безопасность (защищенность от несанкционированного доступа);

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

В то же время обеспечение описанных выше преимуществ системы ставит перед разработчиками ряд ограничений при проектировании и разработке. В частности, для облегчения проектирования в подобных случаях архитекторы нередко пренебрегают универсальностью системы, используя жесткий, неконфигурируемый набор документов. При таком подходе отсутствует потребность в гибком дизайнере бизнес-процессов, так как система согласований документов, система проведения документов и механизм получения бизнес-ролей пользователей для конкретного документа меняются очень редко.

С учетом сказанного выше главным архитектурным принципом построения системы "Кодекс: документооборот" является ее модульность (официальный сайт компании "Ко-

декс" http://www.kodeks.ru). Каждое подразделение с автономным учетом документов может иметь автономную систему делопроизводства (модуль). Затем эти модули с помощью изначально заложенной функции обмена объединяются.

Важным элементом системы является надежное хранилище разнотипных документов. Хранилище текстово-графической информации позволяет обеспечить хранение большого количества документов с возможностью поиска по тексту. Система строится по трехзвен-ному принципу, в соответствии с которым часть вычислительных задач возлагается на сервер баз данных, в качестве которого используется СУБД MS SQL Server 2000/2005. Сервер приложений, функционирующий на платформе Microsoft .NET, обеспечивает кеширование информации, безопасность данных, обмен данными с удаленными подразделениями. Клиентская часть предоставляет удобный пользовательский интерфейс, интегрируемый с офисными приложениями.

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

Автоматически поддерживается версионность документов, помещенных в хранилище.

В состав программного комплекса "Кодекс" входит зарегистрированный на основании Федерального закона об электронно-цифровой подписи и успешно функционирующий удостоверяющий центр "Кодекс", возможности которого позволяют обеспечить в соответствии с законодательством РФ электронными сертификатами всех участников ведомственного защищенного электронного документооборота.

Преимущества:

— собственный механизм защиты электронно-цифровой подписи;

— возможность работы с большим количеством клиентских рабочих мест;

— высокий уровень надежности хранения документов;

— модульная структура системы;

— удобный пользовательский интерфейс.

Недостатки:

— закрытый код программы, отсутствие возможности внесения изменений;

— отсутствие дизайнера бизнес-процессов;

— невозможность добавить собственные типы документов.

3.5. EOS for SharePoint. EOS for SharePoint [8] является расширением стандартных функциональных возможностей Microsoft Office SharePoint Server 2007 (MOSS 2007) в области автоматизации электронного документооборота и работы с поручениями.

С использованием базовых возможностей Microsoft Office SharePoint Server 2007 данный продукт позволяет комплексно решать задачи управления контентом организации (официальный сайт продукта "EOS: документооборот" http://www.eos.ru/eos_delopr/).

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

Преимущества:

— настраиваемый пользовательский интерфейс;

— возможность работы с неструктурированной информацией, ее поиск и хранение;

— возможность интеграции данных, обрабатываемых в других приложениях;

— возможность интеграции с другими модулями для дальнейшего развития системы;

— обеспечение защиты хранящейся в системе информации от несанкционированного доступа;

— эффективный механизм поиска информации;

— автоматизация процессов контроля исполнения документов и поручений.

Недостатки:

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

— версионирование файлов только через внешние компоненты;

— эффективная работа только для небольших и средних предприятий;

— отсутствие гибких настроек бизнес-процессов;

— невозможность создания документов различного типа.

3.6. "Нордис/2: корпоративный документооборот". Корпоративная информационная система "Нордис/2" разработана компанией "Алекта" (Новосибирск) (официальный сайт компании "Алекта" http://www.alekta.ru). Система предназначена для средних, крупных и сверхкрупных предприятий и объединений и служит для комплексной автоматизации бухгалтерского, налогового и финансового учетов.

Созданные интеграционные технологии и решения позволяют эффективно использовать преимущества различных информационных систем для комплексной автоматизации процессов управления и технологий конкретного предприятия.

Корпоративное движение информации в системе "Нордис/2" производится на основе служб репликации данных и предполагает организацию следующих информационных потоков:

— централизованный контроль над проектными ресурсами и задачами;

— централизованный сбор первичных, итоговых и отчетных данных;

— репликация общекорпоративных справочников;

— репликация распределенных справочников;

— корпоративный документооборот.

Подсистема "Корпоративный документооборот" системы "Нордис/2" — это обмен электронными документами, такими как акты приема-передачи основных средств, ордеры (накладные), банковские и кассовые документы, извещения (авизо) и др., между структурными подразделениями при совершении ими взаимных операций.

Система "Нордис/2" поддерживает различные схемы передачи документов:

— непосредственно от одного структурного подразделения другому;

— через базу данных вышестоящей организации.

Анализ особенностей подсистемы "Корпоративный документооборот" системы "Нор-дис/2" позволяет заключить, что система представляет собой некоторое промежуточное решение между "Кодекс: документооборот" и "Аналитика: документооборот".

Уровень производительности системы "Нордис/2" достаточно высок, что позволяет применять ее для автоматизации документооборота на средних и крупных предприятиях, кроме того, эта система способна поддерживать достаточно большой набор документов с возможностью выбрать необходимые. В то же время пользователь лишен возможности изменить (расширить) список этих документов, не прибегая к непосредственной помощи разработчиков системы.

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

Преимущества:

— возможность взаимодействия с другими информационными системами;

— наличие (у единственной из рассматриваемых подсистем) развитой системы внедрения и сопровождения;

— возможность интеграции данных, обрабатываемых в других приложениях.

Недостатки:

— в основе принципов проектирования системы лежат требования, обусловленные спецификой крупных производственных объединений;

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

— отсутствие гибких настроек бизнес-процессов;

— невозможность создания документов различного типа.

Заключение. Специфика системы электронного документооборота в исследуемой области (т. е. для предприятий с высокой степенью ответственности за конечный продукт, рассматриваемых на примере ИСС им. Решетнева) предъявляет жесткие и редко меняющиеся требования к документам. Система должна обеспечивать высокий уровень безопасности хранения файл-репозиториев и авторизации участников.

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

Сформулированы основанные на универсальных стандартах ведения документооборота (ГОСТ и ISO) требования, предъявляемые к подобным системам поддержки электронного документооборота.

Несмотря на то что требования, предъявляемые к потенциальной подсистеме "Электронный документооборот" предприятием-заказчиком, не выходят за рамки общих требований, ни одна из представленных в настоящее время на рынке информационных систем не способна в полной мере удовлетворить всем требованиям.

Сравнительный анализ современных программных продуктов, представленных в настоящее время на рынке универсальных решений, показывает, что использование существующих систем в качестве подсистемы "Электронный документооборот" или какого-либо ее компонента нецелесообразно.

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

Список литературы

1. Документооборот: Концепции и инструментарий / Под ред. В. Л. Арлазарова, Н. Е. Емельянова. Б. м.: Едиториал УРСС, 2004. (Тр. Ин-та системного анализа РАН. Антология). 208 с.

2. Электронный документ и документооборот: правовые аспекты. Антология. М.: ИНИОН РАН, 2003.

3. ISO 9001-2000. Системы менеджмента качества. Требования.

4. ISO 5127-2002. Информация и документация. Словарь.

5. Стенюков М. В. Документы. Делопроизводство: Практ. пособие по обеспечению деятельности предприятия. 9-е изд., перераб. и доп. М.: Приор-издат, 2004. 160 с.

6. СТП 154.123-2005. Система менеджмента качества "Обеспечение бортовое программное, управление проектированием, изготовлением и сопровождением".

7. Руководство пользователя StarTeam2005. [Электрон. ресурс]. Режим доступа: http://techpubs.borland. com/starteam/2005r2/en/user.pdf, свободный.

8. Ноэл М. Microsoft SharePoint 2007: Полн. рук. Microsoft SharePoint 2007 Unleashed / М. Ноэл, К. Спенс. М.: Вильямс, 2008. 832 с.

Платонов Юрий Георгиевич — асп. Института систем информатики СО РАН;

тел.: 913-950-60-71; e-mail: y.platonov@mail.ru

Дата поступления — 10.11.2010

i Надоели баннеры? Вы всегда можете отключить рекламу.