Разработка подсистемы управления проблемами распределенной системы управления телекоммуникационными услугами на базе платформы CPN TOOLS для Ставропольского филиала ОАО "ЮТК"

input (pp,ppp);

output (pp2);

action

((#1 pp, #2 pp, #3 pp, #4 pp, #5 pp, #6 pp, #7 ppp, #8 pp, #9 pp));

Рисунок 3.11 - Поиск решения в базе данных проблем

Затем проблема поступает в позицию «Saving info», а оттуда в переход «Save info», который сохраняет сведения о проблеме в базу данных проблем (рисунок 3.12).

Рисунок 3.12 - Сохранение информации в базе данных проблем

Далее проблема поступает в позицию «problem1», откуда, если решение было найдено, передаётся в переход «transmit1» (условие [#7 pp <> “”]), а если ответ не был найден (условие [#7 pp = “”]), то - в переход «Increase priorety» (рисунок 3.13).



Рисунок 3.13 - Переходы «Increase priorety» и «transmit1»

Из перехода «transmit1», через позицию «Answer», проблема поступает в переход «solve», а оттуда - в позицию «Solved» (рисунок 3.14).

Рисунок 3.14 - Переход «Solve»

В переходе «Increase priorety» увеличивается приоритет не решенной проблемы, которая потом передаётся в позицию «Problem with new priorety», а оттуда через переход «transmit2» в позицию «Searching for answer» (рисунок 3.15).

Код перехода «Increase priorety»:

input (pp);

output (pp2);

action

((#1 pp, #2 pp, #3 pp, #4 pp + 1, #5 pp, #6 pp, #7 pp, #8 pp, #9 pp));

Рисунок 3.15 - Переход «transmit2»

Из позиции «Searching for answer» проблема поступает в переход «tr», в котором выполняется эмуляция действий сотрудников компании. Далее проблема поступает в позицию «Splitter» (рисунок 3.16).

Код перехода «tr»:

input (pp);

output (ppp);

action

(if #6 pp = 3 then (#1 pp, #2 pp, #3 pp, #4 pp, #5 pp, #6 pp, “answer”, #8 pp, #9 pp)

else

if range.ran() = 1 then (#1 pp, #2 pp, #3 pp, #4 pp, #5 pp, #6 pp, “answer”, #8 pp, #9 pp)

else (pp));



Рисунок 3.16 - Переход «tr»

Из позиции «Splitter», если решение было найдено, проблема поступает в переход «Solved problem» (условие [#7 pp <> ««]), а оттуда в позицию «Solved». Если же решение не было найдено, то проблема поступает в переход «Unsolved problem» (условие [#6 pp+1 = #3 uu andalso #7 pp = “”]), который формирует запрос и отправляет его на следующий уровень (рисунок 3.17):

input (pp,uu);

output (rq);

action

((“problem”, #1 uu, #2 uu, (#1 pp, #2 pp, #3 pp, #4 pp, #5 pp, #6 pp+1, #7 pp, #8 pp, #9 pp)));



Рисунок 3.17 - Переходы «Unsolved problem» и «Solved problem»

Используемые цвета и переменные определены следующим образом:

colset UNIT = unit;

colset INT = int;

colset BOOL = bool;

colset STRING = string;

colset u = product STRING*STRING*INT*INT timed

colset p=STRING*STRING*STRING*INT*INT*INT*STRING*INT*INT timed;

colset r = product STRING*STRING*STRING*p timed;

colset range = int with 0..1;

var rq:r;

var pp:p;

var uu:u;

var pp2:p;

var ppp:p;

Цвет «u» предназначен для хранения информации о пользователях. Запись о пользователе имеет следующую структуру:

1) Имя - имя пользователя.

2) Пароль - пароль пользователя.

3) Уровень - уровень, на котором работает пользователь, число от 1 до 3.

4) User id - id пользователя.

Цвет «p» является записью о проблеме. Структура записи о проблеме следующая:

1) Имя - имя абонента или “auto” для проблем, добавленных Участком диагностики и ремонта.

2) Адрес - адрес поломки.

3) Тип - тип проблемы, используется для поиска решения проблемы в базе данных.

4) Приоритет - текущий приоритет проблемы.

5) Дата - дата создания записи.

6) Уровень - текущий уровень, число от 1 до 3.

7) Решение - решение проблемы.

8) Problem id - id проблемы.

9) User id - id пользователя, добавившего проблему, для проблем, добавленных Участком диагностики и ремонта, равно 0.

Цвет «r» представляет собой запрос. Запрос состоит из следующих полей:

1) Тип запроса - может принимать следующие значения:

- report - для запроса на создание отчёта;

- problem - для запроса на добавление новой проблемы;

- solve - для запроса на добавление решённой проблемы.

2) Имя - логин пользователя.

3) Пароль - пароль пользователя.

4) Проблема - запись о проблеме.

Цвет «range» необходим для генерации случайной величины. Переменная «rq» предназначена для хранения информации о запросе, с помощью этой переменной из позиций, хранящих фишки цвета «r», извлекаются и передаются запросы. Переменные «pp», «pp2» и «ppp» необходимы для осуществления операций с фишками цвета «p». Переменная «uu» нужна для извлечения и передачи из позиции «Users DB» фишек цвета «u».

3.6 Описание программного обеспечения проекта

