Оглавление

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСОБЕННОСТИ РАБОТЫ МИКРОФИН
АНСОВОЙ ОРГАНИЗАЦИИ В УСЛОВИЯХ ЦИФРОВОЙ ЭКОНОМИКИ...4
1.1 Современное состояние развития информационных систем и технол
огий в сфере кредитования.....................................................................................4
1.2 Назначение и основные функции скоринговых систем........................7
1.3 Подходы к разработке программного обеспечения для микрофинанс
овых организаций в условиях цифровой экономики.........................................12
ГЛАВА 2. АНАЛИЗ ПРЕДПРИЯТИЯ ООО «АйДиЭф Технолоджи»....18
2.1. Характеристика предприятия и оказываемых услуг...........................18
2.1.1 Резюме компании.................................................................................18
2.1.2.Характеристика производственно-хозяйственной деятельности ком
пании.......................................................................................................................19
2.1.3 Характеристика предоставляемых услуг...........................................22
2.1.4. Характеристика имеющихся основных средств и технологий.......23
2.2. Анализ использования информационных технологий в управлении 
предприятием.........................................................................................................25
2.2.1. Новизна технических и технологических решений, потребительск
их свойств...............................................................................................................25
2.2.2. Кадровый ресурс..................................................................................32
2.2.3. Используемые информационные технологии..................................33
2.2.4. Текущие и планируемые объемы выпуска товаров в натуральном 
и денежном выражении........................................................................................34
2.2.5. Инвестиционный план. Объекты инвестиций..................................35
2.2.6. Выявленные проблемы в реализации CRM системы.......................35
ГЛАВА 3. РАЗРАБОТКА ПРОТОТИПА СКОРИНГОВОЙ СИСТЕМЫ37
3.1. Анализ объекта автоматизации.............................................................37
3.2. Построение модели вариантов использования....................................38
3.2.1 Требования к системе...........................................................................38
3.2.2 Глоссарий проекта................................................................................38
3.2.3 Диаграмма вариантов использования.................................................39
3.3 Структура системы..................................................................................41

1
3.4 Проектирование классов.........................................................................42
3.4.1 Диаграмма концептуальных классов..................................................42
3.4.2 Диаграмма состояний...........................................................................42
3.5 Проектирование схемы данных.............................................................44
ЗАКЛЮЧЕНИЕ.............................................................................................47
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ.........................................48
ПРИЛОЖЕНИЕ А.........................................................................................49

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

3
 Рис. 1 Модель кредитного скоринга Дюрана

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

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

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

9
 где р —вероятность дефолта, 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 решений в Республике Беларусь. Гла
вные цели перспективного стратегического развития заключаются в постоянн
ом совершенствовании разработки высокотехнологичного программного про
дукта, имеющего свои уникальные конкурентные преимущества на рынке Fin
Tech. Также, учитывая планы по привлечению к выполнению работы на осно
вании договора о прохождения производственной практики (2-3 студента в г
од) и профильному обучению студентов вузов IT специальностей, компания 
планирует внести вклад в развитие системы образования.
Компания «АйДиЭф Технолоджи» является центром разработки и оказ
ывает услуги по разработке и внедрению новых FinTech решений для группы 
компаний холдинга ID Finance. Предпосылкой создания собственного центра 
разработки программного обеспечения является возможность холдинга полу

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

18
 Компания «АйДиЭф Технолоджи» входит в международную группу Fi
nTech компаний 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-
система строится на микросервисах и отказоустойчивой инфраструктуре. 
Система покрывает все основные аспекты деятельности кредитно-
финансовой организации, включая привлечение потенциальных клиентов 
и полный цикл автоматического учета займов и кредитов. Автоматизируе
т процессы привлечения заявок, идентификации клиентов, оценку кредит
оспособности, выдачу денежных средств, погашение займов (кредитов), м
ониторинг, администрирование, работу контактного-центра (клиентской 
поддержки), работу с просроченными займами и коллекторами.
Решение строится по модульному принципу - на данный моме
нт разрабатываются более 15 модулей. Это позволяет подобрать оптималь
ную конфигурацию для любой компании и легко интегрироваться с любы
ми сторонними продуктами, включая скорринговые системы, 1С-
бухгалтерию, клиент-банки, а также с кредитными бюро и государственн
ыми службами. 

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

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

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

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

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

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

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

