ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)
Факультет дистанционного управления (ФДО)
Разработка функциональной модели процесса создания хранилища данных
Отчет о выполнении лабораторной работы
по дисциплине «Информационные технологии в управлении»
Вариант № 19
Выполнил:
Студент ФДО гр. з-478П11-4
Серова Н. В.
Проверил:
доцент каф. АОИ ТУСУР,
канд. техн. наук
О. И. Жуковский
2020
Содержание
Введение 3
Выполнение задания по этапам 4
Сбор информации 4
Формулирование требований 7
Создание вычислительной среды 11
Моделирование данных 12
Продолжение моделирования 14
Определение процедур извлечения преобразования и загрузки данных 16
Проектирование аналитических отчетов 17
Разработка приложений ХД 18
Настройка производительности 19
Проверка качества 20
Передача системы складирования данных в эксплуатацию 20
Сопровождение и модификация хранилища данных 20
Список использованных источников 22
Введение
Цели и задачи работы. Целью данной работы является получение и развитие навыков в планировании бизнес-процессов разработки хранилища данных со стороны заказчика на основе функциональных моделей, соответствующих методологии IDEF0.
Рассматриваются основные бизнес-процессы разработки хранилища данных.
Конкретизация и детализация процесса разработки ХД – это основная задача и проекта разработки ХД.
Описание исходных данных.
По заданной предметной области (комитет по управлению памятниками культуры региона) предполагается использование хранилищ данных в ходе процессов принятия решений при их управлении.
В ходе выполнения лабораторной работы необходимо построить функциональную модель бизнес-процессов разработки хранилища данных в одной из предметных областей, предполагающих необходимость исполь-зования хранилищ данных в ходе процессов принятия решений при их управлении. При рассмотрении предметной области необходимо выявить не менее трех источников оперативных данных, которые послужат основой для загрузки проектируемого хранилища данных (ХД) и определят класс задач, решаемых на основе проектируемого хранилища данных.
Выполнение задания по этапам
Сбор информации
Осуществляем поиск информации об особенностях управления выбранным процессом в сети Интернет.
Исследована деятельность нескольких агентств. Основная цель деятельности Агентства – сохранение, эффективное использование и популяризация объектов культурного наследия (памятников истории и культуры) народов Российской Федерации, находящихся в оперативном управлении Агентства.
Миссия Агентства
Разработка и внедрение в практику сохранения ОКН самых эффективных и экономически выгодных методов, вариантов приспособления ОКН к современному использованию с обязательным учетом исторического предназначения, методическое и практическое сопровождение деятельности собственников ОКН по сохранению, использованию и популяризации объектов культурного наследия России.
Агентство осуществляет следующие основные виды деятельности:
— управление и использование объектов культурного наследия, находящихся в федеральной собственности и оперативном управлении Агентства;
— проведение исследований в области истории объектов культурного наследия;
— осуществление реставрационных работ, разработка программ реставрации;
— популяризация недвижимого культурного наследия, включая экскурсионное и лекционное обслуживание, создание мультимедийной продукции.
Создание условий для реализации интеллектуального, творческого потенциала человека является главной задачей инновационной культуры на современном этапе. Ведущая роль в формировании человеческого капитала, создающего экономику знаний, в «Концепции долгосрочного социально-экономического развития Российской Федерации на период до 2020 года» отведена сфере культуры [2].
Подавляющее большинство субъектов хозяйствования культуры представлено учреждениями. Учреждения культуры – созданные и финансируемые собственником некоммерческие организации, основной деятельностью которых является сохранение, создание, освоение культурных ценностей и предоставление культурных благ.
Некоммерческий сектор составляет значительную часть отрасли. Деятельность некоммерческих организаций, в том числе предпринимательская, подчинена целям, закрепленным в учредительных документах, а не извлечению прибыли. Доходы от коммерческой деятельности используются в рамках уставных целей и не могут быть распределены между учредителями.
В условиях действующей государственной политики включения учреждений культуры в рыночную среду целенаправленное развитие перспективных областей работы является действенным инструментом обеспечения их конкурентоспособности на мировом рынке культурных благ [7, с. 12]. Соперничество с гибкими коммерческими организациями популярной массовой культуры, широкое распространение домашнего потребления, высокий уровень и доступность современной техники обуславливает освоение новых форм работы. Управление организационным развитием является главной управленческой задачей в настоящее время.
Одним из инновационных методов менеджмента культуры является процессноориентированное управление, заключающееся в выделении, описании и соединении разрозненных процессов организации в единую систему. Каждый из них представляет собой целенаправленную последовательность действий работников, результат которой представляет ценность для клиента, государства, общества, физических и юридических лиц, осуществляющих финансирование, а также самого работника.
Выделены три источника оперативных данных.
1. Объекты культурного наследия (памятники истории и культуры): Объекты недвижимого имущества со связанными с ними произведениями живописи, скульптуры, декоративно-прикладного искусства, объектами науки и техники и иными предметами материальной культуры, возникающие в результате исторических событий, представляющие собой ценность с точки зрения истории, археологии, архитектуры, градостроительства, искусства, науки и техники, эстетики, этнологии или антропологии, социальной культуры и являющиеся свидетельством эпох и цивилизаций, подлинными источниками информации о зарождении и развитии культуры.
2. Памятники: отдельные постройки, здания и сооружения с исторически сложившимися территориями (в том числе памятники религиозного назначения: церкви, колокольни, часовни, костелы, кирхи, мечети, буддистские храмы, пагоды, синагоги, молельные дома и другие объекты, специально предназначенные для богослужений); мемориальные квартиры; мавзолеи, отдельные захоронения; произведения монументального искусства; объекты науки и техники, включая военные; частично или полностью скрытые в земле или под водой следы существования человека, включая все движимые предметы, имеющие к ним отношение, основным или одним из основных источников информации о которых являются археологические раскопки или находки (далее - объекты археологического наследия).
3. Ансамбли: четко локализуемые на исторически сложившихся территориях группы изолированных или объединенных памятников, строений и сооружений фортификационного, дворцового, жилого, общественного, административного, торгового, производственного, научного, учебного назначения, а также памятников и сооружений религиозного назначения (храмовые комплексы, дацаны, монастыри, подворья), в том числе фрагменты исторических планировок и застроек поселений, которые могут быть отнесены к градостроительным ансамблям; произведения ландшафтной архитектуры и садово-паркового искусства (сады, парки, скверы, бульвары), некрополи.
Проект разработки ХД начинается после того, как выбраны инструменты разработки и сформирована команда проекта. В проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):
– формулирование требований;
– создание вычислительной среды;
– моделирование данных;
– определение процедур извлечения преобразования и загрузки данных;
– проектирование аналитических отчетов;
– разработка приложений ХД;
– настройка производительности;
– проверка качества;
– передача системы складирования данных в эксплуатацию.
Опишем каждый этап по моему варианту.
Формулирование требований
Описание задачи. Главной задачей данного этапа является иденти-фикация требований будущих пользователей ХД и оформление их в виде документа «Каталог требований». Сбор требований осуществляется путем опроса групп потенциальных пользователей ХД на специальных совещаниях и переговорах. Конечные пользователи, как правило, не знакомы с концепцией ХД и процессом складирования данных. Поэтому для успешного решения этой задачи важна помощь лиц, принимающих решения (ЛПР), т. е. руководителей организации. На этом этапе определены:
– масштаб проекта создания ХД (границы предметной области) – комитет по управлению памятниками культуры региона;
– перечень и содержание отчетов:
отчеты о списке памятников культуры, отчеты о реставрации указанных памятников архитектуры, отчеты о выполненных работах по ремонту и реставрации памятников культуры;
О включении в единый государственный реестр объектов культурного наследия;
О включении в перечень выявленных объектов культурного наследия;
Об утверждении границ и режима использования территории объекта культурного наследия;
Об утверждении охранного обязательства;
Об установлении границ защитной зоны;
– требования по анализу данных (перечень задач анализа данных)
Документы должны содержать общие положения о составе и содержании, а также о порядке разработки, согласования и утверждения научно-проектной документации на проведение работ по сохранению объектов культурного наследия независимо от их принадлежности и форм собственности. Рекомендации могут использоваться при осуществлении ремонтно-реставрационных работ на объектах культурного наследия регионального значения.
– требования к аппаратному обеспечению- персональный компьютер, принтер, ксерокс, подключение к интернет.
– требования к системному программному обеспечению – операционная система Windows 7 и выше, офисный пакет для работы с документамти, браузер.
– значения базовых параметров хранилища данных (скорость обработки запросов, объемы используемых данных, актуализация данных, про-изводительность системы и т. д.)
В хранилища данных помещают данные, которые редко меняются. Хранилища ориентированы на выполнение аналитических запросов, обеспечивающих поддержку принятия решений для руководителей и менеджеров. При проектировании хранилищ данных необходимо выполнять следующие требования:
хранилище должно иметь понятную для пользователей структуру данных;
должны быть выделены статические данные, которые модифицируются по расписанию (ежедневно, еженедельно, ежеквартально);
должны быть упрощены требования к запросам для исключения запросов, требующих множественных утверждений SQL в традиционных реляционных СУБД;
должна обеспечиваться поддержка сложных запросов SQL, требующих обработки миллионов записей.
За всеми отчетами, панелями управления и инструментами бизнес-аналитики стоят хранилища данных. В них данные хранятся более эффективно, с меньшей частотой запросов на чтение и запись, и запросы из них молниеносно доставляются сотням и тысячам пользователей одновременно. В отличие от транзакционных баз данных, в хранилищах данных используются специализированные архитектуры и инструменты хранения, повышающие скорость обработки запросов и загрузки данных. К тому же хранилища данных очень легко масштабируются, что позволяет при необходимости без труда добавить больше источников данных и повысить эффективность аналитики и сбора информации. Наконец, хранилища данных обыкновенно без труда интегрируются со сторонними инструментами бизнес-аналитики и SQL-клиентами и поддерживают стандартные SQL-запросы, что позволяет использовать привычные навыки и инструменты.
– требования к квалификации персонала (программа обучения пер-сонала)
пользователь ПК, знание пакета Microsoft Office.
– перечень источников данных – интерент-ресурсы (сайты)
https://opendata.mkrf.ru/opendata/7705851331-egrkn/
https://files.stroyinf.ru/Data1/58/58906/index.htm#i97322
http://www.gostrf.com/normadata/1/4293797/4293797227.htm
– конкретизация плана реализации проекта разработки ХД (опреде-ляется дата завершения проекта).
В дополнение на основе собранной выше информации составляется план восстановления хранилища данных в случае аварийных сбоев. Разра-батывается стратегия архивирования и восстановления ХД.
Временные требования. Время выполнения этапа – от двух недель до двух месяцев.
Результатом выполнения этапа являются каталог требований, утвержденный заказчиком, и уточненный план проекта, который точно определяет используемые ресурсы и даты контрольных точек проверки хода выполнения проекта.
Потенциальные опасности. Этап формулирования требований часто оказывается одним из самых узких мест проекта создания ХД. Причина со-стоит в конфликте внутрикорпоративных интересов и в необходимости наладить коммуникации для успешного выполнения и этапа, и проекта в целом.
По определению складирование данных предполагает интеграцию в ХД данных из нескольких источников (подразделений организации). Позиция и взгляды подразделений на бизнес-информацию (производство данных, их верификацию, поставку данных в ХД, разграничение доступа к данным и т. д.) могут сильно расходиться и даже быть диаметрально про-тивоположными. Даже если команда разработчиков предложит блестящее решение по созданию ХД, его реализация может споткнуться о нежелание определенных групп потенциальных пользователей предоставлять данные в ХД или конструктивно участвовать в определении требований к системе складирования данных.
Если не удается наладить коммуникации между участниками про-цесса, то все усилия по созданию ХД будут потрачены впустую и проект никогда не будет завершен в установленные сроки, а в худшем случае просто будет провален.
Одним из способов избежать такой ловушки является непосредствен-ное вовлечение руководителей организации в процесс реализации проекта. Следует заручиться поддержкой влиятельного покровителя из числа высше-го руководства, чтобы можно было привлечь подразделения к сотрудниче-ству с командой разработчиков ХД.
Создание вычислительной среды
Описание задачи. Главной задачей этого этапа является создание ин-формационно-вычислительной среды, в которой будет разрабатываться ХД. Это достаточно важный этап. Вычислительная среда разработки ХД должна достаточно точно моделировать ту вычислительную среду, в которой реально будет эксплуатироваться ХД, т. е. она должна быть масштабируемой по аппаратному решению.
После того как требования к программно-аппаратной части опреде-лены, нужно обеспечить установку серверов приложений, серверов БД, клиентских рабочих станций и автоматизированных мест разработчиков.
На этом этапе должна быть достигнута полная ясность в том, как будут выполняться технологические работы по созданию ХД.
Причина, по которой лучше применять отдельную вычислительную среду для разработки, состоит в том, что внесение изменений и тестирование разрабатываемого ХД могут привести к аварийным сбоям в существующей вычислительной среде организации, что повлечет дополнительные эксплу-атационные издержки.
Временные требования. Закупка и установка серверов – до двух недель.
Монтажные работы по установке компьютерной сети – две-четыре недели.
Результатом выполнения этапа являются спецификации на про-граммно-аппаратное обеспечение, а также скрипты и установки для про-граммного обеспечения.
Потенциальные опасности. Самой большой опасностью является использование одного сервера БД для моделирования различных вычисли-тельных сред, например вычислительной среды разработки и вычисли-тельной среды тестирования или, что еще хуже, для вычислительной среды разработки и вычислительной среды эксплуатации ХД, особенно если на этом сервере работает уже существующая информационная система.
В этом случае могут возникнуть конфликты между различными участниками проекта создания ХД и ИТ-службой организации в случае не-предусмотренной остановки сервера БД.
Кроме того, в тестовой среде будет невозможно промоделировать ожидаемые показатели нагрузки на систему и оценить ее производитель-ность.
Моделирование данных
Создадим диаграммы А0 и А-0.
Для разработки системы сбалансированных показателей необходимо конкретизировать стратегические цели. Главной стратегической целью данной работы является реализация социального проекта. На рисунке 1 представленна диаграмма главного процесса.
Рисунок 1 Контекстная диаграмма
На входе контекстной диаграммы – социальные требования. Управление происходит исходя из требований FISU,стратегии развития региона, законодательство РФ и требований к проведению мероприятий. На выходе - социальный проект. Когда контекстная диаграмма составлена, выполняем ее декомпозицию. На рисунке 2 представлена декомпозиция главного процесса.
Рисунок 2 Декомпозиция главного процесса
В процессном подходе присутствуют следующие этапы: – анализ; – планирование; – исполнение; – мониторинг и контроль. Исходя из этого, мы провели декомпозицию материнской диаграммы, разделив ее на блоки: – анализ; – планирование; – исполнение.
Продолжение моделирования
На рисунке 3 представлена декомпозиция блока «Анализ состояния памятников». Анализ производится исходя из требований FISU Соответственно, анализ можно разделить на следующие блоки по которым происходила оценка готовности памятников к реставрации и ремонту: оценить инфраструктуру, оценить состояние памятников культуры, принять решение о реставрации памятников.
Рисунок 3 Декомпозиция процесса «Анализ состояния памятников»
На рисунке 4 представлена декомпозиция мониторинга и контроля по управления памятниками.
Рисунок 4 Диаграмма декомпозиции процесса «Мониторинг и контроль по управлению памятниками»
С.М. Ключников в своей статье «Разработка и внедрение ССП на практике» предлагает выделить следующие показатели: – уровень удовлетворенности клиентов; – степень выполнения индивидуальных решений; – доля расходов и т.д.[1] Из вышесказанного можно сделать вывод, что каждый социальный проект направлен на решение определенной проблемы, соответственно показатели эффективности зависят исключительно от цели социального проекта.
Каждая модель имеет определенную цель и создается с конкретной точки зрения. Выбор цели осуществляется с учетом вопросов, на которые должна ответить модель, а выбор точки зрения – в соответствии с выбором позиции, с которой описывается система.
Определение процедур извлечения преобразования и загрузки данных
Описание задачи. Главной задачей этапа является идентификация и определение процедур извлечения, очистки (фильтрации), преобразования и загрузки данных. Это весьма трудоемкий этап, не столько по временным затратам, сколько по усилиям, предпринимаемым по анализу структур данных источников и подающих систем.
Исключительно редким является случай, когда ХД создается на голом месте, т. е. в подразделениях отсутствуют автоматизированные подсистемы обработки данных. Как правило, данные уже существуют (в том или ином виде). Их нужно собрать, согласовать, привести к единому формату, агрегировать и загрузить в ХД. По этой причине этот этап является харак-терным для проекта создания ХД.
Также следует помнить о том, что сам процесс подготовки и загрузки данных в создаваемое ХД может занять более половины времени, отведен-ного на реализацию проекта, особенно в проектах большого масштаба.
Временные требования. Время выполнения этапа – от одной недели до полутора месяцев.
Результатом выполнения этапа являются схема соответствия данных подающих систем и ХД, программы или ETL-инструменты.
Потенциальные опасности. Первой потенциальной опасностью при выполнении этого этапа является недооценка временных параметров. Обычно на выполнение этапа выделяют немного времени. Процедуры из-влечения, преобразования и загрузки данных в ХД оказывают непосред-ственное влияние на качество и полноту предоставляемой конечным поль-зователям информации. Недостаточное внимание к разработке этих проце-дур может вызвать негативные реакции у пользователей после получения ими отчетов.
Второй потенциальной опасностью является стремление команды разработчиков сделать процесс ETL как можно более всеобъемлющим, мо-тивируя свои действия стремлением обеспечить качество данных. Следует помнить, что главная цель ETL-процесса – оптимизации скорости загрузки данных в ХД.
Проектирование аналитических отчетов
Описание задачи. Главной задачей выполнения этого этапа является проектирование и разработка аналитических отчетов на спроектированной структуре данных. Это также специфичный этап для проекта ХД.
Перечень требуемых отчетов содержится в Каталоге требований, и их разработка решает в целом поставленную задачу. Однако следует помнить, что потенциальные пользователи не всегда точно знают, что они хотят увидеть в отчетах. С другой стороны, как правило, собранные дан-ные предоставляют большие возможности по формированию разнообраз-ных отчетов, чем это зафиксировано в Каталоге требований. Здесь должен быть найден разумный компромисс.
Временные требования. Время выполнения этого этапа зависит от числа разрабатываемых отчетов. В зависимости от сложности отчета его разработка занимает от 4 часов до двух недель.
Результатом выполнения этапа станут спецификация кубов данных (измерения и метрики) и разработанные отчеты.
Потенциальные опасности. Потенциальной опасностью при выпол-нении этого этапа является то, что не уделяется достаточного внимания оптимизации времени получения отчета. Конечный пользователь не любит долго ждать. А если он получал такой отчет на своей настольной системе быстрее, то мнение о ХД у него будет, мягко говоря, неадекватное.
Хороший способ избежать такой опасности – тестирование разрабо-танных отчетов с целью минимизации времени их получения.
Разработка приложений ХД
Описание задачи. Главной задачей данного этапа является формиро-вание программной среды, в которой пользователи будут извлекать данные из ХД и просматривать предопределенные отчеты.
Каковы бы ни были инструментальные средства OLAP, необходимо продумать, как будут происходить визуализация отчетов и их доставка ко-нечному пользователю.
Временные требования. Срок выполнения этого этапа – от одной не-дели до месяца. При использовании тонкого клиента типа браузера следует исходить из того, что в среднем на разработку и отладку одной веб-страницы тратится полдня.
Результатом выполнения этапа будет документация, описывающая механизм доставки пользователям отчетов и спецификации экранных форм.
Потенциальные опасности. Самой большой потенциальной опасно-стью является ложное представление о достаточной квалификации пользо-вателей ХД для работы с ИТ-технологиями. Конечные пользователи хотят быстро получать данные, необходимые для решения своих конкретных за-дач, а не изучать многотомные инструкции по работе с программным обеспечением.
Если интерфейс интуитивно не понятен или не содержит ясных и кратких инструкций по работе с электронной формой (встроенных в форму Help), он не будет использовать систему складирования данных с должной эффективностью, что приведет к постепенному ее вымиранию.
Настройка производительности
Описание задачи. Главная задача выполнения этого этапа – добиться оптимальной производительности ETL-процессов, производства отчетов и их доставки конечному пользователю.
Извлечение, преобразование и загрузка данных, как правило, явля-ются длительным процессом, который выполняется в пакетном режиме с не очень высоким приоритетом. Пока данные не загружены в ХД, новые отчеты не могут быть получены.
При обработке некоторых запросов захватывается большое количе-ство данных, на которых выполняются динамические операции агрегиро-вания и суммирования, что приводит к значительному времени производ-ства отчета.
На доставку отчетов пользователю может влиять загрузка локальной вычислительной сети и большой объем сетевого трафика.
Временные требования. Время выполнения этого этапа не должно превышать одной-двух недель.
Результатом выполнения этапа является перечень рекомендаций по настройке производительности.
Потенциальные опасности. Потенциальной опасностью этого этапа считается использование вычислительной среды разработки ХД, которая не масштабируется к вычислительной среде эксплуатации ХД. Из-за этого рекомендации по настройке производительности не будут соответствовать реальным условиям эксплуатации ХД.
Проверка качества
Описание задачи. Главная задача этапа – убедиться, что ХД готово к эксплуатации. Как правило, проверка качества выполняется отдельной группой специалистов, не входящих в состав команды разработчиков.
Временные требования. Срок выполнения этого этапа – от одной до четырех недель.
Результатом выполнения этапа являются план тестирования ХД и заключение о готовности ХД к эксплуатации.
Потенциальные опасности. Самый большой риск любого проекта – это люди: их квалификация, амбиции, заинтересованность в деле, мотивы и т. д. Поскольку люди, проверяющие ХД на этом этапе, не входят в про-ектную команду, возникает потенциальная опасность, связанная с недо-статочной образованностью этих людей в области складирования данных. Разумным решением при выполнении этого этапа является привлечение организацией сторонних специалистов высокой квалификации по проверке качества ХД.
Передача системы складирования данных в эксплуатацию
Задача этапа. Главная задача этапа – передача системы ведения хранилища данных заказчику и представление ее конечным пользователям.
Временные требования. Срок выполнения этого этапа – от одного дня до нескольких недель.
Результатом выполнения этапа является акт о приемке-сдаче про-граммного продукта.
Потенциальные опасности. Самая большая потенциальная опас-ность для этого этапа – неготовность потенциальных пользователей к ра-боте с ХД. Хорошим правилом здесь будет проведение нескольких презен-таций и коротких обучающих курсов по работе с ХД.
Сопровождение и модификация хранилища данных
Обычно в проектный цикл включают еще два этапа – этап сопровож-дения ХД и этап его модификации. Это важные этапы в жизни ХД. Однако, как показывает опыт, целесообразно выделять их в самостоятельные проекты.
Было бы большой ошибкой поручать разработчикам ХД его сопро-вождение. Процессы сопровождения ХД требуют от ИТ-специалистов иной квалификации, чем процессы его разработки. Чтобы сопровождать, не обязательно уметь писать программы, но обязательно нужно уметь их настраивать и использовать.
Если необходимость в модернизации ХД возникает спустя несколько месяцев после сдачи его в эксплуатацию, это говорит о том, что проект не был успешным. Потребность в модернизации реально может сформироваться спустя шесть месяцев после интенсивной его эксплуатации, когда прове-рены его возможности, прочувствована отдача и видны новые перспективы использования, т. е. когда ХД стало частью производственного процесса. При этом не факт, что та же команда разработчиков будет заниматься его модернизацией.
Список использованных источников
Project Management Institute, Руководство к Своду знаний по управлению проектами (Руководство PMBOK®) [Электронный ресурс] : официальный сайт Project Management Institute. – Режим доступа: http://www.pmdoc.ru/ -pmbok5/
Бурмистров, А. Оценка эффективности управления предприятием / А.Бурмистров, В. Конаховская, М. Мясникова // Top-manager. – 2003. – № 5. – С. 10-15.
Гусева, Е.М. Опыт общественной оценки качества государственных и социальных услуг в Санкт-Петербурге / Е.М. Гусеева. – Санкт-Петербург: ЦРНО, 2014.– 140 с.
Рождественская, Н.В. Оценка эффективности некоммерческих организаций, социального предпринимательства и гражданских инициатив / Н.В. Рожденственская.– Санкт- Петербург: Благотворительный фонд Потанина – 2016.- 98 с.