Оптимізація сукупної вартості міжсистемних інтерфейсів

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Оптимізація сукупної вартості міжсистемних інтерфейсів

Сураєв В.Ф., Мазур В.І., Іванкевич О.В.

ОПТИМИЗАЦИЯ СОВОКУПНОЙ СТОИМОСТИ МЕЖСИСТЕМНЫХ ИНТЕРФЕЙСОВ

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

Ключевые слова: информационная среда.модель. межсистемный интерфейс. стоимость. авиакомпания.

Suraiev V.F., Mazur V.I., Ivankevich. A.V.

COST REDUCTION OF INTERSYSTEM INTERFACES

The analysis of information environment components of the airline suggests use simplified models of systems totality. The cost of developing and adjusting of the new intersystem interface decreases with an increase in the number of existing interfaces. Manual start of import, export and data processing operations proposed in cases of operational data processing. The use of such approaches gives real cost reduction for intersystem interfaces creating in “Ukraine International Airline ” applications landscape.

Keywords: information environment, model, intersystem interface, cost, airline.

Мета дослідження

Мета роботи - розробка підходів до аналізу властивостей та оптимізації сукупної вартості міжсистемних інтерфейсів, що створюються в середовищі розподіленої інформаційної мережі сучасного авіапідприємства. Зробимо це на прикладі найбільшої в Україні авіакомпанії «Міжнародні авіалінії України».

Об'єкт дослідження

Ландшафт прикладень авіакомпанії складається з глобальних систем, таких, як системи бронювання та продажу авіаперевезень, системи навігації, системи DCS (Departure Control System) і відносно незалежних систем авіакомпанії. Прикладами таких є системи MRO (Maintenance Repair and Overhaul) [1], системи ERP (Enterprise Resource Planning) [2] та інші. Майже всі вони зв'язані між собою міжсистемними інтерфейсами, яких в розподіленій мережі нараховуються сотні.

Порівняння інтерфейсних можливостей систем

Розглянемо деякі системи з метою порівняння їх інтерфейсних можливостей.

AMOS - система зберігання та обробки даних про технічне обслуговування та ремонт літаків, що розроблена фірмою Swiss Aviation Software[3], є сучасним розвиненим представником систем класу MRO, яка експлуатується в десятках авіакомпаній по всьому світу. Можливості обміну даними з іншими системами включають кілька каналів імпорту даних, можливості експорту даних в багатьох форматах, потужний засіб генерування звітів, великий набір процедур обробки даних, що може поповнюватися новими, та розвинений модуль автоматизованого відпрацювання задач за розкладом.

Microsoft Dynamics Navision - система класу ERP [4]. Використовується в багатьох середніх та великих підприємствах,в тому числі в десятках авіакомпаній, по всьому світу, перш за все, як система обробки фінансових даних та планування ресурсів. Серед модулів, що забезпечують можливості обміну даними в середовищі інформаційної мережі, треба виділити XML-порти, що можуть бути налаштовані як на імпорт, так і на експорт даних, сотні заздалегідь розроблених звітів, що перекривають майже всі потреби управління підприємством, можливості розробки нових звітів та процедур обробки даних на вбудованій мові програмування C/L, наявність багатьох каналів введення та виведення даних, включаючи WEB-сервіси, інтегрування з прикладеннями Microsoft Office. Також до складу системи входить механізм створення та відпрацювання завдань, що збираються в черги та запускаються за розкладом автоматично.

Microsoft SQL Server - платформа баз даних, що є однією з найбільш поширених в світі, виконує не тільки функції зберігання даних, а і засобу розробки та використання бізнес-логіки [5]. І ще важливіше з точки зору інтеграції складових інформаційної мережі підприємства те, що саме ця система в даному випадку стала основою для функціонування інших систем. Так і база даних AMOS і база даних Microsoft Dynamics Navision побудовані в середовищі Microsoft SQL Server. І все ж незважаючи на це, ця платформа може бути розглянута як незалежна система зі своїми інтерфейсними можливостями. Вона також має вбудовані засоби імпорту даних у вигляді файлів формату XML або CSV, механізми для виведення або експорту даних, можливості інтеграції з віддаленими серверами баз даних, засоби створення та розсилки поштових повідомлень, можливості розробки та використання бізнес-логіки, як у вигляді процедур, що зберігаються, розроблених на мові програмування SQL, так і у вигляді інтеграційних пакетів, створених у будь-яких середовищах розробки. Як і інші системи, Microsoft SQL Server підтримує можливості розробки та автоматичного використання завдань за розкладом.

Моделювання сукупності інтерфейсів

Порівняльний аналіз можливостей цих систем дає змогу зробити висновок про те, що їх інтерфейсні можливості майже не відрізняються між собою за наявними складовими. Завжди є модулі імпорту даних у форматах, що вже давно стали типовими, такими, як текстовий з розподільниками, структурованими документами XML, інші. Майже завжди є засоби створення та використання бізнес-логіки, генератори репортів, інше. У наявності розвинені можливості експорту даних за різними каналами: файлові, WEB-сервіси, модулі підготовки та відправки поштових повідомлень, інше. Важко уявити розвинену систему, у якій був би відсутній засіб для автоматичного старту виконання багатокрокових процедур імпорту, перетворення та експорту даних, у відповідності до визначеного розкладу.

Зважаючи на цей висновок припустимо, що інформаційне середовище має вигляд сукупності однакових за функціональними можливостями систем, кожна з яких включає модулі імпорту L, модулі обробки даних P, модулі експорту E та модулі автоматичного планування та старту завдань S. В такому разі інтерфейс між системами I та J має вигляд

