· Rational Rose 98 - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

При дальнейшем анализе будут рассматриваться только характеристики программ ARIS ToolSet (далее, ARIS), BP-Win - Erwin (далее, BP-Win). Программу Rational Rose - как в наибольшей степени ориентированную на построение чисто программных, а не организационных систем, чтобы упростить изложение мы исключим из рассмотрения, тем более что лежащая в ее основе методология UML реализована сейчас в АРИС.

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

· средства построения моделей бизнес-систем;

· средства анализа моделей;

· средства оптимизации моделируемых систем по их моделям;

· поддержка библиотек типовых моделей;

· оформление регламентов и документации;

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

· интеграция с другими программными продуктами (CASE-средствами, ERP-системами, прикладными программами).

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

· универсальность (возможность и способы представления различных аспектов моделируемой системы для разных классов систем);

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

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

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

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

· общую организацию бизнес-процессов и порядок взаимодействия оргзвеньев (исполнителей);

· распределение ответственности за реализацию отдельных функций и расходование ресурсов системы;

· загрузку оргзвеньев, исполнителей и инструментальных ресурсов в системе;

· основные временные и стоимостные параметры моделируемой системы;

· требования по ресурсному обеспечению протекающих в системе процессов.

Модели бизнес-процессов в ARIS и BP-Win строятся непосредственно, а существующие взаимосвязи компонент процесса должны подготавливаться для проведения анализа, в результате соответствующих процедур.

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

Для решения задачи о загрузке исполнителей и инструментальных ресурсов в системе, а также получение оценок по основным временным параметрам моделируемой системы необходимо тем или иным способом ввести в систему такие данные, а также предусмотреть средства получения сводных оценок. Поддержка методологии IDEF3 (в BP-Win), ABC-методов в ARIS и BP-Win, а также средств имитационного моделирования в ARIS (и, частично, в BP-Win) предусматривает определенную обработку этих оценок.

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

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

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

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

В BP-Win прямая возможность получения различных регламентов не оговорена.

В части документации для разработки информационной системы наиболее традиционные возможности предусматривает среда BP-Win/ERwin, которая, собственно, для этого и создавалась.

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

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

ARIS имеет интерфейсы с некоторыми CASE-средствами, а также является средством создания моделей для непосредственной настройки таких систем управления предприятиями, прежде всего SAP R/3.

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

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

Таблица 2.1 Сравнителная таблица CASE-средств моделирования

Функциональные возможности	Вес	ARIS	BP-Win/ ER-Win
Универсальность	5	4	20	5	25
Открытость	4	4	16	4	16
Общая организация, порядок взаимодействия, распределение ответственности, качественный анализ загрузки	5	4	20	4	20
Имитационное, событийно-управляемое моделирование (оценка временных параметров)	2	4	8	3	6
Оценка стоимостных параметров процессов (функционально-стоимостной анализ)	3	4	12	4	12
Средства оптимизации бизнес-систем	2	2	4	2	4
Организационная документация	4	3	12	3	12
Документация СМК (систем менеджмента качества)	3	4	12	3	9
Проектная документация для создания ИС	4	4	16	5	20
Поддержка разработки баз данных и программных средств	5	4	20	5	25
Интеграция с CASE средствами	4	4	16	5	20
Интеграция с прикладными программами и системами	3	3	9	4	12
Итого		44	165	47	181

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

Однако в ходе обсуждения функциональных возможностей подчеркивалось, что непосредственно для решения задач бизнес инжиниринга, отдельные группы функциональных возможностей имеют различное значение. Этот факт отражен коэффициентами, записанными в графе “Bес” Таблицы. Представление комплексного показателя конкурентоспособности продукции (К) суммой вида:

где К_i - единичные показатели конкурентоспособности продукта

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

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

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

В нашем случае предпочтение отдано BP-Win, так как он в наибольшей степени удовлетворяет требованиям аналитика. И веса в таблице расставлялись в соответствии с ними. Не малую роль в выборе сыграло и то, что данный программный продукт уже освоен и имеется опыт работы с ним. А это в свою очередь приводит к экономии времени.

