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

Оглавление

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСОБЕННОСТИ РАБОТЫ


МИКРОФИНАНСОВОЙ ОРГАНИЗАЦИИ В УСЛОВИЯХ ЦИФРОВОЙ
ЭКОНОМИКИ ......................................................................................................... 3
1.1 Современное состояние развития информационных систем и
технологий в сфере кредитования ......................................................................... 3
1.2 Назначение и основные функции скоринговых систем. ....................... 6
1.3 Подходы к разработке программного обеспечения для
микрофинансовых организаций в условиях цифровой экономики ................. 11
ГЛАВА 2. АНАЛИЗ ПРЕДПРИЯТИЯ ООО «АйДиЭф Технолоджи».... 17
2.1. Характеристика предприятия и оказываемых услуг .......................... 17
2.1.1 Резюме компании ................................................................................. 17
2.1.2.Характеристика производственно-хозяйственной деятельности
компании ................................................................................................................ 18
2.1.3 Характеристика предоставляемых услуг ........................................... 21
2.1.4. Характеристика имеющихся основных средств и технологий ...... 22
2.2. Анализ использования информационных технологий в управлении
предприятием ......................................................................................................... 24
2.2.1. Новизна технических и технологических решений,
потребительских свойств...................................................................................... 24
2.2.2. Кадровый ресурс ................................................................................. 31
2.2.3. Используемые информационные технологии .................................. 32
2.2.4. Текущие и планируемые объемы выпуска товаров в натуральном и
денежном выражении. .......................................................................................... 33
2.2.5. Инвестиционный план. Объекты инвестиций.................................. 34
2.2.6. Выявленные проблемы в реализации CRM системы ...................... 34
ГЛАВА 3. РАЗРАБОТКА ПРОТОТИПА СКОРИНГОВОЙ СИСТЕМЫ 36
3.1. Анализ объекта автоматизации ............................................................ 36
3.2. Построение модели вариантов использования ................................... 37
3.2.1 Требования к системе .......................................................................... 37
3.2.2 Глоссарий проекта................................................................................ 37
3.2.3 Диаграмма вариантов использования ................................................ 38
3.3 Структура системы.................................................................................. 40
1
3.4 Проектирование классов ........................................................................ 41
3.4.1 Диаграмма концептуальных классов ................................................. 41
3.4.2 Диаграмма состояний .......................................................................... 41
3.5 Проектирование схемы данных ............................................................. 43
ЗАКЛЮЧЕНИЕ ............................................................................................. 46
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ......................................... 47
ПРИЛОЖЕНИЕ А ......................................................................................... 48

2
ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСОБЕННОСТИ РАБОТЫ
МИКРОФИНАНСОВОЙ ОРГАНИЗАЦИИ В УСЛОВИЯХ
ЦИФРОВОЙ ЭКОНОМИКИ
1.1 Современное состояние развития информационных
систем и технологий в сфере кредитования
Выдача кредита населению является традиционной услугой любого
банка. Год за годом она получается все большее распространение. Развитие
приобретают получение кредитов на обучение, автомобильное кредитование
и ипотека. Так же банки активно внедряют информационные технологии в
процесс кредитования.
Целью данной работы является исследование информационных
технологий в процессе кредитования физических лиц.
Скоринговое кредитование. В процессе выдачи потребительских
кредитов имеют место небольшие суммы, что провоцирует большой объем
работы по их оформлению. Это является довольно дорогостоящей процедурой
оценки кредитоспособности, сравнительно получаемой в результате прибыли.
При оценке кредитоспособности граждан банк производит проверку как
финансового положения заемщика, так и его личных качеств. При этом стоит
учитывать риск невозврата существенной суммы долга и ее процентов. В наши
дни довольно часто для оценки риска кредитования заемщика применяется
скоринг кредитование.
В основе скоринговых систем лежит гипотеза, что люди с похожими
социальными признаками ведут себя одинаково. Согласно этому суждению
можно выстроить разные статистические модели, которые окажутся весьма
полезными при организации любого бизнеса.
Одной из самых успешных систем является модель кредитного скоринга
Дюрана. Для проведения данного процесса необходимо выделить факторы из
имеющихся у банка данных о заемщике, которые позволят оценить степень
кредитного риска. В связи с этим существует методика оценки, состоящая в
присвоении баллов за определенные значения этих факторов, для этого надо
просуммировать баллы и сравнить полученную сумму с пороговым
значением.
При наборе 1,25 баллов и выше заемщик считается кредитоспособным.
После нужного набора баллов идет процесс заключения кредитного договора,
в котором имеет мест изучение кредитной истории.

3
Рис. 1 Модель кредитного скоринга Дюрана
Кредитные истории. Кредитная история – это накопленные в течение
длительного времени данные о получении и погашении заемщиком
банковских кредитов. Можно сказать, что это своего рода паспорт заемщика,
который характеризует его надежность с точки зрения возврата кредита. Банки
используют этот паспорт, принимая решение о предоставлении кредита
конкретному заемщику (но это, безусловно, не единственный фактор для
банка).
Бюро кредитных историй (БКИ) – это юридические лицо, которое
зарегистрировано в соответствии с законодательством, является организацией
коммерческого характера и предоставляет сервис не только по составлению,
обработке и сохранению кредитных историй, но и по передаче кредитных
ведомостей и прилагающих услуг.
В состав кредитной истории входит четыре части: титульная, основная,
закрытая и информационная части.
Титульная часть содержит в себе сведения о заемщике (в нашем случае
о физическом лице), которые дают возможность его идентификации.

4
Основная часть содержит информацию о кредитах заемщика. Эта часть
может включать в себя несколько разделов, например информацию о
безнадежных и активных кредитах и т. д.
Закрытая часть состоит из сведений об учреждениях, которые подавали
сведения в кредитную историю, а также о том, кто и когда запрашивал эту
информацию. Эта часть доступна только для самого субъекта кредитной
истории, поэтому немало важно задуматься о методах защиты персональных
данных. Данная процедура будет особенно важной, если вы совершаете
вклады через интернет или же ведете переписку с банком через электронную
почту.
Криптографические методы защиты данных. На данный момент
существует такие системы электронный платежей, как PayCash, Яндекс.
Деньги, MoneyMail. Они позволяют клиентам использовать свои счета
удаленно, или же удаленно через интернет оформлять кредитные пластиковые
карты. Но возникает проблема защиты этих операций.
На сегодняшний день одной из самых эффективных видов технической
защиты является криптографическая защита информации.
Криптографические методы защиты данных – это такие способы
зашифровки или другие преобразования информации, в результате которых ее
содержание становится недоступным без предъявления ключа криптограммы
и обратного изменения. Криптографический метод защиты, несомненно, один
из самых достоверных методов защиты, потому что охраняется именно сама
информация, а не доступ к ней (к примеру, зашифрованный файл невозможно
прочесть при возможности кражи носителя). Реализация этого способа защиты
происходит в виде программ или пакетов программ.
На данный момент криптография представляет собой четыре области:
• Симметричные криптосистемы. В симметричных криптосистемах и
для шифрования, и для дешифрования используется один и тот же ключ;
• Криптосистемы с открытым ключом. В данной системе присутствуют
только два ключа – открытый и закрытый, которые математически связаны
друг с другом. Информация кодируется при помощи открытого ключа,
который доступен каждому, а декодируется с помощью закрытого ключа,
известного только адресату. (Ключом являются данные, необходимые для
беспрепятственного шифрования и дешифрования текстов.);
• Управление ключами. Это процесс обработки информации, смысл
которого является в формировании и распространении ключей между
пользователями;
• Электронная подпись. Данный метод позволяет при получении текста
другим пользователем проверить его подлинность.

5
Основными направлениями использования криптографических методов
являются передача личных данных по каналам связи (например, электронная
почта), выявление подлинности передаваемых сообщений, а также хранение
информации (документов, баз данных) на носителях в зашифрованном виде.
1.2 Назначение и основные функции скоринговых систем.
Скоринг представляет собой математическую или статистическую
модель, с помощью которой на основе кредитной истории «прошлых»
клиентов банк пытается определить, насколько велика вероятность, что
конкретный потенциальный заемщик вернет кредит в срок.
В западной банковской системе, когда человек обращается за кредитом,
банк может располагать следующей информацией для анализа:
• анкета, которую заполняет заемщик;
• информация на данного заемщика из кредитного бюро —
организации, в которой хранится кредитная история всего взрослого
населения страны;
• данные движений по счетам, если речь идет об уже
действующем клиенте банка.
Кредитные аналитики оперируют следующими понятиями:
«характеристики» клиентов (в математической терминологии — переменные,
факторы) и «признаки» — значения, которые принимает переменная. Если
представить себе анкету, которую заполняет клиент, то характеристиками
являются вопросы анкеты (возраст, семейное положение, профессия), а
признаками — ответы на эти вопросы.
В самом упрощенном виде скоринговая модель представляет собой
взвешенную сумму определенных характеристик. В результате получается
интегральный показатель (score); чем он выше, тем выше надежность клиента,
и банк может упорядочить своих клиентов по степени возрастания
кредитоспособности.
Интегральный показатель каждого клиента сравнивается с неким
числовым порогом, или линией раздела, которая, по существу, является
линией безубыточности и рассчитывается из отношения, сколько в среднем
нужно клиентов, которые платят в срок для того, чтобы компенсировать
убытки от одного должника. Клиентам с интегральным показателем выше
этой линии выдается кредит, клиентам с интегральным показателем ниже этой
линии — нет.
Все это выглядит очень просто, однако сложность заключается в
определении, какие характеристики следует включать в модель и какие
весовые коэффициенты должны им соответствовать. К этой проблеме имеется

