Программное обеспечение классификации заемщиков при оформлении потребительских кредитов Полтавского ГРУ АКБ "Приватбанк"

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

Рисунок 2.4 - ER-диаграмма логической модели данных подсистемы классификации заемщика при оформлении потребительских кредитов

Размещено на http://www.allbest.ru/

Рисунок 2.5 - ER-диаграмма физической модели данных подсистемы классификации заемщика при оформлении потребительских кредитов

Выводы по разделу 2

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

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

3. АЛГОРИТМИЗАЦИЯ ПО ПОДСИСТЕМЫ классификации заемщиков при оформлении потребительских

кредитов

3.1 Описание основных алгоритмов подсистемы классификации заемщиков при оформлении потребительских кредитов

Под алгоритмом понимается точно определенное правило действий, для которого задано указание: как и в какой последовательности это правило необходимо применять к исходным данным задачи, чтобы получить ее решение [14].

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

Каждый алгоритм должен быть:

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

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

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

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

- Процесс составления алгоритмов называется алгоритмизацией. Алгоритмы могут быть заданы несколькими способами:

- с помощью словесного описания;

- с помощью графического описания;

- с помощью псевдокода.

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

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

Единой системой программной документации стандартизовано два метода описания алгоритмов программ: при помощи блок-схем и при помощи р-схем[12]. Общим достоинством этого метода является его независимость от языка реализации, что позволяет добиться переносимости алгоритмического обеспечения. В этом методе также реализованы все базовые структуры управления.

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

3.2 Алгоритм управления интерфейсами

Данный алгоритм предназначен для проверки пользовательских прав доступа в БД и загрузки интерфейсных модулей системы в соответствие с правами.

Входные данные: входное имя и пароль пользователя;

Выходные данные: загрузка выбранного интерфейса;

Рисунок 3.1 - Блок-схема алгоритма управления интерфейсами

3.3 Алгоритм расчета показателей социального статуса заемщика

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

Входные данные: данные анкеты.

Выходные данные: S1 - показатель социального статуса заемщика (0?S1?40).

Рисунок 3.2 - Алгоритм расчета показателей социального статуса заемщика

Рисунок 3.2, лист 2

Рисунок 3.2, лист 3

Рисунок 3.2, лист 4

Рисунок 3.2, лист 5

Рисунок 3.2, лист 6

3.4 Алгоритм расчета финансовых показателей заемщика

Данный алгоритм предназначен для анализа финансового положения заемщика и определения показателей его финансового состояния.

Входные данные: данные анкеты.

Выходные данные: S2 - показатель финансового состояния

заемщика (0?S2?60).

Рисунок 3.3 - Алгоритм расчета финансовых показателей

Рисунок 3.3, лист 2

Рисунок 3.3, лист 3

3.5 Алгоритм вычисления удельной суммы к сальдо бюджета

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

Входные данные: сумма кредита, срок кредита, процентная ставка, общие доходы заемщика, общие расходы заемщика.

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

Рисунок. 3.4 - Алгоритм вычисления удельной суммы к сальдо бюджета

3.6 Алгоритм классификации заемщика

Входные данные: показатели социального статуса и финансового состояния

Выходные данные:Решение о целесообразности кредита, класс заемщика.

Рисунок 3.5 - Алгоритм классификации заемщика

Выводы по разделу 3

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

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

4 Проектирование ПО ПОДСИСТЕМЫ классификации ЗАЕМЩИКА ПРИ ОФОРМЛЕНИИ ПОТРЕБИТЕЛЬСКИХ КРЕДИТОВ

4.1 Выбор и обоснование средств разработки

4.1.1 Основные характеристики современных средств разработки

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

К основным характеристикам современных средств разработки программного обеспечения относят:[6]

- поддержка как процедурного, так и объектно-ориентированного

- стилей программирования;

- наличие "визуальных" средств разработки интерфейса;

