Разработка автоматизированной системы контроля процессов обслуживания кредитовых ведомств ОАО «РЖД»

Аннотация

В данном дипломном проекте разрабатывалась автоматизированная система контроля процессов обслуживания кредитовых ведомств (воинских министерств) ОАО «РЖД».

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

Во второй главе описаны этапы разработки задачи, такие как: выбор источников данных, определение наборов входных и выходных данных. Посредством UML диаграмм вариантов использования, классов, последовательностей и кооперации описаны все функции подсистемы. Основная логика работы системы представлена через диаграммы деятельности. Сформирована объектно-ориентированная БД. Обоснован выбор программного обеспечения для разработки, и описана структурная часть программной разработки. Представлены основные формы отчётов результирующей информации, и проведён анализ результатов, полученных разработанной автоматизированной системой контроля процессов обслуживания кредитовых ведомств ОАО «РЖД».

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

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

В пятой главе произведён расчёт экономической эффективности разрабатываемой системы контроля процессов обслуживания кредитовых ведомств ОАО «РЖД».

В приложении приведены:

· описание вариантов использования;

· основные классы, участвующие в реализации вариантов использования;

· определение обязанностей, атрибутов и ассоциаций классов;

· подробное описание сущностей БД АСККВ;

· формы отчётов;

· исходный код программы;

· руководство пользователей по работе с разработанной системой.

1. АНАЛИЗ СУЩЕСТВУЮЩЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ КОНТРОЛЯ ПРОЦЕССОВ ОБСЛУЖИВАНИЯ КРЕДИТОВЫХ ВЕДОМСТВ (ВОИНСКИХ МИНИСТЕРСТВ) ОАО «РЖД»

1.1 Цель разработки

1.2 Постановка задачи

1.3 Объект автоматизации

1.3.1 Технические средства и показатели системы АСУ «Экспресс-3»

1.3.2 Информационное обеспечение системы АСУ «Экспресс-3»

1.3.3 Таблицы АБД

1.3.4 Таблицы КОЗРВ

1.4 Существующая система контроля процессов обслуживания кредитовых ведомств (воинских министерств) в среде ОАО «РЖД» с использованием данных КОЗРВ

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

1.4.2 Основные достоинства и недостатки системы контроля процессов обслуживания кредитовых ведомств (воинских министерств) в среде ОАО «РЖД» с использованием данных КОЗРВ

1.5 Обоснование целесообразности разработки

1.6 Требования к системе

1.6.1 Требования к системе в целом

1.6.2 Требования к функциям (задачам), выполняемым системой

1.6.3 Требования к архитектуре системы

1.6.4 Требования к видам обеспечения

2. РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ КОНТРОЛЯ ПРОЦЕССОВ ОБСЛУЖИВАНИЯ КРЕДИТОВЫХ ВЕДОМСТВ ОАО «РЖД»

2.1 Выбор источников данных

2.2 Выделение исходных данных

2.2.1 Определение входных данных

2.2.2 Выделение выходных данных

2.3 Анализ разрабатываемой АСККВ с использованием технологии RUP

2.3.1 Моделирование бизнес-процессов (Business UseCase Model)

2.3.2 Модель вариантов использования

2.3.3 Описание вариантов использования

2.3.4 Создание диаграммы вариантов использования

2.3.5 Соглашение по моделированию

2.3.6 Идентификация ключевых абстракций

2.3.7 Анализ вариантов использования

2.3.8 Модель бизнес-анализа

2.3.9 Проектирование БД

2.4. Среда разработки и язык программирования

2.5 Структура программной части АСККВ и формы вывода результирующей информации

2.6 Анализ результатов, полученных автоматизированной системой контроля процессов обслуживания кредитовых ведомств ОАО «РЖД»

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

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

3.1.1 Описание технологии проведения экспертного опроса

3.1.2 Обработка результатов опроса

3.1.3 Конкретизация результатов опроса экспертов

3.1.4 Вывод

3.2 Основные категорий пользователей

3.3 Обоснование компоновки Web-страницы

3.4 Компоновка Web-страницы

3.5 Заключение

4. Системотехнические расчёты

5. Экономическая часть

5.1 Постановка экономической задачи

5.2 Расчёт затрат, связанных с разработкой автоматизированной системы контроля процессов обслуживания кредитовых ведомств ОАО «РЖД»

5.3 Расчёт затрат по эксплуатации автоматизированной системы контроля процессов обслуживания кредитовых ведомств ОАО «РЖД»

5.4 Определение эффективности проекта

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

ГЛОССАРИЙ

Приложение А. Описание вариантов использования АСККВ