Для реализации дипломного проекта использовался персональный компьютер с ОС Microsoft Windows 7. В качестве платформы для разработки использовалась CPN Tools 3.0.4. Эта программа позволяет моделировать телекоммуникационные системы. С помощью CPN Tools можно разрабатывать системы, производить отладку, генерировать отчёты. CPN Tools разрабатывается AIS Group из Eindhoven University of Technology. Программа состоит из трёх частей: симулятора, интерфейса пользователя и Access/CPN. Интерфейс распространяется под лицензией GNU GPL v.2, симулятор распространяется под двумя лицензиями - GNU GPL v.2 и четырёх пунктовой лицензией BSD, Access/CPN - под лицензией LGPL v.2, текст лицензий представлен в приложении 2. Существенным плюсом программы является её бесплатность, актуальная версия всегда доступна для загрузки по адресу http://cpntools.org [18]. Также сейчас ведётся подготовка к опубликованию исходных кодов программы.

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

В CPN Tools есть следующие панели инструментов:

- net - содержит инструменты для создания и сохранения сетей;

- create - содержит инструменты для создания различных элементов сети;

- auxiliary - содержит элементы для повышения наглядности модели;

- hierarchy - содержит инструменты для создания многоуровневых сетей;

- state Space - содержит инструменты для построения и анализа пространства состояний;

- simulation - содержит инструменты для выполнения и отладки модели;

- view - содержит инструменты для выбора масштаба и указания групп элементов;

- style - содержит инструменты для указания внешнего вида элементов модели.

3.7 Описание технического обеспечения проекта

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

Минимальные требования CPN Tools к техническому обеспечению следующие:

- процессор с тактовой частотой не ниже 1,5 ГГц;

- объём оперативной памяти не ниже 1 Гб;

- свободное место на жёстком диске 50 МБ.

В таблице 3.1 приведены характеристики компьютера, использованного при разработке.

Таблица 3.1 - Характеристики аппаратного обеспечения компьютера

Наименование	Характеристика
Процессор	Celeron Dual-Core CPU T3100 64-х разрядный, двуядерный , частота 1,9 ГГц
Оперативная память	2 Гб, DDR2
Видеокарта	Mobile Intel 4 Series Express Chipset Family
Жёсткий диск	320 Гб
Монитор	Разрешение - 1366х768; диагональ 15 дюймов
Оптический накопитель	TSSTcorp CDDVDW TS-L633C

Отсюда следует, что используемый компьютер удовлетворяет системным требованиям CPN Tools.

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

В данном разделе приведено обоснование необходимости разработки, преимущества от автоматизации процесса управления проблемами.

Приведены требования стандартов к организации бизнес-процессов на предприятии.

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

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

4. Описание подсистемы управления проблемами

4.1 Описание разработанной подсистемы управления проблемами

Разработанная подсистема правления проблемами предназначена для автоматизации работы всех уровней службы поддержки. Это позволит снизить время реакции на проблему, а значит, уменьшит потери от прекращения оказания услуги. В компании существует три уровня службы поддержки. Первый уровень представлен центром сообщений, сюда поступают сообщения пользователей о недоступности услуги. На этом уровне пользователю задаются стандартные вопросы, а также проверяется наличие наиболее часто встречающихся проблем. Также к первому уровню относится участок диагностики и ремонта, который представляет собой диагностическое оборудование, осуществляющее мониторинг состояния каналов передачи данных и оборудования. Второй уровень представлен группой технической поддержки, сюда попадают обращения клиентов, которым не смогли помочь на первом уровне. Здесь клиенту оказывают более квалифицированную помощь по поиску причин проблемы и путей её решения. Если же и на втором уровне проблема не была решена, то она передаётся на третий уровень, представленный линейно-техническими участками. Сотрудники этого уровня выезжают к клиенту и на месте проверяют доступность услуги и функционирование оборудования. Сотрудники третьего уровня службы поддержки осуществляют ремонт оборудования, замену повреждённых участков линий и т.п..

Рассмотрим подробнее составные части подсистемы управления проблемами. Для работы подсистемы у сотрудников всех уровней службы поддержки должно быть рабочее место, оснащённое персональным компьютером. Также необходим доступ к корпоративной сети. Помимо ПК, также требуется сервер базы данных проблем. Централизованное хранение информации о проблемах позволит получать информацию о любой известной проблеме. В программной части подсистемы можно выделить несколько составных частей. Запрос от сотрудника проходит идентификацию и аутентификацию. Для этого используется информация из базы данных пользователей. Данная БД уже реализована и является неотъемлемой частью всех подсистем автоматизированной системы компании. Затем запрос поступает в один из трёх блоков: блок генерации отчёта, блок сохранения информации о проблеме в базу данных, блок поиска решения среди уже известных проблем. В случае, если решение не было найдено, происходит эскалация проблемы, т.е. запрос отправляется сотруднику следующего уровня. Немало важным плюсом подсистемы является её обучаемость - чем больше решённых проблем содержится в базе данных проблем, тем быстрее будет осуществляться решение новых проблем.

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

4.2 Рекомендации по реализации системы

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

В настоящее время для автоматизации бизнес-процессов в компании применяется клиент-серверный подход. Существуют несколько серверов баз данных, использующих в качестве СУБД Oracle Enterprise 11. Код серверной части может быть написан либо на встроенном в СУБД языке программирования PL/SQL, либо на языке Java. Первый способ требует наличия вэб-сервера , в качестве которого используется Apache 2.2. Это простой способ, к тому же исторически в компании изначально поступали именно так. Однако, у такого подхода есть и недостатки, основным из которых является не высокая производительность вэб-серверов. Кроме того, так как весь код выполняется в один поток, то в случае возникновения ошибки может пострадать множество пользователей. При таком подходе клиентскую часть обычно реализуют в виде вэб-страницы. Это достаточно удобный способ, однако иногда возможностей браузера не хватает. Второй способ заключается в написании так называемых «сервлетов» на языке программирования Java. Это позволяет выполнять код в несколько потоков, а также более удобно взаимодействовать с другими серверами. Такой подход начал применятся недавно, однако, уже сейчас значительная часть подсистем переписана на язык Java. Клиентская часть в таких случаях обычно также реализуется на языке Java, что снимает с разработчика браузерные ограничения. Минусом такого подхода является больший объём исходных кодов и их сложность.

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

