Анализ информационной системы автосалона "Питер-Лада" и улучшение ее при помощи СУБД MySQL, PHP и HTML

Введение

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

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

Предметом исследования данного дипломного проекта является анализ существующей информационной системы автосалона «Питер-Лада», и улучшение ее при помощи СУБД MySQL, а так же языков PHP и HTML.

1.
Предпроектное исследование

1.1 Изучение деятельности компании

Компания “Питер-Лада” – официальный дилер АО АВТОВАЗ на Северо-западе Российской Федерации. Данная компания предоставляет услуги в сфере продажи автомобилей, сервисного обслуживания, кредитования, страхования, лизинга, а так же одна из первых дилерских сетей АВТОВАЗ, которая откликнулась на Государственный проект по утилизации автомобилей старше 10 лет, предоставляя весьма существенную скидку на приобретение нового авто. В автосалоне компании предоставлен полный модельный ряд автомобилей Лада во всевозможных комплектациях. Так же компания предоставляет своим клиентам богатый выбор дополнительного оборудования и различных аксессуаров, начиная с банальных “плечиков” для одежды и заканчивая современными мультимедийными системами, при помощи которых можно осуществлять доступ в интернет.

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

Автосалон в настоящее время очень динамично развивается, соответственно возрастает необходимость более точного отслеживания стадий, на которых находится автомобиль. А благодаря новой Государственной программе по утилизации старых автомобилей от 10 марта 2010 года, поток клиентов компании должен увеличиться в несколько раз. В связи с такими прогнозами, руководством компании было принято решение увеличить количество находящихся автомобилей на складе в 1.5 раза. В настоящее время на складе автомобилей учет частично автоматизирован, за счет использования MSExcel, однако данная автоматизация частична, и при прогнозируемом возрастании как числа клиентов компании, так и автомобилей на складе - уже не будет справляться с возложенными на нее задачами, в связи с тем, что на своевременное редактирование и обновление данных уходит значительное количество времени и трудовых ресурсов.

Целью данного дипломного проекта является построение автоматизированной информационной системы при помощи СУБД MySQL, РНР и HTML, посредством которой можно будет оперативно вносить, удалять и редактировать сведения об автомобилях, проходящих через отдел склада автосалона «Питер-Лада», а так же получать все необходимые сведения для нужд менеджмента компании.

Для достижения поставленной цели необходимо рассмотреть и решить ряд следующих задач:

1) Изучить теоретический аспект внедрения автоматизированной системы;

2) Проанализировать существующее программное обеспечение;

3) Формализовать деятельность автосалона «Питер-Лада», выделив необходимые к отслеживанию процессы;

4) Выбрать необходимую среду реализации ПО;

5) Разработать действующее ПО, решающее задачи автоматизации учета автомобилей автосалона;

6) Проанализировать экономическую эффективность внедрения данного программного продукта;

7) А так же проанализировать безопасность труда на рабочем месте.

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

1.2
Описание деятельности фирмы

Более 30 лет компания “Питер-Лада” представляет АО “АВТОВАЗ” на северо-западе России. Качество, надежность и выработанный за многие годы успешной работы профессионализм позволили компании войти в число лидеров автомобильного рынка Северо-Запада. С 2003 года “Питер-Лада” становится так же официальным дилером ЗАО “Джи Эм-АВТОВАЗ”, а с 2008 года ОАО “Питер-Лада” входит в крупнейший в России дилерский холдинг “Лада-Сервис”.

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

Структура управления сети автосалонов “Питер-Лада” выглядит следующим образом:

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

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

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

К основным должностным обязанностям руководителя отдела продаж относится:

- осуществлять управление деятельностью дилерского центра;

- решать организационные, кадровые проблемы;

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

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

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

В должностные обязанности руководителя СТО входит:

- Составление заявок на ремонт автомобилей;

- Распределение работ по механикам (учитывая квалификацию) после прихода заявки;

- Принятие решений по гарантийным случаям;

- Контроль полноты и своевременности выполняемых работ;

- Управление складом автозапчастей; следить за тем, чтобы все необходимые запчасти всегда были в наличии;

- Контроль дисциплины персонала на участке рем-зоны;

- Ведение документооборота, составление отчетности.

В задачи бухгалтерии автосалона входит:

- Взаимодействие с банками по документам, срокам оплаты кредитов;

- Взаимодействие с налоговыми органами;

- Решение организационных и оперативных вопросов;

- Составление бухгалтерской отчетности.

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

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

- проведение презентаций клиентам компании в шоу-руме;

- общение с клиентами компании, умение их заинтересовать;

- составление договоров купли-продажи;

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

- информирование клиентов о завершении работ с их автомобилем;

- ведение телефонных переговоров с возможными клиентами автосалона;

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

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

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

- прием поступающих на склад товарных автомобилей;

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

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

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

- подготовка документов по возмещению ущерба от поступления некомплектных или поврежденных автомобилей;

- поддержание товарных автомобилей в надлежащем техническом и эстетическом состоянии;

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

В подчинении у руководителя станции технического обслуживания находятся администратор СТО и механики.

В задачи администратора СТО входит:

- прием заявок от клиентов на техническое обслуживание автомобилей или их ремонт;

- открытие (закрытие) заказ-нарядов на заявленные работы;

- консультирование клиентов по телефону;

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

- составление отчетности.

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

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

- для каждого покупателя определить общую сумму покупки;

- получение денег от покупателей, проверка подлинности полученных купюр;

- сдача выручки в конце рабочего дня в бухгалтерию.

Описанная структура персонала дилерского центра “Питер-Лада” является линейной. Всего в автосалоне задействовано порядка 50 человек, средний возраст которых составляет 30 лет. Отбором кандидатов на должности в дилерском центре занимается отдел кадров, тесно сотрудничая с высшим руководством автосалона, а именно генеральным директором. В первую очередь обращается внимание на предыдущий опыт работы кандидата. Главным же критерием отбора является опыт работы кандидата в подобной должности.

1.3 Оценка функций учета в дилерском центре “Питер-Лада”

Основная деятельность дилерского центра “Питер-Лада” заключается в продаже и сервисном обслуживании автомобилей марки Lada.

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

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

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

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

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

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

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

1.4 Подходы к проектированию ИС

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

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

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

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

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

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

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

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

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

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

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

1.5 Унифицированный язык моделирования UML

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

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

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

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

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

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

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

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

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезным для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

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

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

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

· Поощрять развитие рынка объектных инструментальных средств.

· Способность совершенствоваться.

· Интегрировать в себя новейшие и наилучшие достижения практики

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

· Диаграмма вариантов или прецедентов использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

· Диаграмма состояний (statechart diagram)

· Диаграмма деятельности (activity diagram)

· Диаграммы взаимодействия (interaction diagrams)

· Диаграмма последовательности (sequence diagram)

· Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

· Диаграмма компонентов (component diagram)

· Диаграмма развертывания (deployment diagram)

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

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

1.6 Построение модели в Rational Rose

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария. [6]

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

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

· сокращение время разработки;

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

· улучшение потребительских качеств создаваемых программ;

· способность вести большие проекты или группу проектов;

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

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

1.6.1 Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

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

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

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы в таблице 1.1. [7]

Таб.1.1. Условные обозначения диаграммы вариантов использования

Условное обозначение	Описание условного обозначения
	Actor-актер системы, т.е. любое действующее лицо, которое представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей. В системе актерами являются «директор», «Менеджер по продажам», «руководитель отдела продаж» и «клиент».
	Use case -стандартное обозначение варианта (прецедента) использования, описывающий типичное взаимодействие между пользователем и системой
	связь, называемая коммуникацией (communication). Устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования
	связь включения (include) между двумя вариантами использования, которая указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательности поведения другого варианта использования
	связь расширение (extend)отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования

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

Рис. 1.2. Диаграмма прецедентов

1.6.2 Диаграммы состояний

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

Таб 1.2. Условные обозначения диаграммы состояний

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

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

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entryaction) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

1.6.3 Диаграмма деятельности

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Таб. 1.3. Условные обозначения диаграммы деятельности

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

Диаграммы деятельностей предпочтительнее использовать в следующих ситуациях:

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

· анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения. [6]

1.6.4 Диаграммы взаимодействия

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

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

сообщения – запросы (interrogative) – сообщения, запрашивающие выдачу информации об объекте-получателе;

императивные (imperative) – сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

1. последовательности (sequence diagrams);

2. кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

Рис. 1.5. Диаграмма последовательности «заказ дополнительного оборудования»

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

Рис. 1.6. Диаграмма кооперации «заказ дополнительного оборудования»

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

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

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

1.7 Вывод по главе 1

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

2. Проектирование автоматизированной информационной системы

2.1 Требования, предъявляемые к информационной системе

Целю данной дипломной работы является построение автоматизированной информационно системы для упрощения условий труда сотрудников автосалона «Питер-Лада». Проектируемая база данных является удобным средством решения перечисленных в предыдущей главе проблем и задач. Работа с данной базой данных не требует никакой специальной подготовки пользователей, благодаря удобному дружественному интерфейсу, а так же благодаря тому, что при авторизации пользователя (будь то менеджер, или руководитель СТО), последнему для работы предоставляется только та область базы данных, требуемая для выполнения служебных обязанностей. Например при работе с базой данных руководителя СТО, ему не требуется информация об автомобилях находящихся в наличии на складе автосалона, в то время как менеджмент компании не интересуют данные о автомобилях поступающих в рем-зону. Таким образом, при авторизации в данной базе данных, пользователю предоставляется минимально необходимый для работы набор данных, что позволяет избежать лишней путаницы и максимально упрощает пользовательский интерфейс.

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

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

Таким образом, требование минимальной избыточности следует понимать как устранение "вредной"" (неконтролируемой) и сведение к минимуму "полезной" (контролируемой) избыточности данных;

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

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

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

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

- Производительность. Характеризуется временем ответа на запросы пользователей.

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

2.2 Проектирование базы данных в Rational Rose
Data
Modeler

При создании программных систем процесс создания структуры данных (модели) является одним из важнейших этапов. Однако до недавнего времени аналитики-проектировщики, работающие с RationalRose, должны были обращаться к другим CASE-средствам для автоматизации этого процесса, например, к ERwin компании PLATINUM. С появлением подключаемого модуля (Add-In) под названием DataModeler у разработчиков появилась возможность не отказываться от своего любимого инструмента и использовать RationalRose не только для создания логического представления системы, но и для моделирования физического представления данных.

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей, приведенное в таблице 2.1.:

Таб. 2.1. Соответствие логической и физической модели

Стоит заметить, что для специфических элементов физической модели - триггеров и индексов - не нашлось достойного аналога UML, но в общем-то это не проблема.

Таким образом, концептуально модуль DataModeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД. Результатом работы DataModeler будет являться построение диаграммы «сущность – связь» и последующая генерация описания базы данных на SQL. [6]

Подводя итог, к основным особенностям Data Modeler стоит отнести:

o Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

o Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

o Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

o Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей;

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

2.3 Проектирование логической модели базы данных

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

Работа DataModeler основана на известном механизме отображения объектной модели в реляционную. Результатом являются построение диаграммы «сущность – связь» и последующая генерация описания базы данных на SQL.

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

Далее более подробно рассмотрим сущности таблиц диаграммы классов.

Рис. 2.2. Таблица «СТО».

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

Рис. 2.3. Таблица «клиенты».

В таблице «клиенты» содержатся данные о клиентах компании, без разделения на клиентов СТО и клиентов отдела продаж автомобилей Lada.

В этой таблице хранятся данные о ФИО клиента, его контактном телефоне, адрес места проживания, серия и номер паспорта, а так же номер водительского удостоверения.

Рис. 2.4. Таблица «Новые автомобили».

В данной таблице отображаются сведения о новых автомобилях приобретаемых компанией «Питер-Лада». Таблица содержит данные о модели автомобиля, его цвете, VIN – номере, комплектации и статус, в котором находится автомобиль. Если в статусе стоит Spb, значит автомобиль находится в наличии, и стоит на складе автосалона. Так же в статусе могут стоять следующие данные:

Таб. 2.2 Статусы новых автомобилей

Значение находящееся в таблице:	Расшифровка
20	Сборка автомобиля запланирована на конкретную дату следующего месяца (время ожидания примерно 1.5 месяца)
32	Автомобиль поступил на сборку (ожидание от одной недели до месяца)
40	Автомобиль собран и ждет очереди на покраску.* (ожидание от одной недели до месяца)
48	Автомобиль полностью собран и находится на складе в Тольятти
60	Автомобиль находится в пути от Тольятти до Санкт-Петербурга (срок ожидания 3-4 дня)

*Покраска автомобилей в определенный цвет производится строго по графику, например в цвет 606 - «Млечный путь» 11-12 числа каждого месяца, а цвет 105 – «Франкония» только 1-го числа.

Рис. 2.5. Таблица «Заказы».

Таблица «Заказы» определяет заказ клиента на конкретный автомобиль. В таблице отображаются данные о номере заказа, модели выбранного автомобиля, дате сборки , дате оформления договора с клиентом, ФИО менеджера составившего договор, данные об оставленной клиентом предоплате. Отдельное внимание стоит уделить графе «автомобиль в зачет». Если клиент сдает свой старый автомобиль по программе утилизации, то в графе ставится значение «Да», и клиенту предоставляется скидка в 50 000 рублей, в противном случае ставится значение «Нет» и скидка не предоставляется.

Рис.2.6. Таблица «Утилизация».

В этой таблице содержатся данные об утилизируемых автомобилях, такие как марка автомобиля, год выпуска (под программу утилизации попадают все автомобили произведенные до 2000 года), VIN –номер, а так же данные о владельце данного автомобиля.

Рис. 2.7. Таблица «Пользователи».

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

Рис. 2.8. Таблица «Дополнительное оборудование».

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

Рис. 2.9. Таблица «Диски».

Содержит информацию о радиусе и фирме-производителе оригинальных дисков.

Рис. 2.10. Таблица «Мультимедиа»

Данная таблица отображает сведения о фирме мультимедийной системы, сведения о ее размерах (1-2 din), а так же информацию о ее основных функциях.

Для создания физической модели базы данных, из меню на пакете Моя модель выполняем команду ÞDataModeler/TransformtoDataModel.

В открывшемся окне в списке TargetDatabase указать DB_0 и закрыть окно кнопкой ОК. В результате в логическом представлении в пакете Schemas появится пакет «Schema» S_0, в которую войдут все таблицы имеющие стереотип Сущность (entity). После чего из меню на пакете «Schema» S_0 выполняем команду ÞDataModeler/New/DataModelDiagram. В пакете «Schema» S_0 появится новая диаграмма NewDiagram (диаграмма «сущность – связь»). Затем открываем эту диаграмму и наносим на нее все классы – таблицы, находящиеся в пакете «Schema» S_0.

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

После того, как мы создали физическую модель базы данных, приступим к генерации описания базы данных на SQL. Для этого из меню на пакете «Schema» S_0 выполняем команду ÞDataModeler/ForwardEngineer. Произойдет запуск генератора описания БД на SQL, после чего нажимаем клавишу Next. На следующем шаге мастера устанавливаем все флажки генерации и опять жмем Next. В следующем меню в графе «FileName» указываем имя и расположение текстового файла с результатами генерации. После чего доводим до конца работу с мастером.

После завершения генерации получаем следующий файл с описанием структуры БД на SQL:

CREATE TABLE DO (

name_option VARCHAR ( 255 ) NOT NULL,

cena INT NOT NULL,

DO_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_DO13 PRIMARY KEY NONCLUSTERED (DO_ID)

)

CREATE TABLE Diski (

id_Disk INT NOT NULL,

radius INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

Diski_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Diski12 PRIMARY KEY NONCLUSTERED (Diski_ID)

)

CREATE TABLE Multimedia_system (

id_system INT NOT NULL,

firma VARCHAR ( 255 ) NOT NULL,

din BIT NOT NULL,

function VARCHAR ( 255 ) NOT NULL,

Multimedia_system_ID INT IDENTITY NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_Multimedia_system14 PRIMARY KEY NONCLUSTERED (Multimedia_system_ID)

)

CREATE TABLE Users (

id_users BIGINT NOT NULL,

FIO VARCHAR ( 255 ) NOT NULL,

Dostup INT NOT NULL,

Users_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_Users15 PRIMARY KEY NONCLUSTERED (Users_ID)

)

CREATE TABLE Т_3 (

Zakazi_ID INT NOT NULL,

Clients_ID INT NOT NULL,

CONSTRAINT PK_220 PRIMARY KEY NONCLUSTERED (Zakazi_ID, Clients_ID)

)

CREATE TABLE Т_2 (

Zakazi_ID INT NOT NULL,

DO_ID INT NOT NULL,

CONSTRAINT PK_119 PRIMARY KEY NONCLUSTERED (Zakazi_ID, DO_ID)

)

CREATE TABLE Т_1 (

CTO_ID INT NOT NULL,

Clients_ID INT NOT NULL,

CONSTRAINT PK_018 PRIMARY KEY NONCLUSTERED (CTO_ID, Clients_ID)

)

CREATE TABLE Zakazi (

id_zakaz INT NOT NULL,

number INT NOT NULL,

model_avto VARCHAR ( 255 ) NOT NULL,

data_sborki DATETIME NOT NULL,

data_oforml_zakaz DATETIME NOT NULL,

FIO_manager VARCHAR ( 255 ) NOT NULL,

predoplata INT NOT NULL,

auto_v_zachet BIT NOT NULL,

Zakazi_ID INT IDENTITY NOT NULL,

New_auto_ID INT NOT NULL,

Users_ID INT NOT NULL,

CONSTRAINT TC_Zakazi4 UNIQUE NONCLUSTERED (New_auto_ID),

CONSTRAINT PK_Zakazi17 PRIMARY KEY NONCLUSTERED (Zakazi_ID)

)

CREATE TABLE Utilization (

Id_Utiliz BIGINT NOT NULL,

Marka VARCHAR ( 255 ) NOT NULL,

God_v INT NOT NULL,

VIN INT NOT NULL,

Vladelec VARCHAR ( 255 ) NOT NULL,

Utilization_ID INT IDENTITY NOT NULL,

Zakazi_ID INT NOT NULL,

CONSTRAINT PK_Utilization16 PRIMARY KEY NONCLUSTERED (Utilization_ID)

)

CREATE TABLE Clients (

id_client BIGINT NOT NULL,

FIO VARCHAR ( 255 ) NOT NULL,

Tel VARCHAR ( 255 ) NOT NULL,

Adr VARCHAR ( 255 ) NOT NULL,

N_pasport VARCHAR ( 255 ) NOT NULL,

N_VU VARCHAR ( 255 ) NOT NULL,

Clients_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_Clients11 PRIMARY KEY NONCLUSTERED (Clients_ID)

)

CREATE TABLE CTO (

id_CTO INT NOT NULL,

nuber_zakaz-naryada SMALLINT NOT NULL,

zayavlennie_neispravnosti VARCHAR ( 255 ) NOT NULL,

data_nachala_remonta DATETIME NOT NULL,

viyavlennie_neispravnosti VARCHAR ( 255 ) NOT NULL,

gotovnost DATETIME NOT NULL,

cena INT NOT NULL,

CTO_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_CTO9 PRIMARY KEY NONCLUSTERED (CTO_ID)

)

CREATE TABLE New_auto (

id_New_auto INT NOT NULL,

Model VARCHAR ( 255 ) NOT NULL,

Color INT NOT NULL,

VIN INT NOT NULL,

Complectation VARCHAR ( 255 ) NOT NULL,

status VARCHAR ( 255 ) NOT NULL,

New_auto_ID INT IDENTITY NOT NULL,

CONSTRAINT PK_New_auto10 PRIMARY KEY NONCLUSTERED (New_auto_ID)

)

CREATE INDEX TC_Diski6 ON Diski (DO_ID)

CREATE INDEX TC_Multimedia_system8 ON Multimedia_system (DO_ID)

CREATE INDEX TC_215 ON Т_3 (Zakazi_ID)

CREATE INDEX TC_216 ON Т_3 (Clients_ID)

CREATE INDEX TC_111 ON Т_2 (Zakazi_ID)

CREATE INDEX TC_112 ON Т_2 (DO_ID)

CREATE INDEX TC_00 ON Т_1 (CTO_ID)

CREATE INDEX TC_01 ON Т_1 (Clients_ID)

CREATE INDEX TC_Zakazi3 ON Zakazi (New_auto_ID)

CREATE INDEX TC_Zakazi10 ON Zakazi (Users_ID)

CREATE INDEX TC_Utilization14 ON Utilization (Zakazi_ID)

ALTER TABLE Diski ADD CONSTRAINT FK_Diski3 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

ALTER TABLE Multimedia_system ADD CONSTRAINT FK_Multimedia_system4 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

ALTER TABLE Т_3 ADD CONSTRAINT FK_29 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

ALTER TABLE Т_3 ADD CONSTRAINT FK_210 FOREIGN KEY (Clients_ID) REFERENCES Clients (Clients_ID)

ALTER TABLE Т_2 ADD CONSTRAINT FK_16 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

ALTER TABLE Т_2 ADD CONSTRAINT FK_17 FOREIGN KEY (DO_ID) REFERENCES DO (DO_ID)

ALTER TABLE Т_1 ADD CONSTRAINT FK_00 FOREIGN KEY (CTO_ID) REFERENCES CTO (CTO_ID)

ALTER TABLE Т_1 ADD CONSTRAINT FK_01 FOREIGN KEY (Clients_ID) REFERENCES Clients (Clients_ID)

ALTER TABLE Zakazi ADD CONSTRAINT FK_Zakazi2 FOREIGN KEY (New_auto_ID) REFERENCES New_auto (New_auto_ID)

ALTER TABLE Zakazi ADD CONSTRAINT FK_Zakazi5 FOREIGN KEY (Users_ID) REFERENCES Users (Users_ID)

ALTER TABLE Utilization ADD CONSTRAINT FK_Utilization8 FOREIGN KEY (Zakazi_ID) REFERENCES Zakazi (Zakazi_ID)

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

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

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

автосалон база учет моделирование

Рис. 2.13. Структура Клиент-сервер

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

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

Общеизвестно, что возможности настольных СУБД серьезно ограничены - это пять-семь пользователей и 30-50 Мб, соответственно. Цифры, разумеется, представляют собой некие средние значения, в конкретных случаях они могут отклоняться как в ту, так и в другую сторону. Что наиболее существенно, эти барьеры нельзя преодолеть за счет наращивания возможностей аппаратуры. Системы же на основе серверов баз данных могут поддерживать тысячи пользователей и сотни ГБ информации - дайте им только соответствующую аппаратную платформу.

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

Для создания базы данных было решено использовать MySQL 5.0благодаря её функциональности и простоте в использовании. MySQL - это популярная система управления базами данных (СУБД), очень часто применяемая в сочетании с PHP. MySQL - это система управления реляционными базами данных. В реляционной базе данных данные хранятся не все скопом, а в отдельных таблицах, благодаря чему достигается выигрыш в скорости и гибкости. Таблицы связываются между собой при помощи отношений, благодаря чему обеспечивается возможность объединять при выполнении запроса данные из нескольких таблиц. SQL как часть системы MySQL можно охарактеризовать как язык структурированных запросов плюс наиболее распространенный стандартный язык, используемый для доступа к базам данных.

MySQL - это ПО с открытым кодом. Применять его и модифицировать может любой желающий. Такое ПО можно получать по Internet и использовать бесплатно. При этом каждый пользователь может изучить исходный код и изменить его в соответствии со своими потребностями. Использование программного обеспечения MySQL регламентируется лицензией GPL (GNU General Public License), http://www.gnu.org/licenses/, в которой указано, что можно и чего нельзя делать с этим программным обеспечением в различных ситуациях.

MySQL состоит из двух частей: серверной и клиентской. Сервер MySQL постоянно работает на компьютере. Клиентские программы (например, скрипты PHP) посылают серверу MySQL SQL-запросы через механизм сокетов (то есть при помощи сетевых средств), сервер их обрабатывает и запоминает результат. То есть скрипт (клиент) указывает, какую информацио он хочет получить от сервера баз данных. Затем сервер баз данных посылает ответ (результат) клиенту (скрипту). Почему всегда передается не весь результат? Очень просто: дело в том, что размер результирующего набора данных может быть слишком большим, и на его передачу по сети уйдет чересчур много времени. Да и редко когда бывает нужно получать сразу весь вывод запроса (то есть все записи, удовлетворяющие выражению запроса). Например, нам может потребоваться лишь подсчитать, сколько записей удовлетворяет тому или иному условию, или же выбрать из данных только первые 10 записей. Механизм использования сокетов подразумевает технологию клиент-сервер, а это означает, что в системе должна быть запущена специальная программа — MySQL-сервер, которая принимает и обрабатывает запросы от программ. [10]