А.1 Авторизация пользователя

А.2 Формирование запроса к системе

А.3 Получение результирующей информации

А.4 Администрирование

Приложение B. Основные классы, участвующие в реализации вариантов использования

Приложение C. Определение обязанностей, атрибутов и ассоциаций классов

Приложение D. Подробное описание сущностей БД АСККВ

Приложение E. Формы отчётов

Приложение F. Код программы

Приложение G. Руководство пользователей по работе с системой контроля процессов обслуживания кредитовых ведомств ОАО «РЖД»

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

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

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

Задачей данного дипломного проекта является разработка автоматизированной системы контроля процессов обслуживания кредитовых ведомств ОАО «РЖД» (АСККВ):

· разработка системы, обеспечивающая выдачу информации по дорожным счётчикам кредитовых ведомств агрегированных таблиц АБД (Аналитической Базы Данных) с разбивкой по дорогам, агентам, перевозчикам и кредитовым ведомствам.

1. АНАЛИЗ СУЩЕСТВУЮЩЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ КОНТРОЛЯ ПРОЦЕССОВ ОБСЛУЖИВАНИЯ КРЕДИТОВЫХ ВЕДОМСТВ (ВОИНСКИХ МИНИСТЕРСТВ) ОАО «РЖД»

1.1 Цель разработки

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

1.2 Постановка задачи

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

· сбор показателей из источников, находящихся в таблицах в АБД DB/2 (таблицы «Информация о счётчиках» (DOHODV), «Дороги» (DOR), «Государства» (GOS), «Агенты и перевозчики» (SOBPER), «Льготы» (LGOT));

· выдача показателей в виде таблиц-отчётов в зависимости от набора параметров, введённых пользователем;

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

· контроль доступа пользователя к системе;

· пользовательский интерфейс по вводу исходных данных;

· основные формы отражения информации по кредитовым ведомствам с разбивкой по дорогам и ведомствам, с разбивкой по ведомствам, с разбивкой по ведомствам и агентам, с разбивкой по ведомствам и перевозчикам;

· основную форму отражения итоговой суммы показателей по всем дорогам России по всем ведомствам;

· возможность передачи полученных данных в MS Excel для дальнейшего формирования отчёта;

· контроль доступа для пользователей по дорогам;

· контроль доступа для пользователей по кодам агента и перевозчика.

1.3 Объект автоматизации

Объектом автоматизации в дипломном проекте выбрана АСУ «Экспресс-3». В пассажирском хозяйстве сети железных дорог система «Экспресс-3», являясь базой информатизации, обеспечивает решение основных стратегических задач по увеличению объемов перевозок пассажиров и сокращению транспортных расходов. С помощью системы «Экспресс-3» осуществляется сбор и обработка информации, необходимой для принятия оперативных решений по регулированию перевозок, снижению затрат и получению дополнительных доходов.

Система «Экспресс-3»:

· работает в реальном масштабе времени с большим числом абонентов (в т.ч. билетными кассами),

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

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

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

Целями создания «Экспресс-3» являются:

· повышение эффективности перевозочного процесса за счёт организации оперативного управления;

· улучшение уровня обслуживания и предоставления различных сервисных услуг пассажирам;

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

· реализация механизма автоматизации взаиморасчётов за перевозки;

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

Система «Экспресс-3» базируется:

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

· на обеспечении защиты информации от несанкционированного доступа;

· на автоматизированном взаимодействии с другими аналогичными системами железных дорог и разных видов транспорта.

1.3.1 Технические средства и показатели системы АСУ «Экспресс-3»

В структурном плане технические средства системы «Экспресс-3» состоят из 4-х основных частей:

· вычислительный комплекс: 2 центра обработки данных (HOST-ЭВМ) — IBM z10, z990;

· периферийное оборудование — кассовые терминалы, специализированные АРМ, специализированные принтеры для печати билетов и багажных ярлыков, технологические принтеры, сканеры машиночитаемых документов, информационно-справочные установки, визуальные системы коллективного пользования;

· сетевое оборудование — сети TCP;

· средства обеспечения информационной безопасности на основе VipNet.

Основные технические характеристики АСУ «Экспресс-3», которые относятся ко всем системам, устанавливаемым на дорогах России, СНГ и Балтии, приведены в табл. 1.1.

Таблица 1.1 — Основные технические характеристики АСУ «Экспресс-3»

1.3.2 Информационное обеспечение системы АСУ «Экспресс-3»

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

Основой информационной среды является система баз данных управления перевозочным процессом и ее составная часть — база данных для управления пассажирскими перевозками. Ядром базы данных управления пассажирскими перевозками является база данных, необходимая для функционирования системы управления резервированием мест и продажей железнодорожных билетов «Экспресс-3».

