Принципы построения систем для расчета производственных расписаний
Человекоориентированный интерфейс пользователя
Обратная связь с конечным пользователем
Настраиваемое представление результатов
Качественная сопроводительная документация
Как известно, качество информационной системы и возможность ее эффективного применения во многом определяются теми идеями, которые заложены в ее основу. В «САПР и графика» № 5’2008 мы познакомили читателей с MES-системой Zenith SPPS. В данной статье представлены основные идеологические установки и подходы, на основе которых она была построена. Надеемся, что изложенный далее материал поможет лучше понять, что представляет собой Zenith SPPS и каково ее будущее.
Очевидно, что сформулированные принципы создания систем достаточно универсальны и могут быть использованы применительно не только к MES, но и к другим высокотехнологичным информационным компонентам предприятия.
Человекоориентированный интерфейс пользователя
К сожалению, в России теория создания пользовательских интерфейсов малоизвестна и используется недостаточно. А ведь для конечного пользователя интерфейс программного продукта и сам программный продукт — одно и то же (конечно, здесь под интерфейсом понимается не только «красивая картинка» — это и действия пользователя, и тот отклик, который он получает в ответ). Многие специалисты постепенно приходят к правильным идеям, не зная, что они уже давно формализованы и оформлены в виде теории. Даже на Западе лишь лучшие разработчики активно применяют теоретические правила построения интерфейсов (эти правила очень эффективны). Быть может, это связано с тем, что данная теория относится к области прикладной психологии и программисту-технарю надо иметь очень большой опыт, чтобы понять ее ценность. В плане интерфейса стали хуже и некоторые западные разработки, что, видимо, связано с передачей программных продуктов на аутсорсинг в Индию и другие страны, где соответствующих специалистов еще меньше.
Можно привести ряд примеров, не касающихся напрямую систем расчета расписаний, но весьма показательных. Все знают о том, что многие пользователи не хотят переходить с Windows XP на Vista. По нашему мнению, это связано не только с тем, что новая операционная система требует больше ресурсов и обновленных драйверов, но и с тем, что пользовательский интерфейс, получив косметические изменения, не стал существенно удобнее. Другой пример: интерфейс среды программирования Delphi 2007 по сравнению с Delphi 7 для решения тех же, часто повторяющихся задач требует от пользователя большего количества элементарных операций с мышью, что, безусловно, нарушает один из основных «законов интерфейса»: система не должна вынуждать пользователя выполнять действия сверх необходимых.
Разработчики системы Zenith SPPS — одни из немногих на отечественном рынке, кто использует теорию построения человекоориентированных пользовательских интерфейсов в качестве рабочего инструмента.
 |
