Дипломная (вкр): Разработка программного обеспечения для терминалов приема платежей за услуги связи

Разработка программного обеспечения для терминалов приема платежей за услуги связи

АКАДЕМИЯ МАРКЕТИНГА И СОЦИАЛЬНО-ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ - ИМСИТ (г. Краснодар)

Факультет информатики и вычислительной техники

Кафедра математики и вычислительной техники

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

на тему: "Разработка программного обеспечения для терминалов приема платежей за услуги связи" (по материалам ООО Фирмы "Теплостройсервис", г. Краснодар)

Краснодар

Реферат

ТЕРМИНАЛЫ ПРИЕМА ПЛАТЕЖЕЙ, UML, ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ, ПОЛЬЗОВАТЕЛЬСКИЙ ИНТЕРФЕЙС, ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ, СРЕДА DELPFI 2007

Объектом исследования является сфера деятельности ООО Фирмы "Теплостройсервис", и ее программно-техническое оснащение в области приема платежей за услуги связи от населения через терминалы.

Цель состоит в повышении эффективности бизнес-процессов Фирмы "Теплостройсервис" в области приема платежей за услуги связи от населения через терминалы.

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

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

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

Внедрение результатов предусматривается в терминальном оборудовании для оплаты платежей населением за услуги связи, используемом ООО Фирмой "Теплостройсервис".

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

Перечень сокращений, символов и специальных терминов с их определением

API - интерфейс программирования приложений (Application Programming Interface);

GUI - графический интерфейс пользователя (Graphical User Interface);

ORM - объектно-реляционное отображение (Object-Relational Mapping);

RAD - быстрая разработка приложений (Rapid Application Development);- унифицированный язык моделирования (Unified Modeling Language);- технологический стандарт написания распределённых приложений (Common Object Request Broker Architecture);

БД - база данных;

ООП - объектно-ориентированное программирование;

ОС - операционная система;

ПО - программное обеспечение.

Содержание

Введение

. Исследование предметной области

.1 Концептуальная модель

.2 Диаграмма вариантов использования

.3 Диаграмма классов

. Анализ требований к программному обеспечению

. Техническое задание на разработку

.1 Введение

.2 Требования к программе

.3 Условия эксплуатации

. Выбор метода разработки программного обеспечения

.1 Выбор языка программирования

. Основная часть

. Реализация разработки

.1 Разработка программных модулей

.2 Разработка интерфейса пользователя

. Разработка проектной документации

.1 Руководство пользователя

.2 Руководство программиста

. Оценка эффективности программного продукта

. Мероприятия по охране труда и безопасности жизнедеятельности

.1 Вредные воздействия производственных факторов

.2 Методы повышения безопасности

.3 Пожарная безопасность

.4 Защита окружающей природной среды

Заключение

Список использованных источников и литературы

Приложение

Введение

программный обеспечение интерфейс терминал

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

–       выбор сотового оператора;

–       ввод сотового номера абонента с возможностью проверки его корректности и исправления;

–       ввод номера счёта для оплаты кредита с возможностью проверки его корректности и исправления;

–       возможность контроля суммы внесённого платежа;

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

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

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

Актуальность и необходимость создания такой системы обусловлена следующими аспектами:

-       быстрым вводом нужных пользователю (плательщику) данных и удобством пользовательского интерфейса;

-       сокращением времени на внесение в базу поступивших платежей;

-       безопасном хранении данных.

1.      Исследование предметной области

1.1    Концептуальная модель

Концептуальной моделью является отражение предметной области, в данном случае - сфера деятельности ООО "Теплостройсервис".

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

Терминальное обслуживание осущетвляется по дилерскому договору с фирмой Кампэй (Comepay). Кампэй образована в 2006 году, работает на рынке под зарегистрированным брендом "Comepay", и является одной из ведущих компаний Российской Федерации по приему моментальных платежей. Основными направлениями бизнеса являются: развитие сервиса по приему платежей, который позволяет осуществлять оплату всех повседневных услуг от мобильной связи до погашения банковских кредитов, и производство платежных терминалов.

На первом этапе развития данного направления по предоставлению услуг терминальной оплаты ООО Фирма "Теплостройсервис" являлась региональным провайдером ООО "Кампей". В настоящее время ООО Фирма "Теплостройсервис" имеет подключения свыше 200 точек оплаты и более 600 платежных терминалов в г. Краснодаре и Краснодарском крае.

Для обеспечения надежной и бесперебойной работы по приему платежей, Фирма использует высококачественное оборудование фирмы IBM и CISCO, резервное копирование программного обеспечения и информации находящейся на сервере ООО "Теплостройсервис", а также дублирование серверного оборудования.

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

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

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

Для перехода на самостоятельное предоставление услуг ООО "Теплостройсервис" необходимо покупать техническое оборудование в виде терминала и программное обеспечение к данному оборудованию. Стоимость лицензии на программное обеспечение "Электронный кассир" и базовая настройка на один терминал на 30.03.2015 составляет 29470 рублей. В данную поставку входят интеграция нового поставщика, редактирование формата и вида реестра, генерация доступа к личному кабинету, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека. Таким образом, программирование интерфейса, программирование чека и сценария платежа, настройку простого меню до 8 позиций и простого чека составляют половину пакета услуг по программированию терминалов приема платежей, что составляет около15000 рублей на каждый терминал. Было принято решение о разработке собственного программного продукта, входящего в программно-аппаратный комплекс, возможности которого позволяют организовать прием платежей в пользу операторов сотовой связи.

С приложением будут работать плательщики за услуги связи. Пользователи (плптельщики) могут искать нужного оператора сотовой связи, используя простой вариант поиска (по наименованию).

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

1.2 Диаграмма вариантов использования

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой [2]. Диаграмма вариантов использования показана на рисунке 1.

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

1.3 Диаграмма классов

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

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

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

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

Рисунок 2 - Диаграмма классов

2. Анализ требований к программному обеспечению

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

         выбор сотового оператора;

         ввод сотового номера абонента с возможностью проверки его корректности и исправления;

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

         возможность контроля суммы внесённого платежа;

         возможность печати чека, подтверждающего выполнение операции;

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

Основные требования, предъявляемые к качеству ПО:

.Надежность.

         Устойчивость к отказам.

         Способность к восстановлению работоспособности при отказах.

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

         Понятность (Назначение ПО должно быть понятным, из самой программы и документации).

         Удобство обучения.

         Простота и удобство использования программы. (Это требование относится прежде всего к интерфейсу пользователя).

.Эффективность.

         Временные характеристики.

         Использование ресурсов (Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач).

.Сопровождаемость.

Изменяемость, удобство внесения изменений.

.Переносимость, мобильность.

Адаптируемость (Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии).

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

.Возможность отката на предыдущую версию (roll-back).  8.Возможность интеграции с автоматическими тестерами (типа Rational Robot и т.д.).

.Простота конфигурации системы.

3. Техническое задание на разработку

3.1 Введение

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

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