Система предъявляет к базе данных взаимоисключающие требования:

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

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

· постоянно обновляющиеся данные, отражающие текущее состояние управления пассажирскими перевозками;

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

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

· КОЗРВ (Комплекс обработки заказов реального времени) — оперативная база данных, содержащая информацию об оперативном обслуживании пассажиров;

· АБД (Аналитическая база данных) — единая аналитическая база данных ОАО «РЖД», в которую поступают все проездные документы и информация об исполненных рейсах поездов и вагонов. В АБД поступают данные о перевозках ОАО «РЖД» из всех действующих систем «Экспресс-3». АБД обеспечивает хранение агрегированной информации не менее 3-х лет.

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

На основе АБД разработаны и внедрены на РЖД программно-аналитические комплексы, обеспечивающие проведение:

· маркетинговых исследований рынка пассажирских перевозок;

· оперативного отслеживания финансовых результатов работы пассажирского подвижного состава;

· контроля качества использования пассажирских вагонов;

· прогноза объемов перевозок.

1.3.3 Таблицы АБД

Аналитическая база данных хранит в себе следующие таблицы:

1) первичная информация (документы) ;

2) накопительные таблицы;

3) результаты работы поездов;

4) нормативно-справочная информация;

5) служебные таблицы;

6) отдельные подсистемы.

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

1) заполняемые в реальном режиме времени;

2) заполняемые ежесуточно.

Таблицы «результаты работы поездов» и «нормативно-справочная информация» разделяются на 2 группы:

1) ежесуточно;

2) ежемесячно.

Первичная информация, формируемая в реальном режиме времени:

· проездные документы (бланки, места, паспорта, стоимость, возврат) ;

· запросы (запросы, тексты документов, выданных терминалом, запросы по Р06) ;

· групповые заявки и заявки по паролю;

· утерянные транспортные и воинские требования, попытки оформления по утерянным требованиям;

· опоздания поездов;

· перевозочные документы;

· пригородные документы.

Первичная информация, формируемая ежесуточно

· рейсы поездов и вагонов, норма мест, предложенная к продаже (RNIT, RMRT, NMRVAG, NBRVAG);

· маршруты поездов и календари (NIT, MRT, KALEND);

· суточные финансовые отчёты по терминалам (DOHOD, DOHODV);

· характеристики терминалов (TERM).

Накопительные таблицы, формируемые в реальном режиме времени

· корреспонденции пассажиропотоков с учётом поезда, вагона, категории поездки, категории пассажира, даты продажи и отправления, станции продажи, доходных поступлений (RMEST);

· багажные отправки (BAGOTP);

· багажные отправки по государствам следования (BAGGOS).

Накопительные таблицы, формируемые ежесуточно

· корреспонденции пассажиропотоков по поездам, вагонам, категориям поездки и пассажиров, станции продажи, дате отправления (IRMEST);

· постанционное отправление (по категориям поездов и вагонов) — S3960;

· багажные отправки за месяц (MBAGOTP);

· багажные отправки по государствам следования за месяц (MBAGGOS).

Результаты работы поездов — посуточные Формируются ежесуточно по законченным рейсам поездов

За каждый рейс поезда:

· пассажирские поезда — PZDP;

· маршруты групп вагонов — DVMRT;

· результаты по группам вагонов — REZVAG;

· результаты по дорогам следования — REZMRT.

Результаты работы поездов — месячные

Формируется ежесуточно по накоплению с начала месяца — по категориям поездов и вагонов — NMREZD, NMSREZD

Формируются 6-го числа месяца За каждый рейс поезда:

· пассажирские поезда — MPZDP;

· маршруты групп вагонов — MDVMRT;

· результаты по группам вагонов — MREZVAG;

· результаты по дорогам следования — MREZMRT.

НСИ, обновляемая ежесуточно:

· вагонные предприятия (LINPR);

· валютные курсы (VKURS);

· сервисные услуги (TARIFS);

· константы сервисных услуг (TARIFK).

НСИ, обновляемая при изменении:

· станции — STAN;

· линии — LINES;

· льготы — LGOT;

· города — GOR;

· дороги (DOR) и государства (GOS);

· перевозчики (SOBPER);

· классы обслуживания (KLOV).

Служебные таблицы:

· регистрация пользователей (пользователи, их IP адреса, приложения, допуск пользователей к приложениям);

· статистка работы пользователей;

· журнал запросов пользователей к таблицам с информацией о пассажирах;

· контроль заполнения первичных и накопительных таблиц;

