Она должна предоставлять следующие возможности:
Оперативного учета. В системе должен быть реализована работа в оперативном режиме, то есть регистрация операций продаж в реальном масштабе времени. Входная информация – список товаров, которые хочет приобрести покупатель. Выходная информация – список действительно проданных товаров и его стоимость. Результат – чек.
Работы с прайс-листом. Пользователь – менеджер по продажам, должен имеет возможность формировать и корректировать наборы товаров для обсуждения их с клиентом. Входная информация – список товаров, которые хочет приобрести покупатель. Выходная информация - откорректированный список товаров и его стоимость. Результат - счет клиента.
Работы со счетами клиентов. Пользователь – руководитель отдела продаж (или ответственное лицо) должен иметь возможность представить счета к исполнению или внести коррективы. Должны быть предусмотрены аналитические функции для получения ясной детализированной оперативной информации о торговой деятельности предприятия в разрезе счетов. Пользователь – руководитель торговой деятельностью. Входная информация – список счетов, выходная информация – выполненные счета, информация о должниках и текущих задолженностях.
Формирования плана закупок. Пользователь – менеджер по закупкам должен иметь возможность дополнять или корректировать его для формирования окончательного плана закупок. Входная информация – список счетов. Выходная информация – план закупок.
Для складского учета. Пользователь – работник склада. Должна быть реализована возможность регистрации поступления товаров на склад по системе заказов и вне ее, регистрация ухода товаров со склада. Должны быть аналитические функции для учета торговой деятельности в разрезе товаров. Входная информация – список поставок и счетов на выполнение. Выходная информация – текущее состояние склада и динамика движения товаров.
Регистрации фактов оплаты по счетам. Работа с банком. Пользователь – бухгалтер. Входная информация – платежные извещения. Выходная информация – список оплаченных счетов.
Система должна обеспечивать высокий уровень надежности при хранении и обработке информации. Это необходимое требование для любой операции на каждом из этапов функционировании автоматизированной системы управления, ведь важна не только сохранность информации, но и ее целостность, структура. И если ответственность за сохранность лежит большей частью на аппаратном комплексе и системе управления базами данных, то обеспечение целостности информации лежит целиком на автоматизированной системе. Необходимо исключить повреждение структуры данных в результате работы человеческого фактора или нарушении логики работы системы.
1.5.4 Требования к аппаратным средствам
Требования к аппаратному обеспечению автоматизированной системы управления торговой деятельностью предприятия вытекают из текущего состояния технической оснащенности предприятий, поэтому, на сегодняшний день, эти требования не должны быть очень высокими. Минимальные требования к компьютеру для работы с автоматизированной системой – IntelPentiumI 200MHz, 32Mb ОЗУ. Обязательным условием является наличие локальной сети Ethernet спецификации IEEE 802.3(10 Мбит/с) или выше и оборудования для обеспечения ее функционирования. Требования к топологии сети отсутствуют.
1.5.5 Требования к информационно-программной совместимости
Требования к программной совместимости: возможность внедрения на платформе Windows 2000 Server; поддержка работы с СУБД Oracle 8i; возможность подключения автоматизированной системы управления торговой деятельностью предприятия как модуля для любой ERP-системы;
В процессе эксплуатации программного продукта, зачастую возникают задачи, которые невозможно решить внутренними средствами. Интеграция средств сторонних разработчиков для решения этих задач приводит к значительному увеличению цены разработки. Поэтому автоматизированная система должна иметь интерфейсы для обмена информацией с наиболее распространенными приложениями для хранения и обработки информации: MSWord, MSExcel. Должна быть реализована поддержка программных средств сторонних производителей: FastReport, ExcelReport.
1.5.6 Требования к программной документации
Техническая документация должна отражать логику работы системы на уровне отдельных модулей. То есть необходимо наличие спецификаций для каждого функционального модуля системы. Руководство пользователя должно описывать работу с графическим интерфейсом программы и основные этапы работы с ним для решения отдельных типовых задач из общего функционала системы. Справочная система – минимальна, и вот почему: она может быть создана только после внедрения программного продукта, то есть моменты отраженные в ней не должны привязываться к конкретной задаче. Таким образом, разработка справочной системы должна быть подготовлена на этапе внедрения.
Глава 2. Проектирование автоматизированной системы торговой деятельности
2.1 Принципиальное проектное решение
В качестве автоматизированной системы управления торговой деятельностью предприятия предлагается использовать многопользовательское клиент-серверное приложение(двухуровневая архитектура), разработанное с помощью интегрированной среды BorlandDelphi 7 EnterpriseEdition. В качестве системы управления базами данных предполагается использование продукта Oracle 8iEnterprise, на базе которого будет развернута комбинированная OLAP\OLTP информационная система, где OLAP-компонента(OnlineAnalyticalProcess) – обеспечит аналитические функции работы системы(небольшое число запросов, время отклика некритично)
OLTP-компонента (OnlineTransactionProcess) – обеспечит функции оперативного доступа большого числа клиентов(большое число запросов, минимальное время отклика)
Информационная система будет развернута на основе операционной системы Windows 2000 Server платформы Intel. Аппаратная часть: сервер - минимальные требования к конфигурации IntelPentium-3 450 MHz, 128 Mb ОЗУ. Рекомендуемая конфигурация - IntelPentium-4 2,4 GHz, 512 Mb ОЗУ. В качестве операционной системы клиентской части предполагается использовать Windows 98 и выше, поэтому требования к аппаратному обеспечению таковы: минимальные – IntelPentium-2MMX 200MHz, 32Mb ОЗУ. Рекомендуемые - IntelPentium-3 450 MHz, 128 Mb ОЗУ.
2.1.1 Выбор архитектуры программного обеспечения
Не секрет, что правильная и четкая организация информационных бизнес -решений является слагающим фактором успеха любой компании. Особенно важным этот фактор является для предприятий крупного бизнеса, которым необходима система, которая способна предоставить весь объем бизнес - логики для решения задач компании. В то же время, такие системы для компаний с крупными сетями часто попадают под критерий “цена - качество”, то есть должны обладать максимальной производительностью и надежностью при доступной цене. Информационная система управления, описанная в этой работе, является приложением клиент-серверной архитектуры, что проиллюстрировано на рисунке 1:
Рис.1 Архитектура информационной системы
Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого выступает Oracle. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть может быть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает недостатками, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе. Поэтому я решила отступить от классического варианта “толстого” клиента и постарался максимально переместить бизнес-логику на сервер, тем самым снизив требования к аппаратному обеспечению клиента и пропускной способности сети. Логика работы системы реализована в виде пакетов хранимых процедур, каждый из вместе с триггерами таблиц которых реализует функционал одного из модулей системы. Таким образом на клиентскую машину будут передаваться не данные для обработки, а обработанные данные.
2.1.2 Выбор программной среды для создания информационной системы
Несмотря на наличие большого количества языков и программных сред для разработки приложений, для реализации нашей задачи, в силу ее специфики, наиболее подходящими я считаю следующие:
Oracle Developer.
Borland Delphi 5-8.
Borland C++ Builder 4-6
Microsoft Visual Studio 6.0
Microsoft Visual Studio .Net
При разработке информационной системы с использованием СУБД Oracle, было бы вполне логично остановиться на первом – “родном” варианте этой компании. В пользу этого варианта говорит и то, что в пакете представлены профессиональные CASE-средства для моделирования и анализа бизнес-процессов(OracleDesigner) с последующей генерацией скриптов для создания базы данных и автоматического формирования макета приложения в соответствии с моделью автоматизированной системы(OracleForms), наличие средств генерации отчетов(OracleReports) и работы с графикой(OracleGraphics). Однако, при более детальном изучении этих продуктов становиться ясно, что их использование приведет, во-первых к жесткой привязке программного продукта к политике лицензирования компании Oracle(что на деле выливается в значительные финансовые вложения), а, во-вторых, поскольку это средства с закрытым программным кодом, к уменьшению гибкости приложения. Встает проблема информационной совместимости с другими программными продуктами. Переход компании Oracle к ориентации на средства Java-разработки для приложений работающих в гетерогенных средах, вылился в отказ от поддержки и развития этого пакета. Становится ясно, что этот продукт не подходит для разработки нашей информационной системы.