Таким образом, предпочтительней использовать язык Java и на стороне клиента, и на стороне сервера. Также необходим отдельный сервер для базы данных проблем. Это увеличит надёжность системы и её быстродействие.

4.3 Руководство пользователя

Рассмотрим способы использования разработанной модели.

Для начала работы с моделью следует открыть файл с исходным кодом. Для этого должна быть установлена актуальная версия (не ниже 3.0.4) программы CPN Tools. После открытия модели программа сразу же начнёт проверять синтаксис модели [4, 5]. По мере этого процесса, у объявлений и объектов оранжевая аура начнёт меняться сначала на жёлтую, а потом исчезнет вовсе. Оранжевый цвет ауры означает, что проверка элемента ещё не началась. Жёлтый цвет значит, что проверка осуществляется в данный момент времени. Отсутствие ауры говорит о корректности элемента. Если же аура светится красным, то значит, что в данном элементе была обнаружена ошибка. Если же аура продолжает светиться оранжевым, то это может говорить об отсутствии необходимых определений, например, подписей у дуг. Главное окно программы представлено на рисунке 4.1. После окончания проверки синтаксиса, можно приступать к работе с моделью.

Рисунок 4.1 - Главное окно программы CPN Tools

Для выполнения модели нужно использовать один из инструментов из панели «Sim» (рисунок 4.2).

Рисунок 4.2 - Панель инструментов «Sim»

Инструменты этой панели позволяют:

- вернуться в исходное состояние;

- остановить выполнение модели;

- выполнить переход с выбранными параметрами фишки;

- выполнить один переход (трассировка модели);

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

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

- выполнить текст как код на языке ML.

Для наглядности проведём трассировку модели.

Рассмотрим маркировку позиций в начальный момент времени (исходное состояние).

В позиции «Client» находятся фишки, соответствующие проблемам (рисунок 4.3).

Рисунок 4.3 - Позиция «Client» в начальный момент времени

В позиции «Users PC» находятся фишки, соответствующие запросам (рисунок 4.4).

Рисунок 4.4 - Маркировка позиции «Users PC» в начальный момент времени

В позиции «Devices» находятся фишки, соответствующие проблемам, возникшим в оборудовании (рисунок 4.5).

Рисунок 4.5 - Маркировка позиции «Devices» в начальный момент времени

В позиции «Users DB» хранятся фишки, содержащие данные о пользователях (рисунок 4.6).

Рисунок 4.6 - Маркировка позиции «Users DB» в начальный момент времени

В позиции «Problems DB» хранятся записи о проблемах (рисунок 4.7).

Рисунок 4.7 - Маркировка позиции «Problems DB» в начальный момент времени

Таким образом, позиции «Client», «Devices» и «Users PC» являются входными позициями системы. Позиция «Users DB» хранит данные обо всех пользователях, имеющих доступ к подсистеме управления проблемами. Позиция «Problems DB» в начальный момент времени содержит информацию обо всех уже известных проблемах. Все остальные позиции в исходном состоянии не содержат фишек.

Выполним трассировку модели.

Возьмём одну фишку из позиции «Client» и переместим её в позицию «Users PC», при этом выполнится переход «Set priorety», который установит приоритет, а также сформирует запрос (рисунок 4.8).

Рисунок 4.8 - состояние модели после одного шага

Одна из фишек переместилась в позицию «Users PC», при этом изменив свой цвет на «r», также изменилась и временная метка фишки. Так как временная метка этой фишки увеличилась, она не может перемещаться, пока модельное время не сравняется с её временной меткой. Теперь возьмём другие фишки из позиции «Users PC» и переместим их в позицию «request» (рисунок 4.9).



Рисунок 4.9 - состояние модели после трёх шагов

Теперь в позиции «request» находятся две фишки, у которых после перехода «Identification Autontification» временные метки равны 3. Переместим оставшиеся в позиции «Client» фишки в позицию «Users PC». Теперь переместим фишки из позиции «Devices» в позицию «Diag. dev.», при этом выполнится переход «Transaction to diag. dev.», который ничего не делает, но нужен для передачи информации о проблемах от оборудования до устройств диагностики (рисунок 4.10).

Рисунок 4.10 - состояние модели после семи шагов

Затем переместим фишки из позиции «Diag. dev.» в позицию «Problem», при этом выполнится переход «Select priorety», который установит приоритет проблем в зависимости от их типов, а также увеличит временные метки фишек (рисунок 4.11).



Рисунок 4.11 - состояние модели после девяти шагов

Теперь текущее модельное время равно 1, а количество выполненных шагов - 9. Таким образом, теперь можно переместить фишку, которая использовалась самой первой. После этого переместим одну из фишек из позиции «Problem» позицию «Saving info», при этом, в зависимости от того, найдено решение в базе данных или нет, выполнится переход «Answer found» (рисунок 4.12) или «Answer found» (рисунок 4.13). У фишки, которая пройдёт через переход «Answer found» изменится поле решения. Также оба перехода увеличивают временную метку фишки на 10, это время необходимо для поиска информации в базе данных проблем.

