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

Размещено на http://www.allbest.ru/

ЧАСТНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ «ШАЛИНСКИЙ КОЛЛЕДЖ»

КУРСОВАЯ РАБОТА

по дисциплине: МДК 02.01 Информационные технология и платформы разработки информационных систем

на тему: «Проектирование и разработка информационных систем для фирмы, торгующей автомобилями»

Специальность:

09.02.04 Информационные системы (по отраслям)

Уциева Банату Алихановна

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

Каимова Рамнат Исаевна



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1.1 Особенности разработки информационных систем
• 1.2 Технологии проектирования баз данных
• 1.3 Особенности применения технологической платформы 1С:Предприятие 8
• ГЛАВА 2. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 2.1 Проектирование базы данных
• 2.2 Разработка базы данных информационной системы в конфигураторе 1С:Предприятие 8.2
• 2.3 Разработка функциональности информационной системы
• 2.4 Тестирование информационной системы
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• 
• ВВЕДЕНИЕ
• Теоретическая и практическая важность автоматизации учетной деятельности торгового предприятия и повышения его эффективности обусловили актуальность темы курсовой работы. Объектом исследования являются информационные системы. Предметом исследования являются вопросы разработки информационной системы для торговой фирмы.
• В соответствии с целью были поставлены следующие задачи:
• Изучить особенности разработки информационных систем;
• Изучить технологии проектирования баз данных;
• Изучить особенности применения технологической платформы 1С: Предприятие 8; функциональность информационная система конфигуратор
• Выполнить проектирование базы данных;
• Разработать информационную систему в 1С: Предприятие 8.2;
• Выполнить ввод данных и контроль за правильным функционированием информационной системы.
• Система должна обеспечивать автоматический контроль правильности входной и выходной информации. Система должна обеспечивать надежную защиту данных и программы, должна быть возможность разграничения доступа к информации для различных категорий пользователей с помощью парольной аутентификации. В случае аварийного завершения работы программы предусмотрен режим восстановления и переиндексации БД в приемлемое время восстановления после отказа.
• Создаваемая программная система должна функционировать, легко инсталлироваться, настраиваться и корректно работать при выполнении следующих требований:
• наличие операционной системы типа MS Windows XP, MS Windows Vista, MS Windows 7, MS Windows 8, MS Windows 10.
• Структура курсовой работы состоит из введения, двух глав, заключения и списка использованных источников.
• ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1 Особенности разработки информационных систем

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Итерационная модель жизненного цикла ИС

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

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

1.2 Технологии проектирования баз данных

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

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

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

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

На четвертом этапе производится физическое проектирование, решение вопросов, связанных с производительностью СУБД, определяется структура хранения данных и методы доступа.

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

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

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

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

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

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

В соответствии с этим в трехуровневой архитектуре ANSI/SPARC определено выделение трех различных уровней описания данных (внешнего, концептуального, внутреннего) в модели системы управления базами данных.

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

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

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

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



Рисунок 3. Уровни представлений о данных в базе данных.

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

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

1.3 Особенности применения технологической платформы 1С:Предприятие 8

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

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

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

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

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

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

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

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

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

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

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

Процесс взаимодействия этих объектов выглядит следующим образом:

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

Таким образом, конфигуратор «1С:Предприятия 8» позволяет выполнять разработку и администрирование информационных баз, является удобным и эффективным средством разработки информационных систем.



ГЛАВА 2. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

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

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

На основе анализа предметной области продажи автомобилей выделим информационные объекты и их атрибуты. Выделяем объекты-сущности Покупатели, Сотрудники, Банки, Поставщики, Автомобили, Файлы, Цены, Розничные цены, Продажа автомобиля, Поступление авто, Оплата поставщику, Оплата от покупателя.

Рассмотрим атрибуты перечисленных объектов в таблице 1.

Таблица 1. Атрибуты объектов

Объект	Атрибуты объекта
Покупатели	Код покупателя Наименование ФИО Адрес Телефон E_mail
Сотрудники	Код сотрудника Наименование ФИО Телефон
Банки	Код банка Наименование БИК КоррСчет ИНН Адрес Телефон

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

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

Определим отношения (взаимосвязи) и мощности отношений между объектами.

Отношение «Покупатели» -> «Продажа автомобиля». «Покупатели» является главным объектом, а «Продажа автомобиля» подчинённым объектом. Определен тип связи «один ко многим» (Рисунок 4). Один Покупатель может участвовать в нескольких продажах автомобиля. Указанные объекты связываются между собой по атрибуту «Код покупателя».

Покупатели

Продажа автомобиля

1:M

Рисунок 4. Связь между объектами «Покупатели» и «Продажа автомобиля»

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

Таблица 2 - Отношения между таблицами

Номер связи	Родительская таблица	Дочерняя таблица
1	Покупатели	Продажа автомобиля
2	Сотрудники	Продажа автомобиля
3	Автомобили
4	Автомобили	Поступление авто	1:М
5	Поставщики	Поступление авто	1:М
6	Банки	Поставщики	1:М
7	Автомобили	Цены	1:М
8	Автомобили	Розничные цены	1:М
9	Автомобили	Оплата от покупателя	1:М
10	Покупатели	Оплата от покупателя	1:М
11	Поставщики	Оплата поставщику	1:М

Центральными сущностями базы данных являются таблицы «Автомобили», «Продажа автомобиля», связанные с наибольшим количеством таблиц отношением один-ко-многим. Спроектированная в MS Visio инфологическая модель базы данных по методологии проектирования IDEF1X изображена на рисунке 5.

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

«

Рисунок 5. Инфологическая модель базы данных

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

2.2 Разработка базы данных информационной системы в конфигураторе 1С:Предприятие 8.2

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

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

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

справочников: Покупатели, Сотрудники, Банки, Поставщики, Автомобили, Файлы;

регистров сведений: Цены, Розничные цены;

регистров накопления: Остатки авто, Продажи;

документов: Продажа автомобиля, Поступление авто, Оплата поставщику, Оплата от покупателя.

Разработанный справочник «Покупатели» содержит следующие реквизиты:

Код (тип данных Число, длина 9);

Наименование (тип данных Строка, длина 50);

ФИО (тип данных Строка, длина 50);

Адрес (тип данных Строка, длина 100);

Телефон (тип данных Строка, длина 20);

E_mail (тип данных Строка, длина 50).

«Покупатели». Аналогично были созданы структуры данных справочников «Сотрудники», «Банки», «Поставщики», «Автомобили», «Файлы».

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

Для группировки данных были созданы отдельные вкладки, в список элементов формы добавлена Группа-Страницы, а затем в нее две Группа-Страница и в эти группы перемещены необходимые элементы. Технические параметры автомобиля размещены в группу 3 с заголовком «Характеристики», а группа 2 с заголовком «Фото» создана для отображения фотографии автомобиля.

Для организации хранения фото в справочнике «Автомобили» был создан реквизит «Фото» с типом данных СправочникСсылка.Файлы. Вспомогательный справочник «Файлы» содержит реквизит «Файл» типа «ХранилищеЗначения».

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

Разработаны процедуры, выполняющиеся на клиенте и сервере, «&НаКлиенте Процедура ДобавитьФото(Команда)» и «&НаСервере Процедура ДобавитьФотоНаСервере( )» для сохранения фото с использованием хранилища данных и сформирована процедура «&НаСервере Процедура ПриСозданииНаСервере( )» для получения ссылки на фото и отображения его на странице формы (Приложение Б. Листинг 1) [1, 11].

В свойствах кнопки «КнопкаФото» выбрана имя команды Добавить Фото Для хранения закупочных и розничных цен автомобилей созданы регистры сведений «Цены» и «Розничные цены», для которых задана периодичность «В пределах секунды» и режим записи «Независимый».

2.3 Разработка функциональности информационной системы

Для регистрации данных по торговым операциям созданы регистры накопления (рисунки А.2 - А.4, Приложение А) и движения документов по этим регистрам.

Документ «ПоступлениеАвто» предназначен для регистрации поступления автомобилей в торговую фирму. Для автоматизации заполнения табличной части формы документа для столбца «Автомобиль» создана процедура-обработчик события «При изменении» - Процедура АвтоАвтомобильПриИзменении( ) /листинг 2, Приложение Б/, в результате выполнения которой для выбранного автомобиля выполняется отбор цены из регистра сведений «Цены» (функция РаботаСоСправочниками.ОптоваяЦена( , ), листинг 3, Приложение Б) и значение найденной цены присваивается полю «Цена».

Для автоматического расчета суммы при вводе значения количества создана процедура «АвтоКоличествоПриИзменении( )» (листинг 2, Приложение Б).

Для того чтобы выполнялся расчет итоговой суммы по поступающим автомобилям и она присваивалась реквизиту «СуммаИтог» перед записью документа создана процедура ПередЗаписью( ) (листинг 2, Приложение Б).

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

Для проведения документа по созданы движения по регистрам «ОстаткиАвто» (Приход) и «РасчетыСПоставщиками» (Расход) с помощью конструктора движений (рисунки А.5 и А.6, Приложение А).

Документ «ОплатаПоставщику» предназначен для регистрации оплаты и ликвидации задолженности перед поставщиком за поставленные автомобили. Документ можно сформировать на основании ранее созданного документа «ПоступлениеАвто», для этого с помощью конструктора ввода на основании создана соответствующая процедура (рисунок А.7, Приложение А).

С помощью конструктора движений созданы движения по регистру «РасчетыСПоставщиками» (Приход).

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

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

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

Для анализа торговых операций фирмы произведена разработка отчетов «Расчеты с поставщиками» на основе данных из регистра накопления «РасчетыСПоставщиками», «Остатки автомобилей» на основе данных из регистра накопления «Остатки авто», «Продажи автомобилей» на основе данных из регистра накопления «Продажи» с использованием системы компоновки данных и построения запросов (Листинг 4, Приложение Б).

2.4 Тестирование информационной системы

При открытии информационной системы «Продажа автомобилей» отображается основное окно, а при выборе подсистемы отображаются доступные команды (рисунок 12). Результат тестового ввода информации в справочник «Автомобили».

Результат проверки добавления фото в элемент справочника «Автомобили» отображены на рисунке 14, а результаты проверки заполнения других справочников отображены на рисунках А.9-А.12 в приложении А. Результаты проверки заполнения документа «Поступление автомобиля» отображены на рисунках 14 и 15.

Результаты проверки заполнения документа «Оплата поставщику» отображены на рисунке 16. Документ «Оплата поставщику» можно ввести на основании документа «Поступление автомобиля», при этом произойдет автоматическое заполнение полей «Поставщик» и Сумма».Результаты проверки заполнения регистров сведений «Розничные цены» и «Цены», а также документов «Продажа автомобиля» и «Оплата от покупателя» отображены на рисунках А.13-А.15, Приложения А.

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

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

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



ЗАКЛЮЧЕНИЕ

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

Решены следующие задачи:

Изучены особенности разработки информационных систем;

Изучены технологии проектирования баз данных;

Изучены особенности применения технологической платформы 1С: Предприятие 8;

Выполнено проектирование базы данных;

Разработана информационная система в 1С: Предприятие 8.2;

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

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

повысить эффективность обработки данных;

уменьшить количество ошибок;

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

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



СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Ажеронок В.А. , Габец А.П., Гончаров Д.И. Профессиональная разработка в системе "1С: Предприятие 8" в двух томах / под ред. Радченко М.Г., 2-е издание (+DVD), М.: 1С-Паблишинг, 2012. Т1. 690 с., Т2. 683 с..

2. Балдин, К.В. Информационные системы в экономике: Учебник / К.В. Балдин, В.Б. Уткин. - М.: Дашков и К, 2013. - 395 c.

3. Варфоломеева, А.О. Информационные системы предприятия: Учебное пособие / А.О. Варфоломеева, А.В. Коряковский, В.П. Романов. - М.: НИЦ ИНФРА-М, 2013. - 283 c.

4. Вдовин, В.М. Предметно-ориентированные экономические информационные системы: Учебное пособие / В.М. Вдовин. - М.: Дашков и К, 2013. - 388 c.

5. Граничин Олег, Кияев Владимир. Информационные технологии в управлении предприятием [Электронный ресурс] // Санкт-Петербургский государственный университет 2015. - URL: http://www.intuit.ru (дата обращения: 09.06.17)

6. Губина Е.А., Ирзаев Г.Х., Адеева М.Г. Проектирование информационной системы на основе связывания CASE-инструментария и реляционной базы данных // НАУКА И БИЗНЕС: ПУТИ РАЗВИТИЯ. Тамбов: Изд. Фонд развития науки и культуры, 2014. - С.75-79.

7. Гущин А. Н. Базы данных. Учебник / М.: Директ-Медиа, 2014.- 266 c.

8. Коцюба И.Ю., Чунаев А.В., Шиков А.Н. Основы проектирования информационных систем / Учебное пособие. - СПб.: Университет ИТМО, 2015. - 206 с.

9. Медведкова И. Е., Бугаев Ю. В., Чикунов С. В. Базы данных / Воронежский государственный университет инженерных технологий, 2014. - 105 с.

Размещено на Allbest.ru

...