Комплексная автоматизированная система управления командировками

Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 1. Анализ предметной области и постановка задачи

1.1 Обзор аналогичных систем

1.2 Описание структуры предприятия.

1.3 Анализ бизнес-процессов

1.4 Выделение и описание функций системы

1.5 Выделение классов данных

2. Проектирование

2.1 Выбор архитектуры системы

2.2 Средства реализации

2.2.1 Части системы

2.2.2 Средства реализации уровня баз данных

2.2.3 Средства реализации уровня доступа к данным

2.2.4 Средства моделирования рабочих процессов

2.2.5 Средства реализации пользовательского интерфейса

• 3. Реализация
• 3.1 Описание реализации физической модели данных
• 3.2 Разработка интерфейса пользователя
• 3.2.1 Слой интерфейса
• 3.2.2 MasterPage
• 3.2.3 Блочная верстка и CSS
• 3.2.4 Используемые серверные элементы управления
• 3.2.5 Класс HtmlGenerator
• 3.3 Описание реализации модулей, процедур, функций, запросов, алгоритмов.
• 3.3.1 Кэширование данных
• 3.3.2 Workflow foundation
• 3.3.3 Интеграция с 1С:Бухгалтерия
• 3.3.4 Автоматизированное создание документа для заказа билетов
• 3.3.5 Уровень доступа к данным
• 3.3.6 HttpHandler
• 4. Внедрение и сопровождение
• 4.1 Требования к техническим средствам (конфигурация).
• 4.1.1 Требования к конфигурации клиентской машины
• 4.1.2 Требования к конфигурации сервера баз данных
• 4.1.3 Требования к конфигурации серверной части
• 4.2 Установка и администрирование системы
• 4.2.1 Установка базы данных
• 4.2.2 Установка веб-приложения
• 4.3 Руководство пользователя
• 4.3.1 Подача заявки на командировку
• 4.3.2 Руководство по согласованию заявок
• 4.3.3 Страница "Мои заявки"
• 5. Расчет экономической эффективности проекта
• 5.1 Экономические предпосылки к созданию системы
• 5.2 Расчет затрат на разработку программного продукта
• 5.3 Расчет эксплуатационных расходов до внедрения программного продукта
• 5.4 Расчет эксплуатационных расходов после внедрения программного продукта
• 5.5 Анализ эффекта от внедрения системы
• 6. Вопросы охраны труда и техники безопасности
• 6.1 Анализ опасных и вредных факторов
• 6.2 Опасные и вредные факторы при работе с ПК
• 6.3 Последствия влияния ОПФ и ВПФ на здоровье человека
• 6.4 Меры защиты от ОПФ и ВПФ
• Заключение

Введение

Командировочные расходы занимают вторую по величине долю в затратах большинства компаний, и аналитики прогнозируют рост этих расходов. ОАО «Гипровостокнефть» не исключение, а значит требуется комплексное решение, которое позволит сократить командировочные расходы, давая сотрудникам простой инструмент для управления деловыми поездками, одновременно позволяющий экономить и деньги и время.

Оформление командировки в ОАО «Гипровостокнефть» - сложный процесс, состоящий из нескольких этапов и объединяющий в себе работу сотрудников нескольких отделов. В соответствии с существующей процедурой, сотрудник должен составить ряд заявок, согласовать их у ответственных за эти заявки работников и передать их на выполнение. Все это отрывает сотрудника от работы, отнимая у него время и понижая эффективность производства. Руководством ОАО «Гипровостокнефть» было принято решение о необходимости создания системы автоматизированного оформления командировок с целью ускорения этого процесса, упрощения его для сотрудников и лиц, ответственных за согласование и выполнение заявок по командировкам, а так же для упрощения получения отчетов и статистических данных по прошедшим командировкам.

Основные задачи, которые должны быть решены в дипломном проекте:

автоматизированное создание заявки на командировку;

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

автоматическое управление ходом заявки по этапам согласования/выполнения

контроль состояния согласования/выполнения заявки

Отдельные этапы процесса оформления командировки так же должны быть по возможности автоматизированы. Система должна легко модифицироваться для добавления новых возможностей и углубления автоматизации. автоматизация программирование модель конфигурация

Автоматизация документооборота в ОАО "Гипровостокнефть" строится на базе корпоративного веб-портала, разрабатываемого работниками отдела Информационных Технологий с 2002 года. Портал объединяет новостные, информационные ресурсы, каталог бланков для различных заявлений, различные статьи. Решение задач автоматизации документооборота осуществляется путем добавления в портал новых частей, к которым можно перейти через ссылки в меню портала. В портал встроены система обмена заданиями для взаимодействия смежников и организации их совместной работы над проектами, система оповещения, через которую пользователь оповещается о поступивших к нему на выполнение заданиях и о договорах, которые требуется согласовать. Для упорядочивания проектной документации и контроля за состоянием выполнения проектов используется специально разработанный реестр. Портал работает с базой данных персонала, предоставляю сотрудникам ОАО «Гипровостокнефть» позволяет по имени сотрудника быстро найти его контактные данные.

С технической точки зрения, интранет-портал ОАО «Гипровостокнефть» проедставляет собой хорошо организованное, легко поддерживаемое и масштабируемое веб-приложение, на базе которого достаточно удобно организовывать автоматизацию документооборота. Интранет-портал работает на современном серверном оборудовании, программное и аппаратное обеспечение которого регулярно обновляется. С целью повышения производительности и надежности системы, портал был создан с использованием распределенной архитектуры, с отдельным физическим сервером баз данных и отдельным сервером веб-сервисов. Веб-сервисы находят активное применение, как инструмент интеграции внешних систем в единое информационное пространство.

