Компьютер в бухгалтерском учете и аудите 2000'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Компания "IntellGroup"

Система ТЕКТОН-ДИЗАЙНЕР

 Введение

Традиционный подход к автоматизации хозяйственной деятельности предприятий, предполагающий использование набора автоматизированных рабочих мест (АРМ), обладает определенными недостатками. Эти недостатки, имеющие принципиальный характер, заметно затрудняют процесс автоматизации и ведут к многочисленным непроизводительным затратам времени и ресурсов.

Поясним сказанное на конкретном примере.

Как разрабатывается типичный набор АРМ?

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

На первом этапе конечный пользователь (например, бухгалтер, кассир и т.п.) ставит перед бизнес-аналитиком задачу на создание АРМ.

Однако бизнес-аналитик, детально знакомый с прикладной областью пользователя, не является программистом. Он не в состоянии самостоятельно запрограммировать АРМ с использованием традиционных средств, предназначенных для решения этой задачи. В самом деле, такие средства разработки, как Delphi, Clarion, Clipper или D-Base, с применением которых создаются обычные АРМ, предназначены для профессиональных программистов.

Поэтому бизнес-аналитик, получивший от пользователя задание на разработку АРМ, ставит эту задачу перед программистом или перед группой программистов.

Программисты не знакомы с предметной областью так, как с ней знаком бизнес-аналитик. Они просто реализуют задание последнего настолько хорошо, насколько хорошо его понимают.

Далее бизнес-аналитик принимает готовый АРМ у программистов, высказывает им свои замечания и, как правило, тут же отправляет на доработку. После нескольких промежуточных шагов готовый АРМ передается конечному пользователю.

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

В итоге бизнес-аналитик снова передает АРМ на доработку программистам, и эта доработка, возможно, будет выполнена не за одну итерацию.

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

Сказанное иллюстрируется на рис. 1.

Как видно из этого рисунка, конечные пользователи могут выдавать задания на изменение АРМ не только бизнес-аналитикам, но и непосредственно группе программистов. Такое часто встречается на практике и ведет к еще большей путанице в процессе разработки.

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

Рис. 1. Замкнутый круг процесса разработки АРМ

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

Концепция, принятая в системе ТЕКТОН-ДИЗАЙНЕР

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

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

В основе концепции лежат следующие принципы:

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

Две грани системы ТЕКТОН-ДИЗАЙНЕР

Что же получилось в итоге?

В результате практической реализации новой концепции была создана объектно-ориентированная система ТЕКТОН-Дизайнер (далее — просто ТЕКТОН), предназначенная для автоматизации хозяйственной деятельности предприятий.

Эта система выступает в двух ипостасях — как инструмент для бизнес-аналитика и как виртуальный АРМ для конечного пользователя.

Приступая к автоматизации конкретной прикладной области, бизнес-аналитик получает задание от конечного пользователя. Применяя ТЕКТОН как инструмент, он создает набор документов, отчетов, шаблонов и процедур, а также выполняет другие необходимые действия, формируя виртуальный АРМ.

Иными словами, бизнес-аналитик настраивает ТЕКТОН под конкретную прикладную область, создавая в процессе такой настройки инструмент для конечного пользователя. Полученный инструмент будет применяться для решения задач, возлагаемых на классические АРМ при традиционном подходе. При подключении к системе конечный пользователь вводит свой пароль, после чего система ТЕКТОН показывает себя в том виде, в котором это было предусмотрено при настройке. Заметим, что бизнес-аналитик может задавать для разных пользователей разные права доступа к отдельным объектам системы, что во многих случаях просто необходимо.

Немаловажно, что в процессе такой настройки не требуется привлекать профессиональных программистов. Практически вся работа может быть сделана бизнес-аналитиком с использованием готовых объектов, заложенных программистами в систему ТЕКТОН. Разумеется, при необходимости бизнес-аналитик может заказывать дополнительные компоненты, обращаясь к программистам компании IntellGroup. Заметим, что такая необходимость будет возникать достаточно редко — практически все, что может потребоваться бизнес-аналитику, уже заложено в системе ТЕКТОН и готово к использованию.

В результате цикл разработки информационной системы для автоматизации прикладной деятельности сильно упрощается (рис. 2).

Рис. 2. Цикл разработки при использовании концепции ТЕКТОН

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

Что же касается взаимодействия бизнес-аналитиков с программистами, то оно ограничивается заказом новых компонентов для системы ТЕКТОН. Создание таких компонентов не требует детального знакомства с прикладной областью, и потому на этом этапе также легко достигнуть взаимопонимания между бизнес-аналитиками и программистами.

