Проектирование информационной системы скоринговой оценки

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

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

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

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

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

3.10 Дерево решений Федоровой

В качестве одной из возможных моделей решено использовать класификационно - регрессионное дерево, предложенное Еленой Анатольевной Федоровой в статье «Bankruptcy prediction for Russian companies: Application of combined classifires» в журнале «Expert systems with applications».

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

Рисунок 4 - классификационно-регрессионное дерево Федоровой

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

При построении регрессионного дерева в «листьях» должно находиться значение целевой функции. В случае с деревом, предложенной Федоровой, в качестве целевых функций используются финансовые показатели, которые важность которых была вычислена из выборки в несколько сотен финансовых коэффициентов, используемых в моделях оценки кредитоспособности. Значимость коэффициентов вычислялась на выборке из 3505 реально существующих российских компаний, половина из которых обанкротилась.

В классификационно-регрессионном дереве, представленном на рисунке 4 используется следующие экономические показатели:

· cash flow/sales;

· cash/current liabilities

· sales/current liabilities

· inventories/current liabilities

· cash/current assets

· revenue reserves/total assets

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

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

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

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

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

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

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



4. Анализ требований

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

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

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

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

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



Рисунок 3 - диаграмма вариантов использования для пользователя

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

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

Рисунок 4 - диаграмма вариантов использования для сервера



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

4.1 Детальное проектирование

Внутреннее устройство работы приложения удобно описать при помощи паттерна MVC.

Модель MVC (model, view, controller) - схема шаблонов проектирования, предназначенная для создания веб-приложений. Данный шаблон представляет собой универсальные рекомендации по созданию удобочитаемого кода, и в то же время рабочего приложения с понятным внутренним устройством [17]. Очевидное преимущество, которое предоставляет нам MVC - это четкое разделение логики представления (интерфейса пользователя) и логики приложения. Помимо изолирования видов от логики приложения, концепция MVC существенно уменьшает сложность больших приложений. Код получается гораздо более структурированным, и, тем самым, облегчается поддержка, тестирование и повторное использование решений.

Также, преимуществом использования данного паттерна является его применимость ко всем типам устройств, которые пользуются данным веб-приложением. Для MVC нет разницы, с какой операционной системы происходит запрос к приложению, будь то windows, linux или mac. Вся функциональная часть выполняется на стороне сервера, поэтому возвращаемые данные для всех будут одинаковыми. Но есть различия между запросами с ПК и с мобильных устройств. Предоставляемый интерфейс должен различаться, если запрос приходит с персонального компьютера или с мобильного телефона. Модель возвращает одинаковые данные, единственное различие заключается в том, что контроллер выбирает различные виды для вывода данных.

Далее будет детально рассмотрена модель MVC, представленная на рисунке 5.

Рисунок 5 - схема MVC работы приложения

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

Роль контроллера в модели MVC в данном случае представляет браузер. Браузер принимает запрос от пользователя и проверяет его корректность. Если запрос прошел проверку и соответствует всем требованиям, то контроллер переправляет запрос на «модель».

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

Рисунок 6 - диаграмма деятельности

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

Роль «представления» в данном приложении играет вывод браузером страницы с результатами вычисления системы, согласно заданным условиям и выбранной модели.

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

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

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

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

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



Рисунок 7 - диаграмма классов

На диаграмме классов представлены все классы системы и отображено то, как они взаимодействуют между собой. Подробнее о каждом классе:

«Пользователь» - класс, отражающий пользователя системы. Пользователь обладает следующими атрибутами:

· «Имя» - публичный атрибут для идентификации пользователя в системе. Один из двух атрибутов идентификации;

· «Фамилия» - публичный атрибут для идентификации пользователя в системе. Один из двух атрибутов идентификации;

· user_ID - приватный атрибут для идентификации пользователя в системе. Атрибут нужен для уникальной идентификации пользователя в системе, т.к. атрибут «Имя» и «Фамилия» может дублироваться у многих пользователей.

