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

Оглавление

Введение

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-х годов. Количество внедрений изменяется десятками,качество внедрения зачастую является предметом споров, слухов, домыслов иразочарований. В то же время, интерес к ИС не угасает, и руководителипредприятий «отваживаются» на рискованные шаги.

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

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

1. Теоретическая часть1.1 Понятие ИС и ее жизненного цикла, этапыпроектирования ИС

Информационная система (ИС) в целом — автоматизированнаясистема, предназначенная для организации, хранения, пополнения, поддержки и представленияпользователям информации в соответствии с их запросами. [2]

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

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

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

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

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

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

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

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

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

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

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

развитие системы. [3]

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

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

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

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

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

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

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

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

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

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

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

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

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

SADT (Structured Analysis and DesignTechnique). Для новых систем 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Х.[5]

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

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

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

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

сущности;

атрибуты;

связи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.        Маклаков С.В. Моделирование бизнес-процессов с BPwin4.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.