Программный комплекс учета оборудования торгового эквайринга для отделения ПАО 'Сбербанк'

Программный комплекс учета оборудования торгового эквайринга для отделения ПАО 'Сбербанк'

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. АНАЛИЗ ПРОГРАММНО-ТЕХНИЧЕСКИХ РЕШЕНИЙ ПО УЧЕТУ ОБОРУДОВАНИЯ ТОРГОВОГО ЭКВАЙРИНГА

.1 Анализ средств автоматизации учета оборудования

.2 Обзор существующих вариантов решения

.2.1 КОРУС 23.02 (ООО «СТАНС»)

1.2.2 IT Invent 1.60 (YuKoSoft)

1.2.3 Hardware Inspector (Database Harbor Software)

.3. Выбор решения и его обоснование

. РАЗРАБОТКА АРХИТЕКТУРЫ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

.1 Реализация функций

.2 Система управления контентом

.3 Выбор CMS

.4 CMS Joomla

.5 Менеджер пользователей

3 РАЗРАБОТКА СТРУКТУР ДАННЫХ И БАЗ ДАННЫХ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

3.1 Пользователи системы

.2 Определение категорий пользователей

.3 Регистрация пользователей

.4. Структура информационной базы данных

4. РАЗРАБОТКА АЛГОРИТМОВ АВТОМАТИЗАЦИИ УЧЕТА ОБОРУДОВАНИЯ

.1 Алгоритмы действий пользователей

. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ

.1 Структура программного комплекса

5.2. Стандартные классы, методы и объекты Joomla, используемые в разработке

.2.1Предопределенные константы

.2.2Класс JFactory

.2.3HTTP-запрос (класс JRequest)

.2.4Приложение (класс JApplication). Очередь сообщений

.2.5Перенаправление

.3Структура компонента

.3.1Парадигма MVC

.3.2Файловая структура компонента

.3.3Содержание каталога admin

.3.4Содержание каталога site

.4Разработка компонента

.4.1. Примеры формирования запросов к БД

.4.2Создание производных классов JTable

.4.3Функция сохранения данных

.4.4Функция вывода записей

.4.5Проверка заполнения полей

6. ЭКСПЕРИМЕНТАЛЬНОЕ ТЕСТИРОВАНИЕ И ОТЛАДКА МОДУЛЕЙ

.1 Тестирование программного обеспечения

.2 Уровни тестирования

.3 Статическое и динамическое тестирование

.4 Тестирование «белого ящика» и «чёрного ящика»

.5 Покрытие кода

6.5.1 Виды тестирований

.5.2 Классификация по объекту тестирования

.5.3 Классификация по знанию системы

.5.4 Классификация по степени автоматизации

.5.5 Классификация по степени изолированности компонентов

.5.6 Классификация по времени проведения тестирования

.5.7 Классификация по признаку позитивности сценариев

.5.8 Классификация по степени подготовленности к тестированию

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

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

. ОЦЕНКА КАЧЕСТВА РАЗРАБОТАННОГО ПРОДУКТА

.1 Сертификация

.2 Вторичные стандарты качества

.3 Государственные стандарты Российской Федерации

.4 Определение оценки качества разработанного продукта

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ВВЕДЕНИЕ

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

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

На долю Сбербанка в российском банковском секторе по общему объему активов приходится 28, 7% совокупных банковских активов (по состоянию на 1 января 2016 года).

Сбербанк - универсальный банк, предоставляющий широкий спектр банковских услуг. Его доля в общем объёме активов российского банковского сектора составляла на 1 января 2016 года 28, 7 %; на рынке частных вкладов - 46 %; кредитный портфель соответствовал 38, 7 % всех выданных кредитов населению.

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

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

)        онлайн-банкинг «Сбербанк Онлайн» (более 13 млн активных пользователей);

)        мобильные приложения «Сбербанк Онлайн» для смартфонов (более 1 млн активных пользователей);

)        SMS-сервис «Мобильный банк» (более 17 млн активных пользователей);

)        одна из крупнейших в мире сетей банкоматов и терминалов самообслуживания (более 86 тыс. устройств).

Среди клиентов Сбербанка - более 1 млн предприятий (из 4, 5 млн зарегистрированных юридических лиц в России). Банк обслуживает все группы корпоративных клиентов, причем на долю малых и средних компаний приходится более 35% корпоративного кредитного портфеля банка[1].

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

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

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

1. АНАЛИЗ ПРОГРАММНО-ТЕХНИЧЕСКИХ РЕШЕНИЙ ПО УЧЕТУ ОБОРУДОВАНИЯ ТОРГОВОГО ЭКВАЙРИНГА

.1      Анализ средств автоматизации учета оборудования

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

Эквайринг (от англ. acquire - приобретать, получать) - приём к оплате платёжных карт в качестве средства оплаты товара, работ, услуг. Осуществляется уполномоченным банком-эквайрером (англ. acquiring bank) путём установки на торговых или сервисных предприятиях (ТСП) платёжных терминалов (POS-терминалов).

.2      Обзор существующих вариантов решения

.2.1   КОРУС 23.02 (ООО «СТАНС»)

