CC BY
44
13. QUESTION 22/1: Securing information and communication networks: best practices for developing a culture of cybersecurity [Електронний ресурс] / International Telecommunication Union. - Режим доступу: \www/ URL: http://www.itu.int/dms_pub/ itu-d/opb/stg/D-STG-SG01.22-2010-PDF-E.pdf - 2010 р.
14. ISO/IEC 27005:2011. Information technology - Security techniques - Information security risk management (second edition)
[Текст]. - Введ. 2011-05-19. - Женева, 2011. - 68 с.
15. ITU-T X.1207. Guidelines for telecommunication service providers for addressing the risk of spyware and potentially unwanted software [Текст]. - Введ. 2008-04-18. - Женева, 2008 . - 20 с.
16. Cameron H. Malin Malware Forensics: Investigating and Analyzing Malicious Code [Текст]:/ Cameron H. Malin, Eoghan Casey
James M. Aquilina. - 1 edition. - Waltham: Syngress, 2008. - 592 с.
-----------------------□ □----------------------------
Ми розглядаємо методи та засоби Business Intelligence для аналізу фінансових показників банку, наводимо доцільність використання експертної системи у галузі Business Intelligence, і на основі цього проводимо дослідження процесу індустріального тестування експертних систем. Розглядаємо аналітичний додаток аналізу фінансових показників банку з використанням методів та засобів BI. Детально розглядаємо реалізацію OLAP рішення
Ключові слова: Business Intelligence, Reports Services, тестирование, метрики, экспертные системы, искусственный интеллект
□--------------------------------------------□
Мы рассматриваем методы и средства BI для анализа финансовых показателей банка, приводим целесообразность использования экспертной системы в сфере BI, и на основе этого проводим исследование процесса индустриального тестирования экспертных систем. Рассматриваем аналитическое приложение анализа финансовых показателей банка с использованием методов и средств BI. Подробно рассматриваем реализацию OLAP решения
Ключові слова: Business Intelligence, Reports Services, тестування, метрики, експертні системи, штучний інтелект -----------------------□ □----------------------------
УДК 004.89
ПРОЦЕСИ ТЕСТУВАННЯ ЕКСПЕРТНИХ СИСТЕМ ДЛЯ ВПРОВАДЖЕННЯ В BUSINESS INTELLIGENCE
Н.В. Ковтун*
E-mail: natalivalentain@gmail.com М.М. Нестеренко*
E-mail: misha.nesterenko@gmail.com І. В. Цемкало*
E-mail: irina.tsemkalo@gmail.com *Кафедра програмної інженерії Харківський національний університет радіоелектроніки пр. Леніна, 14, м. Харків, Україна, 61166
1. Вступ
Підвищення прибутковості, зниження собівартості, розширення ринків збуту підприємств неможливе без аналізу бізнес-процесів. Як правило, бізнес-аналіз необхідний на всіх стадіях життєвого циклу продукту й у всіх підрозділах підприємства, це в свою чергу потребує обробки величезних обсягів інформації. Бізнес-аналітики великих ІТ компаній займаються структуруванням інформації, написанням інтерфейсів доступу до неї, забезпеченням безпеки, цілісності та інших проблем, пов’язаних з аналізом. Існують зручні і гнучкі засоби, що дозволяють відобразити потрібні розрізи цієї інформації, що дозволяє управлінцям і аналітикам приймати оптимальні рішення для поліпшення всіх показників функціонування.
Найбільш цікавим питанням є інтеграція засобів ВІ з можливостями експертних систем. Експертні системи розроблюються як практичне використання досліджень у галузі штучного інтелекту (ШІ). Вони комбінують знання про деяку галузь діяльності людини з можливістю робити висновки, які засновані на відомих фактах та правилах застосування знань до відомих фактів. При наявності високоякісних знань (які добре відображають реальність) продуктивність експертної системи може наблизитись до продуктивності людини-експерта, а в деяких випадках навіть перевершити продуктивність людини. Експертні системи з’явились як допоміжні програмні додатки у галузях медичного діагностування, розшуку мінералів та автоматизованого налаштування програмних систем. На даний момент вони все глиб-
Е
© Н. В. Ковтун, М. М. Нестеренко, I. В. Цемкало, 2013
ше проникають до галузі Business Intelligence (BI). Прототипи таких систем використовуються в усьому світі. Найбільші результати по практичному використанню досліджень у ШІ досягнуті у галузях промисловості, наукових досліджень та менеджменту. Незважаючи на те, що розвиток експертних систем знаходиться на початкових етапах, існують успішні приклади використання їх у реальному житті.
Забезпечення якості програмних продуктів (ПП) відіграє життєво важливу роль у процесі розробки програмного забезпечення (ПЗ). Виходячи з вище перерахованого, неможна недооцінювати важливість тестування експертних систем при використанні їх у сфері BI. Якість ПП можна оцінити за допомогою певного набору характеристик, що визначає, чи задовольняє експертна система вимогам учасників процесу розробки ПЗ.
2. Аналіз існуючих засобів та постановка проблеми
Технологія обробки інформації Online Analytical Processing (OLAP) допускає багатовимірні подання даних з оптимізацію швидкості доступу до даних в порівнянні з Online Transaction Processing (OLTP). Крім того OLAP є закінченою формою зберігання даних, які витягуються з бази даних (БД) OLTP. Для перетворення даних в потрібні структури використовуються так звані Extract, Transform, Load (ETL) інструменти. Такими засобами є або програми обробки електронних таблиць, які зазвичай включають клієнта OLAP бази даних, або системи побудови звітів і клієнти зведеної таблиць. Три технології - ETL, OLAP і генератори звітів - спільно працюють на BI [1].
Системи бізнес-аналізу призначені для моделювання різних ситуацій, прогнозування розвитку на майбутні періоди, оцінки виконання поставлених цілей.
Джерелом даних в системах бізнес-аналізу є багатовимірні БД, також можливе використання персональних джерел і вітрин даних. Серед найбільш популярних системи бізнес-аналізу та візуалізації даних можна виділити наступні: IBM Cognos Express, Qlik View, Oracle Hyperion, SAP BPC, MS BI.
Всі вони мають різний набір функцій. Якщо розглядати автоматизацію бюджетування, то важливим є наявність процесу узгодження при введенні даних. Однак не всі приведені популярні системи дозволять вирішити дану задачу в силу своїх функціональних особливостей. Наприклад, Qlick View не впорається з цим завданням. MS BI завдяки інтеграції з SharePoi-nt дозволить призначити етапи та учасників процесу узгодження.
Іншим важливим критерієм вибору системи біз-нес-аналітики й візуалізації даних є швидкодія. MS BI, SAP BPC потребують деякого часу для обробки даних, це пов’язано з тим, що в якості джерела використовується SQL Server, для прискорення даного процесу рекомендується прописувати всі розрахунки на SQL і не використовувати MDX-формули. Тим часом обробка даних в IBM Cognos відбувається досить швидко, а в Qlick View практично миттєво за рахунок обробки даних в оперативній пам’яті [1].
Таким чином, проаналізувавши та порівнявши програмні продукти найвідоміших компаній для дослідження та застосування методів і технологій OL-AP&Datamining, актуальною за оптимальним співвідношення ціна/якість для використання є SQL SERVER 2008 R2 компанії Microsoft. Він надає середовище для створення моделей інтелектуального аналізу даних Microsoft SQL Server Analysis Services, яка складається з Business Intelligence Development Studio, SQL Server Management Studio, Microsoft SQL Server 2008 Integration Services.
Необхідно оброблювати велику кількість даних для виділення інформації, яка може бути використана для розробки рішень та отримання висновків о стані бізнесу та напрямку його руху. Використання систем підтримки прийняття рішень (СППР) дозволяють частково вирішити цю проблему та організувати знання у моделі, які спростять процес прийняття рішення. Цей спосіб має недоліки, одним з яких є те що кінцеве рішення повинна приймати людина. При наявності великої кількості вхідних параметрів людина не може ефективно оброблювати усі ці параметри одночасно. При використанні експертної системи частину праці по аналізу усіх параметрів можна передати комп’ютеру, спрощуючи задачу прийняття рішення для людини.
Для оцінки якості та керування якістю необхідні метрики, що надають кількісні оцінки якості кінцевого продукту. В цій області існують проблеми щодо визначення критеріїв завершення тестування. Тому систематизація та аналіз існуючих метрик тестування є важливим завданням. Для збору метрик використовуються спеціальні CASE-засоби, наприклад, Rational Suite компанії Rational Software [2]. Rational Suite - це інтегрований набір продуктів, призначений для підтримки командної роботи над проектом на кожній фазі життєвого циклу розробки системи [3]. Rational Suite об’єднує зусилля аналітиків, розробників і тестувальників, усуваючи перешкоди, які виникають між групами співробітників, що працюють над одним проектом, оптимізує роботу співробітників, надаючи потрібний набір інструментальних засобів для виконання специфічних завдань кожного члена команди, спрощує установку, підтримку і спільне використання продуктів, що входять в Rational Suite. До складу Rational Suite входять такі засоби як Rational ClearQuest - засіб для управління змінами та відсте-ження дефектів в проекті на основі засобів e-mail і Web; Rational Quantify - засіб кількісного визначення вузьких місць, що впливають на загальну ефективність роботи програми; Rational PureCoverage - засіб ідентифікації ділянок коду, пропущених при тестуванні; Rational TestManager - засіб планування функціонального і навантажувального тестування; Rational Robot - засіб запису і відтворення тестових сценаріїв; Rational TestFactory - засіб тестування надійності; Rational Quality Architect - засіб генерації коду для тестування [3]. Використання наведеного засобу для тестування експертної системи дозволяє покращити сам процес індустріального тестування, формалізуючи його та проводячи по чітко встановленому плану, а збір метрик тестування дозволяє оцінити як якість системи, так і якість самого процесу розробки ПП.
З
3. Мета і завдання дослідження
Метою дослідження є побудова системи на базі методів та засобів ВІ для аналізу фінансових показників банку, а також аналіз інтеграції експертних систем та систем підтримки прийняття рішень, огляд переваг та недоліків кожної з систем, та огляд характеристик отриманої системи. В результаті необхідно проаналізувати та описати процес індустріального тестування, який доцільно використовувати при тестування подібних експерних систем.
4. Реалізація OLAP рішення
Етап побудови аналітичного додатку можна розбити на такі базові етапи: створення схеми OLAP-Warehouse БД, завантаження та перетворення (оп-ціонально) даних з Warehouse БД в OLAPWarehouse, побудова необхідних кубів, метрик і вимірювань, побудова відображення даних користувачеві. На етапі створення схеми OLAPWarehouse БД будується ре-ляційна схема БД, вона складається з: таблиці фактів
- містить в собі факти, наприклад, відсоткова ставка, код продукту, сума та ін.; таблиць вимірювань - містить в собі можливі розрізи таблиці фактів, наприклад, дата, назва валюти, інформація про клієнтів та ін.; відносин між таблицями [4].
Основна ві дмінність OLAPWarehouse і Warehouse заключається у ступіні нормалізації даних у базі даних. Warehouse БД має високий ступінь нормалізації, а OLAPWarehouse повинна бути глибоко денормалі-зована для підвищення швидкодії операцій вибірки. Зважаючи на це розходження необхідне перетворення даних з Warehouse в OLAPWarehouse.
У реальних системах ведется, як мінімум, щоденне оновлення аналітичних БД. Для автоматизації актуалізації даних в OLAPWarehouse БД використовується комплекс програм під загальною назвою ETL, він в буквальному розумінні означає: витягти, тобто отримати дані із зазначених таблиць Warehouse БД, перетворити, тобто перетворити схеми Warehouse БД в схему OLAPWarehouse БД, завантажити, тобто безпосередньо завантажити дані в БД OLAPWarehouse.
Над реляційної схемою OLAPWarehouse БД будуються куби. Куб - концепт, що складається з безлічі метрик, таблиць фактів і вимірювань. Ключовими складовими є метрики, що складаються із даних, що містилися в таблиці фактів; вимірювання - дані містяться в таблиці вимірювань і пов’язані з заходами, що використовують зв’язки один до багатьох. Вимірювання можуть будуватися в ієрархії. Цей етап необхідний для того, щоб аналітик міг вибрати потрібні йому розрізи і проводити аналіз без допомоги технічного фахівця. На основі описаної схеми проходить перевірка цілісності, оптимізація, вибірки.
Таблиця FactLoans - це таблиця фактів бази даних OLAPWarehouse. Дана таблиця містить в собі факти кредитного портфелю банку, такі як відсоткова ставка, загальна сума, валюта, дата, дані про клієнта, регіон. Всі інші таблиці бази даних OLAPW-arehouse - це так звані таблиці вимірювань. Таблиця DimensionsCity зберігає інформацію про регіони в яких знаходяться клієнти. В таблиці DimensionsClie-
nt описані дані про клієнта, такі як вікова категорія, освіта, галузь, в якій клієнт працює, та тип клієнта (фізична, юридична особа), дата оформлення кредиту (DimensionsDate), код підрозділу (Dimensions-Depart), код продукту (DimensionsProduct), термін, на який оформлено кредит (DimensionsTerm), та код валюти, в якій видано кредит (DimensionsVA).
Для завантаження і перетворення даних з бази даних Warehouse в OLAPWarehouse розроблені спеціальні скрипти. Спочатку були створені тимчасові таблиці для наданих кредитів, контрактів, дат та сум наданих наданих кредитів в розрізі контрактів. Після створення тимчасових таблиць їх необхідно заповнити даними, важливо перетворити дані відповідно до уже створених таблиць вимірів. Після того як дані з БД Warehouse були приведені й занесені до тимчасових таблиць БД OLAPWarehouse, їх необхідно внести до таблиці фактів бази даних OLAPWarehouse.
Скрипти запускаються автоматично раз на день, це дозволяє оновлювати аналітичні БД кожного дня. Таким чином інформація, що міститься в БД OLAP-Warehouse, практична та актуальна.
Для побудови куба, метрик і вимірювань використовувався інструмент Business Intelligence Development Studio. Джерелом даних є БД OLAPWarehouse (також можливі множинні джерела даних). Куб містить групу мір, такі як основна заборгованість, прострочена заборгованість, загальна сума, темпи приросту.
Для відображення користувачеві кінцевих результатів використовується MS SQL Server 2008 Reports Services [5]. Для побудови браузерних звітів, додатки Reports Services містять зручні та зрозумілі візарди швидкої побудови та установлення звітів на сервер звітів. У даному прикладі аналіз динаміки кредитного портфеля банку дає можливість задати необхідну дату для формування звіту, здійснювати пошук по звітові та експортувати дані у необхідний користувачеві формат. Також є можливість роздру-кувати звітні дані.
5. Використання експертних систем у BI
Системи допомоги прийняття рішень, які використовуються у ВІ - це інтерактивні програмні додатки, які використовують правила та моделі прийняття рішень разом з БД. В свою чергу експертні системи
- це програмні додатки, які використовують базу даних зі знаннями експерта у деякій галузі та механізм виводу для створення висновків заснованих на базі знань та відомих фактів [6].
Більшість існуючих експертних систем використовуються як незалежні програмні додатки, які допомагають користувачам у вирішенні проблем у спеціалізованих галузях [7]. Таким чином, експертні системи можуть розглядатися як інтелектуальні системи допомоги прийняття рішень. Ці системи мають три основні риси, які присутні в експертних системах: допомога з вирішенням складних неструк-турованих проблем, інтерактивність та інтуітивний інтерфейс для взаємодії [8]. Але існують різниці між цими системами. Системи прийняття рішень допомогають людині отримати рішення, а експертні системи працюють як помічники. Галузь проблеми,
.уз
яка вирішується за допомогою СППР, звичайно, поширена та складна, на відміну від цього галузь проблеми для експертної системи більш структурована та обмежена. Як результат, СППР більш придатна для вирішення унікальних проблем, а експертна система більш придатна для вирішення проблем, які часто повторюються (наприклад діагностування неправильного функціонування) [9].
Більшість існуючих експертних систем та СППР не інтегровані. Експертна система працює як незалежний консультант, а СППР використовується для допомоги у прийнятті рішень.
Інтегруючи можливості експертних систем та СППР можливо досягнути значних результатів. СППР, звичайно, дають велику свободу дій стосовно отриманню інформації, оцінки інформації та розробці кінцевого рішення. Це має деякі негативні наслідки. Людина може мати упередженість у вирішуваному питанні, а це може негативно подіяти на кінцеве рішення. Експертна система, на відміну від людини, таких проблем не має (якщо експертні знання коректні, та сама система коректно побудована). Експертна система може допомогти у перевірці отриманого рішення. Вона є джерелом експертних знань, які дозволяють отримати рішення, яке може бути порівняне з рішенням людини. Усі протиріччя, які знайдені у процесі порівняння, можуть бути використані для покращення результуючого рішення.
6. Процес тестування експертних систем
Процес індустріального тестування експертних систем має бути добре організованим, тобто відповідати таким особливостями індустріального тестування:
- наявність набору характеристик;
- наявність визначеного тестового циклу;
- використання технологій автоматизованого та ручного тестування;
- використання метрик;
- автоматизований підхід для збору метрик.
Процес тестування складається з трьох важливих фаз тестування: модульного, інтеграційного та системного [10]. Фази процесу тестування мають сувору послідовність кроків: визначення цілей, планування проведення тестування, розробка тестів, виповнення тестів та аналіз результатів. Індустріальне тестування вирізняється наявністю визначеного тестового циклу, який визначає послідовність виповнення тестів. Процес тестування має ретельно плануватися: вся інформація щодо заходів записується в обов’язковому тестовому плані, у якому перераховуються і типи тестів: функціональне тестування, стресове, продуктивності тощо. Від того, як буде налагоджений процес тестування експертної системи, залежить успішність розробки систем загалом. Щоб проаналізувати успішність проведення тестування, використовуються спеціальні метрики.
Метрики поділяються: на метрики для опису продукту - його розміру, складності, продуктивності, часу роботі без збоїв, так і безпосередньо на метрики проекту [11]. Метрики проекту поділяються на первинні, або накопичувальні, та обчислювані. Пер-
винні метрики - це числові значення показників, що отримуються на етапі тестування програмного продукту. До них відносяться час та вартість тестування, кількість помилок, знайдених на етапі тестування та на етапі експлуатації, обсяг тестування. Обчислювані метрики отримуються на основі первинних. Вони використовуються для оцінки якості проведення тестування. Прикладами обчислювальних метрик є тестове покриття, кількість дефектів на строку вихідного коду, результативність тестування.
Етап тестування експертної системи включається в кожну стадію прототипування прикладної системи [12]. Хоча зазвичай тестування розглядають в якості заключної фази процесу розробки, операційне про-тотипування, що характеризується можливістю зміни цілей проектування в процесі розробки, висуває особливі вимоги до доказу коректності і відповідності розроблюваної системи пропонованим вимогам. Ці два завдання мають виконуватися паралельно з процесом розробки експертної системи. За аналогією з технологією тестування традиційних програмних систем можна інтерпретувати процес верифікації як альфа-тестування програмної системи, а концептуальне тестування - як етап бета-тестування, хоча тестування експертних систем принципово відрізняється від тестування традиційних систем. Для тестування експертної системи необхідно залучати експерта в даній предметній області.
Фахівці виділяють три аспекти тестування експертних систем:
- тестування вихідних даних;
- логічне тестування бази знань;
- концептуальне тестування прикладної системи.
Тестування вихідних даних включає перевірку
фактографічної інформації, яка є основою для проведення експертизи [12]. Очевидно, що набори даних, використовуваних при тестуванні, повинні покривати область можливих ситуацій, які розпізнаються експертною системою. Логічне тестування бази знань полягає у виявленні логічних помилок в системі про-дукцій, що не залежать від предметної області, таких, як надлишкові, циклічні і конфліктні правила; пропущені та пересічні правила.
До технологій індустріального тестування відносяться ручне та автоматизоване тестування. Ручне тестування - це задокументована процедура, в якій описана методика, що задає порядок тестів та список значень вхідних параметрів та вихідних результатів для кожного тесту. Автоматизоване тестування - це створення певного скрипта за допомогою програмних засобів залежно від продукту, що тестується. Формальний характер помилок, що виникають при тестування експертної системи, дозволяє автоматизувати процес логічного тестування. Існує велика кількість інструментальних засобів для верифікації наборів правил і бази знань в цілому. Проте у ряді випадків, коли ланцюжки правил, використовуваних у процесі виведення, невеликі (від 3 до 10 правил), доцільно проводити процес верифікації вручну. Концептуальне тестування проводиться для перевірки загальної структури системи та обліку в ній всіх аспектів розв’язуваної задачі. На цьому етапі проведення тестування неможливо без залучення кінцевих користувачів прикладної системи.
З
7. Висновки
У статті висвітлені актуальні проблеми фінансового сектору України. Приведено рішення на при-к ла ді з а дачі а на лізу кр еди тного портфе лю банк у. Pозглянута розробка бази даних OLAPWarehouse, завантаження та перетворення дани х з Warehouse БД у розроблену OLAPWarehouse БД, побудувані необхідні куби, метрики, вимірювання, а також приведено зручне відображення даних користувачеві, використовуючи MS SQL Server 2008 Reports Services. Показана практичність використовуваних методів та засобів.
Для зниження складності аналізу проблеми та для допомоги людині розроблювати рішення за домо-погою системи підтримки прийняття рішень використовується експертна система. Галузь, у якій працюють СПП^ набагато більша ніж галузь застосування експертної систми, тому для повноцінної інтеграції необхідно використовувати декілька експертних си-
стем з різними спеціалізаціями. Подібний симбіоз систем дозволяє зробити СППР більш інтерактивною, надати змогу порівнювати рішення людини з рішенням, яке розроблене машиною, та надати змогу для пояснення цього рішення.
Застосування індустріального тестування експертних систем, що використовуються у сфері ВІ, відіграє вкрай важливу роль. Розглянуто особливості індустріального процесу тестування, наведено етапи процесу тестування експертних систем, розглянуто метрики, які використовуються для оцінки якості вихідного продукту. При тестування експертних систем у галузі ВІ важливим завданням є забезпечення мінімізації ризиків виходу проекту за межі графіку, тому у результаті дослідження доведено, що дотримання чіткого тестового плану дає змогу уникнути хаотичності у процесі тестування, підвищити якість ПП завдяки заздалегідь продуманій моделі проведення тестових заходів, допомагає координувати дії розробників та тестувальників.
Література
1. Harinath, S. Microsoft SQL Server Analysis Services 2008 with MDX [Text] / S. Harinath, R. Zare. - «Sams», 2010. -1072 c.
2. Coverage measurement experience during function test [Текст] : 15th International Conference on Software Engineering, May 199З Baltimore, MD, USA / P. Piwowarski, M. Ohba, J. Caruso. - Baltimore: C. 287-З00.
3. IBM Rational Suite [Электронный ресурс] / Корпорация IBM Rational Software - Pежим доступа: http://www.interface. ru/rational/suite1.htm - Загл. с экрана.
4. Федоров, А. Г. SQL Server 2008. [Текст] / А. Г. Федоров. - СПБ: Pусская Pедакция, 2008. - 128 с.
5. Lisin, M. Microsoft SQL Server 2008 Reporting Services Unleashed [Text] / M. Lisin. - «Sams», 2009. - б9б c.
6. Alter, L. Decision Support Systems: Current Practices and Continuing Challenges [Текст] / L. Alter. - Massachusetts : Addi-son-Wesley, 1980. - З1б c.
7. Michaelson, R. Expert Systems in Business [Текст] / D. Michie, R. Michaelson // Datamation, 198З. - Т. 29, №12. - C. 240 -24б.
8. Designing the Expert Component of a Decision Support System [Текст] : ORSA/TIMS meeting, May 1984 San Francisco / M. Goul. - San Francisco : 407 c.
9. The Role of Expert Systems in DSS [Текст] : ORSA/TIMS meeting, November 1984 Dallas / R. Sprague. - Dallas : 592 c.
10. Kaner, C. Testing computer software [Текст] / С. Kaner, J. Falk, H. Nguyen. - М: DiaSoft, 2001. - 5З8 c.
11. What do software reliability parameters represent? [Текст] : International Symposium on Software Reliability Engineering, November 1997 Albuquerque, NM / Y.Malaiya, J.Denton. - Albuquerque: C. 124 - 1З5.
12. Этапы разработки экспертных систем. Этап V. Тестирование [Электронный ресурс] / Портал искусственного интеллекта. - Pежим доступа: http://www.aiportal.ru/articles/expert-systems/development-step5.html - Загл. с экрана.