2.3.2 Моделирование бизнес-процессов

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

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

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

· функциональное моделирование (IDEFO);

· описание бизнес-процессов (IDEF3);

· диаграммы потоков данных (DFD).

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

При моделировании деятельности отдела розничной продажи ОАО "МТС" используем две методологии моделирования: IDEF0 и DFD.

Функциональное моделирование (IDEFO) является технологией анализа системы в целом как набора связанных между собой действий или функций. Действия системы анализируются независимо от объекта (ов), который обеспечивает их исполнение. Моделировать деловой процесс можно исходя из различных перспектив и временных рамок.

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

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

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

2.3.3 Информационная модель "как есть" отдела продаж

В результате обследования предметной области, с помощью CASE-средства BPWin была построена модель разработки бизнес-плана "As is" ("как есть"). Данная модель отражает входящую информацию: "Заказы клиентов", "Сопроводительную документацию" и исходящие данные: "Отчетной информации", "договором о заключенной услуге" и "предоставленными услугами". Контекстная диаграмма модели представлена на рисунке 2.3

Рисунок 2.3 Организация работы отдела продаж "Радуга-ТВ"

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

1. Входящая информация "договор" и "информация об услугах" входит в блок "работа с бумажными документами" там обрабатывается и по требованию клиента или продавца выводиться;

2. Занесение в реестр данных о выполнении услуг, в этот блок заносятся данные для учета там хранятся и распечатывается счет-фактура "Счет СЧФК" (чек с указанием наименованием товара или услуги, стоимости, датой покупки);

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

Эта диаграмма представлена на рис. 2.4

Рисунок 2.4 Декомпозиция контекстной диаграммы “AS IS”.

2.3.4 Сценарий функционирования отдела продаж

Для более полного представления о работе отдела продаж, требуется описать сценарии его функционирования.

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

В обязанности начальника отдела продаж входит:

· Работа с персоналом;

· Контроль за поступлением товара, предоставлением услуг;

· Осуществление организации, планирования и координации деятельности отдела;

· Контроль продаж.

В обязанности менеджеров торгового зала входит:

· Организация работы отдела (утверждение) график работы, нагрузки, премии;

· Работа с клиентами;

· Разрешение конфликтных ситуации с клиентами;

· Информация о количестве продаж;

· Просмотр отчетов и аналитики;

· Прохождение курса повышения квалификации.

В обязанности продавца - консультанта входит:

· Работа с клиентами;

· Оказание услуг;

· Продажа товара;

· Ведение отчетности;

· Мотивирование клиента на покупку услуги или товара.

Для более наглядного представления о функциях каждого сотрудника отдела продаж представлена схема управления отдела продаж (Рисунок 2.5)

Рисунок 2.5 Управление отделом продаж

Рассмотрим организацию работы с клиентами в самом отделе продаж.

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

Рисунок 2.6 Организация работы с клиентами

2.3.4 Модель "Как надо" информационной системы

Затем, в результате проведенного системного анализа и оптимизации работы отдела продаж, была построена модель информационной системы отдела продаж "Радуга-ТВ". Эта модель отображает функции, которые выполняются сотрудниками "Радуга-ТВ" и они будут автоматизированы с внедрением информационной системы. Модель представлена на рисунке 2.7

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

Описание модели

Модель состоит из 4 блоков:

· Модуль занесения и обработки информации о клиенте и составлении договоров;

· Модуль занесения и обработки информации об услугах;

· Модуль составления отчетной документации;

· Модуль хранения и обработки информации.

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



Рисунок 2.7 Организация работ отдела продаж "Радуга-ТВ"

Рисунок 2.8 Блок "Модуль занесения и обработки информации о клиенте и составлении договоров"

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

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

Рис.2.9 Блок "Модуль занесения и обработки информации об услугах"

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

Рисунок 2.10 Блок “Модуль составления отчетной документации”

Модуль хранения и обработки информации состоит из 2 подфункций:

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

Данный блок представлен на рисунке 2.11

Рисунок 2.11 Блок “Модуль хранения и обработки информации”

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

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

