Проектирование реализации операций бизнес-процесса «Управление денежными потоками» (Выбор комплекса задач автоматизации)

Содержание:

Введение

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

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

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

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

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

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

Объектом исследования в курсовой работе является банк.

Цель работы - проектирование реализации операций бизнес-процесса «Управление денежными потоками». Поставленной целью определены основные задачи исследования:

- дать оценку бизнес-процессу Управление денежными потоками;

- выявить «слабые» места;

- дать рекомендации по совершенствованию системы управления.

1 глава. Аналитическая часть

Выбор комплекса задач автоматизации

Объектом исследования в курсовой работе является отдел информационных технологий банка.

Развитие информационных технологий Банка строится по принципам:

-формирования единого информационного пространства Банка;

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

-повышения производительности, надежности и оперативности работы;

-информационно - технологической и телекоммуникационной системы Банка;

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

Основными задачами Отдела являются:

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

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

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

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

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

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

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

Характеристика существующих бизнес – процессов

В рамках установленных тем Отдел исполняет последующие функции:

1. Снижение снабжения необходимостей банка в программных и промышленных средствах обрабатывания данных.

2. Подкрепление верного функционирования работающих банковских порядков, наблюдение и аккомпанемент движения их эксплуатации.

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

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

5. Аппарат программного снабжения и воспитание служащих отделений.

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

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

Характеристика документооборота, возникающего при решении задачи

Входящие документы в зависимости от типа документа могут иметь или не иметь статусов. Динамические входящие документы, формируемые каждый раз заново по запросу клиента – например выписки – не имеют статуса. Статические входящие документы, формируемые исключительно по инициативе банка – например письма – статус имеют. Для статических входящих документов существует два статуса – «Новый» и «Просмотренный». Статус «Новый» имеют входящие письма, с которыми клиент еще не ознакомился. Статус «Просмотренный» имеют письма, которые клиент уже просмотрел. В данной системе для документов мной решено использовать полуавтоматическую обработку. Полуавтоматическая обработка — для части документов решение об исполнении принимается автоматически на основе проверок по формализованным правилам. Другая часть документов также проходит проверки, но окончательное решение об исполнении документов принимает операционист. Электронный документ, отправленный клиентом и полученный банком, является основанием для совершения банком финансовых операций.

Конечной целью всех атак на систему является:

• Подмена (навязывание) злоумышленником электронного документа от имени одной из сторон
• Нарушение конфиденциальности документа (ознакомление с документом)

Для обеспечения аутентичности (доказательство авторства) и целостности документа в системе «Управление денежными потоками» используется механизм электронной цифровой подписи (ЭЦП) под электронными документами. Электронные подписи документов служат для выполнения процедур аутентификации (т.е. документ создан и заверен именно теми лицами, которые указаны) и проверки целостности документа (документ поступил в банк в том виде, в котором был отправлен от клиента). Именно электронный документ с ЭЦП является основанием для совершения финансовых операций и доказательной базой при разрешении конфликтной ситуации.

Обоснование проектных решений по информационному обеспечению.

Система должна работать на IBM совместимых персональных компьюте­рах.

Минимальная конфигурация:

- тип процессора – Pentium II, 600 МГц;

- объем оперативного запоминающего устройства - 256 Мб;

- тип монитора - SVGA 800x800;

- клавиатура;

- мышь.

Для установки Microsoft Access необходима следующая минимальная конфигурация персонального компьютера:

- операционная система: Microsoft Windows 98/2000 (SP2)/XP

- процессор: Pentium II 400 МГц;

- объем оперативного запоминающего устройства: 128 Мб;

- 750 Мб свободного места на жестком диске;

- CD-ROM;

- тип монитора: SVGA 800х600;

- клавиатура;

- мышь.

Обоснование проектных решений по программному обеспечению

Система должна работать под управлением операционных систем семейства Windows - 7, 8, NT, XP.