Рисунок 4. Модуль «Должники».
Модуль «Коллекторы»
Разработка функционала по управлению доступом внутренних и внешн
их коллекторов и коллекторских агентств к системе. Настройки выгрузки дан
ных (например, реестры) и правил работы.

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

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

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

Рисунок 7. Модуль «Бонусы».
2.2.2. Кадровый ресурс
На 31.12.2020 списочная численность ООО «АйДиЭф Технолоджи» 
составляет 16 человек. Численность IT специалистов составляет 12 челове
к, численность административного персонала - 4 человека. Руководитель 
ООО «АйДиЭф Технолоджи» Комаров Александр Сергеевич имеет опыт 
в IT более 10 лет, руководил различными проектами, связанными с разраб
откой корпоративных программных продуктов и финансовых систем, обл
адает достаточным опытом в создании конечных программных продуктов 
и их продвижении на рынках Республики Беларусь, Российской Федераци
и и Европы. Комаров Александр окончил факультет прикладной математ
ики и информатики Белорусского государственного университета по спец
иальности «Компьютерная безопасность». В дальнейшем руководитель о
рганизации «АйДиЭф Технолоджи» занимал различные позиции в компа
нии Itransition, от разработчика до руководителя команды разработки в от
делах разработки финансовых систем и систем электронной коммерции, п
осле руководил одним из направлений разработки финансовых систем в к
омпании HiEnd Systems. 
30
 Ключевыми сотрудниками компании являются: 
Игорь Котов - 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 лет;
Сидорова Марина – бизнес-аналитик, окончила ГУ ВПО "Белорусск
о-Российский университет", работала в ОАО "АСБ Беларусбанк", ОАО "
Хоум Кредит Банк" и ООО "Альфа-Банк", общий стаж 7 лет на должностя
х ведущего, главного специалиста сопровождения ПО управления инфор
мационных технологий, главного специалиста и начальника отдела сопро
вождения ПО управления развития и сопровождения ПО, главного специа
листа управления развития расчетных продуктов и дистанционных канал
ов обслуживания.
Так как АйДиЭф Технолоджи планирует разрабатывать ПО для все
й группы компаний ID Finance. Штат сотрудников будет расширяться. В 2
022 году мы планируем штат около 70 сотрудников, в 2023 – 100 сотрудн
иков, в 2024 – 135 сотрудников.
2.2.3. Используемые информационные технологии
Компания «АйДиЭф Технолоджи» использует современный стек те
хнологий при разработке программных продуктов «Solva 2.0», «MoneyMa
n 2.0», «Ammopay 2.0», «Kresko 2.0». 
1. Бэкэнд разработка базируется на:
- JAVA 7/8 с использованием универсального фреймворка Spring Fr
amework с открытым исходным кодом для Java-платформ. Набор специфи
каций JEE - EJB, JPA, JAX-RS, Glassfish;
- Инфраструктурные решения - Docker, ELK, Netflix stack (Swarm, C
onsul, Vault, Hystrix, Kibana, Grafana, Prometheus, Haproxy);

31
 - Собственный Custom framework для микросервисов на основе Spri
ng и 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, M
ockito, RestAssured. Selenium;
- Системе автоматической сборки - Gradle, Maven.
2. Фронтенд разработка базируется на:
- Компонентной архитектуре AngularJS;
- Системе автоматической сборки - Webpack. Single page application.
- Управлении публичными ресурсами – Wordpress CMS.
Внедрение вышеуказанных ИТ-технологий помогает систематизиро
вать информацию, документы, упрощает сам рабочий процесс. 
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
32
 ов (работ, услуг, имущественных 
прав на объекты интеллектуальн
ой собственности)
Годовая производительность тру
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