1. Анализ предметной области и постановка задачи

1.1 Обзор аналогичных систем

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

Самой подходящей под мои задачи системой, представляется система SAP Travel Management, построенная на базе программного продукта SAP R/3. Эта система решает следующие задачи:

Формирование командировки.

Автоматическое заполнение работника, его должности, его подразделения;

Автоматический подсчет количества дней в командировке;

Автоматическое заполнение дат этапа командировки.

Формирование и согласование приказа на командировку. Автоматическое формирование приказа на командировку в соответствии с заполненными параметрами командировки, с возможностью создания числом ранее текущего. Использование возможностей Workflow и типового маршрута позволяет ускорить согласование приказа с руководителем отдела кадров, бухгалтером, генеральным директором и другими ответственными лицами.

Формирование командировочного удостоверения. Автоматическое формирование командировочного удостоверения в соответствии с заполненными параметрами командировки.

Формирование служебного задания. Автоматическое формирование служебного задания в соответствии с заполненными параметрами командировки.

Поиск командировки и связанных с ней документов.

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

С точки зрения программной разработки, SAP R/3 представляет собой трехуровневую клиент-серверную архитектуру:

Рисунок 1 - Архитектура системы SAP R/3

Приложения для SAP R/3 написанные на языке программирования ABAP, выполняются на уровне приложений (Application layer).

ABAP программы соединяются с системой управления центральной реляционной БД (RDBMS - Relational DataBase Management System) на уровне БД (Database layer), и с графическим пользовательским интерфейсом (SAP GUI) на презентационном уровне (Presentation layer).

SAP R/3 - качественный продукт, уважаемый в мире и используемый многими предприятиями. Очевидными плюсами являются:

Достаточный и избыточный функционал

Надежность

Быстродействие

Но есть важные недостатки, не дающие использовать это решение в ОАО «Гипровостокнефть»:

SAP R/3 - мощнейшая система управления предприятием, она решает множество задач автоматизации документооборота и управления предприятием, использовать SAP R/3 для оформления командировок целесообразно только в том случае, если эта система уже приобретена и внедрена на предприятие, в противном случае затраты на такую систему будут огромны.

Стоимость. По примерным подсчетам, выполненным с помощью предложенного компанией SAP калькулятора, покупка серверной и клиентской частей SAP для предприятия ОАО «Гипровостокнефть» обойдется в 10-15 млн. рублей, что очень много, а использование такой мощной и дорогой системы только для автоматизации процесса оформления командировок абсолютно нецелесообразно.

Простой отечественный аналог SAP R/3 - «1С:Предпиятие». Он уже используется в ОАО «Гипровостокнефть» для управления бухгалтерией.

Технологическая платформа «1С:Предприятие» представляет собой программную оболочку над базой данных (используются базы на основе DBF-файлов в 7.7, собственный формат 1CD в версии 8.0 и 8.1 или СУБД Microsoft SQL Server на любой из этих версий). Кроме того, с версии 8.1 хранение данных возможно в СУБД PostgreSQL, а также DB2 и Oracle (начиная с версии 8.2). Имеет свой внутренний язык программирования, обеспечивающий помимо доступа к данным возможность взаимодействия с другими программами посредством OLE и DDE, в версиях 7.7, 8.0 и 8.1 -- с помощью COM-соединения.

Клиентская часть платформы функционирует только в среде ОС Microsoft Windows (существует также возможность запуска системы программ «1С:Предприятие» на Unix-подобных операционных системах с помощью WINE@Etersoft). Серверная часть при использовании PostgreSQL или DB2 может функционировать на операционной системе Unix.

Существуют специальные версии среды исполнения 1С для ноутбуков и PDA, ПО создания веб-приложений, взаимодействующих с базой данных «1С:Предприятие».

В части (конфигурации) "1С:Зарплата и Управлении Персоналом" есть механизм учета командировок. Он уже используется в ОАО «Гипровостокнефть», поэтому его потребуется интегрировать в разрабатываемую комплексную автоматическую систему оформления командировок.

Еще один инструмент для автоматизации документооборота предприятия и, в частности, автоматизации процесса оформления командировок - система «directum» одноименной компании.

Система DIRECTUM, построенная с помощью предметно-ориентированного инструмента IS-Builder, имеет многоуровневую архитектуру. Архитектура выступает гарантом доступности, надежности и безопасности системы, что позволяет системе DIRECTUM охватить всех компьютеризованных сотрудников и повысить эффективность работы организации в целом.

Рисунок 2 - Архитектура системы DIRECTUM

Основными функциональными элементами архитектуры являются:

СУБД - хранилище данных и метаданных системы. Одним из важных компонентов системы, хранящихся в СУБД, является прикладная разработка DIRECTUM, которая определяет функциональность предметных модулей системы, заказных, а также разработанных партнерами DIRECTUM решений.

Управляющие службы DIRECTUM - службы, обеспечивающие управление системой. Например, служба workflow управляет работой задач DIRECTUM, а DIRECTUM Storage Services отвечает за файловые хранилища документов. Все управляющие службы могут быть установлены как на один компьютер, так и на различные - в целях распределения нагрузки.

IS-Builder Runtime Environment - среда исполнения кода, реализующая интерфейс служб и пользовательских приложений (в том числе сторонней разработки) для доступа к системе. В частности, сервер веб-доступа DIRECTUM, реализованный на платформе ASP.NET, использует IS-Builder Runtime Environment для реализации всех функций системы, которые становятся доступны пользователям через веб-браузер.