КОРУС (компьютеры, оргтехника, расходные материалы - учет и сопровождение) - программа для учета, имеющегося вычислительного оборудования и техники. Ее предназначение - решение разнообразных задач, связанных с учетом компьютеров и оргтехники. Состоит из комплекта программ для учета оргтехники, расходных материалов, сетевого оборудования; автоматизации процесса плановой инвентаризации; печати отчетных документов (актов ввода, списания, технического состояния и пр.); администрирования системы.

Функции КОРУС:

)        учет закупок техники. Постановка техники на учет и списание (с формированием соответствующих актов);

)        учет перемещения техники по различным подразделениям организации;

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

)        настраивается на работу в сети и разных филиалах одной организации;

)        получение всевозможных отчетов, по любой хранимой информации в программе;

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

)        возможность учета средств, находящихся в разных филиалах одной организации или в разных организациях, получение совместных и раздельных отчетов[3].

1.2.2 IT Invent 1.60 (YuKoSoft)

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

Ключевые особенности программы:

)        учет компьютеров и сопутствующей офисной техники.

)        поддержка базы данных MS Access и MS SQL Server.

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

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

)        прикрепление изображений и файлов к объектам учёта.

)        учет Заказов поставщикам на все виды учетных единиц.

)        модуль инвентаризации с автоматической обработкой результатов.

)        ведение истории изменений в ключевых полях объектов учета.

)        учет ремонтов и профилактических обслуживаний оборудования и компьютеров.

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

)        закрепление учетных единиц за сотрудниками организации. Акты приёма-передачи.

)        ведение базы поставщиков, сервисных организаций и прочих контрагентов.

)        гибкое разграничение прав доступа.

)        большое количество уже встроенных печатных форм и отчетов с возможностью их редактирования.

)        импорт и просмотр данных напрямую из Active Directory.

)        импорт данных из Excel/CSV файлов[4].

1.2.3 Hardware Inspector (Database Harbor Software)

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

Основные возможности последней версии Hardware Inspector:

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

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

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

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

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

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

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

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

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

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

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

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

)        большой набор различных отчетов. Отчеты могут экспортироваться в форматы: PDF, MS Word, MS Excel, Open Office и другие.

)        механизмы поиска информации. Фильтры поиска.

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

)        многопользовательский доступ к базе данных[5].

.3      Выбор решения и его обоснование

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

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

Основными характеристиками Joomla являются:

)        полностью основанный на БД движок с использованием PHP/MySQL.

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

)        полностью настраиваемые схемы расположения элементов, включая всевозможные блоки меню.

)        работа под такими операционными системами как Linux, FreeBSD, MacOSX, Solaris, AIX, SCO, WinNT, Win2K.

)        является свободно распространяемым программным обеспечением

)        имеет регулярную поддержку и обновление

Проект предполагается выполнить в виде расширения Joomla.

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

–       CMS Joomla 2.5.6

–       Веб-сервер IIS 7.0

–       PhpMyAdmin 4.0.4.2

–       Язык программирования PHP, JavaScript;

–       СУБД MySQL 5.6.13

Таблица 1.1 - Сравнение программного обеспечения

2. РАЗРАБОТКА АРХИТЕКТУРЫ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

.1      Реализация функций

За реализацию функций отвечают две составляющие:

Аппаратная - технические средства для реализации программных функции (это сервер и сопутствующее серверное оборудование);

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

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

–       Процессоры:Intel®xeon®CPUX5650(2.67ГГц)(2шт.);

–       ОЗУ:12Gb

–       Программная часть:

–       ПО сервера:

–       OS:Windows Server 2008 R2

–       Web-server:IIS7.0

–       PHP5.3.27

–       ПО, используемой для разработки:

–       CMS Joomla 2.5.6

–       СУБД MySql

Данный сервер является стандартным для Сбербанка.

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

Структура программно-аппаратного комплекса

Функциональный анализ

программный учет оборудование эквайринг

2.2    Система управления контентом

Система управления содержимым (контентом) (англ. Content management system, CMS) - информационная система или компьютерная программа, используемая для обеспечения и организации совместного процесса создания, редактирования и управления контентом (то есть содержимым).

Основные функции CMS:

Управление содержимым: хранение, контроль версий, соблюдение режима доступа, управление потоком документов и т. п.

Представление информации в удобном виде.

В системе управления контентом находятся самые различные данные: документы, мультимедиа данные, телефонные номера, научные данные и так далее[7].

.3      Выбор CMS

Так как согласно задачам создаваемого проекта к системе должны иметь доступ пользователи с разными правами, для реализации проекта выберем CMS Joomla, где уже организованы списки контроля доступа Access Control List (ACL). Это список контроля доступа, в котором отображаются и настраиваются права доступа на веб-сайте, включая пункты: просматривать, создавать, редактировать, удалять, вход в систему.

2.4    CMS Joomla

Система подходит для различного вида корпоративных сайтов или информационных проектов. Приведем основные характеристики Joomla:

–       Полностью основанное на БД ядро программы с использованием PHP/MySQL;

