Проектирование систем поддержки принятия решений

Независимые витрины данных (Рис. 4) часто появляются в организации исторически и встречаются в крупных организациях с большим количеством независимых подразделений, зачастую имеющих свои собственные отделы информационных технологий.

 

 

 

 

Источник данных

Источник данных

Источник данных

 

 

 

Источник данных

Источник данных

Источник данных

Источник данных

 

 

Рис. 4. Схема типа «независимые витрины данных»

Преимущества:

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

Недостатки:

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

Двухуровневое хранилище данных (Рис. 5) строится централизованно для предоставления информации в рамках компании. Для поддержки такой архитектуры необходима выделенная команда профессионалов в области хранилищ данных.

 

 

Хранилище данных

 

 

 

Источник данных

Источник данных

Источник данных

Источник данных

 

 

Рис. 5. Схема двухуровневого хранилища данных

Это означает, что вся организация должна согласовать  все определения и процессы преобразования данных.

Преимущества:

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

Недостатки:

• Данные не структурируются для поддержки потребностей отдельных пользователей или групп пользователей;
• Возможны проблемы с производительностью системы;

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Преимущества:

• Создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных нормализованных данных;
• Витрины данных синхронизированы и совместимы с корпоративным представлением. Имеется корпоративная модель данных. Существует возможность сравнительно лёгкого расширения хранилища и добавления новых витрин данных;
• Гарантированная производительность.

Недостатки:

• Существует избыточность данных, ведущая к росту требований на хранение данных;
• Требуется согласованность с принятой архитектурой многих областей с потенциально различными требованиями (например, скорость внедрения иногда конкурирует с требованиями следовать архитектурному подходу).

 

 

 

 

 

 

 

 

 

 

 

Глава 2. Особенности проектирования систем поддержки принятия решений

2.1. Этапы проектирования систем поддержки принятия решений

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

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

Производительность  является главным фактором, определяющим эффективность системы. Хорошее  проектное решение служит основой высокопроизводительной системы[9].

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

• проектирование объектов данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

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

Рассмотрим  основные этапы проектирования.

Определение стратегии предполагает обследование системы. Основная задача обследования - оценка реального объема проекта, его целей и задач, а также  получение определений сущностей  и функций на высоком уровне[9].

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

В документе  обязательно должны быть описаны:

• ограничения, риски, критические факторы, влияющие на успешность проекта, например время реакции системы на запрос является заданным ограничением, а не желательным фактором;
• совокупность условий, при которых предполагается эксплуатировать будущую систему: архитектура системы, аппаратные и программные ресурсы, предоставляемые системе, внешние условия ее функционирования, состав людей и работ, которые обеспечивают бесперебойное функционирование системы;
• сроки завершения отдельных этапов, форма сдачи работ, ресурсы, привлекаемые в процессе разработки проекта, меры по защите информации;
• описание выполняемых системой функций;
• будущие требования к системе в случае ее развития, например возможность работы пользователя с системой с помощью Интернета и т.п.;
• сущности, необходимые для выполнения функций системы;
• интерфейсы и распределение функций между человеком и системой;
• требования к программным и информационным компонентам ПО, требования к СУБД (если проект предполагается реализовывать для нескольких СУБД, то требования к каждой из них, или общие требования к абстрактной СУБД и список рекомендуемых для данного проекта СУБД, которые удовлетворяют заданным условиям);
• что не будет реализовано в рамках проекта.

Выполненная на данном этапе работа позволяет  ответить на вопрос, стоит ли продолжать данный проект и какие требования заказчика могут быть удовлетворены  при тех или иных условиях. Может  оказаться, что проект продолжать не имеет смысла, например из-за того, что  те или иные требования не могут  быть удовлетворены по каким-то объективным  причинам. Если принимается решение  о продолжении проекта, то для  проведения следующего этапа анализа  уже имеются представление об объеме проекта и смета затрат.

Этап анализа  предполагает подробное исследование бизнес-процессов. На этом этапе создается информационная модель, а на следующем за ним этапе проектирования - модель данных.

Вся информация о системе, собранная на этапе  определения стратегии, формализуется  и уточняется на этапе анализа.

На этапе  анализа привлекаются группы тестирования, например для получения сравнительных  характеристик предполагаемых к  использованию аппаратных платформ, операционных систем, СУБД, иного окружения. Кроме того, на данном этапе определяется план работ по обеспечению надежности информационной системы и ее тестирования.

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

• схема базы данных (на основании ER-модели, разработанной на этапе анализа);
• набор спецификаций модулей системы (они строятся на базе моделей функций).

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

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

При проектировании модулей определяют разметку меню, вид окон, горячие клавиши и  связанные с ними вызовы. Существуют два вида перемещения по программам:

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

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

На этапе  определения спецификации модулей  решаются следующие задачи:

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

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

Когда генерация  модуля завершена, выполняют автономный тест, который преследует две основные цели:

• обнаружение отказов модуля (жестких сбоев);
• соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

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

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

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