Автоматизированное рабочее место инженера по гарантии СТО "Континент"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 27.04.2014
Размер файла 2,3 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Расширенная поддержка событийно-ориентированного программирования выгодно отличает язык программирования C# от целого ряда предшественников. Объединение лучших идей современных языков программирования (Java, C++, Visual Basic и др.) делает язык C# не просто суммой их достоинств, а языком программирования нового поколения.

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

В данном разделе были выбраны и описаны средства разработки и даны основные понятия реляционным базам данных. В качестве средства разработки пользовательского интерфейса была выбрана среда быстрой разработки программ MS Visual Studio 2010 и язык программирования C#. Для разработки базы данных по желанию заказчика была выбрана система управления базой данных MS SQL 2008 express.

3. Разработка программы и создание базы данных

3.1 Проектирование базы данных

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

Представленная информационная система основана на БД реляционного типа.

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

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

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

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

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

Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным диаграммам и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей[13].

При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.

3.2 Разработка концептуальной модели базы данных

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

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

Примером такого подхода можно назвать структуру таблиц для хранения машин клиентов и сведений о них показанной на рисунке 3.1

Рисунок 3.1 - Структуру таблиц для хранения машин клиентов

В основной таблице «car» храниться только основные параметры автомобиля:

Таблица 3.1 - Типы полей в таблице «car»

Имя поля

Тип поля

Описание

car_id

Счётчик

Уникальный код

brand_id

Числовой

Ссылка на таблицу ценовых групп

client_id

Числовой

Ссылка на таблицу клиентов

number

Текстовый

Государственный номер автотранспортного средства

model

Текстовый

модель машины

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

Таблица 3.2 - Типы полей в таблице «car_param»

Имя поля

Тип поля

Описание

car_parm_id

Счётчик

Уникальный код

car_parm_name

Числовой

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

car_parm_value

Текстовый

Строковое значение параметра

car_id

Числовой

Ссылка на таблицу машин

В таблица «car_param_text» хранятся названия параметров машин, она содержит следующий набор полей:

Таблица 3.3 - Типы полей в таблице «car_param_text»

Имя поля

Тип поля

Описание

car_param_text_id

Счётчик

Уникальный код

car_param_text

Текстовый

Название параметра

Таблица «brand_machine» хранит информацию о группах машин, она содержит следующий набор полей:

Таблица 3.4 - Типы полей в таблице «brand_machine»

Имя поля

Тип поля

Описание

brand_machine_id

Счётчик

Уникальный код

brand_machine_name

Текстовый

Название группы машин

brand_machine_coef

Числовой

Ценовой коэффициент группы машин

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

Структура таблиц для описания клиентов, предназначена для хранения информации о клиентах автосервиса и их параметров, показана ниже на рисунке 3.2.

Рисунок 3.2 - Структуру таблиц для информации о клиентах автосервиса и их параметров

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

Таблица «сlient» -- основная таблица для хранения клиентов содержит следующий набор полей.

Таблица 3.5 - Типы полей в таблице «сlient»

Имя поля

Тип поля

Описание

client_id

Счётчик

Уникальный код

client_name

Текстовый

Имя клиента может содержат фамилию и инициалы клиента

Таблица «client_param» расширяет информацию о клиенте, здесь хранятся все остальные имеющиеся параметры и содержит следующий набор полей:

Таблица 3.6 - Типы полей в таблице «client_param»

Имя поля

Тип поля

Описание

client_parm_id

Счётчик

Уникальный код

client_parm_name

Текстовый

Название параметра, здесь возможно применение как строкового идентификатора так и русского названия параметра

client_parm_value

Текстовый

Строковое значение параметра

client_id

Числовой

Ссылка на таблицу клиентов определяющая с каким клиентом соотносится параметр

Структура таблиц для описания сотрудников. В этих таблицах хранятся сведения о сотрудниках и выполняемых ими работах, структура показана ниже на рисунке 3.3.

Рисунок 3.3 - Структура таблиц для хранения сотрудников

Таблица «workman» - основная таблица для хранения записей о сотрудниках, которая содержит следующий набор полей:

Таблица 3.7 - Типы полей в таблице «WorkMan»

Имя поля

Тип поля

Описание

workman_id

Счётчик

Уникальный код

post_id

Числовой

Ссылка на таблицу должностей

workman_name

Текстовый

Фамилия имя и отчество сотрудника

adress

Текстовый

Адрес сотрудника

Таблица «post» - таблица должностей сотрудников содержит следующий набор полей:

Таблица 3.8 - Типы полей в таблице «Post»

Имя поля

Тип поля

Описание

post _id

Счётчик

Уникальный код

post _name

Числовой

Название должности

Таблица «workmanwork» - таблица связывающая сотрудников и работы содержит следующий набор полей:

Таблица 3.9 - Типы полей в таблице «workmanwork»

Имя поля

Тип поля

Описание

workmanwork _id

Счётчик

Уникальный код

workman_id

Числовой

Ссылка на таблицу сотрудников

work_id

Числовой

Ссылка на таблицу работ

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

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

Рисунок 3.4 - Структура таблиц для хранения работ

Таблица «work» - таблица работы содержит следующий набор полей:

Таблица 3.10 - Типы полей в таблице «work»

Имя поля

Тип поля

Описание

work _id

Счётчик

Уникальный код

work_name

Текстовый

Название работы

cost_basis

Числовой

Основная стоимость

group_id

Числовой

Ссылка на таблицу групп работ определяет к какой группе относится работа.

warrentytime

Текстовый

Время предоставляемой гарантии

cost_time

Текстовый

Время выполнения

Таблица «workgroup» - Таблица групп работ содержит следующий набор полей:

Таблица 3.11 - Типы полей в таблице «workgroup»

Имя поля

Тип поля

Описание

workgroup_id

Счётчик

Уникальный код

workgroup_name

Текстовый

Название группы работы

Структура таблиц для описания ремонтов, этих таблицах хранятся сведения о заявках на ремонтах, структура показана ниже на рисунке 3.5.

Рисунок 3.5 - Структура таблиц для хранения ремонтов

Таблица «repair» - таблица ремонтов содержит следующий набор полей:

Таблица 3.12 - Типы полей в таблице «repair»

Имя поля

Тип поля

Описание

repair_id

Счётчик

Уникальный код

repair_name

Текстовый

Описание ремонта

intime

Текстовый

Время принятие на ремонт

outtime

Текстовый

Время окончания ремонта

cost

Числовой

Стоимость

iswarenty

Логический

Время выполнения

carid

Числовой

Ссылка на таблицу машин, определяет к какой машине относится ремонт.

Таблица «repairwork» - таблица работ выполняемых во время ремонта содержит следующий набор полей:

Таблица 3.13 - Типы полей в таблице «repairwork»

Имя поля

Тип поля

Описание

repairwork_id

Счётчик

Уникальный код

repair_id

Текстовый

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

work_id

Числовой

Ссылка на таблицу работ

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

· spare_par;

· distributor;

· warehouse;

· units;

· refund_details.

Рисунок 3.6 - Структура таблиц для хранения запчастей и ведения складского учета

Таблица «spare_part» - таблица деталей (запчастей) содержит следующий набор полей:

Таблица 3.14 - Типы полей в таблице «spare_part»

Имя поля

Тип поля

Описание

spare_part_id

Счётчик

Уникальный код

spare_part_name

Текстовый

Наименование детали

distributor_id

Числовой

Ссылка на таблицу поставщиков

unit_id

Числовой

Ссылка на таблицу единиц измерений

Таблица «distributor» предназначена для хранения информации о поставщиках деталей. Таблица поставщиков содержит следующий набор полей:

Таблица 3.15 - Типы полей в таблице «distributor»

Имя поля

Тип поля

Описание

distributor _id

Счётчик

Уникальный код

distributorname

Текстовый

Наименование детали

Таблица «units» предназначена для хранения единиц измерений, она содержит следующий набор полей:

Таблица 3.16 - Типы полей в таблице «units»

Имя поля

Тип поля

Описание

units_id

Счётчик

Уникальный код

units_name

Текстовый

Название единиц измерений

units_count

Числовой

Количество единиц

Таблица «wareshouse» предназначена для хранения сведений о деталях на складе, она содержит следующий набор полей:

Таблица 3.17 - Типы полей в таблице «wareshouse»

Имя поля

Тип поля

Описание

wareshouse _id

Счётчик

Уникальный код

spare_part_id

Числовой

Ссылка на таблицу деталей

count

Числовой

Количество единиц

units_id

Числовой

Ссылка на таблицу единиц измерений

Таблица «refund_details» предназначена для хранения сведений о возвращенных поставщику деталей, она содержит следующий набор полей:

Таблица 3.18 - Типы полей в таблице «refund_details»

Имя поля

Тип поля

Описание

refund_details_id

Счётчик

Уникальный код

spare_part_id

Числовой

Ссылка на таблицу деталей

count

Числовой

Количество единиц

units_id

Числовой

Ссылка на таблицу единиц измерений

other

Описание причины возврата

В спроектированной базе данных таблицы между собой связаны отношением «один-ко-многим». Все связи отображены на схеме базы данных изображенной на рисунке 3.7 ниже:

Рисунок 3.7 - Схема данных

3.3 Запросы

При разработке автоматизированной системы использовался современный инструмент предлагаемый Microsoft - Linq to SQL, предназначенная для решения проблемы объектно-реляционного отображения, потому при разработке не было необходимости создавать классические SQL запросы. Для облегчения взаимодействия клиентского приложения с базой данных был разработан проект (библиотека) реализующая механизм сокрытия деталей доступа к данным реализующий паттерн программирования репозиторий.

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

Методы интерфейса IRepository обеспечивают полный набор CRUD-операций.

GetAll - возвращает всю совокупность объектов данного типа, хранимых в БД. Фильтрация, сортировка и другие операции над выборкой объектов осуществляются на более высоком уровне, благодаря использованию интерфейса IQueryable<T>.

Save - сохраняет объект модели в базе данных. В случае, если он новый, выполняется операция INSERT, иначе - UPDATE.

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

Для получения данных в этом случае используется шаблонная функция.

public IQueryable<T> GetAll<T>() where T : class

{

try

{

return _datacontext.GetTable<T>();

}

catch(Exception ex)

{

_appcontext.SysMsg.ReportMsg(ex.Message, avto.SysMsg.Interfaces.MsgType.Error);

}

return Queryable.AsQueryable<T>(new List<T>());

}

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

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

public bool Del<T>(T obj) where T:class

{

try

{

_datacontext.GetTable<T>().DeleteOnSubmit(GetById<T>(GetID(obj)));

SubmitChangesinDC();

}

catch (Exception ex)

{

return false;

}

return true;

}

Для удаления объектов требующих дополнительных действий используются переопределенные методы параметры с жестко определенными параметрами например public bool Del(Car Obj) при выполнении система сама определит какой метод исполнять.

Для добавления или изменения создан один унифицированный метод

public bool Save<T>(T obj) where T: class

{

try

{

//Получает идентификатор

int ID = GetID(obj);

//если объект присутствует в базе данных

if (ID > 0)

{

//Получаем объект по идентификатору это необходимо если объект создан не при помощи Linq

var oldobj = GetById<T>(ID);

if (oldobj != null)

{

foreach (PropertyInfo propertyitem in obj.GetType().GetProperties())

{

PropertyInfo oldproperty =

oldobj.GetType().GetProperty(propertyitem.Name);

oldproperty.SetValue(oldobj, propertyitem.GetValue(obj, null), null);

}

}

else

{

_appcontext.SysMsg.ReportMsg("Ошибка при попытке добавить данные" + obj.GetType().ToString() , avto.SysMsg.Interfaces.MsgType.Error);

return false;

}

}

else

{

//Инициируем добавление объекта в таблицу

_datacontext.GetTable<T>().InsertOnSubmit(obj);

}

Инициируем принятие изминений

SubmitChangesinDC();

}

catch (Exception ex)

{

_appcontext.SysMsg.ReportMsg(ex.Message, avto.SysMsg.Interfaces.MsgType.Error);

return false;

}

return true;

}

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

GetByFilter<Client_Param>(it=> it.Client_Param_name==textBox2.Text && it.Client_Param_Value==textBox3.Text && it.Client.Client_id ==client.Client_id )

Этот механизм реализован функцией построенной вокруг стандартной для linq функции Where()

public IQueryable<T> GetByFilter<T>(Expression<Func<T, bool>> filter) where T:class

{

try

{

return _datacontext.GetTable<T>().Where(filter);

}

catch (Exception ex)

{

_appcontext.SysMsg.ReportMsg(ex.Message,
avto.SysMsg.Interfaces.MsgType.Error);

}

return Queryable.AsQueryable<T>(new List<T>());

}

3.4 Структура программного комплекса

Так как комплекс состоит из нескольких модулей, необходимо пояснить, как происходит их взаимодействие. Общая схема приведена на рисунке 3.8

Рисунок 3.8 - Структур системы программного комплекса

В основе системы лежит база данных с ней напрямую взаимодействует библиотека AVTO.DATA - библиотека взаимодействия с базой данных.

Узловым проектом системы является библиотека Avto.Interfeise - в которой сосредоточены все применяемые в проекте интерфейсы. Через которые и осуществляется взаимодействие между модулями системы.

На рисунке 3.7 проектом AVTO обозначен исполняемый модуль системы содержащий также и базовые графические элементы управления.

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

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

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

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

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

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

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

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

3.5 Разработка пользовательского интерфейса

Для разработки пользовательского интерфейса разработочного программного средства используется WPF. Это система нового поколения для построения клиентских приложений Windows с визуально привлекательными возможностями взаимодействия с пользователем. С помощью WPF можно создавать широкий спектр как автономных, так и размещенных в браузере приложений. В основе WPF лежит векторная система визуализации, не зависящая от разрешения и созданная с расчетом на возможности современного графического оборудования. WPF расширяет базовую систему полным набором функций разработки приложений, в том числе языком XAML (Extensible Application Markup Language), элементами управления, привязкой данных, макетом, двух- и трехмерной графикой, анимацией, стилями, шаблонами, документами, мультимедиа, текстом и оформлением. WPF входит в состав Microsoft .NET Framework и позволяет создавать приложения, включающие другие элементы библиотеки классов .NET Framework.

В основе WPF лежит векторная система визуализации, не зависящая от разрешения устройства вывода и созданная с учётом возможностей современного графического оборудования. WPF предоставляет средства для создания визуального интерфейса, включая Язык XAML (Extensible Application Markup Language), элементы управления, привязку данных, макеты, двухмерную и трёхмерную графику, анимацию, стили, шаблоны, документы, текст, мультимедиа и оформление[14].

Графической технологией, лежащей в основе WPF, является DirectX, в отличие от Windows Forms, где используется GDI/GDI+. Производительность WPF выше, чем у GDI+ за счёт использования аппаратного ускорения графики через DirectX.

Главное окно программы изображенное ниже на рисунке 3.9. Его можно условно разделить на несколько частей.

Рисунок 3.9 - Стартовое окно программы

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

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

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

Рисунок 3.10 - Строка результата поиска

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

В этом режиме возможно добавление или удаление работ, а так же редактирование.

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

Рисунок 3.11 - Окно редактирования

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

Рисунок 3.12 - Окно редактирования

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

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

На рисунке 3.12 выше изображена вкладка управления должностями сотрудников. Таблица должностей содержит один изменяемый параметр, что отображает единственное поле ввода. Более специфичным является справочник клиентов показанный ниже на рисунке 3.13.

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

Рисунок 3.13 - Окно справочника клиентов

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

Рисунок 3.14 - Окно справочника деталей

Одним из базовых справочников является справочник управления машинами клиентов (см. рисунок 3.15). Плагин этого справочника позволяет создавать и удалять машины клиентов, а также управлять дополнительными параметрами машин.

Рисунок 3.15 - Окно справочника машин клиентов

Еще одним основным справочником является справочник работ показанный ниже на рисуноке 3.16

Рисунок 3.16 - Окно справочник работ

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

Рисунок 3.17 - Блок расширения отчетов

Система подключает имеющиеся плагины отчетов. Которые предоставляют функции:

· предварительного просмотра - кнопка «просмотр»;

· сохранения отчета во внешних форматах «rtf», «doc», «xls», «pdf», «html» - кнопка «сохранить»;

· отправка отчета сразу на принтер - кнопка «печать»

В качестве генератора отчетов используется Crystal Report - фактически стандартного генератора отчетов для платформы «.NET».

3.4 Тестирование программного обеспечения

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

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

Рисунок 3.18 - Запрос на удаление

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

Рисунок 3.19 - Окно предупреждения.

Если же пользователь попытается добавить существующую запись или внести исправления приводящие к дублированию, будет также выдано предупреждение (см. рисунок 3.20) и изменения не произойдет.

Рисунок 3.20 - Окно предупреждения

В случае ошибочно введенных данных будет выдано окно сообщения об ошибке показанное на рисунке 3.21.

Рисунок 3.21 - Окно сообщения об ошибке

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

Рисунок 3.22 - Окно сообщения об ошибке

Существует вероятность ошибки в процессе загрузки плагина расширения, в этом случае будет выдано сообщение с описанием возникшей проблемы (см. рисунок 3.23) плагин вызвавший ошибку не будет загружен. При этом работоспособность приложения в целом не пострадает.

Рисунок 3.23 - Сообщение об ошибке загрузки плагина

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

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

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

4. Экономический раздел

4.1 Расчёт затрат на разработку программного комплекса

Стоимостная оценка затрат определяется с учётом степени затрат на всех этапах инновационного процесса: проектирование, производство, эксплуатация.

В состав затрат на разработку и реализацию проекта включается стоимость всех расходов, необходимых для реализации комплекса работ, составляющих содержание данной разработки [15]. Смета затрат включает в себя следующие статьи расходов:

· заработная плата исполнителям;

· дополнительная заработная плата;

· отчисления во внебюджетные фонды;

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

· расходы на оборудование;

· затраты на расходные материалы.

Необходимо рассчитать заработную плату исполнителям. Месячные оклады исполнителей:

Научный руководитель - старший преподаватель каф. ИТ.

Зр = 10000 р.

Исполнитель - инженер-программист.

Зи = 5500 р.

Учитывая участие каждого специалиста в разработке по количеству дней, а также число рабочих дней в месяце (25 дней), найдём заработную плату каждого исполнителя. Результат расчётов сведён в таблицу 4.1.

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

Исполнитель

Оклад, руб.

Трудоемкость, дней.

Дневная ставка, руб.

Основная з/п, руб.

Руководитель

10000

10

340

3400

Инженер

5500

100

190

19000

Полную заработную плату всех исполнителей рассчитаем по формуле:

         (4.1)
где Зо - основная зарплата всех исполнителей;
Зi - заработная плата i-го исполнителя;
N - количество исполнителей.
Используя данные таблицы 5.1, находим по формуле Зо:
Зо = 3400+ 19000= 22400 руб.
Рассчитаем дополнительную зарплату. Подсчитаем величину районного коэффициента (Рк), с учётом поясного коэффициента (Кп = 30%).
Рк = Зо  Кп   (4.2)
Рк = 22400  0.3 = 6720 руб.
Подсчитаем величину отпускных и премиальных отчислений (О), которые составляют 10% от основной заработной платы:
О = 22400  0.1 = 2240 руб.
Рассчитаем дополнительную заработную плату, которая складывается из величины отпускных и премиальных отчислений и районного коэффициента:
Здоп = Рк + О  (4.3)
Здоп = 6720 + 2240 = 8960 руб.
Зная основную и дополнительную зарплату, найдём фонд заработной платы (ФЗП):
ФЗП = Здоп + Зо    (4.4)
ФЗП = 8960 + 22400 = 31360 руб.
Страховые взносы во внебюджетные фонды составляют 34% от фонда заработной платы.
Овф = 31360  0.34 = 9153,6 руб.
Накладные расходы составляют 20% от основной заработной платы:
НР = 22400  0.2 = 4480 руб.
Вычислим затраты на амортизацию вычислительной техники по следующей формуле:
Зам = (Сбал  Кам  Траб  Н)/Фг,  (4.5)
где Сбал - балансовая стоимость вычислительной техники (26000 руб);
Кам - коэффициент годовой амортизации оборудования;
Траб - время работы вычислительной техники (100 дней);
Н - количество единиц техники (1);
Фг - эффективный фонд времени оборудования (220 дней).
Коэффициент годовой амортизации определяется по формуле:
Kам = 1/Тс,  (4.6)
где Тс - срок службы оборудования (8 лет).
Кам = 1/8 = 0.125
Зам = (26000  0.125  100  1)/220 = 1477 руб.
Подсчитаем затраты на расходные материалы:
· вспомогательная литература - 1500 рублей;
· канцтовары - 400 рублей.
Итого - 1900 рублей.
На основе вышеприведённых расчётов составим полную смету затрат на дипломный проект (см. таблицу 4.2).

Таблица 4.2 - Смета затрат на выполнение дипломного проекта

Статья расходов

Сумма, руб.

Заработная плата исполнителям

22400

Дополнительная заработная плата

8960

Страховые взносы во внебюджетные фонды

9153

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

4480

Амортизационные расходы

1477

Затраты на расходные материалы

1900

Итого

47370

До внедрения каждый месяц 2 пользователя с зарплатой 7000 рублей в месяц выполняли данную работу. Ее годовая себестоимость в таком случае равна 12 * 2 * 7000 = 168000 рублей.

После внедрения эту же работу может выполнять 1 пользователь. Ее годовая себестоимость стала равной 12 * 1 * 7000 = 84000 рублей.

4.2 Оценка экономической эффективности эксплуатации комплекса

Расчет годового экономического эффекта в случае экономии при выполнении одной и той же работы производится по формуле (4.7):

Э=[(С1-С2)-Е*К] (4.7)

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

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

К - капитальные вложения на проектирование и внедрение проекта, руб.

С1 = 168000 руб.

С2 = 84000 руб.

К = 47370 руб.

Подставив значения в формулу (4.7) рассчитаем годовой экономический эффект

Э = (168000 - 84000) - 0,33*47370 = 68988 рублей

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

, (4.8)

E = 68988/45489 = 1,51

Так как Е>0,33, то проектирование и внедрение разрабатываемой системы эффективно.

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

, (4.9)

Tок = 45489 /68988= 0.66 года или примерно 8 месяцев.

Тк - нормальный срок окупаемости равен трем годам;

Тк > Ток - условие выполняется.

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

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

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

5. Безопасность жизнедеятельности

5.1 Гигиеническое нормирование условий труда программистов, операторов электронно-вычислительных машин

данные программирование оператор сервер

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

В производственных помещениях, в которых работа на видеодисплейных терминалах (ВДТ) и персональных электронно-вычислительных машинах (ПЭВМ) является основной, должны обеспечиваться параметры в соответствии с СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к персональным электронно-вычислительным машинам и организации работы».

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

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

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

В соответствии с требованиями СанПиН 2.2.2/2.4.1340-03 к уровням шума и вибрации на рабочих местах, оборудованных ПЭВМ:

· уровень шума на рабочем месте операторов видеоматериалов не должен превышать 50дБА;

· в залах обработки информации на вычислительных машинах - 65дБА;

· уровень шума на рабочем месте программистов должен составлять 45 дБА на частоте - 1000 Гц. Для снижения уровня шума стены и потолок помещений, где установлены компьютеры, могут быть облицованы звукопоглощающими материалами [16].

Кратковременное, так и длительное воздействие всех видов излучения от экрана монитора не опасно для здоровья персонала, обслуживающего компьютеры. Однако исчерпывающих данных относительно опасности воздействия излучения от мониторов на работающих с компьютерами не существует и исследования в этом направлении продолжаются. Более подробно о временных допустимых уровнях электромагнитных полей (ЭМП) написано в разделе 5.3.

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

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

Требования к помещениям для работы с ПЭВМ:

· площадь на одно рабочее место пользователей ПЭВМ с ВДТ на базе электроннолучевой трубки (ЭЛТ) должна составлять не менее 6 мІ, а на базе плоских дискретных экранов (жидкокристаллические, плазменные) - 4,5 м2;

· для внутренней отделки интерьера помещений, где расположены ПЭВМ, должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка - 0,7-0,8; для стен - 0,5-0,6; для пола - 0,3-0,5;

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

Вычислительная техника является в том числеи источником тепловыделений, что может привести к повышению температуры и снижению относительной влажности в помещении. Согласно ГОСТ 12.1.005-88 (2001) Системы стандартов безопасности труда (ССБТ) в помещениях, где установлены компьютеры, должны соблюдаться определенные параметры микроклимата, приведенные в таблице 5.1.

Таблица 5.1 - Оптимальные параметры микроклимата во всех помещениях с использованием ПЭВМ

Период года

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

Температура воздуха, СО

Относительная влажность воздуха, %

Скорость движения воздуха, м/с

Холодный

1 а

22-24

40-60

0,1

1 б

21-23

40-60

0,1

Теплый

1 а

23-25

40-60

0,1

1 б

22-24

40-60

0,2

Требования к микроклимату, содержанию аэроионов и вредных химических веществ в воздухе на рабочих местах, оборудованных ПЭВМ:

· в помещениях, оборудованных ПЭВМ, проводится ежедневная влажная уборка и систематическое проветривание после каждого часа работы на ПЭВМ;

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

Таблица 5.2 - Уровни ионизации воздуха помещений при работе на ВДТ и ПЭВМ

Уровни

Число ионов в 1 см куб. воздуха

n+

n-

минимально

необходимые

400

600

оптимальные

1500-3000

3000-5000

максимально

допустимые

50000

50000

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

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

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

Рабочее место и взаимное расположение всех его элементов (см. таблицу 5.3) должно соответствовать антропометрическим, физическим и психологическим требованиям. Большое значение имеет также характер работы. В частности, при организации рабочего места программиста должны быть соблюдены следующие основные условия: оптимальное размещение оборудования, входящего в состав рабочего места и достаточное рабочее пространство, позволяющее осуществлять все необходимые движения и перемещения.

Таблица 5.3 - Параметры оптимального рабочего места пользователя ПК

Элемент рабочего места

Параметры

Величина (мм)

Диапазон

регулирования (мм)

Рабочий стол

Высота рабочей поверхности

Ширина

Глубина

Пространство для ног:

- высота

- глубина на уровне колен

- глубина на уровне вытянутых ног

725

800, 1000,

1200,1400

800, 1000

600

450

650

680…800

-

-

-

-

-

-

Рабочий стул

Ширина сиденья

Глубина сиденья

Высота поверхности сиденья

Угол наклона сиденья:

- вперед

- назад

Высота опорной поверхности спинки

Ширина спинки

Радиус кривизны спинки в горизонтальной плоскости

Угол наклона спинки в вертикальной плоскости

Расстояние от переднего края сиденья до спинки

400

400

475

00

00

300

380

400

00

330

-

-

400…550

00…150

00…150

280…320

-

-

-300…+300

260…400

Подлокотники

Длина

Ширина

Высота над сиденьем

Расстояние между подлокотниками

250

50…70

230

425

-

-

200…260

350…500

Подставка для ног

Ширина

Глубина

Высота

Наклон опорной поверхности

300

400

150

00

-

-

-

00…200

Общие требования к организации рабочих мест пользователей ПЭВМ:

· при размещении рабочих мест с ПЭВМ расстояние между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), должно быть не менее 2,0 м, а расстояние между боковыми поверхностями видеомониторов - не менее 1,2 м;

· экран видеомонитора должен находиться от глаз пользователя на расстоянии 600 - 700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов;

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

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

5.2 Ответственность за нарушение законодательных и нормативно-правовых актов по безопасности труда

Нарушение законодательных и нормативно-правовых актов по безопасности труда влечет за собой определенную ответственность в соответствии со статьями трудового кодекса РФ (ТК РФ) от 30.12.2001.

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

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

· замечание;

· выговор;

· увольнение по соответствующим основаниям.

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

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

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

Юридические лица, должностные лица и граждане за противоправное, виновное действие (бездействие), установленное трудовым законодательством и иными нормативными правовыми актами, содержащими нормы трудового права, привлекаются к административной ответственности в порядке, установленном Кодексом об административных правонарушениях РФ (Федеральный закон от 31 января 2012 года № 2 - ФЗ) и законами субъектов РФ.

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

· предупреждение;

· административный штраф;

· возмездное изъятие орудия совершения или предмета административного правонарушения;

· конфискация орудия совершения или предмета административного правонарушения;

· лишение специального права, предоставленного физическому
лицу;

· административный арест;

· дисквалификации.

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

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

Уголовная ответственность налагается в соответствии с Уголовным кодексом РФ:

· нарушение правил охраны труда;

· преступления против жизни и здоровья;

· преступления против интересов службы, суда, органов дознания, надзора и контроля.

5.3 Защита персонала предприятий ИВО от опасных и вредных излучений

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

· мягкого рентгеновского;

· ультрафиолетового 200-400 нм;

· видимого 400-700 нм;

· ближнего инфракрасного 700-1050 нм;

· радиочастотного 3 кГц-30 МГц;

· электростатических полей.

Ультрафиолетовое излучение полезно в небольших количествах, но в больших дозах приводит к дерматиту кожи, головной боли, рези в глазах. Инфракрасное излучение приводит к перегреву тканей человека (особенно хрусталика глаза), повышению температуры тела. Уровни напряженности электростатических полей должны составлять не более 20 кВ/м. Поверхностный электростатический потенциал не должен превышать 500 В [19].

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

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