–       Многоуровневый модуль безопасности для аутентификации пользователей/администраторов;

–       Разделы тем могут быть добавлены авторами;

–       Полностью настраиваемые схемы расположения элементов, включая левый, правый и центральный блоки меню;

–       Форум/Опросы/Голосования для эффективной обратной связи;

–       Работа под такими операционными системами как Linux, FreeBSD, MacOSX, Solaris, AIX, SCO, WinNT, Win2K.

.5      Менеджер пользователей

В Joomla пользователям уделяется все больше внимания и постепенно расширяются возможности настройки. Менеджер пользователей в Joomla 2.5.6 имеет большой набор функций управления и расширенные настройки - это создание групп пользователей, добавление заметок с категориями к пользователям, задание уровней доступа, настройка и отправка массовой рассылки и управление правами групп пользователей.

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

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

Рисунок 2.1- Настройка прав доступа пользователей

3. РАЗРАБОТКА СТРУКТУР ДАННЫХ И БАЗ ДАННЫХ ПРОГРАММНОГО КОМПЛЕКСА УЧЕТА ОБОРУДОВАНИЯ

.1      Пользователи системы

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

.2      Определение категорий пользователей

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

Таблица 3.1 - Категории пользователей

3.3 Регистрация пользователей

Регистрация пользователей в системе осуществляется посредством стандартных средств CMS Joomla техническим администратором с выдачей данных авторизации - логина и пароля.

.4 Структура информационной базы данных

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

Таблицы базы данных, описание данных содержащихся в них подробно описаны в таблице 3.2.

Таблица 3.2 - Структура базы данных

ЛОГИЧЕСКАЯ СХЕМА БАЗЫ ДАННЫХ

Методология IDEF0 используется для моделирования широкого круга предметных областей, и применяться как технология проектирования систем на логическом уровне. Процесс моделирования систем в IDEF0 начинается с построения контекстной диаграммы. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействие с внешней средой[8].

Контекстная диаграмма данной модели ИС представлена на рисунке 3.1.

Рисунок 3.1 - Контекстная диаграмма ИС

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

Описание стрелок контекстной диаграммы представлено в таблице 3.1.

Таблица 3.1 - Стрелки контекстной диаграммы

Диаграмма декомпозиции 1-го уровня представлена на рисунке 3.2

Рисунок 3.2 - Диаграмма декомпозиции 1-го уровня

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

Диаграмма декомпозиции 2-го уровня представлена на рисунке 2.3.

Рисунок 3.3 - Диаграмма декомпозиции 2-го уровня

Диаграмма декомпозиции 2-го уровня представлена для блока «Вход в систему». В ней наглядно показано как происходит проверка данных идентификации пользователя и дальнейший переход в главное меню информационной системы. Описание функциональных блоков IDEF0 представлено в таблице 3.2.

Таблица 3.2. - Описание функциональных блоков IDEF0

IDEF3 - это технология для сбора данных, которые требуются для проведения структурного анализа системы. Данная технология используется как дополнение к IDEF0 для разработки моделей, в которых изучается последовательность выполнения действий и взаимосвязей между ними[9].

Диаграмма IDEF3 для автоматизации учета оборудования представлена на рисунке 3.4.

Рисунок 3.4 - Диаграмма IDEF3

Описание функциональных блоков IDEF3 представлено в таблице 3.3.

Таблица 3.3 - Описание функциональных блоков IDEF3

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

Диаграммы потоков данных DFD моделируют систему как набор действий, соединенных друг с другом стрелками, отражают передачу информации от одной функции к другой[10].

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

Рисунок 3.5 - Диаграмма DFD

Описание функциональных блоков DFD представлено в таблице 3.4.

Таблица 3.4 - Описание функциональных блоков DFD

Основные элементы модели представлены в таблице 3.5.

Таблица 3.5 - Основные элементы модели

4. РАЗРАБОТКА АЛГОРИТМОВ АВТОМАТИЗАЦИИ УЧЕТА ОБОРУДОВАНИЯ

.1      Алгоритмы действий пользователей

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

Рисунок 4.1 - Алгоритм действий технического администратора

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

Рисунок 4.2 - Алгоритм действий сотрудника банка

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

Рисунок 4.3 - Алгоритм действий руководителя отдела

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

Рисунок 4.4 - Алгоритм проверки уникальности оборудования.

5. РАЗРАБОТКА И РЕАЛИЗАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ

.1      Структура программного комплекса

В качестве основания для серверной части программы используется ОС Windows 8.1, а также сервер БД MySQL версии 3.23.58, и PHP 5для обеспечения работы скриптов.

Выбранный в качестве СУБД, сервер баз данных MySQL - это компонент программной системы предназначенный для хранения и предварительной обработки всех данных используемых системой. Mysql - это масштабируемый высокопроизводительный SQL сервер баз данных, совершенный по простоте инсталляции, использования и обслуживания. MySQL является собственностью компании MySQL AB. Входит в LAMP.

Гибкость данного СУБД обеспечивается поддержкой большого количества типов таблиц, таких как: MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей[11].