Классу «Пользователь» доступны следующие операции:

· «Авторизация» - при вводе логина и пароля пользователь отправляет запрос серверу на проверку аутентификации. При успешной комбинации логин/пароль, сервер отправляет пользователю уникальный токен, при получении которого у пользователя начинается сессия на странице системы. Сессия не ограничена по времени. При выходе из системы сессия прекращается;

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

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

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

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

Классу «Сервер» доступны следующие операции:

· Обработать данные согласно выбранной методике;

· Предоставить результат - возврат в интерфейс результата вычислений;

· Интерпретация выводимого результата;

· Проверка авторизации.

«База моделей оценки» - библиотека для хранения методик, хранится на сервере. У этого класса две функции - предоставить пользователю список доступных моделей оценки и добавить новую модель оценки. Новые модели добавляются по запросу пользователя после подачи пользователем соответствующей заявки. Услуга добавления модели в базу монетизирована.

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

«Backend разработчик» - класс для описания серверного разработчика, задействованного в системе. Непосредственно разработчик не влияет на работоспособность системы. Backend разработчик имеет те же атрибуты, что и обычный пользователь системы. Т.к. backend-разработчик не взаимодействует с системой напрямую, описание доступных ему действий приводиться не будет.

«Веб - разработчик» - класс для описания участия веб-разработчика в работе системы. Непосредственно разработчик не влияет на работоспособность системы. Веб-разработчик имеет те же атрибуты, что и обычный пользователь системы. Т.к. backend-разработчик не взаимодействует с системой напрямую, описание доступных ему действий приводиться не будет.

«Провайдер» - в этом классе содержится понятие интернет-соединения. Если по какой-то причине отсутствует соединение, любое функционирование системы невозможно.

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



Рисунок 8 - диаграмма последовательности

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

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

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

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



4.2 Управление проектом

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

1) Менеджер проекта;

2) Дизайнер;

3) Веб разработчик;

4) Backend разработчик;

5) QA специалист.

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

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

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

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

QA специалист отвечает за разработку планов тестирования, проведение тестирования согласно разработанным планам. В его обязанности входит проведение тестирования backend и frontend части приложения. Если будут выявлены несоответствия работы приложения с заявленным в ТЗ функционалом, QA специалист обязан поставить соответствующие задачи по исправлению в разработку.

Разработка будет декомпозирована на следующие составные части:

· Анализ требований;

· Проектирование архитектуры и интерфейсов (с точки зрения дизайна);

· Разработка документации и плана интеграции;

· Написание программного кода и сборка проекта;

· Итоговое тестирование.

Оплата труда задействованных специалистов включает в себя следующие позиции:

1) Заработная плата, включает подоходный налог - 13%;

2) Премия;

3) Выплаты в пенсионный фонд и фонд социального страхования - 14%;

4) Медицинская страховка - 1% от ЗП;

5) Расходы на питание - 2% от ЗП;

В таблице ниже будут представлены расчеты затрат на оплату труда и сопровождение проекта:

Таблица 5 - затраты на реализацию проекта

	Менеджер проекта	Backend разработчик	Frontend разработчик	Дизайнер	QA инженер
ЗП сотрудника, rur/месяц	140000	120000	120000	120000	60000
Медицинская страховка -1% от ЗП rur/месяц	1400	1200	1200	1200	600
Расходы на питание - 2% rur/месяц	2800	2400	2400	2400	1200
Ставка социальных налогов	14%	14%	14%	14%	14%
Социальные налоги на сотрудника	19600	16800	16800	16800	8400
Премия 15% от ЗП	21000	18000	18000	18000	9000
Затраты времени в день на сопровождение и разработку (часы)	1	5,6	5,6	2,4	5,6
Затраты на оплату согласно времени разработки	6125	4200	4200	1800	1200

Реализация проекта предположительно займет срок в 15 рабочих дней по 8 часов, что равняется 3 рабочим неделям. В таблице ниже описаны этапы разработки и временные затраты на каждый этап.

