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

• Введение
• 1. Теоретическая часть
• 1.1 Понятие ИС и ее жизненного цикла, этапы проектирования ИС
• 1.2 Подход к проектированию информационной системы, реализованный в проекте
• 1.3 Характеристика CASE-средства для моделирования бизнес-процессов предметной области и выбранного метода (IDEF0 или DFD — общие сведения, состав диаграмм)
• 1.4 Характеристика CASE-средства для создания модели данных предметной области. ERD модель (общие сведения, состав диаграммы «сущность-связь»)
• 1.5 Роль и место базы данных в информационной системе, обоснование выбора используемой в проекте СУБД
• 2. Проектная часть курсовой работы
• 2.1 Описание предметной области задачи
• 2.2 Постановка задачи
• 2.3 Построение модели потоков данных (IDF0, DFD) в BPwin
• 2.4 Построение модели данных в ERwin
• 2.5 Создание базы данных
• Заключение
• Список использованной литературы
• Приложения

Информационные системы (ИС) управления предприятиями присутствуют на Российском рынке относительно недавно, эксперименты с внедрением данных систем на отечественных предприятиях стали проводиться в основном с начала 90-х годов. Количество внедрений изменяется десятками, качество внедрения зачастую является предметом споров, слухов, домыслов и разочарований. В то же время, интерес к ИС не угасает, и руководители предприятий «отваживаются» на рискованные шаги.

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

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

1. Теоретическая часть

1.1 Понятие ИС и ее жизненного цикла, этапы проектирования ИС

Информационная система (ИС) в целом — автоматизированная система, предназначенная для организации, хранения, пополнения, поддержки и представления пользователям информации в соответствии с их запросами. http://do.bti.secna.ru/lib/book_it/inf_sistem.html

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

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

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

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

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

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

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

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

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

интеграцию и сборку системы, проведение ее испытаний;

эксплуатацию системы и ее сопровождение;

развитие системы. http://www.abn.ru/inf/setevoi/cycle.shtml

1.2 Подход к проектированию информационной системы, реализованный в проекте

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

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

Процессный подход подводит к необходимости перехода на так называемое тонкое производство, или тонкую ресурсосберегающую структуру (Lean production).

Основными чертами такой реорганизации являются:

широкое делегирование полномочий и ответственности исполнителям;

сокращение количества уровней принятия решений;

сочетание принципа целевого управления с групповой организацией труда;

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

Процессный подход к анализу и моделированию бизнес-процессов и последующей разработке требований к информационным системам позволяет оперативно изменять и дорабатывать технологии, безболезненно (без остановки производства) модернизировать информационную систему предприятия. http://www.cfin.ru/press/loginfo/2001;02/06.shtml

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

1.3 Характеристика CASE-средства для моделирования бизнес-процессов предметной области и выбранного метода (IDEF0 или DFD — общие сведения, состав диаграмм)

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

SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF0) применяется для определения требований (функций) для разработки системы, реализующей выделенные функции. Для уже существующих — IDEF0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм (рис.1). Вершина этой древовидной структуры, представляющая собой самое общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).

Рис. 1 Модель в нотации IDEF0

DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0.

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

ER (Entity-Relationship Diagrams) диаграммы «сущность-связь». Методология описания данных (IDEF1X).

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

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

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

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

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

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

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

1.4 Характеристика CASE-средства для создания модели данных предметной области. ERD модель (общие сведения, состав диаграммы «сущность-связь»)

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

Наиболее распространенным средством моделирования данных являются диаграммы «сущность-связь» (ERD), нотация которых была впервые введена Питером Ченом в 1976 г. и получила дальнейшее развитие в работах Ричарда Баркера. Различные CASE-средства используют несколько отличающиеся друг от друга нотации ERD. Одна из наиболее распространенных нотаций предложена Баркером (Oracle Designer). В CASE-средстве SilverRun используется один из вариантов нотации Чена. CASE-средства ERwin, ER / Studio, Design / IDEF используют методологию IDEF 1Х. http://www.cfin.ru/press/loginfo/2001;02/06.shtml

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

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

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

Диаграммы «сущность-связь» включают:

сущности;

атрибуты;

связи.

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

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

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

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

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

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

Альтернативный ключ (Alternate Key) — потенциальный ключ, не ставший первичным. На диаграмме альтернативный ключ обозначается AK n. m, где n — порядковый номер ключа, m — порядковый номер атрибута в ключе.

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

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

На логическом уровне можно установить:

идентифицирующую связь один-ко-многим;

неидентифицирующую связь один-ко-многим;

связь многие-ко-многим.

Разработка ERD включает следующие основные этапы:

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

Идентификация отношений между сущностями и указание типов отношений.

Разрешение неспецифических отношений (отношений многие-ко-многим).

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

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

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

В информационных системах, использующих БД, можно:

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

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

избежать противоречий в хранимых данных;

обеспечить сохранность и целостность информации:

многократно использовать одни и те же данные различными прикладными программами;

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

поддерживать адекватность базы данных моделируемой ПО;

обеспечить защиту данных от несанкционированного доступа.

Концепция БД позволяет создавать интегрированные информационные системы, поддерживающие сложные и разнообразные структуры объектов предметной области, содержащие большое число типов данных, значительные объемы фактографической или текстовой информации, а также сделать реальной задачу обеспечения высокой достоверности обработки и хранения больших объемов данных. http://www.cfin.ru/press/loginfo/2001;02/06.shtml

2. Проектная часть курсовой работы

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

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

2.2 Постановка задачи

2.2.1 Цель проектирования ИС:

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

2.2.2 Основные функции, требующие автоматизации:

учет клиентов и заказов;

учет договоров.

2.2.3 Используемые документы и их описание:

Товар — внутренний документ, содержащий информацию о наличии товара, о его цене. Функция: учет товара.

Клиент — внутренний документ, содержащий информацию о клиенте. Функция: учет клиентов.

Заказ — внутренний документ, содержит информацию о всех заказах, сделанных клиентами. Функция: учет заказов.

Договор — исходящий документ. Функция: юридическое обоснование.

Отчет — внутренний документ, составляется на основе запроса по клиентам и товару.

2.3 Построение модели потоков данных (IDF0, DFD) в BPwin

Анализ предметной области организации отгрузки товара и получения отчетов по данному процессу проведем с помощью CASE-средства BPwin с использованием двух методов IDF0 и DFD. Выбор данных методов обусловлен следующими факторами:

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

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

На контекстной диаграмме А-0 отображена система управления процессом.

Report for Diagram: A-0, Организация процесса отгрузки товара

Activity Name: Организация процесса отгрузки товара

Link Name: Канцелярские принадлежности

Link Name: Материалы

Link Name: Услуги организации

Link Name: Стандарты

Link Name: Мнение эксперта

Link Name: Персонал

Link Name: Оборудование

Link Name: Сведения о клиенте

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

Report for Diagram: A0, Организация процесса отгрузки товара

Activity Name: Комплектование набора товаров

Activity Name: Обслуживание клиентов

Link Name: Канцелярские принадлежности

Link Name: Материалы

Link Name: Услуги организации

Link Name: Стандарты

Link Name: Мнение эксперта

Link Name: Персонал

Link Name: Оборудование

Link Name: Отгружаемый товар

Link Name: Сведения о клиенте

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

Report for Diagram: A2, Обслуживание клиентов

Подсистемы:

Activity Name: Оформление «карточки» клиента

Activity Name: Оформление пакета документов

Activity Name: Предоставление услуги

Потоки данных:

Link Name: Услуги организации

Link Name: Стандарты

Link Name: Мнение эксперта

Link Name: Персонал

Link Name: Оборудование

Link Name: Отгружаемый товар

Link Name: Пакет документов клиента

Link Name: Готовый пакет документов

Link Name: Карточка клиента

Link Name: Документация

Link Name: Сведения о клиенте

Link Name: Карточка документов клиента

Хранилища:

Data Store Name: База клиентов

Data Store Name: Хранилище оформленных документов

Report for Diagram: A23, Предоставление услуги

Подсистемы:

Activity Name: Прием заявки

Activity Name: Поиск заказанного товара

