Программа для системы управления мебельным производством

На рис. 3.3 приведена схема информационных потоков малого предприятия.

Рисунок 3.3 - Схема информационных потоков

Эту идею мы применим к диаграмме потоков. На рис. 3.4 представлена логическая диаграмма потоков данных. Основные элементы - действия (связи).

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

Рисунок 3.4 - Диаграмма потоков данных малого мебельного предприятия

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

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

Проводимый анализ дал такой результат - универсальное отношение, содержащее следующие данные:

информация о товаре;

учет продажи товаров;

учет остатков товара;

контроль оплаты за товар;

необходимые документы;

счета фирмы в банке;

товар на складе;

количество товара;

информация о договорах;

информация о фирмах;

информация о сделках;

информация об оплате;

поставленный товар;

сотрудник торговой фирмы;

контроль над продажей;

деятельность предприятия;

менеджер по продаже;

отдел бухгалтерии;

бухгалтер;

кассир;

кладовщик;

договор на поставку товара;

срок периодичности поставки;

вид товара;

цена товара;

количество товара;

реквизиты предприятия;

наименование предприятия;

идентификационный код;

счет в банке;

МФО банка;

наименование банка;

адрес предприятия;

телефон предприятия;

факс;

почтовый ящик в сети Internet;

счет-фактура( счет );

организация - получатель;

платежное поручение;

оплата за товар;

движение денег;

расчетный счет предприятия;

расчетный счет поставщика;

платежное поручение;

отметка банка;

выписка плательщику;

перечисления;

расчеты с поставщиками;

банки;

платежное поручение;

счет поставщика;

документы на отгрузку;

накладная на товар;

сопроводительные документы;

спецификация;

счет фактура;

установочные ярлыки;

описи;

приходная накладная;

карточка формуляр;

подсчет товара;

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

реальное количество товара;

кладовщики;

мат. ответственное лицо;

приходной ордер;

оприходование товара;

журнал реестра товара;

учет движения товара;

номенклатура ценник;

журнал учета движения денег;

финансовые операции;

подготовка товара;

подготовка товара;

заявка-заказ;

прайс-лист;

продажа товара;

менеджер по продаже;

журнал регистрации заказов;

папка заказов;

количество товара;

журнал учета товара;

плательщик;

получатель;

физическое лицо;

заказчик;

приходной кассовый ордер;

деньги;

расчетный счет фирмы-заказчика;

фирма-заказчик;

банк;

уведомление об оплате;

бухгалтерия;

движение денег;

журнал реестра движения денег;

кладовщик;

расходная накладная;

журнал отгрузки товара;

копии счет-фактуры;

описание товара;

записи по движению товара;

журнал реестра товара;

отчет бухгалтерии;

отчет кладовщика.

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

Каждая концептуальная модель данных включает:

- типы сущностей;

- типы связей;

- атрибуты;

- домены атрибутов;

- ключи.

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

определение типов сущностей;

определение типов связей;

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

создание диаграммы «сущность-связь».

Таблица 3.1 - Сведения об основных сущностях

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

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

Определение связей между сущностями.

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



Таблица 2.2 - Типы связей

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

Определение атрибутов и связывание их с типами приведено в табл. 3.3.

Таблица 3.3 - Атрибуты сущностей

Тип сущности	Наименование	Тип	Ширина поля
Поставщик	Наименование орган. Контактное Лицо Должность Адрес Город Область Страна Индекс Телефон Факс Домашняя страница	C С С С C С С C С С С	50 25 15 100 30 30 10 8 50 50 50
Клиент	Наименование орган. Контактное Лицо Должность Адрес	C С С C	50 25 15 100
Клиент	Город Область Страна Индекс Телефон Факс Домашняя страница	С C С С C С С С	100 30 30 10 8 50 50 50
Заказ	КодЗаказа КодКлиента КодСотрудника ДатаРазмещения ДатаИсполнения ДатаНазначения Доставка СтоимостьДоставки НазваниеПолучателя АдресПолучателя ГородПолучателя ОбластьПoлучателя СтранаПолучателя ИндексПолучателя кодОтборочНакладной	N N N T T T C N C C C C C N N	10 10 10 10 10 10 20 10 30 30 30 30 30 30 10
Тип Товара	КодТипа товара Категория Описание Изображение	N C C OLE	10 20 150
Товар	код товара категория товара наименование поставщик единица измерения закупочная цена	N C C C C N	7 20 30 50 15 10
	розничная цена остаток на складе ожидается минимальный запас поставки прекращены	N N N N N	15 10 10 10 2
