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

Задачами аналитической системы являются:

1) Сбор и систематизация информации из разнородных источников.

2) Построение гибкой системы отчетности.

3) Решение задачи прогнозирования спроса.

В ходе выполнения дипломного проекта были:

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

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

- разработан блок прогнозирования количества продаваемого товара.

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

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

Проект содержит 115 листов пояснительной записки и 30 иллюстраций.



СОДЕРЖАНИЕ

стр.



ВВЕДЕНИЕ

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

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

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

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

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

1. 
   РАЗРАБОТКА И АНАЛИЗ ТЕХНИЧЕСКОГО ЗАДАНИЯ
   

1. 
   Исследование предметной области
   

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

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

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

Вторая проблема связана с высоким процентом возврата (возврат – вся непроданная продукция) товара. Средний процент еженедельного возврата составляет 11% от поставки. Издательству хотелось бы снизить % возврата, не снижая при этом уровня обслуживания клиентов.

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


1.2 Разработка технического задания

1. 
   Наименование и область применения
   

Назначение информационно-аналитической системы:

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

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

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

3. 
   Цель и назначение разработки
   

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

2) Система должна поддерживать возможность давать ответы на интересующие пользователя вопросы

3) Содержать стандартные отчеты необходимые работникам холдинга 4) Система должна иметь интуитивно понятный интерфейс

5) Содержать последние данные из сферы деятельности фирмы

6) Предоставлять пользователю системы возможность генерировать новые отчеты, касающиеся деятельности холдинга

7) Иметь современное и актуальное графическое оформление

8) Расчёт примерной стоимости оборудования и работ

9)Содержать встроенное хранилище данных

10) Поддерживать возможность автоматической подгрузки данных в хранилище

11) Обеспечивать автоматическое формирование заказа на центральный склад.

12) Информационная система должна сопровождаться документацией, в которой должны быть описаны следующие аспекты:

а) Настройка операционной системы, под которой будет работать информационная система;

б) Настройка программных продуктов необходимых для работы информационной системы;

в) Установка и настройка самой информационной системы;

г) Взаимодействие пользователя с информационной системой;

11) Срок разработки 2 мес.;

12) Договорная стоимость разработки 187660,5 руб.

Интерфейс информационной системы должен позволять конечному пользователю (менеджеру компании) контролировать и корректировать результаты работы системы.
1.2.5 Требования к программному и аппаратному обеспечению
1) Требования к программному обеспечению

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

Операционная система должна:

1) Иметь возможность разграничения прав пользователей при доступе к информационной системе из сети;

2) Иметь возможность разграничения прав пользователей при доступе к информационной системе при локальном входе.

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

2) Требования к аппаратному обеспечению

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

1) В качестве сетевого оборудования используются: 8-портовый коммутатор, неэкранированная витая пара и сетевые карточки: две с пропускной способностью

10 Мб/с и одна – 100 Мб/с.
2) Система должна работать на компьютерах следующей конфигурации:

а) Pentium II-233 /64Mb /5Gb /CD 48x /15” ViewSonic

б) Celeron 533 /128Mb /30Gb /15” MAG

в) Celeron 700 /128Mb /10Gb /CD 52x /15” ViewSonic
1.3 Анализ технического задания

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

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

1. 
   Функциональные требования
   

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

• 
  Система должна содержать максимум информации накапливаемой в процессе деятельности холдинга;
  

• 
  Система должна поддерживать возможность давать ответы на интересующие пользователя вопросы;
  

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

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

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

2. 
   требования к способам взаимодействия информационной системы с внешним окружением
   

Взаимодействие информационной системы с внешним окружением будет осуществляться в соответствии с моделью OSI (Open Systems Interconnection) открытых систем.

Международная организация стандартов (ISO, International Organization for Standardization) начала разработку модели открытого системного взаимодействия (OSI) в 1977г. С тех пор эта модель стала широко использоваться для построения сетевых коммуникаций. Однако надо отметить, что открытая информационная система это не система, которая всем доступна, а это правила, которые определяют, чтобы в сети с разными сетевыми устройствами происходил обмен данными.

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

Модель OSI имеет следующие уровни: 1) Физический; 2) Канальный; 3) Сетевой; 4) Транспортный; 5) Сеансовый; 6) Представительный; 7) Прикладной.

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

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

3. 
   Требования к платформе
   

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

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

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

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

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

На данный момент существует много операционных систем, которые могут управлять работой информационной системы. Нет смысла рассматривать все операционные системы, поэтому мы рассмотрим только две. Это Microsoft Windows2000 и Linux.

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

1) Вариант с использованием операционной системы Microsoft Windows2000.

• Операционная система

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

• База данных

Oracle – является мощным профессиональным средством для разработки баз данных.

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

• Среда разработки аналитической системы

В качестве сред разработки рассматриваются различные Data Mining системы:

Weka – популярная Data Mining система с открытым исходным кодом.

Yale - Data Mining система с открытым исходным кодом.

Deductor – коммерческая Data Mining система российской разработки.
2) Вариант с использованием операционной системы Linux.

• Операционная система

Linux Red Hat 7.3, проблемы могут возникнуть при настройке взаимодействия с другими операционными системами.

• База данных

Oracle – является мощным профессиональным средством для разработки баз данных.

Firebird – является удобным средством для разработки не больших баз данных. Кроме того Firebird – является бесплатной базой данных.

• Среда разработки системы планирования и прогнозирования спроса

Weka – популярная Data Mining система с открытым исходным кодом.

Yale - Data Mining система с открытым исходным кодом.
1) Операционная система

• Windows2000

Положительные стороны:

По сравнению с предшествующими разработками Microsoft эта операционная система стала более стабильной, менее склонной к зависаниям и требующей перезагрузки в меньшем количестве случаев. Файловая система NTFS позволяет назначать права пользователей на ресурс не только из сети, но и на локальном диске. Так же является легкой в настройке и администрировании.

Отрицательные стороны:

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

• Linux Red Hat 7.3

Положительные стороны:

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

Отрицательные стороны:

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

2) База данных

• Oracle

Положительные стороны:

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

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

• Firebird

Положительные стороны:

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

Отрицательные стороны:

Медленно работает при большом количестве записей; поддерживает не большое количество пользователей локальной сети.

4. 
   Среда разработки аналитической системы.
   

• Weka и Yale

Положительные стороны:

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

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

Отрицательные стороны:

Нет встроенного хранилища данных. Нет достаточно мощного OLAP ядра.

Дописка этих компонентов отнимет очень много сил и времени.

• Deductor

Положительные стороны:

Есть встроенное кроссплатформенное хранилище данных. Мощное OLAP ядро. Развитые средства для решения аналитических задач.

Отрицательные стороны:

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

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

В качестве платформы для реализации хранилища данных была выбрана Firebird 1.5. т.к. этот программный продукт рассчитан на создание и эксплуатацию небольших баз данных. Разрабатываемая информационная система будет не большой (самое большое количество записей в таблице около 100000, объем базы данных не более 3 Гб), поэтому нет смысла использовать дорогостоящий программный продукт, такой как Oracle. Выбор Firebird 1.5., а не Oracle еще обусловлен тем, что для создания информационной системы в Oracle потребуются дополнительные расходы на освоение этого программного продукта, т.к. на данный момент времени я не знаком с этим программным продуктом. Так же Firebird 1.5. легок в использовании, он имеет хороший встроенный инструментарий для создания таблиц, запросов, форм, отчетов и макросов. Кроме того Firebird 1.5. является бесплатной базой данных.

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

Этот выбор обусловлен следующими причинами:

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

2. Развитые средства интеграции с учетными системами.

3. Наличие эффективных алгоритмов для решения задачи прогнозирования спроса.

4. Встроенные в систему хранилище данных и мощные средства визуализации и отчетности.

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

Microsoft Excel 2003 – является привычной средой работы менеджеров. План будет экспортироваться в Excel.

Microsoft Word 2003 – для разработки руководств пользователя и разработчика.

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

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

Разработка информационной системы будет производиться под операционной системой Windows 98 Second Edition, так как Office XP работает в среде операционных системах Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows NT с пакетом обновления 6, Windows 2000 и Windows XP, то не потребуется никакой перенастройки при переносе информационной системы на другую платформу. Поэтому дешевле будет разработать информационную систему на платформе Windows 98 Second Edition, а потом перенести готовую информационную систему на платформу Windows2000.

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