Activity Name: Заполнение первичной документации

Activity Name: Отгрузка товара

Потоки данных:

Link Name: Услуги организации

Link Name: Стандарты

Link Name: Мнение эксперта

Link Name: Персонал

Link Name: Оборудование

Link Name: Готовый пакет документов

Link Name: Сведения о клиенте

Link Name: Отложенные заявки

Link Name: Заявка на товар

Link Name: Первичная документация

Link Name: Отчет об отгрузке

Link Name: Заявка на склад

Link Name: Документы на отгрузку

Link Name: Отчет о наличии

Link Name: Выполненная заявка

Link Name: Отказ

Хранилища:

Data Store Name: БД выполненных заявок

Data Store Name: БД отложенных заказов

Data Store Name: БД отчетов

Внешние сущности:

External Name: Клиент

2.4 Построение модели данных в ERwin

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

2.4.1 Логический уровень — это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, например «Постоянный клиент», «Отдел» или «Фамилия сотрудника». Объекты модели логического уровня называются сущностями и атрибутами.

Рис. 1 Диаграмма ERD-уровень сущности

Рис. 2 Диаграмма ERD-уровень атрибутов

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

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

Рис. 3 Диаграмма ERD-физическая модель

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

2.5 Создание базы данных

Создадим базу данных «Отгрузка товаров в разрезе клиентов» в СУБД MS Access. Основным назначением базы данных «Отгрузка товаров в разрезе клиентов» будет автоматизация функции по учету клиентов и заказов.

Рис. 1 Схема данных БД «Отгрузка товаров в разрезе клиентов»

2.5.1 Таблицы для хранения данных

В соответствии со схемой данных БД «Отгрузка товаров в разрезе клиентов» имеет следующие таблицы:

Рис. 2 Таблицы БД «Отгрузка товаров в разрезе клиентов»

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

Рис. 3 Пример структуры таблицы «Договоры» в конструкторе

2.5.2 Формы для ввода информации

Создадим формы для ввода информации. Например, для заполнения формы — Заказы, необходимо заполнение форм-справочников: формы — Товар и формы — Клиенты; а для формы Договоры, необходима форма-справочник: Справочник договоров.

Рис. 4 Пример форм-справочников: товар и клиенты

Рис. 5 Форма для оформления заявки на товар

Рис. 6 Форма для оформления договора

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

Рис. 7 Главная кнопочная форма БД «Отгрузка товаров в разрезе клиентов»

2.5.3 Запросы для создания отчетов

Рис. 8 Вкладка «Запросы» в окне БД «Отгрузка товаров в разрезе клиентов»

Для формирования отчета в разрезе клиента создадим запрос «Клиент запрос». Данный запрос предназначен для выбора клиентов, заказов и стоимости заказов за определенный промежуток времени (месяц).

Рис. 9 Запрос «Клиент запрос» в Конструкторе

2.5.4 Отчет

Для формирования отчета в разрезе клиентов, создадим «Отчет_Клиенты» на основании запроса «Клиент Запрос» .

Рис. 10 «Отчет_Клиенты», сформированный по запросу «Клиенты Запрос»

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

Заключение

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

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

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

1. Автоматизированные информационные технологии в экономике: Учебник / Под ред. проф. Г. А. Титоренко, — М.: Компьютер, ЮНИТИ, 2004.

2. Вендров А. М. CASE — технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 2005.

3. Вендров А. М. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006.

4. Маклаков С. В. Моделирование бизнес-процессов с BPwin 4.0. — М.: ДИАЛОГМИФИ, 2004.

5. Список сетевых ресурсов

6. http://do. bti. secna.ru/lib/book_it/inf_sistem.html

7. http://www.abn.ru/inf/setevoi/cycle. shtml

8. http://www.cfin.ru/press/loginfo/2001;02/06. shtml

9.

Приложения

Рис. А-0 Контекстная диаграмма отгрузки товара

Рис. А0 Диаграмма декомпозиции отгрузки товара

Рис.2А Диаграмма декомпозиции по работе с клиентами

Рис. А23 Диаграмма декомпозиции системы предоставления услуг

Рис. Диаграмма дерева узлов