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

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

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

Но есть и предприятия, которые хоть и выполняют в целом похожую работу, отличаются спецификой процессов и для них средств автоматизации пока не представлено. В своей дипломной работе я рассмотрю как раз один из примеров такого предприятия – это бюро переводов. В нем есть необходимость присутствия сотрудников в офисе, но только на отдельных стадиях. При этом классические программы из ИТ-индустрии не подходят для решения задач. Они либо содержат избыточный функционал, либо требуется их компоновка, что дорого для небольшого бюро.

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

Глава 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 (UnifiedModelingLanguage) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем [3].

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

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

· Диаграмма классов. Служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы;

· Диаграмма состояний. Описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне;

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

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

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

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

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

В настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо, поэтому рано говорить о UML как о действительно полноценной замене всем другим подходам.

1.2.3. Сравнение подходов к моделированию системы

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

Таблица 1– Сравнительный анализ нотаций IDEF, UML

Мною было решено использовать структурный подход к моделированию. Подход дает возможность проведения глубокого анализа бизнес – процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности. Применение универсальных графических языков моделирования IDEF0, IDEF3обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов при моделировании предметной области в контексте«как должно быть».

1.3. Разработка SADT-моделей деятельности ООО «Бюро переводов Полиглот» как есть

Так как мы определили себе инструмент – структурный анализ и проектирование в виде диаграмм IDEF0 и IDEF3, то воспользуемся идеей построения моделей как есть для отражения снимка реальных событий. Начнем процесс с разработки контекстной диаграммы.

Рисунок 2 – Контекстная диаграмма модели

ДеятельностьООО «Бюро переводов Полиглот» строится вокруг оказания переводческих услуг. На контекстной диаграмме показаны входные, выходные потоки, механизмы и средства управления для процесса работы компании.

Рисунок 3 – Декомпозиция контекстной диаграммы

Процесс работы предприятия декомпозирован на четыре черных ящика.

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

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

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

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

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

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

Рисунок 4 – Модель процесса выдачи заданий

Выдача заданий – первый и основной проблемный процесс в рассматриваемом предприятии. Он заключается в следующем.

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

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

Затем следует вторая проблема в данном процессе – сотруднику лично предаются документы для перевода. Это архаичный процесс, который сопряжен с рисками утраты и нарушения тайны, если таковая требуется заявкой клиента. Опять таки повторюсь, что средств для удаленной выдачи, хоть их рынок сейчас и велик, не применяется. Тут вступают в силу и особенности предметной области, и требования клиента по конфиденциальности и т.д. Но главный фактор здесь – это то, что подавляющее большинство документов, а если быть точным – 93% [5], представлены в бумажном виде и требуют оцифровки. Это не обязательно должны быть OCR-технологии, сотрудники ООО «Бюро переводов Полиглот» не пользуются автоматическими переводчиками, так как это вопрос профессиональной этики и тексты с возможностью копирования и вставки им не нужны.

Рисунок 5 – Модель финансовых процессов

Процесс финансового учета в ООО «Бюро переводов Полиглот» тривиальный и совпадает с 99,9% подобных процессов в других фирмах. Строя его модель, я хотел показать что при выдаче денежных средств переводчику учитывается только его заработная плата. Этот момент в большей степени психологический. При переходе на работу на дому, человек готовится что в офис компании ему в лучшем случае придется явиться только для получения месячной заработной платы. Но как видно из рисунка 4, всем работающим сотрудникам надо появляться в офисе каждый раз при появлении задания для них. Соответственно, растут издержки и из своей заработной платы переводчик оплачивает себе частые поездки в офис, при этом остается работающим «на дому». Это и есть основная причина недовольства сотрудников своими выплатами.

Но перенести бремя оплаты транспортных расходов на ООО «Бюро переводов Полиглот» невозможно, так как число поездок заранее непредсказуемо и требуется четкая стандартизация удаленной работы.

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

1.4. Математическая модель оценки издержек переводчика на посещение офиса ООО «Бюро переводов Полиглот»

Рассмотрим типовые затраты переводчика для выполнения одной работы по переводу текста.Из рисунка 4 мы видим, что первым этапом является посещение офиса с целью получения задания и документов для последующего перевода. Временные затраты на нахождение в офисе обозначим как t₁. Временные затраты на дорогу до офиса обозначим как t₂, финансовые затраты обозначим как m₂.

Следующей операцией будет возврат переводчика домой, который оценивается по времени как t₂, финансово как m₂. Общие затраты на дорогу по времени обозначим как t₃= 2t₂, финансовые как m₃=2m₂. Перейдем к расчетам.

_-Переводчик перемещается на автомобиле. Пусть средний расход топливаA составляет 10л. / 100км;

_-Стоимость литра топлива P (Бензин АИ-95)– 39.50 рублей;