Клиенты системы DIRECTUM - приложения для конечных пользователей, инструментарий разработки, утилиты администрирования системы. Клиентом может быть как Windows-приложение, использующее для доступа к системе IS-Builder Runtime Environment, так и веб-браузер.

Файловые хранилища - архивы больших или редко используемых документов, которые эффективнее держать за пределами СУБД; управляются собственными службами.

Стоимость системы Directum меньше, чем у системы SAP. Исходя из информации на сайте, максимальный пакет лицензий продукта Directum, состоящий из 200 лицензий, стоит 1,5 млн. рублей. Учитывая, что ОАО «Гипровостокнефть» имеет более 800 сотрудников, потребуется около четырех таких пакетов, что составляет около 6 млн. рублей. Приобретать и внедрять такую систему для оформления командировок сложно и дорого и нецелесообразно.

Анализ систем SAP R/3 и DIRECTUM показал, что они дороги и имеют избыточный функционал. Система 1С:Предприятие уже используется в ОАО «Гипровостокнефть», но полная реализация всей системы на его базе не подходит по двум причинам:

Отсутствие удобного и прозрачного инструмента для автоматизации рабочих процессов

Нарушение цельности существующей в ОАО «Гипровостокнефть» системы автоматизации документооборота, реализованной на платформе ASP.net.

Требуется создать модуль, который будет объединять удобный веб-интерфейс, автоматизированное управление рабочими процессами и интеграцию с 1С.

1.2 Описание структуры предприятия

ОАО «Гипровостокнефть» представляет собой мощную комплексную научно-исследовательскую и проектно-изыскательскую организацию, способную решать задачи любой сложности по обеспечению технической документацией инвестиционных программ нефтяных компаний в области нефтедобывающей промышленности. Основными направлениями деятельности предприятия являются перспективное проектирование, проектирование разработки и подсчет запасов углеводородов нефтяных и нефтегазовых месторождений, составление проектов комплексного обустройства месторождений и проектов строительства и реконструкции объектов и сооружений нефтегазодобывающей промышленности и др.

В институте организовано единое информационное пространство на базе корпоративного Web-сайта, в рамках которого осуществляется проектный документооборот, совместная работа проектировщиков над проектами, доступ к справочным и сервисным ресурсам предприятия, обмен заданиями и совместная работа над ними. Функционал корпоративного портала постоянно расширяется с целью создания единой среды для работы сотрудников предприятия. Данный портал создан с использованием технологии ASP.NET с помощью среды программирования Microsoft Visual Studio 2008. Для хранения данных используется СУБД Microsoft SQL Server 2005.

В ОАО «Гипровостокнефть» используется современное серверное оборудование, имеется несколько физических и виртуальных сереверов. Отдельный сервер отвечает за работу веб-портала, на отдельном развернуты базы данных, на отдельном - веб-сервисы.

Для организации работы сотрудников в качестве системного программного обеспечения используются решения на базе платформы Microsoft. На рабочих местах пользователей установлены операционные системы Microsoft Windows XP Professional Listed Upgrade/Software Assurance Pack Open, Microsoft Windows 2000 Professional, Microsoft Windows XP Professional x64 Ed, на серверах Microsoft Windows 2000 Server (дистрибутив и лицензия). В качестве программного обеспечения используется Microsoft Office 2007.

Географически, институт расположен в двух корпусах, находящихся в разных частях города. Корпуса связаны между собой оптоволоконной магистралью, кроме того, на случай поломки оптоволоконной магистрали существует резервный канал - VPN соединение через интернет. Кроме того, сотрудникам ОАО «Гипровостокнефть», направляемым в командировку или в случае необходимости работы из дома, так же предоставляется удаленной доступ к сети института через VPN канал.

Исходя из особенностей организации информационной инфраструктуры ОАО «Гипровостокнефть», проектируемая система должна иметь 3-х звенную архитектуру.

1.3 Анализ бизнес-процессов

Процесс оформления командировки начинается с выяснения необходимости предварительного согласования с генеральным директором. Если такая необходимость есть,то далее следует оформление докладной на имя генерального директора. Если такой необходимости нет, то можно начинать оформление командировки в автоматизированной системе.

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

Если заявка прошла первый этап согласованиея, согласование у непосредственных руководителей, то формируются заявки на тезнические средства, фотоаппарат, если они нужны, билеты и бронирование гостиницы, визу, заявка на оформление документов, заявка на выплату аванса и заявка на транспортировку сотрудников.

Согласованием заявки на технические средства занимается заместитель генерального директора по ИТ. В перечень согласуемых технических средств входят ноутбук, с необходимым в командировке ПО, сим карта, возможно, с доступом в интернет, с использованием технологий GPRS/3G, и прочие технические средства. Если заявка на технические средства была согласована, формируются задания на подготовку и выдачу указанных в заявке технических средств: формируется задание для группы технической поддержки на подготовку ноутбука с указанным программным обеспечением и задание для сотрудника, занимающегося выдачей и учетом корпоративных сим-карт на выдачу сим-карты сотруднику, направляемому в командировку.

Когда задания по подготовке технических средств выполнены, сотрудники отдела делопроизводства оповещаются о том, что следует забрать эти технические средства, а автор заявки оповещается о том, что запрашиваемое им оборудование можно получить у сотрудников отдела делопроизводства.

Заявка на фотоаппарат согласуется у начальника ОПОВС, если заявка согласована, для фотографа ОАО «Гипровостокнефть» формируется задание на подготовку фотоаппарата.