Программный продукт «Управление денежными потоками» разрабатывается в программе Microsoft Access 2013.

2 глава. Проектная часть

2.1. Информационная модель и её описание

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

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

Осмотрим ход осуществления управления информативными ресурсами и технологиями в банке, который презентован в рисунке 2.

С1 – план развития ИТ Банка;

С2 – стандарты, регламенты в области ИТ;

С3 – нормативные документы ЦБ РФ;

С4 – инструкции;

I1 – информация о потребности определенной техники;

I2 – информация о поломке техники;

О1 – заявка на приобретение новой техники и программных средств;

О2 - ремонт техники;

М1 – системный администратор;

М2 – помощник системного администратора.

Управление информационными ресурсами и технологиями

Планирование обеспечения потребностей банка

Установка техники и программного обеспечения

Поддержание бесперебойной работы техники и ПО

Контроль работы и обслуживание

М1

I1

I2

О1

О2

С3

С1

I1

М1

С1

С2

О1

I1

I2

I1

I2

М1

М1

М1

О1

О2

О2

О1

С2

С4

С2

С4

Рисунок 1 - IDEF - диаграмма для отдела информационных технологий

С2

С3

М2

С3

М2

С4

С4

М2

М1

М3

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

Главным шагом управления информативными ресурсами и технологиями считается снижение снабжения необходимостей банка в ресурсах.

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

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

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

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

2.3. Характеристика результатной информации