6
несколько подходов, которые будут рассмотрены в разделе «Методы
классификации клиентов».
Философия скоринга заключается не в поиске объяснений, почему этот
человек не платит. Скоринг выделяет те характеристики, которые наиболее
тесно связаны с ненадежностью или, наоборот, с надежностью клиента. Мы не
знаем, вернет ли данный заемщик кредит, но мы знаем, что в прошлом люди
этого возраста, этой же профессии, с таким же уровнем образования и с таким
же числом иждивенцев кредит не возвращали. Поэтому мы давать кредит
этому человеку не будем.
В этом заключается дискриминационный (не в статистическом, а в
социальном значении этого слова) характер скоринга, т. е. если человек по
формальным признакам близок к группе с плохой кредитной историей, то ему
кредит не дадут. Поэтому даже при очень высокой степени использования
автоматизированных систем скоринга осуществляется субъективное
вмешательство в случае, когда кредитный инспектор располагает
дополнительной информацией, доказывающей, что человек,
классифицированный как ненадежный, на самом деле «хороший», и наоборот.
В Великобритании наиболее часто используются следующие
характеристики:
• Возраст
• Количество детей/иждивенцев
• Профессия
• Профессия супруга(и)
• Доход
• Доход супруга(и)
• Район проживания
• Стоимость жилья
• Наличие телефона
• Сколько лет живет по данному адресу
• Сколько лет работает на данной работе
• Сколько лет является клиентом данного банка
• Наличие кредитной карточки/чековой книжки
В других странах набор характеристик, которые наиболее тесно связаны
с вероятностью дефолта — вероятностью, что заемщик не вернет кредит или
задержится с выплатой, будет отличаться в силу национальных
экономических и социально-культурных особенностей. Чем более однородна
популяция клиентов, на которой разрабатывается модель, тем точнее
прогнозирование дефолта. Поэтому очевидно, что нельзя автоматически
перенести модель из одной страны в другую или из одного банка в другой.
7
Даже внутри одного банка существуют различные модели для различных
групп клиентов и различных видов кредита.
Скоринг, по существу, является методом классификации всей
интересующей нас популяции на различные группы, когда нам неизвестна
характеристика, которая разделяет эти группы (вернет клиент кредит или нет),
но зато известны другие характеристики, связанные с интересующей нас. В
статистике идеи классификации популяции на группы были разработаны
Фишером в 1936 г. на примере растений. В 1941 г. Дэвид Дюран впервые
применил данную методику к классификации кредитов на «плохие» и
«хорошие». По времени это совпало со Второй мировой войной, когда почти
все кредитные аналитики были призваны на фронт, и банки столкнулись с
необходимостью срочной замены этих специалистов. Банки заставили своих
аналитиков перед уходом написать свод правил, которыми следовало
руководствоваться при принятии решения о выдаче кредита, чтобы анализ мог
проводиться неспециалистами. Это и был как бы прообраз будущих
экспертных систем.
В начале 50-х гг. в Сан-Франциско образовалась первая консалтинговая
фирма в области скоринга — Fair Issac, которая до сих пор является лидером
среди разработчиков скоринговых систем.
Но широкое применение скоринга началось с распространением
кредитных карточек. При том количестве людей, которые ежедневно
обращались за кредитными карточками, банкам ничего другого не оставалось,
как автоматизировать процесс принятия решений по выдаче кредита. Однако
очень скоро они оценили не только быстроту обработки заявлений на выдачу
кредита, но и качество оценки риска. По данным некоторых исследований,
после внедрения скоринг-систем уровень безнадежного долга сокращался до
50%.
В 1974 г. в США был принят Закон о предоставлении равных
возможностей на получение кредита, который запрещал отказывать в выдаче
кредита на основании следующих характеристик: раса, цвет кожи,
национальное происхождение, возраст, пол, семейное положение, религия,
получение социальных пособий, отстаивание прав потребителей. В
Великобритании законодательство допускает использование информации о
возрасте и семейном положении, но зато запрещает принимать во внимание
какие-либо физические увечья и недостатки (инвалидность). Для кредитных
организаций использование скоринговых систем стало доказательством
исполнения этих антидискриминационных законов — у компьютера нет
предубеждений.
Помимо установления принципов равноправия в области кредитования,
кредитное законодательство США, как и Закон о потребительском кредите,
8
принятый в Великобритании в том же 1974 г., имели важное значение для
формирования службы кредитных бюро. В таких бюро записывается
кредитная история всех людей, когда-либо обращавшихся за ссудой в любую
кредитную организацию страны.
В кредитных бюро содержатся следующие виды данных:
• социально-демографические характеристики;
• судебные решения (в случае передачи дел о востребовании
задолженности по кредиту в суд);
• информация о банкротствах;
• данные об индивидуальных заемщиках, получаемые от
кредитных организаций по принципу «ты — мне, я — тебе», т. е.
банк может получать информацию о клиентах других банков,
только если сам поставляет аналогичную информацию.
Объем и характер информации, хранящейся в бюро, строго регулируется
законодательством каждой страны. Хотелось бы добавить, что помимо
рассмотренных в статье моделей бюро существуют и транснациональные
коммерческие компании, такие как Experian, Equifax, TransUnion, Scorex. Эти
компании сами используют скоринговые системы, и во многих случаях
продают клиентам не «сырую» информацию, а уже готовый интегральный
показатель, который вводится в автоматизированную систему кредитной
организации.
Значение кредитных бюро чрезвычайно велико, их существование
позволяет кредитным организациям выдавать ссуды клиентам, которые ранее
в этой организации не обслуживались. Кроме того, общепризнанной является
ценность предыдущей кредитной истории для прогнозирования вероятности
дефолта.
В настоящее время скоринг становится все более популярным не только
при оценке риска при различных видах кредита, но и в других областях: в
маркетинге (для определения вероятности, что именно эта группа клиентов
будет пользоваться этим видом продукции), при работе с должниками (если
клиент задерживается с очередным платежом, какой метод воздействия будет
наиболее эффективным), при выявлении мошенничества с кредитными
карточками, при определении вероятности, что клиент может перебежать к
конкуренту и т. п.
Методы классификации клиентов весьма разнообразны и включают в
себя:
• статистические методы, основанные на дискриминантном
анализе (линейная регрессия, логистическая регрессия);
• различные варианты линейного программирования;

9
• дерево классификации или рекурсионно-партиционный
алгоритм (РПА);
• нейронные сети;
• генетический алгоритм;
• метод ближайших соседей.
Традиционными и наиболее распространенными являются
регрессионные методы, прежде всего линейная многофакторная регрессия:
р = wo + w1x1 + w2x2 + … + wnxn ,
где р —вероятность дефолта, w —весовые коэффициенты, x —
характеристики клиента.
Недостаток данной модели заключается в том, что в левой части
уравнения находится вероятность, которая принимает значения от 0 до 1, а
переменные в правой части могут принимать любые значения от - Ґ до + Ґ.
Логистическая регрессия позволяет преодолеть этот недостаток:
log (p/(1-p)) = wo + w1x1 + w2x2 + … + wnxn.
Для применения логистической регрессии необходимы гораздо более
сложные расчеты для получения весовых коэффициентов и, следовательно,
более мощная компьютерная база и усовершенствованное компьютерное
обеспечение. Но при современном уровне развития компьютерной техники это
не является проблемой, и в настоящее время логистическая регрессия является
лидером скоринговых систем.
Преимущество логистической регрессии еще и в том, что она может
подразделять клиентов как на две группы (0 — плохой, 1 — хороший), так и
на несколько групп (1, 2, 3, 4 группы риска).
Все регрессионные методы чувствительны к корреляции между
характеристиками, поэтому в модели не должно быть сильно
коррелированных независимых переменных.
Линейное программирование также приводит к линейной
скоринговой модели. Провести абсолютно точную классификацию на плохих
и хороших клиентов невозможно, но желательно свести ошибку к минимуму.
Задачу можно сформулировать как поиск весовых коэффициентов, для
которых ошибка и будет минимальной.
Дерево классификации и нейронные сети представляют собой
системы, которые разделяют клиентов на группы, внутри которых уровень
риска одинаков и максимально отличается от уровня риска других групп.
Нейронные сети используются главным образом при определении
кредитоспособности юридических лиц, где анализируются выборки меньшего
размера, чем в потребительском кредите. Но наиболее успешной областью их

10
применения стало выявление мошенничества с кредитными карточками
благодаря их способности выявлять нестандартные ситуации.
Генетический алгоритм основан на аналогии с биологическим
процессом естественного отбора. В сфере кредитования это выглядит
следующим образом: имеется набор классификационных моделей, которые
подвергаются «мутации», «скрещиваются», и в результате отбирается
«сильнейший», т. е. модель, дающая наиболее точную классификацию.
При использовании метода ближайших соседей выбирается единица
измерения для определения расстояния между клиентами. Все клиенты в
выборке получают определенное пространственное положение. Каждый
новый клиент классифицируется исходя из того, каких клиентов — плохих или
хороших — больше вокруг него.
На практике используется комбинация нескольких методов, и компании
хранят свои скоринговые модели в строжайшем секрете, поэтому сложно
сказать, какой метод лучше. Можно только делать приблизительные
заключения, основываясь на научных публикациях, ниже приводится
сравнительная таблица точности классификации для различных методов,
составленная профессором Л. Томасом.
Сравнение следует производить только горизонтально, потому что
авторы использовали разные определения «хороших» рисков и проводили
исследования на различных популяциях и выборках. Таблица показывает
процент правильно классифицированных клиентов. Цель всех приведенных
исследований заключалась в сравнении эффективности различных методов
классификации, поэтому не следует делать вывод, что данные цифры
показывают эффективность скоринговых систем в целом, так как уже
говорилось, что коммерческие системы используют несколько методов.
1.3 Подходы к разработке программного обеспечения для
микрофинансовых организаций в условиях цифровой
экономики
В настоящее время выделяют 2 подхода к разработке программного
обеспечения: каскадная модель и спиральная модель.
В изначально существовавших однородных ИС каждое приложение
представляло собой единое целое. Для разработки такого типа приложений
применялся каскадный способ. Его основной характеристикой является
разбиение всей разработки на этапы, причем переход с одного этапа на
следующий происходит только после того, как будет полностью завершена
работа на текущем. Каждый этап завершается выпуском полного комплекта
документации, достаточной для того, чтобы разработка могла быть
продолжена командой специалистов на следующем этапе.

11
Рисунок 2. Каскадная схема разработки ПО
Положительные стороны применения каскадного подхода заключаются
в следующем:
• на каждом этапе формируется законченный набор проектной
документации, отвечающий критериям полноты и согласованности;
• выполняемые в логичной последовательности этапы работ позволяют
планировать сроки завершения всех работ и соответствующие затраты.
Основным недостатком каскадного подхода является существенное
запаздывание с получением результатов. Согласование результатов с
пользователями производится только в точках, планируемых после
завершения каждого этапа работ, требования к ИС “заморожены” в виде
технического задания на все время ее создания. Таким образом, пользователи
могут внести свои замечания только после того, как работа над системой будет
полностью завершена. В случае неточного изложения требований или их
изменения в течение длительного периода создания ПО, пользователи
получают систему, не удовлетворяющую их потребностям. Модели (как
функциональные, так и информационные) автоматизируемого объекта могут
устареть одновременно с их утверждением.
Спиральная модель, в отличие от каскадной, предполагает
итерационный процесс разработки информационной системы.
Каждая итерация представляет собой законченный цикл разработки,
приводящий к выпуску внутренней или внешней версии изделия (или
подмножества конечного продукта), которое совершенствуется от итерации к
итерации, чтобы стать законченной системой.