Язык PHP - это скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере и работы с базами данных. Входит в LAMP - «стандартный» набор для создания веб-сайтов (Linux, Apache, MySQL, PHP (Python или Perl)). Интерпретатор PHP подключается к веб-серверу либо через модуль, созданный специально для этого сервера (например, для Apache или IIS), либо в качестве CGI-приложения. Кроме этого, он может использоваться для решения административных задач в операционных системах UNIX, GNU/Linux, Microsoft Windows, Mac OS X и AmigaOS. Реализация проекта в рамках CMS Joomla невозможна без использования стандартных средств используемой системы управления контентом. В ходе реализации будут применены предустановленные плагины, модули, классы и библиотеки.

5.2 Стандартные классы, методы и объекты Joomla, используемые в разработке

.2.1   Предопределенные константы

В Joomla определен ряд констант, хранящих значения путей: JPATH_BASE - это путь к корневой директории текущего приложения; JPATH_ROOT - это путь к корневой директории сайта, JPATH_COMPONENT - это путь к директории компонента, JPATH_COMPONENT_SITE - это путь к фронтенду компонента, JPATH_COMPONENT_ADMINISTRATOR - это путь к бэкенду компонента и т.д. Все эти константы возвращают значения абсолютных путей в файловой системе. Если вам необходимо получить путь для использования в URL, следует воспользоваться методом JURI::base().

В файле index.php, расположенном в корневой директории Joomla, определена константа _JEXEC. Большинство PHP-файлов, написанных под Joomla, начинаются с выражения defined('_JEXEC') or die('Restricted access');

.2.2   Класс JFactory

В Joomla существует статический класс JFactory, реализующий паттерн "фабрика". Методы данного класса (getApplication(), getDate(), getDbo(), getDocument(), getLanguage(), getURI(), getUser(), getMailer(), getEditor() и др.) позволяют получить доступ к соответствующим глобальным объектам фреймворка (JApplication, JDate, JDatabase, JDocument, JLanguage, JURI, JUser, JMail, JEditor и др.). Пример получения доступа к объекту JUser:

$user =& JFactory::getUser();($user->guest)"Вы не вошли на сайт";"Вы вошли на сайт как ".$user->name;

5.2.3 HTTP-запрос (класс JRequest)

В Joomla вместо непосредственного использования глобальных массивов $_GET, $_POST, $_FILES, $_COOKIE, $_ENV, $_SERVER и $_REQUEST удобнее применять класс JRequest. Его методы пропускают данные, введенные пользователем, через фильтр во избежание инъекций.

Для получения переменных запроса GET/POST используется метод mixed getVar(string $name, string $default=null, string $hash='default', string $type='none', int $mask=0), где:

$nameимя переменной;

$defaultзначение по умолчанию, которое вернет метод getVar(), если значение переменной не задано;

$hashисточник данных, по умолчанию они будут получены из массива $_REQUEST. Явное указание массива GET или POST повысит безопасность кода;

$typeтип ожидаемого значения:

INT

WORDдопускает только буквенно-цифровые значения;допускает только те символы, которые могут быть представлены в кодировке base64 (т.е. a-z, A-Z, 0-9, /, + и =);исключает возможность атаки. Например, если исходное значение содержало /./ или/../, то вместо него метод вернет пустую строку;удаляет управляющие символы (0x00 - 0x1F), 0x7F, <, >, ", ', % и &;

$maskконстанта, задающая опции фильтрации:_NOTRIMне удалять пробелы в начале и конце строки;_ALLOWRAWбез какой-либо фильтрации;_ALLOWHTMLне удалять HTML-код, но пропустить значение через фильтр (в частности, удалить опасные теги - script, applet, iframe и др.).

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

Например, получим массив $_POST:

$arr = JRequest::get('post');

Для присвоения переменным запроса значений используется метод string setVar(string $name, string $value=null, string $hash='method', bool $overwrite=true)

Если $overwrite=false и в запросе уже задано значение переменной $name, то метод просто вернет само это значение. В противном случае переменной будет присвоено значение $value, а метод вернет старое значение $name.

Класс JRequest содержит также методы, позволяющие получить значение определенного типа: getBool(), getCmd(), getFloat(), getInt(), getString(), getWord().

.2.4 Приложение (класс JApplication). Очередь сообщений

В Joomla существует очередь сообщений - массив строк, которые будут выведены на экран при следующей загрузке какой-либо страницы. Стандартными являются три типа сообщений: message (собственно сообщение), notice(предупреждение) и error (ошибка).

Для добавления сообщений в очередь используется метод void enqueueMessage(string $msg, [string $type = 'message']), где:

$msg- текст сообщения;

$type- тип сообщения.Например:

global $app;

$app->enqueueMessage('Message');

$app->enqueueMessage('Notice', 'notice');

$app->enqueueMessage('Error', 'error');

5.2.5 Перенаправление

Для перенаправления пользователя к другому URL используется метод void redirect(string $url, string $msg='', string $msgType='message', bool $moved=false), где:

$url- URL, к которому перенаправляется пользователь;

$msg- сообщение, которое должно быть при этом выведено;

$msgType- тип сообщения;