Сотрудник	КодСотрудника Фамилия Имя Отчество	N C C C	10 15 15 15
Сотрудник	Должность Обращение ДатаРождения ДатаНайма Адрес Город Область Страна Индекс Домашний телефон Добавочный Фотография Кому подчиняется Примечание	C C T T C C C C C C C OLE C C	15 15 10 10 50 15 15 15 10 50 50 OLE 50 250
Товарная накладная	КодТовНакладной Дата кодСотрудника	N T N	20 10 10
Отборочная накладная	КодОтбНакладной Дата кодСотрудника	N T N	20 10 10
Налоговая накладная	КодНалогНакладной КодРасхнойНакл Дата кодСотрудника	N N T N	20 20 10 10
Расходная накладная	КодРасхНакладной КодОтборочнойНакл Дата кодСотрудника	N N T N	20 20 10 10
Возвратная накладная	КодВозврНакладной КодКлиента Дата кодСотрудника	N N T N	20 20 10 10
Заявка	КодТовара КодЗаказаЦена Количество Скидка КодФормыОплаты	N N N N N N	10 10 10 10 10 10
ФормаОплаты	КодФормыОплаты Название	N C	10 15
ФормДоставки	КодФормыДоставки Название	N C	10 15

3.4 Построение модели данных на основе диаграмм ER-типа

Работа существенно упрощается, если сложная система помимо обширного текстового описания имеет и некоторое визуальное представление. Для представления связей между ними обычно используются диаграмма “сущность-связь”( ER-диаграммы).

Диаграммы «сущность-связь» (ER) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ER осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей) [16].

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

В результате анализа получили следующие обобщенные сущности: Поставщик; Товар; Тип Товара; Заказ; Клиент; Сотрудник Товарная накладная; Возвратная накладная; Налоговая накладная Отборочная накладная; Форма оплаты; Форма доставки.

Элементы построения ER- диаграммы имеют следующие обозначения (рис. 3.5):

Рисунок 3.5 - Элементы построения ER- диаграммы

Также в результате упрощения определены основные связи между сущностями (рис. 3.6):

Рисунок 3.6, лист 2 - Основные связи между сущностями

Модель данных отражает взаимосвязи между объектами. На основе выделенных сущностей и связей построим ER-диаграмму (рис. 3.7).



Рисунок 3.7 - ER-диаграмма предметной области

3.5 Построение логической и физической модели

Логическая и физическая модели данных будут строиться с помощью CASE - средства продукта фирмы ER Win Version 4.0. Продукт имеет два уровня представления модели - логический и физический.

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

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



Таблица 3.4 - Преобразование концептуальной модели в реляционную модель

Здесь Е1, Е2-сущности 1,2; О - обязательная связь, Н - необязательная связь. Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Логическая и физическая модели представлены в приложении Е.

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

Рисунок 3.8 - Схема базы данных

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

3.6 Описание основных алгоритмов автоматизированной системы управления мебельным производством

К основным алгоритмам автоматизированной системы относятся:

регистрация договора;

регистрация поставщика и заказчика;

регистрация заказов и счетов;

добавление товара;

поиск товара, поставщиков, заказчиков, счетов или накладных по параметрическим запросам;

вычисление количества остатка товара;

алгоритм отправки и приема товара;

алгоритм оплаты товара;

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

Общая для всех выше перечисленных алгоритмов блок-схема представлена на рис. 3.9.

Рисунок 3.9 - Обобщенная блок-схема алгоритмов

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

На рис. 3.10 представлена блок-схема типового поиска.

Рисунок 3.10 - Алгоритм поиска в БД



Рисунок 3.11 - Алгоритм вычисления остатка по товару

Алгоритм санкционированного доступа в системе предназначен для отражения процесса санкционированного доступа в систему (см. рис. 3.12).



Рисунок 3.12 - Алгоритм санкционированного доступа в систему

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

4. Описание разработанной программной системы

4.1 Выбор программных и аппаратных средств для реализации системы

Для выбора оптимальных аппаратных средств существуют два критерия:

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

- финансовая обеспеченность.

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

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

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

Рекомендуемым вариантом является компьютер со следующими аппаратными возможностями: Процессор 2000 МГЦ(Сервер), 1000 (Клиент), оперативная память 1024 МБ (Сервер), 512 МБ (Клиент). Свободное дисковое пространство 20 ГБ

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

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

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