- обеспечение доступа к базе данных;

- использование различных методов "визуализации" как модели данных, так и самих данных;

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

4.1.2 Выбор оптимального программного средства разработки

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

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

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

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

1 Наличие опыта разработки с использованием данного средства (5).

2 Требования к вычислительным ресурсам ( 5 ).

3 Предоставляемые возможности создания интерфейса ( 5 ).

4 Скорость разработки программного продукта (5 ).

5 Скорость работы разработанного программного обеспечения (4).

6 Удобство эксплуатации средства разработки (3).

В круглых скобках указана важность данной характеристики

Среди современных доступных средств разработки для выбранной нами операционной системы Windows можно выделить три наиболее часто используемых:

- Borland Delphi v 2007;

- Microsoft Visual Studio 2005;

- Eclipse (Java 2 SE 5.0).

Каждое из этих средств содержит весь спектр современного инструментария, который был перечислен ранее. Главное отличие состоит в типичной области использования рассматриваемых средств. Так, Java и Visual C++ обычно используются при разработке приложений, выполняющих большое количество вычислений. К недостаткам этого средства разработки можно отнести высокие требования к системным ресурсам и медленная скорость компиляции исходного кода.

Главными преимуществами Delphi является его распространенность, возможность быстрого внесения изменений в программу и предоставление разработчику большого количества визуальных компонентов для разработки качественного графического интерфейса.[12]

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

- определение критериев, по которым будет произведено сравнение и степени их важности;

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

- нахождение общего количества баллов для каждого из вариантов

- (можно с учетом важности критериев);

- лучшим считается вариант, который набрал максимальное количество баллов.

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

Решение поставленной задачи выбора методом вариантных сетей показано в таблице 4.1.

Таблица 4.1 - Решение задачи выбора средства разработки

Характеристика	1 (5)	2 (5)	3 (5)	4(5)	5(4)	6 (3)	У
Средство разработки
Delphi v 2007	5	5	5	5	4	5	131
Visual Studio 2005	4	4	4	4	5	4	112
Eclipse (Java 2 SE 5.0)	3	4	3	4	4	4	98

Вывод: в результате проведенного исследования получили, что лучшим инструментальным средством для разработки в рассматриваемом случае является Borland Delphi v 2007.

Приведем основные сведения выбранного нами инструментального средства Delphi.

Используя Delphi можно создавать приложения для MS Windows95/98/NT/2000/XP с минимальными затратами времени т.к. в её основе лежит концепция быстрого создания приложений (RAD).

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

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

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

Технология Two Ways Tools делает более эффективной работу с компонентами. При изменении программного кода в окне редактора Delphi соответствующим образом изменяет и сами компоненты. С другой стороны, при изменении свойств компонентов в инспекторе редактора объектов (Object Inspector) они немедленно отражаются в окне редактора кода.

Теперь произведем выбор СУБД

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

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

Наличие опыта разработки с использованием данного средства (5).

Требования к аппаратному обеспечению ( 5 ).

Скорость обработки информации ( 5 ).

Стоимость лицензии на использование ПО (5).

Скорость разработки программного продукта (4 ).

Удобство эксплуатации средства разработки (4).

В круглых скобках указана важность данной характеристики.

Среди современных доступных средств разработки серверной части данного программного продукта выделим следующие:[14]

- Firebird 2.5;

- MS SQL Server 2008;

- Oracle 10g XE.

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

Решение поставленной задачи выбора методом вариантных сетей показано в таблице 4.2.

Таблица 4.2 - Выбор СУБД

Характеристика	1 (5)	2 (5)	3 (5)	4(5)	5(4)	6 (4)	У
СУБД
Oracle 10gXE	5	5	4	5	4	5	131
FireBird 2.5	4	4	5	4	5	5	125
MS SQL Server 2008	4	5	4	5	4	4	122