$moved- при значении true браузер получит код состояния "301 Permanently Moved", в противном случае - "303 See Other".

Данный метод добавляет сообщение к очереди сообщений, перенаправляет браузер пользователя к заданному URL и завершает работу приложения Joomla[13].

.3      Структура компонента

Разработка любого приложения начинается с анализа его структуры. Так как компонент создается на базе Joomla он должен соответствовать общим требованиям.

.3.1   Парадигма MVC

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

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

Контроллер (controller) - это специальный PHP-класс, который "принимает" входящий HTTP-запрос пользователя и отвечает за его дальнейшую маршрутизацию к другим частям компонента. Если представлять компонент как чёрный ящик, то контроллер - это вход в компонент. Когда пользователь переходит по страницам сайта Joomla, ходит по меню, разделам и т.д. первой частью компонента, с которым он работает в данный момент, всегда будет контроллер. Контроллер как бы "доводит" запрос пользователя до более глубинных частей компонента, таких как модель. Контроллер может в какой-то степени являться и выходом из компонента. Если данные оказываются неверными, компонент может перенаправить свое выполнение представлению

Модель (model) - это та часть компонента, которая предназначена как правило для получения данных из какого-либо источника (обычно из базы данных), для обработки этих данных и передачи обработанных данных на "выход" - т.е. для отображения пользователю сайта. Таким образом, модель как бы представляет собой промежуточный слой между базой данных и представлением, т.е. той частью компонента, которая отображает данные пользователю. Модель помимо обработки и получения данных может содержать в себе определенную структуру данных, характерную для конкретного компонента.

Представление (view) - это часть компонента, отвечающая за отображение данных пользователю, т.е. посетителю сайта. У каждого представления есть связанная с ним модель - чтобы представление могло посредством модели получить данные из базы данных и отобразить их пользователю[14].

.3.2   Файловая структура компонента

После установки компонента через административную панель Joomla его файлы устанавливаются в два основных каталога на диске - это /administrator/components/com_<название_компонента> и/components/com_<название_компонента>. Разрабатываемый компонент называется posterm, тогда при установке компонента на сайт Joomla создаст два основных каталога:

<корень_сайта>/administrator/components/com_posterm

<корень_сайта>/components/com_posterm

Есть некоторые каталоги, имена которых должны быть стандартными - это каталоги views, models, controllers. Их имена не меняем, потому что движок Joomla будет искать файлы компонента по заранее установленным правилам.

Установка компонента происходит путем распаковки zip архива компонента, внутри которого находится все служебные каталоги и специальный установочный файл компонента -posterm.xml. Именно он отвечает за то, из какого каталога в ZIP-архиве брать файлы и куда их устанавливать уже на сайте.

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

)        В ZIP-архиве установочный дескриптор компонента - в нашем случае это posterm.xml располагается прямо в корне архива, а после установки он будет скопирован в<корень_сайта>/administrator/components/com_posterm/posterm.xml

)        В ZIP-архиве есть каталог /media, который может содержать различные мультимедиа файлы (изображения, видео и т.д.), которые будет использовать компонент в своей работе. Содержимое этого каталога при установке компонента будет скопировано в каталог<корень_сайта>/media/com_posterm/

)        Из ZIP-архива все содержимое каталога /site будет скопировано в front-end часть компонента, т.е. в каталог <корень_сайта>/components/com_posterm/

)        Из ZIP-архива все содержимое каталога /admin будет скопировано в back-end часть компонента, т.е. в каталог <корень_сайта>/administrator/components/com_posterm/

.3.3   Содержание каталога admin

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

Каталог admin содержит папки:

)        controllers - тут будут храниться файлы с классами контроллеров back-end части

)        css - для хранения файлов CSS-стилей, используемых для отрисовки элементов компонента внутри админки Joomla

)        help - для хранения справки для нашего компонента (на разных языках). Понадобится, если мы захотим написать инструкцию по использованию компонента

)        helpers - для хранения классов-помощников

)        language - здесь будут размещаться языковые файлы компонента

)        models - сюда будем помещать модели для административной части

)        sql - в этом каталоге будут храниться файлы с SQL-запросами для создания всех таблиц компонента в базе данных Joomla

)        tables - тут будут располагаться классы для работы с таблицами компонента

)        views - тут будут храниться файлы представлений, которые будут рисовать всё, что мы увидим в админке Joomla - относительно нашего компонента

Помимо каталогов имеются файлы:

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

-       config.xml - файл всех параметров нашего компонента;

-       controller.php - файл главного контроллера административной части;

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

-       posterm.php - "входная" точка админ-части компонента. Его Joomla вызовет в первую очередь, когда мы будем обращаться через админку к компоненту.

.3.4   Содержание каталога site

Файлы каталога site при установке будут распакованы на сервере в каталог, отвечающий за пользовательскую часть (frontend).

Каталог site содержит папки:

-       css - для хранения файлов CSS-стилей, предназначенных для отрисовки компонента на сайте. Это все стили, которые и будут формировать внешний "облик" компонента - то, что увидит пользователь сайта;