3. Проектирование информационной системы

3.1 Выбор архитектуры информационной системы

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

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

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

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

Существует несколько видов архитектур ИС:

· архитектура файл-сервер;

· архитектура клиент-сервер;

· многоуровневая архитектура;

· распределенная архитектура.

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

3.2 Архитектура клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД - наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL - на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД - на сервере. Архитектура представлена на рисунке 3.1.



Рисунок 3.1 Архитектура клиент-сервер

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

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

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

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

3.3 Выбор CASE-средства проектирования информационной системы

Так как при моделировании был использован пакет программ Computer Associates All Fusion Process Modeler, содержащий как CASE-средство моделирования BPWin, так и CASE-средство проектирования ERWin, то для проектирования ИС целесообразно использовать программу из этого пакета, а именно ERWin.

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

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

ERWin поддерживает следующие СУБД: Oracle, Microsoft SQL Server, Sybase, DB2 и Informix. Одна и та же модель может быть использована для создания нескольких баз данных или для переноса приложения с платформы одной СУБД на другую.

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

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

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

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

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

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

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

База данных должна легко расширяться при реорганизации и расширении предметной области.

База данных должна легко изменяться при изменении программной и аппаратной среды.

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

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

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

Рассмотрим средства разработки, которые предлагает Microsoft.

Эта компания в настоящий момент предлагает три пакета программ, которые могут быть использованы для создания пользовательского приложения по обработке данных: Access, SQL Server, и Visual FoxPro. Эти средства могут быть использованы, так по отдельности - для решения конкретно поставленной задачи, как и в качестве интегрированного набора, каждый компонент которого может быть применен при разработке больших проектов масштаба предприятия.

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

3.4.1Visual FoxPro

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

Интерфейс Visual FoxPro отвечает представлениям о современной графической среде, напоминая интерфейс иных программ Microsoft. Здесь основная работа с данными выполняется с помощью различных инструментальных средств, поэтому команды меню часто имеют вспомогательный характер и их состав гибко меняется в зависимости от того, какое средство активно в данный момент.

Отличительные черты Visual FoxPro можно описать следующим образом:

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

2. Обеспечение полного набора средств для управления событиями. Традиционно в Xbase от программиста требовалось написать собственный драйвер для обработки необходимого набора событий или положиться на READ-состояние ожидания, которое моделирует обработку события системой. В WINDOWS, число событий, к которым может обращаться пользователь, весьма велико, и, следовательно, обработка событий является непростой задачей. Visual FoxPro имеет истинно управляемую событиями модель, так что по умолчанию система раньше, чем пользователи обрабатывает объектные события. Кроме того, программист теперь имеет полный доступ к набору стандартных на функционировании WINDOWS событий (например, движение мыши, которые допускают перетаскивание объектов).

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

4. Обеспечение полной интеграции Visual FoxPro в семейство прикладных программ Micrоsoft. Единый интерфейс с наиболее популярными прикладными программами Microsoft делает работу в интерактивном режиме интуитивно понятной. Поддержка правой кнопки мыши позволяет избежать долгих путешествий по системе меню и значительно облегчает изучение новых возможностей СУБД. Просто выберите курсором объект и нажмите правую кнопку мыши.

3.4.2 Microsoft Access

Microsoft Access - это самая популярная сегодня настольная система управления базами данных. Ее успех можно связывать с великолепной рекламной компанией, организованной Microsoft, или включением ее в богатое окружение семейства Microsoft Office. Вполне возможно, что это так. Но корень успеха, скорее всего, заключается в прекрасной реализации продукта, рассчитанного как на начинающего, так и на квалифицированного пользователя. Не будем сейчас вдаваться в подробности сравнения отдельных характеристик Access, и его основных конкурентов, например Paradox for Windows или Lotus Approach. Эта система прекрасно освещена в периодической компьютерной печати.

