Размещено на http://www.allbest.ru/

22

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АРХИТЕКТУРНО-СТРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ»

Кафедра прикладной математики и вычислительной техники

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

на тему: Подсистема мониторинга информационной системы кредитной организации

Студента

Сахабова А.В.

Руководитель работы

Поляков С.Н.



РЕФЕРАТ

Выпускная квалификационная работа.

Пояснительная записка: 109 страницы, 51 рисунок, 9 таблиц, 23 источника, 3 приложения.

ИНФОРМАЦИОННАЯ СИСТЕМА, ПЛАТЕЖНЫЙ ДОКУМЕНТ, БЕЗНАЛИЧНЫЕ ПЛАТЕЖИ, КРЕДИТНЫЕ ОРГАНИЗАЦИИ, МОНИТОРИНГ.

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

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

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

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

СПИСОК СОКРАЩЕНИЙ И УСЛОВНЫХ ОБОЗНАЧЕНИЙ

В данной работе используются следующие условные обозначения:

БД - база данных

Гб - гигабайт

Гц - герц

ИС - информационная система

Мбайт - мегабайт

ОС - операционная система

ПМиВТ - [кафедра] прикладной математики и вычислительной техники

СГАСУ - Самарский государственный архитектурно-строительный университет

СУБД - система управления базами данных

ФИСТ - факультет информационных систем и технологий

УД - удаленный банкинг

БРКО - безналичных расчетов в кредитной организации

Uml - Unified Modeling Language -- унифицированный язык моделирования



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ предметной области безналичных расчетов в кредитной организации

1.2 Основные принципы построения системы безналичных расчётов кредитной организации

1.3 Теоретические аспекты процедур безналичных расчетов

1.4 Обзор аналогов и прототипа

1.5 Основные цели создания ИС

1.6 Модель анализа UML

1.7 Логическая структура базы данных

2. РЕАЛИЗАЦИЯ ПРОЕКТА

2.1 Выбор и обоснование архитектуры системы

2.2 Физическая структура БД

2.3 Расчет КТС

2.4 Основные интерфейсы

2.5 Диаграмма компонентов

2.6 Диаграмма развёртывания

2.7 Программа и методика испытаний

2.8 Описание схем алгоритмов

2.9 Контрольный пример

3. ВНЕДРЕНИЕ И АНАЛИЗ ЭФФЕКТИВНОСТИ

3.1 Описание планируемого объекта внедрения

3.2 Описание хода планируемого внедрения

3.3 Описание результатов внедрения

3.4 Бизнес-план

4. ОРГАНИЗАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ И САМОРАЗВИТИЕ

4.1 Сведения о деятельности возглавляемого научного микроколлектива

4.2 Перечень публикаций

4.3 Перечень участия в конференциях

4.4 Перечень выполненных в период обучения курсовых работ и проектов

4.5 Портфолио

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ



ВВЕДЕНИЕ

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

Широкое развитие расчетов позволяет значительно ограничить сферу движения наличных денег и сократить издержки обращения наличных денег, связанные с затратами труда для изготовления, транспортировки, хранения и учета денежных знаков. Внедрение эффективных форм безналичных расчетов способствует ускорению платежей и оборачиваемости денежных средств в расчетах и, в конечном счете, ускорению банковского оборота денег. Безналичные расчеты опосредствуют “обмен веществ”, хозяйственные связи в народном хозяйстве, и от их четкости и непрерывности зависит общая эффективность функционирования экономики в целом. Значение безналичных расчетов состоит, прежде всего, в том, что они способствуют кругообороту фондов хозорганов, завершению хозяйственных сделок [1, стр. 15].

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

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

Также, к этому следует добавить фактически полную бесконтрольность за предоставлением кредитов и их целевым использованием, при наличии весьма многочисленного контрольного аппарата в банковской системе и в других органах государственного контроля. Однако, как показала практика, все виды контроля (предварительный текущий, последующий, внешний и внутренний) участников рыночных отношений за выполнением договорных обязательств, в силу неразвитости финансового менеджмента на предприятиях, должным образом еще не налажены. Не отрегулирован механизм и правового контроля со стороны государства за соблюдением правил игры предприятиями различных форм собственности. Эти причины, в свою очередь, стали одними из главных, в образовании платежного кризиса, что ослабило применение всех видов расчетов [2].

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

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

