Разработка информационной системы для магазина

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

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

Проанализировав деятельность мебельного цеха, и проведя пред-проектное исследование, можно выделить три основных бизнес-процесса АИС «Мебель»:

1. Принятие заказа.

2. Изготовление частей изделия.

3. Расчет с заказчиком.

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

- контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);

- диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);

- диаграммы дерева узлов;

- диаграммы только для экспозиции (FEO).

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

Главная бизнес-функция «АИС Мебель» - изготовление мебели. Входными данными является заявка на выполнение работ. Выходными - акт о выполненных работах. В качестве управления выступают порядок обслуживания клиента, ГОСТы и ТУ по изготовлению мебели, проекты готовых решений, характеристики материалов, методики изготовления. Инструментами выполнения главной бизнес-функции служат сотрудники ОАО «Заказчик» (бухгалтер, менеджер, курьер, рабочие, мастер-технолог), а также оборудование, необходимое для изготовления мебели. Диаграмма IDEF0 для главной бизнес-функции представлена на рисунке 5.

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

Функциональный блок «Принятие заказа» включает регистрацию заказа, разработку эскиза, а затем и проекта изделия, а также его согласование с заказчиком. В случае внесения заказчиком каких-либо изменений, эскиз и проект разрабатываются заново. В управлении блоком «Принятие заказа» участвуют характеристики материалов, порядок обслуживания клиентов, проекты готовых решений, ГОСТы по изготовлению мебели. На вход поступает заявка на выполнение работ, на выходе получен согласованный проект и договор. В качестве исполнителей выступают менеджер и мастер-технолог. Диаграмма декомпозиции блока «Принятие заказа» представлена на рисунке 7.

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

Рисунок 5 - Контекстная диаграмма

Рисунок 6 - Диаграмма декомпозиции контекстной диаграммы

Рисунок 7 - Диаграмма декомпозиции блока «Принятие заказа»

Блок «Изготовление частей изделия» имеет в своем составе следующие блоки: заказ и получение материалов, раскрой плиты на детали, сверление соединительных отверстий облицовывание кромочным материалом. Диаграмма декомпозиции блока «Изготовление частей изделия» представлена на рисунке 8. Для автоматизации процесса раскроя потребовалось уточнить, какие процессы входят в блок «Раскрой плиты на детали». Поэтому была составлена и его диаграмма декомпозиции, которая представлена на рисунке 9.

Функциональный блок «Расчет с заказчиком» включает доставку, сборку, оплату и закрытие заявки. На вход поступают части изделия, готовые к сборке, в качестве выходных данных выступает акт о выполненных работах. Управляют данным блоком согласованный проект, договор, порядок обслуживания клиентов. Исполнителями являются рабочие, курьер, бухгалтер-кассир и менеджер. Диаграмма декомпозиции функционального блока «Расчет с заказчиком» представлена на рисунке 10.

Рисунок 8 - Диаграмма декомпозиции блока «Изготовление частей изделия»

Рисунок 9 - Диаграмма декомпозиции блока «Раскрой плиты на детали»

Рисунок 10 - Диаграмма декомпозиции блока «Расчет с заказчиком»

1.3.2 Диаграмма потоков данных

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

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

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

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

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

В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое.

Диаграмма потоков данных для бизнес-процессов ОАО «Заказчик» представлена на рисунке 11.

Рисунок 11 - Диаграмма потоков данных

2. Системное проектирование ИС

2.1 Разработка концепции, архитектуры построения и платформы реализации ИС

­ файл-сервер;

­ клиент-сервер;

­ многоуровневая архитектура.

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

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

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

­ масштабируемость;

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

­ высокая безопасность;

­ высокая надёжность;

­ низкие требования к скорости канала (сети) между терминалами и сервером приложений;

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

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

­ сложность разработки систем на основе многоуровневой архитектуры, т.к очень сложно «состыковать» различные модули, особенно если они написаны разными группами. А изменение в одном модуле, как правило, вызывает лавинообразные изменения в остальных, и с этой точки зрения даже простую систему, основанную на многоуровневой архитектуре, будет сложнее выполнить в 2 раза;

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

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

­ высокая сложность администрирования.

Рассмотрев все достоинства и недостатки каждой из архитектур, для реализации системы «АИС Мебель» выбираем архитектуру клиент-сервер. Данная архитектура позволяет оптимально распределить работу между клиентскими и серверными частями системы: приложение, работающее на рабочей станции, не читает записи базы данных «напрямую», а посылает запросы на сервер, где они последовательно обрабатываются, а результаты обработки отсылаются на рабочую станцию. А это существенно сокращает информационные потоки в ЛВС.

Схема функционирования и построения информационной системы представлена рисунке 12.

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

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

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

- информационная;

- техническая;

- программная;

- математическая;

- лингвистическая.

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

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

- функциональную структуру;

- информационное обеспечение;

- математическое (алгоритмическое и программное) обеспечение;

- техническое обеспечение;

- организационное обеспечение,

а на стадии разработки ИС дополнительные обеспечения:

- правовое;

- лингвистическое;

- технологическое;

- методологическое;

- интерфейсы с внешними ИС.

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

Математическое обеспечение состоит из алгоритмического и программного.

Организационное обеспечение - это совокупность средств и методов организации производства и управления ими в условиях внедрения ИС.

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

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

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

Рисунок 13 - Состав функциональных и обеспечивающих подсистем

2.3 Техническое обеспечение ИС

В комплекс технических средств должны входить следующие элементы:

- рабочие станции;

- источники бесперебойного питания;

- средства для построения ЛВС;

- сервер БД;

- принтер.

Требования к серверу:

- память 8 Гб;

- процессор 2.2 ГГц Intel Xeon 5500 минимум;

- скорость диска SATA 8 Гбит/с;

- сетевой адаптер 10 Гбит/с;

- операционная система Windows Server 2008.

Требования к рабочей станции:

- процессор 2 Ггц;

- память 2 Гб;

- жесткий диск не менее 500;

- операционная система Windows 7;

- сетевой адаптер 100 Мбит/с.

Технические средства ИС описаны с учетом требований к функционированию прикладного пpогpаммного комплекса. Технические средства должны обеспечить:

- круглосуточный режим работы комплекса технических средств и оборудования;

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

- защиту данных от несанкционированного доступа;

- сервера и рабочие места должны быть объединены локальной сетью.

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО «Заказчик».

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

Рисунок 14 - Логическая схема сети ОАО "Заказчик"

3. Информационное обеспечение ИС