12
Рисунок 4. Спиральная модель разработки ПО
Использование спиральной модели позволяет осуществлять переход на
следующий этап выполнения проекта, не дожидаясь полного завершения
текущего — недоделанную работу можно будет выполнить на следующей
итерации. Главная задача каждой итерации — как можно быстрее создать
работоспособный продукт, который можно показать пользователям системы.
Таким образом существенно упрощается процесс внесения уточнений и
дополнений в проект.
Спиральный подход к разработке программного обеспечения позволяет
преодолеть большинство недостатков каскадной модели и, кроме того,
обеспечивает ряд дополнительных возможностей, делая процесс разработки
более гибким.
Рассмотрим преимущества итерационного подхода более подробно.
Итерационная разработка существенно упрощает внесение изменений в
проект при изменении требований заказчика.
13
При использовании спиральной модели отдельные элементы
информационной системы интегрируются в единое целое постепенно. При
итерационном подходе интеграция производится фактически непрерывно.
Поскольку интеграция начинается с меньшего количества элементов, то
возникает гораздо меньше проблем при ее проведении (по некоторым
оценкам, при использовании каскадной модели разработки интеграция
занимает до 40 % всех затрат в конце проекта).
Уменьшение уровня рисков. Данное преимущество является следствием
предыдущего, так как риски обнаруживаются именно во время интеграции.
Поэтому уровень рисков максимален в начале разработки проекта. По мере
продвижения разработки ожидаемый уровень рисков снижается. Данное
утверждение справедливо при любой модели разработки, однако при
использовании спиральной модели снижение уровня рисков происходит с
наибольшей скоростью. Это связано с тем, что при итерационном подходе
интеграция выполняется уже на первой итерации, и на начальных итерациях
выявляются многие аспекты проекта, такие как пригодность используемых
инструментальных средств и программного обеспечения, квалификация
разработчиков и т. п.
Итерационная разработка обеспечивает большую гибкость в управлении
проектом, давая возможность внесения тактических изменений в
разрабатываемое изделие. Например, можно сократить сроки разработки за
счет снижения функциональности системы или использовать в качестве
составных частей системы продукцию сторонних фирм вместо собственных
разработок. Это может быть актуальным в условиях конкурентной борьбы,
когда необходимо противостоять продвижению изделия, предлагаемого
конкурентами.
Итерационный подход упрощает повторное использование
компонентов. Это обусловлено тем, что гораздо проще выявить
(идентифицировать) общие части проекта, когда они уже частично
разработаны, чем пытаться выделить их в самом начале проекта. Анализ
проекта после проведения нескольких начальных итераций позволяет выявить
общие многократно используемые компоненты, которые на последующих
итерациях будут совершенствоваться.
Спиральная модель позволяет получить более надежную и устойчивую
систему. Это связано с тем, что по мере развития системы ошибки и слабые
места обнаруживаются и исправляются на каждой итерации. Одновременно
могут корректироваться критические параметры эффективности, что в случае
каскадной модели доступно только перед внедрением системы.
На начальной стадии проекта полностью и точно сформулировать все
требования к будущей модели невозможно, поскольку пользователи, как
14
правило, не в состоянии изложить все свои требования и не могут предвидеть,
как они изменятся в ходе разработки, и , кроме того, за время разработки могут
произойти изменения во внешней среде, которые могут повлиять на
требования к системе. Поэтому процесс создания ПО носит скорее
итерационный характер, когда результаты очередной стадии разработки могут
вызвать необходимость возврата к предыдущим разработкам.
Поэтому ПО создается не сразу, как в случае каскадного подхода, а
постепенно с использованием макетирования (прототипирования), когда
создается модель требуемого программного продукта. Под прототипом
понимается действующий программный компонент, реализующий отдельные
функции.
Модель может принимать одну из трех форм:
- бумажный макет или макет на основе ПК (изображает или рисует
человеко – машинный диалог),
- работающий макет (выполняет некоторую часть требуемых функций),
- существует программа, характеристики которой затем должны быть
улучшены.
Макетирование основывается на многократном повторении итераций, в
которых участвуют заказчик и разработчик.
Поскольку часто заказчик не может определиться в своих требованиях
по разрабатываемому продукту, а проектировщик сомневается в полноте и
целесообразности требований заказчика, то прототипирование
(макетирование) начинается со сбора и уточнения требований к создаваемому
ПО.
Совместными усилиями разработчик и заказчик определяют все цели
ПО, устанавливают, какие требования известны, а какие предстоит
доопределить. Следующим шагом является быстрое проектирование,
внимание в котором сосредотачивается на тех характеристиках ПО, которые
должны быть видимы пользователю. Макет (прототип), построенный на этапе
быстрого проектирования, оценивается заказчиком и используется для
уточнения требований к ПО. Итерации повторяются до тех пор, пока макет не
выявит все требования заказчика и не даст возможности разработчику понять,
что должно быть сделано.
Достоинством макетирования является обеспечение определения
полных требований к ПО.
К недостаткам макетирования относятся:
- возможность принятия заказчиком макета за продукт,
- возможность принятия разработчиком макета за продукт
Заказчик, получивший предварительную версию (макет) и
удостоверившийся в ее работоспособности, может перестать видеть
15
недостатки и нерешенные вопросы ПО и перестать соглашаться на
дальнейшее усовершенствование, требуя скорейшего преобразования макета
в рабочий продукт.
Исходя из вышеизложенного можно сделать вывод, что для разработки
скоринговой системы наиболее подходящим является гибкий подход к
разработке программного обеспечения. Это обусловлено тем, что кредитная
политика микрофинансовой организации постоянно меняется, так как
компания анализирует статистику по выданным кредитам, делая выводы о
том, какие ошибки были допущены в прошлом.
Вся деятельность микрофинансовых организаций базируется на методе
проб и ошибок, что напрямую сказывается на формировании требований к
программному обеспечению. Также немаловажную роль играет бизнес-
контекст при разработке скоринговой системы. Ввиду того, что
законодательство в сфере кредитования постоянно меняется, меняются и
требования к разработке, что при каскадной модели категорически
недопустимо.
Таким образом спиральная модель идеально подходит для разработки
такого рода программного продукта, так как требования можно менять в
начале каждой итерации, что делает разработку очень гибкой и позволяет
поддерживать программный продукт на протяжении всего его существования.
Также в данном походе большое внимание уделяется рискам проекта, что
является обязательным при работе с кредитами.

16
ГЛАВА 2. АНАЛИЗ ПРЕДПРИЯТИЯ ООО «АйДиЭф
Технолоджи»
2.1. Характеристика предприятия и оказываемых услуг
2.1.1 Резюме компании
Компания «АйДиЭф Технолоджи» является центром разработки
холдинга ID Finance. Основные направления деятельности компании
соответствуют целям и задачам Стратегии развития информационного
общества в Республике Беларусь.
Приоритетным направлением деятельности ООО «АйДиЭф
Технолоджи» является разработка, внедрение и сопровождение
интегрированных информационных систем для деятельности организаций в
области кредитно-финансовых сервисов. Решения компании придают новые
качества финансовым продуктам: точность, скорость, безопасность, комфорт.
Снижают издержки кредитно-финансовых организаций, увеличивают
финансовую грамотность населения и минимизируют уровень финансового
мошенничества.
Областью разработки программного обеспечения и информационных
технологий компании является CRM-система. Благодаря онлайн-модели
работы CRM-системы, решения ООО «АйДиЭф Технолоджи» легко
масштабируемы и применимы в финансовой отрасли практически любой
страны мира, в которой есть спрос на кредитно-финансовые услуги. Продукты
актуальны как для крупных финансовых корпораций со сложной структурой
финансовых механизмов, в том числе с территориально распределенной
структурой офисов, так и для организаций, относящихся к сектору малого и
среднего бизнеса.
Особенностью стратегии развития компании является
возможность адаптации программного решения к законодательству страны
клиента, вызовам рынка и мировым тенденциям.
Миссия компании совместно с холдингом ID Finance - развивать и
совершенствовать разработку FinTech решений в Республике Беларусь.
Главные цели перспективного стратегического развития заключаются в
постоянном совершенствовании разработки высокотехнологичного
программного продукта, имеющего свои уникальные конкурентные
преимущества на рынке FinTech. Также, учитывая планы по привлечению к
выполнению работы на основании договора о прохождения производственной
практики (2-3 студента в год) и профильному обучению студентов вузов IT
специальностей, компания планирует внести вклад в развитие системы
образования.

17
Компания «АйДиЭф Технолоджи» является центром разработки и
оказывает услуги по разработке и внедрению новых FinTech решений для
группы компаний холдинга ID Finance. Предпосылкой создания собственного
центра разработки программного обеспечения является возможность холдинга
получить в свое распоряжение команду специалистов, подобранных с учетом
индивидуальных потребностей под конкретные проекты, а также для
предпочитаемых методов проектного управления.
К 2023 году компания «АйДиЭф Технолоджи» планирует разработать и
внедрить комплексные финансовые системы на рынках Грузии, Испании,
Казахстана, Польши, Колумбии и Аргентины, используя инновационные
скоринговые модели для всех процессов FinTech системы, увеличивая
количество финансовых сервисов CRM системы и применяя современные
алгоритмы и источники данных, такие как machine learning, биометрические
данные (отпечатки пальцев, голосовая идентификация). Компания намерена
использовать последние технические инструменты и frameworks на всех
этапах разработки CRM системы. Так же планируется внедрить мобильные
версии CRM систем во всех странах холдинга. Помимо поддержки высокого
качества выпускаемого программного обеспечения, это позволит
мотивировать и развивать знания сотрудников и, таким образом, повысить
роль компании как работодателя на рынке Республики Беларусь. Также к 2023
году компания планирует достичь следующих результатов финансово-
экономической деятельности: выручка 6 300 000 долларов США, годовая
производительность труда 47 000 долларов США, рентабельность – 22%,
среднесписочная численность -135 человек и среднемесячная зарплата-2 550
долларов США.
ООО «АйДиЭф Технолоджи» нацелена на создание экспортно
ориентированных программных продуктов, способных привлечь в экономику
страны значительные валютные средства.
Разрабатывая качественные программные продукты ООО «АйДиЭф
Технолоджи» планирует внести весомый вклад в повышение авторитета
белорусских IT-компаний на мировом рынке, а также повысить
конкурентоспособность белорусской экономики.
2.1.2.Характеристика производственно-хозяйственной
деятельности компании
Общество с ограниченной ответственностью «АйДиЭф Технолоджи»
зарегистрировано Минским городским исполнительным комитетом 24 августа
2017 года в Едином государственном регистре юридических лиц и
индивидуальных предпринимателей за №192959748.

