Содержание к диссертации
Введение
ГЛАВА 1. Особенности банковской технологии как объекта автоматизации 10
1.1. Роль и место бухгалтерского учёта в коммерческих банках и проблемы его автоматизации 10
1.2. Состояние рынка технологий разработки автоматизированных банковских систем 17
1.3. Обоснование выбора спиральной модели проектирования автоматизированных систем бухгалтерского учёта на основе КЕЙС-технологий 35
Выводы 42
ГЛАВА 2. Методологические основы применения кейс-технологий при проектировании банковских систем бухгалтерского учёта 43
2.1. Концепция КЕЙС-технологий в приложении к проектированию систем бухгалтерского учёта 43
2.2. Разработка методики проектирования систем бухгалтерского учёта на основе КЕЙС-технологий 52
2.2.1. Разработка диаграммы потоков данных подсистем бухгалтерского учёта 53
2.2.2. Разработка концептуальной схемы базы данных банковских информационных подсистем 60
2.2.3. Описание спецификаций приложений подсистем бухгалтерского учёта 70
2.2.4. Разработка логической схемы базы данных банковских информационных подсистем 73
2.2.5. Разработка прикладных программ подсистем бухгалтерского учёта 80
2.2.6. Выбор архитектуры информационной системы коммерческого банка 83
2.3. Анализ особенностей использования современных КЕЙС-средств при проектировании систем бухгалтерского учёта 90
2.3.1. Характеристика современных КЕЙС-средств применительно к проектированию систем бухгалтерского учёта 90
2.3.2. Сравнительная характеристика КЕЙС-средств 102
2.3.3. Технология освоения и внедрения КЕЙС-средств в коммерческом банке 105
Выводы 112
ГЛАВА 3. Практическая реализация методологии проектирования системы бухгалтерского учёта на основе кейс-технологий 114
3.1. Подсистема "Многовалютный операционный день" 115
3.2. Подсистема "Прогноз кредитно-депозитных ресурсов" 125
3.3. Подсистема "Учёт ценных бумаг" 131
Выводы 140
Заключение 181
Литература
- рынка технологий разработки автоматизированных банковских систем
- Обоснование выбора спиральной модели проектирования автоматизированных систем бухгалтерского учёта на основе КЕЙС-технологий
- Разработка методики проектирования систем бухгалтерского учёта на основе КЕЙС-технологий
- Подсистема "Прогноз кредитно-депозитных ресурсов"
Введение к работе
Актуальность проблемы. Банковская система РФ находится на стадии развития и совершенствования. Российские банки постоянно расширяют спектр предоставляемых услуг, стремясь успешно конкурировать на внутреннем и мировом рынках. В тоже время, процессы глобализации обострили международную конкуренцию на рынке банковских услуг, что приводит к постоянному увеличению ассортимента и повышению качества стандартного пакета услуг. Законодательная среда претерпевает перманентные изменения: идут реформы налогового законодательства и бухгалтерского учета, преобразуется гражданское право.
Успешная работа любого коммерческого банка напрямую зависит от качества функционирования автоматизированной системы бухгалтерского учёта (АС БУ). В современных условиях качество работы АС БУ определяется способностью быстрой адаптации к меняющимся внешним и внутренним условиям функционирования. В такой ситуации наиболее остро встает проблема совершенствования методов и средств разработки и доработки АС БУ.
В настоящее время для проектирования автоматизированных систем широко используются КЕЙС-технологии (Computer-Aided Software system Engineering). Внедрение КЕЙС-технологий позволяет существенно сократить время разработки АС БУ, автоматизировать все этапы разработки АС БУ: генерировать простые приложения, описания логической схемы на языке конкретной базы данных и т.д. Анализ публикаций по изучаемой проблематике показывает, что для эффективной реализации разрешающих способностей КЕЙС-технологий необходима разработка методики их применения для конкретной предметной области. Специфика деятельности коммерческих банков требует от АС БУ высокой скорости внесения изменений, обработки большого количества операций, учета иерархической организационной структуры банков и наличия значи тельной филиальной сети. В свою очередь настройка АС БУ к особенностям конкретного банка вызывает рост затрат. Таким образом, проблема разработки научно обоснованной методики использования КЭЙС-технологий в процессе проектирования АС БУ коммерческих банков, акцентированной на особенностях бухгалтерского учёта коммерческих банков, и охватывающей все основные этапы создания АС БУ и взаимосвязи между ними, является актуальной задачей.
Получившая широкое распространение спиральная модель проектирования автоматизированных систем по многим параметрам не соответствует возросшим требованиям, предъявляемым к разработке систем АС БУ коммерческого банка, в методологической поддержке подобных моделей, как правило, не конкретизирован состав и последовательность работ на каждом этапе проектирования, не учитывается необходимость декомпозиции АС БУ на подсистемы с последующим сопряжением. В связи с этим очевидна потребность в адаптации данной модели к современным условиям на основе использования КЕЙС-технологий.
Методический аппарат применения КЕЙС-технологий к разработке АС БУ должен включать уточненную спиральную модель, эффективный порядок использования КЕЙС-средств и нотаций при проектировании концептуальной и логической схем АС БУ, обоснование применения диаграмм потоков данных. При этом особое внимание уделяется проектированию прежде всего концептуальной схемы АС БУ, так как именно в ней определяется иерархия бизнес-функций, где верхние уровни функций показывают основные цели автоматизированных процессов, а нижние уровни в результате подробной декомпозиции функций фактически описывают потребный набор экранных форм и процедур обработки данных. Перечень получившихся функций на нижнем уровне быстро обрисовывает плотный проект системы, давая возможность более формально подойти к стадии генерации форм и написанию процедур. Дальнейшая работа над функциями нижнего уровня иерархии вполне вписывается в уточнен ную спиральную модель системы проектирования, так как работает в режиме усложнения первого плотного варианта АС БУ. Внедрение методологического аппарата должно быть направлено на существенное сокращение времени разработки всех подсистем АС БУ, и в первую очередь, подсистем, подверженных наибольшим изменениям, например, таких как: учет кредитов, ценных бумаг и т.д.
Необходимость создания методологического инструментария применения КЕЙС-технологий при построении АС БУ определила выбор темы, цели и задачи диссертации.
Цель и задачи диссертационной работы. Основная цель исследования состоит в разработке методологического аппарата применения КЭЙС-технологии при проектировании автоматизированных систем бухгалтерского учёта коммерческого банка. В работе поставлены и решены следующие задачи:
проанализированы особенности использования современных КЭЙС-продуктов при проектировании АС БУ;
изучены особенности бухгалтерского учёта в коммерческом банке как предметной области автоматизации;
рассмотрены современные автоматизированные информационные технологии бухгалтерского учёта;
модифицирована спиральная модель проектирования, учитывающая особенности функционирования АС БУ;
разработаны методики построения диаграмм потоков данных, концептуальной и логической схемы базы данных, спецификаций задач и прикладных программ, а также архитектуры применительно к системам бухгалтерского учёта для коммерческих банков;
на основе КЭЙС-технологий разработаны инструментальные средства проектирования и рекомендации по использованию типовых проектных решений при реализации крупных подсистем банковского бух галтерского учета: "Многовалютный операционный день", "Прогноз кре-дитно-депозитных ресурсов" и "Учёт ценных бумаг".
Объект и предмет исследования. Предмет исследования - КЕЙС-технологии как механизм адаптации АС БУ к изменяющейся среде. Объект исследования - автоматизированные системы бухгалтерского учета коммерческого банка.
Теоретическая база исследования. Исследование проведено с использование принципов и моделей проектирования автоматизированных систем на базе КЕЙС-технологий, сформулированных в работах Баркера Р., Йордана Е., Гейне Ц., Сарсона Т., Марка Д., Макговена К, Фишера А,, Гибсона М. Л., Марча Ц., Боема Б,, Демарко Т. и др.
В ходе исследования проанализированыи использованы разработки, выполненные научными коллективами Финансовой академии при Правительстве РФ, МГТУ нм. Баумана, Московского государственного университета экономики, статистики и информатики, Всероссийского заочного финансового экономического института, Центрального Банка РФ и других организаций.
Практические вопросы автоматизации бухгалтерского учета коммерческих банков и применения КЕЙС-средств наиболее полно отражены в работах российских исследователей Е.З. Зиндера, A.M. Вендерова, Г.Н. Калянова, Г.А, Титоренко, СВ. Горина, С.Д. Кузнецова и др.
Методология исследования. Исследование основано на конкретных приложениях методологии научного познания в прикладных направлениях информатики и бухгалтерского учета. В качестве конкретных методов исследования в работе использовались системный анализ, положения теории нормализации отношений, проектирования баз данных, методы объектно-ориентированного проектирования, методы анализа временных характеристик распределенных систем обработки данных.
Научная новизна. В исследовании разработан методологический аппарат применения КЕЙС-технологий при проектировании АС БУ. Элементы новизны содержат следующие результаты исследования:
1. Модифицирована спиральная модель проектирования, детализирующая стадии разработки автоматизированных банковских систем и включающая дополнительный этап, связанный с разработкой архитектуры АС БУ.
2. Разработаны методики проектирования на основе КЭЙС- технологий компонентов концептуальной и логической схемы базы данных, спецификаций задач и прикладных программ, а также архитектуры применительно к системам бухгалтерского учёта для коммерческих банков.
3. На основе проведенного сопоставительного анализа диаграмм, используемых при построении моделей потоков данных, доказаны преимущества применение DFD-диаграмм в процессе проектирования систем бухгалтерского учёта.
4. На основании анализа нотаций Баркера и IDEF1X, применяемых в процессе проектирования концептуальной схемы базы данных, доказано соответствие между этими двумя способами, позволяющее при проектировании банковских систем конвертировать описание концептуальной схемы из одной нотации в другую.
5. Предложено использование RAD-технологий для разработки сложных прикладных программ систем бухгалтерского учёта в дополнение к средствам разработки программных приложений, предлагаемых КЕЙС-технологиями.
Практическая значимость. Рекомендации, методики и выводы диссертационной работы ориентированы на широкое применение организациями, занимающимися разработками АС БУ, отделами автоматизации коммерческих банков, сопровождающими работу АС БУ или разрабатывающими собственные АС БУ.
Самостоятельное практическое значение имеют:
модифицированная спиральная модель проектирования АИТ; разработанные типовые проектные решения на основе КЭЙС-технологий методики проектирования диаграмм потоков данных, концептуальной и логической схемы базы данных, спецификаций задач и прикладных программ;
рекомендации по разработке подсистем бухгалтерского учета: "Многовалютный операционный день", "Прогноз кредитно-депозитных ресурсов", "Учёт ценных бумаг".
Внедрение и апробация результатов исследований.
Отдельные положения разработанной методики использованы холдингом «ФОРС» при проектировании автоматизированных систем бухгалтерского учёта коммерческих банков. Полученные теоретические, методологические и практические результаты обсуждались на научно-практической конференции «Проблемы потребительской кооперации Сибири и дальнего Востока. Ее кадровое обеспечение» (Новосибирск, 1996 г.), на 4-ом конгрессе Международного форума информатизации «Информатика и бизнес» (г. Москва, 1998 г.), на межвузовском научно-практическом семинаре «Тенденции становления и развития информационного бизнеса в России» (г. Тамбов, 1998 г).
Публикации. По результатам выполненных исследований опубликованы 5 печатных работ, общим объемом работ 4,6 п.л.
Объём работы. Диссертационная работа содержит 189 страниц, в том числе 179 страниц машинописного текста, 46 рисунков и таблиц. Список литературы включает 107 наименований.
рынка технологий разработки автоматизированных банковских систем
Рассмотрим решения, предлагаемые отечественными фирмами в области разработки программного обеспечения и построения архитектуры автоматизированных систем бухгалтерского учёта.
К наиболее значимым по числу внедрений фирмам-разработчикам АС БУ следует отнести Diasoft, ПрограмБанк, Rstyle, Инверсия, Форс и др.
Фирма Diasoft (www.diasoft.ru) имеет внедрения в нескольких сотнях банках. Наиболее интересным представляется продукт НОВАЯ АФИНА, разработанный совместно с ПрограмБанк. Информационная система управления банковской деятельностью НОВАЯ АФИНА построена на базе единого бухгалтерского ядра и предназначена для организации бухгалтерского учета и эффективного управления банком. Система установлена в крупнейших российских (Внешторгбанк, Гарантия, Желдорбанк, Мдм, Оргбанк) и западных (Cho Hung Bank, United West Bank) банках. Система позволяет перевести значительную часть бумажного документооборота банка в электронную форму, повышая эффективность работы сотрудников, упрощая хранение, поиск и пересылку документов. В комплект поставки включены планы счетов и нормативные инструкции, а также альбом отчетных форм по обязательной отчетности перед ЦБ. Для типовых банковских операций в системе настроены соответствующие им схемы проводок, контрольных и учетных действий, причем для каждого из подразделений банка набор банковских операций может быть индивидуальным. Система принимает и представляет требуемые данные в различных форматах (РКЦ, S.W.I.F.T., Reuters и др.) и позволяет быстро настраиваться на новые стандарты обмена. Система поддерживает работу многофилиального банка в режимах on-line и off-line. Предусмотрен режим работы с удаленными филиалами по различным протоколам обмена информацией, а также в условиях нестабильной связи.
Следует отметить, что НОВАЯ АФИНА предоставляет средства для доработки этого продукта с целью учёта особенностей работы банка. Трехуровневая архитектура системы обеспечивает наращивание заказчиком не только дополнительной описательной информации, но и создание новых банковских операций на основе существующих в системе функций. Кроме средств настройки модели бизнес-процессов, визуального генератора отчетов и инструментов многослойного администрирования система предоставляет системным аналитикам и технологам банка дополнительный набор средств расширения функциональности системы, в состав которых могут входить сервер обмена сооб щениями, генераторы SQL-запросов и экранных форм, проблемно-ориентированный язык программирования.
Кроме того, Diasoft поставляет другие продукты для автоматизации бухгалтерской деятельности.
В системе DiasoftBALANCE управленческий и финансовый учет рассматривается как единое целое. Благодаря этому обеспечивается возможность успешного управления организацией в период резкой смены внешних условий. Система DiasoftBALANCE позволяет 1) формировать и модифицировать любые виды документов, 2) совершать операции на уровнях производственного и бухгалтерского учета относительно объектов учета, 3) вести и группировать любое количество планов счетов бухгалтерского учета произвольной структуры и любого уровня вложенности, 4) вести многовалютные счета, 5) учитывать и обрабатывать платежи по выбранному счету, 6) осуществлять контроль и анализ формируемых системой показателей в плановых и фактических плоскостях, 7) взаимосвязано учитывать все показатели деятельности, 8) наращивать функциональность системы. Сегодня DiasoftBALANCE используют более чем в 100 организациях, в том числе Газпромбанк, Мфк, Онэксимбанк, Нрб, Deutsche Bank, Rabobank International, Автовазбанк, Ингосстрах, Рк-Гарант.
Система DiasoftBANK 4x4 обеспечивает комплексную автоматизацию всех направлений деятельности банка, полное соответствие текущему банковскому законодательству, единовременное ведение разных планов счетов произвольной структуры, возможность работы на любом национальном языке, работу многофилиальной банковской структуры. Этот продукт решает задачи учета доходов и расходов по кассовому методу и методом начисления, организации валютного учета по принципам multi- и double-currency, работы подразделений банка в едином информационном пространстве в режиме реального времени, быстрого получения отчетов произвольной формы. Этот продукт позволяет использовать различные СУБД: Btrieve, Pervasive SQL, DB2 for AS/400, Informix, язык расширения приложений DiasoftSCRIPT для функционального развития системы, внешние Windows-приложения (Word, Excel, Access). Программные продукты марки DiasoftBANK 4x4 установлены в более, чем в 600 коммерческих банках с филиалами. К их числу относятся крупнейшие россий
ские (Сбербанк России, Внешторгбанк, Газпромбанк, Гута-банк, Национальный Резерв-ный банк) и западные (Deutsche Bank, Ing Barings) банки.
Для системы Diasoftbank 4x4 характерна возможность развития системы пользователем. В систему включены мощные средства, позволяющие банку самостоятельно дополнять или модифицировать функциональность. Развитие системы может вестись в следующих аспектах: 1) расширение множества используемых данных, 2) функциональное расширение системы (достигается посредством использования встроенного в программный комплекс языка расширения приложений DiasoftSCRIPT), 3) технологическое расширение системы (для каждой услуги можно описать действия, которые нужно выполнить), 4) расширение состава отчетных форм, 5) настройка пользовательского интерфейса.
Система электронных расчетов DiasoftCLIENT предназначена для автоматизации документооборота между банком и его клиентами. Она обеспечивает широкий набор функций для работы по системе электронных расчетов, включая передачу платежных документов в банк, получение информации о состоянии счетов, ведение архива документов и остатков на счетах клиента.
DiasoftCREDIT 5NT - это система автоматизации кредитной деятельности. Она обеспечивает комплексную автоматизацию кредитной деятельности банков, полное соответствие нормативным инструкциям ЦБ РФ, ведение различных видов кредитования как юридических, так и физических лиц, взаимодействие кредитных подразделений многофилиальной банковской структуры. Система автоматизации кредитной деятельности DiasoftCREDIT 5NT реализована с использованием архитектуры "клиент-сервер". Возможно применение двух СУБД: Microsoft SQL Server и Sybase SQL Server.
Обоснование выбора спиральной модели проектирования автоматизированных систем бухгалтерского учёта на основе КЕЙС-технологий
К началу 80-х годов сложилась схема проектирования АС БУ и других автоматизированных систем (рис. 1.4), которую сейчас называют каскадной [21, 36]. Каскадная схема предполагает переход к следующему этапу проектирования после полного окончания работ по предыдущему этапу.
Согласно этой схеме процесс разработки автоматизированной системы включает следующие этапы: 1. Анализ и планирование. 2. Проектирование. 3. Реализация и тестирование. 4. Внедрение. 5. Сопровождение.
На первом этапе будущие пользователи системы под руководством специалистов-разработчиков определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности.
На втором этапе разрабатываются информационная и функциональная модели автоматизированной системы и её подсистем, определяются интерфейсы между автономно разрабатываемыми подсистемами.
На третьем этапе выполняется разработка и тестирование прикладных программ (приложений).
На фазе внедрения (четвёртый этап) производится обучение пользователей и реализуются некоторые организационные изменения.
На пятом этапе выявляются и устраняются ошибки, допущенные при проектировании, и выполняется доработка системы (её развитие).
Характерной особенностью каскадной схемы проектирования является то, что конечный пользователь начинает использовать информационную систему только на этапах её внедрения и сопровождения.
Следует отметить, что проектирование автоматизированных систем (в частности и АС БУ) по рассмотренной схеме довольно часто приводило к неутешительным результатам: сразу после внедрения они признавались морально устаревшими. В начале 80-х годов Дж. Мартином были проведены исследования на предмет выявления причин кризисной ситуации, которая сложилась к этому моменту в области проектирования автоматизированных систем [30]. Им было проанализировано большое число разработок и построены диаграммы распределения ошибок (выявленных на этапе сопровождения) по этапам проектирования систем и затрат на их устранение (рис. 1.5).
Больше всего ошибок (56%) допускается при выявлении информационных потребностей пользователей и проектировании, т. е. ещё до реализации проекта. На их устранение требуется 82 % затрат от общего объёма издержек на устранение ошибок проектирования. Эта тенденция носила довольно устойчивый характер.
На основании этих результатов Дж. Мартин сформулировал принцип неопределённости в информатике: процесс автоматизации задач, которые пользователь хочет решать с помощью системы обработки данных, изменяет его представление об этих задачах. Другими словами, процесс внедрения автоматизированной системы корректирует требования к этой системе.
Этот принцип указывает на обратное влияние информационных технологий (Information Technology - IT) на реконструкцию бизнес-процессов (Business Process Reengineering - BPR). Т. е. с помощью средств вычислительной техники пользователь решает свои задачи иначе, чем без их использования. В 1995 г. Меллинг В.П. сформулировал выводы о взаимосвязи IT и BPR, которые, по существу, являются обобщением принципа неопределённости Мартина [36, 49]:
1. Существует двунаправленное воздействие бизнес- и ИТ-платформы предприятия (рис. 1.6).
2. Если бизнес- или ИТ-платформа меняется, то маловероятно, что соответствующая наследуемая ИТ-архитектура предприятия сохранится.
3. Соответствие между бизнес- и ИТ-архитектурой является решающим фактором успеха, но на достижение этого успеха может уйти значительное время.
Разработка методики проектирования систем бухгалтерского учёта на основе КЕЙС-технологий
В разделе 2.1 были определены этапы разработки подсистем автоматизированной системы бухгалтерского учёта (АС БУ) и проанализированы работы, выполняемые на этих этапах. Ниже разрабатывается методика реализации 1-4 этапов проектирования подсистем АС БУ на основе КЕЙС-технологий. Она может быть использована коммерческими банками при доработке пилотного проекта АС БУ или при разработке собственной автоматизированной системы, а также фирмами-разработчиками АС БУ. Наиболее часто и эффективно применяются КЕЙС-средства для описания диаграмм потоков данных совместно со словарями данных и спецификациями процессов (Data Flow Diagrams - DFD), диаграмм "сущность-связь" (Entity-Relationship Diagrams - ERD).
Компоненты логической модели какой-либо подсистемы АС БУ представлены на рис. 2.3. DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также определяет хранилища (накопители) данных, к которым осуществляется доступ. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация перестаёт быть полезной, переходят к выражению логики функции при помощи спецификации процесса (задачи). Содержимое каждого хранилища хранится в словаре данных. Модель данных хранилища затем раскрывается с помощью сущностей ERD. Структуры потоков данных и описания их компонентов также хранятся и анализируются в словаре данных. Наименования потоков данных затем используются для описания атрибутов сущностей ERD.
В отличие от традиционной схемы применения КЕЙС-средств (DFD и ERD) в работе предлагается использовать средство для анализа архитектуры АС БУ. Зто особенно важно для банков, имеющих многофилиальную структуру.
В диссертации разрабатывается методика, которая может быть использована при проектировании подсистем АС БУ. Она включает методические материалы, необходимые для разработки диаграммы потоков данных подсистемы бухгалтерского учёта, разработки концептуальной схемы базы данных банковских информационных подсистем, описания спецификаций приложений, разработки логической схемы базы данных, разработки прикладных программ, выбора архитектуры информационной системы коммерческого банка.
Диаграмма потоков данных (DFD) является основным средством моделирования функциональных требований проектируемой подсистемы АС БУ. С её помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель этих средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. с помощью диаграммы на основе модели SADT (Structured Analysis and Design Technique), с использованием диаграммы на основе собственно модели DFD (Data Flow Diagrams). Эти диаграммы используются в таких КЕЙС-средствах, как Disgner/2000 (Oracle), BPwin (Logic Works) и др.
На рис. 2.4 представлен пример SADT-диаграммы обработки платёжных документов. Место соединения дуги (на рисунке - это стрелка) с блоком (на рисунке - это прямоугольник) определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек), который осуществляет операцию, представляется дугой, входящей в блок снизу. Каждый родительский блок может быть детализирован с помощью двух или более дочерних блоков.
SADT-диаграммы могут использоваться для моделирования документооборота в банке, но из них трудно понять (см. рис. 2.4), какие функции выполняет сотрудник банка, а какие система бухгалтерского учёта.
Анализ показывает, что для моделирования процессов, выполняемых собственно в АС БУ, более всего подходит модель DFD. Для изображения DFD традиционно используются две различные нотации (нотация - это язык описания): Йордана (Yourdon) [107] и Гейна-Сарсона (Gane-Sarson) [88]. Основные символы DFD изображены в табл. 2.2.
Потоки данных являются механизмами, которые используются для моделирования передачи информации из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в её источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным. Далее при проектировании базы данных АС БУ имена потоков данных трансформируются в идентификаторы атрибутов сущностей.
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определённых участках определить данные, которые будут сохраняться в базе данных между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую, оно содержит, может использоваться в любое время после её определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое. В случае, когда поток данных входит или выходит из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Часто хранилища являются прототипами сущностей концептуальной схемы базы данных АС БУ.
Внешняя сущность (терминатор) представляет сущность (это не сущность схемы базы данных) вне контекста системы бухгалтерского учёта, являющуюся источником или приёмником системных данных (например, "Клиент банка"). Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
На рис. 2.5 - 2.8 представлены примеры описания диаграмм потоков данных фрагмента подсистемы "Многовалютный операционный день" АС БУ с помощью КЕЙС-средства BPwin.
Здесь каждая диаграмма следующего уровня является детализацией какого-либо процесса на диаграмме более высокого уровня. Так диаграмма на рис. 2.6 детализирует процесс "Многовалютный операционный день" (рис. 2.5), диаграмма на рис. 2.7 описывает процесс "Ввод", обозначенный на рис. 2.6, и т. д. То есть можно говорить об иерархии диаграмм потоков данных. Входные и выходные потоки данных какого-либо процесса изображаются на соответствующей дочерней диаграмме в виде дуг, один конец которых остаётся непри-соединенным. Например, входной поток данных "Ввод данных" на рис. 2.5 представлен на рис. 2.6 стрелкой со свободным концом.
Подсистема "Прогноз кредитно-депозитных ресурсов"
Подсистема "Прогноз кредитно-депозитных ресурсов" (ПКДР) предназначена для автоматизации оперативной работы с кредитными и депозитными договорами. Она поддерживает выполнение следующих функций: ведение картотек договоров, назначение плановых событий договоров (течений), мониторинг договоров, т. е. фиксирование плановых событий и ввод новых. ПКДР обеспечивает ведение и просмотр следующих основных справочников и классификаторов: план счетов (только просмотр), коды счетов (только просмотр), справочники общих сведений (продолжительность договора, целевое назначение, вид обеспечения, гарант и т. д.), выделенные счета, сведения о клиентах, таблицы процентов, короткие деньги, коды территорий СОАТО, справочники разбиений и др. Данная подсистема формирует все основные отчёты, связанные с выполнением кредитных и депозитных операций в банке: движение средств, остатки средств на договорах, задолженности, расшифровки, отчёты по 17 инструкции, приход/расход средств банка, финансовая отчётность, отчёты по кредитному портфелю и др.
С помощью КЕЙС-средства BPwin были разработаны диаграммы потоков данных (ДПД), которые обеспечивают моделирование функциональных требований к подсистеме ПКДР. Описания этих диаграмм приведены в приложении 2. С целью экономии места здесь так же, как и при описании подсистемы МОД (раздел 3.1), каждый процесс диаграммы потоков данных представлен четырьмя элементами: идентификатор процесса, назначенный пакетом BPwin, наименование процесса, функция, данные.
На основе представленных в приложении 2 диаграмм потоков данных была разработана концептуальная и логическая схемы базы данных подсистемы ПКДР. Для этой цели данные из BPwin были экспортированы в пакет ERwin. На рис. 3.6 - 3.7 представлены подсхемы базы данных подсистемы ПКДР на уровне сущностей. Для связывания сущностей были использованы связи типа "может" (неидентифицирующие связи). Ключ каждой сущности назначается программным путём и не совпадает ни с одним из отображаемых атрибутов. При описании связей при необходимости определялись правила ссылочной целостности (см. подраздел 3.1).
Ниже приведено краткое описание особенностей подсхем базы данных подсистемы ПКДР.
На рис. 3.6 представлена подсхема "Справочники". Состав таблиц этой подсхемы определяется набором вложенных процессов диаграммы потоков данных КД1.1 (справочники), а список атрибутов - элементами "данные" этих процессов. При описании сведений о клиенте используются данные из справочников "Коды счетов", "Коды территорий СОАТО", "Справочник общих сведений" (характер отношений).
На рис. 3.7 изображена подсхема "Кредит". В таблице "События" хранятся последовательности событий всех течений (см. КД2.1.1.3.1, элемент "данные"). С первой записью события течения связана одна или несколько (для сложных процентов) записей таблицы "Процентная ставка", где описываются правила начисления процентов по этому течению (см. КД2.1.1.3.2, элемент "данные"). ПКДР имеет головное меню, которое состоит из следующих пунктов "Сервис" (КД1), "Договоры" (КД2), "Депозит" (КДЗ), "Отчёты" (КД4).
Функция (пункт) "Справочники" (КД1.1) меню "Сервис" обеспечивает 1) просмотр плана счетов, 2) просмотр данных о конкретном счёте, 3) ведение справочника общих сведений о договоре: длительность договора, целевое назначение, отраслевой признак договора, дополнительные признаки договора, вид обеспечения (страховой полис, гарантия, поручительство, залог товаров и др.), гарант, классификатор степени риска, страховая компания, характер отношений с клиентом. С помощью этой функции можно определить выделенные счета, используемые при описании и ведении договоров: счета доходов, счета расходов, счёт убытков, счёт кассы, счёт прибылей, корреспондентский счёт. Здесь можно также описать 1) балансовые счета по договорам (счёт и его логическое наименование), 2) сведения о клиентах, 3) различные таблицы процентов, 4) другие справочники: род операций в платежах (00 - начисление процентов, 08 - выдача или зачисление ссуды и др.), короткие деньги, коды территорий СОАТО, образцы договоров, справочники разбиений в соответствии с инструкцией ЦБ № 17 (по экономическим секторам, по срокам, по группам риска, по суммам, по процентным ставкам).
Функция "Настройка программы" (КД1.2) позволяет определить 1) различные ключи, 2) реквизиты банка, 3) шаблоны бланков для назначения платежа (выдачи кредита, оплаты процентов за кредит, возврата кредита), 4) понятие краткосрочности.
С помощью функции "Работа с валютами" (КД1.3) можно установить 1) валюту для получения отчёта (текущая, национальная), 2) признак получения сводных отчётов по всем валютам, 3) курс валюты в отчётах (на текущую дату, на дату подписания договора, по курсу на дату события, по номиналу), 4) признак вывода шапки в отчёте с названием валюты. Данная функция также позволяет отобразить информацию о кодах, названиях и курсах валют.
Меню "Договоры" (КД2) обеспечивает описание плановых событий договора и ведение его исполнения. Функция "Кредит" (КД2.1) позволяет описать договоры на предоставление кредитов организациям, другим банкам, ИТД, филиалам, гражданам, а также долгосрочные кредиты. Различные виды кредитов обрабатываются примерно одинаково. Поэтому рассмотрим работу функции "Кредит" на примере ведения договора на предоставление кредита организации. Описание договора осуществляется в следующей последовательности: 1) из справочника выбирается клиент, которому предоставляется кредит, 2) определяются общие сведения о договоре, 3) описываются плановые события договора (течения), 4) рассчитываются плановые проценты по договору, 5) затем вводятся события, связанные с исполнением договора.
Общие сведения о договоре включают следующие данные: дату подписания, тип договора, код ссудного счёта, код счёта текущих процентов, признак учёта досрочки, признак учёта резервирования средств, т.е. требуется ли начислять проценты за наличие резерва, признак пролонгации средств, длительность пролонгации, число дней льготного периода для оплаты процентов и погашения ссуды, тип штрафа за просрочку оплаты процентов (из справочника): пеня (не включать в задолженность), пеня (включать в задолженность), занесение процентов на основной счёт ссудной задолженности, занесение процентов на счёт просрочки; код счёта пени (не обязательно), схему начисления процентов (360/360, 360/365, 365/365), признак переноса выходного дня (без переноса, на пятницу, на понедельник) и др.