В работе мною использованы работы отечественных авторов по данной теме, законодательные акты Российской федерации, нормативные документы и методические разработки Центрального Банка Российской Федерации.



1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и анализ предметной области безналичных расчетов в кредитной организации

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

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

Первыми подобными системами в банковской практике появились системы удаленного управления банковским счетом с помощью телефона. Американские банки начали активно предлагать данные системы своим клиентам в 1960-1970-е годы. Платеж по телефону был одним из самых недорогих видов услуг в системе автоматизированных расчетов. Затем банки стали разрабатывать комплекс услуг по предоставлению клиентам банков финансовой информации, а также осуществлению по их инициативе различных банковских операций путем передачи информации по каналам связи. Эта форма услуг предполагала наличие у клиента персонального компьютера, с помощью которого клиент мог передавать банку распоряжение об оплате счетов, вызывать на экран информацию о состоянии своего банковского счета, осуществлять переброску средств на счета контрагентов и давать банку инструкции об автоматическом выполнении будущих платежей. Услуги такого рода получили название «компьютерный-банкинг». Сегодня эти системы можно отнести к системам «Клиент-банк»

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

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

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

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



1.2 Основные принципы построения системы безналичных расчётов кредитной организации

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

Развитие рыночных отношений в экономике потребовало изменения основ системы безналичных расчетов, в том числе принципов их организации.

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

К правовой базе регулирования платежной системы России относятся законы и указы, основными из которых являются законы «О банках и банковской деятельности» [2].

Второй принцип организации расчетов - осуществление расчетов по банковским счетам.

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

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

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

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

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

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

1.3 Теоретические аспекты процедур безналичных расчетов

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

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

В расчетах за товары и услуги платежные поручения используются в следующих случаях:

- за полученные товары и оказанные услуги при условии ссылки в поручении на номер и дату товарно-транспортного документа, подтверждающего получение товаров или услуг плательщиком;

- для платежей в порядке предварительной оплаты и услуг (при условии ссылки в поручении на номер договора, соглашения, контракта, в которых предусмотрена предварительная оплата);

- для погашения кредиторской задолженности;

- при расчетах за товары и услуги по решениям суда и арбитража;

- по арендной плате за помещения; платежи транспортным, коммунальным, бытовым предприятиям за эксплуатационное обслуживание.

В расчетах по нетоварным операциям платежные поручения используются для:

- платежей в бюджет;

- погашения банковских ссуд и процентов по ссудам;

- перечисления средств органам государственного и социального страхования;

- взносов средств в уставные фонды при учреждении ОАО, товариществ и т.п.;

- приобретения акций, облигаций, депозитных сертификатов, банковских векселей;

- уплаты пени, штрафов, неустоек и т.д.

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

1-й экземпляр используется в банке плательщика для списания средств со счета плательщика и остается в документах для банка;

4-й экземпляр возвращается плательщику со штампом банка в качестве расписки о приеме платежного поручения к исполнению;

2-й и 3-й экземпляры платежного поручения отсылаются в банк получателя платежа; при этом 2-й экземпляр служит основанием для зачисления средств на счет получателя и остается в документах для этого банка, а 3-й экземпляр прилагается к выписке со счета получателя как основание для подтверждения банковской проводки.

Платежное поручение принимается банком к исполнению только при наличии достаточных средств на счете плательщика. Для совершения платежа может использоваться также ссуда банка при наличии у хозоргана права на ее получение [3].

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

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

На каждый плановый платеж банку представляется отдельное платежное поручение, в котором в графе «Вид платежа» покупатель указывает плановый платеж по сроку (число, месяц) в соответствии с вышеназванным Указом.

