Файл: Моделирование предметной области «Управление документооборотом» с помощью UML (Соответствие требований MoReq2 функциональности DocsVision).pdf
Добавлен: 28.03.2023
Просмотров: 156
Скачиваний: 2
СОДЕРЖАНИЕ
Использование систем электронного документооборота
Проблема выбора систем электронного документооборота
Описание инструмента моделирования
Выгоды внедрения систем электронного документооборота
Функционирование систем электронного документооборота
Предметная область «ДЕЛОПРОИЗВОДСТВО»
Краткий обзор делопроизводства
Построение моделей предметной области «делопроизводство»
Функциональность системы DocsVision
Таблица 3.1. Соответствие требований MoReq2 функциональности DocsVision
3.2 Описание основных элементов DocsVision
3.3 Обоснование применимости системы DocsVision
Введение
Информационные технологии получают всё большее распространение. Расширение использования информационных технологий сказывается и на деятельности предприятий, в частности, осуществляется переход от традиционного бумажного документооборота к электронному. Это обусловлено потребностью организаций сократить время, затрачиваемое на работу с документами, исключить потерю документов. Для управления движением электронных документов используются СЭД. Перед тем, как внедрить подобную систему необходимо её выбрать. На текущий момент не существует единой методологии выбора и внедрения СЭД. Оценка применимости СЭД осуществляется путем анализа функциональности или при помощи экспертных оценок. Однако, функциональность не отражает, насколько СЭД соответствует процессам организации, а при экспертной оценке всегда существует субъективный фактор. Анализ СЭД занимает значительное время, сложно представить структуру программы в целом.
При осуществлении проектов по внедрению СЭД следует учитывать, что внутри компании существуют группы заинтересованных лиц, которые имеют различающиеся цели. Например, участники документооборота предприятия нуждаются в адекватной системе электронного документооборота, которая позволит быстро и просто выполнять их ежедневные обязанности. Менеджеры предприятий целями внедрения могут выбрать повышение контроля исполнительской дисциплины и оптимизацию процессов компании. Для достижения целей важно сделать правильный выбор СЭД.
В данной работе будет рассмотрена одна из систем автоматизации электронного документооборота и бизнес-процессов DocsVision.
Использование систем электронного документооборота
Проблема выбора систем электронного документооборота
Сложность выбора СЭД заключается в большом количестве альтернатив и большом количестве критериев. Последствиями неудачного выбора являются не только материальные, временные и организационные потери, но и не достижение организацией поставленных целей и отставание в развитии. Перед окончательным выбором СЭД необходимо провести анализ альтернатив, представленных на рыке. Для этого существуют различные методы, например, метод анализа иерархий, который позволяет сравнить и выполнить оценку многовариантных решений. При его использовании следует выделить основные критерии, важные для организации, например, стоимость лицензии, возможность маршрутизации документов, использование цифровой подписи, параметры поиска документов. Строится иерархическая структура, содержащая цель, альтернативные варианты её достижения, критерии для оценки. Далее определяются приоритеты методом парных сравнений, которые определяют относительную предпочтительность элементов. Приоритеты представляют собой безразмерные величины, что позволяет сравнивать разнородные факторы. После синтеза глобальных приоритетов мы получаем решение, которое наилучшим образом согласуется с пониманием сути проблемы лица, принимающего решение. [1] Для реализации данного метода обычно используются программные средства, что упрощает задачу.
Другой метод для выбора СЭД это сравнительный анализ функционального наполнения СЭД на основе количественных показателей. [2] Составляется полный список функций систем документооборота, то есть, описывается эталонная СЭД для организации. Далее вычисляется интегральная количественная оценка функционального наполнения конкретной системы. Для этого определяется степень пересечения множеств функций этой системы и эталона. Описание эталонной системы может быть основано на спецификации MoReq 2 [3], в которой описаны как функциональные так и нефункциональные требования к СЭД. В частности, поиск, извлечение и отображение документов, администрирование, идентификация объектов, ввод и регистрация документов, сроки хранения, требования к метаданным.
Наличие конкурентного рынка СЭД стимулирует производителей постоянно развивать свой продукт и выпускать новые версии. Важно, чтобы функциональность соответствовала потребностям именно вашей компании. Современные системы, лидирующие на рынке, декларируют практически одинаковую функциональность, что усложняет выбор. Однако, одинаковые функции в разных системах реализованы по-разному, что отражается на эксплуатации системы. Поэтому выбор нельзя основывать только на анализе функциональности.
При выборе СЭД компании обычно ориентируются на следующее:
-
-
- наличие требуемой функциональности;
- цена;
- удобство интерфейса, простота использования;
- возможность интеграции с функционирующими в организации информационными системами и приложениями;
- возможность внесения изменений в систему;
- соответствие СЭД стандартам;
- репутация производителя СЭД на рыке.
-
Также важно учесть соответствие структуры СЭД структуре процессов предприятия, иначе в ходе эксплуатации системы могут возникнуть сложности: системой будет неудобно пользоваться, может возникнуть необходимость её доработки. Для выявления соответствия предлагается использовать сравнение структурных моделей.
В основе любой программы лежит некая база понятий, которая может соответствовать или не соответствовать понятийной базе делопроизводства. Основные понятия области делопроизводства представлены в стандарте РФ ГОСТ Р 51141-98 «Делопроизводство и архивное дело. Термины и определения». Поэтому он был принят в качестве основы для разработки модели данной предметной области. Понятийная база системы Docsvision будет сопоставлена с понятийной базой стандарта РФ ГОСТ Р 51141-98 посредством сравнения разработанных моделей.
В качестве инструмента планирования и управления проектом был выбран логико-структурный подход. Для того, чтобы учесть реальные потребности участников проекта и отобразить общее представление о текущей ситуации были составлены анализ заинтересованных сторон (таблица 1.1.) и дерево проблем (рисунок 1.1.)
Таблица 1.1. «Матрица заинтересованных сторон»
Группы заинтерес ованных лиц |
Какова их выгода |
Форма поддержки проекта с их стороны |
Адекватный механизм участия |
Руководит ель проекта |
+опыт управления проекта +новые знания |
Управление работами проекта |
управление командой проекта управление сроками проекта анализ результатов проекта предоставление отчетности |
Команда проекта |
+опыт реализации проекта +новые знания |
Реализация работ проекта |
выполнение работ проекта (анализ, составление моделей, написание рекомендаций) предоставление информации о ходе проекта |
Руководст во организац ии |
+Повышение управляемости процессов +Повышение эффективности системы документооборота (сокращение времени на поиск, перемещение, согласование документов) -финансовые затраты -рост издержек |
Предоставлен ие ресурсов Информацион ная поддержка |
Предоставление человеческих ресурсов Представление финансовых ресурсов Предоставление помещений/оборудования Предоставление необходимой информации |
Сотрудни ки компании |
+упрощение работы с документами +новые знания -необходимость осваивать новое ПО -дополнительная нагрузка во время внедрения |
Участие в реализации проекта |
изучение ПО использование предоставление обратной связи |
Вендоры СЭД |
+новые покупатели +новый опыт внедрения +имидж |
Информацион ная поддержка Проведение работ по внедрению |
предоставление демо- версии СЭД предоставление нормативной документации Установка и настройка ПО обучение сотрудников компании доработка и настройка ПО |
Рис. 1.1. Дерево проблем
На основе дерева проблем сформулированы цели и представлены в виде иерархии (рисунок 1.2.) На нижнем уровне представлены задачи, реализуемые в ходе проекта. Общей целью проекта является внедрение СЭД.
Рис. 1.2. Дерево целей
Краткое содержание проекта заложено в логико-структурной матрице (таблица 1.2.)
Таблица 1.2. Логико-структурная матрица проекта
Текст |
Показатель достижения |
Источники информации и средства измерения |
Допущения и риски |
Общая цель: внедрить систему электронного документооборота |
Наличие акта о внедрении СЭД |
Внутренняя документация компании (наличие/отсутствие) |
Риски: недостаточна я мотивация руководства |
Конкретная цель: предложить методологию для внедрения СЭД |
Использовани е методологии |
Отчет об использовании |
Риски: кардинально е изменение технологий на рынке СЭД |
Результаты: структурные модели предметной области документооборота структурные модели СЭД для внедрения |
Рекомендации на основе сравнения моделей |
Наличие/Отсутствие |
Риски: изменение стандартов в области делопроизво дства недостоверн ость информации о СЭД |
Действия. Изучение предметной области делопроизводства (стандарты, статьи) Выбор нотации для построения моделей |
Ресурсы: Трудовой ресурс Литература для изучения ПО для построения |
Затраты |
Допущения: Достаточное финансирова ние со стороны руководства Достаточное количество |
Продолжение табл.1.2.
Выбор программного обеспечения для построения моделей Разработка моделей делопроизводства Изучение демоверсии DocsVision Разработка моделей системы DocsVision Сравнение Моделей делопроизводства и моделей DocsVision Написание рекомендаций по внедрению DocsVision |
моделей |
трудового ресурса |
Описание инструмента моделирования
Для построения модели будет использоваться объектно- ориентированный графический унифицированный язык моделирования UML (Unified Modeling Language). Этот язык широко распространен в программной индустрии, также этот язык стандартизирован и управляется OMG (Object Management Group), которая представляет собой открытый консорциум компаний. UML использует объектно-ориентированный подход. При таком подходе система может быть декомпозирована на множество отдельных сущностей, которые называют классами. Классы соединяются связями и описывают структуру системы. Язык UML для описания системы предусматривает 13 типов диаграмм, подразделяющихся на диаграммы структуры и диаграммы поведения.[4] Для построения моделей в данной работе будут использоваться диаграммы классов.
Диаграмма классов относится к диаграммам структуры. Она является основным способом описания структуры системы в статическом состоянии. В дополнение к ней используются диаграммы компонентов, составных структур, развёртывания, объектов и пакетов. На диаграмме классов отображаются типы объектов системы, их свойства и отношения между ними. «Объекты обладают набором состояний, в которых они могут находиться, и определенным поведением. На связи между объектами могут накладываться ограничения, которые тоже отображаются на диаграмме. Класс подразумевает объекты, которые обладают одинаковой структурой и поведением, одинаково взаимодействуют с другими классами.» [5] Классы отображают основные понятия системы. Каждый класс обладает свойствами, которые описываются атрибутами и ассоциациями.
На диаграмме класса обычно изображают существенные элементы, которые необходимы для понимания общей картины, опуская незначительные детали. Но диаграмма не должна вводить читателя в заблуждение относительно важных аспектов семантики. Все элементы должны соответствовать требуемому уровню абстракции.
На диаграмме класс изображается в виде прямоугольника, разделенного горизонтальными линиями. В верхней части прямоугольника находится уникальное имя класса, обычно это существительное. Вторая секция прямоугольника содержит атрибуты класса, которые выражают свойства, общие для всех объектов данного класса. «Атрибут представляет собой стоку текста, которая включает видимость, имя, тип, кратность и значение по умолчанию. Видимость обозначает доступность атрибута для других классов и отображается с помощью символов.» [4] Например, «+» означает, что атрибут доступен (виден) любому другому классу, для которого определена диаграмма, «#» означает, что атрибут доступен только подклассам данного класса.
Другой способ отобразить свойства – это ассоциация (непрерывная линия, проведенная от исходного класса к целевому, который является типом свойства).
«В третьей секции прямоугольника класса отображаются операции, которые отображают действия, совершаемые представителем класса.»[6]
Для построения диаграмм классов в нотации UML существует ряд программных средств: Microsoft Visio, Umbrello UML Modeller, StarUML, Dia.