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

Содержание

[1]
Глава 3 Оценка эффективности проекта

[1.1] 3.1 Расчет себестоимости информационной системы

[1.2] 3.2 Оценка экономической эффективности внедрения системы

[1.3] 3.3 Основные экономические показатели

Введение

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

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

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

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

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

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

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

Для достижения данной цели необходимо решить следующие задачи:

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

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

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

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

Глава 1 Анализ предметной области

1.1 Основные понятия и постановка задачи

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

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

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

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

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

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

1.2 Обзор облачных сервисов

Исходя из понятия облачных технологий, сравнение следует проводить исходя из критериев объёма, расширяемости и стоимости эксплуатации оплаченного облака. Для обзора были взяты облачные сервисы Dropbox, Google Drive, облако Mail.ru и MEGA.[3]

Таблица 1.1 Сравнение облачных сервисов

	Dropbox	Google Drive	Mail.ru	MEGA
Бесплатный объем предоставляемой памяти	2 Гб	15 Гб	100 Гб	50 Гб
Расширяемость	+	+	-	+
Средний тарифный план расширения облачного хранилища	120 долларов в год за 100 Гб	300 рублей в год за 10 Гб	-	100 евро в год за 500 Гб
Наличие облачной папки на компьютере	+	+	-	-
Дополнительные возможности	Просмотр большинства документов прямо в облаке	Просмотр большинства документов прямо в облаке, связан с аккаунтом Google	-	Шифрование данных

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

1.3 Выбор системы управления базами данных

Версия системы управления базами данных Access входит в состав пакета Microsoft Office, а также доступна как самостоятельный продукт. В состав Access входят:

Средства манипуляции данными Access.
Средства создания форм, отчетов и приложений, при этом отчеты могут быть экспортированы в формат Microsoft Word или Microsoft Excel, а для создания приложений используется Visual Basic for Applications, общий для всех составных частей Microsoft Office.
Средства публикации отчетов и формирования запросов.

СУБД Access входит в профессиональную версию офисной системы Microsoft Office и предназначена для разработки простых диалоговых информационных систем, она использует реляционную модель данных и графический интерфейс Windows.

К достоинствам СУБД ACCESS относится:

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

Из недостатков можно отметить недостаточно высокую эффективность при работе с большими объемами данных.[8]

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

1.4 Выбор платформы разработки

Embarcadero Delphi XE5 – интегрированная среда разработки ПО для Microsoft Windows на языке Delphi (ранее носившем название Object Pascal), созданная первоначально фирмой Borland и на данный момент принадлежащая и разрабатываемая Embarcadero Technologies. Embarcadero Delphi является частью пакета Embarcadero RAD Studio и поставляется в четырёх редакциях: Starter, Professional, Enterprise и Architect. [9]

Язык Delphi имеет широкий спектр средств для взаимодействия с базами данных, в том числе на технологии клиент-сервер, с возможностью подключения дополнительных библиотек. В версии начиная с XE5 включён набор компонентов FireDAC для универсального доступа к базам данных.

Входящая в состав Delphi XE5 платформа Firemonkey предназначена для разработки визуально привлекательных приложений, использующая возможности графического процессора. Используя эту платформу можно разрабатывать приложения сразу для Mac OS X, Win32, Win64 и iOS. Поздние версии Delphi также поддерживают Multi-Device Application, что значительно повышает кроссплатформенность разрабатываемых приложений.

Также в этой среде разработки имеется библиотека REST Client Library которая предоставляет прикладной интерфейс для сервисов Google, Dropbox, Facebook, Вконтакте и других подобных.

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

Глава 2 Проектирование системы

2.1 Определение требований к разрабатываемой системе

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

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

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

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

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

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

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

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

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

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

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

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

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

К первой группе относятся следующие атрибуты качества:

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

Ко второй группе относятся следующие атрибуты качества:

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

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

Функциональные:

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

Нефункциональные:

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

2.2 Модель вариантов использования

Основное действие пользователя при работе с проектируемой системой – редактирование данных. Пользователь будет вносить, изменять и удалять данные о клиентах, заказах, товарах. Диаграмма вариантов использования показывает, как будет проходить работа с программой. Диаграммы ВИ применяются при бизнес-анализе для моделирования видов работ, выполняемых организацией, и для моделирования функциональных требований к ПС при ее проектировании и разработке. Построение модели требований при необходимости дополняется их текстовым описанием.[5]

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.2.1 Модель вариантов использования

2.3 Модель предметной области

Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте информационной системы предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, в общем виде предметная область – это те объекты, действия или явления, с которыми работает ИС.[6]

Информационные системы – это программы для накопления и обработки информации. Банк данных – это система специальным образом организованных данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования. [7]

Требования, предъявляемые к базам данных:

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

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

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

Для построения диаграммы сущность связь принято использовать ряд правил [8]:

Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей является обязательным, то требуется всего одно отношение, объединяющее эти сущности. При этом ключом этого отношения может быть ключ любой сущности.
Если степень бинарной связи 1:1 и класс принадлежности одной сущности является обязательным, а другой сущности – необязательным, то необходимо формировать два отношения: по одному для каждой сущности, причем ключ сущности с необязательным классом принадлежности добавляется в качестве атрибута в другое отношение.
Если степень бинарной связи 1:1 и классы принадлежности обеих сущностей являются необязательными, то требуются три отношения: по одному для каждой сущности с соответствующими ключами и одно, выражающее связь и содержащее только ключи из каждой сущности.
Если степень бинарной связи 1:m и класс принадлежности многосвязной сущности является обязательным, то достаточно формировать два отношения: по одному для каждой сущности с соответствующими ключами, при этом ключ односвязной сущности должен быть добавлен в качестве атрибута в отношение для многосвязной сущности.
Если степень бинарной связи 1:m и класс принадлежности многосвязной сущности является необязательным, то необходимо формировать три отношения: по одному для каждой сущности с соответствующими ключами, и одно для связи аналогично третьему правилу.
Если степень бинарной связи m:n, то необходимо формирование трех отношений: по одному для каждой сущности с соответствующими ключами и одного для связи аналогично третьему правилу.
В случае трех и более сторонней связи необходимо формировать по одному отношению для каждой сущности и одно отношение, выражающее связь и содержащее только ключи каждой сущности. Ключ этого отношения выбирается также как в шестом правиле.

Основываясь на требованиях к системе и модели вариантов использования, была построена модель сущность-связь:

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

Рис 2.2. Диаграмма сущность-связь

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

Рис.2.3 Диаграмма базы данных

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

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

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

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

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

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

Рис 2.4 Главное окно программы

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

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

Рис 2.5 Пример справочника

Одной из ключевых функций данной системы является резервное копирование базы данных с взятым за основу облачным сервисом Google Drive.

Рис 2.6 Процесс настройки и синхронизации

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

В программе также предусмотрено создание различных отчетов, таких как отчет по видам товаров, по сделкам за период времени и по заказам клиентов.

Рис 2.7 Пример отчета

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

Глава 3 Оценка эффективности проекта