Рисунок 4.12 - состояние фишки после перехода «Answer found»



Рисунок 4.13 - состояние фишки после перехода «Answer not found»

Переместим фишку из позиции «request» через переход «Request for solve». Этот переход выполнит сохранение информации об уже решённой проблеме в базу данных (рисунок 4.14), а также отправит фишку в позицию «Solved», которая является выходной позицией модели (рисунок 4.15).

Рисунок 4.14 - сохранение информации о проблеме в базу данных

Рисунок 4.15 - Выходная позиция «Solved»

Теперь выполним переход «Request for report» (рисунок 4.16).



Рисунок 4.16 - состояние фишки после перехода «Request for report»

Затем выполним переход «Request for problem», который извлечёт из запроса проблему (рисунок 4.17).

Рисунок 4.17 - состояние фишки после перехода «Request for problem»

Переведём в эту же позицию и остальные фишки, соответствующие запросу о новой проблеме. Затем переведём фишки через переход «Save info» (рисунок 4.18), который выполнит сохранение информации о проблеме в базу данных и увеличит временные метки фишек на 3.



Рисунок 4.18 - состояние фишек после перехода «Saving info»

Затем фишка, для которой было найдено решение, сможет пройти через переходы «transmit1» и «solve», а также через промежуточную позицию «Answer» и попадёт в выходную позицию «Solved». Фишка же, для которой не было найдено решение, переместится через переход «Increase priorety», который увеличит приоритет фишки, а также увеличит её временную метку на 1, в позицию «Problem with new priorety» (рисунок 4.19).

Рисунок 4.19 - состояние фишки после перехода «Increase priorety»

Затем эта фишка через ничего не делающий переход «transmit2» попадает в позицию «Searching for answer», а оттуда в переход «tr», который выполняет эмуляцию действий пользователя, случайным образом решая проблему. Оттуда фишка поступает в позицию «Splitter» (рисунок 4.20).

Рисунок 4.20 - состояние фишки после перехода «tr»

Затем, в зависимости от того, была проблема решена пользователем или нет, она поступает или в переход «Solved problem», который сохраняет информацию о проблеме в базу данных и передаёт фишку в выходную позицию «Solved», или в переход «Unsolved problem», который формирует запрос, подставляя из базы данных имя и пароль нужного пользователя, после чего отправляет проблему на второй уровень (рисунок 4.21).

Рисунок 4.21 - состояние проблемы после поступления на второй уровень

Теперь для фишки, содержащей запрос на создание отчёта, выполним переход «Making report», который сформирует отчёт по указанной проблеме и передаст его в выходную позицию «Solved», а также увеличит временную метку фишки на 60. В конечном состоянии позиция «Solved» содержит все проблемы (рисунок 4.22), а позиция «Problems DB» содержит информацию о разных этапах обработки каждой проблемы (рисунок 4.23).

Рисунок 4.22 - состояние позиции «Solved» в конечный момент времени

Рисунок 4.23 - состояние позиции «Problems DB» в конечный момент времени

За время трассировки модели было совершенно 76 шагов, на это понадобилось 98 единиц модельного времени.

4.4 Руководство разработчика

CPNT Tools позволяет легко моделировать даже сложные системы. Рассмотрим подробнее процесс разработки в этой среде.

Все сети состоят из элементов трёх типов: позиций, переходов и дуг [4, 5]. Эти инструментов доступны на панели инструментов «Create».

На рисунке 4.24 представлена позиция. Каждая позиция обладает именем, а также следующими атрибутами: типом позиции, начальной маркировкой [3]. Тип позиции должен соответствовать одному из объявленных цветов. Начальная маркировка представляет собой конструктор фишек, находящихся в позиции в начальный момент времени.

Рисунок 4.24 - Позиция и её атрибуты

Переходы также обладают рядом атрибутов: условие запуска, временная задержка и выполняемое действие. Условие запуска определяет условия, при выполнении который переход осуществляется, условие должно быть булевым выражением, и может использовать переменные входных дуг перехода. Временная задержка указывается в виде @+n, где n - величина задержки. Каждый переход может выполнять некоторое действие. Код действия будет вызываться каждый раз при срабатывании перехода. Если типы переменных на входных и выходных дугах перехода различаются, то действие должно преобразовывать типы. На рисунке 4.25 представлен переход и его атрибуты.



Рисунок 4.25 - Переход и его атрибуты

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

Используемые цвета и переменные определяются в левой части окна, пункте «Declarations» (рисунок 4.26).

Рисунок 4.26 - Описание цветов и переменных

Создать новоё описание можно выбрав в контекстном меню пункт «New Decl». Можно создавать описания цветов, переменных и функций. Для описания цвета используется ключевое слово «colset», после которого указывается название цвета, знак «=«, а затем следует описание цвета. Переменные описываются с помощью ключевого слова «var», за которым следует знак «:», а потом указывается цвет (тип) переменной. Ключевое слово «fun» используется для объявления функций.

Для обратной связи CPN Tools использует систему аур. Аура - цветной фон элемента. Цвет ауры показывает состояние элемента. Оранжевый цвет говорит о том, что проверка синтаксиса ещё не началась или о том, что описание элемента не полное. Например, если тип позиции, то она будет иметь оранжевую ауру. Жёлтый цвет ауры указывает, что проверка корректности элемента идёт в настоящий момент времени. Если аура красного цвета, то это значит, что была обнаружена ошибка. Отсутствие ауры говорит о корректности элемента. Моделирование работы сети возможно только если у всех элементов и описаний отсутствует аура. В случае возникновения ошибки над элементом или в левом нижнем углу главного окна программы появится сообщение об ошибке. Наиболее частым сообщением об ошибке является «Type mismatch», которое говорит о несоответствии типов переменных. Также частыми являются сообщения об опечатках в коде: забытые точки с запятой, отсутствие скобок.

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

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

