Моделирование и разработка WfMS НИУ ВШЭ — Пермь
Первым этапом моделирования является постановка задачи. Задача может быть поставлена в любой форме: в виде словесного описания, графического или в виде программного кода. Второй этап — формализация. Он включает в себя создание модели на выбранном формальной языке, опираясь на поставленную задачу. Перед тем как преступить к построению модели важно выбрать инструменты и стандарты. Модель… Читать ещё >
Моделирование и разработка WfMS НИУ ВШЭ — Пермь (реферат, курсовая, диплом, контрольная)
Данная глава посвящена практической части работы. Она содержит параграфы, описывающие моделирование основных процессов WfMS, создание схемы данных, особенности проектирования и разработки WfMS, преимущества MS SharePoint в разработке системы.
Использование MS SharePoint 2010 при разработке WfMS НИУ ВШЭ — Пермь
В качестве заказчика на разработку WfMS выступает факультет бизнес-информатики НИУ ВШЭ — Пермь и одним из его требований является разработка системы с помощью MS SharePoint 2010.
SharePoint имеет ряд отличительных черт, которые будут использованы при разработке системы, а именно он позволяет:
- · создавать порталы, способные хранить и оперировать с данными разных типов;
- · настраивать сервисы под определенные нужды в рамках исследуемой предметной области;
- · разрабатывать ряд программных решений и надстроек, позволяющих выполнять нетривиальные операции;
- · организовывать совместную работу.
Разрабатываемая служба технической поддержки будет представлять собой веб-портал, созданный с помощью MS SharePoint 2010. Основными элементами этого портала будут списки и программные решения, созданные с применением различных технологий и языков программирования, таких как C#, JavaScript, ASP.NET.
Портал можно разделить на две области: область работы с пользователями — CRM модуль и область, отвечающая за выполнение заявок — WfMS. Именно в рамках разработки WfMS проводится исследование данной работы.
WfMS на уровне веб-портала службы технической поддержки будет представлять собой совокупность списков и программных решений, разработанных для выполнения определенных операций.
Таким образом, WfMS невидима для обычного пользователя и будет являться рабочей областью технического персонала. Таким образом, следует определить роли людей внутри системы:
Оператор. Оператору приходят обработанные заявки из CRM системы. Его основными обязанностями являются: определение задач путем декомпозиции заявки, распределение ресурсов на задачи и контроль хода их выполнения.
Дежурный инженер. Член инженерно-технического и исполнительного персонала WfMS, ответственный за выполнение порученных ему задач.
Главным элементом системы будет являться список задач, содержащий в себе информацию о поставленных задачах, полученных путем разбиения заявки на этапы подобно определению рабочего процесса в XPDL. Одной из особенностей списка будут представления. Например, будет реализовано представление, отображающие архивные задачи — те задачи, которые закрыты и помещены в архив.
Таким образом, список задач, в зависимости от представления, отображает:
- 1) Актуальные задачи.
- 2) Архивные задачи.
Следующим составным элементом является список ресурсов. Он будет содержать в себе перечень ресурсов, которые можно использовать при выполнении задач. Одной из основных целей WfMS является реализация функции распределения ресурсов. Для этого каждый ресурс имеет свои характеристики, которые используются в разрабатываемых средствах анализа, мониторинга и распределения ресурсов.
Третьим списком системы является список назначений ресурсов на задачи. Он содержит в себе подробную информацию о том, какие ресурсы и на какую задачу были назначены. Список необходим для проведения мониторинга и оперативного анализа по текущим задачам и ресурсам. Как в случае со списком задач, назначения могут быть как актуальными, так и архивными.
Звеном взаимодействия CRM и WfMS является список, который будет наполняться данными, посылаемыми обеими системами. CRM модуль должен предоставить заявку, а WfMS удовлетворить ее и подготовить решение, отослав его в общий список.
Кроме того, возможность совместной работы, которую обеспечивает MS SharePoint, предоставляет инженерно-техническому персоналу свободу действий в плане работы на портале, что дает большое преимущество в экономии времени и трудовых ресурсов.
Таким образом, благодаря уже существующим инструментам SharePoint вроде списков, разработка системы упрощается, а время разработки сокращается. Подробнее об особенностях разработки системы будет рассказано в параграфах о моделировании бизнес-процессов и разработке WfMS.
2.2 Моделирование основных бизнес-процессов WfMS НИУ ВШЭ — Пермь Данный параграф содержит описание этапа моделирования WfMS как в целом, так и с учетом конкретных особенностей системы.
Особенности проектирования WfMS НИУ ВШЭ — Пермь.
В предыдущем параграфе были описаны преимущества MS SharePoint, используемые при создании системы. Кроме того, там было кратко рассказано о некоторых особенностях WfMS, которым посвящен данный параграф.
С общими требованиями можно ознакомиться в приложении Б, в котором содержится ТЗ на разработку WfMS НИУ ВШЭ — Пермь.
Первым шагом моделирования WfMS стало определение требований. Ниже описаны обобщенные требования, выполнение которых подтверждает, что WfMS достаточна сложна для того, чтобы считаться отдельной системой, существующей в рамках более крупной системы технической поддержки:
Интероперабельность. WfMS должна быть способна к взаимодействию с CRM системой. Системы взаимодействуют путем использования общих списков MS SharePoint на портале службы технической поддержки.
Масштабируемость. НИУ ВШЭ — Пермь реализует стратегию развития до 2020, которая включает в себя увеличение учебных площадей, внедрение новых информационных сервисов и технического оборудования. Потому важно разработать систему таким образом, чтобы в будущем она смогла справиться с увеличивающейся нагрузкой. Отчасти, это свойство достигается тем, что служба технической поддержки представляет собой комбинацию виртуальной службы поддержки и распределенной службы с центральной точкой приема заявок.
Синергичность. В будущем новые идеи и технологии могут быть использованы для улучшения отдельных частей WfMS, поэтому важно, чтобы улучшение отдельных элементов вело к улучшению производительности системы в целом. В качестве примера можно привести время выполнения заявки системой. Если улучшить временной показатель процессов распределение ресурсов и составления отчетности, то время работы системы в целом так же сократится.
Эмерджентность. WfMS представляет собой набор взаимосвязанных процессов, которые по отдельности неспособны дать необходимый результат. Система же объединяет все процессы вместе с целью получения конечного результата.
Наличие средств администрирования и контроля. Крайне обширное и труднореализуемое свойство. Смысл заключается в том, чтобы система всегда содержала инструмент, позволяющий контролировать активности и оценивать эффективность выполняемых действий.
Ранее были описаны роли, исполняемыми людьми в рамках WfMS, однако стоит четко их различать и выделять зоны их ответственности:
Оператор отвечает:
- · за декомпозицию заявки на задачи;
- · за назначение ответственного исполнителя (дежурного инженера) на задачу;
- · за распределение ресурсов на задачи (в зависимости от ситуации — совместно с дежурным инженером);
- · за архивирование и восстановление задач.
Дежурный инженер ответственен:
- · за выполнение поставленной оператором задачи;
- · за заполнение форм отчетности по проделанной работе.
Только люди этих ролей входят в состав WfMS, в то время как обычный пользователь — в состав CRM. Однако в отдельных случаях пользователь может взаимодействовать как с оператором, так и с дежурным инженером.
Оператор отвечает за разбиение заявки на задачи, потому важно определить, что такое задача. В рамках портала задача есть элемент списка задач, имеющий набор полей. В предыдущем параграфе отмечалось, какой статус может иметь задача:
- · Актуальная — задача находится на стадии выполнения.
- · Архивная — задача, по тем или иным причинам, отправленная в архив.
Наличие особенности определения задач внутри системы удовлетворяет требованию, описанному в стандарте WfRM, согласно которому WfMS должна включать в свой состав уровень создания и управления рабочих процессов.
Построение моделей основных бизнес-процессов WfMS НИУ ВШЭ — Пермь Моделирование как процесс может быть разбит на несколько составляющих: постановка задачи, формализация или создание модели и представление результатов. Правильно составленная модель обеспечит успешное проектирование и разработку системы в целом.
Первым этапом моделирования является постановка задачи. Задача может быть поставлена в любой форме: в виде словесного описания, графического или в виде программного кода. Второй этап — формализация. Он включает в себя создание модели на выбранном формальной языке, опираясь на поставленную задачу. Перед тем как преступить к построению модели важно выбрать инструменты и стандарты. Модель разрабатываемой WfMS может быть построена с помощью различных нотаций, таких как: ARIS, IDEF0/SADT, UML и других.
Было решено, что для построения процессов системы будет использоваться нотация ARIS eEPC. Методология была выбрана благодаря простоте своего освоения и наглядности полученных результатов.
Важнейшей частью при проектировании системы является моделирование процессов этой системы. В приложении, А отображены основной бизнес-процесс выполнения заявки и управляющий процесс распределения ресурсов.
В рамках основного бизнес-процесса выполнения заявки отображаются основные процессы, протекающие в WfMS.
Первым этапом процесса является анализ заявки, пришедшей из CRM. Затем происходит декомпозиция заявки на задачи при участии оператора. Следующим важным этапом является процесс распределения ресурсов, схемы алгоритма которого можно посмотреть в приложении Д. После выполнения всех связанных задач, происходит генерация отчета о выполненной работе и его отправка обратно модулю CRM.
Построение процесса, таким образом, позволяет сократить среднее время выполнения заявки путем: распределения обязанностей между оператором и дежурным инженером; реализацией функций распределения ресурсов по задачам и генерацию отчетов о выполненных работах. В противном случае, все эти действия выполняются вручную и зачастую одним человеком.
В предыдущей главе рассматривался XPDL — язык моделирования бизнес — процессов. Его основная идея заключалась в разбиении крупных задач на более мелкие. Этот принцип взят за основу при моделировании WfMS: заявка разбивается на задачи, которые в свою очередь могут включать в себя использование материальных, денежных или трудовых ресурсов. Так же между задачами могут существовать переходы в зависимости от конкретной ситуации.
Выполнение управляющего процесса происходит при участии оператора и программных средств WfMS. Это одна из наиболее важных функций, выполнение которой определяет успешность выполнения главного бизнес-процесса. В рамках проводимой работы по разработке WfMS, данный бизнес-процесс будет реализован на основе списка MS SharePoint и разработанного программного решения в виде обработчиков событий и визуальных веб-частей.
Реализация функционала распределения ресурсов на задачи является наиважнейшей частью WfMS как признак автоматизированной системы. Быстрое и правильное назначение ресурса позволит скоординировать действия КЦ и ВШЭ — Пермь как предприятия вообще.
Было решено классифицировать ресурсы на три вида:
- 1. Трудовые ресурсы. Человеческие ресурсы, предполагается, что ресурсами этого вида будут сотрудники КЦ.
- 2. Материальные ресурсы. Обычные технические, аппаратные, программные и другие вспомогательные средства. Разделяются на расходные материалы и обычные.
- 3. Денежные ресурсы.
Таким образом, после принятия заявки, распределения ресурсов и ее закрытия происходит архивирование связных задач, которые физически она не удаляются, а помещаются в специальный раздел и в случае чего могут быть восстановлены.
Отчет, составленный по итогам выполнения заявки, представляет собой поле «Описание решения» общего списка модулей, отображающее отчеты по связным задачам.
После разработки основных бизнес-процессов, стоит задуматься о поведении системы в целом. Очень часто при проектировании систем пропускаются важные детали, определяющие характер функционирования системы в определенных ситуациях. Потому была составлена схема прецедентов, показанная на рисунке 2.1.
При разработке диаграммы прецедентов были проанализированы различные случаи, которые могут повлиять на логику работы WfMS. Рассмотрение данных прецедентов позволяет заранее разработать систему с учетом критических ситуаций. Основной причиной неправильного функционирования системы могут стать действия человека. Разработанная диаграмма отражает все возможные действия человека при вмешательстве в работу системы. Кроме сотрудников WfMS была рассмотрена ситуация, когда пользователь отменяет заявку, выполнение которой уже началось.
Рисунок 2.1. Диаграмма прецедентов WfMS.