Автоматизация процесса работы отдела продаж "Новый Стиль Украина"
Анализ публикаций по вопросу системы автоматизации учета движения товаров и формирования отчетности на промышленных предприятиях Украины. Методологии и технологии проектирования. Системная архитектура "клиент-сервер". Требование к аппаратному обеспечению.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 02.06.2017 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
СПИСОК УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СОКРАЩЕНИЙ И ТЕРМИНОВ
ПК - персональный компьютер;
ПО - программное обеспечение;
ПЭВМ - персональная электронно-вычислительная машина;
ОЗУ - оперативное запоминающее устройство;
MHz- мегагерц;
Мb - мегабайт;
Gb - гигабайт;
ОС - операционная система;
ЭВМ - электронно-вычислительная машина;
ООП - объектно-ориентированного программирования;
ОП - оперативная память;
АС - автоматизированная система
CASE (Computer Aided Soft/System Engineering) - автоматизированная система проектирования и разработки программного обеспечения;
БД - база данных;
СКИ - система команд исполнителя.
ВВЕДЕНИЕ
С появлением компьютерной техники появилась возможность выполнить автоматизацию процессов в различных отраслях науки и производства. В то время как малые предприятия заявляют о нехватке ПК и программных продуктов, большие, ведущие предприятия обогащают себя ПК и нужными программными средствами, которые повышают эффективность работы, как самого предприятия, так и каждого подразделения.
В настоящее время предприятие АОЗТ «Новый Стиль Украина» разрастается до гигантских размеров, а вследствие этого происходит усложнение структуры предприятия и возникает необходимость в автоматизации подразделений предприятия. АОЗТ «Новый Стиль Украина» имеет свой отдел по разработке программного обеспечения, который создает ПО облегчающий работу подразделениям, нуждающимся в автоматизации.
Отдел продаж является одним из основных подразделений любой организации. Перед этим отделом встает множество задач по ведению учета различных параметров и составления отчетности - все это является тяжелой рутинной работой, требующей огромных временных затрат и большого напряжения.
Работа отдела по продажам связана с накоплением большого количества информации о товаре и о потребителях. Традиционно информация храниться на бумажных носителях. При этом трудно осуществить быстрый отбор нужных данных при заказе или отправке товаров, учесть наличие на складах, наименование, или другие положения касающиеся продаж. Работа, которая там ведется сложна и трудоемка, возникает множество ошибок, связанных с человеческим фактором, так как предприятие насчитывает несколько тысяч наименований продукции, выпускаемой и продаваемой ежедневно. По каждому из наименований продукции необходимо вести оперативную информацию, кроме того, в течение всего года происходят модификации товара по оформлению и комплектации, что соответствующим образом должно быть учтено отделом по продажам. Поэтому автоматизация даже части работы отдела продаж позволит серьезно уменьшить время и количество ошибок при оформлении документов, формировании отчетности, снизить нагрузку на сотрудников и увеличить эффективность работы подразделения и предприятия в целом.
Учитывая специфику отдельного предприятия, можно утверждать, что на сегодняшний день не существует свободных или свободно распространяемых продуктов, выполняющих данную работу. Коммерческие же программы стоят достаточно дорого, ориентированы на операционные системы компании Microsoft и требуют конфигурации в соответствии с требованиями конкретной организации. Поэтому создание собственного программного обеспечения является обоснованным и наиболее верным решением, так как система создается непосредственно для нужд АОЗТ «Новый Стиль Украина».
Динамичные изменения правил, требований, форм отчетности приводят к частым авральным состояниям отдела продаж. Очевидны два пути: значительное увеличение рабочего штата либо приобретение или разработка специализированного программного обеспечения и внедрение компьютерной техники.
Программное обеспечение системы автоматизации учета движения товаров и формирования отчетности на АОЗТ «Новый Стиль Украина» позволит:
снизить пиковые нагрузки с рабочего персонала отдела продаж;
своевременно выполнять работы в установленные сроки;
упорядочить взаимоотношения предприятия с клиентами;
уменьшить количество ошибок и неточностей в документах и отчетах связанных с человеческим фактором;
значительно уменьшить временные затраты на формирование отчетности, отображающей движение товаров на другие фирмы и предприятия.
Немаловажен вопрос надежности хранения и конфиденциальности данных о товарах и ценах на них. При большой численности товара находящегося на предприятии такого масштаба отдел по продажам состоит из начальника отдела и нескольких сотрудников. Фактически, только начальник отдела продаж должен иметь полный доступ к данным и информации.
Таким образом, автоматизация процесса работы отдела продаж является нужным и перспективным процессом. До написания данного дипломного проекта на АОЗТ «Новый Стиль Украина» работа велась вручную, данные о продажах и переводах товаров были не систематизированы, и учет велся в специальных журналах.
От того насколько тщательно проведен анализ и насколько грамотно спроектирована БД, в существенной мере зависит эффективность будущей БД и ее полезность для пользователя [1]. С учетом имеющихся знаний относительно построения баз данных с помощью FireBird 2.5 технологии и архитектуры «клиент-сервер» было принято решение написать программу с учетом требований данного предприятия. Данные средства реализации являются бесплатными и достаточно функциональными, что позволило решить поставленную задачу в соответствии с требованиями заказчика к программному продукту.
Создание программного обеспечения автоматизированной системы «Market» является актуальной и перспективной разработкой, которая в дальнейшей работе предприятия АОЗТ «Новый Стиль Украина» будет помогать правильно и безукоризненно вести все дела, касающиеся учета движения товаров и формирования отчетности на предприятии.
1. СОСТОЯНИЕ ПРОБЛЕМЫ АВТОМАТИЗАЦИИ УЧЕТА ДВИЖЕНИЯ ТОВАРОВ И ФОРМИРОВАНИЯ ОТЧЕТНОСТИ. ПОСТАНОВКА ЗАДАЧ ДИПЛОМНОГО ПРОЕКТА
1.1 Обзор и анализ публикаций по вопросу системы автоматизации учета движения товаров и формирования отчетности на промышленных предприятиях Украины
В настоящее время существует множество программ для автоматизации учета движения товаров и формирования отчетности, но они или слишком громоздкие, или слишком дорогие, или слишком сложные для простых пользователей, или настолько мощные, что старенькие машины, стоящие на многих фирмах и предприятиях не в состоянии потянуть такое ПО.
Например 1С. Для работы с 1С [2] бухгалтерией необходимо иметь высокую квалификацию, опыт работы с ней, т.е. предприятию необходимо дополнительно обучать свой персонал. Это громоздкий программный комплекс со своим встроенным языком программирования, который не понятен работнику отдела и он не сможет внести коррективы необходимые ему для работы, т.е. нужен программист. Программный комплекс 1С требует постоянного обновления, что влечет за собой выплату средств. Эта программа включает в себя множество приложений не нужных простому работнику[2].
Именно поэтому руководство АОЗТ «Новый Стиль Украина» и заказало автоматизированное ПО, необходимое непосредственно для работы своих отделов и которое бы отвечало всем нуждам и требованиям отдела продаж предприятия.
Кандзюбов С.П. и Громов В.Н отметили, что всякая прикладная программа является отображением какой-то части реального мира и поэтому содержит его формализованное описание в виде данных [3]. Крупные массивы данных размещают, как правило, отдельно от исполняемого кода программы, и организуют в виде баз данных. Для работы с данными используют особые программные комплексы, называемыми системами управления базами данных (СУБД). Системы управления базами данных отвечают за:
физическое размещение данных и их описание;
поиск данных;
поддержка баз данных в актуальном состоянии;
защиту данных от некорректных обновлений и несанкционированного доступа;
обслуживание одновременных запросов к данным от нескольких пользователей (прикладных программ).
Огромное значение приобрели, по мнению Кандзюбова С.П. и Громова В.Н., средства автоматизированного проектирования информационных систем - так называемые CASE-средства (от английского «Computer-Aided Softwaer / System Engineering») [3, 27].
За последние годы значительно возрос объем и оборот информации во всех сферах жизнедеятельности человека: экономической, финансовой, политической. Также значителен этот рост в жизни предприятий и фирм, которые развиваются быстрыми темпами благодаря разработкам ПО. В этом процессе быстрого подъема предприятий и фирм растет непосредственно конкуренция. Все это происходит благодаря тому, что малая фирма не в состоянии обеспечить свои отделы программным продуктом не только качественным, но и самым элементарным. Процесс накопления, обработки и использования знаний постоянно ускоряется. На преуспевающих предприятиях работа отдела по продажам связана с накоплением большого количества информации о продукции, поэтому возникает необходимость использования хорошей и качественной автоматизированной системы, позволяющей эффективно хранить информацию о товаре, который находится на складах, обрабатывать и распределять накопленные данные. Таким образом, при применении автоматизированных систем значительно сокращается время формирования отчетности и составления документов персоналом, ускоряется выполнение необходимой работы. Основной задачей проектируемой автоматизированной системы будет являться учет движения товаров и формирование отчетности.
На данный момент на АОЗТ «Новый Стиль Украина» работа ведется вручную, данные о наличии товаров не систематизированы и хранятся в специальных журналах. Таким образом, автоматизация процесса работы отдела продаж является актуальным и перспективным процессом. Результатом работы является БД и АС для учета движения товаров и формирования отчетности, которая нашла практическое применение в отделе продаж на АОЗТ «Новый Стиль Украина» [33].
Создание собственной автоматизированной системы и БД позволит учесть все особенности данного предприятия, позволит сократить время на выполнение рутинных работ, повысит эффективность работы предприятия. На основании этого можно сказать, что разработка автоматизированной системы учета движения товаров и формирования отчетности на АОЗТ «Новый Стиль Украина» является актуальной и перспективной, так как на основе уже хранящейся в базе данных информации о продукции работает отдел по продажам.
Разработка данного ПО не является новаторской в своей области. Существуют многочисленные аналоги разрабатываемого программного продукта, которые размещены непосредственно на различных фирмах и предприятиях, как малых так и больших эти программные продукты предназначены также для учета движения товаров и средств, которые, однако, имеют ряд существенных недостатков, к которым относят большую ресурсоемкость, не русифицированность, стоимость лицензии. Планируется, что разрабатываемый программный продукт будет лишен недостатков, указанных выше и будет применяться ограниченным кругом предприятий или фирм, а также некоторых организаций для работы непосредственно с учетом особенностей организаций. Поэтому разработка ПО «Market» для автоматизации учета товаров и формирования отчетности будет актуальна [26].
1.2 Цель выполненного программного продукта
Повысить производительность работ отдела продаж АОЗТ «Новый Стиль Украина», повысить качество выполняемых работ, снизить количество рутинных операций при формировании документов за счёт системы автоматизации учёта движения товаров и формирования отчетности.
1.3 Постановка задач дипломного проекта
товар движение учет
Для достижения поставленной цели и опираясь на вышесказанное, можем сформулировать основные задачи дипломного проекта.
Изучение состояния проблемы автоматизации учета движения товаров и формирования отчетности на предприятиях и АОЗТ «Новый стиль Украина» в г. Харькове в частности;
Моделирование серверной части ПО системы автоматизации учета движения товаров и формирования отчетности;
Алгоритмизация программного обеспечения системы автоматизации учета движения товаров и формирования отчетности;
Проектирование программного обеспечения системы автоматизации учета движения товаров и формирования отчетности;
Верификация и валидация ПО системы автоматизации учета движения товаров и формирования отчетности;
Экономическое обоснование разработки ПО системы автоматизации учета движения товаров и формирование отчетности;
Систематизация запросов пользователя;
Безопасность жизнедеятельности в процессе эксплуатации ПО системы автоматизации учета движения товаров и формирования отчетности.
1.4 Техническое задание на разработку ПО системы автоматизации учета движения товаров и формирование отчетности на АОЗТ «Новый Стиль Украина»
1.4.1 Основанием для выполнения работы является
1) Приказ по Национальному аэрокосмическому университету о базе преддипломного проектирования от № _____ от «___»________
2) Приказ № ______ от __________.
3) График учебного процесса Национального аэрокосмического университета им. Н.Е. Жуковского «ХАИ» и учебный план специальности 7.05010301 - «Программное обеспечение систем».
1.4.2 Цель и назначение работы
Разработка ПО системы автоматизации учета движения товаров и формирование отчетности на АОЗТ «Новый Стиль Украина» преследует цели:
автоматизировать составление договоров купли-продажи на предприятии;
значительно сократить время работы персонала при верстке документации и отчетности;
оперативно собирать и формировать данные для анализа.
Автоматизированная система предназначена для обеспечения:
систематизированного учета движения товаров;
систематизированного учета продаж, прибыли и убытков;
систематизированного учета информации о наименовании и количестве товаров;
автоматизированного просмотра информации за предыдущие месяцы и годы;
автоматизированного процесса формирования движения товаров;
автоматизированного процесса обновления записи по заданным критериям.
автоматизированного формирования отчетности по запросу пользователя.
1.4.3 Функциональное назначение программного продукта
ПО обеспечивает целостность данных (с помощью автоматической индексации первичных ключей, каскадного удаления зависимых данных, поддержки внешних ключей), централизованное хранение данных, восстановление данных в исключительных ситуациях, частичный контроль входных данных, управление данными (вставка, редактирование, удаление данных), выдача результатов на запросы пользователей.
К ПО может быть подключено неограниченное число клиентов, точнее то количество, которое может обслужить сервер баз данных. Общая длина каждой записи в каждой таблице не должна превышать 32 КБайт.
1.4.4 Анализ работы отдела продаж АОЗТ «Новый Стиль Украина»
До момента внедрения разработанного программного обеспечения, данные, по учету движимости товаров которые проводились на АОЗТ «Новый Стиль Украина» заполнялись вручную и хранились в специальных книгах и папках. Документация о продажах была весьма неполной и несистематизированной. Поэтому возникла необходимость автоматизации этих работ. За счет автоматизации достигается:
Систематизирование учета:
персонального учета продаж для каждого предприятия или фирмы;
переводов товара, продажа различным фирмам как большим, так и малым;
программный продукт также предоставляет полную информации об использовании продукции не только за этот год, а из-за предыдущие года;
2. Автоматизации процесса:
формирование полного и доступного отчета, генерирование отчета в документы Word,Excel;
составления формы различных перемещения товара;
Полная вносимость информации;
3. Автоматическое формирование отчетной формы.
При эксплуатации разрабатываемое программное обеспечение позволит:
снять пиковые нагрузки с рабочего персонала который занимается продажами и поставками на различные фирмы и предприятия;
своевременно и качественно выполнять необходимые работы в установленные сроки;
упорядочить организационные взаимоотношения с персоналом предприятия.
Анализ состоит в проблеме автоматизации отдела продаж предприятия АОЗТ «Новый Стиль Украина» и показывает то, что автоматизации подлежат следующие процессы.
Продукция поступает в отдел продаж для оформления на склады, а также для подготовки его на продажу различным фирмам, предприятиям.
Пишется полное описание товара, выставляется цена на него, количество товаров измеряемая в (шт).
Отдел продаж оформляет все необходимые документы на поступивший товар и передает их на подпись руководителю предприятия или непосредственно в требуемый отдел предприятия.
Руководство предприятия возвращает документы с резолюцией в отдел продаж.
Отдел продаж предает оформленные документы непосредственно в требуемые отделы предприятия.
В связи с этим тема дипломного проекта актуальна, так как автоматизированная системы необходима предприятию. За счет автоматизации повышается эффективность работы предприятия, почти в трое повышается работа способность отдела по продажам. Отсюда вытекают следующие задачи будут представлять собой распределенную систему включающую в себя клиентскую и серверную часть, серверная часть реализована с использованием Firebird.
Требования заказчика
Внешние требования
Разрабатываемое ПО должно иметь возможность хранить данные о:
каталогах (подразделениях, товарах, контрагентах, пользователях);
приход товаров (нумерация товара, выбор предприятия и фирмы);
перемещения (наличие перечисленного товара, его цены, с какого и по какое время было сделано перемещение).
расходы (наличие товаров, наименование товаров, затраченные средства);
платежи (дата, номер, плательщик, получатель, дата сумма);
отчет (полное хранение данных о проделанной работе).
Разрабатываемое программное обеспечение должно иметь возможность получение полного результата о проделанных операциях, (удалять, изменять, добавлять и просматривать данные).
Разрабатываемое программное обеспечение должно реализовать запросы:
по продукции предприятия вывести все данные о наличии за определенный год;
по указанному году вывести количество групп по списку.
Разрабатываемое программное обеспечение, в случае ввода неправильной даты, должно выдавать предупреждающее сообщение.
В разрабатываемом программном обеспечении должна быть реализована обработка:
всех ошибочных действий оператора;
некорректных входных данных.
В разрабатываемом программном обеспечении должно быть реализовано два уровня доступа:
только чтение данных;
чтение и запись данных.
Разрабатываемое программное обеспечение должно иметь удобный для пользователя интерфейс.
Внутренние требования пользователя
Разрабатываемое программное обеспечение должно поддерживать интерфейс с пользователем на русском языке.
Разрабатываемое программное обеспечение должно функционировать на конфигурации не менее:
ОЗУ: 128Mb;
процесор - Celeron 850 MHz и совместимые;
объем оперативной памяти - 64 Mb;
не менее 100 Mb свободного места на жестком диске;
программное обеспечение должно быть рассчитано на пользователя со знаниями работы в ОС Windows.
программное обеспечение должно функционировать под управлением ОС Windows.
Приёмочные испытания должны проводится в присутствии заказчика, при выявлении ошибок в программном обеспечении разработчик должен их устранить [13].
Должны выполняться требования по надежности ПО:
приемлемый средний временной интервал между отказами ПО составляет пол года.
Новые версии программного обеспечения будут поставляться по мере их возникновения в течение 2 недель за дополнительную плату.
При появлении ошибок в течение месяца после сдачи ПО в эксплуатацию, разработчик должен их бесплатно устранить в течении недели.
Разрабатываемое программное обеспечение должно сопровождаться:
инструкцией пользователя;
пояснительной запиской;
плакаты;
техническим заданием;
демонстрационный ролик;
дискета с программной системой, документацией и презентационным роликом.
Требования к программному обеспечению
Требования по функциональности
Разрабатываемое ПО, должно выполнять следующие функции [13]:
хранить данные о:
каталогах (подразделениях, товарах, контрагентах, пользователях);
приходе товаров (нумерация товара, выбор предприятия и фирмы);
перемещениях (наличие перечисленного товара, его цены, с какого и по какое время было сделано перемещение).
расходах (наличие товаров, наименование товаров, затраченные средства);
платежах (дата, номер, плательщик, получатель, дата сумма);
отчетах (полное хранение данных о проделанной работе).
редактировать данные:
сумме;
дате;
нумерации.
реализовывать запросы:
по продукции предприятия вывести все данные о наличии за определенный год;
по указанному году вывести количество групп по списку;
формировать отчеты, генерировать полученный отчет в документы Word, Excel.
Требования по производительности
Время ответа на запрос не более 5 секунд при работе в локальной сети.
Требования по интерфейсу
Тип операционной системы - Windows 7 и выше.
Тип приложения - обычное приложение Windows, взаимодействующее с приложениями Microsoft Office.
Форматы файлов для хранения данных имеют расширение *.gdb.
Формат выходных файлов - *.pas;
Операционные требования
Диалог с пользователем должен осуществляться на русском языке.
Разрабатываемое программное обеспечение должно иметь графический интерфейс.
Разрабатываемое программное обеспечение должно выдавать сообщать об ошибках, при неправильных действий оператора и при некорректных входных данных.
Разрабатываемое программное обеспечение должно быть рассчитано на пользователя со знаниями работы в ОС Windows [26, 10].
Требования по ресурсам
ПО должно:
быть совместимо с ОС Windows 7/ 8/ 10,
занимать физический объем памяти не более 10 Мб,
центральный процессор - Celeron 850MHz.
Требования по верификации
Верификация и валидация программного обеспечения должна проводиться в соответствии с планом верификации и валидации ПО.
Требования по испытаниям
Приемосдаточные испытания должны проводиться в присутствии заказчика и тестироваться в следующем порядке:
тест на добавление данных;
тест на удаление данных;
тест на просмотр данных;
тест на изменение данных;
тест на корректный и некорректный ввод данных;
тест на разграничение уровней доступа.
Требования по документации
Разрабатываемое программное обеспечение должно сопровождаться документацией:
инструкцией пользователя;
пояснительной запиской;
плакаты;
техническим заданием;
демонстрационный ролик;
диск с программной системой, документацией и презентационным роликом
Требования по защите
В разрабатываемом программном обеспечении должно быть реализовано два уровня доступа (чтение-запись, чтение) с помощью пароля.
Требования по переносимости
Эксплуатация ПО должна быть возможна на х86-совместимых процессорах (не ниже К586), на ОС Windows 7/8/10.
Требования по качеству
Контроль качественных характеристик должен осуществляться на этапе тестирования.
Требования по надежности
Надежность разрабатываемого программного обеспечения будет обеспечиватся обработкой входных данных на корректность ввода и обработка исключительных операций, выводом сообщения с предупреждением.
Требования по техническому обслуживанию
При выявлении ошибок, разработчик должен их устранить в теченнии недели.
Новые версии программного обеспечения будут поставляться по мере их возникновения в течение 2 недель за дополнительную плату.
Требования по безопасности
Для уменьшения риска потери данных, данные должны храниться в файлах с расширением *.gdb, которые будут ежедневно копироваться на устройство хранения данных.
Помещение, в котором установлен компьютер с установленным ПО, должно соответствовать санитарно-техническим нормам по эксплуатации вычислительной техники.
1.5 Стадии и этапы разработки
|
Стадии разработки |
Этапы работ |
Содержания работ |
Отчетность работ |
Сроки |
|
|
1. Техническое задание |
Обоснование необходимости разработки программы |
постановка задачи; сбор исходных материалов. |
10.04.2016 -12.04.2016 |
||
|
Научно-исслед. Работы |
- определение структуры входных и выходных данных; - предварительный выбор методов решения задач; обоснование целесообразности применения ранее разработанных программ; определение требований к техническим средствам. |
Документация по требованиям к техническим средствам |
13.04.2016 -17.04.2016 |
||
|
Разработка и утверждение технического задания |
определение требований к программе; определение стадий, этапов, сроков разработки программы и документации на нее; выбор языков программирования. |
Документация о выборе среды программирования и требованиям к программе |
18.04-2016 -21.04.2016 |
||
|
2. Эскизный проект |
Разработка эскизного проекта |
предварительная разработка структуры входных и выходных данных; разработка общего описания алгоритма решения задачи. |
Документация по общему алгоритму решения |
23.04.2016 -1.05.2016 |
|
|
Утверждение эскизного проекта |
составление пояснительной записки; согласование и утверждение эскизного проекта. |
Пояснительная записка |
2.05.2016 -6.05.2016 |
||
|
3. Рабочий проект |
Разработка программы |
программирование и отладка программы |
Листинг |
7.05.2016 -9.05.2016 |
|
|
Разработка программной документации |
разработка программных документов в соответствии с требованиями стандартов |
Программная документация |
10.05.2016 -12.05.2016 |
||
|
Испытания программы |
разработка, согласование и утверждение программы и методики испытаний; корректировка программы и программной документации по результатам испытаний. |
Документация по испытаниям |
14.05.2016 -16.05.2016 |
||
|
4. Внедрение |
Подготовка и передача программы |
подготовка и передача программы и программной документации для сопровождения и изготовления; оформление и утверждение акта о передаче программы на сопровождение и изготовление. |
Акт о передаче программы |
20.06.2016 -24.06.2016 |
1.6 Порядок контроля и приёмки
Все промежуточные результаты согласовываются с руководителем практики.
Порядок передачи программного продукта таков: после тестирования система вместе с инструкцией пользователя передаются предварительно обученному персоналу в опытную эксплуатацию, а через некоторое время после внесения всех поправок система инсталлируется для работы сотрудников из отдела продаж предприятия.
Выводы по разделу 1
Проведен анализ предметной области, изучено состояние проблемы автоматизации учета движения товаров и формирования отчетности на АОЗТ «Новый Стиль Украина». Проведен обзор литературы по вопросам автоматизации учета движения товаров и формирования отчетности на торговых предприятиях. Работа отдела по продажам связана с накоплением большого количества информации о товаре и о потребителях. Традиционно информация храниться на бумажных носителях. При этом трудно осуществить быстрый отбор нужных данных при заказе или отправке товаров, наличие на складах, наименование, или другие положения касающиеся отдела по продажам. Работа, которая там ведется, не менее тяжела, так как предприятие насчитывает несколько тысяч, а то и более численности продукции выпускаемой каждый день. По каждой из продукции необходимо вести оперативную информацию, кроме того, в течение всего года происходят изменения по модификации товара, что соответствующим образом должно быть учтено отделом по продажам.
Поэтому автоматизация даже части работы этого подразделения позволит серьезно уменьшить нагрузку на сотрудников и увеличить производительность предприятия, т.е. тема выпускной работы актуальна.
Учитывая специфику отдельного предприятия, можно утверждать, что на сегодняшний день не существует свободных или свободно распространяемых продуктов, выполняющих данную работу. Коммерческие же программы стоят достаточно дорого, ориентированы на операционные системы компании Microsoft и требуют конфигурации в соответствии с требованиями конкретной организации. Поэтому создание собственного программного обеспечения является обоснованным и наиболее верным решением, так как система создается непосредственно для нужд АОЗТ «Новый Стиль Украина».
2. МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ ДЛЯ АВТОМАТИЗАЦИИ УЧЕТА ДВИЖЕНИЯ ТОВАРОВ И ФОРМИРОВАНИЕ ОТЧЕТНОСТИ
2.1 Методологии и технологии проектирования (CASE - средства)
Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ [27].
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических операций проектирования (рисунок 2.1);
критериев и правил, используемых для оценки результатов выполнения технологических операций;
нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Рисунок 2.1 - Представление технологической операции проектирования
Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям [28]:
технология должна поддерживать полный ЖЦ ПО;
технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в виде систем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям системы. Реализация систем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
технология должна обеспечивать возможность ведения работ по проектированию отдельных систем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных систем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных систем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным системам;
технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта [33];
технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (базами данных (БД), операционных систем, языков и систем программирования) [34];
технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ [27].
Реальное применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие[27]:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов, и т. д.;
требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта и т. д.[27];
механизм обеспечения совместной работы над проектом, в том числе: правила интеграции систем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов ), правила проверки проектных решений на непротиворечивость.
Стандарт оформления проектной документации должен устанавливать:
комплектность, состав и структуру документации на каждой стадии проектирования;
требования к ее оформлению;
правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями [27].
Стандарт интерфейса пользователя должен устанавливать:
правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя.
2.2 Выбор модели базы данных
Поскольку предполагается, что программный продукт должен будет обрабатывать и хранить большой объем данных, то целесообразно хранить эту информацию определенным образом в базах данных. Задача базы данных заключается в хранении всех представляющих для некоторой организации интерес данных в одном месте, к тому же таким образом, который заведомо исключает их избыточность [33, 49, 14]. Хранение множественных копий данных в разных местах предприятия чревато возникновению рассогласований между предположительно идентичными наборами данных. В хорошо спроектированной базе данных исключается избыточность данных, вероятность сохранения противоречивых данных сводится к минимуму. Тогда разрабатываемый программный продукт можно отнести к классу базами данных (БД). Любая БД основывается на определенной модели данных. [33, 49]
Согласно организации хранения данных рассмотрим следующие модели данных:
сетевые;
иерархические;
реляционные;
объектно-ориентированные.
Сетевая модель данных является, в простом понимании, моделью объектов-связей, где допускаются только бинарные связи "многие к одному" [1]. Такое ограничение позволяет использовать для данных простую модель ориентированных графов. В контексте сетевой модели понятие связь является синонимом бинарной связи "многие к одному". Чтобы представить типы записей и их связи, нужно изобразить ориентированный граф, называемый сетью. В БД, поддерживающих сетевую организацию, любая запись, называемая записью старшего уровня, может содержать данные, которые относятся к набору других записей, называемых записями подчиненного уровня [14, 49]. Возможно обращение ко всем записям в наборе, начиная с записи старшего уровня. Недостатком такой модели данных является большое время доступа от основной записи к вспомогательным записям.
Иерархическая модель данных представляет собой сеть, являющуюся совокупностью деревьев. В такой совокупности все связи направлены от потомка к предку. Любая запись может владеть только одним набором записей более низкого уровня и может быть членом только одного такого набора. Во избежание дублирования данных на нижних уровнях иерархии вводится понятие типа виртуальных записей, который представляет собой ссылку на уже существующий в иерархии тип записей. Часто, в литературе, иерархическую модель данных относят к подвиду сетевой модели данных. К недостаткам иерархической модели отнесем возможность доступа к записи, только через записи, тип которых является родительским по отношению к типу требуемой записи.
Дейт дает следующее неформальное определение системе управления реляционными базами данных [1].
вся информация в базе данных представлена в виде таблиц;
она поддерживает три реляционных оператор выбора, проектирования и объединения, с помощью которых вы получаете необходимые вам данные (и можете выполнять эти операции, не требуя от системы физической записи получаемых с их помощью данных в каком-то определенном виде).
Реляционная модель базы данных была первоначально разработана доктором Коддом в начале 1970-х годов [39]. В основе реляционной модели лежит математическое понятие теоретико-множественного отношения, которое представляет собой подмножество декартова произведения списка доменов. Домен - это просто множество значений. Например, множество целых чисел есть домен. Декартовым произведением доменов D1,D2,..,Dk (обозначается как D1D2..Dk) называется множество всех кортежей (v1,v2,..,vk) длины k, таких, что v1 принадлежит D1, v2 принадлежит D2 и т.д. Например, если k=2, D1={0.1} и D2={a, b, c}, то D1D2 есть {(0,a), (0,b), (0,c), (1,a), (1,b), (1,c)}. Отношением называется некоторое подмножество декартова произведения одного или более доменов. Поскольку речь идет о базах данных, нет смысла обсуждать бесконечные отношения. Поэтому мы будем предполагать, если не оговорено противное, что отношение является конечным. Например, {(0,a), (0,c), (1,b)} есть отношение, подмножество определенного выше D1D2. Другим примером отношения может служить пустое множество. Элементы отношения называются кортежами. Удобно представлять отношение как таблицу, где каждая строка есть кортеж и каждый столбец соответствует одному компоненту. Столбцы называются при этом атрибутами, и им обычно присваиваются имена. Список имен атрибутов отношения называется схемой отношения. Если отношение называется REL и его схема имеет атрибуты A1,A2,..,Ak, то такую схему чаще всего будем записывать как REL(A1,A2,..,Ak). Можно заметить аналогию между схемой отношения и форматом записи, между отношением и файлом, а также между кортежем и записью. Совокупность схем отношений, используемых для представления информации, называется схемой (реляционной) базы данных, а текущие значения соответствующих отношений - (реляционной) базой данных. Поскольку многие способы организации файлов зависят от существования ключа записей, реляционный язык определения данных также должен обеспечивать механизм для спецификации одного атрибута или их множества в качестве ключа отношения. Понятие ключа отношения имеет, по существу тот же смысл, что и понятие ключа в контексте файлов или наборов объектов. Предполагается, что отношение не должно иметь двух кортежей, в которых совпадают все атрибуты ключа. Отношения в реляционных моделях данных, связываются друг с другом связями следующих видов: "один к одному", "один ко многим" и "многие ко многим". Правильное проектирование реляционной модели подразумевает использование сжатой информации, которой достаточно для создания и полной структуры базы данных. Такая информация представляет собой концептуальную модель, применение такой модели позволяет определить необходимые данные для хранения в базе данных, свести число хранимых отношений к минимуму, нормализовать отношения для упрощения решения проблем, связанных с обновлением и удалением данных. Метод декомпозиции отношений основан на 4-х нормальных формах отношений и вполне пригоден при условии небольшого количества задействованных атрибутов. На практике применяются в основном только первые 3 нормальные формы [39]. При большом числе атрибутов, функциональных зависимостей метод декомпозиции усложняет процесс формирования концептуальной модели. Для этого можно применить метод "сущность-связь" (ER-диаграммы) [27]. Этот метод отличается от методов декомпозиции тем, что функциональные зависимости привлекаются не на начальном, а на конечном этапе проектирования. В настоящее время эта технология является наиболее распространенной и поддерживается большинством средств разработки.
Объектно-ориентированные модели данных предназначены для хранения сложных неструктурированных данных [11]. В таких моделях данные не разбиваются на элементы, а помещаются в хранилище в виде объектов и методов их описания как единое целое. Объектное описание модели данных строится на принципах объектно-ориентированного программирования (ООП) [11]: на инкапсуляции - комбинирование данных и методов их описания и манипулирования, для получения нового типа данных - объекта; на наследовании - определение объекта и затем использование его для построения иерархии производных объектов, причем каждый производный объект (“потомок”) наследует доступ к данным, методам описания и манипулирования данными всех своих “прародителей”; на полиморфизме - придание методу описания или манипулирования данными одного имени, которое совместно используется объектами всей иерархии, причем каждый объект иерархии реализует этот метод своим собственным, подходящим для него образом. Поскольку ООП - это результат естественной эволюции более ранних методологий, то объектно-ориентированные модели данных более структурированы, более абстрактные и модульные, чем рассмотренные выше модели данных. Не смотря на то, что такие модели данных более близки сущностям реального мира, по причине своей “молодости” они еще мало известны. К недостаткам можно отнести: слабое распространение инструментальных средств, нехватку соответствующей литературы, вследствие чего отсутствие опыта у разработчиков.
Из перечисленных выше моделей данных выберем модель для представления данных предметной области по следующим критериям:
легкость использования;
простота реализации.
На сегодняшний день наиболее легкие в использовании являются реляционные модели данных, поскольку данная технология наиболее распространена и существует развитый аппарат манипулирования данными - реляционная алгебра (поиск, запоминание, выборка и др.). Сетевая модель требует понимания не только типов записей и связей, но и их взаимоотношений. Реализация связей “многие ко многим” и связей над тремя и более наборами объектов осуществляется не просто. Подобным образом иерархическая модель требует понимания использования указателей (типов виртуальных записей) и порождает те же проблемы, что и сетевая, - относительно представления связей более сложных, чем связи “многие к одному” между двумя наборами объектов. При рассмотрении возможностей реализации высокие оценки получают реляционная и объектно-ориентированная модели. Из-за отсутствия опыта построения объектно-ориентированных моделей данных в качестве модели данных для нашей предметной области примем реляционную модель.
2.3 Выбор концептуальной модели данных
Для выбора концептуальной модели данных рассмотрим три их разновидности:
Семантическая модель;
Фреймы;
Модель "сущность-связь".
Семантическая модель основывается на построении семантической сети. Под семантической сетью понимают ориентированный граф, состоящий из помеченных вершин и дуг и задающий объекты и отношения предметной области. Семантические сети обладают рядом достоинств, а именно:
описание объектов предметной области происходит естественным языком;
все записи, поступающие в БД накапливаются в относительно однородной структуре.
Но несмотря на эти преимущества, семантическая модель данных обладает рядом недостатков, один из которых и наиболее существенный, заключается в том, что построение реляционной модели данных на основе семантических сетей затруднено.
Фреймы выражаются структурами данных с привязанными процедурами обработки этих данных. Фреймы могут быть следующих видов: событийные, характеристики, логические предикаты. Использование фреймовой модели также нецелесообразно, поскольку данная модель не отражает типы связей в реляционной модели данных.
Модель "сущность-связь" описывает в терминах сущность, связь, значение. Сущность - понятие, которое может быть идентифицировано. Связь - соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграмма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность - это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя и более сущностями типа "многие ко многим" или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграмма - графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей - ромбом. Связи могут быть трех типов: "один к одному", "один ко многим", "многие ко многим", данные типы связей присущи реляционной модели, как и сущности, которым в реляционной модели соответствуют таблицы [27, 34].
В связи с тем, что модель "сущность-связь" наиболее близка по принципам организации к реляционной модели и реализация последней на основе первой наиболее удобно, то в качестве концептуальной модели выбрана модель "сущность-связь".
2.4 Проектирование модели баз данных
Среди множества целей, стоящих перед проектированием базы данных (БД), следующие представляются наиболее важными [33]:
возможность хранения всех необходимых данных в БД;
исключение избыточности данных;
сведение числа хранимых в БД отношений к минимуму;
нормализация отношений для упрощения решения проблем, связанных с обновлением и удалением данных.
Первым шагом в процессе проектирования БД является определение всех атрибутов, которые будут впоследствии помещены в БД. После чего определяется сколько отношений необходимо и какие атрибуты включать в какие отношения.
Исключение избыточных данных заключается в удалении повторяющейся информации в данных, что способствует повышению производительности системы, уменьшению размера БД [34].
Сведение отношений к минимуму обуславливается тем, что разбиение одного отношения на два или более меньших отношений желательно с точки зрения исключения определенных проблем, например, повышается гибкость модели на случай дальнейшей ее модификации, но это усложняет модель, снижает производительность системы.
Нормализация отношений - представляет собой разбиение одного отношения на два или более в соответствии со специальной методикой разбиения.
Для того, чтобы отношение считалось нормализованным, каждое из его полей должно быть неделимым и не должно содержать никаких повторяющихся групп. Поле считается неделимым, если оно содержит только один элемент данных. Повторяющаяся группа - это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибутов.
Отношение находится в первой нормальной форме, если все кортежи не повторяются. Если некоторые кортежи повторяются, то атрибуты с повторяющимися значениями выделяются в отдельное отношение или устанавливают новый атрибут, который станет первичным ключом для данного отношения [33].
Отношение находится во второй нормальной форме, если все не ключевые атрибуты зависят от первичного ключа. Если есть зависимость каких-нибудь не ключевых атрибутов от части ключа, то следует выделить эти атрибуты в отдельное отношение, сделав первичным ключом нового отношения ту часть первичного ключа, от которой зависят данные атрибуты, и установить связь от нового отношения к старому.
Отношение находится в третьей нормальной форме, если отсутствует взаимосвязь между не ключевыми атрибутами. Выделение в одно отношение атрибутов с одной и той же зависимостью от не ключевого атрибута, использование атрибутов, определяющих зависимость, в качестве первичного ключа нового отношения и установки связи от нового отношения к старому.
Четвертая нормальная форма запрещает хранить независимые атрибуты в одном и том же отношении, когда между этими атрибутами существует связь вида “многие ко многим”.
Рассмотренные выше нормальные формы относятся к методу декомпозиции на основе функциональных зависимостей, который является пригодным при условии небольшого числа задействованных атрибутов. В нашем случае число атрибутов существенно усложняют применение этого метода. Поэтому применим метод “сущность-связь” (entity-relation), который отличается от метода декомпозиции тем, что функциональные зависимости привлекаются не на начальном, а на конечном этапе проектирования. Сущность - некоторый объект, имеющий экземпляры, отличающиеся друг от друга и допускающие однозначную идентификацию (обычно существительное). Связь - соединение между двумя или более сущностями (обычно глагол). Атрибут - свойство сущности, а если он или набор атрибутов используется для идентификации экземпляра сущности, то называется ключом сущности. Важной характеристикой связи между двумя (и более) сущностями является степень связи: “один к одному”, “один ко многим”, ”многие ко многим”. Экземпляры сущности, участвующие в связи, делятся на класс принадлежности: обязательные или необязательные. После построения диаграмм ER-типа, из них получают отношения, анализируя степень связи между сущностями [27, 14].
2.5 Определение информационных потоков для проектирования модели баз данных
Сбор информации о движении товаров и денег - это процесс взаимодействия главы отдела, работника, зам директора и директора, результатом которого является совокупность сведений о заказах предприятий и их возможностях; это достаточно большая и сложная система, выражаемая бесконечным разнообразием состояний, отношений и связей ее функционирующих компонентов. В состав этой системы входят информационные компоненты, средства организации и управления [14].
В динамике этой системы постоянно происходят изменения содержания, объема, направлений и задач информационных потоков. Существенно важными для системы обработки движения товаров и денег являются: информация о предприятии или фирмы, как часто какой фирмой одет закупка товаров и какого именно, их связь и отношение между собой. Потоки информации характеризуют систему в процессе функционирования и преобразования информационного поля, как по форме, так и по объему и содержанию [34, 27, 35].
В общем виде процесс обработки движения товаров и денег можно рассматривать как информационный процесс, протекающий между работником отдела по торговли, зам директором и непосредственно самим директором [16]. На рисунке 2.2 приведена схема «Учета товаров и формирование отчетности». На рисунке 2.3 приведена информация по отделу продаж, на рисунке 2.4 представлена форма отчетности отдела продаж.
На вход рассматриваемого учета товаров и формирование отчетности подается информация о заказе товаров и информация о наличии товаров на складе. Учет товаров и средств выполняют директор отдела и экономисты. Заполнение бумаг: квитанции об оплате, декларации на товар, льготы на продукцию. На выходе получение товара и формирование отчетности о проделанной работе отдела продаж.
Подобные документы
Характеристика предприятия ООО "КСК-Электро". Экономическая сущность задачи автоматизации отдела продаж. Бизнес-концепция проекта, системные и функциональные требования к информационной системе; архитектура прикладных программ; эффективность инвестиций.
дипломная работа [1,7 M], добавлен 20.03.2013Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.
курсовая работа [88,9 K], добавлен 11.04.2010Характеристика ООО "Евросеть", анализ места учета продаж товаров в его деятельности и использования вычислительной техники в учете. Особенности реализации задач автоматизации учета продажи товаров в ООО "Евросеть", оценка ее экономической эффективности.
дипломная работа [1,4 M], добавлен 30.08.2010Анализ решений по автоматизации аптечной деятельности. Разработка автоматизированной системы формирования заказов. Проектирование многопользовательского доступа к данным. Организация сетевой работы. Реализация протокола взаимодействия сервера и клиента.
дипломная работа [623,8 K], добавлен 19.01.2017Автоматизация работы кредитного отдела банка, решений бизнес-процесса выдачи кредитов и карт. Определения методологии и языка IDEF0, программа Dreamweaver. Правильно построенные и действительные документы XML. Создание отчётов с помощью JasperReports.
дипломная работа [1,9 M], добавлен 22.06.2013Сущность учета и его особенности в торговле. Проблемы создания эффективной системы управления предприятием. Две группы СУБД, используемые в системах автоматизации. Применение систем комплексной автоматизации. Методика разработки программы учета продаж.
курсовая работа [447,0 K], добавлен 08.03.2011Создание программного средства для автоматизации процесса управления учетом клиентов. Алгоритмы и модели базы данных; документооборот бизнес-процесса "работа отдела продаж", задачи и функции менеджера. Системные требования, экономическое обоснование.
курсовая работа [1,4 M], добавлен 18.03.2013Анализ существующих решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Сбор и спецификация, анализ, моделирование и аттестация требований. Возможные неисправности и сопровождение информационной системы.
курсовая работа [645,2 K], добавлен 26.05.2015Архитектура "клиент-сервер". Системный анализ базы данных "Газета объявлений", ее инфологическое и физическое проектирование. Программирование на стороне SQL-сервера. Разработка клиентской части в Borland C++ Builder 6.0 и с помощью Web-технологий.
курсовая работа [1,3 M], добавлен 07.07.2013Разработка модели системы тестирования пользователей с применением технологии "клиент-сервер". Требования к программному изделию и документации. SADT диаграмма системы тестирования до и после автоматизации. Настройка SQL-сервера и установка программы.
курсовая работа [1,5 M], добавлен 22.01.2013