Для создания графического интерфейса было принято решение использовать PHP и HTML. PHP - это язык программирования, специально разработанный для написания web-приложений (сценариев), исполняющихся на Web-сервере. PHP и HTML тесно связаны: PHP генерирует HTML, а HTML содержит информацию, которая высылается в PHP. Значительным отличием PHP от какого-либо кода, выполняющегося на стороне клиента, например, JavaScript, является то, что PHP-скрипты выполняются на стороне сервера. Возможности PHP очень большие. Главным образом, область применения PHP сфокусирована на написание скриптов, работающих на стороне сервера; таким образом, PHP способен выполнять всё то, что выполняет любая другая программа CGI. Например, обрабатывать данных форм, генерировать динамические страницы, отсылать и принимать cookies. Но PHP способен выполнять и множество других задач. PHP — язык, который может быть встроен непосредственно в html -код страниц, которые, в свою очередь будут корректно обрабатываться PHP -интерпретатором. Очень важное преимущество PHP заключается в его «движке». «Движок» PHP не является ни компилятором, ни интерпретатором. Он является транслирующим интерпретатором. Такое устройство «движка» PHP позволяет обрабатывать сценарии с достаточно высокой скоростью.

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

- Средства безопасности системного уровня

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

- Средства безопасности уровня приложения

В стандартный набор функций РНР входит ряд надежных механизмов шифрования. РНР также совместим с многими приложениями независимых фирм, что позволяет легко интегрировать его с защищенными технологиями электронной коммерции (e-commerce). Другое преимущество заключается в том, что исходный текст сценариев РНР нельзя просмотреть в браузере, поскольку сценарий компилируется до его отправки по запросу пользователя. Реализация РНР на стороне сервера предотвращает похищение нетривиальных сценариев пользователями, знаний которых хватает хотя бы для выполнения команды ViewSource. Поскольку РНР является встраиваемым (embedded) языком, он отличается исключительной гибкостью по отношению к потребностям разработчика. Хотя РНР обычно рекомендуется использовать в сочетании с HTML, он с таким же успехом интегрируется и в JavaScript, WML, XML и другие языки. Поскольку РНР не содержит кода, ориентированного на конкретный web-сервер, пользователи не ограничиваются определенными серверами (возможно, незнакомыми для них). Apache, Microsoft IIS, Netscape Enterprise Server, Stronghold и Zeus — РНР работает на всех перечисленных серверах. Поскольку эти серверы работают на разных платформах, РНР в целом является платформенно-независимым языком и существует на таких платформах, как UNIX, Solaris, FreeBSD и Windows 95/98/NT/2000/XP/2003. [8,9]

2.5 Реализация ИС автосалона «Питер-Лада»

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

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

Settings.cfg

$dbname = 'BD_Autosalon';

$hostname ='Localhost';

$usernameman = 'MefedAN';

$passwordman = '12345';

$usernamemech = 'Ruk_CTO';

$passwordmech = '123123';

$usernameboss = Direktor;

$passwordboss = 222111;

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

Index.html

<html>

<head> <title>Официальный диллер ОАО "АВТОВАЗ" </head>

<body>

<table>

<tr>

<td>

<font face="Segoe Print">Вы собираетесь войти в систему.<br> Пожалуйста авторизуйтесь.

</td>

<td>

</td>

</tr>

<tr>

<p >Пользователь: <input type="text" name="Login"></p>

<p>Пароль : <input type="password" name="Pass">

</font>

</tr>

</table>

</html>

auth.php

if (($_POST["Login"]=='Manager')&($_POST["Pass"]=='12345'))

{

Header("Location: manager_menu.html");

}

elseif (($_POST["Login"]=='Ruk_CTO')&($_POST["Pass"]=='123123'))

{

Header("Location: zakaz-nariad.php");

}

else

{

echo 'Неврный логин и/или пароль';

}

<body>

<br>

<a href="index.html">Назад.</a>

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

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

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

usert1.php

<html>

<head> <title>Отчёт продаж за день</head>

<body>

include ("settings.cfg");

$db = mysql_connect ($hostname,$usernameboss,$passwordboss); <---- mysql_select_db($dbname,$db);

$dt=date('Y-m-d');