Заявка на заказ билетов, бронирование гостиницы и оформление визы обрабатывается одним человеком, но фактически является тремя независимыми заявками, потому что каждая из них имеет свои исходные данные и свой результат выполнения. Заявка на заказ билетов обрабатывается протокольной группой ОПОВС, выполняется проверка валидности исходных данных и возможность выполнения заявки, то есть осуществимо ли приобретения билетов, с учетом указанных сроков командировки. Если заказ билетов через обычные для ОАО «Гипровостокнефть» пути,с учетом указанных сроков командировки, невыполним, то ответственность за заказ билетов переносится на автора заявки и расходы на денежные расходы на билеты включаются в заявку в бухгалтерию. Если же заявка признана выполнимой, то, по стандартной процедуре ОАО «Гипровостокнефть», производится заказ электронных билетов, полученные билеты передаются в отдел делопроизводства и автор заявки оповещается о том, что он может забрать от туда готовые билеты.

Заявка на бронирование гостиницы формируется и обрабатывется теми же путями. В случае невыполнимости заявки обычным путем, либо если сотрудниксам пожелал организовать свое проживание, расходы на проживание так же включаются в заявку в бухгалтерию. Аналогично обрабатывается и заявка на оформление визы.

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

Заявка на оформление документов обрабатывается сотрудником отдела кадров. Выполняется проверка, возможна ли командировка в указаные сроки и валидность исходных данных. Если все в порядке и заявка выполнима, сотрудник отдела кадров согласует ее и приступает к выполнению. Если же заявка не выполнима, она отклоняется и возвращается автору для корректировки и последующего пересогласования. Когда сотрудник отеда кадров заканичивает оформление документов по командировке, идет оповещение группы делопроизводство о необходимости собрать подпиписи на документах, когда документы готовы, автор заявки оповещается о том, что может забрать готовые документы из группы делопроизводства.

Когда документы оформлены, формируется заявка на выплату аванса, котора я обрабатывается бухгалтерией. Бухгалтерия согласует заявку, выполняет расчет суточных, если необходимо, включает в аванс расходы на проживание и билеты. Далее выполняется перечисление денежных средств на зарплатную карту сотрудника и оповещение сотрудника о переводе денежных средств.

Обработкой заявки на транспортировку сотрудников до вокзала или аэропорта занимается заместитель генерального директора по общим вопросам. В заявку на транспортировку сотрудников включены результаты заказа быилетов, сроки командировки. За день до выезда в командировку, заместитель генерального директора по общим вопросам оповещается о то, что надо выделить водителя для сопровождения командируемых сотрудников до точки отбытия За день до возвращения сотрудников, происходит оповещение заместителя генерального директора по общим вопросам о том, что надо выделить водителя для встречи сотрудников из точки прибытия(вокзал, аэропорт). Детали транспортировки могут быть обсуждены между автором заявки и заместителем генерального директора по общим вопросам непосредственно.

После обработки всех заявок, касательно командировки, автор заявки оповещается о результатах согласования и может либо забрать оборудование и документы, относящиеся к командировке, из отдела делопроизводства, в случае, если все заявки были успешно согласованы, либо отредактировать заявку и отправить ее на пересогласование, если в указанных им исходных данных по командировке были какие-то ошибки.

1.4 Выделение и описание функций системы

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

После ввода данных по командировке, в первую очередь, формируется заявка на предварительное согласование. Чтобы сформировать задание, нужна соответствующая функция. Далее, задание должно быть выполнено. Если это задание по согласованию, то требуются функции согласования и отклонения заявки. Если это задание на выполнение, например, подготовка ноутбука, то требуется функция подтверждения выполнения задания.

После этапа предварительного согласования, формируются задачи согласования оборудования, заказа билетов и бронирования гостиниц, оформления документов. Все эти задачи формируются предложенной ранее функцией создания заявки.

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

По результатам предварительного анализа, требуются следующие основные функции слоя бизнес-логики:

Ввод данных по командировке

Вход: исходные данные о заявке
Выход: идентификатор созданной командировки

получения списка командировок

Вход: -
Выход: список командировок(идентификаторов заявок)

просмотра состояния командировки

Вход: идентификатор заявки
Выход: объект заявки

формирование задания

Вход: тип задания, идентификатор заявки, к которой относится задание
Выход: идентификатор задания

согласование заявки

Вход: идентификатор задания
Выход: -

отклонение заявки

Вход: идентификатор задания
Выход: -

подтверждение выполнения заявки

Вход: идентификатор задания
Выход: -

опровержение выполнения заявки

Вход: идентификатор задания
Выход: -

завершение согласования

Вход: идентификатор заявки на оформление командировки
Выход: -

оповещение пользователя
Вход: идентификатор пользователя, текст оповещения
Выход: -

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

Создание командировки

Создание задачи/задания по командировке

Получение списка командировок

Получение списка задач по командировке

Получение информации по задаче по командировке

Согласование/отклонение заявки по командировке

Кроме того, уже обработанные заявки надо убирать из списка активных. Это можно осуществить двумя способами: удаление записи из базы данных или пометка записи, как архивной. Физическое удаление из базы данных имеет то приемущество, что база данных не растет в объеме, но этот способ не приветствуется, так как такое решение не дает возможности ведения статистики, к тому же, в случае с командировками, речь идет о важных данных, связанных с финансовыми и временными расходами, что так же делает удаление таких данных нежелательным, поэтому был выбран путь архивации объектов. Для этого требуются еще две функции в слое доступа к данным:

архивация заявки

архивация командировки