СУБД Access для работы с данными использует процессор баз данных Microsoft Jet, объекты доступа к данным и средства быстрого построения интерфейса - Конструктор форм. Для получения распечаток используются Конструкторы отчетов. Автоматизация рутинных операций может быть выполнена с помощью макрокоманд. На тот случай, когда не хватает функциональности визуальных средств, пользователи Access могут обратиться к созданию процедур и функций. При этом как в макрокомандах можно использовать вызовы функций, так и из кода процедур и функций можно выполнять макрокоманды.

Несмотря на свою ориентированность на конечного пользователя в Access присутствует язык программирования Visual Basic for Application, который позволяет создавать массивы, свои типы данных, вызывать DLL-функции, с помощью OLE Automation контролировать работу приложений, которые могут функционировать как OLE - серверы. Можно целиком создавать базы данных с помощью кодирования, когда в этом появляется необходимость.

MS Access из всех рассматриваемых средств разработки имеет, пожалуй, самый богатый набор визуальных средств. Тем не менее, кодировать в Access приходится. Так как ни одно приложение не предназначенное для себя лично, создать хотя бы без одной строчки кода невозможно. Для коммерческого распространения приложений, разработанных на Access, как мы уже писали, предназначен пакет Access Developer Toolkit, вместе с которым поставляются и несколько дополнительных объектов ActiveX.

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

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

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

А также Access обладает лучшей встроенной системой защиты среди всех настольных приложений СУБД. Вы можете создавать группы, пользователей, присваивать права доступа ко всем объектам, в том числе и модулям. Кстати, это решает вопрос закрытия ваших процедур и функций от чужих глаз. Так как для Access нет компилятора, то необходимость защиты становится очень актуальной для разработчиков. Система защиты доступна только при открытой базе данных. Каждому пользователю можно предоставить индивидуальный пароль. Система защиты доступна как с помощью визуальных средств, так и программным путем. Если вы хотите защитить вашу базу данных даже от пользователя с именем Admin, то пользуйтесь услугами настройки Sequrity, которая поставляется вместе с Access Developer Toolkit. Помимо этого вы можете закрыть вашу базу данных от просмотра внешними программами.

3.4.3 MS SQL Server

Microsoft SQL Server - одна из наиболее мощных СУБД архитектуры клиент-сервер. Эта СУБД позволяет удовлетворять такие требования, предъявляемые к системам распределенной обработке данных, как тиражирование данных, параллельная обработка, поддержка больших баз данных на относительно не дорогих аппаратных платформах при сохранении несмежного управления.

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

Сервер имеет средства удаленного администрирования и управления операциями, организованные на базе объектно-ориентированной распределенной среды управления. Microsoft SQL Server входит в состав семейства Microsoft BackOffice, объединяющего 5 серверных приложений, разработанных для совместного функционирования в качестве интегрированной системы.

Microsoft SQL Server предназначен исключительно для поддержки систем, работающих в среде клиент-сервер. Он поддерживает широкий спектр средств разработки и максимально прост в интеграции с приложениями, работающими на ПК.

SQL Server имеет новую масштабируемую архитектуру блокировок, называемую Динамической блокировкой (Dinamic Locking), которая комбинирует блокировку на уровне страницы и записи для достижения максимальной производительности и подключения максимального числа пользователей.

SQL Server может тиражировать информацию в БД иных форматов, включая Oracle, BM DB2, Sybase, Microsoft Access и другие СУБД (при наличии ODBC драйвера, отвечающего определенным требованиям).

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

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

· выполнять копирование объектов любого типа с указанием, какого типа объекты подлежат копированию (или копировать все объекты всех типов);

· переносить схему базы данных вместе с данными или без них;

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

· уничтожать объекты в базе-приемнике перед копированием схемы;

· для копируемого объекта включать объекты от него зависящие;

· использовать стандартные настройки генерации кода создания/удаление объектов или использовать собственные;

· определять момент выполнения переноса объектов: немедленно однократно в определенный момент времени, многократно по определенному графику.

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

С этой точки зрения характеристика всех трёх продуктов приведена в следующей таблице 3.1.

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