· профили пользователей в конкретных АРМ.

АРМ’ы могут вносить изменения только в служебные таблицы.

Сроки хранения информации в АБД:

· первичные документы — 13 месяцев;

· накопительные таблицы и результаты работы поездов — текущий и 2 предыдущих года;

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

1.3.4 Таблицы КОЗРВ

Комплекс обработки заказов реального времени хранит в себе следующие таблицы:

1) программные таблицы;

2) таблицы ОП;

3) таблицы DB2;

4) массивы ОП;

5) НСИ — условно постоянная информация;

6) НСИ — переменная информация;

7) переменная информация — изменяющаяся при обработке заказов пользователей;

8) вторичные таблицы;

9) временная информация.

Таблицы ОП:

· таблица поездов (TPZ);

· параметры системы (PARM);

· таблица городов (TGOR).

Программные таблицы:

· дороги, ж.д.администрации, государства (TSNG);

· льготы и виды проездных документов (TLGOT);

· классы обслуживания (TKL);

· перевозчики (TOWN).

Таблицы DB2:

· станции (STANV) и линии (LIN);

· эталонный файл поездов (FPZ);

· эталонный файл вагонов (CARSE).

Язык общения с системой «Экспресс-3»

· Ключ (латинская буква) — значение;

· вид работы (Р);

· D — дата D1505;

· N — номер поезда N104M;

· С — станция (код или название);

· X — документ;

· G, R — подвид работы;

· B — вагон (категория, номер, класс обслуживания);

· W — номер заказа, документа (штрихкод).

Основные виды работ:

· P01 — отчет кассира;

· P10 — продажа проездных документов;

· P62 — справочная информация;

· P20 — возврат проездных документов;

· P25 — гашение проездных документов;

· P38 — справка о билетах, купленных через Интернет;

· P22 R010 — выдача проездных документов, купленных через Интернет;

· P22 R022 — выдача дубликатов проездных документов;

· P22 — частичный возврат проездных документов.

Виды работ:

· P17 — резервирование и продажа групповых проездных документов;

· P12 — продажа проездных документов через бюро заказов;

· P14 — продажа через диспетчерский терминал;

· P23 — переоформление билетов;

· P24 — прерывание поездки и остановка в пути следования;

· P28 — электронная регистрация проездного документа;

· P36 G1530 — Ведомость электронных билетов;

· P36 G1400 — Схема состава поезда;

· P36 G1510 — Занятые поездки в вагоне;

· P36 G1520 — Cвободные поездки в вагоне;

· P06 — Ввод и оперативная корректировка нормативно — справочной информации;

· P71 — Оформление багажа, грузобагажа и почты;

· P64 — Оформление пригородных проездных документов;

· P02 — Оформление квитанций добровольного страхования;

· P52 и P30 — Выдача оперативной финансовой отчетности;

· P41 — P47 — Оформление проездных документов в дальнее зарубежье;

· P63 — Справка о тарифах в пригородном сообщении.

P62 — справочная информация:

· G11 — расписание между 2-мя станциями;

· G15 — номера поездов;

· G18 — расписание поезда по маршруту;

· G19 — расписание поездов по станции;

· G30 — стоимость проезда;

· G31 — стоимость проезда льготных пасс;

· G32 — курсы валют;

· G40 — даты курсирования поезда;

· G46 — схема состава поезда;

· G50 — опоздание поезда по станции;

· G51 — список опаздывающих поездов;

· G53 — опоздания поезда по маршруту;

· G60 — наличие мест от станций Украины;

· G61 — наличие мест по поезду от Украины

· G62 — наличие мест и стоимость проезда по поезду (группе поездов);

· G63 — наличие мест и стоимость проезда между заданными станциями;

· G69 — наличие мест для табло коллективного пользования;

· G72−77 — правила перевозки пассажиров;

· G90 — стоимость перевозки багажа и грузобагажа.

1.4 Существующая система контроля процессов обслуживания кредитовых ведомств (воинских министерств) в среде ОАО «РЖД» с использованием данных КОЗРВ

Существующая система контроля процессов обслуживания кредитовых ведомств с использованием данных КОЗРВ имеет модель двухуровневой клиент-серверной архитектурой, в которой пользовательские сервисы реализованы на клиентских неинтеллектуальных терминалах, а данные централизованно хранятся на сервере.

Процесс разработки отчёта технологом по запросу «Выдача информации о дорожных счётчиках кредитовых ведомств» (P52R37) включает следующие подсистемы:

1) подсистема ввода текста запроса на терминале (среднее время выполнения данной операции 2 минуты);

