Преподаватель который помогает студентам и школьникам в учёбе.

Проектирование реализации операций бизнес-процесса «Продажи» (Характеристика комплекса задач)

Содержание:

Введение

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

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

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

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

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

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

Управленческий учет – это система:

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

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

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

В данной работе объектом рассмотрения является система учета продаж в ООО «Макситрэйд».

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

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

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

Прежде, чем приступать к автоматизации управленческого учета, руководству компании следует оценить какие методы учета, планирования, контроля и прогнозирования реализованы в настоящее время, ибо ни одна компания не может существовать без осуществления этих функций управления. Здесь возможны следующие варианты:
функции управления реализованы бессистемно, часто основываясь на интуитивном понимании ведения бизнеса компании. В этом случае необходимо сформулировать требования к системе управленческого учета, отвечающие потребностям компании и оценивать информационные системы с точки зрения соответствия этим требованиям.
система управленческого учета построена в соответствии с западными моделями. Основой такой системы является производственный (торговый) план, который является базой для систем учета затрат и калькуляции себестоимости (variablecosting и absorption costing), системы учета, анализа и контроля затрат (standardcost), анализа поведения затрат в зависимости от объема продаж и цен (CVP-analysis) и др.
Основой управленческого учета для коммерческой организации является учет продаж. Без правильно организованного учета продаж практически невозможна деятельность предприятия, так как она протекает условиях полного отсутствия информации о результатах работы организации, что мешает развитию и извлечению прибыли.
В данной работе объектом рассмотрения является система учета продаж в ООО «Макситрэйд».
Проектируемая система не подразумевает радикального изменения технологии ведения учета в ООО «Макситрэйд». Она призвана упростить получение необходимой информации персоналу, упростить ввод исходных данных, повысить достоверность и надежность получаемой информации.
Актуальность работы определена, во-первых, развитием системы учета предприятия в направлении информатизации в целом, во-вторых, с наличием острой необходимости на предприятии в обработке и хранении с каждым годом все более увеличивающегося объема данных, связанных с основным видом деятельности.
Целью данной работы является автоматизация формирования, хранения и обработки отчетности, документов и иных форм, непосредственно, связанных с учетом продаж.

Глава 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1 Характеристика комплекса задач

1.1.1 Выбор комплекса задач автоматизации

Компания ООО «Макситрэйд» предоставляет услуги покупателям по продаже запчастей для автомобилей различных марок.

Деятельность компании ООО «Макситрэйд» на российском рынке автозапчастей насчитывает уже ни один год – компания образована в 1999 году. И все это время с каждым днем персонал компаниистарается все больше вкладывать в развитие бизнеса и во взаимоотношения с партнерами и клиентами. Компания постоянно расширяет спектр оказываемых услуг и каждый раз предлагает что-то новое для своих заказчиков.

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

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

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

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

Рис.1.1Организационно-штатная структура управленияООО «Макситрэйд»

Рассмотрим характеристику основной деятельности отдела продаж компании, представленную в виде схемы на рисунке 1.2.

Рис.1.2Характеристика деятельности отдела продаж

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

Рис.1.3 Декомпозиция деятельности отдела продаж

В соответствии со схемой, основными бизнес-процессом в разрезе деятельности отдела продаж являются:

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

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

Поэтому в качестве автоматизируемого рассмотрим именно этот процесс.

1.2 Характеристика существующих бизнес-процессов

Рассмотрим подробнее процесс учета продаж так, как он происходит на ООО «Макситрэйд» в настоящее время (Рис. 1.4).

