Специфицирование документооборота в учреждении
Создание же начального стартового варианта СУД, как потенциального прототипа, всегда дешевле, нежели одномоментное построение законченной автоматизированной системы.
Учет психологического фактора лиц, принимающих и готовящих решения (в дальнейшем - пользователи), предполагает вначале выявление самой организационной структуры учреждения и специфицирование деловых процессов. Причем последовательность проведения специфицирования должна вестись от системных (целостных) представлений к элементам и, что наиболее существенно, при активном участии пользователя. Чтобы разработчик и пользователь понимали друг друга, форма представления спецификаций должна быть образной, графической, а не вербальной, и с минимальным количеством программистской символики.
Визуальные изображения: могут выполнять функции представления в наглядной, образной форме общей картины исследуемой ситуации; используемые в качестве дополнительных средств представления информации, могут повышать надежность понимания ситуации; способствуют повышению привлекательности работы пользователя в процессе специфицирования; наглядно документируют описание объекта автоматизации и позволяют легко их видоизменять при переходе от одного прототипа к другому.
Задачей визуального мышления является ясность, достигаемая благодаря упорядоченности значений. В ходе такого мыслительного прогресса запутанная и бессвязная ситуация с неопределенными отношениями структурно перестраивается, организуется и упрощается, пока наградой разуму за труд не станет образ, который делает значение видимым, т.е. реально воспринимаемым...
(Профессор Рудольф Арнхейм, Гарвардский Университет)
Специфицирование документооборота в учреждении
Анализ и выработка исходных данных для создания СУД проводятся на этапе обследования объекта автоматизации. Существует множество методов, моделей и автоматизированных инструментальных средств поддержки этого этапа (например, IDEF технология). Любые CASE (Computer Aided System Engeeniring) системы являются только помощниками в проведении обследования, скорее целенаправленными на создание формальной спецификации, нежели для адекватного отображения реальности. В большинстве случаев в итоге мы получаем некое абстрактное описание действительности со стороны лица, проводящего анализ. Дальнейшая автоматизация субъективного взгляда может непредсказуемо изменить объект автоматизации, что не обязательно приведет к /спеху всей компании.
Каковы могут быть рекомендации? На наш взгляд их две:
• технология развития СУД в учреждении должна строиться на подходе незавершаемой разработки, то есть технологии постоянного прототи-пирования;
• процесс обследования в первую очередь должен учитывать психологический фактор, то есть ориентироваться на психологию лиц, ответственных за выполнение деловых операций и принимающих решения в объекте автоматизации.
Технология постоянного прототипирования ориентирует как пользователя, так и разработчика СУД на длительный процесс взаимодействия с частыми модификациями и их быстрыми реализациями. Для крупномасштабных учреждений, в которых большие потоки документов, объемная обработка данных, гибкая технологическая линия проведения бизнеса, изменения в самом учреждении довольно частая ситуация. Подыскать для автоматизации универсальное на все случаи жизни решение не представляется возможным.
Отмеченная технология позволяет оперировать инструментальными средствами, с помощью которых возможно быстро изменить созданную ранее автоматизированную систему управления документами. Чтобы не испугать читателя, заметим, что такой подход никоим образом не связан с постоянной откачкой у пользователя финансовых ресурсов. Наоборот, любые изменения проводятся из фонда экономии от внедрения предыдущего прототипа СУД.
Основные подходы и действия к реализации системы электронного документооборота
Среди множества важных подходов к реализации проекта создания системы электронного документооборота (СЭД) выделим основные:
•. максимальное использование имеющихся в учреждении и пригодных для построения системы программно-технических средств и персонала, имеется в виду вычислительная техника, ПО, в том числе СУБД, персонал администрирования фрагментов офисных систем подразделений, где они имеются;
• привлечение для разработки СЭД надежных фирм, длительное время работающих на рынке компьютерных технологий, имеющих значительное число внедрений систем документооборота и устойчивое финансовое положение, поддерживаемых основными фирмами-разработчиками базового ПО.
• максимальное использование готовых решений и фрагментов технологий, использование гибких, настраиваемых, совместимых с системами поставщиков информации (открытых) и допускающих поэтапное внедрение без замены программно-технических средств (масштабируемых) СЭД, встраиваемых в остальные компоненты электронных офисов;
• использование для сопровождения, администрирования и развития
СЭД только персонала учреждения, для чего провести обучение и сер
тификацию специалистов.
Необходимо решить следующие задачи внедрения в учреждение первой очереди электронного документооборота:
• провести подробный анализ и определить исходные данные для создания СУД учреждения, главной составляющей частью здесь может стать инструкция по документообороту;
• выяснить, какие из имеющихся программно-технических и материальных ресурсов могут быть выделены и какие необходимо приобрести дополнительно;
• в соответствии с предоставляемыми ресурсами разработать стратегию создания электронных офисов, особенно выделив разработку первой очереди СЭД;
• найти надежного и перспективного партнера для быстрой реализации первой очереди системы;
• подготовить персонал сопровождения и администрирования.
Модульность и гибкость СУД
Такая сложная система, как СУД крупного учреждения, не может быть реализована одномоментно и сразу во всех подразделениях. Это может быть обусловлено несколькими причинами. Во-первых, внедрение системы не должно приводить к сбою привычного ритма работы персонала. Как правило, система устанавливается в одном или нескольких подразделениях, а затем после проведения необходимых мероприятий по проверке работоспособности и соответствию предъявляемым требованиям она может быть распространена и на другие подразделения. Немаловажную роль играет и недостаточность финансирования всего проекта, тогда как его поэтапная реализация вполне реальна.
Поэтому система должна строиться по модульному принципу, и каждый из модулей решает свою конкретную задачу или выполняет конкретную функцию документооборота. Важно и то, что состав этих модулей может меняться без ущерба для работающей системы. Модули, по возможности, должны быть независимы друг от друга при сохранении глубокой интеграции между ними.
Система должна обеспечивать выполнение минимальных усилий и затрат для адаптации в процессе установки и конфигурирования. Для обеспечения большей гибкости системы (еще на этапе ее проектирования) нужно предусмотреть как можно больше возможностей для последующего внедрения и развития с тем, чтобы избежать значительных временных и иных затрат при поэтапном ее расширении.
Открытость СУД
Требование открытости системы расширяет требования масштабируемости. При росте системы ее идеология должна обеспечивать простое подключение новых собственных приложений и функционирование в гетерогенных распределенных средах. СУД должна также обеспечивать легкое подключение внешних по отношению к ней приложений, а это значит, что приложение должно придерживаться промышленных стандартов1. К ним можно отнести:
• спецификация OLE
• открытые API:
=> Open Data Base Connectivity (ODBC) - доступ к БД различных производителей
=> Messaging Application Programming Interface (MAPI) - доступ к почтовым системам различных производителей
=> Telephony Application Programming Interface (TAP!) - доступ к телефонным сетям различных типов
• коммуникационные стандарты:
=> Windows SNA API - единообразный доступ к мейнфреймам
=> Windows Sockets - единообразный доступ к сетевым сервисам на различных платформах
=> Windows Remote Procedure Call (RPC) - удаленный вызов процедур в распределенных средах
• стандарты для финансовых- и бизнес-приложений:
=> WOSA/XRT- единый способ получения оперативных рыночных данных
=> WOSA/XFS - единообразный доступ к услугам, типичным для приложений
=> Rightarrow Open Document Management API (ODMA) - единый интерфейс работы с приложениями в узлах-клиентах
• Standard Generalized Markup Language (SGML) - стандарт разметки до
кументов.
Поддержка указанных стандартов позволит легко переходить на новые версии приложений или включать в систему новые приложения.
Масштабируемость СУД
Для защиты инвестиций заказчика, вложенных в систему, она должна удовлетворять требованиям масштабируемости. Это означает, что вне зависимости от повышения количественных требований к системе, она продолжает функционировать по-прежнему, не требуя существенных затрат на изменение принципов построения и конфигурирования.
Наращивание мощности системы должно происходить за счет увеличения вычислительных ресурсов и новых информационных хранилищ документов. Причем эта возможность должна быть предусмотрена заранее. Поэтому СУД должна поддерживаться как можно большим числом операционных систем.
С ростом числа подключенных к СУД пользователей (или с увеличением нагрузки) необходимо иметь возможность перехода на более мощную аппаратную платформу сервера.
Интуитивно понятный интерфейс
Еще один подход связан с принципом, называемом прямым манипулированием - "Direct Manipulation". В примитивной реализации он называется drag-and-drop - протащи-и-брось. Основное свойство этого подхода состоит в том, что пользователь взаимодействует с индивидуальными объектами, а не со всей системой как единым целым.
Наиболее мощным инструментарием для разработки пользовательского интерфейса является OSF/Motif [51], который представляет собой пакет, включающий менеджер окон, набор утилит для выполнения различных вспомогательных операций, а также библиотеку объектов.
Motif поддерживает достаточно большой набор классов, позволяющих создавать меню, полосы прокрутки (scrollbar), нажимаемые кнопки, редактирующие элементы и т.д.
Каждый класс объектов Motif имеет достаточно широкий выбор как наследуемых, так и дополнительных, специфичных для него ресурсов. Они позволяют управлять такими важными характеристиками объектов, как цвет фона, местоположение на экране, шрифт выводимого текста и т.д.
Некоторые из классов Motif не используются для создания экземпляров объектов (такие классы в терминологии ООП называются абстрактными). Они содержат в себе самые общие атрибуты и методы, необходимые для функционирования различных типов объектов.
Motif имеет два основных подкласса объектов: класс примитивов и класс менеджеров. Оба этих класса являются абстрактными. Первый из них используется как базовый для классов объектов, не владеющих другими объектами. Примерами являются нажимаемые кнопки, списки и т.д. Второй класс применяется для создания объектов, которые могут иметь и управлять дочерними объектами.
Набор объектов в "конструкторе" Motif широк и разнообразен: простой и составной текст, графика, графические примитивы, группы кнопок с различными взаимозависимостями (радиокнопки и т.п.), поля для ввода различного вида информации (текст, числа и т.п.), диалоговые меню (прокручиваемые, выпадающие, pop-up и пр.), различные сложные формы с изменяемой общей и внутренней геометриями, и многое другое.
Все свойства элементарных и составных объектов Motif изменяемы, допускается как задание их начальных значений, так и их изменение в процессе работы приложения.
Следует отметить, что имеется несколько открытых проблем в разработке UIMS, которые можно определить как: эргономика взаимодействия; управление диалогом; отделение интерфейса пользователя; сопровождение, мобильность и эффективность.
Пока не существует единственной стратегии конструирования пользовательского интерфейса. Нужны эксперименты и опыт. Это сфера быстро развивающаяся и сулящая многочисленные выгоды.
Появившиеся стандарты (пока де-факто), по крайней мере на нижних уровнях систем (X-Window и в какой-то степени OSF/Motif) и активность разработчиков многих фирм, дают надежду, что ситуация в ближайшее время может измениться к лучшему, что обеспечит успешное решение поставленных перед пользователем задач СУД.
Интуитивно понятный интерфейс
В составе UIMS должен присутствовать инструментарий WYSIWYG (What You See Is What You Get - что видите, то и получаете) - для облегчения конструирования макетов экранов, структур меню и диалоговых последовательностей.
Желательно наличие инструментов, которые могли бы помочь дизайнеру интерфейса вникнуть в суть поставленной задачи, которую конечный продукт и призван решать. Эти инструменты могли бы помочь выработать модели данных и поведения пользователя при работе с ними, оказать содействие при поиске документов и добыче данных (data mining). Инструментарий должен также предоставлять средства для быстрого создания прототипа, который можно было бы многократно использовать в конечной системе -для экономии времени и сил.
UIMS предоставляет возможность настройки интерфейса разработчиком или конечным пользователем. Управление настройкой может быть лексического уровня, например, пользователь определяет, где и как расположены меню и другие интерактивные графические объекты на экране, использовать ли для привлечения внимания звуковой или световой сигнал.
Компоненты, допускающие многократное использование, повышают производительность труда как программиста, так и дизайнера; они предоставляют возможность стандартизации и гарантии полной проверки всех составных частей интерфейса. Поэтому желательно, чтобы UIMS имела средства для универсализации программных компонентов - для облегчения их повторного использования. Такие средства могут представлять собой отладочные, проверочные и аналитические инструментарии.
При разработке пользовательского интерфейса можно выделить следующие три объекта, для каждого из которых ставятся различные цели.
1. Интерфейс с пользователем: согласованность; поддержка пользователя разного уровня; обеспечение обработки ошибок и восстановления.
2. Разработчик программного обеспечения: предоставление абстрактного языка для конструирования интерфейса пользователя; предоставление согласованных интерфейсов для связанных прикладных задач; обеспечение простоты изменения интерфейса на стадии его проектирования (быстрое создание прототипа); упрощение разработки повторным использованием программных компонентов; обеспечение простоты изучения и использования прикладных программ.
3. Конечный пользователь: согласованность интерфейса по прикладным программам; многоуровневая поддержка сопровождения или функций помощи; поддержка процесса обучения; поддержка расширяемости прикладных программ.
Здесь также возможны разные формы реализации:
• размещение на экране интерактивных средств (меню, кнопки и т.п.) и их привязка к фрагментам, написанным разработчиком интерфейса;
• сеть статичных страниц (кадров), содержащих тексты, графики, интерактивные средства;
• спецификация по демонстрации.
Интуитивно понятный интерфейс
Программист использует этот инструментарий для организации взаимодействия с человеком. Инструментарий содержит набор функций, реализующий компоненты интерфейса нижнего уровня такие как: меню, кнопки, зоны диалога, подокна, зоны прокрутки. Инструментарий включает также графическую библиотеку вывода (только основные примитивы) и обработчик событий.
Основной концепцией UIMS является идея строгого разделения интерфейса и прикладной программы. В идеале она должна поддерживать все стили диалога и упрощать построение сложных интерфейсов. UIMS должна обеспечивать язык определения интерфейса для представления требуемого диалога и генератор, который автоматически создает необходимый код из исходного определения в этом языке.
Основной целью UIMS является освобождение программиста не только от низкоуровневого программирования и заботы о непосредственном управлении устройствами ввода/вывода, но и от проблем интерфейса, носящих не программный, а например, эстетический характер. Такие проблемы являются вотчиной художников, дизайнеров интерфейсов, а также предметом исследований в психологии, эргономике и т.п.
Система, обычно, включает, как составную часть, набор инструментов для обеспечения поддержки создания, отладки, тестирования и апробирования интерактивных человеко-компьютерных систем. UIMS должна включать обстоятельное множество инструментов дизайнера интерфейса. UIMS призвана снижать затраты на создание программного обеспечения.
Разработчику программного обеспечения должна быть предоставлена возможность создания интерфейсов, совместимых между разными прикладными программами. Полезным свойством является гибкость системы в смысле возможности поддержки пользователей разного уровня подготовки: от полных "чайников" до опытных "зубров" - такая гибкость делает прикладную часть программного продукта независимой от уровня пользователя и операционной среды.
Интуитивный интерфейс должен быть самодокументированным и предоставлять информационную поддержку различных уровней. Конечный пользователь должен иметь возможность подогнать интерфейс под свои потребности (эстетические, профессиональные) с тем, чтобы сделать его более легким в использовании.
Множество требований, предъявляемых к UIMS, и критериев их оценки строится исходя из основной эталонной модели UIMS. Эта модель представляет систему в виде двух компонентов: инструментария, используемого на стадии разработки диалога - (язык спецификации диалога, готовые библиотечные модули, реализующие стандартные функции (widgets), компилятор с языка спецификации и средства разработки диалога); и части, относящейся ко времени исполнения (run-time portion) - (интерфейс с прикладной программой, средства управления диалогом и графические модули). UIMS обычно предоставляет способ управления последовательностью действий конечного пользователя.
Интуитивно понятный интерфейс
Можно классифицировать существующие инструментарии по следующей схеме:
• текстовые экранные системы;
• графические экранные системы;
• многооконные системы (WMS - Windows Management System);
• UIMS - User Interface Management System - система (управления)
пользовательского интерфейса.
Эта схема не претендует на систематическую классификацию, скорее, это просто перечисление. В последнее время наибольшие усилия прикладываются к разработке методов и созданию инструментальных систем - UIMS.
Наблюдающееся в последнее время бурное развитие графических интерфейсов оказало чрезвычайно большое влияние на все последующее развитие человеко-машинного взаимодействия. Основные идеи современного интерфейса с пользователем на современных рабочих станциях включают следующие элементы:
• управление окнами;
• использование графических символов (пиктограмм) для представления объектов;
• стиль взаимодействия, называемый непосредственным манипулированием;
• популярность мышки как устройства позиционирования на экране;
• объектно-ориентированный стиль программирования.
Многооконная технология обеспечивает пользователя доступом к большему объему информации, чем это возможно при работе с одним экраном. Окна дают доступ ко множеству источников информации. Пользователь может объединять информацию от нескольких источников, исследовать информацию на разных уровнях детализации. В мультипрограммном режиме есть возможность управлять несколькими параллельными задачами. Ввод и вывод каждой задачи отображается в разных окнах, позволяя пользователю сосредоточиться по необходимости на какой-либо одной. Интерфейс со стороны оператора и прикладной программы содержит команды заведения/уничтожения окон, изменения их размеров и положения, поднятия наверх, сжатия окна до пиктограммы и восстановления.
Дальнейшее развитие инструментария привело к появлению понятия widget (заготовка) - объекта более сложного, чем набор простых средств ввода в прикладную программу. Такой инструментарий пока не стандартизован, поскольку различные фирмы (Apple, Sun, др.) предлагают существенно разный набор средств как по номенклатуре, так и по функциональным возможностям.
Инструментарий создания пользовательского интерфейса по Майерсу:
"Инструментарий создания пользовательского интерфейса есть библиотека технологических интерактивных средств, дающих возможность использовать физические устройства ввода (мышь, клавиатура, планшет...) для ввода значений (таких как команда, число, положение или имя) при наличии обратной связи, отображаемой на экране ".