P52 R37- выдача информации о дорожных счётчиках по кредитовым ведомствам:

· G100М — за 5-тидневку;

· G200М — за месяц.

2) подсистема обработки запроса автоматизированной системой «Экспресс-3» и получение ответа в виде строки данных (доступ к данным, хранящимся в КОЗРВ);

Результат, полученный в виде строки данных в существующей системе:

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

1.4.1.1 Постановка условий по существующей системе

Процесс разработки отчёта технологом по запросу «Выдача информации о дорожных счётчиках кредитовых ведомств» (P52R37) в существующей системе включает следующие действия:

1) написание текста запроса — среднее время выполнения данной операции 2 минуты;

2) обработка запроса автоматизированной системой «Экспресс-3» и получение ответа в виде строки данных (доступ к данным, хранящимся в КОЗРВ);

3) формирование отчёта в формате Excel по полученным данным — норма времени для данной операции 9 минут.

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

Поток запросов на получения информации для отчёта — простейший с интенсивностью л=126 (1/мес.).

1.4.1.2 Постановка условий по проектируемой системе

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

1) выбор необходимых для запроса параметров (среднее время выполнения данной операции — 12 сек);

2) обработка запроса АСККВ и получение ответа в виде html-страницы (доступ к данным, хранящимся в АБД АСУ «Экспресс-3»);

3) формирование отчёта в формате Excel.

Поток запросов на получения информации для отчёта — простейший с интенсивностью л=126 (1/мес.).

1.4.1.3 Постановка задачи

1) рассчитать среднее время обслуживания в существующей системе;

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

3) рассчитать предельный эффект и относительный предельный эффект перехода к системе контроля процессов обслуживания кредитовых ведомств ОАО «РЖД» с использованием АРМ (Автоматизированного Рабочего Места);

4) обосновать целесообразность получения необходимого отчёта с помощью АРМ сокращением среднего времени написания запроса и сокращением нормы времени формирования отчёта;

1.4.1.4 Расчёт среднего времени обслуживания в существующей системе

л=126 (1/мес.) — интенсивность поступления заявок за 1 рабочий месяц

1 раб.мес. = 21 раб. день

1 раб. день = 8 часам

л=6 (1/день)=0,0125 (1/мин)

Интенсивность обслуживания потока заявок

µ=1/mx, (1.1)

где mx — среднее время обработки, мин.

Рисунок 1.6 — Модель процесса получения результирующего отчёта в существующей системе

1) среднее время написания запроса

m1x=2 мин

µ1=1/m1x=0,5 (1/мин) — интенсивность обслуживания потока заявок

2) норма времени формирования отчёта в формате Excel

m3x=9 мин

µ3=1/m3x=0,11 (1/мин) — интенсивность формирования отчёта в формиате Excel

3) среднее время обслуживания в существующей системе

mT обслуж = m1T + m2T + m3T, (1.2)

где m1T, m2T, m3T среднее время обработки операции

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

mT обслуж = m1T + m3T, (1.3)

где m1T, m3T среднее время обработки операции.

4) среднее время пребывания заявки в существующей системе

m1T= m1Х + m1W, (1.4)

где m1Х — среднее время обработки заявки в системе;

m1W — среднее время ожидания заявки в очереди.

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

m1T=(µ1- л)-1, (1.5)

где µ1 — интенсивность обслуживания потока заявок;

л — интенсивность поступления заявок.

m1T=2,04 мин

m3T=9 мин — т.к. норма времени выполнения операции включает в себя время ожидания в очереди

mT обслуж=2,04+9=11,04 мин — среднее время обслуживания в существующей системе.

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

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

л=126 (1/мес.) — интенсивность поступления заявок за 1 рабочий месяц

1 раб.мес. = 21 раб. день

1 раб. день = 8 часам

л=6 (1/день)=0,0125 (1/мин)

Рисунок 1.7 — Модель процесса получения результирующего отчёта в проектируемой системе с использованием АРМ

1) среднее время написания запроса

m1x=12 сек = 0,2 мин

µ1=1/m1x=5 (1/мин) — интенсивность обслуживания потока заявок

2) среднее время обслуживания в существующей системе

mT* обслуж = m1T + m2T + m3T

Передача запроса инженер-технологом с персонального компьютера, подключенного к СПД ОАО «РЖД» на центральную ЭВМ осуществляется по каналам связи, число которых, а также пропускную способность определяют при проектировании. Поэтому, оценивая предельный эффект, мы можем пренебречь временами обработки запроса и получением ответа, т. е. для расчёта не учитываем m2T.

