Разработка многопользовательской модели работы на дому
Анализ проблемы ведения трудовой деятельности на дому. Сравнение подходов к моделированию системы. Разработка SADT-моделей деятельности ООО "Бюро переводов Полиглот". Проектирование веб-системы многопользовательского доступа к рабочей документации.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 19.10.2019 |
Размер файла | 1,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
1
Введение
моделирование веб многопользовательский
Появление сети Интернет и широкополосного доступа к ней привело к появлению новых форм деятельности во всех сферах. Так, например, появилось много распределенных предприятий, в которых сотрудники могут физически не находиться в офисе. Системы контроля версий, тайм-трекеры и прочие инструменты позволяют организовать рабочий процесс и создать по сути виртуальный офис.
Самый большой успех в сфере удаленной работы на дому сейчас демонстрирует ИТ-индустрия. Для разработчиков программ существует самый широкий спектр автоматизированных информационных систем и уже практически нет задач, для которых не была бы написана соответствующая программная система.
Но есть и предприятия, которые хоть и выполняют в целом похожую работу, отличаются спецификой процессов и для них средств автоматизации пока не представлено. В своей дипломной работе я рассмотрю как раз один из примеров такого предприятия - это бюро переводов. В нем есть необходимость присутствия сотрудников в офисе, но только на отдельных стадиях. При этом классические программы из ИТ-индустрии не подходят для решения задач. Они либо содержат избыточный функционал, либо требуется их компоновка, что дорого для небольшого бюро.
В ходе исследования была определена ключевая проблема предметной области - высокие издержки на выполнение процессов, что негативно сказывается на работе предприятия.
Глава 1. Формирование модели проблемы ведения трудовой деятельности на дому
1.1 Предпроектный сбор данных и представление объекта исследования
ООО «Бюро переводов Полиглот» образовано в городе Новочеркасске в 2010 году, целью создания компании было получение дохода от деятельности по профессиональному переводу документов и оказания иных услуг, связанных с переводом текста.
ООО «Бюро переводов Полиглот» оказывает своим клиентам следующие услуги:
1. Письменные переводы текста
· Перевод технической документации;
· Перевод переписки с сохранением конфиденциальности;
· Перевод эксплуатационных и проектных документов;
· Перевод медицинских документов;
· Перевод специализированной литературы и научных статей;
· Перевод сопроводительной документации к импортируемым товарам и услугам для таможенного оформления и сертификации;
· Перевод документов для выезда заграницу.
2. Устные переводы
· Сопровождение иностранных визитёров;
· Перевод в реальном времени и сопровождение международных совещаний;
· Сопровождение граждан РФ на иностранных мероприятиях (выставки, форумы, деловые встречи);
· Перевод телефонных переговоров.
Такому бизнесу характерна сложность подбора кадров, особенно кадров высокой мобильности, способных сопровождать и оказывать услуги устного перевода. К счастью, у ООО «Бюро переводов Полиглот» проблем с кадрами нет, однако имеются проблемы финансового характера. Финансовые проблемы выражаются в низкой удовлетворенности переводчиков своей заработной платой и условиями труда.
Ввиду особенностей оказываемых услуг - многие переводы должны заверяться нотариально и существуют конфиденциальные материалы, которые запрещено передавать в незашифрованном виде. Все это требует периодического присутствия переводчиков в офисе, но все прекрасно понимают что работу по переводу можно выполнить и дома. Руководствуясь такими соображениями, директор ООО «Бюро переводов Полиглот» принял решение перенести деятельность переводчиков в формат работы на дому. До кризиса 2015 финансовое положение было стабильным и работников устраивал их доход. Однако после января 2015 года сократились объемы деятельности, связанной с переводами (меньше стало поездок, выставок и прочего).
Мною был выполнен анализ внутренней и внешней среды ООО «Бюро переводов Полиглот», который дал возможность сформировать информационную картину внешнего окружения, раскрыть возможности и риски общества.
Были проанализированы:
1. Потребительский рынок. Потребители услуг ООО «Бюро переводов Полиглот» - в основной массе это физические лица, не заказывающие большой объем работ - гастарбайтеры, которым необходимо перевести какую-либо справку, студенты, люди желающие получить перевод интернет-переписки. Предприятие зарабатывает на количестве подобных услуг, и по этой причине чтобы сэкономить на офисном помещении было решено работать на дому. Юридические лица также обращаются за переводческими услугами, но количество таких обращений как правило мало. Сказывается близость Ростова-на-Дону и сосредоточение крупных фирм, связанных с международной деятельностью, в этом городе;
2. Рынок услуг. В целом рынок переводческих услуг - развитая вещь. Но поскольку Новочеркасск город, находящийся по соседству с городом-миллионником, локальная конкуренция практически отсутствует. Статистика показывает, что несмотря на снижение количества обращений, сотрудники ООО «Бюро переводов Полиглот» без работы не сидят.
3. Кадровые ресурсы. Подбор персонала задача крайне сложная, но к счастью для ООО «Бюро переводов Полиглот» проблем с кадрами нет - компания была образована вокруг группы талантливых переводчиков.
Результат анализа внешней среды натолкнул на выводы о хоть и недостаточно благоприятной, но стабильной внешней среде компании, которая своим ухудшением уже внесла дестабилизацию в работу ООО «Бюро переводов Полиглот», дальнейших ухудшений внешних условий не предвидится.
Поэтому суть финансовых проблем было решено изучить через анализ внутренней среды. Я выполнил оценку состояния и эффективности использования ресурсов, имеющихся в распоряжении ООО «Бюро переводов Полиглот» по разным аспектам.
Структура управления (см. рисунок 1). У ООО «Бюро переводов Полиглот» имеется генеральный директор, бухгалтерия. Организация делится на подразделения, каждое из которых выполняет поставленные перед ним задачи. Рассогласования в структуре управления не было найдено.
Рисунок 1 - Структура ООО «Бюро переводов Полиглот»
В компании работают 20 человек, из которых 2 человека в руководстве (Директор и Бухгалтер), 4 человека в офисе (Администратор, Секретарь, Кассир и Уборщица). Основной состав рабочих - это 14 переводчиков разной специализации.
Продажи. ООО «Бюро переводов Полиглот» занимается оказанием услуг юридическим и физическим лицам, оплата принимается наличным и безналичным расчетом, для чего заключен договор на эквайринг с ПАО КБ Центр-Инвест. Оказание услуг ведется по предоплате в размере от 30% стоимости услуг. Есть система скидок для постоянных клиентов. Оплата труда переводчикам осуществляется без учета издержек, которые они несут в ходе своей работы. Так, оплата нотариально заверяемого перевода фиксированная и подразумевается, что переводчик компенсирует свои издержки самостоятельно.
Услуги. Основной вид деятельности ООО «Бюро переводов Полиглот» - профессиональный перевод текстов и сопровождение интернациональных мероприятий.
Маркетинг. Cлужбы маркетинга в ООО «Бюро переводов Полиглот» нет, это по сути не нужна задача для предприятия, оно прочно заняло свою нишу и заработало хорошую репутацию. Анализ внутренней среды компании помог выявить внутренние риски компании, к которым можно отнести слабую финансовую политику компании в области оплаты труда переводчиков.
1.2 Выбор методологии моделирования
В бакалаврской работе ставится задача выработки предложений по оптимизации работы предприятия ООО «Бюро переводов Полиглот». Это невозможно без современных методологий и CASE-средств. Поэтому первым шагом при построении моделей является выбор средства, которое будет рабочим инструментом. Далее приведены описания, полученные из открытых источников и результаты сравнения CASE-средств по определенным критериям.
1.2.1 Методы структурного анализа
Методы структурного способны упростить модель системы через ее иерархическое разделение на «черные ящики». Преимущество использовании черных ящиков состоит в том, что пользователю не важно содержание черных ящиков, как они работают. Достаточно иметь информацию о его входах и выходах, а также его назначении (т.е. функцию, которую он выполняет) [1].
Разбиение системы на черные ящики является первым шагом и должно быть построено на основе следующих принципов
· Один черный ящик на одну функцию систему;
· функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - "расчет точки приземления");
· связь между черными ящиками должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой для расчета налогов - необходима связь между этими черными ящиками: размер заработанной платы требуется для расчета налогов);
· связи между черными ящиками должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понятности сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур.
Наконец, третий момент: структурные методы широко используют графические нотации, также служащие для облегчения понимания сложных систем. Известно, что “одна картинка стоит тысячи слов”.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
· SADT (Structured Analysis and Design Technique) [2]. Для новых систем SADT (IDEF0) применяется для определения требований для разработки системы, реализующей выделенные функции. Для уже существующих - IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция);
· DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0;
· IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций;
· ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).
На стадии моделирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов на этапе анализа.
Модели SADT (IDEF0) наиболее удобны при построении функциональных моделей. Они наглядно отражают функциональную структуру объекта: производимые действия, связи между этими действиями. Достоинством нотации является возможность получить полную информацию о каждой работе, благодаря ее жестко регламентированной структуре. С ее помощью можно выявить все недостатки, касающиеся как самого процесса, так и то, с помощью чего он реализуется: дублирование функций, отсутствие механизмов, регламентирующих данный процесс, отсутствие контрольных переходов и т.д.
DFD позволяет проанализировать информационное пространство системы и используется для описания документооборота и обработки информации. Поэтому диаграммы DFD применяют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.
IDEF3 предназначена для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.
1.2.2 Язык UML
Язык UML (Unified Modeling Language) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем [3].
Этот язык одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм [4]:
· Диаграмма вариантов использования. Описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Она является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки;
· Диаграмма классов. Служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы;
· Диаграмма состояний. Описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне;
· Диаграмма деятельности. Представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения;
· Диаграмма последовательности. Используется для моделирования взаимодействия элементов во времени. Оно рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений;
· Диаграмма кооперации. Предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии;
· Диаграмма компонентов. Описывает особенности физического представления системы. Диаграмма позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код;
· Диаграмма развертывания. Предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками.
В настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо, поэтому рано говорить о UML как о действительно полноценной замене всем другим подходам.
1.2.3 Сравнение подходов к моделированию системы
Так как каждый подход регламентируется разработчиками как методология, подходящая для анализа и проектирования, то имеет смысл подробнее остановиться на нотациях. В Таблице 1 представлено сравнение нотаций, применяемых для моделирования и проектирования ИС.
Таблица 1 - Сравнительный анализ нотаций IDEF, UML
Мною было решено использовать структурный подход к моделированию. Подход дает возможность проведения глубокого анализа бизнес - процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности. Применение универсальных графических языков моделирования IDEF0, IDEF3 обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов при моделировании предметной области в контексте «как должно быть».
1.3 Разработка SADT-моделей деятельности ООО «Бюро переводов Полиглот» как есть
Так как мы определили себе инструмент - структурный анализ и проектирование в виде диаграмм IDEF0 и IDEF3, то воспользуемся идеей построения моделей как есть для отражения снимка реальных событий. Начнем процесс с разработки контекстной диаграммы.
Размещено на http://www.allbest.ru/
1
Рисунок 2 - Контекстная диаграмма модели
Деятельность ООО «Бюро переводов Полиглот» строится вокруг оказания переводческих услуг. На контекстной диаграмме показаны входные, выходные потоки, механизмы и средства управления для процесса работы компании.
Размещено на http://www.allbest.ru/
1
Рисунок 3 - Декомпозиция контекстной диаграммы
Процесс работы предприятия декомпозирован на четыре черных ящика.
Начинает свою работу компания с приема заявки от клиента. Заявкой считается перечень желаемых услуг и текст/информация о мероприятии, перевод которых необходим клиенту. Заявка оформляется как заказ, в котором уже есть четкие требования по перечню услуг, срокам оказания и стоимости.
На основе заказа клиента выполняется процесс выдачи задания переводчику. Здесь необходимо подобрать подходящего специалиста, выдать ему перечень документов и услуг, которые клиенту необходимо оказать.
В процессе оказания услуг переводчик переводит тексты, а сотрудники офиса, в особенности администратор, следят за соблюдением заказа - сроки и состав услуг не должны быть нарушены без согласования.
Как только переводчик заканчивает свою работу с текстами, он передает их в офис, это в обязательном порядке делается лично, поскольку в компании заведен строгий порядок несения ответственности каждым сотрудником. Все документы сдаются под подпись.
Клиент, чья услуга выполнена, приносит оставшуюся часть оплаты и забирает свои документы в соответствии с заказом. Происходит финансовый учет и переводчик получает свою заработную плату.
Проблемными с моей точки зрения являются два процесса - это выдача задания и финансовый учет. Их я раскрыл с помощью диаграмм декомпозиции.
Размещено на http://www.allbest.ru/
1
Рисунок 4 - Модель процесса выдачи заданий
Выдача заданий - первый и основной проблемный процесс в рассматриваемом предприятии. Он заключается в следующем.
Сотрудник офиса выбирает подходящего специалиста исходя из специфики заказа и загруженности. Выбранный специалист приглашается в офис. Это первая проблема - оснований для приглашения переводчика в офис нет никакого, задание можно выдать и удаленно. Однако есть проблема мониторинга принятия задания к выполнению и прочие управленческие задачи, которые по-другому сейчас не решить.
По приходу в офис, переводчик оформляет задание, в котором указываются сроки, стоимость оплаты и перечень услуг. Этот документ является основанием для начисления заработной платы.
Затем следует вторая проблема в данном процессе - сотруднику лично предаются документы для перевода. Это архаичный процесс, который сопряжен с рисками утраты и нарушения тайны, если таковая требуется заявкой клиента. Опять таки повторюсь, что средств для удаленной выдачи, хоть их рынок сейчас и велик, не применяется. Тут вступают в силу и особенности предметной области, и требования клиента по конфиденциальности и т.д. Но главный фактор здесь - это то, что подавляющее большинство документов, а если быть точным - 93% [5], представлены в бумажном виде и требуют оцифровки. Это не обязательно должны быть OCR-технологии, сотрудники ООО «Бюро переводов Полиглот» не пользуются автоматическими переводчиками, так как это вопрос профессиональной этики и тексты с возможностью копирования и вставки им не нужны.
Размещено на http://www.allbest.ru/
1
Рисунок 5 - Модель финансовых процессов
Процесс финансового учета в ООО «Бюро переводов Полиглот» тривиальный и совпадает с 99,9% подобных процессов в других фирмах. Строя его модель, я хотел показать что при выдаче денежных средств переводчику учитывается только его заработная плата. Этот момент в большей степени психологический. При переходе на работу на дому, человек готовится что в офис компании ему в лучшем случае придется явиться только для получения месячной заработной платы. Но как видно из рисунка 4, всем работающим сотрудникам надо появляться в офисе каждый раз при появлении задания для них. Соответственно, растут издержки и из своей заработной платы переводчик оплачивает себе частые поездки в офис, при этом остается работающим «на дому». Это и есть основная причина недовольства сотрудников своими выплатами.
Но перенести бремя оплаты транспортных расходов на ООО «Бюро переводов Полиглот» невозможно, так как число поездок заранее непредсказуемо и требуется четкая стандартизация удаленной работы.
Подводя итоги можно сделать вывод, что проблемы лежат в устаревшей технологии выдачи заданий сотрудникам, работающим на дому, что влечет финансовые издержки и недовольство сотрудников в отношении оплаты своего труда.
1.4 Математическая модель оценки издержек переводчика на посещение офиса ООО «Бюро переводов Полиглот»
Рассмотрим типовые затраты переводчика для выполнения одной работы по переводу текста. Из рисунка 4 мы видим, что первым этапом является посещение офиса с целью получения задания и документов для последующего перевода. Временные затраты на нахождение в офисе обозначим как t1. Временные затраты на дорогу до офиса обозначим как t2, финансовые затраты обозначим как m2.
Следующей операцией будет возврат переводчика домой, который оценивается по времени как t2, финансово как m2. Общие затраты на дорогу по времени обозначим как t3= 2t2, финансовые как m3=2m2. Перейдем к расчетам.
- Переводчик перемещается на автомобиле. Пусть средний расход топлива A составляет 10л. / 100км;
- Стоимость литра топлива P (Бензин АИ-95)- 39.50 рублей;
- Среднее расстояние S, которое необходимо проехать от дома до офиса, составляет 8 км.;
- Средняя скорость U автомобиля в городе - 24 км. / ч.;
- За 1 задание автомобиль совершит 2 поездки;
- Время нахождения в офисе t1 составляет 30 минут.
Сведем исходные данные в таблицу 2.
Таблица 2. - Исходные данные математической модели
Показатель |
Обозначение |
Значение |
|
Расход топлива |
А |
10л/100км |
|
Стоимость литра бензина |
Р |
39.50 рублей |
|
Среднее расстояние одной поездки |
S |
8 км |
|
Средняя скорость автомобиля |
U |
24км/ч |
|
Количество поездок |
n |
2 |
|
Средний доход переводчика за один заказ |
Q |
370 рублей |
Выведем формулы для расчета: Время, которое тратит переводчик на дорогу в одну сторону равно:
t2 = (S / U)(1)
Где:
S - Среднее расстояние одной поездки
U - Средняя скорость автомобиля
Финансовые затраты на дорогу к офису и обратно определим по формуле:
m2 = (S * A /100* P)(2)
Где:
S - Среднее расстояние одной поездки
A - Расход топлива
P - Стоимость литра бензина
Рассчитаем значение временных затрат на дорогу. По формуле (1), t2 = 20 мин. По формуле (2), рассчитаем денежные затраты на дорогу. m1 = 31,6 руб. Итого общие временные затраты на дорогу по времени t3 составят 40 минут, то есть почти 10% рабочего дня, общие финансовые затраты m3 составят 63,2 рубля, то есть почти 17% от средней суммы заработка.
Исходя из вышеперечисленных данных, мы можем вывести формулы временных Т и денежных M затрат на перевод одного документа сотрудником, работающим на дому.
Временные затраты на перевод одного документа:
T = t1 + (4* t2) + t3 + t4(3)
Где:
t1 - временные затраты на нахождение в офисе;
t2 - временные затраты на поездку за новым заданием и доставку в офис готового перевода;
t3 - временные затраты на перевод документа (порядка 60 минут);
t4 - временные затраты оформление акта выполненных работ (порядка 20 минут).
Денежные затраты на формирование страхового полиса
M = (n* m1)(4)
Где:
m1 - стоимость перемещения
Из формулы (3) получим, что временные затраты выполнение одного перевода равны 190 минут. Из формулы (4) получим, что себестоимость процедуры перевода, не считая заработной платы, составляет 126,4 рублей.
Переводчики, разумеется стараются приспособиться к таким условиям и приезжают 2 раза в день, с утра за новыми заданиями - вечером возвращают переводы. Построим график зависимости издержек от количества документов на перевод (см. рисунок 6,7), принимая во внимание следующее.
- Минимум 80 минут в день переводчик тратит на дорогу.;
- Рабочий день переводчика составляет 8 часов (480 минут);
- На выполнение переводов у него остается в день 400 минут.
Рисунок 6 - Зависимость временных издержек от количества переведенных документов
Рисунок 6 - Зависимость денежных издержек от количества переведенных документов
Из рисунков 5 и 6 видно, что неправильная процедура выдачи заданий влечет не менее чем 26,5% накладных расходов по времени и не менее чем 5% издержек в плане стоимости.
1.5 Формирование проблемы удаленной работы в ООО «Бюро переводов Полиглот»
С момента образования компания вела успешную деятельность, но из-за последних событий в мире сократился спрос на услуги переводчиков, а также возросли издержки (выросла стоимость топлива), упал реальный доход населения. В таких условиях поднятие стоимости услуг не является мудрым решением, так как это отпугнет клиентов.
Поэтому сформируем проблемы, которые следует решить в дипломной работе:
1. Проблема минимизации временных издержек на этапе оформления заданий и сдачи готовых переводов;
2. Проблема минимизации финансовых издержек на этапе оформления заданий и сдачи готовых переводов;
3. Проблема стандартизации процесса выдачи задания удаленным работникам компании;
4. Проблема стабилизации финансовых издержек и обеспечение возможности их переноса в область ответственности компании.
Эти проблемы, которые негативным образом сказываются на удовлетворенности переводчиков своим режимом работы и оплаты я и буду решать в своей дипломной работе.
1.6 Установление целей выпускной квалификационной работы
На этом этапе необходимо определить цели, которые помогут разрешить проблемную ситуацию. На данном предприятии проблема состоит в том, что время переводчиков используется нерационально и их без особой необходимости вызывают в офис, при этом сохраняя формально им режим работы на дому. Руководство ООО «Бюро переводов Полиглот» поставило перед собой цель увеличения удовлетворенности заработком переводчиков без фактического увеличения ставки оплаты. Этого можно достичь, снизив издержки и повысив тем самым эффективность и производительность труда.
Целью выпускной квалификационной работы является минимизация стоимостных и временных затрат на перевод документов, а именно обеспечение удаленного доступа к документам и заданиям, получаемым от клиентов компании.
Требуется решить следующие задачи
1. Осуществить поиск оптимального способа передачи заданий.
2. Предложить сценарий предоставления передачи заданий, минимизирующий затраты.
3. Предложить варианты реализации и проект системы для поставленной задачи.
Глава 2. Реинжиниринг процесса удаленной работы сотрудников компании
2.1 Формирование предложения по оптимизации
Предположим, что есть некоторое средство, с помощью которого можно выдавать новые задания и контролировать их получение удаленно.
Такое средство должно уметь преобразовывать документы в цифровой формат, передавать их в зашифрованном виде по каналам передачи данных и уведомлять исполнителя о получении нового задания.
Если применить такой инструмент, мы сможем изменить схему получения заданий следующим образом (см. рисунок 8).
Рисунок 8. - Оптимальный сценарий выдачи задания
Чтобы выбрать вариант реализации алгоритма я выбрал метод экспертных оценок и процедуру ранжирования.
Постановка задачи
Необходимо выбрать наилучшее средство, которое реализует предложенный алгоритм:
1. - Электронная почта;
2. - Dropbox (Яндекс-диск, Облако Mail.ru и т.д.);
3. - Redmine (ИТ-инструмент);
4. - Специализированная система.
Была собрана группа экспертов в составе 3-х человек:
· Директора ООО «Бюро переводов Полиглот»,
· Переводчика технической документации,
· Администратора,
Им были выданы правила оценивания и критерии оценки каждого варианта. Эксперты выполнили попарное сравнение вариантов реализации алгоритма, оценивая их важность в долях единицы.
Таблица 3 - Экспертные оценки по каждому из критериев
Эj |
А1 ? А2 |
А1 ? А3 |
А1 ? А4 |
А2 ? А3 |
А2 ? А4 |
А3 ? А4 |
|||||||
Э1 |
0,7 |
0,5 |
0,6 |
0,3 |
0,4 |
0,3 |
0,5 |
0,4 |
0,4 |
0,3 |
0,3 |
0,4 |
|
Э2 |
0,3 |
0,5 |
0,3 |
0,7 |
0,2 |
0,5 |
0,4 |
0,6 |
0,3 |
0,5 |
0,7 |
0,4 |
|
Э3 |
0,4 |
0,3 |
0,5 |
0,5 |
0,5 |
0,6 |
0,3 |
0,4 |
0,2 |
0,7 |
0,5 |
0,8 |
Таблица 4 - Сумма по столбцам
А1 ? А2 |
А1 ? А3 |
А1 ? А4 |
А2 ? А3 |
А2 ? А4 |
А3 ? А4 |
||||||||
сумма |
1,4 |
1,3 |
1,4 |
1,5 |
1,1 |
1,4 |
1,2 |
1,4 |
0,9 |
1,5 |
1,5 |
1,6 |
Были определены предпочтения экспертов по следующей формуле:
f(Аi)= ?Аi
f(А1) = 1,4 + 1,4 + 1,1 = 3,9
f(А2) = 1,3 + 1,2 + 0,9 = 3,4
f(А3) = 1,5 + 1,4 + 1,5 = 4,4
f(А4) = 1,4 + 1,5 + 1,6 = 4,5
Далее были рассчитаны веса альтернатив:
А1 = 0,24, А2 = 0,21, А3 = 0,27, А4 = 0,28.
Следовательно, А4 > А3 > А1 > А2. Или другими словами, по мнению экспертов наиболее приемлемым и осуществимым является создание специализированной системы. Это было сделано из-за необходимости оцифровки документов, контроля выполнения и получения заданий и т.д., чем в совокупности не обладало ни одно средство.
2.2 Математическая модель оценки издержек переводчика на посещение офиса ООО «Бюро переводов Полиглот» после реинжиниринга
При воплощении в жизнь предложений по оптимизации уйдет необходимость в посещении офиса для получения заданий. Это приведет к тому, что следующие параметры получат новые значения:
· Временные затраты на нахождение в офисе t1=0
· Количество поездок в офис в день = 1
В остальном исходные данные останутся теми же. Воспользуемся формулами (3,4) и данными таблицы 2, чтобы рассчитать издержки после внедрения предложений по оптимизации:
Параметры t2 = 20 мин и m1 = 31,6 руб. свои значения не поменяют.
Исходя из вышеперечисленных данных, мы можем вывести формулы временных Т и денежных M затрат на перевод одного документа сотрудником, работающим на дому.
Из формулы (3) получим, что временные затраты выполнение одного перевода будут равны 120 минут (на 37% меньше). Из формулы (4) получим, что себестоимость процедуры перевода, не считая заработной платы, составляет 63,2 рубля (на 50% меньше). Построим новый график зависимости издержек от количества документов на перевод (см. рисунок 9,10).
Рисунок 9 - Зависимость временных издержек от количества переведенных документов после оптимизации
Рисунок 10 - Зависимость денежных издержек от количества переведенных документов
Основными результатами оптимизации, как видно из рисунков 9 и 10, являются:
- увеличение количества переводов, которые переводчик может выполнить за 1 день (достигается повышение производительности труда);
- снижены временные издержки на 16% для 6 переводов и на 18% для максимального количества переводов в один рабочий день;
- снижены финансовые издержки на 3,1% для 6 переводов и на 3,5% для максимального числа проектов. Самый главный эффект достигается за счет того, что сотруднику теперь достаточно одного выезда в день, чтобы просто передать переводы в соответствии с регламентом. Эту фикисрованную стоимость в 63,2 рубля можно перенести на предприятие и платить сотруднику чистую заработную плату + доплачивать за транспортные расходы. Сумма не является огромной, но в совокупности с появившейся возможностью делать на 1 перевод за день больше, это даст общий прирост в доходе на 2590-2220=370 рублей или 16%.
2.3 Выбор CASE-средств моделирования
Моделирование особенно важно на первых этапах оптимизации бизнес-процессов. Так как исправление допущенных на этом этапе ошибок обходится наиболее дорого, то и польза на этапе анализа задачи и разработки решения значительна. На сегодняшний день насчитывается около 300 различных CASE-средств, наиболее мощные из которых, так или иначе, используются ведущими фирмами России [6]. В разделе 1.2 была выбрана методология SADT и ее диаграммы IDEF0 и IDEF3, для них наиболее пригодными считаются: Bpwin, MS Visio, Design/IDEF.
Для выбора конкретного CASE-средства применим метод попарных сравнений - методологическую основу для решения задач выбора альтернатив посредством их многокритериального рейтингования [7].
Метод позволяет оценить противоречивость данных и минимизировать ее.
Критерии для анализа:
· Поддержка выбранных типов моделей (диаграмм);
· Простота и удобство работы по созданию моделей;
· Построение русскоязычных моделей;
· Наличие бесплатной (или пробной) версии.
Таблица 5 - Сведения о CASE-средствах по выделенным критериям
Критерий |
Bpwin |
MS Visio |
Design/IDEF |
|
Поддержка выбранных типов моделей (диаграмм) |
Да |
Да |
Да |
|
Простота и удобство работы по созданию моделей |
Нет |
Да |
Нет |
|
Построение русскоязычных моделей |
Есть |
Есть |
Нет |
|
Наличие бесплатной (пробной) версии |
Есть |
Есть |
Есть |
Сравнение критериев происходит согласно шкале относительной важности:
1 - равная важность |
|
3 - умеренное превосходство одного над другим |
|
5 - существенное превосходство одного над другим |
|
7 - значительное превосходство одного над другим |
|
9 - очень сильное превосходство одного над другим |
|
2, 4, 6, 8 - соответствующие промежуточные значения |
Если при сравнении одного фактора i с другим j получено a(i,j) = b, то при сравнении второго фактора с первым получаем a(j,i) = 1/b.
Составим таблицу иерархии, в которой попарно сравним критерии:
Таблица 6 - Сравнение критериев оценки
Критерии |
Поддержка выбранных типов моделей |
Простота и удобство работы |
Построение русскоязычных моделей |
Построение русскоязычных моделей |
Оценка компонент собственного вектора |
Нормализо-ванныеоценки вектораприоритета |
|
Поддержка выбранных типов моделей |
1 |
5 |
7 |
3 |
3,2 |
0,606 |
|
Простота и удобство работы по созданию моделей |
1/5 |
1 |
7 |
1/5 |
0,727 |
0,138 |
|
Построение русскоязычных моделей |
1/7 |
1/7 |
1 |
3 |
0,497 |
0,094 |
|
Наличие бесплатной (пробной) версии |
1/3 |
5 |
1/3 |
1 |
0,859 |
0,162 |
|
У= 5,238 |
Далее попарно сравним альтернативу по каждому из критериев:
A - Design/IDEF
B - Bpwin
С - MS Visio
Критерий 1. «Поддержка выбранных типов моделей» (таблица 7).
Таблица 7 - Оценка по критерию «Поддержка выбранных типов моделей»
A |
B |
С |
Оценка компонент собственного вектора |
Нормализованные оценкивектора приоритета |
||
A |
1 |
1/5 |
7 |
1,117 |
0,241 |
|
B |
5 |
1 |
7 |
3,232 |
0,698 |
|
С |
1/7 |
1/7 |
1 |
0,277 |
0,059 |
|
У=4,626 |
Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что по критерию поддержки выбранных типов моделей лидирующим является MS Visio 2010.
Критерий 2. «Простота и удобство работы» (таблица 8).
Таблица 8 - Оценка по критерию «Простота и удобство работы»
A |
B |
С |
Оценка компонент собственного вектора |
Нормализованные оценкивектора приоритета |
||
A |
1 |
1/7 |
1/3 |
0,365 |
0,073 |
|
B |
7 |
1 |
9 |
3,924 |
0,787 |
|
С |
3 |
1/9 |
1 |
0,694 |
0,139 |
|
У=4,983 |
Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что наиболее простым и удобным в работе также является BPWin.
Критерий 3. « Построение русскоязычных моделей» (таблица 9).
Таблица 9 - Оценка по критерию «Построение русскоязычных моделей»
A |
B |
С |
Оценка компонент собственного вектора |
Нормализованные оценкивектора приоритета |
||
A |
1 |
1/7 |
1/3 |
0,365 |
0,073 |
|
B |
7 |
1 |
9 |
3,924 |
0,787 |
|
С |
3 |
1/9 |
1 |
0,694 |
0,139 |
|
У=4,983 |
Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что безусловным лидером является BPWin, так как данное средство поддерживает построение русскоязычных моделей.
Критерий 4. «Наличие бесплатной версии» (таблица 10).
Таблица 10 - Оценка по критерию «Наличие бесплатной (пробной) версии»
A |
B |
С |
Оценка компонент собственного вектора |
Нормализованные оценкивектора приоритета |
||
A |
1 |
1/9 |
1/3 |
0,335 |
0,063 |
|
B |
9 |
1 |
9 |
4,264 |
0,805 |
|
С |
3 |
1/9 |
1 |
0,694 |
0,131 |
|
У=5,293 |
Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что безусловным лидером является BPWin.
2.4 Разработка SADT-моделей деятельности ООО «Бюро переводов Полиглот» как должно быть
В ходе написания предыдущих разделов пояснительной записки были сформулированы предложения по оптимизации бизнес-процессов удаленной работы. Отразим эти предложения с помощью структурной модели.
Вновь построим контекстную диаграмму (рисунок 11). В оптимизированной модели добавлен новый механизм - это информационная система. Как это отразилось на выполнении бизнес-процессов рассмотрим далее.
Размещено на http://www.allbest.ru/
1
Рисунок 11 - Контекстная диаграмма оптимизированной модели
Рисунок 12 - Диаграмма декомпозиции первого уровня
На диаграмме декомпозиции также только одно изменение - это новый механизм. Перейдем к подробному рассмотрению проблемных процессов.
Размещено на http://www.allbest.ru/
1
Рисунок 13 - Диаграмма процесса выдачи задания
Процесс выдачи задания, наоборот, поменялся очень сильно. Теперь выполняется следующая последовательность действий.
Выбор подходящего специалиста. Сотрудник офиса выбирает из числа переводчиков подходящего по квалификации и загруженности.
Оцифровка документов (новый). Новая функция, в которой с применением аппаратных средств (сканера или МФУ), а также программного обеспечения информационной системы сотрудник офиса создает цифровую копию переводимого текста.
Передача уведомления через систему (новый). Новая функция. После внедрения системы переводчик уже не должен приезжать в офис за новым заданием, ему достаточно запустить информационную систему, в которой он автоматически получит доступ к данным. Данный процесс я показал на диаграмме IDEF3 (см. рисунок 14).
Принятие к исполнению. Ранее переводчику требовалось оформить некоторые документы, чтобы приступить к работе над текстом, теперь ему достаточно подтвердить получение задания и принять его к исполнению, необходимый учет выполнит система автоматически.
Чтобы показать основную особенность системы, была построена следующая диаграмма.
Рисунок 14 - Диаграмма IDEF3 процесса передачи задания
Чтобы передать задание с использованием информационной системы, сотрудник офиса запускает систему, создает в ней новое задание, к которому прикрепляет файлы и выбирает исполнителя. Сформированное задание отправляется переводчику. Процесс финансового учета не поменялся.
Глава 3. Проектирование веб-системы многопользовательского доступа к рабочей документации для сотрудников, работающих на дому
3.1 Формирование требований к веб-системе
Этап реинжиниринга позволил определить общий портрет решения. Теперь его следует детализировать до уровня требований. Мною были определены следующие требования к веб-системе.
Требования к подсистемам и архитектуре.
· Наличие подсистемы оцифровки изображений;
· Наличие подсистемы формирования заданий;
· Наличие подсистемы контроля исполнения заданий;
· Наличие подсистемы передачи заданий;
· Наличие подсистемы шифрования данных.
Функциональные требования:
· Автоматизированное формирование заданий;
· Управление статусами заданий;
· Контроль времени выполнения задания;
· Возможность прикрепления и отправки файлов;
· Шифрование файлов, помеченных как конфиденциальные;
· Обеспечение многопользовательского доступа к документам.
3.2 Сравнительный анализ аналогов проектируемой системы
Из числа определенных требований были выявлены главные, по которым появилась возможность сравнить непрямые аналоги моей системы:
· Автоматизированное формирование заданий;
· Управление статусами заданий;
· Возможность прикрепления и отправки файлов;
· Шифрование файлов, помеченных как конфиденциальные;
· Обеспечение многопользовательского доступа к документам.
По данным критериям были сравнены такие инструментальные средства, как Redmine [8], Wrike[9], Asana[10], Neaktor[11].
Далее показан процесс сравнения аналогов по методу анализа Иерархий
Таблица 11 - Критерии сравнения систем
1 |
Автоматизированное формирование заданий; |
|
2 |
Управление статусами заданий; |
|
3 |
Возможность прикрепления и отправки файлов; |
|
4 |
Шифрование файлов, помеченных как конфиденциальные; |
|
5 |
Обеспечение многопользовательского доступа к документам |
Таблица 12 - Альтернативы
1 |
Redmine |
|
2 |
Wrike |
|
3 |
Asana |
|
4 |
Neaktor |
|
5 |
Проектируемая ИС |
Таблица 13 - Относительные веса критериев
КРИТЕРИИ |
Автоматизированное формирование заданий |
Управление статусами заданий |
Шифрование файлов, помеченных как конфиденциальные |
Возможность прикрепления и отправки файлов |
Обеспечение многопользовательского доступа к документам |
|
Автоматизированное формирование заданий |
1 |
7 |
3 |
8 |
3 |
|
Управление статусами заданий |
1/7 |
1 |
1/5 |
3 |
1/3 |
|
Шифрование файлов, помеченных как конфиденциальные |
1/3 |
5 |
1 |
3 |
5 |
|
Возможность прикрепления и отправки файлов |
1/8 |
1/3 |
1/3 |
1 |
1/3 |
|
Обеспечение многопользовательского доступа к документам |
1/3 |
3 |
1/5 |
3 |
1 |
|
Отношение согласованности (ОС) = |
9,63% |
После того, как были выявлены веса критериев, я приступил к сравнению систем по каждому критерию отдельно.
Таблица 14 - Сравнительные оценки систем по критерию «Автоматизированное формирование заданий»
Redmine |
Wrike |
Asana |
Neaktor |
Проектируемая ИС |
Нормализо-ванные оценки вектора приоритета |
|||
Redmine |
1 |
2 |
1 |
2 |
1/7 |
0,894113 |
0,113129 |
|
Wrike |
1/2 |
1 |
1/2 |
1/2 |
1/9 |
0,425142 |
0,053792 |
|
Asana |
1 |
1 |
1 |
2 |
1/7 |
0,778371 |
0,098484 |
|
Neaktor |
1/2 |
2 |
1/2 |
1 |
1/9 |
0,560978 |
0,070978 |
|
Проектируемая ИС |
7 |
9 |
7 |
9 |
1 |
5,244888 |
0,663617 |
|
Сумма |
10,0000 |
15,0000 |
10,0000 |
14,5000 |
1,5079 |
7,903491 |
Таблица 15 - Сравнительные оценки систем по критерию «Управление статусами заданий»
Redmine |
Wrike |
Asana |
Neaktor |
Проектируемая ИС |
Нормализо-ванные оценки вектора приоритета |
|||
Redmine |
1 |
1 |
1/8 |
1/8 |
1/8 |
0,287175 |
0,038462 |
|
Wrike |
1 |
1 |
1/8 |
1/8 |
1/8 |
0,287175 |
0,038462 |
|
Asana |
8 |
8 |
1 |
1 |
1 |
2,297397 |
0,307692 |
|
Neaktor |
8 |
8 |
1 |
1 |
1 |
2,297397 |
0,307692 |
|
Проектируемая ИС |
8 |
8 |
1 |
1 |
1 |
2,297397 |
0,307692 |
|
Сумма |
26,0000 |
26,0000 |
3,2500 |
3,2500 |
3,2500 |
7,466539 |
Таблица 16 - Сравнительные оценки систем по критерию «Шифрование файлов, помеченных как конфиденциальные»
Redmine |
Wrike |
Asana |
Neaktor |
Проектируемая ИС |
Нормализо-ванные оценки вектора приоритета |
|||
Redmine |
1 |
1/2 |
3 |
4 |
1/7 |
0,969640 |
0,118911 |
|
Wrike |
2 |
1 |
4 |
5 |
1/6 |
1,461443 |
0,179223 |
|
Asana |
1/3 |
1/4 |
1 |
1/2 |
1/8 |
0,349414 |
0,042850 |
|
Neaktor |
1/4 |
1/5 |
2 |
1 |
1/9 |
0,406585 |
0,049861 |
|
Проектируемая ИС |
7 |
6 |
8 |
9 |
1 |
4,967254 |
0,609155 |
|
Сумма |
10,5833 |
7,9500 |
18,0000 |
19,5000 |
1,5456 |
8,154335 |
Таблица 17 - Сравнительные оценки систем по критерию «Возможность прикрепления и отправки файлов»
Redmine |
Wrike |
Asana |
Neaktor |
Проектируемая ИС |
Нормализованные оценки вектора приоритета |
|||
Redmine |
1 |
7 |
4 |
5 |
2 |
3,086254 |
0,458257 |
|
Wrike |
1/7 |
1 |
1/4 |
1/3 |
1/5 |
0,298779 |
0,044364 |
|
Asana |
1/4 |
4 |
1 |
2 |
1/2 |
1,000000 |
0,148483 |
|
Neaktor |
1/5 |
3 |
1/2 |
1 |
1/3 |
0,630957 |
0,093687 |
|
Проектируемая ИС |
1/2 |
5 |
2 |
3 |
1 |
1,718772 |
0,255209 |
|
Сумма |
2,0929 |
20,0000 |
7,7500 |
11,3333 |
4,0333 |
6,734762 |
Таблица 18 - Сравнительные оценки систем по критерию «Обеспечение многопользовательского доступа к документам»
Redmine |
Wrike |
Asana |
Neaktor |
Проектируемая ИС |
Нормализованные оценки вектора приоритета |
|||
Redmine |
1 |
1 |
1 |
1/7 |
1/9 |
0,436648 |
0,051976 |
|
Wrike |
1 |
1 |
1 |
1/7 |
1/9 |
0,436648 |
0,051976 |
|
Asana |
1 |
1 |
1 |
1/7 |
1/9 |
0,436648 |
0,051976 |
|
Neaktor |
7 |
7 |
7 |
1 |
1/2 |
2,798033 |
0,333064 |
|
Проектируемая ИС |
9 |
9 |
9 |
2 |
1 |
4,292907 |
0,511007 |
|
Сумма |
19,0000 |
19,0000 |
19,0000 |
3,4286 |
1,8333 |
8,400885 |
Результаты оценок информационных систем по всем критериям сведены в таблицу 19.
Таблица 19 - Сравнительные оценки систем по всем критериям
Альтернативы |
Критерии |
Глобальные приоритеты |
|||||
Автоматизированное формирование заданий |
Управление статусами заданий |
Шифрование файлов, помеченных как конфиденциальные |
Возможность прикрепления и отправки файлов |
Обеспечение многопользовательского доступа к документам |
|||
Численное значение вектора приоритета |
|||||||
0,488208 |
0,069073 |
0,267736 |
0,047999 |
0,126984 |
|||
Redmine |
0,113129 |
0,038462 |
0,118911 |
0,458257 |
0,051976 |
0,118320 |
|
Wrike |
0,053792 |
0,038462 |
0,179223 |
0,044364 |
0,051976 |
0,085632 |
|
Asana |
0,098484 |
0,307692 |
0,042850 |
0,148483 |
0,051976 |
0,094534 |
|
Neaktor |
0,070978 |
0,307692 |
0,049861 |
0,093687 |
0,333064 |
0,116046 |
|
Проектируемая ИС |
0,663617 |
0,307692 |
0,609155 |
0,255209 |
0,511007 |
0,585469 |
Проектируемая веб-система является оптимальным вариантом для решения задачи удаленного многопользовательского доступа к документам.
3.3 Выбор архитектуры построения системы
Информационные системы могут быть построены на основе одной из следующих типовых архитектур [12]:
· файл-сервер;
· клиент-сервер;
· многоуровневая;
· интернет/интранет.
Разделение информационных систем по классам осуществляется на основе расположения функциональных компонент (см. таблицу 20).
Таблица 20 - Типовые функциональные компоненты информационной системы
Обозна-чение |
Наименование |
Характеристика |
|
PS |
Presentation Services (средства представления) |
Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки. |
|
PL |
Presentation Logic(логика представления) |
Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка. |
|
BL |
Business or Application Logic (прикладная логика) |
Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение. |
|
DL |
Data Logic (логика управления данными) |
Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными. |
|
DS |
Data Services (операции с базой данных) |
Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения. |
|
FS |
File Services (файловые операции) |
Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС) |
Для решения задачи проектирования веб-системы многопользовательского доступа к рабочей документации для сотрудников, работающих на дому подходит технология Интернет/Интранет на базе многоуровневой архитектуры, так как в данной системе требуется многопользовательский доступ с удаленных клиентов без особых требований к клиентскому оборудованию.
Рисунок 15 - Типовая архитектура
Типовая архитектура системы на основе интернет/интранет показана на рисунке 15.
3.4 Проектирование структуры баз данных
Проектирование базы данных выполнено с применением методологии IDEF1X [13] и CASE-средства ERWin.
Согласно методологии, первым этапом является построение логической схемы данных. Она показана на рисунке 16.
Рисунок 16 - Логическая структура базы данных веб-системы многопользовательского доступа к документам
Структура базы данных состоит из следующих сущностей:
Задание. Содержит информацию о заданиях по переводу, созданных на основе заказов клиентов:
· Номер договора - первичный ключ;
· Дата выдачи задания;
· Дата выполнения задания;
· Текущий статус задания.
Файл. Сущность, в которой хранятся оцифрованные тексты для перевода
· Код характеристики - первичный ключ;
· Номер договора - внешний ключ;
· Шифрование - флаг, который указывает зашифрован файл или нет;
· Файл - сам документ.
История статусов. Сущность для учета изменений в состоянии работ по заданию:
· Дата - первичный ключ;
· Номер договора - внешний ключ;
· СтатусБыл - содержит статус до изменения;
· СтатусСтал - содержит статус после измениения.
Услуга. Сущность содержит информацию об услугах, которые может оказать ООО «Бюро переводов Полиглот»:
· Код услуги - первичный ключ;
· Наименование услуги;
· Стоимость за единицу.
Переводчик. Сущность, описывающая переводчиков, трудящихся в компании:
· Табельный номер - первичный ключ;
· ФИО переводчика;
· Специализация переводчика;
· Квалификация переводчика.
Далее следует выполнить переход от логической модели данных к физической. Используемая методология IDEF1x предполагает разработку реляционной БД, в которой физическая модель идентична логической. При переходе на физический уровень необходимо устранить связи «многие-ко-многим» посредством введения ассоциативной сущности.
В проектируемой БД есть две связи многие-ко-многим, для их преобразования были введены две дополнительных ассоциативных сущности «УслугиПоЗаданию» и «Исполнитель» (рисунок 17).
Рисунок 17 - Физическая модель базы данных проектируемой информационной системы
Опишем добавленные сущности.
УслугиПоЗаданию. Сущность содержит информацию об услугах, которые ООО «Бюро переводов Полиглот» оказывает по конкретному договору:
· Код услуги - внешний ключ;
· Номер договора - внешний ключ;
· Количество;
· Статус оказания.
Подобные документы
Реализация информационной системы для ведения документации по аренде в СУБД Access 2000. Построение функциональной и информационной модели. Описание программного обеспечения, разработанного в архитектуре "клиент-сервер", анализ операционных характеристик.
курсовая работа [637,9 K], добавлен 30.08.2010Анализ решений по автоматизации аптечной деятельности. Разработка автоматизированной системы формирования заказов. Проектирование многопользовательского доступа к данным. Организация сетевой работы. Реализация протокола взаимодействия сервера и клиента.
дипломная работа [623,8 K], добавлен 19.01.2017Разработка автоматизированной информационной системы учета заказов на выполнение работ и формированию отчетной документации Бюро технической инвентаризации (БТИ). Системный анализ и схема документооборота. Разработка инфологической модели данных.
дипломная работа [603,9 K], добавлен 29.08.2014Проектирование многопользовательской информационной системы для автоматизации работы диспетчера отдела грузоперевозок. Выбор среды программирования. Разработка программного обеспечения, таблиц базы данных АСОИ. Построение диаграмм классов и деятельности.
курсовая работа [298,1 K], добавлен 03.06.2014Характеристика основных методов проектирования: в SADT, UML. Техническое задание на информационную систему. Создание модели в стандарте SADT (IDEF0). Декомпозиция родительской модели. Создание таблиц базы данных и связей между ними, бизнес логики.
курсовая работа [1,0 M], добавлен 14.11.2017Общая характеристика предприятия и определение проблем в его деятельности, анализ известных подходов к их решению. Средства разработки и анализ информационных потоков. Разработка и структура модели деятельности предприятия "как есть" и "как должно быть".
курсовая работа [372,7 K], добавлен 20.12.2013Разработка информационного обеспечения автоматизированной системы. Структурная схема и алгоритм программы. Проектные решения по программному обеспечению автоматизированной системы. Программа ведения учетно-отчетной документации пофидерного анализа.
дипломная работа [662,2 K], добавлен 06.06.2010Анализ подходов к системе дистанционного образования. Разработка принципов и структуры программы для внеклассной работы школьников по информатике. Проектирование системы с использованием CASE-средств. Построение автоматизированной модели данных.
дипломная работа [2,6 M], добавлен 27.10.2017Разработка автоматизированной системы по учету и анализу заказов на товары для предприятия, работающего в сфере торговли товарами для обеспечения безопасности. Разработка удобного для пользователя интерфейса. Реализация многопользовательского доступа.
дипломная работа [1,1 M], добавлен 14.01.2012История создания методологии SADT, ее сущность и процедура. Состав, типы связей между функциями. Построение IDEF0 модели для автоматизации деятельности магазина "Ластик". Описание предметной области. Применение SADT для моделирования деятельности.
контрольная работа [450,1 K], добавлен 24.12.2013