Таблица 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

33
   в том числе:

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

Таблица 3. Инвестиционный план. Источник: данные компании. 
Увеличение инвестиций на технику и компьютерные программы напря
мую связано с планируемым расширением штата сотрудников, а это значит, ч
то необходимо вкладывать средства в покупку дополнительных компьютеров
, серверов, сетевого оборудования для поддержания стабильного рабочего пр
оцесса.
2.2.6. Выявленные проблемы в реализации CRM системы
Основной заказчик – российская микрофинансовая организация. Вид де
ятельности заказчика – выдача PDL и IL микрозаймов. В данный момент расс
мотрением заявок на кредит занимается команда верификаторов, которые оце
нивают платежеспособность клиентов.
В ходе прохождения преддипломной практики было выявлено несколь
ко проблем, связанных с работой, текущей CRM системы, ввиду отсутствия а
втоматизации процесса выдачи кредита, а именно:
1. Ежемесячные расходы на зарплату верификаторов составляют пр
имерно 10 тысяч долларов.
2. Скорость принятия решения о выдаче займа в среднем составляет 
72 часа
Таким образом была предложена идея во автоматизации процесса выда
чи кредита. В ходе дискуссий с командой разработки и командой бизнес анал
итиков было принято решение начать разработку нового модуля в существую
щей CRM-системе. Модуль «Скоринг» поможет практически полностью авто
матизировать процесс принятия решения о выдаче кредита, что поможет доб
иться следующих результатов:
1. Выдача кредита в большинстве случаев будет происходить за 5 м
инут.
2. Большую часть штата специалистов-верификаторов можно будет 
сократить
3. В перспективе появится больше потенциальных клиентов ввиду з
апуска рекламы «Кредит за 5 минут»
Таким образом, основной задачей для решения в дипломной работе буд
ет написание спецификации требований к программному обеспечению (Техн
ическое задание) для последующей разработки модуля «Скоринг».
Исходя из вышеизложенного можно сделать вывод, что используемые I
T-технологии существенно помогают систематизировать информацию, докум
енты и упрощают сам рабочий процесс. Также данные технологии позволяют 
34
разрабатывать сложные программные продукты такие как, например модуль 
«Скоринг». Планируемые объемы выпуска продукции довольно оптимистичн
ые. Таким образом можно сказать о хорошей тенденции развития компании «
АйДиЭф Технолоджи». Однако не смотря на данный оптимизм в работе сист
емы имеется один существенный недостаток – это отсутствие автоматизации 
в процессе принятия решения о выдаче кредита. Данная проблема и стала тем
ой дипломной работы. И в ходе её выполнения предложено решение. Результ
атом станет готовое техническое задание для модуля «Скоринг».
ГЛАВА 3. РАЗРАБОТКА ПРОТОТИПА СКОРИНГОВОЙ СИС
ТЕМЫ
3.1. Анализ объекта автоматизации
Заказчик – российская микрофинансовая организация. Основной вид де
ятельности – выдача PDL и IL микрозаймов. В данный момент рассмотрение
м заявок на кредит занимается команда верификаторов, которые оценивают п
латежеспособность клиентов. 
Цель проекта – разработка скоринговой системы, которая сможет обраб
атывать заявки клиентов анализируя данные, полученные из БКИ, выбранну
ю сумму/срок займа, номера телефонов, указанные клиентом, IP адреса и про
чее.
Подход к бизнес-анализу - гибкий 
Работа ведется с использованием гибкой методологии разработки прог
раммного обеспечения Scrum 
Артефакты хранятся на онлайн сервисе google drive 
Soft : draw io, Rational Rose 
Тип ПО: заказное, веб сервис, возможно мобильностей приложение, Ск
оринг - специализированное ПО
Модель бизнес-процесса представлена на рисунке 1.1. Моделирование 
бизнес-процесса реализовано с помощью нотации BPMN, так как она максим
ально подходит для описания сложных семантических конструкций, использ
ует базовый набор интуитивно понятных элементов. 
 

