Автор работы: Пользователь скрыл имя, 24 Марта 2011 в 13:55, курсовая работа
Проект по созданию сложной ИС не возможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.
Введение………………………………………………………………..………..…..5
Глава 1. Экономические информационные системы…………………………6
1.1 Понятие и классификация ЭИС…………………………………………….6
1.2 Жизненный цикл ЭИС……………………………………………..……....13
Глава 2. Схема Захмана представление архитектуры ИС………….………...22
1.1Точки зрения…………………………………………………..……......….23
1.2 Аспекты…................................................................................................25
1.3 Названия строк и столбцов………………………………………………25
1.4 Характеристика взгляда……………………………………………….….27
1.5 Дополнение схемы………………………………………………………...28
1.6 Замечания о полноте…………………………………………………......29
1.7 Интеграция схемы Захмана с методами моделирования бизнеса...........30
Глава 3. Разработка модели бизнес-процессов организации в среде BPWin.32
3.1 Построение модели бизнес-процесса в нотации IDEF0………………....33
3.2 Построение диаграммы узлов и FEO диаграммы………………………..38
3.3 Построение IDEF3 диаграммы…………………………………………….40
3.4 Построение DFD-диаграммы……………………………………………...41
3.5 Стоимостной анализ………………………………………………………..41
3.6 Реинжиниринг бизнес-процесса(модедь TO-BE)………………………...43
Глава 4. Разработка информационной модели организации в среде ERWin………………………………………………………………………………..45
4.1 Проектирование логической модели базы данных…………....………………45
Заключение………………..……………………………………….………………..48
Список использованной литературы………………………………..…………..49
При помощи диаграммы дерева узлов показана вся деятельность отдела компьютерной фирмы, занимающегося гарантийным обслуживанием компьютерной техники(Рис. 3.6).
Рис. 3.5
Дерево узлов
В качестве FEO-диаграммы я выбрал диаграмму декомпозиции блока «ремонтная деятельность» (рис. 3.7). Данная диаграмма отражает альтернативный взгляд на процесс осуществления ремонтной деятельности.
Рис. 3.6
FEO-диаграмма
В нотации IDEF3 я описал прием неисправной техники (Рис. 3.8.).
При приеме заявки необходима контактная информация о клиенте, после определяется какой вид работ будет производится: гарантийный или платный. Далее происходит идентификация неполадки, затем клиента уведомляют с условиями выбора, а именно: отправить технику на ремонт или вернуть обратно.
Рис. 3.7 IDEF3 диаграмма «Прием неисправной техники»
Диаграммы потоков данных используются для описания документооборота и обработки информации. В виде DFD-диаграммы я решил изобразить работы по оформлению и ведению складских операций.
На рис. П 3.1 изображена диаграмма «Склад». На ней размещены четыре работы:
В результате на выходе мы получаем базу данных «Выдача детали» и «Списание со склада КТ и подготовка к тесту».
Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса.
С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, поддержки клиента.
Основные
статьи расходов описаны в таблице 3.1.
Статья затрат | Определение |
Детали | Затраты на закупку материалов, деталей и комплектующих |
Персонал отдела | Затраты на оплату работ сотрудников отдела |
Управление | Затраты на управленческую деятельность, такую как организация работ, соблюдение всех правил проведения ремонта и техники безопасности |
Инструменты | Затраты на покупку или использование инструментов в ремонтной деятельности отдела |
Таблица 3.1. Статьи затрат бизнес-процесса
Затраты 1 месяца работы отдела гарантийного обслуживания в рублях отображены в таблице (П 4.1.)
Оценив стоимость всех работ я получил следующие цифры.
Основная деятельность обходится в 5329200,00 рублей. Эта сумма распределяется между статьями затрат следующим образом:
Самой
дорогостоящей операцией
2.6
Реинжиниринг бизнес-процесса
После составления модели «как есть» она анализируется и выявляются недостатки, которые предполагается исправить, построив модель «как должно быть».
Исходя из этого я решил добавить еще одну услугу,которая бует являться скорее дополнительной, нежели одной из основных. Эта услуга будет называться «Сбор компьютеров». Результатом этой работы является сборка дорогих игровых компьютеров, сборка дешевых офисных компьютеров, сборка компьютеров для учебных заведений (рис. 3.9). Таким образом при небольших затратах появляется ощутимая прибыль.
Рис. 3.8 модель TO-BE
Декомпозировав данную модель, получаем следующее (Рис. 3.10.)
Рис. 3.9 «Сборка компьютеров»
Соответственно
после этого диаграмма дерева
узлов изменяется, она представлена в
(П.1).
Глава
4. Разработка информационной модели организации
в среде Erwin
Erwin используется для построения модели данных, и имеет два уровня представления – логический и физический. На логическом уровне данные представляются так, как они выглядят в реальном мире (рис. П5.1). Физический уровень данных – это отображение системного каталога, который зависит от конкретной реализации СУБД (рис. П5.2).
Далее я опишу, как взаимодействуют сущности на диаграмме отдела гарантийного обслуживания в компьютерной фирме.
Каждый сотрудник выполняет ту или иную работу. Существуют администратор, мастера и директор.
При подаче клиентом заявки она сразу же выполняется при условии, что все необходимые ресурсы имеются в наличии, если какой либо детали нет, то сразу оформляется заказ на ее поставку.
Логическая модель данных основана на сущностях и их атрибутах.
Описание
сущностей и атрибутов
Атрибут | Описание атрибута | РК | FК |
ID Мастера | Идентификационный номер работника | Да | Нет |
ФИО | ФИО | Нет | Нет |
e-mail работника | Нет | Нет | |
Телефон | Номер телефона сотрудника | Нет | Нет |
Таблица
1. Сущность «Мастера»
Атрибут | Описание атрибута | РК | FК |
ID поставщика | Идентификационный номер поставщика | Да | Нет |
Наименование фирмы | Наименование фирмы | Нет | Нет |
Телефон | Телефон фирмы | Нет | Нет |
Адрес | Адрес фирмы | Нет | Нет |
Эл. почта | Адрес электронной почты |
Таблица
2. Сущность «Поставщики»
Атрибут | Описание атрибута | РК | FК |
ID клиента | Идентификационный номер клиента | Да | Нет |
ФИО | ФИО клиента | Нет | Нет |
Телефон | Телефон клиента | Нет | Нет |
Электронный адрес клиента | |||
Адрес | Адрес клиента | Нет | Нет |
Таблица
3. Сущность «Клиент»
Атрибут | Описание атрибута | РК | FК |
ID детали | Идентификационный номер детали | Да | Да |
Количество | Количество деталей | Нет | Нет |
Название | Название деталей | Нет | Нет |
Цена | Цена детали | Нет | Нет |
Таблица
4. Сущность «Склад»
Атрибут | Описание атрибута | РК | FК |
ID заказа | Идентификационный номер детали | Да | Нет |
ID детали | Идентификационный номер детали | Нет | Да |
ID поставщика | Идентификационный номер поставщика | Нет | Да |
Название | Наименование детали | Нет | Нет |
Количество | Количество деталей заказа | Нет | Нет |
Цена | Цена продажи | Нет | Нет |
Таблица
5. Сущность «Заказ детали»
Атрибут | Описание атрибута | РК | FК |
ID мастера | Идентификационный номер мастера | Да | Нет |
ID клиента | Идентификационный номер клиента | Нет | Да |
ID заявки | Идентификационный номер заявки | Нет | Да |
ID детали | Идентификационный номер детали | Нет | Да |
Цена | Стоимость работ | Нет | Нет |
Наименование | Наименование проводимых работ | Нет | Нет |
Информация о работе Схема Захмана: представление архитектуры информационной системы