Диплом: Разработка прототипа ПО на примере личного кабинета клиента по факторингу (на примере ООО "Открытие Факторинг")

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
38
Способ
приобретения
\ критерии
Покупка
готовой
системы
Разработка
ИС отделом
разработки
Аутсорсинг
Покупка
системы и её
доработка
отдельный
контракт с
вендором
своими
силами
сопровождени
е системы
изменения
процессов
Надежность
Надежность и
исправление
багов фирмой
разработчиком
Высокая.
Есть
внутренний
ресурс для
тестирования
и обкатки
системы на
ограниченно
м контуре
Надежность
гарантируется
фирмой-
разработчико
м ИС
Низкая.
Доработка
незнакомой
системы
можем вызвать
неожиданные
последствия.
Сложно
протестироват
ь изменения
Покупка готовой системы и её внедрение на предприятии не подходит под
задачу дипломной работы и требования компании.
Покупка системы и её доработка: покупка системы на рынке. Система должна
быть с открытым кодом, и лицензией позволяющей доработку системы для нужд
компании. Доработка системы идет силами внутреннего отдела разработки, для
этого язык и основной стек системы должен совпадать с принятыми в компании.
Аутсорсинг разработки системы требует довольно больших затрат со стороны
менеджмента компании: подбор компании подрядчика, подготовка ТЗ и контроль
выполнения. В нашем случае этот вариант не подходит в первую очередь из-за
необходимости раскрытия внутренних особенностей работы финансовой компании
третьи лицам, что может повлечь за собой мошеннические действия со стороны
аффилированных с аутсорсинговой компанией лиц.
Разработка: создание системы силами внутреннего отдела разработки
позволяет исполнить все требования компании, при этом учесть и не нарушить
ограничения. Этот вариант и был выбран мной для данной дипломной работы.
39
1.4. Обоснование проектных решений
Программное обеспечение (ПО) - совокупность программ системы обработки
информации и программных документов, необходимых для эксплуатации этих
программ [6]. ПО предназначено для придания вычислительной системе
определенных свойств, связанных с увеличением производительности, повышением
достоверности получаемых результатов, повышением надежности
функционирования системы, улучшения работы пользователя.
В рамках решения задачи веб-сайт был выбран как единственный способ
взаимодействия с пользователем. Это не требует установки и настройки рабочий
мест сотрудников, т.к. текущие рабочие места уже обладают необходимыми
характеристиками:
ОС Windows 10 Pro;
Браузер Firefox и Google Chrome;
Достаточный уровень доступа в интернет и к корпоративным ресурсам.
Критериями выбора архитектуры реализации проектируемого Программного
Комплекса являются:
совместимость с существующей инфраструктурой серверов;
возможность создания резервных копий данных;
интерфейс для просмотра статистки по всем заявкам.
В качестве серверной ОС в компании используется Windows Server 2016. За
хранение данных отвечает базы данных MS SQL Server 2016. Сервера и базы данных
находятся в защищенном периметре, бэкапируются на уровне виртуальных машин и
данных. Серверные мощности для развертывания новой системы будут выделены из
текущего свободного пула, это позволяет сократить расходы на проект.
Подход к хранению и обработке данных. Предсказуемая рабочая нагрузка,
характеристики серверов компании и технологический стек позволяют отказаться от
хранимых процедур, триггеров и другой логики на уровне базы данных. Для проекта
будет создана отдельная база данных для упрощения обслуживания и развития
структуры базы (миграция схемы, структуры и содержимого базы данных).
40
1.4.1. Обоснование проектных решений по информационному обеспечению
Информационное обеспечение (ИО) включает в себя:
систему классификации и кодирования;
систему стандартизированной документации;
информационную базу.
Классификатор - это систематизированный свод наименований группировок
объектов, признаков и их кодовых обозначений. Классификаторы служат средством
описания данных, сохраняют единство классификации и кодирования информации.
Предназначены классификаторы для обеспечения машинной обработки и выдачи
данных в удобной форме потребителям при решении различных задач. В
зависимости от применения они делятся на три группы:
общегосударственные классификаторы,
отраслевые (ведомственные) классификаторы, используемые в пределах
определенной отрасли (ведомства);
локальные классификаторы, используемые в пределах организации или
группы организации.
В данном дипломной работе будет использоваться локальный классификатор, так
как никаких других классификаторов РФ на текущий момент не используется.
Классифицировать будем признаки заявок на факторинг. Для решения поставленной
задачи и оценки качества её решения предлагается использовать следующие
классификаторы:
по каналу привлечения клиента,
по сумме запрашиваемого лимита,
по типу продукта (факторинг с регрессом или факторинг без регресса).
Документация – это печатные руководства пользователя, диалоговая
(оперативная) документация и справочный текст, описывающие, как пользоваться
программным продуктом. В современных условиях развития продуктов необходимо
быстро принимать во внимание изменения условий рынка, и вносить изменения в
ИС.
Для сохранения высокой скорости и качества автоматизации важное значение
придается документации. Стандартный подход, и его соблюдение во всех проектах
внутри компании, позволяет установить единые требования к содержанию и
41
построению документов. Стандартизированные формы документов существуют для
всех предприятий РФ (как пример, формы налоговой отчетности), и для отдельных
предприятий (например, формы управленческой отчетности). Унификация
заключается в тщательном отборе и четком определении необходимой
номенклатуры документов, их полей форматов описания и жизненного цикла
документов. При этом определяются сферы назначения и применения документов, а
также специфические особенности, характерные для соответствующих видов
документов, отраслей бизнеса или этапов его развития. Документы могут быть как
унифицированными, так и локальными.
Далее мы будем использовать следующие локальные документы: «Заявка на
факторинг» (от клиента), «Заявка на регистрацию в ЛК» (от сотрудника компании),
«Заявка на проведение оценки рисков по контрагенту» (от менеджера по заявке к
риск-менеджеру), «Заявка на выдачу дополнительных прав доступа в ЛК» ().
Ко всем видам заявок применяются следующие требования:
полнота информации (заполнение обязательных полей);
достоверность информации (при отправке заявок пользователь
предупреждается об ответственности за переданную информацию);
стандартный шаблон документа (заявки принимаются строго по
установленному шаблону, в бумажной или электронной форме);
Существует три модели логической структуры базы данных (по способу
установления связей между данными): иерархическая, сетевая и реляционная.
В иерархической модели каждой информационной единице (сегменту), кроме
корневого, соответствует один исходный сегмент и между исходным и
порожденным сегментом устанавливается только одна связь. В иерархических
моделях экземпляру исходного сегмента соответствует в общем случае какое-то
число экземпляров порожденного сегмента. Такие структуры удобны для
отображения отношений типа «один ко многим» в предметной области. Просмотр
иерархической структуры возможен только с корневой вершины. Пропуск сегмента
в иерархическом пути при доступе к заданному сегменту не допускается. Основные
недостатки иерархической структуры: трудность (неэффективность) отображения
отношений типа «многие ко многим»; длительность доступа к сегментам,
42
находящимся на нижних уровнях иерархии; ориентированность на определенный
тип (разрез) запроса.
Сетевые модели графически отображаются в виде графа. Вершинам графа
соответствуют составные единицы информации (записи). Экземпляры записей
образуют файлы. Структура записи может быть иерархической или линейной в
зависимости от системы. Между парой типов записей может быть объявлено
несколько связей, имена и направления связей должны быть четко обозначены.
Недостатками являются: сложность (очень большое число параметров описания
данных и операторов), а также неудобство навигационного доступа.
Реляционная БД представляет собой совокупность схем отношений,
связанных друг с другом. Реляционная модель данных – позволяет представлять
информацию о предметной области с помощью взаимосвязанных таблиц. В
реляционных базах данных вся информация сведена в таблицы, строки и столбцы
которых называются записями и полями соответственно. Эти таблицы получили
название реляций. Записи в таблицах не повторяются. Их уникальность
обеспечивается первичным ключом, содержащим набор полей, однозначно
определяющих запись. Преимущества использования реляционных базы данных
состоит в следующем:
простота - в реляционной модели данных существует всего одна
информационная конструкция, которая формализует табличное
представление данных, привычное для пользователей;
теоретическое обоснование - наличие теоретически обоснованных методов
нормализации отношений позволяет получать базы данных с заранее
заданными свойствами (в основном, с гарантией минимальной избыточности
представления данных);
реляционная модель данных отображает информацию в наиболее простой для
пользователя форме
модель основана на развитом математическом аппарате, который позволяет
достаточно лаконично описать основные операции над данными.
Основная терминология баз данных:
предметная область - часть реального мира, которая моделируется средствами
реляционной базы данных. Как правило, предметная область имеет сложную
43
структуру и не упорядочена. В данном дипломном проекте это отражение
факторинговых процессов и регламента запуска сделки с клиентом через
заявку на факторинг.
модель данных — это концептуальное описание предметной области. Она
включает в себя определения сущностей и атрибутов. Например, сущность
"базовая станция" может включать в себя атрибуты "номер",
"месторасположение" и т.п., сущность заказчик - "номер", "наименование",
"адрес". В модель данных включаются также ограничения для сущностей,
например, номер может быть только числовым, а название не может быть
пустым значением. В ней также описываются связи между сущностями,
например, заказчиками и заказами. Модель данных не содержит в себе
указаний на физическую модель самой системы.
схема базы данных — это перевод концептуальной модели данных на язык
базы данных, например, определения таблиц и представлений. Это - понятие,
которое относится к концептуальному, а не физическому уровню.
Современные базы данных скрывают физическую реализацию этой модели -
нам не нужно думать про страницы БД, B-tree и т.п. Достаточно реализовать
модель данных по общепринятым в отрасли правилам.
ядро (database engine) - это программный механизм, обеспечивающий работу
с базой данных для приложений и пользователей, например, ядро Jet, ядро
SQL Server и т.п. Он обеспечивает физическое манипулирование данными:
хранение на диске и извлечение по запросу и чтение данных. Именно на
чтение (select операцию) приходится большая часть запросов, это
справедливо для проектов по автоматизации деятельности предприятия.
объектные модели (ADO, ADO.NET, RDO, DAO и т.п.) - это наборы
взаимосвязанных объектов, которые используются для упрощения доступа к
данным в базах данных из приложений. Напрямую с базами данных через API
работать неудобно, поэтому эти объектные модели используются очень
широко. В данной работе для работы с базой данных применяется ORM – это
надстройка над РБД (реляционной базой данных), позволяющая
программисту строить более осмысленную систему на основе объектов,
44
сосредоточив внимание на манипуляциях с объектами и описанием их
поведения как реакции на воздействия. [7]
Исходные сведения для решения обозначенной задачи получают из таких
документов, как:
Регламент работы с клиентами
KPI по подразделениям коммерческого блока
Регламент по запуску и обслуживанию факторинговых сделок
Заявка с лэндинга (форма и поля заявки по внутренним правилам компании)
Результаты решения задачи отображаются в таких отчетах и документах, как:
Отчет по скорости обработки заявок, по сотрудникам
Отчет по скорости обработки заявок, по отделам
Отчет по текущему состоянию заявок
Отчет по конверсии заявок в сделку
1.4.2. Обоснование проектных решений по программному обеспечению
Для функционирования системы в продакшен режиме необходимы:
Кластер из нескольких Windows машин (можно разместить на
существующем) для выполнения основного кода приложения. Приложение
для обработки заявок предполагается реализовать в виде отдельного
микросервиса.
Виртуальная машина с Linux, для установки NGINX. Основное назначение —
самостоятельный HTTP-сервер, или, как его используют чаще, фронтенд для
высоконагруженных проектов. Предполагается использование NGINX как
обратного TCP прокси-сервера.
Service Fabric Cluster. Это платформа распределенных систем, которая дает
возможность не только легко упаковывать и развертывать масштабируемые
надежные микрослужбы и контейнеры, но и управлять ими. Service Fabric
также позволяет устранить значительные трудности, возникающие при
разработке собственных приложений и управлении ими. Получая
гарантированную масштабируемость, надежность и управляемость,
разработчики и администраторы могут сосредоточиться на реализации
критически важных и ресурсоемких рабочих нагрузок вместо того, чтобы
45
тратить силы на решение сложных проблем с инфраструктурой. Service Fabric
— это принципиально новая платформа, позволяющая создавать облачные
высококлассные приложения уровня 1, выполняющиеся в контейнерах, и
управлять ими.
Отдельная база данных MS SQL, которая будет хранить всю информацию
проекта. Выделенный сервер не нужен, нагрузка на систему предсказуемая и
невысокая, поэтому база будет размещена на текущих мощностях компании.
Это система управления реляционными базами данных (СУБД),
разработанная корпорацией Microsoft. Основной используемый язык запросов
Transact-SQL.
В программном решении Service Fabric есть много вариантов управления
работой и циклом развития сервисов и приложений, созданных на базе
микросервисного подхода. Микросервисы, после перемещения в кластер Service
Fabric развертываются и переходят в активное состояние. Учитывая, что
используются не виртуальные машины, а контейнеры мы можем рассчитывать на
высокую плотность размещения служб на существующих мощностях. Еще
большего увеличения плотности можно достичь если заменить использование
самих контейнеров на микрослужбы в этих контейнерах. В дополнение
платформа содержит весь спектр функций для управления микросервисами,
которые позволяют подготавливать, развертывать, проводить мониторинг и
обновление приложения. А встроенная возможность вывести сервис из
эксплуатации позволяет полностью поддерживать жизненный цикл приложения
или сервиса на базе Service Fabric
Например, один кластер облачной базы данных SQL Azure состоит из
десятков или сотен серверов с тысячами контейнеров, на которых развернуты
сотни тысяч баз данных. Каждая из перечисленных баз это микрослужба Service
Fabric с сохранением состояния. [8]
46
1.4.3. Обоснование проектных решений по техническому обеспечению
Под техническим обеспечением понимают состав, формы и способы
эксплуатации различных технических устройств, необходимых для выполнения
информационных процедур: сбора, регистрации, передачи, хранения, обработки и
использования информации.
К элементам технического обеспечения относятся: комплекс технических
средств, организационные формы использования технических средств, персонал,
который работает на технических средствах, инструктивные материалы по
использованию техники.
Комплекс технических средств — это совокупность взаимосвязанных
технических средств, предназначенных для автоматизированной обработки данных.
Требования к комплексу технических средств:
минимизация затрат на приобретение и эксплуатацию;
надежность, защита от сбоя, отказоустойчивость;
защита от неправомерного доступа;
Рассмотрим основные подходы для обеспечения необходимого уровня
отказоустойчивости:
Кластер серверов (Server Cluster) — это определенное количество серверов,
объединенных в группу и образующих единый ресурс. Данное решение позволяет
существенно увеличить надежность и производительность системы.
Сгруппированные в локальную сеть несколько компьютеров можно назвать
аппаратным кластером, однако, суть данного объединения — повышение
стабильности и работоспособности системы за счет единого программного
обеспечения под управлением модуля (Cluster Manager).
Общая логика кластера серверов формируется на уровне программных
протоколов и предоставляет способ:
управлять произвольным количеством аппаратных средств с помощью одного
программного модуля;
добавлять и усовершенствовать программные и аппаратные ресурсы, без
остановки системы и масштабных архитектурных преобразований;
обеспечивать бесперебойную работу системы, при выходе из строя одного
или нескольких серверов;
47
синхронизировать данные между серверами — единицами кластера;
эффективно распределять клиентские запросы по серверам;
использовать общую базу данных кластера.
По сути, основной задачей кластера серверов, можно назвать исключение или
радикальное сокращение простоя системы. Для пользователей системы, любой
инцидент, сбой, авария или другой тип вмешательства в стандартную работу систем
должен оставаться незамеченным и не оказывать влияния на производственный
процесс.
При проектировании систем с участием серверного кластера необходимо
учитывать возможности клиентского программного обеспечения по идентификации
кластера и совместной работе с командным модулем (Cluster Manager). В противном
случае вероятна ситуация, при которой попытка программы-клиента с помощью
модуля получить доступ к данным ресурса через другие сервера может получить
отказ (конкретные механизмы в данном случае зависят от возможностей и настроек
кластера и клиентского оборудования).
Второй важный аспект технического обеспечения — это надёжность хранения
данных. Технология RAID разработанная в 1980-х годах задумывалась как
объединение нескольких дисков в дисковый массив с целью увеличения емкости,
повышения надежности и доступности данных.
Рассмотрим вкратце основные уровни RAID:
RAID0: Чередование (Striping) Описание: Информация записана на все диски
равномерно, должно быть как минимум два диска.
RAID1: Зеркалирование (Mirroring) Данные записываются или считываются с
нескольких дисков одновременно.
RAID3: Чередование с выделенным диском чётности (Virtual disk blocks).
Информация побайтово распределяется между двумя дисками, а на третьем
сохраняется информация о четности. Третий диск идет как дополнительный, и
хранит только технические данные.
RAID4: Чередование с выделенным диском чётности (Dedicated parity disk).
Данные чередуются на уровне блоков. Необходим дополнительный диск, на котором
хранится информация о четности. Минимально три диска в массиве

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран