Автоматизированная система оптимизации оборота локомотивов через сортировочную станцию
Описание работы сортировочной станции и процесса работы диспетчера. Разработка автоматизированной системы, позволяющей обеспечить моделирование процессов движения локомотивов и поездов на железной дороге и оптимизировать привязку локомотивов к поездам.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 01.10.2017 |
Размер файла | 2,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Данный язык программирования разработан специально для платформы .NET Microsoft. Синтаксис Object Pascal основан на синтаксических конструкциях языков программирования Turbo Pascal и Visual Basic.
Основные особенности Object Pascal:
- указатели больше не нужны, как правило, в них нет необходимости (однако если потребуется - возможности для работы с указателями предусмотрены);
- управление памятью производится автоматически;
- предусмотрены встроенные синтаксические конструкции для работы с перечислениями, структурами, свойствами классов;
- полная поддержка программных интерфейсов [11].
1.8.3 Выбор СУБД
В качестве системы управления базами данных выбрана СУБД Oracle Database 10g Express Edition. СУБД Oracle Database является реляционной СУБД, поддерживает SQL (структурированный язык запросов) и может применяться в качестве SQL-сервера. Это означает, что общаться с сервером можно на языке SQL: клиент посылает серверу запрос, тот его обрабатывает и отдает клиенту только те данные, которые были получены в результате этого запроса. Тем самым клиенту не требуется выкачивать данные и производить вычисления, как, например, в Microsoft Access.
Oracle Database - это программное обеспечение (ПО) с открытым кодом, его можно свободно изучать и изменять. Пакет распространяется на условиях General Public License (GPL), его можно бесплатно загрузить из Интернета [12] для некоммерческого применения.
Основные преимущества Oracle Database:
- многопоточность, поддержка нескольких одновременных запросов;
- оптимизация связей с присоединением многих данных за один проход;
- записи фиксированной и переменной длины;
- гибкая система привилегий и паролей;
- гибкая поддержка форматов чисел, строк переменной длины и меток времени;
- интерфейс с языками C и Perl, PHP;
- быстрая работа, масштабируемость;
- пакет распространяется на условиях GPL;
- быстрая поддержка транзакций через механизм InnoDB.
1.9 Выбор и обоснование комплекса технических средств
1.9.1 Расчет емкости ОЗУ
Для расчета объема ОЗУ, необходимого для нормальной работы системы, воспользуемся формулой (1.1):
(1.1)
где - объем оперативной памяти, необходимый для нормальной работы операционной системы.
- объем оперативной памяти, необходимый для нормальной работы системы;
- объем кэша для хранения данных, загружаемых в оперативную память при работе системы.
- объем памяти, используемой системой управления базами данных.
Расчет проведем, исходя из предположения, что в качестве операционной системы (ОС) используется наиболее распространенные в настоящее время ОС Windows XP/Vista/Seven.
= 100 Мб.
Согласно формуле, объем памяти, необходимый для хранения программ определяется объемом памяти, который занимает автоматизированная система «Оптимизация оборота локомотивов».
Для хранения системы необходимо 1,1 Мб.
Таким образом, получаем, что:
= 1,1 Мб.
Опытным путем установлено, что для хранения атрибутивных данных в памяти системе требуется 6 Мб.
= 6 Мб.
Oracle Database может быть настроен на использование любого объема оперативной памяти. Минимальный объем, необходимый для нормальной системы - 65 Мб. Рекомендуемый объем, необходимый для работы АС - 300 Мб. Расчет будем вести исходя из минимального объема.
= 65 Мб.
Таким образом, общий объем ОЗУ составляет
= 100 + 1,1 + 6 + 80 + 65 = 252.1 Мб.
1.9.2 Расчет емкости дискового пространства
Для расчета емкости дискового пространства, необходимого для нормальной работы системы, воспользуемся формулой (1.2):
(1.2)
где - объем дискового пространства, необходимого для хранения файлов операционной системы. = 1100 Мб.
- объем дискового пространства, необходимого для хранения файлов системы. = 1.1 Мб.
- объем дискового пространства, необходимого для хранения данных. = 620 Мб.
- объем дискового пространства, необходимого для хранения файлов СУБД. = 230 Мб.
Таким образом, общий объем дискового пространства составляет:
= 1100 + 1.1 + 620 + 230 = 1951.1 Мб.
С учетом роста размера операционной системы, необходимости дискового пространства для файлов подкачки, роста базы данных рекомендованный минимальный объем дискового пространства составляет 10 Гб.
1.9.3 Расчет времени реакции системы
Для расчета времени реакции системы воспользуемся формулой (1.3):
(1.3)
- время, затрачиваемое процессором на выполнение команд;
- время, затрачиваемое при обращении к жесткому диску для считывания блоков данных;
- время, затрачиваемое системой на вывод информации на экран монитора.
Так как время реакции не является критическим параметром для данной системы, то его определение проводилось опытным путем. Результаты показали, что система отвечает требованиям, указанным в задании при частоте процессора 800 МГц.
1.9.4 Минимальные и рекомендованные характеристики технических средств
Для работы системы понадобится операционная система Windows XP/2000/Vista/Seven, Oracle Database 10g Express Edition. При расчете требований учитывались потребности только автоматизированной информационной системы «Оптимизация оборота локомотивов».
Минимальные требования:
- объем оперативной памяти - 256 МБ;
- объем дискового пространства - 2 ГБ;
- частота процессора - 800 МГц;
- монитор с разрешением экрана от 800х600;
- клавиатура;
- мышь.
Рекомендованные требования:
- объем оперативной памяти - 512 МБ;
- объем дискового пространства - 3 ГБ;
- частота процессора - 2000 МГц;
- монитор с разрешением экрана от 1024х768;
- клавиатура;
- мышь.
2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
2.1 Архитектура автоматизированной системы
Для реализации автоматизированной системы «Оптимизация оборота локомотивов» выбрана двухуровневая клиент-серверная архитектура (толстый клиент). Данный выбор дополнительно обусловлен следующими достоинствами двухуровневой архитектуры:
- предоставляется возможность многопользовательской работы с системой;
- нет необходимости в сервере приложений, к которому предъявлялись бы очень высокие требования производительности;
- толстый клиент обладает широким функционалом в отличие от тонкого клиента;
- предоставляется возможность работы даже при обрывах связи с сервером;
- высокое быстродействие.
Таким образом, автоматизированная система разделена на два взаимодействующих модуля:
- сервер базы данных: СУБД Oracle;
- клиент: диалоговое desktop-ориентированное приложение.
2.2 Структура данных
2.2.1 Логическая модель базы данных
В процессе изучения предметной области нами была создана логическая модель взаимосвязи основных сущностей базы данных. На рисунке 2.1 представлена логическая модель взаимосвязи основных сущностей:
- «Тяговое_плечо»;
- «Локомотив»;
- «Привязка»;
- «Поезд»;
- «Маршрут»;
- «Перегон_маршрута»;
- «Путь»;
- «Станция»;
- «Операции_с_локомотивом»;
- «Операции_с_поездом»;
- «Перегон»;
- «Перегон_плеча»;
- «Депо».
На логическом уровне можно установить следующие связи между сущностями:
- идентифицирующую связь один-ко-многим;
- неидентифицирующую связь один-ко-многим;
Созданная модель базы данных имеет 9 неидентифицирующих связей один-ко-многим и 8 идентифицирующих связей один-ко-многим.
2.2.2 Физическая модель базы данных
На основании разработанной нами логической модели базы данных (Рисунок 2.1) мы создаем физическую модель базы данных автоматизированной системы оптимизации оборота локомотивов (Рисунок 2.2).
Указаны основные таблицы базы данных, атрибуты и ключи, и их типы данных, а также подробно показаны виды и типы связей между таблицами.
2.2.3 Расчет объема занимаемой памяти
Рассчитаем максимальный объем памяти, занимаемой БД. Для этого проанализируем объем памяти, занимаемой каждой записью каждой таблицы БД, и максимальное число записей в таблицах БД (таблицы 2.1 - 2.13).
Рисунок 2.1 - Логическая модель взаимосвязей основных сущностей
Рассчитаем максимальный объем памяти, занимаемой БД. Для этого проанализируем объем памяти, занимаемой каждой записью каждой таблицы БД, и максимальное число записей в таблицах БД и найдем их сумму, а также сумму памяти всех связей между таблицами. Рассчитанная сумма всех таблиц и связей и будет размер максимальной оббьем памяти.
Рисунок 2.2 - Физическая модель базы данных
Таблица 2.1 - Shoulder
Название поля |
Тип |
Размер (в байтах) |
|
Id_shoulder |
Integer |
2 |
|
Id_depo |
Integer |
2 |
|
Размер записи |
4 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
4000 |
Таблица 2.2 - Locomotive
Название поля |
Тип |
Размер (в байтах) |
|
Id_locomotive |
Integer |
2 |
|
Id_shoulder |
Integer |
2 |
|
Id_way |
Integer |
2 |
|
Type |
Varchar (40) |
40 |
|
Power |
Integer |
2 |
|
Technical_condition |
Datetime |
8 |
|
Technical_condition_2 |
Datetime |
8 |
|
Размер записи |
64 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
64000 |
Таблица 2.3 - Привязка
Название поля |
Тип |
Размер (в байтах) |
|
Id_linking |
Integer |
2 |
|
Id_locomotive |
Integer |
2 |
|
Id_train |
Integer |
2 |
|
Id_way |
Integer |
2 |
|
Id_shoulder |
Integer |
2 |
|
Time |
Datetime |
8 |
|
Direction |
Varchar (20) |
20 |
|
Размер записи |
38 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
38000 |
Таблица 2.4 - Поезд
Название поля |
Тип |
Размер (в байтах) |
|
Id_train |
Integer |
2 |
|
Id_way |
Integer |
2 |
|
Massa |
Integer |
2 |
|
ESR_start |
Integer |
2 |
|
Serial_number |
Integer |
2 |
|
ESR_end |
Integer |
2 |
|
Размер записи |
12 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
12000 |
Таблица 2.5 - Rout
Название поля |
Тип |
Размер (в байтах) |
|
Id_rout |
Integer |
2 |
|
Id_train |
Integer |
2 |
|
Размер записи |
4 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
4000 |
Таблица 2.6 - Stage_rout
Название поля |
Тип |
Размер (в байтах) |
|
Id_stage |
Integer |
2 |
|
Id_rout |
Integer |
2 |
|
Размер записи |
4 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
4000 |
Таблица 2.7 - Way
Название поля |
Тип |
Размер (в байтах) |
|
Id_way |
Integer |
2 |
|
Id_station |
Integer |
2 |
|
Specialization_way |
Varchar (40) |
40 |
|
Размер записи |
44 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
44000 |
Таблица 2.8 - Operation_Tr
Название поля |
Тип |
Размер (в байтах) |
|
Id_train |
Integer |
2 |
|
Time_operation1 |
Datetime |
8 |
|
Time_operation2 |
Datetime |
8 |
|
Id_operation |
Integer |
2 |
|
Id_way |
Integer |
2 |
|
Размер записи |
22 |
||
Максимальное количество записей |
100000 |
||
Максимальный размер таблицы |
2200000 |
Таблица 2.9 - Operation_Loc
Название поля |
Тип |
Размер (в байтах) |
|
Id_locomotive |
Integer |
2 |
|
Time_operation1 |
Datetime |
8 |
|
Time_operation2 |
Datetime |
8 |
|
Id_operation |
Integer |
2 |
|
Id_way |
Integer |
2 |
|
Id_shoulder |
Integer |
2 |
|
Размер записи |
24 |
||
Максимальное количество записей |
100000 |
||
Максимальный размер таблицы |
2400000 |
Таблица 2.10 - Station
Название поля |
Тип |
Размер (в байтах) |
|
Id_station |
Integer |
2 |
|
ESR |
Integer |
2 |
|
Name_station |
Varchar (40) |
40 |
|
Размер записи |
44 |
||
Максимальное количество записей |
4000 |
||
Максимальный размер таблицы |
44000 |
Таблица 2.11 - Depo
Название поля |
Тип |
Размер (в байтах) |
|
Id_depo |
Integer |
2 |
|
Id_station |
Integer |
2 |
|
Name_depo |
Varchar2 (60) |
60 |
|
Specialization_depo |
Varchar2 (60) |
60 |
|
Размер записи |
124 |
||
Максимальное количество записей |
100 |
||
Максимальный размер таблицы |
12400 |
Таблица 2.12 - Stage
Название поля |
Тип |
Размер (в байтах) |
|
Id_stage |
Integer |
2 |
|
Time_move_1 |
Datetime |
8 |
|
Time_move_2 |
Datetime |
8 |
|
Name_stage |
Varchar (90) |
9 |
|
Размер записи |
108 |
||
Максимальное количество записей |
1000 |
||
Максимальный размер таблицы |
108000 |
Таблица 2.13 - Stage_shoulder
Название поля |
Тип |
Размер (в байтах) |
|
Id_stage |
Integer |
2 |
|
Id_shoulder |
Integer |
2 |
|
Размер записи |
4 |
||
Максимальное количество записей |
10000 |
||
Максимальный размер таблицы |
40000 |
Таким образом, максимальный объем памяти, занимаемой БД, можно рассчитать как сумму максимальных размеров всех таблиц БД.
VБД = 4000 б + 64000 б + 38000 б + 12000 б + 4000 б + 4000 б + 44000 б + 2200000 б + 2400000 б + 44000 б + 12400 б + 108000 б + 40000 б = 4853.90625 Кб = 4,74 Мб.
2.3 Разработка алгоритмов
После анализа предметной области, в частности процесса оптимизации оборота локомотивов через сортировочную станцию, разработаны алгоритмы, представленные на рисунке 2.3 - 2.8.
2.3.1 Алгоритм определения времени прихода локомотива на сортировочную станцию
Опишем работу алгоритма представленного на рисунке 2.3. На первом этапе идёт процесс инициализации данных о локомотиве, определяется его местоположение. Идёт проверка: текущее местоположение локомотива не должно быть сортировочной станцией, иначе алгоритм прекращает свою работу. Далее мы знаем перегон на котором сейчас находится поезд, и знаем время отправления его с начала перегона, сохраняем это в переменную Т0.
На втором этапе алгоритма мы входим в цикл, условием выхода из которого текущее местоположение равно сортировочной станции. В цикле заводится переменная Т1 в которую мы сохраняем сумму времени подхода локомотива по перегону и времени его простоя на станции. При выходе из цикла мы имеем точное время, которое необходимо для прохождения локомотива от данной точки до сортировочной станции , оно хранится в переменной Т1.
На заключительном этапе мы складываем время полученное в результате работы цикла Т1 и время отправления его с перегона Т0 и получаем Т - время его прихода на станцию.
2.3.2 Алгоритм определения типа локомотива
На рисунке 2.3 приведена схема алгоритма «Определение типа локомотива».
Данный алгоритм проверяем тип локомотива по параметрам, и разбивает по спискам. В начале мы загружаем данные о локомотиве из БД АСУ СТ. Затем с помощью алгоритма вычисляем дату окончания действия ТО2, среднестатистическое значение срока годности ТО» двое суток. Зная дату прохождения ТО» и время его годности вычисляем дату окончания его действия. Далее следует проверка, сравнение текущей даты и даты окончания ТО2: если срок истек или подходит к концу то локомотив заносят в список идущих в депо для прохождения технического обслуживания. Если с ТО 2 всё в порядке та же проверка следует для ТО1. При его истечении локомотив направляется на прохождение ТО1 прямо на сортировочной станции. Далее происходит проверка типа локомотива указанного в документации, возможно 2 варианта. Данный локомотив следует через станцию транзитом , и тогда он заносится в список транзитных. Или же он пришел и идёт в расформирование на данной станции, тогда он заносится в список свободных локомотивов.
Рисунок 2.3 - Схема алгоритма определения времени прихода локомотива на сортировочную станцию
Рисунок 2.4 - Схема алгоритма определения типа локомотива
2.3.3 Алгоритм проверки технического состояния локомотива
На рисунке 2.5 приведена схема алгоритма «проверка технического состояния локомотива». Этот алгоритм вычисляет, годен ли данный локомотив для прохождения по данному маршруту. Возможна ситуация что техническое состояние локомотива не дает ему дойти до конца маршрута и заканчивается на середине. Чтобы избежать поломки локомотива или ситуации что он будет простаивать на путях в ожидании технической помощи, с помощью данного алгоритма вычисляем список годных. В начале идёт загрузка данных и параметров локомотива из БД АСУ СТ. Вычисляется дата окончания срока действия ТО. Затем процедура: находит конец маршрута и вычисляет дату прихода локомотива или же дату прихода локомотива на следующую сортировочную станцию, находящуюся по маршруту.
Далее идёи сравнение полученных результатов: если дата окончания действия ТО больше то локомотив заносится в список локомотивов пригодных для использования по маршруту.
2.3.4 Алгоритм проверки длинны маршрута поезда и величины тягового плеча локомотива
На рисунке 2.6 приведена схема алгоритма «Проверка длины маршрута и величины его тягового плеча». Каждый локомотивов имеет своё тяговое плечо: набор станций, по котором возможно его движение. Локомотив не должен выходить за эти границы, если ситуация требует его выхода, так как маршрут выходит за границы, следует его заменить. С помощью данного алгоритма определяется список локомотивов пригодных и не пригодных для использования по данному маршруту.
В начале загружаются параметры локомотивов из БД АСУ СТ, а так же топология путей и станций. Берется конкретный маршрут следования поезда, начинается цикл с первой станции до последней. Выбираем n станцию маршрута, проверяем, принадлежит ли она списку станций из тягового плеча конкретного локомотива. Если результат положительный, то так проходим весь маршрут и определяем локомотив в список пригодных для использования.
Рисунок 2.5 - Схема алгоритма проверки технического состояния локомотива
2.3.5 Алгоритм нахождения оптимального соотношения мощности локомотива и массы поезда
На рисунке 2.7 приведена схема алгоритма «Нахождения оптимального соотношения массы поезда и мощности локомотива». Основной целью оптимизации является уменьшение времени, потраченное на принятие решения и экономии энергетических ресурсов: топлива, энергии затраченное на перевозку груза. Следовательно, нашей целью будет нахождение оптимального соотношения массы поезда и мощности локомотива. Данный алгоритм выполняет поставленную задачу.
Имеется список локомотивов чьи параметры: техническое состояние и длинна тягового плеча позволяют буксировать состав по маршруту. На первом этапе мы первому локомотиву присваиваем значение min , затем заходим в цикл где проверяется возможности локомотива буксировать состав.
Масса поезда должна быть меньше мощности локомотива, иначе выбираем следующий по списку. Далее выбранный локомотив сравнивается с принятым за min и если его мощность меньше, то присваиваем ему значение min. В результате на выходе алгоритма имеем: локомотив с оптимальным значением мощности для данного состава.
2.3.6 Алгоритм нахождения всех маршрутов проходящих через сортировочную станцию
Работа сортировочной станции начинается с определения всех маршрутов прилегающих к ней. Алгоритм прохождения всех путей и маршрутов создан на основе алгоритма Дейкстры в ширину.
Для начала мы берём первый перегон первого маршрута, который исходит из нашей сортировочной станции. На первом шаге мы считаем количество маршрутов исходящих из самой станции и заносим в массив номера первых перегонов.
Рисунок 2.6 Схема алгоритма проверки длинны маршрута поезда и величины тягового плеча локомотива
Рисунок 2.7 Схема алгоритма нахождения оптимального соотношения мощности локомотива и массы поезда
На втором шаге мы берем последовательно каждый маршрут и проверяем его на ветвление, если у нас маршрут разделяется то мы создаем новый маршрут, сохраняя в нём все преведущие перегоны и добавляем новый. Если маршрут не имеет ветвей больше одной просто добавляем новый перегон к списку перегонов и переходим к следующему маршруту. Условием выхода из цикла будет условие захождения в железнодорожный тупик, прихода на сортировочную станцию или же если сумма времени подхода по перегонам входящим в маршрут будет больше 12 часов.
2.4 Функционирование системы
2.4.1 Функциональная схема системы
Принцип структурного проектирования основан на алгоритмической декомпозиции предметной области, которая предполагает выделения в системе некоторого фиксированного набора функций, каждый из которых может уточняться и состоять из некоторого фиксированного набора функций.
Структурная схема системы - это устойчивая во времени совокупность взаимосвязей между ее элементами или компонентами. Структура системы предполагает вложенность элементов одной системы в другую. Более мелкая система - это подсистема [13].
Система состоит из следующих подсистем:
- подсистема управления (меню) - осуществляет общее управление другими подсистемами;
- подсистема аутентификации - осуществляет разграничение прав доступа;
- подсистема ведения базы данных - предназначена для редактирования, фильтрации и сортировки данных;
- подсистема формирования отчетов - предусматривает возможность формирования и печати документов и вывод;
- справочная подсистема - предоставляет необходимую информацию о системе и ее функциональности;
Рисунок 2.8 Схема алгоритма нахождения всех маршрутов проходящих через сортировочную станцию
- подсистема просмотра - позволяет просматривать информацию с использованием фильтров;
- подсистема визуализации - отображает рабочий процесс в удобном для пользователя виде.
На рисунке 2.9 представлена функциональная схема системы.
Рисунок 2.9 - Функциональная схема системы
2.4.2 Демонстрация работы системы
При входе в систему появляется стартовое диалоговое окно отображенное на рисунке 2.10, в котором пользователь должен пройти аутентификацию.
Если имя пользователя и пароль верны, появится главная экранная форма, изображенная на рисунке 2.11.
Рисунок 2.10 - Форма аутентификации пользователя
Рисунок 2.11 - Главная форма
Сформируем задачи, которые нам нужно реализовать:
- создать новую запись,
- добавить в нее информацию,
- сохранить в базу данных АСУ СТ,
- сформировать привязку,
- вывести отчёт.
Для того чтобы создать новую запись в базу данных через окно формы, на функциональной панели навигатора необходимо нажать кнопку «+» и в появившейся строчке (рисунок 2.11) указать данные по локомотиву. Все поля обязательны для заполнения.
После корректного указания данных и нажатия на кнопку «\/» в списке локомотивов главной экранной формы появится новый локомотив (рисунок 2.11).
Рисунок 2.12 - Форма привязки локомотивов к поездам ( четное направление хода)
На рисунке 2.12 приведена форма привязки локомотива к поездам (чётное направление хода), Форма имеет 2 поля: первое служит для вывода результата работы программы а второе отображает все свободные локомотивы и их параметры.
Окно Привязки отражает поля:
- номер поезда,
- ЕСР станции отправления,
- порядковый номер отправления,
- ЕСР станции прибытия,
- время отбытия,
- номер пути,
- номер локомотива.
Внизу присутствует меню быстрого доступа, прокрутки списка, удаления старых и добавления новых записей.
Также отображается окно свободных локомотивов , которые мы можем привязать в ручную. Используя пункты меню «Правка», мы можем создать привязку локомотива к поезду или убрать существующую привязку по нашему усмотрению.
3. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ОПТИМИЗАЦИИ ОБОРОТА ЛОКОМОТИВОВ
Технико-экономическое обоснование разработки проводится с целью количественного и качественного доказательства экономической целесообразности создания и развития автоматизированной системы оптимизации оборота локомотивов, а также для определения организационно-экономических условий ее эффективного функционирования.
В ходе дипломного проектирования рассмотрены следующие системы, имеющие схожий функционал:
- «Автоматизированная система управления станцией «АСУС» от ОАО "АГАТ-системы управления";
- «Автоматизированная система управления работы сортировочной станцией ».
Автоматизированная система «АСУС» предназначена для:
- автоматизации технологических процессов по обработке вагонопотоков на сортировочной станции;
- создания динамической вагонной модели состояния приемоотправочных, сортировочных и других путей станции;
- организации грузовой работы станции;
- ведения архива вагонно-отправочной модели станции с глубиной хранения 7 лет;
- решения прикладных задач станционной отчетности;
- информационного обмена с системой верхнего уровня.
Однако, несмотря на свой мощный функционал и высокую стоимость, система не имеет функции оптимизации привязки локомотива к поезду.
Автоматизированная система управления работы сортировочной станцией (АСУСС) также не умеет решать поставленную задачу.
Поэтому принято решение о необходимости разработки и внедрения автоматизированной системы оптимизации оборота локомотивов.
Для обоснования экономической целесообразности разработки автоматизированной системы оптимизации оборота локомотивов выполнены расчеты следующих показателей:
- единовременные затраты на разработку;
- минимальная цена разработки;
- единовременные затраты на внедрение;
- экономический эффект от создания.
По результатам проведения вышеперечисленных расчетов определяется экономическая эффективность разработки операционной системы, на основании которой делается вывод о целесообразности ее создания.
3.1 Планирование и организация процесса разработки
Организация процесса разработки системы выполняется по следующему плану:
- составление перечня работ, определение их последовательности и взаимосвязи;
- определение трудоемкости и продолжительности каждого вида работ;
- составление линейного графика;
- расчет продолжительности разработки;
- составление плана-графика выполнения работ.
Разработкой системы занимался один человек - инженер. В качестве заработной платы взят средний показатель оклада специалиста в области разработки программного и аппаратного обеспечения в городе Самара по состоянию на 2011 год, что составило 150 рублей за один час.
Для расчета трудоемкости использован метод экспертной оценки. Продолжительность работ определена по формуле:
, (3.1)
- продолжительность i-й работы, дн.;
- трудоемкость i-й работы, чел. дн.;
- количество исполнителей i-й работы.
Так как в каждом виде работ участие принимает один специалист, то продолжительность работы равна ее трудоемкости:
= . (3.2)
Трудоемкости каждого вида работ представлены в таблице 3.1.
Рисунок 3.1 - Линейный график работ
Таблица 3.1 - Перечень работ и оценки продолжительности работ
Наименование работы |
Специалист |
Трудоемкость (чел. дн.) |
Продолжительность (дней) |
|
Изучение и анализ предметной области |
Инженер |
15 |
15 |
|
Разработка ТЗ на систему |
Инженер |
5 |
5 |
|
Разработка архитектуры системы |
Инженер |
5 |
5 |
|
Разработка функциональной модели системы |
Инженер |
12 |
12 |
|
Разработка алгоритмов |
Инженер |
30 |
30 |
|
Разработка логической модели базы данных |
Инженер |
35 |
35 |
|
Разработка физической модели базы данных |
Инженер |
10 |
10 |
|
Разработка интерфейса системы |
Инженер |
5 |
5 |
|
Создание базы данных |
Инженер |
10 |
10 |
|
Отладка системы и ее тестирование |
Инженер |
15 |
15 |
|
Оформление документации |
Инженер |
8 |
8 |
|
Сдача системы |
Инженер |
5 |
5 |
На основе данных из таблицы 3.1 можно построить линейный график выполнения работ (рисунок 3.1).
3.2 Расчет затрат на разработку системы
Затраты на разработку системы Кп определяются по формуле:
Кп = Фз/п•[(1 + д)•(1+с)+н+пр] + tэвмСм-ч, (3.3)
где Фз/п - фонд основной заработной платы разработчиков и других исполнителей работ, руб.;
д - коэффициент дополнительной зарплаты, принимается равным 0,1;
с - коэффициент отчислений на социальные нужды от основной и дополнительной заработной платы, равен 0,34;
н - коэффициент накладных расходов организации, коэффициент принимается равным 0,6;
пр - коэффициент прочих расходов, принимается равным 0,1 ;
tэвм - машинное время, затраченное для отладки программного обеспечения системы, ч.;
См-ч - стоимость машино-часа работы компьютера, руб.
Расчет фонда основной заработной платы исполнителей работ по разработке системы производится по формуле:
(3.4)
- суммарная трудоемкость работ по разработке системы, чел.-ч.
С - часовая тарифная ставка разработчиков и других исполнителей работ, руб.
Тарифная ставка разработчика принимается в соответствии с ранее определенной суммой оклада 150 рублей в час. Продолжительность рабочего дня равна 8 часов. Общая продолжительность работ - 155 дней. Таким образом:
Фз/п = 155•150•8 = 186000 pуб. (3.5)
Время, затраченное на разработку и отладку программного обеспечения на ЭВМ tЭBM, определено по фактическим затратам машинного времени. Оно равно 88 дням (704 часам).
Стоимость машино-часа работы компьютера или комплекса средств автоматизации (КСА) См-ч берется в бухгалтерии той организации, где выполняется дипломный проект. Себестоимость машино-часа работы компьютера или КСА определяется по формуле:
(3.6)
Зп - затраты на заработную плату обслуживающего персонала с учетом всех отчислений, рублей. Так как нет необходимости в обслуживании ЭВМ класса IBM PC, то нет необходимости проводить расчет затрат на заработную плату обслуживающего персонала (Зп = 0).
А - годовая сумма амортизации. Согласно законодательству с 1 января 2002 года расчет амортизации основных средств производится исходя из планируемого срока эксплуатации независимо от категории основных средств. Поэтому годовые амортизационные отчисления по ЭВМ будут считаться по формуле:
А = 12 СКСА / tэкспл, (3.7)
где СКСА - стоимость ЭВМ и прочего оборудования.
Для разработки ОС использовалась ЭВМ стоимостью 20000 руб. Общая сумма составляет 20000 руб.
tэкспл - общий срок эксплуатации оборудования. Для ЭВМ и оценочного модуля этот срок примем одинаковым и равным 60 месяцам.
Таким образом, годовая сумма амортизации составит:
А = 12 20000 / 60 = 4000 р.
Зэ - затраты на силовую электроэнергию. Затраты на электроэнергию в год Зэ определяются по формуле:
Зэ = Wу Cэ Tв , (3.8)
где Wу - установленная мощность, кВт;
Сэ - стоимость силовой электроэнергии, р. / кВт;
Tв - время, в течение года, когда ЭВМ потребляет электроэнергию, ч.
Суммарная потребляемая мощность комплекса технических средств автоматизации составляет 300 Вт/час. Стоимость 1 кВт/ч для производственных предприятий составляет 2,55 р. Таким образом, затраты на электроэнергию в год составят:
Зэ = 0,3•2,55•1976 = 1511,64 р.
Зр - затраты на ремонт и обслуживание оборудования в год. Примем затраты на текущий ремонт ЭВМ в год равными 5% от стоимости ЭВМ, т.е. 1500 рублей.
3м - затраты на материалы в год. Примем затраты на материалы в год равными 3% от стоимости ЭВМ, т.е. 900 рублей.
Зн - накладные расходы. В накладные расходы включаются затраты на оплату труда административно-управленческого аппарата, содержание площадей, затраты на отопление, освещение и прочие. Примем их равными 5% от стоимости ЭВМ, что составит 1500 рублей.
Фд - действительный годовой фонд времени работы КСА, ч. Годовой фонд времени Фд устанавливается, исходя из номинального фонда времени и времени профилактики оборудования и ремонтов:
Фд = S h D - Tпр, (1976 часов) (3.9)
где S - продолжительность смены, ч. (8 часов);
h -- количество смен (1 смена);
D -- число рабочих дней в году, дн. (252 дней);
Tпр -- время ремонтов и профилактики оборудования в год, ч. (40 часов).
СМ-Ч = (0 + 4000 + 1511,64 + 1500 + 900 + 1500) / 1976 = 4,76 pуб.
Таким образом, затраты на разработку системы:
Кп = 186000 • [ 1,1 • 1,34 + 0,6 + 0,1 ] + 704 • 4,76 = 407715руб.
Расчет-прогноз минимальной цены разработки
Минимальная цена разработки системы Zmin складывается из полных затрат на разработку Кп и минимально необходимой суммы прибыли Пmin, размер которой позволял бы на минимальном уровне осуществить самофинансирование организации-разработчика после всех обязательных платежей и выплаты налогов.
Zmin = Кп + Пmin, (3.10)
Сумма прибыли Пmin рассчитывается, исходя из планируемого минимального уровня рентабельности затрат организации - разработчика.
, (3.11)
где Rmin - минимальный уровень рентабельности равный 30 %.
Пmin = 407715 • 30 / 100 = 122314 pуб.
Таким образом, Zmin = 407715 + 122314 = 530029 pуб.
3.3 Оценка безубыточности и расчет целесообразного объема продаж
Методом анализа безубыточности проекта определяется целесообразность затрат на разработку. Также рассчитаем целесообразный объем продаж.
Метод заключается в том, чтобы выявить точку безубыточности (ТБ). Под ней подразумевается точка кривой (прямой), показывающей рост объема продаж в системе двух координатных осей, в которой доходы от продажи равны суммарным затратам. Для анализа безубыточности необходимы следующие данные:
- единовременные затраты на разработку системы КП, р.;
- затраты на воспроизведение системы, рекламу, сопровождение системы S1, р. ;
- цена продажи Z, р.
Объем продаж в стоимостном выражении Q является функцией от количества продаж N и рассчитывается по формуле:
Q (N) = Z N (3.12)
Суммарные затраты на разработку и реализацию проекта определяются по формуле:
S (N) = KП + S1 N (3.13)
Точка безубыточности (ТБ) находится из соотношения:
Q (NТБ) = S (NТБ) (3.14)
или
Z NТБ = КП + S1 NТБ (3.15)
Откуда
(3.16)
Планируемая цена продажи системы (Z) составляет 40000 рублей.
Затраты на рекламу и сопровождение системы (S1) составляют 10% от стоимости - 4000 рублей.
Подставляя данные в формулу (3.16), получим:
NТБ = 407715 / (40000- 4000) = 11,32 12 копии
Точка безубыточности служит разработчику хорошим ориентиром в оценке риска затрат на разработку. График безубыточности приведен на рисунке 3.2.
Затраты на разработку считаются эффективными, если доходы покроют все затраты на разработку, продажу автоматизированной системы оптимизации оборота локомотивов и будет получена минимально необходимая сумма прибыли Пmin. Поэтому рассчитывается целесообразный объем продаж NЦ из соотношения:
Z NЦ КП + S1 NЦ + Пmin, (3.17)
(3.18)
откуда NЦ 15.
Потенциальными потребителями системы являются поездные диспетчера сортировочных станций.
Рисунок 3.2 - График безубыточности и целесообразного объема продаж
Таким образом, спрос на продукцию данного типа в настоящее время является высоким и продолжает расти, что будет учтено при прогнозе объема продаж.
3.4 Расчет экономической эффективности разработки системы
Для оценки эффективности разработки системы применен метод расчета чистой дисконтированной стоимости. Определим процент расчетной ставки предприятия, при которой инвестиции могут считаться эффективными. Чтобы выбрать величину этой ставки предприятие исходит из ставки на заемный капитал (ставка, по которой предприятие выплачивает своему кредитору) и альтернативной стоимости вложения денежных средств (упущенная возможность). Расчетная ставка процента iр учитывает инфляцию:
iн - номинальная ставка
iи - индекс инфляции
Инвестиции считаются эффективными, если ЧДС положительная.
ЧДС
Т -- период функционирования проекта, г.;
Kj -- инвестиционные затраты в j-м году, т.р.;
Эjг -- экономический результат (экономия, прибыль и амортизация) в j-м году, т.р.;
j -- коэффициент дисконтирования для года j.
Достоинства метода определения ЧДС: предприятие может получить стоимостной результат от вложения средств в производство за весь период функционирования.
Коэффициент дисконтирования j можно рассчитать по формуле:
j = .
Возьмем номинальную ставку процента iн = 20%. По прогнозам на 2011 год инфляция в России составляет 9%. Таким образом, iр=10%
Период функционирования капитальных вложений примем равным 3 годам. В расчет включим стоимость на рекламу и сопровождение системы. Ожидаемый план денежных потоков по тиражированию системы приведен в таблице 3.2.
Расчет чистой дисконтированной стоимости системы приведен в таблице 3.3.
Таблица 3.2 - План денежных потоков
Год |
Кол-во проданных экземпляров, шт. |
Цена, руб. |
Доход, руб. |
Затраты на единицу, руб. |
Сумма затрат, руб. |
Прибыль, руб. |
|
1 |
5 |
40000 |
200000 |
4000 |
20000 |
180000 |
|
2 |
10 |
40000 |
400000 |
4000 |
40000 |
360000 |
|
3 |
10 |
40000 |
400000 |
4000 |
40000 |
360000 |
Таблица 3.3 - Дисконтированная стоимость
Год |
Ряд платежей и поступлений, руб. |
Коэф. дисконтирования |
Текущая дисконтир. стоимость, руб. |
Чистая дисконтир. стоимость, руб. |
|
0 |
-407715 |
-407715 |
-407715 |
||
1 |
180000 |
0,9083 |
163500 |
-244215 |
|
2 |
360000 |
0,8251 |
297025 |
52810 |
|
3 |
360000 |
0,7494 |
269798 |
322608 |
Интегральный эффект ЭI равен 322608 руб. - больше нуля. Срок окупаемости составляет 1 год 7 месяцев. Значит, затраты по созданию системы целесообразны. График чистой дисконтированной стоимости системы приведен на рисунке 3.3.
Рисунок 3.3 - Диаграмма формирования чистой дисконтированной стоимости
4. БЕЗОПАСТНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ
Безопасность жизнедеятельности - система знаний о способах обеспечения безопасности человека в среде его обитания, а также о деятельности направленной на обеспечение безопасности в перспективе, с учетом влияния человека на среду.
В данном случае объектом автоматизации является процесс оптимизации оборота локомотивов. С точки зрения безопасности жизнедеятельности целью данной системы является обеспечение безопасности пользовательских данных на стадии функционирования автоматизированной системы. В разделе 1 предметная область описана более подробно.
4.1 Безопасность объекта автоматизации
В дипломном проекте разработана АС оптимизации оборота локомотивов. Проведем оценку качества и безопасности разработанной системы по показателям, рекомендуемым ГОСТ Р ИСО/МЭК 9126-93 (Государственный стандарт на оценку качества программной системы).
Назначение системы: автоматизация процесса оптимизации оборота локомотивов.
Цели создания системы:
- систематизация информации о локомотивах;
- оптимизация привязки локомотива к поезду;
- формирование отчетной информации.
Проектируемая АС оптимизации оборота локомотивов предполагает проведение процесса оптимизации привязки локомотивов к поезду и вывод отчета о проделанной работе.
Как и в любой подобной системе, существуют 2 части функционирования: клиентская и администраторская. В администраторской части создаются новые учетные записи, в случае необходимости производится их изменение, обеспечивается работоспособность всей системы в целом. В клиентской части вводятся и изменяются данные о локомотивах и поездах, рассчитывается эффективность использования, ведутся справочники базы данных, производится закрепление локомотива за поездом и т.д.
Основные функции разрабатываемой АС представлены ниже:
- аутентификация пользователя;
- ведение базы данных информации о локомотивах;
- прогнозирование времени прихода и готовности локомотивов на сортировочной станции;
- оптимизация привязки локомотива к поезду;
- вывод на экран автоматически сформированных отчетов;
- сохранение сформированных отчетов в базу данных.
Защищенность системы характеризуется разделением ролей пользователей автоматизированной системы на пользовательскую и администраторскую часть. При входе в систему пользователь проходит процесс парольной аутентификации. Введенные пользователем логин и пароль сравниваются системой со значениями, хранящимися в базе данных - учетными записями пользователей. Конечной целью аутентификации пользователя является предоставление возможностей в соответствии с положенными ему правами - процесс авторизации - в случае положительной проверки, и отказ в допуске - в случае отрицательного исхода.
Практичность системы в первую очередь характеризуется логичным интерфейсом и простотой пользования. В АС оптимизации оборота локомотивов через интрефейс создан с расчетом на среднестатистического пользователя, знакомого с работой в простых приложениях. Более подробно интерфейс и основные экраны рассмотрены выше.
Разработанная АС позволяет пользователю, не обладающему специальными знаниями, быстро и грамотно осуществлять процесс изменения и публикации информации в системе. В системе также предусмотрена возможность разграничения уровня доступа к изменению информации.
Автоматизированная система оптимизации оборота локомотивов полностью удовлетворяет требованиям безопасности по защите конфиденциальной информации пользователя, а также безопасности хранимых данных. Это достигается созданием резервных копий, ограничением доступа к администраторской части. Безопасность пользователя системы достигается наличием дружественного, эргономичного и понятного для пользователя интерфейса. Разработанная система полностью удовлетворяет требованиям ГОСТ Р ИСО/МЭК 9126-93 и СанПиН 2.2.2/2.4.1340-03.
4.2 Оценка напряженности трудового процесса пользователя автоматизированной системы
Для того чтобы определить, потребуются ли дополнительные затраты при использовании АС оптимизации оборота локомотивов, следует определить напряженность трудового процесса, который оценивают в соответствии с руководством Р 2.2.2006-05 «Руководство по гигиенической оценке факторов рабочей среды и трудового процесса. Критерии и классификация условий труда».
4.2.1 Нагрузки интеллектуального характера
«Содержание работы» указывает на степень сложности выполнения задания: от решения простых задач до творческой (эвристической) деятельности с решением сложных заданий при отсутствии алгоритма. При использовании АС оптимизации оборота локомотивов деятельность пользователя можно отнести к решению несложных задач.
Таким образом, класс сложности выполняемой работы можно назвать допустимым, что соответствует классу сложности 2. Можно сказать, что пользователь имеет несложную по содержанию работу, требующую выполнения инструкций, предлагаемых программой.
«Восприятие сигналов (информации) и их оценка». Критериальным с точки зрения различий между классами напряженности трудового процесса является установочная цель (или эталонная норма), которая принимается для сопоставления поступающей при работе информации с номинальными значениями, необходимыми для успешного хода рабочего процесса.
Информация может быть представлена пользователю в виде текста, таблиц, символов, изображений и т.д. Все интерфейсные решения подробно рассмотрены выше.
Очевидно, что основой деятельности пользователя является интеллектуальная деятельность, однако не постоянно связанная с восприятием сигналов с последующей комплексной оценкой всей деятельности, поэтому следует отнести нагрузки к классу 3.1.
«Распределение функций по степени сложности задания». Любая трудовая деятельность характеризуется распределением функций между работниками. Соответственно, чем больше возложено функциональных обязанностей на работника, тем выше напряженность его труда.
До введения в эксплуатацию АС оптимизации оборота локомотивов потребителю приходилось совершать физические действия для того, чтобы оптимизацию привязки локомотивов. Это требовало времени и усилий.
После внедрения системы функции пользователя свелись к взаимодействию с автоматизированной системой и выполнению следующих операций: отслеживание информации в базе данных; управление функциями АС; анализ сформированного отчета АС для дальнейшего принятия решения. В приложении «А» в руководстве пользователя функции пользователя рассмотрены более подробно.
По данному показателю класс 2 (допустимый) и класс 3 (напряженный труд) различаются по двум характеристикам - наличию или отсутствию функции контроля и работы по распределению заданий другим лицам.
Работа, как с точки зрения разработчика АС, так и с точки зрения пользователя АС, предполагает отсутствие функций контроля за деятельностью других лиц, следовательно, по данному показателю работа относится к классу 2.
Таким образом, по этому показателю отнесём нагрузки к классу 2.
Характер выполняемой работы. В том случае, когда работа выполняется по индивидуальному плану, то уровень напряженности труда невысок (1 класс). Если работа протекает по строго установленному графику с возможной его коррекцией по мере необходимости, то напряженность повышается (2 класс). Еще большая напряженность труда характерна, когда работа выполняется в условиях дефицита времени (класс 3.1). Наибольшая напряженность (класс 3.2) характеризуется работой в условиях дефицита времени и информации. При этом отмечается высокая ответственность за конечный результат работы.
В приложении «А» в руководстве пользователя также можно ознакомиться с основными типами выполняемых работ с автоматизированной системой.
Работа пользователя протекает по свободному графику, вследствие чего характер выполняемой работы соответствует классу 1.
4.2.2 Сенсорные нагрузки
«Длительность сосредоточенного наблюдения (в % от времени смены)» - чем больше процент времени отводится в течение смены на сосредоточенное наблюдение, тем выше напряженность. Общее время рабочей смены принимается за 100 %.
Пользователю не нужно много времени уделять на поиск нужного вида товаров, т.к. интерфейс разработан с расчетом на среднестатистического пользователя, логичным и удобным для работы (раздел 2.8).
Так как отсутствует длительное сосредоточение внимания при постоянном изменении объекта наблюдения, отнесём к классу 1.
«Плотность сигналов (световых, звуковых) и сообщений в среднем за 1 час работы» - количество воспринимаемых и передаваемых сигналов (сообщений, распоряжений) позволяет оценивать занятость, специфику деятельности работника.
Так как восприятие сигналов происходит в зависимости от пользовательской активности и система может предоставлять такие сигналу в достаточном объеме (функция предпрослушивания и предпросмотра - раздел 2), то отнесем к классу 2 напряженности труда.
«Число производственных объектов одновременного наблюдения» - указывает, что с увеличением числа объектов одновременного наблюдения возрастает напряженность труда. Так как информация может быть получена путем последовательного переключения внимания с объекта на объект и имеется достаточно времени до принятия решения и/или выполнения действий, а человек обычно переходит от распределения к переключению внимания, то такую работу не следует оценивать по показателю «число объектов одновременного наблюдения. Поэтому присваиваем класс 1.
«Размер объекта различения при длительности сосредоточенного внимания (% от времени смены)». Чем меньше размер рассматриваемого предмета (изделия, детали, цифровой или буквенной информации и т. п.) и чем продолжительнее время наблюдения, тем выше нагрузка на зрительный анализатор. Соответственно возрастает класс напряженности труда.
В качестве основы размеров объекта различения взяты категории зрительных работ из СанПиН 23-05-2010 «Естественное и искусственное освещение». При этом рассматривается лишь тот объект, который несет смысловую информацию, необходимую для выполнения работы. Минимальным объектом различения является точка, размер которой составляет примерно 0,3мм. Также благодаря хорошо спроектированному интерфейсу в системе почти нет малых объектов, то относим к классу 2.
Характер зрительной работы - точная зрительная работа при фиксированной линии зрения на рабочую поверхность.
«Работа с оптическими приборами (микроскоп, лупа и т.п.) при длительности сосредоточенного наблюдения (% от времени смены)». Отсутствует, класс 1.
«Наблюдение за экраном видеотерминала (ч в смену)». Чем больше время фиксации взора на экран пользователя ВДТ, тем больше нагрузка на зрительный анализатор и тем выше напряженность труда. Так как время работы пользователя с компьютером увеличивается с внедрением системы, и основное время работы он проводит за экраном монитора, то стоит отнести нагрузки к классу 3.1.
«Нагрузка на слуховой анализатор». Степень напряжения слухового анализатора определяется по зависимости разборчивости слов в процентах от соотношения между уровнем интенсивности речи и «белого» шума. Так как пользователь имеет дело с файлами аудиовизуального типа (см. раздел 1.2), то разборчивость слов не всегда равно 100 % - 1 класс, следовательно нужно оценить работу по 2 классу.
4.2.3 Эмоциональные нагрузки
«Степень ответственности за результат собственной деятельности. Значимость ошибки». Данный показатель указывает, в какой мере работник может влиять на результат собственного труда при различных уровнях сложности осуществляемой деятельности. С возрастанием сложности повышается степень ответственности, поскольку ошибочные действия приводят к дополнительным усилиям со стороны работника или целого коллектива, что соответственно приводит к увеличению эмоционального напряжения.
Для пользователя АС ответственность дифференцируется по типу "правильно-неправильно". Если пользователь совершил ошибку, то система выдаст предупреждение или будет возможность «откатить» действия до предыдущего шага (см. раздел 2.9). Следовательно, имеет место 1 класс.
«Степень риска для собственной жизни». Мерой риска является вероятность наступления нежелательного события, которую с достаточной точностью можно выявить из статистических данных производственного травматизма на данном предприятии и аналогичных предприятиях отрасли. Риск отсутствует, относим к классу 1.
«Ответственность за безопасность других лиц». При оценке напряженности необходимо учитывать лишь прямую, а не опосредованную ответственность (последняя распределяется на всех руководителей), то есть такую, которая вменяется должностной инструкцией. Отсутствует, класс 1.
«Количество конфликтных производственных ситуаций за смену». Наличие конфликтных ситуаций в производственной деятельности ряда профессий (сотрудники всех звеньев прокуратуры, системы МВД, преподаватели и др.) существенно увеличивают эмоциональную нагрузку и подлежат количественной оценке. Количество конфликтных ситуаций учитывается на основании хронометражных наблюдений.
С введение в эксплуатацию автоматизированной системы конфликтные ситуации сведены к минимуму, т.к. пользователю теперь не надо напрямую общаться с продавцом. Поэтому отнесем к классу 1.
4.2.4 Монотонность нагрузок
«Число элементов (приемов), необходимых для реализации простого задания или многократно повторяющихся операций» и «Продолжительность (с) выполнения простых производственных заданий или повторяющихся операций» - чем меньше число выполняемых приемов и чем короче время, тем, соответственно, выше монотонность нагрузок.
В работе пользователя монотонность нагрузок не так выражена и относится скорее к классу 2, т.к. работа пользователя, как и любого другого оператора ПЭВМ представляется в виде коротких, однообразных и часто повторяющиеся действия (см. приложение «А»), которые имеют значительный информационный компонент и вызывают состояние не монотонности, а нервно-эмоционального напряжения.
«Время активных действий (в % к продолжительности смены)». Чем меньше время выполнения активных действий и больше время наблюдения за ходом производственного процесса, тем, соответственно выше монотонность нагрузок. Активных действий со стороны пользователя существуют, так как он сам принимает непосредственное участие в поиске и выборе интересующего товара, класс 2.
«Монотонность производственной обстановки (время пассивного наблюдения за ходом техпроцесса, в % от времени смены)» - чем больше время пассивного наблюдения за ходом технологического процесса, тем более монотонной является работа. Время пассивного наблюдения отсутствует, класс 1.
4.2.5 Режим работы
«Фактическая продолжительность рабочего дня». Поскольку пользователь не привязан к каким-либо временным рамкам по пользованию системы, то отнесем к классу 1.
Подобные документы
Разработка программного продукта "Железная дорога". Вид и классификация инструментальных средств, используемых для создания прикладного ПО. Организация взаимодействия клиентской программы с базой данных; реализация системы контроля движения поездов.
курсовая работа [895,0 K], добавлен 11.11.2010Разработка автоматизированной системы, которая позволит повысить эффективность и качество работы автосервиса. Автоматизация процессов оказания консультационных услуг клиентам и закупки запчастей. Моделирование фрагментов системы в стандарте IDEF3.
курсовая работа [657,5 K], добавлен 19.06.2013Назначение и цели создания системы. Разработка логической модели данных, выбор хранилища. Диаграмма классов для диспетчера и контент-менеджера, схема взаимодействия объектов системы. Описание программных модулей. Тестирование веб-базированной системы.
курсовая работа [5,4 M], добавлен 17.09.2013Описание автоматизированной информационной системы автотранспортного предприятия. Область применения системы, ее функциональное содержание и возможности. Требования к программной и аппаратной части, алгоритм работы. Сценарий работы с пользователем.
курсовая работа [638,6 K], добавлен 18.09.2014Обзор медицинских информационных систем. Анализ и моделирование автоматизированной системы "Регистратура". Требования к составу и параметрам вычислительной системы. Обоснование выбора системы управления базами данных. Разработка инструкции пользователя.
дипломная работа [1,2 M], добавлен 14.10.2012Разработка программы автоматизации подбора запчастей для ремонта автомобилей. Структурные единицы сообщений. Концептуальная модель системы. Алгоритм работы автоматизированной системы. Физическая модель данных. Описание пользовательского интерфейса.
дипломная работа [2,1 M], добавлен 20.06.2013Разработка автоматизированной системы, предназначенной для составления месячных графиков работы экипажей подвижного состава трамвайного депо. Формирования отчетных документов, используемых подразделениями внутри предприятия. Описание алгоритмов работы.
дипломная работа [2,3 M], добавлен 06.04.2013Проектирование автоматизированной системы обслуживания клиентов банка через Интернет, функциональные требования к ней. Выбор системы управления базами данных. Описание интерфейса программы, ее тестирование. Расчёт экономической эффективности проекта.
дипломная работа [7,9 M], добавлен 24.03.2010Современные программные продукты для автоматизации ведения бухгалтерского учета. Описание автоматизированной системы для учета выбранного вида деятельности на предприятии в среде 1С. Технология инсталляции, запуска и работы с программным изделием.
курсовая работа [3,4 M], добавлен 14.01.2013Разработка автоматизированной системы управления холодильной установкой, позволяющей сократить время технологического процесса и обеспечивающую комфортные условия для контроля его параметров. Составление алгоритма данного оптимизированного управления.
курсовая работа [8,5 M], добавлен 22.12.2010