Автор: Пользователь скрыл имя, 21 Ноября 2011 в 17:36, курсовая работа
Когда-то в среде разработчиков бытовало мнение, что достаточно пяти человек для создания банком системы комплексной автоматизации. Каждый банк, отдел автоматизации которой сколько-нибудь амбициозен, занимался разработкой своей АБС. Сегодня, когда фирмы разработчики, выделяют под специализированные проекты громадные коллективы (более 100 разработчиков) и тратит много времени на создание и сопротивление сложных многоцелевых систем, банки начинают избавляться от "дешевой левизны" и в основном перешли на программные варианты АБС.
2. Защита информации.
Соответствие
системы международным
3. Целостность информации.
Система должна соответствовать международным требованиям по сохранности и целостности информации. Этот вопрос также должен решаться на нескольких уровнях:
4. Гибкость и настраиваемость системы.
Деятельность разных банков, несмотря на кажущееся сходство, отличается по многим параметрам. Во-первых, это уровень подготовки сотрудников и диапазон решаемых ими вопросов. Во-вторых, ведение учета финансовой деятельности. В-третьих, распределение объема и характера работ в соответствии с организационной структурой. В результате банки имеют уровень ответственности, круг решаемых задач, требуют различного объема информации и степени компьютеризации работы служащих. Так, в небольших банках с малочисленным персоналом один служащий может решить весь спектр вопросов по какому-то направлению. Рост и развитие банков сопровождаются организацией дополнительных рабочих мест и сужением специализации сотрудников.
Принимая во внимание то, что основой банковской деятельности являются финансовые юридические документы, ИБС должна позволять без перепрограммирования вносить изменения в технологическую схему банковского документооборота. При этом параметризация должна быть интуитивно понятной, логически связанной с функциональной структурой системы и не предъявлять завышенных требований к уровню квалификации персонала. Эксплуатация и сопровождение ИБС должны быть возможны без участия разработчиков.
Развитие ИБС.
При
появлении банка число
Определение того, что наследовать в банковской технологии, предлагая принципиально новые решения, а что привносить - задача не из простых. В свое время в Италии был предложен способ проверки правильности учета движения денежных средств - система двойной котировки сумм, которая оказалась довольно простой и эффективной с точки зрения защиты от ошибок. Попытка придумать что-либо, отличное от нее, повлечет за собой проблемы, связанные с массовым признанием, а значит, и с распространением. Поэтому новые разработки надо начинать с определения того нижнего уровня абстракции в банковском деле, перенос которого на компьютерные технологии может и должен дать положительный эффект.
Важен выбор метода решения, позволяющего развивать и реализовывать задачи реального времени, которые являются перспективными для банков. Множество Банковских задач реального времени, начиная от определения реального кредитного ресурса (с учетом ресурса филиалов Банка) и заканчивая on-line-системами обслуживания, например, кредитной карточки (т.е. переходом на безналичное обслуживание населения, что приведет к резкому- на порядки- увеличению количества банковских операций), невозможны или существенно затруднены без единой концептуальной системы.
Одна
из прогрессивных технологий, применяемая
в Банках, хорошо известна всем- это
"Безбумажная технология". Однако
ее достоинства становятся наглядными
тогда, когда система уже внедрена и эксплуатируется.
Поэтому на первом этапе создания ПО-создания
Ядра ИБС - важны его одновременное внедрение
и проверка.
Описание элементов банковской системы.
Аппаратная платформа.
Исходя из принципа развития, банковская система не должна навязывать выбор аппаратных и системных средств. Этот выбор должен осуществляться с учетом критериев, не связанных с прикладным ПО. Следует учитывать, в частности, достаточную производительность при минимальной цене, наличие технического обслуживания, гарантии, квалификацию и опыт персонала, количество одновременно работающих пользователей, развитие и масштабируемость аппаратных средств, их надежность и т.п.
При выборе платформы следует, прежде всего, определить реальное число пользователей, которые должны быть одновременно подключены к многопользовательской системе. Ориентировочно можно исходить из следующей оценки: на одного пользователя прикладного ПО требуется 1МБ ОЗУ и 1 tps/A общей производительности системы (tps- число транзакций в секунду). Кроме того, необходимо оценить перспективы роста банка и его финансовые возможности.
Количество пользователей, активно работающих на ИБС в реальном банке с производительностью до 2 000 операций в день, не превысит 20-30.
Такая нагрузка вполне по силам системам на базе INTEL 486DX2/66 и Pentium/60,90, обеспечивающим сквозную производительность 15-30 tps/A и 30-60 tps/A соответственно.
При активном подключении филиалов или создании выносных операционных залов, работающих в режиме on-line, число активных пользователей может быть доведено до 100 и более, а число операций достигать 10 000. В таком случае необходимо ориентироваться на системы класса midrange. Это может быть RISC-система (HP, Sun, IBM) или многопроцессорная система на базе Intel 486 и Pentium (Corollary, Acer, Compaq, AST, ALR, Sequent,Unisys и т.д.). Нельзя забывать о таких популярных (на западе) масштабируемых системах, как AS/400 (IBM), VAX (DEC) и т.д. Важным для нашего рынка может оказаться политика активного снижения цен на процессоры INTEL и анонсирование процессоров Pentium/150 с производительностью 250 MIPS и в 1995 году - P6 с производительностью 300 MIPS.
При покупке системы необходимо убедиться в наличии сертификата ОС и СУБД, используемых в банке.
Операционная система.
В
настоящее время выбор
Поэтому в основном используются РС-совместимые компьютеры под управлением DOS или Windows, соединенные локальной сетью NetWare. При внешней простоте и привлекательности такое решение имеет ряд существенных недостатков:
1. DOS, Windows и NetWare не соответствуют требованиям "надежности" защиты информации и разграничения доступа согласно Trusted Computer System Evaluation Criteria ("Оранжевая Книга"). В мировой практике ОС, не прошедшая такой сертификации, не рекомендуется к использованию в финансовых учреждениях.
2. Пропускная
способность локальной сети
3. Многопользовательское ОС (UNIX, VMS и др.) по сравнению с PC LAN значительно проще и эффективнее интегрируются в глобальной сети. Это существенно при необходимости обеспечения режима работы on-line для филиалов и отделений, особенно на низкокачественных и ненадежных линиях передачи.
Специфические требования банковских приложений очень скоро потребует перехода к более мобильным и защищенным ОС. Современные ОС, как правило, переносимые (UNIX, Windows NT) или обеспечивают работу приложений на ряде компьютеров, масштабируемых по производительности (VAX, AS/400).
Важным фактором может оказаться наличие специалистов по установке, конфигурированию ОС в соответствии с решаемыми задачами. Оптимальным выбором является OC UNIX.
UNIX - многопользовательская многозадачная ОС, которая реализована практически на всех платформах и удовлетворяет стандарту открытых систем POSIX для переносимых ОС. Её важная особенность - защищенность системы и данных от несанкционированного доступа. Использование стандартных протоколов позволяет совместно эксплуатировать сеть Ethernet, OC NetWare, UNIX и, таким образом, осуществлять "мягкий" переход из одной ОС в другую.
Связь ОС с 3GL уровнем предопределяет необходимость приобретения среды разработки (редактор, компиляторы С и С++ ) для данной ОС.
3 GL-поддержка.
К 3GL (3 Generation Language) - поддержке относятся практически все привычные инструментальные языки - С, С++, Pascal, Modula и т.д. На этот уровень выносятся средства, необходимые банковской системе, но не реализуемые штатными средствами СУБД. К ним могут относиться системы цифровой защиты данных и т.п. Для максимального использования этого уровня необходимо наличие развитого интерфейса с языками третьего поколения в предполагаемой СУБД.
СУБД.
В описываемой иерархии СУБД занимает особое место:
При выборе необходимо ориентироваться на СУБД, реализующие технологию клиент-сервер и позволяющие создавать приложения, которые работают в распределенных гетерогенных сетях. К таким СУБД, в частности, относятся ORACLE, Informix, PROGRESS, Sybase, Ingres и т.п.
Существует СУБД PROGRESS. Это переносимая СУБД с 4GL-средствами для создания приложений. Она обеспечивает построение систем архитектуры клиент-сервер и включает модули создания приложений, инструментальные средства поддержки, утилиты и среду выполнения (run-time).
Это многосвязанная многопользовательская система с интегрированным словарем данных, уровнем защищенности и поддержкой широкого диапазона коммуникационных протоколов - TCP/IP, NetBIOS, SPX/IPX, SNA, DECNet, TLI, OSI и др.
Целостность данных обеспечивается в PROGRESS как Неожиданное окончание формулы собственной системой по восстановлению данных, так и протоколом двухфазного совершения транзакций, который поддерживается автоматически и не требует дополнительного кодирования.