Рассматривая деятельность предприятия, делаем вывод, что все процессы отдела продаж, за исключением учета продаж, автоматизированы. Учет продаж до сих пор выполняется вручную, без применения персональных компьютеров.
На фоне остальной автоматизированной деятельности фирмы данное положение дел выглядит анахронизмом, кроме того, в силу затрудненности и трудоемкости получения ежедневных отчетов про продажам, что может приводить к неправильной интерпретации деятельности предприятия и , в конечном итоге, вести к неправильному определению развития предприятия.
Поэтому в качестве автоматизируемого рассмотрим именно этот процесс.
Характеристика существующих бизнес-процессов
Рассмотрим подробнее процесс учета продаж так, как он происходит на ООО «Макситрэйд» в настоящее время (Рис. 1.4).
Рис. 1.4 Характеристика процесса учета продаж
Таким образом, учет продаж заключается в анализе сведений по продажам, поступающих от магазинов, классификации и обобщению их, и составлению итоговых отчетов с указанием экономических показателей продаж. Основными показателями является размер прибыли от реализации продукции, а также количество проданной продукции по товарным позициям.
При учете продаж товаров следующие два момента могут считаться продажей:
факт отгрузки товаров и предъявление покупателю расчетных документов;
факт поступления оплаты от покупателей на счета в учреждения банков.
Этот фактор определяет момент перехода права владения, пользования и распоряжения реализуемых товаров от поставщика к покупателю. В первом случае, как только товары отгружены и покупателю предъявлены на нее расчетные документы, все права собственности переходят на этот товар к покупателю; во втором – до момента оплаты товар является собственностью поставщика.
Момент продажи товаров обусловливает метод определения выручки от продажи: метод начисления («по отгрузке») или кассовый метод («по оплате»).
Метод определения выручки по отгрузке товаров и предъявлению расчетных документов покупателю повсеместно используется в международной практике.
Фактически в ООО «Макситрэйд» при продаже автомобильных запчастей применяется кассовый метод "по оплате", но иногда бывают исключения, и используется метод начисления "по отгрузке".
Под учетом продаж подразумевается организация ведения учета продаваемых объектов, оперативный ввод информации по заключаемым договорам, ведение графиков платежей, учет платежей и взаиморасчетов по договорам и получение соответствующих отчетов.
Учёт продажи продукции – это один из составляющих элементов бухгалтерского учёта предприятия. Продажа, как и любой другой бизнес-процесс, нуждается в управлении.

Рис.1.4 Характеристика процесса учета продаж

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

При учете продаж товаров следующие два момента могут считаться продажей:

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

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

Момент продажи товаров обусловливает метод определения выручки от продажи: метод начисления («по отгрузке») или кассовый метод («по оплате»).

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

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

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

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

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

1. 3 Характеристика документооборота, возникающего при решении задачи

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

ведомость «активность покупателей"
ведомость «продажи
"книга продаж"
ведомость "список должников"
отчет "документы продаж"
ведомость "продажи (по товарам)"
перечень "товарные документы"

Данные документы формируются на основе информации из первичных документов, таких как:

- счет;

накладная;
счет-фактура.

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

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

Схема документооборота в процессе учета продаж представлена на рисунке 1.5.

Рис.1.5 Схема документооборота

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

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

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

Обоснование проектных решений

1.4 Обоснование проектных решений по информационному обеспечению

Информационное обеспечение (ИО) — совокупность единой системы классификации и кодирования информации, унифицированных систем документации и информационных массивов. [12]

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

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

Классификатор — это документ, с помощью которого осуществляется формализованное описание экономической информации в ЭИС, содержащей наименования объектов, наименования классификационных группировок и их кодовые обозначения.[13]

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

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

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

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

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

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

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

К внутримашинному информационному обеспечению относится описание экранных форм.

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

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

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

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

Информационная база (ИБ) — определенным образом организованная совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. [3]

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

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

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

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

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

База данных (БД) — поименованная совокупность данных, отражающая совокупность объектов и их отношений в рассматриваемой предметной области. [3]

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

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

иерархическую;
сетевую;
реляционную модель.

Основными компонентами любой из этих моделей являются файлы (или таблицы).

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

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

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

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

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

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

Клиенты;
Продукция;
Договора;
Продажи;
Менеджеры;
Магазины.

1.5 Обоснование проектных решений по программному обеспечению

Программное обеспечение (ПО) — совокупность программ для реализации целей и задач автоматизированной системы. [2]

ПО делится на два вида: общее (операционные системы, операционные оболочки, компиляторы, интерпретаторы, программные среды для разработки прикладных программ, СУБД, сетевые программы и т.д.) и специальное (совокупность прикладных программ, разработанных для конкретных задач в рамках функциональных подсистем, и контрольные примеры). [2]

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

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

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