18
Юридической адрес: 220125, город Минск, проспект Независимости,
177, пом.1а, 2 этаж, кабинет 6.
Компания учреждена унитарным обществом с ограниченной
ответственностью «Ай-Ди Финанс Инвестментс» (Испания) и обществом с
ограниченной ответственностью «Ай-Ди Финанс Спейн С.Л. (Испания).
Компания «АйДиЭф Технолоджи» входит в международную группу
FinTech компаний ID Finance. Компания «Ай-Ди Финанс Инвестментс»
является управляющей компанией холдинга. Компания учреждена в Испании
и расположенная по адресу Калье Тусет, ном. 10, этаж 5, 08006, г. Барселона,
Испания. Сайт группы компаний https://idfinance.com. В состав холдинга
входят следующие компании:
«MFC MONEY MAN» LLC (Россия);
«ID FINANCE POLAND» SP. Z.O.O. (Польша);
«IDF CAPITAL» SAPI DE CV (Мексика);
«ID FINANCE BRASIL» LTDA (Бразилия);
«Online Finance» LLP (Казахстан);
«Online Finance» LTD (Грузия).
Все компании холдинга ID Finance специализируются в «data science»,
кредитовании и онлайн-кредитовании.
Предпосылкой создания собственного центра разработки программного
обеспечения является возможность холдинга получить в свое распоряжение
команду специалистов, подобранных с учетом индивидуальных потребностей
и целей проектов, а также предпочитаемых методов проектного управления.
Также, собственный центр разработки обеспечивает полный цикл услуг
холдингу, включая анализ и проектирование ПО, изучение структуры проекта,
разработку, частичную поддержку проектов.
Бизнес-модель компании
Компания «АйДиЭф Технолоджи» является центром разработки
холдинга ID Finance. На компанию возложена функция анализа,
проектирования и разработки программного обеспечения для холдинга.
Технологическая и отраслевая специализация, география
Областью разработки программного обеспечения и
информационных технологий компании является CRM-система. Благодаря
онлайн-модели работы, решения ООО «АйДиЭф Технолоджи» легко
масштабируемы. Разработки компании применимы в финансовой отрасли
практически любой страны мира, в которой есть спрос на кредитно-
финансовые услуги, развиты информационные технологии, сформированы
информационная и юридическая инфраструктуры и просто есть интернет.
Спрос на кредитно-финансовые услуги активно растет в России, Европе
и Южной Америке и, соответственно, растет спрос на специализированное
19
ПО, автоматизирующее данные услуги. Человеку проще и удобнее оформить
онлайн заявку на услуги, не вставая с места, имея под рукой интернет,
компьютер, планшет или телефон. Неоднократные походы в финансовые
учреждения, заполнение многочисленных документов, всевозможная
бюрократия-всех этих процедур простому потребителю удастся избежать и его
выбор будет в пользу автоматизированных онлайн-услуг. Для технической
реализации подобных процессов необходимы такие компании, как ООО
«АйДиЭф Технолоджи», которые обеспечивают безопасность,
непрерывность, скорость и удаленность процессов, что снижает издержки.
Операторы финансовых услуг по всему миру находятся в поиске FinTech
партнеров. Им необходимы решения как в области платежей, так и в области
обработки больших данных, выявления полезных знаний, в том числе в оценке
платежеспособности своих клиентов.
Методология разработки
Компания «АйДиЭф Технолоджи» в своей работе использует гибкую
методологию разработки ПО, построенную на основе правил и практик Agile,
Scrum, которая является одной из наиболее популярных методологий
разработки ПО.
Качество
В данный момент компания «АйДиЭф Технолоджи» активно занимается
формированием плана мероприятий по развитию компании и повышению
качества продукции (услуг) для достижения целей в области качества и
показателей результативности бизнес-процессов СМК (система менеджмента
качества). Идет начальная фаза разработки документированных процедур, в
том числе:
▪ стратегии развития организации;

▪ управления рисками;
▪ управления документацией;
▪ управления изменениями;
▪ внутренних аудитов СМК;
▪ управления несоответствиями и корректирующие действия;
▪ автоматизации тестирования и мониторинга системы.
Кроме того, для успешной работы на рынках Евросоюза, Южной
Америки и других регионов дальнего зарубежья предполагается получение
сертификатов соответствия системе менеджмента качества стандарта ISO
9001.
Исключительное право

20
Исключительное право на разрабатываемые объекты интеллектуальной
собственности «АйДиЭф Технолоджи» передает заказчику.
Способ монетизации разработок, продуктов
Способом монетизации продуктов компании являются
фиксированные ежемесячные платежи за услуги по разработке программного
обеспечения.
Система налогообложения
На сегодняшний день ООО «АйДиЭф Технолоджи» работает по
общей системе налогообложения.
Перечень планируемых видов деятельности
В качестве резидента ПВТ ООО «АйДиЭф Технолоджи»
осуществляет следующие виды деятельности:
- анализ, проектирование и программное обеспечение информационных
систем;
- консультирование организаций по вопросам коммерческой деятельности
и управления в целях повышения их эффективности с оказанием услуг по
комплексному управлению процессами разработки и внедрения
интегрированных информационных систем и технологий;
- выполнение отдельных работ (этапов работ), составляющих процесс
разработки программного обеспечения (программных средств), поддержка,
сопровождение программного обеспечения (программных средств)
потребителей или собственного программного обеспечения (программных
средств);
- аудит информационных систем и программного обеспечения в процессе
их разработки, внедрения и эксплуатации на соответствие техническим
требованиям и (или) информационным потребностям пользователей по заказам
юридических лиц и индивидуальных предпринимателей Республики Беларусь;
- услуги по внедрению, сопровождению корпоративных информационных
систем или по выполнению отдельных этапов их внедрения.
2.1.3 Характеристика предоставляемых услуг
Компания начала уникальную разработку комплексного решения по
автоматизации работы кредитно-финансовых компаний и сервисов, CRM-
система строится на микросервисах и отказоустойчивой инфраструктуре.
Система покрывает все основные аспекты деятельности кредитно-
финансовой организации, включая привлечение потенциальных клиентов
и полный цикл автоматического учета займов и кредитов. Автоматизирует
процессы привлечения заявок, идентификации клиентов, оценку
кредитоспособности, выдачу денежных средств, погашение займов
(кредитов), мониторинг, администрирование, работу контактного-центра

21
(клиентской поддержки), работу с просроченными займами и
коллекторами.
Решение строится по модульному принципу - на данный
момент разрабатываются более 15 модулей. Это позволяет подобрать
оптимальную конфигурацию для любой компании и легко
интегрироваться с любыми сторонними продуктами, включая
скорринговые системы, 1С-бухгалтерию, клиент-банки, а также с
кредитными бюро и государственными службами.
На сегодняшний день первым потребителем разработки нашей
организации является российская компания ООО МФК «Мани Мен». Для
компании разрабатываются два проекта: «Solva РФ 2.0» (среднесрочные
потребительские кредиты до года) и «MoneyMan РФ 2.0» (краткосрочные
онлайн-займы). МФК «Мани Мен» были передан модуль «Займы».
2.1.4. Характеристика имеющихся основных средств и
технологий
В настоящий момент компания «АйДиЭф Технолоджи» арендует
помещения площадью 181,4 кв. м. по адресу проспект Независимости, 177.
Офис компании оборудован офисной мебелью и необходимой техникой.
Компания оснащена средствами производства: локальной сетью
современных ноутбуков с процессорами Intel® CoreTM i5-i7, оперативной
памятью 16 GB и жесткими дисками 1ТВ. Также заключен договор на покупку
сервера DELL
В компании IT специалистами выполняются работы, предполагающие
использование следующего лицензионного программного обеспечения:
• - платформы: Linux, Windows Server;
• - платформы разработки: J2EE, Angular, Php, Android;
• - базы данных: MySQL, Mongo, GridFS, DB2;
• - серверы приложений: GlassFish, Tomcat, Jetty.
Сведения об обеспеченности:
№ Ед. На
Наименование
п/п изм. 31.12.2020
1. Основные средства
руб.
из них: 24 300
1.1. вычислительная оргтехника. руб. 24 300
2. Нематериальные активы
руб.
из них: 15 000
2.1. компьютерные программы. руб. 15 000

22
Таблица 1. Сведения об обеспеченности. Источник: данные компании.
Таким образом можно сказать, что компания «АйДиЭф Технолоджи»
создала максимально благоприятные условия для создания и
совершенствования уникальных IT-продуктов. Престиж компании позволил
ей выйти на международный рынок и разрабатывать программные продукты
для таких стран как Мексика, Бразилия, Казахстан, Грузия и Польша. Гибкая
методология разработки позволяет поддерживать ПО на достойном уровне,
так как каждые 2 недели планируются новые спринты, в которых
разрабатывается новый функционал и делаются доработки по старому
функционалу. Приобретённая вычислительная техника и программы
позволяют команде разработки не терять время на ожидание загрузок, что
делает процесс разработки гораздо эффективнее.

23
2.2. Анализ использования информационных технологий в
управлении предприятием
2.2.1. Новизна технических и технологических решений,
потребительских свойств
Разработки компании «АйДиЭф Технолоджи» обладают
технологической новизной, обеспечивающей их превосходство над
существующими аналогами. Система основана на микросервисах, написанных
на языке Java и развернута на отказоустойчивой инфраструктуре,
использующей Docker, ELK, Netflix stack, что также позволяет ускорить цикл
доставки изменений, иметь разграничение по областям более качественного
описания, разработки, тестирования функционала.
Разрабатываемая система ориентирована на быстрое внедрение и
настройку, а также простоту использования. Для этого внедряются решения
по управлению процессами CRM на основании DSL (Domain specific language
based on Groovy, Kotlin), которые позволят, не используя программистов,
менять кредитную политику, различные скоринговые модели и
маркетинговые кампании без участия программистов. Интерфейс системы
интуитивно будет понятен и доступен для использования. По окончании
установки система начнет полноценно функционировать, остается лишь
привести ее в соответствие с локальными политиками и требованиями. CRM
разрабатывается с учетом возможности мониторинга за техническими и
логическими метриками, а также противодействию вредоносным атакам (DoS,
DDoS, Cookies stuffing и других) и поставляется совместно системой
мониторинга zabbix.
Перспективы своего развития компания «АйДиЭф Технолоджи» видит
в постоянном совершенствовании технологий, а также в расширении
ассортимента предлагаемых решений.
Учитывая стремительное развитие рынка систем автоматизации МФО и
его активный рост, компания «АйДиЭф Технолоджи» планирует большую
часть прибыли вкладывать в развитие компании: стимулирование процесса
усовершенствования собственных разработок, расширение штата
сотрудников, повышение их профессионального уровня, а также увеличение
уровня их заработной платы.
Планируемые к разработке компоненты позволят:
• Оформлять анкеты заемщиков. При оформлении анкеты
предусмотрены различные параметры, характеризующие заемщика,
разделенные на несколько функциональных блоков: основные параметры,
информация о работе и имуществе, информация о кредитах, личная

24
контактная информация и информация о контактных лицах, история
выданных займов по заемщику, история общения с должником, комментарии.
• Осуществлять проверку заемщика во внутренних и внешних
источниках. Финансовая, административная и хозяйственная информация
позволит осуществить проверку связей с другими клиентами компании,
проверку паспортных данных, проверку по локальным и территориальным
спискам (например, списку экстремистов и террористов), получать кредитные
отчеты от бюро кредитных историй (локальные и международные бюро
кредитной истории и информации).
• Оформлять договора, автоматизируя печатные формы и согласия.
• Автоматически рассчитывать суммы по договору, в том числе
проценты и пени по займу с учетом приостановок, реструктуризации и
частично внесенных сумм. Возможны различные варианты расчета.
• Контролировать денежные потоки - функционал по контролю за
возвратом займов, приема оплаты от платежных сервисов, установка плановой
оплаты должника.
• Осуществлять проверки службами экономической безопасности –
контроль за ходом проработки должника, подготовка дел для передачи в
сторонние коллекторские агентства или суды, контроль сумм к взысканию.
• Формировать аналитические отчеты по всем метрикам
организации с отображением динамики.
• Формировать отчетность для надзорных и контролирующих
органов - данные в автоматическом режиме, включая инструменты для
анализа и проверки данных.
• Передавать информацию заемщикам – данные в личном кабинете,
такие как статус договора, расчеты и ставки, печатные формы (договора и
согласия клиента и управление ими), история взаимоотношений заемщик –
финансовая компания.
Компанией «АйДиЭф Технолоджи» разрабатываются следующие
функциональные модули в рамках разработки программного обеспечения:
Модуль «Статистика»
Разработка общей статистики в реальном времени по заявкам и займам.
Агрегация данных по денежным потокам, в том числе выдачи, погашения,
NPL и предодобрение. Мониторинг статуса текущих балансов, в том числе
интегрированные данные платежных систем и банков.
Модуль «Заёмщики»