Вывод: в результате проведенного исследования получили, что лучшим сервером баз данных для разработки данного программного продукта является Oracle 10gXE.

4.2 Архитектурное проектирование ПО подсистемы классификации заемщика при оформлении потребительских кредитов

Разрабатываемая подсистема подсистемы классификации заемщиков при оформлении потребительских кредитов должна быть частью автоматизированной банковской системы, используемой в Полтавском ГРУ АКБ «Приватбанк», архитектурная схема которой приведена на рисунке 4.1 с указанием места разрабатываемой подсистемы

Архитектурная схема подсистемы классификации заемщиков при оформлении потребительских кредитов представлена на рисунке 4.2.

Рисунок 4.1 - Архитектурная схема автоматизированной банковской системы Полтавского ГРУ

Рисунок 4.2 - Архитетурная схема ПО подсистемы классификации заемщиков при оформлении потребительских кредитов

Размещено на http://www.allbest.ru/

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

4.2.1 Метод проектирования

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

4.2.2 Описание декомпозиции

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

Рисунок 4.3 - Дерево декомпозиции задачи, полученное нисходящим методом проектирования

Размещено на http://www.allbest.ru/

4.2.3 Описание компонент

Главный модуль.

Тип: программный модуль.

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

Подчиненность: находится в верхнем уровне иерархии подзадач.

Зависимости: модуль осуществляет вызов всех остальных программных модулей системы.

Модуль авторизации.

Тип: программный модуль.

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

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному.

Алгоритмы: реализует базовый алгоритм управления интерфейсами

(рис. 3.1).

Интерфейсы: модуль имеет связь с модулем управления интерфейсами.

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

Тип: программный модуль.

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

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному.

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

Модуль организации связи с базой данных.

Тип: программный модуль.

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

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному.

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

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

Тип: программный модуль.

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

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному модулю.

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

Модуль редактирования справочников.

Тип: программный модуль.

Назначение: Данный модуль предназначен для редактирования информации о РОВД, ГНИ, предприятиях и организациях, схемах кредитования.

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному модулю.

Интерфейсы: модуль организует интерфейс редактирования данных о РОВД, ГНИ, предприятиях и организациях, схемах кредитования.

Модуль редактирования пользователей.

Тип: программный модуль.

Назначение: модуль реализует интерфейс изменения сведений о сотрудниках отделения, а именно фамилии, имени, отчества и должности сотрудника.

Подчиненность: находится во втором уровне иерархии подзадач, будучи подчинен главному модулю.

Интерфейсы: организует интерфейс изменения данных о сотрудниках.

Редактирование данных о схемах кредитования.

Тип: подпрограмма.

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

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

Интерфейсы: организует интерфейс изменения данных о схемах кредитования.

Редактирование данных о РОВД.

Тип: подпрограмма.

Назначение: подпрограмма реализует интерфейс изменения данных о РОВД - органе выдачи паспорта.

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

Интерфейсы: организует интерфейс изменения данных о РОВД.

Редактирование данных о ГНИ.

Тип: подпрограмма.

Назначение: подпрограмма реализует интерфейс изменения данных о ГНИ - органе выдачи идентификационного кода.

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

Интерфейсы: организует интерфейс изменения данных о ГНИ.

Редактирование данных о предприятиях и организациях.

Тип: подпрограмма.

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

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

Интерфейсы: организует интерфейс изменения данных о предприятиях и организациях.

Редактирование заявок.

Тип: набор подпрограмм.

Назначение: данный набор подпрограмм реализует интерфейс редактирования заявок, в котором вводятся данные о заемщике.

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

Интерфейсы: организует интерфейс редактирования заявок.

Анализ заявки.

Тип: набор подпрограмм.

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

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

Интерфейсы: организует интерфейс анализа заявки.

Редактирование общих данных.

Тип: набор подпрограмм.

Назначение: данный набор подпрограмм реализует интерфейс для ввода общих данных по заемщику (паспорт, ИНН, дата рождения и проч.)

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

