книги / Поддержка принятия решений при управлении инновационными проектами

проектами (по различным тематикам и с различными свойствами) и субъектами с их свойствами.

Прочие подсущности аналитической базы являются вспомо­ гательными и инкапсулируют различные свойства основных сущностей системы. Так, например, подсущность географическо­ го расположения характеризует как субъекты, так и проекты. Аналогично время и область активности характеризует обе ос­ новные сущности. Персоны посредством своих ролей и образова­ ния позволяют делать выборки различных проектов.

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

Показатели предметной области

Исходная база данных (предоставляемая ПГТУ) должна предоставлять следующие показатели:

1.Для персон должны быть специфицированы:

-адрес;

-образование;

-сфера интересов/продуктов/услуг;

-дата рождения.

2.Для организаций:

-адрес;

-сфера интересов/продуктов/услуг;

-дата образования;

-количество сотрудников.

3.Для проектов:

-сфера применения;

-адрес;

-атрибуты исследования;

-даты начала и окончания проекта;

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

-количество месяцев, за которые проект должен окупиться;

-предположительный процент окупаемости проекта. Наличие всех перечисленных показателей обеспечит

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

Многомерная база

Многомерная база реализуется на основе Microsoft Analysis Service. Поставщиком данных для многомерной базы должно вы­ ступать реляционное хранилище. Хранилище может быть реали­ зовано в виде набора представлений над исходной базой или в виде специализированной реляционной базы. Способ реализации реляционного хранилища должен быть уточнен на этапе реализа­ ции.

Измерения

Многомерная база должна содержать следующие измере­

ния:

1.Общие:

-тип награды;

-тип субъекта;

-тип активности;

-активность/сфера интересов/тип продукции/тип услуги;

-фирмы.

2.Образование (для персон):

-специализация;

-высшая специализация;

-учебное заведение;

-тип обучения;

-научная степень.

3.Географические (для субъектов и проектов):

-тип поселка;

-поселок/город;

-город/район;

-регион;

-страна.

4.Должности и роли (для персон):

-должность в фирме;

-роль в проекте.

5.Проекты и научные исследования:

-проекты;

-состояния проектов;

-тип исследования;

-тип научной новизны;

-рейтинги проектов;

-типы результатов;

-тип оценки проекта;

-патентованность;

-типы и цели финансирования.

6.Временные:

-календарь;

-возраст.

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

Ку б ы

Су б ъ е к т ы

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

наборов:

-общие;

-образование;

-географические;

-временные.

иизмерение должностей. Куб должен содержать следующие по­ казатели:

-количество субъектов;

-количество сотрудников (имеет смысл в случае выборок по фирмам)

-средний возраст (вычислимый показатель, характеризу­ ющий персоны)

-количество наград/патентов/лицензий;

-средняя стоимость наград/патентов/лицензий;

-суммарная стоимость наград/патентов/лицензий.

Куб позволяет создавать выборки субъектов, удовлетворя­ ющих определенным свойствам, заданных путем фиксации изме­ рений.

П р о е к т ы

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

-общие;

-географические;

-проекты и научные исследования;

-временные.

Куб должен содержать следующие показатели:

-количество проектов;

-стоимость проектов (суммарная);

-стоимость проектов (средняя);

-длительность проектов (вычислимый показатель, в меся­ цах, среднее);

-сроки окупаемости проектов (в месяцах, среднее);

-прибыль в % (среднее).

Куб позволяет создавать выборки проектов, удовлетворяю­

щих заданным фиксациям, и на этих выборках производить вы­

числения описанных показателей.

П о л н ы й к у б

Данный куб должен содержать весь комплект измерений и полный комплект показателей. В определенном смысле куб может рассматриваться как объединение «куба субъектов» и «куба проек­ тов», однако реализоваться данный куб должен совершенно само­ стоятельно, поскольку должен учитывать взаимосвязи между эле­ ментами.

Отчеты, генерируемые подсистемой

Подсистема должна генерировать два вида отчетов:

1.Статические - реализуются в виде запросов к многомер­ ной базе и сохраняются в формате XML. Точный список таких отчетов должен быть уточнен на этапе реализации. Общее коли­ чество таких отчетов не должно превышать 10. Отчеты могут быть просмотрены в MS IE или другими средствами. Сопровож­ даясь описаниями XSL, отчеты могут быть легко опубликованы в WEB.

2.Динамические - реализуются в виде Excel шаблонов с ис­ пользованием PivotTables. На основе этих шаблонов аналитики смогут получать необходимые отчеты путем проведения неслож­ ных манипуляций. Точная спецификация таких шаблонов должна быть получена на этапе реализации, но общее количество не должно превышать 15 (по 5 шаблонов на каждый из кубов). Для просмотра и подготовки динамических отчетов должен использо­ ваться Microsoft Excel.

Для работоспособности системы важным является поддер­ жание актуальности данных. Для этой цели может служить сете­ вая структура проекта. Копии системы устанавливаются заинте­ ресованным людям и организациям, которые будут вносить и об­ рабатывать в ней свои данные, а также предоставлять их для цен­ тральной базы данных (рис. 37).

128

ности пользователей и высокой устойчивостью к «зависаниям» (что связано с ее архитектурными особенностями проектирования многозадачности). Для работы рекомендуется выделенный сервер.

Платформой для построения клиентской части системы явля­ ется ОС Windows. Такой выбор обусловлен высокоразвитым гра­ фическим интерфейсом пользователя (GUI), реализованным в этих ОС. Именно графический интерфейс является наиболее важной частью клиентского приложения. Зачастую системы, не утратив­ шие своей функциональности, оказываются «морально» устарев­ шими из-за смены стандартов на пользовательский интерфейс. Выполнение клиентской части на Win-32 платформе позволит си­ стеме иметь самый современный пользовательский интерфейс как сейчас, так и в ближайшем будущем. Это позволит значительно отдалить срок ее «морального» износа.

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

С точки зрения аппаратной части для работы клиентского приложения не требуется выделенной машины, подойдет любая рабочая станция под Windows. Для работы с аналитическим бло­ ком на клиенте должен быть установлен пакет Microsoft Office.

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