• 
  Процессор: Pentium 166
  
• 
  Оперативная память: 64 Mb
  

• 
  Места на HDD (Накопитель на жестком магнитном носителе): 500Mb
  

• 
  Монитор: 15” SVGA
  

• 
  Видео карта: SVGA
  
• 
  CD-ROM
  

• 
  Сетевая карта
  

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

Рассмотрим подробно каждый из блоков системы:
2.1 Блоки информационной системы.

1. 
   Хранилище данных.
   

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

2. 
   Блок автоматической загрузки данных в хранилище.
   

Блок предназначен для автоматизации процесса загрузки новых данных о продажах в хранилище.

3. 
   Блок генерации отчетов (OLAP).
   

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

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

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

4. 
   Блок прогнозирования по количеству и расчета страхового запаса.
   

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

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

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

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

Сетевые технические средства – устройства, обеспечивающие объединение компьютеров в единую компьютерную сеть.

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

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

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

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

Рисунок 2.9 – Архитектура «файл-сервер»
Deductor поддерживает возможность сетевой работы с хранилищем данных. Поместив файл с хранилищем на сервер и поставив Deductor на клиентскую машину можно будет работать с базой данных по сети, при этом передаваться будут только данные. Интерфейс будет загружаться с клиентской машины, что сократит время на передачу данных в сети.

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

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

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

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

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

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

На основе вышесказанного и согласно требованиям технического задания:

В техническом задании было сказано, что уже имеется следующее сетевое оборудование: 8-портовый коммутатор, неэкранированная витая пара и сетевые карточки: две с пропускной способностью 10 Мб/с и одна – 100 Мб/с; и следующие конфигурации компьютеров:

а) Pentium II-233 /64Mb /5Gb /CD 48x /15” ViewSonic

б) Celeron 533 /128Mb /10Gb /CD 52x /15” MAG

в) Celeron 700 /128Mb /30Gb /15” ViewSonic

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

В качестве АРМ сетевого администратора использовать Celeron 700 /128Mb /30Gb /15” ViewSonic, с сетевой картой на 100 Мб/с; в качестве АРМ оператора Pentium II-233 /64Mb /5Gb /CD 48x /15” ViewSonic, с сетевой картой на 10 Мб/с; в качестве АРМ лица принимающего решения Celeron 533 /128Mb /10Gb /CD 52x /15” MAG, с сетевой картой на 10 Мб/с. Все эти автоматизированные рабочие места объединить в единую ЛВС через коммутатор. Таким образом, при одновременном обращении обоих машин к серверу, у каждой из них будет отдельный канал с пропускной способностью 10 Мб/с. Такая же пропускная способность может обеспечиваться при одновременном обращении до 10 компьютеров с сетевыми картами 10 Мб/с.

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

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

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

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

В качестве сетевых программных средств используются операционные системы: на АРМ системного администратора – Windows 2000; На АРМ оператора и лица принимающего решения – Windows 98 Second Edition, полностью поддерживающие выбранную архитектуру информационной системы.

В качестве сетевого протокола можно использовать любой протокол, обеспечивающий взаимодействие между компьютерами (TCP/IP, при этом каждому компьютеру присваивается свой IP – адрес, который назначается сетевым администратором или IPX/SPX и NetBEUI).
2.3 Реализация компонентов информационной системы
2.3.1 Хранилище данных

Первым этапом реализованного проекта, был этап проектирования структуры хранилища данных. Хранилище данных представляет собой единый источник информации (база данных), в котором накапливаются все необходимые для построения отчетов и аналитической обработки данные. Отметим, что в качестве источников исходных данных могут выступать не только Excel таблицы, но и любая другая база данных или учетная система. В частности во время реализации проекта были апробированы механизмы прямого доступа к 1С 7.7.

Создание хранилища данных преследует следующие цели:

1. 
   Обеспечить автоматический сбор и приведение к единому формату данных из различных источников.
   
2. 
   Облегчить конечному пользователю доступ к данных необходимых для аналитической обработки (построение отчетов и моделей). Конечный пользователей при извлечении нужной ему выборки данных оперирует терминами бизнеса (дата, сумма, формат), а не SQL-операторами.
   
3. 
   Снизить нагрузку с учетной системы (в случае если информация необходимая для анализа хранится в учетной системе), т.к. нагрузки на учетную систему при извлечении больших выборок данных необходимых для анализа могут быть значительными, что будет мешать выполнять системе свои повседневные задачи оперативного учета данных. Структура же хранилища данных оптимизирована именно для решения задач анализа, что положительно сказывается на скорости доступа к большим объемам данных хранящихся в Х.Д.
   

Хранилище данных было реализовано на базе компоненты Deductor Warehouse входящей в состав аналитической платформы Deductor. В качестве СУБД была выбрана Firebird.

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

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

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



Схема хранения данных

Измерения могут быть как простыми списками, например, дата, так и содержать дополнительные столбцы, называемые атрибутами. Например, измерение Товар может состоять из 'Наименование товара' – собственно измерение (первичный ключ) и 'Веса', 'Объема' и прочее – атрибуты данного измерения. Измерения могут быть связаны с другими измерениями.

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

Deductor Warehouse может строиться на базе 3-х СУБД: Oracle, MS SQL и Firebird. Выбор информации из хранилища данных производится при помощи мастера импорта: пользователь просто выбирает, какая информация из имеющейся в хранилище данных его интересует, а система самостоятельно формирует специфичный для каждой СУБД SQL запрос для выбора сведений. Работа с любой из баз данных происходит совершенно прозрачно для пользователя.



Кросс-платформенное хранилище данных

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



Варианты решения задач консолидации на базе
кросс-платформенного хранилища данных Deductor Warehouse

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

Deductor Warehouse является идеальным местом хранения аналитических данных:

• 
  Централизованное хранилище;
  
• 
  Оптимизированный доступ;
  
• 
  Непротиворечивость данных;
  
• 
  Использование бизнес-понятий для доступа к информации;
  
• 
  Автоматическое обновление.
  

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

• 
  Данные преобразовываются из плоских таблиц в многомерное представление, наилучшим образом подходящее для анализа данных;
  
• 
  Исключаются все дублирующиеся данные для уменьшения объемов базы данных;
  
• 
  Обеспечивается непротиворечивость информации;
  
• 
  Проводятся все необходимые манипуляции, позволяющие в последствии в 10-100 раз увеличить скорость извлечения необходимых данных из хранилища.
  

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

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

Измерения.

A. Измерение «КлючНомера»

N	Поле в хранилище	Измерение/ свойство	Описание
1	КлючНомера	измерение	Уникальный идентификатор номера (строка в которой содержатся формат, номер, год)
2	Год	свойство
3	Дата	свойство
4	Изменения	свойство
5	НарушениеСроковПечати	свойство
6	Номер	свойство
7	ПерсоныНаОбложке	свойство
8	ПолПерсоны	свойство
9	Полосность	свойство
10	ПорядокВотчете	свойство
11	ПроисхождениеПерсоны	свойство
12	СрокиПечати	свойство
13	Формат	свойство

B. Измерение «Дистрибьютор»

N	Поле в хранилище	Измерение/ свойство	Описание
1	Дистрибьютор	измерение
2	ПорядокВотчете	свойство	Порядок, в котором отображать дистрибьюторов в формируемых отчетах

Процессы.

А. Процесс «ДетальныеПродажи»

N	Поле в процессе	Измерение /факт	Описание
1	Дата	измерение
2	Номер	измерение
3	Формат	измерение
4	НаименованиеТочки	измерение
5	Адрес	измерение	Характеристика точки
6	Дистрибьютор	измерение	Характеристика точки
7	Организация	измерение	Характеристика точки
8	Сегмент	измерение	Характеристика точки
9	Размер	измерение	Характеристика точки
10	Город	измерение	Характеристика точки
11	Город/область	измерение	Характеристика точки
12	РайонГорода	измерение	Характеристика точки
13	Менеджер	измерение	Характеристика точки
14	КоличествоКасс	измерение	Характеристика точки
15	Опт/Розница	измерение	Характеристика точки
16	Ориентир	измерение	Характеристика точки
17	ПоставщикЖурналов	измерение	Характеристика точки
18	ПоставщикМестнойПрессы	измерение	Характеристика точки
19	ТипТочки(местоположение)	измерение	Характеристика точки
20	РежимРаботы	измерение	Характеристика точки
21	ПорядокВотчете	измерение	Порядок, в котором отображать дистрибьюторов в формируемых отчетах
22	КлючЗаменыТочка	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
23	КлючЗаменыТочка2	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
24	КлючЗаменыДистрибьютор	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
25	Возврат	факт
26	Поставка	Факт
27	Продажа	факт

B. Процесс «Долги»

N	Поле в процессе	Измерение /факт	Описание
1	Дистрибьютор	измерение
2	Дата	измерение
3	ОплатаВТекущемМесяце	факт
4	ТекущийДолг	факт

C. Процесс «ИсторияЦен»

N	Поле в процессе	Измерение /факт	Описание
1	Дата	измерение
2	Номер	измерение
3	Формат	измерение
4	Дистрибьютор	измерение
5	КлючЗаменыЦены	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
6	ОтпускнаяЦена	факт
7	РозничнаяЦена	факт
8	ЦенаНаОпте	факт

D. Процесс «Конкуренты»

N	Поле в процессе	Измерение /факт	Описание
1	Дата	измерение
2	Дата(Год+месяц)	измерение
3	ДеньВыхода	измерение
4	НаименованиеИздания	измерение
5	ОбщийТираж	факт
6	ОбъемПолос	факт
7	ОтпускнаяЦена	факт
8	ПолосностьТелепрограммы	факт
9	РозничнаяЦена	факт

E. Процесс «ОбщиеВозвраты»

N	Поле в процессе	Измерение /факт	Описание
1	Дистрибьютор	измерение
2	Формат	измерение
3	Дата	измерение
4	Дата(Год+месяц)	измерение
5	Номер	измерение
6	Год	измерение
7	КлючНомера	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
8	КлючЗаменыДистрибьютор	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
9	Возврат	факт

F. Процесс «ОбщиеПоставки»

N	Поле в процессе	Измерение /факт	Описание
1	Дистрибьютор	измерение
2	Формат	измерение
3	Дата	измерение
4	Дата(Год+месяц)	измерение
5	Номер	измерение
6	Год	измерение
7	КлючНомера	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
8	КлючЗаменыДистрибьютор	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
9	ОтпускнаяЦена	факт
10	ОтпускнаяЦена(БезНДС)	факт
11	Поставка	факт
12	СуммаПоставки	факт
13	СуммаПоставки(БезНДС)	факт

G. Процесс «ОбщиеПродажи»

N	Поле в процессе	Измерение /факт	Описание
1	Дистрибьютор	измерение
2	Формат	измерение
3	Дата	измерение
4	Дата(Год+месяц)	измерение
5	Номер	измерение
6	Год	измерение
7	КлючНомера	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
8	КлючЗаменыДистрибьютор	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
9	ОтпускнаяЦена	факт
10	ОтпускнаяЦена(БезНДС)	факт
11	Поставка	факт
12	СуммаПоставки	факт
13	СуммаПоставки(БезНДС)	факт
14	СуммаПродажи	факт
15	СуммаПродажи(БезНДС)	факт
16	Возврат	факт
17	Продажа	факт
18	СуммаВозврата	факт
19	СуммаВозврата(БезНДС)	факт

H. Процесс «УФПС»

N	Поле в процессе	Измерение /факт	Описание
1	УФПС(Детально)	измерение
2	Формат	измерение
3	Дата	измерение
4	Дата(Год+месяц)	измерение
5	Номер	измерение
6	Год	измерение
7	КлючНомера	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
8	КлючЗаменыУФПС	измерение	Вспомогательное поле необходимое для корректной загрузки данных в хранилище
9	Поставка	факт

Данные, находящиеся в созданном хранилище

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

Формат A3 c 06.09.2005 по 05.12.2006

Формат A4 c 14.02.2006 по 05.12.2006

2. 
   Роспечать
   

Формат A3 c 06.09.2005 по 28.11.2006

Формат A4 c 14.02.2006 по 28.11.2006

3. 
   ЧП Ятманов
   

Формат A3 c 29.11.2005 по 28.11.2006; не была предоставлена информация по номерам 3, 5 и 9 в 2006 году.

Формат A4 c 14.02.2006 по 28.11.2006

4. 
   Шанс-Пресс
   

Формат A3 c 06.12.2005 по 28.11.2006; не была предоставлена информация по номерам 23 и 24 в 2006 году.

Формат A4 c 14.02.2006 по 28.11.2006; не была предоставлена информация по номерам 23, 24 и 26 в 2006 году.

2. 
   Процесс Общие поставки содержит информацию о поставках форматов A3 и A4 по дистрибьюторам:
   

Бесплатные экземпляры, ВТФ "Роспечать" (г.Владимир), Коммерсант-Курьер,

Периодика-НН , Печать, Региональная пресса, Резерв, Роспечать, СИТИ, УФПС, ЦДП, ЧП Минеев, ЧП Симановский, ЧП Ятманов, Шанс-Пресс, подписка,

рекламные экземпляры.

За период с 04.01.2005 по 19.12.2006.

3. 
   Процесс Общие возвраты содержит информацию о возвратах форматов A3 и A4 по дистрибьюторам:
   

Бесплатные экземпляры, ВТФ "Роспечать" (г.Владимир), Коммерсант-Курьер,

Периодика-НН , Печать, Региональная пресса, Резерв, Роспечать, СИТИ, УФПС, ЦДП, ЧП Минеев, ЧП Симановский, ЧП Ятманов, Шанс-Пресс, подписка,

рекламные экземпляры.

За период с 04.01.2005 по 28.11.2006.

4. 
   Процесс УФПС содержит детальную информацию о поставках форматов A3 и A4 дистрибьютору УФПС по следующим направлениям:
   

УФПС Дзержинск, УФПС ПЖДП, УФПС ЦЭП плюс, УФПС область, УФПС почтамт, УФПС розница (дом связи).
За период с 04.01.2005 по 19.12.2006.

5. 
   Процесс Общие продажи содержит информацию о продажах форматов A3 и A4 по дистрибьюторам:
   

Бесплатные экземпляры, ВТФ "Роспечать" (г.Владимир), Коммерсант-Курьер,

Периодика-НН , Печать, Региональная пресса, Резерв, Роспечать, СИТИ, УФПС,

ЦДП, ЧП Минеев, ЧП Симановский, ЧП Ятманов, Шанс-Пресс, подписка,

рекламные экземпляры.

За период с 04.01.2005 по 28.11.2006.

6. 
   Процесс Конкуренты содержит информацию о конкурентах за период с 01.02.2005 по 20.12.2006.
   

7. 
   Процесс История цен содержит информацию о ценах на форматы A3 и A4 по дистрибьюторам:
   

ВТФ "Роспечать" (г.Владимир), Коммерсант-Курьер, Нижполиграф, Периодика-НН,

Печать, Региональная пресса, Роспечать, СИТИ, Свободная пресса, УФПС, Феофанова,

ЦДП, ЧП Минеев, ЧП Симановский, ЧП Ятманов, Шанс-Пресс .

За период с 01.07.2001 по 17.10.2006.

8. 
   Процесс Долги содержит информацию о текущих долгах.
   

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

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

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

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

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

Технически реализовать интеграцию Deductor со сторонними системами можно несколькими способами.



Пакетное выполнение

Подготовленный заранее сценарий автоматически 'прогоняется' на новых данных с экспортом результатов обработки в сторонний приемник. Таковым может выступать таблица в любой СУБД, текстовый файл с разделителями, dbf-файл, RTF, HTML, XML и прочее. Для этого используется приложение Deductor Studio, вызываемое с опцией /run. Результаты выполнения протоколируются в лог-файл. Приложению могут передаваться различные параметры в командной строке, определяющие выполнение тех или иных фрагментов сценария обработки.

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

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





OLE сервер

Deductor Studio может функционировать в режиме OLE сервера. Таким образом, передача информации и управление обработкой данных организуется из любого приложения, поддерживающего работу с OLE серверами, например, из MS Excel или Access. Кроме того, взаимодействие с OLE сервером можно организовать с применением практически любого современного языка программирования: С++, Java, Delphi, Visual Basic, Oracle PL SQL и прочее.

Использование Deductor Studio в качестве OLE сервера может быть организовано, например, так:





Windows служба