Примерные расчеты показывают, что для полной обработки одной заявки по командировке потребуется от 5кб до 2мб дискового пространства, в зависимости от того, будет ли приложенная к командировке докладная на имя генерального директора. В перспективе, возможно, потребуется добавление возможности автоматического перемещения устаревшей архивной информации в архивную базу данных, либо ее экспорт на оптические диски.

1.5 Выделение классов данных

Логично, что центральной сущностью системы оформления командировок, должна являться командировка. Командировка это абстрактная сущность, которая объединяет вокруг себя данные о командировке и заявки, с ней связанные. Исходные данные командировки делятся на пять частей, каждая из которых согласуется отдельной заявкой: часть оформления документов, часть оборудования, часть расходов, часть транспортировки сотрудника до аэропорта или вокзала и часть заказа билетов и бронирования гостиниц, эти пять сущностей связаны с командировкой связями один ко многим(для хранения истории предыдущих заявок при пересогласовании).

Часть оформления документов содержит данные, которые требуются отделу кадров: автор заявки, цель командировки, ее тип, страна, город и организация, куда направляется командировка, а так же список сотрудников, направляемых в эту командировку.

Сотрудник, направляемый в командировку - следующая сущность, связан с частью оформления документов связью один ко многим. Сотрудник характеризуется табельным номером, ФИО, целью командировки и сроками пребывания в ней. Другие сведения о сотруднике буду получаться из базы данных персонала в 1С.

Кроме того, часть оформления документов должна содержать тип командировки по классификатору, один из вариантов:

Авторский надзор

Доставка документации

Доставка сотрудников

Повышение квалификации

Решение вопросов по объекту

Сбор данных на месторождении

Сдача проектов на госэкспертизу

Согласование работ

Участие в семинаре

Участие в совещании

Участие в тендере

Эти пункты следует выделить в отдельную таблицу.

Часть оборудования содержит информацию о том, какие технические средства потребуются сотруднику во время командировки и описание этих средств. Это четыре поля двоичного типа: нужен ли ноутбук, телефон, фотоаппарат и прочее аппаратное обеспечение, а так же текстовое поле, содержащее описание для каждого из этих пунктов.

Часть расходов представляется в виде записи о единичном расходе. Она содержит сведения о том, сколько денег требуется выделить и на какие нужды. По одной командировке может быть много расходов, расходы относятся к конкретной командировке, связь один ко многим. Для хранения данных с предыдущих итераций согласования при пересогласовании, будет использоваться механизм ревизий.

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

Следующая сущность базы данных - заявка, к одной командировке относится множество заявок. Атрибуты заявки - автор, исполнитель, тип и состояние, а так же дата начала.

Тип и состояние заявки - так же сущности базы данных командировок. Состояние заявки (“Выполнена”, “В работе”, “Согласована”,”Отклонена”) так же относится и к командировке в целом. Сущность “Состояние” относится к командировке и заявке как один ко многим.

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

Протокол различных событий и ошибок так же целесообразно вести в базе данных, учитывая что доступ к файловой системе сервера имеет узкий круг лиц, поэтому протокол в файле не удобен. Кроме того к протоколу в базе можно делать запросы, выбирая, например, только сообщения об ошибках, ошибки, возникшие в заданный интервал времени и разные другие удобные запросы.

2. Проектирование

2.1 Выбор архитектуры системы

Разрабатываемая система может иметь различную архитектуру, но учитывая специфику программно-аппаратного обеспечения серверного оборудования ОАО «Гипровостокнефть», было принято решение использовать трехзвенную архитектуру. Распределение решаемой задачи между тремя серверами позволяет снизить нагрузку на каждый из них, а значит повысить надежность системы, а технология «тонкого» клиента снижает требованию к машине-терминалу до минимума, позволяя пользоваться системой с самых маломощных ПК и даже мобильных телефонов.

Система будет иметь современную архитектуру, аналогичную той, которая используется в системе SAP R/3. Правильно написанное приложение, работающее с базами данных должно содержать следующие уровни абстракции:

Уровень базы данных. Это нижний уровень данных, представляющий собой таблицы, связи между ними и представления

Уровень доступа к данным(DAL, Data Access Layer). Уровень, представления данных, хранящихся в базе дынных в виде объектов объектной модели приложения, позволяет при создании бизнес-логики приложения абстрагироваться от технических тонкостей хранения информации в базе данных и оперировать простыми объектами, а не таблицами и связями. В случае с автоматизированной системой оформления командировок, объектами, например, будут являться командировка, заявка, сотрудник

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

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

2.2 Средства реализации

2.2.1 Части системы