Рис. 1

Математичну модель сукупності міжсистемних інтерфейсів інформаційного середовища будь-якої складності можна побудувати на базі використання: кінцевої множини модулів імпорту даних L; кінцевої множини модулів експорту даних E; безкінечної множини можливих модулів обробки даних P; кінцевої множини модулів автоматичного старту процедур S. Визначимо кінцеве співвідношення існуючих каналів передачі даних K, як K = {k| k€ EхL} та побудуємо співвідношення можливих інтерфейсів A для всієї сукупності існуючих на даний момент інформаційних систем A= {a| a € (S vM) xP xK} ,де M - кінцева множина засобів неавтоматизованого старту процедур у вигляді дій користувачів. Співвідношення A є безкінечною, завдяки безкінечній множині P. Кожен з елементів множини A має вигляд a=(s,p,e,l) або a=(m,p,e,l) з координатами множин S, M, P, Eта L відповідно.

Аналіз можливостей зменшення сукупної вартості

Проаналізуємо складові частини сукупної вартості інтерфейсів співвідношення A. Вартість розробки існує тільки для елементів множини P. Для елементів множини S існує вартість налагодження. Інші елементи є складові частини систем, що не підлягають розробкам або налагодження. Тому нам досить розглянути лише проекції співвідношення A на множини Sта P PrS(A)={s| s € S} і PrP(A)={p| p € P}. PrS(A) - це проекція на кінцеву множину, тому робимо висновок, що складова вартості налагодження стрімко зростає тільки на початкових етапах життя розподіленої інформаційної системи. При збільшенні кількості інтерфейсів ця складова переходить до стану насичення, тобто вартість нових налагоджень прагне до нуля. Вартість створення модулів обробки даних залежить від проекції PrP(A) на безкінечну множину, то зменшити її можна лише за рахунок відмови від обробки даних в інтерфейсах. Це цілком природньо, тому, що взагалі інтерфейси призначені перш за все для перенесення даних, а обробку доцільно виконувати тими засобами, які для цього призначені і де можна досягти кращих співвідношень ціна/якість. І все ж на практиці не завжди вдається відмовитись від розробки і використання бізнес-логіки у складі інтерфейсів.

Іншим шляхом до зменшення вартості інтерфейсів є відмова від модулів автоматичного планування та старту процедур та перехід до використання засобів неавтоматизованого старту процедур з множини M.

В авіакомпанії «Міжнародні авіалінії України» на протязі останніх років впроваджуються процедури неавтоматизованого старту завдань, перш за все на ділянках опрацювання даних, де присутність людини є обов'язковою. Відправка поштового повідомлення із завданням на виконання потрібного процесу імпорту, обробки, експорту даних або їх будь-якої комбінації робиться в ручному режимі на вхідну поштову адресу, де всі повідомлення будуть переглянуті спеціальною програмою. Виконуючи достатньо простий аналіз повідомлень, наприклад виділення з теми листа ключових слів, програма може вирішити, яку саму процедуру треба виконати. Виділені з тексту значення параметрів також можуть бути використані в команді запуску визначеної процедури.

Таке рішення в побудові інтерфейсів має переваги на відміну від використання автоматизованого старту процедур за розкладом. По перше, зростає якість даних, що імпортуються, завдяки тому, що мінімізується час між стартом імпорту та початком обробки і в опрацювання надходять більш актуальні дані. І саме це стало основною причиною переходу до використання в авіакомпанії неавтоматизованого старту на найбільш чутливих до «старіння даних» процесах. По друге, використання цього способу старту процедур на практиці приводить до того, що зменшується навантаження на використання ресурсів інформаційних систем, оскільки старт виконується не періодично, а тільки в разі необхідності. І нарешті в цьому разі немає складової вартості налагодження модулів автоматичного планування та старту завдань.

Результати дослідження

міжсистемний інтерфейс модуль

На основі аналізу складових інформаційного середовища авіапідприємства запропоновано використання спрощеної моделі сукупності систем. Доведено, що в умовах насичення ландшафту прикладень міжсистемними інтерфейсами вартість створення нових зменшується. Запропоновано використання неавтоматизованого старту процедур для обробки оперативної інформації. На прикладі авіакомпанії «Міжнародні авіалінії України» показано ефективність такого підходу до зменшення вартості створення міжсистемних інтерфейсів.

Література

1. D.R. Vieira. Maintenance, Repair and Overhaul (MRO) Fundamentals and Strategies: An Aeronautical Industry Overview / D.R. Vieira, P.L. Loures// International Journal of Computer Applications (0975 - 8887) Volume 135 - No.12, February 2016.

2. Y.B. Moon. Enterprise Resource Planning (ERP): a review of the literature. / Y.B. Moon // Int. J. Management and Enterprise Development, Vol. 4, No. 3, 2007.

3. AMOS Aviation M&E. - Режим доступу: https://www.aircraftit.com/webinars/swiss-as-amos-aviation-me-mro-software-demo-and-overview-webinar-inc- digital-functionality/.

4. D. Studebaker. Programming Microsoft Dynamics Nav. / D. Studebaker // Packt Publishing 2009.

5. S. Varga. Introducing Microsoft SQL Server 2016: Mission-Critical Applications, Deeper In-sights. / S. Varga, D. Cherry, J. D'Antoni // Microsoft Press, Redmond, Washington, 2016.

Размещено на Allbest.ru