доступность.

наличие опыта работы.

требования к вычислительным ресурсам.

предоставляемые возможности.

К основным характеристикам современных ОС относят:

наличие мультизадачности.

защита памяти.

поддержка различных файловых систем.

обеспечение стабильной работы системы.

встроенная поддержка работы в локальной сети и Internet.

защита информации.

Среди современных ОС можно выделить:

Microsoft Windows ХР, Vista;

UNIX;

Linux.

В настоящее время наиболее распространенным является семейство ОС MS Windows. Обеспечивается переносимость приложений между различными OC из этого семейства. Для этих OC создано большое количество разнообразных средств разработки приложений.

Основными достоинствами OC UNIX является надежность работы. Огромным недостатком системы является ее цена и отсутствие инструментальных средств.

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

Исходя из вышесказанного, получили, что лучшей операционной системой для разработки в рассматриваемом случае является Microsoft Windows ХР.

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

Solid;

InterBase Sever;

MS SQL Server;

Oracle Server;

Sybase,

так и настольные, например, БД MS Access.

Выбор произведем по следующим критериям:

уровень программных средств;

простота реализации;

обеспечение целостности и защиты данных;

модификация;

опыт разработчиков;

требования к аппаратным средствам.

В результате в качестве базы данных будет использован MS Access, который содержит множество инструментов, предназначенных для разработки внешнего интерфейса БД, к которым давно уже привыкли пользователи ПК. Помимо языка SQL, для хранения, выборки данных и администрирования БД можно использовать также приложения с графическим интерфейсом пользователя.

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

использование CASE технологий;

обеспечение доступа к базе данных;

наличие визуальной технологии разработки интерфейса;

поддержка объектно-ориентированного стиля программирования;

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

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

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

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

По требованиям заказчика наша автоматизированная система должна работать под ОС Windows. Поэтому будем выбирать программные средства согласно этому ограничению.

Для выбора воспользуемся следующими критериями:

опыт разработчиков;

время написания;

проектирование интерфейса;

удобство проектирование под Windows.

В результате проведенного исследования получили, что лучшим инструментальным средством для разработки системы является интегрированная среда разработки Borland C++ Builder.

4.2 Структура автоматизированной системы

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

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

- администратора системы, которому позволено делать изменения во всей системе, в том числе и создавать ее новые элементы;

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

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

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

Рисунок 4.1 - Диаграмма вариантов использования

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

администраторы;

менеджеры;

бухгалтеры;

кладовщики.

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

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

Интерфейс сервера должен быть очень прост, но обладать достаточной информацией по части выполняемой работы.

Интерфейс программы при работе с разделом «Поставщики» приведен на рис. 4.2.

Рисунок 4.1 - Интерфейс программы, раздел «Поставщики»

Интерфейс программы с при работе с разделом «Товар» приведен на рис. 4.3.

Рисунок 4.3 - Интерфейс программы, раздел «Товар»

Интерфейс программы с при работе с разделом «Сотрудник» приведен на рис. 4.4.



Рисунок 4.4 - Интерфейс программы, раздел «Сотрудник»

Диаграмма взаимодействия модулей сервера показана на рис. 4.5.

Рисунок 4.5 - Диаграмма взаимодействия модулей сервера

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



4.3 Руководство пользователя

В ПО реализована автоматизированная система поддержки принятия решений по учету товаров на малом предприятии. ПО решает следующие задачи:

создание баз данных по поставщикам/заказчикам, товаров, договоров, счетов, заказов;

добавление данных в БД;

изменение данных в БД;

удаление данных в БД;

реализация запросов, формирование отчетов;

обеспечение защиты от несанкционированного доступа.

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

информации по поставщикам/заказчикам;

информации о товарах, которые хранятся на складе;

информации о движении товара;

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

Для нормальной работы ПО необходимы следующие минимальные требования:

20000 Mb свободного дискового пространства для сервера СУБД;

для сервера - 1024 МБ, а для клиента 512 МБ оперативной памяти;

видеопамять не менее 256 МБ;

процессор - 2000 МГц (сервер), 1000 МГц (клиент).

Входными данными для выполнения работы являлись договора, заказ-заявки, накладные, счета. Выходными данными являлись: сформированные накладные, счета, отчетность по товару, данные о движении денег, прайс-листы по товару, отчетность по счетам, отчетность по заказам. Для установки системы требуется скопировать 2 каталога с именем “Client” и “Server”.

5. Анализ опытной эксплуатации и возможных приложений

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

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

При эксплуатации данный программный продукт позволит:

сократить временные и трудовые затраты при закупке и продаже товара;

сократить сроки составления отчетности;

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

повысить эффективность сбора и учета информации о товаре, поставщиках и заказчиков;

повысить культуру обслуживания.

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

выбрана реализация модели данных;

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

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

проведено комплексное тестирование разработанного ПП;

определена оценка экономической эффективности применения программного обеспечения и его цена.

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

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

Основными задачами программного продукта (ПП) являются:

Создание серверной части ПП содержащей БД, которая хранит информацию: о товарах; о поставщиках; о заказчиках; о банках; о договорах; о финансах.

Создание клиентской части для управления БД, основные функции которой:

добавление данных в БД;

изменение данных в БД;

удаление данных в БД;

реализация запросов;

формирование отчетов;

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

ПП содержит информацию:

о товарах;

о поставщиках;

о заказах;

о накладных

о заказчиках;

о договорах;

о движении товара на складе;

о движении финансов.

ПП производит изменения в базе данных:

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

изменять информацию о товарах, о фирмах, о поставке и продажи, об оплате;

удалять информацию о товарах, о фирмах, о поставке и продажи, об оплате;

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

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

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

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

Был сделан вывод, что условия работы в вычислительном центре соответствуют необходимым нормам и требованиям.

Перечень ссылок

1. Колесник, А.П. Компьютерные системы в управлении финансами [Текст]/ Колесник А.П. - М.: "Финансы и статистика",1994. - 347 с.

2. Ульман, Дж. Основы систем баз данных [Текст]/ Ульман Дж. Пер. с англ. - М: “Финансы и статистика”, 1983. - 537 с.

3. Конноли, Т. Дазы данных: проектирование, реализация и сопровождение [Текст]/ Томасон Конноли и Каролин Бегг. М.: Издательство дом “Вильямс”. - 2000. - 658 с.

4. Васильев, В.Г. Объектно-ориентированные БД: Взгляд изнутри [Текст]/ Васильев В.Г. // Компьютеры + Программы - 1997 - №3 - С. 45-49.

5. Иллингуорт, В. Толковый словарь по вычислительным системам / Под ред. В. Иллингуорта и др. [Текст]/ Пер. с англ. А.К. Белоцкого и др.; Под ред. Е.К. Масловского. - М.: Машиностроение, 1991. - 688 с.

6. Глен, Дж. Проектирование реляционных бах данных для использования с микроЭВМ [Текст]/ Дж. Глен. - М: Мир, 1991. - 705 с.

7. Андреев, А.М., Березкин Д.В., Кантонистов Ю.А. Среда и хранилище: ООБД [Текст]/ Андреев А.М., Березкин Д.В., Кантонистов Ю.А. // Мир ПК - 1998 - №4 - с.74-81

8. Гради, Б. Объектно-орентированное проектирование с примерами [Текст]/ Гради Буч. Пер. с англ. М.: Конкорд, 1992.

9. Малярский, А.Н. Храните данные на базе [Текст]/ Малярский А.Н., Неплохов В.Ю., Хруст В.А. // Мир ПК - 1997 - №2 - с.62-66.

10. Гостлинг, Д. Язык программирования Java [Текст]/ Гостлинг Д., Арнольд К. СПб: Питер. - 1997. - 477 с.

11. Эккель, Б. Философия Java [Текст]/ Эккель Б. Библиотека програмиста. СПб: Питер, 2001. - 351 с.

12. Винкоп, С. Использование Microsoft SQL Server 7.0 [Текст]/ Стефан Винкоп. - М, 1999

13. Тараканов, К.В. Информатика [Текст]/ Учебное пособие; Под ред. проф. Тараканова К.В. М.: “Книга”, 1986. 578 с.

14. Единая система программной документации [Текст]/ - М: Издательство стандартов, 1988. - 322 с.

15. Озкарахан Э. Машины баз данных и управление базами данных [Текст]/ Озкарахан Э. Пер. С англ. - М.: Мир, 1989. 472 с.

16. Майерс, Г. Искусство тестирования программ [Текст]/ Майерс Г. - М: Финансы и статистика, 1982. - 395 с.