Как на клиентских, так и на серверных машинах ОАО «Гипровостокнефть» установлены операционные системы семейства Windows. На серверах - Microsoft Windows Server 2003(идет переход на Microsoft Windows Server 2008 R2. На клиентских - Microsoft Windows XP Professional, новые машины оснащаются операционной системой Microsoft Windows 7. В техническом задании оговорено, что система должна работать на действующих в организации операционных системах.

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

Уровень базы данных. Это нижний уровень данных, представляющий собой таблицы, связи между ними и представления

Уровень доступа к данным(DAL, Data Access Layer). Уровень, представления данных, хранящихся в базе дынных в виде объектов объектной модели приложения, позволяет при создании бизнес-логики приложения абстрагироваться от технических тонкостей хранения информации в базе данных и оперировать простыми объектами, а не таблицами и связями. В случае с автоматизированной системой оформления командировок, объектами, например, будут являться командировка, заявка, сотрудник

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

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

Существуют различные варианты разработки каждого из этих уровней приложения.

2.2.2 Средства реализации уровня баз данных

Уровень базы данных может представлять собой совершенно любое хранилище данных: единственный файл, структура фалов и папок, реляционная база данных. Конкретное решение выбирается исходя из количества и рода данных, которыми оперирует система. Для небольших объемов данных вполне подойдет и файл: за ним легко следить, легко делать его резервную копию. Структура из файлов и папок подойдет для системы, в которой хранится много мультимедийного содержимого(фото, видео), так как база данных плохо подходит для хранения бинарных данных. В Комплексной автоматизированной системе оформления командировок оперировать придется большими количеством текстовых данных, надо будет производить операции выборки, много пользователей будут одновременно производить запись и чтение данных из базы. Для такой системы лучше всего подойдет реляционная база данных. В ОАО «Гипровостокнефть» использовались разные СУБД, но сейчас стандартом является MS SQL Server, эта СУБД установлена на серверах, поэтому в дипломном проекте будет использована именно она. Для создания базы данных удобно использовать утилиту SQL Server Management Studio, входящую в состав MS SQL Server 2005.

2.2.3 Средства реализации уровня доступа к данным

Уровень доступа к данным(DAL) это важное звено, от его качества зависит стабильность системы, скорость работы и разработки, удобство поддержки. Традиционно в ASP.net для доступа к данным использовалась модель ADO.net, проектирование слоя данных при таком подходе было малоэффективным процессом: приходилось вручную создавать классы для каждой сущности базы данных и классы для манипуляций этими данными, вручную воссоздавать отношения между сущностями. В .net Framework 3.5 появилась новая модель доступа к данным: LINQ To SQL, она автоматически генерирует для сущностей базы данных объекты бизнес-логики и минимальный набор методов для управления этими объектами: добавление, удаление и т.п. Для реализации остальных, специфических для системы методов, потребуется дополнительный класс управления данными.

2.2.4 Средства моделирования рабочих процессов

Процесс оформления командировки - типичный рабочий-процесс, который можно представить в виде блок-схемы. Как раз для моделирования таких процессов отлично подходит технология Windows Workflow Foundation (WF). Windows Workflow Foundation (WF)представляет собой технологию компании Microsoft для определения, выполнения и управления рабочими процессами (англ. workflow). Данная технология входит в состав .NET Framework 3.0, который изначально установлен в Windows Vista и может быть установлен в Windows 2003 Server и Windows XP SP2. WF поддерживается в Visual Studio 2005 в виде расширения (add-on), в состав которого входит визуальный дизайнер процессов и визуальный отладчик, позволяющий отладить созданный процесс. В Visual Studio 2008 эта функциональность входит изначально.

WF ориентирована на визуальное программирование и использует декларативную модель программирования. WF позволяет быстро и наглядно проектировать рабочие процессы в виде блок-схем, а главное обеспечивает легкость модификации этих процессов, их доработки и перекомпоновки.

2.2.5 Средства реализации пользовательского интерфейса

Система будет расширять существующий интерфейс портала ОАО «Гипровостокнефть», а следовательно унаследует его средства реализации. Интерфейс будет реализован на базе технологии Microsoft ASP.net.

ASP.NET -- технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 4.0.

ASP.NET внешне во многом сохраняет схожесть с более старой технологией ASP, что позволяет разработчикам относительно легко перейти на ASP.NET. В то же время внутреннее устройство ASP.NET существенно отличается от ASP, поскольку она основана на платформе .NET и, следовательно, использует все новые возможности, предоставляемые этой платформой.

3. Реализация

3.1 Описание реализации физической модели данных

Воплощение принятых в ходе анализа задачи решений начинается с разработки базы данных. База данных разрабатывается для СУБД Microsoft SQL Server 2005, с помощью утилиты Microsoft SQL Management Studio.

Необходимы для работы системы сущности были описаны следующими таблицами:

Comments - таблица, содержащая комментарии, относящиеся к командировкам.

Таблица 3.1 - Атрибуты таблицы «Comments»

Название	Тип	Описание
ID	Int	Уникальный идентификатор комментария
ObjectID	Int	Идентификатор командировки, к котрой относится комментарий
AuthorID	Int	Идентификатор автора комментария
Title	Varchar(255)	Заголовок комментария, в общем случае, имя автора.
Date	DateTime	Дата добавления комментария
Text	Text	Текст комментария
TaskID	Int	Индентификатор заявки, к которой относится комментарий, если такая есть.

Documents - таблица, содержащая данные, необходимые для оформления документов, касающихся командировки.

Таблица 3.2 - Атрибуты таблицы «Documents»

Название	Тип	Описание
ID	Int	Идентификатор записи
Name	Int	Имя автора заявки
Project	Varchar(50)	Название проекта, которому относится командировка
DestinationCountry	Varchar(255)	Страна, в котрую командировка направляется
DestinationCity	Varchar(100)	Город, в который командировка направляется
Scan	Image	Отсканированная докладная
Department	Varchar(100)	Отдел автора командировки
DestinationCompany	Varchar(255)	Организация, в которую отправляется командировка
FileName	Varchar(100)	Имя файла отсканированной докалдной
CountryID	int	Идентификатор страны
GoalTypeID	int	Идентификатор цели командировки

FirstApprovers - служебная таблица, содержащая список участников предварительного согласования по конкретной командировке.

Таблица 3.3 - Атрибуты таблицы «FirstApprovers»

Название	Тип	Описание
ID	Int	Идентификатор записи
ApproverID	Int	Идентификатор согласующего
ObjectID	Int	Идентификатор командировки

GoalType - таблица-спецификатор, содержащая список типов командировки.

Таблица 3.4 - Атрибуты таблицы «GoalType»

Название	Тип	Описание
ID	Int	Идентификатор записи
Description	Varchar(50)	Расшифорвка

Groups - таблица, содержащая списки командируемых сотрудников.

Таблица 3.5 - Атрибуты таблицы «Groups»

Название	Тип	Описание
ID	Int	Идентификатор записи
PersonnelID	Int	Идентификатор сотрудника в базе данных персонала
UserNumber	Varchar(8)	Табельный номер сотрудника
DocumentID	Int	Идентификатор заявки на оформление документов, к которой относится список сотрудников
Name	Varchar(50)	Фамилия и инициалы сотрудника
StartTime	datetime	Дата начала командировки
EndTime	datetime	Дата окончания командировки
Description	Varchar(255)	Цели сотрудника, каксательно данной командировки
Allowance	Varchar(50)	Суточные, подсчитанные бухгалтерией

Log - служебная таблица, содержащая историю событий в системе, включая сообщения об ошибках и исключительных ситуациях.

Таблица 3.6 - Атрибуты таблицы «Log»

Название	Тип	Описание
ID	Int	Идентификатор записи
Date	Datetime	Время события
Description	Varchar(255)	Описание события: тип и сообщение

Objects - главная таблица, содержит список командировок, командировки являются основой объектной модели, практически все остальные сущности прямо или косвенно связаны с командировкой.

Таблица 3.7 - Атрибуты таблицы «Objects»

Название	Тип	Описание
ID	Int	Идентификатор записи
Comment	Varchar(255)	Технический комментарий
AuthorID	Int	Идентификатор автора заявки
StatusID	Int	Идентификатор состояния командировки
Archived	Bit	Флаг, означающий, что командировка отправлена в архив
StartDate	DateTime	Время создание заявки на оформление командировки
NotApprove	int	Список заявок, которые уже согласованы и в пересогласовании не нуждаются
LastUpdate	DateTime	Дата последних изменений, касающихся командировки

Roles - таблица, содержащая список ролей в системе. В ней перечислены все возможные согласующие и исполнители заданий.

Таблица 3.8 - Атрибуты таблицы «Roles»

Название	Тип	Описание
ID	Int	Идентификатор записи
Description	Varchar(50)	Расшифровка

Statuses - таблица, содержащая список возможных статусов заявок и командировок: «В работе», «Выполнена», «Согласована», «Отклонена» и другие.

Таблица 3.9 - Атрибуты таблицы «Statuses»

Название	Тип	Описание
ID	Int	Идентификатор записи
Description	Varchar(50)	Расшифровка

Subscribers - таблица, содержащая список подписчиков на комментарии по командировке. На форме обсуждения командировки есть возможность подписаться на новые комментарии в обсуждении. Если пользователь подписан, то когда в обсуждение будет добавляться комментарий, пользователь будет оповещаться об этом по средству системы оповещений.

Таблица 3.10 - Атрибуты таблицы «Subscribers»

Название	Тип	Описание
ID	Int	Идентификатор записи
PersonnelID	int	Идентификатор подписчика
ObjectID	int	Идентификатор командировки, к которой относится обсуждение.

Tasks - таблица, содержащая заявки и задачи по командировкам.

Таблица 3.11 - Атрибуты таблицы «Task»

Название	Тип	Описание
ID	Int	Идентификатор записи
AuthorID	Varchar(50)	Расшифровка
PersonnelID	Int
WorkflowID	GUID
ConversationID	GUID
ObjectID	Int
StatusID	Int
TypeID	Int
StartTime	Datetime
Comment	Varchar(255)
Archived	bit
IsTask	bit

Tech - таблица, содержащая данные о требующемся для командировки оборудовании.

Таблица 3.12 - Атрибуты таблицы «Tech»

Название	Тип	Описание
ID	Int	Идентификатор записи
ObjectID	int	Идентификатор командировки, к которой относится оборудование
Laptop	bit	Флаг, указывающий требуется ли ноутбук
LaptopDescription	text	Пожелания к ноутбуку
Sim	Bit	Флаг, указывающий требуется ли сим-карта
SimDescription	Text	Пожелания к сим-карте(например, оператор)
Gprs	Bit	Флаг, указывающий требуется ли услуга GPRS
Photo	Bit	Флаг, указывающий требуется ли фотоаппарат
PhotoDescription	text	Пожелания к фотоаппарату

TicketsAndHotelOrders - таблица, хранящая информацию о заказе билетов и бронировании номеров в гостинице для командировки.

Таблица 3.13 - Атрибуты таблицы «TicketsAndHotelOrders»

Название	Тип	Описание
ID	Int	Идентификатор записи
ObjectID	int	Идентификатор командировки
Tickets	bit	Флаг, указывающий требуются ли билеты
TicketsDescription	text	Пожелания к билетам
Visa	Bit	Флаг, указывающий требуется ли виза
VisaDescription	Text	Пожелания к визе
Hotel	Bit	Флаг, указывающий требуются ли номера в гостинице
HotelDescription	text	Пожелания к гостинице
TicketCash	Varchar(20)	Расходы на билеты, в случае самостоятельного заказа
HotelCash	Varchar(20)	Расходы на проживание, самостоятельного заказа
RtfReport	text	Текст документа для заказа билетов

Types - таблица-классификатор, содержащая возможные типы заявок

Таблица 3.14 - Атрибуты таблицы «Types»

Название	Тип	Описание
ID	Int	Идентификатор записи
Description	Varchar(50)	Расшифорвка

UsersInRoles - таблица, содержащая список согласующих пользователей системы и их роли.

Таблица 3.15 - Атрибуты таблицы «UsersInRoles»

Название	Тип	Описание
ID	Int	Идентификатор записи
UserID	Int	Идентификатор пользователя в базе данных персонала ОАО «Гипровостокнефть»
RoleID	Int	Идентификатор роли пользователя в системе
Description	Varchar(50)	Комментарий к записи
Priority	int	Текущий приоритет пользователя

3.2 Разработка интерфейса пользователя

3.2.1 Слой интерфейса

Слой интерфейса пользователя разрабатываемой системы представляет собой набор веб-страниц, интегрированных в интранет-портал ОАО «Гипровостокнефть». Это избавляет пользователей от необходимы скачивания, установки и освоения клиентской части, так как по сути клиентской частью является браузер, а с ним клиент работать умеет. Портал написан на платформе ASP.net, с широким применением его возможностей. С другой стороны, благодаря архитектуре системы, в перспективе можно создать интерфейс в виде windows-приложения, причем web-интерфейс будет оставаться в силе, так как слой интерфейса независим от слоя бизнес-логики и слоя база данных.

3.2.2 MasterPage

Для гармоничного включения части оформления командировок в общую автоматизированную систему документооборота, она должна соответствовать стандартам дизайна и кодирования, принятым в ОАО «Гипровостокнефть». Целостность дизайна сохраняется благодаря двум техническим приемам, использованным при верстке страниц разрабатываемой системы: использование каскадных таблиц стилей(CSS) и использование предлагаемой платформой ASP.net технологии MasterPage.

Технология MasterPage, широко используемая в портале ОАО «Гипровостонефть», предполагает, что у всех страниц портала есть общая часть. В случае с порталом ОАО «Гипровостокнефть», это видимые пользователю шапка и меню и невидимые метаданные, секции описания общих файлов JavaScript и CSS. Эти общие данные выносятся в отдельный файл, который имеет определенную структуру и разрешение “.master”. По структуре этот файл представляет собой обычную Asp.net страницу и отличается только наличием тегов ContentPlaceHolder. Страницы, которые будут разделять общий MasterPage, тоже должны иметь специальную структуру. Так как обычные для html страницы элементы, такие как “<head>…</head>” и ”<body …>”, уже описаны в MasterPage, их не нужно описывать еще раз. Вместо этого, страница представляет собой набор “содержимых”, заключенных в тэгах “<content>”. В атрибутах этих тэгов задается, в какой ContentPlaceHolder будет вставлено содержимое описываемого Content, а в шапки Content-страницы указывается, какой MasterPage-файл она использует.

Рисунок 3 - Схема работы ASP.net MasterPage

Все страницы портала ОАО «Гипровостокнефть», кроме страниц диалогов, представляют собой Content-страницы, использующий один общий MasterPage, а значит и общие каскадные таблицы стилей, что помогает сохранить целостность дизайна и вести одновременное автоматическое обновление дизайна всех страниц, если эти таблицы были изменены.

3.2.3 Блочная верстка и CSS

Разработчики ОАО «Гипровостокнефть» придерживаются современных стандартов верстки и кодирования, поэтому для разметки веб-страниц портала применяется блочная верстка. В разрабатываемой мной системе, я также применяю ее. Суть блочной верстки состоит в том, что html-страница хранит только список блоков и их вложенность, а внешний вид, размер, положение блоков, фоновые рисунки описываются в каскадных таблицах стилей. Если бы все стили хранились в общем файле, этот файл был бы огромен и навигация по нему была бы сильно затруднена, поэтому отдельные страницы или ветки портала имеют свои таблицы стилей. При этом идеология CSS работает так, что общий таблицы стилей сохраняют свое действие.

Чтобы дать разработчикам возможность подключать свои скрипты и каскадные таблицы стилей, MasterPage портала ОАО «Гипровостокнефть» имеет свои ContentPlaceHolder в разделах Script и Style блока Head.

3.2.4 Используемые серверные элементы управления

Система оформления командировок работает с базой данных, а значит с большим количеством структурированных табличных данных, которые требуется выводить на гипертекстовую страницу в удобном для пользователя виде. ASP.net имеет целый ряд компонентов для отображения табличных данных. Это DataList, DataGridView и DataRepeater компоненты. Самый гибкий из них - Repeater. У него есть блоки, в которых описывается шапка блока данных, шаблон, по котрому будет выводиться запись данных, шаблон разделителя и «дно», то что следует после списка данных. Например, разметка репитера, формирующего список оформляемых пользователем командировок, выглядит так:

<asp:Repeater ID="Repeater1" runat="server" OnItemCommand="Repeater1_ItemCommand">

<HeaderTemplate>

</HeaderTemplate>

<ItemTemplate>

[…верстка…]

<h3>

<%#(((bool)Eval("task.IsTask")) || ((int)Eval("task.TypeID")==9) || ((int)Eval("task.TypeID")==12)) ? "Задание" : "Заявка"%>

от

<%#Eval("task.StartTime")%></h3>

<b>Описание: </b>

<%#Eval("task.Type.Value")%><br />

<b>Автор: </b>

<%#Eval("author.Name")%>

<%#Eval("author.SecondName")%>

<%#Eval("author.Surname")%>

</div>

<div class="InnerRequestStyle">

<%#Eval("text")%><br />

<b>Статус: </b>

<%#Eval("task.Status.Value")%>

<br />

[…кнопки…]

</ItemTemplate>

<FooterTemplate>

</FooterTemplate>