---

Страницы:   1   2   3   4   5

---

Глава 2. Теоретическая часть

2.1. Обзор программ учета взаимоотношений клиентов с магазином

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

Вторым рассматриваемым программным продуктом рассмотрим АРМ оператора «Astrerisk». Данная программа более совершенная и подходящая нуждам онлайн торгового центра, нежели, чем «CallinCall». Однако данный программный продукт позволяет выполнять лишь элементарный набор операций по учету взаимоотношений клиентов и магазина. В программе можно вносить комментарии прямо в карточке заказа, но никаких изменений и автоматического закрепления заказа за тем или иным специалистом в ней нет. Сравним данные программные продукты с собственной разработкой по основным параметрам (табл. 2.1.).

Таблица 2.1. Сравнение программных продуктов

 

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

2.2. Обзор средств разработки информационных систем

2.2.1. Обзор СУБД

В данном разделе более подробно остановимся на особенностях выбора конкретной серверной СУБД. При выборе базы данных очень важно выбрать базу данных, которая в наибольшей степени соответствуют предъявляемым к информационной системе требованиям, т.е. необходимо определиться какая модель автоматизации реализуется (автоматизация документооборота или бизнес — процессов). SQL Server и Oracle относятся к классу многопользовательских систем. Они развиваются и совершенствуются уже в течение многих лет и реализуются как коммерческие программные продукты. Эти СУБД можно характеризовать как основу для промышленных решений в области обработки данных.

В первую очередь при выборе СУБД необходимо принимать во внимание следующие факторы:

1. максимальное число пользователей одновременно обращающихся к базе;
2. характеристики клиентского ПО;
3. аппаратные компоненты сервера;
4. серверную операционную систему;
5. уровень квалификации персонала.

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

1. конфигурирование системы;
2. мониторинг;
3. настройка;
4. обработка запросов;
5. разработка серверных и клиентских модулей.

Данный анализ проведем с учетом того, что число клиентских мест составляет до 50, а управление СУБД должно быть максимально эффективно. Управление системами было возложено на ОС Windows и Linux.

Oracle

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

Причина широкой распространенности Oracle заключается прежде всего в высоких

эксплуатационных характеристиках СУБД, большом количестве подготовленных отечественных специалистов по Oracle, наличию поддерживающей инфраструктры – учебных центров, широкой сети партнеров Oracle, большому числу технических курсов по Oracle в высших учебных заведениях и т.д. Важным является и то, что наряду с СУБД, компания Oracle поставляет центральный инфраструктурный продукт – Internet Application Server, сервер приложений, функционирующих в среде Internet/Intranet.

СУБД Oracle обладает уникальными качествами переносимости, а также предоставляет открытую платформу для разработки переносимых приложений клиент/сервер и Internet/Intranet-приложений. Наличие нескольких редакций сервера баз данных – корпоративной, стандартной, персональной и полная переносимость приложений между ними позволяет удовлетворить потребности информационной системы и кардинально решить задачу унификации базового программного обеспечения.

Единственным недостатком данной СУБД является сложность администрирования, однако все затраты на ее внедрение и освоение в последствии окупятся эффективной и надежной работой.При использовании СУБД Oracle на платформе NT, она потребует практически тех же усилий, что и при использовании MS SQL Server. В случае же работы на UNIX-платформе, можно с уверенностью отметить, что среда Oracle является простой, понятной и доступной. Что касается дороговизны, то компания Oracle предлагает ряд различных масштабируемых решений в зависимости от числа обслуживаемых клиентов.

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

Также необходимо отметить, что разработанная фирмой Oracle система оптимизации одновременного доступа является одной из важнейших характеристик архитектуры Oracle. Данная функция позволяет исключить ситуацию, когда одному пользователю приходится ждать, пока другой завершит изменения в содержимое баз данных (т.е. в Oracle отсутствуют блокировки на чтение). Эта функция позволяет СУБД Oracle выполнять за секунду больше транзакций в расчете на одного пользователя, чем любая другая база данных. По уровню производительности при работе в WEB среде под LINUX Oracle занимает ведущие места и при этом значительно превосходит все другие СУБД по надежности и безопасности.

СУБД Microsoft SQL Server

Важнейшие характеристики данной СУБД — это:

1. простота администрирования;
2. возможность подключения к Web;
3. быстродействие и функциональные возможности механизма сервера СУБД;
4. наличие средств удаленного доступа.

В комплект средств административного управления данной СУБД входит целый набор специальных мастеров и средств автоматической настройки параметров конфигурации. Также данная БД оснащена замечательными средствами тиражирования, позволяющими синхронизировать данные ПК с информацией БД и наоборот. Входящий в комплект поставки сервер OLAP дает возможность сохранять и анализировать все имеющиеся у пользователя данные. В принципе данная СУБД представляет собой современную полнофункциональную базу данных, которая идеально подходит для малых и средних организаций. Необходимо заметить, что SQL Server уступает другим рассматриваемым СУБД по двум важным показателям: программируемость и средства работы. При разработке клиентских БД приложений на основе языков Java, HTML часто возникает проблема недостаточности программных средств SQL Server и пользоваться этой СУБД будет труднее, чем системой Oracle. Общемировой тенденцией в XXI веке стал практически повсеместный переход на платформу LINUX, а SQLServer функционирует только в среде Windows (табл. 2.2.).

Таблица 2.2. Сравнительная характеристика СУБД

 

В результате проведённой сравнительной характеристики СУБД Oracleв наибольшей степени соответствуют предъявляемым к информационной системе требованиям.

2.2.2. Обзор языков программирования

PL/SQL-языкпрограммирования, процедурное расширениеязыка SQL, разработанноекорпорацией Oracle. Базируетсянаязыке Ада.

PL/SQL встроен в следующие СУБД: OracleDatabase (начиная с версии 7), и IBM DB2 (с версии 9.7). Также PL/SQL используется как встроенный язык для средства быстрой разработки OracleForms и инструмента разработки отчётов OracleReports.

Рассмотрим язык с точки зрения требований, рассмотренных в пункте 1.4.:

— Ведение истории заказа — хранение информации о заказах в виде справочника–данное требование реализуется на основе структуры базы данных и не влияет на выбор языка;

— Возможность передачи (приема) данных в другие приложения -реализация данного требования на языке PL/SQLвозможна, но при условии интеграции с системой веб-приложения;

— Возможность составления истории заказа — полностью реализуемо на языке PL/SQL , все операции будут производиться автоматически;

— Возможность создания отчетов — полностью реализуемо на языке PL/SQL, все операции будут производиться автоматически, после создания заказа;

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

— Возможность создания дополнительных функций;

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

— Возможность обучения рабочего персонала – возможно.

C++ — компилируемый статически типизированный язык программирования общего назначения. Являясь одним из самых популярных языков программирования, C++ широко используется для разработки программного обеспечения. Область его применения включает создание операционных систем, разнообразных прикладных программ,драйверов устройств, приложений для встраиваемых систем, высокопроизводительных серверов, а также развлекательных приложений. Существует несколько реализаций языка C++ — как бесплатных, так и коммерческих. Наиболее популярныпроект GNU, Microsoft, Intel и Embarcadero (Borland).

Рассмотрим язык с точки зрения требований, рассмотренных в пункте 1.4.:

— Ведение истории заказа — хранение информации об историив виде справочника–данное требование реализуется на основе структуры БД и не влияет на выбор языка;

— Возможность составления истории заказа — реализация данного требования реализована на стороне СУБД, язык С++позволяет производить вызов процедуры из БД и производить расчет в прикладном ПО;

— Возможность передачи (приема) данных в другие приложения –реализация данного требования реализована на стороне СУБД, язык С++позволяет производить вызов процедуры из БД и производить расчет в прикладном ПО;

— Возможность создания отчетов – возможно;

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

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

— Возможность обучения рабочего персонала – возможно;

— Возможность создания дополнительных функций- возможна;

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

JavaScript–прототипно — ориентированный скриптовый язык программирования. Является диалектом языка ECMAScript. JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам. Основные архитектурные черты:динамическая типизация, слабая типизация, автоматическое управление памятью, прототипное программирование, функции как объекты первого класса.

На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом лёгким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработке.

Рассмотрим язык JavaScript, с точки зрения реализации требований к системе,указанных в пункте 1.4.:

— Ведение истории заказа — хранение информации о заказах в виде справочника–данное требование реализуется на основе структуры БД и не влияет на выбор языка;

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

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

— Возможность создания отчетов — полностью реализуема на языке, после создания заказа;

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

— Возможность обучения рабочего персонала – возможно;

— Возможность создания дополнительных функций- возможна;

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

Таблица 2.3. Сравнительная характеристика языков программирования

 

Как видно из таблицы, наибольшим потенциалом обладает язык PL/SQL. Интерфейс проектируемой информационной системы будет создан средствами продукта OracleApplicationExpress, он наиболее совместим с этим языком. Работа будет проделана средствами языка PL/SQL.

2.2.3. Обзор средств проектирования

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

Наиболее распространенными средствами проектирования в настоящее время являются следующие: средства BPwin и ERwin, RationalRose и Aris.

Средства BPwin, ERwin реализуют методологию SADT. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

Возможности BPwin:

• поддерживает сразу три стандартные нотации — IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;
• позволяет оптимизировать процедуры в компании;
• полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC);
• позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;
• интегрирован с ERwin (для моделирования БД), ParadigmPlus (для моделирования компонентов ПО) и др.;
• интегрирован со средством имитационного моделирования Arena; содержит собственный генератор отчетов;
• позволяет эффективно манипулировать моделями — сливать и расщеплять их;
• имеет широкий набор средств документирования моделей, проектов.

Пакет ERWin это средство концептуального моделирования баз данных, использующее стандарт IDEF1X. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность — связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.).

Возможности ERWin:

• поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных — Dimensional;
• поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;
• интегрирован линейкой продуктов ComputerAssociates для поддержки всех стадий разработки ИС, CASE-средствами OracleDesigner, RationalRose, средствами разработки и др.;
• позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков;
• возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusionModelManager);
• позволяет переносить структуру БД (не сами данные) из СУБД одного типа СУБД в другой;
• позволяет документировать структуру БД.

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

Любые участники проекта — аналитики, специалисты по моделированию, разработчики и другие — могут использовать модели, построенные в RationalRose, для большей эффективности создания конечного продукта. Для бизнес-аналитиков средство RationalRose дает возможность детально описать и проанализировать бизнес-процессы данной предметной области. Системные аналитики, используя указанные описания, смогут разработать необходимый функционал ИС, который максимально удовлетворит запросы заказчика. Для архитекторов средство RationalRose будет полезно при создании мощной и гибкой архитектуры системы. Для аналитиков, специализирующихся в области разработки баз данных, RationalRose даст возможность визуально проектировать и генерировать базы данных любого размера. Таким образом, можно создавать базы данных Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 и любые другие, которые поддерживают возможность запуска скриптов стандарта ANSI SQL.

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

Существуют расширения RationalRose, которые позволяют выполнять скелетную (round-trip) разработку ИС, создаваемых на базе языков C/C++, Java, Smalltalk, Ada, ObjectPascal (BorlandDelphi) и др. Таким образом, можно сгенерировать каркас программного кода на любом из указанных языков или выполнить процедуру обратного проектирования, что позволяет сформировать модель на базе существующего кода.

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

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

Помимо представительного пользовательского функционала сильная сторона Visio состояла в том, что продукт был реализован в виде набора объектов ActiveX и включал в себя встроенную среду программирования MicrosoftVisualBasicforApplications (VBA). Это позволяло, с одной стороны, расширять функциональные возможности пакета, а с другой — легко интегрировать его с внешними приложениями. Собственно, успех Visio на рынке во многом был обусловлен именно тем, что его использовали в своих целях и продвигали на рынке многие независимые разработчики ПО.

Таблица 2.4. Сравнительная характеристика средств проектирования

 

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

2.3. Обоснование проектирования собственной ИС и выбора средств разработки

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

В качестве системы управления базами данных выбрана СУБД Oracle, потому как при равенстве во многих компонентах СУБД MicrosoftSQLServer, в СУБД Oracle наиболее развита интеграция с web — сервисами. В СУБД Oracle существует возможность подключения компоненты OracleApplicationExpress — свободная среда быстрой разработки прикладного программного обеспечения на основе СУБД Oracle, целиком реализованная как веб-приложение.

В качестве языка программирования выбран язык PL/SQL, так как он наиболее совместим с СУБД Oracle.

Глава 3. Проектная часть

3.1. Техническое задание на создание информационной системы

3.1.1. Общие сведения

1) Полное наименование Системы:

«Информационная система учёта взаимоотношений клиентов с онлайн торговым центром».

2) Шифр темы: ИС «История заказа».

3) Информационная система разрабатывается силами своих департаментов: аналитического департамента и отдела информационных технологий ООО «Нижновтранс».

4) Реквизиты ООО «Нижновтранс»:

Краткое наименование       ООО «Нижновтранс»

ОГРН                                     5087746022250

ИНН                                      7719692346

КПП                                      770101001

Юридический адрес            105082, г. Москва, ул Большая Почтовая, д.26В, стр. 2

Фактический адрес              Ленинградский проспект, д. 15, стр. 28

Работы по проектированию и разработке финансируются за счет собственных средств компании ООО «Нижновтранс».

3.1.2. Назначение и цели создания (развития) системы

1) Назначение системы – автоматизация информационных потоков в процессе создания и выполнения заказов.

2) Цели создания системы – уменьшение трудоемкости, снижение сроков выполнения и повышение качества обслуживания клиентов.

3.1.3. Характеристика объектов автоматизации

Объект автоматизации – служба поддержки покупателей.

3.1.4. Требования к системе

1) У системы должен быть простой и удобный в использовании интерфейс. Система должна быть защищена от несанкционированного взлома баз данных.

Информационная система должна обеспечивать:

— непрерываемое и устойчивое функционирование всех элементов системы;

— защиту данных от несанкционированного доступа и непреднамеренного разрушения, безопасность при внештатных ситуациях;

— система должна иметь простой интерфейс, позволяющий оператору максимально быстро обработать запрос клиента;

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

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

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

2) Требования к структуре и функционированию системы

ИС должна состоять из следующих блоков:

2.1 Блок телефонии:

— прием звонка, дальнейшие операции со звонком (перевод, удержание, набор, сброс).

2.2 Блок статистики:

— время входа и выхода из системы операторов;

— текущее количество принятых/не принятых звонков;

— среднее время разговора/общее время разговора;

— текущий уровень обслуживания на 10/20/30 секунд.

2.3 Административная панель:

— общий список всех заказов;

— возможность сортировки, поиска нужного заказа;

— внесение изменений и комментариев в заказ;

— закрепление заказа за определенным специалистом, либо группой.

3) Требования к численности и квалификации персонала

Персонал автоматизированной системы в соответствии с ролью, выполняемой им в процессе функционирования системы, делится на 2 основные категории:

1. Технологический персонал;
2. Обслуживающий персонал.

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

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

4) Показатели назначения

Время отклика системы для операции навигации по экранным формам системы – не более 3 сек, для операций по извлечению информации и её поиску– не более 15 сек.

5) Требования к надежности

Показатели надежности Системы должны отвечать требованиям ГОСТ 24.701-86 ЕСС АСУ «Надежность автоматизированных систем управления. Основные положения». Обеспечение необходимого уровня надежности требует проведения специального комплекса работ, выполняемых на разных стадиях создания и эксплуатации.

6) Требования к безопасности

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

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

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

3.1.5. Требования к функциям (задачам), выполняемым системой

1) Блок телефонии должен реализовывать следующие функции:

— производить обработку входящего/исходящего вызова;

— сохранять историю вызовов за заданный период;

— сохранять запись всех звонков за заданный период.

2) Блок статистики должен реализовывать следующие функции:

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

— осуществлять выгрузку данных за определенный период в базу данных;

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

3) Блок «Административная панель» должен реализовывать следующие функции:

— сохранение всей информации по заказу;

— при входящем вызове клиента с телефона из базы данных выдавать последний оформленный заказ;

— поиск по основным критериям;

— передача в автоматическом режиме информации по заказу определенному специалисту, группе специалистов;

— регистрации клиентов;

— внесение изменений в заказ.

3.1.6. Требования к видам обеспечения

1) Математическое обеспечение.

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

2) Информационное обеспечение.

— Требования к составу, структуре и способам организации данных в системе.

Уровень хранения данных в системе должен быть построен на основе современнойобъектно-реляционной СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.

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

Структура хранения данных в ИС История заказа должна состоять из следующих основных областей:

• область временного хранения данных;
• область постоянного хранения данных.

— Требования к информационному обмену между компонентами системы.

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

В состав передаваемых данных входят:

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

— Требования к информационной совместимости со смежными системами.

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

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

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

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

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

Для реализации подсистемы хранения данных должна использоваться СУБД ORACLE 11g.

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

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

— Требования к защите данных от разрушений при авариях и сбоях в электропитании системы.

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

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

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

— Требования к контролю, хранению, обновлению и восстановлению данных.

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

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

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

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

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

Требований нет.

3) Лингвистическое обеспечение

При реализации системы должны применяться следующие языки высокого уровня: SQL, Java, PHP.

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

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

4) Программное обеспечение

К покупным программным средствам относятся:

• СУБД Oracle Database;
• SQLDeveloper- средство разработки и отладки для SQL и PL/SQL.

5) Техническое обеспечение

Система должна быть реализована с использованием специально выделенных серверов ООО «Нижновтранс».

Сервер базы данных должен быть развернут на HP9000 SuperDome №1,минимальная конфигурация которого должна быть: CPU: 16 (32 core); RAM: 128 Gb; HDD: 500 Gb; NetworkCard: 2 (2 Gbit); FiberChannel: 4.

Сервер сбора, обработки и загрузки данных должен быть развернут на HP9000№2, минимальная конфигурация которого должна быть:CPU: 8 (16 core); RAM: 32 Gb; HDD: 100 Gb; NetworkCard: 2 (1 Gbit); FiberChannel: 2.

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

6) Организационное обеспечение

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

Состав сотрудников каждого из подразделений определяется штатным расписанием ООО «Нижновтранс», которое, в случае необходимости, может изменяться.

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

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

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

К защите от ошибочных действий персонала предъявляются следующие требования:

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

3.1.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1) Технические мероприятия

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

2) Организационные мероприятия

Силами отдела информационных технологий ООО «Нижновтранс» должны быть решены организационные вопросы по взаимодействию с системами-источниками данных. К данным организационным вопросам относятся:

— организация доступа к базам данных источников;

— определение регламента информирования об изменениях структур систем-источников;

— выделение ответственных специалистов со стороны аналитического департамента ООО «Нижновтранс»для взаимодействия с проектной командой по вопросам взаимодействия с системами-источниками данных.

3) Изменения в информационном обеспечении

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

---

Страницы:   1   2   3   4   5

---