CC BY
142
В ходе работы были выявлены требования к бизнес-приложению, при выполнении которых система репликации способна корректно функционировать. Эти требования носят характер промежуточных ограничений. Некоторые из них можно ослабить или убрать, введя новые механизмы в процесс репликации. Основные из них:
1. Все операции обновления базы данных происходят через ORM-слой, причём без использования прямых HQL запросов [12] типа “UPDATE ... SET ...” и “DELETE FROM ...”;
2. Любой бизнес-объект можно корректно загрузить штатными средствами Hibernate
[13];
3. На одну таблицу БД отображено не более одного бизнес-класса;
4. Все бизнес-классы допускают сериализацию и десериализацию с помощью какого-либо механизма, например, XStream [14].
Приведение XWiki в соответствие с этими требованиями позволило создать работающий прототип системы репликации.
Литература
1. Иртегов Д.В. Введение в сетевые технологии. — СПб.: БХВ-Петербург, 2004, стр.468
2. http://www.agiledata.org/essavs/mappingObiects.html (Mapping Objects to Relational Databases: O/R Mapping In Detail)
3. http://www.hibernate.org/about/orm.html (What is Object/Relational Mapping?)
4. http://www.xwiki.org/ (XWiki, an open-source wiki and content-oriented application platform)
5. http://www.hibernate.org/ (Hibernate, relational persistence for Java & .NET)
6. http://docs.iboss.org/hibernate/core/3.3/reference/en/html/mapping.html, Chapter 5.1.4.1. Generator (Hibernate documentation)
7. http://iava.sun.com/i2se/1.5.0/docs/api/iava/util/UUID.html#randomUUID() (Java 2 SE 5.0 documentation)
8. http://iava.sun.com/i2se/1.5.0/docs/api/iava/util/zip/Deflater.html (Java 2 SE 5.0 documentation)
9. Э. Таненбаум, М. ван Стеен. Распределенные системы. Принципы и парадигмы. — СПб.: Питер, 2003, стр.376
10. http://www.ibm.com/developerworks/lotus/library/ls-Domino Replication/index.html, PULL-PUSH (Notes from Support: Lotus Notes/Domino Replication)
11. Э. Таненбаум, М. ван Стеен. Распределенные системы. Принципы и парадигмы. — СПб.: Питер, 2003, стр.371
12. http://docs.iboss.org/hibernate/core/3.3/reference/en/html/quervhql.html (HQL: The
Hibernate Query Language)
13. http://docs.iboss.org/hibernate/stable/core/api/org/hibernate/Session.html#load(iava.lang.Stri ng,%20iava.io.Serializable) (Hibernate Core 3.5.0 API)
14. http://xstream.codehaus.org/ (XStream, a simple library to serialize otyects to XML and back)
УДК 004.422.81
КОРПОРАТИВНАЯ ИНФОРМАЦИОННАЯ СИСТЕМА ОБРАБОТКИ ЗАЯВОК НА
ОБСЛУЖИВАНИЕ
Бойко Алексей Павлович, студент, Томский Государственный Университет Систем Управления и Радиоэлектроники, Россия, Томск, flash-in-dark@vandex.ru
Уровень информатизации современного общества диктует условия необходимые для эффективного функционирования крупных компаний - сегодня трудно себе представить
99
успешный бизнес, в котором не имела бы места какая-либо автоматизация деятельности. Поэтому больше руководителей начинают отчетливо осознавать важность построения на предприятии корпоративной информационной системы, как необходимого инструментария для успешного управления.
Одной из важных составляющих подобных систем является служба технической поддержки ввиду ее ориентированности на пользователей. Служба технической поддержки или техподдержка (Technical support, Helpdesk, Service desk) - сервисная структура, позволяющая своевременно устранять проблемы, возникающие у пользователей и клиентов [1].
В концепции ITIL - библиотеке, описывающей лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся
предоставлением услуг, Service Desk является единственным функциональным
подразделением. Это исключение сделано ввиду большой важности подразделения техподдержки при практическом использовании современных подходов и методик [2].
Если в организации отсутствует служба поддержки, не редки ситуации, когда у клиентов возникает какой-либо вопрос или проблема, и они обычно хотят получить ответ как можно быстрее, но зачастую это затруднено по ряду причин: нужного человека нет на месте, непонятно к кому нужно обращаться по данному вопросу и т.д. [3]
Текущая ситуация во множестве компаний такова, что:
• нет структурированного механизма обеспечения поддержки;
• требования бизнеса переросли существующую систему поддержки;
• накладные расходы для обеспечения поддержки слишком велики;
• предприятие излишне зависит от определённых ключевых людей;
• имеют место некоординированные и письменно незафиксированные изменения;
• время ответа и качество предоставляемой поддержки не соответствуют требованиям бизнеса.
Для исправления сложившейся ситуации необходим консолидированный командный подход, позволяющий уделять больше времени планированию, обучению, более тесной работе с клиентами, то есть позволяющий вести более активную деятельность. Первым шагом на пути создания полноценной службы технической поддержки является внедрение службы приема и обработки заявок, реализация которой и является темой данной работы.
Система обработки заявок - это система, позволяющая вести учёт поступающих заявок от пользователей уровня предприятия, которая помогает упростить процесс отслеживания хода различных работ и организовать интеллектуальное и эффективное управление задачами внутри компании и ее филиалов.
Подобные системы широко используются менеджерами в различных структурах для распределения заданий между сотрудниками: сотрудниками отделов продаж и маркетинга для работы с клиентами, службами поддержки пользователей, разработчиками ПО для ведения проектов и во многих других целях. Отсутствие жёсткого контроля рабочих процессов, а также возможность гибкой настройки системы и её расширяемость, позволяет добиться эффективной реализации бизнес-процессов конкретной задачи.
К основным задачам, решаемым системой, относятся:
• Автоматизация процесса обработки заявок на услуги в части регистрации, согласования и обработки поступивших заявок;
• Создание единого, структурированного хранилища заявок с возможностью поиска и фильтрации заявок, анализа проблем и оптимизации поддержки;
• Формирование аналитических и отчетных материалов по результатам обработки заявок;
• Сокращение времени необходимого для обработки поступивших заявок;
• Организация механизма разграничения полномочий пользователей при работе с системой в соответствии с требованиями локально-нормативных документов.
100
Учитывая современные требования к корпоративным системам [4], было принято решение о реализации системы в виде корпоративного портала для внутреннего использования. В качестве преимуществ подобной архитектуры следует отметить более стойкую безопасность, за счет того, что все данные хранятся централизованно и контроль полномочий для управления этими данными также проверяется на стороне сервера; расширяемость - при необходимости можно распределить нагрузку на серверную часть между несколькими компьютерами в сети; гибкость использования - для доступа к системе пользователю требуется только браузер, тем самым многие снимаются требования к программному и аппаратному обеспечению.
Для реализации системы применялось свободное программное обеспечение. Серверная часть системы основана на связке Apache 2.2 + MySQL + PHP. В качестве клиента может быть использован любой современный интернет-обозреватель: Internet Explorer 6.0 и выше, Opera 9 и выше, Safari, Konqueror, Google Chrome и т.д. За основу для разработки программной части системы был взят Yii - высокоэффективный основанный на компонентной структуре PHP-фреймворк для масштабных веб-приложений. Он позволяет максимально применить концепцию повторного использования кода и позволяет существенно ускорить процесс разработки системы.
Основной особенностью выбранного фреймворка является поддержка архитектуры MVC. MVC или Модель-представление-поведение - архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.
Обеспечение информационной безопасности является одним из необходимых аспектов ведения бизнеса в условиях современной рыночной экономики. По мере развития организации усложняется ее информационная система, основной задачей которой является обеспечение максимальной эффективности ведения бизнеса в постоянно меняющихся условиях конкуренции на рынке.
Именно поэтому информационная безопасность должна быть индивидуальной и основанной на специфике бизнеса заказчика, поэтому был разработан механизм создания и настройки ролей пользователей системой. Каждая роль характеризуется набором допустимых операций, которые оговорены регламентом. В качестве основных ролей были выбраны следующие: оформитель заявки, исполнитель заявки, региональный менеджер, заместитель отдела, начальник отдела, системный администратор, архивариус.
В ходе разработки был выстроен бизнес-процесс (см. рис. 1), схожий с представленным в литературе [5], обеспечивающий эффективный прием заявок и контроль их исполнения и автоматизированы следующие процессы: оперативный, документированный, удобный прием заявок; анализ поступающих заявок с целью планирования и оптимизации будущих работ; непосредственное планирование работ на определенный период времени с учетом приоритета их исполнения, назначение исполнителей/наблюдателей; контроль выполнения работ; анализ фактически выполненных работ по видам, по исполнителям, по скорости и качеству выполнения работ; накопление статистики; получение отчетности для внутренних нужд и для передачи в вышестоящие организации и смежные службы.
Система обеспечивает следующие ключевые возможности для корпоративных информационных систем:
• высокая степень сохранности всех зарегистрированных в системе заявок. Исключается возможность потери заявки в случае ее корректного регистрации в системе;
• постоянный контроль за ходом визирования и исполнения поступивших заявок;
• детальный анализ эффективности работы сервисных подразделений по обеспечению бесперебойной работы всех служб организации;
• детальный анализ потребностей организации в материально-технических ресурсах инфраструктуры организации;
101
• высокая масштабируемость (по количеству и местоположению рабочих мест пользователей системы, объему хранимой в системе информации);
• высокая производительность системы (минимальное время реакции системы на действия пользователя);
• высокий уровень безопасности и управляемости информационными ресурсами;
• обеспечение обратной связи посредством оповещений по e-mail и «прозрачности» прохождения заявки для ее оформителя;
• возможность дальнейшего развития сервисов и автоматизации бизнес-процессов компании на единой платформе.
Внедрение системы сопутствующего документооборота обеспечивает высокую степень защиты хранимой информации, непрерывный контроль за ходом выполнения заявок на оказание услуг, оперативность при анализе хранимой информации и подготовке отчетных и справочных выходных документов, возможность проведения детального анализа эффективности существующей инфраструктуры и деятельности подразделений.
Существуют множество технологий, помогающих в работе службы поддержки, у каждой есть свои достоинства и недостатки. Важно убедиться, что сочетание технологий, процессов и персонала будет соответствовать нуждам клиентов и бизнеса. Технологии нужны для поддержки бизнес-процессов и должны использоваться для дополнения и расширения услуг, но не их подмены.
В результате проделанной работы была разработана система обработки заявок для использования работниками компании, которая проходит промышленное тестирование на базе ОАО «Томскнефтепродукт» ВНК. В дальнейшем необходимо интегрировать систему в набор существующих внутренних сервисов компании. Помимо рассмотренной в статье
102
системы обработки заявок, система включает в себя модуль по работе с внутренними документами, модуль аналитического исследования и другие.
Литература
1. Technical support for the neighbours [Электронный ресурс] // BBC NEWS UK Magazine. Дата обновления: 28.05.2005. URL: http://news.bbc.co.uk/2/hi/uk news/magazine/4387525.stm (дата обращения: 23.02.2010)
2. Service Desk Objectives in ITIL Foundation [Электронный ресурс] // ITIL Portal: The only future for managing IT Services is ITIL. Дата обновления: 01.07.2008. URL: http://www.itilfoundation.org/Service-Desk-Obiectives-in-ITIL-Foundation 43.html (дата обращения 01.03.2010)
3. Gerard Blokdijk, Ivanka Menken. Help Desk, Service Desk Best Practice Handbook: Building, Running and Managing Effective Support — Ready to use supporting documents bringing ITIL Theory into Practice. Emereo Pty Ltd, 2008. 124 с.
4. Ю. В. Кривошеенко. Корпоративные информационные системы. Компания Спутник +, 2008. 106 с.
5. Larry Klosterboer. Implementing ITIL Configuration Management. IBM Press, 2008. 264 с.
УДК 004.053
ОСНОВНЫЕ РАЗНОВИДНОСТИ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ И ИХ
ПРИМЕНЕНИЕ
Градиль Максим Дмитриевич, студент, Пятигорский филиал Российского Государственного Торгово-Экономического Университета, Россия, Пятигорск, lvlax@rambler.ru Ганенок Александр Григорьевич, студент, Пятигорский филиал Российского Государственного Торгово-Экономического Университета, Россия, Пятигорск, greg7515@yandex.ru
Проектирование объектно-ориентированных программ не легкое дело. А если их нужно использовать повторно, то все становится еще сложнее. Необходимо подобрать подходящие объекты, отнести их к различным классам, соблюдая разумность их детализации, определить интерфейсы классов, иерархию наследования и установить существенные отношения между классами. Дизайн с одной стороны должен соответствовать решаемой задаче, а с другой быть общим. Чтобы удалось учесть все требования, которые могут возникнуть в будущем.
Опытному разработчику понятно, что не нужно решать каждую новую задачу с нуля. Вместо этого он старается повторно воспользоваться теми решениями, которые оказались удачными в прошлом. Отыскав хорошее решение один раз, он будет прибегать к нему снова и снова. Именно благодаря накопленному опыту проектировщик и становится экспертом в своей области. Во многих объектно-ориентированных системах вы встретите повторяющиеся паттерны, состоящие из классов и взаимодействующих объектов. С их помощью решаются конкретные задачи проектирования. В результате чего объектноориентированный дизайн становится более гибким, элегантным и им можно воспользоваться повторно. Проектировщик знакомый с паттернами может сразу же применять их к решению новой задачи, не пытаясь, каждый раз изобретать велосипед.
Паттерны проектирования упрощают повторное использование удачных проектных и архитектурных решений. Представление прошедших проверку временем методик, в виде паттерного проектирования, облегчает доступ к ним со стороны разработчиков новых систем. С помощью паттернов можно улучшить качество документации и сопровождение соответствующих систем, позволяя явно описать взаимодействие классов и объектов, а так же причины по которым система была построена так, а не иначе. Проще говоря, паттерное проектирование дает разработчику возможности быстрее найти правильный путь.
Существует 3 основных категории паттернов:
1. Порождающие;
103
