Анализ деятельности торгового предприятия "ИнТорг" с точки зрения организации отдела закупок

Рис. 2.4 Оптимизированный сценарий процесса выбора поставщика

2.6 Сравнение материальных затрат на процесс выбора поставщика

Рассчитаем стоимость выполнения функций в двух вариантах функционирования Отдела Логистики.

Относительный размер оплаты сотрудников Отдела Логистики(см. Таблица 2.14).

Таблица 2.14 Относительный размер оплаты сотрудников отдела Логистики

Должность	Размер ставки	Индекс
НОЛ	1	n1
Зам. НОЛ	0,7	n2
Менеджер по закупкам	0,5	n3

Количество ставок для функций Закупочной логистики, представлено в таблице 2.15.

Таблица 2.15 Количество ставок

Индекс	Вес	Функция
S1	0,3	Составление списка возможных поставщиков
S2	0,2	Организация переписки с поставщиками
S3	0,4	Подготовка запросов в соответствии с заявкой на материал
S4	0,4	Отправка запроса
S5	0,2	Получение предложений от возможных поставщиков
S6	1,3	Согласование полученных предложений
S7	1,5	Анализ возможных вариантов
S8	1.4	Выбор наилучшего поставщика
S9	0,5	Согласование выбранного поставщика
S10	0,4	Ввод характеристик возможных поставщиков в программу
S11	1,3	Согласование поставщика, выбранного программой

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

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

f = ?n_i*S_j

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

0,5*0,3+0,5*0,2+0,5*0,4+0,5*0,4+0,5*0,2+0,7*1,3+1*1,3+0,7*1,5+1*1,5+ +0,7*1,4+1*1,4+1*0,5=6,89 у.е

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

0,5*0,3+0,5*0,2+0,5*0,4+0,5*0,4+0,5*0,2+0,7*1,3+1*1,3+0,5*0,4+0,7*1,3+ +1*1,3=5,37 у.е

После автоматизации требуемый размер оплаты функций уменьшился на 1,52 у.е, что примерно составляет 27%. Это можно считать весьма удовлетворительным результатом.

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

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

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

3.1 Выбор архитектуры информационной системы

По способу организации ИС имеют следующие виды;

· архитектура файл-сервер;

· архитектура клиент-сервер;

· многоуровневая система;

· на основе интернет/интранет-технологий.

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

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью файл-серверной архитектуры является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными размещаются на сервере, а диалог логики, обработка логики - на клиенте. Двух уровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

Многоуровневая архитекту растала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней;

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

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

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle,Sun, Borland и д.р. [4]

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

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

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

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

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

Таблица 3.1 - Сравнительная характеристика архитектуры ИС

Параметры сравнения	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
Установка СУБД	На клиентском компьютере	Отдельный сервер	Несколько отдельных серверов	Несколько отдельных серверов
Объемы передаваемых данных	Малые	Большие	Очень большие	Очень большие
Применяемые на предприятии	Нет	Да	Нет	Нет
Знакомство обслуживающего персонала с представленными архитектурами	Да	Да	Нет	Нет

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 3.2 - Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 3.3.

Таблица 3.3 - Оценка технико-экономической эффективности

Параметры сравнения/ оценка	Весовой коэффициент	Файл-сервер	Клиент-сервер	Многоуровневая система	Интернет/интранет технологии
		Ajf	kj •Ajf	Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Установка СУБД	0,15	1	0,15	4	0,6	3	0,45	3	0,45
Объемы передаваемых данных	0,25	1	0,25	3	0,75	4	1	4	1
Применяемые на предприятии	0,35	0	0	4	1,4	0	0	0	0
Знакомство обслуживающего персонала с представленными архитектурами	0,25	2	0,5	3	0,75	1	0,25	1	0,25
Интегральный технико-экономический показатель, Q		Qf = 0,9	Qk = 3,5	Qm = 1,7	Qi = 1,7

Посчитаем интегральный технико-экономический показатель:

для файл-сервера Q_f:

для клиент-сервер Q_k:

для многоуровневой системы Q_m:

для интернет/интранет технологии Q_i:

Интегральный технико-экономический показатель между файл-серверной архитектурой и клиент-серверной равен:

Q = Q_k/ Q_f = 3,5/0,9 = 3,89

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

Интегральный технико-экономический показатель между клиент-серверной архитектурой и многоуровневой системой равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

Интегральный технико-экономический показатель между клиент-серверной архитектурой и интернет/интранет технологии равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

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

3.2 Разработка структуры БД

3.2.1 Нотация IDEF1x сущности и их атрибуты

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

· она имеет имя и описание;

· она представляет класс, а не единичный экземпляр абстракции;

· ее конкретные представители (экземпляры) могут быть уникально идентифицированы;

· она содержит логическую группировку атрибутов, представляющих информацию, интересную с точки зрения корпорации. [4]

Существует две основных группы сущностей: зависимые и независимые. Независимая сущность не нуждается в информации из другой сущности для идентификации уникального экземпляра. Она представляется в ERwin в виде прямоугольника. Первичный ключ независимой сущности не включает в себя первичных ключей других сущностей. Зависимая сущность должна привлекать информацию из другой сущности для идентификации уникального экземпляра. Она представляется на ER-диаграмме в виде прямоугольника с закругленными углами. Первичный ключ зависимой сущности включает первичные ключи одной или более родительских сущностей.

Понятие атрибута. Типы атрибутов.

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

Ключевые атрибуты

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

Атрибуты первичного ключа

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

Хороший первичный ключ будет обладать следующими признаками:

· значение гарантирует уникальность для каждого из экземпляров;

· значение не имеет скрытого смысла;

· область определения значений будет оставаться постоянной с течением времени;

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

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

Неключевые атрибуты

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

3.2.2 Связи между сущностями

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

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

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

3.2.3 Описание процесса проектирования

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

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

· Характеристики товаров;

· Характеристики поставщиков.

Согласно всему вышеизложенному существует возможность перечислить сущности предметной области:

· Город;

· Поставщик;

· Товар.

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

Для сущности Город атрибутами являются (Название города, количество поставщиков, Расстояние, Возможные способы проезда), первичным ключом будет являться (Название города).

Для сущности Поставщик атрибутами являются (ID_Поставщика, Название города, Наименование, Качество поставляемых материалов, Сроки поставки груза, Стоимость материалов, Опыт сотрудничества с поставщиками, Надежность), первичным ключом будет атрибут (ID_Поставщика). Ключом для связи с другими сущностями является атрибут (Название города).

Для сущности Товар атрибутами являются (ID_Товара, Название города, ID_Поставщика, Наименование товара, Вес, Цена, Количество), первичным ключом в данной сущности будет являться атрибут (ID_Товара). Для связи с внешними сущностями используется два атрибута (ID_поставщика) и (Название города).

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

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

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

LongInteger - числовая переменная целого значения.

Text - случайная текстовая переменная.

Date/time - числовая переменная десятичного значения.

Рис. 3.1 Логическая модель данных



Рис. 3.2 Физическая модель данных

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

4. Реализация выбранного варианта решения

4.1 Обоснование выбора СУБД

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

Рассмотрим некоторые из представленных на рынке СУБД, сведённых в таблицу 4.1.

Таблица 4.1 - Сравнение СУБД

Название критерия выбора	SQL Server 2000	ORACLE 10g	MySQL
Стоимость сервера (лицензия на процессор и на сам сервер)	5448 $	4995 $	Общедоступная
Стоимость клиента	146 $	149 $	Общедоступная
Максимальное число пользователей	Зависит от лицензии	Зависит от лицензии	Зависит от лицензии
Технические требования к серверу	166 Мгц 64 Мб ОЗУ 140-500 Мб на HDD	300 Мгц 128 Мб ОЗУ 1,5 Гб на HDD	100 Мгц 64 Мб ОЗУ 100 Мб на HDD
Поддерживаемые серверные ОС	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition, UNIX-подобные системы, Solaris, Mac OS идр.	Windows 2000 (SP2), Windows Server 2003, Windows NT® 4.0 (SP6a иливыше), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9
Уровень квалификации персонала	Высокий	Высокий	Средний
Установленная на данный момент на предприятии	нет	нет	да

На основании выбранных критериев проведем расчет технико-экномической эффективности MySQL, SQL Server 2000, ORACLE 10g.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Таблица 4.2 - Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем k_j= Результаты сравнения сведем результаты сравнения в таблицу 4.3.

Посчитаем интегральный технико-экономический показатель:

дляSQL Server 2000Q_s:

,

дляORACLE 10g Q_d:



И для MySQL:

Таблица 4.3 - Оценка технико-экономической эффективности

Параметры сравнения/ оценка	Весовой коэффициент	MySQL	SQL Server 2000	ORACLE 10g
Стоимость сервера	0,15	4	0,6	1	0,1	1	0,2
Стоимость клиента	0,10	4	0,40	3	0,30	3	0,3
Максимальное число пользователей	0,10	3	0,3	3	0,3	3	0,3
Технические требования к серверу	0,15	3	0,45	2	0,3	1	0,15
Поддерживаемые серверные ОС	0,05	3	0,15	4	0,2	3	0,15
Уровень квалификации персонала	0,20	4	0,8	2	0,4	1	0,2
Установленная на данный момент на предприятии	0,25	4	1,00	2	0,5	2	0,5
Интегральный технико-экономический показатель, Q		Qa= 3,7	Qs = 2,1	Qo = 1,8

Интегральный технико-экономический показатель между MySQL и SQL Server 2000, равен:

Q = Q_a/ Q_s = 3,7/2,1 = 1,76

Между MySQL и ORACLE 10g,равен:

Q = Q_a/ Q_o = 3,7/1,8 = 2,06

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

MySQL:является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, благодаря хорошей системе безопасности этого пакета, стабильной работе, высокому быстродействию и хорошей интеграции с соответствующими средствами программирования. В дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. [5] Разработчики MySQL всегда считали стабильность предметом особой важности.

4.2 Выбор среды разработки

Выбор средства разработки приложений был основан на сравнении с C++Builder 2007, BorlandDelphi 2007 и C#(MSVisualStudio 2007) (Таблица 4.3).

Новая версия продукта C++Builder 2007, ведущей интегрированной среды для быстрой разработки приложений на С++, сочетает поддержку операционной системы Windows Vista API и технологий Web 2.0 с самыми последними стандартами: значительно выросшей производительностью, интегрированными функциями проверки и множеством сочетаний клавиш, позволяющих экономить время и значительно упрощать выполнение типовых задач. [6]

C++Builder 2007 кардинально улучшает разработку на C++ для Windows, предоставляя полностью интегрированную среду для быстрой разработки приложений (RAD) на C++ под Windows, которая поддерживает Windows Vista™ и AJAX.C++ Builder 2007 продолжает традиции быстрой разработки и в то же время реализует новые технологии: поддержка Vista включает темы приложений и VCL-компоненты для поддержки Aero и Vista Desktop, а также новые диалоги работы с файлами и задачами.

Среди новых функций C++ Builder 2007: улучшенная совместимость со стандартами ANSI C++, Dinkumware и Boost; значительно ускорена работа интегрированной среды, в том числе время сборки проекта внутри среды -- так же быстро или даже быстрее, чем сборка с применением утилит командной строки.

Borland Delphi 2007 - эффективная среда разработки приложений для Microsoft Windows. BorlandDelphi2007 предоставляет исключительный "коэффициент повышения производительности", позволяя устранить утомительный труд и максимально увеличить производительность при помощи революционной среды разработки корпоративных приложений, библиотеки многократно используемых визуальных компонентов и полностью интегрированного пакета инструментов моделирования и управления жизненным циклом проектов (ALM). [7]

C#(MSVisualStudio 2007) - являясь последним из широко распространенных языков программирования, впитал в себя весь имеющийся опыт и вобрал лучшие стороны существующих языков программирования, при этом являясь специально созданным для работы в NET. Сама архитектура NET продиктовала ему объектно-ориентированную направленность.

Свой синтаксис C# во многом унаследовал от C++ и Java. Но вместе с тем он является во многом новаторским - атрибуты, делегаты и события, прекрасно вписанные в общую идеологию языка, прочно заняли место в сердцах NET - разработчиков. Их введение позволило применять принципиально новые приемы программирования.

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

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

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

Таблица 4.4 - Сравнение языков программирования

Критерии сравнения	C++Builder 2007	Borland Delphi 2007	C#(MS Visual Studio 2007)
Степень соответствия назначения языка и целей разработки	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности	Ориентирован на разработку систем любой степени сложности
Использование международных стандартов	Полностью стандартизирован	Имеет собственный стандарт	Полностью стандартизирован
Поддерживаемые СУБД	MS SQL Server 2000/2005, My SQL, Oracle, Sybase, Interbase 2007, SQL Anywhere, DB2, Informix	InterBase 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase	InterBase 7.5, Oracle, IBM DB2, Microfost SQL Server 2000/2005, Informix, SQL Anywhere, MySQL, Sybase
Поддерживаемые ОС	Windows Vista/ Server 2003/ XP Professional/ 2000 Professional / 2000 Server	Microsoft Windows 2000/ XP Professional (SP2 иливыше)/ Vista Professional/ Microsoft Windows Server 2003.	MS Windows OC
Квалификация разработчиков	Высокая	Высокая	Высокая
Стоимость продукта	900 у.е.	900 у.е.	900 у.е.

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

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент k_j, причем k_j= 1.

Таблица 4.5 - Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Результаты сравнения сведем результаты сравнения в таблицу 4.5.

Посчитаем интегральный технико-экономический показатель:

для C++Builder 2007 Q_c:

Для Borland Delphi 2007 Q_b:

Для C#(MS Visual Studio 2007) Q_#:

Интегральный технико-экономический показатель между C#(MSVisualStudio 2007) иC++Builder 2007 равен:

Q = Q_#/ Q_c = 3,6/2,75 = 1,31

т.к. технико-экономический показатель больше 1 выбор в сторону C#(MSVisualStudio 2007).

Таблица 4.6 - Оценка технико-экономической эффективности

Параметры сравнения/ оценка	Весовой коэффициент	C++Builder 2007	BorlandDelphi 2007	C#(MSVisual Studio 2007)
		Ajk	kj •Ajk	Ajm	kj •Ajm	Aji	kj •Aji
Степень соответствия назначения языка и целей разработки	0,25	3	0,75	2	0,5	4	1
Использование международных стандартов	0,10	2	0,2	2	0,2	3	0,3
Поддерживаемые СУБД	0,20	2	0,4	2	0,4	3	0,6
Поддерживаемые ОС	0,15	2	0,3	3	0,45	4	0,6
Квалификация разработчиков	0,2	4	0,8	4	0,8	4	0,8
Стоимость продукта	0,1	3	0,3	3	0,3	3	0,3
Интегральный технико-экономический показатель, Q		Qc = 2,75	Qb = 2,65	Q# = 3,6

Интегральный технико-экономический показатель между C#(MSVisualStudio 2007) и Borland Delphi 2007 равен:

Q = Q_#/ Q_b = 3,6/2,65 = 1,36

т.к. технико-экономический показатель больше 1 выбор в сторону C#(MSVisualStudio 2007).

Вывод - для разработки ИС будем использовать C#(MSVisualStudio 2007) т.к. по сравнению с C++Builder 2007 и BorlandDelphi 2007 с использованием технико-экономического показателя, C#(MSVisualStudio 2007) наиболее подходит мне по критериям оценки.

4.3 Графический интерфейс пользователя модуля выбора поставщика

Рис. 4.1 Графический интерфейс

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

5. Социальная значимость разработки

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

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

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

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

6. Технико-экономическое обоснование проекта

6.1 Расчет затрат на проектирование

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

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

Расчеты длительности всех работ на этапе проектирования сведены в таблицу 6.1.

Таблица 6.1 - Длительность всех работ на этапе проектирования

Наименование работ	Длительность работ (дней)	Расход машинного времени
	tmin	tmax	t0	tM
1. Разработка ТЗ	3	5	3,8	-
2. Анализ ТЗ	4	6	4,8	-
3. Поиск и изучение литературы	3	5	3,8	-
4. Обзор существующих аналогов системы;	5	7	5,8	-
5. Разработка алгоритма	9	13	10,6	-
6. Разработка программы	18	24	20,4	142
7. Отладка работы программы	15	20	17	119
8.БЖ и экологичность разработки	5	7	5,8	40
9. Технико-экономическое обоснование работы	6	9	7,2	50
10. Оформление пояснительной записки	7	9	7,8	54
Итого:	75	105	87	405

t_o = (3t_min +2t_max)/5, (6.1)

где t_о - ожидаемая длительность работ;

t_min, t_max - наименьшая и наибольшая по мнению эксперта длительность работ.

Для определения продолжительности этапа проектирования Т_П по данным табл. 6.1 построим график организации работ во времени.

Рис. 6.1 - Ленточный график

Так как некоторые процессы можно проводить параллельно, общая продолжительность работ уменьшается. По графику видно, что общее время проектирования Т_П=77 дней.

Капитальные затраты на этапе проектирования К_п рассчитываются по формуле:

K_П = Z_П + M_П + Н_П, (6.2)

где Z_П - заработная плата проектировщика задачи на всем этапе проектирования;

M_П - затраты на использование ЭВМ на этапе проектирования;

Н_П - накладные расходы на этапе проектирования.

Одним из основных видов затрат на этапе проектирования является заработная плата проектировщика, которая рассчитывается по формуле:

(6.3)

где Z_д - дневная заработная плата разработчика задачи на этапе проектирования;

А_с - процент отчислений на социальное страхование (26%);

А_п - процент премий (35%).

Средняя дневная плата рассчитывается по формуле:

Z_д= ОК / Д_р, (6.4)

где: ОК - оклад разработчика (7000 руб.);

Д_р - среднее число рабочих дней (21 дней);

Получим,

Z_д = 7000/21 = 333 руб.

Отсюда,

Z_П = 333 * 77 * (1 + 0,26)•(1 + 0,35) = 43 615 руб.

Стоимость одного часа машинного времени примем С = 10 руб, тогда затраты на использовании ЭВМ равны:

М_П = С • Z_д, (6,5)

М_П = 10 * 333 = 3330 руб.

Накладные расходы составляют 80% от заработной платы персонала, занятого эксплуатацией программы, и вычисляются по формуле:

Н_П = (Z_П * 80) / 100, (6,6)

То есть Н_П = (43615 * 80)/100 = 34 892 руб.

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

К_П = Z_П + М_П + Н_П, (6,7)

К_П = 43 615 + 3330 + 34 892 = 81 837 руб.

6.2 Состав эксплуатационных расходов

В эксплуатационные расходы входят:

содержание персонала, занятого работой с программой;

расходы на функционирование программы;

накладные расходы;

прочие расходы.

Расходы на содержание персонала

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

(6,8)

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

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

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

а_п - средний процент премий за год.

До внедрения программы: n₁ = 5, z₁ = 84 000 руб., а₁ = 15%. Следовательно:

Z₁ = 5 * 84 000 * (1 + 0,266) * (1 + 0,15) = 611 478 руб.

После внедрения программы: n₂ = 3, z₂ = 84 000 руб., а₂ = 15%. Значит:

Z₂ = 3 * 84 000 * (1 + 0,266) * (1 + 0,15) = 366 886 руб.

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

Расходы на функционирование программы

Расходы на функционирование системы заключаются в затратах на машинное время. Формула для расчетов имеет вид:

М = С * t, (6,9)

где C - стоимость 1-го часа машинного времени;

t - необходимое для решения задачи машинное время (в часах).

При условии, что до внедрения программы компьютеры не использовались, М₁ = 0. Если стоимость одного часа работы составляет 10 рублей, а программа работает 2016 часов в год, то М₂ = 10 * 2016 = 20 160 руб. после внедрения программы.

Накладные расходы

Накладные расходы составляют 80 % от основной зарплаты персонала, занятого эксплуатацией программы. Т.о., накладные расходы составляют в год:

до использования программы: 611 478 * 80/100 = 489 182 руб.

после внедрения программы: 366 886 * 80/100 = 293 509 руб.

Прочие расходы

Прочие расходы составляют 2 % от суммы всех эксплуатационных расходов.

До внедрения программы: (611 478 + 489 182) * 2/100 = 22 013 руб.

После внедрения программы: (366 886 + 293 509 + 20 160) * 2/ 100 = 13 611 руб.

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

Р₁ = 611 478 + 489 182 + 22 013 = 1 122 673 руб.

Р₂ = 366 886 + 293 509 + 20 160 + 13 611 = 694 166 руб.

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

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

p_j = (?T_j / (t_j - ?T_j)) * 100, (6,10)

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

Т_j - экономия машинного времени при использовании разработанной программы (в часах).

Т_j и t_j должны быть определены в среднем за год.

В нашем случае затрачиваемое на решение без использования программы время составляет - 1620 часа, с использованием программы - 720 часа, то есть экономия составляет - 900 часов в год. Таким образом,

Р_j= (900 / (1620 - 900)) * 100 = 125 %

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

Р_п = Z_п Р_j/100, (6,11)

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

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