Интерфейсы: организует интерфейс редактирования общих данных.

Редактирование финансовых показателей.

Тип: набор подпрограмм.

Назначение: данный набор подпрограмм реализует интерфейс для ввода финансовых показателей заемщика.

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

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

Редактирование данных о месте работы.

Тип: набор подпрограмм.

Назначение: данный набор подпрограмм реализует интерфейс для ввода данных о месте работы заемщика.

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

Интерфейсы: организует интерфейс редактирования данных о месте работы заемщика.

Редактирование данных о семейном положении.

Тип: набор подпрограмм.

Назначение: данный набор подпрограмм реализует интерфейс для ввода данных о семейном положении заемщика.

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

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

Классификация заемщика.

Тип: набор подпрограмм.

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

Алгоритмы: алгоритм вычисления удельной суммы выплат по кредиту к сальдо бюджета заемщика, алгоритм анализа социального статуса заемщика, алгоритм анализа финансовых показателей заемщика, алгоритм классификации заемщика (рис. 3.2-3.5).

Подчиненность: находится в третьем уровне иерархии подзадач, будучи подчинен модулю управления интерфейсами.

Интерфейсы: организует интерфейс классификации заемщика.

4.4 Детальное проектирование по подсистемы классификации заемщика при оформлении потребительских кредитов

4.4.1 Стандарты проекта

Подсистема подсистемы классификации заемщика при оформлении потребительских кредитов «ПОТРЕБ-КРЕДИТ» разработана в соответствии со стандартами ДСТУ 3918-1999 и SO/IEC 16326.

4.4.2 Стандарты документации

Разработка документации подсистемы классификации заемщика при оформлении потребительских кредитов «ПОТРЕБ-КРЕДИТ» осуществлена на основе требований международных стандартов серии ISO/IES 12207.

4.4.3 Соглашения по наименованиям

Имя выполняемого файла - Credit.exe.

Основной модуль - Credit.dpr.

Модуль управления интерфейсами - Main.pas.

Модуль авторизации - Autorize.pas.

Модуль редактирования справочников - BaseTab.pas.

Модуль редактирования пользователей - UserEdit.pas.

Модуль организации связи с базой данных Datamod.pas.

Модуль выдачи справочной информации About.pas.

4.4.4 Инструментальные средства разработки

При разработке подсистемы классификации заемщиков при оформлении потребительских кредитов «ПОТРЕБ-КРЕДИТ» использована среда интегрированной разработки Borland Delphi Enterprise 2007. Для построения серверной части ПП использовалась СУБД Oracle XE. Серверная часть была построена с помощью Case средства Data Modeller 4.12.

4.4.5 Описание программных модулей

Структурная схема подсистемы классификации заемщиков при оформлении потребительских кредитов «ПОТРЕБ-КРЕДИТ» представлена на рисунке 4.4.

Рисунок 4.4 - Структурная схема ПО подсистемы оценки кредитоспособности заемщиков при оформлении потребительских кредитов «ПОТРЕБ-КРЕДИТ»

Рассмотрим подробнее назначение модулей, входящих в подсистему.

ОСНОВНОЙ МОДУЛЬ (CreditTNP.dpr) представляет собой файл проекта. Он предназначен для объединения остальных модулей, для обеспечения связи между ними, управления работой программного продукта в целом.

МОДУЛЬ УПРАВЛЕНИЯ ИНТЕРФЕЙСАМИ (Main.pas) представляет собой главную форму программы на которой расположены закладки и основные элементы управления интерфейсами организации работы кредитного инспектора, связанную с анализом заявки, классификацией заемщика, регистрацией заявки.

МОДУЛЬ СВЯЗИ С БАЗОЙ ДАННЫХ (Datamod.pas) содержит в себе совокупность наборов и источников данных для связи с соответствующими таблицами БД Oracle и двусторонней передачи данных из БД в клиентское приложение и обратно.

