Вы находитесь на странице: 1из 4

ВСТУПЛЕНИЕ.

Цель работы – проектирование программной системы, позволяющей


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

ЛИСТ 1 - СТРУКТУРНАЯ СХЕМА


В результате исследования я определила основные компоненты
системы, представленные на риске 1 на структурной схеме. ОПИСАНИЕ
ВСЕХ БЛОКОВ, и, непосредственно блок События ОР, разработкой которого
занималась я.

ЛИСТ 2 - ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ


Более подробно каждый блок я раскрыла на диаграмме вариантов
использования. ОПИСАНИЕ КАЖДОГО БЛОКА. Также описать блоки
события ОР как пример. Подробнее про сохранение.

ЛИСТ 3 И 4 - СРАВНИТЕЛЬНАЯ СХЕМА И ДИАГРАММА


ДЕЯТЕЛЬНОСТИ
П ом и м о о б ы ч н ы х п ол е й с и с т е ма и м е е т т а к н а з ы ва е м ы е
классификаторы. Это справочники, загруженные извне. В данной системе
они были усовершенствованы и существенно отличаются от коробочных, что
показано на сравнительной схеме.

Рисунок состоит из 2 частей. В нижней части показан коробочный


вариант. Данные поступают сразу на весь блок классификаторов,
обрабатываются и высвечиваются на экране. Во втором варианте мы можем
обрабатывать каждый классификатор по отдельности, не зависимо от других
классификаторов. Это значительно упрощает работу с ним, оптимизирует, а
также позволяет располагать их на экранной форме как требуется заказчику.
А самое главное, можно накладывать условия на другие поля, задействовав
конкрентный классификатор. Ранее классификаторы не имели практической
значимости. Так как классификаторы являлись больше справочной
информацией об объекте, которой нельзя было оперировать. ПОКАЗАТЬ НА
СКРИНШОТЫ. В коробочном варианте системы классификаторы являлись
одном объектом и записывались в так называемую перечную location. Теперь
каждый классификатор я могу записать в любую временную переменную и
работать с ней отдельно. Чуть позже приведу пример.

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

ЛИСТ 5 ДИАГРАММА ДЕЯТЕЛЬНОСТИ РАСЧЕТОВ


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

Для это я реализовала возможность создания связанного Последствия


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

Для этого расчета я написала Groovy-функцию, представленную на


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

ЛИСТ 6-7 СХЕМА БИЗНЕ-ПРОЦЕССА


В данном классе систем должно быть предусмотрено разграничение
ролей, так как Событие ОР должно быть не только выявлено, но и проверено,
на достоверность. Так как Рисковое событие (оно же событие ОР) связано с
крупными финансовыми операциями (от 100 000)Для этого я разработаю
схемы бизнес-процессов и реализовала их в программе SAS workflow Studio.
В Событии ОР девять этапов жизненного цикла объекта, на каждом из
которых свой ответственный сотрудник.

На данном листе можно увидеть разницу коробочного бизнес-процесса


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

Например, если классификатор «Подразделение-Владелец» указан = Иванов


Иван Иванович, то на третьей стадии только у И И И будет доступ к
редактированию объекта.

На более конкретном примере объясню всю значимость системы управления


рисками: произошло рисковое событие, или Событие ОР, например, ошибки в
финансовых моделях. Сотрудник, выявивший событие, регистрирует его в
системе. Далее, сотрудник риск-менеджер, то есть эксперт по рискам и
рисковым событиям проверяет, что действительно не ложная тревога и
событие имеет место быть и происходит расчет убытков. Далее
зарегистрировано событие отправляется по жизненному циклу.
ЛИСТ-8 ГРАФ СОСТОЯНИЙ ИНТЕРФЕЙСА
Для управления данными и их визуализации необходим интерфейс.
Представленный граф состояний интерфейса состоит из следующих
компонетов……..
ЛИСТ-9 ФОРМЫ ИНТЕРФЕЙСА
Реализация которых представлена на данном листе: …….
На мой взгляд это наиболее важные формы интерфейса.
ЛИСТ-10 ТЕСТИРОВАНИЕ
После разработанная программная система была протестирована.
Я провела структурное тестирование во время проектирования
компонентов и отладки системы, тестирование белым ящиком удобства
эксплуатации, результаты которого также показаны в расчетно-пояснительно
записке.
Основными методами тестирования были анализ граничных значений и
предположение об ошибке.

Также было разработано более 30 тест-кейстов для тестирования


работниками банка, пример которого можно наблюдать на правой половине
листа. Также для всё системы в целом было написано около 200 тест-кейсов.

ЗАКЛЮЧЕНИЕ
Таким образом, я создала программную систему управления
операционными рисками банка, которая полностью соответствует
выдвинутым требованиям. В рамках данный системы реализованы новые
способы использования классификаторов, на их основе произведены новые ,
более полные и точные расчеты потерь и возмещений, а также
усовершенствованные бизнес-процессы. Актуальностью данной разработки
является то, что вышеперечисленные возможности позволяют покрывать
максимальное количество условий центробанка для программной системы
управления операционными рисками. В качестве дальнейшего развития
продолжается разработка уведомлений для различных ролей пользователей,
создание автоматических загрузчиков, а также визуализация отчетов. А
результаты моей работы нашли отражение в статьях. Спасибо за внимание!