В настоящее время наиболее востребованы два типа архитектуры – файл-сервер, клиент-сервер.

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

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

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

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

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

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

Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью.

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

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

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

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

Моделирование данных
Особенности архитектуры и функциональные возможности
Контроль работы системы
Особенности разработки приложений
Производительность
Надежность
Требования к рабочей среде
Смешанные критерии

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

На уровне технических характеристик разнообразие СУБД еще больше, чем на качественном уровне. К техническим характеристикам относятся:

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

Оценка производительности производится методом тестирования с помощью эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and Portable). В них контролируется широкий спектр часто встречающихся операций БД и моделируются однопользовательские и многопользователь-ские среды.

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

В качестве языка разработки клиента подключения к базе данных был выбран язык PHP.

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

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

В процессе выбора языка разработки альтернативой PHP был язык ASP(ActiveServerPages), схожий по структуре но построенный на технологии СОМ. Предпочтение PHP было отдано по следующим характеристикам:
В модулях PHP все запускается в области памяти, выделенной программе операционной системой. ASP загружает для различных действий соответствующие СОМ-модули, чем сильно загружает оперативную память и процессор
Интеграция PHP с выбранной СУБД MySQL значительно более полная, чем у ASP. Существует множество утилит на PHP для работы с базами данных MySQL, где реализуется набор свойств наиболее полный в сравнении с другими базами данных. Есть очень полезные встроенные функции, недоступные для других баз данных.Одним из значительных преимуществ PHP является поддержка широкого круга баз данных: Oracle, Microsoft SQL server, MySQL и другие.
Несомненное достоинство PHP - это отсутствие временных проблем с исправлением внутренних ошибок, что позволяет оперативно реагировать и исправлять недоработки.

Глава 2. ПРОЕКТНАЯ ЧАСТЬ

2.1 Информационное обеспечение задачи

2.1.1 Информационная модель и её описание

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

В качестве информационной модели будем использовать схему данных (ГОСТ 19.701-90). Схема данных состоит из следующих элементов:

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

Весь цикл обработки информации можно разбить на два этапа:

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

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

Рис.2.1Информационная модель системы учета продаж

2.2 Характеристика нормативно-справочной, входной и оперативной информации

В системе используются следующие входные документы:

Договор о поставке;
Договор о продаже;
Прайс-лист;
Заявка.

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

Наименование продукции;
Количество;
Дата поставки;
Реквизиты поставщика.

Документ договор о продаже имеет следующие реквизиты:

Наименование продукции;
Количество;
Дата продаж;
Реквизиты клиента.

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

Наименование
Артикул
Единица измерения
Закупочная цена
Оптовая цена
Розничная цена

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

Наименование клиента;
Наименование продукции;
Количество продукции;
Желаемая дата продажи.

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

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

Таблица 2.1

Перечень используемых справочников

№ пп	название справочника	ответственный за ведение	средний объём справочника в записях	среднюю частоту актуализации	средний объем актуализации, %
	Сотрудники	Администратор	100	1 раз в месяц	10
	Поставщики	Пользователь	50	1 раз в месяц	10
	Клиенты	Пользователь	50	1 раз в месяц	10
	Запчасти	Пользователь	500	1 раз в неделю	25
	Расходные материалы	Пользователь	500	1 раз в неделю	25
	Склады	Пользователь	500	1 раз в неделю	25
	Продукция	Пользователь	500	1 раз в неделю	25

Реквизитный состав справочников приведен в таблице 2.2.

Таблица 2.2

Реквизитный состав справочников

№ пп	Наименование	Перечень реквизитов
1	Сотрудники	Фамилия; Имя; Отчество; Дата рождения Пароль Логин Дата регистрации.
2	Поставщики	Полное наименование Краткое наименование Фактический адрес Юридический адрес Банковские реквизиты; Контактное лицо; Телефон E-mail; Дата регистрации
3	Клиенты	Полное наименование Краткое наименование Фактический адрес Юридический адрес Банковские реквизиты; Контактное лицо; Телефон E-mail; Дата регистрации
4	Запчасти	Наименование Артикул Единица измерения Закупочная цена Оптовая цена Розничная цена Примечание
5	Расходные материалы	Наименование Единица измерения Стоимость Срок хранения Вес нетто Вес брутто Примечание
6	Продукция	Наименование Единица измерения Стоимость Срок хранения Примечание
7	Склады	Наименование склада Краткое наименование склада

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

Описание результатных документов приведено в таблице 2.3.

Таблица 2.3

Описание выходных документов

№ пп	Наименование	Реквизиты	Таблицы, на основе которых формируется	Частота формирования	Способ доставки
1	Список поставщиков	Полное наименование Краткое наименование Фактический адрес Юридический адрес Банковские реквизиты; Контактное лицо; Телефон E-mail;	Поставщики	По запросу	Экранная форма
2	Список клиентов	Полное наименование Краткое наименование Фактический адрес Юридический адрес Банковские реквизиты; Контактное лицо; Телефон E-mail;	Клиенты	По запросу	Экранная форма
3	Перечень заявок на продажу	Рег. Номер Дата Наименование поставщика Наименование продукции Количество Стоимость за ед.измерения Общая стоимость	Поставщики Продукция Расх. Материалы Запчасти	По запросу	Экранная форма
4	Остатки по складу	Рег. Номер Дата Наименование клиента Наименование продукции Количество Стоимость за ед.измерения Общая стоимость	Продажи Клиенты Продукция Расх. Материалы Запчасти	По запросу	Экранная форма
5	Перечень продукции (запчастей, расходных материалов)	Наименование Артикул Единица измерения Закупочная цена Оптовая цена Розничная цена	Продукция Расх. Материалы Запчасти	По запросу	Экранная форма
6	Список заявок	Рег. Номер Дата Наименование клиента Наименование продукции Количество Стоимость за ед.измерения Общая стоимость	Клиенты Продукция Расх. Материалы Запчасти Продажи	По запросу	Экранная форма

Программное обеспечение задачи

2.4 Общие положения (дерево функций и сценарий диалога)

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

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

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

1.базисные (основные).

2.целевые.

3.дополнительные.

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

Целевая функция системы соответствует ее основному функциональному назначению, т.е. целевая (главная) функция – отражает назначение, сущность и смысл существования системы.

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

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

Рис. 2.2 Дерево функций системы для менеджера

Под работой со справочниками подразумевается их заполнение и редактирование (удаление записей).

Сценарии диалога, формирующийся на основе дерева функций, приведен на рис. 2.3.

2.5 Характеристика базы данных

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

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

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

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

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

Рис. 2.4ER-диаграмма базы данных

Назначение таблиц представлено в таблице 2.4.

Таблица 2.4

Назначение таблиц базы данных

№ пп	Наименование	Назначение
	Клиенты	Хранит данные о клиентах
	Продукция	Хранит данные о продукции
	Запчасти	Хранит данные о продаваемых запчастях
	Расходные материалы	Хранит данные о продаваемых расходных материалах
	Склады	Хранит данные о складах
	Сотрудники	Хранит данные о менеджерах по продажам
	Поставки	Хранит данные о поставках на склад
	Продажи	Хранит данные о продажах
	Поставщики	Хранит данные о поставщиках

Описание каждой таблицы базы данных приведено ниже.

Таблица 2.5

Расходные материалы

№	Наименование поля	Идентификатор	Тип	Примечание
	Код	idSf	int(11)	Ключевое, автозаполнение
	Наименованиефасованного товара	namesf	varchar(45)
	Единица измерения	edizmsf	varchar(45)
	Стоимость	prisesf	varchar(45)
	Примечание	primSf	text
	Отметка об удалении	udalSirf	int(1)
	Вес нетто	netto	varchar(255)
	Вес брутто	brutto	varchar(255)

Таблица 2.6

Склады

№	Наименование поля	Идентификатор	Тип	Примечание
	Код склада	idGild	int(11)	Ключевое, автозаполнение
	Полное наименование	nameG	varchar(45)
	Краткое наименование	KrnameG	varchar(45)
	Отметка об удалении	udalG	int(1)

Таблица 2.7

Клиенты

№	Наименование поля	Идентификатор	Тип	Примечание
	Код клиента	idKlient	int(11)	Ключевое, автозаполнение
	Наименование	namekl	varchar(45)
	Краткое наименование	krnamekl	varchar(45)
	Фактический адрес	adresskl	varchar(45)
	Юридический адрес	uradrkl	varchar(45)
	Реквизиты	banrekKl	varchar(45)
	Контактоное лицо	kontlizoKl	varchar(45)
	Телефон	tlfKl	varchar(45)
	Адрес электронной почты	emailKl	varchar(45)
	Дата регистрации	dateregKl	timestamp
	Отметка об удалении	udalKl	int(1)

Таблица 2.8

Поставки

№	Наименование поля	Идентификатор	Тип	Примечание
	Код поставки	idPP	int(11)	Ключевое, автозаполнение
	Дата поставки	datePP	date
	Код поставщика	idpostPP	int(11)
	Код склада	idsirPP	int(11)
	Количество	kolvopp	varchar(45)
	Код товара	idgridPP	int(4)

Таблица 2.9

Продажи

№	Наименование поля	Идентификатор	Тип	Примечание
	Код продажи	idPR	int(11)	Ключевое, автозаполнение
	Дата продажи	datePP	varchar(25)
	Код клиента	idklpr	int(11)
	Код продукции	idprodpr	int(11)
	Количество	kolvopr	varchar(45)
	Код склада	idgildprod	int(5)

Таблица 2.10

Поставщики

№	Наименование поля	Идентификатор	Тип	Примечание
	Код поставщика	idPostav	int(11)	Ключевое, автозаполнение
	Наименование	nameP	varchar(45)
	Краткое наименование	krnameP	varchar(45)
	Фактический адрес	adressP	varchar(45)
	Юридический адрес	uradrP	varchar(45)
	Реквизиты	banrekP	varchar(45)
	Контактное лицо	kontlizoP	varchar(45)
	Телефон	tlfP	varchar(45)
	Адрес электронной почты	emailP	varchar(45)
	Дата регистрации	dateregP	timestamp
	Отметка об удалении	udalP	int(1)

Таблица 2.11

Продукция

№	Наименование поля	Идентификатор	Тип	Примечание
	Код продукции	idprod	int(11)	Ключевое, автозаполнение
	Наименование	nameprod	varchar(45)
	Артикул	art	varchar(45)
	Единица измерения	edizmpr	varchar(45)
	Закупочная стоимость	selfst	varchar(45)
	Оптовая стоимость	optst	varchar(45)
	Розничная стоимость	rozst	varchar(45)
	Примечание	primP	text
	Отметка об удалении	udalPr	int(1)
	Срок хранения	srokprod	varchar(255)

Таблица 2.12

Запчасти

№	Наименование поля	Идентификатор	Тип	Примечание
	Код сырья	idS	int(11)	Ключевое, автозаполнение
	Наименование	names	varchar(45)
	Единица измерения	edizms	varchar(45)
	Стоимость	prises	varchar(45)
	Примечание	primS	text
	Отметка об удалении	udalSir	int(1)

Таблица 2.13

Сотрудники

№	Наименование поля	Идентификатор	Тип	Примечание
	Код сотрудника	idsotr	int(11)	Ключевое, автозаполнение
	Фамилия	name	varchar(45)
	Логин	login	varchar(45)
	Пароль	parol	varchar(45)
	Дата регистрации	dates	varchar(45)
	Имя и отчество	surname	varchar(45)
	Дата рождения	datebor	varchar(45)
	Отметка об удалении	udal	int(1)

2.6 Структурная схема пакета (дерево вызова программных модулей)

Структурная схема пакета программных модулей представлена на рисунке 2.5.

Рис.2.5 Схема вызова программных модулей

Описание программных модулей представлено в таблице 2.14.

Таблица 2.14

Описание программных модулей

№ п/п	Наименование модуля	Функции модуля
	Продажи	Совокупность алгоритмов, выполняющих учет продаж – основную функцию системы
	Клиенты	Учет клиентов
	Отчеты	Позволяет получить отчеты по продажам, клиентам, а также товару
	Справочники	Данный модуль позволят осуществлять управление работой системы через управление содержимым справочников
	Авторизация	Обеспечивает допуск сотрудников для работы с системой в соответствии с заранее определенными авторизационными данными

2.7 Описание программных модулей

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