25
Разработка поиска и фильтрации по заёмщикам и сводной отчетности.
Агрегация детализированной информации (в виде карточек) по каждому
клиенту – личная информация, адреса и телефоны, история заявок, банковские
карты и счета, информация из внешних источников. Предоставление
возможности осуществления операции с заемщиками – ручные нотификации,
управление учетными данными, блокировка заемщика и изменение данных.

Рисунок 1. Модуль «Заёмщики».


Модуль «Займы»
Поиск и фильтрация по займам, сводная отчетность. Агрегирована
детализированная информация (в виде карточек) по каждому займу – статус
займа и его параметры, автоматический расчет рисков, информация из
сторонних финансовых и хозяйственных институтов (например, БКИ),
информация о погашениях, продлениях и реструктуризации. Разработка
модуля окончена.

26
Рисунок 2. Модуль «Займы».
Модуль «Платежи»
Процесс по управлению всеми денежными потоками организации –
проведение и контроль для внутренних платежей, внешних поступлений и
сводных кредитных отчетов. Разработаны печатные формы для

27
предоставления в контролирующие и надзорные органы. Разработка модуля
окончена.
Рисунок 3. Модуль «Платежи».
Модуль «Должники»
Разработка процесса по управлению взаимоотношениями с должниками
организации. Поиск, фильтрация и сводная отчетность, автоматизация
рабочего места коллектора с доступом ко всем данным заемщика,
предложениями по работе с ним (по правилам, определяемым для каждой
конкретной организации отдельно). Хранение и доступ полной истории
коммуникаций с должниками, управление каналами связи (SMS, почта,

автоинформатор и прочее).
Рисунок 4. Модуль «Должники».
Модуль «Коллекторы»

28
Разработка функционала по управлению доступом внутренних и
внешних коллекторов и коллекторских агентств к системе. Настройки
выгрузки данных (например, реестры) и правил работы.

Рисунок 5. Модуль «Коллекторы».

Модуль «Партнеры»
Разработка функционала по управлению онлайн и офлайн партнерами
организации. Задаются различные модели коммуникации и расчета
вознаграждения. Создаются возможности построения партнерских сетей.

Рисунок 6. Модуль «Партнеры».


Модуль «Отчеты»
Планируется разрабатываться индивидуально под каждую организацию
и будет содержать набор отчетов и печатных форм, запрашиваемых
локальными подразделениями организации и локальными или
международными контролирующими и надзорными органами.
29
Модуль «Верификация»
Разработка автоматизированного рабочего места верификатора с
доступом ко всем данным потенциального заемщика, предложениями по
работе с его заявкой (по правилам, определяемым для каждой конкретной
организации отдельно). Хранение и доступ к полной истории коммуникаций с
потенциальным заемщиком, управление каналами связи (SMS, почта,
телефонные переговоры и прочее).
Модуль «Черные списки»
Разработка локального хранилища негативной информации по
потенциальным и действующим заемщикам, набор автоматических правил
принятия решения и ручной сверки совпадающей информации (Data
matching).
Модуль «Нотификации»
Разработка функционала по управлению всеми каналами коммуникации
с заемщиками, такими так СМС, телефония и электронная почта. Сбор
статистики и онлайн мониторинг внешних шлюзов. Набор стандартных
отчетов и метрик для каждого из каналов коммуникации.
Модуль «Мониторинг»
Разработка информационного блока для дирекций безопасности
позволяющий искать совпадения по разным полям (сущностям) для
локализации и пресечения фактов мошенничества.
Модуль «Бонусы»
Разработка функционала управления всеми промо-акциями
организации. Будет реализована возможность создания промо-кампаний,
политики скидок и начисления бонусов заемщикам при достижении
определенных результатов или наступлению определенных событий.

30
Рисунок 7. Модуль «Бонусы».
2.2.2. Кадровый ресурс
На 31.12.2020 списочная численность ООО «АйДиЭф Технолоджи»
составляет 16 человек. Численность IT специалистов составляет 12
человек, численность административного персонала - 4 человека.
Руководитель ООО «АйДиЭф Технолоджи» Комаров Александр
Сергеевич имеет опыт в IT более 10 лет, руководил различными проектами,
связанными с разработкой корпоративных программных продуктов и
финансовых систем, обладает достаточным опытом в создании конечных
программных продуктов и их продвижении на рынках Республики
Беларусь, Российской Федерации и Европы. Комаров Александр окончил
факультет прикладной математики и информатики Белорусского
государственного университета по специальности «Компьютерная
безопасность». В дальнейшем руководитель организации «АйДиЭф
Технолоджи» занимал различные позиции в компании Itransition, от
разработчика до руководителя команды разработки в отделах разработки
финансовых систем и систем электронной коммерции, после руководил
одним из направлений разработки финансовых систем в компании HiEnd
Systems.
Ключевыми сотрудниками компании являются:
Игорь Котов - Lead Java разработчик, окончил БГУИР, факультет
компьютерных систем и сетей по специальности "Информатика", работал
в ООО "СКЭНД", опыт работы в IT 5 лет;
Дмитрий Костяев - Java разработчик, окончил БГУ, факультет
ФПМИ, работал в Еpam Systems, Qulix, опыт работы в IT 3 года;
Иван Молчанов – Lead QA, окончил БГУ, факультет ИБМТ, работал
в МТБанке и Геолонсофте, опыт работы 4 года инженером-программистом
и специалистом по тестированию ПО;
Павел Гончаров – Lead BA, окончил БГУ, факультет ИБМТ, по
специальности "Бизнес-администрирование", работал в XBSoftwareSaaS
на продуктах GanttPRO.com и KUKU.io. Опыт работы в IT 4 года;
Виталий Власенко – Lead DevOps окончил Минский
государственный высший радиотехнический колледж со специализацией
"Радиоэлектроника", работал ОДО "Профигруп", ИПУП "ИССОФТ
СОЛЮШЕНЗ", ЧП «Софтвэр Секьюрити Системс», опыт работы в IT 7
лет;
Сидорова Марина – бизнес-аналитик, окончила ГУ ВПО
"Белорусско-Российский университет", работала в ОАО "АСБ
Беларусбанк", ОАО "Хоум Кредит Банк" и ООО "Альфа-Банк", общий

31
стаж 7 лет на должностях ведущего, главного специалиста сопровождения
ПО управления информационных технологий, главного специалиста и
начальника отдела сопровождения ПО управления развития и
сопровождения ПО, главного специалиста управления развития расчетных
продуктов и дистанционных каналов обслуживания.
Так как АйДиЭф Технолоджи планирует разрабатывать ПО для всей
группы компаний ID Finance. Штат сотрудников будет расширяться. В
2022 году мы планируем штат около 70 сотрудников, в 2023 – 100
сотрудников, в 2024 – 135 сотрудников.
2.2.3. Используемые информационные технологии
Компания «АйДиЭф Технолоджи» использует современный стек
технологий при разработке программных продуктов «Solva 2.0»,
«MoneyMan 2.0», «Ammopay 2.0», «Kresko 2.0».
1. Бэкэнд разработка базируется на:
- JAVA 7/8 с использованием универсального фреймворка Spring
Framework с открытым исходным кодом для Java-платформ. Набор
спецификаций JEE - EJB, JPA, JAX-RS, Glassfish;
- Инфраструктурные решения - Docker, ELK, Netflix stack (Swarm,
Consul, Vault, Hystrix, Kibana, Grafana, Prometheus, Haproxy);
- Собственный Custom framework для микросервисов на основе
Spring и Jetty;
- RDBMS – MySql, NoSql - Mongo, GridFS, Redis, ElasticSearch;
- Истории событий и хранении данных - Axon Framework;
- Business DSLs - Groovy and Kotlin;
- Платформе системы обмена сообщениями – RabbitMQ;
- Аналитике данных (Big Data) – Spark;
- JEE - EJB, JPA, JAX-RS, Glassfish;
- ORM - Hibernate, Jooq;
- Модульном и автоматизированном тестировании - Spock, JUnit,
Mockito, RestAssured. Selenium;
- Системе автоматической сборки - Gradle, Maven.
2. Фронтенд разработка базируется на:
- Компонентной архитектуре AngularJS;
- Системе автоматической сборки - Webpack. Single page application.
- Управлении публичными ресурсами – Wordpress CMS.
Внедрение вышеуказанных ИТ-технологий помогает
систематизировать информацию, документы, упрощает сам рабочий
процесс.

32
2.2.4. Текущие и планируемые объемы выпуска товаров в
натуральном и денежном выражении.
№ Наименование показателя Ед. изм. 2020 2021 2022 2023
1 2 3 4 5 6 7
ОБЪЕМ ПРОИЗВОДСТВА И РЕАЛИЗАЦИИ
Выручка от реализации товаров
(работ, услуг, имущественных
1 прав на объекты тыс. руб. 374 6 000 8980 12 600
интеллектуальной
собственности) на экспорт
Темпы роста в % к предыдущему
2 - 1 504 150 140
году %
ЭФФЕКТИВНОСТЬ РАБОТЫ
Затраты на производство и
реализацию товаров (работ,
3 услуг, имущественных прав на тыс. руб. 277 5004 7412 10343
объекты интеллектуальной
собственности)
Прибыль от реализации товаров
(работ, услуг, имущественных
4 прав на объекты тыс. руб. 96 996 1 568 2 257
интеллектуальной
собственности)
Рентабельность реализации
товаров (работ, услуг,
5 имущественных прав на объекты % 35 20 21 22
интеллектуальной
собственности)
Годовая производительность
6 труда (выработка на одного тыс. руб. 29 86 90 93
работника)
СОЦИАЛЬНОЕ РАЗВИТИЕ
Количество вновь созданных
7 чел. 16 57 30 35
рабочих мест
Среднесписочная численность
8 чел. 13 70 100 135
работников
Средняя заработная плата
9 тыс. руб. 3,8 4,2 4,6 5,1
работников
10 В % к предыдущему году % - 110 110 111
33
Таблица 2. Текущие и планируемые объемы выпуска товаров в
натуральном и денежном выражении. Источник: данные компании.
На основании вышеизложенного можно сделать вывод, что
производственная эффективность растет очень стремительно. Рост выручки
уже составляет 1504% по сравнению с прошлым годом, а в 2023 году рост
выручки планируется на 3268% по сравнению с 2020-ым годом. Прибыль от
реализации товаров уже выросла на 937%. Но также стоит заметить, что такой
рост прибыли не может быть при текущем штате сотрудников, поэтому его
планируется расширить почти в 2 раза. Еще хочется обратить внимание на то,
что в будущем компания планирует позволить себе увеличение средней
заработной платы работников, что дополнительно будет стимулировать
сотрудников.
2.2.5. Инвестиционный план. Объекты инвестиций.

Наименование показателя Ед. изм. 2021 2022 2023
п/п

1. Основные средства
тыс. руб. 160 80 80
в том числе:

1.1. вычислительная оргтехника; тыс. руб. 140 60 60

1.2. иное оборудование. тыс. руб. 20 20 20

2. Нематериальные активы
тыс. руб. 40 60 80
в том числе:

2.1. компьютерные программы. тыс. руб. 40 60 80