17. Майерс, Г. Надежность ПО [Текст]/ Майерс Г. - М.: Мир, 1980. - 243 с.

18. Свод законов о предпринимательской деятельности [Текст]/ К.:“Вища освіта”, 2001. - 158 с.

19. Майнетт Т. Разработка программного обеспечения [Текст]/ Барби Тизли Майнетт. Перевод с английского. MVU. Львов-Днепропетровск, 1995.

20. Нагао, М. Структуры и базы данных [Текст]/ Нагао М., Катаяма T., Уємура С. Пер. с япон. - М.:Мир, 1986. - 197 с., ил.

21. Ван Тассел, Д. Стиль, разработка, эффективность, отладка и испытание программ [Текст]/ Ван Тассел Д.: Пер. с англ. - 2-е изд., испр., - М.: Мир, 1985. - 332 с.

22. Маклаков, С.В. Bpwin и Erwin. Case - средства разработки информационных систем [Текст]/ Маклаков С.В. - М.: ДИАЛОГ-МИФИ, 1999. - 256 с.

23. Вагнер, Г. Основы исследования операций [Текст]/ Вагнер Г. - М.: Мир, 1972. - 333 с.

24. Вентцель, Е.С. Исследование операций [Текст]/ Вентцель Е.С. - М.: Советское радио, 1972.- 488 с.

25. Марка, Д.А. Методология структурного анализа и проектирования [Текст]/ Марка Д.А., МакГоуэн К. М., "МетаТехнология", 1993. - с. 128-141.

26. Шураков, В.В. Обеспечение сохранности информации в СОД [Текст]/ Шураков В.В. Издательство “Финансы и статистика”, 1985.

27. Спесивцев, А.В. Защита информации в персональных ЭВМ [Текст]/ Спесивцев А.В., Вегнер В.А., КрутяковА.Ю. и др. М.: Радио и связь, МП Веста. - 1992 - 231 с.

28. Шумаков, П.В. Delphi 5. Руководство разработчика баз данных [Текст]/ Шумаков П.В., Фаронов В.В. - М.: Нолидж, 2000. - 635 с

29. Флэнэген, Д. Java in a Nutshell [Текст]/ Девид Флэнэген. К.: Издательская группа BHV, 1998. - 293 с.

Приложение A

Слайды презентации



Приложение Б

Листинг фрагментов кода программ

ЗАПРОСЫ К БД

Выбор счета

SELECT DISTINCTROW Счета.*

FROM Счета

WHERE (((Счета.КодЗаказа)=[Forms]![Заказы]![КодЗаказа]));

10 самых дорогих товаров

SELECT DISTINCTROW TOP 10 Товары.Марка AS СамыеДорогиеТовары, Товары.Цена

FROM Товары

ORDER BY Товары.Цена DESC;

Заказы

SELECT DISTINCTROW Заказы.КодЗаказа, Заказы.КодКлиента, Заказы.КодСотрудника, Заказы.ДатаРазмещения, Заказы.ДатаНазначения, Заказы.ДатаИсполнения, Заказы.Доставка, Заказы.СтоимостьДоставки, Заказы.НазваниеПолучателя, Заказы.АдресПолучателя, Заказы.ГородПолучателя, Заказы.ОбластьПолучателя, Заказы.ИндексПолучателя, Заказы.СтранаПолучателя, Клиенты.Название, Клиенты.Адрес, Клиенты.Город, Клиенты.Область, Клиенты.Индекс, Клиенты.Страна

FROM Клиенты INNER JOIN Заказы ON Клиенты.КодКлиента = Заказы.КодКлиента;

Итоги продаж по объему

SELECT DISTINCTROW [Промежуточная сумма заказа].ПромежуточнаяСумма AS ОбъемПродаж, Заказы.КодЗаказа, Клиенты.Название, Заказы.ДатаИсполнения

FROM Клиенты INNER JOIN (Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа) ON Клиенты.КодКлиента = Заказы.КодКлиента