Формирование отчёта будет происходить автоматическим экспортированием системой полученных данных в Excel. Пользователю необходимо будет только нажать на кнопку «Передать в Excel», поэтому мы пренебрегаем m3T

mT* обслуж = m1T

m1T=(µ1- л)-1 — среднее время пребывания в существующей одноканальной системе

m1T=(5−0,0125)-1 = 1,25 мин

mT *обслуж = 1,25 мин — среднее время обслуживания в системе с использованием АРМа

1.4.1.6 Расчёт предельного эффекта и относительного предельного эффекта перехода к системе контроля процессов обслуживания кредитовых ведомств с использованием АРМ

Предельный эффект перехода:

Э*= mT обслуж — mT *обслуж, (1.6)

где mT обслуж — среднее время обслуживания в существующей системе;

mT *обслуж — среднее время обслуживания в системе с использованием АРМа

Э*=11,04−1,25=9,79 мин

Относительный предельный эффект перехода:

Э*относит = Э* * 100% / mT обслуж, (1.7)

где Э* - предельный эффект перехода;

mT обслуж — среднее время обслуживания в существующей системе.

Э*относит = 9,79*100% / 11,04 = 0,89 *100% = 89%

1.4.2 Основные достоинства и недостатки системы контроля процессов обслуживания кредитовых ведомств (воинских министерств) в среде ОАО «РЖД» с использованием данных КОЗРВ

Достоинства системы:

· имеется возможность оперативного получения информации об оперативном обслуживании пассажиров;

· сниженные требования к техническим характеристикам терминалов.

Недостатки системы:

· увеличенная нагрузка на HOST-ЭВМ, обрабатывающая запросы с данными КОЗРВ;

· процесс получения результирующей информации требует наличие терминала;

· ограниченный круг пользователей, т.к. общение с КОЗРВ требует определённых навыков обращения с терминалом;

· процесс получения результирующей информации требует больших временных затрат;

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

· отсутствие автоматизированной процедуры получения отчёта по результирующей информации;

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

· содержание выходной результирующей информации неудобочитаемое.

1.5 Обоснование целесообразности разработки

На основании проведённых расчётов и анализа основных достоинств и недостатков системы контроля процессов обслуживания кредитовых ведомств (воинских министерств) с использованием данных КОЗРВ можно сделать вывод о том, что при переходе на систему с использованием АРМ предельный эффект составит 9,79 мин. и относительный предельный эффект составит 89%. В результате разработки система будет обеспечивать выдачу информации по дорожным кредитовым ведомствам агрегированных таблиц АБД (Аналитической Базы Данных) с разбивкой по дорогам, агентам, перевозчикам и кредитовым ведомствам.

Разрабатываемое приложение будет доступно для пользователя посредством web-браузера ПК через сеть передачи данных (СПД) ОАО «РЖД». Использование архитектуры «клиент-сервер» даёт ряд преимуществ по сравнению с моделью распределённого представления данных:

· масштабируемость;

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

· высокая безопасность;

· высокая надёжность;

· низкие требования к скорости канала (сети) между терминалами и сервером приложений;

· низкие требования к производительности и техническим характеристикам терминалов, как следствие снижение их стоимости;

· компьютер пользователя выступает в роли «тонкого клиента».

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

1.6 Требования к системе

1.6.1 Требования к системе в целом

1.6.1.1 Требования к структуре и функционированию системы

1.6.1.1.1 Перечень подсистем, их назначение и основные характеристики

1) Подсистема сбора входных данных пользователя:

предназначена для контроля доступа пользователя к системе и для сбора параметров, введённых пользователем при работе с системой АСККВ.

2) Подсистема обработки данных:

предназначена для формирования и обработки запроса по дорожным счётчикам к агрегированным таблицам АБД.

3) Подсистема вывода результата:

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

4) Подсистема формирования отчёта:

предназначена для автоматического экспорта полученных данных в MS Excel и формирования отчёта;

5) Подсистема анализа результатов:

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

1.6.1.1.2 Требования к характеристикам взаимосвязей разрабатываемой системы со смежными системами

АСККВ должна использовать данные АБД смежной АСУ «Экспресс-3»

· АСККВ должна использовать среду СПД ОАО «РЖД» для информационного обмена с пользователями, информационными исходными данными АБД АСУ «Экспресс-3»;

· в качестве базового протокола сетевого и межсетевого взаимодействия должен использоваться TCP/IP;

· средством организации информационного обмена со стороны пользователя должен быть стандартный Интернет-браузер (Internet Explorer 7.0 и выше).

1.6.1.1.3 Требования к режимам функционирования системы

Разрабатываемая АСККВ должна функционировать в следующих режимах:

· основной режим;

· тестовый режим;