_-Среднее расстояниеS, которое необходимо проехать от дома до офиса, составляет 8 км.;

_-Средняя скоростьU автомобиля в городе – 24 км. / ч.;

_-За 1 задание автомобиль совершит 2 поездки;

_-Время нахождения в офисе t₁составляет 30 минут.

Сведем исходные данные в таблицу 2.

Таблица 2. – Исходные данные математической модели

Показатель	Обозначение	Значение
Расход топлива	А	10л/100км
Стоимость литра бензина	Р	39.50 рублей
Среднее расстояние одной поездки	S	8км
Средняя скорость автомобиля	U	24км/ч
Количество поездок	n	2
Средний доход переводчика за один заказ	Q	370 рублей

Выведем формулы для расчета: Время, которое тратит переводчик на дорогу в одну сторону равно:

t₂ = (S / U) (1)

Где:

S – Среднее расстояние одной поездки

U – Средняя скорость автомобиля

Финансовые затраты на дорогу к офису и обратно определим по формуле:

m₂ = (S * A/100* P) (2)

Где:

S – Среднее расстояние одной поездки

A – Расход топлива

P - Стоимость литра бензина

Рассчитаем значение временных затрат на дорогу. По формуле (1), t₂ = 20 мин. По формуле (2), рассчитаем денежные затраты на дорогу. m₁= 31,6 руб. Итого общие временные затраты на дорогу по времени t₃ составят 40 минут, то есть почти 10% рабочего дня, общие финансовые затраты m₃ составят 63,2 рубля, то есть почти 17% от средней суммы заработка.

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

Временные затраты на перевод одного документа:

T = t₁ + (4* t₂) + t₃ + t₄ (3)

Где:

t₁ – временные затраты на нахождение в офисе;

t₂ – временные затраты на поездку за новым заданием и доставку в офис готового перевода;

t₃ – временные затраты на перевод документа (порядка 60 минут);

t₄ – временные затраты оформление акта выполненных работ (порядка 20 минут).

Денежные затраты на формирование страхового полиса

M = (n* m₁) (4)

Где:

m₁ – стоимость перемещения