-       js - сюда будем помещать все JavaScript-файлы скриптов, jQuery-библиотеки, плагины jQuery и т.д., словом всё, что относится к скриптам. Они будут выполнять всю динамическую логику на стороне браузера, когда пользователь будет работать с частями компонента на сайте;

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

-       models - здесь будут храниться файлы моделей для frontend-части компонента;

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

-       controller.php - файл главного контроллера для frontend-части

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

-       posterm.php - "входная" точка frontend-части компонента. С неё всегда начинается исполнение компонента, когда пользователь работает с частями компонента на сайте Joomla.

.4      Разработка компонента

Любой компонент включает в себя собственно программный код и запросы к БД.

.4.1   Примеры формирования запросов к БД

Чтобы выполнить запрос к базе данных Joomla, необходимо осуществить пять операций:

-       Получение ссылки на объект JDatabase.

-       Формирование запроса.

-       Задание запроса.

-       Выполнение запроса.

-       При необходимости - загрузка результата.

В старых версиях Joomla запросы формулировались в виде строки:

$query = 'SELECT * FROM #__categories';

В Joomla существует объект JDatabaseQuery, методы которого позволяют упростить создание сложных SQL-запросов. Названия этих методов практически совпадают с ключевыми словами языка SQL: select(), from(), where(), having(), join() и т.д. Сформируем запрос к БД для получения списка имеющихся в БД терминалов, у которых серийный номер начинается на 2565:

$db = JFactory::getDbo();//получение ссылки на него с помощью метода getDbo() статического классаJFactory:

$query = $db->getQuery(true);

$query->select('id_pos, address');

$query->from('pos');

$query->order('data_ystanovki');

$query->where('sn_pos LIKE \'2565%\'');

$db->setQuery($query);$query->__toString();

В данном примере мы получаем из таблицы pos отсортированный по алфавиту список id и адресов установки терминалов, чьи серийные номера начинаются на "2565". Данный код выведет на экран следующий SQL-запрос:

SELECT id_pos, address FROM pos WHERE sn_pos LIKE '2565%' ORDER BY data_ystanovki;

Чтобы задать SQL-запрос для последующего выполнения, используется метод:

JDatabase setQuery(string $query, string $offset=0, string $limit=0);

где $query - это запрос, а $offset и $limit - соответственно смещение для начала выборки и количество выбираемых строк.

Например:

$db->setQuery($query, 0, 10);

5.4.2 Создание производных классов JTable

Для каждой таблицы, которая имеется необходимо создать класс, производный от JTable. Каждый такой класс размещается в папке tables компонента с именем «имя таблицы».php.

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

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

Производный от JTable класс для таблицы pinpad будет таким:

class pinpad extends JTable