Диаграммы потоков данных (DFD – Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

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

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

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

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

Рисунок 2 - Контекстная диаграмма системы «Управление денежными потоками

Основным процессом является Электронный банкинг, т.к. вся деятельность системы направлена именно на это. Внешними сущностями являются Операционист и Клиент. Для регистрации в системе клиент вводит соответствующую информацию, после имеет возможность передавать операционисту электронные Документы и отправлять Запросы на отзыв документов, что отражено на диаграмме в виде информационных потоков. Получив документы заемщика, обработанные системой по формализованным правилам, операционист начинает их обработку по не формализованным правилам. Отправляет документы в РКЦ НБ, где решается вопрос об исполнении или неисполнении документа. Так же операционист может отказать в передаче последнего в РКЦ.

После создания контекстной диаграммы, я постаралась рассмотреть

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

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

Рисунок 3 - Диаграмма детализации первого уровня системы «Управление денежными потоками»

2.4. Общие положения (дерево функций и сценарий диалога)

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

Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

Исходя из поиска ответов на следующие вопросы:

Кто взаимодействует с системой или использует систему?

Кто передает или принимает информацию в/из системы?

Кто является внешним по отношению к системе?

Я выявила следующих субъектов.

Рисунок 4 - Субъекты системы

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

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

Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента.

Рисунок 5 - Прецеденты системы

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

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

Достоинства модели вариантов использования заключаются в том, что она:

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

Рисунок 6.

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

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

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

Рисунок 7 - Диаграмма прецедентов для субъекта Клиент банка

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

Следует прокомментировать некоторые особенно «привлекательные» отношения между вариантами использования.

Так, смысл отношения «include» состоит в том, что Создание платежного документа включает в себя Создание платежного поручения и Создание платежного требования. Также, прецедент Подписать документ ЭЦП выполняется только в рамках Создания платежного документа, Создания нового письма или Отзыва документа.

Смысл же связи <<extend>> в том, что прецедент, например, Создание платежного документа «расширяется» вариантом использования Сохранение документа, которой в свою очередь расширяется прецедентом Проверка реквизитов документа. Я объясняю это тем, что сохранить документ можно только проверенный системой на наличие ошибок. Распечатка перечня документов за определенный период «расширяет» прецедент Получение выписки. Таким образом, связь <<extend>> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

2.6. Структурная схема пакета (дерево вызова программных модулей)

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

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

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

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

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

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

Рассмотрим теперь модели видов деятельности, построенные для проектируемой системы.

Рисунок 8 - Диаграмма видов деятельности для прецедента распечатка перечня денежных потоков за определенный период

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

Рисунок 9 - Диаграмма видов деятельности для прецедента Аутентификация пользователя

Для входа в систему «Управление денежными потоками» должна произойти аутентификация клиента. Для этого клиенту необходимо открыть программу. Автоматически появляется форма аутентификации. Далее Клиент системы должен указать путь на файл с Хранилищем ключей ЭЦП клиента. В результате в окне отобразиться список ключей ЭЦП клиента, содержащиеся в Хранилище ключей. Клиент должен выбрать необходимый ключ и ввести пароль для доступа к ключу. Если проверка сведений проходит успешно, то открывается доступ в систему. Иначе выводится сообщение об ошибке и предлагается возможность повторить попытку аутентификации.

Рисунок 10 - Диаграмма видов деятельности для прецедента обработка документа «Управление денежными потоками»

Для того, чтобы произвести обработку документа, необходимо выявить наличие новых поступлений. В случае отсутствия новых документов обработка не происходит. При получении нового документа операционист переводит его в статус «на обработке» из статуса «доставлен». Далее провидится проверка корректности ЭЦП и наличие ошибок. При некорректном ЭЦП и при наличии ошибок, документ также переводится в статус «отвергнут». Формируется сообщение о причине отказа и документ передается клиенту. В противном случае, то есть при положительной обработке документа, он распечатывается и сохраняется.

Рисунок 11 - Диаграмма видов деятельности для прецедента «Отзыв док-та»

2.5. Характеристика базы данных

Для упрощения операций «Управление денежными потоками» будет создана единая база данных. Система должна удовлетворять следующим требованиям к надежности:

- контроль вводимой информации;

- блокировка некоррект­ных действий пользователя при работе с системой;

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

- целостность и конфиденциальность хранимой информации.

2.7. Контрольный пример реализации проекта и его описание

Экранные формы, таблицы и отчеты готовой базы данных «Управление денежными потоками» представлены на рисунках.

Рисунок 12.

Рисунок 13.

Рисунок 14.

Рисунок 15.

Рисунок 16.

Рисунок 17.

Заключение

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

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

Хочу отметить, что разработанный проект далеко не является полным и готовым к реализации. В процессе разработки были рассмотрены и смоделированы основные функции системы. Но помимо рассмотренных, система должна поддерживать еще и другие функции. Так, например, мною не была рассмотрена работа такими с исходящими рублевыми документами как Аккредитив, Инкассовое поручение, Заявление об отказе от акцепта; работа с такими исходящими валютными документами как Заявление на перевод валюты, Поручение на покупку валюты, Поручение на продажу валюты, Поручение на обязательную продажу валюты, Поручение на обратную продажу валюты и многое другое, что, на мой взгляд, имеет место быть в хорошей информационной системе «Управление денежными потоками».

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

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

Проект был выполнен с использованием case-средств BPWin 4.0 и IBM Rational Rose 2003, а так же Microsoft Access 2013. Все требования к содержанию и оформлению проекта были соблюдены.

Список литературы

1. Столбовский Д.Н. Курс лекций по проектированию информационных систем
2. http://ooad.asf.ru (Объектно-ориентированный анализ и проектирование).
3. http://mista.ru/oop_book/index.htm (Объектно-ориентированное проектирование; С.С.Гайсарян)
4. http://www.vrg.ru/articles/uml_book
5. http://alice.stup.ac.ru/case/caseinfo/rrose/part2_2.php#1
6. http://www.citforum.ru/
7. http://www.mmbank.ru
8. http://www.//elib.ispu.ru/library/lessons/isystems/lecture02.html
9. http://www.intuit.ru (Насколько «тонок» клиент. Л.А.Гимейн, С.М.Козменко, А.А.Рындин, И.Б.Фертман)