После проверки банком правильности оформления поручения производится списание средств со счета плательщика. При отсутствии средств на счете покупателя в день наступления срока планового платежа платежное поручение принимается банком в картотеку неоплаченных расчетных документов с оприходованием по вне балансовому счету № 9929 «Расчетные документы, не оплаченные в срок». Оплата его производится по мере поступления средств на счет плательщика после первоочередных платежей в бюджет, Пенсионный фонд, Фонд занятости населения и Фонд обязательного медицинского страхования [4].

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

1.4 Обзор аналогов и прототипа

В настоящее время существует большинство кредитных организаций. Наиболее популярными являются «Сбербанк ОнЛайн» [5] и «Альфа-Банк»[6]

Далее приводится краткое описание и сравнение этих систем.

Обзор Интернет-банкинг «Сбербанк ОнЛайн»

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

У «Сбербанк ОнЛайн» есть возможности открытия онлайн-вкладов, просмотра открытых обезличенных металлических счетов, отправки сообщений получателю перевода, оплаты авиабилетов при заказе на сайте Аэрофлота, оплаты интернет-покупок на OZON.ru, Parter.ru и многое другое.

«Сбербанк ОнЛайн» может использоваться с помощью мобильных приложений для iOS и Android. Также вскоре будут доступными подключение автоплатежей в пользу любых поставщиков услуг, графическая выписка по кредитам и депозитам, удаленная регистрация в системе (возможность регистрации через интернет без необходимости получать логин и пароль в банкомате) и ряд других нововведений.

Рисунок 1 - Интернет-банкинг «Сбербанк ОнЛайн» (Главное окно)

Пользователи «Сбербанк ОнЛайн» также по-прежнему смогут совершать операции между своими счетами, погашать кредиты, осуществлять переводы на счета и карты других клиентов Сбербанка, осуществлять переводы на счета в других банках, оплачивать услуги сотовой связи, ЖКХ, налоги и штрафы, любые другие платежи по произвольным реквизитам. Также в системе можно проверять баланс бонусного счета «Спасибо от Сбербанка» и совершать другие операции.

Обзор «Альфа-Банк»

Альфа-Банк запустил систему Интернет-банкинга в 2006 году, доверив разработку чешской фирме BSC Praha, с которой продолжает сотрудничать и сегодня (рисунок 2). По массовости с системой «Альфа-Клик», которой регулярно пользуется порядка 2,5 млн. клиентов Альфа-Банка, может соперничать только «Сбербанк ОнЛ@йн» с его приблизительно 3 млн. активных пользователей.



Рисунок 2-интернет банкинг «Альфа-банк»

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

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

Другие системы

Так же был проведен анализ других аналогичных систем:

1. Мобильный банкинг - МТС Банк [7].

2. Банк Открытие [8].

3. Интернет-банк - ВТБ 24 [9].

4. Бин Банк [10].

5. МКБ Банк [11].

Сравнительный анализ систем

В таблице 1 приведен сравнительный анализ уже существующих и перечисленных логистических систем и разрабатываемой - ИМБанк - по критериям. В качестве критериев для сравнения были выбраны:

· Необходимость установки сторонних программ

· Архитектура ИС

· Цена использования

· Количество языков

· Необходимость подключения к интернету

· Возможность многопользовательской работы

· Возможность установки дополнительных модулей

· Импорт/экспорт Excel

· Импорт/экспорт pdf

· Мобильное приложение

· Резервирование данных

· Возможность удаленным управлением

· Визуальные и звуковые оповещения

Таблица 1 - Сравнительный анализ

	Сбербанк Онлайн	Мобильный банк Сбербанк	Мобильный банкинг - МТС Банк	Банк Открытие	Интернет-банк - ВТБ 24	Альфа-Банк	Бин Банк	МКБ Банк	ИМБанк
Цена (руб) в месяц	0	50	30	0	0	-		0	0
Необходимость установки сторонних программ	Браузер	1	0	1	1	1	1	1	1	1
Количество языков (штук)	2	2	2	2	2	2	2	2	1
Вид БД	Собственная БД	1	1	1	1	1	1	1	1	1
Интернет	Online	1	0	0	1	1	1	1	1	1
	Offline	0	1	1	0	0	0	0	0	0