Название продукта	Основные преимущества	Основное назначение
Access	Простота освоения. Возможность использования непрофессиональным программистом. Имеет мощные средства подготовки отчетов из БД различных форматов.	Создание отчетов произвольной формы на основании различных данных. Разработка не коммерческих приложений.
SQL-Server	Высокая степень защиты данных. Мощные средства работы с данными. Высокая производительность.	Хранение больших массивов данных. Хранение данных, требующих соблюдения режима секретности или при не допустимости их потери.
Visual FoxPro	Высокий уровень объектной модели. Высокая скорость обработки данных. Интеграция объектно-ориентированного языка программирования с Xbase и SQL. Многоплатформенность.	Создание приложений масштаба предприятия. Создание приложений для работы на различных платформах (Windows 3. x, Windows 95, Macintosh и т.д.)

3.4.4 Заключение

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

3.5 Проектирование информационной системы

Реализация моделирования в ERwin базируется на теории реляционных баз данных и на методологии IDEF1х.

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

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

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

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

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

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

· при разработке используется много различной информации;

· коды информации, продукции, предприятия, проекта неизменны и уникальны;

· один клиент может заключить много договоров.

На рисунке 3.2 представлена логическая модель. На ней представлен общий вид потоков информации. На диаграмме имеются 5 сущностей:

· "Клиент"

· "Договор"

· "Отдел продаж"

· "Хранилище данных"

· "Отчётность"

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

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

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

Рис 3.2 Логическая модель

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

4. Спецификация для создания информационной системы отдела продаж "Радуга-ТВ"

4.1 Состав и принципы информационного обеспечения

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

Объем инициируемых исходных данных составляет 10 Мб.

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

Принципы построения информационного обеспечения ИС:

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

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

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

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

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

ИС имеет модульную структуру и построена в двухуровневой архитектуре клиент-сервер. Информационная система поддерживает уровни представлений и хранения данных.

Нижним уровнем информационного обеспечения является уровень базы данных (БД). На уровне БД данные управляются с помощью системы управления реляционной базой данных Microsoft SQL Server 2005.

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

4.2 Виды и методы контроля в маршрутах обработки данных

В системе ИС реализованы различные виды и методы контроля в маршрутах обработки данных, а именно:

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

· контроль входных данных с блокировкой (жесткий контроль), запрещающий дальнейшее выполнение процесса;

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

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

4.3 Перечень источников информации (входная и выходная информация)

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

К таким документам могут относиться финансовые документы, нормативно-правовые акты, описания продукции (услуги), описания торгового предприятия и другие документы.

Интенсивность и объем потоков информации определяется регламентами ввода информации в систему, которые в свою очередь определяются графиком проекта также нормативными документами по предоставлению отчетности в вышестоящие органы, и количеством АРМ.

Система является масштабируемой, то есть сохраняется работоспособность системы при наращивании информационных потоков.

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

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

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

· разработка отчета в среде Microsoft Access 2003,включение отчета в систему ИС.

4.4 Общие требования к организации сбора, передачи, контроля и корректировки информации

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

Конкретный перечень вводимых данных по операциям и формы экранов ввода представлены в Руководствах пользователей на каждое АРМ.

Информационный обмен между сервером системы и рабочими станциями осуществляется по локальной сети. На транспортном уровне для взаимодействия компонентов системы используется стек протоколов TCP/IP.

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

4.5 Описание построения информационной базы, ее характеристики

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

Пользователи системы и их права доступа к информации определяются на уровне СУБД.

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

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

Централизованная база данных ИС создается автоматически из образа базы (back-up) при установке системы с помощью программы-инсталлятора. В созданной базе данных изначально введен пользователь с правами всех сотрудников (логин admin, пароль admin). Дальнейшее заполнение ЦБД производится пользователями системы с соответствующих АРМ.

В СУБД Microsoft SQL Server (2005) Enterprise Edition создается специальный пользователь, которому предоставляются все права для работы с ЦБД. В дальнейшем все подключения к СУБД со стороны производятся только посредством данного пользователя. Для защиты информации от несанкционированного доступа в системе предусмотрены также:

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

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

4.6 Программные и аппаратные требования

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

Требования к аппаратной части вытекают из требований к СУБД и пакету MS Office и изложены в таблице 4.1.