Для поиска темы - пользуйтесь СИСТЕМОЙ ПОИСКА


Стоимость дипломной работы


Home Для студента... СППР. Особливості проектування СППР.

СППР. Особливості проектування СППР.
загрузка...
Рейтинг пользователей: / 0
ХудшийЛучший 

Особливості проектування СППР
Проектування є двоспрямованим ітераційним процесом, що ураховує як базову функціональність аналітичного інструменту і якість початкової інформації, так і цільові алгоритми і методики, що реалізовують бізнес вимоги, що пред'являються менеджерами і аналітиками всіх зацікавлених служб компанії. Особливо недоліки проектування відчутні при впровадженні СППР.
Найбільш реалістичним пропонується вважати наступну послідовність кроків проектування аналітичної системи: Маються на увазі корпоративні СППР.
• Описується попередня архітектура багатовимірного сховища на основі системного аналізу складу і структури інформаційних потоків. В базу даних завантажується близько десяти відсотків початкової інформації і частини історичних даних. На цьому етапі не притягуються “чисті” аналітики, в постановці задачі беруть участь ІТ-фахівці компанії. Для уявлення і аналізу інформації використовуються базова функціональність і штатні алгоритми агрегації. Ця фаза проекту дозволяє грубо оцінити розміри майбутнього сховища, складність спадкоємства історичних даних, час регламентного завантаження. Практичним виходом може стати розгорнутий звіт про ступінь узгодженості інформаційних потоків і технічні пропозиції щодо розробки алгоритмів очищення даних.
• Наступна фаза, реалізація алгоритмів очищення і узгодження, завантаження всього об'єму історичних і оперативних даних. Аналіз адаптивної призначеного для користувача інтерфейсу до реальних об'ємів даних і технологічності засобів супроводу і розширення наочної області. Після проведення всього переліку робіт і побудови макету робочих місць аналітика і менеджера, над реальними даними на базі штатної функціональності, з'являється потреба активного залучення до проектної групи наочних фахівців. При цьому на конструктивну участь аналітика в проекті можна сподіватися лише у разі коли він зможе побачити можливість практичного використовування прототипу системи для вирішення своїх оперативних задач.
• Фаза розробки наочного технічного завдання для реалізації бізнес процесів аналізу і підтримки ухвалення управлінських рішень. Тільки тут комплексна проектна група остаточно фіксує реквізитний склад, логічні зв'язки, алгоритми і методики, що дозволяють обслуговувати бізнес процеси управління компанією.
З цієї миті починається класичне проектування системи зверху вниз. Але і тут специфіка створення корпоративній СППР нагадує  про себе :
• Масштабна і логічна складність бізнес об'єктів управління.
Структура і реквізитний склад бізнес об'єктів може перевищувати тисячі найменувань, а з урахуванням системи , їх в середньому близько десяти на кожний наочний реквізит, кількість об'єктів в багатовимірній базі може перевищувати десятки тисяч. Ручна, нехай навіть з використанням сучасних графічних засобів, технологія проектування сховища вкрай не ефективна. Штатний інструментарій повинен бути дооснащений спеціалізованим, автоматичним генератором бази даних. Як один з варіантів рішення, джерелом генерації може виступати формалізований Excel файл, що описує реквізитний склад і логічні зв'язки бізнес об'єктів. Використовуючи його, генератор в автоматичному режимі створює або модифікує інформаційне сховище. Така технологія не тільки розпаралелює етап опису метаданих, що є одним з вузьких місць корпоративного проекту, але і залишає як «сухий залишок» роботи кваліфікованої команди архітекторів, зрозумілий Excel документ, який дозволяє службам супроводу розширювати і модифікувати наочну область, не опускаючись до рівня фізичної суті.
Інша, не менше актуальна технологічна проблема є створення і супровід багатовимірних агрегатів, методик їх розрахунку і моделювання. І знову, кількість таких показників і динаміка зміни моделей настільки велика, що стандартний підхід у великих, корпоративних проектах не застосовується.  Тут можливий варіант використання формалізованих Excel файлів, їх багатокористувальне обслуговування прикладними адміністраторами і подальший «накат» на метадані системи. В цьому випадку зрозумілий службам експлуатації документ буде являти собою як описувач наочного рішення, і як джерело для модифікації метаданих.


 
загрузка...

Добавить комментарий


Защитный код
Обновить