Архитектура ИС	Файл-серверная	1	0	0	1	1	1	-	1	1
	Клиент-серверная	1	0	0	1	1	1	1	1	1
Многопользовательская работа	1	0	-	1	-	1	1	1	1
Импорт	0	-	-	0	0	-	-	-	1
Экспорт	1	1	-	0	-	-	-	-	1
Мобильное приложение	1	0	0	0	0	0	0	1	0
Резервирование данных	1	1	-	1	1	1	-	1	0
Удаленное управление	0	1	1	-	-	-	-	0	0
Оповещение	1	1	1	1	-	1	-	1	0
Отчеты	1	1	0	1	1	-	1	1	1

Экспертным путем всем рассматриваемым системам были выставлены оценки от нуля до единицы (кроме цены и количества поддерживаемых языков).

1.5 Основные цели создания ИС

На рынке достаточно много крупных проектов интернет-банкинга, у конкурентов можно выделить некоторые факторы конкурентоспособности:

· качество разработки;

· дизайн;

· только необходимый и узкий функционал.



Рисунок 3 - Дерево целей для разработки ИС «ИМ»

1.6 Модель анализа UML

Для проектирования АИС воспользуемся языком UML, который представляет собой унифицированный язык визуального моделирования, который разработан для специфицирования (создания спецификации), конструирования, визуализации и документирования компонентов программного обеспечения и бизнес-процессов. Язык UML может быть использован для построения концептуальных и логических моделей сложных систем самого различного целевого назначения [12].

Конструктивное использование языка UML основывается на применении общих принципов объектно-ориентированного проектирования:

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

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

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

Представления о модели сложной системы фиксируются на языке UML в виде специальных графических конструкций - диаграмм

Диаграмма вариантов использования

Диаграмма вариантов использования предназначена для описания функционального назначение системы. Она является исходным концептуальным представлением системы и строится со следующими целями:

· определить общие границы и контекст моделируемой предметной области;

· сформулировать общие требования к функциональному поведению и - интерфейсу системы;

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

В диаграмму вариантов использования входят актанты (actors), варианты использования (usecase) и ассоциации (association) [13].

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

Диаграмма вариантов использования разрабатываемой АИС представлена на Рисунке 4. В качестве актантов диаграммы выступают администратор БД, в обязанности которого входит ведение различных справочников системы. Также в качестве пользователя выступает актант - Клиент, который имеет возможность формировать в системе заявку на осуществление платежного поручения без его непосредственного участия и формировать непосредственно платежное поручение по разработанной форме.

Рисунок 4 - Диаграмма вариантов использования

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

Сценарии вариантов использования

Сценарий - текстовое описание последовательности действий, необходимых для выполнения экземпляра варианта использования. Сценарий пишется по определённому шаблону. При создании сценариев тщательно прорабатывается интерфейс системы, и учитываются отношения между вариантами использования. Для абстрактных вариантов использования, являющихся обобщениями конкретных вариантов, сценарии обычно не пишут [14].

Вариант использования: Ведение справочника пользователей

Краткое описание. Даёт возможность Администратору баз данных создавать и редактировать информацию в справочнике «Пользователь».

Актант. Администратор БД.

Предусловия. Компьютер пользователя включён, выполнен вариант использования «Вход в систему» от лица Администратора базы данных, на экране отображается главное меню системы с пунктами «Редактировать Пользователей», «Вид платежа», «Статьи», «Фирмы», «Банки», «Настройка аккаунта».

Основной поток событий:

1. Администратор БД выбирает пункт меню «Редактировать Пользователей».

А1. Вид платежа;

А2. Статьи;

А3. Фирмы;

А4. Банки;

А5. Настройка аккаунта;

А6. Выход.

2. Система отображает форму «Редактирование Пользователей» с таблицей, имеющей колонки: «Код Пользователя», «ФИО», «Логин», «Пароль», «Тип» и кнопки: «Редактировать», «Удалить», «Добавить». Таблица заполнена записями о пользователях, имеющимися в БД. Код пользователя редактированию не подлежит.