Р_п = 366 886 * 125/100 = 458 607 руб.

6.4 Расчет экономического эффекта от использования программы

Критерием эффективности создания и внедрения новых методов является ожидаемый экономический эффект. Он определяется по формуле:

Э = Э_г - Е_нК_п, (6,12)

где Э_г - годовая экономия;

Е_н - нормативный коэффициент (Е_н = 0,15);

К_п - капитальные затраты на проектирование (см. главу 6.1).

Годовая экономия Э_г складывается из экономии эксплуатационных расходов и экономии в связи с повышением производительности труда пользователя (см. главу 6.3):

Э_г = (Р₁ - Р₂) + Р_n,(6,13)

где Р₁ и Р₂ - соответственно эксплуатационные расходы до и после внедрения разрабатываемой программы;

Р_n - экономия от повышения производительности труда пользователя.

Годовая экономия будет равна:

Э_г = (1 122 673 - 694 166) + 448 607 = 877 114 руб/год.

Таким образом, ожидаемый экономический эффект составит:

Э = 877 144 - 0,15 * 81 837 = 864 868 руб.

6.5 Сопоставление технико-экономических характеристик разработки с аналогом

Обоснование выбора критериев для сравнения:

Аналогом для моей разрабатываемой информационной системы является «Поставщик++».

При сопоставлении аналога и разработки необходимо выбрать наиболее важные и значимые критерии с позиций конечного потребителя. Они должны быть с одной стороны значимыми и характеризовать аналог и разработку, с другой стороны должны иметь количественную оценку и с третьей стороны должны быть некоррелируемые (независимые). [9]

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

1) количественные параметры:

- быстродействие;

2) качественные параметры, имеющие количественную оценку:

- удобство пользования;

- оперативность получения результатов

3) новые возможности:

- автоматизация.

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

Выбранные критерии сведены в таблицу.

Таблица 6.2 - Перечень критериев для сравнения разработки и аналога

Количественные параметры	Качественные параметры	Новые возможности
1. Быстродействие 2. Надежность	3. Удобство пользования 4. Оперативность получения результатов	5. Автоматизация

На основании пяти выбранных критериев проведем стоимостную оценку аналога и разработки. Расчет сравнительной технико-экономической эффективности аналога и разработки: Оценим качество аналога и разработки по каждому i-ому показателю качества по 5-ти бальной шкале. Предлагается следующая шкала оценок.

Таблица 6.3 - Шкала оценок

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Определим каждому критерию весовой коэффициент k_j, причем

k_j= 1, (6,14)

Результаты сравнения сведем результаты сравнения в таблицу. Для аналога и для разработки посчитаем интегральный технико-экономический показатель: для аналога Q_а:

, (6,15)

и для разработки:

, (6,16)

Интегральный технико-экономический показатель может дать полезную информацию только при сопоставлении с аналогичным показателем, одних и тех же критериев, одних и тех же экспертов. [9]

В результате сопоставления этих интегрально технико-экономических показателей получаем сравнительную технико-экономическую эффективность.

Таблица 6.4 - Оценка технико-экономической эффективности

Параметр, оценка	Весовой коэффициент	Аналог	Разработка
Быстродействие	0,2	2	0,4	3	0,6
Надежность	0,15	3	0,45	3	0,45
Удобство пользования	0,15	3	0,45	4	0,6
Оперативность получения результатов	0,2	3	0,6	3	0,6
Автоматизация	0,3	2	0,6	3	0,9
Интегральный технико-экономический показатель, Q		Qa = 2,5	Qр = 3,15

Интегральный технико-экономический показатель, таким образом, равен:

Q = Q_р / Q_a, (6,17)

Q = 3,15/2,5 = 1,26

ВЫВОД: значение сравнительной технико-экономической эффективности больше 1,2, что говорит о положительной оценки целесообразности внедрения разработки, по сравнению с аналогом «Поставщик++».

7. Безопасность и экологичность работы

7.1 Анализ безопасности процесса эксплуатации разрабатываемой ИС

В данном дипломном проекте проведен анализ безопасности и экологичности эксплуатации разрабатываемой информационной системы отдела закупок торгового предприятия «ИнТорг».

7.1.1 Особенности функционального назначения ИС

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

Работа пользователя с системой описана в разделе 4 «Интерфейс информационной системы».

