47016 (588462), страница 3
Текст из файла (страница 3)
1.5 Постановка задачи на разработку автоматизированной системы
1.5.1 Назначение
Автоматизированная система управления торговой деятельностью предприятия предназначена для упрощения ведения торгово-хозяйственной деятельности российского предприятия крупного бизнеса, обеспечивая при этом поддержку мультивалютных расчетов. Номенклатура товаров и услуг – ограничена только масштабами предприятия. Система предназначена как для оперативного, так и для текущего учета. Одна из основных функций – анализ и обработка накопленной информации для принятия конкурентоспособной политики развития.
1.5.2 Функциональные требования
Автоматизированная система управления должна быть ориентирована на работу следующих категорий пользователей: продавцов, менеджеров по продажам, менеджеров по закупкам, руководителей отделов продаж, руководителей торговой деятельности, сотрудников склада и бухгалтеров.
Она должна предоставлять следующие возможности:
Оперативного учета. В системе должен быть реализована работа в оперативном режиме, то есть регистрация операций продаж в реальном масштабе времени. Входная информация – список товаров, которые хочет приобрести покупатель. Выходная информация – список действительно проданных товаров и его стоимость. Результат – чек.
Работы с прайс-листом. Пользователь – менеджер по продажам, должен имеет возможность формировать и корректировать наборы товаров для обсуждения их с клиентом. Входная информация – список товаров, которые хочет приобрести покупатель. Выходная информация - откорректированный список товаров и его стоимость. Результат - счет клиента.
Работы со счетами клиентов. Пользователь – руководитель отдела продаж (или ответственное лицо) должен иметь возможность представить счета к исполнению или внести коррективы. Должны быть предусмотрены аналитические функции для получения ясной детализированной оперативной информации о торговой деятельности предприятия в разрезе счетов. Пользователь – руководитель торговой деятельностью. Входная информация – список счетов, выходная информация – выполненные счета, информация о должниках и текущих задолженностях.
Формирования плана закупок. Пользователь – менеджер по закупкам должен иметь возможность дополнять или корректировать его для формирования окончательного плана закупок. Входная информация – список счетов. Выходная информация – план закупок.
Для складского учета. Пользователь – работник склада. Должна быть реализована возможность регистрации поступления товаров на склад по системе заказов и вне ее, регистрация ухода товаров со склада. Должны быть аналитические функции для учета торговой деятельности в разрезе товаров. Входная информация – список поставок и счетов на выполнение. Выходная информация – текущее состояние склада и динамика движения товаров.
Регистрации фактов оплаты по счетам. Работа с банком. Пользователь – бухгалтер. Входная информация – платежные извещения. Выходная информация – список оплаченных счетов.
1.5.3 Требования к надежности
Система должна обеспечивать высокий уровень надежности при хранении и обработке информации. Это необходимое требование для любой операции на каждом из этапов функционировании автоматизированной системы управления, ведь важна не только сохранность информации, но и ее целостность, структура. И если ответственность за сохранность лежит большей частью на аппаратном комплексе и системе управления базами данных, то обеспечение целостности информации лежит целиком на автоматизированной системе. Необходимо исключить повреждение структуры данных в результате работы человеческого фактора или нарушении логики работы системы.
1.5.4 Требования к аппаратным средствам
Требования к аппаратному обеспечению автоматизированной системы управления торговой деятельностью предприятия вытекают из текущего состояния технической оснащенности предприятий, поэтому, на сегодняшний день, эти требования не должны быть очень высокими. Минимальные требования к компьютеру для работы с автоматизированной системой – Intel Pentium I 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 Принципиальное проектное решение
В качестве автоматизированной системы управления торговой деятельностью предприятия предлагается использовать многопользовательское клиент-серверное приложение(двухуровневая архитектура), разработанное с помощью интегрированной среды Borland Delphi 7 Enterprise Edition. В качестве системы управления базами данных предполагается использование продукта Oracle 8i Enterprise, на базе которого будет развернута комбинированная OLAP\OLTP информационная система, где OLAP-компонента(Online Analytical Process) – обеспечит аналитические функции работы системы(небольшое число запросов, время отклика некритично)
OLTP-компонента (Online Transaction Process) – обеспечит функции оперативного доступа большого числа клиентов(большое число запросов, минимальное время отклика)
Информационная система будет развернута на основе операционной системы Windows 2000 Server платформы Intel. Аппаратная часть: сервер - минимальные требования к конфигурации Intel Pentium-3 450 MHz, 128 Mb ОЗУ. Рекомендуемая конфигурация - Intel Pentium-4 2,4 GHz, 512 Mb ОЗУ. В качестве операционной системы клиентской части предполагается использовать Windows 98 и выше, поэтому требования к аппаратному обеспечению таковы: минимальные – Intel Pentium-2MMX 200MHz, 32Mb ОЗУ. Рекомендуемые - Intel Pentium-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-средства для моделирования и анализа бизнес-процессов(Oracle Designer) с последующей генерацией скриптов для создания базы данных и автоматического формирования макета приложения в соответствии с моделью автоматизированной системы(Oracle Forms), наличие средств генерации отчетов(Oracle Reports) и работы с графикой(Oracle Graphics). Однако, при более детальном изучении этих продуктов становиться ясно, что их использование приведет, во-первых к жесткой привязке программного продукта к политике лицензирования компании Oracle(что на деле выливается в значительные финансовые вложения), а, во-вторых, поскольку это средства с закрытым программным кодом, к уменьшению гибкости приложения. Встает проблема информационной совместимости с другими программными продуктами. Переход компании Oracle к ориентации на средства Java-разработки для приложений работающих в гетерогенных средах, вылился в отказ от поддержки и развития этого пакета. Становится ясно, что этот продукт не подходит для разработки нашей информационной системы.
Borland Delphi 8 for .Net Architect Edition и Microsoft Visual Studio .Net я решила не использовать из-за их сильной ориентации на платформу .NET. Хотя они и позволяют разрабатывать обычные приложения с использованием библиотек WinForms и VCL, для нашей задачи они сильно перегружены средствами для этой платформы.
Я остановила свой выбор на среде Delphi 7 Enterprise Edition. И вот почему:
Ориентация на разработку Win32-приложений
Самые развитые(на мой взгляд) средства для разработки приложений баз данных
Наличие 4 альтернативных интерфейсов работы с СУБД Oracle: ODBC, ODAC, DOA, CLI.
Компонентная технология и необычайно быстрый компилятор [8]
Открытый код и, как следствие, возможность гибкого использования объектно-ориентированного подхода.
2.1.3 Выбор системы управления базами данных
В предыдущих пунктах часто упоминалось, что основным инструментом для полного контроля над данными будет выступать СУБД Oracle 8i. Стоит отметить, что по экспертным оценкам собственные разработки автоматизированных систем управления в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД. Я остановилась на этом решении по следующим соображениям:
На первом месте конечно же стоят требования к объемам данных с которыми предстоит работать. Поскольку речь идет о масштабируемой системе управления предприятием крупного бизнеса, то, очевидно, что только документооборот предполагает обработку миллионов записей ежегодно. Для примера, размер корпоративной информационной системы Омского нефтеперерабатывающего завода в год увеличивается на миллионы записей. Сервер Oracle 8i, традиционно ориентирован на работу с очень большими объемами информации [7]. MSSQLServer 2000, Interbase-Firebird-Yaffil, mySQL не предназначены для работы с такими информационными массивами.
Необходимость обеспечения многопользовательского режима работы с развитой системой транзакционной обработки, что обеспечивает многочисленным пользователям возможность работы с базой данных, не мешая друг другу. Это особенно важно для реализации возможности оперативного доступа к информации, что вышеперечисленные СУБД хотя и могут реализовать, но только для достаточно ограниченного числа пользователей.
Надежность. Сервер Oracle 8i считается одним из самых отказоустойчивых систем на сегодняшний день. В совокупности с правильным выбором аппаратного обеспечения он способен обеспечить бесперебойную работу на длительный срок, а очень развитая система журналирования и восстановления информации делают его идеальным средством для решения нашей задачи.
2.2 Структурный анализ точек функциональности
Здесь немного про RAD.
Для проведения структурного анализа, построим диаграммы потоков данных:
Контекстная диаграмма – отражает связи информационной системы с внешними сущностями.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