Таблица 6 - методика RACI

Работы	Сроки	Менеджер	Дизайнер	Веб разработчик	Backend разработчик	QA специалист
Заключение договора	1	R
Формирование команды	1	R
Планирование спринтов	1	R
Определение функциональных требований	2	R		C
Определение технических требований	2	A		C	R
Приобретение оборудования	3	R			C
Установка оборудования	4	A		R		A
Написание ТЗ	3-5					R
Разработка дизайна	5-6	A	R	C
Разработка API на сервере	6-9				R	C
Разработка программного кода	9-13	C		R
Тестирование	13-14			C		R
Сдача проекта заказчику	15	R				C

В таблице 6 представлена методика RACI

RACI - это аббревиатура:

R - Responsible (исполняет);

A - Accountable (несет ответственность);

C - Consult before doing (консультирует до исполнения);

I - Inform after doing (оповещается после исполнения).

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

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

Сумма отчислений в виде премии сотрудникам за проделанную работу, исходя из длительности проекта в 15 рабочих дней составит 42000 рублей.

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

Персональные компьютеры - Dell «Vostro 3900 MT». Цена 1 единицы составляет 19600 рублей. Потребуется 5 экземпляров. Итого 98000 рублей.

Мониторы - Samsung LS24F350FHI. Цена одной единицы товара 8990 рублей. Потребуется 5 экземпляров. Итого 44950 рублей.

Офисная мебель - столы и стулья. Стоимость стола 1350 рублей за единицу. Стоимость стула 850 рублей за единицу. На закупку 5 экземпляров столов и стульев понадобится 11000 рублей.

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

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

1) Определяется годовая норма амортизации.

2) Вычисляется сумма годовой амортизации.

3) Расчет ежемесячных отчислений

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

Таблица 7 - годовые суммы амортизации.

Компьютеры	Мониторы	Офисная мебель
49000	22475	5500



Соответственно, значения годовой амортизации будут следующими:

· Персональные компьютеры - 4083 рубля;

· Мониторы - 1873 рубля;

· Офисная мебель - 483 рубля.

Сумма месячных амортизационных отчислений составляет 6415 рублей.

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



Заключение

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

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

В качестве описания функционала системы был приведен перечень математических моделей, которые будут включены в состав проектируемой системы. Полный перечень моделей следующий: модель Сайфуллина-Кадыкова, модель Альтмана, модель Зайцевой, модель Таффлера, модель Лиса, модель Спрингейта, модель Беликовой-Давыдова. Предполагается, что в систему будут включены также методики Сбербанка РФ и Альфа банка. Также, предполагается, что в систему будет включен аналитический аппарат классификационно-регрессионного дерева решений Федоровой.

В главе о проектировании был приведен ряд диаграмм, которые показывают внутреннее строение системы и этапы ее разработки. Были приведены диаграммы вариантов использования, диаграмма классов, диаграмма деятельности и диаграмма последовательности.

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

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



Список источников

1. A comparison of alternative bankruptcy prediction models [Электронный ресурс]: сайт. - Режим доступа: http://www.sciencedirect.com/science/article/pii/S1815566910000032

2. Altman - Izan: Identifying Corporate Distress in Australia: An Industry Relative Analysis. Working Paper, New York University, 1984.

3. Altman, E. I.: Financial Ratios, Discriminant Analysis and the Prediction of Corporate Bankruptcy. Journal of Finance, September 1968, 589-609 pp.

4. Bankruptcy prediction for Russian companies : Application of combined classifiers / Elena Fedorova, Evgenii Gilenko, Sergey Dovzhenko.

5. Bankruptcy prediction models based on multinorm analysis: An alternative to accounting ratios [Электронный ресурс]: сайт. - Режим доступа: http//www.sciencedirect.com/science/article/pii/S0950705111002413

6. Bankruptcy prediction models: How to choose the most relevant variables? [Электронный ресурс]: сайт. - Режим доступа: https://mpra.ub.uni-muenchen.de/44380/