МОДУЛЬ АВТОРИЗАЦИИ ПОЛЬЗОВАТЕЛЕЙ (Autorize.pas) представляет собой форму, на которой расположены поля ввода входного имени и пароля. Осуществляет проверку регистрации пользователя в системе и прав доступа в систему. Запускает модуль управления интерфейсами.

МОДУЛЬ РЕДАКТИРОВАНИЯ СПРАВОЧНИКОВ (BaseTab.pas) представляет собой форму на которой расположены навигационная панель перехода к разнообразным справочникам, и таблиц отображения содержимого таблицы БД справочников, кнопки для добавления изменения и удаления позиций. Доступен исключительно в режиме работы Администратора.

МОДУЛЬ РЕДАКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЕЙ (UserEdit.pas) представляет собой форму на которой расположены основные элементы управления для редактирования содержимого таблиц пользователей программы. Доступен исключительно в режиме работы Администратора.

МОДУЛЬ ОТОБРАЖЕНИЯ СПРАВОЧНОЙ ИНФОРМАЦИИ (About.pas) представляет собой форму на котором расположено поле вывода текста, содержащее информацию о версии программного продукта, о разработчике, а также информацию о способах получения технической поддержки.

Экранные формы графического интерфейса представлены в Приложении А.

Выводы по разделу 4

В ходе проектирования ПО был проведен выбор и обоснование средств разработки. В качестве средства разработки клиентской части выбрана интегрированная среда разработки приложений - Borland Delphi 2007. В качестве СУБД выбран Oracle, версии 10gXE. Было проведено архитектурное и детальное проектирование ПО, всего разработано 7 модулей.

5. Верификация и валидация программного обеспечения подсистемы классификации ЗАЕМЩИКА ПРИ ОФОРМЛЕНИИ ПОТРЕБИТЕЛЬСКИХ КРЕДИТОВ

5.1 Введение

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

1 Тестирование (testing) - процесс выполнения программы или части программы, с намерением или целью найти ошибки.

2 Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и затем вывод и доказательство математических теорем о правильности программы.

3 Контроль (verification) - попытка найти ошибки в тестовой, или моделируемой среде.

4 Испытание (validation) - попытка найти ошибки, выполняя программу в заданной реальной среде.

5 Аттестация (certification) - авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторыми заранее определённым стандартом.

6 Отладка (debugging) не является разновидностью тестирования. Хотя «отладка» и «тестирование» часто используются как синонимы, под ними подразумеваются разные виды деятельности. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки [18].

5.1.1 Объекты испытаний

При тестировании программного продукта «Программное обеспечение подсистемы оценки классификации заемщика при оформлении потребительских кредитов» можно выделить два объекта испытаний:

- БД, разработанная при помощи СУБД Oracle 10g XE;

- клиентская часть программы, разработанная при помощи Delphi 2007.

5.1.2 Цель испытаний

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

Цель тестирования клиентской части:

- проверке корректности настройки сервера Oracle 10g XE;

- проверке наличия соединения между компьютером пользователя и сервером БД Oracle 10g XE;

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

Критерии завершения тестирования

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

График выполнения тестирования

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

- тестирование настройки сервера БД;

- тестирование соединения между клиентской частью и

- сервером БД;

- тестирование клиентской части.

5.2 Задачи, реализованные при создании системы

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

- проектирование и создание БД учета оптово-розничных продаж;

- разработка алгоритмов работы системы администрирования СУБД учета оптово-розничных продаж;

- разработка клиентского интерфейса для доступа к процедурам выполняющим манипулирования данными в СУБД.

5.3 Требования к программной документации

На испытания программы должна быть предъявлена следующая документация:

- техническое задание;

- техническое предложение.

5.4 Краткий обзор верификации программного продукта

Верификация обозначает:

- действие по проверке, инспекции, тестированию, контролю элементов, процессов и устройств, определённых требованиями ANSI -78;

- процесс определения удовлетворяют ли продукты данной фазы жизненного цикла (ЖЦ) программного обеспечения ПО требованиям, сформулированным ранее;

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

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

5.5 Процессы верификации

Процессы верификации включают:

- технические проверки, сквозные контроли и инспекции ПО;

- проверка того, что требования к ПО являются трассируемыми к требованиям пользователя;

- проверка того, что компоненты проекта являются трассируемыми к требованиям к ПО;

- формальные доказательства и алгоритмы проверки;

- автономное тестирование;

- интеграционное тестирование;

- системное тестирование;

- приёмочное тестирование;

- ревизии.

5.5.1 Проверки, сквозные контроли и инспекции ПО

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

В процессе верификации было использовано 3 вида проверок ПО:

- техническая проверка;

- сквозной контроль;

- инспекция ПО.

Все три вида проверок являются "формальными проверками" в том смысле, что все они имеют особые цели и процедуры. Все виды проверок стремятся определить дефекты и несоответствия ПО спецификациям, планам и стандартам.

Технические проверки использовались в фазах ОТП, ОТ, АП и ДП с целью оценки конкретных элементов ПО для сравнения их со стандартами, спецификациями.

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

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

5.5.2 Автономные тесты

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

Автономные тесты включают тестирование методом "чёрного ящика" и тестирование методом "белого ящика".

Автономные тесты проверяют наличие существования модуля, выполняющего то, что подразумевается (тестирование "чёрного ящика"), но также и то, что это выполняется заданным способом (тестирование "белого ящика").

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

- покрытие операторов;

- покрытие решений (покрытие переходов);

- покрытие условий;

- покрытие решений/условий;

- комбинаторное покрытие условий.

Методология "чёрного ящика" позволяет выбрать для тестирования наиболее подходящее подмножество входных данных. Это достигается за счёт применения следующих методик:

- эквивалентное разбиение;

- анализ граничных значений;

- применение функциональных диаграмм;

- предположение об ошибке.

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

5.5.3 Интеграционные тесты

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

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

5.5.4 Системное тестирование

Системное тестирование является процессом тестирования объединённой системы ПО. Это тестирование проводится в среде разработки или в целевой среде.

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

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

Для проведения этого теста непрерывно заполнялась БД записями до тех пор, пока не последовала выдача сообщения о нехватке места на диске. При этом не отмечалось существенного замедления в работе программы. Свободное место на диске - 300 Mb. Число занесённых записей - 1243217.

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

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

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

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

- процессор- Celeron 1.7 GHz;

- оперативная память (ОП) - 512 MБ;

- 50 МБ свободного дискового пространства для ПП и 300 МБ для таблиц БД;

- видеопамять -512.

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

Для проведения теста защиты БД от несанкционированного доступа, была попытка открытия БД с помощью постороннего редактора (IBEXPERT) во время сеанса работы программы. В результате проведения теста был выдан отказ в доступе к БД постороннему пользователю.

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

Для выполнения этого теста программа выполнялась на оборудовании с минимально необходимой конфигурацией. Время доступа к данным с пяти машин удовлетворяло временным требованиям ПО (не более 2 сек).

Тестирование надёжности. Ключевой момент в комплексном тестировании заключается в попытке доказать, что система не удовлетворяет исходным требованиям к надёжности (среднее время между отказами, количество ошибок, способность к обнаружению, исправлению ошибок и/или устойчивость к ошибкам).

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

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

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

5.6 Набор тестов

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

Таблица 5.1 - Набор тестов для серверной части ПП