Из формулы (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	А₁ ⇔ А₂		А₁ ⇔ А₃		А₁ ⇔ А₄		А₂ ⇔ А₃		А₂ ⇔ А₄		А₃ ⇔ А₄
Э₁	0,7	0,5	0,6	0,3	0,4	0,3	0,5	0,4	0,4	0,3	0,3	0,4
Э₂	0,3	0,5	0,3	0,7	0,2	0,5	0,4	0,6	0,3	0,5	0,7	0,4
Э₃	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,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,4 + 1,4 + 1,1 = 3,9

f(А₂)= 1,3 + 1,2 + 0,9 = 3,4

f(А₃)= 1,5 + 1,4 + 1,5 = 4,4

f(А₄)= 1,4 + 1,5 + 1,6 = 4,5

Далее были рассчитаны веса альтернатив:

А₁ = 0,24, А₂ = 0,21, А₃ = 0,27, А₄ = 0,28.

Следовательно, А₄> А₃> А₁> А₂. Или другими словами, по мнению экспертов наиболее приемлемым и осуществимым является создание специализированной системы. Это было сделано из-за необходимости оцифровки документов, контроля выполнения и получения заданий и т.д., чем в совокупности не обладало ни одно средство.

2.2. Математическая модель оценки издержек переводчика на посещение офиса ООО «Бюро переводов Полиглот» после реинжиниринга

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

· Временные затраты на нахождение в офисе t₁=0

· Количество поездок в офис в день = 1

В остальном исходные данные останутся теми же. Воспользуемся формулами (3,4) и данными таблицы 2, чтобы рассчитать издержки после внедрения предложений по оптимизации:

Параметрыt₂ = 20 мин и m₁= 31,6 руб. свои значения не поменяют.

Из формулы (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

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что по критерию поддержки выбранных типов моделей лидирующим является MSVisio 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).В оптимизированной модели добавлен новый механизм – это информационная система. Как это отразилось на выполнении бизнес-процессов рассмотрим далее.

Рисунок 11 – Контекстная диаграмма оптимизированной модели

Рисунок 12 – Диаграмма декомпозиции первого уровня

На диаграмме декомпозиции также только одно изменение – это новый механизм. Перейдем к подробному рассмотрению проблемных процессов.

Рисунок 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	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 – Физическая модель базы данных проектируемой информационной системы

Опишем добавленные сущности.

УслугиПоЗаданию. Сущность содержит информацию об услугах, которые ООО «Бюро переводов Полиглот» оказывает по конкретному договору:

· Код услуги – внешний ключ;

· Номер договора – внешний ключ;

· Количество;

· Статус оказания.

Исполнитель. Сущность, описывающая переводчиков, занятых выполнением задания:

· Табельный номер – внешний ключ;

· Номер договора – внешний ключ;

· Дата назначения;

· Статус участия.

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

CREATE TABLE Задание

(

Номер_договора INTEGER NOT NULL ,

Дата_выдачи DATE NULL ,

Дата_выполнения DATE NULL ,

Статус VARCHAR2(20) NULL

);

CREATE UNIQUE INDEX XPKЗадание ON Задание

(Номер_договора ASC);

ALTER TABLE Задание

ADD CONSTRAINT XPKЗадание PRIMARY KEY (Номер_договора);

CREATE TABLE Исполнитель

(

ДатаНазначения DATE NULL ,

СтатусУчастия VARCHAR2(20) NULL ,

Табельный_номер INTEGER NOT NULL ,

Номер_договора INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKИсполнитель ON Исполнитель

(Табельный_номер ASC,Номер_договора ASC);

ALTER TABLE Исполнитель

ADD CONSTRAINT XPKИсполнитель PRIMARY KEY (Табельный_номер,Номер_договора);

CREATE TABLE История_статустов

(

Дата DATE NOT NULL ,

СтатусБыл VARCHAR2(20) NULL ,

СтатусСтал VARCHAR2(20) NULL ,

);

CREATE UNIQUE INDEX XPKИстория_статустов ON История_статустов

(Дата ASC,Номер_договора ASC);

ALTER TABLE История_статустов

ADD CONSTRAINT XPKИстория_статустов PRIMARY KEY (Дата,Номер_договора);

CREATE TABLE Переводчик

(

Табельный_номер INTEGER NOT NULL ,

ФИО VARCHAR2(20) NULL ,

Квалификация VARCHAR2(20) NULL ,

Специализация VARCHAR2(20) NULL

);

CREATE UNIQUE INDEX XPKПереводчик ON Переводчик

(Табельный_номер ASC);

ALTER TABLE Переводчик

ADD CONSTRAINT XPKПереводчик PRIMARY KEY (Табельный_номер);

CREATE TABLE Услуга

(

Код_услуги INTEGER NOT NULL ,

Наименование VARCHAR2(20) NULL ,

Стоимость_за_единицу INTEGER NULL

);

CREATE UNIQUE INDEX XPKУслуга ON Услуга

(Код_услуги ASC);

ALTER TABLE Услуга

ADD CONSTRAINT XPKУслуга PRIMARY KEY (Код_услуги);

CREATE TABLE УслугиПоЗаданию

(

Код_услуги INTEGER NOT NULL ,

Номер_договора INTEGER NOT NULL ,

Количество INTEGER NULL ,

Статус VARCHAR2(20) NULL

);

CREATE UNIQUE INDEX XPKУслугиПоЗаданию ONУслугиПоЗаданию

(Код_услуги ASC,Номер_договора ASC);

ALTER TABLE УслугиПоЗаданию

ADD CONSTRAINT XPKУслугиПоЗаданию PRIMARY KEY (Код_услуги,Номер_договора);

CREATE TABLE Файл

(

Код_файла INTEGER NOT NULL ,

Шифрование INTEGER NULL ,

Файл BLOB NULL ,

Номер_договора INTEGER NOT NULL

);

CREATE UNIQUE INDEX XPKФайл ON Файл

(Код_файла ASC,Номер_договора ASC);

ALTER TABLE Файл

ADD CONSTRAINT XPKФайл PRIMARY KEY (Код_файла,Номер_договора);

ALTER TABLE Исполнитель

ADD (CONSTRAINT R_9 FOREIGN KEY (Табельный_номер) REFERENCES Переводчик(Табельный_номер));

ALTER TABLE Исполнитель

ADD (CONSTRAINT R_10 FOREIGN KEY (Номер_договора) REFERENCES Задание(Номер_договора));

ALTER TABLE История_статустов

ADD (CONSTRAINT R_2 FOREIGN KEY (Номер_договора) REFERENCES Задание(Номер_договора));

ALTER TABLE УслугиПоЗаданию

ADD (CONSTRAINT R_7 FOREIGN KEY (Код_услуги) REFERENCES Услуга(Код_услуги));

ALTER TABLE УслугиПоЗаданию

ADD (CONSTRAINT R_8 FOREIGN KEY (Номер_договора) REFERENCES Задание(Номер_договора));

ALTER TABLE Файл

ADD (CONSTRAINT R_1 FOREIGN KEY (Номер_договора) REFERENCES Задание(Номер_договора));

В данном листинге описаны необходимые DDL-процедуры, выполнение которых на сервере СУБД позволит автоматически создать спроектированную базу данных.

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

4.1 Проектирование модульной структуры информационной системы

Согласно данным, содержащимся в третьем разделе данной работы, разрабатываемая ИС представляет собой веб-приложение.

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

· сервер базы данных, хранящий информацию о деятельности предприятия и выдающий её по требованию других модулей;

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

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

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

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

Структура приложения должна содержать следующие элементы:

· модуль доступа к данным;

· модуль обработки данных;

· модуль предоставления данных пользователям.

Т.е. предполагается реализация шаблона проектирования, известного как MVC (Model-view-controller). Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонентатаким образом, чтобы модификация одного из компонентов оказывала минимальное воздействие на остальные.Данная схема проектирования часто используется для построения архитектурного каркаса, когда переходят от теории к реализации в конкретной предметной области.

Рисунок 18 - Связи в модели MVC

4.2 Выбор средств реализации модулей

Необходимо выбрать конкретные средства реализации указанных высокоуровневых модулей ИС.

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

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

Для работы с БД предлагается выбрать готовый сервер баз данных.

4.2.1 Выбор языка программирования

Для написания веб приложений возможно использование многих языков программирования. К наиболее распространённым языкам веб-программирования можно отнести PHP, Ruby, C# (всвязке с технологией ASP.NET), Java [14][15][16].

Для выбора конкретного языка применим метод попарных сравнений.

Метод анализа иерархий – методологическая основа для решения задач выбора альтернатив посредством их многокритериального рейтингования[7].

Метод позволяет оценить противоречивость данных и минимизировать ее.

Критерии для анализа:

· мультипарадигмальность;

· удобство типизации данных;

· сложность организации работы с памятью;

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

· наличие готовых программных модулей для веб-разработки.

Таблица 21 - Информация о языках программирования

Критерий	PHP	Ruby	C# (ASP.NET)	Java
Мультипаради-гмальность	Нет	Нет	Есть	Есть
Удобство типизации данных	Низкое	Низкое	Высокое	Высокое

Окончание таблицы 11

Документированность на русском языке	Средняя	Низкая	Очень высокая	Высокая
Сложность организации работы с памятью	Высокая	Средняя	Низкая	Низкая
Наличие готовых программных модулей для веб-разработки	Большое количество	Среднее количество	Очень большое число	Малое число

Сравнение критериев происходит согласно шкале относительной важности

1 - равная важность

3 - умеренное превосходство одного над другим

5 - существенное превосходство одного над другим

7 - значительное превосходство одного над другим

9 - очень сильное превосходство одного над другим

2, 4, 6, 8 - соответствующие промежуточные значения

Составим таблицу иерархии, в которой попарно сравним критерии:

Таблица 22 - Сравнение критериев оценки

Критерии	Мультипара-дигмальность	Удобство типизации данных	Работа с памятью	Документиро-ванность		Готовые модули	Оценка компонент собственного вектора	Нормализо-ванные оценки вектора приоритета
Мультипара-дигмальность	1	3	4	2		1	1,88818	0,32676
Удобство типизации данных	1/3	1	1/5	1/4		1/3	0,35395	0,06125
Работа с памятью	1/4	5	1	1	3		1,30259	0,22542
Документиро-ванность	1/2	4	1	1	3		1.43097	0,24764
Готовые модули	1	3	1/3	1/3	1		0.80274	0,13892
	Σ= 5.77843

Выполняем проверку согласованности критериев:

λ_max=1.01+0.98+1.47+1.14+1.16=5.76

ИС=(5.76-5)/(5-1)=0,19 – индекс согласованности критериев находится в рамках допустимых значений (0..0,2), значит можно продолжать анализ без корректировки предпочтений.

Далее попарно сравним альтернативу по каждому из критериев:

A - PHP

B – Ruby

С – C# (ASP.NET)

D – Java

Таблица 23 - Оценка по критерию мультипарадигмальности

	A	B	C	D	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
A	1	2	1/5	1/4	0.63096	0.12925
B	1/2	1	1/5	1/4	0.47818	0.09795
C	5	5	1	3	2.37144	0.48577
D	4	4	1/3	1	1.39765	0.2863
	Σ=4.88185

Таблица 24 - Оценка по критерию удобства типизации данных

	A	B	C	D	Оценка компонент собственного вектора	Нормализованные оценки вектораприоритета
A	1	1	3	3	1.55185	0.3533
B	1	1	3	3	1.55185	0.3533
C	1/3	1/3	1	1	0.64439	0.1467
D	1/3	1/3	1	1	0.64439	0.1467
	Σ=4.39248

Таблица 25 - Оценка по сложности работы с памятью

	A	B	C	D	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
A	1	1	1/2	1	0.87055	0.21092
B	1	1	1/2	1	0.87055	0.21092
C	2	2	1	2	1.51572	0.36724
D	1	1	1/2	1	0.87055	0.21092
	Σ= 4.12737

Таблица 26 - Оценка документированности на русском языке

	A	B	C	D	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
A	1	1	1/3	1/3	0.64439	0.14711
B	1	1	1/3	1	0.80274	0.18326
C	3	3	1	3	1.93318	0.44133
D	3	1	1/3	1	1	0.22829
	Σ= 4.38031

Таблица 27 - Оценка наличия готовых модулей для веб-разработки

	A	B	C	D	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
A	1	1/4	1/5	1/5	0.39811	0.08715
B	4	1	1/2	1	0.21892
C	5	2	1	1	1.58489	0.34696
D	5	2	1	1	1.58489	0.34696
	Σ= 4.56789

Результат выбора:

· В самую верхнюю строку переносим значения вектора приоритета для каждого критерия.

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

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

Таблица 28 - Расчет вектора глобального приоритета

Альтер-нативы	Мультипарадигмальность	Удобство типизации данных	Работа с памятью	Документирован- ность	Готовые модули	Глоб. Приори-теты
	Вектора приоритета
	0.32676	0.06125	0.22542	0.24764	0.13892
A	0.12925	0.3533	0.21092	0.14711	0.08715	0.15996
B	0.09795	0.3533	0.21092	0.18326	0.21892	0.17699
C	0.48577	0.1467	0.36724	0.44133	0.34696	0.40799
D	0.2863	0.1467	0.21092	0.22829	0.34696	0.25482

Значение глобального приоритет оказывается наибольшим для языка С. Значит, C# с ASP.NET наиболее полно соответствует предъявляемым нами требованиям.

4.2.2 Выбор серверов баз данных

Платформа .NETFramework, с использованием которой ведется разработка на языке C#, предоставляет технологию CodeFirst – возможность автоматической генерации БД на основе модели данных, описываемой в виде классов языка C#. Данный подход позволяет использовать БД без установки дополнительных серверов и поэтому наилучшим образом подходит для реализации локальной БД – при использовании CodeFirst .NetFramework использует встроенного поставщика данных, что избавляет от необходимости использования сторонних серверов БД.

4.3 Выбор технологий разработки ИС

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

Перечисленные задачи сводятся к выполнению над таблицами реляционной БД следующих элементарных действий: создание, модификацию, просмотр и удаление объектов. Сокращенно совокупность этих действий именуют CRUD (createreadupdatedelete). Конкретные механизмы, реализующие эти действия, входят в набор классов фреймворка .NET и скрыты от программиста.

Как уже было сказано, для разработки ИС выбран язык C#. Связанная с ним платформа .Net предоставляет множество технологий для создания различных приложений. Для веб-приложений, построенных по шаблону MVC, используется технология ASP.NET. Построение ASP.NET поверх .NET позволяет использовать огромное количество готовых классов при разработке. ASP.NET имеет преимущество в скорости по сравнению со скриптовыми технологиями, так как при первом обращении код компилируется и помещается в специальный кэш, и впоследствии только исполняется, не требуя затрат времени на парсинг, оптимизацию , и т. д.

Глава 5. Социальный аспект реализации веб-системы

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

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

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

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

С применением системы издержки времени сократятся на 17%, а финансовые издержки стабилизируются и всегда будут составлять не более 3%. Это также позволит взять компании расходы на транспорт под свою ответственность.

Глава 6. Технико-экономическое обоснование создания веб-системы многопользовательского доступа к документам

6.1. Описание целесообразности проектирования с точки зрения коммерческого использования

6.1.1. Описание предметной области

ООО «Бюро переводов Полиглот» оказывает своим клиентам следующие услуги:

1. Письменные переводы текста

· Перевод технической документации;

· Перевод переписки с сохранением конфиденциальности;

· Перевод эксплуатационных и проектных документов;

· Перевод медицинских документов;

· Перевод специализированной литературы и научных статей;

· Перевод документов для выезда заграницу.

2. Устные переводы

· Сопровождение иностранных визитёров;

· Перевод в реальном времени и сопровождение международных совещаний;

· Сопровождение граждан РФ на иностранных мероприятиях (выставки, форумы, деловые встречи);

· Перевод телефонных переговоров.

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

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

Таблица 29 – Количественная оценка эффективности деятельности отдела до внедрения новой ИС.

Наименование показателя	Количественный результат до внедрения	Максимально возможный результат	Снижение эффективности
Время доставки карты к врачу	5 мин.	1 мин.	83 %
Время заполнения карты	12 мин.	3 мин	50%.
Скорость обмена информацией	5 документов в час	20 документов в час	25%
Материальные затраты на организацию работы	10,000 в год	10,000 в год	0%
Материальные затраты на расходные материалы	20,000 в год	10,000 в год	50%

В таблице 29 показана количественная оценка эффективности деятельности отдела до внедрения ИС. Снижение эффективности показывает насколько снижается эффективность при невыполнении максимально допустимых требований. Для большей наглядности, снижение эффективности представлено в процентах.

Таблица 30 – Эффективность работы предприятия до и после внедрения ИС

Способы представления (обработки) информации		Результат
До внедрения	После внедрения	До внедрения	После внедрения
Преимущественно бумажный документооборот	Увеличилась доля электронного документооборота	Отсутствие надежной связи между сотрудниками	Высокая надежность связи
Ручной сбор и обработка информации	Сбор и обработка данных с помощью ИС	Низкая производительность труда	Высокая производительность труда
Дублирование информации в бумажных документах	Использование единой базы данных, содержащей упорядоченную информацию	Невысокая достоверность результатов решения задачи	Высокая достоверность результатов решения задачи

6.2. Расчет экономической эффективности проекта

6.2.1. Расчет затрат на функционирование предприятия до и после внедрения

Расходы по различным видам работающих определяются по формуле:

(6.1)

где n_i - численность персонала i - вида;

z_i - среднегодовая заработная плата работника i-го вида;

а_c - процент отчислений на социальное страхование, пенсионный фонд и фонд стабилизации (обычно a_c = 34%);

Z = 15500*12*(1+0,34) = 249240 руб.

6.2.2. Расчет экономии от увеличения производительности труда пользователя

Если пользователь при выполнении работы j-го вида с использованием новых информационных технологий экономит DТj часов в год, то повышение производительности труда p_j (в процентах) определяется по формуле:

р_j =(D Т_j /(t_j -DТ_j))100 (6.2)

Р_{сотрудник}= 187,5/(450-187,5)100 = 51.7%

где t_j – время за год, которое планировалось пользователю для выполнения работы j-го вида до внедрения информационных технологий (час).

Экономия, связанная с повышением производительности труда DР_п пользователя определяется по формуле:

DР_п = Z_пS Р_j/100 (5.3)

DР_{сотрудник} = 249240 *0,517= 128857

где Z_п - среднегодовая заработная плата пользователя.

Из полученных данных мы видим, что при денежной оценке обработанных сотрудником документов, экономия значительная. То есть, что до внедрения ИС врач-специалист тратил 249 240 руб., а после внедрения будет тратить 120 383 руб. Разница очевидна и говорит в сторону разрабатываемой ИС.

6.2.3. Стоимостная оценка проекта

Общая сумма затрат на оплату труда () определяется по форме, приведенной в таблице 6.3 .

Общая сумма затрат на оплату труда () определяется по формуле

С_тр = С_д Т_п (1 + а_с /100) (1 + а_д /100),

где С_д – дневная заработная плата проектировщика из расчета МРОТ (4611/21 =219,5);

Т_п– длительность этапа проектирования (50);

а_с – ставка единого социального налога (34%);

а_д – процент дополнительной заработной платы (20%).

С_тр= 219,5 × 40× (1 + 34/100) × (1 + 20/100) = 17648 руб.

Таблица 31 - Затраты на оплату труда

Категория работника

Квалификация

исполнителей

Трудоемкость разработки, чел/ч

Часовая ставка, руб./ч

Сумма, руб.

Проектировщик

Высшее образование

400

27,4

17648

Среднечасовая заработная плата разработчика рассчитывается по формуле ,

где ЗП_i – среднемесячная заработная плата разработчика, руб.;

ФРВ_i– среднемесячный фонд рабочего времени (приблизительно 100 часов в месяц).

Материально-техническое обеспечение процесса разработки. Расчет амортизационных отчислений используемой техники

Расчет амортизации оборудования проводиться по форме, представленной в таблице 32.

Таблица 32 - Расчет амортизационных отчислений

Наименование оборудования	Стоимость оборудования, руб.	Годовая норма амортизации, %	Время работы оборудования во время разработки, ч.	Сумма, руб.
Компьютер	18000	20	400	3600
Итого				3600

Норма амортизации рассчитана по формуле

где Т – срок службы оборудования.

Общая сумма амортизационных отчислений определяется по формуле

где – стоимость i-го оборудования, руб.;

– годовая норма амортизации i-го оборудования, %;

– время работы i-го оборудования за весь период разработки, ч;

– эффективный фонд времени работы i-го оборудования за год, ч/год;

– вид оборудования;

– количество оборудования.

Расчет затрат на электроэнергию

где М – паспортная мощность ЭВМ;

Т– время работы ЭВМ;

Ц_э – цена одного кВт/ч энергии;

К_и – коэффициент интенсивного использования (К_и = 0,8 – 0,9).

Затраты на оплату телематических услуг

Оплата телематических услуг (доступ к сети передачи данных и информационным системам, информационно-коммуникационных сетей, включая Интернет) определяется по соответствующим тарифным планам.

В рассматриваемом случае она составляет 500 рублей.

На основании результатов вышеуказанных расчетов формируется смета затрат на разработку программного продукта (таблица 33).

Таблица 33 - Смета затрат на разработку ПП

Статьи затрат	Сумма
Затраты на оплату труда	17648
Затраты на материально-техническое обеспечение	3600
Затраты на приобретение программного обеспечения	0
Затраты на оплату телематических услуг	500
Итого по смете	21748

6.3. Оценка экономического эффекта от внедрения

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

Э₀=Э_г - Е_н К_п,

где Э_г – годовая экономия,

К_п – капитальные затраты на автоматизацию,

Е_н – нормативный коэффициент, определяется как 1/Т, где Т – срок эксплуатации информационной системы.

Э₀= 128857– 1/3*21748= 121607 руб.

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

6.4. Выводы

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

Глава 7. Безопасность человеко-машинного взаимодействия при работе с проектируемой системой

7.1 Особенности функционального назначения информационной системы

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

7.3 Анализ надежности информационной системы

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

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

Таким образом, можно выделить основные события, которые должны быть предотвращены:

· Программный сбой;

· Аппаратный сбой;

· Некорректные действия пользователя.

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

1. Программный сбой:

· Ошибка MicrosoftSQLServer;

· Ошибки MicrosoftIISServer 2010;

· Ошибки OS;

· Внутренние ошибки ИС.

2. Аппаратный сбой:

· Сбой на сервере;

· Сбой на клиентском компьютере;

· Выход из строя локальной сети.

3. Некорректные действия пользователя:

· Невнимательность;

· Утомление;

· Отсутствие навыков работы с программой.

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

В качестве головного нежелательного события можно рассмотреть отказ в работе информационной системы агентства.

В процессе анализа рассмотренные причины отказа ИС рекламного агентства структурированы в виде дерева причин, разбитого на уровни декомпозиции.

Рисунок 19 - Уровень 1 «Сбой в работе ИС»

Рисунок 20 - Уровень 2 «Некорректные действия пользователя»

Рисунок 21 - Уровень 2 «Программный сбой»

Рисунок 22 - Уровень 2 «Аппаратный сбой»

7.4 Оценка эргономичности пользовательского интерфейса

Заполним таблицу для оценки пользовательского интерфейса разрабатываемой программы и двух ближайших аналогов (табл. 27).

Сравниваемые программные продукты:

А – Разрабатываемая ИС;

В – Redmine;

С – Wrike.

Таблица 34. Критерии и показатели оценки эргономичности пользовательского интерфейса программных продуктов

Критерии и показатели	А	В	С
1. Логичность компоновки элементов	Сумма баллов	Сумма баллов	Сумма баллов
1.1. Наличие и сохранение во всей программе единой системы группировки полей (поля и управляющие элементы должны быть выстроены по порядку выполнения действий в зависимости от требований предметной области и алгоритма работы пользователя, без привязки к структуре и последовательности физических таблиц данных)	5	5	5
1.2. Порядок заполнения полей (во всех окнах поля расположены по логике заполнения сверху вниз или слева направо)	4	5	4
1.3. Обоснованный порядок размещения пунктов списков (по алфавиту или в порядке убывания частоты использования)	4	5	5
1.4. Обоснованное соотношение между «детальностью» и «обобщенностью» выводимой на экран информации (нахождение компромисса между желанием вывести много записей одновременно и/или сразу увидеть детальную информацию по каждой из них)	3	4	4
1.5. Единство в выборе способа работы с однотипными данными (таблицы, списки, меню, консоль)	4	4	5
1.6. Видимое разделение основных и вспомогательных блоков информации	5	5	5
1.7. Видимое разделение редактируемых обязательных и необязательных, а также нередактируемых полей	3	4	5
1.8. Разделение задач: для каждой задачи открывается свое окно, одно окно предназначено для выполнения только одной задачи (поиск, ввод информации и т.д.)	3	4	5
1.9. Возможность совершать несколько различных действий (решать несколько задач) одновременно	3	5	4
1.10. Отсутствие перекрывающихся окон на экране	1	1	1
1.11. Отсутствие рядом расположенных кнопок с противоположным действием	1	1	1
1.12. Отсутствие дублирующих полей ввода	1	1	1
2. Интуитивность и ассоциативность диалогового режима	37	44	45
2.1. Продуманная навигация и целевая ориентация в программе: что надо сделать в следующий момент, очевидность каждого следующего шага действий	3	4	4
2.2. Наличие контекстных подсказок, меню дальнейших событий или объектов, запоминание типичных путей диалога	5	5
2.3. Наличие средств, позволяющих пользователям восстановить данные после ошибочных действий	3	4	4
2.4. Учет предметной области и профессиональных знаний пользователя (в программе должны быть те слова и графические образы, которые пользователь знает или обязан знать по характеру работы или занимаемой должности)	5	5	5
2.5. Возможность настройки интерфейса для пользователей с разным опытом работы с компьютером	0	2	2
2.6. Типичность интерфейса: использование стандартных элементов взаимодействия, их традиционное или общепринятое расположение	5	5	5
2.7. Постоянная возможность вызова главного меню (главной страницы)	1	1	1
2.8. Наличие механизмов поиска, средств листания и прокрутки при работе с большими фрагментами информации	5	5	5
2.9. Легкость и скорость обучения пользования программой, отсутствие необходимости специального обучения	5	5	5
3. Полнота реализации обратной связи с пользователем	31	36	36
3.2. Наличие сообщений о состоянии системы (обработка информации, загрузка данных, зависание программы...)	4	5	5
3.3. Отображение режима работы системы (автономного, штатного, защищенного и пр.)	0	1	1
3.4. Настраиваемое отображение значений важных для текущей задачи показателей	3	4	4
3.5. Отражение действий пользователя (нажатия клавиш, запуск процесса, динамика выполнения процесса, получение ожидаемого и иного результата)	5	5	5
3.6. Ясность и информативность сообщений системы	5	5	5
4. Визуальное оформление пользовательского интерфейса	17	20	20
4.2. Ограниченное использование цвета в оформлении элементов интерфейса соответствует целевому назначению программного продукта и учитывает продолжительность работы с ним пользователя	3	4	4
4.3. Использованные сочетания оттенков цвета совместимы	3	4	4
4.4. Контрастность объектов различения с фоном комфортная и не требует перенастройки дисплея	4	5	5
4.5. Шрифт основного текста и заголовков легко читаем или может быть изменен	3	5	5
4.6. Размер шрифта основного текста, подписей элементов интерфейса может быть увеличен или уменьшен пользователем	2	4	4
4.7. Единство стиля оформления (фона, формата заголовков и основного текста, пиктограмм)	5	5	5
Итоговая сумма баллов	102	127	128

7.5 Оценка напряженности процесса эксплуатации информационной системы

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

Таблица 35. Показатели напряженности трудового процесса до и после внедрения разрабатываемой ИС

Показатели напряженности трудового процесса	Класс условий труда
	Инженер - программист		Инженер - программист
	До	После	До	После
1. Интеллектуальные нагрузки
1.1. Содержание работы	2.0	1	2.0	1.0
1.2. Восприятие сигналов (информации) и их оценка	2	2	2	2
1.3. Распределение функций по степени сложности задания	3.2	3.1	2	2
1.4. Характер выполняемой работы	2	2	2	1
2. Сенсорные нагрузки
2.1. Длительность сосредоточенного наблюдения (% времени смены)	3.1	2	2	1
2.2.Плотность сигналов (световых, звуковых) и сообщений в среднем за 1 час работы	3.1	3.1	3.1	3.1
2.3. Число производственных объектов одновременного наблюдения	1	2	1	1
2.6. Наблюдение за экранами видеотерминалов (часов в смену): при буквенно-цифровом типе отображения информации: при графическом типе отображения информации:	2	3.1	1	2

Окончание таблицы 35

2.7. Нагрузка на слуховой анализатор (при производственной необходимости восприятия речи или дифференцированных сигналов)	1	1	1	1
2.8. Нагрузка на голосовой аппарат (суммарное количество часов, наговариваемое в неделю)	3.1	2	3.1	2
3. Эмоциональные нагрузки
З.1.Степень ответственности за результат собственной деятельности. Значимость ошибки	3.1	2	1	1
3.2. Степень риска для собственной жизни	1	1	1	1
3.3. Степень ответственности за безопасность других лиц	1	1	1	1
3.4. Количество конфликтных ситуаций, обусловленных профессиональной деятельностью, за смену	3.3	2	1	1
4. Монотонность нагрузки
4.1. Число элементов (приемов), необходимых для реализации простого задания или в многократно повторяющихся операциях	3.1	1	1	1
4.2. Продолжительность (в сек) выполнения простых заданий или повторяющихся операций	2	2	2	2
4.3. Время активных действий (в % к продолжительности смены). В остальное время – наблюдение за ходом производственного процесса	1	1	1	1
5. Режим труда и отдыха
5.1. Фактическая продолжительность рабочего дня	2	2	-	-
5.2. Сменность работы	1	1	-	-
5.3. Наличие регламентированных перерывов и их продолжительность	2	2	-	-
Общая оценка напряженности трудового процесса	3.1	2	2	2

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

7.6 Разработка мер профилактики и повышения безопасности человеко-машинного взаимодействия

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

· индивидуальные;

· организационные;

· технические;

· санитарно-гигиенические.

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

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

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

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

7.7 Выводы по разделу

В разделе «безопасность человеко-машинного взаимодействия» был проведен анализ безопасности и экологичности информационной системы для пользователя, при помощи которого были выявлены нежелательные события работы системы. В результате оценки работы информационной системы мы выяснили, что у нас допустимый (2 класс) условий труда

ЗАКЛЮЧЕНИЕ

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

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

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

Были предложены оптимизированные бизнес-процессы выдачи заданий и отправки их удаленному сотруднику. За счет этого удалось сократить издержки по времени на 17% и издержки по деньгам на 3%.

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

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

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

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