Deductor Server регистрируется в Windows как служба, обрабатывающая данные заданного порта по протоколу TCP/IP. Доступ к серверу обеспечивается удаленно при помощи специальной бесплатно распространяемой библиотеки DClient.dll.

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

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

Схема взаимодействия между сторонними приложениями и Deductor Server следующая:





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

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

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

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

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



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

Блок автоматической загрузки данных в хранилище представляет собой сценарий сконструированный из блоков в ходящих в состав Deductor’a и осуществляющий автоматическую перекачку информации из Excel таблиц в хранилище данных. Перекачка осуществляется с определенной периодичностью(1 месяц).

3. 
   Блок генерации отчетов (OLAP).
   

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

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

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

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

1. Продажи по сегментам





2. Город/Область(Тираж)





3. ДетальныйПоТочкам

ТОР100 – 100 точек по которым были произведены наибольшие продажи за конкретную дату.

4. Конкуренты.





5. СвойстваНомеров



6. ДинамикаВозвратов





7. ОбщиеПродажи



8. ОтчетПоВозвратам

1. 
   КоличествоРаботающихТочек
   

2. 
   КоличествоТочекНормальныйВозврат
   
3. 
   КоличествоТочекНулевойВозврат
   

4. 
   КоличествоТочекПревышениеВозврата
   

5. 
   ТочкиСпревышениемВозврата
   
6. 
   ТочкиСнормальнымВозвратом
   
7. 
   ТочкиСнулевымВозвратом
   
8. 
   ВсеТочки
   

9. Долги

Производится расчет долгов дистрибьюторов на заданную дату.

10. ИсторияЦен



11. Заявки

Рассчитываются стандартные формы заявок на последнюю дату находящихся в хранилище данных:

1. 
   Бухгалтерия
   
2. 
   Экспедитор
   
3. 
   Пресс-Трафик
   

12. Декларация

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

1. Модели на основе формул, составленных экспертами в предметной области

Примером подобной модели может служить "модель средней скорости" (скользящее среднее), которая задается следующей формулой

Xпрогноз=X(t+1)=[X(t)+…+X(t-n)]/n или в более общем виде Xпрогноз=X(t+1)=a0*X(t)+…+an*X(t-n),
где а0,…,аn-коэффициенты заданные экспертным путем.

Существует большое количество подобных моделей с коэффициентами, подобранными для конкретных ситуаций ( см. например книгу Шрайбфедера[2]).

Результат работы моделей данного типа легко интерпретируется, значение коэффициента ai, подобранного экспертом, можно интерпретировать, как степень влияния фактора X(i) на прогноз. Модели данного класса очень легко запрограммировать и применить к большому количеству объектов без существенных затрат машинного времени. Кроме того, эти модели идеально подходят для анализа “коротких” рядов.

У моделей на основе формул существует и ряд существенных недостатков:

1. Необходимо прекрасное знание экспертом предметной области и наличие самого эксперта.

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

2. Статистические модели

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

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

3. Полиномиальные модели и в частности линейная регрессия

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

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

Можно конечно попытаться избежать проклятия размерности путем применения полиномиальной модели линейная регрессия Xпрогноз=a0+a1*X1+…+an*Xn, но модели данного типа способны выявить лишь линейные зависимости и бессильны при наличии нелинейностей, что характерно для большинства практических задач.

4. Нейросетевые модели

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

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

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

Рассмотрим более подробно процесс решения задачи прогнозирования по количеству:

Прогнозирование будем строить по классической схеме представленной на Рис.1.




Рис. 1 Классическая схема последовательности действий при прогнозировании.


Объектом прогнозирования выступают общие продажи двух форматов (A3 и А4)

одного из изданий.

Кроме того анализ показал, что эти форматы являются взаимозаменяемыми товарами.

Рост продаж одного из них приводит к падению продаж на другой (см. Рис. 2).



Рис.2.

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




Рис 3. Прогнозируемый временной ряд

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

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

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

Продажи после сглаживания показаны на Рис.4.



Рис. 4. Сглаживание


На данном рисунке приведены данные до и после сглаживания для одного из анализируемых рядов.

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

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

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



Рис.5. На данном рисунке показан график автокорреляционной функции. Этот график показывает наличие сезонности.

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


Качество построенной модели можно оценить при помощи таких инструментов как диаграмма рассеяния и диаграмма.




Рис.6. Диаграмма рассеяния.

Чем ближе красные точки к синей линии тем лучше построилась модель.


Рис.7. Диаграмма. Синяя линия показывает действительные продажи, а фиолетовая то как аппроксимировала их построенная модель.

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

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

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

Рассмотрим используемый метод расчета страхового запаса для формата А3:

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

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

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

Коэффициент отклонения Уровень обслуживания, %

2 95,0

3 97,5

4 98,5

В данном исследовании был выбран оптимальный коэффициент отклонения для формата А3 равный 2.

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

Экономия за 7 недель использования системы составила 110330 рублей.




Рис.8. Экономия от использования системы.


2.4 Защита информации
В анализе технического задания была выбрана операционная система Windows 2000 и СУБД Firebird для хранилища данных. Т.к. информационная система будет находиться на сервере, который подключен к локальной сети, а доступ к ней осуществляться только с двух автоматизированных рабочих мест (АРМ оператора и АРМ начальника сектора), то необходима защита от несанкционированного доступа к информационной системе. Выбранные программные продукты при правильной их настройке обеспечивают распределение прав пользователей, что обеспечивает требуемую защиту информации, оговоренную в техническом задании.

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

В СУБД Firebird защита осуществляется на уровне пользователя, путем присвоения пользователю информационной системы имени и пароля, и распределения прав на ресурсы информационной системы в зависимости от вида работ пользователя.

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

Возможность бороться с опасностями в каждой точке распределенных инфраструктур, связана в первую очередь с такими системными механизмами, как Active Directory и Kerberos. Не менее важную роль в обеспечении защиты играет и ряд решений, впервые внедренных в Windows 2000 на уровне поддержки приложений. Это такие компоненты, как цифровые сертификаты, поддержка микропроцессорных карт, средства управления защитой, а также специализированная файловая система EFS (Encrypted File System). Использование всех этих средств позволит предприятиям открывать для уполномоченных внешних пользователей все свои документы, вплоть до самых секретных.

Кроме того, контролируемый и легко настраиваемый доступ к данным стимулирует предприятия к построению распределенных приложений, охватывающих поставщиков, деловых партнеров и клиентов. Microsoft планирует постепенно отказаться от нынешнего механизма NT LAN Manager (NTLM), разработанного еще в 1988 году, и заменить его на Kerberos версии 5.0. Kerberos - это протокол аутентификации с разделяемым ключом, позволяющий двум участникам сеанса работы по сети удостоверить подлинность сообщений. С этой целью Kerberos снабжает каждого пользователя уникальным ярлыком (ticket), играющим роль ключа при опознании. Источником ярлыков для Kerberos служит подсистема Key Distribution Center (KDC). Ярлык порождается на этапе регистрации каждого пользователя в сети и основан на защищенном кэшировании его пароля. При создании любого пароля неявно вызывается особая хэш-функция, генерирующая ярлык в виде набора зашифрованных алфавитно-цифровых и специальных символов. В дальнейшем ярлык хранится на клиентском ПК в специальном кэше. В тот момент, когда пользователь пытается получить доступ к какой-либо программе или файлу, механизм Kerberos проверяет кэш на наличие действительного ярлыка. При неудаче следует запрос к KDC, который выдает искомый ярлык и отправляет его на машину пользователя. Там ярлык хранится до истечения срока действия. Каждый пользователь может быть зарегистрирован на любом из KDC в пределах корпоративной сети, поскольку все подобные центры, независимо от домена, связаны друг с другом доверительными отношениями.
В отличие от описанного механизма, NTLM использует для хранения учетных записей и прав доступа пользователей централизованную базу данных Security Accounts Manager (SAM), а это наносит ущерб производительности всей системы из-за частых запросов к базе данных, когда приложение или домен выясняют, какие права имеет пользователь на тот или иной ресурс. Kerberos помещает все сведения о правах доступа не только в KDC, но и непосредственно в Active Directory. Тем самым снимается зависимость процедуры входа в сеть от местоположения пользователя. Active Directory рассылает информацию о правах доступа по всей корпоративной системе, что дает возможность пользователям регистрироваться в сети с любого рабочего места. Таким образом, Windows 2000 подходит для использования его в качестве платформы на сервере базы данных, т.к. его возможности удовлетворяют техническим требованиям.