· профилактический режим.

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

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

· первоначальная загрузка или реконфигурация программных средств;

· модернизация аппаратных и программных средств.

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

1.6.1.2 Требования к численности и квалификации персонала системы

Для эксплуатации АСККВ определены следующие роли (категории пользователей):

1) Администраторы: модернизация, настройка и мониторинг работоспособности системы, ведение учетных записей пользователей системы, (рекомендуемая численность — 2 штатных единицы);

2) Пользователи системы (численность персонала определяется количеством дирекций по обслуживанию пассажиров ОАО «РЖД»):

· уровень Региональной дирекции (РД) (возможен доступ к данным по своему региону);

· уровень Центральной дирекции (ЦД) (возможен доступ к данным по всем регионам).

При заданных технических характеристиках рекомендуемое максимальное количество одновременных пользовательских сеансов должно быть не более 1000.

Администраторы должны иметь соответствующую квалификацию в области работы с вычислительной техникой и информационными системами.

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

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

1.6.1.3 Требования к защите информации от несанкционированного доступа

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

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

· администратор информационной системы;

По доступу к дорогам:

· пользователь с доступом к информации по всем дорогам России (сетевой уровень);

· пользователь с доступом к информации по определённой дороге;

· администратор с доступом к информации по всем дорогам России и странам СНГ.

По доступу к кодам агентов и перевозчиков:

· пользователь с доступом к информации по определённому коду перевозчика;

· пользователь с доступом к информации по определённому коду агента;

· пользователь с доступом к информации по определённым кодам агента и перевозчика;

· администратор с доступом к информации по всем кодам агентов и перевозчиков.

1.6.2 Требования к функциям (задачам), выполняемым системой

1) Перечень функциональных подсистем АСККВ указан в пункте 1.6.1.1.1

2) Подсистема сбора входных данных пользователя:

предназначена для контроля доступа пользователя к системе и для сбора параметров, введённых пользователем при работе с системой АСККВ.

Подсистема сбора входных данных должна:

· иметь 4 возможности заполнения поля «дата»:

o день, месяц и год;

o отчётная дата (вчерашняя дата);

o интервал дней (пятидневка), месяц и год;

o месяц и год.

· иметь 3 возможности заполнения поля «дорога»:

o все дороги сети (выдача информации по всем дорогам сети с разбивкой по дорогам и кредитовым ведомствам);

o определённая дорога из приведённого списка (выдача информации по выбранной дороге с разбивкой по ведомствам);

o сумма по дорогам России (выдача итоговой суммы показателей счётчиков по всем дорогам России и по ведомствам);

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

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

3) Подсистема обработки данных:

предназначена для формирования запроса по дорожным счётчикам к агрегированным таблицам АБД.

Подсистема обработки данных должна:

· формировать запрос к агрегированным таблицам АБД системы на основе введённых пользователем данных;

· обрабатывать запрос на стороне АБД;

· выполнять сбор показателей из источников, находящихся в виде таблиц в БД DB/2 (таблицы «Информация о счётчиках» (DOHODV), «Дороги» (DOR), «Государства» (GOS), «Агенты и перевозчики» (SOBPER), «Льготы» (LGOT));

· формировать результат, необходимый для выдачи отчёта.

4) Подсистема вывода результата:

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

Подсистема вывода результата должна:

· обеспечивать выдачу информации по определённой дороге или сумме по дорогам России с разбивкой по ведомствам и агентам или по ведомствам и перевозчикам;

· обеспечивать выдачу итоговой суммы показателей по всем дорогам России по всем ведомствам;

5) Подсистема формирования отчёта:

предназначена для автоматического экспорта полученных данных в MS Excel и формирования отчёта;

6) Подсистема анализа результатов:

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

1.6.3 Требования к архитектуре системы

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

· сервер баз данных;

· сервер приложений;

· клиентское программное обеспечение.

Рисунок 1.9 — Трехзвенная архитектура «клиент-сервер» с сервером приложений и сервером БД на одном интегрированном сервере (IBM Z800)

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

На сервере приложений будет работать АСККВ.

1.6.4 Требования к видам обеспечения

1.6.4.1 Требования к информационному обеспечению

Сервер системы должен быть подключен к сети передачи данных (СПД) ОАО «РЖД» для периодической синхронизации с АСУ «Экспресс-3».

Для хранения всех информационных массивов должна использоваться единая система управления базами данных (далее — СУБД), отвечающая следующим требованиям:

· поддержка реляционной или объектно-реляционной модели базы данных;

· поддержка технологии клиент-сервер.

1.6.4.2 Требования к программному обеспечению

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

