Применение CASE-средств в автоматизации банковской деятельности

По материалам публикаций Interface Ltd.
Составитель С. Маклаков

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

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

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

Создание АБС должно начинаться с функционально-информационного обследования банка и разработки системного проекта, содержащего описание его ФУНКЦИОНАЛЬНОЙ, то есть основанной на процессах (а не организационно-штатной) структуры и информационных потоков. На основании описания деятельности банка разработчик должен сгенерировать оптимальную модель АВС (исходя из текущих и перспективных задач банка) и конфигурацию программно- аппаратного комплекса.

Пример таких корпораций, как банк Emprise в США, планировавший повысить производительность бизнес-процессов на 22% при затратах на реорганизацию в 3,5 млн. долл., а фактически добившийся роста производительности в 12-15 раз и израсходовавший на эти цели только 750 тыс. долл., показывает, что переход на новую аппаратную платформу и современную информационную технологию является необходимым, но не достаточным условием успеха. И этот успех достигается не за счет сокращения расходов, а путем резкого повышения эффективности работы на, так называемых, "интегрированных" рабочих местах и, как следствие, значительным расширением количества и спектра оказываемых услуг при непременном условии высокого качества и оперативности обслуживания клиентов. К сожалению, находясь под влиянием идеи разбиения работы на относительно простые задачи, берущей свое начало еще со времен Адама Смита, большинство людей, работающих в бизнесе, не ориентировано на процессы. Они сосредоточены на выполнении отдельных задач, поручаемых соответствующим специалистам, например, оформлении заказа, получении товаров на складе и т.д. Ряд ведущих компаний - IBM Credit, Ford Motor и Kodak своим примером для многих открыли путь к реорганизации, ориентированной на процессы.

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

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

Ключ к решению этих проблем дает составленный с помощью CASE- технологий проект, позволяющий

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

Основными этапами создания проекта являются:

  1. проведение функционального и информационного обследования деятельности банка;
  2. разработка структурной функциональной модели (модели процессов) деятельности банка: определение информационных потоков между основными процессами деятельности банка, связей между процессами и внешними обьектами и разработка иерархии диаграмм потоков данных, образующих структурную функциональную модель деятельности банка.
  3. разработка информационной модели разработка логической и физической модели данных (ER-модели) банка;
  4. проведение атрибутного анализа, нормализации и оптимизации модели данных;
  5. генерация схемы данных на SQL
При анализе функциональной моделив первую очередь, необходимо получить ответы на главные вопросы: где находятся наиболее слабые и "уязвимые" места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким (кардинальным) изменениям подвергнется существующая cтруктура организации бизнеса. Анализ "узких мест" в организации бизнес-процессов лучше всего начать с построения модели предметной области "AS-IS" - как она есть, т.е., существующей организации работы. Для создания этой модели можно воспользоваться любой из многочисленных методик моделирования процессов, которые хотя и различаются изобразительными средствами, но основаны на одном и том же подходе - использовании DFD (Data Flow Diagram) - диаграмм потоков данных. Поэтому, выбор средств моделирования и соответствующего программного обеспечения, как правило CASE (Computer-Aided Software Engineering) - автоматизированного средства проектирования, зависит от методологических предпочтений системного аналитика и опыта работы. Однако, разработанные для проектирования программного обеспечения, средства DFD ориентированы на системных аналитиков и разработчиков (программистов) и не учитывают особенностей восприятия менеджерами своей предметной области. Для описания бизнес-процессов менеджерам требуются более мощные выразительные средства, чем описание входов и выходов на диаграммах потоков данных.

С точки зрения менеджеров, наиболее подходящим языком моделирования бизнес-процессов на стадии создания моделей предметной области является IDEF0 (аббревиатура слов ICAM Definition Methods - руководства, где были описаны языки моделирования процессов - IDEF0, данных - IDEF1, позже расширен до поддержки реляционных моделей - IDEF1X и IDEF2 - для описания динамических систем). Это язык моделирования появился в результате применения SADT (Structured Analysis and Design Technique) - технологии структурного анализа и проектирования в программе интегрированной компьютеризации производства (ICAM - Integrated Computer-Aided Manufacturing), разработанной около 20 лет назад. К настоящему времени IDEF0, как язык описания бизнес-процессов, стал федеральным стандартом в США и быстро распространяется в Европе. Его успеху, в немалой степени, способствовала фирма Logic Works (США), создав на основе IDEF0 свой популярный среди менеджеров программный продукт BPwin.

При использовании BPwin, моделирование, т.е. процесс создания точного описания бизнес-процессов системы, начинается с определения субъекта, цели и точки зрения модели. В этом смысле, модель является некотороым толкованием описываемой системы. Поэтому, определяя в качестве субъекта саму систему, необходимо точно установить, что входит в систему, а что лежит за ее пределами. С этим вопросом тесно связана позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Для того, чтобы сконцентрировать внимание именно на описываемой системе, не отвлекаясь на посторонние субъекты, добиться согласованного описания всей системы в действии и, тем самым, ответить на все поставленные (целевые) вопросы, IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

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

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