7.1.2 Системный анализ безопасности эксплуатации ИС

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

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

Таким образом, возможно 3 причины сбоя: ошибка в программе (внешней или внутренней), аппаратная ошибка, ошибка человека. 80% сбоев происходят из-за ошибки человека из-за отсутствия инструкции.

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

Рис. 7.2.1 Дерево отказов ИС

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

Ошибка SQL-сервера:

А1 - сбой в работе;

А2 - неверная конфигурация;

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

А3 - ошибки в указании домена/шлюза,

А4 - ошибки в указании адреса сервера DNS;

А5 - неверный статический IP-адрес;

Ошибка ОС:

А6 - недостаток ресурсов;

А7 - конфликт ресурсов;

А8 - деструктивные действия вирусных программ;

Ошибки разработчика:

A9 - ошибки при программировании;

А10 - ошибки при проектировании;

Ошибки системной безопасности:

А11 - хранение пароля в открытом виде;

А12 - ошибки в разграничении прав доступа;

А13 - действия вирусов;

А14 - действия хакеров;

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

А15 - неподходящая рабочая обстановка;

А16 - утомление;

А17 - низкая стрессоустойчивость;

А18 - отсутствие интереса к работе

Аварийное отключение электроснабжения:

А19 - Повреждение в сети связанные с перепадами напряжения, грызунами и прочими внешними факторами;

А20 - Экстремальные погодные условия;

Ошибки оборудования:

А21 - полный отказ оборудования;

А22 - ошибки несовместимости;

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

Следует отметить, что блок А16 «Утомляемость» является недостаточно детально рассмотренным, т.к. факторов, влияющих на утомляемость человека, может быть очень много.

7.1.3 Анализ условий труда оператора при эксплуатации разрабатываемой ИС

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

При оценке напряженности трудовой деятельности, которую предстоит осуществлять оператору в процессе эксплуатации разрабатываемой ИС, использовалось руководство P 2.2.2006 - 05 «Гигиенические критерии оценки условий труда по показателям вредности и опасности факторов производственной среды, тяжести и напряженности трудового процесса».

В соответствии с руководством труд классифицируется по четырем классам: оптимальные условия труда (класс 1.0); допустимые условия труда (класс 2.0); вредные условия труда (класс 3). Вредные условия труда по степени превышения гигиенических нормативов и выраженности изменении в организме работающих, подразделяются на 4 степени вредности: 1 степень 3 класса (3.1); 2 степень 3 класса (3.2); 3 степень 3 класса (3.3); 4 степень 3 класса (3.4). Опасные (экстремальные) условия труда (класс 4.0).

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

Таблица 7.1 - Оценка напряженности труда

Наименование показателя	Заключение	Оценка
1. Нагрузки интеллектуального характера:
1.1. Содержание работы	Решение простых задач по инструкции	2.0
1.2. Восприятие сигналов (информации) и их оценка	Восприятие сигналов с последующей коррекцией действий и операций	2.0
1.3. Распределение функций по степени сложности задания	Обработка, выполнение задания и его проверка	2.0
1.4. Характер выполняемой работы	Работа выполняется по графику	2.0
2. Сенсорные нагрузки
2.1. Длительность сосредоточенного наблюдения (% времени смены)	26 - 50	2.0
2.2. Плотность сигналов (световых, звуковых) и сообщений в среднем за 1 час работы	до 75	1
2.3. Число производственных объектов одновременного наблюдения	Нет	1
2.4. Размер объекта различения (при расстоянии от глаз работающего до объекта различения не более 0,5 м) в мм при длительности сосредоточенного наблюдения (% времени смены)	2 - 5 мм Более 50%	2
2.5. Работа с оптическими приборами (микроскопы, лупы и т.п.) при длительности сосредоточенного наблюдения	Не ведется	1
2.6. Наблюдение за экранами видеотерминалов(часов в смену):	до 3	2
2.7. Нагрузка на слуховой анализатор (при производственной необходимости восприятия речи или дифференцированных сигналов)	Разборчивость слов и сигналов от 100 до 90 %. Помехи отсутствуют	1
2.8. Нагрузка на голосовой аппарат (суммарное количество часов, наговариваемое в неделю)	До 20	2
3. Эмоциональные нагрузки
З.1. Степень ответственности за результат собственной деятельности. Значимость ошибки	Несет ответственность за выполнение отдельных элементов заданий. Влечет за собой дополнительные усилия в работе со стороны работника	1
3.2. Степень риска для собственной жизни	Исключена	1
3.3. Степень ответственности за безопасность других лиц	Исключена	1
3.4. Количество конфликтных ситуаций, обусловленных профессиональной деятельностью, за смену	1 - 3	2
4. Монотонность нагрузок
4.1. Число элементов (приемов), необходимых для реализации простого задания или в многократно повторяющихся операциях	9 - 6	2
4.2. Продолжительность (в сек) выполнения простых заданий или повторяющихся операций	100 - 25	2
4.3. Время активных действий (в % к продолжительности смены). В остальное время - наблюдение за ходом производственного процесса

