22
1.4.2. Обоснование проектных решений по программному
обеспечению
Были рассмотрены средства разработки приложений и программные аналоги по
рассматриваемой задачи.
Было принято решение разработать собственную систему. Для разработки
системы было решено выбрать стандартный стек используемый в банке. В банковской
отрасли уже несколько десятков лет доминирует разработка на Java.Java объектно-
ориентированный язык программирования имеет строгую типизацию. Для
стандартизации разработки в банке используются единые инфраструктурные и
программные подходы. Такой подход позволяет банку значительно экономить на
инфраструктуре и универсальной разработке, а также на поддержке своих программных
продуктов. В качестве золотого стандарта в области баз данных используется база данных
Oracle. В банковской деятельности значительное внимание уделяется стабильности и
сохранности данных, базы данных Oracle имеют все необходимые технологии для
предоставления высокого уровня безопасности и сохранности данных. Еще одной
весомой причиной использования базы Oracle – гибкая политика лицензирования. В
последние годы в разработке на Java доминирует фреймворк Spring.Простота
разворачивания, огромный набор готовых модулей и высокие стандарты безопасности
основные достоинства данного фреймворка. Так как разработка в банке строго
типизирована и применяются унифицированные решения, обоснований для применения
иных технологи нет.
Так как банк обладает большим количеством специалистов в данной области, не
составит труда поддержка и дальнейшее развитие данного программного продукта. Spring
Framework обладает следующими преимуществами:
Высокая скорость разработки информационных систем по
сравнению с аналогичными системами
Низкая цена разработки
Гибкость и кластеризация разработки
23
Модульность
Безопасность
Система инсталляций на любой корпоративный сервер
1.4.3. Обоснование проектных решений по техническому обеспечению
В процессе разработки нашей информационной системы мы будем использовать
технологию «пользователь-сервер». В первую очередь, это избавляет нас от
необходимости оптимизации рабочих станций, так как сервер оптимизирует выполнение
функций обработки данных, что позволяет нам быстро получить результаты обработки
запроса. Далее, существенно снижается нагрузка на сеть, так как рабочие станции не
обрабатывают все промежуточные данные, что дает нам возможность ведения журнала
операций, в котором автоматически регистрируются все прошедшие транзакции что, в
свою очередь, поможет быстрому восстановлению при системных сбоях. Данная
технология организуется проще, и оборудование для её организации вполне приемлемо
по стоимости приобретения.
Таким образом, проектируемая система с технической точки зрения будет
представлять собой корпоративный сервер приложений осуществляющий связь с базой
данных. Пользователи будут заходить в систему через веб-клиент.
Техническая архитектура приложения отображена на рис.6
24
Рисунок 6 – Техническая архитектура
Сервер базы данных
Конфигурация: IBM x3550 m4
Операционная система: REHL
База данных: Oracle 12c
Сервер приложений Openshift
Конфигурация: IBM x3550 m4
Операционная система: REHL
Веб-клиент
Конфигурация: 2.1 GHz/4GB/500GB
Операционная система: Windows 7/10
TCP/IP
HTTP/HTTPS
Сервер HP Service Manager
Конфигурация: IBM x3550 m4
Операционная система: REHL
Сервер базы данных
Конфигурация: IBM x3550 m4
Операционная система: REHL
База данных: Oracle 12c
TCP/IP
API
Сервер: Active Directory
Конфигурация: IBM x3550 m4
Операционная система: Windows Server 2016
TCP/IP
25
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл проекта – это процесс от создания продукта до его вывода
из эксплуатации, на сегодняшний момент в проектной деятельности существует
несколько стандартов:
ГОСТ 34.601-90 – предназначен для автоматизированных систем и
рассматривает этапы создания ПО. В стандарте рассмотрены и описаны все этапы
жизненного цикла ИС. Этапы работ в больше степени подходят под модель
каскадной разработки ПО.
ISO/IEC 12207 – Стандарт не содержит описания этапов разработки.
Больше направлен на организацию жизненного цикла.
Rаtionаl Unified Process – предполагает итеративный подход к разработке,
состоит из четырех фаз: начало, исследование, построение и внедрение. Фазы
разбиты на итерации, в результате которых становится доступна версия ПО для
внутреннего или внешнего использования. Прохождение всех фаз называется
циклом разработки, каждый из циклов завершается новой версией системы. Если
работа не прекащается происходит новый виток разработки. Основной смысл
работы в рамках RUP – это работа на базе UML .
Microsoft Solution Frаmework (MSF) похожа на RUP, включает четыре фазы:
анализ, проектирование, разработка, стабилизация и является итерационной. MSF
в большей степени направленна на разработку бизнес-приложений.
Гибкая методология разработок - Agile software development, — идеология,
направленная на итеративную разработку, динамическое формирование
требований ,а так же обеспечение их реализации в результате взаимодействия
внутри рабочих групп самоорганизующихся и состоящих из специалистов
различного профиля. Основные методики относятся к гибкой методологии
разработки, к примеру XP, BDD, DSDM, FDD ,Scrum.
26
Agile применяется для организации труда небольших групп в объединении
с управлением.
Для выбора методики основным фактором является скорость разработки. В
стандарте ISO/IEC 12207 нет подробного описания работ на разных стадиях.
Стандарт MSF, ориентирован на создание бизнес-приложений. В условиях
высокой конкуренции на рынке и больших затрат на поддержку инфраструктуру
и пользователей, необходим в кратчайшие сроки разработать ПО. Так же очень
важной является возможность быстрого расширения функциональности. Для
такого типа разработки подойдет гибкая методология в частности SCRUM.
Данная методология подразумевает выпуск готового функционала итерациями и
предоставляет конечную ценность пользователю с первых месяцев разработки.
Большинство современных компаний перешли или в процессе перехода к гибким
методологиям разработки.
Произведем выбор стратегии внедрения информационной системы. В
данный момент существую 4 основных стратегий:
Параллельная стратегия – применяется в тех случаях, когда в данный
момент работающую систему нужно заменить новой;
Скачок – стратегия резкого перехода от одной информационной
системы к другой;
Опытная эксплуатация схожа со стратегий скачка ,применяется к
ограниченному числу этапов автоматизации ,успешна в на
небольших участках процесса;
Узкое место – внедрение функционала только для определенного
“узкого места”
В текущих условиях деятельности компании, а также с учетом
особенностей бизнес процесса технической поддержки, наиболее подходящая
стратегия для внедрения это - Опытная эксплуатация пилотного проекта. При
использовании данной стратегии планируется минимизация рисков и постепенное
внедрение функционала.
27
Для проекта разработки ИС учета заявок на техническую поддержку
наиболее подойдет гибкая методология разработки, позволяющая в кратчайшие
сроки обеспечить выпуск готового ПО и начать сокращать потери компании.
2.1.2. Возможные риски на этапах жизненного цикла и их описание
Ни один проект в процессе реализации не застрахован от рисков. Чем
крупнее проект, тем больше масштаб потенциальных рисков. При управлении
проектом необходимо постоянно думать не об оценке рисков, а о плане
реагирования на изменения, который помог бы снизить риски.
Риски проекта всегда связаны с неопределённостью, исходя из этого
необходимо иметь представление о степени неопределённости и ее причинах.
В настоящее время существует четыре общепринятых стратегии
управления рисками:
Избегание рисков или стратегия уклонения. Данная стратегия
нацелена на полное исключение рисков из проекта, подразумевает
разработку системы мер, надежно защищающих нас от возможного
возникновения выделенных рисков. Стратегию уклонения принято
считать самым активным методом борьбы с рисками, а также самым
дорогим методом. Применима данная стратегия далеко не всегда,
так как часто стратегия уклонения приводит к отказу от части работ
или изменению конечной цели проекта. Использование данной
стратегии актуально в случаях, когда мы имеем возможность
полностью исключить источник риска.
Минимизация рисков или стратегия снижения. Является также
одним активных метод работы с рисками. Подразумевает данная
стратегия уменьшение вероятности возникновения определенного
риска или снижение его влияния на проект. В данном случае мы
должны иметь возможность полностью контролировать риски.
Стратегия передачи или страхование рисков. В данном случае сами
риски не устраняются и их влияние на результат не снижается.
28
Данная стратегия заключается в перекладывании последствий
возникновения рисков и ответственности на третью сторону. Данная
стратегия всегда включает в себя финансовые затраты и финансовую
компенсацию в случае возникновения риска.
Принятие рисков. Данная стратегия предполагает анализ возможных
рисков и осознанную готовность к их возникновению. Стратегия
принятия подразделяется на два вида – активная и пассивная.
Активная модель подразумевает заблаговременную подготовку
финансовых и временных ресурсов на работу по устранению
последствий при возникновении риска. Пассивная модель включает
в себя разработку плана действий и мер в случае возникновения
риска.
В данном проекте мы будем применять модель принятия рисков, что
позволит нам применять гибкую методологию и в значительной степени снизить
степень риска, так как проектная команда сможет гибко подстраиваться под
меняющиеся условия.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В компании Сбербанк применяется политика безопасности.
Целями политики безопасности являются:
конфиденциальность информационных ресурсов;
непрерывный доступ к информационным системам;
29
целостность деловой информации для оказания услуг высочайшего
качества;
постоянная работа по повышению грамотности пользователей о
рисках, связанных с информационными ресурсами;
обязательное описание степени ответственности и обязательств
сотрудников по соблюдению информационной безопасности.
Руководители подразделений обязаны на регулярной основе доносить
информацию о безопасности до своих подчинённых и проводить проверки в
отношении все сотрудников.
Текущие требования распространяются на всех сотрудников и все
информационные ресурсы. Требования политики безопасности распространяется
так же на новое ПО. Необходимо учитывать степень доступности
конфиденциальной информации, необходимо предусмотреть систему аудита и
предупреждения утечки конфиденциальной информации.
2.2. Информационное обеспечение задачи
2.2.1. Описание информационной модели
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов.
Информационная модель представлена на рис. 7.
30
Рисунок 7 - Информационная модель системы автоматизации заявок
пользователей
Информационная модель содержит 4 области:
1. Входящая информация — это документы, использующиеся для
входной информации, а также формы для ввода данной информации;
2. Справочники системы -это справочники и таблиц ИС;
3. Обработка информации – это область отвечает за то каким образом
информация обрабатывается и сохраняется в базах данных;
4. Формирования результатов, область в которой присутствуют
экранные формы и выходные документы.
Информация о пользователях системы будет заполнятся на основе
интеграции ИС с доменным каталогом. Авторизация пользователей будет также
Данные о пользователе
из SAP HR
Форма для заведения заявки
Данные о пользователе
из домена
Справочник пользователей
Нормативные акты
Шаблоны поддержки
на основании ТС
Таблица доступов
Сохранение в базе данных о заявке
Отчеты администраторов
Экран с информацией о
статусе заявки для
пользователей
Обработка
заявки
31
проходит на уровне операционной системы с помощью стандартной функции
Windows авторизации.
Администраторы системы наполняют каталог шаблонов технической
поддержки с подробным описанием решаемой проблемы и отмечает обязательные
поля к заполнению. Часть полей определяется автоматически на основе данных
из операционной системы пользователей:
IP - адрес
MAC - адрес
Доменная учетная запись пользователя
На основе технологии полнотекстового поиска пользователи выполняют
поиск по каталогу шаблонов и находят необходимый. Заполняют обязательные
параметры заявки и отправляют. Заявки в зависимости от типа маршрутизируются
в различные системы и отрабатываются в автоматическом либо
полуавтоматическом режиме.
Примеры автоматических шаблонов:
Заявка на разблокировку учетной записи в домене
Заявка на установку стандартного ПО
Примеры полуавтоматических заявок:
Регистрация инцидента в ПО
Заказ оборудования
Заказ на ремонт оборудования