Лабораторная работа 1. Предпроектные исследования предметной области
 Скачать 1.4 Mb.
|
|
работы системы В данном разделе приводятся уточненные решения по режимам функционирования, диагностированию работы системы на основании аналогичного разделапояснительной записки к эскизному проекту. Приводится описание решений по диагностированию системы, осуществляемых путем установления и изучения признаков, которые характеризуют состояние системы для предсказания возможных отклонений и предотвращения нарушений нормального режима ее работы. Например: Предлагается следующая реализация решений по режимам функционирования системы: Основной режим, в котором все подсистемы выполняют свои основные функции. Профилактический режим, в котором одна или все подсистемы не выполняют своих функций. В данный режим работы система переходит в следующих случаях: возникновение необходимости модернизации аппаратно-программного комплекса; возникновение необходимости проведения технического обслуживания; выход из строя аппаратно-программного комплекса, вызванный выходом из строя элементов аппаратной или программной базы; выход из строя сети передачи данных и другие аварийные ситуации. В основном режиме функционирования система обеспечивает: работу пользователей в режиме – 24 часа в день, 7 дней в неделю (24х7); выполнение своих функций – сбор, обработка и загрузка данных; хранение данных, предоставление отчетности по показателям. В профилактическом режиме система обеспечивает возможность проведения следующих работ: - техническое обслуживание; модернизация аппаратно-программного комплекса; устранение аварийных ситуаций. Принимается предварительное решение о том, что общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (XX часов в месяц). Принимается предварительное решение о том, что для обеспечения высокой надежности функционирования как системы в целом, так и ее отдельных компонентов необходимо проводить регулярное диагностирование состояния компонентов. В таблице ниже представлены средства диагностики по подсистемам. Подсистема Средства диагностирования Подсистема сбора, обработки и загрузки ETL Administrator – диагностика и настройка ETL- приложения, управление критериями извлечения, установка 95 данных NLS; ETL Manager - просмотр и редактирование репозитория. Подсистема хранения данных DB Manager – диагностика и настройка и конфигурация одной или более БД Подсистема отображения отчетности BI Administrator – диагностика и настройка бизнес-описания и представления витрин данных Далее для каждой подсистемы приводятся примерные сценарии проведения их диагностирования. Чтобы описать сценарии диагностирования необходимо ответить на следующие вопросы: «Кем проводится диагностирование?», «Какое программное обеспечение используется?», «Какие действия необходимо провести для диагностирования (действия прописываются общие, например, зайти, открыть, проверить)?», «Что необходимо проверить? (например, наличие свободного места на дисках)», «Как часто необходимо выполнять данные действия?». Необходимо также указывать критичность подсистемы для функционирования системы в целом. Например: Подсистема сбора, обработки и загрузки данных : администратор подсистемы должен каждый день контролировать работоспособность серверной части прикладного программного обеспечения сбора, обработки и загрузки данных, т.к. данная подсистема является критичной для работоспособности системы в целом; администратор подсистемы перед началом загрузки данных должен проводить контроль объема свободного места на дисках для временных файлов; администратор подсистемы должен каждый день проводить анализ протоколов работы подсистемы на наличие ошибок и предупреждений, возникающих при ее работе. 2.4. Решения по персоналу и режимам его работы В данном разделе приводятся уточненные решения по численности, квалификации и функциям персонала создаваемой системы, режимам работы персонала на основаниианалогичного раздела пояснительной записки к эскизному проекту. Например: 4.1.2.1. Требования к численности персонала В составе персонала, необходимого для обеспечения эксплуатации КХД в рамках соответствующих подразделений Заказчика, необходимо выделение ответственных лиц на следующие роли. Роль Количество Руководитель эксплуатирующего подразделения 1 человек Администратор подсистемы сбора, обработки и загрузки данных 2 человека Администратор подсистемы хранения данных 2 человека Администратор подсистемы формирования и визуализации отчетности 1 человек 96 Лица, которым назначены данные роли, должны выполнять следующие функциональные обязанности. Роль Функциональные обязанности Период выполнения Руководитель эксплуатирующе го подразделения Обеспечение работы системы в целом и ответственность за достоверность хранимых данных Весь период внедрения и эксплуатации Обеспечение общего руководства группой сопровождения Весь период внедрения и эксплуатации Администратор подсистемы сбора, обработки и загрузки данных Обеспечение загрузки данных из внешних источников в хранилище данных Весь период внедрения и эксплуатации Контроль работы процессов ETL Весь период внедрения и эксплуатации Разработка новых и модификация существующих ETL-процессов По запросу администратора подсистемы формирования и визуализации отчетности Администратор подсистемы хранения данных Распределение дисковой памяти и планирование будущих требований системы к памяти Весь период внедрения и эксплуатации Модификация структуры базы данных в соответствии с потребностями приложений По запросу администратора подсистемы формирования и визуализации отчетности или по запросу администратора подсистемы сбора, обработки и загрузки данных Отслеживание и оптимизация производительности базы данных Весь период внедрения и эксплуатации Планирование и проведение резервного копирования и В соответствии с регламентом 97 восстановления резервного копирования и восстановления Администратор подсистемы формирования и визуализации отчетности Разработка витрин данных По результатам формализации требований к витрине Разработка отчетности По результатам формализации требований к отчетности Разграничение прав доступа на уровне витрин данных и отчетности По результатам формализации требований к разграничению прав доступа, разработки необходимых структур и объектов 4.1.2.2. Требования к квалификации персонала К квалификации персонала эксплуатирующего Систему КХД, предъявляются следующие требования. Роль Требования к квалификации Конечный пользователь Знание соответствующей предметной области; знание основ многомерного анализа; знания и навыки работы с аналитическими приложениями Администратор подсистемы сбора, обработки и загрузки данных Знание методологии проектирования хранилищ данных; знание методологии проектирования ETL- процедур; знание интерфейсов интеграции ХД с источниками данных; знание СУБД; знание языка запросов SQL Администратор подсистемы хранения данных Глубокие знания СУБД; знание архитектуры «Звезда» и «Снежинка»; опыт администрирования СУБД; знания и навыки операций архивирования и восстановления данных; знания и навыки оптимизации работы СУБД Администратор подсистемы формирования и визуализации отчетности Понимание принципов многомерного анализа; знания методологии проектирования хранилищ данных; знание и навыки администрирования приложения; знание языка запросов SQL; знание инструментов разработки 98 4.1.2.3. Требуемый режим работы персонала Персонал, работающий с Системой КХД и выполняющий функции еѐ сопровождения и обслуживания, должен работать в следующих режимах: Роль Режим работы Подразделение Руководитель эксплуатирующего подразделения В соответствии с основным рабочим графиком подразделений Заказчика. Предусматривается ненормированный рабочий день. Департамент информационных технологий Конечный пользователь В соответствии с основным рабочим графиком подразделений Заказчика Отдел анализа Администратор подсистемы сбора, обработки и загрузки данных Двухсменный график, поочередно Департамент информационных технологий Администратор подсистемы хранения данных Двухсменный график, поочередно Департамент информационных технологий Администратор подсистемы формирования и визуализации отчетности В соответствии с основным рабочим графиком подразделений Заказчика. Предусматривается ненормированный рабочий день. Департамент информационных технологий 2.5. Сведения об обеспечении заданных в техническом задании потребительских характеристик системы, определяющих ее качество Приводятся уточненные сведения об обеспечении заданных в техническом заданиипотребительских характеристик системы (подсистем), определяющих ее качество. Приводится таблица трассировки требований, заданных в техническом задании, и описанных проектных решений (достигается, нет, в какой степени, за счет чего?). Например: Требование Метод реализации Взаимодействие со смежными системами Реализуется за счет наличия интерфейсов с системами – источниками данных. Планируется использование промежуточных баз данных; интеграция «точка – точка» (point-to-point); интерактивная загрузка информации из файлов определенного формата. Диагностирование системы Реализуется путем определения перечня работ по диагностированию подсистем. 99 Сохранение работоспособности системы в различных вероятных условиях Реализуется путем разработки процедур резервного копирования, подготовки персонала, использования современных методов разработки и проверенных на практике стандартных программных средств. На объекте автоматизации обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР, в соответствии с утвержденными для каждого объекта ХД мероприятиями по поддержанию его работоспособности. Приводятся сведения об обеспечении заданных в техническом задании требований к функциям, выполняемым каждой подсистемой, определяющих ее качество. Например: Подсистема Функция Метод реализации Подсистемасбора, обработки и загрузки данных Управление процессами сбора, обработки и загрузки данных Путем внедрения комплексного ETL-приложения Запуск процессов сбора, обработки и загрузки данных из источников в ХД Путем разработки и внедрения регламентов запуска ETL- процессов Подсистема хранения данных Создание и сопровождение структур базы данных Путем применения CASE средства и средств администрирования СУБД Осуществление резервного копирования данных Путем применения следующих видов копирования: полное холодное копирование; логическое копирование; инкрементальное копирование 2.6. Состав функций, комплексов задач, реализуемых системой Приводится наименование и назначение функциональных комплексов задач системы (или по каждой подсистеме). Функциональные задачи по мере проработки проектных решений, описываются в виде сценариев. Описания сценариев могут быть вынесены в приложение к пояснительной записке. Процесс формирования сценариев выполнения задач функций каждой подсистемы производится следующим образом: приводится наименование подсистемы, далее приводится наименование функции подсистемы, внутри 100 каждой функции перечисляются задачи, которые выполняются в еѐ рамках (за основу принимаетсяаналогичный раздел из пояснительной записки к эскизному проекту), для каждой задачи формируется таблица вида: Подзадача Действие В данной таблице для каждой задачи приводится перечень подзадач и сценарий их выполнения. Перечень подзадач формируется следующим образом: берется наименование задачи и из названия задачи выделяются подзадачи, например задача «Поддержка (разработка, модификация) модели ХД» содержит в себе две подзадачи «Разработка» и «Модификация», задача «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» содержит в себе следующие подзадачи: «Создание нового процесса», «Редактирование процесса», «Удаление процесса» и т.п. Далее для каждой выделенной подзадачи приводится описание сценариев еѐ выполнения. Сценарий формируется путем последовательных ответов на следующие вопросы: Вопрос: «Кто производит действия для выполнения подзадачи?» Ответ: «Администратор подсистемы...» Вопрос: «Что должен сделать Администратор? К какому ПС обратиться? Какой файл выбрать?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... » Вопрос: «Какие действия после открытия в рамках подзадачи должен выполнить Администратор?» Ответ. «Администратор подсистемы обращается к программе ... и открывает ранее разработанный ... Администратор вносит изменения в ..., содержащие ...» Вопрос: «Какие действия выполняет сама подсистема в момент действия Администратора? Появляется ли диалоговое окно?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ...» Вопрос: «Какие действия выполняет Администратор после появления диалогового окна?» Ответ: «Администратор подсистемы обращается к программе ... и открывает ранее разработанный .... Администратор вносит изменения в ..., содержащие .... Подсистема запрашивает необходимость сохранения работы в виде рабочего файла ... Администратор подтверждает команду сохранения.». Например, таблица, содержащая описание сценариев для подзадач задачи "Создание, редактирование и удаление процессов сбора, обработки и загрузки данных", функции "Управление процессами сбора, обработки и 101 загрузки данных", подсистемы "Подсистема сбора, обработки и загрузки данных", будет выглядеть следующим образом. 2.6.1 Подсистема сбора, обработки и загрузки данных 2.6.1.1 Функция «Управление процессами сбора, обработки и загрузки данных» Описание возможного сценария для последующей реализации задачи «Создание, редактирование и удаление процессов сбора, обработки и загрузки данных» приведено в таблице. Подзадача Действие Создание нового процесса Администратор обращается к модулю разработки подсистемы на сервере разработки. Подсистема предоставляет инструментальные средства для создания нового процесса. Администратор подсистемы создает схему нового процесса ETL. На схеме указываются компоненты процесса: источники данных, компоненты преобразования данных, таблицы БД. Администратор подсистемы инициирует команду сохранения созданного процесса. Подсистема размещает созданный процесс на сервере среды разработки. Администратор подсистемы выполняет запуск, тестирование и отладку создаваемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности нового процесса. Готовый процесс переносится на продуктивный сервер. Редактирование процесса Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. Используя инструментальные программные средства подсистемы, Администратор изменяет схему процесса ETL, размещает измененный процесс на сервере среды разработки. Подсистема размещает редактируемый процесс на сервере среды разработки. Администратор подсистемы выполняет запуск, тестирование и отладку редактируемого процесса. На вход процесса подаются тестовые данные. Анализируя итоговые таблицы БД среды разработки, Администратор принимает решение о готовности редактируемого процесса. Готовый процесс переносится на продуктивный сервер. Удаление процесса Администратор подсистемы вызывает подсистему среды разработки на сервере разработки. Используя инструментальные программные средства подсистемы, Администратор удаляет процесс ETL, размещает изменения на сервере среды разработки. Подсистема размещает внесенные изменения на сервере 102 среды разработки. Изменения переносятся на продуктивный сервер. Рекомендации. Подобным образом формируется описание действий, выполняемых для реализации каждой подзадачи задач функций для каждой подсистемы. При этом детализация описания сценария более подробна, чем на этапе эскизного проектирования. Приводятся конкретные действия по настройке или разработке. Те сценарии (например, для алгоритмы разработки ETL-процессов, настройки отчетности, которые достаточно объемны, выносятся в отдельные приложения и в сценариях на них дается ссылка). Допускается при описании сценария вставка пояснительных рисунков (например, схема организации разграничения прав доступа и т.п.). При описании данных сценариев должны быть тщательно проработаны все технические решения. 2.7. Состав и размещение комплексов технических средств Уточненные решения по комплексу технических средств, его размещению на объекте. В данном разделе актуализируется схема, приведенная в аналогичном разделе пояснительной записки к эскизному проекту. В схему вносятся следующие изменения: обозначаются подсети размещения серверов и рабочих станций, актуализируется состав портов и протоколов, актуализируется набор компонентов, устанавливаемых на сервера. Например: 103 Ниже данной схемы приводится расшифровка использованных в ней сокращений. Также приводится описание сценария взаимодействия между компонентами системы с точки зрения сетевого взаимодействия. Например: AD Server – служба каталога Active Directory, содержащая учетные записи пользователей информационных ресурсов и являющаяся источником информации об учетных записях сотрудников Заказчика. Firewall – межсетевой экран. Application Server – сервер приложений. ETL server – сервер, на котором устанавливается ПО подсистемы извлечения, преобразования и загрузки данных. DB server – сервер, на котором устанавливается ПО подсистемы хранения данных. Ниже приведено описание сценария взаимодействия между компонентами системы: 1 – Используя WEB-браузер, пользователь заходит по адресу системы КХД. Через Firewall запрос пользователя передается на сервер приложений. 2 – Сервер проверяет наличие пользователя в группе пользователей системы в Active Directory. – Для получения данных в отчетах по запросам пользователей, BI- приложение обращается к серверу базы данных. 4 – ETL server производит загрузку данных в БД системы КХД. 5 – ETL server в соответствии с регламентом производит извлечение данных из систем источников. Далее приводится |