3. Администратор БД нажимает кнопку «Редактировать».

А7. Удалить

А8. Добавить

А6. Выход

4. Система выводит форму «Редактирование Пользователей» с полями для редактирования «ФИО», «Логин», «Пароль», выпадающим списком «Тип пользователя» и кнопкой «Редактировать».

5. Администратор БД редактирует необходимые поля и нажимает кнопку «Редактировать»

6. Система сохраняет изменения в БД и возвращает Администратора БД в главное меню системы. Вариант использования успешно завершается.

Альтернативы

А1: Вид платежа.

А1.1 Администратор БД выбрал пункт меню «Вид платежа». Выполняется вариант использования «Редактирование справочника платежей».

А2: Статьи.

А2.1 Администратор БД выбрал пункт меню «Статьи». Выполняется вариант использования «Редактирование справочника статей оплаты».

А3: Фирмы.

А3.1 Администратор БД выбрал пункт меню «Фирмы». Выполняется вариант использования «Редактирование справочника фирмы».

А4: Банки.

А4.1 Администратор БД выбрал пункт меню «Банки». Выполняется вариант использования «Редактирование справочника банков».

А5: Настройка аккаунта.

А5.1 Администратор БД выбрал пункт меню «Настройка аккаунта». Выполняется вариант использования «Редактирование настроек аккаунта».

А6: Выход.

А6.1. Администратор БД нажимает кнопку «Выход»

А6.2. Система закрывает главное окно и осуществляет выход в ОС. Вариант использования завершается.

А7: Удалить.

А7.1 Администратор БД нажимает кнопку «Удалить».

А7.2 Система удаляет выбранную строчку из БД. Вариант использования завершается.

А8. Добавить

А8.1 Администратор БД нажимает кнопку «Добавить»

А8.2 Система выводит форму «Добавить пользователя» с полями для ввода «ФИО», «Логин», «Пароль», «Тип пользователя» и кнопкой «Добавить».

А8.3 Администратор БД нажимает кнопку «Добавить».

А8.4 Система сохраняет введенные данные в БД и возвращает Администратора БД в главное меню приложения.

Вариант использования: Формирование платежного поручения

Краткое описание. Даёт возможность Клиенту создавать и редактировать платежное поручение в системе.

Актант. Клиент

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

Основной поток событий:

1. Клиент выбирает пункт меню «Создать Платежное поручение».

А1. Платежные поручения;

А2. Настройки аккаунта;

2. Система предлагает выбрать из выпадающего списка кредитное учреждение, которому будет отправлено платежное поручение и кнопкой «Выбрать»

3. Клиент выбирает из списка и наживает кнопку «Выбрать».

А3. Выход.

4. Система выводит таблицу, заполненную данными из БД и полями «Код банка», «Наименование организации», «Получатель», «Банковский счет», «Счет получателя», «Статья движения средств», «Договор» и полями для ввода данных «Сумма платежа», «Назначение платежа», «Оплачено», «Ответственный», «Комментарий» и кнопкой «Создать»

5. Клиент нажимает кнопку «Создать».

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

Диаграмма сущностных классов

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

Диаграмма сущностных классов для реализуемой системы представлена на рисунке 6.!!

Рисунок - Диаграмма сущностных классов

Диаграмма граничных классов

Граничные классы (boundary): объекты этих классов предназначены для организации взаимодействия системы с актантом (внешним пользователем), они реализуют интерфейсы системы с внешней средой и различными пользователями. Основным содержанием класса являются операции.

Диаграмма граничных классов для системы оптимизации затрат представлена на рисунке 7.

Диаграмма классов управления

Классы управления (control): объекты этих классов являются активными, берущими на себя управления и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.

Диаграмма классов управления представлена на рисунке 8.



Рисунок - Диаграмма классов управления

В диаграмму классов управления входят:

· Класс «Менеджер приложений» - отражает основные функции для организации работы приложения;

