разработка интернет магазина автозапчастей

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

ВВЕДЕНИЕ 4
ГЛАВА I. КОМПЛЕКСНОЕ ОПИСАНИЕ КОМПАНИИ ОАО «АЛЬФА» КАК ОБЪЕКТ ИССЛЕДОВАНИЯ 6
1.1 Общая характеристика ЗАО «Альфа» 6
1.2 Основные направления деятельности и обязанности сотрудников 10
1.3 Требования к рекламно-информационному сайту «Альфа» 15
1.4 Обзор программных продуктов компьютерного моделирования 20
Инструментальная среда BPwin 26
ГЛАВА II. РАЗРАБОТКА РЕКЛАМНО-ИНФОРМАЦИОННОГО САЙТА 30
2.1 Создание бизнес модели в стандарте IDEF0 30
2.2 Проектирование модели базы данных 34
2.3 Разработка базы данных 39
2.4 UML диаграммы 40
2.4.1 Диаграмма вариантов использования 40
2.4.2 Диаграмма последовательности 42
2.4.3 Диаграмма активности 42
2.5 ГРАФИЧЕСКИЙ ИНТЕРФЕЙС 43
ГЛАВА III. РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ 48
3.1 Расчет трудоемкости разработкипрограммного обеспечения 48
3.2 Определение себестоимости разработки программного обеспечения 49
3.3 Расчет готовых эксплатуационных расходов 50
3.4 Определение экономической эффективности 52
3.4.1. Расчет годовых расходов при неавтоматизированной работ персонала 52
3.4.2 Расчет годовых расходов при автоматизированной работе персонала 53
3.5 Поведение итоговой оценки программного продукта 55
ЗАКЛЮЧЕНИЕ 58
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ 60
ПРИЛОЖЕНИЯ 68

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

Обычно внесение изменений в проект на поздних этапах создании ИС - весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям. На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям. В настоящей книге рассматривается вполне конкретная технология разработки, основывающаяся на решениях фирмы PLATINUM technology (www.platinum.com), которая является одной из лучших на сегодняшний день по критерию стоимость/эффективность. Рассматриваемые CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния в 1998 году Logic Works с PLATINUM technology онивыпускаются под логотипом PLATINUM technology. Рис. 1.1. Общая схема взаимодействия инструментальных средств PLATINUM technology и Rational SoftwareДля проведения анализа и реорганизации бизнес-процессов PLATINUM technology предлагает CASE-средство верхнего уровня BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия компонентов системы.На основе модели BPwin можно построить модель данных. Для построения модели данных PLATINUM technology предлагает мощный и удобный инструмент - ERwin. Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, PLATINUM technology предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (стрелка 1 рис. 1). ERwin имеет два уровня представления модели - логический и физический. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это по существу отображение системного каталога, который зависит от конкретной реализации СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования БД (стрелка 2 рис. 1). Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования того либо другого. ERwin интегрируется с популярными средствами разработки клиентской части - PowerBuilder, Visual Basic, Delphi (стрелка 3 рис. 1), что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению (стрелка 4 рис. 1). Для разных сред разработки реализована различная техника кодогенерации. Код для PowerBuilder генерируется непосредственно в среде ERwin, код для Visual Basic - с помощью add-in компонентов и библиотек, подключаемых в проект Visual Basic. ERwin не поддерживает непосредственно кодогенерацию для Delphi. Код клиентского приложения для Delphi на основе модели данных ERwin можно сгенерировать с помощью MetaBASE - продукта фирмы gs-soft (www.gs-soft.com). Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов БД, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма PLATINUM technology предлагает систему Model Mart - хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5 рис. 1). Model Mart удовлетворяет всем требованиям, предъявляемым к средствам разработки крупных ИС, а именно:Совместное моделирование. Каждый участник проекта имеет инструмент поиска и доступа к интересующей его модели в любое время. При совместной работе используются три режима: незащищенный, защищенный и режим просмотра. В режиме просмотра запрещается любое изменение моделей. В защищенном режиме модель, с которой работает один пользователь, не может быть изменена другими пользователями. В незащищенном режиме пользователи могут работать с общими моделями в реальном масштабе времени. Возникающие при этом конфликты разрешаются при помощи специального модуля - Intelligent Conflict Resolution (ICR). В дополнение к стандартным средствам организации совместной работы Model Mart позволяет сохранять множество версий, снабжен-ных аннотациями, с последующим сравнением предыдущих и новых версий. При необходимости возможен возврат к предыдущим версиям.Создание библиотек решений. Model Mart позволяет формировать библиотеки стандартных решений, включающие наиболее удачные фрагменты реализованных проектов, накапливать и использовать типовые модели, объединяя их при необходимости «сборки» больших систем. На основе существующих БД с помощью ERwin возможно восстановление моделей (обратное проектирование), которые в процессе анализа пригодности их для новой системы могут объединяться с типовыми моделями из библиотек моделей.Управление доступом. Для каждого участника проекта определяются права доступа, в соответствии с которыми они получают возможность работать только с опреде-ленными моделями. Права доступа могут быть определены как для групп, так и для отдельных участников проекта. Роль специалистов, участвующих в различных проектах, может меняться, поэтому в Model Mart можно определять права доступа и управлять правами доступа участников проекта к библиотекам, моделям и даже к специфическим областям модели. Архитектура Model Mart. Model Mart реализована на архитектуре клиент-сервер. В качестве платформы реализации хранилища выбраны РСУБД Sybase, Microsoft SQL Server, Informix и Oracle. Клиентскими приложениями являются ERwin З.Х и BPwin 2.Х. В Model Mart реализован доступ к хранилищу моделей через API, что позволяет постоянно наращивать возможности интегрированной среды путем включения новых инструментов моделирования и анализа. Как было указано выше (см. п. С), при разработке крупных проектов критичным становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения (клиентской части) CASE-средствами на основе модели предметной области. Хотя BPwin решает эту задачу, код генерируется на основе модели IDEFIX, т.е. фактически на основе реляционной модели данных, которая непосредственно не содержит информации о бизнес-процессах. Как следствие этого сгенерированный код не может полностью обеспечить функциональность приложения со сложной бизнес-логикой. Объектно-ориентированное проектирование - альтернативная технология кодогенерации, которая лишена этого недостатка. Существует несколько CASE-средств, поддерживающих языки объектно-ориентированного проектирования, в том числе ставший в последнее время стандартом UML. Наиболее известными являются PLATINUM Paradigm Plus фирмы PLATINUM technology и выпущенный фирмой Rational Software (www.rational.com) программный пакет Rational Rose. Эти инструменты позволяют строить объектные модели в различных нотациях (ОМТ, UML и др.) и генерировать на основе полученной модели приложения на языках программирования C++, Visual Basic, Power Builder, Java, Ada, Smalltalk и др. Поскольку генерация кода реализована на основе знаний предметной области, а не на основе реляционной структуры данных, полученный код более полно отражает бизнес-логику. Rational Rose и Paradigm Plus поддерживают не только прямую генерацию кода, но и обратное проектирование, т. е. создание объектной модели по исходному коду приложения (стрелка 6 рис. 2). В гл. 5 а качестве примера рассматриваются основные принципы построения объектной модели при помощи Rational Rose. Rational Rose предназначен для генерации клиентской части приложения. Для генерации схемы БД объектную модель следует конвертировать в модель данных IDEFIX. Модуль ERwin Translation Wizard (PLATINUM technology) позволяет перегружать объектную модель Rational Rose в модель данных ERwin (и обратно) и, с помощью ERwin, сгенерировать схему БД (стрелка 7 рис. 1) на любой из поддерживаемых в ERwin СУБД. Для связывания объектной модели, созданной в PLATINUM Paradigm Plus, с моделью данных не требуется дополнительных утилит. Версия Paradigm Plus 3.6 полностью интегрирована с ERwin. Инструментальная среда BPwinBPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создавать сложные модели при минимальных усилиях.Ниже будет описан интерфейс версии 2.5. Рис. 1.2. Интегрированная среда разработки модели BPwin 2.5При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer (рис. 1.2). Функциональность панели инструментов доступна из основного меню BPwin (табл. 1.5). Таблица 1.5Описание элементов управления основной панели инструментов BPwin 2.5Элемент управленияОписаниеСоответствующий пункт меню123Создать новую модельFile/NewОткрыть модельFile/OpenСохранить модельFile/SaveОкончание таблицы 1.5123Напечатать модельFile/PrintВыбор масштабаView/ZoomМасштабированиеView/ZoomПроверка правописанияTools/SpellingВключение и выключение навигатора модели Model ExplorerView/Model ExplorerВключение и выключение дополнительной панели инструментов работы с ModelMartModelMartПри создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория ModelMart, внести имя модели и выбрать методологию, В которой будет построена модель (рис. 1.5). Как было указано выше, BPwin поддерживает три методологии - IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. с. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.Рис. 1.3. Диалог создания моделиМодель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. ГЛАВА II. РАЗРАБОТКА РЕКЛАМНО-ИНФОРМАЦИОННОГО САЙТА2.1 Создание бизнес модели в стандарте IDEF0Моделирование начинается с построения контекстной диаграммы. (Рисунок 2.1). [4]Рис. 2.1. Контекстная диаграмма процесса «организация перевозки сотрудников»В контекстной диаграмме процесса «Доставка товара» входными данными являются: заказ. Результатом бизнес-процесса являются подпись путевки.Далее строится диаграмма декомпозиций первого уровня. (Рисунок 2.2).Рис. 2.2 Диаграмма декомпозиций первого уровня процесса «Доставка товара»Процесс «Доставка товара» состоит из следующих работ:прием заказа;составление заявки на автомобиль;назначение автомобиля и выезд;прибытие.Входными данными процесса являются заказ. Выходными данными является подпись путевки. Далее будут представлены диаграммы декомпозиций второго уровня на рисунке 2.3.Рис. 2.3. Диаграмма декомпозиций второго уровня для процесса прием заказаНа данной диаграмме входными данными являются: заказ. Выходными данными являются: заказ. Все работы контролируются руководителем.Выполняются работы:получение целей поездки;согласование с руководителем подразделения.Диаграмма декомпозиций второго уровня для процесса составление заявки на автомобиль изображена на рисунке 2.4.Рис. 2.4. Диаграмма декомпозиций второго уровня для процесса составление заявки на автомобильНа данной диаграмме входными данными являются: заказ. Выходными данными являются: разрешение на выезд. Все работы контролируются руководителем.Процесс состоит из следующих работ:заполнение бланка;подпись начальника отдела;регистрация заявки.На рисунке 9 представлена диаграмма декомпозиций второго уровня для процесса назначение автомобиля и выезд.Рис. 2.5. Диаграмма декомпозиций второго уровня для процесса назначение автомобиля и выездНа данной диаграмме входными данными являются: разрешение на выезд. Выходными данными являются: выезд. Все работы контролируются руководителем.Выполняются такие работы:выбор автомобиля.расчет маршрута.согласование путевки.выдача пропуска.На рисунке 2.6 представлена диаграмма декомпозиций второго уровня для процесса назначение автомобиля и выезд.Рис. 2.6. Диаграмма декомпозиций второго уровня для процесса назначение автомобиля и выездНа данной диаграмме входными данными являются: выезд. Выходными данными являются: подпись путевки. Все работы контролируются руководителем.Выполняются следующие работы:регистрация в журнале прибытия.проверка корректности путевки.2.2 Проектирование модели базы данныхДля работы программного комплекса необходима операционная система Windows XP, Windows Vista, Windows 7.Операционная система должна быть русской, русифицированной.Аппаратные средства.Минимальные требования программы к аппаратным средствампроцессор Pentium 4 и выше, частота рекомендуется не менее 2 ГГц.для работы с небольшими объемами данных необходимо 512 Mb.видеокарта требуется любая современная, не менее чем с 32 Mb видеопамяти, поддерживающая 65 тыс. и более цветов.монитор минимум 17”, разрешением минимум 1024 x 768.Процессор: за количеством MHz можно не гнаться, подойдут не самые старшие модели из линейки Pentium или AMD Athlon. Желательно чтобы процессор имел кэш L1 большего объема.Оперативная память: 1Gb. В случае платформы Intel следует устанавливать 2 x 512 MБ DIMM для организации двухканального режима доступа к памяти.Таблица – структура данных, состоящая из конечного числа однотипных данных.Таблица представляет собой набор записей, имеет следующие особенности:характеризует класс объектов;поля таблицы описывают атрибуты объекта;любая запись является реальным объектом.Выделяют два вида таблиц:- базовая: используется для хранения данных, участвует в структуре БД;- виртуальная: является результатом выполнения запроса, не хранится и формируется при каждом запуске запроса [17].Таблица «Автомобиль» описывает все данные об автомобилях (рисунок 2.7, 2.8). Она состоит из 13 полей (рис.0000), где поле № Инвентаризационный номер является первичным ключевым полем, и данные в нем не повторяются, т.к. автомобилей с одним номером быть не может. Так же есть поля Код топлива, которое связано с таблицей топливо, Инв. № связанное с таблицей водитель. Рис. 2.7 Таблица «Автомобиль» в режиме конструкторНа рисунке 2.8 представлена таблица «Автомобиль» в режиме конструктор.Рис. 2.8 Таблица «Автомобиль» в режиме таблицаТаблица «Водитель» содержит все данные о водителях (рисунок 15,16): табельный номер, ФИО (фамилия имя и отчество водителя), адрес проживания, контактный телефон, стаж вождения семейное положение.Рис. 2.9. Таблица «Водитель» в режиме конструкторНа рисунке 2.10 представлена таблица «Водитель» в режиме конструктор.Рис. 2.10 Таблица «Водитель» в режиме таблицаСледующая таблица «Путевой лист» (рисунок 2.11, 2.12) описывает данные о предстоящей работе. Таблица состоит из 17 полей, где поле номер является главным (ключевым полем). Так же в таблицу входят поля: дата заказа, табельный номер водителя, дата выезда, показания спидометра при выезде, остаток топлива в баке при выезде, так же такие поля как, дата возвращения, показания спидометра при возвращении, сколько было пройдено километров, расход топлива по норме и т.п. Рис. 2.11. Таблица «Путевой лист» в режиме конструкторНа рисунке 2.12 показана таблица «Путевой лист» в режиме конструктор.Рис. 2.13 Таблица «Путевой лист» в режиме таблицаСледующая таблица «Топливо» представленная на рисунках 2.14 и 2.15 она описывает данные об используемом топливе. Состоит из трех полей. Главным (ключевым) полем является поле Код топлива, так же в таблицу входят поля марка топлива и цена.Рис. 2.14. Таблица «Топливо» в режиме конструкторНа рисунке 19 представлена таблица «Топливо» в режиме конструктор.Рис. 2.15. Таблица «Топливо» в режиме таблицаСхема данных рисунок 2.16 является не только средством графического отображения логической структуры базы данных, она активно используется системой в процессе обработки данных. Создание схемы данных позволяет упростить конструирование многотабличных форм, запросов, отчетов и страниц доступа к данным, а также обеспечить поддержание целостности взаимосвязанных данных при корректировке таблиц.Рис. 2.16. Схема данных2.3 Разработка базы данныхВыполнение работ по созданию базы данных начинается с написания технического задания по разрабатываемому программному продукту. Исходя из тех. задания определяется платформа на которой будет реализована разработка программного продукта. После чего проводится предварительная подготовка, целью которой является описание таблиц для последующей разработки, а также создание первоначальных макетов форм будущего интерфейса. После чего уже происходит непосредственно разработка программного продукта: создаётся схема данных, формируются все необходимые процедуры, и разрабатывается пользовательский интерфейс. Следующим этапом разработки является отладка. В процессе отладки проводится предварительное тестирование: проверяется функционирование системы, соответствие требованиям пользователей. Выявленные недостатки устраняются.После доработки программного продукта осуществляется его сдача в эксплуатацию. База данных размещается на сервере компании, на рабочих станциях устанавливаются приложения. После чего проводится написание инструкции и обучение пользователей работе с программным продуктом. В заключении проводится анализ внедрения.После доработки программного продукта осуществляется его сдача в эксплуатацию. База данных размещается на сервере компании, на рабочих станциях устанавливаются приложения. После чего проводится написание инструкции и обучение пользователей работе с программным продуктом. В заключении проводится анализ внедрения.2.4 UML диаграммы2.4.1 Диаграмма вариантов использованияРассмотрим систему заказа на предприятии. Заказ выполняется при наличии товара на складе. В случае изменения срока поставки магазин информирует об изменении условий поставки с целью получения согласия на новые условия выполнения Заказа в целом, либо в части.В случае изменения цены товара в ходе исполнения заказа такие изменения согласуются покупателем.