Подобные документы

• Разработка информационной системы для отдела грузоперевозок ОАО "Кричеврайагропромтехснаб"

  Проектирование многопользовательской информационной системы для автоматизации работы диспетчера отдела грузоперевозок. Выбор среды программирования. Разработка программного обеспечения, таблиц базы данных АСОИ. Построение диаграмм классов и деятельности.
  
  курсовая работа [298,1 K], добавлен 03.06.2014
  

• Автоматизация комплекса задач менеджера отдела продаж торговой организации

  Анализ деятельности компании в целом и отдела продаж в частности. Описание состояния информационной системы предприятия. Декомпозиция бизнес-процессов, протекающих в отделе продаж. Проектирование информационной системы, ее программное обеспечение.
  
  дипломная работа [2,4 M], добавлен 29.08.2014
  

• Анализ и моделирование информационной системы кредитного отдела OAO "Сбербанк"

  Описание кредитного отдела OAO "Сбербанк". Информационные системы и технологии кредитного отдела. Программные продукты, предлагаемые для банков, в частности для кредитной сферы. Варианты улучшения существующей информационной системы кредитного отдела.
  
  курсовая работа [457,9 K], добавлен 24.09.2014
  

• Анализ деятельности отдела информационной безопасности ООО ГП "Спектр"

  Изучение профессиональных и должностных обязанностей специалистов отдела информационной безопасности. Характеристика процесса внедрения новой информационной системы предприятия. Создание плановых, диспозитивных и исполнительных информационных систем.
  
  отчет по практике [180,7 K], добавлен 08.06.2015
  

• Модель информационной системы отдела снабжения предприятия ООО "Бисквит"

  Описание отдела снабжения предприятия ООО "Бисквит". Функциональная схема и сценарии процесса пополнения сырьевых запасов, определения норм закупки сырья. Оптимизация и реинжиниринг бизнес-процессов. Проектирование информационной системы, ее параметры.
  
  дипломная работа [1,9 M], добавлен 11.12.2012
  

• Система поддержки и принятия решений "Маркетинг"

  Схема организационной структуры отдела маркетинга предприятия, его основные задачи и функции. Разработка специализированной системы автоматизации маркетинговой деятельности, ее характеристика и оценка эффективности. Информационное обеспечение системы.
  
  дипломная работа [3,7 M], добавлен 30.07.2009
  

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

  Исследование предметной области. Принципы системы планирования транспортного отдела предприятия. Создание организационной модели, с помощью case средств Bp win4. Основные направления совершенствования организации работы внутризаводского транспорта.
  
  курсовая работа [961,0 K], добавлен 07.06.2016
  

• Информационная система отдела кадров

  Анализ предметной области. Технико-экономическое обоснование разработки программного обеспечения информационной системы отдела кадров. Проектирование пользовательского интерфейса. Оптимизация параметров микроклимата помещений, оборудованных ПЭВМ.
  
  дипломная работа [6,8 M], добавлен 16.01.2015
  

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

  Изучение теоретических основ автоматизации документооборота отдела по работе с физическими лицами коммерческого банка. Общая характеристика работы отдела банка. Описание процесса создания базы данных с помощью выбранного программного средства MS Access.
  
  дипломная работа [5,5 M], добавлен 10.07.2014
  

• Проектирование системы информационной безопасности

  Анализ инфраструктуры ООО магазин "Стиль". Создание системы информационной безопасности отдела бухгалтерии предприятия на основе ее предпроектного обследования. Разработка концепции, политики информационной безопасности и выбор решений по ее обеспечению.
  
  курсовая работа [2,2 M], добавлен 17.09.2010
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам