English version
Логин:
Пароль:
Системы поддержки принятия решений. Теория и практика (СППР 2015)

Всего 6 сообщений.
Участник
конференции:
Бондарчук Юрій Васильович, e-mail:byv.kyiv[at]gmail.com
Авторы: Ю.В. Бондарчук
Название
доклада:
ПАТЕРНИ ВЗАЄМОДІЇ СППР

Вишневский Виталий Вячеславович, ИПММС, Киев1889
Юрий Васильевич, в связи с Вашим докладом у меня таких два вопроса:
1. Какая первоначальная цель преследовалась при составлении такой классификации СППР?
2. СППР - это обычно не просто информационные или технические системы, это организационные системы. Как можно увидеть в Вашей классификации, например, Ситуационный центр с его сложной организационной структурой и ролями пользователей и персонала?
Бондарчук Юрій Васильович, Київський національний університет ім. Т. Шевченка, Київ1911
Quote
Юрий Васильевич, в связи с Вашим докладом у меня таких два вопроса:
1. Какая первоначальная цель преследовалась при составлении такой классификации СППР?
2. СППР - это обычно не просто информационные или технические системы, это организационные системы. Как можно увидеть в Вашей классификации, например, Ситуационный центр с его сложной организационной структурой и ролями пользователей и персонала?

Доброго дня, пане Вишневський.

1. Мета ще однієї і саме такої класифікації:
а) запропонована класифікація, можливо ви помітили, не просто список дефініцій, там є опис способу дії взаємодіючих СППР, як підказка розробникам (без претензій порад "класика" :)
б) зараз типово СППР існують як окремі і закриті системи, і так вони і класифікуються (як вони працюють з моделями знань та методами прийняття рішень, наприклад). Мною же вони розглядаються як взаємодіючі по пошуку/обміну рішеннями. У розгляді взаємодії СППР є певний креатив і для теорії і для практики. Також класифікація допомагає стандартизації інтерфейсів, представленню рішень, формуванням метрик для порівнянь тощо. А стандартизація вже буде ознакою зрілості предмету.

2. Щодо ситуативних центрів.
Я їх не відношу до СППР, бо вони складніші та ширші за СППР. Центр може використовувати десятки СППР, десятки експертів та експертних систем. І там ще певна інфраструктура з персоналом. Це як бази даних і банки даних і сховища даних. Сам факт існування терміну "ситуативний центр" вже практично їх розділяє.
Я СППР бачу вужче, а широке трактування розмиває контури СППР до стану, коли вже важко їх вирізняти серед інших систем, бо завжди можна знайти елементи оптимізації, вибору (а, значить, якогось прийняття рішення).
Я бачу СППР такими системами, які працюють з рішенням як з окремим об'єктом, який має свій життєвий цикл. Рішення, як об'єкт, повинно експортуватися/імпортуватися, порівнюватися з іншими, зберігатися. Ясно, що такого зараз немає.

Дякую Вам за увагу до моєї статті.

Сёмик Анатолий Павлович, ИПММС НАНУ, Киев1895
Добрый день, Юрий Васильевич!
Не могли бы Вы детализировать своё утверждение:
3) методи прийняття рішень (МПР), як на думку автора, взагалі розвиваються не
як прикладна наука – цікаві для МПР задачі є непідйомними для оперативного
прийняття рішень, бо рекомендації потрібні не через 100 років обчислень
Бондарчук Юрій Васильович, Київський національний університет ім. Т. Шевченка, Київ1912
Quote
Добрый день, Юрий Васильевич!
Не могли бы Вы детализировать своё утверждение:
3) методи прийняття рішень (МПР), як на думку автора, взагалі розвиваються не
як прикладна наука – цікаві для МПР задачі є непідйомними для оперативного
прийняття рішень, бо рекомендації потрібні не через 100 років обчислень

Мої вітання, пане Анатолій.
Працюючи 27 років на кафедрі системного аналізу та теорії прийняття рішень (яка випускає магістрів за спеціальністю "Системи та методи прийняття рішень") дійшов до такого узагальнення. Серед всіх колег лише я займаюсь ІТ питаннями СППР, всі інші - МПР. Половина - доктори наук, професери. Друга половина - доценти, канд. наук. Я 20 років умовляю дати постановки суспільно корисних задач, які не є модельними. Жодної такої задачі ніхто не може запропонувати. І це зрозуміло, бо більшість алгоритмів квазіпірибірні. І при реальних розмірностях даних не варті уваги (звичайно, крім статей та дисертацій).

Наприклад, я колегам пропоную постановку в такій (реальній) формі: є 5 секунд для прийняття рішень, плюс можна виконати, скажімо, лише 10 млрд операцій. Для цих умов запропонуйте процедуру прийняття рішення. МПРщки кажуть: давай знімай обмеження по часу і ми подумаємо. Всі ігрові задачі в реальних розмірностях тягнуть на нереальний час. А ці задачі найбільш цікаві для СППР.

Я пропоную інший підхід (див. мою статтю на СППР'2013): СППР має набір рішень, можливо не кращих. Давайте їх оціномо в якійсь метриці для подальшого формального порівняння. І тепер СППР для заданих умов пропонує варіант рішення. Тобто, фактично можна сказати, що складні задачі фактично повинні були розв'язані раніше. Якщо їх мало - добавляємо ще, запозичуємо в інших СППР.
Щодо форми рішень - має бути така, яка дозволяє однотипним СППР обмінюватися рішеннями. А далі розподілені СППР, віртуалізація роботи з рішеннями в хмарах...
Отже, СППР маніпулює рішеннями як окремими об'єктами. А в рішенні інкапсулюйте будь-які МПР.

Косс Виталий, ИПММС1897
Шановний пане Бондарчук, ваша доповідь гарно структурована. 
Допоможіть мені, будь ласка, розібратися у ваших структурних ієрархіях.

Свого часу, я часто бував запрошеним до семінарів професора Стеценко (ІПРІ). На таких семінарах
 його аспіранти доповідали про їх досягнення у вдосконаленні метода аналізу ієрархій. Вони раділи з 
того, що підвищували обчислення збіжності результатів оцінок експертів до 10%. 
Я їх питав, як такі досягнення допомогли меру Києва у прийнятті рішень? Вони відповідали, що чиновники 
не розуміють суті їх наукових досягнень. Моє наступне запитання: А чим ви керували у своєму житті? 
Чи маєте ви власний досвід управління? Вони відповідають - Ні, ми лише аспіранти.

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

Маю череду практичних прикладів, які наводжу як підгрунття для свїх запитань.

Командир полку, щойно прибув з зенітної артиллерії до зенітно-ракетної частини. На тренуванні, діє за 
звичкою і керує за допомогою радіостанції: Такому-командиру, таку-ціль знищити...

Наступного дня я (начальник командного пункту) зайшов до нього з пропозицією провести заняття з 
питань управління. Він погодився.

Наступного тренування він мовчав по радіо, а користувався виключно автоматизованою системою 
командного керування. Командири підрозділів ніяк не могли зрозуміти, чому комкандир полку мовчит
 по радіо? Всі отрималі оцінку "незадовільно" і у приватній розбірці обіцяли мене побити. З цього приводу 
я провів тренінг для них і вони заспокоїлись.

Наступного тренування командир полку тисне кнопку 1, і всі командири підрозділів відповідають 
кнопкою 2, 3, 6. У відповідь отримують сигнал "8 - Дякую за виконання завдання". Але це стосувалося не всіх, 
а лише тих, хто на комапнду "1 - Даю цілеспрямування", змогли вцідповісти "2 - цілеспрямування отримав".

Командири підрозділів, що отримали "незадовільно" були обуреними... Я їм розповів, що вони мають 
обрахувати різницю координат між своєю позицією і поцицією командира полку. Така різниця має 
назву "параллакс". 

Наступного тренування і командир полку і командири підрозділів просили, щоби параллакс  до 
їх станцій вводив особисто я.  Але командир полку зрозумів, що я не зможу зробтити такого своєчасно на 
відстані 12-15 кілометрів до кожного підрозділу. Питання автоматизаці управління примусили керівників 
застосовувати ефективні, а не інтуітивні прийоми управління. Я й досі з повагою згадую того командира полку.

Шановний пане Бондарчук, парошу вас навести відповідності ваших теороетичних позицій до наведеного 
практичного досвіду. Особливо у розділі патернів СППР, та особливо до їх "трьох рівнів абстракції".

А ще дуже прошу визначити,  хто такий ОПР? Це дуже важливо. Тому, що прибиральниця, яка побачила 
течу батареї опалення над серверною кімнатою СППР корпрації, може спокійно підти на обід, а може
 заподіяти гвалт. Так вона є ОПР, у вашій СППР, чи ні?

Шановний пане Бондарчук, я маю до вас ще більше питань, але вони залежитемуть ві відповіді на попередні два.
Архітектура СППР дуже важлива,  якщо знаєшь до чого її застосувати. Сучасні технології будування ИТ-систем мають 
всі складові і їх програмно-апаратні рішення. Кожен фахівець має можливість застосувати стандартні рішення у 
будь-якій послідовності. Але за цю послідовність відповідає той, хто її пропонує. 

Чи здатні ви відповідати практично за ту послідовність, що пропонуєте теоретично?
Я буду захопленим, якщо ви доведете мої сподівання!

Бондарчук Юрій Васильович, Київський національний університет ім. Т. Шевченка, Київ1913
Quote
Шановний пане Бондарчук, ваша доповідь гарно структурована. 
Допоможіть мені, будь ласка, розібратися у ваших структурних ієрархіях.

Свого часу, я часто бував запрошеним до семінарів професора Стеценко (ІПРІ). На таких семінарах
 його аспіранти доповідали про їх досягнення у вдосконаленні метода аналізу ієрархій. Вони раділи з 
того, що підвищували обчислення збіжності результатів оцінок експертів до 10%. 
Я їх питав, як такі досягнення допомогли меру Києва у прийнятті рішень? Вони відповідали, що чиновники 
не розуміють суті їх наукових досягнень. Моє наступне запитання: А чим ви керували у своєму житті? 
Чи маєте ви власний досвід управління? Вони відповідають - Ні, ми лише аспіранти.

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

Маю череду практичних прикладів, які наводжу як підгрунття для свїх запитань.

Командир полку, щойно прибув з зенітної артиллерії до зенітно-ракетної частини. На тренуванні, діє за 
звичкою і керує за допомогою радіостанції: Такому-командиру, таку-ціль знищити...

Наступного дня я (начальник командного пункту) зайшов до нього з пропозицією провести заняття з 
питань управління. Він погодився.

Наступного тренування він мовчав по радіо, а користувався виключно автоматизованою системою 
командного керування. Командири підрозділів ніяк не могли зрозуміти, чому комкандир полку мовчит
 по радіо? Всі отрималі оцінку "незадовільно" і у приватній розбірці обіцяли мене побити. З цього приводу 
я провів тренінг для них і вони заспокоїлись.

Наступного тренування командир полку тисне кнопку 1, і всі командири підрозділів відповідають 
кнопкою 2, 3, 6. У відповідь отримують сигнал "8 - Дякую за виконання завдання". Але це стосувалося не всіх, 
а лише тих, хто на комапнду "1 - Даю цілеспрямування", змогли вцідповісти "2 - цілеспрямування отримав".

Командири підрозділів, що отримали "незадовільно" були обуреними... Я їм розповів, що вони мають 
обрахувати різницю координат між своєю позицією і поцицією командира полку. Така різниця має 
назву "параллакс". 

Наступного тренування і командир полку і командири підрозділів просили, щоби параллакс  до 
їх станцій вводив особисто я.  Але командир полку зрозумів, що я не зможу зробтити такого своєчасно на 
відстані 12-15 кілометрів до кожного підрозділу. Питання автоматизаці управління примусили керівників 
застосовувати ефективні, а не інтуітивні прийоми управління. Я й досі з повагою згадую того командира полку.

Шановний пане Бондарчук, парошу вас навести відповідності ваших теороетичних позицій до наведеного 
практичного досвіду. Особливо у розділі патернів СППР, та особливо до їх "трьох рівнів абстракції".

А ще дуже прошу визначити,  хто такий ОПР? Це дуже важливо. Тому, що прибиральниця, яка побачила 
течу батареї опалення над серверною кімнатою СППР корпрації, може спокійно підти на обід, а може
 заподіяти гвалт. Так вона є ОПР, у вашій СППР, чи ні?

Шановний пане Бондарчук, я маю до вас ще більше питань, але вони залежитемуть ві відповіді на попередні два.
Архітектура СППР дуже важлива,  якщо знаєшь до чого її застосувати. Сучасні технології будування ИТ-систем мають 
всі складові і їх програмно-апаратні рішення. Кожен фахівець має можливість застосувати стандартні рішення у 
будь-якій послідовності. Але за цю послідовність відповідає той, хто її пропонує. 

Чи здатні ви відповідати практично за ту послідовність, що пропонуєте теоретично?
Я буду захопленим, якщо ви доведете мої сподівання!

Шановний пане Віталію Косс, дякую за вашу увагу та критику.

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

У вашому прикладі з військового досвіду метод(и) прийняття рішень прийнятий за СППР (ви метод рішення назвали СППР). Це типова методологічна підміна понять (навіть якби ви розписали військове управління на 100 сторінок, там немає СППР). Методи прийняття рішень є кругом, управління є кругом (ваш приклад з семінарів професора Стеценко) якраз і показує, що, наприклад, управлінський досвід (як застосування прийняття рішень) різний у аспіранта і у спеціаліста з досвідом. Але підкреслюю - це методи прийняття рішень. Ваш досвід систем управління у військовій справі теж не має відношення до СППР, бо ви ж самі його і визначили як системи управління. Системи управління теж не є СППР, бо вони реалізують закладене рішення.

Мене методи прийняття рішень взагалі не цікавлять. Вибирайте і реалізуйте будь-який.
В моєму визначенні СППР це не цікавить СППР. Ви не з того боку мене критикуєте. У нас різне розуміння СППР.
Якщо ви критично подивитеся на своє (традиційне) визначення СППР, то воно є настільки широке, що губиться сам предмет і залишиться щось типу: я побачив і це мені допомогло прийняти рішення (ваш приклад із прибиральницею, вона не є ОПР, бо у неї немає СППР, проте є голова). Але абсолютно всі програмні системи дають інформацію, що впливає на прийняття рішення (як то об'ява у газеті, прочитана думка дописувача може вплинути на ваше голосування за певну політичну силу).

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

Тепер щодо теоретичних позицій. Даю своє (коротке) визначення СППР: це програмні системи, які працюють з рішеннями як з окремими об'єктами (зберігають, порівнюють, обмінюються рішеннями, підтримують життєвий цикл рішення). Наші "лоскутні" варіанти реалізацій СППР заважають побачити рішення об'єктом, відокремленим від СППР. Рішення, я пропоную, є даним для СППР!
От з цього боку вже можна критикувати і не погоджуватися.
Коли ми говоримо про систему керування базами даних, то ми точно розуміємо предмет СКБД. Як ми організуємо нашу БД, що там буде індексуватися, що буде ключами, тригерами, курсорами тощо для СКБД не цікаве. Вона просто реалізує вашу модель. Аналогічно для браузера немає значення дизайн якоїсь сторінки (а це теж рішення, між іншим), браузер просто промалює гіпертекст.
Я хочу добитися такого ж представлення для рішень, а СППР буде транслятором рішення і реалізатором певного сценарію маніпуляцій з рішеннями. Я шукаю як зробити рішення об'єктом (ще не можу). Тоді в такому розумінні СППР міняється і задача СППР, змінюються шаблони дій (патерни). А патерн вже дає роль і форму. Коли ви чуєте про патерн клінт/сервер, то ви зразу розумієте ролі взаємодіючих систем.
От і я описую можливі ролі розподілених СППР. Давайте критикувати запропоновані ролі, їх неадекватність, повноту/неповноту, важливість/неважливість.

© ATS Ukraine 2005