Разработанная подсистема управления проблемами позволяет эффективно решать задачи по обработке возникающих ошибок. Приведены рекомендации по реализации подсистемы. Наиболее эффективным будет использование в качестве сервера программы на языке Java, этот же язык рекомендуется использовать и на стороне клиента. Так как часть подсистем используют JVM, устанавливать дополнительно ничего не потребуется. Хотя это и приведёт к некоторому усложнению кода, но взамен, программа получится более гибкой и лёгкой в поддержке.

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

Платформа CPN Tools является удобным средством для быстрой разработки и эмулирования процесса работы системы.

5. Охраны труда и БЖД на предприятии

5.1 Анализ основных опасных и вредных факторов на рабочем месте

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

Рассмотрим основные требования к ПЭВМ и помещениям с ПЭВМ. Эти требования определены в СанПин 2.2.2_2.4.1340-03. Данный нормативный документ устанавливает саниторно-эпидемиологические требования к проектированию, изготовлению и эксплуатации ПЭВМ, проектированию и эксплуатации помещений с ПЭВМ, организации рабочих мест, а также описывает рекомендуемые комплексы упражнений для снятия усталости глаз. Согласно этим требованиям мощность мягкого рентгеновского излучения от ПЭВМ не должна превышать 1 мкЗв/час на расстоянии 0,05 м, конструкция ПЭВМ должна обеспечивать возможность поворота корпуса с фиксацией в заданном положении. Дизайн ПЭВМ должен предусматривать окраску корпуса в спокойные мягкие тона. Корпус ПЭВМ, клавиатура и другие блоки и устройства ПЭВМ должны иметь матовую поверхность с коэффициентом отражения 0,4-0,6 и не должны иметь блестящих деталей. Конструкция монитора должна предусматривать регулирование яркости и контрастности. Окна в помещениях, предназначенных для эксплуатации ПЭВМ должны быть оборудованы жалюзи или занавесями. В образовательных и культорно-развлекательных учреждения для детей не допускается размещение мест пользования ПЭВМ в цокольных и подвальных помещениях. Площадь на одно рабочее место пользователей ПЭВМ с монитором на базе ЭЛТ должна быть не менее 6 м2 , для ПЭВМ с плоскими экранами не менее 4,5 м2. Для внутренней отделки интерьера помещений должны использоваться материалы с коэффициентом отражения для потолка - 0,7-0,8; для стен - 0,5-0,6; для пола - 0,3-0,5. Помещения должны быть оборудованы защитным заземлением. Рабочие столы следует размещать таким образом, чтобы мониторы были ориентированы боковой стороной к световым проемам, чтобы естественный свет падал преимущественно слева. Искусственное освещение в помещениях для эксплуатации ПЭВМ должно осуществляться системой общего равномерного освещения. Освещенность на поверхности стола в зоне размещения рабочего документа должна быть 300 - 500 лк. Освещение не должно создавать бликов на поверхности экрана. Освещенность поверхности экрана не должна быть более 300 лк. В качестве источников света при искусственном освещении следует применять преимущественно люминесцентные лампы и компактные люминесцентные лампы. При размещении рабочих мест с ПЭВМ расстояние между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора) должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м. Экран видеомонитора должен находиться от глаз пользователя на расстоянии 600 - 700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов.

Таблица 5.1 Допустимые значения уровней звукового давления

Уровни звукового давления в октавных полосах со среднегеометрическими частотами	Уровни звука в дБА
31,5 Гц	63 Гц	125 Гц	250 Гц	500 Гц	1000 Гц	2000 Гц	4000 Гц	8000 Гц
86 дБ	71 дБ	61 дБ	54 дБ	49 дБ	45 дБ	42 дБ	40 дБ	38 дБ	50

Измерение уровня звука и уровней звукового давления проводится на расстоянии 50 см от поверхности оборудования и на высоте расположения источника звука.

Таблица 5.2 Допустимые уровни ЭМП, создаваемых ПЭВМ

Наименование параметров	ВДУ ЭМП
Напряженность электрического поля	в диапазоне частот 5 Гц - 2 кГц	25 В/м
	в диапазоне частот 2 кГц - 400 кГц	2,5 В/м
Плотность магнитного потока	в диапазоне частот 5 Гц - 2 кГц	250 нТл
	в диапазоне частот 2 кГц - 400 кГц	25 нТл
Электростатический потенциал экрана видеомонитора	500 В

Таблица 5.3 Допустимые визуальные параметры устройств отображения информации

N п/п	Параметры	Допустимые значения
1	Яркость белого поля	Не менее 35 кд/кв. м
2	Неравномерность яркости рабочего поля	Не более +/- 20%
3	Контрастность (для монохромного режима)	Не менее 3:1
4	Временная нестабильность изображения (непреднамеренное изменение во времени яркости изображения на экране дисплея)	Не должна фиксироваться
5	Пространственная нестабильность изображения (непреднамеренные изменения положения фрагментов изображения на экране)	Не более 2 x 1E(-4L), где L - проектное расстояние наблюдения, мм

Организация работы с ПЭВМ осуществляется в зависимости от вида и категории трудовой деятельности.