2.4.2 Принципы безопасности информационных технологий

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

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


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

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

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

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

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

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

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

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

Для обеспечения каждой категории пользователей нужным инструментарием в Deductor включено 2 приложения: Studio и Viewer. Эксперты используют Deductor Studio для построения моделей, а конечные пользователи – Deductor Viewer для просмотра результатов.

Deductor Viewer является рабочим местом конечного пользователя. Пользователю доступна только панель управления Отчеты. Программа позволяет минимизировать требования к персоналу, т.к. все необходимые операции выполняются автоматически при помощи подготовленных ранее сценариев обработки, нет необходимости задумываться о способе получения данных и механизмах их обработки. Пользователю Deduсtor Viewer необходимо только выбрать интересующий отчет. Доступны следующие функции: получение результатов обработки, настройка способа отображения, печать, экспорт данных в офисные приложения. Помимо этого, программа решает проблему разграничения прав доступа к данным, т.к. пользователь может получить информацию только в объеме разрешенных для просмотра отчетов и не имеет механизмов получения новых данных. Deductor Viewer ориентирован на интерактивное взаимодействие с пользователем и не поддерживает пакетное выполнение сценариев.
2.5 Тестирование информационной системы
После создания информационной системы было проведено ряд тестов, которые заключаются в том, что информационная система устанавливалась на разные компьютеры с разной производительностью. С разных компьютеров запускались разные запросы. Запросы производились как с одного компьютера, так и одновременно с двух. В результате проведенных тестов были получены следующие результаты:

В качестве минимальной конфигурации компьютера, на котором может работать информационная система – Pentium 200, 64Мб (ОЗУ), 194Мб свободного места на HDD. При этой конфигурации максимальное время ожидания ответа на запрос составило 6сек. При попытке использования информационной системы на компьютерах худшей конфигурации приведет к невозможности работы информационной системы.

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

7. 
   . Руководство по установке и эксплуатации
   

3. Организационно-экономическая часть

3.1 Распределение трудоемкости по стадиям разработки

Определим следующие этапы создания информационной системы:

— разработка технического предложения,

— разработка общей структуры информационной системы,

— разработка модели взаимодействия компонентов системы,

— разработка структуры компонентов,

— разработка информационной системы,

— отладка программного кода,

— внедрение информационной системы.
Данные по трудоемкости каждого этапа приведены в таблице 3.1.
Таблица 3.1 – Трудоёмкости этапов разработки информационной системы

Этапы	Трудоемкость, чел/дней	Процент от общей трудоемкости, %
Разработка технического предложения	6	5
Разработка общей структуры ИС	8	12
Разработка модели взаимодействия компонентов системы	11	14
Разработка модели взаимодействия компонентов	20	5
Разработка ИС	13	20
Разработка экспертных моделей бизнес-процессов	8	8
Отладка программного кода	16	25
Внедрение ИС в пилотном проекте	7	9

В разработке принимали участие 3 человека: программист и 2 эксперта в области информационных процессов торгово-производственной компании. Консультации с экспертами происходили на протяжении всех этапов разработки.
3.2 Разработка сетевой модели организационно-календарного плана

Сетевая модель ОКП (организационно-календарного плана) приведена на рисунке 6.1.


Рисунок 3.1 – Сетевая модель ОКП


Описание ветвей модели приводится в таблице 3.2.
Таблица 3.2 – Назначения ветвей сетевой модели ОКП

Ветвь	Работа
0 – 1	Получение ТЗ на разработку
1 – 2	Обзор литературы по теме
2 – 3	Разработка технического предложения
3 – 4	Расчет экономического эффекта
4 – 5	Обзор подобных программных продуктов
5 – 6	Разработка общей структуры ИС
6 – 7	Разработка интерфейса пользователя
7 – 8	Разработка общих принципов работы модели ИС
8 – 9	Разработка общих принципов работы модели ИС
9 – 10	Разработка моделей базовых компонентов
10 – 11	Разработка программной модели базовых компонентов
11 – 12	Разработка модели взаимодействия компонентов
12 – 13	Разработка интерфейса пользователя для приложения для интеграции компонентов
13 – 14	Разработка экспертных моделей для анализа бизнес-процессов
14 – 15	Отладка программного кода ИС
15 – 16	Внедрение ИС

3.3 Трудоемкость и длительность проектных работ

Трудоемкость отдельных работ оценивается с учетом особенностей проводимой разработки. Минимальная и максимальная длительности проведения работы ij определяется по формуле:

t_{i j} = T_{i j} ( 1 + ) ,

где T_{i j} – трудоёмкость работы ij,

 – коэффициент, учитывающий дополнительное ненормируемое время на доработку и согласование:  _min = 0,1;  _max = 0,3 .

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

Таблица 3.3 – Временные характеристики проектных работ

Код работы	Содержание работы	Трудо-ёмкость, чел/дней	Длительность работы, дней
			tmin	tmax
1. Разработка технического предложения
0 – 1	Получение ТЗ на разработку	1	1,1	1,3
1 – 2	Обзор литературы по теме	3	2,2	2,6
2 – 3	Разработка программного приложения	1	1,1	1,3
3 – 4	Расчет экономического эффекта	1	1,1	1,3
2. Разработка общей структуры программы
4 – 5	Обзор подобных программных продуктов	3	3,3	3,9
5 – 6	Разработка общей структуры программы	2	2,2	2,6
6 – 7	Разработка интерфейса пользователя	3	3,3	3,9
3. Разработка модели компонента
7 – 8	Разработка общих принципов работы моделей ИС с учётом требований экспертов	3	3,3	3,9
8 – 9	Разработка модели базовых компонентов	5	5,5	6,5
9 – 10	Разработка программной модели базовых компонентов с учётом полученных сведений от экспертов	3	3,3	3,6
4. Разработка модели взаимодействия компонентов
10 – 11	Разработка модели взаимодействия компонентов	5	5,5	6,5
11 – 12	Разработка программной части модели взаимодействия компонентов	5	5,5	6,5
12 – 13	Разработка приложения взаимодействия компонентов	10	11	13
13 – 14	Разработка моделей информационных бизнес-процессов	4	4,4	5,2
5. Заключительные этапы разработки ИС
14 – 15	Отладка программного кода с участием экспертов	15	5,5	6,5
15 – 16	Внедрение ИС в рамках пилотного проекта	10	4,3	5,4

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

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

Стоимость одного человеко-дня рассчитываем по формуле

С_чел.дн = Q / 22¹,

где Q - должностной оклад работника. Оклады для исполнителей данной работы:

• 
  оклад программиста 9000 рублей,
  
• 
  оклад эксперта 15000 рублей.
  

Суммарная трудоёмкость проекта – 74 человеко-дней.

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



Так как премия для инженерно-программных разработчиков учитывается в их окладах, то З_ОСН = З_ПР.
3.4.2 Расчет дополнительной заработной платы

Кроме основной заработной платы имеется дополнительная, которая составляет 8% от основной. Она включает в себя премиальные выплаты и учитывает районный коэффициент. Дополнительная зарплата рассчитывается по формуле:

С_доп.з/п = С_осн.з/п * К_д,

где К_д - коэффициент, учитывающий размер дополнительной зарплаты.

В нашем случае К_д=0,08, тогда

С_доп.з/п = 99000 * 0.08 =7920 руб.

3.4.3 Отчисления в социальные фонды

Отчисления на социальные нужды рассчитываются, исходя из формулы:

С_сс = (С_осн.з/п + С_доп.з/п) * К_сс,

где К_сс = 26.2% - единый социальный налог.

C_cc = (99000 + 7920) * 0.262 = 28 013,04 руб.
3
.4.4 Расходы на эксплуатацию и содержание оборудования

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

Расчет потребленной электроэнергии. Будем считать, что 2/3 всего времени проектирования использовался компьютер. При 8 часовом рабочем дне, использование компьютера 395 часов (для 74 рабочих дней). Потребление электроэнергии 500 Вт/час. Стоимость киловатта 2,2 руб. Отсюда получается стоимость затраченной электроэнергии – 869 руб.

Амортизационные отчисления. Стоимость компьютера 15000 руб. Срок службы 6 лет. АО_{годовые} = 2500 руб. Компьютер использовался 50 дней, т.е. 50/365 = 0,14 года. Следовательно, АО = 2500*0,14 = 350 руб.

Итого расходы на содержание оборудования - 350+869 = 1219 руб.
3.4.5 Расходы на расходные материалы

Бумага – 120 рублей

Дискеты и диски – 80 рублей

Заправка картриджа принтера – 150 рублей

Итого: 350 рублей.
3.4.6 Расходы на содержание помещения

Стоимость содержания помещения (отопление, освещение)
- 547 , помещение использовалось 3.5 месяца.

Итого: 476*3,5=1914,5 рубля.

7. 
   Средства на дополнительное программное обеспечение
   

Для работы системы необходимо приобрести 1 лицензию программного обеспечения Deductor Studio по цене 29 000 руб.
3.4.8 Смета затрат на разработку

Смету затрат на разработку системы BIPlanner и подготовку производства сведем в таблицу 3.4.


Таблица 3.4 – Смета затрат на разработку

№	Статьи затрат	Сумма, руб.
1	Основная зарплата разработчиков	99 000
2	Дополнительная заработная плата	7 920
2	Отчисления в социальный фонд	28 013,04
4	Содержание оборудования	1219
5	Расходные материалы	350
6	Содержание помещения	1 914,5
7	Средства на дополнительное программное обеспечение	29 000
Итог:		167 416,54

Себестоимость разработки составляет 167 416,54 руб.

3.5 Расчет экономического эффекта

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

До внедрения OLAP-системы отчеты готовились на базе учетной системы 1С с привлечением стороннего программиста, ежемесячные расходы на которого составляли 6 000 рублей.
Итого выгода за счёт отказа от услуг стороннего программиста – 6 000 руб.
3.5.2. Оценка экономического эффекта от внедрения блоков планирования и прогнозирования.
Внедрение данных блоков позволило:

1. 
   Высвободить время менеджеров для привлечения новых клиентов.
   
2. 
   Повысить уровень обслуживания клиентов.
   
3. 
   Оптимизировать развозку товара.
   
4. 
   Оптимизировать загрузку производства.
   

В результате ежемесячный прирост прибыли по самым скромным оценкам составляет 34 000 рублей.
3.5.3 Суммарная прибыль от использования системы BIPlanner.

Суммарный экономический эффект рассчитывается в таблице 3.9 за май месяц.

Таблица 3.9 – Расчёт общего экономического эффекта

Функция ИС	Прибыль, тыс. руб.
OLAP – анализ	6
Планирование и прогнозирование	34
Итог:	40

3.6 Определение срока окупаемости

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

Практически срок окупаемости (период возврата) инвестиций можно определить по формуле:

,

где K – суммарная величина израсходованных денежных средств из всех источников финансирования, подсчитанная в таблице 6.5. К = 167 416,54 руб.

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

Срок окупаемости (в месяцах): _.
3.7 Определение чистого дисконтированного дохода за 1 год

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

,

где ЧДД – чистый дисконтированный доход

a_t – коэффициент дисконтирования ,

Д_t – чистый доход предприятия в t-ом месяце расчетного периода,

K_t – величина инвестиций в t-ом месяце расчетного периода,

t_Н и  t_К – соответственно начальный и конечный месяцы расчетного периода.



3.8 Определение внутренней нормы доходности

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

,

Проект считается эффективным, если Е_нв> Е, чем выше показатель Е_нв, тем эффективнее инвестиционный проект.

Средняя инфляция в месяц – 0,02.

Для получения Е_нв необходимо найти наименьший корень уравнения:



Решая уравнение итерационным методом, находим внутреннюю норму доходности – Е_нв = 0,04. То есть проект является окупаемым.
3.9 Итоговая таблица технико-экономических показателей

По полученным выше данным составляем таблицу технико-экономических показателей спроектированной экспертной системы (см. табл. 3.10).
Таблица 3.10 – Технико-экономические показатели проекта

Наименование показателя	Значение
Сметная стоимость разработки	167 416,54 руб.
Срок окупаемости	4 месяца
Чистый дисконтированный доход за 1 год	205 901,25 руб.
Внутренняя норма доходности	0,04

Таким образом, проект информационной системы рентабелен.

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

4.1 Оценка опасных и вредных производственных факторов

На рабочем месте разработчика, согласно ГОСТ 12.0.003-74^* «Опасные и вредные производственные факторы. Классификация», можно выделить следующие опасные и вредные производственные факторы:

Физические:

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

1. 
   повышенное напряжение в сети;
   
2. 
   плохое заземление;
   
3. 
   наличие напряжения на корпусе ПЭВМ.
   

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

4. 
   повышенная (пониженная) яркость знака (яркость фона) монитора;
   
5. 
   наличие на рабочем месте объектов, вызывающих отражения и блики;
   
6. 
   недостаток (избыток) искусственного света на рабочем месте;
   
7. 
   отсутствие или недостаток естественного света на рабочем месте;
   
8. 
   повышенная (пониженная) температура воздуха рабочей зоны;
   
9. 
   повышенный уровень электромагнитного излучения;
   
10. 
    повышенная (пониженная) подвижность воздуха;
    
11. 
    повышенная ионизация воздуха;
    
12. 
    повышенный уровень статического электричества;
    
13. 
    физические перегрузки статического характера, связанные с малой подвижностью в течении всего рабочего дня.
    

Психофизиологические:

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

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

4.2 Производственная санитария

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

4.2.1 Микроклимат в производственных помещениях

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

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

1. 
   температурой воздуха, t ( ⁰C);
   
2. 
   относительной влажностью, В (%);
   
3. 
   скоростью движения воздуха на рабочем месте, V(м/с).
   

Все эти факторы должны соответствовать СанПиН 2.2.2/2.4.1340-03 “Гигиенические требования к видео дисплейным терминалам, персональным электронно-вычислительным машинам и организации работы”.

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

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

В таблице 9.1 представлены нормы микроклимата для легкой категории работ 1а, к которой относятся работы, производимые сидя и не требующие физического напряжения, при которых расход энергии составляет до 120 ккал/ч.
Таблица 4.1 - Параметры микроклимата для помещений с ВДТ и ПЭВМ

Период Года	Температура воздуха не более (в 0С)		Относительная влажность воздуха, %		Скорость движения воздуха, м/с
	Опим.	Доп.	Опт.	Доп.	Опт.	Доп.
Холодный	22-24	20-25	40-60	15-70	0,1	0,1
Теплый	23-25	21-28	40-60	15-75	0,1	0,2

Требуемые параметры микроклимата на рабочем месте обеспечиваются при помощи центрального водяного отопления, системы кондиционирования и вентиляции. Проектирование и эксплуатация систем водяного центрального отопления, вентиляции и кондиционирования удовлетворяют требованиям СНиП 41-01-2003 «Отопление, вентиляция и кондиционирование воздуха. Нормы проектирования».

4.2.2 Производственное освещение

Используется совмещенное освещение в соответствии с СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к видео дисплейным терминалам, персональным электронно-вычислительным машинам и организации работы».

Так как в производственном помещении с ВДТ и ПЭВМ разряд зрительных работ IV “в” с наименьшим размером объекта различения 0,5 – 1 мм, согласно СНиП 23-05-95 выбираем нормируемую освещенность помещения равную 400 лк.

Светильники располагаются на потолке.

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

Для внутренней отделки интерьера помещения используются диффузно-отражающие материалы с коэффициентом отражения для потолка - 0,7 - 0,8; для стен - 0,5 - 0,6; для пола - 0,3 - 0,5.

Работа разработчика относится к зрительной работе высокой точности, разряд зрительной работы III по СНиП 23-05-95 «Естественное и искусственное освещение. Нормы проектирования». Минимальный размер объекта различения составляет 0,3-0,5 мм. Освещенность на поверхности стола в зоне размещения рабочего документа равна 200 лк. Освещение не создает бликов на поверхности экрана.

Нормы освещенности на рабочем месте приведены в таблице 9.2.

Таблица 4.2 – Нормы освещенности на рабочем месте

Искусственное освещение			Совмещенное	Естественное боковое
Освещенность, лк	Контраст	Фон	КЕО, %	КЕО, %
200	большой	светлый	1,2	2

4.2.2.1 Расчёт искусственного освещения

Работы по разработке проекта проводятся в прямоугольном помещении, которое имеет следующие размеры:

• 
  длина ;
  
• 
  ширина ;
  
• 
  высота подвески светильников Нр=3м;
  
• 
  площадь помещения равна S = AB = 35.75 м².
  

Расчет искусственного освещения для светильников с люминесцентными лампами ведется по следующей формуле:


(9.1)


где Фл – световой поток лампы, лм;

Ен - нормированная освещенность, лк;

S – освещаемая поверхность, м²;

к – коэффициент запаса;

z – коэффициент минимальной освещенности, для люминесцентных ламп z=1.1;

Nр – количество рядов;

h – коэффициент использования светового потока;

n1 – количество светильников в ряду;

n2 – число ламп в светильнике;

Коэффициент запаса k для данного типа помещений при искусственном освещении равен 1,5.

Условия в помещении – сухие, нормальные, поэтому в соответствии с данными условиями выберем светильник УСП 5 2х40. Его характеристики:

• 
  количество ламп – 2 шт;
  
• 
  мощность – 40 Вт;
  
• 
  габаритные размеры (длина х ширина х высота), мм – 1270х236х102;
  
• 
  масса – 6,8 кг;
  
• 
  группа – 12.
  

Для ламп типа ЛД40, световой поток Фл равен 2340 лм.

Для достижения равномерной освещенности количество рядов определяем, исходя из соотношения Нр/L = 2, где Нр – высота подвеса светильников, L – расстояние между рядами. Из этого выражения находим L = 3/2 = 1,5 м. Отсюда количество рядов равно Np = A/L = 6,50/1,5 = 4 ряда.

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





Коэффициенты отражения стен потолка и пола в соответствии с СанПиН 2.2.2/2.4.1340-03 "Гигиенические требования к персональным ЭВМ и организации работ", должны быть равны соответственно:

pn = 70% ; pc = 50%; pp = 30%.

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

Из формулы (1) находим количество светильников в ряду:

шт.

Таким образом, в данном помещении для обеспечения нормированного значения освещенности необходимо 8 светильников типа УСП 5 2х40 с лампами ЛД 40, расположенных в 4 ряда по 2 светильника в каждом.

Затраты электроэнергии на искусственное освещение светильниками помещения в течении года:



где Р – мощность одной лампы, Р = 40 Вт;

T_д – количество трудовых дней, T_д = 20  12 = 240.

.

За время дипломного проектирования, то есть за 3 месяца (0,25 года), будет израсходовано следующее количество электроэнергии:

1612,8  0,25 = 403,2 кВт  ч.
Схема размещения светильников представлена на рисунке 9.1.


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

4.2.4 Защита от шума

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

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

Оптимальные показатели уровня шумов в рабочих помещениях определяются согласно СН 2.2.4/2.1.8.562-96 «Шум на рабочих местах, в жилых помещениях, на территории жилой постройки». Допустимый уровень шума при умственном труде, требующем сосредоточенности, составляет 50 дБА.

Таблица 4.3 - Уровни звукового давления

Уровни звукового давления, дБ в октавных полосах со среднегеометрическими частотами, Гц									Уровень звука, дБА
31,5	63	125	250	500	1000	2000	4000	8000
86	71	61	54	49	45	42	40	38	50

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

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

4.2.5 Электромагнитные излучения

К числу вредных факторов, с которыми сталкивается человек, работающий за монитором, относятся рентгеновское и электромагнитное излучения, а также электростатическое поле. Допустимые значения параметров излучений, генерируемых мониторами, согласно СанПиН 2.2.2/2.4.1340-03 «Гигиенические требования к видео дисплейным терминалам, персональным электронно-вычислительным машинам и организация работы» представлены в таблице 9.4.

Таблица 4.4 - Допустимые значения параметров излучений, генерируемых мониторами

Параметры	Допустимые значения
Мощность экспозиционной дозы рентгеновского излучения на расстоянии 0,05 м вокруг видеомонитора	100 мкР/час
Электромагнитное излучение на расстоянии 0,5 м вокруг монитора по электрической составляющей:
в диапазоне 5 Гц-2 кГц	25 В/м
в диапазоне 2кГц-400 кГц	2,5 В/м
по магнитной составляющей:
в диапазоне 5 Гц-2 кГц	250 нТл
в диапазоне 2кГц-400 кГц	25 нТл
Поверхностный электростатический потенциал	Не более 500 В

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

4.2.6 Организация рабочего места согласно эргономическим требованиям

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

Рабочее место должно соответствовать требованиям, указанным в СанПин 2.2.2/2.4.1340-03 и обеспечивать возможность удобного выполнения работ.
Таблица 4.5 - Определение радиуса рабочей зоны, зависящего от положения работающего, его подвижности, усилия и особенностей деятельности (на основе нормативных документов по эргономическим характеристикам рабочего места на предприятии).

Положение	Усилие, Н	Подвижность при работе	Радиус рабочей зоны, см	Особенности деятельности
Сидя	до 80	Ограничена	30 – 50	Малая статическая утомляемость

Соблюдены следующие основные условия:

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

Рабочее место показано на рисунке 4.2.



30⁰

97⁰-121⁰

200


Рисунок 4.2 – Размерные характеристики рабочего места пользователя ЭВМ

В рабочем поле различают 2 зоны:

I - зона легкой досягаемости;

II- зона максимальной досягаемости.

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

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

Кроме зон зрительного наблюдения и зон досягаемости органов управления при проектировании рабочего места необходимо читывать антропометрические данные конкретного человека. Рабочее кресло должно выполняться в соответствии с ГОСТ 21889-76 "Система "человек - машина".

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

Статистические характеристики основных антропометрических признаков мужчин и женщин приведены в ГОСТ 12.2.049-80 "ССБТ. Оборудование производственное. Общие эргономические требования".

Таблица 4.6 – Параметры рабочего стола при невозможности регулирования высоты рабочей поверхности

Параметр	Состав работающих
	Женщины	Мужчины	Женщины и мужчины
Высота рабочей поверхности при работе в положении сидя: легкие зрительные работы (зрительный фокус до 50 см)	930мм	1020мм	975мм
Высота сиденья	400мм	430мм	420мм

4.3 Безопасность производственного помещения

4.3.1 Электробезопасность помещения

Основными причинами электротравматизма при работе за ПЭВМ являются:

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

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

Разработка и эксплуатация информационной системы будет производиться на ПЭВМ, которая питается от сети с напряжением 220В, частотой 50Гц. В помещениях отдела используется трехфазная электрическая сеть с глухозаземленной нейтралью, напряжением 220/380В, частотой тока 50Гц, где видом защиты сети является зануление. В помещении с ВДТ и ПЭВМ должны быть установлены электрощиты с автоматами, которые отключают электрический ток при перегрузке сети.

В соответствии с требованиями ГОСТ 12.1.019-79 [8] для предотвращения поражений электрическим током необходимо:

1) Изолировать токоведущие части с применением прочного сплошного или многослойного изоляционного материала с Rиз>5МОм, толщина которого обусловлена типом обеспечиваемой защиты.

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

3) Подводить электропитание к ПЭВМ от розетки здания при помощи специальной вилки с заземляющим контактом. Проверять, что защитный заземляющий проводник надежно изолирован.

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

Также не желательно включать в одну сеть с ПЭВМ другие электрические приборы (электрочайники, кондиционеры, обогреватели и т.д.) т.к. это может привести к перегрузке сети и нарушении нормальной работы ПЭВМ.
4.3.1.1 Расчёт защитного заземления

В качестве искусственного заземления применяем стальные прутья диаметром 50 мм и длиной 5 м. Для связи вертикальных электродов и в качестве самостоятельного горизонтального электрода, используем полосовую сталь сечением 4x12 мм.

Определяем сопротивление растеканию тока одиночного вертикального заземления, ом