|
Кибернетичность
Основные принципы кибернетики были сформулированы много лет назад, но важность их не всегда осознается разработчиками. Между тем кибернетика рассматривает особенности информационных систем независимо от их материальной природы и таким образом разрабатывает общие принципы их создания. Наиболее применяемые и коммерчески успешные компьютерные системы и приложения высококибернетичны. Например, ни одно из основных приложений Microsoft Office не привязано к какой-либо предметной области. То же самое можно сказать и о наиболее популярных операционных системах, и о web-сервисах. В чем причина популярности таких систем?
Кибернетическая идеология позволяет делать системы очень гибкими. Допустим, мы создали информационную систему, эффективно обслуживающую изготовление штампов на автозаводе. Сможем ли мы использовать ее для изготовления пресс-форм? Применима ли она на другом автозаводе с несколько иной системой управления? Сможем ли мы эксплуатировать эту систему через 10 лет на исходном предприятии? Да, если система достаточно абстрактна и такие сущности, как «автозавод» или «штамп», не вшиты в ядро системы, а являются ее настройками.
Мощь кибернетического подхода была проверена авторами данной статьи на практике. Система Zenith SPPS изначально была создана для поддержки процессов механообработки на машиностроительных предприятиях. Затем развитие, казалось бы, чисто абстрактных возможностей системы позволило достаточно легко внедрить ее на предприятии по сборке мебели. Далее выяснилось, что при незначительных доработках Zenith SPPS можно применять для контроля за использованием офисных и учебных помещений (рис. 1). Интересно, что доработки, необходимые для этого, позволяют более эффективно применять систему и в механообработке, и в производстве мебели. Это значит, что создатели Zenith SPPS на верном пути.
a
b
в
Рис. 1. Система Zenith SPPS 2.0, настроенная для различных сфер деятельности: а — механообработка в инструментальном производстве; б — изготовление мебели; в — учебный процесс в вузе
В основе каждой прикладной кибернетической системы должна лежать некая легко осознаваемая информационная структура, вокруг которой располагается максимально полный набор обслуживающих алгоритмов. В электронной таблице такой структурой является двумерная матрица с поименованными строками и столбцами. В текстовом процессоре это собственно текст (он кибернетичен по своей природе), в системе, поддерживающей производственные расписания, — распределение во времени взаимосвязанных работ по рабочим местам.
Если базовая информационная структура и специализированные алгоритмы отсутствуют, то система рискует стать слишком абстрактной и примитивной. Бывают случаи, когда прикладная информационная система представляет собой набор настраиваемых форм для ввода и просмотра данных, причем имеющиеся настройки не подходят большинству пользователей. Такие системы являются по существу обычными универсальными СУБД, хотя и стоят дороже. Иногда встречаются системы с собственным языком программирования, но без реализованных специализированных алгоритмов. Такие системы близки к обычным средам программирования, но зачастую менее универсальны и удобны. Разработчики системы Zenith SPPS стараются избегать подобных ситуаций.
|
|
Технологии быстрой разработки
На начальных этапах создания Zenith SPPS (более 10 лет назад) ее разработчики анализировали результаты деятельности ведущих фирм — разработчиков ПО (в основном зарубежных) и сопоставляли их с собственным опытом. В итоге были сформулированы определенные правила развития системы. Позже, когда появились публикации о технологии быстрой разработки приложений (Rapid Application Development, RAD), стало ясно, что именно эта технология и используется с точностью до мелочей.
Под термином RAD обычно понимается процесс разработки информационных систем, содержащий три элемента:
- небольшую, хорошо управляемую команду профессиональных разработчиков (от двух до десяти человек);
- короткий, но тщательно проработанный и контролируемый производственный график (от двух до шести месяцев);
- повторяющийся цикл, при котором разработчики по мере того, как система начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в ходе взаимодействия с пользователями.
Наиболее важны следующие принципы RAD-технологии:
- разработка системы итерациями;
- вовлечение конечных пользователей в процесс разработки;
- обеспечение целостности проекта;
- применение средств и сред быстрой разработки приложений;
- тестирование и развитие проекта, осуществляемые параллельно с разработкой;
- грамотное руководство разработкой.
Таким образом, по методологии RAD жизненный цикл системы расчета производственных расписаний состоит из анализа и планирования требований, проектирования, построения и внедрения.
Технология RAD реализует лишь один из возможных подходов к разработке автоматизированных информационных систем. Разработчикам, безусловно, следует иметь представление и о структурном подходе, и о различных аспектах и возможностях CASE-технологий. Главное, чтобы эти подходы ощутимо повышали качество и снижали стоимость системы, не были вещью в себе.
|
|
Обратная связь с конечным пользователем
На данную тему сказано уже много, это всеми одобряется и общепризнанно. Конечно, важно найти и наладить сотрудничество именно с теми пользователями, которые способны достаточно глубоко разобраться в системе и сформулировать свои требования на языке, понятном специалистам фирмы-разработчика. Работать с такими пользователями непросто — нередко они весьма требовательны, — но необходимо.
|
|
Настраиваемое представление результатов
Любая система (не только MES) должна уметь отображать результаты своей работы в виде, удобном для восприятия. Если система использует в качестве хранилища информации реляционную базу данных, то для этого целесообразно применять так называемые генераторы отчетов. По нашему мнению, генератором отчетов можно считать программный пакет или модуль, поддерживающий следующий минимальный набор функций:
- получение информации из БД при помощи языка SQL;
- визуальное проектирование отчетов;
- предварительный просмотр и печать отчетов;
- мастер для создания простых (базовых) отчетов;
- сохранение отчетов в виде файлов электронных таблиц и HTML-файлов.
Конечно, приветствуются и другие функции и возможности: расширенный набор форматов для сохранения, языки макрокоманд, построение диаграмм (рис. 2) и т.д.
Концепция генератора отчетов предполагает относительно легкую процедуру привязки данных к отдельным частям документа, предназначенного для вывода на печать. Сами документы при этом иногда несколько «формализованы». В этом смысле генераторы отчетов противоположны электронным таблицам и текстовым процессорам. В Word или Excel можно создать практически любой документ, однако привязка сложных документов к базе данных и автоматическое извлечение информации из них — задача нетривиальная.
|
|
Качественная сопроводительная документация
Еще в советские времена студентов — будущих специалистов по автоматизации учили, что информационные системы имеют не только программное, но и техническое, организационное и методическое обеспечение. Формулировка несколько сухая, но верная. Хорошее описание того, как при помощи автоматизированной системы решать те или иные практические задачи, является важной, полезной и неотъемлемой частью системы. Интересно, что согласно теории идеальный интерфейс не должен требовать от специалиста поиска информации в контекстной справочной системе или в руководстве. Однако в реальной жизни дело чаще всего обстоит так, что идеальных пользовательских интерфейсов не существует или пользователь может оказаться недостаточно квалифицированным.
Сопроводительная документация, даже если она оформлена в виде обычной книги, все равно реализует интерфейс пользователя, работающий, правда, лишь в одну сторону — получение информации. Поэтому при подготовке сопроводительной документации следует использовать те же правила создания человекоориентированного интерфейса, но уже применительно к тексту.
В процессе подготовки документации необходимо выполнить их структуризацию. Для повышения понимаемости технических текстов их рекомендуют разбивать на небольшие главы, примерно одинаковые по размеру. Главы группируются в разделы, но их нумерация остается сквозной. Заголовки глав и разделов должны быть точными и вместе с тем разнообразными.
Повсеместное применение вычислительной техники привело к значительному сокращению времени подготовки текстов, чертежей, плакатов и другого иллюстративного материала. Вместе с тем возросли требования к качеству оформления сопроводительной документации. Не будет преувеличением сказать, что распространенные сейчас текстовые и графические редакторы задают новые стандарты качества. Пользователю персонального компьютера предлагается множество визуальных средств, способных существенно улучшить качество оформления текстового материала. Прежде всего это различные шрифты и отступы, маркеры, таблицы, схемы и диаграммы. Активно используются и «гибриды»: таблицы-рисунки, блок-схемы и т.д.
|
|
Интегрируемость
Разрабатывая систему расчета производственного расписания, как и любой другой элемент системы управления предприятием, необходимо предусмотреть средства и инструменты для быстрой и качественной интеграции. Как показывает опыт разработки Zenith SPPS, целесообразно использовать одновременно целый ряд зарекомендовавших себя интеграционных средств.
Во-первых, данные должны храниться в общедоступном формате. Ядро системы расчета расписаний по своей сути — серверная подсистема, поэтому оно может включать значительную часть бизнес-правил работы с данными. В этом случае при использовании в качестве хранилища информации реляционной СУБД можно разгрузить базу данных, не используя правила и процедуры, специфичные для конкретной СУБД. В результате возможно создать высокомасштабируемую систему поддержки производственных расписаний, работающую с данными нескольких наиболее распространенных форматов.
Во-вторых, должны поддерживаться технологии межпрограммного взаимодействия на уровне операционной системы. Это и сохранение данных в файлах распространенных форматов, и импорт данных из этих файлов, и буфер обмена, и технология OLE, и «точки запуска» дополнительных приложений и библиотек.
В-третьих, хорошо, когда система умеет эффективно и с пользой функционировать самостоятельно, является самодостаточной. Это особенно важно на ранних стадиях автоматизации предприятия, когда необходимо приступить к изучению и использованию системы, не дожидаясь завершения работ по внедрению смежных элементов автоматизации.
|
|