Пользовательские Web-приложения должны быть разработаны с использованием Web-технологий (студия Rational Application Developer ver 7.0.0.4 и Java) с учётом эксплуатации операционной системы MS Windows XP/Vista и браузера MS Internet Explorer версии 7.0 или выше.

Программным обеспечением на стороне сервера является сервер приложений IBM WebSphere Application Server ver.6.0 (WAS) и СУБД.

Для соединения сервера приложений с СУБД требуется Java DataBase Connectivity (JDBC) драйвер. JDBC драйвер доступен для СУБД DB2 ver.9.

Операционной системой сервера является z/OS ver.1.8.

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

· процессор Intel Pentium 500МГц (или аналогичный);

· 128 МБ оперативной памяти;

· 5 ГБ дискового пространства;

· наличие доступа к СПД ОАО «РЖД»;

· наличие монитора с разрешением не ниже 1024*768;

· клавиатура и мышь.

Рекомендуемые аппаратные требования к серверу, призванные обеспечить бесперебойную работу необходимого программного обеспечения (операционная система, сервер приложений, СУБД), таковы:

· 4 ГБ оперативная память;

· от 15 ГБ дискового пространства;

· наличие канала сети передачи данных от 100 Мбит/сек.

2. РЕАЛИЗАЦИЯ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ КОНТРОЛЯ ПРОЦЕССОВ ОБСЛУЖИВАНИЯ КРЕДИТОВЫХ ВЕДОМСТВ ОАО «РЖД»

2.1 Выбор источников данных

Для функционирования АСККВ будут использоваться данные, хранящиеся в АБД АСУ «Экспресс-3», а также:

· отчёт о работе автоматизированных рабочих мест АБД АСУ «Экспресс-3»;

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

· отчёт по структуре АБД (DBKLAS);

· отчёт по структуре АБД (EXPBD);

· презентационный материал «Аналитическая база данных „Экспресс-3“. Принципы формирования информации, информационные потоки, классификация информации и прикладных задач».

2.2 Выделение исходных данных

2.2.1 Определение входных данных

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

Таблица 2.1 — Перечень входных данных

2.2.2 Выделение выходных данных

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

Таблица 2.2 — Перечень дорожных счётчиков

2.3 Анализ разрабатываемой АСККВ с использованием технологии RUP

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

Rational Unified Process (RUP) — одна из лучших методологий разработки информационных систем, созданная компанией IBM Rational Software. В технологии RUP реализован один из вариантов объектно-ориентированного подхода (ООП) к проектированию ИС.

RUP технология позволяет:

· разрабатывать ИС на основе итерационного подхода;

· проектировать систему с помощью визуальных средств;

· управлять требованиями наиболее эффективными способами;

· использовать компонентный подход;

· гарантировать качество создаваемых продуктов;

· контролировать любые изменения в ходе проекта.

RUP технология использует в качестве визуального средства моделирования язык UML (Unified Modeling Language). UML представляет разработчикам чёткую нотацию, позволяющую отображать модели общепринятыми и понятными каждому участнику проекта графическими элементами.

2.3.1 Моделирование бизнес-процессов (Business UseCase Model)

Цель создания системы — разработка автоматизированной системы формирования показателей в виде таблиц-отчётов и графиков в зависимости от набора параметров, введённых пользователем.

Задание состоит из следующих шагов:

1) Построить бизнес-модель вариантов использования (Business UseCase Model):

· выделить действующие лица (актёры) системы;

· выделить варианты использования;

· построить и описать диаграммы вариантов использования.

2) Выполнить анализ вариантов использования:

· идентификация классов, участвующих в потоках событий вариантов использования (Class Diagram);

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

· создание диаграмм взаимодействия (Sequence Diagram, Collaboration Diagram);

· определение обязанностей, атрибутов и ассоциаций классов в формате:

o диаграммы классов с операциями «анализа»;

o классы с операциями «анализа» и атрибутами;

o диаграммы классов сущностей;

o полная диаграмма классов для вариантов использования;

o интегрированная диаграмма классов для проекта системы.

3) Создать модель бизнес-анализа (в терминах «Business Worker» и «Business Entity»):

· построение диаграммы классов модели бизнес-анализа (Class Diagram);

· построение диаграмм взаимодействия (Sequence Diagram, Collaboration Diagram);

· построение диаграмм деятельности и состояния (Activity Diagram, Statechart Diagram).

4) Выполнить проектирование базы данных (БД) (Используя специальный инструмент Rational SoftWare — Data Modeler) на основании моделей бизнес-анализа.

2.3.2 Модель вариантов использования

2.3.2.1 Выделение актёров