Таким образом, ТЕКТОН — это инструмент, посредством которого можно смоделировать любую прикладную область, описываемую в виде потока документов. При описании предметной области создается набор виртуальных АРМ, позволяющий работать с документами, обмениваться между пользователями информацией, управлять потоком документов и анализировать его.

В итоге получилась система, которая изначально управляется данными. Являясь объектно-ориентированной, она предоставляет пользователю возможность работать в его прикладной области. При этом пользователь, работающий с виртуальным АРМ ТЕКТОН, не использует понятия базы данных. Он работает с тем, с чем привык — документами, папками, карточками, накладными и так далее.

Преимущества нетрадиционного подхода, использованного в ТЕКТОН

Подводя итог сказанному, перечислим основные преимущества нового подхода, использованного при создании системы ТЕКТОН:

• цепочка заказчик-исполнитель сокращается в три раза, что приводит к значительной экономии времени на разработку и согласование;
• разработчик системы (бизнес-аналитик) очень хорошо владеет предметной областью. При этом разработка ведется с использованием понятий, доступных конечному пользователю и пригодных для описания бизнес-процессов. Это позволяет описать прикладную задачу быстро, наиболее полно и точно;
• для внесения изменений в систему не требуется привлечения программистов — все можно сделать силами бизнес-аналитиков;
• в системе ТЕКТОН применен простой интуитивно понятный интерфейс, не требующий длительного и дорогостоящего обучения пользователей;
• простая настройка рабочих мест, выполняемая при изменении круга задач, решаемых конечным пользователем.

Первый взгляд на ТЕКТОН

Остановимся на рассмотрении системы ТЕКТОН в целом. При этом основная цель, которую мы здесь преследуем,— дать вам представление о том, как выглядит эта система и из каких компонентов она состоит. Мы дадим определение основных понятий, с которыми вы будете сталкиваться при чтении документации и в процессе работы с системой ТЕКТОН, а также раскроем некоторые секреты ее внутреннего устройства.

Из чего состоит система ТЕКТОН

Основные компоненты системы ТЕКТОН показаны на рис. 3. Это главный модуль, база данных, Дизайнер форм, Дизайнер отчетов и Дизайнер процедур.

Рис. 3. Основные компоненты системы ТЕКТОН

Главный модуль системы является приложением, предназначенным как для бизнес-аналитика, так и для конечного пользователя. С помощью органов управления, расположенных в его окне (рис. 4), бизнес-аналитик настраивает ТЕКТОН на конкретную предметную область. В дальнейшем этот же модуль будет запускаться конечным пользователем виртуального АРМ.

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

Благодаря чему?

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

Рис. 4. Главное окно системы ТЕКТОН

Рис. 5. Главное окно Дизайнера форм

Рис. 6. Окно Дизайнера процедур

При этом часть записей базы данных будет изменена, а часть — нет. Чтобы целостность данных, хранимых в системе, не была нарушена, необходимо отменить изменения, сделанные до момента аварийного останова системы.

В то же время обычные СУБД способны отслеживать неполные изменения только отдельных записей, но не документов — ведь СУБД “не знает” структуры вашей информации.

В системе ТЕКТОН производится отмена операций, выполненных над документами не полностью. Поэтому в ней никогда не появятся документы, обработанные “наполовину”.

Еще один важный момент.

Система ТЕКТОН выполняет отслеживание и сохранение всех событий, происходящих в системе. То есть любые действия (даже ошибочные) оставляют свой след и могут быть проанализированы. В результате становится возможным анализ поведения системы в целом и, что интересно, прогнозирование по схеме “что было бы, если…”. А такая информация представляет собой большой интерес для верхнего уровня руководства фирмы.

Заметим, что в процессе работы внутренняя структура базы данных остается скрытой как от конечного пользователя, так и от бизнес-аналитика. Она остается одной и той же вне зависимости от конкретной прикладной области, для которой настраивается ТЕКТОН.

Дизайнеры форм, отчетов и процедур нужны только для бизнес-аналитиков. Они предназначены для проектирования объектов системы ТЕКТОН в процессе ее настройки на прикладные области, и потому не нужны конечному пользователю.

Что проектируется с помощью Дизайнеров?

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

С помощью Дизайнера процедур (рис. 6) бизнес-аналитик может подготавливать процедуры обработки документов, хранящихся в системе. Процедуры составляются из готового набора операторов, название которых отражает ту или иную прикладную область, поэтому для их подготовки также не требуются навыки общесистемного программирования.

Основные понятия системы ТЕКТОН

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

Copyright © 1994-2016 ООО "К-Пресс"