$result = mysql_query("SELECT model_avto,data_sborki,FIO_manager FROM Zakazi WHERE data_oforml_zakaz=$dt",$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

echo ("<table border ='1'>");

echo ("<tr><td>Модельавтомобиля</td><td>Датасборки</td><td>ФИОменеджера</td></tr>");

while ($tablerows = mysql_fetch_row($result))

{

echo("<tr><td>$tablerows[0]</td><td>$tablerows[1]</td><td>$tablerows[2]</td></tr> ");

}

$result = mysql_query("SELECT sum(predoplata) FROM Zakazi WHERE data_oforml_zakaz=$dt&qu

ot;,$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

echo "<tr><td collspan=2>Итого,руб:</td><td>$tablerows[0]</td></tr></table>";

echo "<a href=BossMenu.html> Назад </a>";

</body>

</html>

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

Для окончательного оформления заказа следует нажать кнопку «Составить заказ».

Если в главном меню менеджера выбрать «Меню утилизации», будет загружена следующая страница:

Менеджер должен ввести необходимые данные об утилизируемом автомобиле в соответствующие поля. При вводе года автомобиля старше 2000, появится сообщение об ошибке. Так же сообщение об ошибке «Автомобиль уже подвергнут утилизации!» возникнет в том случае, если по каким-то причинам данные об утилизируемом автомобиле уже содержатся в таблице Utiliz.

Данная страница реализована следующим образом:

Utilz.html

<html>

<head> <title>Официальный диллер ОАО "АВТОВАЗ" </head>

<body>

<table>

<tr>

<td>

</td>

<td>

Введите следующие данные, необходимые для утилизации:

<p> Марка: <input type="text" name="Marka"></p>

<p> Годвыпуска: <input type="text" name="God_v"></p>

<p> Собственник (ФИО): <input type="text" name="Vladelec"></p>

<a href="manager_menu.html"> Назад. </a>

</td>

</table>

</html>

AddUtil.php

include ("settings.cfg");

$db = mysql_connect ($hostname,$usernameman,$passwordman);

mysql_select_db($dbname,$db);

$result = mysql_query("SELECT VIN FROM Utiliz",$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

while ($tablerows = mysql_fetch_row($result))

{

if ($tablerows[0]==$_POST["VIN"])

{

echo 'Такая машина уже подвергнута утилизации!';

echo '<a href = Utiliz.html> Назад </a>';

exit();

}

$query = "INSERT INTO Utiliz VALUES ('$_POST[Marka]','$_POST[God_v]','$_POST[VIN]','$_POST[Vladelec]');";

$result = mysql_query($query,$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

echo 'Машина принята на утилизацию!';

echo '<a href = Utiliz.html> Назад </a>';

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

Эта страница реализована следующим образом:

zakaz-nariad.php

<html>

<head> <title>Официальный диллер ОАО "АВТОВАЗ" </head>

<body>

<table>

<tr>

<td>

Необходимо ввести следующие данные:

<p> Номерзаказ-наряда: <input type="text" name="number_zakaz_naryda" value="<!number_zakaz_naryda >"></p>

include ("settings.cfg");

$db = mysql_connect ($hostname,$usernamemech,$passwordmech);

mysql_select_db($dbname,$db);

$result = mysql_query("SELECT Max(Number)+1 FROM CTO",$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

$tmp = str_replace ("<!number_zakaz_naryda >",$result);

}

<p> Заявленныенеисправности: <input type="text" name="zayavlennie_neispravnosti"></p>

<p> Датаначаларемонта: <input type="text" name="data_nachala_remonya"></p>

<p> Выявленныенеисправности: <input type="text" name="viyavlennie_neispravnosti"></p>

<p> Датаивремяготовности: <input type="text" name="gotovnost"></p>

<p> Итоговая стоимость работ: <inputtype="text" name="cena"></p>

<inputtype="submit" value="Подтвердить данные">

<a href="Index.html"> Назад. </a>

</td>

<td>

</td>

</table>

</html>

AddZakaz.php

include ("settings.cfg");

$db = mysql_connect ($hostname,$usernamevech,$passwordmech);

mysql_select_db($dbname,$db);

$query = "INSERT INTO СТО VALUES ('$_POST[number_zakaz_naryda]','$_POST[zayavlennie_neispravnosti]','$_POST[data_nachala_remonya]','$_POST[viyavlennie_neispravnosti]','$_POST[gotovnost]','$_POST[cena]');";

$result = mysql_query($query,$db);

if(!$result)

{

echo "Возниклаошибка - ".mysql_error()."<br>";

echo $sql;

exit();

}

echo 'Заказ-наряд составлен!';

echo '<a href = Zakaz-nariad.php> Назад </a>';

В результате проектирования средствами языка UML в среде RationalRose описана логическая модель информационной системы, построена логическая и физическая схема базы данных. На языках HTML и PHP разработан простой и удобный пользовательский Web-интерфейс, позволяющий подключаться к удаленной СУБД MySQL, управляющей базой данных системы. Так же средствами языка PHP происходит обработка всей необходимой информации и управление данными, передаваемыми в базе данных.

3.
Расчёт эффективности инвестиций на разработку и отладку программного продукта

3.1 Цели, задачи и методы оценки инвестиций

Итогом данного дипломного проекта является разработка информационной системы для автоматизации учета автомобилей в дилерском центре «Питер-Лада». Основная цель данного программного продукта – облегчение труда работников предприятия.

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

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

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

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

· возможное получение реальной отдачи (дохода) от вложения инвестиций по истечении ряда лет вложения;

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

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

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

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

Дисконтирование по сложной ставке процента связано с определением дисконтного множителя Vtза каждый год из n-лет вложения по следующей формуле:

(1)

где i - ставка сложных процентов

t = 1,2, ..., n.

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

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

Итоговая величина искомого показателя ЧПВД может быть определена по следующей формуле:

(2)

где n1, - продолжительность осуществления инвестиций;

п2 - продолжительность периода отдачи;

Кl - ежегодные инвестиции в периоде l, l =1,2,..., п1;

pj - ежегодные инвестиции в периоде j, j = 1, 2, ... , п2.

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

(3)

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

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

3.2 Выбор и описание разрабатываемого и альтернативного вариантов

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

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

· разработка;

· производство;

· эксплуатация.

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

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

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

- эксплуатация.

В качестве основного варианта будет рассмотрен проект написания программного продукта при помощи СУБД MySQL и интерфейса на языке программирования PHP.

В качестве альтернативного варианта рассмотрим проект написания данного программного продукта с помощью технологии ASP.NET и языка программирования C#, а также база данных, реализованной на SQLServer 2005.

Исходные данные для расчётов приведены в таблице 3.1.

Таблица 3.1

Назначение показателей	Условные обозначения	Значения по вариантам
Назначение показателей	Условные обозначения	Основной	Альтернативный
Общая продолжительность этапа разработки и отладки, мес.	T	4	2
Общая численность исполнителей в период разработки, чел.	U	1	2
Среднемесячная заработная плата всех исполнителей, р./мес.	З	15000	35000
Общая продолжительность этапа эксплуатации, лет	Тэ	2	2

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

Выбираем в качестве ставки сложных процентов усреднённую существующую величину 10 процентов, хотя эта величина ниже усреднённого уровня.

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

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

· общая продолжительность разработки 4 месяца;

· общая продолжительность эксплуатации 2 года.

В итоге, общий период составляет 2 года 4 месяца

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

Учитывая это и используя данные из справочных источников, находим дисконтный множитель. Дисконтный множитель при i = 10% по годам вложений представлен в таблице №2

Таблица 3.2

Год вложения	1	2
Дискретный множитель	0.9091	0.8264

3.3 Расчёт вложений на этапе разработки и отладки основного варианта

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

Календарный график выполнения работ представлен в таблице 3.3

Таблица 3.3

Наименование этапа	Сроки начала	Сроки окончания
1. Определение требований к системе	01.02.10	04.02.10
2. Определение структуры системы	05.02.10	12.02.10
3. Написание программного комплекса	13.02.10	20.04.10
4. Отладка	20.04.10	30.04.10
5. Подготовка документации	1.05.10	20.05.10

Расчёт основной и дополнительной заработной платы на этапе разработки приведен в таблице 3.4

Таблица 3.4

Категория персонала

Кол-во чел

Основная зарплата,

тыс. руб.

Доп. Зарплата (14% от ОснЗп)

тыс. руб.

Время занятий мес.

Сумма, тыс. руб.

Инженер программист

2,1

68,4

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

Таблица 3.5.

Формулы для расчёта	Условные обозначения
С = Зо+ Зд + Зсс + Зм + Зээ + За + Зпр	Зо - основная з/п персонала, руб./час Зд - доп. з/п персонала, руб./час Зсс - отчисления на гос. страх., руб./час Зм - затраты на материалы, руб./час Зээ - затраты на потр. энергию, руб./час За - амортизация выч. средств, руб./час Зпр - прочие производ. расходы, руб./час
Зо = Зосн /(m * 8)	Зосн - основная з/п программиста, руб./час (см. таб. 4) m - ср. кол-во рабочих дней в месяце m=21
Зд =(Нд /100)* Зо	Нд - процент доп. з/п персонала (14%)
Зсс =(Нсс / 100) * (Зо + Зд)	Нсс - процент отчисления на соц.обеспечение (26%)
Зээ =å qj * Nj * S	qj - число j-х технических средств ЭВМ Nj - потр. мощность j-х технических средств, кВт S- стоимость кВт/ч электроэнергии (1,85 руб.)
За=а* Sэвм /(1008m*12)	a - годовая норма амортизации ЭВМ (20%) Sэвм - балансовая стоимость ЭВМ (30000 руб.)
Зпр =(Нпр / 100) * (Зо + Зээ + За)	Нпр - процент прочих произв. расходов (50%)

Основная заработная плата:

Зо =15000 / (21* 8) = 89,3 руб./час;

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

Зд = (14 / 100) * 89,3 = 12,5 руб./ час;

Отчисления на соцобеспечение:

Зсс = (26 / 100) * (89,3 + 12,5) = 26,5 руб./ час;

Затраты на электроэнергию:

Зээ = 1 * 0,3 * 1,85 = 0,55 руб./час;

Амортизация:

За = 20 * 30000 / (100 * 8 * 21 * 12) = 3 руб./час;

Прочие производственные расходы:

Зпр = 50 / 100 * (89,3 + 0,55 + 3) = 46,7 руб./час;

К прочим производственным расходам можно отнести затраты на материалы, лицензионное программное обеспечение и т.д.

Зс - отчисления на социальное страхование.

Зс = 0.26* (Зо + Зд)=0,26(89,3+12,5) = 26,5 руб.

Таким образом, себестоимость машино-часа работы ЭВМ составит:

С = 89,3 + 12,5 + 26,5 + 0,55 + 3 + 46,7 = 178,5 руб./час;

Однако, при расчёте себестоимости машино-часа учитывались затраты лишь на ЭВМ, занятой для решения данного вопроса. Кроме этого, необходимо ещё учитывать затраты на ремонт оборудования. Затраты на ремонт составляют 10% от стоимости оборудования, т.е.:

Зр = 10 * Sэвм / (8 * m * 12 * 100);

Зр = 10 * 30000 / (8 * 21 * 12 * 100) = 1,5 руб./час;

Таким образом, себестоимость машино-часа работы

С = 178,5 + 1,5 = 180 руб./час;

Зная себестоимость машино-часа работы ЭВМ, можно определить затраты на написание программного комплекса и его отладку по формуле:

Знп-о = С * t ,

где t = 672 - время написания программного комплекса и его отладки и использование вычислительной машины для подготовки технической документации, час (84 рабочих дня).

Получим:

Знп-о = 180 * 672 = 120 960 руб.;

В целом показатели на этапе разработки характеризуются величиной стоимости работы и дисконтным множителем. Величина дисконтного множителя равна 1 (т.к. t = 4 мес. не дисконтируется).

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

3.4 Расчёт вложений на этапе разработки и отладки альтернативного варианта

Исходная информация по календарному графику выполнения работ и расчёт отдельных статей калькуляции сведены в таблице 3.6.

Таблица 3.6.

Наименование этапа	Сроки начала	Сроки окончания
1. Определение требований к системе	01.02.10	04.02.10
2. Определение структуры системы	05.02.10	07.02.10
3. Написание программного комплекса	8.02.10	10.03.10
4. Отладка	10.03.10	20.03.10
5. Подготовка документации	21.03.10	30.03.10

Расчёт основной и дополнительной заработной платы на этапе разработки альтернативного варианта приведен в таблице 3.7

Таблица 3.7.

Категория персонала	Кол-во человек	Основная зарплата тыс. руб.	Доп. Зарплата (14% от ОснЗп) тыс. руб.	Время занятий, мес.	Сумма, тыс. руб.
Разработчик	1	20	2,8	2	45,6
Инженер-программист	1	15	2,1	2	34,2

Для учёта затрат на этапе написания программного комплекса и его отладки определим себестоимость машино-часа работы ЭВМ. Основная заработная плата:

Зо = 35000 / (21* 8) = 208 руб./час;

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

Зд = (14 / 100) * 208 = 29,1 руб./час;

Отчисления на соцобеспечение:

Зсс = (26 / 100) * (208 + 29,1) = 61,6 руб./час;

Затраты на электроэнергию:

Зээ = 2 * 0,3 * 1,85 = 1,1 руб./час;

Амортизация:

За = 20 * 30000 * 2 / (100 * 8 * 21 * 12) = 6 руб./час;

Прочие производственные расходы:

Зпр = 50 / 100 * (208 + 1,1 + 6) = 107,5 руб./час;

Зс - отчисления на социальное страхование.

Зс = 0.26* (Зо + Зд)=0,26(208+29,1) = 61,6 руб.

Таким образом, себестоимость машино-часа работы ЭВМ составит:

С = 208 + 29,1 + 61,6 + 1,1 + 6 + 107,5 = 413,3 руб./час;

Однако, при расчёте себестоимости машино-часа учитывались затраты лишь на ЭВМ, занятой для решения данного вопроса. А нам необходимо ещё учитывать затраты на ремонт оборудования. Затраты на ремонт составляют 10% от стоимости оборудования, т.е.:

Зр = 10 * Sэвм * 2 / (8 * m * 12 * 100);

Зр = 10 * 30000 * 2 / (8 * 21 * 12 * 100) = 3 руб./час;

Таким образом, себестоимость машино-часа работы:

С = 413,3 + 3 = 416,3 руб./час;

Знп-о = С * t ,

где t = 360 - время написания и отладки программного комплекса и использования вычислительной техники для подготовки технической документации, час (45 рабочих дней).

Знп-о = 416,3 * 360 = 149 868 руб.

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

3.5 Расчёт вложений по годам этапа эксплуатации

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

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

· Отчисления на социальные отчисления;

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

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

· Затраты на электроэнергию, потребляемую оборудованием и расходуемую на освещение;

· Расходные материалы (носители информации) и прочие расходы.

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

Общие эксплуатационные издержки потребителя составят:

И = (Зп + Зд + Зс + Зр + За + Зээ) * t ,

где t -время эксплуатации (4032 часов);

Зп - совокупная основная заработная плата пользователей, руб./час;

Для эксплуатации комплекса потребуется администратор. Поэтому при расчете необходимо учитывать заработную плату администратора - 30000 р.

Тогда,

Зп = 30000 / 21 / 8 = 178,6 руб./час;

Зд - совокупная дополнительная заработная плата пользователей, руб./час. (14% от основной зарплаты).

Зд = Зп*0,14 = 178,6*0,14 = 25 руб./час;

Зс - отчисления на социальное страхование.

Зс = 0,26*(Зп + Зд) = 53 руб./час;

Зр - затраты на ремонт (10% от стоимости оборудования).

Зр = 0,1* 1*30000/ 8 / 21/ 12 = 1,49 руб./час;

За – затраты на амортизацию(20% от стоимости оборудования).

Зр = 0,2* 1*30000/ 8 / 21/ 12 = 2,98 руб./час;

Зээ - затраты на электроэнергию.

Зээ = 1,85 * 0.3 * 1 = 0,55 руб./час;

Тогда при основном варианте и альтернативном варианте:

И = (178,6 + 25 + 53 + 1,49 + 2,98 + 0,55 ) * 4032 = 1 054,8 тыс. руб.

3.6
Итоговые показатели технико-экономической эффективности

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

· за первый год эксплуатации (0.9091) * 1 054,8 тыс. руб. / 2 = 479,5 тыс. руб.;

· за второй год эксплуатации (0.8264) * 1 054,8 тыс. руб. / 2 = 435,8 тыс. руб.

Показатель итоговой величины затрат:

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

120,9 тыс. руб. + 915,3 тыс. руб. = 1 036,2 тыс. руб.;

для альтернативного варианта:

149,8 тыс. руб. + 915,3 тыс. руб. = 1 065,1 тыс. руб.

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

Таблица 3.8

Наименование показателей	Значения показателей по вариантам
Наименование показателей	Основной	Альтернативный
Технико-эксплуатационные
Рекомендуемый объём ОЗУ, Гб	1	1
Рекомендуемый тип процессора	PentiumIV 2,8 GHz и выше	PentiumIV 2.8 GHz и выше
Язык программирования	PHP	С#
Экономические показатели
Период разработки и отладки, мес.	4	2
Количество исполнителей	1	2
Период эксплуатации, мес.	24	24
Современная величина затрат на разработку и отладку ПП, тыс. руб.	120,9	149,8
Современная величина затрат на эксплуатацию ПП, тыс. руб.	915,3	915,3
Показатель итоговой величины современных затрат, тыс. руб.	1 036,2	1 065,1

Сравнение итоговых показателей современных затрат по двум возможным вариантам вложения инвестиций показывает, что предпочтительным для финансирования является основной вариант проекта, для осуществления которого при прочих равных условиях требуется меньшая современная сумма затрат. Показатель итоговой величины современных затрат на этапе разработки для этого варианта составляет 120,9 тыс. руб. Это значение меньше показателя итоговой величины современных затрат второго (альтернативного) варианта. Также, следует отметить, что основной вариант является наиболее эффективным в работе, проще в реализации и на его разработку затрачивается гораздо меньше времени с средств. [4]

4. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ

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

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

Таблица 4. 1. Характеристики помещения

Параметр	Значение
Д лина	7 м
ширина	5 м
Высота	2,5 м
площадь	35 м²
Объем	87,5 м³
количество работников	5 чел.
объем для каждого работника	17,5 м³

4.1 Микроклимат

Согласно ГОСТ 12.1.005-88 “ССБТ. Общие санитарно-гигиенические требования к воздуху рабочей зоны”, нормирование параметров микроклимата в рабочей зоне производится в зависимости от периода года, категории работ по энергозатратам, наличия в помещении источников явного тепла.

Данная работа производится сидя и сопровождается незначительным физическим напряжением. Такая работа относится к категории 1а (легкая физическая). Энергозатраты организма составляют до 120ккал/ч (до 500,5 кДж/ч).

Рабочее место - постоянное.

В приведенной ниже таблице № 4.2 приведены оптимальные нормы температуры, относительной влажности и скорости движения воздуха в рассматриваемом рабочем помещении в соответствии с СанПиН 2.2.2/2.4.1340-03.

Таблица 4.2. Оптимальные нормы микроклимата для помещений с ВДТ (Видео Дисплейных Терминалов) и ПЭВМ

Период года	Температура, °С, не более	Относительная влажность, %	Скорость движения воздуха, м/с
Холодный	22-24	40-60	0,1
Теплый	23-25	40-60	0,1

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

4.2 Вредные вещества и пыль

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

4.3 Уровень ионизации воздуха

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

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

Уровни аэроионов	Число ионов в 1 см3 воздуха
Уровни аэроионов	n+	n-
Минимально необходимые	400	600
Оптимальные	1500-3000	3000-5000
Максимально допустимые	50000	50000

4.4 Наличие шума и вибрации

Согласно СанПиН 2.2.2/2.4.1340-03 при выполнении основной работы на ВДТ и ЭВМ уровень шума на рабочем месте не должен превышать 50 дБА. Шум на уровне 50-60 дБА создает значительную нагрузку на нервную систему человека, оказывая на него психологическое воздействие. Это особенно часто наблюдается у людей, занятых умственной деятельностью. Степень вредности и неприятное воздействие какого-либо шума зависит также от того, насколько он отличается от привычного шума и от индивидуального отношения к нему.

В соответствии с СанПиН 2.2.2/2.4.1340-03 для уровня звука 50дБА уровни звукового давления в октавных полосах частот представлены в таблице №3 .

Таблица 4.4 Уровни звукового давления в октавных полосах частот

Рабочее место

Уровни звукового давления, дБ, в октавных полосах со среднегеометрическими частотами, Гц

Ур-ни звука, дБА

31,5

125

250

500

1000

2000

4000

8000

Производственное помещение

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

Шумящее оборудование (АЦПУ, принтеры и т.п.), уровни шума которого превышают нормированные, должно находиться вне помещения с ВДТ и ПЭВМ.

Снизить уровень шума в помещениях с ВДТ и ПЭВМ можно использованием звукопоглощающих материалов с максимальными коэффициентами звукопоглощения в области частот 63 - 8000 Гц для отделки помещений (разрешенных органами и учреждениями Госсанэпиднадзора России), подтвержденных специальными акустическими расчетами. Для достижения максимально возможного звукопоглощения необходимо облицевать не менее 60% общей площади внутренних поверхностей помещения. Дополнительным звукопоглощением служат однотонные занавеси из плотной ткани, подвешенные в складку на расстоянии 15-20 см от ограждения. Ширина занавеси должна быть в 2 раза больше ширины окна.

В производственных помещениях, в которых работа с ВДТ и ПЭВМ является основной, вибрация на рабочих местах не должна превышать допустимых норм вибрации (таблице 4.5) .

Таблица 4.5. Допустимые нормы вибрации на всех рабочих местах с ВДТ и ПЭВМ

Среднегеометрические частоты октавных полос, Гц	Допустимые значения
	по виброускорению		по виброскорости
	мс-2	дБ	мс-1	дБ
	оси X, Y
2	5,3*10	25	4,5*10	79
4	5,3*10	25	2,2*10	73
8	5,3*10	25	1,1*10	67
16	1,0*10	31	1,1*10	67
31,5	2,1*10	37	1,1*10	67
63	4,2*10	43	1,1*10	67
Корректированные значения и их уровни в дБ W	9,3*10	30	2,0*10	72

4.5 Излучения

Сотрудники, работающие с ПК, подвержены воздействию электромагнитных полей.

ПК при работе излучают электромагнитную энергию радиочастот, значит, работники подвержены воздействию электромагнитных полей с ВЧ и УВЧ излучением. Интенсивность ЭМП ВЧ и УВЧ согласно ГОСТ 12.1.006. – 88 «ССБТ Электромагнитные поля радиочастот» на рабочих местах оценивается напряженностью E (В/м) для электрической составляющей и напряженностью Н (А/м) для магнитной составляющей. В целях обеспечения требований, а также защиты от электромагнитных и электростатических полей, допускается применение при экранных фильтров, специальных экранов и других средств индивидуальной защиты, прошедших испытания в аккредитованных лабораториях и имеющих гигиенический сертификат.

Степень воздействия ЭМИ на организм человека зависит от:

· частоты колебаний;

· значения напряженности электрических и магнитных полей;

· размеров облучаемой поверхности тела.

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

Таблица 4.6. Допустимые значения параметров неионизирующих электромагнитных излучений

Наименование параметров	Допустимое значение
Напряженность электромагнитного поля на расстоянии 50 см вокруг ВДТ по электрической составляющей должна быть не более: - в диапазоне частот 5 Гц – 2 кГц; - в диапазоне частот 2 – 400 кГц	25 В/м 2,5 В/м
Плотность магнитного потока должна быть не более: - в диапазоне частот 5 Гц – 2 кГц; - в диапазоне частот 2 – 400 кГц.	250 нТл 25 нТл
Поверхностный электростатический потенциал не должен превышать	500 В

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

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

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

В случае превышения допустимых значений параметров ЭМИ, следует воспользоваться некоторыми способами защиты от ЭМИ:

· Уменьшение мощности источника - уменьшение параметров излучения в самом источнике;

· Экранирование источника излучения (рабочего места);

· Выделение зоны излучения;

· Удаление рабочего места от источника излучения;

· Защита временем (от тока промышленной частоты).

При выборе средств защиты следует отдавать предпочтение экранированию источника излучения (согласно СанПиН 2.2.2/2.4.1340-03).

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

Конструкция ВДТ и ПЭВМ должна обеспечивать мощность экспозиционной дозы рентгеновского излучения в любой точке на расстоянии 0,05 м от экрана и корпуса ВДТ при любых положениях регулировочных устройств не должна превышать 7,74х10 А/кг, что соответствует эквивалентной дозе, равной 1,0 мкЗв/час.

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

4.6 Нормы на освещение рабочего места

Помещения с ПК должны иметь естественное и искусственное освещение.

Естественное освещение должно осуществляться через светопроемы, ориентированные преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (КЕО) не ниже 1,2 % в зонах с устойчивым снежным покровом и не ниже 1,5 % на остальной территории. Для внутренней отделки интерьера помещений с ЭВМ должны использоваться диффузно-отражающие материалы с коэффициентом отражения для потолка ρП - 0,7 – 0,8; для стен ρС - 0,5 – 0,6; для рабочей поверхности ρР - 0,3 – 0,5. и

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

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

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

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

Следует ограничивать отраженную блескость на рабочих поверхностях (экран, стол, клавиатура и др.) за счет правильного выбора типов светильников и расположения рабочих мест по отношению к источникам естественного и искусственного освещения, при этом яркость бликов на экране ПК не должна превышать 40 кд/м² и яркость потолка, при применении системы отраженного освещения, не должна превышать 200 кд/м².

Следует ограничивать неравномерность распределения яркости в поле зрения пользователя ПК, при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1 – 5:1, а между рабочими поверхностями и поверхностями стен и оборудования 10:1.

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

Для освещения помещений с ПК следует применять светильники серии ЛПО36 с зеркальными решетками, укомплектованные высокочастотными пускорегулирующими аппаратами (ВЧ ПРА). Допускается применять светильники серии ЛПО36 без ВЧ ПРА только в модификации «Кососвет», а также светильники прямого света П, преимущественно прямого света – Н, преимущественно отраженного света В. применение светильников без рассеивателей и экранирующих решеток не допускается.

Яркость светильников общего освещения в зоне углов излучения от 50 до 90 градусов с вертикалью в продольной и поперечной плоскостях должна составлять не более 200 кдж/м², защитный угол светильников должен быть не менее 40 градусов.

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

Коэффициент запаса (Кз) для осветительных установок общего освещения должен приниматься равным 1,4.

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

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

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

4.7 Вентиляция

Чтобы нормализовать воздушную среду, в производственном помещении должен осуществляться воздухообмен (вентиляция).

По способу перемещения воздуха вентиляция разделяется на:

1. естественную - осуществляется за счет разности температур воздуха помещения и наружного воздуха или действия ветра;

2. механическую - спроектированную систему для подачи воздуха.

В помещении, объемом 87,5м3, 5 рабочих места. Следовательно, на каждого работающего приходиться 17,5м3 объема воздуха.

Согласно санитарным нормам проектирования промышленных предприятий СН-245-71 в производственных помещениях с объемом на одного работающего:

· менее 20м3 осуществляется подача наружного воздуха в количестве не менее 30м3/ч на каждого работающего;

· более 20м3 – не менее 20м3/ч;

· более 40м3 и при наличии окон достаточно естественной вентиляции.

Объем воздуха на каждого рабочего в этом помещении составляет 17,5м3, следовательно, согласно санитарным нормам проектирования промышленных предприятий, на одного работающего необходима подача воздуха в количестве не менее 30 м3/ч. Следовательно, общий объем приточного воздуха в помещение должен составлять не менее 150 м3/ч.

4.8 Расчет осветительной установки

Работа с ПК относится к работе IV-а разряда (средней точности, наименьший размер объекта различия от 0,5 до 1мм). В данном помещении – высота потолков 2,5м. Целесообразно применять люминесцентные лампы, так как существуют повышенные требования к цветопередаче и качеству освещения.

При выборе нормативного значения освещенности необходимо учитывать, что в производственных помещениях используются системы освещения двух типов:

1. общего (светильники, установленные на потолке помещения, равномерно освещают всю рабочую зону);

2. комбинированного (к общему освещению добавляется местное).

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

В соответствии с нормами освещенности рабочих поверхностей в производственных помещениях (по СНиП 23-05-95), требуемая освещенность для системы одного общего освещения при использовании люминесцентных ламп для проведения работ IV-а разряда составляет 300 лк.

Рассматриваемое помещение относится к помещениям с нормальными условиями среды, для освещения можно использовать светильник типа ЛСП02 (прямого света, исполнение пыле- и водо- незащищенное, тип кривой силы света (КСС) - Д).

Определение высоты подвеса светильника над рабочей поверхностью происходит по формуле:

h = Н – hc – hp,

где:

Н – высота помещения, м;

hc – расстояние от потолка до светильника, м;

hp – высота рабочей поверхности, равная 0,8 м.

h = 2,5 – 0,168– 0,8 = 1,532 (м)

Индекс помещения вычисляется по формуле:

где:

L – длина помещения, м;

В – ширина помещения, м;

h – расчетная высота подвеса светильника, м.

С учетом зависимости коэффициента использования светового потока от индекса помещения и характеристики помещения, определяем коэффициент использования светового потока. Он получен для указанных значений типа кривой силы света (Д – косинусная группа) и коэффициентов отражения потолка, стен и пола, равных, соответственно, 0,7; 0,5; 0,1 (помещение относится к чистым). В данном случае индекс помещения равен 0,652, следовательно, hи = 0,64.

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

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

где:

Ен – нормированная освещенность рабочей поверхности, лк;

S – площадь помещения, м2;

Kз – коэффициент запаса;

Z – коэффициент неравномерности освещения;

n – количество ламп в одном светильнике;

hи – коэффициент использования светового потока в долях единицы;

Ф – световой поток одной лампы, лм.

Коэффициент запаса Kз учитывает возможность уменьшения освещенности в процессе эксплуатации осветительной установки и принимается в данном случае равным 1,4. Коэффициент неравномерности Z для люминесцентных ламп равен 1,1. Световой поток Ф для ЛБ ламп равен 5220 лм и находится из таблиц ГОСТ 6825-74, в зависимости от типа и мощности используемых в светильнике ламп.

Число светильников в осветительной установке:

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

∆L ≤ 0,5*h

В данном случае ∆L должно быть не более 1,02м.

Длина светильника L = 1,534м, ширина светильника d = 0,276м.

Примечание. Из конструктивных соображений допускается изменять количество светильников в осветительной установке. При этом фактическое число светильников не должно отличаться от расчетного N не менее –10% и более +20%.

Предлагаемая схема организации освещения в помещении приведена на рисунке:

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

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

· рабочие места с ВДТ и ПЭВМ по отношению к световым проемам должны располагаться так, чтобы естественный свет падал сбоку, преимущественно слева,

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

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

4.9 Режим труда

Общие требования к организации режима труда и отдыха при работе с ВДТ и ПЭВМ по СанПиН 2.2.2/2.4.1340-03:

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

2. Виды трудовой деятельности разделяются на 3 группы:

· группа А - работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом;

· группа Б - работа по вводу информации;

· группа В - творческая работа в режиме диалога с ЭВМ.

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

3. Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ВДТ и ПЭВМ, которые определяются:

· для группы А - по суммарному числу считываемых знаков за рабочую смену, но не более 60 000 знаков за смену;

· для группы Б - по суммарному числу считываемых или вводимых знаков за рабочую смену, но не более 40 000 знаков за смену;

· для группы В - по суммарному времени непосредственной работы с ВДТ и ПЭВМ за рабочую смену, но не более 6 часов за смену.

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

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

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

7. Продолжительность непрерывной работы с ВДТ без регламентированного перерыва не должна превышать 2 часов.

8. При работе с ВДТ и ПЭВМ в ночную смену (с 22 до 6 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов должна увеличиваться на 60 минут.

9. При 8-ми часовой рабочей смене и работе на ВДТ и ПЭВМ регламентированные перерывы следует устанавливать:

· для I категории работ через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый;

· для II категории работ через 2 часа от начала рабочей смены и через 1.5-2.0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

· для III категории работ через 1.5-2.0 часа от начала рабочей смены и через 1.5-2 часа после обеденного перерыва продолжительностью 20 минут каждый или продолжительностью 15 минут через каждый час работы.

10. При 12-ти часовой рабочей смене регламентированные перерывы должны устанавливаться в первые 8 часов работы, аналогично перерывам при 8-ми часовой рабочей смене, а в течение последних 4 часов работы, независимо от категории и вида работ, каждый час продолжительностью 15 минут.

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

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

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

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

4.10 Электрическая безопасность

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

Применяемая электросеть является однофазной, с напряжением 220 В, ток переменный с частотой 50 Гц, с заземленной нейтралью.

Напряжения прикосновения и токи, протекающие через человека, нормируются согласно ГОСТ 12.1.038-88 «ССБТ. Электробезопасность. Предельно допустимые значения напряжений и токов».

В таблице №7 приведены допустимые значения напряжений прикосновения и токов при аварийном режиме работы техники, где резистором моделируется сопротивление тела человека
R = 850(Ом). Найдем силу тока в аварийном режиме:

Таблица 4.7. Допустимые значения напряжений прикосновения и токов при аварийном режиме работы

Род и

частота тока

Норм.

велич.

Продолжительность воздействия, t, с

0,01-0,08

0,1

0,2

0,4

0,5

0,8

Переменный

50 Гц

Uпр, В

Iч,мА

550

650

340

400

160

190

120

140

105125

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

4.11 Оценка необходимости применения защитных устройств

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

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

Зануление – преднамеренное электрическое соединение металлических нетоковедущих частей электрооборудования с заземленной точкой источника питания электроэнергией при помощи нулевого защитного проводника.

Следует иметь в виду, что в соответствии с «Правилами устройства электроустановок потребителей (ПУЭ)» защитное заземление или зануление электроустановок следует выполнять при напряжении питания 380 В и выше переменного тока и 440 В и выше постоянного тока во всех случаях. При напряжении питания выше 42, но ниже 380 В переменного тока, и выше 110, но ниже 440 В постоянного тока, защитное заземление (зануление) электроустановок выполняется только в помещения с повышенной опасностью и особо опасных по поражению электрическим током, а также в наружных электроустановках.

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

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

Таблица 4.8

Климатические условия	Сопротивление изоляции, МОм, при рабочем напряжении цепи кВ
Нормальные	0,1-0,5
Нормальные	20,0

Сопротивление изоляции силовой и осветительной сети напряжением до 1000В на участке между двумя смежными предохранителями или любым проводом и землей должно быть не менее 0.5 МОм.

4.12 Пожарная безопасность

Основы противопожарной защиты предприятий определены стандартами ГОСТ 12.1.004-91 «Пожарная безопасность» и ГОСТ 12.1.010-76 «Взрывобезопасность. Общие требования».

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

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

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

Автоматические извещатели делятся на: тепловые (срабатывают при превышении максимально допустимой температуры в помещении), дымовые (реагируют на скопление дыма) и световые (срабатывают при появлении открытого пламени).

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

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

Высота установки

извещателя, м

Максимальная

площадь, контролируемая одним извещателем, м2

Макси
мальное расстояние, м

между извещателями

от извещателя до стены

Тепловые пожарные извещатели

До 3,5

Более 3,5 до 6

4,5

2,5

Дымовые пожарные извещатели

До 3,5

Более 3,5 до 6

8.5

4.5

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

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

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

Наименование помещений, сооружений и установок	Защищаемая площадь, м²	Углекислотные огнетушители	Пенные, химические, воздушно-пенные и жидкостные огнетушители, шт.	Ящик с песком вместимостью 0,5; 1,0;3,0 и лопата, шт.	Войлок, кошма или асбест: /1х1,2х1,2х2 м/ , шт.	Бочка с водой вместимостью не менее 0,2 м и ведро, шт.
Вычислительные центры, машиносчетные станции, архивы, библиотеки, проектно- конструкторские бюро.	35	2	2	-	2	-

Для защиты помещения при пожаре объемом менее 200м2 с компьютерной техникой необходимо иметь: углекислотные огнетушители ОУ-2, ОУ-5, ОУ-8 (допускается заменять аэрозольными или порошковыми) – 1шт., пенные огнетушители – 1шт., войлок 2х2 м – 1шт. [2] При оценке условий труда, были рассмотрены безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ:

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

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

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

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

· указаны возможные причины и источники возникновения пожара, установлен перечень первичных средств пожаротушения, а также были разработаны инженерно-технические мероприятия по созданию благоприятных условий труда, используя СанПиН 2.2.2/2.4.1340-03.

Заключение

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

С использованием языков HTML и PHP, СУБД MySQL, разработано программное решение для построения информационной системы автоматизации рабочего места сотрудника автосалона, с доступом через Web интерфейс (браузер). Данный продукт предназначен не только для сотрудников, имеющих дело с клиентами, покупающими новые автомобили, но так же и для работников станции технического обслуживания компании. Данное программное решение позволяет менеджменту компании с любого рабочего места оперировать информацией о работе отделов, следить за автомобилями в наличии, а так же составлять заказы.

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

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

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

Список используемой литературы

1. Трофимов С.А. Case – технологии. Практическая работа в RationalRose. Бином 2001, 272с.

2. Казаченко, Колобашкина Т.В. и др. Безопасность жизнедеятельности. Промышленная и экологическая безопасность. Методические указания к дипломному проектированию, СПб-ГУАП, 2001

3. Определение эффективности инвестиций. Методические указания к выполнению дипломного проекта. Спб, 2002

4. Прогнозирование элементов бизнес-плана проектов. Методические указания к выполнению дипломных проектов. СПб 2002.

5. Роберт Дж. Мюлер. Базы данныз и UML. Справочник в электронном виде, 2001

6. Унди Боггс, Майкл Боггс. UML и RationalRose. Лори, 2004

7. Справочное руководство пользователя по пакету RationalRose.

8. Люк Веллинг, Лора Томсон. Разработка Web – приложений с помощью РНР и MySQL. Вильямс, 2005

9. Джон Когг Золл. РНР 5. Полное руководство. Диалектика, 2006

10. Викрам Васвани. Полный справочник по MySQL. Москва, 2006

11. Мазупкевич А. РНР. Настольная книга программиста. Новое издание,2003

Слов:	16384
Символов:	149148
Размер:	291.30 Кб.

Название реферата: Анализ информационной системы автосалона "Питер-Лада" и улучшение ее при помощи СУБД MySQL, PHP и HTML