Продажи;
Сотрудники;
Клиенты;
Расходные материалы;
Запчасти;
Продукция.

Блок-схема работы данного модуля приведена на рис. 2.6.

Рис.2.6 Блок-схема модуля авторизации

Контрольный пример реализации проекта и его описание

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

Рис.2.7Справочник Поставщики

Рис.2.8Справочник Продукция

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

После ввода данных при успешном завершении система выдает сообщение об этом.Далее, при осуществлении продаж, необходимо заполнить данные о клиенте (Рис. 2.9):

Рис.2.9 Добавление данных о клиенте

После этого производится учет продажи:

Рис.2.10 Форма учета продаж

На странице с отчетами можно получить список продаж (Рис. 2.11), на основе которого формируется накладная на продажу (Рис. 2.12).

Рис.2.11 Список продаж

Рис.2.12Накладная на продажу

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

Рис.2.13 Список поступлений продукции

Листинг программных модулей приведен в Приложении.

Заключение

Курсовой проект ставил целью разработать информационную систему учета продаж в организации ООО «Макситрэйд».

Созданная система автоматизирует следующие функции:

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

Курсовой проект состоит из двух частей.

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем. Издание официальное. - М., 1999
Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. ГОСТ 19.701-90 (ИСО 5807-85) / Государственный комитет СССР по управлению качеством продукции и стандартам, 01.01.1992.
Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие, М.: Гелиос АРВ, 2012. - 368 с., ил
Астелс, Дэвид; Миллер Гранвилл; Новак, Мирослав, Практическое руководство по экстремальному программированию, Пер. с англ. - М.: Издательский дом "Вильямс", 2013. - 320 с.: ил. - Парал. тит. англ
Баженова И. Ю. , Основы проектирования приложений баз данных, Издательства: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2013 г., , 328 стр.
Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2012 г, 456 стр.
Вигерс Карл, Разработка требований к программному обеспечению, Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2013. -576с.: ил
Гашков С. Б., Э. А. Применко, М. А. Черепнев Криптографические методы защиты информации, М, Издательство: Академия, 2015 г., 304 стр.
Гвоздева Т. В., Б. А. Баллод, Проектирование информационных систем, М, Издательство: Феникс, 2014 г., 512 стр.
Голицына О. Л., И. И. Попов, Н. В. Максимов, Т. Л. Партыка, Информационные технологии, М, Издательство Инфра-М, 2014 г., 608 стр.
Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2012. 450 – 490 с.
Дэвид Флэнаган. JavaScript. Подробное руководство: Учебник – М.: Символ Плюс, 2013. 243 – 249 с.
Емельянова Н. З., Партыка Т. Л., И. И. Попов, Проектирование информационных систем, М, Издательство: Форум, 2014 г., 432 стр.
Емельянова Н. З., Т. Л. Партыка, И. И. Попов, М, Издательство Форум, 2012 г., , 416 стр.
Илюшечкин В. М. , Основы использования и проектирования баз данных, М, Издательство Юрайт, 2015 г., 224 стр.
Котляров В. П., Т. В. Коликова, Основы тестирования программного обеспечения, Издательства: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2014 г., 288 стр.
Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2012, 289 стр.
Кузин А. В., С. В. Левонисова, Базы данных, М, Издательство: Академия, 2013 г., 320 стр.
Кузнецов С. Д., Основы баз данных, М, Издательства: Бином. Лаборатория знаний, Интернет-университет информационных технологий, 2012 г., 488 стр.
Молчанов А. Ю., Системное программное обеспечение, М, Издательство: Питер, 2015 г., 400 стр.
Незнанов А. А., Программирование и алгоритмизация, М, Издательство: Академия, 2015 г., 304 стр.
Пирогов В. Ю., Информационные системы и базы данных. М, Организация и проектирование, Издательство: БХВ-Петербург, 2014 г.528 стр.
Предметно-ориентированные экономические информационные системы, М, Издательство: Финансы и статистика, 2012 г., 224 стр.
Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2014 – 400с.:ил;
Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2013, 250с., ил.;
Чипига А. Ф., Информационная безопасность автоматизированных систем, М, Издательство: Гелиос АРВ, 2015 г., 336 стр.