7. Beaver W. H.: Financial Ratios as Predictors of Failure. Empirical Research in Accounting, Selected Studies, 1966.

8. Deakin, E. B.: A Discriminant Analysis of Predictors of Failure. Journal of Accounting Research, 1972/10. 167-179 pp.

9. Анализ и диагностика финансово-хозяйственной деятельности пред-приятия: учебное пособие / Под редакцией П.П. Табурчака, В.М. Гумина, М.С. Сапрыкина. - Ростов-на-Дону: Феникс, 2009. - 352 с.

10. Антикризисное управление: от банкротства - к финансовому оздоровлению/ Под ред. Г.П. Иванова. - М.: Закон и право, ЮНИТИ, 1995. - 130с.

11. Балдин К.В., Белугина В.В., Галдицкая С.Н., Передеряев И.И. Банкротство предприятия: анализ, учет и прогнозирование: Учебное пособие. - М.: ИТК «Дашков и Ко», 2007. - 407с.

12. Берникова, Т.Б. Анализ и диагностика финансово-хозяйственной деятельности предприятия / Т.Б. Берникова. - М., 2003. - 539с.

13. Брауде Э. Технология разработки программного обеспечения / Э. Брауде. СПб.: Питер, 2004. - 655 с.

14. Бройдо В.Л. Вычислительные системы, сети и телекоммуникации: Учебник для вузов. 2-е изд. / В. Л. Бройдо. - СПб.: Питер, 2004. - 703 с.

15. Бухгалтерский учёт и анализ хозяйственной деятельности в строительных организациях: Учебник / Под общей редакцией проф. М.И. Дмитриева. - М.: Финансы, 2006. - 278с.

16. Гермалович Н.А. Анализ хозяйственной деятельности предприятия / Н.А. Гермалович. - М: Финансы и статистика, 2011. - 346с.

17. Грекул, В.И., Проектирование информационных систем / Г.Н. Денищенко, Н.Л. Коровкина - М.: Бином. Лаборатория знаний, 2008. - 304с.

18. Григорьев, М.В., Григорьева, И.И. Проектирование информационных систем. Учебное пособие для вузов / Григорьев М.В. - М.: Юрайт, 2016. - 319с.

19. Григорьев, М.В., Григорьева, И.И. Проектирование информационных систем. Учебное пособие для вузов / Григорьев М.В. - М.: Юрайт, 2016. - 319с.

20. Ефимова О.В. Финансовый анализ. 3-е изд., перераб. с доп. / О.В. Ефимова. М.: Бухгалтерский учет, 1999. - 351c.

21. Исаев, Г.Н., Проектирование информационных систем / Исаев, Г.Н. - М.: Омега-Л, 2012. - 432с.

22. Ковалев В.В. Финансовый анализ: Управление капиталом. Выбор инвестиций. Анализ отчетности. - М.: Финансы и статистика, 1996. - 432с.

23. Лешек А. Мацяшек, Анализ и проектирование информационных систем с помощью UML 2.0 / Лешек А. Мацяшек - М.: Вильямс, 2008. - 816с.

24. Маркарьян Э.А., Герасименко, Г.П. "Финансовый анализ" - М.: "ПРИОР", 1997 г. - 160с.

25. Постановление Правительства РФ от 1 июня 1998 г. № 537 "О Федеральной службе России по делам о несостоятельности и финансовому оздоровлению".

26. Руководство по кредитному менеджменту: Пер. с англ. / Под ред. Б. Эдвардса. - М.: ИНФРА-М, 1996. - 464с.

27. Скоун Т. "Управленческий учет"/Пер. с англ. под редакцией Н.Д. Эриашвили. - Аудит, ЮНИТИ, 1997. - 179с.

28. Федоров И.Г. Моделирование бизнес-процессов в нотации BPMN 2.0: Монография / И.Г. Федоров. - М: МЭСИ, 2013. - 255с.

Размещено на Allbest.ru