Таблица 3. Инвестиционный план. Источник: данные компании.


Увеличение инвестиций на технику и компьютерные программы
напрямую связано с планируемым расширением штата сотрудников, а это
значит, что необходимо вкладывать средства в покупку дополнительных
компьютеров, серверов, сетевого оборудования для поддержания стабильного
рабочего процесса.
2.2.6. Выявленные проблемы в реализации CRM системы
Основной заказчик – российская микрофинансовая организация. Вид
деятельности заказчика – выдача PDL и IL микрозаймов. В данный момент
34
рассмотрением заявок на кредит занимается команда верификаторов,
которые оценивают платежеспособность клиентов.
В ходе прохождения преддипломной практики было выявлено
несколько проблем, связанных с работой, текущей CRM системы, ввиду
отсутствия автоматизации процесса выдачи кредита, а именно:
1. Ежемесячные расходы на зарплату верификаторов
составляют примерно 10 тысяч долларов.
2. Скорость принятия решения о выдаче займа в среднем
составляет 72 часа
Таким образом была предложена идея во автоматизации процесса
выдачи кредита. В ходе дискуссий с командой разработки и командой бизнес
аналитиков было принято решение начать разработку нового модуля в
существующей CRM-системе. Модуль «Скоринг» поможет практически
полностью автоматизировать процесс принятия решения о выдаче кредита,
что поможет добиться следующих результатов:
1. Выдача кредита в большинстве случаев будет происходить
за 5 минут.
2. Большую часть штата специалистов-верификаторов можно
будет сократить
3. В перспективе появится больше потенциальных клиентов
ввиду запуска рекламы «Кредит за 5 минут»
Таким образом, основной задачей для решения в дипломной работе
будет написание спецификации требований к программному обеспечению
(Техническое задание) для последующей разработки модуля «Скоринг».
Исходя из вышеизложенного можно сделать вывод, что используемые
IT-технологии существенно помогают систематизировать информацию,
документы и упрощают сам рабочий процесс. Также данные технологии
позволяют разрабатывать сложные программные продукты такие как,
например модуль «Скоринг». Планируемые объемы выпуска продукции
довольно оптимистичные. Таким образом можно сказать о хорошей тенденции
развития компании «АйДиЭф Технолоджи». Однако не смотря на данный
оптимизм в работе системы имеется один существенный недостаток – это
отсутствие автоматизации в процессе принятия решения о выдаче кредита.
Данная проблема и стала темой дипломной работы. И в ходе её выполнения
предложено решение. Результатом станет готовое техническое задание для
модуля «Скоринг».

35
ГЛАВА 3. РАЗРАБОТКА ПРОТОТИПА СКОРИНГОВОЙ
СИСТЕМЫ
3.1. Анализ объекта автоматизации
Заказчик – российская микрофинансовая организация. Основной вид
деятельности – выдача PDL и IL микрозаймов. В данный момент
рассмотрением заявок на кредит занимается команда верификаторов, которые
оценивают платежеспособность клиентов.
Цель проекта – разработка скоринговой системы, которая сможет
обрабатывать заявки клиентов анализируя данные, полученные из БКИ,
выбранную сумму/срок займа, номера телефонов, указанные клиентом, IP
адреса и прочее.
Подход к бизнес-анализу - гибкий
Работа ведется с использованием гибкой методологии разработки
программного обеспечения Scrum
Артефакты хранятся на онлайн сервисе google drive
Soft : draw io, Rational Rose
Тип ПО: заказное, веб сервис, возможно мобильностей приложение,
Скоринг - специализированное ПО
Модель бизнес-процесса представлена на рисунке 1.1. Моделирование
бизнес-процесса реализовано с помощью нотации BPMN, так как она
максимально подходит для описания сложных семантических конструкций,
использует базовый набор интуитивно понятных элементов.

Рисунок 1.1 – Автоматизированный процесс принятие решения по


заявке.
Для разработки данной системы разрабатывается техническое задания с
использованием SRS ISO/IEC/ IEEE 29148-2011 Systems and software
engineering —Life cycle processes — Requirements engineering. Техническое

36
задание «Автоматизация процесса выдачи кредитов» представлено в
приложении А.
Разработанные в рамках данной главы модель бизнес-процесса и
техническое задание в последующем будут использованы для создания
диаграммы вариантов использования и логического проектирования в целом.
3.2. Построение модели вариантов использования
В данной главе описываются требования к системе, ее функции и
варианты использования на основе разработанного ранее технического
задания, а также разрабатываются глоссарий для проекта, документация
основных вариантов использования.
3.2.1 Требования к системе
Выявление функциональных и нефункциональных требований к
системе необходимо для того, чтобы правильно сформировать
концептуальное описание системы.
Основные функциональные требования к системе:
• Функция проверки IP адреса, с которого была отправлена заявка
• Функция проверки карты
• Функция запроса в МВД
• Функция запроса в БКИ
• Функция оценивания параметров по заданным критериям
Нефункциональные требования к системе
• Доступность-1. Модуль Изи мани должен быть доступен
пользователям, находящимся на территории РФ.
• Надежность-1. При возникновении проблем с соединением,
Модуль не должен позволять посетителям отправлять одну и ту же
заявку более одного раза.
• Надежность-2. Должен быть обеспечен контроль целостности
данных на уровне СУБД.
3.2.2 Глоссарий проекта
Для проекта был разработан специализированный глоссарий
Термины
1. Бюро кредитных историй (БКИ) — компания, оказывающая в
соответствии с законодательством услуги по формированию, обработке и
хранению кредитных историй, а также по предоставлению кредитных отчетов.
2. Верификатор - сотрудник заказчика, принимающий решение по заявке.
3. Заемщик - физическое лицо, клиент заказчика, нуждающийся в
денежных средствах.
4. Заемные средства - денежные средства, выдаваемые заказчиком
физическому лицу.
37
5. Заявка - заявка на кредит.
6. Кредитная история - это информация об исполнении субъектом
кредитной истории, то есть об исполнении заемщиком принятых на себя
обязательств по кредитным договорам.
7. Скоринг - система оценивания потенциального заемщика на основе его
кредитной истории.

Сокращения
1. БА - бизнес аналитик.
2. БКИ - бюро кредитных историй.
3. МВД - министерство внутренних дел.
4. РФ - Российская Федерация.
5. PDL - кредит со сроком исполнения обязательств до 30 дней.
6. IL - кредит со сроком исполнения обязательств более 30 дней.
3.2.3 Диаграмма вариантов использования
Действующими лицами в информационной системе являются клиент,
Скоринг и Верификатор.
Исходя из информации, представленной в техническом задании, были
выявлены следующие варианты использования информационной системы:
• Регистрация в системе
• Заполнение анкеты на кредит
• Принятие решение по заявке на кредит

На рисунке 2.1 и 2.2 представлены диаграммы вариантов использования


данной информационной системы.

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


38
Рисунок 2.2 – Диаграмма вариантов использования 2

Теперь, когда выявлены функциональные и нефункциональные


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

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

№ Требования к Способ реализации Информационные


составной части связи
1. Должна быть При нажатии на Через форму
возможность кнопку “получить открывается для
зарегистрировать деньги” открывается заполнения данных в
личный кабинет форма для ИС
пользователя заполнения
персональных
данных.
2. Пользователь должен Ползунок – «Сумма» Данные изменяются
иметь возможность Ползунок – «Срок» непосредственно после
отправить заявку Кнопка – «Отправить взаимодействия с
выбрав сумму и срок заявку» окном ИС
кредита

40
3.4 Проектирование классов
В данной главе выделяются объекты системы, на основе которых
описываются модельные классы и связи между ними. Итогом этой главы
является разработка диаграммы проектных классов.
3.4.1 Диаграмма концептуальных классов
Диаграмма модельных, или как еще называют, концептуальных классов,
разрабатывается для того, чтобы графически представить концепцию работы
всей системы.
В ходе описания системы были выявлены следующие концептуальные
классы, которые представлены на рисунке 3.1

Рисунок 3.1 – Диаграмма концептуальных классов

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


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

41
Рисунок 3.2 – Диаграмма состояний класса «Credit»

42
3.5 Проектирование схемы данных
В данной главе описывается проектирование схемы данных, а именно,
разработка структуры основной базы данных информационной системы –
клиентская база данных. Именно с ней взаимодействуют большинство классов
программы.
Клиентская база данных хранит в себе информацию о данных кредитов
(Credit), данные верификатора (Verifier) и данные клиента (Registration).
Соответственно, разрабатывается три таблицы. Каждая из таблиц включает в
себя определенные атрибуты, описанные в таблице.
Атрибуты таблиц базы данных:
Наименование
таблицы Атрибут Значение атрибута Тип атрибута

Идентификационный
CreditID (ПК) номер кредита int

CreditDate Дата подачи заявки date


на кредит
Credit CreditAmount Сумма кредита int
Дата окончания
ExpDate договора date

VerifierID (ВК) Идентификационный int


номер работника
Идентификационный int
Reg_ID (ВК)
номер клиента
Наименование
таблицы Атрибут Значение атрибута Тип атрибута

Идентификационный
VerifierID (ПК) номер работника int

worker_firstName Имя работника varchar(50)


Фамилия работника
Verifier worker_lastName varchar(50)

worker_e-mail e-mail работника varchar(25)


Уровень работника
worker_position varchar(50)

Идентификационный
Reg_ID (ПК) номер клиента int
Registration
FIO ФИО клиента varchar(25)

43
Birthday Дата рождения date
клиента
Gender Идентификационный varchar(10)
номер работника
Социальный статус varchar(10)
Status клиента

Атрибуты таблиц имеют следующие типы данных: натуральный (int),


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

Программа Rational Rose позволяет сгенерировать файл, который хранит


в себе код SQL создания всех таблиц, ключей и других элементов, созданных
в рамках диаграммы структуры базы данных.
Сгенерированный код таблиц представлен ниже на примере таблицы
работника. Код остальных таблиц выглядит аналогично.
CREATE TABLE [Verifier]
(
[VerifierID] int NOT NULL,
[worker_firstName] varchar(50) NULL,
[worker_lastName] varchar(50) NULL,
[worker_e-mail] varchar(25) NULL,
[worker_mobilePhone] varchar(20) NULL,
[worker_position] varchar(50) NULL
)
G
O
Создание всех таблиц начинается с вызова CREATE TABLE, а
заканчивается вызовом GO. Параметр NOT NULL означает, что значение не
может быть пустым, соответственно NULL допускает пустое значение ячеек
столбца.

