Материал: Диплом магистратура
Рис. 2.5 – Алгоритм навчання комбінованого методу на основі CART та SVM
Визначення функціональних вимог системи
В рамках атестаційної роботи було вирішено, що система представляє собою веб-орієнтований додаток, спроектований на клієнт-серверній архітектурі. Мається на увазі, що розроблену систему будуть використовувати співробітники банку, та вносити клієнтські дані для аналізу заявок на отримання банківських кредитів.
Для визначення функціональних вимог системи, було обрано стандарт методології IDEF0 (I-CAM DEFinition). Модель IDEF представляє собою ієрархічну модель опису бізнес-процесів. Процеси моделі можна декомпозувати до тих пір, поки не буде досягнута необхідна кількість деталей. На рисунку 3.1 представлена концептуальна діаграма функції системи.
Рисунок 3.1 – Концептуальна діаграма функції «Автоматизація прийняття рішень, щодо видачі банківських кредитів» з точки зору користувача
Для продуктивної обробки та аналізу даних, необхідно зібрати дані, які будуть корисні для отримання ефективного прогнозу. Під корисними даними, передбачається така інформація, яка має вагу щодо вирішення надання чи відмови у позиці. Загалом, кожна людина, що приходить до банку, в очікуванні отримати кредит, надає первинні дані, які потрапляють до системи. Ця інформація, що необхідна для заповнення передбачена системою і вважається корисною. Подається для заповнення у вигляді форми, дані вводяться за допомогою співробітника банку. На рисунку 3.2 представлені декомпозиція основної функції системи.
Рисунок 3.2 – Діаграма декомпозиції, що представляє функції системи
Наступним кроком є взаємодія з блоком обробки даних, де проходить перевірка інформації та внесення до системи. Система передбачає використання інформації з різних джерел. Далі проводиться пошук інформації про клієнта на різних сервісах. Після видобутку всієї доступної інформації, збір даних завершено і вони передаються у блок обробки.
Будь-яка інформація, що потрапляє до системи є необробленою, тобто кожна ознака клієнта, яка може надходити до системи з інших систем чи підсистем, має проходити перевірку, перетворення, нормалізацію.
Для того, щоб метод аналізу даних для класифікації заявок на кредити відпрацьовував найбільш ефективно, система виконує перевірку даних. Наприклад, користувач залишив номер телефона, відбувається перевірка номера, чи дійсно він належить цьому користувачеві. Перевірка паспортних даних, перевірка нерухомості та ін. Кожна з ознак, що пройшла, або не пройшла перевірку подається до системі у вигляді булевої ознаки.
Деякі дані, що надає користувач, мають лише інформативний характер і при аналізі можуть дати слабий результат, але якщо їх трохи перетворити то ситуація зміниться. Наприклад, користувач вказав свій робочий телефон, система обробить ці дані та використає у якості ознаки, не сам номер, а ознаку його належності у вигляді булевого показника.
Всі дані зберігаються у базу даних, на основі СУБД Oracle, тож перед внесенням вони проходять нормалізацію до 3 нормальної форми.
Блок аналізу даних є основою для прийняття рішення, щодо підтвердження чи відхилення заявки клієнта на отримання кредиту. Дані, що потрапляють до цього блоку є обробленими, перевіреними та нормалізованими. Для аналізу даних, використовується метод на основі комбінування алгоритмів CART та SVM, який поєднує в собі деякі переваги обох методів. На рисунку 3.3 представлена декомпозиція функції «Аналіз даних». Прогнозування проходить за допомогою комбінованого методу, до якого подаються детальні дані клієнта.
Рисунок 3.3 – Діаграма декомпозиції функції «Аналіз даних»
Спочатку метод проходить навчання на вибірці всіх клієнтів, де за допомогою дерева рішень визначаються вагові коефіцієнти для кожної з ознак, далі відсіюються неважливі ознаки та дані передаються до алгоритму SVM. Після навчання, система може приступити до прогнозування, щодо видачі кредиту клієнтові. Система надає своє рішення працівнику, з додатковими метриками точності, співробітник банку приймає рішення на основі отриманих результатів.
Розроблена модель функціональних вимог, з усіма описаними функціями використана у проектуванні та розробці системи. Було виділено концептуальний зміст системи, основні функції та важливі моменти головної функції, що виконує аналіз даних.
Проектування системи підтримки рішень для оцінки заявок на отримання кредиту
Діаграма варіантів використання системи
При проектуванні системи важливою складовою є виділення ролей та варіантів використання системи. Діаграма варіантів використання (Use case) описує взаємовідносини і залежності між групами варіантів використання і дійовими особами, які беруть участь в процесі. На рисунку 4.1 представлена Use Case діаграма системи.
Рис. 4.1 – Use Case діаграма системи
Відповідно до діаграми, наведеної вище, було виділено дві основні ролі у системі: співробітник банку, клієнт банку. Співробітник банку може використовувати наступні функції системи:
реєстрація;
авторизація;
створення заявки на кредит;
керування інформацією про клієнта, що включає в себе:
внесення інформації про клієнта;
перегляд інформації про клієнта;
проведення аналізу заявки клієнта на кредит, що включає в себе:
перегляд результатів після аналізу;
експорт даних, отриманих після аналізу;
керування рішенням про видачу позики, що включає в себе:
підтвердження заявки на кредит;
відмова у кредитуванні;
формування документу про результат.
Клієнт банку у свою чергу може користуватися наступними функціями системи:
створення заявки на кредит;
перегляд заявки на кредит;
авторизація;
перегляд рішення, щодо його заявки на кредит;
Таким чином, співробітник банку, разом з клієнтом банку, заповнюють заявку на отримання кредиту, вносять необхідну інформацію про клієнта до системи. Співробітник переглядає передбачення та необхідні метрики, сформовані системою, на основі чого, виносить рішення, підтвердити чи відмовити у кредитуванні. Клієнт, може зайти у систему та перевірити дані, що містяться про нього у системі, а також дізнатися рішення щодо отримання одержання позики.
Розробка структурної схеми інформаційної системи підтримки прийняття рішень для аналізу заявок на отримання позики
Завдяки тому, що функціональні вимоги визначені, ролі та прецеденти системи з’ясовано, веб-системи, що подібні до розроблюваної проаналізовано, було розроблену структурну схему, на якій зображені основні компоненти системи (рисунок 4.2).
Рис. 4.2 – Структурна схема компонентів системи, та їх взаємодії
На структурній схемі представлені наступні компоненти проектованої системи:
інтерфейс користувача;
модуль аналізу даних клієнтів, та видачі прогнозів;
модуль керування інформацією клієнтів банку;
модуль реєстрації та авторизації;
модуль формування документів про результат;
модуль персонального кабінету користувача;
модуль взаємодії з зовнішніми ресурсами;
база даних.
Всі компоненти мають свої зв’язки з іншими компонентами системи, деякі можуть бути використані через інтерфейс користувача, а деякі лише іншими компонентами. Структурна схема дозволяє більш детально розібратися у зв’язках модулів між собою.
Обґрунтування архітектури системи
Для розробки системи, було прийнято рішення використовувати клієнт-серверну архітектуру. Така архітектура дозволяє розділити навантаження між клієнтом і сервером. Клієнт-серверна архітектура описує зв’язок між двома комп’ютерними додатками, клієнтський додаток виконує запит на обслуговування серверному додатку. Ця особливість дозволяє декільком користувачам мати доступ до однієї і тієї ж бази даних одночасно, а також зберігати та накопичувати великі об’єми даних.
Клієнт розпочинає спілкування та використовується для запускання функцій та доступу до даних, що зберігаються на сервері. Зазвичай, клієнтські додатки менш складні ніж серверні, адже вони, та у більшості випадків, не потребують спеціальних системних дозволів.
Сервер оброблює запрошені запити на сервіси з клієнту. Іноді для цього необхідні додаткові можливості, до яких клієнтський додаток не має доступу. Серверний додаток також використовується як інтерфейс доступу до бази даних.
Існують наступні типи клієнт серверної архітектури:
2-шарова архітектура;
3-шарова архітектура;
N-шарова архітектура.
Кожен тип архітектури використовують для різних цілей. Розглянемо детальніше кожен з типів.