Отмеченные в модели "AS-IS" недостатки существующей организации бизнеса можно учесть при создании модели "TO-BE" - модели новой организации бизнес-процессов.

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

Создаваемые в BPwin функциональные модели могут существенно упростить разработку проектов реорганизации бизнес-процессов с помощью средств календарного и сетевого планирования в таких распространенных программных продуктах как MS Project (Microsoft) и Time Line (Symantec). Однако, еще более эффективным является использование BPwin-моделей на первых двух этапах - планирования и анализа, жизненного цикла (включающего, также, этапы проектирования, реализации, тестирования и сопровождения) создания информационной системы. В этом случае, удается гораздо быстрее и точнее сформулировать требования к создаваемой информационной системе и проанализировать различные варианты ее реализации с использованием встроенных в BPwin средств анализа стоимости (ресурсов, затрат) по типу: "что, если...", аналогичных применяемым в известном программном продукте EasyABC фирмы ABC Technologies (США).

Для создания задач по созданию и оптимизации структуры данных на основе моделей процессов необходимо использовать CASE-средство, позволяющее быстро и эффективно создавать ER-модель, которая позволяет с одной стороны, документировать проект, а с другой, - генерировать схему базы без необходимости глубокого знания DDL (языка определения данных) и SQL (структурного языка запросов).

ERwin фирмы Logic Works как раз и является средством. В его названии отражается то, что это средство создания ER-моделей на PC под Windows. Но не это на самом деле является определяющим. ERwin интегрируется с ведущими средствами разработки клиентской части и генерирует схему БД для всех ведущих СУБД.

Есть возможность обмена данными с другими средствами семейства Logic Works (BPWin) , которые позволяют строить модели бизнеса (функциональную и объектную).

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

ERwin также дает возможность выбирать в качестве хранилища-репозитория проекта любую из поддерживаемых СУБД. Это дает возможность особо искушенному пользователю получать отчеты о содержимом репозитория, используя SQL и другие средства СУБД. Такой подход позволяет управлять версиями модели. Для более изощренного управления версиями можно воспользоваться встроенной связью с PVCS.

В качестве средств разработки клиентской части поддерживаются три наиболее популярных в мире средства: SQLWindows, PowerBuilder, Visual Basic.

Выбор платформы для использования в качестве сервера существенно шире. Поддерживается большинство ведущих наиболее популярных реляционных СУБД, а также т.н. настольные системы: Access, FoxPro, dBase, Clipper, Paradox.

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

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

ERwin хорошо управляет процессом подключения к серверу и выдает понятные сообщения, описывающие проблему, если она возникает.

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

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

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

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering).

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

Подробная информация по каждому объекту вводится посредством целого семейства редакторов.

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

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

Можно производить манипуляции атрибутами в технике "drag & drop". Работая в редакторе текстового описания связи, можно просматривать всю модель в специальном окне, не покидая редактора.

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

ERwin обладает весьма изощренными средствами представления и отображения модели данных с разной степенью детализации показываемой информации.

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

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

Есть возможности масштабирования изображения и сохранения одновременно нескольких вариантов отображения для повышения степени наглядности и удобства работы.

Сохраняемое отображение - интересная возможность, которая позволяет легко просматривать модель, обращая внимание на различные ее особенности и детали.

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

ER-модели могут быть очень большими, с их ростом проблемой становится навигация - доступ к нужному фрагменту. ERwin имеет несколько возможностей для этого. Во-первых, масштабирование, во-вторых, для тех, кто может запомнить структуру модели, - опция "Go To" в меню "Edit", которая позволяет перейти непосредственно к выбранной сущности, в-третьих, использование т.н. "предметных областей" (subject area).

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

ERwin содержит несколько средств для получения отчетов, которые позволяют получить информацию о сущностях, атрибутах, связях практически с любой степенью детализации. Сначала всю необходимую информацию можно отобрать и просмотреть на экране. Пользователь управляет процессом отбора и сам определяет, какую информацию включить в отчет. Кроме этого, есть некоторое количество стандартных отчетов, содержимое которых определено заранее. Любой отчет может быть перенесен в Word, Excel, WordPerfect.

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

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

ERwin позволяет автоматически получить всевозможные индексы в среде целевой СУБД: на основе первичных, внешних, альтернативных ключей и инверсных входов.

Для поддержки целостности БД могут быть также созданы триггеры и хранимые процедуры, которые представляют собой программный код на SQL и хранятся на сервере.

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

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

Таким образом, ERwin дает возможность почти полностью запрограммировать сервер.

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

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


Interface Ltd.