44
Сгенерированный код первичных ключей представлен ниже на примере
первичного ключа данных Кредита. Код остальных первичных ключей
выглядит аналогично.
ALTER TABLE [Credit]
ADD CONSTRAINT [PK_Credit]
PRIMARY KEY CLUSTERED ([CreditID] ASC)
GO
Создание всех первичных ключей начинается с вызова ALTER TABLE
[(название таблицы] ADD CONSTRAINT [(название первичного ключа]
PRIMARY KEY CLUSTERED ([(столбец первичного ключа)]), а
заканчивается вызовом GO. Параметр ASC означает сортировку по алфавиту.
Сгенерированный код внешних ключей представлен ниже на примере
внешнего ключа таблицы Кредит. Код остальных внешних ключей выглядит
аналогично.
ALTER TABLE [Credit] ADD CONSTRAINT
[FK_ Credit _Verifier]
FOREIGN KEY ([VerifierID]) REFERENCES [Verifier]
([VerifierID]) ON DELETE No Action ON UPDATE No Action
GO
Создание всех внешних ключей начинается с вызова ALTER TABLE
[(название таблицы] ADD CONSTRAINT [(название первичного ключа]
FOREIGN KEY ([(первичный ключ таблицы, с которой необходимо связать
данную таблицу)]), REFERENCES [(название таблицы, с которой необходимо
связать данную таблицу)] ON DELETE No Action ON UPDATE No Action и
заканчивается вызовом GO.

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

46
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1. Грекул В. Проектирование информационных систем / В. Грекул, Г.
Денищенко, Н. Коровкина – Москва: Издательство «Бином.
Лаборатория знаний» 2008. – 304 с.
2. Хританков А. Проектирование на UML / А. Хританков, В. Полежаев, А.
Андрианов – Екатеринбург.: Издательские решения, 2017. – 240 с.
3. Ньютон, Р. Управление проектами от А до Я / Р. Ньютон – Москва:
Альпина Паблишер, 2017. – 182 с.
4. Назаров С. Архитектура и проектирование программных систем /
Станислав Назаров – Москва: Инфра-М, 2016. – 376 с.
5. Гвоздева Т. Проектирование информационных систем /Т. Гвоздева, Б.
Баллод – Москва: Феникс, 2016. – 512 с.
6. Исаев Г. Проектирование информационных систем /Георгий Исаев –
Москва: Омега-Л, 2013. – 424 с.
7. Семакин И. Основы программирования и баз данных. Учебник для
студентов среднего профессионального образования – Москва:
Академия,
8. 2014. – 224 с.

47
ПРИЛОЖЕНИЕ А

Спецификация требований к ПО (техническое задание)


для

Изи Мани

Версия 1.6

17.02.2020

Составитель:

Гербалы А.В.

48
Лист распространения

Организация Ф.И.О. Должность Для информации /


согласования

История версий

Имя Дата Причина изменения Версия

Александр 02.10.2020 Создание документа 1.0

Александр 05.10.2020 Добавление информации в п.п. 3-4 1.1

Александр 07.10.2020 Дополнение п.п. 1-4 1.2

Александр 12.10.2020 Добавление 2.6, редактирование 1.3


документа

Александр 13.10.2020 Редактирование п.п.1, 2. 1.4

Александр 14.10.2020 Добавление п.п. 2.4, 2.7, 4.1.1, сценария 1.5


использования; форматирование
документа, редактирование всего
документа

49
Александр 17.10.2020 Редактирование всего документа, 1.6
дополнение 3.1., добавление приложения
для прототипов

50
1. Введение
1.1. Назначение

Эта спецификация требований к программному обеспечению (далее ПО)


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

Указанные в документе требования имеют различные приоритеты, выпуск


готовых версий ПО будет осуществляться в два этапа.

1.2. Объем проекта

Заказчик – российская микрофинансовая организация. Основной вид


деятельности – выдача PDL и IL микрозаймов. В данный момент компания
занимает лидирующую позицию на рынке микрофинансовых услуг. Штат
сотрудников превышает 200 человек. Инвестиции компании превышают 8
миллиардов долларов.
Основной потребностью компании является оптимизация процесса
рассмотрения входящих заявок на кредит для ускорения процесса их
обработки. Компании также необходимо повышение качества идентификации
личности заемщика. Ввиду высокой нагрузки на специалистов необходима
автоматизация процесса обработки входящих заявок.
На данный момент организация использует уже существующую Систему Изи
мани.
В Системе используются базы данных MySQL, Mongo, GridFS, DB2.
В качестве платформы разработки используются языки программирования
J2EE, Angular, Php.
Модуль Изи мани позволит автоматизировать процесс обработки и принятия
решения по заявкам клиентов на заём, анализируя данные полученные из БКИ,
выбранной суммы/срока займа, IP адреса и прочие.
1.3. Ссылки

1. Документ общего видения и описание решения в.1.7

https://docs.google.com/document/d/1A_3xdncDvPltCjUN1hewFoIYrscWX_ejQ4
PvA8yU2PA/edit?usp=sharing .
51
2. Проектная документация основной системы “Система Изи мани”.

2. Общее описание
2.1. Общий взгляд на продукт

Модуль Easy money далее Модуль разрабатывается для российской


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

2.2. Классы и характеристики пользователей

Класс Характеристика пользователей


пользователей

Заёмщик Заёмщик - это конечный клиент компании заказчика,


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

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


клиентом при оформлении заявки. Администратор - сотрудник
компании заказчика, у которого есть полномочия вносить
корректировки в заявку (только в случае обращения заёмщика).

Верификатор Верификатор - сотрудник компании заказчика, отвечающий за


решение по заявке на кредит, в случае непринятия точного
решения скорингом.

Матрица ролей и прав доступа

52
2.3. Операционная среда

Операционная среда аналогична операционной среде используемой в


Системе.

Подробное описание в проектной документации Система Изи мани [2].

2.4. Ограничение дизайна и реализации

Ограничения дизайна подробно описаны в проектной документации Системы


[2].

ОДР-1. Необходимо вести разработку Модуля на платформе Системы (языки


программирования J2EE, Angular, Php).

ОДР-2. Модуль должен использовать текущие версии базы данных Системы


(MySQL, Mongo, GridFS, DB2).

2.5. Документация для пользователей

ДП-1. Предоставляется пользователям в электронном виде вместе с


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

ДП-2. Информация и документация сайта компании, указанные на сайте


должны быть обновлены.

2.6. Предположения и зависимости

1. Предполагается, что заёмщик на шаге регистрации может


заполнить паспортные данные неправильно/с ошибками.

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

3. Предполагается, что в один момент времени на ресурсе могут


находиться большее количество посетителей, чем установлено в ТП-3
пункта 4.3.1.

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


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

54
2.7. Пользовательские требования

Epic 1. Управление заявками

ID Как... … хочет ... ...чтобы Условия Приоритет

US Потенциа уменьшения быстрее - доступ к web- 4


01 льный влияния получить ресурсу Системы;
заемщик человеческого решение по
фактора в заявке - потенциальный
принятии решения заемщик должен
по заявке на быть
выдачу займа зарегистрирован в
Системе;
- потенциальный
заемщик должен
быть залогинен в
Системе;

US Верифика автоматическое увеличить - должен быть 4


02 тор оценивание заявок скорость выдачи заведен и
на заём решения по залогинен в
заявке Системе;

US Верифика автоматического минимизировать - должен быть 4


03 тор принятия решения человеческий заведен и
по заявкам фактор в залогинен в
принятии Системе;
решений,
уменьшить
нагрузку на
верификаторов

55
3. Функции системы
3.1. Сценарий использования

СИ-01.01.01 Управление заявками

Актор: Потенциальный клиент.

Триггер: Потенциальный заемщик отправил заявку.

Условия входа:
PRE-1. Потенциальный заемщик зарегистрирован в Системе.
PRE-2. Потенциальный заемщик залогинен в Системе.
PRE-3. Верификатор залогинен в Системе.

Условия выхода:
POST-1. Заявка на заём одобрена.

Главный поток:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Модуль сверяет данные карты с данными из заявки.

4. Система проверяет данные потенциального заёмщика открытых


сервисах МВД для валидации паспорта.

5. Система автоматически проверяет кредитную историю в БКИ.

6. Модуль оценивает максимальную просрочку из БКИ.

7. Модуль оценивает параметр “Заработная плата”.

8. Модуль оценивает параметр “Наличие несовершеннолетних


детей”.

9. Модуль оценивает параметр “Пол”.

10. Модуль оценивает параметр “Общая долговая нагрузка”

11. Модуль оценивает параметр “Возраст”.

12. Модуль оценивает параметр “Семейное положение”.


56
13. Модуль оценивает параметр “Наличие образования”.

14. Модуль оценивает параметр “Недвижимость”.

15. Модуль рассчитывает итоговую оценку.

16. Модуль анализирует результат оценивания.

17. Модуль одобряет заявку.

18. Система отображает заёмщику экран успешной выдачи


займа.

19. Система отправляет на электронную почту уведомление.


Альтернативный поток 2A:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Проверка Модулем не пройдена.

4. Перенаправление Модулем заявки верификатору.

5. Потенциальному заёмщику Система отображает экран


перенаправки специалисту.
Альтернативный поток 3A:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Модуль сверяет данные карты с данными из заявки.

4. Проверка Модулем не пройдена.

5. Потенциальному заёмщику Система отображает экран отказа в


займе.
Альтернативный поток 4А:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Модуль сверяет данные карты с данными из заявки.

4. Система проверяет данные потенциального заёмщика открытых


сервисах МВД для валидации паспорта.
57
5. Проверка Системой не пройдена.

6. Потенциальному заёмщику Система отображает экран отказа в


займе.
Альтернативный поток 5A:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Модуль сверяет данные карты с данными из заявки.

4. Система проверяет данные потенциального заёмщика открытых


сервисах МВД для валидации паспорта.

5. Система автоматически проверяет кредитную историю в БКИ.

6. Система определяет, что кредитная история чиста.

7. Перенаправление Модулем заявки верификатору.

8. Потенциальному заёмщику Система отображает экран


перенаправки специалисту.
Альтернативный поток 5Б:

1. Потенциальный заемщик отправляет заявку на заём.

2. Модуль сверяет IP адрес.

3. Модуль сверяет данные карты с данными из заявки.

4. Система проверяет данные потенциального заёмщика открытых


сервисах МВД для валидации паспорта.

5. Система автоматически проверяет кредитную историю в БКИ.

6. Система определяет, что просрочка составляет более 180 дней.

7. Заёмщику Система отображает экран отказа в займе.

8. Система отправляет на электронную почту уведомление.


Альтернативный поток 17А:
17. Модуль не одобряет заявку.
18. Заёмщику Система отображает экран отказа в займе.
19. Система отправляет на электронную почту уведомление.
Альтернативный поток 17Б:

58
17. Модуль перенаправляет заявку верификатору.
18. Система отображает заёмщику экран перенаправления заявления
специалисту.
19. Система отправляет на электронную почту уведомление.

3.2. Функции

3.2.1. Функция проверки IP адреса, с которого была отправлена заявка

При оформлении заявок клиент чаще использует то же устройство, что и для


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

В случае расхождения Модуль должен перенаправлять заявку на


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

Приоритет - высокий (high).

3.2.2. Функция проверки карты

После проверки IP адресов (п.3.1.) Модуль должен сравнить сравнить имя и


фамилию владельца карты с паспортными данными потенциального
заёмщика.

Если данные не совпадают, Модуль должен автоматически аннулировать


данную заявку.

Если данные совпадают - переход к п.3.3.

Приоритет - высокий (high).

3.2.3. Функция запроса в МВД

После проверки карты (п.3.2.) данные потенциального заемщика Системой


автоматически проверяются на открытых сервисах МВД для валидации
паспорта. Необходимо использовать реализованный в Системе механизм
запроса данных из МВД.

Приоритет - высокий (high).

59
3.2.4. Функция запроса в БКИ

После валидации паспортных данных потенциального заемщика (п.3.3.)


Системой автоматически проверяется кредитная история в БКИ. Необходимо
использовать реализованный в Системе механизм запроса данных из БКИ.

Результаты проверки кредитной истории используются в функции


оценивания.

Приоритет - высокий (high).

3.2.5. Функция оценивания параметров по заданным критериям

3.2.5.1. Оценивание максимального срока просрочки из БКИ

После получения данных из БКИ Модуль должен определить максимальный


срок просрочки, которую заёмщик когда-либо допускал.

Модуль оценивания должен складываться следующим образом:

- если у заёмщика нет кредитной истории, Модуль должен


перенаправлять заявку на ручное рассмотрение к верификаторам
(п.3.2.8.);

- если максимальная просрочка составляет 1-30 дней, Модуль дает


оценку в 90 баллов;

- если максимальная просрочка составляет 30-60 дней, Модуль даёт


оценку в 70 баллов;

- если максимальная просрочка составляет 60-180 дней, Модуль


даёт оценку в 30 баллов;

- если максимальная просрочка составляет 180+ дней, Модуль


автоматически принимает решение отказать в выдаче займа.

Приоритет - критический (critical).

3.2.5.2. Оценивание параметра “Заработная плата”

При регистрации заёмщик указывает свою месячную заработную плату.

Модуль оценивания должен складываться следующим образом:

Берется коэффициент z=((ЗП/ 30дней) - (СуммКред/СрокКред)) / (ЗП/30дней)


* 100%, где

60
ЗП - заработная плата, СуммКред - сумма кредита, СрокКред - срок кредита в
днях.

- если коэффициент z составляет 50%+, Модуль даёт оценку 10


баллов;

- если коэффициент z составляет 30-40%, Модуль даёт оценку 40


баллов;

- если коэффициент z составляет 20-30%, Модуль даёт оценку 60


баллов;

- если коэффициент z составляет менее 20%, Модуль даёт оценку


80 баллов.

Приоритет - критический (critical).

3.2.5.3. Оценивание параметра “Наличие несовершеннолетних детей”

При регистрации заёмщик указывает наличие у себя несовершеннолетних


детей.

Модуль оценивания должен складываться следующим образом:

- если “Да”, Модуль даёт оценку 20 баллов;

- если “Нет”, Модуль даёт оценку 40 баллов.

Приоритет - критический (critical).

3.2.5.4. Оценивание параметра “Пол”

При регистрации заёмщик указывает свой пол.

Модуль оценивания должен складываться следующим образом:

- если пол мужской, Модуль даёт оценку 20 баллов;

- если пол женский, Модуль даёт оценку 40 баллов.

Приоритет - критический (critical).

3.2.5.5. Оценивание параметра “Общая долговая нагрузка”

После получения данных из БКИ Модуль должен оценить общую долговую


нагрузку заёмщика, что должно равняться сумме задолженности по
ежемесячным платежам по всем активным кредитам.

61
Модуль оценивания должен складываться следующим образом:

Берется коэффициент х = (ЗП-ОДН)/ЗП,

где ЗП - заработная плата, ОДН - общая долговая нагрузка.

- если коэффициент х составляет 50%+, Модуль даёт оценку 10


баллов;

- если коэффициент х составляет 30-40%, Модуль даёт оценку 40


баллов;

- если коэффициент х составляет 20-30%, Модуль даёт оценку 60


баллов;

- если коэффициент х составляет менее 20%, Модуль даёт оценку


80 баллов.

Приоритет - критический (critical).

3.2.5.6. Оценивание параметра “Возраст”

При регистрации заёмщик указывает свою дату рождение. Модуль, опираясь


на дату рождения, должен определить возраст заёмщика.

Модуль оценивания должен складываться следующим образом:

- если возраст составляет 18-25 лет или 60 и более, Модуль даёт 10


баллов;

- если возраст составляет 25-35 лет, Модуль даёт 40 баллов;

- если возраст составляет 35- 45 лет, Модуль даёт 80 баллов;

- если возраст составляет 45-60 лет, Модуль даёт 60 баллов.

Приоритет - критический (critical).

3.2.5.7. Оценивание параметра “Семейное положение”

При регистрации заёмщик указывает своё семейное положение.

Модуль оценивания должен складываться следующим образом:

- если женат/замужем, Модуль даёт 80 баллов;

- если холост, Модуль даёт 20 баллов.

62
Приоритет - критический (critical).

3.2.5.8. Оценивание параметра “Наличие образования”

При регистрации заёмщик указывает наличие образования.

Модуль оценивания должен складываться следующим образом:

- если “Высшее”, Модуль даёт 100 баллов;

- если “Средне-специальное”, Модуль даёт 60 баллов;

- если “Базовое”, Модуль даёт 20 баллов .

Приоритет - критический (critical).

3.2.5.9. Оценивание параметра “Недвижимость”

При регистрации заёмщик указывает наличие недвижимости.

Модуль оценивания должен складываться следующим образом:

- если имеется собственное жильё, Модуль даёт 100 баллов;

- если заёмщик арендует жильё, Модуль даёт 60 баллов;

- если заёмщик платит ипотеку за квартиру, Модуль даёт 40 баллов.

Приоритет - критический (critical).

3.2.6. Функция расчета итоговой оценки

Итоговая оценка должна рассчитываться Модулем по следующей формуле:

S=(0,25*балл параметра 3.4.1) + (0,1*балл параметра 3.4.2) + (0,1*балл


параметра 3.4.3)+ (0,1*балл параметра 3.4.4) + (0,15*балл параметра 3.4.5) +
(0,05*балл параметра 3.4.6) + (0,05*балл параметра 3.4.7) + (0,05*балл
параметра 3.4.8) + (0,05*балл параметра 3.4.9)

Приоритет - критический (critical).

3.2.7. Функция анализа результата оценивания

3.2.7.1. Функция автоматического одобрения займа

Если по результатам оценка более 60, то происходит автоматическое


одобрение заявки Модулем.

63
Клиенту Система отображает экран одобрения заявки на заём. На
электронную почту приходит уведомление. Использовать реализованный в
Системе механизм уведомления заемщика.

Приоритет - критический (critical).

3.2.7.2. Функция автоматического отказа

Если по результатам оценка менее 30, то Модуль автоматически дает отказ в


выдаче займа.

Клиенту Система отображает экран отказа по заявке. На электронную почту


приходит уведомление. Использовать реализованный в Системе механизм
уведомления заемщика.

Приоритет - критический (critical).

3.2.7.3. Недостаточный балл для автоматических действий системы

При недостаточном балле (от 30 до 60) для автоматических действий Модуля


переход к п.3.7.

Клиенту Система отображает экран перенаправления заявки специалисту и


отправляет уведомление на электронную почту. Использовать реализованный
в Системе механизм автоматического оповещения заемщика.

Приоритет - критический (critical).

3.2.8. Функция передачи заявки верификатору при недостостаточном


балле

При недостаточном балле для автоматического отказа или одобрения выдачи


займа, должна быть организована передача Модулем заявки верификатору для
дополнительных проверок. Далее верификатору необходимо использовать
реализованный в Системе механизм отклонения либо одобрения заявки на
заем.
Приоритет - критический (critical).

64
4. Нефункциональные требования
4.1. Требование к внешнему интерфейсу

4.1.1. Интерфейсы пользователей

Модуль не влияет на интерфейсы пользователей в существующей Системе.


Используются реализованные в Системе интерфейсы одобрения займа, отказа
в займе, дополнительной проверки заявки на заём верификатором.

Требования к интерфейсам Системы подробно описаны в проектной


документации Системы [2].

Основные цвета - зеленый и белый.

Интерфейс Системы и Модуля должен быть удобным и эргономичным:

- унифицированный интерфейс для всех частей Системы и Модуля;

- надписи на русском языке;

- группировка пунктов меню в зависимости от функции.

4.1.2. Интерфейсы оборудования

Интерфейсы оборудования не выявлены.

4.1.3. Программные интерфейсы

4.2. Интерфейсы передачи данных

ИПД-1. Система должна отправлять уведомление об изменения статуса заявки


на электронную почту.

ИПД-2. Система в случае одобрения заявки на заем должна содержать в себе


сумму займа, процент, суммы выплат, сроки погашения, и пр.

4.3. Другие нефункциональные требования

4.3.1. Требования к производительности

ТП-1. Потенциальный заемщик должен иметь возможность ввести данные


24/7.

ТП-2. Модуль и Система должны обрабатывать входящие заявки за время не


превышающее 5 минут.

65
ТП-3. Модуль и Система должны обслуживать 1000 посетителей ресурса
единовременно, со средней продолжительностью сеанса 15 минут.

ТП-4. Загрузка веб-страниц в браузере должны полностью загружаться не


более чем за 10 секунд по модемному соединению со скоростью 40 кб/с.

ТП-5. Модуль должен обладать механизмом гарантирующими целостность


данных.

4.3.2. Требования к охране труда

Требования к охране труда не выявлены.

4.3.3. Требования к безопасности

ТБ-1. Должно отвечать тем же требованиям к безопасности, что в уже


реализованной Системе [2].

ТБ-2. При выдаче займа суммой свыше 15 000 российских рублей заёмщик
обязан пройти идентификацию личности (фотография личности в профиль с
документами подтверждающие личность) согласно Бизнес-правилу-9 [1].
ТБ-3. Карта, указываемая потенциальным заёмщиком на этапе регистрации,
должна быть именной и принадлежать заёмщику согласно Бизнес-правилу-1
[1].
ТБ-4. Паспортные данные потенциального заёмщика должны быть валидными
согласно Бизнес-правилу-3 [1].
ТБ-5. Номер телефона, вводимый потенциальным заёмщиком на этапе
регистрации, должен быть зарегистрирован в РФ согласно Бизнес-правилу-5
[1].
4.3.4 Атрибуты качества ПО

Доступность-1. Модуль Изи мани должен быть доступен пользователям,


находящимся на территории РФ.

Надежность-1. При возникновении проблем с соединением, Модуль не должен


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

Надежность-2. Должен быть обеспечен контроль целостности данных на


уровне СУБД.

Надежность-3. Должны быть обеспечены те же атрибуты качества


надежности, что в Системе. Подробное описание в проектной документации
[2].
66
67
Приложение 1. Глоссарий
1. Термины

1. Бюро кредитных историй (БКИ) — компания, оказывающая в


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

2. Верификатор - сотрудник заказчика, принимающий решение по


заявке.

3. Заемщик - физическое лицо, клиент заказчика, нуждающийся в


денежных средствах.

4. Заемные средства - денежные средства, выдаваемые заказчиком


физическому лицу.

5. Заявка - заявка на кредит.

6. Кредитная история - это информация об исполнении субъектом


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

7. Скоринг - система оценивания потенциального заемщика на


основе его кредитной истории.

2. Сокращения

1. БА - бизнес аналитик.
2. БКИ - бюро кредитных историй.
3. МВД - министерство внутренних дел.
4. ПО - программное обеспечение.

5. РФ - Российская Федерация.

6. PDL - кредит со сроком исполнения обязательств до 30 дней.

7. IL - кредит со сроком исполнения обязательств более 30 дней.

68
69