Временные допустимые уровни электромагнитных полей (ЭМП), создаваемых ПЭВМ указаны в таблице 1.1;

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

Наименование параметров

Временные допустимые уровни ЭМП

Напряженность электрического поля

в диапазоне частот 5 Гц - 2 кГц

25 В/м

в диапазоне частот 2 кГц - 400 кГц

2,5 В/м

Плотность магнитного поля

в диапазоне частот 5 Гц - 2 кГц

250 нТл

в диапазоне частот 2 кГц - 400 кГц

25 нТл

Электростатический потенциал экрана видеомонитора

500 В

Может возникнуть опасность по уровням напряженности электромагнитного поля. На расстоянии 5-10 см от экрана и корпуса монитора уровни напряженности могут достигать 140 В/м по электрической составляющей, что значительно превышает допустимые значения СанПиН 2.2.2/2.4.1340-03.

В Российской Федерации создана Система сертификации электрооборудования на соответствие стандартам безопасности (ССЭСБ). По требованиям ССЭСБ обязательная сертификация ПЭВМ проводится на соответствие условиям, установленным в следующих стандартах:

· ГОСТ Р МЭК 60950-2002. Безопасность оборудования информационных технологий.

· ГОСТ Р 50948-01. Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности.

· ГОСТ Р 50949-01. Средства отображения информации индивидуального пользования. Методы измерений и оценки эргономических параметров и параметров безопасности.

· ГОСТ Р 50923-96. Рабочее место оператора. Общие эргономические требования и требования к производственной среде. Методы измерения.

· СанПиН 2.2.2/2.4.1340-03. Гигиенические требования к персональным электронно-вычислительным машинам и организация работы.

Существуют также международные стандарты:

· Energy Star, TCO-92, VESA DPMS - по энергосбережению.

· EN 55022, Nordic Swan, ISO 9241, MPR-II, TCO - 99,03 - защита от излучения.

· FCC класс B, CIPSPR 22 - электромагнитная совместимость.

· ISO9241-3, ARAG, ARAS, AGRAS - антибликовая защита.

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

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

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

Заключение

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


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

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

    курсовая работа [1,5 M], добавлен 26.02.2015

  • Функциональная модель системы. Проектирование схемы базы данных. Проектирование архитектуры системы. Принцип технологии клиент-сервер. Построение схемы ресурсов. Выбор программных средств. Разработка базы данных с использованием Microsoft SQL Server.

    дипломная работа [1,1 M], добавлен 30.03.2015

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

    курсовая работа [28,2 K], добавлен 17.12.2011

  • Модели баз данных. Локальная, файл-серверная, клиент-серверная и распределенная архитектуры. Технология BDE для доступа к данным. Драйверы баз данных. Создание таблицы, интерфейс программы, дерево объектов, инсталлятор. Системы визуальной разработки.

    курсовая работа [989,5 K], добавлен 04.06.2013

  • Представление данных в памяти компьютера. Обобщенные структуры и модели данных. Методы доступа к информации. Физическая организация системы управления базами данных, структура сервера. Архитектура "клиент-сервер". Создание базы данных с помощью "Денвер".

    курсовая работа [770,3 K], добавлен 17.11.2014

  • Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.

    курсовая работа [88,9 K], добавлен 11.04.2010

  • Классификации баз данных и СУБД. Технология модели "клиент-сервер". Особенности языка структурированных запросов SQL. Структура и назначение операторов определения, манипулирования и управления данными. Разработка реляционной БД, создание SQL запросов.

    курсовая работа [1,4 M], добавлен 17.08.2015

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

    дипломная работа [1,8 M], добавлен 05.03.2011

  • Рассмотрение архитектуры "файл-сервер" и двух- и трехуровневых архитектур "клиент-сервер". Модель сервера приложений и свойства "идеальной" системы управления распределенными базами данных. Способы распределения функций обработки логики запроса.

    презентация [60,2 K], добавлен 19.08.2013

  • Многоуровневые архитектуры клиент–сервер. Диаграммы классов, реализующих уровни презентации, бизнес–логики и базы данных приложения. Словесное описание процесса выполнения транзакций. Создание, изменение и удаление хранимых процедур, их выполнение.

    курсовая работа [3,4 M], добавлен 23.03.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.