№ теста	Входные данные (режимы работы)	Ожидаемый результат	Назначение теста
1	Insert into Credit (shemaID, goodamount, prepaidamount) values(1,1850, 119)	Добавление данных в таблицу Credit	Проверка работы генератора Gen_Credit_ID и триггера Credit_BI0
2	Insert into ROVD (ROVDName) values (' `Павлограским ГОУМВД Украины в Днепроп. области')	Добавление данных в таблицу ROVD	Проверка работы генератора Gen_ROVD_ID и триггера ROVD_BI0
3	Insert into User (ULName, UFName) values (`Гуцу',`Ганна')	Добавление данных в таблицу User	Проверка работы генератора Gen_User_ID и триггера User_BI0
4	Select Lname, Fname, MName from Client where ID=12	Выдача ФИО клиента, оформляющего заявку с кодом 12	Проверка ссылочной целостности таблиц Client и Credit
5	Delete from Credit where ID=11	Удаленнее записи из всех таблиц, связанных с Credit	Проверка каскадного удаления данных из связанных таблиц.
6	Insert into Estate Values(12, 3,'ул. Ленина 18'1,58, )	Добавление сведений о недвижимости клиента с кодом 12	Проверка правильности передачи параметров в таблицу Estate
7	Update Client set GNID=19, ROVDID=3 where ID=12	Ошибка - введен неверный код РОВД	Проверка ссылочной целостности таблиц Client, GNI и ROVD

В таблице 5.2. приведен перечень тестов для клиентской части системы.

Таблица 5.2 - Перечень тестов для клиентской части системы

№ теста	Входные данные (режимы работы)	Ожидаемый результат	Назначение теста
1	Запуск приложения. Ввод в поле пароля «111». Нажатие на кнопку «Ввод»	Выдача ошибки о не заполнении поля ввода входного имени	Проверка работы процедуры входа в систему
2	Запуск приложения. Ввод в поле пароля «2345456» Нажатие на кнопку «Вхід»	Выдача ошибки о неверном пароле	Проверка работы процедуры входа в систему
3	Запуск приложения. Ввод в поле пароля «history». Нажатие на кнопку «Вхід»	Загрузка основной формы системы	Проверка работы процедуры входа в систему
4	Просмотр данных о последней заявке. Нажатие на кнопку «Редагувати»	Подсветка полей ввода данных о заявке.	Проверка возможности редактирования данных
5	Редактирование данных о последней заявке. Нажатие на кнопку «Видалити»	Выдача сообщения с Предупреждением об удалении пользователя	Проверка выдачи предупреждения
6	Ввод в данных на странице анализа заявки	Вывод сообщения о сумме удельного веса сальдо баланса к ежемесячной сумме выплат.	Проверка алгоритма вычисления удельного веса сальдо баланса к ежемесячной сумме выплат.
7	Ввод в данных на странице финансовых показателей	Вывод сообщения о величине интегрального показателя финансового состояния заемщика	Проверка алгоритма анализа финансового состояния заемщика
8	Ввод в данных на странице места работы, семейного положения	Вывод сообщения о величине показателя социального статуса заемщика	Проверка алгоритма анализа социального статуса заемщика

5.7 Модель надежности программного продукта

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

- определены критерии тестирования;

- определены категории и направлении проведения тестирования;

- проведено тестирование ПО методом белого ящика.

В процессе тестирования было использовано 53 наборов входных данных. Число наборов входных данных, при которых были обнаружены ранее не выявленные ошибки, равно 2.

Эффективность выполнения тестирования определим по формуле:

, (5.1)

где N-количество тестов;

N_отк- количество отказов.

Таким образом : .

5.8 Отладка

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

Отладка серверной части программного продукта была произведена средствами среды SQL Navigator v 6.0., являющийся программной надстройкой для СУБД Oracle

Отладка клиентской части программного продукта была произведена средствами среды разработки Delphi 2007

Выводы по разделу 5

Результат анализа испытания показал, что:

- программа выполняет все необходимые проверки при некорректных входных данных стандартными средствами среды разработки;

- при аварийном отключении сохраняет максимально возможное количество данных;

- в программе реализована защита данных от несанкционированного доступа;

- программа корректно обрабатывает данные при работе с большими объемами;

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

6. экономическое обоснование разработки ПО подсистемы классификации заемщиков

6.1 Резюме

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

- процессором Core i5 2.0 GHz;

- 1 Gb ОЗУ;

- НЖМД -320Гб;

- видеоадаптером SVGA 256 Mб.

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

- затраты на разработку программного продукта составили

- 1378,25 гривен;

- предполагаемое количество продаж составляет 54 копии, в том числе:

- 1-й год - 18;

- 2-й год -20;

- 3-й год - 16.

6.2 Описание характеристик продукта

6.2.1 Характеристика продукта

Наименование программного продукта - «Кредит-ТНП».

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

При работе с системой пользователь должен иметь навыки работы с операционными системами типа Windows на персональных компьютерах. Эксплуатация ПО должна проходить на вычислительной машине с процессором типа Celeron не менее 1.7 GHz, необходимо иметь в наличии 50Мбайт свободного дискового пространства и 512 Мбайт оперативной памяти.

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

6.2.2 Особенности товара

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

6.2.3 Система сервиса

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

6.2.4 Патентная чистота

При разработке программного продукта использовались лицензионные версии операционной системы Windows XP Professional, СУБД Oracle 10g XE, case-средство Computer Associated Data Modeler 4.12.

6.2.5 Гарантии и защита прав потребителя

Гарантируется получение в обусловленные договором сроки надежного, эффективного и простого в эксплуатации программного обеспечения («Кредит-ТНП»).

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

6.3 Исследование и анализ рынков сбыта

6.3.1Сегментация рынка по потребителям

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

Таблица 6.1 - Предполагаемые объемы продаж

Период	Потребители	Количество продаж ПП	Потенциальный покупатель
1	2	3	4
Первый год реализации
Январь	Харьков	2	ЦО «Приватбанк», ЦО «Надра»
Февраль	Харьков	1	ЦО «Укрисббанк»
Март	Харьков	1	Филиал «Укроцбанк»
Апрель	Ахтырка	1	Филиал «Приватбанк»
Май	Харьков	2	Филиал «Приватбанк», филиал «Прокредитбанк»
Июнь	Сумы	2	ЦО «Приватбанк», ЦО «Надра»
Июль	Мариуполь	2	ЦО «Укрсиббанк», ЦО «Аваль»
Август	Харьков	1	Филиал «Газбанк»
Сентябрь	Полтава	1	ЦО «Надра»
Октябрь	Сумы	2	Филиал «Аваль», филиал «Надра»
Ноябрь	Харьков	1	ЦО «Аваль»
Декабрь	Тростянец	2	ЦО «Аваль», филиал «Приватбанк»
Всего		18
Второй год реализации
1 квартал		5
2 квартал		4
3 квартал		5
4 квартал		6
Всего		20
Третий год реализации
Всего		16

6.3.2 Анализ конкурентоспособности

Аналогом данного программного продукта на исследуемом рынке является система «Банк-Кредит», используемая в отделах корпоративных кредитов.

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

Основными показателями качества программного продукта являются:

- экономические показатели;

- требования к аппаратным средствам;

- требования к программным средствам;

- функциональные возможности.

Опишем методику вычисления показателей качества.

Показатели делятся на минимизируемые и максимизируемые. Минимизируемые показатели рассчитываются по формуле:

, (6.1)

где K_ij - относительное значение i-го показателя для j-го варианта;

Р_ij - абсолютное значение I-го показателя для j-го варианта;

Р_ijгип - абсолютное значение I-го показателя для гипотетического варианта.

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

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

. (6.2)

Затем рассчитываются уровни качества нового программного продукта по сравнению с изделиями-конкурентами (j-ми вариантами):

. (6.3)

Обобщенный показатель качества является уровнем качества рассматриваемого j-го варианта к гипотетическому.