R_в =(2l)(ln(2l/d)+0.5ln((4t+l)/(4t-l)) Ом, (4.2)

где l – длина заземления, м

d – разность наружного и внутреннего диаметра трубы (при D = 50 мм 

d_o = 40 мм)

t – глубина заложения половины заземления, м

 - расчётное сопротивление грунта.

С помощью прибора M-416 производим замер сопротивления проводимости грунта (R_пр, Ом) в месте расположения будущего заземления. Показания прибора составили R_пр= 10 Ом. Расчёт удельного сопротивления производится по формуле (4.3):

(4.3)

где а – расстояние между электродами прибора М-416, а = 1 м.

_изм = 2    10  1 = 62.8 Омм.

По найденному значению _изм определим тип грунта – суглинок.

Расчетное удельное сопротивление грунта, (, Омм) определяется по формуле 9.4:

 = _изм  , (4.4)

где _изм – удельное сопротивление грунта

 - климатический коэффициент, зависящий от влажности грунта,  = 1.3.

Подставляя известные величины в формулу (4.3), получим:

 = 62.81.3 = 81.6 Омм

Определим глубину заложения половины заземления, м

t = 0.5l+t_o м, (4.5)

где t_о – расстояние от поверхности земли до верхнего конца заземлителя, принимаем = 0.5 м.

Подставляя известные величины в формулу 4.2, получим:

R_в = 650(25)(ln(10/0.01)+0.5ln(17/7) = 179.75 Ом.

Определим число заземлений по формуле

n = R_в/(R₃) шт,

где R₃ – наибольшее допустимое сопротивление заземляющего устройства, Ом

 - коэффициент использования вертикальных заземлителей без учета влияния соединительной полосы = 0.71 (электроды размещены по контуру).

n = 179.75(40.71) = 63.29 шт.

Принимаем n = 64 шт.

Определим сопротивление растеканию тока горизонтальной соединительной полосы, Ом

R_n = /(2l₁)ln(2l₁²/(bt₁) Ом, (9.4)

где t₁ – глубина заложения полосы, м

b – ширина полосы, м

l₁ – длина полосы, определяется как

l₁ = 1.05an м, (4.5)

где a – расстояние между вертикальными заземлениями, м

a = 3l = 35 = 15 м,

Подставляя известные величины в формулу (4.5) , получим:

l₁ = 1.051564 = 1008 м.

Подставляя известные величины в формулу (4.4), получим:

R_n = 650(21008)ln(21008²(0.0123)) = 1.8 Ом.

Определим сопротивление растеканию тока заземляющего устройства

R_o = R_вR_n/(R_вR_n+R_nn_в) Ом, (4.6)

где _в – коэффициент использования горизонтального полосового заземлителя, соединяющего вертикальные заземлители, м.

Подставляя известные величины в формулу (4.6), получим:

R_o = 179.51.8/(179.50.33+1.80.7164) = 2.29 Ом.

R_o не превышает допустимого сопротивления защитного заземления 

2.29  4 Ом .
4.3.2 Информационная безопасность

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

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

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

Для защиты от таких устройств используется «Генератор шума» ГШ-2500 (см. рис. 4.3). Он предназначен для маскировки информативных побочных электромагнитных излучений и наводок (ПЭМИН) персональных компьютеров, рабочих станций на объектах вычислительной техники 1, 2, и 3 категорий путем формирования и излучения в окружающее пространство электромагнитного поля шума (ЭМПШ) и наведения шумового сигнала в отходящие цепи и инженерные коммуникации в диапазоне частот от 0.1 до 1000 МГц. Установка и настройка генератора производится только специализированной организацией, имеющей соответствующие лицензии.

Один генератор обеспечивает маскировку (защиту) информации устройств вычислительной техники, размещенной в помещении площадью примерно 40 м². Для рабочей комнаты достаточно одного такого генератора, так как её площадь - 35.8 м².



Рисунок 4.3 – Внешний вид генератора шума - ГШ-2500
На уровне сети защита информации осуществляется с помощью межсетевого экрана PIX Firewall. Он осуществляет контроль информации об адресах отправителя и получателя, последовательности нумерации пакетов TCP, номерах портов и добавочных флагах TCP. Эта информация сохраняется в таблице, проверку на соответствие с записями которой проходят все входящие пакеты. Доступ через PIX разрешен только в том случае, если соединение успешно прошло идентификацию. Этот метод обеспечивает прозрачный доступ для внутренних пользователей и авторизованных внешних пользователей, при этом полностью защищая внутреннюю сеть от несанкционированного доступа.

Внешний вид Cisco PIX Firewall показан на рисунке 4.4.

Рисунок 4.4 - Внешний вид Cisco PIX Firewall (спереди и сзади)
4.3.3 Пожарная безопасность

Согласно НПБ-105-03 “Определение категорий помещений, зданий и наружных установок по взрывопожарной и пожарной опасности” помещение с ВДТ и ПЭВМ относится к категории «Д» без возможности короткого замыкания радиооборудования и других электроприборов и возгорания не горючих материалов (дерево, пластмасса и пр.).

Основными причинами возгорания при работе на ПЭВМ являются:

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

Согласно НПБ 105-03 «Нормы противопожарной безопасности. Определение категорий помещений и зданий по взрывопожарной и пожарной опасности» производственные помещения категории В могут быть размещены в зданиях со степенью огнестойкости I, II, IIIa, III и IV ( I – самая огнестойкая степень), число этажей при этом не более 8, площадь этажа не ограничивается.

Помещение размещено на четвертом этаже четырёхэтажного здания. По функциональной опасности здание относится к классу Ф 4.3 (научно-исследовательская организация).

На каждом этаже висят планы эвакуации при пожаре. Помещение, где ведется разработка проекта имеет площадь 35.75 м². По потенциальной опасности вызывать пожар, усиливать опасные факторы пожара материалы, находящиеся в помещении, являются неопасными или малоопасными. Для отделочных материалов помещения используются негорючие огнестойкие материалы (металл, стекло). Помещение оснащено ручным переносным углекислотным огнетушителем, типа ОУ-2, расположенный на видном месте, у выходной двери. Ширина проходов в помещении более метра, имеется внешняя городская телефонная связь. Эффективным средством борьбы с пожаром служит система электрической пожарной сигнализации. В нее входят: пожарные извещатели, пожарная сигнализация, линии связи.

В помещении отдела установлены пожарные извещатели (типа ДТЛ с порогом срабатывания +72 ⁰С) и комбинированные (типа КИ-1), реагирующие на тепло и дым в радиусе 5 м.

В здании имеется четыре выхода. Путь эвакуации проходит через лестницы типа 2 (внутренние открытые). На пути эвакуации используются только огнестойкие материалы (железобетон, металл, стекло). На пути эвакуации отсутствуют перепады высот более 45 см в соответствии с СНиП 21-01-97 «Пожарная безопасность зданий и сооружений». Двери на путях эвакуации открываются по направлению выхода из здания.


ЗАКЛЮЧЕНИЕ

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

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

Решение содержит:

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ
1. Кулаков Ю.А., Омельянский С.В. Компьютерные сети. Выбор, установка, использование и администрирование. – К.: ЮНИОР, 1999. – 544 с.

2. Эффективное управление запасами / Джон Шрайбфедер ; Пер. с англ. - М.: альпина Бизнес Букс, 2005. - 304 с.

3. Минаев Ю.Н., Филимонова О.Ю., Бернаур Лиес. Методы и алгоритмы решения задач идентификации и прогнозирования в условиях неопределенности в нейросетевом логическом базисе. - М.: Горячая линия - Телеком, 2003. - 205 с.: ил.

4.Уотшем Т. Дж., Паррамоу К. Количественные методы в финансах: Учеб. Пособие для вузов/Пер. с англ. под ред. М.Р. Ефимовой. - М.: Финансы, ЮНИТИ, 1999. - 527 с.

5. Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели анализа

данных: OLAP и Data Mining. – Спб.: БХВ-Петербург, 2004. – 336 с.: ил.

6. Архипенков С., Голубев Д., Максименко О. ХРАНИЛИЩА ДАННЫХ. От концепции до внедрения /Под общ. Ред. С.Я. Архипенкова –М.: ДИАЛОГ-МИФИ, 2002.

7. Дюк В., Самойленко А. Data mining: учебный курс. – СПб: Питер, 2001. – 368 с.: ил.

8. Сахаров А. А. Концепция построения и реализации информационных систем, ориентированных на анализ данных // СУБД. - 1996. - № 4. - С. 55-70.

9. Туманов В. Data Warehouse: с чего начать? – www
.
olap
.
ru

10. Бьер М. Интеллектуальное ведение и сопровождение бизнеса./ Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2005. – 240 с.

11. Сахаров А. А. Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server) // СУБД. - 1996 - № 3. - С. 44-59.