Виды трудовой деятельности разделяются на 3 группы: группа А - работа по считыванию информации с экрана ВДТ с предварительным запросом; группа Б - работа по вводу информации; группа В - творческая работа в режиме диалога с ПЭВМ. При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ПЭВМ следует принимать такую, которая занимает не менее 50% времени в течение рабочей смены или рабочего дня.

Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ПЭВМ, которые определяются: для группы А - по суммарному числу считываемых знаков за рабочую смену, но не более 60 000 знаков за смену; для группы Б - по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40 000 знаков за смену; для группы В - по суммарному времени непосредственной работы с ПЭВМ за рабочую смену, но не более 6 ч за смену.

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

Таблица 5.4 Суммарное время регламентированных перерывов

Категория работы с ПЭВМ	Уровень нагрузки за рабочую смену при видах работ с ПЭВМ	Суммарное время регламентированных перерывов, мин.
	группа А, количество знаков	группа Б, количество знаков	группа В, ч	при 8-часовой смене	при 12-часовой смене
I	до 20 000	до 15 000	до 2	50	80
II	до 40 000	до 30 000	до 4	70	110
III	до 60 000	до 40 000	до 6	90	140

5.2 Общие мероприятия по обеспечению безопасности на рабочем месте

Рассмотрим рабочее помещение. Помещение распложено на втором этаже в пятиэтажном здании. Здание расположено на перекрёстке двух оживлённых дорог. В помещение находятся пять рабочих мест, всё они оснащены ПЭВМ. Схему расположение рабочих мест в помещении можно увидеть на рисунке 5.1.



Рисунок 5.1 Схема помещения

В качестве искусственного освещения применяются люминесцентные лампы, равномерно расположенные на потолке. Высота потолков в помещении составляет 3 метра. Оконный проём в помещении один, однако он достаточно большой. Оконный проём начинаётся на высоте 1 метра над полом и заканчивается под потолком. Окна выходят на север, что соответствует пункту 3.2 СанПин 2.2.2_2.4.1340-03. На одно рабочее место приходится площадь 5 м2, что также соответствует требованиям (не менее 4,5 м2). Высота рабочего стола составляет 725 мм. Рабочие стулья регулируются по высоте. В соответствии с пунктом 3.7 СанПин 2.2.2_2.4.1340-03 помещение оборудовано защитным заземлением. Все рабочее места расположены боком к окну: два рабочих места правым боком, три - левым. Расстояние от ВДТ до пользователя соответствует норме - 60-70 см. Сотрудники в данном помещении относятся к категории ВIII (творческая работа с ПЭВМ, до 6 часов за рабочую смену). Разряд зрительных работ - II (размер различаемых объектов - 0,15-0,30 мм).

5.3 Расчёт освещённости

Согласно СНиП 23-05-95 естественное освещение делится на боковое, верхнее, комбинированное. Рассчитаем необходимую площадь оконных проёмов при боковом освещения для данного помещения:

, (5.1)

где Sо - площадь световых проемов;

S - освещаемая площадь, S = 10 * 7 = 70 м2;

Еn, - нормируемое значение КЕО (коэффициента естественной освещенности) Еn = Ен * m, где m - коэффициент, учитывающий климат и ориентацию окон. m = 0,9 (помещение находится во втором световом поясе, ориентация окон на север);

Ен = 1,5%, в соответствие с разрядом работ (II);

Еn = 1,5 * 0,9 = 1,35%;

Кз - коэффициент запаса, определяется по СНиП 23-05-95 и равен 1,5;

- световая характеристика окна, определяется конструкцией окон и согласно СНиП II-4-79 равна 37;

Кзт - коэффициент затенения;

Кзт = 1 (нет противостоящих затеняющих помещений);

To- общий коэффициент светопропускания, рассчитываемый по формуле:

To =T1 * T2 * T3 * T4, (5.2)

где T1 - коэффициент светопропускания материала, T1 = 0,9;

T2 - коэффициент учёта потерь света в переплётах светового проёма, T2=0,75;

T3 - коэффициент учёта потерь света в несущих конструкциях, T3=0.8;

T4 - коэффициент учёта потери света в солнцезащитных устройствах, T4=1;

T = 0,9*0,75*0,8*1= 0,54.

R1 - коэффициент повышения КЕО при боковом естественном освещении благодаря свету, отражённому от поверхности помещения, определяется по формуле:

R1=, (5.3)

где Rп, Rс, Rпп - коэффициенты отражения света от пола, стен и потолка соответственно;

Sп, Sс, Sпп - площади пола, стен и потолка соответственно.

R1=; (5.4)

Sо= м2; (5.5)

Таким образом, необходимая площадь окон составляет 42,7 м2, однако реально имеется лишь 14 м2. Следовательно, необходимо предусмотреть искусственное освещение.

СНиП 23-05-95 определяет минимальную освещённость равной 300 лк.

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

F =, (5.6)

где F - световой поток;

Е - нормируемая минимальная освещенность, Е = 300 лк;

Кз - коэффициент запаса, равный 1,5;

S - освещаемая площадь, составляющая 70 м2;

Z - коэффициент неравномерности освещения, равный 1,1;

С - коэффициент использования излучаемого светильниками светового потока на расчетной площади;

N - число светильников;

n - число ламп в светильнике.

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

i =, (5.7)

где А - длина помещения - 10 м;

В - ширина помещения - 7 м;

h - высота подвеса, которая определяется по формуле:

h = H - hр - hс;

где:

Н - высота помещения - 3 м;

hр - высота рабочей поверхности - 0,75 м;

hс - высота от потолка до нижней части лампы - 0.15 м.

h = 3 - 0,75 - 0,15 = 2,1 м.

i = = 1,96 (5.8)

Для светильников ОД (общего освещения диффузный) при индексе помещения 1,96 и коэффициентах отражения от потолка и стен 70,50%, С = 0,41.

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

N = (5.9)

Наиболее приемлемыми для помещения являются люминесцентные лампы ЛБ (белого света) мощностью 80 Вт. Нормальный световой поток лампы ЛБ-80

F = 5400 люмен (лм).

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

N = = 7,76 (5.10)

Таким образом, потребуется 8 светильников.

Фактически в помещении имеется 8 светильников ОД по 2 лампы ЛБ-80 в каждом.

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

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

В помещении производственный микроклимат соответствует СанПиН 2.2.2_2.4.1340-03. Производственное освещение удовлетворяет требованиям СНиП 23-05-95.

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

6.1 Определение трудоёмкости выполняемых работ

Для определения большинства составляющих трудоёмкости нужно найти общее число операторов Чоп.общ по формуле:

(6.1)

где Чоп - число операторов, ед.;

Ксз - коэффициент сложности задачи;

Ккп - коэффициент коррекции программы, учитывающий новизну проекта.

В данном случае, число операторов составит примерно Чоп=300; коэффициент сложности примем равным 1,8; коэффициент коррекции программы равен 0,1. Таким образом:

Чоп. Общ= 300*1,8(1+0,1)= 594 оп. (6.2)

Затраты труда на описание задачи То примем ориентировочно То=30 чел.-ч.

Затраты труда на исследование предметной области Ти с учётом описания и квалификации программистов определяются по формуле:

(6.3)

где Чоп. общ - общее число операторов, ед;

Кузт - коэффициент увеличения затрат труда, вследствие недостаточного описания задачи;

Чоп. и - количество операторов, приходящееся на 1 чел.-ч (для данного вида работ Чоп. и=75…85 ед/чел.-ч);

Kk - коэффициент квалификации программиста (определяется в зависимости от стажа работы: до 2-х лет - 0,8).

Таким образом, Ти=(594*1,2)/(75*0,8)= 11,88 чел.-ч.

Затраты труда на разработку алгоритма решения задачи Та рассчитываются по фомуле:

(6.4)

где Чоп. а - количество операторов, приходящееся на 1 чел.-ч (для данного вида работ Чоп. а=20…25 ед/чел.-ч).

Та= 594/20=37,125 чел.-ч. (6.5)

Затраты труда на составление программы по готовому алгоритму Тп рассчитываются по формуле:

(6.6)

где Чпп - количество операторов, приходящееся на 1 чел.-ч (для данного вида работ Чпп=20…25 ед/чел.-ч).

Тп=594/(20*0,8)= 37,125 чел.-ч. (6.7)

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

(6.8)

где Чоп. отл - количество операторов, приходящееся на 1 чел.ч (для данного вида работ Чоп. отл=4…5 ед/чел.-ч).

Тотл=594/(4*0,8)= 185,625 чел.-ч. (6.9)

Затраты труда на подготовку документации по задаче Тд определяются по формуле:

Тд=Тдр+Тдо, (6.10)

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

(6.11)

где Чоп. др - количество операторов, приходящееся на 1 чел.-ч (для данного вида работ Чоп др=15…20 ед/чел.-ч).

Затраты труда на редактирование, печать и оформление документов:

Тдо=0,75*Тдр. (6.12)

Тдр=594/(15*0,8)= 49,5 чел.-ч. (6.13)

Тдо=0,75*49,5=37,125 чел.-ч. (6.14)

Тд=49,5+37,125=86,625 чел.-ч. (6.15)

Тпо=То+Ти+Та+Тп+Тотл+Тд (6.16)

Тпо=30+11,88+37,125+37,125+185,625+86,625=388,38 чел.-ч. (6.17)

Полученное общее значение трудоёмкости Тпо корректируется с учётом уровня языка программирования: Т=Тпо*kкар, где

Kкар - коэффициент, учитывающий уровень языка программирования (kкар=0,8…1,0).

Т=380,955*0,8=310,704 чел.-ч. (6.18)

Таблица 6.1 - Определение трудоёмкости

Виды затрат труда	Трудоемкость, чел.- ч
Затраты труда на описание задачи, То Затраты труда на исследование предметной области, Ти Затраты труда на разработку блок-схемы, Та Затраты труда на программирование, Тп Затраты труда на отладку программы, Тотл Затраты труда на подготовку документации, Тд	30 11,88 37,125 37,125 185,625 86,625
Итого затраты труда на разработку программного продукта, Тпо	388,38

6.2 Расчёт затрат на разработку программного продукта

Общая сумма затрат на материальные ресурсы и запасные части (ЗМ) определяется по формуле:

(6.19)

где Pi - расход i-го вида материального ресурса, натуральные единицы;

Цi - цена за единицу i-го вида материального ресурса, руб.

i - вид материального ресурса;

n - количество видов материальных ресурсов.

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

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

(6.20)

где ЧСi - часовая ставка i-го работника, руб.;

Тi - трудоемкость разработки автоматизированной информационной системы, чел.ч;

i - категория работника;

n - количество работников, занятых разработкой автоматизированной информационной системы.

Часовая ставка работника может быть рассчитана по формуле:

(6.21)

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

ФРВi - месячный фонд рабочего времени i-го работника, час (по данным бухгалтерии).

Дополнительная заработная плата производственного персонала Ззп.д рассчитывается по формуле:

(6.22)

где Кдоп.зп - коэффициент дополнительной заработной платы.

(Кдоп.зп = 0,1…0,2).

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

Затраты на потребляемую энергию Зэ определяются по формуле:

Зэ = Рв * tв * цэ, (6.23)

где Рв - мощность ЭВМ, кВт;

tв - время работы вычислительного комплекса, ч;

цэ - стоимость 1 кВт-ч электроэнергии, руб/кВт-ч.

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

tв = ап * (Тп + Тдо + Тотл) * kкор, (6.24)

где ап - коэффициент, учитывающий затраты времени на профилактические работы (ап = 1,15).

Затраты на техническое обслуживание и текущий ремонт рассчитываются по формуле:

, (6.25)

где Кв - балансовая стоимость вычислительной техники;

tв.г - годовой фонд рабочего времени вычислительной техники

(tв.г = 2112ч).

б = 4% норма отчислений на ремонт.

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

Зобщ = Зм + Ззп.о + Ззп.д + Зсн + Зэ + Зр, (6.26)

Таблица 6.2 - Основная заработная плата персонала

Категория работника	Трудоемкость разработки, чел.ч	Часовая ставка, руб./ч.	Сумма, руб.
ИТР	310,704	114	35420,256
ИТОГО основная заработная плата	35420,256

управление проблема алгоритм программа cpn

Таблица 6.3 - Себестоимость создания автоматизированной информационной системы

Статья затрат	Сумма, руб.
Расходы на материалы и запасные части, Зм	0
Основная заработная плата производственного персонала, Ззп.о	35420,256
Дополнительная заработная плата производственного персонала, Ззп.д	3542,0256
Отчисления на социальные нужды, Зсн	13325,1003
Затраты на электроэнергию, Зэ	377,9037
Затраты на амортизацию и ремонт вычислительной техники, Зр	226,40625
Итого затрат, Зобщ	52891,69185

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

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

, (6.27)

где Э - стоимостная оценка результатов применения программного продукта в течение года, руб.;

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

Приток денежных средств в процессе использования программного продукта в течение года может составить:

, (6.28)

где Зручн - затраты на ручную обработку информации в руб.;

Завт. - затраты на автоматизированную обработку информации, руб.;

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

, (6.29)

где tp - время, затрачиваемое на обработку информации вручную, ч;

цч - цена одного часа работы оператора, руб.;

kd - 1…2 - коэффициент, учитывающий дополнительные затраты времени на логические операции.

(6.30)

где ta - затраты времени на автоматизированную обработку информации, ч.

Зруч=6*10000*2=120000; (6.31)

Завт=4*10000*1=40000; (6.32)

Э=120000-40000+10000=90000; (6.33)

П=90000-52891,69185=37108,30815. (6.34)

6.4 Оценка основных технико-экономических показателей проекта

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

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

Чистый дисконтированный доход (ЧДД) ? характеризует превышение суммарных денежных поступлений над суммарными затратами для данного проекта с учетом неравномерности эффектов (затрат, результатов), относящихся к различным моментам времени.

Чистый дисконтированный доход от использования программного продукта определяют по формуле:

(6.35)

где: п - расчетный период, год;

Пk - прибыль от использования программного продукта за k-й год его эксплуатации, руб.;

Е - норма дисконта;

К - капиталовложения при внедрении программного продукта.

Для признания проекта эффективным с точки зрения инвестора, необходимо, чтобы чистый дисконтированный доход проекта был положительным. При проведении сравнительной оценки предпочтение следует отдать проекту с большим значением ЧДД (при выполнении условия его положительности). Очевидно, что при ЧДД > 0 проект следует принять, при ЧДД < 0 отвергнуть, а при ЧДД = 0 проект не прибылен, но и не убыточен.

ЧДД=20000/(1+0,2)+30000/(1+0,2)+40000/(1+0,2)+50000/(1+0,2)-

- 52891,69185=63774,9748 (6.35)

Срок окупаемости ? время, за которое поступления от производственной деятельности предприятия покрывают затраты на инвестиции. Срок окупаемости измеряется в годах или месяцах.

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

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

(6.36)

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

Э=(20000+30000+40000+50000)/4=35000 (6.37)

Ток=52891,69185/35000=1,51 (6.38)

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

Выполненный проект экономически эффективен благодаря низким капиталовложениям (52891,69185) и высокой экономической эффективности (37108,30815). Чистый дисконтированный доход так же говорит об экономической выгодности проекта. Основные результаты представлены в таблице 6.4.

Таблица 6.44 - Основные технико-экономические показатели разрабатываемого проекта

Основные технико-экономические показатели проекта	ед. измерения	Значение показателя
Итоговая трудоемкость разработки	чел-ч.	310,704
Полные затраты на создание программного продукта	руб.	52891,69185
Годовой эффект от внедрения программного продукта	руб.	37108,30815
Чистый дисконтированный доход от использования программного продукта	руб.	63774,9748
Срок окупаемости проекта	год	1,51

Заключение

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

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

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

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

В компании всё ещё есть не автоматизированные процессы, что в современном мире недопустимо. Также часть подсистем морально устарела и уже не соответствует требованиям бизнеса. Также из-за наличия различных подходов к реализации таких подсистем, отсутствует стандартный интерфейс. Более того, клиентская часть некоторых подсистем реализована в браузере, некоторых в виде приложения на языке Java, а некоторых в виде макросов к Microsoft Office. Это приводит к усложнению обучения сотрудников пользованию системой. Также это снижает удобство работы - сотрудники вынуждены пользоваться различными подсистемами, мало связанными или не связанными друг с другом вовсе. Однако, работы по улучшению ситуации ведутся постоянно: устаревшие подсистемы переписываются в соответствии с новыми требованиями, также подсистемы постепенно переносят на платформу Java.