{$id_pinpad = null;$pinpad = null;__construct(&$db)

{::__construct('pinpad, 'id_pinpad', $db);

}

Аналогичным образом создадим классы для оставшихся таблиц БД.

.4.3   Функция сохранения данных

Для добавления информации в БД необходима функция сохранения:

function save()

{

$row =& JTable::getInstance('pinpad', 'Table');(!$row->bind(JRequest::get('post')))

{"<script> alert('".$row->getError()."');.history.go(-1); </script>\n";();

}

$row->question = JRequest::getVar('name_pinpad', '', 'post', 'string', JREQUEST_ALLOWRAW);(!$row->store())

{"<script> alert('".$row->getError()."');.history.go(-1); </script>\n";

exit();

}$row;

}

5.4.4 Функция вывода записей

function showPinpad($option) {

$db =& JFactory::getDbo();

$query = "SELECT * FROM pinpad";

$db->setQuery($query);

$rows = $db->loadObjectList();

if ($db->getErrorNum())

{

echo $db->stderr();false;

Эта функция загружает все записи из таблицы pinpad.

5.4.5 Проверка заполнения полей

Для проверки заполенности полей используем JavaScript

<script type="text/javascript">proverka(Forma) {horosho = true;(Forma.id_name.value == "")

{= false;("Выберите наименование терминала");

Forma. id_name.focus();

};(Forma.data_ystanovki.value == "") {

horosho = false;("Введите дату установки терминала!");

Forma. data_ystanovki.focus();

};(Forma. data_remonta.value == "") {

horosho = false;("Введите дату ремонта терминала!");

Forma.data_remonta.focus();

};(Forma.address.value == "") {= false;("Введите адрес ТСТ!");.address.focus();

};

………horosho;

}

</script>

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

6. ЭКСПЕРИМЕНТАЛЬНОЕ ТЕСТИРОВАНИЕ И ОТЛАДКА МОДУЛЕЙ

.1      Тестирование программного обеспечения

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

)        продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

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

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

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

Полный список атрибутов и критериев можно найти в стандарте ISO 9126 [15].

.2      Уровни тестирования

Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция.

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

Системное тестирование - тестируется интегрированная система на её соответствие требованиям.

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

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

Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования - стадию исправления ошибок.

.3      Статическое и динамическое тестирование

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

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

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

.4      Тестирование «белого ящика» и «чёрного ящика»

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

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

.5      Покрытие кода

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

6.5.1 Виды тестирований

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

.5.2 Классификация по объекту тестирования

Функциональное тестирование (functional testing)

Тестирование производительности (performance testing)

Нагрузочное тестирование (load testing)

Стресс-тестирование (stress testing)

Тестирование стабильности (stability / endurance / soak testing)

Юзабилити-тестирование (usability testing)

Тестирование интерфейса пользователя (UI testing)

Тестирование безопасности (security testing)

Тестирование локализации (localization testing)

Тестирование совместимости (compatibility testing)

.5.3 Классификация по знанию системы

Тестирование чёрного ящика (black box)

Тестирование белого ящика (white box)

Тестирование серого ящика (grey box)

.5.4 Классификация по степени автоматизации

Ручное тестирование (manual testing)

Автоматизированное тестирование (automated testing)

Полуавтоматизированное тестирование (semiautomated testing)

.5.5 Классификация по степени изолированности компонентов

Компонентное (модульное) тестирование (component/unit testing)

Интеграционное тестирование (integration testing)

Системное тестирование (system/end-to-end testing)

.5.6 Классификация по времени проведения тестирования

Альфа-тестирование (alpha testing)

Дымовое тестирование (smoke testing)

Тестирование новой функциональности (new feature testing)

Подтверждающее тестирование (confirmation testing)

Регрессионное тестирование (regression testing)

Приёмочное тестирование (acceptance testing)

Бета-тестирование (beta testing)

.5.7 Классификация по признаку позитивности сценариев

Позитивное тестирование (positive testing)

Негативное тестирование (negative testing)

.5.8 Классификация по степени подготовленности к тестированию

Тестирование по документации (formal testing)

Тестирование ad hoc или интуитивное тестирование (ad hoc testing)

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

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

И второй метод - это метод эквивалентного разбиения. Его составляют два положения:

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

Тест, по возможности, должен включать, максимальное количество классов эквивалентности, для минимизации общего количества тестов.

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

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

Таблица 6.1. - Классы эквивалентности

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

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

Таблица 6.2. - Тестовые наборы для раздела «Добавление новой информации»

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

Для авторизации на главной странице ресурса (рисунок 6.1) используются логин и пароль, которые вводятся в соответствующие поля для заполнения (рисунок 6.2).

Рисунок 6.1- Главная страница сайта

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

Логином является последовательность букв латинского алфавита без специальных символов, длиной не более N символов. Пароль - не превышает 8 символов и состоит из цифр и букв латинского алфавита.

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

Все кнопки в системе сопровождаются короткими всплывающими сообщениями о функциях, которые они выполняют (рисунок 6.3).

Рисунок 6.3 - Всплывающее уведомление об успешном сохранении информации

Рисунок 6.4 - Пример таблицы добавления/редактирования технической информации

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

Рисунок 6.5 - Скриншот окна, где можно создать новый элемент таблицы

Для внесения нового оборудования в БД необходимо заполнить поля и нажать кнопку «Добавить».

Рисунок 6.6 - Добавление новых данных

Выделив галочкой слева нужные записи, мы можем их импортировать, т.е. выгрузить в виде отчета, в формате csv (рисунок 6.7).

Внесенную ранее информацию о терминале можно отредактировать с помощью кнопки «Редактировать» (рисунок 6.8).

Рисунок 6.7 - Формирование отчета

Рисунок 6.8 - Редактирование информации

После внесения всех данных и их сохранения появляется всплывающее окно с соответствующим уведомлением (рисунок 6.9).

Рисунок 6.9 - Скриншот всплывающего окна с уведомлением

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

Рисунок 6.10- Скриншот кнопки «Выход» из системы

7. ОЦЕНКА КАЧЕСТВА РАЗРАБОТАННОГО ПРОДУКТА

7.1    Сертификация

Одним из путей обеспечения качества ИС является ее сертификация. В США Радиотехническая комиссия по аэронавтике определяет процесс сертификации следующим образом:

Рисунок 7.1 - Модель классификации критериев качества информационных систем

В настоящее время нет стандартов, которые полностью удовлетворяют оценке качества ИС. На Западе имеется ряд стандартов, которые определяют основы сертификации программных систем, например стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран-членов НАТО (AQAP1).

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

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

В стандартах ISO 9000 используется определение качества из стандарта ISO 8402: " Качество - совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности".

В ISO 9000 вводится понятие системы качества. Система качества (QS -Quality System) - это документальная система с руководствами и описаниями процедур достижения качества. Представляет из себя совокупность трех слоев документов:

1)      описание политики управления для каждого системного элемента;

)        описание процедур управления качеством (что, где, кем и когда должно быть сделано);

)        тесты, планы, инструкции и т. п.

Сертификация предприятий по стандартам ISO 9001-9003 выполняется какой-либо уполномоченной на это внешней организацией. Наличие сертификата качества - одно из важнейших условий для успеха коммерческой деятельности предприятий[16].

7.2 Вторичные стандарты качества

Они включают в себя:

1)      ISO 9000 - основные понятия, руководство по применению ISO 9001;

)        ISO 9004 - элементы систем управления качеством. Поддерживающие стандарты предназначены для развития и установки систем качества:

)        ISO 10011 - аудит, критерии для аудита систем качества ;

)        ISO 10012 - требования для измерительного оборудования;

)        ISO 10013 - пособие для развития руководств по управлению качеством.

.3 Государственные стандарты Российской Федерации

К ним относятся:

1)      ГОСТ Р ИСО 9001-96 "Системы качества. Модель обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании";

)        ГОСТ Р ИСО 9002-96 "Системы качества. Модель обеспечения качества при производстве, монтаже и обслуживании";

)        ГОСТ Р ИСО 9003-96 "Системы качества. Модель обеспечения качества при окончательном контроле и испытаниях".

На данный момент разработана новая версия стандартов серии ISO 9000. Она называется ISO 9000:2000 Quality management systems, в которую включены следующие документы:

1)      ISO 9000:2000 Fundamentals and vocabulary (основы и терминология);

2)      ISO 9001:2000 Requirements (требования);

3)      ISO 9004:2000 Guidelines for performance improvement (руководство по развитию).

.4 Определение оценки качества разработанного продукта

На этапе определения показателей качества для каждого показателя  при определении веса показателей используется формула (7.1):

, (7.1)

где n - число показателей;

 - вес показателя с индексом i.

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

Таблица 7.1 - Описание оценок программного средства

Набор показателей качества состоит из таких показателей как: Надежность, Эффективность, Качество, Рациональность, Универсальность, Срок службы, Точность, Показатель назначения, Удобство усвоения, Время ввода в эксплуатацию.

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

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

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

Рациональность отвечает за выполнение требуемых функций без излишних затрат ресурсов ЭВМ.

Универсальность говорит о том, что программу можно использовать не только в той технической и программной среде, для которой она предназначена, но и в любой другой

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

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

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

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

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

Результаты выполнения этапов определения экспертной оценки для каждого показателя  и определения конкретной численной оценки показателя R представлены таблице 7.2.

Таблица 7.2 - Характеристика показателей качества

Определяем качество ПС используя формулу (7.2):

, (7.2)

где  - качество ПС;

 - общее число показателей;

 - экспертная оценка показателя с индексом i;

- экспериментальная оценка показателя с индексом i.

Для расчета среднего значения оценки качества на этапе «Определение среднего значения качества ПС» следует использовать формулу (7.3):

, (7.3)

где  - среднее значение оценки качества ПС;

- сумма оценок качества ПС;

- общее число показателей.

=

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

Рисунок 7.2 - Гистограмма распределения показателей по интервалам оценок

Таким образом качество программного средства оценивается как хорошее.

ЗАКЛЮЧЕНИЕ

Целью данной выпускной квалификационной работы являлась разработка автоматизированной системы учета оборудования для Отделения №8638 ОАО «Сбербанк России».

На этапах разработки данной работы, было выполнено следующее:

Описана предметная область разработки. Найдены и проанализированы аналоги. Составлена таблица сравнения аналогов и средств разработки программного обеспечения данной работы;

Произведена разработка архитектуры программного комплекса на основе стандартного сервера Сбербанк. Представлен общий вид программно-аппаратного комплекса. Предоставлены преимущества данной CMS;

Разработана база данных, представлено ее описание;

Разработана архитектура информационной системы;

Разработаны структура данных и алгоритмы работы системы;

Построены диаграммы IDEF;

Приведены методы и результаты тестирования разработанного программного обеспечения;

Разработана инструкция пользователя системы;

Дана оценка качества разработанной информационной системы.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1.      Сбербанк России [Электронный ресурс]: Информация о банке. - Режим доступа: http://sberbank.ru/ru/about/today;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: http://ru.wikipedia.org/wiki/POS;

.        ООО «Станс» [Электронный ресурс]: офиц. сайт. - Режим доступа: http://ocstans.ru;

4.      YuKoSoft [Электронный ресурс]: офиц. сайт. - Режим доступа: http://it-invent.ru/default.aspx;

5.      Database Harbor Software [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.hwinspector.com/ru/index.php;

6.      The Joomla Project [Электронный ресурс]: офиц. сайт. - Режим доступа: https://www.joomla.org;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/Система управления содержимым;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/IDEF0;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/IDEF3;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/DFD;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/MySQL;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/PHP;

.        НОУ «ИНТУИТ» Архитектура Joomla. Базовые сведения [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.intuit.ru /studies/courses/3731/973/lecture/14904;

14.    Model View Controller (MVC) PHP [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.phpinfo.su/articles/theory/model view controller.html;

.        Википедия [Электронный ресурс]: свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/Тестирование программного обеспечения;

.        НОУ «ИНТУИТ» [Электронный ресурс]: офиц. сайт. - Режим доступа: http://www.intuit.ru/studies/courses/651/507/lecture/11551;

17.    Boehm, B. Software engineering economics / B. Boehm. - NJ: Prentice-Hall, 1981. - 261 с.

18.    Щеглов А. Ю. Защита компьютерной информации от несанкционированного доступа/ А. Ю. Щеглов; ред. М. В. Финков. - Москва: Наука и техника, 2004. - 384 c.