35
 Рисунок 1.1 – Автоматизированный процесс принятие решения по за
явке. 
Для разработки данной системы разрабатывается техническое задания 
с использованием SRS ISO/IEC/ IEEE 29148-2011 Systems and software engine
ering —Life cycle processes — Requirements engineering. Техническое задание 
«Автоматизация процесса выдачи кредитов» представлено в приложении А. 
Разработанные в рамках данной главы модель бизнес-процесса и техни
ческое задание в последующем будут использованы для создания диаграммы 
вариантов использования и логического проектирования в целом.
3.2. Построение модели вариантов использования 
В данной главе описываются требования к системе, ее функции и вариа
нты использования на основе разработанного ранее технического задания, а т
акже разрабатываются глоссарий для проекта, документация основных вариа
нтов использования. 
3.2.1 Требования к системе 
Выявление функциональных и нефункциональных требований к систем
е необходимо для того, чтобы правильно сформировать концептуальное опис
ание системы. 
Основные функциональные требования к системе: 
 Функция проверки IP адреса, с которого была отправлена заявка
 Функция проверки карты
 Функция запроса в МВД
 Функция запроса в БКИ
 Функция оценивания параметров по заданным критериям
Нефункциональные требования к системе 
 Доступность-1. Модуль Изи мани должен быть доступен пользов
ателям, находящимся на территории РФ.

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

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

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

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

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

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

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

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

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

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

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

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

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

41
 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) 
Registration  Идентификационный 
Reg_ID  (ПК) номер клиента  int 

FIO ФИО клиента  varchar(25) 

Birthday Дата рождения клиен date
та 

42
 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 допускает пустое значение ячеек столбца. 
Сгенерированный код первичных ключей представлен ниже на пример
е первичного ключа данных Кредита. Код остальных первичных ключей выг
лядит аналогично. 
ALTER TABLE [Credit]  
 ADD CONSTRAINT [PK_Credit] 
43
  PRIMARY KEY CLUSTERED ([CreditID] ASC) 
GO 
Создание всех первичных ключей начинается с вызова ALTER TABLE 
[(название таблицы] ADD CONSTRAINT [(название первичного ключа] PRI
MARY 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 [(название первичного ключа] FOREI
GN KEY ([(первичный ключ таблицы, с которой необходимо связать данную 
таблицу)]), REFERENCES [(название таблицы, с которой необходимо связать 
данную таблицу)] ON DELETE No Action ON UPDATE No Action и заканчив
ается вызовом GO. 
 

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

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

46
 ПРИЛОЖЕНИЕ А 
 
 
 
 Спецификация требований к ПО (техническое задание)

для 

Изи Мани

Версия 1.6

17.02.2020

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

Гербалы А.В.

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

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

гласования

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

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

Александр 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

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

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

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

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

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

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

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

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

https://docs.google.com/document/d/1A_3xdncDvPltCjUN1hewFoIYrscWX_ejQ4
PvA8yU2PA/edit?usp=sharing .

50
2. Проектная документация основной системы “Система Изи мани”.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54
 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.  Модуль оценивает параметр “Возраст”.

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

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. Модуль сверяет данные карты с данными из заявки.

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

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. Заёмщику Система отображает экран отказа в займе. 
57
19. Система отправляет на электронную почту уведомление.
Альтернативный поток 17Б:
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).

58
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%, где

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

- если коэффициент 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. Оценивание параметра “Общая долговая нагрузка”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61
Приоритет - критический (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, то происходит автоматическое одобрен
ие заявки Модулем. 

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

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

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

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

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

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

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

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

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

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

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

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

63
 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 минут.
64
ТП-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].

65
 Приложение 1. Глоссарий
1. Термины

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

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

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

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

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

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

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

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

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

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

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

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

 
 

66
 
 
 

67