· Класс «Менеджер СУБД» - отражает функции для обработки запросов к базам данных;

· Класс «Файловый менеджер» - отражает функцию сохранения файлов;

· Класс «Менеджер ОС» - отражает функции, выполняемые над ИС.

Диаграмма состояний

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

Диаграмма состояний представлена на рисунке 9.



1.7 Логическая структура базы данных

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

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

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

Дочерняя сущность, уникальность которой зависит от атрибута
внешнего ключа, называется зависимой сущностью.

Существует ряд правил организации структур данных, называемых
нормальными формами. Нормализация - процесс приведения модели структуры данных к некоторой нормальной форме[15]. Как правило, используется третья нормальная форма. Она обеспечивает эффективное и не избыточное хранение данных. В таблице 2 приведены требования, которым должна удовлетворять структура БД для того, чтобы быть в одной из первых трех нормальных форм. В процессе нормализации анализируется структура БД, и выявляются элементы, противоречащие определенной нормальной форме.

Таблица 2 - Требования нормализации

Нормальная форма	Требования нормализации
1НФ	БД находится в 1НФ тогда и только тогда, когда поля всех таблиц содержат только атомарные значения и в таблицах нет полностью повторяющихся строк.
2НФ	БД находится в 2НФ тогда и только тогда, когда значение любого не ключевого поля зависит от всего первичного ключа. Так же она должна находиться в 1НФ
3НФ	БД находится в 3НФ тогда и только тогда, когда значение любого не ключевого поля зависит только от значения первичного ключа, но не от значения другого не ключевого поля. Так же она должна находиться во 2НФ.



В результате анализа предметной области и, исходя из поставленных задачей, для подсистемы было выделено 7 сущностей:

1) Users (Пользователи) - предназначена для хранения данных о пользователях подсистемы.

Атрибуты: id, login, password.

2) Banki- банки при помощи которых будут совершаться безналичные расчеты.

Атрибуты: id, name, inn, kpp, rsch.

3) firmy - фирмы

Атрибуты: id, name, inn, kpp, nds, rsch.

4) zayavky - заявки которые составляют фирмы Атрибуты: id, menu, banki,user, firmaa, dogovor. Statbi, summa,oplasheno,naznachenie, otvetstvennyy, comments,status, comment_bank.

5) dogovora - Договора входящие в заявки

Атрибуты: id, id_user, id_firma, id_bank, dogovor.

6) Platezhki платежки которые отравляются в банк.

Атрибуты: id, id_user, id_firma, id_bank, id_dogovor, id_statbi, summa, naznacheno, oplacheno, otvetstvenyy, comments

7) Vid_playezha-вид платежа

Атрибуты: id, name.

Логическая модель данных проектируемой подсистемы была разработана в Microsoft Visio (рисунок 10). В ней учтены все, необходимые для функционирования ИС, сущности и их атрибуты, а также проставлены связи между ними.



Рисунок 10 - Логическая структура БД



2. РЕАЛИЗАЦИЯ ПРОЕКТА

2.1 Выбор и обоснование архитектуры системы

Для реализации проекта была выбрана двухуровневая архитектура клиент-сервер. Получила распространение с начала 1990-х годов на фоне роста рынка персональных компьютеров. Технология "клиент-сервер" разделяет информационную систему на два уровня: представления и хранения данных.

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

Второй уровень - сервер с размещенной на нем базой данных.

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

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

Рисунок 11 - Архитектура двухуровнего клиент-сервера



В целях расширяемости и дальнейшего развития было принято реализовать систему с применением модульной архитектуры. Библиотеки, используемые в реализации, являются стандартными и находятся в свободном доступе. Эти библиотеки реализуют стандартные методы и средства. Другая составная часть системы -- пользовательский интерфейс клиента, использующего классы и методы библиотек визуализации. Эти библиотеки называются TelerikRadControls [9].Они делают интерфейс более «гладким» и приятным при долговременной работе. Также выделен отдельный модуль для взаимодействия с базой данных.

Архитектура и платформа реализации

При разработке АИС были использованы следующие средства:

1. Семейство ОС Windows.

Семейство проприетарных операционных систем корпорации Microsoft, ориентированных на применение графического интерфейса при управлении. Изначально Windows была всего лишь графической надстройкой для MS-DOS. По состоянию на август 2014 года под управлением операционных систем семейства Windows работает почти 92% персональных компьютеров. Windows работает на платформах x86, x86-64, IA-64 и ARM. Существовали также версии для DEC Alpha, MIPS, PowerPC и SPARC [16].

2. Данная система разработана в IDE Netbeans, в данной программе отлично реализованы функции для разработки данной системы [17]. Окно программы показано на рисунке 12.

Рисунок 12 - Среда разработки Netbeans



NetBeans IDE- бесплатная интегрированная среда разработки с открытым исходным кодом для разработчиков программного обеспечения. Среда предоставляет все средства, необходимые для создания профессиональных десктоп приложений, корпоративных, мобильных и веб-приложений на платформе Java [18].Рабочая область среды IDE является полностью настраиваемой - существует возможность пользовательской настройки действий, выполняемых с помощью панели, назначения "горячих" клавиш и т.д.

Данная система разработана на языке программирования PHP [19]. Взаимодействие с базой данных осуществляется с помощью встроенных в PHP средств работы с базами данных MySql и встроеннего приложения phpMyAdmin. К преимуществам phpMyAdmin можно отнести свободное распространение, кросс-платформенность (поскольку она устанавливается на веб-сервер, где установлена база данных, то для доступа достаточно иметь браузер), работу с любым количеством баз данных, удобный графический интерфейс для создания и редактирования таблиц, их связей и запросов на выборку, изменение и удаление элементов.

Для того чтобы взаимодействовать с пользователем, нам необходима база данных, мы выбрали MYSQL. Чтобы разрабатывать на ПК данную систему я установил программу Denwer, которая создавала виртуальную машину на которой все необходимые модули были доступны.

Вспомогательным средством разработки была система управления базой данных phpMyAdmin показана на рисунке 13.



Рисунок 13 - PhpMyAdmin

Основная часть системы работает на этих составляющих. Для того, чтобы, мы графически могли показать пользователю наши результаты используется HTML5 и CSS3 [20]. Для создания динамичных компонентов используется JavaScript [21].

Рисунок 14 - Официальный сайт Twitter Bootstrap



Вся архитектура разработана на Фреймворке Twitter Bootstrap 3 [22].Данный компонент очень удобен для разработки, так как он, предлагает множество готовых решений, которые очень легко использовать для создания блоков из которых состоит система. Сайт фреймворка показан на рисунке 14.

2.2 Физическая структура БД

В качестве СУБД для разработки базы данных системы использовался MYSQL. Физическая структура БД соответствует разработанной ранее логической структуре и представлена на рисунке 15.

Рисунок 15 - Физическая структура БД

Разработка таблиц и схемы базы данных

Для создания данной системы управления данными понадобятся следующие таблицы:

· Banki;

· Dogovora;

· Firmy;

· Users;

· Zayavki;

· Statbi;

· Zayavki.

В СУБД MySQL создание таблицы происходит с помощью команды CREATE TABLE.

Создание таблицы Banki (Банки):

CREATE TABLE IF NOT EXISTS `banki` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` text NOT NULL,

`inn` int(10) NOT NULL,

`kpp` int(9) NOT NULL,

`rsch` varchar(20) NOT NULL,

`bik` int(8) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 16 - Таблица Banki

Создание таблицы Dogovora (Договора):

CREATE TABLE IF NOT EXISTS `dogovora` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`id_user` int(11) NOT NULL,

`id_firma` int(11) NOT NULL,

`id_bank` int(11) NOT NULL,

`dogovor` text NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 17 - Таблица Dogovora (Договора)

Создание таблицы Firmy (Фирмы):

CREATE TABLE IF NOT EXISTS `firmy` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` text NOT NULL,

`inn` int(10) NOT NULL,

`kpp` int(9) NOT NULL,

`nds` int(3) NOT NULL,

`rsch` varchar(20) NOT NULL,

`bik` int(3) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 18 - Таблица Firmy (Фирмы)



Создание таблицы Users (Пользователи):

CREATE TABLE IF NOT EXISTS `users` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` text NOT NULL,

`type` int(11) NOT NULL,

`login` varchar(256) NOT NULL,

`password` text NOT NULL,

`id_type` int(11) NOT NULL DEFAULT '0',

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 19 - Таблица Users (Пользователи)

Создание таблицы Zayavki (Заявки):

CREATE TABLE IF NOT EXISTS `zayavki` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`menu` text NOT NULL,

`banki` int(11) NOT NULL,

`user` int(11) NOT NULL,

`firma` int(11) NOT NULL,

`dogovor` int(11) NOT NULL,

`statbi` int(11) NOT NULL,

`summa` text NOT NULL,

`oplacheno` int(11) NOT NULL,

`naznachenie` text NOT NULL,

`otvetstvennyy` text NOT NULL,

`comments` text NOT NULL,

`status` int(11) NOT NULL DEFAULT '0',

`komment_bank` text NOT NULL,

`date` int(11) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 20 - Таблица Zayavki (Заявки)

Создание таблицы Statbi (Статьи):

CREATE TABLE IF NOT EXISTS `statbi` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`id_statbi` int(11) NOT NULL,

`name` text NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;



Рисунок 21 - Таблица Statbi (Статьи)

Создание таблицы Status (Статус):

CREATE TABLE IF NOT EXISTS `status` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` text NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Рисунок 22 - Таблица Status (Статус)

Создание таблицы vid platezha (Вид платежа):

CREATE TABLE IF NOT EXISTS `vid platezha` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` text NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;



Рисунок 23 - Таблица vid platezha (Вид платежа)

Общая структура базы данных.

Рисунок 24 - Таблица общей структуры базы данных

Описание используемых классов и методов

Используемые классы и методы представлены в таблице 3.

Таблица 3 - Классы и методы

Модуль	Класс	Описание	Методы класса
platezka	platezkaAccountActions	Страница управления аккаунтами пользователей системы	actionDefault() actionAdd() actionEdit() actionDelete()
	platezkaAreaActions	Страница обработки платежного документа	actionDefault() actionAdd() actionEdit() actionDelete()
	platezkaReportActions	Страница вывода платежного документа	actionDefault() actionVisit()
	platezkaSeasonActions	Страница управления банками	actionDefault() actionAdd() actionEdit() actionDelete()
	platezkaVisitActions	Страница системы - просмотра о статусе информации платежного документа	actionDefault() actionAdd() actionClose()
system	noxModel	Базовый класс для работы с базой данных. Обеспечивает взаимодействие с БД, интуитивно понятный построитель sql-запросов и выборку данных	select() updateByField() deleteByField() where() limit() order() fetch() castFieldValue() getEmptyFields() count() exec()
	noxApplication	Выполняет всю работу по маршрутизации и запуску действий	run() runAction() runRouting()
	noxSystem	Основной класс всей системы, запускает работу всех нужных модулей (подробный листинг модуля представлен в приложении Б)	run() location() autorization() getUser() haveRight() getStatistic()
	noxDbConnector	Класс соединения с базой данных	getConnection() closeAll()
	noxThemeAction	Класс работы с шаблоном и темой оформления. Отвечает за формирование веб-документа	run() addMeta() addMetaKeywords() addMetaDescription() AddJs() AddCss() setTheme()



2.3 Расчет КТС

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

Расчет необходимого объема внешней памяти

Расчет объема требуемой внешней памяти происходит по формуле 1.

,

- объем внешней памяти, занимаемый ОС, Мбайт;

- объем внешней памяти, занимаемый СУБД, Мбайт;

- объем внешней памяти, занимаемый данными, необходимыми для работы системы, Мбайт;

- объем внешней памяти, занимаемый программными модулями, Мбайт;

- объем внешней памяти, занимаемый дополнительным ПО, Мбайт;