WHERE ((([Промежуточная сумма заказа].ПромежуточнаяСумма)>25000) AND ((Заказы.ДатаИсполнения) Between #1/1/1997# And #12/31/2008#));

Квартальные обороты

SELECT DISTINCTROW [Клиенты].[КодКлиента], [Клиенты].[Название], [Клиенты].[Город], [Клиенты].[Страна]

FROM Клиенты RIGHT JOIN Заказы ON [Клиенты].[КодКлиента]=[Заказы].[КодКлиента]

WHERE ((([Заказы].[ДатаРазмещения]) Between #1/1/2008# And #12/31/2008#));

Квартальные обороты по товарам

TRANSFORM Sum(CCur([Заказано].[Цена]*[Количество]*(1-[Скидка])/100)*100) AS СуммаПоТовару

SELECT [Товары].[Марка], [Заказы].[КодКлиента], Year([ДатаРазмещения]) AS ГодЗаказа

FROM Товары INNER JOIN (Заказы INNER JOIN Заказано ON [Заказы].[КодЗаказа]=[Заказано].[КодЗаказа]) ON [Товары].[КодТовара]=[Заказано].[КодТовара]

WHERE ((([Заказы].[ДатаРазмещения]) Between #1/1/2008# And #12/31/2008#))

GROUP BY [Товары].[Марка], [Заказы].[КодКлиента], Year([ДатаРазмещения])

PIVOT "Кв " & DatePart("q",[ДатаРазмещения],1,0) In ("Кв 1","Кв 2","Кв 3","Кв 4");

Клиенты и поставщики по городам

SELECT Город, Название, ОбращатьсяК, "Клиенты" AS [Отношения]

FROM Клиенты

UNION SELECT Город, Название, ОбращатьсяК, "Поставщики"

FROM Поставщики

ORDER BY Город, Название;

Продажи по годам

PARAMETERS Forms![Продажи по годам]!НачальнаяДата DateTime, Forms![Продажи по годам]!КонечнаяДата DateTime;

SELECT DISTINCTROW Заказы.ДатаИсполнения, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма, Format([ДатаИсполнения],"yyyy") AS Год

FROM Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа

WHERE (((Заказы.ДатаИсполнения) Is Not Null And (Заказы.ДатаИсполнения) Between [Forms]![Продажи по годам]![НачальнаяДата] And [Forms]![Продажи по годам]![КонечнаяДата]));

Продажи по сотрудникам и странам

PARAMETERS [Начальная дата] DateTime, [Конечная дата] DateTime;

SELECT DISTINCTROW Сотрудники.Страна, Сотрудники.Фамилия, Сотрудники.Имя, Заказы.ДатаИсполнения, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма AS СуммаПродаж

FROM Сотрудники INNER JOIN (Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа) ON Сотрудники.КодСотрудника = Заказы.КодСотрудника

WHERE (((Заказы.ДатаИсполнения) Between [Начальная дата] And [Конечная дата]));

Продажи по типам

SELECT DISTINCTROW Типы.КодТипа, Типы.Категория, Товары.Марка, Sum([Сведения о заказах].ОтпускнаяЦена) AS ПродажиТовара

FROM Типы INNER JOIN (Товары INNER JOIN (Заказы INNER JOIN [Сведения о заказах] ON Заказы.КодЗаказа = [Сведения о заказах].КодЗаказа) ON Товары.КодТовара = [Сведения о заказах].КодТовара) ON Типы.КодТипа = Товары.КодТипа

WHERE (((Заказы.ДатаРазмещения) Between #1/1/1997# And #12/31/2008#))

GROUP BY Типы.КодТипа, Типы.Категория, Товары.Марка

ORDER BY Товары.Марка;

SELECT DISTINCTROW [Продажи товаров в 2008].Категория, Sum([Продажи товаров в 2008].ПродажиТоваров) AS ПродажиПоТипам

FROM [Продажи товаров в 2008]

GROUP BY [Продажи товаров в 2008].Категория;

SELECT DISTINCTROW [Типы].[Категория], [Товары].[Марка], Sum(CCur([Заказано].[Цена]*[Количество]*(1-[Скидка])/100)*100) AS ПродажиТоваров, "Кв " & DatePart("q",[ДатаИсполнения]) AS КварталИсполнения

FROM (Типы INNER JOIN Товары ON [Типы].[КодТипа]=[Товары].[КодТипа]) INNER JOIN (Заказы INNER JOIN Заказано ON [Заказы].[КодЗаказа]=[Заказано].[КодЗаказа]) ON [Товары].[КодТовара]=[Заказано].[КодТовара]

WHERE ((([Заказы].[ДатаИсполнения]) Between #1/1/2008# And #12/31/2008#))

GROUP BY [Типы].[Категория], [Товары].[Марка], "Кв " & DatePart("q",[ДатаИсполнения]);

Промежуточная сумма заказа

SELECT DISTINCTROW [Заказано].[КодЗаказа], Sum(CCur([Цена]*[Количество]*(1-[Скидка])/100)*100) AS ПромежуточнаяСумма

FROM Заказано

GROUP BY [Заказано].[КодЗаказа];

Сведения о заказах

SELECT DISTINCTROW [Заказано].[КодЗаказа], [Заказано].[КодТовара], [Товары].[Марка], [Заказано].[Цена], [Заказано].[Количество], [Заказано].[Скидка], CCur([Заказано].[Цена]*[Количество]*(1-[Скидка])/100)*100 AS ОтпускнаяЦена

FROM Товары INNER JOIN Заказано ON [Товары].[КодТовара]=[Заказано].[КодТовара]

ORDER BY [Заказано].[КодЗаказа];

Список имеющихся товаров

SELECT [Список товаров].КодТовара, [Список товаров].Марка

FROM Товары AS [Список товаров]

WHERE ((([Список товаров].ПоставкиПрекращены)=No))

ORDER BY [Список товаров].Марка;

Список товаров

SELECT DISTINCTROW Товары.*, Типы.Категория

FROM Типы INNER JOIN Товары ON Типы.КодТипа = Товары.КодТипа

WHERE (((Товары.ПоставкиПрекращены)=No));

Сумма продаж по кварталам

SELECT DISTINCTROW Заказы.ДатаИсполнения, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма

FROM Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа

WHERE (((Заказы.ДатаИсполнения) Is Not Null))

ORDER BY Заказы.ДатаИсполнения;

Сумма продаж по годам

SELECT DISTINCTROW Заказы.ДатаИсполнения, Заказы.КодЗаказа, [Промежуточная сумма заказа].ПромежуточнаяСумма

FROM Заказы INNER JOIN [Промежуточная сумма заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа

WHERE (((Заказы.ДатаИсполнения) Is Not Null))

ORDER BY Заказы.ДатаИсполнения;

Счета

SELECT DISTINCTROW [Заказы].[НазваниеПолучателя], [Заказы].[АдресПолучателя], [Заказы].[ГородПолучателя], [Заказы].[ОбластьПолучателя], [Заказы].[ИндексПолучателя], [Заказы].[СтранаПолучателя], [Заказы].[КодКлиента], [Клиенты].[Название], [Клиенты].[Адрес], [Клиенты].[Город], [Клиенты].[Область], [Клиенты].[Индекс], [Клиенты].[Страна], [Имя] & " " & [Фамилия] AS Продавец, [Заказы].[КодЗаказа], [Заказы].[ДатаРазмещения], [Заказы].[ДатаНазначения], [Заказы].[ДатаИсполнения], [Доставка].[Название], [Заказано].[КодТовара], [Товары].[Марка], [Заказано].[Цена], [Заказано].[Количество], [Заказано].[Скидка], CCur([Заказано].[Цена]*[Количество]*(1-[Скидка])/100)*100 AS ОтпускнаяЦена, [Заказы].[СтоимостьДоставки]

FROM Товары INNER JOIN (Сотрудники INNER JOIN (Клиенты INNER JOIN ((Доставка INNER JOIN Заказы ON [Доставка].[КодДоставки]=[Заказы].[Доставка]) INNER JOIN Заказано ON [Заказы].[КодЗаказа]=[Заказано].[КодЗаказа]) ON [Клиенты].[КодКлиента]=[Заказы].[КодКлиента]) ON [Сотрудники].[КодСотрудника]=[Заказы].[КодСотрудника]) ON [Товары].[КодТовара]=[Заказано].[КодТовара];

Товары по типам

SELECT DISTINCTROW Типы.Категория, Товары.Марка, Товары.ЕдиницаИзмерения, Товары.НаСкладе, Товары.ПоставкиПрекращены

FROM Типы INNER JOIN Товары ON Типы.КодТипа = Товары.КодТипа

WHERE (((Товары.ПоставкиПрекращены)<>Yes))

ORDER BY Типы.Категория, Товары.Марка;

Товары с ценой выше средней

SELECT DISTINCTROW Товары.Марка, Товары.Цена

FROM Товары

WHERE (((Товары.Цена)>(SELECT AVG([Цена]) From Товары)))

ORDER BY Товары.Цена DESC;

Приложение В

Рисунок Д.1 - Логическая модель предметной области

Рисунок Д.2 - Физическая модель предметной области

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

...